INTERNET-DRAFT Scott O. Bradner <draft-iesg-vendor-extensions-00.txt> Harvard University Thomas Narten IBM December 20, 2002 Considerations on the Extensibility of IETF protocols <draft-iesg-vendor-extensions-00.txt> Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html 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. The document also recommends that major extensions to IETF protocols only take place through normal IETF processes or if adequate controls are in place to ensure sufficient IETF review. Contents Status of this Memo.......................................... 1 1. Introduction............................................. 2 draft-iesg-vendor-extensions-00.txt [Page 1]
INTERNET-DRAFT December 20, 2002 2. Principles............................................... 2 3. Recommendation........................................... 4 4. IANA Considerations...................................... 5 5. Security Considerations.................................. 5 6. Acknowledgments.......................................... 5 7. Informative References................................... 5 8. Editor's Addresses....................................... 5 1. Introduction When developing protocols, quite a few IETF working groups have made facilities whereby these protocols can be extended in the future. Vendors, other standards development organizations and technology fora have used those facilities. Sometimes the result is non- interoperability or poorly designed mechanisms. The purpose of this memo is to make explicit some guiding princples based on the community's experience with these mechanisms. The IESG is presently applying some version of these principles when evaluating proposals for new standards. 2. Principles The most important principle driving this memo, and in fact the IETF as a whole is the principle of: o IETF Standards are intended to permit multiple implementers to build implementations of protocols that will interoperate. It is a good principle to design extensible protocols but extensions should be done carefully and with a full understanding of the base protocol. If extensions to IETF protocols are done 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. draft-iesg-vendor-extensions-00.txt [Page 2]
INTERNET-DRAFT December 20, 2002 It can be particularly difficult for a user to figure out who is at fault and what to do about it if two pieces of software that both claim to be implementations of an IETF standard do not work together. Yet there are situations where extensions to IETF protocols can make sense. There are two general classes of extensions. The first class, called minor extensions, refers to extensions of limited scope. In such cases: - the extension is proprietary in nature, in that it is used to carry out vendor-specific tasks and does not have general applicability, or - the problem being solved is so narrowly scoped that a standardized approach is not justified (however, few problems can be scoped very narrowly, and often there is a need for more global context, cf. P-headers in RFC 3427/draft-tsvarea-sipchange-03.txt). - only one (or a very small number of) vendors will ever implement the extension - the extension doesn't modify the underlying protocol itself. Instead, the underlying protocol carries the extension as opaque data. Examples of minor extensions include the DHC vendor-specific option, the enterprise OID tree for MIB modules, vnd. MIME types, and some classses of (non-critical) certification extensions. Such extensions can safely be made without IETF coordination and are indicated by having an IANA Considerations that allows assignments of code points with minimal overhead (e.g., first come first served) [IANA-CONSID]. The more interesting class of extensions, called major extensions, involves those in which multiple vendors are expected to implement the extension and the extension is viewed as solving an important problem. Such extensions should only be done when: - there is a clear need for the function and there is no other mechanism within the protocol that already accomplishes the goal of the extension, even if it would do so with less efficiency. - it is expected that multiple vendors will need to implement the extension - use of the extension will be required in environments where if the extensions doesn't work properly, the underlying protocol will be draft-iesg-vendor-extensions-00.txt [Page 3]
INTERNET-DRAFT December 20, 2002 viewed as having failed. Major extensions should be well, and publicly, documented and checked by the IETF community to be sure that the extension does not defeat safeguards designed into the protocol, such as security functions, or undermine its architectural integrity. 3. Recommendation The following principles are the main guiding principles concerning extensions to IETF protocol: o All major extensions to IETF protocols should be done with direct involvement of the IETF. o The decision on whether an extension is major or minor should be done with the direct involvement of the IETF. Extensions should be done by IETF working groups using normal IETF processes or, if a working group does not consider a proposed extension to be general enough, documented in an IETF informational RFC that is reviewed by the working group and the IESG. No individual, vendor, SDO or forum should be able create what is viewed to be a major extension to an IETF protocol on its own and legitimately be able to claim that implementations that implement the extension are compliant to the IETF specification. Exactly what is considered to be a major extension and what is considered minor depends on the specific protocol being extended. For example, some protocols are designed to carry opaque data without impacting the underlying protocol. The definition of additional opaque data types would usually not be considered a major extension, whereas a change that modified the underlying protocol mechanisms would be. Thus IETF protocols should not be designed to encourage the definition of major extensions outside the IETF process. IETF protocols should carefully analyze and identify which protocol components can be extended safely with minimal or no community review and which need community review, and then write appropriate IANA considerations sections that ensure the appropriate level of community review. For example, the definition of additional data formats that can be carried may require no review, while the addition of new protocol message types might require a Standards Track action [IANA-CONSID]. draft-iesg-vendor-extensions-00.txt [Page 4]
INTERNET-DRAFT December 20, 2002 4. IANA Considerations None. 5. Security Considerations Insufficiently reviewed extensions can easily lead to protocols with significant security vulnerabilities. 6. Acknowledgments The initial version of this document was put together by the IESG. 7. Informative References [IANA-CONSID] Guidelines for Writing an IANA Considerations Section in RFCs. T. Narten, H. Alvestrand. October 1998. RFC 2434. 8. Editor's Addresses Scott O. Bradner Harvard University Holyoke Center, Room 813 1350 Mass. Ave. Cambridge, MA 02138 USA Phone: +1 617-495-3864 EMail: sob@harvard.edu Thomas Narten IBM Corporation P.O. Box 12195 Research Triangle Park, NC 27709-2195 USA Phone: +1 919 254 7798 EMail: narten@us.ibm.com draft-iesg-vendor-extensions-00.txt [Page 5]
