Re: MIB identification guidance

[Bill Fenner <fenner@research.att.com>]

>   - 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