idnits 2.17.1 draft-carpenter-protocol-extensions-02.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 523. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 534. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 541. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 547. ** 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 8, 2006) is 6439 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 12, 2007 IBM 7 September 8, 2006 9 Procedures for protocol extensions and variations 10 draft-carpenter-protocol-extensions-02 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 12, 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 larger IETF community. 47 Experience with IETF protocols has shown that extensibility of 48 protocols without early IETF review can cause problems. The document 49 also recommends that major extensions to or variations of IETF 50 protocols only take place through normal IETF processes or in 51 coordination with the IETF. 53 This document is directed principally at other Standards Development 54 Organizations (SDOs) and vendors considering requirements for 55 extensions to IETF protocols. It does not modify formal IETF 56 processes. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. General Considerations . . . . . . . . . . . . . . . . . . . . 4 62 2.1. Quality and Consistency . . . . . . . . . . . . . . . . . 4 63 2.2. Registered Values and the Importance of IANA 64 Assignments . . . . . . . . . . . . . . . . . . . . . . . 4 65 2.3. All extensions require technical review . . . . . . . . . 5 66 3. Procedure for Review of Extensions . . . . . . . . . . . . . . 6 67 4. Some Specific Issues . . . . . . . . . . . . . . . . . . . . . 8 68 5. Intellectual Property . . . . . . . . . . . . . . . . . . . . 9 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 71 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 72 9. Change log [RFC Editor: please remove this section] . . . . . 10 73 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 75 10.2. Informative References . . . . . . . . . . . . . . . . . . 11 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 77 Intellectual Property and Copyright Statements . . . . . . . . . . 13 79 1. Introduction 81 For the origins of this draft, please see the Acknowledgements 82 section. 84 BCP 9 [RFC2026] is the current definition of the IETF standards 85 track. It is implicitly presumed that this process will apply not 86 only to the initial definition of a protocol, but also to any 87 subsequent updates, such that continued interoperability can be 88 guaranteed. However, it is not always clear whether extensions to a 89 protocol fall within this presumption, especially when they originate 90 outside the IETF community. This document lays down procedures for 91 such extensions. 93 When developing protocols, IETF working groups typically include 94 mechanisms whereby these protocols can be extended in the future. In 95 addition to the IETF itself, vendors, standards development 96 organizations and technology fora have used those facilities. 97 Although the results are often good, protocol extensions can also 98 result in poorly designed mechanisms and in non-interoperability. 100 It is of course a good principle to design extensibility into 101 protocols; one common definition of a successful protocol is one that 102 becomes widely used in ways not originally anticipated. Well- 103 designed extensibility mechanisms facilitate the evolution of 104 protocols and help make it easier to roll-out incremental changes in 105 an interoperable fashion. At the same time, experience has shown 106 that extensibility features should be limited to what is clearly 107 necessary when the protocol is developed and any later extensions 108 should be done carefully and with a full understanding of the base 109 protocol, existing implementations, and current operational practice. 110 However, it is not the purpose of this document to describe the 111 architectural principles of sound extensibility design. 113 When extensions to IETF protocols are made within the IETF, the 114 normal IETF process is followed, including the normal process for 115 IETF-wide review, and approval by the IESG. It is presumed that this 116 will ensure that extensions developed in this way will respect all 117 applicable architectural principles and technical criteria. 119 When extensions to IETF protocols are made outside the IETF and 120 without consulting the IETF, experience has shown that they may not 121 be done with the full understanding of why the existing protocol was 122 designed the way that it is - e.g., what ideas were brought up during 123 the original development and rejected because of some problem with 124 them. Also such extensions could, because of a lack of 125 understanding, negate some key function of the existing protocol 126 (such as security or congestion control). Short-sighted design 127 choices are sometimes made, and basic underlying architectural 128 principles of the protocol are sometimes violated. Of course, the 129 IETF itself is not immune to such mistakes, suggesting a need for 130 working groups to document their design decisions (including paths 131 rejected) and some rationale for those decisions, for the benefit of 132 both those within IETF and those outside of IETF. 134 Additionally, documentation of non-IETF extensions can be hard to 135 obtain, so assessing the quality of the specification is hard and 136 achieving interoperability can be hard. Also, there is a risk that 137 mutually incompatible extensions may be developed independently. 139 Simply put, the early peer review by experienced subject matter 140 experts that occurs within the IETF process may be lacking, 141 regardless of the competence or efficiency of the outside 142 developers.. 144 All that can be said about extensions applies with equal or greater 145 force to variations - in fact, by definition, protocol variations 146 damage interoperability. They must therefore be intensely 147 scrutinized. Throughout this document, what is said about extensions 148 also applies to variations. 150 This document is focussed on appropriate process and practices to 151 ensure that extensions developed outside the IETF will not fall into 152 these traps and therefore become useless or, worse, damaging to 153 interoperability. Architectural considerations are documented 154 elsewhere. This document is directed principally at other Standards 155 Development Organizations (SDOs) and vendors considering requirements 156 for extensions to IETF protocols. It does not modify formal IETF 157 processes. 159 2. General Considerations 161 2.1. Quality and Consistency 163 In order to be adequately reviewed by relevant experts, a proposed 164 extension must be documented in a clear and well-written 165 specification normally published as an Internet Draft, which must be 166 sufficiently consistent in terminology and content with the 167 unextended specification that these experts can readily identify the 168 technical changes proposed at an early stage. 170 2.2. Registered Values and the Importance of IANA Assignments 172 An extension is often likely to make use of additional values added 173 to an existing IANA registry (in many cases, simply by adding a new 174 "TLV" (type-length-value) field). It is essential that such new 175 values are properly registered by the applicable procedures, 176 including expert review where applicable (see BCP 26, [RFC2434]). 177 Extensions may even need to create new IANA registries in some cases. 179 Experience shows that the importance of this is often underestimated 180 during extension design; designers sometimes assume that a new 181 codepoint is theirs for the asking, or even simply for the taking. 182 This is hazardous; it is far too likely that someone just taking a 183 protocol value will find that the same value will later be formally 184 assigned to another function, thus guaranteeing an interoperability 185 problem. 187 In many cases IANA assignment requests trigger a thorough technical 188 review of the proposal by a designated IETF expert reviewer. 189 Requests are sometimes refused after such a review. Thus, extension 190 designers must pay particular attention to any needed IANA 191 assignments and to the applicable criteria. 193 2.3. All extensions require technical review 195 Some extensions may be considered minor (e.g. adding a 196 straightforward new TLV to an application protocol, which will only 197 impact a subset of hosts) and some may be considered major (e.g. 198 adding a new IP option type, which will potentially impact every node 199 on the Internet). This is essentially a matter of judgement. It 200 could be argued that anything requiring at most Expert Review in 201 [RFC2434] is probably minor, and anything beyond that is major. 202 However, even an apparently minor extension may have unforeseen 203 consequences on interoperability. Thus, the distinction between 204 major and minor is less important than ensuring that the right amount 205 of technical review takes place in either case. The expertise for 206 such review for IETF protocols lies within the IETF. 208 For example, RADIUS [RFC2865] is designed to carry attributes and 209 allow definition of new attributes. But it is important that 210 discussion of new attributes involve the IETF community of experts 211 knowledgeable about the protocol's architecture and existing usage in 212 order to fully understand the implications of a proposed extension. 213 Adding new attributes without such discussion creates a high risk of 214 interoperability or functionality failure. For this reason among 215 others, the IETF has an active RADIUS Extensions working group at the 216 time of writing. 218 Thus the only safe rule is that, even if an extension appears minor 219 to the person proposing it, early review by subject matter experts is 220 always advisable. The proper forum for such review is the IETF, 221 either in the relevant Working Group, or by individual IETF experts 222 if no such WG exists. 224 There may sometimes be doubt whether a particular proposal is or is 225 not truly a protocol extension. When in doubt, it is preferable to 226 err on the side of additional review. However, it should be noted 227 that if an 'extension' only consists of registering a new value with 228 IANA in a First Come First Served registry [RFC2434], this document 229 is not intended to require formal IETF review. Informal review by 230 experts may nevertheless be valuable. 232 3. Procedure for Review of Extensions 234 In some cases, explicit provision is made in the relevant RFCs for 235 extending individual IETF protocols. Nothing in this document 236 overrides such procedures. Some such cases are mentioned in 237 Section 4. 239 There are several ways in which an extension to an IETF protocol can 240 be considered for publication as an RFC: 241 1. Extensions to IETF protocols developed within the IETF will be 242 subject to the normal IETF process, exactly like new designs. It 243 is not suggested that this is a panacea; appropriate cross- 244 working-group and cross-Area review is needed within the IETF to 245 avoid oversights and mistakes. 246 2. Extensions to IETF protocols discussed in an IRTF Research Group 247 may well be the prelude to regular IETF discussion. However, a 248 Research Group may desire to specify an experimental extension 249 before the work is mature enough for IETF processing. In this 250 case, the Research Group is required to involve appropriate IETF 251 or IANA experts in their process to avoid oversights. 252 3. Extensions to IETF protocols described in Independent Submissions 253 to the RFC Editor are subject to IESG review, currently described 254 in BCP 92 [RFC3932]. If appropriate, the IESG advises the RFC 255 Editor that full IETF processing is needed, or that relevant IANA 256 procedures need to be followed before publication can proceed. 257 Note that Independent Submissions cannot be placed on the IETF 258 Standards Track; they would need to enter full IETF processing. 260 Where vendors or other Standards Development Organisations (SDOs) see 261 a requirement for extending an IETF protocol, their first step should 262 be to select the most appropriate of the above three routes. Regular 263 IETF process is most likely to be suitable, assuming sufficient 264 interest can be found in the IETF community. IRTF process is 265 unlikely to be suitable unless there is a genuine research context 266 for the proposed extension. 268 In the case of an SDO that identifies a requirement for a 269 standardised extension, a standards development process within the 270 IETF (while maintaining appropriate liaison) is strongly recommended 271 in preference to publishing a non-IETF standard. Otherwise, the 272 implementor community will be faced with a standard split into two or 273 more parts in different styles, obtained from different sources, with 274 no unitary control over quality, compatibility, interoperability, and 275 intellectual property conditions. Note that, since participation in 276 the IETF is open, there is no formality or restriction for 277 participants in other SDOs choosing to work in the IETF as well. In 278 some cases (see Section 4) the IETF has well defined procedures for 279 this in place. 281 Naturally, SDOs can and do develop scenarios, requirements and 282 architectures based on IETF specifications. It is only actual 283 protocol extensions and changes that need to go through the IETF 284 process. However, there is still a large potential for harm if 285 significant investment is made in planning stages for use of IETF 286 technology without early review and feedback from the IETF. Other 287 SDOs are encouraged to communicate informally or formally with the 288 IETF as early as possible, to avoid false starts. Early technical 289 review in a collaborative spirit is of great value. Each SDO can 290 "own" its ideas and discuss them in its own fora, but should start 291 talking to the IETF experts about those ideas the moment the idea is 292 well formulated. It is understood that close collaboration may be 293 needed in order that the IETF experts correctly understand the 294 systems architecture envisaged by the other SDO. This is much 295 preferable to a situation where another SDO presents the IANA and the 296 IETF with a 'fait accompli.' 298 Vendors that identify a requirement for an extension are strongly 299 recommended to start informal discussion in the IETF and to publish a 300 preliminary Internet Draft describing the requirements. This will 301 allow the vendor, and the community, to evaluate whether there is 302 community interest and whether there are any major or fundamental 303 issues. However, in the case of a vendor that identifies a 304 requirement for a proprietary extension that does not generate 305 interest in the IETF (or IRTF) communities, an Independent Submission 306 to the RFC Editor is strongly recommended in preference to publishing 307 a proprietary document, unless preliminary IETF discussion has 308 already revealed serious flaws in the proposal. Not only does this 309 bring the draft to the attention of the community; it also ensures a 310 minimum of community review [RFC3932], and (if published) makes the 311 proprietary extension available to the whole community. 313 If, despite these strong recommendations, a vendor or SDO does choose 314 to publish its own specification for an extension to an IETF 315 protocol, the following guidance applies: 317 o Extensions to IETF protocols should be well, and publicly, 318 documented, and reviewed at an early stage by the IETF community 319 to be sure that the extension does not undermine basic assumptions 320 and safeguards designed into the protocol, such as security 321 functions, or undermine its architectural integrity. 322 o Vendors and other SDOs are formally requested to submit any such 323 proposed publications for IETF review, by an established liaison 324 channel if it exists, or by direct communication with relevant 325 working group or with the IESG. This should be done at an early 326 stage, before a large investment of effort has taken place, in 327 case basic problems are revealed. When there is a formal liaison 328 in place between the other SDO and the IETF, the liaison channel 329 should be used to ensure that review takes place, both by relevant 330 experts and by established review teams or Directorates within the 331 IETF. If there is no formal liaison, the other SDO or vendor 332 should ask the IESG (or a relevant Area Director) to obtain such 333 reviews. Note that general aspects such as security, 334 internationalization and management may need review, as well as 335 the protocol as such. 336 o In the case of extensions involving only routine IANA parameter 337 assignments, for which there is an underlying IETF specification 338 containing clear IANA Considerations, this request is satisfied as 339 long as those considerations are satisfied (see [RFC2434]). 340 Anything beyond this requires an explicit protocol review by 341 experts within the IETF. 342 o Note that, like IETF specifications, such proposed publications 343 must include an IANA considerations section to ensure that 344 protocol parameter assignments that are needed to deploy 345 extensions are not made until after a proposed extension has 346 received adequate review, and then to ensure that IANA has precise 347 guidance on how to make those assignments. 349 4. Some Specific Issues 351 It is relatively common for MIB modules, which are all in effect 352 extensions of the SMI data model, to be defined or extended outside 353 the IETF. BCP 111 [RFC4181] offers detailed guidance for authors and 354 reviewers. 356 A number of protocols have foreseen experimental values for certain 357 IANA parameters, so that experimental usages and extensions may be 358 tested without need for a special parameter assignment. It must be 359 stressed that such values are not intended for production use or as a 360 way to evade the type of technical review described in this document. 361 See [RFC3692] and [I-D.fenner-iana-exp-2780]. 363 There are certain documents that specify a change process for 364 specific IETF protocols, such as: 365 The SIP change process [RFC3427] 366 The (G)MPLS change process [I-D.andersson-rtg-gmpls-change] 368 This document does not override such specific change processes. 370 5. Intellectual Property 372 All IETF documents fall under the IETF's intellectual property rules, 373 BCP 78 [RFC3978] and BCP 79 [RFC3979], as amended. In particular, 374 there are restrictions on the production of derivative works, and 375 there are rights that remain with the original authors. Anybody 376 outside the IETF considering an extension based on an IETF document 377 must bear these legal restrictions and rights in mind. 379 6. Security Considerations 381 An extension must not introduce new security risks without also 382 providing an adequate counter-measure, and in particular it must not 383 inadvertently defeat security measures in the unextended protocol. 384 This aspect must always be considered during IETF review. 386 7. IANA Considerations 388 The IETF requests IANA to pay attention to the requirements of this 389 document when requested to make protocol parameter assignments for 390 vendors or other SDOs, i.e. to respect the IANA Considerations of all 391 RFCs that contain them, and the general considerations of BCP 26 392 [RFC2434]. 394 8. Acknowledgements 396 This document is heavily based on an earlier draft under a different 397 title by Scott Bradner and Thomas Narten. 399 That earlier draft stated: The initial version of this document was 400 put together by the IESG in 2002. Since then, it has been reworked 401 in response to feedback from John Loughney, Henrik Levkowetz, Mark 402 Townsley, Randy Bush, Bernard Aboba, and others. 404 Ted Hardie, Scott Brim, Dan Romascanu, Jari Arkko, Loa Andersson, 405 Adrian Farrel, Roy Fielding, Keith Moore, Bernard Aboba, Elwyn 406 Davies, Stephen Trowbridge, and Ted Ts'o also made valuable comments 407 on this document. 409 This document was produced using the xml2rfc tool [RFC2629]. 411 9. Change log [RFC Editor: please remove this section] 413 This draft replaces draft-iesg-vendor-extensions. 415 draft-carpenter-protocol-extensions-02: 2006-09-08. Clarifications 416 in response to IETF Last Call comments. Most significantly, 417 clarified that this document does not override change processes that 418 have been documented for specific protocols. Updated authorship. 420 draft-carpenter-protocol-extensions-01: 2006-08-04. Removed 421 additional architectural material, added material on MIBs, 422 experimental values and IPR, reflected other comments. Extended 423 scope to cover variations as well as extensions. Updated authorship. 425 draft-carpenter-protocol-extensions-00: original version, 2006-06-16. 426 Derived from draft-iesg-vendor-extensions-02.txt dated 2004-06-04 by 427 focussing on procedural issues; the more architectural issues in that 428 draft are left to a separate document. 430 10. References 432 10.1. Normative References 434 [I-D.fenner-iana-exp-2780] 435 Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, 436 ICMPv6, UDP and TCP Headers", 437 draft-fenner-iana-exp-2780-05 (work in progress), 438 June 2006. 440 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 441 3", BCP 9, RFC 2026, October 1996. 443 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 444 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 445 October 1998. 447 [RFC3427] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., 448 and B. Rosen, "Change Process for the Session Initiation 449 Protocol (SIP)", BCP 67, RFC 3427, December 2002. 451 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 452 Considered Useful", BCP 82, RFC 3692, January 2004. 454 [RFC3932] Alvestrand, H., "The IESG and RFC Editor Documents: 456 Procedures", BCP 92, RFC 3932, October 2004. 458 [RFC3978] Bradner, S., "IETF Rights in Contributions", BCP 78, 459 RFC 3978, March 2005. 461 [RFC3979] Bradner, S., "Intellectual Property Rights in IETF 462 Technology", BCP 79, RFC 3979, March 2005. 464 [RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB 465 Documents", BCP 111, RFC 4181, September 2005. 467 10.2. Informative References 469 [I-D.andersson-rtg-gmpls-change] 470 Andersson, L. and A. Farrel, "Change Process for 471 Multiprotocol Label Switching (MPLS) and Generalized MPLS 472 (GMPLS) Protocols and Procedures", 473 draft-andersson-rtg-gmpls-change-03 (work in progress), 474 August 2006. 476 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 477 June 1999. 479 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 480 "Remote Authentication Dial In User Service (RADIUS)", 481 RFC 2865, June 2000. 483 Authors' Addresses 485 Scott Bradner 486 Harvard University 487 29 Oxford St. 488 Cambridge, MA 02138 489 US 491 Email: sob@harvard.edu 493 Brian Carpenter (ed) 494 IBM 495 8 Chemin de Blandonnet 496 1214 Vernier, 497 CH 499 Email: brc@zurich.ibm.com 500 Thomas Narten 501 IBM 502 3039 Cornwallis Ave. 503 PO Box 12195 - BRQA/502 504 Research Triangle Park, NC 27709-2195 505 US 507 Email: narten@us.ibm.com 509 Full Copyright Statement 511 Copyright (C) The Internet Society (2006). 513 This document is subject to the rights, licenses and restrictions 514 contained in BCP 78, and except as set forth therein, the authors 515 retain all their rights. 517 This document and the information contained herein are provided on an 518 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 519 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 520 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 521 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 522 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 523 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 525 Intellectual Property 527 The IETF takes no position regarding the validity or scope of any 528 Intellectual Property Rights or other rights that might be claimed to 529 pertain to the implementation or use of the technology described in 530 this document or the extent to which any license under such rights 531 might or might not be available; nor does it represent that it has 532 made any independent effort to identify any such rights. Information 533 on the procedures with respect to rights in RFC documents can be 534 found in BCP 78 and BCP 79. 536 Copies of IPR disclosures made to the IETF Secretariat and any 537 assurances of licenses to be made available, or the result of an 538 attempt made to obtain a general license or permission for the use of 539 such proprietary rights by implementers or users of this 540 specification can be obtained from the IETF on-line IPR repository at 541 http://www.ietf.org/ipr. 543 The IETF invites any interested party to bring to its attention any 544 copyrights, patents or patent applications, or other proprietary 545 rights that may cover technology that may be required to implement 546 this standard. Please address the information to the IETF at 547 ietf-ipr@ietf.org. 549 Acknowledgment 551 Funding for the RFC Editor function is provided by the IETF 552 Administrative Support Activity (IASA).