[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: MIB module root assignment
>>>>> On Thu, 18 Sep 2003, Andy Bierman wrote:
Andy> I would like to get feedback from this group on a proposal
Andy> before taking it to a larger audience.
Andy>
Andy> Problem:
Andy>
Andy> The MODULE-IDENTITY macro (MIB root assignment) contained
Andy> in a MIB module should be assigned by IANA when the RFC
Andy> containing the MIB module is published. During the I-D
Andy> development, the MIB module root assignment is done in an
Andy> ad-hoc manner. This practice has led to confusion and poor
Andy> procedures, e.g.:
Andy> - WG controlled naming authorities { rmon 30 }
Andy> - invalid SMI syntax in MIBs under development { mib-2 xxx }
Andy> - random (unauthorized) temporary MIB roots { mib-2 6767 }
Andy>
Andy> It is desirable to provide a consistent temporary MIB module
Andy> root which will not require any changes to existing MIB compiler
Andy> tools, and is easily identifiable as a temporary MIB module
Andy> root.
Andy>
Andy> Proposed Solution:
Andy>
Andy> Ask IANA to assign the OID { mib-2 999999 } as the
Andy> official temporary MIB module root. Update the MIB Review
Andy> Guidelines and MIB module template to mandate that
Andy> MIB modules under development use this IANA assigned
Andy> temporary MIB module root.
Andy>
Andy> Comments?
>>>>> On Thu, 18 Sep 2003, Wijnen, Bert (Bert) replied:
Bert> And REQUIRE (i.e. a MUST) that MIB documents under development
Bert> use something aka:
Bert>
Bert> ::= { mib-2 999999 } -- 999999 to be replaced by an IANA assigned
Bert> -- value. Be WARNED to NOT use this value for
Bert> -- shipping any product (not even beta level).
In my opinion, the fact that { mib-2 xxx } and similar placeholder
constructs are invalid SMI syntax and fail to compile is a
_feature_, not a bug. Here's what I said when this topic was
discussed several months ago:
>>>>> Mon, 24 Feb 2003 C. M. Heard wrote:
C> I see the non-compilability of { mib-2 xxx } and friends as a
C> feature, not a bug. It makes it clear that proper number has not
C> been allocated and that the stuff in the module can be changed
C> arbitrarily. Putting in a temporary replacement for compilation
C> purposes is is not so hard. Indeed, the fact that you don't have to
C> do that with real OIDs that will later need to be changed makes it
C> easy to miss the change when it does come. That comment applies
C> equally to { mib-2 999999 } IANA-allocated experimental nodes.
See http://ops.ietf.org/lists/mreview/mreview.2003/threads.html#00290
for the thread where this issues was last discussed. The excerpt above
is from http://ops.ietf.org/lists/mreview/mreview.2003/msg00304.html
I haven't changed my opinion, and I still think that something like
{ mib-2 xxx } or { transmission xxx } or even { rmon xxx } is the way
to go for drafts that are not yet stable. So I'd prefer not to
adopt Andy's proposal.
One issue that was not discussed in our earlier thread on this topic
is the fact that the RFC Editor and IANA staff are sensitively "tuned"
to look for things like { mib-2 xxx } and know exactly what to do
with them (to the point where RFC 2493bis -- now RFC 3593 -- was for
a while erroneously held up for IANA action on account of such
constructs in some ASN.1 comments). If we change to { mib-2 999999 }
we will need to make VERY SURE that the RFC Editor and IANA are
"re-tuned", and we'll need to update http://www.ietf.org/ID-nits.html
Mike