idnits 2.17.1 draft-carpenter-protocol-extensions-03.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 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 622. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 633. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 640. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 646. ** 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 (September 19, 2006) is 6426 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-03 -- 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 T. Narten 6 Expires: March 23, 2007 IBM 7 September 19, 2006 9 Procedures for protocol extensions and variations 10 draft-carpenter-protocol-extensions-03 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on March 23, 2007. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 Abstract 43 This document discusses procedural issues related to the 44 extensibility of IETF protocols, including when it is reasonable to 45 extend IETF protocols with little or no review, and when extensions 46 or variations need to be reviewed by the IETF community. Experience 47 has shown that extension of protocols without early IETF review can 48 carry risk. The document also recommends that major extensions to or 49 variations of IETF protocols only take place through normal IETF 50 processes or in coordination with the IETF. 52 This document is directed principally at other Standards Development 53 Organizations (SDOs) and vendors considering requirements for 54 extensions to IETF protocols. It does not modify formal IETF 55 processes. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Technical Risks in Extensions . . . . . . . . . . . . . . . . 4 61 3. General Considerations . . . . . . . . . . . . . . . . . . . . 5 62 3.1. The Importance of Interoperability . . . . . . . . . . . . 5 63 3.2. Registered Values and the Importance of IANA 64 Assignments . . . . . . . . . . . . . . . . . . . . . . . 5 65 3.3. Significant extensions require technical review . . . . . 6 66 3.4. Quality and Consistency . . . . . . . . . . . . . . . . . 7 67 3.5. The Role of Formal Liaisons . . . . . . . . . . . . . . . 7 68 4. Procedure for Review of Extensions . . . . . . . . . . . . . . 7 69 5. Some Specific Issues . . . . . . . . . . . . . . . . . . . . . 10 70 6. Intellectual Property . . . . . . . . . . . . . . . . . . . . 10 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 72 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 73 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 74 10. Change log [RFC Editor: please remove this section] . . . . . 11 75 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 76 11.1. Normative References . . . . . . . . . . . . . . . . . . . 12 77 11.2. Informative References . . . . . . . . . . . . . . . . . . 13 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 79 Intellectual Property and Copyright Statements . . . . . . . . . . 15 81 1. Introduction 83 BCP 9 [RFC2026] is the current definition of the IETF standards 84 track. This process normally applies not only to the initial 85 definition of a protocol, but also to any subsequent updates, such 86 that continued interoperability can be guaranteed. However, it is 87 not always clear whether extensions to a protocol should be made 88 within the IETF process, especially when they originate outside the 89 IETF community. This document lays down guidelines and procedures 90 for such extensions. 92 When developing protocols, IETF Working Groups (WGs) typically 93 include mechanisms whereby these protocols can be extended in the 94 future. It is of course a good principle to design extensibility 95 into protocols; one common definition of a successful protocol is one 96 that becomes widely used in ways not originally anticipated. Well- 97 designed extensibility mechanisms facilitate the evolution of 98 protocols and help make it easier to roll-out incremental changes in 99 an interoperable fashion. At the same time, experience has shown 100 that extensibility features should be limited to what is clearly 101 necessary when the protocol is developed and any later extensions 102 should be done carefully and with a full understanding of the base 103 protocol, existing implementations, and current operational practice. 104 However, it is not the purpose of this document to describe the 105 architectural principles of sound extensibility design. 107 When extensions to IETF protocols are made within the IETF, the 108 normal IETF process is followed, including the normal process for 109 IETF-wide review, and approval by the IESG. Extensions developed in 110 this way should respect the same architectural principles and 111 technical criteria as any other IETF work. 113 In addition to the IETF itself, other Standards Development 114 Organizations (SDOs), vendors and technology fora may identify a 115 requirement for an extension to an IETF protocol. The question 116 addressed by this document is how such bodies should proceed. There 117 are several possible scenarios: 118 1. The requirement is straightforward and is within the scope of 119 whatever extension mechanism the base protocol includes. 120 2. The requirement is, or may be, outside that scope, and: 121 1. The IETF still has an active WG in the area; 122 2. The IETF has no active WG, but has relevant expertise; 123 3. The IETF no longer has a nucleus of relevant expertise. 125 Especially in the latter three cases, there are technical risks in 126 extension design, described in the next section. These risks are 127 higher when extensions to IETF protocols are made outside the IETF 128 and without consulting the IETF. 130 This document is focussed on appropriate procedures and practices to 131 minimize the chance that extensions developed outside the IETF will 132 encounter these risks and therefore become useless or, worse, 133 damaging to interoperability. Architectural considerations are 134 documented elsewhere. This document is directed principally at other 135 SDOs and vendors considering requirements for extensions to IETF 136 protocols. It does not modify formal IETF processes. 138 The IETF claims no special position. Everything said here about IETF 139 protocols would apply with equal force to protocols specified by any 140 SDO. The IETF should follow whatever procedures another SDO lays 141 down for extensions to its own protocols, if the IETF identifies a 142 need for such an extension. 144 2. Technical Risks in Extensions 146 Extensions may be developed without full understanding of why the 147 existing protocol was designed the way that it is - e.g., what ideas 148 were brought up during the original development and rejected because 149 of some problem with them. Also, extensions could unintentionally 150 negate some key function of the existing protocol (such as security 151 or congestion control). Design choices can be made without analyzing 152 their impact on the protocol as a whole, and basic underlying 153 architectural principles of the protocol can be violated. Of course, 154 the IETF itself is not immune to such mistakes, suggesting a need for 155 WGs to document their design decisions (including paths rejected) and 156 some rationale for those decisions, for the benefit of both those 157 within the IETF and those outside the IETF, perhaps years later. 159 Documentation of non-IETF extensions can sometimes be hard to obtain, 160 so assessing the quality of the specification and verifying 161 interoperability can be hard or impossible. Also, there is a risk 162 that mutually incompatible extensions may be developed independently. 164 A set of interrelated extensions to multiple protocols typically 165 carries a greater danger of interoperability issues or 166 incompatibilities than a simple extension. Consequently, it is 167 important that such proposals receive earlier and more in-depth 168 review than unitary extensions. 170 All that can be said about extensions applies with equal or greater 171 force to variations - in fact, by definition, protocol variations 172 damage interoperability. They must therefore be intensely 173 scrutinized. An extension adds features, and if well designed allows 174 interoperability between old and new implementations. A variation 175 modifies features, in such a way that old and new implementations may 176 not interoperate. Throughout this document, what is said about 177 extensions also applies to variations. 179 3. General Considerations 181 3.1. The Importance of Interoperability 183 According to its Mission Statement [RFC3935], the IETF produces high 184 quality, relevant technical and engineering documents, including 185 protocol standards. The mission statement goes on to say that the 186 benefit of these standards to the Internet "is in interoperability - 187 that multiple products implementing a standard are able to work 188 together in order to deliver valuable functions to the Internet's 189 users." 191 One consequence of this mission is that the IETF designs protocols 192 for the single Internet. The IETF expects its protocols to work the 193 same everywhere. Protocol extensions designed for limited 194 environments may be reasonable provided that products with these 195 extensions interoperate with products without the extensions. 196 Extensions that break interoperability are unacceptable when products 197 with and without the extension are mixed. It is the IETF's 198 experience that this tends to happen on the Internet even when the 199 original designers of the extension did not expect this to happen. 201 Another consequence of this definition of interoperability is that 202 the IETF values the ability to exchange one product implementing a 203 protocol with another. The IETF often specifies mandatory-to- 204 implement functionality as part of its protocols so that there is a 205 core set of functionality sufficient for interoperability that all 206 products implement. The IETF tries to avoid situations where 207 protocols need to be profiled to specify which optional features are 208 required for a given environment, because doing so harms 209 interoperability on the Internet as a whole. 211 The IETF, and in particular the IESG, will apply these considerations 212 when evaluating protocol extensions proposed inside or outside the 213 IETF. 215 3.2. Registered Values and the Importance of IANA Assignments 217 An extension is often likely to make use of additional values added 218 to an existing IANA registry (in many cases, simply by adding a new 219 "TLV" (type-length-value) field). It is essential that such new 220 values are properly registered by the applicable procedures, 221 including expert review where applicable (see BCP 26, [RFC2434]). 222 Extensions may even need to create new IANA registries in some cases. 224 Experience shows that the importance of this is often underestimated 225 during extension design; designers sometimes assume that a new 226 codepoint is theirs for the asking, or even simply for the taking. 227 This is hazardous; it is far too likely that someone just taking a 228 protocol value will find that the same value will later be formally 229 assigned to another function, thus guaranteeing an interoperability 230 problem. 232 In many cases IANA assignment requests trigger a thorough technical 233 review of the proposal by a designated IETF expert reviewer. 234 Requests are sometimes refused after such a review. Thus, extension 235 designers must pay particular attention to any needed IANA 236 assignments and to the applicable criteria. 238 3.3. Significant extensions require technical review 240 Some extensions may be considered minor (e.g. adding a 241 straightforward new TLV to an application protocol, which will only 242 impact a subset of hosts) and some may be considered major (e.g. 243 adding a new IP option type, which will potentially impact every node 244 on the Internet). This is essentially a matter of judgement. It 245 could be argued that anything requiring at most Expert Review in 246 [RFC2434] is probably minor, and anything beyond that is major. 247 However, even an apparently minor extension may have unforeseen 248 consequences on interoperability. Thus, the distinction between 249 major and minor is less important than ensuring that the right amount 250 of technical review takes place in either case. The expertise for 251 such review for IETF protocols lies within the IETF. 253 There may sometimes be doubt whether a particular proposal is or is 254 not truly a protocol extension. When in doubt, it is preferable to 255 err on the side of additional review. However, it should be noted 256 that if an 'extension' only consists of registering a new value with 257 IANA in a First Come First Served registry [RFC2434], this document 258 is not intended to require formal IETF review. Informal review by 259 experts may nevertheless be valuable. In other cases (Section 5), 260 there is a well-specified procedure for extensions which should be 261 followed. 263 The only safe rule is that, even if an extension appears minor to the 264 person proposing it, early review by subject matter experts is 265 advisable. The appropriate forum for such review is the IETF, either 266 in the relevant WG or Area, or by individual IETF experts if no such 267 WG exists. 269 3.4. Quality and Consistency 271 In order to be adequately reviewed by relevant experts, a proposed 272 extension must be documented in a clear and well-written 273 specification that IETF subject matter experts have access to and can 274 review. Ideally, such a document would be published as an Internet 275 Draft, using terminology and content that is sufficiently consistent 276 with the unextended specification that these experts can readily 277 identify the technical changes proposed at an early stage. 279 3.5. The Role of Formal Liaisons 281 The IETF has formal liaisons in place with a number of SDOs; 282 documentation of the liaison process is in [RFC4052], [RFC4053], and 283 [I-D.iab-liaison-guidelines]. These liaison channels should be used 284 as relevant for discussing and reviewing extensions, as should 285 informal communication at the engineering level. Where formal 286 liaison does not exist, the point of contact in the IETF should be 287 the Chairs of relevant WGs, the most appropriate Area Director, or in 288 case of doubt the IESG as a whole. 290 4. Procedure for Review of Extensions 292 In some cases, explicit provision is made in the relevant RFCs for 293 extending individual IETF protocols. Nothing in this document 294 overrides such procedures. Some such cases are mentioned in 295 Section 5. 297 There are several ways in which an extension to an IETF protocol can 298 be considered for publication as an RFC: 299 1. Extensions to IETF protocols developed within the IETF will be 300 subject to the normal IETF process, exactly like new designs. It 301 is not suggested that this is a panacea; appropriate cross- 302 working-group and cross-Area review is needed within the IETF to 303 avoid oversights and mistakes. 304 2. Extensions to IETF protocols discussed in an IRTF Research Group 305 may well be the prelude to regular IETF discussion. However, a 306 Research Group may desire to specify an experimental extension 307 before the work is mature enough for IETF processing. In this 308 case, the Research Group is required to involve appropriate IETF 309 or IANA experts in their process to avoid oversights. 310 3. Extensions to IETF protocols described in Independent Submissions 311 to the RFC Editor are subject to IESG review, currently described 312 in BCP 92 [RFC3932]. If appropriate, the IESG advises the RFC 313 Editor that full IETF processing is needed, or that relevant IANA 314 procedures need to be followed before publication can proceed. 315 Note that Independent Submissions cannot be placed on the IETF 316 Standards Track; they would need to enter full IETF processing. 318 Where vendors or other SDOs identify a requirement for extending an 319 IETF protocol, their first step should be to consider the scenarios 320 listed in Section 1. If the requirement is straightforward and is 321 within the scope of a documented extension mechanism, the way is 322 clear and the documented mechanism must be followed. If these two 323 conditions are not met, the next step should be to contact the 324 relevant IETF Area Director to check whether there is an active WG in 325 the area or at least if relevant expertise is available in the IETF. 326 At this point it will be possible to to select the most appropriate 327 of the above three routes. Regular IETF process is most likely to be 328 suitable, assuming sufficient interest can be found in the IETF 329 community. IRTF process is unlikely to be suitable unless there is a 330 genuine research context for the proposed extension. 332 In the event that the IETF no longer has relevant expertise, there 333 are still two choices to discuss with the Area Director: bring the 334 work to the IETF (i.e. the IETF imports expertise) or reach mutual 335 agreement to do the work elsewhere (i.e. the IETF exports change 336 control). 338 In the case of an SDO that identifies a requirement for a 339 standardised extension, a standards development process within the 340 IETF (while maintaining appropriate liaison) is strongly recommended 341 in preference to publishing a non-IETF standard. Otherwise, the 342 implementor community will be faced with a standard split into two or 343 more parts in different styles, obtained from different sources, with 344 no unitary control over quality, compatibility, interoperability, and 345 intellectual property conditions. Note that, since participation in 346 the IETF is open, there is no formality or restriction for 347 participants in other SDOs choosing to work in the IETF as well. In 348 some cases (see Section 5) the IETF has well defined procedures for 349 this in place. 351 Naturally, SDOs can and do develop scenarios, requirements and 352 architectures based on IETF specifications. It is only actual 353 protocol extensions and changes that need to go through the IETF 354 process. However, there is large risk of wasted effort if 355 significant investment is made in planning stages for use of IETF 356 technology without early review and feedback from the IETF. Other 357 SDOs are encouraged to communicate informally or formally with the 358 IETF as early as possible, to avoid false starts. Early technical 359 review in a collaborative spirit is of great value. Each SDO can 360 "own" its ideas and discuss them in its own fora, but should start 361 talking to the IETF experts about those ideas the moment the idea is 362 well formulated. It is understood that close collaboration may be 363 needed in order that the IETF experts correctly understand the 364 systems architecture envisaged by the other SDO. This is much 365 preferable to a situation where another SDO presents the IANA and the 366 IETF with a 'fait accompli.' 368 Vendors that identify a requirement for an extension are strongly 369 recommended to start informal discussion in the IETF and to publish a 370 preliminary Internet Draft describing the requirements. This will 371 allow the vendor, and the community, to evaluate whether there is 372 community interest and whether there are any major or fundamental 373 issues. However, in the case of a vendor that identifies a 374 requirement for a proprietary extension that does not generate 375 interest in the IETF (or IRTF) communities, an Independent Submission 376 to the RFC Editor is strongly recommended in preference to publishing 377 a proprietary document. Not only does this bring the draft to the 378 attention of the community; it also ensures a minimum of review 379 [RFC3932], and (if published as an RFC) makes the proprietary 380 extension available to the whole community. 382 If, despite these recommendations, a vendor or SDO does choose to 383 publish its own specification for an extension to an IETF protocol, 384 the following guidance applies: 385 o Extensions to IETF protocols should be well, and publicly, 386 documented, and reviewed at an early stage by the IETF community 387 to be sure that the extension does not undermine basic assumptions 388 and safeguards designed into the protocol, such as security 389 functions, or undermine its architectural integrity. 390 o Vendors and other SDOs are formally requested to submit any such 391 proposed publications for IETF review, by an established liaison 392 channel if it exists, or by direct communication with relevant WG 393 or with the IESG. This should be done at an early stage, before a 394 large investment of effort has taken place, in case basic problems 395 are revealed. When there is a formal liaison in place between the 396 other SDO and the IETF, the liaison channel should be used to 397 ensure that review takes place, both by relevant experts and by 398 established review teams or Directorates within the IETF. If 399 there is no formal liaison, the other SDO or vendor should ask the 400 IESG (or a relevant Area Director) to obtain such reviews. Note 401 that general aspects such as security, internationalization and 402 management may need review, as well as the protocol as such. 403 o In the case of extensions involving only routine IANA parameter 404 assignments, for which there is an underlying IETF specification 405 containing clear IANA Considerations, this request is satisfied as 406 long as those considerations are satisfied (see [RFC2434]). 407 Anything beyond this requires an explicit protocol review by 408 experts within the IETF. 409 o Note that, like IETF specifications, such proposed publications 410 must include an IANA considerations section to ensure that 411 protocol parameter assignments that are needed to deploy 412 extensions are not made until after a proposed extension has 413 received adequate review, and then to ensure that IANA has precise 414 guidance on how to make those assignments. 416 5. Some Specific Issues 418 It is relatively common for MIB modules, which are all in effect 419 extensions of the SMI data model, to be defined or extended outside 420 the IETF. BCP 111 [RFC4181] offers detailed guidance for authors and 421 reviewers. 423 A number of protocols have foreseen experimental values for certain 424 IANA parameters, so that experimental usages and extensions may be 425 tested without need for a special parameter assignment. It must be 426 stressed that such values are not intended for production use or as a 427 way to evade the type of technical review described in this document. 428 See [RFC3692] and [I-D.fenner-iana-exp-2780]. 430 RADIUS [RFC2865] is designed to carry attributes and allow definition 431 of new attributes. But it is important that discussion of new 432 attributes involve the IETF community of experts knowledgeable about 433 the protocol's architecture and existing usage in order to fully 434 understand the implications of a proposed extension. Adding new 435 attributes without such discussion creates a high risk of 436 interoperability or functionality failure. For this reason among 437 others, the IETF has an active RADIUS Extensions WG at the time of 438 writing. 440 There are certain documents that specify a change process for 441 specific IETF protocols, such as: 442 The SIP change process [RFC3427] 443 The (G)MPLS change process [I-D.andersson-rtg-gmpls-change] 445 This document does not override such specific change processes. 447 6. Intellectual Property 449 All IETF documents fall under the IETF's intellectual property rules, 450 BCP 78 [RFC3978] and BCP 79 [RFC3979], as amended. In particular, 451 there are restrictions on the production of derivative works, and 452 there are rights that remain with the original authors. Anybody 453 outside the IETF considering an extension based on an IETF document 454 must bear these legal restrictions and rights in mind. 456 7. Security Considerations 458 An extension must not introduce new security risks without also 459 providing an adequate counter-measure, and in particular it must not 460 inadvertently defeat security measures in the unextended protocol. 461 This aspect must always be considered during IETF review. 463 8. IANA Considerations 465 The IETF requests IANA to pay attention to the requirements of this 466 document when requested to make protocol parameter assignments for 467 vendors or other SDOs, i.e. to respect the IANA Considerations of all 468 RFCs that contain them, and the general considerations of BCP 26 469 [RFC2434]. 471 9. Acknowledgements 473 This document is heavily based on an earlier draft under a different 474 title by Scott Bradner and Thomas Narten. 476 That earlier draft stated: The initial version of this document was 477 put together by the IESG in 2002. Since then, it has been reworked 478 in response to feedback from John Loughney, Henrik Levkowetz, Mark 479 Townsley, Randy Bush, Bernard Aboba, and others. 481 Ted Hardie, Scott Brim, Dan Romascanu, Jari Arkko, Loa Andersson, 482 Adrian Farrel, Roy Fielding, Keith Moore, Bernard Aboba, Elwyn 483 Davies, Stephen Trowbridge, and Ted Ts'o also made valuable comments 484 on this document. 486 Sam Hartman contributed the section on interoperability. 488 This document was produced using the xml2rfc tool [RFC2629]. 490 10. Change log [RFC Editor: please remove this section] 492 This draft replaces draft-iesg-vendor-extensions. 494 draft-carpenter-protocol-extensions-02: 2006-09-19. Tuning of tone, 495 significant reordering of material, and other updates in response to 496 IESG comments. Added text on interoperability and short discussion 497 of formal liaisons. 499 draft-carpenter-protocol-extensions-02: 2006-09-08. Clarifications 500 in response to IETF Last Call comments. Most significantly, 501 clarified that this document does not override change processes that 502 have been documented for specific protocols. Updated authorship. 504 draft-carpenter-protocol-extensions-01: 2006-08-04. Removed 505 additional architectural material, added material on MIBs, 506 experimental values and IPR, reflected other comments. Extended 507 scope to cover variations as well as extensions. Updated authorship. 509 draft-carpenter-protocol-extensions-00: original version, 2006-06-16. 510 Derived from draft-iesg-vendor-extensions-02.txt dated 2004-06-04 by 511 focussing on procedural issues; the more architectural issues in that 512 draft are left to a separate document. 514 11. References 516 11.1. Normative References 518 [I-D.fenner-iana-exp-2780] 519 Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, 520 ICMPv6, UDP and TCP Headers", 521 draft-fenner-iana-exp-2780-05 (work in progress), 522 June 2006. 524 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 525 3", BCP 9, RFC 2026, October 1996. 527 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 528 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 529 October 1998. 531 [RFC3427] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., 532 and B. Rosen, "Change Process for the Session Initiation 533 Protocol (SIP)", BCP 67, RFC 3427, December 2002. 535 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 536 Considered Useful", BCP 82, RFC 3692, January 2004. 538 [RFC3932] Alvestrand, H., "The IESG and RFC Editor Documents: 539 Procedures", BCP 92, RFC 3932, October 2004. 541 [RFC3935] Alvestrand, H., "A Mission Statement for the IETF", 542 BCP 95, RFC 3935, October 2004. 544 [RFC3978] Bradner, S., "IETF Rights in Contributions", BCP 78, 545 RFC 3978, March 2005. 547 [RFC3979] Bradner, S., "Intellectual Property Rights in IETF 548 Technology", BCP 79, RFC 3979, March 2005. 550 [RFC4052] Daigle, L. and Internet Architecture Board, "IAB Processes 551 for Management of IETF Liaison Relationships", BCP 102, 552 RFC 4052, April 2005. 554 [RFC4053] Trowbridge, S., Bradner, S., and F. Baker, "Procedures for 555 Handling Liaison Statements to and from the IETF", 556 BCP 103, RFC 4053, April 2005. 558 [RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB 559 Documents", BCP 111, RFC 4181, September 2005. 561 11.2. Informative References 563 [I-D.andersson-rtg-gmpls-change] 564 Andersson, L. and A. Farrel, "Change Process for 565 Multiprotocol Label Switching (MPLS) and Generalized MPLS 566 (GMPLS) Protocols and Procedures", 567 draft-andersson-rtg-gmpls-change-03 (work in progress), 568 August 2006. 570 [I-D.iab-liaison-guidelines] 571 Andersson, L., "Guidelines for Acting as an IETF Liaison 572 to Another Organization", draft-iab-liaison-guidelines-04 573 (work in progress), June 2006. 575 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 576 June 1999. 578 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 579 "Remote Authentication Dial In User Service (RADIUS)", 580 RFC 2865, June 2000. 582 Authors' Addresses 584 Scott Bradner 585 Harvard University 586 29 Oxford St. 587 Cambridge, MA 02138 588 US 590 Email: sob@harvard.edu 591 Brian Carpenter (ed) 592 IBM 593 8 Chemin de Blandonnet 594 1214 Vernier, 595 CH 597 Email: brc@zurich.ibm.com 599 Thomas Narten 600 IBM 601 3039 Cornwallis Ave. 602 PO Box 12195 - BRQA/502 603 Research Triangle Park, NC 27709-2195 604 US 606 Email: narten@us.ibm.com 608 Full Copyright Statement 610 Copyright (C) The Internet Society (2006). 612 This document is subject to the rights, licenses and restrictions 613 contained in BCP 78, and except as set forth therein, the authors 614 retain all their rights. 616 This document and the information contained herein are provided on an 617 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 618 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 619 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 620 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 621 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 622 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 624 Intellectual Property 626 The IETF takes no position regarding the validity or scope of any 627 Intellectual Property Rights or other rights that might be claimed to 628 pertain to the implementation or use of the technology described in 629 this document or the extent to which any license under such rights 630 might or might not be available; nor does it represent that it has 631 made any independent effort to identify any such rights. Information 632 on the procedures with respect to rights in RFC documents can be 633 found in BCP 78 and BCP 79. 635 Copies of IPR disclosures made to the IETF Secretariat and any 636 assurances of licenses to be made available, or the result of an 637 attempt made to obtain a general license or permission for the use of 638 such proprietary rights by implementers or users of this 639 specification can be obtained from the IETF on-line IPR repository at 640 http://www.ietf.org/ipr. 642 The IETF invites any interested party to bring to its attention any 643 copyrights, patents or patent applications, or other proprietary 644 rights that may cover technology that may be required to implement 645 this standard. Please address the information to the IETF at 646 ietf-ipr@ietf.org. 648 Acknowledgment 650 Funding for the RFC Editor function is provided by the IETF 651 Administrative Support Activity (IASA).