RE: Where to root MIB modules - descriptors

["David T. Perkins" <dperkins@dsperkins.com>]

HI,

What do have described below would work perfectly if:
 1) MIB tools could cope with identical descriptors in
     two MIB modules
 2) support of the <MODULE-NAME>"."<descriptor>
    was available in MIB compilers and tools
 3) all authors and readers of MIB modules understood
    the notation

PS  If I was to add support for module qualified references,
    I would suggest that the "." be replaced by "::",
    and that module names used "."s to make a DNS
    name. That is, IETF MIB modules would be named
    such as IF-MIB.ietf.org. And SNMPinfo MIB modules
    would have form MY-MIB.snmpinfo.com.
    And there would be no IMPORTS. And there
    would be world peace. Oops! sorry I turned
    to the cynical side.

Mike - below is a great explaination - thank you for
adding value to my condensed explaination.

On Mon, 5 Jan 2004, C. M. Heard wrote:
> On Mon, 5 Jan 2004, David T. Perkins wrote:
> > This message is to explain what I meant about descriptors.
> > 
> > I thought you were proposing that OID assignments be given
> > in "stable snapshot" versions of a MIB module that is
> > to start the standards track. That is, do a pre-release(s)
> > of the document so that vendors could ship products.
> > Each stable snapshot would have a different OID root
> 
> OK
> 
> > and according to the rules would also require unique
> > descriptor values.
> 
> Not so.  The only formal requirement in RFC 2578 for
> uniqueness of descriptors is for "standard" MIB modules,
> i.e., those that are rooted within the mgmt subtree:
> 
>    The set of descriptors defined in all "standard"
>    information modules shall be unique.  [Section 3.1]
> 
>    The mgmt(2) subtree is used to identify "standard"
>    objects.  [Section 4]
> 
> The uniqueness requirement does NOT apply to descriptors
> in enterprise modules, nor to stuff in the experimental
> subtree.
> 
> So, what a WG starting on the development of a MIB module
> might do is get a number under the experimental subtree
> from the IANA.  Each pre-release of the module for which it
> was desired to make pilot implementations (i.e., each
> stable snapshot) could  be assigned a root OID subordinate
> to that experimental number.  If there is a need to
> disambiguate the descriptors among the different pre-releases,
> each one would need a different module name.
> 
> When it was felt that it was time to finally publish the final
> spec, then it would be submitted with the final module name
> (different, preferably, from any of the pre-release snapshots) and
> with the customary { mib-2 xxx } -- to be assigned by the IANA
> (or similar) placeholder root OID.  IANA would fill in the
> placeholder at publication time.
> 
> Note that this is exactly what RFC 2578 (sec. 4) says:
> 
>    The experimental(3) subtree is used to identify objects
>    being designed by working groups of the IETF.  If an
>    information module produced by a working group becomes a
>    "standard" information module, then at the very beginning
>    of its entry onto the Internet standards track, the objects
>    are moved under the mgmt(2) subtree.
> 
> So we can now answer the other questions:
> 
> > Consider....
> > 
> > 1) a) WG starts on technical specification containing a MIB module.
> 
> WG gets an number in the experimental subtree from the IANA,
> say fizbinExp OBJECT IDENTIFIER ::= { experimental zzz }
> 
> 
> >    b) WG creates "stable snapshot" for implementation and deployment
> >       testing
> 
> root OID is { fizbinExp 1 }
> 
> module name is FIZBIN-MIB-SNAPSHOT-1
> 
> >    c) WG creates another "stable snapshot"
> 
> root OID is { fizbinExp 2 }
> 
> module name is FIZBIN-MIB-SNAPSHOT-2
> 
> >    d) WG sends document to IESG for entrance to standards track
> 
> root is moved to be under mib-2, transmission, or other place
> under mgmt as appropriate, and would be submitted in the
> usual form, e.g., { mib-2 xxx } -- xxx to be assigned
> 
> The module name is FIZBIN-MIB
> 
> fizbinExp and everything below is RETIRED.
> 
> 
> Case 2 represents the situation today, and here is what I would do:
> 
> > 2) a) WG starts on technical spec
> 
> module name is (say) FIZBIN-MIB
> root OID is unassigned, takes the form { mib-2 xxx }
> 
> >    b) vendor creates a proprietary "stable snapshot"
> 
> vendor allocates fizbinExp from its own tree
> 
> root OID is { fizbinExp 1 }
> module name is VEND-EXP-FIZBIN-MIB-SNAPSHOT-1
> 
> descriptors are as in WG draft
> 
> >    c) WG updates techical spec
> 
> module name is still FIZBIN-MIB
> root OID is still unassigned
> 
> >    d) vendor creates a proprietary "stable snapshot"
> 
> root OID is { fizbinExp 2 }
> module name is VEND-EXP-FIZBIN-MIB-SNAPSHOT-2
> 
> descriptors are as in WG draft
> 
> After publication fizbinExp and below are retired.
> 
> Note that references to the obsolete version of the
> descriptors, if such is needed, can be done via dot
> notation (FIXBIN-MIB-SNAPSHOT-2.zzyzx).  It seems to
> me that it usually wouldn't be needed, since the
> old versions are not supposed to receive wide
> deployment.
> 
> OK, now tell me what's wrong with this picture.
> 
> //cmh
> 

/david t. perkins