attachment-0001
Hi Andrew,<br><br>As a designer, I agree with your point about keeping things that<br>encourage well-written code (i.e., avoiding errors in "normal"<br>paths). That's why I originally added the MaxXxxRecords.<br>
<br>But in practice, they've got another design problem. They each<br>limit the number of rows in powXxxTable in the MIB - but they do<br>that *across* all power managed components (System and some<br>Subunits). Yucky. <br>
<br>Also maps terribly to PWG XML Schema, where the limit in the <br>System object spans/includes a bunch of Subunit objects.<br><br>This is a sad collision of the MIB versus XML mapping, with no<br>real obvious solution.<br>
<br>Cheers,<br>- Ira<br><br clear="all">Ira McDonald (Musician / Software Architect)<br>Chair - Linux Foundation Open Printing WG<br>Co-Chair - IEEE-ISTO PWG IPP WG<br>Co-Chair - TCG Hardcopy WG<br>IETF Designated Expert - IPP & Printer MIB<br>
Blue Roof Music/High North Inc<br><a href="http://sites.google.com/site/blueroofmusic" target="_blank">http://sites.google.com/site/blueroofmusic</a><br><a style="color: rgb(102, 0, 204);" href="http://sites.google.com/site/highnorthinc" target="_blank">http://sites.google.com/site/highnorthinc</a><br>
mailto:<a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a><br>Christmas through April:<br> 579 Park Place Saline, MI 48176<br> 734-944-0094<br>May to Christmas:<br> PO Box 221 Grand Marais, MI 49839<br>
906-494-2434<div style="display: inline;"></div><div style="display: inline;"></div><div style="display: inline;"></div><br>
<br><br><div class="gmail_quote">On Wed, Nov 3, 2010 at 2:43 PM, Mitchell, Andrew (Solutions Architect) <span dir="ltr"><<a href="mailto:andrew.mitchell2@hp.com">andrew.mitchell2@hp.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
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.<br>
<br>
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.<br>
<div class="im"><br>
Andrew<br>
<br>
From: Ira McDonald <<a href="mailto:blueroofmusic@gmail.com">blueroofmusic@gmail.com</a><mailto:<a href="mailto:blueroofmusic@gmail.com">blueroofmusic@gmail.com</a>>><br>
</div>Date: Wed, 3 Nov 2010 18:18:50 +0000<br>
To: "Andrew R. Mitchell" <<a href="mailto:andrew.mitchell2@hp.com">andrew.mitchell2@hp.com</a><mailto:<a href="mailto:andrew.mitchell2@hp.com">andrew.mitchell2@hp.com</a>>>, Ira McDonald <<a href="mailto:blueroofmusic@gmail.com">blueroofmusic@gmail.com</a><mailto:<a href="mailto:blueroofmusic@gmail.com">blueroofmusic@gmail.com</a>>><br>
Cc: "<a href="mailto:wims@pwg.org">wims@pwg.org</a><mailto:<a href="mailto:wims@pwg.org">wims@pwg.org</a>>" <<a href="mailto:wims@pwg.org">wims@pwg.org</a><mailto:<a href="mailto:wims@pwg.org">wims@pwg.org</a>>><br>
Subject: Re: [WIMS] High North has reviewed Power Model/MIB and has comments<br>
<div><div></div><div class="h5"><br>
Hi Andrew,<br>
<br>
First a request - please compile this MIB with any SNMP compilers (from<br>
SDKs, management tools, etc.) you have available. I hate making ASN.1<br>
errors that are avoidable.<br>
<br>
<br>
Following IETF MIB convention, we always make whole element groups<br>
one conformance level.<br>
<br>
So, yes we *could* add the MaxXxxRecords to some new group (but<br>
not the REQUIRED PowerGeneral group).<br>
<br>
In review discussion at the October F2F, Pete Zehler and others seemed<br>
to all agree that client-side implementers will ignore these properties.<br>
<br>
My experience over 15 years writing private MIBs for 3 printer vendors has<br>
been Pete's right - clients just try to create the row and handle the error for<br>
table full.<br>
<br>
My Samsung implementers don't want MaxXxxRecords, because they<br>
don't plan to use them client-side and they inflate the number of<br>
REQUIRED elements (which looks bad to upper management).<br>
<br>
Cheers,<br>
- Ira<br>
<br>
Ira McDonald (Musician / Software Architect)<br>
Chair - Linux Foundation Open Printing WG<br>
Co-Chair - IEEE-ISTO PWG IPP WG<br>
Co-Chair - TCG Hardcopy WG<br>
IETF Designated Expert - IPP & Printer MIB<br>
Blue Roof Music/High North Inc<br>
<a href="http://sites.google.com/site/blueroofmusic" target="_blank">http://sites.google.com/site/blueroofmusic</a><br>
<a href="http://sites.google.com/site/highnorthinc" target="_blank">http://sites.google.com/site/highnorthinc</a><br>
</div></div>mailto:<a href="mailto:blueroofmusic@gmail.com">blueroofmusic@gmail.com</a><mailto:<a href="mailto:blueroofmusic@gmail.com">blueroofmusic@gmail.com</a>><br>
<div class="im">Christmas through April:<br>
579 Park Place Saline, MI 48176<br>
734-944-0094<br>
May to Christmas:<br>
PO Box 221 Grand Marais, MI 49839<br>
906-494-2434<br>
<br>
<br>
<br>
</div><div class="im">On Wed, Nov 3, 2010 at 1:50 PM, Mitchell, Andrew (Solutions Architect) <<a href="mailto:andrew.mitchell2@hp.com">andrew.mitchell2@hp.com</a><mailto:<a href="mailto:andrew.mitchell2@hp.com">andrew.mitchell2@hp.com</a>>> wrote:<br>
Ira,<br>
<br>
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.<br>
<br>
Andrew<br>
<br>
</div>From: Ira McDonald <<a href="mailto:blueroofmusic@gmail.com">blueroofmusic@gmail.com</a><mailto:<a href="mailto:blueroofmusic@gmail.com">blueroofmusic@gmail.com</a>><mailto:<a href="mailto:blueroofmusic@gmail.com">blueroofmusic@gmail.com</a><mailto:<a href="mailto:blueroofmusic@gmail.com">blueroofmusic@gmail.com</a>>>><br>
<div class="im">Date: Wed, 3 Nov 2010 17:07:46 +0000<br>
</div>To: "<a href="mailto:wims@pwg.org">wims@pwg.org</a><mailto:<a href="mailto:wims@pwg.org">wims@pwg.org</a>><mailto:<a href="mailto:wims@pwg.org">wims@pwg.org</a><mailto:<a href="mailto:wims@pwg.org">wims@pwg.org</a>>>" <<a href="mailto:wims@pwg.org">wims@pwg.org</a><mailto:<a href="mailto:wims@pwg.org">wims@pwg.org</a>><mailto:<a href="mailto:wims@pwg.org">wims@pwg.org</a><mailto:<a href="mailto:wims@pwg.org">wims@pwg.org</a>>>>, Ira McDonald <<a href="mailto:blueroofmusic@gmail.com">blueroofmusic@gmail.com</a><mailto:<a href="mailto:blueroofmusic@gmail.com">blueroofmusic@gmail.com</a>><mailto:<a href="mailto:blueroofmusic@gmail.com">blueroofmusic@gmail.com</a><mailto:<a href="mailto:blueroofmusic@gmail.com">blueroofmusic@gmail.com</a>>>><br>
<div><div></div><div class="h5">Subject: [WIMS] High North has reviewed Power Model/MIB and has comments<br>
<br>
(2) Technical - delete all 10 PowerGeneral.MaxXxxRecords elements<br>
- section 5.1.1 through 5.1.10, lines 825-892<br>
<br>
Rationale: Table limit elements are unlikely to be queried/used<br>
- typical Client will simply attempt to create a row<br>
<br>
<br>
Power MIB (wd-wimspowermib10-20100926.pdf/mib)<br>
<br>
(2) Technical - delete all 10 powGeneral.MaxXxxRecords objects<br>
- section 5 (spec), lines 261-363 and 389-413 (MIB)<br>
<br>
Rationale: See Power Model comment (2) above<br>
<br>
<br>
</div></div></blockquote></div><br><div style="visibility: hidden; left: -5000px;" id="avg_ls_inline_popup"></div><style type="text/css">#avg_ls_inline_popup{position: absolute;z-index: 9999;padding: 0px 0px;margin-left: 0px;margin-top: 0px;overflow: hidden;word-wrap: break-word;color: black;font-size: 10px;text-align: left;line-height: 130%;}</style>
<br />--
<br />This message has been scanned for viruses and
<br />dangerous content by
<a href="http://www.mailscanner.info/"><b>MailScanner</b></a>, and is
<br />believed to be clean.