idnits 2.17.1 draft-carpenter-protocol-extensions-01.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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 448. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 459. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 466. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 472. ** 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 issues found here. 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 (August 4, 2006) is 6476 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (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 3427 (Obsoleted by RFC 5727) ** Obsolete normative reference: RFC 3932 (Obsoleted by RFC 5742) ** Obsolete normative reference: RFC 3978 (Obsoleted by RFC 5378) ** Obsolete normative reference: RFC 3979 (Obsoleted by RFC 8179) == Outdated reference: A later version (-08) exists of draft-andersson-rtg-gmpls-change-02 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 8 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 S. Bradner 3 Internet-Draft Harvard 4 Intended status: Best Current B. Carpenter (ed) 5 Practice IBM 6 Expires: February 5, 2007 August 4, 2006 8 Procedures for protocol extensions and variations 9 draft-carpenter-protocol-extensions-01 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on February 5, 2007. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This document discusses procedural issues related to the 43 extensibility of IETF protocols, including when it is reasonable to 44 extend IETF protocols with little or no review, and when extensions 45 or variations need to be reviewed by the larger IETF community. 46 Experience with IETF protocols has shown that extensibility of 47 protocols without early IETF review can cause problems. The document 48 also recommends that major extensions to or variations of IETF 49 protocols only take place through normal IETF processes or in 50 coordination with the IETF. 52 This draft replaces draft-iesg-vendor-extensions. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. General Considerations . . . . . . . . . . . . . . . . . . . . 4 58 2.1. Quality and Consistency . . . . . . . . . . . . . . . . . 4 59 2.2. Registered Values and the Importance of IANA 60 Assignments . . . . . . . . . . . . . . . . . . . . . . . 4 61 2.3. All extensions require technical review . . . . . . . . . 5 62 3. Procedure for Review of Extensions . . . . . . . . . . . . . . 5 63 4. Some Specific Issues . . . . . . . . . . . . . . . . . . . . . 7 64 5. Intellectual Property . . . . . . . . . . . . . . . . . . . . 8 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 67 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 68 9. Change log [RFC Editor: please remove this section] . . . . . 9 69 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 71 10.2. Informative References . . . . . . . . . . . . . . . . . . 10 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 73 Intellectual Property and Copyright Statements . . . . . . . . . . 11 75 1. Introduction 77 For the origins of this draft, please see the Acknowledgements 78 section. 80 BCP 9 [RFC2026] is the current definition of the IETF standards 81 track. It is implicitly presumed that this process will apply not 82 only to the initial definition of a protocol, but also to any 83 subsequent updates, such that continued interoperability can be 84 guaranteed. However, it is not always clear whether extensions to a 85 protocol fall within this presumption, especially when they originate 86 outside the IETF community. This document lays down procedures for 87 such extensions. 89 When developing protocols, IETF working groups typically include 90 mechanisms whereby these protocols can be extended in the future. In 91 addition to the IETF itself, vendors, standards development 92 organizations and technology fora have used those facilities. 93 Although the results are often good, there is a real risk of poorly 94 designed mechanisms and of non-interoperability. 96 It is of course a good principle to design extensiblity into 97 protocols; one common definition of a successful protocol is one that 98 becomes widely used in ways not originally anticipated. Well- 99 designed extensibility mechanisms facilitate the evolution of 100 protocols and help make it easier to roll-out incremental changes in 101 an interoperable fashion. At the same time, experience has shown 102 that extensibility features should be limited to what is clearly 103 necessary when the protocol is developed and any later extensions 104 should be done carefully and with a full understanding of the base 105 protocol, existing implementations, and current operational practice. 106 However, it is not the purpose of this document to describe the 107 architectural principles of sound extensibility design. 109 When extensions to IETF protocols are made within the IETF, the 110 normal IETF process is followed, including the normal process for 111 IETF-wide review, and approval by the IESG. It is presumed that this 112 will ensure that extensions developed in this way will respect all 113 applicable architectural principles and technical criteria. 115 When extensions to IETF protocols are made outside the IETF, 116 experience has shown that they may not be done with the full 117 understanding of why the existing protocol was designed the way that 118 it is - e.g., what ideas were brought up during the original 119 development and rejected because of some problem with them. Also 120 such extensions could, because of a lack of understanding, negate 121 some key function of the existing protocol (such as security or 122 congestion control). Generally, short-sighted design choices are 123 sometimes made, and basic underlying architectural principles of the 124 protocol are sometimes violated. 126 Additionally, documentation of non-IETF extensions can be hard to 127 obtain, so assessing the quality of the specification is hard and 128 achieving interoperability can be hard. Also, there is a risk that 129 mutually incompatible extensions may be developed independently. 131 Simply put, the early peer review that occurs within the IETF process 132 may be lacking. 134 All that can be said about extensions applies with equal or greater 135 force to variations - in fact, by definition, protocol variations 136 damage interoperability. They must therefore be intensely 137 scrutinized. Throughout this document, what is said about extensions 138 also applies to variations. 140 This document is focussed on appropriate process and practices to 141 ensure that extensions developed outside the IETF will not fall into 142 these traps and therefore become useless or, worse, damaging to 143 interoperability. Architectural considerations are documented 144 elsewhere. 146 2. General Considerations 148 2.1. Quality and Consistency 150 In order to be adequately reviewed by relevant experts, a proposed 151 extension must be documented in a clear and well-written 152 specification published as an Internet Draft, which must be 153 sufficiently consistent in terminology and content with the 154 unextended specification that these experts can readily identify the 155 technical changes proposed at an early stage. 157 2.2. Registered Values and the Importance of IANA Assignments 159 An extension is often likely to make use of additional values added 160 to an existing IANA registry (in many cases, simply by adding a new 161 "TLV" (type-length-value) field). It is essential that such new 162 values are properly registered by the applicable procedures, 163 including expert review where applicable (see BCP 26, [RFC2434]). 164 Extensions may even need to create new IANA registries in some cases. 166 Experience shows that the importance of this is often underestimated 167 during extension design; designers sometimes assume that a new 168 codepoint is theirs for the asking, or even simply for the taking. 169 This is hazardous; it is far too likely that someone just taking a 170 protocol value will find that the same value will later be formally 171 assigned to another function, thus guaranteeing an interoperability 172 problem. 174 In many cases IANA assignment requests trigger a thorough technical 175 review of the proposal by a designated IETF expert reviewer. 176 Requests are sometimes refused after such a review. Thus, extension 177 designers must pay particular attention to any needed IANA 178 assignments and to the applicable criteria. 180 2.3. All extensions require technical review 182 Some extensions may be considered minor (e.g. adding a 183 straightforward new TLV to an application protocol, which will only 184 impact a subset of hosts) and some may be considered major (e.g. 185 adding a new IP option type, which will potentially impact every node 186 on the Internet). This is essentially a matter of judgement. It 187 could be argued that anything requiring at most Expert Review in 188 [RFC2434] is probably minor, and anything beyond that is major. 189 However, even an apparently minor extension may have unforeseen 190 consequences on interoperability. Thus, the distinction between 191 major and minor is less important than ensuring that the right amount 192 of technical review takes place in either case. 194 For example, RADIUS [RFC2865] is designed to carry attributes and 195 allow definition of new attributes. But it is important that 196 discussion of new attributes involve the IETF community of experts 197 knowledgeable about the protocol's architecture and existing usage in 198 order to fully understand the implications of a proposed extension. 199 Adding new attributes without such discussion creates a high risk of 200 interoperability or functionality failure. For this reason among 201 others, the IETF has an active RADIUS Extensions working group at the 202 time of writing. 204 Thus the only safe rule is that, even if an extension appears minor 205 to the person proposing it, early review by subject matter experts is 206 always advisable. The proper forum for such review is the IETF, 207 either in the relevant Working Group, or by individual IETF experts 208 if no such WG exists. 210 3. Procedure for Review of Extensions 212 Extensions to IETF protocols developed within the IETF will be 213 subject to the normal IETF process, exactly like new designs. 215 Extensions to IETF protocols discussed in an IRTF Research Group may 216 well be the prelude to regular IETF discussion. However, a Research 217 Group may desire to specify an experimental extension before the work 218 is mature enough for IETF processing. In this case, the Research 219 Group is required to involve appropriate IETF or IANA experts in 220 their process to avoid oversights. 222 Extensions to IETF protocols described in Independent Submissions to 223 the RFC Editor are subject to IESG review, currently described in BCP 224 92 [RFC3932]. A possible outcome is that the IESG advises the RFC 225 Editor that full IETF processing is needed, or that relevant IANA 226 procedures have not been followed. 228 Where vendors or other Standards Development Organisations (SDOs) see 229 a requirement for extending an IETF protocol, their first step should 230 be to select the most appropriate of the above three routes. Regular 231 IETF process is most likely to be suitable, assuming sufficient 232 interest can be found in the IETF community. IRTF process is 233 unlikely to be suitable unless there is a genuine research context 234 for the proposed extension. 236 In the case of an SDO that identifies a requirement for a 237 standardised extension, a standards development process within the 238 IETF (while maintaining appropriate liaison) is strongly recommended 239 in preference to publishing a non-IETF standard. Otherwise, the 240 implementor community will be faced with a standard split into two or 241 more parts in different styles, obtained from different sources, with 242 no unitary control over quality, compatibility, interoperability, and 243 intellectual property conditions. Note that, since participation in 244 the IETF is open, there is no formality or restriction for 245 particpants in other SDOs choosing to work in the IETF as well. In 246 some cases (e.g., [RFC3427], [I-D.andersson-rtg-gmpls-change]) the 247 IETF has well defined procedures for this in place. 249 Naturally, SDOs can and do develop scenarios, requirements and 250 architectures based on IETF specifications. It is only actual 251 protocol changes that need to go through the IETF process. Other 252 SDOs are encouraged to communicate informally or formally with the 253 IETF as early as possible, to avoid false starts. Early technical 254 review in a collaborative spirit is of great value. Each SDO can 255 "own" its ideas and discuss them in its own fora, but should start 256 talking to the IETF experts about those ideas the moment the spark 257 hits. 259 Vendors that identify a requirement for an extension are strongly 260 recommended to start informal discussion in the IETF and to publish a 261 preliminary Internet Draft describing the requirements. This will 262 allow the vendor, and the community, to evaluate whether there is 263 community interest and whether there are any major or fundamental 264 issues. However, in the case of a vendor that identifies a 265 requirement for a proprietary extension that does not generate 266 interest in the IETF (or IRTF) communities, an Independent Submission 267 to the RFC Editor is strongly recommended in preference to publishing 268 a proprietary document, unless preliminary IETF discussion has 269 already revealed serious flaws in the proposal. Not only does this 270 bring the draft to the attention of the community; it also ensures a 271 minimum of community review [RFC3932], and (if published) makes the 272 proprietary extension available to the whole community. 274 If, despite these strong recommendations, a vendor or SDO does choose 275 to publish its own specification for an extension to an IETF 276 protocol, the following guidance applies: 277 o Extensions to IETF protocols should be well, and publicly, 278 documented, and reviewed at an early stage by the IETF community 279 to be sure that the extension does not undermine basic assumptions 280 and safeguards designed into the protocol, such as security 281 functions, or undermine its architectural integrity. 282 o Therefore, vendors and other SDOs are formally requested to submit 283 any such proposed publications for IETF review, by an established 284 liaison channel if it exists, or by direct communication with the 285 IESG. This should be done at an early stage, before a large 286 investment of effort has taken place, in case basic prroblems are 287 revealed. 288 o In the case of simple, minor extensions involving routine IANA 289 parameter assignments, this request is satisfied as long as the 290 IANA Considerations of the underlying IETF specification are 291 satisfied (see [RFC2434]). Anything beyond this requires an 292 explicit protocol review by experts within the IETF. 293 o Note that, like IETF specifications, such proposed publications 294 must include an IANA considerations section to ensure that 295 protocol parameter assignments that are needed to deploy 296 extensions are not made until after a proposed extension has 297 received adequate review, and then to ensure that IANA has precise 298 guidance on how to make those assignments. 300 4. Some Specific Issues 302 It is relatively common for MIBs, which are all in effect extensions 303 of the SMI data model, to be defined or extended outside the IETF. 304 BCP 111 [RFC4181] offers detailed guidance for authors and reviewers. 306 A number of protocols have foreseen experimental values for certain 307 IANA parameters, so that experimental usages and extensions may be 308 tested without need for a special parameter assignment. It must be 309 stressed that such values are not intended for production use or as a 310 way to evade the type of technical review described in this document. 311 See [I-D.fenner-iana-exp-2780]. 313 There are certain documents that specify a change process for 314 specific IETF protocols: 315 The SIP change process [RFC3427] 316 The (G)MPLS change process [I-D.andersson-rtg-gmpls-change] 318 5. Intellectual Property 320 All IETF documents fall under the IETF's intellectual property rules, 321 BCP 78 [RFC3978] and BCP 79 [RFC3979], as amended. In particular, 322 there are restrictions on the production of derivative works, and 323 there are rights that remain with the original authors. Anybody 324 outside the IETF considering an extension based on an IETF document 325 must bear these restrictions and rights in mind. 327 6. Security Considerations 329 An extension must not introduce new security risks without also 330 providing an adequate counter-measure, and in particular it must not 331 inadvertently defeat security measures in the unextended protocol. 332 This aspect must always be considered during IETF review. 334 7. IANA Considerations 336 The IETF requests IANA to pay attention to the requirements of this 337 document when requested to make protocol parameter assignments for 338 vendors or other SDOs, i.e. to respect the IANA Considerations of all 339 RFCs that contain them, and the general considerations of BCP 26 340 [RFC2434]. 342 8. Acknowledgements 344 This document is heavily based on an earlier draft under a different 345 title by Scott Bradner and Thomas Narten. 347 That earlier draft stated: The initial version of this document was 348 put together by the IESG in 2002. Since then, it has been reworked 349 in response to feedback from John Loughney, Henrik Levkowetz, Mark 350 Townsley, Randy Bush, Bernard Aboba and others. 352 Ted Hardie, Scott Brim, Dan Romascanu, Jari Arkko, Loa Andersson,... 353 also made valuable comments on this document. 355 This document was produced using the xml2rfc tool [RFC2629]. 357 9. Change log [RFC Editor: please remove this section] 359 draft-carpenter-protocol-extensions-01: 2006-08-04. Removed 360 additional architectural material, added material on MIBs, 361 experimental values and IPR, reflected other comments. Extended 362 scope to cover variations as well as extensions. Updated authorship. 364 draft-carpenter-protocol-extensions-00: original version, 2006-06-16. 365 Derived from draft-iesg-vendor-extensions-02.txt dated 2004-06-04 by 366 focussing on procedural issues; the more architectural issues in that 367 draft are left to a separate document. 369 10. References 371 10.1. Normative References 373 [I-D.fenner-iana-exp-2780] 374 Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, 375 ICMPv6, UDP and TCP Headers", 376 draft-fenner-iana-exp-2780-05 (work in progress), 377 June 2006. 379 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 380 3", BCP 9, RFC 2026, October 1996. 382 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 383 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 384 October 1998. 386 [RFC3427] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., 387 and B. Rosen, "Change Process for the Session Initiation 388 Protocol (SIP)", BCP 67, RFC 3427, December 2002. 390 [RFC3932] Alvestrand, H., "The IESG and RFC Editor Documents: 391 Procedures", BCP 92, RFC 3932, October 2004. 393 [RFC3978] Bradner, S., "IETF Rights in Contributions", BCP 78, 394 RFC 3978, March 2005. 396 [RFC3979] Bradner, S., "Intellectual Property Rights in IETF 397 Technology", BCP 79, RFC 3979, March 2005. 399 [RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB 400 Documents", BCP 111, RFC 4181, September 2005. 402 10.2. Informative References 404 [I-D.andersson-rtg-gmpls-change] 405 Andersson, L., "MPLS and GMPLS Change Process", 406 draft-andersson-rtg-gmpls-change-02 (work in progress), 407 December 2005. 409 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 410 June 1999. 412 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 413 "Remote Authentication Dial In User Service (RADIUS)", 414 RFC 2865, June 2000. 416 Authors' Addresses 418 Scott Bradner 419 Harvard University 420 29 Oxford St. 421 Cambridge, MA 02138 422 US 424 Email: sob@harvard.edu 426 Brian Carpenter (ed) 427 IBM 428 8 Chemin de Blandonnet 429 1214 Vernier, 430 CH 432 Email: brc@zurich.ibm.com 434 Full Copyright Statement 436 Copyright (C) The Internet Society (2006). 438 This document is subject to the rights, licenses and restrictions 439 contained in BCP 78, and except as set forth therein, the authors 440 retain all their rights. 442 This document and the information contained herein are provided on an 443 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 444 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 445 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 446 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 447 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 448 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 450 Intellectual Property 452 The IETF takes no position regarding the validity or scope of any 453 Intellectual Property Rights or other rights that might be claimed to 454 pertain to the implementation or use of the technology described in 455 this document or the extent to which any license under such rights 456 might or might not be available; nor does it represent that it has 457 made any independent effort to identify any such rights. Information 458 on the procedures with respect to rights in RFC documents can be 459 found in BCP 78 and BCP 79. 461 Copies of IPR disclosures made to the IETF Secretariat and any 462 assurances of licenses to be made available, or the result of an 463 attempt made to obtain a general license or permission for the use of 464 such proprietary rights by implementers or users of this 465 specification can be obtained from the IETF on-line IPR repository at 466 http://www.ietf.org/ipr. 468 The IETF invites any interested party to bring to its attention any 469 copyrights, patents or patent applications, or other proprietary 470 rights that may cover technology that may be required to implement 471 this standard. Please address the information to the IETF at 472 ietf-ipr@ietf.org. 474 Acknowledgment 476 Funding for the RFC Editor function is provided by the IETF 477 Administrative Support Activity (IASA).