RE: reviewer guidelines

["Harrington, David" <dbh@enterasys.com>]

I'm not suggesting that we advise other SDOs how to allocate OIDs. 

I think it would be good, for mibs that other SDOs ask the mib doctors
to review, where the OIDs are not in the IETF mib subtree, to suggest
that the SDO put a notice in the mib warning implementers (mainly
application developers) to note that the OID is outside the IETF mib
subtrees, and does not start with 1.3.6.1 as a result.

dbh

> -----Original Message-----
> From: C. M. Heard [mailto:heard@pobox.com] 
> Sent: Tuesday, January 21, 2003 4:14 PM
> To: Mreview (E-mail)
> Subject: RE: reviewer guidelines
> 
> 
> On Mon, 20 Jan 2003, Harrington, David wrote:
> > In general, I don't have a problem with the use of the term
> > "standard" elsewhere. I am concerned about its use in section 4.3
> > because many people make the mistake of thinking all mib objects
> > fall under the 1.3.6.1 subtree.
> 
> I think this concern is easy to address with some minor wording
> changes (mainly adding "IETF" at a few strategic places):
> 
>    RFC 2578 Section 4 describes the object identifier 
> subtrees that are
>    maintained by IANA and specifies the usages for those subtrees.  In
>    particular, the mgmt subtree { iso 3 6 1 2 } is used to 
> identify IETF
>    "standard" objects, while the experimental subtree { iso 3 
> 6 1 3 } is
>    used to identify objects that are under development in the 
> IETF.  It
>    is REQUIRED that objects be moved from the experimental subtree to
>    the mgmt subtree when a MIB module enters the IETF standards track.
> 
>    Experience has shown that it is impractical to move 
> objects from one
>    subtree to another once those objects have seen 
> large-scale use in an
>    operational environment.  Hence any object that is targeted for
>    deployment in an operational environment MUST NOT be 
> registered under
>    the experimental subtree, irrespective of the 
> standardization status
>    of that object.  The experimental subtree should be used only for
>    objects that are intended for limited experimental 
> deployment.  Such
>    objects are typically defined in Experimental RFCs.
> 
> > SNMP has gained wide acceptance, and other SDOs are now developing
> > mibs.  I would like to make sure this is watched for in mib reviews,
> > especially for mib modules developed by other organizations.  For
> > mibs where it is NOT under 1.3.6.1 but does get MIB Doctor review,
> > like the IEEE 802.1x mib, I would like to see that explicitly
> > mentioned in the mib document to help alert application developers
> > to any bad assumptions they may have made in their application.
> 
> It is not entirely clear to me what exactly you think should be
> watched for, or what you want the document to say about reviews of
> MIBS from other SDOs.  I don't think that we've had any trouble in
> the past with other SDOs "stealing" OIDs from the mgmt subtree.  We
> _have_ had problems with misuse of the experimental subtree;  the
> second paragraph was motivated by the recent controversy over RFC
> 2786bis and is supposed to warn people not to allocate OIDs from the
> experimental subtree for MIBs that are destined for operational
> deployment (the MIB module in RFC 2786 could have been registered
> under an enterprise OID assigned to the DOCSIS consortium and the
> document published as an informational RFC).
> 
> I'm very reluctant to have the MIB review document say anything
> about how other SDOs (including industry consortia) should manage
> allocation of OIDs for their SNMP MIBs.  It's true that we recently
> gave the IEEE some advice on what not to do, but I'm not sure that
> the MIB review document should get into that.
> 
> //cmh
> 
>