Individually-submitted proposed RFCs (was: Re: what is a problem)

[John C Klensin]

Patrik,

We are in substantial agreement on most points.  I don't
understand whether the members of the IESG who are not
participating in this conversation disagree or whether we are
"merely" having an implementation problem.

I am going to respond, in separate subthreads, to the two areas
where I think our understanding differs.

--On Tuesday, 26 November, 2002 08:08 +0100 Patrik F=E4ltstr=F6m
<paf@cisco.com> wrote:

>> But, apparently due to IESG instructions, I-Ds don't come =
from
>> the RFC Editor.
>=20
> This is wrong. People can request a publication of an RFC by
> contacting the RFC-Editor. The RFC-Editor will issue a
> "timeout" together with notification to the IESG to give IESG
> ability to send input.
>=20
> The problem which RFC-Editor and IESG discusses is how to
> ensure this timeout is in reality working.
>=20
> I claim we have no disagreements here between RFC-Editor and
> IESG. The truth is that we need to write down _exactly_ how it
> is to work.

Perhaps writing it down will help.  But the description of the
process as it actually works is as follows, based on a long
discussion with the RFC Editor during the June-September period
of this year.

(i) People can, as you indicate, request publication by
contacting the RFC Editor.  The IESG may have given new
instructions in the last few months (the original ones were not
documented, so why should new ones be? :-( ).  But, it you have
not, the RFC Editor believes that it:

	* Has been instructed by the IESG to not process any
	such requests, or even review the documents, during an
	IETF meeting or the several weeks before and maybe after
	it.  That blackout implies around three months out of
	the year in which those documents are not examined, at
	IESG request.
	
	* Has been instructed that any processing of
	IESG-originated documents is to be given priority over
	documents originating elsewhere (except, perhaps, from
	the IAB).  Lower-priority activities include review of
	submissions before they are sent to the IESG for
	"standards process coordination".

	* IESG has strongly delivered the message that any
	document that is intended to be processed in a timely
	fashion will come through the IESG first.  I.e., any
	author who wants a document to be processed in a timely
	fashion will find a friendly AD and get the IESG to
	process the document and _not_ submit it to the RFC
	Editor.

Now, a summary of the above might be "Sure, you can submit a
document directly to the RFC Editor.  But the IESG has now
arranged it so the document then goes into a black hole _before_
any timeouts are initiated and before the document enters the
tracker".  Of course, the RFC Editor takes the blame for this.
If the IESG is trying to get control over all documents, or to
eliminate individual submissions over which it does not have
control, without taking responsibility, it is a pretty efficient
way to do so.   And repeated requests to the IETF Chair and the
RFC Editor to get the actual procedure and model, and the
expectations if documents are submitted in various ways, written
down have led to no response (not even acknowledgement of mail)
from the former and not much more from the RFC Editor.  Those
requests have been copied to the other parties who participate
directly in the RFC Editor management process (as evidenced by
participation in the regular "RFC Editor lunches") as well: the
IAB Chair, the ISOC President, and the ISOC VP for Standards.
No substantive or public responses from them either.

So don't tell me that one can submit documents to the RFC Editor
and that (soon) starts a timeout.  From the RFC Editor's
standpoint, the IESG has fixed that path so that it does not
produce anything resembling a timely response.

Of course, where the IESG gets the authority to do that is
another interesting question.

     john