[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: OID values



Hi -

> From: "David T. Perkins" <dperkins@dsperkins.com>
> To: <strauss@ibr.cs.tu-bs.de>
> Cc: <libsmi@ibr.cs.tu-bs.de>; <ietfmibs@ops.ietf.org>
> Sent: Wednesday, December 01, 2004 2:11 PM
> Subject: OID values
...
(good stuff I agree with deleted)
...
>  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".

I don't think there's any need to make it illegal.
Although the practice could hardly be advisable, it
does not introduce any ambiguity.

...
>     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?)

An object identifier with only one component value can't be encoded
using BER.  The current ASN.1 specs in a note ins section 31.6
of X.680 say: "Object identifier values are required to have at
least two components."

>                       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.)
...

I had always understood the limitation to be on the total number
of components in the object identifier, not the number of tokens
between the "{" and the "}".

Randy