idnits 2.17.1 draft-fenner-obsolete-1264-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 170. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 181. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 188. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 194. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC1264, but the abstract doesn't seem to directly say this. It does mention RFC1264 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 -- 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 (July 11, 2006) is 6499 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 1264 (Obsoleted by RFC 4794) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Fenner 3 Internet-Draft AT&T Labs - Research 4 Obsoletes: 1264 (if approved) July 11, 2006 5 Intended status: Informational 6 Expires: January 12, 2007 8 RFC 1264 is Obsolete 9 draft-fenner-obsolete-1264-03 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 12, 2007. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 RFC 1264 was written during what was effectively a completely 43 different time in the life of the Internet. It prescribed rules to 44 protect the Internet against new routing protocols that may have 45 various undesirable properties. In today's Internet, there are so 46 many other pressures against deploying unreasonable protocols that we 47 believe that existing controls suffice, and the RFC 1264 rules just 48 get in the way. 50 1. Introduction 52 RFC 1264 [RFC1264] describes various rules to be applied when 53 publishing routing protocols on the IETF Standards Track, including 54 requirements for implementation, MIBs, security, etc. These rules 55 were written in an attempt to protect the Internet from incomplete or 56 unscalable new protocols. 58 Today, one of the big problems the IETF faces is timeliness. 59 Applying additional rules to a certain class of protocols hurts the 60 IETF's ability to publish specifications in a timely manner. 62 The current standards process [RFC2026] already permits the IESG to 63 require additional implementation experience when it appears to be 64 needed. We do not need any more rules than that. RFC 2026 says: 66 Usually, neither implementation nor operational experience is 67 required for the designation of a specification as a Proposed 68 Standard. However, such experience is highly desirable, and will 69 usually represent a strong argument in favor of a Proposed 70 Standard designation. 72 The IESG may require implementation and/or operational experience 73 prior to granting Proposed Standard status to a specification that 74 materially affects the core Internet protocols or that specifies 75 behavior that may have significant operational impact on the 76 Internet. 78 2. RFC 1264 is Obsolete 80 Therefore, this document reclassifies RFC 1264 as historic. While 81 that does not prohibit the Routing Area Directors from requiring 82 implementation and/or operational experience under the RFC 2026 83 rules, it removes the broad, general requirement from all routing 84 documents. 86 3. Working Group Procedures 88 Some working groups within the Routing Area have developed 89 procedures, based on RFC 1264, to require implementations before 90 forwarding a document to the IESG. This action does not prevent 91 those working groups from continuing with these procedures if the 92 working group prefers to work this way. We encourage working groups 93 to put measures in place to improve the quality of their output. 95 RFC 1264 required a MIB module to be in development for a protocol; 96 this is still encouraged in a broad sense. This is not meant to be 97 limiting, however; protocol management and manageability should be 98 considered in the context of current IETF management protocols. In 99 addition, [I-D.farrel-rtg-manageability-requirements] contains a 100 description of a "Manageability Requirements" section; this is not 101 currently a requirement but should be considered. 103 4. IANA Considerations 105 This document makes no request of IANA. 107 Note to RFC Editor: this section may be removed on publication as an 108 RFC. 110 5. Security Considerations 112 While RFC 1264's rules placed additional constraints on the security- 113 related contents of an RFC, current policies (e.g., the requirement 114 for a Security Considerations section) suffice. 116 6. Acknowledgements 118 Alex Zinin and Bill Fenner spent a great deal of time trying to 119 produce an updated version of the RFC 1264 rules that would apply to 120 today's Internet. This work was eventually abandoned when it was 121 realized (after much public discussion at Routing Area meetings, 122 Internet Area meetings, and on the Routing Area mailing list) that 123 there was just no way to write the rules in a way that advanced the 124 goals of the IETF. 126 7. References 128 7.1. Normative References 130 [RFC1264] Hinden, R., "Internet Engineering Task Force Internet 131 Routing Protocol Standardization Criteria", RFC 1264, 132 October 1991. 134 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 135 3", BCP 9, RFC 2026, October 1996. 137 7.2. Informative References 139 [I-D.farrel-rtg-manageability-requirements] 140 Farrel, A., "Requirements for Manageability Sections in 141 Routing Area Drafts", 142 draft-farrel-rtg-manageability-requirements-01 (work in 143 progress), October 2005. 145 Author's Address 147 Bill Fenner 148 AT&T Labs - Research 149 1 River Oaks Place 150 San Jose, CA 95134-1918 151 USA 153 Phone: +1 408 493-8505 154 Email: fenner@research.att.com 156 Full Copyright Statement 158 Copyright (C) The Internet Society (2006). 160 This document is subject to the rights, licenses and restrictions 161 contained in BCP 78, and except as set forth therein, the authors 162 retain all their rights. 164 This document and the information contained herein are provided on an 165 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 166 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 167 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 168 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 169 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 170 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 172 Intellectual Property 174 The IETF takes no position regarding the validity or scope of any 175 Intellectual Property Rights or other rights that might be claimed to 176 pertain to the implementation or use of the technology described in 177 this document or the extent to which any license under such rights 178 might or might not be available; nor does it represent that it has 179 made any independent effort to identify any such rights. Information 180 on the procedures with respect to rights in RFC documents can be 181 found in BCP 78 and BCP 79. 183 Copies of IPR disclosures made to the IETF Secretariat and any 184 assurances of licenses to be made available, or the result of an 185 attempt made to obtain a general license or permission for the use of 186 such proprietary rights by implementers or users of this 187 specification can be obtained from the IETF on-line IPR repository at 188 http://www.ietf.org/ipr. 190 The IETF invites any interested party to bring to its attention any 191 copyrights, patents or patent applications, or other proprietary 192 rights that may cover technology that may be required to implement 193 this standard. Please address the information to the IETF at 194 ietf-ipr@ietf.org. 196 Acknowledgment 198 Funding for the RFC Editor function is provided by the IETF 199 Administrative Support Activity (IASA).