I might suggest (once again) that we use the technique whereby
only serious objections are sought. Lacking serious objections,
your proposed wording (with Ron Bergman's enhancements) would be
incorporated in the standard.
Regarding yet another delay in "finalizing" the Printer or HR MIB,
does it really matter? Vendors have been shipping code against
pre-released MIB standards for over 5 years now, so another holdup
at this stage is unlikely to make any waves in the actual marketplace,
IMHO.
I tend to prefer the "get it right" approach when it comes to these
ever-important status bit settings. If the good ones are in the
most recent draft of the spec, then vendors are likely to implement
it accordingly (right???), whether or not the spec is "finalized"
on the standards track.
Harry, I know I'm not alone in being thankful for your tenacious
position on these dratted HR MIB status bit definitions. Thanks
for keeping us on course. ;-)
...jay
harryl@us.ibm.com wrote:
>
> This is all stuff people were interested in 3 years ago. Freezing the
> Printer and HR mibs for 2 or 3 years then hitting them with a blow torch
> or the crawl to the finish that was so slow that motion was hardly
> perceptible (which ever way you want to view it)... has led to
> disinterest, I fear. I think the recommendations still make sense to "get
> it right"... but then, we've lived with it Soooooo long that I don't know
> if it will really make any difference.
>
> Do whatever seems appropriate. I'll edit per your recommendation or the
> consensus if anyone is still awake.
>
> Harry Lewis
> IBM Printing Systems
>
> Ron Bergman <rbergma@hitachi-hkis.com>
> 11/17/99 09:47 AM
>
> To: Harry Lewis/Boulder/IBM@IBMUS
> cc: rbergma@dpc.com, Jeff.Rackowitz@intermec.com,
> jkm@underscore.com,
> pmp@pwg.org, don@lexmark.com
> Subject: PMP> Re: Long-standing HR MIB recommendations from
> Printer MIB
>
> Harry,
>
> I fully agree! The HR MIB linking has certainly been the cause of much
> frustration. The question is, do we delay the HR MIB update and
> consequently the Printer MIB update to add these three new enums to
> the HR MIB. Steve Waldbusser believes that it is very close. If this
> proves to be wrong and the document goes to last call, we should then
> push to add these enums.
>
> I believe that we can, if there are no objections in the PWG, add these
> enums to the Printer MIB. IETF documents all the time build on other
> RFCs, so why should this be an exception. If we were considering the
> addition of a new object, it would be a different. But enums allow
> extensibility and can be added without changes to an RFC. The Printer
> MIB is the ideal place to document them.
>
> My objection to the paragraph mentioned is this is equivalent to a "it
> would be nice if only..." statement. It would be better just to state
> that
> we are extending the HR MIB with these new enum and this is how they
> are used. A minor change to your existing pargraph should be sufficient.
>
> Any comments or objections?
>
> Ron Bergman
> Hitachi Koki Imaging Solutions
>
> harryl@us.ibm.com wrote:
>
> > Regarding the paragraph which I have been asked to remove from the
> Printer
> > MIB...
> >
> > "Although the above mapping is workable, it would be improved with
> > a few additions to hrDeviceStatus and hrPrinterStatus in the Host
> > Resources MIB. In particular, it would be appropriate to add a
> > "standby" enumeration to hrDeviceStatus. Similarly, it would be
> > useful to add the following states to hrPrinterStatus: "offline"
> > to indicate that reason for the printer being down (instead of
> > having to use "other") which allows both "warning" and "offline"
> > to indicate going offline and "down" and "offline" to indicate
> > offline and "notApplicable" to cover cases, such as "standby",
> > where the device state completely describes the state of the
> > device. The suggestions and additions discussed above would
> > require re-convening of the Host Resources MIB working group and
> > a new draft issued prior to actual implementation of these
> > suggestions and/or additions."
> >
> > Standby is listed as an "interesting state" (Printer MIB 2.2.13.2 -
> Overall
> > Printer Status). Yet, to describe it we specify DEVICE STATUS (Running)
> > with PRINTER STATUS (Other). That's not a very explicit way to call
> > attention to an interesting state. Thus, my suggestion to add a simple
> > enumeration - DEVICE STATUS (Standby).
> >
> > The 2nd suggestion to add PRINTER STATUS (Offline) stemmed largely from
> an
> > error in the original MIB that "pegged" hrPrinterDetectedErrorState
> > (Offline) with a mandatory DEVICE STATUS (Down). So, it was
> fundamentally
> > impossible to achieve an "offline warning". The alleviation of mandatory
> > associations between hrPrinterDetectedErrorState and hrDeviceStatus is
> > probably enough to correct this problem (although I was never able to
> get
> > the point across very well that we should have just eliminated the whole
> > association definition altogether rather than specify it the way we did
> > which is to say, in every case, it's OK to associate either DOWN or
> > WARNING. Trouble is... if I'm ever successful in adding STANDBY, we
> can't
> > "officially" associate it very well with any of the "bits".
> >
> > Harry Lewis
> > IBM Printing Systems