Comments on section 5.2.2 of IESG charter (draft-iesg-charter-02.txt)

[John C Klensin]

I have copied the problem-statement list on this because the 
draft Charter text does not precisely describe current practice, 
violates/ changes the provisions of RFC 2026, and is arguably 
the root of a problem that has been discussed on that list.

Detailed discussion probably belongs on the Poised list only.

For the information of problem-statement participants who are 
not subscribed to the poised list, this note accompanies a much 
longer one that comments on other sections of the IESG Charter 
I-D.

---------------


> Section 5.2 Non-working group documents
>...
> Section 5.2.2. Informational and Experimental documents

> "NOTE IN DRAFT ... The IESG is discussing".

Procedurally, I don't understand how you can propose to issue an 
Last Call while this note is still in the text.  If the IESG has 
reached a conclusion, it should be posted to to the list.

My own view is that this "procedure" has been the source of 
considerable abuse, much of it starting from good intentions, 
and that it has few benefits.  In particular, as I understand 
the procedures, if a document goes to the RFC Editor, there is 
expected to be a fairly quick review for relevance and 
publishability (see my comments on 2223bis), followed by handoff 
to the IESG with a timeout.  While the IESG can request 
additional time, I would expect those requests to reflect IESG 
consensus (however lightweight), to be accompanied with a 
reason, and for the request and reason to appear in IESG 
minutes. I would expect, or at least hope, that the RFC Editor 
would not grant extensions indefinitely and I would assume that 
an IESG action to repeatedly ask for extensions (or to ask for a 
very long extension) would be appealable.  The IESG review is 
also constrained (by 2026) to catching end-runs and damaging or 
high-risk proposals only: the IESG is not supposed to be able to 
block a document, using these normal procedures, because, e.g., 
some AD simply disagrees with what it says.

Now, contrast this with the history of IESG taking 
responsibility/ control of these individual-contribution 
informational or experimental documents and the procedure you 
have outlined in this section.   The text says:

>    When an AD decides that an Informational or Experimental
> document is of particular importance to the community, the
> AD may also choose to put it directly before the IESG.
> This document will then be processed in the same fashion as
> an Informational or Experimental document from a working
> group.

The decision is made by an individual AD, not by IESG consensus. 
The decision does not even require the agreement of either the 
author (which deviates somewhat from current practice as I 
understand it).  The RFC Editor timeout doesn't apply, so there 
are no constraints --even those created by pressure from an 
angry WG-- to promote timeliness.  And, from observation, the 
limitations on IESG review of an independent submission imposed 
by 2026 don't apply either: if the document is handled "in the 
same fashion as... from a Working Group", the AD can apply 
whatever standards he or she likes as to when the document has 
been adequately nit-picked before releasing it for IESG review. 
While I'm not aware of its having occurred, an AD who was 
hostile to the content of a particular individual contribution 
could easily declare it as "of particular importance" and then 
bury it or kill it with the death of a thousand cuts (or nits).

I would suggest, if the IESG really feels a need to do this, 
that the decision to treat an individually-submitted document as 
if it were a WG one should require IESG consensus, up front, 
about that treatment.  That consensus should be reflected in 
minutes, the reasons given, and it should be entered into the 
tracking system.  The IESG should then also agree on the AD (or 
Area) to which the document should be assigned.  In other words, 
if the documents are to be processed as if they were WG ones, 
they should undergo similar IESG signoff and approval --before 
AD review begins-- as that for a WG.  If the document is not 
_that_  important, then it should be processed through the 
normal, "submit to the RFC Editor" process.

In the much larger number of cases in which one or more ADs 
consider a document important, but not important enough to 
process as if it were from a WG, I suggest that the IESG has, or 
could establish, mechanisms for giving the RFC Editor proactive 
feedback that a particular document should be given greater or 
lesser priority.   The RFC Editor would, of course, not be bound 
by that type of advice, but unless the IAB disagreed, I would 
assume that they would continue to treat IESG advice and 
requests with courtesy and good sense as they have done in the 
past.

regards,
    john

p.s. As I mentioned in my comments on 2223bis, the elimination 
of the User Services area has essentially created a loose end 
with regard to FYI RFCs.  The are clearly not standards-track, 
unlike the slightly gray-area BCPs which we treat as 
standards-track for most purposes.  If the IESG intends to 
specify which RFCs get an FYI designation, then this Charter 
document should probably say that.   If it intends to delegate 
that job to the RFC Editor, then some appropriate offspring of 
2223bis should define the RFC Editor's process for initiating or 
considering the action/ designation.   And, if we intend to not 
issue any new FYI documents, then there is a bit of tidying up 
that should be done elsewhere.