On 6/21/10 1:12 PM, "Scott Lawrence" <xmlscott(_at_)gmail(_dot_)com> wrote:
On 2010-06-20 10:41, Dave CROCKER wrote:
On 6/20/2010 11:53 AM, SM wrote:
The reader will note that neither implementation nor operational
experience is required. In practice, the IESG does "require
implementation and/or operational experience prior to granting Proposed
Standard status".
Well, they do not /always/ require it.
That said, the fact that they often do and that we've lived with the
reality of that for a long time could make it interesting to simplify
things significantly:
1. Have the current requirements for Draft be the entry-level
requirement for a standard -- do away with Proposed, not Draft.
2. Have a clear demonstration of industry acceptance (deployment
and use) be the criterion for "Internet Standard" (ie, Full.)
Having two interoperable implementations required for /all/ new
specifications takes care of two interesting questions.
a. Whether the specification can be at all understood.
b. Whether there is any meaningful industry motivation to
care about the work.
With these two questions satisfied, the nature of challenges against
standardization might tend to be more pragmatic than theoretical.
I strongly support this approach. The main drawback of this would be
that a document would sometimes need to exist for longer as an I-D while
implementations are developed, but balancing that is the fact that those
implementations would then inform the first RFC version rather than some
subsequent update, and it would be harder to get an RFC published for
something no one is really going to build.
On first blush, I like this approach (doing away with Proposed rather than
Draft) as well, although I see rather different process implications.
In many ways, this still supports a three step maturity level. If two
independent implementations are not available, then the I-D can still be
submitted for publication as an Informational RFC (or Experimental). Once
two implementations are available, the document could be resubmitted for
Draft Standard.
This is still better than the current three step process for a number of
reasons:
(1) the line between proposed standard and informational rfc is often
blurry, but the difference between informational and draft standard is
relatively clear;
(2) there is no way to differentiate between a proposed standard with lots
of supporting code, and one that has little implementation support, but
neither is likely to be progressed to draft these days; and
(3) a streamlined two-step maturity process is available to specifications
that have significant support.
Tim
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf