INTERNET-DRAFT M. Yevstifeyev Intended Status: Best Current Practice March 2, 2011 Updates: 2026 (if approved) Expires: September 3, 2011 Clarifying the Historic RFC Maturity Level <draft-yevstifeyev-genarea-historic-03> Abstract This document defined what the Historic RFC maturity level means, what are the criteria for Historic RFCs, describes procedures for republication and reclassification of RFCs in Historic maturity level and discusses other issues related to Historic RFCs. 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 Yevstifeyev Expires September 3, 2011 [Page 1]
INTERNET DRAFT Historic RFCs March 2, 2011 carefully, as they describe your rights and restrictions with respect 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 1.2. Discussion of this Document . . . . . . . . . . . . . . . . 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.3.1. Separate Historicizing Document . . . . . . . . . 6 3.2.3.2. Superseding Document Historicizes the Superseded One . . . . . . . . . . . . . . . . . 7 3.2.4. Informational RFCs . . . . . . . . . . . . . . . . . . 7 3.2.5. RFCs with No Particular Status . . . . . . . . . . . . 7 4. Other Considerations . . . . . . . . . . . . . . . . . . . . . 8 4.1. 'Status of this Memo' Section in Historic RFCs . . . . . . 8 4.2. Handling References to Historic RFCs . . . . . . . . . . . 8 4.3. IANA Considerations in Historic RFCs . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 7. Varying Procedure . . . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 10 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Yevstifeyev Expires September 3, 2011 [Page 2]
INTERNET DRAFT Historic RFCs March 2, 2011 1. Introduction The Historic RFC maturity was firstly mentioned in RFC 1310 [RFC1310], the first document that defined IETF standards process, and its definition remained unchanged in all its revisions - RFC 1602 [RFC1602] and the most current RFC 2026 [RFC2026]. It just says: 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. This description remains many issues opened and uncertain. They include: criteria for Historic RFCs, procedures for republication and reclassification of RFCs in Historic maturity level, references to Historic RFCs, etc. This caused misunderstandings of the community regarding such issues and often using ad-hoc and often undefined procedures for them. This document is to clarify the Historic maturity level and other issues related to it. It updates RFC 2026 [RFC2026]. 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. The definitions of RFC streams, i. e. IETF stream, IAB stream, IRTF stream and Independent Submissions stream, can be found in RFC 4844 [RFC4844]. The terms 'Standards Action' and 'IETF Consensus' are described in Section 4.1 of RFC 5226 [RFC5226] The term 'historicizing RFC' means the RFC that makes another one Historic. The term 'historicized RFC' means the RFC that is made 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. 1.2. Discussion of this Document Discussion of this document SHALL occure on IETF Discussion mailing list [RFC3005] until and unless any of the ADs will create the separate list. This section MUST be deleted upon publication of this document. Yevstifeyev Expires September 3, 2011 [Page 3]
INTERNET DRAFT Historic RFCs March 2, 2011 2. Historic Status Definition The Historic maturity is used to identify that the particular RFC is obsolete (i.e. outdated), superseded or deprecated. The criteria the RFC should meet to be considered as obsolete, superseded or deprecated are discussed in Section 2.1. Historic RFC maturity level is a kind of caveat emptor, that notifies the reader that they SHOULD be careful with the implementation of the described technology since it is not advised to be used for some reason. But Historic maturity level does NOT restrict any implementations of the described technology. 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 protocol or technology, described in this RFC has not been seen used in the Internet (i. e. no interoperable implementations have appeared during this time) or it has been implemented early in the process of testing of this technology, but further implementations have not appeared. The RFC SHALL be considered to be deprecated if it meets at least one of the following criteria: a. There is another technology, that, in fact, does not supersedes the technology described in such RFC, but just provides more aceptable alternative, and, therefore, makes it 'predecessor' NOT RECOMMENDED to be used; b. The technology, described in it contains a design flaw or provides some risk of danger to the Internet and SHOULD be avoided; c. It described the technology that might create serious problems with its implementation or makes them impossible. Yevstifeyev Expires September 3, 2011 [Page 4]
INTERNET DRAFT Historic RFCs March 2, 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 will become the superseding document for the historicized one (when approved) SHALL be issued. The technical content of this Internet-Draft MUST be the same as in the historicized RFC. Such document SHALL contain the 'Historic Considerations' section clarifying the reason of republication the document in Historic maturity level. Such republication proposal SHALL firstly be discussed at the appropriate mailing list, if any, or on the IETF Discussion mailing list [RFC3005]. If the authors are sure that there is at least rough consensus on such action, they should apply to IESG to request the IETF-wide Last Call for republication the particular document in Historic maturity level. If the Last Call revealed the wide consensus of the community, the corresponding RFC will be republished as Historic document. There are a number of cases when the approval of another parties is needed for republication of RFC in Historic maturity level. In particular, if the historicized document has been processed on IAB Stream, the approval of IAB Chair [RFC2850] is REQUIRED for historicizing such document. If the document has been processed on IRTF or Independent Submissions Streams, the approval of IRTF Chair [RFC2014] or the authors of the document (or the directors of the area the document is considered to be related to, in exceptional 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: Yevstifeyev Expires September 3, 2011 [Page 5]
INTERNET DRAFT Historic RFCs March 2, 2011 a. There is a superseding RFC that moves the superseded one to Historic maturity level; and b. There is a separate historicizing RFC that moves the historicized one to Historic maturity level. The procedures for moving RFCs to Historic, depending on their initial status are described below. For examples of the RFCs that perform such action see RFC 4223 [RFC4223] or RFC 5125 [RFC5125]. 3.2.1. Standards Track RFCs Historicizing of Standards Track RFCs SHALL be made following the 'IETF Consensus' policies. 3.2.2. Best Current Practices RFCs Best Current Practices (BCP) [RFC1818] 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 and the way it is being historicized, as follows. 3.2.3.1. Separate Historicizing Document The procedures described in this section apply to the case, mentioned as 'b' at the beginning of Section 3.2 (separate historicizing document). If the Experimental RFCs has been processed on IETF stream, 'IETF Consensus' is REQUIRED to historicize it. If the Experimental RFCs has been processed on IAB stream, 'IETF Consensus' and IAB Chair [RFC2850] approval is REQUIRED to historicize it. If the Experimental RFCs has been processed on IRTF stream, 'IETF Consensus' and IRTF Chair [RFC2014] approval is REQUIRED to historicize it. If the Experimental RFCs has been processed on Independent Submissions stream, 'IETF Consensus' and authors' approval is REQUIRED to historicize it. In exceptional 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. Yevstifeyev Expires September 3, 2011 [Page 6]
INTERNET DRAFT Historic RFCs March 2, 2011 In the cases described above IESG is responsible for recording their approval. 3.2.3.2. Superseding Document Historicizes the Superseded One The procedures described in this section apply to the case, mentioned as 'a' at the beginning of Section 3.2 (superseding document historicizes the superseded one). The superseding document that is being processed only on the same stream as the superseded one MAY historicize it. A simple mention of such action is therefore REQUIRED in superseding document. 3.2.4. Informational RFCs In order to consider the Informational RFC to be appropriate for assigning it the Historic maturity level, it SHALL meet the following criteria: a. It describes the protocol or other technology (see Section 4.2.2 of RFC 2026 [RFC2026]); b. It is not a part of FYI sub-series [RFC1150]; and c. It meets the criteria of Section 2 of this document. The procedures for historicizing such RFCs are the same as for Experimental ones, described in Section 3.2.3. 3.2.5. RFCs with No Particular Status RFCs with no particular status (see [RFCNOSTATUS]) SHALL be moved to Historic following the 'IETF Consensus' policies. Yevstifeyev Expires September 3, 2011 [Page 7]
INTERNET DRAFT Historic RFCs March 2, 2011 4. Other Considerations 4.1. 'Status of this Memo' Section in Historic RFCs This document does not modify the boilerplates for 'Status of this Memo' sections in Historic RFCs described in RFC 5741 [RFC5741]. 4.2. Handling References to Historic RFCs Normative references to Historic RFCs SHALL be handled as described in RFC 3967 [RFC3967]. Informative references to Historic RFCs are allowed in any RFCs. 4.3. IANA Considerations in Historic RFCs The historicized document may have requested some action from IANA, that are already performed. In this case the historicizing document MUST clearly mention whether any action from IANA is needed once such document becomes Historic. [DISCUSS: Are there any other issues related to Historic docs. that should be discussed here?] 5. Security Considerations Security issues are not discussed in this document. 6. IANA Considerations None. This section may be deleted. 7. Varying Procedure Varying procedure described in RFC 2026 [RFC2026] still applies to this document. 8. References 8.1. Normative References [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. Yevstifeyev Expires September 3, 2011 [Page 8]
INTERNET DRAFT Historic RFCs March 2, 2011 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3967] Bush, R. and T. Narten, "Clarifying when Standards Track Documents may Refer Normatively to Documents at a Lower Level", BCP 97, RFC 3967, December 2004. [RFC4844] Daigle, L., Ed., and Internet Architecture Board, "The RFC Series and RFC Editor", RFC 4844, July 2007. This document makes the downgrade reference to RFC 4844 (Informational RFC). The procedure of RFC 3967, then, SHALL be applied to this document during IETF Last Call. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. 8.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. [RFC1818] Postel, J., Li, T., and Y. Rekhter, "Best Current Practices", RFC 1818, August 1995. [RFC2014] Weinrib, A. and J. Postel, "IRTF Research Group Guidelines and Procedures", BCP 8, RFC 2014, October 1996. [RFC2850] Internet Architecture Board and B. Carpenter, Ed., "Charter of the Internet Architecture Board (IAB)", BCP 39, RFC 2850, May 2000. [RFC3005] Harris, S., "IETF Discussion List Charter", BCP 45, RFC 3005, November 2000. [RFC4223] Savola, P., "Reclassification of RFC 1863 to Historic", RFC 4223, October 2005. [RFC5125] Taylor, T., "Reclassification of RFC 3525 to Historic", Yevstifeyev Expires September 3, 2011 [Page 9]
INTERNET DRAFT Historic RFCs March 2, 2011 RFC 5125, February 2008. [RFC5741] Daigle, L., Ed., Kolkman, O., Ed., and IAB, "RFC Streams, Headers, and Boilerplates", RFC 5741, December 2009. [RFCNOSTATUS] RFC Editor, "The List of Unclassified RFCs", <http://www.rfc-editor.org/categories/rfc-unknown.html> Appendix A. Acknowledgments The comments from Doug Ewell, George Wes . . TBD . . were useful for this document. Author's Addresses Mykyta Yevstifeyev 8 Kuzovkov St., flat 25, Kotovsk, Ukraine EMail: evnikita2@gmail.com Yevstifeyev Expires September 3, 2011 [Page 10]