Re: Review panel's role

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]