Updated IESG Statement on Designating RFCs as Historic

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Date: 20 July 2014

RFC 2026 defines a "Historic" status for documents:

    A specification that has been superseded by a more recent 
    specification or is for any other reason considered to be obsolete 
    is assigned to the "Historic" level.

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.

  - A document is obsolete when there is a newer version that replaces 
    it. RFC 821 is obsoleted by RFC 2821, which is, in turn, obsoleted 
    by RFC 5321. The technology that RFC 821 describes — SMTP — is still 
    current technology, but the documentation of it in RFC 821 is 
    obsolete.

  - A document is labelled Historic when what it describes is no longer 
    considered current: no longer recommended for use.

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:

    ​https://datatracker.ietf.org/doc/rfc5617/

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:

  1. An AD creates a status-change document containing a relatively 
    brief explanation of the reason for the status change. A four-week 
    last call is issued for the status-change document, after which the
    IESG evaluates and ballots on the status change. If the change is 
    approved, the documentation for the change remains in the status-
    change document, which is readily available through the datatracker.

    This method is best when the explanation is not extensive and does 
    not need much documentation development. The discussion about 
    whether the action itself is correct may, of course, still be 
    extensive.

  2. An individual or a working group posts an Internet Draft containing 
    an explanation of the reason for the status change. The I-D is 
    discussed and iterated as usual for I-Ds. At some point, it is sent 
    to an appropriate AD to request publication. The AD creates a 
    status-change document, with an explanation that points to the I-D. 
    The I-D and the status-change are then last-called together, after 
    which the IESG evaluates and ballots on both. If the change is 
    approved, the content of the I-D is moved into the status-change 
    document, and the I-D is marked as "dead", having served its 
    purpose.

    This method is best when the explanation is not extensive, but needs 
    document discussion and development.

  3. As #2 above, except that the I-D might also contain other 
    information. In this case, after IESG approval the I-D is sent to 
    the RFC Editor. When the RFC is published, the status-change 
    document is changed to point to the RFC instead of the I-D.

    This method is best when the explanation is extensive, the 
    explanation is part of another piece of work that involves 
    publication of an RFC, or, in exceptional cases, when the consensus 
    of the community or of the IESG is that having the information in an 
    RFC is important.

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. 





[Index of Archives]     [IETF]     [IETF Discussion]     [Linux Kernel]

  Powered by Linux