ietf
[Top] [All Lists]

Re: Is this an elephant? [Was: call for ideas: tail-heavy IETF process]

2013-05-17 09:22:30
On 05/17/2013 05:32 AM, Yoav Nir wrote:
On May 17, 2013, at 1:38 AM, Fred Baker (fred) <fred(_at_)cisco(_dot_)com> 
wrote:

On May 16, 2013, at 1:46 PM, Yoav Nir <ynir(_at_)checkpoint(_dot_)com> wrote:

There is a problem, though, that this will increase the load on ADs. Other 
concerns raised during IETF LC may lead to revised I-Ds, which the ADs will 
need to re-read (or at least look at the diff). I don't know how significant 
this extra work would be, but it would come at a time that we're thinking of 
ways to reduce AD workload. It might also require prolonging the LC time, 
because there would be actual discussion in it.
If they raise the issue later in a "discuss", will they not have to do this 
anyway? How does this relate to the timing of the comment or the vehicle by which it is 
conveyed?
If you review early, you later might feel like you need to review again, 
because the document has changed some. Hence - more work.
Yes, but you only need to review what has changed. It _can_ be more work, particularly for documents that have changed a lot, or if it's been too long since the last review. But I really wouldn't suggest that ADs should do several reviews of each document. I suspect that the trick is to review a document at the time the WG thinks that it's maybe 70-80% done (which is to say the WG is probably closer to 40-50% done), but when some issues still seem unresolved. That's when the ADs' input, and external input in general, can be the most valuable. That way, ADs should be able to say "yes, but you're totally ignoring this very important issue here, and you really have to deal with it" at a time when the WG isn't yet so exhausted or off in the weeds that it can't focus on it. Then the ADs just need to track the changes from that point forward, to make sure that the issues identified were dealt with satisfactorily.

Of course new issues can still be identified, and WGs can address previously identified issues in unsatisfactory ways. But at some point (well prior to WGLC) it might be appropriate to raise the bar for new issues. At some point it should take a serious defect to significantly delay publication of a document, and at that point it might make more sense to consider other remedies for identified less-serious issues, especially if the existing protocol isn't seen to be actually harmful and it appears that the protocol can be extended to address the issues in a manner that is compatible with existing implementations. In those cases, it might make sense to go ahead and publish, but charter the WG to extend the protocol to address those issues.

Keith