That's a good question Dave. The community might like to comment. On the whole, I am told that if an AD weighs in with her comments during working group last call, her fearsome personality may overwhelm some of the WG participants and she may dominate the WG consensus. Is it possible that the same would happen in IETF last call? I know, of course, that a number of you have a robust ability to defend your opinions, but how would you (the community, not Dave) feel if ADs (speaking as ADs, not speaking as individual contributors) made their review comments during IETF last call? I agree that this would bring the tail forward a little (not a lot). I don't believe it would reduce AD work-load (which is another issue entirely). I have mixed feelings about whether it would change the processing time for a draft. That might depend on how the review is handled in IETF last call. Lastly, I think I disagree with you about "really serious" IETF last call comments coming in the first few days. It seems to me that we also get an number of late comments of substance resulting from people who are not familiar with the document reviewing it (such as directorate reviews and people who didn't notice the I-D sneaking through). Still thinking, Adrian > -----Original Message----- > From: Dave Crocker [mailto:dhc@xxxxxxxxxxxx] > Sent: 16 May 2013 17:23 > To: adrian@xxxxxxxxxxxx > Cc: ietf@xxxxxxxx > Subject: Re: Is this an elephant? [Was: call for ideas: tail-heavy IETF process] > > On 5/15/2013 1:30 PM, Adrian Farrel wrote: > > Suppose the AD raised her concern by writing a Comment or sending an email > and > > balloting "No Objection." That would mean that the I-D would be approved for > > publication. > > > > At this point either: > > - the discussion goes on, but the document becomes an RFC anyway > > or > > - the responsible AD holds the document pending satisfactory completion of > the > > discussion. > > > > I suggest that the former is a bad result. > > > > Personally (but this may reflect my Discusses) I find that an active engagement > > by the authors and the Discussing AD on the issue and the potential resolution, > > always leads to speedy progression of the document either with the AD feeling > > stupid, or the document improved. Both are adequate results. > > > Adrian, > > I suggest we all take a look at the original text of the Subject field. > > The problem here is that basic reviewing is being done by the ADs too > late in the process. We are making the mistake of having ADs be exempt > from IETF Last Call, and allowing them to be unprepared for the IESG > vote. So we are combining "education" with "voting". That's a paradigm > error. > > By the time the IESG schedules the vote, ADs need to already have > educated themselves about the document. > > Of course, the IESG discussion during the voting process well might > uncover an actual, serious issue with the document; this should be > exceptional and it should be an issue that the /IESG/ agrees needs to be > resolved and it means that voting should not take place until it is. > But that is quite different from the usual "let's talk about it" kind of > Discuss imposed by individual ADs. > > So here's a simple proposal that pays attention to AD workload and > includes a simple efficiency hack: > > When the IETF Last Call is issued, wait a few days, to see whether > any serious issues are raised by the community. The really serious ones > usually are raised quickly. If there are none, it's pretty certain the > document will advance to an IESG vote. That leaves 7-10 days of IETF > Last Call for ADs to get educated and ask questions, just like everyone > else. > > Jari has expressed the goal of having AD concerns be raised more > publicly. Moving AD review and comment to the IETF Last Call venue > nicely accomplishes this, too. > > > > On 5/15/2013 8:55 AM, Thomas Narten wrote: > > 1) Discuss criteria should be principles, not rigid rules. The details > > of the issue at hand always matter, and it will sometimes come down to > > judgement calls where reasonable individuals just might disagree. > > We've been doing protocol specification for 40 years. If we can't > codify the major concerns that warrant blocking advancement of a > protocol, we're just being lazy. Really. That a given situation might > cause the IESG to decide to enhance the list does not mean that the list > shouldn't seek to be complete and precise and that ADs be held to it. > > At every turn, the approach we've taken to the IESG review and approval > process is to limit actual accountability to the community. Everyone is > well-intentioned, but really this makes the process a matter of > personalities and not the rigor of serious professionalism. > > The IESG's process is far, far better than it was 10-15 years ago, but > it still lacks meaningful predictability and serious accountability; it > is not reasonable for the process to require that authors and chairs > take the initiative of complaining when an AD is being problematic. > > In terms of quality assurance, the idea that we have a process that > relies on the sudden insight of a single AD, at the end of a many-month > process, is broken. It's fine if that person sees something that > everyone else has missed until then, but that is quite different from > designing a process that is claimed to rely on it. > > And of course, the reality is that we allow bad specs out the door all > the time; we just allow fewer of them than many/most other standards > bodies... > > d/ > > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net