Subject: Re[2]: PMP> Should Alerts be replicated???

From: [email-masked] (Bill Wagner)
Date: Sat, 1 Feb 1997 14:55:49 -0500

Chris, thanks for your efforts. Strange how perfectly clear 
     descriptions can be interpreted, quite reasonably, to mean something 
     very different.
     
     1. The comment that " If the event is "edge triggered," the 
     description must specify how the event is throttled or turned off so 
     to keep from flooding network managers with event reports." seems 
     counter intuitive, at least for a printer. The specific example was 
     running low on paper. An edge triggered treatment will  reasonable 
     result in many fewer events than a level treatment. One may argue that 
     throttling (or setting the reporting period) is required for level but 
     not for edge.
     
     2. The intimation is that an event causes a trap (hence the concern 
     about flooding network managers). This is not necessarily true, since 
     traps typically result only from critical alerts. 
     
     3. The binary/unary discussion may assume an intimate knowledge of 
     printers; indeed, even among different printers, what event is binary 
     and what is unary is not consistent (which is why this is identified 
     in the alert.)  
        a. It would seem inappropriate to repeat a binary alert while the 
     previous alert is still active and in the table. 
        b. Should manufacturer decide to, he may reinstate a binary alert 
     that was removed because of alert table size restrictions. I cannot 
     see requiring this. And if it is a critical event, I question if a 
     resend of a trap is appropriate. Indeed, I would like to see an 
     examination of the scenario where the re-entry of an overwritten alert 
     is significant.
        c. There is much flexibility in non-critical alerts, which may be 
     unary. Indeed, if a manufacturer wishes to say that low paper means 
     low paper at the time that a specific page was to be printed, it would 
     be a unary event. Effective utilization of the available alert table 
     would discourage  such an interpretation. But it seems inappropriate 
     to dictate to this level in the MIB.
     
     A fair amount of effort went into structuring the Alerts group, and I 
     suggest the results of testing be carefully reviewed before it is 
     changed. 
     
     Bill Wagner, DPI

______________________________ Reply Separator _________________________________
Subject: RE: PMP> Should Alerts be replicated???
Author:  Chris Wellens <[email-masked]> at Internet
Date:    1/31/97 5:37 PM

Over the past six weeks, I have asked a group of SNMP experts for their 
advice on a number of the open issues with respect to RFC 1759.
     
This one started with Jay Martin's example of the "low on toner" 
alert being re-entered every thirty minutes or so.
     
On this question, Dave Perkins referred me to page 35, section 2.6.3 
"Event Triggering" in his book "Understandings MIBs":
     
"There are two models for deciding whan an event has occurred.... 
In the first, an event occurs when a monitored value first
enters a range.  This type of event is called "edge triggered." 
The monitored value must then enter a potentially different 
range before the event may occur again.  (This is called 
rearming the trigger.)"
     
"Alternatively, an event can be defined to occur when a monitored 
value is inside a range at the start of each periodic time 
interval.  This type of event is called "level triggered."  The 
event may "occur" only at each periodic interval.  The 
DESCRIPTION clause must describe the modeling of the event.  If 
the event is "edge triggered," the description must specify how 
the event is throttled or turned off so to keep from flooding 
network managers with event reports." 
     
There's a diagram of this in the book.
     
I went back to RFC 1759 and looked at the description for 
prtAlertIndex (p. 86), and I reread 2.2.13.4 Alert Table 
Management (p. 19).   It seems that the discussion of binary 
change events and simple change events was intended to address
this edge triggered vs. level triggered business, but unfortunately it 
fails.  The reason it fails is that at least one printer
engineer interpreted "low on toner" as being a level triggered 
event, and that's why it is re-entered every 30 minutes.
     
Based on the email discussion, it seemed that the consensus was 
that it should *NOT* be repeated, and only re-entered if it were 
flushed to make room for a critical alert.  
     
I would like a volunteer to draft some language for this that 
would cover all the critical and non-critical alerts.

---

From: JK Martin <[email-masked]>
Date: Sat, 01 Feb 1997 17:06:58 -0500

>      throttling (or setting the reporting period) is required for level but

You know, in reading Chris' quoted text from Dave Perkins' book, I can't
help
but wonder if either Perkins' text is misstated, or Chris' mistyped the
text
from the book.

I mean, the key sentence (to which Bill refers) is:

  "If the event is "edge triggered," the description must specify how
   the event is throttled or turned off so to keep from flooding network
   managers with event reports."

Now, this sentence is in the paragraph explicitly describing "level
triggered" events; the discussion on "edge triggered" events was
described in the preceding paragraph.  Why wouldn't this key sentence
be part of the "edge triggered" paragraph?  Moreover, the warning
about "flooding network managers with even reports" would seem to be
likely with "level triggered" events (which, by definition, can be
generated multiple times for a given condition) than for "edge
triggered"
events (which, by definition, should only be generated once, when the
condition first arises).

I think we have a typo here, don't you?

	...jay

----------------------------------------------------------------------
--  JK Martin               |  Email:   [email-masked]          --
--  Underscore, Inc.        |  Voice:   (603) 889-7000              --
--  41C Sagamore Park Road  |  Fax:     (603) 889-2699              --
--  Hudson, NH 03015-4915   |  Web:     http://www.underscore.com   --
----------------------------------------------------------------------

---

From: JK Martin <[email-masked]>
Date: Sat, 01 Feb 1997 18:01:27 -0500

>      traps typically result only from critical alerts.

Agreed, we shouldn't have to worry about this.

