Network Working Group H. Alvestrand Internet-Draft Cisco Systems Updates: 2026 (if approved) E. Lear Expires: April 1, 2005 Cisco Systems GmbH October 1, 2004 Getting rid of the cruft: A procedure to deprecate old standards draft-ietf-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 April 1, 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 "Historical Standards Committee", which shall recommend to the IESG downgrading or progressing documents on the IETF standards track. Ultimate decisions still rest Alvestrand & Lear Expires April 1, 2005 [Page 1] Internet-Draft On Cruft October 2004 of with the IESG, with appeal to the IAB. 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. 2. Bulk Decommissioning Procedure In order to decommission a standard, the level of the standard MUST be "proposed" or "draft" and the period of time for advancement as specified by RFC 2026 MUST have elapsed. Furthermore, the Committee will consider no document that is being actively revised by an IETF working group. N.B. elapse of time beyond the periods specified in RFC 2026 offers an opportunity and NOT a mandate for review. The Committee should make a judgement as to the appropriateness of a review. The review procedure is as follows: o For each standard to be reviewed, 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. Alvestrand & Lear Expires April 1, 2005 [Page 2] Internet-Draft On Cruft October 2004 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 Announcement list, indicating which standards are marked Historic. o Remaining standards are left unchanged, and are not to be further considered by the Committee for at least another twelve months. 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. 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 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 Usage. A standard that is widely used should probably be left alone (better it should be advanced, but that is beyond the scope of this memo). o Implementation. A standard that is unimplemented is a clear candidate to be reclassified as Historic. o Potential for harm. A protocol that is unsafe where a clearly superior alternative is available should be considered for reclassification to Historic. 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 Alvestrand & Lear Expires April 1, 2005 [Page 3] Internet-Draft On Cruft October 2004 once a year, and will choose from the volunteers, and appoint a chair. A current member of the Committee may volunteer again if he/ she wants to. 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. Acknowledgments Members of the NEWTRK working group reviewed drafts of this memo. 6 Normative References [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 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 April 1, 2005 [Page 4] Internet-Draft On Cruft October 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 April 1, 2005 [Page 5]