[WIMS] High North has reviewed Power Model/MIB and has comments

[WIMS] High North has reviewed Power Model/MIB and has comments

[WIMS] High North has reviewed Power Model/MIB and has comments

Ira McDonald blueroofmusic at gmail.com
Wed Nov 3 19:34:10 UTC 2010


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/blueroofmusic
http://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>


More information about the wims mailing list