Earlier, Mike StJohns wrote: > One side note - MIBs. > > MIBs by their nature are actually collections of mini-standards > - the objects. Once an object is defined and published in a > non-transitional document (RFC), the OID associated with that > object is pretty much stuck with that definition. And that > permanence tends to percolate up to the collection of objects > that make up a MIB. > > I'd suggest only a single standards level for a MIB - stable - > tied to a specific conformance statement. Obviously, this is > sort of a sketch of an idea, but given the immutability of each > MIB object, advancing a MIB is pretty much impossible unless > there are absolutely no changes. NOTE WELL: I would rather adopt draft-housley-two-maturity-levels quickly than delay it to add special text for MIBs. That noted, I think that it isn't terribly meaningful to talk about interoperable MIBs. One can test whether a device lets an SNMP client walk a particular MIB, and one can test whether the SNMP agent inside that device returns an in-range value for a given object. For example, the DOCSIS RF MIB has some objects that return a SNR or a power level. As near as I can tell, no one has verified that if the SNR is claimed to be numeric value N dBmv that the actual measured SNR in a test environment is also N dBmv. However, it is either very difficult or impossible to test whether that SNMP agent is accurately reporting the current value of many objects defined for MIBs. So MIBs probably ought to be handled differently by the standards process. I could see publishing all MIBs as BCPs, for example, or as Mike suggests publishing them directly at some other terminal level. Yours, Ran _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf