Re: OID Registration -- Rules versus BCP (fwd)

["David T. Perkins" <dperkins@dsperkins.com>]

HI,

I believe that the descriptions in section 7.10 refer only to
OID values used for object types.

I believe it would be perfectly valid to create, for example,
the following definition:
  ifDescr1 OBJECT-IDENTITY .... ::= { ifDescr 1 }

There are really two rules, which are:
1) using the constructs that register (such as MODULE-IDENTITY,
   OBJECT-IDENTITY, OBJECT-TYPE, etc), the same OID value cannot
   be used by two
2) OID values for OBJECT-TYPEs have additional restrictions, which
    are:
     1) OID values for row OBJECT-TYPEs must have form { <table> 1 }
     2) OID values for columnar OBJECT-TYPEs must have form { <row> <c> }
     3) OID values for a table OBJECT-TYPE cannot be under
        the OID value of another OBJECT-TYPE
     4) OID values for a scalar OBJECT-TYPE cannot be under
        the OID value of another OBJECT-TYPE

These "rules" are reasonable and practical, with an minimal of
silliness.

Can someone define OBJECT-TYPES under an OBJECT-GROUP? Sure,
but not recommended. Why not? Well in the "first version",
all the members of the object group can be defined under
the object group. But in the "second version" where a new
OBJECT-TYPE is defined, it CANNOT be made a member of the
object group, and it will certainly be a source for confusion
and errors.

At 06:23 PM 1/9/2003 -0800, C. M. Heard wrote:
>On Thu, 9 Jan 2003, Michael Kirkham wrote:
>> An issue has come up that I was hoping to get some consensus on regarding
>> OID registration and whether or not certain types of macro invocations are
>> permitted to be defined with OIDs subordinate to other types of macro
>> invocations.  Obviously no OIDs can be registered under an OBJECT-TYPE
>> unless they are the row and column OBJECT-TYPEs of a conceptual table,
>> since it would conflict with the object's instance identifier(s).
>
>Correct.  RFC 2578 Section 7.10 makes this quite explicit.  In fact it
>seems to go further;  if I correctly interpret the following, it is not
>not just registration but any assignment that it banned:
>
>(3)  Otherwise, no other OBJECT IDENTIFIERs which are subordinate to the
>     object may be assigned.
>
>> However, I'm not sure the rules are so clear cut in other cases.  I am
>> aware that some compilers will complain if you assign, say, an OBJECT-TYPE
>> an OID subordinate to an OBJECT-GROUP, while others do not.
>[ ... ]
>> Certainly it is not a very clear or well-organized design to define, say,
>> an OBJECT-GROUP subordinate to a NOTIFICATION-TYPE, or an OBJECT-TYPE
>> subordinate a NOTIFICATION-GROUP, but offhand I am not seeing that it is
>> explicitly illegal to do so.
>
>I agree that this is strange, and if I saw it while reviewing a new MIB
>module I would politely suggest to the author that the OID assignments
>could be better organized.
>
>On the other hand, I can't find anything that says it's illegal, and as
>far as I can tell, it's actually harmless.
>
>> Seeing as how some compilers will complain and others will not, I am
>> leaning toward allowing such relationships and issuing compatibility and
>> BCP warnings if they are encountered, unless someone can point to
>> something I might have overlooked.
>
>That seems reasonable to me.  I'd like to have warnings about such things.
>But it's also a good idea to also have a reliable way to turn the warning
>off.  Not everyone appreciates such warnings, particularly for things that
>are not actually harmful, and sometimes one has to deal with existing MIB
>modules that don't conform to your (or my) concept of "well-organized".
>
>//cmh
Regards,
/david t. perkins