Subject: PMP> Alert table thoughts

From: Lloyd Young <[email-masked]>
Date: 1 Apr 97 11:32:00 EST

For some reason Matt is not able to post mail to the PMP
distribution list so I am posting this one on his behalf:

----------

Hi folks,

I was working on a long overdue clarification of unary ond binary alert
management and started coming up some questions that I wanted to bounce
off the group.

1) I was looking at the new definition of PrtAlertCodeTC, and noticed
some seemingly minor changes that it seems to me make significant
changes in printer implementation.

Examples:

Value   RFC1759                 internet-draft
------- ----------------------- -------------------
3       coverOpen               coverOpened

When it was coverOpen(3) (Open, adj. describing state of cover), it made
sense to put one alert in the alert table when it opened and remove it
when it closed.  I never did understand why there was a coverClosed(4).

With coverOpened(3) (Opened, verb describing the leading edge action) it
is implied that it will be followed by a coverClosed(4).

If this is the case is coverOpen(ed) a binary alert and coverClosed a
unary one?  Is this waht we want?

2) In the internet-draft, the section that talks about the alert table
has a paragraph that talks about unary alerts (included for reference). 
The paragraph gives an example of a unary alert then goes on to talk
about not knowing when to remove unary alerts from the table.  The
clarification I am adding talks about multiple unary alerts of the same
type on the same subunit replacing each other.  This makes the example
not demonstrate waht it was intended to do.  What do you guys think?

Quote talking about unary alerts from internet-draft section 2.2.13.4.

   Unfortunately, there are some events that are not binary
   changes. This other category of event, the unary change 
   event, is illustrated by the configuration change event. 
   With this kind of event the state of the machine has changed, 
   but to a state which is (often) just as valid as the state 
   that was left and from which no return is necessary.  For 
   example, an operator may change the paper that is in the 
   primary input source from letter to legal. At some time 
   in the future the paper may be changed back to letter, but 
   it might be changed to executive instead.  This is where 
   the problem occurs. It is not obvious how long to keep simple 
   change event entries in the Alert Table. If they were never 
   removed, the Alert Table would continue to grow indefinitely.

3) The title of section 2.2.13.3 is "Alert Tables".  The title of
section 2.2.13.4 is "Alert Table Management".  Both sections talk about
a single table.  Any idea why the plurality?

4) The term "unary" and "simple" seem to be used interchangibly without
relating the two.  Should we change all to "unary"?

--Matt

-- 
Matt King                                     Opinions are my own and
Staff Engineer                                    are not necessarily
Lexmark International, Inc.                          those of Lexmark
[email-masked]

---

From: JK Martin <[email-masked]>
Date: Wed, 2 Apr 1997 18:01:20 -0500 (EST)

Matt,

Excellent proposal for the new text!  No redundant unary alerts would
be very helpful for us (as software developers), not to mention printer
vendors.

You ask:

> The question then is, once you apply the new rule, what is a good
> example of what would fill up the alert table?

I am *so* glad you asked...

Here's a serious example worth considering, using the fictitious printer
model "Charmin" (as in, well, you know) made by Cheapoid Printers Corp:

  1. Printer is powered on:  "powerUp (503)" alert inserted as the first
     entry in the Alert Table.

  2. Printer starts processing a print job, drawing paper from tray #1,
     however, that tray is empty:  "inputMediaSupplyEmpty (808)" alert
     added to the Alert Table.

  3. User comes along and pulls out tray #1 to fill it with paper:
     "inputMediaTrayMissing (801)" alert must be added to the Alert Table,
     but...

		THE ALERT TABLE IS FULL !!!

Now, some of you might be thinking, "Come on, Jay, don't be silly!
No printer is going to have an Alert Table capable of only 2 entries!"

Wanna bet?

Before explaining this situation, let me say that I have provided Matt
with a plausible example of how an Alert Table can get filled up.  Now
for the explanation...

One of the hot-n-heavy discussions during the last day of interop
testing in San Jose last December was the heated debate over whether
the Printer MIB should MANDATE that an implementation MUST support an
Alert Table size capable of storing the entire set of critical alerts
that could be *simultaneously* active at any given time in the
printer.  (Sorry that was one sentence.)

During that debate, I argued that the Alert Table should *always*
provide a complete picture of all known problems currently existing in
the printer.  By "problem" I mean "critical alert".

Those against such a mandate argued that too many resources would be
required for very low end printer models.  Gail Songer then provided an
execellent analysis showing how few resources would actually be
required to implement this mandate.  Opponents, however, weren't
convinced.

My position (as stated on this mailing list) was to the effect that if
the Alert Table was not mandated as maintaining the complete set of
existing critical alerts, then the Alert Table was useless and should
be removed.

After all, if our management application software can not trust the
Alert Table to state the complete problem set, WE CAN'T USE IT;
instead, we would merely poll each and every subcomponent's subunit
status object and derive the equivalent set of alerts.

RFC 1759 states:

  "Agent implementors are encouraged to provide at least enough storage
   space for the maximum number of critical alerts that could occur
   simultaneously."

