IPP> RFC 2438 - Advancement of MIB specs on IETF Standards Track

IPP> RFC 2438 - Advancement of MIB specs on IETF Standards Track

Ira Mcdonald x10962 imcdonal at eso.mc.xerox.com
Tue Oct 27 12:42:50 EST 1998


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.

--------------------------------




More information about the Ipp mailing list