> 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.
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.
> 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.
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.
> 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.)
Right, but we should be able to agree on some subset.
> a. It would seem inappropriate to repeat a binary alert while the
> previous alert is still active and in the table.
Agree, and maybe this should be explicitly stated.
> 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.
I invite discussion on this.
> 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.
I would agree.
> 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.
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.
> Bill Wagner, DPI
>
> ______________________________ Reply Separator _________________________________
> Subject: RE: PMP> Should Alerts be replicated???
> Author: Chris Wellens <chrisw@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.
>
>