RE: Changing enum labels -- is this an SMIv2 bug?

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

On Sun, 19 Jan 2003, Orly Nicklass wrote:

> isn't the problem appear only in cases using TEXTUAL-CONVENTION?
> I assume when the change is embedded in enum body and not via
> TEXTUAL-CONVENTION this will not occur.

Unfortunately, no.  As I said in the original message, the same type
of problem can result from modifying a label in an OBJECT-TYPE that
uses an enumerated INTEGER (or BITS construct), because a VARIATION
clause in an AGENT-CAPABILITIES statement can specify a DEFVAL for
such an object, and it will become invalid if the label it uses is
changed.  Here is an example to illustrate that problem:

ELEVATOR-MANAGEMENT DEFINITIONS ::= BEGIN

IMPORTS
    MODULE-IDENTITY, OBJECT-TYPE, experimental
        FROM SNMPv2-SMI
    OBJECT-GROUP
        FROM SNMPv2-CONF;

elevatorManagement MODULE-IDENTITY
    LAST-UPDATED "200301182358Z"  -- January 18, 2003
    ORGANIZATION " "
    CONTACT-INFO " "
    DESCRIPTION  "Module containing elevator management objects"
    REVISION     "200301182358Z"  -- January 18, 2003
    DESCRIPTION  "Base version."
    ::= { experimental 99999996 } -- bogus, get a real number from IANA

elevatorStatus  OBJECT-TYPE
    SYNTAX      INTEGER { descending(-1), halted(0), ascending(1) }
    MAX-ACCESS  read-write
    STATUS      current
    DESCRIPTION " "
    ::= { elevatorManagement 1 }

elevatorGroup   OBJECT-GROUP
    OBJECTS     { elevatorStatus }
    STATUS      current
    DESCRIPTION " "
    ::= { elevatorManagement 2 }

END

ELEVATOR-AGENT-CAPS DEFINITIONS ::= BEGIN

IMPORTS
    MODULE-IDENTITY, experimental
        FROM SNMPv2-SMI
    AGENT-CAPABILITIES
        FROM SNMPv2-CONF
    elevatorGroup, elevatorStatus
        FROM ELEVATOR-MANAGEMENT;

elevatorAgentCaps MODULE-IDENTITY
    LAST-UPDATED "200301182358Z"  -- January 18, 2003
    ORGANIZATION " "
    CONTACT-INFO " "
    DESCRIPTION  "Module containing elevator agent capabilities"
    REVISION     "200301182358Z"  -- January 18, 2003
    DESCRIPTION  "Base version."
    ::= { experimental 99999997 } -- bogus, get a real number from IANA

elevatorAgent   AGENT-CAPABILITIES
    PRODUCT-RELEASE	"X001"
    STATUS      current
    DESCRIPTION "Capabilites of elevator agent"

    SUPPORTS    ELEVATOR-MANAGEMENT
    INCLUDES    { elevatorGroup }
    VARIATION   elevatorStatus
    DEFVAL      { halted }        -- PROBLEM if this label changes
    DESCRIPTION "halted state assumed if object not explicitly set"

    ::= { elevatorAgentCaps 1 }

END

All is well, and the ELEVATOR-AGENT-CAPS compiles OK.  But now, as
in the previous case, suppose that someone decides to change the
labels of the enumerations when updating ELEVATOR-MANAGEMENT and
produces the following (legal) revision:

ELEVATOR-MANAGEMENT DEFINITIONS ::= BEGIN

IMPORTS
    MODULE-IDENTITY, OBJECT-TYPE, experimental
        FROM SNMPv2-SMI
    OBJECT-GROUP
        FROM SNMPv2-CONF;

elevatorManagement MODULE-IDENTITY
    LAST-UPDATED "200301190000Z"  -- January 19, 2003
    ORGANIZATION " "
    CONTACT-INFO " "
    DESCRIPTION  "Module containing elevator management objects"
    REVISION     "200301190000Z"  -- January 19, 2003
    DESCRIPTION  "Revised the enum labels."
    REVISION     "200301182358Z"  -- January 18, 2003
    DESCRIPTION  "Base version."
    ::= { experimental 99999996 } -- bogus, get a real number from IANA

elevatorStatus  OBJECT-TYPE
    SYNTAX      INTEGER { goingDown(-1), stopped(0), goingUp(1) }
    MAX-ACCESS  read-write
    STATUS      current
    DESCRIPTION " "
    ::= { elevatorManagement 1 }

elevatorGroup   OBJECT-GROUP
    OBJECTS     { elevatorStatus }
    STATUS      current
    DESCRIPTION " "
    ::= { elevatorManagement 2 }

END

./ELEVATOR-MANAGEMENT:14 [5] {revision-added} revision `2003-01-19 00:00' added
./ELEVATOR-MANAGEMENT:20 [5] {named-number-changed} named number `descending' changed to `goingDown' at type used in `elevatorStatus'
./ELEVATOR-MANAGEMENT:20 [5] {named-number-changed} named number `halted' changed to `stopped' at type used in `elevatorStatus'
./ELEVATOR-MANAGEMENT:20 [5] {named-number-changed} named number `ascending' changed to `goingUp' at type used in `elevatorStatus'

These changes break ELEVATOR-AGENT-CAPS, because it still uses
'halted' in its DEFVAL clause for elevatorStatus.  Now in real life
it's quite possible for an agent-caps module written by a vendor to
refer to objects in third-party MIB modules like the ones that we
develop here in the IETF.  So it's not just label changes in TCs
that can cause problems for users of our MIB modules;  label changes
in object definitions have the potential to do the same thing.

Incidentally, I did a little checking on the history of this, and
the rule allowing changes to enumerated INTEGER and BITS (then BIT
STRING) labels originated in RFC 1442.  The practice of allowing a
label from an enumeration in a DEFVAL was carried forward from SMIv1
(the earliest published example I can find is RFC 1248, circa July
1991).  So this problem has been around for quite some time now.

Mike