I wonder if we couldn't convince Steve to simply add one enum to
hrDeivceStatus (Standby). I think his main objection was the proposal to
also add "Offline" to the hrPrinterStatus since there is already an
offline bit in hrPrinterDetected... I know time and position in the
process is another major concern. But it's just an enum!
IBM Printing Systems
Ron Bergman <email@example.com>
11/18/99 09:21 AM
To: Harry Lewis/Boulder/IBM@IBMUS
cc: firstname.lastname@example.org, Ron Bergman <email@example.com>,
Jeff.Rackowitz@intermec.com, firstname.lastname@example.org, email@example.com,
Subject: Re: PMP> Re: Long-standing HR MIB recommendations
from Printer MIB
One point of clarification, the latest HR MIB draft...
...has removed the association with hrDeviceStatus. So the only issue of
contention is the new enum for hrDeviceStatus (standby) and two new
enums for hrPrinterStatus (offline and notApplicable).
I totally agree that adding these enums should not be a major change.
However, Steve Waldbusser did not agree and stated that these new
enums would cause a major reset of the HR MIB. We should accept
Steve's position and, if we all agree that these enums are essential to
include, work on adding them without changing the HR MIB.
Hitachi Koki Imaging Solutions
> Thanks to Ron, Jay and Bill for your responses to the issue. First, let
> clarify, for Jay, that the new hrPrinterDetectedErrorState bits DID make
> it into the updated HR MIB which is going for the final holy blessing.
> "paragraph" in question, which Jeff Rackowitz so kindly pointed out,
> related to new hrDevice and hrPrinter states that we determined would
> the MIB more useful (as I recall) following the StarDust bakeoff (anyone
> recall how many candles should be on the cake for THAT anniversary?!).
> key recommendation was to add STANDBY to the list of possible hrDevice
> states because, if you look at our mocked up decoder table, standby is
> less than distinguished, currently, yet we call it out as an
> I may tend to want to flog myself for allowing the HR MIB to reach this
> point without having "pushed" this issue, but then I'm tempered by my
> recollection of the way we "tip-toed" around the whole issue ('we're
> trying to progress here... so we can't afford to make very many
> it might rock the boat). Never mind the boat had it's bow stuck in the
> side of Antarctica.
> So, I agree with Jay regarding the "hrBits"... and I'm glad they made it
> in (although they still have this redundant right hand column that
> associated each bit with either Warning or Down hrDevice status which I
> initially proposed but followed up with the request to just ELIMINATE
> implied mandatory relationship (this way, if we DID add hrDevice =
> Standby, hrBits and Standby would be allowed.
> Bill expresses the sentiment that a change at this point may not receive
> much response anyway. To the extent that I believe the new
> hrPrinterDetectedErrorState bits are more useful additions than hrDevice
> Standby, I tend to agree.
> Ron points out that we may be able to "patch" the situation in the
> MIB and I'm willing to consider this.
> If you look at it galactically, adding an enum to the HR MIB should be
> like swatting a fly... but it does seem to feel more like trying to land
> on Pluto.
> Thanks, again, for all your support.
> Harry Lewis
> IBM Printing Systems