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

["C. M. Heard" <heard@pobox.com>]

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