Network Working Group M. Day Internet-Draft Cisco Expires: May 9, 2001 D. Gilletti Entera November 8, 2000 Content Distribution Network Peering Scenarios draft-day-cdnp-scenarios-02.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 9, 2001. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This document sets forth several logical and detailed scenarios to be considered when evaluating systems and protocols for CDN peering. Discussion List Information This document and related documents are discussed on the cdn mailing list. To join the list, send mail to cdn-request@ops.ietf.org. To contribute to the discussion, send mail to cdn@ops.ietf.org. The archives are at ftp://ops.ietf.org/pub/lists/cdn.*. Day & Gilletti Expires May 9, 2001 [Page 1] Internet-Draft CDNPS November 2000 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Logical Peering Scenarios . . . . . . . . . . . . . . . . . 5 2.1 Expanding Existing CDN Footprint . . . . . . . . . . . . . . 5 2.2 ACCOUNTING and REQUEST DIRECTION Across Multiple DISTIBUTING CDNs . . . . . . . . . . . . . . . . . . . . . . 7 2.3 ACCOUNTING PEERING Across Multiple DISTRIBUTING CDNs . . . . 9 2.4 PUBLISHER peers w/multiple DISTRIBUTING CDNs . . . . . . . . 10 3. Accounting . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.1 Key Assumptions . . . . . . . . . . . . . . . . . . . . . . 12 3.1.1 Content Has Value . . . . . . . . . . . . . . . . . . . . . 12 3.1.2 Distribution Has Value . . . . . . . . . . . . . . . . . . . 12 3.2 Accounting Scenarios . . . . . . . . . . . . . . . . . . . . 13 3.2.1 The Cable Scenario . . . . . . . . . . . . . . . . . . . . . 13 3.2.2 The Telco Scenario . . . . . . . . . . . . . . . . . . . . . 14 3.2.3 The Ticket Scenario . . . . . . . . . . . . . . . . . . . . 14 3.2.4 The Calling Card Scenario . . . . . . . . . . . . . . . . . 14 4. Security Considerations . . . . . . . . . . . . . . . . . . 15 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 16 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 References . . . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 18 Full Copyright Statement . . . . . . . . . . . . . . . . . . 19 Day & Gilletti Expires May 9, 2001 [Page 2] Internet-Draft CDNPS November 2000 1. Introduction This document presents several logical scenarios which are intended to describe the potential configurations that can be realized when peering CDNs. These logical scenarios describe how various entities may combine to provide a complete CDN solution. These scenarios answer two distinct needs: 1. To provide some concrete examples of what CDN peering is, and 2. To provide a basis for evaluating CDN peering proposals. Each of the logical peering scenarios gives an indication of how the various CDN peering systems can be combined. From [2] these peering systems are: 1. DIRECTION PEERING SYSTEM 2. DISTRIBUTION PEERING SYSTEM 3. ACCOUNTING PEERING SYSTEM The peering scenarios presented in this document are also framed by the following concepts: 1. CONTENT Has Value 2. DISTRIBUTION Has Value 3. CLIENTS Have Value Scenarios that reference the above concepts are given within this document in an effort to describe some of the currently known business models. These descriptions are intended to provide guidelines for developing the requirements given in [3]. Terms in ALL CAPS are defined in [1]. Day & Gilletti Expires May 9, 2001 [Page 3] Internet-Draft CDNPS November 2000 2. Logical Peering Scenarios This section provides several logical peering scenarios that may arise in peered CDN implementations. 2.1 Expanding Existing CDN Footprint This scenario considers the case where two or more existing CDNs wish to peer and exchange content in order to provide an increased scale and reach for their existing customers. It assumes that all of these CDNs already provide REDIRECTION, DISTRIBUTION, and ACCOUNTING services and that they will continue to provide these services to existing customers as well as offering them to their peers. In this scenario these CDNs would be interconnected via a CDN PEERING GATEWAY which provides a DIRECTION PEERING SYSTEM, a DISTRIBUTION PEERING SYSTEM, and an ACCOUNTING PEERING SYSTEM. The net result of this peering would be that a larger set of SURROGATES will now be available to the CLIENTs. FIGURE 1 shows three CDNs which have peered to provide greater scale and reach to their existing customers. They are all participating in; DISTRIBUTION PEERING, DIRECTION PEERING, and ACCOUNTING PEERING. As a result of these peering relationships it is assumed that: 1. CONTENT that has been injected into any one of these CDNs (ORIGIN CDN) MAY be distributed into any peered DISTRIBUTING CDN 2. Commands affecting the distribution of CONTENT MAY originate within the ORIGIN CDN or MAY be issued within the DISTRIBUTING CDN 3. Accounting information regarding CLIENT access and/or DISTRIBUTION actions will be made available to the ORIGIN CDN by the DISTRIBUTING CDN 4. The ORIGIN CDN would provide this accounting information to the PUBLISHER based on existing Service Level Agreements (SLAs) 5. Requests by CLIENTS MAY be directed to SURROGATES within any of the peered CDNs The decision of where to direct an individual CLIENT request MAY be dependent upon the DISTRIBUTION and DIRECTION policies associated with the CONTENT being requested as well as the specific algorithms and methods used for directing these requests. It is also worthwhile to consider that any one of these peered CDNs Day & Gilletti Expires May 9, 2001 [Page 4] Internet-Draft CDNPS November 2000 may also have other peering arrangements which may or may not be transitive to peering relationships created for the above purpose. FIGURE 1 - Peering Existing CDNs +--------------+ +--------------+ | CDN A | | CDN B | |..............| +---------+ +---------+ |..............+ | DIRECTION |<=>| |<=>| |<=>| DIRECTION | |..............| | CDN | | CDN | |..............| | DISTRIBUTION |<=>| PEERING |<=>| PEERING |<=>| DISTRIBUTION | |..............| | GATEWAY | | GATEWAY | |..............| | ACCOUNTING |<=>| |<=>| |<=>| ACCOUNTING | |--------------| +---------+ +---------+ +--------------+ | ^ \^ \^ \^ ^/ ^/ ^/ | ^ v | \\ \\ \\ // // // v | +--------------+ \\ \\ \\ // // // +--------------+ | SURROGATES | \\ v\ v\ /v /v // | SURROGATES | +--------------+ \\+---------+// +--------------+ ^ | v| |v ^ | | | | CDN | | | | | | PEERING | | | | | | GATEWAY | | | | | | | | | | | +---------+ | | | | ^| ^| ^| | | | | || || || | | | | |v |v |v | | | | +--------------+ | | | | | CDN C | | | | | |..............| | | | | | DIRECTION | | | | | |..............| | | \ \ | DISTRIBUTION | / / \ \ |..............| / / \ \ | ACCOUNTING | / / \ \ |--------------| / / \ \ | ^ / / \ \ v | / / \ \ +--------------+ / / \ \ | SURROGATES | / / \ \ +--------------+ / / \ \ | ^ / / \ \ | | / / \ \ v | / / \ \ +---------+ / / \ \-->| CLIENTS |---/ / \----| |<---/ +---------+ Day & Gilletti Expires May 9, 2001 [Page 5] Internet-Draft CDNPS November 2000 NOTE: The above FIGURE 1 does not illustrate the CLIENT REQUEST path. It is assumed that the DIRECTION of CLIENT requests follows the methodology given in [2] and that the end result is that the peered DIRECTION SYSTEMs return the IP address of the SURROGATE deemed appropriate to honor the CLIENT's REQUEST. 2.2 ACCOUNTING and REQUEST DIRECTION Across Multiple DISTIBUTING CDNs This scenario describes the case where a single entity (ORG A)performs ACCOUNTING and DIRECTION functions but has no inherent DISTRIBUTION capabilities. This entity must therefore peer with one or more DISTRIBUTING CDNs in order to provide a complete solution. A potential configuration which illustrates this concept is given in FIGURE 2. In the scenario shown in FIGURE 2, ORG A is responsible for collecting ACCOUNTING information from multiple CDNs (CDN A, and CDN B) and providing a "clearing house"/reconciliation function as well as providing a REQUEST DIRECTION service across the peered CDNs. In this scenario, CONTENT is injected into one of the peered CDNs and its DISTRIBUTION between these peered CDNs is controlled via the DISTRIBUTION PEERING SYSTEMs within the peered CPGs. The REQUEST DIRECTION system provided by ORG A is informed of the ability to serve a piece of CONTENT from a particular CDN by the DIRECTION PEERING SYSTEMs within the peered CPGs. ORG A collects statistics and usage information via the ACCOUNTING PEERING SYSTEM and disseminates that information to its peers as appropriate. As illustrated in FIGURE 2, there may be multiple DIRECTION systems employed within the peered CDNs. If the DIRECTION SYSTEM provided by ORG A is the AUTHORITATIVE DIRECTION SYSTEM for a given CONTENT DATA UNIT this is not a problem. However, the individual CDNs may also provide the AUTHORITATIVE DIRECTION SYSTEM for some portion of its existing customers. In this case care must be taken to insure that the tree structure remains intact (i.e. there is one and only one DIRECTION tree for a given CONTENT object). Also, it should be noted that FIGURE 2 does not illustrate the fact that ACCOUNTING PEERING and DIRECTION PEERING MAY also exist between CDN A and CDN B. ORG A could also play an active role in managing the DISTRIBUTION. In this case an additional DISTRIBUTION PEERING relationships are required. Day & Gilletti Expires May 9, 2001 [Page 6] Internet-Draft CDNPS November 2000 FIGURE 2 - Accounting and Request Direction Across Multiple CDNs +--------------+ | ORG A | |..............| +-----------+ | DIRECTION |<===>| | |..............| | CDN | | ACCOUNTING |<===>| PEERING | +--------------+ | GATEWAY | | | +-----------+ ^| ^| ^| ^| +--------------+ // // \\ \\ +--------------+ | CDN A | |v |v |v |v | CDN B | |..............| +---------+ +---------+ |..............| | DIRECTION |<=>| | | |<=>| DIRECTION | |..............| | CDN | | CDN | |..............| | DISTRIBUTION |<=>| PEERING |<=>| PEERING |<=>| DISTRIBUTION | |..............| | GATEWAY | | GATEWAY | |..............| | ACCOUNTING |<=>| | | |<=>| ACCOUNTING | |--------------| +---------+ +---------+ +--------------+ | ^ | ^ v | v | +--------------+ +--------------+ | SURROGATES | | SURROGATES | +--------------+ +--------------+ ^ \ ^ / \ \ / / \ \ / / \ \ / / \ \ +---------+ / / \ \---->| CLIENTS |-----/ / \------| |<-----/ +---------+ As in the previous diagram (FIGURE 1), the communication path(s) between the CLIENT and the REQUEST DIRECTION SYSTEM have been omitted in order to better illustrate the peering connections. It should be noted that FIGURE 2 also omits the (optional) DISTRIBUTION PEERING connection which MAY be implemented between ORG A and any or all of the peered CDNs. It is also worthwhile to consider that any one of these peered entities may also have other peering arrangements which may or may not be transitive to peering relationships created for the above purpose. Day & Gilletti Expires May 9, 2001 [Page 7] Internet-Draft CDNPS November 2000 2.3 ACCOUNTING PEERING Across Multiple DISTRIBUTING CDNs This scenario describes the case where a single ACCOUNTING SYSTEM (ORG A) provides a settlement/clearing-house function and wishes to peer w/multiple DISTRIBUTING CDNs. For the purposes of this scenario it is not necessary to consider the specifics of REQUEST DIRECTION PEERING. In this scenario the entity which operates the ACCOUNTING SYSTEM would enter into ACCOUNTING PEERING relationships w/one or more DISTRIBUTING CDNs as shown in FIGURE 3. FIGURE 3 - Accounting Across Multiple CDNs +--------------+ | ORG A | |..............| +-----------+ | ACCOUNTING |<===>| | +--------------+ | CDN | | PEERING | | GATEWAY | | | +-----------+ ^| ^| +--------------+ // \\ +--------------+ | CDN A | |v |v | CDN B | |..............| +---------+ +---------+ |..............| | DIRECTION |<=>| |<=>| |<=>| DIRECTION | |..............| | CDN | | CDN | |..............| | DISTRIBUTION |<=>| PEERING |<=>| PEERING |<=>| DISTRIBUTION | |..............| | GATEWAY | | GATEWAY | |..............| | ACCOUNTING |<=>| | | |<=>| ACCOUNTING | |--------------| +---------+ +---------+ +--------------+ | ^ | ^ v | v | +--------------+ +--------------+ | SURROGATES | | SURROGATES | +--------------+ +--------------+ ^ \ ^ / \ \ / / \ \ / / \ \ / / \ \ +---------+ / / \ \---->| CLIENTS |-----/ / \------| |<-----/ +---------+ Day & Gilletti Expires May 9, 2001 [Page 8] Internet-Draft CDNPS November 2000 In this scenario, the DISTRIBUTION of CONTENT and the DIRECTION of CLIENT REQUESTs are controlled via the DISTRIBUTION PEERING SYSTEMs and REQUEST DIRECTION PEERING SYSTEMs within the peered CPGs. These systems MAY be decoupled from the ACCOUNTING or they may use information obtained via an optional ACCOUNTING PEERING relationship between CDN A and CDN B. As in the previous diagrams, the communication path(s) between the CLIENT and the REQUEST DIRECTION SYSTEM have been omitted in order to better illustrate the peering connections. It is also worthwhile to consider that any one of these peered entities may also have other peering arrangements which may or may not be transitive to peering relationships created for the above purpose. 2.4 PUBLISHER peers w/multiple DISTRIBUTING CDNs This scenario, shown in FIGURE 4 describes the case where a PUBLISHER wishes to directly enter into peering relationships w/multiple DISTRIBUTING CDNs. In this scenario the PUBLISHER would operate its own CPG and enter into; DISTRIBUTION PEERING, ACCOUNTING PEERING, and REDIRECTION peering with one or more DISTRIBUTING CDNs. FIGURE 4 assumes that the PUBLISHER operates as the FIRST-REDIRECTION SYSTEM for its CONTENT although it is possible that this function may be designated to one of the DISTRIBUTING CDNs. If this delegation occurs then it is not necessary for the PUBLISHER to have an REQUEST DIRECTION PEERING relationship to the DISTRIBUTING CDNs. It likely that a PUBLISHER may also wish to use a third party to perform ACCOUNTING and BILLING. In that case there is no need for an ACCOUNTING PEERING relationship between the PUBLISHER's CPG and those of the DISTRIBUTING CDNs. Likewise, it is possible that the PUBLISHER may only be interested in obtaining additional control over the DISTRIBUTION of its CONTENT. In that case, the only peering relationship that would be required between the PUBLISHER's CPG and those of the DISTRIBUTING CDNs would be a DISTRIBUTION PEERING relationship. As in the previous diagrams, the communication path(s) between the CLIENT and the REQUEST DIRECTION SYSTEM have been omitted in order to better illustrate the peering connections. It is also worthwhile to consider that any one of these peered Day & Gilletti Expires May 9, 2001 [Page 9] Internet-Draft CDNPS November 2000 entities may also have other peering arrangements which may or may not be transitive to peering relationships created for the above purpose. FIGURE 4 - PUBLISHER Peers w/Multiple DISTRIBUTING CDNs +--------------+ | PUBLISHER | |..............| +-----------+ | DIRECTION |<=>| |<---\ |..............| | CDN |----\\ | DISTRIBUTION |<=>| PEERING | \\ |..............| | GATEWAY |--\ \\ | ACCOUNTING |<=>| |<-\\ \\ +--------------+ +-----------+ \\ \\ ^| ^| ^| ^| \\ || +--------------+ || || || \\ || || +--------------+ | CDN A | |v |v |v \v |v |v | CDN B | |..............| +---------+ +---------+ |..............| | DIRECTION |<=>| | | |<=>| DIRECTION | |..............| | CDN | | CDN | |..............| | DISTRIBUTION |<=>| PEERING | | PEERING |<=>| DISTRIBUTION | |..............| | GATEWAY | | GATEWAY | |..............| | ACCOUNTING |<=>| | | |<=>| ACCOUNTING | |--------------| +---------+ +---------+ +--------------+ | ^ | ^ v | v | +--------------+ +--------------+ | SURROGATES | | SURROGATES | +--------------+ +--------------+ ^ \ ^ / \ \ / / \ \ / / \ \ / / \ \ +---------+ / / \ \---->| CLIENTS |-----/ / \------| |<-----/ +---------+ Day & Gilletti Expires May 9, 2001 [Page 10] Internet-Draft CDNPS November 2000 3. Accounting There are several concepts that are helpful to consider when attempting to model the various accounting scenarios that can be realized when peering CDNs. The most fundamental of these is the assignment of value within the distribution exchange. In any distribution system, revenue will generally flow in the direction of value. In order to insure that this revenue flows accurately, it is necessary to provide accurate statistical and access related information to one or more BILLING or ACCOUNTING organizations. In general it can be assumed that accounting information originates within the DISTRIBUTING CDNs and flows towards the BILLING/ACCOUNTING organizations. However it is entirely appropriate to consider that this data may flow through one or more aggregation points. In fact the ability to aggregate statistical and access related information is essential to allow for scalability within the proposed solution. It should be noted that value exists at many points in a peered DISTRIBUTION system. To fully consider this problem one should assume that, in general, any element of the DISTRIBUTION system could have an assigned value associated with its use. This raises some obvious questions about settlement that are outside the scope of this document. A more detailed description of these requirements is contained within [3]. For the purposes of this effort it is sufficient to insure that the appropriate accounting data is capable of being transferred from the measurement point to the BILLING/ACCOUNTING system. 3.1 Key Assumptions The distribution of accounting information, like the distribution of content, is greatly affected by the following concepts. 3.1.1 Content Has Value This concept assumes that the content has intrinsic value and that the revenue (and ACCOUNTING information) flows from the consumer to the CONTENT PROVIDER. A consumer, as defined in this relationship, is the entity that consumes data. Therefore the consumer may be a CLIENT or a SURROGATE. An example of this concept would include services such as Video On Demand (VOD). 3.1.2 Distribution Has Value This concept describes the situation where the value is located Day & Gilletti Expires May 9, 2001 [Page 11] Internet-Draft CDNPS November 2000 within the CDN service being provided. In this case the revenue as well as the statistical and access information flow toward the CDN that provides the service. (NOTE: There may be other ACCOUNTING flows in addition to the one described.) When considering this case, it is a reasonable assumption to consider that the majority of the statistical and access information would be produced and consumed within the CDN service provider's domain and is therefore not important to consider. However, it is not reasonable to assume that all such information is obtained in this manner. The latter is especially true when a third-party BILLING ORGANIZATION or complex peering arrangements are in place. An example of this case is where a service provider has an aggregated CLIENT population which is of sufficient interest to one or more PUBLISHERs. In this case the PUBLISHERs are willing to pay to access the CLIENTs of the service provider and revenue flows from the PUBLISHER to the service provider. 3.2 Accounting Scenarios There are four basic conceptual accounting scenarios that SHOULD be considered when describing the requirements for the peering of accounting events between peered distribution entities:[Editor's Note: Other models suitable for real-time provisioning may be added to this proposal over time.] o Flat Rate Accounting Scenario - (aka "The Cable Scenario) o Metered Accounting Scenario - (aka "The Telco Scenario") o Prepay Event Accounting Scenario - (aka "The Ticket Scenario") o Prepay Metered Accounting Scenario - (aka "The Calling Card Scenario") These scenarios are described in the following sections. 3.2.1 The Cable Scenario In this scenario there is a "subscription" fee associated with the reception of CONTENT. In its primary mode it consists of a CLIENT entering into a transaction, either directly with the CONTENT PROVIDER or through some third party, for the purposes of obtaining access to one or more CONTENT objects. Once the transaction has been approved the CLIENT receives an entitlement to access the requested CONTENT for the duration of the subscription interval. An extension to this scenario is the case where a given DISTRIBUTING Day & Gilletti Expires May 9, 2001 [Page 12] Internet-Draft CDNPS November 2000 CDN enters into a redistribution agreement with a CONTENT PROVIDER. In this scenario, the scope of the transaction is between the CONTENT PROVIDER and the specific DISTRIBUTION CDN. Once the transaction is successful, the DISTRIBUTION CDN obtains the right to redistribute that content in some mutually agreed upon manner. The manner of redistribution can range from unlimited to highly restricted. The resultant accounting information for this scenario consists of a single transaction which is associated with a specific consumer or CLIENT. 3.2.2 The Telco Scenario This scenario associates a finite value with the access or consumption of one or more CONTENT objects and attempts to fully control and/or account for access to this CONTENT. The resultant accounting information for this scenario is a set of detailed or summary accounting records associated with a specific CLIENT. 3.2.3 The Ticket Scenario In this scenario the CLIENT obtains a ticket (or entitlement) in advance of accessing the CONTENT. This is accomplished by a transaction between the CLIENT and the PUBLISHER or their agent(s). The ticket is assumed to be a one-time entitlement which expires upon use. 3.2.4 The Calling Card Scenario In this scenario a CLIENT prepays and receives an entitlement to access a set of CONTENT OBJECTS up to some pre-specified value level. The total value of the entitlement is determined at the time of purchase and its value is decremented each time the CLIENT accesses the CONTENT or CDN service. The amount of the decrement will be specific to the CONTENT or CDN service being accessed. The CLIENT is able to continue accessing or consuming the CONTENT or CDN service until the entitlement is fully depleted. Day & Gilletti Expires May 9, 2001 [Page 13] Internet-Draft CDNPS November 2000 4. Security Considerations This document describes scenarios for use in evaluating CDN peering proposals. As such, it does not propose any solutions which might have security concerns. This document assumes that any peering solutions which are derived within the context of Content Alliance effort will be compliant with the trust model given in [4]. Day & Gilletti Expires May 9, 2001 [Page 14] Internet-Draft CDNPS November 2000 5. Conclusion The set of scenarios contained within this document illustrate the complete set of requirements which should be met in the design of CDN peering system(s). Day & Gilletti Expires May 9, 2001 [Page 15] Internet-Draft CDNPS November 2000 6. Acknowledgements The authors acknowledge the contributions and comments of Fred Douglis (AT&T), Raj Nair (Cisco), Gary Tomlinson (Entera), and John Scharber (Entera). Day & Gilletti Expires May 9, 2001 [Page 16] Internet-Draft CDNPS November 2000 References [1] Day, M., Cain, B. and G. Tomlinson, "A Model for CDN Peering", draft-day-cdnp-model-02.txt (work in progress), November 2000, . [2] Green, M., Cain, B. and G. Tomlinson, "CDN Peering Architectural Overview", draft-green-cdnp-gen-arch-02.txt (work in progress), November 2000, . [3] Gilletti, D., Nair, R. and J. Scharber, "CDN Peering Authentication, Authorization, and Accounting Requirements", draft-gilletti-cdnp-aaa-reqs-00.txt (work in progress), November 2000, . [4] Aboba, B., Arkko, J. and D. Harrington, "Introduction to Accounting Management", RFC 2975, October 2000, . Authors' Addresses Mark S. Day Cisco Systems 135 Beaver Street Waltham, MA 02452 US Phone: +1 781 663 8310 EMail: markday@cisco.com Don Gilletti Entera, Inc. 40971 Encyclopedia Circle Fremont, CA 94538 US Phone: +1 510 770 5281 EMail: don@entera.com Day & Gilletti Expires May 9, 2001 [Page 17] Internet-Draft CDNPS November 2000 Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC editor function is currently provided by the Internet Society. Day & Gilletti Expires May 9, 2001 [Page 18]