Movatterモバイル変換

Network Working Group                                          B. FennerRequest for Comments: 4794                          AT&T Labs - ResearchObsoletes:1264                                            December 2006Category: InformationalRFC 1264 Is ObsoleteStatus of This Memo   This memo provides information for the Internet community.  It does   not specify an Internet standard of any kind.  Distribution of this   memo is unlimited.Copyright Notice   Copyright (C) The IETF Trust (2006).AbstractRFC 1264 was written during what was effectively a completely   different time in the life of the Internet.  It prescribed rules to   protect the Internet against new routing protocols that may have   various undesirable properties.  In today's Internet, there are so   many other pressures against deploying unreasonable protocols that we   believe that existing controls suffice, and theRFC 1264 rules just   get in the way.Fenner                       Informational                      [Page 1]

RFC 4794RFC 1264 Is Obsolete             December 20061.  IntroductionRFC 1264 [RFC1264] describes various rules to be applied when   publishing routing protocols on the IETF Standards Track, including   requirements for implementation, MIBs, security, etc.  These rules   were written in an attempt to protect the Internet from incomplete or   unscalable new protocols.   Today, one of the big problems the IETF faces is timeliness.   Applying additional rules to a certain class of protocols hurts the   IETF's ability to publish specifications in a timely manner.   The current standards process [RFC2026] already permits the IESG to   require additional implementation experience when it appears to be   needed.  We do not need any more rules than that.RFC 2026 says:      Usually, neither implementation nor operational experience is      required for the designation of a specification as a Proposed      Standard.  However, such experience is highly desirable, and will      usually represent a strong argument in favor of a Proposed      Standard designation.      The IESG may require implementation and/or operational experience      prior to granting Proposed Standard status to a specification that      materially affects the core Internet protocols or that specifies      behavior that may have significant operational impact on the      Internet.2.RFC 1264 Is Obsolete   Therefore, this document reclassifiesRFC 1264 as historic.  While   that does not prohibit the Routing Area Directors from requiring   implementation and/or operational experience under theRFC 2026   rules, it removes the broad, general requirement from all routing   documents.3.  Working Group Procedures   Some working groups within the Routing Area have developed   procedures, based onRFC 1264, to require implementations before   forwarding a document to the IESG.  This action does not prevent   those working groups from continuing with these procedures if the   working group prefers to work this way.  We encourage working groups   to put measures in place to improve the quality of their output.RFC 1264 required a MIB module to be in development for a protocol;   this is still encouraged in a broad sense.  This is not meant to be   limiting, however; protocol management and manageability should beFenner                       Informational                      [Page 2]

RFC 4794RFC 1264 Is Obsolete             December 2006   considered in the context of current IETF management protocols.  In   addition, [RTG-REQS] contains a description of a "Manageability   Requirements" section; this is not currently a requirement but should   be considered.4.  Security Considerations   WhileRFC 1264's rules placed additional constraints on the   security-related contents of an RFC, current policies (e.g., the   requirement for a Security Considerations section) suffice.5.  Acknowledgements   Alex Zinin and Bill Fenner spent a great deal of time trying to   produce an updated version of theRFC 1264 rules that would apply to   today's Internet.  This work was eventually abandoned when it was   realized (after much public discussion at Routing Area meetings,   Internet Area meetings, and on the Routing Area mailing list) that   there was just no way to write the rules in a way that advanced the   goals of the IETF.6.  References6.1.  Normative References   [RFC1264]  Hinden, R., "Internet Engineering Task Force Internet              Routing Protocol Standardization Criteria",RFC 1264,              October 1991.   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision              3",BCP 9,RFC 2026, October 1996.6.2.  Informative References   [RTG-REQS] Farrel, A., Andersson, L., and A. Doria, "Requirements for              Manageability Sections in Routing Area Drafts", Work in              Progress, October 2005.Author's Address   Bill Fenner   AT&T Labs - Research   1 River Oaks Place   San Jose, CA  95134-1918   USA   Phone: +1 408 493-8505   EMail: fenner@research.att.comFenner                       Informational                      [Page 3]

RFC 4794RFC 1264 Is Obsolete             December 2006Full Copyright Statement   Copyright (C) The IETF Trust (2006).   This document is subject to the rights, licenses and restrictions   contained inBCP 78, and except as set forth therein, the authors   retain all their rights.   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, THE IETF TRUST,   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.Intellectual Property   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 inBCP 78 andBCP 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 athttp://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.Acknowledgement   Funding for the RFC Editor function is currently provided by the   Internet Society.Fenner                       Informational                      [Page 4]