Re: MIB module root assignment

[Andy Bierman <abierman@cisco.com>]

At 06:42 PM 9/18/2003, C. M. Heard wrote:

I'm just trying to replace a flawed CLR with a better CLR.
I don't agree that putting syntax errors in a MIB under
development is a good idea.  I don't like CLRs that are
meant to protect the MIB reader from themselves, assuming
the readers are too stupid to do the right thing without our help.
If a vendor implements an I-D, they deal with the consequences.
Keeping the real MIB root a secret until the RFC is published
is just another CLR of this type. 

I don't care that much if this CLR doesn't change.  Hopefully,
this won't happen with XML, especially since XML uses a
meaningful naming hierarchy instead of a random hierarchy.

Andy


>On Thu, 18 Sep 2003, Andy Bierman wrote:
>> 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.
>
>FWIW, the guidelines doc does not tell people to ignore MIB
>compilation errors.  It tells them to temporarily replace XXX
>with an actual number:
>
>   When the initial version of a MIB module is under development, the
>   value assigned to the MODULE-IDENTITY descriptor will be unknown if
>   an IANA-assigned value is used, because the assignment is made just
>   prior to publication as an RFC.  The accepted form for the MODULE-
>   IDENTITY statement in draft versions of such a module is something
>   along the following lines:
>
>      <descriptor> MODULE-IDENTITY
>
>          [ ... ]
>
>          ::= { <subtree> XXX }
>   -- RFC Ed.: replace XXX with IANA-assigned number & remove this note
>
>   where <descriptor> is whatever descriptor has been selected for the
>   module and <subtree> is the subtree under which the module is to be
>   registered (e.g., mib-2 or transmission).  Note that XXX must be
>   temporarily replaced by a number in order for the module to compile.
>
>> >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.
>
>I agree that we can get the RFC Editor and the IANA to do what we
>want; I am just reminding everyone that we need to make it VERY
>CLEAR to them if we change the existing well-understood procedures.
>
>I don't agree about not editing MIB modules to change the 'xxx' to
>'999999' -- I _do_ like that, because it makes it painfully obvious
>to anyone using the MIB module that it's not yet ready for
>implementation and deployment.  It's true that '999999' (or '6969'
>or '777') is pretty obviously bogus ... to the persons who looks for
>it.  It won't be obvious to the person who just extracts the MIB module
>and compiles it.
>
>Incidentally, another thing that we would need to do if we use a
>dummy number like '99999' instead of a non-number like 'xxx' would
>be to train MIB document authors to check during the AUTH48 process
>that the dummy number has been replaced.  That's more-or-less
>automatic now, since a failure to replace an 'xxx' would result in
>a compilation failure.
>
>Mike