Changing enum labels considered harmful

["C. M. Heard" <heard@pobox.com>]

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