Procedures for Protocol Extensions and Variations
RFC 4775

 
Document Type RFC - Best Current Practice (December 2006; No errata)
Also known as BCP 125
Was draft-carpenter-protocol-extensions (individual in gen area)
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html
Stream WG state (None)
Consensus Unknown
Document shepherd No shepherd assigned
IESG IESG state RFC 4775 (Best Current Practice)
Telechat date
Responsible AD Ross Callon
Send notices to brc@zurich.ibm.com, sob@harvard.edu

Email authors IPR References Referenced by Nits Search lists

Network Working Group                                         S. Bradner
Request for Comments: 4775                                       Harvard
BCP: 125                                               B. Carpenter, Ed.
Category: Best Current Practice                                T. Narten
                                                                     IBM
                                                           December 2006

           Procedures for Protocol Extensions and Variations

Status of This Memo

   This document specifies an Internet Best Current Practices for the
   Internet Community, and requests discussion and suggestions for
   improvements.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The IETF Trust (2006).

Abstract

   This document discusses procedural issues related to the
   extensibility of IETF protocols, including when it is reasonable to
   extend IETF protocols with little or no review, and when extensions
   or variations need to be reviewed by the IETF community.  Experience
   has shown that extension of protocols without early IETF review can
   carry risk.  The document also recommends that major extensions to or
   variations of IETF protocols only take place through normal IETF
   processes or in coordination with the IETF.

   This document is directed principally at other Standards Development
   Organizations (SDOs) and vendors considering requirements for
   extensions to IETF protocols.  It does not modify formal IETF
   processes.

Bradner, et al.          Best Current Practice                  [Page 1]
RFC 4775           Procedures for Protocol Extensions      December 2006

Table of Contents

   1. Introduction ....................................................2
   2. Technical Risks in Extensions ...................................3
   3. General Considerations ..........................................4
      3.1. The Importance of Interoperability .........................4
      3.2. Registered Values and the Importance of IANA Assignments ...5
      3.3. Significant Extensions Require Technical Review ............5
      3.4. Quality and Consistency ....................................6
      3.5. The Role of Formal Liaisons ................................6
   4. Procedure for Review of Extensions ..............................7
   5. Some Specific Issues ...........................................10
   6. Intellectual Property ..........................................10
   7. Security Considerations ........................................10
   8. IANA Considerations ............................................11
   9. Acknowledgements ...............................................11
   10. References ....................................................11
      10.1. Normative References .....................................11
      10.2. Informative References ...................................12

1.  Introduction

   BCP 9 [RFC2026] is the current definition of the IETF standards
   track.  This process applies not only to the initial definition of a
   protocol, but also to any subsequent updates, such that continued
   interoperability can be guaranteed.  However, it is not always clear
   whether extensions to a protocol should be made within the IETF
   process, especially when they originate outside the IETF community.
   This document lays down guidelines and procedures for such
   extensions.

   When developing protocols, IETF Working Groups (WGs) typically
   include mechanisms whereby these protocols can be extended in the
   future.  It is, of course, a good principle to design extensibility
   into protocols; a common definition of a successful protocol is one
   that becomes widely used in ways not originally anticipated.  Well-
   designed extensibility mechanisms facilitate the evolution of
   protocols and help make it easier to roll out incremental changes in
   an interoperable fashion.  At the same time, experience has shown
   that extensibility features should be limited to what is clearly
   necessary when the protocol is developed, and any later extensions
   should be done carefully and with a full understanding of the base
   protocol, existing implementations, and current operational practice.
   However, it is not the purpose of this document to describe the
   architectural principles of sound extensibility design.

Bradner, et al.          Best Current Practice                  [Page 2]
RFC 4775           Procedures for Protocol Extensions      December 2006

   When extensions to IETF protocols are made within the IETF, the
   normal IETF process is followed, including the normal processes for
   IETF-wide review and IESG approval.  Extensions developed in this way
Show full document text