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
>
>
>
> 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 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