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

From: Lloyd Young <[email-masked]>
Date: 7 May 97 10:00:11 EDT

I want to bring this discussion thread to some conclusion. After
reviewing the discussion, the conclusion that I arrive at is that
no changes to the Printer MIB are required. I think it would be 
beneficial if some of this discussion was placed in Gail's FAQ 
document. For example, a statement from Harry's last e-mail on 
this topic might be helpful:
   Alerts that stop the printer are denoted as critical and alerts 
   that don't as warnings.

There has been alot of discussion on this item so it is entirely
possible that I have overlooked something. Therefore please
speak up if I am entirely off base on my conclusion.
Regards,
Lloyd 

Lloyd Young                       Lexmark International, Inc.
Senior Program Manager            Dept. C14L/Bldg. 035-3
Strategic Alliances               740 New Circle Road NW
internet: [email-masked]     Lexington, KY 40550
Phone: (606) 232-5150             Fax: (606) 232-6740

---

From: JK Martin <[email-masked]>
Date: Wed, 7 May 1997 13:54:56 -0400 (EDT)

Lloyd,

When you say (below) that "no changes to the Printer MIB are required",
we can assume you mean the actual MIB definition and not the draft text
surrounding that definition, right?

I agree that the *MIB* should not change, but certainly the text of the
I-D (that becomes the RFC) should be modified to include a simple, yet
concise statement about critical alerts (paraphrasing your proposed
text):

    Any condition for which the printer stops operation should result
    in the addition of an alert in the Alert Table; such an alert must
    have its prtAlertSeverityLevel variable assigned with the value
    critical(3).

I would suggest that this text should go into the I-D/RFC text at the
very least.  If we also want to put it in Gail's FAQ, then great.

	...jay

----- Begin Included Message -----

>From [email-masked] Wed May  7 10:30 EDT 1997
To: "pmp%pwg.org" <[email-masked]>
From: Lloyd Young <[email-masked]>
Date:  7 May 97 10:00:11 EDT
Subject: PMP> Top 25 minus 4 conditions/alerts proposal

----- End Included Message -----

---

From: JK Martin <[email-masked]>
Date: 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 [email-masked] Thu May  8 14:26 EDT 1997
From: "Gail Songer" <[email-masked]>
Date: Thu, 8 May 1997 11:25:55 -0700
To: JK Martin <[email-masked]>
Subject: Re: PMP> Top 25 minus 4 conditions/alerts proposal
Cc: [email-masked]

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

---

From: [email-masked] (Bill Wagner)
Date: Thu, 8 May 1997 15:50:26 -0400

I offer an opinion as an outside observer. As Gail suggests, the HRMIB 
     hrPrinterDetectedErrorState is a bit map that allows the two 
     conditions, toner low and off-line to be flagged. Off-line is the 
     condition that prompts the  hrDeviceStatus = down. When the user puts 
     the device on-line, low toner remains, but device status is no longer 
     down.
     
     This reflects what is happening very well. I don't see why we want to 
     monkey with it. 
     
     My own feeling is that, in the case where a toner low prompts an off 
     line, the Alert table should have two alerts; one for low toner and 
     another for off-line. The idea of a condition that changes from 
     critical to warning is aesthetically displeasing. I guess you could 
     have two sequential events..toner low unacknowledged, which was 
     critical and toner low acknowledged which was a warning (and which 
     terminated the former). But I think we are making things more 
     complicated than necessary.
     
     Bill Wagner, Osicom/DPI

______________________________ Reply Separator _________________________________
Subject: Re: PMP> Top 25 minus 4 conditions/alerts proposal
Author:  "Gail Songer" <[email-masked]> at Internet
Date:    5/8/97 11:25 AM

Jay,

---

From: JK Martin <[email-masked]>
Date: Thu, 8 May 1997 19:19:23 -0400 (EDT)

Bill,

>      complicated than necessary.

Perhaps you missed the recent (and intense) thread about this topic.

The consensus (not unanimous, but a majority opinion) is to maintain
this position:

  If a condition results in a critical alert, then the alert entry should
  describe the exact nature of the condition.  Furthermore, two or more
  alerts should not be added to the Alert Table for the same, singular
  condition.

That is to say, if a printer goes offline due to a low toner condition,
then only a single alert should be added to the table; this single alert
should be tagged as "critical" and have an alert code corresponding to
"low toner".  The HR MIB variables should be:

  prtDeviceStatus              = down(5)
  prtPrinterStatus             = other(1)
  prtPrinterDetectedErrorState = lowToner(2) and offline(5)

