idnits 2.17.1 draft-hilt-sipping-policy-package-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 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 570. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 547. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 554. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 560. ** 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 (March 5, 2006) is 6626 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) == Unused Reference: '5' is defined on line 490, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2246 (ref. '2') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2327 (ref. '4') (Obsoleted by RFC 4566) -- No information found for draft-hilt-sipping-media-policy-dataset - is the name correct? -- Possible downref: Normative reference to a draft: ref. '5' == Outdated reference: A later version (-18) exists of draft-ietf-sipping-config-framework-07 ** Obsolete normative reference: RFC 3265 (ref. '7') (Obsoleted by RFC 6665) Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 9 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 March 5, 2006 8 A Session Initiation Protocol (SIP) Event Package for Session-Specific 9 Session Policies. 10 draft-hilt-sipping-policy-package-01 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 September 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 . . . . . . . . . . . . . . . . . . . . . 4 57 3.4. Subscription Duration . . . . . . . . . . . . . . . . . . 5 58 3.5. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 6 59 3.6. Subscriber generation of SUBSCRIBE requests . . . . . . . 6 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 . . . . . . . . . 8 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) [8] Session 81 Policies [10] defines a protocol framework for the exchange of 82 session policy information between a network domain and a user agent. 83 This framework introduces two types of session policies: session- 84 specific policies and session-independent policies. Session-specific 85 policies are policies for one specific session. They are created 86 based on the session description of a session. Naturally, a user 87 agent needs to request session-specific policies on a session-by- 88 session basis at the time a session is created and the session 89 description is known. Session-independent policies on the other hand 90 are policies that are created independent of a session and generally 91 apply to SIP sessions. Since these policies are not based on a 92 specific session description, they can be created and conveyed to the 93 user agent at any time. User agents receive session-independent 94 policies as part of their configuration information [6]. 96 This specification defines a SIP event package [7] 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 [10]): 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 [7]. 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 does not define any event package parameters. 159 3.3. SUBSCRIBE Bodies 161 A SUBSCRIBE for the session-specific policy package SHOULD contain a 162 body that consists of a session description. The purpose of this 163 body is to enable the notifier to generate the policy decision the 164 subscriber is interested in. In this event packet, the Request-URI, 165 the event package name and event parameters are not sufficient for 166 this purpose. With the session description in the SUBSCRIBE body, 167 the notifier can generate the requested policy decision and create 168 policy events for this resource. 170 All subscribers and notifiers MUST support the "application/sdp" 171 format as described in [4]. The "application/sdp" format is the 172 default format for session descriptions in this event package. 173 Subscribers and notifiers MAY negotiate the use of other formats 174 capable of representing a session description. 176 Subscriptions to the session-specific policy package are typically 177 created in conjunction with an SDP offer/answer exchange [11] during 178 the establishment of a session as described in [10]. If used with an 179 offer/answer exchange, the subscriber SHOULD insert the local session 180 description in the SUBSCRIBE body. The local session description is 181 the one that was created by the subscriber (i.e. the offer if the 182 subscriber has initiated the offer/answer exchange). A body that 183 contains the local session description offer MUST have a Content- 184 Disposition [9] disposition-type of "session-policy" and a Content- 185 Disposition parameter "description=local", a new value and a new 186 parameter defined in this document. 188 The subscriber MAY choose to also include the remote session 189 description in the SUBSCRIBE body. The remote session description is 190 the one the subscriber has received (i.e. the answer if the 191 subscriber has initiated the offer/answer exchange). In some 192 scenarios, the remote session description is not available to the 193 subscriber at the time the subscription to session-specific policies 194 is created. In this case, the initial SUBSCRIBE message SHOULD only 195 contain the local session description. When the remote description 196 becomes available, the subscriber SHOULD refresh the subscription by 197 sending another SUBSCRIBE request, which then contains the local and 198 the remote session description. 200 All subscribers and notifiers SHOULD support the MIME type 201 "multipart/mixed" [3]. This is needed to include the local and the 202 remote session description in the SUBSCRIBE body. The body that 203 contains the remote session description MUST have the Content- 204 Disposition disposition-type of "session-policy" and a Content- 205 Disposition parameter of "description=remote", a new value and a new 206 parameter defined in this document. 208 3.4. Subscription Duration 210 A subscription to the session-specific policy package is usually 211 established at the beginning of a session and terminated when the 212 corresponding session ends (it may, of course, be terminated 213 earlier). A typical duration of a phone call is a few minutes. 215 Since the duration of a subscription to the session-specific policy 216 package is closely related to the lifetime of the corresponding 217 session, the value for the duration of a subscription is largely 218 irrelevant. However, it SHOULD be longer than the typical duration 219 of a session. The default subscription duration for this event 220 package is set to two hours. 222 3.5. NOTIFY Bodies 224 In this event package, the body of the notification contains the 225 policy decision requested by the subscriber. All subscribers and 226 notifiers MUST support the "application/SDP" format [4] as a format 227 for NOTIFY bodies. 229 The SUBSCRIBE request MAY contain an Accept header field. If no such 230 header field is present, it has a default value of "application/sdp". 231 If the header field is present, it MUST include "application/sdp", 232 and MAY include any other types capable of representing session- 233 specific policy decisions. As defined RFC 3265 [7], the body of 234 notifications MUST be in one of the formats defined in the Accept 235 header of the SUBSCRIBE request or in the default format. 237 If the notifier uses the same format in NOTIFY bodies that was used 238 by the subscriber in the SUBSCRIBE body (e.g. "application/SDP"), the 239 notifier can expect that the subscriber supports all format 240 extensions it has used in the SUBSCRIBE body. However, the notifier 241 cannot assume that the subscriber supports any other extension beyond 242 that. If the notifier uses other extensions, it cannot count on the 243 fact that they will be understood by the subscriber. 245 If the SUBSCRIBE request did contain the local session description of 246 the subscriber and the subscription was accepted, then the NOTIFY 247 body MUST contain a policy decision for this session description. 248 This decision MUST have a disposition-type of "session-policy" and a 249 parameter "description=local". 251 If the SUBSCRIBE request of an accepted subscription contained the 252 local and the remote session description, then the NOTIFY body MUST 253 contain two policy decisions, one for the local and one for the 254 remote session description. The decision for the local description 255 MUST have a disposition-type of "session-policy" with a parameter 256 "description=local", the decision for remote description MUST have a 257 disposition-type of "session-policy" with a parameter 258 "description=remote". 260 3.6. Subscriber generation of SUBSCRIBE requests 262 The subscriber follows the general rules for generating SUBSCRIBE 263 requests defined in [7]. The subscriber SHOULD include the session 264 description in the SUBSCRIBE body that most accurately reflects the 265 session for which it seeks to receive session-specific policies. It 266 SHOULD use the most recent session description if multiple versions 267 are available. 269 A user agent can, of course, change the session description of an 270 ongoing session. A change in the session description often affects 271 the policy decisions that are created for this session. A subscriber 272 SHOULD therefore refresh the subscription to session-specific 273 policies every time the session description of the associated session 274 changes. It does so by sending a SUBSCRIBE request, which contains 275 the updated session description. 277 Session policies can contain sensitive information. Moreover, policy 278 decisions can significantly impact the functionality and behavior of 279 a user agent. A user agent should therefore verify the identity of a 280 policy server and make sure that policies have not been altered in 281 transit. All implementations of this package MUST support TLS [2] 282 and the SIPS URI scheme. A subscriber SHOULD use SIPS URIs, if 283 possible, when subscribing to session-specific policy events so that 284 policies are transmitted over TLS. Subscribers MAY perform server 285 authentication, for example, via TLS or another transport mechanism. 287 3.7. Notifier processing of SUBSCRIBE requests 289 All subscriptions to session-specific policies SHOULD be 290 authenticated and authorized before approval. The notifier SHOULD 291 authenticate the subscriber using any of the techniques available 292 through SIP, including digest, S/MIME, TLS or other transport 293 specific mechanisms. Administrators SHOULD use an SIPS URI as a 294 policy server URI. 296 The authorization policy is at the discretion of the administrator. 297 It is RECOMMENDED that all users are allowed to subscribe to the 298 session-specific policies of their sessions. A subscription to this 299 event package will typically be established by a device that needs to 300 know about the policies for its sessions. However, subscriptions may 301 also be established by applications and automata (e.g. a conference 302 server). In those cases, an authorization policy will typically be 303 provided for these applications. 305 Responding timely to a SUBSCRIBE requests is crucial for this event 306 package. A notifier must minimize the time needed for processing 307 SUBSCRIBE requests and generating the initial NOTIFY. This includes 308 minimizing the time needed to generate an initial policy decision. A 309 short response time is in particular important for this event package 310 since it minimizes the delay for fetching policies during an INVITE 311 transaction and therefore reduces call setup time. In addition, 312 subscriptions to session-specific policies can be established while 313 the subscriber is in an INVITE transaction at a point where it has 314 received the 200 OK but before sending the ACK. Delaying the 315 creation of the initial NOTIFY would delay the transmission of the 316 ACK (a more detailed discussion of this scenario can be found in 317 [10]). 319 3.8. Notifier generation of NOTIFY requests 321 A notifier sends a notification in response to SUBSCRIBE requests as 322 defined in RFC 3265 [7]. In addition, a notifier MAY send a 323 notification at any time during the subscription. Typically, it will 324 send one every time the policy decision this subscription is for has 325 changed. When and why a policy decision changes is entirely at the 326 discretion of the administrator. A change in the policy decision may 327 be triggered, for example, by a change in the network status, a 328 change in the services used or simply by an update of the service 329 level agreement with the customer. 331 The policy decision document in a NOTIFY body MUST represent a 332 complete policy decision. Notifications that contain the deltas to 333 previous policy decisions or partial policy decisions are not 334 supported in this event package. 336 The policy decision to reject a session is expressed by returning an 337 empty NOTIFY body. The notifier MAY terminate the subscription after 338 sending such a notification if it can be expected that this decision 339 will not change in the foreseeable future. The notifier SHOULD keep 340 the subscription up, if it expects that the session can be admitted 341 at a later point in time. A session is admitted by returning a 342 policy decision document that requires some or no changes to the 343 session. If the format "application/sdp" is used, a session is 344 admitted by returning an unmodified session description. To admit a 345 session with changes required, the notifier returns a session 346 description that contains all necessary changes. For example, to 347 disallow video, the notifier returns a session description in which 348 all media lines for video have been removed. When making changes, 349 the notifier SHOULD NOT use any session description format extensions 350 that were not previously used by the subscriber in the original 351 session description. 353 3.9. Subscriber processing of NOTIFY requests 355 A subscriber SHOULD apply the policy decision received to the session 356 associated with this subscription. If the body of a notification 357 contains a policy decision in the "application/sdp" format, the 358 subscriber SHOULD replace the current session description(s) (i.e. 359 the ones submitted in the SUBSCRIBER request) with the ones received 360 in the notification. The subscriber MAY silently ignore extensions 361 to the policy decision format it does not support. 363 If the subscriber receives a notification with an empty body, the 364 session has been rejected. The subscriber SHOULD NOT attempt to 365 establish this session. However, the subscriber MAY keep up the 366 subscription to session-specific policy events for this session since 367 the policy decision may change. 369 A subscriber may receive an update to a policy decision for a session 370 that is already established. The subscriber SHOULD apply the new 371 policy decision to this session. It may need to generate a re-INVITE 372 or UPDATE request for the session or it may need to terminate this 373 session. 375 3.10. Handling of forked requests 377 This event package allows the creation of only one dialog as a result 378 of an initial SUBSCRIBE request. The techniques to achieve this 379 behavior are described in [7]. 381 3.11. Rate of notifications 383 It is anticipated that the rate of policy changes will be very low. 384 In any case, notifications SHOULD NOT be generated at a rate of more 385 than once every five seconds. 387 3.12. State Agents 389 State agents play no role in this package. 391 3.13. Examples 393 TBD. 395 4. Security Considerations 397 Authentication and authorization is important for both, the 398 subscriber and the notifier. 400 A subscriber transmits information about the sessions it wants to 401 establish to the policy server. This data may contain sensitive 402 information that needs to be protected. In addition, a subscriber 403 applies the policies it receives from the policy server to its 404 sessions. These policies can have a significant impact on the 405 functionality and the behavior of a device. A subscriber should 406 therefore verify the identity of a policy server and make sure that 407 policies have not been altered in transit. 409 The policy decisions generated by the notifier may also reveal 410 sensitive information about a user and about the network provider. A 411 notifier therefore needs to ensure that only authorized users can 412 subscribe to session-specific policies. 414 A session description may contain sensitive information the 415 subscriber does not want to share with the notifier. For example, it 416 may contain keys for media encryption. The subscriber needs to 417 ensure that the session description it sends to the notifier in a 418 SUBSCRIBE body only contains information it is actually willing to 419 disclose to the notifier. 421 ISSUE: more details on possible threads and protection mechanisms 422 need to be worked out. 424 5. IANA Considerations 426 5.1. Event Package Name 428 This specification registers an event package, based on the 429 registration procedures defined in RFC 3265 [2]. The following is 430 the information required for such a registration: 432 Package Name: session-spec-policy 434 Package or Template-Package: This is a package. 436 Published Document: RFC XXXX (Note to RFC Editor: Please fill in XXXX 437 with the RFC number of this specification). 439 Person to Contact: Volker Hilt, volkerh@bell-labs.com. 441 5.2. Content-Disposition Types 443 This document defines a new MIME Content-Disposition disposition-type 444 value and a new parameter. 446 The value "session-policy" indicates that the MIME body describes a 447 session policy. 449 An optional parameter "description" is defined for the disposition- 450 type "session-policy". This parameter may have the following values: 452 o The value "description=local" indicates that the MIME body 453 contains the local session description of a user agent in an 454 offer/answer exchange [11]. If the user agent has initiated the 455 offer/answer exchange by sending an offer, then the local 456 description is the offer. If the user agent has received an offer 457 and responds to it, then the local description is the answer. 458 o The value "description=remote" indicates that the MIME body 459 contains the remote session description of a user agent in an 460 offer/answer exchange [11]. If the user agent has initiated the 461 offer/answer exchange, then the remote description is the answer 462 it has received back. If the user agent responds to an offer, 463 then the remote description is the offer. 465 If the parameter "description" is missing, the default value of 466 "description=local" applies. 468 Appendix A. Acknowledgements 470 Many thanks to Jonathan Rosenberg for the discussions and the 471 suggestions for this draft. 473 6. References 475 6.1. Normative References 477 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 478 Levels", BCP 14, RFC 2119, March 1997. 480 [2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 481 RFC 2246, January 1999. 483 [3] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 484 Extensions (MIME) Part Two: Media Types", RFC 2046, 485 November 1996. 487 [4] Handley, M. and V. Jacobson, "SDP: Session Description 488 Protocol", RFC 2327, April 1998. 490 [5] Hilt, V., Camarillo, G., and J. Rosenberg, "A User Agent Profile 491 Data Set for Media Policy", 492 draft-hilt-sipping-media-policy-dataset-01 (work in progress), 493 March 2006. 495 [6] Petrie, D., "A Framework for Session Initiation Protocol User 496 Agent Profile Delivery", draft-ietf-sipping-config-framework-07 497 (work in progress), July 2005. 499 [7] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 500 Notification", RFC 3265, June 2002. 502 [8] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 503 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 504 Session Initiation Protocol", RFC 3261, June 2002. 506 [9] Troost, R., Dorner, S., and K. Moore, "Communicating 507 Presentation Information in Internet Messages: The Content- 508 Disposition Header Field", RFC 2183, August 1997. 510 6.2. Informative References 512 [10] Hilt, V., Camarillo, G., and J. Rosenberg, "A Framework for 513 Session Initiation Protocol (SIP) Session Policies", 514 draft-hilt-sipping-session-policy-framework-01 (work in 515 progress), March 2006. 517 [11] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with 518 Session Description Protocol (SDP)", RFC 3264, June 2002. 520 Authors' Addresses 522 Volker Hilt 523 Bell Labs/Lucent Technologies 524 101 Crawfords Corner Rd 525 Holmdel, NJ 07733 526 USA 528 Email: volkerh@bell-labs.com 530 Gonzalo Camarillo 531 Ericsson 532 Hirsalantie 11 533 Jorvas 02420 534 Finland 536 Email: Gonzalo.Camarillo@ericsson.com 538 Intellectual Property Statement 540 The IETF takes no position regarding the validity or scope of any 541 Intellectual Property Rights or other rights that might be claimed to 542 pertain to the implementation or use of the technology described in 543 this document or the extent to which any license under such rights 544 might or might not be available; nor does it represent that it has 545 made any independent effort to identify any such rights. Information 546 on the procedures with respect to rights in RFC documents can be 547 found in BCP 78 and BCP 79. 549 Copies of IPR disclosures made to the IETF Secretariat and any 550 assurances of licenses to be made available, or the result of an 551 attempt made to obtain a general license or permission for the use of 552 such proprietary rights by implementers or users of this 553 specification can be obtained from the IETF on-line IPR repository at 554 http://www.ietf.org/ipr. 556 The IETF invites any interested party to bring to its attention any 557 copyrights, patents or patent applications, or other proprietary 558 rights that may cover technology that may be required to implement 559 this standard. Please address the information to the IETF at 560 ietf-ipr@ietf.org. 562 Disclaimer of Validity 564 This document and the information contained herein are provided on an 565 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 566 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 567 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 568 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 569 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 570 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 572 Copyright Statement 574 Copyright (C) The Internet Society (2006). This document is subject 575 to the rights, licenses and restrictions contained in BCP 78, and 576 except as set forth therein, the authors retain all their rights. 578 Acknowledgment 580 Funding for the RFC Editor function is currently provided by the 581 Internet Society.