IESG Statement on Designating RFCs as Historic
NOTE: This IESG Statement is superseded by the IESG Statement "IESG Statement on Designating RFCs as Historic" dated 20 July 2014.
NOTE: This IESG Statement is superseded by the IESG Statement "IESG Statement on Designating RFCs as Historic" dated 20 July 2014.
RFC 2026 states the following:
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.
In practice, the Historic status is not automatically assigned to RFCs that have been "obsoleted". That is, when an RFC that contains the "Obsoletes: RFC XXXX" header is published the RFC editor does not automatically apply the Historic status to the XXXX RFC. Note that in some situations this is perfectly acceptable because multiple versions of an Internet Standard are permitted to "honor the installed base," as per RFC 2026.
If authors wish to change the status of RFCs that are in the obsoletes header to Historic, then the authors must include an explicit statement for the RFC editor to do so; preferably in the introduction. Further, when an AD sponsors a draft that includes the obsoletes header, then the AD should ask the authors whether the authors intended to move the RFC(s) listed in the obsoletes header to Historic status.
If an author wishes to publish a document directly to Historic status the preferred approach is to publish an I-D with the "Intended Status: Historic" in the header.
As allowed by RFC 2026 Section 6.4, anyone may request that the IESG move an RFC to Historic that is simply and obviously obsolete (and in A/S terms "not recommended") without the need to produce an I-D. The IESG can issue Last Calls to request that the RFC in question be moved to Historic.
If a document (whatever its intended status) moves another document to "Historic" status, the Last Call should go out saying, "Last Call:to Informational and RFC XXXX to Historic", the document should be handled as a Protocol Action on the IESG agenda using IESG Protocol Action procedures, and a "Protocol Action" announcement should be sent out when the document is approved.
Moving a document to Historic status means that the document is "not [an] Internet Standards in any sense," as per RFC 2026.
NOTE: This IESG Statement is superseded by the IESG Statement "IESG Statement on Designating RFCs as Historic" dated 20 July 2014.
This IESG statement describes the manner in which the IESG will process RFC Errata concerning RFC Metadata [RFC5741].
This statement provides guidance from the IESG on selection of a Document Shepherd for documents from IETF working groups and documents from individuals.
Protocol specifications and other documents intended for RFC publication often include useful examples with correctly formatted and syntactically valid codepoints, addresses or names.
RFC 3777 requires that voting members of the nominating committee (NomCom) be selected from volunteers that have attended at least three of the last five IETF meetings.
Show all