Hi Andrew,
As a designer, I agree with your point about keeping things that
encourage well-written code (i.e., avoiding errors in "normal"
paths). That's why I originally added the MaxXxxRecords.
But in practice, they've got another design problem. They each
limit the number of rows in powXxxTable in the MIB - but they do
that *across* all power managed components (System and some
Subunits). Yucky.
Also maps terribly to PWG XML Schema, where the limit in the
System object spans/includes a bunch of Subunit objects.
This is a sad collision of the MIB versus XML mapping, with no
real obvious solution.
Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Hardcopy WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusichttp://sites.google.com/site/highnorthinc
mailto:blueroofmusic at gmail.com
Christmas through April:
579 Park Place Saline, MI 48176
734-944-0094
May to Christmas:
PO Box 221 Grand Marais, MI 49839
906-494-2434
On Wed, Nov 3, 2010 at 2:43 PM, Mitchell, Andrew (Solutions Architect) <
andrew.mitchell2 at hp.com> wrote:
> OK, so I understand that. At the F2F I hadn't fully internalized the Power
> Model stuff yet. In general I'm not a fan of removing things that well
> written implementations could take use of. Its like dropping error codes as
> return values because no one used them, you're punishing the ones that are
> written well because most simply ignore them. But I also now get why part of
> the group can't be marked as optional and I agree that any ASN.1 errors that
> can be avoided should be.
>> All that being said, I agree that dropping the MaxXxxRecords may be the
> right thing to do, but I still want to make my viewpoint clear since I
> disagree with the reasoning you originally provided in the comments.
>> Andrew
>> From: Ira McDonald <blueroofmusic at gmail.com<mailto:blueroofmusic at gmail.com> >>
> Date: Wed, 3 Nov 2010 18:18:50 +0000
> To: "Andrew R. Mitchell" <andrew.mitchell2 at hp.com<mailto:
>andrew.mitchell2 at hp.com>>, Ira McDonald <blueroofmusic at gmail.com<mailto:
>blueroofmusic at gmail.com>>
> Cc: "wims at pwg.org<mailto:wims at pwg.org>" <wims at pwg.org<mailto:wims at pwg.org> >>
> Subject: Re: [WIMS] High North has reviewed Power Model/MIB and has
> comments
>> Hi Andrew,
>> First a request - please compile this MIB with any SNMP compilers (from
> SDKs, management tools, etc.) you have available. I hate making ASN.1
> errors that are avoidable.
>>> Following IETF MIB convention, we always make whole element groups
> one conformance level.
>> So, yes we *could* add the MaxXxxRecords to some new group (but
> not the REQUIRED PowerGeneral group).
>> In review discussion at the October F2F, Pete Zehler and others seemed
> to all agree that client-side implementers will ignore these properties.
>> My experience over 15 years writing private MIBs for 3 printer vendors has
> been Pete's right - clients just try to create the row and handle the error
> for
> table full.
>> My Samsung implementers don't want MaxXxxRecords, because they
> don't plan to use them client-side and they inflate the number of
> REQUIRED elements (which looks bad to upper management).
>> Cheers,
> - Ira
>> Ira McDonald (Musician / Software Architect)
> Chair - Linux Foundation Open Printing WG
> Co-Chair - IEEE-ISTO PWG IPP WG
> Co-Chair - TCG Hardcopy WG
> IETF Designated Expert - IPP & Printer MIB
> Blue Roof Music/High North Inc
>http://sites.google.com/site/blueroofmusic>http://sites.google.com/site/highnorthinc> mailto:blueroofmusic at gmail.com<mailto:blueroofmusic at gmail.com>
> Christmas through April:
> 579 Park Place Saline, MI 48176
> 734-944-0094
> May to Christmas:
> PO Box 221 Grand Marais, MI 49839
> 906-494-2434
>>>> On Wed, Nov 3, 2010 at 1:50 PM, Mitchell, Andrew (Solutions Architect) <
>andrew.mitchell2 at hp.com<mailto:andrew.mitchell2 at hp.com>> wrote:
> Ira,
>> I have been reviewing the doc as well as have some others within HP looking
> at it. While I don't have any additional comments yet, I do have a couple
> questions on your comments. While I agree that most clients will never use
> the MacXxxRecords, is that a valid rational not to include them? Would a
> better option be mark the MaxXxxRecords as OPTIONAL parts of the sections.
>> Andrew
>> From: Ira McDonald <blueroofmusic at gmail.com<mailto:blueroofmusic at gmail.com> ><mailto:blueroofmusic at gmail.com<mailto:blueroofmusic at gmail.com>>>
> Date: Wed, 3 Nov 2010 17:07:46 +0000
> To: "wims at pwg.org<mailto:wims at pwg.org><mailto:wims at pwg.org<mailto:
>wims at pwg.org>>" <wims at pwg.org<mailto:wims at pwg.org><mailto:wims at pwg.org> <mailto:wims at pwg.org>>>, Ira McDonald <blueroofmusic at gmail.com<mailto:
>blueroofmusic at gmail.com><mailto:blueroofmusic at gmail.com<mailto:
>blueroofmusic at gmail.com>>>
> Subject: [WIMS] High North has reviewed Power Model/MIB and has comments
>> (2) Technical - delete all 10 PowerGeneral.MaxXxxRecords elements
> - section 5.1.1 through 5.1.10, lines 825-892
>> Rationale: Table limit elements are unlikely to be queried/used
> - typical Client will simply attempt to create a row
>>> Power MIB (wd-wimspowermib10-20100926.pdf/mib)
>> (2) Technical - delete all 10 powGeneral.MaxXxxRecords objects
> - section 5 (spec), lines 261-363 and 389-413 (MIB)
>> Rationale: See Power Model comment (2) above
>>>
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/wims/attachments/20101103/5eaaa965/attachment-0001.html>