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.