From flefauch@cisco.com Wed Aug 1 07:05:12 2012 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 5ABDB21F8610; Wed, 1 Aug 2012 07:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.453 X-Spam-Level: X-Spam-Status: No, score=-10.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, 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 3hcYKYqThXQv; Wed, 1 Aug 2012 07:05:11 -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 4C39B21F853E; Wed, 1 Aug 2012 07:05:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=3495; q=dns/txt; s=iport; t=1343829911; x=1345039511; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=UmytXoCwKZR/mszKTfpjLcTAYb2Zd67w91v3xA43o4k=; b=hwlphx6cYZXKPy/yawhe0oZHGk1Pb7qaBZek1D9amyBpS7A9P1oM3uMb lPPzz9NQVcvaPzjmbNioilNFaS8TYnIVKAM+FBpJEXkxBVZK/8VaOtiKD 8vT1VykcRKoUWuT87fRITt687haD7U2XMjdvyZUcQqtBhHDVoyY5Ri6vB A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAPM2GVCtJV2Z/2dsb2JhbAA7CrkRgQeCIAEBAQMBAQEBDwEnNAsFBwQCARkEAQEfCQcnCxQJCAIEDgUbB4dlBgucQ6BLBItJEIYZYAOVR44ngWaCX4Ff X-IronPort-AV: E=Sophos;i="4.77,694,1336348800"; d="scan'208";a="107406796" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP; 01 Aug 2012 14:05:10 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q71E5ADa003656 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 1 Aug 2012 14:05:10 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.184]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0298.004; Wed, 1 Aug 2012 09:05:10 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni-footprint@ietf.org" Thread-Topic: CDNI Footprint/Capabilities Design Team - Suggestion to work from simple usecases Thread-Index: AQHNb+6oW4rEbIaOHEianIYA11qX0g== Date: Wed, 1 Aug 2012 14:05:09 +0000 Message-ID: References: <2779C9F0771F974CAD742BAE6D9904FE32CE33F7@PALLENE.office.hd> In-Reply-To: <2779C9F0771F974CAD742BAE6D9904FE32CE33F7@PALLENE.office.hd> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.125.64] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19076.006 x-tm-as-result: No--56.757900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: [CDNi] CDNI Footprint/Capabilities Design Team - Suggestion to work from simple usecases 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: Wed, 01 Aug 2012 14:05:12 -0000 Jan, Stefano, Jon, I just wanted to reiterate the suggestion I made at the very end of the WG = meeting Yesterday. A possible way to make progress might be to: 1) identify one, or a very small number, of use case(s) that we want the C= DNI Footprint/Capabilities to support 2) identify the semantics of the required information for this/these speci= fic use cases. While this approach may arguably not allow us to define the most flexible u= niversal solution, it would have the merit of allowing us to define a solut= ion addressing some part of the problem. With respect to 1), I think the design team has already identified ISP CDNs= and global CDNs as targeted dCDNs. So perhaps the use cases of focus could= include something like: * the uCDN wants to use dCDN1 (CDN of ISP1) when the enduser is attached t= o a part of ISP1 and where ISP1 feels the request can be well served by on-= net caches of ISP1 (an interesting flavor of this is where ISP1 has some of= his AS not covered well by his own CDN - e.g. some remote territory) * the uCDN wants to use dCDN2 (CDN of ISP 2) when the enduser is attached = to a part of ISP1 where ISP1 feels the request can _not_ be well served by = on-net caches of ISP1 but where ISP2 claims that the request can be well se= rved by CDN of ISP2 (because he has caches that - while not "on-net" on ISP= 1 - are well connected to ISP1 e.g. via many regional peering points) * the uCDN wants to use dCDN3 (a global CDN) when the enduser is attached = to any other ISP network with whom dCDN3 is well interconnected (e.g. via m= any regional peering points) * the uCDN wants to use dCDN 4 (another global CDN) when the enduser is at= tached to an ISP network with whom dCDN3 is not well interconnected (e.g. v= ia single centralized peering points) I just made that up so it needs more thinking, but take is as an example of= the sort of use case we may want to start from. =20 I hope that helps Francois On 31 Jul 2012, at 18:05, Jan Seedorf wrote: > Several people have indicated that they will come to this meeting, so: "i= t's on" :) Let's meet tomorrow (WED) at 15:00 at the IETF registration desk= to continue our discussions, trying to make some progress ... >=20 > - Jan >=20 >> -----Original Message----- >> From: cdni-footprint-bounces@ietf.org [mailto:cdni-footprint- >> bounces@ietf.org] On Behalf Of Jan Seedorf >> Sent: Wednesday, August 01, 2012 1:18 AM >> To: cdni-footprint@ietf.org >> Cc: Brandenburg, R. (Ray) van (ray.vanbrandenburg@tno.nl); Enrico >> Marocco; gilles.bertrand@orange.com; emile.stephan@orange.com; Kevin J >> Ma (kevin.ma@azukisystems.com) >> Subject: Re: [cdni-footprint] Doodle for 2nd CDNI Footprint/Capabilities >> Design Team Side Meeting at IETF-84 >>=20 >> Guys, >>=20 >> Looking at the latest doodle it seems that actually *** WED 15:00-17:00 = *** >> would be a good slot where a reasonable amount of people can make it. So= I >> suggest having another CDNI Footprint/Capabilities Design Team Side >> Meeting at this time. >>=20 >> Please confirm via email if you can actually make this slot, so that we = see if it >> really makes sense to have the meeting (i.e. all people that indicated s= o in >> the doodle really coming). >>=20 >> - Jan >>=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From roy@skytide.com Wed Aug 1 09:13:25 2012 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 7386811E8118 for ; Wed, 1 Aug 2012 09:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.734 X-Spam-Level: X-Spam-Status: No, score=-1.734 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 4M+v5vAdNJq4 for ; Wed, 1 Aug 2012 09:13:24 -0700 (PDT) Received: from mail-pop3-1.server101.com (ns1.giga-sj-001.net [216.218.210.201]) by ietfa.amsl.com (Postfix) with ESMTP id B2BF511E80E5 for ; Wed, 1 Aug 2012 09:13:24 -0700 (PDT) Received: from [172.16.4.47] (108-248-234-253.lightspeed.sntcca.sbcglobal.net [108.248.234.253]) (authenticated as roy@skytide.com with PLAIN (0 bits)) by mail-pop3-1.server101.com (8.13.7/8.12.8) with ESMTP id q71GDJCb014745; Thu, 2 Aug 2012 02:13:20 +1000 Message-ID: <5019559F.2040201@skytide.com> Date: Wed, 01 Aug 2012 09:13:19 -0700 From: Roy Peterkofsky User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "Y. Richard Yang" References: <5018BF8D.4040506@cs.yale.edu> In-Reply-To: <5018BF8D.4040506@cs.yale.edu> Content-Type: multipart/alternative; boundary="------------070307070508060407060005" Cc: cdni@ietf.org Subject: Re: [CDNi] comments on draft-lefaucheur-cdni-logging-delivery-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: Wed, 01 Aug 2012 16:13:25 -0000 This is a multi-part message in MIME format. --------------070307070508060407060005 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 7/31/2012 10:33 PM, Y. Richard Yang wrote: > > - There are use cases to log client QoE, for example, freezing ratio > and # of freezing times. Such metrics may be only observable by the > End User Agent only. A dCDN may collect such data (from End User > Agent) and report to uCDN/CSP. It is a good point that this metrics are of interest. It seems unlikely, however, that a dCDN would have control over the end user agent. That would more typically be under the control of the CSP. Therefore, I am not sure what value including this in the log format for communication between dCDNs and uCDNs would bring. > > Thanks. > > Richard > > > > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > > > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2012.0.2197 / Virus Database: 2437/5167 - Release Date: 07/31/12 > -- Roy Peterkofsky Vice President, Product Management Skytide -- the leader in Digital Media Performance Management www.skytide.com (510) 250-4284 Read our new white paper: The 4 Keys to Telco CDN Success --------------070307070508060407060005 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit


On 7/31/2012 10:33 PM, Y. Richard Yang wrote:

- There are use cases to log client QoE, for example, freezing ratio and # of freezing times. Such metrics may be only observable by the End User Agent only. A dCDN may collect such data (from End User Agent) and report to uCDN/CSP.

It is a good point that this metrics are of interest.  It seems unlikely, however, that a dCDN would have control over the end user agent.  That would more typically be under the control of the CSP.  Therefore, I am not sure what value including this in the log format for communication between dCDNs and uCDNs would bring.



Thanks.

Richard



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


No virus found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.2197 / Virus Database: 2437/5167 - Release Date: 07/31/12



--
Roy Peterkofsky
Vice President, Product Management
Skytide -- the leader in Digital Media Performance Management
www.skytide.com
(510) 250-4284

Read our new white paper: The 4 Keys to Telco CDN Success
--------------070307070508060407060005-- From yry@cs.yale.edu Wed Aug 1 10:12:27 2012 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 733F911E821F for ; Wed, 1 Aug 2012 10:12:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=0.300, 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 nzqRogAzap7z for ; Wed, 1 Aug 2012 10:12:26 -0700 (PDT) Received: from vm-emlprdomr-02.its.yale.edu (vm-emlprdomr-02.its.yale.edu [130.132.50.143]) by ietfa.amsl.com (Postfix) with ESMTP id DA2A611E8228 for ; Wed, 1 Aug 2012 10:12:25 -0700 (PDT) Received: from Faculty-Supports-MacBook-Pro-2.local ([67.21.202.20]) (authenticated bits=0) by vm-emlprdomr-02.its.yale.edu (8.14.4/8.14.4) with ESMTP id q71HCLZe020083 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 1 Aug 2012 13:12:22 -0400 Message-ID: <50196373.3060805@cs.yale.edu> Date: Wed, 01 Aug 2012 10:12:19 -0700 From: "Y. Richard Yang" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Roy Peterkofsky References: <5018BF8D.4040506@cs.yale.edu> <5019559F.2040201@skytide.com> In-Reply-To: <5019559F.2040201@skytide.com> Content-Type: multipart/alternative; boundary="------------020709090708060309090300" X-Scanned-By: MIMEDefang 2.71 on 130.132.50.143 Cc: cdni@ietf.org Subject: Re: [CDNi] comments on draft-lefaucheur-cdni-logging-delivery-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: Wed, 01 Aug 2012 17:12:27 -0000 This is a multi-part message in MIME format. --------------020709090708060309090300 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Roy, On 8/1/12 9:13 AM, Roy Peterkofsky wrote: > > > On 7/31/2012 10:33 PM, Y. Richard Yang wrote: >> >> - There are use cases to log client QoE, for example, freezing ratio >> and # of freezing times. Such metrics may be only observable by the >> End User Agent only. A dCDN may collect such data (from End User >> Agent) and report to uCDN/CSP. > > It is a good point that this metrics are of interest. Glad you also agree that this is a type of metrics that ay have interest. > It seems unlikely, however, that a dCDN would have control over the > end user agent. That would more typically be under the control of the > CSP. It really depends on where the event handler(s) at the UA reports to. Some CSPs may use a third party analytics service, but it can be natural that a CDN provides this report as a part of the service. If it is the CDN who gets the reports and given that the uCDN delegates to the dCDN (say due to limited capacity/footprint), it is less likely that the uCDN is the reported target, but instead the uCDN. What do you think? Richard > Therefore, I am not sure what value including this in the log format > for communication between dCDNs and uCDNs would bring. > > >> >> Thanks. >> >> Richard >> >> >> >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni >> >> >> No virus found in this message. >> Checked by AVG - www.avg.com >> Version: 2012.0.2197 / Virus Database: 2437/5167 - Release Date: 07/31/12 >> > > > -- > Roy Peterkofsky > Vice President, Product Management > Skytide -- the leader in Digital Media Performance Management > www.skytide.com > (510) 250-4284 > > Read our new white paper: The 4 Keys to Telco CDN Success > --------------020709090708060309090300 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Roy,

On 8/1/12 9:13 AM, Roy Peterkofsky wrote:


On 7/31/2012 10:33 PM, Y. Richard Yang wrote:

- There are use cases to log client QoE, for example, freezing ratio and # of freezing times. Such metrics may be only observable by the End User Agent only. A dCDN may collect such data (from End User Agent) and report to uCDN/CSP.

It is a good point that this metrics are of interest.

Glad you also agree that this is a type of metrics that ay have interest.
It seems unlikely, however, that a dCDN would have control over the end user agent.  That would more typically be under the control of the CSP. 
It really depends on where the event handler(s) at the UA reports to. Some CSPs may use a third party analytics service, but it can be natural that a CDN provides this report as a part of the service. If it is the CDN who gets the reports and given that the uCDN delegates to the dCDN (say due to limited capacity/footprint), it is less likely that the uCDN is the reported target, but instead the uCDN. What do you think?

Richard

Therefore, I am not sure what value including this in the log format for communication between dCDNs and uCDNs would bring.



Thanks.

Richard



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


No virus found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.2197 / Virus Database: 2437/5167 - Release Date: 07/31/12



--
Roy Peterkofsky
Vice President, Product Management
Skytide -- the leader in Digital Media Performance Management
www.skytide.com
(510) 250-4284

Read our new white paper: The 4 Keys to Telco CDN Success

--------------020709090708060309090300-- From flefauch@cisco.com Wed Aug 1 12:38:35 2012 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 70A7D11E80A3 for ; Wed, 1 Aug 2012 12:38:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.563 X-Spam-Level: X-Spam-Status: No, score=-10.563 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 B3Q-KCPEXzEC for ; Wed, 1 Aug 2012 12:38:34 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 1F03011E809B for ; Wed, 1 Aug 2012 12:38:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=9951; q=dns/txt; s=iport; t=1343849914; x=1345059514; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=iNfGkZxujkiQ7aZgzfaLt3/GBJMmHeIuadC10MYfius=; b=gonGXwTpCOXDMTFZg7lf37hUHZ/l6bNqkjL8qhAS+uNvf99wpW14IpVl lEuZGnkZnp6ZfxREVtB9d2NdnyoAfQaUOCASeeoxAaWtKxC0LuWMHoRLk 9KwcRGxA+/8AJtbf+AqyPLbs1/ZMY6O9JhBmP4L7FuaYDDbgzgDdNBgQT c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIWEGVCtJV2Z/2dsb2JhbABCAw65AoEHgiEBAQQBAQEPATYlBAcQAgEIBw0rBycLFBECBA4FIodrC5xroEqLSRSDVIJBYAOIGI0vjieBZoImOYFW X-IronPort-AV: E=Sophos;i="4.77,695,1336348800"; d="scan'208,217";a="107611002" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-3.cisco.com with ESMTP; 01 Aug 2012 19:38:33 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q71JcX29015804 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 1 Aug 2012 19:38:33 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.184]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0298.004; Wed, 1 Aug 2012 14:38:33 -0500 From: "Francois Le Faucheur (flefauch)" To: "Y. Richard Yang" Thread-Topic: [CDNi] comments on draft-lefaucheur-cdni-logging-delivery-01.txt Thread-Index: AQHNb6cssttOwiZxDUK4cz3vBu6wzJdFdaSAgAAQfICAACjcAA== Date: Wed, 1 Aug 2012 19:38:33 +0000 Message-ID: References: <5018BF8D.4040506@cs.yale.edu> <5019559F.2040201@skytide.com> <50196373.3060805@cs.yale.edu> In-Reply-To: <50196373.3060805@cs.yale.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.125.170] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19078.001 x-tm-as-result: No--49.490100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_FC1B9AFE29E346D8B00D5C90E987FC53ciscocom_" MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] comments on draft-lefaucheur-cdni-logging-delivery-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: Wed, 01 Aug 2012 19:38:35 -0000 --_000_FC1B9AFE29E346D8B00D5C90E987FC53ciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On 1 Aug 2012, at 10:12, Y. Richard Yang wrote: Hi Roy, On 8/1/12 9:13 AM, Roy Peterkofsky wrote: On 7/31/2012 10:33 PM, Y. Richard Yang wrote: - There are use cases to log client QoE, for example, freezing ratio and # = of freezing times. Such metrics may be only observable by the End User Agen= t only. A dCDN may collect such data (from End User Agent) and report to uC= DN/CSP. It is a good point that this metrics are of interest. Glad you also agree that this is a type of metrics that ay have interest. It seems unlikely, however, that a dCDN would have control over the end use= r agent. That would more typically be under the control of the CSP. It really depends on where the event handler(s) at the UA reports to. Some = CSPs may use a third party analytics service, but it can be natural that a = CDN provides this report as a part of the service. While it is conceivable that CDNs could take on the role of collecting/aggr= egating user agent QoE stats on behalf a CSP, I think this is more of a val= ue add service than a core delivery service. Considering that: * our charter guides us towards delivering first a base set of capabilities= in a fairly short timeframe * the target date for delivering the CDNI Logging interface is _December 20= 12_ * supporting collection of user agent QoE Stats would involve a number of i= nteresting issues (e.g. what protocol does CDN uses to obtain the stats fro= m the enduser? how can the dCDN be authorized by CSP to collect stats from = CSP-controlled user agent considering the CSP may not have any relationship= with the dCDN and in fact may not even be ware of it?), I recommend that we keep collection of user agent QoE stats on our list of = candidates for rechartering. But along the lines of improving the performance tracking through a CDNI en= vironment, a more modest but achievable goal may be for the CDNI Logs to in= clude a few more perf related fields that can be directly measured by the S= urrogate. I believe the DASH performance specs include several reference po= ints for measurement on the client side and the lowest level reference poin= t relates to transport/delivery: perhaps we could look at those and see if = we could extract a few meaningful perf metrics for which we could define th= e mirror server-side metric. And allow inclusion of those in our CDNI logs. Makes sense ? Thanks Francois If it is the CDN who gets the reports and given that the uCDN delegates to = the dCDN (say due to limited capacity/footprint), it is less likely that th= e uCDN is the reported target, but instead the uCDN. What do you think? Richard Therefore, I am not sure what value including this in the log format for co= mmunication between dCDNs and uCDNs would bring. Thanks. Richard _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni No virus found in this message. Checked by AVG - www.avg.com Version: 2012.0.2197 / Virus Database: 2437/5167 - Release Date: 07/31/12 -- Roy Peterkofsky Vice President, Product Management Skytide -- the leader in Digital Media Performance Management www.skytide.com (510) 250-4284 Read our new white paper: The 4 Keys to Telco CDN Success _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni --_000_FC1B9AFE29E346D8B00D5C90E987FC53ciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <088F8CC2CC057041857D2D24C2D3EE68@cisco.com> Content-Transfer-Encoding: quoted-printable

On 1 Aug 2012, at 10:12, Y. Richard Yang wrote:

Hi Roy,

On 8/1/12 9:13 AM, Roy Peterkofsky wrote:


On 7/31/2012 10:33 PM, Y. Richard Yang wrote:

- There are use cases to log client QoE, for example, freezing ratio and # = of freezing times. Such metrics may be only observable by the End User Agen= t only. A dCDN may collect such data (from End User Agent) and report to uC= DN/CSP.

It is a good point that this metrics are of interest.

Glad you also agree that this is a type of metrics that ay have interest.
It seem= s unlikely, however, that a dCDN would have control over the end user agent= .  That would more typically be under the control of the CSP. 
It really depends on where the event handler(s) at the UA reports to. Some = CSPs may use a third party analytics service, but it can be natural that a = CDN provides this report as a part of the service.

While it is conceivable that CDNs could take on the role of collecting= /aggregating user agent QoE stats on behalf a CSP, I think this is more of = a value add service than a core delivery service. 
Considering that:
* our = charter guides us towards delivering first a base set of capabilities in a = fairly short timeframe
* the = target date for delivering the CDNI Logging interface is _December 2012_
* supp= orting collection of user agent QoE Stats would involve a number of interes= ting issues (e.g. what protocol does CDN uses to obtain the stats from the = enduser? how can the dCDN be authorized by CSP to collect stats from CSP-controlled user agent considering the CSP= may not have any relationship with the dCDN and in fact may not even be wa= re of it?),
I recommend that we keep collection of user agent QoE stats on our lis= t of candidates for rechartering. 

But along the lines of improving the performance tracking through a CD= NI environment, a more modest but achievable goal may be for the CDNI = Logs to include a few more perf related fields that can be directly measure= d by the Surrogate. I believe the DASH performance specs include several reference points for measurement on the = client side and the lowest level reference point relates to transport/deliv= ery: perhaps we could look at those and see if we could extract a few meani= ngful perf metrics for which we could define the mirror server-side metric. And allow inclusion of those i= n our CDNI logs.

Makes sense ?

Thanks

Francois


If it is the CDN who gets the rep= orts and given that the uCDN delegates to the dCDN (say due to limited capa= city/footprint), it is less likely that the uCDN is the reported target, bu= t instead the uCDN. What do you think?

Richard

Therefo= re, I am not sure what value including this in the log format for communica= tion between dCDNs and uCDNs would bring.



Thanks.

Richard



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


No virus foun= d in this message.
Checked by AVG - w= ww.avg.com
Version: 2012.0.2197 / Virus Database: 2437/5167 - Release Date: 07/31/12



--
Roy Peterkofsky
Vice President, Product Management
Skytide -- the leader in Digital Media Performance Management
www.skytide.com
(510) 250-4284

Read our new white paper: The 4 Keys to Telco CDN Success

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

--_000_FC1B9AFE29E346D8B00D5C90E987FC53ciscocom_-- From yang.r.yang@gmail.com Wed Aug 1 14:19:00 2012 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 C63A411E8339; Wed, 1 Aug 2012 14:18:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.908 X-Spam-Level: X-Spam-Status: No, score=-0.908 tagged_above=-999 required=5 tests=[AWL=-1.831, BAYES_00=-2.599, FB_CIALIS_LEO3=3.899, FM_FORGED_GMAIL=0.622, 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 RTvck+pyjmlm; Wed, 1 Aug 2012 14:18:58 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8ADA511E8345; Wed, 1 Aug 2012 14:18:57 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so14539101obb.31 for ; Wed, 01 Aug 2012 14:18:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=LglT63Xi3PBEmukb+Ks2oCfOXQ4PWJcQdihz3wE3chg=; b=iz43W6t4M527G456w/sbY+3dJVlqF2C6H+IPiChDc9l+vxQXTvBSkoQmcksD69icmk F43U7eKx1Cv1PJcT47djNqsTTUi0Nc25PClCqxRcmqvBt2u3pNntdps6V1p8Dob/wpRL K4pPBl+Ws6hW292//nRiu9OMdTR7z1WqytlJd7CU5zKPe72Ipa1t1Vj+SXDJr4vskgYM cAQSwakk7oJd01Ft9oWPNjHPCwBz59aG9dDZOKCDxJFS6+sgNKfJUIziBMa95v/aWgDw lE6N89YiKW4HtY10RU1NtbEKGjmhizCjArkiqYvBpqiP1KyleCjgisM7EMYhn+PNuiX2 vlpA== MIME-Version: 1.0 Received: by 10.60.172.101 with SMTP id bb5mr30961713oec.44.1343855936999; Wed, 01 Aug 2012 14:18:56 -0700 (PDT) Sender: yang.r.yang@gmail.com Received: by 10.76.86.136 with HTTP; Wed, 1 Aug 2012 14:18:56 -0700 (PDT) In-Reply-To: References: <2779C9F0771F974CAD742BAE6D9904FE32CE33F7@PALLENE.office.hd> Date: Thu, 2 Aug 2012 05:18:56 +0800 X-Google-Sender-Auth: Qz1cUmvuHYxQb0tgssL3dRVST8g Message-ID: From: "Y. Richard Yang" To: "Francois Le Faucheur (flefauch)" Content-Type: multipart/alternative; boundary=bcaec552435cc110fe04c63ad704 Cc: "cdni-footprint@ietf.org" , "cdni@ietf.org" Subject: Re: [CDNi] CDNI Footprint/Capabilities Design Team - Suggestion to work from simple usecases 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: Wed, 01 Aug 2012 21:19:00 -0000 --bcaec552435cc110fe04c63ad704 Content-Type: text/plain; charset=ISO-8859-1 Hi Francois, Good suggestion. Jon also mentioned that we might want to reread the use case draft, which contains many use cases already. Before we pile in more use cases, I will give a try on the example use case from your email, as the example already touches on some basic issues. In particular, to handle the use case, the uCDN needs the following info from dCDN[1-4]: - dCDN1 (ISP1) Set11 (good set) of dCDN1's home net -> QoE11 Set12 (poor set) of dCDN1's home net -> QoE12 Implication 1: we need ip level encoding, as AS level (Set11 and Set12 may not partition along the ASNs of ISP 1, or ISP1 has only one ASN) may not be enough. Implication 2: we need to come up with representation and semantics for QoE11 and QoE12. One approach is true/false representation, where true means willing-and-can-serve, and false means not willing-or-can-not. However, this is too aggressive, as (1) poor QoE does not mean fully useless; (2) poor or not depends on the request. For example, what I heard is that audio needs 150 ms latency, video needs 200 ms; streaming depends on the streaming rate, etc. Using the spirit of divide-and-conquer, may I suggest that we identify a modular task of defining content delivery performance characterization (syntax and semantics). Just as defining a delivery logging format is a good *hopefully-reusable* "by-product" of CDNi (independent of CDNi deployed or not), we have a smaller, hopefully-reusable task than the larger footprint/capability advertisement task, and we can move on, as long as we feel that there is a quite reasonable chance that the subtask (defining content delivery performance metrics) can be done. As a starting starting straw-man, I define: propagation-delay bound (ms) [Mandatory] max-supported-per-ua-streaming rate (Kbps) [M] delay-jitter [O] I feel that there are multiple experts on content delivery metrics and we can define an initial set. Now we go to dCDN2 (ISP2): Set21 of dCDN2 -> QoE21 Set22 of dCDN2 -> QoE22 ... Note that Set12 intersects with some Set2j. ... Continue this example, an architecture/protocol issue we may face, while the content delivery metrics group is working on the metrics, is how the uCDN will aggregate the reported QoEs to propagate further. One way is the BGP Best-Path design (applying filtering such as comparison with internal/3rd party measurements) which essential reports a single QoE for each IP. Another design is exposing multipaths by exposing multiple access points. Clearly I support the multipaths design. Richard PS: I may suggest the failure/maintainence use case in the use-case draft as a next case. As I see an RSVP style protocol flow will come out of it. I also feel that the affiliation/migration use cases provide another type of distinct use case (less privacy concern). On Wednesday, August 1, 2012, Francois Le Faucheur (flefauch) wrote: > Jan, Stefano, Jon, > > I just wanted to reiterate the suggestion I made at the very end of the WG > meeting Yesterday. > > A possible way to make progress might be to: > > 1) identify one, or a very small number, of use case(s) that we > want the CDNI Footprint/Capabilities to support > > 2) identify the semantics of the required information for > this/these specific use cases. > > While this approach may arguably not allow us to define the most flexible > universal solution, it would have the merit of allowing us to define a > solution addressing some part of the problem. > > With respect to 1), I think the design team has already identified ISP > CDNs and global CDNs as targeted dCDNs. So perhaps the use cases of focus > could include something like: > * the uCDN wants to use dCDN1 (CDN of ISP1) when the enduser is > attached to a part of ISP1 and where ISP1 feels the request can be well > served by on-net caches of ISP1 (an interesting flavor of this is where > ISP1 has some of his AS not covered well by his own CDN - e.g. some remote > territory) > * the uCDN wants to use dCDN2 (CDN of ISP 2) when the enduser is > attached to a part of ISP1 where ISP1 feels the request can _not_ be well > served by on-net caches of ISP1 but where ISP2 claims that the request can > be well served by CDN of ISP2 (because he has caches that - while not > "on-net" on ISP1 - are well connected to ISP1 e.g. via many regional > peering points) > * the uCDN wants to use dCDN3 (a global CDN) when the enduser is > attached to any other ISP network with whom dCDN3 is well interconnected > (e.g. via many regional peering points) > * the uCDN wants to use dCDN 4 (another global CDN) when the > enduser is attached to an ISP network with whom dCDN3 is not well > interconnected (e.g. via single centralized peering points) > I just made that up so it needs more thinking, but take is as an example > of the sort of use case we may want to start from. > > I hope that helps > > Francois > > On 31 Jul 2012, at 18:05, Jan Seedorf wrote: > > > Several people have indicated that they will come to this meeting, so: > "it's on" :) Let's meet tomorrow (WED) at 15:00 at the IETF registration > desk to continue our discussions, trying to make some progress ... > > > > - Jan > > > >> -----Original Message----- > >> From: cdni-footprint-bounces@ietf.org [mailto: > cdni-footprint- > >> bounces@ietf.org ] On Behalf Of Jan Seedorf > >> Sent: Wednesday, August 01, 2012 1:18 AM > >> To: cdni-footprint@ietf.org > >> Cc: Brandenburg, R. (Ray) van (ray.vanbrandenburg@tno.nl ); > Enrico > >> Marocco; gilles.bertrand@orange.com ; > emile.stephan@orange.com ; Kevin J > >> Ma > ( > kevin.ma@azukisystems.com ) > >> Subject: Re: [cdni-footprint] Doodle for 2nd CDNI Footprint/Capabilities > >> Design Team Side Meeting at IETF-84 > >> > >> Guys, > >> > >> Looking at the latest doodle it seems that actually *** WED 15:00-17:00 > *** > >> would be a good slot where a reasonable amount of people can make it. > So I > >> suggest having another CDNI Footprint/Capabilities Design Team Side > >> Meeting at this time. > >> > >> Please confirm via email if you can actually make this slot, so that we > see if it > >> really makes sense to have the meeting (i.e. all people that indicated > so in > >> the doodle really coming). > >> > >> - Jan > >> > > _______________________________________________ > > 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 > --bcaec552435cc110fe04c63ad704 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Francois,

Good suggestion. Jon also mentioned that we= might want to reread the use case draft, which contains many use cases alr= eady.=A0

Before we pile in more use cases, I will = give a try on the example use case from your email, as the example already = touches on some basic issues. In particular, to handle the use case, =A0the= uCDN needs the following info from dCDN[1-4]:

- dCDN1 (ISP1)

=A0 Set11 (good set) of dC= DN1's home net -> QoE11=A0
=A0 Set12 (poor set) of dCDN1&#= 39;s home net -> QoE12

Implication 1: we need i= p level encoding, as AS level (Set11 and Set12 may not partition along the = ASNs of ISP 1, or ISP1 has only one ASN) may not be enough.

Implication 2: we need to come up with representation a= nd semantics for QoE11 and QoE12. One approach is true/false representation= , where true means willing-and-can-serve, and false means not willing-or-ca= n-not. However, this is too aggressive, as (1) poor QoE does not mean fully= useless; (2) poor or not depends on the request. For example, what I heard= is that audio needs 150 ms latency, video needs 200 ms; streaming depends = on the streaming rate, etc. Using the spirit of divide-and-conquer, may I s= uggest that we identify a modular task of defining content delivery perform= ance characterization (syntax and semantics). Just as defining a delivery l= ogging format is a good *hopefully-reusable* "by-product" of CDNi= (independent of CDNi deployed or not), we have a smaller, hopefully-reusab= le task than the larger footprint/capability advertisement task, and we can= move on, as long as we feel that there is a quite reasonable chance that t= he subtask (defining content delivery performance metrics) can be done. As = a starting starting straw-man, I define:
propagation-delay bound (ms) [Mandatory]
max-supported-per-ua-strea= ming rate (Kbps) [M]
delay-jitter [O]

I = feel that there are multiple experts on content delivery metrics and we can= define an initial set.

Now we go to dCDN2 (ISP2):

=A0 Set21 of dCDN2 -> QoE21
=A0 Set22 of dCDN2 -> QoE22
=A0 ...

=A0 Note that Set12 intersects wi= th some Set2j.

...

Continue this example= , an architecture/protocol issue we may face, while the content delivery me= trics group is working on the metrics, is how the uCDN will aggregate the r= eported QoEs to propagate further. One way is the BGP Best-Path design (app= lying filtering such as comparison with internal/3rd party measurements) wh= ich essential reports a single QoE for each IP. Another design is exposing = multipaths by exposing=A0multiple ac= cess points. Clearly I support the multipaths design.

Richard

PS: I may suggest the failure/maintainence use case in the use-case dr= aft as a next case. As I see an RSVP style protocol flow will come out of i= t. I also feel that the affiliation/migration use cases provide another typ= e of distinct use case (less privacy concern).

On Wednesday, August 1, 2012, Francois Le Faucheur (flefauch)= wrote:
Jan, Stefano, Jon,

I just wanted to reiterate the suggestion I made at the very end of the WG = meeting Yesterday.

A possible way to make progress might be to:

=A0 =A0 =A0 =A0 1) identify one, or a very small number, of use case(s) tha= t we want the CDNI Footprint/Capabilities to support

=A0 =A0 =A0 =A0 2) identify the semantics of the required information for t= his/these specific use cases.

While this approach may arguably not allow us to define the most flexible u= niversal solution, it would have the merit of allowing us to define a solut= ion addressing some part of the problem.

With respect to 1), I think the design team has already identified ISP CDNs= and global CDNs as targeted dCDNs. So perhaps the use cases of focus could= include something like:
=A0 =A0 =A0 =A0 * the uCDN wants to use dCDN1 (CDN of ISP1) when the enduse= r is attached to a part of ISP1 and where ISP1 feels the request can be wel= l served by on-net caches of ISP1 (an interesting flavor of this is where I= SP1 has some of his AS not covered well by his own CDN - e.g. some remote t= erritory)
=A0 =A0 =A0 =A0 * the uCDN wants to use dCDN2 (CDN of ISP 2) when the endus= er is attached to a part of ISP1 where ISP1 feels the request can _not_ be = well served by on-net caches of ISP1 but where ISP2 claims that the request= can be well served by CDN of ISP2 (because he has caches that - while not = "on-net" on ISP1 - are well connected to ISP1 e.g. via many regio= nal peering points)
=A0 =A0 =A0 =A0 * the uCDN wants to use dCDN3 (a global CDN) when the endus= er is attached to any other ISP network with whom dCDN3 is well interconnec= ted (e.g. via many regional peering points)
=A0 =A0 =A0 =A0 * the uCDN wants to use dCDN 4 (another global CDN) when th= e enduser is attached to an ISP network with whom dCDN3 is not well interco= nnected (e.g. via single centralized peering points)
I just made that up so it needs more thinking, but take is as an example of= the sort of use case we may want to start from.

I hope that helps

Francois

On 31 Jul 2012, at 18:05, Jan Seedorf wrote:

> Several people have indicated that they will come to this meeting, so:= "it's on" :) Let's meet tomorrow (WED) at 15:00 at the I= ETF registration desk to continue our discussions, trying to make some prog= ress ...
>
> - Jan
>
>> -----Original Message-----
>> From: cdni-footprint-bounces@ietf.o= rg [mailto:cdni-footprint-
>> bounces@ietf.org] On Behalf Of Jan Seedorf
>> Sent: Wednesday, August 01, 2012 1:18 AM
>> To: cdni-footprint@ietf.org
>> Cc: Brandenburg, R. (Ray) van (ray.vanbra= ndenburg@tno.nl); Enrico
>> Marocco; gilles.bertrand@orange.com;= emile.stephan@orange.com; Kevin J
>> Ma <kevin.ma@azukisystems.com> = (kevin.ma@azukisystems.com)
>> Subject: Re: [cdni-footprint] Doodle for 2nd CDNI Footprint/Capabi= lities
>> Design Team Side Meeting at IETF-84
>>
>> Guys,
>>
>> Looking at the latest doodle it seems that actually *** WED 15:00-= 17:00 ***
>> would be a good slot where a reasonable amount of people can make = it. So I
>> suggest having another CDNI Footprint/Capabilities Design Team Sid= e
>> Meeting at this time.
>>
>> Please confirm via email if you can actually make this slot, so th= at we see if it
>> really makes sense to have the meeting (i.e. all people that indic= ated so in
>> the doodle really coming).
>>
>> - Jan
>>
> _______________________________________________
> CDNi mailing list
> CDNi@ietf.org
> https://www.ietf.org/mailman/listinfo/cdni

_______________________________________________
CDNi mailing list
CDNi@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/cdni
--bcaec552435cc110fe04c63ad704-- From ray.vanbrandenburg@tno.nl Wed Aug 1 14:22:16 2012 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 216C811E834B for ; Wed, 1 Aug 2012 14:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.263 X-Spam-Level: X-Spam-Status: No, score=0.263 tagged_above=-999 required=5 tests=[AWL=0.766, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, 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 ncPQU72nt49h for ; Wed, 1 Aug 2012 14:22:15 -0700 (PDT) Received: from fromintoutb.tno.nl (fromintoutb.tno.nl [134.221.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id D6B4011E8345 for ; Wed, 1 Aug 2012 14:22:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,696,1336341600"; d="scan'208,217";a="15919128" Received: from unknown (HELO mail.tno.nl) ([134.221.225.221]) by mailhost1b.tno.nl with ESMTP; 01 Aug 2012 23:21:55 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.96]) by EXC-CASHUB02.tsn.tno.nl ([134.221.225.221]) with mapi id 14.02.0298.004; Wed, 1 Aug 2012 23:21:55 +0200 From: "Brandenburg, R. (Ray) van" To: "cdni@ietf.org" , "bhumip.khasnabish@zteusa.com" Thread-Topic: Comments on draft draft-krishnan-cdni-tm-has-00 Thread-Index: AQHNcCtar9E3CMmGP0C7wFKwbIuN8pdFdwHE Date: Wed, 1 Aug 2012 21:21:53 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_A1781B516C474C48AF21266534863EECtnonl_" MIME-Version: 1.0 Subject: [CDNi] Comments on draft draft-krishnan-cdni-tm-has-00 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: Wed, 01 Aug 2012 21:22:16 -0000 --_000_A1781B516C474C48AF21266534863EECtnonl_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi Bhumip, In response to your question during yesterday's CDNI meeting, I read your d= raft draft-krishnan-cdni-tm-has-00. Since I'm not an expert on TCP and the way router queues are implemented, I= can't comment on the more technical aspects of your draft. However, when l= ooking at the rationale behind the draft I have some questions. If I understand your draft correctly, your main premise is that in cases wh= ere HTTP Adaptive Streaming is used, the content acquisition interface betw= een the dCDN and uCDN (which in itself is out-of-scope of the WG) could bec= ome congested. I have a number of questions related to this: 1) What I don't understand from your draft is what the relationship is betw= een this supposed content congestion and the use of adaptive streaming. Of = course, in peak hours, there will generally be more traffic across the link= than outside peak hours. But isn't true regardless of the case of whether = HAS is used or not? 2) Furthermore, you state that "The bandwidth needs of HAS is directly prop= ortional to the number of active end users who are streaming video." Isn't = the general idea behind using a (d)CDN that the necessary bandwidth between= two CDNs is NOT directly proportional to the number of active end-users? 3) In section 3. you refer to Long-tail personalized content. I'm not sure = what this means. Do you mean dynamic content that is being generated on a p= er-user basis by the uCDN or the CSP? If so, what would be the use case for= wanting to have this content be delivered by a dCDN? Wouldn't this defeat = the purpose of having a dCDN at all, since the content has to be delivered = on a per-user basis by the uCDN anyway? If the uCDN has to deliver the cont= ent to the dCDN for each individual user, wouldn't it be more efficient for= the uCDN to deliver this content to the end-user directly? Best regards, Ray This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer --_000_A1781B516C474C48AF21266534863EECtnonl_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

Hi Bhumip,


In response to your question during yesterday's CDNI meetin= g, I read your draft draft-krishnan-cdni-tm-has-00. 


Since I'm not an expert on TCP and the way router queues ar= e implemented, I can't comment on the more technical aspects of your draft.= However, when looking at the rationale behind the draft I have some questi= ons. 


If I understand your draft correctly, your main premise is = that in cases where HTTP Adaptive Streaming is used, the content acquisitio= n interface between the dCDN and uCDN (which in itself is out-of-scope of t= he WG) could become congested. I have a number of questions related to this:


1) What I don't understand from your draft is what the rela= tionship is between this supposed content congestion and the use of adaptiv= e streaming. Of course, in peak hours, there will generally be more traffic= across the link than outside peak hours. But isn't true regardless of the case of whether HAS is used or not= ? 


2) Furthermore, you state that "The bandwidth needs of= HAS is directly proportional to the number of active end users who are str= eaming video." Isn't the general idea behind using a (d)CDN that the n= ecessary bandwidth between two CDNs is NOT directly proportional to the number of active end-users?


3) In section 3. you refer to Long-tail personalized conten= t. I'm not sure what this means. Do you mean dynamic content that is being = generated on a per-user basis by the uCDN or the CSP? If so, what would be = the use case for wanting to have this content be delivered by a dCDN? Wouldn't this defeat the purpose of having= a dCDN at all, since the content has to be delivered on a per-user basis b= y the uCDN anyway? If the uCDN has to deliver the content to the dCDN for e= ach individual user, wouldn't it be more efficient for the uCDN to deliver this content to the end-user dir= ectly?


Best regards,


Ray



This e-mail and its contents are subject to the DISCLAIMER at http://www= .tno.nl/emaildisclaimer

--_000_A1781B516C474C48AF21266534863EECtnonl_-- From yang.r.yang@gmail.com Wed Aug 1 15:10:17 2012 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 7934C21F8775 for ; Wed, 1 Aug 2012 15:10:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.75 X-Spam-Level: X-Spam-Status: No, score=-2.75 tagged_above=-999 required=5 tests=[AWL=0.226, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 yxN7quzGL7Bb for ; Wed, 1 Aug 2012 15:10:16 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0E64621F8862 for ; Wed, 1 Aug 2012 15:10:14 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so14595280obb.31 for ; Wed, 01 Aug 2012 15:10:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=kFUuy+Arf3sYwjWlNZjC1BLpWLtu0wSmKAF2VN8hNx4=; b=RG7KkCNI1JZSHaLInz706nZJwIhQYP4/uSAkrW/lEin1Ohl3jkmKFyayPN6sM4uF6C MxFIlfeAgFhOIZQn7aEDIThCpUDxfuXG3etPJ2443Rxd4SFvI20EYCYf6oLzPtmRtE7K 5faIBy4ZGL2he8KmfohQWYo9/DQhyX4t3LGbW0Rcm5V2bFzicWSjbVkWTHm8ehBoxJTC CUSLyDaQP7NwJsRSI9RTMhOHsyJRj5WFMYxXCaXwLmNpTC2sU22yRMsdhZhNOoXy2PuI xbRJFBZtWZhSG5XTf0421LhfS4tp5i0DecZz2nXwuBnHmt4kHJLrgt8JMP/Uj+IKD1y9 wNHw== MIME-Version: 1.0 Received: by 10.60.22.165 with SMTP id e5mr31083593oef.60.1343859014567; Wed, 01 Aug 2012 15:10:14 -0700 (PDT) Sender: yang.r.yang@gmail.com Received: by 10.76.86.136 with HTTP; Wed, 1 Aug 2012 15:10:14 -0700 (PDT) In-Reply-To: References: <5018BF8D.4040506@cs.yale.edu> <5019559F.2040201@skytide.com> <50196373.3060805@cs.yale.edu> Date: Thu, 2 Aug 2012 06:10:14 +0800 X-Google-Sender-Auth: 52YRMYhTFvcq6yn32ciD8b1F43s Message-ID: From: "Y. Richard Yang" To: "Francois Le Faucheur (flefauch)" Content-Type: multipart/alternative; boundary=e89a8fb1ed3c31061104c63b8f27 Cc: "cdni@ietf.org" Subject: Re: [CDNi] comments on draft-lefaucheur-cdni-logging-delivery-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: Wed, 01 Aug 2012 22:10:17 -0000 --e89a8fb1ed3c31061104c63b8f27 Content-Type: text/plain; charset=ISO-8859-1 Hi Francois, I was thinking the typical http based UA (say in JavaScript) report. The setting is that the http report url will point to the uCDN who then direct to the dCDN. In the case of uCDN with limited cap, this reporting is delegated to dCDN as well. But of course QoE collection may not be a core service, and may even have a problem of conflict of interest. Looking more into the problem during rechartering makes sense to me. The idea of more server side metrics is interesting. I will look it up to share comments, if any. Thanks! Richard On Wednesday, August 1, 2012, Francois Le Faucheur (flefauch) wrote: > > On 1 Aug 2012, at 10:12, Y. Richard Yang wrote: > > Hi Roy, > > On 8/1/12 9:13 AM, Roy Peterkofsky wrote: > > > > On 7/31/2012 10:33 PM, Y. Richard Yang wrote: > > > - There are use cases to log client QoE, for example, freezing ratio and # > of freezing times. Such metrics may be only observable by the End User > Agent only. A dCDN may collect such data (from End User Agent) and report > to uCDN/CSP. > > > It is a good point that this metrics are of interest. > > > Glad you also agree that this is a type of metrics that ay have interest. > > It seems unlikely, however, that a dCDN would have control over the end > user agent. That would more typically be under the control of the CSP. > > It really depends on where the event handler(s) at the UA reports to. Some > CSPs may use a third party analytics service, but it can be natural that a > CDN provides this report as a part of the service. > > > While it is conceivable that CDNs could take on the role of > collecting/aggregating user agent QoE stats on behalf a CSP, I think this > is more of a value add service than a core delivery service. > Considering that: > * our charter guides us towards delivering first a base set of > capabilities in a fairly short timeframe > * the target date for delivering the CDNI Logging interface is _December > 2012_ > * supporting collection of user agent QoE Stats would involve a number of > interesting issues (e.g. what protocol does CDN uses to obtain the stats > from the enduser? how can the dCDN be authorized by CSP to collect stats > from CSP-controlled user agent considering the CSP may not have any > relationship with the dCDN and in fact may not even be ware of it?), > I recommend that we keep collection of user agent QoE stats on our list of > candidates for rechartering. > > But along the lines of improving the performance tracking through a CDNI > environment, a more modest but achievable goal may be for the CDNI Logs to > include a few more perf related fields that can be directly measured by the > Surrogate. I believe the DASH performance specs include several reference > points for measurement on the client side and the lowest level reference > point relates to transport/delivery: perhaps we could look at those and see > if we could extract a few meaningful perf metrics for which we could define > the mirror server-side metric. And allow inclusion of those in our CDNI > logs. > > Makes sense ? > > Thanks > > Francois > > > If it is the CDN who gets the reports and given that the uCDN delegates > to the dCDN (say due to limited capacity/footprint), it is less likely that > the uCDN is the reported target, but instead the uCDN. What do you think? > > Richard > > Therefore, I am not sure what value including this in the log format for > communication between dCDNs and uCDNs would bring. > > > > Thanks. > > Richard > > > > _______________________________________________ > CDNi mailing listCDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni > > > > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2012.0.2197 / Virus Database: 2437/5167 - Release Date: 07/31/12 > > > > -- > Roy Peterkofsky > Vice President, Product Management > Skytide -- the leader in Digital Media Performance Management > www.skytide.com > (510) 250-4284 > > Read our new white paper: The 4 Keys to Telco CDN Success > > > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > > > --e89a8fb1ed3c31061104c63b8f27 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Francois,

I was thinking the typical http based UA (s= ay in JavaScript) report. The setting is that the http report url will poin= t to the uCDN who then direct to the dCDN. In the case of uCDN with limited= cap, this reporting is delegated to dCDN as well. But of course QoE collec= tion may not be a core service, and may even have a problem of conflict of = interest. Looking more into the problem during rechartering makes sense to = me. The idea of more server side metrics is interesting. I will look it up = to share comments, if any.

Thanks!

Richard

On Wedn= esday, August 1, 2012, Francois Le Faucheur (flefauch) wrote:

On 1 Aug 2012, at 10:12, Y. Richard Yang wrote:

Hi Roy,

On 8/1/12 9:13 AM, Roy Peterkofsky wrote:


On 7/31/2012 10:33 PM, Y. Richard Yang wrote:

- There are use cases to log client QoE, for example, freezing ratio and # = of freezing times. Such metrics may be only observable by the End User Agen= t only. A dCDN may collect such data (from End User Agent) and report to uC= DN/CSP.

It is a good point that this metrics are of interest.

Glad you also agree that this is a type of metrics that ay have interest.
It seems unlikely, however, that a dCDN would hav= e control over the end user agent.=A0 That would more typically be under th= e control of the CSP.=A0
It really depends on where the event handler(s) at the UA reports to. Some = CSPs may use a third party analytics service, but it can be natural that a = CDN provides this report as a part of the service.

While it is conceivable that CDNs could take on the role of collecting= /aggregating user agent QoE stats on behalf a CSP, I think this is more of = a value add service than a core delivery service.=A0
Considering that:
* our charter guides us to= wards delivering first a base set of capabilities in a fairly short timefra= me
* the target date for deli= vering the CDNI Logging interface is _December 2012_
* supporting collection of= user agent QoE Stats would involve a number of interesting issues (e.g. wh= at protocol does CDN uses to obtain the stats from the enduser? how can the= dCDN be authorized by CSP to collect stats from CSP-controlled user agent considering the CSP= may not have any relationship with the dCDN and in fact may not even be wa= re of it?),
I recommend that we keep collection of user agent QoE stats on our lis= t of candidates for rechartering.=A0

But along the lines of improving the performance tracking through a CD= NI environment, a=A0more modest but achievable goal may be for the CDNI Log= s to include a few more perf related fields that can be directly measured b= y the Surrogate. I believe the DASH performance specs include several reference points for measurement on the = client side and the lowest level reference point relates to transport/deliv= ery: perhaps we could look at those and see if we could extract a few meani= ngful perf metrics for which we could define the mirror server-side metric. And allow inclusion of those i= n our CDNI logs.

Makes sense ?

Thanks

Francois


If it is the CDN who gets the rep= orts and given that the uCDN delegates to the dCDN (say due to limited capa= city/footprint), it is less likely that the uCDN is the reported target, bu= t instead the uCDN. What do you think?

Richard

Therefore, I am not sure what value including thi= s in the log format for communication between dCDNs and uCDNs would bring.<= br>


Thanks.

Richard



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


No virus found in this message.
Checked by AVG - www.avg.= com
Version: 2012.0.2197 / Virus Database: 2437/5167 - Release Date: 07/31/12



--
Roy Peterkofsky
Vice President, Product Management
Skytide -- the leader in Digital Media Performance Management
www.skytide.com (510) 250-4284

Read our new white paper: The 4 Keys to Telco CDN Success

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

--e89a8fb1ed3c31061104c63b8f27-- From li.mian@zte.com.cn Wed Aug 1 18:43:44 2012 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 68D2B11E8161; Wed, 1 Aug 2012 18:43:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -87.442 X-Spam-Level: X-Spam-Status: No, score=-87.442 tagged_above=-999 required=5 tests=[AWL=-8.449, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, GB_I_LETTER=-2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, URIBL_BLACK=20, 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 i-HEIKN14FAz; Wed, 1 Aug 2012 18:43:42 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id DB22411E811D; Wed, 1 Aug 2012 18:43:40 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 107232556518306; Thu, 2 Aug 2012 09:32:32 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 23705.5802358122; Thu, 2 Aug 2012 09:43:25 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q721hS4I088676; Thu, 2 Aug 2012 09:43:28 +0800 (GMT-8) (envelope-from li.mian@zte.com.cn) In-Reply-To: <002c01cd6fbb$b4532dd0$1cf98970$@com> To: , cdni@ietf.org, cdni-bounces@ietf.org, jin.weiyi@zte.com.cn, "'Bhumip Khasnabish'" MIME-Version: 1.0 X-KeepSent: 4400C062:0904E487-48257A4D:0033E6E1; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: li.mian@zte.com.cn Date: Thu, 2 Aug 2012 09:43:20 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-08-02 09:43:21, Serialize complete at 2012-08-02 09:43:21 Content-Type: multipart/alternative; boundary="=_alternative 0009782C48257A4E_=" X-MAIL: mse02.zte.com.cn q721hS4I088676 Subject: [CDNi] =?gb2312?b?tPC4tDogUkU6IFJlOiAgRndkOiBkcmFmdC1qaW4tY2Ru?= =?gb2312?b?aS1jb250ZW50LWRlZHVwbGljYXRpb24tb3B0aW1pemF0aW9uLTAyLnR4dA==?= 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, 02 Aug 2012 01:43:44 -0000 This is a multipart message in MIME format. --=_alternative 0009782C48257A4E_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 RGVhciBUaGVvZG9yZSwNCg0KVGhhbmsgeW91IGZvciB5b3VyIHF1aWNrIHJlc3BvbnNlIGFuZCBk ZXRhaWxlZCBleHBsYW5hdGlvbi4gUGxlYXNlIHNlZSBteSANCmZlZWRiYWNrIGJlbG93Og0KDQoN CiJUaGVvZG9yZSBaYWhhcmlhZGlzIiA8emFoYXJpYWRAc3luZWxpeGlzLmNvbT4g5YaZ5LqOIDIw MTItMDgtMDEgMTY6MDA6MjA6DQoNCj4gRGVhciBsaSwNCj4gTWF5YmUgbXkgcmVhY3Rpb24gd2Fz IGZhc3QgYW5kIEkgZGlkIG5vdCBleHBsYWluIGl0IHZlcnkgd2VsbC4NCj4gDQo+IFRoZSBwcm9w b3NhbCBpcyB0byBoYXZlIGEgdW5pcXVlIElEIG9mIHRoZSBjb250ZW50IChDSUQpIGNhbGN1bGF0 ZWQgDQo+IGZyb20gdGhlIGNvbnRlbnQgaXRzZWxmLg0KPiBMaWtlIGEgZmluZ2VycHJpbnQgb2Yg dGhlIGZpbGUsICh3aGljaCBpbiB0aGUgd29yc3QgY2FzZSBjb3VsZCBiZSANCj4gcmVjYWxjdWxh dGVkLCBidXQgaW4gdGhlIGdlbmVyYWwgIGNhc2Ugc2hvdWxkIG5vdCkuICANCj4gRS5nLg0KPiBB ICAyNTYgaGFzaCAob3IgYW5vdGhlciBsb3cgbGV2ZWwgZGVzY3JpcHRvcikgb24gdGhlIGNvbXBs ZXRlIA0KPiBjb250ZW50IG9mIHRoZSBmaWxlLg0KPiBPciBhIGNvbWJpbmF0aW9uIG9mIHRoZSBm aWxlIGNvbnRlbnQgYW5kIHRoZSBmaWxlIHNpemXigKYgKGFzIHRoZSBoYXNoDQo+IG1heSBiZSBv bmx5IDk5LDk5OSUgdW5pcXVlKQ0KPiBJbiB0aGlzIHdheSB5b3UgaGF2ZSBhbiBpZGVudGl0eSBv ZiB0aGUgY29udGVudCBmaWxlIGl0c2VsZi4NCj4gIFtMaSBNaWFuXTogc28gd2hpY2ggZW50aXR5 L3BhcnR5IHdvdWxkIGRvIHRoaXMgSEFTSCBjYWxjdWxhdGlvbiBhbmQgDQpnZW5lcmF0ZSB0aGUg VUlEIChDTS1DSUQtZmlsZW5hbWUueHl6KSwgdGhlIGNvbnRlbnQgcHJvdmlkZXIgb3IgdGhlIENE Tj8NCiAgIFtMaSBNaWFuXTogYWxzbyBpZiBDSUQgaXMgY2FsY3VsYXRlZCBvbiB0aGUgY29tcGxl dGUgY29udGVudCBvZiB0aGUgDQpmaWxlLCBpcyBpdCBjYWxjdWxhdGVkIG9uY2UgYW5kIGRlbGl2 ZXJkIHRocm91Z2ggb3V0IHRoZSBDRE5zIHdpdGhpbiBDRE5pIA0Kc2NvcGUgd2l0aG91dCByZS1j YWxjdWxhdGlvbj8gT3IgaXMgaXQgY2FsY3VsYXRlZCBldmVyeSB0aW1lIHRoZSBjb250ZW50IA0K ZW50ZXJzIGludG8gb25lIENETiwgZS5nLiBmcm9tIHVDRE4gdG8gZENETj8NCg0KPiBUaGUgc2Vj b25kIHN0ZXAgaXMgdG8gYWRkIHRoYXQgQ0lEIHRvIHRoZSBjb250ZW50IG5hbWUsIHNvIGl0IGlz IA0KPiBjYXJyaWVkIGluIHRoZSBuYW1lLg0KPiBTbyB5b3UgaGF2ZSBhIENVUkw6DQo+IGh0dHA6 Ly93d3cuc2VydmVyMS5jb20vLi4uL0NNLUNJRC1maWxlbmFtZS54eXoNCj4gIFtMaSBNaWFuXTog RG9lcyB0aGUgZW1iZWRkaW5nIG9mIENJRCBpbnRvIENVUkwgaGF2ZSBzb21lIHNlY3VyaXR5IGlz c3VlIA0Kb3Igc29tZSBsaW1pdGF0aW9uIHRvIHRoZSBVUkwgZXh0ZW5zaW9uPyBEbyB5b3UgaGF2 ZSBzb21lIG1vcmUgDQpjb25zaWRlcmF0aW9uIG9uIHRoaXM/DQoNCj4gV2hlbiBhIGZpbGUgY29u dGVudCBjaGFuZ2VzIENETiwgdGhlIG5hbWUgbWF5IHJlbWFpbiB0aGUgc2FtZSBvciBub3QuDQo+ IElmIHRoZSBkQ0ROIGZvbGxvd3MgdGhlIHJ1bGUsIGl0IG1heSBjaGFuZ2UgdG8gc29tZXRoaW5n IGxpa2U6DQo+IGh0dHA6Ly93d3cuc2VydmVyMi5jb20vLi4uL0NNLUNJRC1maWxlbmFtZTIueHl6 DQo+IEFzIHlvdSBzZWUgdGhlIENJRCBpcyBzdGlsbCBlbWJlZGRlZCBpbiB0aGUgbmFtZSBhbmQg Y2FuIGJlIHRoZSANCj4gaWRlbnRpdHkgb2YgdGhlIGNvbnRlbnQgZXZlbiBpZiB0aGUgcmVtYWlu aW5nIFVSTCBoYXMgY2hhbmdlZC4gDQo+IA0KPiBOb3cgbGV0c+KAmSBhc3N1bWUgdGhhdCBmb3Ig YSByZWFzb24gdGhlIGNvbnRlbnQgaXMgbW92ZWQgdG8gYSBkQ0ROIA0KPiB0aGF0IGRvZXMgbm90 IGZvbGxvdyB0aGUgcnVsZSwgaXQgY2hhbmdlcyBuYW1lIGFuZCB0aGVuIHRvIGFub3RoZXIgDQo+ IGRDRE4gdGhhdCBmb2xsb3dzIHRoZSBydWxlLiBUaGUgbmV3IGRDRE4gbWF5IGNhbGN1bGF0ZSBh bmQgDQo+IHJlZ2VuZXJhdGUgdGhlIENJRCBhbmQgdXNlIGl0IGFnYWluIGFzIHRoZSBjb250ZW50 IGtleSBpbmRleC4NCj4gIFtMaSBNaWFuXTogYS4gaWYgeW91IHdhbnQgdG8ga2VlcCB0aGUgQ0lE IHVuY2hhbmdlZCwgaS5lLiB0aGUgc2FtZSBhcyANCnRoZSBvcmlnaW5hbCBvbmUsIHlvdSBuZWVk IHRvIGd1YXJhbnRlZSB0aGUgY29uc2lzdGVuY3kgb2YgSEFTSCBhcml0aG1ldGljIA0KdGhyb3Vn aG91dCB0aGUgQ0ROaSBzY29wZSAnY296IGRpZmZlcmVudCBDRE5zIG1heSBoYXZlIGRpZmZlcmVu dCBIQVNIIA0KY2FsY3VsYXRpbmcgcmVzdWx0cy4gYW5kIHRoaXMsIHRvIG1lLCBtYXkgbm90IGJl IGFuIGVhc3kgd29yazsgYi4gdGhlIENJRCANCmlzIGdlbmVyYXRlZCBiYXNlZCBvbiB0aGUgY29t cGxldGUgZG93bmxvYWQgb2YgdGhlIHdob2xlIGNvbnRlbnQuIFNvIHlvdSANCm5lZWQgdG8gZmlu aXNoIGRvd25sb2FkaW5nIG9mIHRoZSBjb250ZW50IGJlZm9yZSB5b3UgZ2VuZXJhdGUgdGhlIENJ RCBhbmQgDQpjaGVjayB3aGV0aGVyIHRoaXMgY29udGVudCBpcyBhbHJlYWR5IHN0b3JlZCBpbiB0 aGlzIENETi4gVGhpcywgdG8gc29tZSANCmV4dGVudCwgZG9lcyBub3QgaW1wcm92ZSB0aGUgZWZm aWNpZW5jeSBvZiBjb250ZW50IGRlLWR1cGxpY2F0aW9uLiBIb3cgZG8gDQp5b3UgdGhpbms/DQpb TGkgTWlhbl06IGluIG91ciBjb250ZW50IGRlLWR1cGxpY2F0aW9uIGRyYWZ0LCB3ZSBhbHdheXMg ZXhjaGFuZ2UgYW5kIA0KY2hlY2sgdGhlIGV4aXN0ZW5jZSBvZiBvbmUgY29udGVudCBvYmplY3Qg YnkgdXNpbmcgdGhlIGNvbnRlbnQgDQppZGVudGlmaWNhdGlvbiBtb2RlbCBiZWZvcmUgdGhlIGFj dHVhbCBjb250ZW50IGl0ZW0gaXMgZG93bmxvYWQsIHdoaWNoIG1heSANCmhhdmUgYmV0dGVyIGVm ZmljaWVuY3kuDQoNCj4gTm93IGxldHPigJkgbW92ZSB0byB0aGUgY2xpZW50cy4gDQo+IElmIHRo ZSBNRFAgZmlsZSAodXNpbmcgREFTSCBzdHJlYW1pbmcpIG9yIHRoZSBodHRwIHBhZ2UgY29udGFp bnMgDQo+IHRoaXMgQ1VSTCwgdGhlIENETiBjYW4gZGlyZWN0bHkgZXh0cmFjdCB0aGUgQ0lEIChh cyBpdCBmb2xsb3dzIHRoZSANCj4gQ00g4oCcbWFnaWMgd29yZOKAnSksIGxvb2sgZm9yIGl0IHVz aW5nIHRoaXMgQ0lEIGFuZCBpZ25vcmUgdGhlIA0KPiByZW1haW5pbmcgVVJMLiBJZiBmb3IgYSBy ZWFzb24gdGhlIGZpbGUgaXMgbm90IGluIHRoZSBDRE4gYW5kIGNhbuKAmXQgDQo+IGJlIGZvdW5k IGF0IHRoZSBvdGhlciBDRE5zLCBpdCBpcyB2ZXJ5IHNpbXBsZSBmb3IgdGhlIENETiB0byByZW1v dmUgDQo+IHRoZSBDTS1DSUQsIHJlZ2VuZXJhdGUgdGhlIG9yaWdpbmFsIFVSTCBhbmQgcmVxdWVz dCBpdCBmcm9tIHRoZSANCj4gb3JpZ2luYWwgd2ViIHNpdGUuDQo+ICBbTGkgTWlhbl06IHNvIGhv dyBjb3VsZCB0aGUgQ0ROIGNoZWNrIHRoZSBjb250ZW50IGlzIG5vdCBmb3VuZCBhdCB0aGUgDQpv dGhlciBDRE5zPyBJbiBjdXJyZW50IGltcGxlbWVudGF0aW9uIGluIGZyYW1ld29yayBkcmFmdCwg dGhlIGRDRE4gb25seSANCmFjcXVpcmVzIGNvbnRlbnQgZnJvbSB1Q0ROIHRoYXQgcmVkaXJlY3Rz IHRoZSB1c2VyJ3MgcmVxdWVzdCB0byBpdC4NCg0KPiBUaGlzIGlzIHNvbWUgZXhwZXJpbWVudGF0 aW9uIHRoYXQgd2UgaGF2ZSBkb25lIGluIHRoZSBwcm9qZWN0IENPQVNUICgNCj4gd3d3LmNvYXN0 LWZwNy5ldSkgYW5kIHRoZSBuYW1pbmcgc2NoZW1lIGlzIGFsc28gZXhwbGFpbmVkIGluIHRoZSBU aC4NCj4gWmFoYXJpYWRpcywgRS4gUXVhY2NoaW8sIOKAnEZhc3QgY29udGVudC1hd2FyZSBkZWxp dmVyeSBpbiBvdmVybGF5IA0KPiBuZXR3b3JrcyzigJ0gSUVFRSBDT01TT0MgTU1UQyBFLUxldHRl ciwgVm9sLjYsIE5vLiA3LCBKdWx5IDIwMTEsIHBwLiANCjQ0LTQ3DQo+IChodHRwOi8vY29tbWl0 dGVlcy5jb21zb2Mub3JnL21tYy9lLW5ld3MvRS1MZXR0ZXItSnVseTExLnBkZiAgcGFnZSANCjQ0 LTQ3KSAgDQo+W0xpIE1pYW5dOiB0aGFuayB5b3UsIEkgd2lsbCByZWFkIHRoZW0gaW4gZGV0YWls LiANCg0KPiBCZXN0IFJlZ2FyZHMsDQo+IFRoZW9kb3JlDQo+IA0KPiANCj4gDQo+IA0KPiBGcm9t OiBsaS5taWFuQHp0ZS5jb20uY24gW21haWx0bzpsaS5taWFuQHp0ZS5jb20uY25dIA0KPiBTZW50 OiBXZWRuZXNkYXksIEF1Z3VzdCAwMSwgMjAxMiA5OjUyIEFNDQo+IFRvOiB6YWhhcmlhZEBzeW5l bGl4aXMuY29tOyBjZG5pQGlldGYub3JnOyBjZG5pLWJvdW5jZXNAaWV0Zi5vcmc7IA0KPiAnQmh1 bWlwIEtoYXNuYWJpc2gnOyBqaW4ud2VpeWlAenRlLmNvbS5jbg0KPiBTdWJqZWN0OiDnrZTlpI06 IFJlOiBbQ0ROaV0gRndkOiBkcmFmdC1qaW4tY2RuaS1jb250ZW50LWRlZHVwbGljYXRpb24tDQo+ IG9wdGltaXphdGlvbi0wMi50eHQNCj4gDQo+IA0KPiBEZWFyIFRoZW9kb3JlLCANCj4gDQo+IFRo YW5rIHlvdSBmb3IgeW91ciBjb21tZW50cyBhbmQgc2hhcmluZyB3aXRoIHVzIHlvdXIgcHJvcG9z YWxzLiANCj4gQ291bGQgeW91IHBsZWFzZSBzaGFyZSB0aGUgZG9jdW1lbnRzIHlvdSBtZW50aW9u ZWQgYmVsb3cgd2l0aCBtZT8gDQo+IEJhc2VkIG9uIHdoYXQgeW91IGV4cGxhaW5lZCBpbiBwcmV2 aW91cyBlbWFpbCwgSSBoYXZlIHNvbWUgcXVlc3Rpb25zDQo+IGZvciBjbGFyaWZpY2F0aW9uOiAN Cj4gMS4gV2UgYm90aCBjb25zaWRlciBpdCBuZWNlc3NhcnkgdG8gaGF2ZSBhIHVuaXF1ZSBjb250 ZW50IGlkZW50aWZpZXINCj4gZm9yIGEgY29udGVudCBvYmplY3QuIE91ciBvcGluaW9uIGluIHRo aXMgZHJhZnQgaXMgdGhhdCB0aGlzIGNvbnRlbnQNCj4gSUQgaXMgQ1NQLXVuaXF1ZS4gQ291bGQg eW91IHBsZWFzZSBleHBsYWluIG1vcmUgYWJvdXQgdGhlIHVuaXF1ZW5lc3MNCj4gb2YgdGhlIFVJ RCBpbiB5b3VyIHByb3Bvc2FsPyANCj4gMi4gQnkgYXBwbHlpbmcgdGhlIG1lY2hhbmlzbSB5b3Ug cHJvcG9zZWQgYmVsb3csIHdlIGNhbiBndWFyYW50ZWUgDQo+IHRoZSBjb250ZW50IGlzIHVuaXF1 ZWx5IHN0b3JlZCBpbiBvbmUgQ0ROLiBBbmQgYWNjb3JkaW5nIHRvIG15IA0KPiBhbmFseXNpcyBv biB0aGUgYmFzaXMgb2YgeW91ciBleHBsYW5hdGlvbiwgdGhlIGNvbnRlbnQgcmVwbGljYXRpb24g DQo+IGlzIGNoZWNrZWQgYnkgY29tcGFyaW5nIHRoZSBDVVJMIHdoaWNoIGlzIHNpbWlsYXIgdG8g dGhlIGN1cnJlbnQgDQo+IG1lY2hhbmlzbSBpbiBDRE5pIHdvcmssIGNvcnJlY3QgbWUgaWYgbXkg dW5kZXJzdGFuZGluZyBpcyB3cm9uZy4gSWYgDQo+IHNvLCB3aGVuIHJlZGlyZWN0aW9uIG9jY3Vy cyBiZXR3ZWVuIHVDRE5zIGFuZCBkQ0ROLCB0aGUgVVJMIHdvdWxkIGJlDQo+IGNoYW5nZWQgYW5k IHRodXMgYmUgZGlmZmVyZW50IHdpdGggdGhlIG9yaWdpbmFsIG9uZSAtIENVUkwuIEFuZCBpZiBh DQo+IGRDRE4gaXMgY29ubmVjdGVkIHdpdGggdHdvIGRpZmZlcmVudCB1Q0ROcyBhbmQgdHdvIGVu ZCB1c2VycyByZXF1ZXN0DQo+IHRoZSBzYW1lIGNvbnRlbnQgZnJvbSB0aGVzZSB0d28gdUNETnMg cmVzcGVjdGl2ZWx5LCB0aGUgdHdvIHVDRE5zIA0KPiBtYXkgZ2VuZXJhdGUgZGlmZmVyZW50IHJl ZGlyZWN0aW9uIFVSTHMgdG8gdGhlIGRDRE4uIEluIHRoaXMgY2FzZSB3ZQ0KPiB0aGluayB0aGUg Y29udGVudCBkdXBsaWNhdGlvbiBpc3N1ZSBzdGlsbCBleGlzdHMuIEhvdyBkbyB5b3UgdGhpbms/ IA0KPiBJZiBteSB1bmRlcnN0YW5kaW5nIGlzIHdyb25nLCBjb3VsZCB5b3UgcGxlYXNlIGV4cGxh aW4gbW9yZSBvbiBob3cgDQo+IHRvIGNvbnNpZGVyIHRoaXMgaXNzdWUgYnkgdXNpbmcgeW91ciBw cm9wb3NhbD8gDQo+IA0KPiBUaGFuayB5b3UgYWdhaW5+IA0KPiANCj4gY2RuaS1ib3VuY2VzQGll dGYub3JnIOWGmeS6jiAyMDEyLTA4LTAxIDAyOjAwOjIzOg0KPiANCj4gPiBEZWFyIEJodW1pcCwg DQo+ID4gDQo+ID4gU29tZSBpZGVhcyBhbmQgY29uc2lkZXJhdGlvbnMgb24gdGhlIGRyYWZ0LiAN Cj4gPiANCj4gPiBXZSBoYXZlIGRvbmUgc29tZSB3b3JrIGluIHRoZSBhcmVhIG9mIGRlLWR1cGxp Y2F0aW9uIG9mIGNvbnRlbnQgDQo+ID4gKFBsZWFzZSBzZWUgVGguIFphaGFyaWFkaXMsIEUuIFF1 YWNjaGlvLCDigJxGYXN0IGNvbnRlbnQtYXdhcmUgDQo+ID4gZGVsaXZlcnkgaW4gb3ZlcmxheSBu ZXR3b3JrcyzigJ0gSUVFRSBDT01TT0MgTU1UQyBFLUxldHRlciwgVm9sLjYsIE5vLg0KPiA+IDcs IEp1bHkgMjAxMSwgcHAuIDQ0LTQ3KSkgDQo+ID4gDQo+ID4gQWN0dWFsbHksIHdlIGJlbGlldmUg dGhhdCBpdCBpcyBuZWVkZWQgdG8gZGVmaW5lIFVuaXF1ZSBJRHMgKFVJRCkgDQo+ID4gcGVyIGNv bnRlbnQgb2JqZWN0L2NodW5rIGluIG9yZGVyIHRvOiANCj4gPiBhKSBBdm9pZCBleHRlbmRlZCBk YXRhIHJlcGxpY2F0aW9ucyBhdCB0aGUgQ0ROIGxldmVsIGFuZCBtaW5pbWl6ZSANCj4gPiB0aGUg bG9hZCB0byBmaW5kIHRoZSBjb3JyZWN0IG9iamVjdC4gDQo+ID4gYikgRGV0ZWN0IGFuZCByZXRy aWV2ZSB2ZXJ5IGZhc3QgdGhlIGNvbnRlbnQuIFRoaXMgc2hvdWxkIGJlIGZhc3QgDQo+ID4gZW5v dWdoIHRvIGFsbG93IGV2ZW4gc2VhbWxlc3MgcmVhbC10aW1lIHZpZGVvIHN0cmVhbWluZyBieSAN Cj4gPiByZXRyaWV2aW5nIHZpZGVvIGNodW5rcyANCj4gPiBjKSBCZSBiYWNrd2FyZHMgY29tcGF0 aWJsZSB3aXRoIHRvZGF5c+KAmSBVUkxzIChpbiBjYXNlIHRoZSANCj4gPiBjb250ZW50L2NodW5r IGlzIG5vdCBmb3VuZCwgeW91IHNob3VsZCBiZSBhYmxlIHRvIGdvIHRvIHRoZSBvcmlnaW5hbCAN CnNpdGUpLg0KPiA+IA0KPiA+IEluIG9yZGVyIHRvIG1lZXQgdGhlIChhKSwgVUlEIHNob3VsZCBi ZSBhbHdheXMgYXNzb2NpYXRlZCB3aXRoIHRoZSANCj4gPiBjb250ZW50IG9iamVjdCBpdHNlbGYg KGUuZy4gZW5jYXBzdWxhdGVkIGluIHRoZSBvYmplY3QpIG9yIGJlIGJhc2VkIA0KPiA+IG9uIHVu aXF1ZSBjaGFyYWN0ZXJpc3RpY3Mgb2YgdGhlIGNvbnRlbnQgb2JqZWN0IChlLmcuIGEgc2V0IG9m IGxvdyANCj4gPiBsZXZlbCBkZXNjcmlwdG9ycykuIEhvd2V2ZXIsIChiKSwgcG9zZXMgdGhhdCB0 aGlzIGNvdWxkIGJlIA0KPiA+IGNhbGN1bGF0ZWQgb25jZSAob3Igc29tZXRpbWVzKSwgYnV0IHNo b3VsZCBub3QgYmUgY2FsY3VsYXRlZCBvciANCj4gPiBnZW5lcmF0ZWQgZWFjaCB0aW1lIHRoZSBv YmplY3QgaXMgcmVxdWVzdGVkOyBpbnN0ZWFkIGl0IHNob3VsZCBiZSANCj4gPiDigJxjYXJyaWVk 4oCdIGFuZCDigJxleHRyYWN0ZWTigJ0gaW4gbW9zdCBjYXNlcy4gIE9uIHRoZSBvdGhlciBoYW5k LCBkdWUgDQp0byANCj4gPiBiYWNrd2FyZHMgY29tcGF0aWJpbGl0eSBuZWVkcyAoYyksIHdlIHNo b3VsZCBub3QgY2hhbmdlIHRoZSBzdGFuZGFyZA0KPiA+IGZpbGUgZm9ybWF0IChlLmcuIHdlIGNv dWxkIG5vdCBlbmNhcHN1bGF0ZSBVSUQgb3IgbG93IGxldmVsIA0KPiA+IGRlc2NyaXB0b3IgaW4g dGhlIGNvbnRlbnQgb2JqZWN0KS4gDQo+ID4gDQo+ID4gT25lIHNvbHV0aW9uIGNvdWxkIGJlIHRv IGNyZWF0ZSBhIHdyYXBwZXIgdGhhdCB3b3VsZCBlbmNhcHN1bGF0ZSB0aGUNCj4gPiBVSUQgd2hl bmV2ZXIgdGhlIGNvbnRlbnQgb2JqZWN0IGVudGVycyB0aGUgQ0ROIGFuZCBleHRyYWN0cyB0aGF0 IGF0IA0KPiA+IHRoZSB0aW1lIHRoYXQgdGhlIGNvbnRlbnQgb2JqZWN0IGxlYXZlcyB0aGUgQ0RO LCBidXQgdGhpcyB3b3VsZCANCj4gPiBpbmNyZWFzZSB0aGUgY29tcGxleGl0eSBhbmQgcHJvY2Vz c2luZyB0aW1lLiANCj4gPiANCj4gPiBJbnN0ZWFkLCB3ZSBwcm9wb3NlIHRvIHVzZSBhcyBVSUQg YSBmb3JtYWwgZmlsZSBuYW1lIGZvcm1hdC4gVUlEIA0KPiA+IHdpbGwgYmUgYSBzdHJpbmcgY29u Y2F0ZW5hdGlvbiBpbiB0aGUgZm9ybWF0OiANCj4gPiANCj4gPiBDTS1DSUQtZmlsZW5hbWUuZXh0 IA0KPiA+IA0KPiA+IHdoZXJlOiANCj4gPiDigKIgQ00gaXMgYSDigJxDb250ZW50IE1hcmtlcuKA nSANCj4gPiDigKIgQ0lEIGlzIGEgY29udGVudCBzaWduYXR1cmUsIHdoaWNoIGNvdWxkIGJlIGEg c2VsZi1jZXJ0aWZ5aW5nIA0KPiA+IGlkZW50aWZpZXIgZS5nLiBNRDUgb3IgU0hBLTEgYmFzZWQt aGFzaCBmdW5jdGlvbiBvbiB0aGUgZmlsZSdzIA0KPiA+IGNvbnRlbnQgb3IgZXZlbiBhIGNvbWJp bmF0aW9uIG9mIHNlYXJjaGFibGUgbG93IGxldmVsIGRlc2NyaXB0b3JzLiAsDQo+ID4gd2hpY2gg Z3VhcmFudGVlcyBhbiBlYXN5IGFuZCBmYXN0IGRldGVjdGlvbiB0aGF0IHRoaXMgbmFtZSBpcyBh IFVJRCANCj4gPiDigKIgdGhlIG9yaWdpbmFsIGZpbGVuYW1lLCB3aGljaCBpcyB1c2VkIGZvciBt YWtpbmcgVUlEIGVhc2lseSANCj4gPiByZWNvZ25pemVkIGJ5IGh1bWFucyBhbmQgYXZvaWQgY29t cGxleCBzZWxmLWNlcnRpZnlpbmcgbmFtZXMuIA0KPiA+IA0KPiA+IFdoZW5ldmVyIG5ldyBjb250 ZW50IGlzIHB1Ymxpc2hlZCBvciBzdG9yZWQgYXQgdGhlIENETiwgdGhlIG9iamVjdCANCj4gPiBm aWxlbmFtZSBjb3VsZCBiZSByZW5hbWVkIHRvIGEgVUlEIGFuZCB0aGUgVVJMIHRvIGEgQ29udGVu dCBVUkwgDQo+ID4gKENVUkwpIHdpdGggdGhlIA0KPiA+IGZvbGxvd2luZyBmb3JtYXQ6IA0KPiA+ IA0KPiA+IGh0dHA6Ly93d3cuIHdlYnNpdGUuY29tL+KApi9DTS1DSUQtZmlsZW5hbWUuZXh0IA0K PiA+IA0KPiA+IFRoZSBDVVJMIGlzIGEgVVJJLCB3aGljaCBpcyBkZXNpZ25lZCB0byBlbmFibGUg Y2FjaGluZyBtZWNoYW5pc21zIA0KPiA+IGFuZCB0cmlnZ2VyIENETi1yZWxhdGVkIGZ1bmN0aW9u YWxpdHkgKGUuZy4gYWNjZXNzaW5nIHRoZSBDRE4gDQo+ID4gb3ZlcmxheSBuZXR3b3JrIGFuZCBx dWVyeWluZyBmb3IgbG9jYWxseSBvciDigJxuZWFyYnnigJ0gY2FjaGVkIA0KPiA+IGNvbnRlbnQp LiBJdCBzaG91bGQgYWxzbyBiZSBlbXBoYXNpemVkIHRoYXQgZnJvbSB0aGUgQ1VSTCwgdGhlIA0K PiA+IG9yaWdpbmFsIFVSTCBhbmQgdGhlIFVJRCBtYXkgYmUgZWFzaWx5IGV4dHJhY3RlZCwgd2hp bGUgb24gdGhlIG90aGVyDQo+ID4gaGFuZCBpdCBpcyBmdWxseSBiYWNrd2FyZHMgY29tcGF0aWJs ZSB3aXRoIGV4aXN0aW5nIGJyb3dzZXJzIGFuZCBubyANCj4gPiBtb2RpZmljYXRpb25zIGFyZSBu ZWVkZWQuIEluIHRoaXMgd2F5LCB3ZSBtYXkgc2VhbWxlc3NseSBzdXBwb3J0IGFueQ0KPiA+IGtp bmQgb2YgZGF0YSBhdmFpbGFibGUgaW4gdGhlIEludGVybmV0ICh0ZXh0LCBpbWFnZXMsIHZhcmlv dXMgdHlwZXMgDQo+ID4gb2YgYXVkaW8gb3IgdmlkZW8pLCB3aGlsZSBpbiBjYXNlIHRoZSBjb250 ZW50IG9iamVjdCBpcyBub3QgY2FjaGVkIA0KPiA+IGluIHRoZSBDRE4sIHdlIGNhbiBhbHdheXMg Z28gYmFjayB0byB0aGUgb3JpZ2luYWwgc291cmNlIFVSTC4gDQo+ID4gDQo+ID4gQmVzdCByZWdh cmRzLCANCj4gPiBUaGVvZG9yZSANCj4gPiANCj4gPiBGcm9tOiBjZG5pLWJvdW5jZXNAaWV0Zi5v cmcgW21haWx0bzpjZG5pLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiANCk9mIA0KPiA+IEJo dW1pcCBLaGFzbmFiaXNoDQo+ID4gU2VudDogVHVlc2RheSwgSnVseSAzMSwgMjAxMiA4OjQ0IFBN DQo+ID4gVG86IGNkbmlAaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBbQ0ROaV0gRndkOiBkcmFmdC1q aW4tY2RuaS1jb250ZW50LWRlZHVwbGljYXRpb24tDQo+IG9wdGltaXphdGlvbi0wMi50eHQgDQo+ ID4gDQo+ID4gDQo+ID4gVG86IGktZC1hbm5vdW5jZSBhdCBpZXRmLm9yZyANCj4gPiBTdWJqZWN0 OiBJLUQgQWN0aW9uOiBkcmFmdC1qaW4tY2RuaS1jb250ZW50LWRlZHVwbGljYXRpb24tDQo+IG9w dGltaXphdGlvbi0wMi50eHQgDQo+ID4gRnJvbTogaW50ZXJuZXQtZHJhZnRzIGF0IGlldGYub3Jn IA0KPiA+IERhdGU6IFN1biwgMjkgSnVsIDIwMTIgMTk6Mjk6MTQgLTA3MDAgDQo+ID4gRGVsaXZl cmVkLXRvOiBpLWQtYW5ub3VuY2UgYXQgaWV0ZmEuYW1zbC5jb20gDQo+ID4gTGlzdC1hcmNoaXZl OiA8aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2ktZC1hbm5vdW5jZT4gDQo+ ID4gTGlzdC1oZWxwOiA8bWFpbHRvOmktZC1hbm5vdW5jZS1yZXF1ZXN0QGlldGYub3JnP3N1Ympl Y3Q9aGVscD4gDQo+ID4gTGlzdC1pZDogSW50ZXJuZXQgRHJhZnQgQW5ub3VuY2VtZW50cyBvbmx5 IDxpLWQtYW5ub3VuY2UuaWV0Zi5vcmc+IA0KPiA+IExpc3QtcG9zdDogPG1haWx0bzppLWQtYW5u b3VuY2VAaWV0Zi5vcmc+IA0KPiA+IExpc3Qtc3Vic2NyaWJlOiA8aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2U+LCANCjwNCj4gPiBtYWlsdG86aS1kLWFu bm91bmNlLXJlcXVlc3RAaWV0Zi5vcmc/c3ViamVjdD1zdWJzY3JpYmU+IA0KPiA+IExpc3QtdW5z dWJzY3JpYmU6IDxodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL29wdGlvbnMvaS1kLWFubm91 bmNlPiwgDQo8DQo+ID4gbWFpbHRvOmktZC1hbm5vdW5jZS1yZXF1ZXN0QGlldGYub3JnP3N1Ympl Y3Q9dW5zdWJzY3JpYmU+IA0KPiA+IFJlcGx5LXRvOiBpbnRlcm5ldC1kcmFmdHMgYXQgaWV0Zi5v cmcgDQo+ID4gDQo+ID4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhl IG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIA0KPiA+IGRpcmVjdG9yaWVzLiANCj4gPiANCj4gPiAN Cj4gPiAgICAgICAgIFRpdGxlICAgICAgICAgICA6IENvbnRlbnQgRGUtZHVwbGljYXRpb24gZm9y IENETmkgT3B0aW1pemF0aW9uIA0KDQo+ID4gICAgICAgICBBdXRob3IocykgICAgICAgOiBXZWlZ aSBKaW4gDQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICBNaWFuIExpIA0KPiA+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgQmh1bWlwIEtoYXNuYWJpc2ggDQo+ID4gICAgICAgICBGaWxl bmFtZSAgICAgICAgOiBkcmFmdC1qaW4tY2RuaS1jb250ZW50LWRlZHVwbGljYXRpb24tDQo+ID4g b3B0aW1pemF0aW9uLTAyLnR4dCANCj4gPiAgICAgICAgIFBhZ2VzICAgICAgICAgICA6IDE3IA0K PiA+ICAgICAgICAgRGF0ZSAgICAgICAgICAgIDogMjAxMi0wNy0yOSANCj4gPiANCj4gPiBBYnN0 cmFjdDogDQo+ID4gICAgUmVjZW50IGV4cGxvc2l2ZSBncm93dGggb2YgY29udGVudCBkZWxpdmVy eS9kaXN0cmlidXRpb24gbmV0d29ya3MgDQo+ID4gICAgKENETnMpIGFuZCB0aGVpciBpbnRlcmNv bm5lY3Rpb24gYXJlIGNhdXNpbmcgdW5pbnRlbmRlZCByZXBldGl0aW9uIA0Kb2YgDQo+ID4gICAg Y29udGVudCBzdG9yYWdlIGluIHRoZSBzYW1lIGRDRE4uICBUaGlzIGNhbiBiZSBhdm9pZGVkIGJ5 IHVzaW5nIGEgDQo+ID4gICAgc3VpdGFibGUgZGUtZHVwbGljYXRpb24gbWVjaGFuaXNtLiAgVGhp cyBkb2N1bWVudCBleHBsb3JlcyB0aGUgDQo+ID4gICAgc2NlbmFyaW9zIHdoaWNoIGNyZWF0ZSB0 aGUgcHJvYmxlbXMsIGFuZCB0aGVuIGRpc2N1c3NlcyB0aGUgDQo+ID4gICAgYXBwcm9hY2hlcyB0 byBlbGltaW5hdGUgdGhlIGR1cGxpY2F0ZWQgdHJhbnNtaXNzaW9uIG9mIHRoZSBzYW1lIA0KPiA+ ICAgIGNvbnRlbnQgZnJvbSB1Q0ROKHMpIHRvIGRDRE4gaW4gQ0ROaSBuZXR3b3Jrcy4gIFRvIGlt cGxlbWVudCB0aGUgDQo+ID4gICAgb3B0aW1pemF0aW9uLCBzb21lIGVuaGFuY2VtZW50cyB0byB0 aGUgQ0ROaSBtZXRhZGF0YSBtb2RlbCBhbmQgDQo+ID4gICAgaW50ZXJmYWNlIGFyZSByZXF1aXJl ZC4gDQo+ID4gDQo+ID4gDQo+ID4gVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9y IHRoaXMgZHJhZnQgaXM6IA0KPiA+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWppbi1jZG5pLWNvbnRlbnQtDQo+ID4gZGVkdXBsaWNhdGlvbi1vcHRpbWl6YXRpb24gDQo+ ID4gDQo+ID4gVGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6IA0K PiA+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWppbi1jZG5pLWNvbnRlbnQtZGVk dXBsaWNhdGlvbi0NCj4gPiBvcHRpbWl6YXRpb24tMDIgDQo+ID4gDQo+ID4gQSBkaWZmIGZyb20g cHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6IA0KPiA+IGh0dHA6Ly90b29scy5pZXRm Lm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtamluLWNkbmktY29udGVudC0NCj4gPiBkZWR1cGxpY2F0 aW9uLW9wdGltaXphdGlvbi0wMiANCj4gPiANCj4gPiANCj4gPiBJbnRlcm5ldC1EcmFmdHMgYXJl IGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6IA0KPiA+IGZ0cDovL2Z0cC5pZXRm Lm9yZy9pbnRlcm5ldC1kcmFmdHMvIA0KPiA+ICBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiA+IENETmkgbWFpbGluZyBsaXN0DQo+ID4gQ0ROaUBpZXRm Lm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2RuaQ0K --=_alternative 0009782C48257A4E_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDAwODAgZmFjZT0ic2Fucy1zZXJpZiI+RGVhciBU aGVvZG9yZSw8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDAwODAgZmFj ZT0ic2Fucy1zZXJpZiI+VGhhbmsgeW91IGZvciB5b3VyIHF1aWNrDQpyZXNwb25zZSBhbmQgZGV0 YWlsZWQgZXhwbGFuYXRpb24uIFBsZWFzZSBzZWUgbXkgZmVlZGJhY2sgYmVsb3c6PC9mb250Pg0K PGJyPg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+JnF1b3Q7VGhlb2RvcmUgWmFoYXJpYWRp cyZxdW90OyAmbHQ7emFoYXJpYWRAc3luZWxpeGlzLmNvbSZndDsNCuWGmeS6jiAyMDEyLTA4LTAx IDE2OjAwOjIwOjxicj4NCjxicj4NCiZndDsgRGVhciBsaSw8L2ZvbnQ+PC90dD4NCjxicj48dHQ+ PGZvbnQgc2l6ZT0yPiZndDsgTWF5YmUgbXkgcmVhY3Rpb24gd2FzIGZhc3QgYW5kIEkgZGlkIG5v dCBleHBsYWluDQppdCB2ZXJ5IHdlbGwuPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9 Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBUaGUg cHJvcG9zYWwgaXMgdG8gaGF2ZSBhIHVuaXF1ZSBJRCBvZiB0aGUgY29udGVudA0KKENJRCkgY2Fs Y3VsYXRlZCA8YnI+DQomZ3Q7IGZyb20gdGhlIGNvbnRlbnQgaXRzZWxmLjwvZm9udD48L3R0Pg0K PGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBMaWtlIGEgZmluZ2VycHJpbnQgb2YgdGhlIGZpbGUs ICh3aGljaCBpbiB0aGUNCndvcnN0IGNhc2UgY291bGQgYmUgPGJyPg0KJmd0OyByZWNhbGN1bGF0 ZWQsIGJ1dCBpbiB0aGUgZ2VuZXJhbCAmbmJzcDtjYXNlIHNob3VsZCBub3QpLiAmbmJzcDs8L2Zv bnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgRS5nLjwvZm9udD48L3R0Pg0KPGJy Pjx0dD48Zm9udCBzaXplPTI+Jmd0OyBBICZuYnNwOzI1NiBoYXNoIChvciBhbm90aGVyIGxvdyBs ZXZlbCBkZXNjcmlwdG9yKQ0Kb24gdGhlIGNvbXBsZXRlIDxicj4NCiZndDsgY29udGVudCBvZiB0 aGUgZmlsZS48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgT3IgYSBjb21i aW5hdGlvbiBvZiB0aGUgZmlsZSBjb250ZW50IGFuZCB0aGUNCmZpbGUgc2l6ZeKApiAoYXMgdGhl IGhhc2g8YnI+DQomZ3Q7IG1heSBiZSBvbmx5IDk5LDk5OSUgdW5pcXVlKTwvZm9udD48L3R0Pg0K PGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBJbiB0aGlzIHdheSB5b3UgaGF2ZSBhbiBpZGVudGl0 eSBvZiB0aGUgY29udGVudA0KZmlsZSBpdHNlbGYuPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250 IHNpemU9Mj4mZ3Q7IDwvZm9udD48L3R0Pjx0dD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZT4mbmJz cDtbTGkNCk1pYW5dOiBzbyB3aGljaCBlbnRpdHkvcGFydHkgd291bGQgZG8gdGhpcyBIQVNIIGNh bGN1bGF0aW9uIGFuZCBnZW5lcmF0ZQ0KdGhlIFVJRCAoQ00tQ0lELWZpbGVuYW1lLnh5eiksIHRo ZSBjb250ZW50IHByb3ZpZGVyIG9yIHRoZSBDRE4/PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250 IHNpemU9MiBjb2xvcj1ibHVlPiZuYnNwOyAmbmJzcDtbTGkgTWlhbl06IGFsc28gaWYgQ0lEIGlz DQpjYWxjdWxhdGVkIG9uIHRoZSBjb21wbGV0ZSBjb250ZW50IG9mIHRoZSBmaWxlLCBpcyBpdCBj YWxjdWxhdGVkIG9uY2UgYW5kDQpkZWxpdmVyZCB0aHJvdWdoIG91dCB0aGUgQ0ROcyB3aXRoaW4g Q0ROaSBzY29wZSB3aXRob3V0IHJlLWNhbGN1bGF0aW9uPw0KT3IgaXMgaXQgY2FsY3VsYXRlZCBl dmVyeSB0aW1lIHRoZSBjb250ZW50IGVudGVycyBpbnRvIG9uZSBDRE4sIGUuZy4gZnJvbQ0KdUNE TiB0byBkQ0ROPzwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBU aGUgc2Vjb25kIHN0ZXAgaXMgdG8gYWRkIHRoYXQgQ0lEIHRvIHRoZSBjb250ZW50DQpuYW1lLCBz byBpdCBpcyA8YnI+DQomZ3Q7IGNhcnJpZWQgaW4gdGhlIG5hbWUuPC9mb250PjwvdHQ+DQo8YnI+ PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IFNvIHlvdSBoYXZlIGEgQ1VSTDo8L2ZvbnQ+PC90dD4NCjxi cj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgaHR0cDovL3d3dy5zZXJ2ZXIxLmNvbS8uLi4vQ00tQ0lE LWZpbGVuYW1lLnh5ejwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJz cDs8L2ZvbnQ+PC90dD48dHQ+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWU+W0xpDQpNaWFuXTogRG9l cyB0aGUgZW1iZWRkaW5nIG9mIENJRCBpbnRvIENVUkwgaGF2ZSBzb21lIHNlY3VyaXR5IGlzc3Vl IG9yDQpzb21lIGxpbWl0YXRpb24gdG8gdGhlIFVSTCBleHRlbnNpb24/IERvIHlvdSBoYXZlIHNv bWUgbW9yZSBjb25zaWRlcmF0aW9uDQpvbiB0aGlzPzwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0 dD48Zm9udCBzaXplPTI+Jmd0OyBXaGVuIGEgZmlsZSBjb250ZW50IGNoYW5nZXMgQ0ROLCB0aGUg bmFtZSBtYXkNCnJlbWFpbiB0aGUgc2FtZSBvciBub3QuPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxm b250IHNpemU9Mj4mZ3Q7IElmIHRoZSBkQ0ROIGZvbGxvd3MgdGhlIHJ1bGUsIGl0IG1heSBjaGFu Z2UgdG8NCnNvbWV0aGluZyBsaWtlOjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+ Jmd0OyBodHRwOi8vd3d3LnNlcnZlcjIuY29tLy4uLi9DTS1DSUQtZmlsZW5hbWUyLnh5ejwvZm9u dD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBBcyB5b3Ugc2VlIHRoZSBDSUQgaXMg c3RpbGwgZW1iZWRkZWQgaW4gdGhlIG5hbWUNCmFuZCBjYW4gYmUgdGhlIDxicj4NCiZndDsgaWRl bnRpdHkgb2YgdGhlIGNvbnRlbnQgZXZlbiBpZiB0aGUgcmVtYWluaW5nIFVSTCBoYXMgY2hhbmdl ZC4gPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48 L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBOb3cgbGV0c+KAmSBhc3N1bWUgdGhhdCBm b3IgYSByZWFzb24gdGhlIGNvbnRlbnQNCmlzIG1vdmVkIHRvIGEgZENETiA8YnI+DQomZ3Q7IHRo YXQgZG9lcyBub3QgZm9sbG93IHRoZSBydWxlLCBpdCBjaGFuZ2VzIG5hbWUgYW5kIHRoZW4gdG8g YW5vdGhlcg0KPGJyPg0KJmd0OyBkQ0ROIHRoYXQgZm9sbG93cyB0aGUgcnVsZS4gVGhlIG5ldyBk Q0ROIG1heSBjYWxjdWxhdGUgYW5kIDxicj4NCiZndDsgcmVnZW5lcmF0ZSB0aGUgQ0lEIGFuZCB1 c2UgaXQgYWdhaW4gYXMgdGhlIGNvbnRlbnQga2V5IGluZGV4LjwvZm9udD48L3R0Pg0KPGJyPjx0 dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD48dHQ+PGZvbnQgc2l6ZT0yIGNv bG9yPWJsdWU+W0xpDQpNaWFuXTogYS4gaWYgeW91IHdhbnQgdG8ga2VlcCB0aGUgQ0lEIHVuY2hh bmdlZCwgaS5lLiB0aGUgc2FtZSBhcyB0aGUgb3JpZ2luYWwNCm9uZSwgeW91IG5lZWQgdG8gZ3Vh cmFudGVlIHRoZSBjb25zaXN0ZW5jeSBvZiBIQVNIIGFyaXRobWV0aWMgdGhyb3VnaG91dA0KdGhl IENETmkgc2NvcGUgJ2NveiBkaWZmZXJlbnQgQ0ROcyBtYXkgaGF2ZSBkaWZmZXJlbnQgSEFTSCBj YWxjdWxhdGluZw0KcmVzdWx0cy4gYW5kIHRoaXMsIHRvIG1lLCBtYXkgbm90IGJlIGFuIGVhc3kg d29yazsgYi4gdGhlIENJRCBpcyBnZW5lcmF0ZWQNCmJhc2VkIG9uIHRoZSBjb21wbGV0ZSBkb3du bG9hZCBvZiB0aGUgd2hvbGUgY29udGVudC4gU28geW91IG5lZWQgdG8gZmluaXNoDQpkb3dubG9h ZGluZyBvZiB0aGUgY29udGVudCBiZWZvcmUgeW91IGdlbmVyYXRlIHRoZSBDSUQgYW5kIGNoZWNr IHdoZXRoZXINCnRoaXMgY29udGVudCBpcyBhbHJlYWR5IHN0b3JlZCBpbiB0aGlzIENETi4gVGhp cywgdG8gc29tZSBleHRlbnQsIGRvZXMNCm5vdCBpbXByb3ZlIHRoZSBlZmZpY2llbmN5IG9mIGNv bnRlbnQgZGUtZHVwbGljYXRpb24uIEhvdyBkbyB5b3UgdGhpbms/PC9mb250PjwvdHQ+DQo8YnI+ PHR0Pjxmb250IHNpemU9MiBjb2xvcj1ibHVlPltMaSBNaWFuXTogaW4gb3VyIGNvbnRlbnQgZGUt ZHVwbGljYXRpb24NCmRyYWZ0LCB3ZSBhbHdheXMgZXhjaGFuZ2UgYW5kIGNoZWNrIHRoZSBleGlz dGVuY2Ugb2Ygb25lIGNvbnRlbnQgb2JqZWN0DQpieSB1c2luZyB0aGUgY29udGVudCBpZGVudGlm aWNhdGlvbiBtb2RlbCBiZWZvcmUgdGhlIGFjdHVhbCBjb250ZW50IGl0ZW0NCmlzIGRvd25sb2Fk LCB3aGljaCBtYXkgaGF2ZSBiZXR0ZXIgZWZmaWNpZW5jeS48L2ZvbnQ+PC90dD4NCjxicj4NCjxi cj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgTm93IGxldHPigJkgbW92ZSB0byB0aGUgY2xpZW50cy4g PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IElmIHRoZSBNRFAgZmlsZSAo dXNpbmcgREFTSCBzdHJlYW1pbmcpIG9yIHRoZQ0KaHR0cCBwYWdlIGNvbnRhaW5zIDxicj4NCiZn dDsgdGhpcyBDVVJMLCB0aGUgQ0ROIGNhbiBkaXJlY3RseSBleHRyYWN0IHRoZSBDSUQgKGFzIGl0 IGZvbGxvd3MgdGhlDQo8YnI+DQomZ3Q7IENNIOKAnG1hZ2ljIHdvcmTigJ0pLCBsb29rIGZvciBp dCB1c2luZyB0aGlzIENJRCBhbmQgaWdub3JlIHRoZSA8YnI+DQomZ3Q7IHJlbWFpbmluZyBVUkwu IElmIGZvciBhIHJlYXNvbiB0aGUgZmlsZSBpcyBub3QgaW4gdGhlIENETiBhbmQgY2Fu4oCZdA0K PGJyPg0KJmd0OyBiZSBmb3VuZCBhdCB0aGUgb3RoZXIgQ0ROcywgaXQgaXMgdmVyeSBzaW1wbGUg Zm9yIHRoZSBDRE4gdG8gcmVtb3ZlDQo8YnI+DQomZ3Q7IHRoZSBDTS1DSUQsIHJlZ2VuZXJhdGUg dGhlIG9yaWdpbmFsIFVSTCBhbmQgcmVxdWVzdCBpdCBmcm9tIHRoZSA8YnI+DQomZ3Q7IG9yaWdp bmFsIHdlYiBzaXRlLjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJz cDs8L2ZvbnQ+PC90dD48dHQ+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWU+W0xpDQpNaWFuXTogc28g aG93IGNvdWxkIHRoZSBDRE4gY2hlY2sgdGhlIGNvbnRlbnQgaXMgbm90IGZvdW5kIGF0IHRoZSBv dGhlcg0KQ0ROcz8gSW4gY3VycmVudCBpbXBsZW1lbnRhdGlvbiBpbiBmcmFtZXdvcmsgZHJhZnQs IHRoZSBkQ0ROIG9ubHkgYWNxdWlyZXMNCmNvbnRlbnQgZnJvbSB1Q0ROIHRoYXQgcmVkaXJlY3Rz IHRoZSB1c2VyJ3MgcmVxdWVzdCB0byBpdC48L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+PGZv bnQgc2l6ZT0yPiZndDsgVGhpcyBpcyBzb21lIGV4cGVyaW1lbnRhdGlvbiB0aGF0IHdlIGhhdmUg ZG9uZQ0KaW4gdGhlIHByb2plY3QgQ09BU1QgKDxicj4NCiZndDsgd3d3LmNvYXN0LWZwNy5ldSkg YW5kIHRoZSBuYW1pbmcgc2NoZW1lIGlzIGFsc28gZXhwbGFpbmVkIGluIHRoZSBUaC48YnI+DQom Z3Q7IFphaGFyaWFkaXMsIEUuIFF1YWNjaGlvLCDigJxGYXN0IGNvbnRlbnQtYXdhcmUgZGVsaXZl cnkgaW4gb3ZlcmxheQ0KPGJyPg0KJmd0OyBuZXR3b3JrcyzigJ0gSUVFRSBDT01TT0MgTU1UQyBF LUxldHRlciwgVm9sLjYsIE5vLiA3LCBKdWx5IDIwMTEsIHBwLg0KNDQtNDc8L2ZvbnQ+PC90dD4N Cjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgKGh0dHA6Ly9jb21taXR0ZWVzLmNvbXNvYy5vcmcv bW1jL2UtbmV3cy9FLUxldHRlci1KdWx5MTEucGRmJm5ic3A7DQpwYWdlIDQ0LTQ3KSAmbmJzcDs8 L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDs8L2ZvbnQ+PC90dD48dHQ+PGZv bnQgc2l6ZT0yIGNvbG9yPWJsdWU+W0xpIE1pYW5dOg0KdGhhbmsgeW91LCBJIHdpbGwgcmVhZCB0 aGVtIGluIGRldGFpbC48L2ZvbnQ+PC90dD48dHQ+PGZvbnQgc2l6ZT0yPiAmbmJzcDs8L2ZvbnQ+ PC90dD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgQmVzdCBSZWdhcmRzLDwvZm9u dD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBUaGVvZG9yZTwvZm9udD48L3R0Pg0K PGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZv bnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4m Z3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDs8 L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgRnJvbTogbGkubWlhbkB6dGUu Y29tLmNuIFttYWlsdG86bGkubWlhbkB6dGUuY29tLmNuXQ0KPGJyPg0KJmd0OyBTZW50OiBXZWRu ZXNkYXksIEF1Z3VzdCAwMSwgMjAxMiA5OjUyIEFNPGJyPg0KJmd0OyBUbzogemFoYXJpYWRAc3lu ZWxpeGlzLmNvbTsgY2RuaUBpZXRmLm9yZzsgY2RuaS1ib3VuY2VzQGlldGYub3JnOw0KPGJyPg0K Jmd0OyAnQmh1bWlwIEtoYXNuYWJpc2gnOyBqaW4ud2VpeWlAenRlLmNvbS5jbjxicj4NCiZndDsg U3ViamVjdDog562U5aSNOiBSZTogW0NETmldIEZ3ZDogZHJhZnQtamluLWNkbmktY29udGVudC1k ZWR1cGxpY2F0aW9uLTxicj4NCiZndDsgb3B0aW1pemF0aW9uLTAyLnR4dDwvZm9udD48L3R0Pg0K PGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZv bnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBEZWFyIFRoZW9kb3JlLCA8YnI+DQomZ3Q7IDxicj4N CiZndDsgVGhhbmsgeW91IGZvciB5b3VyIGNvbW1lbnRzIGFuZCBzaGFyaW5nIHdpdGggdXMgeW91 ciBwcm9wb3NhbHMuIDxicj4NCiZndDsgQ291bGQgeW91IHBsZWFzZSBzaGFyZSB0aGUgZG9jdW1l bnRzIHlvdSBtZW50aW9uZWQgYmVsb3cgd2l0aCBtZT8NCjxicj4NCiZndDsgQmFzZWQgb24gd2hh dCB5b3UgZXhwbGFpbmVkIGluIHByZXZpb3VzIGVtYWlsLCBJIGhhdmUgc29tZSBxdWVzdGlvbnM8 YnI+DQomZ3Q7IGZvciBjbGFyaWZpY2F0aW9uOiA8YnI+DQomZ3Q7IDEuIFdlIGJvdGggY29uc2lk ZXIgaXQgbmVjZXNzYXJ5IHRvIGhhdmUgYSB1bmlxdWUgY29udGVudCBpZGVudGlmaWVyPGJyPg0K Jmd0OyBmb3IgYSBjb250ZW50IG9iamVjdC4gT3VyIG9waW5pb24gaW4gdGhpcyBkcmFmdCBpcyB0 aGF0IHRoaXMgY29udGVudDxicj4NCiZndDsgSUQgaXMgQ1NQLXVuaXF1ZS4gQ291bGQgeW91IHBs ZWFzZSBleHBsYWluIG1vcmUgYWJvdXQgdGhlIHVuaXF1ZW5lc3M8YnI+DQomZ3Q7IG9mIHRoZSBV SUQgaW4geW91ciBwcm9wb3NhbD8gPGJyPg0KJmd0OyAyLiBCeSBhcHBseWluZyB0aGUgbWVjaGFu aXNtIHlvdSBwcm9wb3NlZCBiZWxvdywgd2UgY2FuIGd1YXJhbnRlZQ0KPGJyPg0KJmd0OyB0aGUg Y29udGVudCBpcyB1bmlxdWVseSBzdG9yZWQgaW4gb25lIENETi4gQW5kIGFjY29yZGluZyB0byBt eSA8YnI+DQomZ3Q7IGFuYWx5c2lzIG9uIHRoZSBiYXNpcyBvZiB5b3VyIGV4cGxhbmF0aW9uLCB0 aGUgY29udGVudCByZXBsaWNhdGlvbg0KPGJyPg0KJmd0OyBpcyBjaGVja2VkIGJ5IGNvbXBhcmlu ZyB0aGUgQ1VSTCB3aGljaCBpcyBzaW1pbGFyIHRvIHRoZSBjdXJyZW50IDxicj4NCiZndDsgbWVj aGFuaXNtIGluIENETmkgd29yaywgY29ycmVjdCBtZSBpZiBteSB1bmRlcnN0YW5kaW5nIGlzIHdy b25nLiBJZg0KPGJyPg0KJmd0OyBzbywgd2hlbiByZWRpcmVjdGlvbiBvY2N1cnMgYmV0d2VlbiB1 Q0ROcyBhbmQgZENETiwgdGhlIFVSTCB3b3VsZA0KYmU8YnI+DQomZ3Q7IGNoYW5nZWQgYW5kIHRo dXMgYmUgZGlmZmVyZW50IHdpdGggdGhlIG9yaWdpbmFsIG9uZSAtIENVUkwuIEFuZCBpZg0KYTxi cj4NCiZndDsgZENETiBpcyBjb25uZWN0ZWQgd2l0aCB0d28gZGlmZmVyZW50IHVDRE5zIGFuZCB0 d28gZW5kIHVzZXJzIHJlcXVlc3Q8YnI+DQomZ3Q7IHRoZSBzYW1lIGNvbnRlbnQgZnJvbSB0aGVz ZSB0d28gdUNETnMgcmVzcGVjdGl2ZWx5LCB0aGUgdHdvIHVDRE5zDQo8YnI+DQomZ3Q7IG1heSBn ZW5lcmF0ZSBkaWZmZXJlbnQgcmVkaXJlY3Rpb24gVVJMcyB0byB0aGUgZENETi4gSW4gdGhpcyBj YXNlDQp3ZTxicj4NCiZndDsgdGhpbmsgdGhlIGNvbnRlbnQgZHVwbGljYXRpb24gaXNzdWUgc3Rp bGwgZXhpc3RzLiBIb3cgZG8geW91IHRoaW5rPw0KPGJyPg0KJmd0OyBJZiBteSB1bmRlcnN0YW5k aW5nIGlzIHdyb25nLCBjb3VsZCB5b3UgcGxlYXNlIGV4cGxhaW4gbW9yZSBvbiBob3cNCjxicj4N CiZndDsgdG8gY29uc2lkZXIgdGhpcyBpc3N1ZSBieSB1c2luZyB5b3VyIHByb3Bvc2FsPyA8YnI+ DQomZ3Q7IDxicj4NCiZndDsgVGhhbmsgeW91IGFnYWlufiA8YnI+DQomZ3Q7IDxicj4NCiZndDsg Y2RuaS1ib3VuY2VzQGlldGYub3JnIOWGmeS6jiAyMDEyLTA4LTAxIDAyOjAwOjIzOjxicj4NCiZn dDsgPGJyPg0KJmd0OyAmZ3Q7IERlYXIgQmh1bWlwLCA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7IDxi cj4NCiZndDsgJmd0OyBTb21lIGlkZWFzIGFuZCBjb25zaWRlcmF0aW9ucyBvbiB0aGUgZHJhZnQu IDxicj4NCiZndDsgJmd0OyAmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7IFdlIGhhdmUgZG9uZSBzb21l IHdvcmsgaW4gdGhlIGFyZWEgb2YgZGUtZHVwbGljYXRpb24gb2YgY29udGVudA0KPGJyPg0KJmd0 OyAmZ3Q7IChQbGVhc2Ugc2VlIFRoLiBaYWhhcmlhZGlzLCBFLiBRdWFjY2hpbywg4oCcRmFzdCBj b250ZW50LWF3YXJlDQo8YnI+DQomZ3Q7ICZndDsgZGVsaXZlcnkgaW4gb3ZlcmxheSBuZXR3b3Jr cyzigJ0gSUVFRSBDT01TT0MgTU1UQyBFLUxldHRlciwgVm9sLjYsDQpOby48YnI+DQomZ3Q7ICZn dDsgNywgSnVseSAyMDExLCBwcC4gNDQtNDcpKSA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7IDxicj4N CiZndDsgJmd0OyBBY3R1YWxseSwgd2UgYmVsaWV2ZSB0aGF0IGl0IGlzIG5lZWRlZCB0byBkZWZp bmUgVW5pcXVlIElEcyAoVUlEKQ0KPGJyPg0KJmd0OyAmZ3Q7IHBlciBjb250ZW50IG9iamVjdC9j aHVuayBpbiBvcmRlciB0bzogPGJyPg0KJmd0OyAmZ3Q7IGEpIEF2b2lkIGV4dGVuZGVkIGRhdGEg cmVwbGljYXRpb25zIGF0IHRoZSBDRE4gbGV2ZWwgYW5kIG1pbmltaXplDQo8YnI+DQomZ3Q7ICZn dDsgdGhlIGxvYWQgdG8gZmluZCB0aGUgY29ycmVjdCBvYmplY3QuIDxicj4NCiZndDsgJmd0OyBi KSBEZXRlY3QgYW5kIHJldHJpZXZlIHZlcnkgZmFzdCB0aGUgY29udGVudC4gVGhpcyBzaG91bGQg YmUNCmZhc3QgPGJyPg0KJmd0OyAmZ3Q7IGVub3VnaCB0byBhbGxvdyBldmVuIHNlYW1sZXNzIHJl YWwtdGltZSB2aWRlbyBzdHJlYW1pbmcgYnkgPGJyPg0KJmd0OyAmZ3Q7IHJldHJpZXZpbmcgdmlk ZW8gY2h1bmtzIDxicj4NCiZndDsgJmd0OyBjKSBCZSBiYWNrd2FyZHMgY29tcGF0aWJsZSB3aXRo IHRvZGF5c+KAmSBVUkxzIChpbiBjYXNlIHRoZSA8YnI+DQomZ3Q7ICZndDsgY29udGVudC9jaHVu ayBpcyBub3QgZm91bmQsIHlvdSBzaG91bGQgYmUgYWJsZSB0byBnbyB0byB0aGUgb3JpZ2luYWwN CnNpdGUpLjxicj4NCiZndDsgJmd0OyAmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7IEluIG9yZGVyIHRv IG1lZXQgdGhlIChhKSwgVUlEIHNob3VsZCBiZSBhbHdheXMgYXNzb2NpYXRlZCB3aXRoDQp0aGUg PGJyPg0KJmd0OyAmZ3Q7IGNvbnRlbnQgb2JqZWN0IGl0c2VsZiAoZS5nLiBlbmNhcHN1bGF0ZWQg aW4gdGhlIG9iamVjdCkgb3IgYmUNCmJhc2VkIDxicj4NCiZndDsgJmd0OyBvbiB1bmlxdWUgY2hh cmFjdGVyaXN0aWNzIG9mIHRoZSBjb250ZW50IG9iamVjdCAoZS5nLiBhIHNldCBvZg0KbG93IDxi cj4NCiZndDsgJmd0OyBsZXZlbCBkZXNjcmlwdG9ycykuIEhvd2V2ZXIsIChiKSwgcG9zZXMgdGhh dCB0aGlzIGNvdWxkIGJlIDxicj4NCiZndDsgJmd0OyBjYWxjdWxhdGVkIG9uY2UgKG9yIHNvbWV0 aW1lcyksIGJ1dCBzaG91bGQgbm90IGJlIGNhbGN1bGF0ZWQNCm9yIDxicj4NCiZndDsgJmd0OyBn ZW5lcmF0ZWQgZWFjaCB0aW1lIHRoZSBvYmplY3QgaXMgcmVxdWVzdGVkOyBpbnN0ZWFkIGl0IHNo b3VsZA0KYmUgPGJyPg0KJmd0OyAmZ3Q7IOKAnGNhcnJpZWTigJ0gYW5kIOKAnGV4dHJhY3RlZOKA nSBpbiBtb3N0IGNhc2VzLiAmbmJzcDtPbiB0aGUNCm90aGVyIGhhbmQsIGR1ZSB0byA8YnI+DQom Z3Q7ICZndDsgYmFja3dhcmRzIGNvbXBhdGliaWxpdHkgbmVlZHMgKGMpLCB3ZSBzaG91bGQgbm90 IGNoYW5nZSB0aGUgc3RhbmRhcmQ8YnI+DQomZ3Q7ICZndDsgZmlsZSBmb3JtYXQgKGUuZy4gd2Ug Y291bGQgbm90IGVuY2Fwc3VsYXRlIFVJRCBvciBsb3cgbGV2ZWwgPGJyPg0KJmd0OyAmZ3Q7IGRl c2NyaXB0b3IgaW4gdGhlIGNvbnRlbnQgb2JqZWN0KS4gPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyA8 YnI+DQomZ3Q7ICZndDsgT25lIHNvbHV0aW9uIGNvdWxkIGJlIHRvIGNyZWF0ZSBhIHdyYXBwZXIg dGhhdCB3b3VsZCBlbmNhcHN1bGF0ZQ0KdGhlPGJyPg0KJmd0OyAmZ3Q7IFVJRCB3aGVuZXZlciB0 aGUgY29udGVudCBvYmplY3QgZW50ZXJzIHRoZSBDRE4gYW5kIGV4dHJhY3RzIHRoYXQNCmF0IDxi cj4NCiZndDsgJmd0OyB0aGUgdGltZSB0aGF0IHRoZSBjb250ZW50IG9iamVjdCBsZWF2ZXMgdGhl IENETiwgYnV0IHRoaXMgd291bGQNCjxicj4NCiZndDsgJmd0OyBpbmNyZWFzZSB0aGUgY29tcGxl eGl0eSBhbmQgcHJvY2Vzc2luZyB0aW1lLiA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7IDxicj4NCiZn dDsgJmd0OyBJbnN0ZWFkLCB3ZSBwcm9wb3NlIHRvIHVzZSBhcyBVSUQgYSBmb3JtYWwgZmlsZSBu YW1lIGZvcm1hdC4NClVJRCA8YnI+DQomZ3Q7ICZndDsgd2lsbCBiZSBhIHN0cmluZyBjb25jYXRl bmF0aW9uIGluIHRoZSBmb3JtYXQ6IDxicj4NCiZndDsgJmd0OyAmbmJzcDsgPGJyPg0KJmd0OyAm Z3Q7IENNLUNJRC1maWxlbmFtZS5leHQgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7 ICZndDsgd2hlcmU6IDxicj4NCiZndDsgJmd0OyDigKIgQ00gaXMgYSDigJxDb250ZW50IE1hcmtl cuKAnSA8YnI+DQomZ3Q7ICZndDsg4oCiIENJRCBpcyBhIGNvbnRlbnQgc2lnbmF0dXJlLCB3aGlj aCBjb3VsZCBiZSBhIHNlbGYtY2VydGlmeWluZw0KPGJyPg0KJmd0OyAmZ3Q7IGlkZW50aWZpZXIg ZS5nLiBNRDUgb3IgU0hBLTEgYmFzZWQtaGFzaCBmdW5jdGlvbiBvbiB0aGUgZmlsZSdzDQo8YnI+ DQomZ3Q7ICZndDsgY29udGVudCBvciBldmVuIGEgY29tYmluYXRpb24gb2Ygc2VhcmNoYWJsZSBs b3cgbGV2ZWwgZGVzY3JpcHRvcnMuDQosPGJyPg0KJmd0OyAmZ3Q7IHdoaWNoIGd1YXJhbnRlZXMg YW4gZWFzeSBhbmQgZmFzdCBkZXRlY3Rpb24gdGhhdCB0aGlzIG5hbWUgaXMNCmEgVUlEIDxicj4N CiZndDsgJmd0OyDigKIgdGhlIG9yaWdpbmFsIGZpbGVuYW1lLCB3aGljaCBpcyB1c2VkIGZvciBt YWtpbmcgVUlEIGVhc2lseQ0KPGJyPg0KJmd0OyAmZ3Q7IHJlY29nbml6ZWQgYnkgaHVtYW5zIGFu ZCBhdm9pZCBjb21wbGV4IHNlbGYtY2VydGlmeWluZyBuYW1lcy4NCjxicj4NCiZndDsgJmd0OyAm bmJzcDsgPGJyPg0KJmd0OyAmZ3Q7IFdoZW5ldmVyIG5ldyBjb250ZW50IGlzIHB1Ymxpc2hlZCBv ciBzdG9yZWQgYXQgdGhlIENETiwgdGhlIG9iamVjdA0KPGJyPg0KJmd0OyAmZ3Q7IGZpbGVuYW1l IGNvdWxkIGJlIHJlbmFtZWQgdG8gYSBVSUQgYW5kIHRoZSBVUkwgdG8gYSBDb250ZW50IFVSTA0K PGJyPg0KJmd0OyAmZ3Q7IChDVVJMKSB3aXRoIHRoZSA8YnI+DQomZ3Q7ICZndDsgZm9sbG93aW5n IGZvcm1hdDogPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgaHR0cDovL3d3 dy4gd2Vic2l0ZS5jb20v4oCmL0NNLUNJRC1maWxlbmFtZS5leHQgPGJyPg0KJmd0OyAmZ3Q7ICZu YnNwOyA8YnI+DQomZ3Q7ICZndDsgVGhlIENVUkwgaXMgYSBVUkksIHdoaWNoIGlzIGRlc2lnbmVk IHRvIGVuYWJsZSBjYWNoaW5nIG1lY2hhbmlzbXMNCjxicj4NCiZndDsgJmd0OyBhbmQgdHJpZ2dl ciBDRE4tcmVsYXRlZCBmdW5jdGlvbmFsaXR5IChlLmcuIGFjY2Vzc2luZyB0aGUgQ0RODQo8YnI+ DQomZ3Q7ICZndDsgb3ZlcmxheSBuZXR3b3JrIGFuZCBxdWVyeWluZyBmb3IgbG9jYWxseSBvciDi gJxuZWFyYnnigJ0gY2FjaGVkDQo8YnI+DQomZ3Q7ICZndDsgY29udGVudCkuIEl0IHNob3VsZCBh bHNvIGJlIGVtcGhhc2l6ZWQgdGhhdCBmcm9tIHRoZSBDVVJMLCB0aGUNCjxicj4NCiZndDsgJmd0 OyBvcmlnaW5hbCBVUkwgYW5kIHRoZSBVSUQgbWF5IGJlIGVhc2lseSBleHRyYWN0ZWQsIHdoaWxl IG9uIHRoZQ0Kb3RoZXI8YnI+DQomZ3Q7ICZndDsgaGFuZCBpdCBpcyBmdWxseSBiYWNrd2FyZHMg Y29tcGF0aWJsZSB3aXRoIGV4aXN0aW5nIGJyb3dzZXJzDQphbmQgbm8gPGJyPg0KJmd0OyAmZ3Q7 IG1vZGlmaWNhdGlvbnMgYXJlIG5lZWRlZC4gSW4gdGhpcyB3YXksIHdlIG1heSBzZWFtbGVzc2x5 IHN1cHBvcnQNCmFueTxicj4NCiZndDsgJmd0OyBraW5kIG9mIGRhdGEgYXZhaWxhYmxlIGluIHRo ZSBJbnRlcm5ldCAodGV4dCwgaW1hZ2VzLCB2YXJpb3VzDQp0eXBlcyA8YnI+DQomZ3Q7ICZndDsg b2YgYXVkaW8gb3IgdmlkZW8pLCB3aGlsZSBpbiBjYXNlIHRoZSBjb250ZW50IG9iamVjdCBpcyBu b3QgY2FjaGVkDQo8YnI+DQomZ3Q7ICZndDsgaW4gdGhlIENETiwgd2UgY2FuIGFsd2F5cyBnbyBi YWNrIHRvIHRoZSBvcmlnaW5hbCBzb3VyY2UgVVJMLg0KPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyA8 YnI+DQomZ3Q7ICZndDsgQmVzdCByZWdhcmRzLCA8YnI+DQomZ3Q7ICZndDsgVGhlb2RvcmUgPGJy Pg0KJmd0OyAmZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgRnJvbTogY2RuaS1ib3VuY2VzQGll dGYub3JnIFttYWlsdG86Y2RuaS1ib3VuY2VzQGlldGYub3JnXSBPbg0KQmVoYWxmIE9mIDxicj4N CiZndDsgJmd0OyBCaHVtaXAgS2hhc25hYmlzaDxicj4NCiZndDsgJmd0OyBTZW50OiBUdWVzZGF5 LCBKdWx5IDMxLCAyMDEyIDg6NDQgUE08YnI+DQomZ3Q7ICZndDsgVG86IGNkbmlAaWV0Zi5vcmc8 YnI+DQomZ3Q7ICZndDsgU3ViamVjdDogW0NETmldIEZ3ZDogZHJhZnQtamluLWNkbmktY29udGVu dC1kZWR1cGxpY2F0aW9uLTxicj4NCiZndDsgb3B0aW1pemF0aW9uLTAyLnR4dCA8YnI+DQomZ3Q7 ICZndDsgJm5ic3A7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgVG86IGktZC1hbm5v dW5jZSBhdCBpZXRmLm9yZyA8YnI+DQomZ3Q7ICZndDsgU3ViamVjdDogSS1EIEFjdGlvbjogZHJh ZnQtamluLWNkbmktY29udGVudC1kZWR1cGxpY2F0aW9uLTxicj4NCiZndDsgb3B0aW1pemF0aW9u LTAyLnR4dCA8YnI+DQomZ3Q7ICZndDsgRnJvbTogaW50ZXJuZXQtZHJhZnRzIGF0IGlldGYub3Jn IDxicj4NCiZndDsgJmd0OyBEYXRlOiBTdW4sIDI5IEp1bCAyMDEyIDE5OjI5OjE0IC0wNzAwIDxi cj4NCiZndDsgJmd0OyBEZWxpdmVyZWQtdG86IGktZC1hbm5vdW5jZSBhdCBpZXRmYS5hbXNsLmNv bSA8YnI+DQomZ3Q7ICZndDsgTGlzdC1hcmNoaXZlOiAmbHQ7aHR0cDovL3d3dy5pZXRmLm9yZy9t YWlsLWFyY2hpdmUvd2ViL2ktZC1hbm5vdW5jZSZndDsNCjxicj4NCiZndDsgJmd0OyBMaXN0LWhl bHA6ICZsdDttYWlsdG86aS1kLWFubm91bmNlLXJlcXVlc3RAaWV0Zi5vcmc/c3ViamVjdD1oZWxw Jmd0Ow0KPGJyPg0KJmd0OyAmZ3Q7IExpc3QtaWQ6IEludGVybmV0IERyYWZ0IEFubm91bmNlbWVu dHMgb25seSAmbHQ7aS1kLWFubm91bmNlLmlldGYub3JnJmd0Ow0KPGJyPg0KJmd0OyAmZ3Q7IExp c3QtcG9zdDogJmx0O21haWx0bzppLWQtYW5ub3VuY2VAaWV0Zi5vcmcmZ3Q7IDxicj4NCiZndDsg Jmd0OyBMaXN0LXN1YnNjcmliZTogJmx0O2h0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vaS1kLWFubm91bmNlJmd0OywNCiZsdDs8YnI+DQomZ3Q7ICZndDsgbWFpbHRvOmktZC1h bm5vdW5jZS1yZXF1ZXN0QGlldGYub3JnP3N1YmplY3Q9c3Vic2NyaWJlJmd0OyA8YnI+DQomZ3Q7 ICZndDsgTGlzdC11bnN1YnNjcmliZTogJmx0O2h0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v b3B0aW9ucy9pLWQtYW5ub3VuY2UmZ3Q7LA0KJmx0Ozxicj4NCiZndDsgJmd0OyBtYWlsdG86aS1k LWFubm91bmNlLXJlcXVlc3RAaWV0Zi5vcmc/c3ViamVjdD11bnN1YnNjcmliZSZndDsNCjxicj4N CiZndDsgJmd0OyBSZXBseS10bzogaW50ZXJuZXQtZHJhZnRzIGF0IGlldGYub3JnIDxicj4NCiZn dDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxl IGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzDQo8YnI+DQomZ3Q7ICZndDsgZGlyZWN0 b3JpZXMuIDxicj4NCiZndDsgJmd0OyAmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyA8YnI+ DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFRpdGxlICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7IDogQ29udGVudCBEZS1kdXBsaWNhdGlvbiBmb3IgQ0RO aSBPcHRpbWl6YXRpb24gPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyBBdXRob3IocykgJm5ic3A7ICZuYnNwOyAmbmJzcDsgOg0KV2VpWWkgSmluIDxicj4NCiZndDsg Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IE1pYW4gTGkgPGJyPg0KJmd0 OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgQmh1bWlwIEtoYXNuYWJp c2ggPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBGaWxlbmFtZSAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs6DQpkcmFmdC1qaW4tY2RuaS1jb250ZW50LWRlZHVw bGljYXRpb24tPGJyPg0KJmd0OyAmZ3Q7IG9wdGltaXphdGlvbi0wMi50eHQgPGJyPg0KJmd0OyAm Z3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBQYWdlcyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsNCiZuYnNwOyA6IDE3IDxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgRGF0ZSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDs6 IDIwMTItMDctMjkgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgQWJzdHJh Y3Q6IDxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7UmVjZW50IGV4cGxvc2l2ZSBncm93dGgg b2YgY29udGVudCBkZWxpdmVyeS9kaXN0cmlidXRpb24NCm5ldHdvcmtzIDxicj4NCiZndDsgJmd0 OyAmbmJzcDsgJm5ic3A7KENETnMpIGFuZCB0aGVpciBpbnRlcmNvbm5lY3Rpb24gYXJlIGNhdXNp bmcgdW5pbnRlbmRlZA0KcmVwZXRpdGlvbiBvZiA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNw O2NvbnRlbnQgc3RvcmFnZSBpbiB0aGUgc2FtZSBkQ0ROLiAmbmJzcDtUaGlzIGNhbg0KYmUgYXZv aWRlZCBieSB1c2luZyBhIDxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7c3VpdGFibGUgZGUt ZHVwbGljYXRpb24gbWVjaGFuaXNtLiAmbmJzcDtUaGlzIGRvY3VtZW50DQpleHBsb3JlcyB0aGUg PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDtzY2VuYXJpb3Mgd2hpY2ggY3JlYXRlIHRoZSBw cm9ibGVtcywgYW5kIHRoZW4gZGlzY3Vzc2VzDQp0aGUgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAm bmJzcDthcHByb2FjaGVzIHRvIGVsaW1pbmF0ZSB0aGUgZHVwbGljYXRlZCB0cmFuc21pc3Npb24N Cm9mIHRoZSBzYW1lIDxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7Y29udGVudCBmcm9tIHVD RE4ocykgdG8gZENETiBpbiBDRE5pIG5ldHdvcmtzLiAmbmJzcDtUbw0KaW1wbGVtZW50IHRoZSA8 YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO29wdGltaXphdGlvbiwgc29tZSBlbmhhbmNlbWVu dHMgdG8gdGhlIENETmkgbWV0YWRhdGENCm1vZGVsIGFuZCA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7 ICZuYnNwO2ludGVyZmFjZSBhcmUgcmVxdWlyZWQuIDxicj4NCiZndDsgJmd0OyAmbmJzcDsgPGJy Pg0KJmd0OyAmZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgVGhlIElFVEYgZGF0YXRyYWNrZXIg c3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6IDxicj4NCiZndDsgJmd0OyBodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1qaW4tY2RuaS1jb250ZW50LTxicj4NCiZndDsg Jmd0OyBkZWR1cGxpY2F0aW9uLW9wdGltaXphdGlvbiA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7IDxi cj4NCiZndDsgJmd0OyBUaGVyZSdzIGFsc28gYSBodG1saXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBh dDogPGJyPg0KJmd0OyAmZ3Q7IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWppbi1j ZG5pLWNvbnRlbnQtZGVkdXBsaWNhdGlvbi08YnI+DQomZ3Q7ICZndDsgb3B0aW1pemF0aW9uLTAy IDxicj4NCiZndDsgJmd0OyAmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7IEEgZGlmZiBmcm9tIHByZXZp b3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0OiA8YnI+DQomZ3Q7ICZndDsgaHR0cDovL3Rvb2xz LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1qaW4tY2RuaS1jb250ZW50LTxicj4NCiZndDsg Jmd0OyBkZWR1cGxpY2F0aW9uLW9wdGltaXphdGlvbi0wMiA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7 IDxicj4NCiZndDsgJmd0OyAmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7IEludGVybmV0LURyYWZ0cyBh cmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDogPGJyPg0KJmd0OyAmZ3Q7IGZ0 cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvIDxicj4NCiZndDsgJmd0OyAmbmJzcDtf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsg Jmd0OyBDRE5pIG1haWxpbmcgbGlzdDxicj4NCiZndDsgJmd0OyBDRE5pQGlldGYub3JnPGJyPg0K Jmd0OyAmZ3Q7IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2RuaTwvZm9u dD48L3R0Pg0K --=_alternative 0009782C48257A4E_=-- From ramk@Brocade.com Wed Aug 1 19:09:57 2012 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 6124311E8191 for ; Wed, 1 Aug 2012 19:09:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.264 X-Spam-Level: X-Spam-Status: No, score=-3.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, 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 N3xvkewnWeub for ; Wed, 1 Aug 2012 19:09:55 -0700 (PDT) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by ietfa.amsl.com (Postfix) with ESMTP id 7426811E818C for ; Wed, 1 Aug 2012 19:09:55 -0700 (PDT) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id q7229ori005523; Wed, 1 Aug 2012 19:09:50 -0700 Received: from hq1wp-exhub02.corp.brocade.com ([144.49.131.13]) by mx0b-000f0801.pphosted.com with ESMTP id 16ema7gtxe-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 01 Aug 2012 19:09:49 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB02.corp.brocade.com ([fe80::e1f4:a4c8:696b:3780%10]) with mapi; Wed, 1 Aug 2012 19:09:48 -0700 From: ramki Krishnan To: "Brandenburg, R. (Ray) van" , "cdni@ietf.org" , "bhumip.khasnabish@zteusa.com" Date: Wed, 1 Aug 2012 19:09:42 -0700 Thread-Topic: Comments on draft draft-krishnan-cdni-tm-has-00 Thread-Index: AQHNcCtar9E3CMmGP0C7wFKwbIuN8pdFdwHEgAArZMA= Message-ID: References: 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_C7634EB63EFD984A978DFB46EA5174F2BD6D325F23HQ1EXCH01corp_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.260, 0.0.0000 definitions=2012-08-01_06:2012-08-01, 2012-08-01, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=2 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1207200000 definitions=main-1208010339 Subject: Re: [CDNi] Comments on draft draft-krishnan-cdni-tm-has-00 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, 02 Aug 2012 02:09:57 -0000 --_000_C7634EB63EFD984A978DFB46EA5174F2BD6D325F23HQ1EXCH01corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ray, Thanks for your comments. Please find responses inline. Thanks, ram From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Bra= ndenburg, R. (Ray) van Sent: Wednesday, August 01, 2012 2:22 PM To: cdni@ietf.org; bhumip.khasnabish@zteusa.com Subject: [CDNi] Comments on draft draft-krishnan-cdni-tm-has-00 Hi Bhumip, In response to your question during yesterday's CDNI meeting, I read your d= raft draft-krishnan-cdni-tm-has-00. Since I'm not an expert on TCP and the way router queues are implemented, I= can't comment on the more technical aspects of your draft. However, when l= ooking at the rationale behind the draft I have some questions. If I understand your draft correctly, your main premise is that in cases wh= ere HTTP Adaptive Streaming is used, the content acquisition interface betw= een the dCDN and uCDN (which in itself is out-of-scope of the WG) could bec= ome congested. I have a number of questions related to this: 1) What I don't understand from your draft is what the relationship is betw= een this supposed content congestion and the use of adaptive streaming. Of = course, in peak hours, there will generally be more traffic across the link= than outside peak hours. But isn't true regardless of the case of whether = HAS is used or not? [ramki Krishnan] HAS automatically adapts to the network congestion and ava= ilable bandwidth and delivers acceptable video quality to the user. For exa= mple, during normal hours, high resolution HD video would be delivered to t= he end user. Whereas, during peak hour congestion, low resolution HD video = would be delivered to the end user. 2) Furthermore, you state that "The bandwidth needs of HAS is directly prop= ortional to the number of active end users who are streaming video." Isn't = the general idea behind using a (d)CDN that the necessary bandwidth between= two CDNs is NOT directly proportional to the number of active end-users? [ramki Krishnan] Below are cases where caching in dCDN may not work very we= ll. Pre-positioning of content may not work for all types of content; it often = hard to predict in advance the content needs of users. With this background= , CDNi network congestion could occur in the following scenarios 1) During = peak hours, in a pull model caching, the first copy of many HAS streams wou= ld be delivered. 2) Long-tail personalized content, which is not amenable t= o caching, is desired by the end user. 3) In section 3. you refer to Long-tail personalized content. I'm not sure = what this means. Do you mean dynamic content that is being generated on a p= er-user basis by the uCDN or the CSP? If so, what would be the use case for= wanting to have this content be delivered by a dCDN? Wouldn't this defeat = the purpose of having a dCDN at all, since the content has to be delivered = on a per-user basis by the uCDN anyway? If the uCDN has to deliver the cont= ent to the dCDN for each individual user, wouldn't it be more efficient for= the uCDN to deliver this content to the end-user directly? [ramki Krishnan] Please find a short backgrounder below on long tail conten= t. http://www.wired.com/wired/archive/12.10/tail.html http://whatis.techtarget.com/definition/long-tail Amazon.com and Netflix.com both earn a larger percentage of their profits f= rom relatively obscure, niche books and movies (long tail) than from rental= s and purchases of best sellers and blockbusters (most popular). Best regards, Ray This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer --_000_C7634EB63EFD984A978DFB46EA5174F2BD6D325F23HQ1EXCH01corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Hi Ray,

 

Thanks for your comments. Please fin= d responses inline.

&= nbsp;

Thanks, ram

 

<= p class=3DMsoNormal>From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org= ] On Behalf Of Brandenburg, R. (Ray) van
Sent: Wednesday, = August 01, 2012 2:22 PM
To: cdni@ietf.org; bhumip.khasnabish@zteu= sa.com
Subject: [CDNi] Comments on draft draft-krishnan-cdni-tm-h= as-00

 

Hi Bhumip,

 =

In response to your question during yesterday's CDN= I meeting, I read your draft draft-krishnan-cdni-tm-has-00. 

 

Since I'm not an expe= rt on TCP and the way router queues are implemented, I can't comment on the= more technical aspects of your draft. However, when looking at the rationa= le behind the draft I have some questions. 

 

If I understand your draft correctly, = your main premise is that in cases where HTTP Adaptive Streaming is used, t= he content acquisition interface between the dCDN and uCDN (which in itself= is out-of-scope of the WG) could become congested. I have a number of ques= tions related to this:

 

1) What I don't understand from your draft is what the relations= hip is between this supposed content congestion and the use of adaptive str= eaming. Of course, in peak hours, there will generally be more traffic acro= ss the link than outside peak hours. But isn't true regardless of the case = of whether HAS is used or not? 

[ramki Krishnan] HAS automatically adapts to the network congestion and availab= le bandwidth and delivers acceptable video quality to the user. For example= , during normal hours, high resolution HD video would be delivered to the e= nd user. Whereas, during peak hour congestion, low resolution HD video woul= d be delivered to the end user.

2) Furth= ermore, you state that "The bandwidth needs of HAS is directly proport= ional to the number of active end users who are streaming video." Isn'= t the general idea behind using a (d)CDN that the necessary bandwidth betwe= en two CDNs is NOT directly proportional to the number of active end-users?=

[ramki Krishnan] Below are cases where caching in dCDN may not work very well. =

Pre-positioning of c= ontent may not work for all types of content; it often hard to predict in a= dvance the content needs of users. With this background, CDNi network conge= stion could occur in the following scenarios 1) During peak hours, in a pul= l model caching, the first copy of many HAS streams would be delivered. 2) = Long-tail personalized content, which is not amenable to caching, is desire= d by the end user.

3) In sec= tion 3. you refer to Long-tail personalized content. I'm not sure what this= means. Do you mean dynamic content that is being generated on a per-user b= asis by the uCDN or the CSP? If so, what would be the use case for wanting = to have this content be delivered by a dCDN? Wouldn't this defeat the purpo= se of having a dCDN at all, since the content has to be delivered on a per-= user basis by the uCDN anyway? If the uCDN has to deliver the content to th= e dCDN for each individual user, wouldn't it be more efficient for the uCDN= to deliver this content to the end-user directly?

[ramki Krishnan] Please find a short b= ackgrounder below on long tail content.

http://www.wired.com= /wired/archive/12.10/tail.html

=

http://= whatis.techtarget.com/definition/long-tail

=

Amazon.com and Netflix.com both earn a larger p= ercentage of their profits from relatively obscure, niche books and movies = (long tail) than from rentals and purchases of best sellers and blockbuster= s (most popular). 

Best regards,

 

Ray

 

 

This e-mail = and its contents are subject to the DISCLAIMER at http://www.tno.nl/emaildisclaimer

= --_000_C7634EB63EFD984A978DFB46EA5174F2BD6D325F23HQ1EXCH01corp_-- From kevin.ma@azukisystems.com Wed Aug 1 19:50:14 2012 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 6B44621F87DE for ; Wed, 1 Aug 2012 19:50:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] 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 Iiuo6gYqcByM for ; Wed, 1 Aug 2012 19:50:13 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.244]) by ietfa.amsl.com (Postfix) with ESMTP id 31F6B21F87DA for ; Wed, 1 Aug 2012 19:50:13 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 48081416881; Wed, 1 Aug 2012 22:50:14 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB015.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 91667416875; Wed, 1 Aug 2012 22:50:13 -0400 (EDT) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB015.mail.lan ([10.110.17.15]) with mapi; Wed, 1 Aug 2012 22:49:52 -0400 From: Kevin J Ma To: ramki Krishnan , "Brandenburg, R. (Ray) van" , "cdni@ietf.org" , "bhumip.khasnabish@zteusa.com" Date: Wed, 1 Aug 2012 22:50:08 -0400 Thread-Topic: Comments on draft draft-krishnan-cdni-tm-has-00 Thread-Index: AQHNcCtar9E3CMmGP0C7wFKwbIuN8pdFdwHEgAArZMCAACYzsIAAACAQ Message-ID: <291CC3F9E50E7641901A54E85D0977C6532706FCBD@MAILR002.mail.lan> References: <291CC3F9E50E7641901A54E85D0977C6532706FCB0@MAILR002.mail.lan> In-Reply-To: <291CC3F9E50E7641901A54E85D0977C6532706FCB0@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 Subject: Re: [CDNi] Comments on draft draft-krishnan-cdni-tm-has-00 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, 02 Aug 2012 02:50:14 -0000 Hi Ram, inline: > -----Original Message----- > From: Kevin J Ma > Sent: Wednesday, August 01, 2012 10:14 PM > To: Kevin J Ma > Subject: FW: Comments on draft draft-krishnan-cdni-tm-has-00 >=20 >=20 >=20 > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of > ramki Krishnan > Sent: Wednesday, August 01, 2012 10:10 PM > To: Brandenburg, R. (Ray) van; cdni@ietf.org; bhumip.khasnabish@zteusa.co= m > Subject: Re: [CDNi] Comments on draft draft-krishnan-cdni-tm-has-00 >=20 > Hi Ray, >=20 > Thanks for your comments. Please find responses inline. >=20 > Thanks, ram >=20 > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of > Brandenburg, R. (Ray) van > Sent: Wednesday, August 01, 2012 2:22 PM > To: cdni@ietf.org; bhumip.khasnabish@zteusa.com > Subject: [CDNi] Comments on draft draft-krishnan-cdni-tm-has-00 >=20 > Hi Bhumip, >=20 > In response to your question during yesterday's CDNI meeting, I read your > draft draft-krishnan-cdni-tm-has-00. >=20 > Since I'm not an expert on TCP and the way router queues are implemented, > I can't comment on the more technical aspects of your draft. However, whe= n > looking at the rationale behind the draft I have some questions. >=20 > If I understand your draft correctly, your main premise is that in cases > where HTTP Adaptive Streaming is used, the content acquisition interface > between the dCDN and uCDN (which in itself is out-of-scope of the WG) > could become congested. I have a number of questions related to this: >=20 > 1) What I don't understand from your draft is what the relationship is > between this supposed content congestion and the use of adaptive > streaming. Of course, in peak hours, there will generally be more traffic > across the link than outside peak hours. But isn't true regardless of the > case of whether HAS is used or not? > [ramki Krishnan] HAS automatically adapts to the network congestion and > available bandwidth and delivers acceptable video quality to the user. Fo= r > example, during normal hours, high resolution HD video would be delivered > to the end user. Whereas, during peak hour congestion, low resolution HD > video would be delivered to the end user. I don't think the functionality of HAS is in question. To Ray's point, if the link is congested, it's congested. And as Ray mentioned, content acquisition is out of scope. What is it that is being proposing wrt CDNI? Nothing prevents definition of a new content acquisition protocol which incorporates mandatory WRED, however, that seems orthogonal to CDNI. > 2) Furthermore, you state that "The bandwidth needs of HAS is directly > proportional to the number of active end users who are streaming video." > Isn't the general idea behind using a (d)CDN that the necessary bandwidth > between two CDNs is NOT directly proportional to the number of active end= - > users? > [ramki Krishnan] Below are cases where caching in dCDN may not work very > well. > Pre-positioning of content may not work for all types of content; it ofte= n > hard to predict in advance the content needs of users. With this > background, CDNi network congestion could occur in the following scenario= s > 1) During peak hours, in a pull model caching, the first copy of many HAS > streams would be delivered. 2) Long-tail personalized content, which is > not amenable to caching, is desired by the end user. I agree with Ray in questioning the premise that bandwidth needs are propor= itional to active users. Proportional to the number of different content assets be= ing streamed possibly, but not active users. It's not clear what prepositionin= g has to do with the question of active users? > 3) In section 3. you refer to Long-tail personalized content. I'm not sur= e > what this means. Do you mean dynamic content that is being generated on a > per-user basis by the uCDN or the CSP? If so, what would be the use case > for wanting to have this content be delivered by a dCDN? Wouldn't this > defeat the purpose of having a dCDN at all, since the content has to be > delivered on a per-user basis by the uCDN anyway? If the uCDN has to > deliver the content to the dCDN for each individual user, wouldn't it be > more efficient for the uCDN to deliver this content to the end-user > directly? > [ramki Krishnan] Please find a short backgrounder below on long tail > content. > http://www.wired.com/wired/archive/12.10/tail.html > http://whatis.techtarget.com/definition/long-tail > Amazon.com and Netflix.com both earn a larger percentage of their profits > from relatively obscure, niche books and movies (long tail) than from > rentals and purchases of best sellers and blockbusters (most popular). I don't think Ray was asking so much what long tail content is. I believe Ray was saying that if you don't want to cache that content, because it's long tail, then don't send it through the CDN. Wrt CDNI, what is it that draft-krishnan-cdni-long-tail-00 is proposing? The CDNI requirements (specifically META-14) already discuss distribution control policies, including preventing delegation. Beyond the ability to prevent delegation, are you proposing that CDNs be required to implement analytics-based delegation policies? That seems somewhat beyond our scope. thanx. -- Kevin J. Ma > Best regards, >=20 > Ray >=20 >=20 > This e-mail and its contents are subject to the DISCLAIMER at > http://www.tno.nl/emaildisclaimer From flefauch@cisco.com Wed Aug 1 20:19:59 2012 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 BF6BD21F8564; Wed, 1 Aug 2012 20:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.524 X-Spam-Level: X-Spam-Status: No, score=-8.524 tagged_above=-999 required=5 tests=[AWL=-1.825, BAYES_00=-2.599, FB_CIALIS_LEO3=3.899, HTML_MESSAGE=0.001, 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 pM5mSuHRfQ8y; Wed, 1 Aug 2012 20:19:57 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 3A29021F8BDB; Wed, 1 Aug 2012 20:19:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=17083; q=dns/txt; s=iport; t=1343877597; x=1345087197; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=TrgEREXc2ttxFKwooy6UkwnUEiYPaWAnjBQkHKoxAlg=; b=k2OI/Ip2Ey9O5L+YqY3ybf+YCFkzJjil3paOHZcXyAm9izQRXzz4/0lk y5YSZ8wd4g8QnL3RIqBKvs4A6QzPAVMTWoG/SubBriO95vIXGXksHM3SK h927w5hRXxgIRmGcZMuIwKjVh+NBZvMVuxp1+gYiwmzFstKUXOqp98H73 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAJTxGVCtJXG8/2dsb2JhbAA7Cg65CIEHgiABAQEDAQEBAQ8BFEQDCwUHBAIBCBEBAwEBJAQHJwsUAwYIAgQOBRsHh2UGC50RoEYBAwYBi0IQhhlgA5VHjieBZoImOYFf X-IronPort-AV: E=Sophos;i="4.77,697,1336348800"; d="scan'208,217";a="107672948" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-2.cisco.com with ESMTP; 02 Aug 2012 03:19:52 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q723JqCg000750 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 Aug 2012 03:19:52 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.184]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0298.004; Wed, 1 Aug 2012 22:19:51 -0500 From: "Francois Le Faucheur (flefauch)" To: "Y. Richard Yang" Thread-Topic: [cdni-footprint] [CDNi] CDNI Footprint/Capabilities Design Team - Suggestion to work from simple usecases Thread-Index: AQHNb+6oW4rEbIaOHEianIYA11qX0pdFyngAgABkoQA= Date: Thu, 2 Aug 2012 03:19:51 +0000 Message-ID: <34B323AA-9E77-4C44-B89B-76A1D59F4BEC@cisco.com> References: <2779C9F0771F974CAD742BAE6D9904FE32CE33F7@PALLENE.office.hd> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.123.53] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19078.001 x-tm-as-result: No--63.003900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_34B323AA9E774C44B89B76A1D59F4BECciscocom_" MIME-Version: 1.0 Cc: "cdni-footprint@ietf.org" , "cdni@ietf.org" Subject: Re: [CDNi] [cdni-footprint] CDNI Footprint/Capabilities Design Team - Suggestion to work from simple usecases 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, 02 Aug 2012 03:19:59 -0000 --_000_34B323AA9E774C44B89B76A1D59F4BECciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On 1 Aug 2012, at 14:18, Y. Richard Yang wrote: Hi Francois, Good suggestion. Jon also mentioned that we might want to reread the use ca= se draft, which contains many use cases already. Makes sense. Before we pile in more use cases, I will give a try on the example use case= from your email, as the example already touches on some basic issues. In p= articular, to handle the use case, the uCDN needs the following info from = dCDN[1-4]: - dCDN1 (ISP1) Set11 (good set) of dCDN1's home net -> QoE11 Set12 (poor set) of dCDN1's home net -> QoE12 I do not believe the use case described require that the footprint partitio= n necessarily be mapped into "QoE" levels. Another approach could be to ass= ociate with each partition a hint that reflects some topological properties= (e.g1 there are on-net caches to serve that partition or not, eg2 the nb o= f ASes between caches and partition is 0/1/2/3,=85..). As a starting starting straw-man, I define: propagation-delay bound (ms) [Mandatory] max-supported-per-ua-streaming rate (Kbps) [M] delay-jitter [O] I believe one of the design team decisions is to not try advertise QoS para= meters (at least dynamic ones) along the footprint. As mentioned above, I d= on't think this is called for by the example use cases. Also, the use case I describe is a starting point, but the design team is p= robably going to start by defining the (set of) use case(s) they want to fo= cus on. I suggest we start with that definition before jumping into how to = support the use case example I brought up. Cheers Francois I feel that there are multiple experts on content delivery metrics and we c= an define an initial set. Now we go to dCDN2 (ISP2): Set21 of dCDN2 -> QoE21 Set22 of dCDN2 -> QoE22 ... Note that Set12 intersects with some Set2j. ... Continue this example, an architecture/protocol issue we may face, while th= e content delivery metrics group is working on the metrics, is how the uCDN= will aggregate the reported QoEs to propagate further. One way is the BGP = Best-Path design (applying filtering such as comparison with internal/3rd p= arty measurements) which essential reports a single QoE for each IP. Anothe= r design is exposing multipaths by exposing multiple access points. Clearly= I support the multipaths design. Richard PS: I may suggest the failure/maintainence use case in the use-case draft a= s a next case. As I see an RSVP style protocol flow will come out of it. I = also feel that the affiliation/migration use cases provide another type of = distinct use case (less privacy concern). On Wednesday, August 1, 2012, Francois Le Faucheur (flefauch) wrote: Jan, Stefano, Jon, I just wanted to reiterate the suggestion I made at the very end of the WG = meeting Yesterday. A possible way to make progress might be to: 1) identify one, or a very small number, of use case(s) that we wan= t the CDNI Footprint/Capabilities to support 2) identify the semantics of the required information for this/thes= e specific use cases. While this approach may arguably not allow us to define the most flexible u= niversal solution, it would have the merit of allowing us to define a solut= ion addressing some part of the problem. With respect to 1), I think the design team has already identified ISP CDNs= and global CDNs as targeted dCDNs. So perhaps the use cases of focus could= include something like: * the uCDN wants to use dCDN1 (CDN of ISP1) when the enduser is att= ached to a part of ISP1 and where ISP1 feels the request can be well served= by on-net caches of ISP1 (an interesting flavor of this is where ISP1 has = some of his AS not covered well by his own CDN - e.g. some remote territory= ) * the uCDN wants to use dCDN2 (CDN of ISP 2) when the enduser is at= tached to a part of ISP1 where ISP1 feels the request can _not_ be well ser= ved by on-net caches of ISP1 but where ISP2 claims that the request can be = well served by CDN of ISP2 (because he has caches that - while not "on-net"= on ISP1 - are well connected to ISP1 e.g. via many regional peering points= ) * the uCDN wants to use dCDN3 (a global CDN) when the enduser is at= tached to any other ISP network with whom dCDN3 is well interconnected (e.g= . via many regional peering points) * the uCDN wants to use dCDN 4 (another global CDN) when the enduse= r is attached to an ISP network with whom dCDN3 is not well interconnected = (e.g. via single centralized peering points) I just made that up so it needs more thinking, but take is as an example of= the sort of use case we may want to start from. I hope that helps Francois On 31 Jul 2012, at 18:05, Jan Seedorf wrote: > Several people have indicated that they will come to this meeting, so: "i= t's on" :) Let's meet tomorrow (WED) at 15:00 at the IETF registration desk= to continue our discussions, trying to make some progress ... > > - Jan > >> -----Original Message----- >> From: cdni-footprint-bounces@ietf.org [mailto:cdni-footpri= nt- >> bounces@ietf.org] On Behalf Of Jan Seedorf >> Sent: Wednesday, August 01, 2012 1:18 AM >> To: cdni-footprint@ietf.org >> Cc: Brandenburg, R. (Ray) van (ray.vanbrandenburg@tno.nl);= Enrico >> Marocco; gilles.bertrand@orange.com; emile.stephan@orange.= com; Kevin J >> Ma > (kevin.ma@azukisystems.com<= javascript:;>) >> Subject: Re: [cdni-footprint] Doodle for 2nd CDNI Footprint/Capabilities >> Design Team Side Meeting at IETF-84 >> >> Guys, >> >> Looking at the latest doodle it seems that actually *** WED 15:00-17:00 = *** >> would be a good slot where a reasonable amount of people can make it. So= I >> suggest having another CDNI Footprint/Capabilities Design Team Side >> Meeting at this time. >> >> Please confirm via email if you can actually make this slot, so that we = see if it >> really makes sense to have the meeting (i.e. all people that indicated s= o in >> the doodle really coming). >> >> - Jan >> > _______________________________________________ > 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-footprint mailing list cdni-footprint@ietf.org https://www.ietf.org/mailman/listinfo/cdni-footprint --_000_34B323AA9E774C44B89B76A1D59F4BECciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
On 1 Aug 2012, at 14:18, Y. Richard Yang wrote:

Hi Francois,

Good suggestion. Jon also mentioned that we might want to reread the u= se case draft, which contains many use cases already. 

Makes sense.


Before we pile in more use cases, I will give a try on the example use= case from your email, as the example already touches on some basic issues.= In particular, to handle the use case,  the uCDN needs the following = info from dCDN[1-4]:

- dCDN1 (ISP1)

  Set11 (good set) of dCDN1's home net -> QoE11 
  Set12 (poor set) of dCDN1's home net -> QoE12

I do not believe the use case described require that the footprint par= tition necessarily be mapped into "QoE" levels. Another approach = could be to associate with each partition a hint that reflects some topolog= ical properties (e.g1 there are on-net caches to serve that partition or not, eg2 the nb of ASes between caches and part= ition is 0/1/2/3,=85..).

As a starting starting straw-man, I define:
propagation-delay bound (ms) [Mandatory]
max-supported-per-ua-streaming rate (Kbps) [M]
delay-jitter [O]

I believe one of the design team decisions is to not try advertise QoS= parameters (at least dynamic ones) along the footprint. As mentioned above= , I don't think this is called for by the example use cases.
Also, the use case I describe is a starting point, but the design team= is probably going to start by defining the (set of) use case(s) they want = to focus on. I suggest we start with that definition before jumping into ho= w to support the use case example I brought up. 

Cheers

Francois


I feel that there are multiple experts on content delivery metrics and= we can define an initial set.

Now we go to dCDN2 (ISP2):

  Set21 of dCDN2 -> QoE21
  Set22 of dCDN2 -> QoE22
  ...

  Note that Set12 intersects with some Set2j.

...

Continue this example, an architecture/protocol issue we may face, whi= le the content delivery metrics group is working on the metrics, is how the= uCDN will aggregate the reported QoEs to propagate further. One way is the= BGP Best-Path design (applying filtering such as comparison with internal/3rd party measurements) which e= ssential reports a single QoE for each IP. Another design is exposing multi= paths by exposing multiple= access points. Clearly I support the multipaths design.

Richard

PS: I may suggest the fail= ure/maintainence use case in the use-case draft as a next case. As I see an= RSVP style protocol flow will come out of it. I also feel that the affilia= tion/migration use cases provide another type of distinct use case (less privacy concern).

On Wednesday, August 1, 2012, Francois Le Faucheur (flefauch) wrote:
Jan, Stefano, Jon,

I just wanted to reiterate the suggestion I made at the very end of the WG = meeting Yesterday.

A possible way to make progress might be to:

        1) identify one, or a very small number, of use= case(s) that we want the CDNI Footprint/Capabilities to support

        2) identify the semantics of the required infor= mation for this/these specific use cases.

While this approach may arguably not allow us to define the most flexible u= niversal solution, it would have the merit of allowing us to define a solut= ion addressing some part of the problem.

With respect to 1), I think the design team has already identified ISP CDNs= and global CDNs as targeted dCDNs. So perhaps the use cases of focus could= include something like:
        * the uCDN wants to use dCDN1 (CDN of ISP1) whe= n the enduser is attached to a part of ISP1 and where ISP1 feels the reques= t can be well served by on-net caches of ISP1 (an interesting flavor of thi= s is where ISP1 has some of his AS not covered well by his own CDN - e.g. some remote territory)
        * the uCDN wants to use dCDN2 (CDN of ISP 2) wh= en the enduser is attached to a part of ISP1 where ISP1 feels the request c= an _not_ be well served by on-net caches of ISP1 but where ISP2 claims that= the request can be well served by CDN of ISP2 (because he has caches that - while not "on-net" on ISP1 - are well conne= cted to ISP1 e.g. via many regional peering points)
        * the uCDN wants to use dCDN3 (a global CDN) wh= en the enduser is attached to any other ISP network with whom dCDN3 is well= interconnected (e.g. via many regional peering points)
        * the uCDN wants to use dCDN 4 (another global = CDN) when the enduser is attached to an ISP network with whom dCDN3 is not = well interconnected (e.g. via single centralized peering points)
I just made that up so it needs more thinking, but take is as an example of= the sort of use case we may want to start from.

I hope that helps

Francois

On 31 Jul 2012, at 18:05, Jan Seedorf wrote:

> Several people have indicated that they will come to this meeting, so:= "it's on" :) Let's meet tomorrow (WED) at 15:00 at the IETF regi= stration desk to continue our discussions, trying to make some progress ...=
>
> - Jan
>
>> -----Original Message-----
>> From: cdni-footprint-bounces@ietf.org [mailto:cdni-footprint-
>> bounces@ietf.org] On Behalf Of Jan Seedorf
>> Sent: Wednesday, August 01, 2012 1:18 AM
>> To: cdni-footprint@ietf.org
>> Cc: Brandenburg, R. (Ray) van (ray.vanbrandenburg@tno.nl<= /a>); Enrico
>> Marocco; gilles.bertrand@orange.com; emile.stephan@orange.com; Kevin J
>> Ma <kevin.ma@azukisystems.com> (kevin.= ma@azukisystems.com)
>> Subject: Re: [cdni-footprint] Doodle for 2nd CDNI Footprint/Capabi= lities
>> Design Team Side Meeting at IETF-84
>>
>> Guys,
>>
>> Looking at the latest doodle it seems that actually *** WED 15:00-= 17:00 ***
>> would be a good slot where a reasonable amount of people can make = it. So I
>> suggest having another CDNI Footprint/Capabilities Design Team Sid= e
>> Meeting at this time.
>>
>> Please confirm via email if you can actually make this slot, so th= at we see if it
>> really makes sense to have the meeting (i.e. all people that indic= ated so in
>> the doodle really coming).
>>
>> - Jan
>>
> _______________________________________________
> CDNi mailing list
> https://www.ietf.org/mailman/listinfo/cdni

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

--_000_34B323AA9E774C44B89B76A1D59F4BECciscocom_-- From kevin.ma@azukisystems.com Wed Aug 1 22:04:33 2012 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 207DB21F8B05; Wed, 1 Aug 2012 22:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.342 X-Spam-Level: X-Spam-Status: No, score=-3.342 tagged_above=-999 required=5 tests=[AWL=0.804, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] 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 KePWRxjBVXwW; Wed, 1 Aug 2012 22:04:31 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.244]) by ietfa.amsl.com (Postfix) with ESMTP id 2D0DC21F8B03; Wed, 1 Aug 2012 22:04:29 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id A183CA68589; Thu, 2 Aug 2012 00:43:01 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB015.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 6307CA6839D; Thu, 2 Aug 2012 00:43:00 -0400 (EDT) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB015.mail.lan ([10.110.17.15]) with mapi; Thu, 2 Aug 2012 01:04:06 -0400 From: Kevin J Ma To: "li.mian@zte.com.cn" , "zahariad@synelixis.com" , "cdni@ietf.org" , "cdni-bounces@ietf.org" , 'Bhumip Khasnabish' , "jin.weiyi@zte.com.cn" Date: Thu, 2 Aug 2012 01:04:23 -0400 Thread-Topic: =?utf-8?B?W0NETmldIOetlOWkjTogUmU6ICBGd2Q6CWRyYWZ0LWppbi1jZG5pLWNvbnRl?= =?utf-8?B?bnQtZGVkdXBsaWNhdGlvbi1vcHRpbWl6YXRpb24tMDIudHh0?= Thread-Index: Ac1vskQaGrZkzPwaQD2QRzTr9V9+bgAuIe0A Message-ID: <291CC3F9E50E7641901A54E85D0977C6532706FCC3@MAILR002.mail.lan> References: <005f01cd6f46$5ce667d0$16b33770$@com> 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_291CC3F9E50E7641901A54E85D0977C6532706FCC3MAILR002maill_" MIME-Version: 1.0 Subject: Re: [CDNi] =?utf-8?b?562U5aSNOiBSZTogIEZ3ZDoJZHJhZnQtamluLWNkbmktY29u?= =?utf-8?q?tent-deduplication-optimization-02=2Etxt?= 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, 02 Aug 2012 05:04:33 -0000 --_000_291CC3F9E50E7641901A54E85D0977C6532706FCC3MAILR002maill_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWlhbiBhbmQgQmh1bWlwLA0KDQogIFdoZW4geW91IHNheSBDU1AtdW5pcXVlLCBkb2VzIHRo YXQgaW5jbHVkZSBlbmNvZGluZy11bmlxdWU/DQogIElmIGEgQ0ROIG9yIG90aGVyIGludGVybWVk aWFyeSBtb2RpZmllcyB0aGUgY29udGVudCBpbiBzb21lIHdheSwgaG93DQogIGlzIHRoYXQgcmVm bGVjdGVkIGluIHRoZSBjb250ZW50IElELCBhbmQgaG93IHdvdWxkIHRoYXQgYmUgZW5mb3JjZWQ/ DQoNCiAgVGhlcmUgYXJlIG9yZ2FuaXphdGlvbnMgd2hpY2ggYXJlIGxvb2tpbmcgYXQgY29udGVu dCBpZGVudGlmaWNhdGlvbg0KICAoaHR0cDovL2VpZHIub3JnLyBjb21lcyB0byBtaW5kKS4gIERv ZXMgQ0ROSSBuZWVkIHRvIGRldmVsb3AgaXRzIG93bg0KICAiYXV0aG9yaXRhdGl2ZSAnRW50aXR5 JyIgZm9yIG1hbmFnaW5nIGNvbnRlbnQgSURzLCBvciBkbyB5b3UgZmVlbCB0aGF0DQogdGhlcmUg YXJlIGV4aXN0aW5nIHNlcnZpY2VzL3Byb3RvY29scyB0aGF0IHdvdWxkIHF1YWxpZnkgYXMgY2Fu ZGlkYXRlDQogICdFbnRpdGllcyc/DQoNCnRoYW54Lg0KDQotLSAgS2V2aW4gSi4gTWENCg0KRnJv bTogY2RuaS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86Y2RuaS1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgbGkubWlhbkB6dGUuY29tLmNuDQpTZW50OiBXZWRuZXNkYXksIEF1Z3VzdCAw MSwgMjAxMiAyOjUyIEFNDQpUbzogemFoYXJpYWRAc3luZWxpeGlzLmNvbTsgY2RuaUBpZXRmLm9y ZzsgY2RuaS1ib3VuY2VzQGlldGYub3JnOyAnQmh1bWlwIEtoYXNuYWJpc2gnOyBqaW4ud2VpeWlA enRlLmNvbS5jbg0KU3ViamVjdDogW0NETmldIOetlOWkjTogUmU6IEZ3ZDogZHJhZnQtamluLWNk bmktY29udGVudC1kZWR1cGxpY2F0aW9uLW9wdGltaXphdGlvbi0wMi50eHQNCg0KDQpEZWFyIFRo ZW9kb3JlLA0KDQpUaGFuayB5b3UgZm9yIHlvdXIgY29tbWVudHMgYW5kIHNoYXJpbmcgd2l0aCB1 cyB5b3VyIHByb3Bvc2Fscy4gQ291bGQgeW91IHBsZWFzZSBzaGFyZSB0aGUgZG9jdW1lbnRzIHlv dSBtZW50aW9uZWQgYmVsb3cgd2l0aCBtZT8gQmFzZWQgb24gd2hhdCB5b3UgZXhwbGFpbmVkIGlu IHByZXZpb3VzIGVtYWlsLCBJIGhhdmUgc29tZSBxdWVzdGlvbnMgZm9yIGNsYXJpZmljYXRpb246 DQoxLiBXZSBib3RoIGNvbnNpZGVyIGl0IG5lY2Vzc2FyeSB0byBoYXZlIGEgdW5pcXVlIGNvbnRl bnQgaWRlbnRpZmllciBmb3IgYSBjb250ZW50IG9iamVjdC4gT3VyIG9waW5pb24gaW4gdGhpcyBk cmFmdCBpcyB0aGF0IHRoaXMgY29udGVudCBJRCBpcyBDU1AtdW5pcXVlLiBDb3VsZCB5b3UgcGxl YXNlIGV4cGxhaW4gbW9yZSBhYm91dCB0aGUgdW5pcXVlbmVzcyBvZiB0aGUgVUlEIGluIHlvdXIg cHJvcG9zYWw/DQoyLiBCeSBhcHBseWluZyB0aGUgbWVjaGFuaXNtIHlvdSBwcm9wb3NlZCBiZWxv dywgd2UgY2FuIGd1YXJhbnRlZSB0aGUgY29udGVudCBpcyB1bmlxdWVseSBzdG9yZWQgaW4gb25l IENETi4gQW5kIGFjY29yZGluZyB0byBteSBhbmFseXNpcyBvbiB0aGUgYmFzaXMgb2YgeW91ciBl eHBsYW5hdGlvbiwgdGhlIGNvbnRlbnQgcmVwbGljYXRpb24gaXMgY2hlY2tlZCBieSBjb21wYXJp bmcgdGhlIENVUkwgd2hpY2ggaXMgc2ltaWxhciB0byB0aGUgY3VycmVudCBtZWNoYW5pc20gaW4g Q0ROaSB3b3JrLCBjb3JyZWN0IG1lIGlmIG15IHVuZGVyc3RhbmRpbmcgaXMgd3JvbmcuIElmIHNv LCB3aGVuIHJlZGlyZWN0aW9uIG9jY3VycyBiZXR3ZWVuIHVDRE5zIGFuZCBkQ0ROLCB0aGUgVVJM IHdvdWxkIGJlIGNoYW5nZWQgYW5kIHRodXMgYmUgZGlmZmVyZW50IHdpdGggdGhlIG9yaWdpbmFs IG9uZSAtIENVUkwuIEFuZCBpZiBhIGRDRE4gaXMgY29ubmVjdGVkIHdpdGggdHdvIGRpZmZlcmVu dCB1Q0ROcyBhbmQgdHdvIGVuZCB1c2VycyByZXF1ZXN0IHRoZSBzYW1lIGNvbnRlbnQgZnJvbSB0 aGVzZSB0d28gdUNETnMgcmVzcGVjdGl2ZWx5LCB0aGUgdHdvIHVDRE5zIG1heSBnZW5lcmF0ZSBk aWZmZXJlbnQgcmVkaXJlY3Rpb24gVVJMcyB0byB0aGUgZENETi4gSW4gdGhpcyBjYXNlIHdlIHRo aW5rIHRoZSBjb250ZW50IGR1cGxpY2F0aW9uIGlzc3VlIHN0aWxsIGV4aXN0cy4gSG93IGRvIHlv dSB0aGluaz8gSWYgbXkgdW5kZXJzdGFuZGluZyBpcyB3cm9uZywgY291bGQgeW91IHBsZWFzZSBl eHBsYWluIG1vcmUgb24gaG93IHRvIGNvbnNpZGVyIHRoaXMgaXNzdWUgYnkgdXNpbmcgeW91ciBw cm9wb3NhbD8NCg0KVGhhbmsgeW91IGFnYWlufg0KDQpjZG5pLWJvdW5jZXNAaWV0Zi5vcmc8bWFp bHRvOmNkbmktYm91bmNlc0BpZXRmLm9yZz4g5YaZ5LqOIDIwMTItMDgtMDEgMDI6MDA6MjM6DQoN Cj4gRGVhciBCaHVtaXAsDQo+DQo+IFNvbWUgaWRlYXMgYW5kIGNvbnNpZGVyYXRpb25zIG9uIHRo ZSBkcmFmdC4NCj4NCj4gV2UgaGF2ZSBkb25lIHNvbWUgd29yayBpbiB0aGUgYXJlYSBvZiBkZS1k dXBsaWNhdGlvbiBvZiBjb250ZW50DQo+IChQbGVhc2Ugc2VlIFRoLiBaYWhhcmlhZGlzLCBFLiBR dWFjY2hpbywg4oCcRmFzdCBjb250ZW50LWF3YXJlDQo+IGRlbGl2ZXJ5IGluIG92ZXJsYXkgbmV0 d29ya3Ms4oCdIElFRUUgQ09NU09DIE1NVEMgRS1MZXR0ZXIsIFZvbC42LCBOby4NCj4gNywgSnVs eSAyMDExLCBwcC4gNDQtNDcpKQ0KPg0KPiBBY3R1YWxseSwgd2UgYmVsaWV2ZSB0aGF0IGl0IGlz IG5lZWRlZCB0byBkZWZpbmUgVW5pcXVlIElEcyAoVUlEKQ0KPiBwZXIgY29udGVudCBvYmplY3Qv Y2h1bmsgaW4gb3JkZXIgdG86DQo+IGEpIEF2b2lkIGV4dGVuZGVkIGRhdGEgcmVwbGljYXRpb25z IGF0IHRoZSBDRE4gbGV2ZWwgYW5kIG1pbmltaXplDQo+IHRoZSBsb2FkIHRvIGZpbmQgdGhlIGNv cnJlY3Qgb2JqZWN0Lg0KPiBiKSBEZXRlY3QgYW5kIHJldHJpZXZlIHZlcnkgZmFzdCB0aGUgY29u dGVudC4gVGhpcyBzaG91bGQgYmUgZmFzdA0KPiBlbm91Z2ggdG8gYWxsb3cgZXZlbiBzZWFtbGVz cyByZWFsLXRpbWUgdmlkZW8gc3RyZWFtaW5nIGJ5DQo+IHJldHJpZXZpbmcgdmlkZW8gY2h1bmtz DQo+IGMpIEJlIGJhY2t3YXJkcyBjb21wYXRpYmxlIHdpdGggdG9kYXlz4oCZIFVSTHMgKGluIGNh c2UgdGhlDQo+IGNvbnRlbnQvY2h1bmsgaXMgbm90IGZvdW5kLCB5b3Ugc2hvdWxkIGJlIGFibGUg dG8gZ28gdG8gdGhlIG9yaWdpbmFsIHNpdGUpLg0KPg0KPiBJbiBvcmRlciB0byBtZWV0IHRoZSAo YSksIFVJRCBzaG91bGQgYmUgYWx3YXlzIGFzc29jaWF0ZWQgd2l0aCB0aGUNCj4gY29udGVudCBv YmplY3QgaXRzZWxmIChlLmcuIGVuY2Fwc3VsYXRlZCBpbiB0aGUgb2JqZWN0KSBvciBiZSBiYXNl ZA0KPiBvbiB1bmlxdWUgY2hhcmFjdGVyaXN0aWNzIG9mIHRoZSBjb250ZW50IG9iamVjdCAoZS5n LiBhIHNldCBvZiBsb3cNCj4gbGV2ZWwgZGVzY3JpcHRvcnMpLiBIb3dldmVyLCAoYiksIHBvc2Vz IHRoYXQgdGhpcyBjb3VsZCBiZQ0KPiBjYWxjdWxhdGVkIG9uY2UgKG9yIHNvbWV0aW1lcyksIGJ1 dCBzaG91bGQgbm90IGJlIGNhbGN1bGF0ZWQgb3INCj4gZ2VuZXJhdGVkIGVhY2ggdGltZSB0aGUg b2JqZWN0IGlzIHJlcXVlc3RlZDsgaW5zdGVhZCBpdCBzaG91bGQgYmUNCj4g4oCcY2FycmllZOKA nSBhbmQg4oCcZXh0cmFjdGVk4oCdIGluIG1vc3QgY2FzZXMuICBPbiB0aGUgb3RoZXIgaGFuZCwg ZHVlIHRvDQo+IGJhY2t3YXJkcyBjb21wYXRpYmlsaXR5IG5lZWRzIChjKSwgd2Ugc2hvdWxkIG5v dCBjaGFuZ2UgdGhlIHN0YW5kYXJkDQo+IGZpbGUgZm9ybWF0IChlLmcuIHdlIGNvdWxkIG5vdCBl bmNhcHN1bGF0ZSBVSUQgb3IgbG93IGxldmVsDQo+IGRlc2NyaXB0b3IgaW4gdGhlIGNvbnRlbnQg b2JqZWN0KS4NCj4NCj4gT25lIHNvbHV0aW9uIGNvdWxkIGJlIHRvIGNyZWF0ZSBhIHdyYXBwZXIg dGhhdCB3b3VsZCBlbmNhcHN1bGF0ZSB0aGUNCj4gVUlEIHdoZW5ldmVyIHRoZSBjb250ZW50IG9i amVjdCBlbnRlcnMgdGhlIENETiBhbmQgZXh0cmFjdHMgdGhhdCBhdA0KPiB0aGUgdGltZSB0aGF0 IHRoZSBjb250ZW50IG9iamVjdCBsZWF2ZXMgdGhlIENETiwgYnV0IHRoaXMgd291bGQNCj4gaW5j cmVhc2UgdGhlIGNvbXBsZXhpdHkgYW5kIHByb2Nlc3NpbmcgdGltZS4NCj4NCj4gSW5zdGVhZCwg d2UgcHJvcG9zZSB0byB1c2UgYXMgVUlEIGEgZm9ybWFsIGZpbGUgbmFtZSBmb3JtYXQuIFVJRA0K PiB3aWxsIGJlIGEgc3RyaW5nIGNvbmNhdGVuYXRpb24gaW4gdGhlIGZvcm1hdDoNCj4NCj4gQ00t Q0lELWZpbGVuYW1lLmV4dA0KPg0KPiB3aGVyZToNCj4g4oCiIENNIGlzIGEg4oCcQ29udGVudCBN YXJrZXLigJ0NCj4g4oCiIENJRCBpcyBhIGNvbnRlbnQgc2lnbmF0dXJlLCB3aGljaCBjb3VsZCBi ZSBhIHNlbGYtY2VydGlmeWluZw0KPiBpZGVudGlmaWVyIGUuZy4gTUQ1IG9yIFNIQS0xIGJhc2Vk LWhhc2ggZnVuY3Rpb24gb24gdGhlIGZpbGUncw0KPiBjb250ZW50IG9yIGV2ZW4gYSBjb21iaW5h dGlvbiBvZiBzZWFyY2hhYmxlIGxvdyBsZXZlbCBkZXNjcmlwdG9ycy4gLA0KPiB3aGljaCBndWFy YW50ZWVzIGFuIGVhc3kgYW5kIGZhc3QgZGV0ZWN0aW9uIHRoYXQgdGhpcyBuYW1lIGlzIGEgVUlE DQo+IOKAoiB0aGUgb3JpZ2luYWwgZmlsZW5hbWUsIHdoaWNoIGlzIHVzZWQgZm9yIG1ha2luZyBV SUQgZWFzaWx5DQo+IHJlY29nbml6ZWQgYnkgaHVtYW5zIGFuZCBhdm9pZCBjb21wbGV4IHNlbGYt Y2VydGlmeWluZyBuYW1lcy4NCj4NCj4gV2hlbmV2ZXIgbmV3IGNvbnRlbnQgaXMgcHVibGlzaGVk IG9yIHN0b3JlZCBhdCB0aGUgQ0ROLCB0aGUgb2JqZWN0DQo+IGZpbGVuYW1lIGNvdWxkIGJlIHJl bmFtZWQgdG8gYSBVSUQgYW5kIHRoZSBVUkwgdG8gYSBDb250ZW50IFVSTA0KPiAoQ1VSTCkgd2l0 aCB0aGUNCj4gZm9sbG93aW5nIGZvcm1hdDoNCj4NCj4gaHR0cDovL3d3dy4gd2Vic2l0ZS5jb20v 4oCmL0NNLUNJRC1maWxlbmFtZS5leHQNCj4NCj4gVGhlIENVUkwgaXMgYSBVUkksIHdoaWNoIGlz IGRlc2lnbmVkIHRvIGVuYWJsZSBjYWNoaW5nIG1lY2hhbmlzbXMNCj4gYW5kIHRyaWdnZXIgQ0RO LXJlbGF0ZWQgZnVuY3Rpb25hbGl0eSAoZS5nLiBhY2Nlc3NpbmcgdGhlIENETg0KPiBvdmVybGF5 IG5ldHdvcmsgYW5kIHF1ZXJ5aW5nIGZvciBsb2NhbGx5IG9yIOKAnG5lYXJieeKAnSBjYWNoZWQN Cj4gY29udGVudCkuIEl0IHNob3VsZCBhbHNvIGJlIGVtcGhhc2l6ZWQgdGhhdCBmcm9tIHRoZSBD VVJMLCB0aGUNCj4gb3JpZ2luYWwgVVJMIGFuZCB0aGUgVUlEIG1heSBiZSBlYXNpbHkgZXh0cmFj dGVkLCB3aGlsZSBvbiB0aGUgb3RoZXINCj4gaGFuZCBpdCBpcyBmdWxseSBiYWNrd2FyZHMgY29t cGF0aWJsZSB3aXRoIGV4aXN0aW5nIGJyb3dzZXJzIGFuZCBubw0KPiBtb2RpZmljYXRpb25zIGFy ZSBuZWVkZWQuIEluIHRoaXMgd2F5LCB3ZSBtYXkgc2VhbWxlc3NseSBzdXBwb3J0IGFueQ0KPiBr aW5kIG9mIGRhdGEgYXZhaWxhYmxlIGluIHRoZSBJbnRlcm5ldCAodGV4dCwgaW1hZ2VzLCB2YXJp b3VzIHR5cGVzDQo+IG9mIGF1ZGlvIG9yIHZpZGVvKSwgd2hpbGUgaW4gY2FzZSB0aGUgY29udGVu dCBvYmplY3QgaXMgbm90IGNhY2hlZA0KPiBpbiB0aGUgQ0ROLCB3ZSBjYW4gYWx3YXlzIGdvIGJh Y2sgdG8gdGhlIG9yaWdpbmFsIHNvdXJjZSBVUkwuDQo+DQo+IEJlc3QgcmVnYXJkcywNCj4gVGhl b2RvcmUNCj4NCj4gRnJvbTogY2RuaS1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpjZG5pLWJvdW5j ZXNAaWV0Zi5vcmc+IFttYWlsdG86Y2RuaS1ib3VuY2VzQGlldGYub3JnXTxtYWlsdG86W21haWx0 bzpjZG5pLWJvdW5jZXNAaWV0Zi5vcmddPiBPbiBCZWhhbGYgT2YNCj4gQmh1bWlwIEtoYXNuYWJp c2gNCj4gU2VudDogVHVlc2RheSwgSnVseSAzMSwgMjAxMiA4OjQ0IFBNDQo+IFRvOiBjZG5pQGll dGYub3JnPG1haWx0bzpjZG5pQGlldGYub3JnPg0KPiBTdWJqZWN0OiBbQ0ROaV0gRndkOiBkcmFm dC1qaW4tY2RuaS1jb250ZW50LWRlZHVwbGljYXRpb24tb3B0aW1pemF0aW9uLTAyLnR4dA0KPg0K Pg0KPiBUbzogaS1kLWFubm91bmNlIGF0IGlldGYub3JnDQo+IFN1YmplY3Q6IEktRCBBY3Rpb246 IGRyYWZ0LWppbi1jZG5pLWNvbnRlbnQtZGVkdXBsaWNhdGlvbi1vcHRpbWl6YXRpb24tMDIudHh0 DQo+IEZyb206IGludGVybmV0LWRyYWZ0cyBhdCBpZXRmLm9yZw0KPiBEYXRlOiBTdW4sIDI5IEp1 bCAyMDEyIDE5OjI5OjE0IC0wNzAwDQo+IERlbGl2ZXJlZC10bzogaS1kLWFubm91bmNlIGF0IGll dGZhLmFtc2wuY29tDQo+IExpc3QtYXJjaGl2ZTogPGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1h cmNoaXZlL3dlYi9pLWQtYW5ub3VuY2U+DQo+IExpc3QtaGVscDogPG1haWx0bzppLWQtYW5ub3Vu Y2UtcmVxdWVzdEBpZXRmLm9yZz9zdWJqZWN0PWhlbHA+DQo+IExpc3QtaWQ6IEludGVybmV0IERy YWZ0IEFubm91bmNlbWVudHMgb25seSA8aS1kLWFubm91bmNlLmlldGYub3JnPg0KPiBMaXN0LXBv c3Q6IDxtYWlsdG86aS1kLWFubm91bmNlQGlldGYub3JnPg0KPiBMaXN0LXN1YnNjcmliZTogPGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlPiwgPA0KPiBt YWlsdG86aS1kLWFubm91bmNlLXJlcXVlc3RAaWV0Zi5vcmc/c3ViamVjdD1zdWJzY3JpYmU+DQo+ IExpc3QtdW5zdWJzY3JpYmU6IDxodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL29wdGlvbnMv aS1kLWFubm91bmNlPiwgPA0KPiBtYWlsdG86aS1kLWFubm91bmNlLXJlcXVlc3RAaWV0Zi5vcmc/ c3ViamVjdD11bnN1YnNjcmliZT4NCj4gUmVwbHktdG86IGludGVybmV0LWRyYWZ0cyBhdCBpZXRm Lm9yZw0KPg0KPiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24t bGluZSBJbnRlcm5ldC1EcmFmdHMNCj4gZGlyZWN0b3JpZXMuDQo+DQo+DQo+ICAgICAgICAgVGl0 bGUgICAgICAgICAgIDogQ29udGVudCBEZS1kdXBsaWNhdGlvbiBmb3IgQ0ROaSBPcHRpbWl6YXRp b24NCj4gICAgICAgICBBdXRob3IocykgICAgICAgOiBXZWlZaSBKaW4NCj4gICAgICAgICAgICAg ICAgICAgICAgICAgICBNaWFuIExpDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgQmh1bWlw IEtoYXNuYWJpc2gNCj4gICAgICAgICBGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1qaW4tY2RuaS1j b250ZW50LWRlZHVwbGljYXRpb24tDQo+IG9wdGltaXphdGlvbi0wMi50eHQNCj4gICAgICAgICBQ YWdlcyAgICAgICAgICAgOiAxNw0KPiAgICAgICAgIERhdGUgICAgICAgICAgICA6IDIwMTItMDct MjkNCj4NCj4gQWJzdHJhY3Q6DQo+ICAgIFJlY2VudCBleHBsb3NpdmUgZ3Jvd3RoIG9mIGNvbnRl bnQgZGVsaXZlcnkvZGlzdHJpYnV0aW9uIG5ldHdvcmtzDQo+ICAgIChDRE5zKSBhbmQgdGhlaXIg aW50ZXJjb25uZWN0aW9uIGFyZSBjYXVzaW5nIHVuaW50ZW5kZWQgcmVwZXRpdGlvbiBvZg0KPiAg ICBjb250ZW50IHN0b3JhZ2UgaW4gdGhlIHNhbWUgZENETi4gIFRoaXMgY2FuIGJlIGF2b2lkZWQg YnkgdXNpbmcgYQ0KPiAgICBzdWl0YWJsZSBkZS1kdXBsaWNhdGlvbiBtZWNoYW5pc20uICBUaGlz IGRvY3VtZW50IGV4cGxvcmVzIHRoZQ0KPiAgICBzY2VuYXJpb3Mgd2hpY2ggY3JlYXRlIHRoZSBw cm9ibGVtcywgYW5kIHRoZW4gZGlzY3Vzc2VzIHRoZQ0KPiAgICBhcHByb2FjaGVzIHRvIGVsaW1p bmF0ZSB0aGUgZHVwbGljYXRlZCB0cmFuc21pc3Npb24gb2YgdGhlIHNhbWUNCj4gICAgY29udGVu dCBmcm9tIHVDRE4ocykgdG8gZENETiBpbiBDRE5pIG5ldHdvcmtzLiAgVG8gaW1wbGVtZW50IHRo ZQ0KPiAgICBvcHRpbWl6YXRpb24sIHNvbWUgZW5oYW5jZW1lbnRzIHRvIHRoZSBDRE5pIG1ldGFk YXRhIG1vZGVsIGFuZA0KPiAgICBpbnRlcmZhY2UgYXJlIHJlcXVpcmVkLg0KPg0KPg0KPiBUaGUg SUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCj4gaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtamluLWNkbmktY29udGVudC0NCj4gZGVk dXBsaWNhdGlvbi1vcHRpbWl6YXRpb24NCj4NCj4gVGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVy c2lvbiBhdmFpbGFibGUgYXQ6DQo+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWpp bi1jZG5pLWNvbnRlbnQtZGVkdXBsaWNhdGlvbi0NCj4gb3B0aW1pemF0aW9uLTAyDQo+DQo+IEEg ZGlmZiBmcm9tIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KPiBodHRwOi8vdG9v bHMuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWppbi1jZG5pLWNvbnRlbnQtDQo+IGRlZHVw bGljYXRpb24tb3B0aW1pemF0aW9uLTAyDQo+DQo+DQo+IEludGVybmV0LURyYWZ0cyBhcmUgYWxz byBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4gZnRwOi8vZnRwLmlldGYub3JnL2lu dGVybmV0LWRyYWZ0cy8NCj4gIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+IENETmkgbWFpbGluZyBsaXN0DQo+IENETmlAaWV0Zi5vcmc8bWFpbHRvOkNE TmlAaWV0Zi5vcmc+DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2Ru aQ0K --_000_291CC3F9E50E7641901A54E85D0977C6532706FCC3MAILR002maill_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Ik1TIEdvdGhpYyI7 DQoJcGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseToiTVMgR290aGljIjsNCglwYW5vc2UtMToyIDExIDYgOSA3IDIgNSA4IDIgNDt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAx MSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBNUyBHb3Ro aWMiOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDcgMiA1IDggMiA0O30NCkBmb250LWZhY2UNCgl7Zm9u dC1mYW1pbHk6Ik1TIFVJIEdvdGhpYyI7DQoJcGFub3NlLTE6MiAxMSA2IDAgNyAyIDUgOCAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBNUyBVSSBHb3RoaWMiOw0KCXBhbm9zZS0x OjIgMTEgNiAwIDcgMiA1IDggMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05v cm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQp0dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Ijt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAx MS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8 L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0 IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNo YXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPjwvaGVhZD48Ym9keSBsYW5nPUVOLVVTIGxpbms9 Ymx1ZSB2bGluaz1wdXJwbGU+PGRpdiBjbGFzcz1Xb3JkU2VjdGlvbjE+PHAgY2xhc3M9TXNvTm9y bWFsPjx0dD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+SGkgTWlhbiBhbmQgQmh1bWlw LDxvOnA+PC9vOnA+PC9zcGFuPjwvdHQ+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48dHQ+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvdHQ+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48dHQ+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPsKg IFdoZW4geW91IHNheSBDU1AtdW5pcXVlLCBkb2VzIHRoYXQgaW5jbHVkZSBlbmNvZGluZy11bmlx dWU/PG86cD48L286cD48L3NwYW4+PC90dD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjx0dD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+wqAgSWYgYSBDRE4gb3Igb3RoZXIgaW50ZXJtZWRp YXJ5IG1vZGlmaWVzIHRoZSBjb250ZW50IGluIHNvbWUgd2F5LCBob3c8bzpwPjwvbzpwPjwvc3Bh bj48L3R0PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHR0PjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0Jz7CoCBpcyB0aGF0IHJlZmxlY3RlZCBpbiB0aGUgY29udGVudCBJRCwgYW5kIGhvdyB3 b3VsZCB0aGF0IGJlIGVuZm9yY2VkPzxvOnA+PC9vOnA+PC9zcGFuPjwvdHQ+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48dHQ+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvdHQ+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48dHQ+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQnPsKgIFRoZXJlIGFyZSBvcmdhbml6YXRpb25zIHdoaWNoIGFyZSBs b29raW5nIGF0IGNvbnRlbnQgaWRlbnRpZmljYXRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3R0Pjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHR0PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz7C oCAoPGEgaHJlZj0iaHR0cDovL2VpZHIub3JnLyI+aHR0cDovL2VpZHIub3JnLzwvYT4gY29tZXMg dG8gbWluZCkuwqAgRG9lcyBDRE5JIG5lZWQgdG8gZGV2ZWxvcCBpdHMgb3duPG86cD48L286cD48 L3NwYW4+PC90dD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjx0dD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdCc+wqAgJnF1b3Q7YXV0aG9yaXRhdGl2ZSAnRW50aXR5JyZxdW90OyBmb3IgbWFu YWdpbmcgY29udGVudCBJRHMsIG9yIGRvIHlvdSBmZWVsIHRoYXQ8bzpwPjwvbzpwPjwvc3Bhbj48 L3R0PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHR0PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0Jz4gwqB0aGVyZSBhcmUgZXhpc3Rpbmcgc2VydmljZXMvcHJvdG9jb2xzIHRoYXQgd291bGQg cXVhbGlmeSBhcyBjYW5kaWRhdGU8bzpwPjwvbzpwPjwvc3Bhbj48L3R0PjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHR0PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz7CoCAnRW50aXRpZXMn PzxvOnA+PC9vOnA+PC9zcGFuPjwvdHQ+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48dHQ+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvdHQ+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48dHQ+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPnRo YW54LjxvOnA+PC9vOnA+PC9zcGFuPjwvdHQ+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48dHQ+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvdHQ+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48dHQ+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQn Pi0twqAgS2V2aW4gSi4gTWE8L3NwYW4+PC90dD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseToiQ291cmllciBOZXciJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyInPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2IHN0eWxlPSdib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4g NC4wcHQnPjxkaXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVD NERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4nPjxwIGNsYXNzPU1zb05vcm1hbD48 Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fu cy1zZXJpZiInPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPiBjZG5pLWJvdW5jZXNAaWV0Zi5vcmcg W21haWx0bzpjZG5pLWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9uIEJlaGFsZiBPZiA8L2I+bGkubWlh bkB6dGUuY29tLmNuPGJyPjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEF1Z3VzdCAwMSwgMjAxMiAy OjUyIEFNPGJyPjxiPlRvOjwvYj4gemFoYXJpYWRAc3luZWxpeGlzLmNvbTsgY2RuaUBpZXRmLm9y ZzsgY2RuaS1ib3VuY2VzQGlldGYub3JnOyAnQmh1bWlwIEtoYXNuYWJpc2gnOyBqaW4ud2VpeWlA enRlLmNvbS5jbjxicj48Yj5TdWJqZWN0OjwvYj4gW0NETmldIDwvc3Bhbj48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiTVMgVUkgR290aGljIiwic2Fucy1zZXJpZiIn PuetlOWkjTwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToi VGFob21hIiwic2Fucy1zZXJpZiInPjogUmU6IEZ3ZDogZHJhZnQtamluLWNkbmktY29udGVudC1k ZWR1cGxpY2F0aW9uLW9wdGltaXphdGlvbi0wMi50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48YnI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6bmF2eSc+RGVhciBUaGVvZG9yZSw8L3NwYW4+IDxi cj48YnI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwi c2Fucy1zZXJpZiI7Y29sb3I6bmF2eSc+VGhhbmsgeW91IGZvciB5b3VyIGNvbW1lbnRzIGFuZCBz aGFyaW5nIHdpdGggdXMgeW91ciBwcm9wb3NhbHMuIENvdWxkIHlvdSBwbGVhc2Ugc2hhcmUgdGhl IGRvY3VtZW50cyB5b3UgbWVudGlvbmVkIGJlbG93IHdpdGggbWU/IEJhc2VkIG9uIHdoYXQgeW91 IGV4cGxhaW5lZCBpbiBwcmV2aW91cyBlbWFpbCwgSSBoYXZlIHNvbWUgcXVlc3Rpb25zIGZvciBj bGFyaWZpY2F0aW9uOjwvc3Bhbj4gPGJyPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiO2NvbG9yOm5hdnknPjEuIFdlIGJvdGggY29u c2lkZXIgaXQgbmVjZXNzYXJ5IHRvIGhhdmUgYSB1bmlxdWUgY29udGVudCBpZGVudGlmaWVyIGZv ciBhIGNvbnRlbnQgb2JqZWN0LiBPdXIgb3BpbmlvbiBpbiB0aGlzIGRyYWZ0IGlzIHRoYXQgdGhp cyBjb250ZW50IElEIGlzIENTUC11bmlxdWUuIENvdWxkIHlvdSBwbGVhc2UgZXhwbGFpbiBtb3Jl IGFib3V0IHRoZSB1bmlxdWVuZXNzIG9mIHRoZSBVSUQgaW4geW91ciBwcm9wb3NhbD88L3NwYW4+ IDxicj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJz YW5zLXNlcmlmIjtjb2xvcjpuYXZ5Jz4yLiBCeSBhcHBseWluZyB0aGUgbWVjaGFuaXNtIHlvdSBw cm9wb3NlZCBiZWxvdywgd2UgY2FuIGd1YXJhbnRlZSB0aGUgY29udGVudCBpcyB1bmlxdWVseSBz dG9yZWQgaW4gb25lIENETi4gQW5kIGFjY29yZGluZyB0byBteSBhbmFseXNpcyBvbiB0aGUgYmFz aXMgb2YgeW91ciBleHBsYW5hdGlvbiwgdGhlIGNvbnRlbnQgcmVwbGljYXRpb24gaXMgY2hlY2tl ZCBieSBjb21wYXJpbmcgdGhlIENVUkwgd2hpY2ggaXMgc2ltaWxhciB0byB0aGUgY3VycmVudCBt ZWNoYW5pc20gaW4gQ0ROaSB3b3JrLCBjb3JyZWN0IG1lIGlmIG15IHVuZGVyc3RhbmRpbmcgaXMg d3JvbmcuIElmIHNvLCB3aGVuIHJlZGlyZWN0aW9uIG9jY3VycyBiZXR3ZWVuIHVDRE5zIGFuZCBk Q0ROLCB0aGUgVVJMIHdvdWxkIGJlIGNoYW5nZWQgYW5kIHRodXMgYmUgZGlmZmVyZW50IHdpdGgg dGhlIG9yaWdpbmFsIG9uZSAtIENVUkwuIEFuZCBpZiBhIGRDRE4gaXMgY29ubmVjdGVkIHdpdGgg dHdvIGRpZmZlcmVudCB1Q0ROcyBhbmQgdHdvIGVuZCB1c2VycyByZXF1ZXN0IHRoZSBzYW1lIGNv bnRlbnQgZnJvbSB0aGVzZSB0d28gdUNETnMgcmVzcGVjdGl2ZWx5LCB0aGUgdHdvIHVDRE5zIG1h eSBnZW5lcmF0ZSBkaWZmZXJlbnQgcmVkaXJlY3Rpb24gVVJMcyB0byB0aGUgZENETi4gSW4gdGhp cyBjYXNlIHdlIHRoaW5rIHRoZSBjb250ZW50IGR1cGxpY2F0aW9uIGlzc3VlIHN0aWxsIGV4aXN0 cy4gSG93IGRvIHlvdSB0aGluaz8gSWYgbXkgdW5kZXJzdGFuZGluZyBpcyB3cm9uZywgY291bGQg eW91IHBsZWFzZSBleHBsYWluIG1vcmUgb24gaG93IHRvIGNvbnNpZGVyIHRoaXMgaXNzdWUgYnkg dXNpbmcgeW91ciBwcm9wb3NhbD88L3NwYW4+IDxicj48YnI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6bmF2eSc+VGhh bmsgeW91IGFnYWlufjwvc3Bhbj4gPGJyPjxicj48dHQ+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQnPjxhIGhyZWY9Im1haWx0bzpjZG5pLWJvdW5jZXNAaWV0Zi5vcmciPmNkbmktYm91bmNl c0BpZXRmLm9yZzwvYT4gPC9zcGFuPjwvdHQ+PHR0PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiJNUyBHb3RoaWMiJz7lhpnkuo48L3NwYW4+PC90dD48dHQ+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPiAyMDEyLTA4LTAxIDAyOjAwOjIzOjwvc3Bhbj48L3R0 PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIn Pjxicj48YnI+PHR0PiZndDsgRGVhciBCaHVtaXAsIDwvdHQ+PC9zcGFuPjxicj48dHQ+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPiZndDsgJm5ic3A7PC9zcGFuPjwvdHQ+IDxicj48dHQ+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPiZndDsgU29tZSBpZGVhcyBhbmQgY29uc2lk ZXJhdGlvbnMgb24gdGhlIGRyYWZ0Ljwvc3Bhbj48L3R0PiA8YnI+PHR0PjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0Jz4mZ3Q7ICZuYnNwOzwvc3Bhbj48L3R0PiA8YnI+PHR0PjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0Jz4mZ3Q7IFdlIGhhdmUgZG9uZSBzb21lIHdvcmsgaW4gdGhl IGFyZWEgb2YgZGUtZHVwbGljYXRpb24gb2YgY29udGVudCA8L3NwYW4+PC90dD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz48YnI+PHR0PiZn dDsgKFBsZWFzZSBzZWUgVGguIFphaGFyaWFkaXMsIEUuIFF1YWNjaGlvLCDigJxGYXN0IGNvbnRl bnQtYXdhcmUgPC90dD48YnI+PHR0PiZndDsgZGVsaXZlcnkgaW4gb3ZlcmxheSBuZXR3b3Jrcyzi gJ0gSUVFRSBDT01TT0MgTU1UQyBFLUxldHRlciwgVm9sLjYsIE5vLjwvdHQ+PGJyPjx0dD4mZ3Q7 IDcsIEp1bHkgMjAxMSwgcHAuIDQ0LTQ3KSk8L3R0Pjwvc3Bhbj4gPGJyPjx0dD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdCc+Jmd0OyAmbmJzcDs8L3NwYW4+PC90dD4gPGJyPjx0dD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+Jmd0OyBBY3R1YWxseSwgd2UgYmVsaWV2ZSB0aGF0 IGl0IGlzIG5lZWRlZCB0byBkZWZpbmUgVW5pcXVlIElEcyAoVUlEKSA8L3NwYW4+PC90dD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz48YnI+ PHR0PiZndDsgcGVyIGNvbnRlbnQgb2JqZWN0L2NodW5rIGluIG9yZGVyIHRvOiA8L3R0Pjwvc3Bh bj48YnI+PHR0PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz4mZ3Q7IGEpIEF2b2lkIGV4 dGVuZGVkIGRhdGEgcmVwbGljYXRpb25zIGF0IHRoZSBDRE4gbGV2ZWwgYW5kIG1pbmltaXplIDwv c3Bhbj48L3R0PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyInPjxicj48dHQ+Jmd0OyB0aGUgbG9hZCB0byBmaW5kIHRoZSBjb3JyZWN0IG9iamVj dC48L3R0Pjwvc3Bhbj4gPGJyPjx0dD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+Jmd0 OyBiKSBEZXRlY3QgYW5kIHJldHJpZXZlIHZlcnkgZmFzdCB0aGUgY29udGVudC4gVGhpcyBzaG91 bGQgYmUgZmFzdCA8L3NwYW4+PC90dD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseToiQ291cmllciBOZXciJz48YnI+PHR0PiZndDsgZW5vdWdoIHRvIGFsbG93IGV2ZW4g c2VhbWxlc3MgcmVhbC10aW1lIHZpZGVvIHN0cmVhbWluZyBieSA8L3R0Pjxicj48dHQ+Jmd0OyBy ZXRyaWV2aW5nIHZpZGVvIGNodW5rcyA8L3R0Pjwvc3Bhbj48YnI+PHR0PjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0Jz4mZ3Q7IGMpIEJlIGJhY2t3YXJkcyBjb21wYXRpYmxlIHdpdGggdG9k YXlz4oCZIFVSTHMgKGluIGNhc2UgdGhlIDwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPjxicj48dHQ+Jmd0OyBjb250ZW50 L2NodW5rIGlzIG5vdCBmb3VuZCwgeW91IHNob3VsZCBiZSBhYmxlIHRvIGdvIHRvIHRoZSBvcmln aW5hbCBzaXRlKS48L3R0Pjwvc3Bhbj4gPGJyPjx0dD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdCc+Jmd0OyAmbmJzcDs8L3NwYW4+PC90dD4gPGJyPjx0dD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdCc+Jmd0OyBJbiBvcmRlciB0byBtZWV0IHRoZSAoYSksIFVJRCBzaG91bGQgYmUg YWx3YXlzIGFzc29jaWF0ZWQgd2l0aCB0aGUgPC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+PGJyPjx0dD4mZ3Q7IGNvbnRl bnQgb2JqZWN0IGl0c2VsZiAoZS5nLiBlbmNhcHN1bGF0ZWQgaW4gdGhlIG9iamVjdCkgb3IgYmUg YmFzZWQgPC90dD48YnI+PHR0PiZndDsgb24gdW5pcXVlIGNoYXJhY3RlcmlzdGljcyBvZiB0aGUg Y29udGVudCBvYmplY3QgKGUuZy4gYSBzZXQgb2YgbG93IDwvdHQ+PGJyPjx0dD4mZ3Q7IGxldmVs IGRlc2NyaXB0b3JzKS4gSG93ZXZlciwgKGIpLCBwb3NlcyB0aGF0IHRoaXMgY291bGQgYmUgPC90 dD48YnI+PHR0PiZndDsgY2FsY3VsYXRlZCBvbmNlIChvciBzb21ldGltZXMpLCBidXQgc2hvdWxk IG5vdCBiZSBjYWxjdWxhdGVkIG9yIDwvdHQ+PGJyPjx0dD4mZ3Q7IGdlbmVyYXRlZCBlYWNoIHRp bWUgdGhlIG9iamVjdCBpcyByZXF1ZXN0ZWQ7IGluc3RlYWQgaXQgc2hvdWxkIGJlIDwvdHQ+PGJy Pjx0dD4mZ3Q7IOKAnGNhcnJpZWTigJ0gYW5kIOKAnGV4dHJhY3RlZOKAnSBpbiBtb3N0IGNhc2Vz LiAmbmJzcDtPbiB0aGUgb3RoZXIgaGFuZCwgZHVlIHRvIDwvdHQ+PGJyPjx0dD4mZ3Q7IGJhY2t3 YXJkcyBjb21wYXRpYmlsaXR5IG5lZWRzIChjKSwgd2Ugc2hvdWxkIG5vdCBjaGFuZ2UgdGhlIHN0 YW5kYXJkPC90dD48YnI+PHR0PiZndDsgZmlsZSBmb3JtYXQgKGUuZy4gd2UgY291bGQgbm90IGVu Y2Fwc3VsYXRlIFVJRCBvciBsb3cgbGV2ZWwgPC90dD48YnI+PHR0PiZndDsgZGVzY3JpcHRvciBp biB0aGUgY29udGVudCBvYmplY3QpLiA8L3R0Pjwvc3Bhbj48YnI+PHR0PjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0Jz4mZ3Q7ICZuYnNwOzwvc3Bhbj48L3R0PiA8YnI+PHR0PjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0Jz4mZ3Q7IE9uZSBzb2x1dGlvbiBjb3VsZCBiZSB0byBjcmVh dGUgYSB3cmFwcGVyIHRoYXQgd291bGQgZW5jYXBzdWxhdGUgdGhlPC9zcGFuPjwvdHQ+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+PGJyPjx0 dD4mZ3Q7IFVJRCB3aGVuZXZlciB0aGUgY29udGVudCBvYmplY3QgZW50ZXJzIHRoZSBDRE4gYW5k IGV4dHJhY3RzIHRoYXQgYXQgPC90dD48YnI+PHR0PiZndDsgdGhlIHRpbWUgdGhhdCB0aGUgY29u dGVudCBvYmplY3QgbGVhdmVzIHRoZSBDRE4sIGJ1dCB0aGlzIHdvdWxkIDwvdHQ+PGJyPjx0dD4m Z3Q7IGluY3JlYXNlIHRoZSBjb21wbGV4aXR5IGFuZCBwcm9jZXNzaW5nIHRpbWUuPC90dD48L3Nw YW4+IDxicj48dHQ+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPiZndDsgJm5ic3A7PC9z cGFuPjwvdHQ+IDxicj48dHQ+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPiZndDsgSW5z dGVhZCwgd2UgcHJvcG9zZSB0byB1c2UgYXMgVUlEIGEgZm9ybWFsIGZpbGUgbmFtZSBmb3JtYXQu IFVJRCA8L3NwYW4+PC90dD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eToiQ291cmllciBOZXciJz48YnI+PHR0PiZndDsgd2lsbCBiZSBhIHN0cmluZyBjb25jYXRlbmF0 aW9uIGluIHRoZSBmb3JtYXQ6IDwvdHQ+PC9zcGFuPjxicj48dHQ+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQnPiZndDsgJm5ic3A7PC9zcGFuPjwvdHQ+IDxicj48dHQ+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQnPiZndDsgQ00tQ0lELWZpbGVuYW1lLmV4dCA8L3NwYW4+PC90dD48 YnI+PHR0PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz4mZ3Q7ICZuYnNwOzwvc3Bhbj48 L3R0PiA8YnI+PHR0PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz4mZ3Q7IHdoZXJlOjwv c3Bhbj48L3R0PiA8YnI+PHR0PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz4mZ3Q7IOKA oiBDTSBpcyBhIOKAnENvbnRlbnQgTWFya2Vy4oCdIDwvc3Bhbj48L3R0Pjxicj48dHQ+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPiZndDsg4oCiIENJRCBpcyBhIGNvbnRlbnQgc2lnbmF0 dXJlLCB3aGljaCBjb3VsZCBiZSBhIHNlbGYtY2VydGlmeWluZyA8L3NwYW4+PC90dD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz48YnI+PHR0 PiZndDsgaWRlbnRpZmllciBlLmcuIE1ENSBvciBTSEEtMSBiYXNlZC1oYXNoIGZ1bmN0aW9uIG9u IHRoZSBmaWxlJ3MgPC90dD48YnI+PHR0PiZndDsgY29udGVudCBvciBldmVuIGEgY29tYmluYXRp b24gb2Ygc2VhcmNoYWJsZSBsb3cgbGV2ZWwgZGVzY3JpcHRvcnMuICw8L3R0Pjxicj48dHQ+Jmd0 OyB3aGljaCBndWFyYW50ZWVzIGFuIGVhc3kgYW5kIGZhc3QgZGV0ZWN0aW9uIHRoYXQgdGhpcyBu YW1lIGlzIGEgVUlEPC90dD48L3NwYW4+IDxicj48dHQ+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQnPiZndDsg4oCiIHRoZSBvcmlnaW5hbCBmaWxlbmFtZSwgd2hpY2ggaXMgdXNlZCBmb3Ig bWFraW5nIFVJRCBlYXNpbHkgPC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+PGJyPjx0dD4mZ3Q7IHJlY29nbml6ZWQgYnkg aHVtYW5zIGFuZCBhdm9pZCBjb21wbGV4IHNlbGYtY2VydGlmeWluZyBuYW1lcy48L3R0Pjwvc3Bh bj4gPGJyPjx0dD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+Jmd0OyAmbmJzcDs8L3Nw YW4+PC90dD4gPGJyPjx0dD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+Jmd0OyBXaGVu ZXZlciBuZXcgY29udGVudCBpcyBwdWJsaXNoZWQgb3Igc3RvcmVkIGF0IHRoZSBDRE4sIHRoZSBv YmplY3QgPC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Iic+PGJyPjx0dD4mZ3Q7IGZpbGVuYW1lIGNvdWxkIGJlIHJlbmFtZWQg dG8gYSBVSUQgYW5kIHRoZSBVUkwgdG8gYSBDb250ZW50IFVSTCA8L3R0Pjxicj48dHQ+Jmd0OyAo Q1VSTCkgd2l0aCB0aGUgPC90dD48L3NwYW4+PGJyPjx0dD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdCc+Jmd0OyBmb2xsb3dpbmcgZm9ybWF0OiA8L3NwYW4+PC90dD48YnI+PHR0PjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz4mZ3Q7ICZuYnNwOzwvc3Bhbj48L3R0PiA8YnI+PHR0 PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz4mZ3Q7IDxhIGhyZWY9Imh0dHA6Ly93d3ci Pmh0dHA6Ly93d3c8L2E+LiB3ZWJzaXRlLmNvbS/igKYvQ00tQ0lELWZpbGVuYW1lLmV4dDwvc3Bh bj48L3R0PiA8YnI+PHR0PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz4mZ3Q7ICZuYnNw Ozwvc3Bhbj48L3R0PiA8YnI+PHR0PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz4mZ3Q7 IFRoZSBDVVJMIGlzIGEgVVJJLCB3aGljaCBpcyBkZXNpZ25lZCB0byBlbmFibGUgY2FjaGluZyBt ZWNoYW5pc21zIDwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyInPjxicj48dHQ+Jmd0OyBhbmQgdHJpZ2dlciBDRE4tcmVsYXRl ZCBmdW5jdGlvbmFsaXR5IChlLmcuIGFjY2Vzc2luZyB0aGUgQ0ROIDwvdHQ+PGJyPjx0dD4mZ3Q7 IG92ZXJsYXkgbmV0d29yayBhbmQgcXVlcnlpbmcgZm9yIGxvY2FsbHkgb3Ig4oCcbmVhcmJ54oCd IGNhY2hlZCA8L3R0Pjxicj48dHQ+Jmd0OyBjb250ZW50KS4gSXQgc2hvdWxkIGFsc28gYmUgZW1w aGFzaXplZCB0aGF0IGZyb20gdGhlIENVUkwsIHRoZSA8L3R0Pjxicj48dHQ+Jmd0OyBvcmlnaW5h bCBVUkwgYW5kIHRoZSBVSUQgbWF5IGJlIGVhc2lseSBleHRyYWN0ZWQsIHdoaWxlIG9uIHRoZSBv dGhlcjwvdHQ+PGJyPjx0dD4mZ3Q7IGhhbmQgaXQgaXMgZnVsbHkgYmFja3dhcmRzIGNvbXBhdGli bGUgd2l0aCBleGlzdGluZyBicm93c2VycyBhbmQgbm8gPC90dD48YnI+PHR0PiZndDsgbW9kaWZp Y2F0aW9ucyBhcmUgbmVlZGVkLiBJbiB0aGlzIHdheSwgd2UgbWF5IHNlYW1sZXNzbHkgc3VwcG9y dCBhbnk8L3R0Pjxicj48dHQ+Jmd0OyBraW5kIG9mIGRhdGEgYXZhaWxhYmxlIGluIHRoZSBJbnRl cm5ldCAodGV4dCwgaW1hZ2VzLCB2YXJpb3VzIHR5cGVzIDwvdHQ+PGJyPjx0dD4mZ3Q7IG9mIGF1 ZGlvIG9yIHZpZGVvKSwgd2hpbGUgaW4gY2FzZSB0aGUgY29udGVudCBvYmplY3QgaXMgbm90IGNh Y2hlZCA8L3R0Pjxicj48dHQ+Jmd0OyBpbiB0aGUgQ0ROLCB3ZSBjYW4gYWx3YXlzIGdvIGJhY2sg dG8gdGhlIG9yaWdpbmFsIHNvdXJjZSBVUkwuPC90dD48L3NwYW4+IDxicj48dHQ+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPiZndDsgJm5ic3A7PC9zcGFuPjwvdHQ+IDxicj48dHQ+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPiZndDsgQmVzdCByZWdhcmRzLDwvc3Bhbj48L3R0 PiA8YnI+PHR0PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz4mZ3Q7IFRoZW9kb3JlPC9z cGFuPjwvdHQ+IDxicj48dHQ+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPiZndDsgJm5i c3A7PC9zcGFuPjwvdHQ+IDxicj48dHQ+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPiZn dDsgRnJvbTogPGEgaHJlZj0ibWFpbHRvOmNkbmktYm91bmNlc0BpZXRmLm9yZyI+Y2RuaS1ib3Vu Y2VzQGlldGYub3JnPC9hPiA8YSBocmVmPSJtYWlsdG86W21haWx0bzpjZG5pLWJvdW5jZXNAaWV0 Zi5vcmddIj5bbWFpbHRvOmNkbmktYm91bmNlc0BpZXRmLm9yZ108L2E+IE9uIEJlaGFsZiBPZiA8 L3NwYW4+PC90dD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291 cmllciBOZXciJz48YnI+PHR0PiZndDsgQmh1bWlwIEtoYXNuYWJpc2g8L3R0Pjxicj48dHQ+Jmd0 OyBTZW50OiBUdWVzZGF5LCBKdWx5IDMxLCAyMDEyIDg6NDQgUE08L3R0Pjxicj48dHQ+Jmd0OyBU bzogPGEgaHJlZj0ibWFpbHRvOmNkbmlAaWV0Zi5vcmciPmNkbmlAaWV0Zi5vcmc8L2E+PC90dD48 YnI+PHR0PiZndDsgU3ViamVjdDogW0NETmldIEZ3ZDogZHJhZnQtamluLWNkbmktY29udGVudC1k ZWR1cGxpY2F0aW9uLW9wdGltaXphdGlvbi0wMi50eHQ8L3R0Pjwvc3Bhbj4gPGJyPjx0dD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+Jmd0OyAmbmJzcDs8L3NwYW4+PC90dD4gPGJyPjx0 dD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+Jmd0OyA8L3NwYW4+PC90dD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz48YnI+PHR0 PiZndDsgVG86IGktZC1hbm5vdW5jZSBhdCBpZXRmLm9yZyA8L3R0Pjwvc3Bhbj48YnI+PHR0Pjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz4mZ3Q7IFN1YmplY3Q6IEktRCBBY3Rpb246IGRy YWZ0LWppbi1jZG5pLWNvbnRlbnQtZGVkdXBsaWNhdGlvbi1vcHRpbWl6YXRpb24tMDIudHh0IDwv c3Bhbj48L3R0Pjxicj48dHQ+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPiZndDsgRnJv bTogaW50ZXJuZXQtZHJhZnRzIGF0IGlldGYub3JnIDwvc3Bhbj48L3R0Pjxicj48dHQ+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPiZndDsgRGF0ZTogU3VuLCAyOSBKdWwgMjAxMiAxOToy OToxNCAtMDcwMCA8L3NwYW4+PC90dD48YnI+PHR0PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0Jz4mZ3Q7IERlbGl2ZXJlZC10bzogaS1kLWFubm91bmNlIGF0IGlldGZhLmFtc2wuY29tIDwv c3Bhbj48L3R0Pjxicj48dHQ+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPiZndDsgTGlz dC1hcmNoaXZlOiAmbHQ7PGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUv d2ViL2ktZC1hbm5vdW5jZSI+aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2kt ZC1hbm5vdW5jZTwvYT4mZ3Q7IDwvc3Bhbj48L3R0Pjxicj48dHQ+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQnPiZndDsgTGlzdC1oZWxwOiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmktZC1hbm5v dW5jZS1yZXF1ZXN0QGlldGYub3JnP3N1YmplY3Q9aGVscCI+bWFpbHRvOmktZC1hbm5vdW5jZS1y ZXF1ZXN0QGlldGYub3JnP3N1YmplY3Q9aGVscDwvYT4mZ3Q7IDwvc3Bhbj48L3R0Pjxicj48dHQ+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPiZndDsgTGlzdC1pZDogSW50ZXJuZXQgRHJh ZnQgQW5ub3VuY2VtZW50cyBvbmx5ICZsdDtpLWQtYW5ub3VuY2UuaWV0Zi5vcmcmZ3Q7IDwvc3Bh bj48L3R0Pjxicj48dHQ+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPiZndDsgTGlzdC1w b3N0OiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmktZC1hbm5vdW5jZUBpZXRmLm9yZyI+bWFpbHRvOmkt ZC1hbm5vdW5jZUBpZXRmLm9yZzwvYT4mZ3Q7IDwvc3Bhbj48L3R0Pjxicj48dHQ+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPiZndDsgTGlzdC1zdWJzY3JpYmU6ICZsdDs8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ktZC1hbm5vdW5jZSI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2U8L2E+Jmd0OywgJmx0 Ozwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyInPjxicj48dHQ+Jmd0OyA8YSBocmVmPSJtYWlsdG86aS1kLWFubm91bmNlLXJl cXVlc3RAaWV0Zi5vcmc/c3ViamVjdD1zdWJzY3JpYmUiPm1haWx0bzppLWQtYW5ub3VuY2UtcmVx dWVzdEBpZXRmLm9yZz9zdWJqZWN0PXN1YnNjcmliZTwvYT4mZ3Q7IDwvdHQ+PC9zcGFuPjxicj48 dHQ+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPiZndDsgTGlzdC11bnN1YnNjcmliZTog Jmx0OzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vb3B0aW9ucy9pLWQtYW5u b3VuY2UiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vb3B0aW9ucy9pLWQtYW5ub3VuY2U8 L2E+Jmd0OywgJmx0Ozwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPjxicj48dHQ+Jmd0OyA8YSBocmVmPSJtYWlsdG86aS1k LWFubm91bmNlLXJlcXVlc3RAaWV0Zi5vcmc/c3ViamVjdD11bnN1YnNjcmliZSI+bWFpbHRvOmkt ZC1hbm5vdW5jZS1yZXF1ZXN0QGlldGYub3JnP3N1YmplY3Q9dW5zdWJzY3JpYmU8L2E+Jmd0OyA8 L3R0Pjwvc3Bhbj48YnI+PHR0PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz4mZ3Q7IFJl cGx5LXRvOiBpbnRlcm5ldC1kcmFmdHMgYXQgaWV0Zi5vcmcgPC9zcGFuPjwvdHQ+PGJyPjx0dD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+Jmd0OyA8L3NwYW4+PC90dD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz48YnI+PHR0PiZn dDsgQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50 ZXJuZXQtRHJhZnRzIDwvdHQ+PGJyPjx0dD4mZ3Q7IGRpcmVjdG9yaWVzLjwvdHQ+PC9zcGFuPiA8 YnI+PHR0PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz4mZ3Q7ICZuYnNwOzwvc3Bhbj48 L3R0PiA8YnI+PHR0PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz4mZ3Q7ICZuYnNwOzwv c3Bhbj48L3R0PiA8YnI+PHR0PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz4mZ3Q7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBUaXRsZSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IDogQ29udGVudCBEZS1kdXBsaWNhdGlvbiBmb3IgQ0ROaSBPcHRpbWl6YXRpb248 L3NwYW4+PC90dD4gPGJyPjx0dD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+Jmd0OyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgQXV0aG9yKHMpICZuYnNwOyAmbmJzcDsgJm5ic3A7 IDogV2VpWWkgSmluPC9zcGFuPjwvdHQ+IDxicj48dHQ+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQnPiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IE1pYW4gTGk8L3Nw YW4+PC90dD4gPGJyPjx0dD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+Jmd0OyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgQmh1bWlwIEtoYXNuYWJpc2g8L3NwYW4+PC90 dD4gPGJyPjx0dD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+Jmd0OyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgRmlsZW5hbWUgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7OiBk cmFmdC1qaW4tY2RuaS1jb250ZW50LWRlZHVwbGljYXRpb24tPC9zcGFuPjwvdHQ+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+PGJyPjx0dD4m Z3Q7IG9wdGltaXphdGlvbi0wMi50eHQ8L3R0Pjwvc3Bhbj4gPGJyPjx0dD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdCc+Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgUGFnZXMg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA6IDE3PC9zcGFuPjwvdHQ+IDxicj48 dHQ+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPiZndDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IERhdGUgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs6 IDIwMTItMDctMjk8L3NwYW4+PC90dD4gPGJyPjx0dD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdCc+Jmd0OyAmbmJzcDs8L3NwYW4+PC90dD4gPGJyPjx0dD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdCc+Jmd0OyBBYnN0cmFjdDo8L3NwYW4+PC90dD4gPGJyPjx0dD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdCc+Jmd0OyAmbmJzcDsgJm5ic3A7UmVjZW50IGV4cGxvc2l2ZSBn cm93dGggb2YgY29udGVudCBkZWxpdmVyeS9kaXN0cmlidXRpb24gbmV0d29ya3M8L3NwYW4+PC90 dD4gPGJyPjx0dD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+Jmd0OyAmbmJzcDsgJm5i c3A7KENETnMpIGFuZCB0aGVpciBpbnRlcmNvbm5lY3Rpb24gYXJlIGNhdXNpbmcgdW5pbnRlbmRl ZCByZXBldGl0aW9uIG9mPC9zcGFuPjwvdHQ+IDxicj48dHQ+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQnPiZndDsgJm5ic3A7ICZuYnNwO2NvbnRlbnQgc3RvcmFnZSBpbiB0aGUgc2FtZSBk Q0ROLiAmbmJzcDtUaGlzIGNhbiBiZSBhdm9pZGVkIGJ5IHVzaW5nIGE8L3NwYW4+PC90dD4gPGJy Pjx0dD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+Jmd0OyAmbmJzcDsgJm5ic3A7c3Vp dGFibGUgZGUtZHVwbGljYXRpb24gbWVjaGFuaXNtLiAmbmJzcDtUaGlzIGRvY3VtZW50IGV4cGxv cmVzIHRoZTwvc3Bhbj48L3R0PiA8YnI+PHR0PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 Jz4mZ3Q7ICZuYnNwOyAmbmJzcDtzY2VuYXJpb3Mgd2hpY2ggY3JlYXRlIHRoZSBwcm9ibGVtcywg YW5kIHRoZW4gZGlzY3Vzc2VzIHRoZTwvc3Bhbj48L3R0PiA8YnI+PHR0PjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0Jz4mZ3Q7ICZuYnNwOyAmbmJzcDthcHByb2FjaGVzIHRvIGVsaW1pbmF0 ZSB0aGUgZHVwbGljYXRlZCB0cmFuc21pc3Npb24gb2YgdGhlIHNhbWU8L3NwYW4+PC90dD4gPGJy Pjx0dD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+Jmd0OyAmbmJzcDsgJm5ic3A7Y29u dGVudCBmcm9tIHVDRE4ocykgdG8gZENETiBpbiBDRE5pIG5ldHdvcmtzLiAmbmJzcDtUbyBpbXBs ZW1lbnQgdGhlPC9zcGFuPjwvdHQ+IDxicj48dHQ+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQnPiZndDsgJm5ic3A7ICZuYnNwO29wdGltaXphdGlvbiwgc29tZSBlbmhhbmNlbWVudHMgdG8g dGhlIENETmkgbWV0YWRhdGEgbW9kZWwgYW5kPC9zcGFuPjwvdHQ+IDxicj48dHQ+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPiZndDsgJm5ic3A7ICZuYnNwO2ludGVyZmFjZSBhcmUgcmVx dWlyZWQuPC9zcGFuPjwvdHQ+IDxicj48dHQ+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQn PiZndDsgJm5ic3A7PC9zcGFuPjwvdHQ+IDxicj48dHQ+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQnPiZndDsgJm5ic3A7PC9zcGFuPjwvdHQ+IDxicj48dHQ+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQnPiZndDsgVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRo aXMgZHJhZnQgaXM6PC9zcGFuPjwvdHQ+IDxicj48dHQ+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQnPiZndDsgPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtamluLWNkbmktY29udGVudC0iPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWppbi1jZG5pLWNvbnRlbnQtPC9hPjwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPjxicj48dHQ+Jmd0OyBkZWR1cGxp Y2F0aW9uLW9wdGltaXphdGlvbjwvdHQ+PC9zcGFuPiA8YnI+PHR0PjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0Jz4mZ3Q7ICZuYnNwOzwvc3Bhbj48L3R0PiA8YnI+PHR0PjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0Jz4mZ3Q7IFRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24g YXZhaWxhYmxlIGF0Ojwvc3Bhbj48L3R0PiA8YnI+PHR0PjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0Jz4mZ3Q7IDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWpp bi1jZG5pLWNvbnRlbnQtZGVkdXBsaWNhdGlvbi0iPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWppbi1jZG5pLWNvbnRlbnQtZGVkdXBsaWNhdGlvbi08L2E+PC9zcGFuPjwvdHQ+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+PGJy Pjx0dD4mZ3Q7IG9wdGltaXphdGlvbi0wMjwvdHQ+PC9zcGFuPiA8YnI+PHR0PjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0Jz4mZ3Q7ICZuYnNwOzwvc3Bhbj48L3R0PiA8YnI+PHR0PjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz4mZ3Q7IEEgZGlmZiBmcm9tIHByZXZpb3VzIHZlcnNp b24gaXMgYXZhaWxhYmxlIGF0Ojwvc3Bhbj48L3R0PiA8YnI+PHR0PjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0Jz4mZ3Q7IDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9yZmNkaWZm P3VybDI9ZHJhZnQtamluLWNkbmktY29udGVudC0iPmh0dHA6Ly90b29scy5pZXRmLm9yZy9yZmNk aWZmP3VybDI9ZHJhZnQtamluLWNkbmktY29udGVudC08L2E+PC9zcGFuPjwvdHQ+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+PGJyPjx0dD4m Z3Q7IGRlZHVwbGljYXRpb24tb3B0aW1pemF0aW9uLTAyPC90dD48L3NwYW4+IDxicj48dHQ+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPiZndDsgJm5ic3A7PC9zcGFuPjwvdHQ+IDxicj48 dHQ+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPiZndDsgJm5ic3A7PC9zcGFuPjwvdHQ+ IDxicj48dHQ+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPiZndDsgSW50ZXJuZXQtRHJh ZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Ojwvc3Bhbj48L3R0PiA8 YnI+PHR0PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz4mZ3Q7IDxhIGhyZWY9ImZ0cDov L2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvIj5mdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzLzwvYT48L3NwYW4+PC90dD4gPGJyPjx0dD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdCc+Jmd0OyAmbmJzcDtfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyInPjxicj48dHQ+Jmd0OyBDRE5pIG1haWxpbmcgbGlzdDwvdHQ+ PGJyPjx0dD4mZ3Q7IDxhIGhyZWY9Im1haWx0bzpDRE5pQGlldGYub3JnIj5DRE5pQGlldGYub3Jn PC9hPjwvdHQ+PGJyPjx0dD4mZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vY2RuaSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9j ZG5pPC9hPjwvdHQ+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjwvYm9keT48L2h0 bWw+ --_000_291CC3F9E50E7641901A54E85D0977C6532706FCC3MAILR002maill_-- From yang.r.yang@gmail.com Wed Aug 1 22:37:45 2012 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 ACD9011E80BA; Wed, 1 Aug 2012 22:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.813 X-Spam-Level: X-Spam-Status: No, score=-0.813 tagged_above=-999 required=5 tests=[AWL=-1.736, BAYES_00=-2.599, FB_CIALIS_LEO3=3.899, FM_FORGED_GMAIL=0.622, 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 UYv5Bux0KLZl; Wed, 1 Aug 2012 22:37:43 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2B61B11E809A; Wed, 1 Aug 2012 22:37:39 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so15144422obb.31 for ; Wed, 01 Aug 2012 22:37:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=9JDUfMnLINvPiCdOHXfEVMLr55kKK+m4UHU9HeIHOu4=; b=wnDloue1T+uWZHSdDlywifTUfS8YHTsI+gQR0SYphTktiNZ7+fRepvzHJ1/zuYir4L 8X36JnDrsSOMDFln5lZJbpq06WyUejp1qP/zpqFC7mQf/Ntj8VlK449C2OKBgvPyLMg3 1QV8aOKyTzwK72SHDTwyTLJu4UlDy1Yp07JehgXg/BLtWdXgF1xdQNGJf/mzEvsyEyBc Wukzn2kFoq1QiWYIHv0usvRnv04OcqWR6/viSSbWHTyRysbGIG5X6oLz+xSuViCKTcb4 E0kkeYCZNWv/l8OjvJpsmW06aVrs+SgoBml6/EZGkFm2NFWkORz3eX5bfJGN/BYJ3A+/ fx5Q== MIME-Version: 1.0 Received: by 10.182.131.73 with SMTP id ok9mr33477240obb.19.1343885858562; Wed, 01 Aug 2012 22:37:38 -0700 (PDT) Sender: yang.r.yang@gmail.com Received: by 10.76.86.136 with HTTP; Wed, 1 Aug 2012 22:37:38 -0700 (PDT) In-Reply-To: <34B323AA-9E77-4C44-B89B-76A1D59F4BEC@cisco.com> References: <2779C9F0771F974CAD742BAE6D9904FE32CE33F7@PALLENE.office.hd> <34B323AA-9E77-4C44-B89B-76A1D59F4BEC@cisco.com> Date: Thu, 2 Aug 2012 13:37:38 +0800 X-Google-Sender-Auth: g8tgiSybuGf97yMXXGjx9426Xjs Message-ID: From: "Y. Richard Yang" To: "Francois Le Faucheur (flefauch)" Content-Type: multipart/alternative; boundary=e89a8f64790b37e16104c641cffb Cc: "cdni-footprint@ietf.org" , "cdni@ietf.org" Subject: Re: [CDNi] CDNI Footprint/Capabilities Design Team - Suggestion to work from simple usecases 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, 02 Aug 2012 05:37:45 -0000 --e89a8f64790b37e16104c641cffb Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Francois, On Wednesday, August 1, 2012, Francois Le Faucheur (flefauch) wrote: > > On 1 Aug 2012, at 14:18, Y. Richard Yang wrote: > > Hi Francois, > > Good suggestion. Jon also mentioned that we might want to reread the use > case draft, which contains many use cases already. > > > Makes sense. > > > Before we pile in more use cases, I will give a try on the example use > case from your email, as the example already touches on some basic issues= . > In particular, to handle the use case, the uCDN needs the following info > from dCDN[1-4]: > > - dCDN1 (ISP1) > > Set11 (good set) of dCDN1's home net -> QoE11 > Set12 (poor set) of dCDN1's home net -> QoE12 > > > > > I do not believe the use case described require that the footprint > partition necessarily be mapped into "QoE" levels. > Another approach could be to associate with each partition a hint that > reflects some topological properties (e.g1 there are on-net caches to ser= ve > that partition or not, eg2 the nb of ASes between caches and partition is > 0/1/2/3,=85..). > It appears that I have a different belief :-) The use case is that dCDN1 cannot serve a partition well. Then I prefer that our protocol should say so (i.e., cannot serve well, i.e., not good quality of service), instead of using a (potentially positively) correlated property. What do you think? > > As a starting starting straw-man, I define: > propagation-delay bound (ms) [Mandatory] > max-supported-per-ua-streaming rate (Kbps) [M] > delay-jitter [O] > > > I believe one of the design team decisions is to not try advertise QoS > parameters (at least dynamic ones) along the footprint. > The example metrics I used are stable metrics. Maybe you were reading jitter? I marked it as optional. I agree that we start with more stable metrics. > As mentioned above, I don't think this is called for by the example use > cases. > Also, the use case I describe is a starting point, but the design team is > probably going to start by defining the (set of) use case(s) they want to > focus on. I suggest we start with that definition before jumping into how > to support the use case example I brought up. > I guess I was eager to solve the first use case that you propose because it is a good use case... Thanks! Richard > Cheers > > Francois > > > I feel that there are multiple experts on content delivery metrics and > we can define an initial set. > > Now we go to dCDN2 (ISP2): > > Set21 of dCDN2 -> QoE21 > Set22 of dCDN2 -> QoE22 > ... > > Note that Set12 intersects with some Set2j. > > ... > > Continue this example, an architecture/protocol issue we may face, while > the content delivery metrics group is working on the metrics, is how the > uCDN will aggregate the reported QoEs to propagate further. One way is th= e > BGP Best-Path design (applying filtering such as comparison with > internal/3rd party measurements) which essential reports a single QoE for > each IP. Another design is exposing multipaths by exposing multiple > access points. Clearly I support the multipaths design. > > Richard > > PS: I may suggest the failure/maintainence use case in the use-case > draft as a next case. As I see an RSVP style protocol flow will come out = of > it. I also feel that the affiliation/migration use cases provide another > type of distinct use case (less privacy concern). > > On Wednesday, August 1, 2012, Francois Le Faucheur (flefauch) wrote: > > Jan, Stefano, Jon, > > I just wanted to reiterate the suggestion I made at the very end of the W= G > meeting Yesterday. > > A possible way to make progress might be to: > > 1) identify one, or a very small number, of use case(s) that we > want the CDNI Footprint/Capabilities to support > > 2) identify the semantics of the required information for > this/these specific use cases. > > While this approach may arguably not allow us to define the most flexible > universal solution, it would have the merit of allowing us to define a > solution addressing some part of the problem. > > With respect to 1), I think the design team has already identified ISP > CDNs and global CDNs as targeted dCDNs. So perhaps the use cases of focus > could include something like: > * the uCDN wants to use dCDN1 (CDN of ISP1) when the enduser is > attached to a part of ISP1 and where ISP1 feels the request can be well > served by on-net caches of ISP1 (an interesting flavor of this is where > ISP1 has some of his AS not covered well by his own CDN - e.g. some remot= e > territory) > * the uCDN wants to use dCDN2 (CDN of ISP 2) when the enduser is > attached to a part of ISP1 where ISP1 feels the request can _not_ be well > served by on-net caches of ISP1 but where ISP2 claims that the request ca= n > be well served by CDN of ISP2 (because he has caches that - while not > "on-net" on ISP1 - are well connected to ISP1 e.g. via many regional > peering points) > * the uCDN wants to use dCDN3 (a global CDN) when the enduser is > attached to any other ISP network with whom dCDN3 is well interconnected > (e.g. via many regional peering points) > * the uCDN wants to use dCDN 4 (another global CDN) when the > enduser is attached to an ISP network with whom dCDN3 is not well > interconnected (e.g. via single centralized peering points) > I just made that up so it needs more thinking, but take is as an example > of the sort of use case we may want to start from. > > I hope that helps > > Francois > > On 31 Jul 2012, at 18:05, Jan Seedorf wrote: > > > Several people have indicated that they will come to this meeting, so: > "it's on" :) Let's meet tomorrow (WED) at 15:00 at the IETF registration > desk to continue our discussions, trying to make some progress ... > > > > - Jan > > > >> -----Original Message----- > >> From: cdni-footprint-bounces@ietf.org [mailto:cdni-footprint- > >> bounces@ietf.org] On Behalf Of Jan Seedorf > >> Sent: Wednesday, August 01, 2012 1:18 AM > >> To: cdni-footprint@ietf.org > >> Cc: Brandenburg, R. (Ray) van (ray.vanbrandenburg@tno.nl); Enrico > >> Marocco; gilles.bertrand@orange.com; emile.stephan@orange.com; Kevin J > >> Ma (kevin.ma@azukisystems.com) > >> Subject: Re: [cdni-footprint] Doodle for 2nd CDNI Footprint/Capabiliti= es > >> Design Team Side Meeting at IETF-84 > >> > >> Guys, > >> > >> Looking at the latest doodle it seems that actually *** WED 15:00-17:0= 0 > *** > >> would be a good slot where a reasonable amount of people can make it. > So I > >> suggest having another CDNI Footprint/Capabilities Design Team Side > >> Meeting at this time. > >> > >> Please confirm via email if you can actually make this slot, so that w= e > see if it > >> really makes sense to have t > > _______________________________________________ > cdni-footprint mailing list > cdni-footprint@ietf.org 'cdni-footprint@ietf.org');> > https://www.ietf.org/mailman/listinfo/cdni-footprint > > > --e89a8f64790b37e16104c641cffb Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Francois,

On Wednesday, August 1, 2012, Francois Le = Faucheur (flefauch) wrote:

On 1 Aug 2012, at 14:18, Y. Richard Yang wrote:

Hi Francois,

Good suggestion. Jon also mentioned that we might want to reread the u= se case draft, which contains many use cases already.=A0

Makes sense.


Before we pile in more use cases, I will give a try on the example use= case from your email, as the example already touches on some basic issues.= In particular, to handle the use case, =A0the uCDN needs the following inf= o from dCDN[1-4]:

- dCDN1 (ISP1)

=A0 Set11 (good set) of dCDN1's home net -> QoE11=A0
=A0 Set12 (poor set) of dCDN1's home net -> QoE12

=A0<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
I do not believe the use case described require that the footprint partiti= on necessarily be mapped into "QoE" levels.=A0
Another approach could be to associat= e with each partition a hint that reflects some topological properties (e.g= 1 there are on-net caches to serve that partition or not, eg2 the nb of ASes between caches and part= ition is 0/1/2/3,=85..).

= It appears that I have a different belief :-) The use case is that dCDN1 ca= nnot serve a partition well. Then I prefer that our protocol should say so = (i.e., cannot serve well, i.e., not good quality of service), instead of us= ing a (potentially positively) correlated property. What do you think?

As a starting starting straw-man, I define:
propagation-delay bound (ms) [Mandatory]
max-supported-per-ua-streaming rate (Kbps) [M]
delay-jitter [O]

I believe one of the design team decisions is to not try advertise QoS= parameters (at least dynamic ones) along the footprint.=A0

The example metrics I used ar= e stable metrics. Maybe you were reading jitter? I marked it as optional. I= agree that we start with more stable metrics.
=A0
As mentioned above, I don't think this is called for by= the example use cases.
Also, the use case I describe is a starting point, but the design team= is probably going to start by defining the (set of) use case(s) they want = to focus on. I suggest we start with that definition before jumping into ho= w to support the use case example I brought up.=A0

I guess= I was eager to solve the first use case that you propose because it is a g= ood use case...

Thanks!

Richard


Cheers

Francois


I feel that there are multiple experts on content delivery metrics and= we can define an initial set.

Now we go to dCDN2 (ISP2):

=A0 Set21 of dCDN2 -> QoE21
=A0 Set22 of dCDN2 -> QoE22
=A0 ...

=A0 Note that Set12 intersects with some Set2j.

...

Continue this example, an architecture/protocol issue we may face, whi= le the content delivery metrics group is working on the metrics, is how the= uCDN will aggregate the reported QoEs to propagate further. One way is the= BGP Best-Path design (applying filtering such as comparison with internal/3rd party measurements) which e= ssential reports a single QoE for each IP. Another design is exposing multi= paths by exposing=A0multiple access points. Clearly I support the mul= tipaths design.

Richard

PS: I may suggest the failure/maintainence use case in the use-c= ase draft as a next case. As I see an RSVP style protocol flow will come ou= t of it. I also feel that the affiliation/migration use cases provide anoth= er type of distinct use case (less privacy concern).

On Wednesday, August 1, 2012, Francois Le Faucheur (flefauch) wrote:
Jan, Stefano, Jon,

I just wanted to reiterate the suggestion I made at the very end of the WG = meeting Yesterday.

A possible way to make progress might be to:

=A0 =A0 =A0 =A0 1) identify one, or a very small number, of use case(s) tha= t we want the CDNI Footprint/Capabilities to support

=A0 =A0 =A0 =A0 2) identify the semantics of the required information for t= his/these specific use cases.

While this approach may arguably not allow us to define the most flexible u= niversal solution, it would have the merit of allowing us to define a solut= ion addressing some part of the problem.

With respect to 1), I think the design team has already identified ISP CDNs= and global CDNs as targeted dCDNs. So perhaps the use cases of focus could= include something like:
=A0 =A0 =A0 =A0 * the uCDN wants to use dCDN1 (CDN of ISP1) when the enduse= r is attached to a part of ISP1 and where ISP1 feels the request can be wel= l served by on-net caches of ISP1 (an interesting flavor of this is where I= SP1 has some of his AS not covered well by his own CDN - e.g. some remote territory)
=A0 =A0 =A0 =A0 * the uCDN wants to use dCDN2 (CDN of ISP 2) when the endus= er is attached to a part of ISP1 where ISP1 feels the request can _not_ be = well served by on-net caches of ISP1 but where ISP2 claims that the request= can be well served by CDN of ISP2 (because he has caches that - while not "on-net" on ISP1 - are well conne= cted to ISP1 e.g. via many regional peering points)
=A0 =A0 =A0 =A0 * the uCDN wants to use dCDN3 (a global CDN) when the endus= er is attached to any other ISP network with whom dCDN3 is well interconnec= ted (e.g. via many regional peering points)
=A0 =A0 =A0 =A0 * the uCDN wants to use dCDN 4 (another global CDN) when th= e enduser is attached to an ISP network with whom dCDN3 is not well interco= nnected (e.g. via single centralized peering points)
I just made that up so it needs more thinking, but take is as an example of= the sort of use case we may want to start from.

I hope that helps

Francois

On 31 Jul 2012, at 18:05, Jan Seedorf wrote:

> Several people have indicated that they will come to this meeting, so:= "it's on" :) Let's meet tomorrow (WED) at 15:00 at the I= ETF registration desk to continue our discussions, trying to make some prog= ress ...
>
> - Jan
>
>> -----Original Message-----
>> From: cdni-footprint-bounces@ietf.org [mailto:cdni-footprint-
>> bounces@ietf.org] On Behalf Of Jan Seedorf
>> Sent: Wednesday, August 01, 2012 1:18 AM
>> To: cdni-footprint@ietf.org
>> Cc: Brandenburg, R. (Ray) van (ray.vanbrandenburg@tno.nl); = Enrico
>> Marocco; gilles.bertrand@orange.com; emile.stephan@orange.com; Kevin J
>> Ma <kevin.ma@azukisystems.com> (kevin.ma@azukisyst= ems.com)
>> Subject: Re: [cdni-footprint] Doodle for 2nd CDNI Footprint/Capabi= lities
>> Design Team Side Meeting at IETF-84
>>
>> Guys,
>>
>> Looking at the latest doodle it seems that actually *** WED 15:00-= 17:00 ***
>> would be a good slot where a reasonable amount of people can make = it. So I
>> suggest having another CDNI Footprint/Capabilities Design Team Sid= e
>> Meeting at this time.
>>
>> Please confirm via email if you can actually make this slot, so th= at we see if it
>> really makes sense to have t
_______________________________________________
cdni-footprint mailing list
cdni-footprint@ietf.org
https://www.ietf.org/mailman/listinfo/cdni-footprint

--e89a8f64790b37e16104c641cffb-- From li.mian@zte.com.cn Wed Aug 1 23:23:42 2012 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 4243B11E80E3 for ; Wed, 1 Aug 2012 23:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.626 X-Spam-Level: X-Spam-Status: No, score=-94.626 tagged_above=-999 required=5 tests=[AWL=4.367, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, GB_I_LETTER=-2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, 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 LAhv+54jtPvW for ; Wed, 1 Aug 2012 23:23:40 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 7840811E80E1 for ; Wed, 1 Aug 2012 23:23:39 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 107231050216600; Thu, 2 Aug 2012 14:12:27 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 2590.5636693340; Thu, 2 Aug 2012 14:23:34 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q726McZl065588; Thu, 2 Aug 2012 14:22:38 +0800 (GMT-8) (envelope-from li.mian@zte.com.cn) In-Reply-To: <291CC3F9E50E7641901A54E85D0977C6532706FCC3@MAILR002.mail.lan> To: Kevin J Ma , "cdni@ietf.org" , "jin.weiyi@zte.com.cn" , "'Bhumip Khasnabish'" , "zahariad@synelixis.com" MIME-Version: 1.0 X-KeepSent: F0DD314B:917A20C7-48257A4E:0020A3E7; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: li.mian@zte.com.cn Date: Thu, 2 Aug 2012 14:22:30 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-08-02 14:22:32, Serialize complete at 2012-08-02 14:22:32 Content-Type: multipart/alternative; boundary="=_alternative 0023074A48257A4E_=" X-MAIL: mse02.zte.com.cn q726McZl065588 Subject: [CDNi] =?gb2312?b?tPC4tDogUkU6ICC08Li0OiBSZTogIEZ3ZDoJZHJhZnQt?= =?gb2312?b?amluLWNkbmktY29udGVudC1kZWR1cGxpY2F0aW9uLW9wdGltaXphdGlvbi0w?= =?gb2312?b?Mi50eHQ=?= 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, 02 Aug 2012 06:23:42 -0000 This is a multipart message in MIME format. --=_alternative 0023074A48257A4E_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 RGVhciBLZXZpbiwNCg0KVGhhbmsgeW91IGZvciB5b3UgY29tbWVudHMuIFBsZWFzZSBzZWUgbXkg b3BpbmlvbnMgYmVsb3c6DQoNClAuUy4gZGVhciBhbGwsIGR1ZSB0byB0aGUgd3Jvbmcgb3BlcmF0 aW9uIG9mIG15IG1haWxib3gsIA0KY2RuaS1ib3VuY2VzQGlldGYub3JnIG1haWxsaW5nIGxpc3Qg d2FzIGFkZGVkIGluIHRoaXMgZW1haWwgbG9vcCBieSANCm1pc3Rha2UuIFNvIGlmIHlvdSB3aWxs IHJlcGx5IHRvIHRoaXMgdG9waWMsIGRvIHBsZWFzZSByZW1vdmUgdGhpcyBtYWlsaW5nIA0KbGlz dC4gU29ycnkgZm9yIHlvdXIgaW5jb252ZW5pZW5jZSBhbmQgdGhhbmsgeW91IGZvciB5b3UgY29u c2lkZXJhdGlvbn4NCg0KDQpLZXZpbiBKIE1hIDxrZXZpbi5tYUBhenVraXN5c3RlbXMuY29tPiDl hpnkuo4gMjAxMi0wOC0wMiAxMzowNDoyMzoNCg0KPiBIaSBNaWFuIGFuZCBCaHVtaXAsDQo+IA0K PiAgIFdoZW4geW91IHNheSBDU1AtdW5pcXVlLCBkb2VzIHRoYXQgaW5jbHVkZSBlbmNvZGluZy11 bmlxdWU/DQpbTGkgTWlhbl06IHdoZW4gSSBzYXkgQ1NQLXVuaXF1ZSwgSSBtZWFuIHRoZSBjb250 ZW50IElEIGFzc2lnbmVkIGZvciBhIA0KY29udGVudCBvYmplY3QgaXMgdW5pcXVlIHdpdGhpbiBv bmUgQ1NQIHNjb3BlLg0KPiAgIElmIGEgQ0ROIG9yIG90aGVyIGludGVybWVkaWFyeSBtb2RpZmll cyB0aGUgY29udGVudCBpbiBzb21lIHdheSwgaG93DQo+ICAgaXMgdGhhdCByZWZsZWN0ZWQgaW4g dGhlIGNvbnRlbnQgSUQsIGFuZCBob3cgd291bGQgdGhhdCBiZSBlbmZvcmNlZD8NCj5bTGkgTWlh bl06IERvIHlvdSBtZWFuIHRoYXQgYSBDRE4gb3Igb3RoZXIgaW50ZXJtZWRpYXJ5IG1vZGlmaWVz IHRoZSANCmNvbnRlbnQgaXRzZWxmPyBDb3JyZWN0IG1lIGlmIG15IHVuZGVyc3RhbmRpbmcgaXMg d3JvbmcuIEFzIGZvciBtZSwgdGhpcyANCnNpdHVhdGlvbiB3b3VsZCBub3QgaGFwcGVuICdjb3og Q0ROIGlzIG9ubHkgcmVzcG9uc2libGUgZm9yIGRlbGl2ZXJpbmcgdGhlIA0KY29udGVudCB0byB0 aGUgdXNlci4gSXQgaXMgbm90IGxpa2VseSB0byBtb2RpZnkgdGhlIGNvbnRlbnQgaXRzZWxmLg0K PiAgIFRoZXJlIGFyZSBvcmdhbml6YXRpb25zIHdoaWNoIGFyZSBsb29raW5nIGF0IGNvbnRlbnQg aWRlbnRpZmljYXRpb24NCj4gICAoaHR0cDovL2VpZHIub3JnLyBjb21lcyB0byBtaW5kKS4gIERv ZXMgQ0ROSSBuZWVkIHRvIGRldmVsb3AgaXRzIG93bg0KPiAgICJhdXRob3JpdGF0aXZlICdFbnRp dHknIiBmb3IgbWFuYWdpbmcgY29udGVudCBJRHMsIG9yIGRvIHlvdSBmZWVsIHRoYXQNCj4gIHRo ZXJlIGFyZSBleGlzdGluZyBzZXJ2aWNlcy9wcm90b2NvbHMgdGhhdCB3b3VsZCBxdWFsaWZ5IGFz IGNhbmRpZGF0ZQ0KPiAgICdFbnRpdGllcyc/DQo+W0xpIE1pYW5dOiBhY3R1YWxseSB3ZSBkbyBu b3QgZW5mb3JjZSB0byBkZXZlbG9wIGEgbmV3IGVudGl0eSB0byBhc3NpZ24gDQphbmQgbWFuYWdl IHRoZSBDb250ZW50IElEIGZvciBDRE5pIGNhc2UuIEJvdGggZXhpc3RpbmcgDQpvcmdzL3NlcnZp Y2VzL3Byb3RvY29scyBhbmQgbmV3IG9uZXMgY2FuIHRha2UgY2hhcmdlIG9mIHRoaXMuIFdlIGFy ZSBhbHNvIA0Kc2Vla2luZyB0aGUgcHJvcGVyIG1ldGhvZCBmb3IgQ29udGVudCBJRCBtZWNoYW5p c20gYW5kIG1hbmFnZW1lbnQuIFdlIA0Kd291bGQgd2VsY29tZSB5b3VyIHN1Z2dlc3Rpb25zIG9u IHRoaXMgaWYgeW91IGFyZSBhbHNvIGludGVyZXN0ZWQgaW4gdGhpcy4gDQpUaGFuayB5b3V+DQo+ IHRoYW54Lg0KPiANCj4gLS0gIEtldmluIEouIE1hDQo+IA0KPiBGcm9tOiBjZG5pLWJvdW5jZXNA aWV0Zi5vcmcgW21haWx0bzpjZG5pLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiANCj4g bGkubWlhbkB6dGUuY29tLmNuDQo+IFNlbnQ6IFdlZG5lc2RheSwgQXVndXN0IDAxLCAyMDEyIDI6 NTIgQU0NCj4gVG86IHphaGFyaWFkQHN5bmVsaXhpcy5jb207IGNkbmlAaWV0Zi5vcmc7IGNkbmkt Ym91bmNlc0BpZXRmLm9yZzsgDQo+ICdCaHVtaXAgS2hhc25hYmlzaCc7IGppbi53ZWl5aUB6dGUu Y29tLmNuDQo+IFN1YmplY3Q6IFtDRE5pXSDnrZTlpI06IFJlOiBGd2Q6IGRyYWZ0LWppbi1jZG5p LWNvbnRlbnQtZGVkdXBsaWNhdGlvbi0NCj4gb3B0aW1pemF0aW9uLTAyLnR4dA0KPiANCj4gDQo+ IERlYXIgVGhlb2RvcmUsIA0KPiANCj4gVGhhbmsgeW91IGZvciB5b3VyIGNvbW1lbnRzIGFuZCBz aGFyaW5nIHdpdGggdXMgeW91ciBwcm9wb3NhbHMuIA0KPiBDb3VsZCB5b3UgcGxlYXNlIHNoYXJl IHRoZSBkb2N1bWVudHMgeW91IG1lbnRpb25lZCBiZWxvdyB3aXRoIG1lPyANCj4gQmFzZWQgb24g d2hhdCB5b3UgZXhwbGFpbmVkIGluIHByZXZpb3VzIGVtYWlsLCBJIGhhdmUgc29tZSBxdWVzdGlv bnMNCj4gZm9yIGNsYXJpZmljYXRpb246IA0KPiAxLiBXZSBib3RoIGNvbnNpZGVyIGl0IG5lY2Vz c2FyeSB0byBoYXZlIGEgdW5pcXVlIGNvbnRlbnQgaWRlbnRpZmllcg0KPiBmb3IgYSBjb250ZW50 IG9iamVjdC4gT3VyIG9waW5pb24gaW4gdGhpcyBkcmFmdCBpcyB0aGF0IHRoaXMgY29udGVudA0K PiBJRCBpcyBDU1AtdW5pcXVlLiBDb3VsZCB5b3UgcGxlYXNlIGV4cGxhaW4gbW9yZSBhYm91dCB0 aGUgdW5pcXVlbmVzcw0KPiBvZiB0aGUgVUlEIGluIHlvdXIgcHJvcG9zYWw/IA0KPiAyLiBCeSBh cHBseWluZyB0aGUgbWVjaGFuaXNtIHlvdSBwcm9wb3NlZCBiZWxvdywgd2UgY2FuIGd1YXJhbnRl ZSANCj4gdGhlIGNvbnRlbnQgaXMgdW5pcXVlbHkgc3RvcmVkIGluIG9uZSBDRE4uIEFuZCBhY2Nv cmRpbmcgdG8gbXkgDQo+IGFuYWx5c2lzIG9uIHRoZSBiYXNpcyBvZiB5b3VyIGV4cGxhbmF0aW9u LCB0aGUgY29udGVudCByZXBsaWNhdGlvbiANCj4gaXMgY2hlY2tlZCBieSBjb21wYXJpbmcgdGhl IENVUkwgd2hpY2ggaXMgc2ltaWxhciB0byB0aGUgY3VycmVudCANCj4gbWVjaGFuaXNtIGluIENE Tmkgd29yaywgY29ycmVjdCBtZSBpZiBteSB1bmRlcnN0YW5kaW5nIGlzIHdyb25nLiBJZiANCj4g c28sIHdoZW4gcmVkaXJlY3Rpb24gb2NjdXJzIGJldHdlZW4gdUNETnMgYW5kIGRDRE4sIHRoZSBV Ukwgd291bGQgYmUNCj4gY2hhbmdlZCBhbmQgdGh1cyBiZSBkaWZmZXJlbnQgd2l0aCB0aGUgb3Jp Z2luYWwgb25lIC0gQ1VSTC4gQW5kIGlmIGENCj4gZENETiBpcyBjb25uZWN0ZWQgd2l0aCB0d28g ZGlmZmVyZW50IHVDRE5zIGFuZCB0d28gZW5kIHVzZXJzIHJlcXVlc3QNCj4gdGhlIHNhbWUgY29u dGVudCBmcm9tIHRoZXNlIHR3byB1Q0ROcyByZXNwZWN0aXZlbHksIHRoZSB0d28gdUNETnMgDQo+ IG1heSBnZW5lcmF0ZSBkaWZmZXJlbnQgcmVkaXJlY3Rpb24gVVJMcyB0byB0aGUgZENETi4gSW4g dGhpcyBjYXNlIHdlDQo+IHRoaW5rIHRoZSBjb250ZW50IGR1cGxpY2F0aW9uIGlzc3VlIHN0aWxs IGV4aXN0cy4gSG93IGRvIHlvdSB0aGluaz8gDQo+IElmIG15IHVuZGVyc3RhbmRpbmcgaXMgd3Jv bmcsIGNvdWxkIHlvdSBwbGVhc2UgZXhwbGFpbiBtb3JlIG9uIGhvdyANCj4gdG8gY29uc2lkZXIg dGhpcyBpc3N1ZSBieSB1c2luZyB5b3VyIHByb3Bvc2FsPyANCj4gDQo+IFRoYW5rIHlvdSBhZ2Fp bn4gDQo+IA0KPiBjZG5pLWJvdW5jZXNAaWV0Zi5vcmcg5YaZ5LqOIDIwMTItMDgtMDEgMDI6MDA6 MjM6DQo+IA0KPiA+IERlYXIgQmh1bWlwLCANCj4gPiANCj4gPiBTb21lIGlkZWFzIGFuZCBjb25z aWRlcmF0aW9ucyBvbiB0aGUgZHJhZnQuIA0KPiA+IA0KPiA+IFdlIGhhdmUgZG9uZSBzb21lIHdv cmsgaW4gdGhlIGFyZWEgb2YgZGUtZHVwbGljYXRpb24gb2YgY29udGVudCANCj4gPiAoUGxlYXNl IHNlZSBUaC4gWmFoYXJpYWRpcywgRS4gUXVhY2NoaW8sIOKAnEZhc3QgY29udGVudC1hd2FyZSAN Cj4gPiBkZWxpdmVyeSBpbiBvdmVybGF5IG5ldHdvcmtzLOKAnSBJRUVFIENPTVNPQyBNTVRDIEUt TGV0dGVyLCBWb2wuNiwgTm8uDQo+ID4gNywgSnVseSAyMDExLCBwcC4gNDQtNDcpKSANCj4gPiAN Cj4gPiBBY3R1YWxseSwgd2UgYmVsaWV2ZSB0aGF0IGl0IGlzIG5lZWRlZCB0byBkZWZpbmUgVW5p cXVlIElEcyAoVUlEKSANCj4gPiBwZXIgY29udGVudCBvYmplY3QvY2h1bmsgaW4gb3JkZXIgdG86 IA0KPiA+IGEpIEF2b2lkIGV4dGVuZGVkIGRhdGEgcmVwbGljYXRpb25zIGF0IHRoZSBDRE4gbGV2 ZWwgYW5kIG1pbmltaXplIA0KPiA+IHRoZSBsb2FkIHRvIGZpbmQgdGhlIGNvcnJlY3Qgb2JqZWN0 LiANCj4gPiBiKSBEZXRlY3QgYW5kIHJldHJpZXZlIHZlcnkgZmFzdCB0aGUgY29udGVudC4gVGhp cyBzaG91bGQgYmUgZmFzdCANCj4gPiBlbm91Z2ggdG8gYWxsb3cgZXZlbiBzZWFtbGVzcyByZWFs LXRpbWUgdmlkZW8gc3RyZWFtaW5nIGJ5IA0KPiA+IHJldHJpZXZpbmcgdmlkZW8gY2h1bmtzIA0K PiA+IGMpIEJlIGJhY2t3YXJkcyBjb21wYXRpYmxlIHdpdGggdG9kYXlz4oCZIFVSTHMgKGluIGNh c2UgdGhlIA0KPiA+IGNvbnRlbnQvY2h1bmsgaXMgbm90IGZvdW5kLCB5b3Ugc2hvdWxkIGJlIGFi bGUgdG8gZ28gdG8gdGhlIG9yaWdpbmFsIA0Kc2l0ZSkuDQo+ID4gDQo+ID4gSW4gb3JkZXIgdG8g bWVldCB0aGUgKGEpLCBVSUQgc2hvdWxkIGJlIGFsd2F5cyBhc3NvY2lhdGVkIHdpdGggdGhlIA0K PiA+IGNvbnRlbnQgb2JqZWN0IGl0c2VsZiAoZS5nLiBlbmNhcHN1bGF0ZWQgaW4gdGhlIG9iamVj dCkgb3IgYmUgYmFzZWQgDQo+ID4gb24gdW5pcXVlIGNoYXJhY3RlcmlzdGljcyBvZiB0aGUgY29u dGVudCBvYmplY3QgKGUuZy4gYSBzZXQgb2YgbG93IA0KPiA+IGxldmVsIGRlc2NyaXB0b3JzKS4g SG93ZXZlciwgKGIpLCBwb3NlcyB0aGF0IHRoaXMgY291bGQgYmUgDQo+ID4gY2FsY3VsYXRlZCBv bmNlIChvciBzb21ldGltZXMpLCBidXQgc2hvdWxkIG5vdCBiZSBjYWxjdWxhdGVkIG9yIA0KPiA+ IGdlbmVyYXRlZCBlYWNoIHRpbWUgdGhlIG9iamVjdCBpcyByZXF1ZXN0ZWQ7IGluc3RlYWQgaXQg c2hvdWxkIGJlIA0KPiA+IOKAnGNhcnJpZWTigJ0gYW5kIOKAnGV4dHJhY3RlZOKAnSBpbiBtb3N0 IGNhc2VzLiAgT24gdGhlIG90aGVyIGhhbmQsIGR1ZSANCnRvIA0KPiA+IGJhY2t3YXJkcyBjb21w YXRpYmlsaXR5IG5lZWRzIChjKSwgd2Ugc2hvdWxkIG5vdCBjaGFuZ2UgdGhlIHN0YW5kYXJkDQo+ ID4gZmlsZSBmb3JtYXQgKGUuZy4gd2UgY291bGQgbm90IGVuY2Fwc3VsYXRlIFVJRCBvciBsb3cg bGV2ZWwgDQo+ID4gZGVzY3JpcHRvciBpbiB0aGUgY29udGVudCBvYmplY3QpLiANCj4gPiANCj4g PiBPbmUgc29sdXRpb24gY291bGQgYmUgdG8gY3JlYXRlIGEgd3JhcHBlciB0aGF0IHdvdWxkIGVu Y2Fwc3VsYXRlIHRoZQ0KPiA+IFVJRCB3aGVuZXZlciB0aGUgY29udGVudCBvYmplY3QgZW50ZXJz IHRoZSBDRE4gYW5kIGV4dHJhY3RzIHRoYXQgYXQgDQo+ID4gdGhlIHRpbWUgdGhhdCB0aGUgY29u dGVudCBvYmplY3QgbGVhdmVzIHRoZSBDRE4sIGJ1dCB0aGlzIHdvdWxkIA0KPiA+IGluY3JlYXNl IHRoZSBjb21wbGV4aXR5IGFuZCBwcm9jZXNzaW5nIHRpbWUuIA0KPiA+IA0KPiA+IEluc3RlYWQs IHdlIHByb3Bvc2UgdG8gdXNlIGFzIFVJRCBhIGZvcm1hbCBmaWxlIG5hbWUgZm9ybWF0LiBVSUQg DQo+ID4gd2lsbCBiZSBhIHN0cmluZyBjb25jYXRlbmF0aW9uIGluIHRoZSBmb3JtYXQ6IA0KPiA+ IA0KPiA+IENNLUNJRC1maWxlbmFtZS5leHQgDQo+ID4gDQo+ID4gd2hlcmU6IA0KPiA+IOKAoiBD TSBpcyBhIOKAnENvbnRlbnQgTWFya2Vy4oCdIA0KPiA+IOKAoiBDSUQgaXMgYSBjb250ZW50IHNp Z25hdHVyZSwgd2hpY2ggY291bGQgYmUgYSBzZWxmLWNlcnRpZnlpbmcgDQo+ID4gaWRlbnRpZmll ciBlLmcuIE1ENSBvciBTSEEtMSBiYXNlZC1oYXNoIGZ1bmN0aW9uIG9uIHRoZSBmaWxlJ3MgDQo+ ID4gY29udGVudCBvciBldmVuIGEgY29tYmluYXRpb24gb2Ygc2VhcmNoYWJsZSBsb3cgbGV2ZWwg ZGVzY3JpcHRvcnMuICwNCj4gPiB3aGljaCBndWFyYW50ZWVzIGFuIGVhc3kgYW5kIGZhc3QgZGV0 ZWN0aW9uIHRoYXQgdGhpcyBuYW1lIGlzIGEgVUlEIA0KPiA+IOKAoiB0aGUgb3JpZ2luYWwgZmls ZW5hbWUsIHdoaWNoIGlzIHVzZWQgZm9yIG1ha2luZyBVSUQgZWFzaWx5IA0KPiA+IHJlY29nbml6 ZWQgYnkgaHVtYW5zIGFuZCBhdm9pZCBjb21wbGV4IHNlbGYtY2VydGlmeWluZyBuYW1lcy4gDQo+ ID4gDQo+ID4gV2hlbmV2ZXIgbmV3IGNvbnRlbnQgaXMgcHVibGlzaGVkIG9yIHN0b3JlZCBhdCB0 aGUgQ0ROLCB0aGUgb2JqZWN0IA0KPiA+IGZpbGVuYW1lIGNvdWxkIGJlIHJlbmFtZWQgdG8gYSBV SUQgYW5kIHRoZSBVUkwgdG8gYSBDb250ZW50IFVSTCANCj4gPiAoQ1VSTCkgd2l0aCB0aGUgDQo+ ID4gZm9sbG93aW5nIGZvcm1hdDogDQo+ID4gDQo+ID4gaHR0cDovL3d3dy4gd2Vic2l0ZS5jb20v 4oCmL0NNLUNJRC1maWxlbmFtZS5leHQgDQo+ID4gDQo+ID4gVGhlIENVUkwgaXMgYSBVUkksIHdo aWNoIGlzIGRlc2lnbmVkIHRvIGVuYWJsZSBjYWNoaW5nIG1lY2hhbmlzbXMgDQo+ID4gYW5kIHRy aWdnZXIgQ0ROLXJlbGF0ZWQgZnVuY3Rpb25hbGl0eSAoZS5nLiBhY2Nlc3NpbmcgdGhlIENETiAN Cj4gPiBvdmVybGF5IG5ldHdvcmsgYW5kIHF1ZXJ5aW5nIGZvciBsb2NhbGx5IG9yIOKAnG5lYXJi eeKAnSBjYWNoZWQgDQo+ID4gY29udGVudCkuIEl0IHNob3VsZCBhbHNvIGJlIGVtcGhhc2l6ZWQg dGhhdCBmcm9tIHRoZSBDVVJMLCB0aGUgDQo+ID4gb3JpZ2luYWwgVVJMIGFuZCB0aGUgVUlEIG1h eSBiZSBlYXNpbHkgZXh0cmFjdGVkLCB3aGlsZSBvbiB0aGUgb3RoZXINCj4gPiBoYW5kIGl0IGlz IGZ1bGx5IGJhY2t3YXJkcyBjb21wYXRpYmxlIHdpdGggZXhpc3RpbmcgYnJvd3NlcnMgYW5kIG5v IA0KPiA+IG1vZGlmaWNhdGlvbnMgYXJlIG5lZWRlZC4gSW4gdGhpcyB3YXksIHdlIG1heSBzZWFt bGVzc2x5IHN1cHBvcnQgYW55DQo+ID4ga2luZCBvZiBkYXRhIGF2YWlsYWJsZSBpbiB0aGUgSW50 ZXJuZXQgKHRleHQsIGltYWdlcywgdmFyaW91cyB0eXBlcyANCj4gPiBvZiBhdWRpbyBvciB2aWRl byksIHdoaWxlIGluIGNhc2UgdGhlIGNvbnRlbnQgb2JqZWN0IGlzIG5vdCBjYWNoZWQgDQo+ID4g aW4gdGhlIENETiwgd2UgY2FuIGFsd2F5cyBnbyBiYWNrIHRvIHRoZSBvcmlnaW5hbCBzb3VyY2Ug VVJMLiANCj4gPiANCj4gPiBCZXN0IHJlZ2FyZHMsIA0KPiA+IFRoZW9kb3JlIA0KPiA+IA0KPiA+ IEZyb206IGNkbmktYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmNkbmktYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIA0KT2YgDQo+ID4gQmh1bWlwIEtoYXNuYWJpc2gNCj4gPiBTZW50OiBUdWVz ZGF5LCBKdWx5IDMxLCAyMDEyIDg6NDQgUE0NCj4gPiBUbzogY2RuaUBpZXRmLm9yZw0KPiA+IFN1 YmplY3Q6IFtDRE5pXSBGd2Q6IGRyYWZ0LWppbi1jZG5pLWNvbnRlbnQtZGVkdXBsaWNhdGlvbi0N Cj4gb3B0aW1pemF0aW9uLTAyLnR4dCANCj4gPiANCj4gPiANCj4gPiBUbzogaS1kLWFubm91bmNl IGF0IGlldGYub3JnIA0KPiA+IFN1YmplY3Q6IEktRCBBY3Rpb246IGRyYWZ0LWppbi1jZG5pLWNv bnRlbnQtZGVkdXBsaWNhdGlvbi0NCj4gb3B0aW1pemF0aW9uLTAyLnR4dCANCj4gPiBGcm9tOiBp bnRlcm5ldC1kcmFmdHMgYXQgaWV0Zi5vcmcgDQo+ID4gRGF0ZTogU3VuLCAyOSBKdWwgMjAxMiAx OToyOToxNCAtMDcwMCANCj4gPiBEZWxpdmVyZWQtdG86IGktZC1hbm5vdW5jZSBhdCBpZXRmYS5h bXNsLmNvbSANCj4gPiBMaXN0LWFyY2hpdmU6IDxodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJj aGl2ZS93ZWIvaS1kLWFubm91bmNlPiANCj4gPiBMaXN0LWhlbHA6IDxtYWlsdG86aS1kLWFubm91 bmNlLXJlcXVlc3RAaWV0Zi5vcmc/c3ViamVjdD1oZWxwPiANCj4gPiBMaXN0LWlkOiBJbnRlcm5l dCBEcmFmdCBBbm5vdW5jZW1lbnRzIG9ubHkgPGktZC1hbm5vdW5jZS5pZXRmLm9yZz4gDQo+ID4g TGlzdC1wb3N0OiA8bWFpbHRvOmktZC1hbm5vdW5jZUBpZXRmLm9yZz4gDQo+ID4gTGlzdC1zdWJz Y3JpYmU6IDxodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ktZC1hbm5vdW5j ZT4sIA0KPA0KPiA+IG1haWx0bzppLWQtYW5ub3VuY2UtcmVxdWVzdEBpZXRmLm9yZz9zdWJqZWN0 PXN1YnNjcmliZT4gDQo+ID4gTGlzdC11bnN1YnNjcmliZTogPGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vb3B0aW9ucy9pLWQtYW5ub3VuY2U+LCANCjwNCj4gPiBtYWlsdG86aS1kLWFubm91 bmNlLXJlcXVlc3RAaWV0Zi5vcmc/c3ViamVjdD11bnN1YnNjcmliZT4gDQo+ID4gUmVwbHktdG86 IGludGVybmV0LWRyYWZ0cyBhdCBpZXRmLm9yZyANCj4gPiANCj4gPiBBIE5ldyBJbnRlcm5ldC1E cmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgDQo+ID4g ZGlyZWN0b3JpZXMuIA0KPiA+IA0KPiA+IA0KPiA+ICAgICAgICAgVGl0bGUgICAgICAgICAgIDog Q29udGVudCBEZS1kdXBsaWNhdGlvbiBmb3IgQ0ROaSBPcHRpbWl6YXRpb24gDQoNCj4gPiAgICAg ICAgIEF1dGhvcihzKSAgICAgICA6IFdlaVlpIEppbiANCj4gPiAgICAgICAgICAgICAgICAgICAg ICAgICAgIE1pYW4gTGkgDQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICBCaHVtaXAgS2hh c25hYmlzaCANCj4gPiAgICAgICAgIEZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWppbi1jZG5pLWNv bnRlbnQtZGVkdXBsaWNhdGlvbi0NCj4gPiBvcHRpbWl6YXRpb24tMDIudHh0IA0KPiA+ICAgICAg ICAgUGFnZXMgICAgICAgICAgIDogMTcgDQo+ID4gICAgICAgICBEYXRlICAgICAgICAgICAgOiAy MDEyLTA3LTI5IA0KPiA+IA0KPiA+IEFic3RyYWN0OiANCj4gPiAgICBSZWNlbnQgZXhwbG9zaXZl IGdyb3d0aCBvZiBjb250ZW50IGRlbGl2ZXJ5L2Rpc3RyaWJ1dGlvbiBuZXR3b3JrcyANCj4gPiAg ICAoQ0ROcykgYW5kIHRoZWlyIGludGVyY29ubmVjdGlvbiBhcmUgY2F1c2luZyB1bmludGVuZGVk IHJlcGV0aXRpb24gDQpvZiANCj4gPiAgICBjb250ZW50IHN0b3JhZ2UgaW4gdGhlIHNhbWUgZENE Ti4gIFRoaXMgY2FuIGJlIGF2b2lkZWQgYnkgdXNpbmcgYSANCj4gPiAgICBzdWl0YWJsZSBkZS1k dXBsaWNhdGlvbiBtZWNoYW5pc20uICBUaGlzIGRvY3VtZW50IGV4cGxvcmVzIHRoZSANCj4gPiAg ICBzY2VuYXJpb3Mgd2hpY2ggY3JlYXRlIHRoZSBwcm9ibGVtcywgYW5kIHRoZW4gZGlzY3Vzc2Vz IHRoZSANCj4gPiAgICBhcHByb2FjaGVzIHRvIGVsaW1pbmF0ZSB0aGUgZHVwbGljYXRlZCB0cmFu c21pc3Npb24gb2YgdGhlIHNhbWUgDQo+ID4gICAgY29udGVudCBmcm9tIHVDRE4ocykgdG8gZENE TiBpbiBDRE5pIG5ldHdvcmtzLiAgVG8gaW1wbGVtZW50IHRoZSANCj4gPiAgICBvcHRpbWl6YXRp b24sIHNvbWUgZW5oYW5jZW1lbnRzIHRvIHRoZSBDRE5pIG1ldGFkYXRhIG1vZGVsIGFuZCANCj4g PiAgICBpbnRlcmZhY2UgYXJlIHJlcXVpcmVkLiANCj4gPiANCj4gPiANCj4gPiBUaGUgSUVURiBk YXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczogDQo+ID4gaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtamluLWNkbmktY29udGVudC0NCj4gPiBkZWR1 cGxpY2F0aW9uLW9wdGltaXphdGlvbiANCj4gPiANCj4gPiBUaGVyZSdzIGFsc28gYSBodG1saXpl ZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDogDQo+ID4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtamluLWNkbmktY29udGVudC1kZWR1cGxpY2F0aW9uLQ0KPiA+IG9wdGltaXphdGlvbi0w MiANCj4gPiANCj4gPiBBIGRpZmYgZnJvbSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBh dDogDQo+ID4gaHR0cDovL3Rvb2xzLmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1qaW4tY2Ru aS1jb250ZW50LQ0KPiA+IGRlZHVwbGljYXRpb24tb3B0aW1pemF0aW9uLTAyIA0KPiA+IA0KPiA+ IA0KPiA+IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZU UCBhdDogDQo+ID4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8gDQo+ID4gIF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gQ0ROaSBt YWlsaW5nIGxpc3QNCj4gPiBDRE5pQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9jZG5pDQo= --=_alternative 0023074A48257A4E_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDAwODAgZmFjZT0ic2Fucy1zZXJpZiI+RGVhciBL ZXZpbiw8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDAwODAgZmFjZT0i c2Fucy1zZXJpZiI+VGhhbmsgeW91IGZvciB5b3UgY29tbWVudHMuDQpQbGVhc2Ugc2VlIG15IG9w aW5pb25zIGJlbG93OjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzAwMDA4 MCBmYWNlPSJzYW5zLXNlcmlmIj5QLlMuIGRlYXIgYWxsLCBkdWUgdG8NCnRoZSB3cm9uZyBvcGVy YXRpb24gb2Y8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDAwODAgZmFjZT0iQ29taWMgU2Fu cyBNUyI+DQpteSBtYWlsYm94LCBjZG5pLWJvdW5jZXNAaWV0Zi5vcmcgbWFpPC9mb250Pjx0dD48 Zm9udCBzaXplPTIgY29sb3I9IzAwMDA4MD5sbGluZw0KbGlzdCB3YXMgYWRkZWQgaW4gdGhpcyBl bWFpbCBsb29wIGJ5IG1pc3Rha2UuIFNvIGlmIHlvdSB3aWxsIHJlcGx5IHRvIHRoaXMNCnRvcGlj LCBkbyBwbGVhc2UgcmVtb3ZlIHRoaXMgbWFpbGluZyBsaXN0LiBTb3JyeSBmb3IgeW91ciBpbmNv bnZlbmllbmNlDQphbmQgdGhhbmsgeW91IGZvciB5b3UgY29uc2lkZXJhdGlvbn48L2ZvbnQ+PC90 dD4NCjxicj4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPktldmluIEogTWEgJmx0O2tldmlu Lm1hQGF6dWtpc3lzdGVtcy5jb20mZ3Q7IOWGmeS6jg0KMjAxMi0wOC0wMiAxMzowNDoyMzo8YnI+ DQo8YnI+DQomZ3Q7IEhpIE1pYW4gYW5kIEJodW1pcCw8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZv bnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4m Z3Q7ICZuYnNwOyBXaGVuIHlvdSBzYXkgQ1NQLXVuaXF1ZSwgZG9lcyB0aGF0IGluY2x1ZGUNCmVu Y29kaW5nLXVuaXF1ZT88L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yIGNvbG9yPWJs dWU+W0xpIE1pYW5dOiB3aGVuIEkgc2F5IENTUC11bmlxdWUsIEkgbWVhbg0KdGhlIGNvbnRlbnQg SUQgYXNzaWduZWQgZm9yIGEgY29udGVudCBvYmplY3QgaXMgdW5pcXVlIHdpdGhpbiBvbmUgQ1NQ IHNjb3BlLjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDsgSWYg YSBDRE4gb3Igb3RoZXIgaW50ZXJtZWRpYXJ5IG1vZGlmaWVzDQp0aGUgY29udGVudCBpbiBzb21l IHdheSwgaG93PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOyBp cyB0aGF0IHJlZmxlY3RlZCBpbiB0aGUgY29udGVudCBJRCwgYW5kDQpob3cgd291bGQgdGhhdCBi ZSBlbmZvcmNlZD88L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDs8L2ZvbnQ+ PC90dD48dHQ+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWU+W0xpIE1pYW5dOg0KRG8geW91IG1lYW4g dGhhdCBhIENETiBvciBvdGhlciBpbnRlcm1lZGlhcnkgbW9kaWZpZXMgdGhlIGNvbnRlbnQgaXRz ZWxmPw0KQ29ycmVjdCBtZSBpZiBteSB1bmRlcnN0YW5kaW5nIGlzIHdyb25nLiBBcyBmb3IgbWUs IHRoaXMgc2l0dWF0aW9uIHdvdWxkDQpub3QgaGFwcGVuICdjb3ogQ0ROIGlzIG9ubHkgcmVzcG9u c2libGUgZm9yIGRlbGl2ZXJpbmcgdGhlIGNvbnRlbnQgdG8gdGhlDQp1c2VyLiBJdCBpcyBub3Qg bGlrZWx5IHRvIG1vZGlmeSB0aGUgY29udGVudCBpdHNlbGYuPC9mb250PjwvdHQ+DQo8YnI+PHR0 Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOyBUaGVyZSBhcmUgb3JnYW5pemF0aW9ucyB3aGljaCBh cmUgbG9va2luZw0KYXQgY29udGVudCBpZGVudGlmaWNhdGlvbjwvZm9udD48L3R0Pg0KPGJyPjx0 dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDsgKGh0dHA6Ly9laWRyLm9yZy8gY29tZXMgdG8gbWlu ZCkuJm5ic3A7DQpEb2VzIENETkkgbmVlZCB0byBkZXZlbG9wIGl0cyBvd248L2ZvbnQ+PC90dD4N Cjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7ICZxdW90O2F1dGhvcml0YXRpdmUgJ0Vu dGl0eScmcXVvdDsgZm9yDQptYW5hZ2luZyBjb250ZW50IElEcywgb3IgZG8geW91IGZlZWwgdGhh dDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDt0aGVyZSBhcmUg ZXhpc3Rpbmcgc2VydmljZXMvcHJvdG9jb2xzIHRoYXQNCndvdWxkIHF1YWxpZnkgYXMgY2FuZGlk YXRlPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOyAnRW50aXRp ZXMnPzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OzwvZm9udD48L3R0Pjx0 dD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZT5bTGkgTWlhbl06DQphY3R1YWxseSB3ZSBkbyBub3Qg ZW5mb3JjZSB0byBkZXZlbG9wIGEgbmV3IGVudGl0eSB0byBhc3NpZ24gYW5kIG1hbmFnZQ0KdGhl IENvbnRlbnQgSUQgZm9yIENETmkgY2FzZS4gQm90aCBleGlzdGluZyBvcmdzL3NlcnZpY2VzL3By b3RvY29scyBhbmQNCm5ldyBvbmVzIGNhbiB0YWtlIGNoYXJnZSBvZiB0aGlzLiBXZSBhcmUgYWxz byBzZWVraW5nIHRoZSBwcm9wZXIgbWV0aG9kDQpmb3IgQ29udGVudCBJRCBtZWNoYW5pc20gYW5k IG1hbmFnZW1lbnQuIFdlIHdvdWxkIHdlbGNvbWUgeW91ciBzdWdnZXN0aW9ucw0Kb24gdGhpcyBp ZiB5b3UgYXJlIGFsc28gaW50ZXJlc3RlZCBpbiB0aGlzLiBUaGFuayB5b3V+PC9mb250PjwvdHQ+ DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IHRoYW54LjwvZm9udD48L3R0Pg0KPGJyPjx0dD48 Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0y PiZndDsgLS0mbmJzcDsgS2V2aW4gSi4gTWE8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6 ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IEZy b206IGNkbmktYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmNkbmktYm91bmNlc0BpZXRmLm9yZ10N Ck9uIEJlaGFsZiBPZiA8YnI+DQomZ3Q7IGxpLm1pYW5AenRlLmNvbS5jbjxicj4NCiZndDsgU2Vu dDogV2VkbmVzZGF5LCBBdWd1c3QgMDEsIDIwMTIgMjo1MiBBTTxicj4NCiZndDsgVG86IHphaGFy aWFkQHN5bmVsaXhpcy5jb207IGNkbmlAaWV0Zi5vcmc7IGNkbmktYm91bmNlc0BpZXRmLm9yZzsN Cjxicj4NCiZndDsgJ0JodW1pcCBLaGFzbmFiaXNoJzsgamluLndlaXlpQHp0ZS5jb20uY248YnI+ DQomZ3Q7IFN1YmplY3Q6IFtDRE5pXSDnrZTlpI06IFJlOiBGd2Q6IGRyYWZ0LWppbi1jZG5pLWNv bnRlbnQtZGVkdXBsaWNhdGlvbi08YnI+DQomZ3Q7IG9wdGltaXphdGlvbi0wMi50eHQ8L2ZvbnQ+ PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+ PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgRGVhciBUaGVvZG9yZSwgPGJyPg0KJmd0 OyA8YnI+DQomZ3Q7IFRoYW5rIHlvdSBmb3IgeW91ciBjb21tZW50cyBhbmQgc2hhcmluZyB3aXRo IHVzIHlvdXIgcHJvcG9zYWxzLiA8YnI+DQomZ3Q7IENvdWxkIHlvdSBwbGVhc2Ugc2hhcmUgdGhl IGRvY3VtZW50cyB5b3UgbWVudGlvbmVkIGJlbG93IHdpdGggbWU/DQo8YnI+DQomZ3Q7IEJhc2Vk IG9uIHdoYXQgeW91IGV4cGxhaW5lZCBpbiBwcmV2aW91cyBlbWFpbCwgSSBoYXZlIHNvbWUgcXVl c3Rpb25zPGJyPg0KJmd0OyBmb3IgY2xhcmlmaWNhdGlvbjogPGJyPg0KJmd0OyAxLiBXZSBib3Ro IGNvbnNpZGVyIGl0IG5lY2Vzc2FyeSB0byBoYXZlIGEgdW5pcXVlIGNvbnRlbnQgaWRlbnRpZmll cjxicj4NCiZndDsgZm9yIGEgY29udGVudCBvYmplY3QuIE91ciBvcGluaW9uIGluIHRoaXMgZHJh ZnQgaXMgdGhhdCB0aGlzIGNvbnRlbnQ8YnI+DQomZ3Q7IElEIGlzIENTUC11bmlxdWUuIENvdWxk IHlvdSBwbGVhc2UgZXhwbGFpbiBtb3JlIGFib3V0IHRoZSB1bmlxdWVuZXNzPGJyPg0KJmd0OyBv ZiB0aGUgVUlEIGluIHlvdXIgcHJvcG9zYWw/IDxicj4NCiZndDsgMi4gQnkgYXBwbHlpbmcgdGhl IG1lY2hhbmlzbSB5b3UgcHJvcG9zZWQgYmVsb3csIHdlIGNhbiBndWFyYW50ZWUNCjxicj4NCiZn dDsgdGhlIGNvbnRlbnQgaXMgdW5pcXVlbHkgc3RvcmVkIGluIG9uZSBDRE4uIEFuZCBhY2NvcmRp bmcgdG8gbXkgPGJyPg0KJmd0OyBhbmFseXNpcyBvbiB0aGUgYmFzaXMgb2YgeW91ciBleHBsYW5h dGlvbiwgdGhlIGNvbnRlbnQgcmVwbGljYXRpb24NCjxicj4NCiZndDsgaXMgY2hlY2tlZCBieSBj b21wYXJpbmcgdGhlIENVUkwgd2hpY2ggaXMgc2ltaWxhciB0byB0aGUgY3VycmVudCA8YnI+DQom Z3Q7IG1lY2hhbmlzbSBpbiBDRE5pIHdvcmssIGNvcnJlY3QgbWUgaWYgbXkgdW5kZXJzdGFuZGlu ZyBpcyB3cm9uZy4gSWYNCjxicj4NCiZndDsgc28sIHdoZW4gcmVkaXJlY3Rpb24gb2NjdXJzIGJl dHdlZW4gdUNETnMgYW5kIGRDRE4sIHRoZSBVUkwgd291bGQNCmJlPGJyPg0KJmd0OyBjaGFuZ2Vk IGFuZCB0aHVzIGJlIGRpZmZlcmVudCB3aXRoIHRoZSBvcmlnaW5hbCBvbmUgLSBDVVJMLiBBbmQg aWYNCmE8YnI+DQomZ3Q7IGRDRE4gaXMgY29ubmVjdGVkIHdpdGggdHdvIGRpZmZlcmVudCB1Q0RO cyBhbmQgdHdvIGVuZCB1c2VycyByZXF1ZXN0PGJyPg0KJmd0OyB0aGUgc2FtZSBjb250ZW50IGZy b20gdGhlc2UgdHdvIHVDRE5zIHJlc3BlY3RpdmVseSwgdGhlIHR3byB1Q0ROcw0KPGJyPg0KJmd0 OyBtYXkgZ2VuZXJhdGUgZGlmZmVyZW50IHJlZGlyZWN0aW9uIFVSTHMgdG8gdGhlIGRDRE4uIElu IHRoaXMgY2FzZQ0Kd2U8YnI+DQomZ3Q7IHRoaW5rIHRoZSBjb250ZW50IGR1cGxpY2F0aW9uIGlz c3VlIHN0aWxsIGV4aXN0cy4gSG93IGRvIHlvdSB0aGluaz8NCjxicj4NCiZndDsgSWYgbXkgdW5k ZXJzdGFuZGluZyBpcyB3cm9uZywgY291bGQgeW91IHBsZWFzZSBleHBsYWluIG1vcmUgb24gaG93 DQo8YnI+DQomZ3Q7IHRvIGNvbnNpZGVyIHRoaXMgaXNzdWUgYnkgdXNpbmcgeW91ciBwcm9wb3Nh bD8gPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoYW5rIHlvdSBhZ2Fpbn4gPGJyPg0KJmd0OyA8YnI+ DQomZ3Q7IGNkbmktYm91bmNlc0BpZXRmLm9yZyDlhpnkuo4gMjAxMi0wOC0wMSAwMjowMDoyMzo8 YnI+DQomZ3Q7IDxicj4NCiZndDsgJmd0OyBEZWFyIEJodW1pcCwgPGJyPg0KJmd0OyAmZ3Q7ICZu YnNwOyA8YnI+DQomZ3Q7ICZndDsgU29tZSBpZGVhcyBhbmQgY29uc2lkZXJhdGlvbnMgb24gdGhl IGRyYWZ0LiA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7IDxicj4NCiZndDsgJmd0OyBXZSBoYXZlIGRv bmUgc29tZSB3b3JrIGluIHRoZSBhcmVhIG9mIGRlLWR1cGxpY2F0aW9uIG9mIGNvbnRlbnQNCjxi cj4NCiZndDsgJmd0OyAoUGxlYXNlIHNlZSBUaC4gWmFoYXJpYWRpcywgRS4gUXVhY2NoaW8sIOKA nEZhc3QgY29udGVudC1hd2FyZQ0KPGJyPg0KJmd0OyAmZ3Q7IGRlbGl2ZXJ5IGluIG92ZXJsYXkg bmV0d29ya3Ms4oCdIElFRUUgQ09NU09DIE1NVEMgRS1MZXR0ZXIsIFZvbC42LA0KTm8uPGJyPg0K Jmd0OyAmZ3Q7IDcsIEp1bHkgMjAxMSwgcHAuIDQ0LTQ3KSkgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNw OyA8YnI+DQomZ3Q7ICZndDsgQWN0dWFsbHksIHdlIGJlbGlldmUgdGhhdCBpdCBpcyBuZWVkZWQg dG8gZGVmaW5lIFVuaXF1ZSBJRHMgKFVJRCkNCjxicj4NCiZndDsgJmd0OyBwZXIgY29udGVudCBv YmplY3QvY2h1bmsgaW4gb3JkZXIgdG86IDxicj4NCiZndDsgJmd0OyBhKSBBdm9pZCBleHRlbmRl ZCBkYXRhIHJlcGxpY2F0aW9ucyBhdCB0aGUgQ0ROIGxldmVsIGFuZCBtaW5pbWl6ZQ0KPGJyPg0K Jmd0OyAmZ3Q7IHRoZSBsb2FkIHRvIGZpbmQgdGhlIGNvcnJlY3Qgb2JqZWN0LiA8YnI+DQomZ3Q7 ICZndDsgYikgRGV0ZWN0IGFuZCByZXRyaWV2ZSB2ZXJ5IGZhc3QgdGhlIGNvbnRlbnQuIFRoaXMg c2hvdWxkIGJlDQpmYXN0IDxicj4NCiZndDsgJmd0OyBlbm91Z2ggdG8gYWxsb3cgZXZlbiBzZWFt bGVzcyByZWFsLXRpbWUgdmlkZW8gc3RyZWFtaW5nIGJ5IDxicj4NCiZndDsgJmd0OyByZXRyaWV2 aW5nIHZpZGVvIGNodW5rcyA8YnI+DQomZ3Q7ICZndDsgYykgQmUgYmFja3dhcmRzIGNvbXBhdGli bGUgd2l0aCB0b2RheXPigJkgVVJMcyAoaW4gY2FzZSB0aGUgPGJyPg0KJmd0OyAmZ3Q7IGNvbnRl bnQvY2h1bmsgaXMgbm90IGZvdW5kLCB5b3Ugc2hvdWxkIGJlIGFibGUgdG8gZ28gdG8gdGhlIG9y aWdpbmFsDQpzaXRlKS48YnI+DQomZ3Q7ICZndDsgJm5ic3A7IDxicj4NCiZndDsgJmd0OyBJbiBv cmRlciB0byBtZWV0IHRoZSAoYSksIFVJRCBzaG91bGQgYmUgYWx3YXlzIGFzc29jaWF0ZWQgd2l0 aA0KdGhlIDxicj4NCiZndDsgJmd0OyBjb250ZW50IG9iamVjdCBpdHNlbGYgKGUuZy4gZW5jYXBz dWxhdGVkIGluIHRoZSBvYmplY3QpIG9yIGJlDQpiYXNlZCA8YnI+DQomZ3Q7ICZndDsgb24gdW5p cXVlIGNoYXJhY3RlcmlzdGljcyBvZiB0aGUgY29udGVudCBvYmplY3QgKGUuZy4gYSBzZXQgb2YN CmxvdyA8YnI+DQomZ3Q7ICZndDsgbGV2ZWwgZGVzY3JpcHRvcnMpLiBIb3dldmVyLCAoYiksIHBv c2VzIHRoYXQgdGhpcyBjb3VsZCBiZSA8YnI+DQomZ3Q7ICZndDsgY2FsY3VsYXRlZCBvbmNlIChv ciBzb21ldGltZXMpLCBidXQgc2hvdWxkIG5vdCBiZSBjYWxjdWxhdGVkDQpvciA8YnI+DQomZ3Q7 ICZndDsgZ2VuZXJhdGVkIGVhY2ggdGltZSB0aGUgb2JqZWN0IGlzIHJlcXVlc3RlZDsgaW5zdGVh ZCBpdCBzaG91bGQNCmJlIDxicj4NCiZndDsgJmd0OyDigJxjYXJyaWVk4oCdIGFuZCDigJxleHRy YWN0ZWTigJ0gaW4gbW9zdCBjYXNlcy4gJm5ic3A7T24gdGhlDQpvdGhlciBoYW5kLCBkdWUgdG8g PGJyPg0KJmd0OyAmZ3Q7IGJhY2t3YXJkcyBjb21wYXRpYmlsaXR5IG5lZWRzIChjKSwgd2Ugc2hv dWxkIG5vdCBjaGFuZ2UgdGhlIHN0YW5kYXJkPGJyPg0KJmd0OyAmZ3Q7IGZpbGUgZm9ybWF0IChl LmcuIHdlIGNvdWxkIG5vdCBlbmNhcHN1bGF0ZSBVSUQgb3IgbG93IGxldmVsIDxicj4NCiZndDsg Jmd0OyBkZXNjcmlwdG9yIGluIHRoZSBjb250ZW50IG9iamVjdCkuIDxicj4NCiZndDsgJmd0OyAm bmJzcDsgPGJyPg0KJmd0OyAmZ3Q7IE9uZSBzb2x1dGlvbiBjb3VsZCBiZSB0byBjcmVhdGUgYSB3 cmFwcGVyIHRoYXQgd291bGQgZW5jYXBzdWxhdGUNCnRoZTxicj4NCiZndDsgJmd0OyBVSUQgd2hl bmV2ZXIgdGhlIGNvbnRlbnQgb2JqZWN0IGVudGVycyB0aGUgQ0ROIGFuZCBleHRyYWN0cyB0aGF0 DQphdCA8YnI+DQomZ3Q7ICZndDsgdGhlIHRpbWUgdGhhdCB0aGUgY29udGVudCBvYmplY3QgbGVh dmVzIHRoZSBDRE4sIGJ1dCB0aGlzIHdvdWxkDQo8YnI+DQomZ3Q7ICZndDsgaW5jcmVhc2UgdGhl IGNvbXBsZXhpdHkgYW5kIHByb2Nlc3NpbmcgdGltZS4gPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyA8 YnI+DQomZ3Q7ICZndDsgSW5zdGVhZCwgd2UgcHJvcG9zZSB0byB1c2UgYXMgVUlEIGEgZm9ybWFs IGZpbGUgbmFtZSBmb3JtYXQuDQpVSUQgPGJyPg0KJmd0OyAmZ3Q7IHdpbGwgYmUgYSBzdHJpbmcg Y29uY2F0ZW5hdGlvbiBpbiB0aGUgZm9ybWF0OiA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7IDxicj4N CiZndDsgJmd0OyBDTS1DSUQtZmlsZW5hbWUuZXh0IDxicj4NCiZndDsgJmd0OyAmbmJzcDsgPGJy Pg0KJmd0OyAmZ3Q7IHdoZXJlOiA8YnI+DQomZ3Q7ICZndDsg4oCiIENNIGlzIGEg4oCcQ29udGVu dCBNYXJrZXLigJ0gPGJyPg0KJmd0OyAmZ3Q7IOKAoiBDSUQgaXMgYSBjb250ZW50IHNpZ25hdHVy ZSwgd2hpY2ggY291bGQgYmUgYSBzZWxmLWNlcnRpZnlpbmcNCjxicj4NCiZndDsgJmd0OyBpZGVu dGlmaWVyIGUuZy4gTUQ1IG9yIFNIQS0xIGJhc2VkLWhhc2ggZnVuY3Rpb24gb24gdGhlIGZpbGUn cw0KPGJyPg0KJmd0OyAmZ3Q7IGNvbnRlbnQgb3IgZXZlbiBhIGNvbWJpbmF0aW9uIG9mIHNlYXJj aGFibGUgbG93IGxldmVsIGRlc2NyaXB0b3JzLg0KLDxicj4NCiZndDsgJmd0OyB3aGljaCBndWFy YW50ZWVzIGFuIGVhc3kgYW5kIGZhc3QgZGV0ZWN0aW9uIHRoYXQgdGhpcyBuYW1lIGlzDQphIFVJ RCA8YnI+DQomZ3Q7ICZndDsg4oCiIHRoZSBvcmlnaW5hbCBmaWxlbmFtZSwgd2hpY2ggaXMgdXNl ZCBmb3IgbWFraW5nIFVJRCBlYXNpbHkNCjxicj4NCiZndDsgJmd0OyByZWNvZ25pemVkIGJ5IGh1 bWFucyBhbmQgYXZvaWQgY29tcGxleCBzZWxmLWNlcnRpZnlpbmcgbmFtZXMuDQo8YnI+DQomZ3Q7 ICZndDsgJm5ic3A7IDxicj4NCiZndDsgJmd0OyBXaGVuZXZlciBuZXcgY29udGVudCBpcyBwdWJs aXNoZWQgb3Igc3RvcmVkIGF0IHRoZSBDRE4sIHRoZSBvYmplY3QNCjxicj4NCiZndDsgJmd0OyBm aWxlbmFtZSBjb3VsZCBiZSByZW5hbWVkIHRvIGEgVUlEIGFuZCB0aGUgVVJMIHRvIGEgQ29udGVu dCBVUkwNCjxicj4NCiZndDsgJmd0OyAoQ1VSTCkgd2l0aCB0aGUgPGJyPg0KJmd0OyAmZ3Q7IGZv bGxvd2luZyBmb3JtYXQ6IDxicj4NCiZndDsgJmd0OyAmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7IGh0 dHA6Ly93d3cuIHdlYnNpdGUuY29tL+KApi9DTS1DSUQtZmlsZW5hbWUuZXh0IDxicj4NCiZndDsg Jmd0OyAmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7IFRoZSBDVVJMIGlzIGEgVVJJLCB3aGljaCBpcyBk ZXNpZ25lZCB0byBlbmFibGUgY2FjaGluZyBtZWNoYW5pc21zDQo8YnI+DQomZ3Q7ICZndDsgYW5k IHRyaWdnZXIgQ0ROLXJlbGF0ZWQgZnVuY3Rpb25hbGl0eSAoZS5nLiBhY2Nlc3NpbmcgdGhlIENE Tg0KPGJyPg0KJmd0OyAmZ3Q7IG92ZXJsYXkgbmV0d29yayBhbmQgcXVlcnlpbmcgZm9yIGxvY2Fs bHkgb3Ig4oCcbmVhcmJ54oCdIGNhY2hlZA0KPGJyPg0KJmd0OyAmZ3Q7IGNvbnRlbnQpLiBJdCBz aG91bGQgYWxzbyBiZSBlbXBoYXNpemVkIHRoYXQgZnJvbSB0aGUgQ1VSTCwgdGhlDQo8YnI+DQom Z3Q7ICZndDsgb3JpZ2luYWwgVVJMIGFuZCB0aGUgVUlEIG1heSBiZSBlYXNpbHkgZXh0cmFjdGVk LCB3aGlsZSBvbiB0aGUNCm90aGVyPGJyPg0KJmd0OyAmZ3Q7IGhhbmQgaXQgaXMgZnVsbHkgYmFj a3dhcmRzIGNvbXBhdGlibGUgd2l0aCBleGlzdGluZyBicm93c2Vycw0KYW5kIG5vIDxicj4NCiZn dDsgJmd0OyBtb2RpZmljYXRpb25zIGFyZSBuZWVkZWQuIEluIHRoaXMgd2F5LCB3ZSBtYXkgc2Vh bWxlc3NseSBzdXBwb3J0DQphbnk8YnI+DQomZ3Q7ICZndDsga2luZCBvZiBkYXRhIGF2YWlsYWJs ZSBpbiB0aGUgSW50ZXJuZXQgKHRleHQsIGltYWdlcywgdmFyaW91cw0KdHlwZXMgPGJyPg0KJmd0 OyAmZ3Q7IG9mIGF1ZGlvIG9yIHZpZGVvKSwgd2hpbGUgaW4gY2FzZSB0aGUgY29udGVudCBvYmpl Y3QgaXMgbm90IGNhY2hlZA0KPGJyPg0KJmd0OyAmZ3Q7IGluIHRoZSBDRE4sIHdlIGNhbiBhbHdh eXMgZ28gYmFjayB0byB0aGUgb3JpZ2luYWwgc291cmNlIFVSTC4NCjxicj4NCiZndDsgJmd0OyAm bmJzcDsgPGJyPg0KJmd0OyAmZ3Q7IEJlc3QgcmVnYXJkcywgPGJyPg0KJmd0OyAmZ3Q7IFRoZW9k b3JlIDxicj4NCiZndDsgJmd0OyAmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7IEZyb206IGNkbmktYm91 bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmNkbmktYm91bmNlc0BpZXRmLm9yZ10gT24NCkJlaGFsZiBP ZiA8YnI+DQomZ3Q7ICZndDsgQmh1bWlwIEtoYXNuYWJpc2g8YnI+DQomZ3Q7ICZndDsgU2VudDog VHVlc2RheSwgSnVseSAzMSwgMjAxMiA4OjQ0IFBNPGJyPg0KJmd0OyAmZ3Q7IFRvOiBjZG5pQGll dGYub3JnPGJyPg0KJmd0OyAmZ3Q7IFN1YmplY3Q6IFtDRE5pXSBGd2Q6IGRyYWZ0LWppbi1jZG5p LWNvbnRlbnQtZGVkdXBsaWNhdGlvbi08YnI+DQomZ3Q7IG9wdGltaXphdGlvbi0wMi50eHQgPGJy Pg0KJmd0OyAmZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IFRvOiBp LWQtYW5ub3VuY2UgYXQgaWV0Zi5vcmcgPGJyPg0KJmd0OyAmZ3Q7IFN1YmplY3Q6IEktRCBBY3Rp b246IGRyYWZ0LWppbi1jZG5pLWNvbnRlbnQtZGVkdXBsaWNhdGlvbi08YnI+DQomZ3Q7IG9wdGlt aXphdGlvbi0wMi50eHQgPGJyPg0KJmd0OyAmZ3Q7IEZyb206IGludGVybmV0LWRyYWZ0cyBhdCBp ZXRmLm9yZyA8YnI+DQomZ3Q7ICZndDsgRGF0ZTogU3VuLCAyOSBKdWwgMjAxMiAxOToyOToxNCAt MDcwMCA8YnI+DQomZ3Q7ICZndDsgRGVsaXZlcmVkLXRvOiBpLWQtYW5ub3VuY2UgYXQgaWV0ZmEu YW1zbC5jb20gPGJyPg0KJmd0OyAmZ3Q7IExpc3QtYXJjaGl2ZTogJmx0O2h0dHA6Ly93d3cuaWV0 Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9pLWQtYW5ub3VuY2UmZ3Q7DQo8YnI+DQomZ3Q7ICZndDsg TGlzdC1oZWxwOiAmbHQ7bWFpbHRvOmktZC1hbm5vdW5jZS1yZXF1ZXN0QGlldGYub3JnP3N1Ympl Y3Q9aGVscCZndDsNCjxicj4NCiZndDsgJmd0OyBMaXN0LWlkOiBJbnRlcm5ldCBEcmFmdCBBbm5v dW5jZW1lbnRzIG9ubHkgJmx0O2ktZC1hbm5vdW5jZS5pZXRmLm9yZyZndDsNCjxicj4NCiZndDsg Jmd0OyBMaXN0LXBvc3Q6ICZsdDttYWlsdG86aS1kLWFubm91bmNlQGlldGYub3JnJmd0OyA8YnI+ DQomZ3Q7ICZndDsgTGlzdC1zdWJzY3JpYmU6ICZsdDtodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2ktZC1hbm5vdW5jZSZndDssDQombHQ7PGJyPg0KJmd0OyAmZ3Q7IG1haWx0 bzppLWQtYW5ub3VuY2UtcmVxdWVzdEBpZXRmLm9yZz9zdWJqZWN0PXN1YnNjcmliZSZndDsgPGJy Pg0KJmd0OyAmZ3Q7IExpc3QtdW5zdWJzY3JpYmU6ICZsdDtodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL29wdGlvbnMvaS1kLWFubm91bmNlJmd0OywNCiZsdDs8YnI+DQomZ3Q7ICZndDsgbWFp bHRvOmktZC1hbm5vdW5jZS1yZXF1ZXN0QGlldGYub3JnP3N1YmplY3Q9dW5zdWJzY3JpYmUmZ3Q7 DQo8YnI+DQomZ3Q7ICZndDsgUmVwbHktdG86IGludGVybmV0LWRyYWZ0cyBhdCBpZXRmLm9yZyA8 YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2 YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cw0KPGJyPg0KJmd0OyAmZ3Q7 IGRpcmVjdG9yaWVzLiA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7IDxicj4NCiZndDsgJmd0OyAmbmJz cDsgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBUaXRsZSAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyA6IENvbnRlbnQgRGUtZHVwbGljYXRpb24g Zm9yIENETmkgT3B0aW1pemF0aW9uIDxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgQXV0aG9yKHMpICZuYnNwOyAmbmJzcDsgJm5ic3A7IDoNCldlaVlpIEppbiA8YnI+ DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBNaWFuIExpIDxi cj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEJodW1pcCBL aGFzbmFiaXNoIDxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgRmls ZW5hbWUgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Og0KZHJhZnQtamluLWNkbmktY29udGVu dC1kZWR1cGxpY2F0aW9uLTxicj4NCiZndDsgJmd0OyBvcHRpbWl6YXRpb24tMDIudHh0IDxicj4N CiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgUGFnZXMgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7DQombmJzcDsgOiAxNyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IERhdGUgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsg Jm5ic3A7OiAyMDEyLTA3LTI5IDxicj4NCiZndDsgJmd0OyAmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7 IEFic3RyYWN0OiA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO1JlY2VudCBleHBsb3NpdmUg Z3Jvd3RoIG9mIGNvbnRlbnQgZGVsaXZlcnkvZGlzdHJpYnV0aW9uDQpuZXR3b3JrcyA8YnI+DQom Z3Q7ICZndDsgJm5ic3A7ICZuYnNwOyhDRE5zKSBhbmQgdGhlaXIgaW50ZXJjb25uZWN0aW9uIGFy ZSBjYXVzaW5nIHVuaW50ZW5kZWQNCnJlcGV0aXRpb24gb2YgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNw OyAmbmJzcDtjb250ZW50IHN0b3JhZ2UgaW4gdGhlIHNhbWUgZENETi4gJm5ic3A7VGhpcyBjYW4N CmJlIGF2b2lkZWQgYnkgdXNpbmcgYSA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO3N1aXRh YmxlIGRlLWR1cGxpY2F0aW9uIG1lY2hhbmlzbS4gJm5ic3A7VGhpcyBkb2N1bWVudA0KZXhwbG9y ZXMgdGhlIDxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7c2NlbmFyaW9zIHdoaWNoIGNyZWF0 ZSB0aGUgcHJvYmxlbXMsIGFuZCB0aGVuIGRpc2N1c3Nlcw0KdGhlIDxicj4NCiZndDsgJmd0OyAm bmJzcDsgJm5ic3A7YXBwcm9hY2hlcyB0byBlbGltaW5hdGUgdGhlIGR1cGxpY2F0ZWQgdHJhbnNt aXNzaW9uDQpvZiB0aGUgc2FtZSA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO2NvbnRlbnQg ZnJvbSB1Q0ROKHMpIHRvIGRDRE4gaW4gQ0ROaSBuZXR3b3Jrcy4gJm5ic3A7VG8NCmltcGxlbWVu dCB0aGUgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDtvcHRpbWl6YXRpb24sIHNvbWUgZW5o YW5jZW1lbnRzIHRvIHRoZSBDRE5pIG1ldGFkYXRhDQptb2RlbCBhbmQgPGJyPg0KJmd0OyAmZ3Q7 ICZuYnNwOyAmbmJzcDtpbnRlcmZhY2UgYXJlIHJlcXVpcmVkLiA8YnI+DQomZ3Q7ICZndDsgJm5i c3A7IDxicj4NCiZndDsgJmd0OyAmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7IFRoZSBJRVRGIGRhdGF0 cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOiA8YnI+DQomZ3Q7ICZndDsgaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtamluLWNkbmktY29udGVudC08YnI+ DQomZ3Q7ICZndDsgZGVkdXBsaWNhdGlvbi1vcHRpbWl6YXRpb24gPGJyPg0KJmd0OyAmZ3Q7ICZu YnNwOyA8YnI+DQomZ3Q7ICZndDsgVGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFp bGFibGUgYXQ6IDxicj4NCiZndDsgJmd0OyBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1qaW4tY2RuaS1jb250ZW50LWRlZHVwbGljYXRpb24tPGJyPg0KJmd0OyAmZ3Q7IG9wdGltaXph dGlvbi0wMiA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7IDxicj4NCiZndDsgJmd0OyBBIGRpZmYgZnJv bSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDogPGJyPg0KJmd0OyAmZ3Q7IGh0dHA6 Ly90b29scy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtamluLWNkbmktY29udGVudC08YnI+ DQomZ3Q7ICZndDsgZGVkdXBsaWNhdGlvbi1vcHRpbWl6YXRpb24tMDIgPGJyPg0KJmd0OyAmZ3Q7 ICZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7IDxicj4NCiZndDsgJmd0OyBJbnRlcm5ldC1E cmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6IDxicj4NCiZndDsg Jmd0OyBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLyA8YnI+DQomZ3Q7ICZndDsg Jm5ic3A7X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQomZ3Q7ICZndDsgQ0ROaSBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7ICZndDsgQ0ROaUBpZXRmLm9y Zzxicj4NCiZndDsgJmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nk bmk8L2ZvbnQ+PC90dD4NCg== --=_alternative 0023074A48257A4E_=-- From swainner@cisco.com Thu Aug 2 05:22:52 2012 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 4217C21F8B55; Thu, 2 Aug 2012 05:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.589 X-Spam-Level: X-Spam-Status: No, score=-8.589 tagged_above=-999 required=5 tests=[AWL=-1.890, BAYES_00=-2.599, FB_CIALIS_LEO3=3.899, HTML_MESSAGE=0.001, 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 GMOBAvHn1wJQ; Thu, 2 Aug 2012 05:22:46 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 1B34B21F8A79; Thu, 2 Aug 2012 05:22:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=swainner@cisco.com; l=33551; q=dns/txt; s=iport; t=1343910166; x=1345119766; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=NAwKVR7NOk1rfBi33SfbSXzPRSVUFUXruKuMqysvubM=; b=HAmvWkLAbHC4XGvzagbpZ3Jk3Ki300nH3Td2wdRHKnOMc19XpdxSw2Cy CKibO4N0UeI+XYygPJnGhbL86/f3W2/inOs0WWbZQEx08BO/vn5BLo5M+ +hYxJkHOJ2qLmHoPHVkwquQpNxiTyftzkbjMdvqsuSAGI0Rg3hB9duHTr w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFABlwGlCtJV2Z/2dsb2JhbAA7CrkMgQeCIAEBAQMBAQEBDwEHDUQDCgEFBwQLEQEDAQEBCRYBAQYHCQMCAQIBFR8DBggTAQUCAQEXB4dlBguccI8WkR0BAwaLQxCGdAOVR44ngWaCe4FD X-IronPort-AV: E=Sophos;i="4.77,701,1336348800"; d="scan'208,217";a="107837839" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-3.cisco.com with ESMTP; 02 Aug 2012 12:22:44 +0000 Received: from rtp-swainner-89110.cisco.com (rtp-swainner-89110.cisco.com [10.116.109.203]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q72CMhtE016819; Thu, 2 Aug 2012 12:22:44 GMT Message-ID: <501A7113.8000003@cisco.com> Date: Thu, 02 Aug 2012 08:22:43 -0400 From: Scott Wainner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: cdni-footprint@ietf.org References: <2779C9F0771F974CAD742BAE6D9904FE32CE33F7@PALLENE.office.hd> <34B323AA-9E77-4C44-B89B-76A1D59F4BEC@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090509030605020207050806" Cc: cdni@ietf.org Subject: Re: [CDNi] CDNI Footprint/Capabilities Design Team - Suggestion to work from simple usecases 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, 02 Aug 2012 12:22:52 -0000 This is a multi-part message in MIME format. --------------090509030605020207050806 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit It will be difficult to make progress unless we can define explicit attributes that refer to footprint and capabilities. There seems to be some agreement that the advertised footprint / capabilities should be attributes that are generally time-invariant. With regard to footprint, I think we can define this in two context: 1) Topologically Dependent In this context, we might indicate that a dCDN either has a delivery node in an AS or it does not. A simple binary representation. Of course, an AS can cover any size of geography including the globe, so we can make no assumptions about the geographical location of any given delivery node. Nevertheless, a uCDN can assess the topological proximity of a dCDN's delivery node based on AS-PATH attributes. 2) Topologically Independent In this context, we indicate that a dCDN either has a delivery node in a geographic location or it does not. The problem we have with geographic location is the scope [city, country, continent] and its interpretation. The dCDN could imply that its delivery node can "reach" any of the geographic locations which is somewhat vague. A single delivery node on the Internet can "reach" all geographic locations. In contrast, the definition of a delivery node in a geographic location is generally time-invariant. Either the dCDN has a node installed in the location or it does not. Note the availability of a given node may change over time. Perhaps this is best addressed outside of the time-invariant footprint / capabilities advertisement. Define the granularity of geographic footprint. Now a uCDN can use the concatenation of the two footprint context to discern the 'best' dCDN to use. Example: uCDN learns that the client IP is in city_X attached to AS_1 dCDN_1: delivery nodes in AS_1 dCDN_2: delivery nodes in city_X, city_Y dCDN_3: delivery nodes in AS_2/city_Z Now which one is best? Did you choose wisely? The answer is dCDN3. How is this possible? dCDN_1 is a global AS with a all their delivery nodes 4,000 miles away. dCDN_2 is a local ISP which is in the same city, but is 4 AS hops away. dCDN_3 is a global AS one hop from AS_1 with delivery nodes in city_Z which is 30km from city_X The uCDN is able to use the context of topologically dependent (AS_PATH) and topologically independent information (GEOGRAPHIC LOCATION) to find the optimal dCDN choice. Note we haven't even considered capabilities yet. I'm inclined to define capabilities with time-invariant dCDN attributes such as the following: HTTP_PDL: Yes or No HLS: Yes or No HSS: Yes or No URL Signing Method A: Yes or No URL Signing Mehtod B: Yes or No The advertised capabilities would certainly be the first set of characteristics that the uCDN would use to even qualify a dCDN for evaluation in the footprint assessment. If the uCDN knows that HLS is required and the dCDN_3 above is incapable of HLS, then it doesn't matter what footprint dCDN_3 covers. It is not a candidate. So do we have a set of candidate capabilities that can be reflected in a concise and unambiguous manner? Finally, the routing-request logic would be used for time-variant attributes. Perhaps this is where the aspect of performance applies for a node in a given footprint / capabilities construct and this could be answered by a dCDN with a yes or no. The dCDN advertised that it could serve city_X from AS_2 with HLS and URL Signing Method A. Now the uCDN has a live client request and has called upon the dCDN to execute on that advertised capability. Is the dCDN still capable of serving the request at this specific time (i.e. sufficient bandwidth, sufficient disk space, sufficient priority, etc.)? Scott On 8/2/12 1:37 AM, Y. Richard Yang wrote: > Hi Francois, > > On Wednesday, August 1, 2012, Francois Le Faucheur (flefauch) wrote: > > > On 1 Aug 2012, at 14:18, Y. Richard Yang wrote: > >> Hi Francois, >> >> Good suggestion. Jon also mentioned that we might want to reread >> the use case draft, which contains many use cases already. > > Makes sense. > >> >> Before we pile in more use cases, I will give a try on the >> example use case from your email, as the example already touches >> on some basic issues. In particular, to handle the use case, the >> uCDN needs the following info from dCDN[1-4]: >> >> - dCDN1 (ISP1) >> >> Set11 (good set) of dCDN1's home net -> QoE11 >> Set12 (poor set) of dCDN1's home net -> QoE12 > > I do not believe the use case described require that the footprint > partition necessarily be mapped into "QoE" levels. > > Another approach could be to associate with each partition a hint > that reflects some topological properties (e.g1 there are on-net > caches to serve that partition or not, eg2 the nb of ASes between > caches and partition is 0/1/2/3,.....). > > > It appears that I have a different belief :-) The use case is that > dCDN1 cannot serve a partition well. Then I prefer that our protocol > should say so (i.e., cannot serve well, i.e., not good quality of > service), instead of using a (potentially positively) correlated > property. What do you think? > > >> As a starting starting straw-man, I define: >> propagation-delay bound (ms) [Mandatory] >> max-supported-per-ua-streaming rate (Kbps) [M] >> delay-jitter [O] > > I believe one of the design team decisions is to not try advertise > QoS parameters (at least dynamic ones) along the footprint. > > > The example metrics I used are stable metrics. Maybe you were reading > jitter? I marked it as optional. I agree that we start with more > stable metrics. > > As mentioned above, I don't think this is called for by the > example use cases. > Also, the use case I describe is a starting point, but the design > team is probably going to start by defining the (set of) use > case(s) they want to focus on. I suggest we start with that > definition before jumping into how to support the use case example > I brought up. > > > I guess I was eager to solve the first use case that you propose > because it is a good use case... > > Thanks! > > Richard > > > Cheers > > Francois > >> >> I feel that there are multiple experts on content delivery >> metrics and we can define an initial set. >> >> Now we go to dCDN2 (ISP2): >> >> Set21 of dCDN2 -> QoE21 >> Set22 of dCDN2 -> QoE22 >> ... >> >> Note that Set12 intersects with some Set2j. >> >> ... >> >> Continue this example, an architecture/protocol issue we may >> face, while the content delivery metrics group is working on the >> metrics, is how the uCDN will aggregate the reported QoEs to >> propagate further. One way is the BGP Best-Path design (applying >> filtering such as comparison with internal/3rd party >> measurements) which essential reports a single QoE for each IP. >> Another design is exposing multipaths by exposing multiple access >> points. Clearly I support the multipaths design. >> >> Richard >> >> PS: I may suggest the failure/maintainence use case in the >> use-case draft as a next case. As I see an RSVP style protocol >> flow will come out of it. I also feel that the >> affiliation/migration use cases provide another type of distinct >> use case (less privacy concern). >> >> On Wednesday, August 1, 2012, Francois Le Faucheur (flefauch) wrote: >> >> Jan, Stefano, Jon, >> >> I just wanted to reiterate the suggestion I made at the very >> end of the WG meeting Yesterday. >> >> A possible way to make progress might be to: >> >> 1) identify one, or a very small number, of use >> case(s) that we want the CDNI Footprint/Capabilities to support >> >> 2) identify the semantics of the required information >> for this/these specific use cases. >> >> While this approach may arguably not allow us to define the >> most flexible universal solution, it would have the merit of >> allowing us to define a solution addressing some part of the >> problem. >> >> With respect to 1), I think the design team has already >> identified ISP CDNs and global CDNs as targeted dCDNs. So >> perhaps the use cases of focus could include something like: >> * the uCDN wants to use dCDN1 (CDN of ISP1) when the >> enduser is attached to a part of ISP1 and where ISP1 feels >> the request can be well served by on-net caches of ISP1 (an >> interesting flavor of this is where ISP1 has some of his AS >> not covered well by his own CDN - e.g. some remote territory) >> * the uCDN wants to use dCDN2 (CDN of ISP 2) when the >> enduser is attached to a part of ISP1 where ISP1 feels the >> request can _not_ be well served by on-net caches of ISP1 but >> where ISP2 claims that the request can be well served by CDN >> of ISP2 (because he has caches that - while not "on-net" on >> ISP1 - are well connected to ISP1 e.g. via many regional >> peering points) >> * the uCDN wants to use dCDN3 (a global CDN) when the >> enduser is attached to any other ISP network with whom dCDN3 >> is well interconnected (e.g. via many regional peering points) >> * the uCDN wants to use dCDN 4 (another global CDN) >> when the enduser is attached to an ISP network with whom >> dCDN3 is not well interconnected (e.g. via single centralized >> peering points) >> I just made that up so it needs more thinking, but take is as >> an example of the sort of use case we may want to start from. >> >> I hope that helps >> >> Francois >> >> On 31 Jul 2012, at 18:05, Jan Seedorf wrote: >> >> > Several people have indicated that they will come to this >> meeting, so: "it's on" :) Let's meet tomorrow (WED) at 15:00 >> at the IETF registration desk to continue our discussions, >> trying to make some progress ... >> > >> > - Jan >> > >> >> -----Original Message----- >> >> From: cdni-footprint-bounces@ietf.org [mailto:cdni-footprint- >> >> bounces@ietf.org] On Behalf Of Jan Seedorf >> >> Sent: Wednesday, August 01, 2012 1:18 AM >> >> To: cdni-footprint@ietf.org >> >> Cc: Brandenburg, R. (Ray) van (ray.vanbrandenburg@tno.nl); >> Enrico >> >> Marocco; gilles.bertrand@orange.com; >> emile.stephan@orange.com; Kevin J >> >> Ma (kevin.ma@azukisystems.com) >> >> Subject: Re: [cdni-footprint] Doodle for 2nd CDNI >> Footprint/Capabilities >> >> Design Team Side Meeting at IETF-84 >> >> >> >> Guys, >> >> >> >> Looking at the latest doodle it seems that actually *** >> WED 15:00-17:00 *** >> >> would be a good slot where a reasonable amount of people >> can make it. So I >> >> suggest having another CDNI Footprint/Capabilities Design >> Team Side >> >> Meeting at this time. >> >> >> >> Please confirm via email if you can actually make this >> slot, so that we see if it >> >> really makes sense to have t >> >> _______________________________________________ >> cdni-footprint mailing list >> cdni-footprint@ietf.org > 'cdni-footprint@ietf.org');> >> https://www.ietf.org/mailman/listinfo/cdni-footprint > > > > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni --------------090509030605020207050806 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
It will be difficult to make progress unless we can define explicit attributes that refer to footprint and capabilities.  There seems to be some agreement that the advertised footprint / capabilities should be attributes that are generally time-invariant. 

With regard to footprint, I think we can define this in two context:

1) Topologically Dependent
    In this context, we might indicate that a dCDN either has a delivery node in an AS or it does not.   A simple binary representation.  Of course, an AS can cover any size of geography including the globe, so we can make no assumptions about the geographical location of any given delivery node.  Nevertheless, a uCDN can assess the topological proximity of a dCDN's delivery node based on AS-PATH attributes.

2) Topologically Independent
    In this context, we indicate that a dCDN either has a delivery node in a geographic location or it does not.  The problem we have with geographic location is the scope [city, country, continent] and its interpretation.  The dCDN could imply that its delivery node can "reach" any of the geographic locations which is somewhat vague.  A single delivery node on the Internet can "reach" all geographic locations.  In contrast, the definition of a delivery node in a geographic location is generally time-invariant.  Either the dCDN has a node installed in the location or it does not.  Note the availability of a given node may change over time.  Perhaps this is best addressed outside of the time-invariant footprint / capabilities advertisement.  Define the granularity of geographic footprint.

Now a uCDN can use the concatenation of the two footprint context to discern the 'best' dCDN to use.

Example:  uCDN learns that the client IP is in city_X attached to AS_1

   dCDN_1:  delivery nodes in AS_1
   dCDN_2:  delivery nodes in city_X, city_Y
   dCDN_3:  delivery nodes in AS_2/city_Z

Now which one is best?  Did you choose wisely?  The answer is dCDN3.  How is this possible?
     dCDN_1 is a global AS with a all their delivery nodes 4,000 miles away.
     dCDN_2 is a local ISP which is in the same city, but is 4 AS hops away.
     dCDN_3 is a global AS one hop from AS_1 with delivery nodes in city_Z which is 30km from city_X

The uCDN is able to use the context of topologically dependent (AS_PATH) and topologically independent information (GEOGRAPHIC LOCATION) to find the optimal dCDN choice.  Note we haven't even considered capabilities yet.

I'm inclined to define capabilities with time-invariant dCDN attributes such as the following:

    HTTP_PDL: Yes or No
    HLS: Yes or No
    HSS: Yes or No
    URL Signing Method A: Yes or No
    URL Signing Mehtod B: Yes or No

The advertised capabilities would certainly be the first set of characteristics that the uCDN would use to even qualify a dCDN for evaluation in the footprint assessment.  If the uCDN knows that HLS is required and the dCDN_3 above is incapable of HLS, then it doesn't matter what footprint dCDN_3 covers.  It is not a candidate.  So do we have a set of candidate capabilities that can be reflected in a concise and unambiguous manner?

Finally, the routing-request logic would be used for time-variant attributes.  Perhaps this is where the aspect of performance applies for a node in a given footprint / capabilities construct and this could be answered by a dCDN with a yes or no.  The dCDN advertised that it could serve city_X from AS_2 with HLS and URL Signing Method A.  Now the uCDN has a live client request and has called upon the dCDN to execute on that advertised capability.  Is the dCDN still capable of serving the request at this specific time (i.e. sufficient bandwidth, sufficient disk space, sufficient priority, etc.)?

Scott

On 8/2/12 1:37 AM, Y. Richard Yang wrote:
Hi Francois,

On Wednesday, August 1, 2012, Francois Le Faucheur (flefauch) wrote:

On 1 Aug 2012, at 14:18, Y. Richard Yang wrote:

Hi Francois,

Good suggestion. Jon also mentioned that we might want to reread the use case draft, which contains many use cases already. 

Makes sense.


Before we pile in more use cases, I will give a try on the example use case from your email, as the example already touches on some basic issues. In particular, to handle the use case,  the uCDN needs the following info from dCDN[1-4]:

- dCDN1 (ISP1)

  Set11 (good set) of dCDN1's home net -> QoE11 
  Set12 (poor set) of dCDN1's home net -> QoE12

 
I do not believe the use case described require that the footprint partition necessarily be mapped into "QoE" levels. 
Another approach could be to associate with each partition a hint that reflects some topological properties (e.g1 there are on-net caches to serve that partition or not, eg2 the nb of ASes between caches and partition is 0/1/2/3,…..).

It appears that I have a different belief :-) The use case is that dCDN1 cannot serve a partition well. Then I prefer that our protocol should say so (i.e., cannot serve well, i.e., not good quality of service), instead of using a (potentially positively) correlated property. What do you think?

As a starting starting straw-man, I define:
propagation-delay bound (ms) [Mandatory]
max-supported-per-ua-streaming rate (Kbps) [M]
delay-jitter [O]

I believe one of the design team decisions is to not try advertise QoS parameters (at least dynamic ones) along the footprint. 

The example metrics I used are stable metrics. Maybe you were reading jitter? I marked it as optional. I agree that we start with more stable metrics.
 
As mentioned above, I don't think this is called for by the example use cases.
Also, the use case I describe is a starting point, but the design team is probably going to start by defining the (set of) use case(s) they want to focus on. I suggest we start with that definition before jumping into how to support the use case example I brought up. 

I guess I was eager to solve the first use case that you propose because it is a good use case...

Thanks!

Richard


Cheers

Francois


I feel that there are multiple experts on content delivery metrics and we can define an initial set.

Now we go to dCDN2 (ISP2):

  Set21 of dCDN2 -> QoE21
  Set22 of dCDN2 -> QoE22
  ...

  Note that Set12 intersects with some Set2j.

...

Continue this example, an architecture/protocol issue we may face, while the content delivery metrics group is working on the metrics, is how the uCDN will aggregate the reported QoEs to propagate further. One way is the BGP Best-Path design (applying filtering such as comparison with internal/3rd party measurements) which essential reports a single QoE for each IP. Another design is exposing multipaths by exposing multiple access points. Clearly I support the multipaths design.

Richard

PS: I may suggest the failure/maintainence use case in the use-case draft as a next case. As I see an RSVP style protocol flow will come out of it. I also feel that the affiliation/migration use cases provide another type of distinct use case (less privacy concern).

On Wednesday, August 1, 2012, Francois Le Faucheur (flefauch) wrote:
Jan, Stefano, Jon,

I just wanted to reiterate the suggestion I made at the very end of the WG meeting Yesterday.

A possible way to make progress might be to:

        1) identify one, or a very small number, of use case(s) that we want the CDNI Footprint/Capabilities to support

        2) identify the semantics of the required information for this/these specific use cases.

While this approach may arguably not allow us to define the most flexible universal solution, it would have the merit of allowing us to define a solution addressing some part of the problem.

With respect to 1), I think the design team has already identified ISP CDNs and global CDNs as targeted dCDNs. So perhaps the use cases of focus could include something like:
        * the uCDN wants to use dCDN1 (CDN of ISP1) when the enduser is attached to a part of ISP1 and where ISP1 feels the request can be well served by on-net caches of ISP1 (an interesting flavor of this is where ISP1 has some of his AS not covered well by his own CDN - e.g. some remote territory)
        * the uCDN wants to use dCDN2 (CDN of ISP 2) when the enduser is attached to a part of ISP1 where ISP1 feels the request can _not_ be well served by on-net caches of ISP1 but where ISP2 claims that the request can be well served by CDN of ISP2 (because he has caches that - while not "on-net" on ISP1 - are well connected to ISP1 e.g. via many regional peering points)
        * the uCDN wants to use dCDN3 (a global CDN) when the enduser is attached to any other ISP network with whom dCDN3 is well interconnected (e.g. via many regional peering points)
        * the uCDN wants to use dCDN 4 (another global CDN) when the enduser is attached to an ISP network with whom dCDN3 is not well interconnected (e.g. via single centralized peering points)
I just made that up so it needs more thinking, but take is as an example of the sort of use case we may want to start from.

I hope that helps

Francois

On 31 Jul 2012, at 18:05, Jan Seedorf wrote:

> Several people have indicated that they will come to this meeting, so: "it's on" :) Let's meet tomorrow (WED) at 15:00 at the IETF registration desk to continue our discussions, trying to make some progress ...
>
> - Jan
>
>> -----Original Message-----
>> From: cdni-footprint-bounces@ietf.org [mailto:cdni-footprint-
>> bounces@ietf.org] On Behalf Of Jan Seedorf
>> Sent: Wednesday, August 01, 2012 1:18 AM
>> To: cdni-footprint@ietf.org
>> Cc: Brandenburg, R. (Ray) van (ray.vanbrandenburg@tno.nl); Enrico
>> Marocco; gilles.bertrand@orange.com; emile.stephan@orange.com; Kevin J
>> Ma <kevin.ma@azukisystems.com> (kevin.ma@azukisystems.com)
>> Subject: Re: [cdni-footprint] Doodle for 2nd CDNI Footprint/Capabilities
>> Design Team Side Meeting at IETF-84
>>
>> Guys,
>>
>> Looking at the latest doodle it seems that actually *** WED 15:00-17:00 ***
>> would be a good slot where a reasonable amount of people can make it. So I
>> suggest having another CDNI Footprint/Capabilities Design Team Side
>> Meeting at this time.
>>
>> Please confirm via email if you can actually make this slot, so that we see if it
>> really makes sense to have t
_______________________________________________
cdni-footprint mailing list
cdni-footprint@ietf.org
https://www.ietf.org/mailman/listinfo/cdni-footprint



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


--------------090509030605020207050806-- From ramk@Brocade.com Thu Aug 2 10:46:15 2012 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 EF41E11E81B0 for ; Thu, 2 Aug 2012 10:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.264 X-Spam-Level: X-Spam-Status: No, score=-3.264 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 P99aKa6lYCVa for ; Thu, 2 Aug 2012 10:46:14 -0700 (PDT) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by ietfa.amsl.com (Postfix) with ESMTP id 8C76411E81AD for ; Thu, 2 Aug 2012 10:46:14 -0700 (PDT) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id q72Hjfu2011215; Thu, 2 Aug 2012 10:46:11 -0700 Received: from hq1wp-exhub01.corp.brocade.com ([144.49.131.13]) by mx0b-000f0801.pphosted.com with ESMTP id 16fuycg2k9-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 02 Aug 2012 10:46:11 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB01.corp.brocade.com ([::1]) with mapi; Thu, 2 Aug 2012 10:46:10 -0700 From: ramki Krishnan To: Kevin J Ma , "Brandenburg, R. (Ray) van" , "cdni@ietf.org" , "bhumip.khasnabish@zteusa.com" Date: Thu, 2 Aug 2012 10:46:04 -0700 Thread-Topic: Comments on draft draft-krishnan-cdni-tm-has-00 Thread-Index: AQHNcCtar9E3CMmGP0C7wFKwbIuN8pdFdwHEgAArZMCAACYzsIAAACAQgAECvXA= Message-ID: References: <291CC3F9E50E7641901A54E85D0977C6532706FCB0@MAILR002.mail.lan> <291CC3F9E50E7641901A54E85D0977C6532706FCBD@MAILR002.mail.lan> In-Reply-To: <291CC3F9E50E7641901A54E85D0977C6532706FCBD@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 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.260, 0.0.0000 definitions=2012-08-02_07:2012-08-01, 2012-08-02, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=2 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1207200000 definitions=main-1208020187 Subject: Re: [CDNi] Comments on draft draft-krishnan-cdni-tm-has-00 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, 02 Aug 2012 17:46:16 -0000 Hi Kevin, Thanks for your comments. Content acquisition and data plane is an importan= t part of interconnecting CDNs. If this is considered out of scope for CDNi= , is there any group chartered with this activity ? Thanks, ramki -----Original Message----- From: Kevin J Ma [mailto:kevin.ma@azukisystems.com]=20 Sent: Wednesday, August 01, 2012 7:50 PM To: ramki Krishnan; Brandenburg, R. (Ray) van; cdni@ietf.org; bhumip.khasna= bish@zteusa.com Subject: RE: Comments on draft draft-krishnan-cdni-tm-has-00 Hi Ram, inline: > -----Original Message----- > From: Kevin J Ma > Sent: Wednesday, August 01, 2012 10:14 PM > To: Kevin J Ma > Subject: FW: Comments on draft draft-krishnan-cdni-tm-has-00 >=20 >=20 >=20 > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf=20 > Of ramki Krishnan > Sent: Wednesday, August 01, 2012 10:10 PM > To: Brandenburg, R. (Ray) van; cdni@ietf.org;=20 > bhumip.khasnabish@zteusa.com > Subject: Re: [CDNi] Comments on draft draft-krishnan-cdni-tm-has-00 >=20 > Hi Ray, >=20 > Thanks for your comments. Please find responses inline. >=20 > Thanks, ram >=20 > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf=20 > Of Brandenburg, R. (Ray) van > Sent: Wednesday, August 01, 2012 2:22 PM > To: cdni@ietf.org; bhumip.khasnabish@zteusa.com > Subject: [CDNi] Comments on draft draft-krishnan-cdni-tm-has-00 >=20 > Hi Bhumip, >=20 > In response to your question during yesterday's CDNI meeting, I read=20 > your draft draft-krishnan-cdni-tm-has-00. >=20 > Since I'm not an expert on TCP and the way router queues are=20 > implemented, I can't comment on the more technical aspects of your=20 > draft. However, when looking at the rationale behind the draft I have som= e questions. >=20 > If I understand your draft correctly, your main premise is that in=20 > cases where HTTP Adaptive Streaming is used, the content acquisition=20 > interface between the dCDN and uCDN (which in itself is out-of-scope=20 > of the WG) could become congested. I have a number of questions related t= o this: >=20 > 1) What I don't understand from your draft is what the relationship is=20 > between this supposed content congestion and the use of adaptive=20 > streaming. Of course, in peak hours, there will generally be more=20 > traffic across the link than outside peak hours. But isn't true=20 > regardless of the case of whether HAS is used or not? > [ramki Krishnan] HAS automatically adapts to the network congestion=20 > and available bandwidth and delivers acceptable video quality to the=20 > user. For example, during normal hours, high resolution HD video would=20 > be delivered to the end user. Whereas, during peak hour congestion,=20 > low resolution HD video would be delivered to the end user. I don't think the functionality of HAS is in question. To Ray's point, if the link is congested, it's congested. And as Ray mentioned, content acquisition is out of scope. What is it that is being proposing wrt CDNI? Nothing prevents definition of a new content acquisition protocol which inc= orporates mandatory WRED, however, that seems orthogonal to CDNI. > 2) Furthermore, you state that "The bandwidth needs of HAS is directly=20 > proportional to the number of active end users who are streaming video." > Isn't the general idea behind using a (d)CDN that the necessary=20 > bandwidth between two CDNs is NOT directly proportional to the number=20 > of active end- users? > [ramki Krishnan] Below are cases where caching in dCDN may not work=20 > very well. > Pre-positioning of content may not work for all types of content; it=20 > often hard to predict in advance the content needs of users. With this=20 > background, CDNi network congestion could occur in the following=20 > scenarios > 1) During peak hours, in a pull model caching, the first copy of many=20 > HAS streams would be delivered. 2) Long-tail personalized content,=20 > which is not amenable to caching, is desired by the end user. I agree with Ray in questioning the premise that bandwidth needs are propor= itional to active users. Proportional to the number of different content a= ssets being streamed possibly, but not active users. It's not clear what p= repositioning has to do with the question of active users? > 3) In section 3. you refer to Long-tail personalized content. I'm not=20 > sure what this means. Do you mean dynamic content that is being=20 > generated on a per-user basis by the uCDN or the CSP? If so, what=20 > would be the use case for wanting to have this content be delivered by=20 > a dCDN? Wouldn't this defeat the purpose of having a dCDN at all,=20 > since the content has to be delivered on a per-user basis by the uCDN=20 > anyway? If the uCDN has to deliver the content to the dCDN for each=20 > individual user, wouldn't it be more efficient for the uCDN to deliver=20 > this content to the end-user directly? > [ramki Krishnan] Please find a short backgrounder below on long tail=20 > content. > http://www.wired.com/wired/archive/12.10/tail.html > http://whatis.techtarget.com/definition/long-tail > Amazon.com and Netflix.com both earn a larger percentage of their=20 > profits from relatively obscure, niche books and movies (long tail)=20 > than from rentals and purchases of best sellers and blockbusters (most po= pular). I don't think Ray was asking so much what long tail content is. I believe Ray was saying that if you don't want to cache that content, beca= use it's long tail, then don't send it through the CDN. Wrt CDNI, what is it that draft-krishnan-cdni-long-tail-00 is proposing? The CDNI requirements (specifically META-14) already discuss distribution c= ontrol policies, including preventing delegation. Beyond the ability to pr= event delegation, are you proposing that CDNs be required to implement anal= ytics-based delegation policies? That seems somewhat beyond our scope. thanx. -- Kevin J. Ma > Best regards, >=20 > Ray >=20 >=20 > This e-mail and its contents are subject to the DISCLAIMER at=20 > http://www.tno.nl/emaildisclaimer From Jan.Seedorf@neclab.eu Thu Aug 2 10:55:15 2012 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 4C06811E8072; Thu, 2 Aug 2012 10:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.592 X-Spam-Level: X-Spam-Status: No, score=-102.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, 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 tuV2UfMhj8AN; Thu, 2 Aug 2012 10:55:14 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id D7A2E11E816B; Thu, 2 Aug 2012 10:55:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 6FCD31019C5; Thu, 2 Aug 2012 20:00:49 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WBfkuaagtdAi; Thu, 2 Aug 2012 20:00:49 +0200 (CEST) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 51EDA1019C2; Thu, 2 Aug 2012 20:00:39 +0200 (CEST) Received: from PALLENE.office.hd ([169.254.1.252]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Thu, 2 Aug 2012 19:54:39 +0200 From: Jan Seedorf To: "cdni-footprint@ietf.org" Thread-Topic: Notes from the 2nd CDNI Footprint/capabilities design team side meeting at IETF-84 Thread-Index: Ac1w0jCasoJcOxhKQUm/aimy5Bi8hg== Date: Thu, 2 Aug 2012 17:55:33 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE32CE4DE8@PALLENE.office.hd> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.204] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: [CDNi] Notes from the 2nd CDNI Footprint/capabilities design team side meeting at IETF-84 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, 02 Aug 2012 17:55:15 -0000 Dear all, Here are my notes from yesterday's second footprint/capabilities design tea= m side meeting. The same disclaimer applies ("...probably have not captured= everything and admittedly the notes are rough in some cases"). Thanks to e= veryone for taking the time and the (in my view) productive discussion. - Jan -- CDNI Footprint Design team side meeting IETF-84 -- Wednesday, August 1st, 15:00-17:00 ************** -- start discussion by talking about capabilities first -- Jon: capabilities may only be valid for a partial footprint each -- Kevin: let's start with global capabilities first, and look later on cap= abilities that are only valid for a partial footprint -- Yannick: two different types of capabilities, related to request (e.g. p= rotocol), related to CDN=20 -- not clear what these two capabilities classes are, Yannick trying to exp= lain -- Yannick: classes of requests is first type of capability -- Kevin: on-net off-net is not a capability -- Gilles: capabilities are a functionality that I need to rely on -- Rich: when part of your CDN gets upgraded, you do not want to set up a n= ew contract -- Jan: do we all agree that there is kind of a generically valid contract,= and the interface we are taking about is for giving additional update info= rmation with respect to such a contract? -- Jon: what things do we know that they are useful? -- Yannick: footprint and capabilities are tied together, does not make sen= se to announce a capability, if you do not say along for which footprint it= is valid -- agreement on problem we are trying to solve --> provide additional updat= e information about capabilities that have changed/been added since the con= tract -- agreement that footprint and capabilities are tied together --> given ca= pabilities may apply only to a certain sub-part of the dCDN footprint -- Yannick: no use in announcing a footprint without saying the associated = capabilities -- suggestion from Francois to base the discussion and way forward on some = key use cases we all agree on -- Jon: only on-net or only off-net use case are simple, the interesting us= e case is where you have both mixed; Francois: this is the use case I am pr= oposing (mixed on-net and off-net) -- Yannick: default footprint is "everywhere"; Jon: new interesting idea -- agreement that we are talking about an interface that has the goal of up= dating the uCDN about recent changes in capabilities -- Gilles: the tie-breaking information will be outside of the interface we= are talking about (e.g. business) -- Francois: interface may provide "additional hints" for the uCDN selectio= n algorithm, let's rather call it that and not tie-breaker -- Rich: what does the uCDN have to have to find dCDN candidates is what is= important -- Kevin: let's not define hints yet -- Jon: delivery protocol is mandatory, agreement on this -- Gilles: there is a difference between binary supported/non-supported cap= abilities and value-range capabilities -- Kevin: support of metadata-bundles is mandatory capability -- Kevin: what about security parameters? -- Ray: what about CDNI features that are supported? (like DNS based reques= t routing); Jan: is that part of the control interface or part of the reque= st routing interface? -- Rich: still open issues regarding footprint -- agreement to focus on key use cases ************** From haibin.song@huawei.com Thu Aug 2 14:50:00 2012 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 6D87621E80A1; Thu, 2 Aug 2012 14:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.376 X-Spam-Level: X-Spam-Status: No, score=-6.376 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599, 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 AYwxMxzzycaT; Thu, 2 Aug 2012 14:49:59 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id C281F21E8093; Thu, 2 Aug 2012 14:49:58 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIQ35058; Thu, 02 Aug 2012 13:49:58 -0800 (PST) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 2 Aug 2012 14:46:43 -0700 Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 2 Aug 2012 14:46:41 -0700 Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.243]) by szxeml407-hub.china.huawei.com ([10.82.67.94]) with mapi id 14.01.0323.003; Fri, 3 Aug 2012 05:46:36 +0800 From: Songhaibin To: Jan Seedorf , "cdni-footprint@ietf.org" Thread-Topic: [CDNi] Notes from the 2nd CDNI Footprint/capabilities design team side meeting at IETF-84 Thread-Index: Ac1w0jCasoJcOxhKQUm/aimy5Bi8hgAJHxkP Date: Thu, 2 Aug 2012 21:46:36 +0000 Message-ID: References: <2779C9F0771F974CAD742BAE6D9904FE32CE4DE8@PALLENE.office.hd> In-Reply-To: <2779C9F0771F974CAD742BAE6D9904FE32CE4DE8@PALLENE.office.hd> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.1.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "cdni@ietf.org" Subject: Re: [CDNi] Notes from the 2nd CDNI Footprint/capabilities design team side meeting at IETF-84 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, 02 Aug 2012 21:50:00 -0000 Good discussion. I'm sorry that I missed it. I agree that capability should= be tied with footprint. IMO we need to answer to basic questions, then the= footprint/capbility interface can be clear. a. What factors will impact a particular CDN's footprint?=20 Is it the surrogate's topoligical distance to the content requester? = Or is it the performance requirements (e.g. for streaming, the average resp= onse time, and startup delay...) that should be satisfied for the applicati= on client? Or is it the geographical position of the CDN's surrogates? Or i= s it the capabilities about how many concurent requests this CDN can handle= ? b. then How to represent this footprint? This is obviously less important for now. -Haibin ________________________________________ From: cdni-bounces@ietf.org [cdni-bounces@ietf.org] on behalf of Jan Seedor= f [Jan.Seedorf@neclab.eu] Sent: Friday, August 03, 2012 1:55 AM To: cdni-footprint@ietf.org Cc: cdni@ietf.org Subject: [CDNi] Notes from the 2nd CDNI Footprint/capabilities design team = side meeting at IETF-84 Dear all, Here are my notes from yesterday's second footprint/capabilities design tea= m side meeting. The same disclaimer applies ("...probably have not captured= everything and admittedly the notes are rough in some cases"). Thanks to e= veryone for taking the time and the (in my view) productive discussion. - Jan -- CDNI Footprint Design team side meeting IETF-84 -- Wednesday, August 1st, 15:00-17:00 ************** -- start discussion by talking about capabilities first -- Jon: capabilities may only be valid for a partial footprint each -- Kevin: let's start with global capabilities first, and look later on cap= abilities that are only valid for a partial footprint -- Yannick: two different types of capabilities, related to request (e.g. p= rotocol), related to CDN -- not clear what these two capabilities classes are, Yannick trying to exp= lain -- Yannick: classes of requests is first type of capability -- Kevin: on-net off-net is not a capability -- Gilles: capabilities are a functionality that I need to rely on -- Rich: when part of your CDN gets upgraded, you do not want to set up a n= ew contract -- Jan: do we all agree that there is kind of a generically valid contract,= and the interface we are taking about is for giving additional update info= rmation with respect to such a contract? -- Jon: what things do we know that they are useful? -- Yannick: footprint and capabilities are tied together, does not make sen= se to announce a capability, if you do not say along for which footprint it= is valid -- agreement on problem we are trying to solve --> provide additional updat= e information about capabilities that have changed/been added since the con= tract -- agreement that footprint and capabilities are tied together --> given ca= pabilities may apply only to a certain sub-part of the dCDN footprint -- Yannick: no use in announcing a footprint without saying the associated = capabilities -- suggestion from Francois to base the discussion and way forward on some = key use cases we all agree on -- Jon: only on-net or only off-net use case are simple, the interesting us= e case is where you have both mixed; Francois: this is the use case I am pr= oposing (mixed on-net and off-net) -- Yannick: default footprint is "everywhere"; Jon: new interesting idea -- agreement that we are talking about an interface that has the goal of up= dating the uCDN about recent changes in capabilities -- Gilles: the tie-breaking information will be outside of the interface we= are talking about (e.g. business) -- Francois: interface may provide "additional hints" for the uCDN selectio= n algorithm, let's rather call it that and not tie-breaker -- Rich: what does the uCDN have to have to find dCDN candidates is what is= important -- Kevin: let's not define hints yet -- Jon: delivery protocol is mandatory, agreement on this -- Gilles: there is a difference between binary supported/non-supported cap= abilities and value-range capabilities -- Kevin: support of metadata-bundles is mandatory capability -- Kevin: what about security parameters? -- Ray: what about CDNI features that are supported? (like DNS based reques= t routing); Jan: is that part of the control interface or part of the reque= st routing interface? -- Rich: still open issues regarding footprint -- agreement to focus on key use cases ************** _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni= From ramk@Brocade.com Fri Aug 3 08:04:28 2012 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 47B4E21F8DEB for ; Fri, 3 Aug 2012 08:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.264 X-Spam-Level: X-Spam-Status: No, score=-3.264 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, 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 usjZathgohx5 for ; Fri, 3 Aug 2012 08:04:26 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) by ietfa.amsl.com (Postfix) with ESMTP id 8A54521F8DE6 for ; Fri, 3 Aug 2012 08:04:26 -0700 (PDT) Received: from pps.filterd (m0000542 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id q73F3v01032694; Fri, 3 Aug 2012 08:04:19 -0700 Received: from hq1wp-exhub02.corp.brocade.com ([144.49.131.13]) by mx0a-000f0801.pphosted.com with ESMTP id 16etfjsgdf-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 03 Aug 2012 08:04:19 -0700 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB02.corp.brocade.com ([fe80::e1f4:a4c8:696b:3780%10]) with mapi; Fri, 3 Aug 2012 08:04:19 -0700 From: ramki Krishnan To: "cdni@ietf.org" , Kevin J Ma Date: Fri, 3 Aug 2012 08:04:11 -0700 Thread-Topic: Long Tail personalized content delivery over CDN Interconnections Thread-Index: Ac1vRZcsWETXd9GaR6qHr8+wPfW6agCQbc5Q Message-ID: References: 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_C7634EB63EFD984A978DFB46EA5174F2BD6D3BCBF8HQ1EXCH01corp_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.7.7855, 1.0.260, 0.0.0000 definitions=2012-08-03_03:2012-08-03, 2012-08-03, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=81 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1207200000 definitions=main-1208030139 Cc: Ram Krishnan , "Bhumip.Khasnabish@zte.com.cn" Subject: Re: [CDNi] Long Tail personalized content delivery over CDN Interconnections 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, 03 Aug 2012 15:04:28 -0000 --_000_C7634EB63EFD984A978DFB46EA5174F2BD6D3BCBF8HQ1EXCH01corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Kevin, Thanks a lot for your comments. Please see response below Kevin: >>Wrt CDNI, what is it that draft-krishnan-cdni-long-tail-00 is proposing? >>The CDNI requirements (specifically META-14) already discuss distribution= control policies, including preventing delegation. Beyond the ability to = >>prevent delegation, are you proposing that CDNs be required to implement = analytics-based delegation policies? That seems somewhat beyond our scope. Ramki: The CDNi req META-14 is about the selection of dCDN, but what long tail dra= ft is proposing is the selection of uCDN based on the content attribute, i.= e. whether the content is long tail personalized or not. The long tail draf= t also brings in the concept of no caching in the uCDN and dCDN for certain= types of content based on the content attribute, for e.g. long tail person= alized content. The impacts of this on CDNi request routing is also explain= ed. Thanks, ramki From: Bhumip Khasnabish [mailto:vumip1@gmail.com] Sent: Tuesday, July 31, 2012 10:55 AM To: cdni@ietf.org Cc: Ram Krishnan; ramki Krishnan; li.mian@zte.com.cn Subject: Fwd: Long Tail personalized content delivery over CDN Interconnect= ions FYI.. looking for comments and suggestions on delivery of the most popular to long tail personalized content over CDNI. This document presents the issues and suggests solutions in delivering long= tail personalized content in CDN Interconnection scenarios. Thanks a lot. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++= ++++++++++++++++++++ I-D Action: draft-krishnan-cdni-long-tail-00.txt ________________________________ * To: i-d-announce at ietf.org * Subject: I-D Action: draft-krishnan-cdni-long-tail-00.txt * From: internet-drafts at ietf.org * Date: Mon, 30 Jul 2012 16:49:30 -0700 * Delivered-to: i-d-announce at ietfa.amsl.com * List-archive: * List-help: * List-id: Internet Draft Announcements only > * List-post: * List-subscribe: , = * List-unsubscribe: ,= * Reply-to: internet-drafts at ietf.org ________________________________ A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Long Tail personalized content delivery over CDN = Interconnections Author(s) : Ram Krishnan Mian Li Bhumip Khasnabish Filename : draft-krishnan-cdni-long-tail-00.txt Pages : 7 Date : 2012-07-30 Abstract: The content desire of users is evolving from most popular to long tail personalized content. This document presents the issues and suggests solutions in delivering long tail personalized content in CDN Interconnection scenarios. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-krishnan-cdni-long-tail There's also a htmlized version available at: http://tools.ietf.org/html/draft-krishnan-cdni-long-tail-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ --_000_C7634EB63EFD984A978DFB46EA5174F2BD6D3BCBF8HQ1EXCH01corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Kevin,

 

= Thanks a lot for your comments. Please see response below=

 

Kevin:

>>Wrt CDNI, what is it that draf= t-krishnan-cdni-long-tail-00 is proposing?

>>The CDNI requirements (specifically META-14) already discuss = distribution control policies, including preventing delegation.  Beyon= d the ability to >>prevent delegation, are you proposing that CDNs be= required to implement analytics-based delegation policies?  That seem= s somewhat beyond our scope.

 

=

Ram= ki:

The CDNi req META-14 is about the selection of dCDN, = but what long tail draft is proposing is the selection of uCDN based on the= content attribute, i.e. whether the content is long tail personalized or n= ot. The long tail draft also brings in the concept of no caching in the uCD= N and dCDN for certain types of content based on the content attribute, for= e.g. long tail personalized content. The impacts of this on CDNi request r= outing is also explained.

Thanks, ramki

 

From: Bhumip Khasnabish [mailto:vumip1@gmail.com]
Sent: Tu= esday, July 31, 2012 10:55 AM
To: cdni@ietf.org
Cc: Ram= Krishnan; ramki Krishnan; li.mian@zte.com.cn
Subject: Fwd: Long = Tail personalized content delivery over CDN Interconnections

 

 

FYI.. looking for comments and suggestions on delivery of

the most popular to long tail personalized content over CDNI.

 

This document presents= the issues and suggests solutions in delivering long tail

persona= lized content in CDN Interconnection scenarios. Thanks a lot.


+++++++++++++++++++= +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++= +

I-D Action: draft-krishnan-cdni-long-tail-00.txt<= o:p>

= --_000_C7634EB63EFD984A978DFB46EA5174F2BD6D3BCBF8HQ1EXCH01corp_-- From flefauch@cisco.com Fri Aug 3 08:15:05 2012 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 D938421F8DA7 for ; Fri, 3 Aug 2012 08:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.538 X-Spam-Level: X-Spam-Status: No, score=-10.538 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 vF2Lpggx2xvl for ; Fri, 3 Aug 2012 08:15:04 -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 48E0721F8D52 for ; Fri, 3 Aug 2012 08:15:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=30848; q=dns/txt; s=iport; t=1344006904; x=1345216504; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=fkKu4dQIADl9c+fWliqRgH+hguvzHH5ZOMv2QFRiQtI=; b=VjrM0j30Y0pbfFbGT438QwW65aZhIZGmc0mZ3x8sXVnf+sRpTSyIznkt 3xb3Y+hvZySfMYBwISBIjDtdGkcfFSW3+x0lq7+fhpGUNciATul/mSI+u miVNDxEkn6raXjhFdynWjJavDT8JuSOKnfhSl9f6dQ++x4R9Onut3TULh w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoIFAOfpG1CtJV2Z/2dsb2JhbABFgkqldYgQAYhPgQeCIAEBAQQBAQEPATsgCxACAQgRAwEBAQ0UAQYHIQYKARQJCAIEDgEEAQgSAgQBh1wDDAucPZZPDYlOimFnGoYKYAOTd4FTgRSJdoMdgWaCX4Ff X-IronPort-AV: E=Sophos;i="4.77,706,1336348800"; d="scan'208,217";a="108221816" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 03 Aug 2012 15:15:03 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q73FF3YJ011632 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 3 Aug 2012 15:15:03 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.184]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0298.004; Fri, 3 Aug 2012 10:15:03 -0500 From: "Francois Le Faucheur (flefauch)" To: ramki Krishnan Thread-Topic: [CDNi] Long Tail personalized content delivery over CDN Interconnections Thread-Index: AQHNcYlNeF7QHEEcLkW9PRj8nifKlZdIhfWA Date: Fri, 3 Aug 2012 15:15:01 +0000 Message-ID: <13DB8195-C760-489E-B43E-C16E53FBE7BB@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.254.53.127] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19082.002 x-tm-as-result: No--38.826400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_13DB8195C760489EB43EC16E53FBE7BBciscocom_" MIME-Version: 1.0 Cc: "cdni@ietf.org" , Ram Krishnan , "Bhumip.Khasnabish@zte.com.cn" Subject: Re: [CDNi] Long Tail personalized content delivery over CDN Interconnections 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, 03 Aug 2012 15:15:06 -0000 --_000_13DB8195C760489EB43EC16E53FBE7BBciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On 3 Aug 2012, at 17:04, ramki Krishnan wrote: Hi Kevin, Thanks a lot for your comments. Please see response below Kevin: >>Wrt CDNI, what is it that draft-krishnan-cdni-long-tail-00 is proposing? >>The CDNI requirements (specifically META-14) already discuss distribution= control policies, including preventing delegation. Beyond the ability to = >>prevent delegation, are you proposing that CDNs be required to implement = analytics-based delegation policies? That seems somewhat beyond our scope. Ramki: The CDNi req META-14 is about the selection of dCDN, but what long tail dra= ft is proposing is the selection of uCDN the selection of uCDN by whom? based on the content attribute, i.e. whether the content is long tail perso= nalized or not. The long tail draft also brings in the concept of no cachin= g in the uCDN The intra-CDN decision of the uCDN to cache or not is generally outside the= scope of CDNI. We are not disagreeing that the uCDN may elect to not cache= some content (and in that case to not redirect to a dCDN), but this does n= ot seem directly related to CDNI. and dCDN for certain types of content based on the content attribute, for e= .g. long tail personalized content. The impacts of this on CDNi request rou= ting is also explained. Can you summarize again very briefly the interaction you see between the de= sire to not cache some content and the CDNI interfaces? (when discussing Re= quest Routing, please separate the impact you see on the Request Routing/Re= direction interface vs Request Routing/Footprint & Cap Interface). Thanks Thanks, ramki From: Bhumip Khasnabish [mailto:vumip1@gmail.com] Sent: Tuesday, July 31, 2012 10:55 AM To: cdni@ietf.org Cc: Ram Krishnan; ramki Krishnan; li.mian@zte.com.cn Subject: Fwd: Long Tail personalized content delivery over CDN Interconnect= ions FYI.. looking for comments and suggestions on delivery of the most popular to long tail personalized content over CDNI. This document presents the issues and suggests solutions in delivering long= tail personalized content in CDN Interconnection scenarios. Thanks a lot. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++= ++++++++++++++++++++ I-D Action: draft-krishnan-cdni-long-tail-00.txt ________________________________ * To: i-d-announce at ietf.org * Subject: I-D Action: draft-krishnan-cdni-long-tail-00.txt * From: internet-drafts at ietf.org * Date: Mon, 30 Jul 2012 16:49:30 -0700 * Delivered-to: i-d-announce at ietfa.amsl.com * List-archive: * List-help: * List-id: Internet Draft Announcements only > * List-post: * List-subscribe: ,= * List-unsubscribe: = , * Reply-to: internet-drafts at ietf.org ________________________________ A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Long Tail personalized content delivery over CDN = Interconnections Author(s) : Ram Krishnan Mian Li Bhumip Khasnabish Filename : draft-krishnan-cdni-long-tail-00.txt Pages : 7 Date : 2012-07-30 Abstract: The content desire of users is evolving from most popular to long tail personalized content. This document presents the issues and suggests solutions in delivering long tail personalized content in CDN Interconnection scenarios. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-krishnan-cdni-long-tail There's also a htmlized version available at: http://tools.ietf.org/html/draft-krishnan-cdni-long-tail-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni --_000_13DB8195C760489EB43EC16E53FBE7BBciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <31E9403B183C014E85B8599D6B323A54@cisco.com> Content-Transfer-Encoding: quoted-printable
On 3 Aug 2012, at 17:04, ramki Krishnan wrote:

Hi Kevi= n,
&n= bsp;
Thanks = a lot for your comments. Please see response below
&n= bsp;
Kevin:<= o:p>
>>= ;Wrt CDNI, what is it that draft-krishnan-cdni-long-tail-00 is proposing?
>>= ;The CDNI requirements (specifically META-14) already discuss distribution = control policies, including preventing delegation.  Beyond the ability= to >>prevent delegation, are you proposing that CDNs be required to implement analytics-based delegation policies?  T= hat seems somewhat beyond our scope.
 =
Ramki:=
The CDNi req META-14 is = about the selection of dCDN, but what long tail draft is proposing is the s= election of uCDN

the selection of uCDN by whom?

based on the content att= ribute, i.e. whether the content is long tail personalized or not. The long= tail draft also brings in the concept of no caching in the uCDN

The intra-CDN decision of the uCDN to cache or not is generally outsid= e the scope of CDNI. We are not disagreeing that the uCDN may elect to not = cache some content (and in that case to not redirect to a dCDN), but this d= oes not seem directly related to CDNI.

and dCDN for certain typ= es of content based on the content attribute, for e.g. long tail personaliz= ed content. The impacts of this on CDNi request routing is also explained.<= span class=3D"Apple-converted-space"> 

Can you summarize again very briefly the interaction you see between t= he desire to not cache some content and the CDNI interfaces? (when discussi= ng Request Routing, please separate the impact you see on the Request Routi= ng/Redirection interface vs Request Routing/Footprint & Cap Interface).

Thanks


Thanks, ramki=
&nbs= p;
From:=  Bhumip Khasnabish [ma= ilto:vumip1@gmail.com]  Sent: Tuesday, Jul= y 31, 2012 10:55 AM
To: cdni= @ietf.org
Cc: Ram Krishnan; = ramki Krishnan; li.mian@zte.com.cn
Subject: Fwd: Long= Tail personalized content delivery over CDN Interconnections
 
 
FYI.. looking for comments and sugg= estions on delivery of
the most popular to long tail perso= nalized content over CDNI.
 
This document presents the issues a= nd suggests solutions in delivering long tail
personalized content in CDN Interco= nnection scenarios. Thanks a lot.

+++++++++++++++= +++++++++++++++= +++++++++++++++= +++++++++++++++= +++++++++++++++= +++++++++++++++= +++++

I-D Action: draft-krishnan-cdni-long-tail-00.txt

A New Inte=
rnet-Draft is available from the on-line Internet-Drafts directories.<=
/o:p>
 =
;
 =
;
 &nbs=
p;      Title      &=
nbsp;    : Long Tail personalized content delivery over CDN =
Interconnections
 &nbs=
p;      Author(s)     &nb=
sp; : Ram Krishnan
 &nbs=
p;            &=
nbsp;           Mian Li
 &nbs=
p;            &=
nbsp;           Bhumip Kh=
asnabish
 &nbs=
p;      Filename     &nbs=
p;  : draft-krishnan-cdni-long-tail-00.txt
 &nbs=
p;      Pages      &=
nbsp;    : 7
 &nbs=
p;      Date      &n=
bsp;     : 2012-07-30
 =
;
Abstract:<=
o:p>
 &nbs=
p; The content desire of users is evolving from most popular to long
 &nbs=
p; tail personalized content. This document presents the issues and
 &nbs=
p; suggests solutions in delivering long tail personalized content in<=
/o:p>
 &nbs=
p; CDN Interconnection scenarios.
 =
;
 =
;
The IETF d=
atatracker status page for this draft is:
https://datatra=
cker.ietf.org/doc/draft-krishnan-cdni-long-tail
 =
;
There's al=
so a htmlized version available at:
http://tools.ietf.=
org/html/draft-krishnan-cdni-long-tail-00
 =
;
 =
;
Internet-D=
rafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/cdni<= /a>

--_000_13DB8195C760489EB43EC16E53FBE7BBciscocom_-- From kevin.ma@azukisystems.com Sat Aug 4 23:59:48 2012 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 EEAD521F87C4 for ; Sat, 4 Aug 2012 23:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.638 X-Spam-Level: X-Spam-Status: No, score=-2.638 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599] 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 2w3h1W38oBMo for ; Sat, 4 Aug 2012 23:59:48 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.244]) by ietfa.amsl.com (Postfix) with ESMTP id 4385A21F87BE for ; Sat, 4 Aug 2012 23:59:48 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 0224D416868 for ; Sun, 5 Aug 2012 02:59:50 -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 9DBF9416862 for ; Sun, 5 Aug 2012 02:59:49 -0400 (EDT) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB024.mail.lan ([10.110.17.24]) with mapi; Sun, 5 Aug 2012 02:59:46 -0400 From: Kevin J Ma To: "cdni@ietf.org" Date: Sun, 5 Aug 2012 02:59:43 -0400 Thread-Topic: New Version Notification for draft-ma-cdni-capabilities-00.txt Thread-Index: Ac1y0RjU9ZpGjjABTBmqzlg36gIVywAAA2WQ Message-ID: <291CC3F9E50E7641901A54E85D0977C653270702D4@MAILR002.mail.lan> References: <20120805061102.6419.90677.idtracker@ietfa.amsl.com> In-Reply-To: <20120805061102.6419.90677.idtracker@ietfa.amsl.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [CDNi] FW: New Version Notification for draft-ma-cdni-capabilities-00.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: Sun, 05 Aug 2012 06:59:49 -0000 SGkgQWxsLA0KDQogIEkganVzdCB1cGxvYWRlZCBhIGNhcGFiaWxpdGllcyBpbnRlcmZhY2UgZHJh ZnQuDQogIEkgd2FudGVkIHRvIG1ha2UgbW9yZSBjb25jcmV0ZSBteSBwcm9wb3NhbCBmcm9tIHRo ZSBzZWNvbmQgZm9vdHByaW50DQogIGFuZCBjYXBhYmlsaXRpZXMgZGVzaWduIHRlYW0gbWVldGlu ZyBoZWxkIGxhc3QgV2VkbmVzZGF5IGluIFZhbmNvdXZlci4NCg0KICBUaGUgZHJhZnQgaW5jb3Jw b3JhdGVzIG1hbnkgb2YgdGhlIHBvaW50cyBkaXNjdXNzZWQgaW4gdGhhdCBtZWV0aW5nLg0KICBJ dCBwcm9wb3NlcyBhIG1pbmltYWwgY2FwYWJpbGl0eSBhZHZlcnRpc2VtZW50IGludGVyZmFjZSBh bmQgZGVzY3JpYmVzDQogIGtleSB1c2UgY2FzZXMgZm9yIGNhcGFiaWxpdHkgYWdncmVnYXRpb24u ICBUaGVyZSBhcmUgYSBudW1iZXIgb2Ygbm90ZXMNCiAgaW4gdGhlIGRvY3VtZW50IGRlc2NyaWJp bmcgd2hlcmUgbW9yZSBpbmZvcm1hdGlvbiBpcyByZXF1aXJlZCwgYnV0DQogIGhvcGVmdWxseSBp dCBwcm92aWRlcyBhIHN0YXJ0aW5nIHBvaW50LiAgQ29tbWVudHMgYXJlIHdlbGNvbWUuDQoNCnRo YW54Lg0KDQotLSAgS2V2aW4gSi4gTWENCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy b206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZ10gDQpTZW50OiBTdW5kYXksIEF1Z3VzdCAwNSwgMjAxMiAyOjExIEFNDQpUbzogS2V2aW4g SiBNYQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1tYS1jZG5p LWNhcGFiaWxpdGllcy0wMC50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtbWEt Y2RuaS1jYXBhYmlsaXRpZXMtMDAudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVk IGJ5IEtldmluIEouIE1hIGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoNCkZp bGVuYW1lOgkgZHJhZnQtbWEtY2RuaS1jYXBhYmlsaXRpZXMNClJldmlzaW9uOgkgMDANClRpdGxl OgkJIENvbnRlbnQgRGlzdHJpYnV0aW9uIE5ldHdvcmsgSW50ZXJjb25uZWN0aW9uIChDRE5JKSBD YXBhYmlsaXRpZXMgSW50ZXJmYWNlDQpDcmVhdGlvbiBkYXRlOgkgMjAxMi0wOC0wNQ0KV0cgSUQ6 CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDIwDQpVUkw6ICAgICAg ICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LW1hLWNkbmkt Y2FwYWJpbGl0aWVzLTAwLnR4dA0KU3RhdHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LW1hLWNkbmktY2FwYWJpbGl0aWVzDQpIdG1saXplZDogICAgICAg IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW1hLWNkbmktY2FwYWJpbGl0aWVzLTAw DQoNCg0KQWJzdHJhY3Q6DQogICBUaGUgaW50ZXJjb25uZWN0aW9uIG9mIENvbnRlbnQgRGlzdHJp YnV0aW9uIE5ldHdvcmtzIChDRE5zKSBpcw0KICAgcHJlZGljYXRlZCBvbiB0aGUgYWJpbGl0eSBv ZiBkb3duc3RyZWFtIENETnMgKGRDRE5zKSB0byBoYW5kbGUgZW5kLQ0KICAgdXNlciByZXF1ZXN0 cyBpbiBhIGZ1bmN0aW9uYWxseSBlcXVpdmFsZW50IG1hbm5lciB0byB0aGUgdXBzdHJlYW0gQ0RO DQogICAodUNETikuICBUaGUgdUNETiBtdXN0IGJlIGFibGUgdG8gYXNzZXNzIHRoZSBhYmlsaXR5 IG9mIHRoZSBkQ0ROIHRvDQogICBoYW5kbGUgaW5kaXZpZHVhbCByZXF1ZXN0cy4gIEEgQ0ROIGlu dGVyY29ubmVjdGlvbiAoQ0ROSSkgaW50ZXJmYWNlDQogICBpcyBuZWVkZWQgdG8gZmFjaWxpdGF0 ZSB0aGUgYWR2ZXJ0aXNlbWVudCBvZiBjYXBhYmlsaXRpZXMgYnkgdGhlIGRDRE4NCiAgIHRvIHRo ZSB1Q0ROLiAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYW4gYXBwcm9hY2ggdG8gaW1wbGVtZW50 aW5nIGENCiAgIENETkkgY2FwYWJpbGl0aWVzIGFkdmVydGlzZW1lbnQgaW50ZXJmYWNlLg0KDQoN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From ben@niven-jenkins.co.uk Mon Aug 6 05:10:47 2012 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 09F2621F8541 for ; Mon, 6 Aug 2012 05:10:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.462 X-Spam-Level: X-Spam-Status: No, score=-102.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, 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 7kRiDs9D1hU5 for ; Mon, 6 Aug 2012 05:10:46 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC8221F8526 for ; Mon, 6 Aug 2012 05:10:46 -0700 (PDT) Received: from cpc4-cmbg17-2-0-cust814.5-4.cable.virginmedia.com ([86.14.227.47] helo=[192.168.0.4]) by mail4.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1SyM8y-0004Tu-SA; Mon, 06 Aug 2012 13:10:45 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: <5018BF8D.4040506@cs.yale.edu> Date: Mon, 6 Aug 2012 13:10:43 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1A68A590-C06E-4A62-A213-503392AD9280@niven-jenkins.co.uk> References: <5018BF8D.4040506@cs.yale.edu> To: Y. Richard Yang X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: cdni@ietf.org Subject: Re: [CDNi] comments on draft-lefaucheur-cdni-logging-delivery-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: Mon, 06 Aug 2012 12:10:47 -0000 Richard, On 1 Aug 2012, at 06:33, Y. Richard Yang wrote: > Hi all, >=20 > As suggested by Francois during the meeting today, here are some = comments on draft-lefaucheur-cdni-logging-delivery-01, on the Regular = HTTP Log Fields (Sec. 2.2): >=20 > - We may Client Port in addition to Client IP; >=20 > - About request parameters encoded in message body. In particular, = some request parameters (URI, for example, for the purpose of hiding) = may be encoded in the message body of a POST message; I'm not convinced the dCDN should start trying to interpret & parse the = content type of message bodies to try to extract additional logging = parameters. Ben From swainner@cisco.com Mon Aug 6 07:05:54 2012 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 8E7EA21F865F for ; Mon, 6 Aug 2012 07:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.224 X-Spam-Level: X-Spam-Status: No, score=-10.224 tagged_above=-999 required=5 tests=[AWL=0.375, BAYES_00=-2.599, 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 xIvacrjq+QXY for ; Mon, 6 Aug 2012 07:05:53 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 87CED21F869A for ; Mon, 6 Aug 2012 07:05:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=swainner@cisco.com; l=5340; q=dns/txt; s=iport; t=1344261953; x=1345471553; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=GZ7EmV7Jog8A4RyhBBO1/QhG4NdO1DeUQQoaMWKC198=; b=hCs0NCkFnMUKA4jvJg8eH/Bk5mkNsXA6p8w399mKLF5rKiSl904t9pU0 KVYRyzKjyuT+UAnUm+VlmkxCz+/kL2A9e3YyqBP5t6Vyqb0QbP+88QCda u0G/oacmQfwm8RjGvJOe9Si69ej7DvcCcbp+PsrC64Mcq4GJTQQD0K3AP 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EALXOH1CtJXHA/2dsb2JhbABFuUWBB4IgAQEBBAEBAQ8BFBE2GwsYCSUPAhYwEwYCAQEeh2sLm0SfcASLXhOGXQOVSY4mgWaCe4E6Ag X-IronPort-AV: E=Sophos;i="4.77,720,1336348800"; d="scan'208";a="108831492" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-4.cisco.com with ESMTP; 06 Aug 2012 14:05:52 +0000 Received: from rtp-swainner-89110.cisco.com (rtp-swainner-89110.cisco.com [10.116.109.203]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q76E5pni020109 for ; Mon, 6 Aug 2012 14:05:51 GMT Message-ID: <501FCF3F.30400@cisco.com> Date: Mon, 06 Aug 2012 10:05:51 -0400 From: Scott Wainner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: cdni@ietf.org References: <2779C9F0771F974CAD742BAE6D9904FE32CE4DE8@PALLENE.office.hd> In-Reply-To: <2779C9F0771F974CAD742BAE6D9904FE32CE4DE8@PALLENE.office.hd> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [CDNi] Notes from the 2nd CDNI Footprint/capabilities design team side meeting at IETF-84 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, 06 Aug 2012 14:05:54 -0000 My apologies for not being able to join you in Vancouver. My interpretation of the Use Cases with regards to geography: 2.1 uCDN with limited geographic scope refers to a global dCDN 2.3 uCDN with limited geographic scope refers to a another dCDN with limited geographic scope 2.2 uCDN with global geographic scope refers to a dCDN with limited geographic scope In none of the 2.x Use Cases do we define any capability limitations. There seems to be an assumption that the delegate CDN can do anything the uCDN can do. I certainly don't believe that is true as others have noted below. There seems to be an intrinsic requirement to correlate 'footprint' with a 'capability'. Independently we define a set of Use Cases in Section 4.x and we don't set conditions for the 'footprint'. If we believe that the 'footprint' and 'capabilities' must now be correlated, do we need to determine the order of dependency? Example with Footprint Dependency: Footprint A (AS_A or Prefix_A) Capabilities 1 (HTTP DASH) Capabilities 2 (HTTP HLS) Capabilities 3 (HTTP HSS) Footprint B (AS_B or Prefix_B) Capabilities 2 (HTTP HLS) Or do you use the reverse using Capability dependency as follows: Capability 1 (HTTP DASH) Footprint A (AS_A or Prefix_A) Capability 2 (HTTP HLS) Footprint A (AS_A or Prefix_A) Footprint B (AS_B or Prefix_B) Capability 3 (HTTP HSS) Footprint A (AS_A or Prefix_A) I suspect the capabilities will get a lot more complicated (URL Signing, Delivery Protocol, Delegation Method (DNS-I, DNS-R, HTTP-I, HTTP-R). Any thoughts on the appropriate order of dependency? Scott On 8/2/12 1:55 PM, Jan Seedorf wrote: > Dear all, > > Here are my notes from yesterday's second footprint/capabilities design team side meeting. The same disclaimer applies ("...probably have not captured everything and admittedly the notes are rough in some cases"). Thanks to everyone for taking the time and the (in my view) productive discussion. > > - Jan > > > -- CDNI Footprint Design team side meeting IETF-84 > -- Wednesday, August 1st, 15:00-17:00 > ************** > -- start discussion by talking about capabilities first > -- Jon: capabilities may only be valid for a partial footprint each > -- Kevin: let's start with global capabilities first, and look later on capabilities that are only valid for a partial footprint > -- Yannick: two different types of capabilities, related to request (e.g. protocol), related to CDN > -- not clear what these two capabilities classes are, Yannick trying to explain > -- Yannick: classes of requests is first type of capability > -- Kevin: on-net off-net is not a capability > -- Gilles: capabilities are a functionality that I need to rely on > -- Rich: when part of your CDN gets upgraded, you do not want to set up a new contract > -- Jan: do we all agree that there is kind of a generically valid contract, and the interface we are taking about is for giving additional update information with respect to such a contract? > -- Jon: what things do we know that they are useful? > -- Yannick: footprint and capabilities are tied together, does not make sense to announce a capability, if you do not say along for which footprint it is valid > -- agreement on problem we are trying to solve --> provide additional update information about capabilities that have changed/been added since the contract > -- agreement that footprint and capabilities are tied together --> given capabilities may apply only to a certain sub-part of the dCDN footprint > -- Yannick: no use in announcing a footprint without saying the associated capabilities > -- suggestion from Francois to base the discussion and way forward on some key use cases we all agree on > -- Jon: only on-net or only off-net use case are simple, the interesting use case is where you have both mixed; Francois: this is the use case I am proposing (mixed on-net and off-net) > -- Yannick: default footprint is "everywhere"; Jon: new interesting idea > -- agreement that we are talking about an interface that has the goal of updating the uCDN about recent changes in capabilities > -- Gilles: the tie-breaking information will be outside of the interface we are talking about (e.g. business) > -- Francois: interface may provide "additional hints" for the uCDN selection algorithm, let's rather call it that and not tie-breaker > -- Rich: what does the uCDN have to have to find dCDN candidates is what is important > -- Kevin: let's not define hints yet > -- Jon: delivery protocol is mandatory, agreement on this > -- Gilles: there is a difference between binary supported/non-supported capabilities and value-range capabilities > -- Kevin: support of metadata-bundles is mandatory capability > -- Kevin: what about security parameters? > -- Ray: what about CDNI features that are supported? (like DNS based request routing); Jan: is that part of the control interface or part of the request routing interface? > -- Rich: still open issues regarding footprint > -- agreement to focus on key use cases > ************** > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > . > From yry@cs.yale.edu Mon Aug 6 08:57:23 2012 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 C595821F85ED for ; Mon, 6 Aug 2012 08:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] 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 HMCVBf+J9YRu for ; Mon, 6 Aug 2012 08:57:23 -0700 (PDT) Received: from vm-emlprdomr-02.its.yale.edu (vm-emlprdomr-02.its.yale.edu [130.132.50.143]) by ietfa.amsl.com (Postfix) with ESMTP id 10F7021F859A for ; Mon, 6 Aug 2012 08:57:22 -0700 (PDT) Received: from Faculty-Supports-MacBook-Pro-2.local ([128.36.46.193]) (authenticated bits=0) by vm-emlprdomr-02.its.yale.edu (8.14.4/8.14.4) with ESMTP id q76FvILM031540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 6 Aug 2012 11:57:19 -0400 Message-ID: <501FE95E.8060607@cs.yale.edu> Date: Mon, 06 Aug 2012 08:57:18 -0700 From: "Y. Richard Yang" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Ben Niven-Jenkins References: <5018BF8D.4040506@cs.yale.edu> <1A68A590-C06E-4A62-A213-503392AD9280@niven-jenkins.co.uk> In-Reply-To: <1A68A590-C06E-4A62-A213-503392AD9280@niven-jenkins.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.71 on 130.132.50.143 Cc: cdni@ietf.org Subject: Re: [CDNi] comments on draft-lefaucheur-cdni-logging-delivery-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: Mon, 06 Aug 2012 15:57:23 -0000 Hi Ben, On 8/6/12 5:10 AM, Ben Niven-Jenkins wrote: > Richard, > > On 1 Aug 2012, at 06:33, Y. Richard Yang wrote: > >> Hi all, >> >> As suggested by Francois during the meeting today, here are some comments on draft-lefaucheur-cdni-logging-delivery-01, on the Regular HTTP Log Fields (Sec. 2.2): >> >> - We may Client Port in addition to Client IP; >> >> - About request parameters encoded in message body. In particular, some request parameters (URI, for example, for the purpose of hiding) may be encoded in the message body of a POST message; > I'm not convinced the dCDN should start trying to interpret & parse the content type of message bodies to try to extract additional logging parameters. What I had in mind was to parse the content id. One way to indicate a stream is http://www.example.com/vod?vid=123456 but I know CSPs who hide the vid in POST (not visible in browser) Hence, the video id needs to be extracted from the message body. Does this make sense to you? Richard > Ben > From kevin.ma@azukisystems.com Mon Aug 6 09:10:53 2012 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 BFBA521E8043 for ; Mon, 6 Aug 2012 09:10:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.635 X-Spam-Level: X-Spam-Status: No, score=-2.635 tagged_above=-999 required=5 tests=[AWL=-0.036, BAYES_00=-2.599] 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 GWpY06sT9q-1 for ; Mon, 6 Aug 2012 09:10:53 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.244]) by ietfa.amsl.com (Postfix) with ESMTP id C06C721E8042 for ; Mon, 6 Aug 2012 09:10:52 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id A0E2E416A6D; Mon, 6 Aug 2012 12:10:54 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB015.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 370BC416AC4; Mon, 6 Aug 2012 12:10:44 -0400 (EDT) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB015.mail.lan ([10.110.17.15]) with mapi; Mon, 6 Aug 2012 12:10:20 -0400 From: Kevin J Ma To: Scott Wainner , "cdni@ietf.org" Date: Mon, 6 Aug 2012 12:10:38 -0400 Thread-Topic: [CDNi] Notes from the 2nd CDNI Footprint/capabilities design team side meeting at IETF-84 Thread-Index: Ac1z3JqYa5+2s3w0SYKB6lxUgNP7AQADxyvw Message-ID: <291CC3F9E50E7641901A54E85D0977C65327070474@MAILR002.mail.lan> References: <2779C9F0771F974CAD742BAE6D9904FE32CE4DE8@PALLENE.office.hd> <501FCF3F.30400@cisco.com> In-Reply-To: <501FCF3F.30400@cisco.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 Subject: Re: [CDNi] Notes from the 2nd CDNI Footprint/capabilities design team side meeting at IETF-84 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, 06 Aug 2012 16:10:53 -0000 Hi Scott, I think that footprint can be used for other purposes besides describing, capabilities, but that capabilities may need footprint restrictions. The draft I submitted deals with the latter. The former seems to become more entangled with quality. imo, the two should probably be separated, i.e., capabilities tell if a CDN is technologically capable of handling a given request, while there may be other footprint related information which can describe how (physically) well the request can be handled. That question of "how well" is a much harder problem which was discussed at length... thanx. -- Kevin J. Ma > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of > Scott Wainner > Sent: Monday, August 06, 2012 10:06 AM > To: cdni@ietf.org > Subject: Re: [CDNi] Notes from the 2nd CDNI Footprint/capabilities design > team side meeting at IETF-84 >=20 > My apologies for not being able to join you in Vancouver. >=20 > My interpretation of the Use Cases with regards to geography: >=20 > 2.1 uCDN with limited geographic scope refers to a global dCDN > 2.3 uCDN with limited geographic scope refers to a another dCDN > with limited geographic scope > 2.2 uCDN with global geographic scope refers to a dCDN with limited > geographic scope >=20 > In none of the 2.x Use Cases do we define any capability limitations. > There seems to be an assumption that the delegate CDN can do anything > the uCDN can do. I certainly don't believe that is true as others have > noted below. There seems to be an intrinsic requirement to correlate > 'footprint' with a 'capability'. >=20 > Independently we define a set of Use Cases in Section 4.x and we don't > set conditions for the 'footprint'. >=20 > If we believe that the 'footprint' and 'capabilities' must now be > correlated, do we need to determine the order of dependency? >=20 > Example with Footprint Dependency: > Footprint A (AS_A or Prefix_A) > Capabilities 1 (HTTP DASH) > Capabilities 2 (HTTP HLS) > Capabilities 3 (HTTP HSS) > Footprint B (AS_B or Prefix_B) > Capabilities 2 (HTTP HLS) >=20 > Or do you use the reverse using Capability dependency as follows: >=20 > Capability 1 (HTTP DASH) > Footprint A (AS_A or Prefix_A) > Capability 2 (HTTP HLS) > Footprint A (AS_A or Prefix_A) > Footprint B (AS_B or Prefix_B) > Capability 3 (HTTP HSS) > Footprint A (AS_A or Prefix_A) >=20 > I suspect the capabilities will get a lot more complicated (URL Signing, > Delivery Protocol, Delegation Method (DNS-I, DNS-R, HTTP-I, HTTP-R). > Any thoughts on the appropriate order of dependency? >=20 > Scott >=20 > On 8/2/12 1:55 PM, Jan Seedorf wrote: > > Dear all, > > > > Here are my notes from yesterday's second footprint/capabilities design > team side meeting. The same disclaimer applies ("...probably have not > captured everything and admittedly the notes are rough in some cases"). > Thanks to everyone for taking the time and the (in my view) productive > discussion. > > > > - Jan > > > > > > -- CDNI Footprint Design team side meeting IETF-84 > > -- Wednesday, August 1st, 15:00-17:00 > > ************** > > -- start discussion by talking about capabilities first > > -- Jon: capabilities may only be valid for a partial footprint each > > -- Kevin: let's start with global capabilities first, and look later on > capabilities that are only valid for a partial footprint > > -- Yannick: two different types of capabilities, related to request > (e.g. protocol), related to CDN > > -- not clear what these two capabilities classes are, Yannick trying to > explain > > -- Yannick: classes of requests is first type of capability > > -- Kevin: on-net off-net is not a capability > > -- Gilles: capabilities are a functionality that I need to rely on > > -- Rich: when part of your CDN gets upgraded, you do not want to set up > a new contract > > -- Jan: do we all agree that there is kind of a generically valid > contract, and the interface we are taking about is for giving additional > update information with respect to such a contract? > > -- Jon: what things do we know that they are useful? > > -- Yannick: footprint and capabilities are tied together, does not make > sense to announce a capability, if you do not say along for which > footprint it is valid > > -- agreement on problem we are trying to solve --> provide additional > update information about capabilities that have changed/been added since > the contract > > -- agreement that footprint and capabilities are tied together --> give= n > capabilities may apply only to a certain sub-part of the dCDN footprint > > -- Yannick: no use in announcing a footprint without saying the > associated capabilities > > -- suggestion from Francois to base the discussion and way forward on > some key use cases we all agree on > > -- Jon: only on-net or only off-net use case are simple, the interestin= g > use case is where you have both mixed; Francois: this is the use case I a= m > proposing (mixed on-net and off-net) > > -- Yannick: default footprint is "everywhere"; Jon: new interesting ide= a > > -- agreement that we are talking about an interface that has the goal o= f > updating the uCDN about recent changes in capabilities > > -- Gilles: the tie-breaking information will be outside of the interfac= e > we are talking about (e.g. business) > > -- Francois: interface may provide "additional hints" for the uCDN > selection algorithm, let's rather call it that and not tie-breaker > > -- Rich: what does the uCDN have to have to find dCDN candidates is wha= t > is important > > -- Kevin: let's not define hints yet > > -- Jon: delivery protocol is mandatory, agreement on this > > -- Gilles: there is a difference between binary supported/non-supported > capabilities and value-range capabilities > > -- Kevin: support of metadata-bundles is mandatory capability > > -- Kevin: what about security parameters? > > -- Ray: what about CDNI features that are supported? (like DNS based > request routing); Jan: is that part of the control interface or part of > the request routing interface? > > -- Rich: still open issues regarding footprint > > -- agreement to focus on key use cases > > ************** > > _______________________________________________ > > 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 Mon Aug 6 09:13:07 2012 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 2D96821E8051 for ; Mon, 6 Aug 2012 09:13:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[AWL=-0.034, BAYES_00=-2.599] 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 V+xovC5T3Vwr for ; Mon, 6 Aug 2012 09:13:06 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.244]) by ietfa.amsl.com (Postfix) with ESMTP id 7B7C821E8044 for ; Mon, 6 Aug 2012 09:13:06 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 4F5E0A68B99; Mon, 6 Aug 2012 11:51:40 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB022.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 8E039A68B16; Mon, 6 Aug 2012 11:51:39 -0400 (EDT) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB022.mail.lan ([10.110.17.22]) with mapi; Mon, 6 Aug 2012 12:13:00 -0400 From: Kevin J Ma To: "Y. Richard Yang" , Ben Niven-Jenkins Date: Mon, 6 Aug 2012 12:13:04 -0400 Thread-Topic: [CDNi] comments on draft-lefaucheur-cdni-logging-delivery-01.txt Thread-Index: Ac1z7C3tWF687ZciQdKBUP3m80iV8wAAg8tA Message-ID: <291CC3F9E50E7641901A54E85D0977C65327070479@MAILR002.mail.lan> References: <5018BF8D.4040506@cs.yale.edu> <1A68A590-C06E-4A62-A213-503392AD9280@niven-jenkins.co.uk> <501FE95E.8060607@cs.yale.edu> In-Reply-To: <501FE95E.8060607@cs.yale.edu> 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] comments on draft-lefaucheur-cdni-logging-delivery-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: Mon, 06 Aug 2012 16:13:07 -0000 Hi Richard, > http://www.example.com/vod?vid=3D123456 Is it the CDN that is implementing this service, or the CSP? thanx. -- Kevin J. Ma > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Y= . > Richard Yang > Sent: Monday, August 06, 2012 11:57 AM > To: Ben Niven-Jenkins > Cc: cdni@ietf.org > Subject: Re: [CDNi] comments on draft-lefaucheur-cdni-logging-delivery- > 01.txt >=20 > Hi Ben, >=20 > On 8/6/12 5:10 AM, Ben Niven-Jenkins wrote: > > Richard, > > > > On 1 Aug 2012, at 06:33, Y. Richard Yang wrote: > > > >> Hi all, > >> > >> As suggested by Francois during the meeting today, here are some > comments on draft-lefaucheur-cdni-logging-delivery-01, on the Regular HTT= P > Log Fields (Sec. 2.2): > >> > >> - We may Client Port in addition to Client IP; > >> > >> - About request parameters encoded in message body. In particular, som= e > request parameters (URI, for example, for the purpose of hiding) may be > encoded in the message body of a POST message; > > I'm not convinced the dCDN should start trying to interpret & parse the > content type of message bodies to try to extract additional logging > parameters. > What I had in mind was to parse the content id. One way to indicate a > stream is > http://www.example.com/vod?vid=3D123456 >=20 > but I know CSPs who hide the vid in POST (not visible in browser) >=20 > Hence, the video id needs to be extracted from the message body. >=20 > Does this make sense to you? >=20 > Richard >=20 > > Ben > > > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From yry@cs.yale.edu Mon Aug 6 09:51:50 2012 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 B454A21F860B for ; Mon, 6 Aug 2012 09:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.359 X-Spam-Level: X-Spam-Status: No, score=-2.359 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599] 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 iGmeKWSPylHu for ; Mon, 6 Aug 2012 09:51:49 -0700 (PDT) Received: from vm-emlprdomr-02.its.yale.edu (vm-emlprdomr-02.its.yale.edu [130.132.50.143]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA5221F8568 for ; Mon, 6 Aug 2012 09:51:47 -0700 (PDT) Received: from Faculty-Supports-MacBook-Pro-2.local ([128.36.46.193]) (authenticated bits=0) by vm-emlprdomr-02.its.yale.edu (8.14.4/8.14.4) with ESMTP id q76Gphn1029552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 6 Aug 2012 12:51:43 -0400 Message-ID: <501FF61E.4020107@cs.yale.edu> Date: Mon, 06 Aug 2012 09:51:42 -0700 From: "Y. Richard Yang" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Kevin J Ma References: <5018BF8D.4040506@cs.yale.edu> <1A68A590-C06E-4A62-A213-503392AD9280@niven-jenkins.co.uk> <501FE95E.8060607@cs.yale.edu> <291CC3F9E50E7641901A54E85D0977C65327070479@MAILR002.mail.lan> In-Reply-To: <291CC3F9E50E7641901A54E85D0977C65327070479@MAILR002.mail.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.71 on 130.132.50.143 Cc: "cdni@ietf.org" Subject: Re: [CDNi] comments on draft-lefaucheur-cdni-logging-delivery-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: Mon, 06 Aug 2012 16:51:50 -0000 Hi Kevin, On 8/6/12 9:13 AM, Kevin J Ma wrote: > Hi Richard, > >> http://www.example.com/vod?vid=123456 The setting is that www.example.com points to uCDN.com who then directs to dCDN.com. A setting is that the vid is encoded in a hidden field of a form on a web page. The CDN(s) must parse the message body to extract the vid field. Hence, it is a service that is provided by the CDN (parse the body) by working together with the CSP (use a form). Thanks. Richard > Is it the CDN that is implementing this service, or the CSP? > > thanx. > > -- Kevin J. Ma > >> -----Original Message----- >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Y. >> Richard Yang >> Sent: Monday, August 06, 2012 11:57 AM >> To: Ben Niven-Jenkins >> Cc: cdni@ietf.org >> Subject: Re: [CDNi] comments on draft-lefaucheur-cdni-logging-delivery- >> 01.txt >> >> Hi Ben, >> >> On 8/6/12 5:10 AM, Ben Niven-Jenkins wrote: >>> Richard, >>> >>> On 1 Aug 2012, at 06:33, Y. Richard Yang wrote: >>> >>>> Hi all, >>>> >>>> As suggested by Francois during the meeting today, here are some >> comments on draft-lefaucheur-cdni-logging-delivery-01, on the Regular HTTP >> Log Fields (Sec. 2.2): >>>> - We may Client Port in addition to Client IP; >>>> >>>> - About request parameters encoded in message body. In particular, some >> request parameters (URI, for example, for the purpose of hiding) may be >> encoded in the message body of a POST message; >>> I'm not convinced the dCDN should start trying to interpret & parse the >> content type of message bodies to try to extract additional logging >> parameters. >> What I had in mind was to parse the content id. One way to indicate a >> stream is >> http://www.example.com/vod?vid=123456 >> >> but I know CSPs who hide the vid in POST (not visible in browser) >> >> Hence, the video id needs to be extracted from the message body. >> >> Does this make sense to you? >> >> Richard >> >>> Ben >>> >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni From kevin.ma@azukisystems.com Mon Aug 6 10:08:03 2012 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 4064A21F858F for ; Mon, 6 Aug 2012 10:08:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.631 X-Spam-Level: X-Spam-Status: No, score=-2.631 tagged_above=-999 required=5 tests=[AWL=-0.032, BAYES_00=-2.599] 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 gbzao5cPJ4Fj for ; Mon, 6 Aug 2012 10:08:02 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.244]) by ietfa.amsl.com (Postfix) with ESMTP id 4F4BE21F856D for ; Mon, 6 Aug 2012 10:08:02 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id D39E4554F0B; Mon, 6 Aug 2012 13:08:01 -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 EBD7A554F3C; Mon, 6 Aug 2012 13:08:00 -0400 (EDT) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB012.mail.lan ([10.110.17.12]) with mapi; Mon, 6 Aug 2012 13:07:43 -0400 From: Kevin J Ma To: "Y. Richard Yang" Date: Mon, 6 Aug 2012 13:08:00 -0400 Thread-Topic: [CDNi] comments on draft-lefaucheur-cdni-logging-delivery-01.txt Thread-Index: Ac1z88P+Y4B92HeiRl6UEwLtz6qOogAAWqnQ Message-ID: <291CC3F9E50E7641901A54E85D0977C653270704AD@MAILR002.mail.lan> References: <5018BF8D.4040506@cs.yale.edu> <1A68A590-C06E-4A62-A213-503392AD9280@niven-jenkins.co.uk> <501FE95E.8060607@cs.yale.edu> <291CC3F9E50E7641901A54E85D0977C65327070479@MAILR002.mail.lan> <501FF61E.4020107@cs.yale.edu> In-Reply-To: <501FF61E.4020107@cs.yale.edu> 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] comments on draft-lefaucheur-cdni-logging-delivery-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: Mon, 06 Aug 2012 17:08:03 -0000 Hi Richard, So assuming the CSP and the CDN have some agreement that the CDN is going to provide this translation service, wouldn't the translation result in some kind of actual content URI? It would seem that the translation coul= d be abstracted from the content delivery and the actual content URI could be used for the rest of the delivery processing? thanx. -- Kevin J. Ma > -----Original Message----- > From: Y. Richard Yang [mailto:yry@cs.yale.edu] > Sent: Monday, August 06, 2012 12:52 PM > To: Kevin J Ma > Cc: Y. Richard Yang; Ben Niven-Jenkins; cdni@ietf.org > Subject: Re: [CDNi] comments on draft-lefaucheur-cdni-logging-delivery- > 01.txt >=20 > Hi Kevin, >=20 > On 8/6/12 9:13 AM, Kevin J Ma wrote: > > Hi Richard, > > > >> http://www.example.com/vod?vid=3D123456 > The setting is that www.example.com points to uCDN.com who then directs > to dCDN.com. A setting is that the vid is encoded in a hidden field of a > form on a web page. The CDN(s) must parse the message body to extract > the vid field. Hence, it is a service that is provided by the CDN (parse > the body) by working together with the CSP (use a form). >=20 > Thanks. >=20 > Richard > > Is it the CDN that is implementing this service, or the CSP? > > > > thanx. > > > > -- Kevin J. Ma > > > >> -----Original Message----- > >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf O= f > Y. > >> Richard Yang > >> Sent: Monday, August 06, 2012 11:57 AM > >> To: Ben Niven-Jenkins > >> Cc: cdni@ietf.org > >> Subject: Re: [CDNi] comments on draft-lefaucheur-cdni-logging-delivery= - > >> 01.txt > >> > >> Hi Ben, > >> > >> On 8/6/12 5:10 AM, Ben Niven-Jenkins wrote: > >>> Richard, > >>> > >>> On 1 Aug 2012, at 06:33, Y. Richard Yang wrote: > >>> > >>>> Hi all, > >>>> > >>>> As suggested by Francois during the meeting today, here are some > >> comments on draft-lefaucheur-cdni-logging-delivery-01, on the Regular > HTTP > >> Log Fields (Sec. 2.2): > >>>> - We may Client Port in addition to Client IP; > >>>> > >>>> - About request parameters encoded in message body. In particular, > some > >> request parameters (URI, for example, for the purpose of hiding) may b= e > >> encoded in the message body of a POST message; > >>> I'm not convinced the dCDN should start trying to interpret & parse > the > >> content type of message bodies to try to extract additional logging > >> parameters. > >> What I had in mind was to parse the content id. One way to indicate a > >> stream is > >> http://www.example.com/vod?vid=3D123456 > >> > >> but I know CSPs who hide the vid in POST (not visible in browser) > >> > >> Hence, the video id needs to be extracted from the message body. > >> > >> Does this make sense to you? > >> > >> Richard > >> > >>> Ben > >>> > >> _______________________________________________ > >> CDNi mailing list > >> CDNi@ietf.org > >> https://www.ietf.org/mailman/listinfo/cdni From yry@cs.yale.edu Mon Aug 6 11:13:13 2012 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 F01BA11E80D2 for ; Mon, 6 Aug 2012 11:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.199, 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 n6pINulPwQwr for ; Mon, 6 Aug 2012 11:13:12 -0700 (PDT) Received: from vm-emlprdomr-06.its.yale.edu (vm-emlprdomr-06.its.yale.edu [130.132.50.147]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE2611E80D1 for ; Mon, 6 Aug 2012 11:13:12 -0700 (PDT) Received: from Faculty-Supports-MacBook-Pro-2.local ([128.36.46.193]) (authenticated bits=0) by vm-emlprdomr-06.its.yale.edu (8.14.4/8.14.4) with ESMTP id q76ID2Gp029934 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 6 Aug 2012 14:13:03 -0400 Message-ID: <5020092E.4050105@cs.yale.edu> Date: Mon, 06 Aug 2012 11:13:02 -0700 From: "Y. Richard Yang" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Kevin J Ma References: <5018BF8D.4040506@cs.yale.edu> <1A68A590-C06E-4A62-A213-503392AD9280@niven-jenkins.co.uk> <501FE95E.8060607@cs.yale.edu> <291CC3F9E50E7641901A54E85D0977C65327070479@MAILR002.mail.lan> <501FF61E.4020107@cs.yale.edu> <291CC3F9E50E7641901A54E85D0977C653270704AD@MAILR002.mail.lan> In-Reply-To: <291CC3F9E50E7641901A54E85D0977C653270704AD@MAILR002.mail.lan> Content-Type: multipart/alternative; boundary="------------000404030101050801040505" X-Scanned-By: MIMEDefang 2.71 on 130.132.50.147 Cc: "cdni@ietf.org" Subject: Re: [CDNi] comments on draft-lefaucheur-cdni-logging-delivery-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: Mon, 06 Aug 2012 18:13:14 -0000 This is a multi-part message in MIME format. --------------000404030101050801040505 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Kevin, You may consider that there is a translation process. Consider this example:
...
The URI may be logged as only /vod, and the active page will need to parse the standard input (STDIN) to parse the vid. The fix is that the log format should define the "semantics" one (i.e., including the video id), instead of the only /vod URI, without indicating the video id. Does this make sense to you? Thanks! Richard On 8/6/12 10:08 AM, Kevin J Ma wrote: > Hi Richard, > > So assuming the CSP and the CDN have some agreement that the CDN is going > to provide this translation service, wouldn't the translation result in > some kind of actual content URI? It would seem that the translation could > be abstracted from the content delivery and the actual content URI could > be used for the rest of the delivery processing? > > thanx. > > -- Kevin J. Ma > >> -----Original Message----- >> From: Y. Richard Yang [mailto:yry@cs.yale.edu] >> Sent: Monday, August 06, 2012 12:52 PM >> To: Kevin J Ma >> Cc: Y. Richard Yang; Ben Niven-Jenkins; cdni@ietf.org >> Subject: Re: [CDNi] comments on draft-lefaucheur-cdni-logging-delivery- >> 01.txt >> >> Hi Kevin, >> >> On 8/6/12 9:13 AM, Kevin J Ma wrote: >>> Hi Richard, >>> >>>> http://www.example.com/vod?vid=123456 >> The setting is that www.example.com points to uCDN.com who then directs >> to dCDN.com. A setting is that the vid is encoded in a hidden field of a >> form on a web page. The CDN(s) must parse the message body to extract >> the vid field. Hence, it is a service that is provided by the CDN (parse >> the body) by working together with the CSP (use a form). >> >> Thanks. >> >> Richard >>> Is it the CDN that is implementing this service, or the CSP? >>> >>> thanx. >>> >>> -- Kevin J. Ma >>> >>>> -----Original Message----- >>>> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of >> Y. >>>> Richard Yang >>>> Sent: Monday, August 06, 2012 11:57 AM >>>> To: Ben Niven-Jenkins >>>> Cc: cdni@ietf.org >>>> Subject: Re: [CDNi] comments on draft-lefaucheur-cdni-logging-delivery- >>>> 01.txt >>>> >>>> Hi Ben, >>>> >>>> On 8/6/12 5:10 AM, Ben Niven-Jenkins wrote: >>>>> Richard, >>>>> >>>>> On 1 Aug 2012, at 06:33, Y. Richard Yang wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> As suggested by Francois during the meeting today, here are some >>>> comments on draft-lefaucheur-cdni-logging-delivery-01, on the Regular >> HTTP >>>> Log Fields (Sec. 2.2): >>>>>> - We may Client Port in addition to Client IP; >>>>>> >>>>>> - About request parameters encoded in message body. In particular, >> some >>>> request parameters (URI, for example, for the purpose of hiding) may be >>>> encoded in the message body of a POST message; >>>>> I'm not convinced the dCDN should start trying to interpret & parse >> the >>>> content type of message bodies to try to extract additional logging >>>> parameters. >>>> What I had in mind was to parse the content id. One way to indicate a >>>> stream is >>>> http://www.example.com/vod?vid=123456 >>>> >>>> but I know CSPs who hide the vid in POST (not visible in browser) >>>> >>>> Hence, the video id needs to be extracted from the message body. >>>> >>>> Does this make sense to you? >>>> >>>> Richard >>>> >>>>> Ben >>>>> >>>> _______________________________________________ >>>> CDNi mailing list >>>> CDNi@ietf.org >>>> https://www.ietf.org/mailman/listinfo/cdni --------------000404030101050801040505 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Kevin,

You may consider that there is a translation process. Consider this example:
<HTML>
 <BODY>
  <FORM METHOD="POST" ACTION="/vod">
...
   <INPUT TYPE="hidden" NAME="vid" VALUE="123456">
  </FORM>
 </BODY>
</HTML>

The URI may be logged as only /vod, and the active page will need to parse the standard input (STDIN) to parse the vid. The fix is that the log format should define the "semantics" one (i.e., including the video id), instead of the only /vod URI, without indicating the video id. Does this make sense to you?

Thanks!

Richard

On 8/6/12 10:08 AM, Kevin J Ma wrote:
Hi Richard,

  So assuming the CSP and the CDN have some agreement that the CDN is going
  to provide this translation service, wouldn't the translation result in
  some kind of actual content URI?  It would seem that the translation could
  be abstracted from the content delivery and the actual content URI could
  be used for the rest of the delivery processing?

thanx.

--  Kevin J. Ma


-----Original Message-----
From: Y. Richard Yang [mailto:yry@cs.yale.edu]
Sent: Monday, August 06, 2012 12:52 PM
To: Kevin J Ma
Cc: Y. Richard Yang; Ben Niven-Jenkins; cdni@ietf.org
Subject: Re: [CDNi] comments on draft-lefaucheur-cdni-logging-delivery-
01.txt

Hi Kevin,

On 8/6/12 9:13 AM, Kevin J Ma wrote:

Hi Richard,


http://www.example.com/vod?vid=123456

The setting is that www.example.com points to uCDN.com who then directs
to dCDN.com. A setting is that the vid is encoded in a hidden field of a
form on a web page. The CDN(s) must parse the message body to extract
the vid field. Hence, it is a service that is provided by the CDN (parse
the body) by working together with the CSP (use a form).

Thanks.

Richard

Is it the CDN that is implementing this service, or the CSP?

thanx.

--  Kevin J. Ma


-----Original Message-----
From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of

Y.

Richard Yang
Sent: Monday, August 06, 2012 11:57 AM
To: Ben Niven-Jenkins
Cc: cdni@ietf.org
Subject: Re: [CDNi] comments on draft-lefaucheur-cdni-logging-delivery-
01.txt

Hi Ben,

On 8/6/12 5:10 AM, Ben Niven-Jenkins wrote:

Richard,

On 1 Aug 2012, at 06:33, Y. Richard Yang wrote:


Hi all,

As suggested by Francois during the meeting today, here are some

comments on draft-lefaucheur-cdni-logging-delivery-01, on the Regular

HTTP

Log Fields (Sec. 2.2):

- We may Client Port in addition to Client IP;

- About request parameters encoded in message body. In particular,

some

request parameters (URI, for example, for the purpose of hiding) may be
encoded in the message body of a POST message;

I'm not convinced the dCDN should start trying to interpret & parse

the

content type of message bodies to try to extract additional logging
parameters.
What I had in mind was to parse the content id. One way to indicate a
stream is
http://www.example.com/vod?vid=123456

but I know CSPs who hide the vid in POST (not visible in browser)

Hence, the video id needs to be extracted from the message body.

Does this make sense to you?

Richard


Ben


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


    

    

  


--------------000404030101050801040505--

From internet-drafts@ietf.org  Thu Aug  9 08:07:44 2012
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 9C31421F8799; Thu,  9 Aug 2012 08:07:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.551
X-Spam-Level: 
X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, 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 79680qDOOYjz; Thu,  9 Aug 2012 08:07:43 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DF5221F8794; Thu,  9 Aug 2012 08:07:43 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.33
Message-ID: <20120809150743.31126.24678.idtracker@ietfa.amsl.com>
Date: Thu, 09 Aug 2012 08:07:43 -0700
Cc: cdni@ietf.org
Subject: [CDNi] I-D Action: draft-ietf-cdni-use-cases-10.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: Thu, 09 Aug 2012 15:07:45 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the Content Delivery Networks Interconnection=
 Working Group of the IETF.

	Title           : Use Cases for Content Delivery Network Interconnection
	Author(s)       : Gilles Bertrand
                          Stephan Emile
                          Trevor Burbridge
                          Philip Eardley
                          Kevin J. Ma
                          Grant Watson
	Filename        : draft-ietf-cdni-use-cases-10.txt
	Pages           : 17
	Date            : 2012-08-09

Abstract:
   Content Delivery Networks (CDNs) are commonly used for improving the
   End User experience of a content delivery service while keeping cost
   at a reasonable level.  This document focuses on use cases that
   correspond to identified industry needs and that are expected to be
   realized once open interfaces and protocols supporting
   interconnection of CDNs are specified and implemented.  The document
   can be used to motivate the definition of the requirements to be
   supported by CDN Interconnection (CDNI) interfaces.  It obsoletes RFC
   3570.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-cdni-use-cases

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-cdni-use-cases-10

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-use-cases-10


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From ggolovinsky@qualys.com  Thu Aug  9 08:53:26 2012
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 21E5C21F8793 for ; Thu,  9 Aug 2012 08:53:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level: 
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 uyGBuoi8org6 for ; Thu,  9 Aug 2012 08:53:25 -0700 (PDT)
Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7B29A21F8771 for ; Thu,  9 Aug 2012 08:53:22 -0700 (PDT)
Received: by qcac10 with SMTP id c10so428829qca.31 for ; Thu, 09 Aug 2012 08:53:21 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:mime-version:x-mailer:thread-index:date:message-id:subject:to :content-type:x-gm-message-state; bh=eMpJil85KQWOnp2E/feOPwsGB8Fu5SII6jKqiCMCrIU=; b=hV1WfDbKf4k2axLf9MItd/5w01RasS697dExyOmp5b6myvfexemJ8Flu7IMB7N/+5V +B4rHSV89zug4lbNnN/jF+EOcINdRRN7dVIpNeEwSRX7+YxQdHaOu9cbxic36lvGz/lk T1ogc6PRdoycScNJpEIR6m98MdA40Vtrn8aBfic5RiYkBpd3VKUzKr/LY+6GN3Mg2AE/ iAhIof8LhgXpIayirIV2aTu2jFFpA4qFIUbvY6wdTPFMEdBH+MgeXd4AiuVWVKcgWwhj +l9ORUNzikSSsclX2ikTp+aTSU11sCmniMXrI2m1ueFuTFyxDgRNFdy35V55YS7HC495 SyQA==
Received: by 10.229.135.76 with SMTP id m12mr11283788qct.68.1344527601762; Thu, 09 Aug 2012 08:53:21 -0700 (PDT)
From: Gene Golovinsky 
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Ac12Q385Nf5fKufDSlOno6LH5/6UXg==
Date: Thu, 9 Aug 2012 08:53:21 -0700
Message-ID: <55172eaa644770550044a2e84fb380a5@mail.gmail.com>
To: cdni@ietf.org
Content-Type: multipart/alternative; boundary=00248c6a667e18019f04c6d73af9
X-Gm-Message-State: ALoCoQmzKE5ZJDF67qWd238afF8oL5vtBp+XwASWc23Y3qrUDdKM7lPBROuFIibFa0d3u6uP7Lks
Subject: [CDNi] comments/questions - draft-lefaucheur-cdni-logging-delivery-01
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, 09 Aug 2012 15:53:26 -0000

--00248c6a667e18019f04c6d73af9
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

   comments/questions - draft-lefaucheur-cdni-logging-delivery-01

Hi Francois.

As we discussed during last week IETF meeting here some comments on the
draft.

My general understanding is that not only humans, but also various tools
should be able to take advantage of these logs.

Assuming that this is the case=85

1.      Content and format of the header:

a.      The format of the version field probably needs to be defined; at
the moment the example looks like free flowing ASCII =93v1.0=94. This is no=
t
easy to parse for a tool

b.      What does unique Log-ID mean? And unique within scope of what?

c.      Time stamp format. Can we use RFC 5424, section 6.2.3 timestamp
definition

d.      I would also suggest to have a length of the log record in the
header. It makes parsing a bit easier and also provides additional protecti=
on
against misreading the end of the log record

2.      This may be a controversial question, but why would not we use
Syslog (RFC 5424) for logging? It provides plenty of extensibility
through STRUCTURED-DATA
(SD-ID, SD-ELEMENT, SD-PARAM) and ways to branch out into enterprise
specific needs. It will take care of many topics related to header such as
ID, timestamps, source identifier.

Cheers.

--Gene

--00248c6a667e18019f04c6d73af9
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable






comments/questions - draft-lefaucheur-cdni-logging-delivery-01</titl=
e>
</head>
<body>


<p dir=3D"LTR"><span lang=3D"en-us"><font face=3D"Calibri">Hi Francois.</fo=
nt></span></p>

<p dir=3D"LTR"><span lang=3D"en-us"><font face=3D"Calibri">As we discussed =
during last week IETF</font></span><span lang=3D"en-us"> <font face=3D"Cali=
bri">meeting</font></span><span lang=3D"en-us"><font face=3D"Calibri"></fon=
t></span><span lang=3D"en-us"> <font face=3D"Calibri">here some comments on=
 the draft.</font></span><span lang=3D"en-us"></span></p>


<p dir=3D"LTR"><span lang=3D"en-us"><font face=3D"Calibri">My general</font=
></span><span lang=3D"en-us"> <font face=3D"Calibri">understanding</font></=
span><span lang=3D"en-us"><font face=3D"Calibri"> is that not only humans, =
but also various tools should be able to take advantage of these logs.</fon=
t></span></p>


<p dir=3D"LTR"><span lang=3D"en-us"><font face=3D"Calibri">Assuming that th=
is is the case=85</font></span><span lang=3D"en-us"></span></p>

<p dir=3D"LTR"><span lang=3D"en-us"><font face=3D"Calibri">1.=A0=A0=A0=A0=
=A0</font></span><span lang=3D"en-us"></span><span lang=3D"en-us"></span><s=
pan lang=3D"en-us"> <font face=3D"Calibri">Content and format of the header=
</font></span><span lang=3D"en-us"><font face=3D"Calibri">:</font></span></=
p>


<p dir=3D"LTR"><span lang=3D"en-us"><font face=3D"Calibri">a.=A0=A0=A0=A0=
=A0</font></span><span lang=3D"en-us"></span><span lang=3D"en-us"> <font fa=
ce=3D"Calibri">The format of the version fi</font></span><span lang=3D"en-u=
s"><font face=3D"Calibri">eld</font></span><span lang=3D"en-us"><font face=
=3D"Calibri"> probably need</font></span><span lang=3D"en-us"><font face=3D=
"Calibri">s to be defined; at the moment the example looks like free flowin=
g ASCII</font></span><span lang=3D"en-us"> <font face=3D"Calibri">=93v1.0=
=94. This is not easy to parse for a tool</font></span></p>


<p dir=3D"LTR"><span lang=3D"en-us"><font face=3D"Calibri">b.=A0=A0=A0=A0=
=A0</font> <font face=3D"Calibri">What does unique Log-ID mean? And</font><=
/span><span lang=3D"en-us"> <font face=3D"Calibri">unique</font></span><spa=
n lang=3D"en-us"><font face=3D"Calibri"></font></span><span lang=3D"en-us">=
 <font face=3D"Calibri">within scope of what?</font></span></p>


<p dir=3D"LTR"><span lang=3D"en-us"><font face=3D"Calibri">c.=A0=A0=A0=A0=
=A0</font> <font face=3D"Calibri">Time stamp format.</font></span><span lan=
g=3D"en-us"> <font face=3D"Calibri">Can we use RFC 5424, section 6.2.3 time=
stamp definition</font></span><span lang=3D"en-us"></span></p>


<p dir=3D"LTR"><span lang=3D"en-us"><font face=3D"Calibri">d.=A0=A0=A0=A0=
=A0</font></span><span lang=3D"en-us"> <font face=3D"Calibri">I would also =
suggest to have a length of the log record in the header. It makes parsing =
a bit easier and also provides</font></span><span lang=3D"en-us"> <font fac=
e=3D"Calibri">additional</font></span><span lang=3D"en-us"><font face=3D"Ca=
libri"></font></span><span lang=3D"en-us"> <font face=3D"Calibri">protectio=
n against misreading the end of the log record</font></span></p>


<p dir=3D"LTR"><span lang=3D"en-us"><font face=3D"Calibri">2.=A0=A0=A0=A0=
=A0</font></span><span lang=3D"en-us"> <font face=3D"Calibri">This may be a=
</font></span><span lang=3D"en-us"> <font face=3D"Calibri">controversial</f=
ont></span><span lang=3D"en-us"><font face=3D"Calibri"> question</font></sp=
an><span lang=3D"en-us"><font face=3D"Calibri">, but why would not we use S=
yslog (RFC 5424) for</font></span><span lang=3D"en-us"> <font face=3D"Calib=
ri">logging</font></span><span lang=3D"en-us"><font face=3D"Calibri">? It p=
rovides plenty of extensibility through</font></span><span lang=3D"en-us"> =
<font face=3D"Calibri">STRUCTURED-DATA (SD-ID, SD-ELEMENT, SD-PARAM) and wa=
ys to branch out into enterprise</font></span><span lang=3D"en-us"> <font f=
ace=3D"Calibri">specific</font></span><span lang=3D"en-us"><font face=3D"Ca=
libri"></font></span><span lang=3D"en-us"> <font face=3D"Calibri">needs. It=
 will take care of many topics related to header</font></span><span lang=3D=
"en-us"> <font face=3D"Calibri">such as ID,</font></span><span lang=3D"en-u=
s"> <font face=3D"Calibri">timestamps</font></span><span lang=3D"en-us"><fo=
nt face=3D"Calibri">,</font></span><span lang=3D"en-us"> <font face=3D"Cali=
bri">source identifier.</font></span></p>


<p dir=3D"LTR"><span lang=3D"en-us"></span><span lang=3D"en-us"></span></p>

<p dir=3D"LTR"><span lang=3D"en-us"><font face=3D"Calibri">Cheers.</font></=
span></p>

<p dir=3D"LTR"><span lang=3D"en-us"><font face=3D"Calibri">--Gene</font></s=
pan></p>

<p dir=3D"LTR"><span lang=3D"en-us"></span></p>

<p dir=3D"LTR"><span lang=3D"en-us"></span></p>

<p dir=3D"LTR"><span lang=3D"en-us"></span></p>

</body>
</html>

--00248c6a667e18019f04c6d73af9--

From flefauch@cisco.com  Fri Aug 10 01:59:31 2012
Return-Path: <flefauch@cisco.com>
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 AEDF621F85CC for <cdni@ietfa.amsl.com>; Fri, 10 Aug 2012 01:59:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.549
X-Spam-Level: 
X-Spam-Status: No, score=-10.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, 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 S7bfbbQlZxLj for <cdni@ietfa.amsl.com>; Fri, 10 Aug 2012 01:59:31 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 208E221F856D for <cdni@ietf.org>; Fri, 10 Aug 2012 01:59:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=399; q=dns/txt; s=iport; t=1344589171; x=1345798771; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=2COtqVG0buG8KW9UjWVIuN2qVY5bBec7mOPI6C2aLTI=; b=ZDIT/sXFg1g/a6eYdFZ5RQZzBAXUB7Emx3+epdlZwr0IEKrUWFIvxLcP CL1cjo1ScHk3OOSw328GCeOe4+wjccthJI9npwvoB4DmBafsBUq1g3gTL p+lcpSflnnUu59kFiMrwj8l5DlX81RjqHE9AUH2YnTVDq03Spkd/1see6 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ag0FAIzgI1CtJXHA/2dsb2JhbABFhTq0KIEHgicSASdRAT5CJwQcGYdrC5lTgSigbZETYAOVSY4pgWaCXw
X-IronPort-AV: E=Sophos;i="4.77,744,1336348800"; d="scan'208";a="110281558"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-4.cisco.com with ESMTP; 10 Aug 2012 08:59:30 +0000
Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q7A8xUC7028112 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <cdni@ietf.org>; Fri, 10 Aug 2012 08:59:30 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.216]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0298.004; Fri, 10 Aug 2012 03:59:30 -0500
From: "Francois Le Faucheur (flefauch)" <flefauch@cisco.com>
To: "cdni@ietf.org" <cdni@ietf.org>
Thread-Topic: IETF-84 CDNI draft Minutes posted
Thread-Index: AQHNdtZznz0A5Ir5tUmZUwd5c8NqXQ==
Date: Fri, 10 Aug 2012 08:59:30 +0000
Message-ID: <B7DE3DD0-C8FB-4974-B4D2-2CC1B702A094@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [144.254.53.127]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19098.003
x-tm-as-result: No--22.503800-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="us-ascii"
Content-ID: <190494D127D37145B1D8A711B2F0A6E2@cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [CDNi] IETF-84 CDNI draft Minutes posted
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\)" <cdni.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cdni>, <mailto:cdni-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/cdni>
List-Post: <mailto:cdni@ietf.org>
List-Help: <mailto:cdni-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cdni>, <mailto:cdni-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Aug 2012 08:59:31 -0000

Hi,

The draft minutes of our CDNI WG meetings during IETF-84 have been posted:=
=20
http://www.ietf.org/proceedings/84/minutes/minutes-84-cdni
Please send your comments/corrections as needed.

Thanks again to our scribe Gilles for taking notes during the meeting.

The complete audio recording of the two sessions are available from:
http://www.ietf.org/audio/ietf84/

Francois & Rich

From flefauch@cisco.com  Fri Aug 10 02:57:25 2012
Return-Path: <flefauch@cisco.com>
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 EDBC121F85FC for <cdni@ietfa.amsl.com>; Fri, 10 Aug 2012 02:57:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.556
X-Spam-Level: 
X-Spam-Status: No, score=-10.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, 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 BBH3TpDZ9BBb for <cdni@ietfa.amsl.com>; Fri, 10 Aug 2012 02:57:25 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id DE25721F84EA for <cdni@ietf.org>; Fri, 10 Aug 2012 02:57:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=5189; q=dns/txt; s=iport; t=1344592645; x=1345802245; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=l1Fo/OfO+WtdsyFlRessagEXhzWP39h6/Gz7CRzYHmQ=; b=eDO8bsOcclhCxOf4IO2y+hxdtDuHLx0in2fr9EpfhDvIAWcGtE3J8RyD /h28tGw6HtY+yYWEjr9MZsRN6dA+wwVygk0DHinR+EX4w0SSQP/0fQzvQ omuEYLHgK/j+c5QJeWkEwKYTNmFR/RsxK1cjhNB1CTY3uzva7WK7qwitE k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAIzgI1CtJXHA/2dsb2JhbABFuWKBB4IgAQEBAwEBAQEPASc0EAsCARkDAQIfECcLFAkIAgQTCRIHh2UGC5p7oG2LDxWFb2ADlUmBFIl5gxyBZoJfgVc
X-IronPort-AV: E=Sophos;i="4.77,744,1336348800"; d="scan'208";a="110274974"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-8.cisco.com with ESMTP; 10 Aug 2012 09:57:24 +0000
Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q7A9vNOr006494 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <cdni@ietf.org>; Fri, 10 Aug 2012 09:57:24 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.216]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0298.004; Fri, 10 Aug 2012 04:57:23 -0500
From: "Francois Le Faucheur (flefauch)" <flefauch@cisco.com>
To: "<cdni@ietf.org>" <cdni@ietf.org>
Thread-Topic: Vancouver decisions on CDNI and HTTP Adaptive Bitrate Streaming
Thread-Index: AQHNdt6Jgy4gh5LKfUeCCmq3ZbejTg==
Date: Fri, 10 Aug 2012 09:57:22 +0000
Message-ID: <47324E59-83EB-4904-A33A-0DA8306DE613@cisco.com>
References: <20120713124933.24842.61000.idtracker@ietfa.amsl.com> <14907C1F-86BA-48D9-BB58-3157B42CF01B@cisco.com>
In-Reply-To: <14907C1F-86BA-48D9-BB58-3157B42CF01B@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [144.254.53.127]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19098.003
x-tm-as-result: No--39.730700-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="us-ascii"
Content-ID: <04F5910D8C0C344AB188EE754B11AD6A@cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [CDNi] Vancouver decisions on CDNI and HTTP Adaptive Bitrate Streaming
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\)" <cdni.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cdni>, <mailto:cdni-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/cdni>
List-Post: <mailto:cdni@ietf.org>
List-Help: <mailto:cdni-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cdni>, <mailto:cdni-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Aug 2012 09:57:26 -0000

Folks,

As documented in the draft minutes of the Vancouver CDNI meeting, based on =
the corresponding "Hum test", we have established a tentative WG decision t=
o move ahead along the recommendations detailed in draft-brandenburg-cdni-h=
as-03.txt. This decision will be considered final unless we hear substantia=
ted arguments against it on the list by the end of the month.

Cheers

Francois & Rich


On 23 Jul 2012, at 13:14, Francois Le Faucheur wrote:

> Folks,
>=20
> In line with the approach agreed in Paris, a lot of work has gone since i=
nto analysing the options for how the different CDNI interfaces could/shoul=
d handle HTTP Adaptive Bitrate Streaming (HAS) and in documenting this anal=
ysis as well as recommendations to facilitate WG decisions. This includes t=
he work of the extended design team that held three virtual meetings since =
Paris, as well as the work from Ray (and co-authors) in revving up draft-br=
andenburg-cdni-has multiple times accordingly.
>=20
> Our objective for Vancouver is to reach tentative agreement on how the di=
fferent CDNI interfaces are to handle HAS. To maximise our chances of succe=
ss, we'd like to request that people who want to contribute into that discu=
ssion do read draft-brandenburg-cdni-has-03 before Vancouver, and engage in=
to as much clarification/discussion as possible on the list before Vancouve=
r.
>=20
> In Vancouver, Ray and co-authors will give a brief recap of the options, =
their pros-and-cons and of the recommendations, in order to try bring every=
one up to speed. But it is a complex topic, with a lot of subtle ramificati=
ons, and we feel the only way to have a constructive discussion in a constr=
ain timeslot is if everyone shares a similar base level of terminology/unde=
rstanding. This is why we request that people be familar with the latest ve=
rsion of draft-brandenburg-cdni-has (ie -03).
>=20
> Note that for each of the dimensions analysed in draft-brandenburg-cdni-h=
as, there is a subsection highlighing the recommendations for that dimensio=
n (specifically sections 3.1.3, 3.2.3, 3.3.3 , 3.4.3 and 3.5.9).
>=20
> In the context of that discussion, I would also like everyone to keep in =
mind the following statement from our charter:
> "
> The CDNI WG aims at delivering a targeted, deployable solution in a short=
 timeframe (18-24 months) as needed by the industry.
> "
> and the related guiding principle followed by the extended design team:
> "
> we have a strong motivation to develop first what is REQUIRED to make HAS=
 work. We need to focus on fundamentals to make HAS work vs how to use CDN-=
I to make things work better.
> "
>=20
> Remember also that, once it has delivered a first set of CDNI interfaces,=
 it is possible for the CDNI WG to propose to recharter in order to develop=
 extensions for more advanced functionality. So the HAS decisions that the =
WG will make now only conditions what is to be included in the deliverables=
 against the initial charter, it does not limit what might be supported by =
CDNI interfaces in the future.
>=20
> Looking forward to discussing CDNI support for HAS in Vancouver or on the=
 list before.
>=20
> Cheers
>=20
> Francois & Rich
>=20
>=20
> Begin forwarded message:
>=20
>> From: <internet-drafts@ietf.org>
>> Subject: I-D Action: draft-brandenburg-cdni-has-03.txt
>> Date: 13 July 2012 14:49:33 CEST
>> To: <i-d-announce@ietf.org>
>> Reply-To: <internet-drafts@ietf.org>
>>=20
>>=20
>> A New Internet-Draft is available from the on-line Internet-Drafts direc=
tories.
>>=20
>>=20
>> 	Title           : Models for adaptive-streaming-aware CDN Interconnecti=
on
>> 	Author(s)       : Ray van Brandenburg
>>                         Oskar van Deventer
>>                         Francois Le Faucheur
>>                         Kent Leung
>> 	Filename        : draft-brandenburg-cdni-has-03.txt
>> 	Pages           : 43
>> 	Date            : 2012-07-13
>>=20
>> Abstract:
>>  This documents presents thoughts on the potential impact of
>>  supporting HTTP Adaptive Streaming technologies in CDN
>>  Interconnection scenarios.  Our intent is to spur discussion on how
>>  the different CDNI interfaces could, and should, deal with content
>>  delivered using adaptive streaming technologies and to facilitate
>>  working group decisions.
>>=20
>>=20
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-brandenburg-cdni-has
>>=20
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-brandenburg-cdni-has-03
>>=20
>> A diff from previous version is available at:
>> http://tools.ietf.org/rfcdiff?url2=3Ddraft-brandenburg-cdni-has-03
>>=20
>>=20
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>=20
>> _______________________________________________
>> 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
>=20


From RMurray@velocix.com  Thu Aug 30 11:33:50 2012
Return-Path: <RMurray@velocix.com>
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 B27B821F85A7 for <cdni@ietfa.amsl.com>; Thu, 30 Aug 2012 11:33:50 -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 jG+wtKc6D3Rk for <cdni@ietfa.amsl.com>; Thu, 30 Aug 2012 11:33:50 -0700 (PDT)
Received: from owa.velocix.com (mail-out1.velocix.com [81.134.152.10]) by ietfa.amsl.com (Postfix) with ESMTP id DBC1121F85A4 for <cdni@ietf.org>; Thu, 30 Aug 2012 11:33:49 -0700 (PDT)
Received: from EXC01-MLT.corp.velocix.com (172.18.4.41) by EXC00CAM.corp.velocix.com (172.18.4.40) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 30 Aug 2012 19:33:48 +0100
Received: from EXB04CAM.corp.velocix.com ([169.254.1.76]) by exc01-mlt.corp.velocix.com ([172.18.4.202]) with mapi id 14.02.0318.001; Thu, 30 Aug 2012 19:33:48 +0100
From: Rob Murray <RMurray@velocix.com>
To: "cdni@ietf.org" <cdni@ietf.org>
Thread-Topic: CDNI Triggers draft updated
Thread-Index: AQHNht3+yZkQCIYO10Wuoi/OlOs1OA==
Date: Thu, 30 Aug 2012 18:33:47 +0000
Message-ID: <CC657098.47601%rmurray@velocix.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.2.3.120616
x-originating-ip: [172.18.0.165]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <5D4E8F8D96212D4880D48737370780F5@velocix.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [CDNi] CDNI Triggers draft updated
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\)" <cdni.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cdni>, <mailto:cdni-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/cdni>
List-Post: <mailto:cdni@ietf.org>
List-Help: <mailto:cdni-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cdni>, <mailto:cdni-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Aug 2012 18:33:50 -0000

Hi all,

We've submitted an update to the CDNI Triggers draft dealing with comments
against the first version, we've not addressed open issues yet...

    http://tools.ietf.org/html/draft-murray-cdni-triggers-01


The main change in this version is to allow multiple trigger actions in a
single request, so that an invalidate/delete can be packaged with
prepopulate in order to replace content.

Open issues include:
  - how to refer to content and metadata, including pattern matching for
invalidate/purge (depends on metadata draft)
  - how to report failure (need to come up with error codes, and deal with
partial failure)
  - encoding may change to align with metadata and other interfaces

We'll continue to work on those things.

Best regards,
Rob.