At 01:13 PM 2/11/2003 -0800, C. M. Heard wrote:
>[ in reply to comments/review <draft-ietf-ops-mib-review-guidelines-00.txt> ]
>
>On Fri, 7 Feb 2003, Wijnen, Bert (Bert) wrote:
>> - sect 4.5
>> last sentence of 3rd bullet....
>> are we sure we agree? I have seen trouble with that, even
>> for the RMON MIB space... I cought it in time before
>> we published an RFC, but...
>> Should we at least ask that such registrations are
>> administered by IANA. SO the WG can make them but should
>> get them recorded and documented in the IANA registry.
>> That way... when say 10 years from now, someone wants to
>> add something, they have a central place to check as to
>> what actually has been assigned and what numbers are still
>> available.
>
>Let me reproduce the controversial sentence here:
>
> It is also acceptable for a working group
> to make its own assignments from a subtree
> delegated to it by IANA, provided that adequate
> controls are in place to ensure that such
> assignments are unique.
>
>I put this in because it was my understanding that (a) the RMON
>WG actually does this and (b) they find the practice advantageous
>because assignments can for practical purposes be considered
>finalized once a document is approved, which often precedes
>RFC publication (and thus IANA assignment) by several months.
>
>I guess we ought to put the question to the list, and in
>particular we ought to see what Andy has to say.
There are some advantages:
- MIB root known from early on in the process
- An application can find all RMON related objects
under { mib-2 16 }
There are some disadvantages:
- RMON MIB authors have screwed up the assignments in the
past, causing double assignments for a short time
- Vendors sometimes implement a work-in-progress with the
'real' MIB root assignment, causing conflicts when the
MIB is published as an RFC
- Sometimes a work-in-progress assigned a MIB root is dropped,
leaving a hole in the numbering (not a problem). This has
led to the number being reused for a different module, which
should not have been done.
A bit of history:
IANA assigned { mib-2 16 } for the root of RMON-1, when RFC 1271
was published. This defined { rmon 1 } through { rmon 9 }.
Steve Waldbusser later started the practice of self-assigning
{ rmon 10 } through { rmon N }. Some odd (I think bad) numbering
practices have been used, such as redefining the rmon node
in RMON2-MIB. Later, the RMON-1 module was redone in SMIv2
and its root was assigned as { rmonConformance 8 }. Since
rmonConformance is really { rmon 20 }, this makes the MIB root
lower in the tree than the nodes within the MIB ( rmon 1-9 }.
Summary:
It was probably not the best idea to let the RMONMIB WG
administer its own number space, especially since this WG
has MIB experts in it and still screws up on a regular basis.
I would not recommend that this practice be encouraged for
other WGs.
Andy
>In one recent case that arose in the Hub MIB WG, I (speaking
>as a WG member, not as a MIB reviewer) asked the authors of
>the POWER-ETHERNET-MIB to use an IANA-assigned top-level OID
>instead of picking an unused OID under dot3. I did so because
>the WG didn't have a registry arrangement to ensure that there
>would be no conflicting assignments in the future.
>
>Any other opinions?
>
>Mike