RE: MIB module root assignment

[Andy Bierman <abierman@cisco.com>]

At 07:12 AM 9/19/2003, Harrington, David wrote:
>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.

I'm not being agent-centric.
I'm trying to optimize for the most prevalent case,
not a corner-case.  Why are customers pulling I-D MIBs
into their NMS?  Why optimize for this useless exercise?
I want to optimize for the MIB writers and I-D readers
who just want to check the syntax of a MIB module under 
development.  Why try to make it as painful as possible
to use SNMP?  

BTW, I did not propose { foo 999999 }. I proposed a
single value { mib-2 999999 }.  MIB tools can be
programmed to flag a warning if this special OID
is seen.

Andy



>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
>> 
>> 
>>