My notes show that we were going to have one counter for critical alerts
and another for non-critical alerts. By having separate counters, the hosts
that are polling for critical alerts won't have to be bothered by all the
other stuff in the alert table.
Bob Pentecost
HP
----------
From: JK Martin[SMTP:jkm at underscore.com]
Sent: Thursday, August 01, 1996 4:59 PM
To: pwg at pwg.org
Subject: Draft of the new prtAlertTableChanges MIB object
Following is a draft of the proposed new Printer MIB object describing
changes to the Alert Table, as discussed at the recent PWG July meeting.
prtAlertTableChanges OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
MIN-ACCESS read-only
STATUS current
DESCRIPTION
"Counts the changes made to the Alert Table in a manner similar
to the prtGeneralConfigChanges object. This value is
incremented
whenever an entry is added to or removed from the table, or if
an existing entry is changed in any way. By monitoring this
object a management application should be able to quickly and
decisively determine when the Alert Table has changed; upon
recognizing a change, the application should acquire the
complete
Alert Table to determine the precise nature of the change."
::= { prtGeneralEntry 16 }
Note carefully that I've placed this object in the prtGeneral Group.
This was chosen to reflect similar kinds of info already existing in
the General Group, although I don't really care where it goes in the
MIB. (Is it legal/tasteful to put this object as a peer to an "Entry"
definition within a Table? Or as a peer to the Table? For example,
"{ prtAlertTable 2 }" or "{ prtAlert 2}" ??)
Any help on improving the DESCRIPTION clause would be appreciated!
...jay