Changing enum labels -- is this an SMIv2 bug?

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

Folks,

The SMIv2 documents explicitly permit the labels assigned to
enumerations in INTEGER or BITS types to be changed when a
MIB 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.

Unfortunately, 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 result from modifying labels 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 SMIv2 documents to allow labels
associated with existing enumerations and bit positions to be
changed when a MIB module is revised.  Indeed, I would go so far as
to call this a bug in the SMIv2 documents, because they go out of
their way to ban similar changes that break backward compatibility --
in particular, changes to descriptors of objects and notifications
are classified as semantic change and is not allowed because those
descriptors can be used in an IMPORTS statement in another module.

Other opinions are solicited.

Mike