Subject: PMP> Re: Long-standing HR MIB recommendations from Printer MIB

From: Ron Bergman <[email-masked]>
Date: Wed, 17 Nov 1999 08:47:57 -0800

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

[email-masked] 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

---

From: [email-masked]
Date: Thu, 18 Nov 1999 12:12:53 -0500

Must we continue to change the recipe after the cake is in the oven?

**********************************************
* Don Wright                 [email-masked] *
* Director, Strategic & Technical Alliances  *
* Lexmark International                      *
* 740 New Circle Rd                          *
* Lexington, Ky 40550                        *
* 606-232-4808 (phone) 606-232-6740 (fax)    *
**********************************************

---

From: [email-masked]
Date: Thu, 18 Nov 1999 11:00:34 -0700

The cake has been in the oven for over 3 years. No one's asking to change
the recipe (the MIB is entirely in tact and recognizable)... just adding a
cherry on top. It shouldn't (and never should have) required a federal
case to add an enum.

Harry Lewis
IBM Printing Systems

[email-masked]
11/18/99 10:12 AM

        To:     [email-masked]
        cc:
        Subject:        Re: PMP> Re: Long-standing HR MIB recommendations
from Printer MIB