SMI syntax error in IPSEC-SPD-MIB (RFC 4807) - SNMP

This is a discussion on SMI syntax error in IPSEC-SPD-MIB (RFC 4807) - SNMP ; Hi, I think in IPSEC-SPD-MIB (RFC 4807) there is a SMI syntax error that is difficult to fix without breaking existing implementations (or updating RFC 2578) and which points to a general problem with the VariablePointer TC and default values ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: SMI syntax error in IPSEC-SPD-MIB (RFC 4807)

  1. SMI syntax error in IPSEC-SPD-MIB (RFC 4807)

    Hi,

    I think in IPSEC-SPD-MIB (RFC 4807) there is a
    SMI syntax error that is difficult to fix without
    breaking existing implementations (or updating RFC 2578)
    and which points to a general problem with the
    VariablePointer TC and default values (DEFVAL clause)
    in SMIv2.

    The error in the extracted MIB file is:
    "Illegal object identifier assignment of spdTrueFilterInstance at
    line 1041, column 1 under spdTrueFilter
    for the object ID 1.3.6.1.2.1.153.1.7.1.0 (RFC2578 7.10 et al.)"

    The corresponding definitions of IPSEC-SPD-MIB are:

    spdTrueFilter OBJECT-TYPE
    SYNTAX Integer32 (1)
    MAX-ACCESS read-only
    STATUS current
    DESCRIPTION
    "This scalar indicates a (automatic) true result for
    a filter. That is, this is a filter that is always
    true; it is useful for adding as a default filter for a
    default action or a set of actions."
    ::= { spdStaticFilters 1 }

    spdTrueFilterInstance OBJECT IDENTIFIER ::= { spdTrueFilter 0 }

    spdGroupContFilter OBJECT-TYPE
    SYNTAX VariablePointer
    MAX-ACCESS read-create
    STATUS current
    DESCRIPTION

    "spdGroupContFilter points to a filter that is evaluated
    ....
    packet MUST be dropped."
    REFERENCE "RFC 3289"
    DEFVAL { spdTrueFilterInstance }
    ::= { spdGroupContentsEntry 3 }


    My understanding from RFC2578 7.10 and 3.6(1-2) is that
    the OBJECT IDENTIFIER assignment spdTrueFilterInstance is
    illegal because of 7.10(3):

    (3) Otherwise, no other OBJECT IDENTIFIERs which are subordinate to the
    object may be assigned.

    Here is 3.6(1-2):

    3.6. OBJECT IDENTIFIER usage
    OBJECT IDENTIFIERs are used in information modules in two ways:

    (1) registration: the definition of a particular item is registered as
    a particular OBJECT IDENTIFIER value, and associated with a
    particular descriptor. After such a registration, the semantics
    thereby associated with the value are not allowed to change, the
    OBJECT IDENTIFIER can not be used for any other registration, and
    the descriptor can not be changed nor associated with any other
    registration. The following macros result in a registration:

    OBJECT-TYPE, MODULE-IDENTITY, NOTIFICATION-TYPE, OBJECT-GROUP,
    OBJECT-IDENTITY, NOTIFICATION-GROUP, MODULE-COMPLIANCE,
    AGENT-CAPABILITIES.

    (2) assignment: a descriptor can be assigned to a particular OBJECT
    IDENTIFIER value. For this usage, the semantics associated with
    the OBJECT IDENTIFIER value is not allowed to change, and a
    descriptor assigned to a particular OBJECT IDENTIFIER value cannot
    subsequently be assigned to another. However, multiple descriptors
    can be assigned to the same OBJECT IDENTIFIER value. Such
    assignments are specified in the following manner:

    mib OBJECT IDENTIFIER ::= { mgmt 1 } -- from RFC1156
    mib-2 OBJECT IDENTIFIER ::= { mgmt 1 } -- from RFC1213
    fredRouter OBJECT IDENTIFIER ::= { flintStones 1 1 }
    barneySwitch OBJECT IDENTIFIER ::= { flintStones bedrock(2) 1 }

    Note while the above examples are legal, the following is not:

    dinoHost OBJECT IDENTIFIER ::= { flintStones bedrock 2 }

    A descriptor is allowed to be associated with both a registration and
    an assignment, providing both are associated with the same OBJECT
    IDENTIFIER value and semantics.


    To solve the issue without changing implementations
    of the IPSEC-SPD-MIB, I would relax rule RFC2578 7.10(3)
    to allow OBJECT IDENTIFIER assignments below an OBJECT-TYPE
    definition while not allowing any object registrations
    (RFC 2578 3.6(1)) below a scalar OBJECT-TYPE.

    Do I understand RFC 2578 correctly?

    Regards,
    Frank Fock

  2. Re: SMI syntax error in IPSEC-SPD-MIB (RFC 4807)

    Frank Fock wrote:

    > 3.6. OBJECT IDENTIFIER usage
    > OBJECT IDENTIFIERs are used in information modules in two ways:
    >
    > (1) registration: the definition of a particular item is registered as
    > a particular OBJECT IDENTIFIER value, and associated with a
    > particular descriptor.


    > (2) assignment: a descriptor can be assigned to a particular OBJECT
    > IDENTIFIER value. For this usage, the semantics associated with
    > the OBJECT IDENTIFIER value is not allowed to change, and a
    > descriptor assigned to a particular OBJECT IDENTIFIER value cannot
    > subsequently be assigned to another.


    > To solve the issue without changing implementations
    > of the IPSEC-SPD-MIB, I would relax rule RFC2578 7.10(3)
    > to allow OBJECT IDENTIFIER assignments below an OBJECT-TYPE
    > definition while not allowing any object registrations
    > (RFC 2578 3.6(1)) below a scalar OBJECT-TYPE.


    Section 7.10 of RFC 2578 talks about assignments without being very
    precise how the word is interpreted. As far as I recall, the intention
    really was to talk about registrations. ASN.1 value assignments like

    sysUpTimeInstance OBJECT IDENTIFIER ::= { sysUpTime 0 }

    are made in other IETF MIB modules. If you want a final resolution of
    this, you need to bring this up on the mib-doctors mailing list and
    then go through the discussion process to see whether it is possible
    to find consensus on an RFC 2578 errata.

    /js

    --
    Juergen Schoenwaelder Jacobs University Bremen gGmbH
    Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany
    Fax: +49 421 200 3103

  3. Re: SMI syntax error in IPSEC-SPD-MIB (RFC 4807)

    HI,

    Section 7.10 specifies the rules for OID values that can be specified
    for an OBJECT TYPE definition and does not restrict the values for
    other OID assignments used for other constructs such as the
    OBJECT-IDENTITY construct. However, section
    3.6 makes this restriction so that there is no semantic ambiguity
    when mapping between an OID value and an item. That is,
    section 3.6 makes two points. The first is to restrict a single
    registration to an OID value, so that an OID value to registered item
    mapping is always unambiguious. And secondly, to say that
    "OID value assignments" of the form
    OBJECT IDENTIFIER ::=
    has no semantic mapping. It is simply a shorthand way to
    write an OID value.

    Thus, I don't believe that there is any problem with section
    7.10(3) of RFC 2578.

    Regards,
    /david t. perkins

+ Reply to Thread