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