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 <chrisw at iwl.com> 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.