[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Proposed OID layout update text in guidelines doc
Looks fine to me
Thanks,
Bert
> -----Original Message-----
> From: C. M. Heard [mailto:heard@pobox.com]
> Sent: woensdag 13 augustus 2003 0:33
> To: Mreview (E-mail)
> Subject: Proposed OID layout update text in guidelines doc
>
>
> Folks --
>
> Here is the text that I propose to put in the guidelines doc
> regarding the OID layout appendix. It will be Appendix D,
> not F, because the former appendices B and C will be put to
> sword (more on that in a forthcoming message).
>
> Anyway, in Section 4.6.5 (formerly 4.6.4), "OID Values Assigned
> to Objects", last paragraph:
>
> Although it is not specifically required by the SMI, it is
> customary
> (and strongly RECOMMENDED) that object definitions not be
> registered
> beneath group definitions, compliance statements, capabilities
> statements, or notification definitions. It is also customary (and
> strongly RECOMMENDED) that group definitions, compliance
> statements,
> capabilities statements, and notification definitions not be
> registered beneath object definitions. See Appendix D for
> a +
> RECOMMENDED OID assignment scheme.
> +
>
> and in Section 4.7, "Notification Definitions", second paragraph:
>
> Although it is not specifically required by the SMI, it is
> customary
> (and strongly RECOMMENDED) that notification definitions not be
> registered beneath group definitions, compliance statements,
> capabilities statements, or object definitions (this last is
> especially unwise, as it may result in an object instance and a
> notification definition sharing the same OID). It is also
> customary
> (and strongly RECOMMENDED) that the OIDs assigned to notification
> types be leaf OIDs (i.e., that there be no OID registrations
> subordinate to a notification definition). See Appendix D
> for a +
> RECOMMENDED OID assignment scheme.
> +
>
> In both cases the last sentence is new. For the new appendix itself
> I propose:
>
> Appendix D: Suggested OID Layout
>
> As noted in RFC 2578 Section 5.6, it is common practice to use the
> value of the MODULE-IDENTITY invocation as a subtree under which
> other OBJECT IDENTIFIER values assigned within the module are
> defined. That, of course, leaves open the question of how OIDs are
> assigned within that subtree. One assignment scheme that
> has gained
> favor -- and which is RECOMMENDED unless there is a specific reason
> not use it -- is to have three separate branches immediately below
> the MODULE-IDENTITY value dedicated (respectively) to notification
> definitions, object definitions, and conformance
> definitions, and to
> further subdivide the conformance branch into separate sub-branches
> for compliance statements and object/notification groups. This
> structure is illustrated below, with naming conventions following
> those outlined in Appendix C. The numbers in parentheses are the
> sub-identifiers assigned to the branches.
>
> xxxMIB
> |
> +-- xxxNotifications(0)
> +-- xxxObjects(1)
> +-- xxxConformance(2)
> |
> +-- xxxCompliances(1)
> +-- xxxGroups(2)
>
> When using this scheme notification definition values are assigned
> immediately below the xxxNotifications node. This ensures
> that each
> OID assigned to a notification definition has a next-to-last sub-
> identifier of zero, which is REQUIRED by Section 4.7 above. The
> other sub-branches may have additional sub-structure, but
> none beyond
> that specified in Section 4.6.5 above is actually required.
>
> One example of a MIB module whose OID assignments follow
> this scheme
> is the POWER-ETHERNET-MIB [PETH-MIB].
>
> Here is the new informative reference:
>
> [PETH-MIB] Berger, Avi and D. Romascanu, "Power Ethernet
> MIB", work in
> progress (currently <draft-ietf-hubmib-power-ethernet-mib-
> 08.txt>).
>
> Please let me know ASAP whether or not this is OK. It is
> preferred that
> you send text if you want to request that something be changed.
>
> Thanks,
>
> Mike
>
>