RE: reviewer guidelines

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

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