From nobody Wed Aug 1 19:27:51 2018 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBBA7130DCA for ; Wed, 1 Aug 2018 19:27:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.321 X-Spam-Level: X-Spam-Status: No, score=-2.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=verizon.com header.b=p+V4Fy80; dkim=pass (1024-bit key) header.d=verizon.com header.b=cYCJdQ/I; dkim=pass (1024-bit key) header.d=verizon.com header.b=t4UbF4eb 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 HT3lnucjFSsB for ; Wed, 1 Aug 2018 19:27:49 -0700 (PDT) Received: from omzsmtpe03.verizonbusiness.com (omzsmtpe03.verizonbusiness.com [199.249.25.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0FF0129C6A for ; Wed, 1 Aug 2018 19:27:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=verizon.com; i=@verizon.com; q=dns/txt; s=corp; t=1533176868; x=1564712868; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=pKEgaKK4gKvzVIJU+JcW3qs7qlxyFlOWZrUgxWgVND0=; b=p+V4Fy8020v4hQ9VQVrFqCu5MUh8hHt7YLrq1GwibswnE2ldhDdU7fO2 AN/ZjU27KqsLLUzriOQVpdPlKW6fYUWG4MPkFcrVxazDegFmyiNPeMzrZ pat1w4rzbqaClxb97bJUkGfv/mJ1ROSbaN4sSqIcgqBke/NffxWCuo8V0 Q=; Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143]) by omzsmtpe03.verizonbusiness.com with ESMTP; 02 Aug 2018 02:27:47 +0000 Received: from rogue-10-255-192-101.rogue.vzwcorp.com (HELO atlantis.verizonwireless.com) ([10.255.192.101]) by fldsmtpi01.verizon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Aug 2018 02:27:25 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=verizon.com; i=@verizon.com; q=dns/txt; s=corp; t=1533176845; x=1564712845; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=pKEgaKK4gKvzVIJU+JcW3qs7qlxyFlOWZrUgxWgVND0=; b=cYCJdQ/IJHvd9E1olumCMpd9l0KeUICTmowBdsbNIRv65uSw3OjvAZSk q4Blgjtvp9ly7UdRAAXZ3xV8BS6dE1tdTQa0KKuxC0belbdocatxCT/JF CH6Mu/7+yenDOV2o3w1MS4zw/6A5dODNuFZJc3uQeQgoYs4XG52zjh7mh c=; Received: from mariner.tdc.vzwcorp.com (HELO eris.verizonwireless.com) ([10.254.88.84]) by atlantis.verizonwireless.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Aug 2018 22:27:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=verizon.com; i=@verizon.com; q=dns/txt; s=corp; t=1533176845; x=1564712845; h=to:subject:date:message-id:references:in-reply-to: mime-version:from; bh=pKEgaKK4gKvzVIJU+JcW3qs7qlxyFlOWZrUgxWgVND0=; b=t4UbF4eblhkcj02v2Pu2niG9iwXxqYaMrDSpP91UGlhNi5+Tm3m4OQ+i zGG3AxEz8snPWWjnsYf6oYeHAxVWtNwTPXNRlEJE3NTwil9vz+UaDNmrv ZKxre9VObomSf1Zl4Zo50KIqp+bHHgewnOkIaovumv3zuKHT9XffgGETx M=; From: sanjay.mishra@verizon.com X-Host: mariner.tdc.vzwcorp.com Received: from ohtwi1exh003.uswin.ad.vzwcorp.com ([10.144.218.45]) by eris.verizonwireless.com with ESMTP/TLS/AES128-SHA256; 02 Aug 2018 02:27:24 +0000 Received: from tbwexch09apd.uswin.ad.vzwcorp.com (153.114.162.33) by OHTWI1EXH003.uswin.ad.vzwcorp.com (10.144.218.45) with Microsoft SMTP Server (TLS) id 14.3.248.2; Wed, 1 Aug 2018 22:27:24 -0400 Received: from tbwexch02apd.uswin.ad.vzwcorp.com (153.114.162.26) by tbwexch09apd.uswin.ad.vzwcorp.com (153.114.162.33) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Wed, 1 Aug 2018 22:27:24 -0400 Received: from tbwexch02apd.uswin.ad.vzwcorp.com ([153.114.162.26]) by tbwexch02apd.uswin.ad.vzwcorp.com ([153.114.162.26]) with mapi id 15.00.1365.000; Wed, 1 Aug 2018 22:27:24 -0400 To: Phil Sorber , "" Thread-Topic: [E] [CDNi] Call For Adoption of draft-finkelman-cdni-rr-sva-extensions Thread-Index: AQHUJtS1FyGNGgh5fESBAfPAhXINMaSrwHCw Date: Thu, 2 Aug 2018 02:27:23 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.144.60.250] Content-Type: multipart/alternative; boundary="_000_ad14633f37f446d394f9c96cf7f01e9btbwexch02apduswinadvzwc_" MIME-Version: 1.0 Archived-At: Subject: Re: [CDNi] [E] Call For Adoption of draft-finkelman-cdni-rr-sva-extensions X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2018 02:27:51 -0000 --_000_ad14633f37f446d394f9c96cf7f01e9btbwexch02apduswinadvzwc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UGhpbCDigJMgVGhlIHByZXNlbnRhdGlvbiBjb3ZlcmVkIHRoZSBmb2xsb3dpbmcgdHdvIGRyYWZ0 czoNCg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmlua2VsbWFuLWNk bmktcnItc3ZhLWV4dGVuc2lvbnMvPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92 Mi91cmw/dT1odHRwcy0zQV9fZGF0YXRyYWNrZXIuaWV0Zi5vcmdfZG9jX2RyYWZ0LTJEZmlua2Vs bWFuLTJEY2RuaS0yRHJyLTJEc3ZhLTJEZXh0ZW5zaW9uc18mZD1Ed01GYVEmYz11ZEJUUnZGdlhD NURocWc3VUhwSmxQcHMzbVozTFJ4cGI2X18wUG9tQlRRJnI9WG5pVmJpc2hHaU8yQW85aEtxU2Mt aFRWSVdDaTNULXg2R2RIUjRaVGdvTSZtPWJGaFJCR3FJMHk4SXNVeDY2Q1ZmUUNlUF83am1naVFm c1hmSzYyVWFJTVUmcz0yenB3UU9MSVZ0REkyN05VWnE1dEhhMDZoVTlFSEQ1djN0Wl9qd0ZfX1NZ JmU9Pg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmlua2VsbWFuLWNk bmktdHJpZ2dlcnMtc3ZhLWV4dGVuc2lvbnMvPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50 LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fZGF0YXRyYWNrZXIuaWV0Zi5vcmdfZG9jX2RyYWZ0LTJE Zmlua2VsbWFuLTJEY2RuaS0yRHRyaWdnZXJzLTJEc3ZhLTJEZXh0ZW5zaW9uc18mZD1Ed01GYVEm Yz11ZEJUUnZGdlhDNURocWc3VUhwSmxQcHMzbVozTFJ4cGI2X18wUG9tQlRRJnI9WG5pVmJpc2hH aU8yQW85aEtxU2MtaFRWSVdDaTNULXg2R2RIUjRaVGdvTSZtPWJGaFJCR3FJMHk4SXNVeDY2Q1Zm UUNlUF83am1naVFmc1hmSzYyVWFJTVUmcz1KQnhrdHJVdXBsODdZeXhpTnhyLUpmNVlGcENsSHpi RU5vQzNza1NpNmZRJmU9Pg0KDQpJcyB0aGUgaHVtIGZvciBhZG9wdGlvbiBmb3IgZHJhZnQtZmlu a2VsbWFuLWNkbmktcnItc3ZhLWV4dGVuc2lvbnMgb25seT8NCg0KVGhhbmtzDQpTYW5qYXkNCg0K RnJvbTogQ0ROaSBbbWFpbHRvOmNkbmktYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFBo aWwgU29yYmVyDQpTZW50OiBTYXR1cmRheSwgSnVseSAyOCwgMjAxOCA4OjQwIFBNDQpUbzogPGNk bmlAaWV0Zi5vcmc+IDxjZG5pQGlldGYub3JnPg0KU3ViamVjdDogW0VdIFtDRE5pXSBDYWxsIEZv ciBBZG9wdGlvbiBvZiBkcmFmdC1maW5rZWxtYW4tY2RuaS1yci1zdmEtZXh0ZW5zaW9ucw0KDQpJ biBNb250cmVhbCB3ZSBoYWQgYSBwcmVzZW50YXRpb24gYW5kIGEgaHVtIGZvciBpbnRlcmVzdCBp biBhZG9wdGluZyB0aGlzIGRvY3VtZW50LiBUaGUgaHVtIHdhcyBwb3NpdGl2ZSBhbmQgSSB3b3Vs ZCBsaWtlIHRvIG9wZW4gYSBDYWxsIEZvciBBZG9wdGlvbiBvbiBpdC4gSWYgeW91IHdlcmVuJ3Qg cHJlc2VudCBhdCB0aGUgbWVldGluZywgb3IgcGVyaGFwcyBjYW1lIHVwIHdpdGggc29tZSBuZXcg b3BpbmlvbnMsIHBsZWFzZSB2b2ljZSB0aGVtIGhlcmUuDQoNClRoaXMgQ0ZBIHdpbGwgYmUgb3Bl biB1bnRpbCBBdWd1c3QgMTB0aC4NCg0KVGhhbmtzLg0K --_000_ad14633f37f446d394f9c96cf7f01e9btbwexch02apduswinadvzwc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBz cGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxl MTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWlu IDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0 aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlv dXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286 c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1V UyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5QaGlsIOKAkyBUaGUgcHJlc2VudGF0aW9uIGNvdmVyZWQgdGhlIGZvbGxvd2luZyB0d28gZHJh ZnRzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5j b20vdjIvdXJsP3U9aHR0cHMtM0FfX2RhdGF0cmFja2VyLmlldGYub3JnX2RvY19kcmFmdC0yRGZp bmtlbG1hbi0yRGNkbmktMkRyci0yRHN2YS0yRGV4dGVuc2lvbnNfJmFtcDtkPUR3TUZhUSZhbXA7 Yz11ZEJUUnZGdlhDNURocWc3VUhwSmxQcHMzbVozTFJ4cGI2X18wUG9tQlRRJmFtcDtyPVhuaVZi aXNoR2lPMkFvOWhLcVNjLWhUVklXQ2kzVC14NkdkSFI0WlRnb00mYW1wO209YkZoUkJHcUkweThJ c1V4NjZDVmZRQ2VQXzdqbWdpUWZzWGZLNjJVYUlNVSZhbXA7cz0yenB3UU9MSVZ0REkyN05VWnE1 dEhhMDZoVTlFSEQ1djN0Wl9qd0ZfX1NZJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0 eWxlPSJjb2xvcjpibHVlIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1m aW5rZWxtYW4tY2RuaS1yci1zdmEtZXh0ZW5zaW9ucy88L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29m cG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19kYXRhdHJhY2tlci5pZXRmLm9yZ19kb2NfZHJh ZnQtMkRmaW5rZWxtYW4tMkRjZG5pLTJEdHJpZ2dlcnMtMkRzdmEtMkRleHRlbnNpb25zXyZhbXA7 ZD1Ed01GYVEmYW1wO2M9dWRCVFJ2RnZYQzVEaHFnN1VIcEpsUHBzM21aM0xSeHBiNl9fMFBvbUJU USZhbXA7cj1YbmlWYmlzaEdpTzJBbzloS3FTYy1oVFZJV0NpM1QteDZHZEhSNFpUZ29NJmFtcDtt PWJGaFJCR3FJMHk4SXNVeDY2Q1ZmUUNlUF83am1naVFmc1hmSzYyVWFJTVUmYW1wO3M9SkJ4a3Ry VXVwbDg3WXl4aU54ci1KZjVZRnBDbEh6YkVOb0Mzc2tTaTZmUSZhbXA7ZT0iIHRhcmdldD0iX2Js YW5rIj48c3BhbiBzdHlsZT0iY29sb3I6Ymx1ZSI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtZmlua2VsbWFuLWNkbmktdHJpZ2dlcnMtc3ZhLWV4dGVuc2lvbnMvPC9zcGFu PjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SXMgdGhlIGh1bSBmb3Ig YWRvcHRpb24gZm9yIGRyYWZ0LWZpbmtlbG1hbi1jZG5pLXJyLXN2YS1leHRlbnNpb25zIG9ubHk/ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGFua3M8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+U2FuamF5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IENETmkgW21haWx0bzpjZG5pLWJvdW5jZXNAaWV0 Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlBoaWwgU29yYmVyPGJyPg0KPGI+U2VudDo8L2I+ IFNhdHVyZGF5LCBKdWx5IDI4LCAyMDE4IDg6NDAgUE08YnI+DQo8Yj5Ubzo8L2I+ICZsdDtjZG5p QGlldGYub3JnJmd0OyAmbHQ7Y2RuaUBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4g W0VdIFtDRE5pXSBDYWxsIEZvciBBZG9wdGlvbiBvZiBkcmFmdC1maW5rZWxtYW4tY2RuaS1yci1z dmEtZXh0ZW5zaW9uczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5JbiBNb250cmVhbCB3ZSBoYWQgYSBwcmVzZW50YXRpb24gYW5kIGEgaHVtIGZvciBpbnRlcmVz dCBpbiBhZG9wdGluZyB0aGlzIGRvY3VtZW50LiBUaGUgaHVtIHdhcyBwb3NpdGl2ZSBhbmQgSSB3 b3VsZCBsaWtlIHRvIG9wZW4gYSBDYWxsIEZvciBBZG9wdGlvbiBvbiBpdC4gSWYgeW91IHdlcmVu J3QgcHJlc2VudCBhdCB0aGUgbWVldGluZywgb3IgcGVyaGFwcyBjYW1lIHVwIHdpdGggc29tZSBu ZXcgb3BpbmlvbnMsDQogcGxlYXNlIHZvaWNlIHRoZW0gaGVyZS48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBDRkEgd2lsbCBiZSBvcGVu IHVudGlsIEF1Z3VzdCAxMHRoLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5UaGFua3MuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_ad14633f37f446d394f9c96cf7f01e9btbwexch02apduswinadvzwc_-- From nobody Wed Aug 1 19:28:43 2018 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D836130DCA for ; Wed, 1 Aug 2018 19:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.9 X-Spam-Level: X-Spam-Status: No, score=-14.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=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 J0bVAETpgjOr for ; Wed, 1 Aug 2018 19:28:37 -0700 (PDT) Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by ietfa.amsl.com (Postfix) with SMTP id C707E129C6A for ; Wed, 1 Aug 2018 19:28:37 -0700 (PDT) Received: (qmail 51732 invoked by uid 99); 2 Aug 2018 02:28:37 -0000 Received: from mail-relay.apache.org (HELO mailrelay2-lw-us.apache.org) (207.244.88.137) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 02 Aug 2018 02:28:37 +0000 Received: from mail-it0-f46.google.com (mail-it0-f46.google.com [209.85.214.46]) by mailrelay2-lw-us.apache.org (ASF Mail Server at mailrelay2-lw-us.apache.org) with ESMTPSA id 59CEC2B61 for ; Thu, 2 Aug 2018 02:28:36 +0000 (UTC) Received: by mail-it0-f46.google.com with SMTP id s7-v6so1115677itb.4 for ; Wed, 01 Aug 2018 19:28:36 -0700 (PDT) X-Gm-Message-State: AOUpUlFkSmBU7vCHasaISAONbFzJTy7+T9LT9aqEwcf12Vj5uK7rY7Cx MmMotvrBmv1xgDlHxwbhPVZqutuxyvOynXpQmOM= X-Google-Smtp-Source: AAOMgpeBL7NPqTSOey6um2gTkyJmvizEnq03ZwHMRlqBz3CdTo5NRjQTcfB6shQPdx7gJWXnySlAsOf6Qn3Flf/+dhU= X-Received: by 2002:a24:bd82:: with SMTP id x124-v6mr802100ite.143.1533176915053; Wed, 01 Aug 2018 19:28:35 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Phil Sorber Date: Wed, 1 Aug 2018 20:28:20 -0600 X-Gmail-Original-Message-ID: Message-ID: To: Chris Lemmons Cc: cdni@ietf.org Content-Type: multipart/alternative; boundary="00000000000066511105726a913f" Archived-At: Subject: Re: [CDNi] URI Signing open issues X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2018 02:28:41 -0000 --00000000000066511105726a913f Content-Type: text/plain; charset="UTF-8" On Mon, Jul 30, 2018 at 4:32 PM Chris Lemmons wrote: > > The host shouldn't be specified upstream. > > I can buy this argument. I can think of some strange CDN > architectures, but none that really justify adding complexity here. I > think I agree that path is sufficient. What about the "Secure" flag? > An implementation may wish to require that renewals happen over https. > For example, if the initial signature is handed out via TLS and the > renewal is always handled over HTTP, leakage of the URI is much less > likely to happen without the intervention of the client. Without the > flag, it's acceptable to switch to http after having started with an > https connection. The signer is likely to "prohibit" this if > neccessary by putting "https" in the regex. But there's no way for the > cookie-maker to know that. > > Is it possible that we're simply making this way too hard? I dislike > the duplication, but a claim that looked like: "cdnicp": > "Path=/foo/bar/baz; Domain=special.example.com; Secure" would be > infinitely flexible and dead simple to implement. Signers should have > sufficient information to fill it out (usually, by leaving the > "Domain" off, as you have mentioned). And it's forward compatible, so > if browsers start supporting some fancy new parameter in the future, > signers can start putting it in the cookies. But it's cookie-specific > and duplicates the path. > > > I was recently pointed to the POSIX standard > > Yeah, I almost suggested POSIX BREs or EREs for the format. > Unfortunately, even the BREs are susceptible to catastrophic > backtracking. BREs support backreferences, and backreferences require > a backtracking solution. There's a useful discussion here: > https://swtch.com/~rsc/regexp/regexp2.html. Look at "Digression: POSIX > Submatching". > > > We cannot specify a library for implementers. [...] It was not intended > for implementers of the spec to implement their own Regular Expression > library. > > Right. We're not picking one, but we probably shouldn't pick something > that doesn't have any implementations. BRE, ERE, RE2, and PCRE all > meet that requirement. > And what about section 2.13 Pattern Matching Notation? > > I like the specification for BREs the best. It's well specified and it > feels possible to implement it. Unfortunately, it cannot be > implemented in linear time as it stands. However, I believe > backreferences are the only feature of BREs that cannot. There does > exist at least one implementation of [BE]RE that allows the detection > of backreferences and allows you to exclude them as well as running in > time linear on the input ( https://github.com/laurikari/tre ). There > may be others. > > Is there a specific use-case for backreferences in the urls? I can > kinda guess at something like: http://[^/]*/code/(foo|bar|baz)/\1.[ch] > . That would prohibit something like http://example.com/code/foo/bar.h > from matching. I like flexibility wherever possible, but I think the > cost here is too high. > > On Mon, Jul 30, 2018 at 12:36 PM Phil Sorber wrote: > > > > On Sun, Jul 29, 2018 at 10:42 PM Chris Lemmons > wrote: > >> > >> > Perhaps we could also offer a path depth. cdnicpd that is an integer > of the directory depth to use of the actual resource being requested. So > for example: > >> > > >> > http://cdni.example/foo/bar/baz/movie/fragments/1.ts > >> > > >> > and a cdnicpd of 4 would give you a cookie path of /foo/bar/baz/movie. > >> > >> Interesting. So the target path would depend on the presenter of the > >> token, not the signer? That seems backward to me, but since the signer > >> has control of the possible valid options, it might work. So, if I > >> understand, a token with depth of 2 and a regex of > >> "https?://[^/]*/(foo|bar)/movies/.*" applied to > >> "http://host.example.com/foo/movies/a" would renew at > >> "Path=/foo/movies". And "http://host.example.com/bar/movies/b" would > >> renew at "Path=/bar/movies". > >> > >> I don't like the idea that the token doesn't renew at the same path > >> each time. And it's strange to support "multiple entry points" like > >> this, but then limit it to entry points at the same depth. It also > >> doesn't let us know what host to use for renewal. > >> > >> Spitballing a bit, but what if we used capture groups in the regex to > >> supply the data? That has the advantage of not requiring any > >> additional claims, but the disadvantage of not working for any > >> container except regex. (But practically speaking, regex is probably > >> the only choice for token renewal, unless it's repeated access to a > >> single resource. > >> > >> You could say > "https?://(?P[^/:])(:[0-9]*)?/(?P

