idnits 2.17.1 draft-iesg-vendor-extensions-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 20, 2002) is 7798 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 2434 (ref. 'IANA-CONSID') (Obsoleted by RFC 5226) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Scott O. Bradner 3 Harvard University 4 Thomas Narten 5 IBM 6 December 20, 2002 8 Considerations on the Extensibility of IETF protocols 10 12 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet- Drafts as reference 24 material or to cite them other than as work in progress. 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/1id-abstracts.html 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 Abstract 34 This document discusses issues related to the extensibility of IETF 35 protocols, including when it is reasonable to extend IETF protocols 36 with little or no review, and when extensions need to be reviewed by 37 the larger IETF community. The document also recommends that major 38 extensions to IETF protocols only take place through normal IETF 39 processes or if adequate controls are in place to ensure sufficient 40 IETF review. 42 Contents 44 Status of this Memo.......................................... 1 46 1. Introduction............................................. 2 47 2. Principles............................................... 2 49 3. Recommendation........................................... 4 51 4. IANA Considerations...................................... 5 53 5. Security Considerations.................................. 5 55 6. Acknowledgments.......................................... 5 57 7. Informative References................................... 5 59 8. Editor's Addresses....................................... 5 61 1. Introduction 63 When developing protocols, quite a few IETF working groups have made 64 facilities whereby these protocols can be extended in the future. 65 Vendors, other standards development organizations and technology 66 fora have used those facilities. Sometimes the result is non- 67 interoperability or poorly designed mechanisms. 69 The purpose of this memo is to make explicit some guiding princples 70 based on the community's experience with these mechanisms. The IESG 71 is presently applying some version of these principles when 72 evaluating proposals for new standards. 74 2. Principles 76 The most important principle driving this memo, and in fact the IETF 77 as a whole is the principle of: 79 o IETF Standards are intended to permit multiple implementers to 80 build implementations of protocols that will interoperate. 82 It is a good principle to design extensible protocols but extensions 83 should be done carefully and with a full understanding of the base 84 protocol. 86 If extensions to IETF protocols are done outside the IETF, experience 87 has shown that documentation of these extensions can be hard to 88 obtain, short-sighted design choices are sometimes made, basic 89 underlying architectural principals of the protocol are sometimes 90 violated, assessing the quality of the specification is hard, and 91 achieving interoperability can be hard. 93 It can be particularly difficult for a user to figure out who is at 94 fault and what to do about it if two pieces of software that both 95 claim to be implementations of an IETF standard do not work together. 97 Yet there are situations where extensions to IETF protocols can make 98 sense. There are two general classes of extensions. The first class, 99 called minor extensions, refers to extensions of limited scope. In 100 such cases: 102 - the extension is proprietary in nature, in that it is used to 103 carry out vendor-specific tasks and does not have general 104 applicability, or 106 - the problem being solved is so narrowly scoped that a standardized 107 approach is not justified (however, few problems can be scoped 108 very narrowly, and often there is a need for more global context, 109 cf. P-headers in RFC 3427/draft-tsvarea-sipchange-03.txt). 111 - only one (or a very small number of) vendors will ever implement 112 the extension 114 - the extension doesn't modify the underlying protocol itself. 115 Instead, the underlying protocol carries the extension as opaque 116 data. 118 Examples of minor extensions include the DHC vendor-specific option, 119 the enterprise OID tree for MIB modules, vnd. MIME types, and some 120 classses of (non-critical) certification extensions. Such extensions 121 can safely be made without IETF coordination and are indicated by 122 having an IANA Considerations that allows assignments of code points 123 with minimal overhead (e.g., first come first served) [IANA-CONSID]. 125 The more interesting class of extensions, called major extensions, 126 involves those in which multiple vendors are expected to implement 127 the extension and the extension is viewed as solving an important 128 problem. Such extensions should only be done when: 130 - there is a clear need for the function and there is no other 131 mechanism within the protocol that already accomplishes the goal 132 of the extension, even if it would do so with less efficiency. 134 - it is expected that multiple vendors will need to implement the 135 extension 137 - use of the extension will be required in environments where if the 138 extensions doesn't work properly, the underlying protocol will be 139 viewed as having failed. 141 Major extensions should be well, and publicly, documented and checked 142 by the IETF community to be sure that the extension does not defeat 143 safeguards designed into the protocol, such as security functions, or 144 undermine its architectural integrity. 146 3. Recommendation 148 The following principles are the main guiding principles concerning 149 extensions to IETF protocol: 151 o All major extensions to IETF protocols should be done with direct 152 involvement of the IETF. 154 o The decision on whether an extension is major or minor should be 155 done with the direct involvement of the IETF. 157 Extensions should be done by IETF working groups using normal IETF 158 processes or, if a working group does not consider a proposed 159 extension to be general enough, documented in an IETF informational 160 RFC that is reviewed by the working group and the IESG. No 161 individual, vendor, SDO or forum should be able create what is viewed 162 to be a major extension to an IETF protocol on its own and 163 legitimately be able to claim that implementations that implement the 164 extension are compliant to the IETF specification. 166 Exactly what is considered to be a major extension and what is 167 considered minor depends on the specific protocol being extended. For 168 example, some protocols are designed to carry opaque data without 169 impacting the underlying protocol. The definition of additional 170 opaque data types would usually not be considered a major extension, 171 whereas a change that modified the underlying protocol mechanisms 172 would be. 174 Thus IETF protocols should not be designed to encourage the 175 definition of major extensions outside the IETF process. IETF 176 protocols should carefully analyze and identify which protocol 177 components can be extended safely with minimal or no community review 178 and which need community review, and then write appropriate IANA 179 considerations sections that ensure the appropriate level of 180 community review. For example, the definition of additional data 181 formats that can be carried may require no review, while the addition 182 of new protocol message types might require a Standards Track action 183 [IANA-CONSID]. 185 4. IANA Considerations 187 None. 189 5. Security Considerations 191 Insufficiently reviewed extensions can easily lead to protocols with 192 significant security vulnerabilities. 194 6. Acknowledgments 196 The initial version of this document was put together by the IESG. 198 7. Informative References 200 [IANA-CONSID] Guidelines for Writing an IANA Considerations Section 201 in RFCs. T. Narten, H. Alvestrand. October 1998. RFC 2434. 203 8. Editor's Addresses 205 Scott O. Bradner 206 Harvard University 207 Holyoke Center, Room 813 208 1350 Mass. Ave. 209 Cambridge, MA 02138 210 USA 212 Phone: +1 617-495-3864 213 EMail: sob@harvard.edu 215 Thomas Narten 216 IBM Corporation 217 P.O. Box 12195 218 Research Triangle Park, NC 27709-2195 219 USA 221 Phone: +1 919 254 7798 222 EMail: narten@us.ibm.com