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