Re: draft-klensin-iana-reg-policy (Re: S stands for Steering)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I agreed with almost all of your arguments on this topic, until this:

> As far as history goes, and the OID tree - do remember that the OID tree
> has vendor space, in which anyone can trivially register anything.
> Once there, the OID is just as good as any other OID.
> 
> The Vendor space gets used two ways - one is to actually identify
> vendors, and their products (etc).   For that it is just fine.
> 
> The other is for vendor private MIB variables - for that I (with
> hindsight, naturally) believe it has been a failure.   All it does
> is require data to be sought in multiple different places, depending upon 
> which vendor's equipment is being managed.  Certainly, some of what is
> there is truly vendor specific information, but much of it is just
> general data that could have been in the standard MIB, but either
> wasn't considered, or someone thought it a poor idea.   Yet the
> customers apparently want it, so into the vendor private MIB it goes.

On the contrary, having vendor OID space has been a tremendous success.
Despite all the IETF's work in defining MIBs, there are many, many areas
of technology for which no standard MIBs exist.  It's impossible for the
IETF to standardize everything; if vendors didn't have their own OID space,
then the use of MIBs would be limited, would not be nearly as ubiquitous
as it is, and therefore less valuable.  Even those areas in which the IETF
does specify standard MIBs, the time taken by the IETF process gets
longer and longer as the years go by; if vendors had to wait until the
IETF published a MIB in an RFC(*), MIBs would be so late, that they
would be even more of an afterthought than they already are -- network
management suffers on those occasions when devices don't have
management support from day-1; if vendors didn't have their own space
such suffering would necessarily happen *all* the time.  Using OID
space has allowed other SDOs (e.g., IEEE, ATM Forum, etc.) to define
their own MIBs, which has also been a success.

(*) Bad experiences often occur when implementing MIBs based on I-D's,
because I-D's are not permanent and do not have change control to prevent
illegal changes.  The only way to ensure that an implementation of a
MIB, specified in an I-D, will still be valid 6 months later is for a
vendor to copy the MIB into the vendor's private OID space so that the
vendor has change control.

> The IETF may have tried to control MIB contents using registration
> control, but at that it failed miserably.   That isn't surprising,
> it is a tool not suited to the task.

No and yes.  The IETF did not try for such control, because such
control would have failed in many cases, precisely because the tool is
not suited to the task.  Many vendors would have found other ways to
have OIDs -- exactly as you are suggesting they would find other ways
to have option codepoints.

Keith.

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]