(/premium/channel[1-4]|/free)/.*" > >> and it would pull out the "h" and "p" components for the renewal. It > >> makes the regex much less comprehensible, though. And regexen really > >> doesn't need that. :/ > >> > >> Any solution to the target path problem needs to support at least > >> specifying the host and the path. And it would be nice if it also > >> specified the "secure" parameter by some mechanism, for those who wish > >> to require that tokens be presented over encrypted connections. > > > > > > The host shouldn't be specified upstream. If you are redirecting to a > cache with a host name that the uCDN can't poissibly know, that would be > problematic. > > > > I feel like a lot of this is on the dCDN to interact with the client. It > knows it's architecture, and it should do what it needs to to make the > signalling work. I think the path is important information from the uCDN > because it's essentially information about the content that the dCDN > doesn't have. I think you are over complicating this issue. > > > >> > >> > >> > We chose PCRE because it is much better specified than RE2. > >> > >> I totally get that. Neither of them is really specified in sufficient > >> detail, imo. But PCRE certainly uses more words. RE2 mostly relies on > >> the reader knowing what things do in PCRE, which isn't really great. > >> > >> > You can use RE2 as an implementer if you wanted to. > >> > >> No, I really can't. The draft as it stands requires that you implement > >> > >> the whole thing. And it wouldn't be sufficient to change the draft > >> since unadvertised interop issues would inevitably arise. The point of > >> having a spec that describes URI Signing is to allow interop between > >> parties without requiring that they pre-negotiate which components > >> will be supported. And while it's possible that some of the claims > >> won't be processible by all compliant CDNs, it would significantly > >> hamper implementations if they have to negotiate what subset of PCRE > >> is acceptable. > >> > >> > PCRE also has a DFA mode, which i believe addresses your concerns. > >> > >> Same problem here. A token signer can't reasonably guess what dialect > >> of PCRE is going to be used to interpret the regex. Every regex should > >> be processed by every CDN in the same way. Failing to do this has > >> security concerns, since uris that may not be intended to match can > >> and those that are intended to match may not. > > > > > > There is always going to be some amount of integration issues that both > a uCDN and dCDN will need to work out. > > > >> > >> > >> Given that we need to have a single, documented dialect of a regex, > >> we're mostly picking a mandatory library for implementers. It's worth > >> considering that as well. > > > > > > I disagree. We cannot specify a library for implementers. That simply > won't pass muster. > > > > I was recently pointed to the POSIX standard that has both a basic glob > pattern matching (IEEE 1003.1-2017 sec 2.13) and a more robust regular > expression pattern matching (IEEE 1003.1-2017 sec 9). > > > > We removed a URI Pattern Match that is similar to the sec 2.13 version > because we didn't want to re-invent the wheel poorly. Section 2.13 is the > spec for the wheel so maybe we should reconsider that approach and just use > that. > > > >> > >> > >> If we require PCRE without mitigation, we're building the ReDoS attacks > in. > >> > >> Is the purpose of picking PCRE that it's better specified and > >> therefore easier for implementers to build their own implementations? > >> Or that it's better documented for users to write regexes that match? > > > > > > It was not intended for implementers of the spec to implement their own > Regular Expression library. > --00000000000066511105726a913f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Mon, Jul 30, 2018 at 4:32 PM Chris Lemmons <alficles@gmail.com> wrote:
> The host shouldn= 9;t be specified upstream.

