[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 rfc4775                                        
Network Working Group                                         S. Bradner
Internet-Draft                                                   Harvard
Intended status: Best Current                          B. Carpenter (ed)
Practice                                                       T. Narten
Expires: March 12, 2007                                              IBM
                                                       September 8, 2006

           Procedures for protocol extensions and variations

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on March 12, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).


   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 larger IETF community.
   Experience with IETF protocols has shown that extensibility of
   protocols without early IETF review can cause problems.  The document

Bradner, et al.          Expires March 12, 2007                 [Page 1]

Internet-Draft     Procedures for protocol extensions     September 2006

   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

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  General Considerations . . . . . . . . . . . . . . . . . . . .  4
     2.1.  Quality and Consistency  . . . . . . . . . . . . . . . . .  4
     2.2.  Registered Values and the Importance of IANA
           Assignments  . . . . . . . . . . . . . . . . . . . . . . .  4
     2.3.  All extensions require technical review  . . . . . . . . .  5
   3.  Procedure for Review of Extensions . . . . . . . . . . . . . .  6
   4.  Some Specific Issues . . . . . . . . . . . . . . . . . . . . .  8
   5.  Intellectual Property  . . . . . . . . . . . . . . . . . . . .  9
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
   9.  Change log [RFC Editor: please remove this section]  . . . . . 10
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 10
     10.2. Informative References . . . . . . . . . . . . . . . . . . 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
   Intellectual Property and Copyright Statements . . . . . . . . . . 13

Bradner, et al.          Expires March 12, 2007                 [Page 2]

Internet-Draft     Procedures for protocol extensions     September 2006

1.  Introduction

   For the origins of this draft, please see the Acknowledgements

   BCP 9 [RFC2026] is the current definition of the IETF standards
   track.  It is implicitly presumed that this process will apply 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 fall within this presumption, especially when they originate
   outside the IETF community.  This document lays down procedures for
   such extensions.

   When developing protocols, IETF working groups typically include
   mechanisms whereby these protocols can be extended in the future.  In
   addition to the IETF itself, vendors, standards development
   organizations and technology fora have used those facilities.
   Although the results are often good, protocol extensions can also
   result in poorly designed mechanisms and in non-interoperability.

   It is of course a good principle to design extensibility into
   protocols; one 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.

   When extensions to IETF protocols are made within the IETF, the
   normal IETF process is followed, including the normal process for
   IETF-wide review, and approval by the IESG.  It is presumed that this
   will ensure that extensions developed in this way will respect all
   applicable architectural principles and technical criteria.

   When extensions to IETF protocols are made outside the IETF and
   without consulting the IETF, experience has shown that they may not
   be done with the full understanding of why the existing protocol was
   designed the way that it is - e.g., what ideas were brought up during
   the original development and rejected because of some problem with
   them.  Also such extensions could, because of a lack of
   understanding, negate some key function of the existing protocol
   (such as security or congestion control).  Short-sighted design

Bradner, et al.          Expires March 12, 2007                 [Page 3]

Internet-Draft     Procedures for protocol extensions     September 2006

   choices are sometimes made, and basic underlying architectural
   principles of the protocol are sometimes violated.  Of course, the
   IETF itself is not immune to such mistakes, suggesting a need for
   working groups to document their design decisions (including paths
   rejected) and some rationale for those decisions, for the benefit of
   both those within IETF and those outside of IETF.

   Additionally, documentation of non-IETF extensions can be hard to
   obtain, so assessing the quality of the specification is hard and
   achieving interoperability can be hard.  Also, there is a risk that
   mutually incompatible extensions may be developed independently.

   Simply put, the early peer review by experienced subject matter
   experts that occurs within the IETF process may be lacking,
   regardless of the competence or efficiency of the outside

   All that can be said about extensions applies with equal or greater
   force to variations - in fact, by definition, protocol variations
   damage interoperability.  They must therefore be intensely
   scrutinized.  Throughout this document, what is said about extensions
   also applies to variations.

   This document is focussed on appropriate process and practices to
   ensure that extensions developed outside the IETF will not fall into
   these traps and therefore become useless or, worse, damaging to
   interoperability.  Architectural considerations are documented
   elsewhere.  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

