idnits 2.17.1 draft-carpenter-protocol-extensions-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 371. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 348. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 355. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 361. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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 copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (June 16, 2006) is 6522 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 normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3932 (Obsoleted by RFC 5742) -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Carpenter (ed) 3 Internet-Draft IBM 4 Expires: December 18, 2006 June 16, 2006 6 Procedures for protocol extensions 7 draft-carpenter-protocol-extensions-00 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 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/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on December 18, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 This document discusses issues related to the extensibility of IETF 41 protocols, including when it is reasonable to extend IETF protocols 42 with little or no review, and when extensions need to be reviewed by 43 the larger IETF community. Experience with IETF protocols has shown 44 that extensibility of protocols without IETF review can cause 45 problems. The document also recommends that major extensions to IETF 46 protocols only take place through normal IETF processes or in 47 coordination with the IETF. 49 This draft replaces draft-iesg-vendor-extensions. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. General Considerations . . . . . . . . . . . . . . . . . . . . 4 55 2.1. Interoperability as a Goal . . . . . . . . . . . . . . . . 4 56 2.2. Quality and Consistency . . . . . . . . . . . . . . . . . 4 57 2.3. Registered Values and the Importance of IANA 58 Assignments . . . . . . . . . . . . . . . . . . . . . . . 4 59 2.4. Major versus Minor Extensions . . . . . . . . . . . . . . 5 60 3. Procedure for Review of Extensions . . . . . . . . . . . . . . 5 61 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 63 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 64 7. Change log [RFC Editor: please remove this section] . . . . . 7 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 67 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 Intellectual Property and Copyright Statements . . . . . . . . . . 10 71 1. Introduction 73 For the origins of this draft, please see the Acknowledgements 74 section. It is posted as a personal draft although the material was 75 historically developed in the IESG. 77 BCP 9 [RFC2026] is the current definition of the IETF standards 78 track. It is implicitly presumed that this process will apply not 79 only to the initial definition of a protocol, but also to any 80 subsequent updates, such that continued interoperability can be 81 guaranteed. However, it is not always clear whether extensions to a 82 protocol fall within this presumption, especially when they originate 83 outside the IETF community. This document lays down procedures for 84 such extensions. 86 When developing protocols, IETF working groups typically include 87 mechanisms whereby these protocols can be extended in the future. 88 Vendors, standards development organizations and technology fora have 89 used those facilities. Sometimes the result is a poorly designed 90 mechanism and non-interoperability. 92 It is of course a good principle to design extensiblity into 93 protocols; one common definition of a successful protocol is one that 94 becomes widely used in ways not originally anticipated. Well- 95 designed extensibility mechanisms facilitate the evolution of 96 protocols and help make it easier to roll-out incremental changes in 97 an interoperable fashion. At the same time, experience has shown 98 that extensibility features should be limited to what is clearly 99 necessary when the protocol is developed and any later extensions 100 should be done carefully and with a full understanding of the base 101 protocol, existing implementations, and current operational practice. 102 However, it is not the purpose of this document to describe the 103 architectural principles of sound extensibility design. 105 When extensions to IETF protocols are made within the IETF, the 106 normal IETF process is followed, including the normal process for 107 review and approval by the IESG. It is presumed that this will 108 ensure that extensions developed in this way will respect all 109 applicable architectural principles and technical criteria. 111 When extensions to IETF protocols are made outside the IETF, 112 experience has shown that documentation of these extensions can be 113 hard to obtain, short-sighted design choices are sometimes made, 114 basic underlying architectural principals of the protocol are 115 sometimes violated, assessing the quality of the specification is 116 hard and achieving interoperability can be hard. Also, there is a 117 risk that mutually incompatible extensions may be developed 118 independently. Simply put, the peer review that occurs within the 119 IETF process is lacking. 121 This document is focussed on appropriate process and practices to 122 ensure that extensions developed outside the IETF will not fall into 123 this trap and therefore become useless or, worse, damaging to the 124 Internet. However, some general considerations are listed first. 126 2. General Considerations 128 2.1. Interoperability as a Goal 130 An extension is of little value if it is not interoperable with the 131 unextended protocol, i.e. the extended protocol correctly supports 132 all mandatory and optional features of the unextended protocol, and 133 implementations of the base protocol operate correctly in the 134 presence of the extensions. This places requirements on both the 135 base protocol (design for extensibility) and on the extension. These 136 architectural considerations are outside the scope of the present 137 draft. 139 2.2. Quality and Consistency 141 In order to be adequately reviewed by relevant experts, a proposed 142 extension must be documented in a clear and well-written 143 specification, which must be sufficiently consistent in terminology 144 and content with the unextended specification that these experts can 145 readily identify the technical changes proposed. 147 2.3. Registered Values and the Importance of IANA Assignments 149 An extension is often likely to make use of additional values added 150 to an existing IANA registry (in many cases, simply by adding a new 151 "TLV" (type-length-value) field). It is essential that such new 152 values are properly registered by the applicable procedures, 153 including expert review where applicable (see BCP 26, [RFC2434]). 154 Extensions may even need to create new IANA registries in some cases. 156 Experience shows that the importance of this is often underestimated 157 during extension design; designers sometimes assume that a new 158 codepoint is theirs for the asking, or even simply for the taking. 159 However, in many cases IANA assignment requests trigger a thorough 160 technical review of the proposal by a designated IETF expert 161 reviewer. Requests are sometimes refused after such a review. Thus, 162 extension designers must pay particular attention to any needed IANA 163 assignments and to the applicable criteria. 165 2.4. Major versus Minor Extensions 167 Some extensions may be considered minor (e.g. adding a 168 straightforward new TLV to an application protocol, which will only 169 impact a subset of hosts) and some may be considered major (e.g. 170 adding a new IP option type, which will potentially impact every node 171 on the Internet). This is essentially a matter of judgement. It 172 could be argued that anything requiring at most Expert Review in 173 [RFC2434] is probably minor, and anything beyond that is major. 174 However, even an apparently minor extension may have unforeseen 175 consequences on interoperability. Thus, the distinction between 176 major and minor is less important than ensuring that the right amount 177 of technical review takes place in either case. 179 For example, RADIUS [RFC2865] is designed to carry attributes and 180 allow definition of new attributes. But it is important that 181 discussion of new attributes involve the IETF community of experts 182 knowledgeable about the protocol's architecture and existing usage in 183 order to fully understand the implications of a proposed extension. 184 Adding new attributes without such discussion creates a high risk of 185 interoperability failure. For this reason among others, the IETF has 186 an active RADIUS Extensions working group at the time of writing. 188 Thus the only safe rule is that, even if an extension appears minor 189 to the person proposing it, review by subject matter experts is 190 always advisable. The proper forum for such review is the IETF, 191 either in the relevant Working Group, or by individual IETF experts 192 if no such WG exists. 194 3. Procedure for Review of Extensions 196 Extensions to IETF protocols developed within the IETF will be 197 subject to the normal IETF process, exactly like new designs. 199 Extensions to IETF protocols discussed in an IRTF Research Group may 200 well be the prelude to regular IETF discussion. However, a Research 201 Group may desire to specify an experimental extension before the work 202 is mature enough for IETF processing. In this case, the Research 203 Group is required to involve appropriate IETF or IANA experts in 204 their process to avoid oversights. 206 Extensions to IETF protocols described in Independent Submissions to 207 the RFC Editor are subject to IESG review as described in BCP 92 208 [RFC3932]. A possible outcome is that the IESG advises the RFC 209 Editor that full IETF processing is needed, or that relevant IANA 210 procedures have not been followed. 212 Where vendors or other Standards Development Organisations (SDOs) see 213 a requirement for extending an IETF protocol, their first step should 214 be to select the most appropriate of the above three routes. Regular 215 IETF process is most likely to be suitable, assuming sufficient 216 interest can be found in the IETF community. IRTF process is 217 unlikely to be suitable unless there is a genuine research context 218 for the proposed extension. 220 In the case of an SDO that identifies a requirement for a 221 standardised extension, a standards development process within the 222 IETF (while maintaining appropriate liaison) is strongly recommended 223 in preference to publishing a non-IETF standard. Otherwise, the 224 implementor community will be faced with a standard split into two or 225 more parts in different styles, obtained from different sources, with 226 no unitary control over quality, compatibility, interoperability, and 227 intellectual property conditions. Note that, since participation in 228 the IETF is open, there is no formality or restriction for 229 particpants in other SDOs choosing to work in the IETF as well. 231 Vendors that identify a requirement for an extension are strongly 232 recommended to start informal discussion in the IETF and to publish a 233 preliminary Internet Draft. This will allow the vendor, and the 234 community, to evaluate whether there is community interest and 235 whether there are any major or fundamental issues. However, in the 236 case of a vendor that identifies a requirement for a proprietary 237 extension that does not generate interest in the IETF (or IRTF) 238 communities, an Independent Submission to the RFC Editor is strongly 239 recommended in preference to publishing a proprietary document. Not 240 only does this bring the draft to the attention of the community; it 241 also ensures a minimum of community review [RFC3932], and (if 242 published) makes the proprietary extension available to the whole 243 community. 245 If, despite these strong recommendations, a vendor or SDO does choose 246 to publish its own specification for an extension to an IETF 247 protocol, the following guidance applies: 248 o Extensions to IETF protocols should be well, and publicly, 249 documented, and reviewed by the IETF community to be sure that the 250 extension does not undermine basic assumptions and safeguards 251 designed into the protocol, such as security functions, or 252 undermine its architectural integrity. 253 o Therefore, vendors and other SDOs are formally requested to submit 254 any such proposed publications for IETF review, by an established 255 liaison channel if it exists, or by direct communication with the 256 IESG. 257 o In the case of simple, minor extensions involving routine IANA 258 parameter assignments, this request is satsified as long as the 259 IANA Considerations of the underlying IETF specification are 260 satisfied (see [RFC2434]). Anything beyond this requires an 261 explicit protocol review process. 262 o Note that, like IETF specifications, such proposed publications 263 must include an IANA considerations section to ensure that 264 protocol parameter assignments that are needed to deploy 265 extensions are not made until after a proposed extension has 266 received adequate review, and then to ensure that IANA has precise 267 guidance on how to make those assignments. 269 4. Security Considerations 271 An extension must not introduce new security risks without also 272 providing an adequate counter-measure, and in particular it must not 273 inadvertently defeat security measures in the unextended protocol. 274 This aspect must always be considered during IETF review. 276 5. IANA Considerations 278 The IESG requests IANA to pay attention to the requirements of this 279 document when requested to make protocol parameter assignments for 280 vendors or other SDOs, i.e. to respect the IANA Considerations of all 281 RFCs that contain them, and the general considerations of BCP 26 282 [RFC2434]. 284 6. Acknowledgements 286 This document is heavily based on an earlier draft under a different 287 title by Scott Bradner and Thomas Narten. Final authorship 288 attributions remain to be determined. 290 That earlier draft stated: The initial version of this document was 291 put together by the IESG in 2002. Since then, it has been reworked 292 in response to feedback from John Loughney, Henrik Levkowetz, Mark 293 Townsley, Randy Bush, Bernard Aboba and others. 295 Ted Hardie and Thomas Narten made valuable comments on this version. 297 This document was produced using the xml2rfc tool[RFC2629]. 299 7. Change log [RFC Editor: please remove this section] 301 draft-carpenter-protocol-extensions-00: original version, 2006-06-16. 302 Derived from draft-iesg-vendor-extensions-02.txt dated 2004-06-04 by 303 focussing on procedural issues; the more architectural issues in that 304 draft are left to the IAB. 306 8. References 308 8.1. Normative References 310 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 311 3", BCP 9, RFC 2026, October 1996. 313 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 314 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 315 October 1998. 317 [RFC3932] Alvestrand, H., "The IESG and RFC Editor Documents: 318 Procedures", BCP 92, RFC 3932, October 2004. 320 8.2. Informative References 322 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 323 June 1999. 325 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 326 "Remote Authentication Dial In User Service (RADIUS)", 327 RFC 2865, June 2000. 329 Author's Address 331 Brian Carpenter (ed) 332 IBM 333 8 Chemin de Blandonnet 334 1214 Vernier, 335 Switzerland 337 Email: brc@zurich.ibm.com 339 Intellectual Property Statement 341 The IETF takes no position regarding the validity or scope of any 342 Intellectual Property Rights or other rights that might be claimed to 343 pertain to the implementation or use of the technology described in 344 this document or the extent to which any license under such rights 345 might or might not be available; nor does it represent that it has 346 made any independent effort to identify any such rights. Information 347 on the procedures with respect to rights in RFC documents can be 348 found in BCP 78 and BCP 79. 350 Copies of IPR disclosures made to the IETF Secretariat and any 351 assurances of licenses to be made available, or the result of an 352 attempt made to obtain a general license or permission for the use of 353 such proprietary rights by implementers or users of this 354 specification can be obtained from the IETF on-line IPR repository at 355 http://www.ietf.org/ipr. 357 The IETF invites any interested party to bring to its attention any 358 copyrights, patents or patent applications, or other proprietary 359 rights that may cover technology that may be required to implement 360 this standard. Please address the information to the IETF at 361 ietf-ipr@ietf.org. 363 Disclaimer of Validity 365 This document and the information contained herein are provided on an 366 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 367 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 368 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 369 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 370 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 371 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 373 Copyright Statement 375 Copyright (C) The Internet Society (2006). This document is subject 376 to the rights, licenses and restrictions contained in BCP 78, and 377 except as set forth therein, the authors retain all their rights. 379 Acknowledgment 381 Funding for the RFC Editor function is currently provided by the 382 Internet Society.