I can buy this argument. I can think of some strange CDN
architectures, but none that really justify adding complexity here. I
think I agree that path is sufficient. What about the "Secure" fl= ag?
An implementation may wish to require that renewals happen over https.
For example, if the initial signature is handed out via TLS and the
renewal is always handled over HTTP, leakage of the URI is much less
likely to happen without the intervention of the client. Without the
flag, it's acceptable to switch to http after having started with an https connection. The signer is likely to "prohibit" this if
neccessary by putting "https" in the regex. But there's no wa= y for the
cookie-maker to know that.

Is it possible that we're simply making this way too hard? I dislike the duplication, but a claim that looked like: "cdnicp":
"Path=3D/foo/bar/baz; Domain=3Dspecial.example.com; Secure" = would be
infinitely flexible and dead simple to implement. Signers should have
sufficient information to fill it out (usually, by leaving the
"Domain" off, as you have mentioned). And it's forward compat= ible, so
if browsers start supporting some fancy new parameter in the future,
signers can start putting it in the cookies. But it's cookie-specific and duplicates the path.

> I was recently pointed to the POSIX standard

Yeah, I almost suggested POSIX BREs or EREs for the format.
Unfortunately, even the BREs are susceptible to catastrophic
backtracking. BREs support backreferences, and backreferences require
a backtracking solution. There's a useful discussion here:
https://swtch.com/~rsc/regexp/regexp2.html. Look at &q= uot;Digression: POSIX
Submatching".

> We cannot specify a library for implementers. [...] It was not intende= d for implementers of the spec to implement their own Regular Expression li= brary.

Right. We're not picking one, but we probably shouldn't pick someth= ing
that doesn't have any implementations. BRE, ERE, RE2, and PCRE all
meet that requirement.

And what about s= ection 2.13 Pattern Matching Notation?
=C2=A0

