Browse Prior Art Database

Advancement of MIB specifications on the IETF Standards Track (RFC2438)

IP.com Disclosure Number: IPCOM000003016D
Original Publication Date: 1998-Oct-01
Included in the Prior Art Database: 2019-Feb-11
Document File: 7 page(s) / 9K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

M. O'Dell: AUTHOR [+3]

Related Documents

10.17487/RFC2438: DOI

Abstract

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.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 27% of the total text.

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 t...

Processing...
Loading...