PMP Mail Archive: PMP> The Goal is Draft Standard

PMP Mail Archive: PMP> The Goal is Draft Standard

PMP> The Goal is Draft Standard

Chris Wellens (
Mon, 23 Dec 1996 19:20:34 -0800 (PST)

Here is one long email intended to answer several questions
arising over the past two weeks on the mailing list. Consider
this an ex cathedra communication.

The stated goal of the Printer MIB Working Group is to
advance from "Proposed Standard" to "Draft Standard".

In order to achieve this goal, we need the following:

(1) The revised draft must include a list of the
substantive changes to RFC1759 and the justification for
each change (the changes *must* be for clarification and
correction, they *cannot* be new features).

(2) A comprehensive report on the implementation
experiences demonstrating/proving interoperability.

As soon as these two criteria are satisfied, the Chair
can make the recommendation to the Area Director and
the IESG that the "Proposed Standard" be advanced to
"Draft Standard".

Our status:

In the case of (1) above, I sent out an email with the
subject line "Change Document" on Monday 12/9/96. It
was distributed at the IETF meeting and feedback
requested. So far, only Tom Hastings has pointed out
some missing items. We need to get more feedback and
agreement that we have a correct document.

Without a correct document, the interoperability
testing cannot go forward, because we don't know what
we are testing; we actually have two specs, not one,
and lack a clear statement as to the differences.

The deadline to get this done is now 1/13/97.

In the case of (2) above, there are numerous ways of
getting a comprehensive report on the implementation

(2a) all of the implementations could be
sent to an independent lab that could run a
set of tests and publish a report (UNH, LanQuest ...)

(2b) all of the implementors could get
together, run a set of tests against their
implementations and discuss how the spec
should be changed as a result

(2c) an independent consultant with expertise
in SNMP MIBs could run a set of tests against
each implementation, provide the results and
make recommendations

(2d) various permutations and combinations of
the above

While the Portland Bake-Off seems to have been a
positive experience for many, it did not satisfy (2)
above. If it *had* provided a comprehensive report on
implementation experiences, then RFC1759 would already
be advanced.

The next effort has to be planned and designed to achieve (2)
above. So far we have been converging on (2b), with some
outstanding issues:

(3) Non-Disclosure. There seems to be a lot of confusion on
this. The goal is to keep the specific test results of a given
company's product confidential, not to keep everything

We should be discovering problems from the tests results, such as "four
printers implemented prtFooBar this way, and two printers implemented
prtFooBar another way." Then we have some discussions, and from the
discussions we figure out how to clarify the information around
prtFooBar in the draft. Obviously we do not keep all the results
confidential, since then we would not be able to have these

I know some of you are concerned that your company will not sign
a non-disclosure agreement. Some of you are unaware that your
company, has in fact, already signed such an agreement with
InterWorking Labs in another division for this same kind of
testing. The non-disclosure agreement is at

(4) Not enough activity on the mailing list. I've noticed that
some implementation experience has been posted to the mailing
list with requests for feedback and comments. None seems to be
forthcoming. I do not know why this is the case. We should be
trying to resolve these corrections and clarifications on the
email list in lieu of the face to face meetings.

(5) Everyone who attends will be a test engineer for three days.
Remember that the guiding principle of the IETF is "rough consensus and
running code". Talk is cheap; running code is not. If you do not have
a printer with RFC1759 implemented, we will help you borrow one. We
want the communication and discussion about what is broken and needs to
be fixed in RFC1759 to directly arise from the testing

Finally, I am sure that not everyone is going to like everything in
this email. Rather than nitpick on the style and the process of
what we have to do, I would ask that you nitpick on the
implementation experience of RFC1759. Let's continue to find
and suggest fixes to the errors and ambiguities found therein,
and focus on what we can do to demonstrate/prove

Have a happy holiday!