On 6/26/22 11:51, John Levine wrote:
The best solution will almost always be the responsible AD making a judgment call as to whether an additional Last Call is needed and erring on the side of doing one when there is doubt.It's not the "almost always" cases that I'm concerned about, but the other cases. IOW, a statistical argument isn't convincing here.Here's a statistical argument: if we made a new rule that all modified drafts had to go through last call again, and 95% of those drafts had only trivial changes, looking at modified drafts would nearly always be a waste of time, so people won't look at any of them. If you're saying that ADs do a bad job of managing their documents, that is a conversation we can have, but in a world of limited time I would prefer to let them pick the ones to rerun so it's more likely people will pay attention.
What I'm saying is: (a) most late changes are probably not
substantial, but transparency about such changes is still
necessary. (b) most of the time the supervising AD probably
guesses right about whether late changes require another Last
Call, but sometimes they'll get it wrong. (c) and sometimes,
hopefully rarely, there are people who want to substantially alter
the compromise made by the working group.
So no, I emphatically disagree that it's a good idea to entrust
this to the supervising AD, or even the IESG as a whole.
I do not, however, suggest that a Last Call is necessary for every late change; only that there must be transparency, and the opportunity to challenge late changes before RFC publication. Any network protocol engineer understands that stop-and-wait slows things down and pipelining is often better.
Keith
