Re: Review panel's role

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

 



Spencer Dawkins 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").

Well, please look at draft-iesg-discuss-criteria-00.txt for
a first cut at what is, and isn't, an acceptable DISCUSS. We've got
some pretty good feedback on that draft, so it will be revised.
And I think it would serve as the starting point for a review panel's
criteria.



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).

Allison's on vacation. It's very variable. Sometimes the text change
may be null (if the reviewer had simply misunderstood), sometimes it
will be a few words, sometimes it will be a few paragraphs, and
in the worst case it's a rewrite.


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.

It can be a few minutes if resolved by jabber and a short note to the
RFC Editor; it can be months if it needs a rewrite and a new WG
Last Call. It all depends how deep the problem is.

I would like to get out of this situation.

Some of it is intrinsic, and rearranging the furniture won't
help. But we agree violently that *earlier* review would
help enormously.


Given that the AUTH48 delay is averaging something like a month (did I get this data point right from the plenary last night?), I'm hoping that getting crisper and more predictable in the approval cycle will also encourage working groups to get crisper and more predictable in their part of the process.

Look at that feedback loop from the other side: getting WGs crisper and
more predictable will encourage the approval cycle to be crisper and
more predictable.

Pekka and Spencer also wrote:



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.


In all honesty, there are a lot of things that you do that I wish we all did, and this is one of them :-)

Be careful what you wish for. It's a process violation to make
substantive changes during or after IESG approval without looping
back to the WG. It even attracts appeals. So in such a case,
there is always a judgement call (whether the change is
substantive or editorial) and if you misjudge it, you suffer.

   Brian


_______________________________________________

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]