Re: registration OIDs: do the values matter?

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

On Fri, 21 Feb 2003, Andy Bierman wrote:
> Attached is the list of OID assignments used by the RMON MIBs.
> It's not nearly as orderly as it could be.

Indeed.  And I see a couple of assignments in that list that are
wrong and need to be corrected.  Specifically,

SSPM-MIB:     sspmMIB               M-I     { mib-2 777 }
RAQMON-MIB:   raqmon                M-I     { mib-2 6889 }

are listed in the corresponding I-Ds as

SPM-MIB:      sspmMIB               M-I     { rmon 777 }
RAQMON-MIB:   raqmon                M-I     { rmon 6889 }

These obviously needs to be fixed (I see that SPM-MIB is under
review with the note "revision needed" ... this should be on the
list of required fixes if it isn't already).

> The question I'm asking this group is should it be?  SHOULD (not
> MUST) all of OID assignments within a module be children of the
> MODULE-IDENTITY? I actually don't know if it helps application
> developers or not. I think it would help management of the
> { rmon } number space.

For new MIB modules it does seem to be the general practice these
days for all OIDs defined within the module be children of that
module's MODULE-IDENTITY value, often with something like this

xxxObjects       OBJECT IDENTIFIER ::= { xxxMIB 1 }
xxxNotifications OBJECT IDENTIFIER ::= { xxxMIB 2 }
xxxConformance   OBJECT IDENTIFIER ::= { xxxMIB 3 }
...
xxxNotificationPrefix OBJECT IDENTIFIER ::= { xxxNotifications 0 }

or maybe this

xxxNotifications OBJECT IDENTIFIER ::= { xxxMIB 0 }
xxxObjects       OBJECT IDENTIFIER ::= { xxxMIB 1 }
xxxConformance   OBJECT IDENTIFIER ::= { xxxMIB 2 }

for the sub-branches.  Both of these schemes seem to work well.

I think this scheme evolved because it a reasonably obvious way
to minimize the amount of work in managing the number space.
Certainly there is more administrative work involved if there are
multiple subtrees within a module that are not all children of a
single OID, as would happen if (for example) one assigned OIDs for
objects and conformances under different top-level branches.  If
one wishes to assign only one OID to a module and put everything
underneath it, the obvious thing to do is to make this OID the
MODULE-IDENTITY value.  So, if I saw a new MIB module doing
something else I would ask why and suggest that the authors follow
current practice unless there is a reason not to.  So I guess I
would have to agree that MIB authors SHOULD follow this practice.

Having said that, I should hasten to add that the MIB review
guidelines are in fact silent on this point.  I didn't go out of my
way to say in the MIB review guidelines that this is a RECOMMENDED
practice simply because the issue never came up in a MIB review.

The practice is acknowledged in RFC 2578 Section 5.6:

   Note that it is a common practice to use the value of the MODULE-
   IDENTITY macro as a subtree under which other OBJECT IDENTIFIER
   values assigned within the module are defined.

But if other folks feel that would be a good idea to explicitly say
in the guidelines document that this is RECOMMENDED I guess I would
be OK with that.

//cmh