idnits 2.17.1 draft-jurski-pppext-iphc-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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 571. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 549. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 555. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 4 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC3544]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (March 2007) is 6252 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC1144' is defined on line 455, but no explicit reference was found in the text == Unused Reference: 'RFC2472' is defined on line 464, but no explicit reference was found in the text == Unused Reference: 'RFC3241' is defined on line 474, but no explicit reference was found in the text == Unused Reference: 'RFC2434' is defined on line 490, but no explicit reference was found in the text == Unused Reference: 'RFC2686' is defined on line 494, but no explicit reference was found in the text == Unused Reference: 'RFC3550' is defined on line 497, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2472 (Obsoleted by RFC 5072, RFC 5172) -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) Summary: 4 errors (**), 0 flaws (~~), 8 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Jurski 3 Internet Draft Gdansk University of Technology 4 Document: draft-jurski-pppext-iphc-02.txt March 2007 5 Expires: September 2007 6 Category: Informational 8 Limited IP Header Compression over PPP 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on September, 1 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 The negotiation options specified in RFC 2509 defined an 42 all-or-nothing strategy for applying header compression: peers were 43 assumed to support compression for any combination of headers. 44 [RFC3544] refined that strategy to make it possible to negotiate 45 header compression for only TCP or only non-TCP packets (and also 46 added Enhanced RTP-Compression negotiation option). The current 47 document further refines the strategy by also making it possible to 48 negotiate header compression for only particular combinations of 49 headers or header types. 51 Conventions used in this document 53 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 54 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 55 document are to be interpreted as described in [RFC2119]. 57 Table of Contents 59 1. Introduction...................................................3 60 2. Configuration Suboptions to Disable Particular Header 61 Compression Types..............................................4 62 2.1 Limitations for Differential TCP Compression..............5 63 2.2 Limitations for non-differential TCP Compression..........7 64 2.3 Limitations for non-TCP Compression.......................9 65 3. Changes from Previous RFCs....................................11 66 4. Motivation....................................................11 67 5. References....................................................12 68 5.1 Normative References.....................................12 69 5.2 Informative References...................................13 70 6. IANA Considerations...........................................13 71 7. Security Considerations.......................................13 72 Acknowledgments..................................................13 73 Author's Address.................................................14 74 Intellectual Property Statement..................................14 75 Full Copyright Statement.........................................14 77 1. Introduction 79 The IP Header Compression (IPHC) defined in [RFC2507] may be used for 80 compression of both IPv4 and IPv6 datagrams or packets encapsulated 81 with multiple IP headers. IPHC is also capable of compressing both 82 TCP and UDP transport protocol headers. The IP/UDP/RTP header 83 compression defined in [RFC2508] and [RFC3545] fits within the 84 framework defined by IPHC so that it may also be applied to both IPv4 85 and IPv6 packets. 87 In order to establish compression of IP datagrams sent over a PPP 88 link, each end of the link must agree on a set of configuration 89 parameters for the compression. The process of negotiating link 90 parameters for network layer protocols is handled in PPP by a family 91 of network control protocols (NCPs). Configuration options to be 92 used to negotiate parameters for the compression scheme are described 93 in [RFC3544] (and RFC 2509). 95 According to [RFC3544] and RFC 2509, all combinations of headers are 96 compressed and decompressed. Therefore, it is not possible to 97 disable compression for a particular header type or a combination of 98 headers. For example, even nodes that only support IPv4 had to 99 support IPv6 header compression because it is impossible to specify 100 that IPv6 headers shall not be compressed. 102 This document adds three new suboptions to the IP header compression 103 configuration option defined in [RFC3544] (and RFC 2509). By using 104 these new suboptions, the decompressor can request that the use of 105 compression for particular header types or combinations of headers in 106 the datagram is disabled. For example, a node that only supports 107 IPv4 can request to not receive compressed IPv6 headers (such headers 108 will be sent by the compressor without the use of header 109 compression). These suboptions can also be used by the compressor to 110 tell the decompressor that some header types or header combinations 111 will not be compressed. 113 2. Configuration Suboptions to Disable Particular Header Compression 114 Types 116 [RFC3544] in section 2.1 specifies the IPCP IP-Compression-Protocol 117 option and several suboptions for this option. This document adds 118 three new suboptions: type 4, 5, and 6. 120 The new suboptions are added to make it possible for a decompressor 121 to specify which particular types of headers or their combinations 122 MUST NOT be compressed by a compressor. Separate sets of limitations 123 are defined in the following subsections for differential TCP, non- 124 differential TCP, and non-TCP compression methods. 126 NOTE: [RFC1332] is not explicit about whether the negotiation options 127 negotiate the capabilities of the receiver or of the sender. In 128 keeping with current practice, it is assumed that the suboptions 129 describe the capabilities of the decompressor (receiving side), 130 which sends the Configure-Request message. On the other hand, 131 options included in Configure-Nak messages are a suggestion of the 132 compressor (sending side). 134 Note that flag A of suboption 4 and flag B of suboption 5 overlap 135 with suboption 3 with parameter 1 (see section 2.4 in [RFC3544] for 136 the description of suboption 3). For this reason, in order to avoid 137 a suboptimal NCP negotiation exchange, peers SHOULD use suboption 3 138 with parameter 1 to completely disable TCP compression, instead of 139 setting both flags A and B in suboption 4 and 5. Accordingly, peers 140 implementing suboptions 4 and 5 SHALL also understand suboption 3. 142 NOTE: The compression limitations specified in these suboptions 143 should be used with care. Indiscriminate use of these limitations 144 may lead to suboptimal compression, or even no compression. 145 General purpose systems SHOULD normally request no limitation and 146 use the full compression functionality defined in RFC 2509 or 147 [RFC3544]. The decompressor MAY be configured to request limited 148 compression only when advantages and disadvantages of such a 149 decision are carefully examined, including scenarios when the 150 compressor may not fully support all combinations of flags 151 specified in these suboptions. Although new implementations of 152 the compressor are expected to support these suboptions, there are 153 many older systems that do not support them. The decompressor 154 SHOULD agree on the full RFC 2509 or [RFC3544] compression if it 155 receives a request from an older peer (compressor). 157 2.1 Limitations for Differential TCP Compression 159 This suboption, when included in the suboptions field of the 160 configuration option defined in section 2.1 in [RFC3544], defines 161 limitations that apply for the differential encoding compression 162 method only. 164 Description 166 Disable differential TCP header compression for a particular 167 compression method(s), header type(s), or header combination(s). 169 0 1 2 3 170 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | Type | Length |A B C D E F G| Reserved | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 Type 176 4 178 Length 179 = 4 181 Flags (ABCDEFG) 183 This field is a set of bit-flags that specify limitations. A flag 184 set refers to a particular limitation: 186 A: TCP differential encoding method shall not be used at all 187 ([RFC2507], Section 7.12.1); if this flag is set, the 188 remaining flags are irrelevant (MUST be set to zero by the 189 sender and ignored by the receiver) 191 B: Unused � MUST be set to zero by the sender and ignored by 192 the receiver 194 C: IPv4 header can be compressed only if it is the first header 195 in the compression chain (i.e. tunneled IPv4 headers are not 196 compressed and break the compression chain of headers); if 197 this flag is set for IPv6 Control Protocol, IPv4 header 198 compression is completely disabled (see Section 3 in 199 [RFC3544] for explanation) 201 D: IPv6 base header can be compressed only if it is the first 202 header in the compression chain (i.e. tunneled IPv6 headers 203 are not compressed and break the compression chain of 204 headers); if this flag is set for IP Control Protocol, IPv6 205 header compression is completely disabled (see Section 3 in 206 [RFC3544] for explanation) 208 E: IPv4 header for a fragment or with options shall not be 209 compressed ([RFC2507], Section 7.13, point b); this flag is 210 irrelevant if IPv4 header compression is completely disabled 212 F: IPv6 extension headers shall not be compressed ([RFC2507], 213 Sections from 7.1 to 7.10); this flag is irrelevant if IPv6 214 header compression is completely disabled 216 G: minimal encapsulation header shall not be compressed 217 ([RFC2507], Section 7.14) 219 Reserved 221 MUST be set to zero by the sender and ignored by the receiver. 223 This suboption SHOULD NOT be included in an NCP message if suboption 224 3 with parameter 1 is included (see section 2.4 in [RFC3544] for the 225 description of suboption 3). 227 If this suboption is included multiple times, the sum of all the 228 limitations applies (logical-or on all flags). 230 2.2 Limitations for non-differential TCP Compression 232 This suboption, when included in the suboptions field of the 233 configuration option defined in section 2.1 in [RFC3544], defines 234 limitations that apply for the non-differential encoding compression 235 method only. 237 Description 239 Disable non-differential TCP header compression for a particular 240 compression method(s), header type(s), or header combination(s). 242 0 1 2 3 243 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | Type | Length |A B C D E F G| Reserved | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 Type 249 5 251 Length 252 = 4 254 Flags (ABCDEFG) 256 This field is a set of bit-flags that specify limitations. A flag 257 set refers to a particular limitation: 259 A: Unused � MUST be set to zero by the sender and ignored by 260 the receiver 262 B: TCP non-differential encoding method shall not be used 263 ([RFC2507], Section 7.12.2); if this flag is set, the 264 remaining flags are irrelevant (MUST be set to zero by the 265 sender and ignored by the receiver) 267 C: IPv4 header can be compressed only if it is the first header 268 in the compression chain (i.e. tunneled IPv4 headers are not 269 compressed and break the compression chain of headers); if 270 this flag is set for IPv6 Control Protocol, IPv4 header 271 compression is completely disabled (see Section 3 in 272 [RFC3544] for explanation) 274 D: IPv6 base header can be compressed only if it is the first 275 header in the compression chain (i.e. tunneled IPv6 headers 276 are not compressed and break the compression chain of 277 headers); if this flag is set for IP Control Protocol, IPv6 278 header compression is completely disabled (see Section 3 in 279 [RFC3544] for explanation) 281 E: IPv4 header for a fragment or with options shall not be 282 compressed ([RFC2507], Section 7.13, point b); this flag is 283 irrelevant if IPv4 header compression is completely disabled 285 F: IPv6 extension headers shall not be compressed ([RFC2507], 286 Sections from 7.1 to 7.10); this flag is irrelevant if IPv6 287 header compression is completely disabled 289 G: minimal encapsulation header shall not be compressed 290 ([RFC2507], Section 7.14) 292 Reserved 294 MUST be set to zero by the sender and ignored by the receiver. 296 This suboption SHOULD NOT be included in an NCP message if suboption 297 3 with parameter 1 is included (see section 2.4 in [RFC3544] for the 298 description of suboption 3). 300 If this suboption is included multiple times, the sum of all the 301 limitations applies (logical-or on all flags). 303 2.3 Limitations for non-TCP Compression 305 This suboption, when included in the suboptions field of the 306 configuration option defined in section 2.1 in [RFC3544], defines 307 limitations that apply for the non-TCP compression method only. 309 Description 311 Disable non-TCP header compression for a particular compression 312 method(s), header type(s), or header combination(s). 314 0 1 2 3 315 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | Type | Length |A B C D E F G H I J K| Reserved| 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 Type 321 6 323 Length 324 = 4 326 Flags (ABCDEFGHIJK) 328 This field is a set of bit-flags that specify limitations. A flag 329 set refers to a particular limitation: 331 A: Unused � MUST be set to zero by the sender and ignored by 332 the receiver 334 B: Unused � MUST be set to zero by the sender and ignored by 335 the receiver 337 C: IPv4 header can be compressed only if it is the first header 338 in the compression chain (i.e. tunneled IPv4 headers are not 339 compressed and break the compression chain of headers); if 340 this flag is set for IPv6 Control Protocol, IPv4 header 341 compression is completely disabled (see Section 3 in 342 [RFC3544] for explanation) 344 D: IPv6 base header can be compressed only if it is the first 345 header in the compression chain (i.e. tunneled IPv6 headers 346 are not compressed and break the compression chain of 347 headers); if this flag is set for IP Control Protocol, IPv6 348 header compression is completely disabled (see Section 3 in 349 [RFC3544] for explanation) 351 E: IPv4 header for a fragment or with options shall not be 352 compressed ([RFC2507], Section 7.13, point b); this flag is 353 irrelevant if IPv4 header compression is completely disabled 355 F: IPv6 extension headers shall not be compressed ([RFC2507], 356 Sections from 7.1 to 7.10); this flag is irrelevant if IPv6 357 header compression is completely disabled 359 G: minimal encapsulation header shall not be compressed 360 ([RFC2507], Section 7.14) 362 H: UDP headers with non-zero UDP checksum shall not be 363 compressed ([RFC2507], Section 7.11); note that the checksum 364 cannot be zero with IPv6 366 I: the compressed chain of headers must include a compressed 367 UDP or a compressed RTP header; if the compressible chain 368 of headers does not include a UDP or RTP header, the whole 369 chain cannot be compressed 371 J: the compressed chain of headers must include a compressed 372 RTP header; if the compressible chain of headers does not 373 include a RTP header, the whole chain cannot be compressed; 374 this flag is irrelevant if flag I is set; this flag MUST be 375 set to zero by the sender and ignored by the receiver if RTP 376 compression is not enabled (with use of suboption 1 or 2 as 377 specified in Section 2.2 or 2.3, respectively) 379 K: RTP headers with non-empty CSRC list shall not be compressed 380 ([RFC2508], Section 3.3.2); this flag MUST be set to zero 381 by the sender and ignored by the receiver if RTP compression 382 is not enabled 384 Reserved 386 MUST be set to zero by the sender and ignored by the receiver. 388 This suboption SHOULD NOT be included in an NCP message if suboption 389 3 with parameter 2 is included (see section 2.4 in [RFC3544] for the 390 description of suboption 3). 392 If this suboption is included multiple times, the sum of all the 393 limitations applies (logical-or on all flags). 395 3. Changes from Previous RFCs 397 This document defines new suboptions for Header Compression 398 negotiation. These suboptions are only an addition to [RFC3544] (and 399 RFC 2509) and the content of [RFC3544] is not obsoleted. 401 The new suboptions defined in this document modify the stopping 402 criteria specified in [RFC2507] in Section 7. This can be considered 403 as adding a new subpoint "c)" to the list in the first paragraph of 404 Section 7 in [RFC2507]. This new subpoint would specify that the 405 compressible chain of headers would be additionally limited by the 406 new suboptions. 408 4. Motivation 410 It may be desirable to limit the compression mechanisms in specific 411 situations, so that not all types or combinations of headers are 412 compressed and decompressed. Similarly, it may be desirable that the 413 compressor is able to inform the decompressor that some types or 414 combinations of headers will not be compressed. This document makes 415 it possible. 417 Two reasons for using these limitations are listed here as examples: 419 - limited compression method may be useful to control the natural 420 trade-off between compression efficiency and system resource 421 usage (such as link capacity, processing power, and memory) 423 - using the non-differential compression method only may be 424 beneficial when packet re-ordering or high error rate are 425 expected on the link 427 While the compressor could use heuristics to determine the most 428 efficient way to compress flows, the decompressor may be in a much 429 better position to know the expected traffic type, resource 430 limitations, and usage conditions. Since there is no way of making 431 dynamic adjustments in the negotiated values for IPHC protocol, the 432 negotiation suboptions specified in this document may be useful. 434 Proposed extensions make the protocol more flexible and suitable in 435 more various usage scenarios, so they may also be beneficial for 436 other reasons. For example, with a predefined amount of memory, one 437 can provide a limited compression to 1000 users instead of supporting 438 full compression for only 500 users. 440 However, a request for these new suboptions might also cause 441 inefficient use of the available link capacity. Especially because 442 many compressors do not support these new suboptions and may not 443 support them in the future. Therefore, the decompressor shall 444 request limited compression with care. And for this reason, the new 445 suboptions are designed backward-compatible, so that peers that do 446 not support the new suboptions can interoperate with peers that 447 support them by using the full functionality defined in RFC 2509 or 448 [RFC3544]. The best solution for general purpose equipment, such as 449 Internet routers, is compression with no limitations. 451 5. References 453 5.1 Normative References 455 [RFC1144] Jacobson, V., "Compressing TCP/IP Headers for low-speed 456 serial links", RFC 1144, February 1990. 458 [RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol 459 (IPCP)", RFC 1332, May 1992. 461 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 462 Requirement Levels", BCP 14, RFC 2119, March 1997. 464 [RFC2472] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 465 2472, December 1998. 467 [RFC2507] Degermark, M., Nordgren, B. and S. Pink, "Header 468 Compression for IP", RFC 2507, February 1999. 470 [RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP 471 Headers for Low-Speed Serial Links", RFC 2508, February 472 1999. 474 [RFC3241] Bormann, C., "Robust Header Compression (ROHC) over PPP", 475 RFC 3241, April 2002. 477 [RFC3544] Koren, T., Casner, S., Bormann, C., "IP Header 478 Compression over PPP", RFC 3544, July 2003. 480 [RFC3545] Koren, T., Casner, S., Geevarghese, J., Thompson, B. and 481 P. Ruddy, "Enhanced Compressed RTP (CRTP) for Links with 482 High Delay, Packet Loss and Reordering", RFC 3545, July 483 2003. 485 5.2 Informative References 487 [RFC1661] Simpson, W., Ed., "The Point-To-Point Protocol (PPP)", 488 STD 51, RFC 1661, July 1994. 490 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 491 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 492 October 1998. 494 [RFC2686] Bormann, C., "The Multi-Class Extension to Multi-Link 495 PPP", RFC 2686, September 1999. 497 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R. and V. 498 Jacobson, "RTP: A Transport Protocol for Real-Time 499 Applications", RFC 3550, July 2003. 501 6. IANA Considerations 503 Three new assignments in existing IANA registry titled "IP Header 504 Compression Configuration Option Suboption Types" are needed for the 505 suboption types defined in this document. 507 7. Security Considerations 509 Negotiation of the suboptions defined here imposes no additional 510 security considerations beyond those that otherwise apply to PPP 511 [RFC1661]. 513 Acknowledgments 515 The author would like to thank particularly to Piotr Uminski for his 516 contribution to this document and to James Carlson, Carsten Bormann, 517 and Stephen L. Casner for their critical comments regarding the new 518 suboptions. 520 Mathias Engan, Stephen L. Casner, Carsten Bormann, and Tmima Koren 521 are the authors of RFC 2509 and [RFC3544] documents, on which this 522 document is based. 524 Author's Address 526 Janusz Jurski 527 Gdansk University of Technology 528 ul. Narutowicza 11/12 529 80-952 Gdansk 530 Poland 531 Email: jjurski@eti.pg.gda.pl 533 Intellectual Property Statement 535 The IETF takes no position regarding the validity or scope of any 536 Intellectual Property Rights or other rights that might be claimed to 537 pertain to the implementation or use of the technology described in 538 this document or the extent to which any license under such rights 539 might or might not be available; nor does it represent that it has 540 made any independent effort to identify any such rights. Information 541 on the ISOC's procedures with respect to rights in ISOC Documents can 542 be found in BCP 78 and BCP 79. 544 Copies of IPR disclosures made to the IETF Secretariat and any 545 assurances of licenses to be made available, or the result of an 546 attempt made to obtain a general license or permission for the use of 547 such proprietary rights by implementers or users of this 548 specification can be obtained from the IETF on-line IPR repository at 549 http://www.ietf.org/ipr. 551 The IETF invites any interested party to bring to its attention any 552 copyrights, patents or patent applications, or other proprietary 553 rights that may cover technology that may be required to implement 554 this standard. Please address the information to the IETF at 555 ietf-ipr@ietf.org. 557 Full Copyright Statement 559 Copyright (C) The IETF Trust (2007). 561 This document is subject to the rights, licenses and restrictions 562 contained in BCP 78, and except as set forth therein, the authors 563 retain all their rights. 565 This document and the information contained herein are provided on an 566 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 567 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 568 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 569 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 570 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 571 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.