idnits 2.17.1 draft-ietf-sipping-session-policy-framework-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1193. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1170. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1177. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1183. ** 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 719 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 (April 4, 2006) is 6597 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-ietf-sipping-session-policy-package - is the name correct? -- Possible downref: Normative reference to a draft: ref. '2' == Outdated reference: A later version (-16) exists of draft-ietf-sipping-media-policy-dataset-01 == Outdated reference: A later version (-18) exists of draft-ietf-sipping-config-framework-08 -- 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-03 Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 10 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: October 6, 2006 G. Camarillo 5 Ericsson 6 J. Rosenberg 7 Cisco Systems 8 April 4, 2006 10 A Framework for Session Initiation Protocol (SIP) Session Policies 11 draft-ietf-sipping-session-policy-framework-00 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 October 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 . . . . . . . . . . . . . . . . . . . 19 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 . . . . . . . . . . 21 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 insert 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. 590 If the UAC receives an answer in the response to an INVITE request 591 (i.e. the request contained the offer), it MUST send the ACK before 592 retrieving the policies for the answer from the policy server. If 593 the UAC receives a response with an offer (i.e. the INVITE request 594 did not contain an offer), the UAC MUST first contact the policy 595 server to retrieve session policies and apply these policies before 596 sending the answer in the ACK. The answer in the ACK will therefore 597 already consider the relevant policies. 599 This approach assumes that the policy server immediately responds 600 to a policy request and does not require manual intervention to 601 create a policy. A delay in the response from the policy server 602 would delay the transmission of the ACK and could trigger 603 retransmissions of the INVITE response (also see the 604 recommendations for Flow I in [10]). 606 4.4.2. Caching of Policy Server URIs 608 A UAC SHOULD cache the URI of the policy server in the local domain. 609 It may receive this URI in a 488 from the local proxy after sending 610 an INVITE message. The UA may also receive an initial local policy 611 server URI through configuration or other means. This way, it can be 612 avoided that the local proxy needs to reject the first INVITE in 613 order to initialize the UAs policy server URI cache. A policy server 614 URI received through configuration can, of course, be overwritten by 615 a policy server URI in a 488 response. 617 The UAC SHOULD use the cached policy server URI to retrieve session 618 policies for a new INVITE or UPDATE request before it is sent. 619 Caching the local policy server URI avoids the retransmission of this 620 URI for each new INVITE or UPDATE request. Domains can prevent the 621 UAC from caching the local policy server URI. This is useful, for 622 example, if the policy server does not need to be involved in all 623 sessions or the policy server URI changes from session to session. A 624 proxy can mark the URI of such a policy server as "non-cacheable". 625 The UA SHOULD NOT cache a non-cacheable policy server URI. It SHOULD 626 remove the current URI from the cache when receiving a "non- 627 cacheable" URI. 629 The UAC SHOULD NOT cache policy server URIs it has received from 630 proxies outside of the local domain. These policy servers may not be 631 relevant for subsequent sessions, which may go to a different 632 destination, traversing different domains. 634 The UAC SHOULD store the list of policy server URIs is has contacted 635 for a session. The UAC should keep this list until the session is 636 terminated. The UAC SHOULD contact the policy server URIs in this 637 list for each mid-dialog INVITE or UPDATE request. This avoids the 638 retransmission of policy server URIs for each mid-dialog requests. 640 4.4.3. UAS Behavior 642 An incoming INVITE or UPDATE request may contain a Policy-Contact 643 header with a list of policy server URIs. The UAS SHOULD use these 644 URIs to ask for session policies. The UAS MUST use the policy server 645 URIs in the order in which they were contained in the Policy-Contact 646 header, starting with the topmost value. 648 If the UAS receives an ACK with an answer, it may need to contact the 649 policy servers again depending on the policy type. In this case, it 650 MUST contact the same policy servers it has contacted for the offer. 652 4.4.4. Proxy Behavior 654 A proxy may provide the URI of the local policy server to the UAC or 655 the UAS when processing an INVITE or UPDATE request. 657 If an INVITE or UPDATE request contains a Supported header field with 658 the option tag "policy", the proxy MAY reject the request with a 488 659 response to provide the local policy server URI to the UAC. Before 660 rejecting a request, the proxy MUST check whether the request has a 661 Policy-Id header field that already contains this policy server URI. 662 If the request does not have such a header or the local policy server 663 URI is not present in that header, then the proxy MAY reject the 664 request with a 488. The proxy MUST insert a Policy-Contact header in 665 the 488 response that contains the URI of the local policy server. 666 The proxy MAY add the header field parameter "non-cacheable" to 667 prevent the UAC from caching this policy server URI. 669 If the local policy server URI is already present in the Policy-Id 670 header of an INVITE or UPDATE request, the proxy MUST NOT reject the 671 request as described above. The proxy SHOULD remove this policy 672 server URI from the Policy-Id header field before forwarding the 673 request. 675 The proxy MAY insert a Policy-Contact header field into an INVITE or 676 UPDATE request in order to convey the policy server URI to the UAS. 677 If the request already contains a Policy-Contact header field, the 678 proxy MUST insert the URI before all existing values at the beginning 679 of the list. A proxy MUST NOT change the order of existing Policy- 680 Contact header values. 682 4.4.5. Header Definition and Syntax 684 The Policy-Id header field is inserted into an INVITE or UPDATE 685 request by the UAC. It identifies all policy servers the UAC has 686 contacted for the request. A Policy-Id header value is the URI of a 687 policy server. 689 The syntax of the Policy-Id header field is: 691 Policy-Id = "Policy-Id" HCOLON absoluteURI 692 *(COMMA absoluteURI) 694 The Policy-Contact header field can be inserted into INVITE and 695 UPDATE requests by a proxy. It contains an ordered list of policy 696 server URIs that need to be contacted by the UAS. The UAS starts to 697 process the header field at the topmost value of this list. New 698 header field values are inserted at the top. The Policy-Contact 699 header field effectively forms a stack. The "non-cacheable" header 700 field parameter MUST NOT be used in a request. 702 The Policy-Contact header field can also be inserted into a 488 703 response to an INVITE or UPDATE request by a proxy. It contains a 704 policy server URI that needs to be contacted by the UAC. A proxy MAY 705 add the "non-cacheable" header field parameter to indicate that the 706 UAC should not cache the policy server URI. 708 The syntax of the Policy-Contact header field is: 710 Policy-Contact = "Policy-Contact" HCOLON policyURI 711 *(COMMA policyURI) 712 policyURI = absoluteURI [ SEMI "non-cacheable" ] 714 The BNF for absoluteURI is defined in [6]. 716 Table 1 is an extension of Tables 2 and 3 in [6]. The column 'UPD' 717 is for the UPDATE method [5]. 719 Header field where proxy ACK BYE CAN INV OPT REG UPD 720 _______________________________________________________________ 721 Policy-Id R rd - - - o - - o 722 Policy-Contact R a - - - o - - o 723 Policy-Contact 488 a - - - o - - o 724 Table 1: Policy-Id and Policy-Contact Header Fields 726 4.5. Policy Channel 728 The main task of the policy channel is to enable the transmission of 729 session descriptions (i.e. the offer and the answer) of a session to 730 the policy server and to transmit the resulting session policies back 731 to the UA. 733 A UA uses the "session-spec-policy" event package [2] to subscribe to 734 session-specific policies on a policy server. The UA receives the 735 policies that apply to a session through this subscription. The 736 policy server returns the initial policies for a session when the 737 subscription is established and may notify the UA when there are 738 updates to these policies. 740 When a UA receives a policy update, it SHOULD apply the update to the 741 current session. Typically, this will require the UA to generate a 742 re-INVITE or UPDATE message and re-negotiate the session description. 743 For example, if a policy update disallows the use of video and video 744 is part of the current session description, then the UA will need to 745 create an new session description offer without video. After 746 receiving this offer, the peer UA knows that video can't be used any 747 more and responds with the corresponding answer. 749 Before a policy server can generate a session-specific policy, it 750 needs to receive the session descriptions of a session. 752 The session-spec-policy event package enables a UA to include the 753 session descriptions in the body of the SUBSCRIBE request (see [2]). 754 These session descriptions are used by the policy server to generate 755 the session policies the UA is subscribing to. The policy server 756 returns these policies in NOTIFY messages. Detailed call flows can 757 be found in Appendix B. 759 An alternative approach is using the SUBSCRIBE and PUBLISH methods. 761 A UA inserts the session descriptions into the body of a PUBLISH 762 request and sends it to the policy server. After publishing the 763 session descriptions, the UA uses the session-spec-policy event 764 package to subscribe to the resulting session policies. 766 The PUBLISH requests use a new event package for session descriptions 768 [needs to be defined]. The published session descriptions establish 769 a state on the policy server. The policy server uses this state as 770 input to generate session policies for the described session. These 771 policies form a separate state on the policy server, to which the UA 772 can subscribe to using the session-spec-policy event package. This 773 effectively decouples the transmission of session descriptions (via 774 PUBLISH requests) from the transmission of session policies (through 775 the subscription). PUBLISH and SUBSCRIBE requests for the same 776 session use identical Request-URIs and event parameters so that a 777 policy server can correlate both. Detailed call flows can be found 778 in Appendix B. 780 OPEN ISSUE: Need to select one approach for conveying session 781 descriptions to the policy server!! The following provides an 782 short analysis of both approaches. Call flows can be found in 783 Appendix B. 784 PUBLISH and SUBSCRIBE: 785 * Session descriptions can in some cases be submitted to the 786 policy server by an entity that is different from the entity 787 that subscribes to session policies (e.g. by a proxy). 788 However, the separation of session description sender and 789 policy receiver may lead to deadlocks in some scenarios. This 790 may occur if the subscriber to session policies (e.g. the UA) 791 is waiting for a policy but the entity responsible for 792 submitting session descriptions (e.g. the proxy) can't submit 793 the necessary session descriptions because it has not yet 794 received them. 795 * PUBLISH and SUBSCRIBE both establish their own soft states in 796 the policy server. Thus, there are two states that need to be 797 maintained by the policy server and both need to be refreshed 798 individually. 799 * This approach requires the implementation of two event packages 800 by UA and policy server. 801 SUBSCRIBE: 802 * Using SUBSCRIBE simplifies the message flow between UA and 803 policy server. In a simple session (offer in INVITE, no state 804 refreshes) there are four messages less to be transmitted. 805 * No need to establish, maintain and refresh two different states 806 on the policy server. This simplifies UA and policy server 807 implementation. 808 * Session descriptions are directly coupled to a subscription to 809 policies. There is no need to correlate two states on the 810 policy server. Also, no need to cover cases in which session 811 descriptions are published without a policy subscription and 812 vice versa. 813 * Only one event package needs to be implemented by UA and the 814 policy server. 816 * SUBSCRIBE bodies usually have the semantic of a filter 817 criteria. I.e. they are used to select the resource the 818 subscription is for out of a set of existing objects. Here, 819 SUBSCRIBE bodies are used to as input to generate the resource 820 the subscription is for. This is a change in the use of 821 SUBSCRIBE bodies. 823 5. Security Considerations 825 In particular authentication and authorization are critical issues 826 that need to be addressed here. 828 [TBD.] 830 6. IANA Considerations 832 [TBD.] 834 Appendix A. Acknowledgements 836 Many thanks to Allison Mankin for the discussions and the suggestions 837 for this draft. Many thanks also to everyone who contributed by 838 providing feedback on the mailing list and in IETF meetings. 840 Appendix B. Call Flows 842 The following call flows illustrate the overall operation of session- 843 specific policies using PUBLISH/SUBSCRIBE and SUBSCRIBE only. The 844 call flows contain all messages needed for UA/policy server 845 rendezvous and for the policy channel. The following abbreviations 846 are used: 848 o: offer 849 o': offer modified by a policy 850 po: offer policy 851 a: answer 852 a': answer modified by a policy 853 pa: answer policy 854 ps uri: policy server URI (in Policy-Contact header) 855 ps id: policy server id (in Policy-Id header) 857 B.1. PUBLISH/SUBSCRIBE - Offer in Invite 858 UA A P A PS A PS B P B UA B 859 | | | | | | 860 |(1) INV | | | | 861 |-------->| | | | | 862 |(2) 488 | | | | 863 |<--------| | | | | 864 |(3) ACK | | | | | 865 |-------->| | | | | 866 |(4) PUBLISH | | | | 867 |------------------>| | | | 868 |(5) 200 OK | | | | 869 |<------------------| | | | 870 |(6) SUBSCRIBE | | | | 871 |------------------>| | | | 872 |(7) 200 OK | | | | 873 |<------------------| | | | 874 |(8) NOTIFY | | | | 875 |<------------------| | | | 876 |(9) 200 OK | | | | 877 |------------------>| | | | 878 |(10) INV | | | 879 |-------->| | | | | 880 | |(11) INV | | | 881 | |---------------------------->| | 882 | | | | |(12) INV 883 | | | | |-------->| 884 | | | |(13) PUBLISH 885 | | | |<------------------| 886 | | | |(14) 200 OK | 887 | | | |------------------>| 888 | | | |(15) SUBSCRIBE | 889 | | | |<------------------| 890 | | | |(16) 200 OK | 891 | | | |------------------>| 892 | | | |(17) NOTIFY 893 | | | |------------------>| 894 | | | |(18) 200 OK | 895 | | | |<------------------| 896 | | | | |(19) 200 OK 897 | | | | |<--------| 898 | |(20) 200 OK | | | 899 | |<----------------------------| | 900 |(21) 200 OK | | | | 901 |<--------| | | | | 902 |(22) ACK | | | | | 903 |------------------------------------------------>| 904 |(23) PUBLISH | | | | 905 |------------------>| | | | 906 |(24) 200 OK | | | | 907 |<------------------| | | | 908 |(25) NOTIFY | | | | 909 |<------------------| | | | 910 |(26) 200 OK | | | | 911 |------------------>| | | | 912 | | | | | | 913 | | | | | | 915 B.2. PUBLISH/SUBSCRIBE - Offer in Response 917 UA A P A PS A PS B P B UA B 918 | | | | | | 919 |(1) INV | | | | | 920 |-------->| | | | | 921 |(2) 488 | | | | 922 |<--------| | | | | 923 |(3) ACK | | | | | 924 |-------->| | | | | 925 |(4) SUBSCRIBE | | | | 926 |------------------>| | | | 927 |(5) 200 OK | | | | 928 |<------------------| | | | 929 |(6) NOTIFY | | | | 930 |<------------------| | | | 931 |(7) 200 OK | | | | 932 |------------------>| | | | 933 |(8) INV | | | | 934 |-------->| | | | | 935 | |(9) INV | | | | 936 | |---------------------------->| | 937 | | | | |(10) INV 938 | | | | |-------->| 939 | | | |(11) PUBLISH | 940 | | | |<------------------| 941 | | | |(12) 200 OK | 942 | | | |------------------>| 943 | | | |(13) SUBSCRIBE | 944 | | | |<------------------| 945 | | | |(14) 200 OK | 946 | | | |------------------>| 947 | | | |(15) NOTIFY | 948 | | | |------------------>| 949 | | | |(16) 200 OK | 950 | | | |<------------------| 951 | | | | |(17) 200 OK 952 | | | | |<--------| 953 | |(18) 200 OK | | | 954 | |<----------------------------| | 955 |(19) 200 OK | | | | 956 |<--------| | | | | 957 |(20) PUBLISH | | | 958 |------------------>| | | | 959 |(21) 200 OK | | | | 960 |<------------------| | | | 961 |(22) NOTIFY | | | 962 |<------------------| | | | 963 |(23) 200 OK | | | | 964 |------------------>| | | | 965 |(24) ACK | | | | 966 |------------------------------------------------>| 967 | | | |(25) PUBLISH | 968 | | | |<------------------| 969 | | | |(26) 200 OK | 970 | | | |------------------>| 971 | | | |(27) NOTIFY 972 | | | |------------------>| 973 | | | |(28) 200 OK | 974 | | | |<------------------| 975 | | | | | | 976 | | | | | | 978 B.3. SUBSCRIBE - Offer in Invite 979 UA A P A PS A PS B P B UA B 980 | | | | | | 981 |(1) INV | | | | 982 |-------->| | | | | 983 |(2) 488 | | | | 984 |<--------| | | | | 985 |(3) ACK | | | | | 986 |-------->| | | | | 987 |(4) SUBSCRIBE | | | | 988 |------------------>| | | | 989 |(5) 200 OK | | | | 990 |<------------------| | | | 991 |(6) NOTIFY | | | | 992 |<------------------| | | | 993 |(7) 200 OK | | | | 994 |------------------>| | | | 995 |(8) INV | | | | 996 |-------->| | | | | 997 | |(9) INV | | | 998 | |---------------------------->| | 999 | | | | |(10) INV 1000 | | | | |-------->| 1001 | | | |(11) SUBSCRIBE 1002 | | | |<------------------| 1003 | | | |(12) 200 OK | 1004 | | | |------------------>| 1005 | | | |(13) NOTIFY 1006 | | | |------------------>| 1007 | | | |(14) 200 OK | 1008 | | | |<------------------| 1009 | | | | |(15) 200 OK 1010 | | | | |<--------| 1011 | |(16) 200 OK | | | 1012 | |<----------------------------| | 1013 |(17) 200 OK | | | | 1014 |<--------| | | | | 1015 |(18) ACK | | | | | 1016 |------------------------------------------------>| 1017 |(19) SUBSCRIBE | | | 1018 |------------------>| | | | 1019 |(20) 200 OK | | | | 1020 |<------------------| | | | 1021 |(21) NOTIFY | | | | 1022 |<------------------| | | | 1023 |(22) 200 OK | | | | 1024 |------------------>| | | | 1025 | | | | | | 1026 | | | | | | 1028 B.4. SUBSCRIBE - Offer in Response 1030 UA A P A PS A PS B P B UA B 1031 | | | | | | 1032 |(1) INV | | | | | 1033 |-------->| | | | | 1034 |(2) 488 | | | | 1035 |<--------| | | | | 1036 |(3) ACK | | | | | 1037 |-------->| | | | | 1038 |(4) SUBSCRIBE | | | | 1039 |------------------>| | | | 1040 |(5) 200 OK | | | | 1041 |<------------------| | | | 1042 |(6) NOTIFY | | | | 1043 |<------------------| | | | 1044 |(7) 200 OK | | | | 1045 |------------------>| | | | 1046 |(8) INV | | | | 1047 |-------->| | | | | 1048 | |(9) INV | | | | 1049 | |---------------------------->| | 1050 | | | | |(10) INV 1051 | | | | |-------->| 1052 | | | |(11) SUBSCRIBE | 1053 | | | |<------------------| 1054 | | | |(12) 200 OK | 1055 | | | |------------------>| 1056 | | | |(13) NOTIFY | 1057 | | | |------------------>| 1058 | | | |(14) 200 OK | 1059 | | | |<------------------| 1060 | | | | |(15) 200 OK 1061 | | | | |<--------| 1062 | |(16) 200 OK | | | 1063 | |<----------------------------| | 1064 |(17) 200 OK | | | | 1065 |<--------| | | | | 1066 |(18) SUBSCRIBE | | | 1067 |------------------>| | | | 1068 |(19) 200 OK | | | | 1069 |<------------------| | | | 1070 |(20) NOTIFY | | | 1071 |<------------------| | | | 1072 |(21) 200 OK | | | | 1073 |------------------>| | | | 1074 |(22) ACK | | | | 1075 |------------------------------------------------>| 1076 | | | |(23) SUBSCRIBE 1077 | | | |<------------------| 1078 | | | |(24) 200 OK | 1079 | | | |------------------>| 1080 | | | |(25) NOTIFY 1081 | | | |------------------>| 1082 | | | |(26) 200 OK | 1083 | | | |<------------------| 1084 | | | | | | 1085 | | | | | | 1087 7. References 1089 7.1. Normative References 1091 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1092 Levels", BCP 14, RFC 2119, March 1997. 1094 [2] Hilt, V. and G. Camarillo, "A Session Initiation Protocol (SIP) 1095 Event Package for Session-Specific Session Policies.", 1096 draft-ietf-sipping-session-policy-package-00 (work in progress), 1097 April 2006. 1099 [3] Hilt, V., Camarillo, G., and J. Rosenberg, "A User Agent Profile 1100 Data Set for Media Policy", 1101 draft-ietf-sipping-media-policy-dataset-01 (work in progress), 1102 March 2006. 1104 [4] Petrie, D., "A Framework for Session Initiation Protocol User 1105 Agent Profile Delivery", draft-ietf-sipping-config-framework-08 1106 (work in progress), March 2006. 1108 [5] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE 1109 Method", RFC 3311, October 2002. 1111 [6] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1112 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 1113 Session Initiation Protocol", RFC 3261, June 2002. 1115 7.2. Informative References 1117 [7] Handley, M. and V. Jacobson, "SDP: Session Description 1118 Protocol", RFC 2327, April 1998. 1120 [8] Hilt, V. and G. Camarillo, "Use Cases for Session-Specific 1121 Session Initiation Protocol (SIP) Session Policies", 1122 draft-hilt-sipping-policy-usecases-00 (work in progress), 1123 June 2005. 1125 [9] Petrie, D., Lawrence, S., Dolly, M., and V. Hilt, "A Schema and 1126 Guidelines for Defining Session Initiation Protocol User Agent 1127 Profile Data Sets", draft-petrie-sipping-profile-datasets-03 1128 (work in progress), October 2005. 1130 [10] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, 1131 "Best Current Practices for Third Party Call Control (3pcc) in 1132 the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, 1133 April 2004. 1135 Authors' Addresses 1137 Volker Hilt 1138 Bell Labs/Lucent Technologies 1139 101 Crawfords Corner Rd 1140 Holmdel, NJ 07733 1141 USA 1143 Email: volkerh@bell-labs.com 1145 Gonzalo Camarillo 1146 Ericsson 1147 Hirsalantie 11 1148 Jorvas 02420 1149 Finland 1151 Email: Gonzalo.Camarillo@ericsson.com 1153 Jonathan Rosenberg 1154 Cisco Systems 1155 600 Lanidex Plaza 1156 Parsippany, NJ 07054 1157 USA 1159 Email: jdrosen@cisco.com 1161 Intellectual Property Statement 1163 The IETF takes no position regarding the validity or scope of any 1164 Intellectual Property Rights or other rights that might be claimed to 1165 pertain to the implementation or use of the technology described in 1166 this document or the extent to which any license under such rights 1167 might or might not be available; nor does it represent that it has 1168 made any independent effort to identify any such rights. Information 1169 on the procedures with respect to rights in RFC documents can be 1170 found in BCP 78 and BCP 79. 1172 Copies of IPR disclosures made to the IETF Secretariat and any 1173 assurances of licenses to be made available, or the result of an 1174 attempt made to obtain a general license or permission for the use of 1175 such proprietary rights by implementers or users of this 1176 specification can be obtained from the IETF on-line IPR repository at 1177 http://www.ietf.org/ipr. 1179 The IETF invites any interested party to bring to its attention any 1180 copyrights, patents or patent applications, or other proprietary 1181 rights that may cover technology that may be required to implement 1182 this standard. Please address the information to the IETF at 1183 ietf-ipr@ietf.org. 1185 Disclaimer of Validity 1187 This document and the information contained herein are provided on an 1188 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1189 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1190 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1191 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1192 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1193 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1195 Copyright Statement 1197 Copyright (C) The Internet Society (2006). This document is subject 1198 to the rights, licenses and restrictions contained in BCP 78, and 1199 except as set forth therein, the authors retain all their rights. 1201 Acknowledgment 1203 Funding for the RFC Editor function is currently provided by the 1204 Internet Society.