Harry,
Since you are wondering if anyone is listening...my two cents,
1. Although there has been some frustration and disappointment, I agree
with Ron that it is inappropriate to put a "it would have been nice" into a
MIB.
2. I believe that companies have done their MIB implementations, perhaps
according to RFC 1759, perhaps to the updated draft, or someplace in
between. I have not seen any great interest in further updating
implementations. At this point, I really don't think it makes a difference
if the HR MIB provides the additional resolution or not. As Ron suggests, it
the industry feels the need, it can be addressed in a different way.
3.Indeed, I wonder if it makes a difference if the revised printer MIB is
ever released, although I believe that there is still some value in the
changes and, if it gets released as an RFC, there may be more support to
implementing it. Although it may seem absurd to repeat this after all the
lost time, but I think we ought to wrap this up as expeditiously as
possible.
Bill Wagner
-----Original Message-----
From: harryl at us.ibm.com [mailto:harryl at us.ibm.com]
Sent: Wednesday, November 17, 1999 10:23 PM
To: Ron Bergman
Cc: rbergma at dpc.com; Jeff.Rackowitz at intermec.com; jkm at underscore.com;
pmp at pwg.org; don at lexmark.com
Subject: Re: PMP> Re: Long-standing HR MIB recommendations from Printer
MIB
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 at hitachi-hkis.com>
11/17/99 09:47 AM
To: Harry Lewis/Boulder/IBM at IBMUS
cc: rbergma at dpc.com, Jeff.Rackowitz at intermec.com,
jkm at underscore.com,
pmp at pwg.org, don at 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 at 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