idnits 2.17.00 (12 Aug 2021) /tmp/idnits52631/draft-tschofenig-sipping-spit-policy-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 23. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 707. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 718. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 725. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 731. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (February 26, 2007) is 5563 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) -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Obsolete normative reference: RFC 4474 (ref. '2') (Obsoleted by RFC 8224) == Outdated reference: draft-ietf-simple-xcap has been published as RFC 4825 == Outdated reference: A later version (-02) exists of draft-froment-sipping-spit-authz-policies-01 == Outdated reference: A later version (-06) exists of draft-mahy-iptel-cpc-05 == Outdated reference: draft-ietf-sipping-spam has been published as RFC 5039 == Outdated reference: draft-ietf-simple-presence-rules has been published as RFC 5025 == Outdated reference: A later version (-06) exists of draft-jennings-sip-hashcash-04 == Outdated reference: draft-ietf-sip-consent-framework has been published as RFC 5360 -- Obsolete informational reference (is this intentional?): RFC 3028 (ref. '13') (Obsoleted by RFC 5228, RFC 5429) Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Tschofenig 3 Internet-Draft Siemens Networks GmbH & Co KG 4 Intended status: Standards Track D. Wing 5 Expires: August 30, 2007 Cisco 6 H. Schulzrinne 7 Columbia U. 8 T. Froment 9 Alcatel-Lucent 10 G. Dawirs 11 University of Namur 12 February 26, 2007 14 Anti-SPIT : A Document Format for Expressing Anti-SPIT Authorization 15 Policies 16 draft-tschofenig-sipping-spit-policy-00.txt 18 Status of this Memo 20 By submitting this Internet-Draft, each author represents that any 21 applicable patent or other IPR claims of which he or she is aware 22 have been or will be disclosed, and any of which he or she becomes 23 aware will be disclosed, in accordance with Section 6 of BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on August 30, 2007. 43 Copyright Notice 45 Copyright (C) The IETF Trust (2007). 47 Abstract 49 SPAM, defined as sending unsolicited messages to someone in bulk, 50 might be a problem on SIP open-wide deployed networks. The 51 responsibility for filtering or blocking calls can belong to 52 different elements in the call flow and may depend on various 53 factors. This document defines an authorization based policy 54 language that allows end users to upload anti-SPIT policies to 55 intermediaries, such as SIP proxies. These policies mitigate 56 unwanted SIP communications. It extends the Common Policy 57 authorization framework with additional conditions and actions. The 58 new conditions match a particular Session Initiation Protocol (SIP) 59 communication pattern based on a number of attributes. The range of 60 attributes includes information provided, for example, by SIP itself, 61 by the SIP identity mechanism, by information carried within SAML 62 assertions. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3. Generic Processing . . . . . . . . . . . . . . . . . . . . . . 5 69 3.1. Structure of SPIT Authorization Documents . . . . . . . . 5 70 3.2. Rule Transport . . . . . . . . . . . . . . . . . . . . . . 5 71 4. Condition Elements . . . . . . . . . . . . . . . . . . . . . . 5 72 4.1. MessagePattern Element . . . . . . . . . . . . . . . . . . 6 73 4.2. MethodUsed Element . . . . . . . . . . . . . . . . . . . . 6 74 4.3. Assertions-Specific Parameters . . . . . . . . . . . . . . 6 75 5. Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 76 5.1. Handling Action . . . . . . . . . . . . . . . . . . . . . 7 77 5.2. Redirect Action . . . . . . . . . . . . . . . . . . . . . 8 78 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 79 7. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 11 80 8. XCAP USAGE . . . . . . . . . . . . . . . . . . . . . . . . . . 12 81 8.1. Application Unique ID . . . . . . . . . . . . . . . . . . 12 82 8.2. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 12 83 8.3. Default Namespace . . . . . . . . . . . . . . . . . . . . 12 84 8.4. MIME Type . . . . . . . . . . . . . . . . . . . . . . . . 13 85 8.5. Validation Constraints . . . . . . . . . . . . . . . . . . 13 86 8.6. Data Semantics . . . . . . . . . . . . . . . . . . . . . . 13 87 8.7. Naming Conventions . . . . . . . . . . . . . . . . . . . . 13 88 8.8. Resource Interdependencies . . . . . . . . . . . . . . . . 13 89 8.9. Authorization Policies . . . . . . . . . . . . . . . . . . 13 90 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 91 9.1. Anti-SPIT Policy XML Schema Registration . . . . . . . . . 13 92 9.2. Anti-SPIT Policy Namespace Registration . . . . . . . . . 14 93 9.3. XCAP Application Usage ID . . . . . . . . . . . . . . . . 14 94 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 95 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15 96 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 97 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 98 13.1. Normative References . . . . . . . . . . . . . . . . . . . 15 99 13.2. Informative References . . . . . . . . . . . . . . . . . . 15 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 101 Intellectual Property and Copyright Statements . . . . . . . . . . 18 103 1. Introduction 105 The problem of SPAM for Internet Telephony (SPIT) is an imminent 106 challenge and only the combination of several techniques can provide 107 a framework for dealing with unwanted communication, as stated in 108 [11]. 110 One important building block is to have a mechanism that can instruct 111 SIP intermediaries to react differently on incoming requests based on 112 policies. Different entities, such as end users, parents on behalf 113 of their children, system administrators in enterprise networks, 114 etc., might create and modify authorization policies. The conditions 115 in these policies can be created from many sources but some 116 information elements are more important than others. For example, 117 there is reason to believe that applying authorization policies based 118 on the authenticated identity is an effective way to accept a 119 communication attempt to deal with unsolicited communication. 120 Authentication based on the SIP identity mechanism, see [2], is one 121 important concept. 123 There is also related work in this context that needs to be 124 highlighted. Requirements for the authorization policies described 125 in this document are outlined in [7]. Selected parts of the work 126 done with Sieve [13], a mail filtering language, may be reused by 127 this document. Furthermore, the Call Processing Language (CPL) [14] 128 is similar to the approach described in this document. The 129 difference mainly is that CPL has a more procedural approach, while 130 this proposal is matching-based. 132 2. Terminology 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in RFC 2119 [1]. 138 This document reuses the terminology from RFC 4745 [3]: 140 Rule maker: 142 The RM is an entity that creates the authorization policies that 143 react to unwanted connection attempts. The rule maker might be an 144 end user that owns the device, a VoIP service provider, a person 145 with a relationship to the end user (e.g., the parents of a child 146 using a mobile phone). A standardized policy language is needed 147 when the creation, modification and deletion of authorization 148 policies are not only a local matter. 150 Authorization policy: 152 An authorization policy is given by a rule set. A rule set 153 contains an unordered list of rules. Each rule has a condition, 154 an action and a transformation component. The terms 155 'authorization policy', 'policy', 'rule set', 'authorization 156 policy rule', 'policy rule' and 'rule' are used interchangeably. 157 Authorization policies can be applied at the end host and/or by 158 intermediaries. 160 Permission: 162 The term permission refers to the action and transformation 163 components of a rule. 165 3. Generic Processing 167 3.1. Structure of SPIT Authorization Documents 169 A SPIT authorization document is an XML document, formatted according 170 to the schema defined in RFC 4745 [3]. SPIT authorization documents 171 inherit the MIME type of common policy documents, application/ 172 auth-policy+xml. As described in [3], this document is composed of 173 rules which contain three parts - conditions, actions, and 174 transformations. Each action or transformation, which is also called 175 a permission, has the property of being a positive grant to the 176 authorization server to perform the resulting actions, be it allow, 177 block etc . As a result, there is a well-defined mechanism for 178 combining actions and transformations obtained from several sources. 179 This mechanism therefore can be used to filter connection attempts 180 thus leading to effective SPIT prevention. 182 3.2. Rule Transport 184 Policies are XML documents that are stored at a Proxy Server or a 185 dedicated device. The Rule Maker therefore needs to use a protocol 186 to create, modify and delete the authorization policies defined in 187 this document. Such a protocol is available with the Extensible 188 Markup Language (XML) Configuration Access Protocol (XCAP) [4]. 190 4. Condition Elements 192 This section describes the additional enhancements of the conditions- 193 part of the rule. This document inherits the Common Policy 194 functionality, including identity, validity, and sphere conditions. 196 The identity condition restricts matching of a rule either to a 197 single entity or a group of entities. Authenticated and non- 198 authenticated entities can be matched; acceptable means of 199 authentication are specified in Section 3.1 of [10] and can be reused 200 in this document. An important component of the overall solution are 201 authenticated identities, such as provided via SIP Identity [2]. If 202 the element is absent, identities are not considered, and 203 thus, other conditions in the rule apply to any user, authenticated 204 or not. 206 The condition is considered TRUE if any of its child 207 elements (e.g., the and the elements defined in this 208 document) evaluate to TRUE, i.e., the results of the individual child 209 element are combined using a logical OR. 211 4.1. MessagePattern Element 213 Any attribute of the SIP header, such as the From, To, Contact etc., 214 can be used to perform actions on incoming messages. 216 4.2. MethodUsed Element 218 Any SIP Method invoked by the user can be used to filter incoming 219 messages. 221 4.3. Assertions-Specific Parameters 223 This parameter list set refers to information that can be made 224 available by, for example, using SAML assertions, as defined in [5]. 225 As an example, the following attribute is reused in this document: 227 AuthenticationOfAccountOpening: 229 (a) No validation of new account (could be machine opened) 230 (b) Turing Test (human needed to open new account) 231 (c) Credit card or other form of verifiable identification 232 (d) Passport was presented for verification 234 The values put in the element are defined as follows: 235 o 237 Corresponds to value (a)- (d) 238 o 240 Corresponds to value (b) - (d) 241 o 243 Corresponds to value (c) - (d) 245 o 247 Corresponds to value (d) 249 Other attributes, such as IdentityStrength, CostOfCall, 250 IdentityAssertion, ConnectionSecurity, SPITSuspected, CallCenter, or 251 AssertionStrength from [5] might allow meaningful decisions to be 252 performed. 254 Further parameters carried in a SAML assertion are defined in [6] and 255 can also be used for the decision making process. Possible 256 parameters for Originating Line Indication (OLI) and for Calling 257 Party Category (CPC) are described in Section 7 and 8 of [6]. The 258 CPC parameters may also be encoded in a different form, as shown in 259 [8], and usable by this document. 261 5. Actions 263 As stated in [2], conditions are the 'if'-part of rules, whereas 264 actions and transformations form their 'then'-part. The actions and 265 transformations parts of a rule determine which operations the proxy 266 server MUST execute on receiving a connection request attempt that 267 matches all conditions of this rule. Actions and transformations 268 permit certain operations such as block, polite-block, mark, allow, 269 puzzle and consent. 271 5.1. Handling Action 273 The element allows a couple of actions to be defined. 275 Block Action: 277 The block action states that this specific connection request MUST 278 NOT be forwarded and a "403" forbidden message MUST be sent to the 279 sender of the message. 281 Polite-block Action 283 The Polite-block action states that this specific connection 284 request MUST NOT be forwarded and no message be sent back to the 285 sender of the message. 287 Mark Action: 289 The Mark action states that this specific connection request MUST 290 be forwarded after marking it as a "SPAM". Details for the 291 message marking are for further study. 293 Allow Action: 295 The Allow action states that this specific connection request MUST 296 be forwarded. 297 Puzzle Action: 299 The Puzzle action states that the "Computational Puzzles" 300 mechanism, described in [11], MUST be triggered. 302 Consent Action: 304 The Consent action states that "Consent Framework" [12] mechanism 305 MUST be triggered. 307 Default Action: 309 One of the action can be stated as a default action. 311 5.2. Redirect Action 313 This document defines the action that contains a URI where 314 an incoming message is forwarded to. 316 6. Examples 318 This section provides a few examples for policy rules defined in this 319 document. The example policy shows three rules with the rule id 1, 2 320 and 3. The rule with the id=1 matches for authenticated identities 321 from the domain "example.com", "example.org" and the single identity 322 "sip:bob@good.example.net". For these conditions SIP messages are 323 forwarded to the SIP UA as indicated with the element. 325 Rule 2 indicates that for SIP messages where the identity cannot be 326 matched against a white list and for those where the identity was 327 obtained by having the user to present a passport, credit card or 328 other form of verifiable identification when opening the account (as 329 indicated in the by setting the 330 token 'VERIFYABLE') the consent framework is applied (see 'consent' 331 token in the element). 333 Rule 1 and 2 are valid only from 2007-1-24T17:00:00+01:00 to 2007-3- 334 24T19:00:00+01:00. 336 Rule 3 does not contain any condition. All requests that fall into 337 this category are redirected to an answering machine (namely 338 sip:answering-machine@home.foo-bar.com). Rule 3 is not restricted to 339 a specific time period. 341 342 346 347 348 349 350 351 352 353 354 2007-1-24T17:00:00+01:00 355 2007-3-24T19:00:00+01:00 356 357 358 359 allow 360 361 362 364 365 366 367 2007-1-24T17:00:00+01:00 368 2007-3-24T19:00:00+01:00 369 370 VERIFYABLE 371 372 373 374 consent 375 376 377 379 380 381 382 sip:answering-machine@home.foo-bar.com 383 384 385 386 388 390 7. XML Schema 392 This section contains the XML schema that defines the policies schema 393 described in this document. This schema extends the Common Policy 394 schema (see [2]) by introducing new members of the and 395 elements. 397 398 406 407 410 412 415 418 421 423 424 425 426 427 428 429 430 431 433 434 435 436 438 440 442 443 444 445 446 447 448 449 450 451 452 453 455 457 459 8. XCAP USAGE 461 The following section defines the details necessary for clients to 462 manipulate SPIT authorization documents from a server using XCAP. 464 8.1. Application Unique ID 466 XCAP requires application usages to define a unique application usage 467 ID (AUID) in either the IETF tree or a vendor tree. This 468 specification defines the "Spit-policy" AUID within the IETF tree, 469 via the IANA registration in Section 9. 471 8.2. XML Schema 473 XCAP requires application usages to define a schema for their 474 documents. The schema for Anti-SPIT authorization documents is 475 described in Section 7. 477 8.3. Default Namespace 479 XCAP requires application usages to define the default namespace for 480 their documents. The default namespace is 481 urn:ietf:params:xml:ns:spit-policy. 483 8.4. MIME Type 485 XCAP requires application usages to defined the MIME type for 486 documents they carry. Anti-SPIT privacy authorization documents 487 inherit the MIME type of Common Policy documents, application/ 488 auth-policy+xml. 490 8.5. Validation Constraints 492 This specification does not define additional constraints. 494 8.6. Data Semantics 496 This document discusses the semantics of Anti-SPIT authorization. 498 8.7. Naming Conventions 500 When a SIP Proxy receives a SIP message to route it towards to a 501 specific user foo, it will look for all documents within 502 http://[xcaproot]/spit-policy/users/foo, and use all documents found 503 beneath that point to guide authorization policy. 505 8.8. Resource Interdependencies 507 This application usage does not define additional resource 508 interdependencies. 510 8.9. Authorization Policies 512 This application usage does not modify the default XCAP authorization 513 policy, which is that only a user can read, write or modify his/her 514 own documents. A server can allow privileged users to modify 515 documents that they do not own, but the establishment and indication 516 of such policies is outside the scope of this document. 518 9. IANA Considerations 520 There are several IANA considerations associated with this 521 specification. 523 9.1. Anti-SPIT Policy XML Schema Registration 525 URI: urn:ietf:params:xml:schema:spit-policy 526 Registrant Contact: Hannes Tschofenig 527 (hannes.tschofenig@siemens.com). 528 XML: The XML schema to be registered is contained in Section 7. Its 529 first line is 531 533 and its last line is 535 537 9.2. Anti-SPIT Policy Namespace Registration 539 URI: urn:ietf:params:xml:ns:spit-policy 540 Registrant Contact: Hannes Tschofenig 541 (hannes.tschofenig@siemens.com). 542 XML: 544 9.3. XCAP Application Usage ID 546 This section registers an XCAP Application Usage ID (AUID) according 547 to the IANA procedures defined in . 549 Name of the AUID: spit-policy 551 Description: Anti-SPIT privacy rules are documents that describe the 552 Authorization policies that trigger reaction to unwanted connection 553 attempts. 555 10. Security Considerations 557 This document aims to make it simple for users to influence the 558 behavior of SIP message routing with an emphasis on SPIT prevention. 559 This document proposes a strawman proposal for conditions and actions 560 that might be useful when it comes to allowing a UA to tell its 561 proxies which messages it wants to receive and what tasks it wants 562 those proxies to perform before sending a SIP request to the UA. 564 A couple of requirements are described in [7] and a general 565 discussion about the available solution mechanisms is available with 566 [9]. This document offers the ability to glue the different solution 567 pieces together. 569 Since this document uses the Common Policy framework it also inherits 570 its capabilities, including the combining permission algorithm that 571 is applied when multiple rules fire. Unauthorized access to the 572 user's Anti-SPIT rules must be prevented to avoid the introduction of 573 security vulnerabilities. 575 11. Contributors 577 We would like to thank Mayutan Arumaithurai 578 (mayutan.arumaithurai@gmail.com) for his work on this document. 580 12. Acknowledgments 582 We would like to thank David Schwartz for his work on the "SAML SPIT" 583 draft. We would like to thank Miguel Garcia and Remi Denis-Courmont 584 for their review comments. 586 Finally, we would like to thank Jonathan Rosenberg, David Schwartz 587 and Dan York for sharing their thoughts with us. 589 13. References 591 13.1. Normative References 593 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 594 Levels", March 1997. 596 [2] Peterson, J. and C. Jennings, "Enhancements for Authenticated 597 Identity Management in the Session Initiation Protocol (SIP)", 598 RFC 4474, August 2006. 600 [3] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., Polk, 601 J., and J. Rosenberg, "Common Policy: A Document Format for 602 Expressing Privacy Preferences", RFC 4745, February 2007. 604 [4] Rosenberg, J., "The Extensible Markup Language (XML) 605 Configuration Access Protocol (XCAP)", 606 draft-ietf-simple-xcap-12 (work in progress), October 2006. 608 13.2. Informative References 610 [5] Schwartz, D., "SPAM for Internet Telephony (SPIT) Prevention 611 using the Security Assertion Markup Language (SAML)", 612 draft-schwartz-sipping-spit-saml-01 (work in progress), 613 June 2006. 615 [6] Schubert, S., "Conveying CPC using the SAML", 616 draft-schubert-sipping-saml-cpc-02 (work in progress), 617 July 2006. 619 [7] Froment, T., "Authorization Policies for Preventing SPIT", 620 draft-froment-sipping-spit-authz-policies-01 (work in 621 progress), June 2006. 623 [8] Mahy, R., "The Calling Party's Category tel URI Parameter", 624 draft-mahy-iptel-cpc-05 (work in progress), October 2006. 626 [9] Jennings, C. and J. Rosenberg, "The Session Initiation Protocol 627 (SIP) and Spam", draft-ietf-sipping-spam-03 (work in progress), 628 October 2006. 630 [10] Rosenberg, J., "Presence Authorization Rules", 631 draft-ietf-simple-presence-rules-08 (work in progress), 632 October 2006. 634 [11] Jennings, C., "Computational Puzzles for SPAM Reduction in 635 SIP", draft-jennings-sip-hashcash-04 (work in progress), 636 March 2006. 638 [12] Rosenberg, J., "A Framework for Consent-Based Communications in 639 the Session Initiation Protocol (SIP)", 640 draft-ietf-sip-consent-framework-01 (work in progress), 641 November 2006. 643 [13] Showalter, T., "Sieve: A Mail Filtering Language", RFC 3028, 644 January 2001. 646 [14] Lennox, J., Wu, X., and H. Schulzrinne, "Call Processing 647 Language (CPL): A Language for User Control of Internet 648 Telephony Services", RFC 3880, October 2004. 650 Authors' Addresses 652 Hannes Tschofenig 653 Siemens Networks GmbH & Co KG 654 Otto-Hahn-Ring 6 655 Munich, Bavaria 81739 656 Germany 658 Email: Hannes.Tschofenig@siemens.com 659 URI: http://www.tschofenig.com 660 Dan Wing 661 Cisco 663 Phone: 664 Email: dwing@cisco.com 666 Henning Schulzrinne 667 Columbia University 668 Department of Computer Science 669 450 Computer Science Building 670 New York, NY 10027 671 US 673 Phone: +1 212 939 7004 674 Email: hgs+ecrit@cs.columbia.edu 675 URI: http://www.cs.columbia.edu 677 Thomas Froment 678 Alcatel-Lucent 679 1, rue Ampere - BP 80056 680 Massy, Paris 91302 681 France 683 Email: Thomas.Froment@alcatel-lucent.fr 685 Geoffrey Dawirs 686 University of Namur 687 21, rue Grandgagnage 688 Namur B-5000 689 Belgique 691 Email: gdawirs@gdawirs.be 693 Full Copyright Statement 695 Copyright (C) The IETF Trust (2007). 697 This document is subject to the rights, licenses and restrictions 698 contained in BCP 78, and except as set forth therein, the authors 699 retain all their rights. 701 This document and the information contained herein are provided on an 702 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 703 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 704 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 705 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 706 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 707 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 709 Intellectual Property 711 The IETF takes no position regarding the validity or scope of any 712 Intellectual Property Rights or other rights that might be claimed to 713 pertain to the implementation or use of the technology described in 714 this document or the extent to which any license under such rights 715 might or might not be available; nor does it represent that it has 716 made any independent effort to identify any such rights. Information 717 on the procedures with respect to rights in RFC documents can be 718 found in BCP 78 and BCP 79. 720 Copies of IPR disclosures made to the IETF Secretariat and any 721 assurances of licenses to be made available, or the result of an 722 attempt made to obtain a general license or permission for the use of 723 such proprietary rights by implementers or users of this 724 specification can be obtained from the IETF on-line IPR repository at 725 http://www.ietf.org/ipr. 727 The IETF invites any interested party to bring to its attention any 728 copyrights, patents or patent applications, or other proprietary 729 rights that may cover technology that may be required to implement 730 this standard. Please address the information to the IETF at 731 ietf-ipr@ietf.org. 733 Acknowledgment 735 Funding for the RFC Editor function is provided by the IETF 736 Administrative Support Activity (IASA).