[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: MIB module root assignment
> 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!
>
My M$ email client DOES support HTML. I just find it GARBAGE
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
> > > > >
> > > > >
> > > > >
> > >
> >
> >
>