>I agree that there is a problem, but I don't think it is in the relationship
>between the Alert Table and the HR Mib. It is in the HR Mib itself! The HR
>Mib says that when hrPrinterDetectedErrorState is Low Toner then
>hrDeviceStatus should be Warning. A printer implementation which conflicts
>with this HR Mib edict must find a way to resolve that conflict regardless of
>the Alert Table.It is unthinkable for the AlertTable entry to lie about the
>printer state to match values in the HR Mib.
I can't believe the PRINTER WORKING GROUP PRINTER MIB PROJECT is going
through such contortion on this topic just because the hrMIB does not
recognize the very real situation of toner low criticals! I think
Stuart's recommendation is the best way to address this problem short of
grabbing the hrMIB by the horns (I thought Chris was going to help us
look at changing the hrMIB ala my proposed prtDetectedErrorState bits?).
>To me it seems clear that if I had a printer implementation that went down in a
>low toner condition, I would,
>1) report the situation accurately in the Alert Table,
>2) set hrDeviceStatus to Down, and
>3) set hrPrinterDetectedErrorState to Unknown.
>This gives my printer implementation the best chance of being reported
>accurately with both simple and sophisticated monitoring applications. Note
>that the simple monitoring application error report is not complete, i.e. some
>unknown error, but at least it is accurate, i.e. the printer is down. This is
>vastly superior to reporting that the printer has low toner and is not down,
>which is more informative but is incorrect.
Harry Lewis - IBM Printing Systems
---------------------- Forwarded by Harry Lewis/Boulder/IBM on 05/05/97 11:41 AM
---------------------------
pmp-owner@pwg.org
05/02/97 03:00 PM
To: jkm@underscore.com@internet
cc: PMP@pwg.org@internet
Subject: Re[2]: PMP> Top 25 minus 4 conditions/alerts proposal
Jay,
snip...
>I maintain that we have now come to the crossroads where we must
>decide whether to retain a conforming relationship with the HR status
>values, or do the RIGHT THING and say what must be said in the Alert
>Table.
>The primary scenario driving this decision:
>If "toner low" stops the printer, then a CRITICAL "toner low"
>alert is added to the Alert Table; however, following the HR
>rules, a "toner low" WARNING is indicated in the HR variable
>prtPrinterDetectedErrorState.
>Does everyone agree we have a problem here?
snip...
So how can the conflict in the HR Mib be resolved? Simple monitoring
applications which look at the HR Mib variables use a traffic light metaphor.
Thus, hrDeviceStatus is MUCH MORE IMPORTANT than hrPrinterDetectedErrorState.
I believe that any condition can be reported adequately for both simple and
sophisticated applications using this priority scheme.
Does this view conflict with the Top 25 table? I don't think so. I view a
Toner Low condition which is Critical as a condition which is not defined by our
Top 25 table.
Stuart Rowley
Kyocera Electronics