idnits 2.17.1 draft-ietf-tsvwg-cc-alt-04.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 14. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 561. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 537. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 544. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 550. 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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. 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 (June 2007) is 6122 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 2581 (Obsoleted by RFC 5681) ** Obsolete normative reference: RFC 2960 (Obsoleted by RFC 4960) == Outdated reference: A later version (-11) exists of draft-irtf-tmrg-metrics-07 -- Obsolete informational reference (is this intentional?): RFC 2988 (Obsoleted by RFC 6298) == Outdated reference: A later version (-05) exists of draft-irtf-tmrg-tools-03 Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force S. Floyd 2 Internet-Draft M. Allman 3 Intended status: Best Current Practice ICIR / ICSI 4 Expires: December 2007 June 2007 6 Specifying New Congestion Control Algorithms 7 draft-ietf-tsvwg-cc-alt-04.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as 24 reference material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Copyright Notice 34 Copyright (C) The IETF Trust (2007). 36 Abstract 38 The IETF's standard congestion control schemes have been widely 39 shown to be inadequate for various environments (e.g., high-speed 40 networks). Recent research has yielded many alternate congestion 41 control schemes that significantly differ from the IETF's congestion 42 control principles. Using these new congestion control schemes in 43 the global Internet has possible ramifications to both the traffic 44 using the new congestion control and to traffic using the currently 45 standardized congestion control. Therefore, the IETF must proceed 46 with caution when dealing with alternate congestion control 47 proposals. The goal of this document is to provide guidance for 48 considering alternate congestion control algorithms within the IETF. 50 TO BE DELETED BY THE RFC EDITOR UPON PUBLICATION: 52 Changes from draft-ietf-tsvwg-cc-alt-03.txt: 54 * Minor rewordings in response to IESG review. 56 Changes from draft-ietf-tsvwg-cc-alt-02.txt: 58 * Removed references from abstract. 60 * Added a note that we are focused on documents produced within the 61 IETF (i.e., these are not guidelines that the IRTF or the RFC 62 Editor would necessarily have to follow). 64 * Added a list of 'difficult environments' the IETF has thought 65 about in the past (even while admitting that an exhaustive list of 66 'difficult environments' is impossible to produce). 68 * Removed section 5 (conclusions). Some felt that it was redundant 69 and not needed. 71 * Made a few of the references normative. 73 * Various small wording tweaks. 75 Changes from draft-ietf-tsvwg-cc-alt-01.txt: 77 * Very minor wording tweaks gathered during WGLC. 79 Changes from draft-ietf-tsvwg-cc-alt-00.txt: 81 * Added text to the introduction to clarify the relationship of this 82 document and RFC 2914. In addition, added a requirement (0) in 83 section 3 that says new congestion control schemes that 84 significantly diverge from the principles in RFC 2914 must explain 85 this divergence. 87 Changes from draft-floyd-tsvwg-cc-alt-00.txt: 89 * Changed the name to draft-ietf-tsvwg-cc-alt-00.txt. 91 * Added a sentence about robustness with various 92 queueing algorithms in the routers, especially both RED 93 and DropTail. Suggestion from Jitendra Padhye. 95 * Added a sentence about robustness with the routers, 96 middleboxes, and such deployed in the current Internet. 97 Concern taken from a talk by Henry Sanders. 99 * Add a section about minimum requirements necessary for 100 approval for deployment in the global Internet. 101 Suggestion by Jitendra Padhye. 103 * Added more examples to guideline 3 about difficult environments, 104 and added that TCP performance in difficult environments is 105 still an active research topic. Suggestion from Doug Leith. 107 * Added citations to examples of discussions of these issues 108 in Experimental RFCs 3649 and 4782. 110 * Added examples of high speed TCP proposals. Suggestion 111 from Bob Braden. 113 * Changed the fairness bullets to better reflect that new congestion 114 controllers are expected to assess the impact to standard 115 congestion controlled flows---without commenting on how that 116 assessment should be done. From discussions with bob Briscoe. 118 * Made numerous editing changes suggested by Gorry Fairhurst. 120 Changes from draft-floyd-cc-alt-00.txt: 122 * Changed the name to draft-floyd-tsvwg-cc-alt-00.txt. 124 * Added a bullet about incremental deployment. Feedback from 125 Colin Perkins 127 * Clarified the fairness section; this section is not saying 128 that strict TCP-friendliness is a requirement. 130 * Clarified that as an alternative to Full Backoff, a flow 131 could stop sending when the packet drop rate is above a 132 certain threshold. 134 * Clarified that the Full Backoff bullet does not require 135 that different flows with different round-trip times 136 use the same criteria about when they should back off 137 to one packet per round-trip time or less. 139 * Added a paragraph about Informational RFCs. 141 * Added a bullet about response to transient events, including 142 routing events or moving from a private to a shared network. 144 END OF NOTES TO BE DELETED. 146 1. Introduction 148 This document provides guidelines for the IETF to use when 149 evaluating suggested congestion control algorithms that 150 significantly differ from the general congestion control principles 151 outlined in [RFC2914]. The guidance is intended to be useful to 152 authors proposing alternate congestion control and for the IETF 153 community when evaluating whether a proposal is appropriate for 154 publication in the RFC series. 156 The guidelines in this document are intended to be consistent with 157 the congestion control principles from [RFC2914] of preventing 158 congestion collapse, considering fairness, and optimizing the flow's 159 own performance in terms of throughput, delay, and loss. [RFC2914] 160 also discusses the goal of avoiding a congestion control `arms race' 161 among competing transport protocols. 163 This document does not give hard-and-fast requirements for an 164 appropriate congestion control scheme. Rather, the document 165 provides a set of criteria that should be considered and weighed by 166 the IETF in the context of each proposal. The high-order criteria 167 for any new proposal is that a serious scientific study of the pros 168 and cons of the proposal needs to have been done such that the IETF 169 has a well rounded set of information to consider. 171 After initial studies, we encourage authors to write a specification 172 of their proposals for publication in the RFC series to allow others 173 to concretely understand and investigate the wealth of proposals in 174 this space. 176 2. Document Status 178 Following the lead of HighSpeed TCP [RFC3649], alternate congestion 179 control algorithms are expected to be published as "Experimental" 180 RFCs until such time that the community better understands the 181 solution space. Traditionally, the meaning of "Experimental" status 182 has varied in its use and interpretation. As part of this document 183 we define two classes of congestion control proposals that can be 184 published with the "Experimental" status. The first class includes 185 algorithms that are judged to be safe to deploy for best-effort 186 traffic in the global Internet and further investigated in that 187 environment. The second class includes algorithms that, while 188 promising, are not deemed safe enough for widespread deployment as 189 best-effort traffic on the Internet, but are being specified to 190 facilitate investigations in simulation, testbeds, or controlled 191 environments. The second class can also include algorithms where 192 the IETF does not yet have sufficient understanding to decide if the 193 algorithm is or is not safe for deployment on the Internet. 195 Each alternate congestion control algorithm published is required to 196 include a statement in the abstract indicating whether or not the 197 proposal is considered safe for use on the Internet. Each alternate 198 congestion control algorithm published is also required to include a 199 statement in the abstract describing environments where the protocol 200 is not recommended for deployment. There may be environments where 201 the protocol is deemed *safe* for use, but still is not 202 *recommended* for use because it does not perform well for the user. 204 As examples of such statements, [RFC3649] specifying HighSpeed TCP 205 includes a statement in the abstract stating that the proposal is 206 Experimental, but may be deployed in the current Internet. In 207 contrast, the Quick-Start document [RFC4782] includes a paragraph in 208 the abstract stating the the mechanism is only being proposed for 209 controlled environments. The abstract specifies environments where 210 the Quick-Start request could give false positives (and therefore 211 would be unsafe to deploy). The abstract also specifies 212 environments where packets containing the Quick-Start request could 213 be dropped in the network; in such an environment, Quick-Start would 214 not be unsafe to deploy, but deployment would still not be 215 recommended because it could cause unnecessary delays for the 216 connections attempting to use Quick-Start. 218 For authors of alternate congestion control schemes who are not 219 ready to bring their congestion control mechanisms to the IETF for 220 standardization (either as Experimental or as Proposed Standard), 221 one possibility would be to submit an internet-draft that documents 222 the alternate congestion control mechanism for the benefit of the 223 IETF and IRTF communities. This is particularly encouraged in order 224 to get algorithm specifications widely disseminated to facilitate 225 further research. Such an internet-draft could be submitted to be 226 considered as an Informational RFC, as a first step in the process 227 towards standardization. Such a document would also be expected to 228 carry an explicit warning against using the scheme in the global 229 Internet. 231 Note: we are not changing RFC publication process for non-IETF 232 produced documents (e.g., those from the IRTF or independent 233 RFC-Editor submissions). However, we would hope the guidelines in 234 this document inform the IESG as they consider whether to add a note 235 to such documents. 237 3. Guidelines 239 As noted above, authors are expected to do a well-rounded evaluation 240 of the pros and cons of proposals brought to the IETF. The 241 following are guidelines to help authors and the IETF community. 242 Concerns that fall outside the scope of these guidelines are 243 certainly possible; these guidelines should not be considered as an 244 all-encompassing check-list. 246 (0) Differences with Congestion Control Principles [RFC2914] 248 Proposed congestion control mechanisms should include a clear 249 explanation of the deviations from [RFC2914]. 251 (1) Impact on Standard TCP, SCTP [RFC2960], and DCCP [RFC4340]. 253 Proposed congestion control mechanisms should be evaluated when 254 competing with standard IETF congestion control 255 [RFC2581,RFC2960,RFC4340]. Alternate congestion controllers 256 that have a significantly negative impact on traffic using 257 standard congestion control may be suspect and this aspect 258 should be part of the community's decision making with regards 259 to the suitability of the alternate congestion control 260 mechanism. 262 We note that this bullet is not a requirement for strict 263 TCP-friendliness as a prerequisite for an alternate congestion 264 control mechanism to advance to Experimental. As an example, 265 HighSpeed TCP is a congestion control mechanism that is 266 Experimental, but that is not TCP-friendly in all environments. 267 We also note that this guideline does not constrain the fairness 268 offered for non-best-effort traffic. 270 As an example from an Experimental RFC, fairness with standard 271 TCP is discussed in Sections 4 and 6 of [RFC3649] (HighSpeed 272 TCP) and using spare capacity is discussed in Sections 6, 11.1, 273 and 12 of [RFC3649]. 275 (2) Difficult Environments. 277 The proposed algorithms should be assessed in difficult 278 environments such as paths containing wireless links. 279 Characteristics of wireless environments are discussed in 280 [RFC3819] and in Section 16 of [Tools]. Other difficult 281 environments can include those with multipath routing within a 282 connection. We note that there is still much to be desired in 283 terms of the performance of TCP in some of these difficult 284 environments. For congestion control mechanisms with explicit 285 feedback from routers, difficult environments can include paths 286 with non-IP queues at layer-two, IP tunnels, and the like. A 287 minimum goal for experimental mechanisms proposed for widespread 288 deployment in the Internet should be that they do not perform 289 significantly worse than TCP in these environments. 291 While it is impossible to enumerate all possible "difficult 292 environments", we note that the IETF has previously grappled 293 with paths with long delays [RFC2488], high delay bandwidth 294 products [RFC3649], high packet corruption rates [RFC3155], 295 packet reordering [RFC4653] and significantly slow links 296 [RFC3150]. Aspects of alternate congestion control that impact 297 networks with these characteristics should be detailed. 299 As an example from an Experimental RFC, performance in difficult 300 environments is discussed in Sections 6, 9.2, and 10.2 of 301 [RFC4782] (Quick-Start). 303 (3) Investigating a Range of Environments. 305 Similar to the last criteria, proposed alternate congestion 306 controllers should be assessed in a range of environments. For 307 instance, proposals should be investigated across a range of 308 bandwidths, round-trip times, levels of traffic on the reverse 309 path, and levels of statistical multiplexing at the congested 310 link. Similarly, proposals should be investigated for robust 311 performance with different queueing mechanisms in the routers, 312 especially Random Early Detection (RED) [FJ03] and Drop-Tail. 313 This evaluation is often not included in the internet-draft 314 itself, but in related papers cited in the draft. 316 A particularly important aspect of evaluating a proposal for 317 standardization is in understanding where the algorithm breaks 318 down. Therefore, particular attention should be paid to 319 characterizing the areas where the proposed mechanism does not 320 perform well. 322 As an example from an Experimental RFC, performance in a range 323 of environments is discussed in Section 12 of [RFC3649] 324 (HighSpeed TCP) and Section 9.7 of [RFC4782] (Quick-Start). 326 (4) Protection Against Congestion Collapse. 328 The alternate congestion control mechanism should either stop 329 sending when the packet drop rate exceeds some threshold 330 [RFC3714], or should include some notion of "full backoff". For 331 "full backoff", at some point the algorithm would reduce the 332 sending rate to one packet per round-trip time and then 333 exponentially backoff the time between single packet 334 transmissions if congestion persists. Exactly when either "full 335 backoff" or a pause in sending comes into play will be 336 algorithm-specific. However, as discussed in [RFC2914], this 337 requirement is crucial to protect the network in times of 338 extreme congestion. 340 If "full backoff" is used, this bullet does not require that the 341 full backoff mechanism must be identical to that of TCP 342 [RFC2988]. As an example, this bullet does not preclude full 343 backoff mechanisms that would give flows with different 344 round-trip times comparable bandwidth during backoff. 346 (5) Fairness within the Alternate Congestion Control Algorithm. 348 In environments with multiple competing flows all using the same 349 alternate congestion control algorithm, the proposal should 350 explore how bandwidth is shared among the competing flows. 352 (6) Performance with Misbehaving Nodes and Outside Attackers. 354 The proposal should explore how the alternate congestion control 355 mechanism performs with misbehaving senders, receivers, or 356 routers. In addition, the proposal should explore how the 357 alternate congestion control mechanism performs with outside 358 attackers. This can be particularly important for congestion 359 control mechanisms that involve explicit feedback from routers 360 along the path. 362 As an example from an Experimental RFC, performance with 363 misbehaving nodes and outside attackers is discussed in Sections 364 9.4, 9.5, and 9.6 of [RFC4782] (Quick-Start). This includes 365 discussion of misbehaving senders and receivers; collusion 366 between misbehaving routers; misbehaving middleboxes; and the 367 potential use of Quick-Start to attack routers or to tie up 368 available Quick-Start bandwidth. 370 (7) Responses to Sudden or Transient Events. 372 The proposal should consider how the alternate congestion 373 control mechanism would perform in the presence of transient 374 events such as sudden congestion, a routing change, or a 375 mobility event. Routing changes, link disconnections, 376 intermittent link connectivity, and mobility are discussed in 377 more detail in Section 17 of [Tools]. 379 As an example from an Experimental RFC, response to transient 380 events is discussed in Section 9.2 of [RFC4782] (Quick-Start). 382 (8) Incremental Deployment. 384 The proposal should discuss whether the alternate congestion 385 control mechanism allows for incremental deployment in the 386 targeted environment. For a mechanism targeted for deployment 387 in the current Internet, it would be helpful for the proposal to 388 discuss what is known (if anything) about the correct operation 389 of the mechanism with some of the equipment installed in the 390 current Internet, e.g., routers, transparent proxies, WAN 391 optimizers, intrusion detection systems, home routers, and the 392 like. 394 As a similar concern, if the alternate congestion control 395 mechanism is intended only for specific environments (and not 396 the global Internet), the proposal should consider how this 397 intention is to be carried out. The community will have to 398 address the question of whether the scope can be enforced by 399 simply stating the restrictions or whether additional protocol 400 mechanisms are required to enforce the scoping. The answer will 401 necessarily depend on the change being proposed. 403 As an example from an Experimental RFC, deployment issues are 404 discussed in Sections 10.3 and 10.4 of [RFC4782] (Quick-Start). 406 4. Minimum Requirements 408 This section suggests minimum requirements for a document to be 409 approved as Experimental with approval for widespread deployment in 410 the global Internet. 412 The minimum requirements for approval for widespread deployment in 413 the global Internet include the following guidelines (1) on 414 assessing the impact on standard congestion control, (3) on 415 investigation of the proposed mechanism in a range of environments, 416 guideline (4) on protection against congestion collapse and 417 guideline (8), discussing whether the mechanism allows for 418 incremental deployment. 420 For other guidelines, i.e., (2), (5), (6), and (7), the author must 421 perform the suggested evaluations and provide recommended analysis. 422 Evidence that the proposed mechanism has significantly more problems 423 than those of TCP should be a cause for concern in approval for 424 widespread deployment in the global Internet. 426 5. Security Considerations 428 This document does not represent a change to any aspect of the 429 TCP/IP protocol suite and therefore does not directly impact 430 Internet security. The implementation of various facets of the 431 Internet's current congestion control algorithms do have security 432 implications (e.g., as outlined in [RFC2581]). Alternate congestion 433 control schemes should be mindful of such pitfalls, as well, and 434 should examine any potential security issues that may arise. 436 6. IANA Considerations 438 This document does not require any IANA action. 440 Acknowledgments 442 Discussions with Lars Eggert and Aaron Falk seeded this document. 443 Thanks to Bob Briscoe, Gorry Fairhurst, Doug Leith, Jitendra Padhye, 444 Colin Perkins, Pekka Savola, members of TSVWG, and participants at 445 the TCP Workshop at Microsoft Research for feedback and 446 contributions. This document also draws from [Metrics]. 448 Normative References 450 [RFC2581] M. Allman, V. Paxson, and W. Stevens, TCP Congestion 451 Control, RFC 2581, Proposed Standard, April 1999. 453 [RFC2914] S. Floyd, Congestion Control Principles, RFC 2914, Best 454 Current Practice, September 2000. 456 [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., 457 Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., 458 and V. Paxson, Stream Control Transmission Protocol, RFC 2960, 459 October 2000. 461 [RFC4340] Kohler, E., Handley, M., and S. Floyd, Datagram 462 Congestion Control Protocol (DCCP), RFC 4340, March 2006. 464 Informative References 466 [FJ03] Floyd, S., and Jacobson, V., Random Early Detection 467 Gateways for Congestion Avoidance, IEEE/ACM Transactions on 468 Networking, V.1 N.4, August 1993. 470 [Metrics] S. Floyd, Metrics for the Evaluation of Congestion 471 Control Mechanisms. Internet-draft draft-irtf-tmrg-metrics-07, 472 work in progress, February 2007. 474 [RFC2488] M. Allman, D. Glover, and L. Sanchez. Enhancing TCP Over 475 Satellite Channels using Standard Mechanisms. RFC 2488. January 476 1999. 478 [RFC2988] Vern Paxson, Mark Allman. Computing TCP's Retransmission 479 Timer, November 2000. RFC 2988. 481 [RFC3150] S. Dawkins, G. Montenegro, M . Kojo, V. Magret, End-to-end 482 Performance Implications of Slow Links, RFC 3150, July 2001. 484 [RFC3155] S. Dawkins, G. Montenegro, M. Kojo, V. Magret, N. Vaidya, 485 End-to-end Performance Implications of Links with Errors, RFC 3155, 486 August 2001. 488 [RFC3649] S. Floyd, HighSpeed TCP for Large Congestion Windows, 489 RFC 3649, September 2003. 491 [RFC3714] S. Floyd and J. Kempf, IAB Concerns Regarding Congestion 492 Control for Voice Traffic in the Internet, RFC 3714, March 2004. 494 [RFC3819] P. Karn, C. Bormann, G. Fairhurst, D. Grossman, R. Ludwig, 495 J. Mahdavi, G. Montenegro, J. Touch, and L. Wood, Advice for Internet 496 Subnetwork Designers, RFC 3819, July 2004 498 [RFC4653] Sumitha Bhandarkar, A. L. Narasimha Reddy, Mark Allman, 499 Ethan Blanton, Improving the Robustness of TCP to Non-Congestion 500 Events, RFC 4653, August 2006. 502 [RFC4782] S. Floyd, M. Allman, A. Jain, and P. Sarolahti, 503 Quick-Start for TCP and IP. RFC 4782, Experimental, January 504 2007. 506 [Tools] S. Floyd and E. Kohler, Tools for the Evaluation of 507 Simulation and Testbed Scenarios, Internet-draft 508 draft-irtf-tmrg-tools-03.txt, work in progress, December 2006. 510 Authors' Addresses 512 Sally Floyd 513 ICIR (ICSI Center for Internet Research) 514 1947 Center Street, Suite 600 515 Berkeley, CA 94704-1198 516 Phone: +1 (510) 666-2989 517 Email: floyd at icir.org 518 URL: http://www.icir.org/floyd/ 520 Mark Allman 521 ICSI Center for Internet Research 522 1947 Center Street, Suite 600 523 Berkeley, CA 94704-1198 524 Phone: (440) 235-1792 525 Email: mallman at icir.org 526 URL: http://www.icir.org/mallman/ 528 Intellectual Property Statement 530 The IETF takes no position regarding the validity or scope of any 531 Intellectual Property Rights or other rights that might be claimed 532 to pertain to the implementation or use of the technology described 533 in this document or the extent to which any license under such 534 rights might or might not be available; nor does it represent that 535 it has made any independent effort to identify any such rights. 536 Information on the procedures with respect to rights in RFC 537 documents can be found in BCP 78 and BCP 79. 539 Copies of IPR disclosures made to the IETF Secretariat and any 540 assurances of licenses to be made available, or the result of an 541 attempt made to obtain a general license or permission for the use 542 of such proprietary rights by implementers or users of this 543 specification can be obtained from the IETF on-line IPR repository 544 at http://www.ietf.org/ipr. 546 The IETF invites any interested party to bring to its attention any 547 copyrights, patents or patent applications, or other proprietary 548 rights that may cover technology that may be required to implement 549 this standard. Please address the information to the IETF at 550 ietf-ipr@ietf.org. 552 Disclaimer of Validity 554 This document and the information contained herein are provided on 555 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 556 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 557 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 558 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 559 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 560 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 561 FOR A PARTICULAR PURPOSE. 563 Copyright Statement 565 Copyright (C) The IETF Trust (2007). This document is subject 566 to the rights, licenses and restrictions contained in BCP 78, and 567 except as set forth therein, the authors retain all their rights. 569 Acknowledgment 571 Funding for the RFC Editor function is currently provided by the 572 Internet Society.