what is a problem

[Pete Resnick]

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?

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?

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.

>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.

>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

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.

>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).

pr
-- 
Pete Resnick <mailto:presnick@qualcomm.com>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102