From nobody Tue May 3 05:44: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 3F72E12D7E4; Tue, 3 May 2016 05:44:42 -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 NAeGVFULkn8O; Tue, 3 May 2016 05:44:40 -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 4D6F112D7E3; Tue, 3 May 2016 05:44:40 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id B7C07E5BF316C; Tue, 3 May 2016 12:44:35 +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 u43CicA8005167 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 3 May 2016 12:44:38 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u43CiZpp011266 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 May 2016 14:44:38 +0200 Received: from FR711WXCHMBA02.zeu.alcatel-lucent.com ([169.254.2.95]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Tue, 3 May 2016 14:44:29 +0200 From: "Murray, Rob (Nokia - GB)" To: EXT Alexey Melnikov Thread-Topic: [CDNi] Alexey Melnikov's Yes on draft-ietf-cdni-control-triggers-13: (with COMMENT) Thread-Index: AQHRoWukaGlhrjnUfkqZp76qronUSZ+fxpmAgADPC4CABontAA== Date: Tue, 3 May 2016 12:44:28 +0000 Message-ID: References: <20160428163251.27832.10001.idtracker@ietfa.amsl.com> <810FA1FE-BAC3-400B-8076-EBD5359DBF1A@alcatel-lucent.com> <1461923619.253905.593217961.1A4E752D@webmail.messagingengine.com> In-Reply-To: <1461923619.253905.593217961.1A4E752D@webmail.messagingengine.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.15.1.160411 x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="utf-8" Content-ID: <795D6C3E9C84954BB3752AD33C0030FD@exchange.lucent.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "flefauch@cisco.com" , "cdni@ietf.org" , The IESG , "draft-ietf-cdni-control-triggers@ietf.org" , "cdni-chairs@ietf.org" Subject: Re: [CDNi] Alexey Melnikov's Yes on draft-ietf-cdni-control-triggers-13: (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: Tue, 03 May 2016 12:44:42 -0000 DQpPbiAyOS8wNC8yMDE2LCAxMDo1MywgIkVYVCBBbGV4ZXkgTWVsbmlrb3YiIDxhYW1lbG5pa292 QGZhc3RtYWlsLmZtPiB3cm90ZToNCg0KW3NuaXBdDQoNCj4+ID5JbiA0LjY6IGEgbm9ybWF0aXZl IHJlZmVyZW5jZSB0aGF0IGRlZmluZXMgQVMgaXMgbmVlZGVkIGhlcmUuDQo+PiANCj4+IFdvdWxk IFJGQyAxOTMwIGJlIHRoZSByaWdodCBjaG9pY2U/DQo+DQo+SSB0aGluayBzby4gQXJlIHlvdSB1 c2luZyAxNmJpdCBvciAzMmJpdCB2ZXJzaW9uPw0KDQpJIGRvbid0IHRoaW5rIGl0IG1hdHRlcnMu IEFTIG51bWJlciB3YXMgY2hvc2VuIGFzIGEgdW5pcXVlIGlkZW50aWZpZXIgZm9yIHRoZSBuZXR3 b3JrLCBpdCdzIG5vdCBiZWluZyB1c2VkIGJ5IENJL1Qgb3IgYW55IG9mIHRoZSBvdGhlciBDRE5J IHByb3RvY29scyBhcyBhbiBBUyBudW1iZXIuDQoNCg0KDQo+PiA+SG93IGlzIEhUVFAgQXV0aGVu dGljYXRpb24gZG9uZT8NCj4+IA0KPj4gU29ycnksIG5vdCBzdXJlIHdoYXQgdGhlIGNvbnRleHQg aXMuIFNlY3Rpb24gOC4xIHNheXM6DQo+PiANCj4+ICAgIFRMUyBNVVNUIGJlIHVzZWQgYnkgdGhl IHNlcnZlci1zaWRlIChkQ0ROKSBhbmQgdGhlIGNsaWVudC1zaWRlICh1Q0ROKQ0KPj4gICAgb2Yg dGhlIENJL1QgaW50ZXJmYWNlLCBpbmNsdWRpbmcgYXV0aGVudGljYXRpb24gb2YgdGhlIHJlbW90 ZSBlbmQNCj4+ICAgIFsuLi5dDQo+PiANCj4+IChCdXQgSSB0aGluayBJJ20gbWlzc2luZyB5b3Vy IHBvaW50PykNCj4NCj5JIHRoaW5rIHRoaXMgc2VjdGlvbiBuZWVkcyBtb3JlIGRldGFpbHMgb24g aG93IGNsaWVudCBhbmQgc2VydmVyDQo+aWRlbnRpdGllcyBhcmUgdmVyaWZpZWQuIEluIHBhcnRp Y3VsYXIgd2hhdCBzaG91bGQgdGhlIGNsaWVudCBzaWRlIGxvb2sNCj5mb3IgaW4gc2VydmVyIGNl cnRpZmljYXRlcz8NCg0KVGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIHRleHQgaGFzIGJlZW4g dGhlIHN1YmplY3Qgb2YgYSBsb3Qgb2Ygd29yZHNtaXRoaW5nIGFuZCByb3VuZHMgb2Ygc2VjdXJp dHkgcmV2aWV3IGluIHNldmVyYWwgQ0ROSSBkcmFmdHMsIENJL1QgaXMgYWxpZ25lZCB3aXRoIHRo b3NlIG90aGVyIGRyYWZ0cyAobG9nZ2luZywgcmVkaXJlY3Rpb24sIG1ldGFkYXRhKS4gSSB0aGlu ayB0aGUgZmVlbGluZyBpcyB0aGF0IENETkkgZHJhZnRzIGFyZSBub3QgdGhlIHBsYWNlIHRvIHRy eSB0byBkZWZpbmUgVExTIGJlc3QgcHJhY3RpY2UsIHdoaWNoIGNoYW5nZXMgb3ZlciB0aW1lIGFu ZCBpcyBkaXNjdXNzZWQgYXV0aG9yaXRhdGl2ZWx5IGVsc2V3aGVyZSBieSBwZW9wbGUgd2hvIGtu b3cgd2hhdCB0aGV5J3JlIHRhbGtpbmcgYWJvdXQgKCEpLg0KDQpTbywgbGlrZSB0aGUgb3RoZXIg Q0ROSSBkcmFmdHMsIGFzIHdlbGwgYXMgdGhlICJpbmNsdWRpbmcgYXV0aGVudGljYXRpb24gb2Yg dGhlIHJlbW90ZSBlbmQiIHBhcmEgYWJvdmUgdGhlIGRyYWZ0IGN1cnJlbnRseSBzYXlzOg0KDQog ICAgV2hlbiBUTFMgaXMgdXNlZCwgdGhlIGdlbmVyYWwgVExTIHVzYWdlIGd1aWRhbmNlIGluIFtS RkM3NTI1XSBNVVNUIGJlDQogICAgZm9sbG93ZWQuDQoNCkRvZXMgdGhhdCBjb3ZlciBpdCBmb3Ig eW91PyBJZiBub3QsIHdoYXQgc3BlY2lmaWNzIGFyZSB5b3UgdGhpbmtpbmcgYWJvdXQ/DQoNCg0K W3NuaXBdDQoNCg0KPj4gPk1lZGlhIHR5cGU6IHNob3VsZCBpdCBoYXZlICtqc29uIHN1ZmZpeD8g SXMgdGhlIGN1cnJlbnRseSBkZWZpbmVkIG1lZGlhDQo+PiA+dHlwZSBkZXBsb3llZD8NCj4+IA0K Pj4gTm90IHN1cmUsIEkgdGhvdWdodCBpdCB3YXMgSlNPTiBieS1kZWZpbml0aW9uLCBidXQgaGFw cHkgdG8gYmUgY29ycmVjdGVkLg0KPj4gSSBkb24ndCB0aGluayBpdCdzIGRlcGxveWVkLg0KPg0K PkkgdGhpbmsgaXQgbWlnaHQgYmUgdXNlZnVsIHRvIHN0aWNrICtqc29uIGF0IHRoZSBlbmQgKGFu ZCB1cGRhdGUgYWxsDQo+ZXhhbXBsZXMgdG8gbWF0Y2gpLg0KDQpPay4NCg0KDQo+PiA+T24gcGFn ZSAzNiAtIHNob3VsZCB0aGUgVVJMIGluY2x1ZGUgInBlbmRpbmciLCBub3QgImNvbXBsZXRlIiAo YXMgcGVyIHRoZQ0KPj4gPmRlc2NyaXB0aW9uIGJlZm9yZSB0aGlzIGFuZCB0aGUgcHJldmlvdXMg cmVxdWVzdC9yZXNwb25zZSkuDQo+PiANCj4+IFRoYXQncyBzZWN0aW9uIDYuMi41LCB0aGUgZXhh bXBsZSB3aGVyZSAiL3RyaWdnZXJzLzAiIGdldHMgZGVsZXRlZD8NCj4+IA0KPj4gSSB0aGluayAi Y29tcGxldGUiIGlzIHJpZ2h0LCBzZWN0aW9uIDYuMi40IGZvbGxvd3MgaXQgdGhyb3VnaA0KPj4g InBlbmRpbmciIHRvICJjb21wbGV0ZSIgKG9uIHBhZ2UgMzUpLg0KPg0KPkF0IHRoZSBib3R0b20g b2YgcGFnZSAzNCB0aGVyZSBpcyB0aGUgZm9sbG93aW5nIHRleHQ6DQo+DQo+V2hlbiB0aGUgQ0kv VCBUcmlnZ2VyIENvbW1hbmQgaXMgY29tcGxldGUsIHRoZSBjb250ZW50cyBvZiB0aGUNCj4gZmls dGVyZWQgY29sbGVjdGlvbnMgd2lsbCBiZSB1cGRhdGVkIGFsb25nIHdpdGggdGhlaXIgRW50aXR5 IFRhZ3MuDQo+IEZvciBleGFtcGxlLCB3aGVuIHRoZSB0d28gZXhhbXBsZSBDSS9UIFRyaWdnZXIg Q29tbWFuZHMgYXJlIGNvbXBsZXRlLA0KPiB0aGUgY29sbGVjdGlvbnMgb2YgcGVuZGluZyBhbmQg Y29tcGxldGUgVHJpZ2dlciBTdGF0dXMgUmVzb3VyY2VzDQo+IG1pZ2h0IGxvb2sgbGlrZToNCj4N Cj5hZnRlciB0aGF0IHRoZXJlIGFyZSAyIGV4YW1wbGVzIG9uIHBhZ2VzIDM1IGFuZCAzNiwgYm90 aCB3aXRoIFVSSQ0KPiIvdHJpZ2dlcnMvY29tcGxldGUiLiBJIHRoaW5rIG9uZSBvZiB0aGUgc2hv dWxkIGJlICIgL3RyaWdnZXJzL3BlbmRpbmcsDQo+SSB0aGluayBpdCBpcyB0aGUgb25lIG9uIHBh Z2UgMzUuDQoNCkFoLCB5ZXMgSSBzZWUsIHRoYW5rIHlvdSAtIGxvb2tzIGxpa2UgSSd2ZSBwYXN0 ZWQgaW4gdGhlIHdyb25nIGV4YW1wbGUuIEknbGwgZmluZCB0aGUgcmlnaHQgb25lIHdoaWxlIEkn bSAiK2pzb24iLWluZyB0aGVtLg0KDQoNCj4NCj5CZXN0IFJlZ2FyZHMsDQo+QWxleGV5DQo= From nobody Sat May 14 12:01:51 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 DC1E912D1D7; Sat, 14 May 2016 12:01:47 -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.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160514190147.2444.25479.idtracker@ietfa.amsl.com> Date: Sat, 14 May 2016 12:01:47 -0700 Archived-At: Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-footprint-capabilities-semantics-19.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: Sat, 14 May 2016 19:01:48 -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-19.txt Pages : 27 Date : 2016-05-14 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-19 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-footprint-capabilities-semantics-19 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 Sat May 14 12:04:43 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 55ACD12D1C0 for ; Sat, 14 May 2016 12:04:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[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 LviD1rvcbCjO for ; Sat, 14 May 2016 12:04:39 -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 1C5A312D138 for ; Sat, 14 May 2016 12:04:39 -0700 (PDT) X-AuditID: c618062d-f79886d000002334-62-57376eb7eaf3 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 93.D8.09012.7BE67375; Sat, 14 May 2016 20:30:15 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0248.002; Sat, 14 May 2016 15:04:37 -0400 From: Kevin Ma J To: "cdni@ietf.org" Thread-Topic: [CDNi] I-D Action: draft-ietf-cdni-footprint-capabilities-semantics-19.txt Thread-Index: AQHRrhMpa9ME0rAbaE+nsu/reUwNVp+4ypDQ Date: Sat, 14 May 2016 19:04:36 +0000 Message-ID: References: <20160514190147.2444.25479.idtracker@ietfa.amsl.com> In-Reply-To: <20160514190147.2444.25479.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.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCLMWRmVeSWpSXmKPExsUyuXSPn+72PPNwg2cPxC2ezv7D6sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujC3PvrAXvBat+LjnMFsD41OBLkZODgkBE4nd668zQthiEhfu rWfrYuTiEBI4yijx9Uc3I4SznFHifvsPJpAqNgEticdf/wLZHBwiAsoSPw85goSFBSIlVmx7 DTZIRCBK4mffDijbSOLltY3sIDaLgKrEg5PbWUBsXgFfifcnj7KC2EICDhKzdu9nBxnJKeAo sfeaAkiYEeie76fWgG1lFhCXuPVkPhPEnQISS/acZ4awRSVePv7HCmErSXz8PZ8dol5HYsHu T2wQtrbEsoWvmSHWCkqcnPmEZQKj6CwkY2chaZmFpGUWkpYFjCyrGDlKiwtyctONDDYxAsP+ mASb7g7G+9M9DzEKcDAq8fA+2GcWLsSaWFZcmXuIUYKDWUmEtzjfPFyINyWxsiq1KD++qDQn tfgQozQHi5I4r9gjxXAhgfTEktTs1NSC1CKYLBMHp1QD4wLRy346UvN+aU26ojYhe8pdkZPi kZ/2qUy90MAenPolPEDp2K4Z+gnZ5m+ntxzckXDKNyLeeNOln1tlY/f1lB5xlo46+GTq/ZWH NcL4Jh33fzVxwauLRjy7X9xXjDhRzcl6aP6CWzoNN/eEsaT8f5o7S553gxZbUE+HzIIv6SwL n9eZ/336/4oSS3FGoqEWc1FxIgCGtWh+dwIAAA== Archived-At: Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-footprint-capabilities-semantics-19.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: Sat, 14 May 2016 19:04:41 -0000 Hi All, Thanks to Ben for doing a final review of the Semantics draft. This upda= te has 3 changes: 1. Change "cache" to "surrogate" for consistency with other documents 2. Add clarification on what "mandatory-to-specify" means 3. Clarify text on how empty Logging/Metadata lists should be interpreted thanx! -- Kevin J. Ma > -----Original Message----- > From: CDNi [mailto:cdni-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Saturday, May 14, 2016 3:02 PM > To: i-d-announce@ietf.org > Cc: cdni@ietf.org > Subject: [CDNi] I-D Action: draft-ietf-cdni-footprint-capabilities- > semantics-19.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- > 19.txt > Pages : 27 > Date : 2016-05-14 >=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-19 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-footprint-capabilitie= s- > semantics-19 >=20 >=20 > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From nobody Mon May 16 08:59: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 69E5C12D70E; Mon, 16 May 2016 08:59:01 -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.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160516155901.16797.25095.idtracker@ietfa.amsl.com> Date: Mon, 16 May 2016 08:59:01 -0700 Archived-At: Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-control-triggers-14.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, 16 May 2016 15:59:01 -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-14.txt Pages : 46 Date : 2016-05-16 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-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-control-triggers-14 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 May 16 09:02: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 58E4712D6F3 for ; Mon, 16 May 2016 09:02:24 -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 QgreSVL2ABfk for ; Mon, 16 May 2016 09:02:21 -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 E109912D12E for ; Mon, 16 May 2016 09:02:09 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 93B45BCF917E7; Mon, 16 May 2016 16:01: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 u4GG1WbI005581 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 16 May 2016 16:01: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 u4GG1WTk025531 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 16 May 2016 18:01:32 +0200 Received: from FR711WXCHMBA02.zeu.alcatel-lucent.com ([169.254.2.23]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Mon, 16 May 2016 18:01:32 +0200 From: "Murray, Rob (Nokia - GB)" To: "cdni@ietf.org" , EXT Alexey Melnikov Thread-Topic: Triggers "-14" Thread-Index: AQHRr4w2V/rMtLbxfEKEzVqgbiRuiw== Date: Mon, 16 May 2016 16:01:32 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.16.0.160506 x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="utf-8" Content-ID: <04EBF280F671884F90F2B7DA9B5EB514@exchange.lucent.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [CDNi] Triggers "-14" 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, 16 May 2016 16:02:24 -0000 SGkgYWxsLA0KDQpJJ3ZlIHVwbG9hZGVkIGEgIi0xNCIgb2YgdGhlIHRyaWdnZXJzIGRyYWZ0IGFk ZHJlc3Npbmcgc29tZSBvZiBBbGV4ZXkncyBjb21tZW50cy4NCg0KDQogIFVSTDogICAgICBodHRw czovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1jZG5pLWNvbnRyb2wt dHJpZ2dlcnMtMTQudHh0DQogIFN0YXR1czogICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1pZXRmLWNkbmktY29udHJvbC10cmlnZ2Vycy8NCiAgSHRtbGl6ZWQ6IGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWNkbmktY29udHJvbC10cmlnZ2Vycy0x NA0KICBEaWZmOiAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWll dGYtY2RuaS1jb250cm9sLXRyaWdnZXJzLTE0DQoNCg0KVGhlIG1haW4gY2hhbmdlcyBhcmU6DQoN CiAgLSBBZGRlZCByZWdpc3RyaWVzIGZvciBlcnJvciBjb2RlcyBhbmQgdHJpZ2dlciB0eXBlcw0K DQogICAgU3BlY2lmaWVkIHdoYXQgYSBkQ0ROIHNob3VsZCBkbyBpZiBpdCBnZXRzIGEgcmVxdWVz dCBmb3IgYQ0KICAgIHRyaWdnZXIgaXQgZG9lc24ndCByZWNvZ25pemUsIG5ldyBlcnJvciBjb2Rl ICJldW5zdXBwb3J0ZWQiLg0KDQogICAgVGhlbiBpdCBtYWRlIHNlbnNlIHRvIHJlbW92ZSB0aGUg TVVTVCBpbXBsZW1lbnQgdGhlIHRyaWdnZXINCiAgICB0eXBlcyBzcGVjaWZpZWQgaW4gdGhlIGRy YWZ0IChpbnZhbGlkYXRlL3B1cmdlL3ByZXBvc2l0aW9uKS4NCg0KICAgIFN1cHBvcnQgZm9yIGEg Z2l2ZW4gdHJpZ2dlciB0eXBlIHdpbGwgYmUgc29tZXRoaW5nIGZvciBhDQogICAgZENETiB0byBh ZHZlcnRpc2UgdmlhIHRoZSBGQ0kgaW50ZXJmYWNlIHdoZW4gdGhhdCdzIHJlYWR5Lg0KDQogICAg VGhhdCBtZWFucyBhIENETiB0aGF0IGRvZXNuJ3Qgd2FudCB0byBpbXBsZW1lbnQgInByZXBvc2l0 aW9uIg0KICAgIChmb3IgZXhhbXBsZSkgY2FuIG5vdyBzdGlsbCBiZSBjb21wbGlhbnQgd2l0aCB0 aGUgaW50ZXJmYWNlLA0KICAgIHdoaWNoIHNlZW1zIGxpa2UgYSBnb29kLXRoaW5nLg0KDQogICAg RXJyb3IgY29kZXMgYXJlIHNpbXBsZSwgYW5kIHRoZXJlIGZvciBpbmZvIGZvciB0aGUgdUNETiBt YWtpbmcNCiAgICBhIHJlcXVlc3QsIHNvIEkgcGx1bXBlZCBmb3IgIlNwZWNpZmljYXRpb24gUmVx dWlyZWQiIGZvciB0aGF0DQogICAgcmVnaXN0cnkuIEJ1dCBhZGRpbmcgYSB0cmlnZ2VyIHR5cGUg c2VlbXMgYSBsb3QgbW9yZSBpbnZvbHZlZA0KICAgIGFuZCBsaWtlbHkgdG8gbmVlZCB3aWRlciBy ZXZpZXcsIHNvIEkndmUgc2FpZCB0aGF0IHNob3VsZCBiZQ0KICAgICJSRkMgUmVxdWlyZWQiLg0K CQ0KICAtIE5vdyB0aGUgbWVkaWEgdHlwZSBmb3IgYWxsIHRoZSBKU09OIG1lc3NhZ2VzIGRlZmlu ZWQgYnkgdGhpcw0KICAgIFJGQyBNVVNUIGhhdmUgYSAiK2pzb24iLiBFeGFtcGxlcyB1cGRhdGVk IHRvIG1hdGNoLg0KDQogIC0gTWFkZSBpdCBjbGVhciB0aGF0IHRoZSBVUkxzIGFyZSBodHRwL2h0 dHBzIFVSTHMuDQoNCiAgLSBBZGRlZCBub3JtYXRpdmUgcmVmcyBSRkMtMTkzMCAoZm9yIEFTIG51 bWJlcnMpLCBSRkMtNTIyNiAoSUFOQSkuDQoNCkFueSBvYmplY3Rpb25zL2NvbW1lbnRzLCBwbGVh c2UgbGV0IG1lIGtub3cuDQoNCihBbGV4ZXkgLSBJIGRvbid0IHRoaW5rIHdlJ3ZlIGNvbmNsdWRl ZCBvbiBhbGwgeW91ciBBRCByZXZpZXcgY29tbWVudHMsIGJ1dA0KSSB0aG91Z2h0IGl0J2QgYmUg d29ydGggdG8gcHVzaGluZyBvdXQgYW4gdXBkYXRlIGFueXdheSB0byBrZWVwIHRoZSBiYWxsDQpy b2xsaW5nLiBMZXQgbWUga25vdyBpZiBhbnkgZnVydGhlciBjaGFuZ2Ugb3IgZGlzY3Vzc2lvbiBp cyBuZWVkZWQuIFRoZSBsYXN0DQplbWFpbCB3YXMgaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9y Zy9hcmNoL21zZy9jZG5pL1VuVF9DbERqaHU5anJCZnctVzZqS29Nc2JYSSApDQoNCkNoZWVycywN ClJvYi4NCg0KDQo= From nobody Tue May 17 06:54: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 CFC1D12D5F6; Tue, 17 May 2016 06:53:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mirja Kuehlewind" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160517135357.22221.45082.idtracker@ietfa.amsl.com> Date: Tue, 17 May 2016 06:53:57 -0700 Archived-At: Cc: draft-ietf-cdni-logging@ietf.org, cdni@ietf.org, cdni-chairs@ietf.org Subject: [CDNi] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-cdni-logging-25=3A_=28with_COMMENT=29?= 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, 17 May 2016 13:53:59 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-cdni-logging-25: 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: ---------------------------------------------------------------------- I still agree to the privacy concerns that have been raised earlier by Richard Barnes but don't see a solution that would justify a "DISCUSS" to hold up the document. Further I think it's important that TLS is mandatory and it could be useful to already state this earlier in the doc and not only Section 7. From nobody Wed May 18 06:40: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 5E2D412B062; Wed, 18 May 2016 06:40:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alexey Melnikov" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160518134030.14641.52615.idtracker@ietfa.amsl.com> Date: Wed, 18 May 2016 06:40:30 -0700 Archived-At: Cc: draft-ietf-cdni-logging@ietf.org, cdni@ietf.org, cdni-chairs@ietf.org Subject: [CDNi] Alexey Melnikov's Discuss on draft-ietf-cdni-logging-25: (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: Wed, 18 May 2016 13:40:30 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-cdni-logging-25: 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 know this document has long history and I want to get it done as well. Below is a list of small issues that I think need to be addressed: Is version directive value case-insensitive? The IANA registration is in lowercase, but all examples show uppercase. On page 28: SHA-3, AES-GCM and base64 all need normative references. (Use "Section 4 of [RFC4648]" for base64, as RFC 4648 defines 2 base54 encodings). On page 33: where does the "missing field value is denoted by -" specified in ABNF? If this is not defined in ABNF, it would be good to have an example record with a field missing. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- In 7.1, last sentence: TLS only provides for protection from tampering when in transit, not when a log file being stored. From nobody Wed May 18 08:55: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 BFBFF12D1AE; Wed, 18 May 2016 08:55:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alexey Melnikov" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160518155522.14636.83186.idtracker@ietfa.amsl.com> Date: Wed, 18 May 2016 08:55:22 -0700 Archived-At: Cc: flefauch@cisco.com, cdni@ietf.org, draft-ietf-cdni-control-triggers@ietf.org, cdni-chairs@ietf.org Subject: [CDNi] Alexey Melnikov's Yes on draft-ietf-cdni-control-triggers-14: (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, 18 May 2016 15:55:23 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-cdni-control-triggers-14: 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-control-triggers/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for addressing my earlier comments. Regarding my earlier change: Media type: should it have +json suffix? Is the currently defined media type deployed? -- I didn't realize that application/cdni is already registered with IANA by RFC 7736. So this comment doesn't apply and should revert this change. I am sorry about that! From nobody Wed May 18 15:33: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 A74F012D1E0; Wed, 18 May 2016 15:32:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160518223257.14733.37895.idtracker@ietfa.amsl.com> Date: Wed, 18 May 2016 15:32:57 -0700 Archived-At: Cc: draft-ietf-cdni-logging@ietf.org, cdni@ietf.org, cdni-chairs@ietf.org Subject: [CDNi] Ben Campbell's Discuss on draft-ietf-cdni-logging-25: (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: Wed, 18 May 2016 22:32:58 -0000 Ben Campbell has entered the following ballot position for draft-ietf-cdni-logging-25: 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: ---------------------------------------------------------------------- While the security and privacy bits are much improved from earlier versions, I think I have found some holes. I assume these are not intentional, and it's entirely possible I have misread some things. But I would like to make sure they are considered prior to progressing. - 3.4.1, c-groupid: The privacy-related guidance about c-groupids indentifying individual clients (in the several bullet list entries with "-" bullets) seems contingent on the MAY in the parent (with the "+" bullet.) The parent says that you MAY structure the field so that parts identify the aggregate and one part aggregates the individual, with the sub-bullets following an "In this case..." clause. I assume the guidance is intended to apply even when an implementation doesn't structure c-groupid that way (or at all.) - 7.1: This section seems to effectively say that various protections are required when they are required. But it doesn't give advice on when they may be required. (For example, when c-groupid can be mapped to individual client addresses.) - 7.3: "Making detailed CDNI logging information known to the uCDN does not represent a particular privacy concern because the uCDN is already exposed at request redirection time to most of the information that shows up as CDNI logging information (e.g., enduser IP@, URL, HTTP headers - at least when HTTP redirection is used between uCDN and dCDN)." I agree this is mostly true for HTTP redirection. But as you mention, the assertion seems to fall down for DNS redirection, where the uCDN may have considerably less information. I think some different guidance for that case may be needed. -- "Transporting detailed CDNI logging information over the HTTP based CDNI Logging Interface does not represent a particular privacy concern because it is protected by usual IETF privacy-protection mechanism (e.g.,TLS)." I don't find normative text that says privacy-sensitive information MUST be protected. Just that information that needs to be protected MUST be protected. The reader is left to infer that privacy-sensitive information is covered by that. (See previous comment about 7.1). Without something explicit there, I think it highly likely that some people will rationalize that their deployments don't need protection for one reason or another. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - 3.3, 2nd to last paragraph: What does it mean to reject a logging file? Does it mean to simply ignore it, or does it imply some notice back the source of the file that there's a problem? (I tend to think of "reject" as implying the latter in a protocol, in contrast to words like "drop" or "ignore".) - 3.4.1, 3rd "-" bullet: "The algorithmic mapping and variation over time MAY allow the uCDN ... to reconstruct the actual client IPv4 or IPv6 address" Is that intended to be a 2119 MAY or a statement of fact? If the former, it seems to directly contradict the NOT RECOMMENDED in the next "-" bullet.. From nobody Wed May 18 16:38: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 DE23D12D7CD; Wed, 18 May 2016 16:38:08 -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 UAZAQxQvxDqV; Wed, 18 May 2016 16:38:07 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.144]) by ietfa.amsl.com (Postfix) with ESMTP id F10D412D7C9; Wed, 18 May 2016 16:38:06 -0700 (PDT) Received: from 97e41b89.skybroadband.com ([151.228.27.137] helo=[192.168.0.6]) by smtp04.mailcore.me with esmtpa (Exim 4.80.1) (envelope-from ) id 1b3B2T-0009aI-Ju; Thu, 19 May 2016 00:38:05 +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: <20160518223257.14733.37895.idtracker@ietfa.amsl.com> Date: Thu, 19 May 2016 00:38:04 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3E2786B2-9204-447C-9A53-A3CB0213E0F5@niven-jenkins.co.uk> References: <20160518223257.14733.37895.idtracker@ietfa.amsl.com> To: Ben Campbell 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@ietf.org, cdni-chairs@ietf.org Subject: Re: [CDNi] Ben Campbell's Discuss on draft-ietf-cdni-logging-25: (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, 18 May 2016 23:38:09 -0000 Hi Ben, I=E2=80=99ll let the authors respond to most of your comments but I = wanted to respond to one of them, see below. > On 18 May 2016, at 23:32, Ben Campbell wrote: > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > - 7.3: "Making detailed CDNI logging > information known to the uCDN does not represent a particular = privacy > concern because the uCDN is already exposed at request redirection > time to most of the information that shows up as CDNI logging > information (e.g., enduser IP@, URL, HTTP headers - at least when > HTTP redirection is used between uCDN and dCDN)." >=20 > I agree this is mostly true for HTTP redirection. But as you mention, = the > assertion seems to fall down for DNS redirection, where the uCDN may = have > considerably less information. I think some different guidance for = that > case may be needed. True, but=E2=80=A6making detailed CDNI logging information known to the = uCDN does not expose any more information to the uCDN than if the uCDN = had chosen to perform the content delivery itself. Typically when entity A contracts out work to entity B, entity A is = entitled to see all records produced by entity B on entity A=E2=80=99s = behalf. Ben From nobody Wed May 18 16:46:24 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 1364112D541; Wed, 18 May 2016 16:46:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.727 X-Spam-Level: X-Spam-Status: No, score=-5.727 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=-1.426, SPF_PASS=-0.001] 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 B-s8xI96ypRe; Wed, 18 May 2016 16:46:20 -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 6D82812D53C; Wed, 18 May 2016 16:46:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 1EC76BE2D; Thu, 19 May 2016 00:46:19 +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 nxUpGAgSkUzI; Thu, 19 May 2016 00:46:17 +0100 (IST) Received: from [10.87.48.75] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 4CE01BDF9; Thu, 19 May 2016 00:46:17 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1463615177; bh=ZlJ8RkdDWFgyU1k79yMKOltKGJ1LFAqOds6+cjjr+3c=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=0AACPGPI5yU2GfyUMIGl6lkkCEshqOCiUFLLgwQNLLD580Aovdi68t1z6fTBlk4fu SfBaSe8i+n8VV5TqH3D2QTTlcCeYiI5YvFRsmGHkdT0RTyf6VaDhZdsqpwwVA+2tf0 VLJe3RV4lIs1zs8dyF9XlMhb4d0P8+lCidR2cttE= To: Ben Niven-Jenkins , Ben Campbell References: <20160518223257.14733.37895.idtracker@ietfa.amsl.com> <3E2786B2-9204-447C-9A53-A3CB0213E0F5@niven-jenkins.co.uk> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <573CFEC8.8010600@cs.tcd.ie> Date: Thu, 19 May 2016 00:46:16 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <3E2786B2-9204-447C-9A53-A3CB0213E0F5@niven-jenkins.co.uk> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030800060400000506060204" Archived-At: Cc: draft-ietf-cdni-logging@ietf.org, The IESG , cdni@ietf.org, cdni-chairs@ietf.org Subject: Re: [CDNi] Ben Campbell's Discuss on draft-ietf-cdni-logging-25: (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, 18 May 2016 23:46:22 -0000 This is a cryptographically signed message in MIME format. --------------ms030800060400000506060204 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 19/05/16 00:38, Ben Niven-Jenkins wrote: > Hi Ben, >=20 > I=E2=80=99ll let the authors respond to most of your comments but I wan= ted to > respond to one of them, see below. >=20 >> On 18 May 2016, at 23:32, Ben Campbell wrote:=20 >> ----------------------------------------------------------------------= >> >>=20 DISCUSS: >> ----------------------------------------------------------------------= >> >>=20 - 7.3: "Making detailed CDNI logging >> information known to the uCDN does not represent a particular >> privacy concern because the uCDN is already exposed at request >> redirection time to most of the information that shows up as CDNI >> logging information (e.g., enduser IP@, URL, HTTP headers - at >> least when HTTP redirection is used between uCDN and dCDN)." >>=20 >> I agree this is mostly true for HTTP redirection. But as you >> mention, the assertion seems to fall down for DNS redirection, >> where the uCDN may have considerably less information. I think some >> different guidance for that case may be needed. >=20 > True, but=E2=80=A6making detailed CDNI logging information known to the= uCDN > does not expose any more information to the uCDN than if the uCDN had > chosen to perform the content delivery itself. >=20 > Typically when entity A contracts out work to entity B, entity A is > entitled to see all records produced by entity B on entity A=E2=80=99s > behalf. I don't accept that that applies to all of the information that could be at issue here. For example if A is in the US and B is in the EU then things are not that simple. S. >=20 > Ben >=20 --------------ms030800060400000506060204 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 oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA1MTgy MzQ2MTZaMC8GCSqGSIb3DQEJBDEiBCDWG4rac732Hl/OFg3T53WKNPdSl0377zc1VoRbdle2 dTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQChydKG+sV1G/HQN953hNOKFKLvSVjDvaHOYiAE00LN77oP8Hcd9q63 QrodqD79p7AiWTeB19r4io4g/6bIjIoqQ0mOzoCSxlXVEH/sYEYHa1lhJIiQTQr2yj5zOEQT a44u766knbWlElcskW/I7RFVc1lQfRofoc+fYS4CuVRjXh7gIOMheziqZcmwqmogZ37oWfG7 k2EsIgyi18IeJstAwZdOGXUbiK8x7EMw8EeuDHlhNTPpL09S0fjRuOnmBn6064xgE9R8zYHY OaTEk2uuBpiSW3ytEhVq9Egu/alzx+2BrIUOdcHLmwSJ6ynui6WRoxGPnuROnu6GBoqD45Iz AAAAAAAA --------------ms030800060400000506060204-- From nobody Wed May 18 17:25: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 8C48512D17B; Wed, 18 May 2016 17:25:03 -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, HTML_MESSAGE=0.001, 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 A10m9YZV_npQ; Wed, 18 May 2016 17:25:02 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.144]) by ietfa.amsl.com (Postfix) with ESMTP id 4416D12D709; Wed, 18 May 2016 17:25:00 -0700 (PDT) Received: from 97e41b89.skybroadband.com ([151.228.27.137] helo=[192.168.0.6]) by smtp04.mailcore.me with esmtpa (Exim 4.80.1) (envelope-from ) id 1b3Blr-00099Q-Rr; Thu, 19 May 2016 01:25:00 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_5036B470-4977-4C85-94A2-74E6C535DA66" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Ben Niven-Jenkins In-Reply-To: <573CFEC8.8010600@cs.tcd.ie> Date: Thu, 19 May 2016 01:24:58 +0100 Message-Id: <5DED924E-C407-44E9-8FF1-477B26B69647@niven-jenkins.co.uk> References: <20160518223257.14733.37895.idtracker@ietfa.amsl.com> <3E2786B2-9204-447C-9A53-A3CB0213E0F5@niven-jenkins.co.uk> <573CFEC8.8010600@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.2098) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Archived-At: Cc: Ben Campbell , draft-ietf-cdni-logging@ietf.org, The IESG , cdni@ietf.org, cdni-chairs@ietf.org Subject: Re: [CDNi] Ben Campbell's Discuss on draft-ietf-cdni-logging-25: (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, 19 May 2016 00:25:04 -0000 --Apple-Mail=_5036B470-4977-4C85-94A2-74E6C535DA66 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 19 May 2016, at 00:46, Stephen Farrell = wrote: > On 19/05/16 00:38, Ben Niven-Jenkins wrote: >> Hi Ben, >>=20 >> I=E2=80=99ll let the authors respond to most of your comments but I = wanted to >> respond to one of them, see below. >>=20 >>> On 18 May 2016, at 23:32, Ben Campbell wrote:=20 >>> = ---------------------------------------------------------------------- >>>=20 >>>=20 > DISCUSS: >>> = ---------------------------------------------------------------------- >>>=20 >>>=20 > - 7.3: "Making detailed CDNI logging >>> information known to the uCDN does not represent a particular >>> privacy concern because the uCDN is already exposed at request >>> redirection time to most of the information that shows up as CDNI >>> logging information (e.g., enduser IP@, URL, HTTP headers - at >>> least when HTTP redirection is used between uCDN and dCDN)." >>>=20 >>> I agree this is mostly true for HTTP redirection. But as you >>> mention, the assertion seems to fall down for DNS redirection, >>> where the uCDN may have considerably less information. I think some >>> different guidance for that case may be needed. >>=20 >> True, but=E2=80=A6making detailed CDNI logging information known to = the uCDN >> does not expose any more information to the uCDN than if the uCDN had >> chosen to perform the content delivery itself. >>=20 >> Typically when entity A contracts out work to entity B, entity A is >> entitled to see all records produced by entity B on entity A=E2=80=99s >> behalf. >=20 > I don't accept that that applies to all of the information that > could be at issue here. For example if A is in the US and B is in > the EU then things are not that simple. You are correct that there are laws that may prevent the export of = personal data from one country to another. AFAIK no IETF protocol that = exchanges personal data or privacy impacting data has additional = technical mechanisms to account for such laws (and I can not recall = reading text in a technical specification RFC that discussed the impacts = of such laws on the protocol being specified) so I don=E2=80=99t see how = the presence of such laws is relevant to the technical specification of = the CDNI logging interface. Ben= --Apple-Mail=_5036B470-4977-4C85-94A2-74E6C535DA66 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 19 May 2016, at 00:46, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
On 19/05/16 00:38, Ben = Niven-Jenkins wrote:
Hi Ben,

I=E2=80=99ll let the authors respond to most of your comments = but I wanted to
respond to one of them, see below.

On 18 May = 2016, at 23:32, Ben Campbell <ben@nostrum.com> wrote: 
---------------------------------------------------------------= -------


DISCUSS:
---------------------------------------------------------------= -------


- 7.3: "Making detailed CDNI logging
information known to the uCDN does not represent a = particular
privacy concern because the uCDN is already = exposed at request
redirection time to most of the = information that shows up as CDNI
logging information = (e.g., enduser IP@, URL, HTTP headers - at
least when HTTP = redirection is used between uCDN and dCDN)."

I agree this is mostly true for HTTP redirection. But as = you
mention, the assertion seems to fall down for DNS = redirection,
where the uCDN may have considerably less = information. I think some
different guidance for that case = may be needed.

True, = but=E2=80=A6making detailed CDNI logging information known to the = uCDN
does not expose any more information to the uCDN than = if the uCDN had
chosen to perform the content delivery = itself.

Typically when entity A contracts = out work to entity B, entity A is
entitled to see all = records produced by entity B on entity A=E2=80=99s
behalf.

I don't accept that that applies to all of the = information that
could be at issue here. = For example if A is in the US and B is in
the EU then things are not that = simple.

You = are correct that there are laws that may prevent the export of personal = data from one country to another. AFAIK no IETF protocol that exchanges = personal data or privacy impacting data has additional technical = mechanisms to account for such laws (and I can not recall reading text = in a technical specification RFC that discussed the impacts of such laws = on the protocol being specified) so I don=E2=80=99t see how the presence = of such laws is relevant to the technical specification of the CDNI = logging interface.

Ben
= --Apple-Mail=_5036B470-4977-4C85-94A2-74E6C535DA66-- From nobody Wed May 18 17:33:37 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 0D3B012D0E6; Wed, 18 May 2016 17:33:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.727 X-Spam-Level: X-Spam-Status: No, score=-5.727 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=-1.426, SPF_PASS=-0.001] 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 kM1hLb0GunII; Wed, 18 May 2016 17:33:29 -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 6216F12B068; Wed, 18 May 2016 17:33:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0FDBDBE2C; Thu, 19 May 2016 01:33:28 +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 0DfhpuhWULCS; Thu, 19 May 2016 01:33:26 +0100 (IST) Received: from [10.87.48.75] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id F036DBDF9; Thu, 19 May 2016 01:33:25 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1463618006; bh=nkAzMo2Bo1t/0uhCiaGLoheYHLJ2Z663XdMzmkG0KoY=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=C62+Y/C2INMkCILlLGPO2IORgTzBafl+JKOfP73iJyY50rEcUW3dNGaC8QvrdRk8D cV+/9IzPP5Jx/hTi4+B23iWWV6WxWp6My4N2gt/B+OoVXa9kCxo7tGCUezo63UCHPz B4qEPW0EzJwvMhvb7/ojEYInLEXjWKNPL/Tz4HzI= To: Ben Niven-Jenkins References: <20160518223257.14733.37895.idtracker@ietfa.amsl.com> <3E2786B2-9204-447C-9A53-A3CB0213E0F5@niven-jenkins.co.uk> <573CFEC8.8010600@cs.tcd.ie> <5DED924E-C407-44E9-8FF1-477B26B69647@niven-jenkins.co.uk> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <573D09D5.1020501@cs.tcd.ie> Date: Thu, 19 May 2016 01:33:25 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <5DED924E-C407-44E9-8FF1-477B26B69647@niven-jenkins.co.uk> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040406030908070309020606" Archived-At: Cc: Ben Campbell , draft-ietf-cdni-logging@ietf.org, The IESG , cdni@ietf.org, cdni-chairs@ietf.org Subject: Re: [CDNi] Ben Campbell's Discuss on draft-ietf-cdni-logging-25: (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, 19 May 2016 00:33:31 -0000 This is a cryptographically signed message in MIME format. --------------ms040406030908070309020606 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 19/05/16 01:24, Ben Niven-Jenkins wrote: >=20 >> On 19 May 2016, at 00:46, Stephen Farrell >> wrote: On 19/05/16 00:38, Ben >> Niven-Jenkins wrote: >>> Hi Ben, >>>=20 >>> I=E2=80=99ll let the authors respond to most of your comments but I >>> wanted to respond to one of them, see below. >>>=20 >>>> On 18 May 2016, at 23:32, Ben Campbell wrote: >>>> =20 >>>> --------------------------------------------------------------------= -- >>>> >>>> >> >>>>=20 DISCUSS: >>>> --------------------------------------------------------------------= -- >>>> >>>> >> >>>>=20 - 7.3: "Making detailed CDNI logging >>>> information known to the uCDN does not represent a particular=20 >>>> privacy concern because the uCDN is already exposed at request=20 >>>> redirection time to most of the information that shows up as >>>> CDNI logging information (e.g., enduser IP@, URL, HTTP headers >>>> - at least when HTTP redirection is used between uCDN and >>>> dCDN)." >>>>=20 >>>> I agree this is mostly true for HTTP redirection. But as you=20 >>>> mention, the assertion seems to fall down for DNS redirection,=20 >>>> where the uCDN may have considerably less information. I think >>>> some different guidance for that case may be needed. >>>=20 >>> True, but=E2=80=A6making detailed CDNI logging information known to t= he >>> uCDN does not expose any more information to the uCDN than if the >>> uCDN had chosen to perform the content delivery itself. >>>=20 >>> Typically when entity A contracts out work to entity B, entity A >>> is entitled to see all records produced by entity B on entity >>> A=E2=80=99s behalf. >>=20 >> I don't accept that that applies to all of the information that=20 >> could be at issue here. For example if A is in the US and B is in=20 >> the EU then things are not that simple. >=20 > You are correct that there are laws that may prevent the export of > personal data from one country to another. AFAIK no IETF protocol > that exchanges personal data or privacy impacting data has additional > technical mechanisms to account for such laws (and I can not recall > reading text in a technical specification RFC that discussed the > impacts of such laws on the protocol being specified) so I don=E2=80=99= t see > how the presence of such laws is relevant to the technical > specification of the CDNI logging interface. The relevance is that it shows that your argument wasn't correct as stated. There are other arguments, that are perhaps not yet well accepted by those considering CDNI, for example that receiving all of that logging data unaggregated is more toxic than valuable, but I think we had that discussion before and concluded that the best and correct thing for us to do now with CDNI is to ensure that some privacy friendly mode of operation exists and is usable. Ben's discuss seems to me to be checking whether we've done that as well as we thought, and that's a good thing. If instead you want to re-litigate that basic argument then we can do that but I expect that'd be unproductive for us all and would land us back where we are now anyway. S. >=20 > Ben >=20 --------------ms040406030908070309020606 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 oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA1MTkw MDMzMjVaMC8GCSqGSIb3DQEJBDEiBCDMh1P20ZOVk8gr3pfWn3s5i+2ugfsO783LMMI/e23W 0zBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQBn4auKBXmEvbMZwE8tSVgTKYn9wurT7zLcY74qd/+2y6IygOrR8ERH 98UOBvATA8kHuBM58E8maGDrZavjb8bgbeEkLYYa5LajAoR2U2FAHWmGI9hvNRTCWXQGthHL zGpb2jVj/37TAZrooOuq4hQOlGBuxdFIFO0xsOS0cfiIuj5U0y8xyk6HsKo0B0K58hkl3MGw E7ufOiOqy7dXXSvM+Qn5/FJw+5NfolCKtD1pfsYEBGkBUeM5xsZd3Wo6RtNdq+8T18qljYWE hIYC0CJseZfYqs4TBZZlpZrIds1tMXCg8drNHgAaU+/at8Wa/rn0c3/Qe7imojk43aLh55cA AAAAAAAA --------------ms040406030908070309020606-- From nobody Wed May 18 17:51: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 CE9B712D105; Wed, 18 May 2016 17:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 LPUHvMRZF0NN; Wed, 18 May 2016 17:51:38 -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 8E1EE12B068; Wed, 18 May 2016 17:51:38 -0700 (PDT) Received: from [10.0.1.18] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u4J0pZ8o010041 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 18 May 2016 19:51:36 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.18] From: "Ben Campbell" To: "Ben Niven-Jenkins" Date: Wed, 18 May 2016 19:51:38 -0500 Message-ID: <55925599-3D57-4DFD-BB6E-8142EC6A2199@nostrum.com> In-Reply-To: <3E2786B2-9204-447C-9A53-A3CB0213E0F5@niven-jenkins.co.uk> References: <20160518223257.14733.37895.idtracker@ietfa.amsl.com> <3E2786B2-9204-447C-9A53-A3CB0213E0F5@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: draft-ietf-cdni-logging@ietf.org, The IESG , cdni@ietf.org, cdni-chairs@ietf.org Subject: Re: [CDNi] Ben Campbell's Discuss on draft-ietf-cdni-logging-25: (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, 19 May 2016 00:51:40 -0000 On 18 May 2016, at 18:38, Ben Niven-Jenkins wrote: > Hi Ben, > > I’ll let the authors respond to most of your comments but I wanted > to respond to one of them, see below. > >> On 18 May 2016, at 23:32, Ben Campbell wrote: >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> - 7.3: "Making detailed CDNI logging >> information known to the uCDN does not represent a particular >> privacy >> concern because the uCDN is already exposed at request redirection >> time to most of the information that shows up as CDNI logging >> information (e.g., enduser IP@, URL, HTTP headers - at least when >> HTTP redirection is used between uCDN and dCDN)." >> >> I agree this is mostly true for HTTP redirection. But as you mention, >> the >> assertion seems to fall down for DNS redirection, where the uCDN may >> have >> considerably less information. I think some different guidance for >> that >> case may be needed. > > True, but…making detailed CDNI logging information known to the uCDN > does not expose any more information to the uCDN than if the uCDN had > chosen to perform the content delivery itself. > > Typically when entity A contracts out work to entity B, entity A is > entitled to see all records produced by entity B on entity A’s > behalf. That may be a reasonable argument (I will let the thread from Stephen's comment play out), but that's not the argument the draft makes. If there are arguments that apply to DNS redirection (such as the one you mention), I think they should be included. Thanks, Ben C. From nobody Wed May 18 18:12:04 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 D07F512D094; Wed, 18 May 2016 18:12:02 -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 vWLbLLsudysf; Wed, 18 May 2016 18:12:01 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.144]) by ietfa.amsl.com (Postfix) with ESMTP id 51F2A12B068; Wed, 18 May 2016 18:12:01 -0700 (PDT) Received: from 97e41b89.skybroadband.com ([151.228.27.137] helo=[192.168.0.6]) by smtp04.mailcore.me with esmtpa (Exim 4.80.1) (envelope-from ) id 1b3CVM-000ACi-Dg; Thu, 19 May 2016 02:12:00 +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: <573D09D5.1020501@cs.tcd.ie> Date: Thu, 19 May 2016 02:11:58 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160518223257.14733.37895.idtracker@ietfa.amsl.com> <3E2786B2-9204-447C-9A53-A3CB0213E0F5@niven-jenkins.co.uk> <573CFEC8.8010600@cs.tcd.ie> <5DED924E-C407-44E9-8FF1-477B26B69647@niven-jenkins.co.uk> <573D09D5.1020501@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.2098) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Archived-At: Cc: Ben Campbell , draft-ietf-cdni-logging@ietf.org, The IESG , cdni@ietf.org, cdni-chairs@ietf.org Subject: Re: [CDNi] Ben Campbell's Discuss on draft-ietf-cdni-logging-25: (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, 19 May 2016 01:12:03 -0000 > On 19 May 2016, at 01:33, Stephen Farrell = wrote: > On 19/05/16 01:24, Ben Niven-Jenkins wrote: >>=20 >>> On 19 May 2016, at 00:46, Stephen Farrell >>> wrote: On 19/05/16 00:38, Ben >>> Niven-Jenkins wrote: >>>> Hi Ben, >>>>=20 >>>> I=E2=80=99ll let the authors respond to most of your comments but I >>>> wanted to respond to one of them, see below. >>>>=20 >>>>> On 18 May 2016, at 23:32, Ben Campbell wrote: >>>>>=20 >>>>> = ---------------------------------------------------------------------- >>>>>=20 > DISCUSS: >>>>> = ---------------------------------------------------------------------- >>>>>=20 > - 7.3: "Making detailed CDNI logging >>>>> information known to the uCDN does not represent a particular=20 >>>>> privacy concern because the uCDN is already exposed at request=20 >>>>> redirection time to most of the information that shows up as >>>>> CDNI logging information (e.g., enduser IP@, URL, HTTP headers >>>>> - at least when HTTP redirection is used between uCDN and >>>>> dCDN)." >>>>>=20 >>>>> I agree this is mostly true for HTTP redirection. But as you=20 >>>>> mention, the assertion seems to fall down for DNS redirection,=20 >>>>> where the uCDN may have considerably less information. I think >>>>> some different guidance for that case may be needed. >>>>=20 >>>> True, but=E2=80=A6making detailed CDNI logging information known to = the >>>> uCDN does not expose any more information to the uCDN than if the >>>> uCDN had chosen to perform the content delivery itself. >>>>=20 >>>> Typically when entity A contracts out work to entity B, entity A >>>> is entitled to see all records produced by entity B on entity >>>> A=E2=80=99s behalf. >>>=20 >>> I don't accept that that applies to all of the information that=20 >>> could be at issue here. For example if A is in the US and B is in=20 >>> the EU then things are not that simple. >>=20 >> You are correct that there are laws that may prevent the export of >> personal data from one country to another. AFAIK no IETF protocol >> that exchanges personal data or privacy impacting data has additional >> technical mechanisms to account for such laws (and I can not recall >> reading text in a technical specification RFC that discussed the >> impacts of such laws on the protocol being specified) so I don=E2=80=99= t see >> how the presence of such laws is relevant to the technical >> specification of the CDNI logging interface. >=20 > The relevance is that it shows that your argument wasn't correct > as stated. I=E2=80=99m not sure which part wasn=E2=80=99t correct unless we=E2=80=99r= e debating whether my use of =E2=80=9Ctypically=E2=80=9D is correct. I stated a technical fact that >>>> making detailed CDNI logging information known to the >>>> uCDN does not expose any more information to the uCDN than if the >>>> uCDN had chosen to perform the content delivery itself. I then stated a generalised version of that fact to try to illustrate = that this situation is not unique to CDNI. I don=E2=80=99t have data to = say how often the generalised version I stated occurs vs does not occur, = so maybe it isn=E2=80=99t =E2=80=9Ctypical=E2=80=9D maybe its only = =E2=80=9Csometimes=E2=80=9D. I didn=E2=80=99t consider that relevant and = figured =E2=80=9Ctypically=E2=80=9D conveys the meaning quite often = which I believe to be the case despite not having data to prove it. Anyway, regardless of any of that, the technical fact regarding CDNI = stands IMO and the generalised fact is not core to the point I was = making (see below).=20 > There are other arguments, that are perhaps not yet well > accepted by those considering CDNI, for example that receiving all > of that logging data unaggregated is more toxic than valuable, > but I think we had that discussion before and concluded that the > best and correct thing for us to do now with CDNI is to ensure > that some privacy friendly mode of operation exists and is usable. > Ben's discuss seems to me to be checking whether we've done that > as well as we thought, and that's a good thing. I agree. > If instead you want to re-litigate that basic argument then we > can do that but I expect that'd be unproductive for us all and > would land us back where we are now anyway. I=E2=80=99m not trying to re-litigate anything.=20 Maybe I should have been more expansive in my initial response. Ben = raised the question of whether due to the assertion seeming to fall down = for DNS redirection, the document should offer different guidance for = DNS redirection to HTTP redirection. My intention was to express my = opinion that because the uCDN could have chosen to perform the content = delivery itself the dCDN is not exposing any more information to the = uCDN than the uCDN could have chosen to gather itself if it so desired = and therefore IMO there is no need to provide different guidance for DNS = redirection than for HTTP redirection. Ben From nobody Wed May 18 18:13:12 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 3BF0112D094; Wed, 18 May 2016 18:13:06 -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, HTML_MESSAGE=0.001, 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 qU5toatZkiXC; Wed, 18 May 2016 18:13:05 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.144]) by ietfa.amsl.com (Postfix) with ESMTP id D5E9512B068; Wed, 18 May 2016 18:13:04 -0700 (PDT) Received: from 97e41b89.skybroadband.com ([151.228.27.137] helo=[192.168.0.6]) by smtp04.mailcore.me with esmtpa (Exim 4.80.1) (envelope-from ) id 1b3CWO-000BHT-4P; Thu, 19 May 2016 02:13:04 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_FF8D4A81-8487-452B-B8ED-E4FFA6803525" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Ben Niven-Jenkins In-Reply-To: <55925599-3D57-4DFD-BB6E-8142EC6A2199@nostrum.com> Date: Thu, 19 May 2016 02:13:03 +0100 Message-Id: References: <20160518223257.14733.37895.idtracker@ietfa.amsl.com> <3E2786B2-9204-447C-9A53-A3CB0213E0F5@niven-jenkins.co.uk> <55925599-3D57-4DFD-BB6E-8142EC6A2199@nostrum.com> To: Ben Campbell 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@ietf.org, cdni-chairs@ietf.org Subject: Re: [CDNi] Ben Campbell's Discuss on draft-ietf-cdni-logging-25: (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, 19 May 2016 01:13:06 -0000 --Apple-Mail=_FF8D4A81-8487-452B-B8ED-E4FFA6803525 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Ben C, > On 19 May 2016, at 01:51, Ben Campbell wrote: >=20 > On 18 May 2016, at 18:38, Ben Niven-Jenkins wrote: >=20 >> Hi Ben, >>=20 >> I=E2=80=99ll let the authors respond to most of your comments but I = wanted to respond to one of them, see below. >>=20 >>> On 18 May 2016, at 23:32, Ben Campbell wrote: >>> = ---------------------------------------------------------------------- >>> DISCUSS: >>> = ---------------------------------------------------------------------- >>> - 7.3: "Making detailed CDNI logging >>> information known to the uCDN does not represent a particular = privacy >>> concern because the uCDN is already exposed at request redirection >>> time to most of the information that shows up as CDNI logging >>> information (e.g., enduser IP@, URL, HTTP headers - at least when >>> HTTP redirection is used between uCDN and dCDN)." >>>=20 >>> I agree this is mostly true for HTTP redirection. But as you = mention, the >>> assertion seems to fall down for DNS redirection, where the uCDN may = have >>> considerably less information. I think some different guidance for = that >>> case may be needed. >>=20 >> True, but=E2=80=A6making detailed CDNI logging information known to = the uCDN does not expose any more information to the uCDN than if the = uCDN had chosen to perform the content delivery itself. >>=20 >> Typically when entity A contracts out work to entity B, entity A is = entitled to see all records produced by entity B on entity A=E2=80=99s = behalf. >=20 > That may be a reasonable argument (I will let the thread from = Stephen's comment play out), but that's not the argument the draft = makes. Agreed. > If there are arguments that apply to DNS redirection (such as the one = you mention), I think they should be included. Agreed. Ben --Apple-Mail=_FF8D4A81-8487-452B-B8ED-E4FFA6803525 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Ben C,

On 19 May 2016, at 01:51, Ben = Campbell <ben@nostrum.com> wrote:

On 18 May 2016, at 18:38, Ben Niven-Jenkins = wrote:

Hi Ben,

I=E2=80=99ll let = the authors respond to most of your comments but I wanted to respond to = one of them, see below.

On 18 May 2016, at 23:32, Ben Campbell <ben@nostrum.com> = wrote:
---------------------------------------------------------------= -------
DISCUSS:
---------------------------------------------------------------= -------
- 7.3: "Making detailed CDNI logging
 information known to the uCDN does not represent a = particular privacy
 concern because the uCDN is = already exposed at request redirection
 time to most = of the information that shows up as CDNI logging
 information (e.g., enduser IP@, URL, HTTP headers - at = least when
 HTTP redirection is used between uCDN and = dCDN)."

I agree this is mostly true for = HTTP redirection. But as you mention, the
assertion seems = to fall down for DNS redirection, where the uCDN may have
considerably less information. I think some different = guidance for that
case may be needed.

True, but=E2=80=A6making detailed = CDNI logging information known to the uCDN does not expose any more = information to the uCDN than if the uCDN had chosen to perform the = content delivery itself.

Typically when = entity A contracts out work to entity B, entity A is entitled to see all = records produced by entity B on entity A=E2=80=99s behalf.

That may be a reasonable = argument (I will let the thread from Stephen's comment play out), but = that's not the argument the draft = makes.

Agreed.

If there are arguments that apply to DNS = redirection (such as the one you mention), I think they should be = included.

Agreed.

Ben

= --Apple-Mail=_FF8D4A81-8487-452B-B8ED-E4FFA6803525-- From nobody Wed May 18 18:41:31 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 1E6D512D164; Wed, 18 May 2016 18:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.727 X-Spam-Level: X-Spam-Status: No, score=-5.727 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=-1.426, SPF_PASS=-0.001] 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 pUKIj_WQgSxP; Wed, 18 May 2016 18:41:27 -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 93D1E12D14B; Wed, 18 May 2016 18:41:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 19409BE2C; Thu, 19 May 2016 02:41:26 +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 w8bUTnxqW81I; Thu, 19 May 2016 02:41:24 +0100 (IST) Received: from [10.87.48.75] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 387BFBDF9; Thu, 19 May 2016 02:41:24 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1463622084; bh=PimrU2z9eDQ7iCPvI6iMNvRJKb21SdPPySLsJp3PJ74=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=Mnq3NdC3FaPc5jJM0yUBfFYiHeMF8UBQZRJ7NqlCwA0qZV4tV9i2zLVbUmBeD5A0N xrqD01TMqdpXzG/D9Tv9fScIzdc8xg+4KDbOeB0hhFGWT+fzYZpEPco55tI5Nsburb g95XVtVKW9xfpCwB2t9vgzZ2YYbCruWNUsPFz9Sk= To: Ben Niven-Jenkins References: <20160518223257.14733.37895.idtracker@ietfa.amsl.com> <3E2786B2-9204-447C-9A53-A3CB0213E0F5@niven-jenkins.co.uk> <573CFEC8.8010600@cs.tcd.ie> <5DED924E-C407-44E9-8FF1-477B26B69647@niven-jenkins.co.uk> <573D09D5.1020501@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <573D19C3.3050304@cs.tcd.ie> Date: Thu, 19 May 2016 02:41:23 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010309080303070603030806" Archived-At: Cc: Ben Campbell , draft-ietf-cdni-logging@ietf.org, The IESG , cdni@ietf.org, cdni-chairs@ietf.org Subject: Re: [CDNi] Ben Campbell's Discuss on draft-ietf-cdni-logging-25: (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, 19 May 2016 01:41:29 -0000 This is a cryptographically signed message in MIME format. --------------ms010309080303070603030806 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cutting to (I think) the substantive bit... On 19/05/16 02:11, Ben Niven-Jenkins wrote: > My intention was to express my opinion that because the uCDN could > have chosen to perform the content delivery itself the dCDN is not > exposing any more information to the uCDN than the uCDN could have > chosen to gather itself if it so desired and therefore IMO there is > no need to provide different guidance for DNS redirection than for > HTTP redirection. Yes, I've seen arguments of that form offered a number of times. I don't find it convincing myself, but recognise that other folks do. And in every case so far, neither side has convinced the other, and sometimes not even understood one another. But let's see if we (me really:-) get better with practice... In this case I'd argue that the "could have chosen" isn't really true - presumably the uCDN deals with the dCDN because it's hard(er) for the uCDN to do the work directly, so it's not really true that the uCDN could have chosen to access the information, at least not at the same cost. And there may be aspects of meta-data that are just different because the access was via the dCDN, e.g. perhaps some other client IP address gets used if somethings multihomed, or some ISP infrastructure differs, e.g. HTTP Forwarded might be present and visible to the dCDN but with no similar thing for DNS (or vice versa). I'd not be surprised if even more subtle differences existed over populations of transactions and users and CDNs. S. --------------ms010309080303070603030806 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 oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA1MTkw MTQxMjNaMC8GCSqGSIb3DQEJBDEiBCAa91LiKuCIJSezjfFvoCktwt0Ijh/CP1HUDN7ATOFM ETBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQCFP63wbtYLZ3b1JnM/0dcjrDw03AvLpIaWVNypnuWT8WlwCXsD9vsC rT7bgd7cKHF4V9upyhcaJcRGxzuaPYmg2Sns7+ldspoPqA7Str2dQY1ENMwxNUvTU/AQ77gF V++VW7VOg76imqmCv+dHJfbBp34lnO2F1+jAZGiIw6DyBgJGrQvelQhW0ayLOvA4Ht1ejUtb Ub+KfzJTpmj4jflVv6hf6sigfV+FCy8tnC37VWGEZ6WJTFbmj42sUUpDW5V/wz+AVsby1jJF C5WyDnudgPmnECQ3Gmh8VOS+jd7xf/vwuYtINJ7ZX44nQM/qAy5aP3w3msTdLQmPrf9Rgncw AAAAAAAA --------------ms010309080303070603030806-- From nobody Wed May 18 23:15:54 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 C074412D0BB for ; Wed, 18 May 2016 23:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.334 X-Spam-Level: *** X-Spam-Status: No, score=3.334 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SBL_CSS=3.335] autolearn=no 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 CdxcHpCC4Sqx for ; Wed, 18 May 2016 23:15:51 -0700 (PDT) Received: from gateway21.websitewelcome.com (gateway21.websitewelcome.com [192.185.45.191]) (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 89D5A12B04D for ; Wed, 18 May 2016 23:15:51 -0700 (PDT) Received: from cm3.websitewelcome.com (unknown [108.167.139.23]) by gateway21.websitewelcome.com (Postfix) with ESMTP id 12C4198C248B3 for ; Thu, 19 May 2016 01:15:51 -0500 (CDT) Received: from dacia.websitewelcome.com ([192.185.83.214]) by cm3.websitewelcome.com with id w6Fp1s00Z4dTGTk016Fr2B; Thu, 19 May 2016 01:15:51 -0500 Received: from [189.90.243.192] (port=51596 helo=btkcm.com) by dacia.websitewelcome.com with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.86_1) (envelope-from ) id 1b3HFM-0002To-Ma; Thu, 19 May 2016 01:15:49 -0500 From: To: "cd" , "cdni" , "CEIC" , "Center for American Progress Action Fund" , "Center for American Progress Action Fund" , "Center Parcs - CDO" Date: Thu, 19 May 2016 09:15:41 +0300 Message-ID: <0000a468c02b$a42c5267$2d300cb7$@queuefull.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_2CB31691.77AE76D7" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdGzqnrxxuCU8xpHn6tHvQDXl0uwYw== Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dacia.websitewelcome.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - queuefull.net X-BWhitelist: no X-Source-IP: 189.90.243.192 X-Exim-ID: 1b3HFM-0002To-Ma X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (btkcm.com) [189.90.243.192]:51596 X-Source-Auth: karla@oologahumc.org X-Email-Count: 401 X-Source-Cap: b29sb2dhaHU7Y2hlYXBjOTY7ZGFjaWEud2Vic2l0ZXdlbGNvbWUuY29t Archived-At: Subject: [CDNi] good news 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, 19 May 2016 06:15:53 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0001_2CB31691.77AE76D7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hey, I've got some good news for you, read more about it here Kind regards, bensons@queuefull.net ------=_NextPart_000_0001_2CB31691.77AE76D7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

<= span lang=3DEN-US>Hey,

 

I've got some good news for you, read more about it here <= a href=3D"http://gabogehu.lauraboldrinitroia.com/program.php?o">http:/= /gabogehu.lauraboldrinitroia.com/program.php

=

 

Kind regards, bensons@queuefull.= net

------=_NextPart_000_0001_2CB31691.77AE76D7-- From nobody Thu May 19 07:07:15 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 85ABA12D1DC; Thu, 19 May 2016 07:07:11 -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.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160519140711.17404.82308.idtracker@ietfa.amsl.com> Date: Thu, 19 May 2016 07:07:11 -0700 Archived-At: Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-control-triggers-15.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: Thu, 19 May 2016 14:07:11 -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-15.txt Pages : 46 Date : 2016-05-19 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-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-control-triggers-15 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 May 19 07:13:38 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 A5C5612DA6B; Thu, 19 May 2016 07:13:32 -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 lzuHmZot14Ke; Thu, 19 May 2016 07:13:31 -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 06C7D12B059; Thu, 19 May 2016 07:13:31 -0700 (PDT) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id B0C0D7A5339DC; Thu, 19 May 2016 14:13:24 +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 u4JEDQkw003983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 19 May 2016 14:13:26 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u4JEDHsu018536 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 May 2016 16:13:25 +0200 Received: from FR711WXCHMBA02.zeu.alcatel-lucent.com ([169.254.2.23]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Thu, 19 May 2016 16:13:17 +0200 From: "Murray, Rob (Nokia - GB)" To: Alexey Melnikov , The IESG Thread-Topic: [COMMERCIAL] Alexey Melnikov's Yes on draft-ietf-cdni-control-triggers-14: (withCOMMENT) Thread-Index: AQHRsR262278bjTL+0254bTHCCVoqp/APoSA Date: Thu, 19 May 2016 14:13:16 +0000 Message-ID: References: <20160518155522.14636.83186.idtracker@ietfa.amsl.com> In-Reply-To: <20160518155522.14636.83186.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/f.16.0.160506 x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="utf-8" Content-ID: <60160F9317A6A842B78D3FFFC719F615@exchange.lucent.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "flefauch@cisco.com" , "cdni@ietf.org" , "draft-ietf-cdni-control-triggers@ietf.org" , "cdni-chairs@ietf.org" Subject: Re: [CDNi] [COMMERCIAL] Alexey Melnikov's Yes on draft-ietf-cdni-control-triggers-14: (withCOMMENT) 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, 19 May 2016 14:13:33 -0000 T24gMTgvMDUvMjAxNiwgMTY6NTUsICJBbGV4ZXkgTWVsbmlrb3YiIDxhYW1lbG5pa292QGZhc3Rt YWlsLmZtPiB3cm90ZToNCg0KPkFsZXhleSBNZWxuaWtvdiBoYXMgZW50ZXJlZCB0aGUgZm9sbG93 aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCj5kcmFmdC1pZXRmLWNkbmktY29udHJvbC10cmlnZ2Vy cy0xNDogWWVzDQo+DQo+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPkNPTU1FTlQ6DQo+LS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K Pg0KPlRoYW5rIHlvdSBmb3IgYWRkcmVzc2luZyBteSBlYXJsaWVyIGNvbW1lbnRzLg0KPg0KPlJl Z2FyZGluZyBteSBlYXJsaWVyIGNoYW5nZTogTWVkaWEgdHlwZTogc2hvdWxkIGl0IGhhdmUgK2pz b24gc3VmZml4PyBJcw0KPnRoZSBjdXJyZW50bHkgZGVmaW5lZCBtZWRpYSB0eXBlIGRlcGxveWVk Pw0KPg0KPiAtLSBJIGRpZG4ndCByZWFsaXplIHRoYXQgYXBwbGljYXRpb24vY2RuaSBpcyBhbHJl YWR5IHJlZ2lzdGVyZWQgd2l0aA0KPklBTkEgYnkgUkZDIDc3MzYuIFNvIHRoaXMgY29tbWVudCBk b2Vzbid0IGFwcGx5IGFuZCBzaG91bGQgcmV2ZXJ0IHRoaXMNCj5jaGFuZ2UuIEkgYW0gc29ycnkg YWJvdXQgdGhhdCENCg0KDQpUaGFua3MgQWxleGV5IC0gbm8gcHJvYmxlbSBvbiB0aGUgIitqc29u IiwgdGhhdCdzIHdoYXQgc2VhcmNoICYgcmVwbGFjZSBpcyBmb3IhIEkndmUgcHVibGlzaGVkIGEg Ii0xNSIgd2l0aCB0aGF0IGNoYW5nZS4NCg0KRnJhbmNvaXMvS2V2aW4gLSBJIHRoaW5rIGFsbCB0 aGUgcmV2aWV3IGNvbW1lbnRzIGFnYWluc3QgdGhpcyBkcmFmdCBhcmUgY2xlYXJlZCBub3cuDQog DQpSb2INCg0KDQo= From nobody Thu May 19 07:47:25 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 C1B2012D1E2 for ; Thu, 19 May 2016 07:47: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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=gQz5LFRH; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=I7d1moAL 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 3BzDWaxoKAcO for ; Thu, 19 May 2016 07:47:22 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB06D12D11E for ; Thu, 19 May 2016 07:47:22 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 3530F2018F for ; Thu, 19 May 2016 10:47:22 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute6.internal (MEProxy); Thu, 19 May 2016 10:47:22 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; 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=Poi9I5XNtZ7edZLxdUJS4j+KZmg=; b=gQz5LF RHZtNyFhZjEv90i4HmiviL7/+RxJoc/dm/Lp+su3wvV9yZDrdSeX00TWF1jOT+EY FLyxAIcj48oDUM/WZPE++pva3EfQJbRoxSLRz3mM8rORv801CkXFr4yIgcvKHQjh hpj4jbJnDNal6DFKwXKwGAYEuwHXbvynkC6Zw= 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=Poi9I5XNtZ7edZL xdUJS4j+KZmg=; b=I7d1moAL73Tx691cG5VypTBfut2BG2D9Hmt/yOrHTXKrB2t AE7HykqKOmkgTcol5BXDqXGh1TbfBVQ+mPreJ4O8NNa4K+/W4H1CbC/P3Q2qb5pp 5+pfuWnLe5DzozuzNdcoaA8wU1cJFOrPNNZkYIriliHaQtRlylVkCdQHZEjU= Received: by web5.nyi.internal (Postfix, from userid 99) id 0DF01B42A65; Thu, 19 May 2016 10:47:22 -0400 (EDT) Message-Id: <1463669241.2738481.612687657.19694B14@webmail.messagingengine.com> X-Sasl-Enc: rgpImGYVGL0Gpkp78NjiaaPagk/1TA/jFPTkWe6XcCoz 1463669241 From: Alexey Melnikov To: "Murray, Rob (Nokia - GB)" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-7a111996 In-Reply-To: References: <20160518155522.14636.83186.idtracker@ietfa.amsl.com> Date: Thu, 19 May 2016 15:47:21 +0100 Archived-At: Cc: flefauch@cisco.com, cdni@ietf.org, draft-ietf-cdni-control-triggers@ietf.org, cdni-chairs@ietf.org Subject: Re: [CDNi] [COMMERCIAL] Alexey Melnikov's Yes on draft-ietf-cdni-control-triggers-14: (withCOMMENT) 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, 19 May 2016 14:47:25 -0000 Hi Rob, On Thu, May 19, 2016, at 03:13 PM, Murray, Rob (Nokia - GB) wrote: > On 18/05/2016, 16:55, "Alexey Melnikov" wrote: > > >Alexey Melnikov has entered the following ballot position for > >draft-ietf-cdni-control-triggers-14: Yes > > > >---------------------------------------------------------------------- > >COMMENT: > >---------------------------------------------------------------------- > > > >Thank you for addressing my earlier comments. > > > >Regarding my earlier change: Media type: should it have +json suffix? Is > >the currently defined media type deployed? > > > > -- I didn't realize that application/cdni is already registered with > >IANA by RFC 7736. So this comment doesn't apply and should revert this > >change. I am sorry about that! > > > Thanks Alexey - no problem on the "+json", that's what search & replace > is for! I've published a "-15" with that change. > > Francois/Kevin - I think all the review comments against this draft are > cleared now. Ben needs to check the new text about TLS, which I think is addressed now. I don't know if you ever replied to the following question from Ben: "I assume I am missing something here. How does a surrogate know that the situation exists in the first place? How would a surrogate know about invalidate commands that happened while it was offline?" The text in question is: A CI/T "invalidate" command may be reported as "complete" when surrogates that may have the data are offline. In this case, surrogates MUST NOT use the affected data without first revalidating it when they are back online. From nobody Thu May 19 07:56:59 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 B1A4412D12B; Thu, 19 May 2016 07:56:54 -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.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160519145654.17290.50373.idtracker@ietfa.amsl.com> Date: Thu, 19 May 2016 07:56:54 -0700 Archived-At: Cc: flefauch@cisco.com, cdni@ietf.org, draft-ietf-cdni-control-triggers@ietf.org, cdni-chairs@ietf.org Subject: [CDNi] Ben Campbell's No Objection on draft-ietf-cdni-control-triggers-15: (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, 19 May 2016 14:56:55 -0000 Ben Campbell has entered the following ballot position for draft-ietf-cdni-control-triggers-15: 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-control-triggers/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for handling my DISCUSS point related to the TLS requirement. I had one remaining DISCUSS point that I am not sure has been resolved--but after the conversation that did happen, it is probably no longer DISCUSS-worthy: - 4.7, 2nd bullet under handling of offline surrogates: I assume I am missing something here. How does a surrogate know that the situation exists in the first place? How would a surrogate know about invalidate commands that happened while it was offline? ------------- The remaining comments are old. I think they've mostly been addressed, but did not recheck them: - 3, paragraph 5: SHOULD should not be equated with "optional to implement". MAY means that. SHOULD is intended to be stronger. - 4.5, 2nd paragraph, 1st sentence: This is pretty convoluted. I suggest reformulating without the past tense "MUST". For example, "The dCNI MUST report the expiration times if..." -4.6: "If CDNs B and C delegate delivery of CDN A’s content to each other" Is this a reasonable configuration? It seems like they might already have a delegation loop before the trigger interface got involved. Also, the first sentence is a fragment. = 4.8, first paragraph: I suggest s/transform/"similarly transform" - 5.1.3, staleresourcetime, mandatory: Doesn't this effectively mean the value must be the same across all collections? - 5.2.1, content.ccid: Seems like the reference to [I-D.ietf-cdni-metadata] should be normative. - 6.2.5: it looks like the dCDN is sending the request to itself. Is that the intent? - 8.1, last paragraph: "In this case, the dCDN MUST allow each uCDN from which the content could have been acquired to act upon that content using CI/T Commands." This seems like a place where local policy might reasonably vary. Is a MUST really appropriate? From nobody Thu May 19 08:00: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 B6D0F12D12B; Thu, 19 May 2016 08:00:01 -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 u86IO3KBac01; Thu, 19 May 2016 07:59:59 -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 9F36612D103; Thu, 19 May 2016 07:59:59 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id DDAA8733A9872; Thu, 19 May 2016 14:59:54 +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 u4JExvR5014001 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 19 May 2016 14:59:57 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u4JExrrG023557 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 May 2016 16:59:56 +0200 Received: from FR711WXCHMBA02.zeu.alcatel-lucent.com ([169.254.2.23]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Thu, 19 May 2016 16:59:54 +0200 From: "Murray, Rob (Nokia - GB)" To: Alexey Melnikov , Ben Campbell Thread-Topic: [COMMERCIAL] Alexey Melnikov's Yes on draft-ietf-cdni-control-triggers-14: (withCOMMENT) Thread-Index: AQHRsR262278bjTL+0254bTHCCVoqp/APoSA///4a4CAABSbAA== Date: Thu, 19 May 2016 14:59:53 +0000 Message-ID: References: <20160518155522.14636.83186.idtracker@ietfa.amsl.com> <1463669241.2738481.612687657.19694B14@webmail.messagingengine.com> In-Reply-To: <1463669241.2738481.612687657.19694B14@webmail.messagingengine.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.16.0.160506 x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="utf-8" Content-ID: <143ED5665B4300468915F54BC659AE8F@exchange.lucent.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "flefauch@cisco.com" , "cdni@ietf.org" , "draft-ietf-cdni-control-triggers@ietf.org" , "cdni-chairs@ietf.org" Subject: Re: [CDNi] [COMMERCIAL] Alexey Melnikov's Yes on draft-ietf-cdni-control-triggers-14: (withCOMMENT) 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, 19 May 2016 15:00:02 -0000 T24gMTkvMDUvMjAxNiwgMTU6NDcsICJBbGV4ZXkgTWVsbmlrb3YiIDxhYW1lbG5pa292QGZhc3Rt YWlsLmZtPiB3cm90ZToNCg0KPkhpIFJvYiwNCj4NCj5PbiBUaHUsIE1heSAxOSwgMjAxNiwgYXQg MDM6MTMgUE0sIE11cnJheSwgUm9iIChOb2tpYSAtIEdCKSB3cm90ZToNCj4+IE9uIDE4LzA1LzIw MTYsIDE2OjU1LCAiQWxleGV5IE1lbG5pa292IiA8YWFtZWxuaWtvdkBmYXN0bWFpbC5mbT4gd3Jv dGU6DQo+PiANCj4+ID5BbGV4ZXkgTWVsbmlrb3YgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBi YWxsb3QgcG9zaXRpb24gZm9yDQo+PiA+ZHJhZnQtaWV0Zi1jZG5pLWNvbnRyb2wtdHJpZ2dlcnMt MTQ6IFllcw0KPj4gPg0KPj4gPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+ID5DT01NRU5UOg0KPj4gPi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCj4+ID4NCj4+ID5UaGFuayB5b3UgZm9yIGFkZHJlc3NpbmcgbXkgZWFybGllciBj b21tZW50cy4NCj4+ID4NCj4+ID5SZWdhcmRpbmcgbXkgZWFybGllciBjaGFuZ2U6IE1lZGlhIHR5 cGU6IHNob3VsZCBpdCBoYXZlICtqc29uIHN1ZmZpeD8gSXMNCj4+ID50aGUgY3VycmVudGx5IGRl ZmluZWQgbWVkaWEgdHlwZSBkZXBsb3llZD8NCj4+ID4NCj4+ID4gLS0gSSBkaWRuJ3QgcmVhbGl6 ZSB0aGF0IGFwcGxpY2F0aW9uL2NkbmkgaXMgYWxyZWFkeSByZWdpc3RlcmVkIHdpdGgNCj4+ID5J QU5BIGJ5IFJGQyA3NzM2LiBTbyB0aGlzIGNvbW1lbnQgZG9lc24ndCBhcHBseSBhbmQgc2hvdWxk IHJldmVydCB0aGlzDQo+PiA+Y2hhbmdlLiBJIGFtIHNvcnJ5IGFib3V0IHRoYXQhDQo+PiANCj4+ IA0KPj4gVGhhbmtzIEFsZXhleSAtIG5vIHByb2JsZW0gb24gdGhlICIranNvbiIsIHRoYXQncyB3 aGF0IHNlYXJjaCAmIHJlcGxhY2UNCj4+IGlzIGZvciEgSSd2ZSBwdWJsaXNoZWQgYSAiLTE1IiB3 aXRoIHRoYXQgY2hhbmdlLg0KPj4gDQo+PiBGcmFuY29pcy9LZXZpbiAtIEkgdGhpbmsgYWxsIHRo ZSByZXZpZXcgY29tbWVudHMgYWdhaW5zdCB0aGlzIGRyYWZ0IGFyZQ0KPj4gY2xlYXJlZCBub3cu DQo+DQo+QmVuIG5lZWRzIHRvIGNoZWNrIHRoZSBuZXcgdGV4dCBhYm91dCBUTFMsIHdoaWNoIEkg dGhpbmsgaXMgYWRkcmVzc2VkDQo+bm93Lg0KPg0KPkkgZG9uJ3Qga25vdyBpZiB5b3UgZXZlciBy ZXBsaWVkIHRvIHRoZSBmb2xsb3dpbmcgcXVlc3Rpb24gZnJvbSBCZW46DQo+DQo+ICJJIGFzc3Vt ZSBJIGFtIG1pc3Npbmcgc29tZXRoaW5nIGhlcmUuIEhvdyBkb2VzIGEgc3Vycm9nYXRlIGtub3cg dGhhdA0KPiB0aGUgc2l0dWF0aW9uIGV4aXN0cyBpbiB0aGUgZmlyc3QgcGxhY2U/IEhvdyB3b3Vs ZCBhIHN1cnJvZ2F0ZSBrbm93DQo+IGFib3V0IGludmFsaWRhdGUgY29tbWFuZHMgdGhhdCBoYXBw ZW5lZCB3aGlsZSBpdCB3YXMgb2ZmbGluZT8iDQo+DQo+VGhlIHRleHQgaW4gcXVlc3Rpb24gaXM6 DQo+DQo+ICAgICAgQSBDSS9UICJpbnZhbGlkYXRlIiBjb21tYW5kIG1heSBiZSByZXBvcnRlZCBh cyAiY29tcGxldGUiIHdoZW4NCj4gICAgICBzdXJyb2dhdGVzIHRoYXQgbWF5IGhhdmUgdGhlIGRh dGEgYXJlIG9mZmxpbmUuICBJbiB0aGlzIGNhc2UsDQo+ICAgICAgc3Vycm9nYXRlcyBNVVNUIE5P VCB1c2UgdGhlIGFmZmVjdGVkIGRhdGEgd2l0aG91dCBmaXJzdA0KPiAgICAgIHJldmFsaWRhdGlu ZyBpdCB3aGVuIHRoZXkgYXJlIGJhY2sgb25saW5lLg0KDQpJIHJlcGxpZWQgaW4gdGhpcyBlbWFp bCAuLi4NCg0KaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9jZG5pL25QejRD dUpYdXhrNWRYaEVQMm4tZ3RjeDdBZw0KDQouLi4gYnV0IHRoZXJlIG5vdCBiZWVuIGFueSBmb2xs b3ctdXAuIFNvIHlvdSdyZSByaWdodCwgQmVuJ3MgY29tbWVudHMgYXJlbid0IGNsZWFyZWQgeWV0 LiBTb3JyeS4NCg0KUm9iLg0KDQoNCg0KDQo= From nobody Thu May 19 08:16: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 9779B12D1A2; Thu, 19 May 2016 08:15:56 -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 kK0k2oSTId9H; Thu, 19 May 2016 08:15:54 -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 58E4912D103; Thu, 19 May 2016 08:15:54 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id CFD13B34EDFB0; Thu, 19 May 2016 15:15:49 +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 u4JFFq6v004797 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 19 May 2016 15:15:52 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 u4JFFepI031421 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 May 2016 17:15:50 +0200 Received: from FR711WXCHMBA02.zeu.alcatel-lucent.com ([169.254.2.23]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Thu, 19 May 2016 17:15:41 +0200 From: "Murray, Rob (Nokia - GB)" To: Ben Campbell , The IESG Thread-Topic: [CDNi] Ben Campbell's No Objection on draft-ietf-cdni-control-triggers-15: (with COMMENT) Thread-Index: AQHRsd65dui8eZI4sU+IORGPeGBaeJ/ATnGA Date: Thu, 19 May 2016 15:15:40 +0000 Message-ID: References: <20160519145654.17290.50373.idtracker@ietfa.amsl.com> In-Reply-To: <20160519145654.17290.50373.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/f.16.0.160506 x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="utf-8" Content-ID: <082BEFDBFBF23E48B3908858B6ACC90C@exchange.lucent.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "flefauch@cisco.com" , "cdni@ietf.org" , "draft-ietf-cdni-control-triggers@ietf.org" , "cdni-chairs@ietf.org" Subject: Re: [CDNi] Ben Campbell's No Objection on draft-ietf-cdni-control-triggers-15: (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, 19 May 2016 15:15:56 -0000 VGhhbmtzIEJlbi4NCg0KSSByZXBsaWVkIHRvIHRoZXNlIGNvbW1lbnRzIGluIGh0dHA6Ly9tYWls YXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9jZG5pL0Q3YlFNUW1CaE11TUllMUw1RXBhSDFuQzZz aywgYW5kIGFkZHJlc3NlZCBtb3N0IG9mIHRoZW0gaW4gIi0xMyIgb2YgdGhlIGRyYWZ0Lg0KDQpJ dCdkIGJlIHdvcnRoIHlvdSBjaGVja2luZyB5b3UncmUgaGFwcHkgd2l0aCBteSBvdGhlciByZXNw b25zZXMgdGhvdWdoIC0gcmVwZWF0ZWQgYmVsb3cuDQoNCkNoZWVycywNClJvYi4NCg0KDQpPbiAx OS8wNS8yMDE2LCAxNTo1NiwgIkNETmkgb24gYmVoYWxmIG9mIEJlbiBDYW1wYmVsbCIgPGNkbmkt Ym91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgYmVuQG5vc3RydW0uY29tPiB3cm90ZToNCg0K PkJlbiBDYW1wYmVsbCBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBm b3INCj5kcmFmdC1pZXRmLWNkbmktY29udHJvbC10cmlnZ2Vycy0xNTogTm8gT2JqZWN0aW9uDQo+ DQo+DQo+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPkNPTU1FTlQ6DQo+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPg0KPlRoYW5r cyBmb3IgaGFuZGxpbmcgbXkgRElTQ1VTUyBwb2ludCByZWxhdGVkIHRvIHRoZSBUTFMgcmVxdWly ZW1lbnQuICBJDQo+aGFkIG9uZSByZW1haW5pbmcgRElTQ1VTUyBwb2ludCB0aGF0IEkgYW0gbm90 IHN1cmUgaGFzIGJlZW4gcmVzb2x2ZWQtLWJ1dA0KPmFmdGVyIHRoZSBjb252ZXJzYXRpb24gdGhh dCBkaWQgaGFwcGVuLCBpdCBpcyBwcm9iYWJseSBubyBsb25nZXINCj5ESVNDVVNTLXdvcnRoeToN Cj4NCj4tIDQuNywgMm5kIGJ1bGxldCB1bmRlciBoYW5kbGluZyBvZiBvZmZsaW5lIHN1cnJvZ2F0 ZXM6DQo+DQo+SSBhc3N1bWUgSSBhbSBtaXNzaW5nIHNvbWV0aGluZyBoZXJlLiBIb3cgZG9lcyBh IHN1cnJvZ2F0ZSBrbm93IHRoYXQgdGhlDQo+c2l0dWF0aW9uIGV4aXN0cyBpbiB0aGUgZmlyc3Qg cGxhY2U/IEhvdyB3b3VsZCBhIHN1cnJvZ2F0ZSBrbm93IGFib3V0DQo+aW52YWxpZGF0ZSBjb21t YW5kcyB0aGF0IGhhcHBlbmVkIHdoaWxlIGl0IHdhcyBvZmZsaW5lPw0KDQpJIHJlcGxpZWQgaW4g aHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9jZG5pL25QejRDdUpYdXhrNWRY aEVQMm4tZ3RjeDdBZyB3aXRoIC4uLg0KDQpBIENETiBpbXBsZW1lbnRhdGlvbiBjb3VsZCBkZWNp ZGUgdG8gcmV2YWxpZGF0ZSBhbGwgb2YgaXRzIGNvbnRlbnQgaWYgaXQncyBiZWVuIG9mZmxpbmUs IHRoYXQnZCB3b3JrIGJ1dCBpdCdkIGJlIGEgYml0IGV4dHJlbWUuDQoNCkluIG91ciBpbXBsZW1l bnRhdGlvbiwgaW5kaXZpZHVhbCBjYWNoZXMgcXVlcnkgZm9yIGNvbW1hbmRzIG9yIGNvbmZpZyBj aGFuZ2VzIHRoZXkgbWlzc2VkIHdoZW4gdGhleSBjb21lIG9ubGluZSAoYmVmb3JlIHRoZXkgc3Rh cnQgdGFraW5nIHRyYWZmaWMpLg0KDQpUaGUgcG9pbnQgaXMgdGhhdCBpdCdzIGFuIGltcGxlbWVu dGF0aW9uIGRlY2lzaW9uIC4uLiBmcm9tIGEgQ0ROLWludGVyY29ubmVjdCBwb2ludC1vZi12aWV3 IGl0IGRvZXNuJ3QgbWF0dGVyIGhvdyB0aGUgZENETiBtYWtlcyBzdXJlIGl0J3Mgbm90IHNlcnZp bmcgaW52YWxpZGF0ZWQvZGVsZXRlZCBjb250ZW50LCBidXQgdGhlcmUncyBhIHJlcXVpcmVtZW50 IGZvciBpdCB0byBkbyBzbyBzb21laG93IC0gd2hpY2ggaXMgd2hhdCBJIHdhcyB0cnlpbmcgdG8g c3RhdGUgaW4gdGhlIGRyYWZ0Lg0KDQpPbmNlIGEgQ0ROIGdldHMgYmlnIGVub3VnaCwgdGhlcmUn cyBhIGZhaXIgY2hhbmNlIHRoYXQgYXQgbGVhc3Qgb25lIGNhY2hlIGlzIG9mZmxpbmUgYXQgYW55 IGdpdmVuIHRpbWUgZm9yIG1haW50ZW5hbmNlLCBiZWNhdXNlIG9mIGhhcmR3YXJlIG9yIG5ldHdv cmsgZmFpbHVyZSwgZXRjLiBTbyBDRE5zIGhhdmUgdG8gZGVhbCB3aXRoIGluZGl2aWR1YWwgY2Fj aGVzIG1pc3NpbmcgaW50ZXJuYWwgaW52YWxpZGF0ZS9wdXJnZSBjb21tYW5kcywgYW5kIHNob3Vs ZCBkbyB0aGUgc2FtZSB3aGVuIGludGVyY29ubmVjdGVkLg0KDQoNCj4tLS0tLS0tLS0tLS0tDQo+ DQo+IFRoZSByZW1haW5pbmcgY29tbWVudHMgYXJlIG9sZC4gSSB0aGluayB0aGV5J3ZlIG1vc3Rs eSBiZWVuIGFkZHJlc3NlZCwNCj5idXQgZGlkIG5vdCByZWNoZWNrIHRoZW06DQo+DQo+LSAzLCBw YXJhZ3JhcGggNToNCj5TSE9VTEQgc2hvdWxkIG5vdCBiZSBlcXVhdGVkIHdpdGggIm9wdGlvbmFs IHRvIGltcGxlbWVudCIuIE1BWSBtZWFucw0KPnRoYXQuIFNIT1VMRCBpcyBpbnRlbmRlZCB0byBi ZSBzdHJvbmdlci4NCg0KQ2hhbmdlZCB0byBNQVkgaW4gIi0xMyIuDQoNCg0KPi0gNC41LCAybmQg cGFyYWdyYXBoLCAxc3Qgc2VudGVuY2U6DQo+VGhpcyBpcyBwcmV0dHkgY29udm9sdXRlZC4gSSBz dWdnZXN0IHJlZm9ybXVsYXRpbmcgd2l0aG91dCB0aGUgcGFzdCB0ZW5zZQ0KPiJNVVNUIi4gRm9y IGV4YW1wbGUsICJUaGUgZENOSSBNVVNUIHJlcG9ydCB0aGUgZXhwaXJhdGlvbiB0aW1lcyBpZi4u LiINCg0KQ2hhbmdlZCBpbiAiLTEzIi4NCg0KDQo+LTQuNjogIklmIENETnMgQiBhbmQgQyBkZWxl Z2F0ZSBkZWxpdmVyeSBvZiBDRE4gQeKAmXMgY29udGVudCB0byBlYWNoDQo+b3RoZXIiDQo+SXMg dGhpcyBhIHJlYXNvbmFibGUgY29uZmlndXJhdGlvbj8gSXQgc2VlbXMgbGlrZSB0aGV5IG1pZ2h0 IGFscmVhZHkgaGF2ZQ0KPmEgZGVsZWdhdGlvbiBsb29wIGJlZm9yZSB0aGUgdHJpZ2dlciBpbnRl cmZhY2UgZ290IGludm9sdmVkLg0KDQpJbiBodHRwOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJj aC9tc2cvY2RuaS9EN2JRTVFtQmhNdU1JZTFMNUVwYUgxbkM2c2sgSSByZXBsaWVkIC4uLg0KDQog IFBlcmhhcHMgaXQgY291bGQgaGFwcGVuIGlmIHR3byBDRE5zIHVzZSBlYWNoIG90aGVyIGZvciBl eHRyYQ0KICBDYXBhY2l0eSBkdXJpbmcgcGVyaW9kcyBvZiBoaWdoIGxvYWQuDQoNCiAgQnV0IGl0 J3MgY2VydGFpbmx5IG5vdCBhbiBpbXBvc3NpYmxlIGNvbmZpZ3VyYXRpb24uIFRoZSByZXF1ZXN0 DQogIHJvdXRpbmcgZHJhZnQgZGVhbHMgd2l0aCBsb29wcywgc28gaXQgc2VlbWVkIGJlc3QgdG8g ZG8gc28gaGVyZQ0KICBhcyB3ZWxsLg0KDQogIERvZXMgdGhhdCBoZWxwPyBBcmUgYW55IG1vZHMg b3IgZXhwbGFuYXRpb25zIG5lZWRlZCBpbiB0aGUgZHJhZnQ/DQoNCi4uLiBzbywgbm8gY2hhbmdl IGluIHRoZSBkcmFmdCB5ZXQuDQoNCg0KPkFsc28sIHRoZSBmaXJzdCBzZW50ZW5jZSBpcyBhIGZy YWdtZW50Lg0KDQpGaXhlZCBpbiAiLTEzIi4NCg0KDQo+PSA0LjgsIGZpcnN0IHBhcmFncmFwaDoN Cj5JIHN1Z2dlc3Qgcy90cmFuc2Zvcm0vInNpbWlsYXJseSB0cmFuc2Zvcm0iDQoNCkZpeGVkIGlu ICItMTMiLg0KDQoNCj4tIDUuMS4zLCBzdGFsZXJlc291cmNldGltZSwgbWFuZGF0b3J5Og0KPkRv ZXNuJ3QgdGhpcyBlZmZlY3RpdmVseSBtZWFuIHRoZSB2YWx1ZSBtdXN0IGJlIHRoZSBzYW1lIGFj cm9zcyBhbGwNCj5jb2xsZWN0aW9ucz8gDQoNCkluIGh0dHA6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9y Zy9hcmNoL21zZy9jZG5pL0Q3YlFNUW1CaE11TUllMUw1RXBhSDFuQzZzayBJIHJlcGxpZWQgLi4u DQoNCiAgWWVzLCBidXQgdGhlIGZpbHRlcmVkIGNvbGxlY3Rpb25zIGFyZSBkZXNjcmliZWQgYXMg ZmlsdGVyZWQgdmlld3MNCiAgb2YgdGhlIGNvbGxlY3Rpb24gb2YgYWxsIHRyaWdnZXJzLg0KDQog IEkgdGhpbmsgaXQnZCBiZSBvZGQgdG8gdXNlIGRpZmZlcmVudCB0aW1lcyBmb3IgdGhlIGZpbHRl cmVkDQogIGNvbGxlY3Rpb25zIChlc3BlY2lhbGx5IGxvbmdlciB0aW1lcykgYW5kIGEgbGl0dGxl IG1vcmUgZmlkZGx5DQogIHRvIGltcGxlbWVudC4gSSBkb24ndCB0aGluayB0aGVyZSdkIGJlIGFu eXRoaW5nIHRvIGdhaW4gZnJvbQ0KICB0aGUgZXh0cmEgZmxleGliaWxpdHk/DQoNCi4uLiBzbywg bm8gY2hhbmdlIGluIHRoZSBkcmFmdCB5ZXQuDQoNCg0KPi0gNS4yLjEsIGNvbnRlbnQuY2NpZDoN Cj5TZWVtcyBsaWtlIHRoZSByZWZlcmVuY2UgdG8gW0ktRC5pZXRmLWNkbmktbWV0YWRhdGFdIHNo b3VsZCBiZQ0KPm5vcm1hdGl2ZS4NCg0KTWFkZSBub3JtYXRpdmUgaW4gIi0xMyIuDQoNCg0KPi0g Ni4yLjU6DQo+aXQgbG9va3MgbGlrZSB0aGUgZENETiBpcyBzZW5kaW5nIHRoZSByZXF1ZXN0IHRv IGl0c2VsZi4gSXMgdGhhdCB0aGUNCj5pbnRlbnQ/DQoNClR5cG8sIGZpeGVkIGluICItMTMiLg0K DQoNCj4tIDguMSwgbGFzdCBwYXJhZ3JhcGg6ICJJbiB0aGlzIGNhc2UsIHRoZSBkQ0ROIE1VU1Qg YWxsb3cgZWFjaCB1Q0ROIGZyb20NCj53aGljaCB0aGUgY29udGVudCBjb3VsZCBoYXZlIGJlZW4g YWNxdWlyZWQgdG8gYWN0IHVwb24gdGhhdCBjb250ZW50IHVzaW5nDQo+Q0kvVCBDb21tYW5kcy4i DQo+VGhpcyBzZWVtcyBsaWtlIGEgcGxhY2Ugd2hlcmUgbG9jYWwgcG9saWN5IG1pZ2h0IHJlYXNv bmFibHkgdmFyeS4gSXMgYQ0KPk1VU1QgcmVhbGx5IGFwcHJvcHJpYXRlPw0KDQpJbiBodHRwOi8v bWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvY2RuaS9EN2JRTVFtQmhNdU1JZTFMNUVwYUgx bkM2c2sgSSByZXBsaWVkIC4uLg0KDQogIFRoYXQgbW92ZWQgdG8gc2VjdGlvbiAyLjIuMSBwYXJh IDQgaW4gIi0xMiIsIGFuZCBiZWNhbWUuLi4NCg0KICAgICJDSS9UIGNvbW1hbmRzIG9yaWdpbmF0 aW5nIGluIHRoZSBzaW5nbGUgc291cmNlIHVDRE4gYWZmZWN0IG1ldGFkYXRhDQogICAgYW5kIGNv bnRlbnQgaW4gYWxsIGRDRE5zIGJ1dCwgaW4gYSBkaWFtb25kIGNvbmZpZ3VyYXRpb24sIGl0IG1h eSBub3QNCiAgICBiZSBwb3NzaWJsZSBmb3IgdGhlIGRDRE4gdG8gZGV0ZXJtaW5lIHdoaWNoIHVD RE4gaXQgYWNxdWlyZWQgY29udGVudA0KICAgIGZyb20uIEluIHRoaXMgY2FzZSBhIGRDRE4gTVVT VCBhbGxvdyBlYWNoIHVDRE4gZnJvbSB3aGljaCBpdCBtYXkNCiAgICBoYXZlIGFjcXVpcmVkIHRo ZSBjb250ZW50IHRvIGFjdCB1cG9uIHRoYXQgY29udGVudCB1c2luZyBDSS9UIENvbW1hbmRzLiIN Cg0KICBJIHRoaW5rIGEgTVVTVCBpcyByaWdodCB0aG91Z2ggLi4uIGlmIGEgdUNETiB3YW50cyBp dHMgZGF0YSBnb25lLCBhbmQNCiAgdGhlIGRDRE4gdGhpbmtzIGl0IG1pZ2h0IGhhdmUgc29tZSBv ZiB0aGF0IGRhdGEsIGl0IGhhZCBiZXR0ZXIgZGVsZXRlDQogIGl0Lg0KDQogIFNvIEknZCBwcmVm ZXIgdG8gbGVhdmUgdGhlIE1VU1QsIGlzIHRoYXQgb2s/DQoNCi4uLiBzbywgbm8gY2hhbmdlIGlu IHRoZSBkcmFmdCB5ZXQuDQoNCj4NCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPkNETmkgbWFpbGluZyBsaXN0DQo+Q0ROaUBpZXRmLm9yZw0KPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2RuaQ0KDQo= From nobody Thu May 19 08:42: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 573AE12D101; Thu, 19 May 2016 08:42:38 -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 ZNiJvlTnKsyF; Thu, 19 May 2016 08:42:36 -0700 (PDT) Received: from mailex.mailcore.me (smtp.123-reg.co.uk [94.136.40.63]) by ietfa.amsl.com (Postfix) with ESMTP id F0EB112D16A; Thu, 19 May 2016 08:42:35 -0700 (PDT) Received: from 97e41b89.skybroadband.com ([151.228.27.137] helo=[192.168.0.4]) by smtp04.mailcore.me with esmtpa (Exim 4.80.1) (envelope-from ) id 1b3Q5p-0006Fq-Vw; Thu, 19 May 2016 16:42:34 +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: <573D19C3.3050304@cs.tcd.ie> Date: Thu, 19 May 2016 16:42:30 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160518223257.14733.37895.idtracker@ietfa.amsl.com> <3E2786B2-9204-447C-9A53-A3CB0213E0F5@niven-jenkins.co.uk> <573CFEC8.8010600@cs.tcd.ie> <5DED924E-C407-44E9-8FF1-477B26B69647@niven-jenkins.co.uk> <573D09D5.1020501@cs.tcd.ie> <573D19C3.3050304@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.2098) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Archived-At: Cc: Ben Campbell , draft-ietf-cdni-logging@ietf.org, The IESG , cdni@ietf.org, cdni-chairs@ietf.org Subject: Re: [CDNi] Ben Campbell's Discuss on draft-ietf-cdni-logging-25: (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, 19 May 2016 15:42:38 -0000 > On 19 May 2016, at 02:41, Stephen Farrell = wrote: >=20 > Cutting to (I think) the substantive bit... >=20 > On 19/05/16 02:11, Ben Niven-Jenkins wrote: >> My intention was to express my opinion that because the uCDN could >> have chosen to perform the content delivery itself the dCDN is not >> exposing any more information to the uCDN than the uCDN could have >> chosen to gather itself if it so desired and therefore IMO there is >> no need to provide different guidance for DNS redirection than for >> HTTP redirection. >=20 > Yes, I've seen arguments of that form offered a number of times. > I don't find it convincing myself, but recognise that other folks > do. And in every case so far, neither side has convinced the other, > and sometimes not even understood one another. But let's see if > we (me really:-) get better with practice... >=20 > In this case I'd argue that the "could have chosen" isn't really > true - presumably the uCDN deals with the dCDN because it's hard(er) > for the uCDN to do the work directly, so it's not really true that > the uCDN could have chosen to access the information, at least not > at the same cost. True, but there are lots of possibilities for why the uCDN would;t do it = itself or why it might those to do the content delivery itself if it was = so inclined, e.g. maybe if the uCDN is really interested in invading = user=E2=80=99s privacy, what it gains from that outweighs the additional = cost of performing the delivery itself. Who knows, I don=E2=80=99t think = we can try and account for all that variation. > And there may be aspects of meta-data that are just different because > the access was via the dCDN, e.g. perhaps some other client IP address > gets used if somethings multihomed, or some ISP infrastructure = differs, > e.g. HTTP Forwarded might be present and visible to the dCDN but with > no similar thing for DNS (or vice versa). I'd not be surprised if even > more subtle differences existed over populations of transactions and > users and CDNs. I=E2=80=99m sure there are all sort of things like you suggest above. = What is not at all clear to me is what specifically the logging draft is = meant to do about it. Ultimately it=E2=80=99s a tradeoff I think. I=E2=80=99m not sure we=E2=80=99= ll ever agree. I have nothing more to say that won=E2=80=99t end up just rehashing = discussions we=E2=80=99ve already had so I don=E2=80=99t intend on = participating in this thread any longer. Ben From nobody Thu May 19 08:50:40 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 4C7EC12D101; Thu, 19 May 2016 08:50:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 Rp3UVeuszsGD; Thu, 19 May 2016 08:50:36 -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 A410712D1E9; Thu, 19 May 2016 08:50:36 -0700 (PDT) Received: from [10.0.1.18] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u4JFoUlZ003229 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 19 May 2016 10:50:31 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.18] From: "Ben Campbell" To: "Murray, Rob" Date: Thu, 19 May 2016 10:50:29 -0500 Message-ID: <97765CDC-4AD1-44AD-B135-799E60CDB580@nostrum.com> In-Reply-To: References: <20160519145654.17290.50373.idtracker@ietfa.amsl.com> 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: "flefauch@cisco.com" , "cdni@ietf.org" , The IESG , "draft-ietf-cdni-control-triggers@ietf.org" , "cdni-chairs@ietf.org" Subject: Re: [CDNi] Ben Campbell's No Objection on draft-ietf-cdni-control-triggers-15: (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, 19 May 2016 15:50:38 -0000 On 19 May 2016, at 10:15, Murray, Rob (Nokia - GB) wrote: > Thanks Ben. > > I replied to these comments in > http://mailarchive.ietf.org/arch/msg/cdni/D7bQMQmBhMuMIe1L5EpaH1nC6sk, > and addressed most of them in "-13" of the draft. Hmm. Somehow I missed the more extended response to my offline cache question. The explanation makes sense. It might or might not be worth adding some text to the draft about it--I will leave that to the authors to respond. > > It'd be worth you checking you're happy with my other responses though > - repeated below. The rest of the points are fine--The bit about "old" comments should have been more to the effect of "These have been handled in email discussion; but I did not double-check them in the draft today". Thanks, Ben. > > Cheers, > Rob. > > > On 19/05/2016, 15:56, "CDNi on behalf of Ben Campbell" > wrote: > >> Ben Campbell has entered the following ballot position for >> draft-ietf-cdni-control-triggers-15: No Objection >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Thanks for handling my DISCUSS point related to the TLS requirement. >> I >> had one remaining DISCUSS point that I am not sure has been >> resolved--but >> after the conversation that did happen, it is probably no longer >> DISCUSS-worthy: >> >> - 4.7, 2nd bullet under handling of offline surrogates: >> >> I assume I am missing something here. How does a surrogate know that >> the >> situation exists in the first place? How would a surrogate know about >> invalidate commands that happened while it was offline? > > I replied in > https://mailarchive.ietf.org/arch/msg/cdni/nPz4CuJXuxk5dXhEP2n-gtcx7Ag > with ... > > A CDN implementation could decide to revalidate all of its content if > it's been offline, that'd work but it'd be a bit extreme. > > In our implementation, individual caches query for commands or config > changes they missed when they come online (before they start taking > traffic). > > The point is that it's an implementation decision ... from a > CDN-interconnect point-of-view it doesn't matter how the dCDN makes > sure it's not serving invalidated/deleted content, but there's a > requirement for it to do so somehow - which is what I was trying to > state in the draft. > > Once a CDN gets big enough, there's a fair chance that at least one > cache is offline at any given time for maintenance, because of > hardware or network failure, etc. So CDNs have to deal with individual > caches missing internal invalidate/purge commands, and should do the > same when interconnected. > > >> ------------- >> >> The remaining comments are old. I think they've mostly been >> addressed, >> but did not recheck them: >> >> - 3, paragraph 5: >> SHOULD should not be equated with "optional to implement". MAY means >> that. SHOULD is intended to be stronger. > > Changed to MAY in "-13". > > >> - 4.5, 2nd paragraph, 1st sentence: >> This is pretty convoluted. I suggest reformulating without the past >> tense >> "MUST". For example, "The dCNI MUST report the expiration times >> if..." > > Changed in "-13". > > >> -4.6: "If CDNs B and C delegate delivery of CDN A’s content to each >> other" >> Is this a reasonable configuration? It seems like they might already >> have >> a delegation loop before the trigger interface got involved. > > In > http://mailarchive.ietf.org/arch/msg/cdni/D7bQMQmBhMuMIe1L5EpaH1nC6sk > I replied ... > > Perhaps it could happen if two CDNs use each other for extra > Capacity during periods of high load. > > But it's certainly not an impossible configuration. The request > routing draft deals with loops, so it seemed best to do so here > as well. > > Does that help? Are any mods or explanations needed in the draft? > > ... so, no change in the draft yet. > > >> Also, the first sentence is a fragment. > > Fixed in "-13". > > >> = 4.8, first paragraph: >> I suggest s/transform/"similarly transform" > > Fixed in "-13". > > >> - 5.1.3, staleresourcetime, mandatory: >> Doesn't this effectively mean the value must be the same across all >> collections? > > In > http://mailarchive.ietf.org/arch/msg/cdni/D7bQMQmBhMuMIe1L5EpaH1nC6sk > I replied ... > > Yes, but the filtered collections are described as filtered views > of the collection of all triggers. > > I think it'd be odd to use different times for the filtered > collections (especially longer times) and a little more fiddly > to implement. I don't think there'd be anything to gain from > the extra flexibility? > > ... so, no change in the draft yet. > > >> - 5.2.1, content.ccid: >> Seems like the reference to [I-D.ietf-cdni-metadata] should be >> normative. > > Made normative in "-13". > > >> - 6.2.5: >> it looks like the dCDN is sending the request to itself. Is that the >> intent? > > Typo, fixed in "-13". > > >> - 8.1, last paragraph: "In this case, the dCDN MUST allow each uCDN >> from >> which the content could have been acquired to act upon that content >> using >> CI/T Commands." >> This seems like a place where local policy might reasonably vary. Is >> a >> MUST really appropriate? > > In > http://mailarchive.ietf.org/arch/msg/cdni/D7bQMQmBhMuMIe1L5EpaH1nC6sk > I replied ... > > That moved to section 2.2.1 para 4 in "-12", and became... > > "CI/T commands originating in the single source uCDN affect > metadata > and content in all dCDNs but, in a diamond configuration, it may > not > be possible for the dCDN to determine which uCDN it acquired > content > from. In this case a dCDN MUST allow each uCDN from which it may > have acquired the content to act upon that content using CI/T > Commands." > > I think a MUST is right though ... if a uCDN wants its data gone, > and > the dCDN thinks it might have some of that data, it had better > delete > it. > > So I'd prefer to leave the MUST, is that ok? > > ... so, no change in the draft yet. > >> >> >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni From nobody Fri May 20 07:00:46 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 D628812D13A for ; Fri, 20 May 2016 07:00:44 -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 (1024-bit key) header.d=fastmail.fm header.b=ltBHt8FS; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=QD8rRo4A 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 6qEEDrIgGUGR for ; Fri, 20 May 2016 07:00:43 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B03E312D0B9 for ; Fri, 20 May 2016 07:00:43 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 16D2B20B1E for ; Fri, 20 May 2016 10:00:43 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute6.internal (MEProxy); Fri, 20 May 2016 10:00:43 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=tqb rw68ayHufdwSTdMiscJCkhOw=; b=ltBHt8FSzEhZG3fPyGhy90bDh+UBTKOfDUG 2bb7+RgeRS+Y9IJk4gvadzlsFdCpGp543ejGQpHKXTp7r2CFarnnQuojCfxL09Ka GplCg/ZDmo0/u3xjNcXtVuiasbwYMmZadC1osAVmmn53Wd3XU/sFV5ytr73UdZdc HFc4AzV4= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=tqbrw68ayHufdwSTdMiscJCkhOw=; b=QD8rR o4AvDwf2OjdjAMzb6OUc/hCem1kaHHbUED3vgqKrZSSA/zFo/OyO1mAjoh3eRgr7 PFp8qdm+F/YvtU6w7JiCWlf8HOefbWplCsAgsgQWzLcs2P2BwWkwBidcsUAL1hiw RSmJTAVa5pTYbFW+Jagnkgs6bleao0QCqA75Fs= Received: by web5.nyi.internal (Postfix, from userid 99) id E5C37A644A5; Fri, 20 May 2016 10:00:42 -0400 (EDT) Message-Id: <1463752842.3957746.613766209.00113288@webmail.messagingengine.com> X-Sasl-Enc: FxOzj+Y3b8TA4MNAl7134A+3/xsPO9N3i2mUrOoMxCVi 1463752842 From: Alexey Melnikov To: cdni@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-37b57599 Date: Fri, 20 May 2016 15:00:42 +0100 Archived-At: Subject: [CDNi] Protocol names in draft-ietf-cdni-footprint-capabilities-semantics-19 and draft-ietf-cdni-metadata 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, 20 May 2016 14:00:45 -0000 Hi, This is a minor point, but I am wondering if it is better to change protocol names from "http1.1" and "https1.1" to "http/1.1" and "https/1.1" in both documents? I think consistency with how http is referenced elsewhere (e.g. the version number in HTTP itself) would be a plus. Thoughts? Best Regards, Alexey From nobody Fri May 20 07:16:40 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 EFF3F12D9A6 for ; Fri, 20 May 2016 07:16:38 -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 zqVnc9z_WjQx for ; Fri, 20 May 2016 07:16:37 -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 78A2112D132 for ; Fri, 20 May 2016 07:16:37 -0700 (PDT) X-AuditID: c6180641-f796f6d000000e1e-af-573f1c11e2ff Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 37.A2.03614.11C1F375; Fri, 20 May 2016 16:15:45 +0200 (CEST) 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, 20 May 2016 10:06:49 -0400 From: Kevin Ma J To: Alexey Melnikov , "cdni@ietf.org" Thread-Topic: [CDNi] Protocol names in draft-ietf-cdni-footprint-capabilities-semantics-19 and draft-ietf-cdni-metadata Thread-Index: AQHRsqAGfH5tn5FUU0SHcdSx+QJOyZ/B3DfQ Date: Fri, 20 May 2016 14:06:49 +0000 Message-ID: References: <1463752842.3957746.613766209.00113288@webmail.messagingengine.com> In-Reply-To: <1463752842.3957746.613766209.00113288@webmail.messagingengine.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+NgFnrPLMWRmVeSWpSXmKPExsUyuXRPuK6gjH24wbrF6hb73x9isng6+w+r A5PHzlMH2DyWLPnJFMAUxWWTkpqTWZZapG+XwJVx/dVu9oK/bBWr/z1ga2C8ytrFyMkhIWAi 0fpzKSOELSZx4d56ti5GLg4hgaOMEgd3bwArEhJYzijRekoExGYT0JJ4/PUvE4gtIuArsXrR P7AaYYEqic5F01kh4tUSW468ZIewjSROXtwFFmcRUJV4+raFGcTmBeptPdwDNd9fYnNnO9hM ToEAibcvjoEdxAh00PdTa8DizALiEreezGeCOFRAYsme88wQtqjEy8f/oJ5Rkpjz+hozRL2O xILdn9ggbG2JZQtfQ+0VlDg58wnLBEbRWUjGzkLSMgtJyywkLQsYWVYxcpQWF+TkphsZbmIE RsMxCTbHHYx7ez0PMQpwMCrx8C7ItwsXYk0sK67MPcQowcGsJMJ7RMo+XIg3JbGyKrUoP76o NCe1+BCjNAeLkjiv/kvFcCGB9MSS1OzU1ILUIpgsEwenVANjfCyf4uSX3373Obn8k9qm3LtO avW/HSdV18iZK18I+FjTePD7gkM7HI8w7Jynqi9gPrf7jqLN3hv97xf/vjT1772q+7lGrEnT 43w44xneh7YpZd583rV61cSkeSZ/lwqc2LGDUz/mnnvFrWC7rdanWee9MXtnuG6djYfaUp1H aSHhBsHppycyKbEUZyQaajEXFScCAES+x0aCAgAA Archived-At: Subject: Re: [CDNi] Protocol names in draft-ietf-cdni-footprint-capabilities-semantics-19 and draft-ietf-cdni-metadata 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, 20 May 2016 14:16:39 -0000 Hi Alexey, As an author, I do not have an issue with adding the slash. thanx. -- Kevin J. Ma > -----Original Message----- > From: CDNi [mailto:cdni-bounces@ietf.org] On Behalf Of Alexey Melnikov > Sent: Friday, May 20, 2016 10:01 AM > To: cdni@ietf.org > Subject: [CDNi] Protocol names in draft-ietf-cdni-footprint-capabilities- > semantics-19 and draft-ietf-cdni-metadata >=20 > Hi, > This is a minor point, but I am wondering if it is better to change > protocol names from "http1.1" and "https1.1" to "http/1.1" and > "https/1.1" in both documents? I think consistency with how http is > referenced elsewhere (e.g. the version number in HTTP itself) would be a > plus. >=20 > Thoughts? >=20 > Best Regards, > Alexey >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From nobody Fri May 20 13:17: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 8D02812D53F; Fri, 20 May 2016 13:17:15 -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 AzHqxNGLphNW; Fri, 20 May 2016 13:17:13 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::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 B5B7712D161; Fri, 20 May 2016 13:17:13 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id x194so119949723ywd.0; Fri, 20 May 2016 13:17:13 -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=qFCTPWQlBPhm0SM+w/FBr0YtdZuf6Jg2nx+MT/tcATw=; b=f+G3kTZR0g0k8VWuvpIBPDDdwWv9VOYaaB8rxauh3O7YZbneFc3F5nAGhaAAMKZWI4 I8XMpzuXSLpRpOWixA57pyqGrTRkuEqoTpNeuj3Os/MXeVrSaE2k5/cbzHBLSFS/ri5N zj8iB77IhmMWhgZ3rSAdIM0DzUjxRIjXUYsfq080vQ7bgoS8uA/vaHoMcxB1lYik7jFw mKleg904AVzsLlZM8uYFVCtMGqZERa8x5/Shbb6Se/i4uasqr70mL7IcfNeuOB4cNW/Y qhomhBh7I9ZiSYj5An0XhKW74k2SlXfQPvgMT/C8w9oGlKzWHY/Z+FLOZaC+FWYWj0Nr Nk1Q== 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=qFCTPWQlBPhm0SM+w/FBr0YtdZuf6Jg2nx+MT/tcATw=; b=CPyutVMc519jB6r1Tfbfeb5FjLegm08SiPavBQXr9YsB8JhHDBQYkg2LmFl5XWBhLD xJD6p7ZGAMN+gpOC+6e2ZIMe6IIUUSq24R2djVvN1cF6n3sQrgX4u/KwVmuK914jZyU7 U/CjdidRrA+/2AYHhhFKwHU/WjRNfrTE7RIqATpmTrOgDmhshd/mVqzQhoZ7gV1/Cs8Q hi80fGngk9/c3ticId6DuhR6EUg0USlh7Lbqf15S/F7IaCAGGY2tZOM6oGMBMIcqqtv3 M3kVuHXsD2zvW3AWmAcfv3VxiiSotG/r4LQv552fiox/DHHRQ2+cz8uYwfg/o6FYtO+/ vnrg== X-Gm-Message-State: AOPr4FUJK8sV8qNX4JB9Qi9BG6fqrtRfg0Z7B48fm3CTd3kwIjzrCLl6pTN1p3dU/p76a+hsgPYFeCDlSLVafg== MIME-Version: 1.0 X-Received: by 10.13.226.149 with SMTP id l143mr3125819ywe.294.1463775433002; Fri, 20 May 2016 13:17:13 -0700 (PDT) Received: by 10.37.218.11 with HTTP; Fri, 20 May 2016 13:17:12 -0700 (PDT) In-Reply-To: <20160517135357.22221.45082.idtracker@ietfa.amsl.com> References: <20160517135357.22221.45082.idtracker@ietfa.amsl.com> Date: Fri, 20 May 2016 15:17:12 -0500 Message-ID: From: Spencer Dawkins at IETF To: Mirja Kuehlewind Content-Type: multipart/alternative; boundary=001a114fbd06b716d205334bc646 Archived-At: Cc: "cdni-chairs@ietf.org" , "draft-ietf-cdni-logging@ietf.org" , The IESG , "" Subject: Re: [CDNi] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-cdni-logging-25=3A_=28with_COMMENT=29?= 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, 20 May 2016 20:17:15 -0000 --001a114fbd06b716d205334bc646 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Authors/Shepherd, On Tue, May 17, 2016 at 8:53 AM, Mirja Kuehlewind wrote: > Mirja K=C3=BChlewind has entered the following ballot position for > draft-ietf-cdni-logging-25: 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: > ---------------------------------------------------------------------- > > I still agree to the privacy concerns that have been raised earlier by > Richard Barnes but don't see a solution that would justify a "DISCUSS" to > hold up the document. For this one, it's difficult for new ADs to follow the trail of Richard's Discuss without microscopic examination of the History tab in the datatracker(*), but Richard's Discuss was taken over by Stephen, and considerable discussion ensued over multiple IETF meeting cycles. If Stephen thinks things have improved sufficiently to clear, I'm reluctant to push for further changes in that space. (*) It was challenging for me to follow, and I was on the e-mail threads from earlier versions of Stephen's ballot position, which new ADs don't see because they weren't on the IESG at the time. > Further I think it's important that TLS is mandatory and it could be > useful to already state this earlier in the doc and not only Section 7. > I don't think I've seen a response to Mirja's comment here. Could you folks take a look at that? It seems straightforward. Thanks, Spencer --001a114fbd06b716d205334bc646 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Authors/Shepherd,

On Tue, May 17, 2016 at 8:53 AM, Mirja Kuehlewind <ietf@kuehlewind.net> wrote:
https://www.ietf.org/iesg/s= tatement/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-ie= tf-cdni-logging/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I still agree to the privacy concerns that have been raised earlier by
Richard Barnes but don't see a solution that would justify a "DISC= USS" to
hold up the document.

For this one, it'= s difficult for new ADs to follow the trail of Richard's Discuss withou= t microscopic examination of the History tab in the datatracker(*), but Ric= hard's Discuss was taken over by Stephen, and considerable discussion e= nsued over multiple IETF meeting cycles. If Stephen thinks things have impr= oved sufficiently to clear, I'm reluctant to push for further changes i= n that space.

(*) It was challenging for me to fol= low, and I was on the e-mail threads from earlier versions of Stephen's= ballot position, which new ADs don't see because they weren't on t= he IESG at the time.
=C2=A0
F= urther I think it's important that TLS is mandatory and it could be
useful to already state this earlier in the doc and not only Section 7.
=

I don't think I've seen a response= to Mirja's comment here. Could you folks take a look at that? It seems= straightforward.

Thanks,

Spencer=C2=A0
--001a114fbd06b716d205334bc646-- From nobody Fri May 20 13:20:51 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 220DF12D53B; Fri, 20 May 2016 13:20:50 -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 68oNrPxL8NJZ; Fri, 20 May 2016 13:20:48 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::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 AB4F012D161; Fri, 20 May 2016 13:20:48 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id o16so2291766ywd.2; Fri, 20 May 2016 13:20:48 -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=fiIWII8XAD+JC8dgI649OR81YcyuhvhXYIEy30g2r7I=; b=Q1UI1K70yjeKm2QGIPKYuvVDsos5kJPs7IoHWDJViBbYnahrCOGwuvYQD5cOQXngoe FPiuepoivTigF9UWhpCJbLYQ2NeXyopFaU39LeBF2urRfLSRj4OvG51Em778mT/Y4IYu KSJHI3+Tn7JL78tEbDyZ93ylWoTu/w3v73IThQoHclOwUNZUDDMILYJh4WiiCqHuxAFT Py2w/ArRrB4QPyPu6duNbUXLu8jirSEh3OVuGo9q2OR6iUTvKxV8i3XAB6wxc7t2cLvp EYxVxfRm1b2umFib8Pq0LjjPkQmPDOkRa77L+nv8Zk4Nq06TPj1G1bSyPVUrICMVfIu8 yOhg== 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=fiIWII8XAD+JC8dgI649OR81YcyuhvhXYIEy30g2r7I=; b=en//nf6FhKOUWHNpPULlN4nErQQnWoWSLYooFvFWjSjMP7ZTmmUB/5aOnbq8ZKogVL WZJxT+NKTDmd+detP60pv7+eiQSX7zOkiVqAyJJPAkAYUI7olB2iPVd/FzssGXuZ5iUh dbTGveibCeiBAKBly/cC5efHeHnlLX/CkGj/AKUmvZ3Z1PXoTTcnB2hYKIZ2q4+xgdEZ d5eRwtNm20zzfJ9a6t4M8paI/ZmANlrLHp7aEIaWqNr+1q2ey26BycgDBhckqYkB1Thv VD+U18EAv/2tAAnyiASyhdNU8bgDsOKU3Jtx6MvW5YPNnCKgz098TPlByYAH8tbUhMUq ID0w== X-Gm-Message-State: AOPr4FUOFlkAdUd012d7yMy/MDpGeWp0oUIoVh/26wNNgkqfsADF0AgFMvc8ybCm0U0e1qUUCyhQehVEt1ruwg== MIME-Version: 1.0 X-Received: by 10.13.226.149 with SMTP id l143mr3133995ywe.294.1463775647984; Fri, 20 May 2016 13:20:47 -0700 (PDT) Received: by 10.37.218.11 with HTTP; Fri, 20 May 2016 13:20:47 -0700 (PDT) In-Reply-To: <20160518134030.14641.52615.idtracker@ietfa.amsl.com> References: <20160518134030.14641.52615.idtracker@ietfa.amsl.com> Date: Fri, 20 May 2016 15:20:47 -0500 Message-ID: From: Spencer Dawkins at IETF To: Alexey Melnikov Content-Type: multipart/alternative; boundary=001a114fbd068774e005334bd35a Archived-At: Cc: "cdni-chairs@ietf.org" , "draft-ietf-cdni-logging@ietf.org" , The IESG , "" Subject: Re: [CDNi] Alexey Melnikov's Discuss on draft-ietf-cdni-logging-25: (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, 20 May 2016 20:20:50 -0000 --001a114fbd068774e005334bd35a Content-Type: text/plain; charset=UTF-8 Dear Authors, On Wed, May 18, 2016 at 8:40 AM, Alexey Melnikov wrote: > Alexey Melnikov has entered the following ballot position for > draft-ietf-cdni-logging-25: 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 know this document has long history and I want to get it done as well. > Below is a list of small issues that I think need to be addressed: > > Is version directive value case-insensitive? The IANA registration is in > lowercase, but all examples show uppercase. > > On page 28: SHA-3, AES-GCM and base64 all need normative references. > > (Use "Section 4 of [RFC4648]" for base64, as RFC 4648 defines 2 base54 > encodings). > > On page 33: where does the "missing field value is denoted by -" > specified in ABNF? If this is not defined in ABNF, it would be good to > have an example record with a field missing. > I haven't seen a response to Alexey's ballot yet - did I miss it? The Discuss seems pretty straightforward. Please let me know if you need help absorbing it. Thanks, Spencer > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > In 7.1, last sentence: TLS only provides for protection from tampering > when in transit, not when a log file being stored. > > > --001a114fbd068774e005334bd35a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Authors,

On Wed, May 18, 2016 at 8:40 AM, Alexey Melnikov <aameln= ikov@fastmail.fm> wrote:
Al= exey Melnikov has entered the following ballot position for
draft-ietf-cdni-logging-25: 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/s= tatement/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-ie= tf-cdni-logging/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I know this document has long history and I want to get it done as well. Below is a list of small issues that I think need to be addressed:

Is version directive value case-insensitive? The IANA registration is in lowercase, but all examples show uppercase.

On page 28: SHA-3, AES-GCM and base64 all need normative references.

(Use "Section 4 of [RFC4648]" for base64, as RFC 4648 defines 2 b= ase54
encodings).

On page 33: where does the "missing field value is denoted by -"<= br> specified in ABNF? If this is not defined in ABNF, it would be good to
have an example record with a field missing.

I haven't seen a response to Alexey's ballot yet - did I miss= it?=C2=A0

The Discuss seems pretty straightforwar= d. Please let me know if you need help absorbing it.

Thanks,

Spencer
=C2=A0


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

In 7.1, last sentence: TLS only provides for protection from tampering
when in transit, not when a log file being stored.



--001a114fbd068774e005334bd35a-- From nobody Fri May 20 13:23:12 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 4BC8712D62B for ; Fri, 20 May 2016 13:23:10 -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 iOka0KKPY6U6 for ; Fri, 20 May 2016 13:23:08 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.143]) by ietfa.amsl.com (Postfix) with ESMTP id 4512212D627 for ; Fri, 20 May 2016 13:23:07 -0700 (PDT) Received: from 82-132-240-65.dab.02.net ([82.132.240.65] helo=[10.1.39.26]) by smtp04.mailcore.me with esmtpa (Exim 4.80.1) (envelope-from ) id 1b3qwr-0000bu-Vz; Fri, 20 May 2016 21:23:06 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Ben Niven-Jenkins X-Mailer: iPhone Mail (13C75) In-Reply-To: Date: Fri, 20 May 2016 21:23:00 +0100 Content-Transfer-Encoding: 7bit Message-Id: <68CA6DB7-84A8-4AE2-9B47-96DF0F7335C1@niven-jenkins.co.uk> References: <1463752842.3957746.613766209.00113288@webmail.messagingengine.com> To: Kevin Ma J X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Archived-At: Cc: "cdni@ietf.org" Subject: Re: [CDNi] Protocol names in draft-ietf-cdni-footprint-capabilities-semantics-19 and draft-ietf-cdni-metadata 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, 20 May 2016 20:23:10 -0000 It's fine with me too. Ben > On 20 May 2016, at 15:06, Kevin Ma J wrote: > > Hi Alexey, > > As an author, I do not have an issue with adding the slash. > > thanx. > > -- Kevin J. Ma > >> -----Original Message----- >> From: CDNi [mailto:cdni-bounces@ietf.org] On Behalf Of Alexey Melnikov >> Sent: Friday, May 20, 2016 10:01 AM >> To: cdni@ietf.org >> Subject: [CDNi] Protocol names in draft-ietf-cdni-footprint-capabilities- >> semantics-19 and draft-ietf-cdni-metadata >> >> Hi, >> This is a minor point, but I am wondering if it is better to change >> protocol names from "http1.1" and "https1.1" to "http/1.1" and >> "https/1.1" in both documents? I think consistency with how http is >> referenced elsewhere (e.g. the version number in HTTP itself) would be a >> plus. >> >> Thoughts? >> >> Best Regards, >> Alexey >> >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni > > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From nobody Fri May 20 13:29:40 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 3697C12D632; Fri, 20 May 2016 13:29:33 -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 IkDkHxNaB2ir; Fri, 20 May 2016 13:29:31 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (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 5EB6912D62B; Fri, 20 May 2016 13:29:31 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id x194so120236024ywd.0; Fri, 20 May 2016 13:29:31 -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=s5PAr4MQ1/c6WMySCpJQ+ks8UCkrXxjCQoMprp5u1lg=; b=tr/X28j/zJqSJXJj1QUUAHeNwxiOBP91MjxHADWZmqCsa4GBLzLr8V2KqX3RX1kjwe iMl7aZr7XUFVCQZML9vjphNMLOA2lgfoAoq9yYDu7EH6g2jLbNPTzQYij8/T5kdDZMKw pTA9yOpX9skq8kE5IrdpW0tg40997Buwu9LmG1bYC6cud263CWEslSSoPEH9OxSZphzR X46LlYe83fhmLjK4ca166EpZHosjjtzD+0/fuk6WEjsFso22eLVfYUDeectUO82CfTDS mXlEyA3PuMFiZLQWu3RGF3VFkVRKbO2DjqxgiVlmfrzinEGmKxkcG1mzPN0cfSXjC5nS azWA== 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=s5PAr4MQ1/c6WMySCpJQ+ks8UCkrXxjCQoMprp5u1lg=; b=aM9MYpWrm4+SGHLL2+rlg+88CpXY0i2TFeKK6C8fvVPR4dQWBZMilg2WeKi3BjlhyL /1KsnHMYIf/bZvUXhj05py8eL9klF1rdTxfW0V3O6AKmRQIFP5H4845NB/95tsJzaWOj tjzuhPjbFHqyjT18RHAoZnNtOxN2dbC0eKVmAvNv9TAhlHGKGc3KFKo9DoZFMQlNUpQE SwQE3ZnJ6QUaEyMT4hmHYhfjxQGQ1siACOMQYKl/r+RVmrN36hcFIHffAwy4OwDLjPXd T3q3mtrhS9B/hXVpp+nxS+NGaXDsDi6CkDQSmlbytd9yupNXbTdffuqCKWgrO6zfvEOs lZEg== X-Gm-Message-State: AOPr4FWap1nfDtE8PZdugkPcEhOGf4ve/y5HsGUV+GVfyu6Uw6Va7HBa0e5af/1T6DpmdRN+m/4BDBBgpzYkBg== MIME-Version: 1.0 X-Received: by 10.129.85.81 with SMTP id j78mr3084000ywb.157.1463776170498; Fri, 20 May 2016 13:29:30 -0700 (PDT) Received: by 10.37.218.11 with HTTP; Fri, 20 May 2016 13:29:30 -0700 (PDT) In-Reply-To: References: <20160518223257.14733.37895.idtracker@ietfa.amsl.com> <3E2786B2-9204-447C-9A53-A3CB0213E0F5@niven-jenkins.co.uk> <573CFEC8.8010600@cs.tcd.ie> <5DED924E-C407-44E9-8FF1-477B26B69647@niven-jenkins.co.uk> <573D09D5.1020501@cs.tcd.ie> <573D19C3.3050304@cs.tcd.ie> Date: Fri, 20 May 2016 15:29:30 -0500 Message-ID: From: Spencer Dawkins at IETF To: Ben Niven-Jenkins Content-Type: multipart/alternative; boundary=001a113f1788ac641d05334bf21f Archived-At: Cc: Ben Campbell , "" , "cdni-chairs@ietf.org" , The IESG , "draft-ietf-cdni-logging@ietf.org" , Stephen Farrell Subject: Re: [CDNi] Ben Campbell's Discuss on draft-ietf-cdni-logging-25: (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, 20 May 2016 20:29:33 -0000 --001a113f1788ac641d05334bf21f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Authors, I've seen a robust exchange between Ben Niven-Jenkins, Ben Campbell, and Stephen Farrell, but haven't seen a response from the authors. Could you let me know if you need any help absorbing Ben's ballot position? Thanks! Spencer On Thu, May 19, 2016 at 10:42 AM, Ben Niven-Jenkins wrote: > > > On 19 May 2016, at 02:41, Stephen Farrell > wrote: > > > > Cutting to (I think) the substantive bit... > > > > On 19/05/16 02:11, Ben Niven-Jenkins wrote: > >> My intention was to express my opinion that because the uCDN could > >> have chosen to perform the content delivery itself the dCDN is not > >> exposing any more information to the uCDN than the uCDN could have > >> chosen to gather itself if it so desired and therefore IMO there is > >> no need to provide different guidance for DNS redirection than for > >> HTTP redirection. > > > > Yes, I've seen arguments of that form offered a number of times. > > I don't find it convincing myself, but recognise that other folks > > do. And in every case so far, neither side has convinced the other, > > and sometimes not even understood one another. But let's see if > > we (me really:-) get better with practice... > > > > In this case I'd argue that the "could have chosen" isn't really > > true - presumably the uCDN deals with the dCDN because it's hard(er) > > for the uCDN to do the work directly, so it's not really true that > > the uCDN could have chosen to access the information, at least not > > at the same cost. > > True, but there are lots of possibilities for why the uCDN would;t do it > itself or why it might those to do the content delivery itself if it was = so > inclined, e.g. maybe if the uCDN is really interested in invading user=E2= =80=99s > privacy, what it gains from that outweighs the additional cost of > performing the delivery itself. Who knows, I don=E2=80=99t think we can t= ry and > account for all that variation. > > > And there may be aspects of meta-data that are just different because > > the access was via the dCDN, e.g. perhaps some other client IP address > > gets used if somethings multihomed, or some ISP infrastructure differs, > > e.g. HTTP Forwarded might be present and visible to the dCDN but with > > no similar thing for DNS (or vice versa). I'd not be surprised if even > > more subtle differences existed over populations of transactions and > > users and CDNs. > > I=E2=80=99m sure there are all sort of things like you suggest above. Wha= t is not > at all clear to me is what specifically the logging draft is meant to do > about it. > > Ultimately it=E2=80=99s a tradeoff I think. I=E2=80=99m not sure we=E2=80= =99ll ever agree. > > I have nothing more to say that won=E2=80=99t end up just rehashing discu= ssions > we=E2=80=99ve already had so I don=E2=80=99t intend on participating in t= his thread any > longer. > > Ben > > --001a113f1788ac641d05334bf21f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Authors,

I've seen a robust ex= change between Ben Niven-Jenkins, Ben Campbell, and Stephen Farrell, but ha= ven't seen a response from the authors. Could you let me know if you ne= ed any help absorbing Ben's ballot position?

T= hanks!

Spencer

<= div class=3D"gmail_quote">On Thu, May 19, 2016 at 10:42 AM, Ben Niven-Jenki= ns <ben@niven-jenkins.co.uk> wrote:

> On 19 May 2016, at 02:41, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
>
> Cutting to (I think) the substantive bit...
>
> On 19/05/16 02:11, Ben Niven-Jenkins wrote:
>> My intention was to express my opinion that because the uCDN could=
>> have chosen to perform the content delivery itself the dCDN is not=
>> exposing any more information to the uCDN than the uCDN could have=
>> chosen to gather itself if it so desired and therefore IMO there i= s
>> no need to provide different guidance for DNS redirection than for=
>> HTTP redirection.
>
> Yes, I've seen arguments of that form offered a number of times. > I don't find it convincing myself, but recognise that other folks<= br> > do. And in every case so far, neither side has convinced the other, > and sometimes not even understood one another. But let's see if > we (me really:-) get better with practice...
>
> In this case I'd argue that the "could have chosen" isn&= #39;t really
> true - presumably the uCDN deals with the dCDN because it's hard(e= r)
> for the uCDN to do the work directly, so it's not really true that=
> the uCDN could have chosen to access the information, at least not
> at the same cost.

True, but there are lots of possibilities for why the uCDN would;t d= o it itself or why it might those to do the content delivery itself if it w= as so inclined, e.g. maybe if the uCDN is really interested in invading use= r=E2=80=99s privacy, what it gains from that outweighs the additional cost = of performing the delivery itself. Who knows, I don=E2=80=99t think we can = try and account for all that variation.

> And there may be aspects of meta-data that are just different because<= br> > the access was via the dCDN, e.g. perhaps some other client IP address=
> gets used if somethings multihomed, or some ISP infrastructure differs= ,
> e.g. HTTP Forwarded might be present and visible to the dCDN but with<= br> > no similar thing for DNS (or vice versa). I'd not be surprised if = even
> more subtle differences existed over populations of transactions and > users and CDNs.

I=E2=80=99m sure there are all sort of things like you suggest above= . What is not at all clear to me is what specifically the logging draft is = meant to do about it.

Ultimately it=E2=80=99s a tradeoff I think. I=E2=80=99m not sure we=E2=80= =99ll ever agree.

I have nothing more to say that won=E2=80=99t end up just rehashing discuss= ions we=E2=80=99ve already had so I don=E2=80=99t intend on participating i= n this thread any longer.

Ben


--001a113f1788ac641d05334bf21f-- From nobody Fri May 20 14:01:29 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 B7FDA12D64E; Fri, 20 May 2016 14:01: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.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160520210126.306.86793.idtracker@ietfa.amsl.com> Date: Fri, 20 May 2016 14:01:26 -0700 Archived-At: Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-footprint-capabilities-semantics-20.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, 20 May 2016 21:01: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 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-20.txt Pages : 27 Date : 2016-05-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. 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-20 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-footprint-capabilities-semantics-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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 20 14:03:10 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 9A33E12D642; Fri, 20 May 2016 14:03:07 -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.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160520210307.336.17220.idtracker@ietfa.amsl.com> Date: Fri, 20 May 2016 14:03:07 -0700 Archived-At: Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-metadata-17.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, 20 May 2016 21:03:07 -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-17.txt Pages : 62 Date : 2016-05-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. 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-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-metadata-17 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 May 20 14:05:35 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 649B712D65C for ; Fri, 20 May 2016 14:05:34 -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 o1yBAbEGMLrV for ; Fri, 20 May 2016 14:05: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 8DC6912D65A for ; Fri, 20 May 2016 14:05:32 -0700 (PDT) X-AuditID: c618062d-f79886d000002334-ab-573f73c12c1b Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 0B.F9.09012.1C37F375; Fri, 20 May 2016 22:29:53 +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; Fri, 20 May 2016 17:05:31 -0400 From: Kevin Ma J To: "cdni@ietf.org" Thread-Topic: [CDNi] I-D Action: draft-ietf-cdni-footprint-capabilities-semantics-20.txt Thread-Index: AQHRstra1AVo6xinmUSzYwG45VTe3Z/CULYQ Date: Fri, 20 May 2016 21:05:31 +0000 Message-ID: References: <20160520210126.306.86793.idtracker@ietfa.amsl.com> In-Reply-To: <20160520210126.306.86793.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+NgFnrELMWRmVeSWpSXmKPExsUyuXRPlO7BYvtwgzPfpSyezv7D6sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujLdtnxgLVotUbF73ia2B8Rx/FyMnh4SAicTLO6+ZIGwxiQv3 1rN1MXJxCAkcZZSYsrqbGcJZzijRd/M6WBWbgJbE469/gWwODhEBZYmfhxxBwsICkRIPHv2H CkdJNPwuAgmLCBhJHFk0F6yTRUBVouHIaxaQEl4BX4nHXeogppCAvcSEU+IgFZwCDhLPF81i BrEZga75fmoNWCezgLjErSfzoa4UkFiy5zwzhC0q8fLxP1YIW0li0tJzrBD1OhILdn9ig7C1 JZYtfA1WzysgKHFy5hOWCYyis5CMnYWkZRaSlllIWhYwsqxi5CgtLsjJTTcy2MQIDPljEmy6 OxjvT/c8xCjAwajEw5tgbhcuxJpYVlyZe4hRgoNZSYQ3u9w+XIg3JbGyKrUoP76oNCe1+BCj NAeLkjiv2CPFcCGB9MSS1OzU1ILUIpgsEwenVAPjwknfTrSbMfnM2cUpfEw1m3nepQo+r7Oh D5QM7gUoKl4U2Pk9ssrwcHDj+UXum9jlV0it/1grsK1e9rP6B5t5le3mxn8FXBNPRp3d91Wo k+WuY9SlA7o1ihv2zY/6sH2GBAtzoqfi1O0W/9oSfUWmMMzoep3XpKfu2b6AzTmak/eI5Y+z U94psRRnJBpqMRcVJwIA2Ew43nUCAAA= Archived-At: Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-footprint-capabilities-semantics-20.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, 20 May 2016 21:05:34 -0000 Hi All, This update changes "http1.1" and "https1.1" to "http/1.1" and "https/1.1= ", respectively, per Alexey's comment. thanx. -- Kevin J. Ma > -----Original Message----- > From: CDNi [mailto:cdni-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Friday, May 20, 2016 5:01 PM > To: i-d-announce@ietf.org > Cc: cdni@ietf.org > Subject: [CDNi] I-D Action: draft-ietf-cdni-footprint-capabilities- > semantics-20.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- > 20.txt > Pages : 27 > Date : 2016-05-20 >=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-20 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-footprint-capabilitie= s- > semantics-20 >=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 Fri May 20 14:05: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 619ED12D65A for ; Fri, 20 May 2016 14:05: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 eavxt_d9I9V7 for ; Fri, 20 May 2016 14:05: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 40F9912D0BF for ; Fri, 20 May 2016 14:05:34 -0700 (PDT) X-AuditID: c6180641-f796f6d000000e1e-5c-573f7bead7fe Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 2C.A9.03614.AEB7F375; Fri, 20 May 2016 23:04:42 +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; Fri, 20 May 2016 17:05:32 -0400 From: Kevin Ma J To: "cdni@ietf.org" Thread-Topic: [CDNi] I-D Action: draft-ietf-cdni-metadata-17.txt Thread-Index: AQHRstsT1d7yXEav60WoXT+q6OcFxp/CUPug Date: Fri, 20 May 2016 21:05:32 +0000 Message-ID: References: <20160520210307.336.17220.idtracker@ietfa.amsl.com> In-Reply-To: <20160520210307.336.17220.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+NgFnrMLMWRmVeSWpSXmKPExsUyuXRPgu6ravtwg5Z9khZPZ/9hdWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxvcDK9kLlglVXNz2grGBsYuvi5GTQ0LARGJ7zzImCFtM4sK9 9WxdjFwcQgJHGSVWnZvAAuEsZ5R437qZHaSKTUBL4vHXv0AdHBwiAsoSPw85goSFBewlrh9u ZoUIO0jMvFYBEhYRMJK4u/U7WDWLgKrE0ovqIGFeAV+Jw723GUFsIaDOQ4u3sYLYnECdLZMm gp3DCHTO91NrwGxmAXGJW0/mQ50pILFkz3lmCFtU4uXjf6wQtpLEpKXnWCHqdSQW7P7EBmFr Syxb+JoZYq+gxMmZT1gmMIrOQjJ2FpKWWUhaZiFpWcDIsoqRo7S4ICc33chwEyMw6I9JsDnu YNzb63mIUYCDUYmHd0G+XbgQa2JZcWXuIUYJDmYlEd7scvtwId6UxMqq1KL8+KLSnNTiQ4zS HCxK4rz6LxXDhQTSE0tSs1NTC1KLYLJMHJxSDYz5Rx8FfYv86NUanTfZ+cuxF3KLuz6sSYia JRbyffWrrxVB7xefOOv1S+TAzwuNuxkz55lVppWa8ctOLP07N4rtr9N1a6mKUxnex8+XPN35 47Zcw7WYs/kvOtbbZz5rS55Y8O+l92FLl928S0WZXmWUXy1wrPT9z+x6Mz+1sLvgFXtgpsCG JWZKLMUZiYZazEXFiQARBEaFdgIAAA== Archived-At: Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-metadata-17.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, 20 May 2016 21:05:37 -0000 Hi All, This update changes "http1.1" and "https1.1" to "http/1.1" and "https/1.1= ", respectively, per Alexey's comment. thanx. -- Kevin J. Ma > -----Original Message----- > From: CDNi [mailto:cdni-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Friday, May 20, 2016 5:03 PM > To: i-d-announce@ietf.org > Cc: cdni@ietf.org > Subject: [CDNi] I-D Action: draft-ietf-cdni-metadata-17.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-17.txt > Pages : 62 > Date : 2016-05-20 >=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-17 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-metadata-17 >=20 >=20 > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From nobody Mon May 23 09:38:52 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 B9F6312DA1E; Mon, 23 May 2016 09:38:50 -0700 (PDT) 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.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160523163850.20856.6535.idtracker@ietfa.amsl.com> Date: Mon, 23 May 2016 09:38:50 -0700 Archived-At: Cc: flefauch@cisco.com, draft-ietf-cdni-control-triggers@ietf.org, cdni-chairs@ietf.org, The IESG , alexey.melnikov@isode.com, cdni@ietf.org, rfc-editor@rfc-editor.org Subject: [CDNi] Protocol Action: 'CDNI Control Interface / Triggers' to Proposed Standard (draft-ietf-cdni-control-triggers-15.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, 23 May 2016 16:38:51 -0000 The IESG has approved the following document: - 'CDNI Control Interface / Triggers' (draft-ietf-cdni-control-triggers-15.txt) as Proposed Standard This document is the product of the Content Delivery Networks Interconnection Working Group. The IESG contact persons are Alexey Melnikov, Ben Campbell and Alissa Cooper. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-control-triggers/ Technical Summary 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. Review and Consensus The document is well written and of good quality. It has been reviewed by multiple active members of the working group. It has also been through an early Appsdir review, with specific focus on JSON specification and HTTP. There is strong consensus in the working group on this document. It has been discussed clearly with many supporting the corresponding approach and none objecting to it. Personnel Document Shepherd: Francois Le Faucheur Responsible Area Director: Alexey Melnikov From nobody Mon May 23 10:17: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 1C9E912D11A; Mon, 23 May 2016 10:17:44 -0700 (PDT) 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.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160523171744.21004.42554.idtracker@ietfa.amsl.com> Date: Mon, 23 May 2016 10:17:44 -0700 Archived-At: Cc: Francois Le Faucheur , cdni-chairs@ietf.org, The IESG , draft-ietf-cdni-footprint-capabilities-semantics@ietf.org, alexey.melnikov@isode.com, cdni@ietf.org, rfc-editor@rfc-editor.org Subject: [CDNi] Protocol Action: 'CDNI Request Routing: Footprint and Capabilities Semantics' to Proposed Standard (draft-ietf-cdni-footprint-capabilities-semantics-20.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, 23 May 2016 17:17:44 -0000 The IESG has approved the following document: - 'CDNI Request Routing: Footprint and Capabilities Semantics' (draft-ietf-cdni-footprint-capabilities-semantics-20.txt) as Proposed Standard This document is the product of the Content Delivery Networks Interconnection Working Group. The IESG contact persons are Alexey Melnikov, Ben Campbell and Alissa Cooper. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-footprint-capabilities-semantics/ Technical Summary This document describes the semantic of a footprint and capability advertisement function usable by interconnected CDNs allowing downstream CDNs (dCDNs) to advertise capabilities and the coverage footprint of those capabilities to upstream CDNs (uCDNs). This function is to be supported by the CDNI Footprint & Capabilities interface (FCI) identified in the CDNI Framework (RFC 7336). The FCI is intended to help an uCDN decides whether or not to delegate requests to a given dCDN. Review and Consensus The document contains historical information discussing and defining the scope of FCI (e.g., non-real-time updates, with no attempts to prevent CDNs from lying about footprints, and without requiring CDNs to divulge topology or capacity information). There was a long history of debate over these issues, but consensus was reached. This document defines the broad WG consensus on a minimum set of capabilities to be advertised, and the WG consensus on a minimum set of footprint types to support, with registries created for the future extensibility of both. The document also defines an abstract object for defining new capabilities and footprints. Personnel The document shepherd is Francois Le Faucheur. The responsible AD is Alexey Melnikov. From nobody Tue May 24 07:44: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 026F012D843 for ; Tue, 24 May 2016 07:44:43 -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 3hNfA0_6jbnn for ; Tue, 24 May 2016 07:44:41 -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 8BFC912D842 for ; Tue, 24 May 2016 07:44:41 -0700 (PDT) X-AuditID: c6180641-f796f6d000000e1e-ab-574468a4f73e Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 0F.0F.03614.4A864475; Tue, 24 May 2016 16:43:48 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0294.000; Tue, 24 May 2016 10:44:40 -0400 From: Kevin Ma J To: "cdni@ietf.org" Thread-Topic: Working Group Last Call on draft-ietf-cdni-metadata-17 Thread-Index: AdG1E1bb+DcmCcimThChvHm8Gcgjbw== Date: Tue, 24 May 2016 14:44:40 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsUyuXRPrO6SDJdwg9cbdSyezv7D6sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujNnHZjIVNDNXzN46iamBcQ1TFyMHh4SAicTMn/ZdjJxAppjE hXvr2boYuTiEBI4yShxb2cUE4SxnlGie95QZpIpNQEvi8de/YM0iAsoSPw85goSFBewlZmw6 ABV2kdiyWw4kLCKgJ7Gi4SIriM0ioCpx8c87NhCbV8BX4v3czywgNiPQ3u+nQM7h5GAWEJe4 9WQ+E8Q9AhJL9pxnhrBFJV4+/scKYStJfPw9nx2iXkdiwe5PbBC2tsSyha+ZIeYLSpyc+YRl AqPwLCRjZyFpmYWkZRaSlgWMLKsYOUqLC3Jy040MNzECg/iYBJvjDsa9vZ6HGAU4GJV4eBNq ncOFWBPLiitzDzFKcDArifAKA2NAiDclsbIqtSg/vqg0J7X4EKM0B4uSOK/+S8VwIYH0xJLU 7NTUgtQimCwTB6dUAyOvJodr2AvVva6bd9+5PX1RYLxRVSh7znW5ydu1434Vh+xoTXCNEnnj xrtoBse31fJ7Py6YePCfpeuZb9Oe/18wgTfW7CxLdGNGafzOGd9yj54/4PhTm93QZknwucnz HfgkLhoa3GosOm+tWP39vEHgTbOv27dmBaxyN3WQaprT/nnyAx7xw45KLMUZiYZazEXFiQCt Iw0bXgIAAA== Archived-At: Subject: [CDNi] Working Group Last Call on draft-ietf-cdni-metadata-17 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, 24 May 2016 14:44:43 -0000 Hi All, As per the discussion in BA, we would like to move the Metadata Interface= draft to WGLC. Today will begin the two-week WGLC on: https://tools.ietf.org/html/draft-= ietf-cdni-metadata-17 Please send any comments, questions, concerns to the CDNI mailing list: c= dni@ietf.org The WGLC will end on Tuesday June 7, 2016. thanx! -- Kevin and Francois From nobody Wed May 25 10:54: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 0B21912D518; Wed, 25 May 2016 10:54: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 vrNyEA-o3lLv; Wed, 25 May 2016 10:54:02 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::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 87E5112D1EC; Wed, 25 May 2016 10:54:01 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id a136so138514326wme.0; Wed, 25 May 2016 10:54:01 -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=sGittl2/Ts1iLVSkJcvci6XPSHYOnkQ/daXvSpHON5o=; b=etvtozPQcpGJenOxiLGK/GyabC4Eio8FjSrdugQFUwgckH5PlpoR1N+I6fSzej7tTx PmZBjQODnZf3XZtG2c0uP5pbU1ir0yFaD9ebsiOGMUefoYZgs4i5CDo3gqS4wkJylY8O dQbOiaxhsiRstEnh8/96rGFyoQFG9mtH8IJWjeNdqdWyT6QPGnGXQjPXBGxSFodvB9Y/ 6Mdq03jYLikK1rr1+2WsIquhnhb84k9224vE9IV97PMW7EftxDuo3bcmDGn5b8aXLn5t F5EXo5lRoPzfm0C7p2P4p+3q/9ySVMOAOL5geK2uqLa6+1ExFIbXhH6QhDfVALnoJPkb 8bPQ== 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=sGittl2/Ts1iLVSkJcvci6XPSHYOnkQ/daXvSpHON5o=; b=gAJh6glGzs+Gm4UZW8nwf5eNl0oj5fNqHQe3l/eHM64O9ql04e2tM9brakfzDbuF0+ VjtJXmS8dq0CIz4dOFAvIAq7y32IeyRwQEjajk/WAR4XMJKbD7jwaYOz5hUsR6krDw+j 1GU1Z50ZM/KYdApoCn9kmvamD2SLGfjYXLV7gMtwjHo9qOFhQFGlTzZQxGjgQZ/RF6fD NEa8cR3QgCJDQK8Wc4ido9bpXG+KgZlFP9m2/LZXeVfOIeI/vMecGpAb5PpvwJ7Ry5ST VF84PKAU67KTBnKchntSRGeQpShBl9d0KEw8gg32N+SsefMjyEApmPefntnux4WhZejj RTzw== X-Gm-Message-State: ALyK8tKvBRPh3QA5TRufEJCf91tZbhuIjYwRqQXy8YkCU1EhZnbIiBm5we0qx1wJRAE5JQ== X-Received: by 10.194.165.226 with SMTP id zb2mr5649537wjb.172.1464198839947; Wed, 25 May 2016 10:53:59 -0700 (PDT) Received: from [192.168.1.21] (125.216.113.78.rev.sfr.net. [78.113.216.125]) by smtp.gmail.com with ESMTPSA id g8sm10563444wme.23.2016.05.25.10.53.58 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 25 May 2016 10:53:58 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Francois Le Faucheur In-Reply-To: <20160518134030.14641.52615.idtracker@ietfa.amsl.com> Date: Wed, 25 May 2016 19:53:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <671F8B12-B221-4669-A6EA-41633DD6ED6A@gmail.com> References: <20160518134030.14641.52615.idtracker@ietfa.amsl.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.3124) Archived-At: Cc: draft-ietf-cdni-logging@ietf.org, cdni-chairs@ietf.org, The IESG , cdni@ietf.org Subject: Re: [CDNi] Alexey Melnikov's Discuss on draft-ietf-cdni-logging-25: (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, 25 May 2016 17:54:05 -0000 Hello Alexey and all, Thanks much for the review. Please see below for resolution of all the = comments. >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > I know this document has long history and I want to get it done as = well. > Below is a list of small issues that I think need to be addressed: >=20 > Is version directive value case-insensitive? The IANA registration is = in > lowercase, but all examples show uppercase. Yes, the version directive value is case-insensitive (like the directive = names, the record-types and the field names). There is already a statement about that at the beginning of "section 6: = IANA Considerations" " When IANA allocates new extensions to CDNI Logging Directive Names Registry, CDNI Logging File version Registry, CDNI Logging record- type Registry or CDNI Logging fields Registry, IANA MUST take into account that the directive names are case-insensitive as per the basic ABNF([RFC5234]). =E2=80=9C To make it easier to for the reader, I have added a statement about = case-insensitive under section "6.2. CDNI Logging File version = Registry=E2=80=9D (and section 6.3 and section 6.4 for that matter) like = there was already under 6.1. >=20 > On page 28: SHA-3, AES-GCM and base64 all need normative references. I added=20 [SHA-3] NIST, "SHA-3 STANDARD: PERMUTATION-BASED HASH AND EXTENDABLE OUTPUT FUNCTIONS", August 2015, . I tweaked the text to say: "and the encryption algorithm SHOULD be 128-bit AES [AES] in Galois = Counter Mode (GCM) [GCM] (AES-GCM) or better.=E2=80=9D with :=20 " [AES] NIST, "Advanced Encryption Standard (AES)", August 2015, . [GCM] NIST, "Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC", November 2007, . " I tweaked the text to say: "The encrypted value SHOULD be hex encoded or base64 encoded (as = specified in section 4 of [RFC4648]).=E2=80=9D with: =E2=80=9C [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, . " Please let me know if they are better references to use. >=20 > (Use "Section 4 of [RFC4648]" for base64, as RFC 4648 defines 2 base54 > encodings). Thanks for the tip ! >=20 > On page 33: where does the "missing field value is denoted by -" > specified in ABNF? If this is not defined in ABNF, it would be good to > have an example record with a field missing. I assume you are referencing to the following sentence: "if the value for the field is not available, this MUST be conveyed via = a dash character ("-=E2=80=9C).=E2=80=9D Right? It is not explicitly discussed in the ABNF description (although for all = the fields of format NHTABSTRING it is allowed by the ABNF description). But I like your suggestion and added an example at the bottom of section = "3.6. CDNI Logging File Examples=E2=80=9D: " Say, that for some reason (for example a Surrogate bug), dCDN-1 could not collect the total number of bytes of the responses sent by the Surrogate (in other words, the value for sc-total-bytes is not available). Then the corresponding CDNI Logging records would contain a dash character ("-") in lieu of the value for the sc-total- bytes field (as specified in Section 3.4.1). In that case, the CDNI Logging File that would be communicated by dCDN-1 to uCDN is shown below in Figure 5. #version:cdni/1.0 #UUID:urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 #claimed-origin:cdni-logging-entity.dcdn-1.example.com #record-type:cdni_http_request_v1 #fields:datetimetime-takenc-groupid cs-methodu-uriprotocol sc-statussc-total-bytescs(User-Agent) cs(Referer)s-cached 2013-05-1700:38:06.8259.058US/TN/MEM/38138 GET http://cdni-ucdn.dcdn-1.example.com/video/movie100.mp4 HTTP/1.1200-"Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.127 Safari/533.4" "host1.example.com"1 2013-05-1700:39:09.14515.32FR/PACA/NCE/06100 GET http://cdni-ucdn.dcdn-1.example.com/video/movie118.mp4 HTTP/1.1200-"Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.127 Safari/533.4" "host1.example.com"1 2013-05-1700:42:53.43752.879US/TN/MEM/38138 GET http://cdni-ucdn.dcdn-1.example.com/video/picture11.mp4 HTTP/1.0200-"Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.127 Safari/533.4" "host5.example.com"0 #SHA256-hash: 64-hexadecimal-digit hash value Figure 5: CDNI Logging File Example With A Missing Field Value >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > In 7.1, last sentence: TLS only provides for protection from tampering > when in transit, not when a log file being stored. Agreed. I changed the sentence to say: =E2=80=9C Protection against third party tampering when the CDNI Logging File is = communicated over the CDN Logging Interface can be achieved as discussed = above through the use of TLS. =E2=80=9C Thanks Francois From nobody Wed May 25 13:41:34 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 1619912DD6C; Wed, 25 May 2016 13:41:33 -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.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160525204133.18285.92975.idtracker@ietfa.amsl.com> Date: Wed, 25 May 2016 13:41:33 -0700 Archived-At: Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-logging-26.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: Wed, 25 May 2016 20:41:33 -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-26.txt Pages : 59 Date : 2016-05-25 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-26 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-logging-26 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 May 25 13:47:31 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 03C1612DD1C; Wed, 25 May 2016 13:47:26 -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 Fw3p5qTE7I01; Wed, 25 May 2016 13:47:22 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::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 6132012D1E8; Wed, 25 May 2016 13:47:22 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id z87so76304202wmh.0; Wed, 25 May 2016 13:47:22 -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=eLxiQlUN5x/e2FGWdKn+JsNq500v6vFDnzGHYdo1odo=; b=WgbKuQAb5WyRd4ByHfgXHKFiD8n1Z9TQyZbu26A1seanPBlOxUY5p1V+3oXmKWMDkw MFzvL978+5NACugc+wopnVrlcMwFWO4KfQfbnfSSq3ngA5uObkf2dIqM9G3N3m0eHrLj OmIMPBNLQ/io7Fsbd+b/Z9En4uas2ed1stTEP7lpR54vCObvGGaSV89N4Na7AKeF4Nzg ftVqJfkTfyyOEjoJkjMtbBEvd6F7hRFkloU4m5unmqlriUVl9FOZg7aqXkUrq/eTtKQy 4zOFyLtw5oanYb0x0TehwIusn/CCMOwBTf8gDu+LHgLe0S1GwRKXsiy/n2ujVkXlEU/W Y9+g== 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=eLxiQlUN5x/e2FGWdKn+JsNq500v6vFDnzGHYdo1odo=; b=FjXSjWza+PbbJbgf9OTzLBqAW2IxNE+LNFw2Ie3j/mn+QQwKYQmQIW72ycZiLoJnyE 3o9W0IL/sheEo7ORcEi2SiLeeEwInNEQHnmW7k3x9YpLUBArxltRnTNhkBk28B4E+acS za6fx+wMQAmf7I3LoOD9eHAarbZaFzNPQvmp/QveMenZT3VlqZCzicXCbf6ZIauCWoTx A4nhmlYyidwya5OovdMf2yR0ZmJF+9JU+qHjE1+PnzinpoZBKkCzSmVaAhYW5Jd1VrWT qbyV/jHMwcv46uNvP8qnGZZE7M+zBOEf0p5OCUjBHi9Hn6T56KtWvtrTNF+B24h1X1sv HTGg== X-Gm-Message-State: ALyK8tJp0D3TlCr5PxcfOs+Kor+ANG21CP6lTr/6n9JQbVxdyjvyzVTKSpVMkrgUKxIpFw== X-Received: by 10.28.25.129 with SMTP id 123mr5575887wmz.10.1464209240828; Wed, 25 May 2016 13:47:20 -0700 (PDT) Received: from [192.168.1.21] (125.216.113.78.rev.sfr.net. [78.113.216.125]) by smtp.gmail.com with ESMTPSA id g8sm11243470wme.23.2016.05.25.13.47.19 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 25 May 2016 13:47:20 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_593A4F61-8BFC-4471-8F02-5BB1474169EF" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Francois Le Faucheur In-Reply-To: <671F8B12-B221-4669-A6EA-41633DD6ED6A@gmail.com> Date: Wed, 25 May 2016 22:47:17 +0200 Message-Id: <2FABC97B-CB3C-43C4-937B-65A614DEB1EA@gmail.com> References: <20160518134030.14641.52615.idtracker@ietfa.amsl.com> <671F8B12-B221-4669-A6EA-41633DD6ED6A@gmail.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.3124) Archived-At: Cc: draft-ietf-cdni-logging@ietf.org, cdni-chairs@ietf.org, The IESG , "" Subject: Re: [CDNi] Alexey Melnikov's Discuss on draft-ietf-cdni-logging-25: (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, 25 May 2016 20:47:26 -0000 --Apple-Mail=_593A4F61-8BFC-4471-8F02-5BB1474169EF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Alexey and all, I just posted -26 that includes all the resolutions of your comments as = discussed below. Let us know if anything else is required from your end. I will work on Ben=E2=80=99s comments soon. Cheers Francois htmlized version available at: https://tools.ietf.org/html/draft-ietf-cdni-logging-26 = A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-logging-26 = > On 25 May 2016, at 19:53, Francois Le Faucheur = wrote: >=20 > Hello Alexey and all, >=20 >=20 > Thanks much for the review. Please see below for resolution of all the = comments. >=20 >>=20 >> = ---------------------------------------------------------------------- >> DISCUSS: >> = ---------------------------------------------------------------------- >>=20 >> I know this document has long history and I want to get it done as = well. >> Below is a list of small issues that I think need to be addressed: >>=20 >> Is version directive value case-insensitive? The IANA registration is = in >> lowercase, but all examples show uppercase. >=20 > Yes, the version directive value is case-insensitive (like the = directive names, the record-types and the field names). >=20 > There is already a statement about that at the beginning of "section = 6: IANA Considerations" > " > When IANA allocates new extensions to CDNI Logging Directive Names > Registry, CDNI Logging File version Registry, CDNI Logging record- > type Registry or CDNI Logging fields Registry, IANA MUST take into > account that the directive names are case-insensitive as per the > basic ABNF([RFC5234]). > =E2=80=9C >=20 > To make it easier to for the reader, I have added a statement about = case-insensitive under section "6.2. CDNI Logging File version = Registry=E2=80=9D (and section 6.3 and section 6.4 for that matter) like = there was already under 6.1. >=20 >>=20 >> On page 28: SHA-3, AES-GCM and base64 all need normative references. >=20 > I added=20 >=20 > [SHA-3] NIST, "SHA-3 STANDARD: PERMUTATION-BASED HASH AND > EXTENDABLE OUTPUT FUNCTIONS", August 2015, > . >=20 > I tweaked the text to say: > "and the encryption algorithm SHOULD be 128-bit AES [AES] in Galois = Counter Mode (GCM) [GCM] (AES-GCM) or better.=E2=80=9D >=20 > with :=20 > " > [AES] NIST, "Advanced Encryption Standard (AES)", August 2015, > . >=20 > [GCM] NIST, "Recommendation for Block Cipher Modes of = Operation: > Galois/Counter Mode (GCM) and GMAC", November 2007, 800-38D>. > " >=20 >=20 > I tweaked the text to say: > "The encrypted value SHOULD be hex encoded or base64 encoded (as = specified in section 4 of [RFC4648]).=E2=80=9D >=20 > with: > =E2=80=9C > [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data > Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, > . > " >=20 > Please let me know if they are better references to use. >=20 >>=20 >> (Use "Section 4 of [RFC4648]" for base64, as RFC 4648 defines 2 = base54 >> encodings). >=20 > Thanks for the tip ! >=20 >>=20 >> On page 33: where does the "missing field value is denoted by -" >> specified in ABNF? If this is not defined in ABNF, it would be good = to >> have an example record with a field missing. >=20 > I assume you are referencing to the following sentence: > "if the value for the field is not available, this MUST be conveyed = via a dash character ("-=E2=80=9C).=E2=80=9D > Right? >=20 > It is not explicitly discussed in the ABNF description (although for = all the fields of format NHTABSTRING it is allowed by the ABNF = description). > But I like your suggestion and added an example at the bottom of = section "3.6. CDNI Logging File Examples=E2=80=9D: >=20 > " > Say, that for some reason (for example a Surrogate bug), dCDN-1 could > not collect the total number of bytes of the responses sent by > the Surrogate (in other words, the value for sc-total-bytes is not > available). Then the corresponding CDNI Logging records would > contain a dash character ("-") in lieu of the value for the = sc-total- > bytes field (as specified in Section 3.4.1). In that case, the CDNI > Logging File that would be communicated by dCDN-1 to uCDN is shown > below in Figure 5. >=20 > #version:cdni/1.0 >=20 > #UUID:urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 >=20 > #claimed-origin:cdni-logging-entity.dcdn-1.example.com >=20 > #record-type:cdni_http_request_v1 >=20 > #fields:datetimetime-takenc-groupid > cs-methodu-uriprotocol > sc-statussc-total-bytescs(User-Agent) > cs(Referer)s-cached >=20 > 2013-05-1700:38:06.8259.058US/TN/MEM/38138 > GET > http://cdni-ucdn.dcdn-1.example.com/video/movie100.mp4 > HTTP/1.1200-"Mozilla/5.0 > (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like > Gecko) Chrome/5.0.375.127 Safari/533.4" > "host1.example.com"1 >=20 > 2013-05-1700:39:09.14515.32FR/PACA/NCE/06100 > GET > http://cdni-ucdn.dcdn-1.example.com/video/movie118.mp4 > HTTP/1.1200-"Mozilla/5.0 > (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like > Gecko) Chrome/5.0.375.127 Safari/533.4" > "host1.example.com"1 >=20 > 2013-05-1700:42:53.43752.879US/TN/MEM/38138 > GET > http://cdni-ucdn.dcdn-1.example.com/video/picture11.mp4 > HTTP/1.0200-"Mozilla/5.0 > (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like > Gecko) Chrome/5.0.375.127 Safari/533.4" > "host5.example.com"0 >=20 > #SHA256-hash: 64-hexadecimal-digit hash value >=20 > Figure 5: CDNI Logging File Example With A Missing Field Value >=20 >=20 >=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> In 7.1, last sentence: TLS only provides for protection from = tampering >> when in transit, not when a log file being stored. >=20 > Agreed. I changed the sentence to say: > =E2=80=9C > Protection against third party tampering when the CDNI Logging File is = communicated over the CDN Logging Interface can be achieved as discussed = above through the use of TLS. > =E2=80=9C >=20 > Thanks >=20 > Francois >=20 >=20 --Apple-Mail=_593A4F61-8BFC-4471-8F02-5BB1474169EF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Alexey and all,

I just posted -26 that includes all the resolutions of your = comments as discussed below.
Let us know if = anything else is required from your end.

I will work on Ben=E2=80=99s comments = soon.

Cheers

Francois

htmlized version available at:
https://tools.ietf.org/html/draft-ietf-cdni-logging-26

A diff from the previous version is available = at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-logging-26<= /a>


On = 25 May 2016, at 19:53, Francois Le Faucheur <flefauch@gmail.com> = wrote:

Hello Alexey and all,


Thanks much for the review. Please see below for resolution = of all the comments.


---------------------------------------------------------------= -------
DISCUSS:
---------------------------------------------------------------= -------

I know this document has long = history and I want to get it done as well.
Below is a list = of small issues that I think need to be addressed:

Is version directive value case-insensitive? The IANA = registration is in
lowercase, but all examples show = uppercase.

Yes, the version = directive value is case-insensitive (like the directive names, the = record-types  and the field names).

There is already a statement about that at the beginning of = "section 6: IANA Considerations"
"
When IANA = allocates new extensions to CDNI Logging Directive Names
=   Registry, CDNI Logging File version Registry, CDNI Logging = record-
  type Registry or CDNI Logging fields = Registry, IANA MUST take into
  account that = the directive names are case-insensitive as per the
=   basic ABNF([RFC5234]).
=E2=80=9C

To make it easier to for the reader, I have = added a statement about case-insensitive under section "6.2.  CDNI = Logging File version Registry=E2=80=9D (and section 6.3 and section 6.4 = for that matter) like there was already under 6.1.


On page = 28: SHA-3, AES-GCM and base64 all need normative references.

I added

[SHA-3]    NIST, "SHA-3 STANDARD: = PERMUTATION-BASED HASH AND
=             &n= bsp;EXTENDABLE OUTPUT FUNCTIONS", August 2015,
=             &n= bsp;<http://dx.doi.org/10.6028/NIST.FIPS.202>.

I tweaked the text to say:
"and = the encryption algorithm SHOULD be 128-bit AES [AES] in Galois Counter = Mode (GCM) [GCM] (AES-GCM) or better.=E2=80=9D

with :
"
  [AES] =      NIST, "Advanced Encryption Standard = (AES)", August 2015,
=             &n= bsp;<FIPS 197>.

  [GCM] =      NIST, "Recommendation for Block Cipher = Modes of Operation:
=             &n= bsp;Galois/Counter Mode (GCM) and GMAC", November 2007, <SP
=             &n= bsp;800-38D>.
"


I tweaked the text to say:
"The encrypted value = SHOULD be hex encoded or base64 encoded (as specified in section 4 of = [RFC4648]).=E2=80=9D

with:
=E2=80=9C
  [RFC4648] =  Josefsson, S., "The Base16, Base32, and Base64 Data
=             &n= bsp;Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
=             &n= bsp;<http://www.rfc-editor.org/info/rfc4648>.
"

Please let me know if they are = better references to use.


(Use "Section 4 of [RFC4648]" = for base64, as RFC 4648 defines 2 base54
encodings).

Thanks for the tip !


On page 33: where does the "missing field value is denoted by = -"
specified in ABNF? If this is not defined in ABNF, it = would be good to
have an example record with a field = missing.

I assume you are = referencing to the following sentence:
"if the value for = the field is not available, this MUST be conveyed via a dash character = ("-=E2=80=9C).=E2=80=9D
Right?

It is not explicitly discussed in the ABNF description = (although for all the fields of format NHTABSTRING it is allowed by the = ABNF description).
But I like your suggestion and added an = example at the bottom of section "3.6.  CDNI Logging File = Examples=E2=80=9D:

"
Say, = that for some reason (for example a Surrogate bug), dCDN-1 could
  not collect the total number of bytes of the = responses sent by
  the Surrogate (in other = words, the value for sc-total-bytes is not
=   available).  Then the corresponding CDNI Logging = records would
  contain a dash character ("-") = in lieu of the value for the sc-total-
  bytes = field (as specified in Section 3.4.1).  In that case, the CDNI
  Logging File that would be communicated by = dCDN-1 to uCDN is shown
  below in Figure 5.

=   #version:<HTAB>cdni/1.0<CRLF>

=   #UUID:<HTAB>urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf= 6<CRLF>

=   #claimed-origin:<HTAB>cdni-logging-entity.dcdn-1.example.com<CRLF>

=   #record-type:<HTAB>cdni_http_request_v1<CRLF>

=   #fields:<HTAB>date<HTAB>time<HTAB>time-taken= <HTAB>c-groupid<HTAB>
=   cs-method<HTAB>u-uri<HTAB>protocol<HTAB>
=   sc-status<HTAB>sc-total-bytes<HTAB>cs(User-Agent)&= lt;HTAB>
=   cs(Referer)<HTAB>s-cached<CRLF>

=   2013-05-17<HTAB>00:38:06.825<HTAB>9.058<HTAB>= ;US/TN/MEM/38138<HTAB>
=   GET<HTAB>
  http://cdni-ucdn.dcdn-1.example.com/video/movie100.mp4<HTAB&= gt;
=   HTTP/1.1<HTAB>200<HTAB>-<HTAB>"Mozilla/5.0   (Windows; U; Windows NT 6.0; en-US) = AppleWebKit/533.4 (KHTML, like
  Gecko) = Chrome/5.0.375.127 Safari/533.4"<HTAB>
=   "host1.example.com"<HTAB>1<CRLF>

=   2013-05-17<HTAB>00:39:09.145<HTAB>15.32<HTAB>= ;FR/PACA/NCE/06100<HTAB>
=   GET<HTAB>
  http://cdni-ucdn.dcdn-1.example.com/video/movie118.mp4<HTAB&= gt;
=   HTTP/1.1<HTAB>200<HTAB>-<HTAB>"Mozilla/5.0   (Windows; U; Windows NT 6.0; en-US) = AppleWebKit/533.4 (KHTML, like
  Gecko) = Chrome/5.0.375.127 Safari/533.4"<HTAB>
=   "host1.example.com"<HTAB>1<CRLF>

=   2013-05-17<HTAB>00:42:53.437<HTAB>52.879<HTAB&g= t;US/TN/MEM/38138<HTAB>
=   GET<HTAB>
  http://cdni-ucdn.dcdn-1.example.com/video/picture11.mp4<HTAB= >
=   HTTP/1.0<HTAB>200<HTAB>-<HTAB>"Mozilla/5.0   (Windows; U; Windows NT 6.0; en-US) = AppleWebKit/533.4 (KHTML, like
  Gecko) = Chrome/5.0.375.127 Safari/533.4"<HTAB>
=   "host5.example.com"<HTAB>0<CRLF>

  #SHA256-hash:<HTAB> = 64-hexadecimal-digit hash value <CRLF>

=      Figure 5: CDNI Logging File Example With = A Missing Field Value





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

In 7.1, last sentence: TLS only = provides for protection from tampering
when in transit, = not when a log file being stored.

Agreed. I changed the sentence to say:
=E2=80=9C<= br class=3D"">Protection against third party tampering when the CDNI = Logging File is communicated over the CDN Logging Interface can be = achieved as discussed above through the use of TLS.
=E2=80=9C=

Thanks

Francois



= --Apple-Mail=_593A4F61-8BFC-4471-8F02-5BB1474169EF-- From nobody Sun May 29 04:43: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 BE0D712D0D9; Sun, 29 May 2016 04:43:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alexey Melnikov" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160529114300.27632.32780.idtracker@ietfa.amsl.com> Date: Sun, 29 May 2016 04:43:00 -0700 Archived-At: Cc: draft-ietf-cdni-logging@ietf.org, cdni@ietf.org, cdni-chairs@ietf.org Subject: [CDNi] Alexey Melnikov's No Objection on draft-ietf-cdni-logging-26: (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: Sun, 29 May 2016 11:43:01 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-cdni-logging-26: 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: ---------------------------------------------------------------------- Thank you for addressing my DISCUSS points. Ok, you now clarified that version names are case-insensitive. However I didn't get this impression while reading 3.3, as there is no version ABNF there. So you might want to say that earlier in the document as well. In 7.1, last sentence: TLS only provides for protection from tampering when in transit, not when a log file being stored.