>      and what is unary is not consistent (which is why this is identified

Would everyone in the PMP agree that we MUST all agree on what should be
considered binary vs. unary?  I thought such an agreement was absolutely
essential for interoperability.  If we do indeed have varying
implementations
here, then wouldn't everyone agree that we need to work this out
IMMEDIATELY?
(I sure hope so.)

>      previous alert is still active and in the table.

Amen.  This should be expressly forbidden.

I would also suggest the same policy for warnings.  Of course, this
would
imply that no Printer MIB agents can implement what Dave Perkins refers
to as "level triggered" events...but I maintain this is completely
acceptable.  If anyone disagrees, I would be happy to engage in this
discussion at the interop testing, since too many words would be needed
here to completely discuss it right now.  (See the related comments at
the end of this message.)

>         b. Should manufacturer decide to, he may reinstate a binary alert.

Binary alerts should not be removed from the Table until the related
condition
is no longer present.  (Period.)  An agent should not remove a binary
alert
due to Table space restrictions.  (See summary comments at the end of
this
message.)

>      to dictate to this level in the MIB.

I certainly hope a printer vendor doesn't implement a situation
whereupon,
after a low-paper threshold is reached, a "Low Paper!" warning is placed
in the Alert Table after every so many pages.  Such an alert should only
be
placed in the Table ONCE, and then removed (if paper is added) or
replaced
with "Toner Out!" if that condition arises.

In thinking about it, which conditions within a printer would ever cause
a
vendor to repeatedly insert the same alert in the Alert Table?  (See the
summary comments below.)

>      suggest the results of testing be carefully reviewed before it is

I tend to agree, however...

Summary Comments

What in the world is the Alert Table supposed to be used for, anyway?

I, for one, would like to see this simple, summary statement of purpose
for the Alert Table:

  "The primary purpose of the Alert Table is to provide a complete and
   accurate summary of all alert and warning conditions that currently
   exist within the printer.  By traversing the Alert Table at any given
   time, a management application can quickly and accurately assess the
   the operational state of the printer without having to traverse all
   defined subcomponents of the printer."

A specific agent implementation may also elect to include certain
"informational" events in the Alert Table (pending available table
space),
but such messages should in no way be used to ascertain the operational
state of the printer; such messages exist solely for the convenience of
knowlegeable management applications that have some sort of
"proprietary"
relationship with the printer agent.

Based on some of the comments made recently, it's starting to sound
like some folks are taking the following position:

  "Don't rely on the Alert Table to accurately determine the current
   set of problems that may be present in the printer, since not all
   alert conditions may be represented due to table space constraints.
   You must traverse the entire collection of defined printer components
   defined in the Printer MIB agent implementation to accurately and
   completely determine the current set of problems."

Gawd, I hope this is not true.  If it is, then what the hell good is
the Alert Table?  If it's not accurate and complete, then it should
be removed from the MIB definition altogether, since a management app
would be foolish to ever use it.  (Note that at Underscore, we have
already made such a decision against the HR MIB "magic cookie" values,
since it was neither accurate nor complete for possible problem
conditions, as demonstrated at the first Bake-off in Portland last
July.)

Comments from one and all are desparately needed at this juncture,
since we about to engage in rather massive testing this coming week
in Campbell, CA.  Please post your comments as soon as possible.

	...jay

---

From: JK Martin <[email-masked]>
Date: Sat, 01 Feb 1997 18:12:01 -0500

I apologize for the rather poor formatting of my last few messages.

Seems that Netscape Navigator's email agent believes it has the right
to (transparently, without warning) wrap lines of text as it is sends
the message out.

I'll try to watch out for that situation in the future.  In the
meantime, can anyone recommend a decent Win95-compatible email
agent?

	...jay  (A Unix-oriented person trying to conform... ;-)

---

From: Chris Wellens <[email-masked]>
Date: Sun, 2 Feb 1997 12:00:24 -0800 (PST)

>      throttling (or setting the reporting period) is required for level but 

Exactly right, and I came to the same conclusion.  So
I called Perkins back and said "I think you have a typo 
in your book."  He then gave me several examples of
network devices where an edge triggered event would
flood the network manager.  We just happen to have the
counter examples with "low on paper" and "low on
toner".  My conclusion is that we need strong
DESCRIPTION clauses for both situations.  
 
>      traps typically result only from critical alerts. 

I believe that usinga conservative definition of critical 
alerts, and having these critical send traps would flood 
the network manager.  

I am sorry to say that the definition of what a
critical alert *is* and *is not* is also something
that we have to review.  When InterWorking Labs
did our implementation of RFC 1759, we understood
traps to be sent on critical alerts, and critical
alerts to be "events that caused the printer to stop".
Based on a table early in the RFC, we thought that was
defined as out of paper, out of toner, paper jammed,
and cover open, and that's what we have trap tests on.  
It now appears that some implementors interpreted 
RFC 1759 to include a much larger group of "critical
alerts" and they send traps on all of those.  (Or, for
their printers, there are several more conditions that
cause their printer to stop.)  But, we need to take
this up in a separate thread.

>      and what is unary is not consistent (which is why this is identified 

Right, but we should be able to agree on some subset.

>      previous alert is still active and in the table. 

Agree, and maybe this should be explicitly stated.

>      examination of the scenario where the re-entry of an overwritten alert 

I invite discussion on this.

>      to dictate to this level in the MIB.

I would agree.  

>      suggest the results of testing be carefully reviewed before it is 

I would like to take it on face value that the best
minds in the printer industry went into the definition
of all aspects of RFC 1759.  I don't think anyone is
interested in changing the structure, architecture,
etc.  I have to assume that if we find the 
implementations all over the map, then we need to go
back and figure out what is not clear, and make it
clear.  Rather than change what was originally
intended, we need to clarify what was originally
intended.