idnits 2.17.1 draft-iesg-vendor-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 3667, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 556. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 533. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 540. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 546. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 562), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 36. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 403: '..."A RADIUS server MAY ignore Attributes...' RFC 2119 keyword, line 404: '... RADIUS client MAY ignore Attributes...' RFC 2119 keyword, line 409: '... a given service MUST NOT implement th...' RFC 2119 keyword, line 411: '...fer ARAP service MUST NOT implement th...' RFC 2119 keyword, line 412: '...for ARAP. A NAS MUST treat a RADIUS a...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 398 has weird spacing: '...y, VSAs do no...' == Line 399 has weird spacing: '...clients and s...' == Line 400 has weird spacing: '...safe to ignor...' -- 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 4, 2004) is 7267 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) == Missing Reference: 'DHC' is mentioned on line 205, but not defined == Unused Reference: 'DHCP' is defined on line 492, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2434 (ref. 'IANA-CONSID') (Obsoleted by RFC 5226) == Outdated reference: A later version (-04) exists of draft-ietf-ops-mib-review-guidelines-02 Summary: 8 errors (**), 0 flaws (~~), 8 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Scott O. Bradner 3 Harvard University 4 Thomas Narten 5 IBM 6 June 4, 2004 8 Considerations on the Extensibility of IETF protocols 10 12 Status of this Memo 13 By submitting this Internet-Draft, I certify that any applicable 14 patent or other IPR claims of which I am aware have been disclosed, 15 and any of which I become aware will be disclosed, in accordance with 16 RFC 3668. 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 Copyright Notice 36 Copyright (C) The Internet Society (2004). All Rights Reserved. 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 Contents 51 Status of this Memo.......................................... 1 53 1. Introduction............................................. 2 55 2. Interoperability......................................... 3 57 3. Extensibility............................................ 4 58 3.1. Minor Extensions.................................... 5 59 3.2. Major Extensions.................................... 6 60 3.3. Classification of Major vs. Minor Extensions........ 6 62 4. Review of Proposed Protocol Extensions................... 7 64 5. Recommendation........................................... 7 66 6. Summary.................................................. 8 68 7. Examples................................................. 8 69 7.1. RADIUS Extensions................................... 9 70 7.2. RSVP Extensions..................................... 10 71 7.3. L2TP Extensions..................................... 10 73 8. IANA Considerations...................................... 11 75 9. Security Considerations.................................. 11 77 10. Acknowledgments......................................... 11 79 11. Informative References.................................. 11 81 12. Editor's Addresses...................................... 11 83 1. Introduction 85 When developing protocols, IETF working groups typically include 86 mechanisms whereby these protocols can be extended in the future. 87 Vendors, standards development organizations and technology fora have 88 used those facilities. Sometimes the result is a poorly designed 89 mechanism and non-interoperability. 91 It is of course a good principle to design extensiblity into 92 protocols; one common definition of a successful protocol is one that 93 becomes widely used in ways not originally anticipated. Well-designed 94 extensibility mechanisms facilitate the evolution of protocols and 95 help make it easier to roll-out incremental changes in an 96 interoperable fashion. At the same time, experience has shown that 97 extensibility features should be limited to what is clearly necessary 98 when the protocol is developed and any later extensions should be 99 done carefully and with a full understanding of the base protocol, 100 existing implementations, and current operational practice. 102 If extensions to IETF protocols are done outside the IETF, experience 103 has shown that documentation of these extensions can be hard to 104 obtain, short-sighted design choices are sometimes made, basic 105 underlying architectural principals of the protocol are sometimes 106 violated, assessing the quality of the specification is hard and 107 achieving interoperability can be hard. 109 This memo makes explicit some guiding principles based on the 110 community's experience with extensibility mechanisms. One of the key 111 principles is that protocols should not be made more extensible than 112 clearly necessary at inception, and that proposed extensions should 113 be reviewed by subject-matter experts familiar with the protocol 114 itself and how it is used in currently deployed systems. The IESG is 115 presently applying some version of these principles in evaluating 116 proposals for new extensions and in evaluating the extensibility of 117 new protocols. 119 2. Interoperability 121 The importance of extending protocols only in carefully thought-out 122 ways is driven by the overall goal of acheiving good 123 interoperability. Good interoperability stems from a number of 124 factors, including: 126 - having a well-written spec, that makes clear and precise what an 127 implementor needs to implement and what impact each individual 128 operation (e.g., a message sent to a peer) will have when 129 invoked. However, while necessary, a well-written spec is not by 130 itself sufficient to result in good interoperability. 132 - learning lessons from deployment, including understanding what 133 current implementations do and how a proposed extension will 134 interact with deployed systems. 136 - having an adequate transition story for deploying the new 137 extension. What impact will the proposed extension have on 138 implementations that do not understand it? Is there a way to 139 negotiate or determine the capabilities of a peer? 141 - being archtitecturally compatable with the base protocol. For 142 example, does the extension make use of features as envisioned 143 by the original protocol designers, or is a new mechanism being 144 invented? 146 - respecting underlying architectural or security assumptions 147 (including those that may not be well-documented, those that may 148 have arison as a result of operational experience, or those that 149 only became understood after the original protocol was 150 published). 152 - will the proposed extension (or its proposed usage) 153 operationally stress existing implementations or the underlying 154 protocol itself if widely deployed? 156 - some protocols have become critical components of the Internet 157 infrastructure. Does the proposed extension (or its proposed 158 usage) have the potential for negatively impacting such 159 infrastructure to the point where explicit steps would be 160 appropriate to firewall existing uses from new ones? 162 - does the proposed extension extend the data model in a major 163 way? Does the extension fundamentally change basic assumptions 164 about data handling within the protocol? For example, do the 165 extensions reverse the flow of data, allow formerly static 166 parameters to be changed on the fly, add new data types or 167 change assumptions relating to the frequency of reads/writes? 169 In practice, the only way to ensure that a proposed extension makes 170 sense and will result in good interoperability is to have the 171 extension reviewed by subject-matter experts familiar with the 172 technology. 174 Ideally, the document that defines a base protocol's extension 175 mechanisms will include guidance to future extension writers that 176 help them use extension mechanisms properly. It may also be possible 177 to define classes of extensions that need little or no review, while 178 other classes need wide review. The specific details will necessarily 179 be technology-specific. 181 3. Extensibility 183 The best defense against poorly thought-out extensions is review by 184 subject matter experts. Such experts can identify potential problems 185 early and suggest alternative approaches with fewer problems. To 186 improve interoperability, such review must take place before 187 significant deployment of an extension takes place. Once an extension 188 is deployed and in use, it becomes difficult or impossible to 189 deprecate the extension or otherwise recall implementations. 191 Protocols that permit easy extensions with minimal or no review, make 192 it likely that unreviewed extensions will be deployed and used in 193 practice. Consequently, protocols should not be made more extensible 194 than clearly necessary at inception, and the process for defining new 195 extensibility mechanisms must ensure that adequate review of proposed 196 extensions will take place before widespread adoption. In practice, 197 this means First Come First Served [IANA-CONSID] and similar policies 198 should be used very carefully, as they imply minimal or no review. 200 3.1. Minor Extensions 202 The amount and type of review necessary for a proposed extension can 203 vary considerably. For example, many protocols are designed to carry 204 opaque data, without examining or acting on the data at all. For 205 example, DHCP [DHC] transports options, but the contents of an 206 individual option is generally of no concern to the DHCP protocol 207 itself. Many other protocols provide such a capability, including 208 OSPF LSAs, BGP, Radius Attributes, Diameter AVPs, etc. A new 209 extension may be nothing more than having an existing protocol carry 210 a different kind of opaque data. In such cases, minimal review may be 211 adequate.. For the purposes of this document, we call such extensions 212 "Minor Extensions". Important points to note about Minor Extensions 213 include: 215 o The protocol is designed to carry such opaque data and no 216 changes to the underlying base protocol are needed to carry a 217 new type of data. Moreover, no changes are required to existing 218 and currently deployed implementations of the underlying 219 protocol unless they want to make use of the new data type. 221 o Using the existing protocol to carry a new type of opaque data 222 will not impact existing implementations or cause operational 223 problems. 225 Examples of minor extensions include the DHC vendor-specific option, 226 the enterprise OID tree for MIB modules, vnd. MIME types, and some 227 classes of (non-critical) certification extensions. Such extensions 228 can safely be made with minimal IETF coordination and are indicated 229 by having an IANA Considerations that allows assignments of code 230 points with minimal overhead (e.g., First Come First Served) [IANA- 231 CONSID]. 233 In order to increase the likelyhood that minor extensions are truly 234 minor, protocol documents should provide guidelines explaining how 235 they should be done. For example, even though DHCP carries opaque 236 data, defining a new option using completely unstructured data may 237 lead to an option that is (unnecessarily) hard for clients and 238 servers to process. In contrast, using widely-supported encoding 239 formats leads to better interoperability [XXX need ref]. Similarly, 240 SNMP MIB guidelines exist for defining the MIB objects that SNMP 241 carries [MIB-GUIDELINES]. 243 3.2. Major Extensions 245 Some extensions change the protocol itself (e.g, the bits-on-the- 246 wire), change the interpretation of previously defined Protocol Data 247 Units (PDUs), or require protocol-specific changes in the client, 248 server, or other intermediate nodes. Such changes can be both subtle 249 and significant, and generally warrant careful review. Examples here 250 would include new protocol message types. For the purposes of this 251 document, we call such extensions Major Extensions. 253 Major extensions have some or all of the following characteristics: 255 o Change or extend the way in which the basic underlying protocol 256 works, e.g., by changing the semantics of existing PDUs or 257 defining new message types that require implementation changes 258 in existing and deployed implementations of the protocols, even 259 if they do not want to make use of the new functions or data 260 types. 262 o Change basic architectural assumptions about the protocol that 263 have been an assumed part of the protocol and its 264 implementations. 266 o Lead to new uses of the protocol in ways not originally intended 267 or investigated, potentially leading to operational and other 268 difficulties when deployed, even in cases where the "on-the- 269 wire" format has not changed. For example, the overall quantity 270 of traffic the protocol is expected to carry might go up 271 substantially, typical packet sizes may increase compared to 272 existing deployments, simple implementation algorithms that are 273 widely deployed may not scale sufficiently or otherwise be up to 274 the new task at hand, etc. 276 3.3. Classification of Major vs. Minor Extensions 278 Exactly what is considered to be a major extension and what is 279 considered normal usage will depend on the specific protocol and the 280 proposed extension at issue. Even for protocols designed to carry 281 opaque data, whether a proposed usage qualifies as a major extension 282 may involve considerable debate. For example, RADIUS is designed to 283 carry AVPs and allow definition of new AVPs. But it is important 284 that such discussion involve the IETF community of experts 285 knowledgeable about the protocol's architecture and existing usage in 286 order to fully understand the implications of a proposed extension. 288 4. Review of Proposed Protocol Extensions 290 Major extensions to IETF protocols should be well, and publicly, 291 documented and reviewed by the IETF community to be sure that the 292 extension does not undermine basic assumptions and safeguards 293 designed into the protocol, such as security functions, or undermine 294 its architectural integrity. 296 5. Recommendation 298 The following principles are the main guiding principles concerning 299 extensions to IETF protocols: 301 o Extensibility features in IETF protocols should be limited to 302 providing just the amount of extensibility that is seen as 303 required. Protocols should not be extensible just for the sake 304 of being extensible. 306 o All major extensions to IETF protocols should be done with 307 adequate review by or direct involvement of the IETF. 309 o The decision on whether an extension is major or minor should be 310 done with the direct involvement of the IETF. 312 o Protocols should include IANA considerations section that ensure 313 that protocol code point assignments that are needed to deploy 314 extensions are not made until after a proposed extension has 315 received adequate review. 317 Ideally, extensions should be done by IETF working groups using 318 normal IETF processes or, if a working group does not consider a 319 proposed extension to be general enough, at least documented in an 320 IETF informational RFC that is reviewed by the working group and the 321 IESG. No individual, vendor, standards development organization or 322 forum should be able create what is viewed to be a major extension to 323 an IETF protocol on its own and be able to claim (or create the 324 appearance) that the extensions are part of the IETF protocol. 326 It should also be noted that the second bullet above leads to the 327 possibility of a denial-of-service issue, as it implies that any 328 major extension must be done within or reviewed by the IETF, and that 329 the IETF is required to take on all such work. In practice, the IETF 330 may not have the resources to develop (or even review) every possible 331 extension and will need to prioritize the use of its resources. Thus, 332 it is important to be pragmatic in terms of what work can and will be 333 taken on by the IETF, and to set expectations accordingly. In those 334 cases where the IETF is unable to take on a particular work item, it 335 should be understood that the IETF will review extensions to its 336 technology that it is asked to publish, and may approve publication 337 only after changes are made, or may not agree to publish the 338 extension at all. Thus, anyone proposing extensions outside of the 339 IETF is advised to coordinate any such extensions with the IETF as 340 early as possible. Waiting until the last minute before consulting 341 with the IETF and then assuming quick publication of a finished 342 extension is not recommended. 344 It should also be noted that there are limits to what the IETF can do 345 to prevent others from improperly extending protocols outside of the 346 IETF. The IETF's leverage is limited to such actions as recommending 347 against publication of an extension or denying the assignment of an 348 IANA code point (e.g., when relevant IANA considerations guidelines 349 apply). There is also the real possibility that the development of a 350 poor extension will generate ill-will in the IETF community, which 351 can greatly complicate subsequent attempts by the offending group to 352 carry out future work in the IETF, whether directly related to the 353 particular extension or not. 355 6. Summary 357 IETF protocols should not be designed to encourage the definition of 358 major extensions outside the IETF process. Documents defining IETF 359 protocols should carefully analyze and identify which protocol 360 components can be extended safely with minimal or no community review 361 and which need community review, and then write appropriate IANA 362 considerations sections that ensure the appropriate level of 363 community review prior to the assignment of numbers. For example, the 364 definition of additional data formats that can be carried may require 365 no review, while the addition of new protocol message types might 366 require a Standards Track action [IANA-CONSID]. 368 7. Examples 370 This section discusses some specific examples, as it is not always 371 immediately clear what constitutes a major extension. 373 [note: to be completed, are the following good and representative of 374 some of the debates that have been had?] 376 7.1. RADIUS Extensions 378 The RADIUS [RFC2865] protocol was designed to be extensible via 379 addition of Attributes to a Data Dictionary on the server, without 380 requiring code changes. However, this extensibility model assumed 381 that Attributes would conform to a limited set of data types and that 382 vendor extensionns would be limited to use by vendors in situations 383 in which interoperability was not required. Recent developments have 384 stretched those assumptions. 386 [RFC2865] Section 6.2 defines a mechanism for Vendor-Specific 387 extensions (Attribute 26), and states that use: 389 "... should be encouraged instead of allocation of global attribute 390 types, for functions specific only to one vendor's implementation of 391 RADIUS, where no interoperability is deemed useful." 393 However, in practice usage of Vendor-Specific Attributes (VSAs) has been 394 considerably broader than this; in particular, VSAs have been used by 395 SDOs to define their extensions to the RADIUS protocol. 397 This has caused a number of problems. Since the VSA mechanism was not 398 designed for interoperability, VSAs do not contain a "mandatory" bit. 399 As a result, RADIUS clients and servers may not know whether it is 400 safe to ignore unknown attributes. For example, [RFC2865] Section 5 401 states: 403 "A RADIUS server MAY ignore Attributes with an unknown Type. A 404 RADIUS client MAY ignore Attributes with an unknown Type." 406 However, in the case where the VSAs pertain to security (e.g. Filters) 407 it may not be safe to ignore them, since [RFC2865] also states: 409 "A NAS that does not implement a given service MUST NOT implement the 410 RADIUS attributes for that service. For example, a NAS that is 411 unable to offer ARAP service MUST NOT implement the RADIUS attributes 412 for ARAP. A NAS MUST treat a RADIUS access-accept authorizing an 413 unavailable service as an access-reject instead." 415 Since it was not envisaged that multi-vendor VSA implementations 416 would need to interoperate, [RFC2865] does not define the data model 417 for VSAs, and allows multiple subattributes to be included within a 418 single Attribute of type 26. However, this enables VSAs to be 419 defined which would not be supportable by current implementations if 420 placed within the standard RADIUS attribute space. This has caused 421 problems in standardizing widely deployed VSAs. 423 In addition to extending RADIUS by use of VSAs, SDOs have also 424 defined new values of the Service-Type attribute in order to create 425 new RADIUS commands. Since [RFC2865] defined Service-Type values as 426 being allocated First Come, First Served (FCFS), this essentially 427 enabled new RADIUS commands to be allocated without IETF review. 428 This oversight has since been fixed in [RFC3575]. 430 7.2. RSVP Extensions 432 7.3. L2TP Extensions 434 L2TP [L2TP] carries Attribute-Value Pairs (AVPs), with most AVPs 435 having no semantics to the L2TP protocol itself. However, it should 436 be noted that L2TP message types are identified by a Message Type AVP 437 (Attribute Type 0) with specific AVP values indicating the actual 438 message type. Thus, extensions relating to Message Type AVPs would 439 likely be considered major extensions. 441 L2TP also provides for Vendor-Specific AVPs. Because everything in 442 L2TP is encoded using AVPs, it would be easy to define vendor- 443 specific AVPs that would be considered major extensions. 445 L2TP also provides for a "mandatory" bit in AVPs. Recipients of L2TP 446 messages containing AVPs they do not understand but that have the 447 mandatory bit set, are expected to reject the message and terminate 448 the tunnel or session the message refers to. This leads to 449 interesting interoperability issues, because a sender can include a 450 vendor-specific AVP with the M-bit set, which then cause the 451 recipient to not interoperate with the sender. This sort of behavior 452 is counter to the IETF ideals, as implementations of the IETF 453 standard should interoperate successfully with other implementations 454 and not require the implementation of non-IETF extensions in order to 455 interoperate successfully. Section 4.2 of the L2TP specification 456 [L2TP] includes specific wording on this point, though there was 457 significant debate at the time as to whether such language was by 458 itself sufficient. 460 Fortunately, it does not appear that the above concerns have been a 461 problem in practice. At the time of this writing, the authors are 462 unaware of the existance of vendor-specific AVPs that also set the M- 463 bit. 465 8. IANA Considerations 467 None. 469 9. Security Considerations 471 Insufficiently reviewed extensions can easily lead to protocols with 472 significant security vulnerabilities. In addition, a poorly designed 473 extension can circumvent strong security features that the IETF 474 designed into a protocol. 476 10. Acknowledgments 478 The initial version of this document was put together by the IESG in 479 2002. Since then, it has been reworked in response to feedback from 480 John Loughney, Henrik Levkowetz, Mark Townsley, Randy Bush, Bernard 481 Aboba and others. 483 11. Informative References 485 [IANA-CONSID] Narten, T. and H. Alvestrand, "Guidelines for Writing 486 an IANA Considerations Section in RFCs", BCP 26, RFC 2434, 487 October 1998. 489 [L2TP] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. 490 and B. Peter, "Layer Two Tunneling Protocol (L2TP)", RFC 491 2661, August 1999. 492 [DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 493 March 1997. 495 [MIB-GUIDELINES] draft-ietf-ops-mib-review-guidelines-02.txt 497 [RFC3575] IANA Considerations for RADIUS (Remote Authentication Dial 498 In User Service). B. Aboba. July 2003. 500 [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 501 Authentication Dial In User Service (RADIUS)", RFC 2865, June 502 2000. 504 12. Editor's Addresses 506 Scott Bradner 507 Harvard University 508 29 Oxford St 509 Cambridge MA 02138 510 USA 512 Phone: +1 617-495-3864 513 EMail: sob@harvard.edu 515 Thomas Narten 516 IBM Corporation 517 P.O. Box 12195 518 Research Triangle Park, NC 27709-2195 519 USA 521 Phone: +1 919 254 7798 522 EMail: narten@us.ibm.com 524 Intellectual Property Statement 526 The IETF takes no position regarding the validity or scope of any 527 Intellectual Property Rights or other rights that might be claimed to 528 pertain to the implementation or use of the technology described in 529 this document or the extent to which any license under such rights 530 might or might not be available; nor does it represent that it has 531 made any independent effort to identify any such rights. Information 532 on the procedures with respect to rights in RFC documents can be 533 found in BCP 78 and BCP 79. 535 Copies of IPR disclosures made to the IETF Secretariat and any 536 assurances of licenses to be made available, or the result of an 537 attempt made to obtain a general license or permission for the use of 538 such proprietary rights by implementers or users of this 539 specification can be obtained from the IETF on-line IPR repository at 540 http://www.ietf.org/ipr. 542 The IETF invites any interested party to bring to its attention any 543 copyrights, patents or patent applications, or other proprietary 544 rights that may cover technology that may be required to implement 545 this standard. Please address the information to the IETF at ietf- 546 ipr@ietf.org. 548 Disclaimer of Validity 550 This document and the information contained herein are provided on an 551 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 552 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 553 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 554 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 555 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 556 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 558 Copyright Statement 560 Copyright (C) The Internet Society (2004). This document is subject 561 to the rights, licenses and restrictions contained in BCP 78, and 562 except as set forth therein, the authors retain all their rights.