what is a problem

[John C Klensin]

--On Monday, 25 November, 2002 21:45 +0100 Patrik F=E4ltstr=F6m
<paf@cisco.com> wrote:

> On m=E5ndag, nov 25, 2002, at 21:22 Europe/Stockholm, John C
> Klensin wrote:
>=20
> [A comment on one of John's issues]
>=20
> 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.
>=20
> I think I am asking clarifying questions, and correct a few
> things.
>=20
>> 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".
>=20
> 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.

I'm glad to hear that.  If I've got an individual submission
informational document in that state, what did you say I do
about it?   Given that the IETF Chair is aware of the problem
(and, indeed, if the tracker is to be believed, is the
token-holder/ obstruction), I hope the answer isn't "appeal".

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

To repeat (briefly) a point I've tried to raise elsewhere, under
what authority does the IESG claim the right to take "discuss"
positions on Informational document that do not specify
protocols, address issues that are included in WG Charters, or
suggest courses of action that could be harmful?  I can't speak
for others, but the reason I've been inquiring about an IESG
Charter is to get the IESG to identify the range and limits of
its authority and responsibility so that the community can
determine whether or not it agrees.

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

But one of the ways to reduce overload is to reduce the number
of things the IESG starts trying to review and comment on at a
detail level.  It seems to me that deciding, within the IESG,
that you must, or even can, start quibbling about textual or
editorial points in individual informational documents just adds
to the overload and that you (collectively) should get no
sympathy at all in cases where you take on work that no one has
asked of you and that is not necessary to the integrity of the
standards process.
=20
> 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".
>=20
> 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.

Does this imply that you are telling the community that, when
something appears to be stuck, we should harrass the IESG?  I
had been assuming that you could do a better job in managing an
overloaded situation if the other 2000 +/- of us weren't
continually on your cases, complaining about what you were not
doing, and expecting responses.

>> And
>> there they sit, sometimes for an extended period of time.
>=20
> 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.)

The example in question went into that status, according to the
tracker, on 5 November.  I would feel somewhat more sympathetic
to this situation, with informational documents (I think it is
dangerous for standards-track ones), if "discuss" followed by a
two-week silence implied an automatic release to the RFC Editor
with a "no IESG comments" indication.

>> No
>> clue to the author as to what the issue is.
>=20
> Correct. He can not know. That is to be in the writeup
> everyone is waiting for.
>=20
>> 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".
>=20
> 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).

That, to me, is a correct question.  The answer, if "yes" (i.e.,
there are problems) should be substantive and based in one of a
small number of principles and not ever editorial unless it is a
WG product that qualifies or elaborates on standards-track
materials.

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

But, apparently due to IESG instructions, I-Ds don't come from
the RFC Editor.  If there is any desire to get a document
processed and published in finite time, it has to go to the
IESG.  If there is some other procedure that is supposed to
work, I continue to hope that the IESG will document it.

> 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.
>=20
>> 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.
>=20
> The notes that can be needed are:
>=20
> (1) The issues themselves (of course)
> (2) An IESG Note which IESG want to be added
> (3) A Do Not Publish statement from IESG

I even question "the issues themselves" unless the IESG is
identifying a conflict or end-run or source of confusion with
IETF-approved activities.  Nothing in procedures established and
reviewed by the community give an IESG member any more input
into the ideas of an individual submission than any other member
of the community at the time the document is exposed as an I-D.

Once again, if you think you need that responsibility and
authority, please --whether by a charter or some statement that
can be reviewed-- ask the community for it.   Assuming it in
secret is just not a good idea.

>> Instead, we have a procedure that apparently permits IESG
>> members to drop things into black holes.
>=20
> Because we have no mechanism to keep track of the timers, yes.

And because you have, apparently, no mechanism to prevent
experimental and informational documents from being tied up
using mechanisms that you have identified as only appropriate
for standards-track ones.

>> 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.
>=20
> Let me summarize:
>=20
> - For standard track and bcp, we _do_ know who we are waiting
> for when waiting for writeup
>=20
> - For Informational and Experimental, we have been talking
> about using exactly the same mechanism as the above

My personal recommendation is that, before doing this, you
carefully delineate under  exactly what conditions objections/
"discuss" positions can occur.  And, if those conditions exceed
the review scope specified by RFC 2026 section 4.2.1 (for
Experimental), 4.2.2 (for Informational), and 4.2.3, they need
to be written down and community approval obtained.   I note
that the relevant text in 4.2.1 and 4.2.2 is "subject only to
editorial considerations and to verification that there has been
adequate coordination with the standards process" and that
"editorial considerations" fall clearly (in that document) under
RFC Editor control.


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

I ultimately don't care whether something vanishes into a black
hole because of intentional acts or just because of overload.
However, if the latter is the problem (as I believe it usually
is), I think we should be looking for ways to put less load on
the IESG, rather than having the IESG make up more ways to add
to its load, especially without consulting the community.

   john