Basic RFC rule: informational specs are published.
In fact, that's not the rule. The rule is closer to:
The RFC Editor decides, unless the document is approved by IESG.
Because the RFC Editor has always exercised some degree of
editorial control, and has never published any random document
that someone submitted.
oh? that contradicts actual history, Keith, as well as the premise behind
the RFC series.
This is what Jon told both me personally and IESG, and I heard him
say it on multiple occasions. I don't believe the current policy is
significantly different. And the RFC series today isn't quite the
same as originally envisioned.
I suspect the relevance of this to the header registry discussion is getting
rather tenuous at this point, but in hopes of putting this to rest...
The current informational RFC publication policy is pretty much what Keith said
it was. Someone asks the RFC Editor for publication. Then the RFC Editor asks
the IESG to review and comment. If nobody objects it is then back in the RFC
Editor's court. If the IESG has a problem with publication it drafts a note
explaining why. The RFC Editor evaluates the IESG's position. If the RFC Editor
agreees the author is told the document will not be published in its present
form. If the RFC Editor does not agree it informs the IESG of its decision to
publish anyway and the IESG then has the option of writing an IESG note to be
included in the RFC explaining why it is a bad idea or whatever.
The RFC Editor, usually in consultation with the IESG, does reevaluate and
change its editorial policies from time to time. (A policy change regarding
documents with excessive numbers of authors is forthcoming, for example.) But
this usually leads to document revisions, not outright document rejections.
In practice most informational submissions end up getting published. In the
relatively uncommon cases where the IESG has a problem with pulication the RFC
Editor has in my experience gone along with that assessment most of the time.
I've been on the IESG for almost two years now, and before that I was the IAB's
liason to the IESG for a year, and this is how it has always worked during that
time. I can recall only one case where I strongly disagreed with the RFC
Editor's decision to publish something the IESG objected to.
I've been involved in the IETF since late 1989, and I know of cases where the
RFC Editor declined to publish as early as 1992-1993. However, I don't
know what the process was back then.
Does this take IESG time? Sure. I've written several "do not publish" notes in
my time on the IESG (and if memory serves I believe the RFC Editor has gone
along in every case) and they aren't particularly easy to write. But I don't
find the time they take to be overwhelming. And while I find the argument that
the Web makes it possible for anyone to publish things without the bother
associated with the RFC series pretty compelling, I see real value in having an
independent RFC Editor function. Checks and balances are good things even when
you don't agree with the outcome in specific cases. I therefore view any shift
in policy in this area less in terms of "faster/better rejection of boneheaded
ideas" and more in terms of how it would impact organizational independence.
Ned