IESG procedures (Re: what is a problem)

Harald Tveit Alvestrand harald@alvestrand.no
Wed, 27 Nov 2002 08:56:00 +0100


--On tirsdag, november 26, 2002 11:21:35 -0500 Pete Resnick 
<presnick@qualcomm.com> wrote:

> On 11/26/02 at 11:00 AM +0100, Harald Tveit Alvestrand wrote:
>
>> actually knowing what the IESG can and cannot do doesn't help you in
>> the slightest when analyzing this particular case.....
>
> Of course knowing the possibilities will help me in this particular case.
> See below.
>
>> you already know that the IESG is able to raise objections. you also
>> observe that the information in these objections can take a lot of
>> time
>>
>> you can also safely assume that this waste of time is not due to bad
>> intentions on anyone's parts
>
> Agree.
>
>> so the internal IESG process as currently instantiated is:
>
> So let's flesh out this process a bit (and wouldn't it be nice if you
> wrote all this down in an I-D)...
>
>> 1 - an AD raises a point in mail or on the telechat ("raise a DISCUSS")
>
> Is the AD required at this point to give a substantive account of the
> concern, or is "I think there's a problem in section X, but I'm not
> really sure what it is" enough to raise a DISCUSS?

A description is given - often of the form "section 3.2 is unimplementable 
- details in mail". "I worry about this, but can't say why" is usually a 
DEFER (which can only be done once) - "I want to think about it some more".
>
> If the answer is that a substantive account must be made, I know that
> somewhere there exists a description of the problem (even if it was only
> done by voice) and the problem is that I've got to find it.
>
>> 2 - that point gets discussed by the IESG on the list and/or in a
>> telechat 3 - if the point-raising AD thinks the point is important
>> enough, he  keeps the DISCUSS; otherwise he drops it ("no-obj with
>> comments").
>
> Is there any way at this point for other members of the IESG to say
> "We've answered all of your concerns and your DISCUSS is unreasonable, so
> we're moving the document along", or is the DISCUSS there until the AD
> takes it off?

ADs removing their DISCUSS because objections have been answered happens 
all the time.

> If no one on the IESG can stop a DISCUSS, then I know that the problem
> might be that the document is "permanently stuck in DISCUSS" and I might
> need to start complaining that the rules need to be changed.

Read the tracker docs - there's an override procedure, but it has never 
been invoked. This tells you something about how eager ADs are to stick to 
DISCUSSes the rest of the IESG thinks of as unreasonable.

https://datatracker.ietf.org/public/pidtracker.cgi?command=view_evaluation_
desc is the particular URL that describes this.

>
>> 4 - the point-raising AD writes up the point, if still valid
>>    (may also happen in step 1, usually does if emailed)
>
> What happens if (let's assume for legitimate reasons), the AD at this
> point doesn't write up the point? Is there some sort of time limit?
>
> If there's a time limit and that limit passes, I know that the problem
> can't be that the DISCUSS is stuck waiting for the write up.

The theoretical limit is 2 weeks (next telechat). As you can see from some 
tracker stuff, we've sometimes been lax in enforcing that.
>
>> 5 - the shepherding AD tries to understand the objection, and then
>> takes the point back to the authors and/or working group chairs.
>
> What happens if the shepherding AD is unable to understand the objection?
> Does the DISCUSS stay in place, or can the shepherding AD say, "This
> DISCUSS doesn't make any sense no matter how many times I've had the
> point-raising AD explain it" and then the document moves along? Is there
> any expectation on the part of the point-raising AD that a DISCUSS will
> be brought up at the next telechat, even if the answer is "We're still
> waiting to hear from the WG", or is the document

So far, I haven't had a case where the shepherding AD has given up on 
understanding the problem. I have had cases where an AD has been frustrated 
with another AD, but not enough to want to invoke the override.

> Depending on the answers to these questions, I can get a much better idea
> of what happened to my document.
>
>> It's obvious now that in your case, one of these points
>> failed/stalled, and unless the points' transition times get
>> documented (which we try to do in the tracker), it isn't possible to
>> tell which step failed.
>
> Transition times are certainly one thing that would help. But knowing the
> details of the IESG procedures, like what counts as a legitimate DISCUSS
> and how it can be removed, would certainly help identify problems in the
> process. For example, I have heard rumor that the IETF chair can override
> a DISCUSS if she or he feels that it is not substantive, but along with
> everything else, I've never seen that written down anywhere.

See override procedure given above.

>> But a high level description of the IESG process, such as what I
>> think is appropriate for a charter ("the IESG is able to raise
>> objections to documents, and will attempt to get those comments back
>> to the authors in a timely manner") will STILL not tell you what
>> failed.
>
> Again, "appropriate for a charter" is a red herring. Let's not call it a
> charter. Let's call it "The IESG policies and procedures". Knowing the
> policies and procedures of the IETF *will* tell me (at least some of the
> time) what failed for a particular document. More importantly, it will
> give us invaluable information into figuring out where current problems
> in the overall process are. If the policies were written down, Klensin
> could figure out whether his problem with the RFC Editor was a problem
> with the IESG policy or a problem with RFC Editor policy and could start
> to figure out how to solve that problem.
>
> What is the harm in writing down the current policies and procedures of
> the IESG? I really don't understand why it would do anything other than
> help us figure out where the problems are (and where they are not).

sure - the devil is in the details.

what publication mechanism do you want for them?
what kind of change control do you want over them?
and what amount of effort in keeping them up to date (rather than executing 
them) do you think is appropriate?

The higher level item, which may explain my gut reaction against the 
"document the procedures and all will be well" idea:

We (both the IESG and the IETF as a whole) ARE moving from being a body of 
"people trusted to try to do the right thing" (and make up procedures to 
match) to a body of "people trusted to execute the documented procedures".

But I think that this move has real costs associated with it as well as 
benefits.

                   Harald