INTERNET-DRAFT M. Yevstifeyev Intended Status: BCP January 28, 2011 Updates: 2026 (if approved) Expires: August 1, 2011 Clarifying the Historic Status Abstract This document gives the definition of Historic status, procedures for moving RFCs to this status and discusses some other issues related with it. It updates RFC 2026. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect Yevstifeyev Expires August 1, 2011 [Page 1] INTERNET DRAFT Historic RFCs January 28, 2011 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Historic Status Definition . . . . . . . . . . . . . . . . . . 4 2.1. Criteria for Historic RFCs . . . . . . . . . . . . . . . . 4 3. Procedures for Historic RFCs . . . . . . . . . . . . . . . . . 5 3.1. Republication of RFC as Historic . . . . . . . . . . . . . 5 3.2. Reclassification of RFC as Historic . . . . . . . . . . . . 5 3.2.1. Standards Track RFCs . . . . . . . . . . . . . . . . . 6 3.2.2. Best Current Practices RFCs . . . . . . . . . . . . . 6 3.2.3. Experimental RFCs . . . . . . . . . . . . . . . . . . 6 3.2.4. RFCs with No Particular Status . . . . . . . . . . . . 6 4. Other Considerations . . . . . . . . . . . . . . . . . . . . . 7 4.1. Handling References to Historic RFCs . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Yevstifeyev Expires August 1, 2011 [Page 2] INTERNET DRAFT Historic RFCs January 28, 2011 1. Introduction The Historic status was firstly mentioned in RFC 1310 [RFC1310], and its definition remained unchanged in all the revisions of this document - RFC 1602 [RFC1602] and the most current RFC 2026 [RFC2026]. However none of these documents give gives distinctive and precise description of this status, as well as procedures for Historic RFCs. This caused misunderstandings of members of the community regarding the criteria the RFC should meet to become Historic, procedures for such action, etc. This document is to clarify the Historic status and procedures for moving RFCs to this status. It also discusses some issues related to it, such as handling references to Historic RFCs, etc. It updates RFC 2026 [RFC2026]. 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. The term 'historicizing RFC' means the RFC that moves another one to Historic. The term 'historicized RFC' means the RFC that is moved to Historic by another one. The term 'superseding RFC' means the RFC that replaces another one. The term 'superseded RFC' means the RFC that is replaced by another one. Yevstifeyev Expires August 1, 2011 [Page 3] INTERNET DRAFT Historic RFCs January 28, 2011 2. Historic Status Definition The Historic status is used to identify that the particular RFC is obsolete (i.e. outdated) or superseded. The criteria the RFC should meet to be considered as obsolete or superseded are discussed in Section 2.1. The Historic status MAY be assigned to RFCs of all categories, except Informational RFCs, following the procedures of Section 3 of this document. 2.1. Criteria for Historic RFCs If the RFC is replaced by another one, it SHALL be considered to be superseded. The RFC SHALL be considered to be obsolete if it meets the following criteria: a. It has been publicly available for at least 7 years; b. During this period of time the technology, described in this RFC has not been seen used in the Internet; or c. The technology defined in this RFC is not possible or is not advised to be used in the Internet because of its security issues, impact on its performance or any other reason. Yevstifeyev Expires August 1, 2011 [Page 4] INTERNET DRAFT Historic RFCs January 28, 2011 3. Procedures for Historic RFCs There are two different ways the Historic RFC may put itself on the map. They are: a. Republication of RFC as Historic; and b. Reclassification of RFC as Historic. The procedures for these two cases are described below. 3.1. Republication of RFC as Historic One way to make the RFC Historic is to republish it in this status. If such action is needed, the appropriate Internet-Draft with the intended status 'Historic' and that supersedes the historicized RFC SHALL be published. The technical content of this Internet-Draft MUST be the same as in the historicized RFC. Such document MUST contain the 'Historic Considerations' section clarifying the reason of republishing the document as Historic. Once the authors of such Internet-Draft are sure that there is a consensus is find, they apply to IESG to request the IETF-wide Last Call for republishing thee particular document as Historic. If the Last Call revealed the wide consensus of the community, the corresponding RFC will be republished as Historic. There are a number of cases when the approval of another parties is needed for republication of RFC in Historic status. In particular, if the historicized document has been processed on IAB Stream [RFC4844], the approval of IAB Chair is REQUIRED for historicizing such document. If the document has been processed on IRTF or Independent Submissions Streams [RFC4844], the approval of IRTF Chair or the authors of the document (or the directors of the area the document is considered to be related to, in essential cases), respectively, is REQUIRED for moving such document to Historic. 3.2. Reclassification of RFC as Historic Reclassification of RFC as Historic is made via moving it to this status from the other one. There are two possibilities for such action: a. There is a superseding RFC that moves the superseded one to Historic status; and b. There is a separate historicizing RFC that moves the historicized one to Historic. Yevstifeyev Expires August 1, 2011 [Page 5] INTERNET DRAFT Historic RFCs January 28, 2011 The procedures for moving RFCs to Historic, depending on their initial status are described below. 3.2.1. Standards Track RFCs Historicizing of Standards Track RFCs SHALL be made following the 'Standards Action' policies [RFC5226]. The superseding Standards Track RFC MAY move the superseded one only once it has reached the same maturity level as RFC, superseded by it. 3.2.2. Best Current Practices RFCs Best Current Practices (BCP) RFC MAY be historicized only in the case if it is being superseded by the other one. In this case the usual procedure for BCP RFCs SHALL be followed [RFC2026]. 3.2.3. Experimental RFCs Procedures for historicizing Experimental RFCs depend on their origin. If the Experimental RFCs has been processed on IETF stream [RFC4844], 'IETF Consensus' [RFC5226] is REQUIRED to historicize it. If the Experimental RFCs has been processed on IAB stream [RFC4844], 'IETF Consensus' [RFC5226] and IAB Chair approval is REQUIRED to historicize it. If the Experimental RFCs has been processed on IRTF stream [RFC4844], 'IETF Consensus' [RFC5226] and IRTF Chair approval is REQUIRED to historicize it. If the Experimental RFCs has been processed on Independent Submissions stream [RFC4844], 'IETF Consensus' [RFC5226] and authors' approval is REQUIRED to historicize it. In essential cases the approval of the director of the area the historicized document is considered to be related to MAY be used instead the authors' one. 3.2.4. RFCs with No Particular Status RFCs with no particular status (i.e. 'pre-IETF' RFCs) SHALL be moved to Historic following the 'IETF Consensus' policies [RFC5226] with IETF Chair approval. Yevstifeyev Expires August 1, 2011 [Page 6] INTERNET DRAFT Historic RFCs January 28, 2011 4. Other Considerations 4.1. Handling References to Historic RFCs Normative references to Historic RFCs are NOT allowed in any RFCs, on the basis of the state of the referenced document on the date of publication of the referencing document. Informative references to Historic RFCs are allowed in any RFCs. [DISCUSS: Are there any other issues related to Historic docs. that should be discussed here?] Yevstifeyev Expires August 1, 2011 [Page 7] INTERNET DRAFT Historic RFCs January 28, 2011 5. Security Considerations Security issues are not discussed in this document. 6. IANA Considerations None. This section may be deleted. 7. References 7.1. Normative References [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4844] Daigle, L., Ed., and Internet Architecture Board, "The RFC Series and RFC Editor", RFC 4844, July 2007. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. 7.2. Informative References [RFC1310] Chapin, L., "The Internet Standards Process", RFC 1310, March 1992. [RFC1602] Internet Architecture Board and Internet Engineering Steering Group, "The Internet Standards Process -- Revision 2", RFC 1602, March 1994. Author's Addresses Mykyta Yevstifeyev 8 Kuzovkov St., flat 25, Kotovsk, Ukraine EMail: evnikita2@gmail.com Yevstifeyev Expires August 1, 2011 [Page 8]