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...
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.
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.
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.
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