Proposed OID layout update text in guidelines doc

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

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