Tom
At 19:38 08/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.
I don't read it that there must be two implementations that implement
all OPTIONAL objects. Just that for each OPTIONAL object there must
be at least two implementations that support it. If only 0 or 1
implementations implement the OPTIONAL object, the OPTIONAL object must
be deleted from the standard before it can progress from proposed to draft.
So if there are four implementations: A, B, C, and D, and two optional
objects: 1 and 2, if A and B implement 1 and C and D implement 2, then
both optional objects can remain in the draft standard.
Unfortunately, the document offers no justification for this rule,
except to avoid "functionality creep". Thus, the IESG sees standards
as forcing implementations into a static set of features, namely the
ones that are implemented by the time the standard progresses to draft
standard. I see no justification that MIBs, especially, should follow
such a static product development model.
I believe that your interpretation that two agents/devices and two
clients/managers makes sense, though the document never says that is
what they mean by two implementations. Only counting one agent/device
and one client/manager as two implementations doesn't seem to be what
real interoperability could mean. But they need to clarify their
document.
>
>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.
So I think we only need to take each optional group separately and find two
vendor products that implement them. If there is an optional group that
only 0 or 1 products from different "genetics" (i.e., different code bases,
not necessarily from different vendors), then that group should be deleted
in the draft standard.
Should we forward this dicussion to the authors?
Tom
>
>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.
I think you mis-read Appendix A. I read it as rejected alternatives
for the testing requirements. So a "MIB Dump" is NOT required for
the interoperability testing.
Unfortunately, they don't give any reasons for the rejected alternatives
in the Appendix either.
>
>
>