From: Bruce Lilly (blilly@erols.com)
Date: Sat Jul 03 2004 - 12:08:03 CDT
Henry Spencer wrote:
> More precisely, the WG strongly supported publication of son-of-1036 as a
> Historic RFC.
Then evidently some WG members don't understand the IETF process. There is
a very specific track to an Historical RFC, quoting from RFC 3160:
"There is
actually a third designation, Historical, but that is reserved for
documents that were on the standards track and have been removed due
to lack of current use, or that more recent thinking indicates the
technology is actually harmful to the Internet.
"
I.e. Standards Track first, then moved to Historical. And getting to the
Standards Track in the first place also involves a very specific procedure,
outlined in RFC 3160 also (and in detail in BCP 9):
" 1. Publish the document as an Internet Draft
2. Receive comments on the draft
3. Edit your draft based on the comments
4. Repeat steps 1 through 3 a few times
5. Ask an Area Director to take the draft to the IESG (if it's an
individual submission). If the draft is an official Working
Group product, the WG chair asks the AD to take it to the IESG.
6. Make any changes deemed necessary by the IESG (this might
include giving up on becoming a standard)
7. Wait for the document to be published by the RFC Editor
"
We've been discussing the issues for Standards Track RFCs for some time,
so it should be clear that news.txt will require substantial work to pass
IESG muster. Including correction of factual errors, compliance with
current BCP, updating references to current RFCs, correcting references
to the year 1999 as if it were in the future, etc.
Frankly I'm surprised that we're having this discussion; the procedures
are clearly set out and WG participants are supposed to know how the
process works.
> The preference for doing it after publication of the
> Standards Track document(s) was mine. I'm now reconsidering that; our
> Chair has stated (in private mail) that he has no objection to son-of-1036
> appearing first, and I've had some encouragement from others to do so as
> well.
>
> The point of publishing it as a non-Standards-Track RFC is, of course, to
> guarantee its future availability for historical purposes and to permit
> referencing it more conveniently. It's going to come with a strongly-
> worded preface pointing out that not only is it not a standard, but some
> of its innovations were, in hindsight, mistakes.
There are two other categories of non-Standards Track RFCs: Experimental
and Informational. Getting to Historical doesn't seem to be practical.
Experimental or Informational may well be.