Advancement of MIB specifications on the IETF Standards Track
RFC 2438

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 01

Network Working Group                                          M. O'Dell
Request for Comments: 2438                            UUNET Technologies
BCP: 27                                                    H. Alvestrand
Category: Best Current Practice                                  Maxware
                                                               B. Wijnen
                                               IBM T. J. Watson Research
                                                              S. Bradner
                                                      Harvard University
                                                            October 1998

     Advancement of MIB specifications on the IETF Standards Track

Status of this Memo

   This document specifies an Internet Best Current Practices for the
   Internet Community, and requests discussion and suggestions for
   improvements.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

2. Abstract

   The Internet Standards Process [1] requires that all IETF Standards
   Track specifications must have "multiple, independent, and
   interoperable implementations" before they can be advanced beyond
   Proposed Standard status.  This document specifies the process which
   the IESG will use to determine if a MIB specification document meets
   these requirements.  It also discusses the rationale for this
   process.

3. The Nature of the Problem

   The Internet Standards Process [1] requires that for an IETF
   specification to advance beyond the Proposed Standard level, at least
   two genetically unrelated implementations must be shown to
   interoperate correctly with all features and options. There are two
   distinct reasons for this requirement.

   The first reason is to verify that the text of the specification is
   adequately clear and accurate.  This is demonstrated by showing that
   multiple implementation efforts have used the specification to
   achieved interoperable implementations.

O'Dell, et. al.          Best Current Practice                  [Page 1]
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                  [Page 2]
RFC 2438           Advancement of MIB specifications        October 1998

   applied to such applications and that the approach enjoys a certain
   maturity in the software engineering arts.  A MIB specification, on
   the other hand is not readily amenable to black box test plans.