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

From: [email-masked]
Date: Wed, 17 Nov 1999 20:22:42 -0700

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 <[email-masked]>
11/17/99 09:47 AM

        To:     Harry Lewis/Boulder/IBM@IBMUS
        cc:     [email-masked], [email-masked],
[email-masked],
[email-masked], [email-masked]
        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

[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: Jay Martin <[email-masked]>
Date: Thu, 18 Nov 1999 09:56:57 -0500

Harry,

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