Haven't we beat this topic to death?
The PMP group just spent a significant amount of effort to come up with a Top 25
chart that lists the expected values for the hr variables, the AlertTable, and
SubUnitStatus for all of the most common printer conditions. I think we are now
spending too much time on the 20 side of the 80/20 rule.
We will always be able to find some condition that is not adequately defined by
the hr variables (or where the bindings are conflicting), but does that mean
they are useless? I don't think so. The Alert Table supplies complete
information for the "soup to nuts" management applications, while the hr
variables can be useful for simple "traffic light" type monitoring applications.
We have been fretting over the hr variable bindings in the case of a low toner
which is critical. What about a toner out which is a warning? (In a printer
that has multiple toner hoppers for example), or a printer that is jammed but
not down? (has an alternate paper path) Do these exceptions make the hr
variables useless as they stand? No! We had our chance to drop the hr
variables as a means for describing printer status, but we didn't do it - we
came up with a Top 25 chart instead!
Changing the hr MIB itself seems a whole different discussion (which Harry has
brought up in regards to hrPrinterDetectedErrorState).
I suggest that we simply put a section in the FAQs that directs an implementer
to follow the recommendations in the Top 25 chart for the common printer
conditions. For other conditions which are not covered by the chart,
1) Describe the printer condition as accurately as possible in the
prtAlertTable,
2) Describe the printer sub unit status as accurately as possible using
PrtSubUnitStatusTC,
2) Describe the overall printer state as accurately as possible with
hrDeviceStatus and hrPrinterStatus.
3) Describe the printer condition with hrPrinterDetectedErrorState. In the case
where the condition conflicts with the bindings between
hrPrinterDetectedErrorState and hrDeviceStatus, break the bindings and describe
the condition correctly. For example, in the case of a low toner condition
which causes a printer to stop printing, the hr MIB INCORRECTLY MANDATES that a
low toner condition must correlate with an hrDeviceStatus of (3)warning. In
this example case, the binding between hrPrinterDetectedErrorState and
hrDeviceStatus should be disregarded; hrPrinterDetectedErrorState should be
lowtoner(bit 2) and hrDeviceStatus should be (5)down.
Let's turn out the lights on this one!
Stuart Rowley
Kyocera Electronics
______________________________ Reply Separator _________________________________
Subject: Re: PMP> Top 25 minus 4 conditions/alerts proposal
Author: INTERNET:jkm at underscore.com at CSERVE
Date: 5/8/97 3:12 PM
Sender: pmp-owner at pwg.org
Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by
arl-img-8.compuserve.com (8.6.10/5.950515)
id OAA03462; Thu, 8 May 1997 14:44:53 -0400
Received: from localhost (daemon at localhost) by lists.underscore.com
(8.7.5/8.7.3) with SMTP id OAA16645; Thu, 8 May 1997 14:44:17 -0400 (EDT)
Received: by pwg.org (bulk_mailer v1.5); Thu, 8 May 1997 14:44:03 -0400
Received: (from daemon at localhost) by lists.underscore.com (8.7.5/8.7.3) id
OAA16607 for pmp-outgoing; Thu, 8 May 1997 14:43:34 -0400 (EDT)
Date: Thu, 8 May 1997 14:43:47 -0400 (EDT)
From: JK Martin <jkm at underscore.com>
Message-Id: <199705081843.OAA06392 at uscore.underscore.com>
To: Gail.Songer at eng.efi.com
Subject: Re: PMP> Top 25 minus 4 conditions/alerts proposal
Cc: pmp at pwg.org
X-Sun-Charset: US-ASCII
Sender: pmp-owner at pwg.org
Ah, now I recall the situation. Yes, you're right.
According to the rules defined in the HR MIB, there is a strong binding
between the value set in hrPrinterDetectedErrorState and the value of
hrDeviceStatus.
This is really unfortunate. And yes, this is precisely the scenario
which the PMP must decide whether to diverge from the Host Resources
MIB.
Lloyd: We need to get this discussion rolling asap, and try to reach
consensus in San Diego. Is this acceptable to you?
Here's a premise for all of us in the PMP to jump on in this list:
These statements exclude from consideration any existing Printer MIB
implementations:
There are few, if any, Host Resources MIB implementations that
actually use the hrPrinterStatus and hrPrinterDetectedErrorState
variables. In fact, there are few, if any, HR MIB implementations
that implement "Printer" devices at all.
As a result, the Printer MIB should redefine the rules surrounding
the bindings between the HR MIB variables hrDeviceStatus, hrPrinterStatus
and hrPrinterDetectedErrorState in such a way as to allow for more
accurate presentation of printer status information.
Let's get a quick discussion rolling on the Pro's and Con's of these
statements. Feel free to add other statements, as necessary.
While this may seem like an extreme action on the part of the PWG,
it should be viewed as *far* less extreme than severing ties with
the HR MIB altogether. (Something I hope we don't do.)
...jay
----- Begin Included Message -----
From: "Gail Songer" <Gail.Songer at eng.efi.com>
Date: Thu, 8 May 1997 11:25:55 -0700
To: JK Martin <jkm at underscore.com>
Subject: Re: PMP> Top 25 minus 4 conditions/alerts proposal
Cc: pmp at pwg.org
Jay,
On May 8, 1:49pm, JK Martin wrote:
> Subject: Re: PMP> Top 25 minus 4 conditions/alerts proposal
> Gail,
>> I certainly suggested that if the HR MIB model for printers ends up
> conflicting with what we believe is the *right* model for handling
> certain conditions, then yes, we should consider "deprecating" our
> association with the HR MIB status variables.
>> However, if you agree that the values I proposed for the HR MIB variables
> (below) are correct, then for the "critical toner low" condition, there
> is no conflict. Again, assuming the values I proposed are correct.
I am a bit confused here. The definition that you have proposed:
> >
> > hrDeviceStatus down(5)
> > hrPrinterStatus other(1)
> > hrPrinterDetectedErrorState lowToner(1)
> >
is in conflict the host resources mib. "lowToner" forces hrDeviceStatus to
"warning" not "down". One way to avoid conflict is to add "offline" to
hrPrinterDetectedErrorState since "offline" requires "down" in hrDeviceStatus.
This, unfortunatly, brings us back to the alert table. I suppose that having
a toner low critical, that would change to a warning when the printer
continues
would work and still keep everything consistent.
>> Someone had previously illustrated a scenario in which the Alert Table
> entry would be in conflict with the previously published set of related
> HR MIB values. What was that scenario?
>> ...jay
>
----- End Included Message -----