RE: Where to root MIB modules - descriptors

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

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