1 files changed, 227 insertions, 0 deletions
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]
+