[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Changing enum labels considered harmful
HI,
This issue has seen a lot of discussion between KZM, Juergen, (and somewhat
recently Frank), and myself. There are additional issues than what you
have specified below. It also affects MCs, ACs, and refined ENUM and TC
usage. And note, whether refined ENUM and TC usage is valid and supported,
is another topic for discussion.
Refined ENUM/TC is
MyTC TEXTUAL-CONVENTION ... SYNTAX INTEGER{ red(1), blue(2), green(3) }
myOt OBJECT-TYPE ... SYNTAX MyTC { red(1), green(3) }
have a good day...
At 10:38 PM 1/16/2003 -0800, C. M. Heard wrote:
>Howdy,
>
>Allow me to remind you that the SMIv2 documents explicitly permit
>the labels assigned to enumerations in INTEGER or BITS types to be
>changed when an information module is revised:
>
>+ From RFC 2578 Section 7.1.4, "The BITS construct":
>
> As part of updating an information module, for an object defined
> using the BITS construct, new enumerations can be added or existing
> enumerations can have new labels assigned to them.
>
>+ From RFC 2578, Section 10.2, "Object Definitions":
>
> An object definition may be revised in any of the following ways:
>
>(1) A SYNTAX clause containing an enumerated INTEGER may have new
> enumerations added or existing labels changed. Similarly, named
> bits may be added or existing labels changed for the BITS
> construct.
>
>+ From RFC 2579, Section 5, "Revising a Textual Convention":
>
> The following revisions are allowed:
>
>(1) A SYNTAX clause containing an enumerated INTEGER may have new
> enumerations added or existing labels changed. Similarly, named
> bits may be added or existing labels changed for the BITS
> construct.
>
>It has occurred to me that such revisions have the potential to
>cause backward compatibility problems. Consider the following:
>
>ELEVATOR-TC DEFINITIONS ::= BEGIN
>
>IMPORTS
> MODULE-IDENTITY, experimental
> FROM SNMPv2-SMI
> TEXTUAL-CONVENTION
> FROM SNMPv2-TC;
>
>elevatorTC MODULE-IDENTITY
> LAST-UPDATED "200301162358Z" -- January 16, 2003
> ORGANIZATION " "
> CONTACT-INFO " "
> DESCRIPTION "Module containing elevator TCs"
> REVISION "200301162358Z" -- January 16, 2003
> DESCRIPTION "Base version."
> ::= { experimental 99999998 } -- bogus, get a real number from IANA
>
>ElevatorStatus ::= TEXTUAL-CONVENTION
> STATUS current
> DESCRIPTION " "
> SYNTAX INTEGER { descending(-1), halted(0), ascending(1) }
>
>END
>
>ELEVATOR-MANAGEMENT DEFINITIONS ::= BEGIN
>
>IMPORTS
> MODULE-IDENTITY, OBJECT-TYPE, experimental
> FROM SNMPv2-SMI
> ElevatorStatus
> FROM ELEVATOR-TC
> OBJECT-GROUP
> FROM SNMPv2-CONF;
>
>elevatorManagement MODULE-IDENTITY
> LAST-UPDATED "200301162358Z" -- January 16, 2003
> ORGANIZATION " "
> CONTACT-INFO " "
> DESCRIPTION "Module containing elevator management objects"
> REVISION "200301162358Z" -- January 16, 2003
> DESCRIPTION "Base version."
> ::= { experimental 99999999 } -- bogus, get a real number from IANA
>
>elevatorStatus OBJECT-TYPE
> SYNTAX ElevatorStatus
> MAX-ACCESS read-write
> STATUS current
> DESCRIPTION " "
> DEFVAL { halted } -- PROBLEM if this label changes
> ::= { elevatorManagement 1 }
>
>elevatorGroup OBJECT-GROUP
> OBJECTS { elevatorStatus }
> STATUS current
> DESCRIPTION " "
> ::= { elevatorManagement 2 }
>
>END
>
>All is well, and the ELEVATOR-MANAGEMENT compiles OK. But now suppose
>that someone decides to change the labels of the enumerations when
>updating ELEVATOR-TC and produces the following (legal) revision:
>
>ELEVATOR-TC DEFINITIONS ::= BEGIN
>
>IMPORTS
> MODULE-IDENTITY, experimental
> FROM SNMPv2-SMI
> TEXTUAL-CONVENTION
> FROM SNMPv2-TC;
>
>elevatorTC MODULE-IDENTITY
> LAST-UPDATED "200301170000Z" -- January 17, 2003
> ORGANIZATION " "
> CONTACT-INFO " "
> DESCRIPTION "Module containing elevator TCs"
> REVISION "200301170000Z" -- January 17, 2003
> DESCRIPTION "Revised the enum labels."
> REVISION "200301162358Z" -- January 16, 2003
> DESCRIPTION "Base version."
> ::= { experimental 99999998 } -- bogus, get a real number from IANA
>
>ElevatorStatus ::= TEXTUAL-CONVENTION
> STATUS current
> DESCRIPTION " "
> SYNTAX INTEGER { goingDown(-1), stopped(0), goingUp(1) }
>
>END
>
>Alas, now ELEVATOR-MANAGEMENT no longer compiles :-(
>
>./ELEVATOR-MANAGEMENT:20: [2] {defval-syntax} default value syntax does not match object syntax
>./ELEVATOR-MANAGEMENT:20: [2] {defval-enum} default value does not match underlying enumeration type
>
>The same type of problem can happen from modifying labels in in
>OBJECT-TYPES, because a VARIATION clause in an AGENT-CAPABILITIES
>statement can specify a DEFVAL for an object with enumerated INTEGER
>SYNTAX and be undermined in precisely the same way. And since the
>labels are in DEFVALs for objects with BITS SYNTAX, the same problem
>can arise from modifying labels associated with bit positions, too.
>
>I think it was a mistake for the SMI to allow labels associated with
>existing enumerations and bit positions to be changed when a module
>is revised, and I believe that the practice should be forbidden in
>revisions of IETF MIB. If others on the mreview list agree with
>this, I'll put some words to that effect in the MIB author's and
>reviewer's guide, and Juergen or Frank might want to consider
>adding an equivalent item to the on-line SMI errata list.
>
>Mike
/david t. perkins