RE: MIB module root assignment

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

Hmmm,

Why is it that everybody that chooses to use industry-standard
technology, such as HTML-formatted email, has to suffer these constant
complaints from people who refuse to use a standards-compliant mail
client? Why do we have to keep sending mail in a format to make sure it
is compatible with 1960s technology? Get a new HTML-capable client Bert!

dbh

> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] 
> Sent: Friday, September 19, 2003 10:40 AM
> To: 'Glenn Waters'; Mreview (E-mail)
> Subject: RE: MIB module root assignment
> 
> 
> First, WHy is it that so many of you are sending HTML formatted
> email??? Can we not all do just PLAIN text PLEASE!!!
> 
> Inline
> 
> Thanks,
> Bert 
> 
> > -----Original Message-----
> > From: Glenn Waters [mailto:gww@nortelnetworks.com]
> > Sent: vrijdag 19 september 2003 16:35
> > To: Mreview (E-mail)
> > Subject: RE: MIB module root assignment
> > 
> > 
> > I agree with Dave's assessment. I don't agree with his outcome. 
> > I agree with Andy's requirement. 
> > I agree with Bert's comments. 
> >
> > Is there another possible solution? 
> >
> > For example using just 999999 is problematic -- for both the 
> > agent and the manager that may have many of these 999999 
> > branches. Does the branch have to be under mib-2? Could we 
> > have a "developmental" branch and place under that a unique 
> > number. IANA could be the authority to hand out the unique 
> > number under developmental. The IANA process would have to be 
> > real simple and they would have to pretty much say yes to anyone.
> >
> Basically we do have such a thing, and it is called experimental.
> But when people then move from experimental to mib-2, do we then
> require them to rename their modules and descriptors?
> 
> > Thoughts? 
> 
> Another thought is that we just use a fixed "nnn" or "xxx" value and
> that MIB compilers will NOT flag an Error, just a Warning that that
> number needs to still be assigned. Other then that they would just
> compiles as if it was a valid number.
> 
> Bert
> > Regards, /gww 
> > > -----Original Message----- 
> > > From: Harrington, David [mailto:dbh@enterasys.com] 
> > > Sent: Friday, September 19, 2003 10:13 
> > > To: Mreview (E-mail) 
> > > Subject: RE: MIB module root assignment 
> > > 
> > > 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 
> > > > 
> > > > 
> > > > 
> > 
> 
>