RFC 2438 (rfc2438) - Page 2 of 7
Advancement of MIB specifications on the IETF Standards Track
Alternative Format: Original Text Document
RFC 2438 Advancement of MIB specifications October 1998
The second reason is to discourage excessive options and "feature
creep". This is accomplished by requiring interoperable
implementation of all features, including options. If an option is
not included in at least two different interoperable implementations,
it is safe to assume that it has not been deemed useful and must be
removed before the specification can advance.
In the case of a protocol specification which specifies the "bits on
the wire" exchanged by executing state machines, the notion of
"interoperability" is reasonably intuitive - the implementations must
successfully "talk to each other", exchanging "bits on the wire",
while exercising all features and options.
In the case of an SNMP Management Information Base (MIB)
specification, exactly what constitutes "interoperation" is less
obvious. This document specifies how the IESG has decided to judge
"MIB specification interoperability" in the context of the IETF
Standards Process.
There are a number of plausible interpretations of MIB specification
interoperability, many of which have merit but which have very
different costs and difficulties in realization.
The aim is to ensure that the dual goals of specification clarity and
feature evaluation have been met using an interpretation of the
concept of MIB specification interoperability that strikes a balance
between testing complexity and practicality.
4. On The Nature of MIB specifications
Compared to "state machine" protocols which focus on procedural
specifications, a MIB specification is much more data oriented. To
over-generalize, in a typical MIB specification the collection of
data type and instance specifications outnumbers inter-object
procedural or causal semantics by a significant amount.
A central issue is that a MIB specification does not stand alone; it
forms the access interface to the instrumentation underneath it.
Without the instrumentation, a MIB has form but no values. Coupled
with the large number of objects even in a simple MIB specification,
a MIB specification tends to have more of the look and feel of an API
or a dictionary than a state machine protocol.
It is important to distinguish between assessing the interoperability
of applications which may use or interact with MIBs, and the MIBs
themselves. It is fairly obvious that "black-box testing" can be
O'Dell, et. al. Best Current Practice