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

[Ron Bergman <[e-mail]>]

Harry,

We cannot make this a type-2 without a new specification (RFC).

I do agree that the risk of including this addition as a part of an RFC
1759 implememtation is fairly low.  as long as a supporting management
application does not get upset, there is no problem.

	Ron Bergman
	Dataproducts Corp.



On Thu, 11 Jun 1998, Harry Lewis wrote:

> 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