Re: Review panel's role

[Pekka Savola <pekkas at netcore.fi>]

On Thu, 4 Aug 2005, Spencer Dawkins wrote:
> 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.

Documents don't need to be reballoted [in IESG] to be approved (after 
being revised). This is up to the nature of the comments/changes and 
the AD's confidence that the discusses have been addressed to the 
satisfaction of commenters, and that new text doesn't have issues.

If time is of the essence, the chair or whoever could certainly take 
up the document from the editor; I've done so personally in a couple 
of cases.

On Thu, 4 Aug 2005, Henning Schulzrinne 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").

Exactly.  As I read it, the review panel proposal included "yes" and 
"no".  If you say "yes", the document is shipped as-is.

It is (IMHO) important to be able to fix problems, even if relatively 
minor, even if you would like to say "yes" or would have confidence 
that the problems could be fixed in a day or two.

There are many levels of issues, for example:
 - "there is a significant architectural problem in the doc", NO (or
   big discuss)
 - "there are major issues which require at least significant
   clarification/discussion"
 - there are relatively important issues which need to be fixed but
   are so straightforward that the WG (and the editor in particular)
   can probably do it without further dialogue.
 - there are typos or other things affecting readability, and
   sometimes even the clarity of the document.
 - probably a lot more different classes of issues..

To me, having reviews which wouldn't report any issues would meant 
that with high probability, such reviews wouldn't be sufficiently 
indepth.  Finding issues is one sign of a good review -- if the issues 
found are minor, this is also often a sign of a document in a good 
shape.  Discarding the issues doesn't seem good, though if they are 
minor, the amount of dialogue/energy needed should be minimized.

--
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf