Advancement of MIB specifications on the IETF Standards Track
RFC 2438
Document | Type |
RFC - Best Current Practice
(October 1998; No errata)
Also known as BCP 27
Was draft-iesg-odell-mibtest (iesg)
|
|
---|---|---|---|
Authors | Michael O'Dell , Harald Alvestrand , Bert Wijnen , Scott Bradner | ||
Last updated | 2013-03-02 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 2438 (Best Current Practice) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
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.Show full document text