Draft of the new prtAlertTableChanges MIB object

Draft of the new prtAlertTableChanges MIB object

Draft of the new prtAlertTableChanges MIB object

Caruso,Angelo Angelo_Caruso at wb.xerox.com
Tue Aug 6 11:50:19 EDT 1996


The XPrint 4920 does not implement any unary alerts (e.g. 
 interpreterCartridgeAdded) since these typically involve a power cycle 
 or reset, which will clear the alert table.

I would like to propose the following alternative to the new 
 prtAlertTableChanges object. This alternative requires no new objects 
 and is fairly simple to implement.

The management application needs to keep track of the OIDs of the 
 entries in the prtAlertSeverityLevel column. Instead of polling a new 
 counter object, the management station should periodically do a 
 GetNext with the OIDs in this column (typically this should fit in a 
 single PDU). The response will give the severity level of the next new 
 alert (if there is one) and also let you know when an existing alert 
 has been removed. Note that if an alert is added and subsequently 
 removed between polling intervals this method will miss it, but so 
 will a counter based method. The only real issue with this method is 
 that if there are many alerts in the table then several PDUs may be 
 requried to perform the GetNext. But typically this won't be the case 
 since the alert table is usually close to empty.



From: owner-pwg at pwg.org
To: binnur at hpb15650.boi.hp.com
Cc: JK Martin; pwg at pwg.org
Subject: RE: Draft of the new prtAlertTableChanges MIB object
Date: Friday, August 02, 1996 6:51PM


> 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

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,

> 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


More information about the Pwg mailing list