> My own, primary concern about them is having an "experimental" header
> become a defacto standard and then having to find a way to get folks to
> use a new, non-X header name for it. I believe that hasn't been
> successful yet, or at least not much.
why does it work better in the case of Experimental vs Standard MIBs?
(or do you think that doesn't work well either?)
First, I don't know that it works better. I suspect it does not, and that once
an experimental MIB is in use it is very difficult to get rid of it. Indeed, if
such transitions worked well, why isn't the accepted practice for MIBs
developed in the IETF to assign an experimental OID during development and
switch to a standard one after IESG approval? It sure isn't done this way -
what happpens in practice is that there is NO OID assigned in the document
until after it is approved.
But even if this approach worked well for MIBs, the cases aren't even remotely
comparable. The difference between a MIB registered in the experimental space
and a MIB registered in the standards space is simply the OID prefix. That's
almost certainly something you can configure on a management station and in
some cases on the agent side as well. I don't believe I've ever seen a mail
system component with comparable flexibility in regards to header fields.
Additionally, nobody runs around, management station in hand, and tries to
access random agents on the network. (Well, perhaps people actually do do this,
but I'll bet that when they do they are crackers and are more interested in
exploiting one of the many ASN.1 parser buffer overrun bugs than in performing
any sort of useful management function.) Agents and managements stations tend
to be operated by people in the same administrative domain and a given agent
is likely to only be probed by a small number of management stations. (I'm
confident the most common number is 0, then 1, with numbers greater than 1 a
very distant third.) This means that OID mismatches present a trivial
problem compared to header field mismatches.
Finally, anyone who thinks SNMP isn't bothered by interop problems of various
sorts hasn't spent much time using it. As it happens I have (a) Developed
standards-track MIBs, (b) Written both agent code and agent plugin code, (c)
Written management station plugins, and (d) Use a fairly sophisticated SNMP
monitoring setup to keep tabs on my home network. And I've run into plenty of
problems along the way, including but not limited to: Lack of specificity in
widely used standard MIBs causing interop problems, experimental MIBs
constructed in extremely bizarre ways that are very difficult to build probes
for (if anyone knows how to construct a probe that's able to see Mac OS X
systems connected to an original series Apple Airport please let me know),
plugin architectures that are inherently incompatible with the design of some
MIBs, and fun and games with row creation. And then there's Agent X. You don't
want to get me started on that...
Ned
P.S. An interesting test will be to see if once CAPWAP gets going whether
it can produce standard MIBs to replace the experimental MIBs in use
in existing wireless products. I am not optimistic.