PMP Mail Archive: Re: PMP> Top 25 minus 4 conditions/alerts proposal

Re: PMP> Top 25 minus 4 conditions/alerts proposal

JK Martin (jkm@underscore.com)
Thu, 8 May 1997 14:43:47 -0400 (EDT)

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@eng.efi.com>
Date: Thu, 8 May 1997 11:25:55 -0700
To: JK Martin <jkm@underscore.com>
Subject: Re: PMP> Top 25 minus 4 conditions/alerts proposal
Cc: pmp@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 -----