From johan.rydberg@edgeware.tv Thu Aug 4 02:52:42 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2768E21F8582 for ; Thu, 4 Aug 2011 02:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ByPCS1QR-ckL for ; Thu, 4 Aug 2011 02:52:41 -0700 (PDT) Received: from mail.edgeware.tv (mail.edgeware.tv [94.127.35.114]) by ietfa.amsl.com (Postfix) with ESMTP id 8539021F8569 for ; Thu, 4 Aug 2011 02:52:41 -0700 (PDT) Received: from kalm.local (m83-185-122-60.cust.tele2.se [83.185.122.60]) by mail.edgeware.tv (Postfix) with ESMTPA id 48F3A19100A4 for ; Thu, 4 Aug 2011 11:52:52 +0200 (CEST) Message-ID: <4E3A6BEE.4080301@edgeware.tv> Date: Thu, 04 Aug 2011 11:52:46 +0200 From: Johan Rydberg User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.16) Gecko/20101125 Thunderbird/3.0.11 MIME-Version: 1.0 To: "cdni@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [CDNi] upstream cdn enforce content policies X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 09:52:42 -0000 After following the discussions for a while, I have a question: Instead of constructing a complex metadata exchange protocol, why not force the upstream CDN to enforce any prolicy rules that the CSP has put on the content? In the case of DNS-based routing, the CDN can answer the DNS lookup with the address of one of its own CDNI request routers that will enforce any policies before redirecting (HTTP 302) to a downstream CDN. The upside to this is that redirects between CDNs will always be HTTP 302, regardless if the initial mechanism was DNS-based. Also, the complex metadata protocol can be elimited, minimizing the scope of the CDNI work. - Johan Rydberg From ben@niven-jenkins.co.uk Thu Aug 4 03:10:41 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6939821F8B6F for ; Thu, 4 Aug 2011 03:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.568 X-Spam-Level: X-Spam-Status: No, score=-103.568 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1TH8XR1d1rVl for ; Thu, 4 Aug 2011 03:10:40 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id B977621F8B6A for ; Thu, 4 Aug 2011 03:10:40 -0700 (PDT) Received: from host1.cachelogic.com ([212.44.43.80] helo=dhcp-105-devlan.cachelogic.com) by mail10.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1QoutB-0005VY-NP; Thu, 04 Aug 2011 11:10:54 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: <4E3A6BEE.4080301@edgeware.tv> Date: Thu, 4 Aug 2011 11:10:52 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8AF4C086-7E25-4931-9BF7-7DC7F44A9D2C@niven-jenkins.co.uk> References: <4E3A6BEE.4080301@edgeware.tv> To: Johan Rydberg X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: "cdni@ietf.org" Subject: Re: [CDNi] upstream cdn enforce content policies X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 10:10:41 -0000 Johan, On 4 Aug 2011, at 10:52, Johan Rydberg wrote: > After following the discussions for a while, I have a question: >=20 > Instead of constructing a complex metadata exchange protocol, > why not force the upstream CDN to enforce any prolicy rules that > the CSP has put on the content? That would not provide sufficient coverage to ensure that the policy is = enforced as clients may attempt to request content directly from a = downstream CDN, bypassing the upstream CDN. > In the case of DNS-based routing, the CDN can answer the DNS > lookup with the address of one of its own CDNI request routers > that will enforce any policies before redirecting (HTTP 302) to > a downstream CDN. >=20 > The upside to this is that redirects between CDNs will always be > HTTP 302, regardless if the initial mechanism was DNS-based. > Also, the complex metadata protocol can be elimited, minimizing > the scope of the CDNI work. Even if one could avoid the need for a downstream CDN to apply some = policies, this wouldn't eliminate the need to exchange CDNI metadata as = other CDNI metadata such as rate limiting, whether an encrypted channel = is required, where to obtain the content from etc. is still required. From johan.rydberg@edgeware.tv Thu Aug 4 03:16:20 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7E2C21F8B11 for ; Thu, 4 Aug 2011 03:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Z3r3SGfNlKr for ; Thu, 4 Aug 2011 03:16:20 -0700 (PDT) Received: from mail.edgeware.tv (mail.edgeware.tv [94.127.35.114]) by ietfa.amsl.com (Postfix) with ESMTP id 193CC21F8B10 for ; Thu, 4 Aug 2011 03:16:20 -0700 (PDT) Received: from kalm.local (m83-185-122-60.cust.tele2.se [83.185.122.60]) by mail.edgeware.tv (Postfix) with ESMTPA id 203C619100A7; Thu, 4 Aug 2011 12:16:31 +0200 (CEST) Message-ID: <4E3A7178.6080400@edgeware.tv> Date: Thu, 04 Aug 2011 12:16:24 +0200 From: Johan Rydberg User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.16) Gecko/20101125 Thunderbird/3.0.11 MIME-Version: 1.0 To: Ben Niven-Jenkins References: <4E3A6BEE.4080301@edgeware.tv> <8AF4C086-7E25-4931-9BF7-7DC7F44A9D2C@niven-jenkins.co.uk> In-Reply-To: <8AF4C086-7E25-4931-9BF7-7DC7F44A9D2C@niven-jenkins.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "cdni@ietf.org" Subject: Re: [CDNi] upstream cdn enforce content policies X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 10:16:20 -0000 On 8/4/11 12:10 PM, Ben Niven-Jenkins wrote: > Johan, > > On 4 Aug 2011, at 10:52, Johan Rydberg wrote: > > >> After following the discussions for a while, I have a question: >> >> Instead of constructing a complex metadata exchange protocol, >> why not force the upstream CDN to enforce any prolicy rules that >> the CSP has put on the content? >> > That would not provide sufficient coverage to ensure that the policy is enforced as clients may attempt to request content directly from a downstream CDN, bypassing the upstream CDN. > There must be ways to make sure that the client first passes through the upstream CDN. I have a feeling that if the interconnect protocols are not limited in scope, this CDNI effort will either (1) fail or (2) be in some "design phase" for ever. > >> In the case of DNS-based routing, the CDN can answer the DNS >> lookup with the address of one of its own CDNI request routers >> that will enforce any policies before redirecting (HTTP 302) to >> a downstream CDN. >> >> The upside to this is that redirects between CDNs will always be >> HTTP 302, regardless if the initial mechanism was DNS-based. >> Also, the complex metadata protocol can be elimited, minimizing >> the scope of the CDNI work. >> > Even if one could avoid the need for a downstream CDN to apply some policies, this wouldn't eliminate the need to exchange CDNI metadata as other CDNI metadata such as rate limiting, whether an encrypted channel is required, where to obtain the content from etc. is still required. > It sounds like most of those could be folded into the request routing protocol. Rate limiting and encryption might not be attributes of the content, but rather of the client. (Some customers pay more, and get a higher bitrate for example) From ben@niven-jenkins.co.uk Thu Aug 4 03:54:30 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03B7D21F8B27 for ; Thu, 4 Aug 2011 03:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.573 X-Spam-Level: X-Spam-Status: No, score=-103.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v89D31YX2Rt1 for ; Thu, 4 Aug 2011 03:54:29 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.64]) by ietfa.amsl.com (Postfix) with ESMTP id 380DD21F8B26 for ; Thu, 4 Aug 2011 03:54:29 -0700 (PDT) Received: from host1.cachelogic.com ([212.44.43.80] helo=dhcp-105-devlan.cachelogic.com) by mail6.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1QovZX-0005JF-Bs; Thu, 04 Aug 2011 11:54:39 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: <4E3A7178.6080400@edgeware.tv> Date: Thu, 4 Aug 2011 11:54:42 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E3A6BEE.4080301@edgeware.tv> <8AF4C086-7E25-4931-9BF7-7DC7F44A9D2C@niven-jenkins.co.uk> <4E3A7178.6080400@edgeware.tv> To: Johan Rydberg X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: "cdni@ietf.org" Subject: Re: [CDNi] upstream cdn enforce content policies X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 10:54:30 -0000 Johan, On 4 Aug 2011, at 11:16, Johan Rydberg wrote: > On 8/4/11 12:10 PM, Ben Niven-Jenkins wrote: >> Johan, >>=20 >> On 4 Aug 2011, at 10:52, Johan Rydberg wrote: >>=20 >> =20 >>> After following the discussions for a while, I have a question: >>>=20 >>> Instead of constructing a complex metadata exchange protocol, >>> why not force the upstream CDN to enforce any prolicy rules that >>> the CSP has put on the content? >>> =20 >> That would not provide sufficient coverage to ensure that the policy = is enforced as clients may attempt to request content directly from a = downstream CDN, bypassing the upstream CDN. >> =20 > There must be ways to make sure that the client first passes through = the upstream > CDN. I don't see how you can guarantee that behaviour. For example, how do you handle the upstream request router being the = only policy enforcement point if a client (after being redirected by a = request router) holds a persistent HTTP connection open to the surrogate = and uses it to request multiple pieces of content? > I have a feeling that if the interconnect protocols are not limited in = scope, this > CDNI effort will either (1) fail or (2) be in some "design phase" for = ever. There are two parts to that: (1) what interfaces does CDNI need to = support and (2) what is the scope of data/functionality that needs to be = incorporated into each interfaces. Removing the metadata interface (and stuffing the resultant = functionality into request routing as you suggest below) doesn't reduce = the design work required it just moves it to a different interface. I agree that we need to constrain the scope of data/functionality we = incorporate into each interface to a pragmatic set that is capable of = delivering the required services so as not to end up "boiling the ocean" = but hiding metadata functionality in another interface doesn't achieve = that. =20 >>> In the case of DNS-based routing, the CDN can answer the DNS >>> lookup with the address of one of its own CDNI request routers >>> that will enforce any policies before redirecting (HTTP 302) to >>> a downstream CDN. >>>=20 >>> The upside to this is that redirects between CDNs will always be >>> HTTP 302, regardless if the initial mechanism was DNS-based. >>> Also, the complex metadata protocol can be elimited, minimizing >>> the scope of the CDNI work. >>> =20 >> Even if one could avoid the need for a downstream CDN to apply some = policies, this wouldn't eliminate the need to exchange CDNI metadata as = other CDNI metadata such as rate limiting, whether an encrypted channel = is required, where to obtain the content from etc. is still required. >> =20 > It sounds like most of those could be folded into the request routing = protocol. > Rate limiting and encryption might not be attributes of the content, = but rather > of the client. (Some customers pay more, and get a higher bitrate for = example) You can't assume that request routing has happened for every request = (see above) and even if you could, doing so would introduce a degree of = coupling between surrogates and request routers that IMO is undesirable. Ben =20 From ben@niven-jenkins.co.uk Thu Aug 4 06:04:37 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A175E21F8AFD for ; Thu, 4 Aug 2011 06:04:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.577 X-Spam-Level: X-Spam-Status: No, score=-103.577 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YQ4uF02WxeuM for ; Thu, 4 Aug 2011 06:04:37 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id 18FE421F8B2C for ; Thu, 4 Aug 2011 06:04:37 -0700 (PDT) Received: from host1.cachelogic.com ([212.44.43.80] helo=dhcp-105-devlan.cachelogic.com) by mail11.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1QoxbW-0003H9-Cn for cdni@ietf.org; Thu, 04 Aug 2011 14:04:50 +0100 From: Ben Niven-Jenkins Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 4 Aug 2011 14:04:49 +0100 Message-Id: <7D5A9C99-E984-4D64-A03B-AD646A39A405@niven-jenkins.co.uk> To: cdni@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Subject: [CDNi] Updating the CDNI Problem Statement as agreed last week X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 13:04:37 -0000 Colleagues, I have summarised below the changes to the Problem Statement draft that = were agreed during the face to face CDNI meeting last week as well as = those which have been suggested on the mailing list or to me privately. Feel free to remind me of anything I have forgotten or misremembered. In the absence of any further discussion on the mailing list related to = these suggested changes, I will go ahead and update the Problem = Statement draft with these changes in the next few weeks. 1) Add an Appendix to the document titled "Additional Material" (if = anyone can think of a better title feel free ti suggest it) including = the following statement "Note to RFC Editor: this section is to be = removed on publication as an RFC." and move the following sections into = that appendix: (a) Section 3.2. "Non-Goals for IETF" (except for the final paragraph = of that section which will be moved to the end of Section 3.1). (b) Section 5. "Prioritizing the CDNI Work". (c) Section 6.1. "Related standardization activities". (d) Section 6.2. "Related Research Projects". 2) Update Figure 1 "CDNI Problem Area" to reflect the consensus of the = group as judged by the chairs with respect to including: (a) A "Request" interface (labelled out of scope for CDNI) between the = Downstream Surrogate and the Upstream Request Router. (b) An "internal" interface (labelled out of scope for CDNI) between = the Control function and the Surrogate function in each of the CDNs. 3) Align the terminology in the Problem Statement with that used in the = WG charter, i.e. to use "interface" instead of "protocol" when referring = to CDNI interfaces. 4) Incorporate the 24 minor corrections/comments provided by Kent Leung Ben From ben@niven-jenkins.co.uk Thu Aug 4 06:06:24 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C57921F8B3D for ; Thu, 4 Aug 2011 06:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.579 X-Spam-Level: X-Spam-Status: No, score=-103.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u1QvTjNs1nzD for ; Thu, 4 Aug 2011 06:06:23 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id 70F5421F8B5A for ; Thu, 4 Aug 2011 06:06:23 -0700 (PDT) Received: from host1.cachelogic.com ([212.44.43.80] helo=dhcp-105-devlan.cachelogic.com) by mail11.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1QoxdF-00071S-Eu; Thu, 04 Aug 2011 14:06:37 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Ben Niven-Jenkins In-Reply-To: Date: Thu, 4 Aug 2011 14:06:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Bitar, Nabil N" X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: "cdni@ietf.org" Subject: Re: [CDNi] Definitions for "Recursive/Iterative CDNI request routing" X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 13:06:24 -0000 I don't hold a strong opinion but the framework seems a slightly better = place IMO if for no other reason than because the Problem Statement = doesn't currently use either of these terms. Ben On 27 Jul 2011, at 14:53, Bitar, Nabil N wrote: > Hi, > I think that the framework or problem statement document is more = appropriate than the requirements document. The framework document now = refers to terminology and definitions in the problem statement document, = so it could be there. However, I think sit is better fit in he framework = document. >=20 > Thanks, > Nabil >=20 > From: Francois Le Faucheur > Date: Tue, 26 Jul 2011 15:36:20 -0400 > To: Niven-Jenkins Ben , "Bitar, Nabil N" = , Bruce Davie , Larry = Peterson > Cc: "cdni@ietf.org" , Le Faucheur Francois = > Subject: Re: Definitions for "Recursive/Iterative CDNI request = routing" >=20 > Hi, > Any thoughts on that before the WG meeting? > Francois >=20 > On 8 Jul 2011, at 14:01, Francois Le Faucheur wrote: >=20 >> Folks, >>=20 >> The definitions for the terms of "Recursive/Iterative CDNI request = routing" had been included in the cdni-requirements document until they = move to a more suitable place. >> Could you guys agree on which document these definitions should = migrate into (problem-statement or framework) and keep a mental note to = include it there in the next rev? >>=20 >> Thanks >>=20 >> Francois >>=20 >> PS: Here is the relevant excerpt from cdni-framework: >>=20 >> " >> This also defined the following additional terms [Editor's Note: >> these definitions may be better located in another document such as >> the Problem Statement]: >>=20 >> o Recursive CDNI request routing: When an Upstream CDN elects to >> redirect a request towards a Downstream CDN, the Upstream CDN = can >> query the Downstream CDN Request Routing system via the CDNI >> Request Routing protocol (or use information cached from earlier >> similar queries) to find out how the Downstream CDN wants the >> request to be redirected, which allows the Upstream CDN to = factor >> in the Downstream CDN response when redirecting the user agent. >> This approach is referred to as "recursive" CDNI request = routing. >> Note that the Downstream CDN may elect to have the request >> redirected directly to a Surrogate inside the Downstream CDN, to >> the Request-Routing System of the Downstream CDN, to another = CDN, >> or to any other system that the Downstream CDN sees as fit for >> handling the redirected request. >>=20 >> o Iterative CDNI Request Routing: When an Upstream CDN elects to >> redirect a request towards a Downstream CDN, the Upstream CDN = can >> base its redirection purely on a local decision (and without >> attempting to take into account how the Downstream CDN may in = turn >> redirect the user agent). In that case, the Upstream CDN >> redirects the request to the request routing system in the >> Downstream CDN, which in turn will decide how to redirect that >> request: this approach is referred to as "iterative" CDNI = request >> routing. >> " >>=20 >> Francois >=20 > >=20 > Francois Le Faucheur > Distinguished Engineer > Corporate Development > flefauch@cisco.com > Phone: +33 49 723 2619 > Mobile: +33 6 19 98 50 90 >=20 >=20 >=20 > Cisco Systems France > Greenside > 400 Ave de Roumanille > 06410 Sophia Antipolis > France > Cisco.com >=20 >=20 > =20 >=20 > > Think before you print. >=20 > This email may contain confidential and privileged material for the = sole use of the intended recipient. Any review, use, distribution or = disclosure by others is strictly prohibited. If you are not the intended = recipient (or authorized to receive for the recipient), please contact = the sender by reply email and delete all copies of this message. >=20 > Cisco Systems France, Soci=E9t=E9 =E0 responsabiit=E9 limit=E9e, Rue = Camille Desmoulins =96 Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy = les Moulineaux, Au capital de 91.470 =80, 349 166 561 RCS Nanterre, = Directeur de la publication: Jean-Luc Michel Givone. >=20 > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html >=20 >=20 From ben@niven-jenkins.co.uk Thu Aug 4 07:22:26 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CEBF21F8B85 for ; Thu, 4 Aug 2011 07:22:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.582 X-Spam-Level: X-Spam-Status: No, score=-103.582 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ij1fHz24OAA for ; Thu, 4 Aug 2011 07:22:23 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.64]) by ietfa.amsl.com (Postfix) with ESMTP id 232BA21F8B73 for ; Thu, 4 Aug 2011 07:22:23 -0700 (PDT) Received: from host1.cachelogic.com ([212.44.43.80] helo=dhcp-105-devlan.cachelogic.com) by mail5.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1Qoyon-0003na-6h; Thu, 04 Aug 2011 15:22:37 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: Date: Thu, 4 Aug 2011 15:22:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0160D539-A630-4BCB-BC25-D50881FCFEDF@niven-jenkins.co.uk> References: <1AC8E92C-3A69-4C80-A235-710DEF396A53@cisco.com> <2979E38DD6FC6544B789C8DAD7BAFC520F72CD55@xmb-sjc-235.amer.cisco.com> To: Francois Le Faucheur X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: cdni@ietf.org, draft-bertrand-cdni-use-cases@tools.ietf.org Subject: Re: [CDNi] comments on draft-bertrand-cdni-use-cases-02 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 14:22:26 -0000 Use Case authors, Colleagues, On 28 Jul 2011, at 21:16, Francois Le Faucheur wrote: > Kent and all, >=20 > On 28 Jul 2011, at 16:10, Kent Leung (kleung) wrote: >=20 >> Hi Francois. Responding to comments related to the requirements = draft >> below. >>=20 >>=20 >> o an expiration time (i.e., the time at which the content files >> should be expunged from all CDN storage). >> " >> I understand this is saying that CDNI metadata need to include this >> expiration time (triggering cache removal) , in addition to = deactivation >> time.=20 >> I don't think this is discussed in cdni-requirements yet. Can you = bring >> that up on the list with the cdni-reqts authors? >>=20 >> KL> I've seen references to content expiration time (i.e. removal) in >> some drafts. So it seems to be needed in the CDNI Metadata. Noted = as >> requirement (possibly part of availability window) unless others = object. >=20 > FLF as an Individual: that works for me. I'd like to understand the underlying requirement a bit better as it's = not clear to me what the expected behaviour of a surrogate would be when = receiving a request for the content after the "expiration time" is = reached as well as how the surrogate is supposed to treat any cached = copy of the content held in either volatile or non-volatile storage. For example, when receiving a request for content after the "expiration = time" is reached, is a surrogate required to: - No longer deliver the content, even if presented with a valid request = to do? - Consider any cached copy of the content as "stale" and revalidate the = content against the Origin, delivering the content if revalidation = succeeds and not delivering the content if revalidation fails. For example, for any cached copy of the content after the "expiration = time" is reach, is a surrogate required to: - Nothing more than whatever it is supposed to do in the example above = and use its normal cache expiration procedures to recovery the storage = space used like it would for "stale" content that does not have an = explicit expiration time?=20 - Actively keep track of cached content & its associated expiration time = and actively "de-link" (e.g. remove from the filesystem table) the = cached copy of the content?=20 - Actively keep track of cached content & its associated expiration time = and actively overwrite the storage sectors containing that content in = both volatile & non-volatile storage? Thanks Ben From richard_woundy@cable.comcast.com Thu Aug 4 07:38:16 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 898D721F8B21 for ; Thu, 4 Aug 2011 07:38:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.417 X-Spam-Level: X-Spam-Status: No, score=-103.417 tagged_above=-999 required=5 tests=[AWL=-1.682, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id llUKLmaYGX9H for ; Thu, 4 Aug 2011 07:38:16 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id 541D021F8B1C for ; Thu, 4 Aug 2011 07:38:15 -0700 (PDT) Received: from ([24.40.55.42]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.47494522; Thu, 04 Aug 2011 08:39:43 -0600 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%11]) with mapi id 14.01.0289.001; Thu, 4 Aug 2011 10:34:42 -0400 From: "Woundy, Richard" To: Johan Rydberg , Ben Niven-Jenkins Thread-Topic: [CDNi] upstream cdn enforce content policies Thread-Index: AQHMUoxOe9o5Dl8G80aFZBDqzy+b85UMu4oAgAABiwCAAAIFEA== Date: Thu, 4 Aug 2011 14:34:40 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD11360E6C4@PACDCEXMB05.cable.comcast.com> References: <4E3A6BEE.4080301@edgeware.tv> <8AF4C086-7E25-4931-9BF7-7DC7F44A9D2C@niven-jenkins.co.uk> <4E3A7178.6080400@edgeware.tv> In-Reply-To: <4E3A7178.6080400@edgeware.tv> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.191.223.245] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] upstream cdn enforce content policies X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 14:38:16 -0000 A couple of observations, as an individual and not a working group chair. > Instead of constructing a complex metadata exchange protocol How about we construct a *simple* metadata exchange protocol? :) I believe we are anticipating this protocol to be XML/JSON over HTTP. > I have a feeling that if the interconnect protocols are not limited in sc= ope, this CDNI effort will either (1) fail or (2) be in some "design phase"= for ever. CDNI was approved as a WG in late June. Now it is early August and we're al= ready in danger of failing? Hmmm. It feels to me like we are debating theoretical scenarios. Johan, if you fe= el strongly about eliminating this interface, maybe you could write up your= proposal as an internet-draft that we can discuss and debate? We also need= to ensure that your proposal meets the use cases identified by this group. -- Rich -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Joh= an Rydberg Sent: Thursday, August 04, 2011 6:16 AM To: Ben Niven-Jenkins Cc: cdni@ietf.org Subject: Re: [CDNi] upstream cdn enforce content policies On 8/4/11 12:10 PM, Ben Niven-Jenkins wrote: > Johan, > > On 4 Aug 2011, at 10:52, Johan Rydberg wrote: > > =20 >> After following the discussions for a while, I have a question: >> >> Instead of constructing a complex metadata exchange protocol, >> why not force the upstream CDN to enforce any prolicy rules that >> the CSP has put on the content? >> =20 > That would not provide sufficient coverage to ensure that the policy is e= nforced as clients may attempt to request content directly from a downstrea= m CDN, bypassing the upstream CDN. > =20 There must be ways to make sure that the client first passes through the=20 upstream CDN. I have a feeling that if the interconnect protocols are not limited in=20 scope, this CDNI effort will either (1) fail or (2) be in some "design phase" for ever. > =20 >> In the case of DNS-based routing, the CDN can answer the DNS >> lookup with the address of one of its own CDNI request routers >> that will enforce any policies before redirecting (HTTP 302) to >> a downstream CDN. >> >> The upside to this is that redirects between CDNs will always be >> HTTP 302, regardless if the initial mechanism was DNS-based. >> Also, the complex metadata protocol can be elimited, minimizing >> the scope of the CDNI work. >> =20 > Even if one could avoid the need for a downstream CDN to apply some polic= ies, this wouldn't eliminate the need to exchange CDNI metadata as other CD= NI metadata such as rate limiting, whether an encrypted channel is required= , where to obtain the content from etc. is still required. > =20 It sounds like most of those could be folded into the request routing=20 protocol. Rate limiting and encryption might not be attributes of the content, but=20 rather of the client. (Some customers pay more, and get a higher bitrate for=20 example) _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni From ben@niven-jenkins.co.uk Thu Aug 4 07:45:01 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2293C21F8A91 for ; Thu, 4 Aug 2011 07:45:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.283 X-Spam-Level: X-Spam-Status: No, score=-103.283 tagged_above=-999 required=5 tests=[AWL=-0.284, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jaE1ZhTtzYuq for ; Thu, 4 Aug 2011 07:45:00 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.64]) by ietfa.amsl.com (Postfix) with ESMTP id 6668121F8A7D for ; Thu, 4 Aug 2011 07:45:00 -0700 (PDT) Received: from host1.cachelogic.com ([212.44.43.80] helo=dhcp-105-devlan.cachelogic.com) by mail5.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1QozAg-0005rW-MJ; Thu, 04 Aug 2011 15:45:15 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: <2979E38DD6FC6544B789C8DAD7BAFC520F72CD55@xmb-sjc-235.amer.cisco.com> Date: Thu, 4 Aug 2011 15:45:11 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7EBF6898-A595-4DD4-A48E-71296357C839@niven-jenkins.co.uk> References: <1AC8E92C-3A69-4C80-A235-710DEF396A53@cisco.com> <2979E38DD6FC6544B789C8DAD7BAFC520F72CD55@xmb-sjc-235.amer.cisco.com> To: Kent Leung (kleung) X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: cdni@ietf.org, draft-bertrand-cdni-use-cases@tools.ietf.org Subject: [CDNi] Maximum resolutions & CDNs X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 14:45:01 -0000 Use Case authors, Colleagues, draft-bertrand-cdni-use-cases states in section 2.4: > " > The delivery of content may be further influenced by policies which > may include quality of service rules that specify: > o the maximum resolution deliverable to specific devices, > o the maximum resolution deliverable though a specific NSP, or > o the maximum resolution deliverable to users based on their > subscription levels. > " On 26 Jul 2011, at 21:54, Francois Le Faucheur wrote: > I don't think this is covered in the cdni-requirements doc.=20 > It is not obvious to me that absolutely all of those ought to be in > phase 1. The first bullet only makes sense if the solution supports > transcoding/transrating, which I don't know if it will be supported in > Initial scope. > The last bullet does not make sense to me as we don;t want the CDNs to > be aware of any user subscription levels (ie only CSP is aware of user > subscription level). On 28 Jul 2011, at 21:10, Kent Leung (kleung) wrote: > KL> I'm not yet convinced that this should be part of the CDNI = Metadata. > Based on the discussion conclusion, we can track this as possible > requirement for now. I can understand that the stated "maximum resolution" requirements may = be CSP requirements but I'm a little unclear as to how they translate to = capabilities on a CDN which would typically not be aware of the = resolution of the content it is delivering. It is not clear to me how delivery to specific devices can be handled by = a CDN as I'm not really sure how a CDN can identify a particular device = in the general case? Given different resolutions will map to different files (or sets of = files) in a CDN is it sufficient to, for example (other methods may also = be equally applicable): - Have delivery to specific NSPs handled by geo-blocking policies per = file (or set of files)? - Have delivery based on subscription level handled by authentication = tokens set by the CSP's "portal" (or something other than the CDN that = actually understands who has what subscription?)? Therefore meaning that specific details of the resolution of a = particular file (or set of files) still remain transparent to the CDN? Thanks Ben From johan.rydberg@edgeware.tv Thu Aug 4 07:48:27 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A59C21F8AED for ; Thu, 4 Aug 2011 07:48:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PvIzVL9jGpJm for ; Thu, 4 Aug 2011 07:48:26 -0700 (PDT) Received: from mail.edgeware.tv (mail.edgeware.tv [94.127.35.114]) by ietfa.amsl.com (Postfix) with ESMTP id 2047921F8AB0 for ; Thu, 4 Aug 2011 07:48:26 -0700 (PDT) Received: from kalm.local (m83-182-60-133.cust.tele2.se [83.182.60.133]) by mail.edgeware.tv (Postfix) with ESMTPA id B9D0719100A4; Thu, 4 Aug 2011 16:48:35 +0200 (CEST) Message-ID: <4E3AB142.4030103@edgeware.tv> Date: Thu, 04 Aug 2011 16:48:34 +0200 From: Johan Rydberg User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.16) Gecko/20101125 Thunderbird/3.0.11 MIME-Version: 1.0 To: "Woundy, Richard" References: <4E3A6BEE.4080301@edgeware.tv> <8AF4C086-7E25-4931-9BF7-7DC7F44A9D2C@niven-jenkins.co.uk> <4E3A7178.6080400@edgeware.tv> <1CA25301D2219F40B3AA37201F0EACD11360E6C4@PACDCEXMB05.cable.comcast.com> In-Reply-To: <1CA25301D2219F40B3AA37201F0EACD11360E6C4@PACDCEXMB05.cable.comcast.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "cdni@ietf.org" Subject: Re: [CDNi] upstream cdn enforce content policies X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 14:48:27 -0000 Richard, I just got a bit scared when I saw discussions about features that "may be good to have" or "it would be nice to support". I guess all I wanted to say was that everyone would benefit from a minimized scoop. On 8/4/11 4:34 PM, Woundy, Richard wrote: > A couple of observations, as an individual and not a working group chair. > > >> Instead of constructing a complex metadata exchange protocol >> > How about we construct a *simple* metadata exchange protocol? :) > > I believe we are anticipating this protocol to be XML/JSON over HTTP. > > >> I have a feeling that if the interconnect protocols are not limited in scope, this CDNI effort will either (1) fail or (2) be in some "design phase" for ever. >> > CDNI was approved as a WG in late June. Now it is early August and we're already in danger of failing? Hmmm. > > It feels to me like we are debating theoretical scenarios. Johan, if you feel strongly about eliminating this interface, maybe you could write up your proposal as an internet-draft that we can discuss and debate? We also need to ensure that your proposal meets the use cases identified by this group. > > -- Rich > > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Johan Rydberg > Sent: Thursday, August 04, 2011 6:16 AM > To: Ben Niven-Jenkins > Cc: cdni@ietf.org > Subject: Re: [CDNi] upstream cdn enforce content policies > > On 8/4/11 12:10 PM, Ben Niven-Jenkins wrote: > >> Johan, >> >> On 4 Aug 2011, at 10:52, Johan Rydberg wrote: >> >> >> >>> After following the discussions for a while, I have a question: >>> >>> Instead of constructing a complex metadata exchange protocol, >>> why not force the upstream CDN to enforce any prolicy rules that >>> the CSP has put on the content? >>> >>> >> That would not provide sufficient coverage to ensure that the policy is enforced as clients may attempt to request content directly from a downstream CDN, bypassing the upstream CDN. >> >> > There must be ways to make sure that the client first passes through the > upstream > CDN. > > I have a feeling that if the interconnect protocols are not limited in > scope, this > CDNI effort will either (1) fail or (2) be in some "design phase" for ever. > > >> >> >>> In the case of DNS-based routing, the CDN can answer the DNS >>> lookup with the address of one of its own CDNI request routers >>> that will enforce any policies before redirecting (HTTP 302) to >>> a downstream CDN. >>> >>> The upside to this is that redirects between CDNs will always be >>> HTTP 302, regardless if the initial mechanism was DNS-based. >>> Also, the complex metadata protocol can be elimited, minimizing >>> the scope of the CDNI work. >>> >>> >> Even if one could avoid the need for a downstream CDN to apply some policies, this wouldn't eliminate the need to exchange CDNI metadata as other CDNI metadata such as rate limiting, whether an encrypted channel is required, where to obtain the content from etc. is still required. >> >> > It sounds like most of those could be folded into the request routing > protocol. > Rate limiting and encryption might not be attributes of the content, but > rather > of the client. (Some customers pay more, and get a higher bitrate for > example) > > > > > > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > From vumip1@gmail.com Thu Aug 4 08:00:48 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A479621F8B4B for ; Thu, 4 Aug 2011 08:00:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=-1.010, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G3SHkRDX74ZW for ; Thu, 4 Aug 2011 08:00:47 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id BF0EF21F8B47 for ; Thu, 4 Aug 2011 08:00:46 -0700 (PDT) Received: by gwb20 with SMTP id 20so1276620gwb.31 for ; Thu, 04 Aug 2011 08:01:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2HaHCWibqbtk9mWhtzrtU6wnk0EIjr2q4UpAf9ckmX4=; b=J/XYivUZ6cOw735WGCQ2G+OMoegSPk6jHGDMUoK+hdNoGK10TgmEaLCFXhbTUPFlrj KYHZWC4Ypl74DrQt9G0Aj2rCL0aVZSxTmweT1O3QWkaAbIhOA22mgZpbS6TsYTh68Cru 7L0KXYVfV2cv3owvnMvPlge8CyqJsAegp/ctg= MIME-Version: 1.0 Received: by 10.236.165.40 with SMTP id d28mr1210914yhl.217.1312470061373; Thu, 04 Aug 2011 08:01:01 -0700 (PDT) Received: by 10.236.145.138 with HTTP; Thu, 4 Aug 2011 08:01:01 -0700 (PDT) In-Reply-To: References: Date: Thu, 4 Aug 2011 11:01:01 -0400 Message-ID: From: Bhumip Khasnabish To: Francois Le Faucheur Content-Type: multipart/related; boundary=20cf305e2621c9593404a9af3f5a Cc: cdni@ietf.org Subject: Re: [CDNi] Fwd: comments on draft-bertrand-cdni-use-cases-02 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 15:00:48 -0000 --20cf305e2621c9593404a9af3f5a Content-Type: multipart/alternative; boundary=20cf305e2621c9593104a9af3f59 --20cf305e2621c9593104a9af3f59 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hello, Please note that "well-accepted" and "opaque" elements may be different in different environment (region, provider, context, etc.). May be some *specific* examples are needed on what one means by "well-accepted" and "opaque" metadata elements in region/provider/context/... ... ... . Thanks. Best. Bhumip On Fri, Jul 29, 2011 at 10:03 AM, Francois Le Faucheur wrote: > Ken, Yiu, > > Can you add into your list of tracked candidate items something reflectin= g > this thread? ie ensuring cdni-requirements incorporates requirements on t= he > CDNI Metadata interface covering: > *A* ability to exchange a set of well-accepted metadata elements with > specified semantics (eg start of time window, end of time window,...), AN= D > *B* ability to allow exchange of opaque metadata element, whose semantic = is > not defined in CDNI but left up to private CDN agreement. > > Dave Oran also privately suggested that we expand on *B* to cover the usu= al > distribution options for treatment of opaque element (eg > ignore-and-pass-on-when-not-understood, etc). Which makes sense to me. > > Thanks > > Francois > > Begin forwarded message: > > *From: *Kevin J Ma > *Date: *28 July 2011 17:35:22 EDT > *To: *Francois Le Faucheur > *Cc: *Francois Le Faucheur , "Kent Leung (kleung)" < > kleung@cisco.com>, "draft-bertrand-cdni-use-cases@tools.ietf.org" < > draft-bertrand-cdni-use-cases@tools.ietf.org>, "cdni@ietf.org" < > cdni@ietf.org> > *Subject: **Re: [CDNi] comments on draft-bertrand-cdni-use-cases-02* > > i think there could be alot of debate about what qualifies as A. > > one solution would be to go with just B, for requirements, but > either way is ok with me. > > Sent from my iPhone > > On Jul 28, 2011, at 5:22 PM, "Francois Le Faucheur" > wrote: > > > On 28 Jul 2011, at 16:54, Kevin J Ma wrote: > > Just one quick comment: it was not necessarily the intent of the use > cases to imply**** > that CDNI requirements be generated for each piece of metadata; the > metadata may be**** > useful for certain deployments, but opaque metadata distribution may be > sufficient?**** > ** ** > There was discussion early on about metadata with implied actions like: > expiration,**** > or sunset/sunrise, or ssl only, or url hashing required, or content > transformation,**** > or do accounting, or other proprietary optimization or policy enforcement > features,**** > etc., but its not clear that we would want CDNI requirements for each of > these?**** > ** ** > It seems like a more generic notion of defining metadata (and their > actions), and**** > allowing CDNs to advertise or decline metadata (action) support would > useful, as**** > opposed to adding a requirement for each piece of metadata? > > > I have been assuming that we'd want to specify: > *A* a set of well-accepted metadata elements with their semantics (eg sta= rt > of time window, end of time window,...), AND > *B* probably, also a mechanism to allow exchange of opaque metadata > element, whose semantic is not defined in CDNI but up to private CDN > agreement. > > I believe *A* is needed to facilitate actual base interoperation across > CDNs. > I believe *B* is useful to allow CDNs to do extra thing on top of what ha= s > been specified in CDNI. > Are you saying that you feel only *B* is needed? > > Cheers > > Francois > > **** > ** ** > ** ** > *From:* Francois Le Faucheur [mailto:flefauch@cisco.com] > *Sent:* Thursday, July 28, 2011 4:17 PM > *To:* Kent Leung (kleung) > *Cc:* Francois Le Faucheur; > draft-bertrand-cdni-use-cases@tools.ietf.org; > cdni@ietf.org > *Subject:* Re: [CDNi] comments on draft-bertrand-cdni-use-cases-02**** > ** ** > Kent and all,**** > ** ** > On 28 Jul 2011, at 16:10, Kent Leung (kleung) wrote:**** > > > **** > Hi Francois. Responding to comments related to the requirements draft > below. > > > o an expiration time (i.e., the time at which the content files > should be expunged from all CDN storage). > " > I understand this is saying that CDNI metadata need to include this > expiration time (triggering cache removal) , in addition to deactivation > time. > I don't think this is discussed in cdni-requirements yet. Can you bring > that up on the list with the cdni-reqts authors? > > KL> I've seen references to content expiration time (i.e. removal) in > some drafts. So it seems to be needed in the CDNI Metadata. Noted as > requirement (possibly part of availability window) unless others object.*= * > ** > ** ** > FLF as an Individual: that works for me.**** > ** ** > > > > " > The delivery of content may be further influenced by policies which > may include quality of service rules that specify: > o the maximum resolution deliverable to specific devices, > o the maximum resolution deliverable though a specific NSP, or > o the maximum resolution deliverable to users based on their > subscription levels. > " > I don't think this is covered in the cdni-requirements doc. > It is not obvious to me that absolutely all of those ought to be in > phase 1. The first bullet only makes sense if the solution supports > transcoding/transrating, which I don't know if it will be supported in > Initial scope. > The last bullet does not make sense to me as we don;t want the CDNs to > be aware of any user subscription levels (ie only CSP is aware of user > subscription level). > > > KL> I'm not yet convinced that this should be part of the CDNI Metadata. > Based on the discussion conclusion, we can track this as possible > requirement for now.**** > > ** ** > FLF as a chair: I will raise a discussion in the "Open Items" slot > towards the end of the WG meeting on "Content Adaptation" and what shoudl= be > in scope of CDNI. This will give us some sense on the WG views on that.**= * > * > ** ** > Francois**** > ** ** > > > **** > > > Kent > > **** > ** ** > **** > > * > Francois Le Faucheur* > *Distinguished Engineer* > *Corporate Development* > flefauch@cisco.com > Phone: *+33 49 723 2619* > Mobile: *+33 6 19 98 50 90* > > **** > > *Cisco Systems France* > Greenside > 400 Ave de Roumanille > 06410 Sophia Antipolis > France > Cisco.com **** > **** > > **** > Think before you print.**** > > > This email may contain confidential and privileged material for the sole > use of the intended recipient. Any review, use, distribution or disclosur= e > by others is strictly prohibited. If you are not the intended recipient (= or > authorized to receive for the recipient), please contact the sender by re= ply > email and delete all copies of this message. > > Cisco Systems France, Soci=E9t=E9 =E0 responsabiit=E9 limit=E9e, Rue Cami= lle > Desmoulins =96 Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy les Mouline= aux, > Au capital de 91.470 =80, 349 166 561 RCS Nanterre, Directeur de la > publication: Jean-Luc Michel Givone. > > For corporate legal information go to: > > http://www.cisco.com/web/about/doing_business/legal/cri/index.html**** > ** ** > > > > > * > Francois Le Faucheur* > *Distinguished Engineer* > *Corporate Development* > flefauch@cisco.com > Phone: *+33 49 723 2619* > Mobile: *+33 6 19 98 50 90* > > > *Cisco Systems France* > Greenside > 400 Ave de Roumanille > 06410 Sophia Antipolis > France > Cisco.com > > > > Think before you print. > This email may contain confidential and privileged material for the sole > use of the intended recipient. Any review, use, distribution or disclosur= e > by others is strictly prohibited. If you are not the intended recipient (= or > authorized to receive for the recipient), please contact the sender by re= ply > email and delete all copies of this message. > > Cisco Systems France, Soci=E9t=E9 =E0 responsabiit=E9 limit=E9e, Rue Cami= lle > Desmoulins =96 Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy les Mouline= aux, > Au capital de 91.470 =80, 349 166 561 RCS Nanterre, Directeur de la > publication: Jean-Luc Michel Givone. > > For corporate legal information go to: > > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > > > * > Francois Le Faucheur* > *Distinguished Engineer* > *Corporate Development* > flefauch@cisco.com > Phone: *+33 49 723 2619* > Mobile: *+33 6 19 98 50 90* > > > *Cisco Systems France* > Greenside > 400 Ave de Roumanille > 06410 Sophia Antipolis > France > Cisco.com > > > > Think before you print. > This email may contain confidential and privileged material for the sole > use of the intended recipient. Any review, use, distribution or disclosur= e > by others is strictly prohibited. If you are not the intended recipient (= or > authorized to receive for the recipient), please contact the sender by re= ply > email and delete all copies of this message. > > Cisco Systems France, Soci=E9t=E9 =E0 responsabiit=E9 limit=E9e, Rue Cami= lle > Desmoulins =96 Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy les Mouline= aux, > Au capital de 91.470 =80, 349 166 561 RCS Nanterre, Directeur de la > publication: Jean-Luc Michel Givone. > > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > > -- --20cf305e2621c9593104a9af3f59 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hello,
=A0
Please note that "well-accepted" and "opaque" elem= ents may be different in different environment (region, provider, context, = etc.).
May be some specific examples are needed on what one means by= =A0=A0"well-accepted" and "opaque" metadata elements in= region/provider/context/... ... ... . Thanks.
=A0
Best.
=A0
Bhumip



On Fri, Jul 29, 2011 at 10:03 AM, Francois Le Fa= ucheur <flefauch= @cisco.com> wrote:
Ken, Yiu,=20

Can you add into your list of tracked candidate items something reflec= ting this thread? ie ensuring cdni-requirements incorporates requirements o= n the CDNI Metadata interface covering:
*A* ability to exchange a= set of well-accepted metadata elements with specified semantics (eg start = of time window, end of time window,...), AND
*B* ability to=A0allow ex= change of opaque metadata element, whose semantic is not defined in CDNI bu= t left up to private CDN agreement.

Dave Oran also privately suggested that we expand on *B* to cover the = usual distribution options for treatment of opaque element (eg ignore-and-p= ass-on-when-not-understood, etc). Which makes sense to me.

Thanks

Francois

Begin forwarded message:

From: Kevin J Ma <kevin.ma@azukisystems.com>
Date: 28 July 2011 17:35:22 EDT
To: Francois Le Faucheur <flefauch@cisco.com>
Subject: Re: [CDNi] comments on draft-bertran= d-cdni-use-cases-02

i think there could be alot of debate about what qualifies as A.

one solution would be to go with just B, for requirements, but
either way is ok with me.

Sent from my iPhone

On Jul 28, 2011, at 5:22 PM, "Francois Le Faucheur" <= flefauch@cisco.com<= /a>> wrote:


On 28 Jul 2011, at 16:54, Kevin J Ma wrote:

Just one quick comment: it was not necessarily the intent = of the use cases to imply
that CDNI requirements be generated for each piece of meta= data; the metadata may be
useful for certain deployments, but opaque metadata distri= bution may be sufficient?
=A0
There was discussion early on about metadata with implied = actions like: expiration,
or sunset/sunrise, or ssl only, or url hashing required, o= r content transformation,
or do accounting, or other proprietary optimization or pol= icy enforcement features,
etc., but its not clear that we would want CDNI requiremen= ts for each of these?
=A0
It seems like a more generic notion of defining metadata (= and their actions), and
allowing CDNs to advertise or decline metadata (action) su= pport would useful, as
opposed to adding a requirement for each piece of metadata= ?

I have been assuming that we'd want to specify:
*A* a set of well-accepte= d metadata elements with their semantics (eg start of time window, end of t= ime window,...), AND
*B* probably, also a mech= anism to allow exchange of opaque metadata element, whose semantic is not d= efined in CDNI but up to private CDN agreement.

I believe *A* is needed to facilitate actual base interoperation acros= s CDNs.
I believe *B* is useful to allow CDNs to do extra thing on top of what= has been specified in CDNI.
Are you saying that you feel only *B* is needed?

Cheers

Francois

=A0
=A0
=A0
Kent and all,
=A0
On 28 Jul 2011, at 16:10, Kent Leung (kleung) wrote= :


Hi Francois. =A0Responding to comments related to t= he requirements draft
below.


=A0=A0o =A0an expiration time (i= .e., the time at which the content files
=A0=A0=A0=A0=A0should be expunged from all CDN storage).
"
I und= erstand this is saying that CDNI metadata need to include this
expiratio= n time (triggering cache removal) , in addition to deactivation
time.=A0
I don't think this is discussed in cdni-requirements yet. Can you bring=
that up on the list with the cdni-reqts authors?

KL> I've= seen references to content expiration time (i.e. removal) in
some draft= s. =A0So it seems to be needed in the CDNI Metadata. =A0Noted as
requirement (possibly part of availability window) unless others object.=
=A0
FLF as an Individual: that works for me.<= /u>
=A0


"
=A0=A0The delivery of content may= be further influenced by policies which
=A0=A0may include quality of se= rvice rules that specify:
=A0=A0o =A0the maximum resolution deliverable to specific devices,
=A0= =A0o =A0the maximum resolution deliverable though a specific NSP, or
=A0= =A0o =A0the maximum resolution deliverable to users based on their
=A0= =A0=A0=A0=A0subscription levels.
"
I don't think this is covered in the cdni-requirements doc.=A0
It is not obvious to me that absolutely all of those ough= t to be in
phase 1. The first bullet only makes sense if the solution su= pports
transcoding/transrating, which I don't know if it will be supported in<= br>Initial scope.
The last bullet does not make sense to me as we don;t = want the CDNs to
be aware of any user subscription levels (ie only CSP i= s aware of user
subscription level).


KL> I'm not yet convinced that this = should be part of the CDNI Metadata.
Based on the discussion conclusion,= we can track this as possible
requirement for now.
=A0
FLF as a chair: I will raise a discussion in the &q= uot;Open Items" slot towards the end of the WG meeting on "Conten= t Adaptation" and what shoudl be in scope of CDNI. This will give us s= ome sense on the WG views on that.
=A0
Francois
=A0



Kent

=A0
<image001.jpg>


Francois Le Faucheur=
Distinguished Engineer
Corporate Developmen= t
flefauch@cisco.com
Phone:=A0+33 4= 9 723 2619
Mobile:=A0+33 6 19 98 50 90

Cisco Systems France
Greenside
400 Ave de Roumanille
06410 Sophia Antipolis
France
<= a style=3D"COLOR: blue; TEXT-DECORATION: underline" href=3D"http://www.cisc= o.com/" target=3D"_blank">Cisco.com=

=A0

<image002.gif>
=A0Think before you print.=


This email ma= y contain confidential and privileged material for the sole use of the inte= nded recipient. Any review, use, distribution or disclosure by others is st= rictly prohibited. If you are not the intended recipient (or authorized to = receive for the recipient), please contact the sender by reply email and de= lete all copies of this message.

Cisco Systems France, Soci=E9t=E9 =E0 responsabiit=E9 limit=E9e, Rue Ca= mille Desmoulins =96 Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy les Mou= lineaux, Au capital de 91.470 =80, 349 166 561 RCS Nanterre, Directeur de l= a publication: Jean-Luc Michel Givone.

For corporate legal information go to:
http:/= /www.cisco.com/web/about/doing_business/legal/cri/index.html<= /u>

=A0

<image001.jpg>


Francois Le Faucheur=
Distinguished Engineer
Corporate D= evelopment
= flefauch@cisco.com
Phone:=A0+33 49 723 2619
Mobile:=A0+33 6 19 98 50 90

Cisco Systems France
Greenside
400 Ave de Roumanille
06410 Sophia Antipolis
France
Ci= sco.com

 =A0

<green.gif>
=A0Think before you print.

This email may contain confidential and pri= vileged material for the sole use of the intended recipient. Any review, us= e, distribution or disclosure by others is strictly prohibited. If you are = not the intended recipient (or authorized to receive for the recipient), pl= ease contact the sender by reply email and delete all copies of this messag= e.

Cisco Systems France, Soci=E9t=E9 =E0 responsabiit=E9 limit=E9e, Rue Ca= mille Desmoulins =96 Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy les Mou= lineaux, Au capital de 91.470 =80, 349 166 561 RCS Nanterre, Directeur de l= a publication: Jean-Luc Michel Givone.

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/= index.html





Francois Le Faucheur=
Distinguished Engineer
Corporate D= evelopment
flefauch@cisco.com
Phone:=A0+33 49 723 = 2619
Mobile:=A0+33 6 19 98 50 90

Cisco Systems France
Greenside
400 Ave de Roumanille
06410 Sophia Antipolis
France
Cisco.com

 =A0


=A0Think before you print.

This email may contain confidential and pri= vileged material for the sole use of the intended recipient. Any review, us= e, distribution or disclosure by others is strictly prohibited. If you are = not the intended recipient (or authorized to receive for the recipient), pl= ease contact the sender by reply email and delete all copies of this messag= e.

Cisco Systems France, Soci=E9t=E9 =E0 responsabiit=E9 limit=E9e, Rue Ca= mille Desmoulins =96 Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy les Mou= lineaux, Au capital de 91.470 =80, 349 166 561 RCS Nanterre, Directeur de l= a publication: Jean-Luc Michel Givone.

For corporate legal information go to:
http://= www.cisco.com/web/about/doing_business/legal/cri/index.html

=


________________________= _______________________
CDNi mailing list
CDNi@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/cdni


=

--
--20cf305e2621c9593104a9af3f59-- --20cf305e2621c9593404a9af3f5a Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: a1d8c35bf1dc1150_0.0.1.1 /9j/4AAQSkZJRgABAQEAYABgAAD/4QBmRXhpZgAASUkqAAgAAAAEABoBBQABAAAAPgAAABsBBQAB AAAARgAAACgBAwABAAAAAgAAADEBAgAQAAAATgAAAAAAAABgAAAAAQAAAGAAAAABAAAAUGFpbnQu TkVUIHYzLjM1AP/bAEMAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAf/bAEMBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAf/AABEIAGQAmgMBIgACEQEDEQH/xAAf AAABBQEBAQEBAQAAAAAAAAAAAQIDBAUGBwgJCgv/xAC1EAACAQMDAgQDBQUEBAAAAX0BAgMABBEF EiExQQYTUWEHInEUMoGRoQgjQrHBFVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJ SlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4eLj5OXm5+jp6vHy8/T19vf4+fr/xAAfAQADAQEBAQEBAQEB AAAAAAAAAQIDBAUGBwgJCgv/xAC1EQACAQIEBAMEBwUEBAABAncAAQIDEQQFITEGEkFRB2FxEyIy gQgUQpGhscEJIzNS8BVictEKFiQ04SXxFxgZGiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNk ZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfI ycrS09TV1tfY2dri4+Tl5ufo6ery8/T19vf4+fr/2gAMAwEAAhEDEQA/AP7+KKKKACiiigAoor49 /wCCgOv634Y/Yu/aP1vw7qt9omsWnwy1mO01TTLmSzv7Rb57bT7prW6hZJraWSzuriETwuk0QkLx SJIFdenBYaWNxmEwcZqEsXiaGGjOSbjCVerCkptKzai53aTu0rI4syxscty7H5jOEqsMBgsVjZUo tRlUjhaFSvKEZNNRlNU3FNppN3asfX6SRyqWjdJFDyRlkZXUSQyNFKhKkgPFKjxyL95JEZGAZSA+ v54/+Df/AFzWLvwf+0zoF1qd7caJpHiL4YappelzXEkllYajrun+OoNZvLSBmKQT6nFomkJevGAZ xp9rvyYwa/ocr0eIcneQ5xjcpeIWKeElRSrqm6PtI1sPRxEW6bnU5Go1lGS9pJXi2m00ePwfxFHi zhzLOII4R4FZhDEN4R1liHRlhsZiMHNKsqVH2kZTw8pxl7KD5ZJOKaYUUUV4p9KFFFFABTGliR44 mkjWSXf5UbOqvL5Y3P5aEhn2KQz7QdoOTgU+v5DP+CqnjnxjYf8ABS23uLHxNrdlP4BX4NL4MmtN RureTwz52l6Hr8zaM0UimwebWNRvL+Z7fY0087tIX4A+k4X4elxNmFbARxUcG6OBr4z2sqLrKXsZ 0qcafIqlK3POtG8+Z8sVJqMnaL+M454whwVlGHzWeAnmKxGaYTLVQhiFhnH6zCvVlWdR0a1/Z08P Plp8i55yjFzhG8l/XnRRRXzZ9mFFFFABRRRQAUUUUAFVry4FnZ3V2UMgtbae4KA7S4gieUoGIIUs FwDg4znB6V/OT+zV+3z+0t4+/wCCpWtfB3xR43Oo/CXXviR8ZvANv4AOmaTDpOg6L4F0zxvd+Frn SLmCwj1GLV7Sfwxp/wDaWozXUsmsx3GoJeL+9tGsf6LNa/5A2rf9gy//APSWWvczrIcXkGJweGxs 6FSeMwWGx8HQlOUY0sRKpD2c3KEGqkJ0pqXKnFq0oyd9Pl+GOLMv4twWY43LaWKo08uzTGZTUWLh ThOdfCQo1HVpqnVqp0alOvTlDncZp80ZwVk3+C3/AASz/wCCiX7Rf7U/7RvxG+HPxg1Pw7rHha68 A698QPDVppnhzStDm8GXOkeJvC2lQ6Fpl5pltb3WraLNY+IrgTP4km1fWPtNpaTR6skf2mC4/SP/ AIKPf8mNftL/APZNr7/04adX8+H/AAQo/wCTyPFn/ZAfGv8A6m3w1r+g/wD4KPf8mNftL/8AZNr7 /wBOGnV9nxPgMFl3H+VYfAYWjhKH1jI5+xw9ONKmpvE04ykoRSipSUU5NK8pXlK8m2/zbgTNcyzn wmz7GZrjsTmGL+q8T03icXVlWrOnHB1Zxg6k25OMHOShFtqEbQgowjGK/Kf/AIN9/wDkDftVf9hP 4Nf+kvxOr9Sf+Cjn7QHj39mf9lDx18UPhjNYWfje31Pwr4f0TVNSsLbVLfR5PEOvWdhd6ommXsct jfXdtYtciyhvoZ7JbuSGe6truGF7Wb8tv+Dff/kDftVf9hP4Nf8ApL8Tq+2P+Cz/APyYj42/7Hf4 b/8AqT21PiChRxPiksPiKcK1CtmmR06tKpFSp1KcsHl6lCcXpKEldSi01JNppptE8JYvE4HwJljM HWqYbFYbIuJquHxFKThVo1YZjm7hVpTVpQqQlaUJxalCSUotNJnd/wDBLX9pj4n/ALVH7Mk3j34v Xum6t4z8PfEbxH4FuNd07SrLRTrtlpWjeGNbtNS1DTdLhtdJttR/4qOWymGlWNhZSRWcEq2kczzM /wCj1fi//wAEKP8AkzfxZ/2X7xr/AOoT8Nau/wDBZD9qn4zfs2/DT4R6b8GPFM3gjVviN4p8SR63 4m0+1sbjWodK8KadpNxHpenTaha3kVimo3mtwz3l5bRR3+zTo7WG5jtrq8in8PM8ieYcbY7I8shh 8Kq2Y4inh4NOlhqEKdKVedo04ycYQhCbjCELbQikrW+oyTipZR4Y5VxTndTGY94fJ8JWxdSLVfG4 qpVrQwtNudapBVKs6lSmp1KtRN+9UnKTu3+ydfhd/wAFbP28f2g/2VPiB8HfBfwR1zRfDFtrvhy/ 8Z+Jb+/8NaL4jutcFvrjaXa6BKmvWl9BYaT5VlcSXc2lx2WsTNdgW+qWggXf+gv/AAT3+Mvjj9oD 9jz4L/Fn4kXtvqfjfxJp3iyy1/VLazttPTVLjwn4/wDFfg231OWzsooLK3vNRsfD1reX6Wdvb2hv p7hra2t4GjhT8Lf+C+v/ACXb4G/9kl1L/wBTHVK6+C8nof66f2TmmHw2Mjg55nh69GpCNfDTr4SF ak5KNSPLUjGpBypuUFqoyspJW4PEriLErw0fEGRYzG5dLMKWR4zC4ijUlhcbTw2YVsLXjBzozcqV SVGooVVTqNWc6fPKDd/6avht4nuvG3w78A+M722gs73xd4L8LeJ7u0tTIbW1utf0Ox1W4trYzM8p gglu3ihMrvIY1UuzNkn+RX/gq9/yko8Tf90V/wDUS8K1/WJ8Av8AkhPwV/7JL8OP/UO0av5O/wDg q9/yko8Tf90V/wDUS8K16XhpGMOKc0hFWjDKsxjFLZRjjcGkvkkkeJ41znV4DyKpUk5TqZ9ks5yd rynPLswlKTtZXbbeisf2PV/Pl4W/4KQftF6z/wAFR7z9na61Dw6vwUj+MPi34Ox+DI/DulLcJb+H 31nSbXxSPExtT4kOuTajpkWpXFu+pvohgllsItLjPl3af0G1/Hr8P/8AlNbf/wDZ43xL/wDUl8V1 5fA+X4LHUuKJYzC0MS8NkGKq4d1qcansKqjNqrS5k/Z1YuK5asbThryyV3f3PFDN8zyvE8Cwy7HY nBRxvFuBoYxYarKksVh+empYevyte1w81OXtKM+alU054S5Y2/sKoor+bT/gmD+37+0z+0L+2N4g 8G/FDxz/AMJD4G8b+FvGfiK38JzaTpVtp3hG80aSzvdGj8LS2VnbX1jb2Vm0ulS29xd3cWoW8zXm ord6skWoR/O5ZkOMzXAZzmGHqUIUckw9LE4mNWU41KkavtnGNFRpzUpKGHqyfPKCuoxveV19jnvF mXZBmvDeUYyliqmJ4nxtbBYGdCFOVKjUovDRlPEynVhKMHUxeHgvZxqStKcmkoa/0l0UUV4h9QFF FFAH46/Bj/glXP8ACj9unV/2sZfivb6v4VXxd8R/HPhzwXH4fmttdTV/iLZ6/ZSaXrGqtfSWL6do aeKdSkgvbOAXOpSWOn+daWST3Sp+wlxBHdW89tKCYriGWCQKdrGOZGjcBhyCVY4PY81NRXp5nm+Y ZxVw9fMK/t6uGwtHB0ZKFOny0KDnKnG1KME5c1ScpTac5OWrskl4mR8O5Rw5h8Xhcnwv1WhjcdiM yxMHWrVufF4mNOFWadapUlCLhSpwjTg4wjGC5Yptt/kN+wN/wS6uP2L/AI1ePfivqPxVt/HVtqvh XV/Avg7SbPw/LpNxb6Fq3iHRtak1XxHcTXtxE2sRweHdOs0s9Njax33V/ObhgltGv1D/AMFHQT+w 3+0vgE/8W1vzxzwL/TyT9AASfQDNfbFYviTw5oPjDQNa8K+KdI0/X/DfiLTL3Rdd0TVbaK903VdK 1G3ktb6wvrWZWintrm3lkiljdSCrHGDgjqq5/jcbnWDzrNKjxdfDYjBVJuMKVJzpYOpCcacY04wg nJQfvcuspNs4KHCeWZXw1mPDWRUY4DC43CZnRpqdSviFTr5jRq05VZzrVKlWUYynH3VPSEFGNrH8 9P8Awb7g/wBjftUnBwdU+DYB7Ei0+J2Rn1GRn0yPWv2E/bU/ZpP7Wv7PPjH4KweJl8IanrVzoWsa Jr01i2pWNrq/h3VrbVbWHUrKOa3nl0+/WCWxuJLaZbizFyt9FFdm2+xXPe/Av9m74I/s0+H9W8Mf BD4f6Z4C0fXdVbWtZis73WdWvNT1ExmKOW91fxFqer6vcQ2sRaKwspL82OnRSSx2FtbJNKr+3115 9xD9f4oxHEOWqrhn9YweIwnt40nVpzweHw9KE6kFKrSbc6HO4c1SFnytyVzg4U4Q/srgbCcH53LD 46P1PMMJmH1WdeNCtTzHF4zEVIUaso0K6UaeK9mqnJSnzR54qLtb4p/YI/ZJuP2MfgQfhPqHjCDx vrOp+M9d8ca3rFlpsmlaZFqGs2Oi6Smn6ZbT3FzdNaWun6BYlrm6dZri8lupRDbwmKFOA/4KLfsK XP7cPgXwHo2ieObPwJ4q+HfiHU9V0q91bS7nVtF1LTtfs7Sy1nTryKyura6s7gNp+m3tjfxJeKrW k9jJaBb/AO22X6K0V50M9zOnnDz6GItmbr1MQ8R7KlZ1KsZQqfuuT2XJKnOVNwUElF2VnZnsVeFs jrcOLhSpg3LI1hKWDWE9vXUlRoThVpf7Qqnt/aQq04VVUdRyc43k2m0/nT9kv4Awfsu/s8fDX4Ew +IX8Vt4E0/WVvPED2Q05dT1TxJ4n1vxdrEtvY+fdNa2Meq6/eW+nwyXM8y2MNv58rzeYx+Lf+Cin /BNrU/23fFnwy8ZeHvidp/gHUvBmkX/hbWbXWdAutbs7/Q73UhqsF9prWV/Yyw6pYTy3sb2dzutd Riubci801rJ/tv6u0UYTPc0wOazzrDYnkzKrVxNapXdKjNTqYvneIlKlODpfvHUm7KCUW04KNlYz DhbI8zyClwzjMG6mS0KGCw1HCxr4inKnRy/2SwkY4inVjiL0lRpx5nVcpxTVRy5pX5rwX4ZtfBXg 7wn4Nsbie7svCXhrQvDNpdXIQXNza6DpdrpVvcXAiCxieaK0SSURqqCRmCALgV/IP/wVfVh/wUn8 SkggMPgsykggMv8AwinhdcqT1G5WXI43KR1Br+x2vnH4jfsi/s3fFv4m+F/jH8RvhL4c8VfEjwct gmheJL+XVomVNKunvNLXVtKstStdD8SDTbmR5bD/AISTTNW+xnatt5aIir6/CHEVDh7NsTmOMo18 THEYDFYZxoez9p7atUo1ozl7SUI8jnR5ZtO8VPmjGbjyP57xD4OxXF/D+CyfLcRhcFPCZtgMapYr 23svq+FpYjDzpxdKnVm6ip4jmppxUZypqE6lNS9pH6Or8edB/wCCVsmift93f7X4+K1vN4Rm+IGv /FWLwMPD86eIR4r8QJfTz6TJrJv3046FBrOpXOpJepZi9eyjh0Y2SSM2sL+w1FeHl2b5hlSxscDX 9iswwlTBYpezp1PaYer8cV7SEuSVrpVIcs4pu0lc+ozjh7KM+lls81wv1mWUZhRzPAP2tal7HGUH enN+yqQ9rC9nKlV56U3GPNB2QV+Nv7Ev/BKS4/ZG/aN1/wCNFx8WbTxb4etdE8SaB4H8O2nh2403 VEtPEVxCq3HiW/udRu7fzdL0yD7KsOnRyjUbyf7c9xYRW32K7/ZKings3zDLsLmODwlf2WHzWjCh joezpz9tTpupypSnCUqbSq1Y81NxfLUkr3s0s04dyjOcdk2ZZjhfb4zIMTUxeV1fbVqaw9er7Fzk 4UqkIVU5YehNRqxnFTpRaVnJSKKKK8w9sKKKKACuS8eeO/CHww8G+I/iB4916w8MeDvCWl3Gs+IN d1J2S10+wtgNzlY0knubiaRo7aysbSGe+1C9mt7Gxt7i8uIIJOtr8G/+C9PxE1zQvgl8Gvhvp1xc W2kfELx7rmteIfIMiR31v4C0rT207TLx1+R7V9S8UQaqttJkSXmj2dyoLWYK+bnGYf2XlmMx/Iqj w9LmhBtqMqk5xpUlJrXldScea2vLezTPtvDjhB8ecccOcJfWJYWnnGOdPE4mCjKrRwWFw9bHY6dF TTg66weFr+wU04e25OdON0/BvjR/wXr8VL4g1Cw/Z9+DnhdfDdpPJBp/iP4sz61qOpazEkmFvn8M eFdY8Px6LHMgJitH8SapOFKSzSwuXtU+3v8Agmv/AMFIfiD+2p4y8d+BvH3w88G+Fbzwb4QtvFMe teELzW0tr9p9Zs9JaxfR9audVltwBdG4FwusTH5BEYOTIPnv/gj1+xN8BfFH7P8AH8f/AIneAPCX xQ8Y+NfE3iPTtEg8baNpnijRPCWgeF9U/seOGw8PatHf6VHr19q+nXupT61dWX9pw2T6dbaa1lbm 7m1P9qfBfwF+Cvw38U6l41+Hfwq8BeAvE+s6Qug6xq3gvwvpPhaXVtLS7gvkttSg0O1sbO/eO5to Hjurq3lvI1jWFJ1hzGfmciocTYuWCzbGZtTeFxKVeeAjSik8PUhJ0knGmowk7wmkm5ctuao5XR+2 +KuaeCHD1Hibw94a8P8AGRz/ACWcsrw/F1XHVp1IZxgsTRjjp1IVsZKriKN6eKw05TjGj7Xmlh8H Gj7OS/PH/gqN+3j8Xv2JP+FGf8Kq8OfDfxB/ws3/AIWb/b3/AAsHSPE+q/ZP+EM/4V9/Zf8AZH/C OeMPCf2f7R/wleo/b/tn2/zfJsvs/wBl8uf7T9afsMfHnxf+03+yz8Lvjf4803w3pHizxt/wm39q 6f4Rs9UsPD1v/wAI38RfF3hGx/s+01nWNf1KLzdN0Cznu/tOrXfmX0tzLD5Fu8VtD+Of/BwV/wA2 kf8Ade//AHi9fpB/wSO/5R6/s+/91X/9Xd8Sq3wWPxlTjPN8vniKksHQy+lVo4dtezp1HTyxucVa 9261V7/bkeZxNwnw5hPo0eHvF2GyjCUeJc04wxuAzDOIRmsZi8HTxfHEIYerJzcHTjDLcDFJQTth qeujv8yftzf8Fg9O/Zy+JesfBn4OeA9I+IfjPwlPFaeNfEvifUb228J6Jq7RLNceG9P07SGg1HWt SsUlij1W7OqaZa6ZfCbTlhv7mG5Nr5N+xJ/wWB+Nn7Qv7Qfw8+CXxI+GHwttrT4galqmnx+IfBA8 W6DcaN/Z/h7VtcWZ9O17xD4vj1PzW0v7MY1u9O2ifzQ7GLy5Pze/bs+Evxi/ZC/bi8T/AByvvCUG u+GvEPxp1L4zfDjxJ4l0eXxD4C8Sy6t4jl8ZHwvrJJgie70W7uptG1TRZrmx1QWtpHqOnyi0uLDU n/Y39jj/AIK9fCn9pLxp4P8Ahb8X/AMHww+KWs38em+Ddat54tf8C634iu2SCz0vTr28gh1rwjrW sO6Wel2d2mpWN7cItmfEKX13YWFx4eFzfMMRn1ahmGdyymdHMI06GWzwSdDE4dVUlR+sNxUJVqaU YVKim5uanSlrGK/VM78O+D8m8JsszbhLwvw/iHQzPhGrjM140w3E1WnmuSZvUwDlLMFlFOlWqYmj l2LlKriMFg5YeOFWFnhsdRvGtWl+zep6np2i6bqGsavfWml6TpNjd6nqmp6hcRWlhp2nWEEl1e31 7dzvHBa2lpbRS3FzcTOkUMMbySOqKSP56/2if+C7WnaB4m1Lw3+zX8MtK8ZaTpdzNar8RPiJd6tZ 6VrkkTGNp9E8H6S+l6sulMymS0v9V16wvruJlMuiWBAMn2N/wWZ+I2veAP2JtfsNBuZ7J/iT478J /DnVrq2kaKZdB1CDWvEmq2wdeRBqlv4W/si9jyFnsdQurd8pMyn84P8Agi/+xj8FvjN4b+Ivx1+L /hPQviPL4a8ZL4A8JeD/ABTZ22r+GNOuLXQdK17Wde1bw9dtNYa7PeQ+INPsNLh1mxuNOsvseo3E UFzfPDPpvsZ5mWa184wvD+T1qeEq1KDxGJxc4qThC05ckOaM+VKELtxhzznOEVKEVNv858K+CeAM r8Oc88XfEjLsXxBgMFmscmyXh7C1qlKGIxN8NTeIxDpV8N7SVTEYl04wr144bD4fDYmvOhi6tXDU 4fVX/BPX/gqr8Wf2svjjY/Bj4j/Db4d6Mb/wx4j19fEvgmXxLpohk0G3iuBbNo2u6v4l85LoS7DI NWiaEruCy52j9jPix8VfAvwR+Hnin4p/ErXIfD3gvwfpx1HWdTljlnkCvNFaWdlZWkCvcX2panf3 Frp2m2Nujz3l9dW9vGu6QEc/4d/Z2+Avg7xdpvj3wb8G/hp4O8ZaRYX2l2PiTwh4L0Dwvqsem6lC ILywnutBsdPa9s5YxhLa9+0QwNmS3SKRi5/DL/gvp8S/EVnYfAD4R2N7c2nhnW28Y+OvEVpFKyQa xqWjPoujeGluURl8yPSI9Q1+ZYpVeN59QgmAEtrGw662JzHh7IMZicwxUczxdCf7iq4OCl7aVKjQ hUSUW1TqylOfvOUoJpTu0l83l+S8H+MXi1w5knB2Q1uCMgzShH+1sCsQsTOl/ZtLH5hmmIwVSc60 I1MXgaFLD4VOlGlSxTU54aVOM5VPN/ip/wAF7/iVca5eRfBL4KeBdI8NwzvHp998UrnxB4k1vUbd XXy7u70zwnrvhSx0eaaMNu0+HVtbS3dlxqVwEO/6I/ZS/wCC3nhv4leNNG+H/wC0V4E0j4ZTeIr6 10vSPiH4W1O+uvB1vqd7MYLW38TaTrBn1Lw9p0szQQf29HrGr2dtLN52qQaXpsNxqMPrP/BMj9gn 9nXRv2Zvh58VvHPw48FfFT4hfFrw9D4t1LWPHfh/R/GFjoOl6pJO2keHvDela3b6jpej/Y9LaNNY vre2XWNQ1G41CC9vP7PistNsfzZ/4LNfse/CP9n/AMSfDD4pfB7QNM8DaZ8T5/E2jeJvA2iRx2Ph 201vw7DpF5Z654b0eNhBpFvqNnqc1pqumaZDa6NZz2Gn3FpaQ3GpXjS/N1qvF+X5fS4grZlRxFJq hXr5fKnBRjh68oKEbRpRin+8gpqk4zhdtVJ8rv8AtmXZf9HXi/i/G+EGW8E5nlOPp1M0yrK+LqWM xLxFbNspo4ieKq3q42tVlB/U8TPDSx9KvhsS4KE8Jhva01H+r6ivhL/gmd8S/EXxZ/Yg+A/izxZe 3OpeIYND13wlf6leStcXWoQ+BfF3iDwdpN5dXMjNNd3k+iaJpr311cE3FzfG5mmeV3M0n3bX6Ng8 THGYTC4uCcYYrD0cRCMvijGtTjUUX5pSs/NH8Y8RZLiOHM/zzh7FVIVcTkWb5lk+Iq001Tq1stxl bB1KtNO7VOpOi5wTd+WSvqFFFFdB44UUUUAFfmP/AMFWP2TvEf7Uv7OSf8K+sH1X4mfCnXH8b+Ft FhGbvxNpj2E9h4p8LWALBTqV/Yta6rpUQV5r/VNCstIh2NqRkT9OKwPEviG08M6VPql2rSCPCQwI QJJ5nOEjTPc9Seygk8AkceYYShj8FicHib+wr0nCo07Sjs4zi3dKUJqM43TXNFXTWj+j4R4hzXhT ibJeIsk5XmmU4+lisLTqRc6Vd606uFrRjKEnQxVCdXDV1GcJ+xqz5KkJWmv43f2LP+Ckfxf/AGEr XxP8LdX+H8PjzwPJr97qN74B8TajqXgzxL4R8VgW9hq66bq0ulaxJpCXQskj1jQtS8O3ipqMC3dt /Z91JqY1H93f2BP+ClGu/twfFbx74Qk+E2k/DLw54O8BW3iWFU8W3njLW77VJ9fsNKKy6mdC8LWM Onrb3Mri2TRZLkzCNjfbFaOTpfjP8FfhF+0d4iOvfEL4B/D3xZraLFGusf2BqEHiue0tlMVtb6p4 k8O6hpOtanbWyMyW9teXMlpbhsQwocGvb/2UfgR8I/gzc+JF+H/wY8HfDTVb2xtLW81bRdH1KDXN T02OfzRY3+ra7f6rqtxaLcrHcfZxdpbtPGkskTyxxunx+TZdnmAxeGwsc4hXyfD1JctGVDlrVKXL Jxp80qM5U4qUk1BYlwSVkkrJf0Z4mcZ+FfFuQZ3ns/DrE5V4j5thcM62Z0c19tl2Fxbr4WNfFujS zHD0MVVqUY1KbxE8kWInKfPUqOd6j/I//g4K/wCbSP8Auvf/ALxev0g/4JHf8o9f2ff+6r/+ru+J Ve6/tG+FvA3ivUPC0Pj34QfB/wCKtpptnqkuiH4o/DzRfHU+g3F/PZpq40Z9aWZNMi1OOw0j7ctp FE92+n2xuZJhb2yw+zfCrRPDHhv4c+GtI8FeEPC3gPw/a2NzLY+FPBeg6d4a8L6TdXt9d3+qf2Vo Wkw21hYRX2sXN9qU6Qxh5ru8uLi4kmuZpp5PWwmVSpcT5lm/t4ShicHDDqhySU4OMMBHnc37jT+r N2Wvvx7M+Az/AI+oY/wL4K8O1lleliMk4jxWbzzZ4mjPDYiFavxTWVCGGivb06kVnkIuU24t4ao1 pOB+QXxM/wCCzf7OWheLfir8Hfix8BfH+vQeDPGnjTwHqFpaW3gXxl4a8SyeEfEOo6JDdXdh4l1T QEhtNSn01Lt7aay1BrASBVN88IaT8L/Bfh6D9rD9u7RG/Zm+FEnw28MeJvif4Z8TaL4M0qSOWw+H fhTQb3RJvEXie/ntYo7DRtMtWs73xJcWNkhstMub+Hw3oKXrjS4Lr+j7x7+xJ8FfiV4q13xd4q/Z b+HGq6/q2ralqes6vp+m+J/DTaxqd/dPcahqt7B4e8XaPBd3uo3LSXlzdzQyXFxczT3MkjzTzSSf Qn7PHhj4S/BNp/B3gn4NeCvha2qXIivr7whoq6fd6hcBsxQ69eXj3ut34iOBbyXuq3UcAISGGGPF eHismzbN8Xh45vj8J9SoYn2tKVHCOnipxUvdo+1dGmoKUW4tqpKClabhUlGNv1LIfErw+8O+H83x Hh7wpxA+J80yP+z8dRzDiGGK4fw9epSp+2zBYCOZYqeJlTrwVSmpYSliXS58LTxGGpV63NN+3z+z ZeftV/sw+PvhZoRtk8aL/Z/izwDJeSxW9q3i/wAM3BvLKwnuZiIbSPXrB9S8ONezOkNiNY+2TN5U Dg/ywfso/tkfHv8A4JwfETx14P1bwDNeadqd3b23xB+EfjpdT8M39rrWlxTJp2saVe/ZrifQtV8i 4Ecl6dM1TTtb0d4A9rceVpOoWX9q+r6raaLp9zqV6xW3tYy77Rl3P8KIO7ueAK+Avjn4M+Fv7R1z awfEj4F+APHqabG1to9/4i0a8uvFdjZtL50tvZeJNFvtJ1zT7O4lAmmsLK+jtmkG6UTMAw9PiHJp 4nF4bNMvxrwOa4eHs6cuRzp1aacrKaUZ8rXtJxbcKkakZezlBpJr4jwf8S8NkvD2d8CcYcLw4r4B zjFfXcVh1iI4bGYDGOOH554SVSrRjWjOWFwtaFOnicDWwmJp/W6OLhOcoVPm39jP/grFrf7Yf7Q/ h/4PWvwR0r4a6HdeF/Fev6rqlx48u/G+q3E2h2cc9nb6eY/Cng6zsInllH2lrm21N5I1KxeQzB16 L/gsL+yH4k/aL+Cnh/4i/DrTbzXPiJ8D59b1OPw1pts11qPinwV4hTTB4nsdMtYVNxe61o8uj6br mmWcW+W6s7fW7GytrrU76xgf2r9nT9nv4PfBjx5Y6n8NfgB8P/h/rd5Bc6dP4nt9I8RXniG2026A a9trDWPEuu6veWSXYjSOdLaaJZoVMMgaLKV+gGtazY6Dp8+p6hIUt4FyQgDSyufuxRISN8j4wq5A 7kgAkdOFwGKzDJcXgc9xccXUxE5qdelBUo0opUp0eSKpUI81GpBVf4ajKWkuZN38TOuL8i4R8TeH +KvCnh+vw/gcooYV4fKcfi6uPq4+rUnjaGZQxVWWPzOsqWZYPFSwUksZOpSp+/RdOUYOP8g37GP/ AAVu+J/7J3w7g+EfiT4eaf8AGHwLoU92/hC3vPFV34N8SeF4r65nvLzR01v+wfFVtf6Gl9PNdWNh caLFd6fJcXNvFqLWH2OzsvF/2g/2jP2hP+Cnnx38B+HdM8HRi7SSfw58Mvhl4Va9v7DQIdXuLafX Nb1fVrpFae4mjs7S68TeJrq30vS7HSNHtpXtNPtLGV3/AKNPi38Af2bvjh4lvPEnib9l/wCG2ta7 eXD3V9rg03VdK8Q6xOd6/btd1DwVqHhq51S6kjYCR9Tm1CQbY1NxIIISvo/wQ8P/AAu/Z9eTTfh3 8Dfh78PLW/EVrrV94S0F9O8S31okokjTVNc1Ge/1vWYrZ8ywWup6jLHG+5ojEzFj8x/YGb16VHK8 bnyqZNSnBRhToTVadOlKLp025Uk0kkuRTxFanRai4wkoRR+6f8Rd8Osqx2P474b8J6mE8S8ww+Jq VMRi81w08tw+NxtKUMTiqapY+dN1KrnUeJq4TKMtxeYRqVqdXE0Xiasz6E/Zj+B+mfs3fAT4Y/BL Sr0anD4C8OrY32qLF5Eeq6/qd9ea94n1WCDAa3ttS8Sarqt9bW8heWC3uIoppZpUeV/d6r2l1BfW 0F3bOJILiJJYnHdHAIz6EZwQeQQQelWK/SaNKnQo0qNGKjSo04UqUVqo06cVCEU+yikl5I/ijMsf jM0zHH5nmNWWIzDMcbisfjq80lOtjMXXqYjFVZqKSUqlepOckkknJpJLQKKKK0OIKKKKACvLfibY y39vpcQBMKzTyOv8PmBEWMkdztaTHpz68epVn6jYRX8HlSDlWDocZ2sARnHcEEg+xz2qKkOeEo97 fg0/xsdWDxH1XE0q/wDz7k35q8XG681e5yfw+0mz07RFaKFBczTym5kKgvuRsRrnkhRHtYDgZZiB zk93tUEsFAYjBOBkj0J64rm7TTLqxLfZZDGHxuUBWRsdCUYFc9ecA4PWta1S7WR2uZS6lMKuFVQd wJOFAGcdzzjjpSprlhGPK1ZW0tb1363u9N76DxU/bVqtd1VN1JOVm25atWjta0bpLW1lsrWPMfif pf8AaE2jvt3eXFer0zjL2xrtfBkH2XwzpVuRjyo51x6f6XcEfoavatpo1BoCRnyhIOf9sp/8TV6w tvstnFb9PLDj/vqR29/71TGnatOpb4o2v6KHl5dzWri/aZdh8Jf+DVlO19rurrbz5/8Ah9TiPEXi y+t55bLSYV3xEpLdSqXAfAysUZwMochmcMCchV4DHh9H8Hapq+txaxqCuq/akuri5mURvKYyMLEh AJztCghdiqMAkgKfVH0TbeNdRqpfzjOpYAjeW3nIPX5iensQRWzEb3egkESxj72xGBx+LsB+A/Lq JdJzmpVG2oyvGKS5Vqrf8HyT13N6ePWFoOnhIU4TqUuWrWbvVd0nJeeuqV+VNfDozjviNay3mhxQ Jko95F5qjugV2XPsHVfxNZ/w30SysbO8uDDGb17gIzsql0hCKUC55VWYvnGMle+K9EvbSO9t3gkG VYAjjOGBBVh7gj8Rkd6w7bSLiykL2sjRsRglcbWH+0jAq3qNynB6U3T/AHyqW5tLenTTTz7rdmVP F/8ACfPBc/s71HNvZSu4u0mt07Wfay3V0dKUQsGKKWX7rFQWH0JGR+Bryz4mWc1+mmQDcYFM8jKM 7WkGwDcOh2jBHHGT616HAl8JlaeUtGAcqFRQSeATtAPv6UupafFqEIRx80bbkb0OMEe4I7eoB6ir qR9pTlG1ua29tbNPz3tbUwwlb6piqNa6lyNu8bvl5ouN9baq938+pzngbR7DTNEtmt4YxcThnuZs AyNJuIKluoCfdC5AAHTNcz8SdCsrwafcpDGt4XlSRkUBpIgqkGTHXaxIDEZOcZOOO3tNNu7IMLaQ xq3JTCsmfUKwKgnuQATgZNRT6NNeSiS6dpGOAWbnao7Ko4A5JwABk+9RKHNSVPk2UV0srW1Xn8ur vszppYqVPHvG+3u3Kc73blJTTXI+nKrrS70irJNe7X8CwS23hy0gl3fu5LhU3ZyIxM4QDPYAYHtX YVBbQR20McEY2pGoUD6D9T6nueanrWK5Yxj/ACxS+5WOCvV9tWq1bW9pUlO3bmbf66hRRRVGQUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAf/2Q== --20cf305e2621c9593404a9af3f5a Content-Type: image/gif; name="green.gif" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: a1d8c35bf1dc1150_0.0.1.2 R0lGODlhEgATAJEAAAAAAP///wCZAP///yH5BAEAAAMALAAAAAASABMAAAIojI+pGyK8nINqUiTf bVnfvHEg1UmhdZRqaawu6XZVjKb0/CYxo8JOAQA7 --20cf305e2621c9593404a9af3f5a-- From richard_woundy@cable.comcast.com Thu Aug 4 08:02:32 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 926DE21F8B3D for ; Thu, 4 Aug 2011 08:02:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.856 X-Spam-Level: X-Spam-Status: No, score=-102.856 tagged_above=-999 required=5 tests=[AWL=-1.121, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hne8UaoRPVyU for ; Thu, 4 Aug 2011 08:02:32 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id DC6E121F8B1D for ; Thu, 4 Aug 2011 08:02:31 -0700 (PDT) Received: from ([24.40.55.42]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.47500996; Thu, 04 Aug 2011 09:07:39 -0600 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%11]) with mapi id 14.01.0289.001; Thu, 4 Aug 2011 11:02:41 -0400 From: "Woundy, Richard" To: Johan Rydberg Thread-Topic: [CDNi] upstream cdn enforce content policies Thread-Index: AQHMUoxOe9o5Dl8G80aFZBDqzy+b85UMu4oAgAABiwCAAAIFEIAASgYA///Ae1A= Date: Thu, 4 Aug 2011 15:02:39 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD11360E8F6@PACDCEXMB05.cable.comcast.com> References: <4E3A6BEE.4080301@edgeware.tv> <8AF4C086-7E25-4931-9BF7-7DC7F44A9D2C@niven-jenkins.co.uk> <4E3A7178.6080400@edgeware.tv> <1CA25301D2219F40B3AA37201F0EACD11360E6C4@PACDCEXMB05.cable.comcast.com> <4E3AB142.4030103@edgeware.tv> In-Reply-To: <4E3AB142.4030103@edgeware.tv> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.191.223.245] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] upstream cdn enforce content policies X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 15:02:32 -0000 OK, fair enough. There are several participants that want CDNI to be "as si= mple as possible, but no simpler" -- including me. :) -----Original Message----- From: Johan Rydberg [mailto:johan.rydberg@edgeware.tv]=20 Sent: Thursday, August 04, 2011 10:49 AM To: Woundy, Richard Cc: Ben Niven-Jenkins; cdni@ietf.org Subject: Re: [CDNi] upstream cdn enforce content policies Richard, I just got a bit scared when I saw discussions about features that "may=20 be good to have" or "it would be nice to support". I guess all I wanted to say was that everyone would benefit from a=20 minimized scoop. On 8/4/11 4:34 PM, Woundy, Richard wrote: > A couple of observations, as an individual and not a working group chair. > > =20 >> Instead of constructing a complex metadata exchange protocol >> =20 > How about we construct a *simple* metadata exchange protocol? :) > > I believe we are anticipating this protocol to be XML/JSON over HTTP. > =20 > =20 >> I have a feeling that if the interconnect protocols are not limited in s= cope, this CDNI effort will either (1) fail or (2) be in some "design phase= " for ever. >> =20 > CDNI was approved as a WG in late June. Now it is early August and we're = already in danger of failing? Hmmm. > > It feels to me like we are debating theoretical scenarios. Johan, if you = feel strongly about eliminating this interface, maybe you could write up yo= ur proposal as an internet-draft that we can discuss and debate? We also ne= ed to ensure that your proposal meets the use cases identified by this grou= p. > > -- Rich > > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of J= ohan Rydberg > Sent: Thursday, August 04, 2011 6:16 AM > To: Ben Niven-Jenkins > Cc: cdni@ietf.org > Subject: Re: [CDNi] upstream cdn enforce content policies > > On 8/4/11 12:10 PM, Ben Niven-Jenkins wrote: > =20 >> Johan, >> >> On 4 Aug 2011, at 10:52, Johan Rydberg wrote: >> >> >> =20 >>> After following the discussions for a while, I have a question: >>> >>> Instead of constructing a complex metadata exchange protocol, >>> why not force the upstream CDN to enforce any prolicy rules that >>> the CSP has put on the content? >>> >>> =20 >> That would not provide sufficient coverage to ensure that the policy is = enforced as clients may attempt to request content directly from a downstre= am CDN, bypassing the upstream CDN. >> >> =20 > There must be ways to make sure that the client first passes through the > upstream > CDN. > > I have a feeling that if the interconnect protocols are not limited in > scope, this > CDNI effort will either (1) fail or (2) be in some "design phase" for eve= r. > > =20 >> >> =20 >>> In the case of DNS-based routing, the CDN can answer the DNS >>> lookup with the address of one of its own CDNI request routers >>> that will enforce any policies before redirecting (HTTP 302) to >>> a downstream CDN. >>> >>> The upside to this is that redirects between CDNs will always be >>> HTTP 302, regardless if the initial mechanism was DNS-based. >>> Also, the complex metadata protocol can be elimited, minimizing >>> the scope of the CDNI work. >>> >>> =20 >> Even if one could avoid the need for a downstream CDN to apply some poli= cies, this wouldn't eliminate the need to exchange CDNI metadata as other C= DNI metadata such as rate limiting, whether an encrypted channel is require= d, where to obtain the content from etc. is still required. >> >> =20 > It sounds like most of those could be folded into the request routing > protocol. > Rate limiting and encryption might not be attributes of the content, but > rather > of the client. (Some customers pay more, and get a higher bitrate for > example) > > > > > > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > =20 From richard_woundy@cable.comcast.com Thu Aug 4 08:26:34 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 041A121F8B1D for ; Thu, 4 Aug 2011 08:26:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=-0.841, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9bMOopCC+AdG for ; Thu, 4 Aug 2011 08:26:33 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id 5021B21F8ABE for ; Thu, 4 Aug 2011 08:26:33 -0700 (PDT) Received: from ([24.40.55.40]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.47502923; Thu, 04 Aug 2011 09:15:28 -0600 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%11]) with mapi id 14.01.0289.001; Thu, 4 Aug 2011 11:10:42 -0400 From: "Woundy, Richard" To: Ben Niven-Jenkins , "cdni@ietf.org" Thread-Topic: [CDNi] Updating the CDNI Problem Statement as agreed last week Thread-Index: AQHMUqce72/+Q9v5Pk6fbB+dH5bJR5UMyh2A Date: Thu, 4 Aug 2011 15:10:39 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD11360E94A@PACDCEXMB05.cable.comcast.com> References: <7D5A9C99-E984-4D64-A03B-AD646A39A405@niven-jenkins.co.uk> In-Reply-To: <7D5A9C99-E984-4D64-A03B-AD646A39A405@niven-jenkins.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.191.223.245] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CDNi] Updating the CDNI Problem Statement as agreed last week X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 15:26:34 -0000 > In the absence of any further discussion on the mailing list related to t= hese suggested changes, I will go ahead and update the Problem Statement dr= aft with these changes in the next few weeks. No objection, but please allow the following actions to occur prior to post= ing the updated draft. 1. The chairs will post the draft CDNI meeting minutes. That way we have a = record of what we agreed in our WG session in Quebec. 2. The chairs will re-confirm the acceptance of the Problem Statement, Use = Cases, and Requirements draft by the WG. This will affect the naming of you= r draft, eg draft-ietf-cdni-problem-statement. -- Rich -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Ben= Niven-Jenkins Sent: Thursday, August 04, 2011 9:05 AM To: cdni@ietf.org Subject: [CDNi] Updating the CDNI Problem Statement as agreed last week Colleagues, I have summarised below the changes to the Problem Statement draft that wer= e agreed during the face to face CDNI meeting last week as well as those wh= ich have been suggested on the mailing list or to me privately. Feel free to remind me of anything I have forgotten or misremembered. In the absence of any further discussion on the mailing list related to the= se suggested changes, I will go ahead and update the Problem Statement draf= t with these changes in the next few weeks. 1) Add an Appendix to the document titled "Additional Material" (if anyone = can think of a better title feel free ti suggest it) including the followin= g statement "Note to RFC Editor: this section is to be removed on publicati= on as an RFC." and move the following sections into that appendix: (a) Section 3.2. "Non-Goals for IETF" (except for the final paragraph of = that section which will be moved to the end of Section 3.1). (b) Section 5. "Prioritizing the CDNI Work". (c) Section 6.1. "Related standardization activities". (d) Section 6.2. "Related Research Projects". 2) Update Figure 1 "CDNI Problem Area" to reflect the consensus of the grou= p as judged by the chairs with respect to including: (a) A "Request" interface (labelled out of scope for CDNI) between the Do= wnstream Surrogate and the Upstream Request Router. (b) An "internal" interface (labelled out of scope for CDNI) between the = Control function and the Surrogate function in each of the CDNs. 3) Align the terminology in the Problem Statement with that used in the WG = charter, i.e. to use "interface" instead of "protocol" when referring to CD= NI interfaces. 4) Incorporate the 24 minor corrections/comments provided by Kent Leung Ben _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni From lpeterson@verivue.com Thu Aug 4 08:30:24 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC32921F899F for ; Thu, 4 Aug 2011 08:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dA6IuGr1A32a for ; Thu, 4 Aug 2011 08:30:24 -0700 (PDT) Received: from exprod8og118.obsmtp.com (exprod8og118.obsmtp.com [64.18.3.36]) by ietfa.amsl.com (Postfix) with ESMTP id 827FC21F87FA for ; Thu, 4 Aug 2011 08:30:23 -0700 (PDT) Received: from vvexch.verivue.com ([63.64.170.198]) (using TLSv1) by exprod8ob118.postini.com ([64.18.7.12]) with SMTP ID DSNKTjq7Gpc/HQ5klrnk3nR/k240rgSiCDKR@postini.com; Thu, 04 Aug 2011 08:30:38 PDT Received: from vvexch.verivue.com ([10.10.6.20]) by vvexch.verivue.com ([10.10.6.20]) with mapi; Thu, 4 Aug 2011 11:30:33 -0400 From: "Peterson, Larry" To: Johan Rydberg Date: Thu, 4 Aug 2011 11:30:32 -0400 Thread-Topic: [CDNi] upstream cdn enforce content policies Thread-Index: AcxSu3L5yMQFJC6mRW2wxsTEYzrAJw== Message-ID: <70AE7D15-69E5-40FE-A4EE-F6BF5E01C6A9@verivue.com> References: <4E3A6BEE.4080301@edgeware.tv> <8AF4C086-7E25-4931-9BF7-7DC7F44A9D2C@niven-jenkins.co.uk> <4E3A7178.6080400@edgeware.tv> <1CA25301D2219F40B3AA37201F0EACD11360E6C4@PACDCEXMB05.cable.comcast.com> <4E3AB142.4030103@edgeware.tv> In-Reply-To: <4E3AB142.4030103@edgeware.tv> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] upstream cdn enforce content policies X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 15:30:24 -0000 Picking up on Johan's minimized scope thread... I too have been puzzled by the metadata interface. If you read the language= =20 carefully, you'll see there's a caveat that this interface might exist in v= arious=20 forms, presumably as a combination of other interfaces and mechanisms, for example: o the uCDN doesn't route the request to the dCDN unless policy permits; o the uCDN sets HTTP caching directives consistent with policy and the dCDN obeys those directives; and o the uCDN invokes purge on dCDN should the policy change. But that generous interpretation aside, the high level issue seems to be ho= w access control policy is enforced. In a single CDN it's natural for this po= licy to=20 be enforced by the CDN, and there's likely a metadata-like interface by whi= ch the CSP expresses this policy to that CDN. The question is: does interconnection imply that uCDN further delegates tha= t responsibility for enforcing access control policy to the dCDN, or does the= uCDN retain that locus of control for itself. The later design, which essentiall= y treats=20 the dCDN as it would any other cache (at least with respect to metadata), s= eems=20 the simplest to me. Larry On Aug 4, 2011, at 10:48 AM, Johan Rydberg wrote: > Richard, >=20 > I just got a bit scared when I saw discussions about features that "may=20 > be good to have" > or "it would be nice to support". >=20 > I guess all I wanted to say was that everyone would benefit from a=20 > minimized scoop. >=20 > On 8/4/11 4:34 PM, Woundy, Richard wrote: >> A couple of observations, as an individual and not a working group chair= . >>=20 >>=20 >>> Instead of constructing a complex metadata exchange protocol >>>=20 >> How about we construct a *simple* metadata exchange protocol? :) >>=20 >> I believe we are anticipating this protocol to be XML/JSON over HTTP. >>=20 >>=20 >>> I have a feeling that if the interconnect protocols are not limited in = scope, this CDNI effort will either (1) fail or (2) be in some "design phas= e" for ever. >>>=20 >> CDNI was approved as a WG in late June. Now it is early August and we're= already in danger of failing? Hmmm. >>=20 >> It feels to me like we are debating theoretical scenarios. Johan, if you= feel strongly about eliminating this interface, maybe you could write up y= our proposal as an internet-draft that we can discuss and debate? We also n= eed to ensure that your proposal meets the use cases identified by this gro= up. >>=20 >> -- Rich >>=20 >> -----Original Message----- >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of = Johan Rydberg >> Sent: Thursday, August 04, 2011 6:16 AM >> To: Ben Niven-Jenkins >> Cc: cdni@ietf.org >> Subject: Re: [CDNi] upstream cdn enforce content policies >>=20 >> On 8/4/11 12:10 PM, Ben Niven-Jenkins wrote: >>=20 >>> Johan, >>>=20 >>> On 4 Aug 2011, at 10:52, Johan Rydberg wrote: >>>=20 >>>=20 >>>=20 >>>> After following the discussions for a while, I have a question: >>>>=20 >>>> Instead of constructing a complex metadata exchange protocol, >>>> why not force the upstream CDN to enforce any prolicy rules that >>>> the CSP has put on the content? >>>>=20 >>>>=20 >>> That would not provide sufficient coverage to ensure that the policy is= enforced as clients may attempt to request content directly from a downstr= eam CDN, bypassing the upstream CDN. >>>=20 >>>=20 >> There must be ways to make sure that the client first passes through the >> upstream >> CDN. >>=20 >> I have a feeling that if the interconnect protocols are not limited in >> scope, this >> CDNI effort will either (1) fail or (2) be in some "design phase" for ev= er. >>=20 >>=20 >>>=20 >>>=20 >>>> In the case of DNS-based routing, the CDN can answer the DNS >>>> lookup with the address of one of its own CDNI request routers >>>> that will enforce any policies before redirecting (HTTP 302) to >>>> a downstream CDN. >>>>=20 >>>> The upside to this is that redirects between CDNs will always be >>>> HTTP 302, regardless if the initial mechanism was DNS-based. >>>> Also, the complex metadata protocol can be elimited, minimizing >>>> the scope of the CDNI work. >>>>=20 >>>>=20 >>> Even if one could avoid the need for a downstream CDN to apply some pol= icies, this wouldn't eliminate the need to exchange CDNI metadata as other = CDNI metadata such as rate limiting, whether an encrypted channel is requir= ed, where to obtain the content from etc. is still required. >>>=20 >>>=20 >> It sounds like most of those could be folded into the request routing >> protocol. >> Rate limiting and encryption might not be attributes of the content, but >> rather >> of the client. (Some customers pay more, and get a higher bitrate for >> example) >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni >>=20 >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From vumip1@gmail.com Thu Aug 4 08:59:05 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F29F321F8B6E for ; Thu, 4 Aug 2011 08:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.093 X-Spam-Level: X-Spam-Status: No, score=-3.093 tagged_above=-999 required=5 tests=[AWL=0.505, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zfvOycG7apYZ for ; Thu, 4 Aug 2011 08:59:05 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id A59E021F8B6C for ; Thu, 4 Aug 2011 08:59:04 -0700 (PDT) Received: by gwb20 with SMTP id 20so1322773gwb.31 for ; Thu, 04 Aug 2011 08:59:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XGkwpAHWHBiAm3EgIWQUj3fnFqTeBBL8OBTW4MPhx1Q=; b=RlYpq5rcechJObbMJKd5DJkNfHZAGRSbMJI+3MBW/51NONfVdEBjFao4zoDk9vvLwx kQbeiwL5lAf8UMiej6YJrVH982ZUUPqU4ZaGCydhJOjMkQsgcmellHYoW1ptsum+teYU jH2i57IRD8uaN3Bz3+XA9Yghu+eCCT+k8xPEk= MIME-Version: 1.0 Received: by 10.236.197.39 with SMTP id s27mr1532940yhn.150.1312473557213; Thu, 04 Aug 2011 08:59:17 -0700 (PDT) Received: by 10.236.145.138 with HTTP; Thu, 4 Aug 2011 08:59:16 -0700 (PDT) In-Reply-To: <70AE7D15-69E5-40FE-A4EE-F6BF5E01C6A9@verivue.com> References: <4E3A6BEE.4080301@edgeware.tv> <8AF4C086-7E25-4931-9BF7-7DC7F44A9D2C@niven-jenkins.co.uk> <4E3A7178.6080400@edgeware.tv> <1CA25301D2219F40B3AA37201F0EACD11360E6C4@PACDCEXMB05.cable.comcast.com> <4E3AB142.4030103@edgeware.tv> <70AE7D15-69E5-40FE-A4EE-F6BF5E01C6A9@verivue.com> Date: Thu, 4 Aug 2011 11:59:16 -0400 Message-ID: From: Bhumip Khasnabish To: "Peterson, Larry" Content-Type: multipart/alternative; boundary=20cf3040e99427a10004a9b0109d Cc: "cdni@ietf.org" Subject: Re: [CDNi] upstream cdn enforce content policies X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 15:59:06 -0000 --20cf3040e99427a10004a9b0109d Content-Type: text/plain; charset=ISO-8859-1 once handed over to dCDN, uCDN should probably be not tracking any further.. unless the dCDN allows it. If it does, things will definitely get more complicated because different uCDN may have different requirements.. which may be out of scope.. On Thu, Aug 4, 2011 at 11:30 AM, Peterson, Larry wrote: > Picking up on Johan's minimized scope thread... > > I too have been puzzled by the metadata interface. If you read the language > carefully, you'll see there's a caveat that this interface might exist in > various > forms, presumably as a combination of other interfaces and mechanisms, > for example: > o the uCDN doesn't route the request to the dCDN unless policy permits; > o the uCDN sets HTTP caching directives consistent with policy and the > dCDN obeys those directives; and > o the uCDN invokes purge on dCDN should the policy change. > > But that generous interpretation aside, the high level issue seems to be > how > access control policy is enforced. In a single CDN it's natural for this > policy to > be enforced by the CDN, and there's likely a metadata-like interface by > which > the CSP expresses this policy to that CDN. > > The question is: does interconnection imply that uCDN further delegates > that > responsibility for enforcing access control policy to the dCDN, or does the > uCDN > retain that locus of control for itself. The later design, which > essentially treats > the dCDN as it would any other cache (at least with respect to metadata), > seems > the simplest to me. > > Larry > > On Aug 4, 2011, at 10:48 AM, Johan Rydberg wrote: > > > Richard, > > > > I just got a bit scared when I saw discussions about features that "may > > be good to have" > > or "it would be nice to support". > > > > I guess all I wanted to say was that everyone would benefit from a > > minimized scoop. > > > > On 8/4/11 4:34 PM, Woundy, Richard wrote: > >> A couple of observations, as an individual and not a working group > chair. > >> > >> > >>> Instead of constructing a complex metadata exchange protocol > >>> > >> How about we construct a *simple* metadata exchange protocol? :) > >> > >> I believe we are anticipating this protocol to be XML/JSON over HTTP. > >> > >> > >>> I have a feeling that if the interconnect protocols are not limited in > scope, this CDNI effort will either (1) fail or (2) be in some "design > phase" for ever. > >>> > >> CDNI was approved as a WG in late June. Now it is early August and we're > already in danger of failing? Hmmm. > >> > >> It feels to me like we are debating theoretical scenarios. Johan, if you > feel strongly about eliminating this interface, maybe you could write up > your proposal as an internet-draft that we can discuss and debate? We also > need to ensure that your proposal meets the use cases identified by this > group. > >> > >> -- Rich > >> > >> -----Original Message----- > >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of > Johan Rydberg > >> Sent: Thursday, August 04, 2011 6:16 AM > >> To: Ben Niven-Jenkins > >> Cc: cdni@ietf.org > >> Subject: Re: [CDNi] upstream cdn enforce content policies > >> > >> On 8/4/11 12:10 PM, Ben Niven-Jenkins wrote: > >> > >>> Johan, > >>> > >>> On 4 Aug 2011, at 10:52, Johan Rydberg wrote: > >>> > >>> > >>> > >>>> After following the discussions for a while, I have a question: > >>>> > >>>> Instead of constructing a complex metadata exchange protocol, > >>>> why not force the upstream CDN to enforce any prolicy rules that > >>>> the CSP has put on the content? > >>>> > >>>> > >>> That would not provide sufficient coverage to ensure that the policy is > enforced as clients may attempt to request content directly from a > downstream CDN, bypassing the upstream CDN. > >>> > >>> > >> There must be ways to make sure that the client first passes through the > >> upstream > >> CDN. > >> > >> I have a feeling that if the interconnect protocols are not limited in > >> scope, this > >> CDNI effort will either (1) fail or (2) be in some "design phase" for > ever. > >> > >> > >>> > >>> > >>>> In the case of DNS-based routing, the CDN can answer the DNS > >>>> lookup with the address of one of its own CDNI request routers > >>>> that will enforce any policies before redirecting (HTTP 302) to > >>>> a downstream CDN. > >>>> > >>>> The upside to this is that redirects between CDNs will always be > >>>> HTTP 302, regardless if the initial mechanism was DNS-based. > >>>> Also, the complex metadata protocol can be elimited, minimizing > >>>> the scope of the CDNI work. > >>>> > >>>> > >>> Even if one could avoid the need for a downstream CDN to apply some > policies, this wouldn't eliminate the need to exchange CDNI metadata as > other CDNI metadata such as rate limiting, whether an encrypted channel is > required, where to obtain the content from etc. is still required. > >>> > >>> > >> It sounds like most of those could be folded into the request routing > >> protocol. > >> Rate limiting and encryption might not be attributes of the content, but > >> rather > >> of the client. (Some customers pay more, and get a higher bitrate for > >> example) > >> > >> > >> > >> > >> > >> _______________________________________________ > >> CDNi mailing list > >> CDNi@ietf.org > >> https://www.ietf.org/mailman/listinfo/cdni > >> > > > > _______________________________________________ > > CDNi mailing list > > CDNi@ietf.org > > https://www.ietf.org/mailman/listinfo/cdni > > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > --20cf3040e99427a10004a9b0109d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable once handed over to dCDN, uCDN should probably be not=A0 tracking any furth= er.. unless the dCDN allows it. If it does, things will definitely get more= complicated because different uCDN may have different requirements.. which= may be out of scope..

On Thu, Aug 4, 2011 at 11:30 AM, Peterson, Larry= <lpeterson@v= erivue.com> wrote:
Picking up on Johan's minimi= zed scope thread...

I too have been puzzled by the metadata interfac= e. If you read the language
carefully, you'll see there's a caveat that this interface might ex= ist in various
forms, presumably as a combination of other interfaces an= d mechanisms,
for example:
=A0 o the uCDN doesn't route the reque= st to the dCDN unless policy permits;
=A0 o the uCDN sets HTTP caching directives consistent with policy and the<= br>=A0 =A0 =A0dCDN obeys those directives; and
=A0 o the uCDN invokes pu= rge on dCDN should the policy change.

But that generous interpretati= on aside, the high level issue seems to be how
access control policy is enforced. In a single CDN it's natural for thi= s policy to
be enforced by the CDN, and there's likely a metadata-li= ke interface by which
the CSP expresses this policy to that CDN.

The question is: does interconnection imply that uCDN further delegates= that
responsibility for enforcing access control policy to the dCDN, or= does the uCDN
retain that locus of control for itself. The later design= , which essentially treats
the dCDN as it would any other cache (at least with respect to metadata), s= eems
the simplest to me.

Larry

On Aug 4, 2011, at 10:48 AM, Johan Rydberg wrote:
=
> Richard,
>
> I just got a bit scared when I saw discus= sions about features that "may
> be good to have"
> o= r "it would be nice to support".
>
> I guess all I wanted to say was that everyone would benefit fr= om a
> minimized scoop.
>
> On 8/4/11 4:34 PM, Woundy, Ri= chard wrote:
>> A couple of observations, as an individual and not= a working group chair.
>>
>>
>>> Instead of constructing a complex meta= data exchange protocol
>>>
>> How about we construct a= *simple* metadata exchange protocol? :)
>>
>> I believe = we are anticipating this protocol to be XML/JSON over HTTP.
>>
>>
>>> I have a feeling that if the interconn= ect protocols are not limited in scope, this CDNI effort will either (1) fa= il or (2) be in some "design phase" for ever.
>>>
>> CDNI was approved as a WG in late June. Now it is early August and= we're already in danger of failing? Hmmm.
>>
>> It f= eels to me like we are debating theoretical scenarios. Johan, if you feel s= trongly about eliminating this interface, maybe you could write up your pro= posal as an internet-draft that we can discuss and debate? We also need to = ensure that your proposal meets the use cases identified by this group.
>>
>> -- Rich
>>
>> -----Original Message-= ----
>> From: cdni-bounce= s@ietf.org [mailto:cdni-bounce= s@ietf.org] On Behalf Of Johan Rydberg
>> Sent: Thursday, August 04, 2011 6:16 AM
>> To: Ben Niven-= Jenkins
>> Cc: cdni@ietf.org<= br>>> Subject: Re: [CDNi] upstream cdn enforce content policies
>>
>> On 8/4/11 12:10 PM, Ben Niven-Jenkins wrote:
>&g= t;
>>> Johan,
>>>
>>> On 4 Aug 2011, at= 10:52, Johan Rydberg wrote:
>>>
>>>
>>>= ;
>>>> After following the discussions for a while, I have a ques= tion:
>>>>
>>>> Instead of constructing a com= plex metadata exchange protocol,
>>>> why not force the upst= ream CDN to enforce any prolicy rules that
>>>> the CSP has put on the content?
>>>>
>= ;>>>
>>> That would not provide sufficient coverage to= ensure that the policy is enforced as clients may attempt to request conte= nt directly from a downstream CDN, bypassing the upstream CDN.
>>>
>>>
>> There must be ways to make sure th= at the client first passes through the
>> upstream
>> CDN= .
>>
>> I have a feeling that if the interconnect protoco= ls are not limited in
>> scope, this
>> CDNI effort will either (1) fail or (2) be= in some "design phase" for ever.
>>
>>
>= >>
>>>
>>>> In the case of DNS-based routi= ng, the CDN can answer the DNS
>>>> lookup with the address of one of its own CDNI request rou= ters
>>>> that will enforce any policies before redirecting = (HTTP 302) to
>>>> a downstream CDN.
>>>>
>>>> The upside to this is that redirects between CDNs will alw= ays be
>>>> HTTP 302, regardless if the initial mechanism wa= s DNS-based.
>>>> Also, the complex metadata protocol can be= elimited, minimizing
>>>> the scope of the CDNI work.
>>>>
>>= ;>>
>>> Even if one could avoid the need for a downstream= CDN to apply some policies, this wouldn't eliminate the need to exchan= ge CDNI metadata as other CDNI metadata such as rate limiting, whether an e= ncrypted channel is required, where to obtain the content from etc. is stil= l required.
>>>
>>>
>> It sounds like most of those could= be folded into the request routing
>> protocol.
>> Rate = limiting and encryption might not be attributes of the content, but
>> rather
>> of the client. =A0(Some customers pay more, and= get a higher bitrate for
>> example)
>>
>>
&= gt;>
>>
>>
>> _______________________________= ________________
>> CDNi mailing list
>> CDN= i@ietf.org
>> https://www.ietf.org/mailman/listinfo/cdni
= >>
>
> _______________________________________________
> CDNi m= ailing list
> CDNi@ietf.org
&= gt; https://www.ietf.org/mailman/listinfo/cdni

_______________________________________________
CDNi mailing listCDNi@ietf.org
https://www.ietf.org/m= ailman/listinfo/cdni



=A0 --20cf3040e99427a10004a9b0109d-- From kleung@cisco.com Thu Aug 4 11:52:04 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C340821F8A4E for ; Thu, 4 Aug 2011 11:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.952 X-Spam-Level: X-Spam-Status: No, score=-0.952 tagged_above=-999 required=5 tests=[AWL=-1.374, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E9W8iMVYGvl2 for ; Thu, 4 Aug 2011 11:52:03 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 6F3D821F8834 for ; Thu, 4 Aug 2011 11:52:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=kleung@cisco.com; l=71818; q=dns/txt; s=iport; t=1312483938; x=1313693538; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=i4jia06ixj0cIoddQVHbXs0YphBXvu+wj8Qoyk7DrAk=; b=S5QPiYG/orUb6Ey1CwMlKtZb/gSZM/+jsE2MCQYKnoFRyg0VsZscYvwr brNAsmIUNVhk+W5ZS7bicBUm/R3OAmUmG/tncG2xMi6EId+x2GxWJfmRH ttKcfEkRCZEEOtUWhw4GeweWX+8SuRZXycwWwYphS2fvsk/QNUyzxzKOX s=; X-Files: image001.jpg, image002.gif : 11041, 87 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvoAABnqOk6rRDoJ/2dsb2JhbABDgk2BNEaTRoc3hy53d4FAAQEBAQMBAQECBwYBCQcCCAECNAoLDgICAQYCBwcDAwEBAQYBAQMDAwIOAQYBAgICAQEFEAQCBAMCAR8JCAEBBAERAQgTB4dOolQBjSuRQQKFMDFfBIJQhQqDQYJkUQiHKoIJhFuHGQ X-IronPort-AV: E=Sophos;i="4.67,318,1309737600"; d="gif'147?jpg'147,145?scan'147,145,208,217,147,145";a="9754553" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-9.cisco.com with ESMTP; 04 Aug 2011 18:52:16 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p74IqGfn012578; Thu, 4 Aug 2011 18:52:16 GMT Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 4 Aug 2011 11:52:16 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01CC52D7.A0FCB077" Date: Thu, 4 Aug 2011 11:51:35 -0700 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC520F8762E0@xmb-sjc-235.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CDNi] Fwd: comments on draft-bertrand-cdni-use-cases-02 Thread-Index: AcxSt1eQJJpYEneMRBmD8vKiGzsV5QAHiMaQ References: From: "Kent Leung (kleung)" To: "Bhumip Khasnabish" , "Francois Le Faucheur (flefauch)" X-OriginalArrivalTime: 04 Aug 2011 18:52:16.0372 (UTC) FILETIME=[A140B340:01CC52D7] Cc: cdni@ietf.org Subject: Re: [CDNi] Fwd: comments on draft-bertrand-cdni-use-cases-02 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 18:52:05 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC52D7.A0FCB077 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CC52D7.A0FCB077" ------_=_NextPart_002_01CC52D7.A0FCB077 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 TXkgaW50ZXJwcmV0YXRpb24gb2Yg4oCcd2VsbC1hY2NlcHRlZOKAnSBpcyB0aGF0IHRoZXNlIG1l dGFkYXRhIGVsZW1lbnRzIGFyZSBjb21tb24gZm9yIENETkkgcmVnYXJkbGVzcyBvZiByZWdpb24s IHByb3ZpZGVyLCBlbnZpcm9ubWVudCwgZXRjLiAgVGhlIHNwZWNpZmljIGVsZW1lbnRzIGFyZSBk ZXRlcm1pbmVkIGluIHRoZSBzb2x1dGlvbnMgZHJhZnQuICBJIGV4cGVjdCB0aGVzZSBhcmUgdGhl IGluZm9ybWF0aW9uIG5lZWRlZCBmb3IgYmFzaWMgQ0ROSSBvcGVyYXRpb24gKGkuZS4gbmVjZXNz YXJ5IGZvciBpbnRlcm9wZXJhYmlsaXR5KS4gIFNvIHRoZXNlIGluZm9ybWF0aW9uIGVsZW1lbnRz IGFyZSBkZWZpbmVkIGluIHRoZSBzdGFuZGFyZGl6ZWQgdHlwZXMuICBOb3RlLCBhIHNwZWNpZmlj ICBlbnZpcm9ubWVudCBtYXkgb25seSB1c2UgYSBzdWJzZXQgb2YgdGhlIHN0YW5kYXJkaXplZCBl bGVtZW50cy4NCg0KIA0KDQpGb3Ig4oCcb3BhcXVl4oCdLCBJIGV4cGVjdCB0aGF0IHRoZXJlIHdp bGwgYmUgYSBzdGFuZGFyZHMgdHlwZSB0aGF0IHNwZWNpZmllcyB0aGUgaW5mb3JtYXRpb24gaXMg b3BhcXVlIChpLmUuIG5vdCBkZWZpbmVkIGJ5IHN0YW5kYXJkcykgYW5kIGNhbiBiZSB1c2VkIGJ5 IHByaXZhdGUgQ0ROIGFncmVlbWVudC4gIFNvLCBpbiB0aGlzIGNhc2UsIGl0IG1heSBiZSBDRE4g cHJvdmlkZXItc3BlY2lmaWMgaW5mb3JtYXRpb24gZWxlbWVudHMuICAgSW4gbWFueSBwcm90b2Nv bHMsIHRoaXMgaXMgZGVmaW5lZCBhcyBWZW5kb3IgU3BlY2lmaWMgT3B0aW9uL0F0dHJpYnV0ZS4N Cg0KIA0KDQpLZW50DQoNCiANCg0KRnJvbTogQmh1bWlwIEtoYXNuYWJpc2ggW21haWx0bzp2dW1p cDFAZ21haWwuY29tXSANClNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgMDQsIDIwMTEgODowMSBBTQ0K VG86IEZyYW5jb2lzIExlIEZhdWNoZXVyIChmbGVmYXVjaCkNCkNjOiBLZW50IExldW5nIChrbGV1 bmcpOyBZaXUgTGVlOyBjZG5pQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0NETmldIEZ3ZDogY29t bWVudHMgb24gZHJhZnQtYmVydHJhbmQtY2RuaS11c2UtY2FzZXMtMDINCg0KIA0KDQpIZWxsbywN Cg0KIA0KDQpQbGVhc2Ugbm90ZSB0aGF0ICJ3ZWxsLWFjY2VwdGVkIiBhbmQgIm9wYXF1ZSIgZWxl bWVudHMgbWF5IGJlIGRpZmZlcmVudCBpbiBkaWZmZXJlbnQgZW52aXJvbm1lbnQgKHJlZ2lvbiwg cHJvdmlkZXIsIGNvbnRleHQsIGV0Yy4pLiANCg0KTWF5IGJlIHNvbWUgc3BlY2lmaWMgZXhhbXBs ZXMgYXJlIG5lZWRlZCBvbiB3aGF0IG9uZSBtZWFucyBieSAgIndlbGwtYWNjZXB0ZWQiIGFuZCAi b3BhcXVlIiBtZXRhZGF0YSBlbGVtZW50cyBpbiByZWdpb24vcHJvdmlkZXIvY29udGV4dC8uLi4g Li4uIC4uLiAuIFRoYW5rcy4NCg0KIA0KDQpCZXN0Lg0KDQogDQoNCkJodW1pcA0KDQoNCg0KDQoN Ck9uIEZyaSwgSnVsIDI5LCAyMDExIGF0IDEwOjAzIEFNLCBGcmFuY29pcyBMZSBGYXVjaGV1ciA8 ZmxlZmF1Y2hAY2lzY28uY29tPiB3cm90ZToNCg0KS2VuLCBZaXUsIA0KDQogDQoNCkNhbiB5b3Ug YWRkIGludG8geW91ciBsaXN0IG9mIHRyYWNrZWQgY2FuZGlkYXRlIGl0ZW1zIHNvbWV0aGluZyBy ZWZsZWN0aW5nIHRoaXMgdGhyZWFkPyBpZSBlbnN1cmluZyBjZG5pLXJlcXVpcmVtZW50cyBpbmNv cnBvcmF0ZXMgcmVxdWlyZW1lbnRzIG9uIHRoZSBDRE5JIE1ldGFkYXRhIGludGVyZmFjZSBjb3Zl cmluZzoNCg0KKkEqIGFiaWxpdHkgdG8gZXhjaGFuZ2UgYSBzZXQgb2Ygd2VsbC1hY2NlcHRlZCBt ZXRhZGF0YSBlbGVtZW50cyB3aXRoIHNwZWNpZmllZCBzZW1hbnRpY3MgKGVnIHN0YXJ0IG9mIHRp bWUgd2luZG93LCBlbmQgb2YgdGltZSB3aW5kb3csLi4uKSwgQU5EDQoNCipCKiBhYmlsaXR5IHRv IGFsbG93IGV4Y2hhbmdlIG9mIG9wYXF1ZSBtZXRhZGF0YSBlbGVtZW50LCB3aG9zZSBzZW1hbnRp YyBpcyBub3QgZGVmaW5lZCBpbiBDRE5JIGJ1dCBsZWZ0IHVwIHRvIHByaXZhdGUgQ0ROIGFncmVl bWVudC4NCg0KIA0KDQpEYXZlIE9yYW4gYWxzbyBwcml2YXRlbHkgc3VnZ2VzdGVkIHRoYXQgd2Ug ZXhwYW5kIG9uICpCKiB0byBjb3ZlciB0aGUgdXN1YWwgZGlzdHJpYnV0aW9uIG9wdGlvbnMgZm9y IHRyZWF0bWVudCBvZiBvcGFxdWUgZWxlbWVudCAoZWcgaWdub3JlLWFuZC1wYXNzLW9uLXdoZW4t bm90LXVuZGVyc3Rvb2QsIGV0YykuIFdoaWNoIG1ha2VzIHNlbnNlIHRvIG1lLg0KDQogDQoNClRo YW5rcw0KDQogDQoNCkZyYW5jb2lzDQoNCiANCg0KQmVnaW4gZm9yd2FyZGVkIG1lc3NhZ2U6DQoN Cg0KDQoNCg0KRnJvbTogS2V2aW4gSiBNYSA8a2V2aW4ubWFAYXp1a2lzeXN0ZW1zLmNvbT4NCg0K RGF0ZTogMjggSnVseSAyMDExIDE3OjM1OjIyIEVEVA0KDQpUbzogRnJhbmNvaXMgTGUgRmF1Y2hl dXIgPGZsZWZhdWNoQGNpc2NvLmNvbT4NCg0KQ2M6IEZyYW5jb2lzIExlIEZhdWNoZXVyIDxmbGVm YXVjaEBjaXNjby5jb20+LCAiS2VudCBMZXVuZyAoa2xldW5nKSIgPGtsZXVuZ0BjaXNjby5jb20+ LCAiZHJhZnQtYmVydHJhbmQtY2RuaS11c2UtY2FzZXNAdG9vbHMuaWV0Zi5vcmciIDxkcmFmdC1i ZXJ0cmFuZC1jZG5pLXVzZS1jYXNlc0B0b29scy5pZXRmLm9yZz4sICJjZG5pQGlldGYub3JnIiA8 Y2RuaUBpZXRmLm9yZz4NCg0KU3ViamVjdDogUmU6IFtDRE5pXSBjb21tZW50cyBvbiBkcmFmdC1i ZXJ0cmFuZC1jZG5pLXVzZS1jYXNlcy0wMg0KDQogDQoNCmkgdGhpbmsgdGhlcmUgY291bGQgYmUg YWxvdCBvZiBkZWJhdGUgYWJvdXQgd2hhdCBxdWFsaWZpZXMgYXMgQS4NCg0KIA0KDQpvbmUgc29s dXRpb24gd291bGQgYmUgdG8gZ28gd2l0aCBqdXN0IEIsIGZvciByZXF1aXJlbWVudHMsIGJ1dA0K DQplaXRoZXIgd2F5IGlzIG9rIHdpdGggbWUuDQoNCg0KU2VudCBmcm9tIG15IGlQaG9uZQ0KDQoN Ck9uIEp1bCAyOCwgMjAxMSwgYXQgNToyMiBQTSwgIkZyYW5jb2lzIExlIEZhdWNoZXVyIiA8Zmxl ZmF1Y2hAY2lzY28uY29tPiB3cm90ZToNCg0KCSANCg0KCU9uIDI4IEp1bCAyMDExLCBhdCAxNjo1 NCwgS2V2aW4gSiBNYSB3cm90ZToNCg0KCQ0KCQ0KCQ0KDQoJSnVzdCBvbmUgcXVpY2sgY29tbWVu dDogaXQgd2FzIG5vdCBuZWNlc3NhcmlseSB0aGUgaW50ZW50IG9mIHRoZSB1c2UgY2FzZXMgdG8g aW1wbHkNCg0KCXRoYXQgQ0ROSSByZXF1aXJlbWVudHMgYmUgZ2VuZXJhdGVkIGZvciBlYWNoIHBp ZWNlIG9mIG1ldGFkYXRhOyB0aGUgbWV0YWRhdGEgbWF5IGJlDQoNCgl1c2VmdWwgZm9yIGNlcnRh aW4gZGVwbG95bWVudHMsIGJ1dCBvcGFxdWUgbWV0YWRhdGEgZGlzdHJpYnV0aW9uIG1heSBiZSBz dWZmaWNpZW50Pw0KDQoJIA0KDQoJVGhlcmUgd2FzIGRpc2N1c3Npb24gZWFybHkgb24gYWJvdXQg bWV0YWRhdGEgd2l0aCBpbXBsaWVkIGFjdGlvbnMgbGlrZTogZXhwaXJhdGlvbiwNCg0KCW9yIHN1 bnNldC9zdW5yaXNlLCBvciBzc2wgb25seSwgb3IgdXJsIGhhc2hpbmcgcmVxdWlyZWQsIG9yIGNv bnRlbnQgdHJhbnNmb3JtYXRpb24sDQoNCglvciBkbyBhY2NvdW50aW5nLCBvciBvdGhlciBwcm9w cmlldGFyeSBvcHRpbWl6YXRpb24gb3IgcG9saWN5IGVuZm9yY2VtZW50IGZlYXR1cmVzLA0KDQoJ ZXRjLiwgYnV0IGl0cyBub3QgY2xlYXIgdGhhdCB3ZSB3b3VsZCB3YW50IENETkkgcmVxdWlyZW1l bnRzIGZvciBlYWNoIG9mIHRoZXNlPw0KDQoJIA0KDQoJSXQgc2VlbXMgbGlrZSBhIG1vcmUgZ2Vu ZXJpYyBub3Rpb24gb2YgZGVmaW5pbmcgbWV0YWRhdGEgKGFuZCB0aGVpciBhY3Rpb25zKSwgYW5k DQoNCglhbGxvd2luZyBDRE5zIHRvIGFkdmVydGlzZSBvciBkZWNsaW5lIG1ldGFkYXRhIChhY3Rp b24pIHN1cHBvcnQgd291bGQgdXNlZnVsLCBhcw0KDQoJb3Bwb3NlZCB0byBhZGRpbmcgYSByZXF1 aXJlbWVudCBmb3IgZWFjaCBwaWVjZSBvZiBtZXRhZGF0YT8NCg0KCSANCg0KCUkgaGF2ZSBiZWVu IGFzc3VtaW5nIHRoYXQgd2UnZCB3YW50IHRvIHNwZWNpZnk6DQoNCgkqQSogYSBzZXQgb2Ygd2Vs bC1hY2NlcHRlZCBtZXRhZGF0YSBlbGVtZW50cyB3aXRoIHRoZWlyIHNlbWFudGljcyAoZWcgc3Rh cnQgb2YgdGltZSB3aW5kb3csIGVuZCBvZiB0aW1lIHdpbmRvdywuLi4pLCBBTkQNCg0KCSpCKiBw cm9iYWJseSwgYWxzbyBhIG1lY2hhbmlzbSB0byBhbGxvdyBleGNoYW5nZSBvZiBvcGFxdWUgbWV0 YWRhdGEgZWxlbWVudCwgd2hvc2Ugc2VtYW50aWMgaXMgbm90IGRlZmluZWQgaW4gQ0ROSSBidXQg dXAgdG8gcHJpdmF0ZSBDRE4gYWdyZWVtZW50Lg0KDQoJIA0KDQoJSSBiZWxpZXZlICpBKiBpcyBu ZWVkZWQgdG8gZmFjaWxpdGF0ZSBhY3R1YWwgYmFzZSBpbnRlcm9wZXJhdGlvbiBhY3Jvc3MgQ0RO cy4NCg0KCUkgYmVsaWV2ZSAqQiogaXMgdXNlZnVsIHRvIGFsbG93IENETnMgdG8gZG8gZXh0cmEg dGhpbmcgb24gdG9wIG9mIHdoYXQgaGFzIGJlZW4gc3BlY2lmaWVkIGluIENETkkuDQoNCglBcmUg eW91IHNheWluZyB0aGF0IHlvdSBmZWVsIG9ubHkgKkIqIGlzIG5lZWRlZD8NCg0KCSANCg0KCUNo ZWVycw0KDQoJIA0KDQoJRnJhbmNvaXMNCg0KCQ0KCQ0KCQ0KDQoJIA0KDQoJIA0KDQoJRnJvbTog RnJhbmNvaXMgTGUgRmF1Y2hldXIgW21haWx0bzpmbGVmYXVjaEBjaXNjby5jb21dIA0KCVNlbnQ6 IFRodXJzZGF5LCBKdWx5IDI4LCAyMDExIDQ6MTcgUE0NCglUbzogS2VudCBMZXVuZyAoa2xldW5n KQ0KCUNjOiBGcmFuY29pcyBMZSBGYXVjaGV1cjsgZHJhZnQtYmVydHJhbmQtY2RuaS11c2UtY2Fz ZXNAdG9vbHMuaWV0Zi5vcmc7IGNkbmlAaWV0Zi5vcmcNCglTdWJqZWN0OiBSZTogW0NETmldIGNv bW1lbnRzIG9uIGRyYWZ0LWJlcnRyYW5kLWNkbmktdXNlLWNhc2VzLTAyDQoNCgkgDQoNCglLZW50 IGFuZCBhbGwsDQoNCgkgDQoNCglPbiAyOCBKdWwgMjAxMSwgYXQgMTY6MTAsIEtlbnQgTGV1bmcg KGtsZXVuZykgd3JvdGU6DQoNCgkgDQoNCglIaSBGcmFuY29pcy4gIFJlc3BvbmRpbmcgdG8gY29t bWVudHMgcmVsYXRlZCB0byB0aGUgcmVxdWlyZW1lbnRzIGRyYWZ0DQoJYmVsb3cuDQoJDQoJDQoJ ICBvICBhbiBleHBpcmF0aW9uIHRpbWUgKGkuZS4sIHRoZSB0aW1lIGF0IHdoaWNoIHRoZSBjb250 ZW50IGZpbGVzDQoJICAgICBzaG91bGQgYmUgZXhwdW5nZWQgZnJvbSBhbGwgQ0ROIHN0b3JhZ2Up Lg0KCSINCglJIHVuZGVyc3RhbmQgdGhpcyBpcyBzYXlpbmcgdGhhdCBDRE5JIG1ldGFkYXRhIG5l ZWQgdG8gaW5jbHVkZSB0aGlzDQoJZXhwaXJhdGlvbiB0aW1lICh0cmlnZ2VyaW5nIGNhY2hlIHJl bW92YWwpICwgaW4gYWRkaXRpb24gdG8gZGVhY3RpdmF0aW9uDQoJdGltZS4gDQoJSSBkb24ndCB0 aGluayB0aGlzIGlzIGRpc2N1c3NlZCBpbiBjZG5pLXJlcXVpcmVtZW50cyB5ZXQuIENhbiB5b3Ug YnJpbmcNCgl0aGF0IHVwIG9uIHRoZSBsaXN0IHdpdGggdGhlIGNkbmktcmVxdHMgYXV0aG9ycz8N CgkNCglLTD4gSSd2ZSBzZWVuIHJlZmVyZW5jZXMgdG8gY29udGVudCBleHBpcmF0aW9uIHRpbWUg KGkuZS4gcmVtb3ZhbCkgaW4NCglzb21lIGRyYWZ0cy4gIFNvIGl0IHNlZW1zIHRvIGJlIG5lZWRl ZCBpbiB0aGUgQ0ROSSBNZXRhZGF0YS4gIE5vdGVkIGFzDQoJcmVxdWlyZW1lbnQgKHBvc3NpYmx5 IHBhcnQgb2YgYXZhaWxhYmlsaXR5IHdpbmRvdykgdW5sZXNzIG90aGVycyBvYmplY3QuDQoNCgkg DQoNCglGTEYgYXMgYW4gSW5kaXZpZHVhbDogdGhhdCB3b3JrcyBmb3IgbWUuDQoNCgkgDQoNCgkJ DQoJCQ0KCQkiDQoJCSAgVGhlIGRlbGl2ZXJ5IG9mIGNvbnRlbnQgbWF5IGJlIGZ1cnRoZXIgaW5m bHVlbmNlZCBieSBwb2xpY2llcyB3aGljaA0KCQkgIG1heSBpbmNsdWRlIHF1YWxpdHkgb2Ygc2Vy dmljZSBydWxlcyB0aGF0IHNwZWNpZnk6DQoJCSAgbyAgdGhlIG1heGltdW0gcmVzb2x1dGlvbiBk ZWxpdmVyYWJsZSB0byBzcGVjaWZpYyBkZXZpY2VzLA0KCQkgIG8gIHRoZSBtYXhpbXVtIHJlc29s dXRpb24gZGVsaXZlcmFibGUgdGhvdWdoIGEgc3BlY2lmaWMgTlNQLCBvcg0KCQkgIG8gIHRoZSBt YXhpbXVtIHJlc29sdXRpb24gZGVsaXZlcmFibGUgdG8gdXNlcnMgYmFzZWQgb24gdGhlaXINCgkJ ICAgICBzdWJzY3JpcHRpb24gbGV2ZWxzLg0KCQkiDQoJCUkgZG9uJ3QgdGhpbmsgdGhpcyBpcyBj b3ZlcmVkIGluIHRoZSBjZG5pLXJlcXVpcmVtZW50cyBkb2MuIA0KCQlJdCBpcyBub3Qgb2J2aW91 cyB0byBtZSB0aGF0IGFic29sdXRlbHkgYWxsIG9mIHRob3NlIG91Z2h0IHRvIGJlIGluDQoJCXBo YXNlIDEuIFRoZSBmaXJzdCBidWxsZXQgb25seSBtYWtlcyBzZW5zZSBpZiB0aGUgc29sdXRpb24g c3VwcG9ydHMNCgkJdHJhbnNjb2RpbmcvdHJhbnNyYXRpbmcsIHdoaWNoIEkgZG9uJ3Qga25vdyBp ZiBpdCB3aWxsIGJlIHN1cHBvcnRlZCBpbg0KCQlJbml0aWFsIHNjb3BlLg0KCQlUaGUgbGFzdCBi dWxsZXQgZG9lcyBub3QgbWFrZSBzZW5zZSB0byBtZSBhcyB3ZSBkb247dCB3YW50IHRoZSBDRE5z IHRvDQoJCWJlIGF3YXJlIG9mIGFueSB1c2VyIHN1YnNjcmlwdGlvbiBsZXZlbHMgKGllIG9ubHkg Q1NQIGlzIGF3YXJlIG9mIHVzZXINCgkJc3Vic2NyaXB0aW9uIGxldmVsKS4NCgkJDQoJCQ0KCQlL TD4gSSdtIG5vdCB5ZXQgY29udmluY2VkIHRoYXQgdGhpcyBzaG91bGQgYmUgcGFydCBvZiB0aGUg Q0ROSSBNZXRhZGF0YS4NCgkJQmFzZWQgb24gdGhlIGRpc2N1c3Npb24gY29uY2x1c2lvbiwgd2Ug Y2FuIHRyYWNrIHRoaXMgYXMgcG9zc2libGUNCgkJcmVxdWlyZW1lbnQgZm9yIG5vdy4NCg0KCSAN Cg0KCUZMRiBhcyBhIGNoYWlyOiBJIHdpbGwgcmFpc2UgYSBkaXNjdXNzaW9uIGluIHRoZSAiT3Bl biBJdGVtcyIgc2xvdCB0b3dhcmRzIHRoZSBlbmQgb2YgdGhlIFdHIG1lZXRpbmcgb24gIkNvbnRl bnQgQWRhcHRhdGlvbiIgYW5kIHdoYXQgc2hvdWRsIGJlIGluIHNjb3BlIG9mIENETkkuIFRoaXMg d2lsbCBnaXZlIHVzIHNvbWUgc2Vuc2Ugb24gdGhlIFdHIHZpZXdzIG9uIHRoYXQuDQoNCgkgDQoN CglGcmFuY29pcw0KDQoJIA0KDQoJIA0KDQoJDQoJS2VudA0KDQoJIA0KDQo8aW1hZ2UwMDEuanBn Pg0KDQoJDQoNCiANCg0KDQpGcmFuY29pcyBMZSBGYXVjaGV1cg0KRGlzdGluZ3Vpc2hlZCBFbmdp bmVlcg0KQ29ycG9yYXRlIERldmVsb3BtZW50DQpmbGVmYXVjaEBjaXNjby5jb20gPG1haWx0bzpm bGVmYXVjaEBjaXNjby5jb20+IA0KUGhvbmU6ICszMyA0OSA3MjMgMjYxOSA8dGVsOiUyQjMzJTIw NDklMjA3MjMlMjAyNjE5PiANCk1vYmlsZTogKzMzIDYgMTkgOTggNTAgOTAgPHRlbDolMkIzMyUy MDYlMjAxOSUyMDk4JTIwNTAlMjA5MD4gDQoNCkNpc2NvIFN5c3RlbXMgRnJhbmNlDQpHcmVlbnNp ZGUNCjQwMCBBdmUgZGUgUm91bWFuaWxsZQ0KMDY0MTAgU29waGlhIEFudGlwb2xpcw0KRnJhbmNl DQpDaXNjby5jb20gPGh0dHA6Ly93d3cuY2lzY28uY29tLz4gDQoNCiANCg0KDQo8aW1hZ2UwMDIu Z2lmPg0KDQoJDQoNCiBUaGluayBiZWZvcmUgeW91IHByaW50Lg0KDQoNClRoaXMgZW1haWwgbWF5 IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUgc29s ZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudC4gQW55IHJldmlldywgdXNlLCBkaXN0cmli dXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gSWYg eW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCAob3IgYXV0aG9yaXplZCB0byByZWNl aXZlIGZvciB0aGUgcmVjaXBpZW50KSwgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBieSByZXBs eSBlbWFpbCBhbmQgZGVsZXRlIGFsbCBjb3BpZXMgb2YgdGhpcyBtZXNzYWdlLg0KDQpDaXNjbyBT eXN0ZW1zIEZyYW5jZSwgU29jacOpdMOpIMOgIHJlc3BvbnNhYmlpdMOpIGxpbWl0w6llLCBSdWUg Q2FtaWxsZSBEZXNtb3VsaW5zIOKAkyBJbW0gQXRsYW50aXMgWmFjIEZvcnVtIFNlaW5lIElsb3Qg NyA5MjEzMCBJc3N5IGxlcyBNb3VsaW5lYXV4LCBBdSBjYXBpdGFsIGRlIDkxLjQ3MCDigqwsIDM0 OSAxNjYgNTYxIFJDUyBOYW50ZXJyZSwgRGlyZWN0ZXVyIGRlIGxhIHB1YmxpY2F0aW9uOiBKZWFu LUx1YyBNaWNoZWwgR2l2b25lLg0KDQpGb3IgY29ycG9yYXRlIGxlZ2FsIGluZm9ybWF0aW9uIGdv IHRvOg0KaHR0cDovL3d3dy5jaXNjby5jb20vd2ViL2Fib3V0L2RvaW5nX2J1c2luZXNzL2xlZ2Fs L2NyaS9pbmRleC5odG1sDQoNCgkgDQoNCgkgDQoNCjxpbWFnZTAwMS5qcGc+DQoNCgkNCg0KIA0K DQoNCkZyYW5jb2lzIExlIEZhdWNoZXVyDQpEaXN0aW5ndWlzaGVkIEVuZ2luZWVyDQpDb3Jwb3Jh dGUgRGV2ZWxvcG1lbnQNCmZsZWZhdWNoQGNpc2NvLmNvbQ0KUGhvbmU6ICszMyA0OSA3MjMgMjYx OSA8dGVsOiUyQjMzJTIwNDklMjA3MjMlMjAyNjE5PiANCk1vYmlsZTogKzMzIDYgMTkgOTggNTAg OTAgPHRlbDolMkIzMyUyMDYlMjAxOSUyMDk4JTIwNTAlMjA5MD4gDQoNCg0KDQpDaXNjbyBTeXN0 ZW1zIEZyYW5jZQ0KR3JlZW5zaWRlDQo0MDAgQXZlIGRlIFJvdW1hbmlsbGUNCjA2NDEwIFNvcGhp YSBBbnRpcG9saXMNCkZyYW5jZQ0KQ2lzY28uY29tIDxodHRwOi8vY2lzY28uY29tLz4gDQoNCiAN Cg0KDQo8Z3JlZW4uZ2lmPg0KDQoJDQogVGhpbmsgYmVmb3JlIHlvdSBwcmludC4NCg0KDQpUaGlz IGVtYWlsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBm b3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQuIEFueSByZXZpZXcsIHVz ZSwgZGlzdHJpYnV0aW9uIG9yIGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hp Yml0ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgKG9yIGF1dGhvcml6 ZWQgdG8gcmVjZWl2ZSBmb3IgdGhlIHJlY2lwaWVudCksIHBsZWFzZSBjb250YWN0IHRoZSBzZW5k ZXIgYnkgcmVwbHkgZW1haWwgYW5kIGRlbGV0ZSBhbGwgY29waWVzIG9mIHRoaXMgbWVzc2FnZS4N Cg0KQ2lzY28gU3lzdGVtcyBGcmFuY2UsIFNvY2nDqXTDqSDDoCByZXNwb25zYWJpaXTDqSBsaW1p dMOpZSwgUnVlIENhbWlsbGUgRGVzbW91bGlucyDigJMgSW1tIEF0bGFudGlzIFphYyBGb3J1bSBT ZWluZSBJbG90IDcgOTIxMzAgSXNzeSBsZXMgTW91bGluZWF1eCwgQXUgY2FwaXRhbCBkZSA5MS40 NzAg4oKsLCAzNDkgMTY2IDU2MSBSQ1MgTmFudGVycmUsIERpcmVjdGV1ciBkZSBsYSBwdWJsaWNh dGlvbjogSmVhbi1MdWMgTWljaGVsIEdpdm9uZS4NCg0KRm9yIGNvcnBvcmF0ZSBsZWdhbCBpbmZv cm1hdGlvbiBnbyB0bzoNCmh0dHA6Ly93d3cuY2lzY28uY29tL3dlYi9hYm91dC9kb2luZ19idXNp bmVzcy9sZWdhbC9jcmkvaW5kZXguaHRtbA0KDQoJIA0KDQogDQoNCiANCg0KCQ0KDQogDQoNCg0K RnJhbmNvaXMgTGUgRmF1Y2hldXINCkRpc3Rpbmd1aXNoZWQgRW5naW5lZXINCkNvcnBvcmF0ZSBE ZXZlbG9wbWVudA0KZmxlZmF1Y2hAY2lzY28uY29tIDxtYWlsdG86ZmxlZmF1Y2hAY2lzY28uY29t PiANClBob25lOiArMzMgNDkgNzIzIDI2MTkgPHRlbDolMkIzMyUyMDQ5JTIwNzIzJTIwMjYxOT4g DQpNb2JpbGU6ICszMyA2IDE5IDk4IDUwIDkwIDx0ZWw6JTJCMzMlMjA2JTIwMTklMjA5OCUyMDUw JTIwOTA+IA0KDQoNCg0KQ2lzY28gU3lzdGVtcyBGcmFuY2UNCkdyZWVuc2lkZQ0KNDAwIEF2ZSBk ZSBSb3VtYW5pbGxlDQowNjQxMCBTb3BoaWEgQW50aXBvbGlzDQpGcmFuY2UNCkNpc2NvLmNvbSA8 aHR0cDovL3d3dy5jaXNjby5jb20vPiANCg0KIA0KDQoNCiANCg0KCQ0KIFRoaW5rIGJlZm9yZSB5 b3UgcHJpbnQuDQoNCg0KVGhpcyBlbWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHBy aXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBp ZW50LiBBbnkgcmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVy cyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVj aXBpZW50IChvciBhdXRob3JpemVkIHRvIHJlY2VpdmUgZm9yIHRoZSByZWNpcGllbnQpLCBwbGVh c2UgY29udGFjdCB0aGUgc2VuZGVyIGJ5IHJlcGx5IGVtYWlsIGFuZCBkZWxldGUgYWxsIGNvcGll cyBvZiB0aGlzIG1lc3NhZ2UuDQoNCkNpc2NvIFN5c3RlbXMgRnJhbmNlLCBTb2Npw6l0w6kgw6Ag cmVzcG9uc2FiaWl0w6kgbGltaXTDqWUsIFJ1ZSBDYW1pbGxlIERlc21vdWxpbnMg4oCTIEltbSBB dGxhbnRpcyBaYWMgRm9ydW0gU2VpbmUgSWxvdCA3IDkyMTMwIElzc3kgbGVzIE1vdWxpbmVhdXgs IEF1IGNhcGl0YWwgZGUgOTEuNDcwIOKCrCwgMzQ5IDE2NiA1NjEgUkNTIE5hbnRlcnJlLCBEaXJl Y3RldXIgZGUgbGEgcHVibGljYXRpb246IEplYW4tTHVjIE1pY2hlbCBHaXZvbmUuDQoNCkZvciBj b3Jwb3JhdGUgbGVnYWwgaW5mb3JtYXRpb24gZ28gdG86DQpodHRwOi8vd3d3LmNpc2NvLmNvbS93 ZWIvYWJvdXQvZG9pbmdfYnVzaW5lc3MvbGVnYWwvY3JpL2luZGV4Lmh0bWwNCg0KIA0KDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpDRE5pIG1haWxp bmcgbGlzdA0KQ0ROaUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9jZG5pDQoNCg0KDQoNCi0tIA0KDQo= ------_=_NextPart_002_01CC52D7.A0FCB077 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PCEtLVtpZiAhbXNvXT48c3R5 bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7YmVoYXZpb3I6dXJs KCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KLnNo YXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwhW2VuZGlmXS0tPjxz dHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OkhlbHZldGljYTsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0 IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0x OjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21h Ow0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6VGltZXM7DQoJcGFub3NlLTE6MiAyIDYgMyA1IDQgNSAyIDMgNDt9DQovKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG b2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglm b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTIw DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVp biAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPjwvaGVhZD48Ym9keSBsYW5nPUVOLVVTIGxp bms9Ymx1ZSB2bGluaz1wdXJwbGU+PGRpdiBjbGFzcz1Xb3JkU2VjdGlvbjE+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+TXkgaW50ZXJwcmV0YXRpb24gb2Yg4oCcd2Vs bC1hY2NlcHRlZOKAnSBpcyB0aGF0IHRoZXNlIG1ldGFkYXRhIGVsZW1lbnRzIGFyZSBjb21tb24g Zm9yIENETkkgcmVnYXJkbGVzcyBvZiByZWdpb24sIHByb3ZpZGVyLCBlbnZpcm9ubWVudCwgZXRj LsKgIFRoZSBzcGVjaWZpYyBlbGVtZW50cyBhcmUgZGV0ZXJtaW5lZCBpbiB0aGUgc29sdXRpb25z IGRyYWZ0LsKgIEkgZXhwZWN0IHRoZXNlIGFyZSB0aGUgaW5mb3JtYXRpb24gbmVlZGVkIGZvciBi YXNpYyBDRE5JIG9wZXJhdGlvbiAoaS5lLiBuZWNlc3NhcnkgZm9yIGludGVyb3BlcmFiaWxpdHkp LsKgIFNvIHRoZXNlIGluZm9ybWF0aW9uIGVsZW1lbnRzIGFyZSBkZWZpbmVkIGluIHRoZSBzdGFu ZGFyZGl6ZWQgdHlwZXMuwqAgTm90ZSwgYSBzcGVjaWZpYyDCoGVudmlyb25tZW50IG1heSBvbmx5 IHVzZSBhIHN1YnNldCBvZiB0aGUgc3RhbmRhcmRpemVkIGVsZW1lbnRzLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFG NDk3RCc+Rm9yIOKAnG9wYXF1ZeKAnSwgSSBleHBlY3QgdGhhdCB0aGVyZSB3aWxsIGJlIGEgc3Rh bmRhcmRzIHR5cGUgdGhhdCBzcGVjaWZpZXMgdGhlIGluZm9ybWF0aW9uIGlzIG9wYXF1ZSAoaS5l LiBub3QgZGVmaW5lZCBieSBzdGFuZGFyZHMpIGFuZCBjYW4gYmUgdXNlZCBieSBwcml2YXRlIENE TiBhZ3JlZW1lbnQuwqAgU28sIGluIHRoaXMgY2FzZSwgaXQgbWF5IGJlIENETiBwcm92aWRlci1z cGVjaWZpYyBpbmZvcm1hdGlvbiBlbGVtZW50cy4gwqDCoEluIG1hbnkgcHJvdG9jb2xzLCB0aGlz IGlzIGRlZmluZWQgYXMgVmVuZG9yIFNwZWNpZmljIE9wdGlvbi9BdHRyaWJ1dGUuPG86cD48L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xv cjojMUY0OTdEJz5LZW50PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2IHN0 eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzoz LjBwdCAwaW4gMGluIDBpbic+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEi LCJzYW5zLXNlcmlmIic+IEJodW1pcCBLaGFzbmFiaXNoIFttYWlsdG86dnVtaXAxQGdtYWlsLmNv bV0gPGJyPjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgQXVndXN0IDA0LCAyMDExIDg6MDEgQU08YnI+ PGI+VG86PC9iPiBGcmFuY29pcyBMZSBGYXVjaGV1ciAoZmxlZmF1Y2gpPGJyPjxiPkNjOjwvYj4g S2VudCBMZXVuZyAoa2xldW5nKTsgWWl1IExlZTsgY2RuaUBpZXRmLm9yZzxicj48Yj5TdWJqZWN0 OjwvYj4gUmU6IFtDRE5pXSBGd2Q6IGNvbW1lbnRzIG9uIGRyYWZ0LWJlcnRyYW5kLWNkbmktdXNl LWNhc2VzLTAyPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48 bzpwPiZuYnNwOzwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5IZWxsbyw8bzpwPjwv bzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDs8bzpwPjwvbzpwPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5QbGVhc2Ugbm90ZSB0aGF0ICZxdW90O3dl bGwtYWNjZXB0ZWQmcXVvdDsgYW5kICZxdW90O29wYXF1ZSZxdW90OyBlbGVtZW50cyBtYXkgYmUg ZGlmZmVyZW50IGluIGRpZmZlcmVudCBlbnZpcm9ubWVudCAocmVnaW9uLCBwcm92aWRlciwgY29u dGV4dCwgZXRjLikuIDxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs Pk1heSBiZSBzb21lIDxlbT5zcGVjaWZpYzwvZW0+IGV4YW1wbGVzIGFyZSBuZWVkZWQgb24gd2hh dCBvbmUgbWVhbnMgYnkmbmJzcDsmbmJzcDsmcXVvdDt3ZWxsLWFjY2VwdGVkJnF1b3Q7IGFuZCAm cXVvdDtvcGFxdWUmcXVvdDsgbWV0YWRhdGEgZWxlbWVudHMgaW4gcmVnaW9uL3Byb3ZpZGVyL2Nv bnRleHQvLi4uIC4uLiAuLi4gLiBUaGFua3MuPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+Jm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+QmVzdC48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5CaHVt aXA8bzpwPjwvbzpwPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1i b3R0b206MTIuMHB0Jz48YnI+PGJyPjxvOnA+PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPk9uIEZyaSwgSnVsIDI5LCAyMDExIGF0IDEwOjAzIEFNLCBGcmFuY29pcyBMZSBGYXVjaGV1 ciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmZsZWZhdWNoQGNpc2NvLmNvbSI+ZmxlZmF1Y2hAY2lzY28u Y29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ S2VuLCBZaXUsIDxvOnA+PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkNhbiB5b3UgYWRkIGlu dG8geW91ciBsaXN0IG9mIHRyYWNrZWQgY2FuZGlkYXRlIGl0ZW1zIHNvbWV0aGluZyByZWZsZWN0 aW5nIHRoaXMgdGhyZWFkPyBpZSBlbnN1cmluZyBjZG5pLXJlcXVpcmVtZW50cyBpbmNvcnBvcmF0 ZXMgcmVxdWlyZW1lbnRzIG9uIHRoZSBDRE5JIE1ldGFkYXRhIGludGVyZmFjZSBjb3ZlcmluZzo8 bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4qQSogYWJpbGl0eSB0 byBleGNoYW5nZSBhIHNldCBvZiB3ZWxsLWFjY2VwdGVkIG1ldGFkYXRhIGVsZW1lbnRzIHdpdGgg c3BlY2lmaWVkIHNlbWFudGljcyAoZWcgc3RhcnQgb2YgdGltZSB3aW5kb3csIGVuZCBvZiB0aW1l IHdpbmRvdywuLi4pLCBBTkQ8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD4qQiogYWJpbGl0eSB0byZuYnNwO2FsbG93IGV4Y2hhbmdlIG9mIG9wYXF1ZSBtZXRhZGF0 YSBlbGVtZW50LCB3aG9zZSBzZW1hbnRpYyBpcyBub3QgZGVmaW5lZCBpbiBDRE5JIGJ1dCBsZWZ0 IHVwIHRvIHByaXZhdGUgQ0ROIGFncmVlbWVudC48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD5EYXZlIE9yYW4gYWxzbyBwcml2YXRlbHkgc3VnZ2VzdGVkIHRoYXQgd2UgZXhw YW5kIG9uICpCKiB0byBjb3ZlciB0aGUgdXN1YWwgZGlzdHJpYnV0aW9uIG9wdGlvbnMgZm9yIHRy ZWF0bWVudCBvZiBvcGFxdWUgZWxlbWVudCAoZWcgaWdub3JlLWFuZC1wYXNzLW9uLXdoZW4tbm90 LXVuZGVyc3Rvb2QsIGV0YykuIFdoaWNoIG1ha2VzIHNlbnNlIHRvIG1lLjxvOnA+PC9vOnA+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2 PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPlRoYW5rczxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPkZyYW5jb2lzPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD5CZWdpbiBmb3J3YXJkZWQgbWVzc2FnZTo8bzpwPjwvbzpwPjwvcD48L2Rpdj48cCBjbGFzcz1N c29Ob3JtYWw+PGJyPjxicj48bzpwPjwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48 Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseToiSGVsdmV0aWNhIiwi c2Fucy1zZXJpZiInPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMy41 cHQ7Zm9udC1mYW1pbHk6IkhlbHZldGljYSIsInNhbnMtc2VyaWYiJz5LZXZpbiBKIE1hICZsdDs8 YSBocmVmPSJtYWlsdG86a2V2aW4ubWFAYXp1a2lzeXN0ZW1zLmNvbSIgdGFyZ2V0PSJfYmxhbmsi PmtldmluLm1hQGF6dWtpc3lzdGVtcy5jb208L2E+Jmd0Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEz LjVwdDtmb250LWZhbWlseToiSGVsdmV0aWNhIiwic2Fucy1zZXJpZiInPkRhdGU6IDwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6IkhlbHZldGljYSIs InNhbnMtc2VyaWYiJz4yOCBKdWx5IDIwMTEgMTc6MzU6MjIgRURUPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTMuNXB0O2ZvbnQtZmFtaWx5OiJIZWx2ZXRpY2EiLCJzYW5zLXNlcmlmIic+VG86IDwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6IkhlbHZldGlj YSIsInNhbnMtc2VyaWYiJz5GcmFuY29pcyBMZSBGYXVjaGV1ciAmbHQ7PGEgaHJlZj0ibWFpbHRv OmZsZWZhdWNoQGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmZsZWZhdWNoQGNpc2NvLmNvbTwv YT4mZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs PjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiJIZWx2ZXRpY2Ei LCJzYW5zLXNlcmlmIic+Q2M6IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMy41 cHQ7Zm9udC1mYW1pbHk6IkhlbHZldGljYSIsInNhbnMtc2VyaWYiJz5GcmFuY29pcyBMZSBGYXVj aGV1ciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmZsZWZhdWNoQGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPmZsZWZhdWNoQGNpc2NvLmNvbTwvYT4mZ3Q7LCAmcXVvdDtLZW50IExldW5nIChrbGV1bmcp JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86a2xldW5nQGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPmtsZXVuZ0BjaXNjby5jb208L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmRyYWZ0 LWJlcnRyYW5kLWNkbmktdXNlLWNhc2VzQHRvb2xzLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ ZHJhZnQtYmVydHJhbmQtY2RuaS11c2UtY2FzZXNAdG9vbHMuaWV0Zi5vcmc8L2E+JnF1b3Q7ICZs dDs8YSBocmVmPSJtYWlsdG86ZHJhZnQtYmVydHJhbmQtY2RuaS11c2UtY2FzZXNAdG9vbHMuaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5kcmFmdC1iZXJ0cmFuZC1jZG5pLXVzZS1jYXNlc0B0b29s cy5pZXRmLm9yZzwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86Y2RuaUBpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPmNkbmlAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWls dG86Y2RuaUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmNkbmlAaWV0Zi5vcmc8L2E+Jmd0Ozwv c3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6IkhlbHZldGlj YSIsInNhbnMtc2VyaWYiJz5TdWJqZWN0OiBSZTogW0NETmldIGNvbW1lbnRzIG9uIGRyYWZ0LWJl cnRyYW5kLWNkbmktdXNlLWNhc2VzLTAyPC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD48L2Rpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PGRpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD5pIHRoaW5rIHRoZXJlIGNvdWxkIGJlIGFsb3Qgb2YgZGViYXRlIGFib3V0IHdo YXQgcXVhbGlmaWVzIGFzIEEuPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ b25lIHNvbHV0aW9uIHdvdWxkIGJlIHRvIGdvIHdpdGgganVzdCBCLCBmb3IgcmVxdWlyZW1lbnRz LCBidXQ8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5laXRoZXIg d2F5IGlzIG9rIHdpdGggbWUuPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+PGJyPlNlbnQgZnJvbSBteSBpUGhvbmU8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPjxicj5PbiBKdWwg MjgsIDIwMTEsIGF0IDU6MjIgUE0sICZxdW90O0ZyYW5jb2lzIExlIEZhdWNoZXVyJnF1b3Q7ICZs dDs8YSBocmVmPSJtYWlsdG86ZmxlZmF1Y2hAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+Zmxl ZmF1Y2hAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+PC9kaXY+PGJsb2Nr cXVvdGUgc3R5bGU9J21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCc+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PGRpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD5PbiAyOCBKdWwgMjAxMSwgYXQgMTY6NTQsIEtldmluIEogTWEgd3JvdGU6PG86 cD48L286cD48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxicj48YnI+PG86cD48L286cD48 L3A+PGRpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPkp1c3Qgb25lIHF1aWNrIGNvbW1l bnQ6IGl0IHdhcyBub3QgbmVjZXNzYXJpbHkgdGhlIGludGVudCBvZiB0aGUgdXNlIGNhc2VzIHRv IGltcGx5PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIn PnRoYXQgQ0ROSSByZXF1aXJlbWVudHMgYmUgZ2VuZXJhdGVkIGZvciBlYWNoIHBpZWNlIG9mIG1l dGFkYXRhOyB0aGUgbWV0YWRhdGEgbWF5IGJlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyInPnVzZWZ1bCBmb3IgY2VydGFpbiBkZXBsb3ltZW50cywgYnV0 IG9wYXF1ZSBtZXRhZGF0YSBkaXN0cmlidXRpb24gbWF5IGJlIHN1ZmZpY2llbnQ/PC9zcGFuPjxv OnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz5UaGVyZSB3YXMgZGlz Y3Vzc2lvbiBlYXJseSBvbiBhYm91dCBtZXRhZGF0YSB3aXRoIGltcGxpZWQgYWN0aW9ucyBsaWtl OiBleHBpcmF0aW9uLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmll ciBOZXciJz5vciBzdW5zZXQvc3VucmlzZSwgb3Igc3NsIG9ubHksIG9yIHVybCBoYXNoaW5nIHJl cXVpcmVkLCBvciBjb250ZW50IHRyYW5zZm9ybWF0aW9uLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseToiQ291cmllciBOZXciJz5vciBkbyBhY2NvdW50aW5nLCBvciBvdGhlciBw cm9wcmlldGFyeSBvcHRpbWl6YXRpb24gb3IgcG9saWN5IGVuZm9yY2VtZW50IGZlYXR1cmVzLDwv c3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz5ldGMuLCBi dXQgaXRzIG5vdCBjbGVhciB0aGF0IHdlIHdvdWxkIHdhbnQgQ0ROSSByZXF1aXJlbWVudHMgZm9y IGVhY2ggb2YgdGhlc2U/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyInPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291 cmllciBOZXciJz5JdCBzZWVtcyBsaWtlIGEgbW9yZSBnZW5lcmljIG5vdGlvbiBvZiBkZWZpbmlu ZyBtZXRhZGF0YSAoYW5kIHRoZWlyIGFjdGlvbnMpLCBhbmQ8L3NwYW4+PG86cD48L286cD48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+YWxsb3dpbmcgQ0ROcyB0byBhZHZlcnRpc2Ug b3IgZGVjbGluZSBtZXRhZGF0YSAoYWN0aW9uKSBzdXBwb3J0IHdvdWxkIHVzZWZ1bCwgYXM8L3Nw YW4+PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+b3Bwb3NlZCB0 byBhZGRpbmcgYSByZXF1aXJlbWVudCBmb3IgZWFjaCBwaWVjZSBvZiBtZXRhZGF0YT88L3NwYW4+ PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+SSBoYXZl IGJlZW4gYXNzdW1pbmcgdGhhdCB3ZSdkIHdhbnQgdG8gc3BlY2lmeTo8bzpwPjwvbzpwPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4qQSogYSBzZXQgb2Ygd2VsbC1hY2NlcHRlZCBt ZXRhZGF0YSBlbGVtZW50cyB3aXRoIHRoZWlyIHNlbWFudGljcyAoZWcgc3RhcnQgb2YgdGltZSB3 aW5kb3csIGVuZCBvZiB0aW1lIHdpbmRvdywuLi4pLCBBTkQ8bzpwPjwvbzpwPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4qQiogcHJvYmFibHksIGFsc28gYSBtZWNoYW5pc20gdG8g YWxsb3cgZXhjaGFuZ2Ugb2Ygb3BhcXVlIG1ldGFkYXRhIGVsZW1lbnQsIHdob3NlIHNlbWFudGlj IGlzIG5vdCBkZWZpbmVkIGluIENETkkgYnV0IHVwIHRvIHByaXZhdGUgQ0ROIGFncmVlbWVudC48 bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwv bzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5JIGJlbGlldmUgKkEqIGlzIG5l ZWRlZCB0byBmYWNpbGl0YXRlIGFjdHVhbCBiYXNlIGludGVyb3BlcmF0aW9uIGFjcm9zcyBDRE5z LjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkkgYmVsaWV2ZSAq QiogaXMgdXNlZnVsIHRvIGFsbG93IENETnMgdG8gZG8gZXh0cmEgdGhpbmcgb24gdG9wIG9mIHdo YXQgaGFzIGJlZW4gc3BlY2lmaWVkIGluIENETkkuPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+QXJlIHlvdSBzYXlpbmcgdGhhdCB5b3UgZmVlbCBvbmx5ICpCKiBp cyBuZWVkZWQ/PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86 cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Q2hlZXJzPG86 cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286 cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+RnJhbmNvaXM8bzpwPjwvbzpwPjwv cD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PGJyPjxicj48bzpwPjwvbzpwPjwvcD48ZGl2Pjxk aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwv ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48 L2Rpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQnPjxkaXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4n PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlm Iic+Jm5ic3A7RnJhbmNvaXMgTGUgRmF1Y2hldXIgW21haWx0bzo8YSBocmVmPSJtYWlsdG86Zmxl ZmF1Y2hAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+ZmxlZmF1Y2hAY2lzY28uY29tPC9hPl0m bmJzcDs8YnI+PGI+U2VudDo8L2I+Jm5ic3A7VGh1cnNkYXksIEp1bHkgMjgsIDIwMTEgNDoxNyBQ TTxicj48Yj5Ubzo8L2I+Jm5ic3A7S2VudCBMZXVuZyAoa2xldW5nKTxicj48Yj5DYzo8L2I+Jm5i c3A7RnJhbmNvaXMgTGUgRmF1Y2hldXI7Jm5ic3A7PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWJlcnRy YW5kLWNkbmktdXNlLWNhc2VzQHRvb2xzLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ZHJhZnQt YmVydHJhbmQtY2RuaS11c2UtY2FzZXNAdG9vbHMuaWV0Zi5vcmc8L2E+OyZuYnNwOzxhIGhyZWY9 Im1haWx0bzpjZG5pQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+Y2RuaUBpZXRmLm9yZzwvYT48 YnI+PGI+U3ViamVjdDo8L2I+Jm5ic3A7UmU6IFtDRE5pXSBjb21tZW50cyBvbiBkcmFmdC1iZXJ0 cmFuZC1jZG5pLXVzZS1jYXNlcy0wMjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5LZW50IGFuZCBhbGwsPG86cD48L286cD48L3A+PC9kaXY+ PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48 ZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+T24gMjggSnVsIDIwMTEsIGF0IDE2OjEw LCBLZW50IExldW5nIChrbGV1bmcpIHdyb3RlOjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+PG86cD4m bmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5IaSBGcmFu Y29pcy4gJm5ic3A7UmVzcG9uZGluZyB0byBjb21tZW50cyByZWxhdGVkIHRvIHRoZSByZXF1aXJl bWVudHMgZHJhZnQ8YnI+YmVsb3cuPGJyPjxicj48YnI+Jm5ic3A7Jm5ic3A7byAmbmJzcDthbiBl eHBpcmF0aW9uIHRpbWUgKGkuZS4sIHRoZSB0aW1lIGF0IHdoaWNoIHRoZSBjb250ZW50IGZpbGVz PGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3Nob3VsZCBiZSBleHB1bmdlZCBmcm9t IGFsbCBDRE4gc3RvcmFnZSkuPGJyPiZxdW90Ozxicj5JIHVuZGVyc3RhbmQgdGhpcyBpcyBzYXlp bmcgdGhhdCBDRE5JIG1ldGFkYXRhIG5lZWQgdG8gaW5jbHVkZSB0aGlzPGJyPmV4cGlyYXRpb24g dGltZSAodHJpZ2dlcmluZyBjYWNoZSByZW1vdmFsKSAsIGluIGFkZGl0aW9uIHRvIGRlYWN0aXZh dGlvbjxicj50aW1lLiZuYnNwOzxicj5JIGRvbid0IHRoaW5rIHRoaXMgaXMgZGlzY3Vzc2VkIGlu IGNkbmktcmVxdWlyZW1lbnRzIHlldC4gQ2FuIHlvdSBicmluZzxicj50aGF0IHVwIG9uIHRoZSBs aXN0IHdpdGggdGhlIGNkbmktcmVxdHMgYXV0aG9ycz88YnI+PGJyPktMJmd0OyBJJ3ZlIHNlZW4g cmVmZXJlbmNlcyB0byBjb250ZW50IGV4cGlyYXRpb24gdGltZSAoaS5lLiByZW1vdmFsKSBpbjxi cj5zb21lIGRyYWZ0cy4gJm5ic3A7U28gaXQgc2VlbXMgdG8gYmUgbmVlZGVkIGluIHRoZSBDRE5J IE1ldGFkYXRhLiAmbmJzcDtOb3RlZCBhczxicj5yZXF1aXJlbWVudCAocG9zc2libHkgcGFydCBv ZiBhdmFpbGFiaWxpdHkgd2luZG93KSB1bmxlc3Mgb3RoZXJzIG9iamVjdC48bzpwPjwvbzpwPjwv cD48L2Rpdj48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPiZuYnNwOzxvOnA+PC9v OnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+RkxGIGFzIGFu IEluZGl2aWR1YWw6IHRoYXQgd29ya3MgZm9yIG1lLjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2 PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+ PC9kaXY+PGJsb2NrcXVvdGUgc3R5bGU9J21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCc+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48YnI+PGJyPiZxdW90Ozxicj4mbmJz cDsmbmJzcDtUaGUgZGVsaXZlcnkgb2YgY29udGVudCBtYXkgYmUgZnVydGhlciBpbmZsdWVuY2Vk IGJ5IHBvbGljaWVzIHdoaWNoPGJyPiZuYnNwOyZuYnNwO21heSBpbmNsdWRlIHF1YWxpdHkgb2Yg c2VydmljZSBydWxlcyB0aGF0IHNwZWNpZnk6PGJyPiZuYnNwOyZuYnNwO28gJm5ic3A7dGhlIG1h eGltdW0gcmVzb2x1dGlvbiBkZWxpdmVyYWJsZSB0byBzcGVjaWZpYyBkZXZpY2VzLDxicj4mbmJz cDsmbmJzcDtvICZuYnNwO3RoZSBtYXhpbXVtIHJlc29sdXRpb24gZGVsaXZlcmFibGUgdGhvdWdo IGEgc3BlY2lmaWMgTlNQLCBvcjxicj4mbmJzcDsmbmJzcDtvICZuYnNwO3RoZSBtYXhpbXVtIHJl c29sdXRpb24gZGVsaXZlcmFibGUgdG8gdXNlcnMgYmFzZWQgb24gdGhlaXI8YnI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7c3Vic2NyaXB0aW9uIGxldmVscy48YnI+JnF1b3Q7PGJyPkkg ZG9uJ3QgdGhpbmsgdGhpcyBpcyBjb3ZlcmVkIGluIHRoZSBjZG5pLXJlcXVpcmVtZW50cyBkb2Mu Jm5ic3A7PGJyPkl0IGlzIG5vdCBvYnZpb3VzIHRvIG1lIHRoYXQgYWJzb2x1dGVseSBhbGwgb2Yg dGhvc2Ugb3VnaHQgdG8gYmUgaW48YnI+cGhhc2UgMS4gVGhlIGZpcnN0IGJ1bGxldCBvbmx5IG1h a2VzIHNlbnNlIGlmIHRoZSBzb2x1dGlvbiBzdXBwb3J0czxicj50cmFuc2NvZGluZy90cmFuc3Jh dGluZywgd2hpY2ggSSBkb24ndCBrbm93IGlmIGl0IHdpbGwgYmUgc3VwcG9ydGVkIGluPGJyPklu aXRpYWwgc2NvcGUuPGJyPlRoZSBsYXN0IGJ1bGxldCBkb2VzIG5vdCBtYWtlIHNlbnNlIHRvIG1l IGFzIHdlIGRvbjt0IHdhbnQgdGhlIENETnMgdG88YnI+YmUgYXdhcmUgb2YgYW55IHVzZXIgc3Vi c2NyaXB0aW9uIGxldmVscyAoaWUgb25seSBDU1AgaXMgYXdhcmUgb2YgdXNlcjxicj5zdWJzY3Jp cHRpb24gbGV2ZWwpLjxicj48YnI+PGJyPktMJmd0OyBJJ20gbm90IHlldCBjb252aW5jZWQgdGhh dCB0aGlzIHNob3VsZCBiZSBwYXJ0IG9mIHRoZSBDRE5JIE1ldGFkYXRhLjxicj5CYXNlZCBvbiB0 aGUgZGlzY3Vzc2lvbiBjb25jbHVzaW9uLCB3ZSBjYW4gdHJhY2sgdGhpcyBhcyBwb3NzaWJsZTxi cj5yZXF1aXJlbWVudCBmb3Igbm93LjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjwvYmxvY2tx dW90ZT48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjwv ZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+RkxGIGFzIGEgY2hhaXI6IEkg d2lsbCByYWlzZSBhIGRpc2N1c3Npb24gaW4gdGhlICZxdW90O09wZW4gSXRlbXMmcXVvdDsgc2xv dCB0b3dhcmRzIHRoZSBlbmQgb2YgdGhlIFdHIG1lZXRpbmcgb24gJnF1b3Q7Q29udGVudCBBZGFw dGF0aW9uJnF1b3Q7IGFuZCB3aGF0IHNob3VkbCBiZSBpbiBzY29wZSBvZiBDRE5JLiBUaGlzIHdp bGwgZ2l2ZSB1cyBzb21lIHNlbnNlIG9uIHRoZSBXRyB2aWV3cyBvbiB0aGF0LjxvOnA+PC9vOnA+ PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7PG86cD48 L286cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5GcmFuY29p czxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ Jm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPjxicj5L ZW50PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Jm5i c3A7PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48ZGl2Pjx0YWJsZSBjbGFzcz1Nc29Ob3JtYWxU YWJsZSBib3JkZXI9MCBjZWxsc3BhY2luZz0wIGNlbGxwYWRkaW5nPTAgd2lkdGg9NTQzIHN0eWxl PSd3aWR0aDo0MDcuMjVwdCc+PHRyPjx0ZCBzdHlsZT0ncGFkZGluZzowaW4gMGluIDBpbiAwaW4n PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuNXB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Jmx0O2ltYWdl MDAxLmpwZyZndDs8L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PHRhYmxlIGNsYXNzPU1zb05v cm1hbFRhYmxlIGJvcmRlcj0wIGNlbGxzcGFjaW5nPTAgY2VsbHBhZGRpbmc9MCB3aWR0aD01NDMg c3R5bGU9J3dpZHRoOjQwNy4yNXB0Jz48dHI+PHRkIHN0eWxlPSdwYWRkaW5nOjBpbiAwaW4gMGlu IDBpbic+PC90ZD48L3RyPjwvdGFibGU+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdk aXNwbGF5Om5vbmUnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48dGFibGUgY2xhc3M9TXNv Tm9ybWFsVGFibGUgYm9yZGVyPTAgY2VsbHNwYWNpbmc9MCBjZWxscGFkZGluZz0wIHdpZHRoPTU0 MyBzdHlsZT0nd2lkdGg6NDA3LjI1cHQnPjx0cj48dGQgbm93cmFwIHZhbGlnbj10b3Agc3R5bGU9 J3BhZGRpbmc6MGluIDBpbiAxMS4yNXB0IC4yNWluJz48cCBzdHlsZT0nbWFyZ2luLWJvdHRvbTox Mi4wcHQnPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6IkFyaWFs Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzY2NjY2Nic+PGJyPjxzdHJvbmc+PHNwYW4gc3R5bGU9J2Zv bnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz5GcmFuY29pcyBMZSBGYXVjaGV1cjwvc3Bh bj48L3N0cm9uZz48L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OC41cHQ7Zm9udC1m YW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzY2NjY2Nic+PGJyPjxzdHJvbmc+PHNw YW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz5EaXN0aW5ndWlzaGVk IEVuZ2luZWVyPC9zcGFuPjwvc3Ryb25nPjxicj48c3Ryb25nPjxzcGFuIHN0eWxlPSdmb250LWZh bWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+Q29ycG9yYXRlIERldmVsb3BtZW50PC9zcGFuPjwv c3Ryb25nPjxicj48YSBocmVmPSJtYWlsdG86ZmxlZmF1Y2hAY2lzY28uY29tIiB0YXJnZXQ9Il9i bGFuayI+PHNwYW4gc3R5bGU9J2NvbG9yOiM2NjY2NjYnPmZsZWZhdWNoQGNpc2NvLmNvbTwvc3Bh bj48L2E+PGJyPlBob25lOiZuYnNwOzxzdHJvbmc+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJB cmlhbCIsInNhbnMtc2VyaWYiJz48YSBocmVmPSJ0ZWw6JTJCMzMlMjA0OSUyMDcyMyUyMDI2MTki IHRhcmdldD0iX2JsYW5rIj4rMzMgNDkgNzIzIDI2MTk8L2E+PC9zcGFuPjwvc3Ryb25nPjxicj5N b2JpbGU6Jm5ic3A7PHN0cm9uZz48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fu cy1zZXJpZiInPjxhIGhyZWY9InRlbDolMkIzMyUyMDYlMjAxOSUyMDk4JTIwNTAlMjA5MCIgdGFy Z2V0PSJfYmxhbmsiPiszMyA2IDE5IDk4IDUwIDkwPC9hPjwvc3Bhbj48L3N0cm9uZz48L3NwYW4+ PG86cD48L286cD48L3A+PC90ZD48dGQgbm93cmFwIHZhbGlnbj10b3Agc3R5bGU9J3BhZGRpbmc6 MGluIDBpbiA3LjVwdCAxNS4wcHQnPjxwIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+PHN0 cm9uZz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNh bnMtc2VyaWYiO2NvbG9yOiM2NjY2NjYnPkNpc2NvIFN5c3RlbXMgRnJhbmNlPC9zcGFuPjwvc3Ry b25nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fu cy1zZXJpZiI7Y29sb3I6IzY2NjY2Nic+PGJyPkdyZWVuc2lkZTxicj40MDAgQXZlIGRlIFJvdW1h bmlsbGU8YnI+MDY0MTAgU29waGlhIEFudGlwb2xpczxicj5GcmFuY2U8YnI+PGEgaHJlZj0iaHR0 cDovL3d3dy5jaXNjby5jb20vIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9J2NvbG9yOiM2 NjY2NjYnPkNpc2NvLmNvbTwvc3Bhbj48L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvdGQ+PHRk IHdpZHRoPTIwMCBzdHlsZT0nd2lkdGg6MTUwLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDBpbic+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+PC90ZD48 L3RyPjwvdGFibGU+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMy41cHQ7Zm9udC1mYW1pbHk6IkhlbHZldGljYSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNr Jz48YnI+Jmx0O2ltYWdlMDAyLmdpZiZndDs8L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PHRh YmxlIGNsYXNzPU1zb05vcm1hbFRhYmxlIGJvcmRlcj0wIGNlbGxzcGFjaW5nPTAgY2VsbHBhZGRp bmc9MCB3aWR0aD00MDAgc3R5bGU9J3dpZHRoOjMwMC4wcHQnPjx0cj48dGQgc3R5bGU9J3BhZGRp bmc6MGluIDBpbiAwaW4gMGluJz48L3RkPjwvdHI+PHRyPjx0ZCBzdHlsZT0ncGFkZGluZzowaW4g LjI1aW4gMGluIC4yNWluJz48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiMwMDk5 MDAnPiZuYnNwO1RoaW5rIGJlZm9yZSB5b3UgcHJpbnQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwv ZGl2PjwvdGQ+PC90cj48dHI+PHRkIHN0eWxlPSdwYWRkaW5nOjUuMjVwdCAuMjVpbiA0LjVwdCAu MjVpbic+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlm Ijtjb2xvcjojOTk5OTk5Jz48YnI+VGhpcyBlbWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwg YW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQg cmVjaXBpZW50LiBBbnkgcmV2aWV3LCB1c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5 IG90aGVycyBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5k ZWQgcmVjaXBpZW50IChvciBhdXRob3JpemVkIHRvIHJlY2VpdmUgZm9yIHRoZSByZWNpcGllbnQp LCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGJ5IHJlcGx5IGVtYWlsIGFuZCBkZWxldGUgYWxs IGNvcGllcyBvZiB0aGlzIG1lc3NhZ2UuPGJyPjxicj5DaXNjbyBTeXN0ZW1zIEZyYW5jZSwgU29j acOpdMOpIMOgIHJlc3BvbnNhYmlpdMOpIGxpbWl0w6llLCBSdWUgQ2FtaWxsZSBEZXNtb3VsaW5z IOKAkyBJbW0gQXRsYW50aXMgWmFjIEZvcnVtIFNlaW5lIElsb3QgNyA5MjEzMCBJc3N5IGxlcyBN b3VsaW5lYXV4LCBBdSBjYXBpdGFsIGRlIDkxLjQ3MCDigqwsIDM0OSAxNjYgNTYxIFJDUyBOYW50 ZXJyZSwgRGlyZWN0ZXVyIGRlIGxhIHB1YmxpY2F0aW9uOiBKZWFuLUx1YyBNaWNoZWwgR2l2b25l Ljxicj48YnI+Rm9yIGNvcnBvcmF0ZSBsZWdhbCBpbmZvcm1hdGlvbiBnbyB0bzo8YnI+PGEgaHJl Zj0iaHR0cDovL3d3dy5jaXNjby5jb20vd2ViL2Fib3V0L2RvaW5nX2J1c2luZXNzL2xlZ2FsL2Ny aS9pbmRleC5odG1sIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3d3dy5jaXNjby5jb20vd2ViL2Fi b3V0L2RvaW5nX2J1c2luZXNzL2xlZ2FsL2NyaS9pbmRleC5odG1sPC9hPjwvc3Bhbj48bzpwPjwv bzpwPjwvcD48L3RkPjwvdHI+PC90YWJsZT48L3RkPjwvdHI+PC90YWJsZT48L2Rpdj48L2Rpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48 L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286 cD48L3A+PGRpdj48ZGl2Pjx0YWJsZSBjbGFzcz1Nc29Ob3JtYWxUYWJsZSBib3JkZXI9MCBjZWxs c3BhY2luZz0wIGNlbGxwYWRkaW5nPTAgd2lkdGg9NTQzIHN0eWxlPSd3aWR0aDo0MDcuMjVwdCc+ PHRyPjx0ZCBzdHlsZT0ncGFkZGluZzowaW4gMGluIDBpbiAwaW4nPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiZsdDtpbWFnZTAwMS5qcGcmZ3Q7PC9zcGFuPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiJUaW1lcyIsInNlcmlmIjtjb2xv cjojMUY0OTdEJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHRhYmxlIGNsYXNzPU1zb05vcm1hbFRh YmxlIGJvcmRlcj0wIGNlbGxzcGFjaW5nPTAgY2VsbHBhZGRpbmc9MCB3aWR0aD01NDMgc3R5bGU9 J3dpZHRoOjQwNy4yNXB0Jz48dHI+PHRkIHN0eWxlPSdwYWRkaW5nOjBpbiAwaW4gMGluIDBpbic+ PC90ZD48L3RyPjwvdGFibGU+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTMuNXB0O2ZvbnQtZmFtaWx5OiJUaW1lcyIsInNlcmlmIjtjb2xvcjojMUY0OTdEO2Rpc3Bs YXk6bm9uZSc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjx0YWJsZSBjbGFzcz1Nc29Ob3Jt YWxUYWJsZSBib3JkZXI9MCBjZWxsc3BhY2luZz0wIGNlbGxwYWRkaW5nPTAgd2lkdGg9NTQzIHN0 eWxlPSd3aWR0aDo0MDcuMjVwdCc+PHRyPjx0ZCBub3dyYXAgdmFsaWduPXRvcCBzdHlsZT0ncGFk ZGluZzowaW4gMGluIDExLjI1cHQgLjI1aW4nPjxwIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBw dCc+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseToiQXJpYWwiLCJz YW5zLXNlcmlmIjtjb2xvcjojNjY2NjY2Jz48YnI+PHN0cm9uZz48c3BhbiBzdHlsZT0nZm9udC1m YW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPkZyYW5jb2lzIExlIEZhdWNoZXVyPC9zcGFuPjwv c3Ryb25nPjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWls eToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojNjY2NjY2Jz48YnI+PHN0cm9uZz48c3BhbiBz dHlsZT0nZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPkRpc3Rpbmd1aXNoZWQgRW5n aW5lZXI8L3NwYW4+PC9zdHJvbmc+PGJyPjxzdHJvbmc+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5 OiJBcmlhbCIsInNhbnMtc2VyaWYiJz5Db3Jwb3JhdGUgRGV2ZWxvcG1lbnQ8L3NwYW4+PC9zdHJv bmc+PGJyPjxhIGhyZWY9Im1haWx0bzpmbGVmYXVjaEBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5r Ij5mbGVmYXVjaEBjaXNjby5jb208L2E+PGJyPlBob25lOiZuYnNwOzxzdHJvbmc+PHNwYW4gc3R5 bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz48YSBocmVmPSJ0ZWw6JTJCMzMl MjA0OSUyMDcyMyUyMDI2MTkiIHRhcmdldD0iX2JsYW5rIj4rMzMgNDkgNzIzIDI2MTk8L2E+PC9z cGFuPjwvc3Ryb25nPjxicj5Nb2JpbGU6Jm5ic3A7PHN0cm9uZz48c3BhbiBzdHlsZT0nZm9udC1m YW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPjxhIGhyZWY9InRlbDolMkIzMyUyMDYlMjAxOSUy MDk4JTIwNTAlMjA5MCIgdGFyZ2V0PSJfYmxhbmsiPiszMyA2IDE5IDk4IDUwIDkwPC9hPjwvc3Bh bj48L3N0cm9uZz48YnI+PGJyPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L3RkPjx0ZCBub3dyYXAg dmFsaWduPXRvcCBzdHlsZT0ncGFkZGluZzowaW4gMGluIDcuNXB0IDE1LjBwdCc+PHAgc3R5bGU9 J21hcmdpbi1ib3R0b206MTIuMHB0Jz48c3Ryb25nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OC41 cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzY2NjY2Nic+Q2lzY28g U3lzdGVtcyBGcmFuY2U8L3NwYW4+PC9zdHJvbmc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo4LjVw dDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojNjY2NjY2Jz48YnI+R3Jl ZW5zaWRlPGJyPjQwMCBBdmUgZGUgUm91bWFuaWxsZTxicj4wNjQxMCBTb3BoaWEgQW50aXBvbGlz PGJyPkZyYW5jZTxicj48YSBocmVmPSJodHRwOi8vY2lzY28uY29tLyIgdGFyZ2V0PSJfYmxhbmsi PkNpc2NvLmNvbTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC90ZD48dGQgd2lkdGg9MjAwIHN0 eWxlPSd3aWR0aDoxNTAuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gMGluJz48cCBjbGFzcz1Nc29O b3JtYWw+Jm5ic3A7PG86cD48L286cD48L3A+PC90ZD48L3RyPjwvdGFibGU+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiJIZWx2ZXRp Y2EiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48YnI+Jmx0O2dyZWVuLmdpZiZndDs8L3Nw YW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6IlRpbWVzIiwic2Vy aWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48dGFibGUgY2xhc3M9TXNv Tm9ybWFsVGFibGUgYm9yZGVyPTAgY2VsbHNwYWNpbmc9MCBjZWxscGFkZGluZz0wIHdpZHRoPTQw MCBzdHlsZT0nd2lkdGg6MzAwLjBwdCc+PHRyPjx0ZCBzdHlsZT0ncGFkZGluZzowaW4gMGluIDBp biAwaW4nPjwvdGQ+PC90cj48dHI+PHRkIHN0eWxlPSdwYWRkaW5nOjBpbiAuMjVpbiAwaW4gLjI1 aW4nPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjcuNXB0O2ZvbnQt ZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOiMwMDk5MDAnPiZuYnNwO1RoaW5rIGJl Zm9yZSB5b3UgcHJpbnQuPG86cD48L286cD48L3NwYW4+PC9wPjwvdGQ+PC90cj48dHI+PHRkIHN0 eWxlPSdwYWRkaW5nOjUuMjVwdCAuMjVpbiA0LjVwdCAuMjVpbic+PHAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjVw dDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojOTk5OTk5Jz48YnI+VGhp cyBlbWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwg Zm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LiBBbnkgcmV2aWV3LCB1 c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9o aWJpdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IChvciBhdXRob3Jp emVkIHRvIHJlY2VpdmUgZm9yIHRoZSByZWNpcGllbnQpLCBwbGVhc2UgY29udGFjdCB0aGUgc2Vu ZGVyIGJ5IHJlcGx5IGVtYWlsIGFuZCBkZWxldGUgYWxsIGNvcGllcyBvZiB0aGlzIG1lc3NhZ2Uu PGJyPjxicj5DaXNjbyBTeXN0ZW1zIEZyYW5jZSwgU29jacOpdMOpIMOgIHJlc3BvbnNhYmlpdMOp IGxpbWl0w6llLCBSdWUgQ2FtaWxsZSBEZXNtb3VsaW5zIOKAkyBJbW0gQXRsYW50aXMgWmFjIEZv cnVtIFNlaW5lIElsb3QgNyA5MjEzMCBJc3N5IGxlcyBNb3VsaW5lYXV4LCBBdSBjYXBpdGFsIGRl IDkxLjQ3MCDigqwsIDM0OSAxNjYgNTYxIFJDUyBOYW50ZXJyZSwgRGlyZWN0ZXVyIGRlIGxhIHB1 YmxpY2F0aW9uOiBKZWFuLUx1YyBNaWNoZWwgR2l2b25lLjxicj48YnI+Rm9yIGNvcnBvcmF0ZSBs ZWdhbCBpbmZvcm1hdGlvbiBnbyB0bzo8YnI+PGEgaHJlZj0iaHR0cDovL3d3dy5jaXNjby5jb20v d2ViL2Fib3V0L2RvaW5nX2J1c2luZXNzL2xlZ2FsL2NyaS9pbmRleC5odG1sIiB0YXJnZXQ9Il9i bGFuayI+aHR0cDovL3d3dy5jaXNjby5jb20vd2ViL2Fib3V0L2RvaW5nX2J1c2luZXNzL2xlZ2Fs L2NyaS9pbmRleC5odG1sPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L3RkPjwvdHI+PC90YWJs ZT48L3RkPjwvdHI+PC90YWJsZT48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4m bmJzcDs8L286cD48L3A+PC9kaXY+PC9ibG9ja3F1b3RlPjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2 PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PGRpdj48 ZGl2Pjx0YWJsZSBjbGFzcz1Nc29Ob3JtYWxUYWJsZSBib3JkZXI9MCBjZWxsc3BhY2luZz0wIGNl bGxwYWRkaW5nPTAgd2lkdGg9NTQzIHN0eWxlPSd3aWR0aDo0MDcuMjVwdCc+PHRyPjx0ZCBzdHls ZT0ncGFkZGluZzowaW4gMGluIDBpbiAwaW4nPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2Nv bG9yOiMxRjQ5N0QnPjxpbWcgYm9yZGVyPTAgd2lkdGg9MTU0IGhlaWdodD0xMDAgaWQ9Il94MDAw MF9pMTAyNSIgc3JjPSJjaWQ6aW1hZ2UwMDEuanBnQDAxQ0M1MjlCLjY5MjE0QkEwIj48L3NwYW4+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6IlRpbWVzIiwic2VyaWYi O2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHRhYmxlIGNsYXNzPU1zb05vcm1h bFRhYmxlIGJvcmRlcj0wIGNlbGxzcGFjaW5nPTAgY2VsbHBhZGRpbmc9MCB3aWR0aD01NDMgc3R5 bGU9J3dpZHRoOjQwNy4yNXB0Jz48dHI+PHRkIHN0eWxlPSdwYWRkaW5nOjBpbiAwaW4gMGluIDBp bic+PC90ZD48L3RyPjwvdGFibGU+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiJUaW1lcyIsInNlcmlmIjtjb2xvcjpibGFjaztkaXNw bGF5Om5vbmUnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48dGFibGUgY2xhc3M9TXNvTm9y bWFsVGFibGUgYm9yZGVyPTAgY2VsbHNwYWNpbmc9MCBjZWxscGFkZGluZz0wIHdpZHRoPTU0MyBz dHlsZT0nd2lkdGg6NDA3LjI1cHQnPjx0cj48dGQgbm93cmFwIHZhbGlnbj10b3Agc3R5bGU9J3Bh ZGRpbmc6MGluIDBpbiAxMS4yNXB0IC4yNWluJz48cCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4w cHQnPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzY2NjY2Nic+PGJyPjxzdHJvbmc+PHNwYW4gc3R5bGU9J2ZvbnQt ZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz5GcmFuY29pcyBMZSBGYXVjaGV1cjwvc3Bhbj48 L3N0cm9uZz48L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OC41cHQ7Zm9udC1mYW1p bHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzY2NjY2Nic+PGJyPjxzdHJvbmc+PHNwYW4g c3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz5EaXN0aW5ndWlzaGVkIEVu Z2luZWVyPC9zcGFuPjwvc3Ryb25nPjxicj48c3Ryb25nPjxzcGFuIHN0eWxlPSdmb250LWZhbWls eToiQXJpYWwiLCJzYW5zLXNlcmlmIic+Q29ycG9yYXRlIERldmVsb3BtZW50PC9zcGFuPjwvc3Ry b25nPjxicj48YSBocmVmPSJtYWlsdG86ZmxlZmF1Y2hAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFu ayI+PHNwYW4gc3R5bGU9J2NvbG9yOiM2NjY2NjYnPmZsZWZhdWNoQGNpc2NvLmNvbTwvc3Bhbj48 L2E+PGJyPlBob25lOiZuYnNwOzxzdHJvbmc+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlh bCIsInNhbnMtc2VyaWYiJz48YSBocmVmPSJ0ZWw6JTJCMzMlMjA0OSUyMDcyMyUyMDI2MTkiIHRh cmdldD0iX2JsYW5rIj4rMzMgNDkgNzIzIDI2MTk8L2E+PC9zcGFuPjwvc3Ryb25nPjxicj5Nb2Jp bGU6Jm5ic3A7PHN0cm9uZz48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1z ZXJpZiInPjxhIGhyZWY9InRlbDolMkIzMyUyMDYlMjAxOSUyMDk4JTIwNTAlMjA5MCIgdGFyZ2V0 PSJfYmxhbmsiPiszMyA2IDE5IDk4IDUwIDkwPC9hPjwvc3Bhbj48L3N0cm9uZz48YnI+PGJyPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD48L3RkPjx0ZCBub3dyYXAgdmFsaWduPXRvcCBzdHlsZT0ncGFk ZGluZzowaW4gMGluIDcuNXB0IDE1LjBwdCc+PHAgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0 Jz48c3Ryb25nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6IkFyaWFs Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzY2NjY2Nic+Q2lzY28gU3lzdGVtcyBGcmFuY2U8L3NwYW4+ PC9zdHJvbmc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseToiQXJpYWwi LCJzYW5zLXNlcmlmIjtjb2xvcjojNjY2NjY2Jz48YnI+R3JlZW5zaWRlPGJyPjQwMCBBdmUgZGUg Um91bWFuaWxsZTxicj4wNjQxMCBTb3BoaWEgQW50aXBvbGlzPGJyPkZyYW5jZTxicj48YSBocmVm PSJodHRwOi8vd3d3LmNpc2NvLmNvbS8iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0nY29s b3I6IzY2NjY2Nic+Q2lzY28uY29tPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC90 ZD48dGQgd2lkdGg9MjAwIHN0eWxlPSd3aWR0aDoxNTAuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4g MGluJz48cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7PG86cD48L286cD48L3A+PC90ZD48L3RyPjwv dGFibGU+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTMuNXB0O2Zv bnQtZmFtaWx5OiJIZWx2ZXRpY2EiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+PGJyPjxpbWcg Ym9yZGVyPTAgd2lkdGg9MTggaGVpZ2h0PTE5IGlkPSJfeDAwMDBfaTEwMjYiIHNyYz0iY2lkOmlt YWdlMDAyLmdpZkAwMUNDNTI5Qi42OTIxNEJBMCI+PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTMuNXB0O2ZvbnQtZmFtaWx5OiJUaW1lcyIsInNlcmlmIjtjb2xvcjpibGFjayc+PG86cD48 L286cD48L3NwYW4+PC9wPjx0YWJsZSBjbGFzcz1Nc29Ob3JtYWxUYWJsZSBib3JkZXI9MCBjZWxs c3BhY2luZz0wIGNlbGxwYWRkaW5nPTAgd2lkdGg9NDAwIHN0eWxlPSd3aWR0aDozMDAuMHB0Jz48 dHI+PHRkIHN0eWxlPSdwYWRkaW5nOjBpbiAwaW4gMGluIDBpbic+PC90ZD48L3RyPjx0cj48dGQg c3R5bGU9J3BhZGRpbmc6MGluIC4yNWluIDBpbiAuMjVpbic+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzAwOTkwMCc+Jm5ic3A7VGhpbmsgYmVmb3JlIHlvdSBwcmludC48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PC90ZD48L3RyPjx0cj48dGQgc3R5bGU9J3BhZGRpbmc6NS4yNXB0IC4yNWlu IDQuNXB0IC4yNWluJz48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIu MHB0Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNh bnMtc2VyaWYiO2NvbG9yOiM5OTk5OTknPjxicj5UaGlzIGVtYWlsIG1heSBjb250YWluIGNvbmZp ZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBp bnRlbmRlZCByZWNpcGllbnQuIEFueSByZXZpZXcsIHVzZSwgZGlzdHJpYnV0aW9uIG9yIGRpc2Ns b3N1cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIElmIHlvdSBhcmUgbm90IHRo ZSBpbnRlbmRlZCByZWNpcGllbnQgKG9yIGF1dGhvcml6ZWQgdG8gcmVjZWl2ZSBmb3IgdGhlIHJl Y2lwaWVudCksIHBsZWFzZSBjb250YWN0IHRoZSBzZW5kZXIgYnkgcmVwbHkgZW1haWwgYW5kIGRl bGV0ZSBhbGwgY29waWVzIG9mIHRoaXMgbWVzc2FnZS48YnI+PGJyPkNpc2NvIFN5c3RlbXMgRnJh bmNlLCBTb2Npw6l0w6kgw6AgcmVzcG9uc2FiaWl0w6kgbGltaXTDqWUsIFJ1ZSBDYW1pbGxlIERl c21vdWxpbnMg4oCTIEltbSBBdGxhbnRpcyBaYWMgRm9ydW0gU2VpbmUgSWxvdCA3IDkyMTMwIElz c3kgbGVzIE1vdWxpbmVhdXgsIEF1IGNhcGl0YWwgZGUgOTEuNDcwIOKCrCwgMzQ5IDE2NiA1NjEg UkNTIE5hbnRlcnJlLCBEaXJlY3RldXIgZGUgbGEgcHVibGljYXRpb246IEplYW4tTHVjIE1pY2hl bCBHaXZvbmUuPGJyPjxicj5Gb3IgY29ycG9yYXRlIGxlZ2FsIGluZm9ybWF0aW9uIGdvIHRvOjxi cj48YSBocmVmPSJodHRwOi8vd3d3LmNpc2NvLmNvbS93ZWIvYWJvdXQvZG9pbmdfYnVzaW5lc3Mv bGVnYWwvY3JpL2luZGV4Lmh0bWwiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vd3d3LmNpc2NvLmNv bS93ZWIvYWJvdXQvZG9pbmdfYnVzaW5lc3MvbGVnYWwvY3JpL2luZGV4Lmh0bWw8L2E+PG86cD48 L286cD48L3NwYW4+PC9wPjwvdGQ+PC90cj48L3RhYmxlPjwvdGQ+PC90cj48L3RhYmxlPjwvZGl2 PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48L2Rp dj48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIu MHB0Jz48YnI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+Q0ROaSBtYWlsaW5nIGxpc3Q8YnI+PGEgaHJlZj0ibWFpbHRvOkNETmlAaWV0Zi5vcmciPkNE TmlAaWV0Zi5vcmc8L2E+PGJyPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vY2RuaSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vY2RuaTwvYT48bzpwPjwvbzpwPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+PGJyPjxiciBjbGVhcj1hbGw+PGJyPi0tIDxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvYm9keT48 L2h0bWw+ ------_=_NextPart_002_01CC52D7.A0FCB077-- ------_=_NextPart_001_01CC52D7.A0FCB077 Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.jpg Content-Location: image001.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/4QBmRXhpZgAASUkqAAgAAAAEABoBBQABAAAAPgAAABsBBQAB AAAARgAAACgBAwABAAAAAgAAADEBAgAQAAAATgAAAAAAAABgAAAAAQAAAGAAAAABAAAAUGFpbnQu TkVUIHYzLjM1AP/bAEMAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAf/bAEMBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAf/AABEIAGQAmgMBIgACEQEDEQH/xAAf AAABBQEBAQEBAQAAAAAAAAAAAQIDBAUGBwgJCgv/xAC1EAACAQMDAgQDBQUEBAAAAX0BAgMABBEF EiExQQYTUWEHInEUMoGRoQgjQrHBFVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJ SlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4eLj5OXm5+jp6vHy8/T19vf4+fr/xAAfAQADAQEBAQEBAQEB AAAAAAAAAQIDBAUGBwgJCgv/xAC1EQACAQIEBAMEBwUEBAABAncAAQIDEQQFITEGEkFRB2FxEyIy gQgUQpGhscEJIzNS8BVictEKFiQ04SXxFxgZGiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNk ZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfI ycrS09TV1tfY2dri4+Tl5ufo6ery8/T19vf4+fr/2gAMAwEAAhEDEQA/AP7+KKKKACiiigAoor49 /wCCgOv634Y/Yu/aP1vw7qt9omsWnwy1mO01TTLmSzv7Rb57bT7prW6hZJraWSzuriETwuk0QkLx SJIFdenBYaWNxmEwcZqEsXiaGGjOSbjCVerCkptKzai53aTu0rI4syxscty7H5jOEqsMBgsVjZUo tRlUjhaFSvKEZNNRlNU3FNppN3asfX6SRyqWjdJFDyRlkZXUSQyNFKhKkgPFKjxyL95JEZGAZSA+ v54/+Df/AFzWLvwf+0zoF1qd7caJpHiL4YappelzXEkllYajrun+OoNZvLSBmKQT6nFomkJevGAZ xp9rvyYwa/ocr0eIcneQ5xjcpeIWKeElRSrqm6PtI1sPRxEW6bnU5Go1lGS9pJXi2m00ePwfxFHi zhzLOII4R4FZhDEN4R1liHRlhsZiMHNKsqVH2kZTw8pxl7KD5ZJOKaYUUUV4p9KFFFFABTGliR44 mkjWSXf5UbOqvL5Y3P5aEhn2KQz7QdoOTgU+v5DP+CqnjnxjYf8ABS23uLHxNrdlP4BX4NL4MmtN RureTwz52l6Hr8zaM0UimwebWNRvL+Z7fY0087tIX4A+k4X4elxNmFbARxUcG6OBr4z2sqLrKXsZ 0qcafIqlK3POtG8+Z8sVJqMnaL+M454whwVlGHzWeAnmKxGaYTLVQhiFhnH6zCvVlWdR0a1/Z08P Plp8i55yjFzhG8l/XnRRRXzZ9mFFFFABRRRQAUUUUAFVry4FnZ3V2UMgtbae4KA7S4gieUoGIIUs FwDg4znB6V/OT+zV+3z+0t4+/wCCpWtfB3xR43Oo/CXXviR8ZvANv4AOmaTDpOg6L4F0zxvd+Frn SLmCwj1GLV7Sfwxp/wDaWozXUsmsx3GoJeL+9tGsf6LNa/5A2rf9gy//APSWWvczrIcXkGJweGxs 6FSeMwWGx8HQlOUY0sRKpD2c3KEGqkJ0pqXKnFq0oyd9Pl+GOLMv4twWY43LaWKo08uzTGZTUWLh ThOdfCQo1HVpqnVqp0alOvTlDncZp80ZwVk3+C3/AASz/wCCiX7Rf7U/7RvxG+HPxg1Pw7rHha68 A698QPDVppnhzStDm8GXOkeJvC2lQ6Fpl5pltb3WraLNY+IrgTP4km1fWPtNpaTR6skf2mC4/SP/ AIKPf8mNftL/APZNr7/04adX8+H/AAQo/wCTyPFn/ZAfGv8A6m3w1r+g/wD4KPf8mNftL/8AZNr7 /wBOGnV9nxPgMFl3H+VYfAYWjhKH1jI5+xw9ONKmpvE04ykoRSipSUU5NK8pXlK8m2/zbgTNcyzn wmz7GZrjsTmGL+q8T03icXVlWrOnHB1Zxg6k25OMHOShFtqEbQgowjGK/Kf/AIN9/wDkDftVf9hP 4Nf+kvxOr9Sf+Cjn7QHj39mf9lDx18UPhjNYWfje31Pwr4f0TVNSsLbVLfR5PEOvWdhd6ommXsct jfXdtYtciyhvoZ7JbuSGe6truGF7Wb8tv+Dff/kDftVf9hP4Nf8ApL8Tq+2P+Cz/APyYj42/7Hf4 b/8AqT21PiChRxPiksPiKcK1CtmmR06tKpFSp1KcsHl6lCcXpKEldSi01JNppptE8JYvE4HwJljM HWqYbFYbIuJquHxFKThVo1YZjm7hVpTVpQqQlaUJxalCSUotNJnd/wDBLX9pj4n/ALVH7Mk3j34v Xum6t4z8PfEbxH4FuNd07SrLRTrtlpWjeGNbtNS1DTdLhtdJttR/4qOWymGlWNhZSRWcEq2kczzM /wCj1fi//wAEKP8AkzfxZ/2X7xr/AOoT8Nau/wDBZD9qn4zfs2/DT4R6b8GPFM3gjVviN4p8SR63 4m0+1sbjWodK8KadpNxHpenTaha3kVimo3mtwz3l5bRR3+zTo7WG5jtrq8in8PM8ieYcbY7I8shh 8Kq2Y4inh4NOlhqEKdKVedo04ycYQhCbjCELbQikrW+oyTipZR4Y5VxTndTGY94fJ8JWxdSLVfG4 qpVrQwtNudapBVKs6lSmp1KtRN+9UnKTu3+ydfhd/wAFbP28f2g/2VPiB8HfBfwR1zRfDFtrvhy/ 8Z+Jb+/8NaL4jutcFvrjaXa6BKmvWl9BYaT5VlcSXc2lx2WsTNdgW+qWggXf+gv/AAT3+Mvjj9oD 9jz4L/Fn4kXtvqfjfxJp3iyy1/VLazttPTVLjwn4/wDFfg231OWzsooLK3vNRsfD1reX6Wdvb2hv p7hra2t4GjhT8Lf+C+v/ACXb4G/9kl1L/wBTHVK6+C8nof66f2TmmHw2Mjg55nh69GpCNfDTr4SF ak5KNSPLUjGpBypuUFqoyspJW4PEriLErw0fEGRYzG5dLMKWR4zC4ijUlhcbTw2YVsLXjBzozcqV SVGooVVTqNWc6fPKDd/6avht4nuvG3w78A+M722gs73xd4L8LeJ7u0tTIbW1utf0Ox1W4trYzM8p gglu3ihMrvIY1UuzNkn+RX/gq9/yko8Tf90V/wDUS8K1/WJ8Av8AkhPwV/7JL8OP/UO0av5O/wDg q9/yko8Tf90V/wDUS8K16XhpGMOKc0hFWjDKsxjFLZRjjcGkvkkkeJ41znV4DyKpUk5TqZ9ks5yd rynPLswlKTtZXbbeisf2PV/Pl4W/4KQftF6z/wAFR7z9na61Dw6vwUj+MPi34Ox+DI/DulLcJb+H 31nSbXxSPExtT4kOuTajpkWpXFu+pvohgllsItLjPl3af0G1/Hr8P/8AlNbf/wDZ43xL/wDUl8V1 5fA+X4LHUuKJYzC0MS8NkGKq4d1qcansKqjNqrS5k/Z1YuK5asbThryyV3f3PFDN8zyvE8Cwy7HY nBRxvFuBoYxYarKksVh+empYevyte1w81OXtKM+alU054S5Y2/sKoor+bT/gmD+37+0z+0L+2N4g 8G/FDxz/AMJD4G8b+FvGfiK38JzaTpVtp3hG80aSzvdGj8LS2VnbX1jb2Vm0ulS29xd3cWoW8zXm ord6skWoR/O5ZkOMzXAZzmGHqUIUckw9LE4mNWU41KkavtnGNFRpzUpKGHqyfPKCuoxveV19jnvF mXZBmvDeUYyliqmJ4nxtbBYGdCFOVKjUovDRlPEynVhKMHUxeHgvZxqStKcmkoa/0l0UUV4h9QFF FFAH46/Bj/glXP8ACj9unV/2sZfivb6v4VXxd8R/HPhzwXH4fmttdTV/iLZ6/ZSaXrGqtfSWL6do aeKdSkgvbOAXOpSWOn+daWST3Sp+wlxBHdW89tKCYriGWCQKdrGOZGjcBhyCVY4PY81NRXp5nm+Y ZxVw9fMK/t6uGwtHB0ZKFOny0KDnKnG1KME5c1ScpTac5OWrskl4mR8O5Rw5h8Xhcnwv1WhjcdiM yxMHWrVufF4mNOFWadapUlCLhSpwjTg4wjGC5Yptt/kN+wN/wS6uP2L/AI1ePfivqPxVt/HVtqvh XV/Avg7SbPw/LpNxb6Fq3iHRtak1XxHcTXtxE2sRweHdOs0s9Njax33V/ObhgltGv1D/AMFHQT+w 3+0vgE/8W1vzxzwL/TyT9AASfQDNfbFYviTw5oPjDQNa8K+KdI0/X/DfiLTL3Rdd0TVbaK903VdK 1G3ktb6wvrWZWintrm3lkiljdSCrHGDgjqq5/jcbnWDzrNKjxdfDYjBVJuMKVJzpYOpCcacY04wg nJQfvcuspNs4KHCeWZXw1mPDWRUY4DC43CZnRpqdSviFTr5jRq05VZzrVKlWUYynH3VPSEFGNrH8 9P8Awb7g/wBjftUnBwdU+DYB7Ei0+J2Rn1GRn0yPWv2E/bU/ZpP7Wv7PPjH4KweJl8IanrVzoWsa Jr01i2pWNrq/h3VrbVbWHUrKOa3nl0+/WCWxuJLaZbizFyt9FFdm2+xXPe/Av9m74I/s0+H9W8Mf BD4f6Z4C0fXdVbWtZis73WdWvNT1ExmKOW91fxFqer6vcQ2sRaKwspL82OnRSSx2FtbJNKr+3115 9xD9f4oxHEOWqrhn9YweIwnt40nVpzweHw9KE6kFKrSbc6HO4c1SFnytyVzg4U4Q/srgbCcH53LD 46P1PMMJmH1WdeNCtTzHF4zEVIUaso0K6UaeK9mqnJSnzR54qLtb4p/YI/ZJuP2MfgQfhPqHjCDx vrOp+M9d8ca3rFlpsmlaZFqGs2Oi6Smn6ZbT3FzdNaWun6BYlrm6dZri8lupRDbwmKFOA/4KLfsK XP7cPgXwHo2ieObPwJ4q+HfiHU9V0q91bS7nVtF1LTtfs7Sy1nTryKyura6s7gNp+m3tjfxJeKrW k9jJaBb/AO22X6K0V50M9zOnnDz6GItmbr1MQ8R7KlZ1KsZQqfuuT2XJKnOVNwUElF2VnZnsVeFs jrcOLhSpg3LI1hKWDWE9vXUlRoThVpf7Qqnt/aQq04VVUdRyc43k2m0/nT9kv4Awfsu/s8fDX4Ew +IX8Vt4E0/WVvPED2Q05dT1TxJ4n1vxdrEtvY+fdNa2Meq6/eW+nwyXM8y2MNv58rzeYx+Lf+Cin /BNrU/23fFnwy8ZeHvidp/gHUvBmkX/hbWbXWdAutbs7/Q73UhqsF9prWV/Yyw6pYTy3sb2dzutd Riubci801rJ/tv6u0UYTPc0wOazzrDYnkzKrVxNapXdKjNTqYvneIlKlODpfvHUm7KCUW04KNlYz DhbI8zyClwzjMG6mS0KGCw1HCxr4inKnRy/2SwkY4inVjiL0lRpx5nVcpxTVRy5pX5rwX4ZtfBXg 7wn4Nsbie7svCXhrQvDNpdXIQXNza6DpdrpVvcXAiCxieaK0SSURqqCRmCALgV/IP/wVfVh/wUn8 SkggMPgsykggMv8AwinhdcqT1G5WXI43KR1Br+x2vnH4jfsi/s3fFv4m+F/jH8RvhL4c8VfEjwct gmheJL+XVomVNKunvNLXVtKstStdD8SDTbmR5bD/AISTTNW+xnatt5aIir6/CHEVDh7NsTmOMo18 THEYDFYZxoez9p7atUo1ozl7SUI8jnR5ZtO8VPmjGbjyP57xD4OxXF/D+CyfLcRhcFPCZtgMapYr 23svq+FpYjDzpxdKnVm6ip4jmppxUZypqE6lNS9pH6Or8edB/wCCVsmift93f7X4+K1vN4Rm+IGv /FWLwMPD86eIR4r8QJfTz6TJrJv3046FBrOpXOpJepZi9eyjh0Y2SSM2sL+w1FeHl2b5hlSxscDX 9iswwlTBYpezp1PaYer8cV7SEuSVrpVIcs4pu0lc+ozjh7KM+lls81wv1mWUZhRzPAP2tal7HGUH enN+yqQ9rC9nKlV56U3GPNB2QV+Nv7Ev/BKS4/ZG/aN1/wCNFx8WbTxb4etdE8SaB4H8O2nh2403 VEtPEVxCq3HiW/udRu7fzdL0yD7KsOnRyjUbyf7c9xYRW32K7/ZKings3zDLsLmODwlf2WHzWjCh joezpz9tTpupypSnCUqbSq1Y81NxfLUkr3s0s04dyjOcdk2ZZjhfb4zIMTUxeV1fbVqaw9er7Fzk 4UqkIVU5YehNRqxnFTpRaVnJSKKKK8w9sKKKKACuS8eeO/CHww8G+I/iB4916w8MeDvCWl3Gs+IN d1J2S10+wtgNzlY0knubiaRo7aysbSGe+1C9mt7Gxt7i8uIIJOtr8G/+C9PxE1zQvgl8Gvhvp1xc W2kfELx7rmteIfIMiR31v4C0rT207TLx1+R7V9S8UQaqttJkSXmj2dyoLWYK+bnGYf2XlmMx/Iqj w9LmhBtqMqk5xpUlJrXldScea2vLezTPtvDjhB8ecccOcJfWJYWnnGOdPE4mCjKrRwWFw9bHY6dF TTg66weFr+wU04e25OdON0/BvjR/wXr8VL4g1Cw/Z9+DnhdfDdpPJBp/iP4sz61qOpazEkmFvn8M eFdY8Px6LHMgJitH8SapOFKSzSwuXtU+3v8Agmv/AMFIfiD+2p4y8d+BvH3w88G+Fbzwb4QtvFMe teELzW0tr9p9Zs9JaxfR9audVltwBdG4FwusTH5BEYOTIPnv/gj1+xN8BfFH7P8AH8f/AIneAPCX xQ8Y+NfE3iPTtEg8baNpnijRPCWgeF9U/seOGw8PatHf6VHr19q+nXupT61dWX9pw2T6dbaa1lbm 7m1P9qfBfwF+Cvw38U6l41+Hfwq8BeAvE+s6Qug6xq3gvwvpPhaXVtLS7gvkttSg0O1sbO/eO5to Hjurq3lvI1jWFJ1hzGfmciocTYuWCzbGZtTeFxKVeeAjSik8PUhJ0knGmowk7wmkm5ctuao5XR+2 +KuaeCHD1Hibw94a8P8AGRz/ACWcsrw/F1XHVp1IZxgsTRjjp1IVsZKriKN6eKw05TjGj7Xmlh8H Gj7OS/PH/gqN+3j8Xv2JP+FGf8Kq8OfDfxB/ws3/AIWb/b3/AAsHSPE+q/ZP+EM/4V9/Zf8AZH/C OeMPCf2f7R/wleo/b/tn2/zfJsvs/wBl8uf7T9afsMfHnxf+03+yz8Lvjf4803w3pHizxt/wm39q 6f4Rs9UsPD1v/wAI38RfF3hGx/s+01nWNf1KLzdN0Cznu/tOrXfmX0tzLD5Fu8VtD+Of/BwV/wA2 kf8Ade//AHi9fpB/wSO/5R6/s+/91X/9Xd8Sq3wWPxlTjPN8vniKksHQy+lVo4dtezp1HTyxucVa 9261V7/bkeZxNwnw5hPo0eHvF2GyjCUeJc04wxuAzDOIRmsZi8HTxfHEIYerJzcHTjDLcDFJQTth qeujv8yftzf8Fg9O/Zy+JesfBn4OeA9I+IfjPwlPFaeNfEvifUb228J6Jq7RLNceG9P07SGg1HWt SsUlij1W7OqaZa6ZfCbTlhv7mG5Nr5N+xJ/wWB+Nn7Qv7Qfw8+CXxI+GHwttrT4galqmnx+IfBA8 W6DcaN/Z/h7VtcWZ9O17xD4vj1PzW0v7MY1u9O2ifzQ7GLy5Pze/bs+Evxi/ZC/bi8T/AByvvCUG u+GvEPxp1L4zfDjxJ4l0eXxD4C8Sy6t4jl8ZHwvrJJgie70W7uptG1TRZrmx1QWtpHqOnyi0uLDU n/Y39jj/AIK9fCn9pLxp4P8Ahb8X/AMHww+KWs38em+Ddat54tf8C634iu2SCz0vTr28gh1rwjrW sO6Wel2d2mpWN7cItmfEKX13YWFx4eFzfMMRn1ahmGdyymdHMI06GWzwSdDE4dVUlR+sNxUJVqaU YVKim5uanSlrGK/VM78O+D8m8JsszbhLwvw/iHQzPhGrjM140w3E1WnmuSZvUwDlLMFlFOlWqYmj l2LlKriMFg5YeOFWFnhsdRvGtWl+zep6np2i6bqGsavfWml6TpNjd6nqmp6hcRWlhp2nWEEl1e31 7dzvHBa2lpbRS3FzcTOkUMMbySOqKSP56/2if+C7WnaB4m1Lw3+zX8MtK8ZaTpdzNar8RPiJd6tZ 6VrkkTGNp9E8H6S+l6sulMymS0v9V16wvruJlMuiWBAMn2N/wWZ+I2veAP2JtfsNBuZ7J/iT478J /DnVrq2kaKZdB1CDWvEmq2wdeRBqlv4W/si9jyFnsdQurd8pMyn84P8Agi/+xj8FvjN4b+Ivx1+L /hPQviPL4a8ZL4A8JeD/ABTZ22r+GNOuLXQdK17Wde1bw9dtNYa7PeQ+INPsNLh1mxuNOsvseo3E UFzfPDPpvsZ5mWa184wvD+T1qeEq1KDxGJxc4qThC05ckOaM+VKELtxhzznOEVKEVNv858K+CeAM r8Oc88XfEjLsXxBgMFmscmyXh7C1qlKGIxN8NTeIxDpV8N7SVTEYl04wr144bD4fDYmvOhi6tXDU 4fVX/BPX/gqr8Wf2svjjY/Bj4j/Db4d6Mb/wx4j19fEvgmXxLpohk0G3iuBbNo2u6v4l85LoS7DI NWiaEruCy52j9jPix8VfAvwR+Hnin4p/ErXIfD3gvwfpx1HWdTljlnkCvNFaWdlZWkCvcX2panf3 Frp2m2Nujz3l9dW9vGu6QEc/4d/Z2+Avg7xdpvj3wb8G/hp4O8ZaRYX2l2PiTwh4L0Dwvqsem6lC ILywnutBsdPa9s5YxhLa9+0QwNmS3SKRi5/DL/gvp8S/EVnYfAD4R2N7c2nhnW28Y+OvEVpFKyQa xqWjPoujeGluURl8yPSI9Q1+ZYpVeN59QgmAEtrGw662JzHh7IMZicwxUczxdCf7iq4OCl7aVKjQ hUSUW1TqylOfvOUoJpTu0l83l+S8H+MXi1w5knB2Q1uCMgzShH+1sCsQsTOl/ZtLH5hmmIwVSc60 I1MXgaFLD4VOlGlSxTU54aVOM5VPN/ip/wAF7/iVca5eRfBL4KeBdI8NwzvHp998UrnxB4k1vUbd XXy7u70zwnrvhSx0eaaMNu0+HVtbS3dlxqVwEO/6I/ZS/wCC3nhv4leNNG+H/wC0V4E0j4ZTeIr6 10vSPiH4W1O+uvB1vqd7MYLW38TaTrBn1Lw9p0szQQf29HrGr2dtLN52qQaXpsNxqMPrP/BMj9gn 9nXRv2Zvh58VvHPw48FfFT4hfFrw9D4t1LWPHfh/R/GFjoOl6pJO2keHvDela3b6jpej/Y9LaNNY vre2XWNQ1G41CC9vP7PistNsfzZ/4LNfse/CP9n/AMSfDD4pfB7QNM8DaZ8T5/E2jeJvA2iRx2Ph 201vw7DpF5Z654b0eNhBpFvqNnqc1pqumaZDa6NZz2Gn3FpaQ3GpXjS/N1qvF+X5fS4grZlRxFJq hXr5fKnBRjh68oKEbRpRin+8gpqk4zhdtVJ8rv8AtmXZf9HXi/i/G+EGW8E5nlOPp1M0yrK+LqWM xLxFbNspo4ieKq3q42tVlB/U8TPDSx9KvhsS4KE8Jhva01H+r6ivhL/gmd8S/EXxZ/Yg+A/izxZe 3OpeIYND13wlf6leStcXWoQ+BfF3iDwdpN5dXMjNNd3k+iaJpr311cE3FzfG5mmeV3M0n3bX6Ng8 THGYTC4uCcYYrD0cRCMvijGtTjUUX5pSs/NH8Y8RZLiOHM/zzh7FVIVcTkWb5lk+Iq001Tq1stxl bB1KtNO7VOpOi5wTd+WSvqFFFFdB44UUUUAFfmP/AMFWP2TvEf7Uv7OSf8K+sH1X4mfCnXH8b+Ft FhGbvxNpj2E9h4p8LWALBTqV/Yta6rpUQV5r/VNCstIh2NqRkT9OKwPEviG08M6VPql2rSCPCQwI QJJ5nOEjTPc9Seygk8AkceYYShj8FicHib+wr0nCo07Sjs4zi3dKUJqM43TXNFXTWj+j4R4hzXhT ibJeIsk5XmmU4+lisLTqRc6Vd606uFrRjKEnQxVCdXDV1GcJ+xqz5KkJWmv43f2LP+Ckfxf/AGEr XxP8LdX+H8PjzwPJr97qN74B8TajqXgzxL4R8VgW9hq66bq0ulaxJpCXQskj1jQtS8O3ipqMC3dt /Z91JqY1H93f2BP+ClGu/twfFbx74Qk+E2k/DLw54O8BW3iWFU8W3njLW77VJ9fsNKKy6mdC8LWM Onrb3Mri2TRZLkzCNjfbFaOTpfjP8FfhF+0d4iOvfEL4B/D3xZraLFGusf2BqEHiue0tlMVtb6p4 k8O6hpOtanbWyMyW9teXMlpbhsQwocGvb/2UfgR8I/gzc+JF+H/wY8HfDTVb2xtLW81bRdH1KDXN T02OfzRY3+ra7f6rqtxaLcrHcfZxdpbtPGkskTyxxunx+TZdnmAxeGwsc4hXyfD1JctGVDlrVKXL Jxp80qM5U4qUk1BYlwSVkkrJf0Z4mcZ+FfFuQZ3ns/DrE5V4j5thcM62Z0c19tl2Fxbr4WNfFujS zHD0MVVqUY1KbxE8kWInKfPUqOd6j/I//g4K/wCbSP8Auvf/ALxev0g/4JHf8o9f2ff+6r/+ru+J Ve6/tG+FvA3ivUPC0Pj34QfB/wCKtpptnqkuiH4o/DzRfHU+g3F/PZpq40Z9aWZNMi1OOw0j7ctp FE92+n2xuZJhb2yw+zfCrRPDHhv4c+GtI8FeEPC3gPw/a2NzLY+FPBeg6d4a8L6TdXt9d3+qf2Vo Wkw21hYRX2sXN9qU6Qxh5ru8uLi4kmuZpp5PWwmVSpcT5lm/t4ShicHDDqhySU4OMMBHnc37jT+r N2Wvvx7M+Az/AI+oY/wL4K8O1lleliMk4jxWbzzZ4mjPDYiFavxTWVCGGivb06kVnkIuU24t4ao1 pOB+QXxM/wCCzf7OWheLfir8Hfix8BfH+vQeDPGnjTwHqFpaW3gXxl4a8SyeEfEOo6JDdXdh4l1T QEhtNSn01Lt7aay1BrASBVN88IaT8L/Bfh6D9rD9u7RG/Zm+FEnw28MeJvif4Z8TaL4M0qSOWw+H fhTQb3RJvEXie/ntYo7DRtMtWs73xJcWNkhstMub+Hw3oKXrjS4Lr+j7x7+xJ8FfiV4q13xd4q/Z b+HGq6/q2ralqes6vp+m+J/DTaxqd/dPcahqt7B4e8XaPBd3uo3LSXlzdzQyXFxczT3MkjzTzSSf Qn7PHhj4S/BNp/B3gn4NeCvha2qXIivr7whoq6fd6hcBsxQ69eXj3ut34iOBbyXuq3UcAISGGGPF eHismzbN8Xh45vj8J9SoYn2tKVHCOnipxUvdo+1dGmoKUW4tqpKClabhUlGNv1LIfErw+8O+H83x Hh7wpxA+J80yP+z8dRzDiGGK4fw9epSp+2zBYCOZYqeJlTrwVSmpYSliXS58LTxGGpV63NN+3z+z ZeftV/sw+PvhZoRtk8aL/Z/izwDJeSxW9q3i/wAM3BvLKwnuZiIbSPXrB9S8ONezOkNiNY+2TN5U Dg/ywfso/tkfHv8A4JwfETx14P1bwDNeadqd3b23xB+EfjpdT8M39rrWlxTJp2saVe/ZrifQtV8i 4Ecl6dM1TTtb0d4A9rceVpOoWX9q+r6raaLp9zqV6xW3tYy77Rl3P8KIO7ueAK+Avjn4M+Fv7R1z awfEj4F+APHqabG1to9/4i0a8uvFdjZtL50tvZeJNFvtJ1zT7O4lAmmsLK+jtmkG6UTMAw9PiHJp 4nF4bNMvxrwOa4eHs6cuRzp1aacrKaUZ8rXtJxbcKkakZezlBpJr4jwf8S8NkvD2d8CcYcLw4r4B zjFfXcVh1iI4bGYDGOOH554SVSrRjWjOWFwtaFOnicDWwmJp/W6OLhOcoVPm39jP/grFrf7Yf7Q/ h/4PWvwR0r4a6HdeF/Fev6rqlx48u/G+q3E2h2cc9nb6eY/Cng6zsInllH2lrm21N5I1KxeQzB16 L/gsL+yH4k/aL+Cnh/4i/DrTbzXPiJ8D59b1OPw1pts11qPinwV4hTTB4nsdMtYVNxe61o8uj6br mmWcW+W6s7fW7GytrrU76xgf2r9nT9nv4PfBjx5Y6n8NfgB8P/h/rd5Bc6dP4nt9I8RXniG2026A a9trDWPEuu6veWSXYjSOdLaaJZoVMMgaLKV+gGtazY6Dp8+p6hIUt4FyQgDSyufuxRISN8j4wq5A 7kgAkdOFwGKzDJcXgc9xccXUxE5qdelBUo0opUp0eSKpUI81GpBVf4ajKWkuZN38TOuL8i4R8TeH +KvCnh+vw/gcooYV4fKcfi6uPq4+rUnjaGZQxVWWPzOsqWZYPFSwUksZOpSp+/RdOUYOP8g37GP/ AAVu+J/7J3w7g+EfiT4eaf8AGHwLoU92/hC3vPFV34N8SeF4r65nvLzR01v+wfFVtf6Gl9PNdWNh caLFd6fJcXNvFqLWH2OzsvF/2g/2jP2hP+Cnnx38B+HdM8HRi7SSfw58Mvhl4Va9v7DQIdXuLafX Nb1fVrpFae4mjs7S68TeJrq30vS7HSNHtpXtNPtLGV3/AKNPi38Af2bvjh4lvPEnib9l/wCG2ta7 eXD3V9rg03VdK8Q6xOd6/btd1DwVqHhq51S6kjYCR9Tm1CQbY1NxIIISvo/wQ8P/AAu/Z9eTTfh3 8Dfh78PLW/EVrrV94S0F9O8S31okokjTVNc1Ge/1vWYrZ8ywWup6jLHG+5ojEzFj8x/YGb16VHK8 bnyqZNSnBRhToTVadOlKLp025Uk0kkuRTxFanRai4wkoRR+6f8Rd8Osqx2P474b8J6mE8S8ww+Jq VMRi81w08tw+NxtKUMTiqapY+dN1KrnUeJq4TKMtxeYRqVqdXE0Xiasz6E/Zj+B+mfs3fAT4Y/BL Sr0anD4C8OrY32qLF5Eeq6/qd9ea94n1WCDAa3ttS8Sarqt9bW8heWC3uIoppZpUeV/d6r2l1BfW 0F3bOJILiJJYnHdHAIz6EZwQeQQQelWK/SaNKnQo0qNGKjSo04UqUVqo06cVCEU+yikl5I/ijMsf jM0zHH5nmNWWIzDMcbisfjq80lOtjMXXqYjFVZqKSUqlepOckkknJpJLQKKKK0OIKKKKACvLfibY y39vpcQBMKzTyOv8PmBEWMkdztaTHpz68epVn6jYRX8HlSDlWDocZ2sARnHcEEg+xz2qKkOeEo97 fg0/xsdWDxH1XE0q/wDz7k35q8XG681e5yfw+0mz07RFaKFBczTym5kKgvuRsRrnkhRHtYDgZZiB zk93tUEsFAYjBOBkj0J64rm7TTLqxLfZZDGHxuUBWRsdCUYFc9ecA4PWta1S7WR2uZS6lMKuFVQd wJOFAGcdzzjjpSprlhGPK1ZW0tb1363u9N76DxU/bVqtd1VN1JOVm25atWjta0bpLW1lsrWPMfif pf8AaE2jvt3eXFer0zjL2xrtfBkH2XwzpVuRjyo51x6f6XcEfoavatpo1BoCRnyhIOf9sp/8TV6w tvstnFb9PLDj/vqR29/71TGnatOpb4o2v6KHl5dzWri/aZdh8Jf+DVlO19rurrbz5/8Ah9TiPEXi y+t55bLSYV3xEpLdSqXAfAysUZwMochmcMCchV4DHh9H8Hapq+txaxqCuq/akuri5mURvKYyMLEh AJztCghdiqMAkgKfVH0TbeNdRqpfzjOpYAjeW3nIPX5iensQRWzEb3egkESxj72xGBx+LsB+A/Lq JdJzmpVG2oyvGKS5Vqrf8HyT13N6ePWFoOnhIU4TqUuWrWbvVd0nJeeuqV+VNfDozjviNay3mhxQ Jko95F5qjugV2XPsHVfxNZ/w30SysbO8uDDGb17gIzsql0hCKUC55VWYvnGMle+K9EvbSO9t3gkG VYAjjOGBBVh7gj8Rkd6w7bSLiykL2sjRsRglcbWH+0jAq3qNynB6U3T/AHyqW5tLenTTTz7rdmVP F/8ACfPBc/s71HNvZSu4u0mt07Wfay3V0dKUQsGKKWX7rFQWH0JGR+Bryz4mWc1+mmQDcYFM8jKM 7WkGwDcOh2jBHHGT616HAl8JlaeUtGAcqFRQSeATtAPv6UupafFqEIRx80bbkb0OMEe4I7eoB6ir qR9pTlG1ua29tbNPz3tbUwwlb6piqNa6lyNu8bvl5ouN9baq938+pzngbR7DTNEtmt4YxcThnuZs AyNJuIKluoCfdC5AAHTNcz8SdCsrwafcpDGt4XlSRkUBpIgqkGTHXaxIDEZOcZOOO3tNNu7IMLaQ xq3JTCsmfUKwKgnuQATgZNRT6NNeSiS6dpGOAWbnao7Ko4A5JwABk+9RKHNSVPk2UV0srW1Xn8ur vszppYqVPHvG+3u3Kc73blJTTXI+nKrrS70irJNe7X8CwS23hy0gl3fu5LhU3ZyIxM4QDPYAYHtX YVBbQR20McEY2pGoUD6D9T6nueanrWK5Yxj/ACxS+5WOCvV9tWq1bW9pUlO3bmbf66hRRRVGQUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAf/2Q== ------_=_NextPart_001_01CC52D7.A0FCB077 Content-Type: image/gif; name="image002.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image002.gif Content-Location: image002.gif R0lGODlhEgATAJEAAAAAAP///wCZAP///yH5BAEAAAMALAAAAAASABMAAAIojI+pGyK8nINqUiTf bVnfvHEg1UmhdZRqaawu6XZVjKb0/CYxo8JOAQA7 ------_=_NextPart_001_01CC52D7.A0FCB077-- From kleung@cisco.com Thu Aug 4 11:55:05 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 233D121F8B90 for ; Thu, 4 Aug 2011 11:55:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.348 X-Spam-Level: X-Spam-Status: No, score=-2.348 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B15S85Bsjiyv for ; Thu, 4 Aug 2011 11:55:03 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 8499121F8B5A for ; Thu, 4 Aug 2011 11:55:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=kleung@cisco.com; l=9797; q=dns/txt; s=iport; t=1312484119; x=1313693719; h=mime-version:subject:date:message-id:from:to:cc; bh=UMG75qFOrnHGUL2zWgEzp4GntT4E8TX/7v3CTM7jjAQ=; b=INtbaXDMcb+yXBqKXB+7sBD82z694+qvCPTBTBcwUtrIYPg/4NAM7Szg tXyRvWhSEfvQojtXvfkrsoKjIWByodCyalZDj6RODBFpsCt9fMyxv3iAJ VpfO2OZA3evqg8dZAzVGrLv71zQaybzgCcLmMl32kWK775abUwIJnJo3u s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAILqOk6rRDoG/2dsb2JhbABDgk2lHHeBQgEBAxIBCREDPgIJEgEqBhgHVwEEGxqqLgGebIVjXwSHWpAxi3Q X-IronPort-AV: E=Sophos;i="4.67,318,1309737600"; d="scan'208,217";a="9755371" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-5.cisco.com with ESMTP; 04 Aug 2011 18:55:18 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p74ItIUr028022; Thu, 4 Aug 2011 18:55:18 GMT Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 4 Aug 2011 11:55:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC52D8.0D5189D7" Date: Thu, 4 Aug 2011 11:55:13 -0700 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC520F8762E5@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updates to the CDNI Requirements draft Thread-Index: AcxS2Aq22OiAoCMNSbSR7x3wrDSBGA== From: "Kent Leung (kleung)" To: X-OriginalArrivalTime: 04 Aug 2011 18:55:18.0035 (UTC) FILETIME=[0D884630:01CC52D8] Subject: [CDNi] Updates to the CDNI Requirements draft X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 18:55:05 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC52D8.0D5189D7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi folks. Based on the last working group session, mailing list discussions, and some offline discussions, we plan to make the following changes: =20 1. Multiple authors to two editors. 2. Change "Protocol" to "Interface". 3. Remove "Within/Beyond CDN Initial Scope" titles. 4. Use "High Priority", "Medium Priority", and "Low Priority" to designate the priority of the requirements (instead of "Must", "Should", "May"). 5. Remove duplicate requirements. 6. Description should cover inter-dependancies of requirements (e.g. loop prevention if cascaded CDNs supported). 7. Requirements numbering based on sections (e.g. Control, Request Routing, etc.) 8. Add requirement for no impact to CSP. 9. Remove "Recursive/Iterative" request routing definitions (Framework draft is referred for terminologies). 10. Unresolved requirements are marked as "OPEN ISSUE" for working group to handle. 11. Add HTTP ABR requirements, implications to CDNI interfaces. 12. Add requirements on the CDNI Metadata interface covering the ability to a) exchange a set of well-accepted metadata elements with specified semantics (eg start of time window, end of time window,...), AND b) allow exchange of opaque metadata element, whose semantic is not defined in CDNI but left up to private CDN agreement. 13. Add example of content purge (i.e. expiration) to CDNI Metadata interface requirement for availability window of content (i.e. activation and deactivation). =20 We plan to publish with changes after the chairs re-confirm acceptance of requirements draft by WG. Let us know if we missed anything. Thanks. =20 Kent ------_=_NextPart_001_01CC52D8.0D5189D7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = folks.  Based on the last working group session, mailing list = discussions, and some offline discussions, we plan to make the following = changes:

 

1.       = Multiple authors to two = editors.

2.       = Change “Protocol” to = “Interface”.

3.       = Remove “Within/Beyond CDN Initial = Scope” titles.

4.       Use = “High Priority”, “Medium Priority”, and = “Low Priority” to designate the priority of the requirements = (instead of “Must”, “Should”, = “May”).

5.       = Remove duplicate requirements.

6.       = Description should cover inter-dependancies of = requirements (e.g. loop prevention if cascaded CDNs = supported).

7.       = Requirements numbering based on sections (e.g. = Control, Request Routing, etc.)

8.       Add = requirement for no impact to CSP.

9.       = Remove “Recursive/Iterative” request = routing definitions (Framework draft is referred for = terminologies).

10.   = Unresolved requirements are marked as = “OPEN ISSUE” for working group to handle.

11.   = Add HTTP ABR requirements, implications to CDNI = interfaces.

12.   = Add requirements on the CDNI Metadata interface = covering the ability to a) exchange a set of well-accepted metadata = elements with specified semantics (eg start of time window, end of time = window,...), AND b) allow exchange of opaque metadata element, whose = semantic is not defined in CDNI but left up to private CDN = agreement.

13.   = Add example of content purge (i.e. expiration) = to CDNI Metadata interface requirement for availability window of = content (i.e. activation and deactivation).

 

We plan to = publish with changes after the chairs re-confirm acceptance of = requirements draft by WG.  Let us know if we missed anything.  = Thanks.

 

Kent

------_=_NextPart_001_01CC52D8.0D5189D7-- From kevin.ma@azukisystems.com Thu Aug 4 12:00:24 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 118475E804F for ; Thu, 4 Aug 2011 12:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.305 X-Spam-Level: X-Spam-Status: No, score=-2.305 tagged_above=-999 required=5 tests=[AWL=0.294, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FcrPUkvV3u0M for ; Thu, 4 Aug 2011 12:00:23 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id C06B75E8037 for ; Thu, 4 Aug 2011 12:00:21 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 910988BE3F1; Thu, 4 Aug 2011 15:00:36 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB025.mail.lan (unknown [10.110.2.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mxout.myoutlookonline.com (Postfix) with ESMTPS id AD7C28BE4C0; Thu, 4 Aug 2011 15:00:35 -0400 (EDT) Received: from MAILR002.mail.lan ([10.110.18.16]) by HUB025.mail.lan ([10.110.17.25]) with mapi; Thu, 4 Aug 2011 15:00:21 -0400 From: Kevin J Ma To: "Peterson, Larry" , Johan Rydberg Date: Thu, 4 Aug 2011 15:00:20 -0400 Thread-Topic: [CDNi] upstream cdn enforce content policies Thread-Index: AcxSu3L5yMQFJC6mRW2wxsTEYzrAJwABssUQ Message-ID: <291CC3F9E50E7641901A54E85D0977C6518C23922F@MAILR002.mail.lan> References: <4E3A6BEE.4080301@edgeware.tv> <8AF4C086-7E25-4931-9BF7-7DC7F44A9D2C@niven-jenkins.co.uk> <4E3A7178.6080400@edgeware.tv> <1CA25301D2219F40B3AA37201F0EACD11360E6C4@PACDCEXMB05.cable.comcast.com> <4E3AB142.4030103@edgeware.tv> <70AE7D15-69E5-40FE-A4EE-F6BF5E01C6A9@verivue.com> In-Reply-To: <70AE7D15-69E5-40FE-A4EE-F6BF5E01C6A9@verivue.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] upstream cdn enforce content policies X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 19:00:24 -0000 > The question is: does interconnection imply that uCDN further delegates t= hat > responsibility for enforcing access control policy to the dCDN, or does t= he uCDN > retain that locus of control for itself.=20 I think the issue is more the threat that a CSP may have an agreement with the uCDN, which it has paid for, which may not be enforceable through dCDNs= . It is not clear that a uCDN can always enforce those policies. It is not t= hat hard to figure out where the content is really coming from (i.e., the dCDN)= . Will CSPs, who tend to be risk averse, just disallow delegation? Sticking with the minimalist approach, I still think there is value in a standardized method of exchanging opaque metadata. If some CDNs agree=20 amongst themselves (outside of CDNI) to enforce policies, they will most likely need to exchange metadata? Having a well defined protocol to do so seems like an important first step? > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of > Peterson, Larry > Sent: Thursday, August 04, 2011 11:31 AM > To: Johan Rydberg > Cc: cdni@ietf.org > Subject: Re: [CDNi] upstream cdn enforce content policies >=20 > Picking up on Johan's minimized scope thread... >=20 > I too have been puzzled by the metadata interface. If you read the > language > carefully, you'll see there's a caveat that this interface might exist in > various > forms, presumably as a combination of other interfaces and mechanisms, > for example: > o the uCDN doesn't route the request to the dCDN unless policy permits= ; > o the uCDN sets HTTP caching directives consistent with policy and the > dCDN obeys those directives; and > o the uCDN invokes purge on dCDN should the policy change. >=20 > But that generous interpretation aside, the high level issue seems to be > how > access control policy is enforced. In a single CDN it's natural for this > policy to > be enforced by the CDN, and there's likely a metadata-like interface by > which > the CSP expresses this policy to that CDN. >=20 > The question is: does interconnection imply that uCDN further delegates > that > responsibility for enforcing access control policy to the dCDN, or does > the uCDN > retain that locus of control for itself. The later design, which > essentially treats > the dCDN as it would any other cache (at least with respect to metadata), > seems > the simplest to me. >=20 > Larry >=20 > On Aug 4, 2011, at 10:48 AM, Johan Rydberg wrote: >=20 > > Richard, > > > > I just got a bit scared when I saw discussions about features that "may > > be good to have" > > or "it would be nice to support". > > > > I guess all I wanted to say was that everyone would benefit from a > > minimized scoop. > > > > On 8/4/11 4:34 PM, Woundy, Richard wrote: > >> A couple of observations, as an individual and not a working group > chair. > >> > >> > >>> Instead of constructing a complex metadata exchange protocol > >>> > >> How about we construct a *simple* metadata exchange protocol? :) > >> > >> I believe we are anticipating this protocol to be XML/JSON over HTTP. > >> > >> > >>> I have a feeling that if the interconnect protocols are not limited i= n > scope, this CDNI effort will either (1) fail or (2) be in some "design > phase" for ever. > >>> > >> CDNI was approved as a WG in late June. Now it is early August and > we're already in danger of failing? Hmmm. > >> > >> It feels to me like we are debating theoretical scenarios. Johan, if > you feel strongly about eliminating this interface, maybe you could write > up your proposal as an internet-draft that we can discuss and debate? We > also need to ensure that your proposal meets the use cases identified by > this group. > >> > >> -- Rich > >> > >> -----Original Message----- > >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf O= f > Johan Rydberg > >> Sent: Thursday, August 04, 2011 6:16 AM > >> To: Ben Niven-Jenkins > >> Cc: cdni@ietf.org > >> Subject: Re: [CDNi] upstream cdn enforce content policies > >> > >> On 8/4/11 12:10 PM, Ben Niven-Jenkins wrote: > >> > >>> Johan, > >>> > >>> On 4 Aug 2011, at 10:52, Johan Rydberg wrote: > >>> > >>> > >>> > >>>> After following the discussions for a while, I have a question: > >>>> > >>>> Instead of constructing a complex metadata exchange protocol, > >>>> why not force the upstream CDN to enforce any prolicy rules that > >>>> the CSP has put on the content? > >>>> > >>>> > >>> That would not provide sufficient coverage to ensure that the policy > is enforced as clients may attempt to request content directly from a > downstream CDN, bypassing the upstream CDN. > >>> > >>> > >> There must be ways to make sure that the client first passes through > the > >> upstream > >> CDN. > >> > >> I have a feeling that if the interconnect protocols are not limited in > >> scope, this > >> CDNI effort will either (1) fail or (2) be in some "design phase" for > ever. > >> > >> > >>> > >>> > >>>> In the case of DNS-based routing, the CDN can answer the DNS > >>>> lookup with the address of one of its own CDNI request routers > >>>> that will enforce any policies before redirecting (HTTP 302) to > >>>> a downstream CDN. > >>>> > >>>> The upside to this is that redirects between CDNs will always be > >>>> HTTP 302, regardless if the initial mechanism was DNS-based. > >>>> Also, the complex metadata protocol can be elimited, minimizing > >>>> the scope of the CDNI work. > >>>> > >>>> > >>> Even if one could avoid the need for a downstream CDN to apply some > policies, this wouldn't eliminate the need to exchange CDNI metadata as > other CDNI metadata such as rate limiting, whether an encrypted channel i= s > required, where to obtain the content from etc. is still required. > >>> > >>> > >> It sounds like most of those could be folded into the request routing > >> protocol. > >> Rate limiting and encryption might not be attributes of the content, > but > >> rather > >> of the client. (Some customers pay more, and get a higher bitrate for > >> example) > >> > >> > >> > >> > >> > >> _______________________________________________ > >> CDNi mailing list > >> CDNi@ietf.org > >> https://www.ietf.org/mailman/listinfo/cdni > >> > > > > _______________________________________________ > > CDNi mailing list > > CDNi@ietf.org > > https://www.ietf.org/mailman/listinfo/cdni >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From lpeterson@verivue.com Thu Aug 4 12:14:33 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF0E721F889A for ; Thu, 4 Aug 2011 12:14:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3mAuZ0BrXCo for ; Thu, 4 Aug 2011 12:14:33 -0700 (PDT) Received: from exprod8og102.obsmtp.com (exprod8og102.obsmtp.com [64.18.3.84]) by ietfa.amsl.com (Postfix) with ESMTP id 5D5C921F8849 for ; Thu, 4 Aug 2011 12:14:32 -0700 (PDT) Received: from vvexch.verivue.com ([63.64.170.198]) (using TLSv1) by exprod8ob102.postini.com ([64.18.7.12]) with SMTP ID DSNKTjrvozyLVNawsdA1989bU4fUgnS8mLcg@postini.com; Thu, 04 Aug 2011 12:14:48 PDT Received: from vvexch.verivue.com ([10.10.6.20]) by vvexch.verivue.com ([10.10.6.20]) with mapi; Thu, 4 Aug 2011 15:14:42 -0400 From: "Peterson, Larry" To: Kevin J Ma Date: Thu, 4 Aug 2011 15:14:42 -0400 Thread-Topic: [CDNi] upstream cdn enforce content policies Thread-Index: AcxS2sNHSlb6wXqPSue433kxUl0UUw== Message-ID: References: <4E3A6BEE.4080301@edgeware.tv> <8AF4C086-7E25-4931-9BF7-7DC7F44A9D2C@niven-jenkins.co.uk> <4E3A7178.6080400@edgeware.tv> <1CA25301D2219F40B3AA37201F0EACD11360E6C4@PACDCEXMB05.cable.comcast.com> <4E3AB142.4030103@edgeware.tv> <70AE7D15-69E5-40FE-A4EE-F6BF5E01C6A9@verivue.com> <291CC3F9E50E7641901A54E85D0977C6518C23922F@MAILR002.mail.lan> In-Reply-To: <291CC3F9E50E7641901A54E85D0977C6518C23922F@MAILR002.mail.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] upstream cdn enforce content policies X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 19:14:33 -0000 Good questions... In my mind, the metadata interface is used to delegate responsibility from uCDN to dCDN. The CSP still has to trust that the dCDN behaves according to the metadata it's passed. Alternatively, the CSP trust= s that the uCDN -- with which it has a contractual agreement -- to "stay in the loop" and keep a tighter leash on what the dCDN does (e.g., make a decision on each request it routes, issues purge commands when necessary, and adds cache directives as necessary). Yes, we have to trust the dCDN to observe cache directives, so you could argue both strategies involve trusti= ng the dCDN, but you could also argue that the latter approach narrows the window of vulnerability if trust is violated. As to the position that "we just as well define the interface in case some = pair of CDNs want to use it"... sure, but every bit of mechanism comes at some c= ost in complexity. Larry On Aug 4, 2011, at 3:00 PM, Kevin J Ma wrote: >> The question is: does interconnection imply that uCDN further delegates = that >> responsibility for enforcing access control policy to the dCDN, or does = the uCDN >> retain that locus of control for itself.=20 >=20 > I think the issue is more the threat that a CSP may have an agreement wit= h > the uCDN, which it has paid for, which may not be enforceable through dCD= Ns. > It is not clear that a uCDN can always enforce those policies. It is not= that > hard to figure out where the content is really coming from (i.e., the dCD= N). > Will CSPs, who tend to be risk averse, just disallow delegation? >=20 > Sticking with the minimalist approach, I still think there is value in a > standardized method of exchanging opaque metadata. If some CDNs agree=20 > amongst themselves (outside of CDNI) to enforce policies, they will most > likely need to exchange metadata? Having a well defined protocol to do s= o > seems like an important first step? >=20 >=20 >> -----Original Message----- >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of >> Peterson, Larry >> Sent: Thursday, August 04, 2011 11:31 AM >> To: Johan Rydberg >> Cc: cdni@ietf.org >> Subject: Re: [CDNi] upstream cdn enforce content policies >>=20 >> Picking up on Johan's minimized scope thread... >>=20 >> I too have been puzzled by the metadata interface. If you read the >> language >> carefully, you'll see there's a caveat that this interface might exist i= n >> various >> forms, presumably as a combination of other interfaces and mechanisms, >> for example: >> o the uCDN doesn't route the request to the dCDN unless policy permits= ; >> o the uCDN sets HTTP caching directives consistent with policy and the >> dCDN obeys those directives; and >> o the uCDN invokes purge on dCDN should the policy change. >>=20 >> But that generous interpretation aside, the high level issue seems to be >> how >> access control policy is enforced. In a single CDN it's natural for this >> policy to >> be enforced by the CDN, and there's likely a metadata-like interface by >> which >> the CSP expresses this policy to that CDN. >>=20 >> The question is: does interconnection imply that uCDN further delegates >> that >> responsibility for enforcing access control policy to the dCDN, or does >> the uCDN >> retain that locus of control for itself. The later design, which >> essentially treats >> the dCDN as it would any other cache (at least with respect to metadata)= , >> seems >> the simplest to me. >>=20 >> Larry >>=20 >> On Aug 4, 2011, at 10:48 AM, Johan Rydberg wrote: >>=20 >>> Richard, >>>=20 >>> I just got a bit scared when I saw discussions about features that "may >>> be good to have" >>> or "it would be nice to support". >>>=20 >>> I guess all I wanted to say was that everyone would benefit from a >>> minimized scoop. >>>=20 >>> On 8/4/11 4:34 PM, Woundy, Richard wrote: >>>> A couple of observations, as an individual and not a working group >> chair. >>>>=20 >>>>=20 >>>>> Instead of constructing a complex metadata exchange protocol >>>>>=20 >>>> How about we construct a *simple* metadata exchange protocol? :) >>>>=20 >>>> I believe we are anticipating this protocol to be XML/JSON over HTTP. >>>>=20 >>>>=20 >>>>> I have a feeling that if the interconnect protocols are not limited i= n >> scope, this CDNI effort will either (1) fail or (2) be in some "design >> phase" for ever. >>>>>=20 >>>> CDNI was approved as a WG in late June. Now it is early August and >> we're already in danger of failing? Hmmm. >>>>=20 >>>> It feels to me like we are debating theoretical scenarios. Johan, if >> you feel strongly about eliminating this interface, maybe you could writ= e >> up your proposal as an internet-draft that we can discuss and debate? We >> also need to ensure that your proposal meets the use cases identified by >> this group. >>>>=20 >>>> -- Rich >>>>=20 >>>> -----Original Message----- >>>> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf O= f >> Johan Rydberg >>>> Sent: Thursday, August 04, 2011 6:16 AM >>>> To: Ben Niven-Jenkins >>>> Cc: cdni@ietf.org >>>> Subject: Re: [CDNi] upstream cdn enforce content policies >>>>=20 >>>> On 8/4/11 12:10 PM, Ben Niven-Jenkins wrote: >>>>=20 >>>>> Johan, >>>>>=20 >>>>> On 4 Aug 2011, at 10:52, Johan Rydberg wrote: >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> After following the discussions for a while, I have a question: >>>>>>=20 >>>>>> Instead of constructing a complex metadata exchange protocol, >>>>>> why not force the upstream CDN to enforce any prolicy rules that >>>>>> the CSP has put on the content? >>>>>>=20 >>>>>>=20 >>>>> That would not provide sufficient coverage to ensure that the policy >> is enforced as clients may attempt to request content directly from a >> downstream CDN, bypassing the upstream CDN. >>>>>=20 >>>>>=20 >>>> There must be ways to make sure that the client first passes through >> the >>>> upstream >>>> CDN. >>>>=20 >>>> I have a feeling that if the interconnect protocols are not limited in >>>> scope, this >>>> CDNI effort will either (1) fail or (2) be in some "design phase" for >> ever. >>>>=20 >>>>=20 >>>>>=20 >>>>>=20 >>>>>> In the case of DNS-based routing, the CDN can answer the DNS >>>>>> lookup with the address of one of its own CDNI request routers >>>>>> that will enforce any policies before redirecting (HTTP 302) to >>>>>> a downstream CDN. >>>>>>=20 >>>>>> The upside to this is that redirects between CDNs will always be >>>>>> HTTP 302, regardless if the initial mechanism was DNS-based. >>>>>> Also, the complex metadata protocol can be elimited, minimizing >>>>>> the scope of the CDNI work. >>>>>>=20 >>>>>>=20 >>>>> Even if one could avoid the need for a downstream CDN to apply some >> policies, this wouldn't eliminate the need to exchange CDNI metadata as >> other CDNI metadata such as rate limiting, whether an encrypted channel = is >> required, where to obtain the content from etc. is still required. >>>>>=20 >>>>>=20 >>>> It sounds like most of those could be folded into the request routing >>>> protocol. >>>> Rate limiting and encryption might not be attributes of the content, >> but >>>> rather >>>> of the client. (Some customers pay more, and get a higher bitrate for >>>> example) >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> CDNi mailing list >>>> CDNi@ietf.org >>>> https://www.ietf.org/mailman/listinfo/cdni >>>>=20 >>>=20 >>> _______________________________________________ >>> CDNi mailing list >>> CDNi@ietf.org >>> https://www.ietf.org/mailman/listinfo/cdni >>=20 >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni From kleung@cisco.com Thu Aug 4 12:15:30 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC77B21F8AB8 for ; Thu, 4 Aug 2011 12:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.067 X-Spam-Level: X-Spam-Status: No, score=-2.067 tagged_above=-999 required=5 tests=[AWL=-0.068, BAYES_00=-2.599, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vl72Tg7jHCtv for ; Thu, 4 Aug 2011 12:15:30 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 29A2921F8AAA for ; Thu, 4 Aug 2011 12:15:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=kleung@cisco.com; l=2648; q=dns/txt; s=iport; t=1312485346; x=1313694946; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=sjL6wfA+W/vpMLSm3LrUA8G72Jc3eMcrPxDJo9YUTao=; b=HSljCEolH26jeBOwPpsJ/auPp2SvqCIcm7LF/Xx6Opcp+L0mvBrdO68V 41RLJ/tcTdFP1xHWzmea01hd7qaFwCj9a/xW/RfGcf8JuBbesXhjTk0NH FK7eLfC9NjWma4HHIdvJtMeGFW5o5hgrt6G2Yth/tenOUKRwUbh+38V6/ U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvgAAFTvOk6rRDoH/2dsb2JhbAA5CpgOj1x3gUABAQEBAxIBHQo/DAQCAQgRBAEBAQoDAxcBBgFFCQgBAQQTCBMHqmEBnmuDJII/XwSHWpAxi3Q X-IronPort-AV: E=Sophos;i="4.67,318,1309737600"; d="scan'208";a="9759232" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-6.cisco.com with ESMTP; 04 Aug 2011 19:15:45 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p74JFVeD002590; Thu, 4 Aug 2011 19:15:44 GMT Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 4 Aug 2011 12:15:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 4 Aug 2011 12:15:36 -0700 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC520F876307@xmb-sjc-235.amer.cisco.com> In-Reply-To: <7EBF6898-A595-4DD4-A48E-71296357C839@niven-jenkins.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Maximum resolutions & CDNs Thread-Index: AcxStSHgb/cvsHjISjebKan6sBCxXQAJYLwg References: <1AC8E92C-3A69-4C80-A235-710DEF396A53@cisco.com> <2979E38DD6FC6544B789C8DAD7BAFC520F72CD55@xmb-sjc-235.amer.cisco.com> <7EBF6898-A595-4DD4-A48E-71296357C839@niven-jenkins.co.uk> From: "Kent Leung (kleung)" To: "Ben Niven-Jenkins" X-OriginalArrivalTime: 04 Aug 2011 19:15:36.0793 (UTC) FILETIME=[E3F7FC90:01CC52DA] Cc: cdni@ietf.org, draft-bertrand-cdni-use-cases@tools.ietf.org Subject: Re: [CDNi] Maximum resolutions & CDNs X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 19:15:31 -0000 Hi Ben. I agree with your comments. It seems that there are no new requirements. Kent -----Original Message----- From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk]=20 Sent: Thursday, August 04, 2011 7:45 AM To: Kent Leung (kleung) Cc: Francois Le Faucheur (flefauch); draft-bertrand-cdni-use-cases@tools.ietf.org; cdni@ietf.org Subject: Maximum resolutions & CDNs Use Case authors, Colleagues, draft-bertrand-cdni-use-cases states in section 2.4: > " > The delivery of content may be further influenced by policies which > may include quality of service rules that specify: > o the maximum resolution deliverable to specific devices, > o the maximum resolution deliverable though a specific NSP, or > o the maximum resolution deliverable to users based on their > subscription levels. > " On 26 Jul 2011, at 21:54, Francois Le Faucheur wrote: > I don't think this is covered in the cdni-requirements doc.=20 > It is not obvious to me that absolutely all of those ought to be in > phase 1. The first bullet only makes sense if the solution supports > transcoding/transrating, which I don't know if it will be supported in > Initial scope. > The last bullet does not make sense to me as we don;t want the CDNs to > be aware of any user subscription levels (ie only CSP is aware of user > subscription level). On 28 Jul 2011, at 21:10, Kent Leung (kleung) wrote: > KL> I'm not yet convinced that this should be part of the CDNI Metadata. > Based on the discussion conclusion, we can track this as possible > requirement for now. I can understand that the stated "maximum resolution" requirements may be CSP requirements but I'm a little unclear as to how they translate to capabilities on a CDN which would typically not be aware of the resolution of the content it is delivering. It is not clear to me how delivery to specific devices can be handled by a CDN as I'm not really sure how a CDN can identify a particular device in the general case? Given different resolutions will map to different files (or sets of files) in a CDN is it sufficient to, for example (other methods may also be equally applicable): - Have delivery to specific NSPs handled by geo-blocking policies per file (or set of files)? - Have delivery based on subscription level handled by authentication tokens set by the CSP's "portal" (or something other than the CDN that actually understands who has what subscription?)? Therefore meaning that specific details of the resolution of a particular file (or set of files) still remain transparent to the CDN? Thanks Ben From kleung@cisco.com Thu Aug 4 12:26:29 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE6BC21F8747 for ; Thu, 4 Aug 2011 12:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.363 X-Spam-Level: X-Spam-Status: No, score=-2.363 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R1b22qwjxUIV for ; Thu, 4 Aug 2011 12:26:29 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1461021F8726 for ; Thu, 4 Aug 2011 12:26:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=kleung@cisco.com; l=3355; q=dns/txt; s=iport; t=1312486004; x=1313695604; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=SlVSyTr5nPqpxOu6oa+UwnNfl6unHTx9QTWYeArJfgs=; b=U/qpyqK95InqeDiBIEBHi1WnvC+wNSFyJj0fY6RplUKEum/NRVHo1EV6 yvqAxdvZ/5SkEuMBTBJPadHjBb8yPIc+HKEvlOnvKtsm8q4pdVptMZA5z 5sEpqLjZDYzIPsZn9g7hgiqz3aHGWpFuRkjxCVDzE6Ggg62Mwf0FF0VmK w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvgAAATyOk6rRDoJ/2dsb2JhbABDmA6PXHeBQAEBAQECARIBHQo/BQcEAgEIEQQBAQEKBhcBBgFFCQgBAQQBEggah0qjGQGebIVjXwSHWpAxi3Q X-IronPort-AV: E=Sophos;i="4.67,318,1309737600"; d="scan'208";a="9763420" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-1.cisco.com with ESMTP; 04 Aug 2011 19:26:44 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p74JQhMm010733; Thu, 4 Aug 2011 19:26:43 GMT Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 4 Aug 2011 12:26:43 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 4 Aug 2011 12:26:42 -0700 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC520F876312@xmb-sjc-235.amer.cisco.com> In-Reply-To: <0160D539-A630-4BCB-BC25-D50881FCFEDF@niven-jenkins.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CDNi] comments on draft-bertrand-cdni-use-cases-02 Thread-Index: AcxSsfjK3DMEUq3fSqWJf46PyZ6P3AAKRZUQ References: <1AC8E92C-3A69-4C80-A235-710DEF396A53@cisco.com> <2979E38DD6FC6544B789C8DAD7BAFC520F72CD55@xmb-sjc-235.amer.cisco.com> <0160D539-A630-4BCB-BC25-D50881FCFEDF@niven-jenkins.co.uk> From: "Kent Leung (kleung)" To: "Ben Niven-Jenkins" , "Francois Le Faucheur (flefauch)" X-OriginalArrivalTime: 04 Aug 2011 19:26:43.0374 (UTC) FILETIME=[71482CE0:01CC52DC] Cc: cdni@ietf.org, draft-bertrand-cdni-use-cases@tools.ietf.org Subject: Re: [CDNi] comments on draft-bertrand-cdni-use-cases-02 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 19:26:29 -0000 Hi Ben. In general, I think that content that has expired should be treated similarly as de-activated except that content is removed from the Surrogate. The content availability window has to work in conjunction with cache aging function. So there shouldn't be requirements to the level of implementation. As for de-linking from filesystem vs overwrite, this is the same question for Control Interface content removal function. I think both operations should be consistent (i.e. explicit content removal and content expiration). Kent -----Original Message----- From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk]=20 Sent: Thursday, August 04, 2011 7:23 AM To: Francois Le Faucheur (flefauch) Cc: Kent Leung (kleung); cdni@ietf.org; draft-bertrand-cdni-use-cases@tools.ietf.org Subject: Re: [CDNi] comments on draft-bertrand-cdni-use-cases-02 Use Case authors, Colleagues, On 28 Jul 2011, at 21:16, Francois Le Faucheur wrote: > Kent and all, >=20 > On 28 Jul 2011, at 16:10, Kent Leung (kleung) wrote: >=20 >> Hi Francois. Responding to comments related to the requirements draft >> below. >>=20 >>=20 >> o an expiration time (i.e., the time at which the content files >> should be expunged from all CDN storage). >> " >> I understand this is saying that CDNI metadata need to include this >> expiration time (triggering cache removal) , in addition to deactivation >> time.=20 >> I don't think this is discussed in cdni-requirements yet. Can you bring >> that up on the list with the cdni-reqts authors? >>=20 >> KL> I've seen references to content expiration time (i.e. removal) in >> some drafts. So it seems to be needed in the CDNI Metadata. Noted as >> requirement (possibly part of availability window) unless others object. >=20 > FLF as an Individual: that works for me. I'd like to understand the underlying requirement a bit better as it's not clear to me what the expected behaviour of a surrogate would be when receiving a request for the content after the "expiration time" is reached as well as how the surrogate is supposed to treat any cached copy of the content held in either volatile or non-volatile storage. For example, when receiving a request for content after the "expiration time" is reached, is a surrogate required to: - No longer deliver the content, even if presented with a valid request to do? - Consider any cached copy of the content as "stale" and revalidate the content against the Origin, delivering the content if revalidation succeeds and not delivering the content if revalidation fails. For example, for any cached copy of the content after the "expiration time" is reach, is a surrogate required to: - Nothing more than whatever it is supposed to do in the example above and use its normal cache expiration procedures to recovery the storage space used like it would for "stale" content that does not have an explicit expiration time?=20 - Actively keep track of cached content & its associated expiration time and actively "de-link" (e.g. remove from the filesystem table) the cached copy of the content?=20 - Actively keep track of cached content & its associated expiration time and actively overwrite the storage sectors containing that content in both volatile & non-volatile storage? Thanks Ben From kevin.ma@azukisystems.com Thu Aug 4 12:26:58 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03F1321F8747 for ; Thu, 4 Aug 2011 12:26:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.032 X-Spam-Level: X-Spam-Status: No, score=-2.032 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CDhcS57TGcJs for ; Thu, 4 Aug 2011 12:26:57 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 57DCB21F8726 for ; Thu, 4 Aug 2011 12:26:57 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 860F3554A7D; Thu, 4 Aug 2011 15:27:12 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB013.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id E2AC655481D; Thu, 4 Aug 2011 15:27:08 -0400 (EDT) Received: from MAILR002.mail.lan ([10.110.18.16]) by HUB013.mail.lan ([10.110.17.13]) with mapi; Thu, 4 Aug 2011 15:27:06 -0400 From: Kevin J Ma To: Ben Niven-Jenkins , Kent Leung Date: Thu, 4 Aug 2011 15:27:05 -0400 Thread-Topic: [CDNi] Maximum resolutions & CDNs Thread-Index: AcxStTRWdTNtGaPgQoKuPxNpfxpu0AAJPWvg Message-ID: <291CC3F9E50E7641901A54E85D0977C6518C239268@MAILR002.mail.lan> References: <1AC8E92C-3A69-4C80-A235-710DEF396A53@cisco.com> <2979E38DD6FC6544B789C8DAD7BAFC520F72CD55@xmb-sjc-235.amer.cisco.com> <7EBF6898-A595-4DD4-A48E-71296357C839@niven-jenkins.co.uk> In-Reply-To: <7EBF6898-A595-4DD4-A48E-71296357C839@niven-jenkins.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" , "draft-bertrand-cdni-use-cases@tools.ietf.org" Subject: Re: [CDNi] Maximum resolutions & CDNs X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 19:26:58 -0000 Hi Ben, As mentioned in a previous response, different encodings could certainly be treated as independent files. It may be, however, that information about different encodings (not just resolution) may be useful to dCDNs, e.g., for prefetching HLS segments, or for identifying HLS segment bundles, but for policy enforcement, often a User-Agent header or some other custom header or cookie is sufficient for content selection. It may be that not all CDNs support this, and this is probably outside the scope of CDNI, but the use case was more intended as an example of the need for opaque metadata, and not as a requirement of CDNI to enforce CSP policies. In the updated draft, we have moved the text and tried to make it more generic in terms of the need for detecting metadata feature support. thanx. -- Kevin J. Ma > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of > Ben Niven-Jenkins > Sent: Thursday, August 04, 2011 10:45 AM > To: Kent Leung > Cc: cdni@ietf.org; draft-bertrand-cdni-use-cases@tools.ietf.org > Subject: [CDNi] Maximum resolutions & CDNs >=20 > Use Case authors, Colleagues, >=20 > draft-bertrand-cdni-use-cases states in section 2.4: > > " > > The delivery of content may be further influenced by policies which > > may include quality of service rules that specify: > > o the maximum resolution deliverable to specific devices, > > o the maximum resolution deliverable though a specific NSP, or > > o the maximum resolution deliverable to users based on their > > subscription levels. > > " >=20 > On 26 Jul 2011, at 21:54, Francois Le Faucheur wrote: > > I don't think this is covered in the cdni-requirements doc. > > It is not obvious to me that absolutely all of those ought to be in > > phase 1. The first bullet only makes sense if the solution supports > > transcoding/transrating, which I don't know if it will be supported in > > Initial scope. > > The last bullet does not make sense to me as we don;t want the CDNs to > > be aware of any user subscription levels (ie only CSP is aware of user > > subscription level). >=20 > On 28 Jul 2011, at 21:10, Kent Leung (kleung) wrote: > > KL> I'm not yet convinced that this should be part of the CDNI Metadata= . > > Based on the discussion conclusion, we can track this as possible > > requirement for now. >=20 > I can understand that the stated "maximum resolution" requirements may be > CSP requirements but I'm a little unclear as to how they translate to > capabilities on a CDN which would typically not be aware of the resolutio= n > of the content it is delivering. >=20 > It is not clear to me how delivery to specific devices can be handled by = a > CDN as I'm not really sure how a CDN can identify a particular device in > the general case? >=20 > Given different resolutions will map to different files (or sets of files= ) > in a CDN is it sufficient to, for example (other methods may also be > equally applicable): >=20 > - Have delivery to specific NSPs handled by geo-blocking policies per > file (or set of files)? >=20 > - Have delivery based on subscription level handled by authentication > tokens set by the CSP's "portal" (or something other than the CDN that > actually understands who has what subscription?)? >=20 > Therefore meaning that specific details of the resolution of a particular > file (or set of files) still remain transparent to the CDN? >=20 > Thanks > Ben >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From kevin.ma@azukisystems.com Thu Aug 4 12:36:08 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 205701F0C3F for ; Thu, 4 Aug 2011 12:36:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.329 X-Spam-Level: X-Spam-Status: No, score=-2.329 tagged_above=-999 required=5 tests=[AWL=0.270, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D74RgufjvABz for ; Thu, 4 Aug 2011 12:36:07 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 5ADA21F0C3E for ; Thu, 4 Aug 2011 12:36:07 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id A7C69553FA6; Thu, 4 Aug 2011 15:36:17 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB027.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 252E4553EEF; Thu, 4 Aug 2011 15:36:17 -0400 (EDT) Received: from MAILR002.mail.lan ([10.110.18.16]) by HUB027.mail.lan ([10.110.17.27]) with mapi; Thu, 4 Aug 2011 15:36:09 -0400 From: Kevin J Ma To: Ben Niven-Jenkins , Francois Le Faucheur Date: Thu, 4 Aug 2011 15:36:16 -0400 Thread-Topic: [CDNi] comments on draft-bertrand-cdni-use-cases-02 Thread-Index: AcxSsgSr8ARRLyE2QyOL09ckGlOtOQAK0rqw Message-ID: <291CC3F9E50E7641901A54E85D0977C6518C23927B@MAILR002.mail.lan> References: <1AC8E92C-3A69-4C80-A235-710DEF396A53@cisco.com> <2979E38DD6FC6544B789C8DAD7BAFC520F72CD55@xmb-sjc-235.amer.cisco.com> <0160D539-A630-4BCB-BC25-D50881FCFEDF@niven-jenkins.co.uk> In-Reply-To: <0160D539-A630-4BCB-BC25-D50881FCFEDF@niven-jenkins.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" , "draft-bertrand-cdni-use-cases@tools.ietf.org" Subject: Re: [CDNi] comments on draft-bertrand-cdni-use-cases-02 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 19:36:08 -0000 Hi Ben, I would expect that once the expiration time is reached, all copies of th= e content would be expunged from any surrogates/storage devices. I believe there was discussion a while back about whether to only use the control interface to issue purge requests, or whether to use metadata to set expiration dates, or to allow both? In the event of both, I would think both functions should act the same, i.e., when the expiration date is reached, it is just like a uCDN sent a purge request. thanx. -- Kevin J. Ma > -----Original Message----- > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] > Sent: Thursday, August 04, 2011 10:23 AM > To: Francois Le Faucheur > Cc: Kent Leung (kleung); cdni@ietf.org; draft-bertrand-cdni-use- > cases@tools.ietf.org > Subject: Re: [CDNi] comments on draft-bertrand-cdni-use-cases-02 >=20 > Use Case authors, Colleagues, >=20 > On 28 Jul 2011, at 21:16, Francois Le Faucheur wrote: >=20 > > Kent and all, > > > > On 28 Jul 2011, at 16:10, Kent Leung (kleung) wrote: > > > >> Hi Francois. Responding to comments related to the requirements draft > >> below. > >> > >> > >> o an expiration time (i.e., the time at which the content files > >> should be expunged from all CDN storage). > >> " > >> I understand this is saying that CDNI metadata need to include this > >> expiration time (triggering cache removal) , in addition to > deactivation > >> time. > >> I don't think this is discussed in cdni-requirements yet. Can you brin= g > >> that up on the list with the cdni-reqts authors? > >> > >> KL> I've seen references to content expiration time (i.e. removal) in > >> some drafts. So it seems to be needed in the CDNI Metadata. Noted as > >> requirement (possibly part of availability window) unless others > object. > > > > FLF as an Individual: that works for me. >=20 > I'd like to understand the underlying requirement a bit better as it's no= t > clear to me what the expected behaviour of a surrogate would be when > receiving a request for the content after the "expiration time" is reache= d > as well as how the surrogate is supposed to treat any cached copy of the > content held in either volatile or non-volatile storage. >=20 > For example, when receiving a request for content after the "expiration > time" is reached, is a surrogate required to: > - No longer deliver the content, even if presented with a valid request t= o > do? > - Consider any cached copy of the content as "stale" and revalidate the > content against the Origin, delivering the content if revalidation > succeeds and not delivering the content if revalidation fails. >=20 > For example, for any cached copy of the content after the "expiration > time" is reach, is a surrogate required to: > - Nothing more than whatever it is supposed to do in the example above an= d > use its normal cache expiration procedures to recovery the storage space > used like it would for "stale" content that does not have an explicit > expiration time? > - Actively keep track of cached content & its associated expiration time > and actively "de-link" (e.g. remove from the filesystem table) the cached > copy of the content? > - Actively keep track of cached content & its associated expiration time > and actively overwrite the storage sectors containing that content in bot= h > volatile & non-volatile storage? >=20 > Thanks > Ben >=20 From vishwas.ietf@gmail.com Thu Aug 4 12:39:35 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3635621F8761 for ; Thu, 4 Aug 2011 12:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.837 X-Spam-Level: X-Spam-Status: No, score=-2.837 tagged_above=-999 required=5 tests=[AWL=0.761, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDUgXms2ncRF for ; Thu, 4 Aug 2011 12:39:34 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id B38BF21F866A for ; Thu, 4 Aug 2011 12:39:33 -0700 (PDT) Received: by qwc23 with SMTP id 23so1498720qwc.31 for ; Thu, 04 Aug 2011 12:39:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=c23P/fk2cvR7kz2KOaBXg/MpGmSc6mJOaGuiV9H0bpI=; b=T5FoTA7lgPfEmaOOFhOwdNMaYfqmLuJRipxca2jWeC09v0qS+Yb9atoAmax142lpNT pQuIhJXcVM4m9qYcxsMriz5peqRY6cmuRrS2l5wcWeffs5MsyacY8Yz9QzS/RVNC8fXq cSGUZNHvuQKnjGIEbgnJN/VPpdeeHZTnuAKLU= MIME-Version: 1.0 Received: by 10.229.118.72 with SMTP id u8mr993765qcq.1.1312486788832; Thu, 04 Aug 2011 12:39:48 -0700 (PDT) Received: by 10.229.65.91 with HTTP; Thu, 4 Aug 2011 12:39:48 -0700 (PDT) In-Reply-To: <291CC3F9E50E7641901A54E85D0977C6518C23922F@MAILR002.mail.lan> References: <4E3A6BEE.4080301@edgeware.tv> <8AF4C086-7E25-4931-9BF7-7DC7F44A9D2C@niven-jenkins.co.uk> <4E3A7178.6080400@edgeware.tv> <1CA25301D2219F40B3AA37201F0EACD11360E6C4@PACDCEXMB05.cable.comcast.com> <4E3AB142.4030103@edgeware.tv> <70AE7D15-69E5-40FE-A4EE-F6BF5E01C6A9@verivue.com> <291CC3F9E50E7641901A54E85D0977C6518C23922F@MAILR002.mail.lan> Date: Thu, 4 Aug 2011 12:39:48 -0700 Message-ID: From: Vishwas Manral To: Kevin J Ma Content-Type: multipart/alternative; boundary=000e0cd5cff4d21e0e04a9b324df Cc: "cdni@ietf.org" Subject: Re: [CDNi] upstream cdn enforce content policies X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 19:39:35 -0000 --000e0cd5cff4d21e0e04a9b324df Content-Type: text/plain; charset=ISO-8859-1 Hi Kevin, I agree with you here. We need to define metadata for content to have the CSP delegate the policies, which could include the content not leaving the uCDN, or being passed to a defined set of dCDN's. Thanks, Vishwas On Thu, Aug 4, 2011 at 12:00 PM, Kevin J Ma wrote: > > The question is: does interconnection imply that uCDN further delegates > that > > responsibility for enforcing access control policy to the dCDN, or does > the uCDN > > retain that locus of control for itself. > > I think the issue is more the threat that a CSP may have an agreement with > the uCDN, which it has paid for, which may not be enforceable through > dCDNs. > It is not clear that a uCDN can always enforce those policies. It is not > that > hard to figure out where the content is really coming from (i.e., the > dCDN). > Will CSPs, who tend to be risk averse, just disallow delegation? > > Sticking with the minimalist approach, I still think there is value in a > standardized method of exchanging opaque metadata. If some CDNs agree > amongst themselves (outside of CDNI) to enforce policies, they will most > likely need to exchange metadata? Having a well defined protocol to do so > seems like an important first step? > > > > -----Original Message----- > > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of > > Peterson, Larry > > Sent: Thursday, August 04, 2011 11:31 AM > > To: Johan Rydberg > > Cc: cdni@ietf.org > > Subject: Re: [CDNi] upstream cdn enforce content policies > > > > Picking up on Johan's minimized scope thread... > > > > I too have been puzzled by the metadata interface. If you read the > > language > > carefully, you'll see there's a caveat that this interface might exist in > > various > > forms, presumably as a combination of other interfaces and mechanisms, > > for example: > > o the uCDN doesn't route the request to the dCDN unless policy > permits; > > o the uCDN sets HTTP caching directives consistent with policy and the > > dCDN obeys those directives; and > > o the uCDN invokes purge on dCDN should the policy change. > > > > But that generous interpretation aside, the high level issue seems to be > > how > > access control policy is enforced. In a single CDN it's natural for this > > policy to > > be enforced by the CDN, and there's likely a metadata-like interface by > > which > > the CSP expresses this policy to that CDN. > > > > The question is: does interconnection imply that uCDN further delegates > > that > > responsibility for enforcing access control policy to the dCDN, or does > > the uCDN > > retain that locus of control for itself. The later design, which > > essentially treats > > the dCDN as it would any other cache (at least with respect to metadata), > > seems > > the simplest to me. > > > > Larry > > > > On Aug 4, 2011, at 10:48 AM, Johan Rydberg wrote: > > > > > Richard, > > > > > > I just got a bit scared when I saw discussions about features that "may > > > be good to have" > > > or "it would be nice to support". > > > > > > I guess all I wanted to say was that everyone would benefit from a > > > minimized scoop. > > > > > > On 8/4/11 4:34 PM, Woundy, Richard wrote: > > >> A couple of observations, as an individual and not a working group > > chair. > > >> > > >> > > >>> Instead of constructing a complex metadata exchange protocol > > >>> > > >> How about we construct a *simple* metadata exchange protocol? :) > > >> > > >> I believe we are anticipating this protocol to be XML/JSON over HTTP. > > >> > > >> > > >>> I have a feeling that if the interconnect protocols are not limited > in > > scope, this CDNI effort will either (1) fail or (2) be in some "design > > phase" for ever. > > >>> > > >> CDNI was approved as a WG in late June. Now it is early August and > > we're already in danger of failing? Hmmm. > > >> > > >> It feels to me like we are debating theoretical scenarios. Johan, if > > you feel strongly about eliminating this interface, maybe you could write > > up your proposal as an internet-draft that we can discuss and debate? We > > also need to ensure that your proposal meets the use cases identified by > > this group. > > >> > > >> -- Rich > > >> > > >> -----Original Message----- > > >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf > Of > > Johan Rydberg > > >> Sent: Thursday, August 04, 2011 6:16 AM > > >> To: Ben Niven-Jenkins > > >> Cc: cdni@ietf.org > > >> Subject: Re: [CDNi] upstream cdn enforce content policies > > >> > > >> On 8/4/11 12:10 PM, Ben Niven-Jenkins wrote: > > >> > > >>> Johan, > > >>> > > >>> On 4 Aug 2011, at 10:52, Johan Rydberg wrote: > > >>> > > >>> > > >>> > > >>>> After following the discussions for a while, I have a question: > > >>>> > > >>>> Instead of constructing a complex metadata exchange protocol, > > >>>> why not force the upstream CDN to enforce any prolicy rules that > > >>>> the CSP has put on the content? > > >>>> > > >>>> > > >>> That would not provide sufficient coverage to ensure that the policy > > is enforced as clients may attempt to request content directly from a > > downstream CDN, bypassing the upstream CDN. > > >>> > > >>> > > >> There must be ways to make sure that the client first passes through > > the > > >> upstream > > >> CDN. > > >> > > >> I have a feeling that if the interconnect protocols are not limited in > > >> scope, this > > >> CDNI effort will either (1) fail or (2) be in some "design phase" for > > ever. > > >> > > >> > > >>> > > >>> > > >>>> In the case of DNS-based routing, the CDN can answer the DNS > > >>>> lookup with the address of one of its own CDNI request routers > > >>>> that will enforce any policies before redirecting (HTTP 302) to > > >>>> a downstream CDN. > > >>>> > > >>>> The upside to this is that redirects between CDNs will always be > > >>>> HTTP 302, regardless if the initial mechanism was DNS-based. > > >>>> Also, the complex metadata protocol can be elimited, minimizing > > >>>> the scope of the CDNI work. > > >>>> > > >>>> > > >>> Even if one could avoid the need for a downstream CDN to apply some > > policies, this wouldn't eliminate the need to exchange CDNI metadata as > > other CDNI metadata such as rate limiting, whether an encrypted channel > is > > required, where to obtain the content from etc. is still required. > > >>> > > >>> > > >> It sounds like most of those could be folded into the request routing > > >> protocol. > > >> Rate limiting and encryption might not be attributes of the content, > > but > > >> rather > > >> of the client. (Some customers pay more, and get a higher bitrate for > > >> example) > > >> > > >> > > >> > > >> > > >> > > >> _______________________________________________ > > >> CDNi mailing list > > >> CDNi@ietf.org > > >> https://www.ietf.org/mailman/listinfo/cdni > > >> > > > > > > _______________________________________________ > > > CDNi mailing list > > > CDNi@ietf.org > > > https://www.ietf.org/mailman/listinfo/cdni > > > > _______________________________________________ > > CDNi mailing list > > CDNi@ietf.org > > https://www.ietf.org/mailman/listinfo/cdni > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > --000e0cd5cff4d21e0e04a9b324df Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Kevin,
=A0
I agree with you here.
=A0
We need to define metadata for content to have the CSP delegate the po= licies, which could include the content not leaving the uCDN, or being pass= ed to a defined set of dCDN's.
=A0
Thanks,
Vishwas
On Thu, Aug 4, 2011 at 12:00 PM, Kevin J Ma <kevin.ma@azukisystems.com> wrote:
> The question is: does interconnection imply that uCD= N further delegates that
> responsibility for enforcing access contro= l policy to the dCDN, or does the uCDN
> retain that locus of control= for itself.

I think the issue is more the threat that a CSP may have an agree= ment with
the uCDN, which it has paid for, which may not be enforceable = through dCDNs.
It is not clear that a uCDN can always enforce those poli= cies. =A0It is not that
hard to figure out where the content is really coming from (i.e., the dCDN)= .
Will CSPs, who tend to be risk averse, just disallow delegation?
Sticking with the minimalist approach, I still think there is value in a<= br> standardized method of exchanging opaque metadata. =A0If some CDNs agreeamongst themselves (outside of CDNI) to enforce policies, they will mostlikely need to exchange metadata? =A0Having a well defined protocol to do= so
seems like an important first step?


> -----Original Message-----
> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf = Of
> Peterson, Larry
> Sent: Thursday, August 04, 2011 11:31 AM=
> To: Johan Rydberg
> Cc: cdni@ietf.org
> Subject: Re: [CDNi] upstream cdn enforce content policies
>= ;
> Picking up on Johan's minimized scope thread...
>
&g= t; I too have been puzzled by the metadata interface. If you read the
> language
> carefully, you'll see there's a caveat that t= his interface might exist in
> various
> forms, presumably as a= combination of other interfaces and mechanisms,
> for example:
> =A0 =A0o the uCDN doesn't route the request to the dCDN unless pol= icy permits;
> =A0 =A0o the uCDN sets HTTP caching directives consist= ent with policy and the
> =A0 =A0 =A0 dCDN obeys those directives; an= d
> =A0 =A0o the uCDN invokes purge on dCDN should the policy change.=
>
> But that generous interpretation aside, the high level issue s= eems to be
> how
> access control policy is enforced. In a sing= le CDN it's natural for this
> policy to
> be enforced by t= he CDN, and there's likely a metadata-like interface by
> which
> the CSP expresses this policy to that CDN.
>
&g= t; The question is: does interconnection imply that uCDN further delegates<= br>> that
> responsibility for enforcing access control policy to = the dCDN, or does
> the uCDN
> retain that locus of control for itself. The later de= sign, which
> essentially treats
> the dCDN as it would any oth= er cache (at least with respect to metadata),
> seems
> the sim= plest to me.
>
> Larry
>
> On Aug 4, 2011, at 10:48 AM, Johan Rydbe= rg wrote:
>
> > Richard,
> >
> > I just go= t a bit scared when I saw discussions about features that "may
> > be good to have"
> > or "it would be nice to s= upport".
> >
> > I guess all I wanted to say was tha= t everyone would benefit from a
> > minimized scoop.
> ><= br> > > On 8/4/11 4:34 PM, Woundy, Richard wrote:
> >> A coup= le of observations, as an individual and not a working group
> chair.=
> >>
> >>
> >>> Instead of construc= ting a complex metadata exchange protocol
> >>>
> >> How about we construct a *simple* metada= ta exchange protocol? :)
> >>
> >> I believe we are= anticipating this protocol to be XML/JSON over HTTP.
> >>
> >>
> >>> I have a feeling that if the interconnec= t protocols are not limited in
> scope, this CDNI effort will either = (1) fail or (2) be in some "design
> phase" for ever.
> >>>
> >> CDNI was approved as a WG in late June. = Now it is early August and
> we're already in danger of failing? = Hmmm.
> >>
> >> It feels to me like we are debating= theoretical scenarios. Johan, if
> you feel strongly about eliminating this interface, maybe you could wr= ite
> up your proposal as an internet-draft that we can discuss and d= ebate? We
> also need to ensure that your proposal meets the use case= s identified by
> this group.
> >>
> >> -- Rich
> >>=
> >> -----Original Message-----
> >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of > Johan Rydberg
> >> Sent: Thursday, August 04, 2011 6:16 AM=
> >> To: Ben Niven-Jenkins
> >> Cc: cdni@ietf.org
> >> Subject: Re: [CDNi] u= pstream cdn enforce content policies
> >>
> >> On 8/4/11 12:10 PM, Ben Niven-Jenkins wrote:=
> >>
> >>> Johan,
> >>>
> = >>> On 4 Aug 2011, at 10:52, Johan Rydberg wrote:
> >>= >
> >>>
> >>>
> >>>> After follo= wing the discussions for a while, I have a question:
> >>>&g= t;
> >>>> Instead of constructing a complex metadata exch= ange protocol,
> >>>> why not force the upstream CDN to enforce any prolicy= rules that
> >>>> the CSP has put on the content?
>= ; >>>>
> >>>>
> >>> That would= not provide sufficient coverage to ensure that the policy
> is enforced as clients may attempt to request content directly from a<= br>> downstream CDN, bypassing the upstream CDN.
> >>>> >>>
> >> There must be ways to make sure that th= e client first passes through
> the
> >> upstream
> >> CDN.
> >>> >> I have a feeling that if the interconnect protocols are not= limited in
> >> scope, this
> >> CDNI effort will = either (1) fail or (2) be in some "design phase" for
> ever.
> >>
> >>
> >>>
> &= gt;>>
> >>>> In the case of DNS-based routing, the = CDN can answer the DNS
> >>>> lookup with the address of = one of its own CDNI request routers
> >>>> that will enforce any policies before redirecting (HT= TP 302) to
> >>>> a downstream CDN.
> >>>&= gt;
> >>>> The upside to this is that redirects between C= DNs will always be
> >>>> HTTP 302, regardless if the initial mechanism was DNS= -based.
> >>>> Also, the complex metadata protocol can be= elimited, minimizing
> >>>> the scope of the CDNI work.<= br> > >>>>
> >>>>
> >>> Even if= one could avoid the need for a downstream CDN to apply some
> polici= es, this wouldn't eliminate the need to exchange CDNI metadata as
> other CDNI metadata such as rate limiting, whether an encrypted channe= l is
> required, where to obtain the content from etc. is still requi= red.
> >>>
> >>>
> >> It sounds l= ike most of those could be folded into the request routing
> >> protocol.
> >> Rate limiting and encryption might= not be attributes of the content,
> but
> >> rather
&= gt; >> of the client. =A0(Some customers pay more, and get a higher b= itrate for
> >> example)
> >>
> >>
> >>> >>
> >>
> >> _________________________= ______________________
> >> CDNi mailing list
> >> = CDNi@ietf.org
> >> https://www.ietf.org/mailman/listinfo/cdni
> >>=
> >
> > _______________________________________________<= br> > > CDNi mailing list
> > C= DNi@ietf.org
> > https://www.ietf.org/mailman/listinfo/cdni<= br> >
> _______________________________________________
> CDNi m= ailing list
> CDNi@ietf.org
&= gt; https://www.ietf.org/mailman/listinfo/cdni
_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/mailm= an/listinfo/cdni

--000e0cd5cff4d21e0e04a9b324df-- From vishwas.ietf@gmail.com Thu Aug 4 12:49:42 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 577DB1F0C41 for ; Thu, 4 Aug 2011 12:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.877 X-Spam-Level: X-Spam-Status: No, score=-2.877 tagged_above=-999 required=5 tests=[AWL=0.721, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jPVgPFNq1dg4 for ; Thu, 4 Aug 2011 12:49:41 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0F0081F0C40 for ; Thu, 4 Aug 2011 12:49:40 -0700 (PDT) Received: by qwc23 with SMTP id 23so1503687qwc.31 for ; Thu, 04 Aug 2011 12:49:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Fh+XtU1q23nW491VmQ9z2aSuKAwEp5p+l1Zstfeenls=; b=PjslnJaAzrvSUD1/Mimogf2CAI0Jmla1GvJAglpGKq6L5S1aB6QSjnjYOULuv5sXNk qH2QXWlsAw0Cm88D0+dRfIZj64uOsch/SnntzvQT41CjNP2OeIqpp1cF/znPdHkBGnUu UEvvsZeKij/pFKI5/kk3lNrrgz+KtDTI3uO54= MIME-Version: 1.0 Received: by 10.229.107.5 with SMTP id z5mr964022qco.229.1312487396117; Thu, 04 Aug 2011 12:49:56 -0700 (PDT) Received: by 10.229.65.91 with HTTP; Thu, 4 Aug 2011 12:49:56 -0700 (PDT) In-Reply-To: <291CC3F9E50E7641901A54E85D0977C6518C23927B@MAILR002.mail.lan> References: <1AC8E92C-3A69-4C80-A235-710DEF396A53@cisco.com> <2979E38DD6FC6544B789C8DAD7BAFC520F72CD55@xmb-sjc-235.amer.cisco.com> <0160D539-A630-4BCB-BC25-D50881FCFEDF@niven-jenkins.co.uk> <291CC3F9E50E7641901A54E85D0977C6518C23927B@MAILR002.mail.lan> Date: Thu, 4 Aug 2011 12:49:56 -0700 Message-ID: From: Vishwas Manral To: Kevin J Ma Content-Type: multipart/alternative; boundary=0023544711bc048b9704a9b34929 Cc: "cdni@ietf.org" , "draft-bertrand-cdni-use-cases@tools.ietf.org" Subject: Re: [CDNi] comments on draft-bertrand-cdni-use-cases-02 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 19:49:42 -0000 --0023544711bc048b9704a9b34929 Content-Type: text/plain; charset=ISO-8859-1 Hi Kevin, I would think the data should have the expiration times for sure. Time based content, which uses control messages to purge can have issues which could be result of connectivity. I am not sure why there should be any control messages for purge at all. Thanks, Vishwas On Thu, Aug 4, 2011 at 12:36 PM, Kevin J Ma wrote: > Hi Ben, > > I would expect that once the expiration time is reached, all copies of the > content would be expunged from any surrogates/storage devices. > > I believe there was discussion a while back about whether to only use the > control interface to issue purge requests, or whether to use metadata to > set expiration dates, or to allow both? In the event of both, I would > think both functions should act the same, i.e., when the expiration date > is reached, it is just like a uCDN sent a purge request. > > thanx. > > -- Kevin J. Ma > > > -----Original Message----- > > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] > > Sent: Thursday, August 04, 2011 10:23 AM > > To: Francois Le Faucheur > > Cc: Kent Leung (kleung); cdni@ietf.org; draft-bertrand-cdni-use- > > cases@tools.ietf.org > > Subject: Re: [CDNi] comments on draft-bertrand-cdni-use-cases-02 > > > > Use Case authors, Colleagues, > > > > On 28 Jul 2011, at 21:16, Francois Le Faucheur wrote: > > > > > Kent and all, > > > > > > On 28 Jul 2011, at 16:10, Kent Leung (kleung) wrote: > > > > > >> Hi Francois. Responding to comments related to the requirements draft > > >> below. > > >> > > >> > > >> o an expiration time (i.e., the time at which the content files > > >> should be expunged from all CDN storage). > > >> " > > >> I understand this is saying that CDNI metadata need to include this > > >> expiration time (triggering cache removal) , in addition to > > deactivation > > >> time. > > >> I don't think this is discussed in cdni-requirements yet. Can you > bring > > >> that up on the list with the cdni-reqts authors? > > >> > > >> KL> I've seen references to content expiration time (i.e. removal) in > > >> some drafts. So it seems to be needed in the CDNI Metadata. Noted as > > >> requirement (possibly part of availability window) unless others > > object. > > > > > > FLF as an Individual: that works for me. > > > > I'd like to understand the underlying requirement a bit better as it's > not > > clear to me what the expected behaviour of a surrogate would be when > > receiving a request for the content after the "expiration time" is > reached > > as well as how the surrogate is supposed to treat any cached copy of the > > content held in either volatile or non-volatile storage. > > > > For example, when receiving a request for content after the "expiration > > time" is reached, is a surrogate required to: > > - No longer deliver the content, even if presented with a valid request > to > > do? > > - Consider any cached copy of the content as "stale" and revalidate the > > content against the Origin, delivering the content if revalidation > > succeeds and not delivering the content if revalidation fails. > > > > For example, for any cached copy of the content after the "expiration > > time" is reach, is a surrogate required to: > > - Nothing more than whatever it is supposed to do in the example above > and > > use its normal cache expiration procedures to recovery the storage space > > used like it would for "stale" content that does not have an explicit > > expiration time? > > - Actively keep track of cached content & its associated expiration time > > and actively "de-link" (e.g. remove from the filesystem table) the cached > > copy of the content? > > - Actively keep track of cached content & its associated expiration time > > and actively overwrite the storage sectors containing that content in > both > > volatile & non-volatile storage? > > > > Thanks > > Ben > > > > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > --0023544711bc048b9704a9b34929 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Kevin,
=A0
I would think the data should have the expiration times for sure.
=A0
Time based content, which uses control messages to purge can have issu= es which could be result of connectivity. I am not sure why there should be= any control messages for purge at all.
=A0
Thanks,
Vishwas
On Thu, Aug 4, 2011 at 12:36 PM, Kevin J Ma <kevin.ma@azukisystems.com> wrote:
Hi Ben,

=A0I would expect= that once the expiration time is reached, all copies of the
=A0content = would be expunged from any surrogates/storage devices.

=A0I believe there was discussion a while back about whether to only us= e the
=A0control interface to issue purge requests, or whether to use me= tadata to
=A0set expiration dates, or to allow both? =A0In the event of = both, I would
=A0think both functions should act the same, i.e., when the expiration date=
=A0is reached, it is just like a uCDN sent a purge request.

than= x.

-- =A0Kevin J. Ma

> -----Original Message-----
> From: Ben Niv= en-Jenkins [mailto:ben@niven-jen= kins.co.uk]
> Sent: Thursday, August 04, 2011 10:23 AM
> To:= Francois Le Faucheur
> Cc: Kent Leung (kleung); cdni@ietf.org; draft-bertrand-cdni-use-
> cases@tools.ietf.org
> Subject: Re: [CDNi]= comments on draft-bertrand-cdni-use-cases-02
>
> Use Case authors, Colleagues,
>
> On 28 Jul 2011, = at 21:16, Francois Le Faucheur wrote:
>
> > Kent and all,> >
> > On 28 Jul 2011, at 16:10, Kent Leung (kleung) wrote= :
> >
> >> Hi Francois. =A0Responding to comments related t= o the requirements draft
> >> below.
> >>
> &= gt;>
> >> =A0 o =A0an expiration time (i.e., the time at whi= ch the content files
> >> =A0 =A0 =A0should be expunged from all CDN storage).
> = >> "
> >> I understand this is saying that CDNI meta= data need to include this
> >> expiration time (triggering cach= e removal) , in addition to
> deactivation
> >> time.
> >> I don't think= this is discussed in cdni-requirements yet. Can you bring
> >>= that up on the list with the cdni-reqts authors?
> >>
> = >> KL> I've seen references to content expiration time (i.e. r= emoval) in
> >> some drafts. =A0So it seems to be needed in the CDNI Metadata= . =A0Noted as
> >> requirement (possibly part of availability w= indow) unless others
> object.
> >
> > FLF as an In= dividual: that works for me.
>
> I'd like to understand the underlying requirement a bit be= tter as it's not
> clear to me what the expected behaviour of a s= urrogate would be when
> receiving a request for the content after th= e "expiration time" is reached
> as well as how the surrogate is supposed to treat any cached copy of t= he
> content held in either volatile or non-volatile storage.
>=
> For example, when receiving a request for content after the "= expiration
> time" is reached, is a surrogate required to:
> - No longer= deliver the content, even if presented with a valid request to
> do?=
> - Consider any cached copy of the content as "stale" and= revalidate the
> content against the Origin, delivering the content if revalidation
= > succeeds and not delivering the content if revalidation fails.
>=
> For example, for any cached copy of the content after the "ex= piration
> time" is reach, is a surrogate required to:
> - Nothing mor= e than whatever it is supposed to do in the example above and
> use i= ts normal cache expiration procedures to recovery the storage space
> used like it would for "stale" content that does not have an= explicit
> expiration time?
> - Actively keep track of cached = content & its associated expiration time
> and actively "de-= link" (e.g. remove from the filesystem table) the cached
> copy of the content?
> - Actively keep track of cached content &= amp; its associated expiration time
> and actively overwrite the stor= age sectors containing that content in both
> volatile & non-vola= tile storage?
>
> Thanks
> Ben
>

____________________________= ___________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/cdni

--0023544711bc048b9704a9b34929-- From kevin.ma@azukisystems.com Thu Aug 4 14:03:05 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D38821F861A for ; Thu, 4 Aug 2011 14:03:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=0.249, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PajkFWz8M1T8 for ; Thu, 4 Aug 2011 14:03:04 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 2988411E8082 for ; Thu, 4 Aug 2011 14:02:59 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 48825792E8D; Thu, 4 Aug 2011 17:03:14 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB012.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 901F2792E49; Thu, 4 Aug 2011 17:03:13 -0400 (EDT) Received: from MAILR002.mail.lan ([10.110.18.16]) by HUB012.mail.lan ([10.110.17.12]) with mapi; Thu, 4 Aug 2011 17:02:59 -0400 From: Kevin J Ma To: Vishwas Manral Date: Thu, 4 Aug 2011 17:03:12 -0400 Thread-Topic: [CDNi] comments on draft-bertrand-cdni-use-cases-02 Thread-Index: AcxS39EpYiuoWHSVRBG84Juvx79cgwACWRzw Message-ID: <291CC3F9E50E7641901A54E85D0977C6518C23931A@MAILR002.mail.lan> References: <1AC8E92C-3A69-4C80-A235-710DEF396A53@cisco.com> <2979E38DD6FC6544B789C8DAD7BAFC520F72CD55@xmb-sjc-235.amer.cisco.com> <0160D539-A630-4BCB-BC25-D50881FCFEDF@niven-jenkins.co.uk> <291CC3F9E50E7641901A54E85D0977C6518C23927B@MAILR002.mail.lan> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_291CC3F9E50E7641901A54E85D0977C6518C23931AMAILR002maill_" MIME-Version: 1.0 Cc: "cdni@ietf.org" , "draft-bertrand-cdni-use-cases@tools.ietf.org" Subject: Re: [CDNi] comments on draft-bertrand-cdni-use-cases-02 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 21:03:05 -0000 --_000_291CC3F9E50E7641901A54E85D0977C6518C23931AMAILR002maill_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Vishwas, One could certainly implement an instantaneous purge by setting the expiration date to the current time, but I believe the one advantage of using the control interface was going to be some type of explicit acknowledgement (synchronous or asynchronous) for purge complete. It may be that this could be done another way as well (perhaps via the logging interface), but that was the distinction, as I recall. thanx. -- Kevin J. Ma From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] Sent: Thursday, August 04, 2011 3:50 PM To: Kevin J Ma Cc: Ben Niven-Jenkins; Francois Le Faucheur; cdni@ietf.org; draft-bertrand-= cdni-use-cases@tools.ietf.org Subject: Re: [CDNi] comments on draft-bertrand-cdni-use-cases-02 Hi Kevin, I would think the data should have the expiration times for sure. Time based content, which uses control messages to purge can have issues wh= ich could be result of connectivity. I am not sure why there should be any = control messages for purge at all. Thanks, Vishwas On Thu, Aug 4, 2011 at 12:36 PM, Kevin J Ma @azuk= isystems.com> wrote: Hi Ben, I would expect that once the expiration time is reached, all copies of the content would be expunged from any surrogates/storage devices. I believe there was discussion a while back about whether to only use the control interface to issue purge requests, or whether to use metadata to set expiration dates, or to allow both? In the event of both, I would think both functions should act the same, i.e., when the expiration date is reached, it is just like a uCDN sent a purge request. thanx. -- Kevin J. Ma > -----Original Message----- > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] > Sent: Thursday, August 04, 2011 10:23 AM > To: Francois Le Faucheur > Cc: Kent Leung (kleung); cdni@ietf.org; draft-bertr= and-cdni-use- > cases@tools.ietf.org > Subject: Re: [CDNi] comments on draft-bertrand-cdni-use-cases-02 > > Use Case authors, Colleagues, > > On 28 Jul 2011, at 21:16, Francois Le Faucheur wrote: > > > Kent and all, > > > > On 28 Jul 2011, at 16:10, Kent Leung (kleung) wrote: > > > >> Hi Francois. Responding to comments related to the requirements draft > >> below. > >> > >> > >> o an expiration time (i.e., the time at which the content files > >> should be expunged from all CDN storage). > >> " > >> I understand this is saying that CDNI metadata need to include this > >> expiration time (triggering cache removal) , in addition to > deactivation > >> time. > >> I don't think this is discussed in cdni-requirements yet. Can you brin= g > >> that up on the list with the cdni-reqts authors? > >> > >> KL> I've seen references to content expiration time (i.e. removal) in > >> some drafts. So it seems to be needed in the CDNI Metadata. Noted as > >> requirement (possibly part of availability window) unless others > object. > > > > FLF as an Individual: that works for me. > > I'd like to understand the underlying requirement a bit better as it's no= t > clear to me what the expected behaviour of a surrogate would be when > receiving a request for the content after the "expiration time" is reache= d > as well as how the surrogate is supposed to treat any cached copy of the > content held in either volatile or non-volatile storage. > > For example, when receiving a request for content after the "expiration > time" is reached, is a surrogate required to: > - No longer deliver the content, even if presented with a valid request t= o > do? > - Consider any cached copy of the content as "stale" and revalidate the > content against the Origin, delivering the content if revalidation > succeeds and not delivering the content if revalidation fails. > > For example, for any cached copy of the content after the "expiration > time" is reach, is a surrogate required to: > - Nothing more than whatever it is supposed to do in the example above an= d > use its normal cache expiration procedures to recovery the storage space > used like it would for "stale" content that does not have an explicit > expiration time? > - Actively keep track of cached content & its associated expiration time > and actively "de-link" (e.g. remove from the filesystem table) the cached > copy of the content? > - Actively keep track of cached content & its associated expiration time > and actively overwrite the storage sectors containing that content in bot= h > volatile & non-volatile storage? > > Thanks > Ben > _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni --_000_291CC3F9E50E7641901A54E85D0977C6518C23931AMAILR002maill_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Vishwas,

 

  One could certainly implement= an instantaneous purge by setting the

  exp= iration date to the current time, but I believe the one advantage

  of using the control interface was going to be some= type of explicit

  acknowledgement (synchro= nous or asynchronous) for purge complete.

  = It may be that this could be done another way as well (perhaps via

  the logging interface), but that was the distincti= on, as I recall.

 

thanx.

 

-- = Kevin J. Ma

 

<= div>

From: Vishwas Manral [mailto:vishwas.ietf@g= mail.com]
Sent: Thursday, August 04, 2011 3:50 PM
To: = Kevin J Ma
Cc: Ben Niven-Jenkins; Francois Le Faucheur; cdni@ietf= .org; draft-bertrand-cdni-use-cases@tools.ietf.org
Subject: Re: [= CDNi] comments on draft-bertrand-cdni-use-cases-02

 

Hi Kevin,

 =

I would think the data should have the = expiration times for sure.

&= nbsp;

Time based content, whi= ch uses control messages to purge can have issues which could be result of = connectivity. I am not sure why there should be any control messages for pu= rge at all.

 =

Thanks,

Vishwas

On Thu= , Aug 4, 2011 at 12:36 PM, Kevin J Ma <kevin= .ma@azukisystems.com> wrote:=

Hi Ben,

 I would expect tha= t once the expiration time is reached, all copies of the
 content w= ould be expunged from any surrogates/storage devices.

 I believ= e there was discussion a while back about whether to only use the
 = control interface to issue purge requests, or whether to use metadata to set expiration dates, or to allow both?  In the event of both, = I would
 think both functions should act the same, i.e., when the e= xpiration date
 is reached, it is just like a uCDN sent a purge req= uest.

thanx.

--  Kevin J. = Ma


> -----Original Me= ssage-----
> From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk]

> Sent: Thursday, August 04, 2011 10:23 AM
> To= : Francois Le Faucheur

&= gt; Cc: Kent Leung (kleung); cdni@ietf.org= ; draft-bertrand-cdni-use-
> cases@tools.ietf.org
> Subject: Re: [CDNi] comments on draft-= bertrand-cdni-use-cases-02
>
> Use Case authors, Colleagues,>
> On 28 Jul 2011, at 21:16, Francois Le Faucheur wrote:
>=
> > Kent and all,
> >
> > On 28 Jul 2011, at 16= :10, Kent Leung (kleung) wrote:
> >
> >> Hi Francois. =  Responding to comments related to the requirements draft
> >= > below.
> >>
> >>
> >>   o &nb= sp;an expiration time (i.e., the time at which the content files
> &g= t;>      should be expunged from all CDN storage).
>= ; >> "
> >> I understand this is saying that CDNI me= tadata need to include this
> >> expiration time (triggering ca= che removal) , in addition to
> deactivation
> >> time.> >> I don't think this is discussed in cdni-requirements yet. C= an you bring
> >> that up on the list with the cdni-reqts autho= rs?
> >>
> >> KL> I've seen references to conten= t expiration time (i.e. removal) in
> >> some drafts.  So = it seems to be needed in the CDNI Metadata.  Noted as
> >>= requirement (possibly part of availability window) unless others
> o= bject.
> >
> > FLF as an Individual: that works for me.>
> I'd like to understand the underlying requirement a bit bett= er as it's not
> clear to me what the expected behaviour of a surroga= te would be when
> receiving a request for the content after the &quo= t;expiration time" is reached
> as well as how the surrogate is = supposed to treat any cached copy of the
> content held in either vol= atile or non-volatile storage.
>
> For example, when receiving = a request for content after the "expiration
> time" is reac= hed, is a surrogate required to:
> - No longer deliver the content, e= ven if presented with a valid request to
> do?
> - Consider any= cached copy of the content as "stale" and revalidate the
>= content against the Origin, delivering the content if revalidation
>= succeeds and not delivering the content if revalidation fails.
>
= > For example, for any cached copy of the content after the "expira= tion
> time" is reach, is a surrogate required to:
> - Not= hing more than whatever it is supposed to do in the example above and
&g= t; use its normal cache expiration procedures to recovery the storage space=
> used like it would for "stale" content that does not hav= e an explicit
> expiration time?
> - Actively keep track of cac= hed content & its associated expiration time
> and actively "= ;de-link" (e.g. remove from the filesystem table) the cached
> c= opy of the content?
> - Actively keep track of cached content & i= ts associated expiration time
> and actively overwrite the storage se= ctors containing that content in both
> volatile & non-volatile s= torage?
>
> Thanks
> Ben
>

_________________= ______________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/cdni<= /a>

 <= /p>

= --_000_291CC3F9E50E7641901A54E85D0977C6518C23931AMAILR002maill_-- From kleung@cisco.com Thu Aug 4 14:10:04 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 901B921F8726 for ; Thu, 4 Aug 2011 14:10:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.378 X-Spam-Level: X-Spam-Status: No, score=-2.378 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sB0sVlYWfbLy for ; Thu, 4 Aug 2011 14:10:03 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 2171121F874F for ; Thu, 4 Aug 2011 14:10:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=kleung@cisco.com; l=18036; q=dns/txt; s=iport; t=1312492219; x=1313701819; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=yE2mRcBks71RYJfcg2lkB8WyY1J54fB72XxBo/7bTy8=; b=MiA3lU3AJ9B83n1p4YcT1lfqzsfR3xI1zXjoTmLGigcKhY/asofdgjmI nAHmW6QUxFSeHilZcjCImN5ZdbwbDEIqKBQF/xH2EwikzLjq1tnSteZ// YqHn1GcGzh7R07W135hi30uOC2QLj+Wn7JPW966DzWfVzdTdCgciUSsvJ E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsAAHQJO06rRDoH/2dsb2JhbABDgk2VQUWGcQGIJXeBQAEBAQECAQEBAQ8BCREDPgsFBwQCAQgRBAEBAQoGFwEGASAGHwkIAQEEARIIGodKBKJvAZ5jhWNfBIdakDGEW4cZ X-IronPort-AV: E=Sophos;i="4.67,319,1309737600"; d="scan'208,217";a="9800065" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-7.cisco.com with ESMTP; 04 Aug 2011 21:09:50 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p74L92gk024942; Thu, 4 Aug 2011 21:09:49 GMT Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 4 Aug 2011 14:09:48 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC52EA.D7AC92AF" Date: Thu, 4 Aug 2011 14:09:46 -0700 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC520F87639C@xmb-sjc-235.amer.cisco.com> In-Reply-To: <291CC3F9E50E7641901A54E85D0977C6518C23931A@MAILR002.mail.lan> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CDNi] comments on draft-bertrand-cdni-use-cases-02 Thread-Index: AcxS39EpYiuoWHSVRBG84Juvx79cgwACWRzwAAA4EpA= References: <1AC8E92C-3A69-4C80-A235-710DEF396A53@cisco.com><2979E38DD6FC6544B789C8DAD7BAFC520F72CD55@xmb-sjc-235.amer.cisco.com><0160D539-A630-4BCB-BC25-D50881FCFEDF@niven-jenkins.co.uk><291CC3F9E50E7641901A54E85D0977C6518C23927B@MAILR002.mail.lan> <291CC3F9E50E7641901A54E85D0977C6518C23931A@MAILR002.mail.lan> From: "Kent Leung (kleung)" To: "Kevin J Ma" , "Vishwas Manral" X-OriginalArrivalTime: 04 Aug 2011 21:09:48.0416 (UTC) FILETIME=[D7DAB000:01CC52EA] Cc: cdni@ietf.org, draft-bertrand-cdni-use-cases@tools.ietf.org Subject: Re: [CDNi] comments on draft-bertrand-cdni-use-cases-02 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 21:10:04 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC52EA.D7AC92AF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The CDNI Control Interfaces enables the removal of content asynchronously for reasons that could be administrative, legal, etc. which are not based on a scheduled time. For example, a content may have metadata to expire in one week. But some legal ruling requires the content to be removed from distribution & delivery before that time. Then the CDNI Control Interface can be used to accomplish that. The requirement for asynchronous removal is explicit acknowledgement. =20 Kent =20 From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Kevin J Ma Sent: Thursday, August 04, 2011 2:03 PM To: Vishwas Manral Cc: cdni@ietf.org; draft-bertrand-cdni-use-cases@tools.ietf.org Subject: Re: [CDNi] comments on draft-bertrand-cdni-use-cases-02 =20 Hi Vishwas, =20 One could certainly implement an instantaneous purge by setting the expiration date to the current time, but I believe the one advantage of using the control interface was going to be some type of explicit acknowledgement (synchronous or asynchronous) for purge complete. It may be that this could be done another way as well (perhaps via the logging interface), but that was the distinction, as I recall. =20 thanx. =20 -- Kevin J. Ma =20 From: Vishwas Manral [mailto:vishwas.ietf@gmail.com]=20 Sent: Thursday, August 04, 2011 3:50 PM To: Kevin J Ma Cc: Ben Niven-Jenkins; Francois Le Faucheur; cdni@ietf.org; draft-bertrand-cdni-use-cases@tools.ietf.org Subject: Re: [CDNi] comments on draft-bertrand-cdni-use-cases-02 =20 Hi Kevin, =20 I would think the data should have the expiration times for sure.=20 =20 Time based content, which uses control messages to purge can have issues which could be result of connectivity. I am not sure why there should be any control messages for purge at all. =20 Thanks, Vishwas On Thu, Aug 4, 2011 at 12:36 PM, Kevin J Ma wrote: Hi Ben, I would expect that once the expiration time is reached, all copies of the content would be expunged from any surrogates/storage devices. I believe there was discussion a while back about whether to only use the control interface to issue purge requests, or whether to use metadata to set expiration dates, or to allow both? In the event of both, I would think both functions should act the same, i.e., when the expiration date is reached, it is just like a uCDN sent a purge request. thanx. -- Kevin J. Ma > -----Original Message----- > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] > Sent: Thursday, August 04, 2011 10:23 AM > To: Francois Le Faucheur > Cc: Kent Leung (kleung); cdni@ietf.org; draft-bertrand-cdni-use- > cases@tools.ietf.org > Subject: Re: [CDNi] comments on draft-bertrand-cdni-use-cases-02 > > Use Case authors, Colleagues, > > On 28 Jul 2011, at 21:16, Francois Le Faucheur wrote: > > > Kent and all, > > > > On 28 Jul 2011, at 16:10, Kent Leung (kleung) wrote: > > > >> Hi Francois. Responding to comments related to the requirements draft > >> below. > >> > >> > >> o an expiration time (i.e., the time at which the content files > >> should be expunged from all CDN storage). > >> " > >> I understand this is saying that CDNI metadata need to include this > >> expiration time (triggering cache removal) , in addition to > deactivation > >> time. > >> I don't think this is discussed in cdni-requirements yet. Can you bring > >> that up on the list with the cdni-reqts authors? > >> > >> KL> I've seen references to content expiration time (i.e. removal) in > >> some drafts. So it seems to be needed in the CDNI Metadata. Noted as > >> requirement (possibly part of availability window) unless others > object. > > > > FLF as an Individual: that works for me. > > I'd like to understand the underlying requirement a bit better as it's not > clear to me what the expected behaviour of a surrogate would be when > receiving a request for the content after the "expiration time" is reached > as well as how the surrogate is supposed to treat any cached copy of the > content held in either volatile or non-volatile storage. > > For example, when receiving a request for content after the "expiration > time" is reached, is a surrogate required to: > - No longer deliver the content, even if presented with a valid request to > do? > - Consider any cached copy of the content as "stale" and revalidate the > content against the Origin, delivering the content if revalidation > succeeds and not delivering the content if revalidation fails. > > For example, for any cached copy of the content after the "expiration > time" is reach, is a surrogate required to: > - Nothing more than whatever it is supposed to do in the example above and > use its normal cache expiration procedures to recovery the storage space > used like it would for "stale" content that does not have an explicit > expiration time? > - Actively keep track of cached content & its associated expiration time > and actively "de-link" (e.g. remove from the filesystem table) the cached > copy of the content? > - Actively keep track of cached content & its associated expiration time > and actively overwrite the storage sectors containing that content in both > volatile & non-volatile storage? > > Thanks > Ben > _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni =20 ------_=_NextPart_001_01CC52EA.D7AC92AF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The CDNI Control Interfaces enables the removal of content = asynchronously for reasons that could be administrative, legal, etc. = which are not based on a scheduled time.  For example, a content = may have metadata to expire in one week.  But some legal ruling = requires the content to be removed from distribution & delivery = before that time.  Then the CDNI Control Interface can be used to = accomplish that.  The requirement for asynchronous removal is = explicit acknowledgement.

 

Kent

 

From:= = cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of = Kevin J Ma
Sent: Thursday, August 04, 2011 2:03 = PM
To: Vishwas Manral
Cc: cdni@ietf.org; = draft-bertrand-cdni-use-cases@tools.ietf.org
Subject: Re: = [CDNi] comments on = draft-bertrand-cdni-use-cases-02

 

Hi = Vishwas,

 

  One could = certainly implement an instantaneous purge by setting = the

  expiration = date to the current time, but I believe the one = advantage

  of using the = control interface was going to be some type of = explicit

  = acknowledgement (synchronous or asynchronous) for purge = complete.

  It may be = that this could be done another way as well (perhaps = via

  the logging = interface), but that was the distinction, as I = recall.

 

thanx.

 

--  Kevin J. = Ma

 

From:= = Vishwas Manral [mailto:vishwas.ietf@gmail.com]
Sent: = Thursday, August 04, 2011 3:50 PM
To: Kevin J Ma
Cc: = Ben Niven-Jenkins; Francois Le Faucheur; cdni@ietf.org; = draft-bertrand-cdni-use-cases@tools.ietf.org
Subject: Re: = [CDNi] comments on = draft-bertrand-cdni-use-cases-02

 

Hi = Kevin,

 

I = would think the data should have the expiration times for sure. =

 

Time based content, which uses control messages to = purge can have issues which could be result of connectivity. I am not = sure why there should be any control messages for purge at = all.

 

Thanks,

Vishwas

On Thu, Aug 4, 2011 at 12:36 PM, Kevin J Ma <kevin.ma@azukisystems.com> = wrote:

Hi Ben,

 I would = expect that once the expiration time is reached, all copies of = the
 content would be expunged from any surrogates/storage = devices.

 I believe there was discussion a while back about = whether to only use the
 control interface to issue purge = requests, or whether to use metadata to
 set expiration dates, = or to allow both?  In the event of both, I would
 think = both functions should act the same, i.e., when the expiration = date
 is reached, it is just like a uCDN sent a purge = request.

thanx.

-- =  Kevin J. Ma


> -----Original Message-----
> From: Ben = Niven-Jenkins [mailto:ben@niven-jenkins.co.uk]=

> Sent: Thursday, August = 04, 2011 10:23 AM
> To: Francois Le = Faucheur

> Cc: = Kent Leung (kleung); cdni@ietf.org; = draft-bertrand-cdni-use-
> cases@tools.ietf.org
> = Subject: Re: [CDNi] comments on = draft-bertrand-cdni-use-cases-02
>
> Use Case authors, = Colleagues,
>
> On 28 Jul 2011, at 21:16, Francois Le = Faucheur wrote:
>
> > Kent and all,
> >
> = > On 28 Jul 2011, at 16:10, Kent Leung (kleung) wrote:
> = >
> >> Hi Francois.  Responding to comments related = to the requirements draft
> >> below.
> = >>
> >>
> >>   o  an expiration = time (i.e., the time at which the content files
> >>   =    should be expunged from all CDN storage).
> >> = "
> >> I understand this is saying that CDNI metadata = need to include this
> >> expiration time (triggering cache = removal) , in addition to
> deactivation
> >> = time.
> >> I don't think this is discussed in = cdni-requirements yet. Can you bring
> >> that up on the = list with the cdni-reqts authors?
> >>
> >> = KL> I've seen references to content expiration time (i.e. removal) = in
> >> some drafts.  So it seems to be needed in the = CDNI Metadata.  Noted as
> >> requirement (possibly = part of availability window) unless others
> object.
> = >
> > FLF as an Individual: that works for = me.
>
> I'd like to understand the underlying requirement a = bit better as it's not
> clear to me what the expected behaviour = of a surrogate would be when
> receiving a request for the content = after the "expiration time" is reached
> as well as how = the surrogate is supposed to treat any cached copy of the
> = content held in either volatile or non-volatile storage.
>
> = For example, when receiving a request for content after the = "expiration
> time" is reached, is a surrogate required = to:
> - No longer deliver the content, even if presented with a = valid request to
> do?
> - Consider any cached copy of the = content as "stale" and revalidate the
> content against = the Origin, delivering the content if revalidation
> succeeds and = not delivering the content if revalidation fails.
>
> For = example, for any cached copy of the content after the = "expiration
> time" is reach, is a surrogate required = to:
> - Nothing more than whatever it is supposed to do in the = example above and
> use its normal cache expiration procedures to = recovery the storage space
> used like it would for = "stale" content that does not have an explicit
> = expiration time?
> - Actively keep track of cached content & = its associated expiration time
> and actively "de-link" = (e.g. remove from the filesystem table) the cached
> copy of the = content?
> - Actively keep track of cached content & its = associated expiration time
> and actively overwrite the storage = sectors containing that content in both
> volatile & = non-volatile storage?
>
> Thanks
> = Ben
>

_______________________________________________
CDN= i mailing list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/cdni

 

------_=_NextPart_001_01CC52EA.D7AC92AF-- From vishwas.ietf@gmail.com Thu Aug 4 14:53:17 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BD1111E807D for ; Thu, 4 Aug 2011 14:53:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.913 X-Spam-Level: X-Spam-Status: No, score=-2.913 tagged_above=-999 required=5 tests=[AWL=0.685, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6XNVrB1RheBy for ; Thu, 4 Aug 2011 14:53:16 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id EB57011E807C for ; Thu, 4 Aug 2011 14:53:04 -0700 (PDT) Received: by qwc23 with SMTP id 23so1565521qwc.31 for ; Thu, 04 Aug 2011 14:53:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Q4W+IDavzY0ShqYGfbruUOueuRBIC60os81VRjT/JNo=; b=tPXLDVL4zY8mmaihlyzNKVu4zEMn7smeiJPRoOhcq08BB6CB45lUjTYeF86ApM8WH0 BOfANei7X1y11bFqLYvp3NMje9Faodgy2hnOC6ApZ5pTqJgiMmGDmJQN+F9KwVAOVwvC pVB7ddwrdTfpz4m8qgWoc2S4wsXr8oimFD6Dw= MIME-Version: 1.0 Received: by 10.229.107.5 with SMTP id z5mr1063773qco.229.1312494796058; Thu, 04 Aug 2011 14:53:16 -0700 (PDT) Received: by 10.229.65.91 with HTTP; Thu, 4 Aug 2011 14:53:16 -0700 (PDT) In-Reply-To: <2979E38DD6FC6544B789C8DAD7BAFC520F87639C@xmb-sjc-235.amer.cisco.com> References: <1AC8E92C-3A69-4C80-A235-710DEF396A53@cisco.com> <2979E38DD6FC6544B789C8DAD7BAFC520F72CD55@xmb-sjc-235.amer.cisco.com> <0160D539-A630-4BCB-BC25-D50881FCFEDF@niven-jenkins.co.uk> <291CC3F9E50E7641901A54E85D0977C6518C23927B@MAILR002.mail.lan> <291CC3F9E50E7641901A54E85D0977C6518C23931A@MAILR002.mail.lan> <2979E38DD6FC6544B789C8DAD7BAFC520F87639C@xmb-sjc-235.amer.cisco.com> Date: Thu, 4 Aug 2011 14:53:16 -0700 Message-ID: From: Vishwas Manral To: "Kent Leung (kleung)" Content-Type: multipart/alternative; boundary=0023544711bc16afa104a9b50232 Cc: cdni@ietf.org, draft-bertrand-cdni-use-cases@tools.ietf.org Subject: Re: [CDNi] comments on draft-bertrand-cdni-use-cases-02 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 21:53:17 -0000 --0023544711bc16afa104a9b50232 Content-Type: text/plain; charset=ISO-8859-1 Agree with you there Kent. But the control interface is not the default mechanism for sure, its used as an exception. -Vishwas On Thu, Aug 4, 2011 at 2:09 PM, Kent Leung (kleung) wrote: > The CDNI Control Interfaces enables the removal of content asynchronously > for reasons that could be administrative, legal, etc. which are not based on > a scheduled time. For example, a content may have metadata to expire in one > week. But some legal ruling requires the content to be removed from > distribution & delivery before that time. Then the CDNI Control Interface > can be used to accomplish that. The requirement for asynchronous removal is > explicit acknowledgement.**** > > ** ** > > Kent**** > > ** ** > > *From:* cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] *On Behalf Of > *Kevin J Ma > *Sent:* Thursday, August 04, 2011 2:03 PM > *To:* Vishwas Manral > *Cc:* cdni@ietf.org; draft-bertrand-cdni-use-cases@tools.ietf.org > > *Subject:* Re: [CDNi] comments on draft-bertrand-cdni-use-cases-02**** > > ** ** > > Hi Vishwas,**** > > ** ** > > One could certainly implement an instantaneous purge by setting the**** > > expiration date to the current time, but I believe the one advantage**** > > of using the control interface was going to be some type of explicit**** > > acknowledgement (synchronous or asynchronous) for purge complete.**** > > It may be that this could be done another way as well (perhaps via**** > > the logging interface), but that was the distinction, as I recall.**** > > ** ** > > thanx.**** > > ** ** > > -- Kevin J. Ma**** > > ** ** > > *From:* Vishwas Manral [mailto:vishwas.ietf@gmail.com] > *Sent:* Thursday, August 04, 2011 3:50 PM > *To:* Kevin J Ma > *Cc:* Ben Niven-Jenkins; Francois Le Faucheur; cdni@ietf.org; > draft-bertrand-cdni-use-cases@tools.ietf.org > *Subject:* Re: [CDNi] comments on draft-bertrand-cdni-use-cases-02**** > > ** ** > > Hi Kevin,**** > > **** > > I would think the data should have the expiration times for sure. **** > > **** > > Time based content, which uses control messages to purge can have issues > which could be result of connectivity. I am not sure why there should be any > control messages for purge at all.**** > > **** > > Thanks,**** > > Vishwas**** > > On Thu, Aug 4, 2011 at 12:36 PM, Kevin J Ma > wrote:**** > > Hi Ben, > > I would expect that once the expiration time is reached, all copies of the > content would be expunged from any surrogates/storage devices. > > I believe there was discussion a while back about whether to only use the > control interface to issue purge requests, or whether to use metadata to > set expiration dates, or to allow both? In the event of both, I would > think both functions should act the same, i.e., when the expiration date > is reached, it is just like a uCDN sent a purge request. > > thanx. > > -- Kevin J. Ma**** > > > > -----Original Message----- > > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk]**** > > > Sent: Thursday, August 04, 2011 10:23 AM > > To: Francois Le Faucheur**** > > > Cc: Kent Leung (kleung); cdni@ietf.org; draft-bertrand-cdni-use- > > cases@tools.ietf.org > > Subject: Re: [CDNi] comments on draft-bertrand-cdni-use-cases-02 > > > > Use Case authors, Colleagues, > > > > On 28 Jul 2011, at 21:16, Francois Le Faucheur wrote: > > > > > Kent and all, > > > > > > On 28 Jul 2011, at 16:10, Kent Leung (kleung) wrote: > > > > > >> Hi Francois. Responding to comments related to the requirements draft > > >> below. > > >> > > >> > > >> o an expiration time (i.e., the time at which the content files > > >> should be expunged from all CDN storage). > > >> " > > >> I understand this is saying that CDNI metadata need to include this > > >> expiration time (triggering cache removal) , in addition to > > deactivation > > >> time. > > >> I don't think this is discussed in cdni-requirements yet. Can you > bring > > >> that up on the list with the cdni-reqts authors? > > >> > > >> KL> I've seen references to content expiration time (i.e. removal) in > > >> some drafts. So it seems to be needed in the CDNI Metadata. Noted as > > >> requirement (possibly part of availability window) unless others > > object. > > > > > > FLF as an Individual: that works for me. > > > > I'd like to understand the underlying requirement a bit better as it's > not > > clear to me what the expected behaviour of a surrogate would be when > > receiving a request for the content after the "expiration time" is > reached > > as well as how the surrogate is supposed to treat any cached copy of the > > content held in either volatile or non-volatile storage. > > > > For example, when receiving a request for content after the "expiration > > time" is reached, is a surrogate required to: > > - No longer deliver the content, even if presented with a valid request > to > > do? > > - Consider any cached copy of the content as "stale" and revalidate the > > content against the Origin, delivering the content if revalidation > > succeeds and not delivering the content if revalidation fails. > > > > For example, for any cached copy of the content after the "expiration > > time" is reach, is a surrogate required to: > > - Nothing more than whatever it is supposed to do in the example above > and > > use its normal cache expiration procedures to recovery the storage space > > used like it would for "stale" content that does not have an explicit > > expiration time? > > - Actively keep track of cached content & its associated expiration time > > and actively "de-link" (e.g. remove from the filesystem table) the cached > > copy of the content? > > - Actively keep track of cached content & its associated expiration time > > and actively overwrite the storage sectors containing that content in > both > > volatile & non-volatile storage? > > > > Thanks > > Ben > > > > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni**** > > ** ** > --0023544711bc16afa104a9b50232 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Agree with you there Kent.
=A0
But the control interface is not the default mechanism for sure, its u= sed as an exception.
=A0
-Vishwas
On Thu, Aug 4, 2011 at 2:09 PM, Kent Leung (kleu= ng) <kleung@cisco.= com> wrote:

The = CDNI Control Interfaces enables the removal of content asynchronously for r= easons that could be administrative, legal, etc. which are not based on a s= cheduled time.=A0 For example, a content may have metadata to expire in one= week.=A0 But some legal ruling requires the content to be removed from dis= tribution & delivery before that time.=A0 Then the CDNI Control Interfa= ce can be used to accomplish that.=A0 The requirement for asynchronous remo= val is explicit acknowledgement.

<= /u>=A0

Kent=

<= /u>=A0

From:<= span style=3D"FONT-SIZE: 10pt"> cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf O= f Kevin J Ma
Sent: Thursday, August 04, 2011 2:03 PM
To: Vishwas Manral=
Cc: cdni@ietf= .org; draft-bertrand-cdni-use-cases@tools.ietf.org=20


Subject: Re: [CDNi] comments on draft-bertrand= -cdni-use-cases-02

=A0

Hi Vishwas,

=A0

=A0 One could certainly implement an instantaneous purge by= setting the

=A0 expiration date to the current time, but I believe the = one advantage

=A0 of using the control interface was going to be some typ= e of explicit

=A0 acknowledgement (synchronous or asynchronous) for purge= complete.

=A0 It may be that this could be done another way as well (= perhaps via

=A0 the logging interface), but that was the distinction, a= s I recall.

=A0

thanx.

=A0

--=A0 Kevin J. Ma

=A0

From:<= span style=3D"FONT-SIZE: 10pt"> Vishwas Manral [mailto:vishwas.ietf@gmail.com]
= Sent: Thursday, August 04, 2011 3:50 PM
To: Kevin J Ma
Cc: Ben Niven-Jenkins; Francois Le Faucheur= ; cdni@ietf.org; draft-bertrand-cdni-use-cases@tools.ietf.org
Subject: Re: [CDNi] comments on draft-bertrand-cdni-use-cases-02<= /u>

=A0

Hi Kevin,

=A0

I would think the data should have the expiration ti= mes for sure.

=A0

Time based content, which uses control messages to p= urge can have issues which could be result of connectivity. I am not sure w= hy there should be any control messages for purge at all.

=A0

Thanks,

Vishwas

On Thu, Aug 4, 2011 at 12:36 PM, Kevin J Ma <kevin.ma@azukisystems.com> wrote:<= u>

Hi Ben,

=A0I would expect that once the expir= ation time is reached, all copies of the
=A0content would be expunged fr= om any surrogates/storage devices.

=A0I believe there was discussion= a while back about whether to only use the
=A0control interface to issue purge requests, or whether to use metadata to=
=A0set expiration dates, or to allow both? =A0In the event of both, I w= ould
=A0think both functions should act the same, i.e., when the expirat= ion date
=A0is reached, it is just like a uCDN sent a purge request.

thanx.
-- =A0Kevin J. Ma=


> -----Original Message-----
> From: Be= n Niven-Jenkins [mailto:ben@niven-jenkins.co.uk]

> Sent: Thursday, August 04, 2011 10:23 AM
>= ; To: Francois Le Faucheur

> Cc: Kent Leung (kleung); cdni@ietf.org; draft-bertrand-cdni-use-> cases@tools= .ietf.org
> Subject: Re: [CDNi] comments on draft-bertrand-cdni-use-cases-02
&g= t;
> Use Case authors, Colleagues,
>
> On 28 Jul 2011, at= 21:16, Francois Le Faucheur wrote:
>
> > Kent and all,
> >
> > On 28 Jul 2011, at 16:10, Kent Leung (kleung) wrote:=
> >
> >> Hi Francois. =A0Responding to comments relat= ed to the requirements draft
> >> below.
> >>
> >>
> >> =A0 o =A0an expiration time (i.e., the time = at which the content files
> >> =A0 =A0 =A0should be expunged f= rom all CDN storage).
> >> "
> >> I understand= this is saying that CDNI metadata need to include this
> >> expiration time (triggering cache removal) , in addition to> deactivation
> >> time.
> >> I don't thi= nk this is discussed in cdni-requirements yet. Can you bring
> >&g= t; that up on the list with the cdni-reqts authors?
> >>
> >> KL> I've seen references to content e= xpiration time (i.e. removal) in
> >> some drafts. =A0So it see= ms to be needed in the CDNI Metadata. =A0Noted as
> >> requirem= ent (possibly part of availability window) unless others
> object.
> >
> > FLF as an Individual: that works for= me.
>
> I'd like to understand the underlying requirement = a bit better as it's not
> clear to me what the expected behaviou= r of a surrogate would be when
> receiving a request for the content after the "expiration time&qu= ot; is reached
> as well as how the surrogate is supposed to treat an= y cached copy of the
> content held in either volatile or non-volatil= e storage.
>
> For example, when receiving a request for content after the &q= uot;expiration
> time" is reached, is a surrogate required to:> - No longer deliver the content, even if presented with a valid requ= est to
> do?
> - Consider any cached copy of the content as "stale&q= uot; and revalidate the
> content against the Origin, delivering the = content if revalidation
> succeeds and not delivering the content if = revalidation fails.
>
> For example, for any cached copy of the content after the &quo= t;expiration
> time" is reach, is a surrogate required to:
&g= t; - Nothing more than whatever it is supposed to do in the example above a= nd
> use its normal cache expiration procedures to recovery the storage spa= ce
> used like it would for "stale" content that does not h= ave an explicit
> expiration time?
> - Actively keep track of c= ached content & its associated expiration time
> and actively "de-link" (e.g. remove from the filesystem tabl= e) the cached
> copy of the content?
> - Actively keep track of= cached content & its associated expiration time
> and actively o= verwrite the storage sectors containing that content in both
> volatile & non-volatile storage?
>
> Thanks
> Be= n
>

_______________________________________________
CDNi ma= iling list
CDNi@ietf.= org
ht= tps://www.ietf.org/mailman/listinfo/cdni

<= /div>

=A0

<= /blockquote>

--0023544711bc16afa104a9b50232-- From ben@niven-jenkins.co.uk Thu Aug 4 16:08:40 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 053D221F8749 for ; Thu, 4 Aug 2011 16:08:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.56 X-Spam-Level: X-Spam-Status: No, score=-103.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2BKum+sYcmvj for ; Thu, 4 Aug 2011 16:08:39 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id 2610A21F871E for ; Thu, 4 Aug 2011 16:08:39 -0700 (PDT) Received: from cpc10-cmbg15-2-0-cust121.5-4.cable.virginmedia.com ([86.30.246.122] helo=[192.168.0.3]) by mail10.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1Qp725-0007hU-UC; Fri, 05 Aug 2011 00:08:54 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: <2979E38DD6FC6544B789C8DAD7BAFC520F876312@xmb-sjc-235.amer.cisco.com> Date: Fri, 5 Aug 2011 00:08:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <39875C0A-F9D4-433A-8F76-DBE04816B6FF@niven-jenkins.co.uk> References: <1AC8E92C-3A69-4C80-A235-710DEF396A53@cisco.com> <2979E38DD6FC6544B789C8DAD7BAFC520F72CD55@xmb-sjc-235.amer.cisco.com> <0160D539-A630-4BCB-BC25-D50881FCFEDF@niven-jenkins.co.uk> <2979E38DD6FC6544B789C8DAD7BAFC520F876312@xmb-sjc-235.amer.cisco.com> To: "Kent Leung (kleung)" , Kevin J Ma X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: cdni@ietf.org, draft-bertrand-cdni-use-cases@tools.ietf.org Subject: Re: [CDNi] comments on draft-bertrand-cdni-use-cases-02 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 23:08:40 -0000 Kent, Kevin, On 4 Aug 2011, at 20:26, Kent Leung (kleung) wrote: > Hi Ben. In general, I think that content that has expired should be > treated similarly as de-activated except that content is removed from > the Surrogate. The content availability window has to work in > conjunction with cache aging function. So there shouldn't be > requirements to the level of implementation. On 4 Aug 2011, at 20:36, Kevin J Ma wrote: > I would expect that once the expiration time is reached, all copies = of the > content would be expunged from any surrogates/storage devices. I'm starting to worry that we are creating new requirements on CDNs in = general rather than reflecting existing CDN requirements into CDNI. For example, content that expires "naturally" (e.g. due to Cache-Control = headers) is not automatically "expunged" and therefore I am struggling a = little to understand why content that has an associated availability = window is required to be "expunged" when that availability window = expires. I have not personally encountered a CSP that has such a = requirement. Ben > -----Original Message----- > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk]=20 > Sent: Thursday, August 04, 2011 7:23 AM > To: Francois Le Faucheur (flefauch) > Cc: Kent Leung (kleung); cdni@ietf.org; > draft-bertrand-cdni-use-cases@tools.ietf.org > Subject: Re: [CDNi] comments on draft-bertrand-cdni-use-cases-02 >=20 > Use Case authors, Colleagues, >=20 > On 28 Jul 2011, at 21:16, Francois Le Faucheur wrote: >=20 >> Kent and all, >>=20 >> On 28 Jul 2011, at 16:10, Kent Leung (kleung) wrote: >>=20 >>> Hi Francois. Responding to comments related to the requirements > draft >>> below. >>>=20 >>>=20 >>> o an expiration time (i.e., the time at which the content files >>> should be expunged from all CDN storage). >>> " >>> I understand this is saying that CDNI metadata need to include this >>> expiration time (triggering cache removal) , in addition to > deactivation >>> time.=20 >>> I don't think this is discussed in cdni-requirements yet. Can you > bring >>> that up on the list with the cdni-reqts authors? >>>=20 >>> KL> I've seen references to content expiration time (i.e. removal) = in >>> some drafts. So it seems to be needed in the CDNI Metadata. Noted > as >>> requirement (possibly part of availability window) unless others > object. >>=20 >> FLF as an Individual: that works for me. >=20 > I'd like to understand the underlying requirement a bit better as it's > not clear to me what the expected behaviour of a surrogate would be = when > receiving a request for the content after the "expiration time" is > reached as well as how the surrogate is supposed to treat any cached > copy of the content held in either volatile or non-volatile storage. >=20 > For example, when receiving a request for content after the = "expiration > time" is reached, is a surrogate required to: > - No longer deliver the content, even if presented with a valid = request > to do? > - Consider any cached copy of the content as "stale" and revalidate = the > content against the Origin, delivering the content if revalidation > succeeds and not delivering the content if revalidation fails. >=20 > For example, for any cached copy of the content after the "expiration > time" is reach, is a surrogate required to: > - Nothing more than whatever it is supposed to do in the example above > and use its normal cache expiration procedures to recovery the storage > space used like it would for "stale" content that does not have an > explicit expiration time?=20 > - Actively keep track of cached content & its associated expiration = time > and actively "de-link" (e.g. remove from the filesystem table) the > cached copy of the content?=20 > - Actively keep track of cached content & its associated expiration = time > and actively overwrite the storage sectors containing that content in > both volatile & non-volatile storage? >=20 > Thanks > Ben >=20 >=20 From ben@niven-jenkins.co.uk Thu Aug 4 16:19:49 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F29621F86C4 for ; Thu, 4 Aug 2011 16:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.565 X-Spam-Level: X-Spam-Status: No, score=-103.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sc4EeAPr7Hqi for ; Thu, 4 Aug 2011 16:19:48 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id 253A611E807C for ; Thu, 4 Aug 2011 16:19:43 -0700 (PDT) Received: from cpc10-cmbg15-2-0-cust121.5-4.cable.virginmedia.com ([86.30.246.122] helo=[192.168.0.3]) by mail10.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1Qp7Co-00084y-5x; Fri, 05 Aug 2011 00:19:58 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: Date: Fri, 5 Aug 2011 00:19:56 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3C17706D-6CE3-4F69-8E75-D7161C845534@niven-jenkins.co.uk> References: <4E3A6BEE.4080301@edgeware.tv> <8AF4C086-7E25-4931-9BF7-7DC7F44A9D2C@niven-jenkins.co.uk> <4E3A7178.6080400@edgeware.tv> <1CA25301D2219F40B3AA37201F0EACD11360E6C4@PACDCEXMB05.cable.comcast.com> <4E3AB142.4030103@edgeware.tv> <70AE7D15-69E5-40FE-A4EE-F6BF5E01C6A9@verivue.com> <291CC3F9E50E7641901A54E85D0977C6518C23922F@MAILR002.mail.lan> To: "Peterson, Larry" X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: "cdni@ietf.org" Subject: Re: [CDNi] upstream cdn enforce content policies X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 23:19:49 -0000 Larry, On 4 Aug 2011, at 20:14, Peterson, Larry wrote: > Good questions... In my mind, the metadata interface is used to = delegate > responsibility from uCDN to dCDN. The CSP still has to trust that the = dCDN > behaves according to the metadata it's passed. Alternatively, the CSP = trusts > that the uCDN -- with which it has a contractual agreement -- to "stay = in > the loop" and keep a tighter leash on what the dCDN does (e.g., make a > decision on each request it routes, issues purge commands when = necessary, > and adds cache directives as necessary). Yes, we have to trust the = dCDN to > observe cache directives, so you could argue both strategies involve = trusting > the dCDN, but you could also argue that the latter approach narrows = the > window of vulnerability if trust is violated. Can you expand on that argument because I can't see how the latter = approach narrows the window of vulnerability without introducing an = undesirable level of coupling between the upstream & downstream CDNs? Thanks Ben >=20 > As to the position that "we just as well define the interface in case = some pair > of CDNs want to use it"... sure, but every bit of mechanism comes at = some cost > in complexity. >=20 > Larry >=20 > On Aug 4, 2011, at 3:00 PM, Kevin J Ma wrote: >=20 >>> The question is: does interconnection imply that uCDN further = delegates that >>> responsibility for enforcing access control policy to the dCDN, or = does the uCDN >>> retain that locus of control for itself.=20 >>=20 >> I think the issue is more the threat that a CSP may have an agreement = with >> the uCDN, which it has paid for, which may not be enforceable through = dCDNs. >> It is not clear that a uCDN can always enforce those policies. It is = not that >> hard to figure out where the content is really coming from (i.e., the = dCDN). >> Will CSPs, who tend to be risk averse, just disallow delegation? >>=20 >> Sticking with the minimalist approach, I still think there is value = in a >> standardized method of exchanging opaque metadata. If some CDNs = agree=20 >> amongst themselves (outside of CDNI) to enforce policies, they will = most >> likely need to exchange metadata? Having a well defined protocol to = do so >> seems like an important first step? >>=20 >>=20 >>> -----Original Message----- >>> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf = Of >>> Peterson, Larry >>> Sent: Thursday, August 04, 2011 11:31 AM >>> To: Johan Rydberg >>> Cc: cdni@ietf.org >>> Subject: Re: [CDNi] upstream cdn enforce content policies >>>=20 >>> Picking up on Johan's minimized scope thread... >>>=20 >>> I too have been puzzled by the metadata interface. If you read the >>> language >>> carefully, you'll see there's a caveat that this interface might = exist in >>> various >>> forms, presumably as a combination of other interfaces and = mechanisms, >>> for example: >>> o the uCDN doesn't route the request to the dCDN unless policy = permits; >>> o the uCDN sets HTTP caching directives consistent with policy and = the >>> dCDN obeys those directives; and >>> o the uCDN invokes purge on dCDN should the policy change. >>>=20 >>> But that generous interpretation aside, the high level issue seems = to be >>> how >>> access control policy is enforced. In a single CDN it's natural for = this >>> policy to >>> be enforced by the CDN, and there's likely a metadata-like interface = by >>> which >>> the CSP expresses this policy to that CDN. >>>=20 >>> The question is: does interconnection imply that uCDN further = delegates >>> that >>> responsibility for enforcing access control policy to the dCDN, or = does >>> the uCDN >>> retain that locus of control for itself. The later design, which >>> essentially treats >>> the dCDN as it would any other cache (at least with respect to = metadata), >>> seems >>> the simplest to me. >>>=20 >>> Larry >>>=20 >>> On Aug 4, 2011, at 10:48 AM, Johan Rydberg wrote: >>>=20 >>>> Richard, >>>>=20 >>>> I just got a bit scared when I saw discussions about features that = "may >>>> be good to have" >>>> or "it would be nice to support". >>>>=20 >>>> I guess all I wanted to say was that everyone would benefit from a >>>> minimized scoop. >>>>=20 >>>> On 8/4/11 4:34 PM, Woundy, Richard wrote: >>>>> A couple of observations, as an individual and not a working group >>> chair. >>>>>=20 >>>>>=20 >>>>>> Instead of constructing a complex metadata exchange protocol >>>>>>=20 >>>>> How about we construct a *simple* metadata exchange protocol? :) >>>>>=20 >>>>> I believe we are anticipating this protocol to be XML/JSON over = HTTP. >>>>>=20 >>>>>=20 >>>>>> I have a feeling that if the interconnect protocols are not = limited in >>> scope, this CDNI effort will either (1) fail or (2) be in some = "design >>> phase" for ever. >>>>>>=20 >>>>> CDNI was approved as a WG in late June. Now it is early August and >>> we're already in danger of failing? Hmmm. >>>>>=20 >>>>> It feels to me like we are debating theoretical scenarios. Johan, = if >>> you feel strongly about eliminating this interface, maybe you could = write >>> up your proposal as an internet-draft that we can discuss and = debate? We >>> also need to ensure that your proposal meets the use cases = identified by >>> this group. >>>>>=20 >>>>> -- Rich >>>>>=20 >>>>> -----Original Message----- >>>>> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On = Behalf Of >>> Johan Rydberg >>>>> Sent: Thursday, August 04, 2011 6:16 AM >>>>> To: Ben Niven-Jenkins >>>>> Cc: cdni@ietf.org >>>>> Subject: Re: [CDNi] upstream cdn enforce content policies >>>>>=20 >>>>> On 8/4/11 12:10 PM, Ben Niven-Jenkins wrote: >>>>>=20 >>>>>> Johan, >>>>>>=20 >>>>>> On 4 Aug 2011, at 10:52, Johan Rydberg wrote: >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>> After following the discussions for a while, I have a question: >>>>>>>=20 >>>>>>> Instead of constructing a complex metadata exchange protocol, >>>>>>> why not force the upstream CDN to enforce any prolicy rules that >>>>>>> the CSP has put on the content? >>>>>>>=20 >>>>>>>=20 >>>>>> That would not provide sufficient coverage to ensure that the = policy >>> is enforced as clients may attempt to request content directly from = a >>> downstream CDN, bypassing the upstream CDN. >>>>>>=20 >>>>>>=20 >>>>> There must be ways to make sure that the client first passes = through >>> the >>>>> upstream >>>>> CDN. >>>>>=20 >>>>> I have a feeling that if the interconnect protocols are not = limited in >>>>> scope, this >>>>> CDNI effort will either (1) fail or (2) be in some "design phase" = for >>> ever. >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>> In the case of DNS-based routing, the CDN can answer the DNS >>>>>>> lookup with the address of one of its own CDNI request routers >>>>>>> that will enforce any policies before redirecting (HTTP 302) to >>>>>>> a downstream CDN. >>>>>>>=20 >>>>>>> The upside to this is that redirects between CDNs will always be >>>>>>> HTTP 302, regardless if the initial mechanism was DNS-based. >>>>>>> Also, the complex metadata protocol can be elimited, minimizing >>>>>>> the scope of the CDNI work. >>>>>>>=20 >>>>>>>=20 >>>>>> Even if one could avoid the need for a downstream CDN to apply = some >>> policies, this wouldn't eliminate the need to exchange CDNI metadata = as >>> other CDNI metadata such as rate limiting, whether an encrypted = channel is >>> required, where to obtain the content from etc. is still required. >>>>>>=20 >>>>>>=20 >>>>> It sounds like most of those could be folded into the request = routing >>>>> protocol. >>>>> Rate limiting and encryption might not be attributes of the = content, >>> but >>>>> rather >>>>> of the client. (Some customers pay more, and get a higher bitrate = for >>>>> example) >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> CDNi mailing list >>>>> CDNi@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/cdni >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> CDNi mailing list >>>> CDNi@ietf.org >>>> https://www.ietf.org/mailman/listinfo/cdni >>>=20 >>> _______________________________________________ >>> CDNi mailing list >>> CDNi@ietf.org >>> https://www.ietf.org/mailman/listinfo/cdni >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From kevin.ma@azukisystems.com Thu Aug 4 17:23:03 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87A8F21F869D for ; Thu, 4 Aug 2011 17:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.368 X-Spam-Level: X-Spam-Status: No, score=-2.368 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-LO0O-NQlrH for ; Thu, 4 Aug 2011 17:23:02 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 7FBF721F867F for ; Thu, 4 Aug 2011 17:23:02 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 55194417088; Thu, 4 Aug 2011 20:23:18 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB024.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 93DBF416D9F; Thu, 4 Aug 2011 20:23:17 -0400 (EDT) Received: from MAILR002.mail.lan ([10.110.18.16]) by HUB024.mail.lan ([10.110.17.24]) with mapi; Thu, 4 Aug 2011 20:23:03 -0400 From: Kevin J Ma To: Ben Niven-Jenkins , "Kent Leung (kleung)" Date: Thu, 4 Aug 2011 20:23:14 -0400 Thread-Topic: [CDNi] comments on draft-bertrand-cdni-use-cases-02 Thread-Index: AcxS+33HbheZhUWvRqWx+5CE4tCj3AAB4ITw Message-ID: <291CC3F9E50E7641901A54E85D0977C6518C239372@MAILR002.mail.lan> References: <1AC8E92C-3A69-4C80-A235-710DEF396A53@cisco.com> <2979E38DD6FC6544B789C8DAD7BAFC520F72CD55@xmb-sjc-235.amer.cisco.com> <0160D539-A630-4BCB-BC25-D50881FCFEDF@niven-jenkins.co.uk> <2979E38DD6FC6544B789C8DAD7BAFC520F876312@xmb-sjc-235.amer.cisco.com> <39875C0A-F9D4-433A-8F76-DBE04816B6FF@niven-jenkins.co.uk> In-Reply-To: <39875C0A-F9D4-433A-8F76-DBE04816B6FF@niven-jenkins.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" , "draft-bertrand-cdni-use-cases@tools.ietf.org" Subject: Re: [CDNi] comments on draft-bertrand-cdni-use-cases-02 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 00:23:03 -0000 Hi Ben, > I'm starting to worry that we are creating new requirements on CDNs in > general rather than reflecting existing CDN requirements into CDNI. =20 I will just reiterate that I do not necessarily see a need for an explicit requirement, but I do think this may be a feature that interconnected CDNs may wish to support and therefore need to be able to exchange metadata abou= t, and/or advertise their support for. > I am struggling a > little to understand why content that has an associated availability > window is required to be "expunged" when that availability window expires= . I suppose it depends on the paranoia level of the CSP? I have delt with CS= Ps who requested content purge at a certain time, when they nolonger have the rights to distribute it. One consideration might be the case where a CDN d= oes not support availability windows, but it does support expiration/purge? thanx. -- Kevin J. Ma > -----Original Message----- > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] > Sent: Thursday, August 04, 2011 7:09 PM > To: Kent Leung (kleung); Kevin J Ma > Cc: Francois Le Faucheur (flefauch); cdni@ietf.org; draft-bertrand-cdni- > use-cases@tools.ietf.org > Subject: Re: [CDNi] comments on draft-bertrand-cdni-use-cases-02 >=20 > Kent, Kevin, >=20 > On 4 Aug 2011, at 20:26, Kent Leung (kleung) wrote: > > Hi Ben. In general, I think that content that has expired should be > > treated similarly as de-activated except that content is removed from > > the Surrogate. The content availability window has to work in > > conjunction with cache aging function. So there shouldn't be > > requirements to the level of implementation. >=20 > On 4 Aug 2011, at 20:36, Kevin J Ma wrote: > > I would expect that once the expiration time is reached, all copies of > the > > content would be expunged from any surrogates/storage devices. >=20 > I'm starting to worry that we are creating new requirements on CDNs in > general rather than reflecting existing CDN requirements into CDNI. >=20 > For example, content that expires "naturally" (e.g. due to Cache-Control > headers) is not automatically "expunged" and therefore I am struggling a > little to understand why content that has an associated availability > window is required to be "expunged" when that availability window expires= . > I have not personally encountered a CSP that has such a requirement. >=20 > Ben >=20 >=20 > > -----Original Message----- > > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] > > Sent: Thursday, August 04, 2011 7:23 AM > > To: Francois Le Faucheur (flefauch) > > Cc: Kent Leung (kleung); cdni@ietf.org; > > draft-bertrand-cdni-use-cases@tools.ietf.org > > Subject: Re: [CDNi] comments on draft-bertrand-cdni-use-cases-02 > > > > Use Case authors, Colleagues, > > > > On 28 Jul 2011, at 21:16, Francois Le Faucheur wrote: > > > >> Kent and all, > >> > >> On 28 Jul 2011, at 16:10, Kent Leung (kleung) wrote: > >> > >>> Hi Francois. Responding to comments related to the requirements > > draft > >>> below. > >>> > >>> > >>> o an expiration time (i.e., the time at which the content files > >>> should be expunged from all CDN storage). > >>> " > >>> I understand this is saying that CDNI metadata need to include this > >>> expiration time (triggering cache removal) , in addition to > > deactivation > >>> time. > >>> I don't think this is discussed in cdni-requirements yet. Can you > > bring > >>> that up on the list with the cdni-reqts authors? > >>> > >>> KL> I've seen references to content expiration time (i.e. removal) in > >>> some drafts. So it seems to be needed in the CDNI Metadata. Noted > > as > >>> requirement (possibly part of availability window) unless others > > object. > >> > >> FLF as an Individual: that works for me. > > > > I'd like to understand the underlying requirement a bit better as it's > > not clear to me what the expected behaviour of a surrogate would be whe= n > > receiving a request for the content after the "expiration time" is > > reached as well as how the surrogate is supposed to treat any cached > > copy of the content held in either volatile or non-volatile storage. > > > > For example, when receiving a request for content after the "expiration > > time" is reached, is a surrogate required to: > > - No longer deliver the content, even if presented with a valid request > > to do? > > - Consider any cached copy of the content as "stale" and revalidate the > > content against the Origin, delivering the content if revalidation > > succeeds and not delivering the content if revalidation fails. > > > > For example, for any cached copy of the content after the "expiration > > time" is reach, is a surrogate required to: > > - Nothing more than whatever it is supposed to do in the example above > > and use its normal cache expiration procedures to recovery the storage > > space used like it would for "stale" content that does not have an > > explicit expiration time? > > - Actively keep track of cached content & its associated expiration tim= e > > and actively "de-link" (e.g. remove from the filesystem table) the > > cached copy of the content? > > - Actively keep track of cached content & its associated expiration tim= e > > and actively overwrite the storage sectors containing that content in > > both volatile & non-volatile storage? > > > > Thanks > > Ben > > > > From lpeterson@verivue.com Fri Aug 5 05:45:02 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DDF821F8B9C for ; Fri, 5 Aug 2011 05:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PGJLxYeYtTJu for ; Fri, 5 Aug 2011 05:44:58 -0700 (PDT) Received: from exprod8og111.obsmtp.com (exprod8og111.obsmtp.com [64.18.3.22]) by ietfa.amsl.com (Postfix) with ESMTP id 764F821F8B00 for ; Fri, 5 Aug 2011 05:44:57 -0700 (PDT) Received: from vvexch.verivue.com ([63.64.170.198]) (using TLSv1) by exprod8ob111.postini.com ([64.18.7.12]) with SMTP ID DSNKTjvl1WN61E9Vzhq2/7k5WS7LT/11f9y+@postini.com; Fri, 05 Aug 2011 05:45:15 PDT Received: from vvexch.verivue.com ([10.10.6.20]) by vvexch.verivue.com ([10.10.6.20]) with mapi; Fri, 5 Aug 2011 08:45:08 -0400 From: "Peterson, Larry" To: Ben Niven-Jenkins Date: Fri, 5 Aug 2011 08:45:06 -0400 Thread-Topic: [CDNi] upstream cdn enforce content policies Thread-Index: AcxTbYGcaM6CcBV4SGS10stCqcCozQ== Message-ID: <325B2706-2E54-45C1-91E3-610C6B9FD487@verivue.com> References: <4E3A6BEE.4080301@edgeware.tv> <8AF4C086-7E25-4931-9BF7-7DC7F44A9D2C@niven-jenkins.co.uk> <4E3A7178.6080400@edgeware.tv> <1CA25301D2219F40B3AA37201F0EACD11360E6C4@PACDCEXMB05.cable.comcast.com> <4E3AB142.4030103@edgeware.tv> <70AE7D15-69E5-40FE-A4EE-F6BF5E01C6A9@verivue.com> <291CC3F9E50E7641901A54E85D0977C6518C23922F@MAILR002.mail.lan> <3C17706D-6CE3-4F69-8E75-D7161C845534@niven-jenkins.co.uk> In-Reply-To: <3C17706D-6CE3-4F69-8E75-D7161C845534@niven-jenkins.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] upstream cdn enforce content policies X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 12:45:02 -0000 Ben, I think the phrasing of your question makes my point. In one model, there remains a strong coupling. The uCDN is involved in every request=20 routing decision (for example), and hence, retains the ability to interject itself (and its customer's will) on content delivery. In the other model, the uCDN delegates (through metadata) all responsibility to the dCDN. Is that level of coupling undesirable? In m view, no. Certainly I think we can agree the uCDN is going to be involved in request routing since the URL is going to contain a domain name that the uCDN is going to have deal with one way or another. I hope we can also agree that the dCDN is going to need to respect caching directives, so I don't see the problem with taking advantage of that. Let me turn this around and talk about why I'm worried that the metadata interface is going to be tricky... and maybe people will correct me on this= . My sense is that metadata is in a semantically rich space (at least relativ= e=20 to a CDN's pure caching function), and so reaching agreement on universal CDN metadata is going to be a challenge.=20 Larry On Aug 4, 2011, at 7:19 PM, Ben Niven-Jenkins wrote: > Larry, >=20 > On 4 Aug 2011, at 20:14, Peterson, Larry wrote: >=20 >> Good questions... In my mind, the metadata interface is used to delegate >> responsibility from uCDN to dCDN. The CSP still has to trust that the dC= DN >> behaves according to the metadata it's passed. Alternatively, the CSP tr= usts >> that the uCDN -- with which it has a contractual agreement -- to "stay i= n >> the loop" and keep a tighter leash on what the dCDN does (e.g., make a >> decision on each request it routes, issues purge commands when necessary= , >> and adds cache directives as necessary). Yes, we have to trust the dCDN = to >> observe cache directives, so you could argue both strategies involve tru= sting >> the dCDN, but you could also argue that the latter approach narrows the >> window of vulnerability if trust is violated. >=20 > Can you expand on that argument because I can't see how the latter approa= ch narrows the window of vulnerability without introducing an undesirable l= evel of coupling between the upstream & downstream CDNs? >=20 > Thanks > Ben >=20 >>=20 >> As to the position that "we just as well define the interface in case so= me pair >> of CDNs want to use it"... sure, but every bit of mechanism comes at som= e cost >> in complexity. >>=20 >> Larry >>=20 >> On Aug 4, 2011, at 3:00 PM, Kevin J Ma wrote: >>=20 >>>> The question is: does interconnection imply that uCDN further delegate= s that >>>> responsibility for enforcing access control policy to the dCDN, or doe= s the uCDN >>>> retain that locus of control for itself.=20 >>>=20 >>> I think the issue is more the threat that a CSP may have an agreement w= ith >>> the uCDN, which it has paid for, which may not be enforceable through d= CDNs. >>> It is not clear that a uCDN can always enforce those policies. It is n= ot that >>> hard to figure out where the content is really coming from (i.e., the d= CDN). >>> Will CSPs, who tend to be risk averse, just disallow delegation? >>>=20 >>> Sticking with the minimalist approach, I still think there is value in = a >>> standardized method of exchanging opaque metadata. If some CDNs agree= =20 >>> amongst themselves (outside of CDNI) to enforce policies, they will mos= t >>> likely need to exchange metadata? Having a well defined protocol to do= so >>> seems like an important first step? >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf O= f >>>> Peterson, Larry >>>> Sent: Thursday, August 04, 2011 11:31 AM >>>> To: Johan Rydberg >>>> Cc: cdni@ietf.org >>>> Subject: Re: [CDNi] upstream cdn enforce content policies >>>>=20 >>>> Picking up on Johan's minimized scope thread... >>>>=20 >>>> I too have been puzzled by the metadata interface. If you read the >>>> language >>>> carefully, you'll see there's a caveat that this interface might exist= in >>>> various >>>> forms, presumably as a combination of other interfaces and mechanisms, >>>> for example: >>>> o the uCDN doesn't route the request to the dCDN unless policy permits= ; >>>> o the uCDN sets HTTP caching directives consistent with policy and the >>>> dCDN obeys those directives; and >>>> o the uCDN invokes purge on dCDN should the policy change. >>>>=20 >>>> But that generous interpretation aside, the high level issue seems to = be >>>> how >>>> access control policy is enforced. In a single CDN it's natural for th= is >>>> policy to >>>> be enforced by the CDN, and there's likely a metadata-like interface b= y >>>> which >>>> the CSP expresses this policy to that CDN. >>>>=20 >>>> The question is: does interconnection imply that uCDN further delegate= s >>>> that >>>> responsibility for enforcing access control policy to the dCDN, or doe= s >>>> the uCDN >>>> retain that locus of control for itself. The later design, which >>>> essentially treats >>>> the dCDN as it would any other cache (at least with respect to metadat= a), >>>> seems >>>> the simplest to me. >>>>=20 >>>> Larry >>>>=20 >>>> On Aug 4, 2011, at 10:48 AM, Johan Rydberg wrote: >>>>=20 >>>>> Richard, >>>>>=20 >>>>> I just got a bit scared when I saw discussions about features that "m= ay >>>>> be good to have" >>>>> or "it would be nice to support". >>>>>=20 >>>>> I guess all I wanted to say was that everyone would benefit from a >>>>> minimized scoop. >>>>>=20 >>>>> On 8/4/11 4:34 PM, Woundy, Richard wrote: >>>>>> A couple of observations, as an individual and not a working group >>>> chair. >>>>>>=20 >>>>>>=20 >>>>>>> Instead of constructing a complex metadata exchange protocol >>>>>>>=20 >>>>>> How about we construct a *simple* metadata exchange protocol? :) >>>>>>=20 >>>>>> I believe we are anticipating this protocol to be XML/JSON over HTTP= . >>>>>>=20 >>>>>>=20 >>>>>>> I have a feeling that if the interconnect protocols are not limited= in >>>> scope, this CDNI effort will either (1) fail or (2) be in some "design >>>> phase" for ever. >>>>>>>=20 >>>>>> CDNI was approved as a WG in late June. Now it is early August and >>>> we're already in danger of failing? Hmmm. >>>>>>=20 >>>>>> It feels to me like we are debating theoretical scenarios. Johan, if >>>> you feel strongly about eliminating this interface, maybe you could wr= ite >>>> up your proposal as an internet-draft that we can discuss and debate? = We >>>> also need to ensure that your proposal meets the use cases identified = by >>>> this group. >>>>>>=20 >>>>>> -- Rich >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf= Of >>>> Johan Rydberg >>>>>> Sent: Thursday, August 04, 2011 6:16 AM >>>>>> To: Ben Niven-Jenkins >>>>>> Cc: cdni@ietf.org >>>>>> Subject: Re: [CDNi] upstream cdn enforce content policies >>>>>>=20 >>>>>> On 8/4/11 12:10 PM, Ben Niven-Jenkins wrote: >>>>>>=20 >>>>>>> Johan, >>>>>>>=20 >>>>>>> On 4 Aug 2011, at 10:52, Johan Rydberg wrote: >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>> After following the discussions for a while, I have a question: >>>>>>>>=20 >>>>>>>> Instead of constructing a complex metadata exchange protocol, >>>>>>>> why not force the upstream CDN to enforce any prolicy rules that >>>>>>>> the CSP has put on the content? >>>>>>>>=20 >>>>>>>>=20 >>>>>>> That would not provide sufficient coverage to ensure that the polic= y >>>> is enforced as clients may attempt to request content directly from a >>>> downstream CDN, bypassing the upstream CDN. >>>>>>>=20 >>>>>>>=20 >>>>>> There must be ways to make sure that the client first passes through >>>> the >>>>>> upstream >>>>>> CDN. >>>>>>=20 >>>>>> I have a feeling that if the interconnect protocols are not limited = in >>>>>> scope, this >>>>>> CDNI effort will either (1) fail or (2) be in some "design phase" fo= r >>>> ever. >>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>> In the case of DNS-based routing, the CDN can answer the DNS >>>>>>>> lookup with the address of one of its own CDNI request routers >>>>>>>> that will enforce any policies before redirecting (HTTP 302) to >>>>>>>> a downstream CDN. >>>>>>>>=20 >>>>>>>> The upside to this is that redirects between CDNs will always be >>>>>>>> HTTP 302, regardless if the initial mechanism was DNS-based. >>>>>>>> Also, the complex metadata protocol can be elimited, minimizing >>>>>>>> the scope of the CDNI work. >>>>>>>>=20 >>>>>>>>=20 >>>>>>> Even if one could avoid the need for a downstream CDN to apply some >>>> policies, this wouldn't eliminate the need to exchange CDNI metadata a= s >>>> other CDNI metadata such as rate limiting, whether an encrypted channe= l is >>>> required, where to obtain the content from etc. is still required. >>>>>>>=20 >>>>>>>=20 >>>>>> It sounds like most of those could be folded into the request routin= g >>>>>> protocol. >>>>>> Rate limiting and encryption might not be attributes of the content, >>>> but >>>>>> rather >>>>>> of the client. (Some customers pay more, and get a higher bitrate f= or >>>>>> example) >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> CDNi mailing list >>>>>> CDNi@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/cdni >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> CDNi mailing list >>>>> CDNi@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/cdni >>>>=20 >>>> _______________________________________________ >>>> CDNi mailing list >>>> CDNi@ietf.org >>>> https://www.ietf.org/mailman/listinfo/cdni >>=20 >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni >=20 From zhouzhipeng@huawei.com Fri Aug 5 01:41:19 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C80B721F8B55 for ; Fri, 5 Aug 2011 01:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.905 X-Spam-Level: X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[AWL=-4.693, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C3am2QPGyGVy for ; Fri, 5 Aug 2011 01:41:17 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id B652821F8610 for ; Fri, 5 Aug 2011 01:41:16 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPG00HTZ5F7F5@szxga05-in.huawei.com> for cdni@ietf.org; Fri, 05 Aug 2011 16:40:19 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPG00HN75E7DS@szxga05-in.huawei.com> for cdni@ietf.org; Fri, 05 Aug 2011 16:40:19 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml201-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ACY09824; Fri, 05 Aug 2011 16:40:16 +0800 (CST) Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 05 Aug 2011 16:40:08 +0800 Received: from SZXEML519-MBS.china.huawei.com ([169.254.7.219]) by szxeml402-hub.china.huawei.com ([10.82.67.32]) with mapi id 14.01.0270.001; Fri, 05 Aug 2011 16:40:15 +0800 Date: Fri, 05 Aug 2011 08:40:15 +0000 From: ZhouZhipeng In-reply-to: <1CA25301D2219F40B3AA37201F0EACD11360E6C4@PACDCEXMB05.cable.comcast.com> X-Originating-IP: [10.138.73.38] To: "Woundy, Richard" , Johan Rydberg , Ben Niven-Jenkins Message-id: <260A32EFD5C9EB47AD504929D005DF623D4B37@SZXEML519-MBS.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: [CDNi] upstream cdn enforce content policies Thread-index: AQHMUrdrllglbdYgCEKe5UsiIczS4pUN7/sg X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4E3A6BEE.4080301@edgeware.tv> <8AF4C086-7E25-4931-9BF7-7DC7F44A9D2C@niven-jenkins.co.uk> <4E3A7178.6080400@edgeware.tv> <1CA25301D2219F40B3AA37201F0EACD11360E6C4@PACDCEXMB05.cable.comcast.com> X-Mailman-Approved-At: Fri, 05 Aug 2011 08:11:39 -0700 Cc: "cdni@ietf.org" Subject: [CDNi] =?gb2312?b?tPC4tDogIHVwc3RyZWFtIGNkbiBlbmZvcmNlIGNvbnRl?= =?gb2312?b?bnQgcG9saWNpZXM=?= X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 08:43:45 -0000 SSBhZ3JlZSB3aXRoIFJpY2hhcmQgdGhhdCBmb3IgQ0ROSSBpdCBpcyBqdXN0IGluIGFuIGVhcmx5 IHN0YWdlIGFuZCB0aGUgdXNlIGNhc2VzIGFuZCByZXF1aXJlbWVudHMgYXJlIHN0aWxsIGJlaW5n IGRpc2N1c3NlZC4NCkFzIGZvciB0aGUgbWV0YWRhdGEsIG15IGZlZWxpbmcgaXMgdGhlIHF1ZXN0 aW9uIGluY2x1ZGVzIHR3byBwYXJ0czogd2hhdCBtYXkgYmUgY29udGFpbmVkIGluIHRoZSBtZXRh ZGF0YTsgaG93IHRvIHVzZSB0aGUgbWV0YWRhdGEuDQpUaGUgY29uY2x1c2lvbiBuZWVkcyB0aW1l IHRvIGJlIGdpdmVuIGF0IGxhc3QuDQpaaGlwZW5nDQoNCg0KLS0tLS3Tyrz+1K28/i0tLS0tDQq3 orz+yMs6IFdvdW5keSwgUmljaGFyZCBbbWFpbHRvOlJpY2hhcmRfV291bmR5QGNhYmxlLmNvbWNh c3QuY29tXSANCreiy83KsbzkOiAyMDExxOo41MI0yNUgMjI6MzUNCsrVvP7IyzogSm9oYW4gUnlk YmVyZzsgQmVuIE5pdmVuLUplbmtpbnMNCrOty806IGNkbmlAaWV0Zi5vcmcNCtb3zOI6IFJlOiBb Q0ROaV0gdXBzdHJlYW0gY2RuIGVuZm9yY2UgY29udGVudCBwb2xpY2llcw0KDQpBIGNvdXBsZSBv ZiBvYnNlcnZhdGlvbnMsIGFzIGFuIGluZGl2aWR1YWwgYW5kIG5vdCBhIHdvcmtpbmcgZ3JvdXAg Y2hhaXIuDQoNCj4gSW5zdGVhZCBvZiBjb25zdHJ1Y3RpbmcgYSBjb21wbGV4IG1ldGFkYXRhIGV4 Y2hhbmdlIHByb3RvY29sDQoNCkhvdyBhYm91dCB3ZSBjb25zdHJ1Y3QgYSAqc2ltcGxlKiBtZXRh ZGF0YSBleGNoYW5nZSBwcm90b2NvbD8gOikNCg0KSSBiZWxpZXZlIHdlIGFyZSBhbnRpY2lwYXRp bmcgdGhpcyBwcm90b2NvbCB0byBiZSBYTUwvSlNPTiBvdmVyIEhUVFAuDQoNCj4gSSBoYXZlIGEg ZmVlbGluZyB0aGF0IGlmIHRoZSBpbnRlcmNvbm5lY3QgcHJvdG9jb2xzIGFyZSBub3QgbGltaXRl ZCBpbiBzY29wZSwgdGhpcyBDRE5JIGVmZm9ydCB3aWxsIGVpdGhlciAoMSkgZmFpbCBvciAoMikg YmUgaW4gc29tZSAiZGVzaWduIHBoYXNlIiBmb3IgZXZlci4NCg0KQ0ROSSB3YXMgYXBwcm92ZWQg YXMgYSBXRyBpbiBsYXRlIEp1bmUuIE5vdyBpdCBpcyBlYXJseSBBdWd1c3QgYW5kIHdlJ3JlIGFs cmVhZHkgaW4gZGFuZ2VyIG9mIGZhaWxpbmc/IEhtbW0uDQoNCkl0IGZlZWxzIHRvIG1lIGxpa2Ug d2UgYXJlIGRlYmF0aW5nIHRoZW9yZXRpY2FsIHNjZW5hcmlvcy4gSm9oYW4sIGlmIHlvdSBmZWVs IHN0cm9uZ2x5IGFib3V0IGVsaW1pbmF0aW5nIHRoaXMgaW50ZXJmYWNlLCBtYXliZSB5b3UgY291 bGQgd3JpdGUgdXAgeW91ciBwcm9wb3NhbCBhcyBhbiBpbnRlcm5ldC1kcmFmdCB0aGF0IHdlIGNh biBkaXNjdXNzIGFuZCBkZWJhdGU/IFdlIGFsc28gbmVlZCB0byBlbnN1cmUgdGhhdCB5b3VyIHBy b3Bvc2FsIG1lZXRzIHRoZSB1c2UgY2FzZXMgaWRlbnRpZmllZCBieSB0aGlzIGdyb3VwLg0KDQot LSBSaWNoDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBjZG5pLWJvdW5jZXNA aWV0Zi5vcmcgW21haWx0bzpjZG5pLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKb2hh biBSeWRiZXJnDQpTZW50OiBUaHVyc2RheSwgQXVndXN0IDA0LCAyMDExIDY6MTYgQU0NClRvOiBC ZW4gTml2ZW4tSmVua2lucw0KQ2M6IGNkbmlAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbQ0ROaV0g dXBzdHJlYW0gY2RuIGVuZm9yY2UgY29udGVudCBwb2xpY2llcw0KDQpPbiA4LzQvMTEgMTI6MTAg UE0sIEJlbiBOaXZlbi1KZW5raW5zIHdyb3RlOg0KPiBKb2hhbiwNCj4NCj4gT24gNCBBdWcgMjAx MSwgYXQgMTA6NTIsIEpvaGFuIFJ5ZGJlcmcgd3JvdGU6DQo+DQo+ICAgIA0KPj4gQWZ0ZXIgZm9s bG93aW5nIHRoZSBkaXNjdXNzaW9ucyBmb3IgYSB3aGlsZSwgSSBoYXZlIGEgcXVlc3Rpb246DQo+ Pg0KPj4gSW5zdGVhZCBvZiBjb25zdHJ1Y3RpbmcgYSBjb21wbGV4IG1ldGFkYXRhIGV4Y2hhbmdl IHByb3RvY29sLA0KPj4gd2h5IG5vdCBmb3JjZSB0aGUgdXBzdHJlYW0gQ0ROIHRvIGVuZm9yY2Ug YW55IHByb2xpY3kgcnVsZXMgdGhhdA0KPj4gdGhlIENTUCBoYXMgcHV0IG9uIHRoZSBjb250ZW50 Pw0KPj4gICAgICANCj4gVGhhdCB3b3VsZCBub3QgcHJvdmlkZSBzdWZmaWNpZW50IGNvdmVyYWdl IHRvIGVuc3VyZSB0aGF0IHRoZSBwb2xpY3kgaXMgZW5mb3JjZWQgYXMgY2xpZW50cyBtYXkgYXR0 ZW1wdCB0byByZXF1ZXN0IGNvbnRlbnQgZGlyZWN0bHkgZnJvbSBhIGRvd25zdHJlYW0gQ0ROLCBi eXBhc3NpbmcgdGhlIHVwc3RyZWFtIENETi4NCj4gICAgDQpUaGVyZSBtdXN0IGJlIHdheXMgdG8g bWFrZSBzdXJlIHRoYXQgdGhlIGNsaWVudCBmaXJzdCBwYXNzZXMgdGhyb3VnaCB0aGUgDQp1cHN0 cmVhbQ0KQ0ROLg0KDQpJIGhhdmUgYSBmZWVsaW5nIHRoYXQgaWYgdGhlIGludGVyY29ubmVjdCBw cm90b2NvbHMgYXJlIG5vdCBsaW1pdGVkIGluIA0Kc2NvcGUsIHRoaXMNCkNETkkgZWZmb3J0IHdp bGwgZWl0aGVyICgxKSBmYWlsIG9yICgyKSBiZSBpbiBzb21lICJkZXNpZ24gcGhhc2UiIGZvciBl dmVyLg0KDQo+ICAgIA0KPj4gSW4gdGhlIGNhc2Ugb2YgRE5TLWJhc2VkIHJvdXRpbmcsIHRoZSBD RE4gY2FuIGFuc3dlciB0aGUgRE5TDQo+PiBsb29rdXAgd2l0aCB0aGUgYWRkcmVzcyBvZiBvbmUg b2YgaXRzIG93biBDRE5JIHJlcXVlc3Qgcm91dGVycw0KPj4gdGhhdCB3aWxsIGVuZm9yY2UgYW55 IHBvbGljaWVzIGJlZm9yZSByZWRpcmVjdGluZyAoSFRUUCAzMDIpIHRvDQo+PiBhIGRvd25zdHJl YW0gQ0ROLg0KPj4NCj4+IFRoZSB1cHNpZGUgdG8gdGhpcyBpcyB0aGF0IHJlZGlyZWN0cyBiZXR3 ZWVuIENETnMgd2lsbCBhbHdheXMgYmUNCj4+IEhUVFAgMzAyLCByZWdhcmRsZXNzIGlmIHRoZSBp bml0aWFsIG1lY2hhbmlzbSB3YXMgRE5TLWJhc2VkLg0KPj4gQWxzbywgdGhlIGNvbXBsZXggbWV0 YWRhdGEgcHJvdG9jb2wgY2FuIGJlIGVsaW1pdGVkLCBtaW5pbWl6aW5nDQo+PiB0aGUgc2NvcGUg b2YgdGhlIENETkkgd29yay4NCj4+ICAgICAgDQo+IEV2ZW4gaWYgb25lIGNvdWxkIGF2b2lkIHRo ZSBuZWVkIGZvciBhIGRvd25zdHJlYW0gQ0ROIHRvIGFwcGx5IHNvbWUgcG9saWNpZXMsIHRoaXMg d291bGRuJ3QgZWxpbWluYXRlIHRoZSBuZWVkIHRvIGV4Y2hhbmdlIENETkkgbWV0YWRhdGEgYXMg b3RoZXIgQ0ROSSBtZXRhZGF0YSBzdWNoIGFzIHJhdGUgbGltaXRpbmcsIHdoZXRoZXIgYW4gZW5j cnlwdGVkIGNoYW5uZWwgaXMgcmVxdWlyZWQsIHdoZXJlIHRvIG9idGFpbiB0aGUgY29udGVudCBm cm9tIGV0Yy4gaXMgc3RpbGwgcmVxdWlyZWQuDQo+ICAgIA0KSXQgc291bmRzIGxpa2UgbW9zdCBv ZiB0aG9zZSBjb3VsZCBiZSBmb2xkZWQgaW50byB0aGUgcmVxdWVzdCByb3V0aW5nIA0KcHJvdG9j b2wuDQpSYXRlIGxpbWl0aW5nIGFuZCBlbmNyeXB0aW9uIG1pZ2h0IG5vdCBiZSBhdHRyaWJ1dGVz IG9mIHRoZSBjb250ZW50LCBidXQgDQpyYXRoZXINCm9mIHRoZSBjbGllbnQuICAoU29tZSBjdXN0 b21lcnMgcGF5IG1vcmUsIGFuZCBnZXQgYSBoaWdoZXIgYml0cmF0ZSBmb3IgDQpleGFtcGxlKQ0K DQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpDRE5pIG1haWxpbmcgbGlzdA0KQ0ROaUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9jZG5pDQoNCg== From richard_woundy@cable.comcast.com Fri Aug 5 10:10:15 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBCC321F8C10 for ; Fri, 5 Aug 2011 10:10:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.379 X-Spam-Level: X-Spam-Status: No, score=-103.379 tagged_above=-999 required=5 tests=[AWL=-1.644, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id neqba7Ej5DoI for ; Fri, 5 Aug 2011 10:10:14 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id 8333C21F8B80 for ; Fri, 5 Aug 2011 10:10:14 -0700 (PDT) Received: from ([24.40.55.42]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.47702726; Fri, 05 Aug 2011 11:15:12 -0600 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%11]) with mapi id 14.01.0289.001; Fri, 5 Aug 2011 13:10:09 -0400 From: "Woundy, Richard" To: "Peterson, Larry" , Ben Niven-Jenkins Thread-Topic: [CDNi] upstream cdn enforce content policies Thread-Index: AcxTbYGce9o5Dl8G80aFZBDqzy+b8wAJDH7Q Date: Fri, 5 Aug 2011 17:10:07 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD113611E9B@PACDCEXMB05.cable.comcast.com> References: <4E3A6BEE.4080301@edgeware.tv> <8AF4C086-7E25-4931-9BF7-7DC7F44A9D2C@niven-jenkins.co.uk> <4E3A7178.6080400@edgeware.tv> <1CA25301D2219F40B3AA37201F0EACD11360E6C4@PACDCEXMB05.cable.comcast.com> <4E3AB142.4030103@edgeware.tv> <70AE7D15-69E5-40FE-A4EE-F6BF5E01C6A9@verivue.com> <291CC3F9E50E7641901A54E85D0977C6518C23922F@MAILR002.mail.lan> <3C17706D-6CE3-4F69-8E75-D7161C845534@niven-jenkins.co.uk> <325B2706-2E54-45C1-91E3-610C6B9FD487@verivue.com> In-Reply-To: <325B2706-2E54-45C1-91E3-610C6B9FD487@verivue.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [76.96.69.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] upstream cdn enforce content policies X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 17:10:15 -0000 Speaking personally... > My sense is that metadata is in a semantically rich space (at least relat= ive to a CDN's pure caching function), and so reaching agreement on univers= al CDN metadata is going to be a challenge. Maybe we are aiming for the wrong goal. Instead of agreement on "universal"= CDN metadata, we should be aiming for "core" CDN metadata -- what do we ag= ree we need (as a consensus)? If there is "universal" metadata that we *might* need, we could leverage ve= ndor extensions to the initial metadata interface, and/or include them in a= future version of the specification. If we cannot agree on any "core" metadata, then we should closely examine t= o see if we still need the metadata interface. -- Rich -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Pet= erson, Larry Sent: Friday, August 05, 2011 8:45 AM To: Ben Niven-Jenkins Cc: cdni@ietf.org Subject: Re: [CDNi] upstream cdn enforce content policies Ben, I think the phrasing of your question makes my point. In one model, there remains a strong coupling. The uCDN is involved in every request=20 routing decision (for example), and hence, retains the ability to interject itself (and its customer's will) on content delivery. In the other model, the uCDN delegates (through metadata) all responsibility to the dCDN. Is that level of coupling undesirable? In m view, no. Certainly I think we can agree the uCDN is going to be involved in request routing since the URL is going to contain a domain name that the uCDN is going to have deal with one way or another. I hope we can also agree that the dCDN is going to need to respect caching directives, so I don't see the problem with taking advantage of that. Let me turn this around and talk about why I'm worried that the metadata interface is going to be tricky... and maybe people will correct me on this= . My sense is that metadata is in a semantically rich space (at least relativ= e=20 to a CDN's pure caching function), and so reaching agreement on universal CDN metadata is going to be a challenge.=20 Larry On Aug 4, 2011, at 7:19 PM, Ben Niven-Jenkins wrote: > Larry, >=20 > On 4 Aug 2011, at 20:14, Peterson, Larry wrote: >=20 >> Good questions... In my mind, the metadata interface is used to delegate >> responsibility from uCDN to dCDN. The CSP still has to trust that the dC= DN >> behaves according to the metadata it's passed. Alternatively, the CSP tr= usts >> that the uCDN -- with which it has a contractual agreement -- to "stay i= n >> the loop" and keep a tighter leash on what the dCDN does (e.g., make a >> decision on each request it routes, issues purge commands when necessary= , >> and adds cache directives as necessary). Yes, we have to trust the dCDN = to >> observe cache directives, so you could argue both strategies involve tru= sting >> the dCDN, but you could also argue that the latter approach narrows the >> window of vulnerability if trust is violated. >=20 > Can you expand on that argument because I can't see how the latter approa= ch narrows the window of vulnerability without introducing an undesirable l= evel of coupling between the upstream & downstream CDNs? >=20 > Thanks > Ben >=20 >>=20 >> As to the position that "we just as well define the interface in case so= me pair >> of CDNs want to use it"... sure, but every bit of mechanism comes at som= e cost >> in complexity. >>=20 >> Larry >>=20 >> On Aug 4, 2011, at 3:00 PM, Kevin J Ma wrote: >>=20 >>>> The question is: does interconnection imply that uCDN further delegate= s that >>>> responsibility for enforcing access control policy to the dCDN, or doe= s the uCDN >>>> retain that locus of control for itself.=20 >>>=20 >>> I think the issue is more the threat that a CSP may have an agreement w= ith >>> the uCDN, which it has paid for, which may not be enforceable through d= CDNs. >>> It is not clear that a uCDN can always enforce those policies. It is n= ot that >>> hard to figure out where the content is really coming from (i.e., the d= CDN). >>> Will CSPs, who tend to be risk averse, just disallow delegation? >>>=20 >>> Sticking with the minimalist approach, I still think there is value in = a >>> standardized method of exchanging opaque metadata. If some CDNs agree= =20 >>> amongst themselves (outside of CDNI) to enforce policies, they will mos= t >>> likely need to exchange metadata? Having a well defined protocol to do= so >>> seems like an important first step? >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf O= f >>>> Peterson, Larry >>>> Sent: Thursday, August 04, 2011 11:31 AM >>>> To: Johan Rydberg >>>> Cc: cdni@ietf.org >>>> Subject: Re: [CDNi] upstream cdn enforce content policies >>>>=20 >>>> Picking up on Johan's minimized scope thread... >>>>=20 >>>> I too have been puzzled by the metadata interface. If you read the >>>> language >>>> carefully, you'll see there's a caveat that this interface might exist= in >>>> various >>>> forms, presumably as a combination of other interfaces and mechanisms, >>>> for example: >>>> o the uCDN doesn't route the request to the dCDN unless policy permits= ; >>>> o the uCDN sets HTTP caching directives consistent with policy and the >>>> dCDN obeys those directives; and >>>> o the uCDN invokes purge on dCDN should the policy change. >>>>=20 >>>> But that generous interpretation aside, the high level issue seems to = be >>>> how >>>> access control policy is enforced. In a single CDN it's natural for th= is >>>> policy to >>>> be enforced by the CDN, and there's likely a metadata-like interface b= y >>>> which >>>> the CSP expresses this policy to that CDN. >>>>=20 >>>> The question is: does interconnection imply that uCDN further delegate= s >>>> that >>>> responsibility for enforcing access control policy to the dCDN, or doe= s >>>> the uCDN >>>> retain that locus of control for itself. The later design, which >>>> essentially treats >>>> the dCDN as it would any other cache (at least with respect to metadat= a), >>>> seems >>>> the simplest to me. >>>>=20 >>>> Larry >>>>=20 >>>> On Aug 4, 2011, at 10:48 AM, Johan Rydberg wrote: >>>>=20 >>>>> Richard, >>>>>=20 >>>>> I just got a bit scared when I saw discussions about features that "m= ay >>>>> be good to have" >>>>> or "it would be nice to support". >>>>>=20 >>>>> I guess all I wanted to say was that everyone would benefit from a >>>>> minimized scoop. >>>>>=20 >>>>> On 8/4/11 4:34 PM, Woundy, Richard wrote: >>>>>> A couple of observations, as an individual and not a working group >>>> chair. >>>>>>=20 >>>>>>=20 >>>>>>> Instead of constructing a complex metadata exchange protocol >>>>>>>=20 >>>>>> How about we construct a *simple* metadata exchange protocol? :) >>>>>>=20 >>>>>> I believe we are anticipating this protocol to be XML/JSON over HTTP= . >>>>>>=20 >>>>>>=20 >>>>>>> I have a feeling that if the interconnect protocols are not limited= in >>>> scope, this CDNI effort will either (1) fail or (2) be in some "design >>>> phase" for ever. >>>>>>>=20 >>>>>> CDNI was approved as a WG in late June. Now it is early August and >>>> we're already in danger of failing? Hmmm. >>>>>>=20 >>>>>> It feels to me like we are debating theoretical scenarios. Johan, if >>>> you feel strongly about eliminating this interface, maybe you could wr= ite >>>> up your proposal as an internet-draft that we can discuss and debate? = We >>>> also need to ensure that your proposal meets the use cases identified = by >>>> this group. >>>>>>=20 >>>>>> -- Rich >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf= Of >>>> Johan Rydberg >>>>>> Sent: Thursday, August 04, 2011 6:16 AM >>>>>> To: Ben Niven-Jenkins >>>>>> Cc: cdni@ietf.org >>>>>> Subject: Re: [CDNi] upstream cdn enforce content policies >>>>>>=20 >>>>>> On 8/4/11 12:10 PM, Ben Niven-Jenkins wrote: >>>>>>=20 >>>>>>> Johan, >>>>>>>=20 >>>>>>> On 4 Aug 2011, at 10:52, Johan Rydberg wrote: >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>> After following the discussions for a while, I have a question: >>>>>>>>=20 >>>>>>>> Instead of constructing a complex metadata exchange protocol, >>>>>>>> why not force the upstream CDN to enforce any prolicy rules that >>>>>>>> the CSP has put on the content? >>>>>>>>=20 >>>>>>>>=20 >>>>>>> That would not provide sufficient coverage to ensure that the polic= y >>>> is enforced as clients may attempt to request content directly from a >>>> downstream CDN, bypassing the upstream CDN. >>>>>>>=20 >>>>>>>=20 >>>>>> There must be ways to make sure that the client first passes through >>>> the >>>>>> upstream >>>>>> CDN. >>>>>>=20 >>>>>> I have a feeling that if the interconnect protocols are not limited = in >>>>>> scope, this >>>>>> CDNI effort will either (1) fail or (2) be in some "design phase" fo= r >>>> ever. >>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>> In the case of DNS-based routing, the CDN can answer the DNS >>>>>>>> lookup with the address of one of its own CDNI request routers >>>>>>>> that will enforce any policies before redirecting (HTTP 302) to >>>>>>>> a downstream CDN. >>>>>>>>=20 >>>>>>>> The upside to this is that redirects between CDNs will always be >>>>>>>> HTTP 302, regardless if the initial mechanism was DNS-based. >>>>>>>> Also, the complex metadata protocol can be elimited, minimizing >>>>>>>> the scope of the CDNI work. >>>>>>>>=20 >>>>>>>>=20 >>>>>>> Even if one could avoid the need for a downstream CDN to apply some >>>> policies, this wouldn't eliminate the need to exchange CDNI metadata a= s >>>> other CDNI metadata such as rate limiting, whether an encrypted channe= l is >>>> required, where to obtain the content from etc. is still required. >>>>>>>=20 >>>>>>>=20 >>>>>> It sounds like most of those could be folded into the request routin= g >>>>>> protocol. >>>>>> Rate limiting and encryption might not be attributes of the content, >>>> but >>>>>> rather >>>>>> of the client. (Some customers pay more, and get a higher bitrate f= or >>>>>> example) >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> CDNi mailing list >>>>>> CDNi@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/cdni >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> CDNi mailing list >>>>> CDNi@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/cdni >>>>=20 >>>> _______________________________________________ >>>> CDNi mailing list >>>> CDNi@ietf.org >>>> https://www.ietf.org/mailman/listinfo/cdni >>=20 >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni >=20 _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni From swainner@cisco.com Sun Aug 7 21:34:37 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0368321F85DE for ; Sun, 7 Aug 2011 21:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qi3ZIKX7ySK7 for ; Sun, 7 Aug 2011 21:34:34 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 8CD6E21F8586 for ; Sun, 7 Aug 2011 21:34:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=swainner@cisco.com; l=36876; q=dns/txt; s=iport; t=1312778099; x=1313987699; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=EbBI7/x21GH4l9xOH9jjG/3Nm8TmnGTmYLsAbagdZ/c=; b=INb3qGF556mHQq4bwpW8pvog3VpcN8vXQLgz87nDJo+G5rhA8wjiMiZC fDod6UI51hMmNk6Xi3mYOWDukEahg5wyJTm7t5Ef21SHLBSXQzfnDVPFA 75BoYcJVQYfNIMd95LBQmrGo0M0VZJoq1wYzqxLChb9cp87d8VLo8yQ8X Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AucAAGxmP06tJXG+/2dsb2JhbABCl2uPS3eBQAEBAQECAQEBAQ8BBxNBCgYHBAsRBAEBAQkWAQEGBwkDAgECARUfCQgTBgIBAR6HSwScaAGdZYZGBJMCkQQ X-IronPort-AV: E=Sophos;i="4.67,335,1309737600"; d="scan'208,217";a="10667854" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-9.cisco.com with ESMTP; 08 Aug 2011 04:34:59 +0000 Received: from rtp-vpn3-1070.cisco.com (rtp-vpn3-1070.cisco.com [10.82.220.51]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p784YvGK027279 for ; Mon, 8 Aug 2011 04:34:57 GMT Message-ID: <4E3F67D3.6090505@cisco.com> Date: Mon, 08 Aug 2011 00:36:35 -0400 From: Scott Wainner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: cdni@ietf.org References: <4E3A6BEE.4080301@edgeware.tv><8AF4C086-7E25-4931-9BF7-7DC7F44A9D2C@niven-jenkins.co.uk><4E3A7178.6080400@edgeware.tv><1CA25301D2219F40B3AA37201F0EACD11360E6C4@PACDCEXMB05.cable.comcast.com><4E3AB142.4030103@edgeware.tv><70AE7D15-69E5-40FE-A4EE-F6BF5E01C6A9@verivue.com><291CC3F9E50E7641901A54E85D0977C6518C23922F@MAILR002.mail.lan><3C17706D-6CE3-4F69-8E75-D7161C845534@niven-jenkins.co.uk><325B2706-2E54-45C1-91E3-610C6B9FD487@verivue.com> <1CA25301D2219F40B3AA37201F0EACD113611E9B@PACDCEXMB05.cable.comcast.com> In-Reply-To: <1CA25301D2219F40B3AA37201F0EACD113611E9B@PACDCEXMB05.cable.comcast.com> Content-Type: multipart/alternative; boundary="------------070206030105050505090700" Subject: Re: [CDNi] upstream cdn enforce content policies X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2011 04:34:37 -0000 This is a multi-part message in MIME format. --------------070206030105050505090700 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Richard, I too am confused about the use of the Metadata interface to relay metadata. Seems the term metadata is overloaded and can mean 'anything we deem relevant' which will get us in trouble. In looking through the requirements document, I can see concrete evidence of specific information in the following: R50: acquisition protocol and uri of the content to be pre-positioned or dynamically acquired R51: list of candidate Origin sources R58: metadata exchange status R59: policies; presumably policies associated with an object or set of objects R60: authorization checks Perhaps these elements represent a few of the 'core' metadata of which we speak. When I think of metadata, I usually think of it in the context of metadata for a specific object. For example, a media file will need metadata that describes the use of the media (offering date, expiration date, black-out locations, trick mode restrictions, transcode restrictions, cipher requirements, etc.). The metadata is not in the media; the metadata must be associated with the media. This is typically done by packaging the media and metadata together. If we're talking about dynamic acquisition or pre-positioning of the media only, then we will need some means of relaying the associated metadata. The capabilities of the dCDN seemed to be defined in the Routing Request requirements. Need to delineate where the policies in R59 are handled .. Routing Request or Metadata. Scott On 8/5/11 1:10 PM, Woundy, Richard wrote: > > Speaking personally... > > > My sense is that metadata is in a semantically rich space (at least > relative to a CDN's pure caching function), and so reaching agreement > on universal CDN metadata is going to be a challenge. > > Maybe we are aiming for the wrong goal. Instead of agreement on > "universal" CDN metadata, we should be aiming for "core" CDN metadata > -- what do we agree we need (as a consensus)? > > If there is "universal" metadata that we *might* need, we could > leverage vendor extensions to the initial metadata interface, and/or > include them in a future version of the specification. > > If we cannot agree on any "core" metadata, then we should closely > examine to see if we still need the metadata interface. > > -- Rich > > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf > Of Peterson, Larry > Sent: Friday, August 05, 2011 8:45 AM > To: Ben Niven-Jenkins > Cc: cdni@ietf.org > Subject: Re: [CDNi] upstream cdn enforce content policies > > Ben, > > I think the phrasing of your question makes my point. In one model, > there remains a strong coupling. The uCDN is involved in every request > routing decision (for example), and hence, retains the ability to > interject > itself (and its customer's will) on content delivery. In the other model, > the uCDN delegates (through metadata) all responsibility to the dCDN. > > Is that level of coupling undesirable? In m view, no. Certainly I think we > can agree the uCDN is going to be involved in request routing since the > URL is going to contain a domain name that the uCDN is going to have > deal with one way or another. I hope we can also agree that the dCDN > is going to need to respect caching directives, so I don't see the problem > with taking advantage of that. > > Let me turn this around and talk about why I'm worried that the metadata > interface is going to be tricky... and maybe people will correct me on > this. > My sense is that metadata is in a semantically rich space (at least > relative > to a CDN's pure caching function), and so reaching agreement on universal > CDN metadata is going to be a challenge. > > Larry > > On Aug 4, 2011, at 7:19 PM, Ben Niven-Jenkins wrote: > > > Larry, > > > > On 4 Aug 2011, at 20:14, Peterson, Larry wrote: > > > >> Good questions... In my mind, the metadata interface is used to > delegate > >> responsibility from uCDN to dCDN. The CSP still has to trust that > the dCDN > >> behaves according to the metadata it's passed. Alternatively, the > CSP trusts > >> that the uCDN -- with which it has a contractual agreement -- to > "stay in > >> the loop" and keep a tighter leash on what the dCDN does (e.g., make a > >> decision on each request it routes, issues purge commands when > necessary, > >> and adds cache directives as necessary). Yes, we have to trust the > dCDN to > >> observe cache directives, so you could argue both strategies > involve trusting > >> the dCDN, but you could also argue that the latter approach narrows the > >> window of vulnerability if trust is violated. > > > > Can you expand on that argument because I can't see how the latter > approach narrows the window of vulnerability without introducing an > undesirable level of coupling between the upstream & downstream CDNs? > > > > Thanks > > Ben > > > >> > >> As to the position that "we just as well define the interface in > case some pair > >> of CDNs want to use it"... sure, but every bit of mechanism comes > at some cost > >> in complexity. > >> > >> Larry > >> > >> On Aug 4, 2011, at 3:00 PM, Kevin J Ma wrote: > >> > >>>> The question is: does interconnection imply that uCDN further > delegates that > >>>> responsibility for enforcing access control policy to the dCDN, > or does the uCDN > >>>> retain that locus of control for itself. > >>> > >>> I think the issue is more the threat that a CSP may have an > agreement with > >>> the uCDN, which it has paid for, which may not be enforceable > through dCDNs. > >>> It is not clear that a uCDN can always enforce those policies. It > is not that > >>> hard to figure out where the content is really coming from (i.e., > the dCDN). > >>> Will CSPs, who tend to be risk averse, just disallow delegation? > >>> > >>> Sticking with the minimalist approach, I still think there is > value in a > >>> standardized method of exchanging opaque metadata. If some CDNs agree > >>> amongst themselves (outside of CDNI) to enforce policies, they > will most > >>> likely need to exchange metadata? Having a well defined protocol > to do so > >>> seems like an important first step? > >>> > >>> > >>>> -----Original Message----- > >>>> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On > Behalf Of > >>>> Peterson, Larry > >>>> Sent: Thursday, August 04, 2011 11:31 AM > >>>> To: Johan Rydberg > >>>> Cc: cdni@ietf.org > >>>> Subject: Re: [CDNi] upstream cdn enforce content policies > >>>> > >>>> Picking up on Johan's minimized scope thread... > >>>> > >>>> I too have been puzzled by the metadata interface. If you read the > >>>> language > >>>> carefully, you'll see there's a caveat that this interface might > exist in > >>>> various > >>>> forms, presumably as a combination of other interfaces and > mechanisms, > >>>> for example: > >>>> o the uCDN doesn't route the request to the dCDN unless policy > permits; > >>>> o the uCDN sets HTTP caching directives consistent with policy > and the > >>>> dCDN obeys those directives; and > >>>> o the uCDN invokes purge on dCDN should the policy change. > >>>> > >>>> But that generous interpretation aside, the high level issue > seems to be > >>>> how > >>>> access control policy is enforced. In a single CDN it's natural > for this > >>>> policy to > >>>> be enforced by the CDN, and there's likely a metadata-like > interface by > >>>> which > >>>> the CSP expresses this policy to that CDN. > >>>> > >>>> The question is: does interconnection imply that uCDN further > delegates > >>>> that > >>>> responsibility for enforcing access control policy to the dCDN, > or does > >>>> the uCDN > >>>> retain that locus of control for itself. The later design, which > >>>> essentially treats > >>>> the dCDN as it would any other cache (at least with respect to > metadata), > >>>> seems > >>>> the simplest to me. > >>>> > >>>> Larry > >>>> > >>>> On Aug 4, 2011, at 10:48 AM, Johan Rydberg wrote: > >>>> > >>>>> Richard, > >>>>> > >>>>> I just got a bit scared when I saw discussions about features > that "may > >>>>> be good to have" > >>>>> or "it would be nice to support". > >>>>> > >>>>> I guess all I wanted to say was that everyone would benefit from a > >>>>> minimized scoop. > >>>>> > >>>>> On 8/4/11 4:34 PM, Woundy, Richard wrote: > >>>>>> A couple of observations, as an individual and not a working group > >>>> chair. > >>>>>> > >>>>>> > >>>>>>> Instead of constructing a complex metadata exchange protocol > >>>>>>> > >>>>>> How about we construct a *simple* metadata exchange protocol? :) > >>>>>> > >>>>>> I believe we are anticipating this protocol to be XML/JSON over > HTTP. > >>>>>> > >>>>>> > >>>>>>> I have a feeling that if the interconnect protocols are not > limited in > >>>> scope, this CDNI effort will either (1) fail or (2) be in some > "design > >>>> phase" for ever. > >>>>>>> > >>>>>> CDNI was approved as a WG in late June. Now it is early August and > >>>> we're already in danger of failing? Hmmm. > >>>>>> > >>>>>> It feels to me like we are debating theoretical scenarios. > Johan, if > >>>> you feel strongly about eliminating this interface, maybe you > could write > >>>> up your proposal as an internet-draft that we can discuss and > debate? We > >>>> also need to ensure that your proposal meets the use cases > identified by > >>>> this group. > >>>>>> > >>>>>> -- Rich > >>>>>> > >>>>>> -----Original Message----- > >>>>>> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On > Behalf Of > >>>> Johan Rydberg > >>>>>> Sent: Thursday, August 04, 2011 6:16 AM > >>>>>> To: Ben Niven-Jenkins > >>>>>> Cc: cdni@ietf.org > >>>>>> Subject: Re: [CDNi] upstream cdn enforce content policies > >>>>>> > >>>>>> On 8/4/11 12:10 PM, Ben Niven-Jenkins wrote: > >>>>>> > >>>>>>> Johan, > >>>>>>> > >>>>>>> On 4 Aug 2011, at 10:52, Johan Rydberg wrote: > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> After following the discussions for a while, I have a question: > >>>>>>>> > >>>>>>>> Instead of constructing a complex metadata exchange protocol, > >>>>>>>> why not force the upstream CDN to enforce any prolicy rules that > >>>>>>>> the CSP has put on the content? > >>>>>>>> > >>>>>>>> > >>>>>>> That would not provide sufficient coverage to ensure that the > policy > >>>> is enforced as clients may attempt to request content directly from a > >>>> downstream CDN, bypassing the upstream CDN. > >>>>>>> > >>>>>>> > >>>>>> There must be ways to make sure that the client first passes > through > >>>> the > >>>>>> upstream > >>>>>> CDN. > >>>>>> > >>>>>> I have a feeling that if the interconnect protocols are not > limited in > >>>>>> scope, this > >>>>>> CDNI effort will either (1) fail or (2) be in some "design > phase" for > >>>> ever. > >>>>>> > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> In the case of DNS-based routing, the CDN can answer the DNS > >>>>>>>> lookup with the address of one of its own CDNI request routers > >>>>>>>> that will enforce any policies before redirecting (HTTP 302) to > >>>>>>>> a downstream CDN. > >>>>>>>> > >>>>>>>> The upside to this is that redirects between CDNs will always be > >>>>>>>> HTTP 302, regardless if the initial mechanism was DNS-based. > >>>>>>>> Also, the complex metadata protocol can be elimited, minimizing > >>>>>>>> the scope of the CDNI work. > >>>>>>>> > >>>>>>>> > >>>>>>> Even if one could avoid the need for a downstream CDN to apply > some > >>>> policies, this wouldn't eliminate the need to exchange CDNI > metadata as > >>>> other CDNI metadata such as rate limiting, whether an encrypted > channel is > >>>> required, where to obtain the content from etc. is still required. > >>>>>>> > >>>>>>> > >>>>>> It sounds like most of those could be folded into the request > routing > >>>>>> protocol. > >>>>>> Rate limiting and encryption might not be attributes of the > content, > >>>> but > >>>>>> rather > >>>>>> of the client. (Some customers pay more, and get a higher > bitrate for > >>>>>> example) > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> CDNi mailing list > >>>>>> CDNi@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/cdni > >>>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> CDNi mailing list > >>>>> CDNi@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/cdni > >>>> > >>>> _______________________________________________ > >>>> CDNi mailing list > >>>> CDNi@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/cdni > >> > >> _______________________________________________ > >> CDNi mailing list > >> CDNi@ietf.org > >> https://www.ietf.org/mailman/listinfo/cdni > > > > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > --------------070206030105050505090700 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Richard,

    I too am confused about the use of the Metadata interface to relay metadata.  Seems the term metadata is overloaded and can mean 'anything we deem relevant' which will get us in trouble.  In looking through the requirements document, I can see concrete evidence of specific information in the following:

R50: acquisition protocol and uri of the content to be pre-positioned or dynamically acquired
R51: list of candidate Origin sources
R58: metadata exchange status
R59: policies; presumably policies associated with an object or set of objects
R60: authorization checks

Perhaps these elements represent a few of the 'core' metadata of which we speak.

When I think of metadata, I usually think of it in the context of metadata for a specific object.  For example, a media file will need metadata that describes the use of the media (offering date, expiration date, black-out locations, trick mode restrictions, transcode restrictions, cipher requirements, etc.).  The metadata is not in the media; the metadata must be associated with the media.  This is typically done by packaging the media and metadata together.  If we're talking about dynamic acquisition or pre-positioning of the media only, then we will need some means of relaying the associated metadata.

The capabilities of the dCDN seemed to be defined in the Routing Request requirements.  Need to delineate where the policies in R59 are handled .. Routing Request or Metadata.

Scott

On 8/5/11 1:10 PM, Woundy, Richard wrote:
Re: [CDNi] upstream cdn enforce content policies

Speaking personally...

> My sense is that metadata is in a semantically rich space (at least relative to a CDN's pure caching function), and so reaching agreement on universal CDN metadata is going to be a challenge.

Maybe we are aiming for the wrong goal. Instead of agreement on "universal" CDN metadata, we should be aiming for "core" CDN metadata -- what do we agree we need (as a consensus)?

If there is "universal" metadata that we *might* need, we could leverage vendor extensions to the initial metadata interface, and/or include them in a future version of the specification.

If we cannot agree on any "core" metadata, then we should closely examine to see if we still need the metadata interface.

-- Rich

-----Original Message-----
From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Peterson, Larry
Sent: Friday, August 05, 2011 8:45 AM
To: Ben Niven-Jenkins
Cc: cdni@ietf.org
Subject: Re: [CDNi] upstream cdn enforce content policies

Ben,

I think the phrasing of your question makes my point. In one model,
there remains a strong coupling. The uCDN is involved in every request
routing decision (for example), and hence, retains the ability to interject
itself (and its customer's will) on content delivery. In the other model,
the uCDN delegates (through metadata) all responsibility to the dCDN.

Is that level of coupling undesirable? In m view, no. Certainly I think we
can agree the uCDN is going to be involved in request routing since the
URL is going to contain a domain name that the uCDN is going to have
deal with one way or another. I hope we can also agree that the dCDN
is going to need to respect caching directives, so I don't see the problem
with taking advantage of that.

Let me turn this around and talk about why I'm worried that the metadata
interface is going to be tricky... and maybe people will correct me on this.
My sense is that metadata is in a semantically rich space (at least relative
to a CDN's pure caching function), and so reaching agreement on universal
CDN metadata is going to be a challenge.

Larry

On Aug 4, 2011, at 7:19 PM, Ben Niven-Jenkins wrote:

> Larry,
>
> On 4 Aug 2011, at 20:14, Peterson, Larry wrote:
>
>> Good questions... In my mind, the metadata interface is used to delegate
>> responsibility from uCDN to dCDN. The CSP still has to trust that the dCDN
>> behaves according to the metadata it's passed. Alternatively, the CSP trusts
>> that the uCDN -- with which it has a contractual agreement -- to "stay in
>> the loop" and keep a tighter leash on what the dCDN does (e.g., make a
>> decision on each request it routes, issues purge commands when necessary,
>> and adds cache directives as necessary). Yes, we have to trust the dCDN to
>> observe cache directives, so you could argue both strategies involve trusting
>> the dCDN, but you could also argue that the latter approach narrows the
>> window of vulnerability if trust is violated.
>
> Can you expand on that argument because I can't see how the latter approach narrows the window of vulnerability without introducing an undesirable level of coupling between the upstream & downstream CDNs?
>
> Thanks
> Ben
>
>>
>> As to the position that "we just as well define the interface in case some pair
>> of CDNs want to use it"... sure, but every bit of mechanism comes at some cost
>> in complexity.
>>
>> Larry
>>
>> On Aug 4, 2011, at 3:00 PM, Kevin J Ma wrote:
>>
>>>> The question is: does interconnection imply that uCDN further delegates that
>>>> responsibility for enforcing access control policy to the dCDN, or does the uCDN
>>>> retain that locus of control for itself.
>>>
>>> I think the issue is more the threat that a CSP may have an agreement with
>>> the uCDN, which it has paid for, which may not be enforceable through dCDNs.
>>> It is not clear that a uCDN can always enforce those policies.  It is not that
>>> hard to figure out where the content is really coming from (i.e., the dCDN).
>>> Will CSPs, who tend to be risk averse, just disallow delegation?
>>>
>>> Sticking with the minimalist approach, I still think there is value in a
>>> standardized method of exchanging opaque metadata.  If some CDNs agree
>>> amongst themselves (outside of CDNI) to enforce policies, they will most
>>> likely need to exchange metadata?  Having a well defined protocol to do so
>>> seems like an important first step?
>>>
>>>
>>>> -----Original Message-----
>>>> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of
>>>> Peterson, Larry
>>>> Sent: Thursday, August 04, 2011 11:31 AM
>>>> To: Johan Rydberg
>>>> Cc: cdni@ietf.org
>>>> Subject: Re: [CDNi] upstream cdn enforce content policies
>>>>
>>>> Picking up on Johan's minimized scope thread...
>>>>
>>>> I too have been puzzled by the metadata interface. If you read the
>>>> language
>>>> carefully, you'll see there's a caveat that this interface might exist in
>>>> various
>>>> forms, presumably as a combination of other interfaces and mechanisms,
>>>> for example:
>>>> o the uCDN doesn't route the request to the dCDN unless policy permits;
>>>> o the uCDN sets HTTP caching directives consistent with policy and the
>>>>    dCDN obeys those directives; and
>>>> o the uCDN invokes purge on dCDN should the policy change.
>>>>
>>>> But that generous interpretation aside, the high level issue seems to be
>>>> how
>>>> access control policy is enforced. In a single CDN it's natural for this
>>>> policy to
>>>> be enforced by the CDN, and there's likely a metadata-like interface by
>>>> which
>>>> the CSP expresses this policy to that CDN.
>>>>
>>>> The question is: does interconnection imply that uCDN further delegates
>>>> that
>>>> responsibility for enforcing access control policy to the dCDN, or does
>>>> the uCDN
>>>> retain that locus of control for itself. The later design, which
>>>> essentially treats
>>>> the dCDN as it would any other cache (at least with respect to metadata),
>>>> seems
>>>> the simplest to me.
>>>>
>>>> Larry
>>>>
>>>> On Aug 4, 2011, at 10:48 AM, Johan Rydberg wrote:
>>>>
>>>>> Richard,
>>>>>
>>>>> I just got a bit scared when I saw discussions about features that "may
>>>>> be good to have"
>>>>> or "it would be nice to support".
>>>>>
>>>>> I guess all I wanted to say was that everyone would benefit from a
>>>>> minimized scoop.
>>>>>
>>>>> On 8/4/11 4:34 PM, Woundy, Richard wrote:
>>>>>> A couple of observations, as an individual and not a working group
>>>> chair.
>>>>>>
>>>>>>
>>>>>>> Instead of constructing a complex metadata exchange protocol
>>>>>>>
>>>>>> How about we construct a *simple* metadata exchange protocol? :)
>>>>>>
>>>>>> I believe we are anticipating this protocol to be XML/JSON over HTTP.
>>>>>>
>>>>>>
>>>>>>> I have a feeling that if the interconnect protocols are not limited in
>>>> scope, this CDNI effort will either (1) fail or (2) be in some "design
>>>> phase" for ever.
>>>>>>>
>>>>>> CDNI was approved as a WG in late June. Now it is early August and
>>>> we're already in danger of failing? Hmmm.
>>>>>>
>>>>>> It feels to me like we are debating theoretical scenarios. Johan, if
>>>> you feel strongly about eliminating this interface, maybe you could write
>>>> up your proposal as an internet-draft that we can discuss and debate? We
>>>> also need to ensure that your proposal meets the use cases identified by
>>>> this group.
>>>>>>
>>>>>> -- Rich
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of
>>>> Johan Rydberg
>>>>>> Sent: Thursday, August 04, 2011 6:16 AM
>>>>>> To: Ben Niven-Jenkins
>>>>>> Cc: cdni@ietf.org
>>>>>> Subject: Re: [CDNi] upstream cdn enforce content policies
>>>>>>
>>>>>> On 8/4/11 12:10 PM, Ben Niven-Jenkins wrote:
>>>>>>
>>>>>>> Johan,
>>>>>>>
>>>>>>> On 4 Aug 2011, at 10:52, Johan Rydberg wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> After following the discussions for a while, I have a question:
>>>>>>>>
>>>>>>>> Instead of constructing a complex metadata exchange protocol,
>>>>>>>> why not force the upstream CDN to enforce any prolicy rules that
>>>>>>>> the CSP has put on the content?
>>>>>>>>
>>>>>>>>
>>>>>>> That would not provide sufficient coverage to ensure that the policy
>>>> is enforced as clients may attempt to request content directly from a
>>>> downstream CDN, bypassing the upstream CDN.
>>>>>>>
>>>>>>>
>>>>>> There must be ways to make sure that the client first passes through
>>>> the
>>>>>> upstream
>>>>>> CDN.
>>>>>>
>>>>>> I have a feeling that if the interconnect protocols are not limited in
>>>>>> scope, this
>>>>>> CDNI effort will either (1) fail or (2) be in some "design phase" for
>>>> ever.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> In the case of DNS-based routing, the CDN can answer the DNS
>>>>>>>> lookup with the address of one of its own CDNI request routers
>>>>>>>> that will enforce any policies before redirecting (HTTP 302) to
>>>>>>>> a downstream CDN.
>>>>>>>>
>>>>>>>> The upside to this is that redirects between CDNs will always be
>>>>>>>> HTTP 302, regardless if the initial mechanism was DNS-based.
>>>>>>>> Also, the complex metadata protocol can be elimited, minimizing
>>>>>>>> the scope of the CDNI work.
>>>>>>>>
>>>>>>>>
>>>>>>> Even if one could avoid the need for a downstream CDN to apply some
>>>> policies, this wouldn't eliminate the need to exchange CDNI metadata as
>>>> other CDNI metadata such as rate limiting, whether an encrypted channel is
>>>> required, where to obtain the content from etc. is still required.
>>>>>>>
>>>>>>>
>>>>>> It sounds like most of those could be folded into the request routing
>>>>>> protocol.
>>>>>> Rate limiting and encryption might not be attributes of the content,
>>>> but
>>>>>> rather
>>>>>> of the client.  (Some customers pay more, and get a higher bitrate for
>>>>>> example)
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> CDNi mailing list
>>>>>> CDNi@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/cdni
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> CDNi mailing list
>>>>> CDNi@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/cdni
>>>>
>>>> _______________________________________________
>>>> CDNi mailing list
>>>> CDNi@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/cdni
>>
>> _______________________________________________
>> CDNi mailing list
>> CDNi@ietf.org
>> https://www.ietf.org/mailman/listinfo/cdni
>

_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/cdni
_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/cdni


--------------070206030105050505090700-- From hexiaoyan@huawei.com Wed Aug 10 19:30:58 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6A8811E8086 for ; Wed, 10 Aug 2011 19:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[AWL=3.800, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lxt2ahj1lB2y for ; Wed, 10 Aug 2011 19:30:58 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id D068C11E8083 for ; Wed, 10 Aug 2011 19:30:57 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPQ007UXSB7KY@szxga05-in.huawei.com> for cdni@ietf.org; Thu, 11 Aug 2011 10:30:43 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPQ00DSJSB6ZE@szxga05-in.huawei.com> for cdni@ietf.org; Thu, 11 Aug 2011 10:30:42 +0800 (CST) Received: from w36710x ([10.144.242.54]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LPQ007CSSB07L@szxml06-in.huawei.com> for cdni@ietf.org; Thu, 11 Aug 2011 10:30:42 +0800 (CST) Date: Thu, 11 Aug 2011 10:30:31 +0800 From: He Xiaoyan To: "'Francois Le Faucheur (flefauch)'" , "'Woundy, Richard'" Message-id: <02ae01cc57ce$a9340560$36f2900a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_nWSBl/DnGIQaOUlQcU/+9g)" Thread-index: AcxXzqO4r7S5BiOzToyyL21P37xwsw== Cc: cdni@ietf.org Subject: [CDNi] When the meeting minutes would be available? X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 02:30:58 -0000 This is a multi-part message in MIME format. --Boundary_(ID_nWSBl/DnGIQaOUlQcU/+9g) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Francois and Richard, Can I ask when the Quebec meeting minutes would be available? Thanks. Best Regards Xiaoyan(Susan) He --Boundary_(ID_nWSBl/DnGIQaOUlQcU/+9g) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi Francois and = Richard,

Can I ask when the Quebec meeting minutes would be = available?

Thanks.

 

Best Regards

Xiaoyan(Susan) He

 

--Boundary_(ID_nWSBl/DnGIQaOUlQcU/+9g)-- From swainner@cisco.com Thu Aug 11 05:51:42 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1205221F87C9 for ; Thu, 11 Aug 2011 05:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gO6iGhcNm1vf for ; Thu, 11 Aug 2011 05:51:40 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 48FAE21F8783 for ; Thu, 11 Aug 2011 05:51:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=swainner@cisco.com; l=28438; q=dns/txt; s=iport; t=1313067134; x=1314276734; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=+F1sF/31hAifodglZyy5cvZc+f835an/h8UBuskvpME=; b=DQz7K+2jX+p1tXTcJj/70ygshP70BxYOnTGDz+yjJOjnaSieWlY/NP0c GlQMHQoFhovYBz3NqdEGVrS6aGtzNj3PfJD29gPUDbNxk1jshe+UgzTMV 4W3vl6miv9IQ02HK2E0H2evqkvgWO0upeP73/h7NURGRZufW9bXRT1JEb o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUBAA/QQ06tJV2c/2dsb2JhbAAULYJNlTCPSXeBQAEBAQECAQEBAQ8BWwoGBwQLEQQBAQEJFgEHBwkDAgECAQ8GHwkIEwYCAQEeh00Ei22SDQGfA4ZHBJMOiXOHGA X-IronPort-AV: E=Sophos;i="4.67,355,1309737600"; d="scan'208,217";a="12156287" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 11 Aug 2011 12:52:13 +0000 Received: from rtp-vpn3-1393.cisco.com (rtp-vpn3-1393.cisco.com [10.82.221.119]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p7BCqB30004582 for ; Thu, 11 Aug 2011 12:52:12 GMT Message-ID: <4E43D0E0.5000301@cisco.com> Date: Thu, 11 Aug 2011 08:53:52 -0400 From: Scott Wainner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: cdni@ietf.org References: <1AC8E92C-3A69-4C80-A235-710DEF396A53@cisco.com><2979E38DD6FC6544B789C8DAD7BAFC520F72CD55@xmb-sjc-235.amer.cisco.com><0160D539-A630-4BCB-BC25-D50881FCFEDF@niven-jenkins.co.uk><291CC3F9E50E7641901A54E85D0977C6518C23927B@MAILR002.mail.lan><291CC3F9E50E7641901A54E85D0977C6518C23931A@MAILR002.mail.lan><2979E38DD6FC6544B789C8DAD7BAFC520F87639C@xmb-sjc-235.amer.cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060103010109060607060205" Subject: Re: [CDNi] comments on draft-bertrand-cdni-use-cases-02 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 12:51:42 -0000 This is a multi-part message in MIME format. --------------060103010109060607060205 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Indeed there are cases where cached content needs to be purged prior to expiration. For example, the quality of a transcoded asset may be unsatisfactory leading the CSP to issue a purge request to flush the cache prior to content expiration. The assumption is made that a new media version is published using the previously defined metadata and we want the CDN's to re-populate its cache with the updated version of the media. In lieu of this capability, the corrupt content may continue to be served until the natural expiration of the cache or availability window. Scott On 8/4/11 5:53 PM, Vishwas Manral wrote: > Agree with you there Kent. > But the control interface is not the default mechanism for sure, its > used as an exception. > -Vishwas > On Thu, Aug 4, 2011 at 2:09 PM, Kent Leung (kleung) > wrote: > > The CDNI Control Interfaces enables the removal of content > asynchronously for reasons that could be administrative, legal, > etc. which are not based on a scheduled time. For example, a > content may have metadata to expire in one week. But some legal > ruling requires the content to be removed from distribution & > delivery before that time. Then the CDNI Control Interface can be > used to accomplish that. The requirement for asynchronous removal > is explicit acknowledgement. > > Kent > > *From:*cdni-bounces@ietf.org > [mailto:cdni-bounces@ietf.org ] *On > Behalf Of *Kevin J Ma > *Sent:* Thursday, August 04, 2011 2:03 PM > *To:* Vishwas Manral > *Cc:* cdni@ietf.org ; > draft-bertrand-cdni-use-cases@tools.ietf.org > > > *Subject:* Re: [CDNi] comments on draft-bertrand-cdni-use-cases-02 > > Hi Vishwas, > > One could certainly implement an instantaneous purge by setting the > > expiration date to the current time, but I believe the one advantage > > of using the control interface was going to be some type of explicit > > acknowledgement (synchronous or asynchronous) for purge complete. > > It may be that this could be done another way as well (perhaps via > > the logging interface), but that was the distinction, as I recall. > > thanx. > > -- Kevin J. Ma > > *From:*Vishwas Manral [mailto:vishwas.ietf@gmail.com > ] > *Sent:* Thursday, August 04, 2011 3:50 PM > *To:* Kevin J Ma > *Cc:* Ben Niven-Jenkins; Francois Le Faucheur; cdni@ietf.org > ; > draft-bertrand-cdni-use-cases@tools.ietf.org > > *Subject:* Re: [CDNi] comments on draft-bertrand-cdni-use-cases-02 > > Hi Kevin, > > I would think the data should have the expiration times for sure. > > Time based content, which uses control messages to purge can have > issues which could be result of connectivity. I am not sure why > there should be any control messages for purge at all. > > Thanks, > > Vishwas > > On Thu, Aug 4, 2011 at 12:36 PM, Kevin J Ma @azukisystems.com > wrote: > > Hi Ben, > > I would expect that once the expiration time is reached, all > copies of the > content would be expunged from any surrogates/storage devices. > > I believe there was discussion a while back about whether to only > use the > control interface to issue purge requests, or whether to use > metadata to > set expiration dates, or to allow both? In the event of both, I > would > think both functions should act the same, i.e., when the > expiration date > is reached, it is just like a uCDN sent a purge request. > > thanx. > > -- Kevin J. Ma > > > > -----Original Message----- > > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk > ] > > > Sent: Thursday, August 04, 2011 10:23 AM > > To: Francois Le Faucheur > > > Cc: Kent Leung (kleung); cdni@ietf.org ; > draft-bertrand-cdni-use- > > cases@tools.ietf.org > > Subject: Re: [CDNi] comments on draft-bertrand-cdni-use-cases-02 > > > > Use Case authors, Colleagues, > > > > On 28 Jul 2011, at 21:16, Francois Le Faucheur wrote: > > > > > Kent and all, > > > > > > On 28 Jul 2011, at 16:10, Kent Leung (kleung) wrote: > > > > > >> Hi Francois. Responding to comments related to the > requirements draft > > >> below. > > >> > > >> > > >> o an expiration time (i.e., the time at which the content > files > > >> should be expunged from all CDN storage). > > >> " > > >> I understand this is saying that CDNI metadata need to > include this > > >> expiration time (triggering cache removal) , in addition to > > deactivation > > >> time. > > >> I don't think this is discussed in cdni-requirements yet. Can > you bring > > >> that up on the list with the cdni-reqts authors? > > >> > > >> KL> I've seen references to content expiration time (i.e. > removal) in > > >> some drafts. So it seems to be needed in the CDNI Metadata. > Noted as > > >> requirement (possibly part of availability window) unless others > > object. > > > > > > FLF as an Individual: that works for me. > > > > I'd like to understand the underlying requirement a bit better > as it's not > > clear to me what the expected behaviour of a surrogate would be when > > receiving a request for the content after the "expiration time" > is reached > > as well as how the surrogate is supposed to treat any cached > copy of the > > content held in either volatile or non-volatile storage. > > > > For example, when receiving a request for content after the > "expiration > > time" is reached, is a surrogate required to: > > - No longer deliver the content, even if presented with a valid > request to > > do? > > - Consider any cached copy of the content as "stale" and > revalidate the > > content against the Origin, delivering the content if revalidation > > succeeds and not delivering the content if revalidation fails. > > > > For example, for any cached copy of the content after the > "expiration > > time" is reach, is a surrogate required to: > > - Nothing more than whatever it is supposed to do in the example > above and > > use its normal cache expiration procedures to recovery the > storage space > > used like it would for "stale" content that does not have an > explicit > > expiration time? > > - Actively keep track of cached content & its associated > expiration time > > and actively "de-link" (e.g. remove from the filesystem table) > the cached > > copy of the content? > > - Actively keep track of cached content & its associated > expiration time > > and actively overwrite the storage sectors containing that > content in both > > volatile & non-volatile storage? > > > > Thanks > > Ben > > > > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > > --------------060103010109060607060205 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Indeed there are cases where cached content needs to be purged prior to expiration.

For example, the quality of a transcoded asset may be unsatisfactory leading the CSP to issue a purge request to flush the cache prior to content expiration.  The assumption is made that a new media version is published using the previously defined metadata and we want the CDN's to re-populate its cache with the updated version of the media.  In lieu of this capability, the corrupt content may continue to be served until the natural expiration of the cache or availability window.

Scott

On 8/4/11 5:53 PM, Vishwas Manral wrote:
Agree with you there Kent.
 
But the control interface is not the default mechanism for sure, its used as an exception.
 
-Vishwas
On Thu, Aug 4, 2011 at 2:09 PM, Kent Leung (kleung) <kleung@cisco.com> wrote:

The CDNI Control Interfaces enables the removal of content asynchronously for reasons that could be administrative, legal, etc. which are not based on a scheduled time.  For example, a content may have metadata to expire in one week.  But some legal ruling requires the content to be removed from distribution & delivery before that time.  Then the CDNI Control Interface can be used to accomplish that.  The requirement for asynchronous removal is explicit acknowledgement.

 

Kent

 

From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Kevin J Ma
Sent: Thursday, August 04, 2011 2:03 PM
To: Vishwas Manral
Cc: cdni@ietf.org; draft-bertrand-cdni-use-cases@tools.ietf.org


Subject: Re: [CDNi] comments on draft-bertrand-cdni-use-cases-02

 

Hi Vishwas,

 

  One could certainly implement an instantaneous purge by setting the

  expiration date to the current time, but I believe the one advantage

  of using the control interface was going to be some type of explicit

  acknowledgement (synchronous or asynchronous) for purge complete.

  It may be that this could be done another way as well (perhaps via

  the logging interface), but that was the distinction, as I recall.

 

thanx.

 

--  Kevin J. Ma

 

From: Vishwas Manral [mailto:vishwas.ietf@gmail.com]
Sent: Thursday, August 04, 2011 3:50 PM
To: Kevin J Ma
Cc: Ben Niven-Jenkins; Francois Le Faucheur; cdni@ietf.org; draft-bertrand-cdni-use-cases@tools.ietf.org
Subject: Re: [CDNi] comments on draft-bertrand-cdni-use-cases-02

 

Hi Kevin,

 

I would think the data should have the expiration times for sure.

 

Time based content, which uses control messages to purge can have issues which could be result of connectivity. I am not sure why there should be any control messages for purge at all.

 

Thanks,

Vishwas

On Thu, Aug 4, 2011 at 12:36 PM, Kevin J Ma <kevin.ma@azukisystems.com> wrote:

Hi Ben,

 I would expect that once the expiration time is reached, all copies of the
 content would be expunged from any surrogates/storage devices.

 I believe there was discussion a while back about whether to only use the
 control interface to issue purge requests, or whether to use metadata to
 set expiration dates, or to allow both?  In the event of both, I would
 think both functions should act the same, i.e., when the expiration date
 is reached, it is just like a uCDN sent a purge request.

thanx.

--  Kevin J. Ma


> -----Original Message-----
> From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk]

> Sent: Thursday, August 04, 2011 10:23 AM
> To: Francois Le Faucheur

> Cc: Kent Leung (kleung); cdni@ietf.org; draft-bertrand-cdni-use-
> cases@tools.ietf.org
> Subject: Re: [CDNi] comments on draft-bertrand-cdni-use-cases-02
>
> Use Case authors, Colleagues,
>
> On 28 Jul 2011, at 21:16, Francois Le Faucheur wrote:
>
> > Kent and all,
> >
> > On 28 Jul 2011, at 16:10, Kent Leung (kleung) wrote:
> >
> >> Hi Francois.  Responding to comments related to the requirements draft
> >> below.
> >>
> >>
> >>   o  an expiration time (i.e., the time at which the content files
> >>      should be expunged from all CDN storage).
> >> "
> >> I understand this is saying that CDNI metadata need to include this
> >> expiration time (triggering cache removal) , in addition to
> deactivation
> >> time.
> >> I don't think this is discussed in cdni-requirements yet. Can you bring
> >> that up on the list with the cdni-reqts authors?
> >>
> >> KL> I've seen references to content expiration time (i.e. removal) in
> >> some drafts.  So it seems to be needed in the CDNI Metadata.  Noted as
> >> requirement (possibly part of availability window) unless others
> object.
> >
> > FLF as an Individual: that works for me.
>
> I'd like to understand the underlying requirement a bit better as it's not
> clear to me what the expected behaviour of a surrogate would be when
> receiving a request for the content after the "expiration time" is reached
> as well as how the surrogate is supposed to treat any cached copy of the
> content held in either volatile or non-volatile storage.
>
> For example, when receiving a request for content after the "expiration
> time" is reached, is a surrogate required to:
> - No longer deliver the content, even if presented with a valid request to
> do?
> - Consider any cached copy of the content as "stale" and revalidate the
> content against the Origin, delivering the content if revalidation
> succeeds and not delivering the content if revalidation fails.
>
> For example, for any cached copy of the content after the "expiration
> time" is reach, is a surrogate required to:
> - Nothing more than whatever it is supposed to do in the example above and
> use its normal cache expiration procedures to recovery the storage space
> used like it would for "stale" content that does not have an explicit
> expiration time?
> - Actively keep track of cached content & its associated expiration time
> and actively "de-link" (e.g. remove from the filesystem table) the cached
> copy of the content?
> - Actively keep track of cached content & its associated expiration time
> and actively overwrite the storage sectors containing that content in both
> volatile & non-volatile storage?
>
> Thanks
> Ben
>

_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/cdni

 



--------------060103010109060607060205-- From philip.eardley@bt.com Thu Aug 11 07:40:06 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D5F521F8A70 for ; Thu, 11 Aug 2011 07:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=-0.131, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p4ghTAEZpVjl for ; Thu, 11 Aug 2011 07:40:05 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp61.intersmtp.COM [62.239.224.234]) by ietfa.amsl.com (Postfix) with ESMTP id B805721F886A for ; Thu, 11 Aug 2011 07:40:04 -0700 (PDT) Received: from EVMHT63-UKRD.domain1.systemhost.net (10.36.3.100) by RDW083A005ED61.smtp-e1.hygiene.service (10.187.98.10) with Microsoft SMTP Server (TLS) id 8.3.159.2; Thu, 11 Aug 2011 15:40:38 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.71]) by EVMHT63-UKRD.domain1.systemhost.net ([10.36.3.100]) with mapi; Thu, 11 Aug 2011 15:40:38 +0100 From: To: Date: Thu, 11 Aug 2011 15:40:36 +0100 Thread-Topic: Recursive & Iterative definitions Thread-Index: AcxYNKI3uWCmJztWT/KxAIQEVa7EUw== Message-ID: <9510D26531EF184D9017DF24659BB87F32E4C7B375@EMV65-UKRD.domain1.systemhost.net> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_9510D26531EF184D9017DF24659BB87F32E4C7B375EMV65UKRDdoma_" MIME-Version: 1.0 Subject: [CDNi] Recursive & Iterative definitions X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 14:40:06 -0000 --_000_9510D26531EF184D9017DF24659BB87F32E4C7B375EMV65UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Currently the definitions for Recursive & Iterative CDNI Request Routing ap= pear in the use-cases document. The authors had some discussion that the de= finitions could be clearer. Below is a possible variant. I think that all the definitions are being moved into one document? - so th= is is just a suggestion for the editor of the Definitions document Recursive & Iterative CDNI Request Routing CDNI request routing involves the Upstream CDN electing to redirect a route= request towards a Downstream CDN. There are two possibilities for what happens next 1. (recursive) the Downstream CDN advises the Upstream CDN how to han= dle the route request. For example, it might (1) indicate one of its own su= rrogates or (2) a third CDN to try. The Upstream CDN then sends a new route= request (1) to the second CDN's surrogate or (2) towards the third CDN. 2. (iterative) the Downstream CDN decides how to handle the route req= uest without referring back to the Upstream CDN. It could forward the route= request, for example, (1) to one of its own surrogates or (2) towards a th= ird CDN. In the latter case, it now plays the role of the Upstream CDN and = the third CDN acts as a Downstream CDN. A picture would help as well Best wishes Phil/ Philip Eardley Research and Technology Strategy This email contains BT information, which may be privileged or confidential= . It's meant only for the individual(s) or entity named above. If you're no= t the intended recipient, note that disclosing, copying, distributing or us= ing this information is prohibited. If you've received this email in error,= please let me know immediately on the email address above. Thank you. We m= onitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 --_000_9510D26531EF184D9017DF24659BB87F32E4C7B375EMV65UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

=

Currently t= he definitions for Recursive & Iterative CDNI Request Routing appear in= the use-cases document. The authors had some discussion that the definitio= ns could be clearer. Below is a possible variant.

 

I think that all the definitions are being moved into one document? - so = this is just a suggestion for the editor of the Definitions document <= /o:p>

 

 

Recursive & Iterative CDNI Reque= st Routing

CDNI request routing involves the Upstream CDN electin= g to redirect a route request towards a Downstream CDN. <= /p>

There ar= e two possibilities for what happens next

1.      = ; (recursive) the Downst= ream CDN advises the Upstream CDN how to handle the route request. For exam= ple, it might (1) indicate one of its own surrogates or (2) a third CDN to = try. The Upstream CDN then sends a new route request (1) to the second CDN&= #8217;s surrogate or (2) towards the third CDN.

= 2.    &nbs= p;  (iterative) the= Downstream CDN decides how to handle the route request without referring b= ack to the Upstream CDN. It could forward the route request, for example, (= 1) to one of its own surrogates or (2) towards a third CDN. In the latter c= ase, it now plays the role of the Upstream CDN and the third CDN acts as a = Downstream CDN.

A picture would h= elp as well

 

Best wishes

Phil/

 

&= nbsp;

 

 

Philip Eardley   
Research and T= echnology Strategy

This email contains BT in= formation, which may be privileged or confidential. It's meant only for the= individual(s) or entity named above. If you're not the intended recipient,= note that disclosing, copying, distributing or using this information is p= rohibited. If you've received this email in error, please let me know immed= iately on the email address above. Thank you. We monitor our email system, = and may record your emails.

British Telecommunications pl= c
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in = England no: 1800000

 

= --_000_9510D26531EF184D9017DF24659BB87F32E4C7B375EMV65UKRDdoma_-- From richard_woundy@cable.comcast.com Thu Aug 11 15:26:57 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E570821F86BF for ; Thu, 11 Aug 2011 15:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.031 X-Spam-Level: X-Spam-Status: No, score=-102.031 tagged_above=-999 required=5 tests=[AWL=-0.297, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sCMGFWzeeXm0 for ; Thu, 11 Aug 2011 15:26:57 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id BFFE621F86AA for ; Thu, 11 Aug 2011 15:26:56 -0700 (PDT) Received: from ([24.40.55.42]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.48528918; Thu, 11 Aug 2011 16:32:20 -0600 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%11]) with mapi id 14.01.0289.001; Thu, 11 Aug 2011 18:27:04 -0400 From: "Woundy, Richard" To: He Xiaoyan , "'Francois Le Faucheur (flefauch)'" Thread-Topic: When the meeting minutes would be available? Thread-Index: AcxXzqO4r7S5BiOzToyyL21P37xwswApr/Yg Date: Thu, 11 Aug 2011 22:27:01 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD113629B43@PACDCEXMB05.cable.comcast.com> References: <02ae01cc57ce$a9340560$36f2900a@china.huawei.com> In-Reply-To: <02ae01cc57ce$a9340560$36f2900a@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.163.75.13] Content-Type: multipart/alternative; boundary="_000_1CA25301D2219F40B3AA37201F0EACD113629B43PACDCEXMB05cabl_" MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] When the meeting minutes would be available? X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 22:26:58 -0000 --_000_1CA25301D2219F40B3AA37201F0EACD113629B43PACDCEXMB05cabl_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Xiaoyan, my apologies but I am still working on consolidating the fine meet= ing minutes from Daryl Malas and Ray van Brandenburg, as well as reconcilin= g from my own notes. I hope to have them completed by this weekend, barring= any other work interruptions... From: He Xiaoyan [mailto:hexiaoyan@huawei.com] Sent: Wednesday, August 10, 2011 10:31 PM To: 'Francois Le Faucheur (flefauch)'; Woundy, Richard Cc: cdni@ietf.org Subject: When the meeting minutes would be available? Hi Francois and Richard, Can I ask when the Quebec meeting minutes would be available? Thanks. Best Regards Xiaoyan(Susan) He --_000_1CA25301D2219F40B3AA37201F0EACD113629B43PACDCEXMB05cabl_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Xiaoyan, my apologies but I am still working on consolidatin= g the fine meeting minutes from Daryl Malas and Ray van Brandenburg, as wel= l as reconciling from my own notes. I hope to have them completed by this weekend, barring any o= ther work interruptions…

 

From: He Xiaoyan [mailto:hexiaoyan@huawei.com]
Sent: Wednesday, August 10, 2011 10:31 PM
To: 'Francois Le Faucheur (flefauch)'; Woundy, Richard
Cc: cdni@ietf.org
Subject: When the meeting minutes would be available?

 =

Hi Francois and Richard,=

Can I ask when the Quebec meeting minutes = would be available?

Thanks.

 

Best Regards=

Xiaoyan(Susan) He

 

--_000_1CA25301D2219F40B3AA37201F0EACD113629B43PACDCEXMB05cabl_-- From hexiaoyan@huawei.com Thu Aug 11 18:13:28 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DC8821F8A91 for ; Thu, 11 Aug 2011 18:13:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.914 X-Spam-Level: ** X-Spam-Status: No, score=2.914 tagged_above=-999 required=5 tests=[AWL=-0.156, BAYES_05=-1.11, CHARSET_FARAWAY_HEADER=3.2, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vsE7KR983jZI for ; Thu, 11 Aug 2011 18:13:27 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 3226521F8A6C for ; Thu, 11 Aug 2011 18:13:27 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPS00BVRJFC0E@szxga03-in.huawei.com> for cdni@ietf.org; Fri, 12 Aug 2011 09:14:00 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPS00JW1JFBFF@szxga03-in.huawei.com> for cdni@ietf.org; Fri, 12 Aug 2011 09:14:00 +0800 (CST) Received: from w36710x ([10.144.242.54]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LPS00HWQJFB2I@szxml06-in.huawei.com> for cdni@ietf.org; Fri, 12 Aug 2011 09:13:59 +0800 (CST) Date: Fri, 12 Aug 2011 09:13:58 +0800 From: He Xiaoyan In-reply-to: <1CA25301D2219F40B3AA37201F0EACD113629B43@PACDCEXMB05.cable.comcast.com> To: "'Woundy, Richard'" , "'Francois Le Faucheur (flefauch)'" Message-id: <02f201cc588d$1d8d6320$36f2900a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_2L47T7nSUjZ/Ptwz5eysdw)" Thread-index: AcxXzqO4r7S5BiOzToyyL21P37xwswApr/YgAAXnGsA= Cc: cdni@ietf.org Subject: [CDNi] =?gb2312?b?tPC4tDogV2hlbiB0aGUgbWVldGluZyBtaW51dGVzIHdv?= =?gb2312?b?dWxkIGJlIGF2YWlsYWJsZT8=?= X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 01:13:28 -0000 This is a multi-part message in MIME format. --Boundary_(ID_2L47T7nSUjZ/Ptwz5eysdw) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Richard, Thanks for your effort and response. =20 Best Regards Xiaoyan(Susan) He _____ =20 =B7=A2=BC=FE=C8=CB: Woundy, Richard = [mailto:Richard_Woundy@cable.comcast.com]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA8=D4=C212=C8=D5 6:27 =CA=D5=BC=FE=C8=CB: He Xiaoyan; 'Francois Le Faucheur (flefauch)' =B3=AD=CB=CD: cdni@ietf.org; Woundy, Richard =D6=F7=CC=E2: RE: When the meeting minutes would be available? =20 Xiaoyan, my apologies but I am still working on consolidating the fine meeting minutes from Daryl Malas and Ray van Brandenburg, as well as reconciling from my own notes. I hope to have them completed by this weekend, barring any other work interruptions=A1=AD =20 From: He Xiaoyan [mailto:hexiaoyan@huawei.com]=20 Sent: Wednesday, August 10, 2011 10:31 PM To: 'Francois Le Faucheur (flefauch)'; Woundy, Richard Cc: cdni@ietf.org Subject: When the meeting minutes would be available? =20 Hi Francois and Richard, Can I ask when the Quebec meeting minutes would be available? Thanks. =20 Best Regards Xiaoyan(Susan) He =20 --Boundary_(ID_2L47T7nSUjZ/Ptwz5eysdw) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable

Richard,

Thanks for your = effort and response.

 <= /span>

Best = Regards

Xiaoyan(Susan) = He

=B7=A2=BC=FE= =C8=CB: Woundy, = Richard [mailto:Richard_Woundy@cable.comcast.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA8=D4=C212=C8=D5 6:27
=CA=D5=BC=FE=C8=CB: He Xiaoyan; = 'Francois Le Faucheur (flefauch)'
=B3=AD=CB=CD: cdni@ietf.org; Woundy, Richard
=D6=F7=CC=E2: RE: When the meeting minutes would be = available?

 

Xiaoyan, my apologies but I am still working on consolidating the fine meeting = minutes from Daryl Malas and Ray van Brandenburg, as well as reconciling from my = own notes. I hope to have them completed by this weekend, barring any other = work interruptions=A1=AD

 <= /o:p>

From: He Xiaoyan [mailto:hexiaoyan@huawei.com]
Sent: Wednesday, August = 10, 2011 10:31 PM
To: 'Francois Le Faucheur (flefauch)'; Woundy, Richard
Cc: cdni@ietf.org
Subject: When the meeting = minutes would be available?

 

Hi Francois and = Richard,

Can I ask when the Quebec meeting minutes would be = available?

Thanks.

 

Best Regards

Xiaoyan(Susan) He

 

--Boundary_(ID_2L47T7nSUjZ/Ptwz5eysdw)-- From zhouzhipeng@huawei.com Thu Aug 11 18:27:08 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31A5E21F85B5 for ; Thu, 11 Aug 2011 18:27:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.57 X-Spam-Level: X-Spam-Status: No, score=0.57 tagged_above=-999 required=5 tests=[AWL=-2.480, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gEQvo3nFqjhp for ; Thu, 11 Aug 2011 18:27:07 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 085D421F85B2 for ; Thu, 11 Aug 2011 18:27:07 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPS009IGK158E@szxga05-in.huawei.com> for cdni@ietf.org; Fri, 12 Aug 2011 09:27:05 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPS00A0BJZ897@szxga05-in.huawei.com> for cdni@ietf.org; Fri, 12 Aug 2011 09:27:05 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml201-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADC83264; Fri, 12 Aug 2011 09:27:04 +0800 (CST) Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 12 Aug 2011 09:26:56 +0800 Received: from SZXEML519-MBS.china.huawei.com ([169.254.7.219]) by szxeml402-hub.china.huawei.com ([10.82.67.32]) with mapi id 14.01.0270.001; Fri, 12 Aug 2011 09:27:03 +0800 Date: Fri, 12 Aug 2011 01:27:02 +0000 From: ZhouZhipeng In-reply-to: <9510D26531EF184D9017DF24659BB87F32E4C7B375@EMV65-UKRD.domain1.systemhost.net> X-Originating-IP: [10.138.73.38] To: "philip.eardley@bt.com" , "cdni@ietf.org" Message-id: <260A32EFD5C9EB47AD504929D005DF623D5EA9@SZXEML519-MBS.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_d4jlzaRBlmIZoHP1K4ILmg)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: [CDNi] Recursive & Iterative definitions Thread-index: AQHMWFkM849GbJPXMEGNbBDkd/cx6pUYa30w X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <9510D26531EF184D9017DF24659BB87F32E4C7B375@EMV65-UKRD.domain1.systemhost.net> Subject: [CDNi] =?gb2312?b?tPC4tDogIFJlY3Vyc2l2ZSAmIEl0ZXJhdGl2ZSAgZGVm?= =?gb2312?b?aW5pdGlvbnM=?= X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 01:27:08 -0000 --Boundary_(ID_d4jlzaRBlmIZoHP1K4ILmg) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 SGkgUGhpbGlwLA0KQSBjb21tZW50OiBpZiB0aGUgRG93bnN0cmVhbSBDRE4gbWF5IG5vdCBmdWxm aWxsIHRoZSB0YXNrLCBpdCBtYXkganVzdCBmZWVkYmFjayChsHVuYXZhaWxhYmxlobEuDQpXaGV0 aGVyIG9yIG5vdCB0byBhZHZpc2UgdGhlIFVwc3RyZWFtIENETiBvZiB0aGUgbmV4dCByb3V0ZSBp cyBub3QgbmVjZXNzYXJ5Lg0KVGhhbmtzLg0KWmhpcGVuZw0KDQq3orz+yMs6IHBoaWxpcC5lYXJk bGV5QGJ0LmNvbSBbbWFpbHRvOnBoaWxpcC5lYXJkbGV5QGJ0LmNvbV0NCreiy83KsbzkOiAyMDEx xOo41MIxMcjVIDIyOjQxDQrK1bz+yMs6IGNkbmlAaWV0Zi5vcmcNCtb3zOI6IFtDRE5pXSBSZWN1 cnNpdmUgJiBJdGVyYXRpdmUgZGVmaW5pdGlvbnMNCg0KSGksDQpDdXJyZW50bHkgdGhlIGRlZmlu aXRpb25zIGZvciBSZWN1cnNpdmUgJiBJdGVyYXRpdmUgQ0ROSSBSZXF1ZXN0IFJvdXRpbmcgYXBw ZWFyIGluIHRoZSB1c2UtY2FzZXMgZG9jdW1lbnQuIFRoZSBhdXRob3JzIGhhZCBzb21lIGRpc2N1 c3Npb24gdGhhdCB0aGUgZGVmaW5pdGlvbnMgY291bGQgYmUgY2xlYXJlci4gQmVsb3cgaXMgYSBw b3NzaWJsZSB2YXJpYW50Lg0KDQpJIHRoaW5rIHRoYXQgYWxsIHRoZSBkZWZpbml0aW9ucyBhcmUg YmVpbmcgbW92ZWQgaW50byBvbmUgZG9jdW1lbnQ/IC0gc28gdGhpcyBpcyBqdXN0IGEgc3VnZ2Vz dGlvbiBmb3IgdGhlIGVkaXRvciBvZiB0aGUgRGVmaW5pdGlvbnMgZG9jdW1lbnQNCg0KDQpSZWN1 cnNpdmUgJiBJdGVyYXRpdmUgQ0ROSSBSZXF1ZXN0IFJvdXRpbmcNCkNETkkgcmVxdWVzdCByb3V0 aW5nIGludm9sdmVzIHRoZSBVcHN0cmVhbSBDRE4gZWxlY3RpbmcgdG8gcmVkaXJlY3QgYSByb3V0 ZSByZXF1ZXN0IHRvd2FyZHMgYSBEb3duc3RyZWFtIENETi4NClRoZXJlIGFyZSB0d28gcG9zc2li aWxpdGllcyBmb3Igd2hhdCBoYXBwZW5zIG5leHQNCg0KMS4gICAgICAocmVjdXJzaXZlKSB0aGUg RG93bnN0cmVhbSBDRE4gYWR2aXNlcyB0aGUgVXBzdHJlYW0gQ0ROIGhvdyB0byBoYW5kbGUgdGhl IHJvdXRlIHJlcXVlc3QuIEZvciBleGFtcGxlLCBpdCBtaWdodCAoMSkgaW5kaWNhdGUgb25lIG9m IGl0cyBvd24gc3Vycm9nYXRlcyBvciAoMikgYSB0aGlyZCBDRE4gdG8gdHJ5LiBUaGUgVXBzdHJl YW0gQ0ROIHRoZW4gc2VuZHMgYSBuZXcgcm91dGUgcmVxdWVzdCAoMSkgdG8gdGhlIHNlY29uZCBD RE6hr3Mgc3Vycm9nYXRlIG9yICgyKSB0b3dhcmRzIHRoZSB0aGlyZCBDRE4uDQoNCjIuICAgICAg KGl0ZXJhdGl2ZSkgdGhlIERvd25zdHJlYW0gQ0ROIGRlY2lkZXMgaG93IHRvIGhhbmRsZSB0aGUg cm91dGUgcmVxdWVzdCB3aXRob3V0IHJlZmVycmluZyBiYWNrIHRvIHRoZSBVcHN0cmVhbSBDRE4u IEl0IGNvdWxkIGZvcndhcmQgdGhlIHJvdXRlIHJlcXVlc3QsIGZvciBleGFtcGxlLCAoMSkgdG8g b25lIG9mIGl0cyBvd24gc3Vycm9nYXRlcyBvciAoMikgdG93YXJkcyBhIHRoaXJkIENETi4gSW4g dGhlIGxhdHRlciBjYXNlLCBpdCBub3cgcGxheXMgdGhlIHJvbGUgb2YgdGhlIFVwc3RyZWFtIENE TiBhbmQgdGhlIHRoaXJkIENETiBhY3RzIGFzIGEgRG93bnN0cmVhbSBDRE4uDQpBIHBpY3R1cmUg d291bGQgaGVscCBhcyB3ZWxsDQoNCkJlc3Qgd2lzaGVzDQpQaGlsLw0KDQoNCg0KDQpQaGlsaXAg RWFyZGxleQ0KUmVzZWFyY2ggYW5kIFRlY2hub2xvZ3kgU3RyYXRlZ3kNClRoaXMgZW1haWwgY29u dGFpbnMgQlQgaW5mb3JtYXRpb24sIHdoaWNoIG1heSBiZSBwcml2aWxlZ2VkIG9yIGNvbmZpZGVu dGlhbC4gSXQncyBtZWFudCBvbmx5IGZvciB0aGUgaW5kaXZpZHVhbChzKSBvciBlbnRpdHkgbmFt ZWQgYWJvdmUuIElmIHlvdSdyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgbm90ZSB0aGF0 IGRpc2Nsb3NpbmcsIGNvcHlpbmcsIGRpc3RyaWJ1dGluZyBvciB1c2luZyB0aGlzIGluZm9ybWF0 aW9uIGlzIHByb2hpYml0ZWQuIElmIHlvdSd2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9y LCBwbGVhc2UgbGV0IG1lIGtub3cgaW1tZWRpYXRlbHkgb24gdGhlIGVtYWlsIGFkZHJlc3MgYWJv dmUuIFRoYW5rIHlvdS4gV2UgbW9uaXRvciBvdXIgZW1haWwgc3lzdGVtLCBhbmQgbWF5IHJlY29y ZCB5b3VyIGVtYWlscy4NCkJyaXRpc2ggVGVsZWNvbW11bmljYXRpb25zIHBsYw0KUmVnaXN0ZXJl ZCBvZmZpY2U6IDgxIE5ld2dhdGUgU3RyZWV0IExvbmRvbiBFQzFBIDdBSg0KUmVnaXN0ZXJlZCBp biBFbmdsYW5kIG5vOiAxODAwMDAwDQoNCg== --Boundary_(ID_d4jlzaRBlmIZoHP1K4ILmg) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable

Hi Philip,

A comment: if the Downstream CDN may not fulfill the task, it may= just feedback =A1=B0unavailable=A1=B1.

Whether or not to advise the Upstream CDN of the next route is no= t necessary.

Thanks.

Zhipeng

 

=B7=A2=BC=FE=C8=CB: philip.= eardley@bt.com [mailto:philip.eardley@bt.com]
=B7=A2= =CB=CD=CA=B1=BC=E4: 2011=C4=EA8=D4=C211=C8=D5 22:41
=CA=D5=BC=FE=C8=CB: cdni@ietf.org
=D6=F7=CC=E2: [CDNi] Recursive & Iterative definitions

 

Hi, <= /p>

Current= ly the definitions for Recursive & Iterative CDNI Request Routing appea= r in the use-cases document. The authors had some discussion that the defin= itions could be clearer. Below is a possible variant.

&n= bsp;

I think= that all the definitions are being moved into one document? - so this is j= ust a suggestion for the editor of the Definitions document

&n= bsp;

&n= bsp;

Recursi= ve & Iterative CDNI Request Routing

CDNI re= quest routing involves the Upstream CDN electing to redirect a route reques= t towards a Downstream CDN.

There a= re two possibilities for what happens next

1.      (r= ecursive) the Downstream CDN advises the Upstream CDN how to handle the rou= te request. For example, it might (1) indicate one of its own surrogates or (2) a third CDN to try. The Upstream CDN then sends a ne= w route request (1) to the second CDN=A1=AFs surrogate or (2) towards the t= hird CDN.

2.      (i= terative) the Downstream CDN decides how to handle the route request withou= t referring back to the Upstream CDN. It could forward the route request, for example, (1) to one of its own surrogates or (2) toward= s a third CDN. In the latter case, it now plays the role of the Upstream CD= N and the third CDN acts as a Downstream CDN.

A picture would help as well

 

Best wishes

Phil/

 

 

 

 

Philip Eardley   <= span lang=3D"EN-GB" style=3D"font-size:9.0pt;font-family:"Arial",= "sans-serif"">
Research and Technology Strategy

This email contains BT information, which= may be privileged or confidential. It's meant only for the individual(s) or entity named above. If you're not the intended recipient,= note that disclosing, copying, distributing or using this information is p= rohibited. If you've received this email in error, please let me know immed= iately on the email address above. Thank you. We monitor our email system, and may record your emails.

British Telecommunications plc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no: 1800000

 

--Boundary_(ID_d4jlzaRBlmIZoHP1K4ILmg)-- From richard_woundy@cable.comcast.com Mon Aug 15 14:08:15 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6170D21F8D04 for ; Mon, 15 Aug 2011 14:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.994 X-Spam-Level: X-Spam-Status: No, score=-101.994 tagged_above=-999 required=5 tests=[AWL=-0.260, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EIl8UfQjv+6r for ; Mon, 15 Aug 2011 14:08:15 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id D711A21F8C75 for ; Mon, 15 Aug 2011 14:08:14 -0700 (PDT) Received: from ([24.40.55.41]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.48926818; Mon, 15 Aug 2011 15:14:03 -0600 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%11]) with mapi id 14.01.0289.001; Mon, 15 Aug 2011 17:08:44 -0400 From: "Woundy, Richard" To: "cdni@ietf.org" Thread-Topic: CDNI minutes from IETF 81 Thread-Index: Acxbj4LXjOqObl9aTv2bzX1R9H5ikA== Date: Mon, 15 Aug 2011 21:08:43 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD11362CC49@PACDCEXMB05.cable.comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.163.75.13] Content-Type: multipart/alternative; boundary="_000_1CA25301D2219F40B3AA37201F0EACD11362CC49PACDCEXMB05cabl_" MIME-Version: 1.0 Subject: [CDNi] CDNI minutes from IETF 81 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 21:08:15 -0000 --_000_1CA25301D2219F40B3AA37201F0EACD11362CC49PACDCEXMB05cabl_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, We have uploaded the CDNI minutes from our last WG session in Quebec City. = Please review the minutes for accuracy. Please send any corrections to us b= y Monday August 29. Many thanks to Daryl Malas and Ray van Brandenburg who composed these notes= ! -- Rich & Francois --_000_1CA25301D2219F40B3AA37201F0EACD11362CC49PACDCEXMB05cabl_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

We have uploaded the CDNI minutes from our last WG s= ession in Quebec City. Please review the minutes for accuracy. Please send = any corrections to us by Monday August 29.

 

Many thanks to Daryl Malas and Ray van Brandenburg w= ho composed these notes!

 

<http://www.ietf.org/proceedings/81/minutes/cdni.txt>=

 

-- Rich & Francois

--_000_1CA25301D2219F40B3AA37201F0EACD11362CC49PACDCEXMB05cabl_-- From zhouzhipeng@huawei.com Tue Aug 16 03:39:23 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B496021F8A1A for ; Tue, 16 Aug 2011 03:39:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.634 X-Spam-Level: X-Spam-Status: No, score=-3.634 tagged_above=-999 required=5 tests=[AWL=2.964, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c8n205wJsb+Z for ; Tue, 16 Aug 2011 03:39:21 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 0D0F621F8A62 for ; Tue, 16 Aug 2011 03:39:21 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQ000FJHOAU89@szxga03-in.huawei.com> for cdni@ietf.org; Tue, 16 Aug 2011 18:40:07 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQ000E15OAU2V@szxga03-in.huawei.com> for cdni@ietf.org; Tue, 16 Aug 2011 18:40:06 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml202-edg.china.huawei.com) ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADE71952; Tue, 16 Aug 2011 18:40:06 +0800 (CST) Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 16 Aug 2011 18:40:01 +0800 Received: from SZXEML519-MBS.china.huawei.com ([169.254.7.36]) by szxeml412-hub.china.huawei.com ([169.254.226.192]) with mapi id 14.01.0270.001; Tue, 16 Aug 2011 18:40:06 +0800 Date: Tue, 16 Aug 2011 10:40:04 +0000 From: ZhouZhipeng X-Originating-IP: [10.138.73.38] To: "cdni@ietf.org" Message-id: <260A32EFD5C9EB47AD504929D005DF623DA9D2@SZXEML519-MBS.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_nU528OsuiW9bmPIQkcgakQ)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: explanation on use cases. Thread-index: AcxcANuFxjOxkBL7SNmX/wYtoHm6sg== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Subject: [CDNi] explanation on use cases. X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 10:39:23 -0000 --Boundary_(ID_nU528OsuiW9bmPIQkcgakQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Dear all, I have taken a carefully review on the meeting minutes and felt that this meeting is really very practical with many valuable comments and opinions. Thanks for Manning's presentation on my slides and thanks for all members' feedback on these use cases. I feel most people esp. the chairs have made consensus that the CDNI is to cooperate multiple CDNs hence the signaling and metadata would be the output of this project. So for my use case 3 and 4, obviously they are not proposing for operations(such as transcoding) but to describe how such operations may be implemented and controlled/signaled in the CDNI scenario. Absolutely CDNI will not dive into such basic operations since they have existed and been mature for quite a few years( transcoding belong to ITU/MPEG) while the gap is the interaction between CDNs for the fulfillment of these operations( e.g. how uCDN informs dCDN to support some media adaptation). Totally, these two cases are to enhance the value of CDN service and in fact as I know are supported in more and more CDN providers.(transcoding has been the popular service by many CDN providers. You may google if you like to learn the names of those CDN providers) Further I think for CDNI to support such functionality would not be complicated since we only need to clarify how to transfer the signaling and the individual CDN may fulfill the functionality internally. I also notes in Gilles's slide 7 on the "CDN capability use cases", it illustrates that "an end-user switches from her connected TV to her mobile". Obviously if at first a CDN may support mobile application and another CDN may support TV application. If to connect these two CDNs, they should both support mobile and TV applications. Besides, for the "differentiated delivery", it is a very popular concept in fact. Many people have already shared the understanding on this use case and feel it is similar to some other concepts such as SLA. While I like to explain that this case is towards the content awareness and the object is the content. For other technology area the differ service may be towards a link or a transport chain or the type of transferred data. By similar logic for the content delivery, the differentiation may be set towards the specific content. As for my first two use cases, I think they are relevant to some requirements but: 1) Those requirements do not have use case to support( for example, the whitelist/blacklist looks relative ( not exactly) but miss the use cases) 2) The content of these two use case are new. Somehow the Bertrand-usecase has shared the footprint use cases that is to show the requirements of several requirements(geography extension...) But it has not shown what information would be exchanged and how multiple CDN cooperate for a task. So, I personally feel these two use cases may be merged under the section of "Footprint Extension Use Cases". By the explanation above, I hope it may help you more understand my use cases. For any concern, welcome your more comments. Thanks. Zhipeng ----------------------------------------------------- Huawei Carrier Software Business Unit. No.101,Software Avenue,Yuhuatai District,Nanjing, P.R.of China Zipcode:210012 E-Mail: zhouzhipeng@huawei.com Phone:(+86) 25-56620690 Fax:(+86) 25-56624081 Mobile:(+86) 13404162849 ----------------------------------------------------- --Boundary_(ID_nU528OsuiW9bmPIQkcgakQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Dear all,

I have taken a carefully review on the meeting minutes and felt that this meeting is really very practical with many valuable comments and opinions.

Thanks for Manning’s presentation on my slides and thanks for all members’ feedback on these use cases.

I feel most people esp. the chairs have made consensus that the CDNI is to cooperate multiple CDNs hence the signaling and metadata would be the output of this project.

So for my use case 3 and 4, obviously they are not proposing for operations(such as transcoding) but to describe how such operations may be implemented and controlled/signaled in the CDNI scenario.

Absolutely CDNI will not dive into such basic operations since they have existed and been mature for quite a few years( transcoding belong to ITU/MPEG) while the gap is the interaction between CDNs for the fulfillment of these operations( e.g. how uCDN informs dCDN to support some media adaptation).

Totally, these two cases are to enhance the value of CDN service and in fact as I know are supported in more and more CDN providers.(transcoding has been the popular service by many CDN providers. You may google if you like to learn the names of those CDN providers) Further I think for CDNI to support such functionality would not be complicated since we only need to clarify how to transfer the signaling and the individual CDN may fulfill the functionality internally.

I also notes in Gilles’s slide 7 on the “CDN capability use cases”, it illustrates that “an end-user switches from her connected TV to her mobile”.  Obviously if at first a CDN may support mobile application and another CDN may support TV application. If to connect these two CDNs, they should both support mobile and TV applications.

 

Besides, for the “differentiated delivery”, it is a very popular concept in fact. Many people have already shared the understanding on this use case and feel it is similar to some other concepts such as SLA. While I like to explain that this case is towards the content awareness and the object is the content.
For other technology area the differ service may be towards a link or a transport chain or the type of transferred data. By similar logic for the content delivery, the differentiation may be set towards the specific content.
 

As for my first two use cases, I think they are relevant to some requirements but:

1)      Those requirements do not have use case to support( for example, the whitelist/blacklist looks relative ( not exactly) but miss the use cases)

2)         The content of these two use case are new. Somehow the Bertrand-usecase has shared the footprint use cases that is to show the requirements of several requirements(geography extension…)

But it has not shown what information would be exchanged and how multiple CDN cooperate for a task.

So, I personally feel these two use cases may be merged under the section of  “Footprint Extension Use Cases”.

 

By the explanation above, I hope it may help you more understand my use cases. For any concern, welcome your more comments.

Thanks.

Zhipeng

 

-----------------------------------------------------

Huawei Carrier Software Business Unit.

No.101,Software Avenue,Yuhuatai District,Nanjing, P.R.of China
Zipcode:210012
E-Mail: zhouzhipeng@huawei.com
Phone:(+86) 25-56620690

Fax:(+86) 25-56624081

Mobile:(+86) 13404162849
-----------------------------------------------------

 

--Boundary_(ID_nU528OsuiW9bmPIQkcgakQ)-- From gilles.bertrand@orange-ftgroup.com Fri Aug 19 09:34:33 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB7B021F8B36 for ; Fri, 19 Aug 2011 09:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-sll-HTZpxz for ; Fri, 19 Aug 2011 09:34:33 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id 156C221F8B33 for ; Fri, 19 Aug 2011 09:34:33 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id F374D8B8003 for ; Fri, 19 Aug 2011 18:36:21 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id EDA548B8001 for ; Fri, 19 Aug 2011 18:36:21 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 19 Aug 2011 18:35:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 19 Aug 2011 18:35:23 +0200 Message-ID: <8E09C72DBC577D489F13A71228C0B7BF029744A7@ftrdmel0.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action: draft-bertrand-cdni-experiments-01.txt Thread-Index: AcxejRwxCY/e3LMJRuGmGqzgjo9UzgAAEBLQ From: To: X-OriginalArrivalTime: 19 Aug 2011 16:35:29.0939 (UTC) FILETIME=[0208A630:01CC5E8E] Subject: [CDNi] TR: I-D Action: draft-bertrand-cdni-experiments-01.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2011 16:34:34 -0000 Colleagues, We have posted an update of draft-bertrand-cdni-experiments. It brings = mostly editorial changes. Cheers, Gilles -----Message d'origine----- De=A0: i-d-announce-bounces@ietf.org = [mailto:i-d-announce-bounces@ietf.org] De la part de = internet-drafts@ietf.org Envoy=E9=A0: vendredi 19 ao=FBt 2011 18:28 =C0=A0: i-d-announce@ietf.org Objet=A0: I-D Action: draft-bertrand-cdni-experiments-01.txt A New Internet-Draft is available from the on-line Internet-Drafts = directories. Title : Content Distribution Network Interconnection (CDNI) = Experiments Author(s) : Gilles Bertrand Francois Le Faucheur Larry Peterson Filename : draft-bertrand-cdni-experiments-01.txt Pages : 20 Date : 2011-08-19 This document reports studies and related experiments on CDN interconnection performed by France Telecom-Orange Labs. The document summarizes implications of CDN interconnection to CDN service providers and lessons learned through CDNI experiments. The main purpose of the experiments was to test the interconnection of CDN solutions from two vendors (namely, Cisco and Verivue) and to identify the gaps and needs for standardization work for CDN interconnection. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bertrand-cdni-experiments-01.tx= t Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-bertrand-cdni-experiments-01.txt= _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt From richard_woundy@cable.comcast.com Mon Aug 22 05:14:14 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5464D21F8B29 for ; Mon, 22 Aug 2011 05:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.408 X-Spam-Level: X-Spam-Status: No, score=-102.408 tagged_above=-999 required=5 tests=[AWL=-0.673, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ROLLjhmfGP-X for ; Mon, 22 Aug 2011 05:14:14 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id 75ADB21F8B28 for ; Mon, 22 Aug 2011 05:14:08 -0700 (PDT) Received: from ([24.40.55.42]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.49756812; Mon, 22 Aug 2011 06:20:46 -0600 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%11]) with mapi id 14.01.0289.001; Mon, 22 Aug 2011 08:15:10 -0400 From: "Woundy, Richard" To: "CDNI@ietf.org" Thread-Topic: Adopting problem statement draft as CDNI WG document Thread-Index: Acxgw35TODPwhTf1QDCiQENoaVlvKA== Date: Mon, 22 Aug 2011 12:15:09 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD113632CD1@PACDCEXMB05.cable.comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.191.125.12] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [CDNi] Adopting problem statement draft as CDNI WG document X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 12:14:14 -0000 Folks, As confirmation of the =93hum=94 we took in the WG session at the IETF 81 m= eeting in Quebec City, please post on the list if there is any objection to= moving the following draft to a CDNI WG draft: draft-jenkins-cdni-problem-statement-02 If there are no objections by Friday September 2 2011, the draft above will= be accepted as a WG document fulfilling the "problem statement=94 delivera= ble. Also note that we had a related "hum" about moving the material in this dra= ft concerning CDNI non-goals, prioritization, and related standardization w= ork into an appendix, with a note to the RFC Editor to remove it upon publi= cation. -- Rich and Francois From richard_woundy@cable.comcast.com Mon Aug 22 05:19:23 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D19FB21F8B38 for ; Mon, 22 Aug 2011 05:19:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.551 X-Spam-Level: X-Spam-Status: No, score=-101.551 tagged_above=-999 required=5 tests=[AWL=-1.305, BAYES_05=-1.11, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w7ITpAXi-aYf for ; Mon, 22 Aug 2011 05:19:23 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id 982B921F8AAC for ; Mon, 22 Aug 2011 05:19:21 -0700 (PDT) Received: from ([24.40.55.41]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.49757315; Mon, 22 Aug 2011 06:25:59 -0600 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%11]) with mapi id 14.01.0289.001; Mon, 22 Aug 2011 08:20:22 -0400 From: "Woundy, Richard" To: "CDNI@ietf.org" Thread-Topic: Adopting requirements draft as CDNI WG document Thread-Index: AQHMYMW1Ig4et+Peu0iTssaxFLLo9w== Date: Mon, 22 Aug 2011 12:20:21 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD113632CF7@PACDCEXMB05.cable.comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.191.125.12] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [CDNi] Adopting requirements draft as CDNI WG document X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 12:19:23 -0000 Folks, As confirmation of the =93hum=94 we took in the WG session at the IETF 81 m= eeting in Quebec City, please post on the list if there is any objection to= moving the following draft to a CDNI WG draft: draft-lefaucheur-cdni-requirements-02 If there are no objections by Friday September 2 2011, the draft above will= be accepted as a WG document fulfilling the "requirements=94 deliverable. -- Rich and Francois From ben@niven-jenkins.co.uk Mon Aug 22 05:30:05 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B983A21F8B2D for ; Mon, 22 Aug 2011 05:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.742 X-Spam-Level: X-Spam-Status: No, score=-102.742 tagged_above=-999 required=5 tests=[AWL=-0.694, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RCVD_IN_DNSWL_LOW=-1, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ikXnXXJNl+6M for ; Mon, 22 Aug 2011 05:30:05 -0700 (PDT) Received: from mailex.mailcore.me (unknown [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id BEC2121F8582 for ; Mon, 22 Aug 2011 05:30:00 -0700 (PDT) Received: from host1.cachelogic.com ([212.44.43.80] helo=xxx.dhcp.cachelogic.com) by mail11.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1QvTei-0004Cg-Ca; Mon, 22 Aug 2011 13:31:04 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: <1CA25301D2219F40B3AA37201F0EACD11362CC49@PACDCEXMB05.cable.comcast.com> Date: Mon, 22 Aug 2011 13:31:01 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1CA25301D2219F40B3AA37201F0EACD11362CC49@PACDCEXMB05.cable.comcast.com> To: "Woundy, Richard" X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: "cdni@ietf.org" Subject: Re: [CDNi] CDNI minutes from IETF 81 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 12:30:05 -0000 Rich, One correction related to something I said during the meeting Towards the bottom of the minutes: > Ben Niven-Jenkins: Layer 4 VPNs are a multi-billion dollar market. And = they do=20 > everything out of band.=20 Can you s/Layer 4/Layer 3/ Also as a clarification I didn't actually say that Layer 3 VPNs do = *everything* out of band, what I said was that the negotiation for what = treatment to apply for a particular CoS/DSCP value (or how to map a = particular DSCP value in one network to a different DSCP value in = another network) is performed out of band between Layer 3 VPNs running = over interconnected network. The rest of the minutes look OK to me. Thanks Ben On 15 Aug 2011, at 22:08, Woundy, Richard wrote: > Folks, > =20 > We have uploaded the CDNI minutes from our last WG session in Quebec = City. Please review the minutes for accuracy. Please send any = corrections to us by Monday August 29. > =20 > Many thanks to Daryl Malas and Ray van Brandenburg who composed these = notes! > =20 > > =20 > -- Rich & Francois > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From richard_woundy@cable.comcast.com Mon Aug 22 05:45:49 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8466521F8B29 for ; Mon, 22 Aug 2011 05:45:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.18 X-Spam-Level: X-Spam-Status: No, score=-101.18 tagged_above=-999 required=5 tests=[AWL=-1.304, BAYES_20=-0.74, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q90hedR91uK7 for ; Mon, 22 Aug 2011 05:45:49 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id 059D521F8AA8 for ; Mon, 22 Aug 2011 05:45:48 -0700 (PDT) Received: from ([24.40.55.41]) by copdcimo01.cable.comcast.com with ESMTP with TLS id 5503630.49758455; Mon, 22 Aug 2011 06:36:42 -0600 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%11]) with mapi id 14.01.0289.001; Mon, 22 Aug 2011 08:31:06 -0400 From: "Woundy, Richard" To: "CDNI@ietf.org" Thread-Topic: Adopting use cases draft as CDNI WG document Thread-Index: AQHMYMdckI18N95JGk+qzDqLHH4K6A== Date: Mon, 22 Aug 2011 12:31:05 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD113632D2B@PACDCEXMB05.cable.comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.191.125.12] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [CDNi] Adopting use cases draft as CDNI WG document X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 12:45:49 -0000 Folks, As confirmation of the =93hum=94 we took in the WG session at the IETF 81 m= eeting in Quebec City, please post on the list if there is any objection to= moving the following draft to a CDNI WG draft: draft-bertrand-cdni-use-cases-02 If there are no objections by Friday September 2 2011, the draft above will= be accepted as a WG document fulfilling the "use cases=94 deliverable. Note that the authors will include a clear statement that the draft is not = yet finished and other use cases may still be included. -- Rich and Francois From zhouzhipeng@huawei.com Mon Aug 22 19:11:08 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D25421F8549 for ; Mon, 22 Aug 2011 19:11:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.466 X-Spam-Level: X-Spam-Status: No, score=0.466 tagged_above=-999 required=5 tests=[AWL=-2.322, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wYGhNYSb6hez for ; Mon, 22 Aug 2011 19:11:07 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 5724521F8548 for ; Mon, 22 Aug 2011 19:11:07 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQC00DEFZGB8E@szxga03-in.huawei.com> for CDNI@ietf.org; Tue, 23 Aug 2011 10:12:11 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LQC00ERLZGBWD@szxga03-in.huawei.com> for CDNI@ietf.org; Tue, 23 Aug 2011 10:12:11 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml201-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADJ24411; Tue, 23 Aug 2011 10:12:10 +0800 (CST) Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 23 Aug 2011 10:12:07 +0800 Received: from SZXEML519-MBS.china.huawei.com ([169.254.7.36]) by szxeml412-hub.china.huawei.com ([169.254.226.192]) with mapi id 14.01.0270.001; Tue, 23 Aug 2011 10:12:10 +0800 Date: Tue, 23 Aug 2011 02:12:09 +0000 From: ZhouZhipeng In-reply-to: <1CA25301D2219F40B3AA37201F0EACD113632CF7@PACDCEXMB05.cable.comcast.com> X-Originating-IP: [10.138.73.38] To: "Woundy, Richard" , "CDNI@ietf.org" Message-id: <260A32EFD5C9EB47AD504929D005DF623DB72A@SZXEML519-MBS.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: [CDNi] Adopting requirements draft as CDNI WG document Thread-index: AQHMYP3mTG+6gHLiJEGJ7MqXn3KyS5UpsYPQ X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <1CA25301D2219F40B3AA37201F0EACD113632CF7@PACDCEXMB05.cable.comcast.com> Subject: [CDNi] =?gb2312?b?tPC4tDogIEFkb3B0aW5nIHJlcXVpcmVtZW50cyBkcmFm?= =?gb2312?b?dCBhcyBDRE5JIFdHIGRvY3VtZW50?= X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 02:11:08 -0000 SSB0aGluayBpdCBtYXkgYWxzbyBhZGQgYSBub3RlIHRoYXQgInRoZSBkcmFmdCBpcyBub3QgeWV0 IGZpbmlzaGVkIGFuZCBvdGhlciByZXF1aXJlbWVudHMgbWF5IHN0aWxsIGJlIGluY2x1ZGVkLiIN Cg0KVGhhbmtzLg0KWmhpcGVuZw0KDQoNCi0tLS0t08q8/tStvP4tLS0tLQ0Kt6K8/sjLOiBXb3Vu ZHksIFJpY2hhcmQgW21haWx0bzpSaWNoYXJkX1dvdW5keUBjYWJsZS5jb21jYXN0LmNvbV0gDQq3 osvNyrG85DogMjAxMcTqONTCMjLI1SAyMDoyMA0KytW8/sjLOiBDRE5JQGlldGYub3JnDQrW98zi OiBbQ0ROaV0gQWRvcHRpbmcgcmVxdWlyZW1lbnRzIGRyYWZ0IGFzIENETkkgV0cgZG9jdW1lbnQN Cg0KRm9sa3MsDQoNCkFzIGNvbmZpcm1hdGlvbiBvZiB0aGUgobBodW2hsSB3ZSB0b29rIGluIHRo ZSBXRyBzZXNzaW9uIGF0IHRoZSBJRVRGIDgxIG1lZXRpbmcgaW4gUXVlYmVjIENpdHksIHBsZWFz ZSBwb3N0IG9uIHRoZSBsaXN0IGlmIHRoZXJlIGlzIGFueSBvYmplY3Rpb24gdG8gbW92aW5nIHRo ZSBmb2xsb3dpbmcgZHJhZnQgdG8gYSBDRE5JIFdHIGRyYWZ0Og0KDQpkcmFmdC1sZWZhdWNoZXVy LWNkbmktcmVxdWlyZW1lbnRzLTAyDQoNCklmIHRoZXJlIGFyZSBubyBvYmplY3Rpb25zIGJ5IEZy aWRheSBTZXB0ZW1iZXIgMiAyMDExLCB0aGUgZHJhZnQgYWJvdmUgd2lsbCBiZSBhY2NlcHRlZCBh cyBhIFdHIGRvY3VtZW50IGZ1bGZpbGxpbmcgdGhlICJyZXF1aXJlbWVudHOhsSBkZWxpdmVyYWJs ZS4NCg0KLS0gUmljaCBhbmQgRnJhbmNvaXMNCg0K From ben@niven-jenkins.co.uk Fri Aug 26 06:43:49 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 789DB21F8B88 for ; Fri, 26 Aug 2011 06:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.468 X-Spam-Level: X-Spam-Status: No, score=-103.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oamwm85HPfeX for ; Fri, 26 Aug 2011 06:43:48 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.64]) by ietfa.amsl.com (Postfix) with ESMTP id 70E3C21F8A7D for ; Fri, 26 Aug 2011 06:43:48 -0700 (PDT) Received: from host1.cachelogic.com ([212.44.43.80] helo=dhcp-112-devlan.cachelogic.com) by mail5.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1QwwiV-0004m2-83; Fri, 26 Aug 2011 14:45:03 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: <2979E38DD6FC6544B789C8DAD7BAFC520F72C8C5@xmb-sjc-235.amer.cisco.com> Date: Fri, 26 Aug 2011 14:45:02 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1F3DE948AD28CB4D905D51039D081AF62659902006@EMV64-UKRD.domain1.systemhost.net> <7B5DD5B9-27A5-46FA-8444-F6C5D0CB6619@cisco.com> <2979E38DD6FC6544B789C8DAD7BAFC520F72C8C5@xmb-sjc-235.amer.cisco.com> To: Kent Leung (kleung) X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: cdni@ietf.org Subject: Re: [CDNi] Progressing the CDNI Problem Statement X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 13:43:49 -0000 Kent, On 27 Jul 2011, at 20:40, Kent Leung (kleung) wrote: > Here are my comments on ver-02: I have updated my working copy but I'll hold off publishing it until the = WG adoption poll has concluded. > 1. Spec consistency. "end users" should be "End Users" in document > (e.g. Abstract, Intro sections) Done. > 2. Spec consistency. "CDN Interconnection" vs "CDN Interconnect". > Currently used interchangebly. Done - I went with "CDN Interconnection". > 3. Sect 1 Intro: Typos for Section 6 and Section 7 in the last = sentence Done. > 4. Spec consistency. "Pre-Position" to "Pre-position" Done - I went with "Pre-position". > 5. Sect 1.1 Terminology: typo "indepedent" to "independent" Done. > 6. In context of CDNI ... "CDN acquires distribution metadata for > content". Technically, this is "CDNI Metadata" for content. =20 Changed to "CDNI Metdata". > 7. "CSP's Service" to "CSP's service" Done. > 8. "Dedicated content applications" to "dedicated content = applications" Done. > 9. "connectivity/services to Users" to "connectivity/services to End > User" Done. > 10. Extra space in "a Logging System and a CDN control system ." Done. > 11. Should the term "Authoritative CDN" (reference later in sect 3.2) = be > included in section? I think it's valuable to have term that can be = used > by CDNI specs. I've added: Authoritative CDN: A CDN which has a direct relationship with a CSP for = the distribution & delivery of that CSP's content. > 12. Should the term "Cascaded CDNs" be included? IMO no as the Problem Statement doesn't use the term cascaded CDNs. > 13. "Iterative" and "Recursive" Request Routing should be included? = In > general, all terms relevant to CDNI should be located in one spec. I believe we agreed (after you sent your comments) that the best place = for these definitions is in the Framework draft. > 13. "user agent" to "User Agent" Done. > 14. Sect 3 CDNI Model Figure: CDNI protocol -> CDNI interface. An > interface may have served by multiple protocols. Done. > 15. Typo "CDNI Metatdata" to "CDNI Metadata" Done. > 16. Missing Control to Surrogate interface, marked as out of scope > (e.g., content removal) See separate (offline) discussion where we agreed to make the interfaces = to the "Distribution" function rather than directly to the Surrogate. > 17. Need Request Interface from dCDN Surrogate to uCDN Req-Routing = (e.g. > cache miss on dCDN)? Done. > 18. Sect 3.1 Candidate CDNI: "protocol" to "interface" Done. > 19. Typo "Pre-postioned" Done. > 20. Sect 3.2 Non-Goals: Editorial nit, should be "Internal CDN = Protocols > (i.e. protocols within one CDN)" Done. > 21. Sects 4.3-4.6: "API" to "Interface" Done. > 22. Sect 4.4 CDNI Metadata: "element of the Metadata protocol" to > "element of the CDNI Metadata protocol" Done. > 23. Sect 4.6 CDNI Control: "Allow the downstream CDN to communicate > information about its delivery capabilities, resources and policies". > Is this part of Request Routing Interface? These are parameters that > are needed by Request Routing System. I added 'static' as I believe that was the intent but exactly where = different functions/parameters are placed is still TBD. The Problem Statement does already contain the following sentence: Note that the actual grouping of functionalities under these = four interfaces is considered tentative at this stage and may be = changed after further study (e.g. some subset of functionality be moved = from one interface into another). > 24. Sect 6.3 Gap Analysis: Remove or update "" bullet. I have left this in for now. The TODO relates to inserting a sentence = summarising the ITU work and I am not familiar with that work, but = hopefully someone on the list is and can provide some text. If no text = is forthcoming we can remove it at a later date. Ben From vishwas.ietf@gmail.com Fri Aug 26 12:01:29 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ED9621F8C47 for ; Fri, 26 Aug 2011 12:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.097 X-Spam-Level: X-Spam-Status: No, score=-3.097 tagged_above=-999 required=5 tests=[AWL=0.501, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oqy1k2Gh2U6e for ; Fri, 26 Aug 2011 12:01:28 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id D008221F8C3D for ; Fri, 26 Aug 2011 12:01:18 -0700 (PDT) Received: by qyk34 with SMTP id 34so589844qyk.10 for ; Fri, 26 Aug 2011 12:02:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XNPymqHSEPswTZf540u77SurJedzBRGqhMvNE8/hfbw=; b=HmSOAYOlPxRpQKpPzw/6JwbV/x4AGpntQ2z6rxdI7QtIeGY4u+W8srmyRHQ1zRTh+m 44IKXJdUhjDyPQtNc7lvMjw4dAZEF+zUfDrKOIjHFN2m7tI0aBppo1j38nrgd1XSdfU9 cyD1kjRd223lFV+OxZngmc1t8Iok2SMi2zEuQ= MIME-Version: 1.0 Received: by 10.229.89.13 with SMTP id c13mr1945423qcm.54.1314385354089; Fri, 26 Aug 2011 12:02:34 -0700 (PDT) Received: by 10.229.223.211 with HTTP; Fri, 26 Aug 2011 12:02:34 -0700 (PDT) In-Reply-To: <1CA25301D2219F40B3AA37201F0EACD113632CF7@PACDCEXMB05.cable.comcast.com> References: <1CA25301D2219F40B3AA37201F0EACD113632CF7@PACDCEXMB05.cable.comcast.com> Date: Fri, 26 Aug 2011 12:02:34 -0700 Message-ID: From: Vishwas Manral To: "Woundy, Richard" Content-Type: multipart/alternative; boundary=00163646d47a20e3fe04ab6d3016 Cc: "CDNI@ietf.org" Subject: Re: [CDNi] Adopting requirements draft as CDNI WG document X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 19:01:29 -0000 --00163646d47a20e3fe04ab6d3016 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Rich, I think this is a good start. Thanks, Vishwas On Mon, Aug 22, 2011 at 5:20 AM, Woundy, Richard < Richard_Woundy@cable.comcast.com> wrote: > Folks, > > As confirmation of the =93hum=94 we took in the WG session at the IETF 81 > meeting in Quebec City, please post on the list if there is any objection= to > moving the following draft to a CDNI WG draft: > > draft-lefaucheur-cdni-requirements-02 > > If there are no objections by Friday September 2 2011, the draft above wi= ll > be accepted as a WG document fulfilling the "requirements=94 deliverable. > > -- Rich and Francois > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > --00163646d47a20e3fe04ab6d3016 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Rich,
=A0
I think this is a good start.
=A0
Thanks,
Vishwas
=A0
On Mon, Aug 22, 2011 at 5:20 AM, Woundy, Richard= <= Richard_Woundy@cable.comcast.com> wrote:
Folks,

As confirmation of= the =93hum=94 we took in the WG session at the IETF 81 meeting in Quebec C= ity, please post on the list if there is any objection to moving the follow= ing draft to a CDNI WG draft:

draft-lefaucheur-cdni-requirements-02

If there are no objections= by Friday September 2 2011, the draft above will be accepted as a WG docum= ent fulfilling the "requirements=94 deliverable.

-- Rich and Fr= ancois
_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/mailm= an/listinfo/cdni

--00163646d47a20e3fe04ab6d3016-- From gilles.bertrand@orange-ftgroup.com Tue Aug 30 07:11:35 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7CAE21F8C00 for ; Tue, 30 Aug 2011 07:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EMmCa8iYf+gN for ; Tue, 30 Aug 2011 07:11:33 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id F3CCA21F8BF8 for ; Tue, 30 Aug 2011 07:11:32 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C2DFAFC4014; Tue, 30 Aug 2011 16:12:58 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id B3650FC400C; Tue, 30 Aug 2011 16:12:58 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 30 Aug 2011 16:12:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC671E.CBA2A67D" Date: Tue, 30 Aug 2011 16:11:22 +0200 Message-ID: <8E09C72DBC577D489F13A71228C0B7BF029D2522@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <2979E38DD6FC6544B789C8DAD7BAFC520F72CCED@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CDNi] comments on draft-bertrand-cdni-use-cases-02 Thread-Index: AcxL1jXw3JFi3oNuSdWb2fXkqkNujQBfooOQBnHm7nA= References: <1AC8E92C-3A69-4C80-A235-710DEF396A53@cisco.com> <2979E38DD6FC6544B789C8DAD7BAFC520F72CCED@xmb-sjc-235.amer.cisco.com> From: To: X-OriginalArrivalTime: 30 Aug 2011 14:12:05.0881 (UTC) FILETIME=[CC28D690:01CC671E] Cc: cdni@ietf.org, draft-bertrand-cdni-use-cases@tools.ietf.org Subject: Re: [CDNi] comments on draft-bertrand-cdni-use-cases-02 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 14:11:36 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC671E.CBA2A67D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Kent, =20 Thanks for your review. =20 =20 =3D=3D=3D=3D=3D=3D=3D=3D 1. Sect 1.1 Terminology: The following are not new terms: CDN Provider, = dCDN, CDNI. These terms should go to one document later. =20 We are progressing on the cleaning of this section, keeping in mind that = all the definitions will be moved later to a unique draft.=20 =20 2. "Asymmetric Distribution" term doesn't match description well, IMHO. Maybe something like "Authorized Content Distribution"? It's probably = not much better. =20 We have removed this definition as the text did not use it anymore =20 3. Sect 1.2 Abbreviations: ISP, PC, STB, UE, VoD, WiFI are not used in = document. Maybe others too? =20 We have updated the list to remove the non-used acronyms. We will = cleanup the list again later, as the text evolves. =20 4. Consistency use of "CDN Interconnect" vs "CDN Interconnection" =20 Checked =20 5. Make sure to use terms properly "surrogate" -> "Surrogate", = "end-user" -> "End User", etc. =20 Done. I have lowercased all these terms (more readable, IMHO) =20 6. Sect 2.4 Delivery Restrictions: Typo "geo- location-based" =20 Corrected=20 =20 7. The bullets for maximum resolution do not seem relevant to CDNI. Would this be controlled by the CSP/SP that authorizes access to the = content by providing the URL to this type of resolution? The line is = blurring between content delivery limitations (in non-CDNI case) and = metadata relevant to CDNI. Definitely subscription should not be a = factor. It seems to me that if the request reaches the uCDN, access to = the content has already been authorized (i.e. to the End User or = device). =20 We are working on this point and should propose a text revision to = clarify these issues.=20 =20 8. Sect 3.2.1 and 3.2.2 Failure of Content: I'm not clear if dCDN is = allowed to obtain contain directly from CSP? If so, then the CDNI model = should have a Request Interface from dCDN to CSP. =20 I think acquisition on any origin server should be supported. We agree = that the interface for the actual content acquisition is out of scope; = however, the provision of the content source information is in scope. =20 9. Sect 4.1 Device and Network: The example assumes that CSP licensed = both high and low resolution content to CDN A, right? Not clear how UA = (mobile device) can get authorization to high resolution content? I = assume there will be some URL validation at uCDN. =20 We have clarified the section and are working on a text revision on = "content availability", to clarify the resolution-related issues. 10.Sect 7 Security: Typo "situtations" -> "situations" =20 Corrected. =3D=3D=3D=3D=3D=3D=3D=3D =20 =20 =20 Cheers, =20 Gilles =20 =20 -----Message d'origine----- De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part de = Kent Leung (kleung) Envoy=E9 : jeudi 28 juillet 2011 20:55 =C0 : Francois Le Faucheur (flefauch); = draft-bertrand-cdni-use-cases@tools.ietf.org Cc : cdni@ietf.org Objet : Re: [CDNi] comments on draft-bertrand-cdni-use-cases-02 =20 Hi. I'll pile on my comments under the same subject line. =20 1. Sect 1.1 Terminology: The following are not new terms: CDN Provider, = dCDN, CDNI. These terms should go to one document later. 2. "Asymmetric Distribution" term doesn't match description well, IMHO. Maybe something like "Authorized Content Distribution"? It's probably = not much better. 3. Sect 1.2 Abbreviations: ISP, PC, STB, UE, VoD, WiFI are not used in = document. Maybe others too? 4. Consistency use of "CDN Interconnect" vs "CDN Interconnection" 5. Make sure to use terms properly "surrogate" -> "Surrogate", = "end-user" -> "End User", etc. 6. Sect 2.4 Delivery Restrictions: Typo "geo- location-based" 7. The bullets for maximum resolution do not seem relevant to CDNI. Would this be controlled by the CSP/SP that authorizes access to the = content by providing the URL to this type of resolution? The line is = blurring between content delivery limitations (in non-CDNI case) and = metadata relevant to CDNI. Definitely subscription should not be a = factor. It seems to me that if the request reaches the uCDN, access to = the content has already been authorized (i.e. to the End User or = device). 8. Sect 3.2.1 and 3.2.2 Failure of Content: I'm not clear if dCDN is = allowed to obtain contain directly from CSP? If so, then the CDNI model = should have a Request Interface from dCDN to CSP. 9. Sect 4.1 Device and Network: The example assumes that CSP licensed = both high and low resolution content to CDN A, right? Not clear how UA = (mobile device) can get authorization to high resolution content? I = assume there will be some URL validation at uCDN. 10. Sect 7 Security: Typo "situtations" -> "situations" =20 Kent =20 =20 -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of = Francois Le Faucheur (flefauch) Sent: Tuesday, July 26, 2011 1:54 PM To: draft-bertrand-cdni-use-cases@tools.ietf.org Cc: cdni@ietf.org Subject: [CDNi] comments on draft-bertrand-cdni-use-cases-02 =20 Hello, =20 Please find my review comments below. Cheers =20 Francois =20 *** Abstract & Introduction: " It provides the business motivations for CDNI Working Group, which can = be used to validate different interconnection arrangements, and requirements of = the various CDNI interfaces. " Now the WG is formed you may want to adjust into something like: " It can be used to provide guidance to the CDNI WG about the = interconnection arrangements to be supported and to validate the = requirements of the various CDNI interfaces." =20 =20 *** Introduction: " This document now merges input from [I-D.watson-cdni-use-cases] and [I-D.ma-cdni-publisher-use-cases]. " I suggest you remove this historical info in new revs, as the document = gradually matures towards WG material. =20 =20 *** Introduction: " There are many possible combinations for the relationships between the different parties (Network Service Provider (NSP), CDN Provider, Content Service Provider (CSP) and End User) involved in end-to-end content delivery. However, in the context of interconnecting CDNs the key relationships are listed below. o How the CSP interacts with the CDN provider, so that the CDN delivers content in a manner compliant with CSP's distribution policies. o How the End User interacts with the CSP and one or more CDNs to request and receive content. o How the different CDN providers, operating their CDNs, interact with one another to deliver the CSP's content to the End User while continuing to enforce the CSP's distribution policies. " I don't quite see the relevance of this text in the use-case document, = or what point it is trying to bring across. In particular, it is a little confusing sine it talks about interfaces = that are out of scope for CDNI without saying so. =20 =20 *** 1.1 Terminology o I expect that terminology across problem-statement, requirements and = use-case needs to be aligned and made probably moved into one document = and referred by all the others.=20 o "CDN Peering": I am not sure we need that term.=20 o "Recursive request routing/ Recursive request routing": see discussion = on the list about moving those terms in a single doc=20 =20 =20 *** 1.3 High Level Use Cases for Multi-CDN Systems I found it a little = confusing to have the word "use cases" used here in the introduction as = well as later in teh individual use-cases. How about something like "Rationale or Multi-CDN Systems"? =20 =20 *** 1.3 High Level Use Cases for Multi-CDN Systems " CSP-1 benefits because it only needs to make one business agreement and one physical connection, with CDN Provider A, but its End Users get a service quality as though it had also gone to the trouble of making a business agreement with CDN Provider B. " s/as though it had /as though CSP-1 had / =20 =20 *** 1.4. The Need for CDNI Standards " Existing CDN interfaces are proprietary and an external CDN typically cannot use them, especially if the two CDNs rely on different solutions.=20 " It is difficult to use existing interfaces because they are proprietary, = but also because they have often been designed as intra-CDN/intra-domain = interfaces, so they don't have all the right attributes. Also, I think by "solutions" you mean "implementations". So perhaps: " Existing CDN interfaces are proprietary and have often been design = for intra-CDN/intra-domain operations. So an external CDN typically = cannot use them, especially if the two CDNs rely on different = implementations. " =20 " Nevertheless, [I-D.bertrand-cdni-experiments] shows that some level of CDN interconnection can be achieved experimentally without standardized interfaces between the CDNs. The methods used in these experiments are hardly usable in an operational context, because they suffer from several limitations in terms of functionalities, scalability, and security level. " s/ The methods used/However, the methods used/ =20 =20 " The aim of the CDNI standards work is therefore to overcome such shortcomings; a full list of requirements is being developed in [I-D.lefaucheur-cdni-requirements]. " s/the CDNI standards work/IETF CDNI WG solution/ =20 =20 ***2.1. Geographic Extension " In this use case, the CDN Provider wants to extend the geographic distribution that it can offer CSPs, without =20 o compromising the quality of delivery =20 o attracting transit and other network costs by serving from geographically or topologically remote surrogates. " I think would read better as: " In this use case, the CDN Provider wants to extend the geographic distribution that it can offer to its CSPs: =20 o without compromising the quality of delivery =20 o without incurring additional transit and other network costs that = would result from serving content from geographically or topologically remote surrogates. " =20 " As an example, suppose a French CSP wants to distribute its TV programs to End Users located in various countries in Europe and North Africa. It asks a French CDN Provider to deliver the content. The French CDN Provider's network only covers France, so it makes an agreement with another CDN Provider that covers North Africa. Overall, from the CSP's perspective the French CDN Provider provides a CDN service for both France and North Africa. " The example initially mentions a required coverage of Europe+ North = Africa, but then seem to descrive a solution for a coverage of France+North Africa. =20 =20 *** 2.2. Region to Region Interconnection I don't find the phrase = "Region to Region" very distinctive versus the previous "Geographic = Extension". I think the key differences here is that the different CDNs are operated = by different organization that are affiliates of the same company. So how about "Inter-Affiliates Interconnection"? =20 =20 *** 2.3. Nomadic Users You may want to mention that this is often loosely referred to as "TV = everywhere". =20 " The motivation in this case is to allow nomadic users to maintain = access, rather than to allow all residents within a region access to the content. " s/to maintain access/to maintain access with consistent quality of = experience/ =20 You may want to expand a little on which CDNs need to be interconnected = to address the use case (ie with CDN of "home NSP" interconnected to CDN = of visited NSP) possibly with a picture. =20 =20 *** 2.4. Delivery Restrictions "Hence, the exchange through the CDN interconnection of information for controlling the footprint of the delivery is an important use case. " To me this is not an additional use cases, this is a requirement that = has to be met in the use cases described earlier. In fact, the document = mixes use cases and requirements in a few places. I would suggest that : * you refer to things discussed in that section as "requirements" * add a statement clarifying these requirements apply to the use = cases discussed in the document. =20 " o an expiration time (i.e., the time at which the content files should be expunged from all CDN storage). " I understand this is saying that CDNI metadata need to include this = expiration time (triggering cache removal) , in addition to deactivation = time.=20 I don't think this is discussed in cdni-requirements yet. Can you bring = that up on the list with the cdni-reqts authors? =20 " The delivery of content may be further influenced by policies which may include quality of service rules that specify: o the maximum resolution deliverable to specific devices, o the maximum resolution deliverable though a specific NSP, or o the maximum resolution deliverable to users based on their subscription levels. " I don't think this is covered in the cdni-requirements doc.=20 It is not obvious to me that absolutely all of those ought to be in = phase 1. The first bullet only makes sense if the solution supports = transcoding/transrating, which I don't know if it will be supported in = Initial scope. The last bullet does not make sense to me as we don;t want the CDNs to = be aware of any user subscription levels (ie only CSP is aware of user = subscription level). =20 =20 *** 3.1. Overload Handling and Dimensioning " This brings dimensioning savings to the CDNs as they can use the = resources of each other during their peaks of activity. " s/their peaks of activity./ their respective peaks of activity./ =20 =20 *** 3.3. Branding Consideration Again, this seems more of a requirement than a use case per-say. I = recommend you make that clear upfront in teh section (ie this is not an = extra use cases, but a requirement applying to use-cases discussed = before). Also, is there a reason this applicable to only the use cases in section 3 and not section 2? Anotehr option may be to move 2.4 and 3.3 under a separate heading = somewhere collecting key requirements applicable to the many use cases.=20 =20 =20 *** 4.1. Device and Network Technology Extension Again I think some of = the discussion assumes that there is some conversion of quality done = inside the CDNs (as opposed to different terminal requesting different = URIs). I think we need to discuss whether this is going to come in Initial = Scope or not. =20 =20 =20 *** in Figure 2:=20 s/CDN Provider A/CDN Provider 1/ =20 =20 =20 *** co-authors. You have a long list of co-authors. As per current = practice, you would want to split that into "editors" and = "contributors". =20 _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni ------_=_NextPart_001_01CC671E.CBA2A67D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Kent,

 

Thanks for your review.

 

 

=3D=3D=3D=3D=3D=3D=3D=3D

1.  Sect = 1.1 Terminology: The following are not new terms: CDN Provider, dCDN, = CDNI.=A0 These terms should go to one document = later.

 

We are = progressing on the cleaning of this section, keeping in mind that all = the definitions will be moved later to a unique draft. =

 

2.  "Asymmetric Distribution" term doesn't match = description well, IMHO.

Maybe something like = "Authorized Content Distribution"? It's probably not much = better.

 

We have removed this definition as the text did not use it = anymore

 

3.  Sect = 1.2 Abbreviations: ISP, PC, STB, UE, VoD, WiFI are not used in = document.=A0 Maybe others too?

 

We have updated the list to = remove the non-used acronyms. We will cleanup the list again later, as = the text evolves.

 

4.  Consistency use of "CDN Interconnect" vs = "CDN Interconnection"

 

Checked

 

5.  Make = sure to use terms properly "surrogate" -> = "Surrogate", "end-user" -> "End User", = etc.

 

Done. I have lowercased all these terms (more readable, = IMHO)

 

6.  Sect = 2.4 Delivery Restrictions: Typo "geo- = location-based"

 

Corrected

 

7. = The bullets for maximum resolution do not seem relevant to = CDNI.

Would this be controlled = by the CSP/SP that authorizes access to the content by providing the URL = to this type of resolution?=A0 The line is blurring between content = delivery limitations (in non-CDNI case) and metadata relevant to = CDNI.=A0 Definitely subscription should not be a factor.=A0 It seems to = me that if the request reaches the uCDN, access to the content has = already been authorized (i.e. to the End User or = device).

 

We are working on this point and should propose a text = revision to clarify these issues.

 

8.  Sect = 3.2.1 and 3.2.2 Failure of Content: I'm not clear if dCDN is allowed to = obtain contain directly from CSP?=A0 If so, then the CDNI model should = have a Request Interface from dCDN to CSP.

 

I think acquisition on any = origin server should be supported. We agree that the interface for the = actual content acquisition is out of scope; however, the provision of = the content source information is in scope.

 

9.  Sect = 4.1 Device and Network: The example assumes that CSP licensed both high = and low resolution content to CDN A, right?=A0 Not clear how UA (mobile = device) can get authorization to high resolution content?=A0 I assume = there will be some URL validation at uCDN.

 

We have clarified the section = and are working on a text revision on "content availability", = to clarify the resolution-related issues.

10.Sect 7 Security: Typo "situtations" -> = "situations"

 

Corrected.

=3D=3D=3D=3D=3D=3D=3D=3D

 

 

 

Cheers,

 

Gilles

 

 

-----Message = d'origine-----
De : cdni-bounces@ietf.org = [mailto:cdni-bounces@ietf.org] De la part de Kent Leung = (kleung)
Envoy=E9 : jeudi 28 juillet 2011 20:55
=C0 : = Francois Le Faucheur (flefauch); = draft-bertrand-cdni-use-cases@tools.ietf.org
Cc : = cdni@ietf.org
Objet : Re: [CDNi] comments on = draft-bertrand-cdni-use-cases-02

 

Hi.=A0 I'll pile on my comments under the same subject = line.

 

1. Sect 1.1 Terminology: The following are not new terms: = CDN Provider, dCDN, CDNI.=A0 These terms should go to one document = later.

2. "Asymmetric Distribution" term doesn't match = description well, IMHO.

Maybe something like = "Authorized Content Distribution"? It's probably not much = better.

3. Sect 1.2 Abbreviations: ISP, PC, STB, UE, VoD, WiFI are = not used in document.=A0 Maybe others too?

4. Consistency use of "CDN = Interconnect" vs "CDN = Interconnection"

5. Make sure to use terms properly "surrogate" = -> "Surrogate", "end-user" -> "End = User", etc.

6. Sect 2.4 Delivery Restrictions: Typo "geo- = location-based"

7. The bullets for maximum resolution do not seem relevant = to CDNI.

Would this be controlled by the CSP/SP that authorizes = access to the content by providing the URL to this type of = resolution?=A0 The line is blurring between content delivery limitations = (in non-CDNI case) and metadata relevant to CDNI.=A0 Definitely = subscription should not be a factor.=A0 It seems to me that if the = request reaches the uCDN, access to the content has already been = authorized (i.e. to the End User or device).

8. Sect 3.2.1 and 3.2.2 Failure = of Content: I'm not clear if dCDN is allowed to obtain contain directly = from CSP?=A0 If so, then the CDNI model should have a Request Interface = from dCDN to CSP.

9. Sect 4.1 Device and Network: The example assumes that = CSP licensed both high and low resolution content to CDN A, right?=A0 = Not clear how UA (mobile device) can get authorization to high = resolution content?=A0 I assume there will be some URL validation at = uCDN.

10. Sect 7 Security: Typo "situtations" -> = "situations"

 

Kent

 

 

-----Original = Message-----

From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] = On Behalf Of Francois Le Faucheur (flefauch)

Sent: Tuesday, July 26, 2011 = 1:54 PM

To: = draft-bertrand-cdni-use-cases@tools.ietf.org

Cc: = cdni@ietf.org

Subject: [CDNi] comments on = draft-bertrand-cdni-use-cases-02

 

Hello,

 

Please find my review comments = below.

Cheers

 

Francois

 

*** Abstract & Introduction:

"

It provides the business = motivations for CDNI Working Group, which can be used = to

=A0=A0 validate different interconnection arrangements, and = requirements of the various CDNI interfaces.

"

Now the WG is formed you may = want to adjust into something like:

"

It can be used to provide = guidance to the CDNI WG about the interconnection arrangements to be = supported and to validate the requirements of the various CDNI = interfaces."

 

 

*** Introduction:

"

This document now merges input = from [I-D.watson-cdni-use-cases] and

=A0=A0 = [I-D.ma-cdni-publisher-use-cases].

"

I suggest you remove this = historical info in new revs, as the document gradually matures towards = WG material.

 

 

*** Introduction:

"

There are many possible = combinations for the relationships between

=A0=A0 the different parties = (Network Service Provider (NSP), CDN Provider,

=A0=A0 Content Service Provider = (CSP) and End User) involved in end-to-end

=A0=A0 content delivery.=A0 = However, in the context of interconnecting CDNs

=A0=A0 the key relationships are = listed below.

=A0=A0 o=A0 How the CSP interacts with the CDN provider, so = that the CDN

=A0=A0=A0=A0=A0 delivers content in a manner compliant with = CSP's distribution

=A0=A0=A0=A0=A0 policies.

=A0=A0 o=A0 How the End User = interacts with the CSP and one or more CDNs to

=A0=A0=A0=A0=A0 request and = receive content.

=A0=A0 o=A0 How the different CDN providers, operating = their CDNs, interact

=A0=A0=A0=A0=A0 with one another to deliver the CSP's = content to the End User

=A0=A0=A0=A0=A0 while continuing = to enforce the CSP's distribution policies.

"

I don't quite see the relevance = of this text in the use-case document, or what point it is trying to = bring across.

In particular, it is a little confusing sine it talks about = interfaces that are out of scope for CDNI without saying = so.

 

 

*** 1.1 Terminology

o I expect that terminology = across problem-statement, requirements and use-case needs to be aligned = and made probably moved into one document and referred by all the = others.

o "CDN Peering": I am not sure we need that term. =

o = "Recursive request routing/ Recursive request routing": see = discussion on the list about moving those terms in a single doc =

 

 

*** 1.3 High Level Use Cases for Multi-CDN Systems I found = it a little confusing to have the word "use cases" used here = in the introduction as well as later in teh individual = use-cases.

How about something like "Rationale or Multi-CDN = Systems"?

 

 

*** 1.3 High Level Use Cases for Multi-CDN Systems = "

= CSP-1 benefits because it only needs to make one business = agreement

=A0=A0 and one physical connection, with CDN Provider A, = but its End Users

=A0=A0 get a service quality as though it had also gone to = the trouble of

=A0=A0 making a business agreement with CDN Provider = B.

"

s/as though it had /as though CSP-1 had = /

 

 

*** 1.4.=A0 The Need for CDNI = Standards

"

=A0=A0 Existing CDN interfaces are proprietary and an = external CDN typically

=A0=A0 cannot use them, = especially if the two CDNs rely on different

=A0=A0 solutions. =

"

It is difficult to use existing interfaces because they are = proprietary, but also because they have often been designed as = intra-CDN/intra-domain interfaces, so they don't have all the right = attributes.

Also, I think by "solutions" you mean = "implementations".

So = perhaps:

"

=A0=A0 Existing CDN interfaces are proprietary and have = often been design for intra-CDN/intra-domain operations. So an external = CDN typically cannot use them, especially if the two CDNs rely on = different implementations.

"

 

"

Nevertheless, = [I-D.bertrand-cdni-experiments] shows that

=A0=A0 some level of CDN = interconnection can be achieved experimentally

=A0=A0 without standardized = interfaces between the CDNs.=A0 The methods used

=A0=A0 in these experiments are = hardly usable in an operational context,

=A0=A0 because they suffer from = several limitations in terms of

=A0=A0 functionalities, = scalability, and security level.

"

s/ The methods used/However, the = methods used/

 

 

"

=A0=A0 The aim of the CDNI standards work is therefore to = overcome such

=A0=A0 shortcomings; a full list of requirements is being = developed in

=A0=A0 = [I-D.lefaucheur-cdni-requirements].

"

s/the CDNI standards work/IETF = CDNI WG solution/

 

 

***2.1.=A0 Geographic Extension

"

=A0=A0 In this use case, the CDN = Provider wants to extend the geographic

=A0=A0 distribution that it can = offer CSPs, without

 

=A0=A0 o=A0 compromising the quality of = delivery

 

=A0=A0 o=A0 attracting transit and other network costs by = serving from

=A0=A0=A0=A0=A0 geographically or topologically remote = surrogates.

"

I think would read better as:

"

=A0=A0 In this use case, the CDN = Provider wants to extend the geographic

=A0=A0 distribution that it can = offer to its CSPs:

 

=A0=A0 o=A0 without compromising the quality of = delivery

 

=A0=A0 o=A0 without incurring additional transit and other = network costs that would result from serving content = from

=A0=A0=A0=A0=A0 geographically or topologically remote = surrogates.

"

 

"

As an example, suppose a French CSP wants to distribute its = TV

=A0=A0 programs to End Users located in various countries = in Europe and

=A0=A0 North Africa.=A0 It asks a French CDN Provider to = deliver the content.

=A0=A0 The French CDN Provider's network only covers = France, so it makes an

=A0=A0 agreement with another = CDN Provider that covers North Africa.

=A0=A0 Overall, from the CSP's = perspective the French CDN Provider provides

=A0=A0 a CDN service for both = France and North Africa.

"

The example initially mentions a = required coverage of Europe+ North Africa, but then seem to descrive a = solution for a coverage of

France+North = Africa.

 

 

*** 2.2.=A0 Region to Region Interconnection I don't find = the phrase "Region to Region" very distinctive versus the = previous "Geographic Extension".

I think the key differences here = is that the different CDNs are operated by different organization that = are affiliates of the same company.

So how about = "Inter-Affiliates Interconnection"?

 

 

*** 2.3.=A0 Nomadic = Users

You may want to mention that this is often loosely referred = to as "TV everywhere".

 

"

The motivation in this case is = to allow nomadic users to maintain access,

=A0=A0 rather than to allow all = residents within a region access to the

=A0=A0 = content.

"

s/to maintain access/to maintain access with consistent = quality of experience/

 

You may want to expand a little = on which CDNs need to be interconnected to address the use case (ie with = CDN of "home NSP" interconnected to CDN of visited NSP) = possibly with a picture.

 

 

*** 2.4.=A0 Delivery = Restrictions

"Hence, the exchange through the CDN interconnection = of information

=A0=A0 for controlling the footprint of the delivery is an = important use

=A0=A0 case.

"

To me this is not an additional = use cases, this is a requirement that has to be met in the use cases = described earlier. In fact, the document mixes use cases and = requirements in a few places.

I would suggest that = :

=A0=A0=A0=A0=A0 * you refer to=A0 things discussed in that = section as "requirements"

=A0=A0=A0=A0=A0 * add a = statement clarifying these requirements apply to the use cases discussed = in the document.

 

"

=A0=A0 o=A0 an expiration time (i.e., the time at which the = content files

=A0=A0=A0=A0=A0 should be expunged from all CDN = storage).

"

I understand this is saying that CDNI metadata need to = include this expiration time (triggering cache removal) , in addition to = deactivation time.

I don't think this is discussed in cdni-requirements yet. = Can you bring that up on the list with the cdni-reqts = authors?

 

"

=A0=A0 The delivery of content may be further influenced by = policies which

=A0=A0 may include quality of service rules that = specify:

=A0=A0 o=A0 the maximum resolution deliverable to specific = devices,

=A0=A0 o=A0 the maximum resolution deliverable though a = specific NSP, or

=A0=A0 o=A0 the maximum resolution deliverable to users = based on their

=A0=A0=A0=A0=A0 subscription = levels.

"

I don't think this is covered in the cdni-requirements doc. =

It is = not obvious to me that absolutely all of those ought to be in phase 1. = The first bullet only makes sense if the solution supports = transcoding/transrating, which I don't know if it will be supported in = Initial scope.

The last bullet does not make sense to me as we don;t want = the CDNs to be aware of any user subscription levels (ie only CSP is = aware of user subscription level).

 

 

*** 3.1.=A0 Overload Handling = and Dimensioning "

This brings dimensioning savings = to the CDNs as they can use the resources

=A0=A0 of each other during = their peaks of activity.

"

s/their peaks of activity./ = their respective peaks of activity./

 

 

*** 3.3.=A0 Branding = Consideration

Again, this seems more of a requirement than a use case = per-say. I recommend you make that clear upfront in teh section (ie this = is not an extra use cases, but a requirement applying to use-cases = discussed before).

Also, is there a reason this applicable to only the use = cases in section

3 and not section 2?

Anotehr option may be to move = 2.4 and 3.3 under a separate heading somewhere collecting key = requirements applicable to the many use cases.

 

 

*** 4.1.=A0 Device and Network = Technology Extension Again I think some of the discussion assumes that = there is some conversion of quality done inside the CDNs (as opposed to = different terminal requesting different URIs).

I think we need to discuss = whether this is going to come in Initial Scope or = not.

 

 

 

*** in Figure 2:

s/CDN Provider A/CDN Provider = 1/

 

 

 

*** co-authors. You have a long list of co-authors. As per = current practice, you would want to split that into "editors" = and "contributors".

 

_______________________________________________

CDNi mailing = list

CDNi@ietf.org

https://www.ietf.org/mailman/listinfo/cdni=

_______________________________________________

CDNi mailing = list

CDNi@ietf.org

https://www.ietf.org/mailman/listinfo/cdni=

------_=_NextPart_001_01CC671E.CBA2A67D-- From gilles.bertrand@orange-ftgroup.com Tue Aug 30 07:11:36 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9819121F8BF8 for ; Tue, 30 Aug 2011 07:11:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.348 X-Spam-Level: X-Spam-Status: No, score=-1.348 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, J_CHICKENPOX_65=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g3+v-d6O7l4w for ; Tue, 30 Aug 2011 07:11:33 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id E3DE521F8BF6 for ; Tue, 30 Aug 2011 07:11:32 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id AEAAEFDC006; Tue, 30 Aug 2011 16:12:58 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 9C98AFC4014; Tue, 30 Aug 2011 16:12:58 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 30 Aug 2011 16:12:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC671E.CB991D11" Date: Tue, 30 Aug 2011 16:11:49 +0200 Message-ID: <8E09C72DBC577D489F13A71228C0B7BF029D2521@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <1AC8E92C-3A69-4C80-A235-710DEF396A53@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: comments on draft-bertrand-cdni-use-cases-02 Thread-Index: AcxL1iM1pyrrccVoRJqUCOzVpI6x9AbQwDFQ References: <1AC8E92C-3A69-4C80-A235-710DEF396A53@cisco.com> From: To: X-OriginalArrivalTime: 30 Aug 2011 14:12:05.0552 (UTC) FILETIME=[CBF6A300:01CC671E] Cc: cdni@ietf.org, draft-bertrand-cdni-use-cases@tools.ietf.org Subject: Re: [CDNi] comments on draft-bertrand-cdni-use-cases-02 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 14:11:36 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC671E.CB991D11 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Fran=E7ois, =20 Thanks for your review. =20 =3D=3D=3D=3D=3D=3D=3D=3D =20 *** Abstract & Introduction: " It provides the business motivations for CDNI Working Group, which can = be used to validate different interconnection arrangements, and requirements of = the various CDNI interfaces. " Now the WG is formed you may want to adjust into something like: " It can be used to provide guidance to the CDNI WG about the = interconnection arrangements to be supported and to validate the = requirements of the various CDNI interfaces." =20 Done =20 *** Introduction: " This document now merges input from [I-D.watson-cdni-use-cases] and [I-D.ma-cdni-publisher-use-cases]. " I suggest you remove this historical info in new revs, as the document = gradually matures towards WG material. =20 Done =20 *** Introduction: " There are many possible combinations for the relationships between the different parties (Network Service Provider (NSP), CDN Provider, Content Service Provider (CSP) and End User) involved in end-to-end content delivery. However, in the context of interconnecting CDNs the key relationships are listed below. o How the CSP interacts with the CDN provider, so that the CDN delivers content in a manner compliant with CSP's distribution policies. o How the End User interacts with the CSP and one or more CDNs to request and receive content. o How the different CDN providers, operating their CDNs, interact with one another to deliver the CSP's content to the End User while continuing to enforce the CSP's distribution policies. " I don't quite see the relevance of this text in the use-case document, = or what point it is trying to bring across. In particular, it is a little confusing sine it talks about interfaces = that are out of scope for CDNI without saying so. =20 Text removed =20 =20 *** 1.1 Terminology o I expect that terminology across problem-statement, requirements and = use-case needs to be aligned and made probably moved into one document = and referred by all the others.=20 o "CDN Peering": I am not sure we need that term.=20 o "Recursive request routing/ Recursive request routing": see discussion = on the list about moving those terms in a single doc=20 =20 We are progressing on the cleaning of this section, keeping in mind that = all the definitions will be moved later to a unique draft.=20 =20 =20 *** 1.3 High Level Use Cases for Multi-CDN Systems I found it a little = confusing to have the word "use cases" used here in the introduction as = well as later in teh individual use-cases. How about something like "Rationale or Multi-CDN Systems"? =20 Done =20 *** 1.3 High Level Use Cases for Multi-CDN Systems " CSP-1 benefits because it only needs to make one business agreement and one physical connection, with CDN Provider A, but its End Users get a service quality as though it had also gone to the trouble of making a business agreement with CDN Provider B. " s/as though it had /as though CSP-1 had / =20 Done =20 *** 1.4. The Need for CDNI Standards " Existing CDN interfaces are proprietary and an external CDN typically cannot use them, especially if the two CDNs rely on different solutions.=20 " It is difficult to use existing interfaces because they are proprietary, = but also because they have often been designed as intra-CDN/intra-domain = interfaces, so they don't have all the right attributes. Also, I think by "solutions" you mean "implementations". So perhaps: " Existing CDN interfaces are proprietary and have often been designed = for intra-CDN/intra-domain operations. So an external CDN typically = cannot use them, especially if the two CDNs rely on different = implementations. " =20 Done =20 " Nevertheless, [I-D.bertrand-cdni-experiments] shows that some level of CDN interconnection can be achieved experimentally without standardized interfaces between the CDNs. The methods used in these experiments are hardly usable in an operational context, because they suffer from several limitations in terms of functionalities, scalability, and security level. " s/ The methods used/However, the methods used/ =20 Done =20 " The aim of the CDNI standards work is therefore to overcome such shortcomings; a full list of requirements is being developed in [I-D.lefaucheur-cdni-requirements]. " s/the CDNI standards work/IETF CDNI WG solution/ =20 Done =20 ***2.1. Geographic Extension " In this use case, the CDN Provider wants to extend the geographic distribution that it can offer CSPs, without =20 o compromising the quality of delivery =20 o attracting transit and other network costs by serving from geographically or topologically remote surrogates. " I think would read better as: " In this use case, the CDN Provider wants to extend the geographic distribution that it can offer to its CSPs: =20 o without compromising the quality of delivery =20 o without incurring additional transit and other network costs that = would result from serving content from geographically or topologically remote surrogates. " =20 Done =20 " As an example, suppose a French CSP wants to distribute its TV programs to End Users located in various countries in Europe and North Africa. It asks a French CDN Provider to deliver the content. The French CDN Provider's network only covers France, so it makes an agreement with another CDN Provider that covers North Africa. Overall, from the CSP's perspective the French CDN Provider provides a CDN service for both France and North Africa. " The example initially mentions a required coverage of Europe+ North = Africa, but then seem to descrive a solution for a coverage of = France+North Africa. =20 Corrected =20 *** 2.2. Region to Region Interconnection I don't find the phrase = "Region to Region" very distinctive versus the previous "Geographic = Extension". I think the key differences here is that the different CDNs are operated = by different organization that are affiliates of the same company. So how about "Inter-Affiliates Interconnection"? =20 Done =20 *** 2.3. Nomadic Users You may want to mention that this is often loosely referred to as "TV = everywhere". =20 In progress. =20 " The motivation in this case is to allow nomadic users to maintain = access, rather than to allow all residents within a region access to the content. " s/to maintain access/to maintain access with consistent quality of = experience/ Done =20 You may want to expand a little on which CDNs need to be interconnected = to address the use case (ie with CDN of "home NSP" interconnected to CDN = of visited NSP) possibly with a picture. =20 In progress. =20 =20 *** 2.4. Delivery Restrictions "Hence, the exchange through the CDN interconnection of information for controlling the footprint of the delivery is an important use case. " To me this is not an additional use cases, this is a requirement that = has to be met in the use cases described earlier. In fact, the document = mixes use cases and requirements in a few places. I would suggest that : * you refer to things discussed in that section as "requirements" * add a statement clarifying these requirements apply to the use = cases discussed in the document. =20 " o an expiration time (i.e., the time at which the content files should be expunged from all CDN storage). " I understand this is saying that CDNI metadata need to include this = expiration time (triggering cache removal) , in addition to deactivation = time.=20 I don't think this is discussed in cdni-requirements yet. Can you bring = that up on the list with the cdni-reqts authors? =20 " The delivery of content may be further influenced by policies which may include quality of service rules that specify: o the maximum resolution deliverable to specific devices, o the maximum resolution deliverable though a specific NSP, or o the maximum resolution deliverable to users based on their subscription levels. " I don't think this is covered in the cdni-requirements doc.=20 It is not obvious to me that absolutely all of those ought to be in = phase 1. The first bullet only makes sense if the solution supports = transcoding/transrating, which I don't know if it will be supported in = Initial scope. The last bullet does not make sense to me as we don;t want the CDNs to = be aware of any user subscription levels (ie only CSP is aware of user = subscription level). =20 We have collected the requirements-like use cases in a new section about = "Content Availability", and we are working on it to take all the = received comments into account. =20 =20 *** 3.1. Overload Handling and Dimensioning " This brings dimensioning savings to the CDNs as they can use the = resources of each other during their peaks of activity. " s/their peaks of activity./ their respective peaks of activity./ =20 Done =20 *** 3.3. Branding Consideration Again, this seems more of a requirement than a use case per-say. I = recommend you make that clear upfront in teh section (ie this is not an = extra use cases, but a requirement applying to use-cases discussed = before). Also, is there a reason this applicable to only the use cases in section = 3 and not section 2? Anotehr option may be to move 2.4 and 3.3 under a separate heading = somewhere collecting key requirements applicable to the many use cases.=20 =20 We are working to improve this section. =20 *** 4.1. Device and Network Technology Extension Again I think some of = the discussion assumes that there is some conversion of quality done = inside the CDNs (as opposed to different terminal requesting different = URIs). I think we need to discuss whether this is going to come in Initial = Scope or not. =20 This section presents a quite general use case in which a CDN1 delegates = requests to another CDN2 that offers any function that CDN1 is not able = to provide. It does not assume that quality conversion is done in the = CDN, although this one of the possible examples for this use case. =20 *** in Figure 2:=20 s/CDN Provider A/CDN Provider 1/ =20 We have removed this figure =20 *** co-authors. You have a long list of co-authors. As per current = practice, you would want to split that into "editors" and = "contributors". =20 We need to discuss this point with the co-authors. =3D=3D=3D=3D=3D=3D=3D=3D =20 =20 Best regards, =20 Gilles =20 -----Message d'origine----- De : Francois Le Faucheur [mailto:flefauch@cisco.com]=20 Envoy=E9 : mardi 26 juillet 2011 22:54 =C0 : draft-bertrand-cdni-use-cases@tools.ietf.org Cc : Le Faucheur Francois; cdni@ietf.org Objet : comments on draft-bertrand-cdni-use-cases-02 =20 Hello, =20 Please find my review comments below. Cheers =20 Francois =20 *** Abstract & Introduction: " It provides the business motivations for CDNI Working Group, which can = be used to validate different interconnection arrangements, and requirements of = the various CDNI interfaces. " Now the WG is formed you may want to adjust into something like: " It can be used to provide guidance to the CDNI WG about the = interconnection arrangements to be supported and to validate the = requirements of the various CDNI interfaces." =20 =20 *** Introduction: " This document now merges input from [I-D.watson-cdni-use-cases] and [I-D.ma-cdni-publisher-use-cases]. " I suggest you remove this historical info in new revs, as the document = gradually matures towards WG material. =20 =20 *** Introduction: " There are many possible combinations for the relationships between the different parties (Network Service Provider (NSP), CDN Provider, Content Service Provider (CSP) and End User) involved in end-to-end content delivery. However, in the context of interconnecting CDNs the key relationships are listed below. o How the CSP interacts with the CDN provider, so that the CDN delivers content in a manner compliant with CSP's distribution policies. o How the End User interacts with the CSP and one or more CDNs to request and receive content. o How the different CDN providers, operating their CDNs, interact with one another to deliver the CSP's content to the End User while continuing to enforce the CSP's distribution policies. " I don't quite see the relevance of this text in the use-case document, = or what point it is trying to bring across. In particular, it is a little confusing sine it talks about interfaces = that are out of scope for CDNI without saying so. =20 =20 *** 1.1 Terminology o I expect that terminology across problem-statement, requirements and = use-case needs to be aligned and made probably moved into one document = and referred by all the others.=20 o "CDN Peering": I am not sure we need that term.=20 o "Recursive request routing/ Recursive request routing": see discussion = on the list about moving those terms in a single doc=20 =20 =20 *** 1.3 High Level Use Cases for Multi-CDN Systems I found it a little = confusing to have the word "use cases" used here in the introduction as = well as later in teh individual use-cases. How about something like "Rationale or Multi-CDN Systems"? =20 =20 *** 1.3 High Level Use Cases for Multi-CDN Systems " CSP-1 benefits because it only needs to make one business agreement and one physical connection, with CDN Provider A, but its End Users get a service quality as though it had also gone to the trouble of making a business agreement with CDN Provider B. " s/as though it had /as though CSP-1 had / =20 =20 *** 1.4. The Need for CDNI Standards " Existing CDN interfaces are proprietary and an external CDN typically cannot use them, especially if the two CDNs rely on different solutions.=20 " It is difficult to use existing interfaces because they are proprietary, = but also because they have often been designed as intra-CDN/intra-domain = interfaces, so they don't have all the right attributes. Also, I think by "solutions" you mean "implementations". So perhaps: " Existing CDN interfaces are proprietary and have often been design = for intra-CDN/intra-domain operations. So an external CDN typically = cannot use them, especially if the two CDNs rely on different = implementations. " =20 " Nevertheless, [I-D.bertrand-cdni-experiments] shows that some level of CDN interconnection can be achieved experimentally without standardized interfaces between the CDNs. The methods used in these experiments are hardly usable in an operational context, because they suffer from several limitations in terms of functionalities, scalability, and security level. " s/ The methods used/However, the methods used/ =20 =20 " The aim of the CDNI standards work is therefore to overcome such shortcomings; a full list of requirements is being developed in [I-D.lefaucheur-cdni-requirements]. " s/the CDNI standards work/IETF CDNI WG solution/ =20 =20 ***2.1. Geographic Extension " In this use case, the CDN Provider wants to extend the geographic distribution that it can offer CSPs, without =20 o compromising the quality of delivery =20 o attracting transit and other network costs by serving from geographically or topologically remote surrogates. " I think would read better as: " In this use case, the CDN Provider wants to extend the geographic distribution that it can offer to its CSPs: =20 o without compromising the quality of delivery =20 o without incurring additional transit and other network costs that = would result from serving content from geographically or topologically remote surrogates. " =20 " As an example, suppose a French CSP wants to distribute its TV programs to End Users located in various countries in Europe and North Africa. It asks a French CDN Provider to deliver the content. The French CDN Provider's network only covers France, so it makes an agreement with another CDN Provider that covers North Africa. Overall, from the CSP's perspective the French CDN Provider provides a CDN service for both France and North Africa. " The example initially mentions a required coverage of Europe+ North = Africa, but then seem to descrive a solution for a coverage of = France+North Africa. =20 =20 *** 2.2. Region to Region Interconnection I don't find the phrase = "Region to Region" very distinctive versus the previous "Geographic = Extension". I think the key differences here is that the different CDNs are operated = by different organization that are affiliates of the same company. So how about "Inter-Affiliates Interconnection"? =20 =20 *** 2.3. Nomadic Users You may want to mention that this is often loosely referred to as "TV = everywhere". =20 " The motivation in this case is to allow nomadic users to maintain = access, rather than to allow all residents within a region access to the content. " s/to maintain access/to maintain access with consistent quality of = experience/ =20 You may want to expand a little on which CDNs need to be interconnected = to address the use case (ie with CDN of "home NSP" interconnected to CDN = of visited NSP) possibly with a picture. =20 =20 *** 2.4. Delivery Restrictions "Hence, the exchange through the CDN interconnection of information for controlling the footprint of the delivery is an important use case. " To me this is not an additional use cases, this is a requirement that = has to be met in the use cases described earlier. In fact, the document = mixes use cases and requirements in a few places. I would suggest that : * you refer to things discussed in that section as "requirements" * add a statement clarifying these requirements apply to the use = cases discussed in the document. =20 " o an expiration time (i.e., the time at which the content files should be expunged from all CDN storage). " I understand this is saying that CDNI metadata need to include this = expiration time (triggering cache removal) , in addition to deactivation = time.=20 I don't think this is discussed in cdni-requirements yet. Can you bring = that up on the list with the cdni-reqts authors? =20 " The delivery of content may be further influenced by policies which may include quality of service rules that specify: o the maximum resolution deliverable to specific devices, o the maximum resolution deliverable though a specific NSP, or o the maximum resolution deliverable to users based on their subscription levels. " I don't think this is covered in the cdni-requirements doc.=20 It is not obvious to me that absolutely all of those ought to be in = phase 1. The first bullet only makes sense if the solution supports = transcoding/transrating, which I don't know if it will be supported in = Initial scope. The last bullet does not make sense to me as we don;t want the CDNs to = be aware of any user subscription levels (ie only CSP is aware of user = subscription level). =20 =20 *** 3.1. Overload Handling and Dimensioning " This brings dimensioning savings to the CDNs as they can use the = resources of each other during their peaks of activity. " s/their peaks of activity./ their respective peaks of activity./ =20 =20 *** 3.3. Branding Consideration Again, this seems more of a requirement than a use case per-say. I = recommend you make that clear upfront in teh section (ie this is not an = extra use cases, but a requirement applying to use-cases discussed = before). Also, is there a reason this applicable to only the use cases in section = 3 and not section 2? Anotehr option may be to move 2.4 and 3.3 under a separate heading = somewhere collecting key requirements applicable to the many use cases.=20 =20 =20 *** 4.1. Device and Network Technology Extension Again I think some of = the discussion assumes that there is some conversion of quality done = inside the CDNs (as opposed to different terminal requesting different = URIs). I think we need to discuss whether this is going to come in Initial = Scope or not. =20 =20 =20 *** in Figure 2:=20 s/CDN Provider A/CDN Provider 1/ =20 =20 =20 *** co-authors. You have a long list of co-authors. As per current = practice, you would want to split that into "editors" and = "contributors". =20 ------_=_NextPart_001_01CC671E.CB991D11 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Fran=E7ois,

 

Thanks for your = review.

 

=3D=3D=3D=3D=3D=3D=3D=3D<= o:p>

 

*** Abstract & = Introduction:

"

It provides the business = motivations for CDNI Working Group, which can be used = to

   validate = different interconnection arrangements, and requirements of the various = CDNI interfaces.

"

Now the WG is formed you = may want to adjust into something like:

"

It can be used to = provide guidance to the CDNI WG about the interconnection arrangements = to be supported and to validate the requirements of the various CDNI = interfaces."

 

Done

 

*** = Introduction:

"

This document now merges = input from [I-D.watson-cdni-use-cases] and

   = [I-D.ma-cdni-publisher-use-cases].

"

I suggest you remove = this historical info in new revs, as the document gradually matures = towards WG material.

 

Done

 

*** = Introduction:

"

There are many possible = combinations for the relationships between

   the different parties (Network Service = Provider (NSP), CDN Provider,

   Content Service Provider (CSP) and End User) = involved in end-to-end

   content = delivery.  However, in the context of interconnecting = CDNs

   the key = relationships are listed below.

   o  How the CSP interacts with the CDN = provider, so that the CDN

      delivers content in a manner = compliant with CSP's distribution

      = policies.

   o  How = the End User interacts with the CSP and one or more CDNs = to

      request and receive = content.

   o  How = the different CDN providers, operating their CDNs, = interact

      with one another to deliver = the CSP's content to the End User

      while continuing to enforce = the CSP's distribution policies.

"

I don't quite see the = relevance of this text in the use-case document, or what point it is = trying to bring across.

In particular, it is a = little confusing sine it talks about interfaces that are out of scope = for CDNI without saying so.

 

Text removed

 

 

*** 1.1 = Terminology

o I expect that = terminology across problem-statement, requirements and use-case needs to = be aligned and made probably moved into one document and referred by all = the others.

o "CDN = Peering": I am not sure we need that term.

o = "Recursive request routing/ Recursive request routing": see = discussion on the list about moving those terms in a single doc =

 

We are progressing on the cleaning of this section, keeping = in mind that all the definitions will be moved later to a unique draft. =

 

 

*** 1.3 High Level Use = Cases for Multi-CDN Systems I found it a little confusing to have the = word "use cases" used here in the introduction as well as = later in teh individual use-cases.

How = about something like "Rationale or Multi-CDN = Systems"?

 

Done

 

*** 1.3 High Level Use = Cases for Multi-CDN Systems "

CSP-1 benefits because it only needs to make one business = agreement

   and one = physical connection, with CDN Provider A, but its End = Users

   get a = service quality as though it had also gone to the trouble = of

   making a = business agreement with CDN Provider B.

"

s/as though it had /as = though CSP-1 had /

 

Done

 

*** 1.4.  The Need = for CDNI Standards

"

   Existing = CDN interfaces are proprietary and an external CDN = typically

   cannot use = them, especially if the two CDNs rely on = different

   solutions. =

"

It is difficult to use = existing interfaces because they are proprietary, but also because they = have often been designed as intra-CDN/intra-domain interfaces, so they = don't have all the right attributes.

Also, I think by "solutions" you mean = "implementations".

So = perhaps:

"

   Existing = CDN interfaces are proprietary and have often been designed for = intra-CDN/intra-domain operations. So an external CDN typically cannot = use them, especially if the two CDNs rely on different = implementations.

"

 

Done

 

"

Nevertheless, = [I-D.bertrand-cdni-experiments] shows that

   some level of CDN interconnection can be = achieved experimentally

   without = standardized interfaces between the CDNs.  The methods = used

   in these = experiments are hardly usable in an operational = context,

   because = they suffer from several limitations in terms of

   functionalities, scalability, and security = level.

"

s/ The methods = used/However, the methods used/

 

Done

 

"

   The aim of = the CDNI standards work is therefore to overcome = such

   = shortcomings; a full list of requirements is being developed = in

   = [I-D.lefaucheur-cdni-requirements].

"

s/the CDNI standards = work/IETF CDNI WG solution/

 

Done

 

***2.1.  Geographic = Extension

"

   In this use = case, the CDN Provider wants to extend the = geographic

   = distribution that it can offer CSPs, without

 

   o  = compromising the quality of delivery

 

   o  = attracting transit and other network costs by serving = from

      geographically or = topologically remote surrogates.

"

I think would read = better as:

"

   In this use = case, the CDN Provider wants to extend the = geographic

   = distribution that it can offer to its CSPs:

 

   o  = without compromising the quality of delivery

 

   o  = without incurring additional transit and other network costs that would = result from serving content from

      geographically or = topologically remote surrogates.

"

 

Done

 

"

As an example, suppose a = French CSP wants to distribute its TV

   programs to End Users located in various = countries in Europe and

   North = Africa.  It asks a French CDN Provider to deliver the = content.

   The French = CDN Provider's network only covers France, so it makes = an

   agreement = with another CDN Provider that covers North = Africa.

   Overall, = from the CSP's perspective the French CDN Provider = provides

   a CDN = service for both France and North Africa.

"

The example initially = mentions a required coverage of Europe+ North Africa, but then seem to = descrive a solution for a coverage of France+North = Africa.

 

Corrected

 

*** 2.2.  Region to = Region Interconnection I don't find the phrase "Region to = Region" very distinctive versus the previous "Geographic = Extension".

I think the key = differences here is that the different CDNs are operated by different = organization that are affiliates of the same = company.

So how about = "Inter-Affiliates Interconnection"?

 

Done

 

*** 2.3.  Nomadic = Users

You may want to mention = that this is often loosely referred to as "TV = everywhere".

 

In progress.

 

"

The motivation in this = case is to allow nomadic users to maintain = access,

   rather than = to allow all residents within a region access to = the

   = content.

"

s/to maintain access/to = maintain access with consistent quality of = experience/

Done

 

You may want to expand a = little on which CDNs need to be interconnected to address the use case = (ie with CDN of "home NSP" interconnected to CDN of visited = NSP) possibly with a picture.

 

In = progress.

 

 

*** 2.4.  Delivery = Restrictions

"Hence, the = exchange through the CDN interconnection of = information

   for = controlling the footprint of the delivery is an important = use

   = case.

"

To me this is not an = additional use cases, this is a requirement that has to be met in the = use cases described earlier. In fact, the document mixes use cases and = requirements in a few places.

I = would suggest that :

      * you refer to  things = discussed in that section as = "requirements"

      * add a statement clarifying = these requirements apply to the use cases discussed in the = document.

 

"

   o  an = expiration time (i.e., the time at which the content = files

      should be expunged from all = CDN storage).

"

I understand this is = saying that CDNI metadata need to include this expiration time = (triggering cache removal) , in addition to deactivation time. =

I don't think this is = discussed in cdni-requirements yet. Can you bring that up on the list = with the cdni-reqts authors?

 

"

   The = delivery of content may be further influenced by policies = which

   may include = quality of service rules that specify:

   o  the maximum resolution deliverable to = specific devices,

   o  the = maximum resolution deliverable though a specific NSP, = or

   o  the = maximum resolution deliverable to users based on = their

      subscription = levels.

"

I don't think this is = covered in the cdni-requirements doc.

It = is not obvious to me that absolutely all of those ought to be in phase = 1. The first bullet only makes sense if the solution supports = transcoding/transrating, which I don't know if it will be supported in = Initial scope.

The last bullet does not = make sense to me as we don;t want the CDNs to be aware of any user = subscription levels (ie only CSP is aware of user subscription = level).

 

We have collected the requirements-like use cases in a new = section about "Content Availability", and we are working on it = to take all the received comments into account.

 

 

*** 3.1.  Overload = Handling and Dimensioning "

This brings dimensioning savings to the CDNs as they can = use the resources

   of each = other during their peaks of activity.

"

s/their peaks of = activity./ their respective peaks of activity./

 

Done

 

*** 3.3.  Branding = Consideration

Again, this seems more = of a requirement than a use case per-say. I recommend you make that = clear upfront in teh section (ie this is not an extra use cases, but a = requirement applying to use-cases discussed = before).

Also, is there a reason = this applicable to only the use cases in section 3 and not section = 2?

Anotehr option may be to = move 2.4 and 3.3 under a separate heading somewhere collecting key = requirements applicable to the many use cases.

 

We are working to improve this = section.

 

*** 4.1.  Device = and Network Technology Extension Again I think some of the discussion = assumes that there is some conversion of quality done inside the CDNs = (as opposed to different terminal requesting different = URIs).

I think we need to = discuss whether this is going to come in Initial Scope or = not.

 

This section presents a quite general use case in which a = CDN1 delegates requests to another CDN2 that offers any function that = CDN1 is not able to provide. It does not assume that quality conversion = is done in the CDN, although this one of the possible examples for this = use case.

 

*** in Figure 2: =

s/CDN Provider A/CDN = Provider 1/

 

We have removed this figure

 

*** co-authors. You have = a long list of co-authors. As per current practice, you would want to = split that into "editors" and = "contributors".

 

We need to discuss this point with the = co-authors.

=3D=3D=3D=3D=3D=3D=3D=3D<= o:p>

 

 

Best regards,

 

Gilles

 

-----Message = d'origine-----
De : Francois Le Faucheur = [mailto:flefauch@cisco.com]
Envoy=E9 : mardi 26 juillet 2011 = 22:54
=C0 : = draft-bertrand-cdni-use-cases@tools.ietf.org
Cc : Le Faucheur = Francois; cdni@ietf.org
Objet : comments on = draft-bertrand-cdni-use-cases-02

 

Hello,

 

Please find my review comments = below.

Cheers

 

Francois

 

*** Abstract & Introduction:

"

It provides the business = motivations for CDNI Working Group, which can be used = to

   validate different interconnection = arrangements, and requirements of the various CDNI = interfaces.

"

Now the WG is formed you may want to adjust into something = like:

"

It can be used to provide guidance to the CDNI WG about the = interconnection arrangements to be supported and to validate the = requirements of the various CDNI = interfaces."

 

 

*** Introduction:

"

This document now merges input = from [I-D.watson-cdni-use-cases] and

   = [I-D.ma-cdni-publisher-use-cases].

"

I suggest you remove this = historical info in new revs, as the document gradually matures towards = WG material.

 

 

*** Introduction:

"

There are many possible = combinations for the relationships between

   the different = parties (Network Service Provider (NSP), CDN = Provider,

   Content Service Provider (CSP) and End User) = involved in end-to-end

   content = delivery.  However, in the context of interconnecting = CDNs

   the key relationships are listed = below.

   o  How the CSP interacts with the CDN = provider, so that the CDN

      = delivers content in a manner compliant with CSP's = distribution

      = policies.

   o  How the End User interacts with the = CSP and one or more CDNs to

      = request and receive content.

   o  How the = different CDN providers, operating their CDNs, = interact

      with one another to deliver = the CSP's content to the End User

      = while continuing to enforce the CSP's distribution = policies.

"

I don't quite see the relevance of this text in the = use-case document, or what point it is trying to bring = across.

In particular, it is a little confusing sine it talks about = interfaces that are out of scope for CDNI without saying = so.

 

 

*** 1.1 Terminology

o I expect that terminology = across problem-statement, requirements and use-case needs to be aligned = and made probably moved into one document and referred by all the = others.

o "CDN Peering": I am not sure we need that term. =

o = "Recursive request routing/ Recursive request routing": see = discussion on the list about moving those terms in a single doc =

 

 

*** 1.3 High Level Use Cases for Multi-CDN Systems I found = it a little confusing to have the word "use cases" used here = in the introduction as well as later in teh individual = use-cases.

How about something like "Rationale or Multi-CDN = Systems"?

 

 

*** 1.3 High Level Use Cases for Multi-CDN Systems = "

CSP-1 benefits because it only needs to make one business = agreement

   and one physical connection, with CDN Provider = A, but its End Users

   get a service quality as though it had also = gone to the trouble of

   making a business = agreement with CDN Provider B.

"

s/as though it had /as though = CSP-1 had /

 

 

*** 1.4.  The Need for CDNI = Standards

"

   Existing CDN interfaces are proprietary and an = external CDN typically

   cannot use them, = especially if the two CDNs rely on different

   solutions. =

"

It is difficult to use existing interfaces because they are = proprietary, but also because they have often been designed as = intra-CDN/intra-domain interfaces, so they don't have all the right = attributes.

Also, I think by "solutions" you mean = "implementations".

So = perhaps:

"

   Existing CDN interfaces are proprietary and = have often been design for intra-CDN/intra-domain operations. So an = external CDN typically cannot use them, especially if the two CDNs rely = on different implementations.

"

 

"

Nevertheless, = [I-D.bertrand-cdni-experiments] shows that

   some level of CDN = interconnection can be achieved experimentally

   without = standardized interfaces between the CDNs.  The methods = used

   in these experiments are hardly usable in an = operational context,

   because they suffer from several limitations = in terms of

   functionalities, scalability, and security = level.

"

s/ The methods used/However, the methods = used/

 

 

"

   The aim of the CDNI standards work is = therefore to overcome such

   shortcomings; a = full list of requirements is being developed in

   = [I-D.lefaucheur-cdni-requirements].

"

s/the CDNI standards work/IETF = CDNI WG solution/

 

 

***2.1.  Geographic Extension

"

   In this use case, = the CDN Provider wants to extend the geographic

   distribution that = it can offer CSPs, without

 

   o  = compromising the quality of delivery

 

   o  attracting = transit and other network costs by serving from

      = geographically or topologically remote = surrogates.

"

I think would read better as:

"

   In this use case, = the CDN Provider wants to extend the geographic

   distribution that = it can offer to its CSPs:

 

   o  without = compromising the quality of delivery

 

   o  without = incurring additional transit and other network costs that would result = from serving content from

      = geographically or topologically remote = surrogates.

"

 

"

As an example, suppose a French CSP wants to distribute its = TV

   programs to End Users located in various = countries in Europe and

   North Africa.  = It asks a French CDN Provider to deliver the = content.

   The French CDN Provider's network only covers = France, so it makes an

   agreement with = another CDN Provider that covers North Africa.

   Overall, from the = CSP's perspective the French CDN Provider = provides

   a CDN service for both France and North = Africa.

"

The example initially mentions a required coverage of = Europe+ North Africa, but then seem to descrive a solution for a = coverage of France+North Africa.

 

 

*** 2.2.  Region to Region = Interconnection I don't find the phrase "Region to Region" = very distinctive versus the previous "Geographic = Extension".

I think the key differences here is that the different CDNs = are operated by different organization that are affiliates of the same = company.

So how about "Inter-Affiliates = Interconnection"?

 

 

*** 2.3.  Nomadic = Users

You may want to mention that this is often loosely referred = to as "TV everywhere".

 

"

The motivation in this case is = to allow nomadic users to maintain access,

   rather than to = allow all residents within a region access to = the

   content.

"

s/to maintain access/to maintain = access with consistent quality of experience/

 

You may want to expand a little = on which CDNs need to be interconnected to address the use case (ie with = CDN of "home NSP" interconnected to CDN of visited NSP) = possibly with a picture.

 

 

*** 2.4.  Delivery = Restrictions

"Hence, the exchange through the CDN interconnection = of information

   for controlling the footprint of the delivery = is an important use

   case.

"

To me this is not an additional = use cases, this is a requirement that has to be met in the use cases = described earlier. In fact, the document mixes use cases and = requirements in a few places.

I would suggest that = :

      * you refer to  things = discussed in that section as = "requirements"

      * = add a statement clarifying these requirements apply to the use cases = discussed in the document.

 

"

   o  an = expiration time (i.e., the time at which the content = files

      should be expunged from all = CDN storage).

"

I understand this is saying that CDNI metadata need to = include this expiration time (triggering cache removal) , in addition to = deactivation time.

I don't think this is discussed in cdni-requirements yet. = Can you bring that up on the list with the cdni-reqts = authors?

 

"

   The delivery of content may be further = influenced by policies which

   may include quality = of service rules that specify:

   o  the maximum = resolution deliverable to specific devices,

   o  the maximum = resolution deliverable though a specific NSP, or

   o  the maximum = resolution deliverable to users based on their

      = subscription levels.

"

I don't think this is covered in the cdni-requirements doc. =

It is = not obvious to me that absolutely all of those ought to be in phase 1. = The first bullet only makes sense if the solution supports = transcoding/transrating, which I don't know if it will be supported in = Initial scope.

The last bullet does not make sense to me as we don;t want = the CDNs to be aware of any user subscription levels (ie only CSP is = aware of user subscription level).

 

 

*** 3.1.  Overload Handling = and Dimensioning "

This brings dimensioning savings = to the CDNs as they can use the resources

   of each other = during their peaks of activity.

"

s/their peaks of activity./ = their respective peaks of activity./

 

 

*** 3.3.  Branding = Consideration

Again, this seems more of a requirement than a use case = per-say. I recommend you make that clear upfront in teh section (ie this = is not an extra use cases, but a requirement applying to use-cases = discussed before).

Also, is there a reason this applicable to only the use = cases in section 3 and not section 2?

Anotehr option may be to move = 2.4 and 3.3 under a separate heading somewhere collecting key = requirements applicable to the many use cases.

 

 

*** 4.1.  Device and = Network Technology Extension Again I think some of the discussion = assumes that there is some conversion of quality done inside the CDNs = (as opposed to different terminal requesting different = URIs).

I = think we need to discuss whether this is going to come in Initial Scope = or not.

 

 

 

*** in Figure 2:

s/CDN Provider A/CDN Provider = 1/

 

 

 

*** co-authors. You have a long list of co-authors. As per = current practice, you would want to split that into "editors" = and "contributors".

 

------_=_NextPart_001_01CC671E.CB991D11-- From flefauch@cisco.com Tue Aug 30 10:39:32 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC06421F8D18 for ; Tue, 30 Aug 2011 10:39:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZSxA02ENpWUK for ; Tue, 30 Aug 2011 10:39:29 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id B633D21F8CF1 for ; Tue, 30 Aug 2011 10:39:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=131105; q=dns/txt; s=iport; t=1314726054; x=1315935654; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=DPwzLVSWBDY0pArr1cuFYNMn/mCqFjPgtwRGxuRkbrY=; b=Nfbp31HCQ488skyeFQFXJQXeZozmOFIlm14JrOs6B8Z+bSWsyvvtCEOq Lbx5ACAxyIbJxRED2tOEwisS14W4fDfBbrwXdKuJVayPiuyXsS4cd4Dan AbmbW9mUBcqoV7kdi9WC7a/uLYH2xvxLDMrZF0RuskYhQ++S5wiLhjf3r Q=; X-IronPort-AV: E=Sophos;i="4.68,303,1312156800"; d="scan'208,217";a="52599407" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 30 Aug 2011 17:40:53 +0000 Received: from ams-flefauch-8714.cisco.com (ams-flefauch-8714.cisco.com [10.55.161.197]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p7UHem0D031256; Tue, 30 Aug 2011 17:40:48 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-504--736043844 From: Francois Le Faucheur In-Reply-To: <8E09C72DBC577D489F13A71228C0B7BF029D2521@ftrdmel0.rd.francetelecom.fr> Date: Tue, 30 Aug 2011 19:41:28 +0200 Message-Id: <316876FB-B492-4CC2-9FBA-D304DBE920E0@cisco.com> References: <1AC8E92C-3A69-4C80-A235-710DEF396A53@cisco.com> <8E09C72DBC577D489F13A71228C0B7BF029D2521@ftrdmel0.rd.francetelecom.fr> To: "" X-Mailer: Apple Mail (2.1084) Cc: cdni@ietf.org, draft-bertrand-cdni-use-cases@tools.ietf.org Subject: Re: [CDNi] comments on draft-bertrand-cdni-use-cases-02 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 17:39:32 -0000 --Apple-Mail-504--736043844 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Gilles and co-authors, Thanks for factoring all my earlier comments. Looking forward to the new = version. Francois On 30 Aug 2011, at 16:11, = wrote: > Hi Fran=E7ois, > =20 > Thanks for your review. > =20 > =3D=3D=3D=3D=3D=3D=3D=3D > =20 > *** Abstract & Introduction: > " > It provides the business motivations for CDNI Working Group, which can = be used to > validate different interconnection arrangements, and requirements = of the various CDNI interfaces. > " > Now the WG is formed you may want to adjust into something like: > " > It can be used to provide guidance to the CDNI WG about the = interconnection arrangements to be supported and to validate the = requirements of the various CDNI interfaces." > =20 > Done > =20 > *** Introduction: > " > This document now merges input from [I-D.watson-cdni-use-cases] and > [I-D.ma-cdni-publisher-use-cases]. > " > I suggest you remove this historical info in new revs, as the document = gradually matures towards WG material. > =20 > Done > =20 > *** Introduction: > " > There are many possible combinations for the relationships between > the different parties (Network Service Provider (NSP), CDN = Provider, > Content Service Provider (CSP) and End User) involved in end-to-end > content delivery. However, in the context of interconnecting CDNs > the key relationships are listed below. > o How the CSP interacts with the CDN provider, so that the CDN > delivers content in a manner compliant with CSP's distribution > policies. > o How the End User interacts with the CSP and one or more CDNs to > request and receive content. > o How the different CDN providers, operating their CDNs, interact > with one another to deliver the CSP's content to the End User > while continuing to enforce the CSP's distribution policies. > " > I don't quite see the relevance of this text in the use-case document, = or what point it is trying to bring across. > In particular, it is a little confusing sine it talks about interfaces = that are out of scope for CDNI without saying so. > =20 > Text removed > =20 > =20 > *** 1.1 Terminology > o I expect that terminology across problem-statement, requirements and = use-case needs to be aligned and made probably moved into one document = and referred by all the others. > o "CDN Peering": I am not sure we need that term. > o "Recursive request routing/ Recursive request routing": see = discussion on the list about moving those terms in a single doc > =20 > We are progressing on the cleaning of this section, keeping in mind = that all the definitions will be moved later to a unique draft. > =20 > =20 > *** 1.3 High Level Use Cases for Multi-CDN Systems I found it a little = confusing to have the word "use cases" used here in the introduction as = well as later in teh individual use-cases. > How about something like "Rationale or Multi-CDN Systems"? > =20 > Done > =20 > *** 1.3 High Level Use Cases for Multi-CDN Systems " > CSP-1 benefits because it only needs to make one business agreement > and one physical connection, with CDN Provider A, but its End Users > get a service quality as though it had also gone to the trouble of > making a business agreement with CDN Provider B. > " > s/as though it had /as though CSP-1 had / > =20 > Done > =20 > *** 1.4. The Need for CDNI Standards > " > Existing CDN interfaces are proprietary and an external CDN = typically > cannot use them, especially if the two CDNs rely on different > solutions. > " > It is difficult to use existing interfaces because they are = proprietary, but also because they have often been designed as = intra-CDN/intra-domain interfaces, so they don't have all the right = attributes. > Also, I think by "solutions" you mean "implementations". > So perhaps: > " > Existing CDN interfaces are proprietary and have often been = designed for intra-CDN/intra-domain operations. So an external CDN = typically cannot use them, especially if the two CDNs rely on different = implementations. > " > =20 > Done > =20 > " > Nevertheless, [I-D.bertrand-cdni-experiments] shows that > some level of CDN interconnection can be achieved experimentally > without standardized interfaces between the CDNs. The methods used > in these experiments are hardly usable in an operational context, > because they suffer from several limitations in terms of > functionalities, scalability, and security level. > " > s/ The methods used/However, the methods used/ > =20 > Done > =20 > " > The aim of the CDNI standards work is therefore to overcome such > shortcomings; a full list of requirements is being developed in > [I-D.lefaucheur-cdni-requirements]. > " > s/the CDNI standards work/IETF CDNI WG solution/ > =20 > Done > =20 > ***2.1. Geographic Extension > " > In this use case, the CDN Provider wants to extend the geographic > distribution that it can offer CSPs, without > =20 > o compromising the quality of delivery > =20 > o attracting transit and other network costs by serving from > geographically or topologically remote surrogates. > " > I think would read better as: > " > In this use case, the CDN Provider wants to extend the geographic > distribution that it can offer to its CSPs: > =20 > o without compromising the quality of delivery > =20 > o without incurring additional transit and other network costs = that would result from serving content from > geographically or topologically remote surrogates. > " > =20 > Done > =20 > " > As an example, suppose a French CSP wants to distribute its TV > programs to End Users located in various countries in Europe and > North Africa. It asks a French CDN Provider to deliver the = content. > The French CDN Provider's network only covers France, so it makes = an > agreement with another CDN Provider that covers North Africa. > Overall, from the CSP's perspective the French CDN Provider = provides > a CDN service for both France and North Africa. > " > The example initially mentions a required coverage of Europe+ North = Africa, but then seem to descrive a solution for a coverage of = France+North Africa. > =20 > Corrected > =20 > *** 2.2. Region to Region Interconnection I don't find the phrase = "Region to Region" very distinctive versus the previous "Geographic = Extension". > I think the key differences here is that the different CDNs are = operated by different organization that are affiliates of the same = company. > So how about "Inter-Affiliates Interconnection"? > =20 > Done > =20 > *** 2.3. Nomadic Users > You may want to mention that this is often loosely referred to as "TV = everywhere". > =20 > In progress. > =20 > " > The motivation in this case is to allow nomadic users to maintain = access, > rather than to allow all residents within a region access to the > content. > " > s/to maintain access/to maintain access with consistent quality of = experience/ > Done > =20 > You may want to expand a little on which CDNs need to be = interconnected to address the use case (ie with CDN of "home NSP" = interconnected to CDN of visited NSP) possibly with a picture. > =20 > In progress. > =20 > =20 > *** 2.4. Delivery Restrictions > "Hence, the exchange through the CDN interconnection of information > for controlling the footprint of the delivery is an important use > case. > " > To me this is not an additional use cases, this is a requirement that = has to be met in the use cases described earlier. In fact, the document = mixes use cases and requirements in a few places. > I would suggest that : > * you refer to things discussed in that section as = "requirements" > * add a statement clarifying these requirements apply to the use = cases discussed in the document. > =20 > " > o an expiration time (i.e., the time at which the content files > should be expunged from all CDN storage). > " > I understand this is saying that CDNI metadata need to include this = expiration time (triggering cache removal) , in addition to deactivation = time. > I don't think this is discussed in cdni-requirements yet. Can you = bring that up on the list with the cdni-reqts authors? > =20 > " > The delivery of content may be further influenced by policies which > may include quality of service rules that specify: > o the maximum resolution deliverable to specific devices, > o the maximum resolution deliverable though a specific NSP, or > o the maximum resolution deliverable to users based on their > subscription levels. > " > I don't think this is covered in the cdni-requirements doc. > It is not obvious to me that absolutely all of those ought to be in = phase 1. The first bullet only makes sense if the solution supports = transcoding/transrating, which I don't know if it will be supported in = Initial scope. > The last bullet does not make sense to me as we don;t want the CDNs to = be aware of any user subscription levels (ie only CSP is aware of user = subscription level). > =20 > We have collected the requirements-like use cases in a new section = about "Content Availability", and we are working on it to take all the = received comments into account. > =20 > =20 > *** 3.1. Overload Handling and Dimensioning " > This brings dimensioning savings to the CDNs as they can use the = resources > of each other during their peaks of activity. > " > s/their peaks of activity./ their respective peaks of activity./ > =20 > Done > =20 > *** 3.3. Branding Consideration > Again, this seems more of a requirement than a use case per-say. I = recommend you make that clear upfront in teh section (ie this is not an = extra use cases, but a requirement applying to use-cases discussed = before). > Also, is there a reason this applicable to only the use cases in = section 3 and not section 2? > Anotehr option may be to move 2.4 and 3.3 under a separate heading = somewhere collecting key requirements applicable to the many use cases. > =20 > We are working to improve this section. > =20 > *** 4.1. Device and Network Technology Extension Again I think some = of the discussion assumes that there is some conversion of quality done = inside the CDNs (as opposed to different terminal requesting different = URIs). > I think we need to discuss whether this is going to come in Initial = Scope or not. > =20 > This section presents a quite general use case in which a CDN1 = delegates requests to another CDN2 that offers any function that CDN1 is = not able to provide. It does not assume that quality conversion is done = in the CDN, although this one of the possible examples for this use = case. > =20 > *** in Figure 2: > s/CDN Provider A/CDN Provider 1/ > =20 > We have removed this figure > =20 > *** co-authors. You have a long list of co-authors. As per current = practice, you would want to split that into "editors" and = "contributors". > =20 > We need to discuss this point with the co-authors. > =3D=3D=3D=3D=3D=3D=3D=3D > =20 > =20 > Best regards, > =20 > Gilles > =20 > -----Message d'origine----- > De : Francois Le Faucheur [mailto:flefauch@cisco.com]=20 > Envoy=E9 : mardi 26 juillet 2011 22:54 > =C0 : draft-bertrand-cdni-use-cases@tools.ietf.org > Cc : Le Faucheur Francois; cdni@ietf.org > Objet : comments on draft-bertrand-cdni-use-cases-02 > =20 > Hello, > =20 > Please find my review comments below. > Cheers > =20 > Francois > =20 > *** Abstract & Introduction: > " > It provides the business motivations for CDNI Working Group, which can = be used to > validate different interconnection arrangements, and requirements = of the various CDNI interfaces. > " > Now the WG is formed you may want to adjust into something like: > " > It can be used to provide guidance to the CDNI WG about the = interconnection arrangements to be supported and to validate the = requirements of the various CDNI interfaces." > =20 > =20 > *** Introduction: > " > This document now merges input from [I-D.watson-cdni-use-cases] and > [I-D.ma-cdni-publisher-use-cases]. > " > I suggest you remove this historical info in new revs, as the document = gradually matures towards WG material. > =20 > =20 > *** Introduction: > " > There are many possible combinations for the relationships between > the different parties (Network Service Provider (NSP), CDN = Provider, > Content Service Provider (CSP) and End User) involved in end-to-end > content delivery. However, in the context of interconnecting CDNs > the key relationships are listed below. > o How the CSP interacts with the CDN provider, so that the CDN > delivers content in a manner compliant with CSP's distribution > policies. > o How the End User interacts with the CSP and one or more CDNs to > request and receive content. > o How the different CDN providers, operating their CDNs, interact > with one another to deliver the CSP's content to the End User > while continuing to enforce the CSP's distribution policies. > " > I don't quite see the relevance of this text in the use-case document, = or what point it is trying to bring across. > In particular, it is a little confusing sine it talks about interfaces = that are out of scope for CDNI without saying so. > =20 > =20 > *** 1.1 Terminology > o I expect that terminology across problem-statement, requirements and = use-case needs to be aligned and made probably moved into one document = and referred by all the others. > o "CDN Peering": I am not sure we need that term. > o "Recursive request routing/ Recursive request routing": see = discussion on the list about moving those terms in a single doc > =20 > =20 > *** 1.3 High Level Use Cases for Multi-CDN Systems I found it a little = confusing to have the word "use cases" used here in the introduction as = well as later in teh individual use-cases. > How about something like "Rationale or Multi-CDN Systems"? > =20 > =20 > *** 1.3 High Level Use Cases for Multi-CDN Systems " > CSP-1 benefits because it only needs to make one business agreement > and one physical connection, with CDN Provider A, but its End Users > get a service quality as though it had also gone to the trouble of > making a business agreement with CDN Provider B. > " > s/as though it had /as though CSP-1 had / > =20 > =20 > *** 1.4. The Need for CDNI Standards > " > Existing CDN interfaces are proprietary and an external CDN = typically > cannot use them, especially if the two CDNs rely on different > solutions. > " > It is difficult to use existing interfaces because they are = proprietary, but also because they have often been designed as = intra-CDN/intra-domain interfaces, so they don't have all the right = attributes. > Also, I think by "solutions" you mean "implementations". > So perhaps: > " > Existing CDN interfaces are proprietary and have often been design = for intra-CDN/intra-domain operations. So an external CDN typically = cannot use them, especially if the two CDNs rely on different = implementations. > " > =20 > " > Nevertheless, [I-D.bertrand-cdni-experiments] shows that > some level of CDN interconnection can be achieved experimentally > without standardized interfaces between the CDNs. The methods used > in these experiments are hardly usable in an operational context, > because they suffer from several limitations in terms of > functionalities, scalability, and security level. > " > s/ The methods used/However, the methods used/ > =20 > =20 > " > The aim of the CDNI standards work is therefore to overcome such > shortcomings; a full list of requirements is being developed in > [I-D.lefaucheur-cdni-requirements]. > " > s/the CDNI standards work/IETF CDNI WG solution/ > =20 > =20 > ***2.1. Geographic Extension > " > In this use case, the CDN Provider wants to extend the geographic > distribution that it can offer CSPs, without > =20 > o compromising the quality of delivery > =20 > o attracting transit and other network costs by serving from > geographically or topologically remote surrogates. > " > I think would read better as: > " > In this use case, the CDN Provider wants to extend the geographic > distribution that it can offer to its CSPs: > =20 > o without compromising the quality of delivery > =20 > o without incurring additional transit and other network costs = that would result from serving content from > geographically or topologically remote surrogates. > " > =20 > " > As an example, suppose a French CSP wants to distribute its TV > programs to End Users located in various countries in Europe and > North Africa. It asks a French CDN Provider to deliver the = content. > The French CDN Provider's network only covers France, so it makes = an > agreement with another CDN Provider that covers North Africa. > Overall, from the CSP's perspective the French CDN Provider = provides > a CDN service for both France and North Africa. > " > The example initially mentions a required coverage of Europe+ North = Africa, but then seem to descrive a solution for a coverage of = France+North Africa. > =20 > =20 > *** 2.2. Region to Region Interconnection I don't find the phrase = "Region to Region" very distinctive versus the previous "Geographic = Extension". > I think the key differences here is that the different CDNs are = operated by different organization that are affiliates of the same = company. > So how about "Inter-Affiliates Interconnection"? > =20 > =20 > *** 2.3. Nomadic Users > You may want to mention that this is often loosely referred to as "TV = everywhere". > =20 > " > The motivation in this case is to allow nomadic users to maintain = access, > rather than to allow all residents within a region access to the > content. > " > s/to maintain access/to maintain access with consistent quality of = experience/ > =20 > You may want to expand a little on which CDNs need to be = interconnected to address the use case (ie with CDN of "home NSP" = interconnected to CDN of visited NSP) possibly with a picture. > =20 > =20 > *** 2.4. Delivery Restrictions > "Hence, the exchange through the CDN interconnection of information > for controlling the footprint of the delivery is an important use > case. > " > To me this is not an additional use cases, this is a requirement that = has to be met in the use cases described earlier. In fact, the document = mixes use cases and requirements in a few places. > I would suggest that : > * you refer to things discussed in that section as = "requirements" > * add a statement clarifying these requirements apply to the use = cases discussed in the document. > =20 > " > o an expiration time (i.e., the time at which the content files > should be expunged from all CDN storage). > " > I understand this is saying that CDNI metadata need to include this = expiration time (triggering cache removal) , in addition to deactivation = time. > I don't think this is discussed in cdni-requirements yet. Can you = bring that up on the list with the cdni-reqts authors? > =20 > " > The delivery of content may be further influenced by policies which > may include quality of service rules that specify: > o the maximum resolution deliverable to specific devices, > o the maximum resolution deliverable though a specific NSP, or > o the maximum resolution deliverable to users based on their > subscription levels. > " > I don't think this is covered in the cdni-requirements doc. > It is not obvious to me that absolutely all of those ought to be in = phase 1. The first bullet only makes sense if the solution supports = transcoding/transrating, which I don't know if it will be supported in = Initial scope. > The last bullet does not make sense to me as we don;t want the CDNs to = be aware of any user subscription levels (ie only CSP is aware of user = subscription level). > =20 > =20 > *** 3.1. Overload Handling and Dimensioning " > This brings dimensioning savings to the CDNs as they can use the = resources > of each other during their peaks of activity. > " > s/their peaks of activity./ their respective peaks of activity./ > =20 > =20 > *** 3.3. Branding Consideration > Again, this seems more of a requirement than a use case per-say. I = recommend you make that clear upfront in teh section (ie this is not an = extra use cases, but a requirement applying to use-cases discussed = before). > Also, is there a reason this applicable to only the use cases in = section 3 and not section 2? > Anotehr option may be to move 2.4 and 3.3 under a separate heading = somewhere collecting key requirements applicable to the many use cases. > =20 > =20 > *** 4.1. Device and Network Technology Extension Again I think some = of the discussion assumes that there is some conversion of quality done = inside the CDNs (as opposed to different terminal requesting different = URIs). > I think we need to discuss whether this is going to come in Initial = Scope or not. > =20 > =20 > =20 > *** in Figure 2: > s/CDN Provider A/CDN Provider 1/ > =20 > =20 > =20 > *** co-authors. You have a long list of co-authors. As per current = practice, you would want to split that into "editors" and = "contributors". > =20 --Apple-Mail-504--736043844 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Hi Gilles and co-authors,
Thanks for = factoring all my earlier comments. Looking forward to the new = version.
Francois


Hi = Fran=E7ois,
 
Thanks = for your review.
 
 
*** Abstract & = Introduction:
"
It = provides the business motivations for CDNI Working Group, which can be = used to
   validate different interconnection = arrangements, and requirements of the various CDNI = interfaces.
"
Now the = WG is formed you may want to adjust into something = like:
"
It can = be used to provide guidance to the CDNI WG about the interconnection = arrangements to be supported and to validate the requirements of the = various CDNI interfaces."
 
Done
 
*** = Introduction:
"
This = document now merges input from [I-D.watson-cdni-use-cases] = and
   = [I-D.ma-cdni-publisher-use-cases].
"
I = suggest you remove this historical info in new revs, as the document = gradually matures towards WG material.
 
Done
 
*** Introduction:
"
There = are many possible combinations for the relationships = between
   the different parties (Network Service = Provider (NSP), CDN Provider,
   Content Service Provider (CSP) and = End User) involved in end-to-end
   content delivery.  However, in = the context of interconnecting CDNs
   the key relationships are listed = below.
   o  How the CSP interacts with the CDN = provider, so that the CDN
      delivers content in a = manner compliant with CSP's distribution
      = policies.
   o  How the End User interacts with the = CSP and one or more CDNs to
      request and = receive content.
   o  How the different CDN providers, = operating their CDNs, interact
      with one another = to deliver the CSP's content to the End User
      while continuing = to enforce the CSP's distribution policies.
"
I don't = quite see the relevance of this text in the use-case document, or what = point it is trying to bring across.
In particular, it is a little confusing sine it = talks about interfaces that are out of scope for CDNI without saying = so.
 
Text = removed
 
 
*** 1.1 = Terminology
o I = expect that terminology across problem-statement, requirements and = use-case needs to be aligned and made probably moved into one document = and referred by all the others.
o "CDN Peering": I am not sure we need that = term.
o = "Recursive request routing/ Recursive request routing": see discussion = on the list about moving those terms in a single = doc
 
We are = progressing on the cleaning of this section, keeping in mind that all = the definitions will be moved later to a unique = draft.
 
 
*** 1.3 = High Level Use Cases for Multi-CDN Systems I found it a little confusing = to have the word "use cases" used here in the introduction as well as = later in teh individual use-cases.
How about something like "Rationale or Multi-CDN = Systems"?
 
Done
 
*** 1.3 = High Level Use Cases for Multi-CDN Systems "
CSP-1 benefits because it only needs to make one = business agreement
   and one physical connection, with CDN = Provider A, but its End Users
   get a service quality as though it = had also gone to the trouble of
   making a business agreement with CDN = Provider B.
"
s/as = though it had /as though CSP-1 had /
 
Done
 
*** 1.4.  The Need for CDNI = Standards
"
   Existing CDN interfaces are proprietary and = an external CDN typically
   cannot use them, especially if the two CDNs = rely on different
   solutions.
"
It is = difficult to use existing interfaces because they are proprietary, but = also because they have often been designed as intra-CDN/intra-domain = interfaces, so they don't have all the right = attributes.
Also, I = think by "solutions" you mean = "implementations".
So = perhaps:
"
   Existing CDN interfaces are proprietary and = have often been designed for intra-CDN/intra-domain operations. So an = external CDN typically cannot use them, especially if the two CDNs rely = on different implementations.
"
 
Done
 
"
Nevertheless, [I-D.bertrand-cdni-experiments] shows = that
   some level of = CDN interconnection can be achieved = experimentally
   without standardized interfaces between the = CDNs.  The methods used
   in these experiments are hardly = usable in an operational context,
   because they suffer from several = limitations in terms of
   functionalities, scalability, and security = level.
"
s/ The = methods used/However, the methods used/
 
Done
 
"
   The aim of the CDNI standards work is = therefore to overcome such
   shortcomings; a full list of = requirements is being developed in
   = [I-D.lefaucheur-cdni-requirements].
"
s/the = CDNI standards work/IETF CDNI WG solution/
 
Done
 
***2.1.  Geographic = Extension
"
   In this use case, the CDN Provider wants to = extend the geographic
   distribution that it can offer CSPs, = without
 
   o  compromising the quality of = delivery
 
   o  attracting transit and other network = costs by serving from
      geographically or = topologically remote surrogates.
"
I think = would read better as:
"
   In this use case, the CDN Provider wants to = extend the geographic
   distribution that it can offer to its = CSPs:
 
   o  without compromising the quality of = delivery
 
   o  without incurring additional transit = and other network costs that would result from serving content = from
      geographically or = topologically remote surrogates.
"
 
Done
 
"
As an = example, suppose a French CSP wants to distribute its = TV
   programs to = End Users located in various countries in Europe = and
   North = Africa.  It asks a French CDN Provider to deliver the = content.
   The French CDN Provider's network only = covers France, so it makes an
   agreement with another CDN Provider = that covers North Africa.
   Overall, from the CSP's perspective the = French CDN Provider provides
   a CDN service for both France and = North Africa.
"
The = example initially mentions a required coverage of Europe+ North Africa, = but then seem to descrive a solution for a coverage of France+North = Africa.
 
Corrected
 
*** = 2.2.  Region to Region Interconnection I don't find the phrase = "Region to Region" very distinctive versus the previous "Geographic = Extension".
I think = the key differences here is that the different CDNs are operated by = different organization that are affiliates of the same = company.
So how = about "Inter-Affiliates Interconnection"?
 
Done
 
*** 2.3.  Nomadic = Users
You may = want to mention that this is often loosely referred to as "TV = everywhere".
 
In = progress.
 
"
The = motivation in this case is to allow nomadic users to maintain = access,
   rather than to allow all residents within a = region access to the
   content.
"
s/to = maintain access/to maintain access with consistent quality of = experience/
Done
 
You may = want to expand a little on which CDNs need to be interconnected to = address the use case (ie with CDN of "home NSP" interconnected to CDN of = visited NSP) possibly with a picture.
 
In progress.
 
 
*** 2.4.  Delivery = Restrictions
"Hence, = the exchange through the CDN interconnection of = information
   for controlling the footprint of the = delivery is an important use
   case.
"
To me = this is not an additional use cases, this is a requirement that has to = be met in the use cases described earlier. In fact, the document mixes = use cases and requirements in a few places.
I would suggest that = :
      * you refer to  = things discussed in that section as = "requirements"
      * add a statement = clarifying these requirements apply to the use cases discussed in the = document.
 
"
   o  an expiration time (i.e., the time = at which the content files
      should be expunged = from all CDN storage).
"
I = understand this is saying that CDNI metadata need to include this = expiration time (triggering cache removal) , in addition to deactivation = time.
I don't = think this is discussed in cdni-requirements yet. Can you bring that up = on the list with the cdni-reqts authors?
 
"
   The delivery of content may be further = influenced by policies which
   may include quality of service rules = that specify:
   o  the maximum resolution deliverable = to specific devices,
   o  the maximum resolution deliverable = though a specific NSP, or
  =  o  the maximum resolution deliverable to users based on = their
      subscription = levels.
"
I don't = think this is covered in the cdni-requirements = doc.
It is not obvious to me = that absolutely all of those ought to be in phase 1. The first bullet = only makes sense if the solution supports transcoding/transrating, which = I don't know if it will be supported in Initial = scope.
The = last bullet does not make sense to me as we don;t want the CDNs to be = aware of any user subscription levels (ie only CSP is aware of user = subscription level).
 
We have = collected the requirements-like use cases in a new section about = "Content Availability", and we are working on it to take all the = received comments into account.
 
 
*** 3.1.  Overload Handling and Dimensioning = "
This brings dimensioning = savings to the CDNs as they can use the = resources
   of each other during their peaks of = activity.
"
s/their = peaks of activity./ their respective peaks of = activity./
 
Done
 
*** = 3.3.  Branding Consideration
Again, this seems more of a requirement than a = use case per-say. I recommend you make that clear upfront in teh section = (ie this is not an extra use cases, but a requirement applying to = use-cases discussed before).
Also, is there a reason this applicable to only = the use cases in section 3 and not section = 2?
Anotehr option may be to = move 2.4 and 3.3 under a separate heading somewhere collecting key = requirements applicable to the many use = cases.
 
We are = working to improve this section.
 
*** 4.1.  Device and Network Technology = Extension Again I think some of the discussion assumes that there is = some conversion of quality done inside the CDNs (as opposed to different = terminal requesting different URIs).
I think we need to discuss whether this is going = to come in Initial Scope or not.
 
This section presents a quite general use case in = which a CDN1 delegates requests to another CDN2 that offers any function = that CDN1 is not able to provide. It does not assume that quality = conversion is done in the CDN, although this one of the possible = examples for this use case.
 
*** in Figure 2:
s/CDN Provider A/CDN Provider = 1/
 
We have = removed this figure
 
*** = co-authors. You have a long list of co-authors. As per current practice, = you would want to split that into "editors" and = "contributors".
 
We need = to discuss this point with the co-authors.
=3D=3D=3D=3D=3D=3D=3D=3D
<= div style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; = margin-bottom: 0.0001pt; font-size: 10.5pt; font-family: Consolas; = "> 
 
Best regards,
 
Gilles
 
-----Message d'origine-----
De : Francois = Le Faucheur [mailto:flefauch@cisco.com] 
Envoy=E9 : mardi = 26 juillet 2011 22:54
=C0 :  cdni@ietf.org
Objet : comments on = draft-bertrand-cdni-use-cases-02
 
Hello,
 
Please find my review comments = below.
Cheers
 
Francois
 
*** = Abstract & Introduction:
"
It = provides the business motivations for CDNI Working Group, which can be = used to
   = validate different interconnection arrangements, and requirements of the = various CDNI interfaces.
"
Now the WG is = formed you may want to adjust into something = like:
"
It can be used to = provide guidance to the CDNI WG about the interconnection arrangements = to be supported and to validate the requirements of the various CDNI = interfaces."
 
 
*** = Introduction:
"
This document now = merges input from [I-D.watson-cdni-use-cases] = and
   = [I-D.ma-cdni-publisher-use-cases].
"
I = suggest you remove this historical info in new revs, as the document = gradually matures towards WG material.
 
 
*** Introduction:
"
There = are many possible combinations for the relationships = between
   the = different parties (Network Service Provider (NSP), CDN = Provider,
   = Content Service Provider (CSP) and End User) involved in = end-to-end
   = content delivery.  However, in the context of interconnecting = CDNs
   the key = relationships are listed below.
   o  How the CSP interacts with = the CDN provider, so that the CDN
      delivers content = in a manner compliant with CSP's = distribution
      = policies.
   = o  How the End User interacts with the CSP and one or more CDNs = to
      request and receive = content.
   = o  How the different CDN providers, operating their CDNs, = interact
      with one another to = deliver the CSP's content to the End User
      while continuing = to enforce the CSP's distribution policies.
"
I don't = quite see the relevance of this text in the use-case document, or what = point it is trying to bring across.
In particular, it is a little confusing sine it = talks about interfaces that are out of scope for CDNI without saying = so.
 
 
*** 1.1 = Terminology
o I expect that = terminology across problem-statement, requirements and use-case needs to = be aligned and made probably moved into one document and referred by all = the others.
o "CDN Peering": I = am not sure we need that term.
o "Recursive request routing/ Recursive request = routing": see discussion on the list about moving those terms in a = single doc
 
 
*** 1.3 = High Level Use Cases for Multi-CDN Systems I found it a little confusing = to have the word "use cases" used here in the introduction as well as = later in teh individual use-cases.
How about something like "Rationale or Multi-CDN = Systems"?
 
 
*** 1.3 = High Level Use Cases for Multi-CDN Systems "
CSP-1 benefits because it only needs to make one = business agreement
   and = one physical connection, with CDN Provider A, but its End = Users
   get a = service quality as though it had also gone to the trouble = of
   making a = business agreement with CDN Provider B.
"
s/as = though it had /as though CSP-1 had /
 
 
*** 1.4.  The Need for CDNI = Standards
"
   = Existing CDN interfaces are proprietary and an external CDN = typically
   = cannot use them, especially if the two CDNs rely on = different
   = solutions.
"
It is difficult to = use existing interfaces because they are proprietary, but also because = they have often been designed as intra-CDN/intra-domain interfaces, so = they don't have all the right attributes.
Also, I think by "solutions" you mean = "implementations".
So = perhaps:
"
   = Existing CDN interfaces are proprietary and have often been design for = intra-CDN/intra-domain operations. So an external CDN typically cannot = use them, especially if the two CDNs rely on different = implementations.
"
 
"
Nevertheless, = [I-D.bertrand-cdni-experiments] shows that
   some level of CDN interconnection = can be achieved experimentally
   without standardized interfaces = between the CDNs.  The methods used
   in these experiments are hardly = usable in an operational context,
   because they suffer from several = limitations in terms of
   functionalities, scalability, and security = level.
"
s/ The methods = used/However, the methods used/
 
 
"
   The aim of the CDNI standards work is = therefore to overcome such
   shortcomings; a full list of = requirements is being developed in
   = [I-D.lefaucheur-cdni-requirements].
"
s/the = CDNI standards work/IETF CDNI WG solution/
 
 
***2.1.  Geographic = Extension
"
   In = this use case, the CDN Provider wants to extend the = geographic
   = distribution that it can offer CSPs, without
 
   o  compromising the quality of = delivery
 
   o  attracting transit and other network = costs by serving from
      geographically or = topologically remote surrogates.
"
I think = would read better as:
"
   In = this use case, the CDN Provider wants to extend the = geographic
   = distribution that it can offer to its CSPs:
 
   o  without compromising the = quality of delivery
 
   o  without incurring additional transit = and other network costs that would result from serving content = from
      geographically or = topologically remote surrogates.
"
 
"
As an example, = suppose a French CSP wants to distribute its = TV
   programs to = End Users located in various countries in Europe = and
   North = Africa.  It asks a French CDN Provider to deliver the = content.
   The = French CDN Provider's network only covers France, so it makes = an
   agreement = with another CDN Provider that covers North = Africa.
   = Overall, from the CSP's perspective the French CDN Provider = provides
   a CDN = service for both France and North Africa.
"
The = example initially mentions a required coverage of Europe+ North Africa, = but then seem to descrive a solution for a coverage of France+North = Africa.
 
 
*** = 2.2.  Region to Region Interconnection I don't find the phrase = "Region to Region" very distinctive versus the previous "Geographic = Extension".
I think the key = differences here is that the different CDNs are operated by different = organization that are affiliates of the same = company.
So how about = "Inter-Affiliates Interconnection"?
 
 
*** 2.3.  Nomadic = Users
You may want to = mention that this is often loosely referred to as "TV = everywhere".
 
"
The motivation in = this case is to allow nomadic users to maintain = access,
   = rather than to allow all residents within a region access to = the
   = content.
"
s/to maintain = access/to maintain access with consistent quality of = experience/
 
You may = want to expand a little on which CDNs need to be interconnected to = address the use case (ie with CDN of "home NSP" interconnected to CDN of = visited NSP) possibly with a picture.
 
 
*** 2.4.  Delivery = Restrictions
"Hence, the = exchange through the CDN interconnection of = information
   for = controlling the footprint of the delivery is an important = use
   = case.
"
To me this is not = an additional use cases, this is a requirement that has to be met in the = use cases described earlier. In fact, the document mixes use cases and = requirements in a few places.
I would suggest that = :
      * you refer to  = things discussed in that section as = "requirements"
      * add a statement = clarifying these requirements apply to the use cases discussed in the = document.
 
"
   = o  an expiration time (i.e., the time at which the content = files
      should be expunged from = all CDN storage).
"
I understand this = is saying that CDNI metadata need to include this expiration time = (triggering cache removal) , in addition to deactivation = time.
I don't think this = is discussed in cdni-requirements yet. Can you bring that up on the list = with the cdni-reqts authors?
 
"
   The delivery of content may be further = influenced by policies which
   may include quality of service rules = that specify:
   = o  the maximum resolution deliverable to specific = devices,
   = o  the maximum resolution deliverable though a specific NSP, = or
   o  the = maximum resolution deliverable to users based on = their
      subscription = levels.
"
I don't think this = is covered in the cdni-requirements doc.
It is not obvious to me that absolutely all of = those ought to be in phase 1. The first bullet only makes sense if the = solution supports transcoding/transrating, which I don't know if it will = be supported in Initial scope.
The last bullet does not make sense to me as we = don;t want the CDNs to be aware of any user subscription levels (ie only = CSP is aware of user subscription level).
 
 
*** 3.1.  Overload Handling and Dimensioning = "
This brings dimensioning = savings to the CDNs as they can use the = resources
   of = each other during their peaks of activity.
"
s/their = peaks of activity./ their respective peaks of = activity./
 
 
*** = 3.3.  Branding Consideration
Again, this seems more of a requirement than a = use case per-say. I recommend you make that clear upfront in teh section = (ie this is not an extra use cases, but a requirement applying to = use-cases discussed before).
Also, is there a reason this applicable to only = the use cases in section 3 and not section = 2?
Anotehr option may be to = move 2.4 and 3.3 under a separate heading somewhere collecting key = requirements applicable to the many use = cases.
 
 
*** = 4.1.  Device and Network Technology Extension Again I think some of = the discussion assumes that there is some conversion of quality done = inside the CDNs (as opposed to different terminal requesting different = URIs).
I think we need to = discuss whether this is going to come in Initial Scope or = not.
 
 
 
*** in = Figure 2:
s/CDN Provider = A/CDN Provider 1/
 
 
 
*** = co-authors. You have a long list of co-authors. As per current practice, = you would want to split that into "editors" and = "contributors".