From nobody Tue Dec 2 04:58:37 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3531B1A1B3B for ; Tue, 2 Dec 2014 04:58:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.116 X-Spam-Level: X-Spam-Status: No, score=-2.116 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OWlW2_do9q8R for ; Tue, 2 Dec 2014 04:58:32 -0800 (PST) Received: from fromintoutb.tno.nl (fromintoutb.tno.nl [134.221.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id 1F1F51A1B2E for ; Tue, 2 Dec 2014 04:58:31 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.07,500,1413237600"; d="scan'208";a="5702743" Received: from exc-cashub02.tsn.tno.nl (HELO mail.tno.nl) ([134.221.225.221]) by mailhost1b.tno.nl with ESMTP; 02 Dec 2014 13:58:31 +0100 Received: from EXC-MBX03.tsn.tno.nl ([fe80::e969:1300:fb9f:7e12]) by EXC-CASHUB02.tsn.tno.nl ([fe80::8c02:de2a:3094:171%14]) with mapi id 14.03.0195.001; Tue, 2 Dec 2014 13:58:31 +0100 From: "Brandenburg, R. (Ray) van" To: Ben Niven-Jenkins Thread-Topic: [CDNi] Liaison Statement on URI Signing for MPEG-DASH Thread-Index: AQHP/gWZcjC4WeJbFUStxfdC8RpP1JxdyIGAgABcl4CAAJm2AIABe1QAgAKqFQCAAWKZgIAAXRCQgAWIzoCABVjCgIAJkhkAgANIPpA= Date: Tue, 2 Dec 2014 12:58:30 +0000 Message-ID: References: <4C639B2E-E1B8-4B42-8F76-D98697E7CE5D@niven-jenkins.co.uk> <60396378-BBFF-4926-8141-990141163B1E@tno.nl> <166EBB70C264A9479E459B01B1BA6C926D62FDF4@xmb-aln-x03.cisco.com> <3A7EDCDD-7C42-4D82-88DE-E81A0EB65EB5@tno.nl> <166EBB70C264A9479E459B01B1BA6C926D641A55@xmb-aln-x03.cisco.com> <72CA5ACB-4283-41F7-A991-E53ABDE335AD@tno.nl> <9D8B22BA-A2C1-4AE9-9976-246D7D7D7969@niven-jenkins.co.uk> In-Reply-To: <9D8B22BA-A2C1-4AE9-9976-246D7D7D7969@niven-jenkins.co.uk> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.191] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/W5J2TiZBA-E0OljE5gCvUG4dwtI Cc: "cdni@ietf.org" Subject: Re: [CDNi] Liaison Statement on URI Signing for MPEG-DASH X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 12:58:35 -0000 Hi Ben, -----Original Message----- From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk]=20 Sent: zondag 30 november 2014 12:39 To: Brandenburg, R. (Ray) van Cc: Matt Caulfield (mcaulfie); Francois Le Faucher; cdni@ietf.org Subject: Re: [CDNi] Liaison Statement on URI Signing for MPEG-DASH Ray, See inline... On 24 Nov 2014, at 08:29, Brandenburg, R. (Ray) van wrote: > On 20/11/14 23:50, "Ben Niven-Jenkins" wrote: >=20 >> Ray, >>=20 >> I haven't caught up with the whole thread yet, but wanted to respond=20 >> to a couple things you say below. >>=20 >> On 17 Nov 2014, at 10:27, Brandenburg, R. (Ray) van=20 >> wrote: >>=20 >>> From: Matt Caulfield (mcaulfie) [mailto:mcaulfie@cisco.com] >>>> From: Brandenburg, R. (Ray) van [mailto:ray.vanbrandenburg@tno.nl]I >>>> don't necessarily think this method is superior to the Cookie-method. >>>> Both have their pros and cons. The problem with the Cookie method=20 >>>> is that it doesn't work when the manifest is served by the Content=20 >>>> Provider (which can be quite a common case). The problem with the=20 >>>> header-query-string method is that it only works for DASH clients,=20 >>>> and not for standard HLS clients. >>>=20 >>> In the case where the manifest is served by the Content Provider and=20 >>> the segments are served by the CDN, wouldn't the MPD need to contain=20 >>> absolute URLs? Meaning that segment URLs would go through regular=20 >>> request routing and URI signing? >>>=20 >>> [Ray] Yes, it would contain absolute URLs. It would be possible for=20 >>> the CSP to sign these URLs, however, that would mean signing them=20 >>> with an expiration time of at least the length of the content item. >>=20 >> Isn't that the same for the case where both the manifest & content is=20 >> served by the dCDN? The Content Provider only gets one chance to sign=20 >> a cookie in that case too? >=20 > The initial cookie yes. But the dCDN has the chance of=20 > refreshing/resigning the cookie every time a new request comes in. I'm struggling a little to get a picture of how you imagine this working? If the dCDN is seeing a valid (token in a) cookie and then setting a new (t= oken in a) cookie to effectively extend the validity of authorisation to ac= cess the content, it is not clear to me how that is in practice any differe= nt to setting a single cookie with a long expiration time. Could you explain a bit what the difference are? [Ray] The assumption is that a cookie that is only valid for e.g. 30 second= s before it has to be refreshed is inherently safer than one that is valid = for 90 minutes. Let me put it differently: if you have a token that is vali= d for 90 minutes (or possibly more) what is the purpose of having a token a= t all? If you look at URI Signing from a broader perspective, not just at H= AS content, is it really that much more difficult to share the deep-link to= the CDN that sharing the deep-link to the CDN in combination with the Cook= ie?=20 >> I also don't understand why the Content Provider delivering the=20 >> manifest and the dCDN delivering the content results in the Content=20 >> Provider having to sign the individual URLs in the manifest. >>=20 >> AFAIK (I haven't tested it), the Content Provider can deliver the=20 >> manifest from manifest.video.example.com and deliver the content via=20 >> the uCDN/dCDN by using URLs pointing to chunks.video.example.com and=20 >> share cookies across the domains by setting the token in a cookie=20 >> with a Domain attribute of ".video.example.com". >=20 > I believe most browser implementations reject cross-domain cookies,=20 > unless using CORS. What I described are not really cross-domain cookies, the situation I descr= ibe above is allowed by RFC6265 for instance and is not the same as say man= ifest.bar.com trying to set a cookie for chunks.foo.com Having said that I have no idea whether browsers typically have a stricter = policy than specified in RFC6265 but I have seen references on various help= websites (e.g. stack overflow) suggesting what I describe above as being a= llowed by browsers. [Ray] Agree, as long as it is the same domain. However, in the typical CSP-= CDN scenario, you're talking about different domains.=20 >> Alternatively the Content Provider could use CORS to enable cookie=20 >> sharing across domains. >=20 > I haven't thought of using CORS before. In theory I guess it should be=20 > possible. Do you have any idea on whether such a mechanism is used in=20 > practice by players/CDNs? We have customers that use CORS as part of their video services/players (wh= ere we are the CDN) but I am not in a position to share many details. I hav= e seen CORS used to deliver video to Chromecast devices. [Ray] Ok. That's good news. So I guess using CORS to set cross-domain cooki= es would be possible.=20 Ray >>> For an MPD of a 90min movie, that would mean expiration times of at=20 >>> least 90mins, which would reduce, if not negate altogether, the=20 >>> effectiveness of signing the URLs in the first place. >>=20 >> There are other approaches to avoid long expiration times, e.g=20 >> defining the semantics of the token so that it expiration applies to=20 >> TCP connection setup and so multiple requests are allowed on a=20 >> persistent connection past the expiration time of the token. >=20 > Hmm, yes, that would probably work, although it would give issues in=20 > case of dropped TCP connections. It does sound a bit like a=20 > cross-layer violation. Are you aware of any implementations that work lik= e this? I am not aware of any implementations that work like that. Another way to minimise the possible exposure of a long expiration time wou= ld be to "lock" the token to the client's IP address, although that is not = perfect in all cases either. Ben >=20 > Ray >=20 >>=20 >> Ben > This message may contain information that is not intended for you. If you= are not the addressee or if this message was sent to you by mistake, you a= re requested to inform the sender and delete the message. TNO accepts no li= ability for the content of this e-mail, for the manner in which you use it = and for damage of any kind resulting from the risks inherent to the electro= nic transmission of messages. From nobody Tue Dec 9 03:24:43 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1564D1A1BCF for ; Tue, 9 Dec 2014 03:24:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j9GGhC6zmafl for ; Tue, 9 Dec 2014 03:24:37 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id 6E9851A1BDB for ; Tue, 9 Dec 2014 03:24:28 -0800 (PST) Received: from cpc4-cmbg17-2-0-cust814.5-4.cable.virginm.net ([86.14.227.47] helo=[192.168.0.3]) by smtp04.mailcore.me with esmtpa (Exim 4.80.1) (envelope-from ) id 1XyIu2-0005lW-Rk; Tue, 09 Dec 2014 11:24:27 +0000 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Niven-Jenkins In-Reply-To: <68814413-8671-4A03-A274-CE89BD3AC4BD@cisco.com> Date: Tue, 9 Dec 2014 11:24:23 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20141025081441.2004.72206.idtracker@ietfa.amsl.com> <0D8B12F8-40E1-4D19-944F-4BC0C7D64972@niven-jenkins.co.uk> <68814413-8671-4A03-A274-CE89BD3AC4BD@cisco.com> To: Francois Le Faucher X-Mailer: Apple Mail (2.1878.6) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/O3C1ZH1nzWJ5hu07ljqGPuAigiw Cc: "draft-ietf-cdni-redirection@tools.ietf.org" , "cdni@ietf.org" Subject: Re: [CDNi] Review comments on draft-ietf-cdni-redirection-04.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 11:24:41 -0000 Hi Francois, I've incorporated the editorial comments below into my working copy of = -06. I'll respond to the TLS comments separately later. Ben =20 On 28 Nov 2014, at 10:59, Francois Le Faucheur (flefauch) = wrote: > All, >=20 > (as an individual) >=20 > My suggestions/comments below. >=20 > Francois >=20 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > *** Figure 1: > OLD: > =93 > with body containing attributes > =93 > NEW: > =93 > with body containing RT attributes > =93 >=20 >=20 >=20 > *** section 4: > OLD: > =93 > 3. The Request Routing System of CDN B processes the request > =93 > NEW: > =93 > 3. The Request Routing System of CDN B processes the RI request > " >=20 >=20 > *** section 4.2: > OLD: > =93 > o Requests or responses containing duplicate keys or containing keys > that are not all lowercase are considered syntactically invalid. > =93 > NEW: > =93 > o Requests or responses containing duplicate keys or containing keys > that are not all lowercase MUST be considered syntactically = invalid. > =93 >=20 >=20 > *** section 4.2: > OLD: > =93 > the dCDN it is making the request to then > =93 > NEW: > =93 > the dCDN it is making the request to, then > " >=20 >=20 >=20 >=20 > *** section 4.2: > OLD: > =93 > a transit CDN appends > =93 > NEW: > =93 > a transit CDN MUST append > =93 >=20 >=20 > *** section 4.3: > OLD: > =93 > RI requests SHOULD use > =93 > NEW > " > RI requests MUST use > =93 >=20 >=20 > *** section 4.3: > OLD: > =93 > RI responses SHOULD use > =93 > NEW > " > RI responses MUST use > =93 >=20 >=20 > *** section 4.4 > OLD: > =93 > provide more detailed descriptions > =93 > NEW: > =93 > provide detailed descriptions > =93 >=20 >=20 > *** section 4.4 > =93DNS response code=94=20 > Please add a reference where these codes are specified. >=20 >=20 >=20 > *** section 4.5 > OLD: > =93 > provide more detailed descriptions > =93 > NEW: > =93 > provide detailed descriptions > =93 >=20 >=20 > *** section 4.5.1 > OLD: > =93 > the User Agent's DNS query/request > =93 > NEW: > =93 > the User Agent's HTTP request > =93 >=20 >=20 > *** section 4.7 > OLD: > =93 > =46rom a uCDN perspective, there are two types of errors that can be > the result of the transmission of an RI request to a dCDN: An HTTP > protocol error signaled via an HTTP status code, indicating a = problem > with the reception or parsing of the RI request or the generation of > the RI response by the dCDN, and a RI-level error specified in an RI > response message. > =93 > NEW: > =93 > =46rom a uCDN perspective, there are two types of errors that can be > the result of the transmission of an RI request to a dCDN:=20 > (i ) An HTTP protocol error signaled via an HTTP status code, = indicating a problem > with the reception or parsing of the RI request or the generation of > the RI response by the dCDN, and=20 > (ii) a RI-level error specified in an RI response message. > =93 >=20 >=20 > *** section 4.7 > =93 > To aid with diagnosing the cause of errors, RI responses may include = an > error dictionary to provide additional information to the uCDN as to > the reason/cause of the error. > =93 > should the =93may=94 be a =93MAY=94 , or perhaps even a =93SHOULD=94? >=20 >=20 > *** section 5: > This section should mandate support for TLS and discuss when it should = be used. > This section should mandate support for some cypher suite. > This is common to all CDNI interfaces, so align with cdni-logging (and = cdni-metadata as discussed in Honolulu). >=20 >=20 >=20 >> On 25 Oct 2014, at 10:18, Ben Niven-Jenkins = wrote: >>=20 >> Colleagues, >>=20 >> This version is identical to -03 with the exception that we removed = the editors' note on adding a section for FCI capabilities as it is no = longer required as per the plan for FCI outlined by Francois & Kevin. >>=20 >> Ben >>=20 >> On 25 Oct 2014, at 09:14, internet-drafts@ietf.org wrote: >>=20 >>>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>> This draft is a work item of the Content Delivery Networks = Interconnection Working Group of the IETF. >>>=20 >>> Title : Request Routing Redirection Interface for CDN = Interconnection >>> Authors : Ben Niven-Jenkins >>> Ray van Brandenburg >>> Filename : draft-ietf-cdni-redirection-04.txt >>> Pages : 29 >>> Date : 2014-10-25 >>>=20 >>> Abstract: >>> The Request Routing Interface comprises of (1) the asynchronous >>> advertisement of footprint and capabilities by a downstream CDN that >>> allows a upstream CDN to decide whether to redirect particular user >>> requests to that downstream CDN; and (2) the synchronous operation = of >>> an upstream CDN requesting whether a downstream CDN is prepared to >>> accept a user request and of a downstream CDN responding with how to >>> actually redirect the user request. This document describes an >>> interface for the latter part, i.e. the CDNI Request Routing >>> Redirection interface. >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-cdni-redirection/ >>>=20 >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-cdni-redirection-04 >>>=20 >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-redirection-04 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of = submission >>> until the htmlized version and diff are available at tools.ietf.org. >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>> _______________________________________________ >>> CDNi mailing list >>> CDNi@ietf.org >>> https://www.ietf.org/mailman/listinfo/cdni >>=20 >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From nobody Tue Dec 9 04:08:29 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5310F1A1BCF for ; Tue, 9 Dec 2014 04:08:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_41=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6TVdIPgKZ1XS for ; Tue, 9 Dec 2014 04:08:23 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id CF9091A1BCC for ; Tue, 9 Dec 2014 04:08:21 -0800 (PST) Received: from cpc4-cmbg17-2-0-cust814.5-4.cable.virginm.net ([86.14.227.47] helo=[192.168.0.3]) by smtp04.mailcore.me with esmtpa (Exim 4.80.1) (envelope-from ) id 1XyJaW-0002lI-75; Tue, 09 Dec 2014 12:08:20 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Niven-Jenkins In-Reply-To: Date: Tue, 9 Dec 2014 12:08:17 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <50C0366F-C080-4004-8E37-7DE30F79AD9C@niven-jenkins.co.uk> References: <20141110233955.18069.1914.idtracker@ietfa.amsl.com> To: Kevin Ma J X-Mailer: Apple Mail (2.1878.6) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/6hFzgCh09zeOtNKsfO2nYv0nslI Cc: "cdni@ietf.org" Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-redirection-05.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 12:08:26 -0000 Hi Kevin, Thanks for the review. I've incorporated most of your editorial comments = into my working copy of -06. Responses to some other points are below. On 28 Nov 2014, at 22:33, Kevin Ma J wrote: > - Is the following statement true? I thought the idea of advertising > support for redirection mode was so that a given CDN did not have to > support both mechanisms? >=20 > "CDNI solutions are required to support both of the request routing > mechanisms illustrated in section 2.1 of [RFC7336], namely Iterative > Request Redirection and Recursive Request Redirection." >=20 > When using the RI, it doesn't matter if the dCDNs support either; > they could support neither. As long as the uCDN supported one, the > other, or both, and the dCDNs returned surrogate addresses over the > RI, then, it should just work? >=20 > - I think this can be simplified: >=20 > "Therefore, the Redirection Interface is only relevant in the case of > Recursive Request Redirection and so this document will not discuss > Iterative Request Redirection further." >=20 > to say: >=20 > "This document will therefore only focus on Recursive Request = Redirection." I reworded to=20 The Redirection Interface is only relevant in the case of Recursive Request Redirection, as Iterative Request Redirection does not invoke any interaction over the Redirection Interface between interconnected CDNs. Therefore the scope of this document is limited to Recursive Request Redirection. > - I think it would be useful to list the actual requirements > (i assume this is referring to GEN-11 and RI-5) and > possibly have a reference to the requirements RFC7337. >=20 > "Also, according to the CDNI generic and request routing interface > requirements, the CDNI solution shall support mechanisms to prevent > and detect RI request loops" >=20 > e.g.: >=20 > "CDNI requirements GEN-11 and RI-5 [RFC7337] specify that=20 > the CDNI solution shall support mechanisms to prevent > and detect RI request loops" I tried referencing the requirements in RFC7337 and decided I didn;t = like it so I reworded the sentence to simply say This document also defines an RI loop prevention and detection mechanism as part of the Redirection Interface. > - Is the scope only signaled when the response cacheable? > Is the scope only allowed to be signaled when the response is = cacheable? > The scope only really makes sense when it's cacheable, but is it an > error to send a scope if the response is not cacheable? As you note the scope of tends to make sense if the RI response is = cacheable but it is not an error to include a scope in an uncacheable RI = response and the spec doesn't dictate behaviour because it is not an = interoperability issue if a dCDN includes a scope in an uncacheable RI = response. > Section 4.2: > - Though the cdn-path MAY be reflected back, are the transit CDNs > allowed to remove themselves (and all further dCDNs) from the chain > as they respond, or are they required to maintain the full chain, if > they choose to include cdn-path in the response. >=20 > Similarly, is any CDN in the chain allowed to remove cdn-path from > the response, even if further downstream CDNs have included it > (i.e., the ultimate CDN decided to reflect)? I added some text to cover this: Transit CDNs MUST NOT modify the cdn-path when cascading an RI request, except to append its own CDN Provider ID. ... If the cdn-path is reflected back in the RI response it MUST contain the value of cdn-path received in the associated RI request with the final dCDN's CDN Provider ID appended. Transit CDNs MAY remove the cdn-path from RI responses but MUST NOT modify the cdn-path in other ways. > Section 4.4.1: >=20 > - What is the use case for the dns-only flag? Is it intended to > improve delivery performance? Would it be configured by the > content owner to enforce request routing properties? It is intended as a way for the uCDN to signal that it wants IP = addresses of surrogates returned not a request router in a dCDN. E.g. = because the uCDN/Content Provider knows that the content (e.g. a = website) is not compatible with HTTP redirection for some reason. In theory one could allow a dCDN to return a Request Router on the = promise that the request router only performed DNS redirection but we = didn't scope the fns-only flag that way because saying to only return IP = addresses seemed cleaner. > - If dns-only is set to true, and the transit CDN does not support DNS > redirection, is it always safe to propagate the request (assuming > the hop count and loop detection don't error out)? Presumably there > is eventually either a dCDN that supports DNS or an error? Yes it should always be safe as eventually there will either be a dCDN = that supports the fns-only flag or an error. > It's not clear to me how this flag should be used (see also > questions on next section)? If the authoritative CDN is returning > the DNS resolution to the UA, but the address provided by the dCDN > is a CNAME, does the dCDN have to honor that flag in subsequent DNS > queries to the dCDN? I have tried to clarify this is the description of the dns-only flag and = the description of DNS redirection responses=20 If True then dCDN MUST only use DNS redirection directly to a surrogate for its RI response and MUST include the dns-only property set to True on any cascaded RI requests. Defaults to False. ... A dCDN MUST NOT return a RT which is a Request Router if the dns- only key is set to True in the RI request. >=20 > Section 4.4.2: >=20 > This is the TTL for the DNS response? Is there an implied scope for > the RI response? Should the uCDN not try to glean anything from it? > Either way, we might want to explicitly state whether or not the > uCDN can use that information (especially if the information > conflicts with the scope information in the HTTP response headers of > the RI response). the ttl key is the TTL to be included in the DNS response sent to the = User Agent. There is no implied scope beyond what can be inferred by a = User Agent receiving that response. The ttl in the DNS redirection = response sent to the uCDN does not imply any cache ability or scope for = the RI response itself (that is signalled separately in the HTTP headers = & the top-level scope key of the RI response). > Section 4.5.1: >=20 > - For "cs-uri", is this the RFC2616 Request-URI from the HTTP request, > or is this the RFC7230 Effective Request URI? Could/Should/Would > the uCDN ever transform the URI to make it understandable to the = dCDN? It is the RFC7230 Effective Request URI. I've made that more explicit. I don't think the uCDN should transform the URL and the text now stating = that it is the RFC7230 Effective Request URI should make that clear. If a uCDN needs to transform for some reason, it should probably send = the transformation in a different key in the JSON object. > Section 4.5.2: >=20 > - Why is there a special case for "sc(cache-control)" in the table? > It is not mandatory and already covered by "sc()"? cs(location) is a similar case. They are both included as they are = required (in the case of cs(location)) and often used (in the case of = (cs(cache-control)) in redirection responses so it seems helpful to list = them directly. They also serve as example of the syntax. > This is the cacheability of the HTTP response. Is there an implied > scope for the RI response? Yes the cs(cache-control) key contains the field-value for the = Cache-Control: header to be included in the HTTP response sent to the = User Agent. There is no implied scope in the same way as there is no = implied scope for the t/l key in DNS redirection responses. > Section 4.7: > - Are error-codes generally vendor implementation/deployment = dependent? >=20 > "A three-digit numeric code defined by the server" >=20 > Should there be a registry for all error codes? The document already defines an IANA registry for RI error codes. > - Depending on the answer to the dns-only question above, should there > also be an error code for "dCDN does not support DNS redirection and > does not want to give a surrogate address and dns-only set to true"? > Would that just be a 500? I've added error code 506 for "Redirection protocol not supported": | 506 | Redirection | The dCDN does not support the requested | | | protocol not | redirection protocol. This error-code is | | | supported | also used when the RI request has the dns- | | | | only flag set to True and the dCDN is not | | | | support or is not prepared to return a RT | | | | of a surrogate directly. | > - Is it valid for the dCDN to set the Cache-Control header for an > error response, e.g., out of capacity for the next 20 min? Yes it is valid. > - Is it necessary to have both of these requirements? If the transit > CDNs never forward to looped dCDNs, the dCDNs should never be able > to detect a loop (assuming a uCDN doesn't sent to itself)? >=20 > "When receiving RI requests a dCDN MUST check > the cdn-path and reject any RI requests which already contain the > downstream CDN's Provider ID in the cdn-path. Transit CDNs MUST > check the cdn-path and not cascade the RI request to downstream CDNs > that are already listed in cdn-path." >=20 > I don't see any harm in listing both checks, just to be safe, but I > didn't know if I was missing something? It's belt & braces. If you only rely on the transit CDN to not forward = to looped dCDNs then a misbehaving transit CDN could cause a loop. = Checking on reception as well prevents that. > - Why aren't the 502 and 503 errors a MUST? >=20 > "If a downstream CDN receives a RI request whose cdn-path already > contains that downstream CDN's Provider ID the downstream CDN SHOULD > send a RI response with an error code of 502." >=20 > "If a downstream CDN receives a RI request where the number of CDN > Provider IDs in cdn-path is greater than max-hops, the downstream = CDN > SHOULD send a RI response with an error code of 503." Because returning an error key is optional. > Section 5: >=20 > - Should we make TLS a MUST? Using similar text to the triggers = draft? I'll respond to this in a separate e-mail as Francois had a similar = comment too. Ben >=20 >> -----Original Message----- >> From: CDNi [mailto:cdni-bounces@ietf.org] On Behalf Of Ben = Niven-Jenkins >> Sent: Monday, November 10, 2014 6:41 PM >> To: cdni@ietf.org >> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-redirection-05.txt >>=20 >> Colleagues, >>=20 >> This update just contains a small number of editorial changes the = editors >> noticed when preparing for IETF91. >>=20 >> Regards >> Ben >>=20 >> On 10 Nov 2014, at 23:39, internet-drafts@ietf.org wrote: >>=20 >>>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >>> This draft is a work item of the Content Delivery Networks = Interconnection >> Working Group of the IETF. >>>=20 >>> Title : Request Routing Redirection Interface for = CDN >> Interconnection >>> Authors : Ben Niven-Jenkins >>> Ray van Brandenburg >>> Filename : draft-ietf-cdni-redirection-05.txt >>> Pages : 29 >>> Date : 2014-11-10 >>>=20 >>> Abstract: >>> The Request Routing Interface comprises of (1) the asynchronous >>> advertisement of footprint and capabilities by a downstream CDN = that >>> allows a upstream CDN to decide whether to redirect particular user >>> requests to that downstream CDN; and (2) the synchronous operation = of >>> an upstream CDN requesting whether a downstream CDN is prepared to >>> accept a user request and of a downstream CDN responding with how = to >>> actually redirect the user request. This document describes an >>> interface for the latter part, i.e. the CDNI Request Routing >>> Redirection interface. >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-cdni-redirection/ >>>=20 >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-cdni-redirection-05 >>>=20 >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-redirection-05 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of >> submission >>> until the htmlized version and diff are available at tools.ietf.org. >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>> _______________________________________________ >>> CDNi mailing list >>> CDNi@ietf.org >>> https://www.ietf.org/mailman/listinfo/cdni >>=20 >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni From nobody Tue Dec 9 04:56:12 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 760E81A19E9 for ; Tue, 9 Dec 2014 04:56:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.589 X-Spam-Level: *** X-Spam-Status: No, score=3.589 tagged_above=-999 required=5 tests=[BAYES_50=0.8, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L6ZRzXQkuU0J for ; Tue, 9 Dec 2014 04:56:06 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id 413D11A0451 for ; Tue, 9 Dec 2014 04:56:06 -0800 (PST) Received: from cpc4-cmbg17-2-0-cust814.5-4.cable.virginm.net ([86.14.227.47] helo=[192.168.0.3]) by smtp04.mailcore.me with esmtpa (Exim 4.80.1) (envelope-from ) id 1XyKKj-0006ew-3w; Tue, 09 Dec 2014 12:56:05 +0000 Content-Type: text/plain; charset=GB2312 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Niven-Jenkins In-Reply-To: <46A1DF3F04371240B504290A071B4DB66CA9F356@SZXEMA510-MBX.china.huawei.com> Date: Tue, 9 Dec 2014 12:56:01 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <46A1DF3F04371240B504290A071B4DB66CA9F356@SZXEMA510-MBX.china.huawei.com> To: Bert Greevenbosch X-Mailer: Apple Mail (2.1878.6) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/FP6b7ykWlrmAgRBytIAgU94A1gk Cc: "cdni@ietf.org" , "draft-ietf-cdni-redirection@tools.ietf.org" Subject: Re: [CDNi] Review of draft-ietf-cdni-redirection-05 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 12:56:09 -0000 Hi Bert, Thanks for the review. Please see inline for my responses. On 29 Nov 2014, at 03:07, Bert Greevenbosch = wrote: > --- > (BG1) In section 4.2: "The cdn-path MAY be reflected back in RI = responses, although doing so would expose information to the uCDN that a = dCDN may not wish to expose (for example, the existence of business = relationships between a dCDN and other CDNs)." The information in the = cdn-path can be forwarded from a dCDN to another dCDN though. Why is it = not a problem that the second dCDN acquires such information from the = first? Because having that information is required for loop prevention. = cdn-path in an RI request exposes the CDNs that are before the current = CDN in the RI flow. cdn-path in an RI response exposes the CDNs that = come after the current CDN in the RI flow. We need to expose the former = to prevent loops but we don't need to expose the latter. =20 >=20 > (BG2) In section 4.4.1, the bullet list specifies five information = points that need to be passed from the uCDN to the dCDN. The IP address = or prefix of the UA is also listed, but in the following table, the = related field "c-subnet" is not mandatory. Why is it not mandatory? c-subnet is only available if the DNS resolvers between the User and the = uCDN support a DNS extension (draft-vaandergaast) that is not widely = deployed at the moment so it is not possible to make c-subnet mandatory. =20 > (BG3) Related to (BG2): It seems better to combine the text "This dns = dictionary MUST contain the following keys: resolver-ip, qtype, qclass, = qname and the value of each MUST be the value of the appropriate part of = the User Agent's DNS query/request" with the bullet list at the start of = section 4.4.1, as the information seems to be double. This comment also = applies to section 4.5.1. The idea is to introduce the concepts, then the dictionary structure and = then define which of those dictionary keys are mandatory and their = related behaviour. =20 > (BG4) In section 4.4.2: "The dns dictionary MAY include both 'a' and = 'aaaa' keys. If the dns dictionary contains a cname key it MUST NOT = contain either an a or aaaa key." Why? It makes sense to not do a DNS = lookup for a cname if the related IP address is already available in the = response, but why mandate the absence of cname in that case? The cname returned is what the dCDN wants the User Agent to receive so = it can perform DNS resolution based on the User Agent itself, e.g. to = select a particular surrogate in response to a DNS request directly from = the User Agent. Pre-resolving provides no value in that use case and = provides an unclear semantic to the uCDN which does not know whether to = return the A/AAAA records or the CNAME to the User Agent. =20 > (BG5) Do the 'a' and 'aaaa' fields point at the same RTs? (I notice = in the examples that the number of elements in the 'a' and 'aaaa' fields = are equal, which may mean that for each element in a there is a related = element in 'aaaa'.) I guess this is not the case, but want to make sure. The A and AAAA fields do not have to be equal sized lists or point at = the same RTs. =20 > (BG6) Table in section 4.5.1: "cs-uri", "The URI requested by the UA". = This URI is called URL elsewhere. Unify the wording. I unified on URI. =20 > (BG7) Section 4.5.1: "In the case where the User Agent request = includes multiple HTTP header fields with the same field-name, it is up = to the uCDN to determine how to handle this. One option would be to only = send the contents of the first occurrence of that HTTP Header in the = User Agent Request. Another would be to combine the different HTTP = Headers into a single value according to Section 3.2.2 of [RFC7230]." = The text in RFC 7230 says that such combined header field is = semantically equivalent to the separated headers fields. However, here = we allow different handling for such equivalent encodings. Maybe we = should mandate that the Headers need to be combined into a single value, = or at least use a SHOULD? Unfortunately use of HTTP header fields in the wild is inconsistent for = some headers fields, so it is really dependent on which header fields = the uCDN is passing on as to what the best behaviour might be so we = can't be too specific and have to rely on the uCDN knowing what they are = passing on. =20 > (BG8) In sections 4.5.1 and 4.5.2, there is mentioning of the keys = "sc()" and "cs()". Are these the same? If so, = use a single key. If not, explain their difference. (Maybe this has = something to do with the direction server->client, client->server.) Correct it is a convention to show the direction the header field was = passed. I've added the following text to explain them The dictionary keys used in HTTP Redirection requests and responses use the following conventions for their prefixes: o c- is prefixed to keys for information related to the Client (User Agent). o cs- is prefixed to keys for information passed by the Client (User Agent) to the Server (uCDN). o sc- is prefixed to keys for information to be passed by the Server (uCDN) to the Client (User Agent). =20 > (BG9) Related to (BG8): in the last line on page 16, should = "cs()" be "sc()"? Good catch! =20 > (BG10) I propose to modify first sentence in section 4.6, "RI = responses may be cacheable and may be reused by the uCDN in response to = User Agent requests without the uCDN issuing another RI request to the = dCDN if the RI response is considered cachable & not stale according to = the standard HTTP Cache-Control, etc mechanisms." as follows: "RI = responses may be cacheable. As long as a cached RI response is not stale = according to standard HTTP Cache-Control or other applicable mechanisms, = it may be reused by the uCDN in response to User Agent requests without = sending another RI request to the dCDN." Done. =20 > (BG11) Section 4.6 contains the following text: "(except for the c-ip = field provided the User Agent's c-ip is covered by the scope in the = original RI response)". The scope dictionary ("iprange") is only defined = later, making the sentence confusing. Maybe reword as follows: "(except = for the c-ip field provided that the User Agent's c-ip is covered by the = scope in the original RI response, as elaborated upon below)". Done. =20 > (BG12) The second example on page 9 in has two "max-age" fields: one = in the header ("max-age=3D60") and one in the body ("max-age=3D30"). The = former must be meant for the uCDN, whereas the latter is meant for the = UA. Maybe it would be good to add the following text after "Example of = HTTP redirection response from Section 4.5.2 that is cacheable by the = uCDN for 60 seconds and can be returned to any User Agent with an IPv4 = address in 198.51.100.0/24.": "Notice that the response to the UA is = only valid for 30 seconds, whereas the uCDN can cache the RI response = for 60 seconds." Done. =20 > (BG13) In the second table in section 4.7, on page 22, there is the = text "" for codes 100, 400, and 500. =46rom the IANA = considerations section, it later becomes clear that this "" is = actually the value of the "reason" string in the error information. = However, that is not clear from the table. I think it would be good to = clarify this already in section 4.7. Done. I added the following text above the table: Error codes with a "Reason" of "" do not have a defined value for their 'reason'-key. Depending on the error-code semantics, the value of this field may be determined dynamically. =20 > (BG14) In section 4.8, there is the following text (A) about the = max-hops value: "Transit CDNs MUST NOT propagate to any downstream CDNs = if the number of CDN Provider IDs in cdn-path is equal to or greater = than max-hops." In addition, there is the text (B): "If a downstream CDN = receives a RI request where the number of CDN Provider IDs in cdn-path = is greater than max-hops, the downstream CDN SHOULD send a RI response = with an error code of 503.". Text (B) seems to indicate that the values = of max-hops / cdn-path are checked upon receipt of the message, not = before sending it. Thus, if max-hops =3D 1, the first dCDN can propagate = the RI request, but the second cannot. That means that in text (A), the = cdn-path is evaluated _before_ the dCDN adds its own Provider ID. I = propose to write this explicitly, and thus rephrase (A) as follows: = "Transit CDNs MUST NOT propagate to any downstream CDNs if the number of = CDN Provider IDs in cdn-path (before adding its own Provider ID) is = equal to or greater than max-hops." Done. Thanks Ben > =20 > =20 > Bert Greevenbosch > Huawei Technologies Co., Ltd. > =20 > bert.greevenbosch@huawei.com > =20 > Huawei Industrial Base F1-8 > Bantian, Longgang District > Shenzhen 518129 > P.R. China > =20 > http://www.huawei.com > = =B1=BE=D3=CA=BC=FE=BC=B0=C6=E4=B8=BD=BC=FE=BA=AC=D3=D0=BB=AA=CE=AA=B9=AB=CB= =BE=B5=C4=B1=A3=C3=DC=D0=C5=CF=A2=A3=AC=BD=F6=CF=DE=D3=DA=B7=A2=CB=CD=B8=F8= =C9=CF=C3=E6=B5=D8=D6=B7=D6=D0=C1=D0=B3=F6=B5=C4=B8=F6=C8=CB=BB=F2=C8=BA=D7= =E9=A1=A3=BD=FB > = =D6=B9=C8=CE=BA=CE=C6=E4=CB=FB=C8=CB=D2=D4=C8=CE=BA=CE=D0=CE=CA=BD=CA=B9=D3= =C3=A3=A8=B0=FC=C0=A8=B5=AB=B2=BB=CF=DE=D3=DA=C8=AB=B2=BF=BB=F2=B2=BF=B7=D6= =B5=D8=D0=B9=C2=B6=A1=A2=B8=B4=D6=C6=A1=A2=BB=F2=C9=A2=B7=A2=A3=A9=B1=BE=D3= =CA=BC=FE=D6=D0 > =B5=C4=D0=C5=CF=A2=A1=A3=C8=E7=B9=FB=C4=FA=B4=ED=CA=D5=C1=CB=B1=BE=D3=CA= =BC=FE=A3=AC=C7=EB=C4=FA=C1=A2=BC=B4=B5=E7=BB=B0=BB=F2=D3=CA=BC=FE=CD=A8=D6= =AA=B7=A2=BC=FE=C8=CB=B2=A2=C9=BE=B3=FD=B1=BE=D3=CA=BC=FE=A3=A1 > This e-mail and its attachments contain confidential information from = HUAWEI, which=20 > is intended only for the person or entity whose address is listed = above. Any use of the=20 > information contained herein in any way (including, but not limited = to, total or partial=20 > disclosure, reproduction, or dissemination) by persons other than the = intended=20 > recipient(s) is prohibited. If you receive this e-mail in error, = please notify the sender by=20 > phone or email immediately and delete it! > =20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From nobody Tue Dec 9 17:07:29 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 252741A1A5F for ; Tue, 9 Dec 2014 17:07:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.278 X-Spam-Level: * X-Spam-Status: No, score=1.278 tagged_above=-999 required=5 tests=[BAYES_50=0.8, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id scDFhAW4akCB for ; Tue, 9 Dec 2014 17:07:23 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F55A1A0399 for ; Tue, 9 Dec 2014 17:07:22 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BMR28497; Wed, 10 Dec 2014 01:07:20 +0000 (GMT) Received: from SZXEMA414-HUB.china.huawei.com (10.82.72.73) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 10 Dec 2014 01:07:19 +0000 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.118]) by SZXEMA414-HUB.china.huawei.com ([10.82.72.73]) with mapi id 14.03.0158.001; Wed, 10 Dec 2014 09:07:12 +0800 From: Bert Greevenbosch To: Ben Niven-Jenkins Thread-Topic: [CDNi] Review of draft-ietf-cdni-redirection-05 Thread-Index: AQHQE6+Skg9znac35E2mEebQ+mjpSJyH/Zjw Date: Wed, 10 Dec 2014 01:07:11 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB66CB0F9EB@SZXEMA510-MBX.china.huawei.com> References: <46A1DF3F04371240B504290A071B4DB66CA9F356@SZXEMA510-MBX.china.huawei.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.63.174.121] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/hU5cDeARBZZEbL_61JBBm7PB6Ns Cc: "cdni@ietf.org" , "draft-ietf-cdni-redirection@tools.ietf.org" Subject: Re: [CDNi] Review of draft-ietf-cdni-redirection-05 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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, 10 Dec 2014 01:07:27 -0000 SGkgQmVuLA0KDQpUaGFuayB5b3UgZm9yIHlvdXIgYW5zd2VyIHRvIG15IGNvbW1lbnRzLg0KDQpQ bGVhc2UgZmluZCBteSByZXNwb25zZSBiZWxvdy4NCg0KQmVzdCByZWdhcmRzLA0KQmVydA0KDQoN Cj4gSGkgQmVydCwNCj4gDQo+IFRoYW5rcyBmb3IgdGhlIHJldmlldy4gUGxlYXNlIHNlZSBpbmxp bmUgZm9yIG15IHJlc3BvbnNlcy4NCj4gDQo+IE9uIDI5IE5vdiAyMDE0LCBhdCAwMzowNywgQmVy dCBHcmVldmVuYm9zY2ggPEJlcnQuR3JlZXZlbmJvc2NoQGh1YXdlaS5jb20+DQo+IHdyb3RlOg0K PiANCj4gPiAtLS0NCj4gPiAoQkcxKSBJbiBzZWN0aW9uIDQuMjogIlRoZSBjZG4tcGF0aCBNQVkg YmUgcmVmbGVjdGVkIGJhY2sgaW4gUkkgcmVzcG9uc2VzLA0KPiBhbHRob3VnaCBkb2luZyBzbyB3 b3VsZCBleHBvc2UgaW5mb3JtYXRpb24gdG8gdGhlIHVDRE4gdGhhdCBhIGRDRE4gbWF5IG5vdA0K PiB3aXNoIHRvIGV4cG9zZSAoZm9yIGV4YW1wbGUsIHRoZSBleGlzdGVuY2Ugb2YgYnVzaW5lc3Mg cmVsYXRpb25zaGlwcyBiZXR3ZWVuIGENCj4gZENETiBhbmQgb3RoZXIgQ0ROcykuIiBUaGUgaW5m b3JtYXRpb24gaW4gdGhlIGNkbi1wYXRoIGNhbiBiZSBmb3J3YXJkZWQgZnJvbSBhDQo+IGRDRE4g dG8gYW5vdGhlciBkQ0ROIHRob3VnaC4gV2h5IGlzIGl0IG5vdCBhIHByb2JsZW0gdGhhdCB0aGUg c2Vjb25kIGRDRE4NCj4gYWNxdWlyZXMgc3VjaCBpbmZvcm1hdGlvbiBmcm9tIHRoZSBmaXJzdD8N Cj4gDQo+IEJlY2F1c2UgaGF2aW5nIHRoYXQgaW5mb3JtYXRpb24gaXMgcmVxdWlyZWQgZm9yIGxv b3AgcHJldmVudGlvbi4gY2RuLXBhdGggaW4NCj4gYW4gUkkgcmVxdWVzdCBleHBvc2VzIHRoZSBD RE5zIHRoYXQgYXJlIGJlZm9yZSB0aGUgY3VycmVudCBDRE4gaW4gdGhlIFJJIGZsb3cuDQo+IGNk bi1wYXRoIGluIGFuIFJJIHJlc3BvbnNlIGV4cG9zZXMgdGhlIENETnMgdGhhdCBjb21lIGFmdGVy IHRoZSBjdXJyZW50IENETiBpbg0KPiB0aGUgUkkgZmxvdy4gV2UgbmVlZCB0byBleHBvc2UgdGhl IGZvcm1lciB0byBwcmV2ZW50IGxvb3BzIGJ1dCB3ZSBkb24ndCBuZWVkDQo+IHRvIGV4cG9zZSB0 aGUgbGF0dGVyLg0KDQpPSyAtIEkgc2VlIHRoZSBuZWVkIGZvciBmb3J3YXJkaW5nIHZpc2l0ZWQg bm9kZXMgaW4gdGhlIGNkbi1wYXRoLCBhbmQgdGhhdCB0aGlzIGlzIGEga2luZCBvZiBiZXN0IGVm Zm9ydCBhcHByb2FjaC4NCg0KU3RpbGwsIEkgd29uZGVyIGluIGhvdyBmYXIgdGhlIGNvbmZpZGVu dGlhbCBpbmZvcm1hdGlvbiBmcm9tIHRoZSB1Q0ROIGlzIHJlYWxseSBwcm90ZWN0ZWQgYnkgdGhl IG1lY2hhbmlzbS4gTmV2ZXJ0aGVsZXNzLCBzZW5kaW5nIGluZm9ybWF0aW9uIHRoYXQgaXMgbm90 IG5lZWRlZCBpcyBqdXN0IGEgd2FzdGUgb2YgYmFuZHdpZHRoLCBzbyBpbmRlZWQgaXQgaXMgYmV0 dGVyIHRvIG9taXQgaXQuDQoNCj4gPiAoQkcyKSBJbiBzZWN0aW9uIDQuNC4xLCB0aGUgYnVsbGV0 IGxpc3Qgc3BlY2lmaWVzIGZpdmUgaW5mb3JtYXRpb24gcG9pbnRzDQo+IHRoYXQgbmVlZCB0byBi ZSBwYXNzZWQgZnJvbSB0aGUgdUNETiB0byB0aGUgZENETi4gVGhlIElQIGFkZHJlc3Mgb3IgcHJl Zml4IG9mDQo+IHRoZSBVQSBpcyBhbHNvIGxpc3RlZCwgYnV0IGluIHRoZSBmb2xsb3dpbmcgdGFi bGUsIHRoZSByZWxhdGVkIGZpZWxkICJjLQ0KPiBzdWJuZXQiIGlzIG5vdCBtYW5kYXRvcnkuIFdo eSBpcyBpdCBub3QgbWFuZGF0b3J5Pw0KPiANCj4gYy1zdWJuZXQgaXMgb25seSBhdmFpbGFibGUg aWYgdGhlIEROUyByZXNvbHZlcnMgYmV0d2VlbiB0aGUgVXNlciBhbmQgdGhlIHVDRE4NCj4gc3Vw cG9ydCBhIEROUyBleHRlbnNpb24gKGRyYWZ0LXZhYW5kZXJnYWFzdCkgdGhhdCBpcyBub3Qgd2lk ZWx5IGRlcGxveWVkIGF0DQo+IHRoZSBtb21lbnQgc28gaXQgaXMgbm90IHBvc3NpYmxlIHRvIG1h a2UgYy1zdWJuZXQgbWFuZGF0b3J5Lg0KDQpPSw0KDQo+ID4gKEJHMykgUmVsYXRlZCB0byAoQkcy KTogSXQgc2VlbXMgYmV0dGVyIHRvIGNvbWJpbmUgdGhlIHRleHQgIlRoaXMgZG5zDQo+IGRpY3Rp b25hcnkgTVVTVCBjb250YWluIHRoZSBmb2xsb3dpbmcga2V5czogcmVzb2x2ZXItaXAsIHF0eXBl LCBxY2xhc3MsIHFuYW1lDQo+IGFuZCB0aGUgdmFsdWUgb2YgZWFjaCBNVVNUIGJlIHRoZSB2YWx1 ZSBvZiB0aGUgYXBwcm9wcmlhdGUgcGFydCBvZiB0aGUgVXNlcg0KPiBBZ2VudCdzIEROUyBxdWVy eS9yZXF1ZXN0IiB3aXRoIHRoZSBidWxsZXQgbGlzdCBhdCB0aGUgc3RhcnQgb2Ygc2VjdGlvbiA0 LjQuMSwNCj4gYXMgdGhlIGluZm9ybWF0aW9uIHNlZW1zIHRvIGJlIGRvdWJsZS4gVGhpcyBjb21t ZW50IGFsc28gYXBwbGllcyB0byBzZWN0aW9uDQo+IDQuNS4xLg0KPiANCj4gVGhlIGlkZWEgaXMg dG8gaW50cm9kdWNlIHRoZSBjb25jZXB0cywgdGhlbiB0aGUgZGljdGlvbmFyeSBzdHJ1Y3R1cmUg YW5kIHRoZW4NCj4gZGVmaW5lIHdoaWNoIG9mIHRob3NlIGRpY3Rpb25hcnkga2V5cyBhcmUgbWFu ZGF0b3J5IGFuZCB0aGVpciByZWxhdGVkDQo+IGJlaGF2aW91ci4NCg0KSSByZWFsaXNlIHRoYXQg dGhpcyBpcyBhbiBlZGl0b3JpYWwuIE5ldmVydGhlbGVzcyBpZiB5b3Ugd3JpdGUgdGhlIGluZm9y bWF0aW9uIHR3aWNlLCB5b3UgbmVlZCB0byBkb3VibGUgY2hlY2sgZm9yIGluY29uc2lzdGVuY2ll cyB0b28sIGFuZCB0aGUgcmVhZGVyIGhhcyB0byByZWFkIG1vcmUgdGhhbiB0aGV5IG5lZWQuIEkn bGwgbGVhdmUgaXQgdXAgdG8gdGhlIGF1dGhvcnMgd2hldGhlciB0byBrZWVwIHRoaXMgc3RydWN0 dXJlLg0KDQo+ID4gKEJHNCkgSW4gc2VjdGlvbiA0LjQuMjogIlRoZSBkbnMgZGljdGlvbmFyeSBN QVkgaW5jbHVkZSBib3RoICdhJyBhbmQgJ2FhYWEnDQo+IGtleXMuIElmIHRoZSBkbnMgZGljdGlv bmFyeSBjb250YWlucyBhIGNuYW1lIGtleSBpdCBNVVNUIE5PVCBjb250YWluIGVpdGhlciBhbg0K PiBhIG9yIGFhYWEga2V5LiIgV2h5PyBJdCBtYWtlcyBzZW5zZSB0byBub3QgZG8gYSBETlMgbG9v a3VwIGZvciBhIGNuYW1lIGlmIHRoZQ0KPiByZWxhdGVkIElQIGFkZHJlc3MgaXMgYWxyZWFkeSBh dmFpbGFibGUgaW4gdGhlIHJlc3BvbnNlLCBidXQgd2h5IG1hbmRhdGUgdGhlDQo+IGFic2VuY2Ug b2YgY25hbWUgaW4gdGhhdCBjYXNlPw0KPiANCj4gVGhlIGNuYW1lIHJldHVybmVkIGlzIHdoYXQg dGhlIGRDRE4gd2FudHMgdGhlIFVzZXIgQWdlbnQgdG8gcmVjZWl2ZSBzbyBpdCBjYW4NCj4gcGVy Zm9ybSBETlMgcmVzb2x1dGlvbiBiYXNlZCBvbiB0aGUgVXNlciBBZ2VudCBpdHNlbGYsIGUuZy4g dG8gc2VsZWN0IGENCj4gcGFydGljdWxhciBzdXJyb2dhdGUgaW4gcmVzcG9uc2UgdG8gYSBETlMg cmVxdWVzdCBkaXJlY3RseSBmcm9tIHRoZSBVc2VyIEFnZW50Lg0KPiBQcmUtcmVzb2x2aW5nIHBy b3ZpZGVzIG5vIHZhbHVlIGluIHRoYXQgdXNlIGNhc2UgYW5kIHByb3ZpZGVzIGFuIHVuY2xlYXIN Cj4gc2VtYW50aWMgdG8gdGhlIHVDRE4gd2hpY2ggZG9lcyBub3Qga25vdyB3aGV0aGVyIHRvIHJl dHVybiB0aGUgQS9BQUFBIHJlY29yZHMNCj4gb3IgdGhlIENOQU1FIHRvIHRoZSBVc2VyIEFnZW50 Lg0KDQpPSw0KDQo+ID4gKEJHNSkgRG8gdGhlICdhJyBhbmQgJ2FhYWEnIGZpZWxkcyBwb2ludCBh dCB0aGUgc2FtZSBSVHM/ICAoSSBub3RpY2UgaW4gdGhlDQo+IGV4YW1wbGVzIHRoYXQgdGhlIG51 bWJlciBvZiBlbGVtZW50cyBpbiB0aGUgJ2EnIGFuZCAnYWFhYScgZmllbGRzIGFyZSBlcXVhbCwN Cj4gd2hpY2ggbWF5IG1lYW4gdGhhdCBmb3IgZWFjaCBlbGVtZW50IGluIGEgdGhlcmUgaXMgYSBy ZWxhdGVkIGVsZW1lbnQgaW4NCj4gJ2FhYWEnLikgSSBndWVzcyB0aGlzIGlzIG5vdCB0aGUgY2Fz ZSwgYnV0IHdhbnQgdG8gbWFrZSBzdXJlLg0KPiANCj4gVGhlIEEgYW5kIEFBQUEgZmllbGRzIGRv IG5vdCBoYXZlIHRvIGJlIGVxdWFsIHNpemVkIGxpc3RzIG9yIHBvaW50IGF0IHRoZSBzYW1lDQo+ IFJUcy4NCg0KTWF5YmUgcmVtb3ZlIG9uZSBvZiB0aGUgSVB2NCBhZGRyZXNzZXMgZnJvbSB0aGUg ZXhhbXBsZT8NCiANCj4gPiAoQkc2KSBUYWJsZSBpbiBzZWN0aW9uIDQuNS4xOiAiY3MtdXJpIiwg IlRoZSBVUkkgcmVxdWVzdGVkIGJ5IHRoZSBVQSIuIFRoaXMNCj4gVVJJIGlzIGNhbGxlZCBVUkwg ZWxzZXdoZXJlLiBVbmlmeSB0aGUgd29yZGluZy4NCj4gDQo+IEkgdW5pZmllZCBvbiBVUkkuDQoN Ck9LDQoNCj4gPiAoQkc3KSBTZWN0aW9uIDQuNS4xOiAiSW4gdGhlIGNhc2Ugd2hlcmUgdGhlIFVz ZXIgQWdlbnQgcmVxdWVzdCBpbmNsdWRlcw0KPiBtdWx0aXBsZSBIVFRQIGhlYWRlciBmaWVsZHMg d2l0aCB0aGUgc2FtZSBmaWVsZC1uYW1lLCBpdCBpcyB1cCB0byB0aGUgdUNETiB0bw0KPiBkZXRl cm1pbmUgaG93IHRvIGhhbmRsZSB0aGlzLiBPbmUgb3B0aW9uIHdvdWxkIGJlIHRvIG9ubHkgc2Vu ZCB0aGUgY29udGVudHMgb2YNCj4gdGhlIGZpcnN0IG9jY3VycmVuY2Ugb2YgdGhhdCBIVFRQIEhl YWRlciBpbiB0aGUgVXNlciBBZ2VudCBSZXF1ZXN0LiBBbm90aGVyDQo+IHdvdWxkIGJlIHRvIGNv bWJpbmUgdGhlIGRpZmZlcmVudCBIVFRQIEhlYWRlcnMgaW50byBhIHNpbmdsZSB2YWx1ZSBhY2Nv cmRpbmcNCj4gdG8gU2VjdGlvbiAzLjIuMiBvZiBbUkZDNzIzMF0uIiBUaGUgdGV4dCBpbiBSRkMg NzIzMCBzYXlzIHRoYXQgc3VjaCBjb21iaW5lZA0KPiBoZWFkZXIgZmllbGQgaXMgc2VtYW50aWNh bGx5IGVxdWl2YWxlbnQgdG8gdGhlIHNlcGFyYXRlZCBoZWFkZXJzIGZpZWxkcy4NCj4gSG93ZXZl ciwgaGVyZSB3ZSBhbGxvdyBkaWZmZXJlbnQgaGFuZGxpbmcgZm9yIHN1Y2ggZXF1aXZhbGVudCBl bmNvZGluZ3MuIE1heWJlDQo+IHdlIHNob3VsZCBtYW5kYXRlIHRoYXQgdGhlIEhlYWRlcnMgbmVl ZCB0byBiZSBjb21iaW5lZCBpbnRvIGEgc2luZ2xlIHZhbHVlLCBvcg0KPiBhdCBsZWFzdCB1c2Ug YSBTSE9VTEQ/DQo+IA0KPiBVbmZvcnR1bmF0ZWx5IHVzZSBvZiBIVFRQIGhlYWRlciBmaWVsZHMg aW4gdGhlIHdpbGQgaXMgaW5jb25zaXN0ZW50IGZvciBzb21lDQo+IGhlYWRlcnMgZmllbGRzLCBz byBpdCBpcyByZWFsbHkgZGVwZW5kZW50IG9uIHdoaWNoIGhlYWRlciBmaWVsZHMgdGhlIHVDRE4g aXMNCj4gcGFzc2luZyBvbiBhcyB0byB3aGF0IHRoZSBiZXN0IGJlaGF2aW91ciBtaWdodCBiZSBz byB3ZSBjYW4ndCBiZSB0b28gc3BlY2lmaWMNCj4gYW5kIGhhdmUgdG8gcmVseSBvbiB0aGUgdUNE TiBrbm93aW5nIHdoYXQgdGhleSBhcmUgcGFzc2luZyBvbi4NCg0KWWVzLCBidXQgc3RpbGwgdGhl cmUgaXMgYW4gaW5jb25zaXN0ZW5jeSB3aXRoIFJGQyA3MjMwLiBJIHdvdWxkIG9wdCBmb3IgYSBT SE9VTEQgb3IgUkVDT01NRU5ERUQsIGUuZy4gY2hhbmdlIHRoZSB0ZXh0IHRvOg0KDQoiSW4gdGhl IGNhc2Ugd2hlcmUgdGhlIFVzZXIgQWdlbnQgcmVxdWVzdCBpbmNsdWRlcyBtdWx0aXBsZSBIVFRQ IGhlYWRlciBmaWVsZHMgd2l0aCB0aGUgc2FtZSBmaWVsZC1uYW1lLCBpdCBpcyBSRUNPTU1FTkRF RCB0aGF0IHRoZSB1Q0ROIGNvbWJpbmVzIHRoZXNlIGRpZmZlcmVudCBIVFRQIGhlYWRlcnMgaW50 byBhIHNpbmdsZSB2YWx1ZSBhY2NvcmRpbmcgdG8gU2VjdGlvbiAzLjIuMiBvZiBbUkZDNzIzMF0u IEhvd2V2ZXIsIGJlY2F1c2Ugb2YgdGhlIHBsdXJhbGl0eSBvZiBhbHJlYWR5IGRlZmluZWQgSFRU UCBoZWFkZXIgZmllbGRzLCBhbmQgaW5jb25zaXN0ZW5jeSBvZiBzb21lIG9mIHRoZXNlIGhlYWRl ciBmaWVsZHMgY29uY2VybmluZyB0aGUgY29tYmluYXRpb24gbWVjaGFuaXNtIGRlZmluZWQgaW4g UkZDIDcyMzAsIHRoZSB1Q0ROIE1BWSBoYXZlIHRvIGRldmlhdGUgZnJvbSB1c2luZyB0aGUgY29t YmluYXRpb24gbWVjaGFuaXNtIHdoZXJlIGFwcHJvcHJpYXRlLiBGb3IgZXhhbXBsZSwgaXQgTUFZ IG9ubHkgc2VuZCB0aGUgY29udGVudHMgb2YgdGhlIGZpcnN0IG9jY3VycmVuY2Ugb2YgdGhlIEhU VFAgSGVhZGVycyBpbnN0ZWFkLiINCg0KPiA+IChCRzgpIEluIHNlY3Rpb25zIDQuNS4xIGFuZCA0 LjUuMiwgdGhlcmUgaXMgbWVudGlvbmluZyBvZiB0aGUga2V5cw0KPiAic2MoPGhlYWRlcm5hbWU+ KSIgYW5kICJjcyg8aGVhZGVybmFtZT4pIi4gQXJlIHRoZXNlIHRoZSBzYW1lPyBJZiBzbywgdXNl IGENCj4gc2luZ2xlIGtleS4gSWYgbm90LCBleHBsYWluIHRoZWlyIGRpZmZlcmVuY2UuIChNYXli ZSB0aGlzIGhhcyBzb21ldGhpbmcgdG8gZG8NCj4gd2l0aCB0aGUgZGlyZWN0aW9uIHNlcnZlci0+ Y2xpZW50LCBjbGllbnQtPnNlcnZlci4pDQo+IA0KPiBDb3JyZWN0IGl0IGlzIGEgY29udmVudGlv biB0byBzaG93IHRoZSBkaXJlY3Rpb24gdGhlIGhlYWRlciBmaWVsZCB3YXMgcGFzc2VkLg0KPiAN Cj4gSSd2ZSBhZGRlZCB0aGUgZm9sbG93aW5nIHRleHQgdG8gZXhwbGFpbiB0aGVtDQo+ICAgIFRo ZSBkaWN0aW9uYXJ5IGtleXMgdXNlZCBpbiBIVFRQIFJlZGlyZWN0aW9uIHJlcXVlc3RzIGFuZCBy ZXNwb25zZXMNCj4gICAgdXNlIHRoZSBmb2xsb3dpbmcgY29udmVudGlvbnMgZm9yIHRoZWlyIHBy ZWZpeGVzOg0KPiANCj4gICAgbyAgYy0gaXMgcHJlZml4ZWQgdG8ga2V5cyBmb3IgaW5mb3JtYXRp b24gcmVsYXRlZCB0byB0aGUgQ2xpZW50IChVc2VyDQo+ICAgICAgIEFnZW50KS4NCj4gDQo+ICAg IG8gIGNzLSBpcyBwcmVmaXhlZCB0byBrZXlzIGZvciBpbmZvcm1hdGlvbiBwYXNzZWQgYnkgdGhl IENsaWVudCAoVXNlcg0KPiAgICAgICBBZ2VudCkgdG8gdGhlIFNlcnZlciAodUNETikuDQo+IA0K PiAgICBvICBzYy0gaXMgcHJlZml4ZWQgdG8ga2V5cyBmb3IgaW5mb3JtYXRpb24gdG8gYmUgcGFz c2VkIGJ5IHRoZSBTZXJ2ZXINCj4gICAgICAgKHVDRE4pIHRvIHRoZSBDbGllbnQgKFVzZXIgQWdl bnQpLg0KDQpUaGF0IGNsYXJpZmllcyBhIGxvdC4gVGhhbmtzIQ0KDQo+ID4gKEJHOSkgUmVsYXRl ZCB0byAoQkc4KTogaW4gdGhlIGxhc3QgbGluZSBvbiBwYWdlIDE2LCBzaG91bGQNCj4gImNzKDxo ZWFkZXJuYW1lPikiIGJlICJzYyg8aGVhZGVybmFtZT4pIj8NCj4gDQo+IEdvb2QgY2F0Y2ghDQo+ IA0KPiA+IChCRzEwKSBJIHByb3Bvc2UgdG8gbW9kaWZ5IGZpcnN0IHNlbnRlbmNlIGluIHNlY3Rp b24gNC42LCAiUkkgcmVzcG9uc2VzIG1heQ0KPiBiZSBjYWNoZWFibGUgYW5kIG1heSBiZSByZXVz ZWQgYnkgdGhlIHVDRE4gaW4gcmVzcG9uc2UgdG8gVXNlciBBZ2VudCByZXF1ZXN0cw0KPiB3aXRo b3V0IHRoZSB1Q0ROIGlzc3VpbmcgYW5vdGhlciBSSSByZXF1ZXN0IHRvIHRoZSBkQ0ROIGlmIHRo ZSBSSSByZXNwb25zZSBpcw0KPiBjb25zaWRlcmVkIGNhY2hhYmxlICYgbm90IHN0YWxlIGFjY29y ZGluZyB0byB0aGUgc3RhbmRhcmQgSFRUUCBDYWNoZS1Db250cm9sLA0KPiBldGMgbWVjaGFuaXNt cy4iIGFzIGZvbGxvd3M6ICJSSSByZXNwb25zZXMgbWF5IGJlIGNhY2hlYWJsZS4gQXMgbG9uZyBh cyBhDQo+IGNhY2hlZCBSSSByZXNwb25zZSBpcyBub3Qgc3RhbGUgYWNjb3JkaW5nIHRvIHN0YW5k YXJkIEhUVFAgQ2FjaGUtQ29udHJvbCBvcg0KPiBvdGhlciBhcHBsaWNhYmxlIG1lY2hhbmlzbXMs IGl0IG1heSBiZSByZXVzZWQgYnkgdGhlIHVDRE4gaW4gcmVzcG9uc2UgdG8gVXNlcg0KPiBBZ2Vu dCByZXF1ZXN0cyB3aXRob3V0IHNlbmRpbmcgYW5vdGhlciBSSSByZXF1ZXN0IHRvIHRoZSBkQ0RO LiINCj4gDQo+IERvbmUuDQo+IA0KPiA+IChCRzExKSBTZWN0aW9uIDQuNiBjb250YWlucyB0aGUg Zm9sbG93aW5nIHRleHQ6ICIoZXhjZXB0IGZvciB0aGUgYy1pcCBmaWVsZA0KPiBwcm92aWRlZCB0 aGUgVXNlciBBZ2VudCdzIGMtaXAgaXMgY292ZXJlZCBieSB0aGUgc2NvcGUgaW4gdGhlIG9yaWdp bmFsIFJJDQo+IHJlc3BvbnNlKSIuIFRoZSBzY29wZSBkaWN0aW9uYXJ5ICgiaXByYW5nZSIpIGlz IG9ubHkgZGVmaW5lZCBsYXRlciwgbWFraW5nIHRoZQ0KPiBzZW50ZW5jZSBjb25mdXNpbmcuIE1h eWJlIHJld29yZCBhcyBmb2xsb3dzOiAiKGV4Y2VwdCBmb3IgdGhlIGMtaXAgZmllbGQNCj4gcHJv dmlkZWQgdGhhdCB0aGUgVXNlciBBZ2VudCdzIGMtaXAgaXMgY292ZXJlZCBieSB0aGUgc2NvcGUg aW4gdGhlIG9yaWdpbmFsIFJJDQo+IHJlc3BvbnNlLCBhcyBlbGFib3JhdGVkIHVwb24gYmVsb3cp Ii4NCj4gDQo+IERvbmUuDQo+IA0KPiA+IChCRzEyKSBUaGUgc2Vjb25kIGV4YW1wbGUgb24gcGFn ZSA5IGluIGhhcyB0d28gIm1heC1hZ2UiIGZpZWxkczogb25lIGluIHRoZQ0KPiBoZWFkZXIgKCJt YXgtYWdlPTYwIikgYW5kIG9uZSBpbiB0aGUgYm9keSAoIm1heC1hZ2U9MzAiKS4gVGhlIGZvcm1l ciBtdXN0IGJlDQo+IG1lYW50IGZvciB0aGUgdUNETiwgd2hlcmVhcyB0aGUgbGF0dGVyIGlzIG1l YW50IGZvciB0aGUgVUEuIE1heWJlIGl0IHdvdWxkIGJlDQo+IGdvb2QgdG8gYWRkIHRoZSBmb2xs b3dpbmcgdGV4dCBhZnRlciAiRXhhbXBsZSBvZiBIVFRQIHJlZGlyZWN0aW9uIHJlc3BvbnNlDQo+ IGZyb20gU2VjdGlvbiA0LjUuMiB0aGF0IGlzIGNhY2hlYWJsZSBieSB0aGUgdUNETiBmb3IgNjAg c2Vjb25kcyBhbmQgY2FuIGJlDQo+IHJldHVybmVkIHRvIGFueSBVc2VyIEFnZW50IHdpdGggYW4g SVB2NCBhZGRyZXNzIGluIDE5OC41MS4xMDAuMC8yNC4iOiAiTm90aWNlDQo+IHRoYXQgdGhlIHJl c3BvbnNlIHRvIHRoZSBVQSBpcyBvbmx5IHZhbGlkIGZvciAzMCBzZWNvbmRzLCB3aGVyZWFzIHRo ZSB1Q0ROIGNhbg0KPiBjYWNoZSB0aGUgUkkgcmVzcG9uc2UgZm9yIDYwIHNlY29uZHMuIg0KPiAN Cj4gRG9uZS4NCj4gDQo+ID4gKEJHMTMpIEluIHRoZSBzZWNvbmQgdGFibGUgaW4gc2VjdGlvbiA0 LjcsIG9uIHBhZ2UgMjIsIHRoZXJlIGlzIHRoZSB0ZXh0DQo+ICI8cmVhc29uPiIgZm9yIGNvZGVz IDEwMCwgNDAwLCBhbmQgNTAwLiBGcm9tIHRoZSBJQU5BIGNvbnNpZGVyYXRpb25zIHNlY3Rpb24s DQo+IGl0IGxhdGVyIGJlY29tZXMgY2xlYXIgdGhhdCB0aGlzICI8cmVhc29uPiIgaXMgYWN0dWFs bHkgdGhlIHZhbHVlIG9mIHRoZQ0KPiAicmVhc29uIiBzdHJpbmcgaW4gdGhlIGVycm9yIGluZm9y bWF0aW9uLiBIb3dldmVyLCB0aGF0IGlzIG5vdCBjbGVhciBmcm9tIHRoZQ0KPiB0YWJsZS4gSSB0 aGluayBpdCB3b3VsZCBiZSBnb29kIHRvIGNsYXJpZnkgdGhpcyBhbHJlYWR5IGluIHNlY3Rpb24g NC43Lg0KPiANCj4gRG9uZS4gSSBhZGRlZCB0aGUgZm9sbG93aW5nIHRleHQgYWJvdmUgdGhlIHRh YmxlOg0KPiANCj4gICAgRXJyb3IgY29kZXMgd2l0aCBhICJSZWFzb24iIG9mICI8cmVhc29uPiIg ZG8gbm90IGhhdmUgYSBkZWZpbmVkIHZhbHVlDQo+ICAgIGZvciB0aGVpciAncmVhc29uJy1rZXku ICBEZXBlbmRpbmcgb24gdGhlIGVycm9yLWNvZGUgc2VtYW50aWNzLCB0aGUNCj4gICAgdmFsdWUg b2YgdGhpcyBmaWVsZCBtYXkgYmUgZGV0ZXJtaW5lZCBkeW5hbWljYWxseS4NCj4gDQo+ID4gKEJH MTQpIEluIHNlY3Rpb24gNC44LCB0aGVyZSBpcyB0aGUgZm9sbG93aW5nIHRleHQgKEEpIGFib3V0 IHRoZSBtYXgtaG9wcw0KPiB2YWx1ZTogIlRyYW5zaXQgQ0ROcyBNVVNUIE5PVCBwcm9wYWdhdGUg dG8gYW55IGRvd25zdHJlYW0gQ0ROcyBpZiB0aGUgbnVtYmVyDQo+IG9mIENETiBQcm92aWRlciBJ RHMgaW4gY2RuLXBhdGggaXMgZXF1YWwgdG8gb3IgZ3JlYXRlciB0aGFuIG1heC1ob3BzLiIgSW4N Cj4gYWRkaXRpb24sIHRoZXJlIGlzIHRoZSB0ZXh0IChCKTogIklmIGEgZG93bnN0cmVhbSBDRE4g cmVjZWl2ZXMgYSBSSSByZXF1ZXN0DQo+IHdoZXJlIHRoZSBudW1iZXIgb2YgQ0ROIFByb3ZpZGVy IElEcyBpbiBjZG4tcGF0aCBpcyBncmVhdGVyIHRoYW4gbWF4LWhvcHMsIHRoZQ0KPiBkb3duc3Ry ZWFtIENETiBTSE9VTEQgc2VuZCBhIFJJIHJlc3BvbnNlIHdpdGggYW4gZXJyb3IgY29kZSBvZiA1 MDMuIi4gVGV4dCAoQikNCj4gc2VlbXMgdG8gaW5kaWNhdGUgdGhhdCB0aGUgdmFsdWVzIG9mIG1h eC1ob3BzIC8gY2RuLXBhdGggYXJlIGNoZWNrZWQgdXBvbg0KPiByZWNlaXB0IG9mIHRoZSBtZXNz YWdlLCBub3QgYmVmb3JlIHNlbmRpbmcgaXQuIFRodXMsIGlmIG1heC1ob3BzID0gMSwgdGhlDQo+ IGZpcnN0IGRDRE4gY2FuIHByb3BhZ2F0ZSB0aGUgUkkgcmVxdWVzdCwgYnV0IHRoZSBzZWNvbmQg Y2Fubm90LiBUaGF0IG1lYW5zDQo+IHRoYXQgaW4gdGV4dCAoQSksIHRoZSBjZG4tcGF0aCBpcyBl dmFsdWF0ZWQgX2JlZm9yZV8gdGhlIGRDRE4gYWRkcyBpdHMgb3duDQo+IFByb3ZpZGVyIElELiBJ IHByb3Bvc2UgdG8gd3JpdGUgdGhpcyBleHBsaWNpdGx5LCBhbmQgdGh1cyByZXBocmFzZSAoQSkg YXMNCj4gZm9sbG93czogIlRyYW5zaXQgQ0ROcyBNVVNUIE5PVCBwcm9wYWdhdGUgdG8gYW55IGRv d25zdHJlYW0gQ0ROcyBpZiB0aGUgbnVtYmVyDQo+IG9mIENETiBQcm92aWRlciBJRHMgaW4gY2Ru LXBhdGggKGJlZm9yZSBhZGRpbmcgaXRzIG93biBQcm92aWRlciBJRCkgaXMgZXF1YWwNCj4gdG8g b3IgZ3JlYXRlciB0aGFuIG1heC1ob3BzLiINCj4gDQo+IERvbmUuDQo+IA0KPiBUaGFua3MNCj4g QmVuDQo+IA0KPiA+DQo+ID4NCj4gPiBCZXJ0IEdyZWV2ZW5ib3NjaA0KPiA+IEh1YXdlaSBUZWNo bm9sb2dpZXMgQ28uLCBMdGQuDQo+ID4NCj4gPiBiZXJ0LmdyZWV2ZW5ib3NjaEBodWF3ZWkuY29t DQo+ID4NCj4gPiBIdWF3ZWkgSW5kdXN0cmlhbCBCYXNlIEYxLTgNCj4gPiBCYW50aWFuLCBMb25n Z2FuZyBEaXN0cmljdA0KPiA+IFNoZW56aGVuIDUxODEyOQ0KPiA+IFAuUi4gQ2hpbmENCj4gPg0K PiA+IGh0dHA6Ly93d3cuaHVhd2VpLmNvbQ0KPiA+ILG+08q8/rywxuS4vbz+uqzT0Luqzqq5q8u+ tcSxo8Pc0MXPoqOsvfbP3tPat6LLzbj4yc/D5rXY1rfW0MHQs/a1xLj2yMu78si61+mho737DQo+ ID4g1rnIzrrOxuTL+8jL0tTIzrrO0M7Kvcq508OjqLD8wKi1q7K7z97T2sirsr+78rK/t9a12NC5 wrahori01sahorvyyaK3oqOpsb7Tyrz+1tANCj4gPiC1xNDFz6Kho8jnufvE+rTtytXBy7G+08q8 /qOsx+vE+sGivLS157uwu/LTyrz+zajWqreivP7Iy7Kiyb6z/bG+08q8/qOhDQo+ID4gVGhpcyBl LW1haWwgYW5kIGl0cyBhdHRhY2htZW50cyBjb250YWluIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlv biBmcm9tIEhVQVdFSSwNCj4gd2hpY2gNCj4gPiBpcyBpbnRlbmRlZCBvbmx5IGZvciB0aGUgcGVy c29uIG9yIGVudGl0eSB3aG9zZSBhZGRyZXNzIGlzIGxpc3RlZCBhYm92ZS4gQW55DQo+IHVzZSBv ZiB0aGUNCj4gPiBpbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWluIGluIGFueSB3YXkgKGluY2x1 ZGluZywgYnV0IG5vdCBsaW1pdGVkIHRvLA0KPiB0b3RhbCBvciBwYXJ0aWFsDQo+ID4gZGlzY2xv c3VyZSwgcmVwcm9kdWN0aW9uLCBvciBkaXNzZW1pbmF0aW9uKSBieSBwZXJzb25zIG90aGVyIHRo YW4gdGhlDQo+IGludGVuZGVkDQo+ID4gcmVjaXBpZW50KHMpIGlzIHByb2hpYml0ZWQuIElmIHlv dSByZWNlaXZlIHRoaXMgZS1tYWlsIGluIGVycm9yLCBwbGVhc2UNCj4gbm90aWZ5IHRoZSBzZW5k ZXIgYnkNCj4gPiBwaG9uZSBvciBlbWFpbCBpbW1lZGlhdGVseSBhbmQgZGVsZXRlIGl0IQ0KPiA+ DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g PiBDRE5pIG1haWxpbmcgbGlzdA0KPiA+IENETmlAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NkbmkNCg0K From nobody Wed Dec 10 02:55:11 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 894981A19F8 for ; Wed, 10 Dec 2014 02:55:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sSf_0osV_DbW for ; Wed, 10 Dec 2014 02:55:06 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id 0B9651A03A3 for ; Wed, 10 Dec 2014 02:55:06 -0800 (PST) Received: from host4.velocix.com ([81.134.152.4] helo=xxx.corp.velocix.com) by smtp04.mailcore.me with esmtpa (Exim 4.80.1) (envelope-from ) id 1XyevA-0005Md-Uq; Wed, 10 Dec 2014 10:55:05 +0000 Content-Type: text/plain; charset=GB2312 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Niven-Jenkins In-Reply-To: <46A1DF3F04371240B504290A071B4DB66CB0F9EB@SZXEMA510-MBX.china.huawei.com> Date: Wed, 10 Dec 2014 10:54:56 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <1274E18B-94D5-48B9-A6C5-71DFA777FDC6@niven-jenkins.co.uk> References: <46A1DF3F04371240B504290A071B4DB66CA9F356@SZXEMA510-MBX.china.huawei.com> <46A1DF3F04371240B504290A071B4DB66CB0F9EB@SZXEMA510-MBX.china.huawei.com> To: Bert Greevenbosch X-Mailer: Apple Mail (2.1878.6) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/2ixD_1NTQWn5xELbj5GsRnL-HPs Cc: "cdni@ietf.org" , "draft-ietf-cdni-redirection@tools.ietf.org" Subject: Re: [CDNi] Review of draft-ietf-cdni-redirection-05 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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, 10 Dec 2014 10:55:08 -0000 Bert, On 10 Dec 2014, at 01:07, Bert Greevenbosch = wrote: >>> (BG5) Do the 'a' and 'aaaa' fields point at the same RTs? (I notice = in the >> examples that the number of elements in the 'a' and 'aaaa' fields are = equal, >> which may mean that for each element in a there is a related element = in >> 'aaaa'.) I guess this is not the case, but want to make sure. >>=20 >> The A and AAAA fields do not have to be equal sized lists or point at = the same >> RTs. >=20 > Maybe remove one of the IPv4 addresses from the example? I added an extra IPv4 address instead but the effect is the same (the = example has different length lists for a and aaaa). >>> (BG7) Section 4.5.1: "In the case where the User Agent request = includes >> multiple HTTP header fields with the same field-name, it is up to the = uCDN to >> determine how to handle this. One option would be to only send the = contents of >> the first occurrence of that HTTP Header in the User Agent Request. = Another >> would be to combine the different HTTP Headers into a single value = according >> to Section 3.2.2 of [RFC7230]." The text in RFC 7230 says that such = combined >> header field is semantically equivalent to the separated headers = fields. >> However, here we allow different handling for such equivalent = encodings. Maybe >> we should mandate that the Headers need to be combined into a single = value, or >> at least use a SHOULD? >>=20 >> Unfortunately use of HTTP header fields in the wild is inconsistent = for some >> headers fields, so it is really dependent on which header fields the = uCDN is >> passing on as to what the best behaviour might be so we can't be too = specific >> and have to rely on the uCDN knowing what they are passing on. >=20 > Yes, but still there is an inconsistency with RFC 7230. I would opt = for a SHOULD or RECOMMENDED, e.g. change the text to: >=20 > "In the case where the User Agent request includes multiple HTTP = header fields with the same field-name, it is RECOMMENDED that the uCDN = combines these different HTTP headers into a single value according to = Section 3.2.2 of [RFC7230]. However, because of the plurality of already = defined HTTP header fields, and inconsistency of some of these header = fields concerning the combination mechanism defined in RFC 7230, the = uCDN MAY have to deviate from using the combination mechanism where = appropriate. For example, it MAY only send the contents of the first = occurrence of the HTTP Headers instead." Thanks. I changed the text to what you provided above. Ben From nobody Wed Dec 10 03:25:44 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21CF71A701A for ; Wed, 10 Dec 2014 03:25:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wqEBbzsYBis4 for ; Wed, 10 Dec 2014 03:25:40 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id 9BD831A1A0F for ; Wed, 10 Dec 2014 03:25:40 -0800 (PST) Received: from host4.velocix.com ([81.134.152.4] helo=xxx.corp.velocix.com) by smtp04.mailcore.me with esmtpa (Exim 4.80.1) (envelope-from ) id 1XyfOl-0001IA-BL; Wed, 10 Dec 2014 11:25:39 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Niven-Jenkins In-Reply-To: <68814413-8671-4A03-A274-CE89BD3AC4BD@cisco.com> Date: Wed, 10 Dec 2014 11:25:34 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <92C4A6BD-F61F-4019-AE12-A8F86D1BF3A8@niven-jenkins.co.uk> References: <20141025081441.2004.72206.idtracker@ietfa.amsl.com> <0D8B12F8-40E1-4D19-944F-4BC0C7D64972@niven-jenkins.co.uk> <68814413-8671-4A03-A274-CE89BD3AC4BD@cisco.com> To: Francois Le Faucher , Kevin Ma J X-Mailer: Apple Mail (2.1878.6) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/0QHy9i7J1KqwhTq1S7m1MhF3DPw Cc: "draft-ietf-cdni-redirection@tools.ietf.org" , "cdni@ietf.org" Subject: [CDNi] Mandating support for TLS in draft-ietf-cdni-redirection X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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, 10 Dec 2014 11:25:42 -0000 Francois, Kevin & Colleagues, As part of reviewing draft-ietf-cdni-redirection it has been suggested = to mandate the use of TLS and to mandate support for some cipher suite. I am against such a change. The RI interface document lays out in the security considerations = section the threats and then recommends (SHOULD) secure and = authenticated communication. I have changed that to a MUST in the latest draft which now reads In order to prevent passive interception of RI messages the RI communications channel MUST be suitably secured (e.g. use of TLS). In order to reduce the risk of information leakage to unauthorized parties, RI clients and servers MUST use suitable authentication prior to trusting the contents of RI messages. which I believe to be sufficient. I am against mandating TLS as it is not the only mechanism available for = securing the redirection interface, e.g. CDNs may use IPSec tunnels and = run the RI over them. The document already suggests TLS by example and = defines that the RI MUST run over a suitably secured & authenticated = channel. Mandating TLS adds nothing extra to the specification except = inflexibility for deployers. Likewise recommending a particular cipher suite seems problematic as we = are not security experts and the recommended suite may change over time = forcing a need to update the RFC just to update the advice on cipher = suites. Better to have the deployer follow the current best practice for = the secure channel they choose to deploy over IMO. If the consensus of the working group is that we should mandate a = specific secure channel and/or a specific cipher suite, I'm OK to be = declared in the rough and make the necessary editorial changes. But I do = believe we're better off not going there and leaving it to deployers to = decide what is most appropriate for their environment. Ben From nobody Fri Dec 12 02:45:21 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 339331ACCE2; Fri, 12 Dec 2014 02:45:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJp2lAAKLq0q; Fri, 12 Dec 2014 02:45:15 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CF64B1ACC92; Fri, 12 Dec 2014 02:45:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141212104514.27904.20407.idtracker@ietfa.amsl.com> Date: Fri, 12 Dec 2014 02:45:14 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/qJg_hqxsA1iaz0p-tdPfKFwXv2E Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-redirection-06.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 10:45:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Content Delivery Networks Interconnection Working Group of the IETF. Title : Request Routing Redirection Interface for CDN Interconnection Authors : Ben Niven-Jenkins Ray van Brandenburg Filename : draft-ietf-cdni-redirection-06.txt Pages : 30 Date : 2014-12-12 Abstract: The Request Routing Interface comprises of (1) the asynchronous advertisement of footprint and capabilities by a downstream CDN that allows an upstream CDN to decide whether to redirect particular user requests to that downstream CDN; and (2) the synchronous operation of an upstream CDN requesting whether a downstream CDN is prepared to accept a user request and of a downstream CDN responding with how to actually redirect the user request. This document describes an interface for the latter part, i.e. the CDNI Request Routing Redirection interface. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-redirection/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-cdni-redirection-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-redirection-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Dec 12 02:47:29 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A7BB1ACCD9 for ; Fri, 12 Dec 2014 02:47:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GiB7Afu_Qxy7 for ; Fri, 12 Dec 2014 02:47:25 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id 8D3E11ACC92 for ; Fri, 12 Dec 2014 02:47:25 -0800 (PST) Received: from cpc4-cmbg17-2-0-cust814.5-4.cable.virginm.net ([86.14.227.47] helo=[192.168.0.3]) by smtp04.mailcore.me with esmtpa (Exim 4.80.1) (envelope-from ) id 1XzNkq-0005pt-9T for cdni@ietf.org; Fri, 12 Dec 2014 10:47:24 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Niven-Jenkins In-Reply-To: <20141212104514.27904.20407.idtracker@ietfa.amsl.com> Date: Fri, 12 Dec 2014 10:47:23 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <5B6DDF2D-9117-422A-BD3B-2CE652C0A063@niven-jenkins.co.uk> References: <20141212104514.27904.20407.idtracker@ietfa.amsl.com> To: cdni@ietf.org X-Mailer: Apple Mail (2.1878.6) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/zHfvRA8JTUKCobETBXcl9YTDuzk Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-redirection-06.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 10:47:28 -0000 Colleagues, This version incorporates the edits resulting from Francois', Kevin's & = Bert's reviews. Ben On 12 Dec 2014, at 10:45, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Content Delivery Networks = Interconnection Working Group of the IETF. >=20 > Title : Request Routing Redirection Interface for CDN = Interconnection > Authors : Ben Niven-Jenkins > Ray van Brandenburg > Filename : draft-ietf-cdni-redirection-06.txt > Pages : 30 > Date : 2014-12-12 >=20 > Abstract: > The Request Routing Interface comprises of (1) the asynchronous > advertisement of footprint and capabilities by a downstream CDN that > allows an upstream CDN to decide whether to redirect particular user > requests to that downstream CDN; and (2) the synchronous operation = of > an upstream CDN requesting whether a downstream CDN is prepared to > accept a user request and of a downstream CDN responding with how to > actually redirect the user request. This document describes an > interface for the latter part, i.e. the CDNI Request Routing > Redirection interface. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-cdni-redirection/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-cdni-redirection-06 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-redirection-06 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From nobody Mon Dec 29 03:47:16 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 601F21A036B; Mon, 29 Dec 2014 03:47:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E_heTwtv314O; Mon, 29 Dec 2014 03:47:08 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7441A036C; Mon, 29 Dec 2014 03:46:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141229114647.7621.55315.idtracker@ietfa.amsl.com> Date: Mon, 29 Dec 2014 03:46:47 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/QKfmdaHV4xJTz8gLhOjjym6FRag Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-control-triggers-05.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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, 29 Dec 2014 11:47:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Content Delivery Networks Interconnection Working Group of the IETF. Title : CDNI Control Interface / Triggers Authors : Rob Murray Ben Niven-Jenkins Filename : draft-ietf-cdni-control-triggers-05.txt Pages : 42 Date : 2014-12-29 Abstract: This document describes the part of the CDN Interconnection Control Interface that allows a CDN to trigger activity in an interconnected CDN that is configured to deliver content on its behalf. The upstream CDN can use this mechanism to request that the downstream CDN pre-positions metadata or content, or that it invalidates or purges metadata or content. The upstream CDN can monitor the status of activity that it has triggered in the downstream CDN. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-control-triggers/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-cdni-control-triggers-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-control-triggers-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Dec 29 03:52:10 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B30A1A0393 for ; Mon, 29 Dec 2014 03:52:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qJNxsz0WmyJB for ; Mon, 29 Dec 2014 03:52:03 -0800 (PST) Received: from owa.velocix.com (mail-out1.velocix.com [81.134.152.10]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 388CC1A038E for ; Mon, 29 Dec 2014 03:51:48 -0800 (PST) Received: from EXB04CAM.corp.velocix.com ([169.254.1.180]) by EXC00CAM.corp.velocix.com ([172.18.4.40]) with mapi id 14.02.0347.000; Mon, 29 Dec 2014 11:51:46 +0000 From: Rob Murray To: "cdni@ietf.org" Thread-Topic: [CDNi] I-D Action: draft-ietf-cdni-control-triggers-05.txt Thread-Index: AQHQI13Snhyl5sf91Ua8F8QvHgNquA== Date: Mon, 29 Dec 2014 11:51:45 +0000 Message-ID: <7FDC0CFB-3546-46A9-B3F9-8880EA3CD1F0@velocix.com> References: <20141229114647.7621.55315.idtracker@ietfa.amsl.com> In-Reply-To: <20141229114647.7621.55315.idtracker@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.225.117.228] Content-Type: text/plain; charset="utf-8" Content-ID: <2B264A6759869741AACD3519D73F4A45@velocix.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/5KmcobzGtMh9RiTtYowYECCkK3c Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-control-triggers-05.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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, 29 Dec 2014 11:52:07 -0000 SGkgYWxsLCBJJ3ZlIHBvc3RlZCBhIG5ldyB2ZXJzaW9uIG9mIHRoZSBUcmlnZ2VycyBkcmFmdCB0 byBhZGRyZXNzIGNvbW1lbnRzIGZyb20gUmF5IGFuZCBGcmFuY29pcyAtIGRldGFpbGVkIHJlcGxp ZXMgdG8gdGhvc2UgdHdvIHNldHMgb2YgY29tbWVudHMgYXJlIGJlbG93Lg0KDQpDaGVlcnMsDQpS b2IuDQoNCg0KPiBPbiAxMCBOb3YgMjAxNCwgYXQgMTM6MTIsIEJyYW5kZW5idXJnLCBSLiAoUmF5 KSB2YW4gPHJheS52YW5icmFuZGVuYnVyZ0B0bm8ubmw+IHdyb3RlOg0KPiANCj4gSGkgUm9iLCBC ZW4sIA0KPiANCj4gSeKAmXZlIHJldmlld2VkIHRoZSBsYXRlc3QgdmVyc2lvbiBvZiB0aGUgZHJh ZnQtaWV0Zi1jZG5pLWNvbnRyb2wtdHJpZ2dlcnMgZG9jdW1lbnQuIChTb3JyeSBmb3IgbWlzc2lu ZyB0aGUgZGVhZGxpbmUgYnkgYSBkYXkgOykgKQ0KPiANCj4gSW4gZ2VuZXJhbCwgSSB0aGluayB0 aGUgZG9jdW1lbnQgaXMgaW4gYSBnb29kIHN0YXRlIGFuZCBhbG1vc3QgcmVhZHkgdG8gYmUgc2Vu dCB0byB0aGUgSUVTRy4gSeKAmXZlIGdvdCBhIGZldyBjb21tZW50czoNCj4gLSBJbiBzZWN0aW9u IDUuMi4yLCBpdCBzYXlzIHVuZGVyIOKAmHB1cmdl4oCZLCAg4oCcQWZ0ZXIgc2VydmljaW5nIHRo ZSByZXF1ZXN0LCB0aGUgc3BlY2lmaWVkIGRhdGEgTVVTVCBOT1QgYmUgaGVsZCBvbiB0aGUgZENE Ti7igJ0gSSB0aGluayB3ZSBhZ3JlZSBvbiB3aGF0IHB1cmdlIHNob3VsZCBkbywgYnV0IHRoaXMg c2VudGVuY2UgbWlnaHQgbm90IGJlIHRoZSBiZXN0IHJlcHJlc2VudGF0aW9uIG9mIHRoYXQuIE1h eWJlIGl0IHdvdWxkIGJlIGJldHRlciB0byBmb3JtdWxhdGUgaXQgYWxvbmcgdGhlIGxpbmVzIG9m IOKAmEFmdGVyIHNlcnZpY2luZyB0aGUgcmVxdWVzdCwgdGhlIHNwZWNpZmllZCBkYXRhIE1VU1Qg YmUgaW52YWxpZGF0ZWQgb24gdGhlIGRDRE7igJ0sIG9yIGV2ZW4gYmV0dGVyIOKAnEFmdGVyIHNl cnZpY2luZyB0aGUgcmVxdWVzdCwgdGhlIGRDRE4gTVVTVCByZWplY3QgYW55IGZ1dHVyZSByZXF1 ZXN0cyBmb3IgdGhlIHNwZWNpZmllZCBkYXRh4oCdLiAgIA0KDQpJbnZhbGlkYXRlIGFuZCBwdXJn ZSBhcmUgZGlmZmVyZW50IC0gaW4gc2VjdGlvbiAyIGl0IHNheXMgLi4uDQoNCiAgLSBpbnZhbGlk YXRlIC0gdXNlZCB0byBpbnN0cnVjdCB0aGUgZENETiB0byByZXZhbGlkYXRlIHNwZWNpZmljIG1l dGFkYXRhIG9yIGNvbnRlbnQgYmVmb3JlIHJlLXVzaW5nIGl0Lg0KICAtIHB1cmdlIC0gdXNlZCB0 byBpbnN0cnVjdCB0aGUgZENETiB0byBkZWxldGUgc3BlY2lmaWMgbWV0YWRhdGEgb3IgY29udGVu dC4NCg0KU28sIGZvciBwdXJnZSwgInRoZSBzcGVjaWZpZWQgZGF0YSBNVVNUIGJlIGludmFsaWRh dGVkIG9uIHRoZSBkQ0ROIiB3b3VsZG4ndCBiZSB3aGF0IEkgaW50ZW5kZWQgLSB0aGUgZGF0YSBp cyBhY3R1YWxseSBzdXBwb3NlZCB0byBiZSBkZWxldGVkLg0KDQpTaW1pbGFybHkgd2hlbiBjb250 ZW50IGlzIHB1cmdlZCAtIEkgZG9uJ3QgdGhpbmsgInRoZSBkQ0ROIE1VU1QgcmVqZWN0IGFueSBm dXR1cmUgcmVxdWVzdHMgZm9yIHRoZSBzcGVjaWZpZWQgZGF0YSIgd291bGQgYmUgcXVpdGUgcmln aHQuLi4gdGhlIGRDRE4gc2hvdWxkbid0IGp1c3QgcmVqZWN0IHJlcXVlc3RzLCBpdCBzaG91bGQg YXR0ZW1wdCB0byByZS1hY3F1aXJlIGZyb20gdGhlIHVDRE4uDQoNClNvIEkndmUgYWRkZWQgIih0 aGUgZENETiBzaG91bGQgcmUtYWNxdWlyZSB0aGUgbWV0YWRhdGEgb3IgY29udGVudCBmcm9tIHVD RE4gaWYgaXQgbmVlZHMgaXQpLiIgdG8gc2VjdGlvbiA1LjIuMiAtIGRvZXMgdGhhdCBjb3ZlciBp dD8NCg0KPiAtIE9uIHRoZSBzYW1lIHNlY3Rpb246IGRvIHlvdSB3YW50IHRvIHNheSBhbnl0aGlu ZyBhYm91dCBvbmdvaW5nIHRyYW5zZmVycyBvZiB0aGUgc3BlY2lmaWVkIGRhdGE/IEFyZSB0aGVz ZSB0byBiZSB0ZXJtaW5hdGVkPw0KDQpJJ3ZlIGFkZGVkIHRoaXMgdG8gc2VjdGlvbiAyLjEgIlRp bWluZyBvZiBUcmlnZ2VyZWQgQWN0aXZpdHkiIC4uLg0KDQoiQmVjYXVzZSB0aGUgQ0kvVCBDb21t YW5kIHRpbWluZyBpcyB1bmRlciB0aGUgZENETidzIGNvbnRyb2wsIHRoZSBkQ0ROIGltcGxlbWVu dGF0aW9uIGNhbiBjaG9vc2Ugd2hldGhlciB0byBhcHBseSBDSS9UIGludmFsaWRhdGUgYW5kIHB1 cmdlIGNvbW1hbmRzIHRvIGNvbnRlbnQgYWNxdWlzaXRpb24gdGhhdCBoYXMgYWxyZWFkeSBzdGFy dGVkIHdoZW4gdGhlIGNvbW1hbmQgaXMgcmVjZWl2ZWQuIg0KDQo+IC0gVGhlIHNlY3VyaXR5IGNv bnNpZGVyYXRpb25zIHNlY3Rpb24gbW9zdGx5IGRpc2N1c3NlcyBzb2x1dGlvbnMsIGJ1dCBkb2Vz buKAmXQgcHJlc2VudCB0aGUgcG90ZW50aWFsIHJpc2tzLiBBcyBhbiBleGFtcGxlOiBXaGlsZSBJ IGFwcHJlY2lhdGUgeW91IG1hbmRhdGluZyB0aGUgZENETiB0byBzdXBwb3J0IFRMUywgdGhlIGZh Y3QgdGhhdCB5b3UgZG9u4oCZdCBtYW5kYXRlIGl0cyB1c2UgSSB0aGluayByZXF1aXJlcyB5b3Ug dG8gYXQgbGVhc3QgbGlzdCB0aGUgcG90ZW50aWFsIHJpc2tzIG9mIG5vdCBkb2luZyBzby4gSSBp bWFnaW5lIGhhdmluZyBzb21lIGVudGl0eSBzZW5kcyBpbGxlZ2l0aW1hdGUgcHVyZ2UgcmVxdWVz dHMgY2FuIGhhdmUgcXVpdGUgYW4gaW1wYWN0IG9uIHRoZSBDRE5zLCBhbmQgaXQgd291bGRu4oCZ dCBodXJ0IHBvaW50aW5nIG91dCB0aGVzZSBpc3N1ZXMuIEVzcGVjaWFsbHkgc2luY2UgdGhpcyBu b3Qgb25seSBpbXBhY3RzIHRoZSBkQ0ROLCBidXQgdGhlIHVDRE4gYXMgd2VsbCwgc2luY2UgdGhl IGRDRE4gd2lsbCBoYXZlIHRoZSByZS1mZXRjaCB0byBjb250ZW50LiBUaGUgc2FtZSBnb2VzIGZv ciBoYXZpbmcgYSB0aGlyZCBwYXJ0eSBzZW5kIG1ldGFkYXRhIGludmFsaWRhdGlvbiByZXF1ZXN0 cy4gDQoNCkFkZGVkICJUaGlzIGlzIGludGVuZGVkIHRvIHByZXZlbnQgdW5hdXRob3Jpc2VkIHVz ZXJzIGZyb20gZ2VuZXJhdGluZyB1bm5lY2Vzc2FyeSBsb2FkIGluIGRDRE4gb3IgdUNETiBkdWUg dG8gcmV2YWxpZGF0aW9uLCByZWFjcXVpc2l0aW9uLCBvciB1bm5lY2Vzc2FyeSBhY3F1aXNpdGlv bi4iDQoNCj09PT0NCg0KPiBPbiAxMCBOb3YgMjAxNCwgYXQgMjE6MDEsIEZyYW5jb2lzIExlIEZh dWNoZXVyIChmbGVmYXVjaCkgPGZsZWZhdWNoQGNpc2NvLmNvbT4gd3JvdGU6DQo+IA0KPiBGb2xr cywNCj4gDQo+IChhcyBhbiBpbmRpdmlkdWFsIGNvbnRyaWJ1dG9yKQ0KPiANCj4gQmVsb3cgYXJl IG15IGJlbGF0ZWQgY29tbWVudHMuDQo+IEkgaG9wZSB0aGlzIGlzIHVzZWZ1bC4NCj4gDQo+IEZy YW5jb2lzDQo+IA0KPiANCj4gKioqIDI6DQo+IOKAnA0KPiBBIHRyaWdnZXIsIHNlbnQgZnJvbSB0 aGUgdUNETiB0byB0aGUgZENETiwgaXMgYSByZXF1ZXN0IGZvciB0aGUgZENETg0KPiAgICB0byBk byBzb21lIHdvcmsgcmVsYXRpbmcgdG8gZGF0YSBvcmlnaW5hdGluZyBmcm9tIHRoZSB1Q0ROLg0K PiDigJwNCj4gd2VsbCwgd2hlbiB0aGUgdHJpZ2dlciBhcHBsaWVzIHRvIGNvbnRlbnQsIHRoZSBj b250ZW50IG1heSBvcmlnaW5hdGUgZnJvbSB0aGUgdUNETiBvciBpdCBtYXkgb3JpZ2luYXRlIGZy b20gc29tZXdoZXJlIGVsc2UuDQo+IEhvdyBhYm91dCB0aGUgZm9sbG93aW5nPyA6DQo+IOKAnA0K PiBBIHRyaWdnZXIsIHNlbnQgZnJvbSB0aGUgdUNETiB0byB0aGUgZENETiwgaXMgYSByZXF1ZXN0 IGZvciB0aGUgZENETg0KPiAgICB0byBkbyBzb21lIHdvcmsgcmVsYXRpbmcgdG8gZGF0YSBhc3Nv Y2lhdGVkIHdpdGggY29udGVudCByZXF1ZXN0cyBvcmlnaW5hdGluZyBmcm9tIHRoZSB1Q0ROLg0K PiDigJwNCg0KRG9uZS4NCg0KPiAqKiogMjoNCj4gIlRoZSBkQ0ROIG1haW50YWlucyBhIGNvbGxl Y3Rpb24gb2YgVHJpZ2dlciBTdGF0dXMgUmVzb3VyY2VzIGZvciBlYWNoDQo+ICAgIHVDRE4sIGVh Y2ggdUNETiBvbmx5IGhhcyBhY2Nlc3MgdG8gaXRzIG93biBjb2xsZWN0aW9uIGFuZCB0aGUNCj4g ICAgbG9jYXRpb24gb2YgdGhhdCBjb2xsZWN0aW9uIGlzIHNoYXJlZCB3aGVuIENETiBpbnRlcmNv bm5lY3Rpb24gaXMNCj4gICAgZXN0YWJsaXNoZWQu4oCdDQo+IFNob3VsZCB3ZSBwcmV2ZW50IGEg cGFpciBvZiB1Q0ROIGFuZCBkQ0ROIHRvIHVzZSBtb3JlIHRoYW4gMSBjb2xsZWN0aW9uPw0KPiBm b3IgZXhhbXBsZSwgZG8gd2Ugd2FudCB0byBwcmV2ZW50IHRoYXQgYSBkQ0ROIG9mZmVycyBhIHNl cGFyYXRlIGNvbGxlY3Rpb24gZm9yIHNlcGFyYXRlIOKAnENJIGVuZHBvaW50c+KAnSB3aXRoaW4g dGhlIHVDRE4/DQo+IEkgdGhpbmsgd2UgZG9u4oCZdCBuZWVkIHRvIHByZXZlbnQgdGhhdC4NCj4g U28gcGVyaGFwcyByZXBocmFzZSBpbnRvOg0KPiAiVGhlIGRDRE4gbWFpbnRhaW5zIChhdCBsZWFz dCkgb25lIGNvbGxlY3Rpb24gb2YgVHJpZ2dlciBTdGF0dXMgUmVzb3VyY2VzIGZvciBlYWNoDQo+ ICAgIHVDRE4uIEVhY2ggdUNETiBvbmx5IGhhcyBhY2Nlc3MgdG8gaXRzIG93biBjb2xsZWN0aW9u KHMpIGFuZCB0aGUNCj4gICAgbG9jYXRpb24gb2YgdGhhdCh0aGVzZSkgY29sbGVjdGlvbihzKSBp cyhhcmUpIHNoYXJlZCB3aGVuIENETiBpbnRlcmNvbm5lY3Rpb24gaXMNCj4gICAgZXN0YWJsaXNo ZWQu4oCdDQoNCkRvbmUuDQoNCj4gKioqIDI6DQo+ICIgIEludmFsaWRhdGUgYW5kIHB1cmdlIHRy aWdnZXJzIE1VU1QgYmUgYXBwbGllZCB0byBhbGwgZGF0YSBhY3F1aXJlZA0KPiAgICBiZWZvcmUg dGhlIHRyaWdnZXIgd2FzIGNyZWF0ZWQgaW4gdGhlIGRDRE4uICBUaGUgZENETiBNQVkgYXBwbHkg dGhlIHRyaWdnZXJzIHRvIGRhdGEgYWNxdWlyZWQgYWZ0ZXIgdHJpZ2dlciBjcmVhdGlvbi7igJ0N Cj4gUGhyYXNlZCB0aGlzIHdheSB3aXRoIGFuIFJGQzIxMTkg4oCcTUFZ4oCdIGl0IHNvdW5kcyBs aWtlIHRoaXMgaXMgYSBuaWNlIG9wdGlvbiB0aGF0IHRoZSBkQ0ROIG1heSBlbGVjdCB0byBzdXBw b3J0LiBJIGJlbGlldmUgdGhpcyBpcyBhY3R1YWxseSBzb21ldGhpbmcgdGhhdCBpcyB1bmRlc2ly YWJsZSBidXQgY2Fubm90IGFsd2F5cyBiZSBhdm9pZGVkLiBJIHRoaW5rIHRoZSB3b3JkaW5nIHNo b3VsZCBiZSB0d2Vha2VkIHRvIGluZGljYXRlIHRoYXQuDQo+IFBlcmhhcHM6DQo+ICJUaGUgZENE TiBTSE9VTEQgYWltIGF0IG5vdCBhcHBseWluZyB0aGUgaW52YWxpZGF0ZSBhbmQgcHVyZ2UgdHJp Z2dlcnMgdG8gZGF0YSBhY3F1aXJlZCBhZnRlciB0cmlnZ2VyIGNyZWF0aW9uLCBidXQgdGhpcyBt YXkgbm90IGFsd2F5cyBiZSBhY2hpZXZhYmxlIHNvIHRoZSB1Q0ROIGNhbm5vdCBjb3VudCBwbiB0 aGF0LuKAnQ0KDQpEb25lLg0KDQooV29yZGVkIGFzICJUaGUgZENETiBTSE9VTEQgTk9UIGFwcGx5 IHRoZSBpbnZhbGlkYXRlIGFuZCBwdXJnZSB0cmlnZ2VycyB0byBkYXRhIGFjcXVpcmVkIGFmdGVy IHRyaWdnZXIgY3JlYXRpb24sIGJ1dCB0aGlzIG1heSBub3QgYWx3YXlzIGJlIGFjaGlldmFibGUg c28gdGhlIHVDRE4gY2Fubm90IGNvdW50IG9uIHRoYXQuIi4pDQoNCj4gKioqIDI6DQo+ICIgNC4g IFRoZSB1Q0ROIGNhbiByZXBlYXRlZGx5IHBvbGwgdGhlIFRyaWdnZXIgU3RhdHVzIFJlc291cmNl IGluIHRoZQ0KPiAgICAgICAgZENETi7igJ0NCj4gaG93IGFib3V0Og0KPiAiIDQuICBUaGUgdUNE TiBjYW4gcG9sbCwgcG9zc2libHkgcmVwZWF0ZWRseSwgdGhlIFRyaWdnZXIgU3RhdHVzIFJlc291 cmNlIGluIHRoZQ0KPiAgICAgICAgZENETi7igJ0NCg0KRG9uZS4NCg0KPiAqKiogMi4yOg0KPiBG b3IgYSByZWFkZXIgZ29pbmcgdGhyb3VnaCB0aGUgZG9jdW1lbnQgdGhlIGZpcnN0IHRpbWUsIHRo aXMgaXMgYSBsaXR0bGUgZGlmZmljdWx0IHRvIGZvbGxvdyBiZWNhdXNlIGFsbCB0aGUgc3RhdHVz ICjigJxjb21wbGV0ZeKAnSwg4oCccHJvY2Vzc2Vk4oCdIGV0YykgaGF2ZSBub3QgeWV0IGJlZW4g ZGVmaW5lZC4gT25lIHNvbHV0aW9uIG1heSBiZSB0byBpbmNsdWRlIGEgZm9yd2FyZCByZWZlcmVu Y2UgdG93YXJkcyB0aGUgc2VjdGlvbiB3aGVyZSB0aG9zZSBhcmUgcHJlY2lzZWx5IGRlZmluZWQu DQoNCkFkZGVkICBhIHJlZiBhcyBzdWdnZXN0ZWQuDQoNCj4gKioqIDM6DQo+IOKAnFRoZSBkQ0RO IGNvdWxkLCBmb3INCj4gICAgZXhhbXBsZSwgYWNoaWV2ZSB0aGlzIGJ5IG9mZmVyaW5nIGRpZmZl cmVudCBjb2xsZWN0aW9uIFVSTHMgdG8gZWFjaA0KPiAgICB1Q0ROLCBvciBieSBmaWx0ZXJpbmcg dGhlIHJlc3BvbnNlIGJhc2VkIG9uIHRoZSBjbGllbnQgdUNETi4gIg0KPiDigJxvcuKAnSDigJQ+ ICJhbmQvb3IiDQo+IGFsc28sIEkgZG9u4oCZdCB0aGluayDigJxjbGllbnQgdUNETuKAnSBpcyB2 ZXJ5IGNsZWFyLiBTbyBob3cgYWJvdXQ6DQo+IOKAnFRoZSBkQ0ROIGNvdWxkLCBmb3INCj4gICAg ZXhhbXBsZSwgYWNoaWV2ZSB0aGlzIGJ5IG9mZmVyaW5nIGRpZmZlcmVudCBjb2xsZWN0aW9uIFVS THMgdG8gZWFjaA0KPiAgICB1Q0ROLCBhbmQvb3IgYnkgZmlsdGVyaW5nIHRoZSByZXNwb25zZSBi YXNlZCBvbiB0aGUgdUNETiB0byB3aGljaCB0aGUgSFRUUCBjbGllbnQgaXNzZXVpbmcgdGhlIENJ L1QgY29tbWFuZCBpcyBhc3NvY2lhdGVkIHdpdGguIOKAnA0KDQpEb25lLg0KDQooV29yZGVkIGFz ICJUaGUgZENETiBjb3VsZCwgZm9yIGV4YW1wbGUsIGFjaGlldmUgdGhpcyBieSBvZmZlcmluZyBk aWZmZXJlbnQgY29sbGVjdGlvbiBVUkxzIHRvIGVhY2ggdUNETiwgYW5kL29yIGJ5IGZpbHRlcmlu ZyB0aGUgcmVzcG9uc2UgYmFzZWQgb24gdGhlIHVDRE4gd2l0aCB3aGljaCB0aGUgSFRUUCBjbGll bnQgaXMgYXNzb2NpYXRlZC4iLikNCg0KPiAqKiogNDoNCj4gT0xEOg0KPiAiVGhlIG9ubHkgcmVw cmVzZW50YXRpb24gc3BlY2lmaWVkIGluIHRoaXMgZG9jdW1lbnQgaXMgSlNPTiwgW1JGQzcxNTld LuKAnQ0KPiBORVc6DQo+ICJUaGUgb25seSByZXByZXNlbnRhdGlvbiBzcGVjaWZpZWQgaW4gdGhp cyBkb2N1bWVudCBpcyBKU09OLCBbUkZDNzE1OV0gYW5kIE1VU1QgYmUgc3VwcG9ydGVkIGJ5IHRo ZSB1Q0ROIGFuZCBkQ0ROLiINCg0KRG9uZS4NCg0KPiAqKiogNC4xOg0KPiBPTEQ6DQo+ICJhbmQg YSByZXNvdXJjZSBNVVNUIE5PVCBiZSBjcmVhdGVkIG9uIHRoZSBkQ0RO4oCdDQo+IE5FVzoNCj4g ImFuZCBhIFRyaWdnZXIgU3RhdHVzIFJlc291cmNlIE1VU1QgTk9UIGJlIGNyZWF0ZWQgb24gdGhl IGRDRE7igJ0NCj4gQlRXLCBJIHRoaW5rIHRoZXJlIGFyZSBhIGZldyBvdGhlciBwbGFjZXMgd2hl cmUgdGhlIHNhbWUgY2hhbmdlIHNob3VkbCBiZSBtYWRlOyBjYW4geW91IGNoZWNrIG91dCB0aHJv dWdob3V0IHRoZSBkb2M/DQoNCkRvbmUgKGluIHNldmVyYWwgcGxhY2VzKS4NCg0KPiAqKiogNC4x Og0KPiAiVGhlIEhUVFAgcmVzcG9uc2UgdG8gdGhlIGRDRE4gTVVTVCBoYXZlIHN0YXR1cyBjb2Rl IDIwMQ0KPiAgICBhbmQgdGhlIFVSSSBvZiB0aGUgVHJpZ2dlciBTdGF0dXMgUmVzb3VyY2UgaW4g dGhlIExvY2F0aW9uIGhlYWRlcg0KPiAgICBmaWVsZC7igJ0NCj4gd291ZGwgcmVhZCBiZXR0ZXIg YXM6DQo+IOKAnA0KPiBUaGUgSFRUUCByZXNwb25zZSB0byB0aGUgZENETiBNVVNUIGhhdmUgc3Rh dHVzIGNvZGUgMjAxDQo+ICAgIGFuZCBNVVNUIGNvbnZleSB0aGUgVVJJIG9mIHRoZSBUcmlnZ2Vy IFN0YXR1cyBSZXNvdXJjZSBpbiB0aGUgTG9jYXRpb24gaGVhZGVyDQo+ICAgIGZpZWxkLg0KDQpE b25lLg0KDQo+ICoqKiA0LjE6DQo+IE9MRDoNCj4gIiBPbmNlIGEgVHJpZ2dlciBTdGF0dXMgUmVz b3VyY2UgaGFzIGJlZW4gY3JlYXRlZCB0aGUgZENETiBNVVNUIE5PVCByZS0NCj4gICAgdXNlIGl0 cyBsb2NhdGlvbiwgZXZlbiBhZnRlciB0aGF0IHJlc291cmNlIGhhcyBiZWVuIHJlbW92ZWQu4oCd DQo+IE5FVzoNCj4gIiBPbmNlIGEgVHJpZ2dlciBTdGF0dXMgUmVzb3VyY2UgaGFzIGJlZW4gY3Jl YXRlZCB0aGUgZENETiBNVVNUIE5PVCByZS0NCj4gICAgdXNlIGl0cyBVUkksIGV2ZW4gYWZ0ZXIg dGhhdCByZXNvdXJjZSBoYXMgYmVlbiByZW1vdmVkLuKAnQ0KDQpEb25lLg0KDQo+ICoqKiA0LjE6 DQo+ICIgVGhlICJ0cmlnZ2VyIiBwcm9wZXJ0eSBvZiB0aGUgVHJpZ2dlciBTdGF0dXMgUmVzb3Vy Y2UgY29udGFpbnMgdGhlDQo+ICAgIFRyaWdnZXIgU3BlY2lmaWNhdGlvbiBwb3N0ZWQgaW4gdGhl IGJvZHkgb2YgdGhlIENJL1QgQ29tbWFuZC4g4oCcDQo+IEFnYWluIGZvciBhIDFzdCB0aW1lIHJl YWRlciB0aGlzIGlzIGEgbGl0dGxlIGRpZmZpY3VsdCB0byBmb2xsb3cgYmVjYXVzZSDigJx0cmln Z2VyIHByb3BlcnR54oCdIGFuZCDigJxUcmlnZ2VyIFNwZWNpZmljYXRpb27igJ0gaGF2ZSBuZXZl ciBiZWVuIGRlZmluZWQuDQo+IEkgdGhpbmsgdGhlIGJlc3Qgc29sdXRpb24gd291ZGwgYmUgdG8g dXNlIGEgZ2VuZXJpYyBkZXNjcmlwdGlvbiBsaWtlIOKAnFRoZSBUcmlnZ2VyIFN0YXR1cyBSZXNv dXJjZSB3aWxsIGNvbnZleSBhIHNwZWNpZmljYXRpb24gb2YgdGhlIHRyaWdnZXLigJ0gb3IgIOKA nFRoZSBUcmlnZ2VyIFN0YXR1cyBSZXNvdXJjZSB3aWxsIGNvbnZleSBhbGwgdGhlIGluZm9ybWF0 aW9uIGNoYXJhY3Rlcml6aW5nIHRoZSB0cmlnZ2Vy4oCdIG9yIHNvbWV0aGluZyBsaWtlIHRoYXQu DQo+IEFub3RoZXIgc29sdXRpb24gd291ZGwgYmUgdG9wIGluY2x1ZGUgZm9yd2FyZCByZWZlcmVu Y2VzIHRvIGxhdGVyIHNlY3Rpb25zLCBidXQgdGhhdCB3b3VkbCBiZSBtb3JlIGRpZmZpY3VsdCB0 byBmb2xsb3cuDQoNCkRvbmUgLSBtZXJnZWQgeW91ciBnZW5lcmFsIHdvcmRpbmcgaW4gdG8gdGhl IHByZXZpb3VzIHBhcmFncmFwaCwgYW5kIG1vdmVkIHRoZSBkZXRhaWwgdG8gc2VjdGlvbiA1LjEu MiB3aGVyZSB0aGUgVHJpZ2dlciBTdGF0dXMgUmVzb3VyY2UgaXMgZGVmaW5lZC4NCg0KDQo+ICoq KiA0LjE6DQo+ICIgSWYgdGhlIGRDRE4gaXMgbm90IGFibGUgdG8gdHJhY2sgdGhlIGV4ZWN1dGlv biBvZiB0cmlnZ2VyZWQgYWN0aXZpdHks4oCm4oCdDQo+IFRoZSB0ZXh0IGp1c3Qgc2F5cyB3aGF0 IHRoZSBkQ0ROIG91Z2h0IHRvIGRvIHdoZW4gaXQgY2FuIHRyYWNrIGFuZCB3aGVuIGl0IGNhbm5v dC4gSSB0aGluayB3ZSB3YW50IHRvIGNvbnZleSB0aGUgbWVzc2FnZSB0aGF0IHRoZSBkQ0ROIHNo b3VsZCB0cmFjayB3aGVuZXZlciBpdCBpcyBwb3NzaWJsZS4gDQo+IENhbiB5b3UgYWRkIGEgc2Vu dGVuY2UgdG8gdGhhdCBlZmZlY3Q/IHByb2JhYmx5IGEg4oCcU0hPVUxE4oCdLg0KDQpEb25lIChh cyBhIFNIT1VMRCkuDQoNCj4gKioqIDQuMzoNCj4gIlRoZSB1Q0ROIHNob3VsZCByZXNwb25kIHRv IHRoYXQgY29tbWFuZCBhcHByb3ByaWF0ZWx54oCdDQo+IFdoeSBpcyB0aGlzIG5vdCBhIOKAnE1V U1TigJ0gKG9yIGF0IGxlYXN0IGEgU0hPVUxEKT8NCj4gQWxzbywgSSB0aGluayB0aGlzIHNob3Vk bCBzYXkg4oCcZENETuKAnSBhbmQgbm90IOKAnHVDRE4iDQoNCnVDRE4gLT4gZENETiwgYW5kIGFk ZGVkIE1VU1QuDQoNCj4gKioqIDQuMzoNCj4gIiBpZiBjYW5jZWxsYXRpb24gaXMgbm90IHN1cHBv cnRlZCBieSB0aGUgZENETi4iDQo+IFNvIGlzIOKAnGNhbmNlbGxhdGlvbuKAnSBhbiAib3B0aW9u bmFsIHRvIGltcGxlbWVudCIgZmVhdHVyZSBvZiB0aGUgaW50ZXJmYWNlPyBpZiB5ZXMsIHlvdSBu ZWVkIHRvIG1ha2UgdGhhdCBtdWNoIGNsZWFyZXIuDQo+IEkgYXNzdW1lIGV2ZXJ5dGhpbmcgZWxz ZSBpcyAibWFuZGF0b3J5IHRvIGltcGxlbWVudCIgKGVnIGRlbGV0ZSkgYnV0IG1ha2luZyBvbmUg Yml0IG9wdGlvbmFsIChpZSBjYW5jZWwpIG5vdyBzb3J0IG9mIGJlZ3MgdGhlIHF1ZXN0aW9uLiBQ bGVhc2UgZW5zdXJlIHRoaXMgaXMgMTAwJSBjbGVhci4NCj4gQWN0dWFsbHkgSSBzYXcgbGF0ZXIg aW4gbXkgcmV2aWV3IHRoYXQgZmlsdGVyZWQgY29sbGVjdGlvbnMgYXJlIG9wdGlvbmFsLXRvLWlt cGxlbWVudC4gU28sIGNhbiB5b3UgbWFrZSBzdXJlIHRoYXQgdGhpcyBpcyBhbHNvIGNsZWFyPyAN Cg0KRG9uZSAtIEkgdGhpbmssIGJ1dCBsZXQgbWUga25vdyBpZiBpdCdzIHN0aWxsIG5vdCBjbGVh ciBlbm91Z2guLi4NCg0KSSd2ZSBhZGRlZCAiQ2FuY2VsbGF0aW9uIG9mIHRyaWdnZXJlZCBhY3Rp dml0eSBpcyBvcHRpb25hbC10by1pbXBsZW1lbnQgaW4gdGhlIGRDRE4uIiB0byBzZWN0aW9uIDQu My4NCg0KVGhlIGZpbHRlcmVkIGNvbGxlY3Rpb25zIGFscmVhZHkgaGFkICJ0aGUgZENETiBTSE9V TEQgYWxzbyBtYWludGFpbiBjb2xsZWN0aW9ucyByZXByZXNlbnRpbmcgZmlsdGVyZWQgdmlld3Mu Li4iLCBJJ3ZlIGFkZGVkICJUaGVzZSBmaWx0ZXJlZCBjb2xsZWN0aW9ucyBhcmUgb3B0aW9uYWwt dG8taW1wbGVtZW50IGJ1dCwgaWYgaW1wbGVtZW50ZWQsIHRoZSBkQ0ROIE1VU1QuLi4iLg0KDQo+ ICoqKiA0LjM6DQo+IE9MRDoNCj4gImRvZXMgbm90IGhvd2V2ZXIgZ3VhcmFudGVlIHRoYXQgbm90 IGFjdGl2aXR5IGlzIHN0YXJ0ZWTigJ0NCj4gTkVXOg0KPiAiZG9lcyBub3QgaG93ZXZlciBndWFy YW50ZWUgdGhhdCB0aGUgY29ycmVzcG9uZGluZyBhY3Rpdml0eSB3aWxsIG5vdCBiZSBzdGFydGVk 4oCdDQoNCkRvbmUuDQoNCj4gKioqIDQuNDoNCj4gT0xEOg0KPiDigJxTdWJzZXF1ZW50IHJlcXVl c3RzIHRvIEdFVCB0aGUgZGVsZXRlZCByZXNvdXJjZSBTSE9VTEQgZmFpbC7igJ0NCj4gTkVXOg0K PiDigJxTdWJzZXF1ZW50IHJlcXVlc3RzIHRvIEdFVCB0aGUgZGVsZXRlZCByZXNvdXJjZSBTSE9V TEQgYmUgcmVqZWN0ZWQgYnkgdGhlIGRDRE4gd2l0aCBhbiBIVFRQIGVycm9yLuKAnQ0KPiBBbHNv LCB3aHkgaXMgdGhpcyBub3QgYSBNVVNUPw0KDQpEb25lLCBhbmQgTVVTVGVkLg0KDQo+ICoqKiA0 LjQ6DQo+ICJJZiBhbiAiYWN0aXZlIiBvciAicHJvY2Vzc2VkIiBUcmlnZ2VyIFN0YXR1cyBSZXNv dXJjZSBpcyBkZWxldGVkLCB0aGUNCj4gICAgZENETiBNQVkgc3RvcCBwcm9jZXNzaW5nIHRoZSB0 cmlnZ2VyZWQgYWN0aXZpdHkuIOKAnA0KPiBXaHkgaXMgdGhpcyBub3QgYSBTSE9VTEQ/DQoNClNI T1VMRGVkLg0KDQo+ICoqKiA0LjU6DQo+IE9MRDoNCj4gIiBJdCBpcyByZWNvbW1lbmRlZCB0aGF0 IFRyaWdnZXIgU3RhdHVzIFJlc291cmNlcyBhcmUgbm90DQo+ICAgIGF1dG9tYXRpY2FsbHkgZGVs ZXRlZCBmb3IgYXQgbGVhc3QgMjQgaG91cnMgYWZ0ZXIgdGhleSBiZWNvbWUNCj4gICAgImNvbXBs ZXRlIiwgInByb2Nlc3NlZCIsICJmYWlsZWQiIG9yICJjYW5jZWxsZWTigJ0u4oCdDQo+IE5FVzoN Cj4gIiBJdCBpcyBSRUNPTU1FTkRFRCB0aGF0IFRyaWdnZXIgU3RhdHVzIFJlc291cmNlcyBhcmUg bm90DQo+ICAgIGF1dG9tYXRpY2FsbHkgZGVsZXRlZCBieSB0aGUgZENETiBmb3IgYXQgbGVhc3Qg MjQgaG91cnMgYWZ0ZXIgdGhleSBiZWNvbWUNCj4gICAgImNvbXBsZXRlIiwgInByb2Nlc3NlZCIs ICJmYWlsZWQiIG9yICJjYW5jZWxsZWTigJ0u4oCdDQoNCkRvbmUuDQoNCj4gKioqIDQuNToNCj4g T0xEOg0KPiAiICAgVG8gZW5zdXJlIGl0IGlzIGFibGUgdG8gZ2V0IHRoZSBzdGF0dXMgb2YgaXRz IGNvbXBsZXRlZCBhbmQgZmFpbGVkDQo+ICAgIHRyaWdnZXJzLCBpdCBpcyByZWNvbW1lbmRlZCB0 aGF0IHRoZSB1Q0ROJ3MgcG9sbGluZyBpbnRlcnZhbCBpcyBsZXNzDQo+ICAgIHRoYW4gdGhlIHRp bWUgYWZ0ZXIgd2hpY2ggcmVjb3JkcyBmb3IgY29tcGxldGVkIGFjdGl2aXR5IHdpbGwgYmUNCj4g ICAgZGVsZXRlZC7igJ0NCj4gTkVXOg0KPiAiICAgVG8gZW5zdXJlIGl0IGlzIGFibGUgdG8gZ2V0 IHRoZSBzdGF0dXMgb2YgaXRzIGNvbXBsZXRlZCBhbmQgZmFpbGVkDQo+ICAgIHRyaWdnZXJzLCBp dCBpcyBSRUNPTU1FTkRFRCB0aGF0IHRoZSB1Q0ROIHBvbGxpbmcgaW50ZXJ2YWwgaXMgbGVzcw0K PiAgICB0aGFuIHRoZSB0aW1lIGFmdGVyIHdoaWNoIHJlY29yZHMgZm9yIGNvbXBsZXRlZCBhY3Rp dml0eSB3aWxsIGJlDQo+ICAgIGRlbGV0ZWQu4oCdDQoNCkRvbmUuDQoNCj4gKioqIDQuNjoNCj4g T0xEOg0KPiAidGhlIGNoYXJhY3RlcnMgQVMgZm9sbG93ZWQgYnkgdGhlIENETiBQcm92aWRlcidz IEFTIG51bWJlcizigJ0NCj4gTkVXOg0KPiAidGhlIHR3byBjaGFyYWN0ZXJzIOKAnEFTIiBmb2xs b3dlZCBieSB0aGUgQ0ROIFByb3ZpZGVyJ3MgQXV0b25vbW91cyBTeXN0ZW0gbnVtYmVyLOKAnQ0K DQpEb25lLg0KDQo+ICoqKiA0LjY6DQo+IHNvbWUgQ0ROIFByb3ZpZGVyIG1heSBvd24gbXVsdGlw bGUgQVNlcy4gSSBzdWdnZXN0IHlvdSBhZGQgYSBzdGF0ZW1lbnQgdGhhdCBpbiBzdWNoIGEgY2Fz ZSwgdGhlIHNhbWUgQVMgbmIgYmUgdXNlZCBpbiBhbGwgbWVzc2FnZXMgZnJvbSB0aGF0IENETiBQ cm92aWRlciAodW5sZXNzIHRoZSBDRE4gaXMgYWN0dWFsbHkgb3BlcmF0aW5nIGFzIG11bHRpcGxl IGRpc3RpbmN0cyBDRE5zKS4NCg0KQWRkZWQgIklmIHRoZSBDRE4gcHJvdmlkZXIgaGFzIG11bHRp cGxlIEF1dG9ub21vdXMgU3lzdGVtcywgdGhlIHNhbWUgQVMgbnVtYmVyIFNIT1VMRCBiZSB1c2Vk IGluIGFsbCBtZXNzYWdlcyBmcm9tIHRoYXQgQ0ROIHByb3ZpZGVyICh1bmxlc3MgdGhlcmUgYXJl IG11bHRpcGxlIGRpc3RpbmN0IENETnMpLiINCg0KPiAqKiogNToNCj4gIiBOYW1lcyBpbiBKU09O IGFyZSBjYXNlIHNlbnNpdGl2ZSBhbmQgdGhlcmVmb3JlIHRoZSBuYW1lcyBhbmQgbGl0ZXJhbA0K PiAgICB2YWx1ZXMgc3BlY2lmaWVkIGhlcmUgTVVTVCBhbHdheXMgdXNlIGxvd2VyLWNhc2Uu4oCd DQo+IHRoZSBmYWN0IHRoYXQgSlNPTiBpcyBjYXNlIHNlbnNpdGl2ZSBkb2VzIG5vdCByZXF1aXJl IHRoYXQgQ0kgdXNlcyBsb3dlciBjYXNlLiBJdCBqdXN0IHJlcXVpcmUgdGhhdCBjYXNlcyBhcmUg dXNlZCBjYXJlZnVsbHkuDQo+IFNvIGhvdyBhYm91dDoNCj4gIiBOYW1lcyBpbiBKU09OIGFyZSBj YXNlIHNlbnNpdGl2ZS4gVGhlIG5hbWVzIGFuZCBsaXRlcmFsDQo+ICAgIHZhbHVlcyBzcGVjaWZp ZWQgaW4gdGhlIHByZXNlbnQgZG9jdW1lbnQgTVVTVCBhbHdheXMgdXNlIGxvd2VyLWNhc2Uu4oCd DQoNCkRvbmUuDQoNCj4gKioqIDU6DQo+ICJVbnJlY29nbmlzZWQgbmFtZS92YWx1ZSBwYWlycyBp biBKU09OIG9iamVjdHMgU0hPVUxEIE5PVCBiZSB0cmVhdGVkDQo+ICAgIGFzIGFuIGVycm9yIGJ5 IGVpdGhlciB0aGUgdUNETiBvciBkQ0ROLuKAnA0KPiBQbGVhc2UgaW5kaWNhdGUgaG93IHRoZXkg c2hvdWxkIGJlIHRyZWF0ZWQgdGhlbi4NCg0KQWRkZWQgIlRoZXkgU0hPVUxEIGJlIGlnbm9yZWQg aW4gdGhlIHByb2Nlc3NpbmcsIGFuZCBwYXNzZWQgb24gYnkgZENETiB0byBhbnkgZnVydGhlciBk Q0ROcyBpbiBhIGNhc2NhZGUuIi4NCg0KPiAqKiogNS4xLjENCj4g4oCcQSBKU09OIGFycmF5IG9m IOKApuKAnQ0KPiBEb2VzIHRoZSB0ZXJtIOKAnGFycmF54oCdIGhhdmUgYSBjb21wbGV0ZWx5IHNw ZWNpZmllZCBtZWFuaW5nPyANCg0KSSBiZWxpZXZlIHNvLCBpdCdzIGEgSlNPTiB0ZXJtIGRlZmlu ZWQgaW4gc2VjdGlvbiA1IG9mIFJGQyA3MTU5IC4uLiBkbyB5b3UgdGhpbmsgaXQgbmVlZHMgYSBz cGVjaWZpYyByZWZlcmVuY2U/DQoNCj4gKioqIDUuMS4zOiBjb2xsLWFsbCwgY29sbC1wZW5kaW5n IGV0Yy4NCj4gIk1hbmRhdG9yeTogTGlua3MgdG8gZmlsdGVyZWQgY29sbGVjdGlvbnMgYXJlIG1h bmRhdG9yeSBpbiB0aGUNCj4gICAgICAgICAgY29sbGVjdGlvbiBvZiBhbGwgVHJpZ2dlciBTdGF0 dXMgUmVzb3VyY2VzLCBpZiB0aGUgZENETg0KPiAgICAgICAgICBpbXBsZW1lbnRzIHRoZSBmaWx0 ZXJlZCBjb2xsZWN0aW9ucy4gIE90aGVyd2lzZSwgb3B0aW9uYWwu4oCdDQo+IEkgdGhpbmsgdGhl IGludGVudGlvbiBpcyB0aGF0IGxpbmtzIHRvIEFMTCB0aGUgZmlsdGVyZWQgY29sbGVjdGlvbnMg YXJlIG1hbmRhdG9yeSBpbiB0aGF0IGNhc2UuIElmIGNvcnJlY3QsIHBsZWFzZSBtYWtlIHRoYXQg Y2xlYXIuDQoNCkRvbmUuDQoNCj4gKioqIDUuMS4zOiBjZG4taWQ6DQo+ICJNYW5kYXRvcnk6IE9u bHkgaW4gdGhlIGNvbGxlY3Rpb24gb2YgYWxsIFRyaWdnZXIgU3RhdHVzDQo+ICAgICAgICAgIFJl c291cmNlcywgaWYgdGhlIGRDRE4gaW1wbGVtZW50cyB0aGUgZmlsdGVyZWQgY29sbGVjdGlvbnMu DQo+ICAgICAgICAgIE9wdGlvbmFsIGluIHRoZSBmaWx0ZXJlZCBjb2xsZWN0aW9ucy7igJ0NCj4g V2h5IGlzIHRoZSBwcmVzZW5jZSBvZiBjZG4taWQgdGllZCB0byB0aGUgc3VwcG9ydCBvZiBmaWx0 ZXJlZCBjb2xsZWN0aW9ucz8NCg0KSXQgaGFzIHRvIGJlIHRoZXJlIGF0IGxlYXN0IG9uY2UgLi4u IHB1dHRpbmcgaXQgaW4gdGhlIGZpbHRlcmVkIGNvbGxlY3Rpb25zIGlzIGEgYml0IG9mIGEgd2Fz dGUgb2Ygc3BhY2UsIGJ1dCBwb3NzaWJseSB1c2VmdWwgZm9yIGEgaHVtYW4gcmVhZGVyLiBJdCBt aWdodCBiZSBzbGlnaHRseSBlYXNpZXIgdG8gaW1wbGVtZW50IGFsbCB0aGUgY29sbGVjdGlvbnMg d2l0aCB0aGUgc2FtZSBzZXQgb2YgcHJvcGVydGllcyAtIHNvIEkgbWFkZSBpdCBvcHRpb25hbC4N Cg0KSSd2ZSBhZGRlZCAiT3B0aW9uYWwgaW4gdGhlIGZpbHRlcmVkIGNvbGxlY3Rpb25zICh0aGUg dUNETiBjYW4gYWx3YXlzIGZpbmQgdGhlIGRDRE4ncyBjZG4taWQgaW4gdGhlIGNvbGxlY3Rpb24g b2YgYWxsIFRyaWdnZXIgU3RhdHVzIFJlc291cmNlcywgYnV0IHRoZSBkQ0ROIGNhbiBjaG9vc2Ug dG8gcmVwZWF0IHRoYXQgaW5mb3JtYXRpb24gaW4gaXRzIGltcGxlbWVudGF0aW9uIG9mIGZpbHRl cmVkIGNvbGxlY3Rpb25zKS4iDQoNCj4gKioqIDYuMS4xIGFuZCA2LjEuMg0KPiB5b3UgdXNlIHRo ZSBwaHJhc2Ug4oCcQWxsVHJpZ2dlcnPigJ0gd2hpY2ggaXMgbm90IGRlZmluZWQgb3IgdXNlZCBh bnl3aGVyZSBlbHNlLiANCj4gSG93IGFib3V0IGp1c3Qgc2F5aW5nIOKAnHRoZSBjb2xsZWN0aW9u IG9mIFRyaWdnZXIgU3RhdHVzIFJlc291cmNlc+KAnSAsIG9yIHRoZSDigJwobm9uLWZpbHRlcmVk KSBjb2xsZWN0aW9uIG9mIFRyaWdnZXIgU3RhdHVzIFJlc291cmNlc+KAnQ0KDQpEb25lLg0KDQo+ ICoqKiA2LjEuMjoNCj4gdGhlIHRleHQgc2F5cyDigJxjYXNlLWluc2Vuc2l0aXZlIG1hdGNoaW5n 4oCdIHdoaWxlIHRoZSBKU09OIGVuY29kaW5nIHN5cyAiImNhc2Utc2Vuc2l0aXZlIiA6IHRydWXi gJ0uIElzIHRoaXMgbm9ybWFsPw0KDQpBIG1pc3Rha2UgKHNvIGZhaXJseSBub3JtYWwhKSwgZml4 ZWQgaW4gdGhlIHRleHQgLi4uIHRoZSBtZXRhZGF0YSBtYXRjaCBpcyBjYXNlIGluc2Vuc2l0aXZl LCB0aGUgY29udGVudCBtYXRjaCBpcyBjYXNlIHNlbnNpdGl2ZS4NCg0KPiAqKiogNi4yLjE6DQo+ ICJUaGUgdUNETiBjYW4gZmV0Y2ggdGhlIHNldCBvZiBhbGwgdGhlIHRyaWdnZXJzIC4uLuKAnQ0K PiBwcm9iYWJseSBiZXR0ZXIgc2F5IDoNCj4gIlRoZSB1Q0ROIGNhbiBmZXRjaCB0aGUgd2hvbGUg Y29sbGVjdGlvbiBvZiBUcmlnZ2VyIFN0YXR1cyBSZXNvdXJjZXMg4oCm4oCdDQo+IEkgdGhpbmsg dGhlcmUgYXJlIGEgZmV3IG9jY3VyZW5jZXMgd2hlcmUgdGhlIHRleHQgdXNlcyDigJx0cmlnZ2Vy c+KAnSBpbnN0ZWFkIG9mIOKAnFRyaWdnZXIgU3RhdHVzIFJlc291cmNlc+KAnSwgdGhpcyBjb3Vs ZCBiZSBjbGVhbmVkIHVwLg0KDQpEb25lLCBpbiBhIGZldyBwbGFjZXMuDQoNCg0KPiAqKiog4oCc Ni4yLjIgRmlsdGVyZWQgQ29sbGVjdGlvbnMgb2YgVHJpZ2dlcnPigJ0NCj4gdGhpcyBzaG91bGQg cmVhZDoNCj4g4oCcNi4yLjIgRmlsdGVyZWQgQ29sbGVjdGlvbnMgb2YgVHJpZ2dlciBTdGF0dXMg UmVzb3VyY2Vz4oCdDQoNCkRvbmUuDQoNCj4gKioqICI2LjIuMy4gIFRyaWdnZXIgU3RhdHVzIFJl c291cmNlc+KAnQ0KPiB0aGlzIGNvdWxkIHJlYWQ6DQo+ICI2LjIuMy4gIEluZGl2aWR1YWwgVHJp Z2dlciBTdGF0dXMgUmVzb3VyY2Vz4oCdDQoNCkRvbmUuDQoNCg0KPiAqKiogIjYuMi41LiAgUmVt b3ZpbmcgYSBUcmlnZ2Vy4oCdDQo+IFRoaXMgbWl4ZXMg4oCccmVtb3ZpbmfigJ0sIOKAnGNhbmNl bGxpbmfigJ0gYW5kIOKAnGRlbGV0aW5n4oCdLiBJIHRoaW5rIHRoaXMgZGlzY3Vzc2VzIGEgZGVs ZXRlLiBTbyBhbGwgdGhlIHdvcmRpbmcgc2hvdWRsIGJlIGFsaWduZWQgdG8g4oCcZGVsZXRlIg0K DQpEb25lLg0KDQo+ICoqKiA4LjEgOg0KPiAiIEEgQ0kvVCBkQ0ROIHNlcnZlciBpbXBsZW1lbnRh dGlvbiBNVVNUIHN1cHBvcnQgVExTIHRyYW5zcG9ydCBmb3IgSFRUUA0KPiAgICAoaHR0cHMpIGFz IHBlciBbUkZDMjgxOF0uIOKAnA0KPiBJIHRoaW5rIHRoZSAgQ0kvVCB1Q0ROIHNlcnZlciBpbXBs ZW1lbnRhdGlvbiBNVVNUIGFsc28gc3VwcG9ydCBUTFMuDQoNCkZpeGVkLg0KDQo+ICoqKiB0aHJv dWdob3V0IHRoZSBkb2N1bWVudDoNCj4gVGhlcmUgaXMgYSBmYWlybHkgbG9vc2UgdXNlIG9mIHRo ZSB3b3JkcyDigJxjb21tYW5k4oCdLCDigJxyZXF1ZXN04oCdLCDigJx0cmlnZ2Vy4oCdLCAuLi4N Cj4gZWcgc2VjdGlvbiAyOg0KPiAiVGhlIHVDRE4gdHJpZ2dlcnMgYWN0aW9uIGluIHRoZSBkQ0RO IGJ5IHBvc3RpbmcgYSBDSS9UIENvbW1hbmQg4oCcDQo+IGVnIHNlY3Rpb24gNDoNCj4gIiBSZXF1 ZXN0cyBhcmUgbWFkZSBvdmVyIEhUVFAiDQo+IEkgdGhpbmsgdGhpcyBjb3VsZCBiZSB0aWdodGVu ZWQgdXAuDQoNCkRvbmUuDQoNCg0KPT09PT0NCg0KDQo+IE9uIDI5IERlYyAyMDE0LCBhdCAxMTo0 NiwgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIHdyb3RlOg0KPiANCj4gDQo+IEEgTmV3IEludGVy bmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBk aXJlY3Rvcmllcy4NCj4gVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgQ29udGVudCBE ZWxpdmVyeSBOZXR3b3JrcyBJbnRlcmNvbm5lY3Rpb24gV29ya2luZyBHcm91cCBvZiB0aGUgSUVU Ri4NCj4gDQo+ICAgICAgICBUaXRsZSAgICAgICAgICAgOiBDRE5JIENvbnRyb2wgSW50ZXJmYWNl IC8gVHJpZ2dlcnMNCj4gICAgICAgIEF1dGhvcnMgICAgICAgICA6IFJvYiBNdXJyYXkNCj4gICAg ICAgICAgICAgICAgICAgICAgICAgIEJlbiBOaXZlbi1KZW5raW5zDQo+IAlGaWxlbmFtZSAgICAg ICAgOiBkcmFmdC1pZXRmLWNkbmktY29udHJvbC10cmlnZ2Vycy0wNS50eHQNCj4gCVBhZ2VzICAg ICAgICAgICA6IDQyDQo+IAlEYXRlICAgICAgICAgICAgOiAyMDE0LTEyLTI5DQo+IA0KPiBBYnN0 cmFjdDoNCj4gICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyB0aGUgcGFydCBvZiB0aGUgQ0ROIElu dGVyY29ubmVjdGlvbiBDb250cm9sDQo+ICAgSW50ZXJmYWNlIHRoYXQgYWxsb3dzIGEgQ0ROIHRv IHRyaWdnZXIgYWN0aXZpdHkgaW4gYW4gaW50ZXJjb25uZWN0ZWQNCj4gICBDRE4gdGhhdCBpcyBj b25maWd1cmVkIHRvIGRlbGl2ZXIgY29udGVudCBvbiBpdHMgYmVoYWxmLiAgVGhlDQo+ICAgdXBz dHJlYW0gQ0ROIGNhbiB1c2UgdGhpcyBtZWNoYW5pc20gdG8gcmVxdWVzdCB0aGF0IHRoZSBkb3du c3RyZWFtDQo+ICAgQ0ROIHByZS1wb3NpdGlvbnMgbWV0YWRhdGEgb3IgY29udGVudCwgb3IgdGhh dCBpdCBpbnZhbGlkYXRlcyBvcg0KPiAgIHB1cmdlcyBtZXRhZGF0YSBvciBjb250ZW50LiAgVGhl IHVwc3RyZWFtIENETiBjYW4gbW9uaXRvciB0aGUgc3RhdHVzDQo+ICAgb2YgYWN0aXZpdHkgdGhh dCBpdCBoYXMgdHJpZ2dlcmVkIGluIHRoZSBkb3duc3RyZWFtIENETi4NCj4gDQo+IA0KPiANCj4g VGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+IGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtY2RuaS1jb250cm9sLXRy aWdnZXJzLw0KPiANCj4gVGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUg YXQ6DQo+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY2RuaS1jb250cm9s LXRyaWdnZXJzLTA1DQo+IA0KPiBBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBh dmFpbGFibGUgYXQ6DQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWll dGYtY2RuaS1jb250cm9sLXRyaWdnZXJzLTA1DQo+IA0KPiANCj4gUGxlYXNlIG5vdGUgdGhhdCBp dCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lv bg0KPiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0 IHRvb2xzLmlldGYub3JnLg0KPiANCj4gSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJs ZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJh ZnRzLw0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gQ0ROaSBtYWlsaW5nIGxpc3QNCj4gQ0ROaUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NkbmkNCg0K