Info/exptl RFCs [Re: Killing old/slow groups - transition thinking)

[John C Klensin]

--On Tuesday, 10 December, 2002 15:05 +0200 Jari Arkko
<jari.arkko@piuha.net> wrote:

> Margaret Wasserman wrote:
>...
  
>> The first place I think that we should look is at the side
>> track for publication of informational/experimental RFCs.
>> Why does the IESG need to review all of the weakly academic
>> documents that the RFC editor wants to publish as Info, just
>> to see if they overlap the IETF and/or meet our guidelines?
>> Perhaps we could set-up a separate review group to handle
>> this task which would only bump the real problems up into
>> the IESG?
> 
> I agree. Or let the RFC editor do it as RFC 2026 indicates. Or
> was it too much work?

I have been pushing on this on and off for some years, intensely
so in the last year.  I would describe my success as negative,
i.e., the problem has gotten worse.  This is one of the areas I
identified as IESG expansion of its role into
probably-unnecessary areas in my during-IETF PACT response to
the PACT draft (see section 4 of "Comments and alternatives to
draftt-huston-ietf-pact-00..." of 21 November if you want to
check the archives).

Formally, the only procedural changes that has been introduced
since 2026 are:

	(1) The RFC Editor now requires (with IESG agreement and
	maybe at IESG request -- I can't remember) that all
	documents be published as I-Ds before being submitted
	for RFC processing.  So the language in 2026 that
	implies that the RFC Editor would post the documents for
	comment is no longer relevant.
	
	(2) The RFC Editor was asked to perform a preliminary
	review of documents before forwarding them to the IESG
	for "verification that there has been adequate
	coordination with the standards process" (see sections
	4.2.2 and 4.2.3 of RFC 2026) so that the IESG did not
	have to waste time on documents that the RFC Editor
	wouldn't publish anyway.  And that change is below the
	level of 2026's specification.  

Note that the more extensive provisions for IESG review outlined
in RFC 2418 apply to proposed standards-track documents that are
Last Called.  At least as I read it, there is no provision in
2418 for IESG editorial suggestions about non-standards-track
documents.

But, in practice, a few other things have happened:

	(i) The IESG has taken it upon itself to do _editorial_
	reviews on these documents, sometimes sitting on them
	for weeks or months because some AD says "I have
	comments which I want to write up" and then getting
	comments that involve editorial nitpicking or simple
	disagreements with the author's presentation, rather
	than standards coordination.  It is hard to sympathize
	with IESG's delaying other work when IESG time is being
	spent this way.
	
	(ii) The IESG has added looking for protocol and
	operational suggestions that would be damaging to the
	network, if deployed, to the "standards coordination"
	item.  I personally think this was reasonable, but it
	has added to the workload and been used as the excuse
	for long delays, consideration, and editorial review.
	In years past, we counted on the RFC Editor to catch and
	filter these sorts of things and assumed that really
	stupid and dangerous ideas were better dealt with by
	RFCs that refuted them rather than by disclaimers and
	arm-wrestling about their precise text as a condition
	for publication.
	
	(iii) The IESG has established a de facto procedure
	(undocumented and with no real rules) for their
	reviewing and approving individual submission
	informational/experimental documents before those
	documents get near the RFC Editor.  They have then,
	apparently, told the RFC Editor that such documents take
	priority over anything submitted to the RFC Editor
	directly (at least the RFC Editor believes that to be
	the case).

I clearly do not have much patience for this pattern, which may
be just my personal idiosyncracy.  But I have complained about
the effects of it to individual ADs, the IETF Chair, and the
IESG as a whole with almost no discernable effect.  It is one of
the things that causes me to be skeptical about guidelines,
since no one I have talked with seems to be able to find any
justification in RFC2026 or 2418 for IESG editorial review of
any sort on individual informational documents, much less long
and drawn out reviews that effectively block publication for
long periods without explanation.  

I am reaching the conclusion that the only way things are likely
to get better in this area is if each of us who receives such
editorial comments from the IESG immediately appeals and, if
that is not effective, launches recall actions against whichever
AD is listed as responsible in the tracking system.  While
appeals against the IESG's failure to act have proven
problematic, perhaps it is time we start exercising the
procedure in those cases as well.

> Perhaps the perceived problem with Informational RFCs is that
> they create a feeling of an IETF standard without actually
> being one. I don't personally think this is an issue, but I
> sense that some others do. If this is felt as a problem, maybe
> we should just rename all Informational RFCs to IFCs
> (Informational request For Comments) to make the difference
> clearer and the process lighter. Then the IESG would not have
> to worry so much about the IFCs...

This is part of an old and very complex discussion that we seem
to revisit every half-dozen or so years.  In previous rounds, it
has produced a great deal of debate, followed by a conclusion
that the costs of making a change are not worth it.  The quick
summary is that it isn't nearly as simple as renaming some
documents to "IFCs".

  regards,
     john