The fact that the printer goes offline is a side effect of the low toner
condition.

	...jay

---

From: [email-masked] (Bill Wagner)
Date: Fri, 9 May 1997 09:51:41 -0400

Jay, 
     
     I have been following the thread. I did not offer an opinion until it 
     appeared to work its way to the point of ...questionable rationality.
     
     I agree to the general statement

 " If a condition results in a critical alert, then the alert entry should
  describe the exact nature of the condition.  Furthermore, two or more
  alerts should not be added to the Alert Table for the same, singular
  condition."

     An example might be removing a paper tray  should not cause all the 
     alerts associated with media.  But if a manufacturer/user has chosen 
     to have a low toner condition precipitate an off line condition, these 
     are still two separate conditions, which may be independently cleared. 
     One could remove the low toner condition without the off line and 
     vice-versa.  To treat them as one condition seems unreasonable, and 
     produces oddities like the alert that changes from a critical to a 
     warning level.
     
     Again, just my opinion, but I think we have followed a line of 
     reasoning without paying much attention to whether it makes sense. 
     
     Bill Wagner
     
     Osicom/DPI

---

From: [email-masked]
Date: 09 May 97 11:43:13 EDT

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:[email-masked] at CSERVE
Date:    5/8/97 3:12 PM

Sender: [email-masked]
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@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@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 <[email-masked]>
Message-Id: <[email-masked]> 
To: [email-masked]
Subject: Re: PMP> Top 25 minus 4 conditions/alerts proposal 
Cc: [email-masked]
X-Sun-Charset: US-ASCII
Sender: [email-masked]

     

     

     

     ...jay
     
----- Begin Included Message -----

Jay,

     
     
a toner low critical, that would change to a warning when the printer 
continues

----- End Included Message -----

---

From: [email-masked] (Bill Wagner)
Date: Fri, 9 May 1997 13:00:45 -0400

______________________________ Reply Separator _________________________________
Subject: Re: Re[4]: PMP> Top 25 minus 4 conditions/alerts proposal
Author:  JK Martin <[email-masked]> at Internet
Date:    5/9/97 12:05 PM

Geez, don't hold back, Bill.  ;-)

WW..  Indeed, I have been. 

>      produces oddities like the alert that changes from a critical to a 

With this statement you've completely disregarded the past statements
about what the user sees and expects.  That's unfortunate.  Others see
it differently than you.

WW.. Not disregarded, but apparently disagreed ...which is why I offered my 
observation. I suggest that the status should refect the status of the machine. 
What the user sees and expects will vary from user to user and perhaps is in the
area of the management application to customize. (;)>
As a user myself, it seems that since I can independently shut off the low toner
and the off line conditions, they are indeed two conditions, not one.

Bill Wagner  Osicom/DPI

---

From: JK Martin <[email-masked]>
Date: Fri, 9 May 1997 14:29:23 -0400 (EDT)

Gail,

> > If a vendor chooses to add two alert entries for the printer-stopping
> > low toner condition, then the offline alert should have its description
> > string clearly state that the reason for going offline is due to the
> > low toner condition, and not simply say "Offline" (as so many do now).
> >
> > Is this a fair compromise?
> 
> If we are going to have multiple "types" of offline, then the other variables
> in the alert table probably should reflect the differences.  At a minimum the
> offline alert should have different prtAlertLocation's based on the "type" of
> offline.  To me a better implementation would have different alert groups and
> alert group indexes as well.

You're absolutely right.  Thanks for pointing this out.  In the (now infamous)
case of a critical low toner condition, the (single) "Offline" alert would
not only have a description saying "Low toner", but also have the alert
group point to the Marker group, etc.

> This could take a lot of space in an imbedded system where space is precious,
> either code space to create the entry and then ram space to store it or extra
> entries in a table. Additionally this could clutter up the alert table with
> multiple offlines and we should definatly try to hold the size of the table
> down.

I agree, and I thought other printer vendors would agree regarding the
embedded space requirements when multiple alerts are posted for a single
condition.  I was hoping this new compromise could be the "best of both
worlds".

> Given that you really want to inform the user of why the printer is not
> printing, I like your previous suggestion better.  One alert describes the true
> state imposed by the alert(one alert that is tonerlow, critical and one that is
> tonerlow wraning). This also seems to be more consistent with other critical
> errors. It is annoying that I have two alerts for basically the same engine
> event, but to me, it is cleaner then the above.

Thanks for your support.

	...jay