Dave CROCKER <d...@dcrocker.net> 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".
That's news to me: I can't recall any recent discusses calling for operational experience before publishing as Proposed Standard. Some years ago, there was such a requirement for Routing Area, but that was declared obsolete. (In actuality, there seems to still be a somewhat informal requirement to document implementations for _some_ Routing Area documents, but it is not by IESG direction.) > Well, they do not /always/ require it. I'm willing to be corrected: does anyone want to document a single case where this was required _by_the_IESG_ in the last two years? > 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. That strikes me as a terrible idea. I can think of several cases where WG LastCall was postponed until two implementations were demonstrated. By that time, folks were so set on their implementations that it proved "just too difficult" to dislodge that with facts about faults in the specification. (I realize that only flame-wars can follow such a statement as "the reason" to keep 2026 the way it is for Proposed Standard. I shall try to find a sufficiently flame-proof suit...) Please consider human nature here. We do have folks that are good at pointing out theoretical weaknesses of proposed algorithms. But they stand no chance of prevailing against "running code" that's already deployed in the field. I grant that IETF runs on "rough consensus and running code"; and I have no particular interest in even _trying_ to change that. But can't we PLEASE keep the review stage before we cast the "running code" in silicon? > 2. Have a clear demonstration of industry acceptance (deployment and > use) be the criterion for "Internet Standard" (ie, Full.) In truth, there are interlocking reasons why advancement beyond Proposed Standard is so difficult -- but I'd like to call attention to one particular reason: the IESG is overworked. Look at any bi-weekly agenda. Count the pages in the I-Ds. Glance through some of the questions raised. Even if you think the majority of them are spurious, documents _do_ reach the IESG in a state which essentially precludes implementation working only from the document. Now, imagine bringing every standard-track document back two more times. :^( We've had several Working Groups over the years consider this; and IMHO they've mostly agreed the IESG shouldn't have to act on these documents three times. But we don't have to abolish the three-levels of 2026 to accomplish that: there have been several proposals to simplify the process of advancement. It is a characteristic of consensus process that sometimes it's "obvious" to a majority that the "wrong consensus" was reached. That doesn't mean, however, that proposing a "better consensus" is workable. We've gone through years of proposing "better consensus" here; and I'm frankly not convinced it's worth another half hour of Plenary time to propose another. We have three levels in RFC 2026. The levels are reasonable, starting with a clear specification, progressing through interoperable implementation, and finishing with experience in the field. Frankly, the fact that we seldom get past the first _doesn't_ convince me there's anything wrong with the levels. And I don't see why we should expect it to convince anyone who doesn't already subscribe to one or another "better consensus". I wish we could instead discuss how to improve the _process_ of advancing through the levels. It may be that some prior IESG was unwilling to let go of a death-grip on blocking advancement for any perceived imperfection. (I simply don't know...) I do NOT believe, however, that the current IESG has any such interest in keeping tight control of advancement. -- John Leslie <j...@jlc.net> _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
