[libsmi] OID values

1 Dec 2004


      HI,
This recent discussion about valid OID values is quite old
and has been repeated many times on many different forums.
RFC 2578, section 3.6 has the most direct text. However,
it does not specificly address "named-number" sub-identifiers
in OID values, nor discuss the issue of uniqueness of
descriptors of sibling OID values.
It explicitly covers: 
 1) registration vs assignment and says that it is legal.
    That is, in a MIB module, one could have all three
    of the following definitions (which all have the
    same OID value):
d1 OBJECT IDENTIFIER ::= { goo 1 }
    d2 OBJECT IDENTIFIER ::= { goo 1 }
    d3 OBJECT-IDENTITY -- or OBJECT-TYPE, MODULE-COMPLIANCE, etc
                         ::= { goo 1 }
It does not say anything about labels. And in such cases,
one has to read the ASN.1-1988 definition. So for cases:
 2) semantics of a label on a "name-number" sub-identifier.
    For ASN.1, the lalel caries no semantics and is
    simply an aid to the reader. Thus, you have the
    following outcomes:
    a) the label is just a label, and even though it
       seems redundant or conflicting, it can be specified
       on the last sub-identifier in an OID value. Thus,
       the following definitions are legal:
         da1 OBJECT IDENTIFIER 
                 ::= { goo da1(1) } -- legal and "redundant" label 
         da2 OBJECT IDENTIFIER
                 ::= { goo da2X(1) } -- legal and "conflicting" label
    b) the label cannot be referenced by other definitions.
       Thus, the second definition is illegal:
         db1 OBJECT IDENTIFIER ::= { goo bar(1) }
         db2 OBJECT IDENTIFIER ::= { bar 1 } -- illegal, since bar
                                                is not defined!
    c) the label cannot be imported! Thus, the following
         import of "regs" is illegal:
         M1 DEFINITIONS ::= BEGIN
          ...
          dc1 OBJECT IDENTIFIER ::= { myRoot regs(1) 34 }
          ...
         END
         M2 DEFINITIONS ::= BEGIN
           IMPORTS
             regs FROM M1  -- illegal, since regs is not defined
           ...
         END
     d) the label can be used on other values (even though
        it may be confusing). Thus the second usage (in the
        same MIB module) is legal:
          dd1 OBJECT IDENTITY ::= { goo bar(1) }
          dd2 OBJECT IDENTITY ::= { goo bar(2) } -- legal   
A case that is not covered (that I can find) in the ASN.1-1988
docs or in the SMI is the following:
 3) The same descriptor on sibling OID values for either
    registrations or assignments. Note that ASN.1 (and the SMI)
    disallows the same descriptor to be used on a definition
    within a single MIB module. However, both (in certain cases)
    allow the same descriptor to be used on definitions found
    in different MIB modules. Normally this is not a problem.
    However, if the descriptor are used for "sibling OID values",
    then this is confusing. For example, I can find no
    text that restricts the following definitions:
      M3a DEFINITIONS ::= BEGIN
        ...
        def3 OBJECT-IDENTITY ...  ::= { goo 1 }
        ...
      END
      M3b DEFINITIONS ::= BEGIN
        ...
        def3 OBJECT IDENTIFIER ... ::= { goo 2 }
      END
      M3c DEFINITIONS ::= BEGIN
        ...
        def3 OBJECT-TYPE ... ::= { goo 3}
        ...
      END
    Resulting in defintions:
       goo.1 def3
       goo.2 def3
       goo.3 def3
    I suggest that the above be made illegal, and clarified
    in an update to RFC 2578. That is, is is illegal to create
    definitions that are assignments and registrations that
    use the same descriptor for "OID value siblings".
And a repeat of a usage that comes up again and again.
 4) What is the legal form or OID values? The ASN.1 spec
    and the SMI must be consulted to determine the
    rules. The important rules are:
    a) an OID value is contained in "{" and "}"
    b) the first item is either:
       i) a previous defined (or imported) item
          that has an OID value
       ii) a number or named-number with value of
            0, 1, or 2
       iii) one of the following well known names:
            ccitt, iso, joint-iso-ccitt (see RFC 2578 section 3.5)
    c) the minimum number of items specified in the "{" and "}"
       is not explicited stated in the SMI, and is allowed
       to be 1 in ASN.1. However, one does not seem to be
       supported by SNMP MIB module compilers. (Do we need
       clarification?) The SMI restrict the maximum number
       to 128. (However, practically it would be lower if
       the first item is a defined item with an OID value.)
       That is, the following are legal:
          d4a OBJECT IDENTIFIER ::= { goo 1 2 3 }
          d4b OBJECT IDENTIFIER ::= { goo bar(2) 78 red(3) 99 }  
    d) there is no requirement that all of the OID sub-identifiers
       in an OID value have an assignment, registration, or
       label associated with them. So, an OID value dump
       could look like:
         iso(1).org(3).dod(6).internet(1).678.docs(1).foo(2)
       That is, the sub-identifier "678" does not have
       a descriptor or label associated with it!
I hope I have covered this issue. If not, others please
send questions and examples. Maybe there needs to be a
two or three page BCP for OIDs in SNMP MIB modules.
Regards,
/david t. perkins

[libsmi] OID values

David T. Perkins