From nobody Wed Mar 2 05:49:58 2016 Return-Path: X-Original-To: cdni@ietf.org Delivered-To: cdni@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 045551B2A2A; Wed, 2 Mar 2016 05:49:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.15.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160302134957.19134.42315.idtracker@ietfa.amsl.com> Date: Wed, 02 Mar 2016 05:49:57 -0800 Archived-At: Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-logging-22.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: Wed, 02 Mar 2016 13:49:57 -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 of the IETF. Title : CDNI Logging Interface Authors : Francois Le Faucheur Gilles Bertrand Iuniana Oprescu Roy Peterkofsky Filename : draft-ietf-cdni-logging-22.txt Pages : 57 Date : 2016-03-02 Abstract: This memo specifies the Logging interface between a downstream CDN (dCDN) and an upstream CDN (uCDN) that are interconnected as per the CDN Interconnection (CDNI) framework. First, it describes a reference model for CDNI logging. Then, it specifies the CDNI Logging File format and the actual protocol for exchange of CDNI Logging Files. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-logging/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-cdni-logging-22 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-logging-22 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 Wed Mar 2 06:11:17 2016 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 7C2C61B2AB2 for ; Wed, 2 Mar 2016 06:11:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.506 X-Spam-Level: X-Spam-Status: No, score=-14.506 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, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 OzcHR6ZtABIp for ; Wed, 2 Mar 2016 06:11:12 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0D5E1B2AE3 for ; Wed, 2 Mar 2016 06:11:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10722; q=dns/txt; s=iport; t=1456927868; x=1458137468; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=nrywDBhTtA6PbQ0AvQh/U/qhkBVzals+Yz/MbGwmr8w=; b=UsPbHz049j3Tnx1txxe8zAO896rfvx/dvca+xivWFLwailD4fUTIUxja gCckoQrh+eX+nLUSpldwIbkBRnQ6HXFNaBwGp7WQ5m4W4qbF82Gebiz8Y acMflxKaHIkHTz9pWIyvzav/RJ0y5waXCo/vCE1XsThJxl2hU5TtMdbaO c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AsAgA49NZW/5xdJa1egzpSbQaqXI9EA?= =?us-ascii?q?Q2BZxcBCYVyAhyBKTgUAQEBAQEBAWQnhEIBAQQBAQEgSwsQAgEIPwMCAgIlCxQ?= =?us-ascii?q?RAgQBDQUJiBgOqhmPHAEBAQEBAQEBAQEBAQEBAQEBAQEBARWHfgiCRoILggsBA?= =?us-ascii?q?UoRgkIrgQ8FlxIBhVmICYFgS4N5iFKFdYhWAR4BAUKDZGoBhy00fgEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,529,1449532800"; d="scan'208,217";a="243216213" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Mar 2016 14:10:50 +0000 Received: from XCH-ALN-020.cisco.com (xch-aln-020.cisco.com [173.36.7.30]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u22EAoiU021195 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 2 Mar 2016 14:10:50 GMT Received: from xch-rcd-020.cisco.com (173.37.102.30) by XCH-ALN-020.cisco.com (173.36.7.30) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 2 Mar 2016 08:10:49 -0600 Received: from xch-rcd-020.cisco.com ([173.37.102.30]) by XCH-RCD-020.cisco.com ([173.37.102.30]) with mapi id 15.00.1104.009; Wed, 2 Mar 2016 08:10:49 -0600 From: "Francois Le Faucheur (flefauch)" To: "" , Stephen Farrell , Pete Resnick Thread-Topic: [CDNi] I-D Action: draft-ietf-cdni-logging-22.txt Thread-Index: AQHRdIpr0JDkQFfRkkOJ5p0JoabYUJ9GliMA Date: Wed, 2 Mar 2016 14:10:49 +0000 Message-ID: <4220D1BD-2D43-4299-8CB5-73E3FEAADBC3@cisco.com> References: <20160302134957.19134.42315.idtracker@ietfa.amsl.com> In-Reply-To: <20160302134957.19134.42315.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.155.23] Content-Type: multipart/alternative; boundary="_000_4220D1BD2D4342998CB573E3FEAADBC3ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-logging-22.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: Wed, 02 Mar 2016 14:11:14 -0000 --_000_4220D1BD2D4342998CB573E3FEAADBC3ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sDQoNClRoaXMgdmVyc2lvbiBhZGRyZXNzZXM6DQoqIG1pbm9yIGFuZCBmaW5hbCBjb21t ZW50cyByZWdhcmRpbmcgQUJORiBmcm9tIFBldGUgUmVzbmljayAocHJvdmlkZWQgaW4gWW9rb2hh bWEpDQoqIFN0ZXBoZW4gRmFycmVsbOKAmXMgRElTQ1VTUyB0aGF0IHdhcyBkaXNjdXNzZWQgb24g dGhlIHdvcmtpbmcgZ3JvdXAgbGlzdCAoaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUv d2ViL2NkbmkvY3VycmVudC9tc2cwMjM1Ny5odG1sKQ0KDQpUaGF0IGxlYXZlcyB0d28gb3BlbiBp dGVtcyB0byBmaXgsIGFzIHBlciB0aGUgQ0ROSSBXb3JraW5nIEdyb3VwIFlva29oYW1hIG1lZXRp bmcgbWludXRlczoNCiINCm8gTmVlZCB0byB1cGRhdGUgdGhlIHRleHQgcmVsYXRlZCB0byBjaG9p Y2Ugb2YgYWxnb3JpdGhtIGZvciBtYXBwaW5nIHRoZSBJUCBhZGRyZXNzZXM7IE5lZWQgdG8gZW5z dXJlIHRleHQgcmVmbGVjdHMgd2hpY2ggYXBwcm9hY2ggaXMg4oCcbWFuZGF0b3J5IHRvIGltcGxl bWVudOKAnSB0byBlbnN1cmUgaW50ZXJvcGVyYWJpbGl0eS4gVGhpcyB3YXMgZGlzY3Vzc2VkIG9u IHRoZSBsaXN0LiBQbGVhc2UgcmFpc2UgY29uY2VybnMgb24gdGhlIGxpc3QgYXNhcCwgaWYgYW55 Lg0KbyBSZXNvbHZlIGNvbW1lbnQgZnJvbSBLZXZpbiBhYm91dCB3aGF0IGFwcHJvYWNoIHRvIHRh a2UgZm9yIGV4dGVuZGluZyBsb2dnaW5nDQrigJwNCg0KQ2hlZXJzDQoNCkZyYW7Dp29pcw0KDQoN Ck9uIDIgTWFyIDIwMTYsIGF0IDE0OjQ5LCBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRv OmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4gd3JvdGU6DQoNCg0KQSBOZXcgSW50ZXJuZXQtRHJh ZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9y aWVzLg0KVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgQ29udGVudCBEZWxpdmVyeSBO ZXR3b3JrcyBJbnRlcmNvbm5lY3Rpb24gb2YgdGhlIElFVEYuDQoNCiAgICAgICBUaXRsZSAgICAg ICAgICAgOiBDRE5JIExvZ2dpbmcgSW50ZXJmYWNlDQogICAgICAgQXV0aG9ycyAgICAgICAgIDog RnJhbmNvaXMgTGUgRmF1Y2hldXINCiAgICAgICAgICAgICAgICAgICAgICAgICBHaWxsZXMgQmVy dHJhbmQNCiAgICAgICAgICAgICAgICAgICAgICAgICBJdW5pYW5hIE9wcmVzY3UNCiAgICAgICAg ICAgICAgICAgICAgICAgICBSb3kgUGV0ZXJrb2Zza3kNCkZpbGVuYW1lICAgICAgICA6IGRyYWZ0 LWlldGYtY2RuaS1sb2dnaW5nLTIyLnR4dA0KUGFnZXMgICAgICAgICAgIDogNTcNCkRhdGUgICAg ICAgICAgICA6IDIwMTYtMDMtMDINCg0KQWJzdHJhY3Q6DQogIFRoaXMgbWVtbyBzcGVjaWZpZXMg dGhlIExvZ2dpbmcgaW50ZXJmYWNlIGJldHdlZW4gYSBkb3duc3RyZWFtIENETg0KICAoZENETikg YW5kIGFuIHVwc3RyZWFtIENETiAodUNETikgdGhhdCBhcmUgaW50ZXJjb25uZWN0ZWQgYXMgcGVy IHRoZQ0KICBDRE4gSW50ZXJjb25uZWN0aW9uIChDRE5JKSBmcmFtZXdvcmsuICBGaXJzdCwgaXQg ZGVzY3JpYmVzIGENCiAgcmVmZXJlbmNlIG1vZGVsIGZvciBDRE5JIGxvZ2dpbmcuICBUaGVuLCBp dCBzcGVjaWZpZXMgdGhlIENETkkNCiAgTG9nZ2luZyBGaWxlIGZvcm1hdCBhbmQgdGhlIGFjdHVh bCBwcm90b2NvbCBmb3IgZXhjaGFuZ2Ugb2YgQ0ROSQ0KICBMb2dnaW5nIEZpbGVzLg0KDQoNClRo ZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1jZG5pLWxvZ2dpbmcvDQoNClRo ZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Og0KaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY2RuaS1sb2dnaW5nLTIyDQoNCkEgZGlmZiBmcm9t IHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCmh0dHBzOi8vd3d3LmlldGYu b3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWNkbmktbG9nZ2luZy0yMg0KDQoNClBsZWFzZSBu b3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9m IHN1Ym1pc3Npb24NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFp bGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNCkludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFp bGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1k cmFmdHMvDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpDRE5pIG1haWxpbmcgbGlzdA0KQ0ROaUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9jZG5pDQoNCg== --_000_4220D1BD2D4342998CB573E3FEAADBC3ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <86D3682384230B45B32F4A290F15E445@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5IZWxsbyw8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PlRoaXMgdmVyc2lvbiBhZGRyZXNzZXM6PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxzcGFuIGNsYXNz PSJBcHBsZS10YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOnByZSI+PC9zcGFuPiogbWlub3Ig YW5kIGZpbmFsIGNvbW1lbnRzIHJlZ2FyZGluZyBBQk5GIGZyb20gUGV0ZSBSZXNuaWNrIChwcm92 aWRlZCBpbiBZb2tvaGFtYSk8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PHNwYW4gY2xhc3M9IkFwcGxl LXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6cHJlIj48L3NwYW4+KiBTdGVwaGVuIEZhcnJl bGzigJlzIERJU0NVU1MgdGhhdCB3YXMgZGlzY3Vzc2VkIG9uIHRoZSB3b3JraW5nIGdyb3VwIGxp c3QgKDxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9jZG5pL2N1 cnJlbnQvbXNnMDIzNTcuaHRtbCIgY2xhc3M9IiI+aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFy Y2hpdmUvd2ViL2NkbmkvY3VycmVudC9tc2cwMjM1Ny5odG1sPC9hPik8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRoYXQgbGVhdmVzIHR3 byBvcGVuIGl0ZW1zIHRvIGZpeCwgYXMgcGVyIHRoZSBDRE5JIFdvcmtpbmcgR3JvdXAgWW9rb2hh bWEgbWVldGluZyBtaW51dGVzOjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mcXVvdDs8L2Rpdj4NCjxz cGFuIGNsYXNzPSJBcHBsZS10YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOnByZSI+PC9zcGFu Pm8gTmVlZCB0byB1cGRhdGUgdGhlIHRleHQgcmVsYXRlZCB0byBjaG9pY2Ugb2YgYWxnb3JpdGht IGZvciBtYXBwaW5nIHRoZSBJUCBhZGRyZXNzZXM7Jm5ic3A7TmVlZCB0byBlbnN1cmUmbmJzcDt0 ZXh0IHJlZmxlY3RzIHdoaWNoIGFwcHJvYWNoIGlzIOKAnG1hbmRhdG9yeSB0byBpbXBsZW1lbnTi gJ0gdG8gZW5zdXJlIGludGVyb3BlcmFiaWxpdHkuIFRoaXMgd2FzIGRpc2N1c3NlZA0KIG9uIHRo ZSBsaXN0LiZuYnNwO1BsZWFzZSByYWlzZSBjb25jZXJucyBvbiB0aGUgbGlzdCBhc2FwLCBpZiBh bnkuPGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48c3BhbiBjbGFzcz0iQXBwbGUtdGFiLXNw YW4iIHN0eWxlPSJ3aGl0ZS1zcGFjZTogcHJlOyI+PC9zcGFuPm8gUmVzb2x2ZSBjb21tZW50IGZy b20gS2V2aW4gYWJvdXQgd2hhdCBhcHByb2FjaCB0byB0YWtlIGZvciBleHRlbmRpbmcgbG9nZ2lu ZyZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj7igJw8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkNoZWVyczwvZGl2Pg0KPGRpdiBjbGFz cz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+RnJhbsOnb2lzPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGRp dj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiAy IE1hciAyMDE2LCBhdCAxNDo0OSwgPGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZyIgY2xhc3M9IiI+DQppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+IHdyb3RlOjwvZGl2 Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPg0KQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhl IG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLjxiciBjbGFzcz0iIj4NClRoaXMg ZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIENvbnRlbnQgRGVsaXZlcnkgTmV0d29ya3MgSW50 ZXJjb25uZWN0aW9uIG9mIHRoZSBJRVRGLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1RpdGxlICZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzogQ0ROSSBM b2dnaW5nIEludGVyZmFjZTxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwO0F1dGhvcnMgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7OiBGcmFuY29pcyBMZSBGYXVjaGV1cjxiciBjbGFzcz0iIj4NCiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0dpbGxlcyBCZXJ0cmFuZDxiciBjbGFzcz0i Ij4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0l1bmlhbmEgT3ByZXNjdTxi ciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1JveSBQZXRl cmtvZnNreTxiciBjbGFzcz0iIj4NCjxzcGFuIGNsYXNzPSJBcHBsZS10YWItc3BhbiIgc3R5bGU9 IndoaXRlLXNwYWNlOnByZSI+PC9zcGFuPkZpbGVuYW1lICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOzogZHJhZnQtaWV0Zi1jZG5pLWxvZ2dpbmctMjIudHh0PGJyIGNs YXNzPSIiPg0KPHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6 cHJlIj48L3NwYW4+UGFnZXMgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7OiA1NzxiciBjbGFzcz0iIj4NCjxzcGFuIGNsYXNzPSJBcHBs ZS10YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOnByZSI+PC9zcGFuPkRhdGUgJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 OiAyMDE2LTAzLTAyPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQWJzdHJhY3Q6PGJyIGNs YXNzPSIiPg0KJm5ic3A7Jm5ic3A7VGhpcyBtZW1vIHNwZWNpZmllcyB0aGUgTG9nZ2luZyBpbnRl cmZhY2UgYmV0d2VlbiBhIGRvd25zdHJlYW0gQ0ROPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7 KGRDRE4pIGFuZCBhbiB1cHN0cmVhbSBDRE4gKHVDRE4pIHRoYXQgYXJlIGludGVyY29ubmVjdGVk IGFzIHBlciB0aGU8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDtDRE4gSW50ZXJjb25uZWN0aW9u IChDRE5JKSBmcmFtZXdvcmsuICZuYnNwO0ZpcnN0LCBpdCBkZXNjcmliZXMgYTxiciBjbGFzcz0i Ij4NCiZuYnNwOyZuYnNwO3JlZmVyZW5jZSBtb2RlbCBmb3IgQ0ROSSBsb2dnaW5nLiAmbmJzcDtU aGVuLCBpdCBzcGVjaWZpZXMgdGhlIENETkk8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDtMb2dn aW5nIEZpbGUgZm9ybWF0IGFuZCB0aGUgYWN0dWFsIHByb3RvY29sIGZvciBleGNoYW5nZSBvZiBD RE5JPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7TG9nZ2luZyBGaWxlcy48YnIgY2xhc3M9IiI+ DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0 dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczo8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWNkbmktbG9nZ2luZy8iIGNsYXNz PSIiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtY2RuaS1sb2dn aW5nLzwvYT48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGVyZSdzIGFsc28gYSBodG1s aXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDo8YnIgY2xhc3M9IiI+DQpodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1jZG5pLWxvZ2dpbmctMjI8YnIgY2xhc3M9IiI+DQo8YnIg Y2xhc3M9IiI+DQpBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUg YXQ6PGJyIGNsYXNzPSIiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0 LWlldGYtY2RuaS1sb2dnaW5nLTIyPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNs YXNzPSIiPg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVz IGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbjxiciBjbGFzcz0iIj4NCnVudGlsIHRoZSBodG1s aXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuPGJy IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWls YWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0OjxiciBjbGFzcz0iIj4NCmZ0cDovL2Z0cC5pZXRmLm9y Zy9pbnRlcm5ldC1kcmFmdHMvPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnIgY2xhc3M9IiI+DQpDRE5p IG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCkNETmlAaWV0Zi5vcmc8YnIgY2xhc3M9IiI+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nkbmk8YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_4220D1BD2D4342998CB573E3FEAADBC3ciscocom_-- From nobody Wed Mar 2 06:18:48 2016 Return-Path: X-Original-To: cdni@ietf.org Delivered-To: cdni@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF431B2B2D; Wed, 2 Mar 2016 06:18:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.15.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160302141846.11521.25340.idtracker@ietfa.amsl.com> Date: Wed, 02 Mar 2016 06:18:46 -0800 Archived-At: Cc: draft-ietf-cdni-logging@ietf.org, cdni@ietf.org, cdni-chairs@ietf.org Subject: [CDNi] Stephen Farrell's No Objection on draft-ietf-cdni-logging-22: (with COMMENT) 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: Wed, 02 Mar 2016 14:18:46 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-cdni-logging-22: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cdni-logging/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the additional text in -22, which clears up the last of my discuss points. old comments below, I didn't check 'em - in the description of c-groupid, "the address with a shared secret that is pre-synchronised and rotated at a predefined time interval" isn't very clear. I know what you mean but I don't think you state it very clearly. Could be that a bit of text earlier in the document that describes the basic idea would be better than doing it all inline as you have in -21. OLD COMMENTS Below, not updated for -21, I didn't check if you took 'em on board, feel free to chat about 'em if that's useful - I'm happy to do so anyway. - I support Richard's discuss. Isn't it ironic that the dCDN's privacy (that of a company) is better supported than that of the end user (a person) - 2.2.1 - why is per-chunk always needed? - 2.2.5.3: what's "track audience" mean? - 2.2.5.4: there are more security goals in the universe - 2.2.5.4: seems like the user is the enemy, that's odd - 2.2.5.6.2: there is no "browser type header" that I know of, but there is the well-known UA string. Being specific about that is better. - 3.1: SS.S - does that imply a time granularity of 100ms? If so, please say so. - 3.4.4: cs-uri: please not that these can be privacy sensitive, though presumably less so than e.g. logged URIs on a search engine. - 3.4.4: foo-uri: do these contain fragments or not? From nobody Wed Mar 2 06:33:51 2016 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 C0EA61B2B56 for ; Wed, 2 Mar 2016 06:33:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.307 X-Spam-Level: X-Spam-Status: No, score=-4.307 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] 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 d4uaIX27TSaL for ; Wed, 2 Mar 2016 06:33:47 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 677291B2B5E for ; Wed, 2 Mar 2016 06:33:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C5DFDBE55; Wed, 2 Mar 2016 14:33:45 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HjoMJj5L4SHY; Wed, 2 Mar 2016 14:33:45 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3D397BE51; Wed, 2 Mar 2016 14:33:45 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1456929225; bh=kA+GXdu0Z27iWz7cK0w24MCeMdkr0Tm7x5TWrjXQzpw=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=CWLM0cqCfLMsbjElq0VcgTPutrRRL2cxhJqBxSiqF836ZsJLznLm7jx0sCZkmdhTU sVnBBTz6EA15qZW7xQ/2A6mNi2fhEm1dyhcB6Zo7j8omccwyVq1YM3zc7NrnVnp6zm LZ/Q9cq6ZAa2yZTTwrhLdmmVa1+DvzucEEvZYIuY= To: "Francois Le Faucheur (flefauch)" , "" , Pete Resnick References: <20160302134957.19134.42315.idtracker@ietfa.amsl.com> <4220D1BD-2D43-4299-8CB5-73E3FEAADBC3@cisco.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56D6F9C9.9070708@cs.tcd.ie> Date: Wed, 2 Mar 2016 14:33:45 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <4220D1BD-2D43-4299-8CB5-73E3FEAADBC3@cisco.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020402080208000300000003" Archived-At: Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-logging-22.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: Wed, 02 Mar 2016 14:33:49 -0000 This is a cryptographically signed message in MIME format. --------------ms020402080208000300000003 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, I cleared the discuss already:-) Cheers, S. On 02/03/16 14:10, Francois Le Faucheur (flefauch) wrote: > Hello, >=20 > This version addresses: > * minor and final comments regarding ABNF from Pete Resnick (provided i= n Yokohama) > * Stephen Farrell=E2=80=99s DISCUSS that was discussed on the working g= roup list (http://www.ietf.org/mail-archive/web/cdni/current/msg02357.htm= l) >=20 > That leaves two open items to fix, as per the CDNI Working Group Yokoha= ma meeting minutes: > " > o Need to update the text related to choice of algorithm for mapping th= e IP addresses; Need to ensure text reflects which approach is =E2=80=9Cm= andatory to implement=E2=80=9D to ensure interoperability. This was discu= ssed on the list. Please raise concerns on the list asap, if any. > o Resolve comment from Kevin about what approach to take for extending = logging > =E2=80=9C >=20 > Cheers >=20 > Fran=C3=A7ois >=20 >=20 > On 2 Mar 2016, at 14:49, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. > This draft is a work item of the Content Delivery Networks Interconnect= ion of the IETF. >=20 > Title : CDNI Logging Interface > Authors : Francois Le Faucheur > Gilles Bertrand > Iuniana Oprescu > Roy Peterkofsky > Filename : draft-ietf-cdni-logging-22.txt > Pages : 57 > Date : 2016-03-02 >=20 > Abstract: > This memo specifies the Logging interface between a downstream CDN > (dCDN) and an upstream CDN (uCDN) that are interconnected as per the > CDN Interconnection (CDNI) framework. First, it describes a > reference model for CDNI logging. Then, it specifies the CDNI > Logging File format and the actual protocol for exchange of CDNI > Logging Files. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-cdni-logging/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-cdni-logging-22 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-logging-22 >=20 >=20 > Please note that it may take a couple of minutes from the time of submi= ssion > 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 --------------ms020402080208000300000003 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjAzMDIx NDMzNDVaMC8GCSqGSIb3DQEJBDEiBCChkhKSYcJPvJ5ge9YLRkRi9KJH1knKnIaTSoFr3Byr KTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQAqch62podMrzPdeFMGH09lvhOWabnsbm/C/Wkao2UAOfa9H+20Yo/I 3Luu18i/HkOUgm20BoyjSK7NHN/p3f+9/f+XRxlDJTfv1HEarD06nlmleP2IIcAS28tqCt/P Bbj6XNAFMG5zz2FeijEE8g8gHfsmaQEdKshikiYW4sB76NMUWX6OkTSL4vYW73DTNQNYJ3Ei zH0C7Cy/IZOZwLk1AUEaJeoxr6/IpGWvmfWNTayuwts93PDs4aZpLfwS/2kcPfAip+DebISd yRk6gV5KY0w+hp/FPPnjLTAma6nX/CQqtidIB+lag7S1paTsv3BwGfWXRfDEQPfpHqQkf0kD AAAAAAAA --------------ms020402080208000300000003-- From nobody Wed Mar 2 10:06:38 2016 Return-Path: X-Original-To: cdni@ietf.org Delivered-To: cdni@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C13011B2FEB; Wed, 2 Mar 2016 10:06:34 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.15.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20160302180634.14118.36497.idtracker@ietfa.amsl.com> Date: Wed, 02 Mar 2016 10:06:34 -0800 Archived-At: Cc: cdni@ietf.org, draft-ietf-cdni-redirection@ietf.org, barryleiba@gmail.com, cdni-chairs@ietf.org Subject: [CDNi] Last Call: (Request Routing Redirection interface for CDN Interconnection) to Proposed Standard X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org 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, 02 Mar 2016 18:06:34 -0000 The IESG has received a request from the Content Delivery Networks Interconnection WG (cdni) to consider the following document: - 'Request Routing Redirection interface for CDN Interconnection' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-03-16. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Request Routing Interface comprises of (1) the asynchronous advertisement of footprint and capabilities by a downstream Content Delivery Network (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. This Standards Track document has a normative reference to the Informational RFC 6707, "Content Distribution Network Interconnection (CDNI) Problem Statement", which is used to define terminology. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-cdni-redirection/ When IESG discussion begins, it can be tracked via https://datatracker.ietf.org/doc/draft-ietf-cdni-redirection/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/2657/ From nobody Wed Mar 2 12:30:36 2016 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 21DDC1B2FA1 for ; Wed, 2 Mar 2016 12:30:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 aLJdB572mQWQ for ; Wed, 2 Mar 2016 12:30:31 -0800 (PST) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::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 3F6ED1B2F9B for ; Wed, 2 Mar 2016 12:30:26 -0800 (PST) Received: by mail-yw0-x22e.google.com with SMTP id e63so484455ywc.3 for ; Wed, 02 Mar 2016 12:30:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=SUOMXvGhBXzscbZzDkLBMXvttatssZXUvND6yybuBP8=; b=obZprC/fgtMQKxPnbXE9T9zG+CduoTXfAKKVEsaC0Q+VE0qsruR9xd5XywxgHZQenc 7jpcs8g5H6QefhTbczwBhxuHfUdUWn1jS0VuP4Z2XiolErZEE6A4CI0viePK/6dK3Nvh 3cCBjPtS8FByNH0N/eU/O2haqors+OyIs1yQHjvXG7IbNJF22epput1Vl+cwz6praDG1 7J3kdr0YEw2Gf2t3M8zB+L0miTcnRY+TBFstQANrSoOMbf+Nl+7ByiTzP10Vxdu5QipC HkBEEf+H8YXy0fJdBym3a+0GtU4s/GshqTUIEmKvjKldTUhY++CTJY+eNrFAUzUTFTko geEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=SUOMXvGhBXzscbZzDkLBMXvttatssZXUvND6yybuBP8=; b=fj3pvkyii7svrvMZoIcHwY6XhR72zGi0R+Aw4asp7ThaWsUBQ3dT9DvbUvxAhFMFH4 xKBCfAeSEv3iKKyBAAuCbGhLPvSA9FVUprxDdNSdVZtbacczgItZrrqfsh2P8OMbuJxx XPG0BNcmzZIGvqCrVh36PCl9PYPjdZD/XfuDqf5Q20kJfQgobugWasmCP2y5ehy+52S+ ky6vguFCQEcwx61wcHralCZWkGEntYr2HdQOp4YACy6RXFGCib+Eko6//DZSKMCbB2qY aD3tKVnlWoj0y9XsxqInoCIhqFZycvBcouv/eaIVUJvxdbssNQcpCV0iigwlRXbiQbQL xZNA== X-Gm-Message-State: AD7BkJKsVuuttw+lyRqlxYpQs4y0224QCh6+rByP4hSzJ0kt+0knSa4zSM5045tNnJTsOv0BS9DaO/etMJ3rNw== MIME-Version: 1.0 X-Received: by 10.129.155.151 with SMTP id s145mr15586896ywg.24.1456950625560; Wed, 02 Mar 2016 12:30:25 -0800 (PST) Received: by 10.37.115.2 with HTTP; Wed, 2 Mar 2016 12:30:25 -0800 (PST) In-Reply-To: <4220D1BD-2D43-4299-8CB5-73E3FEAADBC3@cisco.com> References: <20160302134957.19134.42315.idtracker@ietfa.amsl.com> <4220D1BD-2D43-4299-8CB5-73E3FEAADBC3@cisco.com> Date: Wed, 2 Mar 2016 14:30:25 -0600 Message-ID: From: Spencer Dawkins at IETF To: Barry Leiba Content-Type: multipart/alternative; boundary=94eb2c0b8da87df3d7052d16c0bf Archived-At: Cc: "" , Pete Resnick , Stephen Farrell Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-logging-22.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: Wed, 02 Mar 2016 20:30:34 -0000 --94eb2c0b8da87df3d7052d16c0bf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Barry, On Wed, Mar 2, 2016 at 8:10 AM, Francois Le Faucheur (flefauch) < flefauch@cisco.com> wrote: > Hello, > > This version addresses: > * minor and final comments regarding ABNF from Pete Resnick (provided in > Yokohama) > If I'm reading the runes correctly, you took over Pete's discuss on the ABNF for this draft. If that's correct, could you take a look at -22 and see if you can clear? That will leave us with two open items (below), and I'm hoping these can be closed before Buenos Aires (the draft loses two or three no-OBJs when the new IESG is seated, and it already needs one more from a sitting AD to pass). Thanks, all, Spencer > * Stephen Farrell=E2=80=99s DISCUSS that was discussed on the working gro= up list ( > http://www.ietf.org/mail-archive/web/cdni/current/msg02357.html) > > That leaves two open items to fix, as per the CDNI Working Group Yokohama > meeting minutes: > " > o Need to update the text related to choice of algorithm for mapping the > IP addresses; Need to ensure text reflects which approach is =E2=80=9Cman= datory to > implement=E2=80=9D to ensure interoperability. This was discussed on the > list. Please raise concerns on the list asap, if any. > o Resolve comment from Kevin about what approach to take for extending > logging > =E2=80=9C > > Cheers > > Fran=C3=A7ois > > > On 2 Mar 2016, at 14:49, internet-drafts@ietf.org wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Content Delivery Networks Interconnectio= n > of the IETF. > > Title : CDNI Logging Interface > Authors : Francois Le Faucheur > Gilles Bertrand > Iuniana Oprescu > Roy Peterkofsky > Filename : draft-ietf-cdni-logging-22.txt > Pages : 57 > Date : 2016-03-02 > > Abstract: > This memo specifies the Logging interface between a downstream CDN > (dCDN) and an upstream CDN (uCDN) that are interconnected as per the > CDN Interconnection (CDNI) framework. First, it describes a > reference model for CDNI logging. Then, it specifies the CDNI > Logging File format and the actual protocol for exchange of CDNI > Logging Files. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-cdni-logging/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-cdni-logging-22 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-logging-22 > > > 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/ > > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > > > --94eb2c0b8da87df3d7052d16c0bf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Barry,

On Wed, Mar 2, 2016 at 8:10 AM, Francois Le Faucheur (flefauch) <= span dir=3D"ltr"><flefauch@cisco.com> wrote:
Hello,

This version addresses:
* minor and final comments= regarding ABNF from Pete Resnick (provided in Yokohama)

If I'm reading the runes correctly, you took = over Pete's discuss on the ABNF for this draft.=C2=A0

If that's correct, could you take a look at -22 and see if you = can clear?

That will leave us with two open items = (below), and I'm hoping these can be closed before Buenos Aires (the dr= aft loses two or three no-OBJs when the new IESG is seated, and it already = needs one more from a sitting AD to pass).

Thanks,= all,

Spencer
=C2=A0
* Stephen Farrell=E2=80=99= s DISCUSS that was discussed on the working group list (= http://www.ietf.org/mail-archive/web/cdni/current/msg02357.html)

That leaves two open items to fix, as per the CDNI Working Group Yokoh= ama meeting minutes:
"
o Need to update the text relat= ed to choice of algorithm for mapping the IP addresses;=C2=A0Need to ensure= =C2=A0text reflects which approach is =E2=80=9Cmandatory to implement=E2=80= =9D to ensure interoperability. This was discussed on the list.=C2=A0Please raise concerns on the list asap, if any.
o Resolve comment from Kev= in about what approach to take for extending logging=C2=A0
=E2=80=9C

Cheers

Fran=C3=A7ois


On 2 Mar 2016, at 14:49, internet-drafts@ietf.org wrote:


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

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Title =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: CDNI Logging Interface
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Authors =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0: Francois Le Faucheur
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= Gilles Bertrand
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= Iuniana Oprescu
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= Roy Peterkofsky
Filename =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0: draft-ietf-cdni-logging-22.txt
Pages =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: 57
Date =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: 2016-03-02

Abstract:
=C2=A0=C2=A0This memo specifies the Logging interface between a downstream = CDN
=C2=A0=C2=A0(dCDN) and an upstream CDN (uCDN) that are interconnected as pe= r the
=C2=A0=C2=A0CDN Interconnection (CDNI) framework.=C2=A0 First, it describes= a
=C2=A0=C2=A0reference model for CDNI logging.=C2=A0 Then, it specifies the = CDNI
=C2=A0=C2=A0Logging File format and the actual protocol for exchange of CDN= I
=C2=A0=C2=A0Logging Files.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-cdni-logging/<= br>
There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-cdni-logging-22

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-loggi= ng-22


Please note that it may take a couple of minutes from the time of submissio= n
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/

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


--94eb2c0b8da87df3d7052d16c0bf-- From nobody Thu Mar 3 14:28:00 2016 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 0019A1B2DD4; Thu, 3 Mar 2016 14:27:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 aaiOEMOixj5z; Thu, 3 Mar 2016 14:27:56 -0800 (PST) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74DDD1B2DD1; Thu, 3 Mar 2016 14:27:55 -0800 (PST) X-AuditID: c6180641-f799c6d000007d66-a5-56d8ba4bd80b Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 76.FA.32102.B4AB8D65; Thu, 3 Mar 2016 23:27:23 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0248.002; Thu, 3 Mar 2016 17:27:51 -0500 From: Kevin Ma J To: Francois Le Faucheur , "draft-ietf-cdni-footprint-capabilities-semantics@ietf.org" Thread-Topic: Comments on draft-ietf-cdni-footprint-capabilities-semantics-09 Thread-Index: AQHRdZAnTT6+xnUzeUivQGImnatU259ISiiA Date: Thu, 3 Mar 2016 22:27:50 +0000 Message-ID: References: <34517284-7A2A-4332-8FDF-794B07F1629F@gmail.com> In-Reply-To: <34517284-7A2A-4332-8FDF-794B07F1629F@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrHLMWRmVeSWpSXmKPExsUyuXRPuK73rhthBp+3mFs8nf2H1eL13GtM Fu9f72Z0YPbYOesuu8eSJT+ZApiiuGxSUnMyy1KL9O0SuDIWXZ3FWjDPqOLnq3/sDYw/DLoY OTgkBEwkzq9W72LkBDLFJC7cW8/WxcjFISRwhFHi44JNTBDOMkaJvv7tbCBVbAJaEo+//gVL iAisYpRYv2kfO0iCWUBVom/qQbAiYQEfiRsTXjKBbBAR8JU4u4MbJCwiYCTxZdJWsBIWARWJ n1tusYDYvEAlX79cYAWxhQRsJCav6GEGsTkFbCXaD6xnBLEZga77fmoNE8QqcYlbT+YzQVwt ILFkz3lmCFtU4uXjf6wQtpLEpKXnWEFOYBbQlFi/Sx+iVVFiSvdDdoi1ghInZz5hmcAoNgvJ 1FkIHbOQdMxC0rGAkWUVI0dpcUFObrqR4SZGYKwck2Bz3MG4t9fzEKMAB6MSD++GFdfDhFgT y4orcw8xSnAwK4nwKvXdCBPiTUmsrEotyo8vKs1JLT7EKM3BoiTO++3j5TAhgfTEktTs1NSC 1CKYLBMHp1QDY+P+/d/6dZcd0heyk7wqtGC7UsQJtbltUV/FepYv/2B63rv6rtCqC+WLt8W/ 1p+6Yo9JLON21tWOt1VZpkzZ+7Oat12uxHB3Z+tEscmXvnIsn/lUOemtTotJ7+eqm1q/1WYc emGlJXVKwtK5pNOtM36bxOqFiszmaUcXpivZPz7C+TY/30FbT4mlOCPRUIu5qDgRANck/NyR AgAA Archived-At: Cc: "" Subject: Re: [CDNi] Comments on draft-ietf-cdni-footprint-capabilities-semantics-09 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: Thu, 03 Mar 2016 22:27:59 -0000 SGkgRnJhbmNvaXMsDQoNCiAgVGhhbmsgeW91IGZvciB0aGUgcmV2aWV3LiAgSSBhZ3JlZSB3aXRo IGFsbCB5b3VyIHN1Z2dlc3Rpb25zIGJlbG93IGFuZCBoYXZlIGFsc28gY2xlYW5lZCB1cCB0aGUg MjExOSBsYW5ndWFnZSBhbmQgcmVtb3ZlZCB0aGUgImZlZGVyYXRpb24iIGxhbmd1YWdlLiAgSSB3 aWxsIGJlIHVwbG9hZGluZyBhIG5ldyB2ZXJzaW9uIHNob3J0bHkuDQoNCnRoYW54IQ0KDQotLSAg S2V2aW4gSi4gTWENCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBGcmFu Y29pcyBMZSBGYXVjaGV1ciBbbWFpbHRvOmZsZWZhdWNoQGdtYWlsLmNvbV0NCj4gU2VudDogVGh1 cnNkYXksIE1hcmNoIDAzLCAyMDE2IDQ6MDMgUE0NCj4gVG86IGRyYWZ0LWlldGYtY2RuaS1mb290 cHJpbnQtY2FwYWJpbGl0aWVzLXNlbWFudGljc0BpZXRmLm9yZw0KPiBDYzogPGNkbmlAaWV0Zi5v cmc+DQo+IFN1YmplY3Q6IENvbW1lbnRzIG9uIGRyYWZ0LWlldGYtY2RuaS1mb290cHJpbnQtY2Fw YWJpbGl0aWVzLXNlbWFudGljcy0wOQ0KPiANCj4gRGVhciBGQ0kgc2VtYW50aWNzIGF1dGhvcnMg YW5kIGFsbCwNCj4gDQo+IA0KPiBBcyBwYXJ0IG9mIHRoZSBkb2N1bWVudCBzaGVwaGVyZGluZywg aSBkaWQgYSBXRyBjaGFpciByZXZpZXcgb2YgdGhlIGxhdGVzdA0KPiB2ZXJzaW9uLCBhbmQgaGF2 ZSB0aGUgY29tbWVudHMgYmVsb3cuDQo+IA0KPiBDaGVlcnMNCj4gDQo+IEZyYW5jb2lzDQo+IA0K PiANCj4gU2lnbmlmaWNhbnQgQ29tbWVudDoNCj4gPT09PT09PT09PT09PT09PQ0KPiBJIHRoaW5r IHRoZSBkb2N1bWVudCBuZWVkcyBhIGNsZWFuIHVwIG9mIGl0cyB1c2Ugb2YgbWFueSDigJxtdXN0 c+KAnSBhbmQNCj4g4oCcbmVlZHPigJ0gZXRjLg0KPiANCj4gSW4gc2VjdGlvbiA0ICwg4oCcTVVT VOKAnSBpcyB1c2VkLCBJIGJlbGlldmUgY29ycmVjdGx5ICwgZS5nLiDigJwgdGhlcmVmb3JlDQo+ IGNvbnN0aXR1dGUgbWFuZGF0b3J5IGNhcGFiaWxpdGllcyB0aGF0IE1VU1QgYmUgc3VwcG9ydGVk IGJ5IHRoZSBDRE5JDQo+IEZDSTrigJ0uDQo+IA0KPiBCdXQgdGhlcmUgYXJlIGFsc28gbWFueSBv Y2N1cnJlbmNlcyBpbiB0aGUgZG9jdW1lbnQgb2Yg4oCcbXVzdOKAnS4gTW9zdCBvZg0KPiB0aGVz ZSBzaG91bGQgcHJvYmFibHkgYmUgc2ltcGx5IHJlcGxhY2VkIGJ5IOKAnG5lZWRzIHRv4oCdICh3 aGVyZSBpdCBpcw0KPiBpbnRlbmRlZCBub3QgdG8gbWVhbiBhbnl0aGluZyBtYW5kYXRvcnkgdG8g aW1wbGVtZW50KS4NCj4gRm9yIGV4YW1wbGUsIGluIHNlY3Rpb24gNCwgaXQgc2F5cyAiZG93bnN0 cmVhbSBDRE4gbXVzdCBiZSBhYmxlIHRvIC4uLuKAnS4NCj4gU2ltaWxhcmx5LCBpbiBzZWN0aW9u IDUgaXQgc2F5cyAidGhlIGRDRE4gbXVzdCBiZSBhYmxlIHRvIOKApiINCj4gDQo+IEluIHNlY3Rp b24gNywgaXQgc2F5czogIlRoZXJlZm9yZSwgYW55IEZDSSBzb2x1dGlvbiBwcm90b2NvbCBtdXN0 IGRlZmluZQ0KPiAgICBob3cgdGhlIHN1cHBvcnQgZm9yIG9wdGlvbmFsIHR5cGVzIG9mIGZvb3Rw cmludC9jYXBhYmlsaXRpZXMgd2lsbCBiZQ0KPiAgICBuZWdvdGlhdGVkIGJldHdlZW4gYSB1Q0RO IGFuZCBhIGRDRE4gdGhhdCB1c2UgdGhlIHBhcnRpY3VsYXIgRkNJDQo+ICAgIHByb3RvY29sLuKA nQ0KPiBJIHRoaW5rIHRoYXQgc2hvdWxkIGJlIGEgTVVTVC4NCj4gQW5kIHNpbWlsYXJseSwgc3Rp bGwgaW4gc2VjdGlvbiA3LCBpdCBzYXlzOiAiYW55IEZDSSBzb2x1dGlvbiBwcm90b2NvbA0KPiBu ZWVkcyB0byBzcGVjaWZ54oCdIGFuZCBJIHRoaW5rIHRoYXQgc2hvdWxkIHByb2JhYmx5IGJlIGEg Ik1VU1Qgc3BlY2lmeeKAnS4NCj4gDQo+IA0KPiBFZGl0b3JpYWwgQ29tbWVudHMNCj4gPT09PT09 PT09PT09PT09PQ0KPiANCj4gDQo+ICoqKiBBYnN0cmFjdDoNCj4gT0xEOg0KPiDigJwNCj4gZ3Vp ZGVsaW5lcyBob3cNCj4g4oCcDQo+IE5FVzoNCj4g4oCcDQo+IGd1aWRlbGluZXMgb24gaG93DQo+ IOKAnA0KPiANCj4gDQo+IFRoZXJlIGFyZSBNQU5ZIG9jY3VycmVuY2VzIG9mIHRoZSB0ZXJtcyDi gJxmZWRlcmF0aW9uL2ZlZGVyYXRlL2ZlZGVyYXRlZOKAnSBpbg0KPiB0aGUgZG9jdW1lbnQuIFRo b3NlIG5lZWQgdG8gYmUgYWxsIHJlbW92ZWQgYW5kIHJlcGxhY2VkIHNpbXBseSB3aXRoDQo+IOKA nGludGVyY29ubmVjdGVkIENETnPigJ0gb3Igc29tZXRoaW5nIGxpa2UgdGhhdC4NCj4gVGhlIHJl YXNvbiBpcyB0aGF0IOKAnENETiBGZWRlcmF0aW9u4oCdIGlzIGEgdGVybSBkaXNjdXNzZWQgaW4g c2VjdGlvbiA1LjQgb2YNCj4gdGhlIENETkkgRnJhbWV3b3JrIGRvY3VtZW50IChSRkMgNzMzNikg d2l0aCBhIHNwZWNpZmljIG1lYW5pbmcgdGhhdCBpcyBOT1QNCj4gd2hhdCBpcyBpbnRlbmRlZCBo ZXJlLg0KPiANCj4gDQo+IA0KPiANCj4gKioqIHNlY3Rpb24gMToNCj4gT0xEOg0KPiDigJwNCj4g VGhlIHVDRE4gaGFzIHJlY2VpdmVkDQo+IOKAnA0KPiBORVc6DQo+IOKAnA0KPiBUaGUgdUNETiBy ZWNlaXZlcw0KPiDigJwNCj4gDQo+IA0KPiANCj4gDQo+ICoqKiBzZWN0aW9uIDE6DQo+IE9MRDoN Cj4g4oCcDQo+IGRlc2NyaWJlcyBmb290cHJpbnQgYW5kIGNhcGFiaWxpdGllcyBhZHZlcnRpc2Vt ZW50IGFzDQo+IOKAnA0KPiBORVc6DQo+IOKAnA0KPiBkZXNjcmliZXMgdGhlIFJlcXVlc3QgUm91 dGluZyBJbnRlcmZhY2UgYXMNCj4g4oCcDQo+IA0KPiANCj4gDQo+IA0KPiAqKiogc2VjdGlvbiAx Og0KPiBPTEQ6DQo+IOKAnA0KPiBhbmQgZGV0YWlsIHRoZQ0KPiDigJwNCj4gTkVXOg0KPiDigJwN Cj4gYW5kIGRldGFpbHMgdGhlDQo+IOKAnA0KPiANCj4gDQo+ICoqKiBzZWN0aW9uIDI6DQo+IE9M RDoNCj4g4oCcDQo+IHNlZWsgdG8gZmVkZXJhdGUNCj4g4oCcDQo+IE5FVzoNCj4g4oCcDQo+IHNl ZWsgdG8gaW50ZXJjb25uZWN0DQo+IOKAnA0KPiANCj4gDQo+ICoqKiBzZWN0aW9uIDI6DQo+IE9M RDoNCj4g4oCcDQo+IG5lZWQgYmUNCj4g4oCcDQo+IE5FVzoNCj4g4oCcDQo+IG5lZWQgdG8gYmUN Cj4g4oCcDQo+IA0KPiANCj4gKioqIHNlY3Rpb24gMi4xOg0KPiBPTEQ6DQo+IOKAnA0KPiB0b3Bv bG9naWNhbGx5IGNsb3Nlc3QNCj4g4oCcDQo+IE5FVzoNCj4g4oCcDQo+IHRvcG9sb2dpY2FsbHkg Y2xvc2VyDQo+IOKAnA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IOKAnCoqKiBzZWN0aW9uIDIuNDoN Cj4gT0xEOg0KPiDigJwNCj4gT25lIHRoZSBvdGhlciBoYW5kDQo+IOKAnA0KPiBORVc6DQo+IOKA nA0KPiBPbiB0aGUgb3RoZXIgaGFuZA0KPiDigJwNCj4gDQo+IA0KPiANCj4gDQo+IOKAnCoqKiBz ZWN0aW9uIDIuNToNCj4gT0xEOg0KPiDigJwNCj4gdG8gYmUgZW52aXNpb25lZCB0aGUgbWFpbiBk ZXBsb3ltZW50cw0KPiDigJwNCj4gTkVXOg0KPiDigJwNCj4gdG8gYmUgZW52aXNpb25lZCBpbiB0 aGUgbWFpbiBkZXBsb3ltZW50cw0KPiDigJwNCj4gDQo+IA0KPiANCj4gDQo+IOKAnCoqKiBzZWN0 aW9uIDQ6DQo+IE9MRDoNCj4g4oCcDQo+IEEgJ3NldCBvZiBJUC1wcmVmaXhlcycgbXVzdCBiZSBh YmxlDQo+IOKAnA0KPiBORVc6DQo+IOKAnA0KPiBBICdzZXQgb2YgSVAtcHJlZml4ZXMnIE1VU1Qg YmUgYWJsZQ0KPiDigJwNCj4gDQo+IA0KPiANCj4gDQo+IOKAnCoqKiBzZWN0aW9uIDQ6DQo+IE9M RDoNCj4g4oCcDQo+IFRoZXJlIG11c3QgYWxzbw0KPiDigJwNCj4gTkVXOg0KPiDigJwNCj4gVGhl cmUgTVVTVCBhbHNvDQo+IOKAnA0KPiANCj4gDQo+IA0KPiANCj4g4oCcKioqIHNlY3Rpb24gNDoN Cj4gT0xEOg0KPiDigJwNCj4gbWF5IGRlZmluZWQNCj4g4oCcDQo+IE5FVzoNCj4g4oCcDQo+IG1h eSBiZSBkZWZpbmVkDQo+IOKAnA0KPiANCj4gDQo+IOKAnCoqKiBzZWN0aW9uIDQ6DQo+IE9MRDoN Cj4g4oCcDQo+IFtJLUQuaWV0Zi1jZG5pLW1ldGFkYXRhXSgNCj4g4oCcDQo+IE5FVzoNCj4g4oCc DQo+IFtJLUQuaWV0Zi1jZG5pLW1ldGFkYXRhXSkNCj4g4oCcDQo+IA0KPiANCj4gDQo+IOKAnCoq KiBzZWN0aW9uIDQ6DQo+IE9MRDoNCj4g4oCcDQo+IGNhc2VzIHdoZXJlIHRoZXJlIGlzIGEgdHJh bnNpdGl2ZSBDRE4gaW50ZXJjb25uZWN0aW9uDQo+IOKAnA0KPiBORVc6DQo+IOKAnA0KPiBjYXNl cyBvZiBjYXNjYWRlZCBDRE5zDQo+IOKAnA0KPiANCj4gDQo+ICoqKiBzZWN0aW9uIDU6DQo+IE9M RDoNCj4g4oCcDQo+IEl0IGlzIG5vdCBmZWFzYWJsZQ0KPiDigJwNCj4gTkVXOg0KPiDigJwNCj4g SXQgaXMgbm90IGZlYXNpYmxlDQo+IOKAnA0KPiANCj4gDQo+IOKAnCoqKiBzZWN0aW9uIDguMS4y Og0KPiBPTEQ6DQo+IOKAnA0KPiBDRE5JIEZDSSBBY3VpcWlzaXRpb25Qcm90b2NvbA0KPiDigJwN Cj4gTkVXOg0KPiDigJwNCj4gQ0ROSSBGQ0kgQWNxdWlzaXRpb25Qcm90b2NvbA0KPiDigJwNCj4g DQo+IA0KPiAqKiogc2VjdGlvbiA5Og0KPiBPTEQ6DQo+IOKAnA0KPiBhbmQgZm9vdHByaW50IGFk dmVydGlzZW1lbnQgb2JqZWN0cyBpbiBjb250ZW50IGRpc3RyaWJ1dGlvbiBuZXR3b3Jrcy4NCj4g 4oCcDQo+IE5FVzoNCj4g4oCcDQo+IGFuZCBmb290cHJpbnQgYWR2ZXJ0aXNlbWVudCBvYmplY3Rz IGFjcm9zcyBpbnRlcmNvbm5lY3RlZCBDRE5zLg0KPiDigJwNCj4gDQo+IA0KPiANCj4gKioqIHNl Y3Rpb24gOToNCj4gT0xEOg0KPiDigJwNCj4gQ0ROaQ0KPiDigJwNCj4gTkVXOg0KPiDigJwNCj4g Q0ROSQ0KPiDigJwNCj4gDQo+IA0KDQo= From nobody Thu Mar 3 14:41:43 2016 Return-Path: X-Original-To: cdni@ietf.org Delivered-To: cdni@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E88591B2E71; Thu, 3 Mar 2016 14:41:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.15.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160303224139.14246.2661.idtracker@ietfa.amsl.com> Date: Thu, 03 Mar 2016 14:41:39 -0800 Archived-At: Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-footprint-capabilities-semantics-10.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: Thu, 03 Mar 2016 22:41:40 -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 of the IETF. Title : CDNI Request Routing: Footprint and Capabilities Semantics Authors : Jan Seedorf Jon Peterson Stefano Previdi Ray van Brandenburg Kevin J. Ma Filename : draft-ietf-cdni-footprint-capabilities-semantics-10.txt Pages : 21 Date : 2016-03-03 Abstract: This document captures the semantics of the "Footprint and Capabilities Advertisement" part of the CDNI Request Routing interface, i.e., the desired meaning of "Footprint" and "Capabilities" in the CDNI context, and what the "Footprint and Capabilities Advertisement Interface (FCI)" offers within CDNI. The document also provides guidelines for the CDNI FCI protocol. It further defines a Base Advertisement Object, the necessary registries for capabilities and footprints, and guidelines on how these registries can be extended in the future. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-footprint-capabilities-semantics/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-cdni-footprint-capabilities-semantics-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-footprint-capabilities-semantics-10 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 Thu Mar 3 14:43:41 2016 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 71AA31B2E8C for ; Thu, 3 Mar 2016 14:43:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 026_w89sG3hW for ; Thu, 3 Mar 2016 14:43:38 -0800 (PST) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4CCF1B2E84 for ; Thu, 3 Mar 2016 14:43:35 -0800 (PST) X-AuditID: c6180641-f799c6d000007d66-37-56d8bdf40ca0 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 97.BB.32102.4FDB8D65; Thu, 3 Mar 2016 23:43:00 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0248.002; Thu, 3 Mar 2016 17:43:28 -0500 From: Kevin Ma J To: "cdni@ietf.org" Thread-Topic: [CDNi] I-D Action: draft-ietf-cdni-footprint-capabilities-semantics-10.txt Thread-Index: AQHRdZ3t55yoVfMJUUe0JNN0V5wDMp9IUM3A Date: Thu, 3 Mar 2016 22:43:26 +0000 Message-ID: References: <20160303224139.14246.2661.idtracker@ietfa.amsl.com> In-Reply-To: <20160303224139.14246.2661.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKLMWRmVeSWpSXmKPExsUyuXSPn+6XvTfCDPa90bJ4OvsPqwOjx5Il P5kCGKO4bFJSczLLUov07RK4Mn5NmMFU8F244nLLV/YGxsX8XYycHBICJhJbfhxngrDFJC7c W8/WxcjFISRwhFFiTet9dghnGaPE2yn3mUGq2AS0JB5//QvUwcEhIqAs8fOQI0hYWCBSYmnz TEYQW0QgSuL+QxjbSGLCt6usIDaLgIrEr5tN7CA2r4CvxMGzv8BGCgk4SFxdPBWsnlPAUWLe pGawOCPQQd9PrQE7jllAXOLWk/lQhwpILNlznhnCFpV4+fgfK4StJDFp6TlWiHodiQW7P7FB 2NoSyxa+ZobYKyhxcuYTlgmMorOQjJ2FpGUWkpZZSFoWMLKsYuQoLS7IyU03MtzECAz8YxJs jjsY9/Z6HmIU4GBU4uHdsOJ6mBBrYllxZe4hRgkOZiURXqW+G2FCvCmJlVWpRfnxRaU5qcWH GKU5WJTEeb99vBwmJJCeWJKanZpakFoEk2Xi4JRqYEyLOhQx1Uo57YDpDFMe5y7+iZaORxyz E5LaLyxnczvl+7BvRsPz/XGyMf37XmR5frjA/Xi+j6PO9rRNOz94hj26soBBO1vE9oLyyZzV SYqbTKe4dhtuMFLeXr80ecLV5aKNXeeicj7MlyudtCE92rStr9Vk/0ndpp5tdxe77zr5Meb5 I6Zzv5VYijMSDbWYi4oTAarXiJZ4AgAA Archived-At: Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-footprint-capabilities-semantics-10.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: Thu, 03 Mar 2016 22:43:40 -0000 Hi all, This update addresses Francois's shepherd review comments. thanx! -- Kevin J. Ma > -----Original Message----- > From: CDNi [mailto:cdni-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Thursday, March 03, 2016 5:42 PM > To: i-d-announce@ietf.org > Cc: cdni@ietf.org > Subject: [CDNi] I-D Action: draft-ietf-cdni-footprint-capabilities- > semantics-10.txt >=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 Interconnectio= n > of the IETF. >=20 > Title : CDNI Request Routing: Footprint and Capabilitie= s > Semantics > Authors : Jan Seedorf > Jon Peterson > Stefano Previdi > Ray van Brandenburg > Kevin J. Ma > Filename : draft-ietf-cdni-footprint-capabilities-semantics- > 10.txt > Pages : 21 > Date : 2016-03-03 >=20 > Abstract: > This document captures the semantics of the "Footprint and > Capabilities Advertisement" part of the CDNI Request Routing > interface, i.e., the desired meaning of "Footprint" and > "Capabilities" in the CDNI context, and what the "Footprint and > Capabilities Advertisement Interface (FCI)" offers within CDNI. The > document also provides guidelines for the CDNI FCI protocol. It > further defines a Base Advertisement Object, the necessary registries > for capabilities and footprints, and guidelines on how these > registries can be extended in the future. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-cdni-footprint-capabilities- > semantics/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-cdni-footprint-capabilities- > semantics-10 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-footprint-capabilitie= s- > semantics-10 >=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 Thu Mar 3 23:40:43 2016 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 2F1D01A8903; Thu, 3 Mar 2016 13:03:31 -0800 (PST) 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, SPF_PASS=-0.001] 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 jWjoD3VbyJLD; Thu, 3 Mar 2016 13:03:29 -0800 (PST) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (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 4BD951A88FF; Thu, 3 Mar 2016 13:03:26 -0800 (PST) Received: by mail-wm0-x230.google.com with SMTP id l68so6595588wml.1; Thu, 03 Mar 2016 13:03:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-transfer-encoding:subject:date:message-id:cc:to :mime-version; bh=6jRjBsOXcie9jRXM/QmhSVbm/mUfqUgNr/XoHj4XRPw=; b=vS0e56YdQeBbVC3BfaF3ZJMehPznpW8MbPT3FmCyC6Nb93+So1GfmY9D5Avve7CO/9 N3I5PEedtHklrhahWlHDxL8xfhI6HnH+yjuZWz/6mdkgw8QjtsLeF487lRbqiE/NRL00 jZzUOHyKq2EwrU/bHOUSfLfFDpHvUHnmMGJIwlAz/+k1wlNo9nTEHHyApnSlLQdIpIh6 A+aI4gaC76DY4falptZfnfBpNT8MVRkDyRbzm6pdf8kFH6CL2DOknKn/yS/m/1JFRShb thxG/exvCKPp47Av7ZvKUqNS1p6B+0F09xrDDKrQra2On9+sdKeJcLrhqMi/ZX3pXAMd sxAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject:date :message-id:cc:to:mime-version; bh=6jRjBsOXcie9jRXM/QmhSVbm/mUfqUgNr/XoHj4XRPw=; b=lYBdZFxJEm+YcB3d1xhorwCxaANE8DVefvZ+x5eNbHrteiUiF4X4+u47lpDiHjQ/dU 1im44OFX8zOMbaq/mQHfHFtpe2wTDOWytri5adoaw/ZAJ5bV+AZDGIt+VxNiBbwD2RpS xNuiNDXR727i1x2SRTn6du09RxxnlCZwdfjMJYMjA+8DE/bHOkRapnhL4/n9PPZ9phLV 8qI5M/noqvwlJX893n5nHXP0QxYwF9mvL4pLDBwu9CITxDaMN2tXjpjPBHs5HGHmKKMl LRev7+Gi7Fw5X8ta3pSzLylMh6TdtrexU8YNQJCA6ydzmRiYYpK2uAvGZysPGhh8+IY3 YhQQ== X-Gm-Message-State: AD7BkJJsFSCJWzaKTT5RmCHACMUfPty///6/oOoGlE3sI5KmwOZV+lGzvZJu2L3FNUXMbg== X-Received: by 10.28.125.86 with SMTP id y83mr1182510wmc.27.1457039004856; Thu, 03 Mar 2016 13:03:24 -0800 (PST) Received: from ams-flefauch-nitro6.cisco.com ([173.38.220.33]) by smtp.gmail.com with ESMTPSA id 198sm245859wml.22.2016.03.03.13.03.23 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 03 Mar 2016 13:03:24 -0800 (PST) From: Francois Le Faucheur Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Thu, 3 Mar 2016 22:03:21 +0100 Message-Id: <34517284-7A2A-4332-8FDF-794B07F1629F@gmail.com> To: draft-ietf-cdni-footprint-capabilities-semantics@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: X-Mailman-Approved-At: Thu, 03 Mar 2016 23:40:41 -0800 Cc: "" Subject: [CDNi] Comments on draft-ietf-cdni-footprint-capabilities-semantics-09 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: Thu, 03 Mar 2016 21:03:31 -0000 Dear FCI semantics authors and all, As part of the document shepherding, i did a WG chair review of the = latest version, and have the comments below.=20 Cheers Francois Significant Comment: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I think the document needs a clean up of its use of many =E2=80=9Cmusts=E2= =80=9D and =E2=80=9Cneeds=E2=80=9D etc. In section 4 , =E2=80=9CMUST=E2=80=9D is used, I believe correctly , = e.g. =E2=80=9C therefore constitute mandatory capabilities that MUST be = supported by the CDNI FCI:=E2=80=9D. =20 But there are also many occurrences in the document of =E2=80=9Cmust=E2=80= =9D. Most of these should probably be simply replaced by =E2=80=9Cneeds = to=E2=80=9D (where it is intended not to mean anything mandatory to = implement). For example, in section 4, it says "downstream CDN must be able to = ...=E2=80=9D. Similarly, in section 5 it says "the dCDN must be able to =E2=80=A6" In section 7, it says: "Therefore, any FCI solution protocol must define how the support for optional types of footprint/capabilities will be negotiated between a uCDN and a dCDN that use the particular FCI protocol.=E2=80=9D I think that should be a MUST. And similarly, still in section 7, it says: "any FCI solution protocol = needs to specify=E2=80=9D and I think that should probably be a "MUST = specify=E2=80=9D. Editorial Comments =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D *** Abstract: OLD: =E2=80=9C guidelines how =E2=80=9C NEW: =E2=80=9C guidelines on how =E2=80=9C There are MANY occurrences of the terms = =E2=80=9Cfederation/federate/federated=E2=80=9D in the document. Those = need to be all removed and replaced simply with =E2=80=9Cinterconnected = CDNs=E2=80=9D or something like that. The reason is that =E2=80=9CCDN Federation=E2=80=9D is a term discussed = in section 5.4 of the CDNI Framework document (RFC 7336) with a specific = meaning that is NOT what is intended here.=20 *** section 1: OLD: =E2=80=9C The uCDN has received =E2=80=9C NEW: =E2=80=9C The uCDN receives =E2=80=9C *** section 1: OLD: =E2=80=9C describes footprint and capabilities advertisement as =E2=80=9C NEW: =E2=80=9C describes the Request Routing Interface as =E2=80=9C *** section 1: OLD: =E2=80=9C and detail the =E2=80=9C NEW: =E2=80=9C and details the =E2=80=9C *** section 2: OLD: =E2=80=9C seek to federate =E2=80=9C NEW: =E2=80=9C seek to interconnect =E2=80=9C *** section 2: OLD: =E2=80=9C need be =E2=80=9C NEW: =E2=80=9C need to be =E2=80=9C *** section 2.1: OLD: =E2=80=9C topologically closest =E2=80=9C NEW: =E2=80=9C topologically closer =E2=80=9C =E2=80=9C*** section 2.4: OLD: =E2=80=9C One the other hand =E2=80=9C NEW: =E2=80=9C On the other hand =E2=80=9C =E2=80=9C*** section 2.5: OLD: =E2=80=9C to be envisioned the main deployments =E2=80=9C NEW: =E2=80=9C to be envisioned in the main deployments =E2=80=9C =E2=80=9C*** section 4: OLD: =E2=80=9C A 'set of IP-prefixes' must be able =E2=80=9C NEW: =E2=80=9C A 'set of IP-prefixes' MUST be able =E2=80=9C =E2=80=9C*** section 4: OLD: =E2=80=9C There must also =E2=80=9C NEW: =E2=80=9C There MUST also =E2=80=9C =E2=80=9C*** section 4: OLD: =E2=80=9C may defined =E2=80=9C NEW: =E2=80=9C may be defined =E2=80=9C =E2=80=9C*** section 4: OLD: =E2=80=9C [I-D.ietf-cdni-metadata]( =E2=80=9C NEW: =E2=80=9C [I-D.ietf-cdni-metadata]) =E2=80=9C =E2=80=9C*** section 4: OLD: =E2=80=9C cases where there is a transitive CDN interconnection =E2=80=9C NEW: =E2=80=9C cases of cascaded CDNs =E2=80=9C *** section 5: OLD: =E2=80=9C It is not feasable =E2=80=9C NEW: =E2=80=9C It is not feasible =E2=80=9C =E2=80=9C*** section 8.1.2: OLD: =E2=80=9C CDNI FCI AcuiqisitionProtocol =E2=80=9C NEW: =E2=80=9C CDNI FCI AcquisitionProtocol =E2=80=9C *** section 9: OLD: =E2=80=9C and footprint advertisement objects in content distribution networks. =E2=80=9C NEW: =E2=80=9C and footprint advertisement objects across interconnected CDNs. =E2=80=9C *** section 9: OLD: =E2=80=9C CDNi =E2=80=9C NEW: =E2=80=9C CDNI =E2=80=9C From nobody Fri Mar 4 01:42:43 2016 Return-Path: X-Original-To: cdni@ietf.org Delivered-To: cdni@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ABB601B355A for ; Fri, 4 Mar 2016 01:10:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.15.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160304091012.27318.69686.idtracker@ietfa.amsl.com> Date: Fri, 04 Mar 2016 01:10:12 -0800 From: IETF Secretariat Archived-At: X-Mailman-Approved-At: Fri, 04 Mar 2016 01:42:42 -0800 Subject: [CDNi] Milestones changed for cdni WG 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, 04 Mar 2016 09:10:12 -0000 Changed milestone "Submit specification of the CDNI Logging interface to IESG as Proposed Standard", resolved as "Under IESG Review". Changed milestone "Submit specification of the CDNI Control interface to IESG as proposed Standard", resolved as "Under IESG Review". Changed milestone "Submit specification of the CDNI Request Routing Redirection interface to IESG as Proposed Standard", resolved as "Under IESG Review". Changed milestone "Submit specification of the CDNI Metadata interface to IESG as Proposed Standard", set due date to August 2016 from April 2015. Changed milestone "Submit specification of URI Signing for CDNI to IESG as Proposed Standard", set due date to August 2016 from August 2015. Changed milestone "Submit specification of the CDNI Footprint & Capabilities Advertisement interface to IESG as Proposed Standard", set due date to December 2016 from December 2015. URL: https://datatracker.ietf.org/wg/cdni/charter/ From nobody Fri Mar 4 06:13:35 2016 Return-Path: X-Original-To: cdni@ietf.org Delivered-To: cdni@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 629FA1A01D8 for ; Fri, 4 Mar 2016 06:13:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.15.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160304141333.27977.17169.idtracker@ietfa.amsl.com> Date: Fri, 04 Mar 2016 06:13:33 -0800 From: IETF Secretariat Archived-At: Subject: [CDNi] Milestones changed for cdni WG 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, 04 Mar 2016 14:13:33 -0000 Changed milestone "Recharter or dissolve", set due date to December 2016 from December 2015. URL: https://datatracker.ietf.org/wg/cdni/charter/ From nobody Fri Mar 4 07:33:40 2016 Return-Path: X-Original-To: cdni@ietf.org Delivered-To: cdni@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C3A1B1A219F; Fri, 4 Mar 2016 07:33:38 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.15.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160304153338.19118.33896.idtracker@ietfa.amsl.com> Date: Fri, 04 Mar 2016 07:33:38 -0800 Archived-At: Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-footprint-capabilities-semantics-11.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, 04 Mar 2016 15:33:38 -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 of the IETF. Title : CDNI Request Routing: Footprint and Capabilities Semantics Authors : Jan Seedorf Jon Peterson Stefano Previdi Ray van Brandenburg Kevin J. Ma Filename : draft-ietf-cdni-footprint-capabilities-semantics-11.txt Pages : 21 Date : 2016-03-04 Abstract: This document captures the semantics of the "Footprint and Capabilities Advertisement" part of the CDNI Request Routing interface, i.e., the desired meaning of "Footprint" and "Capabilities" in the CDNI context, and what the "Footprint and Capabilities Advertisement Interface (FCI)" offers within CDNI. The document also provides guidelines for the CDNI FCI protocol. It further defines a Base Advertisement Object, the necessary registries for capabilities and footprints, and guidelines on how these registries can be extended in the future. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-footprint-capabilities-semantics/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-cdni-footprint-capabilities-semantics-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-footprint-capabilities-semantics-11 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 Mar 4 07:35:37 2016 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 21F001A1BE4 for ; Fri, 4 Mar 2016 07:35:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 j1d-zYCkMyAV for ; Fri, 4 Mar 2016 07:35:33 -0800 (PST) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDB541A1B66 for ; Fri, 4 Mar 2016 07:35:33 -0800 (PST) X-AuditID: c618062d-f79dd6d000003091-9f-56d9a6a9e282 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 78.79.12433.9A6A9D65; Fri, 4 Mar 2016 16:15:53 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0248.002; Fri, 4 Mar 2016 10:35:32 -0500 From: Kevin Ma J To: "cdni@ietf.org" Thread-Topic: [CDNi] I-D Action: draft-ietf-cdni-footprint-capabilities-semantics-11.txt Thread-Index: AQHRditKflp4vU+MOEm0dAnuQy5F959JanVQ Date: Fri, 4 Mar 2016 15:35:31 +0000 Message-ID: References: <20160304153338.19118.33896.idtracker@ietfa.amsl.com> In-Reply-To: <20160304153338.19118.33896.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMLMWRmVeSWpSXmKPExsUyuXRPiO7KZTfDDN6tUbR4OvsPqwOjx5Il P5kCGKO4bFJSczLLUov07RK4Mg6u/sdWsFKkYu/smYwNjMf4uxg5OSQETCSmb93ADmGLSVy4 t56ti5GLQ0jgCKNE04dDLBDOMkaJ44/vM4FUsQloSTz++hfI5uAQEVCW+HnIESQsLBApcX/3 XTYQW0QgSmLp8/usECVGElfuy4OYLAIqEocmSINU8Ar4SjzdeZwFxBYScJT42dAGdgKngJPE 2i1XWUFsRqBzvp9aA7aUWUBc4taT+UwQZwpILNlznhnCFpV4+fgfK4StJDHn9TVmiHodiQW7 P7FB2NoSyxa+ZobYKyhxcuYTlgmMorOQjJ2FpGUWkpZZSFoWMLKsYuQoLS7IyU03MtjECAz6 YxJsujsY70/3PMQowMGoxMO7YcX1MCHWxLLiytxDjBIczEoivLtm3QwT4k1JrKxKLcqPLyrN SS0+xCjNwaIkzrv+7eUwIYH0xJLU7NTUgtQimCwTB6dUA6O//hJO17dvgy9Pzzj1Peau9tNk u0nZtVcVayavkPd5dHGi2u83k1bMiWItMmK1XPrPc6u3TY8W44Zm7ceJvWcFDz1o/JiWUvnK r2ZPcqSAeoRv+eIQ683uk2z/JqWrpPJM5PzkYvVUsUI6d+KjE5ENd4IyJZVVFfgfCEmVZXiV r+iaWRW5TImlOCPRUIu5qDgRALPjtG52AgAA Archived-At: Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-footprint-capabilities-semantics-11.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, 04 Mar 2016 15:35:36 -0000 Hi All, I had forgotten to fix the reference for RFC7736. This version just upda= tes the reference from ID to RFC. thanx! -- Kevin J. Ma > -----Original Message----- > From: CDNi [mailto:cdni-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Friday, March 04, 2016 10:34 AM > To: i-d-announce@ietf.org > Cc: cdni@ietf.org > Subject: [CDNi] I-D Action: draft-ietf-cdni-footprint-capabilities- > semantics-11.txt >=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 Interconnectio= n > of the IETF. >=20 > Title : CDNI Request Routing: Footprint and Capabilitie= s > Semantics > Authors : Jan Seedorf > Jon Peterson > Stefano Previdi > Ray van Brandenburg > Kevin J. Ma > Filename : draft-ietf-cdni-footprint-capabilities-semantics- > 11.txt > Pages : 21 > Date : 2016-03-04 >=20 > Abstract: > This document captures the semantics of the "Footprint and > Capabilities Advertisement" part of the CDNI Request Routing > interface, i.e., the desired meaning of "Footprint" and > "Capabilities" in the CDNI context, and what the "Footprint and > Capabilities Advertisement Interface (FCI)" offers within CDNI. The > document also provides guidelines for the CDNI FCI protocol. It > further defines a Base Advertisement Object, the necessary registries > for capabilities and footprints, and guidelines on how these > registries can be extended in the future. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-cdni-footprint-capabilities- > semantics/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-cdni-footprint-capabilities- > semantics-11 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-footprint-capabilitie= s- > semantics-11 >=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 Sat Mar 5 02:52:18 2016 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 ADB441B2DD2 for ; Sat, 5 Mar 2016 02:52:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 kPe0VJjjIfRD for ; Sat, 5 Mar 2016 02:52:15 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CBAB1B2DCE for ; Sat, 5 Mar 2016 02:52:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=654; q=dns/txt; s=iport; t=1457175135; x=1458384735; h=from:to:subject:date:message-id:references:content-id: content-transfer-encoding:mime-version; bh=oFZHZXA81h+ao8If1x1JtRytvDfGfwzGYMF6cC1Tpu0=; b=iJwxkzmHdnjUqzbSrQ6Z9IhABCm4IVOycxXhvoAP1RvGO57f/VjirwFO ENNX12ngztQwvDP/iYV2ZOs3Xrlm7K8ph45ruYLXqbJ8xmmck9MOJH5+u GdTpAPgiqdlt9BSqLMiDN51xytTqZ51+dRQr4M7SaUIkRdHDCMFFjRVxI 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D5AQBYudpW/4oNJK1dgzpSbQaqbY05g?= =?us-ascii?q?hMBDYFpIYYMgRA4FAEBAQEBAQFkJ4RCAQEDASMRVQIBIgImAgICMBUGCgIEiC0?= =?us-ascii?q?IDrAtjnMBAQEBAQEBAQEBAQEBAQEBAQEBAQERBHuHCwiCRoIMhS4rgQ8FlyoBh?= =?us-ascii?q?WKICoFNAY0sjlMBHgEBQoNkagGIL34BAQE?= X-IronPort-AV: E=Sophos;i="5.22,540,1449532800"; d="scan'208";a="77655399" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Mar 2016 10:52:14 +0000 Received: from XCH-ALN-016.cisco.com (xch-aln-016.cisco.com [173.36.7.26]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u25AqCmG008793 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Sat, 5 Mar 2016 10:52:13 GMT Received: from xch-rcd-020.cisco.com (173.37.102.30) by XCH-ALN-016.cisco.com (173.36.7.26) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sat, 5 Mar 2016 04:52:12 -0600 Received: from xch-rcd-020.cisco.com ([173.37.102.30]) by XCH-RCD-020.cisco.com ([173.37.102.30]) with mapi id 15.00.1104.009; Sat, 5 Mar 2016 04:52:11 -0600 From: "Francois Le Faucheur (flefauch)" To: "" Thread-Topic: IETF 95 Preliminary Agenda Thread-Index: AQHRdoI0MekFJCPMr0WAJvZKPA+cFA== Date: Sat, 5 Mar 2016 10:52:11 +0000 Message-ID: <48D51FEA-AA7D-4715-98C8-0758EA139B69@cisco.com> References: <20160305015607.28578.84130.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.155.23] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [CDNi] Fwd: IETF 95 Preliminary Agenda 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: Sat, 05 Mar 2016 10:52:16 -0000 RllJLg0KDQpUaGUgQ0ROSSBXRyBpcyB0ZW50YXRpdmVseSBzY2hlZHVsZWQgZm9yIFRodXJzZGF5 IDE0OjAwIHRvIDE2OjAwLg0KDQpGcmFuw6dvaXMNCg0KPiANCj4gDQo+IFRoZSBJRVRGIDk1IHBy ZWxpbWluYXJ5IGFnZW5kYSBoYXMgYmVlbiBwb3N0ZWQuICBUaGUgZmluYWwgYWdlbmRhIHdpbGwg YmUgcHVibGlzaGVkIG9uIEZyaWRheSwgTWFyY2ggMTEsIDIwMTYuICANCj4gDQo+IA0KPiBodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvOTUvYWdlbmRhLmh0bWwNCj4gaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzk1L2FnZW5kYS50eHQNCj4gDQo+IE5PVEU6 IFNlc3Npb25zIHdpbGwgYmVnaW4gYXQgMTA6MDAgZm9yIElFVEYgOTUgdG8gY29vcmRpbmF0ZSB3 aXRoIGxvY2FsIGRpbmluZyBzY2hlZHVsZXMuIA0KPiANCj4gVGhhbmsgeW91IQ0KPiANCj4gSUVU RiBTZWNyZXRhcmlhdA0KPiANCg0K From nobody Tue Mar 8 04:32:13 2016 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 913C012D660; Tue, 8 Mar 2016 04:32:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mgTyo0VDxp2w; Tue, 8 Mar 2016 04:32:09 -0800 (PST) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (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 E040112D662; Tue, 8 Mar 2016 04:32:05 -0800 (PST) Received: by mail-io0-x232.google.com with SMTP id m184so24000461iof.1; Tue, 08 Mar 2016 04:32:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc; bh=n68ChJor/bH9DEqGbUeI4LDJI6PLEDS0HZrBr0dWh8Y=; b=Gr+WeKmmmZkFds+ws+8zcntWs/cP8n50LiBgzuzQdCi81AkeqWP9cApXSU/5NOS3dm ld/rKNrPQNWa4jMz3JB3ObvAshaKo4QO0TFLeMT3BF1w4/YHSyP3Grf5MuFKgHD544ek cbNjO8eY5IVYQA7STrUuVQFhmqexU5HKSAE/K4cTeMGgrM2kML7OQHM5p3vja7qsmYjr rn/G0acZjOV+aXyTwaPtZoh0TxTQFVX36e3Ua/YBA7hv8MbHFOL0CgtRUPFpUOaM/Yn/ 5ZK6t6iiBxeC7mpCnhS/xSsjEVA/yfElSlCht9aJS1reewzk/ij6V6GZehHt1zPiZWNv QN0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:date:message-id:subject:from :to:cc; bh=n68ChJor/bH9DEqGbUeI4LDJI6PLEDS0HZrBr0dWh8Y=; b=WMq+ogyU+0plcazrM5sHz7BvQV4s9OWouRjasH2HD1kHRi6cG+3EG1E/+F0ORaucYp AcIX7w3uwtbqer719PxZ2tU/vOmCBUEb6A5RvsYRohVUm+xEAcxzR2epkZxjPD9e2eWZ lCEMm54POqrJgRiFS8J55tJql7ERBF0hslVvty/a/SBnh/KoigTWXDEExKGZrXFf6Mv+ ERQPNvbpXCPJdEKtSDI2ayWinO7HOTizsbbJDZ0CWlNR6sRg70fBXha0U+TaDbOLuqDX 3q5NcBYCigebp6e4+ZXU/gnNtmwYf/Wj/nUB9asHRpCl2VwUZjKrRBalWSgHcc67c2dW sU3g== X-Gm-Message-State: AD7BkJK935whZ4yqqdT7ptHOL1jgR+7OTrHpt2VmvWhaQQYsVuyAV475zMl41OGCbjW1l4NCVuiGKUaIR9evUA== MIME-Version: 1.0 X-Received: by 10.107.10.215 with SMTP id 84mr11309319iok.193.1457440325223; Tue, 08 Mar 2016 04:32:05 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.36.59.133 with HTTP; Tue, 8 Mar 2016 04:32:05 -0800 (PST) Date: Tue, 8 Mar 2016 12:32:05 +0000 X-Google-Sender-Auth: C8adHyOghI3QcdxhDUbs8OR0eDk Message-ID: From: Barry Leiba To: draft-ietf-cdni-footprint-capabilities-semantics@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: [CDNi] AD review of draft-ietf-cdni-footprint-capabilities-semantics-11 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 08 Mar 2016 12:32:12 -0000 I only have two substantive comments, which come out as questions I'd like you to answer for me: In Section 5: Advertiseing support for mandatory-to-implement GenericMetadata types SHOULD be supported but would be redundant. CDNs SHOULD NOT advertise support for mandatory-to-implement GenericMetadata types. I don't understand this combination of requirements. It appears to say that you SHOULD be able to advertise support for MtI types, but that you SHOULD NOT do it. Is that correct? What/why? (Also, "advertising" only has one "e".) In the 8.1 subsections: Encoding: see Section 7 Where in Section 7 is the information about encoding? -------- The rest are only some minor editorial suggestions, which you can disagree with and ignore if you prefer. If you choose to accept my suggested changes, just queue them up for the next version -- there's no need for an update now unless my questions above result in one. -- Section 2 -- Some CDNs aspire to cover the entire world, which we will henceforth call global CDNs. That sounds like it's "the entire world" that you'll be calling "global CDNs". Consider this: NEW Some CDNs aspire to cover the entire world; we will call those "global CDNs". END -- Section 4 -- One can imagine that such additional information is implicitly associated with a given footprint, e.g., due to contractual agreements (e.g., SLAs), business relationships, or perceived dCDN quality in the past. This is my kookiness: I generally dislike "i.e." and "e.g." because they're so often overused and unnecessary ("i.e." can almost always be removed, and "e.g." is usually better rendered in plain English). But I especially dislike nesting them, as here: it just seems awkward. May I suggest this?: NEW One can imagine that such additional information is implicitly associated with a given footprint, due to such things as SLAs and other contractual agreements, business relationships, or past perceptions of dCDN quality. END It is reasonable to assume that a significant part of the actual footprint advertisement will happen in contractual agreements between participating CDNs, i.e., prior to the advertisement phase using the CDNI FCI. The reason for this assumption is that any contractual agreement is likely to contain specifics about the dCDN coverage (i.e., the dCDN footprint) to which the contractual agreement applies. In particular, additional information to judge the delivery quality associated with a given dCDN footprint might be defined in contractual agreements (i.e. outside of the CDNI FCI). Further, one can assume that dCDN contractual agreements about the delivery quality associated with a given footprint will probably be based on high-level aggregated statistics (i.e., not too detailed). Take this or leave it, as you please, but I just want to demonstrate what I mean when I say that "i.e." is almost always unnecessary and can be removed. I would have written that this way: NEW It is reasonable to assume that a significant part of the actual footprint advertisement will happen in contractual agreements between participating CDNs prior to the advertisement phase that uses the CDNI FCI. The reason for this assumption is that any contractual agreement is likely to contain specifics about the dCDN coverage (the dCDN footprint) to which the contractual agreement applies. In particular, additional information to judge the delivery quality associated with a given dCDN footprint might be defined in contractual agreements outside of the CDNI FCI. Further, one can assume that dCDN contractual agreements about the delivery quality associated with a given footprint will probably be based on high-level aggregated statistics, and will not be too detailed. END Do you not think it reads better without the parentheses and Latin? (If not, take heart: Alexey likes the Latin abbreviations, and won't be making these sorts of comments...) For each of these footprint types, there are capabilities associated with a given footprint, i.e., the capabilities (e.g., delivery protocol, redirection mode, metadata) supported in the coverage area for a "coverage/reachability" defined footprint, or the capabilities of resources (e.g., delivery protocol, redirection mode, metadata support) for a "resource" defined footprint. Another suggestion along the same lines, because of "e.g." nested within "i.e.": NEW For each of these footprint types, there are capabilities associated with a given footprint: o capabilities such as delivery protocol, redirection mode, and metadata, which are supported in the coverage area for a "coverage/reachability" defined footprint, or o capabilities of resources, such as delivery protocol, redirection mode, and metadata support, which apply to a "resource" defined footprint. END One more example: Multiple footprint constraints are additive, i.e., the advertisement of different types of footprint narrows the dCDN candidacy cumulatively. In this case, I would replace "i.e." with a colon: NEW Multiple footprint constraints are additive: the advertisement of different types of footprint narrows the dCDN candidacy cumulatively. END -- Section 8.1 -- I suggest adding the section numbers into the table, so, for example, the Specification column for FCI.DeliveryProtocol would be "RFCthis, Section 8.1.1". -- Barry, ART Director From nobody Tue Mar 8 06:43:00 2016 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 97C1E12D721; Tue, 8 Mar 2016 06:42:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RW2CxCdsBYEf; Tue, 8 Mar 2016 06:42:55 -0800 (PST) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3006712D6DE; Tue, 8 Mar 2016 06:42:54 -0800 (PST) X-AuditID: c6180641-f799c6d000007d66-7d-56dee4cfa19a Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 87.6F.32102.FC4EED65; Tue, 8 Mar 2016 15:42:24 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0248.002; Tue, 8 Mar 2016 09:42:53 -0500 From: Kevin Ma J To: Barry Leiba , "draft-ietf-cdni-footprint-capabilities-semantics@ietf.org" Thread-Topic: AD review of draft-ietf-cdni-footprint-capabilities-semantics-11 Thread-Index: AQHReTaNMksETV9o5kyOXKQUfIKjlJ9PnKCg Date: Tue, 8 Mar 2016 14:42:51 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgkeLIzCtJLcpLzFFi42KZXLonVvfCk3thBu1dohaHFl9itXg6+w+r xeu515gcmD1aVvUyeyxZ8pMpgCmKyyYlNSezLLVI3y6BK+N57x/Wgm8BFQ9W7GZtYHzj18XI ySEhYCLxvm0NI4QtJnHh3nq2LkYuDiGBI4wSB2/dYIVwljFKvHjSywJSxSagJfH4618mkIQI SGLPrEdgCWYBVYm+qQfZQGxhAV+J/ceugsVFBAIkZj6ZyA5hG0l8fHqDGcRmEVCReLTsIlg9 L1D9s3WbmUBsIaD6MwfOg53EKRAosXzdGbB6RqDzvp9awwSxS1zi1pP5TBBnC0gs2XOeGcIW lXj5+B8rhK0kMef1NaA4B1C9psT6XfoQrYoSU7ofskOsFZQ4OfMJywRGsVlIps5C6JiFpGMW ko4FjCyrGDlKiwtyctONDDcxAuPlmASb4w7Gvb2ehxgFOBiVeHg/sN8LE2JNLCuuzD3EKMHB rCTCawGMNiHelMTKqtSi/Pii0pzU4kOM0hwsSuK83z5eDhMSSE8sSc1OTS1ILYLJMnFwSjUw ytpOTpHSCGExCCj9PPPm+zTVYPHpm4J6FvkuP2/+ZKpusf/h7x9ZGl/8KFZVkp/78nFqqO8G jUm+Z09URVnyTtzIrLTzepzXy8p4Z49muxaHtRt+LLzixVSn86LorsYr5nnfW3g2bdFzvPJq 2o+UmYm/pG2fxyVUl96umvwpSadzw4ZVjycHKrEUZyQaajEXFScCAKhn9syTAgAA Archived-At: Cc: "" Subject: Re: [CDNi] AD review of draft-ietf-cdni-footprint-capabilities-semantics-11 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 08 Mar 2016 14:42:58 -0000 SGkgQmFycnksDQoNCiAgVGhhbmtzIGZvciB0aGUgcmV2aWV3LiAgUmVzcG9uc2VzIHRvIHlvdXIg dHdvIHN1YnN0YW50aXZlIGNvbW1lbnRzIGlubGluZToNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiBGcm9tOiBiYXJyeWxlaWJhQGdtYWlsLmNvbSBbbWFpbHRvOmJhcnJ5bGVpYmFA Z21haWwuY29tXSBPbiBCZWhhbGYgT2YNCj4gQmFycnkgTGVpYmENCj4gU2VudDogVHVlc2RheSwg TWFyY2ggMDgsIDIwMTYgNzozMiBBTQ0KPiBUbzogZHJhZnQtaWV0Zi1jZG5pLWZvb3RwcmludC1j YXBhYmlsaXRpZXMtc2VtYW50aWNzQGlldGYub3JnDQo+IENjOiA8Y2RuaUBpZXRmLm9yZz4NCj4g U3ViamVjdDogQUQgcmV2aWV3IG9mIGRyYWZ0LWlldGYtY2RuaS1mb290cHJpbnQtY2FwYWJpbGl0 aWVzLXNlbWFudGljcy0xMQ0KPiANCj4gSSBvbmx5IGhhdmUgdHdvIHN1YnN0YW50aXZlIGNvbW1l bnRzLCB3aGljaCBjb21lIG91dCBhcyBxdWVzdGlvbnMgSSdkDQo+IGxpa2UgeW91IHRvIGFuc3dl ciBmb3IgbWU6DQo+IA0KPiBJbiBTZWN0aW9uIDU6DQo+IA0KPiAgICBBZHZlcnRpc2Vpbmcgc3Vw cG9ydA0KPiAgICBmb3IgbWFuZGF0b3J5LXRvLWltcGxlbWVudCBHZW5lcmljTWV0YWRhdGEgdHlw ZXMgU0hPVUxEIGJlIHN1cHBvcnRlZA0KPiAgICBidXQgd291bGQgYmUgcmVkdW5kYW50LiAgQ0RO cyBTSE9VTEQgTk9UIGFkdmVydGlzZSBzdXBwb3J0IGZvcg0KPiAgICBtYW5kYXRvcnktdG8taW1w bGVtZW50IEdlbmVyaWNNZXRhZGF0YSB0eXBlcy4NCj4gDQo+IEkgZG9uJ3QgdW5kZXJzdGFuZCB0 aGlzIGNvbWJpbmF0aW9uIG9mIHJlcXVpcmVtZW50cy4gIEl0IGFwcGVhcnMgdG8NCj4gc2F5IHRo YXQgeW91IFNIT1VMRCBiZSBhYmxlIHRvIGFkdmVydGlzZSBzdXBwb3J0IGZvciBNdEkgdHlwZXMs IGJ1dA0KPiB0aGF0IHlvdSBTSE9VTEQgTk9UIGRvIGl0LiAgSXMgdGhhdCBjb3JyZWN0PyAgV2hh dC93aHk/ICAoQWxzbywNCj4gImFkdmVydGlzaW5nIiBvbmx5IGhhcyBvbmUgImUiLikNCg0KVGhl IHRob3VnaHQgaGVyZSB3YXMgdGhhdCB3ZSB3YW50IHRvIGJlIGFibGUgdG8gYWR2ZXJ0aXNlIHdo ZW4gYSBkQ0ROIGRvZXMgbm90IHN1cHBvcnQgYSBnaXZlbiBNdEkgbWV0YWRhdGE7IGl0IGNvdWxk IGJlIGEgdGVtcG9yYXJ5IG91dGFnZSwgaW4gYSBsaW1pdGVkIGZvb3RwcmludCwgYnV0IHN1Y2gg YSBjYXBhYmlsaXR5IGFkdmVydGlzZW1lbnQgd291bGQgYmUgdmFsaWQuICBUaGUgZENETiB3b3Vs ZCBhbHNvIG5lZWQgdG8gYmUgYWJsZSB0byBhZHZlcnRpc2Ugd2hlbiBzdXBwb3J0IHdhcyByZWVz dGFibGlzaGVkLiAgVGhlcmUgd2FzIGFsc28gYSB0aG91Z2h0IHRoYXQgd2UgbWlnaHQgd2FudCBh IGZ1bGwgY2FwYWJpbGl0eSBzdGF0ZSBkdW1wIGNvbW1hbmQsIGluIHdoaWNoIGNhc2Ugd2Ugd291 bGQgc2VuZCBNdEkgbWV0YWRhdGEgYXMgd2VsbC4gIEluIHRoZSB0eXBpY2FsIGNhc2UsIGhvd2V2 ZXIsIHdlIHdhbnRlZCB0byBub3Qgd2FzdGUgdGhlIGJhbmR3aWR0aCBzZW5kaW5nIE10SSBtZXRh ZGF0YSBpbmZvcm1hdGlvbiB3aGVuIHdlIGZpZ3VyZWQgdGhleSB3b3VsZCBhbGwgYmUgc3VwcG9y dGVkLg0KDQpXb3VsZCBpdCBoZWxwIHRvIG1ha2UgdGhlIHNlY29uZCBzZW50ZW5jZSBhIFJFQ09N TUVORCwgcmF0aGVyIHRoYW4gYSBTSE9VTEQsIGFuZCBhZGQgc29tZSB0ZXh0IGFzIHRvIHRoZSBy ZWFzb25pbmcgKGkuZS4sIHNhdmluZyBiaXRzKT8NCg0KPiBJbiB0aGUgOC4xIHN1YnNlY3Rpb25z Og0KPiANCj4gICAgRW5jb2Rpbmc6IHNlZSBTZWN0aW9uIDcNCj4gDQo+IFdoZXJlIGluIFNlY3Rp b24gNyBpcyB0aGUgaW5mb3JtYXRpb24gYWJvdXQgZW5jb2Rpbmc/DQoNClNlY3Rpb24gNy41IGhh cyB0aGUgZXhhbXBsZSBvZiB0aGUgY2FwYWJpbGl0eSBzZXJpYWxpemF0aW9uIG9mIHRoZSB0aHJl ZSBvYmplY3RzIGRlc2NyaWJlZCBpbiBzZWN0aW9ucyA3LjIsIDcuMywgYW5kIDcuNCAoY29ycmVz cG9uZGluZyB0byB0aGUgcmVnaXN0cmF0aW9ucyBpbiBzZWN0aW9ucyA4LjEuMSwgOC4xLjIsIGFu ZCA4LjEuMykNCg0KV291bGQgaXQgaGVscCB0byBtYWtlIHRoZSBzZWN0aW9uIHJlZmVyZW5jZXMg Ny4yIGFuZCA3LjUsIDcuMyBhbmQgNy41LCBhbmQgNy40IGFuZCA3LjUsIGluIHNlY3Rpb25zIDgu MS4xLCA4LjEuMiwgYW5kIDguMS4zLCByZXNwZWN0aXZlbHk/DQoNCldlIHdpbGwgYWRkcmVzcyB0 aGUgb3RoZXIgZWRpdG9yaWFsIGNvbW1lbnRzIGluIHRoZSBuZXh0IHZlcnNpb24uDQoNCnRoYW54 IQ0KDQotLSAgS2V2aW4gSi4gTWENCg0KPiAtLS0tLS0tLQ0KPiANCj4gVGhlIHJlc3QgYXJlIG9u bHkgc29tZSBtaW5vciBlZGl0b3JpYWwgc3VnZ2VzdGlvbnMsIHdoaWNoIHlvdSBjYW4NCj4gZGlz YWdyZWUgd2l0aCBhbmQgaWdub3JlIGlmIHlvdSBwcmVmZXIuICBJZiB5b3UgY2hvb3NlIHRvIGFj Y2VwdCBteQ0KPiBzdWdnZXN0ZWQgY2hhbmdlcywganVzdCBxdWV1ZSB0aGVtIHVwIGZvciB0aGUg bmV4dCB2ZXJzaW9uIC0tIHRoZXJlJ3MNCj4gbm8gbmVlZCBmb3IgYW4gdXBkYXRlIG5vdyB1bmxl c3MgbXkgcXVlc3Rpb25zIGFib3ZlIHJlc3VsdCBpbiBvbmUuDQo+IA0KPiAtLSBTZWN0aW9uIDIg LS0NCj4gDQo+ICAgIFNvbWUgQ0ROcyBhc3BpcmUgdG8gY292ZXIgdGhlIGVudGlyZSB3b3JsZCwg d2hpY2ggd2Ugd2lsbCBoZW5jZWZvcnRoDQo+ICAgIGNhbGwgZ2xvYmFsIENETnMuDQo+IA0KPiBU aGF0IHNvdW5kcyBsaWtlIGl0J3MgInRoZSBlbnRpcmUgd29ybGQiIHRoYXQgeW91J2xsIGJlIGNh bGxpbmcNCj4gImdsb2JhbCBDRE5zIi4gIENvbnNpZGVyIHRoaXM6DQo+IA0KPiBORVcNCj4gICAg U29tZSBDRE5zIGFzcGlyZSB0byBjb3ZlciB0aGUgZW50aXJlIHdvcmxkOyB3ZSB3aWxsIGNhbGwg dGhvc2UNCj4gICAgImdsb2JhbCBDRE5zIi4NCj4gRU5EDQo+IA0KPiAtLSBTZWN0aW9uIDQgLS0N Cj4gDQo+ICAgIE9uZQ0KPiAgICBjYW4gaW1hZ2luZSB0aGF0IHN1Y2ggYWRkaXRpb25hbCBpbmZv cm1hdGlvbiBpcyBpbXBsaWNpdGx5IGFzc29jaWF0ZWQNCj4gICAgd2l0aCBhIGdpdmVuIGZvb3Rw cmludCwgZS5nLiwgZHVlIHRvIGNvbnRyYWN0dWFsIGFncmVlbWVudHMgKGUuZy4sDQo+ICAgIFNM QXMpLCBidXNpbmVzcyByZWxhdGlvbnNoaXBzLCBvciBwZXJjZWl2ZWQgZENETiBxdWFsaXR5IGlu IHRoZSBwYXN0Lg0KPiANCj4gVGhpcyBpcyBteSBrb29raW5lc3M6IEkgZ2VuZXJhbGx5IGRpc2xp a2UgImkuZS4iIGFuZCAiZS5nLiIgYmVjYXVzZQ0KPiB0aGV5J3JlIHNvIG9mdGVuIG92ZXJ1c2Vk IGFuZCB1bm5lY2Vzc2FyeSAoImkuZS4iIGNhbiBhbG1vc3QgYWx3YXlzIGJlDQo+IHJlbW92ZWQs IGFuZCAiZS5nLiIgaXMgdXN1YWxseSBiZXR0ZXIgcmVuZGVyZWQgaW4gcGxhaW4gRW5nbGlzaCku ICBCdXQNCj4gSSBlc3BlY2lhbGx5IGRpc2xpa2UgbmVzdGluZyB0aGVtLCBhcyBoZXJlOiBpdCBq dXN0IHNlZW1zIGF3a3dhcmQuDQo+IE1heSBJIHN1Z2dlc3QgdGhpcz86DQo+IA0KPiBORVcNCj4g ICAgT25lDQo+ICAgIGNhbiBpbWFnaW5lIHRoYXQgc3VjaCBhZGRpdGlvbmFsIGluZm9ybWF0aW9u IGlzIGltcGxpY2l0bHkgYXNzb2NpYXRlZA0KPiAgICB3aXRoIGEgZ2l2ZW4gZm9vdHByaW50LCBk dWUgdG8gc3VjaCB0aGluZ3MgYXMgU0xBcyBhbmQgb3RoZXINCj4gY29udHJhY3R1YWwNCj4gICAg YWdyZWVtZW50cywgYnVzaW5lc3MgcmVsYXRpb25zaGlwcywgb3IgcGFzdCBwZXJjZXB0aW9ucyBv ZiBkQ0RODQo+IHF1YWxpdHkuDQo+IEVORA0KPiANCj4gICAgSXQgaXMgcmVhc29uYWJsZSB0byBh c3N1bWUgdGhhdCBhIHNpZ25pZmljYW50IHBhcnQgb2YgdGhlIGFjdHVhbA0KPiAgICBmb290cHJp bnQgYWR2ZXJ0aXNlbWVudCB3aWxsIGhhcHBlbiBpbiBjb250cmFjdHVhbCBhZ3JlZW1lbnRzIGJl dHdlZW4NCj4gICAgcGFydGljaXBhdGluZyBDRE5zLCBpLmUuLCBwcmlvciB0byB0aGUgYWR2ZXJ0 aXNlbWVudCBwaGFzZSB1c2luZyB0aGUNCj4gICAgQ0ROSSBGQ0kuICBUaGUgcmVhc29uIGZvciB0 aGlzIGFzc3VtcHRpb24gaXMgdGhhdCBhbnkgY29udHJhY3R1YWwNCj4gICAgYWdyZWVtZW50IGlz IGxpa2VseSB0byBjb250YWluIHNwZWNpZmljcyBhYm91dCB0aGUgZENETiBjb3ZlcmFnZQ0KPiAg ICAoaS5lLiwgdGhlIGRDRE4gZm9vdHByaW50KSB0byB3aGljaCB0aGUgY29udHJhY3R1YWwgYWdy ZWVtZW50DQo+ICAgIGFwcGxpZXMuICBJbiBwYXJ0aWN1bGFyLCBhZGRpdGlvbmFsIGluZm9ybWF0 aW9uIHRvIGp1ZGdlIHRoZSBkZWxpdmVyeQ0KPiAgICBxdWFsaXR5IGFzc29jaWF0ZWQgd2l0aCBh IGdpdmVuIGRDRE4gZm9vdHByaW50IG1pZ2h0IGJlIGRlZmluZWQgaW4NCj4gICAgY29udHJhY3R1 YWwgYWdyZWVtZW50cyAoaS5lLiAgb3V0c2lkZSBvZiB0aGUgQ0ROSSBGQ0kpLiAgRnVydGhlciwg b25lDQo+ICAgIGNhbiBhc3N1bWUgdGhhdCBkQ0ROIGNvbnRyYWN0dWFsIGFncmVlbWVudHMgYWJv dXQgdGhlIGRlbGl2ZXJ5DQo+ICAgIHF1YWxpdHkgYXNzb2NpYXRlZCB3aXRoIGEgZ2l2ZW4gZm9v dHByaW50IHdpbGwgcHJvYmFibHkgYmUgYmFzZWQgb24NCj4gICAgaGlnaC1sZXZlbCBhZ2dyZWdh dGVkIHN0YXRpc3RpY3MgKGkuZS4sIG5vdCB0b28gZGV0YWlsZWQpLg0KPiANCj4gVGFrZSB0aGlz IG9yIGxlYXZlIGl0LCBhcyB5b3UgcGxlYXNlLCBidXQgSSBqdXN0IHdhbnQgdG8gZGVtb25zdHJh dGUNCj4gd2hhdCBJIG1lYW4gd2hlbiBJIHNheSB0aGF0ICJpLmUuIiBpcyBhbG1vc3QgYWx3YXlz IHVubmVjZXNzYXJ5IGFuZA0KPiBjYW4gYmUgcmVtb3ZlZC4gIEkgd291bGQgaGF2ZSB3cml0dGVu IHRoYXQgdGhpcyB3YXk6DQo+IA0KPiBORVcNCj4gICAgSXQgaXMgcmVhc29uYWJsZSB0byBhc3N1 bWUgdGhhdCBhIHNpZ25pZmljYW50IHBhcnQgb2YgdGhlIGFjdHVhbA0KPiAgICBmb290cHJpbnQg YWR2ZXJ0aXNlbWVudCB3aWxsIGhhcHBlbiBpbiBjb250cmFjdHVhbCBhZ3JlZW1lbnRzIGJldHdl ZW4NCj4gICAgcGFydGljaXBhdGluZyBDRE5zIHByaW9yIHRvIHRoZSBhZHZlcnRpc2VtZW50IHBo YXNlIHRoYXQgdXNlcyB0aGUNCj4gICAgQ0ROSSBGQ0kuICBUaGUgcmVhc29uIGZvciB0aGlzIGFz c3VtcHRpb24gaXMgdGhhdCBhbnkgY29udHJhY3R1YWwNCj4gICAgYWdyZWVtZW50IGlzIGxpa2Vs eSB0byBjb250YWluIHNwZWNpZmljcyBhYm91dCB0aGUgZENETiBjb3ZlcmFnZQ0KPiAgICAodGhl IGRDRE4gZm9vdHByaW50KSB0byB3aGljaCB0aGUgY29udHJhY3R1YWwgYWdyZWVtZW50IGFwcGxp ZXMuDQo+ICAgIEluIHBhcnRpY3VsYXIsIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gdG8ganVkZ2Ug dGhlIGRlbGl2ZXJ5IHF1YWxpdHkNCj4gICAgYXNzb2NpYXRlZCB3aXRoIGEgZ2l2ZW4gZENETiBm b290cHJpbnQgbWlnaHQgYmUgZGVmaW5lZCBpbiBjb250cmFjdHVhbA0KPiAgICBhZ3JlZW1lbnRz IG91dHNpZGUgb2YgdGhlIENETkkgRkNJLiAgRnVydGhlciwgb25lIGNhbiBhc3N1bWUgdGhhdCBk Q0RODQo+ICAgIGNvbnRyYWN0dWFsIGFncmVlbWVudHMgYWJvdXQgdGhlIGRlbGl2ZXJ5IHF1YWxp dHkgYXNzb2NpYXRlZCB3aXRoIGENCj4gICAgZ2l2ZW4gZm9vdHByaW50IHdpbGwgcHJvYmFibHkg YmUgYmFzZWQgb24gaGlnaC1sZXZlbCBhZ2dyZWdhdGVkDQo+ICAgIHN0YXRpc3RpY3MsIGFuZCB3 aWxsIG5vdCBiZSB0b28gZGV0YWlsZWQuDQo+IEVORA0KPiANCj4gRG8geW91IG5vdCB0aGluayBp dCByZWFkcyBiZXR0ZXIgd2l0aG91dCB0aGUgcGFyZW50aGVzZXMgYW5kIExhdGluPw0KPiAoSWYg bm90LCB0YWtlIGhlYXJ0OiBBbGV4ZXkgbGlrZXMgdGhlIExhdGluIGFiYnJldmlhdGlvbnMsIGFu ZCB3b24ndA0KPiBiZSBtYWtpbmcgdGhlc2Ugc29ydHMgb2YgY29tbWVudHMuLi4pDQo+IA0KPiAg ICBGb3IgZWFjaCBvZiB0aGVzZSBmb290cHJpbnQgdHlwZXMsIHRoZXJlIGFyZSBjYXBhYmlsaXRp ZXMgYXNzb2NpYXRlZA0KPiAgICB3aXRoIGEgZ2l2ZW4gZm9vdHByaW50LCBpLmUuLCB0aGUgY2Fw YWJpbGl0aWVzIChlLmcuLCBkZWxpdmVyeQ0KPiAgICBwcm90b2NvbCwgcmVkaXJlY3Rpb24gbW9k ZSwgbWV0YWRhdGEpIHN1cHBvcnRlZCBpbiB0aGUgY292ZXJhZ2UgYXJlYQ0KPiAgICBmb3IgYSAi Y292ZXJhZ2UvcmVhY2hhYmlsaXR5IiBkZWZpbmVkIGZvb3RwcmludCwgb3IgdGhlIGNhcGFiaWxp dGllcw0KPiAgICBvZiByZXNvdXJjZXMgKGUuZy4sIGRlbGl2ZXJ5IHByb3RvY29sLCByZWRpcmVj dGlvbiBtb2RlLCBtZXRhZGF0YQ0KPiAgICBzdXBwb3J0KSBmb3IgYSAicmVzb3VyY2UiIGRlZmlu ZWQgZm9vdHByaW50Lg0KPiANCj4gQW5vdGhlciBzdWdnZXN0aW9uIGFsb25nIHRoZSBzYW1lIGxp bmVzLCBiZWNhdXNlIG9mICJlLmcuIiBuZXN0ZWQgd2l0aGluDQo+ICJpLmUuIjoNCj4gDQo+IE5F Vw0KPiAgICBGb3IgZWFjaCBvZiB0aGVzZSBmb290cHJpbnQgdHlwZXMsIHRoZXJlIGFyZSBjYXBh YmlsaXRpZXMgYXNzb2NpYXRlZA0KPiAgICB3aXRoIGEgZ2l2ZW4gZm9vdHByaW50Og0KPiAgICAg IG8gIGNhcGFiaWxpdGllcyBzdWNoIGFzIGRlbGl2ZXJ5IHByb3RvY29sLCByZWRpcmVjdGlvbiBt b2RlLCBhbmQNCj4gICAgICAgICBtZXRhZGF0YSwgd2hpY2ggYXJlIHN1cHBvcnRlZCBpbiB0aGUg Y292ZXJhZ2UgYXJlYSBmb3IgYQ0KPiAgICAgICAgICJjb3ZlcmFnZS9yZWFjaGFiaWxpdHkiIGRl ZmluZWQgZm9vdHByaW50LCBvcg0KPiAgICAgIG8gIGNhcGFiaWxpdGllcyBvZiByZXNvdXJjZXMs IHN1Y2ggYXMgZGVsaXZlcnkgcHJvdG9jb2wsIHJlZGlyZWN0aW9uDQo+ICAgICAgICAgbW9kZSwg YW5kIG1ldGFkYXRhIHN1cHBvcnQsIHdoaWNoIGFwcGx5IHRvIGEgInJlc291cmNlIiBkZWZpbmVk DQo+ICAgICAgICAgZm9vdHByaW50Lg0KPiBFTkQNCj4gDQo+IE9uZSBtb3JlIGV4YW1wbGU6DQo+ IA0KPiAgICBNdWx0aXBsZSBmb290cHJpbnQgY29uc3RyYWludHMgYXJlIGFkZGl0aXZlLCBpLmUu LCB0aGUNCj4gICAgYWR2ZXJ0aXNlbWVudCBvZiBkaWZmZXJlbnQgdHlwZXMgb2YgZm9vdHByaW50 IG5hcnJvd3MgdGhlIGRDRE4NCj4gICAgY2FuZGlkYWN5IGN1bXVsYXRpdmVseS4NCj4gDQo+IElu IHRoaXMgY2FzZSwgSSB3b3VsZCByZXBsYWNlICJpLmUuIiB3aXRoIGEgY29sb246DQo+IA0KPiBO RVcNCj4gICAgTXVsdGlwbGUgZm9vdHByaW50IGNvbnN0cmFpbnRzIGFyZSBhZGRpdGl2ZTogdGhl DQo+ICAgIGFkdmVydGlzZW1lbnQgb2YgZGlmZmVyZW50IHR5cGVzIG9mIGZvb3RwcmludCBuYXJy b3dzIHRoZSBkQ0RODQo+ICAgIGNhbmRpZGFjeSBjdW11bGF0aXZlbHkuDQo+IEVORA0KPiANCj4g LS0gU2VjdGlvbiA4LjEgLS0NCj4gSSBzdWdnZXN0IGFkZGluZyB0aGUgc2VjdGlvbiBudW1iZXJz IGludG8gdGhlIHRhYmxlLCBzbywgZm9yIGV4YW1wbGUsDQo+IHRoZSBTcGVjaWZpY2F0aW9uIGNv bHVtbiBmb3IgRkNJLkRlbGl2ZXJ5UHJvdG9jb2wgd291bGQgYmUgIlJGQ3RoaXMsDQo+IFNlY3Rp b24gOC4xLjEiLg0KPiANCj4gLS0NCj4gQmFycnksIEFSVCBEaXJlY3Rvcg0K From nobody Tue Mar 8 07:34:03 2016 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 A117412D797; Tue, 8 Mar 2016 07:34:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qbix6uu8Sd8P; Tue, 8 Mar 2016 07:34:00 -0800 (PST) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (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 9D1E712D7A4; Tue, 8 Mar 2016 07:33:23 -0800 (PST) Received: by mail-ig0-x233.google.com with SMTP id hb3so67189352igb.0; Tue, 08 Mar 2016 07:33:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=J1qiDIe1nifL0AFIbvDR3X2hxePfL17amVhouc4oDxk=; b=V/lR2K+56ZvNRVolcX5MCgl7vBxkn7pCjlDTR7Fr2ZBaLPsnl0vjRRIFDzNlO3b/S3 uGXJl6XRUWktfIt8MkIz9IWU+34nIMLFNsI0+j43xqcky0xWJour63iw8qglvReehRou cC/nOiBbDnQbC9zFWfMyOUt6gCdziTJGMaSVEsnSiwrX0RWJ+RrtXWGqSa/T+XzUgB8H BPITA3nQGP4Ax5umtV/YNH0c2SP40YDsY+6j7ab9mXrSZDbzTsgSzATRGD2BCCals0hv 5t+UdA1xWQdKNHvU1ISdb4+zFiG9BYYBIjim2STLddumXpSFxBu7CZUhG0veA4pvui5J tB6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=J1qiDIe1nifL0AFIbvDR3X2hxePfL17amVhouc4oDxk=; b=XhFwC8Xe80bIQPp4MvInt3Rw3FQYLlr9lF2bFnIC+xOyzOldhalC8/YgD1DUKpOzBA uZH3Ht+u8+nDOnu7E/wjjjWmb/3hcZhanYfuiYsXa1EYflQEZe+vRtwUmtm5bT7HduQ+ dwE9vsNI04D9G+FCNBMMk+BuGas2QBThNCDfBpv1nUQUGX8XiziOWOApYxceYOgSC5qM OJLOc8+qz1PkbbCTnMktjeEKENArSumlKe070++f/0ZqRNjR/ICUWZWlcGGLunmGwJdz TMwII641WQ+tg3Qr9UeODAUVwPnsya0LBuEov3cxEhGv02G7778UtiQWY6kxF06GLnIe Yw4w== X-Gm-Message-State: AD7BkJI2mO4pmZ1SsPPu2nH/4Xc0qNolccxdS+kY8OS4WJkS7rzNwTt3WN8SX2orBYWHR6pSely5DDS4urG3Rw== MIME-Version: 1.0 X-Received: by 10.50.110.5 with SMTP id hw5mr20646450igb.54.1457451202882; Tue, 08 Mar 2016 07:33:22 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.36.59.133 with HTTP; Tue, 8 Mar 2016 07:33:22 -0800 (PST) In-Reply-To: References: Date: Tue, 8 Mar 2016 15:33:22 +0000 X-Google-Sender-Auth: GapSHDCjNV4HvNexYlEjfKy_EyI Message-ID: From: Barry Leiba To: Kevin Ma J Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" , "draft-ietf-cdni-footprint-capabilities-semantics@ietf.org" Subject: Re: [CDNi] AD review of draft-ietf-cdni-footprint-capabilities-semantics-11 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 08 Mar 2016 15:34:01 -0000 Thanks for the quick reply, Kevin. >> Advertiseing support >> for mandatory-to-implement GenericMetadata types SHOULD be supported >> but would be redundant. CDNs SHOULD NOT advertise support for >> mandatory-to-implement GenericMetadata types. >> >> I don't understand this combination of requirements. It appears to >> say that you SHOULD be able to advertise support for MtI types, but >> that you SHOULD NOT do it. Is that correct? What/why? (Also, >> "advertising" only has one "e".) > > The thought here was that we want to be able to advertise when a dCDN > does not support a given MtI metadata; it could be a temporary outage, > in a limited footprint, but such a capability advertisement would be > valid. The dCDN would also need to be able to advertise when support > was reestablished. There was also a thought that we might want a full > capability state dump command, in which case we would send MtI > metadata as well. In the typical case, however, we wanted to not > waste the bandwidth sending MtI metadata information when we figured > they would all be supported. > > Would it help to make the second sentence a RECOMMEND, rather than a > SHOULD, and add some text as to the reasoning (i.e., saving bits)? Well, RECOMMEND and SHOULD mean the same thing (see RFC 2119); they're just different parts of speech. Yes, it would help to rephrase and explain what the issue is here. >> In the 8.1 subsections: >> >> Encoding: see Section 7 >> >> Where in Section 7 is the information about encoding? > > Section 7.5 has the example of the capability serialization of the > three objects described in sections 7.2, 7.3, and 7.4 (corresponding > to the registrations in sections 8.1.1, 8.1.2, and 8.1.3) > > Would it help to make the section references 7.2 and 7.5, 7.3 and 7.5, > and 7.4 and 7.5, in sections 8.1.1, 8.1.2, and 8.1.3, respectively? It would. Thanks. I'll watch for an update, and will request last call then. Barry From nobody Tue Mar 8 07:47:53 2016 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 5FF0C12D783; Tue, 8 Mar 2016 07:47:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dxg9-ETH1E5r; Tue, 8 Mar 2016 07:47:51 -0800 (PST) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD69E12D7AD; Tue, 8 Mar 2016 07:47:50 -0800 (PST) X-AuditID: c618062d-f79dd6d000003091-7f-56deef58268f Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 6A.98.12433.85FEED65; Tue, 8 Mar 2016 16:27:21 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0248.002; Tue, 8 Mar 2016 10:47:49 -0500 From: Kevin Ma J To: Barry Leiba Thread-Topic: AD review of draft-ietf-cdni-footprint-capabilities-semantics-11 Thread-Index: AQHReTaNMksETV9o5kyOXKQUfIKjlJ9PnKCggABkdgD//7A70A== Date: Tue, 8 Mar 2016 15:47:48 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPLMWRmVeSWpSXmKPExsUyuXRPgm7k+3thBu/X8VscWnyJ1eLp7D+s Fq/nXmNyYPZoWdXL7LFkyU+mAKYoLpuU1JzMstQifbsErowL296wFGySrtg4dx9bA+MNqS5G Tg4JAROJFzufs0LYYhIX7q1n62Lk4hASOMIo8eLha1YIZxmjRMvW6WBVbAJaEo+//mUCsUUE NCWef57CBFLELLCIUeJS33EWkISwgK/E/mNXWSCKAiRmPpnIDmE7Sdya9ACsmUVARWLFtT1A Qzk4eIHqbx2uAgkLCdxmlHj8DKycUyBQ4uqOTWBjGIGu+35qDVgrs4C4xK0n85kgrhaQWLLn PDOELSrx8vE/qG8UJfb1T2cHGc8MdOf6XfoQrYoSU7ofgo3nFRCUODnzCcsERrFZSKbOQuiY haRjFpKOBYwsqxg5SosLcnLTjQw2MQKj5ZgEm+4OxvvTPQ8xCnAwKvHwfmC/FybEmlhWXJl7 iFGCg1lJhLfpE1CINyWxsiq1KD++qDQntfgQozQHi5I47/q3l8OEBNITS1KzU1MLUotgskwc nFINjBveXVCZsti4TN17x9Pnq+pXiExaVbOvYrnHhdnNxxpnKkz4bWt1eo/jz86/l58IMJ7X 29x/63emkdC7W/v/7p3NeL33wAOv1T//V20+m+R8n3/659p0mRkrNpgWbP+6cyXD/Xk7Te6H bBJY9MG5pXh7T83rVe/nHIl5ucr+ztHYVcUcrBdsZyx/oMRSnJFoqMVcVJwIAN5qU2iSAgAA Archived-At: Cc: "" , "draft-ietf-cdni-footprint-capabilities-semantics@ietf.org" Subject: Re: [CDNi] AD review of draft-ietf-cdni-footprint-capabilities-semantics-11 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 08 Mar 2016 15:47:52 -0000 SGkgQmFycnksDQoNCiAgSSdsbCBtYWtlIHRoZSB1cGRhdGVzIGFuZCBzdWJtaXQgYSBuZXcgdmVy c2lvbi4NCg0KdGhhbnghDQoNCi0tICBLZXZpbiBKLiBNYQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+IEZyb206IGJhcnJ5bGVpYmFAZ21haWwuY29tIFttYWlsdG86YmFycnlsZWli YUBnbWFpbC5jb21dIE9uIEJlaGFsZiBPZg0KPiBCYXJyeSBMZWliYQ0KPiBTZW50OiBUdWVzZGF5 LCBNYXJjaCAwOCwgMjAxNiAxMDozMyBBTQ0KPiBUbzogS2V2aW4gTWEgSg0KPiBDYzogZHJhZnQt aWV0Zi1jZG5pLWZvb3RwcmludC1jYXBhYmlsaXRpZXMtc2VtYW50aWNzQGlldGYub3JnOw0KPiA8 Y2RuaUBpZXRmLm9yZz4NCj4gU3ViamVjdDogUmU6IEFEIHJldmlldyBvZiBkcmFmdC1pZXRmLWNk bmktZm9vdHByaW50LWNhcGFiaWxpdGllcy0NCj4gc2VtYW50aWNzLTExDQo+IA0KPiBUaGFua3Mg Zm9yIHRoZSBxdWljayByZXBseSwgS2V2aW4uDQo+IA0KPiA+PiAgICBBZHZlcnRpc2Vpbmcgc3Vw cG9ydA0KPiA+PiAgICBmb3IgbWFuZGF0b3J5LXRvLWltcGxlbWVudCBHZW5lcmljTWV0YWRhdGEg dHlwZXMgU0hPVUxEIGJlIHN1cHBvcnRlZA0KPiA+PiAgICBidXQgd291bGQgYmUgcmVkdW5kYW50 LiAgQ0ROcyBTSE9VTEQgTk9UIGFkdmVydGlzZSBzdXBwb3J0IGZvcg0KPiA+PiAgICBtYW5kYXRv cnktdG8taW1wbGVtZW50IEdlbmVyaWNNZXRhZGF0YSB0eXBlcy4NCj4gPj4NCj4gPj4gSSBkb24n dCB1bmRlcnN0YW5kIHRoaXMgY29tYmluYXRpb24gb2YgcmVxdWlyZW1lbnRzLiAgSXQgYXBwZWFy cyB0bw0KPiA+PiBzYXkgdGhhdCB5b3UgU0hPVUxEIGJlIGFibGUgdG8gYWR2ZXJ0aXNlIHN1cHBv cnQgZm9yIE10SSB0eXBlcywgYnV0DQo+ID4+IHRoYXQgeW91IFNIT1VMRCBOT1QgZG8gaXQuICBJ cyB0aGF0IGNvcnJlY3Q/ICBXaGF0L3doeT8gIChBbHNvLA0KPiA+PiAiYWR2ZXJ0aXNpbmciIG9u bHkgaGFzIG9uZSAiZSIuKQ0KPiA+DQo+ID4gVGhlIHRob3VnaHQgaGVyZSB3YXMgdGhhdCB3ZSB3 YW50IHRvIGJlIGFibGUgdG8gYWR2ZXJ0aXNlIHdoZW4gYSBkQ0RODQo+ID4gZG9lcyBub3Qgc3Vw cG9ydCBhIGdpdmVuIE10SSBtZXRhZGF0YTsgaXQgY291bGQgYmUgYSB0ZW1wb3Jhcnkgb3V0YWdl LA0KPiA+IGluIGEgbGltaXRlZCBmb290cHJpbnQsIGJ1dCBzdWNoIGEgY2FwYWJpbGl0eSBhZHZl cnRpc2VtZW50IHdvdWxkIGJlDQo+ID4gdmFsaWQuICBUaGUgZENETiB3b3VsZCBhbHNvIG5lZWQg dG8gYmUgYWJsZSB0byBhZHZlcnRpc2Ugd2hlbiBzdXBwb3J0DQo+ID4gd2FzIHJlZXN0YWJsaXNo ZWQuICBUaGVyZSB3YXMgYWxzbyBhIHRob3VnaHQgdGhhdCB3ZSBtaWdodCB3YW50IGEgZnVsbA0K PiA+IGNhcGFiaWxpdHkgc3RhdGUgZHVtcCBjb21tYW5kLCBpbiB3aGljaCBjYXNlIHdlIHdvdWxk IHNlbmQgTXRJDQo+ID4gbWV0YWRhdGEgYXMgd2VsbC4gIEluIHRoZSB0eXBpY2FsIGNhc2UsIGhv d2V2ZXIsIHdlIHdhbnRlZCB0byBub3QNCj4gPiB3YXN0ZSB0aGUgYmFuZHdpZHRoIHNlbmRpbmcg TXRJIG1ldGFkYXRhIGluZm9ybWF0aW9uIHdoZW4gd2UgZmlndXJlZA0KPiA+IHRoZXkgd291bGQg YWxsIGJlIHN1cHBvcnRlZC4NCj4gPg0KPiA+IFdvdWxkIGl0IGhlbHAgdG8gbWFrZSB0aGUgc2Vj b25kIHNlbnRlbmNlIGEgUkVDT01NRU5ELCByYXRoZXIgdGhhbiBhDQo+ID4gU0hPVUxELCBhbmQg YWRkIHNvbWUgdGV4dCBhcyB0byB0aGUgcmVhc29uaW5nIChpLmUuLCBzYXZpbmcgYml0cyk/DQo+ IA0KPiBXZWxsLCBSRUNPTU1FTkQgYW5kIFNIT1VMRCBtZWFuIHRoZSBzYW1lIHRoaW5nIChzZWUg UkZDIDIxMTkpOyB0aGV5J3JlDQo+IGp1c3QgZGlmZmVyZW50IHBhcnRzIG9mIHNwZWVjaC4gIFll cywgaXQgd291bGQgaGVscCB0byByZXBocmFzZSBhbmQNCj4gZXhwbGFpbiB3aGF0IHRoZSBpc3N1 ZSBpcyBoZXJlLg0KPiANCj4gPj4gSW4gdGhlIDguMSBzdWJzZWN0aW9uczoNCj4gPj4NCj4gPj4g ICAgRW5jb2Rpbmc6IHNlZSBTZWN0aW9uIDcNCj4gPj4NCj4gPj4gV2hlcmUgaW4gU2VjdGlvbiA3 IGlzIHRoZSBpbmZvcm1hdGlvbiBhYm91dCBlbmNvZGluZz8NCj4gPg0KPiA+IFNlY3Rpb24gNy41 IGhhcyB0aGUgZXhhbXBsZSBvZiB0aGUgY2FwYWJpbGl0eSBzZXJpYWxpemF0aW9uIG9mIHRoZQ0K PiA+IHRocmVlIG9iamVjdHMgZGVzY3JpYmVkIGluIHNlY3Rpb25zIDcuMiwgNy4zLCBhbmQgNy40 IChjb3JyZXNwb25kaW5nDQo+ID4gdG8gdGhlIHJlZ2lzdHJhdGlvbnMgaW4gc2VjdGlvbnMgOC4x LjEsIDguMS4yLCBhbmQgOC4xLjMpDQo+ID4NCj4gPiBXb3VsZCBpdCBoZWxwIHRvIG1ha2UgdGhl IHNlY3Rpb24gcmVmZXJlbmNlcyA3LjIgYW5kIDcuNSwgNy4zIGFuZCA3LjUsDQo+ID4gYW5kIDcu NCBhbmQgNy41LCBpbiBzZWN0aW9ucyA4LjEuMSwgOC4xLjIsIGFuZCA4LjEuMywgcmVzcGVjdGl2 ZWx5Pw0KPiANCj4gSXQgd291bGQuICBUaGFua3MuDQo+IA0KPiBJJ2xsIHdhdGNoIGZvciBhbiB1 cGRhdGUsIGFuZCB3aWxsIHJlcXVlc3QgbGFzdCBjYWxsIHRoZW4uDQo+IA0KPiBCYXJyeQ0K From nobody Tue Mar 8 10:14:07 2016 Return-Path: X-Original-To: cdni@ietf.org Delivered-To: cdni@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E1DB012D969; Tue, 8 Mar 2016 10:14:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.15.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160308181404.25230.91803.idtracker@ietfa.amsl.com> Date: Tue, 08 Mar 2016 10:14:04 -0800 Archived-At: Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-footprint-capabilities-semantics-12.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 08 Mar 2016 18:14:05 -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 of the IETF. Title : CDNI Request Routing: Footprint and Capabilities Semantics Authors : Jan Seedorf Jon Peterson Stefano Previdi Ray van Brandenburg Kevin J. Ma Filename : draft-ietf-cdni-footprint-capabilities-semantics-12.txt Pages : 21 Date : 2016-03-08 Abstract: This document captures the semantics of the "Footprint and Capabilities Advertisement" part of the CDNI Request Routing interface, i.e., the desired meaning of "Footprint" and "Capabilities" in the CDNI context, and what the "Footprint and Capabilities Advertisement Interface (FCI)" offers within CDNI. The document also provides guidelines for the CDNI FCI protocol. It further defines a Base Advertisement Object, the necessary registries for capabilities and footprints, and guidelines on how these registries can be extended in the future. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-footprint-capabilities-semantics/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-cdni-footprint-capabilities-semantics-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-footprint-capabilities-semantics-12 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 Tue Mar 8 10:15:33 2016 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 D0DE312D858 for ; Tue, 8 Mar 2016 10:15:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27rwmplnr1kX for ; Tue, 8 Mar 2016 10:15:21 -0800 (PST) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0A2112D958 for ; Tue, 8 Mar 2016 10:15:20 -0800 (PST) X-AuditID: c6180641-f799c6d000007d66-c3-56df169a7547 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id F5.BC.32102.A961FD65; Tue, 8 Mar 2016 19:14:50 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0248.002; Tue, 8 Mar 2016 13:15:19 -0500 From: Kevin Ma J To: "cdni@ietf.org" Thread-Topic: [CDNi] I-D Action: draft-ietf-cdni-footprint-capabilities-semantics-12.txt Thread-Index: AQHReWZRcaZPVJwVpU69J31JUKDX7p9P2gPA Date: Tue, 8 Mar 2016 18:15:19 +0000 Message-ID: References: <20160308181404.25230.91803.idtracker@ietfa.amsl.com> In-Reply-To: <20160308181404.25230.91803.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCLMWRmVeSWpSXmKPExsUyuXRPrO4ssfthBk+Oy1k8nf2H1YHRY8mS n0wBjFFcNimpOZllqUX6dglcGVd3T2Ir2CRScWXFYeYGxrP8XYycHBICJhIvj1xhh7DFJC7c W88GYgsJHGGUuLWBu4uRC8hexiix+vsJJpAEm4CWxOOvf4FsDg4RAWWJn4ccQcLCApESv9cd ACsREYiS+NJ5iRXCNpLY9+UVC4jNIqAicbV9Edh8XgFfidk3ZzNC7HKUmNR8F6yGU8BJ4uaF NWC9jED3fD+1Bmwms4C4xK0n85kg7hSQWLLnPDOELSrx8vE/VghbUWJf/3R2iHodiQW7P7FB 2NoSyxa+ZobYKyhxcuYTlgmMorOQjJ2FpGUWkpZZSFoWMLKsYuQoLS7IyU03MtzECAz7YxJs jjsY9/Z6HmIU4GBU4uH9wH4vTIg1say4MvcQowQHs5IIb7XI/TAh3pTEyqrUovz4otKc1OJD jNIcLErivN8+Xg4TEkhPLEnNTk0tSC2CyTJxcEo1MIY4mAl+ujc9oe3cmm8O12Pr10c9s9uZ J1t/NcIk5dYD3yD9VpNqkdnHngSc/3PYONN1gsD6vgPcjJlh23J2mby913pG/cHveYftL1fG 1hXvNdZbk73gssPRu61f/lvIc/xRuGWccuvwA7mt+svyXb695zteExhUaykrrZqT3aGWbe58 4NXaOUosxRmJhlrMRcWJAGbRe6Z3AgAA Archived-At: Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-footprint-capabilities-semantics-12.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 08 Mar 2016 18:15:28 -0000 Hi All, This version has the updates to address Barry's AD review comments. I al= so did a spell check and fixed some typos. thanx! -- Kevin J. Ma > -----Original Message----- > From: CDNi [mailto:cdni-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Tuesday, March 08, 2016 1:14 PM > To: i-d-announce@ietf.org > Cc: cdni@ietf.org > Subject: [CDNi] I-D Action: draft-ietf-cdni-footprint-capabilities- > semantics-12.txt >=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 Interconnectio= n > of the IETF. >=20 > Title : CDNI Request Routing: Footprint and Capabilitie= s > Semantics > Authors : Jan Seedorf > Jon Peterson > Stefano Previdi > Ray van Brandenburg > Kevin J. Ma > Filename : draft-ietf-cdni-footprint-capabilities-semantics- > 12.txt > Pages : 21 > Date : 2016-03-08 >=20 > Abstract: > This document captures the semantics of the "Footprint and > Capabilities Advertisement" part of the CDNI Request Routing > interface, i.e., the desired meaning of "Footprint" and > "Capabilities" in the CDNI context, and what the "Footprint and > Capabilities Advertisement Interface (FCI)" offers within CDNI. The > document also provides guidelines for the CDNI FCI protocol. It > further defines a Base Advertisement Object, the necessary registries > for capabilities and footprints, and guidelines on how these > registries can be extended in the future. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-cdni-footprint-capabilities- > semantics/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-cdni-footprint-capabilities- > semantics-12 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-footprint-capabilitie= s- > semantics-12 >=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 Tue Mar 8 10:25:19 2016 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 D420712D972; Tue, 8 Mar 2016 10:25:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id noOSAqlzyGRP; Tue, 8 Mar 2016 10:25:14 -0800 (PST) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B4FD12D967; Tue, 8 Mar 2016 10:17:04 -0800 (PST) X-AuditID: c618062d-f79dd6d000003091-32-56df125157c7 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 00.F1.12433.1521FD65; Tue, 8 Mar 2016 18:56:33 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0248.002; Tue, 8 Mar 2016 13:16:59 -0500 From: Kevin Ma J To: Barry Leiba Thread-Topic: AD review of draft-ietf-cdni-footprint-capabilities-semantics-11 Thread-Index: AQHReTaNMksETV9o5kyOXKQUfIKjlJ9PnKCggABkdgD//7A70IAAKWNw Date: Tue, 8 Mar 2016 18:16:58 +0000 Message-ID: References: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMLMWRmVeSWpSXmKPExsUyuXRPrG6g0P0wgz2TxSwOLb7EavF09h9W i9dzrzE5MHu0rOpl9liy5CdTAFMUl01Kak5mWWqRvl0CV8bt/4uYCs4pVRzfP42xgfGOYhcj B4eEgInExla1LkZOIFNM4sK99WxdjFwcQgJHGCU+f7rECOEsY5R4+qSRBaSKTUBL4vHXv0wg toiApsTzz1OYQIqYBRYxSlzqOw5WJCzgK7H/2FUWiKIAiZlPJrJD2G4S/ye+B7NZBFQk7q3Y xAJyBS9Q/cU7HBDL7jBKrHjXzAhSwwh00vdTa8CWMQuIS9x6Mp8J4lQBiSV7zjND2KISLx// Y4WwFSX29U9nB5nJDHTc+l36EK2KElO6H4Kt5RUQlDg58wnLBEbRWUimzkLomIWkYxaSjgWM LKsYOUqLC3Jy040MNjECo+KYBJvuDsb70z0PMQpwMCrx8H5gvxcmxJpYVlyZe4hRgoNZSYR3 mej9MCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8699eDhMSSE8sSc1OTS1ILYLJMnFwSjUwNv0V C3e6cfupytM6ldYPV32Oa7zuexZqYGcTXRC49I5v21WzY4KPmza1F5UvOb7J0allQtbmnU9q rWT8VHS75dZ6GaSad+W8+P5axTWO+8c96b8yzy5enckb8E3X0Hvxmym/3IyfJN/c/yE8NNrV O/SYvWFdx6oFxpNbuy2CkyxSZv8tj4tQYinOSDTUYi4qTgQAfhSlVYYCAAA= Archived-At: Cc: "" , "draft-ietf-cdni-footprint-capabilities-semantics@ietf.org" Subject: Re: [CDNi] AD review of draft-ietf-cdni-footprint-capabilities-semantics-11 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 08 Mar 2016 18:25:18 -0000 SGkgQmFycnksDQoNCiAgSSd2ZSBwb3N0ZWQgLTEyLCB3aGljaCBob3BlZnVsbHkgYWRkcmVzc2Vz IHlvdXIgY29tbWVudHMuICBJIHRvb2sgYWxsIGJ1dCBvbmUgb2YgdGhlIGVkaXRvcmlhbCBzdWdn ZXN0aW9ucywgYW5kIGZpeGVkIGEgY291cGxlIG9mIHJhbmRvbSB0eXBvcy4gIFBsZWFzZSBsZXQg bWUga25vdyBpZiB5b3Ugc2VlIGFueXRoaW5nIGZ1cnRoZXIgdGhhdCBuZWVkcyBhZGRyZXNzZWQu DQoNCnRoYW54IQ0KDQotLSAgS2V2aW4gSi4gTWENCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiBGcm9tOiBLZXZpbiBNYSBKDQo+IFNlbnQ6IFR1ZXNkYXksIE1hcmNoIDA4LCAyMDE2 IDEwOjQ4IEFNDQo+IFRvOiAnQmFycnkgTGVpYmEnDQo+IENjOiBkcmFmdC1pZXRmLWNkbmktZm9v dHByaW50LWNhcGFiaWxpdGllcy1zZW1hbnRpY3NAaWV0Zi5vcmc7DQo+IDxjZG5pQGlldGYub3Jn Pg0KPiBTdWJqZWN0OiBSRTogQUQgcmV2aWV3IG9mIGRyYWZ0LWlldGYtY2RuaS1mb290cHJpbnQt Y2FwYWJpbGl0aWVzLQ0KPiBzZW1hbnRpY3MtMTENCj4gDQo+IEhpIEJhcnJ5LA0KPiANCj4gICBJ J2xsIG1ha2UgdGhlIHVwZGF0ZXMgYW5kIHN1Ym1pdCBhIG5ldyB2ZXJzaW9uLg0KPiANCj4gdGhh bnghDQo+IA0KPiAtLSAgS2V2aW4gSi4gTWENCj4gDQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gPiBGcm9tOiBiYXJyeWxlaWJhQGdtYWlsLmNvbSBbbWFpbHRvOmJhcnJ5bGVpYmFA Z21haWwuY29tXSBPbiBCZWhhbGYgT2YNCj4gPiBCYXJyeSBMZWliYQ0KPiA+IFNlbnQ6IFR1ZXNk YXksIE1hcmNoIDA4LCAyMDE2IDEwOjMzIEFNDQo+ID4gVG86IEtldmluIE1hIEoNCj4gPiBDYzog ZHJhZnQtaWV0Zi1jZG5pLWZvb3RwcmludC1jYXBhYmlsaXRpZXMtc2VtYW50aWNzQGlldGYub3Jn Ow0KPiA+IDxjZG5pQGlldGYub3JnPg0KPiA+IFN1YmplY3Q6IFJlOiBBRCByZXZpZXcgb2YgZHJh ZnQtaWV0Zi1jZG5pLWZvb3RwcmludC1jYXBhYmlsaXRpZXMtDQo+ID4gc2VtYW50aWNzLTExDQo+ ID4NCj4gPiBUaGFua3MgZm9yIHRoZSBxdWljayByZXBseSwgS2V2aW4uDQo+ID4NCj4gPiA+PiAg ICBBZHZlcnRpc2Vpbmcgc3VwcG9ydA0KPiA+ID4+ICAgIGZvciBtYW5kYXRvcnktdG8taW1wbGVt ZW50IEdlbmVyaWNNZXRhZGF0YSB0eXBlcyBTSE9VTEQgYmUNCj4gc3VwcG9ydGVkDQo+ID4gPj4g ICAgYnV0IHdvdWxkIGJlIHJlZHVuZGFudC4gIENETnMgU0hPVUxEIE5PVCBhZHZlcnRpc2Ugc3Vw cG9ydCBmb3INCj4gPiA+PiAgICBtYW5kYXRvcnktdG8taW1wbGVtZW50IEdlbmVyaWNNZXRhZGF0 YSB0eXBlcy4NCj4gPiA+Pg0KPiA+ID4+IEkgZG9uJ3QgdW5kZXJzdGFuZCB0aGlzIGNvbWJpbmF0 aW9uIG9mIHJlcXVpcmVtZW50cy4gIEl0IGFwcGVhcnMgdG8NCj4gPiA+PiBzYXkgdGhhdCB5b3Ug U0hPVUxEIGJlIGFibGUgdG8gYWR2ZXJ0aXNlIHN1cHBvcnQgZm9yIE10SSB0eXBlcywgYnV0DQo+ ID4gPj4gdGhhdCB5b3UgU0hPVUxEIE5PVCBkbyBpdC4gIElzIHRoYXQgY29ycmVjdD8gIFdoYXQv d2h5PyAgKEFsc28sDQo+ID4gPj4gImFkdmVydGlzaW5nIiBvbmx5IGhhcyBvbmUgImUiLikNCj4g PiA+DQo+ID4gPiBUaGUgdGhvdWdodCBoZXJlIHdhcyB0aGF0IHdlIHdhbnQgdG8gYmUgYWJsZSB0 byBhZHZlcnRpc2Ugd2hlbiBhIGRDRE4NCj4gPiA+IGRvZXMgbm90IHN1cHBvcnQgYSBnaXZlbiBN dEkgbWV0YWRhdGE7IGl0IGNvdWxkIGJlIGEgdGVtcG9yYXJ5IG91dGFnZSwNCj4gPiA+IGluIGEg bGltaXRlZCBmb290cHJpbnQsIGJ1dCBzdWNoIGEgY2FwYWJpbGl0eSBhZHZlcnRpc2VtZW50IHdv dWxkIGJlDQo+ID4gPiB2YWxpZC4gIFRoZSBkQ0ROIHdvdWxkIGFsc28gbmVlZCB0byBiZSBhYmxl IHRvIGFkdmVydGlzZSB3aGVuIHN1cHBvcnQNCj4gPiA+IHdhcyByZWVzdGFibGlzaGVkLiAgVGhl cmUgd2FzIGFsc28gYSB0aG91Z2h0IHRoYXQgd2UgbWlnaHQgd2FudCBhIGZ1bGwNCj4gPiA+IGNh cGFiaWxpdHkgc3RhdGUgZHVtcCBjb21tYW5kLCBpbiB3aGljaCBjYXNlIHdlIHdvdWxkIHNlbmQg TXRJDQo+ID4gPiBtZXRhZGF0YSBhcyB3ZWxsLiAgSW4gdGhlIHR5cGljYWwgY2FzZSwgaG93ZXZl ciwgd2Ugd2FudGVkIHRvIG5vdA0KPiA+ID4gd2FzdGUgdGhlIGJhbmR3aWR0aCBzZW5kaW5nIE10 SSBtZXRhZGF0YSBpbmZvcm1hdGlvbiB3aGVuIHdlIGZpZ3VyZWQNCj4gPiA+IHRoZXkgd291bGQg YWxsIGJlIHN1cHBvcnRlZC4NCj4gPiA+DQo+ID4gPiBXb3VsZCBpdCBoZWxwIHRvIG1ha2UgdGhl IHNlY29uZCBzZW50ZW5jZSBhIFJFQ09NTUVORCwgcmF0aGVyIHRoYW4gYQ0KPiA+ID4gU0hPVUxE LCBhbmQgYWRkIHNvbWUgdGV4dCBhcyB0byB0aGUgcmVhc29uaW5nIChpLmUuLCBzYXZpbmcgYml0 cyk/DQo+ID4NCj4gPiBXZWxsLCBSRUNPTU1FTkQgYW5kIFNIT1VMRCBtZWFuIHRoZSBzYW1lIHRo aW5nIChzZWUgUkZDIDIxMTkpOyB0aGV5J3JlDQo+ID4ganVzdCBkaWZmZXJlbnQgcGFydHMgb2Yg c3BlZWNoLiAgWWVzLCBpdCB3b3VsZCBoZWxwIHRvIHJlcGhyYXNlIGFuZA0KPiA+IGV4cGxhaW4g d2hhdCB0aGUgaXNzdWUgaXMgaGVyZS4NCj4gPg0KPiA+ID4+IEluIHRoZSA4LjEgc3Vic2VjdGlv bnM6DQo+ID4gPj4NCj4gPiA+PiAgICBFbmNvZGluZzogc2VlIFNlY3Rpb24gNw0KPiA+ID4+DQo+ ID4gPj4gV2hlcmUgaW4gU2VjdGlvbiA3IGlzIHRoZSBpbmZvcm1hdGlvbiBhYm91dCBlbmNvZGlu Zz8NCj4gPiA+DQo+ID4gPiBTZWN0aW9uIDcuNSBoYXMgdGhlIGV4YW1wbGUgb2YgdGhlIGNhcGFi aWxpdHkgc2VyaWFsaXphdGlvbiBvZiB0aGUNCj4gPiA+IHRocmVlIG9iamVjdHMgZGVzY3JpYmVk IGluIHNlY3Rpb25zIDcuMiwgNy4zLCBhbmQgNy40IChjb3JyZXNwb25kaW5nDQo+ID4gPiB0byB0 aGUgcmVnaXN0cmF0aW9ucyBpbiBzZWN0aW9ucyA4LjEuMSwgOC4xLjIsIGFuZCA4LjEuMykNCj4g PiA+DQo+ID4gPiBXb3VsZCBpdCBoZWxwIHRvIG1ha2UgdGhlIHNlY3Rpb24gcmVmZXJlbmNlcyA3 LjIgYW5kIDcuNSwgNy4zIGFuZCA3LjUsDQo+ID4gPiBhbmQgNy40IGFuZCA3LjUsIGluIHNlY3Rp b25zIDguMS4xLCA4LjEuMiwgYW5kIDguMS4zLCByZXNwZWN0aXZlbHk/DQo+ID4NCj4gPiBJdCB3 b3VsZC4gIFRoYW5rcy4NCj4gPg0KPiA+IEknbGwgd2F0Y2ggZm9yIGFuIHVwZGF0ZSwgYW5kIHdp bGwgcmVxdWVzdCBsYXN0IGNhbGwgdGhlbi4NCj4gPg0KPiA+IEJhcnJ5DQo= From nobody Tue Mar 8 10:40:17 2016 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 7A0C312D99A; Tue, 8 Mar 2016 10:40:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a2YsRW3g1Qlt; Tue, 8 Mar 2016 10:40:14 -0800 (PST) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::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 EF94312D98B; Tue, 8 Mar 2016 10:35:05 -0800 (PST) Received: by mail-ig0-x22e.google.com with SMTP id z8so24892455ige.0; Tue, 08 Mar 2016 10:35:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=9U/1HTrREj0ekS20N3cOUug7cskC1b4hMT/0qLrgjio=; b=b2cjmGJ99KI9094o28caXYqPBjB1wme/ANkdI2Y3UAAAXY58tVgSbfTazHKPmvjPdD MbBAN1GS/crxTVtWoiys9jHKH2ZiDSVPkVg1txsIMlwrxgzFKnVI0u0lWmXqX9Gr0Uig P6+eqoM/3aFe91A9SQ53PwiNWKvI3Xvcj5xtn/GoFUf4mwV4VOgj+vq4yhhg8vCu1QTB cripfBSAZhyDJWM8cr9ksAzXedN8wU/3mrMbcNzVblLWT07hhCvBwE0+/hZjmUlUgoLP SWkiI8EEvE54tja818tHjBtJtcBGfRTM/7iY50pVtb5Kw8voIUwDVn4jOIe3pZvrlHr9 z+uA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=9U/1HTrREj0ekS20N3cOUug7cskC1b4hMT/0qLrgjio=; b=EI+SBcey64a2CVib/DGzHZhkOixxSX9nAvzFDjj+mNSqVwXwDc33pmqvFhOW7UhL6F GVO4+cd/fauI3aX96dwFQEBlB23SrRK44ifRc0hr0VPLjCxFgiXHKsFR3gDbbcd1fw1m bRJwOGiUmAVNVatpH8S9Lqi2CNurTfr5UDnKksdvt0Jfzorq3s6HrnVSPq4vSThAtNBN L+mW1qldcz4dUXGjmCMFFF7Vh4oquRTuaROwta9kTLVZzD4JvkPfPZoAs5cneJCe1UwZ Fv8b60YGsbKWhbJ2YbuJhckoVd2WLHN7WhhVolQHf56IWIYt4w4cJBede8RxKJdhWneK jBTg== X-Gm-Message-State: AD7BkJLL0IDe7A1kSj9OXT00egE4arjRM5E9odaTUKqzPXm9mCcbnfJx6t354xbzHOn+uZwGZn/YTA+3fh5xSg== MIME-Version: 1.0 X-Received: by 10.50.138.72 with SMTP id qo8mr19815541igb.81.1457462104985; Tue, 08 Mar 2016 10:35:04 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.36.59.133 with HTTP; Tue, 8 Mar 2016 10:35:04 -0800 (PST) In-Reply-To: References: Date: Tue, 8 Mar 2016 18:35:04 +0000 X-Google-Sender-Auth: 8nneqQuh5zS6-U72XZj1UqlybdA Message-ID: From: Barry Leiba To: Kevin Ma J Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" , "draft-ietf-cdni-footprint-capabilities-semantics@ietf.org" Subject: Re: [CDNi] AD review of draft-ietf-cdni-footprint-capabilities-semantics-11 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 08 Mar 2016 18:40:15 -0000 Looks great; thanks. Last call going out... Barry On Tue, Mar 8, 2016 at 6:16 PM, Kevin Ma J wrote: > Hi Barry, > > I've posted -12, which hopefully addresses your comments. I took all but one of the editorial suggestions, and fixed a couple of random typos. Please let me know if you see anything further that needs addressed. > > thanx! > > -- Kevin J. Ma > >> -----Original Message----- >> From: Kevin Ma J >> Sent: Tuesday, March 08, 2016 10:48 AM >> To: 'Barry Leiba' >> Cc: draft-ietf-cdni-footprint-capabilities-semantics@ietf.org; >> >> Subject: RE: AD review of draft-ietf-cdni-footprint-capabilities- >> semantics-11 >> >> Hi Barry, >> >> I'll make the updates and submit a new version. >> >> thanx! >> >> -- Kevin J. Ma >> >> > -----Original Message----- >> > From: barryleiba@gmail.com [mailto:barryleiba@gmail.com] On Behalf Of >> > Barry Leiba >> > Sent: Tuesday, March 08, 2016 10:33 AM >> > To: Kevin Ma J >> > Cc: draft-ietf-cdni-footprint-capabilities-semantics@ietf.org; >> > >> > Subject: Re: AD review of draft-ietf-cdni-footprint-capabilities- >> > semantics-11 >> > >> > Thanks for the quick reply, Kevin. >> > >> > >> Advertiseing support >> > >> for mandatory-to-implement GenericMetadata types SHOULD be >> supported >> > >> but would be redundant. CDNs SHOULD NOT advertise support for >> > >> mandatory-to-implement GenericMetadata types. >> > >> >> > >> I don't understand this combination of requirements. It appears to >> > >> say that you SHOULD be able to advertise support for MtI types, but >> > >> that you SHOULD NOT do it. Is that correct? What/why? (Also, >> > >> "advertising" only has one "e".) >> > > >> > > The thought here was that we want to be able to advertise when a dCDN >> > > does not support a given MtI metadata; it could be a temporary outage, >> > > in a limited footprint, but such a capability advertisement would be >> > > valid. The dCDN would also need to be able to advertise when support >> > > was reestablished. There was also a thought that we might want a full >> > > capability state dump command, in which case we would send MtI >> > > metadata as well. In the typical case, however, we wanted to not >> > > waste the bandwidth sending MtI metadata information when we figured >> > > they would all be supported. >> > > >> > > Would it help to make the second sentence a RECOMMEND, rather than a >> > > SHOULD, and add some text as to the reasoning (i.e., saving bits)? >> > >> > Well, RECOMMEND and SHOULD mean the same thing (see RFC 2119); they're >> > just different parts of speech. Yes, it would help to rephrase and >> > explain what the issue is here. >> > >> > >> In the 8.1 subsections: >> > >> >> > >> Encoding: see Section 7 >> > >> >> > >> Where in Section 7 is the information about encoding? >> > > >> > > Section 7.5 has the example of the capability serialization of the >> > > three objects described in sections 7.2, 7.3, and 7.4 (corresponding >> > > to the registrations in sections 8.1.1, 8.1.2, and 8.1.3) >> > > >> > > Would it help to make the section references 7.2 and 7.5, 7.3 and 7.5, >> > > and 7.4 and 7.5, in sections 8.1.1, 8.1.2, and 8.1.3, respectively? >> > >> > It would. Thanks. >> > >> > I'll watch for an update, and will request last call then. >> > >> > Barry From nobody Tue Mar 8 10:51:58 2016 Return-Path: X-Original-To: cdni@ietf.org Delivered-To: cdni@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 545BF12D9C2; Tue, 8 Mar 2016 10:51:57 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.15.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20160308185157.22209.39132.idtracker@ietfa.amsl.com> Date: Tue, 08 Mar 2016 10:51:57 -0800 Archived-At: Cc: cdni@ietf.org, draft-ietf-cdni-footprint-capabilities-semantics@ietf.org, barryleiba@gmail.com, cdni-chairs@ietf.org Subject: [CDNi] Last Call: (CDNI Request Routing: Footprint and Capabilities Semantics) to Informational RFC X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org 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, 08 Mar 2016 18:51:57 -0000 The IESG has received a request from the Content Delivery Networks Interconnection WG (cdni) to consider the following document: - 'CDNI Request Routing: Footprint and Capabilities Semantics' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-03-22. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document captures the semantics of the "Footprint and Capabilities Advertisement" part of the CDNI Request Routing interface, i.e., the desired meaning of "Footprint" and "Capabilities" in the CDNI context, and what the "Footprint and Capabilities Advertisement Interface (FCI)" offers within CDNI. The document also provides guidelines for the CDNI FCI protocol. It further defines a Base Advertisement Object, the necessary registries for capabilities and footprints, and guidelines on how these registries can be extended in the future. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-cdni-footprint-capabilities-semantics/ When IESG discussion begins, it can be tracked via https://datatracker.ietf.org/doc/draft-ietf-cdni-footprint-capabilities-semantics/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/2656/ From nobody Fri Mar 11 06:03:17 2016 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 8A2B612D6F4 for ; Fri, 11 Mar 2016 06:03:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 7GwQ30n2hAOE for ; Fri, 11 Mar 2016 06:03:14 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E74D712D6C7 for ; Fri, 11 Mar 2016 06:03:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1325; q=dns/txt; s=iport; t=1457704991; x=1458914591; h=from:to:cc:subject:date:message-id:mime-version; bh=Ijos8/m9V67Tx9mhAopoaNZtkoIvm54mptxdyEDJf+w=; b=km7/k+34vzp6eSy8KdcomGFmpnNy+iMOER10kte4ycDfHovBSLXvB94d yJbNo9yIZTzf50fssOC9X0t7iBodFdkvkbhxGMQX5OUfxRMdNKYMcp2lx NuXWaAoKS/LPsYLYcDfX7NrYbOr/L4vZlZTkRaBup2SQwHtS8zYzwJBNK c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BGAgCWz+JW/4MNJK1egnJMUnOqTo9WA?= =?us-ascii?q?Q2BbR2FcIEvOBQBAQEBAQEBZCeEOAwEeRIBCwF0JwQOiCkOvQ4BAQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQERBIgLgk+BN1WCW4J+gQ8Fl0MBhWyID48CjnABHgEBQoIQg?= =?us-ascii?q?VSKPX4BAQE?= X-IronPort-AV: E=Sophos; i="5.24,320,1454976000"; d="scan'208,217"; a="80046452" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Mar 2016 14:03:10 +0000 Received: from XCH-ALN-017.cisco.com (xch-aln-017.cisco.com [173.36.7.27]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u2BE3AD6006993 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 11 Mar 2016 14:03:10 GMT Received: from xch-rcd-020.cisco.com (173.37.102.30) by XCH-ALN-017.cisco.com (173.36.7.27) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 11 Mar 2016 08:03:10 -0600 Received: from xch-rcd-020.cisco.com ([173.37.102.30]) by XCH-RCD-020.cisco.com ([173.37.102.30]) with mapi id 15.00.1104.009; Fri, 11 Mar 2016 08:03:10 -0600 From: "Francois Le Faucheur (flefauch)" To: "" Thread-Topic: Reminder: I-D Cut-off is on Monday 21 March Thread-Index: AQHRe56+MPBKGSPqhU2tZcy7Fckxug== Date: Fri, 11 Mar 2016 14:03:10 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.155.23] Content-Type: multipart/alternative; boundary="_000_F0B9FB0B10A3482DA31153356E954EAAciscocom_" MIME-Version: 1.0 Archived-At: Subject: [CDNi] Reminder: I-D Cut-off is on Monday 21 March X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 11 Mar 2016 14:03:16 -0000 --_000_F0B9FB0B10A3482DA31153356E954EAAciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable * 2016-03-21 (Monday): Internet Draft submission cut-off (for all draft= s, including -00) by UTC 23:59, upload using IETF ID Submission Tool. --_000_F0B9FB0B10A3482DA31153356E954EAAciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <371F52F9C23EB847AB6BF48C53055D40@emea.cisco.com> Content-Transfer-Encoding: quoted-printable

  • 2016-03-21 (Monday): Intern= et Draft submission cut-off (for all drafts, including -00) by UTC 23:59, u= pload using IETF ID Submission Tool.

--_000_F0B9FB0B10A3482DA31153356E954EAAciscocom_-- From nobody Tue Mar 15 10:46:31 2016 Return-Path: X-Original-To: cdni@ietf.org Delivered-To: cdni@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EE58012DD6E; Fri, 11 Mar 2016 15:05:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.16.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160311230531.15028.17830.idtracker@ietfa.amsl.com> Date: Fri, 11 Mar 2016 15:05:31 -0800 Archived-At: X-Mailman-Approved-At: Tue, 15 Mar 2016 10:46:28 -0700 Cc: cdni@ietf.org, barryleiba@computer.org Subject: [CDNi] cdni - Requested session has been scheduled for IETF 95 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 11 Mar 2016 23:05:34 -0000 Dear Francois Le Faucheur, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. cdni Session 1 (2:00:00) Thursday, Afternoon Session I 1400-1600 Room Name: Atlantico B size: 125 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Content Delivery Networks Interconnection Area Name: Applications and Real-Time Area Session Requester: Francois Le Faucheur Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 60 Conflicts to Avoid: First Priority: storm tsvwg tcpm ppsp nfsv4 mptcp ippm alto httpbis Second Priority: appsawg rmcat Special Requests: WebEx is not needed if Meetecho is provided --------------------------------------------------------- From nobody Tue Mar 15 19:21:23 2016 Return-Path: X-Original-To: cdni@ietf.org Delivered-To: cdni@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 313A112DDA9; Tue, 15 Mar 2016 19:21:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.16.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160316022119.12526.24798.idtracker@ietfa.amsl.com> Date: Tue, 15 Mar 2016 19:21:19 -0700 Archived-At: Cc: cdni@ietf.org, draft-ietf-cdni-redirection@ietf.org, cdni-chairs@ietf.org Subject: [CDNi] Ben Campbell's No Objection on draft-ietf-cdni-redirection-17: (with COMMENT) X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 16 Mar 2016 02:21:19 -0000 Ben Campbell has entered the following ballot position for draft-ietf-cdni-redirection-17: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cdni-redirection/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I have a few comments and questions: # Substantive: # - 3, last paragraph: "Any operational mechanisms this requires, e.g., private key distribution to surrogates and request routers in dCDNs, are outside the scope of this document. Further mechanisms to notify User Agents of trusted redirection are also outside the scope of this document." Is it in scope _somewhere_? As it is, this seems like an excuse to avoid HTTPS, which is not optimal. -4, first paragraph: Was any thought given to using or supporting HTTP/2? -- step 1 after figure 1: I am I correct to infer an assumption that CDN A acts as the UAs DNS server? Is that assumption documented somewhere? - 4.2, last paragraph (note) This explicitly makes an IPv6 only CDN non-compliant. Is that the intent? - 4.4.1, table, entry for dns-only: The description says "MUST include RTs". That doesn't seem to consider error cases. - 4.8, 3rd and 4th paragraph: I'm curious why they SHOULDs are not MUSTs. Are there times it might be reasonable to do something different; maybe even choosing not to send an error at all? I wonder if these should be of the form of "MUST send an error which SHOULD be XXX" -5.1, 2nd to last paragraph: " In an environment where any such protection is required...," is a pretty weak recommendation. Would you consider making the default behavior secure? Or at least saying something to the effect of "Except in networks where similar protections are provided by some other means,..."? -5.2, First paragraph: I have trouble imagining situations where information passed over the RI might not be sensitive. -- third paragraph: I wish the text wasn't so dismissive of attempts to anonymize some RI request data. I agree doing so may reduce RI effectiveness in some cases. But that needs to be balanced with privacy needs, and that balance may not always land on the side of RI effectiveness. And the inability to correlate UAs between requests can be a feature in some circumstances. # Editorial: # - General: There's quite a bit of repetition and redundant text, including redundant normative text. - abstract: s/"The Request Routing Interface..."/ "The Content Delivery Network Interface (CDNI) Request Routing Interface..." s/"comprises of"/"comprises" - 4, 2nd paragraph: "The same HTTP interface is used for both DNS and HTTP redirection of User Agent requests,..." >From the rest of the sentence, I assume this means the RI uses the same interface to communicate information about DNS and HTTP redirects—but the first part sounds like it is saying that the actual redirection (i.e. interacting with the UA) occurs over the same interface. -- 4th paragraph: s/"try and"/"try to" - 4.1, 2nd to last paragraph: "... signaled the HTTP response body of the RI response ..." Missing word? (perhaps "... signaled in the HTTP response body ..." -4.2, paragraph 4: This paragraph is redundant to section 4.8. -4.5.1, last paragraph before example: "For example, it MAY only send the contents of the first occurrence of the HTTP Headers instead." s/MAY/might. From nobody Wed Mar 16 16:23:04 2016 Return-Path: X-Original-To: cdni@ietf.org Delivered-To: cdni@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 78E9E12D567; Wed, 16 Mar 2016 16:23:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160316232303.13060.881.idtracker@ietfa.amsl.com> Date: Wed, 16 Mar 2016 16:23:03 -0700 Archived-At: Cc: cdni@ietf.org, draft-ietf-cdni-redirection@ietf.org, cdni-chairs@ietf.org Subject: [CDNi] Alissa Cooper's Discuss on draft-ietf-cdni-redirection-17: (with DISCUSS) X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 16 Mar 2016 23:23:03 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-cdni-redirection-17: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cdni-redirection/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- (1) There is some ambiguity in the document about whether the uCDN passes the IP address of the UA or its prefix to the dCDN. Sec 4.4.1 says that for DNS redirection, the uCDN passes "IP address or prefix" of the UA, but then in the definition of resolver-ip specifies it only as the IP address of the UA. Then in Sec 4.5.1 for HTTP redirection the equivalent field is specified as the IP address of the UA and the possibility of sending only a prefix is not mentioned. Then 5.2 has the para that begins "While it is technically possible to mask some information in the RI Request, such as the last bits of the UA IP address ..." which makes it seem like prefixes really shouldn't be sent. I think the document needs some consistency and clarity here about whether prefixes are expected to be used for either redirection method. It's also not obvious to me why the document shouldn't recommend to uCDNs that if they are polling multiple candidate dCDNs as described in Sec 5.2, they should use only a prefix for such requests. The arguments given against this seem pretty thin -- isn't preventing correlation of multiple requests to a single UA a good thing, especially when it's being done by a bunch of dCDNs? And I don't understand the CGN example -- isn't the root of the problem here that topologically dispersed UAs are sharing the same public-facing IP address, in which case the dCDN may have the same problem when passed a full IP address as it does a prefix? (2) Ben noted the weakness of the recommendation in 5.1 regarding TLS. I see that the language here is the same as it is in draft-ietf-cdni-logging-22. But I thought the agreement on that document was MUST use TLS, full stop. So there is ambiguity in both documents I think. "In an environment where ..." and "When TLS is used ..." seem inconsistent with "TLS MUST be used ...." I'm happy to clear on this if I'm missing something from the previous discussion, which I think happened when I was on leave and resulted from one of Stephen's ballots. From nobody Thu Mar 17 03:10:18 2016 Return-Path: X-Original-To: cdni@ietf.org Delivered-To: cdni@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B965A12D506; Thu, 17 Mar 2016 03:10:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160317101014.1026.78717.idtracker@ietfa.amsl.com> Date: Thu, 17 Mar 2016 03:10:14 -0700 Archived-At: Cc: cdni@ietf.org, draft-ietf-cdni-redirection@ietf.org, cdni-chairs@ietf.org Subject: [CDNi] Stephen Farrell's Discuss on draft-ietf-cdni-redirection-17: (with DISCUSS and COMMENT) X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 17 Mar 2016 10:10:14 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-cdni-redirection-17: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cdni-redirection/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- The basic idea of the uCDN sending everything to the dCDN so that the dCDN can reply with all the details of a request that'll work (i.e. the sc-* stuff) seems broken as it requires that the uCDN expose all security and privacy sensitive data to the dCDN in pretty much all cases. I fail to see why that is an acceptable approach. Can you point me at where the WG disucssed the issues with that approach and considered less security/privacy unfriendly potential alternatives? Some examples: - section 4.1 says "SHOULD convey as much information as possible" that is surely wrong - there is no reason to encourage sending cookies and other security/privacy sensitive information and in fact sending such should be discouraged (SHOULD NOT) or even, if possible, prohibited (MUST NOT). - The cs-(cookie) in 4.5.1 is one specific case of sending too much. - 4.4.1 Resolver IP addr is liable to be that of an end user's machine (if they operate a recursive). But the examples are just that, I'd like to DISCUSS the WG's consideration of the overall design first before we dive into those. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - I support Alissa's discuss points. - section 3: false-negative? don't you mean false-positive? And in any case, those warnings are not false from the browser perspective. I'd suggest s/false-negative// - section 3: phrases like "trusted re-direction" are a bad idea - you need to say who is trusting whom for what for this to be meaningful and not misleading (people get misled by such phrases all the time). I'd just delete the sentence or s/trusted// - 4.4.2: a JSON "string" is not the same as a DNS name is it? What about i18n? (ULABEL or ALABEL?) what about odd characters allowed in JSON but not in DNS names? In general the fields in this dictionary (and others) seem underspecified to me. From nobody Thu Mar 17 10:12:23 2016 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 412E712DCBB; Thu, 17 Mar 2016 10:12:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 dzhT9BokVuW0; Thu, 17 Mar 2016 10:12:20 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (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 3FE4B12DC65; Thu, 17 Mar 2016 10:10:28 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id h129so108064769ywb.1; Thu, 17 Mar 2016 10:10:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=wNByoEroZmZOZW139VX7gl2WKiglk/IMk3NpwamqAfo=; b=T7HINpaiWnFym3D57LGkCPkhnCITIgVwrnr2pAvo5xH0dDZ7XrqJTVxu7AhglNItDw 00Tn7VbbJWLpoMObIVdFlYwZFkBmpH8MQY6Sl52082Rb7luDTUNRsn9BahHPPcGyOF4y mFYWh0aPx7uWx7dOy32CQTWXgPWUOloWjiYkkeCAIItyVbCIlvJ8kesPylLmz9g9EOEV hPVGrk/VrTcKF1w3eCTrccMZur+iMDZ3yITxnZasdyLTUwvAY05jJry2XfJrqyofHuQv hJGkRlWf/qbhrGcp7JAGiO/T7etMJltpt4AnH6Mb5NQxmcGHASFDqQ+/bzRhLycZfd67 1Tww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=wNByoEroZmZOZW139VX7gl2WKiglk/IMk3NpwamqAfo=; b=M0TeHfKfe2GXhR6p/wqrpD2Y7rmgUhMWYTHjFp2pcA3AsAmVXn/1161ukufFIlGMcd 0/+3lAam3Y2bTJhEw+S2Bkn3ByzrJYEu/I/GmzrQrKkxWWqeOQZjEqL+FuXNudtT2nQ7 g9hjyTwXKGxL8rfg6cw49QgrTDxnVFtK2ff6FU6Cyjqqli1IhJhRtVEUHJthq4mH8MOX 2tWY0eH/z8OCC6NleP+fmtZmFIxW3e2rxApgffJdI9zedQRKueQeXPn+R1mpbM7ySpS5 qjKMohw1IO3HGId3cIChy9THhqO0PnKdxerUpK5tmG9iGGebTY2uN87Qt7VFNeg948Qq ekFg== X-Gm-Message-State: AD7BkJLyRO3F1VZGPL67oIYqVaK0GPNE9zemj47nX0leqMTNudDQHy6AT+q5vvoHdZ3HxhOdqIU1ITZY3jbAkQ== MIME-Version: 1.0 X-Received: by 10.129.48.77 with SMTP id w74mr5097680yww.147.1458234627526; Thu, 17 Mar 2016 10:10:27 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.83.78.193 with HTTP; Thu, 17 Mar 2016 10:10:27 -0700 (PDT) In-Reply-To: <20160317170445.26849.16234.idtracker@ietfa.amsl.com> References: <20160317170445.26849.16234.idtracker@ietfa.amsl.com> Date: Thu, 17 Mar 2016 13:10:27 -0400 X-Google-Sender-Auth: v1APt_4NrSzaBVdA5MhOvU4sU4A Message-ID: From: Barry Leiba To: draft-ietf-cdni-redirection@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: Re: [CDNi] ID Tracker State Update Notice: X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 17 Mar 2016 17:12:22 -0000 > IESG state changed to IESG Evaluation::AD Followup from IESG Evaluation > ID Tracker URL: https://datatracker.ietf.org/doc/draft-ietf-cdni-redirection/ What this means is that we're waiting for responses and discussion of the IESG Evaluation comments, and I haven't seen that yet. Authors, please respond to those and engage in the necessary discussion, and please put a priority on that. Thanks, Barry, ART Director From nobody Thu Mar 17 13:12:01 2016 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 91F5E12D779 for ; Thu, 17 Mar 2016 13:12:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001] 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 1ybAPjcVG2KP for ; Thu, 17 Mar 2016 13:11:59 -0700 (PDT) Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by ietfa.amsl.com (Postfix) with SMTP id 3A58C12D6ED for ; Thu, 17 Mar 2016 13:11:59 -0700 (PDT) Received: (qmail 61378 invoked by uid 99); 17 Mar 2016 20:11:58 -0000 Received: from mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 17 Mar 2016 20:11:58 +0000 Received: from mail-ig0-f177.google.com (mail-ig0-f177.google.com [209.85.213.177]) by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with ESMTPSA id 4EF781A0044 for ; Thu, 17 Mar 2016 20:11:58 +0000 (UTC) Received: by mail-ig0-f177.google.com with SMTP id av4so23706333igc.1 for ; Thu, 17 Mar 2016 13:11:58 -0700 (PDT) X-Gm-Message-State: AD7BkJIBuGetOtyXc4JaPaE9MQ4pF/p8I3pP3gpUnz66NQw3qVGT2SbFNTzl7IyFQH1+f2xsHHAFYwqOIRdKUg== X-Received: by 10.50.61.234 with SMTP id t10mr41686721igr.20.1458245517569; Thu, 17 Mar 2016 13:11:57 -0700 (PDT) MIME-Version: 1.0 From: Phil Sorber Date: Thu, 17 Mar 2016 20:11:47 +0000 X-Gmail-Original-Message-ID: Message-ID: To: "cdni@ietf.org" Content-Type: multipart/alternative; boundary=047d7bdc07e211fe95052e443e22 Archived-At: Subject: [CDNi] URI Signing Path Parameters X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 17 Mar 2016 20:12:00 -0000 --047d7bdc07e211fe95052e443e22 Content-Type: text/plain; charset=UTF-8 I have a use case where path parameters (matrix parameters) would be very useful for URI Signing. If we have an HLS manifest with relative URI's, we don't have to modify it to add query params or use other techniques that may have IPR issues. The URI to the manifest has the signed token in it as a path parameter and then that means the base URI will have it also. Thoughts on adding this? Perhaps as a separate RFC? Thanks. --047d7bdc07e211fe95052e443e22 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have a use case where path parameters (matrix parameters= ) would be very useful for URI Signing. If we have an HLS manifest with rel= ative URI's, we don't have to modify it to add query params or use = other techniques that may have IPR issues. The URI to the manifest has the = signed token in it as a path parameter and then that means the base URI wil= l have it also.

Thoughts on adding this? Perhaps as a se= parate RFC?

Thanks.
--047d7bdc07e211fe95052e443e22-- From nobody Thu Mar 17 23:07:19 2016 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 1BF8C12D664 for ; Thu, 17 Mar 2016 23:07:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] 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 mFJnoXq2byfA for ; Thu, 17 Mar 2016 23:07:16 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CAB612D58D for ; Thu, 17 Mar 2016 23:07:16 -0700 (PDT) X-AuditID: c6180641-f79fa6d0000057a9-ef-56eb9af237fd Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id B9.51.22441.2FA9BE65; Fri, 18 Mar 2016 07:06:42 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0248.002; Fri, 18 Mar 2016 02:07:14 -0400 From: Kevin Ma J To: Phil Sorber , "cdni@ietf.org" Thread-Topic: [CDNi] URI Signing Path Parameters Thread-Index: AQHRgIlHncwoVtRwsUKJZ1DRyVb9ZJ9etjPg Date: Fri, 18 Mar 2016 06:07:14 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: multipart/alternative; boundary="_000_A419F67F880AB2468214E154CB8A556206D2CC43eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnkeLIzCtJLcpLzFFi42KZXLrHT/fTrNdhBvv/WVk8nf2H1WLB2fvs DkweP/42sHgsWfKTKYApissmJTUnsyy1SN8ugSvj6pQ2xoIJARXn2jpZGhi/+HYxcnJICJhI HP+8hB3CFpO4cG89WxcjF4eQwBFGiY5jL5kgnOWMEo39r1lBqtgEtCQef/3LBGKLCLhITDm+ HCwuLKAvsXjCDnaIuIHEzo+LmCFsI4mP096wgNgsAqoSb898ZQSxeQV8Je6/XQYWFxIIkLgx 7T4biM0pECgx+fhDsDgj0EXfT60B28UsIC5x68l8JohLBSSW7DnPDGGLSrx8/I8VwlaSmPP6 GjNEfb7EvF/72CB2CUqcnPmEZQKjyCwko2YhKZuFpGwWIwdQXFNi/S59iBJFiSndD9khbA2J 1jlz2ZHFFzCyr2LkKC0uyMlNNzLcxAiMnmMSbI47GPf2eh5iFOBgVOLhLXj6MkyINbGsuDL3 EKMEB7OSCC9n2+swId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rzfPl4OExJITyxJzU5NLUgtgsky cXBKNTBKKKdPclmVvbPwQ2fCgojJ13fxchf3b3lwz/ay/D/LhrRz+xWTuRcVnLv/utNj0cIY tpVPVC4c3mV5+k/rxrZjP/7PtozuiXSS8WQvr55S2pulkfM+y3PRlkIPHf1pPv/SE9kF9q2Z Na9XRfRGxY8frzgVHs6fcWCDutpq1YfXo8tsT0yaL3xSiaU4I9FQi7moOBEAO1Vv1ZoCAAA= Archived-At: Subject: Re: [CDNi] URI Signing Path Parameters X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 18 Mar 2016 06:07:18 -0000 --_000_A419F67F880AB2468214E154CB8A556206D2CC43eusaamb103erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUGhpbCwNCg0KICBKdXN0IHRvIG1ha2Ugc3VyZSBJIHVuZGVyc3RhbmQgY29ycmVjdGx5LCBh cmUgeW91IHN1Z2dlc3RpbmcgdGhhdCwgZ2l2ZW4gYSBVUkkgcGF0aDoNCg0KICAgIC92aWRlby9m b28vaW5kZXgubTN1OA0KDQogIFVSSSBzaWduaW5nIGNvdWxkLCBlLmcuLCBwcmVwZW5kIHRoZSB0 b2tlbiB0byB0aGUgVVJJIHBhdGg6DQoNCiAgICAvPHRva2VuPi92aWRlby9mb28vaW5kZXgubTN1 OA0KDQogIGFzIG9wcG9zZWQgdG8gcHV0dGluZyB0aGUgdG9rZW4gaW4gdGhlIHF1ZXJ5IHN0cmlu ZzoNCg0KICAgIC92aWRlby9mb28vaW5kZXgubTN1OD9VUklTaWduaW5nUGFja2FnZT08dG9rZW4+ DQoNCiAgPw0KDQogIE5vdGU6IEkgZG9uJ3Qga25vdyBpZiB0aGVyZSBpcyBhbnkgSVBSIG9uIHRo aXMsIGJ1dCBJIGRvIGtub3cgb2YgYSBwcm9kdWN0IHRoYXQgZG9lcyBpdC4NCg0KdGhhbnguDQoN Ci0tICBLZXZpbiBKLiBNYQ0KDQoNCkZyb206IENETmkgW21haWx0bzpjZG5pLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBQaGlsIFNvcmJlcg0KU2VudDogVGh1cnNkYXksIE1hcmNoIDE3 LCAyMDE2IDQ6MTIgUE0NClRvOiBjZG5pQGlldGYub3JnDQpTdWJqZWN0OiBbQ0ROaV0gVVJJIFNp Z25pbmcgUGF0aCBQYXJhbWV0ZXJzDQoNCkkgaGF2ZSBhIHVzZSBjYXNlIHdoZXJlIHBhdGggcGFy YW1ldGVycyAobWF0cml4IHBhcmFtZXRlcnMpIHdvdWxkIGJlIHZlcnkgdXNlZnVsIGZvciBVUkkg U2lnbmluZy4gSWYgd2UgaGF2ZSBhbiBITFMgbWFuaWZlc3Qgd2l0aCByZWxhdGl2ZSBVUkkncywg d2UgZG9uJ3QgaGF2ZSB0byBtb2RpZnkgaXQgdG8gYWRkIHF1ZXJ5IHBhcmFtcyBvciB1c2Ugb3Ro ZXIgdGVjaG5pcXVlcyB0aGF0IG1heSBoYXZlIElQUiBpc3N1ZXMuIFRoZSBVUkkgdG8gdGhlIG1h bmlmZXN0IGhhcyB0aGUgc2lnbmVkIHRva2VuIGluIGl0IGFzIGEgcGF0aCBwYXJhbWV0ZXIgYW5k IHRoZW4gdGhhdCBtZWFucyB0aGUgYmFzZSBVUkkgd2lsbCBoYXZlIGl0IGFsc28uDQoNClRob3Vn aHRzIG9uIGFkZGluZyB0aGlzPyBQZXJoYXBzIGFzIGEgc2VwYXJhdGUgUkZDPw0KDQpUaGFua3Mu DQo= --_000_A419F67F880AB2468214E154CB8A556206D2CC43eusaamb103erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsN Cgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2Ug V29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAx LjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0 PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N CjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+SGkgUGhpbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPiZuYnNwOyBKdXN0IHRvIG1ha2Ugc3VyZSBJIHVuZGVyc3RhbmQgY29ycmVj dGx5LCBhcmUgeW91IHN1Z2dlc3RpbmcgdGhhdCwgZ2l2ZW4gYSBVUkkgcGF0aDo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyAm bmJzcDsmbmJzcDsvdmlkZW8vZm9vL2luZGV4Lm0zdTg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyBVUkkgc2lnbmluZyBjb3Vs ZCwgZS5nLiwgcHJlcGVuZCB0aGUgdG9rZW4gdG8gdGhlIFVSSSBwYXRoOjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7IC8mbHQ7dG9rZW4mZ3Q7L3ZpZGVvL2Zvby9pbmRleC5tM3U4PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgYXMgb3Bw b3NlZCB0byBwdXR0aW5nIHRoZSB0b2tlbiBpbiB0aGUgcXVlcnkgc3RyaW5nOjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5i c3A7Jm5ic3A7IC92aWRlby9mb28vaW5kZXgubTN1OD9VUklTaWduaW5nUGFja2FnZT0mbHQ7dG9r ZW4mZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij4mbmJzcDsgPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7IE5vdGU6IEkgZG9uJ3Qga25vdyBpZiB0aGVyZSBpcyBh bnkgSVBSIG9uIHRoaXMsIGJ1dCBJIGRvIGtub3cgb2YgYSBwcm9kdWN0IHRoYXQgZG9lcyBpdC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PnRoYW54LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+LS0mbmJzcDsgS2V2aW4gSi4gTWE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7 cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAw aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IENETmkgW21haWx0 bzpjZG5pLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlBoaWwgU29yYmVy PGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBNYXJjaCAxNywgMjAxNiA0OjEyIFBNPGJyPg0K PGI+VG86PC9iPiBjZG5pQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFtDRE5pXSBVUkkg U2lnbmluZyBQYXRoIFBhcmFtZXRlcnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBoYXZlIGEgdXNlIGNhc2Ugd2hlcmUgcGF0aCBwYXJhbWV0 ZXJzIChtYXRyaXggcGFyYW1ldGVycykgd291bGQgYmUgdmVyeSB1c2VmdWwgZm9yIFVSSSBTaWdu aW5nLiBJZiB3ZSBoYXZlIGFuIEhMUyBtYW5pZmVzdCB3aXRoIHJlbGF0aXZlIFVSSSdzLCB3ZSBk b24ndCBoYXZlIHRvIG1vZGlmeSBpdCB0byBhZGQgcXVlcnkgcGFyYW1zIG9yIHVzZSBvdGhlciB0 ZWNobmlxdWVzIHRoYXQgbWF5IGhhdmUgSVBSIGlzc3Vlcy4NCiBUaGUgVVJJIHRvIHRoZSBtYW5p ZmVzdCBoYXMgdGhlIHNpZ25lZCB0b2tlbiBpbiBpdCBhcyBhIHBhdGggcGFyYW1ldGVyIGFuZCB0 aGVuIHRoYXQgbWVhbnMgdGhlIGJhc2UgVVJJIHdpbGwgaGF2ZSBpdCBhbHNvLjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhvdWdodHMgb24gYWRkaW5nIHRo aXM/IFBlcmhhcHMgYXMgYSBzZXBhcmF0ZSBSRkM/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_A419F67F880AB2468214E154CB8A556206D2CC43eusaamb103erics_-- From nobody Fri Mar 18 03:03:30 2016 Return-Path: X-Original-To: cdni@ietf.org Delivered-To: cdni@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CF4D412D700; Fri, 18 Mar 2016 03:03:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160318100326.8680.88076.idtracker@ietfa.amsl.com> Date: Fri, 18 Mar 2016 03:03:26 -0700 Archived-At: Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-logging-23.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 18 Mar 2016 10:03:27 -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 of the IETF. Title : CDNI Logging Interface Authors : Francois Le Faucheur Gilles Bertrand Iuniana Oprescu Roy Peterkofsky Filename : draft-ietf-cdni-logging-23.txt Pages : 58 Date : 2016-03-18 Abstract: This memo specifies the Logging interface between a downstream CDN (dCDN) and an upstream CDN (uCDN) that are interconnected as per the CDN Interconnection (CDNI) framework. First, it describes a reference model for CDNI logging. Then, it specifies the CDNI Logging File format and the actual protocol for exchange of CDNI Logging Files. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-logging/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-cdni-logging-23 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-logging-23 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 Mar 18 03:12:02 2016 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 8DD7B12D7C4 for ; Fri, 18 Mar 2016 03:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 rdJg4S2mjO9d for ; Fri, 18 Mar 2016 03:11:51 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (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 177A512D7B0 for ; Fri, 18 Mar 2016 03:11:51 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id l68so29812835wml.1 for ; Fri, 18 Mar 2016 03:11:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:date:references:to:message-id:mime-version; bh=VG8tUE7E2oonO0VakWjgpvD0A391KxADzjUUKFdwh3Q=; b=FxFlN1IOt/p8p/aJFyMmm+WaUZKlflq2GPIfYXUFGOabUVsBUFbb8oJCVjVSn/U4Jc VR/Dtc7XaeYd2lmUNIox+CS7ZJvACFiEZpkzD3MDmTWpqQAoRR/6Bd2m0h9Ok2ljAFsU zQQNmgwR3v9Ih72BuqapNCeYZIuDklEqttkWsH0GiS9Anht3eApbT4W7Uhito0rcQgqo uZTHHU3JgIzRPILRldCFmAkHMiPR7xYUGUGyWEima2XjvJzDOPmHLK9bf9sk9WSYA4u/ FC160bKesYGrGVKdzSpwkveObxg8rV0okqdBhIwd+M5MnagtjSiX/y+QtuseTXMusrCX fpig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:date:references:to:message-id :mime-version; bh=VG8tUE7E2oonO0VakWjgpvD0A391KxADzjUUKFdwh3Q=; b=EAV16gTALvGU+dCTgJDPaH9NulhqS2BuZ526t1sDPgvadu+exg90QlTAf+TLJ+CDgS YyUC7Q+DOJSEIXQyKvRk4CC9ZSaVuu79ceQeuUMFQCPA3tirLGAnL+StbCxgwYrVD8Bj KB8djCNNXh/Wh/ILfEKQlNArmUod38V9Mk18Bqv1uZvyHJklZQF0DaLaPiLQigF6ajIC fvVxtJFobHenQ5/usDUBxbY1xsz/edchAxchZaB7mcqE00qPGyoK0xjZnp07El6PwQU9 rkdCNcN83XkmPgbKMW6qcD9Fe4xp9RotAVA+JgIbgS32FWA1+haZ7s/sq5dv1UvzTMdt djkg== X-Gm-Message-State: AD7BkJLOBusq0HKhDtVLEXLsOXCbTCy55rUAnLMqwGbv/XVxBlAfyJBeT3TlPlEeFFKs3w== X-Received: by 10.194.184.234 with SMTP id ex10mr14398952wjc.8.1458295909611; Fri, 18 Mar 2016 03:11:49 -0700 (PDT) Received: from ams-flefauch-nitro11.cisco.com ([173.38.220.42]) by smtp.gmail.com with ESMTPSA id ux5sm11520357wjc.17.2016.03.18.03.11.48 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 18 Mar 2016 03:11:48 -0700 (PDT) From: Francois Le Faucheur Content-Type: multipart/alternative; boundary="Apple-Mail=_48EF3C49-B911-47CB-9EF2-10A6CAA16CCA" Date: Fri, 18 Mar 2016 11:11:49 +0100 References: <20160318100326.8680.88076.idtracker@ietfa.amsl.com> To: "" Message-Id: <965F5546-FBE5-4FE5-9045-DDB7382F3ADD@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Subject: [CDNi] Fwd: I-D Action: draft-ietf-cdni-logging-23.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 18 Mar 2016 10:11:59 -0000 --Apple-Mail=_48EF3C49-B911-47CB-9EF2-10A6CAA16CCA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello, (as a document editor) This new version of cdni-logging closes all the remaining open items. Changes over -22 are: * clarified text on a mapping approach for c-groupid identifying = individual clients * clarified statement that this method MAY be implemented (we = had tentatively agreed to make that approach MANDATORY-to-implement, but = given the strong guidance from ADs that we do not want to encourage = mapping identifying individual clients, we agreed to make that a MAY = implement). * added text to resolve comment from Kevin about what approach = to take for extending logging=20 Francois PS: Thanks to Kevin for his great help on editing this new version > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: I-D Action: draft-ietf-cdni-logging-23.txt > Date: 18 March 2016 11:03:26 CET > To: > Cc: cdni@ietf.org > Reply-To: internet-drafts@ietf.org >=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 of the IETF. >=20 > Title : CDNI Logging Interface > Authors : Francois Le Faucheur > Gilles Bertrand > Iuniana Oprescu > Roy Peterkofsky > Filename : draft-ietf-cdni-logging-23.txt > Pages : 58 > Date : 2016-03-18 >=20 > Abstract: > This memo specifies the Logging interface between a downstream CDN > (dCDN) and an upstream CDN (uCDN) that are interconnected as per the > CDN Interconnection (CDNI) framework. First, it describes a > reference model for CDNI logging. Then, it specifies the CDNI > Logging File format and the actual protocol for exchange of CDNI > Logging Files. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-cdni-logging/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-cdni-logging-23 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-logging-23 >=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 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --Apple-Mail=_48EF3C49-B911-47CB-9EF2-10A6CAA16CCA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hello,

(as = a document editor)

This new version of cdni-logging closes all the remaining = open items.

Changes over -22 are:
* = clarified text on a mapping approach for c-groupid identifying = individual clients
* clarified statement that this = method MAY be implemented (we had tentatively agreed to make that = approach MANDATORY-to-implement, but given the strong guidance from ADs = that we do not want to encourage mapping identifying individual clients, = we agreed to make that a MAY implement).
* added = text to resolve comment from Kevin about what approach to take for = extending logging 

Francois

PS: Thanks to Kevin for his great help on editing this new = version

Begin forwarded message:

From: = internet-drafts@ietf.org
Subject: = I-D Action: = draft-ietf-cdni-logging-23.txt
Date: = 18 March 2016 11:03:26 CET
To: = <i-d-announce@ietf.org>
Cc: cdni@ietf.org
Reply-To: = internet-drafts@ietf.org


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 = of the IETF.

=        Title =           : CDNI = Logging Interface
=        Authors =         : Francois Le = Faucheur
=             &n= bsp;           &nbs= p;Gilles Bertrand
=             &n= bsp;           &nbs= p;Iuniana Oprescu
=             &n= bsp;           &nbs= p;Roy Peterkofsky
Filename =        : = draft-ietf-cdni-logging-23.txt
Pages =           : 58
= Date =            : = 2016-03-18

Abstract:
=   This memo specifies the Logging interface between a = downstream CDN
  (dCDN) and an upstream CDN = (uCDN) that are interconnected as per the
  CDN = Interconnection (CDNI) framework.  First, it describes a
  reference model for CDNI logging.  Then, it = specifies the CDNI
  Logging File format and = the actual protocol for exchange of CDNI
=   Logging Files.


The= IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-cdni-logging/
There's also a htmlized version available = at:
https://tools.ietf.org/html/draft-ietf-cdni-logging-23

A diff from the previous version is available = at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-logging-23<= br class=3D"">

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/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: = http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt

= --Apple-Mail=_48EF3C49-B911-47CB-9EF2-10A6CAA16CCA-- From nobody Fri Mar 18 06:25:00 2016 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 1CE1412D56E; Fri, 18 Mar 2016 06:25:00 -0700 (PDT) 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 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 XixQznZiIUFX; Fri, 18 Mar 2016 06:24:57 -0700 (PDT) Received: from mailex.mailcore.me (smtp.123-reg.co.uk [94.136.40.63]) by ietfa.amsl.com (Postfix) with ESMTP id 7782412D51B; Fri, 18 Mar 2016 06:24:57 -0700 (PDT) Received: from 97e1f3b1.skybroadband.com ([151.225.243.177] helo=[192.168.0.4]) by smtp04.mailcore.me with esmtpa (Exim 4.80.1) (envelope-from ) id 1aguOe-000CjV-7t; Fri, 18 Mar 2016 13:24:56 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Ben Niven-Jenkins In-Reply-To: Date: Fri, 18 Mar 2016 13:24:54 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160317170445.26849.16234.idtracker@ietfa.amsl.com> To: Barry Leiba X-Mailer: Apple Mail (2.2098) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Archived-At: Cc: "" , draft-ietf-cdni-redirection@ietf.org Subject: Re: [CDNi] ID Tracker State Update Notice: X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 18 Mar 2016 13:25:00 -0000 Hi Barry, I=E2=80=99ve been snowed under this week so will reply to the IESG = comments early next week. Ben > On 17 Mar 2016, at 17:10, Barry Leiba wrote: >=20 >> IESG state changed to IESG Evaluation::AD Followup from IESG = Evaluation >> ID Tracker URL: = https://datatracker.ietf.org/doc/draft-ietf-cdni-redirection/ >=20 > What this means is that we're waiting for responses and discussion of > the IESG Evaluation comments, and I haven't seen that yet. Authors, > please respond to those and engage in the necessary discussion, and > please put a priority on that. >=20 > Thanks, > Barry, ART Director >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From nobody Fri Mar 18 07:25:52 2016 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 36DF912D901 for ; Fri, 18 Mar 2016 07:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001] 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 sHZsvtjgylgH for ; Fri, 18 Mar 2016 07:25:43 -0700 (PDT) Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by ietfa.amsl.com (Postfix) with SMTP id 9E80612D8F7 for ; Fri, 18 Mar 2016 07:25:42 -0700 (PDT) Received: (qmail 46358 invoked by uid 99); 18 Mar 2016 14:25:41 -0000 Received: from mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 18 Mar 2016 14:25:41 +0000 Received: from mail-ig0-f174.google.com (mail-ig0-f174.google.com [209.85.213.174]) by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with ESMTPSA id 4DA8A1A0182 for ; Fri, 18 Mar 2016 14:25:41 +0000 (UTC) Received: by mail-ig0-f174.google.com with SMTP id kc10so22702063igb.0 for ; Fri, 18 Mar 2016 07:25:41 -0700 (PDT) X-Gm-Message-State: AD7BkJKIUapm8RqYpm8iFQ66QXUN2x/q1f++RTo05FDs/vwLdE8Tj3PVTOQVFByOp/rxft27nYYlY/G6R4FXDQ== X-Received: by 10.50.61.234 with SMTP id t10mr46199224igr.20.1458311140704; Fri, 18 Mar 2016 07:25:40 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Phil Sorber Date: Fri, 18 Mar 2016 14:25:31 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Kevin Ma J , "cdni@ietf.org" Content-Type: multipart/alternative; boundary=047d7bdc07e283ee46052e538551 Archived-At: Subject: Re: [CDNi] URI Signing Path Parameters X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 18 Mar 2016 14:25:52 -0000 --047d7bdc07e283ee46052e538551 Content-Type: text/plain; charset=UTF-8 Yes, that sounds right. It doesn't have to be in the front though. In our effort to make this happen we put it at the end: /path/to//manifest.m3u8 Also, to technically be a path parameter I think it needs some syntactical glue, such as: /path/;URISigningPackage=/manifest.m3u8 Which could also be written as: /path;URISigningPackage=/manifest.m3u8 Also, sorry, I didn't mean to suggest I knew there was no IPR on it, I instead meant to contrast it with the 04 revision of the draft that has the HLS token exchange method that we had an IPR notice on and moved into it's own draft. That was also the reason I asked about a separate draft for this. You are correct, this method may also have IPR associated with it that I am unaware of, I was just being hopeful. Thanks. On Fri, Mar 18, 2016, 00:07 Kevin Ma J wrote: > Hi Phil, > > > > Just to make sure I understand correctly, are you suggesting that, given > a URI path: > > > > /video/foo/index.m3u8 > > > > URI signing could, e.g., prepend the token to the URI path: > > > > //video/foo/index.m3u8 > > > > as opposed to putting the token in the query string: > > > > /video/foo/index.m3u8?URISigningPackage= > > > > ? > > > > Note: I don't know if there is any IPR on this, but I do know of a > product that does it. > > > > thanx. > > > > -- Kevin J. Ma > > > > > > *From:* CDNi [mailto:cdni-bounces@ietf.org] *On Behalf Of *Phil Sorber > *Sent:* Thursday, March 17, 2016 4:12 PM > *To:* cdni@ietf.org > *Subject:* [CDNi] URI Signing Path Parameters > > > > I have a use case where path parameters (matrix parameters) would be very > useful for URI Signing. If we have an HLS manifest with relative URI's, we > don't have to modify it to add query params or use other techniques that > may have IPR issues. The URI to the manifest has the signed token in it as > a path parameter and then that means the base URI will have it also. > > > > Thoughts on adding this? Perhaps as a separate RFC? > > > > Thanks. > --047d7bdc07e283ee46052e538551 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Yes, that sounds right. It doesn't have to be = in the front though. In our effort to make this happen we put it at the end= :

/path/to/<token>/manifest.m3u8

Also, to technically b= e a path parameter I think it needs some syntactical glue, such as:

= /path/;URISigningPackage=3D<token>/manifest.m3u8

Which could a= lso be written as:

/path;URISigningPackage=3D<token>/manifest.= m3u8

Also, sorry, I didn't mean to suggest I knew there was no I= PR on it, I instead meant to contrast it with the 04 revision of the draft = that has the HLS token exchange method that we had an IPR notice on and mov= ed into it's own draft. That was also the reason I asked about a separa= te draft for this. You are correct, this method may also have IPR associate= d with it that I am unaware of, I was just being hopeful.

Thanks.

On Fri, M= ar 18, 2016, 00:07 Kevin Ma J <kevin.j.ma@ericsson.com> wrote:

Hi Phil,

=C2=A0

=C2=A0 Just to make sure I understand correctly, are you s= uggesting that, given a URI path:

=C2=A0

=C2=A0 =C2=A0=C2=A0/video/foo/index.m3u8

=C2=A0

=C2=A0 URI signing could, e.g., prepend the token to the U= RI path:

=C2=A0

=C2=A0=C2=A0=C2=A0 /<token>/video/foo/index.m3u8<= /u>

=C2=A0

=C2=A0 as opposed to putting the token in the query string= :

=C2=A0

=C2=A0=C2=A0=C2=A0 /video/foo/index.m3u8?URISigningPackage= =3D<token>

=C2=A0

=C2=A0 ?

=C2=A0

=C2=A0 Note: I don't know if there is any IPR on this,= but I do know of a product that does it.

=C2=A0

thanx.

=C2=A0

--=C2=A0 Kevin J. Ma

=C2=A0

=C2=A0

From: CDNi [ma= ilto:cdni-bounce= s@ietf.org] On Behalf Of Phil Sorber
Sent: Thursday, March 17, 2016 4:12 PM
To: cdni@ietf.org=
Subject: [CDNi] URI Signing Path Parameters

=

=C2=A0

I have a use case where path parameters (matrix para= meters) would be very useful for URI Signing. If we have an HLS manifest wi= th relative URI's, we don't have to modify it to add query params o= r use other techniques that may have IPR issues. The URI to the manifest has the signed token in it as a path parameter and= then that means the base URI will have it also.

=C2=A0

Thoughts on adding this? Perhaps as a separate RFC?<= u>

=C2=A0

Thanks.

--047d7bdc07e283ee46052e538551-- From nobody Fri Mar 18 07:41:36 2016 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 A910F12DB92 for ; Fri, 18 Mar 2016 07:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 ciSHMPaMZ3Hr for ; Fri, 18 Mar 2016 07:41:32 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB86112D8FB for ; Fri, 18 Mar 2016 07:40:09 -0700 (PDT) X-AuditID: c618062d-f79216d00000767f-fe-56ec0e000a0b Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id A4.71.30335.00E0CE65; Fri, 18 Mar 2016 15:17:36 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0248.002; Fri, 18 Mar 2016 10:40:08 -0400 From: Kevin Ma J To: Phil Sorber , "cdni@ietf.org" Thread-Topic: [CDNi] URI Signing Path Parameters Thread-Index: AQHRgIlHncwoVtRwsUKJZ1DRyVb9ZJ9etjPggADP1YD//8EhgA== Date: Fri, 18 Mar 2016 14:40:08 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: multipart/alternative; boundary="_000_A419F67F880AB2468214E154CB8A556206D2D398eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupikeLIzCtJLcpLzFFi42KZXLonXJeB702Ywe+XihZPZ/9htVhw9j67 A5PHj78NLB5LlvxkCmCK4rJJSc3JLEst0rdL4Mp4f2I9U8GZfsaKd/+vsDYwPuhm7GLk5JAQ MJHo/fIdyhaTuHBvPVsXIxeHkMARRokff/rYIZzljBJv2uexgVSxCWhJPP76lwnEFhFwkZhy fDkriC0soC+xeMIOdoi4gcTOj4uYIWwniY0314DFWQRUJdYfWwhWzyvgK3Hg9VFGiAW3GSVO r/gNdganQKDE/6bZYMsYgU76fmoN2DJmAXGJW0/mM0GcKiCxZM95ZghbVOLl43+sELaSxJzX 15gh6vMlVmxqZ4ZYJihxcuYTlgmMIrOQjJqFpGwWkrJZjBxAcU2J9bv0IUoUJaZ0P2SHsDUk WufMZUcWX8DIvoqRo7S4ICc33chgEyMwho5JsOnuYLw/3fMQowAHoxIPb8Hy12FCrIllxZW5 hxglOJiVRHjvCr4JE+JNSaysSi3Kjy8qzUktPsQozcGiJM67/u3lMCGB9MSS1OzU1ILUIpgs EwenVAPjRu+iWzXvbkQYzHf+9XV1uiPTfpPDT/xX1TE2Zy2/JttXPLG5svm/JGNH9v8DEyd/ MxKrLDfm1Kmw+Ny29Y5aY7uI7JmTi53Sn312v3lxy5GdDuJni6aemXjiYH3YtUuSHWw8CmfV lE4LX8pLuPpPo/4VV8zXuVdVDk/3nsZYcDhd9l7WgfYiJZbijERDLeai4kQAnrPNhp0CAAA= Archived-At: Subject: Re: [CDNi] URI Signing Path Parameters X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 18 Mar 2016 14:41:35 -0000 --_000_A419F67F880AB2468214E154CB8A556206D2D398eusaamb103erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 dW5kZXJzdG9vZC4gIHRoYW54Lg0KDQpGcm9tOiBQaGlsIFNvcmJlciBbbWFpbHRvOnNvcmJlckBh cGFjaGUub3JnXQ0KU2VudDogRnJpZGF5LCBNYXJjaCAxOCwgMjAxNiAxMDoyNiBBTQ0KVG86IEtl dmluIE1hIEo7IGNkbmlAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbQ0ROaV0gVVJJIFNpZ25pbmcg UGF0aCBQYXJhbWV0ZXJzDQoNCg0KDQpZZXMsIHRoYXQgc291bmRzIHJpZ2h0LiBJdCBkb2Vzbid0 IGhhdmUgdG8gYmUgaW4gdGhlIGZyb250IHRob3VnaC4gSW4gb3VyIGVmZm9ydCB0byBtYWtlIHRo aXMgaGFwcGVuIHdlIHB1dCBpdCBhdCB0aGUgZW5kOg0KDQovcGF0aC90by88dG9rZW4+L21hbmlm ZXN0Lm0zdTgNCg0KQWxzbywgdG8gdGVjaG5pY2FsbHkgYmUgYSBwYXRoIHBhcmFtZXRlciBJIHRo aW5rIGl0IG5lZWRzIHNvbWUgc3ludGFjdGljYWwgZ2x1ZSwgc3VjaCBhczoNCg0KL3BhdGgvO1VS SVNpZ25pbmdQYWNrYWdlPTx0b2tlbj4vbWFuaWZlc3QubTN1OA0KDQpXaGljaCBjb3VsZCBhbHNv IGJlIHdyaXR0ZW4gYXM6DQoNCi9wYXRoO1VSSVNpZ25pbmdQYWNrYWdlPTx0b2tlbj4vbWFuaWZl c3QubTN1OA0KDQpBbHNvLCBzb3JyeSwgSSBkaWRuJ3QgbWVhbiB0byBzdWdnZXN0IEkga25ldyB0 aGVyZSB3YXMgbm8gSVBSIG9uIGl0LCBJIGluc3RlYWQgbWVhbnQgdG8gY29udHJhc3QgaXQgd2l0 aCB0aGUgMDQgcmV2aXNpb24gb2YgdGhlIGRyYWZ0IHRoYXQgaGFzIHRoZSBITFMgdG9rZW4gZXhj aGFuZ2UgbWV0aG9kIHRoYXQgd2UgaGFkIGFuIElQUiBub3RpY2Ugb24gYW5kIG1vdmVkIGludG8g aXQncyBvd24gZHJhZnQuIFRoYXQgd2FzIGFsc28gdGhlIHJlYXNvbiBJIGFza2VkIGFib3V0IGEg c2VwYXJhdGUgZHJhZnQgZm9yIHRoaXMuIFlvdSBhcmUgY29ycmVjdCwgdGhpcyBtZXRob2QgbWF5 IGFsc28gaGF2ZSBJUFIgYXNzb2NpYXRlZCB3aXRoIGl0IHRoYXQgSSBhbSB1bmF3YXJlIG9mLCBJ IHdhcyBqdXN0IGJlaW5nIGhvcGVmdWwuDQoNClRoYW5rcy4NCg0KT24gRnJpLCBNYXIgMTgsIDIw MTYsIDAwOjA3IEtldmluIE1hIEogPGtldmluLmoubWFAZXJpY3Nzb24uY29tPG1haWx0bzprZXZp bi5qLm1hQGVyaWNzc29uLmNvbT4+IHdyb3RlOg0KSGkgUGhpbCwNCg0KICBKdXN0IHRvIG1ha2Ug c3VyZSBJIHVuZGVyc3RhbmQgY29ycmVjdGx5LCBhcmUgeW91IHN1Z2dlc3RpbmcgdGhhdCwgZ2l2 ZW4gYSBVUkkgcGF0aDoNCg0KICAgIC92aWRlby9mb28vaW5kZXgubTN1OA0KDQogIFVSSSBzaWdu aW5nIGNvdWxkLCBlLmcuLCBwcmVwZW5kIHRoZSB0b2tlbiB0byB0aGUgVVJJIHBhdGg6DQoNCiAg ICAvPHRva2VuPi92aWRlby9mb28vaW5kZXgubTN1OA0KDQogIGFzIG9wcG9zZWQgdG8gcHV0dGlu ZyB0aGUgdG9rZW4gaW4gdGhlIHF1ZXJ5IHN0cmluZzoNCg0KICAgIC92aWRlby9mb28vaW5kZXgu bTN1OD9VUklTaWduaW5nUGFja2FnZT08dG9rZW4+DQoNCiAgPw0KDQogIE5vdGU6IEkgZG9uJ3Qg a25vdyBpZiB0aGVyZSBpcyBhbnkgSVBSIG9uIHRoaXMsIGJ1dCBJIGRvIGtub3cgb2YgYSBwcm9k dWN0IHRoYXQgZG9lcyBpdC4NCg0KdGhhbnguDQoNCi0tICBLZXZpbiBKLiBNYQ0KDQoNCkZyb206 IENETmkgW21haWx0bzpjZG5pLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmNkbmktYm91bmNlc0Bp ZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBQaGlsIFNvcmJlcg0KU2VudDogVGh1cnNkYXksIE1hcmNo IDE3LCAyMDE2IDQ6MTIgUE0NClRvOiBjZG5pQGlldGYub3JnPG1haWx0bzpjZG5pQGlldGYub3Jn Pg0KU3ViamVjdDogW0NETmldIFVSSSBTaWduaW5nIFBhdGggUGFyYW1ldGVycw0KDQpJIGhhdmUg YSB1c2UgY2FzZSB3aGVyZSBwYXRoIHBhcmFtZXRlcnMgKG1hdHJpeCBwYXJhbWV0ZXJzKSB3b3Vs ZCBiZSB2ZXJ5IHVzZWZ1bCBmb3IgVVJJIFNpZ25pbmcuIElmIHdlIGhhdmUgYW4gSExTIG1hbmlm ZXN0IHdpdGggcmVsYXRpdmUgVVJJJ3MsIHdlIGRvbid0IGhhdmUgdG8gbW9kaWZ5IGl0IHRvIGFk ZCBxdWVyeSBwYXJhbXMgb3IgdXNlIG90aGVyIHRlY2huaXF1ZXMgdGhhdCBtYXkgaGF2ZSBJUFIg aXNzdWVzLiBUaGUgVVJJIHRvIHRoZSBtYW5pZmVzdCBoYXMgdGhlIHNpZ25lZCB0b2tlbiBpbiBp dCBhcyBhIHBhdGggcGFyYW1ldGVyIGFuZCB0aGVuIHRoYXQgbWVhbnMgdGhlIGJhc2UgVVJJIHdp bGwgaGF2ZSBpdCBhbHNvLg0KDQpUaG91Z2h0cyBvbiBhZGRpbmcgdGhpcz8gUGVyaGFwcyBhcyBh IHNlcGFyYXRlIFJGQz8NCg0KVGhhbmtzLg0K --_000_A419F67F880AB2468214E154CB8A556206D2D398eusaamb103erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6d2luZG93dGV4dDt9DQpz cGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIi Ow0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0 IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJ bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij51bmRlcnN0b29kLiZuYnNwOyB0aGFueC48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzoz LjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij4gUGhpbCBTb3JiZXIgW21haWx0bzpzb3JiZXJAYXBhY2hlLm9yZ10NCjxicj4NCjxiPlNlbnQ6 PC9iPiBGcmlkYXksIE1hcmNoIDE4LCAyMDE2IDEwOjI2IEFNPGJyPg0KPGI+VG86PC9iPiBLZXZp biBNYSBKOyBjZG5pQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbQ0ROaV0gVVJJ IFNpZ25pbmcgUGF0aCBQYXJhbWV0ZXJzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NClllcywgdGhhdCBzb3VuZHMgcmlnaHQu IEl0IGRvZXNuJ3QgaGF2ZSB0byBiZSBpbiB0aGUgZnJvbnQgdGhvdWdoLiBJbiBvdXIgZWZmb3J0 IHRvIG1ha2UgdGhpcyBoYXBwZW4gd2UgcHV0IGl0IGF0IHRoZSBlbmQ6PGJyPg0KPGJyPg0KL3Bh dGgvdG8vJmx0O3Rva2VuJmd0Oy9tYW5pZmVzdC5tM3U4PGJyPg0KPGJyPg0KQWxzbywgdG8gdGVj aG5pY2FsbHkgYmUgYSBwYXRoIHBhcmFtZXRlciBJIHRoaW5rIGl0IG5lZWRzIHNvbWUgc3ludGFj dGljYWwgZ2x1ZSwgc3VjaCBhczo8YnI+DQo8YnI+DQovcGF0aC87VVJJU2lnbmluZ1BhY2thZ2U9 Jmx0O3Rva2VuJmd0Oy9tYW5pZmVzdC5tM3U4PGJyPg0KPGJyPg0KV2hpY2ggY291bGQgYWxzbyBi ZSB3cml0dGVuIGFzOjxicj4NCjxicj4NCi9wYXRoO1VSSVNpZ25pbmdQYWNrYWdlPSZsdDt0b2tl biZndDsvbWFuaWZlc3QubTN1ODxicj4NCjxicj4NCkFsc28sIHNvcnJ5LCBJIGRpZG4ndCBtZWFu IHRvIHN1Z2dlc3QgSSBrbmV3IHRoZXJlIHdhcyBubyBJUFIgb24gaXQsIEkgaW5zdGVhZCBtZWFu dCB0byBjb250cmFzdCBpdCB3aXRoIHRoZSAwNCByZXZpc2lvbiBvZiB0aGUgZHJhZnQgdGhhdCBo YXMgdGhlIEhMUyB0b2tlbiBleGNoYW5nZSBtZXRob2QgdGhhdCB3ZSBoYWQgYW4gSVBSIG5vdGlj ZSBvbiBhbmQgbW92ZWQgaW50byBpdCdzIG93biBkcmFmdC4gVGhhdCB3YXMgYWxzbyB0aGUgcmVh c29uDQogSSBhc2tlZCBhYm91dCBhIHNlcGFyYXRlIGRyYWZ0IGZvciB0aGlzLiBZb3UgYXJlIGNv cnJlY3QsIHRoaXMgbWV0aG9kIG1heSBhbHNvIGhhdmUgSVBSIGFzc29jaWF0ZWQgd2l0aCBpdCB0 aGF0IEkgYW0gdW5hd2FyZSBvZiwgSSB3YXMganVzdCBiZWluZyBob3BlZnVsLjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzLjxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGcmksIE1hciAxOCwgMjAxNiwgMDA6 MDcgS2V2aW4gTWEgSiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmtldmluLmoubWFAZXJpY3Nzb24uY29t IiB0YXJnZXQ9Il9ibGFuayI+a2V2aW4uai5tYUBlcmljc3Nvbi5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDtt YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SGkgUGhpbCw8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgSnVzdCB0byBt YWtlIHN1cmUgSSB1bmRlcnN0YW5kIGNvcnJlY3RseSwgYXJlIHlvdSBzdWdnZXN0aW5nIHRoYXQs IGdpdmVuIGEgVVJJIHBhdGg6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7ICZuYnNwOyZuYnNwOy92aWRlby9mb28vaW5k ZXgubTN1ODwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPiZuYnNwOyBVUkkgc2lnbmluZyBjb3VsZCwgZS5nLiwgcHJlcGVuZCB0aGUg dG9rZW4gdG8gdGhlIFVSSSBwYXRoOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyAvJmx0O3Rva2Vu Jmd0Oy92aWRlby9mb28vaW5kZXgubTN1ODwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyBhcyBvcHBvc2VkIHRvIHB1dHRp bmcgdGhlIHRva2VuIGluIHRoZSBxdWVyeSBzdHJpbmc6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 IC92aWRlby9mb28vaW5kZXgubTN1OD9VUklTaWduaW5nUGFja2FnZT0mbHQ7dG9rZW4mZ3Q7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Jm5ic3A7ID88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgTm90ZTogSSBkb24ndCBrbm93IGlmIHRoZXJlIGlzIGFu eSBJUFIgb24gdGhpcywgYnV0IEkgZG8ga25vdyBvZiBhIHByb2R1Y3QgdGhhdCBkb2VzIGl0Ljwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPnRoYW54Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPi0tJm5ic3A7IEtldmluIEouIE1hPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg Ymx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBw dCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PiBDRE5pIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmNkbmktYm91bmNlc0BpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPmNkbmktYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2Yg PC9iPlBoaWwgU29yYmVyPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBNYXJjaCAxNywgMjAx NiA0OjEyIFBNPGJyPg0KPGI+VG86PC9iPiA8YSBocmVmPSJtYWlsdG86Y2RuaUBpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPmNkbmlAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFtD RE5pXSBVUkkgU2lnbmluZyBQYXRoIFBhcmFtZXRlcnM8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNC4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgaGF2ZSBhIHVzZSBjYXNl IHdoZXJlIHBhdGggcGFyYW1ldGVycyAobWF0cml4IHBhcmFtZXRlcnMpIHdvdWxkIGJlIHZlcnkg dXNlZnVsIGZvciBVUkkgU2lnbmluZy4gSWYgd2UgaGF2ZSBhbiBITFMgbWFuaWZlc3Qgd2l0aCBy ZWxhdGl2ZSBVUkkncywgd2UgZG9uJ3QgaGF2ZSB0byBtb2RpZnkgaXQgdG8gYWRkDQogcXVlcnkg cGFyYW1zIG9yIHVzZSBvdGhlciB0ZWNobmlxdWVzIHRoYXQgbWF5IGhhdmUgSVBSIGlzc3Vlcy4g VGhlIFVSSSB0byB0aGUgbWFuaWZlc3QgaGFzIHRoZSBzaWduZWQgdG9rZW4gaW4gaXQgYXMgYSBw YXRoIHBhcmFtZXRlciBhbmQgdGhlbiB0aGF0IG1lYW5zIHRoZSBiYXNlIFVSSSB3aWxsIGhhdmUg aXQgYWxzby48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5UaG91Z2h0cyBvbiBhZGRpbmcgdGhpcz8gUGVyaGFwcyBhcyBhIHNlcGFyYXRlIFJGQz88bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRo YW5rcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_A419F67F880AB2468214E154CB8A556206D2D398eusaamb103erics_-- From nobody Fri Mar 18 09:06:00 2016 Return-Path: X-Original-To: cdni@ietf.org Delivered-To: cdni@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EE99112D943; Fri, 18 Mar 2016 09:05:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160318160557.9788.76392.idtracker@ietfa.amsl.com> Date: Fri, 18 Mar 2016 09:05:57 -0700 Archived-At: Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-control-triggers-12.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 18 Mar 2016 16:05:58 -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 of the IETF. Title : CDNI Control Interface / Triggers Authors : Rob Murray Ben Niven-Jenkins Filename : draft-ietf-cdni-control-triggers-12.txt Pages : 44 Date : 2016-03-18 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: https://tools.ietf.org/html/draft-ietf-cdni-control-triggers-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-control-triggers-12 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 Mar 18 09:08:59 2016 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 7EBAE12D56F; Fri, 18 Mar 2016 09:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 HEvkuAkqtl0L; Fri, 18 Mar 2016 09:08:51 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 2C8F212D590; Fri, 18 Mar 2016 09:08:43 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 22C1643DE62A8; Fri, 18 Mar 2016 16:08:38 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u2IG8epC016560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 18 Mar 2016 16:08:41 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u2IG8NZj026753 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 18 Mar 2016 17:08:40 +0100 Received: from FR711WXCHMBA02.zeu.alcatel-lucent.com ([169.254.2.90]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Fri, 18 Mar 2016 17:08:30 +0100 From: "Murray, Rob (Nokia - GB)" To: Vincent Roca Thread-Topic: Secdir review of draft-ietf-cdni-control-triggers-11 Thread-Index: AQHRRwzfQRQykiwnh0mW9gDUEP6L557tC9uAgAENeoCAcaifgA== Date: Fri, 18 Mar 2016 16:08:29 +0000 Message-ID: <252883D7-E325-4B9A-A978-FEACE5B40143@alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.160212 x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="utf-8" Content-ID: <4F3156016E03884B91DD157704C7EC8C@exchange.lucent.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-cdni-control-triggers@tools.ietf.org" , "cdni@ietf.org" , IESG , "secdir@ietf.org" Subject: Re: [CDNi] Secdir review of draft-ietf-cdni-control-triggers-11 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 18 Mar 2016 16:08:53 -0000 SGkgVmluY2VudCBhbmQgYWxsLA0KDQpJJ3ZlIGp1c3QgcG9zdGVkIGEgIi0xMiIgb2YgdGhlIENE TkkgVHJpZ2dlcnMgZHJhZnQsIGhvcGVmdWxseSBhZGRyZXNzaW5nIHRoZXNlIGNvbW1lbnRzLiBS ZXNwb25zZXMgaW5saW5lIGJlbG93Lg0KDQpDaGVlcnMsDQpSb2IuDQoNCk9uIDA2LzAxLzIwMTYs IDA4OjI3LCAiVmluY2VudCBSb2NhIiA8dmluY2VudC5yb2NhQGlucmlhLmZyPiB3cm90ZToNCg0K PkhlbGxvIFJvYiwNCj4NCj4+IEhpIFZpbmNlbnQgLSBtYW55IHRoYW5rcyBmb3IgdGhlIHJldmll dywgcmVzcG9uc2VzIGlubGluZSBiZWxvd+KApg0KPg0KPllvdeKAmXJlIHdlbGNvbWUuDQo+DQo+ DQo+Pj4gVGhlcmUgYXJlIHNldmVyYWwgdG9waWNzIEnigJlkIGxpa2UgdG8gZGlzY3VzczoNCj4+ PiANCj4+PiAxLSBDb25jZXJuaW5nIHRoZSB1c2Ugb2YgVExTIHRvIGNhcnJ5IENJL1QgdHJhZmZp YywgSSBzZWUgaXQgaXMgbWFuZGF0b3J5DQo+Pj4gdG8gaW1wbGVtZW50LCBidXQgc3RpbGwgb3B0 aW9uYWwgdG8gdXNlICgxc3Qgc2VudGVuY2Ugb2YgU2VjdGlvbiA4LjEpLiBJcw0KPj4+IGl0IHN0 aWxsIHJlYXNvbmFibGUgaW4gY3VycmVudCBJbnRlcm5ldD8gQXQgYSBtaW5pbXVtIEkgd291bGQg ZXhwZWN0IGENCj4+PiDCqyBNVVNUIHN1cHBvcnQgwrsgLyDCqyBTSE9VTEQgdXNlIMK7Lg0KPj4g DQo+PiBTZWN0aW9uIDguMSBnb2VzIG9uIHRvIHNheSAuLi4NCj4+IA0KPj4gICBbIC4uLiBkZXNj cmlwdGlvbiBvZiBiZW5lZml0cyBvZiBIVFRQUyAuLi4gXQ0KPj4gDQo+PiAgIEluIGFuIGVudmly b25tZW50IHdoZXJlIGFueSBzdWNoIHByb3RlY3Rpb24gaXMgcmVxdWlyZWQsIG11dHVhbGx5DQo+ PiAgIGF1dGhlbnRpY2F0ZWQgZW5jcnlwdGVkIHRyYW5zcG9ydCBNVVNUIGJlIHVzZWQgdG8gZW5z dXJlDQo+PiAgIGNvbmZpZGVudGlhbGl0eSBvZiB0aGUgQ0kvVCBpbmZvcm1hdGlvbi4gVG8gdGhh dCBlbmQsIFRMUyBNVVNUIGJlDQo+PiAgIHVzZWQgYnkgQ0kvVCwgaW5jbHVkaW5nIGF1dGhlbnRp Y2F0aW9uIG9mIHRoZSByZW1vdGUgZW5kLg0KPj4gDQo+PiAuLi4gdGhlIEludGVybmV0IGlzIGNs ZWFybHkgYW4gZW52aXJvbm1lbnQgd2hlcmUgc3VjaCBwcm90ZWN0aW9uIGlzDQo+PiByZXF1aXJl ZCwgYW5kIGl0J2xsIG9mdGVuIGJlIHVzZWQgZm9yIHRoZXNlIGludGVyZmFjZXMgLSB3ZSBjb3Vs ZCBzdGF0ZQ0KPj4gdGhhdCBleHBsaWNpdGx5LCB3b3VsZCB0aGF0IGFkZHJlc3MgdGhlIGNvbmNl cm4/DQo+PiANCj4+IEJ1dCwgQ0kvVCBjb3VsZCBhbHNvIGJlIGRlcGxveWVkIHRvIHJ1biBvdmVy IGEgVlBOIG9yIHByaXZhdGUgbmV0d29yaw0KPj4gYmV0d2VlbiB0d28gaW50ZXJjb25uZWN0ZWQg Q0ROcywgaW4gc3VjaCBhbiBlbnZpcm9ubWVudCBIVFRQUyB0cmFuc3BvcnQNCj4+IHdvdWxkIG5v dCBoYXZlIHRoZSBzYW1lIGJlbmVmaXRzLg0KPg0KPlllcywgdGhhdOKAmXMgbXkgcG9pbnQuIFNh eSBleHBsaWNpdGx5IHRoYXQgSW50ZXJuZXQgaXMgYW4gZXhhbXBsZSBvZiBlbnZpcm9ubWVudCB3 aGVyZQ0KPnN1Y2ggYSBwcm90ZWN0aW9uIGlzIG1hbmRhdG9yeS4NCg0KSW4gIi0xMiIgSSd2ZSBh bGlnbmVkIHRoZSB0ZXh0IGFib3ZlIHdpdGggdGhlIHRleHQgdXNlZCBpbiB0aGUgY2RuaS1tZXRh ZGF0YSBkcmFmdDoNCg0KICBUTFMgTVVTVCBiZSB1c2VkIGJ5IHRoZSBzZXJ2ZXItc2lkZSAoZENE TikgYW5kIHRoZSBjbGllbnQtc2lkZSAodUNETikgb2YNCiAgdGhlIENJL1QgaW50ZXJmYWNlLCBp bmNsdWRpbmcgYXV0aGVudGljYXRpb24gb2YgdGhlIHJlbW90ZSBlbmQsIHVubGVzcw0KICBhbHRl cm5hdGUgbWV0aG9kcyBhcmUgdXNlZCBmb3IgZW5zdXJpbmcgdGhlIGNvbmZpZGVudGlhbGl0eSBv ZiB0aGUNCiAgaW5mb3JtYXRpb24gaW4gdGhlIENJL1QgaW50ZXJmYWNlIHJlcXVlc3RzIGFuZCBy ZXNwb25zZXMgKHN1Y2ggYXMgc2V0dGluZw0KICB1cCBhbiBJUHNlYyB0dW5uZWwgYmV0d2VlbiB0 aGUgdHdvIENETnMgb3IgdXNpbmcgYSBwaHlzaWNhbGx5IHNlY3VyZWQNCiAgaW50ZXJuYWwgbmV0 d29yayBiZXR3ZWVuIHR3byBDRE5zIHRoYXQgYXJlIG93bmVkIGJ5IHRoZSBzYW1lIGNvcnBvcmF0 ZQ0KICBlbnRpdHkpLg0KDQpJIHRoaW5rIHRoYXQgY292ZXJzIGl0IGJldHRlciAoPykuDQoNCg0K Pj4+IDItIFNlY3Rpb24gOC4xLCBwbGVhc2UgY2hlY2sgdGhlIHBhcmFncmFwaCDCqyBOb3RlIHRo YXQgaW4gYSDCqyBkaWFtb25kIMK7DQo+Pj4gY29uZmlndXJhdGlvbiBb4oCmXSDCuy4gVGhpcyBw YXJhZ3JhcGggaXMgcmF0aGVyIGNvbmZ1c2luZyB0byBtZS4gQ29uZnVzaW9uDQo+Pj4gY29tZXMg ZnJvbToNCj4+PiAtIHRoZSBsYWNrIG9mIGRlc2NyaXB0aW9uIG9mIHRoZSDCqyBkaWFtb25kIGNv bmZpZ3VyYXRpb24gwrsuIEkgdW5kZXJzdGFuZA0KPj4+IHRoZXJlIGlzIG9uZSBkQ0ROIG9uIHRv cCBhbmQgbXVsdGlwbGUgdUNETiBkaXJlY3RseSBjb25uZWN0ZWQgYmVsb3csIGFtIEkNCj4+PiBy aWdodD8NCj4+IA0KPj4gWWVzLCB0aGF0J3MgcmlnaHQuIFRoZSBkcmFmdCBzYXlzOg0KPj4gDQo+ PiAgIE5vdGUgdGhhdCBpbiBhICJkaWFtb25kIiBjb25maWd1cmF0aW9uLCB3aGVyZSBvbmUgdUNE TidzIGNvbnRlbnQgY2FuDQo+PiAgIGJlIGFjcXVpcmVkIHZpYSBtb3JlIHRoYW4gb25lIGRpcmVj dGx5LWNvbm5lY3RlZCB1Q0ROLA0KPj4gDQo+PiBXb3VsZCB0aGUgZm9sbG93aW5nIHJlYXJyYW5n ZW1lbnQgaGVscD8gLi4uDQo+PiANCj4+ICAgQSAiZGlhbW9uZCIgY29uZmlndXJhdGlvbiBpcyBv bmUgd2hlcmUgYSBkQ0ROIGNhbiBhY3F1aXJlIGEgdUNETidzDQo+PiAgIGNvbnRlbnQgdmlhIG1v cmUgdGhhbiBvbmUgZGlyZWN0bHktY29ubmVjdGVkIHVDRE4uIE5vdGUgdGhhdA0KPj4gICBpbiBh IGRpYW1vbmQgY29uZmlndXJhdGlvbiBb4oCmXQ0KPg0KPlllcywgSSBwcmVmZXIgdGhpcyB2ZXJz aW9uLiBIb3dldmVyLCBjYW4gdGhlIHNhbWUgwqsgdUNETuKAmXMgY29udGVudCDCuyBiZQ0KPmF2 YWlsYWJsZSBhdCBzZXZlcmFsIHVDRE5zIGluIHRoaXMgZGlhbW9uZCBjb25maWd1cmF0aW9uPyBT YWlkIGRpZmZlcmVudGx5LA0KPndoYXQgYWJvdXQgdGhlIGZvbGxvd2luZyB0ZXh0Og0KPg0KPglB IMKrIGRpYW1vbmQgwrsgY29uZmlndXJhdGlvbiBpcyBvbmUgd2hlcmUgYSBkQ0ROIGNhbiBhY3F1 aXJlIGEgZ2l2ZW4NCj4JY29udGVudCB2aWEgbW9yZSB0aGFuIG9uZSBkaXJlY3RseS1jb25uZWN0 ZWQgdUNETi4gTm90ZSB0aGF0IFvigKZdDQoNClllcywgbW9yZSB0aGFuIG9uZSB1Q0ROIHdpbGwg aGF2ZSB0aGUgc2FtZSBjb250ZW50IC0gYnV0IHRoZSBpbXBvcnRhbnQgcG9pbnQgaXMgdGhhdCB1 bHRpbWF0ZWx5IHRoZXkgd2lsbCBhbGwgaGF2ZSBhY3F1aXJlZCBpdCBmcm9tIHRoZSBzYW1lIHVD RE4sIGFuZCB0aGF0IHVDRE4gb3ducyB0aGUgbWV0YWRhdGEuDQoNCkkndmUgdHJpZWQgdG8gcHJv dmlkZSBhIGJldHRlciBpbnRyby9leHBsYW5hdGlvbiBpbiBuZXcgc2VjdGlvbiAyLjIuMSAiTXVs dGlwbGUgaW50ZXJjb25uZWN0ZWQgQ0ROcyIuIEhvcGVmdWxseSB0aGF0IG1ha2VzIGl0IGEgYml0 IGNsZWFyZXI/DQoNCg0KPj4+IC0gdGhlIG5vdGlvbiBvZiDCqyBjb250ZW50IGFjcXVpcmVkIGZy b20gYSB1Q0ROIMK7LiBJZiBJIHVuZGVyc3RhbmQgY29ycmVjdGx5LA0KPj4+IGl0IG1lYW5zIMKr IGNvbnRlbnQgdGhhdCBoYXMgYmVlbiBhY3F1aXJlZCBhZnRlciBhIHVDRE4gcmVxdWVzdCB0byBk byBzbyDCuy4NCj4+PiBJIGluaXRpYWxseSB0aG91Z2h0IHRoZXJlIHdlcmUgc29tZSBtaXN0YWtl cyBpbiB0aGUgdXNlIG9mIHVDRE4gLyBkQ0RO4oCmDQo+PiANCj4+IEEgZENETiB3aWxsIGFsd2F5 cyBhY3F1aXJlIGNvbnRlbnQgZnJvbSBhIHVDRE4gYmVjYXVzZSBpdCdzIGJlZW4gcmVxdWVzdGVk DQo+PiB0byBkbyBzbyAod2l0aG91dCBhIHJlcXVlc3QgaXQgd29uJ3Qga25vdyB0aGUgVVJMIGlu IHRoZSB1Q0ROKS4NCj4+IA0KPj4gVGhlIHJlcXVlc3QgY2FuIGJlIGZyb20gYW4gZW5kLWNsaWVu dCBvciBhIGZ1cnRoZXItZG93bnN0cmVhbSBDRE4sIGluIHdoaWNoDQo+PiBjYXNlIHRoZSBjb250 ZW50IHdpbGwgYmUgYWNxdWlyZWQgb24tZGVtYW5kLCBvciBpdCBjYW4gYmUgYSBDSS9UDQo+PiBw cmUtcG9zaXRpb25pbmcgcmVxdWVzdCBmcm9tIGEgdUNETi4NCj4+IA0KPj4gRG9lcyB0aGF0IGhl bHA/IEnigJltIG5vdCBzdXJlIHdoYXQgY2hhbmdlIG9yIGNsYXJpZmljYXRpb24geW91J3JlIGFz a2luZyBmb3IuDQo+DQo+Rm9yZ2V0IG15IGNvbW1lbnQsIEkgbWlzdW5kZXJzdG9vZCB0aGUgbm90 aW9uIG9mIHVDRE7igKYgSSBzaG91bGQgaGF2ZSByZWFkDQo+UkZDIDY3MDcgYmVmb3JlIQ0KPg0K Pg0KPj4+IDMtIFdpdGggdGhpcyDCqyBkaWFtb25kIGNvbmZpZ3VyYXRpb24gwrssIHNpbmNlIHNl dmVyYWwgdUNETiBjYW4gYWN0IHVwb24gdGhlDQo+Pj4gc2FtZSBjb250ZW50LCB3aGF0IGhhcHBl bnMgaWYgdGhleSBiZWhhdmUgaW4gYSBub24gY29vcmRpbmF0ZWQgbWFubmVyIChpLmUuLA0KPj4+ IGluIHRoZSBnZW5lcmFsIGNhc2UpPyBGb3IgaW5zdGFuY2UgbGV04oCZcyBpbWFnaW5lIG9uZSBv ZiB0aGVtIGFza3MgdGhlIGRDRE4NCj4+PiB0byBkZWxldGUgdGhlIGNvbnRlbnQgb3IgY2FuY2Vs IHRoZSBpbml0aWFsIGNvbW1hbmQuIFdoYXQgaGFwcGVucyBpZiBhbm90aGVyDQo+Pj4gdUNETiB0 aGVuIGFza3MgdGhlIGRDRE4gdG8gaW52YWxpZGF0ZSB0aGlzIGNvbnRlbnQsIHByb3ZpZGluZyB0 aGUgVVJMIG9mIHRoZQ0KPj4+IFRyaWdnZXIgU3RhdHVzIFJlc291cmNlIHdoaWNoIChpZiBJIHVu ZGVyc3RhbmQgY29ycmVjdGx5KSBpcyBubyBsb25nZXIgdmFsaWQ/DQo+Pj4gVGhpcyDCqyBkaWFt b25kIGNvbmZpZ3VyYXRpb24gwrsgY2FuIGJlIGEgbGl0dGxlIGJpdCB0cmlja3kgYW5kIG5vIGNs ZWFyDQo+Pj4gZ3VpZGVsaW5lIGlzIHByb3ZpZGVkIGluIHRoZSBkb2N1bWVudC4NCj4+IA0KPj4g QSB0cmlnZ2VyIHN0YXR1cyByZXNvdXJjZSBiZWxvbmdzIHRvIG9uZSB1Q0ROIGFuZCBjYW5ub3Qg YmUgYWNjZXNzZWQgb3INCj4+IG1hbmlwdWxhdGVkIGJ5IGFueSBvdGhlciBDRE4sIHNlY3Rpb24g MyBwYXJhIDMgc2F5czoNCj4+IA0KPj4gICBUcmlnZ2VyIFN0YXR1cyBSZXNvdXJjZXMgYmVsb25n aW5nIHRvIGEgdUNETiBNVVNUIE5PVA0KPj4gICBiZSB2aXNpYmxlIHRvIGFueSBvdGhlciBDRE4u IFRoZSBkQ0ROIGNvdWxkLCBmb3IgZXhhbXBsZSwgYWNoaWV2ZQ0KPj4gICB0aGlzIGJ5IG9mZmVy aW5nIGRpZmZlcmVudCBjb2xsZWN0aW9uIFVSTHMgdG8gZWFjaCB1Q0ROLCBhbmQvb3IgYnkNCj4+ ICAgZmlsdGVyaW5nIHRoZSByZXNwb25zZSBiYXNlZCBvbiB0aGUgdUNETiB3aXRoIHdoaWNoIHRo ZSBIVFRQIGNsaWVudA0KPj4gICBpcyBhc3NvY2lhdGVkLg0KPg0KPkkgc2Vl4oCmIEhvd2V2ZXIs IGlmIG11bHRpcGxlIHVDRE5zIGNhbiBhY3Qgb24gdGhlIHNhbWUgY29udGVudCAod2hhdCBpcyBz YWlkKSwNCj5ldmVuIGlmIGVhY2ggdUNETiB1c2VzIGEgZGlmZmVyZW50IFVSTCwgd2lsbCBzaW11 bHRhbmVvdXMgQ0kvVCBjb21tYW5kcyBmb3INCj50aGUgc2FtZSBjb250ZW50IGJlIG1hbmFnZWQg Y29ycmVjdGx5PyBUaGlzIGlzIG5vdCBzYWlkIGluIHNlY3Rpb24gMw0KPnBhcmFncmFwaCAzIGVp dGhlciBhbmQgdGhpcyBpcyBhIGtleSBwb2ludC4NCg0KU29ycnksIEknZCBtaXNzZWQgeW91ciBw b2ludC4NCg0KSW50ZXJhY3Rpb25zIGNhbiBiZSBpbmVmZmljaWVudCwgYnV0IGFyZSBvdGhlcndp c2UgaGFybWxlc3MgYmVjYXVzZSB0aGUgc3Ryb25nZXN0IG9mICJpbnZhbGlkYXRlIiBvciAicHVy Z2UiIHdpbGwgd2luLCBhbmQgY29udGVudCBjYW4gYWx3YXlzIGJlIHJlLWFjcXVpcmVkIGlmIGl0 J3Mgc3RpbGwgYXZhaWxhYmxlIGZyb20gYW55IHVDRE4uDQoNCkkndmUgZ2l2ZW4gc29tZSBleGFt cGxlcyBpbiBuZXcgc2VjdGlvbiAyLjIuMSAiTXVsdGlwbGUgaW50ZXJjb25uZWN0ZWQgQ0ROcyIs IGFuZCBhZGRlZCBhIHBvaW50ZXIgdG8gdGhhdCBmcm9tIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0 aW9ucyBzZWN0aW9uLg0KDQoNCj4+IENvbnRlbnQgYWx3YXlzIG9yaWdpbmF0ZXMgZnJvbSBvbmUg dUNETiwgYnV0IGluIGEgZGlhbW9uZCBjb25maWdyYXRpb24gdGhlcmUNCj4+IG1heSBiZSBtdWx0 aXBsZSByb3V0ZXMgKHZpYSBvdGhlciBDRE5zKSB0byBhIGdpdmVuIGRDRE4uDQo+PiANCj4+IFRo ZSBtb3N0IGNvbW1vbiBzY2VuYXJpbyBtYXkgd2VsbCBiZSB0aGF0IHRoZSB1Q0ROIHdpbGwgaW5p dGlhdGUgYWxsIG9mIHRoZQ0KPj4gQ0kvVCBjb21tYW5kcyByZWxhdGVkIHRvIGl0cyBjb250ZW50 LCBhbmQgdGhvc2UgY29tbWFuZHMgd2lsbCBzaW1wbHkgYmUNCj4+IGZvcndhcmRlZCBieSBpbnRl cm1lZGlhdGUgQ0ROcy4NCj4+IA0KPj4gQnV0LCB0aGVyZSdzIG5vdGhpbmcgdG8gc3RvcCBhbiBp bnRlcm1lZGlhdGUgQ0ROIGluaXRpYXRpbmcgb3IgbW9kaWZ5aW5nDQo+PiBDSS9UIGNvbW1hbmRz IC0gYW5kIHNvbWUgbW9kaWZpY2F0aW9ucyBvZiB0aGUgY29tbWFuZCB3aWxsIGJlIG5lY2Vzc2Fy eQ0KPj4gKGZvciBleGFtcGxlLCBtZXRhZGF0YSBVUkxzIHdpbGwgbmVlZCB0byBiZSBjaGFuZ2Vk KS4NCj4+IA0KPj4gQnkgYW5hbHlzaXMgb2YgbG9nIGZpbGVzIGl0IHdpbGwgcHJvYmFibHkgYmUg cG9zc2libGUgdG8gd29yayBvdXQgd2hpY2gNCj4+IHVDRE4gYW4gaW5kaXZpZHVhbCBjYWNoZSBp biB0aGUgZENETiBhY3F1aXJlZCBlYWNoIGNhY2hlZCByZXNvdXJjZSBmcm9tLg0KPj4gQnV0IHRo ZSBjYWNoZSBpcyBub3QgcmVxdWlyZWQgdG8ga2VlcCBhIGxpdmUgcmVjb3JkIG9mIHRoYXQsIGFu ZCBpdA0KPj4gcHJvYmFibHkgd29uJ3QuIEluIHRoYXQgY2FzZSwgd2hlbiBpdCByZWNlaXZlcyBh IENJL1QgY29tbWFuZCB0byBpbnZhbGlkYXRlDQo+PiBvciBwdXJnZSBjb250ZW50LCB0aGUgZENE TiBzaG91bGQgYXBwbHkgdGhhdCBjb21tYW5kIHRvIGFueSBjb250ZW50IGl0DQo+PiBtYXkgaGF2 ZSBhY3F1aXJlZCBmcm9tIHRoZSB1Q0ROIGl0IGdvdCB0aGUgQ0kvVCBjb21tYW5kIGZyb20uDQo+ PiANCj4+IFNvIHRoZXJlIGlzIHNjb3BlIGZvciBhIG1hbGljaW91cyBpbnRlcm1lZGlhdGUgQ0RO IHRvIGNhdXNlIGV4dHJhIHByb2Nlc3NpbmcNCj4+IGFuZCBhY3F1aXNpdGlvbiBieSBhIGRDRE4g KGFuZCB0aGF0J3MgbWVudGlvbmVkIGluIHNlY3Rpb24gOCkuIEJ1dCBhDQo+PiBtYWxpY2lvdXMg Q0ROIGlzIGxpa2VseSB0byBmaW5kIGl0c2VsZiByZW1vdmVkIGZyb20gdGhlIENETiBmZWRlcmF0 aW9uIGZhaXJseQ0KPj4gcXVpY2tseSAtIHRoZXJlIHdpbGwgbmVjZXNzYXJpbHkgYmUgYSBsZXZl bCBvZiB0cnVzdCBiZXR3ZWVuIGludGVyY29ubmVjdGVkDQo+PiBDRE5zLg0KPj4gDQo+PiBXb3Vs ZCBpdCBoZWxwIHRvIHNwZWxsIG91dCBzb21lIG9mIHRoYXQgaW4gdGhlIGRyYWZ0PyAoVGhlIHNh bWUgb3IgdmVyeQ0KPj4gc2ltaWxhciB0ZXh0IGhhcyBiZWVuIHVzZWQgaW4gc2V2ZXJhbCBvZiB0 aGUgQ0ROSSBkcmFmdHMuKQ0KPg0KPlllcywgdGhpcyBwYXJhZ3JhcGggaXMgd29ydGggYmVpbmcg ZGV0YWlsZWQgYSBsaXR0bGUgYml0Lg0KPg0KPkluIHlvdXIgZXhwbGFuYXRpb25zIHlvdSBtZW50 aW9uIGludGVybWVkaWF0ZSBDRE5zIHdoaWxlIG9yaWdpbmFsIHRleHQgb25seQ0KPm1lbnRpb25z IGRpcmVjdGx5IGNvbm5lY3RlZCB1Q0ROcy4gVGhlIG5vdGlvbiBvZiDCqyBpbnRlcm1lZGlhdGUg Q0ROIMK7IGlzDQo+b25seSBkaXNjdXNzZWQgaW4gc2VjdGlvbnMgMi4zIGFuZCA0LjguIFNpbmNl IG1hbGljaW91cyBpbnRlcm1lZGlhdGUgQ0ROcyBhcmUNCj5wYXJ0IG9mIGEgdmFsaWQgYXR0YWNr IG1vZGVsLCBpdCBpcyB3b3J0aCB0byBleHBsYWluIGl0IChvciBnaXZlIGEgcmVmZXJlbmNlIHRv IGFub3RoZXINCj5kb2N1bWVudCkuDQoNCldoZW4gYSBjb250ZW50IG93bmVyLCB0aGUgb3JpZ2lu LCBkZWxlZ2F0ZXMgZGVsaXZlcnkgdG8gYSBDRE4gaXQgaXMgdHJ1c3RpbmcgdGhhdCBDRE4gdG8g ZGVsaXZlciB0aGUgcmlnaHQgY29udGVudCBvbiBpdHMgYmVoYWxmLiBBIG1hbGljaW91cyBDRE4g Y291bGQgZGVsaXZlciBhbnl0aGluZyBpbnN0ZWFkLCBidXQgaXQgd291bGQgc29vbiBsb3NlIHRo ZSB0cnVzdCBvZiB0aGUgb3JpZ2luLg0KDQpDRE4taW50ZXJjb25uZWN0aW9uIHNpbXBseSBleHRl bmRzIHRoYXQgdHJ1c3QgdG8gdGhlIGZ1cnRoZXItZG93bnN0cmVhbSBDRE5zIGFjdGluZyBvbiBi ZWhhbGYgb2YgdGhlIG9yaWdpbmFsLg0KDQpTbyBlc3RhYmxpc2htZW50L2VuZm9yY2VtZW50IG9m IHRoZSB0cnVzdCByZWxhdGlvbnNoaXAgaXRzZWxmLCB0aGUgY29udHJhY3QgYmV0d2VlbiB0aGUg b3JpZ2luIGFuZCB0aGUgQ0ROLCBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiBDRE5JIGFuZCBpbiB0 aGUgbGFuZCBvZiBjb21tZXJjaWFsIGFncmVlbWVudHMuDQoNCkkndmUgYWRkZWQgYSBub3RlIG9u IHRoYXQgaW4gdGhlIGludHJvIHRvIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBzZWN0aW9u Lg0KDQoNCj4+PiA0LSBDb25jZXJuaW5nIHByaXZhY3kgYXNwZWN0cywgSSB3b3VsZCBiZSBtdWNo IG1vcmUgY2F1dGlvdXMgdGhhbiB0aGUgYXV0aG9ycy4NCj4+PiBGb3IgaW5zdGFuY2UsIEkgd291 bGRuJ3QgY2xhaW0gInRoZXJlIGFyZSBubyBwcml2YWN5IGNvbmNlcm5zIGZvciBFbmQgVXNlcnMi DQo+Pj4gYmVjYXVzZSB0aGUgQ0kvVCBwcm90b2NvbCBkb2VzIG5vdCBjYXJyeSBpbmZvcm1hdGlv biBhYm91dCBpbmRpdmlkdWFsIEVuZA0KPj4+IFVzZXJzIChzZWN0aW9uIDguMykuIFRoZSBkQ0RO IGtub3dzIHRoYXQgdGhlcmUgYXJlIHVzZXJzIGludGVyZXN0ZWQgKG9yIGF0DQo+Pj4gdGhlIG9w cG9zaXRlIG5vIHVzZXIgaW50ZXJlc3RlZCkgYnkgYSBjZXJ0YWluIGNvbnRlbnQgaW4gdGhlIHJl Z2lvbiBzZXJ2ZWQNCj4+PiBieSBhIHVDRE4uIFRoZXJlZm9yZSwgdGhlIHByb3RvY29sIG9ubHkg cHJvdmlkZXMgay1hbm9ueW1pdHksIHdoZXJlIGsgaXMgdGhlDQo+Pj4gbnVtYmVyIG9mIEVuZCBV c2VycyBpbiB0aGUgcmVnaW9uLiBEZXBlbmRpbmcgb24gdGhlIGNvbnRlbnQgc2Vuc2l0aXZpdHkg YW5kDQo+Pj4gayB2YWx1ZSwgdGhpcyBrLWFub255bWl0eSBtYXkgc3RpbGwgcmFpc2UgcHJpdmFj eSBpc3N1ZXMsIGV2ZW4gaWYgdGhlDQo+Pj4gaW5kaXZpZHVhbCBFbmQgVXNlciBhY3Rpdml0eSBs b2dzIGFyZSBub3QgYXZhaWxhYmxlIHRvIHRoZSBkQ0ROIChJIGFzc3VtZQ0KPj4+IFRMUyBpcyB1 c2VkIHRvIHByZXZlbnQgZWF2ZXNkcm9wcGluZ+KApikuDQo+PiANCj4+IEkgZG9uJ3QgdGhpbmsg dGhhdCBhbmFseXNpcyBpcyBjb3JyZWN0Li4uDQo+PiANCj4+IElycmVzcGVjdGl2ZSBvZiBDSS9U LCB0aGUgZENETiB3aWxsIGFsd2F5cyBrbm93IHdobydzIGFjY2Vzc2luZyB0aGUgY29udGVudCwN Cj4+IGNsaWVudHMgYXJlIG1ha2luZyB0aGVpciByZXF1ZXN0cyBkaXJlY3RseSB0byBpdC4NCj4+ IA0KPj4gVGhlIENJL1QgaW50ZXJmYWNlIGlzIG9ubHkgYSBzbWFsbCBwYXJ0IG9mIENETiBJbnRl cmNvbm5lY3Rpb24uIFRoZXJlIGFyZQ0KPj4gb3RoZXIgaW50ZXJmYWNlcyBmb3IgZGlzdHJpYnV0 aW9uIG9mIG1ldGFkYXRhLCByZXF1ZXN0IHJvdXRpbmcsIGFuZCByZXRyaWV2YWwNCj4+IG9mIGRD RE4gbG9nIGZpbGVzIGJ5IHRoZSB1Q0ROLg0KPj4gDQo+PiBTaWduaWZpY2FudCB3b3JrIHdlbnQg aW4gdG8gdGhlIENETkkgbG9nZ2luZyBpbnRlcmZhY2UgdG8gbWFrZSBpdCBwb3NzaWJsZQ0KPj4g dG8gYW5vbnltaXNlL2FnZ3JlZ2F0ZSBlbmQtY2xpZW50IGluZm9ybWF0aW9uIGJlZm9yZSBzaGFy aW5nIGl0IHdpdGggYQ0KPj4gdUNETiAtIGJ1dCB0aGF0J3Mgbm90IHJlbGV2YW50IHRvIHRoZSBD SS9UIGludGVyZmFjZSwgd2hpY2ggZG9lcyBub3QgY2FycnkNCj4+IGFueSBlbmQtdXNlciBzcGVj aWZpYyBpbmZvcm1hdGlvbi4NCj4+IA0KPj4gVGhlIENJL1QgaW50ZXJmYWNlIGRvZXMgbm90IGV4 cG9zZSBhbnkgZENETiBpbmZvcm1hdGlvbiBhYm91dCBlbmQtY2xpZW50cyB0bw0KPj4gdGhlIHVD RE4uDQo+DQo+TXkgY29tbWVudCBpcyBhbHNvIGNhdXNlZCBieSBteSBtaXN1bmRlcnN0YW5kaW5n IG9mIHVDRE4gaW4gdGhlIGFyY2hpdGVjdHVyZS4NCj5TbyB5ZXMsIEkgYWdyZWUgd2l0aCB5b3Ug dGhhdCB0aGVyZeKAmXMgbm8gcHJpdmFjeSBpc3N1ZSBoZXJlLg0KPg0KPkluIGFueSBjYXNlLCB0 aGFua3MgZm9yIHlvdXIgZGV0YWlsZWQgYW5zd2VyLiBBbmQgc29ycnkgZm9yIG15IG1pc3VuZGVy c3RhbmRpbmcNCj5vZiB0aGUgYXJjaGl0ZWN0dXJlLg0KPg0KPkNoZWVycywNCj4NCj4gICBWaW5j ZW50DQo= From nobody Fri Mar 18 09:11:11 2016 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 46F8B12D56F; Fri, 18 Mar 2016 09:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 o7nyB8pcx2Ce; Fri, 18 Mar 2016 09:10:58 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 6F6ED12D52C; Fri, 18 Mar 2016 09:10:58 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 4CA624AE7AA6E; Fri, 18 Mar 2016 16:10:53 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u2IGAugK019790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 18 Mar 2016 16:10:56 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u2IGAmmI031356 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 18 Mar 2016 17:10:55 +0100 Received: from FR711WXCHMBA02.zeu.alcatel-lucent.com ([169.254.2.90]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Fri, 18 Mar 2016 17:10:52 +0100 From: "Murray, Rob (Nokia - GB)" To: Alissa Cooper , The IESG Thread-Topic: [CDNi] Alissa Cooper's Discuss on draft-ietf-cdni-control-triggers-11: (with DISCUSS and COMMENT) Thread-Index: AQHRSLglGP/+TlTdFE6hmhQuZTszDJ9fv0YA Date: Fri, 18 Mar 2016 16:10:51 +0000 Message-ID: References: <20160106192622.3241.46321.idtracker@ietfa.amsl.com> In-Reply-To: <20160106192622.3241.46321.idtracker@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.160212 x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="utf-8" Content-ID: <50C9FF0864EA1F46B3DE9BE10A4BC6F0@exchange.lucent.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "cdni@ietf.org" , "draft-ietf-cdni-control-triggers@ietf.org" , "cdni-chairs@ietf.org" Subject: Re: [CDNi] Alissa Cooper's Discuss on draft-ietf-cdni-control-triggers-11: (with DISCUSS and COMMENT) X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 18 Mar 2016 16:11:06 -0000 SGkgQWxpc3NhIGFuZCBhbGwsDQoNCkkndmUganVzdCBwb3N0ZWQgYSAiLTEyIiBvZiB0aGUgQ0RO SSBUcmlnZ2VycyBkcmFmdCwgaG9wZWZ1bGx5IGFkZHJlc3NpbmcgdGhlc2UgaXNzdWVzLiBSZXNw b25zZXMgaW5saW5lIGJlbG93Lg0KDQpDaGVlcnMsDQpSb2IuDQoNClVSTDogICAgICAgICAgICBo dHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1jZG5pLWNvbnRy b2wtdHJpZ2dlcnMtMTIudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1jZG5pLWNvbnRyb2wtdHJpZ2dlcnMvDQpIdG1saXplZDog ICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY2RuaS1jb250cm9s LXRyaWdnZXJzLTEyDQpEaWZmOiAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlm Zj91cmwyPWRyYWZ0LWlldGYtY2RuaS1jb250cm9sLXRyaWdnZXJzLTEyDQoNCg0KDQoNCk9uIDA2 LzAxLzIwMTYsIDE5OjI2LCAiQ0ROaSBvbiBiZWhhbGYgb2YgQWxpc3NhIENvb3BlciIgPGNkbmkt Ym91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgYWxpc3NhQGNvb3BlcncuaW4+IHdyb3RlOg0K DQo+QWxpc3NhIENvb3BlciBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlv biBmb3INCj5kcmFmdC1pZXRmLWNkbmktY29udHJvbC10cmlnZ2Vycy0xMTogRGlzY3Vzcw0KPg0K PldoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5k IHJlcGx5IHRvIGFsbA0KPmVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIEND IGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlzDQo+aW50cm9kdWN0b3J5IHBhcmFncmFwaCwg aG93ZXZlci4pDQo+DQo+DQo+UGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYub3JnL2ll c2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0KPmZvciBtb3JlIGluZm9ybWF0aW9u IGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQo+DQo+DQo+VGhlIGRv Y3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBo ZXJlOg0KPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtY2RuaS1j b250cm9sLXRyaWdnZXJzLw0KPg0KPg0KPg0KPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj5ESVNDVVNTOg0KPi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCj4NCj49IFNlY3Rpb24gNS4xLjggPQ0KPg0KPk5hbWU6IHN0YWxlcmVzb3Vy Y2V0aW1lDQo+DQo+ICAgICAgICAgRGVzY3JpcHRpb246IFRoZSBsZW5ndGggb2YgdGltZSBmb3Ig d2hpY2ggdGhlIGRDRE4gZ3VhcmFudGVlcw0KPiAgICAgICAgIHRvIGtlZXAgYSBjb21wbGV0ZWQg VHJpZ2dlciBTdGF0dXMgUmVzb3VyY2UuICBBZnRlciB0aGlzIHRpbWUsDQo+ICAgICAgICAgdGhl IGRDRE4gU0hPVUxEIGRlbGV0ZSB0aGUgVHJpZ2dlciBTdGF0dXMgUmVzb3VyY2UgYW5kIGFsbA0K PiAgICAgICAgIHJlZmVyZW5jZXMgdG8gaXQgZnJvbSBjb2xsZWN0aW9ucy4NCj4NCj5JJ20gbm90 IGNsZWFyIG9uIHdoeSB0aGlzIGlzIGEgU0hPVUxEIHJhdGhlciB0aGFuIGEgTVVTVC4gSWYgdGhl IGRDRE4NCj50ZWxscyB0aGUgdUNETiBpdCdzIGdvaW5nIHRvIGRlbGV0ZSByZXNvdXJjZXMgYWZ0 ZXIgYSBzcGVjaWZpZWQgcGVyaW9kIG9mDQo+dGltZSwgd2h5IHNob3VsZG4ndCBpdCBmb2xsb3cg dGhyb3VnaCBvbiB0aGF0PyBGb3IgYSB1Q0ROIHRoYXQgcmVsaWVzIG9uDQo+cmVzb3VyY2VzIG5v dCBzdGlja2luZyBhcm91bmQgYWZ0ZXIgYSBzcGVjaWZpZWQgcGVyaW9kIG9mIHRpbWUgKGJlY2F1 c2UNCj5vZiBzZWN1cml0eSBvciBjb21wZXRpdGl2ZSBjb25jZXJucyksIGRvZXNuJ3QgdGhpcyBu ZWVkIHRvIGJlIGEgZmlybQ0KPnJlcXVpcmVtZW50IHNvIHRoYXQgdGhlIHVDRE4gZG9lc24ndCBo YXZlIHRvIGlzc3VlIHB1cmdlIHJlcXVlc3RzIHRvIGJlDQo+c3VyZSB0aGF0IGl0cyByZXNvdXJj ZXMgZ2V0IGRlbGV0ZWQ/DQoNCkkgZG9uJ3QgdGhpbmsgdGhlcmUgYXJlIGFueSBzZWN1cml0eSBv ciBjb21wZXRpdGl2ZSBjb25jZXJucywgYSB1Q0ROJ3MgQ0kvVCBkYXRhIGlzIG9ubHkgdmlzaWJs ZSB0byB0aGF0IHVDRE4gKHRoYXQncyBhIE1VU1QgaW4gc2VjdGlvbnMgMyBhbmQgOC4zKS4NCg0K VGhlcmUncyBubyBpbnRlci1vcCByZWFzb24gdG8gaG9sZCB0aGUgZENETiB0byBhbnkgc3RyaWN0 IGNvbW1pdG1lbnQgb24gdGhlIHRpbWluZyAuLi4gZm9yIGV4YW1wbGUsIGZvciBzaW1wbGljaXR5 LCBhIGRDRE4gaW1wbGVtZW50YXRpb24gbWlnaHQgYWx3YXlzIGFkdmVydGlzZSBhICJzdGFsZXJl c291cmNldGltZSIgb2YgMjQgaG91cnMgYnV0IG9ubHkgYWN0dWFsbHkgZG8gdGhlIHRpZHktdXAg b25jZSBhIGRheSwgcmVtb3ZpbmcgYW55dGhpbmcgdGhhdCdzIG92ZXIgMS1kYXkgb2xkLg0KDQpT byBTSE9VTEQgc2VlbWVkIGxpa2UgdGhlIHJpZ2h0IHRoaW5nIGhlcmUsIGludGVyLW9wIHdvbid0 IGJlIGFmZmVjdGVkIGV2ZW4gaWYgdGhlIGRDRE4gZm9yZ2V0cyB0byBzY2hlZHVsZSBpdHMgZGVs ZXRlIGZvciBhIHdlZWsuDQoNCklmIHRoZSB1Q0ROIGlzIGdldHRpbmcgYW5ub3llZCB3aXRoIHRo ZSBjbHV0dGVyIGl0IGNhbiBleHBsaWNpdGx5IGRlbGV0ZSBDSS9UIHJlc291cmNlcyBpdHMgbm90 IGludGVyZXN0ZWQgaW4gKG5vdGUgaXQncyBhbiAiSFRUUCBERUxFVEUiIG5vdCBhICJDSS9UIHB1 cmdlIiwgdGhpcyBpcyBqdXN0IGFib3V0IHRoZSBDSS9UIHRyYWNraW5nIGRhdGEsIG5vdCB0aGUg Y29udGVudCBvciBtZXRhZGF0YSBpbiB0aGUgQ0ROKS4NCg0KSSd2ZSBub3QgdXBkYXRlZCB0aGUg d29yZGluZyBpbiAiLTEyIiwgYnV0IGhhcHB5IHRvIG1ha2UgY2hhbmdlcyBpZiB0aGVyZSdzIHN0 aWxsIGFuIGlzc3VlLg0KDQoNCj49IFNlY3Rpb24gOC4xID0NCj4NCj5JIGhhZCB0aGUgc2FtZSBj b25mdXNpb24gYXMgQmVuIGFuZCB0aGUgc2VjZGlyIHJldmlld2VyIGNvbmNlcm5pbmcNCj53aGV0 aGVyIFRMUyBpcyBhbHdheXMgcmVxdWlyZWQgdG8gdXNlIG9yIG5vdC4gSWYgdGhlcmUgYXJlIGNh c2VzIGluIHdoaWNoDQo+VExTIGlzIG5vdCBtYW5kYXRvcnkgdG8gdXNlLCB0aGVuIEkgdGhpbmsg dGhpcyBzaG91bGQgYmUgcGhyYXNlZCBhcyBhDQo+U0hPVUxEIHdpdGggdGhlIGV4Y2VwdGlvbnMg Y2xlYXJseSBlbnVtZXJhdGVkLiBGb3IgZXhhbXBsZSwgaXQncyBub3QNCj5jbGVhciB0byBtZSB3 aGV0aGVyIHRoZSBvbmx5IGV4Y2VwdGlvbiBpcyBlbnZpcm9ubWVudHMgd2hlcmUgZXF1aXZhbGVu dA0KPnByb3RlY3Rpb25zIGFyZSBhZmZvcmRlZCBieSBhIGRpZmZlcmVudCBwcm90b2NvbCwgb3Ig aWYganVzdCBiZWluZyB3aXRoaW4NCj5hIHNpbmdsZSBhZG1pbmlzdHJhdGl2ZSBkb21haW4gaXMg Y29uc2lkZXJlZCBwcm90ZWN0aW9uIGVub3VnaCAobm90IHN1cmUNCj5JIGFncmVlIHdpdGggdGhl IGxhdHRlcikuDQoNCkkndmUgdXBkYXRlZCB0aGF0IHRleHQgdG8gYWxpZ24gd2l0aCB0aGUgb3Ro ZXIgQ0ROSSBkb2NzIHdoZXJlIHRoZSBzYW1lIGRpc2N1c3Npb24gaGFzIGJlZW4gaGFkLg0KDQoN Cj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQo+Q09NTUVOVDoNCj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+DQo+PSBHZW5lcmFs ID0NCj4NCj5JIHRoaW5rIHRoZSBleGFtcGxlcyBpbiB0aGUgZG9jdW1lbnQgc2hvdWxkIHVzZSBo dHRwcyBVUklzLg0KDQpJdCdzIGEgZmFpciBjb3AhIERvbmUuDQoNCg0KPj0gU2VjdGlvbiAzID0N Cj4iVHJpZ2dlciBTdGF0dXMgUmVzb3VyY2VzIGJlbG9uZ2luZyB0byBhIHVDRE4gTVVTVCBOT1QN Cj4gICBiZSB2aXNpYmxlIHRvIGFueSBvdGhlciBDRE4uICBUaGUgZENETiBjb3VsZCwgZm9yIGV4 YW1wbGUsIGFjaGlldmUNCj4gICB0aGlzIGJ5IG9mZmVyaW5nIGRpZmZlcmVudCBjb2xsZWN0aW9u IFVSTHMgdG8gZWFjaCB1Q0ROLCBhbmQvb3IgYnkNCj4gICBmaWx0ZXJpbmcgdGhlIHJlc3BvbnNl IGJhc2VkIG9uIHRoZSB1Q0ROIHdpdGggd2hpY2ggdGhlIEhUVFAgY2xpZW50DQo+ICAgaXMgYXNz b2NpYXRlZC4iDQo+DQo+VXNpbmcgZGlmZmVyZW50IFVSTHMgZm9yIGRpZmZlcmVudCB1Q0ROcyBp cyBub3Qgc3VmZmljaWVudCBmb3IgdGhpcywNCj5jb3JyZWN0PyBJIHRoaW5rIHRoZSAiYW5kL29y IiBuZWVkcyB0byBiZSBqdXN0ICJhbmQiLg0KDQpPaywgZG9uZS4NCg0KDQo+PSBTZWN0aW9uIDQu MSA9DQo+SSBkb24ndCB1bmRlcnN0YW5kIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gd2hlbiBzdGF0 dXMgaXMgdXNlZCBpbiBxdW90ZXMNCj5hbmQgbm90IGluIHF1b3RlcywgZS5nLiwgJ09uY2UgcHJv Y2Vzc2luZyBoYXMgc3RhcnRlZCB0aGUgInN0YXR1cyIgTVVTVA0KPmJlICJhY3RpdmUiJyB2cy4g J29uY2UgdGhlIENJL1QgQ29tbWFuZCBpcyBjb21wbGV0ZSwgdGhlIHN0YXR1cyBNVVNUIGJlDQo+ c2V0IHRvICJjb21wbGV0ZSIgb3IgImZhaWxlZCInLg0KDQpUaGVyZSBpc24ndCBvbmUsIGxvb2tz IGxpa2UgSSBqdXN0IGdvdCBhIGJpdCBjYXJyaWVkIGF3YXkgd2l0aCB0aGUgcXVvdGUgYnV0dG9u LiBUaWRpZWQgdXAgbm93IEkgdGhpbmsuDQoNCg0KPj0gU2VjdGlvbiA0LjMgPQ0KPnMvcmVxdWly ZXMgbm8gcHJvY2Vzc2luZyBpbiB0aGUgZENETiwgaXRzIHN0YXR1cyBNVVNUIE5PVCBiZQ0KPmNo YW5nZWQvcmVxdWlyZXMgbm8gcHJvY2Vzc2luZyBpbiB0aGUgZENETi4gSXRzIHN0YXR1cyBNVVNU IE5PVCBiZQ0KPmNoYW5nZWQvDQoNCkRvbmUuDQoNCg0KPj0gU2VjdGlvbiA1LjEuMSA9DQo+DQo+ Ik5hbWU6IGNkbi1wYXRoDQo+DQo+ICAgICAgICAgRGVzY3JpcHRpb246IFRoZSBDRE4gUHJvdmlk ZXIgSWRlbnRpZmllcnMgb2YgQ0ROcyB0aGF0IGhhdmUNCj4gICAgICAgICBhbHJlYWR5IGFjY2Vw dGVkIHRoZSBDSS9UIENvbW1hbmQuIg0KPiAgICAgICAgDQo+SSBmaW5kIHRoZSBwaHJhc2UgImFs cmVhZHkgYWNjZXB0ZWQiIHNvbWV3aGF0IGNvbmZ1c2luZywgc2luY2UgYSB1Q0ROIGlzDQo+c3Vw cG9zZWQgdG8gaW5zZXJ0IGl0cyBvd24gb24gSUQgaGVyZSwgYW5kIGluIHRoYXQgc2Vuc2UgaGFz bid0DQo+ImFjY2VwdGVkIiBhbnl0aGluZywgYnV0IGlzIG1ha2luZyB0aGUgcmVxdWVzdCBpdHNl bGYuDQoNCkNoYW5nZWQgdG8gIi4uLiB0aGF0IGhhdmUgYWxyZWFkeSBpc3N1ZWQgdGhlIENJL1Qg Q29tbWFuZCB0byB0aGVpciBkQ0ROcyIuDQoNCg0KPg0KPj0gU2VjdGlvbiA4LjMgPQ0KPnMvcGFy dGllcyBvdGhlciBwYXJ0eSB0aGFuIHRoZSBhdXRob3Jpc2VkIGRDRE4vcGFydGllcyBvdGhlciB0 aGFuIHRoZQ0KPmF1dGhvcmlzZWQgZENETi8NCg0KRG9uZS4NCg0KPg0KPg0KPl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Q0ROaSBtYWlsaW5nIGxpc3QN Cj5DRE5pQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9j ZG5pDQo= From nobody Fri Mar 18 09:12:15 2016 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 34D5C12D997; Fri, 18 Mar 2016 09:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 vtArAMUAeX8F; Fri, 18 Mar 2016 09:12:08 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 4CDD812DABB; Fri, 18 Mar 2016 09:11:36 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 38F5F5904D611; Fri, 18 Mar 2016 16:11:31 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u2IGBYeR020720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 18 Mar 2016 16:11:34 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u2IGBVXQ000602 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 18 Mar 2016 17:11:33 +0100 Received: from FR711WXCHMBA02.zeu.alcatel-lucent.com ([169.254.2.90]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Fri, 18 Mar 2016 17:11:32 +0100 From: "Murray, Rob (Nokia - GB)" To: Stephen Farrell Thread-Topic: Stephen Farrell's No Objection on draft-ietf-cdni-control-triggers-11: (with COMMENT) Thread-Index: AQHRSVLvvJnf49cQdkOlPG1UnBH2r59fvkGA Date: Fri, 18 Mar 2016 16:11:32 +0000 Message-ID: <48F52309-DDB7-466E-8D1C-1CB0CD1C6BBB@alcatel-lucent.com> References: <20160107135418.28288.79368.idtracker@ietfa.amsl.com> In-Reply-To: <20160107135418.28288.79368.idtracker@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.160212 x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "cdni@ietf.org" , The IESG , "draft-ietf-cdni-control-triggers@ietf.org" , "cdni-chairs@ietf.org" Subject: Re: [CDNi] Stephen Farrell's No Objection on draft-ietf-cdni-control-triggers-11: (with COMMENT) X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 18 Mar 2016 16:12:10 -0000 SGkgU3RlcGhlbiBhbmQgYWxsLA0KDQpJJ3ZlIGp1c3QgcG9zdGVkIGEgIi0xMiIgb2YgdGhlIENE TkkgVHJpZ2dlcnMgZHJhZnQsIGhvcGVmdWxseSBhZGRyZXNzaW5nIHRoZXNlIGlzc3Vlcy4gUmVz cG9uc2VzIGlubGluZSBiZWxvdy4NCg0KQ2hlZXJzLA0KUm9iLg0KDQpVUkw6ICAgICAgICAgICAg aHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtY2RuaS1jb250 cm9sLXRyaWdnZXJzLTEyLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtY2RuaS1jb250cm9sLXRyaWdnZXJzLw0KSHRtbGl6ZWQ6 ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWNkbmktY29udHJv bC10cmlnZ2Vycy0xMg0KRGlmZjogICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2Rp ZmY/dXJsMj1kcmFmdC1pZXRmLWNkbmktY29udHJvbC10cmlnZ2Vycy0xMg0KDQoNCg0KDQpPbiAw Ny8wMS8yMDE2LCAxMzo1NCwgIlN0ZXBoZW4gRmFycmVsbCIgPHN0ZXBoZW4uZmFycmVsbEBjcy50 Y2QuaWU+IHdyb3RlOg0KDQo+U3RlcGhlbiBGYXJyZWxsIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dp bmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KPmRyYWZ0LWlldGYtY2RuaS1jb250cm9sLXRyaWdnZXJz LTExOiBObyBPYmplY3Rpb24NCj4NCj5XaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBz dWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0byBhbGwNCj5lbWFpbCBhZGRyZXNzZXMgaW5j bHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgdGhpcw0KPmlu dHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KPg0KPg0KPlBsZWFzZSByZWZlciB0byBo dHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwN Cj5mb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9z aXRpb25zLg0KPg0KPg0KPlRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9z aXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZToNCj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1pZXRmLWNkbmktY29udHJvbC10cmlnZ2Vycy8NCj4NCj4NCj4NCj4tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQo+Q09NTUVOVDoNCj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+DQo+DQo+LSBJIGFncmVlIHdpdGgg dGhlIGRpc2N1c3MgcG9pbnRzIGFib3V0IHVzZSBvZiBUTFMuDQoNCkkndmUgZXhwYW5kZWQgb24g d2hlbiBUTFMgaXMgYSBNVVNULCBpbiBsaW5lIHdpdGggdGhlIGNkbmkgbWV0YWRhdGEgYW5kIGxv Z2dpbmcgZHJhZnRzLg0KDQo+LSBJIHRoaW5rIGl0J2QgYmUgYmV0dGVyIGlmIHlvdSBjbGFyaWZp ZWQgdGhhdCBieQ0KPiJtdXR1YWxseSBhdXRoZW50aWNhdGVkIiB5b3UgbWVhbiBUTFMgY2xpZW50 IGF1dGggYW5kDQo+VExTIHNlcnZlciBhdXRoIGFuZCBub3QgZS5nLiBIVFRQIEJBU0lDIHBsdXMg VExTIHNlcnZlcg0KPmF1dGguDQoNCkFkZGVkIHRoYXQgaXQncyBUTFMgYXV0aCB0byB0aGUgZmly c3QgYnVsbGV0IGluIHNlY3Rpb24gOC4xLg0KDQo+LSBJIHRoaW5rIGEgc3RhdGVtZW50IHRvIHRo ZSBlZmZlY3QgdGhhdCB0aGUgbWVjaGFuaXNtcw0KPmZvciBhY2Nlc3MgY29udHJvbCBhcmUgZENE Ti1zcGVjaWZpYyAoZm9yIG5vdyBhdCBsZWFzdCkNCj5taWdodCBiZSBhIGdvb2QgYWRkaXRpb24u IEknbSBndWVzc2luZyB0aGF0IHNvbWVvbmUNCj5taWdodCB3YW50IHRvIHVzZSBzb21lIGZvcm0g b2YgT0F1dGggbGF0ZXIgb24gKG9yIGlzDQo+ZG9pbmcgc28gbm93KSBzbyBwYXJ0KHMpIG9mIHRo YXQgbWlnaHQgYmUgYSB0aGluZyB0bw0KPnN0YW5kYXJkaXNlIGxhdGVyLg0KDQpBZGRlZCBhIG5v dGUgaW4gc2VjdGlvbiA4LjEuDQoNCg0K From nobody Fri Mar 18 09:21:41 2016 Return-Path: X-Original-To: cdni@ietf.org Delivered-To: cdni@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B68112DAB3; Fri, 18 Mar 2016 09:21:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Barry Leiba" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160318162138.28437.46557.idtracker@ietfa.amsl.com> Date: Fri, 18 Mar 2016 09:21:38 -0700 Archived-At: Cc: draft-ietf-cdni-logging@ietf.org, cdni@ietf.org, cdni-chairs@ietf.org Subject: [CDNi] Barry Leiba's Yes on draft-ietf-cdni-logging-23: (with COMMENT) X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 18 Mar 2016 16:21:39 -0000 Barry Leiba has entered the following ballot position for draft-ietf-cdni-logging-23: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cdni-logging/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The ABNF issues have all been fixed; thanks for all the work on this. From nobody Mon Mar 21 08:54:39 2016 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 B77FB12D8F8 for ; Mon, 21 Mar 2016 08:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] 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 wEmXpu-3ykNT for ; Mon, 21 Mar 2016 08:54:30 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor35.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7204512D8F4 for ; Mon, 21 Mar 2016 08:54:12 -0700 (PDT) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id 4A63AA03DF for ; Mon, 21 Mar 2016 16:54:11 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.41]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 17B9212006B for ; Mon, 21 Mar 2016 16:54:11 +0100 (CET) Received: from OPEXCLILMA1.corporate.adroot.infra.ftgroup ([fe80::95e2:eb4b:3053:fabf]) by OPEXCLILM31.corporate.adroot.infra.ftgroup ([fe80::2cc9:4bac:7b7d:229d%19]) with mapi id 14.03.0279.002; Mon, 21 Mar 2016 16:54:10 +0100 From: To: "cdni@ietf.org" Thread-Topic: new version of draft-fieau-https-delivery-delegation -02 Thread-Index: AdGDiWWeqBS8CBOiQ4KwTvY6cNLzKw== Date: Mon, 21 Mar 2016 15:54:10 +0000 Message-ID: <21594_1458575651_56F01923_21594_2609_1_1BD328329726EF4E91AE924BB1B4CB9E0FE8D5CE@OPEXCLILMA1.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: multipart/alternative; boundary="_000_1BD328329726EF4E91AE924BB1B4CB9E0FE8D5CEOPEXCLILMA1corp_" MIME-Version: 1.0 Archived-At: Subject: [CDNi] new version of draft-fieau-https-delivery-delegation -02 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 21 Mar 2016 15:54:38 -0000 --_000_1BD328329726EF4E91AE924BB1B4CB9E0FE8D5CEOPEXCLILMA1corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, I've just posted a new version of the draft related to HTTPS delegation in = CDNI (draft-fieau-https-delivery-delegation-02). Here are the changes: - Added a delegation requirements section - Rephrased HTTPS redirection section - Added a section on a Lurk remote private key interface in CDNI Thanks for your review, Best regards, Frederic ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_1BD328329726EF4E91AE924BB1B4CB9E0FE8D5CEOPEXCLILMA1corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear all,

 

I’ve jus= t posted a new version of the draft relate= d to HTTPS delegation in CDNI (draft-fieau-https-delivery-delegation-02).

 

Here are the changes:=

-       Added = a delegation requirements section

-       Rephra= sed HTTPS redirection section

-       Added = a section on a Lurk remote private key interface in CDNI<= /p>

 

Thanks for your review,

 

Best regards,

Frederic= 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_1BD328329726EF4E91AE924BB1B4CB9E0FE8D5CEOPEXCLILMA1corp_-- From nobody Mon Mar 21 12:20:32 2016 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 EACAB12D904 for ; Mon, 21 Mar 2016 12:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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 Y20bxEmegB0i for ; Mon, 21 Mar 2016 12:20:20 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (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 D9BE712D9F0 for ; Mon, 21 Mar 2016 12:20:19 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id r129so63999573wmr.1 for ; Mon, 21 Mar 2016 12:20:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-transfer-encoding:subject:date:message-id:cc:to :mime-version; bh=YOiGxM0fU7wn2ADtouNwNxWfTK4xQERphhIm24lDarc=; b=p/JCdSgD00SD0LalfeXkucilgR0e5W73oqZ/H703hwiht0mpy/ZAzPJa/3fvPyG8uU UPtKvcgeOXI8Sy0FcY2QO2kZdJ+k1InO7fu3NcH0xHwdkSaqF27ONSrJmZu5lfv4qZ+y tt/yLQ66BvGJTXxqW0/7zGyMnEZiPaBfAcJcQt/fINW9K1pRjrtwYy7NUto3ZcbVDeyM x1p+X+ijy2kcamtayM60bWaVYJuYXgKqNtyI54o26ClJ0scj6EBHWh3C4VYt+MnTHHyh 3mbV47SnTS89Hqfl+IOHMmPZ6R0hNDL+ysRDQv+bIuo3nkAEsea0W76j/RAO1tdjcxZO xpug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject:date :message-id:cc:to:mime-version; bh=YOiGxM0fU7wn2ADtouNwNxWfTK4xQERphhIm24lDarc=; b=QeFXt7f3OwxMHeB/Uz3N8dmHKRFtfRd4ybBTTHAkE7qeBtSEdH0Zbx+3iGat69sbeu boRWzJvK8U9jaeIJLNvqVeltf2pgaIRj1MZypi+27iBuXq06f72UmebgN2HPXwFCIH4L pIxjYP888KOQoupQ8CgJjZza7UtV2qwxR9zUxNE+bYimL0KRX1o8czhLn459ut/2+uRM 6Tb6OcByOrs2YYdqP1QX9xbKe7gll9E5dfxtDEH8MrfV3cT2zZI8vQVXgLbSk1GQbnW6 H77Yzv+oxzMlE/oFQZiaoccGg9i0iKvqXcQ46bZm15Y9/paW7wIIPgorX576xv1u5Svn DRNA== X-Gm-Message-State: AD7BkJJ+0A2Zj54Jgc6HBq1lSuXs1YNuf1L/0UEgJ3XMfH5OD0XmlCYmWz7UbZ9XqUn1EA== X-Received: by 10.194.185.237 with SMTP id ff13mr35463531wjc.129.1458588018449; Mon, 21 Mar 2016 12:20:18 -0700 (PDT) Received: from ams-flefauch-nitro11.cisco.com ([173.38.220.60]) by smtp.gmail.com with ESMTPSA id w184sm12111734wmb.1.2016.03.21.12.20.11 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 21 Mar 2016 12:20:17 -0700 (PDT) From: Francois Le Faucheur Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 21 Mar 2016 20:20:09 +0100 Message-Id: To: "" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Le Faucheur Francois Subject: [CDNi] Agenda Slot Request for IETF-95 CDNI WG Meeting X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 21 Mar 2016 19:20:25 -0000 Hi, Please send Kevin and I your slot request for IETF-95 (with desired time = and speaker). Thanks Francois & Kevin= From nobody Mon Mar 21 16:32:01 2016 Return-Path: X-Original-To: cdni@ietf.org Delivered-To: cdni@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 127BE12D1A1; Mon, 21 Mar 2016 16:31:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160321233158.5783.73087.idtracker@ietfa.amsl.com> Date: Mon, 21 Mar 2016 16:31:58 -0700 Archived-At: Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-metadata-13.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 21 Mar 2016 23:31:58 -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 of the IETF. Title : CDN Interconnection Metadata Authors : Ben Niven-Jenkins Rob Murray Matt Caulfield Kevin J. Ma Filename : draft-ietf-cdni-metadata-13.txt Pages : 62 Date : 2016-03-21 Abstract: The Content Delivery Networks Interconnection (CDNI) metadata interface enables interconnected Content Delivery Networks (CDNs) to exchange content distribution metadata in order to enable content acquisition and delivery. The CDNI metadata associated with a piece of content provides a downstream CDN with sufficient information for the downstream CDN to service content requests on behalf of an upstream CDN. This document describes both a base set of CDNI metadata and the protocol for exchanging that metadata. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-metadata/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-cdni-metadata-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-metadata-13 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 Mar 21 16:39:29 2016 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 25AF712D1C0 for ; Mon, 21 Mar 2016 16:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] 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 XnDmXcly4vnf for ; Mon, 21 Mar 2016 16:39:25 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 098B112D194 for ; Mon, 21 Mar 2016 16:39:23 -0700 (PDT) X-AuditID: c6180641-f79fa6d0000057a9-ef-56f086099c8b Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id F4.CB.22441.90680F65; Tue, 22 Mar 2016 00:38:49 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0248.002; Mon, 21 Mar 2016 19:39:23 -0400 From: Kevin Ma J To: "cdni@ietf.org" Thread-Topic: [CDNi] I-D Action: draft-ietf-cdni-metadata-13.txt Thread-Index: AQHRg8nx2F5nXQPzikaPt7t+rrG9S59kjIhQ Date: Mon, 21 Mar 2016 23:39:21 +0000 Message-ID: References: <20160321233158.5783.73087.idtracker@ietfa.amsl.com> In-Reply-To: <20160321233158.5783.73087.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCLMWRmVeSWpSXmKPExsUyuXRPoC5n24cwg+OzbSyezv7D6sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujLm3d7AVNAtXLLp6k7mB8RpfFyMnh4SAicTZif+YIGwxiQv3 1rN1MXJxCAkcYZS4cn4lO4SznFFi8stZLCBVbAJaEo+//gXq4OAQEVCW+HnIESQsLGAvsfD8 A2YQW0TAQWLCoeOsELaRxIx7vxlBylkEVCVW7qwCCfMK+Eqsfr0PrFwIqPzFxANgNqeAo8SD oxPZQWxGoHu+n1oDdhuzgLjErSfzoe4UkFiy5zwzhC0q8fLxP1YIW1FiX/90doh6HYkFuz+x QdjaEssWvmaG2CsocXLmE5YJjKKzkIydhaRlFpKWWUhaFjCyrGLkKC0uyMlNNzLcxAgM+2MS bI47GPf2eh5iFOBgVOLhNbjyPkyINbGsuDL3EKMEB7OSCO+7lg9hQrwpiZVVqUX58UWlOanF hxilOViUxHm/fbwcJiSQnliSmp2aWpBaBJNl4uCUamDUl33DmxKg/atycTKPsFyxX9P7Fv1F 5y6/jtLIqPV+/tFYWc//bFfn1ClGxnd78vbpHNhodWbjvxc1LZ61DS1tvz2LDjtH7BP593fy lDsLJeZcUft4SMB6VXHWZs55bOWr0uO4J5X6PdVUb/nxoV+FwVBdLd2bb6buAftfMV4anov5 Wywv/VViKc5INNRiLipOBAAH5uOgdwIAAA== Archived-At: Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-metadata-13.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 21 Mar 2016 23:39:27 -0000 Hi All, Just uploaded a new version of the metadata draft. Mostly editorial chan= ges (fixed examples, fixed typos, cleaned up and hopefully simplified some = text, removed non-normative 2119 language, etc.) thanx. -- Kevin J. Ma=09 > -----Original Message----- > From: CDNi [mailto:cdni-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Monday, March 21, 2016 7:32 PM > To: i-d-announce@ietf.org > Cc: cdni@ietf.org > Subject: [CDNi] I-D Action: draft-ietf-cdni-metadata-13.txt >=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 Interconnectio= n > of the IETF. >=20 > Title : CDN Interconnection Metadata > Authors : Ben Niven-Jenkins > Rob Murray > Matt Caulfield > Kevin J. Ma > Filename : draft-ietf-cdni-metadata-13.txt > Pages : 62 > Date : 2016-03-21 >=20 > Abstract: > The Content Delivery Networks Interconnection (CDNI) metadata > interface enables interconnected Content Delivery Networks (CDNs) to > exchange content distribution metadata in order to enable content > acquisition and delivery. The CDNI metadata associated with a piece > of content provides a downstream CDN with sufficient information for > the downstream CDN to service content requests on behalf of an > upstream CDN. This document describes both a base set of CDNI > metadata and the protocol for exchanging that metadata. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-cdni-metadata/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-cdni-metadata-13 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-metadata-13 >=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 Thu Mar 24 08:17:02 2016 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 82FB112DD75; Thu, 24 Mar 2016 08:17:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001] 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 QxMrUHydC1PH; Thu, 24 Mar 2016 08:16:57 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.144]) by ietfa.amsl.com (Postfix) with ESMTP id 44B0612DCA4; Thu, 24 Mar 2016 08:02:13 -0700 (PDT) Received: from 97e1f3b1.skybroadband.com ([151.225.243.177] helo=[192.168.0.4]) by smtp04.mailcore.me with esmtpa (Exim 4.80.1) (envelope-from ) id 1aj6m3-0001Dk-OO; Thu, 24 Mar 2016 15:02:12 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Ben Niven-Jenkins In-Reply-To: <20160316022119.12526.24798.idtracker@ietfa.amsl.com> Date: Thu, 24 Mar 2016 15:02:09 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <0EC8CD81-4F11-43E7-B52E-A7B0D88E8A10@niven-jenkins.co.uk> References: <20160316022119.12526.24798.idtracker@ietfa.amsl.com> To: Ben Campbell X-Mailer: Apple Mail (2.2098) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Archived-At: Cc: cdni@ietf.org, draft-ietf-cdni-redirection@ietf.org, The IESG , cdni-chairs@ietf.org Subject: Re: [CDNi] Ben Campbell's No Objection on draft-ietf-cdni-redirection-17: (with COMMENT) X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 24 Mar 2016 15:17:00 -0000 Hi Ben, (Francois, Kevin, there is a question from Ben below that I think needs = your input as WG chairs) > On 16 Mar 2016, at 02:21, Ben Campbell wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I have a few comments and questions: >=20 > # Substantive: # >=20 > - 3, last paragraph: "Any operational > mechanisms this requires, e.g., private key distribution to > surrogates and request routers in dCDNs, are outside the scope of > this document. Further mechanisms to notify User Agents of trusted > redirection are also outside the scope of this document." >=20 > Is it in scope _somewhere_? As it is, this seems like an excuse to = avoid > HTTPS, which is not optimal. I believe it is in scope of the LURK BoF. I don=E2=80=99t understand your point about avoiding HTTPS. This is = saying that once a User Agent connects to a surrogate or request router = over HTTPS, that surrogate/request router better be able present the = correct certificate, complete a TLS handshake, etc otherwise content = delivery will fail. How a surrogate/request router manages to achieve = that is outside of the scope of the redirection interface this document = is specifying, similar to how a particular origin/web server/etc = (without CDNI) manages to achieve that is outside of the scope of the = HTTPS spec. >=20 > -4, first paragraph: > Was any thought given to using or supporting HTTP/2? The authors gave it a bit of thought. It was not raised in the working = group from what I remember. I=E2=80=99m not sure HTTP/2 is particularly relevant to the = specification. The CDNI RI spec is essentially a HTTP API for exchanging = CDNI redirection requests/responses. Like any HTTP API it can feasibly = be run over HTTP, HTTPS & HTTP/2 as the semantics of all three are the = same. =20 >=20 > -- step 1 after figure 1: > I am I correct to infer an assumption that CDN A acts as the UAs DNS > server? Is that assumption documented somewhere? No, CDN A does not act as the UA=E2=80=99s caching DNS server. The = text/diagram is a bit simplified to be able to show the main idea and = collapse the DNS & HTTP cases for brevity as they are largely the same. When the document says: "The User Agent sends its (DNS or HTTP) request to CDN A.=E2=80=9D what it really means is: =E2=80=9CIf HTTP redirection is being used between the UA & CDN A, the = User Agent sends its HTTP request to CDN A. If DNS redirection is being = used between the UA & CDN A, the User Agent sends a DNS request to its = configured DNS resolver, normal DNS caching infrastructure interactions = occur and if a suitable response is not already cached, the last DNS = resolver in the chain will send a DNS request to CDN A." If you think including the above text (or a modified version you=E2=80=99d= like to suggest) would help the clarity of the document I=E2=80=99m = happy to add it? >=20 > - 4.2, last paragraph (note) > This explicitly makes an IPv6 only CDN non-compliant. Is that the > intent? I=E2=80=99m not sure how it does that, could you explain? =46rom my point of view the text is stating what formats for parsing = IPv4 & IPv6 addresses implementations must support. It does not say that = in order to use the CDNI redirection interface, one=E2=80=99s CDN must = use IPv4. >=20 > - 4.4.1, table, entry for dns-only: > The description says "MUST include RTs". That doesn't seem to consider > error cases.=20 My intention was to state what someone must do under normal = circumstances and I assumed that in the case of any error that prevented = them from doing that, that they would return an appropriate error = response instead. I can change "If True then dCDN MUST only use DNS redirection and MUST = include RTs to one or more surrogates in its RI response." to "If True then dCDN MUST only use DNS redirection and MUST include RTs to = one or more surrogates in any successful RI response." (or any other text you=E2=80=99d prefer) if that would alleviate your = concern? >=20 > - 4.8, 3rd and 4th paragraph: > I'm curious why they SHOULDs are not MUSTs. Are there times it might = be > reasonable to do something different; maybe even choosing not to send = an > error at all? I wonder if these should be of the form of "MUST send an > error which SHOULD be XXX=E2=80=9D You=E2=80=99re right I think we were a bit lax here. The only thing I = was thinking was maybe someone would want to return a different error = code for some reason we haven=E2=80=99t thought of. I prefer your suggestion of "MUST send which SHOULD be=E2=80=9D so = I=E2=80=99ve changed the two paragraphs in my working copy of -18 to be: "the dCDN MUST send an RI error response which SHOULD include an error = code of XXX=E2=80=9D (with XXX replaced by the appropriate error code). >=20 > -5.1, 2nd to last paragraph: > " In an environment where any such protection is required...," is a > pretty weak recommendation. Would you consider making the default > behavior secure? Or at least saying something to the effect of "Except = in > networks where similar protections are provided by some other > means,=E2=80=A6"? There has been quite a bit of discussion in the CDNI WG around this = wording and the WG decided to align the wording it used across all its = documents. The first document to progress to IESG was = draft-ietf-cdni-logging and the other CDNI drafts (including the = redirection one we are discussing) use the same wording as = draft-ietf-cdni-logging. I=E2=80=99m happy to continue to align the wording in this document with = that in draft-ietf-cdni-logging, but I would suggest we avoid repeating = the same discussion that is happening around draft-ietf-cdni-logging = here. Francois/Kevin - Can you help here? Has the discussion around this text = for draft-ietf-cdni-logging concluded yet? >=20 > -5.2, First paragraph: > I have trouble imagining situations where information passed over the = RI > might not be sensitive. Fair point. I have changed it to now read =E2=80=9CInformation passed over the RI ought to be considered personal = and sensitive." (I wanted to say =E2=80=9Cshould be considered=E2=80=9D but that would = be ambiguous about whether it is really should or SHOULD so I settled on = =E2=80=9Cought to be=E2=80=9D but if you can think of a better way to = phrase it I=E2=80=99m happy to use it) > -- third paragraph: > I wish the text wasn't so dismissive of attempts to anonymize some RI > request data. I agree doing so may reduce RI effectiveness in some = cases. > But that needs to be balanced with privacy needs, and that balance may > not always land on the side of RI effectiveness. And the inability to > correlate UAs between requests can be a feature in some circumstances.=20= I agree where the balance lands may be different depending on = circumstances. If you can suggest specific edits/new text that comes = across less dismissive, I=E2=80=99ll incorporate them.=20 >=20 > # Editorial: # >=20 > - General: > There's quite a bit of repetition and redundant text, including = redundant > normative text. Do you think the repetition is harmful? I=E2=80=99m reluctant to rework = the document unless really necessary.=20 >=20 > - abstract:=20 > s/"The Request Routing Interface..."/ "The Content Delivery Network > Interface (CDNI) Request Routing Interface..." > s/"comprises of"/=E2=80=9Ccomprises" Done. >=20 > - 4, 2nd paragraph: "The same HTTP interface is used for both DNS and > HTTP redirection of > User Agent requests,..." >> =46rom the rest of the sentence, I assume this means the RI uses the = same > interface to communicate information about DNS and HTTP = redirects=E2=80=94but the > first part sounds like it is saying that the actual redirection (i.e. > interacting with the UA) occurs over the same interface. I reworded to make the distinction clearer (hopefully), this is what I = have now: "The RI between the uCDN and dCDN uses the same HTTP interface to = encapsulate the attributes of both DNS and HTTP requests received from = User Agents=E2=80=A6" >=20 > -- 4th paragraph: > s/"try and"/"try to=E2=80=9D Done >=20 > - 4.1, 2nd to last paragraph: "... signaled the HTTP response body > of the RI response ..." > Missing word? (perhaps "... signaled in the HTTP response body =E2=80=A6= " Done >=20 > -4.2, paragraph 4: > This paragraph is redundant to section 4.8. I=E2=80=99ve removed this paragraph from my working copy of -18 >=20 > -4.5.1, last paragraph before example: "For example, it MAY only > send the contents of the first occurrence of the HTTP Headers > instead." > s/MAY/might. Done Ben >=20 >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From nobody Thu Mar 24 08:21:08 2016 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 761A112D1BA; Thu, 24 Mar 2016 08:21:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001] 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 aTI8mMsYpuCX; Thu, 24 Mar 2016 08:21:04 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.143]) by ietfa.amsl.com (Postfix) with ESMTP id A132C12DDDD; Thu, 24 Mar 2016 08:05:32 -0700 (PDT) Received: from 97e1f3b1.skybroadband.com ([151.225.243.177] helo=[192.168.0.4]) by smtp04.mailcore.me with esmtpa (Exim 4.80.1) (envelope-from ) id 1aj6pH-0008dL-K8; Thu, 24 Mar 2016 15:05:31 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Ben Niven-Jenkins In-Reply-To: <20160316232303.13060.881.idtracker@ietfa.amsl.com> Date: Thu, 24 Mar 2016 15:05:31 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <46E278DB-B866-48E7-A698-8569D9638C20@niven-jenkins.co.uk> References: <20160316232303.13060.881.idtracker@ietfa.amsl.com> To: Alissa Cooper X-Mailer: Apple Mail (2.2098) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Archived-At: Cc: cdni@ietf.org, draft-ietf-cdni-redirection@ietf.org, The IESG , cdni-chairs@ietf.org Subject: Re: [CDNi] Alissa Cooper's Discuss on draft-ietf-cdni-redirection-17: (with DISCUSS) X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 24 Mar 2016 15:21:06 -0000 Hi Alissa, (Francois, Kevin, there is a question from Alissa below that I think = needs your input as WG chairs) > On 16 Mar 2016, at 23:23, Alissa Cooper wrote: > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > (1) > There is some ambiguity in the document about whether the uCDN passes = the > IP address of the UA or its prefix to the dCDN. Sec 4.4.1 says that = for > DNS redirection, the uCDN passes "IP address or prefix" of the UA, but > then in the definition of resolver-ip specifies it only as the IP = address > of the UA. resolver-ip contains =E2=80=9CThe IP address of the UA=E2=80=99s DNS = resolver." c-subnet contains the "The IP address (or prefix) of the UA in CIDR = format." The idea is resolver-ip contains the IP address of the DNS resolver = making the DNS request to the uCDN. c-subnet contains (if present) the = address/prefix carried by draft-ietf-dnsop-edns-client-subnet. > Then in Sec 4.5.1 for HTTP redirection the equivalent field is > specified as the IP address of the UA and the possibility of sending = only > a prefix is not mentioned. That is because with HTTP the UA connects directly to the uCDN and the = uCDN can see the UA=E2=80=99s IP address. > Then 5.2 has the para that begins "While it is > technically possible to mask some information in the RI Request, such = as > the last bits of the UA IP address ..." which makes it seem like = prefixes > really shouldn't be sent. What we have provided is the ability for the CDNI Redirection Interface = to encode the properties of the source (DNS or HTTP) requests so that = uCDNs & dCDNs can make the best dCDN & surrogate selection decisions = that they can. We=E2=80=99re not suggesting or mandating any additional = IP address masking behaviour than that provided (or not provided) by the = source protocol. This may be the source of the confusion - we=E2=80=99re = not saying =E2=80=9Cyou should mask the IP address behind a prefix and = this is how to do it=E2=80=9D and then being inconsistent about applying = it to DNS vs HTTP, we=E2=80=99re saying =E2=80=9Chere=E2=80=99s how to = encapsulate a DNS or HTTP request into our protocol=E2=80=9D. >=20 > I think the document needs some consistency and clarity here about > whether prefixes are expected to be used for either redirection = method. Does the above explanation change this view? Or change the text you = would like to see that provides that clarity? > It's also not obvious to me why the document shouldn't recommend to = uCDNs > that if they are polling multiple candidate dCDNs as described in Sec > 5.2, they should use only a prefix for such requests. The arguments = given > against this seem pretty thin -- isn't preventing correlation of = multiple > requests to a single UA a good thing, especially when it's being done = by > a bunch of dCDNs? And I don't understand the CGN example -- isn't the > root of the problem here that topologically dispersed UAs are sharing = the > same public-facing IP address, in which case the dCDN may have the = same > problem when passed a full IP address as it does a prefix?=20 We describe how to encapsulate DNS & HTTP requests in the RI protocol = and we discuss that in some circumstances it may provide information to = a dCDN that they would not otherwise have got and that masking IP = addresses also has downsides. We do not provide any privacy enhancing normative behaviour and we do = not make a value judgement on whether any possible reduction in privacy = is more important than the downsides of providing that reduction in = privacy. The specific example of CGN may not be the best example for us to have = used. The general point is that dCDNs perform surrogate selection using = UA IP address (or the closest proxy they can get, e.g. the UA=E2=80=99s = DNS resolver=E2=80=99s IP address) and that masking the UA IP address = therefore means dCDNs may make less optimum decisions and that is a = downside. Maybe we=E2=80=99d be better just saying that rather than trying to = provide specific scenarios that say that by inference? >=20 > (2) > Ben noted the weakness of the recommendation in 5.1 regarding TLS. I = see > that the language here is the same as it is in > draft-ietf-cdni-logging-22. But I thought the agreement on that = document > was MUST use TLS, full stop. So there is ambiguity in both documents I > think. "In an environment where ..." and "When TLS is used ..." seem > inconsistent with "TLS MUST be used ...." I'm happy to clear on this = if > I'm missing something from the previous discussion, which I think > happened when I was on leave and resulted from one of Stephen's = ballots. What I replied to Ben=E2=80=A6"There has been quite a bit of discussion = in the CDNI WG around this wording and the WG decided to align the = wording it used across all its documents. The first document to progress = to IESG was draft-ietf-cdni-logging and the other CDNI drafts (including = the redirection one we are discussing) use the same wording as = draft-ietf-cdni-logging. I=E2=80=99m happy to continue to align the wording in this document with = that in draft-ietf-cdni-logging, but I would suggest we avoid repeating = the same discussion that is happening around draft-ietf-cdni-logging = here. Francois/Kevin - Can you help here? Has the discussion around this text = for draft-ietf-cdni-logging concluded yet?" Ben From nobody Thu Mar 24 08:23:55 2016 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 D780012DBD9; Thu, 24 Mar 2016 08:23:53 -0700 (PDT) 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 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 bci_04sS_U0v; Thu, 24 Mar 2016 08:23:52 -0700 (PDT) Received: from mailex.mailcore.me (smtp.123-reg.co.uk [94.136.40.63]) by ietfa.amsl.com (Postfix) with ESMTP id F354812DCF0; Thu, 24 Mar 2016 08:07:47 -0700 (PDT) Received: from 97e1f3b1.skybroadband.com ([151.225.243.177] helo=[192.168.0.4]) by smtp04.mailcore.me with esmtpa (Exim 4.80.1) (envelope-from ) id 1aj6rS-00015F-NJ; Thu, 24 Mar 2016 15:07:46 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Ben Niven-Jenkins In-Reply-To: <20160317101014.1026.78717.idtracker@ietfa.amsl.com> Date: Thu, 24 Mar 2016 15:07:45 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <6B22150C-4A0E-4FFF-A48C-AEA2D881632E@niven-jenkins.co.uk> References: <20160317101014.1026.78717.idtracker@ietfa.amsl.com> To: Stephen Farrell X-Mailer: Apple Mail (2.2098) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Archived-At: Cc: cdni@ietf.org, draft-ietf-cdni-redirection@ietf.org, The IESG , cdni-chairs@ietf.org Subject: Re: [CDNi] Stephen Farrell's Discuss on draft-ietf-cdni-redirection-17: (with DISCUSS and COMMENT) X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 24 Mar 2016 15:23:54 -0000 Hi Stephen, > On 17 Mar 2016, at 10:10, Stephen Farrell = wrote: > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 >=20 > The basic idea of the uCDN sending everything to the dCDN so > that the dCDN can reply with all the details of a request > that'll work (i.e. the sc-* stuff) seems broken as it requires > that the uCDN expose all security and privacy sensitive data > to the dCDN in pretty much all cases. I fail to see why that > is an acceptable approach. Can you point me at where the WG > disucssed the issues with that approach and considered less > security/privacy unfriendly potential alternatives? =20 >=20 > Some examples: > - section 4.1 says "SHOULD convey as much information as > possible" that is surely wrong - there is no reason to > encourage sending cookies and other security/privacy sensitive > information and in fact sending such should be discouraged > (SHOULD NOT) or even, if possible, prohibited (MUST NOT). =20 > - The cs-(cookie) in 4.5.1 is one specific case of sending too > much. =20 > - 4.4.1 Resolver IP addr is liable to be that of an end user's > machine (if they operate a recursive).=20 >=20 > But the examples are just that, I'd like to DISCUSS the WG's > consideration of the overall design first before we dive into > those. I haven=E2=80=99t searched the archives. I don=E2=80=99t recall lots of = discussion around the design. The chairs may be able to shed more light. My personal view is that there is a trade off between exposing = potentially security or privacy sensitive data and the impact that might = cause to e.g. efficiency or surrogate selection, user experience, etc. The technology side of CDN interconnect does not operate in a vacuum = there is also the business agreement/contractual side of such = interconnects. Depending on your point of view and the specific = deployment where the balance of trade-offs falls will be different and = one may not be exposing anything one would not have exposed if only a = single CDN was in use. For example, if CDNI is used to interconnect two CDNs owned & operated = by the same entity (e.g. a network operator using CDNI to interconnect = CDNs from two different vendors) there is no additional privacy = implications than if the same network operator used a single larger CDN. = Or a dCDN may be refusing an IP address and if presented with a larger = prefix may refuse to serve the whole prefix, leading to a poorer user = experience because a different dCDN is used for the content delivery. I do not feel qualified to decide where the line should be drawn. The = document provides the technical mechanics to encapsulate existing DNS & = HTTP requests and allow interconnected CDNs to perform exactly as they = do today when they are operating independently. =46rom my non-qualified = point of view I do not believe CDNI makes privacy worse for users = compared to the single CDN use case, but if it does, that discussion = feels like it is much wider than this particular document. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 >=20 > - I support Alissa's discuss points. See my response just now to Alissa. >=20 > - section 3: false-negative? don't you mean false-positive? > And in any case, those warnings are not false from the browser > perspective. I'd suggest s/false-negative// Good suggestion, I've removed false-negative and left it as just = =E2=80=9Ctrigger security warnings=E2=80=9D from my working copy of -18.=20= >=20 > - section 3: phrases like "trusted re-direction" are a bad > idea - you need to say who is trusting whom for what for this > to be meaningful and not misleading (people get misled by such > phrases all the time). I'd just delete the sentence or > s/trusted// I=E2=80=99ve deleted the whole sentence from my working copy of -18 >=20 > - 4.4.2: a JSON "string" is not the same as a DNS name is it? > What about i18n? (ULABEL or ALABEL?) what about odd characters > allowed in JSON but not in DNS names? In general the fields > in this dictionary (and others) seem underspecified to me. I=E2=80=99m afraid I=E2=80=99m not an expert in JSON strings, unicode or = i18n. I think what you=E2=80=99re getting at is that a JSON string can = contain more characters than allowed by an ALABEL or a ULABEL and we = should be more precise in constraining the allowed characters? And that = you think there are other fields in the document that would also benefit = from constraining the allowable set of characters. If that=E2=80=99s the = case I=E2=80=99m happy to make the edits to improve the document but I = will need some help on what the right terminology is and the right = references for the allowable characters. Ben From nobody Thu Mar 24 08:48:49 2016 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 5731E12DD44; Thu, 24 Mar 2016 08:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 1w04w4d5skcR; Thu, 24 Mar 2016 08:48:40 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B641112DBD0; Thu, 24 Mar 2016 08:35:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7BFFEBE33; Thu, 24 Mar 2016 15:35:08 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t1QPUQyzSt04; Thu, 24 Mar 2016 15:35:06 +0000 (GMT) Received: from [10.87.49.100] (unknown [86.46.21.5]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 12070BDCF; Thu, 24 Mar 2016 15:35:06 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1458833706; bh=Q9YLUCMo+LiE13UILigNN8tOWNBqvDvoHRtSu32hU5Y=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=ObyhoFqgV3NrMZyENMO2aXdkK95R9NyeqN5XKLN3AAIsZxGXIBr0KpOzoAT2DN2VA wn46Z56Xl08/40Xw4G9mQ34AuZKOkz/32C41VCGNhNhcbjOBSxG2p0pRDxi+xoxMn0 FmWxMg4bBo6ZyQCJVfodEJE/rso5dogx6CTE4/tg= To: Ben Niven-Jenkins References: <20160317101014.1026.78717.idtracker@ietfa.amsl.com> <6B22150C-4A0E-4FFF-A48C-AEA2D881632E@niven-jenkins.co.uk> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56F40929.1020309@cs.tcd.ie> Date: Thu, 24 Mar 2016 15:35:05 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <6B22150C-4A0E-4FFF-A48C-AEA2D881632E@niven-jenkins.co.uk> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050904050307020501050600" Archived-At: Cc: cdni@ietf.org, draft-ietf-cdni-redirection@ietf.org, The IESG , cdni-chairs@ietf.org Subject: Re: [CDNi] Stephen Farrell's Discuss on draft-ietf-cdni-redirection-17: (with DISCUSS and COMMENT) X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 24 Mar 2016 15:48:43 -0000 This is a cryptographically signed message in MIME format. --------------ms050904050307020501050600 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 24/03/16 15:07, Ben Niven-Jenkins wrote: > Hi Stephen, >=20 >> On 17 Mar 2016, at 10:10, Stephen Farrell >> wrote:=20 >> ----------------------------------------------------------------------= >> >>=20 DISCUSS: >> ----------------------------------------------------------------------= >> >> >> >>=20 The basic idea of the uCDN sending everything to the dCDN so >> that the dCDN can reply with all the details of a request that'll >> work (i.e. the sc-* stuff) seems broken as it requires that the >> uCDN expose all security and privacy sensitive data to the dCDN in >> pretty much all cases. I fail to see why that is an acceptable >> approach. Can you point me at where the WG disucssed the issues >> with that approach and considered less security/privacy unfriendly >> potential alternatives? >>=20 >> Some examples: - section 4.1 says "SHOULD convey as much >> information as possible" that is surely wrong - there is no reason >> to encourage sending cookies and other security/privacy sensitive=20 >> information and in fact sending such should be discouraged (SHOULD >> NOT) or even, if possible, prohibited (MUST NOT). - The cs-(cookie) >> in 4.5.1 is one specific case of sending too much. - 4.4.1 Resolver >> IP addr is liable to be that of an end user's machine (if they >> operate a recursive). >>=20 >> But the examples are just that, I'd like to DISCUSS the WG's=20 >> consideration of the overall design first before we dive into=20 >> those. >=20 > I haven=E2=80=99t searched the archives. I don=E2=80=99t recall lots of= discussion > around the design. The chairs may be able to shed more light. >=20 > My personal view is that there is a trade off between exposing > potentially security or privacy sensitive data and the impact that > might cause to e.g. efficiency or surrogate selection, user > experience, etc. >=20 > The technology side of CDN interconnect does not operate in a vacuum > there is also the business agreement/contractual side of such > interconnects. Depending on your point of view and the specific > deployment where the balance of trade-offs falls will be different > and one may not be exposing anything one would not have exposed if > only a single CDN was in use. >=20 > For example, if CDNI is used to interconnect two CDNs owned & > operated by the same entity (e.g. a network operator using CDNI to > interconnect CDNs from two different vendors) there is no additional > privacy implications than if the same network operator used a single > larger CDN. Or a dCDN may be refusing an IP address and if presented > with a larger prefix may refuse to serve the whole prefix, leading to > a poorer user experience because a different dCDN is used for the > content delivery. >=20 > I do not feel qualified to decide where the line should be drawn. Frankly I'm not convinced by the argument above. The draft IMO now very clearly draws the line way way over on the commercial side, and without seeming to consider the privacy issues much or at all. The draft says that one SHOULD send as much as possible. I think if we base our discussion on the text we should be able to make better progress. Can we agree that as-is, the draft is very much aiming to meet the commercial requirements and is not taking account or privacy requirements? S. > The > document provides the technical mechanics to encapsulate existing DNS > & HTTP requests and allow interconnected CDNs to perform exactly as > they do today when they are operating independently. From my > non-qualified point of view I do not believe CDNI makes privacy worse > for users compared to the single CDN use case, but if it does, that > discussion feels like it is much wider than this particular > document. >=20 >> ----------------------------------------------------------------------= >> >>=20 COMMENT: >> ----------------------------------------------------------------------= >> >> >> >>=20 - I support Alissa's discuss points. >=20 > See my response just now to Alissa. >=20 >>=20 >> - section 3: false-negative? don't you mean false-positive? And in >> any case, those warnings are not false from the browser=20 >> perspective. I'd suggest s/false-negative// >=20 > Good suggestion, I've removed false-negative and left it as just > =E2=80=9Ctrigger security warnings=E2=80=9D from my working copy of -18= =2E >=20 >>=20 >> - section 3: phrases like "trusted re-direction" are a bad idea - >> you need to say who is trusting whom for what for this to be >> meaningful and not misleading (people get misled by such phrases >> all the time). I'd just delete the sentence or s/trusted// >=20 > I=E2=80=99ve deleted the whole sentence from my working copy of -18 >=20 >>=20 >> - 4.4.2: a JSON "string" is not the same as a DNS name is it? What >> about i18n? (ULABEL or ALABEL?) what about odd characters allowed >> in JSON but not in DNS names? In general the fields in this >> dictionary (and others) seem underspecified to me. >=20 > I=E2=80=99m afraid I=E2=80=99m not an expert in JSON strings, unicode o= r i18n. I > think what you=E2=80=99re getting at is that a JSON string can contain = more > characters than allowed by an ALABEL or a ULABEL and we should be > more precise in constraining the allowed characters? And that you > think there are other fields in the document that would also benefit > from constraining the allowable set of characters. If that=E2=80=99s th= e case > I=E2=80=99m happy to make the edits to improve the document but I will = need > some help on what the right terminology is and the right references > for the allowable characters. >=20 > Ben >=20 --------------ms050904050307020501050600 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjAzMjQx NTM1MDVaMC8GCSqGSIb3DQEJBDEiBCBFuIkwlEjUBolZqnVVKHTX3yzZbNWLgcAw6lqR/YIB SzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQBjN5HI+UvP6sbMF+LMkMY30erj/FR6v5gCt0YRZ703mRNlEvRSyTKS fZS32MMsPpbEuZpMoNrBfkwbf8nZ6wulQWZH9QXP49OX3KQWi6QHZFCZ/y6IEm9a1PJB8u8J mMmFNNSQpxYOXD9Cb4DcJgetgh6eNAjTGyqO2iNzcA6Dw/aVilKB4Df4ZUZLaovMYlo77np1 B1rgvY179pmYYAc8Or6f6jHeiSOBBr0sMDLtLlQkGAYtmDCjIGC56jwHWlj2W9Tzg5vCJRar 2IV+yzoC4sbbURKZzacNGfRaJRQM88ENvnBNBXKCPbm5U9uEWEjTTpmUQM2emqdodCHdODuB AAAAAAAA --------------ms050904050307020501050600-- From nobody Thu Mar 24 10:07:47 2016 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 74A6D12D9F5; Tue, 22 Mar 2016 07:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] 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 Ae5e_P8u6_4R; Tue, 22 Mar 2016 07:57:41 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5611E12D975; Tue, 22 Mar 2016 07:57:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.24,377,1454972400"; d="asc'?scan'208,217";a="209498763" Received: from geve.inrialpes.fr ([194.199.28.1]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Mar 2016 15:57:38 +0100 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_060E29B6-ECD5-44E4-BC08-AB14B7CE2E8D"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Vincent Roca In-Reply-To: <252883D7-E325-4B9A-A978-FEACE5B40143@alcatel-lucent.com> Date: Tue, 22 Mar 2016 15:57:37 +0100 Message-Id: <61B94AAC-920E-4909-9680-6FF212E8901D@inria.fr> References: <252883D7-E325-4B9A-A978-FEACE5B40143@alcatel-lucent.com> To: "Murray, Rob (Nokia - GB)" X-Mailer: Apple Mail (2.3112) Archived-At: X-Mailman-Approved-At: Thu, 24 Mar 2016 10:07:46 -0700 Cc: "draft-ietf-cdni-control-triggers@tools.ietf.org" , Vincent Roca , "cdni@ietf.org" , IESG , "secdir@ietf.org" Subject: Re: [CDNi] Secdir review of draft-ietf-cdni-control-triggers-11 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 22 Mar 2016 14:57:43 -0000 --Apple-Mail=_060E29B6-ECD5-44E4-BC08-AB14B7CE2E8D Content-Type: multipart/alternative; boundary="Apple-Mail=_828F5FE5-2B44-482B-A67B-DAA632B1F4EB" --Apple-Mail=_828F5FE5-2B44-482B-A67B-DAA632B1F4EB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Rob, > I've just posted a "-12" of the CDNI Triggers draft, hopefully = addressing these comments. Responses inline below. I see you've added section 2.2.1 to clarify many architectural aspects. = That's quite useful. >>>> There are several topics I=E2=80=99d like to discuss: >>>>=20 >>>> 1- Concerning the use of TLS to carry CI/T traffic, I see it is = mandatory >>>> to implement, but still optional to use (1st sentence of Section = 8.1). Is >>>> it still reasonable in current Internet? At a minimum I would = expect a >>>> =C2=AB MUST support =C2=BB / =C2=AB SHOULD use =C2=BB. >>>=20 >>> Section 8.1 goes on to say ... >>>=20 >>> [ ... description of benefits of HTTPS ... ] >>>=20 >>> In an environment where any such protection is required, mutually >>> authenticated encrypted transport MUST be used to ensure >>> confidentiality of the CI/T information. To that end, TLS MUST be >>> used by CI/T, including authentication of the remote end. >>>=20 >>> ... the Internet is clearly an environment where such protection is >>> required, and it'll often be used for these interfaces - we could = state >>> that explicitly, would that address the concern? >>>=20 >>> But, CI/T could also be deployed to run over a VPN or private = network >>> between two interconnected CDNs, in such an environment HTTPS = transport >>> would not have the same benefits. >>=20 >> Yes, that=E2=80=99s my point. Say explicitly that Internet is an = example of environment where >> such a protection is mandatory. >=20 > In "-12" I've aligned the text above with the text used in the = cdni-metadata draft: >=20 > TLS MUST be used by the server-side (dCDN) and the client-side (uCDN) = of > the CI/T interface, including authentication of the remote end, = unless > alternate methods are used for ensuring the confidentiality of the > information in the CI/T interface requests and responses (such as = setting > up an IPsec tunnel between the two CDNs or using a physically secured > internal network between two CDNs that are owned by the same = corporate > entity). >=20 > I think that covers it better (?). This is much better. Just a minor comment: "... for insuring the = security" instead of "... for ensuring the confidentiality", since confidentiality is only = one aspect of security. >>>> 2- Section 8.1, please check the paragraph =C2=AB Note that in a =C2=AB= diamond =C2=BB >>>> configuration [=E2=80=A6] =C2=BB. This paragraph is rather = confusing to me. Confusion >>>> comes from: >>>> - the lack of description of the =C2=AB diamond configuration =C2=BB.= I understand >>>> there is one dCDN on top and multiple uCDN directly connected = below, am I >>>> right? >>>=20 >>> Yes, that's right. The draft says: >>>=20 >>> Note that in a "diamond" configuration, where one uCDN's content = can >>> be acquired via more than one directly-connected uCDN, >>>=20 >>> Would the following rearrangement help? ... >>>=20 >>> A "diamond" configuration is one where a dCDN can acquire a uCDN's >>> content via more than one directly-connected uCDN. Note that >>> in a diamond configuration [=E2=80=A6] >>=20 >> Yes, I prefer this version. However, can the same =C2=AB uCDN=E2=80=99s= content =C2=BB be >> available at several uCDNs in this diamond configuration? Said = differently, >> what about the following text: >>=20 >> A =C2=AB diamond =C2=BB configuration is one where a dCDN can = acquire a given >> content via more than one directly-connected uCDN. Note that = [=E2=80=A6] >=20 > Yes, more than one uCDN will have the same content - but the important = point is that ultimately they will all have acquired it from the same = uCDN, and that uCDN owns the metadata. >=20 > I've tried to provide a better intro/explanation in new section 2.2.1 = "Multiple interconnected CDNs". Hopefully that makes it a bit clearer? Yes, as said above, section 2.2.1 is rather useful. Just a comment for this section 2.2.1, third paragraph, last sentence. = You mention both "intermediate CDN" and just after "intermediate uCDN". This is a = bit confusing. Another detail: in second paragraph you mention ""intermediate" CDN" = with extra " " around intermediate. Please harmonize. >>>> 3- With this =C2=AB diamond configuration =C2=BB, since several = uCDN can act upon the >>>> same content, what happens if they behave in a non coordinated = manner (i.e., >>>> in the general case)? For instance let=E2=80=99s imagine one of = them asks the dCDN >>>> to delete the content or cancel the initial command. What happens = if another >>>> uCDN then asks the dCDN to invalidate this content, providing the = URL of the >>>> Trigger Status Resource which (if I understand correctly) is no = longer valid? >>>> This =C2=AB diamond configuration =C2=BB can be a little bit tricky = and no clear >>>> guideline is provided in the document. >>>=20 >>> A trigger status resource belongs to one uCDN and cannot be accessed = or >>> manipulated by any other CDN, section 3 para 3 says: >>>=20 >>> Trigger Status Resources belonging to a uCDN MUST NOT >>> be visible to any other CDN. The dCDN could, for example, achieve >>> this by offering different collection URLs to each uCDN, and/or by >>> filtering the response based on the uCDN with which the HTTP client >>> is associated. >>=20 >> I see=E2=80=A6 However, if multiple uCDNs can act on the same content = (what is said), >> even if each uCDN uses a different URL, will simultaneous CI/T = commands for >> the same content be managed correctly? This is not said in section 3 >> paragraph 3 either and this is a key point. >=20 > Sorry, I'd missed your point. >=20 > Interactions can be inefficient, but are otherwise harmless because = the strongest of "invalidate" or "purge" will win, and content can = always be re-acquired if it's still available from any uCDN. >=20 > I've given some examples in new section 2.2.1 "Multiple interconnected = CDNs", and added a pointer to that from the Security Considerations = section. Once again, the examples of section 2.2.1 answer my comments. Thanks. >>> Content always originates from one uCDN, but in a diamond = configration there >>> may be multiple routes (via other CDNs) to a given dCDN. >>>=20 >>> The most common scenario may well be that the uCDN will initiate all = of the >>> CI/T commands related to its content, and those commands will simply = be >>> forwarded by intermediate CDNs. >>>=20 >>> But, there's nothing to stop an intermediate CDN initiating or = modifying >>> CI/T commands - and some modifications of the command will be = necessary >>> (for example, metadata URLs will need to be changed). >>>=20 >>> By analysis of log files it will probably be possible to work out = which >>> uCDN an individual cache in the dCDN acquired each cached resource = from. >>> But the cache is not required to keep a live record of that, and it >>> probably won't. In that case, when it receives a CI/T command to = invalidate >>> or purge content, the dCDN should apply that command to any content = it >>> may have acquired from the uCDN it got the CI/T command from. >>>=20 >>> So there is scope for a malicious intermediate CDN to cause extra = processing >>> and acquisition by a dCDN (and that's mentioned in section 8). But a >>> malicious CDN is likely to find itself removed from the CDN = federation fairly >>> quickly - there will necessarily be a level of trust between = interconnected >>> CDNs. >>>=20 >>> Would it help to spell out some of that in the draft? (The same or = very >>> similar text has been used in several of the CDNI drafts.) >>=20 >> Yes, this paragraph is worth being detailed a little bit. >>=20 >> In your explanations you mention intermediate CDNs while original = text only >> mentions directly connected uCDNs. The notion of =C2=AB intermediate = CDN =C2=BB is >> only discussed in sections 2.3 and 4.8. Since malicious intermediate = CDNs are >> part of a valid attack model, it is worth to explain it (or give a = reference to another >> document). >=20 > When a content owner, the origin, delegates delivery to a CDN it is = trusting that CDN to deliver the right content on its behalf. A = malicious CDN could deliver anything instead, but it would soon lose the = trust of the origin. >=20 > CDN-interconnection simply extends that trust to the = further-downstream CDNs acting on behalf of the original. >=20 > So establishment/enforcement of the trust relationship itself, the = contract between the origin and the CDN, is outside the scope of CDNI = and in the land of commercial agreements. Sure, I agree. > I've added a note on that in the intro to the Security Considerations = section. That's perfect. To conclude the document is okay from my point of view. Thanks for your detailed answers. Cheers, Vincent --Apple-Mail=_828F5FE5-2B44-482B-A67B-DAA632B1F4EB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Rob,

I've just posted a "-12" of the CDNI Triggers = draft, hopefully addressing these comments. Responses inline below.

I see you've = added section 2.2.1 to clarify many architectural aspects. That's quite = useful.


There are = several topics I=E2=80=99d like to discuss:

1- Concerning the use of TLS to carry CI/T traffic, I see it = is mandatory
to implement, but still optional to use (1st = sentence of Section 8.1). Is
it still reasonable in = current Internet? At a minimum I would expect a
=C2=AB = MUST support =C2=BB / =C2=AB SHOULD use =C2=BB.

Section 8.1 goes on to say ...

 [ ... description of benefits of HTTPS = ... ]

 In an environment where any = such protection is required, mutually
 authenticated = encrypted transport MUST be used to ensure
 confidentiality of the CI/T information. To that end, = TLS MUST be
 used by CI/T, including authentication = of the remote end.

... the Internet is = clearly an environment where such protection is
required, = and it'll often be used for these interfaces - we could state
that explicitly, would that address the concern?

But, CI/T could also be deployed to run over a = VPN or private network
between two interconnected CDNs, in = such an environment HTTPS transport
would not have the = same benefits.

Yes, that=E2=80=99= s my point. Say explicitly that Internet is an example of environment = where
such a protection is mandatory.

In "-12" I've aligned the text = above with the text used in the cdni-metadata draft:

 TLS MUST be used by the server-side (dCDN) and the = client-side (uCDN) of
 the CI/T interface, including = authentication of the remote end, unless
 alternate = methods are used for ensuring the confidentiality of the
 information in the CI/T interface requests and = responses (such as setting
 up an IPsec tunnel = between the two CDNs or using a physically secured
 internal network between two CDNs that are owned by the = same corporate
 entity).

I= think that covers it better (?).

This is much better. Just a minor comment: "... = for insuring the security" instead of
"... for ensuring the = confidentiality", since confidentiality is only one aspect of = security.


2- Section = 8.1, please check the paragraph =C2=AB Note that in a =C2=AB diamond = =C2=BB
configuration [=E2=80=A6] =C2=BB. This paragraph is = rather confusing to me. Confusion
comes from:
- the lack of description of the =C2=AB diamond configuration = =C2=BB. I understand
there is one dCDN on top and multiple = uCDN directly connected below, am I
right?

Yes, that's right. The draft = says:

 Note that in a "diamond" = configuration, where one uCDN's content can
 be = acquired via more than one directly-connected uCDN,

Would the following rearrangement help? ...

 A "diamond" configuration is one where a dCDN can = acquire a uCDN's
 content via more than one = directly-connected uCDN. Note that
 in a diamond = configuration [=E2=80=A6]

Yes, = I prefer this version. However, can the same =C2=AB uCDN=E2=80=99s = content =C2=BB be
available at several uCDNs in this = diamond configuration? Said differently,
what about the = following text:

A =C2=AB = diamond =C2=BB configuration is one where a dCDN can acquire a given
= content via more than one directly-connected uCDN. Note that = [=E2=80=A6]

Yes, more than one = uCDN will have the same content - but the important point is that = ultimately they will all have acquired it from the same uCDN, and that = uCDN owns the metadata.

I've tried to = provide a better intro/explanation in new section 2.2.1 "Multiple = interconnected CDNs". Hopefully that makes it a bit clearer?

Yes, as said = above, section 2.2.1 is rather useful.
Just a comment for this = section 2.2.1, third paragraph, last sentence. You = mention
both "intermediate CDN" and just after "intermediate = uCDN". This is a bit confusing.

Another detail: in second paragraph you mention = ""intermediate" CDN" with extra " "
around intermediate. = Please harmonize.


3- With this =C2=AB diamond configuration =C2=BB,= since several uCDN can act upon the
same content, what = happens if they behave in a non coordinated manner (i.e.,
in= the general case)? For instance let=E2=80=99s imagine one of them asks = the dCDN
to delete the content or cancel the initial = command. What happens if another
uCDN then asks the dCDN = to invalidate this content, providing the URL of the
Trigger= Status Resource which (if I understand correctly) is no longer = valid?
This =C2=AB diamond configuration =C2=BB can be a = little bit tricky and no clear
guideline is provided in = the document.

A trigger status = resource belongs to one uCDN and cannot be accessed or
manipulated by any other CDN, section 3 para 3 says:

 Trigger Status Resources belonging to a = uCDN MUST NOT
 be visible to any other CDN. The dCDN = could, for example, achieve
 this by offering = different collection URLs to each uCDN, and/or by
 filtering the response based on the uCDN with which the = HTTP client
 is associated.

I see=E2=80=A6 However, if = multiple uCDNs can act on the same content (what is said),
even if each uCDN uses a different URL, will simultaneous = CI/T commands for
the same content be managed correctly? = This is not said in section 3
paragraph 3 either and this = is a key point.

Sorry, I'd = missed your point.

Interactions can be = inefficient, but are otherwise harmless because the strongest of = "invalidate" or "purge" will win, and content can always be re-acquired = if it's still available from any uCDN.

I've = given some examples in new section 2.2.1 "Multiple interconnected CDNs", = and added a pointer to that from the Security Considerations section.

Once again, the = examples of section 2.2.1 answer my comments. Thanks.


Content always originates from one uCDN, but in a diamond = configration there
may be multiple routes (via other CDNs) = to a given dCDN.

The most common scenario = may well be that the uCDN will initiate all of the
CI/T = commands related to its content, and those commands will simply be
forwarded by intermediate CDNs.

But, there's nothing to stop an intermediate CDN initiating = or modifying
CI/T commands - and some modifications of the = command will be necessary
(for example, metadata URLs will = need to be changed).

By analysis of log = files it will probably be possible to work out which
uCDN = an individual cache in the dCDN acquired each cached resource from.
But the cache is not required to keep a live record of that, = and it
probably won't. In that case, when it receives a = CI/T command to invalidate
or purge content, the dCDN = should apply that command to any content it
may have = acquired from the uCDN it got the CI/T command from.

So there is scope for a malicious intermediate CDN to cause = extra processing
and acquisition by a dCDN (and that's = mentioned in section 8). But a
malicious CDN is likely to = find itself removed from the CDN federation fairly
quickly = - there will necessarily be a level of trust between interconnected
CDNs.

Would it help to spell out = some of that in the draft? (The same or very
similar text = has been used in several of the CDNI drafts.)

Yes, this paragraph is worth = being detailed a little bit.

In your = explanations you mention intermediate CDNs while original text only
mentions directly connected uCDNs. The notion of =C2=AB = intermediate CDN =C2=BB is
only discussed in sections 2.3 = and 4.8. Since malicious intermediate CDNs are
part of a = valid attack model, it is worth to explain it (or give a reference to = another
document).

When a content owner, the origin, delegates delivery to a CDN = it is trusting that CDN to deliver the right content on its behalf. A = malicious CDN could deliver anything instead, but it would soon lose the = trust of the origin.

CDN-interconnection = simply extends that trust to the further-downstream CDNs acting on = behalf of the original.

So = establishment/enforcement of the trust relationship itself, the contract = between the origin and the CDN, is outside the scope of CDNI and in the = land of commercial agreements.

Sure, I agree.


I've added a note on = that in the intro to the Security Considerations section.

That's = perfect.

To conclude = the document is okay from my point of view.

Thanks for your detailed = answers.
Cheers,

  =  Vincent
= --Apple-Mail=_828F5FE5-2B44-482B-A67B-DAA632B1F4EB-- --Apple-Mail=_060E29B6-ECD5-44E4-BC08-AB14B7CE2E8D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJW8V1iAAoJEHBYw8t72N4rFogQAK4csGPr4nCwEWqqDMW+yqyz IYG35peb2e+mBwlgP032oxsAwUJonHCvG4hG1IaYGFb9XW6EROGdW9Pl8w1HXC4a prUdC0psicvn4k/qzaM5WPbU2klHn8twVu+OmDq1Xv7F4hJ7BRRJTS8OWXAF6qbO oXIvA8+GR6dVii9dKRYllu2JX+VDdgxjQdarLx//2cI6Kk4ZmpMQHj//fcsxULMq 1Oa8k59AG8yi5TtuRKpaNWIX0TN5FOFNqaI/jhSz3+pbItKT/GNuU8f2U1YK3QRe +/h3g+0dJZxVLA4k0B3A9eyRHZI5eypR3dCL6y1i7nUC+UyNtEQkTdycdhzj9+IJ ofXhcr+wozo0tapI45ZJaROxE8kJZCYjwbpcYBJSBJggGweOI4ErtBLFx9zQYRvi bI8giPEKKZEZ061Df4gcQdO1S6IDdL5Hupv6+43L/7fDlQzB48pxfOSpdji9GMvM 94h/glE6Sf40UU7KD7Bhyunbh8oRwwLDz/0Rl6LK7qMyG62OfdL3NuXuv1wyIvNB 13Re1P+o3P6pSQdKDRLch08IJ9CIMur8tU+5ftsvSUburyPNo8mAdEKq+s5BuqG8 fXtqN7x1obAARcjAKwlmy+inribBLn8+J5vOa5y04txRRauk1MUwnuy84vBIKTg3 PU8SqIW8vON3iD5crMvA =bPMU -----END PGP SIGNATURE----- --Apple-Mail=_060E29B6-ECD5-44E4-BC08-AB14B7CE2E8D-- From nobody Thu Mar 24 10:07:48 2016 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 6EB5012D57E; Thu, 24 Mar 2016 09:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 ybyDZ-o1rBwQ; Thu, 24 Mar 2016 09:02:44 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 DFF8212D7C0; Thu, 24 Mar 2016 08:51:34 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 4A4CF27E45C1B; Thu, 24 Mar 2016 15:51:29 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u2OFpWmO028980 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 24 Mar 2016 15:51:32 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u2OFpUAk015209 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 24 Mar 2016 16:51:32 +0100 Received: from FR711WXCHMBA06.zeu.alcatel-lucent.com ([169.254.2.80]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Thu, 24 Mar 2016 16:51:30 +0100 From: "Niven - Jenkins, Ben (Nokia - GB)" To: EXT Stephen Farrell Thread-Topic: [CDNi] Stephen Farrell's Discuss on draft-ietf-cdni-redirection-17: (with DISCUSS and COMMENT) Thread-Index: AQHRgDU2phlI5zxh20WKDVCTbPGD/59orKiAgAAHo4CAABVa2Q== Date: Thu, 24 Mar 2016 15:51:29 +0000 Message-ID: <774D3FF5-A163-472A-B441-ED3CD9C50724@alcatel-lucent.com> References: <20160317101014.1026.78717.idtracker@ietfa.amsl.com> <6B22150C-4A0E-4FFF-A48C-AEA2D881632E@niven-jenkins.co.uk>, <56F40929.1020309@cs.tcd.ie> In-Reply-To: <56F40929.1020309@cs.tcd.ie> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Thu, 24 Mar 2016 10:07:46 -0700 Cc: "cdni@ietf.org" , "draft-ietf-cdni-redirection@ietf.org" , The IESG , "cdni-chairs@ietf.org" Subject: Re: [CDNi] Stephen Farrell's Discuss on draft-ietf-cdni-redirection-17: (with DISCUSS and COMMENT) X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 24 Mar 2016 16:02:51 -0000 Hi Stephen, > On 24 Mar 2016, at 15:49, EXT Stephen Farrell = wrote: >=20 >=20 > Hiya, >=20 >> On 24/03/16 15:07, Ben Niven-Jenkins wrote: >> Hi Stephen, >>=20 >>> On 17 Mar 2016, at 10:10, Stephen Farrell >>> wrote:=20 >>> ---------------------------------------------------------------------- > DISCUSS: >>> ---------------------------------------------------------------------- > The basic idea of the uCDN sending everything to the dCDN so >>> that the dCDN can reply with all the details of a request that'll >>> work (i.e. the sc-* stuff) seems broken as it requires that the >>> uCDN expose all security and privacy sensitive data to the dCDN in >>> pretty much all cases. I fail to see why that is an acceptable >>> approach. Can you point me at where the WG disucssed the issues >>> with that approach and considered less security/privacy unfriendly >>> potential alternatives? >>>=20 >>> Some examples: - section 4.1 says "SHOULD convey as much >>> information as possible" that is surely wrong - there is no reason >>> to encourage sending cookies and other security/privacy sensitive=20 >>> information and in fact sending such should be discouraged (SHOULD >>> NOT) or even, if possible, prohibited (MUST NOT). - The cs-(cookie) >>> in 4.5.1 is one specific case of sending too much. - 4.4.1 Resolver >>> IP addr is liable to be that of an end user's machine (if they >>> operate a recursive). >>>=20 >>> But the examples are just that, I'd like to DISCUSS the WG's=20 >>> consideration of the overall design first before we dive into=20 >>> those. >>=20 >> I haven=92t searched the archives. I don=92t recall lots of discussion >> around the design. The chairs may be able to shed more light. >>=20 >> My personal view is that there is a trade off between exposing >> potentially security or privacy sensitive data and the impact that >> might cause to e.g. efficiency or surrogate selection, user >> experience, etc. >>=20 >> The technology side of CDN interconnect does not operate in a vacuum >> there is also the business agreement/contractual side of such >> interconnects. Depending on your point of view and the specific >> deployment where the balance of trade-offs falls will be different >> and one may not be exposing anything one would not have exposed if >> only a single CDN was in use. >>=20 >> For example, if CDNI is used to interconnect two CDNs owned & >> operated by the same entity (e.g. a network operator using CDNI to >> interconnect CDNs from two different vendors) there is no additional >> privacy implications than if the same network operator used a single >> larger CDN. Or a dCDN may be refusing an IP address and if presented >> with a larger prefix may refuse to serve the whole prefix, leading to >> a poorer user experience because a different dCDN is used for the >> content delivery. >>=20 >> I do not feel qualified to decide where the line should be drawn. >=20 > Frankly I'm not convinced by the argument above. The draft IMO now > very clearly draws the line way way over on the commercial side, and > without seeming to consider the privacy issues much or at all. The > draft says that one SHOULD send as much as possible. >=20 > I think if we base our discussion on the text we should be able to > make better progress. Can we agree that as-is, the draft is very much > aiming to meet the commercial requirements and is not taking account > or privacy requirements? Yes I think we can agree that. Ben >=20 > S. >=20 >> The >> document provides the technical mechanics to encapsulate existing DNS >> & HTTP requests and allow interconnected CDNs to perform exactly as >> they do today when they are operating independently. From my >> non-qualified point of view I do not believe CDNI makes privacy worse >> for users compared to the single CDN use case, but if it does, that >> discussion feels like it is much wider than this particular >> document. >>=20 >>> ---------------------------------------------------------------------- > COMMENT: >>> ---------------------------------------------------------------------- > - I support Alissa's discuss points. >>=20 >> See my response just now to Alissa. >>=20 >>>=20 >>> - section 3: false-negative? don't you mean false-positive? And in >>> any case, those warnings are not false from the browser=20 >>> perspective. I'd suggest s/false-negative// >>=20 >> Good suggestion, I've removed false-negative and left it as just >> =93trigger security warnings=94 from my working copy of -18. >>=20 >>>=20 >>> - section 3: phrases like "trusted re-direction" are a bad idea - >>> you need to say who is trusting whom for what for this to be >>> meaningful and not misleading (people get misled by such phrases >>> all the time). I'd just delete the sentence or s/trusted// >>=20 >> I=92ve deleted the whole sentence from my working copy of -18 >>=20 >>>=20 >>> - 4.4.2: a JSON "string" is not the same as a DNS name is it? What >>> about i18n? (ULABEL or ALABEL?) what about odd characters allowed >>> in JSON but not in DNS names? In general the fields in this >>> dictionary (and others) seem underspecified to me. >>=20 >> I=92m afraid I=92m not an expert in JSON strings, unicode or i18n. I >> think what you=92re getting at is that a JSON string can contain more >> characters than allowed by an ALABEL or a ULABEL and we should be >> more precise in constraining the allowed characters? And that you >> think there are other fields in the document that would also benefit >> from constraining the allowable set of characters. If that=92s the case >> I=92m happy to make the edits to improve the document but I will need >> some help on what the right terminology is and the right references >> for the allowable characters. >>=20 >> Ben >=20 From nobody Thu Mar 24 10:19:34 2016 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 EFB3D12D668; Thu, 24 Mar 2016 10:19:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 hJ13iFSeCr4o; Thu, 24 Mar 2016 10:19:32 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E92F612D1D8; Thu, 24 Mar 2016 10:19:31 -0700 (PDT) X-AuditID: c618062d-f79216d00000767f-e5-56f41c0ec605 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 3B.92.30335.E0C14F65; Thu, 24 Mar 2016 17:55:43 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0248.002; Thu, 24 Mar 2016 13:19:30 -0400 From: Kevin Ma J To: Ben Niven-Jenkins , Alissa Cooper Thread-Topic: [CDNi] Alissa Cooper's Discuss on draft-ietf-cdni-redirection-17: (with DISCUSS) Thread-Index: AQHRf9rMWMdybhn2BES1wjsa5Xon5J9pAI+A///hhgA= Date: Thu, 24 Mar 2016 17:19:30 +0000 Message-ID: References: <20160316232303.13060.881.idtracker@ietfa.amsl.com> <46E278DB-B866-48E7-A698-8569D9638C20@niven-jenkins.co.uk> In-Reply-To: <46E278DB-B866-48E7-A698-8569D9638C20@niven-jenkins.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAIsWRmVeSWpSXmKPExsUyuXSPny6/zJcwg57ZzBbTz/xltFhwbgKb xZHWX4wWT2f/YbV43bmZxWLGn4nMDmweX568ZPJYsuQnk8fP65MYA5ijuGxSUnMyy1KL9O0S uDL2NrWyFRxyrph9YBJrA+MTxy5GTg4JAROJhln72CBsMYkL99YD2VwcQgJHGCX+/VzMDuEs Z5TYOnMyM0gVm4CWxOOvf5lAbBGBEInFLSfBupkFDjJKfFrB28XIwSEsEC8x66M9REmCxNJF s6DKrSRmntzCBlLCIqAqsfifK0iYV8BXon3PUUaQsJBAjcSCve4gYU4Bd4mZW5aygtiMQKd9 P7WGCWKRuMStJ/OZIE4WkFiy5zwzhC0q8fLxP1YIW0li0tJzrCAjmQU0Jdbv0odoVZSY0v2Q HWKroMTJmU9YJjCKzUIydRZCxywkHbOQdCxgZFnFyFFaXJCTm25ksIkRGE/HJNh0dzDen+55 iFGAg1GJh/eD/OcwIdbEsuLK3EOMEhzMSiK80yS/hAnxpiRWVqUW5ccXleakFh9ilOZgURLn Xf/2cpiQQHpiSWp2ampBahFMlomDU6qBUXx6RnLJSn8jYfm1paYVJS1iedtml7zs35ii5nL3 6xS/xSXqm1bc77a5kfekbJOjjh+3Zl/Oh57n9WFqXD2/Ref1L7i4LMzAPaglMqsjo9s06yfT 5azoqYGJO7cqdq85Y7BmtjBretAv01MtJamXP3VyHBQ2f6fm8kviQ5DB1qP8G3ac0tujxFKc kWioxVxUnAgAhz2UrKMCAAA= Archived-At: Cc: "cdni@ietf.org" , "draft-ietf-cdni-redirection@ietf.org" , The IESG , "cdni-chairs@ietf.org" Subject: Re: [CDNi] Alissa Cooper's Discuss on draft-ietf-cdni-redirection-17: (with DISCUSS) X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 24 Mar 2016 17:19:34 -0000 PiBGcmFuY29pcy9LZXZpbiAtIENhbiB5b3UgaGVscCBoZXJlPyBIYXMgdGhlIGRpc2N1c3Npb24g YXJvdW5kIHRoaXMgdGV4dA0KPiBmb3IgZHJhZnQtaWV0Zi1jZG5pLWxvZ2dpbmcgY29uY2x1ZGVk IHlldD8iDQoNClllcyEgIChXb29ob28hKSAgQWxsIERJU0NVU1MncyBvbiBMb2dnaW5nIGhhdmUg YmVlbiBjbGVhcmVkLCBhbmQgVHJpZ2dlcnMgaGFzIHVwZGF0ZWQgaXQncyB0ZXh0IHRvIG1hdGNo IExvZ2dpbmcuICBXZSBjYW4gZ28gYWhlYWQgYW5kIHVwZGF0ZSBSZWRpcmVjdGlvbiB0byBncmFi IHRoZSBzYW1lIHRleHQuICB0aGFueCENCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PiBGcm9tOiBCZW4gTml2ZW4tSmVua2lucyBbbWFpbHRvOmJlbkBuaXZlbi1qZW5raW5zLmNvLnVr XQ0KPiBTZW50OiBUaHVyc2RheSwgTWFyY2ggMjQsIDIwMTYgMTE6MDYgQU0NCj4gVG86IEFsaXNz YSBDb29wZXINCj4gQ2M6IFRoZSBJRVNHOyBjZG5pQGlldGYub3JnOyBkcmFmdC1pZXRmLWNkbmkt cmVkaXJlY3Rpb25AaWV0Zi5vcmc7IGNkbmktDQo+IGNoYWlyc0BpZXRmLm9yZw0KPiBTdWJqZWN0 OiBSZTogW0NETmldIEFsaXNzYSBDb29wZXIncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtY2RuaS0N Cj4gcmVkaXJlY3Rpb24tMTc6ICh3aXRoIERJU0NVU1MpDQo+IA0KPiBIaSBBbGlzc2EsDQo+IChG cmFuY29pcywgS2V2aW4sIHRoZXJlIGlzIGEgcXVlc3Rpb24gZnJvbSBBbGlzc2EgYmVsb3cgdGhh dCBJIHRoaW5rIG5lZWRzDQo+IHlvdXIgaW5wdXQgYXMgV0cgY2hhaXJzKQ0KPiANCj4gPiBPbiAx NiBNYXIgMjAxNiwgYXQgMjM6MjMsIEFsaXNzYSBDb29wZXIgPGFsaXNzYUBjb29wZXJ3LmluPiB3 cm90ZToNCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gRElTQ1VTUzoNCj4gPiAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQo+ID4NCj4gPiAoMSkNCj4gPiBUaGVyZSBpcyBzb21lIGFtYmlndWl0eSBpbiB0aGUgZG9jdW1l bnQgYWJvdXQgd2hldGhlciB0aGUgdUNETiBwYXNzZXMNCj4gdGhlDQo+ID4gSVAgYWRkcmVzcyBv ZiB0aGUgVUEgb3IgaXRzIHByZWZpeCB0byB0aGUgZENETi4gU2VjIDQuNC4xIHNheXMgdGhhdCBm b3INCj4gPiBETlMgcmVkaXJlY3Rpb24sIHRoZSB1Q0ROIHBhc3NlcyAiSVAgYWRkcmVzcyBvciBw cmVmaXgiIG9mIHRoZSBVQSwgYnV0DQo+ID4gdGhlbiBpbiB0aGUgZGVmaW5pdGlvbiBvZiByZXNv bHZlci1pcCBzcGVjaWZpZXMgaXQgb25seSBhcyB0aGUgSVANCj4gYWRkcmVzcw0KPiA+IG9mIHRo ZSBVQS4NCj4gDQo+IHJlc29sdmVyLWlwIGNvbnRhaW5zIOKAnFRoZSBJUCBhZGRyZXNzIG9mIHRo ZSBVQeKAmXMgRE5TIHJlc29sdmVyLiINCj4gDQo+IGMtc3VibmV0IGNvbnRhaW5zIHRoZSAiVGhl IElQIGFkZHJlc3MgKG9yIHByZWZpeCkgb2YgdGhlIFVBIGluIENJRFINCj4gZm9ybWF0LiINCj4g DQo+IFRoZSBpZGVhIGlzIHJlc29sdmVyLWlwIGNvbnRhaW5zIHRoZSBJUCBhZGRyZXNzIG9mIHRo ZSBETlMgcmVzb2x2ZXIgbWFraW5nDQo+IHRoZSBETlMgcmVxdWVzdCB0byB0aGUgdUNETi4gYy1z dWJuZXQgY29udGFpbnMgKGlmIHByZXNlbnQpIHRoZQ0KPiBhZGRyZXNzL3ByZWZpeCBjYXJyaWVk IGJ5IGRyYWZ0LWlldGYtZG5zb3AtZWRucy1jbGllbnQtc3VibmV0Lg0KPiANCj4gPiBUaGVuIGlu IFNlYyA0LjUuMSBmb3IgSFRUUCByZWRpcmVjdGlvbiB0aGUgZXF1aXZhbGVudCBmaWVsZCBpcw0K PiA+IHNwZWNpZmllZCBhcyB0aGUgSVAgYWRkcmVzcyBvZiB0aGUgVUEgYW5kIHRoZSBwb3NzaWJp bGl0eSBvZiBzZW5kaW5nDQo+IG9ubHkNCj4gPiBhIHByZWZpeCBpcyBub3QgbWVudGlvbmVkLg0K PiANCj4gVGhhdCBpcyBiZWNhdXNlIHdpdGggSFRUUCB0aGUgVUEgY29ubmVjdHMgZGlyZWN0bHkg dG8gdGhlIHVDRE4gYW5kIHRoZQ0KPiB1Q0ROIGNhbiBzZWUgdGhlIFVB4oCZcyBJUCBhZGRyZXNz Lg0KPiANCj4gPiBUaGVuIDUuMiBoYXMgdGhlIHBhcmEgdGhhdCBiZWdpbnMgIldoaWxlIGl0IGlz DQo+ID4gdGVjaG5pY2FsbHkgcG9zc2libGUgdG8gbWFzayBzb21lIGluZm9ybWF0aW9uIGluIHRo ZSBSSSBSZXF1ZXN0LCBzdWNoIGFzDQo+ID4gdGhlIGxhc3QgYml0cyBvZiB0aGUgVUEgSVAgYWRk cmVzcyAuLi4iIHdoaWNoIG1ha2VzIGl0IHNlZW0gbGlrZQ0KPiBwcmVmaXhlcw0KPiA+IHJlYWxs eSBzaG91bGRuJ3QgYmUgc2VudC4NCj4gDQo+IFdoYXQgd2UgaGF2ZSBwcm92aWRlZCBpcyB0aGUg YWJpbGl0eSBmb3IgdGhlIENETkkgUmVkaXJlY3Rpb24gSW50ZXJmYWNlIHRvDQo+IGVuY29kZSB0 aGUgcHJvcGVydGllcyBvZiB0aGUgc291cmNlIChETlMgb3IgSFRUUCkgcmVxdWVzdHMgc28gdGhh dCB1Q0ROcyAmDQo+IGRDRE5zIGNhbiBtYWtlIHRoZSBiZXN0IGRDRE4gJiBzdXJyb2dhdGUgc2Vs ZWN0aW9uIGRlY2lzaW9ucyB0aGF0IHRoZXkNCj4gY2FuLiBXZeKAmXJlIG5vdCBzdWdnZXN0aW5n IG9yIG1hbmRhdGluZyBhbnkgYWRkaXRpb25hbCBJUCBhZGRyZXNzIG1hc2tpbmcNCj4gYmVoYXZp b3VyIHRoYW4gdGhhdCBwcm92aWRlZCAob3Igbm90IHByb3ZpZGVkKSBieSB0aGUgc291cmNlIHBy b3RvY29sLg0KPiBUaGlzIG1heSBiZSB0aGUgc291cmNlIG9mIHRoZSBjb25mdXNpb24gLSB3ZeKA mXJlIG5vdCBzYXlpbmcg4oCceW91IHNob3VsZA0KPiBtYXNrIHRoZSBJUCBhZGRyZXNzIGJlaGlu ZCBhIHByZWZpeCBhbmQgdGhpcyBpcyBob3cgdG8gZG8gaXTigJ0gYW5kIHRoZW4NCj4gYmVpbmcg aW5jb25zaXN0ZW50IGFib3V0IGFwcGx5aW5nIGl0IHRvIEROUyB2cyBIVFRQLCB3ZeKAmXJlIHNh eWluZyDigJxoZXJl4oCZcw0KPiBob3cgdG8gZW5jYXBzdWxhdGUgYSBETlMgb3IgSFRUUCByZXF1 ZXN0IGludG8gb3VyIHByb3RvY29s4oCdLg0KPiANCj4gPg0KPiA+IEkgdGhpbmsgdGhlIGRvY3Vt ZW50IG5lZWRzIHNvbWUgY29uc2lzdGVuY3kgYW5kIGNsYXJpdHkgaGVyZSBhYm91dA0KPiA+IHdo ZXRoZXIgcHJlZml4ZXMgYXJlIGV4cGVjdGVkIHRvIGJlIHVzZWQgZm9yIGVpdGhlciByZWRpcmVj dGlvbiBtZXRob2QuDQo+IA0KPiBEb2VzIHRoZSBhYm92ZSBleHBsYW5hdGlvbiBjaGFuZ2UgdGhp cyB2aWV3PyBPciBjaGFuZ2UgdGhlIHRleHQgeW91IHdvdWxkDQo+IGxpa2UgdG8gc2VlIHRoYXQg cHJvdmlkZXMgdGhhdCBjbGFyaXR5Pw0KPiANCj4gPiBJdCdzIGFsc28gbm90IG9idmlvdXMgdG8g bWUgd2h5IHRoZSBkb2N1bWVudCBzaG91bGRuJ3QgcmVjb21tZW5kIHRvDQo+IHVDRE5zDQo+ID4g dGhhdCBpZiB0aGV5IGFyZSBwb2xsaW5nIG11bHRpcGxlIGNhbmRpZGF0ZSBkQ0ROcyBhcyBkZXNj cmliZWQgaW4gU2VjDQo+ID4gNS4yLCB0aGV5IHNob3VsZCB1c2Ugb25seSBhIHByZWZpeCBmb3Ig c3VjaCByZXF1ZXN0cy4gVGhlIGFyZ3VtZW50cw0KPiBnaXZlbg0KPiA+IGFnYWluc3QgdGhpcyBz ZWVtIHByZXR0eSB0aGluIC0tIGlzbid0IHByZXZlbnRpbmcgY29ycmVsYXRpb24gb2YNCj4gbXVs dGlwbGUNCj4gPiByZXF1ZXN0cyB0byBhIHNpbmdsZSBVQSBhIGdvb2QgdGhpbmcsIGVzcGVjaWFs bHkgd2hlbiBpdCdzIGJlaW5nIGRvbmUgYnkNCj4gPiBhIGJ1bmNoIG9mIGRDRE5zPyBBbmQgSSBk b24ndCB1bmRlcnN0YW5kIHRoZSBDR04gZXhhbXBsZSAtLSBpc24ndCB0aGUNCj4gPiByb290IG9m IHRoZSBwcm9ibGVtIGhlcmUgdGhhdCB0b3BvbG9naWNhbGx5IGRpc3BlcnNlZCBVQXMgYXJlIHNo YXJpbmcNCj4gdGhlDQo+ID4gc2FtZSBwdWJsaWMtZmFjaW5nIElQIGFkZHJlc3MsIGluIHdoaWNo IGNhc2UgdGhlIGRDRE4gbWF5IGhhdmUgdGhlIHNhbWUNCj4gPiBwcm9ibGVtIHdoZW4gcGFzc2Vk IGEgZnVsbCBJUCBhZGRyZXNzIGFzIGl0IGRvZXMgYSBwcmVmaXg/DQo+IA0KPiBXZSBkZXNjcmli ZSBob3cgdG8gZW5jYXBzdWxhdGUgRE5TICYgSFRUUCByZXF1ZXN0cyBpbiB0aGUgUkkgcHJvdG9j b2wgYW5kDQo+IHdlIGRpc2N1c3MgdGhhdCBpbiBzb21lIGNpcmN1bXN0YW5jZXMgaXQgbWF5IHBy b3ZpZGUgaW5mb3JtYXRpb24gdG8gYSBkQ0RODQo+IHRoYXQgdGhleSB3b3VsZCBub3Qgb3RoZXJ3 aXNlIGhhdmUgZ290IGFuZCB0aGF0IG1hc2tpbmcgSVAgYWRkcmVzc2VzIGFsc28NCj4gaGFzIGRv d25zaWRlcy4NCj4gDQo+IFdlIGRvIG5vdCBwcm92aWRlIGFueSBwcml2YWN5IGVuaGFuY2luZyBu b3JtYXRpdmUgYmVoYXZpb3VyIGFuZCB3ZSBkbyBub3QNCj4gbWFrZSBhIHZhbHVlIGp1ZGdlbWVu dCBvbiB3aGV0aGVyIGFueSBwb3NzaWJsZSByZWR1Y3Rpb24gaW4gcHJpdmFjeSBpcw0KPiBtb3Jl IGltcG9ydGFudCB0aGFuIHRoZSBkb3duc2lkZXMgb2YgcHJvdmlkaW5nIHRoYXQgcmVkdWN0aW9u IGluIHByaXZhY3kuDQo+IA0KPiBUaGUgc3BlY2lmaWMgZXhhbXBsZSBvZiBDR04gbWF5IG5vdCBi ZSB0aGUgYmVzdCBleGFtcGxlIGZvciB1cyB0byBoYXZlDQo+IHVzZWQuIFRoZSBnZW5lcmFsIHBv aW50IGlzIHRoYXQgZENETnMgcGVyZm9ybSBzdXJyb2dhdGUgc2VsZWN0aW9uIHVzaW5nIFVBDQo+ IElQIGFkZHJlc3MgKG9yIHRoZSBjbG9zZXN0IHByb3h5IHRoZXkgY2FuIGdldCwgZS5nLiB0aGUg VUHigJlzIEROUw0KPiByZXNvbHZlcuKAmXMgSVAgYWRkcmVzcykgYW5kIHRoYXQgbWFza2luZyB0 aGUgVUEgSVAgYWRkcmVzcyB0aGVyZWZvcmUgbWVhbnMNCj4gZENETnMgbWF5IG1ha2UgbGVzcyBv cHRpbXVtIGRlY2lzaW9ucyBhbmQgdGhhdCBpcyBhIGRvd25zaWRlLg0KPiANCj4gTWF5YmUgd2Xi gJlkIGJlIGJldHRlciBqdXN0IHNheWluZyB0aGF0IHJhdGhlciB0aGFuIHRyeWluZyB0byBwcm92 aWRlDQo+IHNwZWNpZmljIHNjZW5hcmlvcyB0aGF0IHNheSB0aGF0IGJ5IGluZmVyZW5jZT8NCj4g DQo+ID4NCj4gPiAoMikNCj4gPiBCZW4gbm90ZWQgdGhlIHdlYWtuZXNzIG9mIHRoZSByZWNvbW1l bmRhdGlvbiBpbiA1LjEgcmVnYXJkaW5nIFRMUy4gSSBzZWUNCj4gPiB0aGF0IHRoZSBsYW5ndWFn ZSBoZXJlIGlzIHRoZSBzYW1lIGFzIGl0IGlzIGluDQo+ID4gZHJhZnQtaWV0Zi1jZG5pLWxvZ2dp bmctMjIuIEJ1dCBJIHRob3VnaHQgdGhlIGFncmVlbWVudCBvbiB0aGF0IGRvY3VtZW50DQo+ID4g d2FzIE1VU1QgdXNlIFRMUywgZnVsbCBzdG9wLiBTbyB0aGVyZSBpcyBhbWJpZ3VpdHkgaW4gYm90 aCBkb2N1bWVudHMgSQ0KPiA+IHRoaW5rLiAiSW4gYW4gZW52aXJvbm1lbnQgd2hlcmUgLi4uIiBh bmQgIldoZW4gVExTIGlzIHVzZWQgLi4uIiBzZWVtDQo+ID4gaW5jb25zaXN0ZW50IHdpdGggIlRM UyBNVVNUIGJlIHVzZWQgLi4uLiIgSSdtIGhhcHB5IHRvIGNsZWFyIG9uIHRoaXMgaWYNCj4gPiBJ J20gbWlzc2luZyBzb21ldGhpbmcgZnJvbSB0aGUgcHJldmlvdXMgZGlzY3Vzc2lvbiwgd2hpY2gg SSB0aGluaw0KPiA+IGhhcHBlbmVkIHdoZW4gSSB3YXMgb24gbGVhdmUgYW5kIHJlc3VsdGVkIGZy b20gb25lIG9mIFN0ZXBoZW4ncyBiYWxsb3RzLg0KPiANCj4gV2hhdCBJIHJlcGxpZWQgdG8gQmVu 4oCmIlRoZXJlIGhhcyBiZWVuIHF1aXRlIGEgYml0IG9mIGRpc2N1c3Npb24gaW4gdGhlDQo+IENE TkkgV0cgYXJvdW5kIHRoaXMgd29yZGluZyBhbmQgdGhlIFdHIGRlY2lkZWQgdG8gYWxpZ24gdGhl IHdvcmRpbmcgaXQNCj4gdXNlZCBhY3Jvc3MgYWxsIGl0cyBkb2N1bWVudHMuIFRoZSBmaXJzdCBk b2N1bWVudCB0byBwcm9ncmVzcyB0byBJRVNHIHdhcw0KPiBkcmFmdC1pZXRmLWNkbmktbG9nZ2lu ZyBhbmQgdGhlIG90aGVyIENETkkgZHJhZnRzIChpbmNsdWRpbmcgdGhlDQo+IHJlZGlyZWN0aW9u IG9uZSB3ZSBhcmUgZGlzY3Vzc2luZykgdXNlIHRoZSBzYW1lIHdvcmRpbmcgYXMgZHJhZnQtaWV0 Zi0NCj4gY2RuaS1sb2dnaW5nLg0KPiANCj4gSeKAmW0gaGFwcHkgdG8gY29udGludWUgdG8gYWxp Z24gdGhlIHdvcmRpbmcgaW4gdGhpcyBkb2N1bWVudCB3aXRoIHRoYXQgaW4NCj4gZHJhZnQtaWV0 Zi1jZG5pLWxvZ2dpbmcsIGJ1dCBJIHdvdWxkIHN1Z2dlc3Qgd2UgYXZvaWQgcmVwZWF0aW5nIHRo ZSBzYW1lDQo+IGRpc2N1c3Npb24gdGhhdCBpcyBoYXBwZW5pbmcgYXJvdW5kIGRyYWZ0LWlldGYt Y2RuaS1sb2dnaW5nIGhlcmUuDQo+IA0KPiBGcmFuY29pcy9LZXZpbiAtIENhbiB5b3UgaGVscCBo ZXJlPyBIYXMgdGhlIGRpc2N1c3Npb24gYXJvdW5kIHRoaXMgdGV4dA0KPiBmb3IgZHJhZnQtaWV0 Zi1jZG5pLWxvZ2dpbmcgY29uY2x1ZGVkIHlldD8iDQo+IA0KPiBCZW4NCg0K From nobody Thu Mar 24 10:35:02 2016 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 5C11F12D6F8; Thu, 24 Mar 2016 10:35:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001] 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 UiHFB4TVYgNJ; Thu, 24 Mar 2016 10:34:59 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.143]) by ietfa.amsl.com (Postfix) with ESMTP id 25BE812D6C1; Thu, 24 Mar 2016 10:34:57 -0700 (PDT) Received: from dab-rcn1-h-2-3.dab.02.net ([82.132.245.56] helo=[10.9.89.198]) by smtp04.mailcore.me with esmtpa (Exim 4.80.1) (envelope-from ) id 1aj99r-000786-M8; Thu, 24 Mar 2016 17:34:56 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Ben Niven-Jenkins X-Mailer: iPhone Mail (13C75) In-Reply-To: Date: Thu, 24 Mar 2016 17:34:50 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160316232303.13060.881.idtracker@ietfa.amsl.com> <46E278DB-B866-48E7-A698-8569D9638C20@niven-jenkins.co.uk> To: Kevin Ma J X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Archived-At: Cc: "draft-ietf-cdni-redirection@ietf.org" , "cdni@ietf.org" , The IESG , "cdni-chairs@ietf.org" Subject: Re: [CDNi] Alissa Cooper's Discuss on draft-ietf-cdni-redirection-17: (with DISCUSS) X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 24 Mar 2016 17:35:01 -0000 Kevin, On 24 Mar 2016, at 17:19, Kevin Ma J wrote: >> Francois/Kevin - Can you help here? Has the discussion around this text >> for draft-ietf-cdni-logging concluded yet?" >=20 > Yes! (Woohoo!) All DISCUSS's on Logging have been cleared, and Triggers h= as updated it's text to match Logging. We can go ahead and update Redirecti= on to grab the same text. thanx! =46rom what I can tell redirection-17 has the same text as logging-22 which h= as different text to triggers-12. Which text should I use in redirection-18?= Thanks Ben >=20 >> -----Original Message----- >> From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] >> Sent: Thursday, March 24, 2016 11:06 AM >> To: Alissa Cooper >> Cc: The IESG; cdni@ietf.org; draft-ietf-cdni-redirection@ietf.org; cdni- >> chairs@ietf.org >> Subject: Re: [CDNi] Alissa Cooper's Discuss on draft-ietf-cdni- >> redirection-17: (with DISCUSS) >>=20 >> Hi Alissa, >> (Francois, Kevin, there is a question from Alissa below that I think need= s >> your input as WG chairs) >>=20 >>> On 16 Mar 2016, at 23:23, Alissa Cooper wrote: >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>>=20 >>> (1) >>> There is some ambiguity in the document about whether the uCDN passes >> the >>> IP address of the UA or its prefix to the dCDN. Sec 4.4.1 says that for >>> DNS redirection, the uCDN passes "IP address or prefix" of the UA, but >>> then in the definition of resolver-ip specifies it only as the IP >> address >>> of the UA. >>=20 >> resolver-ip contains =E2=80=9CThe IP address of the UA=E2=80=99s DNS reso= lver." >>=20 >> c-subnet contains the "The IP address (or prefix) of the UA in CIDR >> format." >>=20 >> The idea is resolver-ip contains the IP address of the DNS resolver makin= g >> the DNS request to the uCDN. c-subnet contains (if present) the >> address/prefix carried by draft-ietf-dnsop-edns-client-subnet. >>=20 >>> Then in Sec 4.5.1 for HTTP redirection the equivalent field is >>> specified as the IP address of the UA and the possibility of sending >> only >>> a prefix is not mentioned. >>=20 >> That is because with HTTP the UA connects directly to the uCDN and the >> uCDN can see the UA=E2=80=99s IP address. >>=20 >>> Then 5.2 has the para that begins "While it is >>> technically possible to mask some information in the RI Request, such as= >>> the last bits of the UA IP address ..." which makes it seem like >> prefixes >>> really shouldn't be sent. >>=20 >> What we have provided is the ability for the CDNI Redirection Interface t= o >> encode the properties of the source (DNS or HTTP) requests so that uCDNs &= >> dCDNs can make the best dCDN & surrogate selection decisions that they >> can. We=E2=80=99re not suggesting or mandating any additional IP address m= asking >> behaviour than that provided (or not provided) by the source protocol. >> This may be the source of the confusion - we=E2=80=99re not saying =E2=80= =9Cyou should >> mask the IP address behind a prefix and this is how to do it=E2=80=9D and= then >> being inconsistent about applying it to DNS vs HTTP, we=E2=80=99re saying= =E2=80=9Chere=E2=80=99s >> how to encapsulate a DNS or HTTP request into our protocol=E2=80=9D. >>=20 >>>=20 >>> I think the document needs some consistency and clarity here about >>> whether prefixes are expected to be used for either redirection method. >>=20 >> Does the above explanation change this view? Or change the text you would= >> like to see that provides that clarity? >>=20 >>> It's also not obvious to me why the document shouldn't recommend to >> uCDNs >>> that if they are polling multiple candidate dCDNs as described in Sec >>> 5.2, they should use only a prefix for such requests. The arguments >> given >>> against this seem pretty thin -- isn't preventing correlation of >> multiple >>> requests to a single UA a good thing, especially when it's being done by= >>> a bunch of dCDNs? And I don't understand the CGN example -- isn't the >>> root of the problem here that topologically dispersed UAs are sharing >> the >>> same public-facing IP address, in which case the dCDN may have the same >>> problem when passed a full IP address as it does a prefix? >>=20 >> We describe how to encapsulate DNS & HTTP requests in the RI protocol and= >> we discuss that in some circumstances it may provide information to a dCD= N >> that they would not otherwise have got and that masking IP addresses also= >> has downsides. >>=20 >> We do not provide any privacy enhancing normative behaviour and we do not= >> make a value judgement on whether any possible reduction in privacy is >> more important than the downsides of providing that reduction in privacy.= >>=20 >> The specific example of CGN may not be the best example for us to have >> used. The general point is that dCDNs perform surrogate selection using U= A >> IP address (or the closest proxy they can get, e.g. the UA=E2=80=99s DNS >> resolver=E2=80=99s IP address) and that masking the UA IP address therefo= re means >> dCDNs may make less optimum decisions and that is a downside. >>=20 >> Maybe we=E2=80=99d be better just saying that rather than trying to provi= de >> specific scenarios that say that by inference? >>=20 >>>=20 >>> (2) >>> Ben noted the weakness of the recommendation in 5.1 regarding TLS. I see= >>> that the language here is the same as it is in >>> draft-ietf-cdni-logging-22. But I thought the agreement on that document= >>> was MUST use TLS, full stop. So there is ambiguity in both documents I >>> think. "In an environment where ..." and "When TLS is used ..." seem >>> inconsistent with "TLS MUST be used ...." I'm happy to clear on this if >>> I'm missing something from the previous discussion, which I think >>> happened when I was on leave and resulted from one of Stephen's ballots.= >>=20 >> What I replied to Ben=E2=80=A6"There has been quite a bit of discussion i= n the >> CDNI WG around this wording and the WG decided to align the wording it >> used across all its documents. The first document to progress to IESG was= >> draft-ietf-cdni-logging and the other CDNI drafts (including the >> redirection one we are discussing) use the same wording as draft-ietf- >> cdni-logging. >>=20 >> I=E2=80=99m happy to continue to align the wording in this document with t= hat in >> draft-ietf-cdni-logging, but I would suggest we avoid repeating the same >> discussion that is happening around draft-ietf-cdni-logging here. >>=20 >> Francois/Kevin - Can you help here? Has the discussion around this text >> for draft-ietf-cdni-logging concluded yet?" >>=20 >> Ben >=20 From nobody Thu Mar 24 10:47:42 2016 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 6119712D663; Thu, 24 Mar 2016 10:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] 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 zQFllK5l3pon; Thu, 24 Mar 2016 10:47:34 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D683312D5DE; Thu, 24 Mar 2016 10:47:33 -0700 (PDT) X-AuditID: c6180641-f79fa6d0000057a9-67-56f42812aa02 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 58.44.22441.21824F65; Thu, 24 Mar 2016 18:46:58 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0248.002; Thu, 24 Mar 2016 13:47:32 -0400 From: Kevin Ma J To: Ben Niven-Jenkins Thread-Topic: [CDNi] Alissa Cooper's Discuss on draft-ietf-cdni-redirection-17: (with DISCUSS) Thread-Index: AQHRf9rMWMdybhn2BES1wjsa5Xon5J9pAI+A///hhgCAAEgyAP//vWNw Date: Thu, 24 Mar 2016 17:47:30 +0000 Message-ID: References: <20160316232303.13060.881.idtracker@ietfa.amsl.com> <46E278DB-B866-48E7-A698-8569D9638C20@niven-jenkins.co.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMIsWRmVeSWpSXmKPExsUyuXRPlK6Qxpcwg6n9lhbTz/xltFhwbgKb xZHWX4wWT2f/YbV43bmZxWLGn4nMDmweX568ZPJYsuQnk8fP65MYA5ijuGxSUnMyy1KL9O0S uDK+3dnMUnAhsuLK/wMsDYwrwrsYOTkkBEwkpjy4ywphi0lcuLeerYuRi0NI4AijxIf9T5gh nOWMEoe/tbOAVLEJaEk8/vqXqYuRg0NEQF+i41gxSA2zwBNGiRPNnWBxYYF4iVkf7UHKRQQS JJYumsUEYbtJrLj0EGwZi4CqxN9708BsXgFfiYVXXkLt+ssocXLPbLAEp4C7xOn+iWB7GYGu +35qDdggZgFxiVtP5jNBXC0gsWTPeWYIW1Ti5eN/UN8oSUxaeo4V5B5mAU2J9bv0IVoVJaZ0 P2SH2CsocXLmE5YJjGKzkEydhdAxC0nHLCQdCxhZVjFylBYX5OSmGxluYgRG1TEJNscdjHt7 PQ8xCnAwKvHwfpD/HCbEmlhWXJl7iFGCg1lJhFdO8UuYEG9KYmVValF+fFFpTmrxIUZpDhYl cd5vHy+HCQmkJ5akZqemFqQWwWSZODilGhhLZ0cx7i5Jzgn/I8Strnh8z1NZ17Su/fNSb4jH 3Vyo87T/SaZd+pd73VzLTlnONQm8XpS2Jl6g6UQHgyvrp8J2T8N7PBGFL2TOF229Gblzz+ZM 5rnbebpY3f0838duP/bzQtOaHpV3s89mqfV/2zzNdt6ldqvMtM5dSSIizF2p0wqzxdh3flRi Kc5INNRiLipOBACKCQ7xpgIAAA== Archived-At: Cc: "draft-ietf-cdni-redirection@ietf.org" , "cdni@ietf.org" , The IESG , "cdni-chairs@ietf.org" Subject: Re: [CDNi] Alissa Cooper's Discuss on draft-ietf-cdni-redirection-17: (with DISCUSS) X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 24 Mar 2016 17:47:36 -0000 SGkgQmVuLA0KDQogIEknbSBsb29raW5nIGF0IHRoZSB0ZXh0IGluIDcuMSBvZiBsb2dnaW5nLTIz IGFuZCA4LjEgb2YgdHJpZ2dlcnMtMTIuICBUaGV5IGFyZSB3b3JkZWQgYSBsaXR0bGUgZGlmZmVy ZW50bHksIGJ1dCBJIHRoaW5rIHRoZSBnaXN0IG9mIGl0IGlzOg0KDQogICBBIENJL1QgaW1wbGVt ZW50YXRpb24gTVVTVCBzdXBwb3J0IFRMUyB0cmFuc3BvcnQgZm9yIEhUVFAgKGh0dHBzKSBhcw0K ICAgcGVyIFtSRkMyODE4XSBhbmQgW1JGQzcyMzBdLg0KDQogICBbdHJpZ2dlcnMgaGFzIGEgTVVT VCBzdGF0ZW1lbnQgaGVyZSBhYm91dCAiYXV0aGVudGljYXRpb24gb2YgdGhlIHJlbW90ZSBlbmQi OyBsb2dnaW5nJ3MgaXMgYmVsb3ddDQoNCiAgIFRoZSB1c2Ugb2YgVExTIGZvciB0cmFuc3BvcnQg b2YgdGhlIENJL1QgaW50ZXJmYWNlIGFsbG93czoNCg0KICAgbyAgW2RDRE4gYW5kIHVDRE4gdG8g YXV0aGVudGljYXRlIGVhY2ggb3RoZXJdLg0KDQogICBBbmQsIG9uY2UgdGhleSBoYXZlIG11dHVh bGx5IGF1dGhlbnRpY2F0ZWQgZWFjaCBvdGhlciwgaXQgYWxsb3dzOg0KDQogICBvICBUaGUgZENE TiBhbmQgdGhlIHVDRE4gdG8gYXV0aG9yaXplIGVhY2ggb3RoZXIgW2ZvciBpbnRlcmZhY2Ugc3Bl Y2lmaWMgcHVycG9zZV0uDQoNCiAgIG8gIFtpbnRlcmZhY2Ugc3BlY2lmaWMgc3R1ZmZdIHRvIGJl IHRyYW5zbWl0dGVkIHdpdGgNCiAgICAgIGNvbmZpZGVudGlhbGl0eS4NCg0KICAgbyAgUHJvdGVj dGlvbiBvZiB0aGUgaW50ZWdyaXR5IG9mIFtpbnRlcmZhY2Ugc3BlY2lmaWMgc3R1ZmZdLg0KDQog ICBXaGVuIFRMUyBpcyB1c2VkLCB0aGUgZ2VuZXJhbCBUTFMgdXNhZ2UgZ3VpZGFuY2UgaW4gW1JG Qzc1MjVdIE1VU1QgYmUNCiAgIGZvbGxvd2VkLg0KDQogICBbbG9nZ2luZyBoYXMgYSBNVVNUIHN0 YXRlbWVudCBoZXJlIGFib3V0ICJhdXRoZW50aWNhdGlvbiBvZiB0aGUgcmVtb3RlIGVuZCJdDQoN CnRoYW54Lg0KDQotLSAgS2V2aW4gSi4gTWENCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiBGcm9tOiBCZW4gTml2ZW4tSmVua2lucyBbbWFpbHRvOmJlbkBuaXZlbi1qZW5raW5zLmNv LnVrXQ0KPiBTZW50OiBUaHVyc2RheSwgTWFyY2ggMjQsIDIwMTYgMTozNSBQTQ0KPiBUbzogS2V2 aW4gTWEgSg0KPiBDYzogQWxpc3NhIENvb3BlcjsgVGhlIElFU0c7IGNkbmlAaWV0Zi5vcmc7IGRy YWZ0LWlldGYtY2RuaS0NCj4gcmVkaXJlY3Rpb25AaWV0Zi5vcmc7IGNkbmktY2hhaXJzQGlldGYu b3JnDQo+IFN1YmplY3Q6IFJlOiBbQ0ROaV0gQWxpc3NhIENvb3BlcidzIERpc2N1c3Mgb24gZHJh ZnQtaWV0Zi1jZG5pLQ0KPiByZWRpcmVjdGlvbi0xNzogKHdpdGggRElTQ1VTUykNCj4gDQo+IEtl dmluLA0KPiANCj4gT24gMjQgTWFyIDIwMTYsIGF0IDE3OjE5LCBLZXZpbiBNYSBKIDxrZXZpbi5q Lm1hQGVyaWNzc29uLmNvbT4gd3JvdGU6DQo+IA0KPiA+PiBGcmFuY29pcy9LZXZpbiAtIENhbiB5 b3UgaGVscCBoZXJlPyBIYXMgdGhlIGRpc2N1c3Npb24gYXJvdW5kIHRoaXMgdGV4dA0KPiA+PiBm b3IgZHJhZnQtaWV0Zi1jZG5pLWxvZ2dpbmcgY29uY2x1ZGVkIHlldD8iDQo+ID4NCj4gPiBZZXMh ICAoV29vaG9vISkgIEFsbCBESVNDVVNTJ3Mgb24gTG9nZ2luZyBoYXZlIGJlZW4gY2xlYXJlZCwg YW5kDQo+IFRyaWdnZXJzIGhhcyB1cGRhdGVkIGl0J3MgdGV4dCB0byBtYXRjaCBMb2dnaW5nLiAg V2UgY2FuIGdvIGFoZWFkIGFuZA0KPiB1cGRhdGUgUmVkaXJlY3Rpb24gdG8gZ3JhYiB0aGUgc2Ft ZSB0ZXh0LiAgdGhhbnghDQo+IA0KPiBGcm9tIHdoYXQgSSBjYW4gdGVsbCByZWRpcmVjdGlvbi0x NyBoYXMgdGhlIHNhbWUgdGV4dCBhcyBsb2dnaW5nLTIyIHdoaWNoDQo+IGhhcyBkaWZmZXJlbnQg dGV4dCB0byB0cmlnZ2Vycy0xMi4gV2hpY2ggdGV4dCBzaG91bGQgSSB1c2UgaW4gcmVkaXJlY3Rp b24tDQo+IDE4Pw0KPiANCj4gVGhhbmtzDQo+IEJlbg0KPiANCj4gPg0KPiA+PiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBCZW4gTml2ZW4tSmVua2lucyBbbWFpbHRvOmJl bkBuaXZlbi1qZW5raW5zLmNvLnVrXQ0KPiA+PiBTZW50OiBUaHVyc2RheSwgTWFyY2ggMjQsIDIw MTYgMTE6MDYgQU0NCj4gPj4gVG86IEFsaXNzYSBDb29wZXINCj4gPj4gQ2M6IFRoZSBJRVNHOyBj ZG5pQGlldGYub3JnOyBkcmFmdC1pZXRmLWNkbmktcmVkaXJlY3Rpb25AaWV0Zi5vcmc7DQo+IGNk bmktDQo+ID4+IGNoYWlyc0BpZXRmLm9yZw0KPiA+PiBTdWJqZWN0OiBSZTogW0NETmldIEFsaXNz YSBDb29wZXIncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtY2RuaS0NCj4gPj4gcmVkaXJlY3Rpb24t MTc6ICh3aXRoIERJU0NVU1MpDQo+ID4+DQo+ID4+IEhpIEFsaXNzYSwNCj4gPj4gKEZyYW5jb2lz LCBLZXZpbiwgdGhlcmUgaXMgYSBxdWVzdGlvbiBmcm9tIEFsaXNzYSBiZWxvdyB0aGF0IEkgdGhp bmsNCj4gbmVlZHMNCj4gPj4geW91ciBpbnB1dCBhcyBXRyBjaGFpcnMpDQo+ID4+DQo+ID4+PiBP biAxNiBNYXIgMjAxNiwgYXQgMjM6MjMsIEFsaXNzYSBDb29wZXIgPGFsaXNzYUBjb29wZXJ3Lmlu PiB3cm90ZToNCj4gPj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPj4+IERJU0NVU1M6DQo+ID4+PiAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQo+ID4+Pg0KPiA+Pj4gKDEpDQo+ID4+PiBUaGVyZSBpcyBzb21lIGFtYmlndWl0 eSBpbiB0aGUgZG9jdW1lbnQgYWJvdXQgd2hldGhlciB0aGUgdUNETiBwYXNzZXMNCj4gPj4gdGhl DQo+ID4+PiBJUCBhZGRyZXNzIG9mIHRoZSBVQSBvciBpdHMgcHJlZml4IHRvIHRoZSBkQ0ROLiBT ZWMgNC40LjEgc2F5cyB0aGF0DQo+IGZvcg0KPiA+Pj4gRE5TIHJlZGlyZWN0aW9uLCB0aGUgdUNE TiBwYXNzZXMgIklQIGFkZHJlc3Mgb3IgcHJlZml4IiBvZiB0aGUgVUEsIGJ1dA0KPiA+Pj4gdGhl biBpbiB0aGUgZGVmaW5pdGlvbiBvZiByZXNvbHZlci1pcCBzcGVjaWZpZXMgaXQgb25seSBhcyB0 aGUgSVANCj4gPj4gYWRkcmVzcw0KPiA+Pj4gb2YgdGhlIFVBLg0KPiA+Pg0KPiA+PiByZXNvbHZl ci1pcCBjb250YWlucyDigJxUaGUgSVAgYWRkcmVzcyBvZiB0aGUgVUHigJlzIEROUyByZXNvbHZl ci4iDQo+ID4+DQo+ID4+IGMtc3VibmV0IGNvbnRhaW5zIHRoZSAiVGhlIElQIGFkZHJlc3MgKG9y IHByZWZpeCkgb2YgdGhlIFVBIGluIENJRFINCj4gPj4gZm9ybWF0LiINCj4gPj4NCj4gPj4gVGhl IGlkZWEgaXMgcmVzb2x2ZXItaXAgY29udGFpbnMgdGhlIElQIGFkZHJlc3Mgb2YgdGhlIEROUyBy ZXNvbHZlcg0KPiBtYWtpbmcNCj4gPj4gdGhlIEROUyByZXF1ZXN0IHRvIHRoZSB1Q0ROLiBjLXN1 Ym5ldCBjb250YWlucyAoaWYgcHJlc2VudCkgdGhlDQo+ID4+IGFkZHJlc3MvcHJlZml4IGNhcnJp ZWQgYnkgZHJhZnQtaWV0Zi1kbnNvcC1lZG5zLWNsaWVudC1zdWJuZXQuDQo+ID4+DQo+ID4+PiBU aGVuIGluIFNlYyA0LjUuMSBmb3IgSFRUUCByZWRpcmVjdGlvbiB0aGUgZXF1aXZhbGVudCBmaWVs ZCBpcw0KPiA+Pj4gc3BlY2lmaWVkIGFzIHRoZSBJUCBhZGRyZXNzIG9mIHRoZSBVQSBhbmQgdGhl IHBvc3NpYmlsaXR5IG9mIHNlbmRpbmcNCj4gPj4gb25seQ0KPiA+Pj4gYSBwcmVmaXggaXMgbm90 IG1lbnRpb25lZC4NCj4gPj4NCj4gPj4gVGhhdCBpcyBiZWNhdXNlIHdpdGggSFRUUCB0aGUgVUEg Y29ubmVjdHMgZGlyZWN0bHkgdG8gdGhlIHVDRE4gYW5kIHRoZQ0KPiA+PiB1Q0ROIGNhbiBzZWUg dGhlIFVB4oCZcyBJUCBhZGRyZXNzLg0KPiA+Pg0KPiA+Pj4gVGhlbiA1LjIgaGFzIHRoZSBwYXJh IHRoYXQgYmVnaW5zICJXaGlsZSBpdCBpcw0KPiA+Pj4gdGVjaG5pY2FsbHkgcG9zc2libGUgdG8g bWFzayBzb21lIGluZm9ybWF0aW9uIGluIHRoZSBSSSBSZXF1ZXN0LCBzdWNoDQo+IGFzDQo+ID4+ PiB0aGUgbGFzdCBiaXRzIG9mIHRoZSBVQSBJUCBhZGRyZXNzIC4uLiIgd2hpY2ggbWFrZXMgaXQg c2VlbSBsaWtlDQo+ID4+IHByZWZpeGVzDQo+ID4+PiByZWFsbHkgc2hvdWxkbid0IGJlIHNlbnQu DQo+ID4+DQo+ID4+IFdoYXQgd2UgaGF2ZSBwcm92aWRlZCBpcyB0aGUgYWJpbGl0eSBmb3IgdGhl IENETkkgUmVkaXJlY3Rpb24gSW50ZXJmYWNlDQo+IHRvDQo+ID4+IGVuY29kZSB0aGUgcHJvcGVy dGllcyBvZiB0aGUgc291cmNlIChETlMgb3IgSFRUUCkgcmVxdWVzdHMgc28gdGhhdA0KPiB1Q0RO cyAmDQo+ID4+IGRDRE5zIGNhbiBtYWtlIHRoZSBiZXN0IGRDRE4gJiBzdXJyb2dhdGUgc2VsZWN0 aW9uIGRlY2lzaW9ucyB0aGF0IHRoZXkNCj4gPj4gY2FuLiBXZeKAmXJlIG5vdCBzdWdnZXN0aW5n IG9yIG1hbmRhdGluZyBhbnkgYWRkaXRpb25hbCBJUCBhZGRyZXNzDQo+IG1hc2tpbmcNCj4gPj4g YmVoYXZpb3VyIHRoYW4gdGhhdCBwcm92aWRlZCAob3Igbm90IHByb3ZpZGVkKSBieSB0aGUgc291 cmNlIHByb3RvY29sLg0KPiA+PiBUaGlzIG1heSBiZSB0aGUgc291cmNlIG9mIHRoZSBjb25mdXNp b24gLSB3ZeKAmXJlIG5vdCBzYXlpbmcg4oCceW91IHNob3VsZA0KPiA+PiBtYXNrIHRoZSBJUCBh ZGRyZXNzIGJlaGluZCBhIHByZWZpeCBhbmQgdGhpcyBpcyBob3cgdG8gZG8gaXTigJ0gYW5kIHRo ZW4NCj4gPj4gYmVpbmcgaW5jb25zaXN0ZW50IGFib3V0IGFwcGx5aW5nIGl0IHRvIEROUyB2cyBI VFRQLCB3ZeKAmXJlIHNheWluZw0KPiDigJxoZXJl4oCZcw0KPiA+PiBob3cgdG8gZW5jYXBzdWxh dGUgYSBETlMgb3IgSFRUUCByZXF1ZXN0IGludG8gb3VyIHByb3RvY29s4oCdLg0KPiA+Pg0KPiA+ Pj4NCj4gPj4+IEkgdGhpbmsgdGhlIGRvY3VtZW50IG5lZWRzIHNvbWUgY29uc2lzdGVuY3kgYW5k IGNsYXJpdHkgaGVyZSBhYm91dA0KPiA+Pj4gd2hldGhlciBwcmVmaXhlcyBhcmUgZXhwZWN0ZWQg dG8gYmUgdXNlZCBmb3IgZWl0aGVyIHJlZGlyZWN0aW9uDQo+IG1ldGhvZC4NCj4gPj4NCj4gPj4g RG9lcyB0aGUgYWJvdmUgZXhwbGFuYXRpb24gY2hhbmdlIHRoaXMgdmlldz8gT3IgY2hhbmdlIHRo ZSB0ZXh0IHlvdQ0KPiB3b3VsZA0KPiA+PiBsaWtlIHRvIHNlZSB0aGF0IHByb3ZpZGVzIHRoYXQg Y2xhcml0eT8NCj4gPj4NCj4gPj4+IEl0J3MgYWxzbyBub3Qgb2J2aW91cyB0byBtZSB3aHkgdGhl IGRvY3VtZW50IHNob3VsZG4ndCByZWNvbW1lbmQgdG8NCj4gPj4gdUNETnMNCj4gPj4+IHRoYXQg aWYgdGhleSBhcmUgcG9sbGluZyBtdWx0aXBsZSBjYW5kaWRhdGUgZENETnMgYXMgZGVzY3JpYmVk IGluIFNlYw0KPiA+Pj4gNS4yLCB0aGV5IHNob3VsZCB1c2Ugb25seSBhIHByZWZpeCBmb3Igc3Vj aCByZXF1ZXN0cy4gVGhlIGFyZ3VtZW50cw0KPiA+PiBnaXZlbg0KPiA+Pj4gYWdhaW5zdCB0aGlz IHNlZW0gcHJldHR5IHRoaW4gLS0gaXNuJ3QgcHJldmVudGluZyBjb3JyZWxhdGlvbiBvZg0KPiA+ PiBtdWx0aXBsZQ0KPiA+Pj4gcmVxdWVzdHMgdG8gYSBzaW5nbGUgVUEgYSBnb29kIHRoaW5nLCBl c3BlY2lhbGx5IHdoZW4gaXQncyBiZWluZyBkb25lDQo+IGJ5DQo+ID4+PiBhIGJ1bmNoIG9mIGRD RE5zPyBBbmQgSSBkb24ndCB1bmRlcnN0YW5kIHRoZSBDR04gZXhhbXBsZSAtLSBpc24ndCB0aGUN Cj4gPj4+IHJvb3Qgb2YgdGhlIHByb2JsZW0gaGVyZSB0aGF0IHRvcG9sb2dpY2FsbHkgZGlzcGVy c2VkIFVBcyBhcmUgc2hhcmluZw0KPiA+PiB0aGUNCj4gPj4+IHNhbWUgcHVibGljLWZhY2luZyBJ UCBhZGRyZXNzLCBpbiB3aGljaCBjYXNlIHRoZSBkQ0ROIG1heSBoYXZlIHRoZQ0KPiBzYW1lDQo+ ID4+PiBwcm9ibGVtIHdoZW4gcGFzc2VkIGEgZnVsbCBJUCBhZGRyZXNzIGFzIGl0IGRvZXMgYSBw cmVmaXg/DQo+ID4+DQo+ID4+IFdlIGRlc2NyaWJlIGhvdyB0byBlbmNhcHN1bGF0ZSBETlMgJiBI VFRQIHJlcXVlc3RzIGluIHRoZSBSSSBwcm90b2NvbA0KPiBhbmQNCj4gPj4gd2UgZGlzY3VzcyB0 aGF0IGluIHNvbWUgY2lyY3Vtc3RhbmNlcyBpdCBtYXkgcHJvdmlkZSBpbmZvcm1hdGlvbiB0byBh DQo+IGRDRE4NCj4gPj4gdGhhdCB0aGV5IHdvdWxkIG5vdCBvdGhlcndpc2UgaGF2ZSBnb3QgYW5k IHRoYXQgbWFza2luZyBJUCBhZGRyZXNzZXMNCj4gYWxzbw0KPiA+PiBoYXMgZG93bnNpZGVzLg0K PiA+Pg0KPiA+PiBXZSBkbyBub3QgcHJvdmlkZSBhbnkgcHJpdmFjeSBlbmhhbmNpbmcgbm9ybWF0 aXZlIGJlaGF2aW91ciBhbmQgd2UgZG8NCj4gbm90DQo+ID4+IG1ha2UgYSB2YWx1ZSBqdWRnZW1l bnQgb24gd2hldGhlciBhbnkgcG9zc2libGUgcmVkdWN0aW9uIGluIHByaXZhY3kgaXMNCj4gPj4g bW9yZSBpbXBvcnRhbnQgdGhhbiB0aGUgZG93bnNpZGVzIG9mIHByb3ZpZGluZyB0aGF0IHJlZHVj dGlvbiBpbg0KPiBwcml2YWN5Lg0KPiA+Pg0KPiA+PiBUaGUgc3BlY2lmaWMgZXhhbXBsZSBvZiBD R04gbWF5IG5vdCBiZSB0aGUgYmVzdCBleGFtcGxlIGZvciB1cyB0byBoYXZlDQo+ID4+IHVzZWQu IFRoZSBnZW5lcmFsIHBvaW50IGlzIHRoYXQgZENETnMgcGVyZm9ybSBzdXJyb2dhdGUgc2VsZWN0 aW9uIHVzaW5nDQo+IFVBDQo+ID4+IElQIGFkZHJlc3MgKG9yIHRoZSBjbG9zZXN0IHByb3h5IHRo ZXkgY2FuIGdldCwgZS5nLiB0aGUgVUHigJlzIEROUw0KPiA+PiByZXNvbHZlcuKAmXMgSVAgYWRk cmVzcykgYW5kIHRoYXQgbWFza2luZyB0aGUgVUEgSVAgYWRkcmVzcyB0aGVyZWZvcmUNCj4gbWVh bnMNCj4gPj4gZENETnMgbWF5IG1ha2UgbGVzcyBvcHRpbXVtIGRlY2lzaW9ucyBhbmQgdGhhdCBp cyBhIGRvd25zaWRlLg0KPiA+Pg0KPiA+PiBNYXliZSB3ZeKAmWQgYmUgYmV0dGVyIGp1c3Qgc2F5 aW5nIHRoYXQgcmF0aGVyIHRoYW4gdHJ5aW5nIHRvIHByb3ZpZGUNCj4gPj4gc3BlY2lmaWMgc2Nl bmFyaW9zIHRoYXQgc2F5IHRoYXQgYnkgaW5mZXJlbmNlPw0KPiA+Pg0KPiA+Pj4NCj4gPj4+ICgy KQ0KPiA+Pj4gQmVuIG5vdGVkIHRoZSB3ZWFrbmVzcyBvZiB0aGUgcmVjb21tZW5kYXRpb24gaW4g NS4xIHJlZ2FyZGluZyBUTFMuIEkNCj4gc2VlDQo+ID4+PiB0aGF0IHRoZSBsYW5ndWFnZSBoZXJl IGlzIHRoZSBzYW1lIGFzIGl0IGlzIGluDQo+ID4+PiBkcmFmdC1pZXRmLWNkbmktbG9nZ2luZy0y Mi4gQnV0IEkgdGhvdWdodCB0aGUgYWdyZWVtZW50IG9uIHRoYXQNCj4gZG9jdW1lbnQNCj4gPj4+ IHdhcyBNVVNUIHVzZSBUTFMsIGZ1bGwgc3RvcC4gU28gdGhlcmUgaXMgYW1iaWd1aXR5IGluIGJv dGggZG9jdW1lbnRzIEkNCj4gPj4+IHRoaW5rLiAiSW4gYW4gZW52aXJvbm1lbnQgd2hlcmUgLi4u IiBhbmQgIldoZW4gVExTIGlzIHVzZWQgLi4uIiBzZWVtDQo+ID4+PiBpbmNvbnNpc3RlbnQgd2l0 aCAiVExTIE1VU1QgYmUgdXNlZCAuLi4uIiBJJ20gaGFwcHkgdG8gY2xlYXIgb24gdGhpcw0KPiBp Zg0KPiA+Pj4gSSdtIG1pc3Npbmcgc29tZXRoaW5nIGZyb20gdGhlIHByZXZpb3VzIGRpc2N1c3Np b24sIHdoaWNoIEkgdGhpbmsNCj4gPj4+IGhhcHBlbmVkIHdoZW4gSSB3YXMgb24gbGVhdmUgYW5k IHJlc3VsdGVkIGZyb20gb25lIG9mIFN0ZXBoZW4ncw0KPiBiYWxsb3RzLg0KPiA+Pg0KPiA+PiBX aGF0IEkgcmVwbGllZCB0byBCZW7igKYiVGhlcmUgaGFzIGJlZW4gcXVpdGUgYSBiaXQgb2YgZGlz Y3Vzc2lvbiBpbiB0aGUNCj4gPj4gQ0ROSSBXRyBhcm91bmQgdGhpcyB3b3JkaW5nIGFuZCB0aGUg V0cgZGVjaWRlZCB0byBhbGlnbiB0aGUgd29yZGluZyBpdA0KPiA+PiB1c2VkIGFjcm9zcyBhbGwg aXRzIGRvY3VtZW50cy4gVGhlIGZpcnN0IGRvY3VtZW50IHRvIHByb2dyZXNzIHRvIElFU0cNCj4g d2FzDQo+ID4+IGRyYWZ0LWlldGYtY2RuaS1sb2dnaW5nIGFuZCB0aGUgb3RoZXIgQ0ROSSBkcmFm dHMgKGluY2x1ZGluZyB0aGUNCj4gPj4gcmVkaXJlY3Rpb24gb25lIHdlIGFyZSBkaXNjdXNzaW5n KSB1c2UgdGhlIHNhbWUgd29yZGluZyBhcyBkcmFmdC1pZXRmLQ0KPiA+PiBjZG5pLWxvZ2dpbmcu DQo+ID4+DQo+ID4+IEnigJltIGhhcHB5IHRvIGNvbnRpbnVlIHRvIGFsaWduIHRoZSB3b3JkaW5n IGluIHRoaXMgZG9jdW1lbnQgd2l0aCB0aGF0DQo+IGluDQo+ID4+IGRyYWZ0LWlldGYtY2RuaS1s b2dnaW5nLCBidXQgSSB3b3VsZCBzdWdnZXN0IHdlIGF2b2lkIHJlcGVhdGluZyB0aGUNCj4gc2Ft ZQ0KPiA+PiBkaXNjdXNzaW9uIHRoYXQgaXMgaGFwcGVuaW5nIGFyb3VuZCBkcmFmdC1pZXRmLWNk bmktbG9nZ2luZyBoZXJlLg0KPiA+Pg0KPiA+PiBGcmFuY29pcy9LZXZpbiAtIENhbiB5b3UgaGVs cCBoZXJlPyBIYXMgdGhlIGRpc2N1c3Npb24gYXJvdW5kIHRoaXMgdGV4dA0KPiA+PiBmb3IgZHJh ZnQtaWV0Zi1jZG5pLWxvZ2dpbmcgY29uY2x1ZGVkIHlldD8iDQo+ID4+DQo+ID4+IEJlbg0KPiA+ DQo= From nobody Thu Mar 24 11:00:22 2016 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 1F36E12D67D; Thu, 24 Mar 2016 11:00:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001] 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 2f1MvbNJ_rwR; Thu, 24 Mar 2016 11:00:14 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.145]) by ietfa.amsl.com (Postfix) with ESMTP id 48E9B12D538; Thu, 24 Mar 2016 11:00:14 -0700 (PDT) Received: from dab-rcn1-h-2-3.dab.02.net ([82.132.245.56] helo=[10.9.89.198]) by smtp04.mailcore.me with esmtpa (Exim 4.80.1) (envelope-from ) id 1aj9YK-00022E-M6; Thu, 24 Mar 2016 18:00:13 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Ben Niven-Jenkins X-Mailer: iPhone Mail (13C75) In-Reply-To: Date: Thu, 24 Mar 2016 18:00:05 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <6DBCEDD5-4999-4AD2-8188-821E597244DA@niven-jenkins.co.uk> References: <20160316232303.13060.881.idtracker@ietfa.amsl.com> <46E278DB-B866-48E7-A698-8569D9638C20@niven-jenkins.co.uk> To: Kevin Ma J X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Archived-At: Cc: "draft-ietf-cdni-redirection@ietf.org" , "cdni@ietf.org" , The IESG , "cdni-chairs@ietf.org" Subject: Re: [CDNi] Alissa Cooper's Discuss on draft-ietf-cdni-redirection-17: (with DISCUSS) X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 24 Mar 2016 18:00:16 -0000 OK, i'd missed -23 of logging. I will align the text in redirection-18 with l= ogging-23. Ben > On 24 Mar 2016, at 17:47, Kevin Ma J wrote: >=20 > Hi Ben, >=20 > I'm looking at the text in 7.1 of logging-23 and 8.1 of triggers-12. The= y are worded a little differently, but I think the gist of it is: >=20 > A CI/T implementation MUST support TLS transport for HTTP (https) as > per [RFC2818] and [RFC7230]. >=20 > [triggers has a MUST statement here about "authentication of the remote e= nd"; logging's is below] >=20 > The use of TLS for transport of the CI/T interface allows: >=20 > o [dCDN and uCDN to authenticate each other]. >=20 > And, once they have mutually authenticated each other, it allows: >=20 > o The dCDN and the uCDN to authorize each other [for interface specific= purpose]. >=20 > o [interface specific stuff] to be transmitted with > confidentiality. >=20 > o Protection of the integrity of [interface specific stuff]. >=20 > When TLS is used, the general TLS usage guidance in [RFC7525] MUST be > followed. >=20 > [logging has a MUST statement here about "authentication of the remote e= nd"] >=20 > thanx. >=20 > -- Kevin J. Ma >=20 >> -----Original Message----- >> From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] >> Sent: Thursday, March 24, 2016 1:35 PM >> To: Kevin Ma J >> Cc: Alissa Cooper; The IESG; cdni@ietf.org; draft-ietf-cdni- >> redirection@ietf.org; cdni-chairs@ietf.org >> Subject: Re: [CDNi] Alissa Cooper's Discuss on draft-ietf-cdni- >> redirection-17: (with DISCUSS) >>=20 >> Kevin, >>=20 >> On 24 Mar 2016, at 17:19, Kevin Ma J wrote: >>=20 >>>> Francois/Kevin - Can you help here? Has the discussion around this text= >>>> for draft-ietf-cdni-logging concluded yet?" >>>=20 >>> Yes! (Woohoo!) All DISCUSS's on Logging have been cleared, and >> Triggers has updated it's text to match Logging. We can go ahead and >> update Redirection to grab the same text. thanx! >>=20 >> =46rom what I can tell redirection-17 has the same text as logging-22 whi= ch >> has different text to triggers-12. Which text should I use in redirection= - >> 18? >>=20 >> Thanks >> Ben >>=20 >>>=20 >>>> -----Original Message----- >>>> From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] >>>> Sent: Thursday, March 24, 2016 11:06 AM >>>> To: Alissa Cooper >>>> Cc: The IESG; cdni@ietf.org; draft-ietf-cdni-redirection@ietf.org; >> cdni- >>>> chairs@ietf.org >>>> Subject: Re: [CDNi] Alissa Cooper's Discuss on draft-ietf-cdni- >>>> redirection-17: (with DISCUSS) >>>>=20 >>>> Hi Alissa, >>>> (Francois, Kevin, there is a question from Alissa below that I think >> needs >>>> your input as WG chairs) >>>>=20 >>>>> On 16 Mar 2016, at 23:23, Alissa Cooper wrote: >>>>> ----------------------------------------------------------------------= >>>>> DISCUSS: >>>>> ----------------------------------------------------------------------= >>>>>=20 >>>>> (1) >>>>> There is some ambiguity in the document about whether the uCDN passes >>>> the >>>>> IP address of the UA or its prefix to the dCDN. Sec 4.4.1 says that >> for >>>>> DNS redirection, the uCDN passes "IP address or prefix" of the UA, but= >>>>> then in the definition of resolver-ip specifies it only as the IP >>>> address >>>>> of the UA. >>>>=20 >>>> resolver-ip contains =E2=80=9CThe IP address of the UA=E2=80=99s DNS re= solver." >>>>=20 >>>> c-subnet contains the "The IP address (or prefix) of the UA in CIDR >>>> format." >>>>=20 >>>> The idea is resolver-ip contains the IP address of the DNS resolver >> making >>>> the DNS request to the uCDN. c-subnet contains (if present) the >>>> address/prefix carried by draft-ietf-dnsop-edns-client-subnet. >>>>=20 >>>>> Then in Sec 4.5.1 for HTTP redirection the equivalent field is >>>>> specified as the IP address of the UA and the possibility of sending >>>> only >>>>> a prefix is not mentioned. >>>>=20 >>>> That is because with HTTP the UA connects directly to the uCDN and the >>>> uCDN can see the UA=E2=80=99s IP address. >>>>=20 >>>>> Then 5.2 has the para that begins "While it is >>>>> technically possible to mask some information in the RI Request, such >> as >>>>> the last bits of the UA IP address ..." which makes it seem like >>>> prefixes >>>>> really shouldn't be sent. >>>>=20 >>>> What we have provided is the ability for the CDNI Redirection Interface= >> to >>>> encode the properties of the source (DNS or HTTP) requests so that >> uCDNs & >>>> dCDNs can make the best dCDN & surrogate selection decisions that they >>>> can. We=E2=80=99re not suggesting or mandating any additional IP addres= s >> masking >>>> behaviour than that provided (or not provided) by the source protocol. >>>> This may be the source of the confusion - we=E2=80=99re not saying =E2=80= =9Cyou should >>>> mask the IP address behind a prefix and this is how to do it=E2=80=9D a= nd then >>>> being inconsistent about applying it to DNS vs HTTP, we=E2=80=99re sayi= ng >> =E2=80=9Chere=E2=80=99s >>>> how to encapsulate a DNS or HTTP request into our protocol=E2=80=9D. >>>>=20 >>>>>=20 >>>>> I think the document needs some consistency and clarity here about >>>>> whether prefixes are expected to be used for either redirection >> method. >>>>=20 >>>> Does the above explanation change this view? Or change the text you >> would >>>> like to see that provides that clarity? >>>>=20 >>>>> It's also not obvious to me why the document shouldn't recommend to >>>> uCDNs >>>>> that if they are polling multiple candidate dCDNs as described in Sec >>>>> 5.2, they should use only a prefix for such requests. The arguments >>>> given >>>>> against this seem pretty thin -- isn't preventing correlation of >>>> multiple >>>>> requests to a single UA a good thing, especially when it's being done >> by >>>>> a bunch of dCDNs? And I don't understand the CGN example -- isn't the >>>>> root of the problem here that topologically dispersed UAs are sharing >>>> the >>>>> same public-facing IP address, in which case the dCDN may have the >> same >>>>> problem when passed a full IP address as it does a prefix? >>>>=20 >>>> We describe how to encapsulate DNS & HTTP requests in the RI protocol >> and >>>> we discuss that in some circumstances it may provide information to a >> dCDN >>>> that they would not otherwise have got and that masking IP addresses >> also >>>> has downsides. >>>>=20 >>>> We do not provide any privacy enhancing normative behaviour and we do >> not >>>> make a value judgement on whether any possible reduction in privacy is >>>> more important than the downsides of providing that reduction in >> privacy. >>>>=20 >>>> The specific example of CGN may not be the best example for us to have >>>> used. The general point is that dCDNs perform surrogate selection using= >> UA >>>> IP address (or the closest proxy they can get, e.g. the UA=E2=80=99s DN= S >>>> resolver=E2=80=99s IP address) and that masking the UA IP address there= fore >> means >>>> dCDNs may make less optimum decisions and that is a downside. >>>>=20 >>>> Maybe we=E2=80=99d be better just saying that rather than trying to pro= vide >>>> specific scenarios that say that by inference? >>>>=20 >>>>>=20 >>>>> (2) >>>>> Ben noted the weakness of the recommendation in 5.1 regarding TLS. I >> see >>>>> that the language here is the same as it is in >>>>> draft-ietf-cdni-logging-22. But I thought the agreement on that >> document >>>>> was MUST use TLS, full stop. So there is ambiguity in both documents I= >>>>> think. "In an environment where ..." and "When TLS is used ..." seem >>>>> inconsistent with "TLS MUST be used ...." I'm happy to clear on this >> if >>>>> I'm missing something from the previous discussion, which I think >>>>> happened when I was on leave and resulted from one of Stephen's >> ballots. >>>>=20 >>>> What I replied to Ben=E2=80=A6"There has been quite a bit of discussion= in the >>>> CDNI WG around this wording and the WG decided to align the wording it >>>> used across all its documents. The first document to progress to IESG >> was >>>> draft-ietf-cdni-logging and the other CDNI drafts (including the >>>> redirection one we are discussing) use the same wording as draft-ietf- >>>> cdni-logging. >>>>=20 >>>> I=E2=80=99m happy to continue to align the wording in this document wit= h that >> in >>>> draft-ietf-cdni-logging, but I would suggest we avoid repeating the >> same >>>> discussion that is happening around draft-ietf-cdni-logging here. >>>>=20 >>>> Francois/Kevin - Can you help here? Has the discussion around this text= >>>> for draft-ietf-cdni-logging concluded yet?" >>>>=20 >>>> Ben >>>=20 From nobody Fri Mar 25 11:27:21 2016 Return-Path: X-Original-To: cdni@ietf.org Delivered-To: cdni@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B7AA312D5B4; Fri, 25 Mar 2016 11:27:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160325182719.17995.1066.idtracker@ietfa.amsl.com> Date: Fri, 25 Mar 2016 11:27:19 -0700 Archived-At: Cc: draft-ietf-cdni-logging@ietf.org, cdni@ietf.org, cdni-chairs@ietf.org Subject: [CDNi] Alissa Cooper's Discuss on draft-ietf-cdni-logging-23: (with DISCUSS and COMMENT) X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 25 Mar 2016 18:27:19 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-cdni-logging-23: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cdni-logging/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I appreciate all the work that has gone into this document. It was originally up for IESG review when I was on leave, so I was not able to review it at that time. The document needs one more ballot to progress, so I told Spencer I would review it. I realize it's probably frustrating to see another DISCUSS at this point but these should be straightforward to resolve I think. (1) I am wondering about a potential inconsistency that I see in Section 3.4.1. I see with the definition of the c-groupid field that there is inherent support for reporting about clients as aggregates, which is great, and even when reporting is done about individual clients there are a bunch of normative recommendations to try to reduce the chances that a logging field will be tied back to an individual user or host. Excellent. But then with the definition of the cs(insert_HTTP_header_name_here) field and discussion about it, there is no equivalent normative guidance given about not including headers that could potentially be used to identify an individual user or host. There is discussion about cookies but none of it is normative, and cookies are not the only headers that could be identifying. In fact, one of the examples given -- User-Agent -- is known to be identifying in some cases. Given the extent to which the specification of c-groupid goes to support masking the identity of the host, I would expect normative guidance about the use of the header field. That is, if an implementation is using c-groupid to represent an aggregate, it would make sense to me that it MUST NOT include header fields that could be uniquely identifying. I also wonder if the recommendations about cookies in 3.4.1 could be made normative. I will say that based on the use cases for these logs listed in 2.2.5 it's hard to understand what a uCDN needs headers like cookies for on a consistent basis; if they're needed for an occasional troubleshoot, logging them consistently seems like overkill. (2) Section 7.1 says: "In an environment where any such protection is required, mutually authenticated encrypted transport MUST be used to ensure confidentiality of the logging information. To that end, TLS MUST be used (including authentication of the remote end) by the server-side and the client-side of the CDNI Logging feed, as well as the server- side and the client-side of the CDNI Logging File pull mechanism." I know this text has been the subject of much discussion and careful editing, and that I raised an issue on this on the redirection draft. What I don't understand from reading this is whether the expectation is that all servers and clients implementing this specification will use TLS. The first sentence seems to indicate that there will be cases when that is not true. The second sentence says MUST use, which means use in every case. Which is it? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (1) Per my first DISCUSS point above, I wonder if it makes sense to specify a field where the dCDN could report a sanitized version of the client User-Agent string. This would allow a uCDN to calculate the "terminal type" KPI listed in 2.2.5.5.2 without requiring full, potentially identifying User-Agent strings to be logged. (2) I think the use of partial-time in 3.4.1 means that the timestamps have no time zone information. It's not clear to me how the uCDN uses these timestamps in an absolute sense anyway, but I'm wondering if that could create problems if the uCDN does not know what time zone the dCDN is in. The time information in that case is somewhat meaningless if the uCDN needs to know the actual time at which something occurred. From nobody Fri Mar 25 12:39:00 2016 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 A96FC12D0A1; Fri, 25 Mar 2016 12:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 vkHlJVrxt-tg; Fri, 25 Mar 2016 12:38:52 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (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 1A96712D132; Fri, 25 Mar 2016 12:38:52 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id o6so38367486qkc.2; Fri, 25 Mar 2016 12:38:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=Zuqa0P5kLMD91p5GiZQzNPo02tQHpQRHjWur/vefW28=; b=kxYDDVLDyM4q6rslOGq+neihwVGDiEw57LSzclcH+WgJouEHCG9Xs5ZOyg5m9IAcms YpeGFUkcZe+oV5DlvdCRg3gXDiLQJqOtw7yv7z3f70jeamEANbn7di67/aCI4rhKkGhp aXOjuFxafZ2ZG3CjGFXU4uRnZJbTBcNOH0jnu9XcgcKspyBhB87lc+CTToz+Doz3GHlO 6jZd16yJBmt2XuatxCKBOhS8HQuoO/PTLVSWn5pGeUkpanbUd/nbqh5AsNwpYHnqcszo 8417IMf6hrd5x1c6SY6pru/b9jt30yykgkAGPLVXqhWT4HUWMjCx/NHXmILnemIWWu3f Iv3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=Zuqa0P5kLMD91p5GiZQzNPo02tQHpQRHjWur/vefW28=; b=N77pQcHFR7dXKizrt1sEFV+EJQSAxY2oPrh7zqBaYV8UMMkNEsoCLhpfAEnkpDbIHI Jo2WoilvLDop32XhnksNKRl5Ef57HRdezmWTPICQ+9PWMK04qKp9Z9LIcM/RJD3k9DLi rP55FANpH3Ek2221iBmys3mRi1YLjNhebt4SAs1JsPwgZpI3clPVPvCM+Gv1xl8lobiV ZBt9m9ECcMu2vzbINLHmMYbeKCmvH+wFdVGrxgp6qvPs8Jt60rA+MC/Zkzmwv5Gqunqf NfcuFAlrWBH5kTjQA1tQfqQ1cADoJ9nt8l6RdvvLX/2R1F/CDaZBN+KmwT2rtSKCCvos E8qw== X-Gm-Message-State: AD7BkJL4GbATipTjcd/cxLKgXryqyhA3nxKKIVELiTFdhL5nbeL+xqWT0BRDuux8Nx90Gx3CrF+e+KlzKmi8cg== MIME-Version: 1.0 X-Received: by 10.13.221.148 with SMTP id g142mr5084654ywe.59.1458934731069; Fri, 25 Mar 2016 12:38:51 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.83.28.67 with HTTP; Fri, 25 Mar 2016 12:38:51 -0700 (PDT) In-Reply-To: <20160325182719.17995.1066.idtracker@ietfa.amsl.com> References: <20160325182719.17995.1066.idtracker@ietfa.amsl.com> Date: Fri, 25 Mar 2016 15:38:51 -0400 X-Google-Sender-Auth: E-of0lApMEE0K55GM0yy1QL5xv0 Message-ID: From: Barry Leiba To: draft-ietf-cdni-logging@ietf.org, cdni-chairs@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" , The IESG Subject: Re: [CDNi] Alissa Cooper's Discuss on draft-ietf-cdni-logging-23: (with DISCUSS and COMMENT) X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 25 Mar 2016 19:38:54 -0000 For the authors/chairs: There's quite a premium on getting Alissa's comments resolved to everyone's satisfaction by the end of March. If we can't, then three ballots become invalid (mine, Brian's, and Martin's), and Spencer will need to get three more reviews from among the five who didn't ballot and the three new ADs. That's certainly possible, but you can see how it'll be much easier if Alissa's can be the last ballot needed. Let's not let haste push us into bad decisions... but let promptness and quick work rule here. Thanks. Barry On Fri, Mar 25, 2016 at 2:27 PM, Alissa Cooper wrote: > Alissa Cooper has entered the following ballot position for > draft-ietf-cdni-logging-23: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-cdni-logging/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I appreciate all the work that has gone into this document. It was > originally up for IESG review when I was on leave, so I was not able to > review it at that time. The document needs one more ballot to progress, > so I told Spencer I would review it. I realize it's probably frustrating > to see another DISCUSS at this point but these should be straightforward > to resolve I think. > > (1) > I am wondering about a potential inconsistency that I see in Section > 3.4.1. I see with the definition of the c-groupid field that there is > inherent support for reporting about clients as aggregates, which is > great, and even when reporting is done about individual clients there are > a bunch of normative recommendations to try to reduce the chances that a > logging field will be tied back to an individual user or host. Excellent. > But then with the definition of the cs(insert_HTTP_header_name_here) > field and discussion about it, there is no equivalent normative guidance > given about not including headers that could potentially be used to > identify an individual user or host. There is discussion about cookies > but none of it is normative, and cookies are not the only headers that > could be identifying. In fact, one of the examples given -- User-Agent -- > is known to be identifying in some cases. > > Given the extent to which the specification of c-groupid goes to support > masking the identity of the host, I would expect normative guidance about > the use of the header field. That is, if an implementation is using > c-groupid to represent an aggregate, it would make sense to me that it > MUST NOT include header fields that could be uniquely identifying. I also > wonder if the recommendations about cookies in 3.4.1 could be made > normative. I will say that based on the use cases for these logs listed > in 2.2.5 it's hard to understand what a uCDN needs headers like cookies > for on a consistent basis; if they're needed for an occasional > troubleshoot, logging them consistently seems like overkill. > > (2) > Section 7.1 says: > > "In an environment where any such protection is required, mutually > authenticated encrypted transport MUST be used to ensure > confidentiality of the logging information. To that end, TLS MUST be > used (including authentication of the remote end) by the server-side > and the client-side of the CDNI Logging feed, as well as the server- > side and the client-side of the CDNI Logging File pull mechanism." > > I know this text has been the subject of much discussion and careful > editing, and that I raised an issue on this on the redirection draft. > What I don't understand from reading this is whether the expectation is > that all servers and clients implementing this specification will use > TLS. The first sentence seems to indicate that there will be cases when > that is not true. The second sentence says MUST use, which means use in > every case. Which is it? > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > (1) Per my first DISCUSS point above, I wonder if it makes sense to > specify a field where the dCDN could report a sanitized version of the > client User-Agent string. This would allow a uCDN to calculate the > "terminal type" KPI listed in 2.2.5.5.2 without requiring full, > potentially identifying User-Agent strings to be logged. > > (2) I think the use of partial-time in 3.4.1 means that the timestamps > have no time zone information. It's not clear to me how the uCDN uses > these timestamps in an absolute sense anyway, but I'm wondering if that > could create problems if the uCDN does not know what time zone the dCDN > is in. The time information in that case is somewhat meaningless if the > uCDN needs to know the actual time at which something occurred. > > From nobody Fri Mar 25 14:59:21 2016 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 7A1E712D656; Fri, 25 Mar 2016 14:59:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 5WVqIckxaNhK; Fri, 25 Mar 2016 14:59:13 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12B9312D62B; Fri, 25 Mar 2016 14:59:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5747; q=dns/txt; s=iport; t=1458943153; x=1460152753; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=7cwVOjS5IQhIlL5kXS1feIlUwfX9m37IabT7Hc/30u0=; b=ljB6kFzKcRf2pJm8sPIYEaXQywlfzy/FK1GZM5mJbyfu9cRRxV0nUEa8 YMFffcGRwsORsZzDohBYc3GT0Z/qJBNkK1As5KrxYdWjygejwF7KYE+gK 0nRyBOC1DEK006z2Six3/IZVF1BNgw2pOpvDn/+0eE2Gp5mRm3oShYVYE Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AyAgABtPVW/5hdJa1UAQmDLlN9ul4BD?= =?us-ascii?q?YFwIYVsAoEzOBQBAQEBAQEBZCeEQQEBAQMBOj8FCwIBCBgeEDIlAgQOAwKIHwg?= =?us-ascii?q?OwSwBAQEBAQEBAQEBAQEBAQEBAQEBAQERBIgRglGEDAYBCgEGFjSCeYIrBYdhj?= =?us-ascii?q?38BhXCIEwqBXIRMiFmPCQEeAQFCgjCBNT8tAYdogTQBAQE?= X-IronPort-AV: E=Sophos;i="5.24,392,1454976000"; d="scan'208";a="252894820" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Mar 2016 21:59:11 +0000 Received: from XCH-ALN-019.cisco.com (xch-aln-019.cisco.com [173.36.7.29]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u2PLxBXG025540 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 25 Mar 2016 21:59:11 GMT Received: from xch-rcd-020.cisco.com (173.37.102.30) by XCH-ALN-019.cisco.com (173.36.7.29) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 25 Mar 2016 16:59:10 -0500 Received: from xch-rcd-020.cisco.com ([173.37.102.30]) by XCH-RCD-020.cisco.com ([173.37.102.30]) with mapi id 15.00.1104.009; Fri, 25 Mar 2016 16:59:10 -0500 From: "Francois Le Faucheur (flefauch)" To: Barry Leiba Thread-Topic: Alissa Cooper's Discuss on draft-ietf-cdni-logging-23: (with DISCUSS and COMMENT) Thread-Index: AQHRhsP4iuNYklNmQ02XT5JZGF9cRJ9q4jSA///TYzM= Date: Fri, 25 Mar 2016 21:59:10 +0000 Message-ID: References: <20160325182719.17995.1066.idtracker@ietfa.amsl.com>, 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 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "" , "cdni-chairs@ietf.org" , Francois Le Faucheur , The IESG , "draft-ietf-cdni-logging@ietf.org" Subject: Re: [CDNi] Alissa Cooper's Discuss on draft-ietf-cdni-logging-23: (with DISCUSS and COMMENT) X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 25 Mar 2016 21:59:15 -0000 Noted. I will work on this next Tuesday.=20 Up in the mountains till then.=20 Thanks Sent from my iPhone > On 25 Mar 2016, at 20:38, Barry Leiba wrote: >=20 > For the authors/chairs: > There's quite a premium on getting Alissa's comments resolved to > everyone's satisfaction by the end of March. If we can't, then three > ballots become invalid (mine, Brian's, and Martin's), and Spencer will > need to get three more reviews from among the five who didn't ballot > and the three new ADs. That's certainly possible, but you can see how > it'll be much easier if Alissa's can be the last ballot needed. >=20 > Let's not let haste push us into bad decisions... but let promptness > and quick work rule here. Thanks. >=20 > Barry >=20 >> On Fri, Mar 25, 2016 at 2:27 PM, Alissa Cooper wrote= : >> Alissa Cooper has entered the following ballot position for >> draft-ietf-cdni-logging-23: Discuss >>=20 >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >>=20 >>=20 >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.htm= l >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-cdni-logging/ >>=20 >>=20 >>=20 >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >>=20 >> I appreciate all the work that has gone into this document. It was >> originally up for IESG review when I was on leave, so I was not able to >> review it at that time. The document needs one more ballot to progress, >> so I told Spencer I would review it. I realize it's probably frustrating >> to see another DISCUSS at this point but these should be straightforward >> to resolve I think. >>=20 >> (1) >> I am wondering about a potential inconsistency that I see in Section >> 3.4.1. I see with the definition of the c-groupid field that there is >> inherent support for reporting about clients as aggregates, which is >> great, and even when reporting is done about individual clients there ar= e >> a bunch of normative recommendations to try to reduce the chances that a >> logging field will be tied back to an individual user or host. Excellent= . >> But then with the definition of the cs(insert_HTTP_header_name_here) >> field and discussion about it, there is no equivalent normative guidance >> given about not including headers that could potentially be used to >> identify an individual user or host. There is discussion about cookies >> but none of it is normative, and cookies are not the only headers that >> could be identifying. In fact, one of the examples given -- User-Agent -= - >> is known to be identifying in some cases. >>=20 >> Given the extent to which the specification of c-groupid goes to support >> masking the identity of the host, I would expect normative guidance abou= t >> the use of the header field. That is, if an implementation is using >> c-groupid to represent an aggregate, it would make sense to me that it >> MUST NOT include header fields that could be uniquely identifying. I als= o >> wonder if the recommendations about cookies in 3.4.1 could be made >> normative. I will say that based on the use cases for these logs listed >> in 2.2.5 it's hard to understand what a uCDN needs headers like cookies >> for on a consistent basis; if they're needed for an occasional >> troubleshoot, logging them consistently seems like overkill. >>=20 >> (2) >> Section 7.1 says: >>=20 >> "In an environment where any such protection is required, mutually >> authenticated encrypted transport MUST be used to ensure >> confidentiality of the logging information. To that end, TLS MUST be >> used (including authentication of the remote end) by the server-side >> and the client-side of the CDNI Logging feed, as well as the server- >> side and the client-side of the CDNI Logging File pull mechanism." >>=20 >> I know this text has been the subject of much discussion and careful >> editing, and that I raised an issue on this on the redirection draft. >> What I don't understand from reading this is whether the expectation is >> that all servers and clients implementing this specification will use >> TLS. The first sentence seems to indicate that there will be cases when >> that is not true. The second sentence says MUST use, which means use in >> every case. Which is it? >>=20 >>=20 >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >>=20 >> (1) Per my first DISCUSS point above, I wonder if it makes sense to >> specify a field where the dCDN could report a sanitized version of the >> client User-Agent string. This would allow a uCDN to calculate the >> "terminal type" KPI listed in 2.2.5.5.2 without requiring full, >> potentially identifying User-Agent strings to be logged. >>=20 >> (2) I think the use of partial-time in 3.4.1 means that the timestamps >> have no time zone information. It's not clear to me how the uCDN uses >> these timestamps in an absolute sense anyway, but I'm wondering if that >> could create problems if the uCDN does not know what time zone the dCDN >> is in. The time information in that case is somewhat meaningless if the >> uCDN needs to know the actual time at which something occurred. >>=20 >>=20 From nobody Sat Mar 26 15:06:34 2016 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 7202312D136; Sat, 26 Mar 2016 15:06:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 WFbaY9C8TBDW; Sat, 26 Mar 2016 15:06:24 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (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 EC01112D0CF; Sat, 26 Mar 2016 15:06:23 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id o6so67299372qkc.2; Sat, 26 Mar 2016 15:06:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=8XFA4EmGr+rmYifx9EDZeThHNEelN+nch3C6E08Axqo=; b=kpR4qGiEWlePEg5XNH4ctekhHLQi+NUxWVSCG4fp6epCEraybNwkX+19RgKAmsgG+B oEEfNY4ZEPwaadHFSogwiyhQhjMvg8eEBsh9MVdESZUDQLkhQo+Ycyf5/qkge/Q5vJfe 8Yj1ZzZ1xiZ07fDXrVXHaMzrr12yCga4yK9WJ+roDfbqkl1J+g1lfxiMkF1qTrd22nTO F6pv4Tap7I/qk/nmqMCyuIvlg1QLGYW0IAkkratJHpUsUkz9/OQ/oQ1s8D6UQtK+C0RW juj+os+vVNBCPXwPFWFvAKx0zA40DZbq/81iSuVBCndegP8x0gm0EYFTQ0BfD5HPqe10 5B8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=8XFA4EmGr+rmYifx9EDZeThHNEelN+nch3C6E08Axqo=; b=FfnZcYr7PbuOB7+ist4g2dpKRBKYC3PyghKmiF8NWAJDNNKZxvZjmY4FwAk7ToDjjx Mh+QcSXr8II1AIVONr11emOqB6WtA8NkCj0Gl1/emstPn1CvTo7mVp0g8W2RB3jlRAr4 XCv3O42Pmb0EzHHrG1rsy2iVKLqlUx6zxm3an/UtU2/t4u3NyJWzL+KmEDSG+G8UQNNk mwkAuC+vuU8BiVyolqtefdqRPkR19jgOX798l/pCHkrHAAZQdAHhVEKBi456myGdIDX9 SkMhK/wvofdSaZIDMmHHr/cyfsDrQDkEWltreCAFj9SanVisa4t1iZnq3eGJKVsI49So smaw== X-Gm-Message-State: AD7BkJIWFP5Ss/GZMeetRBGwyHDvRN5uUOc/3frCEuZhIJvGWsTNAWUU0dmKgGZ6IWBjesPNEnOcd3z7WFG7OQ== MIME-Version: 1.0 X-Received: by 10.37.22.197 with SMTP id 188mr10669395ybw.98.1459029983074; Sat, 26 Mar 2016 15:06:23 -0700 (PDT) Received: by 10.37.214.13 with HTTP; Sat, 26 Mar 2016 15:06:22 -0700 (PDT) In-Reply-To: References: <20160325182719.17995.1066.idtracker@ietfa.amsl.com> Date: Sat, 26 Mar 2016 17:06:22 -0500 Message-ID: From: Spencer Dawkins at IETF To: "Francois Le Faucheur (flefauch)" Content-Type: multipart/alternative; boundary=001a113fca64db9fd8052efae326 Archived-At: Cc: "" , "cdni-chairs@ietf.org" , Francois Le Faucheur , "draft-ietf-cdni-logging@ietf.org" , The IESG , Barry Leiba Subject: Re: [CDNi] Alissa Cooper's Discuss on draft-ietf-cdni-logging-23: (with DISCUSS and COMMENT) X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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: Sat, 26 Mar 2016 22:06:27 -0000 --001a113fca64db9fd8052efae326 Content-Type: text/plain; charset=UTF-8 Thank all of you for the last minute effort here. I'll be traveling on Thursday evening/Friday morning, but will be watching closely otherwise. If you'll be traveling, please travel safely! Spencer On Friday, March 25, 2016, Francois Le Faucheur (flefauch) < flefauch@cisco.com> wrote: > Noted. I will work on this next Tuesday. > Up in the mountains till then. > Thanks > > Sent from my iPhone > > > On 25 Mar 2016, at 20:38, Barry Leiba > wrote: > > > > For the authors/chairs: > > There's quite a premium on getting Alissa's comments resolved to > > everyone's satisfaction by the end of March. If we can't, then three > > ballots become invalid (mine, Brian's, and Martin's), and Spencer will > > need to get three more reviews from among the five who didn't ballot > > and the three new ADs. That's certainly possible, but you can see how > > it'll be much easier if Alissa's can be the last ballot needed. > > > > Let's not let haste push us into bad decisions... but let promptness > > and quick work rule here. Thanks. > > > > Barry > > > >> On Fri, Mar 25, 2016 at 2:27 PM, Alissa Cooper > wrote: > >> Alissa Cooper has entered the following ballot position for > >> draft-ietf-cdni-logging-23: Discuss > >> > >> When responding, please keep the subject line intact and reply to all > >> email addresses included in the To and CC lines. (Feel free to cut this > >> introductory paragraph, however.) > >> > >> > >> Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > >> for more information about IESG DISCUSS and COMMENT positions. > >> > >> > >> The document, along with other ballot positions, can be found here: > >> https://datatracker.ietf.org/doc/draft-ietf-cdni-logging/ > >> > >> > >> > >> ---------------------------------------------------------------------- > >> DISCUSS: > >> ---------------------------------------------------------------------- > >> > >> I appreciate all the work that has gone into this document. It was > >> originally up for IESG review when I was on leave, so I was not able to > >> review it at that time. The document needs one more ballot to progress, > >> so I told Spencer I would review it. I realize it's probably frustrating > >> to see another DISCUSS at this point but these should be straightforward > >> to resolve I think. > >> > >> (1) > >> I am wondering about a potential inconsistency that I see in Section > >> 3.4.1. I see with the definition of the c-groupid field that there is > >> inherent support for reporting about clients as aggregates, which is > >> great, and even when reporting is done about individual clients there > are > >> a bunch of normative recommendations to try to reduce the chances that a > >> logging field will be tied back to an individual user or host. > Excellent. > >> But then with the definition of the cs(insert_HTTP_header_name_here) > >> field and discussion about it, there is no equivalent normative guidance > >> given about not including headers that could potentially be used to > >> identify an individual user or host. There is discussion about cookies > >> but none of it is normative, and cookies are not the only headers that > >> could be identifying. In fact, one of the examples given -- User-Agent > -- > >> is known to be identifying in some cases. > >> > >> Given the extent to which the specification of c-groupid goes to support > >> masking the identity of the host, I would expect normative guidance > about > >> the use of the header field. That is, if an implementation is using > >> c-groupid to represent an aggregate, it would make sense to me that it > >> MUST NOT include header fields that could be uniquely identifying. I > also > >> wonder if the recommendations about cookies in 3.4.1 could be made > >> normative. I will say that based on the use cases for these logs listed > >> in 2.2.5 it's hard to understand what a uCDN needs headers like cookies > >> for on a consistent basis; if they're needed for an occasional > >> troubleshoot, logging them consistently seems like overkill. > >> > >> (2) > >> Section 7.1 says: > >> > >> "In an environment where any such protection is required, mutually > >> authenticated encrypted transport MUST be used to ensure > >> confidentiality of the logging information. To that end, TLS MUST be > >> used (including authentication of the remote end) by the server-side > >> and the client-side of the CDNI Logging feed, as well as the server- > >> side and the client-side of the CDNI Logging File pull mechanism." > >> > >> I know this text has been the subject of much discussion and careful > >> editing, and that I raised an issue on this on the redirection draft. > >> What I don't understand from reading this is whether the expectation is > >> that all servers and clients implementing this specification will use > >> TLS. The first sentence seems to indicate that there will be cases when > >> that is not true. The second sentence says MUST use, which means use in > >> every case. Which is it? > >> > >> > >> ---------------------------------------------------------------------- > >> COMMENT: > >> ---------------------------------------------------------------------- > >> > >> (1) Per my first DISCUSS point above, I wonder if it makes sense to > >> specify a field where the dCDN could report a sanitized version of the > >> client User-Agent string. This would allow a uCDN to calculate the > >> "terminal type" KPI listed in 2.2.5.5.2 without requiring full, > >> potentially identifying User-Agent strings to be logged. > >> > >> (2) I think the use of partial-time in 3.4.1 means that the timestamps > >> have no time zone information. It's not clear to me how the uCDN uses > >> these timestamps in an absolute sense anyway, but I'm wondering if that > >> could create problems if the uCDN does not know what time zone the dCDN > >> is in. The time information in that case is somewhat meaningless if the > >> uCDN needs to know the actual time at which something occurred. > >> > >> > > --001a113fca64db9fd8052efae326 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thank all of you for the last minute effort here.

I'= ll be traveling on Thursday evening/Friday morning, but will be watching cl= osely otherwise.

If you'll be traveling, pleas= e travel safely!

Spencer

On Friday, March 2= 5, 2016, Francois Le Faucheur (flefauch) <flefauch@cisco.com> wrote:
Noted. I will work on this next Tuesday.
Up in the mountains till then.
Thanks

Sent from my iPhone

> On 25 Mar 2016, at 20:38, Barry Leiba <barry= leiba@computer.org> wrote:
>
> For the authors/chairs:
> There's quite a premium on getting Alissa's comments resolved = to
> everyone's satisfaction by the end of March.=C2=A0 If we can't= , then three
> ballots become invalid (mine, Brian's, and Martin's), and Spen= cer will
> need to get three more reviews from among the five who didn't ball= ot
> and the three new ADs.=C2=A0 That's certainly possible, but you ca= n see how
> it'll be much easier if Alissa's can be the last ballot needed= .
>
> Let's not let haste push us into bad decisions... but let promptne= ss
> and quick work rule here.=C2=A0 Thanks.
>
> Barry
>
>> On Fri, Mar 25, 2016 at 2:27 PM, Alissa Cooper <https://www.ietf.org/iesg/statement/d= iscuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here= :
>> https://datatracker.ietf.org/doc/draft-ietf-cdni-logg= ing/
>>
>>
>>
>> ------------------------------------------------------------------= ----
>> DISCUSS:
>> ------------------------------------------------------------------= ----
>>
>> I appreciate all the work that has gone into this document. It was=
>> originally up for IESG review when I was on leave, so I was not ab= le to
>> review it at that time. The document needs one more ballot to prog= ress,
>> so I told Spencer I would review it. I realize it's probably f= rustrating
>> to see another DISCUSS at this point but these should be straightf= orward
>> to resolve I think.
>>
>> (1)
>> I am wondering about a potential inconsistency that I see in Secti= on
>> 3.4.1. I see with the definition of the c-groupid field that there= is
>> inherent support for reporting about clients as aggregates, which = is
>> great, and even when reporting is done about individual clients th= ere are
>> a bunch of normative recommendations to try to reduce the chances = that a
>> logging field will be tied back to an individual user or host. Exc= ellent.
>> But then with the definition of the cs(insert_HTTP_header_name_her= e)
>> field and discussion about it, there is no equivalent normative gu= idance
>> given about not including headers that could potentially be used t= o
>> identify an individual user or host. There is discussion about coo= kies
>> but none of it is normative, and cookies are not the only headers = that
>> could be identifying. In fact, one of the examples given -- User-A= gent --
>> is known to be identifying in some cases.
>>
>> Given the extent to which the specification of c-groupid goes to s= upport
>> masking the identity of the host, I would expect normative guidanc= e about
>> the use of the header field. That is, if an implementation is usin= g
>> c-groupid to represent an aggregate, it would make sense to me tha= t it
>> MUST NOT include header fields that could be uniquely identifying.= I also
>> wonder if the recommendations about cookies in 3.4.1 could be made=
>> normative. I will say that based on the use cases for these logs l= isted
>> in 2.2.5 it's hard to understand what a uCDN needs headers lik= e cookies
>> for on a consistent basis; if they're needed for an occasional=
>> troubleshoot, logging them consistently seems like overkill.
>>
>> (2)
>> Section 7.1 says:
>>
>> "In an environment where any such protection is required, mut= ually
>>=C2=A0 =C2=A0authenticated encrypted transport MUST be used to ensu= re
>>=C2=A0 =C2=A0confidentiality of the logging information.=C2=A0 To t= hat end, TLS MUST be
>>=C2=A0 =C2=A0used (including authentication of the remote end) by t= he server-side
>>=C2=A0 =C2=A0and the client-side of the CDNI Logging feed, as well = as the server-
>>=C2=A0 =C2=A0side and the client-side of the CDNI Logging File pull= mechanism."
>>
>> I know this text has been the subject of much discussion and caref= ul
>> editing, and that I raised an issue on this on the redirection dra= ft.
>> What I don't understand from reading this is whether the expec= tation is
>> that all servers and clients implementing this specification will = use
>> TLS. The first sentence seems to indicate that there will be cases= when
>> that is not true. The second sentence says MUST use, which means u= se in
>> every case. Which is it?
>>
>>
>> ------------------------------------------------------------------= ----
>> COMMENT:
>> ------------------------------------------------------------------= ----
>>
>> (1) Per my first DISCUSS point above, I wonder if it makes sense t= o
>> specify a field where the dCDN could report a sanitized version of= the
>> client User-Agent string. This would allow a uCDN to calculate the=
>> "terminal type" KPI listed in 2.2.5.5.2 without requirin= g full,
>> potentially identifying User-Agent strings to be logged.
>>
>> (2) I think the use of partial-time in 3.4.1 means that the timest= amps
>> have no time zone information. It's not clear to me how the uC= DN uses
>> these timestamps in an absolute sense anyway, but I'm wonderin= g if that
>> could create problems if the uCDN does not know what time zone the= dCDN
>> is in. The time information in that case is somewhat meaningless i= f the
>> uCDN needs to know the actual time at which something occurred. >>
>>

--001a113fca64db9fd8052efae326-- From nobody Sun Mar 27 09:36:32 2016 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 5D5D412D0AB; Sun, 27 Mar 2016 09:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 FFiID9e0-MGZ; Sun, 27 Mar 2016 09:36:28 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E796012D110; Sun, 27 Mar 2016 09:36:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id EEF71BE51; Sun, 27 Mar 2016 17:36:24 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bgUjtVH9xDMs; Sun, 27 Mar 2016 17:36:23 +0100 (IST) Received: from [10.87.49.100] (unknown [86.41.56.135]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 870E0BE50; Sun, 27 Mar 2016 17:36:22 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1459096583; bh=BBvjuOevVnYf33G10Dsnmr6/MYVD5cB2aG9CZQytNyY=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=ko9GFB4gBft2Ea2iUOw3lFD/8UbUtd1B26+WkyQMWpGZDjw45XxfCK45qRtW8F2cf aYnqzY4vpYIKqAhXJn1g7rbXBPUIPbreTwccSRlftXeqptNOE0dWVHFnRjZTZx1L2G woVPS0G4X3FXf++pOltdxAH2lcbPcVFOoHYKKI7A= To: "Niven - Jenkins, Ben (Nokia - GB)" References: <20160317101014.1026.78717.idtracker@ietfa.amsl.com> <6B22150C-4A0E-4FFF-A48C-AEA2D881632E@niven-jenkins.co.uk> <56F40929.1020309@cs.tcd.ie> <774D3FF5-A163-472A-B441-ED3CD9C50724@alcatel-lucent.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56F80C06.1080402@cs.tcd.ie> Date: Sun, 27 Mar 2016 17:36:22 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <774D3FF5-A163-472A-B441-ED3CD9C50724@alcatel-lucent.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090109070906090107060200" Archived-At: Cc: "cdni@ietf.org" , "draft-ietf-cdni-redirection@ietf.org" , The IESG , "cdni-chairs@ietf.org" Subject: Re: [CDNi] Stephen Farrell's Discuss on draft-ietf-cdni-redirection-17: (with DISCUSS and COMMENT) X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2016 16:36:30 -0000 This is a cryptographically signed message in MIME format. --------------ms090109070906090107060200 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 24/03/16 15:51, Niven - Jenkins, Ben (Nokia - GB) wrote: >> Can we agree that as-is, the draft is very much >> aiming to meet the commercial requirements and is not taking account >> or privacy requirements? > > Yes I think we can agree that. Ben Great. Then I'd suggest that the best next step may be to try get a bunch of folks to chat in B-A about how to take privacy into account and hopefully that'll also turn out to be a fine way to resolve the discuss. (Or if not in B-A then a subsequent concall maybe.) I'll certainly try to be there for that, but I expect it may be possible to make good progress so long as you have someone there who knows/cares a bit about privacy. It may also be worth pointing out here that, just as with the cdni-logging draft, my goal here is not to try to force the CDNs using this to be privacy friendly, since that's impossible and (en)forcing such things against the will of an operator isn't the IETF's responsibility. Even if we defined the protocol to try do that, there'd be loads of ways to work around it and companies trying to "monetize" my mouse-clicks would just do that without asking anyone anyway. We do however need to define a protocol that allows a willing CDN to be privacy friendly and achieve interop for the function conerned. So that last is my goal for this discussion. I assume the authors, WG chairs, document shepherd or responsible AD can take the lead in finding a time/place/set of folks to chat. Cheers, S. --------------ms090109070906090107060200 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjAzMjcx NjM2MjJaMC8GCSqGSIb3DQEJBDEiBCAg0mTBraTOC0GbTfXBiGJpDMi370ce8jWn11mx7Hsy 6TBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQBE7kZIxEQzBrFt1Sml43ImwPHb2us3XLyt4TaGzQFkPbTUxrIahkpw 4BwoefacL81W3W8xEQ4LnHCBF/wcTXqZtZj08nMcv3BxBLU4oDPQDVrogHhdQhtbcJ+GGlDL hcNc5eEEYfEBd/yA3YTBhjrFd8zaLGq0df2DDgoFu9Fu9diCqbTxYMFgfwJCyQocUOYGn2jh wg//W9uxFONIcvx2UbMzAc/35DGi/Esqxc9DjHl45H45XNMSo0RinOxN6wk2bJEhyWLs7i5I nCwh53zsQSYF88f5laJ3xMItxdvOifGdxUWp+QWKct68BL7q3+qrUipOsWujL/SQHil1RtPy AAAAAAAA --------------ms090109070906090107060200-- From nobody Mon Mar 28 08:53:44 2016 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 122E312DBFA; Mon, 28 Mar 2016 08:53:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] 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 WxUweeHhlnXu; Mon, 28 Mar 2016 08:53:27 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 465E712DB68; Mon, 28 Mar 2016 08:51:11 -0700 (PDT) X-AuditID: c6180641-f79fa6d0000057a9-4b-56f952cbf20a Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id F8.E2.22441.BC259F65; Mon, 28 Mar 2016 17:50:35 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0248.002; Mon, 28 Mar 2016 11:51:10 -0400 From: Kevin Ma J To: Stephen Farrell , "Niven - Jenkins, Ben (Nokia - GB)" Thread-Topic: [CDNi] Stephen Farrell's Discuss on draft-ietf-cdni-redirection-17: (with DISCUSS and COMMENT) Thread-Index: AQHRgDU1dnXrv5ODAEOGnCfGtVnh4J9pAHqAgAAHo4CAAASVgIAEw4kAgAFAnZA= Date: Mon, 28 Mar 2016 15:51:09 +0000 Message-ID: References: <20160317101014.1026.78717.idtracker@ietfa.amsl.com> <6B22150C-4A0E-4FFF-A48C-AEA2D881632E@niven-jenkins.co.uk> <56F40929.1020309@cs.tcd.ie> <774D3FF5-A163-472A-B441-ED3CD9C50724@alcatel-lucent.com> <56F80C06.1080402@cs.tcd.ie> In-Reply-To: <56F80C06.1080402@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0008_01D188E8.36CBA140" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrEIsWRmVeSWpSXmKPExsUyuXRPlO7poJ9hBk1HTSwe9v5jsVhwbgKb xZHWX4wWT2f/YbV43bmZxWLGn4nMFtP3XmN3YPdY232VzWPJkp9MHj+vT2L0uHvrElMASxSX TUpqTmZZapG+XQJXxpovfYwFyyIrHp57yNLAuCS4i5GTQ0LARKJr7xVWCFtM4sK99WxdjFwc QgJHGSWuLVjICuEsZ5SYvekaE0gVm4CWxOOvf8FsEYESicfXT7KB2MwC7xglzq0As4UFciXO Xz4MVZMn8XDPCRYI20/i7qnvjCA2i4CqxLI3l8E28wr4Srz69ZgZYtl3oDlnV4A1cApoStxr 7AcrYgQ67/upNUwQy8Qlbj2ZzwRxtojEw4un2SBsUYmXj/9BvaMkMef1NbChzAK9jBLbP3Uy Q2wTlDg58wnLBEbRWUhmzUJWNwtJHUSRtsTTm0+hbHmJ7W/nMEPY1hIzfh1kg7AVJaZ0P2SH sE0lXh/9yLiAkWMVI0dpcUFObrqR4SZGYOwek2Bz3MG4t9fzEKMAB6MSD++D8B9hQqyJZcWV uYcYVYBaH21YfYFRiiUvPy9VSYT3fuDPMCHelMTKqtSi/Pii0pzU4kOM0hwsSuK83z5eDhMS SE8sSc1OTS1ILYLJMnFwSjUwskr/evv+KGcAb+3KipvaXa+nfH69pK+WL7pYfZPkhOjNn77e aN1d+fJ50BH+ENuXzVlpe8qzj4rMbpzuxCau88DzwbRpv7QPys/8e+bRJP+iUvaEGfxTW7wf WAo/yvL3Xdi9KNp5G8OMJ3lPkmycTzT/2xB3/CvnIqG2k0tSk36lr+J4PdX4vBJLcUaioRZz UXEiAOGNAnnlAgAA Archived-At: Cc: "cdni@ietf.org" , "draft-ietf-cdni-redirection@ietf.org" , The IESG , "cdni-chairs@ietf.org" Subject: Re: [CDNi] Stephen Farrell's Discuss on draft-ietf-cdni-redirection-17: (with DISCUSS and COMMENT) X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 28 Mar 2016 15:53:32 -0000 ------=_NextPart_000_0008_01D188E8.36CBA140 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Hi Stephen, (as co-chair/shepherd) I agree we can probably make the text more privacy friendly. Unfortunately, neither Ben nor I will be in BA, though Francois and Ray will be, if we can get a f2f talk/call setup. In the case of logging, it was very helpful having you recommend folks with better security/privacy experience with whom we could discuss the issues. Is there someone you could suggest for the redirection privacy discussion? thanx! -- Kevin J. Ma > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > Sent: Sunday, March 27, 2016 12:36 PM > To: Niven - Jenkins, Ben (Nokia - GB) > Cc: Ben Niven-Jenkins; cdni@ietf.org; draft-ietf-cdni- > redirection@ietf.org; The IESG; cdni-chairs@ietf.org > Subject: Re: [CDNi] Stephen Farrell's Discuss on draft-ietf-cdni- > redirection-17: (with DISCUSS and COMMENT) > > > > On 24/03/16 15:51, Niven - Jenkins, Ben (Nokia - GB) wrote: > >> Can we agree that as-is, the draft is very much > >> aiming to meet the commercial requirements and is not taking account > >> or privacy requirements? > > > > Yes I think we can agree that. Ben > > Great. Then I'd suggest that the best next step may be to try get > a bunch of folks to chat in B-A about how to take privacy into > account and hopefully that'll also turn out to be a fine way to > resolve the discuss. (Or if not in B-A then a subsequent concall > maybe.) > > I'll certainly try to be there for that, but I expect it may be > possible to make good progress so long as you have someone there > who knows/cares a bit about privacy. > > It may also be worth pointing out here that, just as with the > cdni-logging draft, my goal here is not to try to force the CDNs > using this to be privacy friendly, since that's impossible and > (en)forcing such things against the will of an operator isn't > the IETF's responsibility. Even if we defined the protocol to > try do that, there'd be loads of ways to work around it and > companies trying to "monetize" my mouse-clicks would just do > that without asking anyone anyway. We do however need to define > a protocol that allows a willing CDN to be privacy friendly and > achieve interop for the function conerned. So that last is my goal > for this discussion. > > I assume the authors, WG chairs, document shepherd or responsible > AD can take the lead in finding a time/place/set of folks to chat. > > Cheers, > S. ------=_NextPart_000_0008_01D188E8.36CBA140 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVSDCCAyAw ggIIoAMCAQICAR0wDQYJKoZIhvcNAQEFBQAwOTELMAkGA1UEBhMCRkkxDzANBgNVBAoTBlNvbmVy YTEZMBcGA1UEAxMQU29uZXJhIENsYXNzMiBDQTAeFw0wMTA0MDYwNzI5NDBaFw0yMTA0MDYwNzI5 NDBaMDkxCzAJBgNVBAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFz czIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCQF0o1ncrwDZbHRPoWN/xIvb1/ gC01O+FvqGepvwMcTYxvMkfVQWikEwTBNQyahEP8XB3/ibPoFxjNkV/7iePqv05dfBsm03V57eaE 41flrSnE9Doo56V7hDZps/1edr2jLZnTkE4jKH0YY/FUOyaddluXQrL/rvBO7N05lU6DBn/nSUDI xQGyVFpmHT38+ek8Cp6BuHDwAYvkI1R8yK74kB4AlnLUVM9hI7zq+50CldG2uXE6aQg/D7ThQseI 9T+YqKe6HOBxce9YV4FQelxrdEYOgwOYw46obvJ2Mm4ng8Jz89wY6LST6nVEawRgIHFXh53zvqCQ Iz2KJOHaIdvDAgMBAAGjMzAxMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0OBAoECEqgqliE0148MAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEAWs6H+RZyFVdLHdmb56ImMOyTZ9/WLdI0r/c4 pc6rFrmrL3w1y6zQD7RMK/yA72uMkV82dvfbsxsZ6vSyEf1hcUS/KLM6Hb+zQ+ifv9wxCHGwnY3W NEcykMZlJPegSnwEc485bxeMcrW9S8h6+HuDwyhOnAnqZz+yZwQbwxTa+OdJJJHQHWr6YTnva+ch dQYH2BK0ISBwQnGB2jyaNr6mWw1qbJofkXv5+e9Cuk5OnswMjZTc2UWcXuxCUGOu9F3EsRLcyjuo Lp0UWgV1t+zXY+K6NbYECJHo2p2c9ma1GKwKplQmNDPSG8HUfxo6jguqMm7b/E8ln9kyx5ZacKzf TDCCBX0wggRloAMCAQICEQDR4D5bSO3Hngk/QN7hYcOLMA0GCSqGSIb3DQEBBQUAMDkxCzAJBgNV BAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFzczIgQ0EwHhcNMDcx MDE4MTI1MjAxWhcNMTkxMDE3MDUwNDExWjA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UE AwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIB AMK+6yfwIaPzaSZVfp3FVRaRXP3vIb9TgHot0pGMYzHw7CTww6XScnwQbfQ3t+XmfHnqjLWCi65I tqwA3GV17CpNX8GH9SBlK4GoRz6JI5UwFpB/6FcHSOcZrr9FZ7E3GwYq/t75rH2D+1665I+XZ75L jo1kB1c4VWk0Nj0TSO9P4tNmHqTPGrdeNjPUtAa9GAH9d4RQAEX1jF3oI7x+/jXh7VB7qTCNGdMJ jmhnXb88lxhTuylixcpecsHHltTbLaC0H2kD7OriUPEMPPCs81Mt8Bz17Ww5OXOAFshSsCPN4D7c 3TxHoLs1iuKYaIu+5b9y7tL6pe0S7fyYGKkmdtwoSxAgHNN/Fnct7W+A90m7UwW7XWjH1Mh1Fj+J Wov3F0fUTPHSiXk+TT2YqGHeOh7S+F4D4MHJHIzTjU3TlTazN19jY5szFPAtJmtTfImMMsJu7D0h ADnJoWjiUIMusDor8zagrC/kb2HCUQk5PotTubtn2txTuXZZNp1D5SDgPTJghSJRt8czu90VL6R4 pgd7gUY2BIbdeTXHlSw7sKMXNeVzH7RcWe/a6hBle3rQf5+ztCo3O3CLm1u5K7fsslESl1MpWtTw EhDcTwK7EpIvYtQ/aUN8Ddb8WHUBiJ1YFkveupD/RwGJBmr2X7KQarMCpgKIv7NHfirZ1fpoeDVN AgMBAAGjggGAMIIBfDBOBggrBgEFBQcBAQRCMEAwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jYS50cnVz dC50ZWxpYXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY2VyMA8GA1UdEwEB/wQFMAMBAf8wGQYD VR0gBBIwEDAOBgwrBgEEAYIPAgMBAQIwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBTwj1k4ALP1 j5qWDNXr+nuqF+gTEjCBuQYDVR0fBIGxMIGuMG+gbaBrhmlsZGFwOi8vY3JsLTEudHJ1c3QudGVs aWFzb25lcmEuY29tL2NuPVNvbmVyYSUyMENsYXNzMiUyMENBLG89U29uZXJhLGM9Rkk/Y2VydGlm aWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwO6A5oDeGNWh0dHA6Ly9jcmwtMi50cnVzdC50ZWxp YXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY3JsMBMGA1UdIwQMMAqACEqgqliE0148MA0GCSqG SIb3DQEBBQUAA4IBAQB7L2bVGhb4q6FZUtsGVNbneHh+Q5OmrXeyTfAHxWAg90PVlDgAY0+cBk4o PxOL9ZVGnhec070CdiGWHwrqqKER1uDC2H97BTr3jBzGl9mf/43MxbY7NJB9LHMONfDeF+V+8bMK ziBdedr0HocKuKtBbzbvChOkDOaAKZkqCVXEC4+x1AUwqx4++t6D3aSnC3+1CWt2+AXfXrIzjE6p AKqZcnJfrI2mqIatmAtaXvW12I8TyZR+ERIMcOVGIa4MYfxxSpz0TSSz94DWfLK3DlKiXaxT+Tqo k3yH1wZhC+6q/11vPLL52cPWk2HciFDaylK2u3watcxmk8kaxNEt6K5zMIIF5TCCA82gAwIBAgIQ Rv4txqXmZ+sXEhErG3pCQjANBgkqhkiG9w0BAQUFADA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMG A1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MjAeFw0xNTAxMDIwNTM3MTNaFw0xODAx MDIwNTM3MTJaMGIxETAPBgNVBAoMCEVyaWNzc29uMRMwEQYDVQQDDApLZXZpbiBNYSBKMSYwJAYJ KoZIhvcNAQkBFhdrZXZpbi5qLm1hQGVyaWNzc29uLmNvbTEQMA4GA1UEBRMHZWtlbm1hYTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKg3uQ6WXdh5TN9HJoOIHYYukINFpcsPgEKtxaIz v2737Ll5aQ24DuVAEgX+JhMSJnJaXuecLOzLLgSQzOYPIDIICzyuvf1EzlSAt2p3hOigAuPSe3dz Rx6gOciikLqTu7+Im+6cH2qvItGZgWPANxEUhw0SbnYeXUj0FzqDZ+oCVXIKieiu6LRjjOI30EZs /HaAeSElCMaINWYO/iZUwKh16jFhFGugPJqBvT+vGhSgJN241sFRI+SOmzk1RtBM0YAW6Z1X7SsI J1Jw8ZH/3re0U8rm1sw9XrXUmJMORKEutB8IGxy3ZJaGv73qOs3A0MQZa6E3HC6/BdjDt3drHHUC AwEAAaOCAb0wggG5MEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9jcmwudHJ1c3QudGVsaWEuY29t L2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2Mi5jcmwwgYIGCCsGAQUFBwEBBHYwdDAoBggrBgEFBQcw AYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBIBggrBgEFBQcwAoY8aHR0cDovL2NhLnRy dXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5kaXZpZHVhbGNhdjIuY2VyMCIGA1UdEQQb MBmBF2tldmluLmoubWFAZXJpY3Nzb24uY29tMFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDow OAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BT MB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQUPgEsMN2jlrM7D5XYI9lj kV6OWBMwHwYDVR0jBBgwFoAUsQ3K1Ea3r4YCwy9vBsoOdnF/SzcwDgYDVR0PAQH/BAQDAgWgMA0G CSqGSIb3DQEBBQUAA4ICAQDWznBvLyHvtiqNzzTG2tZrrR/HFgjB+o06op2xSxrofdQKLvtvWj0y yvI1IOzRTS9ZOMnvnoFvqQ+wI/YTbGsGGZSc7k2ExRljJFGAVEN0MsQqh+qDuSXEl97ND/B7Ad9T jfJ+viUGvVEXyU7x3Yr1FAhbGxrwS/UkG9/f4ucl/jT80x7uEAA1YJYicu9sWOz2wNLfOqQHFBR1 dqMSbtuuKRH62Q4LcQv960WCrAL//drojOGp5dCOImiduU6OWZhFR+dB49M1eXeh1pzV9FQ71esq +BROKOVjN3UPj/1v51ileSnV8zuqIc0MCPHUXhKEoITKtTOqNAXHHb2KqGOCkTNhfx+LUt+3CtXk DkRdeAGtgM/QpiTH0DYS/YdZ+WMCdTpffjoO1GICrL4IIaCSGRulSC66QgYvpUAobWNojIXCI24/ A1hmCM/0lSzMmbSAzbhLGpisP74e0F5kNfe5dB2rrd705mtH/q2slSZVQz/UWENuVToEEgvye3LI dgsKb1F++LUma16l3B6pAcBcUdWZvvRdJeDYaXr1IJzTbUu5Ub6ZegwJr3bNxvgw4vKi92PYjmzg TGmbFHuEdvqEK4Vgpb6pQwYmGANgu7k1MDm52s0ojVD3y7MSo8Z6J7+kQO7XRV72rPcCfoQTk0fQ XYv5Lb4gUm8/tms85d02yTCCBrYwggSeoAMCAQICEQCgDMvMm5mY7OI6cPR8wcBZMA0GCSqGSIb3 DQEBBQUAMDcxFDASBgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290 IENBIHYxMB4XDTE0MDUyNzA3NDYyMVoXDTI0MDUyNzA3NDYyMVowOjERMA8GA1UECgwIRXJpY3Nz b24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjIwggIiMA0GCSqGSIb3DQEB AQUAA4ICDwAwggIKAoICAQDaulPrX0iWU5+JOOqjddx4Gnl17DJhklkoXOgOSBMhW6FzGVt5RR7K Pv+rjt2YpbwdoqWSYa4VPkS/72vuQoWsvz2avWWXhPTdNzrB3zs5cJO7sKIyd+LRy4l/8kKK4iPm +Q18XyGF0xTuc5WS3WiMScJSxEKdIOP8xehBraHZabrGh9OxQHC4iBHkzD0YF3J/vBqBTr7blRzY f1h3j5a7qVIHCPfz+eCE175mResXDQRI7LvMiZtVaqitBl0oAJiJyeBmvEujBNsIEgUQ6JcQFG5n y0EazLywv7clwb7izvLgoXc6SFrd0D7TGJtkdldVJtMwDYXpyFMGAijT6uf8h2kuPIwrDgQFNEyI QZ4q52ZpRGwugC6sMxgHEDGjA/CxX9aC5Vi1EMRJiOGF6gV3T+V5yHDHSBBeQbVAXm8wSTDBfXQw dro/AXqET0mG6Rpe4q2FGBaauE8qHEO6qR3WAEgvjVfFU2k6xZx1qmvwhkXadxh6ZIMXzgb6Wpji vLnR0GEKNrgN2DXdvo+6eAt45Bhvmeka2TrJDxMLWiBy8QYgNeNXYQsuREnDsjWo6wF0LqbA5769 om9nn/uJzmzxb3nT1iHue5co9J93ta06kxiASHvcIzZwAOjKnmk0vR3IT7Qbzq2of3E1s18xo8DM 9D91Cak0Nq+RALtdv1uZKQIDAQABo4IBuDCCAbQwgYoGCCsGAQUFBwEBBH4wfDAtBggrBgEFBQcw AYYhaHR0cDovL29jc3AudHJ1c3QudGVsaWFzb25lcmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8v cmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5jZXIw EgYDVR0TAQH/BAgwBgEB/wIBADBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgGCCsGAQUF BwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzBLBgNVHR8E RDBCMECgPqA8hjpodHRwOi8vY3JsLTMudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJh cm9vdGNhdjEuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMC AQYwHQYDVR0OBBYEFLENytRGt6+GAsMvbwbKDnZxf0s3MB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM 1ev6e6oX6BMSMA0GCSqGSIb3DQEBBQUAA4ICAQBuByBsr6x3PZBCsmGbcSZ/XL+0tnVMblInoJgL 1Bh3PiRicgdo8l+6cvWp/ArBwMYNwSNyrvY9IewyaV8n65c5oN+l2JDUuzrdANVKnYxha7ZyCEiP mY98sB2bnZgxfJLXQYoRwI7pOOwfyoP2fCYVCd+xhsfysYiIl4ORzE3TpeppQ2yWkyBBmoHUXJh9 7ue6+bJ2fqnVUoOVMVnYYEtvsz67v7w2z3fvdcy04/RnoylxSenxADi1tY9iIydHMgyOu3dfzsxU 8AivMGG4aKStsCfUEyg0LlkbhqMrdness3e1qAEueSRNASLfpFwyRmzmiuNh9onzuhER2yYhK/6I eCs4HQHrPhkY8JUmhtmdL2uErOZWOs38FQhGWHWXI0g6SgdDObU0GEHju0MkDziOhm+BVwPZKN7B 7wD7OPj6vlLVo6d8vLGK9bywhEfXjxLIC3Qhtu5lJPTgIo5Bup+aBBjiJ/u9BfqryqZpudnWfG+w xC327rpNAq2OKdFsR92wbehSZD3mSSAemDVwGB2Yu0XHQYyyYfpWsGyGEyRSHKFhRwJdINPzWLI8 9wy4Wc+PgqyekkEmJqe6g4XSQFj4mqtwvqhP4dg2QCcKM/bh62RwfM7GeSS/LFGe84KmJjTDfvT8 c2rK8nEyZ/emOtwCGXQ6tZCByMNLxeDwU1TGbTGCAvMwggLvAgEBME4wOjERMA8GA1UECgwIRXJp Y3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjICEEb+Lcal5mfrFxIR Kxt6QkIwCQYFKw4DAhoFAKCCAXowGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTYwMzI4MTU1MTUwWjAjBgkqhkiG9w0BCQQxFgQUp017cgPUqOLt5hUfAdEqXU1P3eUw WwYJKoZIhvcNAQkPMU4wTDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwIC AUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowXQYJKwYBBAGCNxAEMVAwTjA6MREw DwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MgIQ Rv4txqXmZ+sXEhErG3pCQjBfBgsqhkiG9w0BCRACCzFQoE4wOjERMA8GA1UECgwIRXJpY3Nzb24x JTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjICEEb+Lcal5mfrFxIRKxt6QkIw DQYJKoZIhvcNAQEBBQAEggEAlI0WR9e/SEVjrLLaLCHjfUiZHBGRqP8Uc9B2HqQO1bcJ2KM529z/ OuQOtbWYTGFcWJxD8402/OKIALT5kjavEU4pRr+glMXmOM3lS/13VtLdvlEHDuA9kbViDwiyZJ/9 0RHfrkzHvn24bCVi2oF+sitkVyNL0DVkVeCPvdP4ur0YFEsZuOeTsceEGYZmliGoqIRzi9q0MT1H GTZ3Th+NisYPjG/7pxEaAMcZP4+/WrSPoqlN/4Xah/2JCyThJeBJlcTWYUirMuJFv3cU217UOtnP 5JJZoZ/l2AaKTz38PS3ooenmsWhnVNLP72mDahK2egjdbt7E07KY1ItE2De+cgAAAAAAAA== ------=_NextPart_000_0008_01D188E8.36CBA140-- From nobody Mon Mar 28 09:01:45 2016 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 4DE8712DB31; Mon, 28 Mar 2016 09:01:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 ygw5oF1JfgMw; Mon, 28 Mar 2016 09:01:36 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAD3612DAD1; Mon, 28 Mar 2016 09:01:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id CED94BE4D; Mon, 28 Mar 2016 17:01:11 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nmBVyw7w2IgC; Mon, 28 Mar 2016 17:01:06 +0100 (IST) Received: from [10.87.49.100] (unknown [86.41.49.138]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 4A540BE32; Mon, 28 Mar 2016 17:01:05 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1459180866; bh=0VC9/uBNSzScVLHIhxL6Oo2zUIJR+7j75i16TDNpwcw=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=qd7uZvCOslxeqpSzKNzvFJxVS6MNAIO1tHV2/29NCkF0/JVMSGq+ry3QCWNUyW9Kv /Uu7bOkDxw6d4tLkt6QLei+1eyFVRVT55/clGhOdidu0NVXQWS9yN1AAi+1a06xg+P rQAl8DQS/9bTcieMsDHChuCahsg7p6/hcE+AhloA= To: Kevin Ma J , "Niven - Jenkins, Ben (Nokia - GB)" References: <20160317101014.1026.78717.idtracker@ietfa.amsl.com> <6B22150C-4A0E-4FFF-A48C-AEA2D881632E@niven-jenkins.co.uk> <56F40929.1020309@cs.tcd.ie> <774D3FF5-A163-472A-B441-ED3CD9C50724@alcatel-lucent.com> <56F80C06.1080402@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56F95540.1030704@cs.tcd.ie> Date: Mon, 28 Mar 2016 17:01:04 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000602060403010501010208" Archived-At: Cc: "cdni@ietf.org" , "draft-ietf-cdni-redirection@ietf.org" , The IESG , "cdni-chairs@ietf.org" Subject: Re: [CDNi] Stephen Farrell's Discuss on draft-ietf-cdni-redirection-17: (with DISCUSS and COMMENT) X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 28 Mar 2016 16:01:44 -0000 This is a cryptographically signed message in MIME format. --------------ms000602060403010501010208 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 28/03/16 16:51, Kevin Ma J wrote: > Hi Stephen, >=20 > (as co-chair/shepherd) I agree we can probably make the text more pri= vacy=20 > friendly. Unfortunately, neither Ben nor I will be in BA, though Franc= ois and=20 > Ray will be, if we can get a f2f talk/call setup. In the case of loggi= ng, it=20 > was very helpful having you recommend folks with better security/privac= y=20 > experience with whom we could discuss the issues. Is there someone you= could=20 > suggest for the redirection privacy discussion? Not sure tbh. It mightn't be a good plan to go back to the same folks again, but I might ask 'em in B-A if they'd like to help some more. OTOH, I'd also hope that the WG would be better able to figure this out, having seen the kinds of changes that helped with cdni-logging. I'd also hope that folks involved in the WG could make the effort to reach out to colleagues of their own that are familiar with privacy. (It's not like this is the first time that a document from the CDNI WG has had privacy issues;-) S. >=20 > thanx! >=20 > -- Kevin J. Ma >=20 >> -----Original Message----- >> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] >> Sent: Sunday, March 27, 2016 12:36 PM >> To: Niven - Jenkins, Ben (Nokia - GB) >> Cc: Ben Niven-Jenkins; cdni@ietf.org; draft-ietf-cdni- >> redirection@ietf.org; The IESG; cdni-chairs@ietf.org >> Subject: Re: [CDNi] Stephen Farrell's Discuss on draft-ietf-cdni- >> redirection-17: (with DISCUSS and COMMENT) >> >> >> >> On 24/03/16 15:51, Niven - Jenkins, Ben (Nokia - GB) wrote: >>>> Can we agree that as-is, the draft is very much >>>> aiming to meet the commercial requirements and is not taking account= >>>> or privacy requirements? >>> >>> Yes I think we can agree that. Ben >> >> Great. Then I'd suggest that the best next step may be to try get >> a bunch of folks to chat in B-A about how to take privacy into >> account and hopefully that'll also turn out to be a fine way to >> resolve the discuss. (Or if not in B-A then a subsequent concall >> maybe.) >> >> I'll certainly try to be there for that, but I expect it may be >> possible to make good progress so long as you have someone there >> who knows/cares a bit about privacy. >> >> It may also be worth pointing out here that, just as with the >> cdni-logging draft, my goal here is not to try to force the CDNs >> using this to be privacy friendly, since that's impossible and >> (en)forcing such things against the will of an operator isn't >> the IETF's responsibility. Even if we defined the protocol to >> try do that, there'd be loads of ways to work around it and >> companies trying to "monetize" my mouse-clicks would just do >> that without asking anyone anyway. We do however need to define >> a protocol that allows a willing CDN to be privacy friendly and >> achieve interop for the function conerned. So that last is my goal >> for this discussion. >> >> I assume the authors, WG chairs, document shepherd or responsible >> AD can take the lead in finding a time/place/set of folks to chat. >> >> Cheers, >> S. >=20 --------------ms000602060403010501010208 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjAzMjgx NjAxMDRaMC8GCSqGSIb3DQEJBDEiBCA/9wL8B41Oy812A4PlMVIVNvYXa/pwi6TBPTjiBWI/ KjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQCYaymsJ+hC9v4NsKpeh7ZRDl41vN8fQGsJ2Ebjr5M9oyFVLQF7Mw1I 1bEM/lZlLaDyWRwaA77C/NxfhC4OyT/aK/iz500nRvviz4LjryiO/HcxrapTaDvZRzPj9aKk epeM2c2dZC190mSdkGYNpzwp5oamA3HDs8IEBmIVADmRVtKYj8WnVtHU0/B4ahZIL+kysQ2V 0DB73zkj0nUe+DNaneBy90azmzOkhd1JCXeljj+26GkhTk8pYdcjxHJO7suahwwWiMTxTFwk KjQ9sxRghRJUZBK/WpoDETlFONxA65aiDh0HIgmpoM7ZTYuopse6bt/HA+L+QKkEzy0nyNOl AAAAAAAA --------------ms000602060403010501010208-- From nobody Mon Mar 28 09:27:50 2016 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 F00AC12DB8F; Mon, 28 Mar 2016 09:27:48 -0700 (PDT) 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 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 jr1_HywH_m4b; Mon, 28 Mar 2016 09:27:46 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.145]) by ietfa.amsl.com (Postfix) with ESMTP id 8A63712DACF; Mon, 28 Mar 2016 09:27:46 -0700 (PDT) Received: from 97e1f3b1.skybroadband.com ([151.225.243.177] helo=[192.168.0.6]) by smtp04.mailcore.me with esmtpa (Exim 4.80.1) (envelope-from ) id 1aka13-0007kD-4F; Mon, 28 Mar 2016 17:27:45 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Ben Niven-Jenkins In-Reply-To: <56F95540.1030704@cs.tcd.ie> Date: Mon, 28 Mar 2016 17:27:46 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160317101014.1026.78717.idtracker@ietfa.amsl.com> <6B22150C-4A0E-4FFF-A48C-AEA2D881632E@niven-jenkins.co.uk> <56F40929.1020309@cs.tcd.ie> <774D3FF5-A163-472A-B441-ED3CD9C50724@alcatel-lucent.com> <56F80C06.1080402@cs.tcd.ie> <56F95540.1030704@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.2098) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Archived-At: Cc: "cdni-chairs@ietf.org" , "Niven - Jenkins, Ben \(Nokia - GB\)" , "draft-ietf-cdni-redirection@ietf.org" , The IESG , "cdni@ietf.org" Subject: Re: [CDNi] Stephen Farrell's Discuss on draft-ietf-cdni-redirection-17: (with DISCUSS and COMMENT) X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 28 Mar 2016 16:27:49 -0000 Stephen, Kevin, > On 28 Mar 2016, at 17:01, Stephen Farrell = wrote: > On 28/03/16 16:51, Kevin Ma J wrote: >> Hi Stephen, >>=20 >> (as co-chair/shepherd) I agree we can probably make the text more = privacy=20 >> friendly. Unfortunately, neither Ben nor I will be in BA, though = Francois and=20 >> Ray will be, if we can get a f2f talk/call setup. I=E2=80=99ll be in Singapore the week of IETF so it may be a little = difficult to schedule something that week, but lets see. The week = afterwards I have pretty good availability for a call. >> In the case of logging, it=20 >> was very helpful having you recommend folks with better = security/privacy=20 >> experience with whom we could discuss the issues. Is there someone = you could=20 >> suggest for the redirection privacy discussion? >=20 > Not sure tbh. It mightn't be a good plan to go back to the > same folks again, but I might ask 'em in B-A if they'd like > to help some more. OTOH, I'd also hope that the WG would be > better able to figure this out, having seen the kinds of > changes that helped with cdni-logging. I wasn=E2=80=99t involved in the cdni-logging draft, however I=E2=80=99m = sure those that were will contribute their experience & suggestions. I have a slight worry that we=E2=80=99ll end up playing a bit of a = guessing game and coming up with changes, to be told =E2=80=9Cnot good = enough, try again=E2=80=9D. Lets have the call/conversation you suggest = and hopefully we can come up with some changes that are good enough that = they only need a bit of tweaking, if anything. =20 > I'd also hope that > folks involved in the WG could make the effort to reach out > to colleagues of their own that are familiar with privacy. > (It's not like this is the first time that a document from > the CDNI WG has had privacy issues;-) Which could be an indication that the necessary expertise does not exist = in the WG. Thinking out loud, as the IETF/IESG is showing/expecting a higher degree = of privacy awareness than in the past, I wonder if having a set of known = =E2=80=9Cprivacy doctors=E2=80=9D might be an idea to get this sort of = review earlier in the document cycle? Ben From nobody Mon Mar 28 13:53:05 2016 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 8A2DE12D54D; Mon, 28 Mar 2016 13:53:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 h64jzz8LMwhJ; Mon, 28 Mar 2016 13:53:01 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 D6D0A12D145; Mon, 28 Mar 2016 13:53:00 -0700 (PDT) Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u2SKqxmU094504 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 28 Mar 2016 15:53:00 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.10] From: "Ben Campbell" To: "Ben Niven-Jenkins" Date: Mon, 28 Mar 2016 15:52:58 -0500 Message-ID: <756FD1BA-0AAE-4231-B0CB-460971F341BB@nostrum.com> In-Reply-To: <0EC8CD81-4F11-43E7-B52E-A7B0D88E8A10@niven-jenkins.co.uk> References: <20160316022119.12526.24798.idtracker@ietfa.amsl.com> <0EC8CD81-4F11-43E7-B52E-A7B0D88E8A10@niven-jenkins.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: cdni@ietf.org, draft-ietf-cdni-redirection@ietf.org, The IESG , cdni-chairs@ietf.org Subject: Re: [CDNi] Ben Campbell's No Objection on draft-ietf-cdni-redirection-17: (with COMMENT) X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 28 Mar 2016 20:53:04 -0000 Hi, Thanks for the response. Comments inline. I removed sections that do not seem to need further comment. Ben. On 24 Mar 2016, at 10:02, Ben Niven-Jenkins wrote: > >> On 16 Mar 2016, at 02:21, Ben Campbell wrote: >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> I have a few comments and questions: >> >> # Substantive: # >> >> - 3, last paragraph: "Any operational >> mechanisms this requires, e.g., private key distribution to >> surrogates and request routers in dCDNs, are outside the scope of >> this document. Further mechanisms to notify User Agents of trusted >> redirection are also outside the scope of this document." >> >> Is it in scope _somewhere_? As it is, this seems like an excuse to >> avoid >> HTTPS, which is not optimal. > > I believe it is in scope of the LURK BoF. > > I don’t understand your point about avoiding HTTPS. This is saying > that once a User Agent connects to a surrogate or request router over > HTTPS, that surrogate/request router better be able present the > correct certificate, complete a TLS handshake, etc otherwise content > delivery will fail. How a surrogate/request router manages to achieve > that is outside of the scope of the redirection interface this > document is specifying, similar to how a particular origin/web > server/etc (without CDNI) manages to achieve that is outside of the > scope of the HTTPS spec. I'm not suggesting this draft has to offer solutions; that's why I asked if the work was in scope "somewhere". But it seems like key management, especially in an interoperable fashion, is kind of an "elephant in the room" for secure redirection. > >> >> -4, first paragraph: >> Was any thought given to using or supporting HTTP/2? > > The authors gave it a bit of thought. It was not raised in the working > group from what I remember. > > I’m not sure HTTP/2 is particularly relevant to the specification. > The CDNI RI spec is essentially a HTTP API for exchanging CDNI > redirection requests/responses. Like any HTTP API it can feasibly be > run over HTTP, HTTPS & HTTP/2 as the semantics of all three are the > same. Is saying it is based on HTTP 1.1 really accurate then? Or maybe it's just based on HTTP in general? > >> >> -- step 1 after figure 1: >> I am I correct to infer an assumption that CDN A acts as the UAs DNS >> server? Is that assumption documented somewhere? > > No, CDN A does not act as the UA’s caching DNS server. The > text/diagram is a bit simplified to be able to show the main idea and > collapse the DNS & HTTP cases for brevity as they are largely the > same. > > When the document says: > > "The User Agent sends its (DNS or HTTP) request to CDN A.” > > what it really means is: > > “If HTTP redirection is being used between the UA & CDN A, the User > Agent sends its HTTP request to CDN A. If DNS redirection is being > used between the UA & CDN A, the User Agent sends a DNS request to its > configured DNS resolver, normal DNS caching infrastructure > interactions occur and if a suitable response is not already cached, > the last DNS resolver in the chain will send a DNS request to CDN A." > > If you think including the above text (or a modified version you’d > like to suggest) would help the clarity of the document I’m happy to > add it? > I probably misstated my question. I understand from your response that CDN A hosts the authoritative DNS server for domains it services. That's already covered in the definition of DNS based redirection, so that's all good. >> >> - 4.2, last paragraph (note) >> This explicitly makes an IPv6 only CDN non-compliant. Is that the >> intent? > > I’m not sure how it does that, could you explain? > > From my point of view the text is stating what formats for parsing > IPv4 & IPv6 addresses implementations must support. It does not say > that in order to use the CDNI redirection interface, one’s CDN must > use IPv4. Language of the form "MUST SUPPORT X encoded as Y" can be interpreted as "MUST support X and MUST support encoding as Y". Suggestion: OLD All implementations MUST support IPv4 addresses encoded as specified by the ’IPv4address’ rule in Section 3.2.2 of [RFC3986] and MUST support all IPv6 address formats specified in [RFC4291]. NEW All implementations that support IPv4 addresses MUST support the encoding specified by the ’IPv4address’ rule in Section 3.2.2 of [RFC3986]. Likewise, implementations that support IPv6 addresses MUST support all IPv6 address formats specified in [RFC4291]. END > >> >> - 4.4.1, table, entry for dns-only: >> The description says "MUST include RTs". That doesn't seem to >> consider >> error cases. > > My intention was to state what someone must do under normal > circumstances and I assumed that in the case of any error that > prevented them from doing that, that they would return an appropriate > error response instead. > > I can change "If True then dCDN MUST only use DNS redirection and MUST > include RTs to one or more surrogates in its RI response." > > to > > "If True then dCDN MUST only use DNS redirection and MUST include RTs > to one or more surrogates in any successful RI response." > > (or any other text you’d prefer) if that would alleviate your > concern? That works for me, thanks! > >> >> - 4.8, 3rd and 4th paragraph: >> I'm curious why they SHOULDs are not MUSTs. Are there times it might >> be >> reasonable to do something different; maybe even choosing not to send >> an >> error at all? I wonder if these should be of the form of "MUST send >> an >> error which SHOULD be XXX” > > You’re right I think we were a bit lax here. The only thing I was > thinking was maybe someone would want to return a different error code > for some reason we haven’t thought of. > > I prefer your suggestion of "MUST send which SHOULD be” so I’ve > changed the two paragraphs in my working copy of -18 to be: > "the dCDN MUST send an RI error response which SHOULD include an error > code of XXX” (with XXX replaced by the appropriate error code). That helps, thanks! > >> >> -5.1, 2nd to last paragraph: >> " In an environment where any such protection is required...," is a >> pretty weak recommendation. Would you consider making the default >> behavior secure? Or at least saying something to the effect of >> "Except in >> networks where similar protections are provided by some other >> means,…"? > > There has been quite a bit of discussion in the CDNI WG around this > wording and the WG decided to align the wording it used across all its > documents. The first document to progress to IESG was > draft-ietf-cdni-logging and the other CDNI drafts (including the > redirection one we are discussing) use the same wording as > draft-ietf-cdni-logging. > > I’m happy to continue to align the wording in this document with > that in draft-ietf-cdni-logging, but I would suggest we avoid > repeating the same discussion that is happening around > draft-ietf-cdni-logging here. > > Francois/Kevin - Can you help here? Has the discussion around this > text for draft-ietf-cdni-logging concluded yet? I see Alissa has a DISCUSS position on this (and also on cdni-logging). I will defer to the outcome of that discussion. > >> >> -5.2, First paragraph: >> I have trouble imagining situations where information passed over the >> RI >> might not be sensitive. > > Fair point. I have changed it to now read > > “Information passed over the RI ought to be considered personal and > sensitive." > > (I wanted to say “should be considered” but that would be > ambiguous about whether it is really should or SHOULD so I settled on > “ought to be” but if you can think of a better way to phrase it > I’m happy to use it) Modulo the ongoing discussion about lower-case usage of 2119 keywords, I'm fine with that :-) > >> -- third paragraph: >> I wish the text wasn't so dismissive of attempts to anonymize some RI >> request data. I agree doing so may reduce RI effectiveness in some >> cases. >> But that needs to be balanced with privacy needs, and that balance >> may >> not always land on the side of RI effectiveness. And the inability >> to >> correlate UAs between requests can be a feature in some >> circumstances. > > I agree where the balance lands may be different depending on > circumstances. If you can suggest specific edits/new text that comes > across less dismissive, I’ll incorporate them. > Suggestion: OLD While it is technically possible to mask some information in the RI Request, such as the last bits of the UA IP address, it is important to note that this will reduce the effectivess of the RI in certain cases. As an example, when the UA is behind a Carrier-grade NAT, and the RI is used to find an appropriate delivery node behind the same NAT, the full IP address might be necessary. Another potential issue when using IP anonymization is that it is no longer possible to correlate an RI Request with a subsequent UA request. NEW: While it is technically possible to mask some information in the RI Request, such as the last bits of the UA IP address, it is important to note that this will reduce the effectivess of the RI in certain cases. CDN deployments need to strike a balance between end-user privacy and the features impacted by such masking. This balance is likely to vary from one deployment to another. As an example, when the UA is behind a Carrier-grade NAT, and the RI is used to find an appropriate delivery node behind the same NAT, the full IP address might be necessary. Another potential issue when using IP anonymization is that it is no longer possible to correlate an RI Request with a subsequent UA request. >> >> # Editorial: # >> >> - General: >> There's quite a bit of repetition and redundant text, including >> redundant >> normative text. > > Do you think the repetition is harmful? I’m reluctant to rework the > document unless really necessary. I personally think such repetition has the potential to confuse the reader, or to make life harder for people who may update the draft in the future. But I recognize a lot of work has gone into getting people to agree to the current language, so I think it's your call. > [...] > >> >> - 4, 2nd paragraph: "The same HTTP interface is used for both DNS and >> HTTP redirection of >> User Agent requests,..." >>> From the rest of the sentence, I assume this means the RI uses the >>> same >> interface to communicate information about DNS and HTTP >> redirects—but the >> first part sounds like it is saying that the actual redirection (i.e. >> interacting with the UA) occurs over the same interface. > > I reworded to make the distinction clearer (hopefully), this is what I > have now: > > "The RI between the uCDN and dCDN uses the same HTTP interface to > encapsulate the attributes of both DNS and HTTP requests received from > User Agents…" That helps, thanks. [...] From nobody Mon Mar 28 16:19:59 2016 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 5DF5412D0E5; Mon, 28 Mar 2016 16:19:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001] 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 YBr_SndCc34q; Mon, 28 Mar 2016 16:19:54 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.143]) by ietfa.amsl.com (Postfix) with ESMTP id 7498112D0CF; Mon, 28 Mar 2016 16:19:54 -0700 (PDT) Received: from 97e1f3b1.skybroadband.com ([151.225.243.177] helo=[192.168.0.6]) by smtp04.mailcore.me with esmtpa (Exim 4.80.1) (envelope-from ) id 1akgRs-0005cY-D6; Tue, 29 Mar 2016 00:19:53 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Ben Niven-Jenkins In-Reply-To: <756FD1BA-0AAE-4231-B0CB-460971F341BB@nostrum.com> Date: Tue, 29 Mar 2016 00:19:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6554653B-7718-422A-A17A-0C2A095F22C5@niven-jenkins.co.uk> References: <20160316022119.12526.24798.idtracker@ietfa.amsl.com> <0EC8CD81-4F11-43E7-B52E-A7B0D88E8A10@niven-jenkins.co.uk> <756FD1BA-0AAE-4231-B0CB-460971F341BB@nostrum.com> To: Ben Campbell X-Mailer: Apple Mail (2.2098) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Archived-At: Cc: cdni@ietf.org, draft-ietf-cdni-redirection@ietf.org, The IESG , cdni-chairs@ietf.org Subject: Re: [CDNi] Ben Campbell's No Objection on draft-ietf-cdni-redirection-17: (with COMMENT) X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 28 Mar 2016 23:19:57 -0000 Hi Ben, > On 28 Mar 2016, at 21:52, Ben Campbell wrote: > On 24 Mar 2016, at 10:02, Ben Niven-Jenkins wrote: >>> On 16 Mar 2016, at 02:21, Ben Campbell wrote: >>> = ---------------------------------------------------------------------- >>> COMMENT: >>> = ---------------------------------------------------------------------- >>>=20 >>> I have a few comments and questions: >>>=20 >>> # Substantive: # >>>=20 >>> - 3, last paragraph: "Any operational >>> mechanisms this requires, e.g., private key distribution to >>> surrogates and request routers in dCDNs, are outside the scope of >>> this document. Further mechanisms to notify User Agents of trusted >>> redirection are also outside the scope of this document." >>>=20 >>> Is it in scope _somewhere_? As it is, this seems like an excuse to = avoid >>> HTTPS, which is not optimal. >>=20 >> I believe it is in scope of the LURK BoF. >>=20 >> I don=E2=80=99t understand your point about avoiding HTTPS. This is = saying that once a User Agent connects to a surrogate or request router = over HTTPS, that surrogate/request router better be able present the = correct certificate, complete a TLS handshake, etc otherwise content = delivery will fail. How a surrogate/request router manages to achieve = that is outside of the scope of the redirection interface this document = is specifying, similar to how a particular origin/web server/etc = (without CDNI) manages to achieve that is outside of the scope of the = HTTPS spec. >=20 > I'm not suggesting this draft has to offer solutions; that's why I = asked if the work was in scope "somewhere". But it seems like key = management, especially in an interoperable fashion, is kind of an = "elephant in the room" for secure redirection. Yes it is currently. Hopefully LURK will solve that in the future. = Non-standardised techniques similar to some of the LURK proposals are = deployed today, so the key management bit is solved IMO but are not = documented in any kind of formal document AFAIK.=20 >>> -4, first paragraph: >>> Was any thought given to using or supporting HTTP/2? >>=20 >> The authors gave it a bit of thought. It was not raised in the = working group from what I remember. >>=20 >> I=E2=80=99m not sure HTTP/2 is particularly relevant to the = specification. The CDNI RI spec is essentially a HTTP API for exchanging = CDNI redirection requests/responses. Like any HTTP API it can feasibly = be run over HTTP, HTTPS & HTTP/2 as the semantics of all three are the = same. >=20 > Is saying it is based on HTTP 1.1 really accurate then? Or maybe it's = just based on HTTP in general? Good point. I=E2=80=99ve dropped the 1.1 in my working copy of -18. >>> - 4.2, last paragraph (note) >>> This explicitly makes an IPv6 only CDN non-compliant. Is that the >>> intent? >>=20 >> I=E2=80=99m not sure how it does that, could you explain? >>=20 >> =46rom my point of view the text is stating what formats for parsing = IPv4 & IPv6 addresses implementations must support. It does not say that = in order to use the CDNI redirection interface, one=E2=80=99s CDN must = use IPv4. >=20 > Language of the form "MUST SUPPORT X encoded as Y" can be interpreted = as "MUST support X and MUST support encoding as Y". >=20 > Suggestion: > OLD > All implementations MUST support IPv4 addresses encoded as > specified by the =E2=80=99IPv4address=E2=80=99 rule in Section 3.2.2 = of [RFC3986] and > MUST support all IPv6 address formats specified in [RFC4291]. > NEW > All implementations that support IPv4 addresses MUST support > the encoding specified by the =E2=80=99IPv4address=E2=80=99 rule in > Section 3.2.2 of [RFC3986]. Likewise, implementations that support > IPv6 addresses MUST support all IPv6 address formats specified in = [RFC4291]. > END Thanks. I=E2=80=99ve adopted your suggested text in my working copy of = -18. >>> - 4.4.1, table, entry for dns-only: >>> The description says "MUST include RTs". That doesn't seem to = consider >>> error cases. >>=20 >> My intention was to state what someone must do under normal = circumstances and I assumed that in the case of any error that prevented = them from doing that, that they would return an appropriate error = response instead. >>=20 >> I can change "If True then dCDN MUST only use DNS redirection and = MUST include RTs to one or more surrogates in its RI response." >>=20 >> to >>=20 >> "If True then dCDN MUST only use DNS redirection and MUST include RTs = to one or more surrogates in any successful RI response." >>=20 >> (or any other text you=E2=80=99d prefer) if that would alleviate your = concern? >=20 > That works for me, thanks! Done. >>> -5.1, 2nd to last paragraph: >>> " In an environment where any such protection is required...," is a >>> pretty weak recommendation. Would you consider making the default >>> behavior secure? Or at least saying something to the effect of = "Except in >>> networks where similar protections are provided by some other >>> means,=E2=80=A6"? >>=20 >> There has been quite a bit of discussion in the CDNI WG around this = wording and the WG decided to align the wording it used across all its = documents. The first document to progress to IESG was = draft-ietf-cdni-logging and the other CDNI drafts (including the = redirection one we are discussing) use the same wording as = draft-ietf-cdni-logging. >>=20 >> I=E2=80=99m happy to continue to align the wording in this document = with that in draft-ietf-cdni-logging, but I would suggest we avoid = repeating the same discussion that is happening around = draft-ietf-cdni-logging here. >>=20 >> Francois/Kevin - Can you help here? Has the discussion around this = text for draft-ietf-cdni-logging concluded yet? >=20 > I see Alissa has a DISCUSS position on this (and also on = cdni-logging). I will defer to the outcome of that discussion. Seems it has already been resolved but I missed the edits to the latest = logging draft, so I=E2=80=99ve adopted those in my working copy of -18 = which should hopefully clear this from both yourself & Alissa when I = publish -18 (there=E2=80=99s a few more still to be agreed with Alissa & = Stephen). >>> -- third paragraph: >>> I wish the text wasn't so dismissive of attempts to anonymize some = RI >>> request data. I agree doing so may reduce RI effectiveness in some = cases. >>> But that needs to be balanced with privacy needs, and that balance = may >>> not always land on the side of RI effectiveness. And the inability = to >>> correlate UAs between requests can be a feature in some = circumstances. >>=20 >> I agree where the balance lands may be different depending on = circumstances. If you can suggest specific edits/new text that comes = across less dismissive, I=E2=80=99ll incorporate them. >>=20 >=20 > Suggestion: > OLD > While it is technically possible to mask some information in the RI > Request, such as the last bits of the UA IP address, it is important > to note that this will reduce the effectivess of the RI in certain > cases. As an example, when the UA is behind a Carrier-grade NAT, = and > the RI is used to find an appropriate delivery node behind the same > NAT, the full IP address might be necessary. Another potential = issue > when using IP anonymization is that it is no longer possible to > correlate an RI Request with a subsequent UA request. > NEW: > While it is technically possible to mask some information in the RI > Request, such as the last bits of the UA IP address, it is important > to note that this will reduce the effectivess of the RI in certain > cases. CDN deployments need to strike a balance between end-user > privacy and the features impacted by such masking. This balance is > likely to vary from one deployment to another. As an example, when > the UA is behind a Carrier-grade NAT, and the RI is used to find an > appropriate delivery node behind the same NAT, the full IP address > might be necessary. Another potential issue when using IP > anonymization is that it is no longer possible to correlate an > RI Request with a subsequent UA request. I=E2=80=99ve adopted your suggested text. Alissa has a comment on the = language here and Stephen has a discuss on privacy concerns in general = so I suspect this text might change some more before we=E2=80=99re = finished with the document. >>> # Editorial: # >>>=20 >>> - General: >>> There's quite a bit of repetition and redundant text, including = redundant >>> normative text. >>=20 >> Do you think the repetition is harmful? I=E2=80=99m reluctant to = rework the document unless really necessary. >=20 > I personally think such repetition has the potential to confuse the = reader, or to make life harder for people who may update the draft in = the future. But I recognize a lot of work has gone into getting people = to agree to the current language, so I think it's your call. I=E2=80=99ll probably need to give the document a full read through = after making changes to address Stephen=E2=80=99s discuss so I=E2=80=99ll = look out for obvious repetition then and have a go at reducing some of = it. Ben From nobody Wed Mar 30 08:43:45 2016 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 42F9612D760 for ; Wed, 30 Mar 2016 08:43:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 k8HIBNsGcb3r for ; Wed, 30 Mar 2016 08:43:37 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (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 BD02B12D780 for ; Wed, 30 Mar 2016 08:43:36 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id p65so188907393wmp.1 for ; Wed, 30 Mar 2016 08:43:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:message-id:date:to:mime-version; bh=7U2rs+cST4PC1DlXEdYFm13nafWu/2UAh798qo5NuQA=; b=m+6nAsAdQtELIBgWUnB8hcYLCTg9DP8xR3njg3qV3UVlLsSb99KgMusVA9umpY/+0D Vheulql/j+sECsE/MmhCY3Ckq/OhEcDm4nnIodFR24UjargbANr7iLziG+RAyPTT/1XG 8NXgqSMkptAHIGFsY823fHE1mgOVOsi1pGbhQAhVcZb+B+byMI/ndGrx2D7LWLOSBSu9 huuNFE6W9a66Lx4mwBwi+MXHg4iywmOLuI1ZpMkX/AoRZK1QavUUI5wiN6TBkrAmbuf7 E4Hwww5mVmBV5PzZAzF0JKkKWB5SJVGVwVDsEwwPJ0w3DI9wfO8fkDQ8TfTyzdtZ4IZI Gt9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:message-id:date:to:mime-version; bh=7U2rs+cST4PC1DlXEdYFm13nafWu/2UAh798qo5NuQA=; b=gwSzdMXj4oOJcHjf7ID5ahEo++TfME23vJgBwf3+kXRQp4rdJyPAIgkiUHp8X8e+Cd s1vp28gvQfCf8XDZbq+iqqG7PH72akeQ4sRRFD5nQWoOduXusrVm+YnsX2WpzIE0ZFPI u36/XyLi62+29LR8K0+c3NoTFpRjzMIG7bVh/8SermJB7UqkLQvz9QevuuqgKzvf4UR4 +aUP4MQ3ejv1SC0YKUxVe6pgoECOw0vPM/Mt4JNm6vXVdC0qfkYU3R5PM5hBlk8sjPxS J6dIe+ev20EsrqRANurmchcPicUfDngribQH8r1r3L88z4Q8SrFEHq5n7VvK9BsSgEK7 K3gA== X-Gm-Message-State: AD7BkJJErWxp0hqPC/kVxPKej2SkYGjLs6X4NwUFdhVrY60VLVZKpp7OYdbtUzYZ9Me+mg== X-Received: by 10.194.61.209 with SMTP id s17mr10303339wjr.35.1459352615315; Wed, 30 Mar 2016 08:43:35 -0700 (PDT) Received: from ams-flefauch-nitro3.cisco.com ([173.38.220.42]) by smtp.gmail.com with ESMTPSA id w125sm5017800wmw.18.2016.03.30.08.43.34 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 30 Mar 2016 08:43:34 -0700 (PDT) From: Francois Le Faucheur Content-Type: multipart/alternative; boundary="Apple-Mail=_6D8391CF-45A2-4FD1-BE6F-100F5C3D68CD" Message-Id: Date: Wed, 30 Mar 2016 17:43:30 +0200 To: "" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Subject: [CDNi] Draft agenda posted X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 30 Mar 2016 15:43:44 -0000 --Apple-Mail=_6D8391CF-45A2-4FD1-BE6F-100F5C3D68CD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello, The draft agenda for our CDNI WG meeting in Buenos Aires has been = posted: https://www.ietf.org/proceedings/95/agenda/agenda-95-cdni = Please let us know if you have any comments. Cheers Francois & Kevin= --Apple-Mail=_6D8391CF-45A2-4FD1-BE6F-100F5C3D68CD Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
Hello,

The draft agenda for our CDNI WG meeting in Buenos Aires has been posted:

Please let us know if you have any comments.

Cheers

Francois & Kevin
--Apple-Mail=_6D8391CF-45A2-4FD1-BE6F-100F5C3D68CD-- From nobody Wed Mar 30 09:12:33 2016 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 5C83B12D794 for ; Wed, 30 Mar 2016 09:12:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 4lGuodOAgZRX for ; Wed, 30 Mar 2016 09:12:31 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E834C12D5E2 for ; Wed, 30 Mar 2016 09:12:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=113; q=dns/txt; s=iport; t=1459354350; x=1460563950; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=kSy6he+HFpSrPz71axHLxRS5ujM8l2PIm0d1pQs/mus=; b=ITRdOFw6YNGzBSM45VSi4su6ktjyeckUX2stFMuY32/qz6Ii7JP1B9YD taR8pwJ8xgTReLFwszUajcTnK3/7VJpZZ5Vr2ufP1vEVH/31XbUSLudB5 VGNm+DX+llNoS31W+Hu49eKI5pi20TazWcPnRj0wpXtLbxQcfpVe2KZ3z U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BpBQBV+vtW/4sNJK1dgzOBVqsIjWKED?= =?us-ascii?q?YYNgU07EQEBAQEBAQFkJ4REBDo/EgE+QicEDogswTQBAQEBAQEBAQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEViBIIhFaFXIIrBZduAY4GgVABFYRNiFqPDwE2LINniC1+AQEB?= X-IronPort-AV: E=Sophos;i="5.24,417,1454976000"; d="scan'208";a="254641341" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Mar 2016 16:12:30 +0000 Received: from XCH-ALN-020.cisco.com (xch-aln-020.cisco.com [173.36.7.30]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u2UGCTM4024720 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 30 Mar 2016 16:12:29 GMT Received: from xch-rcd-020.cisco.com (173.37.102.30) by XCH-ALN-020.cisco.com (173.36.7.30) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 30 Mar 2016 11:12:29 -0500 Received: from xch-rcd-020.cisco.com ([173.37.102.30]) by XCH-RCD-020.cisco.com ([173.37.102.30]) with mapi id 15.00.1104.009; Wed, 30 Mar 2016 11:12:28 -0500 From: "Francois Le Faucheur (flefauch)" To: "" Thread-Topic: Presentation slides for CDNI WG in Buenos Aires Thread-Index: AQHRip70ECToMhQP90SVHMXnYyUY+g== Date: Wed, 30 Mar 2016 16:12:28 +0000 Message-ID: <02038C8B-3545-45BE-84C2-2F07586D2B59@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.155.20] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Le Faucheur Francois Subject: [CDNi] Presentation slides for CDNI WG in Buenos Aires X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 30 Mar 2016 16:12:32 -0000 To all presenters, Please send your slides to Kevin and I by Friday this week. Thanks Francois & Kevin From nobody Wed Mar 30 13:39:42 2016 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 9644112D114 for ; Wed, 30 Mar 2016 13:39:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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 SzojpGK7ItUL for ; Wed, 30 Mar 2016 13:39:39 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (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 6F9AB12D702 for ; Wed, 30 Mar 2016 13:39:39 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id 127so111139797wmu.1 for ; Wed, 30 Mar 2016 13:39:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-transfer-encoding:subject:date:references:to :message-id:mime-version; bh=k+0q48jmiUgrsoGq2+NkilqfV5J6XQ60Y7G/TsAbH7w=; b=dnZA8xaV62wONuBn+KY3gIBk18NrYPNWNe94OTpLmUgNmIBk5BPzQa8MvEDISvh3Op qB8hXDhtj8y/EZXWzMPluVAnSopSzYliz10ovQRIorP99IragEeTt9dKHaBzv3Nj1Giz PNn6CnUO0FdIiLbVOyh0Med6GxHR6rbGSQiXbk+5B8tMU4+PxuvPfXYJ/Ds7flbzlwHB t8HwlR7tkuez+cW0Y6n8n9nxZKhRoPKK0abQYjsxQifTz2FF5jplREaDJBWDpcpoY4sO 6pSZkCuE4y4rcf2auwNK4vYB1c2pqf/WKdGqLG+dGLdkrCjCKDRHaSqiUjho0B5guxT8 1c9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject:date :references:to:message-id:mime-version; bh=k+0q48jmiUgrsoGq2+NkilqfV5J6XQ60Y7G/TsAbH7w=; b=KXgumd6gF9PXzAbcaiCmCwhKni+q4tAKJSjGlcKqKuaeOLMdcZ/ACKtjNqqBpel5A7 DFDCh3dd/DV+RZJl6mX0W5X2ItNYedaZ4AZ5MDCjj4P/S64L4gpebvMB+v8f6y2WeDmj jhj+f0S9z3u7RLsf370ojhuuh69kNzF/wQ5bFKe7snkSwGe2KLC39zJWLi64m4w/yNQd A569BilakHUKXyXIwLbMt3vHyYeHZV6RjtiJtp/PJ95vMJk42A7zklTWrpul2SXBjMLE zC8COJfLK5iRDCsKvTPhHPf62UCJDmvOTMc3t+M97HKcMUAgSwB/LYAiHTE2taDbUo2Z c9yQ== X-Gm-Message-State: AD7BkJJZUN1lOP+RZvry7o0ttDCLoEc8Rep9zCv3YjNqAZarwZOfyQYQRSzZLgIJQ98O1A== X-Received: by 10.194.48.33 with SMTP id i1mr2178796wjn.53.1459370377941; Wed, 30 Mar 2016 13:39:37 -0700 (PDT) Received: from ams-flefauch-nitro3.cisco.com ([173.38.220.57]) by smtp.gmail.com with ESMTPSA id av3sm5630076wjc.44.2016.03.30.13.39.36 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 30 Mar 2016 13:39:37 -0700 (PDT) From: Francois Le Faucheur Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 30 Mar 2016 22:39:33 +0200 References: <20160330202243.4795.63685.idtracker@ietfa.amsl.com> To: "" Message-Id: <50540B1E-8F7C-4393-A5C6-BC58F077D931@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Subject: [CDNi] Fwd: [95all] Remote Participation for IETF 95: Meetecho Details X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 30 Mar 2016 20:39:41 -0000 Folks, FYI, for those that will participate remotely: >=20 > You may use Meetecho to participate in or just observe any session = being held in Buenos Aires. Here are the requirements and details.=20 >=20 > 1. Individuals are required to register for the meeting to observe or = participate via Meetecho. > - Individuals are required to enter registration I.D and name when = logging into a session via Meetecho > - The name must match that used to register for the meeting > - Please register even if you are participating as part of remote hub > - There is no cost to register as a remote attendee. Register = here:http://ietf.org/meeting/register.html.=20 >=20 > 2. Participation includes the ability to transmit audio and video via = the Meetecho virtual queue. > - The virtual queue permits remote attendees to share audio and video = if they choose, see here for more information: = https://ietf95.conf.meetecho.com/index.php/UMPIRE_Project > - Anyone who thinks they may want to participate by transmitting audio = / video should perform the Meetecho self-test prior to the start of the = session: http://ietf95.conf.meetecho.com/index.php/Self_Test >=20 > 3. WG Chairs will control the virtual queue, unmuting and muting of = remote participants >=20 > 4. The agenda for the WG sessions, as well as more detail on how to = use Meetecho to participate, can be found here: = https://ietf95.conf.meetecho.com/index.php/. Francois PS: Apologies for potential redundant posting, but this is useful info.= From nobody Wed Mar 30 13:52:10 2016 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 585BD12D87D; Wed, 30 Mar 2016 13:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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 IAv_imahV6el; Wed, 30 Mar 2016 13:52:03 -0700 (PDT) Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com [IPv6:2a00:1450:400c:c09::244]) (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 58E0512D506; Wed, 30 Mar 2016 13:52:03 -0700 (PDT) Received: by mail-wm0-x244.google.com with SMTP id p65so18256610wmp.1; Wed, 30 Mar 2016 13:52:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/ghlF0Nr8PK0vHxGN7AuOtNtkUbQtZ1CUqDLBAG+e7s=; b=WZg0myZWTg1xx9xkpm5nDLsG+gZ0evef1c84P5uv1dxqvHH+QAwIWM3QC8w3AR7Mmz V1i9h1qNaA8n4aFIm49Ju1i0OTLhKVROCYis04Pl3WkCNqFIjFmflxo+sulZBo8ZuZSj 58S9XJ/TpTLWK3sC5H0KovcdtH0GFkaqynQ+CGPjls6vQ2Osh38nS2ABmKA3nOWgXGqt RdNG89v4VxsdpXyfrQv0k/IuH/8v/3eqOGFuMFICSXfiY020Kn1LRUWrO8Bdz0rb1I59 sALZSqWS2pQ0Ev/SFHBwCfSBw2txz7qPtabwbNn4T8DD8lnXQnDdrBgF1hk7iQ8j/Bia XD0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/ghlF0Nr8PK0vHxGN7AuOtNtkUbQtZ1CUqDLBAG+e7s=; b=iWq2/aL1e+G/HfcchiW3Evqm9V0RZ7nkjN6EgITpUQD5dQ7/LRFl13PsG2+BakJhUI xVTPpWaQ6sQmktmDN0t1tVhLb2bjEVb4fpHvd6/Wy3eLJzg/ow7zi0ZtidSwmJLOsEyf Vuzc/44+AMoa7Cc7QjqickR+d2RYrD7ypffsYk3XRTFZ4AOslOGehrxQeM26Gx1VeEB2 zwM6J496BuihDbhvkM/yTwpp2PkuPTph8VfZAxUpVXnzGUfvX2y5aooW6xKOfl5mSTLY VDbF11wBcM5PmuSfm3PrgrfLgOmp6BW3ACSqQBPWMGH36++BjD3PGwFYT/vqpzjPmFf9 5NXA== X-Gm-Message-State: AD7BkJIq5TLxbszNxLBxl8NJnQZd2UfW2gW16NsLVLDiPAjzU2eu5PBtCcGXG8TSPV81/w== X-Received: by 10.28.224.132 with SMTP id x126mr12858684wmg.88.1459371121898; Wed, 30 Mar 2016 13:52:01 -0700 (PDT) Received: from ams-flefauch-nitro3.cisco.com ([173.38.220.57]) by smtp.gmail.com with ESMTPSA id m13sm6196607wma.3.2016.03.30.13.51.59 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 30 Mar 2016 13:52:01 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Francois Le Faucheur In-Reply-To: <20160325182719.17995.1066.idtracker@ietfa.amsl.com> Date: Wed, 30 Mar 2016 22:51:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6EC0B4CB-7F83-410F-9A0F-CCEF8F8436B4@gmail.com> References: <20160325182719.17995.1066.idtracker@ietfa.amsl.com> To: Alissa Cooper X-Mailer: Apple Mail (2.2104) Archived-At: Cc: draft-ietf-cdni-logging@ietf.org, cdni-chairs@ietf.org, Le Faucheur Francois , The IESG , "" Subject: Re: [CDNi] Alissa Cooper's Discuss on draft-ietf-cdni-logging-23: (with DISCUSS and COMMENT) X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 30 Mar 2016 20:52:05 -0000 Hello Alissa, Thanks for helping us close that document. Please see below: >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 >=20 > (1) > I am wondering about a potential inconsistency that I see in Section > 3.4.1. I see with the definition of the c-groupid field that there is > inherent support for reporting about clients as aggregates, which is > great, and even when reporting is done about individual clients there = are > a bunch of normative recommendations to try to reduce the chances that = a > logging field will be tied back to an individual user or host. = Excellent. > But then with the definition of the cs(insert_HTTP_header_name_here) > field and discussion about it, there is no equivalent normative = guidance > given about not including headers that could potentially be used to > identify an individual user or host. There is discussion about cookies > but none of it is normative, and cookies are not the only headers that > could be identifying. In fact, one of the examples given -- User-Agent = -- > is known to be identifying in some cases. >=20 > Given the extent to which the specification of c-groupid goes to = support > masking the identity of the host, I would expect normative guidance = about > the use of the header field. That is, if an implementation is using > c-groupid to represent an aggregate, it would make sense to me that it > MUST NOT include header fields that could be uniquely identifying. I = also > wonder if the recommendations about cookies in 3.4.1 could be made > normative. I will say that based on the use cases for these logs = listed > in 2.2.5 it's hard to understand what a uCDN needs headers like = cookies > for on a consistent basis; if they're needed for an occasional > troubleshoot, logging them consistently seems like overkill. This makes sense, and Stephen Farrell expressed the same concern. He = suggested to add the following text, which was incorporated in section = 3.4.1 right after the definition of all fields: "Logging some specific fields from HTTP requests and responses can introduce serious security and privacy risks. For example, cookies will often contain (months) long lived token values that can be used to log into a service as the relevant user. Similar values may be included in other header fields or within URLs or elsewhere in HTTP requests and responses. Centralising such values in a CDNI Logging File can therefore represent a significant increase in risk both for the user and the web service provider, but also for the CDNs involved. Implementations ought therefore to attempt to lower the probability of such bad outcomes e.g. by only allowing a configured set of headers to be added to CDNI Logging Records, or by not supporting wildcard selection of HTTP request/response fields to add. Such mechanisms can reduce the probability that security (or privacy) sensitive values are centralised in CDNI Logging Files. Also, when agreeing on which HTTP request/response fields are to be provided in CDNI Logging Files, the uCDN and dCDN administrators ought to consider these risks. =E2=80=9C Does that work for you? Or do you feel there ought to be some normative language (suggestions = welcome)? >=20 > (2) > Section 7.1 says: >=20 > "In an environment where any such protection is required, mutually > authenticated encrypted transport MUST be used to ensure > confidentiality of the logging information. To that end, TLS MUST = be > used (including authentication of the remote end) by the server-side > and the client-side of the CDNI Logging feed, as well as the server- > side and the client-side of the CDNI Logging File pull mechanism." >=20 > I know this text has been the subject of much discussion and careful > editing, and that I raised an issue on this on the redirection draft. > What I don't understand from reading this is whether the expectation = is > that all servers and clients implementing this specification will use > TLS. The first sentence seems to indicate that there will be cases = when > that is not true. The second sentence says MUST use, which means use = in > every case. Which is it? The answer to your question is meant to be conveyed by =E2=80=9CTo that = end=E2=80=9D. In other words: When protection is needed, authenticated encrypted = transport MUST be used. And when this is done, it MUST be achieved using = TLS. Can you leave with "to that end=E2=80=9D ? If not, how about: "In an environment where any such protection is required, mutually authenticated encrypted transport MUST be used to ensure confidentiality of the logging information, and to do so TLS MUST be used (including authentication of the remote end) by the server-side and the client-side of the CDNI Logging feed, as well as the server- side and the client-side of the CDNI Logging File pull mechanism." ? >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > (1) Per my first DISCUSS point above, I wonder if it makes sense to > specify a field where the dCDN could report a sanitized version of the > client User-Agent string. This would allow a uCDN to calculate the > "terminal type" KPI listed in 2.2.5.5.2 without requiring full, > potentially identifying User-Agent strings to be logged. I see the idea. But I think there are several fields which may contain user identifying = information. So how about we add a statement following the text provided by Stephen = to the effect that when fields (e.g. User Agent) contain = user-identifying information they SHOULD be sanitised to remove the = sensitive information while keeping non-sensitive information (e.g. = terminal type) and that the sanitisation is to be agreed upon by uCDN = and dCDN. >=20 > (2) I think the use of partial-time in 3.4.1 means that the timestamps > have no time zone information. It's not clear to me how the uCDN uses > these timestamps in an absolute sense anyway, but I'm wondering if = that > could create problems if the uCDN does not know what time zone the = dCDN > is in. The time information in that case is somewhat meaningless if = the > uCDN needs to know the actual time at which something occurred. I think this is a problem. We could either move to full-time, or stick = with partial-time but specify that time is always expressed in GMT. I = will poll the list on that. Thanks Francois From nobody Wed Mar 30 13:55:36 2016 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 50C5D12D935 for ; Wed, 30 Mar 2016 13:55:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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 1x177nP3kZLi for ; Wed, 30 Mar 2016 13:55:32 -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 8857C12D0B8 for ; Wed, 30 Mar 2016 13:55:32 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id 191so103687218wmq.0 for ; Wed, 30 Mar 2016 13:55:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-transfer-encoding:subject:date:references:to :message-id:mime-version; bh=J1RB1jt2gkLpYbcoh1TTCZgA2r8hcYwM3DQw9/dZbkg=; b=pEnBe8kCMRFoKP9MHZwDSzYqAFiBV+kaadI08zOU+mv1AzQOkN6CyvhZwUCJWJU507 0fuxavJg/PeUAddxS9CNj6Dx3kC3fLjF0mxvbaivuiUBTWBWzKq76tLIMKHFeLWmPbQw oc1ODGwX4bOHUHz2cu6QtF26wFk9Rgo831eBQdF2iiZXSgEiEWIHZRIYw85IaUCrHgxy KS+3vmWHXrczVvs6guki058HEkikpSWVn5twqG6+7ckTA9DdmhuoSvFwTh25+Px/tnnc t+odwb6qrgLuCxbI8xX0ri8wQvku//56HazvB+UbqVa3VxBMcsrROFC7Wy0EfNRhbk3t e4KQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject:date :references:to:message-id:mime-version; bh=J1RB1jt2gkLpYbcoh1TTCZgA2r8hcYwM3DQw9/dZbkg=; b=f2EA6qj65nPxTze1OFmWbOr6v7AcDN0X9lFKK0YKeGsju5qUdSLRWT9xeRx2T5CEtX krssPu1lR/rG986gkuaUd9WUiGuyH3emCmT7o6JI6fwrcuZEy9YjNMYcL3CiGRVhbing S1r6SAwfpJ4P0AEw1BnJznmdNx0UdhW6gozPLlMep9kQq0HhB4a0M/Onc8ck6NV0Pgpz +r/f+aV8JkedIjqXnTpBjag3T7gWTcidOENHbw6Huj9uPz0foYTuV+fwSlMsQt6vlub8 uLPwps0XMVrUB7BfQuRTuLqDDzIJCrnuVbihBrhpQucEto+/Ns+0YOCoSyZWUdOIv5od TEqA== X-Gm-Message-State: AD7BkJLEDBmjJ7ST4DvK5cP+JVwW8SDKqRJKDrLO3EL/1u2qhx2JsjSV226/XzsPJhMW0w== X-Received: by 10.28.222.67 with SMTP id v64mr26740829wmg.14.1459371331261; Wed, 30 Mar 2016 13:55:31 -0700 (PDT) Received: from ams-flefauch-nitro3.cisco.com ([173.38.220.57]) by smtp.gmail.com with ESMTPSA id i2sm5708303wje.22.2016.03.30.13.55.30 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 30 Mar 2016 13:55:30 -0700 (PDT) From: Francois Le Faucheur Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 30 Mar 2016 22:55:26 +0200 References: <6EC0B4CB-7F83-410F-9A0F-CCEF8F8436B4@gmail.com> To: "" Message-Id: <193235AB-5E08-4928-B148-311FD0825AAF@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Subject: [CDNi] Time Format for cdni-logging (Fwd: Alissa Cooper's Discuss on draft-ietf-cdni-logging-23) X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 30 Mar 2016 20:55:34 -0000 Folks, Any opinion of the question of time zone information in CDNI Logs = discussed below: >=20 >=20 >>=20 >> (2) I think the use of partial-time in 3.4.1 means that the = timestamps >> have no time zone information. It's not clear to me how the uCDN uses >> these timestamps in an absolute sense anyway, but I'm wondering if = that >> could create problems if the uCDN does not know what time zone the = dCDN >> is in. The time information in that case is somewhat meaningless if = the >> uCDN needs to know the actual time at which something occurred. >=20 > I think this is a problem. We could either move to full-time, or stick = with partial-time but specify that time is always expressed in GMT. I = will poll the list on that. Francois= From nobody Wed Mar 30 14:00:05 2016 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 D9B8812D936 for ; Wed, 30 Mar 2016 14:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] 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 J6MjKHLD-ELj for ; Wed, 30 Mar 2016 14:00:02 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01DC012D93F for ; Wed, 30 Mar 2016 14:00:01 -0700 (PDT) X-AuditID: c6180641-f79fa6d0000057a9-57-56fc3e2da18a Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id E3.3D.22441.D2E3CF65; Wed, 30 Mar 2016 22:59:25 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0248.002; Wed, 30 Mar 2016 17:00:00 -0400 From: Kevin Ma J To: Francois Le Faucheur , "" Thread-Topic: [CDNi] Time Format for cdni-logging (Fwd: Alissa Cooper's Discuss on draft-ietf-cdni-logging-23) Thread-Index: AQHRisaEahVR/7sXpkKoXD6dP7/+c59yeGiA Date: Wed, 30 Mar 2016 21:00:00 +0000 Message-ID: References: <6EC0B4CB-7F83-410F-9A0F-CCEF8F8436B4@gmail.com> <193235AB-5E08-4928-B148-311FD0825AAF@gmail.com> In-Reply-To: <193235AB-5E08-4928-B148-311FD0825AAF@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyuXRPoK6u3Z8wg5MNYhZPZ/9htXj/ejej A5PHzll32T2WLPnJFMAUxWWTkpqTWZZapG+XwJWx94tTwSquii07XjM1MC7h6GLk5JAQMJFo PnuHHcIWk7hwbz1bFyMXh5DAUUaJ0y9PQDnLGSX+LtnHDFLFJqAl8fjrXyYQW0QgSGLynC5G EFtYIF+i4/kDRoh4gcSe3RtZIGwjie8LT4PVswioSjQ19oHZvAK+EvPPX2EDsYWAeu/tbQPr 5RSwlbjz8i5YLyPQRd9PrQGrZxYQl7j1ZD4TxKUCEkv2nGeGsEUlXj7+xwphK0rs65/ODlGv I7Fg9yc2CFtbYtnC18wQewUlTs58wjKBUXQWkrGzkLTMQtIyC0nLAkaWVYwcpcUFObnpRoab GIHRcEyCzXEH495ez0OMAhyMSjy8Csa/w4RYE8uKK3MPMUpwMCuJ8CoZ/AkT4k1JrKxKLcqP LyrNSS0+xCjNwaIkzvvt4+UwIYH0xJLU7NTUgtQimCwTB6dUA+O8mIkcentrpz8KWeVQ3LLk /X0zuW9+IQ1CE0/MrHB8w+JiJ71jh/uan2djXZfcT1Le0v5FZCrfuie6ZSw8iyZsNdy8099x 1Yw7L3b2f/rmm1H2kvPJ2fN6ZwxeFT6daMS1u3bW+cXzz3gkBN5LPnz9XbnGWRY7y92nv053 9TOusHZrmvhPOotViaU4I9FQi7moOBEApPpj6IICAAA= Archived-At: Subject: Re: [CDNi] Time Format for cdni-logging (Fwd: Alissa Cooper's Discuss on draft-ietf-cdni-logging-23) X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 30 Mar 2016 21:00:04 -0000 I thought the time was always UTC? https://tools.ietf.org/html/rfc3339#section-4.1 > -----Original Message----- > From: CDNi [mailto:cdni-bounces@ietf.org] On Behalf Of Francois Le > Faucheur > Sent: Wednesday, March 30, 2016 4:55 PM > To: > Subject: [CDNi] Time Format for cdni-logging (Fwd: Alissa Cooper's Discus= s > on draft-ietf-cdni-logging-23) >=20 > Folks, >=20 > Any opinion of the question of time zone information in CDNI Logs > discussed below: >=20 > > > > > >> > >> (2) I think the use of partial-time in 3.4.1 means that the timestamps > >> have no time zone information. It's not clear to me how the uCDN uses > >> these timestamps in an absolute sense anyway, but I'm wondering if tha= t > >> could create problems if the uCDN does not know what time zone the dCD= N > >> is in. The time information in that case is somewhat meaningless if th= e > >> uCDN needs to know the actual time at which something occurred. > > > > I think this is a problem. We could either move to full-time, or stick > with partial-time but specify that time is always expressed in GMT. I wil= l > poll the list on that. >=20 > Francois > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From nobody Wed Mar 30 17:20:14 2016 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 2FDA612D1B4; Wed, 30 Mar 2016 17:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001] 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 umxjVqpmcoCZ; Wed, 30 Mar 2016 17:20:10 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.143]) by ietfa.amsl.com (Postfix) with ESMTP id 52B6612D1A1; Wed, 30 Mar 2016 17:20:09 -0700 (PDT) Received: from ppp-seco11pa2-46-193-137-75.wb.wifirst.net ([46.193.137.75] helo=[10.188.186.81]) by smtp04.mailcore.me with esmtpa (Exim 4.80.1) (envelope-from ) id 1alQLH-000Aeg-Dj; Thu, 31 Mar 2016 01:20:08 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Ben Niven-Jenkins In-Reply-To: <6EC0B4CB-7F83-410F-9A0F-CCEF8F8436B4@gmail.com> Date: Thu, 31 Mar 2016 01:20:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2DC5E6F0-F919-4DAB-BB43-3029C8A2B88A@niven-jenkins.co.uk> References: <20160325182719.17995.1066.idtracker@ietfa.amsl.com> <6EC0B4CB-7F83-410F-9A0F-CCEF8F8436B4@gmail.com> To: Francois Le Faucheur X-Mailer: Apple Mail (2.2098) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Archived-At: Cc: draft-ietf-cdni-logging@ietf.org, The IESG , "" , cdni-chairs@ietf.org Subject: Re: [CDNi] Alissa Cooper's Discuss on draft-ietf-cdni-logging-23: (with DISCUSS and COMMENT) X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 31 Mar 2016 00:20:13 -0000 All, I=E2=80=99m not an author on this document but for what it=E2=80=99s = worth my 2p opinion is inline below. > On 30 Mar 2016, at 21:51, Francois Le Faucheur = wrote: >> = ---------------------------------------------------------------------- >> DISCUSS: >> = ---------------------------------------------------------------------- >> (1) >> I am wondering about a potential inconsistency that I see in Section >> 3.4.1. I see with the definition of the c-groupid field that there is >> inherent support for reporting about clients as aggregates, which is >> great, and even when reporting is done about individual clients there = are >> a bunch of normative recommendations to try to reduce the chances = that a >> logging field will be tied back to an individual user or host. = Excellent. >> But then with the definition of the cs(insert_HTTP_header_name_here) >> field and discussion about it, there is no equivalent normative = guidance >> given about not including headers that could potentially be used to >> identify an individual user or host. There is discussion about = cookies >> but none of it is normative, and cookies are not the only headers = that >> could be identifying. In fact, one of the examples given -- = User-Agent -- >> is known to be identifying in some cases. >>=20 >> Given the extent to which the specification of c-groupid goes to = support >> masking the identity of the host, I would expect normative guidance = about >> the use of the header field. That is, if an implementation is using >> c-groupid to represent an aggregate, it would make sense to me that = it >> MUST NOT include header fields that could be uniquely identifying. I = also >> wonder if the recommendations about cookies in 3.4.1 could be made >> normative. I will say that based on the use cases for these logs = listed >> in 2.2.5 it's hard to understand what a uCDN needs headers like = cookies >> for on a consistent basis; if they're needed for an occasional >> troubleshoot, logging them consistently seems like overkill. >=20 > This makes sense, and Stephen Farrell expressed the same concern. He = suggested to add the following text, which was incorporated in section = 3.4.1 right after the definition of all fields: >=20 > "Logging some specific fields from HTTP requests and responses can > introduce serious security and privacy risks. For example, cookies > will often contain (months) long lived token values that can be used > to log into a service as the relevant user. Similar values may be > included in other header fields or within URLs or elsewhere in HTTP > requests and responses. Centralising such values in a CDNI Logging > File can therefore represent a significant increase in risk both for > the user and the web service provider, but also for the CDNs > involved. Implementations ought therefore to attempt to lower the > probability of such bad outcomes e.g. by only allowing a configured > set of headers to be added to CDNI Logging Records, or by not > supporting wildcard selection of HTTP request/response fields to = add. > Such mechanisms can reduce the probability that security (or = privacy) > sensitive values are centralised in CDNI Logging Files. Also, when > agreeing on which HTTP request/response fields are to be provided in > CDNI Logging Files, the uCDN and dCDN administrators ought to > consider these risks. > =E2=80=9C > Does that work for you? > Or do you feel there ought to be some normative language (suggestions = welcome)? IMO no, there should not be any normative language. Including normative = language presupposes that the set of header fields that expose user = identifiable material is well known and well defined and that is not the = case. Logging these fields exposes no more to the content provider than = they would obtain had they not used a CDN. CDNs (uCDNs & dCDNs in the = case of CDNI) are gateways/=E2=80=9Cdelegated origins=E2=80=9D operating = on behalf of the content provider. Who are we to tell a content provider = what they can & cannot log? A user agent under the control of the content provider (e.g. mobile = application) can send header fields containing anything the content = provider desires and there is no way to account for all those scenarios = in the document. It doesn=E2=80=99t even have to be header fields. I am = aware of deployments where the user=E2=80=99s username & zip code are = included as query parameters in the URL. That=E2=80=99s horrible for = user privacy but there=E2=80=99s no way to construct normative language = that will account for that case and no way to construct normative = language that accounts for user identifying header fields either because = from the perspective of the dCDN, the values of the URL or special = headers are opaque to the dCDN. Having some discussion of the risks (as the above text outlines) is fine = & probably a good thing IMO, trying to construct normative text serves = no purpose IMO except giving folks a warm fuzzy feeling that they=E2=80=99= ve protected user privacy without doing actually doing so. I thought our = role here was to produce interoperable standards, not to be the Internet = privacy police. I also wonder whether including normative text for this would actually = achieve the opposite of the desired effect - i.e. having normative text = may cause some implementers to assume that all privacy-related scenarios = have been covered and lead folks to follow the normative text and not = consider the privacy implications of header fields/etc not explicitly = called out by the document? >> (2) >> Section 7.1 says: >>=20 >> "In an environment where any such protection is required, mutually >> authenticated encrypted transport MUST be used to ensure >> confidentiality of the logging information. To that end, TLS MUST = be >> used (including authentication of the remote end) by the server-side >> and the client-side of the CDNI Logging feed, as well as the server- >> side and the client-side of the CDNI Logging File pull mechanism." >>=20 >> I know this text has been the subject of much discussion and careful >> editing, and that I raised an issue on this on the redirection draft. >> What I don't understand from reading this is whether the expectation = is >> that all servers and clients implementing this specification will use >> TLS. The first sentence seems to indicate that there will be cases = when >> that is not true. The second sentence says MUST use, which means use = in >> every case. Which is it? >=20 > The answer to your question is meant to be conveyed by =E2=80=9CTo = that end=E2=80=9D. > In other words: When protection is needed, authenticated encrypted = transport MUST be used. And when this is done, it MUST be achieved using = TLS. >=20 > Can you leave with "to that end=E2=80=9D ? >=20 > If not, how about: > "In an environment where any such protection is required, mutually > authenticated encrypted transport MUST be used to ensure > confidentiality of the logging information, and to do so TLS MUST be > used (including authentication of the remote end) by the server-side > and the client-side of the CDNI Logging feed, as well as the server- > side and the client-side of the CDNI Logging File pull mechanism." > ? Personally I find the relentless wordsmithing of this text to be = incredibly tiresome. Way back at the beginning we had text that = essentially said =E2=80=9Cyou need to authenticate & encrypt the = transport and in the absence of anything else use TLS=E2=80=9D and = we=E2=80=99ve slowly creeped towards =E2=80=9CMUST use TLS and nothing = else=E2=80=9D. I must have missed the memo that said that TLS is the = panacea for authenticated & encrypted transport and that VPNs and other = approaches have been deprecated in favour of TLS. I=E2=80=99ve said in other threads that for the CDNI documents I edit, = I=E2=80=99ll include whatever text is agreed for this logging document = and I will do that, but I strongly believe that folks will implement = what their customers=E2=80=99 want and that folks will deploy what makes = sense for them irrespective of what we write in our documents. Further = wordsmithing of the text is pure theatre IMO and adds no additional = value or clarity to the document IMO. IMO this is a good example of the IESG demanding edits that go beyond = what is required to meet the bar for Proposed Standard. I see nothing in = the original text (or any of the previous versions of the same section) = that contradicts the requirements for Proposed Standard described in = section 3.1 of RFC7127 or that will materially improve interoperability. = Changing the text does nothing except waste more time in tiresome debate = IMO. We should just accept the text as-is and move on to more important = things IMO. >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> (1) Per my first DISCUSS point above, I wonder if it makes sense to >> specify a field where the dCDN could report a sanitized version of = the >> client User-Agent string. This would allow a uCDN to calculate the >> "terminal type" KPI listed in 2.2.5.5.2 without requiring full, >> potentially identifying User-Agent strings to be logged. >=20 > I see the idea. > But I think there are several fields which may contain user = identifying information. > So how about we add a statement following the text provided by Stephen = to the effect that when fields (e.g. User Agent) contain = user-identifying information they SHOULD be sanitised to remove the = sensitive information while keeping non-sensitive information (e.g. = terminal type) and that the sanitisation is to be agreed upon by uCDN = and dCDN. Which assumes the uCDN & dCDN are in a position to know which fields = contains sensitive information and which do not, which in the general = case neither the uCDN or dCDN are in a position to know.=20 >> (2) I think the use of partial-time in 3.4.1 means that the = timestamps >> have no time zone information. It's not clear to me how the uCDN uses >> these timestamps in an absolute sense anyway, but I'm wondering if = that >> could create problems if the uCDN does not know what time zone the = dCDN >> is in. The time information in that case is somewhat meaningless if = the >> uCDN needs to know the actual time at which something occurred. >=20 > I think this is a problem. We could either move to full-time, or stick = with partial-time but specify that time is always expressed in GMT. I = will poll the list on that. My vote is for partial-time expressed in UTC. Ben From nobody Wed Mar 30 23:04:27 2016 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 A662212D9AB for ; Wed, 30 Mar 2016 23:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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 Xnh2IM8FJ1Wq for ; Wed, 30 Mar 2016 23:04:20 -0700 (PDT) Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (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 DE57912D962 for ; Wed, 30 Mar 2016 23:04:19 -0700 (PDT) Received: by mail-wm0-x243.google.com with SMTP id 139so20661065wmn.2 for ; Wed, 30 Mar 2016 23:04:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=haoWX6UDa3u7AmMUbeCx5crnvMKi6h8IPu5XZug7K/4=; b=KGf2QLDoMd3YQE76fLg5rltEOmiUn4ADt12lHJwobzG/6ypf3e08h6zqjCuJ3S5Irw I1GF88WEoUtor8+LFyyKYqWlWGoGJ4GSBv73ddJUU4l+A+0U6UW4DxJoAitJpy8GktPi XjqCduP3ADwPm6128GQrecnsJoysfg4WdSdpZIPTpBxOr6gaJyf+68Vdxx9F9Z6nUJoy EK2E0baCptV2SaSrjFHw70ERG5Oq3NS71KsgZjj742WrfwI3rdJQk/J7WQpWad/S+xQs 4oBsz4VtuHsnpkgb2fKRqYbXcP7D7zSi9PLXBFSHmjzFr6y63paGkZqEWjfXBSyzk1Qj XAtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=haoWX6UDa3u7AmMUbeCx5crnvMKi6h8IPu5XZug7K/4=; b=QyU4fGl3mY5wKRn085KC5tqxwwBeGQJcMBLfC8hLOstQGyNkxoFhJsNCc0xwL8Gbh8 M2tiKf2w/wCuSeGHHzZ0MkQFIrDjQwYRRaH8bdRbMw/BcUlrWZ7cnpeMjvOdTpZBGEKy 4XKTcCGPXEoaH04pxYfJYjrl4dztAe7He5EXu/it5bGJu9jXpjplD4lQAdTtM4x0rRa0 Hi/aDmRgNy4L1mXCG7N7Cl3UOENKI6jvMoVfDEgwSExGJL8DqtWcUZiGp0fd9SouAzxu lMjQluiHUD/P8lTU4HKwdvwRonp82cEtPJI2TxnEjfnsTd9kOVKnpsn9rLLQvGMb7n0j iTHA== X-Gm-Message-State: AD7BkJJFs/pWC3yyp+D/5e95SV5nXhl9ffnUDHfRetrF4DdHJ5+H0iPG8d+9OkupAqeYfw== X-Received: by 10.28.217.82 with SMTP id q79mr14265285wmg.29.1459404258461; Wed, 30 Mar 2016 23:04:18 -0700 (PDT) Received: from ams-flefauch-nitro3.cisco.com ([173.38.220.36]) by smtp.gmail.com with ESMTPSA id p125sm7761261wmd.16.2016.03.30.23.04.17 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 30 Mar 2016 23:04:17 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Francois Le Faucheur In-Reply-To: Date: Thu, 31 Mar 2016 08:04:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <82A260A5-5596-43B0-900A-A39FB36E7B4D@gmail.com> References: <6EC0B4CB-7F83-410F-9A0F-CCEF8F8436B4@gmail.com> <193235AB-5E08-4928-B148-311FD0825AAF@gmail.com> To: Ma Kevin , Niven-Jenkins Ben X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "" Subject: Re: [CDNi] Time Format for cdni-logging (Fwd: Alissa Cooper's Discuss on draft-ietf-cdni-logging-23) X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 31 Mar 2016 06:04:25 -0000 All, UTC works fine. But I think we need to be explicit about it. Let me know = if you have any comment on this proposed change: OLD: " o time: * format: TIME * field value: the time at which the processing of request = completed on the Surrogate. =E2=80=9C NEW: =E2=80=9C o time: * format: TIME * field value: the time, expressed in Coordinated Universal Time = (UTC), at which the processing of request completed on the Surrogate. " Francois > On 30 Mar 2016, at 23:00, Kevin Ma J wrote: >=20 > I thought the time was always UTC? >=20 > https://tools.ietf.org/html/rfc3339#section-4.1 >=20 >> -----Original Message----- >> From: CDNi [mailto:cdni-bounces@ietf.org] On Behalf Of Francois Le >> Faucheur >> Sent: Wednesday, March 30, 2016 4:55 PM >> To: >> Subject: [CDNi] Time Format for cdni-logging (Fwd: Alissa Cooper's = Discuss >> on draft-ietf-cdni-logging-23) >>=20 >> Folks, >>=20 >> Any opinion of the question of time zone information in CDNI Logs >> discussed below: >>=20 >>>=20 >>>=20 >>>>=20 >>>> (2) I think the use of partial-time in 3.4.1 means that the = timestamps >>>> have no time zone information. It's not clear to me how the uCDN = uses >>>> these timestamps in an absolute sense anyway, but I'm wondering if = that >>>> could create problems if the uCDN does not know what time zone the = dCDN >>>> is in. The time information in that case is somewhat meaningless if = the >>>> uCDN needs to know the actual time at which something occurred. >>>=20 >>> I think this is a problem. We could either move to full-time, or = stick >> with partial-time but specify that time is always expressed in GMT. I = will >> poll the list on that. >>=20 >> Francois >> _______________________________________________ >> 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 Thu Mar 31 04:06:08 2016 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 E2F6F12D599 for ; Thu, 31 Mar 2016 04:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] 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 Imgen-Uecw8p for ; Thu, 31 Mar 2016 04:06:05 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5455B12D597 for ; Thu, 31 Mar 2016 04:06:04 -0700 (PDT) X-AuditID: c6180641-f79fa6d0000057a9-d4-56fd04772a8c Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 5A.31.22441.7740DF65; Thu, 31 Mar 2016 13:05:28 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0248.002; Thu, 31 Mar 2016 07:06:03 -0400 From: Kevin Ma J To: Francois Le Faucheur Thread-Topic: [CDNi] Time Format for cdni-logging (Fwd: Alissa Cooper's Discuss on draft-ietf-cdni-logging-23) Thread-Index: AQHRisaEahVR/7sXpkKoXD6dP7/+c59yeGiAgADbZgCAABFFMw== Date: Thu, 31 Mar 2016 11:06:02 +0000 Message-ID: <82471A62-0004-420F-BBC5-6E87991F8290@ericsson.com> References: <6EC0B4CB-7F83-410F-9A0F-CCEF8F8436B4@gmail.com> <193235AB-5E08-4928-B148-311FD0825AAF@gmail.com> , <82A260A5-5596-43B0-900A-A39FB36E7B4D@gmail.com> In-Reply-To: <82A260A5-5596-43B0-900A-A39FB36E7B4D@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUyuXRPgm4Fy98wg0kXOCwWnJvAZvF09h9W i/evdzM6MHvsnHWX3WPJkp9MHj+vT2IMYI7isklJzcksSy3St0vgynjR/I6x4IpQxbPlcg2M d/m6GDk5JARMJD7NaGeBsMUkLtxbz9bFyMUhJHCUUWJ17xsmkISQwHJGiXubbEFsNgEticdf /4LFRQR0JdY1LgKzmQVCJB6/fAlmCwvkS3ybcIkFoqZAYs/ujUA2B5DtJNHerwoSZhFQlbj0 fRlYOa+AvcSBR29ZIPY+YZRoWQExk1PAVmJ12x82EJsR6Ljvp9ZA7RKXuPVkPhPE0QISS/ac Z4awRSVePv7HClFjIPH+3HxmCFtbYtnC18wQywQlTs58wjKBUXQWklGzkLTMQtIyC0nLAkaW VYwcpcUFObnpRoabGIHxcUyCzXEH495ez0OMAhyMSjy8C1r+hAmxJpYVV+YeYpTgYFYS4U1m /hsmxJuSWFmVWpQfX1Sak1p8iFGag0VJnPfbx8thQgLpiSWp2ampBalFMFkmDk6pBsbgn7fv noyYGHbv0h43Na3bIrEpG2Uu2k0T+rFt6rqY3ZYtz28KmNbuONebaNL7KWpNA0+L5KJdWuWX X7x9/oQngGvtmagbH8wlHItm+8UGfDlbramxpCj3RKqGZOWq9Vrx2wLnhlilpVXXBHhqvXP9 dJ73csmrWU8yDrdkPswKZNui5ODnFqPEUpyRaKjFXFScCACHEOmmiwIAAA== Archived-At: Cc: "" Subject: Re: [CDNi] Time Format for cdni-logging (Fwd: Alissa Cooper's Discuss on draft-ietf-cdni-logging-23) X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 31 Mar 2016 11:06:07 -0000 The proposed text works for me. thanx. Sent from my iPhone > On Mar 31, 2016, at 2:04 AM, Francois Le Faucheur wr= ote: >=20 > All, >=20 > UTC works fine. But I think we need to be explicit about it. Let me know = if you have any comment on this proposed change: >=20 >=20 > OLD: > " > o time: >=20 > * format: TIME >=20 > * field value: the time at which the processing of request complete= d on the Surrogate. > =93 >=20 > NEW: > =93 > o time: >=20 > * format: TIME >=20 > * field value: the time, expressed in Coordinated Universal Time (U= TC), at which the processing of request > completed on the Surrogate. > " >=20 > Francois >=20 >=20 >=20 >> On 30 Mar 2016, at 23:00, Kevin Ma J wrote: >>=20 >> I thought the time was always UTC? >>=20 >> https://tools.ietf.org/html/rfc3339#section-4.1 >>=20 >>> -----Original Message----- >>> From: CDNi [mailto:cdni-bounces@ietf.org] On Behalf Of Francois Le >>> Faucheur >>> Sent: Wednesday, March 30, 2016 4:55 PM >>> To: >>> Subject: [CDNi] Time Format for cdni-logging (Fwd: Alissa Cooper's Disc= uss >>> on draft-ietf-cdni-logging-23) >>>=20 >>> Folks, >>>=20 >>> Any opinion of the question of time zone information in CDNI Logs >>> discussed below: >>>=20 >>>>=20 >>>>=20 >>>>>=20 >>>>> (2) I think the use of partial-time in 3.4.1 means that the timestamp= s >>>>> have no time zone information. It's not clear to me how the uCDN uses >>>>> these timestamps in an absolute sense anyway, but I'm wondering if th= at >>>>> could create problems if the uCDN does not know what time zone the dC= DN >>>>> is in. The time information in that case is somewhat meaningless if t= he >>>>> uCDN needs to know the actual time at which something occurred. >>>>=20 >>>> I think this is a problem. We could either move to full-time, or stick >>> with partial-time but specify that time is always expressed in GMT. I w= ill >>> poll the list on that. >>>=20 >>> Francois >>> _______________________________________________ >>> CDNi mailing list >>> CDNi@ietf.org >>> https://www.ietf.org/mailman/listinfo/cdni >>=20 >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni >=20 From nobody Thu Mar 31 09:19:02 2016 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 70D0C12D1AD; Thu, 31 Mar 2016 09:19:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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 GHlt0tHRbzPG; Thu, 31 Mar 2016 09:18:58 -0700 (PDT) Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (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 75E1012D67C; Thu, 31 Mar 2016 09:18:58 -0700 (PDT) Received: by mail-wm0-x243.google.com with SMTP id 139so25059913wmn.2; Thu, 31 Mar 2016 09:18:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9aQd5qXHM03vFIqfVpUbgBTlj/OsdyrubXZEcf5HsUU=; b=KuJmkUbhUnEs8bSVNL9WP9rLDNQgojMvSIUdS10Kx/M2Fy/DMKmN9IeTLzVHru76K2 bP2SFM68VDH2X1ua6X85dsIs/LXaJ8KudFHZsU4vNXh2nXKevnIGgh3nCEbiDf+z21UY 9oNN8FpF3LGzY6OcWTjXMDXydMU8mz8j0fIfZ/N68JZ06SKgs1Icub0RUhP7CzOi92NC SfyxFTXd9461QL91hMjn5hFuRcKVNGTwvQEKLxoX+0O5VtYciVxLmIR7ov6p5A3ydF/5 VJs1RAeKo7Josr0U7dRRNpO97s6lTeHZspzAsLsWfzycJekUzYOUdXozBG08P+71YHfP VbxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9aQd5qXHM03vFIqfVpUbgBTlj/OsdyrubXZEcf5HsUU=; b=XLrsKuF85fFAVGoi13vWJsD6GGr5wDmBf5mG4xtntT1ir2fpKGbjbQov8oaKDAcbsw 7zUABAyQxTXg29FMnpm3gHQJ22JG+EwcEvmM2WVk1XeldroUTe8Tomeu+BkWdeCmC206 AHH9hwOGuK2bxsCEA2MW4qZ5zW7tUHQiggJKpc8HEUM4VOH9ZHs2nIYn8tl1YtOodtw1 OuFOsZxog6vC3q/dibc3woh6bMDJSdiiCDXNiW82Ay4FUOEW3wBoRKr5uRp3aU4lnnxE 03vHXhwdJRMhShcTV4ji38qEFWl0B7GWXF53winrs1nxfi38R8VxfASDgSzYVF5hLKvM j23Q== X-Gm-Message-State: AD7BkJK96Pi7gbaWzhwq+4TVr5o1kjJC6y6TwjcXjf4HiTqzPXAT0cNNa3tnzMcak5PB8Q== X-Received: by 10.194.62.110 with SMTP id x14mr18109306wjr.68.1459441136912; Thu, 31 Mar 2016 09:18:56 -0700 (PDT) Received: from ams-flefauch-nitro3.cisco.com ([173.38.220.42]) by smtp.gmail.com with ESMTPSA id hx10sm9728069wjb.25.2016.03.31.09.18.54 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 31 Mar 2016 09:18:56 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Francois Le Faucheur In-Reply-To: <2DC5E6F0-F919-4DAB-BB43-3029C8A2B88A@niven-jenkins.co.uk> Date: Thu, 31 Mar 2016 18:18:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <81D842F0-D3BF-40D7-801D-9B0532C51A84@gmail.com> References: <20160325182719.17995.1066.idtracker@ietfa.amsl.com> <6EC0B4CB-7F83-410F-9A0F-CCEF8F8436B4@gmail.com> <2DC5E6F0-F919-4DAB-BB43-3029C8A2B88A@niven-jenkins.co.uk> To: Alissa Cooper X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "" , cdni-chairs@ietf.org, Le Faucheur Francois , The IESG , draft-ietf-cdni-logging@ietf.org Subject: Re: [CDNi] Alissa Cooper's Discuss on draft-ietf-cdni-logging-23: (with DISCUSS and COMMENT) X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 31 Mar 2016 16:19:01 -0000 Alissa, (as document editor) In an attempt to work towards closure, please see below: > On 31 Mar 2016, at 02:20, Ben Niven-Jenkins = wrote: >=20 > All, >=20 > I=E2=80=99m not an author on this document but for what it=E2=80=99s = worth my 2p opinion is inline below. >=20 >> On 30 Mar 2016, at 21:51, Francois Le Faucheur = wrote: >>> = ---------------------------------------------------------------------- >>> DISCUSS: >>> = ---------------------------------------------------------------------- >>> (1) >>> I am wondering about a potential inconsistency that I see in Section >>> 3.4.1. I see with the definition of the c-groupid field that there = is >>> inherent support for reporting about clients as aggregates, which is >>> great, and even when reporting is done about individual clients = there are >>> a bunch of normative recommendations to try to reduce the chances = that a >>> logging field will be tied back to an individual user or host. = Excellent. >>> But then with the definition of the cs(insert_HTTP_header_name_here) >>> field and discussion about it, there is no equivalent normative = guidance >>> given about not including headers that could potentially be used to >>> identify an individual user or host. There is discussion about = cookies >>> but none of it is normative, and cookies are not the only headers = that >>> could be identifying. In fact, one of the examples given -- = User-Agent -- >>> is known to be identifying in some cases. >>>=20 >>> Given the extent to which the specification of c-groupid goes to = support >>> masking the identity of the host, I would expect normative guidance = about >>> the use of the header field. That is, if an implementation is using >>> c-groupid to represent an aggregate, it would make sense to me that = it >>> MUST NOT include header fields that could be uniquely identifying. I = also >>> wonder if the recommendations about cookies in 3.4.1 could be made >>> normative. I will say that based on the use cases for these logs = listed >>> in 2.2.5 it's hard to understand what a uCDN needs headers like = cookies >>> for on a consistent basis; if they're needed for an occasional >>> troubleshoot, logging them consistently seems like overkill. >>=20 >> This makes sense, and Stephen Farrell expressed the same concern. He = suggested to add the following text, which was incorporated in section = 3.4.1 right after the definition of all fields: >>=20 >> "Logging some specific fields from HTTP requests and responses can >> introduce serious security and privacy risks. For example, cookies >> will often contain (months) long lived token values that can be used >> to log into a service as the relevant user. Similar values may be >> included in other header fields or within URLs or elsewhere in HTTP >> requests and responses. Centralising such values in a CDNI Logging >> File can therefore represent a significant increase in risk both for >> the user and the web service provider, but also for the CDNs >> involved. Implementations ought therefore to attempt to lower the >> probability of such bad outcomes e.g. by only allowing a configured >> set of headers to be added to CDNI Logging Records, or by not >> supporting wildcard selection of HTTP request/response fields to = add. >> Such mechanisms can reduce the probability that security (or = privacy) >> sensitive values are centralised in CDNI Logging Files. Also, when >> agreeing on which HTTP request/response fields are to be provided in >> CDNI Logging Files, the uCDN and dCDN administrators ought to >> consider these risks. >> =E2=80=9C >> Does that work for you? >> Or do you feel there ought to be some normative language (suggestions = welcome)? >=20 > IMO no, there should not be any normative language. Including = normative language presupposes that the set of header fields that expose = user identifiable material is well known and well defined and that is = not the case. Logging these fields exposes no more to the content = provider than they would obtain had they not used a CDN. CDNs (uCDNs & = dCDNs in the case of CDNI) are gateways/=E2=80=9Cdelegated origins=E2=80=9D= operating on behalf of the content provider. Who are we to tell a = content provider what they can & cannot log? >=20 > A user agent under the control of the content provider (e.g. mobile = application) can send header fields containing anything the content = provider desires and there is no way to account for all those scenarios = in the document. It doesn=E2=80=99t even have to be header fields. I am = aware of deployments where the user=E2=80=99s username & zip code are = included as query parameters in the URL. That=E2=80=99s horrible for = user privacy but there=E2=80=99s no way to construct normative language = that will account for that case and no way to construct normative = language that accounts for user identifying header fields either because = from the perspective of the dCDN, the values of the URL or special = headers are opaque to the dCDN. >=20 > Having some discussion of the risks (as the above text outlines) is = fine & probably a good thing IMO, trying to construct normative text = serves no purpose IMO except giving folks a warm fuzzy feeling that = they=E2=80=99ve protected user privacy without doing actually doing so. = I thought our role here was to produce interoperable standards, not to = be the Internet privacy police. >=20 > I also wonder whether including normative text for this would actually = achieve the opposite of the desired effect - i.e. having normative text = may cause some implementers to assume that all privacy-related scenarios = have been covered and lead folks to follow the normative text and not = consider the privacy implications of header fields/etc not explicitly = called out by the document? I think Ben makes a valid argument that a CDN may not be in a position = to comply to any normative behaviour. So can we stick to the text above recommended by Stephen to discuss the = issue, raise concern and make suggestions and leave it at that? >=20 >=20 >>> (2) >>> Section 7.1 says: >>>=20 >>> "In an environment where any such protection is required, mutually >>> authenticated encrypted transport MUST be used to ensure >>> confidentiality of the logging information. To that end, TLS MUST = be >>> used (including authentication of the remote end) by the server-side >>> and the client-side of the CDNI Logging feed, as well as the server- >>> side and the client-side of the CDNI Logging File pull mechanism." >>>=20 >>> I know this text has been the subject of much discussion and careful >>> editing, and that I raised an issue on this on the redirection = draft. >>> What I don't understand from reading this is whether the expectation = is >>> that all servers and clients implementing this specification will = use >>> TLS. The first sentence seems to indicate that there will be cases = when >>> that is not true. The second sentence says MUST use, which means use = in >>> every case. Which is it? >>=20 >> The answer to your question is meant to be conveyed by =E2=80=9CTo = that end=E2=80=9D. >> In other words: When protection is needed, authenticated encrypted = transport MUST be used. And when this is done, it MUST be achieved using = TLS. >>=20 >> Can you leave with "to that end=E2=80=9D ? >>=20 >> If not, how about: >> "In an environment where any such protection is required, mutually >> authenticated encrypted transport MUST be used to ensure >> confidentiality of the logging information, and to do so TLS MUST be >> used (including authentication of the remote end) by the server-side >> and the client-side of the CDNI Logging feed, as well as the server- >> side and the client-side of the CDNI Logging File pull mechanism." >> ? >=20 > Personally I find the relentless wordsmithing of this text to be = incredibly tiresome. Way back at the beginning we had text that = essentially said =E2=80=9Cyou need to authenticate & encrypt the = transport and in the absence of anything else use TLS=E2=80=9D and = we=E2=80=99ve slowly creeped towards =E2=80=9CMUST use TLS and nothing = else=E2=80=9D. I must have missed the memo that said that TLS is the = panacea for authenticated & encrypted transport and that VPNs and other = approaches have been deprecated in favour of TLS. >=20 > I=E2=80=99ve said in other threads that for the CDNI documents I edit, = I=E2=80=99ll include whatever text is agreed for this logging document = and I will do that, but I strongly believe that folks will implement = what their customers=E2=80=99 want and that folks will deploy what makes = sense for them irrespective of what we write in our documents. Further = wordsmithing of the text is pure theatre IMO and adds no additional = value or clarity to the document IMO. >=20 > IMO this is a good example of the IESG demanding edits that go beyond = what is required to meet the bar for Proposed Standard. I see nothing in = the original text (or any of the previous versions of the same section) = that contradicts the requirements for Proposed Standard described in = section 3.1 of RFC7127 or that will materially improve interoperability. = Changing the text does nothing except waste more time in tiresome debate = IMO. We should just accept the text as-is and move on to more important = things IMO. I agree with Ben we need to move on on that topic. But I think the = change I propose above is purely editorial and for clarification, so = doing that last change should not destabilise anything. So, Alissa, = please tell us whether the current text is acceptable, or if you prefer = the proposed change text. >=20 >>> = ---------------------------------------------------------------------- >>> COMMENT: >>> = ---------------------------------------------------------------------- >>>=20 >>> (1) Per my first DISCUSS point above, I wonder if it makes sense to >>> specify a field where the dCDN could report a sanitized version of = the >>> client User-Agent string. This would allow a uCDN to calculate the >>> "terminal type" KPI listed in 2.2.5.5.2 without requiring full, >>> potentially identifying User-Agent strings to be logged. >>=20 >> I see the idea. >> But I think there are several fields which may contain user = identifying information. >> So how about we add a statement following the text provided by = Stephen to the effect that when fields (e.g. User Agent) contain = user-identifying information they SHOULD be sanitised to remove the = sensitive information while keeping non-sensitive information (e.g. = terminal type) and that the sanitisation is to be agreed upon by uCDN = and dCDN. >=20 > Which assumes the uCDN & dCDN are in a position to know which fields = contains sensitive information and which do not, which in the general = case neither the uCDN or dCDN are in a position to know.=20 This is back to the earlier point. Given, as Ben points out, that the = CDN may not be in a position to comply to any normative language and = given there is text recommended by Stephen to discuss the issue, raise = concern and make suggestions, can we leave it at that? >=20 >>> (2) I think the use of partial-time in 3.4.1 means that the = timestamps >>> have no time zone information. It's not clear to me how the uCDN = uses >>> these timestamps in an absolute sense anyway, but I'm wondering if = that >>> could create problems if the uCDN does not know what time zone the = dCDN >>> is in. The time information in that case is somewhat meaningless if = the >>> uCDN needs to know the actual time at which something occurred. >>=20 >> I think this is a problem. We could either move to full-time, or = stick with partial-time but specify that time is always expressed in = GMT. I will poll the list on that. >=20 > My vote is for partial-time expressed in UTC. As agreed on the list, the next rev will specify the =E2=80=9Ctime=E2=80=9D= field value is expressed in UTC, which solves the concern. Francois >=20 > Ben >=20 From nobody Thu Mar 31 10:11:21 2016 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 8CAE712D6A0 for ; Thu, 31 Mar 2016 10:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=uhmYCazd; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=r0TDRMqf 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 rbIhC0XRYjRQ for ; Thu, 31 Mar 2016 10:11:17 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 096EF12D67F for ; Thu, 31 Mar 2016 10:11:09 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 774BC22A92 for ; Thu, 31 Mar 2016 13:11:08 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute5.internal (MEProxy); Thu, 31 Mar 2016 13:11:08 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=jAlZ70GwIN4LsmHzQV131OZRG9g=; b=uhmYCa zdNy/Hbz/IImntezloQWitgaY9U6nuIwuVea2I9Ywh1ZQHeDGypcQD/bgkzwJJuQ l9iNbPQ/3DmLtFPPbuom1Z08P59l9hrIQ9bczdqeV1YCgkEBZ2MuOk8Zf9AGsGLW sofxQ8rQi4MDcJwJ6IpaUSDFJGXFMXjGl8UfE= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=jAlZ70GwIN4LsmH zQV131OZRG9g=; b=r0TDRMqfGiNVJMrfJXjhEQ9jLRGUSj0osCg2gFn7mh69v8S sDfVPSBJLvDdx7rlJEMN7YFYrYVKIMkinwFSoQVwT0UPDqh8a4d+cITjaVLbsJdP fztNU6E7GeLVJD2TqH0WuGnHMdTu4mFm6/lfyx3pdurCxrdiKn1TrrebVad4= X-Sasl-enc: sJJAVeh5CEC+arHDH5ni+KIcQhTE7nQAu6X1U6ikfzkU 1459444268 Received: from dhcp-171-68-20-39.cisco.com (dhcp-171-68-20-39.cisco.com [171.68.20.39]) by mail.messagingengine.com (Postfix) with ESMTPA id 952BEC00024; Thu, 31 Mar 2016 13:11:07 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alissa Cooper In-Reply-To: <2DC5E6F0-F919-4DAB-BB43-3029C8A2B88A@niven-jenkins.co.uk> Date: Thu, 31 Mar 2016 10:11:51 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5D3D0ADA-18AD-481F-B085-424B81A4CF90@cooperw.in> References: <20160325182719.17995.1066.idtracker@ietfa.amsl.com> <6EC0B4CB-7F83-410F-9A0F-CCEF8F8436B4@gmail.com> <2DC5E6F0-F919-4DAB-BB43-3029C8A2B88A@niven-jenkins.co.uk> To: Ben Niven-Jenkins X-Mailer: Apple Mail (2.3112) Archived-At: Cc: Francois Le Faucheur , draft-ietf-cdni-logging@ietf.org, IESG , "" , cdni-chairs@ietf.org Subject: Re: [CDNi] Alissa Cooper's Discuss on draft-ietf-cdni-logging-23: (with DISCUSS and COMMENT) X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 31 Mar 2016 17:11:19 -0000 Hi Ben and all, > On Mar 30, 2016, at 5:20 PM, Ben Niven-Jenkins = wrote: >=20 > All, >=20 > I=E2=80=99m not an author on this document but for what it=E2=80=99s = worth my 2p opinion is inline below. >=20 >> On 30 Mar 2016, at 21:51, Francois Le Faucheur = wrote: >>> = ---------------------------------------------------------------------- >>> DISCUSS: >>> = ---------------------------------------------------------------------- >>> (1) >>> I am wondering about a potential inconsistency that I see in Section >>> 3.4.1. I see with the definition of the c-groupid field that there = is >>> inherent support for reporting about clients as aggregates, which is >>> great, and even when reporting is done about individual clients = there are >>> a bunch of normative recommendations to try to reduce the chances = that a >>> logging field will be tied back to an individual user or host. = Excellent. >>> But then with the definition of the cs(insert_HTTP_header_name_here) >>> field and discussion about it, there is no equivalent normative = guidance >>> given about not including headers that could potentially be used to >>> identify an individual user or host. There is discussion about = cookies >>> but none of it is normative, and cookies are not the only headers = that >>> could be identifying. In fact, one of the examples given -- = User-Agent -- >>> is known to be identifying in some cases. >>>=20 >>> Given the extent to which the specification of c-groupid goes to = support >>> masking the identity of the host, I would expect normative guidance = about >>> the use of the header field. That is, if an implementation is using >>> c-groupid to represent an aggregate, it would make sense to me that = it >>> MUST NOT include header fields that could be uniquely identifying. I = also >>> wonder if the recommendations about cookies in 3.4.1 could be made >>> normative. I will say that based on the use cases for these logs = listed >>> in 2.2.5 it's hard to understand what a uCDN needs headers like = cookies >>> for on a consistent basis; if they're needed for an occasional >>> troubleshoot, logging them consistently seems like overkill. >>=20 >> This makes sense, and Stephen Farrell expressed the same concern. He = suggested to add the following text, which was incorporated in section = 3.4.1 right after the definition of all fields: >>=20 >> "Logging some specific fields from HTTP requests and responses can >> introduce serious security and privacy risks. For example, cookies >> will often contain (months) long lived token values that can be used >> to log into a service as the relevant user. Similar values may be >> included in other header fields or within URLs or elsewhere in HTTP >> requests and responses. Centralising such values in a CDNI Logging >> File can therefore represent a significant increase in risk both for >> the user and the web service provider, but also for the CDNs >> involved. Implementations ought therefore to attempt to lower the >> probability of such bad outcomes e.g. by only allowing a configured >> set of headers to be added to CDNI Logging Records, or by not >> supporting wildcard selection of HTTP request/response fields to = add. >> Such mechanisms can reduce the probability that security (or = privacy) >> sensitive values are centralised in CDNI Logging Files. Also, when >> agreeing on which HTTP request/response fields are to be provided in >> CDNI Logging Files, the uCDN and dCDN administrators ought to >> consider these risks. >> =E2=80=9C >> Does that work for you? >> Or do you feel there ought to be some normative language (suggestions = welcome)? >=20 > IMO no, there should not be any normative language. Including = normative language presupposes that the set of header fields that expose = user identifiable material is well known and well defined and that is = not the case. Logging these fields exposes no more to the content = provider than they would obtain had they not used a CDN. CDNs (uCDNs & = dCDNs in the case of CDNI) are gateways/=E2=80=9Cdelegated origins=E2=80=9D= operating on behalf of the content provider. Who are we to tell a = content provider what they can & cannot log? >=20 > A user agent under the control of the content provider (e.g. mobile = application) can send header fields containing anything the content = provider desires and there is no way to account for all those scenarios = in the document. It doesn=E2=80=99t even have to be header fields. I am = aware of deployments where the user=E2=80=99s username & zip code are = included as query parameters in the URL. That=E2=80=99s horrible for = user privacy but there=E2=80=99s no way to construct normative language = that will account for that case and no way to construct normative = language that accounts for user identifying header fields either because = from the perspective of the dCDN, the values of the URL or special = headers are opaque to the dCDN. >=20 > Having some discussion of the risks (as the above text outlines) is = fine & probably a good thing IMO, trying to construct normative text = serves no purpose IMO except giving folks a warm fuzzy feeling that = they=E2=80=99ve protected user privacy without doing actually doing so. = I thought our role here was to produce interoperable standards, not to = be the Internet privacy police. >=20 > I also wonder whether including normative text for this would actually = achieve the opposite of the desired effect - i.e. having normative text = may cause some implementers to assume that all privacy-related scenarios = have been covered and lead folks to follow the normative text and not = consider the privacy implications of header fields/etc not explicitly = called out by the document? Maybe I wasn=E2=80=99t clear in articulating my point. The spec clearly = supports the ability for the dCDN to decide to send logs about an = aggregate of clients. That isn=E2=80=99t =E2=80=9Ctelling a content = provider=E2=80=9D what to log or not, but it is providing support for a = dCDN to not report a piece of data that would have been delivered to the = content provider if there were no CDN. If that is the point of = specifying c-groupid the way that it is specified =E2=80=94 including = normative recommendations clearly designed to ensure that the c-groupid = does indeed identify an aggregate and not a single client =E2=80=94 then = it seems to me to undermine the whole point of providing an identifier = for an aggregate if the dCDN then includes a bunch of header fields that = identify an individual client. The spec shouldn=E2=80=99t pretend to = support provision for some protections that it actually doesn=E2=80=99t = provide given the way it=E2=80=99s expected to be implemented. I think = at a minimum the draft needs to point this out in the paragraph Francois = quoted. Personally I don=E2=80=99t think making the recommendations in = the text about cookies normative gives anyone a fuzzier feeling than the = text does as-is, but I=E2=80=99m not going to say that it=E2=80=99s not = worth holding up the document over.=20 >=20 >=20 >>> (2) >>> Section 7.1 says: >>>=20 >>> "In an environment where any such protection is required, mutually >>> authenticated encrypted transport MUST be used to ensure >>> confidentiality of the logging information. To that end, TLS MUST = be >>> used (including authentication of the remote end) by the server-side >>> and the client-side of the CDNI Logging feed, as well as the server- >>> side and the client-side of the CDNI Logging File pull mechanism." >>>=20 >>> I know this text has been the subject of much discussion and careful >>> editing, and that I raised an issue on this on the redirection = draft. >>> What I don't understand from reading this is whether the expectation = is >>> that all servers and clients implementing this specification will = use >>> TLS. The first sentence seems to indicate that there will be cases = when >>> that is not true. The second sentence says MUST use, which means use = in >>> every case. Which is it? >>=20 >> The answer to your question is meant to be conveyed by =E2=80=9CTo = that end=E2=80=9D. >> In other words: When protection is needed, authenticated encrypted = transport MUST be used. And when this is done, it MUST be achieved using = TLS. >>=20 >> Can you leave with "to that end=E2=80=9D ? >>=20 >> If not, how about: >> "In an environment where any such protection is required, mutually >> authenticated encrypted transport MUST be used to ensure >> confidentiality of the logging information, and to do so TLS MUST be >> used (including authentication of the remote end) by the server-side >> and the client-side of the CDNI Logging feed, as well as the server- >> side and the client-side of the CDNI Logging File pull mechanism." >> ? >=20 > Personally I find the relentless wordsmithing of this text to be = incredibly tiresome. Way back at the beginning we had text that = essentially said =E2=80=9Cyou need to authenticate & encrypt the = transport and in the absence of anything else use TLS=E2=80=9D and = we=E2=80=99ve slowly creeped towards =E2=80=9CMUST use TLS and nothing = else=E2=80=9D. I must have missed the memo that said that TLS is the = panacea for authenticated & encrypted transport and that VPNs and other = approaches have been deprecated in favour of TLS. >=20 > I=E2=80=99ve said in other threads that for the CDNI documents I edit, = I=E2=80=99ll include whatever text is agreed for this logging document = and I will do that, but I strongly believe that folks will implement = what their customers=E2=80=99 want and that folks will deploy what makes = sense for them irrespective of what we write in our documents. Further = wordsmithing of the text is pure theatre IMO and adds no additional = value or clarity to the document IMO. >=20 > IMO this is a good example of the IESG demanding edits that go beyond = what is required to meet the bar for Proposed Standard. I see nothing in = the original text (or any of the previous versions of the same section) = that contradicts the requirements for Proposed Standard described in = section 3.1 of RFC7127 or that will materially improve interoperability. = Changing the text does nothing except waste more time in tiresome debate = IMO. We should just accept the text as-is and move on to more important = things IMO. I did not demand any edits. I asked a question because the text isn=E2=80=99= t clear. I don=E2=80=99t care if the standard is MUST use TLS (which = means all the time) or SHOULD use TLS (which means sometimes). =E2=80=9CMU= ST use TLS sometimes=E2=80=9D is not a legitimate choice. This is = relevant for the IESG to comment on because MUST means something = specific everywhere we use it, not just in this document, and I=E2=80=99d = rather not establish a precedent that MUST means =E2=80=9Cuse it = sometimes.=E2=80=9D Alissa >=20 >>> = ---------------------------------------------------------------------- >>> COMMENT: >>> = ---------------------------------------------------------------------- >>>=20 >>> (1) Per my first DISCUSS point above, I wonder if it makes sense to >>> specify a field where the dCDN could report a sanitized version of = the >>> client User-Agent string. This would allow a uCDN to calculate the >>> "terminal type" KPI listed in 2.2.5.5.2 without requiring full, >>> potentially identifying User-Agent strings to be logged. >>=20 >> I see the idea. >> But I think there are several fields which may contain user = identifying information. >> So how about we add a statement following the text provided by = Stephen to the effect that when fields (e.g. User Agent) contain = user-identifying information they SHOULD be sanitised to remove the = sensitive information while keeping non-sensitive information (e.g. = terminal type) and that the sanitisation is to be agreed upon by uCDN = and dCDN. >=20 > Which assumes the uCDN & dCDN are in a position to know which fields = contains sensitive information and which do not, which in the general = case neither the uCDN or dCDN are in a position to know.=20 >=20 >>> (2) I think the use of partial-time in 3.4.1 means that the = timestamps >>> have no time zone information. It's not clear to me how the uCDN = uses >>> these timestamps in an absolute sense anyway, but I'm wondering if = that >>> could create problems if the uCDN does not know what time zone the = dCDN >>> is in. The time information in that case is somewhat meaningless if = the >>> uCDN needs to know the actual time at which something occurred. >>=20 >> I think this is a problem. We could either move to full-time, or = stick with partial-time but specify that time is always expressed in = GMT. I will poll the list on that. >=20 > My vote is for partial-time expressed in UTC. >=20 > Ben >=20 From nobody Thu Mar 31 10:11:41 2016 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 07A6512D550; Thu, 31 Mar 2016 10:10:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 WxPCJUwnCiXh; Thu, 31 Mar 2016 10:10:11 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (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 DAB6D12D52E; Thu, 31 Mar 2016 10:10:10 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id 127so141532893wmu.1; Thu, 31 Mar 2016 10:10:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-transfer-encoding :message-id:cc:from:subject:date:to; bh=QTf+40PIDazR28wspxtV+Wl6CyFCRpj2eXxDv6MtHOo=; b=PJTsZXA+QQm+B49XtAS1boivcdu0IgWygDZSxbp5gZoH2OqJyCJWOZzjgDEkiuuTyT Sy4qgR4piFVcANb3X1IdZArLmoOJT7b0umnReZKQjV1geXCINKPeKpsKnMddBXz5kaUC 7F6WaSXLtQS+h48k3pcviOJaybABacrmtwflldbcln9JsYT+EX0+vpFDJWyLftqSkFAf 0CWXxAcJRW8SUOvo87j7VhbJiEIUgCTjUmV4uGVRnIxQ10fVU4vxoGnmPANNAgUR2M3m Ip9wn5ZI4W+aohCk7O7TDQXAH9Fsuw7f/dFG3XE1PwxtTGzsPfyF8a6FuH5mVbToPpHq cKWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=QTf+40PIDazR28wspxtV+Wl6CyFCRpj2eXxDv6MtHOo=; b=k35C45I2OSZ1E/t7U01P2dA+wcFvqWnymGcQLsQ2Pyu1jKjecJG3t962bGdtjat6UH bndHYhoI3w06unsxtcSiKLz0NOo6J+DeLlhArB0o2YQgH4c+7863dHK8buLSm+2q1yfG Fa1Qdzkt9/4/owKapGOJfX5bkcKvpWmnFlMDY2wjQ+NDCv+ba9Ddy+B4yqyL0E72aTvk 6wpMA01NNxfDk4Fb+njcZ4J36n2Hg7BetLWob703l+H/IDaGWdmapEi7cGuyPCjlGGXR yHkc+27w5PbEsKS+HvRoEunYpcGtjfrV9fsmwx9JMz2ddbAr5QmkuwdBT1dlnu47ngWR wy6g== X-Gm-Message-State: AD7BkJKgsnVncnzcQwxyT7kS7jWgwgmCpHPl7+qy0fxcSuZQf918p/+u64hivfBiwXLUZw== X-Received: by 10.194.190.6 with SMTP id gm6mr5507658wjc.115.1459444209293; Thu, 31 Mar 2016 10:10:09 -0700 (PDT) Received: from [192.168.0.2] (97e1f3b1.skybroadband.com. [151.225.243.177]) by smtp.gmail.com with ESMTPSA id m13sm10453230wma.3.2016.03.31.10.10.08 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 31 Mar 2016 10:10:08 -0700 (PDT) References: <20160325182719.17995.1066.idtracker@ietfa.amsl.com> <6EC0B4CB-7F83-410F-9A0F-CCEF8F8436B4@gmail.com> <2DC5E6F0-F919-4DAB-BB43-3029C8A2B88A@niven-jenkins.co.uk> <81D842F0-D3BF-40D7-801D-9B0532C51A84@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: <81D842F0-D3BF-40D7-801D-9B0532C51A84@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPad Mail (13E237) From: iuniana.oprescu@gmail.com Date: Thu, 31 Mar 2016 18:10:07 +0100 To: Francois Le Faucheur Archived-At: X-Mailman-Approved-At: Thu, 31 Mar 2016 10:11:40 -0700 Cc: "" , cdni-chairs@ietf.org, The IESG , draft-ietf-cdni-logging@ietf.org Subject: Re: [CDNi] Alissa Cooper's Discuss on draft-ietf-cdni-logging-23: (with DISCUSS and COMMENT) X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 31 Mar 2016 17:10:14 -0000 Hello all, (as document editor as well) I think the change regrading the time stamps being UTC is a valid point and o= nce it's cleared that should allow us to move this document forward.=20 Regarding the other comments, I think they are valuable and would certainly m= ake the specification very privacy-friendly. Unfortunately we don't really h= ave the time and I have personally lost motivation to make it perfect. The c= onversation about the cookie header being logged was an indication of how th= ings could become privacy unfriendly and we established that CDNI cannot go a= nd do a thorough analysis of all possible combinations of headers and what i= nformation can be inferred from them. I think a thorough analysis of what is= a perfectly private profile for logging would take a very long time. I thin= k the statements currently included in the draft are good enough and if we'r= e happy with "good enough" and done now rather than "perfect" and done in an= other year or so, then we can stick with the current text. Alissa, how strongly do you feel about your previous comments? Are they abso= lutely essential and are they a show stopper? Thanks every for the effort put into this, --iuniana Pe 31 mars 2016, la 17:18, Francois Le Faucheur a scris= : > Alissa, >=20 > (as document editor) >=20 > In an attempt to work towards closure, please see below: >=20 >> On 31 Mar 2016, at 02:20, Ben Niven-Jenkins wro= te: >>=20 >> All, >>=20 >> I=E2=80=99m not an author on this document but for what it=E2=80=99s wort= h my 2p opinion is inline below. >>=20 >>>> On 30 Mar 2016, at 21:51, Francois Le Faucheur wro= te: >>>> ---------------------------------------------------------------------- >>>> DISCUSS: >>>> ---------------------------------------------------------------------- >>>> (1) >>>> I am wondering about a potential inconsistency that I see in Section >>>> 3.4.1. I see with the definition of the c-groupid field that there is >>>> inherent support for reporting about clients as aggregates, which is >>>> great, and even when reporting is done about individual clients there a= re >>>> a bunch of normative recommendations to try to reduce the chances that a= >>>> logging field will be tied back to an individual user or host. Excellen= t. >>>> But then with the definition of the cs(insert_HTTP_header_name_here) >>>> field and discussion about it, there is no equivalent normative guidanc= e >>>> given about not including headers that could potentially be used to >>>> identify an individual user or host. There is discussion about cookies >>>> but none of it is normative, and cookies are not the only headers that >>>> could be identifying. In fact, one of the examples given -- User-Agent -= - >>>> is known to be identifying in some cases. >>>>=20 >>>> Given the extent to which the specification of c-groupid goes to suppor= t >>>> masking the identity of the host, I would expect normative guidance abo= ut >>>> the use of the header field. That is, if an implementation is using >>>> c-groupid to represent an aggregate, it would make sense to me that it >>>> MUST NOT include header fields that could be uniquely identifying. I al= so >>>> wonder if the recommendations about cookies in 3.4.1 could be made >>>> normative. I will say that based on the use cases for these logs listed= >>>> in 2.2.5 it's hard to understand what a uCDN needs headers like cookies= >>>> for on a consistent basis; if they're needed for an occasional >>>> troubleshoot, logging them consistently seems like overkill. >>>=20 >>> This makes sense, and Stephen Farrell expressed the same concern. He sug= gested to add the following text, which was incorporated in section 3.4.1 ri= ght after the definition of all fields: >>>=20 >>> "Logging some specific fields from HTTP requests and responses can >>> introduce serious security and privacy risks. For example, cookies >>> will often contain (months) long lived token values that can be used >>> to log into a service as the relevant user. Similar values may be >>> included in other header fields or within URLs or elsewhere in HTTP >>> requests and responses. Centralising such values in a CDNI Logging >>> File can therefore represent a significant increase in risk both for >>> the user and the web service provider, but also for the CDNs >>> involved. Implementations ought therefore to attempt to lower the >>> probability of such bad outcomes e.g. by only allowing a configured >>> set of headers to be added to CDNI Logging Records, or by not >>> supporting wildcard selection of HTTP request/response fields to add. >>> Such mechanisms can reduce the probability that security (or privacy) >>> sensitive values are centralised in CDNI Logging Files. Also, when >>> agreeing on which HTTP request/response fields are to be provided in >>> CDNI Logging Files, the uCDN and dCDN administrators ought to >>> consider these risks. >>> =E2=80=9C >>> Does that work for you? >>> Or do you feel there ought to be some normative language (suggestions we= lcome)? >>=20 >> IMO no, there should not be any normative language. Including normative l= anguage presupposes that the set of header fields that expose user identifia= ble material is well known and well defined and that is not the case. Loggin= g these fields exposes no more to the content provider than they would obtai= n had they not used a CDN. CDNs (uCDNs & dCDNs in the case of CDNI) are gate= ways/=E2=80=9Cdelegated origins=E2=80=9D operating on behalf of the content p= rovider. Who are we to tell a content provider what they can & cannot log? >>=20 >> A user agent under the control of the content provider (e.g. mobile appli= cation) can send header fields containing anything the content provider desi= res and there is no way to account for all those scenarios in the document. I= t doesn=E2=80=99t even have to be header fields. I am aware of deployments w= here the user=E2=80=99s username & zip code are included as query parameters= in the URL. That=E2=80=99s horrible for user privacy but there=E2=80=99s no= way to construct normative language that will account for that case and no w= ay to construct normative language that accounts for user identifying header= fields either because from the perspective of the dCDN, the values of the U= RL or special headers are opaque to the dCDN. >>=20 >> Having some discussion of the risks (as the above text outlines) is fine &= probably a good thing IMO, trying to construct normative text serves no pur= pose IMO except giving folks a warm fuzzy feeling that they=E2=80=99ve prote= cted user privacy without doing actually doing so. I thought our role here w= as to produce interoperable standards, not to be the Internet privacy police= . >>=20 >> I also wonder whether including normative text for this would actually ac= hieve the opposite of the desired effect - i.e. having normative text may ca= use some implementers to assume that all privacy-related scenarios have been= covered and lead folks to follow the normative text and not consider the pr= ivacy implications of header fields/etc not explicitly called out by the doc= ument? >=20 > I think Ben makes a valid argument that a CDN may not be in a position to c= omply to any normative behaviour. > So can we stick to the text above recommended by Stephen to discuss the is= sue, raise concern and make suggestions and leave it at that? >=20 >>=20 >>=20 >>>> (2) >>>> Section 7.1 says: >>>>=20 >>>> "In an environment where any such protection is required, mutually >>>> authenticated encrypted transport MUST be used to ensure >>>> confidentiality of the logging information. To that end, TLS MUST be >>>> used (including authentication of the remote end) by the server-side >>>> and the client-side of the CDNI Logging feed, as well as the server- >>>> side and the client-side of the CDNI Logging File pull mechanism." >>>>=20 >>>> I know this text has been the subject of much discussion and careful >>>> editing, and that I raised an issue on this on the redirection draft. >>>> What I don't understand from reading this is whether the expectation is= >>>> that all servers and clients implementing this specification will use >>>> TLS. The first sentence seems to indicate that there will be cases when= >>>> that is not true. The second sentence says MUST use, which means use in= >>>> every case. Which is it? >>>=20 >>> The answer to your question is meant to be conveyed by =E2=80=9CTo that e= nd=E2=80=9D. >>> In other words: When protection is needed, authenticated encrypted trans= port MUST be used. And when this is done, it MUST be achieved using TLS. >>>=20 >>> Can you leave with "to that end=E2=80=9D ? >>>=20 >>> If not, how about: >>> "In an environment where any such protection is required, mutually >>> authenticated encrypted transport MUST be used to ensure >>> confidentiality of the logging information, and to do so TLS MUST be >>> used (including authentication of the remote end) by the server-side >>> and the client-side of the CDNI Logging feed, as well as the server- >>> side and the client-side of the CDNI Logging File pull mechanism." >>> ? >>=20 >> Personally I find the relentless wordsmithing of this text to be incredib= ly tiresome. Way back at the beginning we had text that essentially said =E2= =80=9Cyou need to authenticate & encrypt the transport and in the absence of= anything else use TLS=E2=80=9D and we=E2=80=99ve slowly creeped towards =E2= =80=9CMUST use TLS and nothing else=E2=80=9D. I must have missed the memo th= at said that TLS is the panacea for authenticated & encrypted transport and t= hat VPNs and other approaches have been deprecated in favour of TLS. >>=20 >> I=E2=80=99ve said in other threads that for the CDNI documents I edit, I=E2= =80=99ll include whatever text is agreed for this logging document and I wil= l do that, but I strongly believe that folks will implement what their custo= mers=E2=80=99 want and that folks will deploy what makes sense for them irre= spective of what we write in our documents. Further wordsmithing of the text= is pure theatre IMO and adds no additional value or clarity to the document= IMO. >>=20 >> IMO this is a good example of the IESG demanding edits that go beyond wha= t is required to meet the bar for Proposed Standard. I see nothing in the or= iginal text (or any of the previous versions of the same section) that contr= adicts the requirements for Proposed Standard described in section 3.1 of RFC= 7127 or that will materially improve interoperability. Changing the text doe= s nothing except waste more time in tiresome debate IMO. We should just acce= pt the text as-is and move on to more important things IMO. >=20 > I agree with Ben we need to move on on that topic. But I think the change I= propose above is purely editorial and for clarification, so doing that last= change should not destabilise anything. So, Alissa, please tell us whether t= he current text is acceptable, or if you prefer the proposed change text. >=20 >=20 >>=20 >>>> ---------------------------------------------------------------------- >>>> COMMENT: >>>> ---------------------------------------------------------------------- >>>>=20 >>>> (1) Per my first DISCUSS point above, I wonder if it makes sense to >>>> specify a field where the dCDN could report a sanitized version of the >>>> client User-Agent string. This would allow a uCDN to calculate the >>>> "terminal type" KPI listed in 2.2.5.5.2 without requiring full, >>>> potentially identifying User-Agent strings to be logged. >>>=20 >>> I see the idea. >>> But I think there are several fields which may contain user identifying i= nformation. >>> So how about we add a statement following the text provided by Stephen t= o the effect that when fields (e.g. User Agent) contain user-identifying inf= ormation they SHOULD be sanitised to remove the sensitive information while k= eeping non-sensitive information (e.g. terminal type) and that the sanitisat= ion is to be agreed upon by uCDN and dCDN. >>=20 >> Which assumes the uCDN & dCDN are in a position to know which fields cont= ains sensitive information and which do not, which in the general case neith= er the uCDN or dCDN are in a position to know. >=20 > This is back to the earlier point. Given, as Ben points out, that the CDN m= ay not be in a position to comply to any normative language and given there i= s text recommended by Stephen to discuss the issue, raise concern and make s= uggestions, can we leave it at that? >=20 >>=20 >>>> (2) I think the use of partial-time in 3.4.1 means that the timestamps >>>> have no time zone information. It's not clear to me how the uCDN uses >>>> these timestamps in an absolute sense anyway, but I'm wondering if that= >>>> could create problems if the uCDN does not know what time zone the dCDN= >>>> is in. The time information in that case is somewhat meaningless if the= >>>> uCDN needs to know the actual time at which something occurred. >>>=20 >>> I think this is a problem. We could either move to full-time, or stick w= ith partial-time but specify that time is always expressed in GMT. I will po= ll the list on that. >>=20 >> My vote is for partial-time expressed in UTC. >=20 > As agreed on the list, the next rev will specify the =E2=80=9Ctime=E2=80=9D= field value is expressed in UTC, which solves the concern. >=20 > Francois >=20 >>=20 >> Ben >=20 From nobody Thu Mar 31 10:20:27 2016 Return-Path: X-Original-To: cdni@ietf.org Delivered-To: cdni@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CDD2712D6B2; Thu, 31 Mar 2016 10:20:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.18.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160331172021.28635.55112.idtracker@ietfa.amsl.com> Date: Thu, 31 Mar 2016 10:20:21 -0700 Archived-At: Cc: draft-ietf-cdni-logging@ietf.org, cdni@ietf.org, cdni-chairs@ietf.org Subject: [CDNi] Alissa Cooper's Abstain on draft-ietf-cdni-logging-23: (with COMMENT) X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 31 Mar 2016 17:20:22 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-cdni-logging-23: Abstain When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cdni-logging/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I think we could resolve my DISCUSS points to the satisfaction of all parties given more time, but I think the issues have narrowed through the list discussion and time is running out to get this approved, so moving to abstain to not delay it further. From nobody Thu Mar 31 10:20:29 2016 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 D468512D6B5; Thu, 31 Mar 2016 10:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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 fiFKUZoia26a; Thu, 31 Mar 2016 10:20:21 -0700 (PDT) Received: from mail-wm0-x241.google.com (mail-wm0-x241.google.com [IPv6:2a00:1450:400c:c09::241]) (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 2304012D6A2; Thu, 31 Mar 2016 10:20:21 -0700 (PDT) Received: by mail-wm0-x241.google.com with SMTP id p65so25499742wmp.1; Thu, 31 Mar 2016 10:20:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=C7r3UHVqUXYKY0DwZLS//PJCywFxFzUs3O1AAz+8zZY=; b=Ye1XQcvfnsxUBv/za4rg171WVddKdMMdcrGO1hKMYaaOFcmQ9GCT5/aA8IJ/rkGf+H 15HB6l8Gfmaa8BAS1THDh9e9lnAandQeGqQ1APFUoHpHGd0yUNGZx3dXsyAQnPPW397Y BsY8TU03fVusOYmMSqZQz2loPuTzvQImNf8idn6p9LVcaV56Td++m9ERcUTm0GmdddS0 Uc7E3t76M6nXQLNO09sigiuPSjUX1LB2YN+9Y/itpwIa7S5xoL8XdBsVfRW3T3oQpl6G BM56jpSuHO+ffoGwMBo37jN50hmIzHXhyb/6FiWLh5ywPYCaz8vUHHzoe0OGbpY7J0fi Hq5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=C7r3UHVqUXYKY0DwZLS//PJCywFxFzUs3O1AAz+8zZY=; b=cJPKYhfh+//ouXsqN0ERL3ly/3dkCT/rfmCZ3ZGV+sPll7UR6pyHWewMFDV3y5sSIr YCNt/Vcu0HA6n347b6HjI6qj9bZUof1laPCJM/S/SDxS/R8/ikn4216WsLZNWAGSmsxd rTwI9DbFylOM2gtAVBGbYruJCqrSairlZDriISsJnD15IdVApfzGTrIP7KILxeEqGTLl Oha5JbFP1qL8SSY57CBEAhhIl7wJKtdXy4O3s1Ya0J+6NvsfrAaSYC66RBFw3yH96JFN dZtgnudIuGsnUXX89Xhha1799l/vFOh+kLYsnpnT2C+S08tRqs1OzDUy9Iw74XJYHNNv e+eQ== X-Gm-Message-State: AD7BkJIyjuNl9RFbF6H/oxe8bYKAwp94lbWuWDQbhXeuNMGAs0MBYebuG2u+2fefPT4nLg== X-Received: by 10.194.184.139 with SMTP id eu11mr13585456wjc.154.1459444819567; Thu, 31 Mar 2016 10:20:19 -0700 (PDT) Received: from ams-flefauch-nitro3.cisco.com ([173.38.220.42]) by smtp.gmail.com with ESMTPSA id hh8sm9941168wjc.42.2016.03.31.10.20.17 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 31 Mar 2016 10:20:18 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Francois Le Faucheur In-Reply-To: Date: Thu, 31 Mar 2016 19:20:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2689AB3A-5404-4067-844A-5058A845B408@gmail.com> References: <20160325182719.17995.1066.idtracker@ietfa.amsl.com> <6EC0B4CB-7F83-410F-9A0F-CCEF8F8436B4@gmail.com> <2DC5E6F0-F919-4DAB-BB43-3029C8A2B88A@niven-jenkins.co.uk> <81D842F0-D3BF-40D7-801D-9B0532C51A84@gmail.com> To: Alissa Cooper X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "" , cdni-chairs@ietf.org, Le Faucheur Francois , IESG , draft-ietf-cdni-logging@ietf.org Subject: Re: [CDNi] Alissa Cooper's Discuss on draft-ietf-cdni-logging-23: (with DISCUSS and COMMENT) X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 31 Mar 2016 17:20:23 -0000 >>>>=20 >>>> If not, how about: >>>> "In an environment where any such protection is required, mutually >>>> authenticated encrypted transport MUST be used to ensure >>>> confidentiality of the logging information, and to do so TLS MUST = be >>>> used (including authentication of the remote end) by the = server-side >>>> and the client-side of the CDNI Logging feed, as well as the = server- >>>> side and the client-side of the CDNI Logging File pull = mechanism.=E2=80=9D >>>> ? >=20 > This is better, thanks. >=20 > Alissa Change incorporated in the next rev. Thanks Francois= From nobody Thu Mar 31 10:26:48 2016 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 1B33312D172; Thu, 31 Mar 2016 10:26:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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 8wzrhOPrronT; Thu, 31 Mar 2016 10:26:39 -0700 (PDT) Received: from mail-wm0-x242.google.com (mail-wm0-x242.google.com [IPv6:2a00:1450:400c:c09::242]) (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 29BFA12D6CA; Thu, 31 Mar 2016 10:26:39 -0700 (PDT) Received: by mail-wm0-x242.google.com with SMTP id 20so25550716wmh.3; Thu, 31 Mar 2016 10:26:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=v02dIIfCcLPkY9qewl3jeVBoJJrq0p6aXQhNsAaCguI=; b=eZSl3IKAuCuOusXtuTejHr2cdYyw4EOglJ1Ty/eteEfXHZhg92GQwsVl+5uCJbd3vk conEfUtql1aqZqIa7UCl/VZIrMMdwFk1eXwO0eI0rXBeDzQr5ldELzLX81XBqVO3g7ys ai4Z173Inv0pZIY464Ra1oI7HNR0kwWPeKzlSPdtqsO3RUGazJt3lGUmMZW/mfA097+7 wxZ0c6dk6YNa5rZodUGKbPP4gZTaM59uI7TYnQJ4+RaDDAgl9f9f1SUz8D3PDKqoovXI Q6fCq019QAb/dvSs2nn6pxncEqlEZQnb+58bTZpWYAoqUcOr7mW6+2eYiZWg4VZmvtBk CTAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=v02dIIfCcLPkY9qewl3jeVBoJJrq0p6aXQhNsAaCguI=; b=R503xgSC3qvloa+yhQH4DRN7Pt/2dhLjtA1IkocHPg790sbelSWMRPHoj6xpftleqa Epdu3xbTjmkMDI7Viq+gdJ4+hKb/3FmM+mXS3C73btlPSnfHj+z9mopZnO+/IBWbAK8X QF8pj0zvKIto5x+/NNXpQb/VxKFmi6IUaf/NyZyoRiYow8gJji7+BxWDlZuedyMVO4Ii tLbwZX0Al0M3NJ/nIJDDQgWJwQUBcm2aY3YJgpYT0otHO2GNpd6/BtnzjeWTpTAT5Gyh HjH+xzeiS3iR5LPnmbsKZ3skM+YQ+nHEa8UfZatsDuF1TCEjvnPpGrGTXMVtqagf5R8A Q0dA== X-Gm-Message-State: AD7BkJJl5H0J1PS/Cvm4WkG/dMFe0prh/tYYlllx2lcnrtLqCGCAkQ15Ii5HEAyW/Xj8Uw== X-Received: by 10.28.188.7 with SMTP id m7mr10453541wmf.83.1459445197526; Thu, 31 Mar 2016 10:26:37 -0700 (PDT) Received: from ams-flefauch-nitro3.cisco.com ([173.38.220.42]) by smtp.gmail.com with ESMTPSA id cb2sm10027573wjc.16.2016.03.31.10.26.35 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 31 Mar 2016 10:26:36 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Francois Le Faucheur In-Reply-To: <5D3D0ADA-18AD-481F-B085-424B81A4CF90@cooperw.in> Date: Thu, 31 Mar 2016 19:26:32 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3755C76F-28F9-4644-9AC0-090E1B06A2D1@gmail.com> References: <20160325182719.17995.1066.idtracker@ietfa.amsl.com> <6EC0B4CB-7F83-410F-9A0F-CCEF8F8436B4@gmail.com> <2DC5E6F0-F919-4DAB-BB43-3029C8A2B88A@niven-jenkins.co.uk> <5D3D0ADA-18AD-481F-B085-424B81A4CF90@cooperw.in> To: Alissa Cooper X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "" , cdni-chairs@ietf.org, Le Faucheur Francois , IESG , draft-ietf-cdni-logging@ietf.org Subject: Re: [CDNi] Alissa Cooper's Discuss on draft-ietf-cdni-logging-23: (with DISCUSS and COMMENT) X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 31 Mar 2016 17:26:42 -0000 Hi Alissa, Thanks for updating your Discuss to Abstain. It may be a moot point now, but just for the record: >>=20 >>=20 >=20 > Maybe I wasn=E2=80=99t clear in articulating my point. The spec = clearly supports the ability for the dCDN to decide to send logs about = an aggregate of clients. That isn=E2=80=99t =E2=80=9Ctelling a content = provider=E2=80=9D what to log or not, but it is providing support for a = dCDN to not report a piece of data that would have been delivered to the = content provider if there were no CDN. If that is the point of = specifying c-groupid the way that it is specified =E2=80=94 including = normative recommendations clearly designed to ensure that the c-groupid = does indeed identify an aggregate and not a single client =E2=80=94 then = it seems to me to undermine the whole point of providing an identifier = for an aggregate if the dCDN then includes a bunch of header fields that = identify an individual client. The spec shouldn=E2=80=99t pretend to = support provision for some protections that it actually doesn=E2=80=99t = provide given the way it=E2=80=99s expected to be implemented. I think = at a minimum the draft needs to point this out in the paragraph Francois = quoted. Personally I don=E2=80=99t think making the recommendations in = the text about cookies normative gives anyone a fuzzier feeling than the = text does as-is, but I=E2=80=99m not going to say that it=E2=80=99s not = worth holding up the document over.=20 Double negations sometimes get me, but I think you meant: "but I=E2=80=99m not going to say that it=E2=80=99s worth holding up the = document over =E2=80=9C, right? >>=20 >=20 > I did not demand any edits. I asked a question because the text = isn=E2=80=99t clear. I don=E2=80=99t care if the standard is MUST use = TLS (which means all the time) or SHOULD use TLS (which means = sometimes). =E2=80=9CMUST use TLS sometimes=E2=80=9D is not a legitimate = choice. This is relevant for the IESG to comment on because MUST means = something specific everywhere we use it, not just in this document, and = I=E2=80=99d rather not establish a precedent that MUST means =E2=80=9Cuse = it sometimes.=E2=80=9D As discussed, the text was not intended to say =E2=80=9Cuse it = sometimes=E2=80=9D but rather =E2=80=9Cunder such circumstances, it MUST = be used=E2=80=9D which I believe is a perfectly IESG-friendly way to use = =E2=80=9CMUST=E2=80=9D 8^). I think the updated text reflects that more = clearly now. Thanks again for working fast with us to resolution. Francois >=20 > Alissa >=20 >>=20 >>>> = ---------------------------------------------------------------------- >>>> COMMENT: >>>> = ---------------------------------------------------------------------- >>>>=20 >>>> (1) Per my first DISCUSS point above, I wonder if it makes sense to >>>> specify a field where the dCDN could report a sanitized version of = the >>>> client User-Agent string. This would allow a uCDN to calculate the >>>> "terminal type" KPI listed in 2.2.5.5.2 without requiring full, >>>> potentially identifying User-Agent strings to be logged. >>>=20 >>> I see the idea. >>> But I think there are several fields which may contain user = identifying information. >>> So how about we add a statement following the text provided by = Stephen to the effect that when fields (e.g. User Agent) contain = user-identifying information they SHOULD be sanitised to remove the = sensitive information while keeping non-sensitive information (e.g. = terminal type) and that the sanitisation is to be agreed upon by uCDN = and dCDN. >>=20 >> Which assumes the uCDN & dCDN are in a position to know which fields = contains sensitive information and which do not, which in the general = case neither the uCDN or dCDN are in a position to know.=20 >>=20 >>>> (2) I think the use of partial-time in 3.4.1 means that the = timestamps >>>> have no time zone information. It's not clear to me how the uCDN = uses >>>> these timestamps in an absolute sense anyway, but I'm wondering if = that >>>> could create problems if the uCDN does not know what time zone the = dCDN >>>> is in. The time information in that case is somewhat meaningless if = the >>>> uCDN needs to know the actual time at which something occurred. >>>=20 >>> I think this is a problem. We could either move to full-time, or = stick with partial-time but specify that time is always expressed in = GMT. I will poll the list on that. >>=20 >> My vote is for partial-time expressed in UTC. >>=20 >> Ben >>=20 >=20 From nobody Thu Mar 31 10:30:07 2016 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 F306E12D6DD for ; Thu, 31 Mar 2016 10:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=BCXApIdV; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=aombJvuz 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 nH9vsUjYB4my for ; Thu, 31 Mar 2016 10:30:04 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BD5D12D6DC for ; Thu, 31 Mar 2016 10:30:04 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id D06A022D06 for ; Thu, 31 Mar 2016 13:17:15 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Thu, 31 Mar 2016 13:17:15 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=SVf/AN5HvL4SV1tnRM1tMsAeHgM=; b=BCXApI dVjPOTrv4qUl8EoufJQDQ7Onf5Q/SgnIkLia8HyBL3S+iBI6q0GRhdlxU05Qp3ba AaQk6LaJRkIb0TR+m6kAvSub4HqVuGaA6Qfldzldl8yJ91MO5AG7ol1q1soGv+Zw MEqUuEcd6LW4bHhtgzSC6draAonpg8xUQ8IAc= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=SVf/AN5HvL4SV1t nRM1tMsAeHgM=; b=aombJvuztaj0YadtkdP/2EI++dTBUJr3CihxkPWV9hI4g5Y xbWqLKkm5wD/ak0etLGjWnJ7nelKdQEg8u3xmitCOnj/RHdz48IJxbJlO4LflBF+ 9wDZk3WBByTuDi3tvuNb0USTOYC47jPWB0GDLPbIig+FKqfAa2sVSSJqaGNY= X-Sasl-enc: TK1EduQ4/sgw5FIqMVD2JOGUfDyavo1LkEGuqxhk49cj 1459444635 Received: from dhcp-171-68-20-39.cisco.com (dhcp-171-68-20-39.cisco.com [171.68.20.39]) by mail.messagingengine.com (Postfix) with ESMTPA id E477BC00020; Thu, 31 Mar 2016 13:17:14 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alissa Cooper In-Reply-To: <81D842F0-D3BF-40D7-801D-9B0532C51A84@gmail.com> Date: Thu, 31 Mar 2016 10:17:59 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160325182719.17995.1066.idtracker@ietfa.amsl.com> <6EC0B4CB-7F83-410F-9A0F-CCEF8F8436B4@gmail.com> <2DC5E6F0-F919-4DAB-BB43-3029C8A2B88A@niven-jenkins.co.uk> <81D842F0-D3BF-40D7-801D-9B0532C51A84@gmail.com> To: Francois Le Faucheur X-Mailer: Apple Mail (2.3112) Archived-At: Cc: draft-ietf-cdni-logging@ietf.org, IESG , "" , cdni-chairs@ietf.org Subject: Re: [CDNi] Alissa Cooper's Discuss on draft-ietf-cdni-logging-23: (with DISCUSS and COMMENT) X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 31 Mar 2016 17:30:06 -0000 Hi Francois, > On Mar 31, 2016, at 9:18 AM, Francois Le Faucheur = wrote: >=20 >=20 >>=20 >>=20 >>>> (2) >>>> Section 7.1 says: >>>>=20 >>>> "In an environment where any such protection is required, mutually >>>> authenticated encrypted transport MUST be used to ensure >>>> confidentiality of the logging information. To that end, TLS MUST = be >>>> used (including authentication of the remote end) by the = server-side >>>> and the client-side of the CDNI Logging feed, as well as the = server- >>>> side and the client-side of the CDNI Logging File pull mechanism." >>>>=20 >>>> I know this text has been the subject of much discussion and = careful >>>> editing, and that I raised an issue on this on the redirection = draft. >>>> What I don't understand from reading this is whether the = expectation is >>>> that all servers and clients implementing this specification will = use >>>> TLS. The first sentence seems to indicate that there will be cases = when >>>> that is not true. The second sentence says MUST use, which means = use in >>>> every case. Which is it? >>>=20 >>> The answer to your question is meant to be conveyed by =E2=80=9CTo = that end=E2=80=9D. >>> In other words: When protection is needed, authenticated encrypted = transport MUST be used. And when this is done, it MUST be achieved using = TLS. >>>=20 >>> Can you leave with "to that end=E2=80=9D ? >>>=20 >>> If not, how about: >>> "In an environment where any such protection is required, mutually >>> authenticated encrypted transport MUST be used to ensure >>> confidentiality of the logging information, and to do so TLS MUST be >>> used (including authentication of the remote end) by the server-side >>> and the client-side of the CDNI Logging feed, as well as the server- >>> side and the client-side of the CDNI Logging File pull mechanism.=E2=80= =9D >>> ? This is better, thanks. Alissa >>=20 >> Personally I find the relentless wordsmithing of this text to be = incredibly tiresome. Way back at the beginning we had text that = essentially said =E2=80=9Cyou need to authenticate & encrypt the = transport and in the absence of anything else use TLS=E2=80=9D and = we=E2=80=99ve slowly creeped towards =E2=80=9CMUST use TLS and nothing = else=E2=80=9D. I must have missed the memo that said that TLS is the = panacea for authenticated & encrypted transport and that VPNs and other = approaches have been deprecated in favour of TLS. >>=20 >> I=E2=80=99ve said in other threads that for the CDNI documents I = edit, I=E2=80=99ll include whatever text is agreed for this logging = document and I will do that, but I strongly believe that folks will = implement what their customers=E2=80=99 want and that folks will deploy = what makes sense for them irrespective of what we write in our = documents. Further wordsmithing of the text is pure theatre IMO and adds = no additional value or clarity to the document IMO. >>=20 >> IMO this is a good example of the IESG demanding edits that go beyond = what is required to meet the bar for Proposed Standard. I see nothing in = the original text (or any of the previous versions of the same section) = that contradicts the requirements for Proposed Standard described in = section 3.1 of RFC7127 or that will materially improve interoperability. = Changing the text does nothing except waste more time in tiresome debate = IMO. We should just accept the text as-is and move on to more important = things IMO. >=20 > I agree with Ben we need to move on on that topic. But I think the = change I propose above is purely editorial and for clarification, so = doing that last change should not destabilise anything. So, Alissa, = please tell us whether the current text is acceptable, or if you prefer = the proposed change text. >=20 >=20 >>=20 >>>> = ---------------------------------------------------------------------- >>>> COMMENT: >>>> = ---------------------------------------------------------------------- >>>>=20 >>>> (1) Per my first DISCUSS point above, I wonder if it makes sense to >>>> specify a field where the dCDN could report a sanitized version of = the >>>> client User-Agent string. This would allow a uCDN to calculate the >>>> "terminal type" KPI listed in 2.2.5.5.2 without requiring full, >>>> potentially identifying User-Agent strings to be logged. >>>=20 >>> I see the idea. >>> But I think there are several fields which may contain user = identifying information. >>> So how about we add a statement following the text provided by = Stephen to the effect that when fields (e.g. User Agent) contain = user-identifying information they SHOULD be sanitised to remove the = sensitive information while keeping non-sensitive information (e.g. = terminal type) and that the sanitisation is to be agreed upon by uCDN = and dCDN. >>=20 >> Which assumes the uCDN & dCDN are in a position to know which fields = contains sensitive information and which do not, which in the general = case neither the uCDN or dCDN are in a position to know.=20 >=20 > This is back to the earlier point. Given, as Ben points out, that the = CDN may not be in a position to comply to any normative language and = given there is text recommended by Stephen to discuss the issue, raise = concern and make suggestions, can we leave it at that? >=20 >>=20 >>>> (2) I think the use of partial-time in 3.4.1 means that the = timestamps >>>> have no time zone information. It's not clear to me how the uCDN = uses >>>> these timestamps in an absolute sense anyway, but I'm wondering if = that >>>> could create problems if the uCDN does not know what time zone the = dCDN >>>> is in. The time information in that case is somewhat meaningless if = the >>>> uCDN needs to know the actual time at which something occurred. >>>=20 >>> I think this is a problem. We could either move to full-time, or = stick with partial-time but specify that time is always expressed in = GMT. I will poll the list on that. >>=20 >> My vote is for partial-time expressed in UTC. >=20 > As agreed on the list, the next rev will specify the =E2=80=9Ctime=E2=80= =9D field value is expressed in UTC, which solves the concern. >=20 > Francois >=20 >>=20 >> Ben >>=20 >=20 From nobody Thu Mar 31 10:42:13 2016 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 EAE6F12D6EC for ; Thu, 31 Mar 2016 10:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=ZqpdApCT; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=r7QrQC03 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 6LfZjhAIQ4fp for ; Thu, 31 Mar 2016 10:42:10 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F2B012D6A7 for ; Thu, 31 Mar 2016 10:42:10 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id E93C922B7E for ; Thu, 31 Mar 2016 13:21:22 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Thu, 31 Mar 2016 13:21:22 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=0LwLsQ3iPYAC3bxjaxPx1HIw47U=; b=ZqpdAp CT4MnbxmPWKmy61ICBA/H+C0/DX/xSZa9qUgRv39N626Qvp7V4I6DQd9ZxJjO5S7 H0X1ot/JD8UBJ3jqxQeni8M5s9lGxwlg72Y4sJfuz9V4RqapxNV7h/G7WGpUovX2 KM9qKCSPYwilZ3Dkzeom6wCi46mX6I1CTBBdk= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=0LwLsQ3iPYAC3bx jaxPx1HIw47U=; b=r7QrQC0399NADx68sMtGVWo8usT7NzT5Dvk/kPH12cmoPPf jflLzzeUPrZYe5NrmxNXg+D32Jgf1Slg3Ur1MN5Ayrtw/pywwZTbe4wOnVaki0p4 Wkap3EJaP0NCcWuNg4xjwqrM7WCWViLCSLKV2WyxS7f8iSuIyLZ7CPndLNkw= X-Sasl-enc: x+GAwzaVpQDB5nH6olwNOpZy5nrpX5Rkfc+ksEXSFuqK 1459444882 Received: from dhcp-171-68-20-39.cisco.com (dhcp-171-68-20-39.cisco.com [171.68.20.39]) by mail.messagingengine.com (Postfix) with ESMTPA id CB271C00024; Thu, 31 Mar 2016 13:21:21 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alissa Cooper In-Reply-To: Date: Thu, 31 Mar 2016 10:22:05 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5AEC171E-54DC-4B5B-83BA-246BD753BCF0@cooperw.in> References: <20160325182719.17995.1066.idtracker@ietfa.amsl.com> <6EC0B4CB-7F83-410F-9A0F-CCEF8F8436B4@gmail.com> <2DC5E6F0-F919-4DAB-BB43-3029C8A2B88A@niven-jenkins.co.uk> <81D842F0-D3BF-40D7-801D-9B0532C51A84@gmail.com> To: iuniana.oprescu@gmail.com X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "" , cdni-chairs@ietf.org, Francois Le Faucheur , IESG , draft-ietf-cdni-logging@ietf.org Subject: Re: [CDNi] Alissa Cooper's Discuss on draft-ietf-cdni-logging-23: (with DISCUSS and COMMENT) X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 31 Mar 2016 17:42:12 -0000 Hi Iuniana, > On Mar 31, 2016, at 10:10 AM, iuniana.oprescu@gmail.com wrote: >=20 > Hello all, >=20 > (as document editor as well) >=20 > I think the change regrading the time stamps being UTC is a valid = point and once it's cleared that should allow us to move this document = forward.=20 >=20 > Regarding the other comments, I think they are valuable and would = certainly make the specification very privacy-friendly. Unfortunately we = don't really have the time and I have personally lost motivation to make = it perfect. The conversation about the cookie header being logged was an = indication of how things could become privacy unfriendly and we = established that CDNI cannot go and do a thorough analysis of all = possible combinations of headers and what information can be inferred = from them. I think a thorough analysis of what is a perfectly private = profile for logging would take a very long time. I think the statements = currently included in the draft are good enough and if we're happy with = "good enough" and done now rather than "perfect" and done in another = year or so, then we can stick with the current text. >=20 > Alissa, how strongly do you feel about your previous comments? Are = they absolutely essential and are they a show stopper? I moved to abstain. Alissa >=20 > Thanks every for the effort put into this, > --iuniana >=20 > Pe 31 mars 2016, la 17:18, Francois Le Faucheur a = scris: >=20 >> Alissa, >>=20 >> (as document editor) >>=20 >> In an attempt to work towards closure, please see below: >>=20 >>> On 31 Mar 2016, at 02:20, Ben Niven-Jenkins = wrote: >>>=20 >>> All, >>>=20 >>> I=E2=80=99m not an author on this document but for what it=E2=80=99s = worth my 2p opinion is inline below. >>>=20 >>>>> On 30 Mar 2016, at 21:51, Francois Le Faucheur = wrote: >>>>> = ---------------------------------------------------------------------- >>>>> DISCUSS: >>>>> = ---------------------------------------------------------------------- >>>>> (1) >>>>> I am wondering about a potential inconsistency that I see in = Section >>>>> 3.4.1. I see with the definition of the c-groupid field that there = is >>>>> inherent support for reporting about clients as aggregates, which = is >>>>> great, and even when reporting is done about individual clients = there are >>>>> a bunch of normative recommendations to try to reduce the chances = that a >>>>> logging field will be tied back to an individual user or host. = Excellent. >>>>> But then with the definition of the = cs(insert_HTTP_header_name_here) >>>>> field and discussion about it, there is no equivalent normative = guidance >>>>> given about not including headers that could potentially be used = to >>>>> identify an individual user or host. There is discussion about = cookies >>>>> but none of it is normative, and cookies are not the only headers = that >>>>> could be identifying. In fact, one of the examples given -- = User-Agent -- >>>>> is known to be identifying in some cases. >>>>>=20 >>>>> Given the extent to which the specification of c-groupid goes to = support >>>>> masking the identity of the host, I would expect normative = guidance about >>>>> the use of the header field. That is, if an implementation is = using >>>>> c-groupid to represent an aggregate, it would make sense to me = that it >>>>> MUST NOT include header fields that could be uniquely identifying. = I also >>>>> wonder if the recommendations about cookies in 3.4.1 could be made >>>>> normative. I will say that based on the use cases for these logs = listed >>>>> in 2.2.5 it's hard to understand what a uCDN needs headers like = cookies >>>>> for on a consistent basis; if they're needed for an occasional >>>>> troubleshoot, logging them consistently seems like overkill. >>>>=20 >>>> This makes sense, and Stephen Farrell expressed the same concern. = He suggested to add the following text, which was incorporated in = section 3.4.1 right after the definition of all fields: >>>>=20 >>>> "Logging some specific fields from HTTP requests and responses can >>>> introduce serious security and privacy risks. For example, cookies >>>> will often contain (months) long lived token values that can be = used >>>> to log into a service as the relevant user. Similar values may be >>>> included in other header fields or within URLs or elsewhere in HTTP >>>> requests and responses. Centralising such values in a CDNI Logging >>>> File can therefore represent a significant increase in risk both = for >>>> the user and the web service provider, but also for the CDNs >>>> involved. Implementations ought therefore to attempt to lower the >>>> probability of such bad outcomes e.g. by only allowing a configured >>>> set of headers to be added to CDNI Logging Records, or by not >>>> supporting wildcard selection of HTTP request/response fields to = add. >>>> Such mechanisms can reduce the probability that security (or = privacy) >>>> sensitive values are centralised in CDNI Logging Files. Also, when >>>> agreeing on which HTTP request/response fields are to be provided = in >>>> CDNI Logging Files, the uCDN and dCDN administrators ought to >>>> consider these risks. >>>> =E2=80=9C >>>> Does that work for you? >>>> Or do you feel there ought to be some normative language = (suggestions welcome)? >>>=20 >>> IMO no, there should not be any normative language. Including = normative language presupposes that the set of header fields that expose = user identifiable material is well known and well defined and that is = not the case. Logging these fields exposes no more to the content = provider than they would obtain had they not used a CDN. CDNs (uCDNs & = dCDNs in the case of CDNI) are gateways/=E2=80=9Cdelegated origins=E2=80=9D= operating on behalf of the content provider. Who are we to tell a = content provider what they can & cannot log? >>>=20 >>> A user agent under the control of the content provider (e.g. mobile = application) can send header fields containing anything the content = provider desires and there is no way to account for all those scenarios = in the document. It doesn=E2=80=99t even have to be header fields. I am = aware of deployments where the user=E2=80=99s username & zip code are = included as query parameters in the URL. That=E2=80=99s horrible for = user privacy but there=E2=80=99s no way to construct normative language = that will account for that case and no way to construct normative = language that accounts for user identifying header fields either because = from the perspective of the dCDN, the values of the URL or special = headers are opaque to the dCDN. >>>=20 >>> Having some discussion of the risks (as the above text outlines) is = fine & probably a good thing IMO, trying to construct normative text = serves no purpose IMO except giving folks a warm fuzzy feeling that = they=E2=80=99ve protected user privacy without doing actually doing so. = I thought our role here was to produce interoperable standards, not to = be the Internet privacy police. >>>=20 >>> I also wonder whether including normative text for this would = actually achieve the opposite of the desired effect - i.e. having = normative text may cause some implementers to assume that all = privacy-related scenarios have been covered and lead folks to follow the = normative text and not consider the privacy implications of header = fields/etc not explicitly called out by the document? >>=20 >> I think Ben makes a valid argument that a CDN may not be in a = position to comply to any normative behaviour. >> So can we stick to the text above recommended by Stephen to discuss = the issue, raise concern and make suggestions and leave it at that? >>=20 >>>=20 >>>=20 >>>>> (2) >>>>> Section 7.1 says: >>>>>=20 >>>>> "In an environment where any such protection is required, mutually >>>>> authenticated encrypted transport MUST be used to ensure >>>>> confidentiality of the logging information. To that end, TLS MUST = be >>>>> used (including authentication of the remote end) by the = server-side >>>>> and the client-side of the CDNI Logging feed, as well as the = server- >>>>> side and the client-side of the CDNI Logging File pull mechanism." >>>>>=20 >>>>> I know this text has been the subject of much discussion and = careful >>>>> editing, and that I raised an issue on this on the redirection = draft. >>>>> What I don't understand from reading this is whether the = expectation is >>>>> that all servers and clients implementing this specification will = use >>>>> TLS. The first sentence seems to indicate that there will be cases = when >>>>> that is not true. The second sentence says MUST use, which means = use in >>>>> every case. Which is it? >>>>=20 >>>> The answer to your question is meant to be conveyed by =E2=80=9CTo = that end=E2=80=9D. >>>> In other words: When protection is needed, authenticated encrypted = transport MUST be used. And when this is done, it MUST be achieved using = TLS. >>>>=20 >>>> Can you leave with "to that end=E2=80=9D ? >>>>=20 >>>> If not, how about: >>>> "In an environment where any such protection is required, mutually >>>> authenticated encrypted transport MUST be used to ensure >>>> confidentiality of the logging information, and to do so TLS MUST = be >>>> used (including authentication of the remote end) by the = server-side >>>> and the client-side of the CDNI Logging feed, as well as the = server- >>>> side and the client-side of the CDNI Logging File pull mechanism." >>>> ? >>>=20 >>> Personally I find the relentless wordsmithing of this text to be = incredibly tiresome. Way back at the beginning we had text that = essentially said =E2=80=9Cyou need to authenticate & encrypt the = transport and in the absence of anything else use TLS=E2=80=9D and = we=E2=80=99ve slowly creeped towards =E2=80=9CMUST use TLS and nothing = else=E2=80=9D. I must have missed the memo that said that TLS is the = panacea for authenticated & encrypted transport and that VPNs and other = approaches have been deprecated in favour of TLS. >>>=20 >>> I=E2=80=99ve said in other threads that for the CDNI documents I = edit, I=E2=80=99ll include whatever text is agreed for this logging = document and I will do that, but I strongly believe that folks will = implement what their customers=E2=80=99 want and that folks will deploy = what makes sense for them irrespective of what we write in our = documents. Further wordsmithing of the text is pure theatre IMO and adds = no additional value or clarity to the document IMO. >>>=20 >>> IMO this is a good example of the IESG demanding edits that go = beyond what is required to meet the bar for Proposed Standard. I see = nothing in the original text (or any of the previous versions of the = same section) that contradicts the requirements for Proposed Standard = described in section 3.1 of RFC7127 or that will materially improve = interoperability. Changing the text does nothing except waste more time = in tiresome debate IMO. We should just accept the text as-is and move on = to more important things IMO. >>=20 >> I agree with Ben we need to move on on that topic. But I think the = change I propose above is purely editorial and for clarification, so = doing that last change should not destabilise anything. So, Alissa, = please tell us whether the current text is acceptable, or if you prefer = the proposed change text. >>=20 >>=20 >>>=20 >>>>> = ---------------------------------------------------------------------- >>>>> COMMENT: >>>>> = ---------------------------------------------------------------------- >>>>>=20 >>>>> (1) Per my first DISCUSS point above, I wonder if it makes sense = to >>>>> specify a field where the dCDN could report a sanitized version of = the >>>>> client User-Agent string. This would allow a uCDN to calculate the >>>>> "terminal type" KPI listed in 2.2.5.5.2 without requiring full, >>>>> potentially identifying User-Agent strings to be logged. >>>>=20 >>>> I see the idea. >>>> But I think there are several fields which may contain user = identifying information. >>>> So how about we add a statement following the text provided by = Stephen to the effect that when fields (e.g. User Agent) contain = user-identifying information they SHOULD be sanitised to remove the = sensitive information while keeping non-sensitive information (e.g. = terminal type) and that the sanitisation is to be agreed upon by uCDN = and dCDN. >>>=20 >>> Which assumes the uCDN & dCDN are in a position to know which fields = contains sensitive information and which do not, which in the general = case neither the uCDN or dCDN are in a position to know. >>=20 >> This is back to the earlier point. Given, as Ben points out, that the = CDN may not be in a position to comply to any normative language and = given there is text recommended by Stephen to discuss the issue, raise = concern and make suggestions, can we leave it at that? >>=20 >>>=20 >>>>> (2) I think the use of partial-time in 3.4.1 means that the = timestamps >>>>> have no time zone information. It's not clear to me how the uCDN = uses >>>>> these timestamps in an absolute sense anyway, but I'm wondering if = that >>>>> could create problems if the uCDN does not know what time zone the = dCDN >>>>> is in. The time information in that case is somewhat meaningless = if the >>>>> uCDN needs to know the actual time at which something occurred. >>>>=20 >>>> I think this is a problem. We could either move to full-time, or = stick with partial-time but specify that time is always expressed in = GMT. I will poll the list on that. >>>=20 >>> My vote is for partial-time expressed in UTC. >>=20 >> As agreed on the list, the next rev will specify the =E2=80=9Ctime=E2=80= =9D field value is expressed in UTC, which solves the concern. >>=20 >> Francois >>=20 >>>=20 >>> Ben >>=20 From nobody Thu Mar 31 10:52:26 2016 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 5E62512D5D2; Thu, 31 Mar 2016 10:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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 ifA5PnP0UVcE; Thu, 31 Mar 2016 10:52:01 -0700 (PDT) Received: from mail-wm0-x241.google.com (mail-wm0-x241.google.com [IPv6:2a00:1450:400c:c09::241]) (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 DDE1512D6D5; Thu, 31 Mar 2016 10:51:59 -0700 (PDT) Received: by mail-wm0-x241.google.com with SMTP id 20so25737428wmh.3; Thu, 31 Mar 2016 10:51:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=c5A+4QS9vpKV1EQGpXVhdAY5ogNc92QyFN2hqDslApk=; b=mSE/sbUb8BzmwFszTgBBRgbCIQU1R0HLwLunrCSv6QbfdzcXuIdMTEPpZYtdvu+fvk 14z2nPYkD5bXyoexRb/ewV0+H1QACsdJXSsgcHZYNV2SK9pbf4qV/6rBCSkwl2gxC4Sc 7MH1SMSGtePxSzF8tTbvmvY1HXOh+QXKRzIcf95tE7vazUhE+/LwTk70PvqY3xgfxU5f GmIPeHHgivZ0T5uBLl0FxOyWyipmlFYERVm0xvLKK9zV0g1E8h04du+LHN1eMmA6Otw7 CCf5sM97wSOgcuX9RmjVxSRybct/B5kM8JHTB32TW6gJpWoO71dT7MfjT3wujLr1EeL/ y7DA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=c5A+4QS9vpKV1EQGpXVhdAY5ogNc92QyFN2hqDslApk=; b=iYC7YPgoAkgPkgLEyG2Ypm6ZIPSWnFkfFedW+vyKQVttyAsMq0CPw9vtie6aJwRarx jNd1kZaK4WMXGWsFzEZojGt3wEB8mI26Ci51n6g7pOqhKQ7+oajJmOcofubg1HFRtIdY pB8tEEVpi6Nqo9H3lnQJsiGNaxJRjzZ1O6LcEdzFr6zc31aPWHiTQ7cERDsFEAyln6Zs S0Lv4ma7YnjVdo2PFavkt51EhFR06FIb+S9HKDW8riQWovtjH4xJkhlKsJcL0+XIVQM4 UGKFVRTW390X8MCdy9OE4KKFJDNGKU5zkLOiSyOLyOlx4Z+gMQO+lqoFV5kUBUgmK5Br GzRA== X-Gm-Message-State: AD7BkJLzr8+vQyuL2U4Gi66xRxxbmwX4BDp3wne52GlsqeU2k+OrxXfMIz6Mc8IEoi5uQA== X-Received: by 10.28.21.75 with SMTP id 72mr74949wmv.64.1459446718360; Thu, 31 Mar 2016 10:51:58 -0700 (PDT) Received: from ams-flefauch-nitro3.cisco.com ([173.38.220.42]) by smtp.gmail.com with ESMTPSA id 198sm10636794wml.22.2016.03.31.10.51.56 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 31 Mar 2016 10:51:57 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Francois Le Faucheur In-Reply-To: <605997F5-AD07-4C9B-96DE-41275DAE7B6A@cooperw.in> Date: Thu, 31 Mar 2016 19:51:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9993F747-938E-4FCD-A6A9-2B9EDC4B214F@gmail.com> References: <20160325182719.17995.1066.idtracker@ietfa.amsl.com> <6EC0B4CB-7F83-410F-9A0F-CCEF8F8436B4@gmail.com> <2DC5E6F0-F919-4DAB-BB43-3029C8A2B88A@niven-jenkins.co.uk> <5D3D0ADA-18AD-481F-B085-424B81A4CF90@cooperw.in> <3755C76F-28F9-4644-9AC0-090E1B06A2D1@gmail.com> <605997F5-AD07-4C9B-96DE-41275DAE7B6A@cooperw.in> To: Alissa Cooper X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "" , cdni-chairs@ietf.org, Le Faucheur Francois , IESG , draft-ietf-cdni-logging@ietf.org Subject: Re: [CDNi] Alissa Cooper's Discuss on draft-ietf-cdni-logging-23: (with DISCUSS and COMMENT) X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 31 Mar 2016 17:52:11 -0000 > On 31 Mar 2016, at 19:43, Alissa Cooper wrote: >=20 >=20 >> On Mar 31, 2016, at 10:26 AM, Francois Le Faucheur = wrote: >>=20 >> Hi Alissa, >>=20 >> Thanks for updating your Discuss to Abstain. >=20 > As several ADs have pointed out to me offline, it turns out abstain = doesn=E2=80=99t help you, you need one more yes or no-objection. Right. > So let=E2=80=99s see if I can get there. >=20 >>=20 >> It may be a moot point now, but just for the record: >>=20 >>>>=20 >>>>=20 >>>=20 >>> Maybe I wasn=E2=80=99t clear in articulating my point. The spec = clearly supports the ability for the dCDN to decide to send logs about = an aggregate of clients. That isn=E2=80=99t =E2=80=9Ctelling a content = provider=E2=80=9D what to log or not, but it is providing support for a = dCDN to not report a piece of data that would have been delivered to the = content provider if there were no CDN. If that is the point of = specifying c-groupid the way that it is specified =E2=80=94 including = normative recommendations clearly designed to ensure that the c-groupid = does indeed identify an aggregate and not a single client =E2=80=94 then = it seems to me to undermine the whole point of providing an identifier = for an aggregate if the dCDN then includes a bunch of header fields that = identify an individual client. The spec shouldn=E2=80=99t pretend to = support provision for some protections that it actually doesn=E2=80=99t = provide given the way it=E2=80=99s expected to be implemented. I think = at a minimum the draft needs to point this out in the paragraph Francois = quoted. Personally I don=E2=80=99t think making the recommendations in = the text about cookies normative gives anyone a fuzzier feeling than the = text does as-is, but I=E2=80=99m not going to say that it=E2=80=99s not = worth holding up the document over.=20 >>=20 >> Double negations sometimes get me, but I think you meant: >> "but I=E2=80=99m not going to say that it=E2=80=99s worth holding up = the document over =E2=80=9C, right? >=20 > Sorry for that, writing too quickly. Let=E2=80=99s see if making a = concrete suggestion will help. >=20 > I feel that we shouldn=E2=80=99t specify features that give the = pretense of privacy protection but don=E2=80=99t actually provide it, = without at least making that clear. So here is what I would suggest = after the paragraph about cookies: >=20 > "Furthermore, implementers making use of c-groupid to identify an = aggregate of clients rather than individual clients should realize that = by logging certain header fields they may create the possibility to = re-identify individual clients. In these cases heeding the above advice, = or not logging header fields at all, is particularly important if the = goal is to provide logs that do not identify individual clients.=E2=80=9D I am fine with that extra text. Just two minor editorials: * I would just propose to replace =E2=80=9Cimplementers=E2=80=9D = by =E2=80=9CCDNs=E2=80=9D in your text above because in the document = =E2=80=9Cimplementations=E2=80=9D refer to software supporting the = functionality , while the folks deploying the software/functionality are = referred to as the =E2=80=9CCDNs=E2=80=9D. Is that OK? * I would propose to replace =E2=80=9Cshould realize=E2=80=9D by = =E2=80=9Cought to realize" All good? Thanks for providing a specific suggestion. Francois >=20 > Alissa >=20 >=20 >>=20 >>>>=20 >>>=20 >>> I did not demand any edits. I asked a question because the text = isn=E2=80=99t clear. I don=E2=80=99t care if the standard is MUST use = TLS (which means all the time) or SHOULD use TLS (which means = sometimes). =E2=80=9CMUST use TLS sometimes=E2=80=9D is not a legitimate = choice. This is relevant for the IESG to comment on because MUST means = something specific everywhere we use it, not just in this document, and = I=E2=80=99d rather not establish a precedent that MUST means =E2=80=9Cuse = it sometimes.=E2=80=9D >>=20 >> As discussed, the text was not intended to say =E2=80=9Cuse it = sometimes=E2=80=9D but rather =E2=80=9Cunder such circumstances, it MUST = be used=E2=80=9D which I believe is a perfectly IESG-friendly way to use = =E2=80=9CMUST=E2=80=9D 8^). I think the updated text reflects that more = clearly now. >>=20 >> Thanks again for working fast with us to resolution. >>=20 >> Francois >>=20 >>=20 >>>=20 >>> Alissa >>>=20 >>>>=20 >>>>>> = ---------------------------------------------------------------------- >>>>>> COMMENT: >>>>>> = ---------------------------------------------------------------------- >>>>>>=20 >>>>>> (1) Per my first DISCUSS point above, I wonder if it makes sense = to >>>>>> specify a field where the dCDN could report a sanitized version = of the >>>>>> client User-Agent string. This would allow a uCDN to calculate = the >>>>>> "terminal type" KPI listed in 2.2.5.5.2 without requiring full, >>>>>> potentially identifying User-Agent strings to be logged. >>>>>=20 >>>>> I see the idea. >>>>> But I think there are several fields which may contain user = identifying information. >>>>> So how about we add a statement following the text provided by = Stephen to the effect that when fields (e.g. User Agent) contain = user-identifying information they SHOULD be sanitised to remove the = sensitive information while keeping non-sensitive information (e.g. = terminal type) and that the sanitisation is to be agreed upon by uCDN = and dCDN. >>>>=20 >>>> Which assumes the uCDN & dCDN are in a position to know which = fields contains sensitive information and which do not, which in the = general case neither the uCDN or dCDN are in a position to know.=20 >>>>=20 >>>>>> (2) I think the use of partial-time in 3.4.1 means that the = timestamps >>>>>> have no time zone information. It's not clear to me how the uCDN = uses >>>>>> these timestamps in an absolute sense anyway, but I'm wondering = if that >>>>>> could create problems if the uCDN does not know what time zone = the dCDN >>>>>> is in. The time information in that case is somewhat meaningless = if the >>>>>> uCDN needs to know the actual time at which something occurred. >>>>>=20 >>>>> I think this is a problem. We could either move to full-time, or = stick with partial-time but specify that time is always expressed in = GMT. I will poll the list on that. >>>>=20 >>>> My vote is for partial-time expressed in UTC. >>>>=20 >>>> Ben >>>>=20 >>>=20 >>=20 >=20 From nobody Thu Mar 31 10:53:06 2016 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 006C112D700 for ; Thu, 31 Mar 2016 10:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=NEkAbkyz; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=ssBFWJHj 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 mm7p2UfoAYZc for ; Thu, 31 Mar 2016 10:52:55 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF39D12D6D5 for ; Thu, 31 Mar 2016 10:52:55 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 7C466229BA for ; Thu, 31 Mar 2016 13:43:05 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute5.internal (MEProxy); Thu, 31 Mar 2016 13:43:05 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=jgdzXlJdcBRw0HFRJX3z/xV6xJA=; b=NEkAbk yzZzrVrL8D0GeT9/8o5xWUjbUHq3wc12s41kJOndIUMSRonh3vZ/o3GJ83FkJC94 OeNRnfjaAo2pq1BdyheMTcUE5xc4xbUPmNVTLGTKO27JVKbMIs3+3hqAmZLNuCT8 k0o54sCTaZDiGHx+S6l70kyrT4zT0jBadKeuI= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=jgdzXlJdcBRw0HF RJX3z/xV6xJA=; b=ssBFWJHjIBqMBkjHZyoPfMZebmc+lPa1j3dCJIBKvQ3psz9 E7lomS8y8Twp8FwKTpLy/2FcN/nmcX4OoiorUXoivBLTlpe/b0e5qUEtQ+ZjSP1t w51TFVwao60bwPDN7WcVuL9xVn8vLRzHZFnaJMMbRjso/V+kKOZ0QDr72gWc= X-Sasl-enc: QyjnhEK+giqYK/h4XPWzZ6QM1tPA0QMqe4CVPbAq05q4 1459446185 Received: from dhcp-171-68-20-39.cisco.com (dhcp-171-68-20-39.cisco.com [171.68.20.39]) by mail.messagingengine.com (Postfix) with ESMTPA id A7B76C00045; Thu, 31 Mar 2016 13:43:04 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alissa Cooper In-Reply-To: <3755C76F-28F9-4644-9AC0-090E1B06A2D1@gmail.com> Date: Thu, 31 Mar 2016 10:43:48 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <605997F5-AD07-4C9B-96DE-41275DAE7B6A@cooperw.in> References: <20160325182719.17995.1066.idtracker@ietfa.amsl.com> <6EC0B4CB-7F83-410F-9A0F-CCEF8F8436B4@gmail.com> <2DC5E6F0-F919-4DAB-BB43-3029C8A2B88A@niven-jenkins.co.uk> <5D3D0ADA-18AD-481F-B085-424B81A4CF90@cooperw.in> <3755C76F-28F9-4644-9AC0-090E1B06A2D1@gmail.com> To: Francois Le Faucheur X-Mailer: Apple Mail (2.3112) Archived-At: Cc: draft-ietf-cdni-logging@ietf.org, IESG , "" , cdni-chairs@ietf.org Subject: Re: [CDNi] Alissa Cooper's Discuss on draft-ietf-cdni-logging-23: (with DISCUSS and COMMENT) X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 31 Mar 2016 17:53:03 -0000 > On Mar 31, 2016, at 10:26 AM, Francois Le Faucheur = wrote: >=20 > Hi Alissa, >=20 > Thanks for updating your Discuss to Abstain. As several ADs have pointed out to me offline, it turns out abstain = doesn=E2=80=99t help you, you need one more yes or no-objection. So = let=E2=80=99s see if I can get there. >=20 > It may be a moot point now, but just for the record: >=20 >>>=20 >>>=20 >>=20 >> Maybe I wasn=E2=80=99t clear in articulating my point. The spec = clearly supports the ability for the dCDN to decide to send logs about = an aggregate of clients. That isn=E2=80=99t =E2=80=9Ctelling a content = provider=E2=80=9D what to log or not, but it is providing support for a = dCDN to not report a piece of data that would have been delivered to the = content provider if there were no CDN. If that is the point of = specifying c-groupid the way that it is specified =E2=80=94 including = normative recommendations clearly designed to ensure that the c-groupid = does indeed identify an aggregate and not a single client =E2=80=94 then = it seems to me to undermine the whole point of providing an identifier = for an aggregate if the dCDN then includes a bunch of header fields that = identify an individual client. The spec shouldn=E2=80=99t pretend to = support provision for some protections that it actually doesn=E2=80=99t = provide given the way it=E2=80=99s expected to be implemented. I think = at a minimum the draft needs to point this out in the paragraph Francois = quoted. Personally I don=E2=80=99t think making the recommendations in = the text about cookies normative gives anyone a fuzzier feeling than the = text does as-is, but I=E2=80=99m not going to say that it=E2=80=99s not = worth holding up the document over.=20 >=20 > Double negations sometimes get me, but I think you meant: > "but I=E2=80=99m not going to say that it=E2=80=99s worth holding up = the document over =E2=80=9C, right? Sorry for that, writing too quickly. Let=E2=80=99s see if making a = concrete suggestion will help. I feel that we shouldn=E2=80=99t specify features that give the pretense = of privacy protection but don=E2=80=99t actually provide it, without at = least making that clear. So here is what I would suggest after the = paragraph about cookies: "Furthermore, implementers making use of c-groupid to identify an = aggregate of clients rather than individual clients should realize that = by logging certain header fields they may create the possibility to = re-identify individual clients. In these cases heeding the above advice, = or not logging header fields at all, is particularly important if the = goal is to provide logs that do not identify individual clients.=E2=80=9D Alissa >=20 >>>=20 >>=20 >> I did not demand any edits. I asked a question because the text = isn=E2=80=99t clear. I don=E2=80=99t care if the standard is MUST use = TLS (which means all the time) or SHOULD use TLS (which means = sometimes). =E2=80=9CMUST use TLS sometimes=E2=80=9D is not a legitimate = choice. This is relevant for the IESG to comment on because MUST means = something specific everywhere we use it, not just in this document, and = I=E2=80=99d rather not establish a precedent that MUST means =E2=80=9Cuse = it sometimes.=E2=80=9D >=20 > As discussed, the text was not intended to say =E2=80=9Cuse it = sometimes=E2=80=9D but rather =E2=80=9Cunder such circumstances, it MUST = be used=E2=80=9D which I believe is a perfectly IESG-friendly way to use = =E2=80=9CMUST=E2=80=9D 8^). I think the updated text reflects that more = clearly now. >=20 > Thanks again for working fast with us to resolution. >=20 > Francois >=20 >=20 >>=20 >> Alissa >>=20 >>>=20 >>>>> = ---------------------------------------------------------------------- >>>>> COMMENT: >>>>> = ---------------------------------------------------------------------- >>>>>=20 >>>>> (1) Per my first DISCUSS point above, I wonder if it makes sense = to >>>>> specify a field where the dCDN could report a sanitized version of = the >>>>> client User-Agent string. This would allow a uCDN to calculate the >>>>> "terminal type" KPI listed in 2.2.5.5.2 without requiring full, >>>>> potentially identifying User-Agent strings to be logged. >>>>=20 >>>> I see the idea. >>>> But I think there are several fields which may contain user = identifying information. >>>> So how about we add a statement following the text provided by = Stephen to the effect that when fields (e.g. User Agent) contain = user-identifying information they SHOULD be sanitised to remove the = sensitive information while keeping non-sensitive information (e.g. = terminal type) and that the sanitisation is to be agreed upon by uCDN = and dCDN. >>>=20 >>> Which assumes the uCDN & dCDN are in a position to know which fields = contains sensitive information and which do not, which in the general = case neither the uCDN or dCDN are in a position to know.=20 >>>=20 >>>>> (2) I think the use of partial-time in 3.4.1 means that the = timestamps >>>>> have no time zone information. It's not clear to me how the uCDN = uses >>>>> these timestamps in an absolute sense anyway, but I'm wondering if = that >>>>> could create problems if the uCDN does not know what time zone the = dCDN >>>>> is in. The time information in that case is somewhat meaningless = if the >>>>> uCDN needs to know the actual time at which something occurred. >>>>=20 >>>> I think this is a problem. We could either move to full-time, or = stick with partial-time but specify that time is always expressed in = GMT. I will poll the list on that. >>>=20 >>> My vote is for partial-time expressed in UTC. >>>=20 >>> Ben >>>=20 >>=20 >=20 From nobody Thu Mar 31 10:58:10 2016 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 BDDE112D690 for ; Thu, 31 Mar 2016 10:57:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=qUrbrdxX; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=JxR3+MAO 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 uYRgzfV06Eht for ; Thu, 31 Mar 2016 10:57:53 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38FC712D6A7 for ; Thu, 31 Mar 2016 10:57:53 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 8EB2B22A9F for ; Thu, 31 Mar 2016 13:57:52 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Thu, 31 Mar 2016 13:57:52 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=KblZB MJI4g0fwc8el+z9gomj+zw=; b=qUrbrdxX9ec9BDI2Tl3HuIFpCdxMfYYaFvL/d ICQNiZjkE5MzhKHUBu62bUzVlTFaeHhnzQvoFansW5yvonjcrhizR/mgnnjfmT4t 3p+o11nVgOBUXnf++ANL0NVCios/H9Y65PtS74Xe8q3YznVcKNuKgLcSjGtjoNNJ 8SRLbE= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=KblZBMJI4g0fwc8el+z9gomj+zw=; b=JxR3+ MAORc9yxMo+sRzm8xuHEiEVmwYGBlrHlcSLvwoKM6ucmryYZDDpUlOfZFblqJJ8S 7FsGDtJU4trIo2QJpXs80c5n/LcxKSS+X1bBioBALAJH2sTeCwl1FU/7nIxx+3I9 N5sVZZPWNto96WtfuD/KLuvbHG38jt0uRR0fBU= X-Sasl-enc: P5Z/R5ofhNUQE8fyiXehgBXndH/HMCIJ4+Qm9711oQXJ 1459447071 Received: from dhcp-171-68-20-39.cisco.com (dhcp-171-68-20-39.cisco.com [171.68.20.39]) by mail.messagingengine.com (Postfix) with ESMTPA id 40404C00020; Thu, 31 Mar 2016 13:57:51 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_56E0FF97-DDC6-4BB7-BA96-030DE155CF2F" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alissa Cooper In-Reply-To: <9993F747-938E-4FCD-A6A9-2B9EDC4B214F@gmail.com> Date: Thu, 31 Mar 2016 10:58:35 -0700 Message-Id: <147D55CC-4927-4E07-B50B-D1603481A2EA@cooperw.in> References: <20160325182719.17995.1066.idtracker@ietfa.amsl.com> <6EC0B4CB-7F83-410F-9A0F-CCEF8F8436B4@gmail.com> <2DC5E6F0-F919-4DAB-BB43-3029C8A2B88A@niven-jenkins.co.uk> <5D3D0ADA-18AD-481F-B085-424B81A4CF90@cooperw.in> <3755C76F-28F9-4644-9AC0-090E1B06A2D1@gmail.com> <605997F5-AD07-4C9B-96DE-41275DAE7B6A@cooperw.in> <9993F747-938E-4FCD-A6A9-2B9EDC4B214F@gmail.com> To: Francois Le Faucheur X-Mailer: Apple Mail (2.3112) Archived-At: Cc: draft-ietf-cdni-logging@ietf.org, IESG , "" , cdni-chairs@ietf.org Subject: Re: [CDNi] Alissa Cooper's Discuss on draft-ietf-cdni-logging-23: (with DISCUSS and COMMENT) X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 31 Mar 2016 17:57:56 -0000 --Apple-Mail=_56E0FF97-DDC6-4BB7-BA96-030DE155CF2F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 31, 2016, at 10:51 AM, Francois Le Faucheur = wrote: >=20 >>=20 >> On 31 Mar 2016, at 19:43, Alissa Cooper > wrote: >>=20 >>=20 >>> On Mar 31, 2016, at 10:26 AM, Francois Le Faucheur = > wrote: >>>=20 >>> Hi Alissa, >>>=20 >>> Thanks for updating your Discuss to Abstain. >>=20 >> As several ADs have pointed out to me offline, it turns out abstain = doesn=E2=80=99t help you, you need one more yes or no-objection. >=20 > Right. >=20 >> So let=E2=80=99s see if I can get there. >>=20 >>>=20 >>> It may be a moot point now, but just for the record: >>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>> Maybe I wasn=E2=80=99t clear in articulating my point. The spec = clearly supports the ability for the dCDN to decide to send logs about = an aggregate of clients. That isn=E2=80=99t =E2=80=9Ctelling a content = provider=E2=80=9D what to log or not, but it is providing support for a = dCDN to not report a piece of data that would have been delivered to the = content provider if there were no CDN. If that is the point of = specifying c-groupid the way that it is specified =E2=80=94 including = normative recommendations clearly designed to ensure that the c-groupid = does indeed identify an aggregate and not a single client =E2=80=94 then = it seems to me to undermine the whole point of providing an identifier = for an aggregate if the dCDN then includes a bunch of header fields that = identify an individual client. The spec shouldn=E2=80=99t pretend to = support provision for some protections that it actually doesn=E2=80=99t = provide given the way it=E2=80=99s expected to be implemented. I think = at a minimum the draft needs to point this out in the paragraph Francois = quoted. Personally I don=E2=80=99t think making the recommendations in = the text about cookies normative gives anyone a fuzzier feeling than the = text does as-is, but I=E2=80=99m not going to say that it=E2=80=99s not = worth holding up the document over.=20 >>>=20 >>> Double negations sometimes get me, but I think you meant: >>> "but I=E2=80=99m not going to say that it=E2=80=99s worth holding up = the document over =E2=80=9C, right? >>=20 >> Sorry for that, writing too quickly. Let=E2=80=99s see if making a = concrete suggestion will help. >>=20 >> I feel that we shouldn=E2=80=99t specify features that give the = pretense of privacy protection but don=E2=80=99t actually provide it, = without at least making that clear. So here is what I would suggest = after the paragraph about cookies: >>=20 >> "Furthermore, implementers making use of c-groupid to identify an = aggregate of clients rather than individual clients should realize that = by logging certain header fields they may create the possibility to = re-identify individual clients. In these cases heeding the above advice, = or not logging header fields at all, is particularly important if the = goal is to provide logs that do not identify individual clients.=E2=80=9D >=20 > I am fine with that extra text. >=20 > Just two minor editorials: > * I would just propose to replace =E2=80=9Cimplementers=E2=80=9D = by =E2=80=9CCDNs=E2=80=9D in your text above because in the document = =E2=80=9Cimplementations=E2=80=9D refer to software supporting the = functionality , while the folks deploying the software/functionality are = referred to as the =E2=80=9CCDNs=E2=80=9D. Is that OK? > * I would propose to replace =E2=80=9Cshould realize=E2=80=9D by = =E2=80=9Cought to realize" > All good? WFM >=20 > Thanks for providing a specific suggestion. >=20 > Francois >=20 >=20 >>=20 >> Alissa >>=20 >>=20 >>>=20 >>>>>=20 >>>>=20 >>>> I did not demand any edits. I asked a question because the text = isn=E2=80=99t clear. I don=E2=80=99t care if the standard is MUST use = TLS (which means all the time) or SHOULD use TLS (which means = sometimes). =E2=80=9CMUST use TLS sometimes=E2=80=9D is not a legitimate = choice. This is relevant for the IESG to comment on because MUST means = something specific everywhere we use it, not just in this document, and = I=E2=80=99d rather not establish a precedent that MUST means =E2=80=9Cuse = it sometimes.=E2=80=9D >>>=20 >>> As discussed, the text was not intended to say =E2=80=9Cuse it = sometimes=E2=80=9D but rather =E2=80=9Cunder such circumstances, it MUST = be used=E2=80=9D which I believe is a perfectly IESG-friendly way to use = =E2=80=9CMUST=E2=80=9D 8^). I think the updated text reflects that more = clearly now. >>>=20 >>> Thanks again for working fast with us to resolution. >>>=20 >>> Francois >>>=20 >>>=20 >>>>=20 >>>> Alissa >>>>=20 >>>>>=20 >>>>>>> = ---------------------------------------------------------------------- >>>>>>> COMMENT: >>>>>>> = ---------------------------------------------------------------------- >>>>>>>=20 >>>>>>> (1) Per my first DISCUSS point above, I wonder if it makes sense = to >>>>>>> specify a field where the dCDN could report a sanitized version = of the >>>>>>> client User-Agent string. This would allow a uCDN to calculate = the >>>>>>> "terminal type" KPI listed in 2.2.5.5.2 without requiring full, >>>>>>> potentially identifying User-Agent strings to be logged. >>>>>>=20 >>>>>> I see the idea. >>>>>> But I think there are several fields which may contain user = identifying information. >>>>>> So how about we add a statement following the text provided by = Stephen to the effect that when fields (e.g. User Agent) contain = user-identifying information they SHOULD be sanitised to remove the = sensitive information while keeping non-sensitive information (e.g. = terminal type) and that the sanitisation is to be agreed upon by uCDN = and dCDN. >>>>>=20 >>>>> Which assumes the uCDN & dCDN are in a position to know which = fields contains sensitive information and which do not, which in the = general case neither the uCDN or dCDN are in a position to know.=20 >>>>>=20 >>>>>>> (2) I think the use of partial-time in 3.4.1 means that the = timestamps >>>>>>> have no time zone information. It's not clear to me how the uCDN = uses >>>>>>> these timestamps in an absolute sense anyway, but I'm wondering = if that >>>>>>> could create problems if the uCDN does not know what time zone = the dCDN >>>>>>> is in. The time information in that case is somewhat meaningless = if the >>>>>>> uCDN needs to know the actual time at which something occurred. >>>>>>=20 >>>>>> I think this is a problem. We could either move to full-time, or = stick with partial-time but specify that time is always expressed in = GMT. I will poll the list on that. >>>>>=20 >>>>> My vote is for partial-time expressed in UTC. >>>>>=20 >>>>> Ben --Apple-Mail=_56E0FF97-DDC6-4BB7-BA96-030DE155CF2F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Mar 31, 2016, at 10:51 AM, Francois Le Faucheur <flefauch@gmail.com> = wrote:


On 31 Mar 2016, at 19:43, Alissa = Cooper <alissa@cooperw.in> wrote:


On Mar = 31, 2016, at 10:26 AM, Francois Le Faucheur <flefauch@gmail.com> = wrote:

Hi Alissa,

Thanks for updating your Discuss to Abstain.

As several ADs have pointed out = to me offline, it turns out abstain doesn=E2=80=99t help you, you need = one more yes or no-objection.

Right.

So = let=E2=80=99s see if I can get there.


It may be = a moot point now, but just for the record:




Maybe= I wasn=E2=80=99t clear in articulating my point. The spec clearly = supports the ability for the dCDN to decide to send logs about an = aggregate of clients. That isn=E2=80=99t =E2=80=9Ctelling a content = provider=E2=80=9D what to log or not, but it is providing support for a = dCDN to not report a piece of data that would have been delivered to the = content provider if there were no CDN. If that is the point of = specifying c-groupid the way that it is specified =E2=80=94 including = normative recommendations clearly designed to ensure that the c-groupid = does indeed identify an aggregate and not a single client =E2=80=94 then = it seems to me to undermine the whole point of providing an identifier = for an aggregate if the dCDN then includes a bunch of header fields that = identify an individual client. The spec shouldn=E2=80=99t pretend to = support provision for some protections that it actually doesn=E2=80=99t = provide given the way it=E2=80=99s expected to be implemented. I think = at a minimum the draft needs to point this out in the paragraph Francois = quoted. Personally I don=E2=80=99t think making the recommendations in = the text about cookies normative gives anyone a fuzzier feeling than the = text does as-is, but I=E2=80=99m not going to say that it=E2=80=99s not = worth holding up the document over. 

Double negations sometimes get = me, but I think you meant:
"but I=E2=80=99m not going to = say that it=E2=80=99s worth holding up the document over =E2=80=9C, = right?

Sorry for that, writing = too quickly. Let=E2=80=99s see if making a concrete suggestion will = help.

I feel that we shouldn=E2=80=99t = specify features that give the pretense of privacy protection but = don=E2=80=99t actually provide it, without at least making that clear. = So here is what I would suggest after the paragraph about cookies:

"Furthermore, implementers making use of = c-groupid to identify an aggregate of clients rather than individual = clients should realize that by logging certain header fields they may = create the possibility to re-identify individual clients. In these cases = heeding the above advice, or not logging header fields at all, is = particularly important if the goal is to provide logs that do not = identify individual clients.=E2=80=9D

I am fine with that extra = text.

Just two minor = editorials:
* I would just propose to = replace =E2=80=9Cimplementers=E2=80=9D by =E2=80=9CCDNs=E2=80=9D in your = text above because in the document =E2=80=9Cimplementations=E2=80=9D = refer to software supporting the functionality , while the folks = deploying the software/functionality are referred to as the =E2=80=9CCDNs=E2= =80=9D. Is that OK?
* I would propose to = replace =E2=80=9Cshould realize=E2=80=9D by =E2=80=9Cought to = realize"
All good?

WFM


Thanks for providing a = specific suggestion.

Francois



Alissa





I did not demand any edits. I = asked a question because the text isn=E2=80=99t clear. I don=E2=80=99t = care if the standard is MUST use TLS (which means all the time) or = SHOULD use TLS (which means sometimes). =E2=80=9CMUST use TLS = sometimes=E2=80=9D is not a legitimate choice. This is relevant for the = IESG to comment on because MUST means something specific everywhere we = use it, not just in this document, and I=E2=80=99d rather not establish = a precedent that MUST means =E2=80=9Cuse it sometimes.=E2=80=9D

As discussed, the text was not = intended to say =E2=80=9Cuse it sometimes=E2=80=9D but rather =E2=80=9Cund= er such circumstances, it MUST be used=E2=80=9D which I believe is a = perfectly IESG-friendly way to use =E2=80=9CMUST=E2=80=9D  8^). I = think the updated text reflects that more clearly now.

Thanks again for working fast with us to resolution.

Francois



Alissa


---------------------------------------------------------------= -------
COMMENT:
---------------------------------------------------------------= -------

(1) Per my first DISCUSS point = above, I wonder if it makes sense to
specify a field where = the dCDN could report a sanitized version of the
client = User-Agent string. This would allow a uCDN to calculate the
"terminal type" KPI listed in 2.2.5.5.2 without requiring = full,
potentially identifying User-Agent strings to be = logged.

I see the idea.
But I think there are several fields which may contain user = identifying information.
So how about we add a statement = following the text provided by Stephen to the effect that when fields = (e.g. User Agent) contain user-identifying information they SHOULD be = sanitised to remove the sensitive information while keeping = non-sensitive information (e.g. terminal type) and that the sanitisation = is to be agreed upon by uCDN and dCDN.

Which assumes the uCDN & dCDN are in a position to know = which fields contains sensitive information and which do not, which in = the general case neither the uCDN or dCDN are in a position to = know. 
(2) I think the use of partial-time in 3.4.1 means that the = timestamps
have no time zone information. It's not clear = to me how the uCDN uses
these timestamps in an absolute = sense anyway, but I'm wondering if that
could create = problems if the uCDN does not know what time zone the dCDN
is in. The time information in that case is somewhat = meaningless if the
uCDN needs to know the actual time at = which something occurred.

I = think this is a problem. We could either move to full-time, or stick = with partial-time but specify that time is always expressed in GMT. I = will poll the list on that.

My = vote is for partial-time expressed in UTC.

Ben

= --Apple-Mail=_56E0FF97-DDC6-4BB7-BA96-030DE155CF2F-- From nobody Thu Mar 31 11:01:05 2016 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 0DCE012D550; Thu, 31 Mar 2016 11:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 yi_cAaRTJb1v; Thu, 31 Mar 2016 11:00:59 -0700 (PDT) Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (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 C101C12D142; Thu, 31 Mar 2016 11:00:58 -0700 (PDT) Received: by mail-wm0-x243.google.com with SMTP id p65so25799246wmp.1; Thu, 31 Mar 2016 11:00:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=tzLzrOcmqVyijM2wKkn7Jt6FJz0byYoDmS04YA3VabY=; b=ktltHXvwutzqawHaXmBsOlOGJoTL45jv2D9A64TdrUKdfc3HyW3uog1bclbIeiPuDA WnHJvRz8TOxULJ6KfgtxNq/bBbvAyu3Wrd8aP0LA4S8cgMQ/XETtee09s8C8x/s5PEbu k2nDWHv3/BkznbpXctkuqkasOTd0+M6EJ1G+3avdcMJN1mItT2JeV4aWlFVmcnL4stkw eHJG6Ipbwdt+B3S1r1rdxh5cxbLfIB4ccnQ45kp7oE0mtbBCDjEZY8kMnhA6jsV0FUnW xTB1YhoFw85SEscXEPHMixB2JikrQdIbVhHI/h+7HHq8QrTcRsTUGwMVUMVK4JuQZrYJ 9O5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=tzLzrOcmqVyijM2wKkn7Jt6FJz0byYoDmS04YA3VabY=; b=UZWRDWKpN5HFi69mwxjUfx1eulACzfQzFCVSwdk8hpG9cUC345T2JZRSBHb3TdPcnu pB6GDzHA8kq9IYW8rSnVMJNopgXSXr8Da4xxwAY+PtOz8a+Hu/TkEcZjoqFYPj/L+I1f kvBYbvJji2q7otRzQAVyINo2MnvqFb5KFhep/w2vDiaZhNsj4t9dCa98A0V5DzosiPGz WELoJPcbIVB4aGK1YTbTEeVRkpu0/3sOufXKjMcQGt2pqS+KnYrIFDCJn9mp3LjSKUuO u+j4K81/O6Srisp4cgwKqMpBxHzAZpWPxMm46FxwSQtWyzX7Gj5lHjGpMdnKNokvv7vB Uh2w== X-Gm-Message-State: AD7BkJJYQY8CHMX1XocfLMtW61ndqL12U7JpdG0xWWGJ9C9GT3In6sGK2T6P07FoEwTtoQ== X-Received: by 10.28.73.66 with SMTP id w63mr87214wma.53.1459447257250; Thu, 31 Mar 2016 11:00:57 -0700 (PDT) Received: from ams-flefauch-nitro3.cisco.com ([173.38.220.42]) by smtp.gmail.com with ESMTPSA id w131sm10629192wmd.17.2016.03.31.11.00.54 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 31 Mar 2016 11:00:56 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_B41CBBFC-7807-4C57-9F08-63B6C463F569" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Francois Le Faucheur In-Reply-To: <147D55CC-4927-4E07-B50B-D1603481A2EA@cooperw.in> Date: Thu, 31 Mar 2016 20:00:51 +0200 Message-Id: <634E06FE-EC8A-4EF1-8F52-D649AA68260F@gmail.com> References: <20160325182719.17995.1066.idtracker@ietfa.amsl.com> <6EC0B4CB-7F83-410F-9A0F-CCEF8F8436B4@gmail.com> <2DC5E6F0-F919-4DAB-BB43-3029C8A2B88A@niven-jenkins.co.uk> <5D3D0ADA-18AD-481F-B085-424B81A4CF90@cooperw.in> <3755C76F-28F9-4644-9AC0-090E1B06A2D1@gmail.com> <605997F5-AD07-4C9B-96DE-41275DAE7B6A@cooperw.in> <9993F747-938E-4FCD-A6A9-2B9EDC4B214F@gmail.com> <147D55CC-4927-4E07-B50B-D1603481A2EA@cooperw.in> To: Alissa Cooper X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "" , cdni-chairs@ietf.org, Le Faucheur Francois , IESG , draft-ietf-cdni-logging@ietf.org Subject: Re: [CDNi] Alissa Cooper's Discuss on draft-ietf-cdni-logging-23: (with DISCUSS and COMMENT) X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 31 Mar 2016 18:01:02 -0000 --Apple-Mail=_B41CBBFC-7807-4C57-9F08-63B6C463F569 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I will post a new version with all the agreed text as soon as posting = reopens. Thanks a lot for working with us. Francois > On 31 Mar 2016, at 19:58, Alissa Cooper wrote: >=20 >=20 >> On Mar 31, 2016, at 10:51 AM, Francois Le Faucheur = > wrote: >>=20 >>>=20 >>> On 31 Mar 2016, at 19:43, Alissa Cooper > wrote: >>>=20 >>>=20 >>>> On Mar 31, 2016, at 10:26 AM, Francois Le Faucheur = > wrote: >>>>=20 >>>> Hi Alissa, >>>>=20 >>>> Thanks for updating your Discuss to Abstain. >>>=20 >>> As several ADs have pointed out to me offline, it turns out abstain = doesn=E2=80=99t help you, you need one more yes or no-objection. >>=20 >> Right. >>=20 >>> So let=E2=80=99s see if I can get there. >>>=20 >>>>=20 >>>> It may be a moot point now, but just for the record: >>>>=20 >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>> Maybe I wasn=E2=80=99t clear in articulating my point. The spec = clearly supports the ability for the dCDN to decide to send logs about = an aggregate of clients. That isn=E2=80=99t =E2=80=9Ctelling a content = provider=E2=80=9D what to log or not, but it is providing support for a = dCDN to not report a piece of data that would have been delivered to the = content provider if there were no CDN. If that is the point of = specifying c-groupid the way that it is specified =E2=80=94 including = normative recommendations clearly designed to ensure that the c-groupid = does indeed identify an aggregate and not a single client =E2=80=94 then = it seems to me to undermine the whole point of providing an identifier = for an aggregate if the dCDN then includes a bunch of header fields that = identify an individual client. The spec shouldn=E2=80=99t pretend to = support provision for some protections that it actually doesn=E2=80=99t = provide given the way it=E2=80=99s expected to be implemented. I think = at a minimum the draft needs to point this out in the paragraph Francois = quoted. Personally I don=E2=80=99t think making the recommendations in = the text about cookies normative gives anyone a fuzzier feeling than the = text does as-is, but I=E2=80=99m not going to say that it=E2=80=99s not = worth holding up the document over.=20 >>>>=20 >>>> Double negations sometimes get me, but I think you meant: >>>> "but I=E2=80=99m not going to say that it=E2=80=99s worth holding = up the document over =E2=80=9C, right? >>>=20 >>> Sorry for that, writing too quickly. Let=E2=80=99s see if making a = concrete suggestion will help. >>>=20 >>> I feel that we shouldn=E2=80=99t specify features that give the = pretense of privacy protection but don=E2=80=99t actually provide it, = without at least making that clear. So here is what I would suggest = after the paragraph about cookies: >>>=20 >>> "Furthermore, implementers making use of c-groupid to identify an = aggregate of clients rather than individual clients should realize that = by logging certain header fields they may create the possibility to = re-identify individual clients. In these cases heeding the above advice, = or not logging header fields at all, is particularly important if the = goal is to provide logs that do not identify individual clients.=E2=80=9D >>=20 >> I am fine with that extra text. >>=20 >> Just two minor editorials: >> * I would just propose to replace =E2=80=9Cimplementers=E2=80=9D = by =E2=80=9CCDNs=E2=80=9D in your text above because in the document = =E2=80=9Cimplementations=E2=80=9D refer to software supporting the = functionality , while the folks deploying the software/functionality are = referred to as the =E2=80=9CCDNs=E2=80=9D. Is that OK? >> * I would propose to replace =E2=80=9Cshould realize=E2=80=9D by = =E2=80=9Cought to realize" >> All good? >=20 > WFM >=20 >>=20 >> Thanks for providing a specific suggestion. >>=20 >> Francois >>=20 >>=20 >>>=20 >>> Alissa >>>=20 >>>=20 >>>>=20 >>>>>>=20 >>>>>=20 >>>>> I did not demand any edits. I asked a question because the text = isn=E2=80=99t clear. I don=E2=80=99t care if the standard is MUST use = TLS (which means all the time) or SHOULD use TLS (which means = sometimes). =E2=80=9CMUST use TLS sometimes=E2=80=9D is not a legitimate = choice. This is relevant for the IESG to comment on because MUST means = something specific everywhere we use it, not just in this document, and = I=E2=80=99d rather not establish a precedent that MUST means =E2=80=9Cuse = it sometimes.=E2=80=9D >>>>=20 >>>> As discussed, the text was not intended to say =E2=80=9Cuse it = sometimes=E2=80=9D but rather =E2=80=9Cunder such circumstances, it MUST = be used=E2=80=9D which I believe is a perfectly IESG-friendly way to use = =E2=80=9CMUST=E2=80=9D 8^). I think the updated text reflects that more = clearly now. >>>>=20 >>>> Thanks again for working fast with us to resolution. >>>>=20 >>>> Francois >>>>=20 >>>>=20 >>>>>=20 >>>>> Alissa >>>>>=20 >>>>>>=20 >>>>>>>> = ---------------------------------------------------------------------- >>>>>>>> COMMENT: >>>>>>>> = ---------------------------------------------------------------------- >>>>>>>>=20 >>>>>>>> (1) Per my first DISCUSS point above, I wonder if it makes = sense to >>>>>>>> specify a field where the dCDN could report a sanitized version = of the >>>>>>>> client User-Agent string. This would allow a uCDN to calculate = the >>>>>>>> "terminal type" KPI listed in 2.2.5.5.2 without requiring full, >>>>>>>> potentially identifying User-Agent strings to be logged. >>>>>>>=20 >>>>>>> I see the idea. >>>>>>> But I think there are several fields which may contain user = identifying information. >>>>>>> So how about we add a statement following the text provided by = Stephen to the effect that when fields (e.g. User Agent) contain = user-identifying information they SHOULD be sanitised to remove the = sensitive information while keeping non-sensitive information (e.g. = terminal type) and that the sanitisation is to be agreed upon by uCDN = and dCDN. >>>>>>=20 >>>>>> Which assumes the uCDN & dCDN are in a position to know which = fields contains sensitive information and which do not, which in the = general case neither the uCDN or dCDN are in a position to know.=20 >>>>>>=20 >>>>>>>> (2) I think the use of partial-time in 3.4.1 means that the = timestamps >>>>>>>> have no time zone information. It's not clear to me how the = uCDN uses >>>>>>>> these timestamps in an absolute sense anyway, but I'm wondering = if that >>>>>>>> could create problems if the uCDN does not know what time zone = the dCDN >>>>>>>> is in. The time information in that case is somewhat = meaningless if the >>>>>>>> uCDN needs to know the actual time at which something occurred. >>>>>>>=20 >>>>>>> I think this is a problem. We could either move to full-time, or = stick with partial-time but specify that time is always expressed in = GMT. I will poll the list on that. >>>>>>=20 >>>>>> My vote is for partial-time expressed in UTC. >>>>>>=20 >>>>>> Ben >=20 --Apple-Mail=_B41CBBFC-7807-4C57-9F08-63B6C463F569 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I will post a new version with all the agreed text as soon as = posting reopens.

Thanks a lot for working with us.

Francois


On = 31 Mar 2016, at 19:58, Alissa Cooper <alissa@cooperw.in> = wrote:


On Mar 31, 2016, at 10:51 AM, Francois Le Faucheur <flefauch@gmail.com> = wrote:


On 31 Mar 2016, at 19:43, Alissa = Cooper <alissa@cooperw.in> wrote:


On Mar = 31, 2016, at 10:26 AM, Francois Le Faucheur <flefauch@gmail.com> = wrote:

Hi Alissa,

Thanks for updating your Discuss to Abstain.

As several ADs have pointed out = to me offline, it turns out abstain doesn=E2=80=99t help you, you need = one more yes or no-objection.

Right.

So = let=E2=80=99s see if I can get there.


It may be = a moot point now, but just for the record:




Maybe= I wasn=E2=80=99t clear in articulating my point. The spec clearly = supports the ability for the dCDN to decide to send logs about an = aggregate of clients. That isn=E2=80=99t =E2=80=9Ctelling a content = provider=E2=80=9D what to log or not, but it is providing support for a = dCDN to not report a piece of data that would have been delivered to the = content provider if there were no CDN. If that is the point of = specifying c-groupid the way that it is specified =E2=80=94 including = normative recommendations clearly designed to ensure that the c-groupid = does indeed identify an aggregate and not a single client =E2=80=94 then = it seems to me to undermine the whole point of providing an identifier = for an aggregate if the dCDN then includes a bunch of header fields that = identify an individual client. The spec shouldn=E2=80=99t pretend to = support provision for some protections that it actually doesn=E2=80=99t = provide given the way it=E2=80=99s expected to be implemented. I think = at a minimum the draft needs to point this out in the paragraph Francois = quoted. Personally I don=E2=80=99t think making the recommendations in = the text about cookies normative gives anyone a fuzzier feeling than the = text does as-is, but I=E2=80=99m not going to say that it=E2=80=99s not = worth holding up the document over. 

Double negations sometimes get = me, but I think you meant:
"but I=E2=80=99m not going to = say that it=E2=80=99s worth holding up the document over =E2=80=9C, = right?

Sorry for that, writing = too quickly. Let=E2=80=99s see if making a concrete suggestion will = help.

I feel that we shouldn=E2=80=99t = specify features that give the pretense of privacy protection but = don=E2=80=99t actually provide it, without at least making that clear. = So here is what I would suggest after the paragraph about cookies:

"Furthermore, implementers making use of = c-groupid to identify an aggregate of clients rather than individual = clients should realize that by logging certain header fields they may = create the possibility to re-identify individual clients. In these cases = heeding the above advice, or not logging header fields at all, is = particularly important if the goal is to provide logs that do not = identify individual clients.=E2=80=9D

I am fine with that extra = text.

Just two minor = editorials:
* I would just propose to = replace =E2=80=9Cimplementers=E2=80=9D by =E2=80=9CCDNs=E2=80=9D in your = text above because in the document =E2=80=9Cimplementations=E2=80=9D = refer to software supporting the functionality , while the folks = deploying the software/functionality are referred to as the =E2=80=9CCDNs=E2= =80=9D. Is that OK?
* I would propose to = replace =E2=80=9Cshould realize=E2=80=9D by =E2=80=9Cought to = realize"
All good?

WFM


Thanks for providing a specific = suggestion.

Francois



Alissa





I did not demand any edits. I = asked a question because the text isn=E2=80=99t clear. I don=E2=80=99t = care if the standard is MUST use TLS (which means all the time) or = SHOULD use TLS (which means sometimes). =E2=80=9CMUST use TLS = sometimes=E2=80=9D is not a legitimate choice. This is relevant for the = IESG to comment on because MUST means something specific everywhere we = use it, not just in this document, and I=E2=80=99d rather not establish = a precedent that MUST means =E2=80=9Cuse it sometimes.=E2=80=9D

As discussed, the text was not = intended to say =E2=80=9Cuse it sometimes=E2=80=9D but rather =E2=80=9Cund= er such circumstances, it MUST be used=E2=80=9D which I believe is a = perfectly IESG-friendly way to use =E2=80=9CMUST=E2=80=9D  8^). I = think the updated text reflects that more clearly now.

Thanks again for working fast with us to resolution.

Francois



Alissa


---------------------------------------------------------------= -------
COMMENT:
---------------------------------------------------------------= -------

(1) Per my first DISCUSS point = above, I wonder if it makes sense to
specify a field where = the dCDN could report a sanitized version of the
client = User-Agent string. This would allow a uCDN to calculate the
"terminal type" KPI listed in 2.2.5.5.2 without requiring = full,
potentially identifying User-Agent strings to be = logged.

I see the idea.
But I think there are several fields which may contain user = identifying information.
So how about we add a statement = following the text provided by Stephen to the effect that when fields = (e.g. User Agent) contain user-identifying information they SHOULD be = sanitised to remove the sensitive information while keeping = non-sensitive information (e.g. terminal type) and that the sanitisation = is to be agreed upon by uCDN and dCDN.

Which assumes the uCDN & dCDN are in a position to know = which fields contains sensitive information and which do not, which in = the general case neither the uCDN or dCDN are in a position to = know. 
(2) I think the use of partial-time in 3.4.1 means that the = timestamps
have no time zone information. It's not clear = to me how the uCDN uses
these timestamps in an absolute = sense anyway, but I'm wondering if that
could create = problems if the uCDN does not know what time zone the dCDN
is in. The time information in that case is somewhat = meaningless if the
uCDN needs to know the actual time at = which something occurred.

I = think this is a problem. We could either move to full-time, or stick = with partial-time but specify that time is always expressed in GMT. I = will poll the list on that.

My = vote is for partial-time expressed in UTC.

Ben


= --Apple-Mail=_B41CBBFC-7807-4C57-9F08-63B6C463F569-- From nobody Thu Mar 31 11:12:59 2016 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 AD93512D6A7 for ; Thu, 31 Mar 2016 11:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=GKBpbAym; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=RwGUeEcp 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 zYk3Y8SYtK4f for ; Thu, 31 Mar 2016 11:12:56 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A6FE12D0F0 for ; Thu, 31 Mar 2016 11:12:56 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id B09B822AAB for ; Thu, 31 Mar 2016 14:05:25 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Thu, 31 Mar 2016 14:05:25 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=ysHBr /geDIRJUCZpBhreMSzr0l4=; b=GKBpbAymnw3kOLaDNAUyoBGxrTem93DgRabCc 9JetcqqMB8MIh/cWnJzClMNBAWmNxneKK2Av/rD2jfQSe+7MyCe+jLGYWyLFgotr zUB5bBLQj2THEMXTKHU8VwlmfsLnfTF3VSYEGKksDhbIDMf65XmKAEy25EPD2hsF YhdJok= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=ysHBr/geDIRJUCZpBhreMSzr0l4=; b=RwGUe EcpVBPhz1L+LA5LEc1lfT9b9x3IwbyW4LNugZAKEOfRcfCQw2BbgYm5gmhOqLvwU ZfSo9DxuBeAMoK43yc6kqQNenFzmhX5hoZojQTq1F2ZCtAhlyPOQ1HqgmOyoza6v LuCrCy0eZkf7x2l8zHwk4Fu5qGPmXA7gBeptNg= X-Sasl-enc: 2bz0AagusUEVfyOLgbGFUwOF8mcxKBun/EZhvBL7rf79 1459447525 Received: from dhcp-171-68-20-39.cisco.com (dhcp-171-68-20-39.cisco.com [171.68.20.39]) by mail.messagingengine.com (Postfix) with ESMTPA id 9E5B8C00022; Thu, 31 Mar 2016 14:05:24 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_1C8B7708-1FFC-4F9B-B18E-E5D9402BE808" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alissa Cooper In-Reply-To: <634E06FE-EC8A-4EF1-8F52-D649AA68260F@gmail.com> Date: Thu, 31 Mar 2016 11:06:08 -0700 Message-Id: <16EF3BE5-C0F0-47E3-A75F-01AB82B1A312@cooperw.in> References: <20160325182719.17995.1066.idtracker@ietfa.amsl.com> <6EC0B4CB-7F83-410F-9A0F-CCEF8F8436B4@gmail.com> <2DC5E6F0-F919-4DAB-BB43-3029C8A2B88A@niven-jenkins.co.uk> <5D3D0ADA-18AD-481F-B085-424B81A4CF90@cooperw.in> <3755C76F-28F9-4644-9AC0-090E1B06A2D1@gmail.com> <605997F5-AD07-4C9B-96DE-41275DAE7B6A@cooperw.in> <9993F747-938E-4FCD-A6A9-2B9EDC4B214F@gmail.com> <147D55CC-4927-4E07-B50B-D1603481A2EA@cooperw.in> <634E06FE-EC8A-4EF1-8F52-D649AA68260F@gmail.com> To: Francois Le Faucheur X-Mailer: Apple Mail (2.3112) Archived-At: Cc: draft-ietf-cdni-logging@ietf.org, IESG , "" , cdni-chairs@ietf.org Subject: Re: [CDNi] Alissa Cooper's Discuss on draft-ietf-cdni-logging-23: (with DISCUSS and COMMENT) X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 31 Mar 2016 18:12:57 -0000 --Apple-Mail=_1C8B7708-1FFC-4F9B-B18E-E5D9402BE808 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 31, 2016, at 11:00 AM, Francois Le Faucheur = wrote: >=20 > I will post a new version with all the agreed text as soon as posting = reopens. Great. I=E2=80=99ll update my ballot when it gets posted. Alissa >=20 > Thanks a lot for working with us. >=20 > Francois >=20 >=20 >> On 31 Mar 2016, at 19:58, Alissa Cooper > wrote: >>=20 >>=20 >>> On Mar 31, 2016, at 10:51 AM, Francois Le Faucheur = > wrote: >>>=20 >>>>=20 >>>> On 31 Mar 2016, at 19:43, Alissa Cooper > wrote: >>>>=20 >>>>=20 >>>>> On Mar 31, 2016, at 10:26 AM, Francois Le Faucheur = > wrote: >>>>>=20 >>>>> Hi Alissa, >>>>>=20 >>>>> Thanks for updating your Discuss to Abstain. >>>>=20 >>>> As several ADs have pointed out to me offline, it turns out abstain = doesn=E2=80=99t help you, you need one more yes or no-objection. >>>=20 >>> Right. >>>=20 >>>> So let=E2=80=99s see if I can get there. >>>>=20 >>>>>=20 >>>>> It may be a moot point now, but just for the record: >>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>> Maybe I wasn=E2=80=99t clear in articulating my point. The spec = clearly supports the ability for the dCDN to decide to send logs about = an aggregate of clients. That isn=E2=80=99t =E2=80=9Ctelling a content = provider=E2=80=9D what to log or not, but it is providing support for a = dCDN to not report a piece of data that would have been delivered to the = content provider if there were no CDN. If that is the point of = specifying c-groupid the way that it is specified =E2=80=94 including = normative recommendations clearly designed to ensure that the c-groupid = does indeed identify an aggregate and not a single client =E2=80=94 then = it seems to me to undermine the whole point of providing an identifier = for an aggregate if the dCDN then includes a bunch of header fields that = identify an individual client. The spec shouldn=E2=80=99t pretend to = support provision for some protections that it actually doesn=E2=80=99t = provide given the way it=E2=80=99s expected to be implemented. I think = at a minimum the draft needs to point this out in the paragraph Francois = quoted. Personally I don=E2=80=99t think making the recommendations in = the text about cookies normative gives anyone a fuzzier feeling than the = text does as-is, but I=E2=80=99m not going to say that it=E2=80=99s not = worth holding up the document over.=20 >>>>>=20 >>>>> Double negations sometimes get me, but I think you meant: >>>>> "but I=E2=80=99m not going to say that it=E2=80=99s worth holding = up the document over =E2=80=9C, right? >>>>=20 >>>> Sorry for that, writing too quickly. Let=E2=80=99s see if making a = concrete suggestion will help. >>>>=20 >>>> I feel that we shouldn=E2=80=99t specify features that give the = pretense of privacy protection but don=E2=80=99t actually provide it, = without at least making that clear. So here is what I would suggest = after the paragraph about cookies: >>>>=20 >>>> "Furthermore, implementers making use of c-groupid to identify an = aggregate of clients rather than individual clients should realize that = by logging certain header fields they may create the possibility to = re-identify individual clients. In these cases heeding the above advice, = or not logging header fields at all, is particularly important if the = goal is to provide logs that do not identify individual clients.=E2=80=9D >>>=20 >>> I am fine with that extra text. >>>=20 >>> Just two minor editorials: >>> * I would just propose to replace =E2=80=9Cimplementers=E2=80=9D = by =E2=80=9CCDNs=E2=80=9D in your text above because in the document = =E2=80=9Cimplementations=E2=80=9D refer to software supporting the = functionality , while the folks deploying the software/functionality are = referred to as the =E2=80=9CCDNs=E2=80=9D. Is that OK? >>> * I would propose to replace =E2=80=9Cshould realize=E2=80=9D by = =E2=80=9Cought to realize" >>> All good? >>=20 >> WFM >>=20 >>>=20 >>> Thanks for providing a specific suggestion. >>>=20 >>> Francois >>>=20 >>>=20 >>>>=20 >>>> Alissa >>>>=20 >>>>=20 >>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>> I did not demand any edits. I asked a question because the text = isn=E2=80=99t clear. I don=E2=80=99t care if the standard is MUST use = TLS (which means all the time) or SHOULD use TLS (which means = sometimes). =E2=80=9CMUST use TLS sometimes=E2=80=9D is not a legitimate = choice. This is relevant for the IESG to comment on because MUST means = something specific everywhere we use it, not just in this document, and = I=E2=80=99d rather not establish a precedent that MUST means =E2=80=9Cuse = it sometimes.=E2=80=9D >>>>>=20 >>>>> As discussed, the text was not intended to say =E2=80=9Cuse it = sometimes=E2=80=9D but rather =E2=80=9Cunder such circumstances, it MUST = be used=E2=80=9D which I believe is a perfectly IESG-friendly way to use = =E2=80=9CMUST=E2=80=9D 8^). I think the updated text reflects that more = clearly now. >>>>>=20 >>>>> Thanks again for working fast with us to resolution. >>>>>=20 >>>>> Francois >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>> Alissa >>>>>>=20 >>>>>>>=20 >>>>>>>>> = ---------------------------------------------------------------------- >>>>>>>>> COMMENT: >>>>>>>>> = ---------------------------------------------------------------------- >>>>>>>>>=20 >>>>>>>>> (1) Per my first DISCUSS point above, I wonder if it makes = sense to >>>>>>>>> specify a field where the dCDN could report a sanitized = version of the >>>>>>>>> client User-Agent string. This would allow a uCDN to calculate = the >>>>>>>>> "terminal type" KPI listed in 2.2.5.5.2 without requiring = full, >>>>>>>>> potentially identifying User-Agent strings to be logged. >>>>>>>>=20 >>>>>>>> I see the idea. >>>>>>>> But I think there are several fields which may contain user = identifying information. >>>>>>>> So how about we add a statement following the text provided by = Stephen to the effect that when fields (e.g. User Agent) contain = user-identifying information they SHOULD be sanitised to remove the = sensitive information while keeping non-sensitive information (e.g. = terminal type) and that the sanitisation is to be agreed upon by uCDN = and dCDN. >>>>>>>=20 >>>>>>> Which assumes the uCDN & dCDN are in a position to know which = fields contains sensitive information and which do not, which in the = general case neither the uCDN or dCDN are in a position to know.=20 >>>>>>>=20 >>>>>>>>> (2) I think the use of partial-time in 3.4.1 means that the = timestamps >>>>>>>>> have no time zone information. It's not clear to me how the = uCDN uses >>>>>>>>> these timestamps in an absolute sense anyway, but I'm = wondering if that >>>>>>>>> could create problems if the uCDN does not know what time zone = the dCDN >>>>>>>>> is in. The time information in that case is somewhat = meaningless if the >>>>>>>>> uCDN needs to know the actual time at which something = occurred. >>>>>>>>=20 >>>>>>>> I think this is a problem. We could either move to full-time, = or stick with partial-time but specify that time is always expressed in = GMT. I will poll the list on that. >>>>>>>=20 >>>>>>> My vote is for partial-time expressed in UTC. >>>>>>>=20 >>>>>>> Ben >>=20 >=20 --Apple-Mail=_1C8B7708-1FFC-4F9B-B18E-E5D9402BE808 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Mar 31, 2016, at 11:00 AM, Francois Le Faucheur <flefauch@gmail.com> = wrote:

I will post a = new version with all the agreed text as soon as posting = reopens.

Great. = I=E2=80=99ll update my ballot when it gets posted.

Alissa


Thanks a = lot for working with us.

Francois


On 31 = Mar 2016, at 19:58, Alissa Cooper <alissa@cooperw.in> wrote:


On Mar 31, 2016, at 10:51 AM, Francois Le Faucheur <flefauch@gmail.com> = wrote:


On 31 Mar 2016, at 19:43, Alissa = Cooper <alissa@cooperw.in> wrote:


On Mar = 31, 2016, at 10:26 AM, Francois Le Faucheur <flefauch@gmail.com> = wrote:

Hi Alissa,

Thanks for updating your Discuss to Abstain.

As several ADs have pointed out = to me offline, it turns out abstain doesn=E2=80=99t help you, you need = one more yes or no-objection.

Right.

So = let=E2=80=99s see if I can get there.


It may be = a moot point now, but just for the record:




Maybe= I wasn=E2=80=99t clear in articulating my point. The spec clearly = supports the ability for the dCDN to decide to send logs about an = aggregate of clients. That isn=E2=80=99t =E2=80=9Ctelling a content = provider=E2=80=9D what to log or not, but it is providing support for a = dCDN to not report a piece of data that would have been delivered to the = content provider if there were no CDN. If that is the point of = specifying c-groupid the way that it is specified =E2=80=94 including = normative recommendations clearly designed to ensure that the c-groupid = does indeed identify an aggregate and not a single client =E2=80=94 then = it seems to me to undermine the whole point of providing an identifier = for an aggregate if the dCDN then includes a bunch of header fields that = identify an individual client. The spec shouldn=E2=80=99t pretend to = support provision for some protections that it actually doesn=E2=80=99t = provide given the way it=E2=80=99s expected to be implemented. I think = at a minimum the draft needs to point this out in the paragraph Francois = quoted. Personally I don=E2=80=99t think making the recommendations in = the text about cookies normative gives anyone a fuzzier feeling than the = text does as-is, but I=E2=80=99m not going to say that it=E2=80=99s not = worth holding up the document over. 

Double negations sometimes get = me, but I think you meant:
"but I=E2=80=99m not going to = say that it=E2=80=99s worth holding up the document over =E2=80=9C, = right?

Sorry for that, writing = too quickly. Let=E2=80=99s see if making a concrete suggestion will = help.

I feel that we shouldn=E2=80=99t = specify features that give the pretense of privacy protection but = don=E2=80=99t actually provide it, without at least making that clear. = So here is what I would suggest after the paragraph about cookies:

"Furthermore, implementers making use of = c-groupid to identify an aggregate of clients rather than individual = clients should realize that by logging certain header fields they may = create the possibility to re-identify individual clients. In these cases = heeding the above advice, or not logging header fields at all, is = particularly important if the goal is to provide logs that do not = identify individual clients.=E2=80=9D

I am fine with that extra = text.

Just two minor = editorials:
* I would just propose to = replace =E2=80=9Cimplementers=E2=80=9D by =E2=80=9CCDNs=E2=80=9D in your = text above because in the document =E2=80=9Cimplementations=E2=80=9D = refer to software supporting the functionality , while the folks = deploying the software/functionality are referred to as the =E2=80=9CCDNs=E2= =80=9D. Is that OK?
* I would propose to = replace =E2=80=9Cshould realize=E2=80=9D by =E2=80=9Cought to = realize"
All good?

WFM


Thanks for providing a specific = suggestion.

Francois



Alissa





I did not demand any edits. I = asked a question because the text isn=E2=80=99t clear. I don=E2=80=99t = care if the standard is MUST use TLS (which means all the time) or = SHOULD use TLS (which means sometimes). =E2=80=9CMUST use TLS = sometimes=E2=80=9D is not a legitimate choice. This is relevant for the = IESG to comment on because MUST means something specific everywhere we = use it, not just in this document, and I=E2=80=99d rather not establish = a precedent that MUST means =E2=80=9Cuse it sometimes.=E2=80=9D

As discussed, the text was not = intended to say =E2=80=9Cuse it sometimes=E2=80=9D but rather =E2=80=9Cund= er such circumstances, it MUST be used=E2=80=9D which I believe is a = perfectly IESG-friendly way to use =E2=80=9CMUST=E2=80=9D  8^). I = think the updated text reflects that more clearly now.

Thanks again for working fast with us to resolution.

Francois



Alissa


---------------------------------------------------------------= -------
COMMENT:
---------------------------------------------------------------= -------

(1) Per my first DISCUSS point = above, I wonder if it makes sense to
specify a field where = the dCDN could report a sanitized version of the
client = User-Agent string. This would allow a uCDN to calculate the
"terminal type" KPI listed in 2.2.5.5.2 without requiring = full,
potentially identifying User-Agent strings to be = logged.

I see the idea.
But I think there are several fields which may contain user = identifying information.
So how about we add a statement = following the text provided by Stephen to the effect that when fields = (e.g. User Agent) contain user-identifying information they SHOULD be = sanitised to remove the sensitive information while keeping = non-sensitive information (e.g. terminal type) and that the sanitisation = is to be agreed upon by uCDN and dCDN.

Which assumes the uCDN & dCDN are in a position to know = which fields contains sensitive information and which do not, which in = the general case neither the uCDN or dCDN are in a position to = know. 
(2) I think the use of partial-time in 3.4.1 means that the = timestamps
have no time zone information. It's not clear = to me how the uCDN uses
these timestamps in an absolute = sense anyway, but I'm wondering if that
could create = problems if the uCDN does not know what time zone the dCDN
is in. The time information in that case is somewhat = meaningless if the
uCDN needs to know the actual time at = which something occurred.

I = think this is a problem. We could either move to full-time, or stick = with partial-time but specify that time is always expressed in GMT. I = will poll the list on that.

My = vote is for partial-time expressed in UTC.

Ben



= --Apple-Mail=_1C8B7708-1FFC-4F9B-B18E-E5D9402BE808-- From nobody Thu Mar 31 18:16:47 2016 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 D75CE12D112; Thu, 31 Mar 2016 18:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 NjYM4o_ByS23; Thu, 31 Mar 2016 18:16:43 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (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 4E0D812D1A1; Thu, 31 Mar 2016 18:10:40 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id g3so124994674ywa.3; Thu, 31 Mar 2016 18:10:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=dUYG0H/Akgdkk3BfmxBqT23VI2y6c4P68vifzKJs93M=; b=nleETmv8uuuLfBJtQP9mOwjCPO477wLOlgeYBE7w+tHDojBiThL4rAkktHgyFw1bAB Km9mUzHQr4nC1eY+q3PD9rm/N+Toe85EHxVaWpDgX83gIVaWuTMC7oUHnH/pcDu8m13R c733shmmP3TJZjcE7O6vh0+mfkkee+ZSgck0/amSeT4f2e2PBfbJEKuALn8r9PUlBvEe w92jMJLggwBujRLJCCQTDTBF9aESr1U6pBguPBMi8iCmff1HJD9qdw8eBFGwFIcpo+bO KGh3DCQPBMXLTq1+ZQXt933QiiwiF7WBTOae0DQ4qYPZFzJyr9Esp/gL0Ahz52bhf2nS w8nw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=dUYG0H/Akgdkk3BfmxBqT23VI2y6c4P68vifzKJs93M=; b=ZBQEcqAtT9hk3Ga3TcEIGogG9NPjK3iZAeqtTS52K/p/UrPi4mD/0qgHDt5KC0mCIJ VGZLWo2w2heGOx+RRGq2WilJnfVNCN70fU4D6TWIeHEo8kH+E6RJfeRaTCl1Qouw9sDu vrknNzbSpUjwRBxp1e76//mP9wWdw6z9vUTg+9u+ZiKikPZ1jlyI67o2SOjo7/guvvRJ 5eOgeE/Vh5QhBdRs2hclQhyJPetyM6K1AMcsGp3nq11o+HrXjFKQoK3CpVg5H+/M9aut xUcZbemCaOg4kZWiecj+eXH8mV+L8bfQxUCty7LpIZajKD2IYfMd8y53QyIOsJZN/NyH BDSw== X-Gm-Message-State: AD7BkJJlu8T6LQFs00pgtFVEl6fZoYxf5MBI9xa8FMGXjZbgHhH2/ZEbNlnhtvEp8EylTFP5K0QmU0xfas+lyQ== MIME-Version: 1.0 X-Received: by 10.37.101.69 with SMTP id z66mr1763118ybb.90.1459473039349; Thu, 31 Mar 2016 18:10:39 -0700 (PDT) Received: by 10.37.214.13 with HTTP; Thu, 31 Mar 2016 18:10:39 -0700 (PDT) In-Reply-To: <16EF3BE5-C0F0-47E3-A75F-01AB82B1A312@cooperw.in> References: <20160325182719.17995.1066.idtracker@ietfa.amsl.com> <6EC0B4CB-7F83-410F-9A0F-CCEF8F8436B4@gmail.com> <2DC5E6F0-F919-4DAB-BB43-3029C8A2B88A@niven-jenkins.co.uk> <5D3D0ADA-18AD-481F-B085-424B81A4CF90@cooperw.in> <3755C76F-28F9-4644-9AC0-090E1B06A2D1@gmail.com> <605997F5-AD07-4C9B-96DE-41275DAE7B6A@cooperw.in> <9993F747-938E-4FCD-A6A9-2B9EDC4B214F@gmail.com> <147D55CC-4927-4E07-B50B-D1603481A2EA@cooperw.in> <634E06FE-EC8A-4EF1-8F52-D649AA68260F@gmail.com> <16EF3BE5-C0F0-47E3-A75F-01AB82B1A312@cooperw.in> Date: Thu, 31 Mar 2016 20:10:39 -0500 Message-ID: From: Spencer Dawkins at IETF To: Alissa Cooper Content-Type: multipart/alternative; boundary=001a1143019211df7d052f620cab Archived-At: Cc: "" , "cdni-chairs@ietf.org" , Francois Le Faucheur , IESG , "draft-ietf-cdni-logging@ietf.org" Subject: Re: [CDNi] Alissa Cooper's Discuss on draft-ietf-cdni-logging-23: (with DISCUSS and COMMENT) X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.17 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, 01 Apr 2016 01:16:46 -0000 --001a1143019211df7d052f620cab Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Mar 31, 2016 at 1:06 PM, Alissa Cooper wrote: > > On Mar 31, 2016, at 11:00 AM, Francois Le Faucheur > wrote: > > I will post a new version with all the agreed text as soon as posting > reopens. > > > Great. I=E2=80=99ll update my ballot when it gets posted. > As the AD responsible for this draft, I'd like to thank everyone for the quick and intense responses. Spencer p.s. I think the time difference is immaterial now (Friday versus Monday when posting reopens anyway, and I suspect that at least half the people who would need to notice the new version are either at the airport or about to be at the airport), but I routinely approve draft postings when they're in IESG evaluation and automatic posting is closed. Just so people can file that away, for future use. > Alissa > > > Thanks a lot for working with us. > > Francois > > > On 31 Mar 2016, at 19:58, Alissa Cooper wrote: > > > On Mar 31, 2016, at 10:51 AM, Francois Le Faucheur > wrote: > > > On 31 Mar 2016, at 19:43, Alissa Cooper wrote: > > > On Mar 31, 2016, at 10:26 AM, Francois Le Faucheur > wrote: > > Hi Alissa, > > Thanks for updating your Discuss to Abstain. > > > As several ADs have pointed out to me offline, it turns out abstain > doesn=E2=80=99t help you, you need one more yes or no-objection. > > > Right. > > So let=E2=80=99s see if I can get there. > > > It may be a moot point now, but just for the record: > > > > > Maybe I wasn=E2=80=99t clear in articulating my point. The spec clearly s= upports > the ability for the dCDN to decide to send logs about an aggregate of > clients. That isn=E2=80=99t =E2=80=9Ctelling a content provider=E2=80=9D = what to log or not, but it > is providing support for a dCDN to not report a piece of data that would > have been delivered to the content provider if there were no CDN. If that > is the point of specifying c-groupid the way that it is specified =E2=80= =94 > including normative recommendations clearly designed to ensure that the > c-groupid does indeed identify an aggregate and not a single client =E2= =80=94 then > it seems to me to undermine the whole point of providing an identifier fo= r > an aggregate if the dCDN then includes a bunch of header fields that > identify an individual client. The spec shouldn=E2=80=99t pretend to supp= ort > provision for some protections that it actually doesn=E2=80=99t provide g= iven the > way it=E2=80=99s expected to be implemented. I think at a minimum the dra= ft needs > to point this out in the paragraph Francois quoted. Personally I don=E2= =80=99t > think making the recommendations in the text about cookies normative give= s > anyone a fuzzier feeling than the text does as-is, but I=E2=80=99m not go= ing to say > that it=E2=80=99s not worth holding up the document over. > > > Double negations sometimes get me, but I think you meant: > "but I=E2=80=99m not going to say that it=E2=80=99s worth holding up the = document over =E2=80=9C, > right? > > > Sorry for that, writing too quickly. Let=E2=80=99s see if making a concre= te > suggestion will help. > > I feel that we shouldn=E2=80=99t specify features that give the pretense = of > privacy protection but don=E2=80=99t actually provide it, without at leas= t making > that clear. So here is what I would suggest after the paragraph about > cookies: > > "Furthermore, implementers making use of c-groupid to identify an > aggregate of clients rather than individual clients should realize that b= y > logging certain header fields they may create the possibility to > re-identify individual clients. In these cases heeding the above advice, = or > not logging header fields at all, is particularly important if the goal i= s > to provide logs that do not identify individual clients.=E2=80=9D > > > I am fine with that extra text. > > Just two minor editorials: > * I would just propose to replace =E2=80=9Cimplementers=E2=80=9D by =E2= =80=9CCDNs=E2=80=9D in your text > above because in the document =E2=80=9Cimplementations=E2=80=9D refer to = software > supporting the functionality , while the folks deploying the > software/functionality are referred to as the =E2=80=9CCDNs=E2=80=9D. Is = that OK? > * I would propose to replace =E2=80=9Cshould realize=E2=80=9D by =E2=80= =9Cought to realize" > All good? > > > WFM > > > Thanks for providing a specific suggestion. > > Francois > > > > Alissa > > > > > > I did not demand any edits. I asked a question because the text isn=E2=80= =99t > clear. I don=E2=80=99t care if the standard is MUST use TLS (which means = all the > time) or SHOULD use TLS (which means sometimes). =E2=80=9CMUST use TLS so= metimes=E2=80=9D > is not a legitimate choice. This is relevant for the IESG to comment on > because MUST means something specific everywhere we use it, not just in > this document, and I=E2=80=99d rather not establish a precedent that MUST= means > =E2=80=9Cuse it sometimes.=E2=80=9D > > > As discussed, the text was not intended to say =E2=80=9Cuse it sometimes= =E2=80=9D but > rather =E2=80=9Cunder such circumstances, it MUST be used=E2=80=9D which = I believe is a > perfectly IESG-friendly way to use =E2=80=9CMUST=E2=80=9D 8^). I think t= he updated text > reflects that more clearly now. > > Thanks again for working fast with us to resolution. > > Francois > > > > Alissa > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > (1) Per my first DISCUSS point above, I wonder if it makes sense to > specify a field where the dCDN could report a sanitized version of the > client User-Agent string. This would allow a uCDN to calculate the > "terminal type" KPI listed in 2.2.5.5.2 without requiring full, > potentially identifying User-Agent strings to be logged. > > > I see the idea. > But I think there are several fields which may contain user identifying > information. > So how about we add a statement following the text provided by Stephen to > the effect that when fields (e.g. User Agent) contain user-identifying > information they SHOULD be sanitised to remove the sensitive information > while keeping non-sensitive information (e.g. terminal type) and that the > sanitisation is to be agreed upon by uCDN and dCDN. > > > Which assumes the uCDN & dCDN are in a position to know which fields > contains sensitive information and which do not, which in the general cas= e > neither the uCDN or dCDN are in a position to know. > > (2) I think the use of partial-time in 3.4.1 means that the timestamps > have no time zone information. It's not clear to me how the uCDN uses > these timestamps in an absolute sense anyway, but I'm wondering if that > could create problems if the uCDN does not know what time zone the dCDN > is in. The time information in that case is somewhat meaningless if the > uCDN needs to know the actual time at which something occurred. > > > I think this is a problem. We could either move to full-time, or stick > with partial-time but specify that time is always expressed in GMT. I wil= l > poll the list on that. > > > My vote is for partial-time expressed in UTC. > > Ben > > > > > --001a1143019211df7d052f620cab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Mar 31, 2016 at 1:06 PM, Alissa Cooper <alissa@cooperw.in> wrote:

=
On Mar 31, 2016, at 11:00 A= M, Francois Le Faucheur <flefauch@gmail.com> wrote:

I will post a new version with all the agreed text as soo= n as posting reopens.

Gr= eat. I=E2=80=99ll update my ballot when it gets posted.

As the AD responsible for this draft, I'= d like to thank everyone for the quick and intense responses.

Spencer

p.s. I think the time differen= ce is immaterial now (Friday versus Monday when posting reopens anyway, and= I suspect that at least half the people who would need to notice the new v= ersion are either at the airport or about to be at the airport), but I rout= inely approve draft postings when they're in IESG evaluation and automa= tic posting is closed.=C2=A0

Just so people can fi= le that away, for future use.
=C2=A0
Alissa


Thanks a lot = for working with us.

Francois


On 31 Mar 2016, at 19:58, Alissa= Cooper <alissa@c= ooperw.in> wrote:

=
On Mar 31, 2016, at 10:51 AM, Franc= ois Le Faucheur <flefauch@gmail.com> wrote:


On 31 = Mar 2016, at 19:43, Alissa Cooper <alissa@cooperw.in> wrote:


On Mar 31, 2016, at 10:26 AM, Francois Le Faucheur <flefauch@gmail.com>= wrote:

Hi Alissa,

Thanks for updating your Discuss to Abstai= n.

As several ADs have pointed out to me offline, it tu= rns out abstain doesn=E2=80=99t help you, you need one more yes or no-objec= tion.

Right.

So let=E2= =80=99s see if I can get there.


It may= be a moot point now, but just for the record:




Maybe I wasn=E2=80= =99t clear in articulating my point. The spec clearly supports the ability = for the dCDN to decide to send logs about an aggregate of clients. That isn= =E2=80=99t =E2=80=9Ctelling a content provider=E2=80=9D what to log or not,= but it is providing support for a dCDN to not report a piece of data that = would have been delivered to the content provider if there were no CDN. If = that is the point of specifying c-groupid the way that it is specified =E2= =80=94 including normative recommendations clearly designed to ensure that = the c-groupid does indeed identify an aggregate and not a single client =E2= =80=94 then it seems to me to undermine the whole point of providing an ide= ntifier for an aggregate if the dCDN then includes a bunch of header fields= that identify an individual client. The spec shouldn=E2=80=99t pretend to = support provision for some protections that it actually doesn=E2=80=99t pro= vide given the way it=E2=80=99s expected to be implemented. I think at a mi= nimum the draft needs to point this out in the paragraph Francois quoted. P= ersonally I don=E2=80=99t think making the recommendations in the text abou= t cookies normative gives anyone a fuzzier feeling than the text does as-is= , but I=E2=80=99m not going to say that it=E2=80=99s not worth holding up t= he document over.=C2=A0

Double negations s= ometimes get me, but I think you meant:
"but I=E2=80=99m not going = to say that it=E2=80=99s worth holding up the document over =E2=80=9C, righ= t?

Sorry for that, writing too quickly. Let=E2=80=99s s= ee if making a concrete suggestion will help.

I feel that we shouldn= =E2=80=99t specify features that give the pretense of privacy protection bu= t don=E2=80=99t actually provide it, without at least making that clear. So= here is what I would suggest after the paragraph about cookies:

&qu= ot;Furthermore, implementers making use of c-groupid to identify an aggrega= te of clients rather than individual clients should realize that by logging= certain header fields they may create the possibility to re-identify indiv= idual clients. In these cases heeding the above advice, or not logging head= er fields at all, is particularly important if the goal is to provide logs = that do not identify individual clients.=E2=80=9D

I am fine with that extra text.

= Just two minor editorials:
* I would = just propose to replace =E2=80=9Cimplementers=E2=80=9D by =E2=80=9CCDNs=E2= =80=9D in your text above because in the document =E2=80=9Cimplementations= =E2=80=9D refer to software supporting the functionality , while the folks = deploying the software/functionality are referred to as the =E2=80=9CCDNs= =E2=80=9D. Is that OK?
* I would prop= ose to replace =E2=80=9Cshould realize=E2=80=9D by =E2=80=9Cought to realiz= e"
All good?
<= br>
WFM


Thanks for providing a specific suggestion.

Francois



Alissa





I did no= t demand any edits. I asked a question because the text isn=E2=80=99t clear= . I don=E2=80=99t care if the standard is MUST use TLS (which means all the= time) or SHOULD use TLS (which means sometimes). =E2=80=9CMUST use TLS som= etimes=E2=80=9D is not a legitimate choice. This is relevant for the IESG t= o comment on because MUST means something specific everywhere we use it, no= t just in this document, and I=E2=80=99d rather not establish a precedent t= hat MUST means =E2=80=9Cuse it sometimes.=E2=80=9D

As d= iscussed, the text was not intended to say =E2=80=9Cuse it sometimes=E2=80= =9D but rather =E2=80=9Cunder such circumstances, it MUST be used=E2=80=9D = which I believe is a perfectly IESG-friendly way to use =E2=80=9CMUST=E2=80= =9D =C2=A08^). I think the updated text reflects that more clearly now.
=
Thanks again for working fast with us to resolution.

Francois


Alissa


---------------= -------------------------------------------------------
COMMENT:
----= ------------------------------------------------------------------

(= 1) Per my first DISCUSS point above, I wonder if it makes sense to
speci= fy a field where the dCDN could report a sanitized version of the
client= User-Agent string. This would allow a uCDN to calculate the
"termi= nal type" KPI listed in 2.2.5.5.2 without requiring full,
potential= ly identifying User-Agent strings to be logged.

I see t= he idea.
But I think there are several fields which may contain user ide= ntifying information.
So how about we add a statement following the text= provided by Stephen to the effect that when fields (e.g. User Agent) conta= in user-identifying information they SHOULD be sanitised to remove the sens= itive information while keeping non-sensitive information (e.g. terminal ty= pe) and that the sanitisation is to be agreed upon by uCDN and dCDN.

Which assumes the uCDN & dCDN are in a position to know w= hich fields contains sensitive information and which do not, which in the g= eneral case neither the uCDN or dCDN are in a position to know.=C2=A0=

(2) I th= ink the use of partial-time in 3.4.1 means that the timestamps
have no t= ime zone information. It's not clear to me how the uCDN uses
these t= imestamps in an absolute sense anyway, but I'm wondering if that
cou= ld create problems if the uCDN does not know what time zone the dCDN
is = in. The time information in that case is somewhat meaningless if the
uCD= N needs to know the actual time at which something occurred.

I think this is a problem. We could either move to full-time, or stic= k with partial-time but specify that time is always expressed in GMT. I wil= l poll the list on that.

My vote is for partial-time ex= pressed in UTC.

Ben




--001a1143019211df7d052f620cab--