I like the specification for BREs the best. It's well specified and it<= br> feels possible to implement it. Unfortunately, it cannot be
implemented in linear time as it stands. However, I believe
backreferences are the only feature of BREs that cannot. There does
exist at least one implementation of [BE]RE that allows the detection
of backreferences and allows you to exclude them as well as running in
time linear on the input ( https://github.com/laurikari/tre ). T= here
may be others.

Is there a specific use-case for backreferences in the urls? I can
kinda guess at something like: http://[^/]*/code/(foo|bar|baz)/\1.[ch]
. That would prohibit something like http://example.com/code/foo/ba= r.h
from matching. I like flexibility wherever possible, but I think the
cost here is too high.

On Mon, Jul 30, 2018 at 12:36 PM Phil Sorber <sorber@apache.org> wrote:
>
> On Sun, Jul 29, 2018 at 10:42 PM Chris Lemmons <alficles@gmail.com> wrote:
>>
>> > Perhaps we could also offer a path depth. cdnicpd that is an = integer of the directory depth to use of the actual resource being requeste= d. So for example:
>> >
>> > http://cdni.example/foo/bar/baz/mo= vie/fragments/1.ts
>> >
>> > and a cdnicpd of 4 would give you a cookie path of /foo/bar/b= az/movie.
>>
>> Interesting. So the target path would depend on the presenter of t= he
>> token, not the signer? That seems backward to me, but since the si= gner
>> has control of the possible valid options, it might work. So, if I=
>> understand, a token with depth of 2 and a regex of
>> "https?://[^/]*/(foo|bar)/movies/.*" applied to
>> "http://host.example.com/foo/movies/a" wo= uld renew at
>> "Path=3D/foo/movies". And "http://host.e= xample.com/bar/movies/b" would
>> renew at "Path=3D/bar/movies".
>>
>> I don't like the idea that the token doesn't renew at the = same path
>> each time. And it's strange to support "multiple entry po= ints" like
>> this, but then limit it to entry points at the same depth. It also=
>> doesn't let us know what host to use for renewal.
>>
>> Spitballing a bit, but what if we used capture groups in the regex= to
>> supply the data? That has the advantage of not requiring any
>> additional claims, but the disadvantage of not working for any
>> container except regex. (But practically speaking, regex is probab= ly
>> the only choice for token renewal, unless it's repeated access= to a
>> single resource.
>>
>> You could say "https?://(?P<h>[^/:])(:[0-9]*)?/(?P<p= >(/premium/channel[1-4]|/free)/.*"
>> and it would pull out the "h" and "p" componen= ts for the renewal. It
>> makes the regex much less comprehensible, though. And regexen real= ly
>> doesn't need that. :/
>>
>> Any solution to the target path problem needs to support at least<= br> >> specifying the host and the path. And it would be nice if it also<= br> >> specified the "secure" parameter by some mechanism, for = those who wish
>> to require that tokens be presented over encrypted connections. >
>
> The host shouldn't be specified upstream. If you are redirecting t= o a cache with a host name that the uCDN can't poissibly know, that wou= ld be problematic.
>
> I feel like a lot of this is on the dCDN to interact with the client. = It knows it's architecture, and it should do what it needs to to make t= he signalling work. I think the path is important information from the uCDN= because it's essentially information about the content that the dCDN d= oesn't have. I think you are over complicating this issue.
>
>>
>>
>> > We chose PCRE because it is much better specified than RE2. >>
>> I totally get that. Neither of them is really specified in suffici= ent
>> detail, imo. But PCRE certainly uses more words. RE2 mostly relies= on
>> the reader knowing what things do in PCRE, which isn't really = great.
>>
>> > You can use RE2 as an implementer if you wanted to.
>>
>> No, I really can't. The draft as it stands requires that you i= mplement
>>
>> the whole thing. And it wouldn't be sufficient to change the d= raft
>> since unadvertised interop issues would inevitably arise. The poin= t of
>> having a spec that describes URI Signing is to allow interop betwe= en
>> parties without requiring that they pre-negotiate which components=
>> will be supported. And while it's possible that some of the cl= aims
>> won't be processible by all compliant CDNs, it would significa= ntly
>> hamper implementations if they have to negotiate what subset of PC= RE
>> is acceptable.
>>
>> >=C2=A0 PCRE also has a DFA mode, which i believe addresses you= r concerns.
>>
>> Same problem here. A token signer can't reasonably guess what = dialect
>> of PCRE is going to be used to interpret the regex. Every regex sh= ould
>> be processed by every CDN in the same way. Failing to do this has<= br> >> security concerns, since uris that may not be intended to match ca= n
>> and those that are intended to match may not.
>
>
> There is always going to be some amount of integration issues that bot= h a uCDN and dCDN will need to work out.
>
>>
>>
>> Given that we need to have a single, documented dialect of a regex= ,
>> we're mostly picking a mandatory library for implementers. It&= #39;s worth
>> considering that as well.
>
>
> I disagree. We cannot specify a library for implementers. That simply = won't pass muster.
>
> I was recently pointed to the POSIX standard that has both a basic glo= b pattern matching (IEEE 1003.1-2017 sec 2.13) and a more robust regular ex= pression pattern matching (IEEE 1003.1-2017 sec 9).
>
> We removed a URI Pattern Match that is similar to the sec 2.13 version= because we didn't want to re-invent the wheel poorly. Section 2.13 is = the spec for the wheel so maybe we should reconsider that approach and just= use that.
>
>>
>>
>> If we require PCRE without mitigation, we're building the ReDo= S attacks in.
>>
>> Is the purpose of picking PCRE that it's better specified and<= br> >> therefore easier for implementers to build their own implementatio= ns?
>> Or that it's better documented for users to write regexes that= match?
>
>
> It was not intended for implementers of the spec to implement their ow= n Regular Expression library.
--00000000000066511105726a913f-- From nobody Wed Aug 1 19:30:24 2018 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CACB129C6A for ; Wed, 1 Aug 2018 19:30:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.911 X-Spam-Level: X-Spam-Status: No, score=-12.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=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 BZFNiyYupk1A for ; Wed, 1 Aug 2018 19:30:21 -0700 (PDT) Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by ietfa.amsl.com (Postfix) with SMTP id 76EC5130DCA for ; Wed, 1 Aug 2018 19:30:21 -0700 (PDT) Received: (qmail 52070 invoked by uid 99); 2 Aug 2018 02:30:18 -0000 Received: from mail-relay.apache.org (HELO mailrelay1-lw-us.apache.org) (207.244.88.152) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 02 Aug 2018 02:30:18 +0000 Received: from mail-io0-f181.google.com (mail-io0-f181.google.com [209.85.223.181]) by mailrelay1-lw-us.apache.org (ASF Mail Server at mailrelay1-lw-us.apache.org) with ESMTPSA id 1BF2E140F for ; Thu, 2 Aug 2018 02:30:17 +0000 (UTC) Received: by mail-io0-f181.google.com with SMTP id q9-v6so544913ioj.8 for ; Wed, 01 Aug 2018 19:30:17 -0700 (PDT) X-Gm-Message-State: AOUpUlEFEXtImTsKZG2TvQ2y9lXz+Jgg05J684utp60VOqfyjrnUHjB7 dVszngnPGuRSxkrvGpa3A3c7xEC8Wlm9Wn0/QTw= X-Google-Smtp-Source: AA+uWPwld82FoO1hk/TQCCaMwTyyRLVfTFA9R3QNYObvTOwNSxnEIkK9VCJh8f11OCCGK/Tsg8QiHH8QmFOKHZuFO9Y= X-Received: by 2002:a5e:dc41:: with SMTP id s1-v6mr677994iop.200.1533177017367; Wed, 01 Aug 2018 19:30:17 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Phil Sorber Date: Wed, 1 Aug 2018 20:30:04 -0600 X-Gmail-Original-Message-ID: Message-ID: To: sanjay.mishra@verizon.com Cc: "" Content-Type: multipart/alternative; boundary="0000000000007f83ea05726a97f6" Archived-At: Subject: Re: [CDNi] [E] Call For Adoption of draft-finkelman-cdni-rr-sva-extensions X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2018 02:30:23 -0000 --0000000000007f83ea05726a97f6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes. The other hum was interest in rechartering that we would have to do to adopt the triggers. So we are going to do them separately. There will be information about rechartering forthcoming. Does that pose any problems? Thanks. On Wed, Aug 1, 2018 at 8:28 PM wrote: > Phil =E2=80=93 The presentation covered the following two drafts: > > > > https://datatracker.ietf.org/doc/draft-finkelman-cdni-rr-sva-extensions/ > > > > https://datatracker.ietf.org/doc/draft-finkelman-cdni-triggers-sva-extens= ions/ > > > > > Is the hum for adoption for draft-finkelman-cdni-rr-sva-extensions only? > > > > Thanks > > Sanjay > > > > *From:* CDNi [mailto:cdni-bounces@ietf.org] *On Behalf Of *Phil Sorber > *Sent:* Saturday, July 28, 2018 8:40 PM > *To:* > *Subject:* [E] [CDNi] Call For Adoption of > draft-finkelman-cdni-rr-sva-extensions > > > > In Montreal we had a presentation and a hum for interest in adopting this > document. The hum was positive and I would like to open a Call For Adopti= on > on it. If you weren't present at the meeting, or perhaps came up with som= e > new opinions, please voice them here. > > > > This CFA will be open until August 10th. > > > > Thanks. > --0000000000007f83ea05726a97f6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes. The other hum was interest in rechartering that = we would have to do to adopt the triggers. So we are going to do them separ= ately. There will be information about rechartering forthcoming. Does that = pose any problems?

Thanks.

On Wed, Aug 1, 2018 at 8:28 PM <sanjay.mishra@verizon.com> wr= ote:

Phil =E2=80=93 The presentation cover= ed the following two drafts:

=C2=A0

https://= datatracker.ietf.org/doc/draft-finkelman-cdni-rr-sva-extensions/=

ht= tps://datatracker.ietf.org/doc/draft-finkelman-cdni-triggers-sva-extensions= /

=C2=A0

Is the hum for adoption for draft-fin= kelman-cdni-rr-sva-extensions only?

=C2=A0

Thanks

Sanjay

=C2=A0

From: CDNi [mailto:cdni-bounces@ietf.org] On Behalf Of Phil Sorber
Sent: Saturday, July 28, 2018 8:40 PM
To: <cdni@ietf= .org> <cdni@ie= tf.org>
Subject: [E] [CDNi] Call For Adoption of draft-finkelman-cdni-rr-sva= -extensions

=C2=A0

In Montreal we had a presentation and a hum for inte= rest in adopting this document. The hum was positive and I would like to op= en a Call For Adoption on it. If you weren't present at the meeting, or= perhaps came up with some new opinions, please voice them here.

=C2=A0

This CFA will be open until August 10th.

=C2=A0

Thanks.

--0000000000007f83ea05726a97f6-- From nobody Wed Aug 1 23:06:33 2018 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A1A812F1A2 for ; Wed, 1 Aug 2018 23:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.09 X-Spam-Level: X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, T_SPF_TEMPERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=qwilt-com.20150623.gappssmtp.com 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 a1DaqLIqeaJR for ; Wed, 1 Aug 2018 23:06:29 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 213B5128C65 for ; Wed, 1 Aug 2018 23:06:29 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id l2-v6so1320251wme.1 for ; Wed, 01 Aug 2018 23:06:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qwilt-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=n1Pv3vy4gG3cbJETQprKirr+Zun6sRe70PSjAGYM8r0=; b=ntlFlru2EPTvMLSesHFoLIGjj4ZpIeLN+sNM6cGcG2sa1VWhhetrC3orKrN4HNrusD Q+LCE8HrN0pYmahqphZowslQ8x0extCqTqOhQGdXuzhL+lZJVdah+yp1kQaaxvGgrhFx vNNGyT8GlUPxDDZxy41V2tMytAwZ1z+M+bEr6I7Qs2aUl8/SkJl0ePelavRelO7bzBl+ iHQIUxum6+odUgCf6VBBTFdJfWNH+tatsVfF61OA++U4U5K0uaagchXC31GIHOGcBDCp AwTX4MSuPTFfb8ZpIXclwlNzqN4Ss4VPafYCCa1RgzW+GmwL3IYds7TYkeZrKwloUuL3 1KqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=n1Pv3vy4gG3cbJETQprKirr+Zun6sRe70PSjAGYM8r0=; b=hCQeIjAQXrY3O/KoJwOYt3lkWPln4DLiHytMXZCv3xP1Kg2sZu6OYVMtsUdqcrsFPT KQ/riI/Oj0qLTM0+uQQAZ4fCyXYzWV4didQB7bhRWkqd2QM9cp3yAERqzNM7l93UxBzO n1kj1xrsPCiBn2hEixuehFLNPQ3gM6UuozTnl7nlKdD9/iooFKw0bbO8AtiYZ6rARF1g SynnlkHo09x9hI9lseJN+uVdhwrG1FzVIfeuRK/N0urBdYaahektfiN2Wy82aNavqo1/ 75fm5tqWzBuU2lNyOLQP+P1RgwZt9GvLaoGFBk2nVSuITI7XVlLtviqj80O1ZoVJl7ZS oH9Q== X-Gm-Message-State: AOUpUlEpRyv8yCF71b1cTjJZhcLOt+gdeoAGd3IOynZApy2d12XrwWmZ DiJt91NOz1jbD/RSjgZfWHrcMXz/3A9kzndzvorJoA== X-Google-Smtp-Source: AAOMgpfY449yuDTMF39FJ1yDZyrs5izJ8Nb7EhTtWiPBDWfyPBfgdThMe9lSKadnQ/vbl2gi2Gzdv1BhUjO37fXy7fo= X-Received: by 2002:a1c:c1c8:: with SMTP id r191-v6mr879204wmf.103.1533189987519; Wed, 01 Aug 2018 23:06:27 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ori Finkelman Date: Thu, 2 Aug 2018 09:03:01 +0300 Message-ID: To: Phil Sorber Cc: "" , sanjay.mishra@verizon.com Content-Type: multipart/alternative; boundary="00000000000094626005726d9cf9" Archived-At: Subject: Re: [CDNi] [E] Call For Adoption of draft-finkelman-cdni-rr-sva-extensions X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2018 06:06:32 -0000 --00000000000094626005726d9cf9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm ok with that. Thanks. On Thu, Aug 2, 2018, 05:30 Phil Sorber wrote: > Yes. The other hum was interest in rechartering that we would have to do > to adopt the triggers. So we are going to do them separately. There will = be > information about rechartering forthcoming. Does that pose any problems? > > Thanks. > > On Wed, Aug 1, 2018 at 8:28 PM wrote: > >> Phil =E2=80=93 The presentation covered the following two drafts: >> >> >> >> https://datatracker.ietf.org/doc/draft-finkelman-cdni-rr-sva-extensions/ >> >> >> >> https://datatracker.ietf.org/doc/draft-finkelman-cdni-triggers-sva-exten= sions/ >> >> >> >> >> Is the hum for adoption for draft-finkelman-cdni-rr-sva-extensions only? >> >> >> >> Thanks >> >> Sanjay >> >> >> >> *From:* CDNi [mailto:cdni-bounces@ietf.org] *On Behalf Of *Phil Sorber >> *Sent:* Saturday, July 28, 2018 8:40 PM >> *To:* > >> > >> *Subject:* [E] [CDNi] Call For Adoption of >> draft-finkelman-cdni-rr-sva-extensions >> >> >> >> In Montreal we had a presentation and a hum for interest in adopting thi= s >> document. The hum was positive and I would like to open a Call For Adopt= ion >> on it. If you weren't present at the meeting, or perhaps came up with so= me >> new opinions, please voice them here. >> >> >> >> This CFA will be open until August 10th. >> >> >> >> Thanks. >> > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > --=20 *Ori Finkelman*Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 | orif@qwilt.com --00000000000094626005726d9cf9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm ok with that.=C2=A0
Thanks.=C2=A0

On Thu, Aug 2, 2018, 05:30 Phil Sor= ber <sorber@apache.org> wrot= e:
Yes. The o= ther hum was interest in rechartering that we would have to do to adopt the= triggers. So we are going to do them separately. There will be information= about rechartering forthcoming. Does that pose any problems?
Thanks.

On Wed, Aug 1, 2018 at 8:28 PM <sanjay.mishra@verizon.com> wrote:
=

Phil =E2=80=93 The presentation cover= ed the following two drafts:

=C2=A0

https://= datatracker.ietf.org/doc/draft-finkelman-cdni-rr-sva-extensions/=

ht= tps://datatracker.ietf.org/doc/draft-finkelman-cdni-triggers-sva-extensions= /

=C2=A0

Is the hum for adoption for draft-fin= kelman-cdni-rr-sva-extensions only?

=C2=A0

Thanks

Sanjay

=C2=A0

From: CDNi [mailto:cdni-bounces@ietf.org] On Behalf Of Phil Sorber
Sent: Saturday, July 28, 2018 8:40 PM
To: <cdni@ietf= ..org> <cdni@i= etf.org>


Subject: [E] [CDNi] Call For Adoption of draft-finkelman-cdni-rr-sva= -extensions

=C2=A0

In Montreal we had a presentation and a hum for inte= rest in adopting this document. The hum was positive and I would like to op= en a Call For Adoption on it. If you weren't present at the meeting, or= perhaps came up with some new opinions, please voice them here.

=C2=A0

This CFA will be open until August 10th.

=C2=A0

Thanks.

_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/cdni
--
Ori Finkelman<= br>Qwilt | Work: +972-72-2221647 | Mobile: +972-52-3832189 |=C2= =A0orif@qwilt.com
--00000000000094626005726d9cf9-- From nobody Thu Aug 2 06:41:03 2018 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB798129AB8 for ; Thu, 2 Aug 2018 06:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 trkPRFLrEBcq for ; Thu, 2 Aug 2018 06:40:58 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32F07128BAC for ; Thu, 2 Aug 2018 06:40:58 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id s9-v6so2571193wmh.3 for ; Thu, 02 Aug 2018 06:40:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=QoleL9Tb353x9wiZOYRYo1wE/Kj22nM8Ngkdt/mDn40=; b=BpmkkrBOofsYRA8F9eg86VA08xlbu2Fwi7q9gDKPPMOYarQ5fQIkuNlKTWnRaqb7+A rK3ihrbfupReI6mzCAxf3ynTmdhqSxC4qUUzwUE+XZIr5pQmPCwCK1sNL3CFM4GBMX0/ 4lpKO+jFIPRqWhl57oZfCK3s0xbGosmLMG3pUCaVsAzk2sV+5911n8qxgaS5QVZVqq6+ CtbwEXNYcvQ0Djm1uCGgp+cFBuYwj/xkbjZ2qkS43iQBfncNvsL4xwBNJYwjUK0i5l42 ze7k1lZSQ11V/cIzGQiy1TWKw0gcnec0BfMDYr6tejvJFEeJF+WD4uruuXxbEt1dDFuB 9Elg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=QoleL9Tb353x9wiZOYRYo1wE/Kj22nM8Ngkdt/mDn40=; b=UvvOPRtvTFaG2pC8qvx3UDOr6KOi4FvxMXka15PguY1KhhIhAYd60vCyP842QTP8Ws CAVubOhYOkJooVLvVCP8LRoVhCOzLPwwDakDkPU/RNNC+L45cC+lcXHidYwzIyLQ+4/Y Rh4qjzi16DXVp5pwu+I9nw7tffyWv31oWsjnZoIUnNmnNWkRrzROM5uUg6eLH9qRuq8p uJPvULHZ2u3Yo2Zhffn5E01JjdemWT8mYkAAP4uQmROlwV0kjXv2nh/qvH3QEISpQQJo gsNnOTCVlRN41I4BZ6bS1mvviNnO7i4yayrXXoqnefgZ+n0PtLDZSJVLW1DwNNICqghA ALRQ== X-Gm-Message-State: AOUpUlGjloy3EWXEEH6UAxcMYMIhWtYmJwLMQ2HxR8ZlPPSLUcIlbSCr /kCd0Yw8sfdaREPoKWPx98rq5t3SOtpVnPz2xGk= X-Google-Smtp-Source: AAOMgpctGLFdyv/PfZnGmR1I/yN4oVF6rmpc0LEqB/GSq8E86vTN/4MNW+FpKDTt7j7g1xfTS8PW1B5snoeFwZccifg= X-Received: by 2002:a1c:1c52:: with SMTP id c79-v6mr1962869wmc.147.1533217256422; Thu, 02 Aug 2018 06:40:56 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Chris Lemmons Date: Thu, 2 Aug 2018 07:40:44 -0600 Message-ID: To: sorber@apache.org Cc: cdni@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [CDNi] URI Signing open issues X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2018 13:41:01 -0000 Pattern matching is an interesting option there, but probably too limited. Either you incorporate the restrictions in 2.13.3, in order to limit the glob so it does not match '/': http://example.com/foo/* does not match http://example.com/foo/bar/baz. Or you don't incorporate them and stick with 2.13.2, so that http://example.com/foo/*.ts matches http://example.com/foo/secretplace/secrets.xml#nowhere.ts. Also, if you incorporate the file restrictions, you get weird stuff like requiring read privileges on a uri, which doesn't make a whole lot of sense. I guess you could try to add your own restrictions in a similar section. Something like: glob doesn't match '/', unless it occurs at the end of a pattern. But then you're firmly in "bespoke pattern matching" territory. Looking at all the options, so far, the only two options that meet the criteria I think we need are RE2 and ERE. Of those, the ERE is the most well specified. Additionally, EREs don't support backreferences (though implementers should beware, some libraries appear to support them as an extension) and are implementable in time bounded linearly on the input. (And compile in time quadratic to the regex... I think.) Would ERE work for the regexes? On Wed, Aug 1, 2018 at 8:28 PM Phil Sorber wrote: > > On Mon, Jul 30, 2018 at 4:32 PM Chris Lemmons wrote: >> >> > The host shouldn't be specified upstream. >> >> I can buy this argument. I can think of some strange CDN >> architectures, but none that really justify adding complexity here. I >> think I agree that path is sufficient. What about the "Secure" flag? >> An implementation may wish to require that renewals happen over https. >> For example, if the initial signature is handed out via TLS and the >> renewal is always handled over HTTP, leakage of the URI is much less >> likely to happen without the intervention of the client. Without the >> flag, it's acceptable to switch to http after having started with an >> https connection. The signer is likely to "prohibit" this if >> neccessary by putting "https" in the regex. But there's no way for the >> cookie-maker to know that. >> >> Is it possible that we're simply making this way too hard? I dislike >> the duplication, but a claim that looked like: "cdnicp": >> "Path=3D/foo/bar/baz; Domain=3Dspecial.example.com; Secure" would be >> infinitely flexible and dead simple to implement. Signers should have >> sufficient information to fill it out (usually, by leaving the >> "Domain" off, as you have mentioned). And it's forward compatible, so >> if browsers start supporting some fancy new parameter in the future, >> signers can start putting it in the cookies. But it's cookie-specific >> and duplicates the path. >> >> > I was recently pointed to the POSIX standard >> >> Yeah, I almost suggested POSIX BREs or EREs for the format. >> Unfortunately, even the BREs are susceptible to catastrophic >> backtracking. BREs support backreferences, and backreferences require >> a backtracking solution. There's a useful discussion here: >> https://swtch.com/~rsc/regexp/regexp2.html. Look at "Digression: POSIX >> Submatching". >> >> > We cannot specify a library for implementers. [...] It was not intende= d for implementers of the spec to implement their own Regular Expression li= brary. >> >> Right. We're not picking one, but we probably shouldn't pick something >> that doesn't have any implementations. BRE, ERE, RE2, and PCRE all >> meet that requirement. > > > And what about section 2.13 Pattern Matching Notation? > >> >> >> I like the specification for BREs the best. It's well specified and it >> feels possible to implement it. Unfortunately, it cannot be >> implemented in linear time as it stands. However, I believe >> backreferences are the only feature of BREs that cannot. There does >> exist at least one implementation of [BE]RE that allows the detection >> of backreferences and allows you to exclude them as well as running in >> time linear on the input ( https://github.com/laurikari/tre ). There >> may be others. >> >> Is there a specific use-case for backreferences in the urls? I can >> kinda guess at something like: http://[^/]*/code/(foo|bar|baz)/\1.[ch] >> . That would prohibit something like http://example.com/code/foo/bar.h >> from matching. I like flexibility wherever possible, but I think the >> cost here is too high. >> >> On Mon, Jul 30, 2018 at 12:36 PM Phil Sorber wrote: >> > >> > On Sun, Jul 29, 2018 at 10:42 PM Chris Lemmons wr= ote: >> >> >> >> > Perhaps we could also offer a path depth. cdnicpd that is an intege= r of the directory depth to use of the actual resource being requested. So = for example: >> >> > >> >> > http://cdni.example/foo/bar/baz/movie/fragments/1.ts >> >> > >> >> > and a cdnicpd of 4 would give you a cookie path of /foo/bar/baz/mov= ie. >> >> >> >> Interesting. So the target path would depend on the presenter of the >> >> token, not the signer? That seems backward to me, but since the signe= r >> >> has control of the possible valid options, it might work. So, if I >> >> understand, a token with depth of 2 and a regex of >> >> "https?://[^/]*/(foo|bar)/movies/.*" applied to >> >> "http://host.example.com/foo/movies/a" would renew at >> >> "Path=3D/foo/movies". And "http://host.example.com/bar/movies/b" woul= d >> >> renew at "Path=3D/bar/movies". >> >> >> >> I don't like the idea that the token doesn't renew at the same path >> >> each time. And it's strange to support "multiple entry points" like >> >> this, but then limit it to entry points at the same depth. It also >> >> doesn't let us know what host to use for renewal. >> >> >> >> Spitballing a bit, but what if we used capture groups in the regex to >> >> supply the data? That has the advantage of not requiring any >> >> additional claims, but the disadvantage of not working for any >> >> container except regex. (But practically speaking, regex is probably >> >> the only choice for token renewal, unless it's repeated access to a >> >> single resource. >> >> >> >> You could say "https?://(?P[^/:])(:[0-9]*)?/(?P

(/premium/channe= l[1-4]|/free)/.*" >> >> and it would pull out the "h" and "p" components for the renewal. It >> >> makes the regex much less comprehensible, though. And regexen really >> >> doesn't need that. :/ >> >> >> >> Any solution to the target path problem needs to support at least >> >> specifying the host and the path. And it would be nice if it also >> >> specified the "secure" parameter by some mechanism, for those who wis= h >> >> to require that tokens be presented over encrypted connections. >> > >> > >> > The host shouldn't be specified upstream. If you are redirecting to a = cache with a host name that the uCDN can't poissibly know, that would be pr= oblematic. >> > >> > I feel like a lot of this is on the dCDN to interact with the client. = It knows it's architecture, and it should do what it needs to to make the s= ignalling work. I think the path is important information from the uCDN bec= ause it's essentially information about the content that the dCDN doesn't h= ave. I think you are over complicating this issue. >> > >> >> >> >> >> >> > We chose PCRE because it is much better specified than RE2. >> >> >> >> I totally get that. Neither of them is really specified in sufficient >> >> detail, imo. But PCRE certainly uses more words. RE2 mostly relies on >> >> the reader knowing what things do in PCRE, which isn't really great. >> >> >> >> > You can use RE2 as an implementer if you wanted to. >> >> >> >> No, I really can't. The draft as it stands requires that you implemen= t >> >> >> >> the whole thing. And it wouldn't be sufficient to change the draft >> >> since unadvertised interop issues would inevitably arise. The point o= f >> >> having a spec that describes URI Signing is to allow interop between >> >> parties without requiring that they pre-negotiate which components >> >> will be supported. And while it's possible that some of the claims >> >> won't be processible by all compliant CDNs, it would significantly >> >> hamper implementations if they have to negotiate what subset of PCRE >> >> is acceptable. >> >> >> >> > PCRE also has a DFA mode, which i believe addresses your concerns. >> >> >> >> Same problem here. A token signer can't reasonably guess what dialect >> >> of PCRE is going to be used to interpret the regex. Every regex shoul= d >> >> be processed by every CDN in the same way. Failing to do this has >> >> security concerns, since uris that may not be intended to match can >> >> and those that are intended to match may not. >> > >> > >> > There is always going to be some amount of integration issues that bot= h a uCDN and dCDN will need to work out. >> > >> >> >> >> >> >> Given that we need to have a single, documented dialect of a regex, >> >> we're mostly picking a mandatory library for implementers. It's worth >> >> considering that as well. >> > >> > >> > I disagree. We cannot specify a library for implementers. That simply = won't pass muster. >> > >> > I was recently pointed to the POSIX standard that has both a basic glo= b pattern matching (IEEE 1003.1-2017 sec 2.13) and a more robust regular ex= pression pattern matching (IEEE 1003.1-2017 sec 9). >> > >> > We removed a URI Pattern Match that is similar to the sec 2.13 version= because we didn't want to re-invent the wheel poorly. Section 2.13 is the = spec for the wheel so maybe we should reconsider that approach and just use= that. >> > >> >> >> >> >> >> If we require PCRE without mitigation, we're building the ReDoS attac= ks in. >> >> >> >> Is the purpose of picking PCRE that it's better specified and >> >> therefore easier for implementers to build their own implementations? >> >> Or that it's better documented for users to write regexes that match? >> > >> > >> > It was not intended for implementers of the spec to implement their ow= n Regular Expression library. From nobody Thu Aug 2 08:46:45 2018 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D80F130F4C for ; Thu, 2 Aug 2018 08:46:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.321 X-Spam-Level: X-Spam-Status: No, score=-2.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=verizon.com header.b=GGOaaEyO; dkim=pass (1024-bit key) header.d=verizon.com header.b=Yuo1YT3z; dkim=pass (1024-bit key) header.d=verizon.com header.b=E6dpNbH+ 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 j1vCkZlQmUKM for ; Thu, 2 Aug 2018 08:46:35 -0700 (PDT) Received: from omzsmtpe01.verizonbusiness.com (omzsmtpe01.verizonbusiness.com [199.249.25.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F6B5130F4F for ; Thu, 2 Aug 2018 08:46:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=verizon.com; i=@verizon.com; q=dns/txt; s=corp; t=1533224795; x=1564760795; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=dBDr5v/tR/Rl/fXWT7W94d/koGIEXwpxKyqBe0W4c7k=; b=GGOaaEyOH/yMT1c7JQQBL6MTA2+MG8aH7PdfWca/GlI+XZobne5u907V Rl1LCcwfqEDF0bW4UCvF79mRx1LJMvdzqb18du8oOPtScfQ5G3bU5TEYU GP4r/OsggRC4qOb+kZ9JBQGaHFGU2Z2LnG92MQrm+jW8T0S6YvPkJWYaj g=; Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143]) by omzsmtpe01.verizonbusiness.com with ESMTP; 02 Aug 2018 15:46:33 +0000 Received: from rogue-10-255-192-101.rogue.vzwcorp.com (HELO apollo.verizonwireless.com) ([10.255.192.101]) by fldsmtpi01.verizon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Aug 2018 15:45:32 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=verizon.com; i=@verizon.com; q=dns/txt; s=corp; t=1533224732; x=1564760732; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=dBDr5v/tR/Rl/fXWT7W94d/koGIEXwpxKyqBe0W4c7k=; b=Yuo1YT3zRj5GBO2ttbWC1E4Upg7XBwPWhlDU+/GhhKLtywqWbcD9AerJ BcU6oK47J0xhpDzk6E2Kkh3RQxBoCFxJ7T11uX4HVWaeBNQyViCAV7zln gD1kKRxv9S9+o63tHNx56J/9GhyLEUPPAWg+tBMy7Ith0tVC6g1eMbSah E=; Received: from mariner.tdc.vzwcorp.com (HELO eris.verizonwireless.com) ([10.254.88.84]) by apollo.verizonwireless.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Aug 2018 11:45:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=verizon.com; i=@verizon.com; q=dns/txt; s=corp; t=1533224732; x=1564760732; h=to:cc:subject:date:message-id:references:in-reply-to: mime-version:from; bh=dBDr5v/tR/Rl/fXWT7W94d/koGIEXwpxKyqBe0W4c7k=; b=E6dpNbH+ttptMfX9cdbPfWLJvRx47lgsba8N7yRCgWwEbzgOECH+5tvg Wdv6XBzkjH7s9q06BEkl3fhJhFKEkDcrBrK+aBu7RqArgOzVCt9uctwAi EUSUF6P2TsTlMPfairPzNnDTBL0t86VlCNJr85measId1OF3+8id7V48O E=; From: sanjay.mishra@verizon.com X-Host: mariner.tdc.vzwcorp.com Received: from ohtwi1exh002.uswin.ad.vzwcorp.com ([10.144.218.44]) by eris.verizonwireless.com with ESMTP/TLS/AES128-SHA256; 02 Aug 2018 15:45:31 +0000 Received: from tbwexch10apd.uswin.ad.vzwcorp.com (153.114.162.34) by OHTWI1EXH002.uswin.ad.vzwcorp.com (10.144.218.44) with Microsoft SMTP Server (TLS) id 14.3.248.2; Thu, 2 Aug 2018 11:45:29 -0400 Received: from tbwexch02apd.uswin.ad.vzwcorp.com (153.114.162.26) by tbwexch10apd.uswin.ad.vzwcorp.com (153.114.162.34) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Thu, 2 Aug 2018 11:45:27 -0400 Received: from tbwexch02apd.uswin.ad.vzwcorp.com ([153.114.162.26]) by tbwexch02apd.uswin.ad.vzwcorp.com ([153.114.162.26]) with mapi id 15.00.1365.000; Thu, 2 Aug 2018 11:45:27 -0400 To: Phil Sorber CC: "" Thread-Topic: [E] [CDNi] Call For Adoption of draft-finkelman-cdni-rr-sva-extensions Thread-Index: AQHUJtS1FyGNGgh5fESBAfPAhXINMaSrwHCwgABGZQCAAJrUkA== Date: Thu, 2 Aug 2018 15:45:27 +0000 Message-ID: <8391552fbb4947f381d98f828a4bd239@tbwexch02apd.uswin.ad.vzwcorp.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.144.60.250] Content-Type: multipart/alternative; boundary="_000_8391552fbb4947f381d98f828a4bd239tbwexch02apduswinadvzwc_" MIME-Version: 1.0 Archived-At: Subject: Re: [CDNi] [E] Call For Adoption of draft-finkelman-cdni-rr-sva-extensions X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2018 15:46:45 -0000 --_000_8391552fbb4947f381d98f828a4bd239tbwexch02apduswinadvzwc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUGhpbCDigJMgWWVzLCB0aGFua3MgZm9yIGNsYXJpZnlpbmcsIHRoaXMgbWFrZXMgc2Vuc2Uu IERvbuKAmXQgc2VlIGEgcHJvYmxlbSB3aXRoIHRoaXMuDQoNClRoYW5rcw0KU2FuamF5DQoNCkZy b206IFBoaWwgU29yYmVyIFttYWlsdG86c29yYmVyQGFwYWNoZS5vcmddDQpTZW50OiBXZWRuZXNk YXksIEF1Z3VzdCAwMSwgMjAxOCAxMDozMCBQTQ0KVG86IE1pc2hyYSwgU2FuamF5IDxzYW5qYXku bWlzaHJhQG9uZS52ZXJpem9uLmNvbT4NCkNjOiA8Y2RuaUBpZXRmLm9yZz4gPGNkbmlAaWV0Zi5v cmc+DQpTdWJqZWN0OiBSZTogW0VdIFtDRE5pXSBDYWxsIEZvciBBZG9wdGlvbiBvZiBkcmFmdC1m aW5rZWxtYW4tY2RuaS1yci1zdmEtZXh0ZW5zaW9ucw0KDQpZZXMuIFRoZSBvdGhlciBodW0gd2Fz IGludGVyZXN0IGluIHJlY2hhcnRlcmluZyB0aGF0IHdlIHdvdWxkIGhhdmUgdG8gZG8gdG8gYWRv cHQgdGhlIHRyaWdnZXJzLiBTbyB3ZSBhcmUgZ29pbmcgdG8gZG8gdGhlbSBzZXBhcmF0ZWx5LiBU aGVyZSB3aWxsIGJlIGluZm9ybWF0aW9uIGFib3V0IHJlY2hhcnRlcmluZyBmb3J0aGNvbWluZy4g RG9lcyB0aGF0IHBvc2UgYW55IHByb2JsZW1zPw0KDQpUaGFua3MuDQoNCk9uIFdlZCwgQXVnIDEs IDIwMTggYXQgODoyOCBQTSA8c2FuamF5Lm1pc2hyYUB2ZXJpem9uLmNvbTxtYWlsdG86c2FuamF5 Lm1pc2hyYUB2ZXJpem9uLmNvbT4+IHdyb3RlOg0KUGhpbCDigJMgVGhlIHByZXNlbnRhdGlvbiBj b3ZlcmVkIHRoZSBmb2xsb3dpbmcgdHdvIGRyYWZ0czoNCg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtZmlua2VsbWFuLWNkbmktcnItc3ZhLWV4dGVuc2lvbnMvPGh0dHBz Oi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fZGF0YXRyYWNr ZXIuaWV0Zi5vcmdfZG9jX2RyYWZ0LTJEZmlua2VsbWFuLTJEY2RuaS0yRHJyLTJEc3ZhLTJEZXh0 ZW5zaW9uc18mZD1Ed01GYVEmYz11ZEJUUnZGdlhDNURocWc3VUhwSmxQcHMzbVozTFJ4cGI2X18w UG9tQlRRJnI9WG5pVmJpc2hHaU8yQW85aEtxU2MtaFRWSVdDaTNULXg2R2RIUjRaVGdvTSZtPWJG aFJCR3FJMHk4SXNVeDY2Q1ZmUUNlUF83am1naVFmc1hmSzYyVWFJTVUmcz0yenB3UU9MSVZ0REky N05VWnE1dEhhMDZoVTlFSEQ1djN0Wl9qd0ZfX1NZJmU9Pg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtZmlua2VsbWFuLWNkbmktdHJpZ2dlcnMtc3ZhLWV4dGVuc2lvbnMv PGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fZGF0 YXRyYWNrZXIuaWV0Zi5vcmdfZG9jX2RyYWZ0LTJEZmlua2VsbWFuLTJEY2RuaS0yRHRyaWdnZXJz LTJEc3ZhLTJEZXh0ZW5zaW9uc18mZD1Ed01GYVEmYz11ZEJUUnZGdlhDNURocWc3VUhwSmxQcHMz bVozTFJ4cGI2X18wUG9tQlRRJnI9WG5pVmJpc2hHaU8yQW85aEtxU2MtaFRWSVdDaTNULXg2R2RI UjRaVGdvTSZtPWJGaFJCR3FJMHk4SXNVeDY2Q1ZmUUNlUF83am1naVFmc1hmSzYyVWFJTVUmcz1K QnhrdHJVdXBsODdZeXhpTnhyLUpmNVlGcENsSHpiRU5vQzNza1NpNmZRJmU9Pg0KDQpJcyB0aGUg aHVtIGZvciBhZG9wdGlvbiBmb3IgZHJhZnQtZmlua2VsbWFuLWNkbmktcnItc3ZhLWV4dGVuc2lv bnMgb25seT8NCg0KVGhhbmtzDQpTYW5qYXkNCg0KRnJvbTogQ0ROaSBbbWFpbHRvOmNkbmktYm91 bmNlc0BpZXRmLm9yZzxtYWlsdG86Y2RuaS1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9m IFBoaWwgU29yYmVyDQpTZW50OiBTYXR1cmRheSwgSnVseSAyOCwgMjAxOCA4OjQwIFBNDQpUbzog PGNkbmlAaWV0Zi5vcmc8bWFpbHRvOmNkbmlAaWV0Zi5vcmc+PiA8Y2RuaUBpZXRmLm9yZzxtYWls dG86Y2RuaUBpZXRmLm9yZz4+DQpTdWJqZWN0OiBbRV0gW0NETmldIENhbGwgRm9yIEFkb3B0aW9u IG9mIGRyYWZ0LWZpbmtlbG1hbi1jZG5pLXJyLXN2YS1leHRlbnNpb25zDQoNCkluIE1vbnRyZWFs IHdlIGhhZCBhIHByZXNlbnRhdGlvbiBhbmQgYSBodW0gZm9yIGludGVyZXN0IGluIGFkb3B0aW5n IHRoaXMgZG9jdW1lbnQuIFRoZSBodW0gd2FzIHBvc2l0aXZlIGFuZCBJIHdvdWxkIGxpa2UgdG8g b3BlbiBhIENhbGwgRm9yIEFkb3B0aW9uIG9uIGl0LiBJZiB5b3Ugd2VyZW4ndCBwcmVzZW50IGF0 IHRoZSBtZWV0aW5nLCBvciBwZXJoYXBzIGNhbWUgdXAgd2l0aCBzb21lIG5ldyBvcGluaW9ucywg cGxlYXNlIHZvaWNlIHRoZW0gaGVyZS4NCg0KVGhpcyBDRkEgd2lsbCBiZSBvcGVuIHVudGlsIEF1 Z3VzdCAxMHRoLg0KDQpUaGFua3MuDQo= --_000_8391552fbb4947f381d98f828a4bd239tbwexch02apduswinadvzwc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIFBoaWwg4oCTIFllcywgdGhhbmtzIGZv ciBjbGFyaWZ5aW5nLCB0aGlzIG1ha2VzIHNlbnNlLiBEb27igJl0IHNlZSBhIHByb2JsZW0gd2l0 aCB0aGlzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhhbmtz PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPlNhbmpheTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBQaGlsIFNvcmJlciBbbWFpbHRvOnNv cmJlckBhcGFjaGUub3JnXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgQXVndXN0IDAx LCAyMDE4IDEwOjMwIFBNPGJyPg0KPGI+VG86PC9iPiBNaXNocmEsIFNhbmpheSAmbHQ7c2FuamF5 Lm1pc2hyYUBvbmUudmVyaXpvbi5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiAmbHQ7Y2RuaUBpZXRm Lm9yZyZndDsgJmx0O2NkbmlAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBb RV0gW0NETmldIENhbGwgRm9yIEFkb3B0aW9uIG9mIGRyYWZ0LWZpbmtlbG1hbi1jZG5pLXJyLXN2 YS1leHRlbnNpb25zPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Plllcy4gVGhlIG90aGVyIGh1bSB3YXMgaW50ZXJlc3QgaW4gcmVjaGFydGVyaW5nIHRoYXQgd2Ug d291bGQgaGF2ZSB0byBkbyB0byBhZG9wdCB0aGUgdHJpZ2dlcnMuIFNvIHdlIGFyZSBnb2luZyB0 byBkbyB0aGVtIHNlcGFyYXRlbHkuIFRoZXJlIHdpbGwgYmUgaW5mb3JtYXRpb24gYWJvdXQgcmVj aGFydGVyaW5nIGZvcnRoY29taW5nLiBEb2VzIHRoYXQgcG9zZSBhbnkgcHJvYmxlbXM/PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcy48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgQXVn IDEsIDIwMTggYXQgODoyOCBQTSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNhbmpheS5taXNocmFAdmVy aXpvbi5jb20iPnNhbmpheS5taXNocmFAdmVyaXpvbi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UGhpbCDigJMgVGhlIHBy ZXNlbnRhdGlvbiBjb3ZlcmVkIHRoZSBmb2xsb3dpbmcgdHdvIGRyYWZ0czo8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1o dHRwcy0zQV9fZGF0YXRyYWNrZXIuaWV0Zi5vcmdfZG9jX2RyYWZ0LTJEZmlua2VsbWFuLTJEY2Ru aS0yRHJyLTJEc3ZhLTJEZXh0ZW5zaW9uc18mYW1wO2Q9RHdNRmFRJmFtcDtjPXVkQlRSdkZ2WEM1 RGhxZzdVSHBKbFBwczNtWjNMUnhwYjZfXzBQb21CVFEmYW1wO3I9WG5pVmJpc2hHaU8yQW85aEtx U2MtaFRWSVdDaTNULXg2R2RIUjRaVGdvTSZhbXA7bT1iRmhSQkdxSTB5OElzVXg2NkNWZlFDZVBf N2ptZ2lRZnNYZks2MlVhSU1VJmFtcDtzPTJ6cHdRT0xJVnRESTI3TlVacTV0SGEwNmhVOUVIRDV2 M3RaX2p3Rl9fU1kmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtZmlua2VsbWFuLWNkbmktcnItc3ZhLWV4dGVuc2lvbnMvPC9hPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YSBocmVmPSJodHRwczovL3Vy bGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX2RhdGF0cmFja2VyLmll dGYub3JnX2RvY19kcmFmdC0yRGZpbmtlbG1hbi0yRGNkbmktMkR0cmlnZ2Vycy0yRHN2YS0yRGV4 dGVuc2lvbnNfJmFtcDtkPUR3TUZhUSZhbXA7Yz11ZEJUUnZGdlhDNURocWc3VUhwSmxQcHMzbVoz TFJ4cGI2X18wUG9tQlRRJmFtcDtyPVhuaVZiaXNoR2lPMkFvOWhLcVNjLWhUVklXQ2kzVC14Nkdk SFI0WlRnb00mYW1wO209YkZoUkJHcUkweThJc1V4NjZDVmZRQ2VQXzdqbWdpUWZzWGZLNjJVYUlN VSZhbXA7cz1KQnhrdHJVdXBsODdZeXhpTnhyLUpmNVlGcENsSHpiRU5vQzNza1NpNmZRJmFtcDtl PSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWZpbmtlbG1hbi1jZG5pLXRyaWdnZXJzLXN2YS1leHRlbnNpb25zLzwvYT48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPklzIHRoZSBodW0gZm9yIGFkb3B0aW9uIGZvciBk cmFmdC1maW5rZWxtYW4tY2RuaS1yci1zdmEtZXh0ZW5zaW9ucyBvbmx5Pzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rczwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPlNhbmpheTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gQ0ROaSBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpjZG5p LWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5jZG5pLWJvdW5jZXNAaWV0Zi5vcmc8 L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5QaGlsIFNvcmJlcjxicj4NCjxiPlNlbnQ6PC9iPiBT YXR1cmRheSwgSnVseSAyOCwgMjAxOCA4OjQwIFBNPGJyPg0KPGI+VG86PC9iPiAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmNkbmlAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5jZG5pQGlldGYub3JnPC9h PiZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpjZG5pQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ Y2RuaUBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFtFXSBbQ0ROaV0gQ2Fs bCBGb3IgQWRvcHRpb24gb2YgZHJhZnQtZmlua2VsbWFuLWNkbmktcnItc3ZhLWV4dGVuc2lvbnM8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPkluIE1vbnRyZWFsIHdlIGhhZCBhIHByZXNlbnRhdGlvbiBh bmQgYSBodW0gZm9yIGludGVyZXN0IGluIGFkb3B0aW5nIHRoaXMgZG9jdW1lbnQuIFRoZSBodW0g d2FzIHBvc2l0aXZlIGFuZCBJIHdvdWxkIGxpa2UgdG8gb3BlbiBhIENhbGwgRm9yIEFkb3B0aW9u IG9uIGl0LiBJZiB5b3Ugd2VyZW4ndCBwcmVzZW50DQogYXQgdGhlIG1lZXRpbmcsIG9yIHBlcmhh cHMgY2FtZSB1cCB3aXRoIHNvbWUgbmV3IG9waW5pb25zLCBwbGVhc2Ugdm9pY2UgdGhlbSBoZXJl LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+VGhpcyBDRkEgd2lsbCBiZSBvcGVuIHVudGlsIEF1Z3VzdCAxMHRoLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhhbmtzLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_8391552fbb4947f381d98f828a4bd239tbwexch02apduswinadvzwc_--