Let me restate for clarity - ADs aren't necessarily more technically
astute than *all* the rest of us. That is, we need to be careful that
technical input from ADs isn't automatically assigned extra weight or
control (veto power).
There's no way to avoid that happening and still have quality control.
Why is that? If an AD has a compelling reason that a specification needs work, the AD should be able to make a convincing argument to the IETF as a whole.
Not necessarily, because many compelling reasons will not be understood by the IETF as a whole. Look how long it took for the community to start understanding the problems associated with scoped addressing.
Best way to do that is in an open conversation during the IETF last call.
The best time to give a working group feedback is as early as possible, and long before the IETF last call. Providing an extra stage of review during Last Call would provide marginal, perhaps even negative, return for the additional effort invested. If we're going to invest effort in extra stages of review, we'd get more benefit by doing that review much earlier in a document's life cycle.
Which is why I suggest ADs provide technical input in open mailing lists during last calls, to make sure their technical input is on the same footing as everyone else's technical input. I agree that the IESG's job is to ensure correctness, completeness, etc. That feedback should be provided earlier, in an open forum.
I agree that input should be provided as early as possible. But some kinds of feedback inherently follow Last Call,
Such as?
Somebody has to evaluate Last Call comments, and make a determination as to whether the Last Call comment is correct, or the WG text is correct, or (as is often the case) whether there is some merit in the Last Call comment but it is overreaching in some way. It's also possible for multiple Last Call comments to conflict, or for a Last Call comment to reveal new issues about a document that weren't the subject of the Last Call comment.
What you seem to be asking for is for the final review to be done twice - one in which the IESG reviews a document during Last Call, and another in which the IESG reviews a document after Last Call comments have been received. This would substantially increase IESG's workload.
Something that needs to be understood is that most people who read as many documents as the IESG does will not retain many details of those documents in memory. So they'll need to reread the documents (or at least the relevant portions) to evaluate Last Call comments. And yet when rereading the document the text will look familiar and it's even harder to notice details. For this reason a thorough rereading of a document can be even more tedious than reading it the first time.
and limiting IESG input to before Last Call would just serve to make the process even slower than it already is (by requiring multiple IESG reviews rather than just one),
I disagree - suppose the gating function comes *before* the IETF last call: before a draft goes to IETF last call, the ADs all agree that they are prepared (have cycles, aren't travelling, etc.) to review and comment on the draft.
My experience has been that the there can be an unbounded delay between the IETF last call and the IESG review.
Your proposal would move the unbounded delay to _before_ IETF Last Call. As it is now, if a WG gets feedback during Last Call that there's something wrong with its work, it can suggest fixes for the problems (or otherwise respond to the comments) before IESG reviews the document, thus increasing the potential for the document to be approved (pending changes) by IESG on the first review.
The other problem with the proposal - the other reason it would increase IESG workload for marginal benefit - has to do with the changes that it would imply for the way IESG operates. At least when I was on IESG, the IESG as a whole would not evaluate a document until the responsible AD had reviewed it and was willing to vote Yes on the document. This saved the IESG the effort of having to review documents that were clearly not ready. Your proposal would take away this optimization.
(OTOH, that procedure had its own problems - in particular it put the responsible AD in a bind if he or she found problems with a document. Pushing the document back to the WG required an extra revision/review cycle and delayed progress of the document for several weeks. At the same time, since this pushback came from a single AD, the WG could accuse the AD of capriciousness. So responsible ADs would either be tempted to solve the problems themselves by suggesting changes in text to the WG (to which their response might be to balk), or to state a Yes position on the document but somehow get another AD to state a Discuss position in order to get the responsible AD's comments addressed. I really hope that this has changed since I was on IESG, so that an AD can say to the rest of IESG "this document needs changes, but it's good enough that the rest of IESG can review it now".)
Keith
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf