RE: MIB identification guidance

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

W.r.t. "stolen" assignments.

I agree they are sort of stolen. I think it will be too much of an
administrative burdon to ask the secretariat to check such
"stolen assigments" in all I-Ds that are submitted,

Bert

> ----------
> From: 	David T. Perkins[SMTP:dperkins@dsperkins.com]
> Sent: 	Tuesday, January 16, 2001 1:57 AM
> To: 	Bill Fenner; bob.natale@appliedsnmp.com
> Cc: 	sming@ops.ietf.org; iana@iana.org
> Subject: 	Re: MIB identification guidance
> 
> 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
> 
>