Binnur,
> However, talking to our developers here, they are more concern with
> counter incrementing for both critical & warning alerts. As an example,
> even if there is no critical error present, finding out that the toner is
> getting low, or you are out of paper in tray 1 is as important. So, we
> want to filter out everything else from the counter object which are
> informational, or possibly classified as other. This way, we could still
> have only one object added to the MIB, and if the management application
> is interested in all the changes that occurs in the alert table, they
> would simply poll. Any comments from other developers??
I completely understand your interests and concerns. (Really!)
You make it sound like a typical Printer MIB implementation will have
tons of "informational" messages stored in the Alert Table. Is this
really the case, though? (As a software developer, I certainly hope not!)
So, can all of you Printer MIB implementers out there give the PWG some
idea of how many (and what types of) "informational" messages you expect
to insert into the Alert Table? We want to hear from you as soon as
possible.
Incidentally, since informational messages are unary (er, non-binary),
I would think most printer manufacturers would be very cautious about
putting such messages in the Alert Table since they consume valuable
space. Unless a particular manufacturer has some kind of "special" needs
(aka "value-added features") that are perhaps proprietary for special
associated software, I can't imagine this happening...at least not much,
anyway.
> I was thinking in terms of sending a trap out with a alert code that
> indicates that alert table change has occurred (without entering it into
> the alert table). This would be a duplicate entry for critical errors,
> but might be useful for warnings.. Overall, I just wanted to assure we
> have covered all areas in the Printer MIB in terms of adding this new
> object.
Traps? Did you say TRAPS?? Let me quote from the SNMP Book of Life:
"Traps are bad. Traps are to be avoided. Traps should only
be used to indicate truly catastrophic situations, such as
the pending doom of the Earth, or perhaps the reinstatement
of the SDI Program..."
Seriously, though, the use of Traps with the Printer MIB is a complete
and utter mess, not to mention virtually useless for non-NMS management
apps (ie, apps used by other than network managers).
Hey, if you want to add a new Trap--and no one else minds--I guess it
doesn't really matter. Anyone else have an opinion to share on this
topic?
...jay