idnits 2.17.1 draft-willis-p2psip-concepts-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 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1074. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1085. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1092. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1098. ** 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 issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 10 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 12, 2006) is 6407 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 1738 (ref. '2') (Obsoleted by RFC 4248, RFC 4266) == Outdated reference: A later version (-03) exists of draft-bryan-sipping-p2p-02 == Outdated reference: A later version (-01) exists of draft-irtf-p2prg-survey-search-00 == Outdated reference: A later version (-16) exists of draft-ietf-behave-turn-02 == Outdated reference: A later version (-20) exists of draft-ietf-sip-outbound-04 Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING Working Group D. Willis, Ed. 3 Internet-Draft Cisco Systems 4 Intended status: Experimental D. Bryan 5 Expires: April 15, 2007 SIPeerior Technologies and William 6 & Mary 7 P. Matthews 8 Avaya 9 E. Shim 10 Panasonic Digital Networking 11 Laboratory 12 October 12, 2006 14 Concepts and Terminology for Peer to Peer SIP 15 draft-willis-p2psip-concepts-02 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on April 15, 2007. 42 Copyright Notice 44 Copyright (C) The Internet Society (2006). 46 Abstract 48 This document defines concepts and terminology for use of the Session 49 Initiation Protocol in a peer-to-peer environment where the 50 traditional proxy-registrar function is replaced by a distributed 51 mechanism that might be implemented using a distributed hash table or 52 other distributed data mechanism with similar external properties. 53 This document includes a high-level view of the functional 54 relationships between the network elements defined herein, a 55 conceptual model of operations, and an outline of the related open 56 problems that might be addressed by an IETF working group. 58 Requirements Language 60 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 61 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 62 document are to be interpreted as described in [1]. 64 Table of Contents 66 1. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 3.1. What Kinds of P2PSIP Peers and Clients Might Exist? . . . 10 72 3.2. Reference Model . . . . . . . . . . . . . . . . . . . . . 10 73 3.3. Example Signalling Message Flows . . . . . . . . . . . . . 13 74 3.3.1. P2PSIP Peer contacts P2PSIP Peer . . . . . . . . . . . 13 75 3.3.2. P2PSIP Client contacts P2PSIP Peer . . . . . . . . . . 14 76 3.3.3. Conventional SIP Device using a Proxy Peer . . . . . . 15 77 3.3.4. Conventional SIP Device Using a Redirect Peer . . . . 16 78 3.4. Conceptual Outline of Operations . . . . . . . . . . . . . 18 79 3.4.1. Enrolling and Inserting an P2PSIP Peer . . . . . . . . 18 80 3.4.2. More on The Difference Between a Peer, Client, and 81 User Agent . . . . . . . . . . . . . . . . . . . . . . 18 82 3.4.3. Enrolling a User and Inserting a P2PSIP User Agent . . 19 83 3.4.4. Bootstrapping . . . . . . . . . . . . . . . . . . . . 19 85 4. Questions . . . . . . . . . . . . . . . . . . . . . . . . . . 20 86 4.1. PP2PSIP Peer Protocol . . . . . . . . . . . . . . . . . . 20 87 4.2. P2PSIP Client Protocol . . . . . . . . . . . . . . . . . . 20 88 4.3. How To Find Media Relays? . . . . . . . . . . . . . . . . 20 89 4.4. How Do We Find Gateways? . . . . . . . . . . . . . . . . . 21 90 4.5. Peer-Adjacency Through NATs . . . . . . . . . . . . . . . 21 91 4.6. Cryptotransparency . . . . . . . . . . . . . . . . . . . . 21 92 4.7. Record Formats . . . . . . . . . . . . . . . . . . . . . . 21 93 4.8. Peer and Client Enrollment Protocols . . . . . . . . . . . 21 94 4.9. Peer and User Credentials . . . . . . . . . . . . . . . . 21 95 4.10. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 21 96 4.11. Credential Recovery . . . . . . . . . . . . . . . . . . . 22 97 4.12. Overlapping Domains . . . . . . . . . . . . . . . . . . . 22 98 4.13. Hybrid Domains . . . . . . . . . . . . . . . . . . . . . . 22 99 4.14. Admissions Control . . . . . . . . . . . . . . . . . . . . 22 100 4.15. Users versus Resources . . . . . . . . . . . . . . . . . . 22 102 5. Security Considerations . . . . . . . . . . . . . . . . . . . 23 104 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 106 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 108 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 109 8.1. Normative References . . . . . . . . . . . . . . . . . . . 23 110 8.2. Informative References . . . . . . . . . . . . . . . . . . 24 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 113 Intellectual Property and Copyright Statements . . . . . . . . . . 26 115 1. Background 117 One of the fundamental problems in multimedia communications between 118 Internet nodes is that of a discovering the IP address at which a 119 given correspondent can be reached. Correspondents are frequently 120 identified by distinguished names, perhaps represented in the form of 121 a universal resource indicator (URI) [2]. 123 The Session Initiation Protocol (SIP) [3] commonly addresses this 124 task assuming that the domain part of the URI indicates an internet 125 host address or internet domain name using the Domain Name System 126 (DNS) [4]. SIP's location process [5] assumes that host part of the 127 URI indicates either the target SIP user agent (UA), or a proxy that 128 has knowledge of how to to reach the target UA, presumably gained 129 through SIP's registration process. 131 This approach, referred to herein as "Conventional SIP" or "Client/ 132 Server SIP", assumes a relatively fixed hierarchy of SIP routing 133 proxies (servers) and SIP user agents (clients). The routing proxies 134 are typically resolvable using conventional Internet mechanisms with 135 static IP addresses and associated DNS entries. This structure may 136 not be ideal in all cases, including specifically ad-hoc, serverless, 137 and reduced-administration scenarios. As an alternative, several 138 authors [7] [8] [9] [10] have proposed using peer-to-peer (P2P) [11] 139 approaches to solving the correspondent discovery problem. The 140 motivations for a P2P approach in SIP have been documented in [12]. 142 This document offers a consolidation of the more important terms and 143 concepts from several of the above documents, presented in the 144 context of a reference model for peer-to-peer SIP (P2PSIP). It is 145 intended that this document serve as a starting point for describing 146 the work needed to resolve a number of open questions such that an 147 IETF working group could be chartered to do the work needed to 148 resolve these questions and present a standard solution. The authors 149 believe that this goal is roughly consistent with that of a Protocol 150 Model as defined in [13]. 152 2. Definitions 154 We provide a list of terms used, as well as alternate forms that have 155 been used for these in drafts or discussions. In general, the 156 thought is to use the primary suggested form for clarity -- we have 157 included the other forms for simplicity and to provide a "mapping" to 158 existing drafts. Defined terms include: 160 Overlay Network: An overlay network is a computer network which is 161 built on top of another network. Nodes in the overlay can be 162 thought of as being connected by virtual or logical links, each of 163 which corresponds to a path, perhaps through many physical links, 164 in the underlying network. For example, many peer-to-peer 165 networks are overlay networks because they run on top of the 166 Internet. Dial-up Internet is an overlay upon the telephone 167 network. 169 P2P Network: A peer-to-peer (or P2P) computer network is a network 170 that relies primarily on the computing power and bandwidth of the 171 participants in the network rather than concentrating it in a 172 relatively low number of servers. P2P networks are typically used 173 for connecting nodes via largely ad hoc connections. Such 174 networks are useful for many purposes. Sharing content files (see 175 file sharing [16]) containing audio, video, data or anything in 176 digital format is very common, and realtime data, such as 177 telephony traffic, is also passed using P2P technology. 178 . A P2P Network may 179 also be called a "P2P Overlay" or "P2P Overlay Network" or "P2P 180 Network Overlay" , since its organization is not at the physical 181 layer, but is instead "on top of" an existing Internet Protocol 182 network. 184 P2PSIP: A communications protocol related to the Session Initiation 185 Protocol (sip) [3] that extends SIP by using peer-to-peer 186 techniques for resolving the targets of SIP requests. 188 P2PSIP Overlay: A P2PSIP Overlay is an association, collection, or 189 federation of nodes that provides SIP registration, SIP request 190 routing, and similar functions using a P2P organization, as 191 defined by "P2P Network" above. Other forms: overlay. 193 P2PSIP Peer: A node participating in a P2PSIP Overlay that provides 194 storage and routing services (fully participates in the P2P 195 routing) to other nodes in that P2PSIP Overlay. Each P2PSIP Peer 196 is presumed to have a unique identifier within the P2PSIP Overlay. 197 Each P2PSIP Peer may or may not be coupled to one or more P2PSIP 198 User Agents. Within the P2PSIP Overlay, the peer is capable of 199 performing several different operations, including: joining and 200 leaving the overlay, routing requests within the overlay, storing 201 information on behalf of the overlay, putting information into the 202 overlay, and getting information from the overlay. Other forms: 203 overlay peer or node, peer or node, superpeer or supernode (in 204 systems with peers and clients), peer. 206 P2PSIP Client: A node participating in a P2PSIP Overlay that 207 provides neither routing nor route storage and retrieval functions 208 to that P2PSIP Overlay. The P2PSIP Client interacts with the 209 P2PSIP Overlay only to request the insertion of routing 210 information (put in a Contact), request the retrieval of routing 211 information (get a Contact), or to request the routing of a 212 message to elsewhere in the P2PSIP Overlay. Unlike the P2PSIP 213 Peer, the client is presumed not to have a unique identifier 214 within the overlay. In cases where conventional SIP is used for 215 the P2PSIP Client protocol, this entity could be identical to a 216 standard SIP user agent. A P2PSIP Client may be coupled to one or 217 more P2PSIP Overlay User Agents. A P2PSIP Client is a logical 218 subset of a P2PSIP Peer; anything a P2PSIP Client can do, a P2PSIP 219 Peer can do as well. Other forms: overlay client, client. 221 P2PSIP Resource (User): An addressable user endpoint, entity, 222 service, or function within a P2PSIP Overlay. Examples include 223 but are not limited to humans, automata, bridges, mixers, media 224 relays, gateways, and media storage. Other forms: resource 225 (user). 227 P2PSIP Overlay Identifier: Information that identifies a specific 228 P2PSIP Overlay. All the P2PSIP Peers in a particular P2PSIP 229 Overlay have the same P2PSIP Overlay Identifier. This is may be 230 scoped to a name within the DNS, but other scopes may apply, 231 particularly in ad-hoc environments. Short forms: overlay name, 232 overlay identifier, overlay ID. 234 P2PSIP Peer-ID: Information that uniquely identifies each P2PSIP 235 Peer within a given P2PSIP Overlay. This value is not human- 236 friendly -- in a DHT approach, this is a numeric value in the hash 237 space. These Peer-IDs are completely independent of the 238 identifier of any user of a user agent associated with a peer. 239 Other forms: Node-ID 241 P2PSIP Resource (User) Name: A distinguished, human readable name 242 that identifies a specific P2PSIP Resource or User within a given 243 P2PSIP Overlay. This is presumed to be a URI scoped to the P2PSIP 244 Overlay Identifier. This is presumably the same or very similar 245 to a SIP Address of Record, or AOR. Other forms: overlay resource 246 (user) name, P2PSIP AOR. 248 P2PSIP Resource-ID: A non-human friendly value that uniquely 249 determines which P2PSIP Peer is responsible for storing 250 information about this resource (user). In a DHT approach, this 251 is a numeric value in the hash space resulting from hashing the 252 P2PSIP Resource Name. Since Resource-ID is in the same space as 253 the P2PSIP Peer-ID, it allows for a mapping between the values, 254 used to map a P2PSIP Resource to the P2PSIP Peer that stores it. 255 Other forms: P2PSIP User-ID. 257 P2PSIP Resource (User) Record: A block of data, stored using the 258 data mechanism of the P2PSIP Overlay, that includes information 259 relevant to a specific resource. We presume that there may be 260 multiple types of resource records. Some may describe routes to a 261 client at which the user is presumed reachable (a "user routing 262 record", like a SIP "Contact:"). Others might store presence 263 information. The types, usages, and formats of user records are a 264 question for future study. 266 P2PSIP User Agent: A SIP user agent that is coupled with or 267 incorporates a P2PSIP Peer or P2PSIP Client, such that the peer or 268 client can assist the UA with registration (storage of a route to 269 users of the UA) and/or routing of requests using the P2PSIP 270 Overlay. A P2PSIP User Agent differs from a conventional SIP user 271 agent in that it is coupled directly to a P2PSIP Peer or P2PSIP 272 Client, and can therefore directly interact with a P2PSIP Overlay, 273 which a conventional SIP UA cannot do. P2PSIP User Agents do not 274 themselves have a distinguished name or identifier, although the 275 P2PSIP User associated with it may, and if it is associated with a 276 P2PSIP Peer, that peer may as well. Other forms: overlay UA, 277 P2PSIP UA. 279 P2PSIP Peer Protocol: The protocol spoken between P2PSIP Overlay 280 peers to share information and organize the P2PSIP Overlay 281 Network. Short form: peer protocol. 283 P2PSIP Client Protocol: The protocol spoken between P2PSIP Clients 284 and the P2PSIP Peer they use to store or retrieve information from 285 the P2P Overlay. This is a functional subset of the P2P Peer 286 Protocol, but may differ in syntax and protocol implementation 287 (i.e., may not be syntactically related). Note that the precise 288 relationship between the P2PSIP Peer Protocol and the P2PSIP 289 Client Protocol (the same? subset?) remains an open question and 290 is expected to be a principle topic of the detailed design work. 291 This protocol may not exist (it may simply be conventional SIP) in 292 some designs. Short form: client protocol. 294 P2PSIP Overlay Neighbors: The set of P2PSIP Peers that either a 295 P2PSIP Peer or P2PSIP Client know of directly and can reach 296 without further lookups. Short form: neighbor 298 P2PSIP Bootstrap Server: A network node used by P2PSIP Peers or 299 Clients who are attempting to locate an entry into the P2PSIP 300 Overlay Network. It may return an entry point (address of a Peer) 301 to the P2PSIP Overlay or act as one itself. This should be a 302 quasi-stable and well known host, located using a configuration or 303 discovered via , DNS, broadcast, or other mechanism. This is a 304 logical role, meaning it can be implemented as a P2PSIP Peer, as a 305 standalone server, etc., but not every peer must provide this 306 functionality. Example: a P2PSIP Peer that reboots and has no 307 knowledge of other peers uses a P2PSIP Bootstrap Server to find 308 other peers in the P2P Overlay Network and establish P2PSIP Peer 309 Insertion. Other forms: bootstrap peer or node. 311 P2PSIP Resource (User) Record: A P2PSIP overlay user record that 312 provides a routing vector that points to a location where the 313 resource can presumably be reached. This is analogous to the 314 combination of a SIP [3] "Contact:" and a "Path:" [6]. The P2PSIP 315 equivalent of a SIP registration process would be the insertion of 316 an P2PSIP Resource Record into the overlay. Other forms: resource 317 (user) record, resource (user) registration. 319 P2PSIP Peer Insertion: The act of inserting a P2PSIP Overlay Peer 320 into the current routing structure (presumably a distributed 321 database or hash table) of a P2PSIP Overlay. For example, the 322 routing structure map the peer's IP address or DNS name to the 323 peer's P2PSIP Peer-ID. During insertion, the peer discovers its 324 P2PSIP Overlay neighbors. Following insertion, the peer will be 325 able to store user records (such as routing information), query 326 other peers for user records, and pass requests to route messages 327 to other peers. Other forms: peer or node registration, peer or 328 node join. 330 P2PSIP Resource (User) Record Insertion: The act of inserting a 331 record for a P2PSIP Resource (User) into the data maintained by 332 the P2PSIP Peers. Following insertion, the data stored at one or 333 more peers will contain a record (such as a P2PSIP Resource 334 Routing Record), keyed at least in part by a P2PSIP User 335 Identifier. Other forms: Resource registration, User record 336 insertion. 338 P2PSIP Peer Enrollment: The initial one-time process a P2PSIP Peer 339 follows to obtain an identifier and credentials, if any, within a 340 P2PSIP Overlay. This is not performed each time the peer comes 341 online (contrast to P2PSIP Peer Insertion above), but only the 342 first time they do so, or following a loss of identifier or 343 credentials by the peer. Other forms: node enrollment, peer 344 enrollment. 346 P2PSIP Resource (User) Enrollment: The initial one-time process a 347 P2PSIP Resource follows to obtain a unique identifier within a 348 P2PSIP Overlay. This is not performed each time the resource 349 comes online, only the first time they do so, or following a loss 350 of identifier or credentials by the client (contrast to P2PSIP 351 Resource Record Insertion). Other forms: user enrollment. 353 3. Discussion 355 3.1. What Kinds of P2PSIP Peers and Clients Might Exist? 357 In general, P2PSIP nodes might have the same sorts of duties/logical 358 roles as traditional client-server SIP nodes. This includes but is 359 not limited to: 361 1. User Agent: a phone, voice mail server, bridge, or other device 362 that initiates or terminates session requests. This could be a 363 P2PSIP Client (only performs GET/PUT of data) or P2PSIP Peer 364 (participates in storing data as well) 366 2. Media relay: a P2PSIP peer or client capable of relaying RTP 367 sessions, as described in [14] 369 3. Gateway: a P2PSIP peer or client that converts from P2PSIP to 370 some other protocol, such as PSTN (Public Switched Telephone 371 Network). 373 4. Redirector: a P2PSIP peer or client that accepts SIP requests 374 (such as INVITE) for a P2PSIP resource identifier, searches the 375 overlay, and returns the route to the resource in a 302 or 305 376 response. 378 5. Proxy: a P2PSIP peer or client that accepts SIP requests (such as 379 INVITE) for a P2PSIP resource identifier, searches the overlay, 380 and forwards (proxies) the request to that resource. 382 6. Registrar: A peer or client that processes SIP REGISTER requests 383 from non-P2P aware entities, either storing or retrieving the 384 contact information to/from the routing data of the P2PSIP 385 Overlay. 387 3.2. Reference Model 389 The following diagram depicts a reference or "boxes and arrows" model 390 showing several of the above peer and client types, along with a 391 conventional SIP user agent. 393 --->PSTN 394 +------+ N +------+ +---------+ / 395 | | A | | | Gateway |-/ 396 | UA |####T#####| UA |#####| Peer |######## 397 | Peer | N | Peer | | G | # Client Protocol 398 | E | A | F | +---------+ # GET/PUT 399 | | T | | # | 400 +------+ N +------+ # | 401 # A # | 402 NATNATNATNAT # | 403 # # | \__/ 404 NATNATNATNAT +-------+ v / \ 405 # N | |=====/ UA \ 406 +------+ A P2PSIP Overlay | Proxy | /Client\ 407 | | T | Peer | |___C__| 408 | UA | N Route Data | Q | 409 | Peer | A +-------+ 410 | D | T P2PSIP Peer Protocol # 411 | | N # 412 +------+ A # 413 # T # 414 # N +-------+ +-------+ # 415 # A | | | | # 416 #########T####| Proxy |########| Redir |####### 417 | Peer | | Peer | 418 | P | | R | 419 +-------+ +-------+ 421 \__/ 422 /\ 423 / \ 424 / UA \ 425 /______\ 426 SIP UA A 428 Figure: P2PSIP Overlay Reference Model 430 Here, the large perimeter depicted by "#" represents a stylized view 431 of the P2PSIP Overlay and its associated routing data (the actual 432 connections could be a mesh, ring, or some other structure). Around 433 the periphery of the P2PSIP Overlay rectangle, we have a number of 434 P2PSIP Peers -- a PSTN gateway peer "G", three user-agent peers "D", 435 "E" and "F", two proxy peers "P" and "Q", and a redirector peer "R". 436 Note that because these are all P2PSIP Peers, each is responsible for 437 helping store some information of the P2PSIP Overlay. 439 To the left, two of the peers ("D" and "E") are behind network 440 address translators. These peers are included in the P2PSIP overlay 441 and thus participate in storing information, despite being behind the 442 NATs. 444 Below the P2PSIP Overlay, we have a conventional SIP UA "A" which is 445 not part of the P2PSIP Overlay, either directly as a peer or 446 indirectly as a client. It speaks neither the P2PSIP Peer nor P2PSIP 447 Client protocols. Instead, it uses pure (unmodified/extended) SIP to 448 interact with with the P2PSIP Overlay. 450 On the right side, we have a P2PSIP UA client "C", which uses the 451 P2PSIP Client Protocol depicted by "=" to communicate with Proxy Peer 452 "Q". The P2PSIP Client protocol only allows for gets and puts to the 453 overlay. Therefore, "C" does NOT participate directly in/store 454 information in the overlay. In a solution where the P2PSIP Client 455 Protocol is SIP, such as is proposed in [7], there is no difference 456 between UA client "C" and standard SIP UAs "A", and the special 457 P2PSIP client protocol is not needed. 459 Note that in some scenarios, the P2PSIP Peers involved in the overlay 460 might use a keepalive mechanism to ensure that messages to neighbors 461 can pass through NATs. Presumably, these messages will be in the 462 form of the P2PSIP Peer protocol. 464 Both the "Proxy Peers" and "Redirect Peers" can serve as adapters 465 between ordinary SIP devices and the the P2PSIP Overlay. Each 466 accepts standard SIP requests and resolves the next-hop by using the 467 P2PSIP overlay Peer Protocol to interact with the routing knowledge 468 of the P2PSIP Overlay, then processes the SIP requests as appropriate 469 (proxying or redirecting towards the next-hop). Note that proxy 470 operation is bidirectional - the proxy may be forwarding a request 471 from an ordinary SIP device to the P2PSIP overlay, or from the P2PSIP 472 overlay to an ordinary SIP device. 474 The Gateway Peer provides a similar sort of adaptation to and from 475 the public switched telephone network (PSTN). However, there is a 476 subtle distinction. The gateway function itself can be viewed as a 477 "user" or within the P2PSIP overlay, and is addressed using a P2PSIP 478 Overlay User Identifier. This gateway functionality could also be 479 located in a P2PSIP Client, or even in a traditional SIP UA that is 480 reached via P2P (using a P2P proxy or redirector) or conventional SIP 481 mechanisms. 483 The functions of various types of peers (redirect, UA, proxy, 484 gateway) are logical roles. There is no reason a particular 485 implementation could not support one, several, or all of these 486 functions in one entity. For clarity, we show each as a fully 487 distinct entity. 489 3.3. Example Signalling Message Flows 491 The following show very high level examples of message flows for 492 various interactions of devices within the reference model. In each 493 case, we DO NOT show the flow of messages exchanged between P2PSIP 494 peers to lookup information, since the exact nature of these flows 495 and even who the messages would flow between will be a function of 496 the particular data structure and protocol that is selected. We do 497 however indicate when the lookups occur. This leads to the somewhat 498 odd situation of a diagram having numbered flows to indicate 499 ordering, but some numbers missing. This is regrettable, but we 500 aren't sure how else to do this since we cannot currently know what 501 the lookup flows will look like in the final P2PSIP Peer protocol. 503 In a solution where the P2PSIP Client Protocol is some protocol other 504 than SIP, all of the following example flows are needed. In a design 505 where unmodified SIP is used for the P2PSIP Client, Section 506 Section 3.3.2 is not needed. 508 3.3.1. P2PSIP Peer contacts P2PSIP Peer 510 The following diagram shows P2PSIP UA Peer "E" placing a call to 511 P2PSIP UA Peer "F". 1) UA Peer "E" first uses the P2PSIP Peer 512 protocol to communicate among the peers and obtain the location of 513 "F" (flow not shown as this will depend on the protocol designed). 2) 514 "E" then establishes a session directly with "F" using a conventional 515 SIP INVITE/200 OK mechanism. 517 2) SIP INVITE/200 OK 518 /----------------\ 519 / \ --->PSTN 520 +------+ N +------+ +---------+ / 521 | | A | | | Gateway |-/ 522 | UA |####T#####| UA |#####| Peer |######## 523 | Peer | N | Peer | | G | # Client Protocol 524 | E | A | F | +---------+ # GET/PUT 525 | | T | | # | 526 +------+ N +------+ # | 527 # A # | 528 NATNATNATNAT # | 529 # # | \__/ 530 NATNATNATNAT +-------+ v / \ 531 # N | |=====/ UA \ 532 +------+ A P2PSIP Overlay | Proxy | /Client\ 533 | | T | Peer | |___C__| 534 | UA | N Route Data | Q | 535 | Peer | A +-------+ 536 | D | T P2PSIP Peer Protocol # 537 | | N # 538 +------+ A # 539 # T # 540 # N +-------+ +-------+ # 541 # A | | | | # 542 #########T####| Proxy |########| Redir |####### 543 | Peer | | Peer | 544 | P | | R | 545 +-------+ +-------+ 547 Figure: P2PSIP Peer to Peer 549 3.3.2. P2PSIP Client contacts P2PSIP Peer 551 NOTE: In a design where unmodified SIP is used for the P2PSIP Client 552 protocol, this case does not exist/is not needed. Sections 553 Section 3.3.3 and Section 3.3.4, covering conventional SIP access are 554 all that are required. 556 The following diagram shows P2PSIP UA Client "C" placing a call to 557 P2PSIP UA Peer "F". 1) "C" first sends a GET request using the P2P 558 Client GET/PUT protocol to a Peer in the overlay, in this case "Q". 559 2) Some messages are exchanged among client "C" and the peers in the 560 overlay to perform the lookup (flow not shown as this will depend on 561 the protocol designed), and the address of "F" is passed back to "C" 562 using the P2PSIP Client protocol. 3) "C" then establishes a session 563 directly with "F" using a conventional SIP INVITE/200 OK mechanism. 565 3) SIP INVITE/200 OK 566 /---------------------------------------------+ 567 / | 568 / --->PSTN | 569 +------+ N +------+ +---------+ / | 570 | | A | | | Gateway |-/ | 571 | UA |####T#####| UA |#####| Peer |######## | 572 | Peer | N | Peer | | G | # 1) Client Protocol | 573 | E | A | F | +---------+ # GET | 574 | | T | | # | | 575 +------+ N +------+ # | | 576 # A # | / 577 NATNATNATNAT # | / 578 # # | \__/ / 579 NATNATNATNAT +-------+ v / \ / 580 # N | |=====/ UA \ / 581 +------+ A P2PSIP Overlay | Proxy | /Client\/ 582 | | T | Peer | |___C__| 583 | UA | N Route Data | Q | 584 | Peer | A +-------+ 585 | D | T P2PSIP Peer Protocol # 586 | | N # 587 +------+ A # 588 # T # 589 # N +-------+ +-------+ # 590 # A | | | | # 591 #########T####| Proxy |########| Redir |####### 592 | Peer | | Peer | 593 | P | | R | 594 +-------+ +-------+ 596 Figure: P2PSIP Client to Peer 598 3.3.3. Conventional SIP Device using a Proxy Peer 600 The following diagram shows a conventional SIP device, SIP UA "A", 601 establishing a dialog with UA Peer "F". 1) "A" sends a conventional 602 SIP INVITE to Proxy Peer "P". 2) Proxy Peer "P" uses the P2PSIP 603 Overlay Protocol to locate the target (flow not shown as this will 604 depend on the protocol designed), in this case UA Peer "F". 3) "P" 605 forwards the SIP request to the destination and proxies the response 606 back to "A". 608 --->PSTN 609 +------+ N +------+ +---------+ / 610 | | A | | | Gateway |-/ 611 | UA |####T#####| UA |#####| Peer |######## 612 | Peer | N | Peer | | G | # Client Protocol 613 | E | A | F | +---------+ # GET/PUT 614 | | T | | # | 615 +------+ N +------+ # | 616 # A | # | 617 NATNATNATNAT | # | 618 # | # | \__/ 619 NATNATNATNAT | +-------+ v / \ 620 # N | | |=====/ UA \ 621 +------+ A P2PSIP Overlay | Proxy | /Client\ 622 | | T | | Peer | |___C__| 623 | UA | N | | Q | 624 | Peer | A | +-------+ 625 | D | T |3) SIP INVITE/200 OK # 626 | | N | # 627 +------+ A | # 628 # T | # 629 # N +-------+ +-------+ # 630 # A | | | | # 631 #########T####| Proxy |########| Redir |####### 632 | Peer | | Peer | 633 | P | | R | 634 +-------+ +-------+ 635 / 636 / 637 \__/ / 1) SIP INVITE/200 OK 638 /\ / 639 / \/ 640 / UA \ 641 /______\ 642 SIP UA A 644 Figure: Proxied SIP dialog from SIP UA to P2PSIP UA through Peer 645 Proxy 647 3.3.4. Conventional SIP Device Using a Redirect Peer 649 The following diagram shows a second conventional SIP device, SIP UA 650 "A" establishing a dialog with a P2PSIP Client UA "C". 1) "A" sends a 651 conventional SIP INVITE to the Redirect Peer "R". 2) Redirect Peer 652 "R" uses the P2PSIP Peer Protocol to locate the target (flow not 653 shown as this will depend on the protocol designed), in this case 654 P2PSIP Client UA "C". In contrast to the Proxy peer above, "R" 655 returns the result of the lookup to "A" as a 302 Moved message, with 656 a contact of "C" (the conventional SIP 302 mechanism), rather than 657 proxying the request for "A". 3) The conventional SIP UA "A" device 658 can then establish the dialog directly with UA Client "C", even 659 though "A" has no awareness of the P2PSIP Overlay, or of the P2PSIP 660 Client Protocol. 662 --->PSTN 663 +------+ N +------+ +---------+ / 664 | | A | | | Gateway |-/ 665 | UA |####T#####| UA |#####| Peer |######## 666 | Peer | N | Peer | | G | # Client Protocol 667 | E | A | F | +---------+ # GET/PUT 668 | | T | | # | 669 +------+ N +------+ # | 670 # A # | 671 NATNATNATNAT # | 672 # # | \__/ 673 NATNATNATNAT +-------+ v / \ 674 # N | |=====/ UA \ 675 +------+ A P2PSIP Overlay | Proxy | /Client\ 676 | | T | Peer | |___C__| 677 | UA | N Route Data | Q | | 678 | Peer | A +-------+ | 679 | D | T P2PSIP Peer Protocol # | 680 | | N # 3) SIP INVITE 681 +------+ A # /200 OK 682 # T # | 683 # N +-------+ +-------+ # | 684 # A | | | | # | 685 #########T####| Proxy |########| Redir |####### | 686 | Peer | | Peer | / 687 | P | | R | / 688 +-------+ +-------+ / 689 \ / 690 \ / 691 1) SIP INVITE \ \__/ / 692 /302 Moved \ /\ / 693 \ / \ / 694 \/ UA \/ 695 /______\ 696 SIP UA A 698 Figure: Redirect from P2PSIP Overlay 700 3.4. Conceptual Outline of Operations 702 3.4.1. Enrolling and Inserting an P2PSIP Peer 704 Peers are the full-function "routing and storage" nodes of a P2PSIP 705 Overlay. When a new peer is first created, it must enroll in the 706 P2PSIP Overlay. We currently have no defined mechanism for this 707 (should this group define one?), but we know that once the process is 708 complete, the new peer will have at least a P2PSIP Peer-ID and 709 optionally a set of credentials. 711 After enrollment, each time the peer connects to the overlay, it must 712 insert itself. We don't have a defined protocol mechanism for this, 713 and assume we need one. Presumably the inserting peer connects to 714 one or more existing peers (possibly with the aid of a bootstrap 715 server) presents its credentials, and after exchanging some messages 716 with other P2PSIP Peers, ends up connected to the overlay. It will 717 then have some knowledge of neighbors (successor, precursor, finger 718 tables, or whatever the distribution mechanism defines) and is able 719 to store data on behalf of and route requests to other nodes in the 720 P2PSIP overlay. 722 3.4.2. More on The Difference Between a Peer, Client, and User Agent 724 P2PSIP Peers directly interact with and contain the routing and 725 storage fabric of the overlay. P2PSIP Clients simply use the routing 726 and storage facilities provided by the peers to get/put information. 727 The peers speak the P2PSIP Peer Protocol, which presumably has a full 728 range of expressivity for the routing and storage facilities of the 729 overlay. Clients speak the P2PSIP Client protocol, which is 730 presumably a subset of the peer protocol, and is limited to storage 731 insertion (put), storage retrieval (get), and message routing (send). 732 Some designs do not require a separate client protocol. 734 Some peers and some clients may be coupled to SIP user agents, making 735 them P2PSIP User Agents capable of both sending and receiving 736 conventional SIP messages (as per a SIP UA) using conventional SIP 737 resolution procedures and of using the resolution facilities provided 738 by the overlay. 740 The mix and configuration of peers, clients, and P2PSIP UAs is 741 expected to vary depending on the deployment scenario. For example, 742 an ad-hoc scenario might deploy nothing but P2PSIP Peers, each of 743 which is coupled to a P2PSIP User Agent, using a broadcast or 744 multicast bootstrap mechanism. Another common scenario, the "self 745 organizing proxy farm", might consist of P2PSIP Peers, each of which 746 is coupled to a SIP proxy/registrar function. 748 Some of the systems proposed that use SIP for the P2PSIP Client 749 protocol essentially remove that protocol from their design. 750 Standard SIP messages are sent to a proxy or redirect server which 751 speaks the P2PSIP server protocol, eliminating the need for another 752 protocol. 754 3.4.3. Enrolling a User and Inserting a P2PSIP User Agent 756 Clients and Peers are devices, the "end points" or "user agents" of a 757 P2PSIP Overlay. Users are the named entities that participate in a 758 P2PSIP overlay using a client. 760 To get started, users must be enrolled in the overlay. We do not 761 have a process or protocol for this, nor are we certain we need a 762 standardized mechanism. We presume that after enrollment, the user 763 has a distinguished name within the overlay (example: 764 sip:bob@example.com) and a set of credentials useful for 765 authenticating its usage of the distinguished name. One possible 766 mechanism for these credentials would be an x.509 certificate. It 767 might also be possible to use a PGP key, a password, or some other 768 mechanism. Presumably following enrollment, the user is also 769 equipped with the information needed to connect to the overlay, such 770 as the address of a bootstrap server. Whether this startup 771 information is delivered as a part of enrollment of through some 772 separate configuration process remains an open question, and it is 773 not clear it is within the scope of the proposed WG. 775 Once a user is enrolled, the user may exercise a P2PSIP User Agent to 776 insert into the P2PSIP Overlay. We currently have no protocol 777 mechanism for this, and need to define one. The P2PSIP UA exercises 778 the associated P2PSIP Peer or P2PSIP Client to execute the 779 "registration" function and insert a route for the user into the 780 P2PSIP overlay. This function is described as a "PUT" request, and 781 results in the storage of an authenticated route-set for the user in 782 the P2PSIP overlay, such that the terminus of the route is the URI of 783 the user at the P2PSIP UA. This is analogous to "registration" in a 784 classic SIP environment, and one mechanism proposed is in fact to use 785 the SIP REGISTER method. Presumably, the P2PSIP UA connects to a 786 peer or client and uses the user's credentials to authenticate a 787 route-set (Contact: plus Path:) to itself, and the peer or client 788 stores the route-set into the overlay, using a key derived from the 789 user's identity. 791 3.4.4. Bootstrapping 793 If a client or peer is just starting up and has no knowledge of how 794 to reach the other nodes of the overlay, it may exercise a bootstrap 795 server to find one. Presumably it discovers the bootstrap server by 796 some mechanism such as a DNS lookup, multicast, broadcast or 797 configuration, then queries the bootstrap server and receives an 798 address for a peer or set of peers that can be used to reach the 799 overlay. Ideally, these target peers will be selected from a 800 relatively large pool of peers that are currently online and 801 reachable. 803 After discovering the address of a peer, the behavior of the starting 804 node will vary depending on whether it is intending to be a peer or a 805 client. If it is intending to be a peer, it goes into the P2PSIP 806 Peer Insertion process, at the conclusion of which it is actively 807 participating in the target overlay as a peer and is capable of 808 routing requests and storing records on behalf of the P2PSIP overlay. 809 If it is intending to be a client, it does not bother with insertion, 810 but merely contacts the discovered peer in order to use the overlay. 812 In the typical case, the peer or client coming up is also a P2PSIP 813 User Agent with one or more associated P2PSIP Resource (User) 814 Identifiers. The next step then is to insert a P2PSIP Resource 815 Record (a Contact:) into the P2PSIP Overlay. 817 We may wish to have a mechanism in place where a particular bootstrap 818 server can send a redirect response, offloading a heavily loaded 819 server. 821 4. Questions 823 4.1. PP2PSIP Peer Protocol 825 This may or may not be SIP. What should it be? Alternatives include 826 SIP, a full IETF protocol based on OpenDHT, or something else. Do we 827 need to define a new protocol? Will implementors want to implement a 828 new protocol? 830 4.2. P2PSIP Client Protocol 832 This may or may not be SIP. What should it be? It defines only GET/ 833 PUT operations, which could be done using SIP REGISTER transactions. 834 Essentially disappears if we do select SIP. 836 4.3. How To Find Media Relays? 838 This needs to be net-path efficient. Is this possible? Is it enough 839 just to construct a key with a "relay" identifier? What sorts of 840 access controls do we need on media relays? 842 4.4. How Do We Find Gateways? 844 This needs to be not only netpath efficient, but also embodies 845 elements of the TRIP and SPEERMINT problems. 847 4.5. Peer-Adjacency Through NATs 849 We assume that some or even many peers will be behind NATs, and 850 therefore reached through peer-to-peer routing. How do we keep alive 851 the NAT-crossing peer bindings? Is some variant of "outbound" [15] 852 usable? 854 4.6. Cryptotransparency 856 When forwarding requests, are the bodies of the requests visible to 857 peers? If so, this creates substantial security problems that the 858 deployers of conventional SIP have been willing to mostly ignore. 859 Can we make peers cryptotransparent (like HTTP proxies) when security 860 is requested? 862 4.7. Record Formats 864 Clearly we need user routing records stored into the P2PSIP overlay. 865 Do we need other sorts of record? If so, what? How do we 866 differentiate between or classify records? Do we end up with many 867 records per user per client, or do we aggregate the per-client or 868 per-user view using something like XML? 870 4.8. Peer and Client Enrollment Protocols 872 We know that we need to enroll peer and client nodes into a P2PSIP 873 Overlay. Do we define a protocol or process for this, assume it will 874 happen externally, or just provide an existence-proof argument? 876 4.9. Peer and User Credentials 878 We believe we need some sort of credentials for authenticating peers 879 and users of each P2PSIP Overlay. What should we use for these 880 credentials? Certificates? PGP keys? Passwords? If certificates, 881 should these be signed by a CA associated with the overlay, or can 882 self-signed certificates work in some or all cases? Do we need to 883 specify a standard credential format, or should we allow different 884 implementations to use different credential formats? 886 4.10. Bootstrapping 888 We know that sometimes peers or clients will start up without 889 knowledge of how to find a peer for insertion. Do we need to define 890 a bootstrap mechanism or mechanisms? Do we need to define supporting 891 protocols? 893 4.11. Credential Recovery 895 One reader suggested that we extend the definition of P2PSIP Peer 896 Enrollment to cover the case where a previously-inserted peer has 897 lost its credentials (through, perhaps, being moved to a different 898 host) and wishes to recover them without necessarily creating a new 899 P2PSIP Peer-ID. The editors are inclined to believe that this is an 900 operational issue, not a matter of definition, but would like to seek 901 a broader consensus before concluding the topic. A similar question 902 applies to user enrollment. 904 4.12. Overlapping Domains 906 If the P2PSIP Resource (User) Identifier is not scoped to a single 907 DNS domain, this would appear to allow nodes from two or more 908 apparent domains to share a single P2PSIP Overlay. What, if 909 anything, do we need to say about this mode of operation? 911 4.13. Hybrid Domains 913 It appears possible to have some hosts within a domain using 914 conventional SIP and some using P2PSIP. This potentially raises a 915 number of questions: 1) What should happen if we want to run a P2PSIP 916 overlay in an existing SIP domain? 2) Do the existing redir/proxy 917 servers need to be coupled with a peer layer? 3) When would an 918 overlay peer want to discover them as opposed to looking in the 919 overlay? 4) Is better not to run conventional SIP with P2PSIP? 5) 920 When conventional and P2PSIP are run together, shall the existing 921 redir servers keep their local databases or switch to the overlay 922 storage. 924 4.14. Admissions Control 926 What do we need to say about admissions control with respect to the 927 enrollment of peers and users? Do we need to discuss per-call 928 admissions control in a P2P environment? 930 4.15. Users versus Resources 932 This model presumes that all addressable elements, aka "users", are 933 unique. Are their other classes of resources that need some sort of 934 class-addressable identifier that does not refer to a unique user? 936 5. Security Considerations 938 Building a P2PSIP system has many security considerations, many of 939 which we have only begun to consider. We anticipate that the 940 protocol documents describing the actual protocols will deal more 941 thoroughly with security topics. 943 6. IANA Considerations 945 This document presently raises no IANA considerations. 947 7. Acknowledgements 949 This document draws heavily from the contributions of many 950 participants in the P2PSIP Mailing List but the authors are 951 especially grateful for the support of Spencer Dawkins, Cullen 952 Jennings, and Henning Schulzrinne, all of whom spent time on phone 953 calls about this document or provided text. Additionally, Spencer 954 provided a large portion of the ASCII art contained in this document. 956 8. References 958 8.1. Normative References 960 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 961 Levels", BCP 14, RFC 2119, March 1997. 963 [2] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform 964 Resource Locators (URL)", RFC 1738, December 1994. 966 [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 967 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 968 Session Initiation Protocol", RFC 3261, June 2002. 970 [4] Mockapetris, P., "Domain names - concepts and facilities", 971 STD 13, RFC 1034, November 1987. 973 [5] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol 974 (SIP): Locating SIP Servers", RFC 3263, June 2002. 976 [6] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) 977 Extension Header Field for Registering Non-Adjacent Contacts", 978 RFC 3327, December 2002. 980 8.2. Informative References 982 [7] Bryan, D., "A P2P Approach to SIP Registration and Resource 983 Location", draft-bryan-sipping-p2p-02 (work in progress), 984 March 2006. 986 [8] Shim, E., "An Architecture for Peer-to-Peer Session Initiation 987 Protocol (P2P SIP)", draft-shim-sipping-p2p-arch-00 (work in 988 progress), March 2006. 990 [9] Sinnreich, H. and A. Johnston, "SIP, P2P, and Internet 991 Communications", draft-johnston-sipping-p2p-ipcom-02 (work in 992 progress), March 2006. 994 [10] Matthews, P., "Industrial-Strength P2P SIP", 995 draft-matthews-sipping-p2p-industrial-strength-00 (work in 996 progress), February 2005. 998 [11] Risson, J. and T. Moors, "Survey of Research towards Robust 999 Peer-to-Peer Networks: Search Methods", 1000 draft-irtf-p2prg-survey-search-00 (work in progress), 1001 March 2006. 1003 [12] Bryan, D., "Use Cases for Peer-to-Peer Session Initiation 1004 Protocol (P2P SIP)", draft-bryan-sipping-p2p-usecases-00 (work 1005 in progress), December 2005. 1007 [13] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101, 1008 June 2005. 1010 [14] Rosenberg, J., "Obtaining Relay Addresses from Simple Traversal 1011 Underneath NAT (STUN)", draft-ietf-behave-turn-02 (work in 1012 progress), October 2006. 1014 [15] Jennings, C. and R. Mahy, "Managing Client Initiated 1015 Connections in the Session Initiation Protocol (SIP)", 1016 draft-ietf-sip-outbound-04 (work in progress), June 2006. 1018 URIs 1020 [16] 1022 Authors' Addresses 1024 Dean Willis (editor) 1025 Cisco Systems 1026 3100 Independence Pkwy #311-164 1027 Plano, Texas 75075 1028 USA 1030 Phone: unlisted 1031 Email: dean.willis@softarmor.com 1033 David A. Bryan 1034 SIPeerior Technologies and William & Mary 1035 3000 Easter Circle 1036 Williamsburg, Virginia 23188 1037 USA 1039 Phone: unlisted 1040 Email: bryan@ethernot.org 1042 Philip Matthews 1043 Avaya 1044 100 Innovation Drive 1045 Ottawa, Ontario K2K 3G7 1046 Canada 1048 Phone: +1 613 592 4343 x224 1049 Email: philip_matthews@magma.ca 1051 Eunsoo Shim 1052 Panasonic Digital Networking Laboratory 1053 Two Research Way, 3rd Floor 1054 Princeton, New Jersey 08540 1055 USA 1057 Phone: unlisted 1058 Email: eunsoo@research.panasonic.com 1060 Full Copyright Statement 1062 Copyright (C) The Internet Society (2006). 1064 This document is subject to the rights, licenses and restrictions 1065 contained in BCP 78, and except as set forth therein, the authors 1066 retain all their rights. 1068 This document and the information contained herein are provided on an 1069 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1070 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1071 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1072 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1073 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1074 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1076 Intellectual Property 1078 The IETF takes no position regarding the validity or scope of any 1079 Intellectual Property Rights or other rights that might be claimed to 1080 pertain to the implementation or use of the technology described in 1081 this document or the extent to which any license under such rights 1082 might or might not be available; nor does it represent that it has 1083 made any independent effort to identify any such rights. Information 1084 on the procedures with respect to rights in RFC documents can be 1085 found in BCP 78 and BCP 79. 1087 Copies of IPR disclosures made to the IETF Secretariat and any 1088 assurances of licenses to be made available, or the result of an 1089 attempt made to obtain a general license or permission for the use of 1090 such proprietary rights by implementers or users of this 1091 specification can be obtained from the IETF on-line IPR repository at 1092 http://www.ietf.org/ipr. 1094 The IETF invites any interested party to bring to its attention any 1095 copyrights, patents or patent applications, or other proprietary 1096 rights that may cover technology that may be required to implement 1097 this standard. Please address the information to the IETF at 1098 ietf-ipr@ietf.org. 1100 Acknowledgment 1102 Funding for the RFC Editor function is provided by the IETF 1103 Administrative Support Activity (IASA).