IESG Statement on Designating RFCs as Historic
Date: 20 July 2014
RFC 2026 defines a "Historic" status for documents:
However, the only instructions in 2026 for its use are in section 6, and those are to move full "Internet Standard" status documents to "Historic" status, thereby "retiring" the technology in the standard. This differs from the "Obsoletes:" header that is put on documents as per RFC 2223. The "Obsoletes:" header indicates a replacement version of the same technology, rather than a retirement of the technology itself. Using "Obsoletes:" is simply a matter of indicating this in the header of the RFC. Moving a document to "Historic" status requires a specific IETF-wide Last Call and a formal action of the IESG.
We have reclassified RFCs as Historic through different mechanisms and with different documentation over time. All reclassifications have suffered from a common problem: there is no direct reference from the RFC that has been made Historic to the explanation of why that action was taken.
There now exists a new type of document, "status-change" documents, to fill this gap. These documents are kept in the datatracker, are not Internet drafts, and are not published as RFCs, but they are archival documents that are linked to the RFCs whose status is changed. Much as an Internet draft that requests Historic status might be named "draft-jones-9191-to-historic", a status-change document requesting that action might be "status-change-9191-to-historic. Such status change documents are created by an Area Director, and can be requested by individuals or working groups.
A major advantage of a status-change document is that it adds traceability: when the now-Historic RFC is displayed in the datatracker, there is a pointer directly to the status-change document, making the explanation more readily accessible. See RFC 5617 for an example:
Note the line in the header that says "Status changed by status-change-adsp-rfc5617-to-historic".
The current process, then, of moving an RFC to Historic status is to follow one of these, depending upon the level of documentation and discussion of the documentation required:
All cases involve a status-change document, which provides the mechanics for separately approving the Historic RFC's status change and for tying the explanation to the Historic RFC. In all cases, the approval of the status-change document will result in a "Protocol Action" or "Document Action" announcement.
An RFC may be published directly as Historic, with no earlier status to change (see, for example, RFC 4870). This is usually done to document ideas that were considered and discarded, or protocols that were already historic when it was decided to document them. Those publications are handled as are any other RFCs. As there is no status change, no status-change document is used.
Documents having Historic status means that those documents are "not Internet Standards in any sense," as per RFC 2026.