idnits 2.17.1 draft-baset-sipping-p2preq-00.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 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 523. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 500. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 507. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 513. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No '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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. 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 (October 28, 2005) is 6754 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) == Outdated reference: A later version (-03) exists of draft-bryan-sipping-p2p-01 -- Possible downref: Normative reference to a draft: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' == Outdated reference: A later version (-02) exists of draft-johnston-sipping-p2p-ipcom-01 -- Possible downref: Normative reference to a draft: ref. '5' -- Possible downref: Normative reference to a draft: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' ** Obsolete normative reference: RFC 3489 (ref. '11') (Obsoleted by RFC 5389) -- Possible downref: Normative reference to a draft: ref. '12' -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '14' -- Possible downref: Non-RFC (?) normative reference: ref. '15' Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 19 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING WG S. Baset 3 Internet-Draft H. Schulzrinne 4 Expires: May 1, 2006 Columbia University 5 E. Shim 6 Panasonic 7 K. Dhara 8 Avaya Labs Research 9 October 28, 2005 11 Requirements for SIP-based Peer-to-Peer Internet Telephony 12 draft-baset-sipping-p2preq-00 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on May 1, 2006. 39 Copyright Notice 41 Copyright (C) The Internet Society (2005). 43 Abstract 45 This document defines requirements for designing peer-to-peer voice, 46 text, and real-time multimedia communication system protocols. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 52 3. Functional Scope . . . . . . . . . . . . . . . . . . . . . . . 6 53 4. High-level Requirements . . . . . . . . . . . . . . . . . . . 7 54 4.1. Resources for Distribution . . . . . . . . . . . . . . . . 7 55 4.2. Protocol Reuse . . . . . . . . . . . . . . . . . . . . . . 7 56 4.3. DHT Changeability . . . . . . . . . . . . . . . . . . . . 7 57 4.4. Small Overhead . . . . . . . . . . . . . . . . . . . . . . 7 58 4.5. NAT and Firewall Traversal . . . . . . . . . . . . . . . . 7 59 4.6. Voice Transport . . . . . . . . . . . . . . . . . . . . . 8 60 4.7. Deployment Scale . . . . . . . . . . . . . . . . . . . . . 8 61 5. Architectural Requirements . . . . . . . . . . . . . . . . . . 9 62 5.1. Scalability . . . . . . . . . . . . . . . . . . . . . . . 9 63 5.2. Reliability . . . . . . . . . . . . . . . . . . . . . . . 9 64 5.3. Namespace . . . . . . . . . . . . . . . . . . . . . . . . 9 65 5.4. Services/Resource Lookup . . . . . . . . . . . . . . . . . 9 66 5.4.1. Centralized Lookup . . . . . . . . . . . . . . . . . . 9 67 5.4.2. Distributed Lookup . . . . . . . . . . . . . . . . . . 9 68 5.5. Interconnect with P2P, non-P2P and PSTN networks . . . . . 10 69 6. Protocol Specification Requirements . . . . . . . . . . . . . 11 70 6.1. Support for different DHTs . . . . . . . . . . . . . . . . 11 71 6.2. Addressing for Heterogeneous Resources . . . . . . . . . . 11 72 7. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 12 73 7.1. Global Telephony Overlay . . . . . . . . . . . . . . . . . 12 74 7.2. Emergency, Ad-hoc . . . . . . . . . . . . . . . . . . . . 12 75 7.3. Office Environments, P2P-IP-PBX . . . . . . . . . . . . . 12 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 77 8.1. Identity . . . . . . . . . . . . . . . . . . . . . . . . . 13 78 8.2. Signaling and Media Anonymization . . . . . . . . . . . . 13 79 8.3. Misbehaving Peers . . . . . . . . . . . . . . . . . . . . 13 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 82 Intellectual Property and Copyright Statements . . . . . . . . . . 17 84 1. Introduction 86 This document has the objective of focusing on the requirements for 87 designing protocols for peer-to-peer voice, text, and real-time 88 multimedia communication systems. 90 Peer-to-peer (P2P) technologies enable large-scale overlay networks 91 of hosts for various applications such as file sharing, VoIP, 92 presence, instant messaging, content distribution, and collaboration. 93 In P2P-based systems, physical resources such as computing power, 94 storage space, and network bandwidth from participating hosts are 95 collectively used to support the application functions and centrally 96 managed severs do not exist or perform much less functions than in 97 traditional client server based systems. Hence, P2P-based systems 98 can have advantages of good scalability, reduced management and 99 deployment costs, and easy setup. 101 The traditional SIP [2] based VoIP systems employ SIP registrars, SIP 102 proxy servers, and STUN [11] and TURN [12] servers. SIP registrars 103 are used to locate the user contact information, SIP proxy servers 104 are used to route the calls, and STUN and TURN servers are used to 105 traverse NATs and firewalls. The SIP RFC does not mandate the use of 106 these servers; it specifically says that all servers in SIP are 107 optional. The deployment and maintenance of these servers can 108 constitute a significant cost for a SIP-based VoIP service provider. 110 Several peer-to-peer voice systems, such as Skype [13] and Nimcat 111 [14] have demonstrated the possibility of voice and IM services for 112 end users. Typically, these systems distribute the functionality of 113 location servers and NAT and firewall traversal servers to the end- 114 points. Each end-point or peer can potentially participate in the 115 routing decisions and spare its CPU and bandwidth for servicing other 116 peers in the network. Most of these systems assume a network of 117 peers that are similar in capabilities such as processing power, 118 memory, bandwidth, media mixing abilities. However, heterogeneous 119 peer-to-peer voice network do not operate on such assumptions and 120 hence require architectures that support communication among users 121 with a diverse set of end-points. 123 P2P-based SIP or P2P SIP will enable P2P VoIP and other multimedia 124 communications based on open standards. It was demonstrated by Bryan 125 [3] and Singh [4] that it is possible to build a P2P SIP network in 126 which the location service is distributed to the end-points. While 127 these two pioneering works take designs quite close to each other, a 128 different architecture was proposed by Matthews [6]. A distributed 129 location service for SIP was proposed by Johnston [5]. With various 130 design options and open issues, identifying requirements for P2P SIP 131 will facilitate making design choices. This document defines a set 132 of requirements for P2P-SIP. 134 2. Terminology 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in RFC 2119 [1]. 140 Terminology defined in RFC 3261 [2] is used without definition. 142 Distributed Hash Table (DHT): A mechanism in which resources are 143 given a unique key produced by hashing some attribute of the 144 resource, locating them in a hash space (see below). Nodes located 145 in this hash space also have a unique id within the hash space. 146 Nodes store information about resources with keys that are 147 numerically similar to the node's ID in the hash space. 149 Node or a Peer: Software running on a user machine that allows 150 sharing the machine's resources such as CPU cycles and bandwidth to 151 perform functions typically carried out by a centralized server for 152 its clients. In most simple terms, a peer is both a client and a 153 server. 155 Overlay or Overlay Network: This document refers to the virtual 156 network created by the interconnection between the nodes 157 participating in the P2P SIP network as the "overlay network", in 158 keeping with the terminology used in the P2P community. 160 Peer-to-Peer Service Provider: The organization that provides 161 services required to run a P2P network, for example, providing a 162 centralized authentication service, a centralized bootstrap service 163 or a centralized resource location service. 165 3. Functional Scope 167 P2P SIP SHOULD be able to support all or most of the applications and 168 services supported by the traditional SIP. The most important and 169 basic functionality of P2P SIP should be the support of real-time 170 communications such as basic voice services and video conferencing. 171 Additionally, P2P SIP should be flexible to accommodate non-real-time 172 communications like asynchronous messaging and presence. 174 4. High-level Requirements 176 4.1. Resources for Distribution 178 Location service, NAT and firewall traversal servers, voicemail, 179 address book, and configuration storage are examples of centralized 180 resources in a conventional VoIP deployment. A peer-to-peer system 181 SHOULD allow a generic mechanism for distributing these centralized 182 resources to the peers. 184 4.2. Protocol Reuse 186 Existing protocols such as SSL, TLS, and SIP SHOULD be reused as much 187 as possible such that their usage does not introduce a significant 188 overhead. 190 4.3. DHT Changeability 192 The protocol(s) for maintaining the peer-to-peer network SHOULD be 193 flexible to accommodate different DHT algorithms. 195 Motivation: There are many different algorithms for maintaining a DHT 196 such as Chord [7], CAN [8], and Pastry [9]. The research in DHT is 197 on going and it is possible that these algorithms can be improved or 198 new algorithms can be devised. Also, it cannot be assumed that one 199 DHT algorithm will fit for all deployments of various scale. Thus, 200 the protocol should be flexible to accommodate various DHT 201 algorithms. 203 4.4. Small Overhead 205 The overhead of the protocol SHOULD be minimal so that it can support 206 low capability devices. 208 Motivation: The protocol is envisioned to be run on low capability 209 mobile devices such as WiFi phones and wireless enabled cameras as 210 well as more resourceful devices. A protocol which has a large 211 overhead for P2P network maintenance can devour the device resources, 212 the most critical being the battery. 214 A better P2P algorithm might need fewer resources, so the ability of 215 a system to change the P2P algorithm actually helps low capability 216 devices. 218 4.5. NAT and Firewall Traversal 220 R1. The peer-to-peer system SHOULD distribute the functionality of 221 NAT and firewall traversal servers to the end-points. 223 Motivation: This is one of the main reasons for designing a peer-to- 224 peer IP telephony protocol. According to September 2005 press 225 release from Nielsen NetRatings [15], 60% of the US home Internet 226 users are using broadband. Many of these users are likely to use 227 some sort of NAT to setup a home network. An IP telephony system 228 supporting these kind of users must provide NAT and firewall 229 traversal servers and allocate sufficient bandwidth for them. A P2P 230 IP telephony system can save on the cost of maintaining these servers 231 and corresponding bandwidth by distributing the functionality of 232 these servers to the end-points. 234 R2. A peer with NAT and firewall traversal capabilities SHOULD be 235 selected such that it does not introduce significant delay between 236 the communicating peers. 238 Motivation: A peer in Australia should not act as a NAT traversal 239 server for two communicating voice peers in New York. 241 4.6. Voice Transport 243 The peers SHOULD support sending and receiving voice packets over TCP 244 in addition to UDP. 246 Motivation: The typical NAT configurations maintain the binding of a 247 TCP connection for its lifetime. Thus, packets sent over TCP 248 'seamlessly' traverse through NATs. The peers acting as NAT and 249 firewall traversal servers should be able to relay voice packets over 250 TCP between caller and callee. 252 4.7. Deployment Scale 254 The P2P system will be deployed in small offices and home networks 255 (SOHO), emergency and ad-hoc situations, and globally over the 256 Internet. The protocols SHOULD be flexible to cater for the varying 257 scale requirements of these networks. 259 5. Architectural Requirements 261 5.1. Scalability 263 The protocol SHOULD achieve an Internet wide scale. 265 Motivation: It is envisioned that a global VoIP overlay will be 266 deployed which will contain hundreds of thousands of nodes. The 267 protocol(s) should be scalable to support such a deployment. 269 5.2. Reliability 271 The system MUST continue to function as peers arrive, depart, and 272 fail. No assumptions should be made regarding peer uptime or their 273 capabilities. 275 Motivation: The peers will run on machines of end-users and it is 276 quite difficult to predict the reliability of those machines. The 277 system should allow reallocating the resources of a graceful or 278 ungraceful departing peer to existing peers in a seamless way. Time 279 interval for detection of failed peers should be adjustable based on 280 scale and other system requirements. 282 5.3. Namespace 284 The system SHOULD allow centralized and non-centralized naming 285 authorities. In the absence of any naming authority, the system MUST 286 be able to determine if two users pick up the same name and SHOULD be 287 able to decide which of them should be allowed to use the name. The 288 system SHOULD support both SIP and non-SIP naming (addressing) 289 schemes. 291 Motivation: A global overlay network will probably require a central 292 naming authority to maintain a unique namespace. A home network may 293 not need any central authority due to small number of devices. 295 5.4. Services/Resource Lookup 297 5.4.1. Centralized Lookup 299 Value-added services such as reliable voicemail storage can be 300 provided by a central authority in a P2P network. The system SHOULD 301 allow the peers to efficiently locate the centralized service 302 providers or resources. 304 5.4.2. Distributed Lookup 306 The peers should be able to perform distributed resource and service 307 lookup in an efficient manner. The number of peers to be contacted 308 SHOULD be minimal in such a lookup. 310 5.5. Interconnect with P2P, non-P2P and PSTN networks 312 The P2P system SHOULD be able to interconnect with other P2P or non- 313 P2P systems and PSTN networks. To provide this interconnection, the 314 P2P system should be able to discover these networks in a centralized 315 or in a distributed away. 317 6. Protocol Specification Requirements 319 6.1. Support for different DHTs 321 Any protocol specification SHOULD be able to incorporate different 322 DHT algorithms based on the P2P service provider requirements. 324 6.2. Addressing for Heterogeneous Resources 326 It is envisioned that more than one type of resources will be 327 distributed in the overlay network. Location service and NAT and 328 firewall traversal servers are examples of two such resources. The 329 protocol specification SHOULD have a flexible addressing scheme to 330 support distinct distributed resources and SHOULD allow new 331 distributed resources to be incorporated in an existing network. 333 7. Usage Scenarios 335 Below, some deployment scenarios for the P2P VoIP system are 336 described. 338 7.1. Global Telephony Overlay 340 A global P2P telephony VoIP system which allows its users located in 341 different regions and countries to communicate with each other. 343 7.2. Emergency, Ad-hoc 345 In emergency situations, communication links can break down, and many 346 of the servers such as DNS may not be reachable. An overlay 347 communication network can be established in that situation. Clearly, 348 the assumption is that some sort of underlying network infrastructure 349 available. 351 7.3. Office Environments, P2P-IP-PBX 353 A small office or an environment with a heterogeneous network 354 infrastructure are good candidates for P2P overlay network. Small 355 offices may not want to be bothered with maintaining yet another 356 server. Server-less P2P systems can help achieve this goal. 358 8. Security Considerations 360 8.1. Identity 362 A global overlay network will probably have more stringent 363 requirements for identity management and protection than a home based 364 network. The system should allow identities to be verified in a 365 reasonable way. Central naming and certificate authorities can 366 provide protection against identity theft. 368 Lack of central authority in a large overlay implies that the system 369 is susceptible to Sybil Attack [10]. 371 8.2. Signaling and Media Anonymization 373 Since a peer can route signaling messages between peers and can act 374 as a NAT or a firewall traversal server for the communicating 375 parties, it is imperative that the communication is encrypted. A 376 peer acting as a router or a NAT or a firewall traversal server 377 should not be able to listen to the communication. It is recommended 378 that the system should also support IP address and port anonymization 379 to the extent it does not significantly delay the real-time media 380 stream. 382 8.3. Misbehaving Peers 384 The system must not assume that all peers will behave correctly. The 385 system must recognize the existence of leachers and free-loaders, and 386 must provide a mechanism to detect and penalize them. 388 Motivation: Users do not like arbitrary traffic to flow across their 389 machines. Even if the user has agreed with the terms of service of 390 the P2P software, he or she may take active steps to block overlay 391 traffic. Misbehaved peers can choose to discard the routing requests 392 or route them incorrectly. Any such action by legitimate or 393 illegitimate users can hamper the operation of the P2P network. The 394 protocols must be designed with this perspective. 396 9. References 398 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 399 Levels", BCP 14, RFC 2119, March 1997. 401 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 402 Petersen, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 403 Session Initiation Protocol", RFC 3261, June 2002. 405 [3] Bryan, D. and C. Jennings, "A P2P Approach to SIP Registration 406 and Resource Location", draft-bryan-sipping-p2p-01 (work in 407 progress), July 2005. 409 [4] Singh, K. and H. Schulzrinne, "Peer-to-peer Internet Telephony 410 using SIP", Proceedings of the 2005 Network and Operating 411 Systems Support for Digital Audio and Video Workshop (NOSSDAV) 412 '05 , June 2005. 414 [5] Johnston, A., "SIP, P2P, and Internet Communications", 415 draft-johnston-sipping-p2p-ipcom-01 (work in progress), 416 March 2005. 418 [6] Matthews, P. and B. Poustchi, "Industrial-Strength P2P SIP", 419 draft-matthews-sipping-p2p-industrial-strength-00 (work in 420 progress), February 2005. 422 [7] Stoica, I., Morris, R., Liben-Nowell, D., Karger, D., Kaashoek, 423 M., Dabek, F., and H. Balakrishnan, "Chord: A Scalable Peer-to- 424 peer Lookup Service for Internet Applications", IEEE/ACM 425 Transactions on Networking (To Appear). 427 [8] Ratmasamy, S., Francis, P., Handley, M., Karp, R., and S. 428 Shenker, "A scalable content-addressable network", Proc. ACM 429 SIGCOMM (San Diego, CA), pp. 161-172, August 2001. 431 [9] Rowstron, A. and P. Druschel, "Pastry: Scalable, distributed 432 object location and routing for large-scale peer-to-peer 433 systems", Proceedings of the 18th IFIP/ACM International 434 Conference on Distributed Systems Platforms (Middleware 2001), 435 March 2002. 437 [10] Docuer, J., "The Sybil Attack", IPTPS '02 , March 2002. 439 [11] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN 440 - Simple Traversal of User Datagram Protocol (UDP) Through 441 Network Address Translators (NATs)", RFC 3489, March 2003. 443 [12] Rosenberg, J., Mahy, R., and C. Huitema, "TURN - Traversal 444 Using Relay NAT", draft-rosenberg-midcom-turn-08 (work in 445 progress), September 2005. 447 [13] "Skype. P2P Internet Telephony Application", 448 . 450 [14] "Nimcat Networks. P2P Solutions for Enterprise Telephony", 451 . 453 [15] "Nielsen Ratings Press Release", September 28 2005, 454 . 456 Authors' Addresses 458 Salman A. Baset 459 Dept. of Computer Science 460 Columbia University 461 1214 Amsterdam Avenue 462 New York, NY 10027 463 USA 465 Email: salman@cs.columbia.edu 467 Henning Schulzrinne 468 Dept. of Computer Science 469 Columbia University 470 1214 Amsterdam Avenue 471 New York, NY 10027 472 USA 474 Email: hgs@cs.columbia.edu 476 Eunsoo Shim 477 Panasonic Digital Networking Laboratory 478 Two Research Way, 3rd Floor 479 Princeton, NJ 08540 480 USA 482 Email: eunsoo@research.panasonic.com 484 Krishna Kishore Dhara 485 Avaya Labs Research 486 307 Middletown Lincroft Road 487 Lincroft, NJ 07738-1526 489 Email: dhara@avaya.com 491 Intellectual Property Statement 493 The IETF takes no position regarding the validity or scope of any 494 Intellectual Property Rights or other rights that might be claimed to 495 pertain to the implementation or use of the technology described in 496 this document or the extent to which any license under such rights 497 might or might not be available; nor does it represent that it has 498 made any independent effort to identify any such rights. Information 499 on the procedures with respect to rights in RFC documents can be 500 found in BCP 78 and BCP 79. 502 Copies of IPR disclosures made to the IETF Secretariat and any 503 assurances of licenses to be made available, or the result of an 504 attempt made to obtain a general license or permission for the use of 505 such proprietary rights by implementers or users of this 506 specification can be obtained from the IETF on-line IPR repository at 507 http://www.ietf.org/ipr. 509 The IETF invites any interested party to bring to its attention any 510 copyrights, patents or patent applications, or other proprietary 511 rights that may cover technology that may be required to implement 512 this standard. Please address the information to the IETF at 513 ietf-ipr@ietf.org. 515 Disclaimer of Validity 517 This document and the information contained herein are provided on an 518 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 519 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 520 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 521 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 522 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 523 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 525 Copyright Statement 527 Copyright (C) The Internet Society (2005). This document is subject 528 to the rights, licenses and restrictions contained in BCP 78, and 529 except as set forth therein, the authors retain all their rights. 531 Acknowledgment 533 Funding for the RFC Editor function is currently provided by the 534 Internet Society.