what is a problem

[Patrik Fältström]

On måndag, nov 25, 2002, at 21:22 Europe/Stockholm, John C Klensin 
wrote:

[A comment on one of John's issues]

When reading the below, I find it rises some important issues which we 
have been talking about internally in the IESG a number of times.

I think I am asking clarifying questions, and correct a few things.

> Hence
> we have documents that make no normative statements, do not
> specify anything that could be construed as a protocol, and that
> have been exposed to several rounds of comments through the I-D
> process, go into the state "Point raised - writeup needed".

This state is something only(!) Standard Track Documents or BCP go to. 
Writeup of a discuss is only needed when a ballot is issued. Not on 
experimental or informational documents.

The goal is that a writeup should be sent in asap, which imply this 
state should only be used a few days. If something is stuck there for 
weeks, then something is really wrong. It is in the ID-tracker possible 
to see who is supposed to do the writeup as one know already who cast a 
Discuss during the evaluation.

Now, the reason why things are stuck there has to do with the overload 
of individual AD's which John pointed out during the plenary, and his 
note to the IETF list.

Something we have been talking about in the IESG is that with the help 
of the tracker, we have the ability to send notifications when certain 
events happen. Events in the form of "new I-D did appear in the 
repository" or "things have been stuck at this state for too long time".

We don't have this mechanism yet, so we individual AD's rely on 
individuals as ourselves and now also you other IETF people to let us 
know.

> And
> there they sit, sometimes for an extended period of time.

Note, things should be in "writeup needed" only a few days, or maximum 
2 weeks, between two telechats. (For various reasons, 2 weeks is the in 
practice shortest timeframe IESG can act on for major state changes in 
reality. Sometimes things can go faster, but that is modulo 
availability of many people.)

> No
> clue to the author as to what the issue is.

Correct. He can not know. That is to be in the writeup everyone is 
waiting for.

> And remember that,
> unless the IESG has quietly expanded its role (again), the only
> possible comments on this type of document are supposed to be
> "ok to publish if the RFC Editor wants to do that", "end-run
> around the foo WG's efforts/charter or around standards-track
> RFC ZZZZ", or "damaging if deployed".

Here we have a different issue. Here we have a draft which is supposed 
to be Informational or Experimental. No evaluation is used. The 
question to IESG is "Does anyone have any problems with this being 
published as Informational" (or equivalent).

What we _know_ we have problems with is if an individual IESG member 
have issues. My suggestion, now with the new tracker etc, is that we 
should handle these issues exactly like the Discuss for BCP and 
standards track, BUT, modulo exactly what you John state. That I-D's 
that come from RFC-Editor is to be treated differently.

Part from this, which is a known problem, we also in the IESG have a 
generic problem with timers. One timer which we get is the RFC-Editor 
timer. RFC-Editor ask IESG what we think, and we get a timeout.

> If either of the latter
> were invoked, the status would presumably indicate that the IESG
> was waiting for disclaimer text and the author (and, probably,
> RFC Editor) would already have been informally notified.

The notes that can be needed are:

(1) The issues themselves (of course)
(2) An IESG Note which IESG want to be added
(3) A Do Not Publish statement from IESG

> Instead, we have a procedure that apparently permits IESG
> members to drop things into black holes.

Because we have no mechanism to keep track of the timers, yes.

> And, while the tracker
> permits us to identify the "shepherding AD" (which is real
> progress), it doesn't permit us to identify the AD who is
> sitting on the thing.

Let me summarize:

- For standard track and bcp, we _do_ know who we are waiting for when 
waiting for writeup

- For Informational and Experimental, we have been talking about using 
exactly the same mechanism as the above

- We _do_ have problems with timers, but this is not the same thing as 
having AD's intentionally black-holing a document

      paf