Support for Additional Enums - SNMP

This is a discussion on Support for Additional Enums - SNMP ; Hello! I was wondering if adding additional enum definitions to an integer object would cause problems with SNMP Managers that would have to support both the old and new objects. For example: Old Definition ============== FooValue ::= TEXTUAL-CONVENTION STATUS current ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Support for Additional Enums

  1. Support for Additional Enums

    Hello!

    I was wondering if adding additional enum definitions to an integer
    object would cause problems with SNMP Managers that would have to
    support both the old and new objects.

    For example:

    Old Definition
    ==============

    FooValue ::= TEXTUAL-CONVENTION
    STATUS current
    DESCRIPTION
    "An integer value"
    SYNTAX INTEGER {
    value1 (1),
    value2 (2),
    value3 (3)
    }

    New Definition
    ==============

    FooValue ::= TEXTUAL-CONVENTION
    STATUS current
    DESCRIPTION
    "An integer value"
    SYNTAX INTEGER {
    value1 (1),
    value2 (2),
    value3 (3),
    new4 (4),
    new5 (5)
    }

    Would a SNMP Manager be able to manager two different devices, one
    that had objects using the old FooValue TEXTUAL-CONVENTION and one
    that used the new value new FooValue? Is it even possible to compile
    two MIBs with different definitions like this?

    Thanks

    Kai Mao

  2. Re: Support for Additional Enums

    > I was wondering if adding additional enum definitions to an integer
    > object would cause problems with SNMP Managers that would have to
    > support both the old and new objects.
    >
    > For example:
    >

    [ ... snipped .., ]

    This modification is explicitly allowed. See RFC 2578 Section 10.

    > Would a SNMP Manager be able to manager two different devices, one
    > that had objects using the old FooValue TEXTUAL-CONVENTION and one
    > that used the new value new FooValue?


    Sure ... assuming that agent and manager are implemented properly.

    That means: (a) the agent properly handles the situation where a
    manager, implemented to support the extended TC, sends it a value
    that it doesn't support (which it has to be able to do anyway);
    (b) the manager is prepared, when reading an object, to get back
    values that it does not know about but which the agent (implemented
    with a newer version of the TC) does; and (c) the manager is prepared,
    when setting an object, to have the agent (implemented with an older
    version of the TC) reject apparently valid values.

    > Is it even possible to compile two MIBs with different definitions
    > like this?


    The question is confused. Presumably, the TC (FooValue) will reside
    in some MIB module (FOO-TC-MIB) and the different versions of FooValue
    will reside in different versions of FOO-TC-MIB. Naturally you would
    not compile more than one version of FOO-TC-MIB at a time. Now, the
    objects defined with FooValue could live in other MIB modules that
    import FooValue from FOO-TC-MIB. Since you are only allowed to add
    (not to remove) enums, then everything will compile just fine as long
    as the version of FOO-TC-MIB is at least as new as the newest MIB
    module that imports from it. In other words, you are safe if you
    always use the latest version of FOO-TC-MIB. (*)

    One possible side effect from adding enums is that it might silently
    change the meaning of compliance or capabilities statements; but
    that can be fixed by adding OBJECT or VARIATION clauses that explicitly
    spell out which enums are requires or supported (respectively).

    nobody

    (*) Actually, there could be compilation problems if you change enum
    labels, since they can appear in DEFVAL clauses; so you shouldn't do
    that, despite the fact that RFC 2578 allows it. The IETF MIB review
    guidelines draft now forbids that.

+ Reply to Thread