Re: MIB module root assignment

["C. M. Heard" <heard@pobox.com>]

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