idnits 2.17.1 draft-hilt-sipping-session-policy-framework-01.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 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1181. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1158. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1165. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1171. ** 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 712 has weird spacing: '... where prox...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 5, 2006) is 6625 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) -- No information found for draft-hilt-sipping-session-policy-package - is the name correct? -- Possible downref: Normative reference to a draft: ref. '2' -- No information found for draft-hilt-sipping-media-policy-dataset - is the name correct? -- Possible downref: Normative reference to a draft: ref. '3' == Outdated reference: A later version (-18) exists of draft-ietf-sipping-config-framework-07 -- Obsolete informational reference (is this intentional?): RFC 2327 (ref. '7') (Obsoleted by RFC 4566) == Outdated reference: A later version (-05) exists of draft-petrie-sipping-profile-datasets-02 Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING Working Group V. Hilt 3 Internet-Draft Bell Labs/Lucent Technologies 4 Expires: September 6, 2006 G. Camarillo 5 Ericsson 6 J. Rosenberg 7 Cisco Systems 8 March 5, 2006 10 A Framework for Session Initiation Protocol (SIP) Session Policies 11 draft-hilt-sipping-session-policy-framework-01 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on September 6, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 Proxy servers play a central role as an intermediary in the Session 45 Initiation Protocol (SIP) as they define and impact policies on call 46 routing, rendezvous, and other call features. However, there is 47 currently no standard mechanism by which a proxy can influence 48 session policies such as the codecs or media types to be used. This 49 document specifies a framework for SIP session policies. It defines 50 two types of session policies, session-specific and session- 51 independent policies and introduces a model, an overall architecture 52 and the protocol components needed for session policies. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Session-Independent Policies . . . . . . . . . . . . . . . . . 4 59 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3.2. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3.2.1. Subscription . . . . . . . . . . . . . . . . . . . . . 5 62 3.2.2. Content . . . . . . . . . . . . . . . . . . . . . . . 6 63 4. Session-Specific Policies . . . . . . . . . . . . . . . . . . 6 64 4.1. Architecture . . . . . . . . . . . . . . . . . . . . . . . 7 65 4.2. Overall Operation . . . . . . . . . . . . . . . . . . . . 8 66 4.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 4.3.1. Offer in Request . . . . . . . . . . . . . . . . . . . 9 68 4.3.2. Offer in Response . . . . . . . . . . . . . . . . . . 12 69 4.4. UA/Policy Server Rendezvous . . . . . . . . . . . . . . . 13 70 4.4.1. UAC Behavior . . . . . . . . . . . . . . . . . . . . . 13 71 4.4.2. Caching of Policy Server URIs . . . . . . . . . . . . 14 72 4.4.3. UAS Behavior . . . . . . . . . . . . . . . . . . . . . 15 73 4.4.4. Proxy Behavior . . . . . . . . . . . . . . . . . . . . 15 74 4.4.5. Header Definition and Syntax . . . . . . . . . . . . . 16 75 4.5. Policy Channel . . . . . . . . . . . . . . . . . . . . . . 17 76 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 78 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 19 79 Appendix B. Call Flows . . . . . . . . . . . . . . . . . . . . . 19 80 B.1. PUBLISH/SUBSCRIBE - Offer in Invite . . . . . . . . . . . 19 81 B.2. PUBLISH/SUBSCRIBE - Offer in Response . . . . . . . . . . 20 82 B.3. SUBSCRIBE - Offer in Invite . . . . . . . . . . . . . . . 22 83 B.4. SUBSCRIBE - Offer in Response . . . . . . . . . . . . . . 24 84 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 85 7.1. Normative References . . . . . . . . . . . . . . . . . . . 25 86 7.2. Informative References . . . . . . . . . . . . . . . . . . 25 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 88 Intellectual Property and Copyright Statements . . . . . . . . . . 28 90 1. Introduction 92 The Session Initiation Protocol (SIP) [6] is a signaling protocol for 93 creating, modifying and terminating multimedia sessions. A central 94 element in SIP is the proxy server. Proxy servers are intermediaries 95 that are responsible for request routing, rendezvous, authentication 96 and authorization, mobility, and other signaling services. However, 97 proxies are divorced from the actual sessions - audio, video, and 98 messaging - that SIP establishes. Details of the sessions are 99 carried in the payload of SIP messages, and are usually described 100 with the Session Description Protocol (SDP) [7]. Indeed, SIP 101 provides end-to-end encryption features using S/MIME, so that all 102 information about the sessions can be hidden from eavesdroppers and 103 proxies alike. 105 However, experience has shown that there is a need for SIP 106 intermediaries to impact aspects of a session. For example, SIP may 107 be used in a wireless network, which has limited resources for media 108 traffic. During periods of high activity, the wireless network 109 provider wants to restrict the amount of bandwidth available to each 110 individual user. With session policies, an intermediary in the 111 wireless network can inform the user agent about the bandwidth it 112 currently has available. This information enables the user agent to 113 make an informed decision about the number of streams, the media 114 types, and the codecs it can successfully use in a session. 116 In another example, a SIP user agent is using a network which is 117 connected to the public Internet through a firewall or a network 118 border device. The network provider would like to tell the user 119 agent that it needs to send its media streams to a specific IP 120 address and port on the firewall or border device to reach the public 121 Internet. Knowing this policy enables the user agent to set up 122 sessions across the firewall or the network border. In contrast to 123 other methods for inserting a media intermediary, the use of session 124 policies does not require the inspection or modification of SIP 125 message bodies. Other user cases for session policies are described 126 in [8]. 128 Domains sometimes enforce policies they have in place. For example, 129 a domain might have a configuration in which all packets containing a 130 certain audio codec are dropped. Unfortunately, enforcement 131 mechanisms usually do not inform the user about the policies they are 132 enforcing and silently keep the user from doing anything against 133 them. This may lead to the malfunctioning of devices that is 134 incomprehensible to the user. With session policies, the user knows 135 about the restricted codecs and can use a different codec or simply 136 connect to a domain with less stringent policies. Session policies 137 provide an important combination of consent coupled with enforcement. 139 That is, the user becomes aware of the policy and needs to act on it, 140 but the provider still retains the right to enforce the policy. 142 Two types of session policies exist: session-specific policies and 143 session-independent policies. Session-specific policies are policies 144 that are created for one particular session, in response to the 145 session description for this session. For example, a session- 146 specific policy may modify the IP addresses and ports of media 147 streams in a specific session. Since session-specific policies are 148 tailored to a session, they only apply to the session they are 149 created for. Session-specific policies are created on a session-by- 150 session basis during the establishment of the session. 152 Session-independent policies on the other hand are policies that are 153 created independent of a session and generally apply to the SIP 154 sessions set up by a user agent. Since these policies are not based 155 on a specific session description, they can be created and conveyed 156 to the user agent at any time, independent of an attempt to set up a 157 session. 159 This specification defines a framework for SIP session policies. It 160 specifies a model, the overall architecture, and the protocol 161 components that are needed for session-independent and session- 162 specific policies. 164 2. Terminology 166 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 167 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 168 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 169 described in BCP 14, RFC 2119 [1] and indicate requirement levels for 170 compliant implementations. 172 3. Session-Independent Policies 174 This section defines a model and the protocol components for session- 175 independent policies. 177 3.1. Overview 179 Setting up session-independent policies involves the following steps: 181 1. A user agent requests session-independent policies from the 182 policy servers in the local network and home domain. These two 183 domains most likely have session-independent policies for a user 184 agent. A user agent typically request these policies when it 185 starts up or connects to a new network domain. 186 2. The policy server selects the policies that apply to this user 187 agent. The policy server may have general policies that apply to 188 all users or maintain separate policies for each individual user. 189 The selected policies are returned to the user agent. 190 3. The policy server may update the policies, for example, when 191 network conditions change. 193 3.2. Protocol 195 A UA subscribes to session-independent policies using the "ua 196 profile" event package defined in the Framework for SIP User Agent 197 Profile Delivery [4]. This event package has been designed to 198 support subscriptions to user agent configuration information as well 199 as to session-specific policies. A server can provide session- 200 independent policies and configuration information through the same 201 subscription. However, it is expected that session-independent 202 policies and configuration information will often be provided by 203 different servers, which may even be in different domains. In 204 addition, session-independent policies may change more frequently 205 than configuration information since they may consider external 206 information, such as the network status. 208 3.2.1. Subscription 210 Session-independent policies are usually provided by the network 211 domain the UA is physically connected to (i.e. the local network 212 domain). This domain may, for example, have policies that limit the 213 bandwidth currently available to each user. Frequently, the domain a 214 user registers at (i.e., the domain in the address-of-record (AoR)) 215 will also provides session-independent policies. This domain may, 216 for example, provide policies needed for a service the user has 217 subscribed to. 219 The "ua profile" event package [4] provides a mechanism to discover 220 policy servers in these two domains. The "localnetwork" profile-type 221 enables a UA to discover a servers in the local network domain; the 222 "user" profile type enables the discovery of a server in the AoR 223 domain. A UA SHOULD attempt to discover and subscribe to the policy 224 servers in these two domains. 226 A UA SHOULD create a SUBSCRIBE request when the following events 227 occur: 229 o The UA registers a new AoR or it removes a AoR from the set of 230 AoRs it has registered. In these cases, the UA SHOULD establish 231 subscriptions for each new AoR using the "user" and the 232 "localnetwork" profile-types. The UA SHOULD terminate all 233 subscriptions for AoRs it has removed. 234 o The UA changes the domain it is connected to. The UA SHOULD 235 terminate all existing subscriptions for the "localnetwork" 236 profile-type. It SHOULD then create a new subscription for each 237 AoR using the "localnetwork" profile-type. This way, the UA stops 238 receiving policies from the previous local domain and starts 239 receives policies from the new local domain instead. The UA does 240 not need to change the subscriptions for "user" profiles. 242 If a subscriber is unable to establish a subscription, it SHOULD NOT 243 attempt to re-try this subscription, unless one of the above events 244 occurs again. This is to limit the number of SUBSCRIBE requests sent 245 within domains that do not support session-independent policies. 247 3.2.2. Content 249 The "ua profile" event package is an abstract event package that does 250 not define a default content type for subscriptions. A user agent 251 subscribing to session-independent policies SHOULD include the MIME 252 type for the Schema for SIP User Agent Profile Data Sets [9] and the 253 "application/session-policy+xml" format [3] in the Accept header of a 254 SUBSCRIBE request. The Schema for SIP User Agent Profile Data Sets 255 is an abstract format for configuration data that is extended by the 256 "application/session-policy+xml" format for media-related policies. 257 These are the default formats for subscriptions to session- 258 independent policies and MUST be supported by a user agent compliant 259 to this specification. 261 A policy server MAY send a notification to the subscriber every time 262 the session-independent policy covered by the subscription changes. 263 The definition of what causes a policy to change is at the discretion 264 of the administrator. A change in the policy may be triggered, for 265 example, by a change in the network status or simply by an update of 266 the service level agreement with the customer. The session- 267 independent policy contained in notification MUST represent a 268 complete session-independent policy. Deltas to previous policies or 269 partial policies are not supported. 271 4. Session-Specific Policies 273 This section defines a model, an architecture and the protocol 274 components for session-specific policies. 276 4.1. Architecture 278 +-------------+ 279 /------| Proxy |----... 280 +----+ / +-------------+ 281 | |---/ +-------------+ 282 | | | Policy | 283 | UA |============| Server | 284 | | +-------------+ 285 | |**** +-------------+ 286 +----+ * | Router w/ | 287 *******| Policy |****... 288 | Enforcement | 289 +-------------+ 291 --- SIP Signaling 292 === Policy Channel 293 *** Media 295 Figure 1 297 The following entities are involved in setting up session-specific 298 policies (see Figure 1): a user agent (UA), a proxy, a policy server 299 and possibly a router with policy enforcement functionality. 301 The role of the proxy is to provide a rendezvous mechanism for UA and 302 policy server. It conveys the URI of the policy server in its domain 303 to UAs and ensures that each UA knows where to retrieve policies 304 from. It does not deliver the actual policies to UAs. 306 The policy server is a separate logical entity that may be physically 307 co-located with the proxy. The role of the policy server is to 308 deliver session policies to UAs. The policy server receives session 309 information, uses this information to determine the policies that 310 apply to the session and returns the corresponding session policy to 311 the UA. The mechanism for generating policies (i.e. making policy 312 decisions) is outside the scope of this specification. A policy 313 server may, for example, query an external entity to get the policies 314 that apply to a session or it may directly incorporate a policy 315 decision point and generate policies locally. 317 A UA receives the URI of a policy server from the proxy. It uses 318 this URI to establish a policy channel to the policy server. It 319 provides information about the current session to the policy server 320 and receives session policies in response. The UA may also receive 321 policy updates from the policy server during the course of a session. 323 A network may have a policy enforcement infrastructure in place. 325 However, this specification does not make any assumptions about the 326 enforcement of session policies and the mechanisms defined here are 327 orthogonal a policy enforcement infrastructure. Their goal is to 328 provide a mechanism to convey session information to a policy server 329 and to return the policies that apply to a session to the UA. 331 4.2. Overall Operation 333 The protocol defined in this specification clearly separates SIP 334 signaling and the exchange of policy information. SIP signaling is 335 only used to rendezvous the UA with the policy server. From this 336 point on, UA and policy server communicate directly with each other 337 over a separate policy channel. This is opposed to a piggyback 338 model, where the exchange of policy information between endpoint and 339 a policy server in the network is piggybacked onto the SIP signaling 340 messages that are exchanged between endpoints. 342 The main advantage of using a separate policy channel is that it 343 decouples the exchange of signaling messages between endpoints from 344 the exchange of policy information between endpoint and a policy 345 server. This decoupling provides a number of desirable properties. 346 It enables the use of separate encryption mechanisms on the signaling 347 path (to secure the communication between endpoints) and on the 348 policy channel (to secure the communication between endpoint and 349 policy server). Policies can be submitted directly from the policy 350 server to the endpoint and never travel along the signaling path, 351 possibly crossing many domains. Endpoints set up a separate policy 352 channel to each policy server and can specifically decide which 353 information they want to disclose to which policy server. Finally, 354 policy servers do not need to rely on a SIP signaling message flowing 355 by to send policies or policy updates to the endpoint. A policy 356 server can use the policy channel at any time to update session 357 policies as needed. A disadvantage of the separate channel model is 358 that it requires additional messages for the exchange of policy 359 information. 361 Following this model, the signaling for session-specific policies 362 involves the following two fundamental tasks: 364 1. UA/policy server rendezvous: a UA setting up a session needs to 365 be able to discover the policy servers that are relevant to this 366 session. In principle, each domain that is traversed by the 367 signaling messages of a session can have session policies in 368 place and therefore run a policy server. However, session- 369 specific policies are usually only provided by the local domain 370 of the user agent. 372 2. Policy channel: once the UA has discovered the relevant policy 373 servers for a session, it needs to retrieve the policies that 374 apply to the current session from these servers. 376 The exchange of policy information on the policy channel follows the 377 model described below: 379 1. A user agent submits a session description to the policy server 380 and asks whether a session using this session description is 381 permissible. 382 2. The policy server generates a policy decision for this session 383 and returns the decision to the user agent. Possible policy 384 decisions are to (1) deny the session, (2) propose changes to the 385 session description with which the session is acceptable, or (3) 386 accept the session as it was proposed. 387 3. The policy server possibly updates the policy decision at a later 388 time. 390 The protocol mechanisms for UA/policy server rendezvous and the 391 mechanism used on the policy channel are discussed in the following 392 sections. 394 4.3. Examples 396 This section provides two examples to illustrate the overall 397 operation of session-specific policies. The call flows depict the 398 rendezvous mechanism between UA and policy server in detail and 399 indicate the points at which the UA exchanges policy information with 400 the policy server. 402 The example is based on the following scenario: there are two domains 403 (domain A and domain B), which both have session-specific policies 404 for the UAs in their domain. Both domains do not provide policies to 405 the UAs outside of their domain. The two domains have a proxy (P A 406 and P B) and a policy server (PS A and PS B). The policies in both 407 domains involve the session description offer and answer. 409 4.3.1. Offer in Request 411 The first call flow depicts an INVITE transaction with the offer in 412 the request. It is assumed that the UAC does not have previous 413 knowledge about the policy server in its domain. 415 (1) UA A sends an INVITE to proxy P A. P A knows that policies apply 416 to this session and (2) returns a 488 to UA A. P A includes the URI 417 of PS A in the 488 response. (3) UA A contacts PS A, discloses the 418 session description offer to PS A and (4) receives policies for the 419 offer. (5) UA A reformulates the INVITE request under consideration 420 of the received policies and includes a Policy-Id header to indicate 421 that it has already contacted PS A. P A does not reject the INVITE 422 this time and removes the Policy-Id header when forwarding the 423 INVITE. P B adds a Policy-Contact header containing the URI of PS B. 424 (6) UA B uses this URI to contact PS B and discloses the offer and 425 the answer it is about to send. (7) UA B receives policies from PS B 426 and applies them to the offer and answer respectively. (8) UA B 427 returns the updated answer in the 200 OK. (9) UA A contacts PS A with 428 the answer and (10) retrieves answer policies from PS A. 430 UA A P A P B UA B 431 | | | | 432 | INVITE offer | | | 433 |---------------->| | | (1) 434 | 488 | | | 435 | + Policy-Contact| | | 436 |<----------------| | | (2) 437 | ACK | | | 438 |---------------->| | | 439 | | PS A | | 440 | | | | 441 | PolicyChannel | | | 442 | + InfoOffer | | | 443 |------------------->| | | (3) 444 | PolicyChannel | | | 445 | + PolicyOffer | | | 446 |<-------------------| | | (4) 447 | | | | 448 | | | | 449 | INVITE offer' | INVITE offer' | INVITE offer | 450 | + Policy-Id | | + Policy-Contact| 451 |---------------->|--------------->|---------------->| (5) 452 | | | | 453 | | PS B | | 454 | | | | 455 | | | PolicyChannel | 456 | | | + InfoOffer | 457 | | | + InfoAnswer | 458 | | |<-------------------| (6) 459 | | | PolicyChannel | 460 | | | + PolicyOffer | 461 | | | + PolicyAnswer | 462 | | |------------------->| (7) 463 | | | | 464 | | | | 465 | OK answer | OK answer | OK answer | 466 |<----------------|<---------------|<----------------| (8) 467 | ACK | 468 |--------------------------------------------------->| 469 | | | | 470 | | | | 471 | PolicyChannel | | | 472 | + InfoAnswer | | | 473 |------------------->| | | (9) 474 | PolicyChannel | | | 475 | + PolicyAnswer | | | 476 |<-------------------| | | (10) 477 | | | | 479 4.3.2. Offer in Response 481 This call flow depicts an INVITE transaction with the offer in the 482 response. 484 Steps (1) - (8) are analogous to steps (1) - (8) in the above flow. 485 An important difference is that in steps (9) and (10) UA A contacts 486 PS A after receiving the offer in the 200 OK but before returning the 487 answer in step (11). This enables UA A to return the final answer, 488 which includes all applicable policies, in the ACK. However, it 489 requires that PS A immediately returns a policy to avoid a delay in 490 the transmission of the ACK. This is similar to Flow I in [10]. 492 UA A P A P B UA B 493 | | | | 494 | INVITE | | | 495 |---------------->| | | (1) 496 | 488 | | | 497 | + Policy-Contact| | | 498 |<----------------| | | (2) 499 | ACK | | | 500 |---------------->| | | 501 | | PS A | | 502 | | | | 503 | PolicyChannel | | | 504 |------------------->| | | (3) 505 | PolicyChannel | | | 506 |<-------------------| | | (4) 507 | | | | 508 | | | | 509 | INVITE | INVITE | INVITE | 510 | + Policy-Id | | + Policy-Contact| 511 |---------------->|--------------->|---------------->| (5) 512 | | | | 513 | | PS B | | 514 | | | | 515 | | | PolicyChannel | 516 | | | + InfoOffer | 517 | | |<-------------------| (6) 518 | | | PolicyChannel | 519 | | | + PolicyOffer | 520 | | |------------------->| (7) 521 | | | | 522 | | | | 523 | OK offer | OK offer | OK offer | 524 |<----------------|<---------------|<----------------| (8) 525 | | | | 526 | | | | 527 | PolicyChannel | | | 528 | + InfoOffer | | | 529 | + InfoAnswer | | | 530 |------------------->| | | (9) 531 | PolicyChannel | | | 532 | + PolicyOffer | | | 533 | + PolicyAnswer | | | 534 |<-------------------| | | (10) 535 | | | | 536 | ACK answer | 537 |--------------------------------------------------->| (11) 538 | | | | 539 | | | | 540 | | | PolicyChannel | 541 | | | + InfoAnswer | 542 | | |<-------------------| (12) 543 | | | PolicyChannel | 544 | | | + PolicyAnswer | 545 | | |------------------->| (13) 546 | | | | 548 4.4. UA/Policy Server Rendezvous 550 The first step in setting up session-specific policies is to 551 rendezvous the UAs with the relevant policy servers. This is 552 achieved by providing the URIs of all policy servers relevant for a 553 session to the UAs. 555 4.4.1. UAC Behavior 557 When a UA compliant to this specification generates an INVITE or 558 UPDATE request, it MUST include a Supported header field with the 559 option tag "policy" in the request. 561 A UAC may receive a 488 in response to an INVITE or UPDATE request, 562 which contains a Policy-Contact header field. This is a new header 563 defined in this specification that contains the URI of a policy 564 server. A 488 response with this header is generated by a proxy to 565 convey the URI of the local policy server to the UAC. The UAC SHOULD 566 use this URI to contact the policy server and ask for policies for 567 current session. The UAC SHOULD apply the policies received and 568 resend the updated request. 570 The UAC MUST a Policy-Id header into the updated request. The 571 Policy-Id header MUST include the URIs of all policy servers the UAC 572 has contacted during the processing of the request. The Policy-Id 573 header enables a proxy to determine whether the URI of its policy 574 server is already known to the UAC (and thus the request can be 575 passed through) or whether the URI still needs to be conveyed to the 576 UAC in a 488 response. 578 In some cases, a request may traverse multiple domains with session- 579 policies in place. Each of these domains may return a 488 response 580 containing a policy server URI. Since the UAC contacts the policy 581 server URI received in a 488 response before it resends the request, 582 session policies are always applied to a session in the order in 583 which the request traverses through these domains. The UAC SHOULD 584 NOT change this implicit order among policy servers. 586 Session policies may apply to the offer, the answer or both session 587 descriptions. Depending on the type of session policies, a UAC may 588 need to submit the offer and/or the answer to the policy server. If 589 offer and answer are submitted separately, they MUST be submitted to 590 the same policy servers. If the UAC receives an answer in the 591 response to an INVITE request (i.e. the request contained the offer), 592 it MUST send the ACK before retrieving the policies for the answer 593 from the policy server. If the UAC receives a response with an offer 594 (i.e. the INVITE request did not contain an offer), the UAC MUST 595 first contact the policy server to retrieve session policies and 596 apply these policies before sending the answer in the ACK. The 597 answer in the ACK will therefore already consider the relevant 598 policies. 600 This approach assumes that the policy server immediately responds 601 to a policy request and does not require manual intervention to 602 create a policy. A delay in the response from the policy server 603 would delay the transmission of the ACK and could trigger 604 retransmissions of the INVITE response (also see the 605 recommendations for Flow I in [10]). 607 4.4.2. Caching of Policy Server URIs 609 A UAC SHOULD cache the URI of the local policy server. It receives 610 this URI in a 488 from the proxy in the local domain. The UAC SHOULD 611 use this URI to retrieve session policies for a new INVITE or UPDATE 612 request before it is sent. Caching the local policy server URI 613 avoids the retransmission of this URI for each new INVITE or UPDATE 614 request. Domains can prevent the UAC from caching the local policy 615 server URI. This is useful, for example, if the policy server does 616 not need to be involved in all sessions or the policy server URI 617 changes from session to session. A proxy can mark the URI of such a 618 policy server as "non-cacheable". The UA SHOULD NOT cache a non- 619 cacheable policy server URI. It SHOULD remove the current URI from 620 the cache when receiving a "non-cacheable" URI. 622 The UAC SHOULD NOT cache policy server URIs it has received from 623 proxies outside of the local domain. These policy servers may not be 624 relevant for subsequent sessions, which may go to a different 625 destination and may traverse different domains. 627 The UAC SHOULD store the list of policy server URIs is has contacted 628 for a session. The UAC should keep this list until the session is 629 terminated. The UAC SHOULD contact the policy server URIs in this 630 list for each mid-dialog INVITE or UPDATE request. This avoids the 631 retransmission of policy server URIs for each mid-dialog requests. 633 4.4.3. UAS Behavior 635 An incoming INVITE or UPDATE request may contain a Policy-Contact 636 header with a list of policy server URIs. The UAS SHOULD use these 637 URIs to ask for session policies. The UAS MUST use the policy server 638 URIs in the order in which they were contained in the Policy-Contact 639 header, starting with the topmost value. 641 If the UAS receives an ACK with an answer, it may need to contact the 642 policy servers again depending on the policy type. In this case, it 643 MUST contact the same policy servers it has contacted for the offer. 645 4.4.4. Proxy Behavior 647 A proxy may provide the URI of the local policy server to the UAC or 648 the UAS when processing an INVITE or UPDATE request. 650 If an INVITE or UPDATE request contains a Supported header field with 651 the option tag "policy", the proxy MAY reject the request with a 488 652 response to provide the local policy server URI to the UAC. Before 653 rejecting a request, the proxy MUST check whether the request has a 654 Policy-Id header field that already contains this policy server URI. 655 If the request does not have such a header or the local policy server 656 URI is not present in that header, then the proxy MAY reject the 657 request with a 488. The proxy MUST insert a Policy-Contact header in 658 the 488 response that contains the URI of the local policy server. 659 The proxy MAY add the header field parameter "non-cacheable" to 660 prevent the UAC from caching this policy server URI. 662 If the local policy server URI is already present in the Policy-Id 663 header of an INVITE or UPDATE request, the proxy MUST NOT reject the 664 request as described above. The proxy SHOULD remove this policy 665 server URI from the Policy-Id header field before forwarding the 666 request. 668 The proxy MAY insert a Policy-Contact header field into an INVITE or 669 UPDATE request in order to convey the policy server URI to the UAS. 670 If the request already contains a Policy-Contact header field, the 671 proxy MUST insert the URI before all existing values at the beginning 672 of the list. A proxy MUST NOT change the order of existing Policy- 673 Contact header values. 675 4.4.5. Header Definition and Syntax 677 The Policy-Id header field is inserted into an INVITE or UPDATE 678 request by the UAC. It identifies all policy servers the UAC has 679 contacted for the request. A Policy-Id header value is the URI of a 680 policy server. 682 The syntax of the Policy-Id header field is: 684 Policy-Id = "Policy-Id" HCOLON absoluteURI 685 *(COMMA absoluteURI) 687 The Policy-Contact header field can be inserted into INVITE and 688 UPDATE requests by a proxy. It contains an ordered list of policy 689 server URIs that need to be contacted by the UAS. The UAS starts to 690 process the header field at the topmost value of this list. New 691 header field values are inserted at the top. The Policy-Contact 692 header field effectively forms a stack. The "non-cacheable" header 693 field parameter MUST NOT be used in a request. 695 The Policy-Contact header field can also be inserted into a 488 696 response to an INVITE or UPDATE request by a proxy. It contains a 697 policy server URI that needs to be contacted by the UAC. A proxy MAY 698 add the "non-cacheable" header field parameter to indicate that the 699 UAC should not cache the policy server URI. 701 The syntax of the Policy-Contact header field is: 703 Policy-Contact = "Policy-Contact" HCOLON policyURI 704 *(COMMA policyURI) 705 policyURI = absoluteURI [ SEMI "non-cacheable" ] 707 The BNF for absoluteURI is defined in [6]. 709 Table 1 is an extension of Tables 2 and 3 in [6]. The column 'UPD' 710 is for the UPDATE method [5]. 712 Header field where proxy ACK BYE CAN INV OPT REG UPD 713 _______________________________________________________________ 714 Policy-Id R rd - - - o - - o 715 Policy-Contact R a - - - o - - o 716 Policy-Contact 488 a - - - o - - o 717 Table 1: Policy-Id and Policy-Contact Header Fields 719 4.5. Policy Channel 721 The main task of the policy channel is to enable the transmission of 722 session descriptions (i.e. the offer and the answer) of a session to 723 the policy server and to transmit the resulting session policies back 724 to the UA. 726 A UA uses the "session-spec-policy" event package [2] to subscribe to 727 session-specific policies on a policy server. The UA receives the 728 policies that apply to a session through this subscription. The 729 policy server returns the initial policies for a session when the 730 subscription is established and may notify the UA when there are 731 updates to these policies. 733 When a UA receives a policy update, it SHOULD apply the update to the 734 current session. Typically, this will require the UA to generate a 735 re-INVITE or UPDATE message and re-negotiate the session description. 736 For example, if a policy update disallows the use of video and video 737 is part of the current session description, then the UA will need to 738 create an new session description offer without video. After 739 receiving this offer, the peer UA knows that video can't be used any 740 more and responds with the corresponding answer. 742 Before a policy server can generate a session-specific policy, it 743 needs to receive the session descriptions of a session. 745 The session-spec-policy event package enables a UA to include the 746 session descriptions in the body of the SUBSCRIBE request (see [2]). 747 These session descriptions are used by the policy server to generate 748 the session policies the UA is subscribing to. The policy server 749 returns these policies in NOTIFY messages. Detailed call flows can 750 be found in Appendix B. 752 An alternative approach is using the SUBSCRIBE and PUBLISH methods. 754 A UA inserts the session descriptions into the body of a PUBLISH 755 request and sends it to the policy server. After publishing the 756 session descriptions, the UA uses the session-spec-policy event 757 package to subscribe to the resulting session policies. 759 The PUBLISH requests use a new event package for session descriptions 760 [needs to be defined]. The published session descriptions establish 761 a state on the policy server. The policy server uses this state as 762 input to generate session policies for the described session. These 763 policies form a separate state on the policy server, to which the UA 764 can subscribe to using the session-spec-policy event package. This 765 effectively decouples the transmission of session descriptions (via 766 PUBLISH requests) from the transmission of session policies (through 767 the subscription). PUBLISH and SUBSCRIBE requests for the same 768 session use identical Request-URIs and event parameters so that a 769 policy server can correlate both. Detailed call flows can be found 770 in Appendix B. 772 OPEN ISSUE: Need to select one approach for conveying session 773 descriptions to the policy server!! The following provides an 774 short analysis of both approaches. Call flows can be found in 775 Appendix B. 776 PUBLISH and SUBSCRIBE: 777 * Session descriptions can in some cases be provided by an entity 778 that is different from the subscriber to session policies (e.g. 779 by a proxy). However, there are limitations to this usage 780 since many call flows require that session descriptions are 781 submitted to the policy server at a point when they are only 782 known to the UA. Thus, in many call flows this separation is 783 not feasible. 784 * PUBLISH and SUBSCRIBE both establish their own soft states in 785 the policy server. Thus, there are two states that need to be 786 maintained by the policy server and both need to be refreshed 787 individually. 788 * This approach requires the implementation of two event packages 789 by UA and policy server. 790 SUBSCRIBE: 791 * Using SUBSCRIBE simplifies the message flow between UA and 792 policy server. In a simple session (offer in INVITE, no state 793 refreshes) there are four messages less to be transmitted. 794 * No need to establish, maintain and refresh two different states 795 on the policy server. This simplifies UA and policy server 796 implementation. 797 * Session descriptions are directly coupled to a subscription to 798 policies. There is no need to correlate two states on the 799 policy server. Also, no need to cover cases in which session 800 descriptions are published without a policy subscription and 801 vice versa. 802 * Only one event package needs to be implemented by UA and the 803 policy server. 804 * SUBSCRIBE bodies usually have the semantic of a filter 805 criteria. I.e. they are used to select the resource the 806 subscription is for out of a set of existing objects. Here, 807 SUBSCRIBE bodies are used to as input to generate the resource 808 the subscription is for. This is a change in the use of 809 SUBSCRIBE bodies. 811 5. Security Considerations 813 In particular authentication and authorization are critical issues 814 that need to be addressed here. 816 [TBD.] 818 6. IANA Considerations 820 [TBD.] 822 Appendix A. Acknowledgements 824 Many thanks to Allison Mankin for the discussions and the suggestions 825 for this draft. Many thanks also to everyone who contributed by 826 providing feedback on the mailing list and in IETF meetings. 828 Appendix B. Call Flows 830 The following call flows illustrate the overall operation of session- 831 specific policies using PUBLISH/SUBSCRIBE and SUBSCRIBE only. The 832 call flows contain all messages needed for UA/policy server 833 rendezvous and for the policy channel. The following abbreviations 834 are used: 836 o: offer 837 o': offer modified by a policy 838 po: offer policy 839 a: answer 840 a': answer modified by a policy 841 pa: answer policy 842 ps uri: policy server URI (in Policy-Contact header) 843 ps id: policy server id (in Policy-Id header) 845 B.1. PUBLISH/SUBSCRIBE - Offer in Invite 847 UA A P A PS A PS B P B UA B 848 | | | | | | 849 |(1) INV | | | | 850 |-------->| | | | | 851 |(2) 488 | | | | 852 |<--------| | | | | 853 |(3) ACK | | | | | 854 |-------->| | | | | 855 |(4) PUBLISH | | | | 856 |------------------>| | | | 857 |(5) 200 OK | | | | 858 |<------------------| | | | 859 |(6) SUBSCRIBE | | | | 860 |------------------>| | | | 861 |(7) 200 OK | | | | 862 |<------------------| | | | 863 |(8) NOTIFY | | | | 864 |<------------------| | | | 865 |(9) 200 OK | | | | 866 |------------------>| | | | 867 |(10) INV | | | 868 |-------->| | | | | 869 | |(11) INV | | | 870 | |---------------------------->| | 871 | | | | |(12) INV 872 | | | | |-------->| 873 | | | |(13) PUBLISH 874 | | | |<------------------| 875 | | | |(14) 200 OK | 876 | | | |------------------>| 877 | | | |(15) SUBSCRIBE | 878 | | | |<------------------| 879 | | | |(16) 200 OK | 880 | | | |------------------>| 881 | | | |(17) NOTIFY 882 | | | |------------------>| 883 | | | |(18) 200 OK | 884 | | | |<------------------| 885 | | | | |(19) 200 OK 886 | | | | |<--------| 887 | |(20) 200 OK | | | 888 | |<----------------------------| | 889 |(21) 200 OK | | | | 890 |<--------| | | | | 891 |(22) ACK | | | | | 892 |------------------------------------------------>| 893 |(23) PUBLISH | | | | 894 |------------------>| | | | 895 |(24) 200 OK | | | | 896 |<------------------| | | | 897 |(25) NOTIFY | | | | 898 |<------------------| | | | 899 |(26) 200 OK | | | | 900 |------------------>| | | | 901 | | | | | | 902 | | | | | | 904 B.2. PUBLISH/SUBSCRIBE - Offer in Response 905 UA A P A PS A PS B P B UA B 906 | | | | | | 907 |(1) INV | | | | | 908 |-------->| | | | | 909 |(2) 488 | | | | 910 |<--------| | | | | 911 |(3) ACK | | | | | 912 |-------->| | | | | 913 |(4) SUBSCRIBE | | | | 914 |------------------>| | | | 915 |(5) 200 OK | | | | 916 |<------------------| | | | 917 |(6) NOTIFY | | | | 918 |<------------------| | | | 919 |(7) 200 OK | | | | 920 |------------------>| | | | 921 |(8) INV | | | | 922 |-------->| | | | | 923 | |(9) INV | | | | 924 | |---------------------------->| | 925 | | | | |(10) INV 926 | | | | |-------->| 927 | | | |(11) PUBLISH | 928 | | | |<------------------| 929 | | | |(12) 200 OK | 930 | | | |------------------>| 931 | | | |(13) SUBSCRIBE | 932 | | | |<------------------| 933 | | | |(14) 200 OK | 934 | | | |------------------>| 935 | | | |(15) NOTIFY | 936 | | | |------------------>| 937 | | | |(16) 200 OK | 938 | | | |<------------------| 939 | | | | |(17) 200 OK 940 | | | | |<--------| 941 | |(18) 200 OK | | | 942 | |<----------------------------| | 943 |(19) 200 OK | | | | 944 |<--------| | | | | 945 |(20) PUBLISH | | | 946 |------------------>| | | | 947 |(21) 200 OK | | | | 948 |<------------------| | | | 949 |(22) NOTIFY | | | 950 |<------------------| | | | 951 |(23) 200 OK | | | | 952 |------------------>| | | | 953 |(24) ACK | | | | 954 |------------------------------------------------>| 955 | | | |(25) PUBLISH | 956 | | | |<------------------| 957 | | | |(26) 200 OK | 958 | | | |------------------>| 959 | | | |(27) NOTIFY 960 | | | |------------------>| 961 | | | |(28) 200 OK | 962 | | | |<------------------| 963 | | | | | | 964 | | | | | | 966 B.3. SUBSCRIBE - Offer in Invite 967 UA A P A PS A PS B P B UA B 968 | | | | | | 969 |(1) INV | | | | 970 |-------->| | | | | 971 |(2) 488 | | | | 972 |<--------| | | | | 973 |(3) ACK | | | | | 974 |-------->| | | | | 975 |(4) SUBSCRIBE | | | | 976 |------------------>| | | | 977 |(5) 200 OK | | | | 978 |<------------------| | | | 979 |(6) NOTIFY | | | | 980 |<------------------| | | | 981 |(7) 200 OK | | | | 982 |------------------>| | | | 983 |(8) INV | | | | 984 |-------->| | | | | 985 | |(9) INV | | | 986 | |---------------------------->| | 987 | | | | |(10) INV 988 | | | | |-------->| 989 | | | |(11) SUBSCRIBE 990 | | | |<------------------| 991 | | | |(12) 200 OK | 992 | | | |------------------>| 993 | | | |(13) NOTIFY 994 | | | |------------------>| 995 | | | |(14) 200 OK | 996 | | | |<------------------| 997 | | | | |(15) 200 OK 998 | | | | |<--------| 999 | |(16) 200 OK | | | 1000 | |<----------------------------| | 1001 |(17) 200 OK | | | | 1002 |<--------| | | | | 1003 |(18) ACK | | | | | 1004 |------------------------------------------------>| 1005 |(19) SUBSCRIBE | | | 1006 |------------------>| | | | 1007 |(20) 200 OK | | | | 1008 |<------------------| | | | 1009 |(21) NOTIFY | | | | 1010 |<------------------| | | | 1011 |(22) 200 OK | | | | 1012 |------------------>| | | | 1013 | | | | | | 1014 | | | | | | 1016 B.4. SUBSCRIBE - Offer in Response 1018 UA A P A PS A PS B P B UA B 1019 | | | | | | 1020 |(1) INV | | | | | 1021 |-------->| | | | | 1022 |(2) 488 | | | | 1023 |<--------| | | | | 1024 |(3) ACK | | | | | 1025 |-------->| | | | | 1026 |(4) SUBSCRIBE | | | | 1027 |------------------>| | | | 1028 |(5) 200 OK | | | | 1029 |<------------------| | | | 1030 |(6) NOTIFY | | | | 1031 |<------------------| | | | 1032 |(7) 200 OK | | | | 1033 |------------------>| | | | 1034 |(8) INV | | | | 1035 |-------->| | | | | 1036 | |(9) INV | | | | 1037 | |---------------------------->| | 1038 | | | | |(10) INV 1039 | | | | |-------->| 1040 | | | |(11) SUBSCRIBE | 1041 | | | |<------------------| 1042 | | | |(12) 200 OK | 1043 | | | |------------------>| 1044 | | | |(13) NOTIFY | 1045 | | | |------------------>| 1046 | | | |(14) 200 OK | 1047 | | | |<------------------| 1048 | | | | |(15) 200 OK 1049 | | | | |<--------| 1050 | |(16) 200 OK | | | 1051 | |<----------------------------| | 1052 |(17) 200 OK | | | | 1053 |<--------| | | | | 1054 |(18) SUBSCRIBE | | | 1055 |------------------>| | | | 1056 |(19) 200 OK | | | | 1057 |<------------------| | | | 1058 |(20) NOTIFY | | | 1059 |<------------------| | | | 1060 |(21) 200 OK | | | | 1061 |------------------>| | | | 1062 |(22) ACK | | | | 1063 |------------------------------------------------>| 1064 | | | |(23) SUBSCRIBE 1065 | | | |<------------------| 1066 | | | |(24) 200 OK | 1067 | | | |------------------>| 1068 | | | |(25) NOTIFY 1069 | | | |------------------>| 1070 | | | |(26) 200 OK | 1071 | | | |<------------------| 1072 | | | | | | 1073 | | | | | | 1075 7. References 1077 7.1. Normative References 1079 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1080 Levels", BCP 14, RFC 2119, March 1997. 1082 [2] Hilt, V. and G. Camarillo, "A Session Initiation Protocol (SIP) 1083 Event Package for Session-Specific Session Policies.", 1084 draft-hilt-sipping-session-policy-package-01 (work in progress), 1085 March 2006. 1087 [3] Hilt, V., Camarillo, G., and J. Rosenberg, "A User Agent Profile 1088 Data Set for Media Policy", 1089 draft-hilt-sipping-media-policy-dataset-01 (work in progress), 1090 March 2006. 1092 [4] Petrie, D., "A Framework for Session Initiation Protocol User 1093 Agent Profile Delivery", draft-ietf-sipping-config-framework-07 1094 (work in progress), July 2005. 1096 [5] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE 1097 Method", RFC 3311, October 2002. 1099 [6] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1100 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 1101 Session Initiation Protocol", RFC 3261, June 2002. 1103 7.2. Informative References 1105 [7] Handley, M. and V. Jacobson, "SDP: Session Description 1106 Protocol", RFC 2327, April 1998. 1108 [8] Hilt, V. and G. Camarillo, "Use Cases for Session-Specific 1109 Session Initiation Protocol (SIP) Session Policies", 1110 draft-hilt-sipping-policy-usecases-00 (work in progress), 1111 June 2005. 1113 [9] Petrie, D., Lawrence, S., Dolly, M., and V. Hilt, "A Schema and 1114 Guidelines for Defining Session Initiation Protocol User Agent 1115 Profile Data Sets", draft-petrie-sipping-profile-datasets-02 1116 (work in progress), October 2005. 1118 [10] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, 1119 "Best Current Practices for Third Party Call Control (3pcc) in 1120 the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, 1121 April 2004. 1123 Authors' Addresses 1125 Volker Hilt 1126 Bell Labs/Lucent Technologies 1127 101 Crawfords Corner Rd 1128 Holmdel, NJ 07733 1129 USA 1131 Email: volkerh@bell-labs.com 1133 Gonzalo Camarillo 1134 Ericsson 1135 Hirsalantie 11 1136 Jorvas 02420 1137 Finland 1139 Email: Gonzalo.Camarillo@ericsson.com 1141 Jonathan Rosenberg 1142 Cisco Systems 1143 600 Lanidex Plaza 1144 Parsippany, NJ 07054 1145 USA 1147 Email: jdrosen@cisco.com 1149 Intellectual Property Statement 1151 The IETF takes no position regarding the validity or scope of any 1152 Intellectual Property Rights or other rights that might be claimed to 1153 pertain to the implementation or use of the technology described in 1154 this document or the extent to which any license under such rights 1155 might or might not be available; nor does it represent that it has 1156 made any independent effort to identify any such rights. Information 1157 on the procedures with respect to rights in RFC documents can be 1158 found in BCP 78 and BCP 79. 1160 Copies of IPR disclosures made to the IETF Secretariat and any 1161 assurances of licenses to be made available, or the result of an 1162 attempt made to obtain a general license or permission for the use of 1163 such proprietary rights by implementers or users of this 1164 specification can be obtained from the IETF on-line IPR repository at 1165 http://www.ietf.org/ipr. 1167 The IETF invites any interested party to bring to its attention any 1168 copyrights, patents or patent applications, or other proprietary 1169 rights that may cover technology that may be required to implement 1170 this standard. Please address the information to the IETF at 1171 ietf-ipr@ietf.org. 1173 Disclaimer of Validity 1175 This document and the information contained herein are provided on an 1176 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1177 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1178 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1179 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1180 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1181 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1183 Copyright Statement 1185 Copyright (C) The Internet Society (2006). This document is subject 1186 to the rights, licenses and restrictions contained in BCP 78, and 1187 except as set forth therein, the authors retain all their rights. 1189 Acknowledgment 1191 Funding for the RFC Editor function is currently provided by the 1192 Internet Society.