Two observations, just my opinion...
--On Thursday, August 04, 2005 15:18 +0200 Spencer Dawkins
<spencer@xxxxxxxxxxxxx> wrote:
I think it would be useful to analyze the nature of current
DISCUSS comments before drawing conclusions from the 70%
figure. They apparently range from simple typos ("expand
acronyms") to differences of opinion ("WG chose X, AD
prefers Y; both X and Y are at least plausible") to adding
various disclaimers to fundamental design problems
("broken").
I agree completely with Henning. If I understood Allison in
the plenary last night, she was saying that most DISCUSSes
don't really result in much change (Allison, if I
misunderstood, please correct me).
Well, as long as we don't remove the "editor" function from "RFC
Editor" I hope there is _never_ an IESG DISCUSS on "expand
acronyms". If there is, we are doing something seriously wrong
and wasting time, probably a month or more (AD reads document to
that level, writes up DISCUSS, enters it in tracker, negotiates
with author, slides to the next telechat...). The good news is
that, while I could be wrong, my subjective impression is that
those happen rarely if at all these days. The bad news is that
these DISCUSSes are mostly more substantive, and that brings us
to...
My point is that each of these DISCUSSes kept a specification
from being approved for at least one two-week telechat cycle.
I believe, in the absence of data, that adding delays to a
project makes it easier to stretch out other delays, so "two
weeks" is the minimum amount of time one would wait before a
specification would be reballoted, but if a document editor is
on vacation for a week and doesn't provide updated text
immediately, the actual delay can be longer.
I would like to get out of this situation.
There is another element of this, which intersects with NEWTRK
and Spencer's earlier note. While we haven't been taking
advantage of them, there are really strong reasons for a two (at
least)-stage standards process. One of them is the ability to
get those early-stage specifications that Proposed Standards are
supposed to be out the door.
Conceptually, I think we ought to be adding a new section to
most Proposed Standards. That section is exactly what 2026
indirectly calls for in its prohibition on known technical
deficiencies, reading that is "we know about them and know how
to fix them". Perhaps we should be letting things go out with
an "Areas of Unresolved Controversy" section in which questions
and issues that are not absolutely fatal showstoppers, to a
proposal could just be identified in a Proposed Standard, the
thing shipped, and those issues resolved before the
specification could go to Draft (or, in a two-step process, Last
or whatever it is called).
This is not yet another process change suggestion, just a
suggestion that we need to, again, think of Proposed Standards
as what 2026 and the term "proposed" imply, such that the
response to finding a slightly-important problem is to note it
and move on, rather than aspiring to have every specification
perfect, even pre-implementation specifications.
Of course, one could get the same effect by declaring all of
today's Proposed Standards to be Experimental, taking the "note
and move on" approach to them, and then having a one-stage
standards track that requires implementation and deployment
experience to get to stage 1.
john
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf