Network Working Group H. Alvestrand Internet-Draft Cisco Systems Updates: 2026 (if approved) E. Lear Expires: February 24, 2005 Cisco Systems GmbH August 26, 2004 Getting rid of the cruft: A procedure to deprecate old standards draft-alvestrand-newtrk-cruft-00.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on February 24, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document describes a procedure for performing the downgrading of old standards described in RFC 2026, as well as BCPs, without placing an unreasonable load on groups charged with performing other tasks in the IETF. It defines a new group, called the "Cruft Committee", which shall recommend to the IESG downgrading or progressing documents on the IETF standards track. Ultimate decisions still rest of with the Alvestrand & Lear Expires February 24, 2005 [Page 1] Internet-Draft On Cruft August 2004 IESG, with appeal to the IAB. A new status of "Outdated" is created. 1. Introduction and history RFC 2026, and RFC 1602 before it, specified timelines for review of immature (draft or proposed) standards. The purpose of such review was to determine whether such documents should be advanced, retired, or developed further.[1] This procedure has never been followed in the history of the IETF. Since this procedure has not been followed, members of the community have suggested that the retiring of a document to Historic is a significant event, which should be justified carefully - leading to the production of documents such as RFC 2556 (OSI connectionless transport services on top of UDP Applicability Statement for Historic Status) and RFC 3166 (Request to Move RFC 1433 to Historic Status). Such documents require significant time and effort on the part of authors, area directors, and the RFC Editor. Indeed such effort should be reserved for advancing or maintaining immature standards. Hence, no document should be required for an immature standard to be retired. 1.1 Outdated Status In this specification we define a new status of outdated. The reason we do not simply reuse historic for everything is that there is at least the perceived implication that historic is dangerous. Whether this is true, the distinction between merely "old and crufty" and "old, crufty, and dangerous" seems like a good one to make, and so we make it here. 1.2 Related Work At the time of this writing there is work under way to revamp standards status information. In particular, the NEWTRK working group has considered a proposal to move such information into web pages and out of the technical documents. This effort is complimentary. Should that effort be accepted by the community, this document should be applied to the document describing the status of a given document or set of documents. 2. New Decommissioning Procedure The decommissioning procedure for standards has the following steps: o The Committee determines that a set of documents is eligible for reclassification according to RFC 2026. It's up to the Committee to decide which documents to tackle next. Alvestrand & Lear Expires February 24, 2005 [Page 2] Internet-Draft On Cruft August 2004 o The Committee attempts to find out whether there are mailing lists or contactable individuals relevant to the technology described in the documents. o For each standard in question, the Committee sends out a message to the IETF list and the lists deemed relevant, asking for implementation experience and active usage. o If there are reports of implementation experience and/or active usage, the RFC is moved into the Committee's Individual Decommissioning Procedure. o The Committee sends to the IESG the remaining list of documents it recommends be reclassified as either Historic or Outdated along with a record of steps taken to identify that standard"s use. That record should include pointers to archives, as well as a log of actions taken to seek out usage. o The IESG will issue a Last Call for community input on all documents in question. o The IESG will respond to the Committee's recommendation with a message to the IETF Announce list. If it agrees to the change in status, the standard is marked Historic. It may also request more information from the Committee or outright disagree. 3. Individual Decommissioning Procedure This procedure is intended for use when one needs to consider more detailed evidence before deciding what to do with a document. Because of the time that has passed without applying the 2026 rule, this document describes three alternatives, not two: o Maintenance on the standards track (per 2026) o Reclassification as Historic (per 2026) o Reclassification as Outdated. Maintenance on the standards track at this point demands attention from the IETF if a document is not full standard. Such a document should either be advanced by the IESG, or a working group should be formed to address its shortcomings. Standards that are unsafe to use should be marked Historic and annotated as mentioned below. The last alternative is intended for cases where the technology is safe, but not reasonable to advance or retain on the standards track. 3.1 Procedure The Committee takes input from all sources it cares to take input from. As it does so it will keep an archive and a record of all such input. Once it determines a recommended action, it sends a recommendation to the IESG along with a pointer to the record, and the IESG will announce this to the IETF community if it agrees with Alvestrand & Lear Expires February 24, 2005 [Page 3] Internet-Draft On Cruft August 2004 the recommendation. 3.2 Evaluation criteria The decision on when to ask for reclassification is made by the Committee. Criteria that should be considered are: o Implementations. A spec that is unimplemented should go to Outdated. o Usage. A protocol or feature that is safe to use but is no longer generally useful should go to Outdated. o Potential for harm. A protocol that is unsafe shall be marked Historical. In the latter case, the danger must be documented in the permanent record either with a brief RFC under current practice, or with a notation kept with the standard status (as envisioned in NEWTRK). o Interest in further work. If there is a reasonable expectation that the specification will be updated or advanced within a reasonable timeframe, the Committee should do nothing. 4. Selection of the Committee NOTE IN DRAFT: This is intended to be simple, and convey the idea that signing up for this is an 1-year stint, not a permanent position. The IESG will send out a call for volunteers for the Cruft Committee once a year, and will choose from the volunteers. A current member of the Committee may volunteer again if he/she wants to. The IESG will appoint as many members to the commission as it deems appropriate, along with a chair. The chair will report every six months via electronic mail to the IETF Announce mailing list on the Committee's progress. The Committee otherwise organizes its own work. The IESG may cut short the term of the Committee and send out a new call for volunteers if it finds that reasonable. 5 Normative References [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. Alvestrand & Lear Expires February 24, 2005 [Page 4] Internet-Draft On Cruft August 2004 Authors' Addresses Harald Tveit Alvestrand Cisco Systems Weidemanns vei 27 Trondheim 7043 NO EMail: harald@alvestrand.no Eliot Lear Cisco Systems GmbH Glatt-com Glattzentrum, ZH CH-8301 Switzerland Phone: +41 1 878 7525 EMail: lear@cisco.com Alvestrand & Lear Expires February 24, 2005 [Page 5] Internet-Draft On Cruft August 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Alvestrand & Lear Expires February 24, 2005 [Page 6]