Hi Carl, Tuesday (11 August 1998)
The new I-D updates (NOT replaces) the IETF Internet Standards Process
(RFC 2026, S. Bradner, October 1996) which states the two implementations
requirement on page 3:
In general, an Internet Standard is a specification that is stable
and well-understood, is technically competent, has multiple,
independent, and interoperable implementations with substantial
operational experience, enjoys significant public support, and is
recognizably useful in some or all parts of the Internet.
And on page 13:
4.1.2 Draft Standard
A specification from which at least two independent and interoperable
implementations from different code bases have been developed, and
for which sufficient successful operational experience has been
obtained, may be elevated to the "Draft Standard" level. For the
purposes of this section, "interoperable" means to be functionally
equivalent or interchangeable components of the system or process in
which they are used. If patented or otherwise controlled technology
is required for implementation, the separate implementations must
also have resulted from separate exercise of the licensing process.
Elevation to Draft Standard is a major advance in status, indicating
a strong belief that the specification is mature and will be useful.
The requirement for at least two independent and interoperable
implementations applies to all of the options and features of the
specification. In cases in which one or more options or features
have not been demonstrated in at least two interoperable
implementations, the specification may advance to the Draft Standard
level only if those options or features are removed.
The key phrase is "operational experience". In all of the Internet
standards process BCPs (Best Current Practices), the term "operational"
means "in live networks".
Also, standards which reach the Draft Standard status are NOT supposed
to be volatile (ie, subject to future change). Draft Standard status
is meant to be a short holding period before Internet (Final) Standard
status is granted. This is why I have long argued (unsuccessfully) that
the new Printer MIB text should NOT be advanced to Draft Standard status
without widespread implementation by software and hardware vendors.
If we put something in the Draft Standard Printer MIB we later regret,
it must be kept forever for backwards compatibility. There is NO
precedent for a Draft Standard MIB ever making a change that breaks
backwards compatibility. The PWG doesn't get a vote on this one.
Cheers,
- Ira McDonald (High North Inc)
>------------------------------------------------
>[Carl's note]
>Date: Tue, 11 Aug 1998 08:20:42 PDT
>From: "Carl Kugler" <kugler at us.ibm.com>
>Subject: Re: IPP> Draft Standard MIB rules from IESG
>To: ipp at pwg.org>>>> 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).
>>>>Where does it say the implementations have to be products, not not prototypes?
>