RE: Where to root MIB modules

["Harrington, David" <dbh@enterasys.com>]

Hi,

For rmon-related modules, do we continually ask IANA for the mib
assignments under rmon, or is the rmon wg empowered to make those
subordinate assignments?

I ask this because I have a growing concern about CLRs in the IETF
process, especially for mibs. I am finding it harder and harder to
recruit editors from my engineering staff to do IETF work because so
much of document editing has now become dotting the i's and crossing the
t's to meet a myriad of CLRs (nits) in IETF document preparation. 

Many of these CLRs do nothing to help vendors ship product quickly, or
improve interoperability; they merely help the IESG review documents
faster, and the rfc-editor publish them faster. While these are laudable
goals, there reaches a point where using a proprietary mib benefits a
vendor more than waiting for the IETF process. Programmers typcially do
not use text layout languages like nroff in their day-to-day work, and
having to learn languages like this just to edit IETF documents
increases the entry costs for recruited personnnel, costs engineering
managers don't want to have to absorb. I think recducing the CLRs
associated with mib publication would be a good thing.

Most standards-track protocols from various SDOs go through many
revisions, and vendors often release pre-standard implementations with
the caveat that the implementation will change when the standard is
ratified. This helps to build interest in a protocol, and helps to
develop some experience with the protocol before it is cast in stone.

If we assign an OID to a working group, and then they are empowered to
assign the mib module OIDs under that assignment, that would make it
slightly simpler to get a module published and, more importantly, have
compilable pre-standard mibs made available in a timely manner, with the
caveat that implementations should change to match the standard when
(and if) the standard is ratified.

I think allowing a wg to assign the oids for their mibs, in a controlled
manner, might be a good thing to consider.

dbh

> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] 
> Sent: Sunday, January 04, 2004 6:41 AM
> To: Mreview (E-mail)
> Subject: Where to root MIB modules
> 
> 
> MIB-Doctors,
> 
> First a happy, prosperous and healthy new year to all of you!
> 
> Mike Heard and I had a little side discussion when Mike
> ran into a practice in PWE3 MIB documents.
> 
> The questionable (?) practice is that some WGs or Technologies
> are requesting (I will use a well known example here):
> 
>        rmon    OBJECT IDENTIFIER ::= { mib-2 16 }
> 
> And then we keep requesting assignments for RMON related modules 
> under rmon.
> 
> The MPLS WG has done a similar thing for a set of MPLS related MIB
> modules, where they have:
> 
>           mplsStdMIB OBJECT IDENTIFIER
> 
>           -- This object identifier needs to be assigned by IANA.
>           -- Since mpls has been assigned an ifType of 166 we 
> recommend
>           -- that this OID be 166 as well, e.g.
>           --   ::= { transmission 166 }
> 
>           ::= { transmission XXX }  -- to be assigned by IANA
> 
> and then they root their various MIB modules under mplsStdMIB.
> 
> PWE3 seems to want to go down the same path.
> 
> The question that is on the table is:
> 
>   Should we (MIB Doctors)
>    - discourage this practice (admitting that rmon and mplsStdMIB were
>      mistakes) and instead recommend to assign directly under mib-2
>      or transmission?
>    - encourage this practice because it is a good way to group 
>      related modules together?
>    - just leave it to the various WGs and accept the way they choose
>      to root their MIB modules?
>    
> Comments and arguments for or against various options are sollicited.
> 
> Thanks 
> Bert
> 
>