Re: MIB module root assignment

[Andy Bierman <abierman@cisco.com>]

At 03:39 PM 9/18/2003, C. M. Heard wrote:
>>>>>> 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.

I don't like the fact that this is illegal SMI and causes
MIB compilers to generate errors.  We want MIB writers
to use SMICng or smilint, and it's confusing to tell them
that for initial MIB modules (i.e., root never assigned)
then ignore these specific errors...but don't ignore 
these errors otherwise.


>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

I think IANA is bright enough to look for whatever pattern
we tell them to look for.  I want there to be one specific
value that is used for this purpose.  Plus I want to stop
editing MIBs to change the 'xxx' to '999999' in order to
compile them!  I think it's obvious that the 999999 is
a bogus number.


>Mike

Andy