No subject

No subject

No subject

imcdonal at imcdonal at
Tue Aug 11 11:49:05 EDT 1998

>From ipp-owner at Tue Aug 11 15:43:30 1998
Date: Mon, 10 Aug 1998 19:38:59 PDT
From: imcdonal at (Ira Mcdonald x10962)
Message-Id: <9808110238.AA00864 at snorkel>
To: ipp at, pmp at
Subject: IPP> Draft Standard MIB rules from IESG
Sender: owner-ipp at

Copies: pmp at
        ipp at

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.

- Ira McDonald (High North Inc)


Network Working Group                                        Mike O'Dell
Internet-Draft                                        UUNET Technologies
                                                    Harald T. Alvestrand
                                                             Bert Wijnen
                                               IBM T. J. Watson Research
                                                           Scott Bradner
                                                      Harvard University
                                                             August 1998

     Advancement of MIB specifications on the IETF Standards Track


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.

More information about the Ipp mailing list