RE: MIB identification guidance

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

I suggest that if there is no need to actually use a experimental
assignment,
then DO NOT do it. In the I-D, use this notation (using mib-2 as an
example):

  ::= { mib-2 xxxx } -- xxxx to be assigned by IANA

A document does enter the "standards track" when the IESG approves
it as a PS (proposed standard). The actual assignment happens just
before the RFC is published.

We (IESG) do normally not accept a document (MIB) as PS with a MIB
assigned under the experimental tree.

Bert

> ----------
> From: 	Bob.Natale@AppliedSNMP.com[SMTP:Bob.Natale@AppliedSNMP.com]
> Sent: 	Tuesday, January 16, 2001 12:24 AM
> To: 	sming@ops.ietf.org
> Subject: 	MIB identification guidance
> 
> Hi,
> 
> What is the current thinking/practice re the following text from RFC2578:
> 
>    "The mgmt(2) subtree is used to identify "standard" objects.
> 
>    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."
> 
> It seems there may be a fair degree of variability still in how MIBs
> defined in I-Ds (pre standards track RFCs) from WGs are identified, e.g.:
> 
>    - mib-2 nnnn           // "nnnn" is some numerical value
>    - mib-2 XXX            // "XXX" is "XXX"
>    - experimental nnnn    // "nnnn" is some numerical value
> 
> What is the definition of *when* "an information module produced by a
> working group becomes a 'statndard' information module"...at PS RFC stage?
> 
> Thanks,
> 
> BobN
> 
>