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

[Harry Lewis <[e-mail]>]

I think it should be a type-1 enum and the RFC should have been approved about
9 months ago ;-). I sense that someone may have an implementation itching 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 pending
OID. Still, if it would ease the pain, I guess we could consider the type-2
enum approach. The distinction and cuttoff (between type-1 and type-2 event
codes) is somewhat arbitrary in the first place. It's just that the "alert
alert" is pretty fundamental.

Harry Lewis - IBM Printing Systems



[e-mail] on 06/04/98 07:54:31 PM
Please respond to [e-mail]
To: [e-mail]
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 published.

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 unary
                              -- change alert table entry is added to the
                              -- 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(1801)
                   prtAlertDescription     <description or null string>
                   prtAlertTime            the value of sysUpTime at
                                           the time of the removal of the

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 ::= TEXTUAL-CONVENTION
              -- This value is a type 1 enumeration for values in the range
              -- 1 to 29.
              -- Values of 30 and greater are type 2 enumerations and are
              -- for use in other MIBs that augment tables in the Printer



          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 30 or
              -- higher to use the alert table from the Printer MIB without
              -- 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 identifies
                   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 critical
                   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 ::= 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 describe
                   states of the subunit while unary change event alerts



          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 code
                   can be used to indicate a critical or a non-critical
                   (warning) alert, depending on implementation. The value
                   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 subunits,
                   the generic codes should be used for most subunit
                   alerts. The network management station can then query
                   the subunit specified by prtAlertGroup to determine
                   further subunit status and other subunit information