Just one little correction to your message. Harald is no longer
Applications Area Direrctor. He moved earlier this year and is now Area
Director for the Operations and Management Area in IETF. So management is
now his primary interest.
See further info at:
http://www.ietf.org/html.charters/wg-dir.html#Operations_and_Management_Area
Carl-Uno
----
At 07:38 PM 8/10/98 PDT, Ira Mcdonald x10962 wrote:
>
>Copies: pmp@pwg.org
> ipp@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.
>
>
>
Carl-Uno Manros
Principal Engineer - Advanced Printing Standards - Xerox Corporation
701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
Phone +1-310-333 8273, Fax +1-310-333 5514
Email: manros@cp10.es.xerox.com