Harry's questions seemed puzzling to me:
> In reading the definition of alertRemovalofBinaryChangeEntry, there doesn't
> seem to be any information about WHICH alert was cleared. Is this intentional?
> Is it obvious that the associated sub-unit should be 18 (Alert Group) and
> sub-unit index should be the index of the alert that was removed?
In reviewing my copy of the draft (version 01) to get back up to speed
on alertRemovalofBinaryChangeEntry, I became even more confused.
Somehow it escaped me that we are now proposing to add yet another alert
to the table...and this this alert is designed to denote that an alert
has been removed!
Can someone quickly state why this is needed (or point me to a relevant
discussion or other posting)? Having such an alert doesn't seem to
gain anything. I fully understand the desire to have a related trap
for this kind of event, but do we really need an "Alert Alert"?
What I *do* recall is that we were going to add two new objects to the
MIB that functioned in a relatively indentical manner--both syntactically
and semantically--as the prtGeneralConfigChanges object. One of the
new objects (prtGeneralAllEvents) would count all changes made to the
alert table, while the other (prtGeneralCriticalEvents) would only
count those changes made for critical alerts.
The philosophy was, as I recall, centered around the idiom whereby a mgmt
app would only have to watch for changes in one of these new objects in
order to know whether the app has to process the alert table.
Did I miss something along the way? Can someone shed some light on this?
Perhaps a comment can be made by someone who is actually developing code
that uses this new objects. I realize my memory must be failing me on
this, but I'd really appreciate some comments from someone on this topic.
I realize the draft claims that this new "alertRemovalOfBinaryChangeEntry"
alert is optional, but still--who is going to use it, and how, and why?
Could it be that the presence of this alert would result in an app not
having to parse the entire alert table in order to fully maintain its
internal working copy?
That seems conceivable, however, since this new alert is OPTIONAL, our
products certainly wouldn't use it. Our customers expect our products
to work with ANY "RFC 1759" printer; the overhead and complexity of
having two algorithms just doesn't pan out, so we always opt for the
algorithm that is bullet-proof and works across the board.
By the way, the draft section "2.2.13.4 Alert Table Management" continues
to interchange the use of "simple" and "unary". (Hadn't we resolved that
problem once and for all already?) In that section, the term "simple" is
used a total of 5 times to denote a "unary" event type. Randy, can you
make these changes, or would you prefer that I send you corrected text?
...jay
----------------------------------------------------------------------
-- JK Martin | Email: jkm at underscore.com --
-- Underscore, Inc. | Voice: (603) 889-7000 --
-- 41C Sagamore Park Road | Fax: (603) 889-2699 --
-- Hudson, NH 03051-4915 | Web: http://www.underscore.com --
----------------------------------------------------------------------