Subject: Re: draft-housley-two-maturity-levels-00

From: RJ Atkinson <[email-masked]>
Date: Tue, 22 Jun 2010 06:53:02 -0400

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