Re: MIB identification guidance

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

HI,

This issue keeps recurring. The tension is between stability and
testing to see if viable. Unfortunately, it seems that when an
experimental OID is provided and testing is successfully done,
then there is a BIG reluctance to change the implementations.
So, I believe that the best approach is to not provide an OID
in the experimental branch unless the OID will stay experimental.
And to only provide an OID under a standards branch when the
document has been approved by the IESG.

In the use of OID values below, there are examples of "stolen"
assignments. This is pretty bad, and the I-Ds should not be allowed
to be posted in the I-D directory that have stolen assignments.

Thanks for the list Bill!

Regards,
/david t. perkins

At 03:59 PM 1/15/2001 -0800, Bill Fenner wrote:

>>   - mib-2 nnnn           // "nnnn" is some numerical value
>>   - mib-2 XXX            // "XXX" is "XXX"
>>   - experimental nnnn    // "nnnn" is some numerical value
>
>And note that for both instances of "nnnn", many uses are of
>unassigned values, e.g.
>
>diffPolicyMib=mib-2.22222222
>diffServMib=mib-2.12345
>l2tp=experimental.9999.1
>dpnssMib=transmission.999
>
>(see http://www.aciri.org/fenner/mibs/mib-index.html column 4)
>
>>What is the definition of *when* "an information module produced by a
>>working group becomes a 'statndard' information module"...at PS RFC stage?
>
>When it's approved by the IESG.  (It used to be when it was published
>by the RFC-Editor, but since there's no technical reason to let the
>RFC-Editor's document queue get in the way, now the IANA assigns a
>mib-2 OID when the IESG approves the document for publication).
>
>
>The issue of what to use in documents under development came up on the
>mibs@ops.ietf.org list some time ago; the consensus seemed to be to
>get an experimental OID early on and use it; switch to mib-2 when it's
>published as PS; leave transition up to the agent/manager implementors
>to figure out.
>
>Another problem that bit us when finally publishing the IPMROUTE-MIB as a
>standard was that we got a lot of pushback on changing the top-level OID
>while keeping the module name the same.  We ended up renaming the module
>to IPMROUTE-STD-MIB and the top-level descriptor to ipMRouteStdMIB.
>
>  Bill