Dave & Scott: >> 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. This would seem to encourage publication as Informational (perhaps on the Independent Submission Stream) as a first step. I'm not sure that really reduces the work load, but it does shift it out of the standards track. Russ _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf