Re: registration OIDs: do the values matter?

[Andy Bierman <abierman@cisco.com>]

At 11:14 AM 2/22/2003 -0800, C. M. Heard wrote:
>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 MIB modules are under development and will be fixed soon.


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

agreed. At Cscio, we are trying to get MIB authors to use
the 2nd approach.


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

I think the text in 2578 is good enough. I don't know if
it's important enough to put in the MIB review draft.
This practice minimizes the number of registration OIDs
that can conflict with definitions in other modules to 1.


>//cmh

Andy