Harry,
Do we also want to pursue adding "notApplicable" to hrPrinterStatus?
Requesting to add just "standby" or both is worth a try.
Ron
harryl at us.ibm.com wrote:
> Great! I missed that disassociation but have now confirmed it.
>> 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!
>> Harry Lewis
> IBM Printing Systems
>> Ron Bergman <rbergma at hitachi-hkis.com>
> 11/18/99 09:21 AM
>> To: Harry Lewis/Boulder/IBM at IBMUS> cc: jkm at underscore.com, Ron Bergman <rbergma at dpc.com>,
>Jeff.Rackowitz at intermec.com, pmp at pwg.org, don at lexmark.com,
>bwagner at digprod.com> Subject: Re: PMP> Re: Long-standing HR MIB recommendations
> from Printer MIB
>> Harry,
>> One point of clarification, the latest HR MIB draft...
>>http://search.ietf.org/internet-drafts/draft-ops-hostmib-01.txt>> ...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.
>> Ron Bergman
> Hitachi Koki Imaging Solutions
>>harryl at us.ibm.com wrote:
>> > Thanks to Ron, Jay and Bill for your responses to the issue. First, let
> me
> > clarify, for Jay, that the new hrPrinterDetectedErrorState bits DID make
> > it into the updated HR MIB which is going for the final holy blessing.
> The
> > "paragraph" in question, which Jeff Rackowitz so kindly pointed out,
> > related to new hrDevice and hrPrinter states that we determined would
> make
> > the MIB more useful (as I recall) following the StarDust bakeoff (anyone
> > recall how many candles should be on the cake for THAT anniversary?!).
> The
> > 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
> "interesting"
> > state.
> >
> > 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
> changes...
> > 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
> any
> > 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
> Printer
> > 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