2.  General Considerations

2.1.  Quality and Consistency

   In order to be adequately reviewed by relevant experts, a proposed
   extension must be documented in a clear and well-written
   specification normally published as an Internet Draft, which must be
   sufficiently consistent in terminology and content with the
   unextended specification that these experts can readily identify the
   technical changes proposed at an early stage.

2.2.  Registered Values and the Importance of IANA Assignments

   An extension is often likely to make use of additional values added
   to an existing IANA registry (in many cases, simply by adding a new

Bradner, et al.          Expires March 12, 2007                 [Page 4]

Internet-Draft     Procedures for protocol extensions     September 2006

   "TLV" (type-length-value) field).  It is essential that such new
   values are properly registered by the applicable procedures,
   including expert review where applicable (see BCP 26, [RFC2434]).
   Extensions may even need to create new IANA registries in some cases.

   Experience shows that the importance of this is often underestimated
   during extension design; designers sometimes assume that a new
   codepoint is theirs for the asking, or even simply for the taking.
   This is hazardous; it is far too likely that someone just taking a
   protocol value will find that the same value will later be formally
   assigned to another function, thus guaranteeing an interoperability

   In many cases IANA assignment requests trigger a thorough technical
   review of the proposal by a designated IETF expert reviewer.
   Requests are sometimes refused after such a review.  Thus, extension
   designers must pay particular attention to any needed IANA
   assignments and to the applicable criteria.

2.3.  All extensions require technical review

   Some extensions may be considered minor (e.g. adding a
   straightforward new TLV to an application protocol, which will only
   impact a subset of hosts) and some may be considered major (e.g.
   adding a new IP option type, which will potentially impact every node
   on the Internet).  This is essentially a matter of judgement.  It
   could be argued that anything requiring at most Expert Review in
   [RFC2434] is probably minor, and anything beyond that is major.
   However, even an apparently minor extension may have unforeseen
   consequences on interoperability.  Thus, the distinction between
   major and minor is less important than ensuring that the right amount
   of technical review takes place in either case.  The expertise for
   such review for IETF protocols lies within the IETF.

   For example, RADIUS [RFC2865] is designed to carry attributes and
   allow definition of new attributes.  But it is important that
   discussion of new attributes involve the IETF community of experts
   knowledgeable about the protocol's architecture and existing usage in
   order to fully understand the implications of a proposed extension.
   Adding new attributes without such discussion creates a high risk of
   interoperability or functionality failure.  For this reason among
   others, the IETF has an active RADIUS Extensions working group at the
   time of writing.

   Thus the only safe rule is that, even if an extension appears minor
   to the person proposing it, early review by subject matter experts is
   always advisable.  The proper forum for such review is the IETF,
   either in the relevant Working Group, or by individual IETF experts

Bradner, et al.          Expires March 12, 2007                 [Page 5]

Internet-Draft     Procedures for protocol extensions     September 2006

   if no such WG exists.

   There may sometimes be doubt whether a particular proposal is or is
   not truly a protocol extension.  When in doubt, it is preferable to
   err on the side of additional review.  However, it should be noted
   that if an 'extension' only consists of registering a new value with
   IANA in a First Come First Served registry [RFC2434], this document
   is not intended to require formal IETF review.  Informal review by
   experts may nevertheless be valuable.

3.  Procedure for Review of Extensions

   In some cases, explicit provision is made in the relevant RFCs for
   extending individual IETF protocols.  Nothing in this document
   overrides such procedures.  Some such cases are mentioned in
   Section 4.

   There are several ways in which an extension to an IETF protocol can
   be considered for publication as an RFC:
   1.  Extensions to IETF protocols developed within the IETF will be
       subject to the normal IETF process, exactly like new designs.  It
       is not suggested that this is a panacea; appropriate cross-
       working-group and cross-Area review is needed within the IETF to
       avoid oversights and mistakes.
   2.  Extensions to IETF protocols discussed in an IRTF Research Group
       may well be the prelude to regular IETF discussion.  However, a
       Research Group may desire to specify an experimental extension
       before the work is mature enough for IETF processing.  In this
       case, the Research Group is required to involve appropriate IETF
       or IANA experts in their process to avoid oversights.
   3.  Extensions to IETF protocols described in Independent Submissions
       to the RFC Editor are subject to IESG review, currently described
       in BCP 92 [RFC3932].  If appropriate, the IESG advises the RFC
       Editor that full IETF processing is needed, or that relevant IANA
       procedures need to be followed before publication can proceed.
       Note that Independent Submissions cannot be placed on the IETF
       Standards Track; they would need to enter full IETF processing.

   Where vendors or other Standards Development Organisations (SDOs) see
   a requirement for extending an IETF protocol, their first step should
   be to select the most appropriate of the above three routes.  Regular
   IETF process is most likely to be suitable, assuming sufficient
   interest can be found in the IETF community.  IRTF process is
   unlikely to be suitable unless there is a genuine research context
   for the proposed extension.

   In the case of an SDO that identifies a requirement for a

Bradner, et al.          Expires March 12, 2007                 [Page 6]

Internet-Draft     Procedures for protocol extensions     September 2006

   standardised extension, a standards development process within the
   IETF (while maintaining appropriate liaison) is strongly recommended
   in preference to publishing a non-IETF standard.  Otherwise, the
   implementor community will be faced with a standard split into two or
   more parts in different styles, obtained from different sources, with
   no unitary control over quality, compatibility, interoperability, and
   intellectual property conditions.  Note that, since participation in
   the IETF is open, there is no formality or restriction for
   participants in other SDOs choosing to work in the IETF as well.  In
   some cases (see Section 4) the IETF has well defined procedures for
   this in place.

   Naturally, SDOs can and do develop scenarios, requirements and
   architectures based on IETF specifications.  It is only actual
   protocol extensions and changes that need to go through the IETF
   process.  However, there is still a large potential for harm if
   significant investment is made in planning stages for use of IETF
   technology without early review and feedback from the IETF.  Other
   SDOs are encouraged to communicate informally or formally with the
   IETF as early as possible, to avoid false starts.  Early technical
   review in a collaborative spirit is of great value.  Each SDO can
   "own" its ideas and discuss them in its own fora, but should start
   talking to the IETF experts about those ideas the moment the idea is
   well formulated.  It is understood that close collaboration may be
   needed in order that the IETF experts correctly understand the
   systems architecture envisaged by the other SDO.  This is much
   preferable to a situation where another SDO presents the IANA and the
   IETF with a 'fait accompli.'

   Vendors that identify a requirement for an extension are strongly
   recommended to start informal discussion in the IETF and to publish a
   preliminary Internet Draft describing the requirements.  This will
   allow the vendor, and the community, to evaluate whether there is
   community interest and whether there are any major or fundamental
   issues.  However, in the case of a vendor that identifies a
   requirement for a proprietary extension that does not generate
   interest in the IETF (or IRTF) communities, an Independent Submission
   to the RFC Editor is strongly recommended in preference to publishing
   a proprietary document, unless preliminary IETF discussion has
   already revealed serious flaws in the proposal.  Not only does this
   bring the draft to the attention of the community; it also ensures a
   minimum of community review [RFC3932], and (if published) makes the
   proprietary extension available to the whole community.

   If, despite these strong recommendations, a vendor or SDO does choose
   to publish its own specification for an extension to an IETF
   protocol, the following guidance applies:

