Advancement of MIB specifications on the IETF Standards Track (RFC2438)
Original Publication Date: 1998-Oct-01
Included in the Prior Art Database: 2019-Feb-11
Internet Society Requests For Comment (RFCs)
M. O'Dell: AUTHOR [+3]
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. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
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 (C) The Internet Society (1998). All Rights Reserved.
The Internet Standards Process  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  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 t...