idnits 2.17.1 draft-ietf-sip-congestsafe-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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 Security Considerations section. 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 (Feb 12, 2003) is 7743 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) -- Looks like a reference, but probably isn't: 'RFC2119' on line 85 == Unused Reference: '1' is defined on line 464, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 467, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 470, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 477, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2223 (ref. '3') (Obsoleted by RFC 7322) ** Obsolete normative reference: RFC 3427 (ref. '5') (Obsoleted by RFC 5727) Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP -- Session Initiation Protocol D. Willis 3 Working Group B. Campbell 4 Internet-Draft dynamicsoft Inc. 5 Expires: August 13, 2003 Feb 12, 2003 7 Session Initiation Protocol Extension to Assure Congestion Safety 8 draft-ietf-sip-congestsafe-01 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at http:// 26 www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on August 13, 2003. 33 Copyright Notice 35 Copyright (C) The Internet Society (2003). All Rights Reserved. 37 Abstract 39 The Session Initiation Protocol allows the use of UDP for transport 40 of SIP messages. The use of UDP inherently risks network congestion 41 problems, as UDP itself does not define congestion prevention, 42 avoidance, detection, or correction mechanisms. This problem is 43 aggravated by large SIP messages which fragment at the UDP level. 44 Transport protocols in SIP are also negotiated on a per-hop basis, at 45 the SIP level, so SIP proxies may convert from TCP to UDP and so 46 forth. This document defines what it means for SIP nodes to be 47 congestion safe and specifies an extension by which a SIP User Agent 48 may require that its requests are treated in a congestion safe 49 manner. 51 Table of Contents 53 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Definition of Congestion Safety for SIP . . . . . . . . . . . 3 59 4. Assuring Transitive Congestion Safety with Proxy-Require . . . 4 61 5. Responsible use of SIP over UDP . . . . . . . . . . . . . . . 4 62 5.1 Requirements For Use of SIP Over UDP . . . . . . . . . . . . . 6 63 5.2 Pacing SIP Requests Over UDP . . . . . . . . . . . . . . . . . 6 64 5.3 Proxy Rejects Request That Would Require UDP Fragmentation . 7 65 5.4 Server Rejects Request Because Response Could Not Be Sent 66 Safely . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 6. Syntax of Extensions and Changes to SIP Specifications . . . . 9 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 72 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 74 Normative References . . . . . . . . . . . . . . . . . . . . . 11 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11 78 Intellectual Property and Copyright Statements . . . . . . . . 12 80 1. Terminology 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 84 document are to be interpreted as described in RFC 2119 [RFC2119]. 86 2. Background 88 The Session Initiation Protocol RFC 3261 [4] provides application 89 support over multiple transport protocols, including UDP and TCP. 90 Transport negotiation is not "end to end" with SIP. Instead, each 91 SIP hop individually determines which transport to use. For example, 92 a User Agent (UA) may use TCP to talk to a proxy, that proxy my use 93 UDP to talk to another proxy, and that second proxy may use SCTP to 94 talk to a destination UA. 96 UDP has inherent issues with congestion management. The protocol has 97 not explicit mechanisms for avoiding, detecting, or adapting to 98 network congestion. SIP attempts to deal with this in two ways: 99 1. Retransmission timers with exponential back offs. 100 2. Attempting to limit the size of transmissions over UDP to reduce 101 the effects of fragmentation. 103 This would appear to be an incomplete solution. One solution might 104 be to deprecate UDP entirely for SIP. However, there is a large 105 installed base using UDP, and there are legitimately places where UDP 106 appears to be quite useful such as tiny mobile phones and in 107 extremely high-volume proxies connecting over dedicated networks. 109 As an alternative, this draft: 110 1. Defines what it means for a SIP node to be "congestion-safe". 111 2. Defines a mechanism whereby a congestion-safe UA may require that 112 any proxy processing its requests be congestion safe. 113 3. Defines a mechanism whereby a proxy may reject a request that it 114 would be forced to fragment, and in so doing inform the 115 originating UA of relevant sizing parameters. 116 4. Defines a mechanism whereby a server may reject requests that 117 would result in responses that might not be transmitted 118 congestion-safely if the request itself was not received in a 119 congestion-safe manner. 121 3. Definition of Congestion Safety for SIP 123 A SIP node can be considered "congestion safe" if it never emits a 124 request or response in a manner not known to be congestion safe. 126 Requests may be considered congestion-safe if any one of the 127 following criteria is met: 129 1. The transport toward the next SIP hop is TCP, SCTP, or other 130 transport providing congestion control and the next hop is known 131 to be either a UA or a congestion-safe proxy. 132 2. The transport toward the next hop is UDP, the next hop is known 133 to be a UA or congestion-safe proxy, and the network between the 134 two is known to support congestion management at a lower layer. 135 Note that this is an uncomoon case in typical Internet 136 applications. 137 3. If the only available transport toward the next hop is UDP and 138 the next hop is known to be a UA or congestion-safe proxy, the 139 request MAY be transmitted over UDP or rejected by local policy. 140 If the request is transmitted over UDP, the procedures described 141 under the heading "Responsible use of SIP over UDP" in this 142 document MUST be followed. 144 Responses may be considered congestion-safe if any one of the 145 following criteria is met: 146 1. The request was congestion-safe, as defined above. 147 2. The response is no larger than the request. 149 The preceding uses the phrase "the next hop is known to be either a 150 UA or a congestion-safe proxy." Such knowledge may be derived either 151 through administrative configuration or through use of the 152 Proxy-Require mechanism defined herein under the heading "Assuring 153 Transitive Congestion Safety with Proxy-Require". 155 4. Assuring Transitive Congestion Safety with Proxy-Require 157 SIP provides a mechanism whereby a user agent making a request can be 158 assured that any proxy servicing that request support a specific 159 extension or set of behavior. To do so, the user agent includes a 160 "Proxy-Require" header field with a value indicating a tag for the 161 specific extension or behavior required. There is an IANA 162 registration process for these tags. As per [4], proxies not 163 recognizing a specific tag or unwilling to support the associated 164 behavior reject a request referencing that tag with a 420 response, 165 which has the semantic "Unsupported". 167 We herein define a tag value of "congestion-safe". A proxy 168 forwarding a request containing a Proxy-Require with this tag value 169 MUST manifest the property of congestion-safety as defined by this 170 document. 172 5. Responsible use of SIP over UDP 174 The fundamental problem with UDP is that it provides no feedback 175 mechanism to allow a sender to pace its transmissions against the 176 real performance of the network. While this tends to have no 177 significant effect on extremely low-volume sender-receiver pairs, the 178 impact of high-volume relationships on the network can be severe. 179 Consider the following scenario, wherein the traffic between multiple 180 UAs is funnelled through a single proxy-proxy relationship. 182 Example of large-fan out/fan-in likely to encounter congestion: 184 UA1----\ /----UA10 185 UA2-----\ /-----UA11 186 UA3------\ /------UA12 187 UA4-------\ /-------UA13 188 UA5--------P1------P2--------UA14 189 UA6-------/ \-------UA15 190 UA7------/ \------UA16 191 UA8-----/ \-----UA17 192 UA9----/ \----UA18 194 Figure 1 196 In this scenario, any requests from UA(1..9) to UA(10..18) traverse 197 the proxy-proxy link P1<-->P2. Assuming current SIP practices, if 198 this link is UDP and every UA emits a request simultaneously, each 199 proxy will insert nine (one for each UA) requests, resulting in 200 eighteen simultaneous requests on the P1<-->P2 link. Each request 201 may require retransmissions, and large requests may require 202 fragmentation to fit the link MTU -- at the worst case, producing 203 more than one hundred packets per request, or approximately 2,000 204 simultaneously expressed packets in this scenario. If the capacity 205 of link P1<-->P2 is inadequate to deliver these messages within the 206 SIP retransmission window, the originating UAs (or the proxies, if 207 acting in transaction-stateful mode) generate retransmissions, 208 further compounding the problem into a "retransmission storm". 209 Real-world scenarios may scale far more seriously. It is not 210 unreasonable to assume that there may be tens of thousands of UAs on 211 each side of the network. 213 Clearly the best thing to do is to use a more sophisticated transport 214 protocol (TCP, SCTP, etc.) between P1 and P2, and between each UA and 215 its associated proxy. If this is not feasible, it may be necessary 216 to fall back to UDP. 218 It should be noted that the fundamental problem not just between UAs 219 and proxies, but whenever there is a high fan-out or fan-in ratio. 220 If in the above example, each UA were behind a "residential proxy", 221 the problem would occur in similar fashion. 223 One might propose that SIP ALWAYS use a congestion-controlled 224 transport to talk to proxies, and only fall back to UDP when the next 225 hop is a UA. The primary problem with this approach is that in 226 general, a SIP node does not and cannot know whether the next node is 227 a UA or a proxy -- it is this ability to "insert" proxies into a 228 sequence that provides much of the flexibility of SIP. A secondary 229 problem is that even if the next hop is a UA, some UAs are 230 sufficienty high volume, and some links sufficiently narrow, that 231 congestion might still result from the incautious use of UDP. 233 5.1 Requirements For Use of SIP Over UDP 235 The previously described problems with the general use of SIP over 236 UDP lead to the following two requirements for the use of UDP as a 237 transport protocol for SIP: 238 1. Large messages MUST NOT be transmitted over UDP. The SIP 239 specification provides basic guidance for UAs. Congestion-safe 240 proxies MUST follow the procedures described below under the 241 heading "Proxy Rejects Request That Would Require UDP 242 Fragmentation." UAs MAY also make use of the MTU feedback 243 techniques in that section. 244 2. Nodes sending requests over UDP MUST pace those requests as 245 described under the heading "Pacing SIP requests over UDP." 247 Response messages SHOULD be constrained to be smaller than the MTUs 248 established for requests by the preceding mechanisms, and systems 249 implementors should remain aware that SIP provides limited support 250 for managing response sizes. Further experience may indicate a need 251 for further control over response handling. 253 5.2 Pacing SIP Requests Over UDP 255 One simple way to describe the congestion problem is that UDP lets us 256 send packets without knowing whether those packets are arriving. The 257 simplest approach to dealing with this at the application level is to 258 send a request, then wait for some sort of response indicating that 259 the request was received before sending anything else. This produces 260 an effect described by some as "ping-ponging" -- traffic bounces back 261 and forth between two nodes like a ping-pong ball or tennis ball in a 262 match. Since there's only one ball in play between any two players 263 at any given time, most of the potential for congestion cascades is 264 eliminated. 266 This pacing or serialization approach has the side-effect of 267 significantly reducing the maximum throughput, as transmission occurs 268 in only one direction at a time and there is at least a 2xRTT delay 269 between transmissions. More sophisticated algorithms such as those 270 in TCP and SCTP have been developed to address this, and it would be 271 inappropriate to duplicate that work here. Consequently, if greater 272 efficiency is required than that provided by this simple approach, 273 implementors should use TCP, SCTP, or another such protocol. But if 274 one absolutely must use UDP, this approach works, and is reasonably 275 efficient in the most likely application of "edge proxy" to UA and 276 other proxies with large fan-outs to individual low-volume nodes. 278 SIP has two sorts of request transactions: "invite" and "non-invite" 279 tranactions. Invite transaction use a three way sequence of 280 "request, response, acknowledgement" and may include a "provisional 281 response" between the request and response steps. Non-invite 282 transactions use a two-way "request, response" sequence, and may also 283 have a provisional response although that behavior has been 284 deprecated. 286 Congestion-safe use of SIP over UDP requires waiting for some sort of 287 response to a request (or a timeout, which has backoff properties) 288 before sending another request to that same destination. A 289 congestion-safe SIP node (UA or proxy) MUST NOT send a request to a 290 given next-hop if there is an existing request to that destination 291 which has not received some sort of response. The existing 292 transaction MUST either receive a response (final or provisional) or 293 time-out before a new request can be made to that next-hop. 295 This effectively requires congestion-safe proxies to act in a 296 transaction-stateful manner on a per-next-hop destination basis, at 297 least to the extent of tracking whether some sort of request is 298 pending to each next-hop and correlating provisional and final 299 responses to that request. 301 Some may argue that this puts an excessive burden onto the SIP node, 302 and that implementations that are "congestion-safe" per this 303 specification will have reduced performance when used with UDP over a 304 shared or public network. We counter that congestion-safe transport 305 protocols are readily available, and that network users which insist 306 on using unsafe transports (such as UDP) MUST be responsible for 307 assuring that they do not impede the function of other users of the 308 network, even at the expense of reducing their own efficiency. It is 309 simply irresponsible to "blast away" at the network without regard 310 for congestion or its impact on other users of the network. 312 5.3 Proxy Rejects Request That Would Require UDP Fragmentation 314 A proxy may be faced with a request to deliver a large message using 315 UDP as a transport. Fragmentation of such messages is problematic in 316 several ways. Loss of any fragment requires time-out and 317 retransmission of the message. The fragments are commonly 318 transmitted out the interface at local interface (usually LAN) rates, 319 without awareness of intervening network conditions. For these 320 reason, we believe it in general a bad practice to send large 321 requests over UDP. 323 While the actual MTU of a link may not be known, common practice 324 seems to indicate that the local interface MTU is likely to be a 325 reasonable approximation. Where the actual path MTU is known, that 326 value should be used instead. 328 When a congestion-safe SIP proxy processing a request determines that 329 the next hop is reached via UDP, and that the request is larger than 330 the effective MTU toward that hop and would consequently be 331 fragmented, the proxy MUST reject that request with a 513 response. 333 The base SIP specification provides minimal guidance on dealing with 334 oversized requests. There is an error response code, 513, with the 335 semantic "request too large" that seems applicable. However, SIP 336 provides no guidance on how to indicate what size might be allowed. 337 We define here two extension header fields that may be used in a 513 338 response to indicate by the rejecting proxy the size of message 339 allowed by that proxy. The extension header field "Proxy-Max-Size" 340 may be used to indicate the largest allowable request to the 341 originating UA. The extension header field "Proxy-Seen-Size" may be 342 used to indicate the size of the rejected request as calculated by 343 the rejecting proxy. In both cases, the size value used indicates 344 the SIP message size, which does not include IP or transport protocol 345 overhead. 347 A congestion-safe SIP proxy which rejects a request based on size 348 SHOULD include a "Proxy-Max-Size" header field with a value 349 indicating the largest size message allowed by this proxy on this 350 link. If a Proxy-Max-Size header field is sent, the proxy MUST also 351 include a "Proxy-Seen-Size" header indicating the size of the request 352 as seen at this proxy. 354 A UA receiving a 513 response has the options of giving up, trying a 355 smaller request, or trying a different set of proxies. Should it 356 choose to try a smaller request, it may estimate the size of the 357 largest message that can be sent by taking the original request size, 358 subtracting it from the value of the Proxy-Seen-Size header field, 359 and subtracting that result from the value of the Proxy-max-Size 360 header field. Note that a UA SHOULD NOT repeatedly downsize and 361 retry a request. This technique is not an adequate replacement for 362 TCP's Path MTU Discovery. Any request that has been rejected more 363 than once with a 513 SHOULD either be abandoned or re-issued over 364 congestion-safe channels. 366 5.4 Server Rejects Request Because Response Could Not Be Sent Safely 368 A server receiving a SIP request generates a resposne to that 369 request. Delivery of this response may raise issues of 370 congestion-safety. Because SIP requires that responses traverse 371 exactly the reverse of the route taken by the request (recorded in 372 the Via: header fields values), the server has no options about 373 routing the response. If the request was delivered in a 374 congestion-safe manner, it can be safely assumed that the response 375 will also be returned in a congestion-safe manner, as it must 376 traverse exactly this recorded route. However, if the request was 377 NOT received in a congestion-safe manner, the server cannot negotiate 378 a congestion-safe path for the response, as the response must follow 379 the path of the request. 381 If the size of the generated response is less than the size of the 382 received request, it may be reasonably assumed that since the request 383 arrived intact, a response of equal or smaller size is likely to 384 traverse the reverse of that path succesfully. However, no such 385 assumptions can be made about responses that are larger than the 386 corresponding request. 388 When a congestion-safe server generates a response to a request that 389 is larger than the request and that request was not received over a 390 congestion-safe channel, it cannot be assumed that the response can 391 be safely transmitted. An unsafe response cannot be transmitted by a 392 congestion-safe server. Instead the server MUST reject the request 393 and return an error response using response code 514, which has the 394 semantic of "Response Could Not Be Sent Safely". 396 A UA receiving a 514 response to a request may either retry the 397 request in a congestion-safe manner or abandon the request. 399 6. Syntax of Extensions and Changes to SIP Specifications 401 The syntax for the Proxy-Max-Size header field is: 403 Proxy-Max-Size = "Proxy-Max-Size" HCOLON 1*DIGIT 405 The syntax for the Proxy-Seen-Size header field is: 407 Proxy-Seen-Size = "Proxy-Seen-Size" HCOLON 1*DIGIT 409 7. IANA Considerations 411 This document defines the SIP extension header fields 412 "Proxy-Max-Size" and "Proxy-Seen-Size" ", which IANA will add to the 413 registry of SIP header fields defined in [4]. 415 This document also defines the SIP option tag "congestion-safe" which 416 IANA will add to the registry of SIP option tags defined in [4]. 418 This document also defines the SIP response code 514, with the 419 semantic "Response Cannot Be Sent Safely" which IANA will add to the 420 registry of SIP response codes defined in [4] in the section for 5xx 421 clase response codes. 423 The following is the registration for the Proxy-Max-Size header 424 field: 426 RFC Number: RFCXXXX [Note to IANA: Fill in with the RFC number of 427 this specification.] 429 Header Field Name: Proxy-Max-Size 431 Compact Form: none 433 The following is the registration for the Proxy-Seen-Size header 434 field: 436 RFC Number: RFCXXXX [Note to IANA: Fill in with the RFC number of 437 this specification.] 439 Header Field Name: Proxy-Seen-Size 441 Compact Form: none 443 The following is the registration for the congestion-safe option tag: 445 RFC Number: RFCXXXX [Note to IANA: Fill in with the RFC number of 446 this specification.] 448 Option Tag: congestion-safe 450 The following is the registration for the SIP response code 514: 452 RFC Number: RFCXXXX [Note to IANA: Fill in with the RFC number of 453 this specification.] 455 Response Code: 514 Response Cannot Be Sent Safely 457 8. Acknowledgements 459 Robert Sparks and Jonathan Rosenberg argued with us vociferously over 460 this topic and contributed substantial insight. 462 Normative References 464 [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 465 9, RFC 2026, October 1996. 467 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 468 Levels", BCP 14, RFC 2119, March 1997. 470 [3] Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC 471 2223, October 1997. 473 [4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 474 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 475 Session Initiation Protocol", RFC 3261, June 2002. 477 [5] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J. and B. 478 Rosen, "Change Process for the Session Initiation Protocol 479 (SIP)", BCP 67, RFC 3427, December 2002. 481 Authors' Addresses 483 Dean Willis 484 dynamicsoft Inc. 485 5100 Tennyson Parkway 486 Suite 1200 487 Plano, TX 75028 488 US 490 Phone: +1 972 473 5455 491 EMail: dean.willis@softarmor.com 492 URI: http://www.dynamicsoft.com/ 494 Ben Campbell 495 dynamicsoft Inc. 496 5100 Tennyson Parkway 497 Suite 1200 498 Plano, TX 75028 499 US 501 Phone: +1 972 473 5452 502 EMail: bcampbell@dynamicsoft.com 503 URI: http://www.dynamicsoft.com/ 505 Intellectual Property Statement 507 The IETF takes no position regarding the validity or scope of any 508 intellectual property or other rights that might be claimed to 509 pertain to the implementation or use of the technology described in 510 this document or the extent to which any license under such rights 511 might or might not be available; neither does it represent that it 512 has made any effort to identify any such rights. Information on the 513 IETF's procedures with respect to rights in standards-track and 514 standards-related documentation can be found in BCP-11. Copies of 515 claims of rights made available for publication and any assurances of 516 licenses to be made available, or the result of an attempt made to 517 obtain a general license or permission for the use of such 518 proprietary rights by implementors or users of this specification can 519 be obtained from the IETF Secretariat. 521 The IETF invites any interested party to bring to its attention any 522 copyrights, patents or patent applications, or other proprietary 523 rights which may cover technology that may be required to practice 524 this standard. Please address the information to the IETF Executive 525 Director. 527 Full Copyright Statement 529 Copyright (C) The Internet Society (2003). All Rights Reserved. 531 This document and translations of it may be copied and furnished to 532 others, and derivative works that comment on or otherwise explain it 533 or assist in its implementation may be prepared, copied, published 534 and distributed, in whole or in part, without restriction of any 535 kind, provided that the above copyright notice and this paragraph are 536 included on all such copies and derivative works. However, this 537 document itself may not be modified in any way, such as by removing 538 the copyright notice or references to the Internet Society or other 539 Internet organizations, except as needed for the purpose of 540 developing Internet standards in which case the procedures for 541 copyrights defined in the Internet Standards process must be 542 followed, or as required to translate it into languages other than 543 English. 545 The limited permissions granted above are perpetual and will not be 546 revoked by the Internet Society or its successors or assignees. 548 This document and the information contained herein is provided on an 549 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 550 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 551 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 552 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 553 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 555 Acknowledgement 557 Funding for the RFC Editor function is currently provided by the 558 Internet Society.