RE: MIB module root assignment

["Harrington, David" <dbh@enterasys.com>]

Hi Andy,

It seems a rather agent-centric view of the world to assume that
problems would only be introduced by implementing the bogus number.
That's not the case however.

A MIB document serves as a contract for use by the agent implementors,
the application implementors, and the application users. Most agent and
application implementors can be expected to understand the details of
MIB documents and do the right thing.

However, it is common for users to have difficulties importing MIBs into
applications due to a lack of understanding of what makes a legal mib.
Support departments often have to deal with customers who try to import
mibs without first stripping them of surrounding text, importig SMIv2
into SMIv1-only applications, trying to import agent-capability "mibs",
or importing the wrong mib revision for the device they are using. 

While the rfc-editor might be smart enough to watch for { mib-2 99999 },
users (and importing applications) are unlikely to be ready for such a
change and are likely to import mib revisions with the bogus number. If
the mib contains {mib-2 xxx} they'll get a warning that what they are
doing is wrong; if it contains {mib-2 99999} then they won't get an
error unless they've already imported another mib with that assignment
in it (and very possibly not even then, since importing an updated mib
often requires ignoring or re-importing known OID assignments).

The current CLR is a pain in the arse only for standard developers and
for those who want to work with pre-RFC internet drafts. For those
working with RFCs, i.e. users and most implementors, the CLR can help to
identify pre-standard (unstable) mib revisions. 

The "flaw" that you see in the current CLR is actually a feature in some
environments. I recommend against changing the current CLR.

Dbh
David Harrington            
dbh@enterasys.com
Director, Network Management Architecture
Office of the CTO, Enterasys Networks



> -----Original Message-----
> From: Andy Bierman [mailto:abierman@cisco.com] 
> Sent: Thursday, September 18, 2003 11:30 PM
> To: C. M. Heard
> Cc: Mreview (E-mail)
> Subject: Re: MIB module root assignment
> 
> 
> 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
> 
> 
>