--- 1/draft-ietf-cdni-use-cases-02.txt 2012-01-30 12:13:56.218671536 +0100 +++ 2/draft-ietf-cdni-use-cases-03.txt 2012-01-30 12:13:56.250671537 +0100 @@ -1,24 +1,24 @@ Internet Engineering Task Force G. Bertrand, Ed. Internet-Draft E. Stephan Intended status: Informational France Telecom - Orange -Expires: July 21, 2012 G. Watson +Expires: August 2, 2012 G. Watson T. Burbridge P. Eardley BT K. Ma Azuki Systems - January 18, 2012 + January 30, 2012 Use Cases for Content Delivery Network Interconnection - draft-ietf-cdni-use-cases-02 + draft-ietf-cdni-use-cases-03 Abstract Content Delivery Networks (CDNs) are commonly used for improving the End User experience of a content delivery service, at a reasonable cost. This document outlines real world use cases (not technical solutions) for interconnecting CDNs. It focuses on use cases that correspond to identified industry needs and that are expected to be realized once a CDN Interconnection (CDNI) solution is available. This document can be used to provide guidance to the CDNI WG about @@ -33,21 +33,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." - This Internet-Draft will expire on July 21, 2012. + This Internet-Draft will expire on August 2, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -457,22 +457,21 @@ understanding of origin server availability and be better equipped to both distribute load between origin servers and attempt content acquisition from alternate origin servers when acquisition failures occur. When normal content acquisition fails, a CDN may need to try other origin server options, e.g.: o an upstream CDN may acquire content from an alternate CSP origin server, o a downstream CDN may acquire content from an alternate Surrogate - within an upstream CDN, as directed by the upstream CDN's request - routing interface, + within an upstream CDN, o a downstream CDN may acquire content from an alternate upstream CDN, or o a downstream CDN may acquire content directly from the CSP's origin server. Though content acquisition protocols are beyond the scope of CDNI, the selection of content acquisition sources should be considered. @@ -586,31 +585,31 @@ An uCDN needs to be able to exclude dCDNs which lack support for the secure access features requested by the CSP. 5.3. Branding Preserving the branding of the CSP throughout delivery is often important to the CSP. CSPs may desire to offer content services under their own name, even when the associated CDN service involves other CDN Providers. For instance, a CSP may desire to ensure that - content is delivered with URIs appearing to the endusers under the + content is delivered with URIs appearing to the End Users under the CSP's own domain name, even when the content delivery involves separate CDN Providers. The CSP may wish to forbid the delivery of its content by specific dCDNs that lack support for such branding preservation features. - Similar restrictions may exist when the uCDN wants to offer CDN + Analogous restrictions may exist when the uCDN wants to offer CDN services under its own branding even if dCDNs are involved. - Conversely, a CDN Provider might not want the brand of a CDN Exchange - to be visible, even if the CDN Exchange is involved in the content - delivery call flow. + Similarly, a CDN Provider might not want the brand of an intermediary + in the CDN delegation chain to be visible, even if the intermediary + is involved in the content delivery call flow. 6. Acknowledgments The authors would like to thank Kent Leung, Francois Le Faucheur, Ben Niven-Jenkins, and Scott Wainner for lively discussions, as well as for their reviews and comments on the mailing list. They also thank the contributors of the EU FP7 OCEAN and ETICS projects for valuable inputs. @@ -634,21 +633,21 @@ b. The relationship between the uCDN and dCDN: the transitive trust relationship that extends the contract defined in (a) above and that authorizes the dCDN to acquire content on uCDN's or CSP's origin servers and to deliver it, potentially with content delivery restrictions. c. The relationship between the End User and dCDN: the recognition of right to download predicated on (b) above. d. The relationship between the End User and the CSP: the contract - that authorizes the End User to access to the content. + that authorizes the End User to access the content. CDNI should enable the four parties (CSP, uCDN, dCDN, End User) to negotiate a security method or a method for confirming authorization along the chain of trust (CSP -> uCDN -> dCDN -> End User). The security issues fall into three general categories: o CSP Trust: where the CSP may have negotiated service level agreements for delivery quality of service with the uCDN, and/or configured distribution policies (e.g., geo-restrictions, @@ -694,21 +693,21 @@ August 2011. [I-D.davie-cdni-framework] Davie, B. and L. Peterson, "Framework for CDN Interconnection", draft-davie-cdni-framework-01 (work in progress), October 2011. [I-D.ietf-cdni-problem-statement] Niven-Jenkins, B., Faucheur, F., and N. Bitar, "Content Distribution Network Interconnection (CDNI) Problem - Statement", draft-ietf-cdni-problem-statement-02 (work in + Statement", draft-ietf-cdni-problem-statement-03 (work in progress), January 2012. [I-D.ietf-cdni-requirements] Leung, K. and Y. Lee, "Content Distribution Network Interconnection (CDNI) Requirements", draft-ietf-cdni-requirements-02 (work in progress), December 2011. [RFC3466] Day, M., Cain, B., Tomlinson, G., and P. Rzewski, "A Model for Content Internetworking (CDI)", RFC 3466,