[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
> > >
> > >
> > >
>