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 15:42 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 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 <ben@niven-jenkins.co.uk>) 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 <ben@niven-jenkins.co.uk>
In-Reply-To: <573D19C3.3050304@cs.tcd.ie>
Date: Thu, 19 May 2016 16:42:30 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <A4F4089F-DAB0-4BE2-AE95-6B3BABB52D04@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> <5DED924E-C407-44E9-8FF1-477B26B69647@niven-jenkins.co.uk> <573D09D5.1020501@cs.tcd.ie> <C23FF36A-E663-4158-B6CE-4E129BFEE9C2@niven-jenkins.co.uk> <573D19C3.3050304@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/__IZNQVIp2MjakSGOxM4EWPMNqU>
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 15:42:38 -0000

> 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 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’s privacy, what it gains from that outweighs the additional cost of performing the delivery itself. Who knows, I don’t 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’m 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’s a tradeoff I think. I’m not sure we’ll ever agree.

I have nothing more to say that won’t end up just rehashing discussions we’ve already had so I don’t intend on participating in this thread any longer.

Ben