>From ipp-owner at pwg.org Tue Aug 11 15:43:30 1998
Date: Mon, 10 Aug 1998 19:38:59 PDT
From: imcdonal at eso.mc.xerox.com (Ira Mcdonald x10962)
Message-Id: <9808110238.AA00864 at snorkel>
To: ipp at pwg.org, pmp at pwg.org
Subject: IPP> Draft Standard MIB rules from IESG
Sender: owner-ipp at pwg.org
Copies: pmp at pwg.orgipp at pwg.org
Hi Printer MIB folks and Carl-Uno, Monday (10 August 1998)
Thanks to Carl-Uno Manros for pointing out these new IESG rules for MIB
advancment I-D to us all. I just read them. They can be faithfully
summarized as follows:
* For a MIB to advance to Draft Standard status it must be able to be
proved that there are two independent implementations (ie, two SNMP
clients/managers and two matching SNMP devices/agents) yielding 'MIB
dumps' with IDENTICAL types and plausible values for EVERY object
specified in the MIB, including ALL optional objects.
For the revised Printer MIB to advance to a Draft Standard status, it
must be proven that there are two such interoperable implementations in
existence (product quality, not merely prototypes) of every object in
the new Printer MIB draft text (including new objects recently added).
Are two vendors willing to step forward with such implementations of
EVERY object in the new Printer MIB draft text? This is the current
IESG hurdle and they are serious about it (see excerpts below). Note
that our Applications Area Director (Harald Alvestrand) is one of the
co-authors of this I-D.
Cheers,
- Ira McDonald (High North Inc)
>----------------------------------------------------------------------<
Network Working Group Mike O'Dell
Internet-Draft UUNET Technologies
Harald T. Alvestrand
Maxware
Bert Wijnen
IBM T. J. Watson Research
Scott Bradner
Harvard University
August 1998
Advancement of MIB specifications on the IETF Standards Track
<draft-iesg-odell-mibtest-01.txt>
[...]
3. The Nature of the Problem
The Internet Standards Process [1] requires that for a 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.
[...]
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 interoperability that strikes a balance between
testing complexity and practicality.
[...]
5. Discussion and Recommended Process
[...]
Therefore, the Operations and Management Area and the IESG have
adopted a more pragmatic approach to determining the suitability of a
MIB specification for advancement on the standards track beyond
Proposed Standard status. Each MIB specification suggested for
advancement must have one or more advocates who can make a convincing
argument that the MIB specification meets the multiple implementation
and feature support requirements of the IETF Standards Process. The
specific way to make the argument is left to the advocate, but will
normally include reports that basic object comparison testing has
been done.
[...]
The implementation report will be placed on the IETF web page along
with the other pre-advancement implementation reports and will be
specifically referred to in the IETF Last-Call. As with all such
implementation reports, the determination of adequacy is made by the
Area Director(s) of the relevant IETF Area. This determination of
adequacy can be challenged during the Last-Call period.
[...]
A.1 Basic Object Comparison
Assume the requisite two genetically unrelated implementations of
the MIB in an SNMP agent and an SNMP management station which can
do a "MIB Dump" (extract the complete set of MIB object types and
values from the agent implementation). Extract a MIB Dump from
each implementation and compare the two dumps to verify that both
provide the complete set of mandatory and optional objects and
that the individual objects are of the correct types.