PMP Mail Archive: Re: PMP> Can an RFC 1759 implementation use the alert(18) ty

Re: PMP> Can an RFC 1759 implementation use the alert(18) ty

Harry Lewis (harryl@us.ibm.com)
Thu, 11 Jun 1998 17:47:34 -0400

I think it should be a type-1 enum and the RFC should have been approve=
d about
9 months ago ;-). I sense that someone may have an implementation itchi=
ng to
use this new feature but doesn't want to ship to a latent spec. I know =
the
feeling! I don't think shipping a "Code 18" is as risky as shipping a p=
ending
OID. Still, if it would ease the pain, I guess we could consider the ty=
pe-2
enum approach. The distinction and cuttoff (between type-1 and type-2 e=
vent
codes) is somewhat arbitrary in the first place. It's just that the "al=
ert
alert" is pretty fundamental.

Harry Lewis - IBM Printing Systems

pmp-owner@pwg.org on 06/04/98 07:54:31 PM
Please respond to pmp-owner@pwg.org
To: pmp@pwg.org
cc:
Subject: PMP> Can an RFC 1759 implementation use the alert(18) type 1

RFC 1759 says that implementations conforming to RFC 1759 may implement=

type 2 and type 3 enums that are registered after 1759 has been publish=
ed.

In order to use the new type 2 alert code:

-- Alert Group
alertRemovalOfBinaryChangeEntry(1801)
-- A binary change event entry has been
-- removed from the alert table. This una=
ry
-- change alert table entry is added to t=
he
-- end of the alert table.

an implementation has to include the new type 1 alert(18) code
in the alert table and trap (which is defined in the draft Printer MIB)=
:

prtAlertSeverityLevel warningUnaryChangeEvent(4)
prtAlertTrainingLevel noInterventionRequired(7)
prtAlertGroup alert(18)
prtAlertGroupIndex the index of the row in the
alert table of the binary
change event that this event=

has removed.
prtAlertLocation unknown (-2)
prtAlertCode alertRemovalOfBinaryChangeEntry(1=
801)
prtAlertDescription <description or null string>=

prtAlertTime the value of sysUpTime at
the time of the removal of t=
he

With hind site we should have made the PrtAlertGroupTC a type 2
enum, instead of a type 1 enum. But we didn't.

Alternatively, since the alert group codes starting at 30 are type 2,
why not also indicate that the alert code 18 is also type 2, so that
implementations conforming to RFC 1759 can use it?

Or am I just being too fussy here? Should implementators conforming to=

RFC 1759 feel free to implement the alert(18) type 1 code?

Here is the complete text of both TCs:

PrtAlertGroupTC ::=3D TEXTUAL-CONVENTION
-- This value is a type 1 enumeration for values in the r=
ange
-- 1 to 29.
-- Values of 30 and greater are type 2 enumerations and a=
re
-- for use in other MIBs that augment tables in the Print=
er

Turner draft-ietf-printmib-mib-info-03.txt [Page=
61]
Expires July 22, 1998

INTERNET DRAFT Printer MIB October 15, =
1997

-- MIB. Therefore, other MIBs may assign alert codes of 3=
0 or
-- higher to use the alert table from the Printer MIB wit=
hout
-- requiring revising and re-publishing this document.
STATUS current
DESCRIPTION
"The type of sub-unit within the printer model that =
this
alert is related. Input, output, and markers are
examples of printer model groups, i.e., examples of
types of sub-units. Wherever possible, these
enumerations match the sub-identifier that identifie=
s
the relevant table in the printer MIB.

NOTE: Alert type codes have been added for the host
resources MIB storage table and device table. These
additional types are for situations in which the
printer's storage and device objects
must generate alerts (and possibly traps for critica=
l
alerts)."
SYNTAX INTEGER {
other(1),
hostResourcesMIBStorageTable(3),
hostResourcesMIBDeviceTable(4),
generalPrinter(5),
cover(6),
localization(7),
input(8),
output(9),
marker(10),
markerSupplies(11),
markerColorant(12),
mediaPath(13),
channel(14),
interpreter(15),
consoleDisplayBuffer(16),
consoleLights(17),
alert(18)
}

PrtAlertCodeTC ::=3D TEXTUAL-CONVENTION
-- This value is a type 2 enumeration
STATUS current
DESCRIPTION
"The code that describes the type of alert for this
entry in the table. Binary change event alerts descr=
ibe
states of the subunit while unary change event alert=
s

Turner draft-ietf-printmib-mib-info-03.txt [Page=
62]
Expires July 22, 1998

INTERNET DRAFT Printer MIB October 15, =
1997

describe a single event. The same alert code can be =
used
for a binary change event or a unary change event,
depending on implementation. Also, the same alert co=
de
can be used to indicate a critical or a non-critical=

(warning) alert, depending on implementation. The va=
lue
of prtAlertSeverityLevel specifies binary vs. unary =
and
critical vs. non-critical for each event for the
implementation.

While there are some specific codes for many subunit=
s,
the generic codes should be used for most subunit
alerts. The network management station can then quer=
y
the subunit specified by prtAlertGroup to determine
further subunit status and other subunit information=