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(_at_)ietf(_dot_)org
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On Behalf Of
Keith Moore
Sent: Friday, October 29, 2010 5:14 AM
To: t.petch
Cc: ietf(_at_)ietf(_dot_)org
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf