An I-D usually needs to get WG consensus before it becomes a WG draft. Getting consensus from the wider community at this point, as you suggest, seems very reasonable. In my experience, once a document is issued as an RFC, it is considered to be a standard. The steps beyond that are largely irrelevant. Sent from my iPhone > -----Original Message----- > From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf Of > Keith Moore > Sent: Friday, October 29, 2010 5:14 AM > To: t.petch > Cc: ietf@xxxxxxxx > Subject: what is the problem ter > > > On Oct 29, 2010, at 4:54 AM, t.petch wrote: > > > By contrast, the delays in producing an RFC seem to revolve around WG > process, > > where Last Call causes people to come out of the woodwork with > delaying > > suggestions, something a good chair or AD would stamp on, and IESG > process, > > where certain hot buttons - eg security, flow control - produce some > ludicrous > > DISCUSS' which delay the process for months. > > Tom Petch > > What I get from this is that the entire community needs to be involved > in review and input of future RFCs much earlier in the process than > Last Call. In my experience, the problem is generally not that the > people "coming out of the woodwork" are making irrelevant suggestions, > because IESG is fairly good at ignoring these. The problem seems to be > that by the time a document as reached Last Call, the working group is > past the point where it can meaningfully consider input from outside > for anything but the most trivial changes - and the problems identified > in Last Call are often much more fundamental than that. Often in my > experience, outside reviewers and IESG members have been compelled to > try to suggest minor wording changes to address what they saw as > fundamental problems of architecture or scope in the proposed protocol. > > And yet, there are far too many Internet-Drafts published for the > community to notice and consistently provide early review of every > proposal, and far too many WGs even in a particular subject area to > permit most community members to keep track of those documents and WGs > with which they might be concerned. > > I'm not sure exactly where this leads, but I'm sort of thinking it > might be nice if there were a "First Call" for community review much > earlier in a document's life cycle. The I-D associated with a First > Call should outline the solution that is being proposed, and all of the > major considerations (e.g. security) should be dealt with - though > perhaps not specified in detail. There wouldn't be any expectation > that the document should be polished, that every aspect of the protocol > being proposed should be nailed down, every option defined, every > reference included or current, and so forth. The First Call I-D would > not be published as an RFC, unless perhaps the WG died prematurely and > there were a desire to publish it as Informational. It's just an I-D > for which the WG requests wide community review. > > The WG would be expected to take First Call comments seriously and to > report to the responsible AD how it was considering First Call comments > into account in the development of its protocol. The tradeoff is that > WGs would not be expected to deal with major structural/scope > challenges at Last Call - provided, of course that they hadn't changed > the structure/scope drastically from First Call. > > Obviously this is not even half-baked yet. Biggest problem I see is > that the community would initially have no idea what level of detail > should be specified by First Call. Some well-written (but incomplete!) > examples, perhaps of imagined First Calls for well-established > protocols, or early Internet-Drafts for protocols that were eventually > standardized, might help. There are lots of other potential problems > also. But in general I think the idea of getting earlier community > feedback is a sound one. > > Keith > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf