idnits 2.17.1 draft-alvestrand-newtrk-historical-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 7 longer pages, the longest (page 3) being 73 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) -- The draft header indicates that this document updates RFC2026, but the abstract doesn't seem to directly say this. It does mention RFC2026 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year (Using the creation date from RFC2026, updated by this document, for RFC5378 checks: 1995-09-12) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 26, 2004) is 7337 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group H. Alvestrand 2 Internet-Draft E. Lear 3 Updates: 2026 (if approved) Cisco Systems 4 Expires: September 24, 2004 March 26, 2004 6 Moving documents to Historic: A procedure 7 draft-alvestrand-newtrk-historical-00.txt 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at http:// 24 www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 This Internet-Draft will expire on September 24, 2004. 31 Copyright Notice 33 Copyright (C) The Internet Society (2004). All Rights Reserved. 35 Abstract 37 This document describes a procedure for performing the downgrading of 38 old Proposed and Draft standards described in RFC 2026 without 39 placing an unreasonable load on groups charged with performing other 40 tasks in the IETF. 42 It defines a new group, called the "Commission for Protocol 43 Obsolesence", which shall recommend to the IESG downgrading or 44 progressing documents on the IETF standards track. Ultimate 45 decisions still rest of with the IESG, with appeal to the IAB. 47 1. Introduction and history 48 RFC 2026, and RFC 1602 before it, specified timelines for review of 49 immature (draft or proposed) standards. The purpose of such review 50 was to determine whether such documents should be advanced, retired, 51 or developed further.[1] 53 This procedure has never been followed in the history of the IETF. 54 Since this procedure has not been followed, members of the community 55 have suggested that the retiring of a document to Historic is a 56 significant event, which should be justified carefully - leading to 57 the production of documents such as RFC 2556 (OSI connectionless 58 transport services on top of UDP Applicability Statement for Historic 59 Status) and RFC 3166 (Request to Move RFC 1433 to Historic Status). 61 Such documents require significant time and effort on the part of 62 authors, area directors, and the RFC Editor. Indeed such effort 63 should be reserved for advancing or maintaining immature standards. 64 Hence, no document should be required for an immature standard to be 65 retired to Historic status. 67 2. New Decommissioning Procedure 69 The decommissioning procedure for standards has the following steps: 71 o The Commission determines that a set of documents is eligible for 72 reclassification as Historic according to RFC 2026. It's up to the 73 Commission to decide which documents to tackle next. 75 o The Commission attempts to find out whether there are mailing 76 lists or contactable individuals relevant to the technology 77 described in the documents. 79 o For each standard in question, the Commission sends out a message 80 to the IETF list and the lists deemed relevant, asking for 81 implementation experience and active usage. 83 o If there are reports of implementation experience and/or active 84 usage, the RFC is moved into the Commission's Individual 85 Decommissioning Procedure. 87 o The Commission sends to the IESG the remaining list of documents 88 it recommends be reclassified as Historic along with a record of 89 steps taken to identify that standard's use. That record should 90 include pointers to archives, as well as a log of actions taken to 91 seek out usage. 93 o The IESG will respond to the Commission's recommendation with a 94 message to the IETF Announce list. If it agrees to the change in 95 status, the standard is marked Historic. It may also request more 96 information from the Commission or outright disagree. 98 3. Individual Decommissioning Procedure 100 This procedure is intended for use when one needs to consider 101 evidence before deciding what to do with a document. 103 Because of the time that has passed without applying the 2026 rule, 104 this document describes three alternatives, not two: 106 o Maintenance on the standards track (per 2026) 108 o Reclassification as Historic (per 2026) 110 o Reclassification as Informational.(XXX Do we require a new 111 classification?) 113 Maintenance on the standards track at this point demands attention 114 from the IETF if a document is not full standard. Such a document 115 should either be advanced by the IESG, or a working group should be 116 formed to address its shortcomings. The last alternative is intended 117 for cases where the technology is in active use, perhaps in a small 118 community, and it is clearly not reasonable to expect it to advance 119 on the standards track. (XXX DRAFT NOTE: Cannot a small community 120 continue to use a Historic standard, such as, oh, SNMPv1?) 122 3.1 Procedure 124 The Commission takes input from all sources it cares to take input 125 from. As it does so it will keep an archive and a record of all such 126 input. Once it determines a recommended action, it sends a 127 recommendation to the IESG along with a pointer to the record, and 128 the IESG will announce this to the IETF community if it agrees with 129 the recommendation. 131 3.2 Evaluation criteria 133 The decision on when to ask for reclassification is made by the 134 Commission. 136 Criteria that should be considered are: 138 o Implementations. A spec that is unimplemented should go to 139 Historic. 141 o Usage. A protocol or feature that is completely unused should go 142 to Historic. A protocol or feature that is used, and found useful, 143 but only in limited circumstances, should go Informational. XXX 145 o Potential for harm. A protocol or feature that has been shown to 146 create opeational problems that clearly outstrip its benefits 147 should go to Historic even if there is some usage of it. RFC 1137 148 - "Mapping between full RFC 822 and RFC 822 with restricted 149 encoding" - was reclassified for that reason. 151 o Interest in further work. If there is a reasonable expectation 152 that the specification will be updated or advanced within a 153 reasonable timeframe, the Commission should do nothing. 155 4. Selection of the Commission 157 NOTE IN DRAFT: This is intended to be simple, and convey the idea 158 that signing up for this is an 1-year stint, not a permanent 159 position. 161 The IESG will send out a call for volunteers for the Commission once 162 a year, and will choose from the volunteers. A current member of the 163 Commission may volunteer again if he/she wants to. 165 The IESG will appoint as many members to the commission as it deems 166 appropriate, along with a chair. The chair will report every six 167 months via electronic mail to the IETF Announce mailing list on the 168 Commission's progress. 170 The Commission otherwise organizes its own work. 172 The IESG may cut short the term of the commission and send out a new 173 call for volunteers if it finds that reasonable. 175 Normative References 177 [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 178 9, RFC 2026, October 1996. 180 Authors' Addresses 182 Harald Tveit Alvestrand 183 Cisco Systems 184 Weidemanns vei 27 185 Trondheim 7043 186 NO 188 EMail: harald@alvestrand.no 189 Eliot Lear 190 Cisco Systems 191 170 W. Tasman Dr. 192 San Jose, CA 95134 193 US 195 Phone: +1 408 527 4020 196 EMail: lear@cisco.com 198 Intellectual Property Statement 200 The IETF takes no position regarding the validity or scope of any 201 intellectual property or other rights that might be claimed to 202 pertain to the implementation or use of the technology described in 203 this document or the extent to which any license under such rights 204 might or might not be available; neither does it represent that it 205 has made any effort to identify any such rights. Information on the 206 IETF's procedures with respect to rights in standards-track and 207 standards-related documentation can be found in BCP-11. Copies of 208 claims of rights made available for publication and any assurances of 209 licenses to be made available, or the result of an attempt made to 210 obtain a general license or permission for the use of such 211 proprietary rights by implementors or users of this specification can 212 be obtained from the IETF Secretariat. 214 The IETF invites any interested party to bring to its attention any 215 copyrights, patents or patent applications, or other proprietary 216 rights which may cover technology that may be required to practice 217 this standard. Please address the information to the IETF Executive 218 Director. 220 Full Copyright Statement 222 Copyright (C) The Internet Society (2004). All Rights Reserved. 224 This document and translations of it may be copied and furnished to 225 others, and derivative works that comment on or otherwise explain it 226 or assist in its implementation may be prepared, copied, published 227 and distributed, in whole or in part, without restriction of any 228 kind, provided that the above copyright notice and this paragraph are 229 included on all such copies and derivative works. However, this 230 document itself may not be modified in any way, such as by removing 231 the copyright notice or references to the Internet Society or other 232 Internet organizations, except as needed for the purpose of 233 developing Internet standards in which case the procedures for 234 copyrights defined in the Internet Standards process must be 235 followed, or as required to translate it into languages other than 236 English. 238 The limited permissions granted above are perpetual and will not be 239 revoked by the Internet Society or its successors or assignees. 241 This document and the information contained herein is provided on an 242 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 243 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 244 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 245 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 246 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 248 Acknowledgment 250 Funding for the RFC Editor function is currently provided by the 251 Internet Society.