RFC 2438 (rfc2438) - Page 2 of 7

Advancement of MIB specifications on the IETF Standards Track

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