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: 2000-Sep-13
Document File: 8 page(s) / 13K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

M. O'Dell: AUTHOR [+4]

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.

This text was extracted from a ASCII document.
This is the abbreviated version, containing approximately 22% 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.

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", exchangin...