On 05/17/2013 05:32 AM, Yoav Nir wrote:
On May 17, 2013, at 1:38 AM, Fred Baker (fred) <fred@xxxxxxxxx> wrote:
On May 16, 2013, at 1:46 PM, Yoav Nir <ynir@xxxxxxxxxxxxxx> 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