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/blueroofmusichttp://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.