Network Working Group S. Bradner Internet-Draft Harvard Intended status: Best Current B. Carpenter (ed) Practice IBM Expires: February 5, 2007 August 4, 2006 Procedures for protocol extensions and variations draft-carpenter-protocol-extensions-01 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 February 5, 2007. Copyright Notice Copyright (C) The Internet Society (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 larger IETF community. Experience with IETF protocols has shown that extensibility of protocols without early IETF review can cause problems. The document also recommends that major extensions to or variations of IETF Bradner & Carpenter (ed) Expires February 5, 2007 [Page 1] Internet-Draft Procedures for protocol extensions August 2006 protocols only take place through normal IETF processes or in coordination with the IETF. This draft replaces draft-iesg-vendor-extensions. 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 . . . . . . . . . . . . . . 5 4. Some Specific Issues . . . . . . . . . . . . . . . . . . . . . 7 5. Intellectual Property . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 9. Change log [RFC Editor: please remove this section] . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 10.2. Informative References . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 11 Bradner & Carpenter (ed) Expires February 5, 2007 [Page 2] Internet-Draft Procedures for protocol extensions August 2006 1. Introduction For the origins of this draft, please see the Acknowledgements section. 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, there is a real risk of poorly designed mechanisms and of 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 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, 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). Generally, short-sighted design choices are Bradner & Carpenter (ed) Expires February 5, 2007 [Page 3] Internet-Draft Procedures for protocol extensions August 2006 sometimes made, and basic underlying architectural principles of the protocol are sometimes violated. 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 that occurs within the IETF process may be lacking. 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. 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 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 "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 Bradner & Carpenter (ed) Expires February 5, 2007 [Page 4] Internet-Draft Procedures for protocol extensions August 2006 protocol value will find that the same value will later be formally assigned to another function, thus guaranteeing an interoperability problem. 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. 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 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 Bradner & Carpenter (ed) Expires February 5, 2007 [Page 5] Internet-Draft Procedures for protocol extensions August 2006 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, currently 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. 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. In some cases (e.g., [RFC3427], [I-D.andersson-rtg-gmpls-change]) 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 changes that need to go through the IETF process. 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 spark hits. 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 Bradner & Carpenter (ed) Expires February 5, 2007 [Page 6] Internet-Draft Procedures for protocol extensions August 2006 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: 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 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. This should be done at an early stage, before a large investment of effort has taken place, in case basic prroblems are revealed. o In the case of simple, minor extensions involving routine IANA parameter assignments, this request is satisfied as long as the IANA Considerations of the underlying IETF specification 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 MIBs, 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 reviewers. 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 [I-D.fenner-iana-exp-2780]. Bradner & Carpenter (ed) Expires February 5, 2007 [Page 7] Internet-Draft Procedures for protocol extensions August 2006 There are certain documents that specify a change process for specific IETF protocols: The SIP change process [RFC3427] The (G)MPLS change process [I-D.andersson-rtg-gmpls-change] 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 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 [RFC2434]. 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,... also made valuable comments on this document. This document was produced using the xml2rfc tool [RFC2629]. Bradner & Carpenter (ed) Expires February 5, 2007 [Page 8] Internet-Draft Procedures for protocol extensions August 2006 9. Change log [RFC Editor: please remove this section] 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 [I-D.fenner-iana-exp-2780] 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. [RFC3932] Alvestrand, H., "The IESG and RFC Editor Documents: 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. Bradner & Carpenter (ed) Expires February 5, 2007 [Page 9] Internet-Draft Procedures for protocol extensions August 2006 10.2. Informative References [I-D.andersson-rtg-gmpls-change] Andersson, L., "MPLS and GMPLS Change Process", draft-andersson-rtg-gmpls-change-02 (work in progress), December 2005. [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 US Email: sob@harvard.edu Brian Carpenter (ed) IBM 8 Chemin de Blandonnet 1214 Vernier, CH Email: brc@zurich.ibm.com Bradner & Carpenter (ed) Expires February 5, 2007 [Page 10] Internet-Draft Procedures for protocol extensions August 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 "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. 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Bradner & Carpenter (ed) Expires February 5, 2007 [Page 11]