On 6/21/10 1:12 PM, "Scott Lawrence" <xmlscott@xxxxxxxxx> 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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf