[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04 RFC 4775

Network Working Group                                  B. Carpenter (ed)
Internet-Draft                                                       IBM
Expires: December 18, 2006                                 June 16, 2006


                   Procedures for protocol extensions
                 draft-carpenter-protocol-extensions-00

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-
   Drafts.

   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
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on December 18, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document discusses 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 need to be reviewed by
   the larger IETF community.  Experience with IETF protocols has shown
   that extensibility of protocols without IETF review can cause
   problems.  The document also recommends that major extensions to IETF
   protocols only take place through normal IETF processes or in
   coordination with the IETF.




Carpenter (ed)          Expires December 18, 2006               [Page 1]

Internet-Draft     Procedures for protocol extensions          June 2006


   This draft replaces draft-iesg-vendor-extensions.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  General Considerations . . . . . . . . . . . . . . . . . . . .  4
     2.1.  Interoperability as a Goal . . . . . . . . . . . . . . . .  4
     2.2.  Quality and Consistency  . . . . . . . . . . . . . . . . .  4
     2.3.  Registered Values and the Importance of IANA
           Assignments  . . . . . . . . . . . . . . . . . . . . . . .  4
     2.4.  Major versus Minor Extensions  . . . . . . . . . . . . . .  5
   3.  Procedure for Review of Extensions . . . . . . . . . . . . . .  5
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  7
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  7
   7.  Change log [RFC Editor: please remove this section]  . . . . .  7
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     8.1.  Normative References . . . . . . . . . . . . . . . . . . .  8
     8.2.  Informative References . . . . . . . . . . . . . . . . . .  8
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . .  9
   Intellectual Property and Copyright Statements . . . . . . . . . . 10





























Carpenter (ed)          Expires December 18, 2006               [Page 2]

Internet-Draft     Procedures for protocol extensions          June 2006


1.  Introduction

   For the origins of this draft, please see the Acknowledgements
   section.  It is posted as a personal draft although the material was
   historically developed in the IESG.

   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.
   Vendors, standards development organizations and technology fora have
   used those facilities.  Sometimes the result is a poorly designed
   mechanism and non-interoperability.

   It is of course a good principle to design extensiblity 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
   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,
   experience has shown that documentation of these extensions can be
   hard to obtain, short-sighted design choices are sometimes made,
   basic underlying architectural principals of the protocol are
   sometimes violated, 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 peer review that occurs within the



Carpenter (ed)          Expires December 18, 2006               [Page 3]

Internet-Draft     Procedures for protocol extensions          June 2006


   IETF process is lacking.

   This document is focussed on appropriate process and practices to
   ensure that extensions developed outside the IETF will not fall into
   this trap and therefore become useless or, worse, damaging to the
   Internet.  However, some general considerations are listed first.


2.  General Considerations

2.1.  Interoperability as a Goal

   An extension is of little value if it is not interoperable with the
   unextended protocol, i.e. the extended protocol correctly supports
   all mandatory and optional features of the unextended protocol, and
   implementations of the base protocol operate correctly in the
   presence of the extensions.  This places requirements on both the
   base protocol (design for extensibility) and on the extension.  These
   architectural considerations are outside the scope of the present
   draft.

2.2.  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, which must be sufficiently consistent in terminology
   and content with the unextended specification that these experts can
   readily identify the technical changes proposed.

2.3.  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
   "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.
   However, 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.





Carpenter (ed)          Expires December 18, 2006               [Page 4]

Internet-Draft     Procedures for protocol extensions          June 2006


2.4.  Major versus Minor Extensions

   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.

   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 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, 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
   if no such WG exists.


3.  Procedure for Review of Extensions

   Extensions to IETF protocols developed within the IETF will be
   subject to the normal IETF process, exactly like new designs.

   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.

   Extensions to IETF protocols described in Independent Submissions to
   the RFC Editor are subject to IESG review as described in BCP 92
   [RFC3932].  A possible outcome is that the IESG advises the RFC
   Editor that full IETF processing is needed, or that relevant IANA
   procedures have not been followed.




Carpenter (ed)          Expires December 18, 2006               [Page 5]

Internet-Draft     Procedures for protocol extensions          June 2006


   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
   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
   particpants in other SDOs choosing to work in the IETF as well.

   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.  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.  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:
   o  Extensions to IETF protocols should be well, and publicly,
      documented, and reviewed 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  Therefore, 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 the
      IESG.
   o  In the case of simple, minor extensions involving routine IANA
      parameter assignments, this request is satsified as long as the
      IANA Considerations of the underlying IETF specification are



Carpenter (ed)          Expires December 18, 2006               [Page 6]

Internet-Draft     Procedures for protocol extensions          June 2006


      satisfied (see [RFC2434]).  Anything beyond this requires an
      explicit protocol review process.
   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.  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.


5.  IANA Considerations

   The IESG 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
   [RFC2434].


6.  Acknowledgements

   This document is heavily based on an earlier draft under a different
   title by Scott Bradner and Thomas Narten.  Final authorship
   attributions remain to be determined.

   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 and Thomas Narten made valuable comments on this version.

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


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

   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



Carpenter (ed)          Expires December 18, 2006               [Page 7]

Internet-Draft     Procedures for protocol extensions          June 2006


   draft are left to the IAB.


8.  References

8.1.  Normative References

   [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.

   [RFC3932]  Alvestrand, H., "The IESG and RFC Editor Documents:
              Procedures", BCP 92, RFC 3932, October 2004.

8.2.  Informative References

   [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.


























Carpenter (ed)          Expires December 18, 2006               [Page 8]

Internet-Draft     Procedures for protocol extensions          June 2006


Author's Address

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

   Email: brc@zurich.ibm.com










































Carpenter (ed)          Expires December 18, 2006               [Page 9]

Internet-Draft     Procedures for protocol extensions          June 2006


Intellectual Property Statement

   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.


Disclaimer of Validity

   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 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.


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.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Carpenter (ed)          Expires December 18, 2006              [Page 10]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/