I would like to propose that the phrase "Agent implementors are encouraged
to" be changed to "An agent implementation must" in the above sentence.

What say ye?  Shouldn't the Printer MIB mandate that an implementation
must be able to store all existing critical alerts in its Alert Table?
If not, then what good is the Alert Table?

	...jay

---

From: Harry Lewis <[email-masked]>
Date: Thu, 3 Apr 1997 08:51:20 -0500

Classification:
Prologue:
Epilogue: Harry Lewis - IBM Printing Systems

In this example...

>  THE ALERT TABLE IS FULL !!!

...why doesn't 808 get "managed out" by 801? If the tray is put back in
"full" the final state of the alert table will just be "powerUp". If
the tray is put back in empty, then 801 would get managed out by 808.

I'm not arguing for a 2 entry alert table - I'm just not sure I
believe the alert table needs to be a guaranteed size in order to
be useful.

Harry Lewis.

---

From: JK Martin <[email-masked]>
Date: Thu, 3 Apr 1997 10:49:30 -0500 (EST)

Harry,

> the tray is put back in empty, then 801 would get managed out by 808.

Hey, good point.  If the tray gets pulled, then the printer can't
honestly say the tray is empty.  So, let's come up with a slightly
different (but more accurate) example.

Since you're not biting on the mandatory Alert Table size issue,  ;-)
then let's consider a more accurate situation...however, it still
revolves around a severely limited Alert Table size:

  2. Printer starts processing a print job, but a jam occurs during
     printing:  "jam (8)" alert added to the Alert Table.

  3. User comes along and opens one of the covers to clear the jam:
     "coverOpen (3)" alert must be added to the Alert Table, but...

		THE ALERT TABLE IS FULL, etc...

That is, opening the cover does not automatically negate the jam
condition.

> believe the alert table needs to be a guaranteed size in order to

If a mgmt app can't trust the Alert Table to contain all existing
problem descriptions (ie, critical alerts), then how can the Alert
Table be useful?

Given, if the mgmt app polls the printer at a fairly high rate,
then perhaps the mgmt app can believe that it won't miss the insertion
of a new alert.  But I wouldn't bet money on that approach.

Can you shed some light on what kinds of problem areas and scenarios
would find the Alert Table useful?

	...jay

---

From: [email-masked] (Bill Wagner)
Date: Fri, 4 Apr 1997 02:09:26 -0500

Jay,
     
     I suppose I do regret cutting the last day of interop testing.
     
     1. Although I find Matt's proposal well expressed, and  I agree that 
     it may be desirable to a continuously edit the alert table to ensure 
     that it fully expresses the current condition, I do not agree with 
     making the concise editing of the table mandatory. The table 
     management paragraph recognized that there must be some way to empty 
     events or else the table would fill up. It defined a simple protocol 
     (set of rules) to make room. Its intent was not to require that the 
     printer remove unary events the effect of which appears to have been 
     superseded by other unary events. I believe it unreasonable to mandate 
     this.
     
     2. I suggest that Jay is indulging in hyperbole in stating  "if the 
     Alert Table was not mandated as maintaining the complete set of 
     existing critical alerts, then the Alert Table was useless and should 
     be removed." Again, although it would be nice to have a complete 
     profile of the printer condition in the alert table, and higher end 
     units will want to stress the fact that they have such support, I do 
     not believe that it should be mandated. To Jay's objection that it 
     imposes a requirement on the management application to poll the 
     printer and keep a record of alert events that the printer may drop, I 
     suggest that it not be mandated that the management app keep this full 
     record either. If a printer manufacturer decides that a limited depth 
     alert table is appropriate for his product, that implementation is 
     still better than if there were no alert table. 
     
     In case I an unclear, I see insufficient justification for mandating 
     either the editing of alert table events so that only current 
     conditions are reflected, or for mandating that the alert table be 
     large enough to accommodate all possible, 'significant', contemporary 
     alerts.
     
     Bill Wagner, DPI

______________________________ Reply Separator _________________________________
Subject: Re: PMP> Alert table thoughts
Author:  JK Martin <[email-masked]> at Internet
Date:    4/2/97 6:01 PM

Matt,

     

     

     

Wanna bet?

     

     
     
RFC 1759 states:

     
     
        ...jay

---

From: JK Martin <[email-masked]>
Date: Fri, 4 Apr 1997 10:24:59 -0500 (EST)

Bill,

First, I have no real complaints about what you refer to as "editing"
of the Alert Table with respect to unary alerts.

I previously asked Harry Lewis:

	If a mgmt app can't trust the Alert Table to contain all
	existing problem descriptions (ie, critical alerts), then how
	can the Alert Table be useful?

	Given, if the mgmt app polls the printer at a fairly high rate,
	then perhaps the mgmt app can believe that it won't miss the
	insertion of a new alert.  But I wouldn't bet money on that
	approach.

	Can you shed some light on what kinds of problem areas and
	scenarios would find the Alert Table useful?

I would now like to ask you the same questions.  What problem scenarios
can you suggest that would make good use of an Alert Table that does
not necessarily contain all existing critical alerts?

I'll say in advance that if the answer is something like "well, it can
be used as a 'hint' to a mgmt app...", then I'd have to point out that
we already have other objects to provide such hints, such as the counters
indicating changes to the Alert Table (which, if the Alert Table were
to be removed, would be changed to simply reflect the number of critical
alerts encountered, rather than reflecting changes to the Alert Table).

Bill, please give us your ideas about how the Alert Table can be used
given the current design.  We'd really appreciate it.

By the way, have you had any experience in coding a mgmt app to deal
with the Alert Table?  Has anyone else in PWG land experienced this
effort?

If the Alert Table were not so critical for our printer mgmt app, I'd
simply smile when you call my comments "hyperbole".  However, when we
ask our customers whether it would be OK for us to miss a critical
alert or two, they inevitably remark "Then what good is your
software?"  This does not make me smile.  Your comments below make it
sound as if it's ok for the mgmt app to miss critical alerts.

Does anyone else out there share Bill's view, that it's ok for a mgmt
app to miss critical alerts?  It could be that the answer to this
question will ultimately drive the resolution of this entire issue.

Comments from one and all are definitely appreciated.  I would really
like to see some comments from the Lexmark and Tektronix folks, in
particular.

	...jay

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

>From [email-masked] Fri Apr  4 03:32 EST 1997
Date: Fri, 4 Apr 1997 02:09:26 -0500
From: [email-masked] (Bill Wagner)
Subject: Re[2]: PMP> Alert table thoughts
Cc: [email-masked]
Content-Transfer-Encoding: 7bit

     Jay,

     

     Bill Wagner, DPI

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

---

From: [email-masked] (Bill Wagner)
Date: Fri, 4 Apr 1997 20:03:58 -0500

Jay,
     
     First, let me stress that my position stems from a firm belief that 
     the function of these commercial standards is to allow 
     interoperability among commercial products and not to guarantee a 
     particular level of functionality. I do not regard these documents as 
     MIL SPECS. I grant that this belief might be neither common or 
     current. But I regard it preferable to have wider and more complete 
     compliance to a less demanding standard than limited and questionable 
     compliance to a more rigid one. Although I grant that some useful 
     level of functionality should be provided, I suggest that market 
     pressures should dictate the degree of functionality.
     
     Speaking from this position, your question:

     is a reasonable one (although 'trust' seems a bit dramatic). I would 
     respond that even the reporting of the single most critical or even 
     the latest critical alert condition is useful and is preferable to 
     having no alert. That having the five or ten or 20 critical alert 
     conditions listed is probably increasingly better (although at a 
     decreasing rate). And a unit that guarantees that every possible 
     concurrent problem is described in the alert table is perhaps the best 
     but certainly not the only acceptable implementation.
     
     I understand your desire to have a management application that tells 
     the user absolutely everything about the printer. But I suggest that 
     there is a place for less extensive management capabilities.
     
     You then ask: "What problem scenarios can you suggest that would make 
     good use of an Alert Table that does not necessarily contain all 
     existing critical alerts?"  Report of a paper jam is useful 
     information, even though the fact that tray 2 is out of paper may be 
     lost. Report of an internal problem is useful in calling attention of 
     a repair person to a problem in the fuser (for example) even though 
     someone might have to look at the printer to ascertain exactly what is 
     wrong. Yes, it might mean that the supervisor has to make two trips to 
     a printer to bring it up again rather than collecting all necessary 
     tools and replacement parts for the first trip, using the complete 
     report provided from the alert table.
     
     And yes, I suppose someone could write a management application that, 
     on sensing a critical alert, could look at some more of the MIB to 
     provide more extensive information about the problem even if it is not 
     in the alert table. 

     As you point out "...we already have other objects to provide such 
     hints, such as the counters indicating changes to the Alert Table"
     However, a simple application might find it easier to have a concise 
     description of the conditions, even though it may be limited to two or 
     five or whatever concurrent conditions.  Note that I said nothing 
     about not allowing a full implementation of the alert table. It is the 
     position of all or nothing with which I do not agree. 
     
     Yes, I have worked on several printers that provided (though a 
     utility) a single statement of the current condition of the printer; 
     although this statement was not derived from the alert table, the 
     implementation is very much like a single entry alert table.

     You portrayal that my view is "that it's ok for a mgmt app to miss 
     critical alerts" is something of a misstatement.  But I do maintain 
     that having a summary description of the  several most critical alert 
     conditions is useful, even if all conceivable concurrent conditions 
     are not listed. And I think that using the alert table to get a 
     concise statement with respect to the most critical problem in a 
     printer is useful, especially since the existing status objects 
     provide little detailed information.
     
     With respect to "Lexmark and Tektronix folks", they have every right 
     to demand only the best and most complete implementation for their 
     products. I am not sure that they should have the right ...or that 
     they would exercise the  right.. of requiring all printers must have 
     the same degree of implementation to be compliant.

     Bill Wagner, DPI