idnits 2.17.1 draft-ietf-sipping-policy-package-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 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 576. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 553. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 560. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 566. ** 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 == 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 6595 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) ** Obsolete normative reference: RFC 2246 (ref. '2') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2327 (ref. '4') (Obsoleted by RFC 4566) == Outdated reference: A later version (-18) exists of draft-ietf-sipping-config-framework-08 ** Obsolete normative reference: RFC 3265 (ref. '6') (Obsoleted by RFC 6665) == Outdated reference: A later version (-01) exists of draft-ietf-sipping-session-policy-framework-00 Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 7 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 April 4, 2006 8 A Session Initiation Protocol (SIP) Event Package for Session-Specific 9 Session Policies. 10 draft-ietf-sipping-policy-package-00 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on October 6, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 Abstract 43 This specification defines a Session Initiation Protocol (SIP) event 44 package for session-specific session policies. This event package 45 enables users to subscribe to the policies for a SIP session and to 46 receive notifications if the policies change. The package is part of 47 the Framework for SIP Session Policies. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3. Event Package Formal Definition . . . . . . . . . . . . . . . 4 54 3.1. Event Package Name . . . . . . . . . . . . . . . . . . . . 4 55 3.2. Event Package Parameters . . . . . . . . . . . . . . . . . 4 56 3.3. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 5 57 3.4. Subscription Duration . . . . . . . . . . . . . . . . . . 6 58 3.5. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 6 59 3.6. Subscriber generation of SUBSCRIBE requests . . . . . . . 7 60 3.7. Notifier processing of SUBSCRIBE requests . . . . . . . . 7 61 3.8. Notifier generation of NOTIFY requests . . . . . . . . . . 8 62 3.9. Subscriber processing of NOTIFY requests . . . . . . . . . 9 63 3.10. Handling of forked requests . . . . . . . . . . . . . . . 9 64 3.11. Rate of notifications . . . . . . . . . . . . . . . . . . 9 65 3.12. State Agents . . . . . . . . . . . . . . . . . . . . . . . 9 66 3.13. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 69 5.1. Event Package Name . . . . . . . . . . . . . . . . . . . . 10 70 5.2. Content-Disposition Types . . . . . . . . . . . . . . . . 10 71 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11 72 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 6.1. Normative References . . . . . . . . . . . . . . . . . . . 11 74 6.2. Informative References . . . . . . . . . . . . . . . . . . 12 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 76 Intellectual Property and Copyright Statements . . . . . . . . . . 14 78 1. Introduction 80 The Framework for Session Initiation Protocol (SIP) [7] Session 81 Policies [9] defines a protocol framework for the exchange of session 82 policy information between a network domain and a user agent. This 83 framework introduces two types of session policies: session-specific 84 policies and session-independent policies. Session-specific policies 85 are policies for one specific session. They are created based on the 86 session description of a session. Naturally, a user agent needs to 87 request session-specific policies on a session-by-session basis at 88 the time a session is created and the session description is known. 89 Session-independent policies on the other hand are policies that are 90 created independent of a session and generally apply to SIP sessions. 91 Since these policies are not based on a specific session description, 92 they can be created and conveyed to the user agent at any time. User 93 agents receive session-independent policies as part of their 94 configuration information [5]. 96 This specification defines a SIP event package [6] that enables user 97 agents to subscribe to session-specific policies. Session policies 98 can change while they are in effect. These changes can result, for 99 example, from changes in network conditions, the use of services, or 100 simply because a provider wants to revoke rights or grant additional 101 rights to a customer. 103 Setting up session-specific policies involves the following steps 104 (see [9]): 106 1. A user agent submits a session description to the policy server 107 and asks whether a session using this session description is 108 permissible. This request covers all aspects of the included 109 session description. For example, if the session description 110 contains a media line for video, the user agent implicitly asks 111 for permission to use video. 112 2. The policy server creates a policy decision for this particular 113 session and returns the decision to the user agent. Possible 114 policy decisions are to (1) deny the session, (2) propose changes 115 to the session description with which the session is acceptable, 116 or (3) accept the session as it was proposed. An example for a 117 policy decision is to disallow the use of video but agree to all 118 other aspects of the proposed session. 119 3. The policy server can update the policy decision at any time. A 120 policy decision update can, for example, propose additional 121 changes to the session description (e.g. change the allowed 122 codecs) or deny a previously accepted session (e.g. disallow the 123 continuation of a session). 125 4. The user agent applies the policy decision to the session it is 126 establishing or managing. 128 The session-specific policy event package defined in this document 129 enables a user agent to subscribe to session-specific policies based 130 on this model. In this event package, the resource the subscriber is 131 subscribing to is created at the time the subscription is 132 established. The notifier takes information from the SUBSCRIBE 133 request and generates the resource the subscription is for. This is 134 different from other event packages, in which subscriptions are for 135 an existing resource. 137 2. Terminology 139 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 140 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 141 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 142 described in BCP 14, RFC 2119 [1] and indicate requirement levels for 143 compliant implementations. 145 3. Event Package Formal Definition 147 This document provides the details for defining a SIP event package 148 as required by RFC 3265 [6]. 150 3.1. Event Package Name 152 The name of the event package defined in this specification is 153 "session-spec-policy". 155 3.2. Event Package Parameters 157 This package defines the optional event package parameter "request- 158 uri". This parameter is only defined for SUBSCRIBE requests and MUST 159 be ignored if received in a NOTIFY request. 161 If present, the "request-uri" parameter contains the Request-URI that 162 is used to establish or modify the session this policy subscription 163 is for. Typically, this is the Request-URI of the INVITE request 164 that will carry the session descriptions used in this subscription. 165 The "request-uri" parameter enables the subscriber to provide 166 additional information about the current session (i.e. the Request- 167 URI) to the policy server that is not contained in the session 168 descriptions. 170 3.3. SUBSCRIBE Bodies 172 A SUBSCRIBE for the session-specific policy package SHOULD contain a 173 body that consists of a session description. The purpose of this 174 body is to enable the notifier to generate the policy decision the 175 subscriber is interested in. In this event packet, the Request-URI, 176 the event package name and event parameters are not sufficient for 177 this purpose. With the session description in the SUBSCRIBE body, 178 the notifier can generate the requested policy decision and create 179 policy events for this resource. 181 All subscribers and notifiers MUST support the "application/sdp" 182 format as described in [4]. The "application/sdp" format is the 183 default format for session descriptions in this event package. 184 Subscribers and notifiers MAY negotiate the use of other formats 185 capable of representing a session description. 187 Subscriptions to the session-specific policy package are typically 188 created in conjunction with an SDP offer/answer exchange [10] during 189 the establishment of a session as described in [9]. If used with an 190 offer/answer exchange, the subscriber SHOULD insert the local session 191 description in the SUBSCRIBE body. The local session description is 192 the one that was created by the subscriber (i.e. the offer if the 193 subscriber has initiated the offer/answer exchange). A body that 194 contains the local session description offer MUST have a Content- 195 Disposition [8] disposition-type of "session-policy" and a Content- 196 Disposition parameter "description=local", a new value and a new 197 parameter defined in this document. 199 The subscriber MAY choose to also include the remote session 200 description in the SUBSCRIBE body. The remote session description is 201 the one the subscriber has received (i.e. the answer if the 202 subscriber has initiated the offer/answer exchange). In some 203 scenarios, the remote session description is not available to the 204 subscriber at the time the subscription to session-specific policies 205 is created. In this case, the initial SUBSCRIBE message SHOULD only 206 contain the local session description. When the remote description 207 becomes available, the subscriber SHOULD refresh the subscription by 208 sending another SUBSCRIBE request, which then contains the local and 209 the remote session description. 211 All subscribers and notifiers SHOULD support the MIME type 212 "multipart/mixed" [3]. This is needed to include the local and the 213 remote session description in the SUBSCRIBE body. The body that 214 contains the remote session description MUST have the Content- 215 Disposition disposition-type of "session-policy" and a Content- 216 Disposition parameter of "description=remote", a new value and a new 217 parameter defined in this document. 219 3.4. Subscription Duration 221 A subscription to the session-specific policy package is usually 222 established at the beginning of a session and terminated when the 223 corresponding session ends (it may, of course, be terminated 224 earlier). A typical duration of a phone call is a few minutes. 226 Since the duration of a subscription to the session-specific policy 227 package is closely related to the lifetime of the corresponding 228 session, the value for the duration of a subscription is largely 229 irrelevant. However, it SHOULD be longer than the typical duration 230 of a session. The default subscription duration for this event 231 package is set to two hours. 233 3.5. NOTIFY Bodies 235 In this event package, the body of the notification contains the 236 policy decision requested by the subscriber. All subscribers and 237 notifiers MUST support the "application/SDP" format [4] as a format 238 for NOTIFY bodies. 240 The SUBSCRIBE request MAY contain an Accept header field. If no such 241 header field is present, it has a default value of "application/sdp". 242 If the header field is present, it MUST include "application/sdp", 243 and MAY include any other types capable of representing session- 244 specific policy decisions. As defined RFC 3265 [6], the body of 245 notifications MUST be in one of the formats defined in the Accept 246 header of the SUBSCRIBE request or in the default format. 248 If the notifier uses the same format in NOTIFY bodies that was used 249 by the subscriber in the SUBSCRIBE body (e.g. "application/SDP"), the 250 notifier can expect that the subscriber supports all format 251 extensions it has used in the SUBSCRIBE body. However, the notifier 252 cannot assume that the subscriber supports any other extension beyond 253 that. If the notifier uses other extensions, it cannot count on the 254 fact that they will be understood by the subscriber. 256 If the SUBSCRIBE request did contain the local session description of 257 the subscriber and the subscription was accepted, then the NOTIFY 258 body MUST contain a policy decision for this session description. 259 This decision MUST have a disposition-type of "session-policy" and a 260 parameter "description=local". 262 If the SUBSCRIBE request of an accepted subscription contained the 263 local and the remote session description, then the NOTIFY body MUST 264 contain two policy decisions, one for the local and one for the 265 remote session description. The decision for the local description 266 MUST have a disposition-type of "session-policy" with a parameter 267 "description=local", the decision for remote description MUST have a 268 disposition-type of "session-policy" with a parameter 269 "description=remote". 271 3.6. Subscriber generation of SUBSCRIBE requests 273 The subscriber follows the general rules for generating SUBSCRIBE 274 requests defined in [6]. The subscriber SHOULD include the session 275 description in the SUBSCRIBE body that most accurately reflects the 276 session for which it seeks to receive session-specific policies. It 277 SHOULD use the most recent session description if multiple versions 278 are available. 280 A user agent can, of course, change the session description of an 281 ongoing session. A change in the session description often affects 282 the policy decisions that are created for this session. A subscriber 283 SHOULD therefore refresh the subscription to session-specific 284 policies every time the session description of the associated session 285 changes. It does so by sending a SUBSCRIBE request, which contains 286 the updated session description. 288 Session policies can contain sensitive information. Moreover, policy 289 decisions can significantly impact the functionality and behavior of 290 a user agent. A user agent should therefore verify the identity of a 291 policy server and make sure that policies have not been altered in 292 transit. All implementations of this package MUST support TLS [2] 293 and the SIPS URI scheme. A subscriber SHOULD use SIPS URIs, if 294 possible, when subscribing to session-specific policy events so that 295 policies are transmitted over TLS. Subscribers MAY perform server 296 authentication, for example, via TLS or another transport mechanism. 298 3.7. Notifier processing of SUBSCRIBE requests 300 All subscriptions to session-specific policies SHOULD be 301 authenticated and authorized before approval. The notifier SHOULD 302 authenticate the subscriber using any of the techniques available 303 through SIP, including digest, S/MIME, TLS or other transport 304 specific mechanisms. Administrators SHOULD use an SIPS URI as a 305 policy server URI. 307 The authorization policy is at the discretion of the administrator. 308 It is RECOMMENDED that all users are allowed to subscribe to the 309 session-specific policies of their sessions. A subscription to this 310 event package will typically be established by a device that needs to 311 know about the policies for its sessions. However, subscriptions may 312 also be established by applications and automata (e.g. a conference 313 server). In those cases, an authorization policy will typically be 314 provided for these applications. 316 Responding timely to a SUBSCRIBE requests is crucial for this event 317 package. A notifier must minimize the time needed for processing 318 SUBSCRIBE requests and generating the initial NOTIFY. This includes 319 minimizing the time needed to generate an initial policy decision. A 320 short response time is in particular important for this event package 321 since it minimizes the delay for fetching policies during an INVITE 322 transaction and therefore reduces call setup time. In addition, 323 subscriptions to session-specific policies can be established while 324 the subscriber is in an INVITE transaction at a point where it has 325 received the 200 OK but before sending the ACK. Delaying the 326 creation of the initial NOTIFY would delay the transmission of the 327 ACK (a more detailed discussion of this scenario can be found in 328 [9]). 330 3.8. Notifier generation of NOTIFY requests 332 A notifier sends a notification in response to SUBSCRIBE requests as 333 defined in RFC 3265 [6]. In addition, a notifier MAY send a 334 notification at any time during the subscription. Typically, it will 335 send one every time the policy decision this subscription is for has 336 changed. When and why a policy decision changes is entirely at the 337 discretion of the administrator. A change in the policy decision may 338 be triggered, for example, by a change in the network status, a 339 change in the services used or simply by an update of the service 340 level agreement with the customer. 342 The policy decision document in a NOTIFY body MUST represent a 343 complete policy decision. Notifications that contain the deltas to 344 previous policy decisions or partial policy decisions are not 345 supported in this event package. 347 The policy decision to reject a session is expressed by returning an 348 empty NOTIFY body. The notifier MAY terminate the subscription after 349 sending such a notification if it can be expected that this decision 350 will not change in the foreseeable future. The notifier SHOULD keep 351 the subscription up, if it expects that the session can be admitted 352 at a later point in time. A session is admitted by returning a 353 policy decision document that requires some or no changes to the 354 session. If the format "application/sdp" is used, a session is 355 admitted by returning an unmodified session description. To admit a 356 session with changes required, the notifier returns a session 357 description that contains all necessary changes. For example, to 358 disallow video, the notifier returns a session description in which 359 all media lines for video have been removed. When making changes, 360 the notifier SHOULD NOT use any session description format extensions 361 that were not previously used by the subscriber in the original 362 session description. 364 3.9. Subscriber processing of NOTIFY requests 366 A subscriber SHOULD apply the policy decision received to the session 367 associated with this subscription. If the body of a notification 368 contains a policy decision in the "application/sdp" format, the 369 subscriber SHOULD replace the current session description(s) (i.e. 370 the ones submitted in the SUBSCRIBER request) with the ones received 371 in the notification. The subscriber MAY silently ignore extensions 372 to the policy decision format it does not support. 374 If the subscriber receives a notification with an empty body, the 375 session has been rejected. The subscriber SHOULD NOT attempt to 376 establish this session. However, the subscriber MAY keep up the 377 subscription to session-specific policy events for this session since 378 the policy decision may change. 380 A subscriber may receive an update to a policy decision for a session 381 that is already established. The subscriber SHOULD apply the new 382 policy decision to this session. It may need to generate a re-INVITE 383 or UPDATE request for the session or it may need to terminate this 384 session. 386 3.10. Handling of forked requests 388 This event package allows the creation of only one dialog as a result 389 of an initial SUBSCRIBE request. The techniques to achieve this 390 behavior are described in [6]. 392 3.11. Rate of notifications 394 It is anticipated that the rate of policy changes will be very low. 395 In any case, notifications SHOULD NOT be generated at a rate of more 396 than once every five seconds. 398 3.12. State Agents 400 State agents play no role in this package. 402 3.13. Examples 404 TBD. 406 4. Security Considerations 408 Authentication and authorization is important for both, the 409 subscriber and the notifier. 411 A subscriber transmits information about the sessions it wants to 412 establish to the policy server. This data may contain sensitive 413 information that needs to be protected. In addition, a subscriber 414 applies the policies it receives from the policy server to its 415 sessions. These policies can have a significant impact on the 416 functionality and the behavior of a device. A subscriber should 417 therefore verify the identity of a policy server and make sure that 418 policies have not been altered in transit. 420 The policy decisions generated by the notifier may also reveal 421 sensitive information about a user and about the network provider. A 422 notifier therefore needs to ensure that only authorized users can 423 subscribe to session-specific policies. 425 A session description may contain sensitive information the 426 subscriber does not want to share with the notifier. For example, it 427 may contain keys for media encryption. The subscriber needs to 428 ensure that the session description it sends to the notifier in a 429 SUBSCRIBE body only contains information it is actually willing to 430 disclose to the notifier. 432 ISSUE: more details on possible threads and protection mechanisms 433 need to be worked out. 435 5. IANA Considerations 437 5.1. Event Package Name 439 This specification registers an event package, based on the 440 registration procedures defined in RFC 3265 [2]. The following is 441 the information required for such a registration: 443 Package Name: session-spec-policy 445 Package or Template-Package: This is a package. 447 Published Document: RFC XXXX (Note to RFC Editor: Please fill in XXXX 448 with the RFC number of this specification). 450 Person to Contact: Volker Hilt, volkerh@bell-labs.com. 452 5.2. Content-Disposition Types 454 This document defines a new MIME Content-Disposition disposition-type 455 value and a new parameter. 457 The value "session-policy" indicates that the MIME body describes a 458 session policy. 460 An optional parameter "description" is defined for the disposition- 461 type "session-policy". This parameter may have the following values: 463 o The value "description=local" indicates that the MIME body 464 contains the local session description of a user agent in an 465 offer/answer exchange [10]. If the user agent has initiated the 466 offer/answer exchange by sending an offer, then the local 467 description is the offer. If the user agent has received an offer 468 and responds to it, then the local description is the answer. 469 o The value "description=remote" indicates that the MIME body 470 contains the remote session description of a user agent in an 471 offer/answer exchange [10]. If the user agent has initiated the 472 offer/answer exchange, then the remote description is the answer 473 it has received back. If the user agent responds to an offer, 474 then the remote description is the offer. 476 If the parameter "description" is missing, the default value of 477 "description=local" applies. 479 Appendix A. Acknowledgements 481 Many thanks to Jonathan Rosenberg for the discussions and the 482 suggestions for this draft. 484 6. References 486 6.1. Normative References 488 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 489 Levels", BCP 14, RFC 2119, March 1997. 491 [2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 492 RFC 2246, January 1999. 494 [3] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 495 Extensions (MIME) Part Two: Media Types", RFC 2046, 496 November 1996. 498 [4] Handley, M. and V. Jacobson, "SDP: Session Description 499 Protocol", RFC 2327, April 1998. 501 [5] Petrie, D., "A Framework for Session Initiation Protocol User 502 Agent Profile Delivery", draft-ietf-sipping-config-framework-08 503 (work in progress), March 2006. 505 [6] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 506 Notification", RFC 3265, June 2002. 508 [7] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 509 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 510 Session Initiation Protocol", RFC 3261, June 2002. 512 [8] Troost, R., Dorner, S., and K. Moore, "Communicating 513 Presentation Information in Internet Messages: The Content- 514 Disposition Header Field", RFC 2183, August 1997. 516 6.2. Informative References 518 [9] Hilt, V., Camarillo, G., and J. Rosenberg, "A Framework for 519 Session Initiation Protocol (SIP) Session Policies", 520 draft-ietf-sipping-session-policy-framework-00 (work in 521 progress), March 2006. 523 [10] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 524 Session Description Protocol (SDP)", RFC 3264, June 2002. 526 Authors' Addresses 528 Volker Hilt 529 Bell Labs/Lucent Technologies 530 101 Crawfords Corner Rd 531 Holmdel, NJ 07733 532 USA 534 Email: volkerh@bell-labs.com 536 Gonzalo Camarillo 537 Ericsson 538 Hirsalantie 11 539 Jorvas 02420 540 Finland 542 Email: Gonzalo.Camarillo@ericsson.com 544 Intellectual Property Statement 546 The IETF takes no position regarding the validity or scope of any 547 Intellectual Property Rights or other rights that might be claimed to 548 pertain to the implementation or use of the technology described in 549 this document or the extent to which any license under such rights 550 might or might not be available; nor does it represent that it has 551 made any independent effort to identify any such rights. Information 552 on the procedures with respect to rights in RFC documents can be 553 found in BCP 78 and BCP 79. 555 Copies of IPR disclosures made to the IETF Secretariat and any 556 assurances of licenses to be made available, or the result of an 557 attempt made to obtain a general license or permission for the use of 558 such proprietary rights by implementers or users of this 559 specification can be obtained from the IETF on-line IPR repository at 560 http://www.ietf.org/ipr. 562 The IETF invites any interested party to bring to its attention any 563 copyrights, patents or patent applications, or other proprietary 564 rights that may cover technology that may be required to implement 565 this standard. Please address the information to the IETF at 566 ietf-ipr@ietf.org. 568 Disclaimer of Validity 570 This document and the information contained herein are provided on an 571 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 572 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 573 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 574 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 575 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 576 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 578 Copyright Statement 580 Copyright (C) The Internet Society (2006). This document is subject 581 to the rights, licenses and restrictions contained in BCP 78, and 582 except as set forth therein, the authors retain all their rights. 584 Acknowledgment 586 Funding for the RFC Editor function is currently provided by the 587 Internet Society.