From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc4794.txt | 227 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 227 insertions(+) create mode 100644 doc/rfc/rfc4794.txt (limited to 'doc/rfc/rfc4794.txt') diff --git a/doc/rfc/rfc4794.txt b/doc/rfc/rfc4794.txt new file mode 100644 index 0000000..3daa05e --- /dev/null +++ b/doc/rfc/rfc4794.txt @@ -0,0 +1,227 @@ + + + + + + +Network Working Group B. Fenner +Request for Comments: 4794 AT&T Labs - Research +Obsoletes: 1264 December 2006 +Category: Informational + + + RFC 1264 Is Obsolete + +Status 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). + +Abstract + + RFC 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 the RFC 1264 rules just + get in the way. + + + + + + + + + + + + + + + + + + + + + + + + +Fenner Informational [Page 1] + +RFC 4794 RFC 1264 Is Obsolete December 2006 + + +1. Introduction + + RFC 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 reclassifies RFC 1264 as historic. While + that does not prohibit the Routing Area Directors from requiring + implementation and/or operational experience under the RFC 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 on RFC 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 be + + + +Fenner Informational [Page 2] + +RFC 4794 RFC 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 + + While RFC 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 the RFC 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. References + +6.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.com + + + +Fenner Informational [Page 3] + +RFC 4794 RFC 1264 Is Obsolete December 2006 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2006). + + 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. + + 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 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. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + +Fenner Informational [Page 4] + -- cgit v1.2.3