INTERNET-DRAFT M. Yevstifeyev Intended Status: BCP January 25, 2011 Updates: 2026 (if approved) Expires: July 29, 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 July 29, 2011 [Page 1] INTERNET DRAFT Historic RFCs January 25, 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 . . . . . . . . . . . . . . . . . 5 3.2.2. Best Current Practices RFCs . . . . . . . . . . . . . 6 3.2.3. Experimental RFCs . . . . . . . . . . . . . . . . . . 6 3.2.4. Informational RFCs . . . . . . . . . . . . . . . . . . 6 3.2.5. RFCs with No Particular Status . . . . . . . . . . . . 6 4. Other Considerations . . . . . . . . . . . . . . . . . . . . n 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 July 29, 2011 [Page 2] INTERNET DRAFT Historic RFCs January 25, 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 'hsitoricized 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 July 29, 2011 [Page 3] INTERNET DRAFT Historic RFCs January 25, 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 mentioned in Section 2.1. The Historic status MAY be assigned to RFCs of all categories 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 July 29, 2011 [Page 4] INTERNET DRAFT Historic RFCs January 25, 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. 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. The procedures for moving RFCs to Historic, depending on their initial status are described below. 3.2.1. Standards Track RFCs Standards Track RFCs SHALL be moved to Historic via the 'Standards Action' [RFC5226]. The superseding Standards Track RFC MAY move the superseded one only Yevstifeyev Expires July 29, 2011 [Page 5] INTERNET DRAFT Historic RFCs January 25, 2011 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 moved to Historic 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 Experimental RFCs SHALL be moved to Historic following the 'IETF Consensus' policies [RFC5226]. In the case that historicized RFC has been processed as RFC Editor Independent Submission [RFC5742], the approval of the authors of historicized RFC is REQUIRED. In the case there is no possibility to contact them, the approval of the director of area the historicized RFC is considered to be related to (or IETF Chair, in essential cases) MAY be used instead. IESG is responsible for recording their approval. 3.2.4. Informational RFCs Informational RFCs SHALL meet the following criteria to be considered as appropriate for moving to Historic: a. It meets the criteria of Section 2.1 of this document; b. It specifies the protocol (see Section 4.2.2 of RFC 2026 [RFC2026]); and c. It is not a part of FYI RFC sub-series [RFC1150]. If it meets all these criteria, the procedure for moving it to Historic is 'IETF Consensus' [RFC5226]. 3.2.5. RFCs with No Particular Status RFCs with no particular status (i.e. RFCs with 'Unknown' status) SHALL be moved to Historic following the 'IETF Consensus' policies [RFC5226]. Yevstifeyev Expires July 29, 2011 [Page 6] INTERNET DRAFT Historic RFCs January 25, 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 July 29, 2011 [Page 7] INTERNET DRAFT Historic RFCs January 25, 2011 5. Security Considerations Security issues are not discussed in this document. 6. IANA Considerations None. This section mat 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. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC5742] Alvestrand, H. and R. Housley, "IESG Procedures for Handling of Independent and IRTF Stream Submissions", BCP 92, RFC 5742, December 2009. 7.2. Informative References [RFC1150] Malkin, G. and J. Reynolds, "FYI on FYI: Introduction to the FYI Notes", FYI 1, RFC 1150, March 1990. [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 July 29, 2011 [Page 8] INTERNET DRAFT Historic RFCs January 25, 2011 Yevstifeyev Expires July 29, 2011 [Page 9]