Re: text suggested by ADs

> > > 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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf