> 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.
Agreed, we shouldn't have to worry about this.
> 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.)
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.)
> a. It would seem inappropriate to repeat a binary alert while the
> 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.
> 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.
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.)
> 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 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.)
>
> 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 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
----------------------------------------------------------------------
-- JK Martin | Email: jkm@underscore.com --
-- Underscore, Inc. | Voice: (603) 889-7000 --
-- 41C Sagamore Park Road | Fax: (603) 889-2699 --
-- Hudson, NH 03015-4915 | Web: http://www.underscore.com --
----------------------------------------------------------------------