RE: Where to root MIB modules - descriptors

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

Two things to think about:

1. For the case of Mike's text below:
   > >    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
   > 
   I would prefer  to see them as OID is { vendFizbin 1 }
   I.w. also in the module root OID make it clear it is from vendor "vend"

   ANd I assume you mean that "VEND" gets replaced by the name of the
   actual vendor, no? Same for "vend"

   > descriptors are as in WG draft
   >  
   Doable... I'd rather see them prefixed with "vend"

2. For the allocation under experimental, we have experience with 
   RFC2786. We can consider that RFC more or less as a 
   "stable snapshot" can we not?
   ANd when we suggested they move it to stds track, they are 
   VERY RELUCTANT (I think they are just refusing) to even reroot 
   under mib-2. They want to stay under experimental tree!

   So what does that tell us?

Thanks,
Bert 

> -----Original Message-----
> From: C. M. Heard [mailto:heard@pobox.com]
> Sent: dinsdag 6 januari 2004 1:38
> To: mreview@ops.ietf.org
> Subject: RE: Where to root MIB modules - descriptors
> 
> 
> 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
> 
>