Re: [CDNi] Ben Campbell's Discuss on draft-ietf-cdni-logging-25: (with DISCUSS and COMMENT)

Ben Niven-Jenkins <ben@niven-jenkins.co.uk> Thu, 19 May 2016 00:25 UTC

Return-Path: <ben@niven-jenkins.co.uk>
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 <ben@niven-jenkins.co.uk>) 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 <ben@niven-jenkins.co.uk>
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 <stephen.farrell@cs.tcd.ie>
X-Mailer: Apple Mail (2.2098)
X-Mailcore-Auth: 9600544
X-Mailcore-Domain: 172912
Archived-At: <http://mailarchive.ietf.org/arch/msg/cdni/vQLZW0vZ5sNLhQnuOHKNadGfRX0>
Cc: Ben Campbell <ben@nostrum.com>, draft-ietf-cdni-logging@ietf.org, The IESG <iesg@ietf.org>, 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\)" <cdni.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cdni>, <mailto:cdni-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cdni/>
List-Post: <mailto:cdni@ietf.org>
List-Help: <mailto:cdni-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cdni>, <mailto:cdni-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 May 2016 00:25:04 -0000

> 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’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 <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…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.
> 
> 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’t see how the presence of such laws is relevant to the technical specification of the CDNI logging interface.

Ben