ietf
[Top] [All Lists]

Re: Is this an elephant? [Was: call for ideas: tail-heavy IETF process]

2013-05-16 16:04:43
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