Bradner, et al.          Expires March 12, 2007                 [Page 7]

Internet-Draft     Procedures for protocol extensions     September 2006

   o  Extensions to IETF protocols should be well, and publicly,
      documented, and reviewed at an early stage by the IETF community
      to be sure that the extension does not undermine basic assumptions
      and safeguards designed into the protocol, such as security
      functions, or undermine its architectural integrity.
   o  Vendors and other SDOs are formally requested to submit any such
      proposed publications for IETF review, by an established liaison
      channel if it exists, or by direct communication with relevant
      working group or with the IESG.  This should be done at an early
      stage, before a large investment of effort has taken place, in
      case basic problems are revealed.  When there is a formal liaison
      in place between the other SDO and the IETF, the liaison channel
      should be used to ensure that review takes place, both by relevant
      experts and by established review teams or Directorates within the
      IETF.  If there is no formal liaison, the other SDO or vendor
      should ask the IESG (or a relevant Area Director) to obtain such
      reviews.  Note that general aspects such as security,
      internationalization and management may need review, as well as
      the protocol as such.
   o  In the case of extensions involving only routine IANA parameter
      assignments, for which there is an underlying IETF specification
      containing clear IANA Considerations, this request is satisfied as
      long as those considerations are satisfied (see [RFC2434]).
      Anything beyond this requires an explicit protocol review by
      experts within the IETF.
   o  Note that, like IETF specifications, such proposed publications
      must include an IANA considerations section to ensure that
      protocol parameter assignments that are needed to deploy
      extensions are not made until after a proposed extension has
      received adequate review, and then to ensure that IANA has precise
      guidance on how to make those assignments.

4.  Some Specific Issues

   It is relatively common for MIB modules, which are all in effect
   extensions of the SMI data model, to be defined or extended outside
   the IETF.  BCP 111 [RFC4181] offers detailed guidance for authors and

   A number of protocols have foreseen experimental values for certain
   IANA parameters, so that experimental usages and extensions may be
   tested without need for a special parameter assignment.  It must be
   stressed that such values are not intended for production use or as a
   way to evade the type of technical review described in this document.
   See [RFC3692] and [I-D.fenner-iana-exp-2780].

   There are certain documents that specify a change process for

Bradner, et al.          Expires March 12, 2007                 [Page 8]

Internet-Draft     Procedures for protocol extensions     September 2006

   specific IETF protocols, such as:
      The SIP change process [RFC3427]
      The (G)MPLS change process [I-D.andersson-rtg-gmpls-change]

   This document does not override such specific change processes.

5.  Intellectual Property

   All IETF documents fall under the IETF's intellectual property rules,
   BCP 78 [RFC3978] and BCP 79 [RFC3979], as amended.  In particular,
   there are restrictions on the production of derivative works, and
   there are rights that remain with the original authors.  Anybody
   outside the IETF considering an extension based on an IETF document
   must bear these legal restrictions and rights in mind.

6.  Security Considerations

   An extension must not introduce new security risks without also
   providing an adequate counter-measure, and in particular it must not
   inadvertently defeat security measures in the unextended protocol.
   This aspect must always be considered during IETF review.

7.  IANA Considerations

   The IETF requests IANA to pay attention to the requirements of this
   document when requested to make protocol parameter assignments for
   vendors or other SDOs, i.e. to respect the IANA Considerations of all
   RFCs that contain them, and the general considerations of BCP 26

8.  Acknowledgements

   This document is heavily based on an earlier draft under a different
   title by Scott Bradner and Thomas Narten.

   That earlier draft stated: The initial version of this document was
   put together by the IESG in 2002.  Since then, it has been reworked
   in response to feedback from John Loughney, Henrik Levkowetz, Mark
   Townsley, Randy Bush, Bernard Aboba, and others.

   Ted Hardie, Scott Brim, Dan Romascanu, Jari Arkko, Loa Andersson,
   Adrian Farrel, Roy Fielding, Keith Moore, Bernard Aboba, Elwyn
   Davies, Stephen Trowbridge, and Ted Ts'o also made valuable comments
   on this document.

