Hi folks,
This document has now become RFC 2438 / BCP 27 (October 1998).
This will affect Printer MIB revisions, Finisher MIB, and any
other IETF 'standards track' MIBs (eg, the IPP Server MIB
required for the IPP to move to Draft Standard status by
the Internet standards process).
Cheers,
- Ira McDonald
High North
--------------------------------
[From 'ftp://ftp.isi.edu/in-notes/rfc2438.txt']
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.
--------------------------------