RFC 1264 Is Obsolete
RFC 4794

Document Type RFC - Informational (December 2006; No errata)
Obsoletes RFC 1264
Was draft-fenner-obsolete-1264 (individual in rtg area)
Last updated 2015-10-14
Stream IETF
Formats plain text pdf htmlized bibtex
Reviews
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 4794 (Informational)
Consensus Boilerplate Unknown
Telechat date
Responsible AD Ross Callon
Send notices to (None)
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
Show full document text