Dave, On 17/05/2013 04:23, Dave Crocker wrote: ... > The problem here is that basic reviewing is being done by the ADs too > late in the process. You are making a lot of assumptions in that sentence. At least these: 1. "Basic" reviewing means .... 2. At some stage before approval, ADs should perform basic reviewing. 3. Doing basic reviewing after the document has completed IETF LC is too late. Now, if "basic" reviewing means (A) "looking for fundamental flaws" that is one thing. If it means (B) "getting a general understanding of the topic" it's another. I'm really not sure which you mean. > 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. Ah, maybe you mean basic (B). Well, I think this is a totally unrealistic expectation. There are too many drafts on too diverse a range of subjects for ADs to educate themselves at the time of IETF LC, which may be weeks or months before a draft hits the agenda. (I'm not talking about the sponsoring AD or her co-AD, of course: they are presumed to be aware of what's going on in their area.) Busy people are deadline driven, and the IESG agenda is an imminent deadline for ADs in a way that an IETF LC in another Area isn't. > Of course, the IESG discussion during the voting process well might > uncover an actual, serious issue with the document; And that's basic (B). I think we all agree that it's unfortunate if a basic flaw shows up during the IESG ballot phase, but please don't blame the IESG for that. Blame the WG and the IETF as a whole for failing to pick it up during WG LC and IETF LC. Thank the IESG for finding it. > 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. I'm not quite sure what you're saying here, but I think you're saying that the majority of clarity and cross-area issues should be picked up earlier. I couldn't agree more, but don't expect the over-worked IESG to fix that. The rest of us need to fix that. > > 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. Which, as I said above, is a totally unrealistic expectation. > 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. Thanks but no thanks. My mail is full enough with discussion of drafts I will never read as it is. AD reviews should certainly go to the WG list unless they are only nits, but isn't that what everybody does anyway? > > > > 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. I agree with Thomas. We need to be able to apply common sense. Rules and targets are the enemy of common sense. > 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 I find that the tracker in its present state has substantially improved both visibility and predictability. > is not reasonable for the process to require that authors and chairs > take the initiative of complaining when an AD is being problematic. Huh? Who else will complain? > 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. It's supposed to be a backstop, and I think we concur that too many issues are being left for the backstop. It's not the IESG that is falling down on the job. It's the rest of us, who keep sending defective documents to the IESG. > 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... Hubris alert! Brian