Bradner, et al.          Expires March 12, 2007                 [Page 9]

Internet-Draft     Procedures for protocol extensions     September 2006

   This document was produced using the xml2rfc tool [RFC2629].

9.  Change log [RFC Editor: please remove this section]

   This draft replaces draft-iesg-vendor-extensions.

   draft-carpenter-protocol-extensions-02: 2006-09-08.  Clarifications
   in response to IETF Last Call comments.  Most significantly,
   clarified that this document does not override change processes that
   have been documented for specific protocols.  Updated authorship.

   draft-carpenter-protocol-extensions-01: 2006-08-04.  Removed
   additional architectural material, added material on MIBs,
   experimental values and IPR, reflected other comments.  Extended
   scope to cover variations as well as extensions.  Updated authorship.

   draft-carpenter-protocol-extensions-00: original version, 2006-06-16.
   Derived from draft-iesg-vendor-extensions-02.txt dated 2004-06-04 by
   focussing on procedural issues; the more architectural issues in that
   draft are left to a separate document.

10.  References

10.1.  Normative References

              Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4,
              ICMPv6, UDP and TCP Headers",
              draft-fenner-iana-exp-2780-05 (work in progress),
              June 2006.

   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
              3", BCP 9, RFC 2026, October 1996.

   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
              October 1998.

   [RFC3427]  Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J.,
              and B. Rosen, "Change Process for the Session Initiation
              Protocol (SIP)", BCP 67, RFC 3427, December 2002.

   [RFC3692]  Narten, T., "Assigning Experimental and Testing Numbers
              Considered Useful", BCP 82, RFC 3692, January 2004.

   [RFC3932]  Alvestrand, H., "The IESG and RFC Editor Documents:

Bradner, et al.          Expires March 12, 2007                [Page 10]

Internet-Draft     Procedures for protocol extensions     September 2006

              Procedures", BCP 92, RFC 3932, October 2004.

   [RFC3978]  Bradner, S., "IETF Rights in Contributions", BCP 78,
              RFC 3978, March 2005.

   [RFC3979]  Bradner, S., "Intellectual Property Rights in IETF
              Technology", BCP 79, RFC 3979, March 2005.

   [RFC4181]  Heard, C., "Guidelines for Authors and Reviewers of MIB
              Documents", BCP 111, RFC 4181, September 2005.

10.2.  Informative References

              Andersson, L. and A. Farrel, "Change Process for
              Multiprotocol Label Switching (MPLS) and Generalized MPLS
              (GMPLS) Protocols and Procedures",
              draft-andersson-rtg-gmpls-change-03 (work in progress),
              August 2006.

   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
              June 1999.

   [RFC2865]  Rigney, C., Willens, S., Rubens, A., and W. Simpson,
              "Remote Authentication Dial In User Service (RADIUS)",
              RFC 2865, June 2000.

Authors' Addresses

   Scott Bradner
   Harvard University
   29 Oxford St.
   Cambridge, MA  02138

   Email: sob@harvard.edu

   Brian Carpenter (ed)
   8 Chemin de Blandonnet
   1214 Vernier,

   Email: brc@zurich.ibm.com

Bradner, et al.          Expires March 12, 2007                [Page 11]

Internet-Draft     Procedures for protocol extensions     September 2006

   Thomas Narten
   3039 Cornwallis Ave.
   PO Box 12195 - BRQA/502
   Research Triangle Park, NC  27709-2195

   Email: narten@us.ibm.com

Bradner, et al.          Expires March 12, 2007                [Page 12]

Internet-Draft     Procedures for protocol extensions     September 2006

Full Copyright Statement

   Copyright (C) The Internet Society (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

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

   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


   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Bradner, et al.          Expires March 12, 2007                [Page 13]