Re: [CDNi] Ben Campbell's Discuss on draft-ietf-cdni-logging-25: (with DISCUSS and COMMENT)
"Ben Campbell" <ben@nostrum.com> Wed, 08 June 2016 14:33 UTC
Return-Path: <ben@nostrum.com>
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 49DE412D559; Wed, 8 Jun 2016 07:33:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.325
X-Spam-Level:
X-Spam-Status: No, score=-3.325 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.426] autolearn=unavailable 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 u6xiVqiDuFOy; Wed, 8 Jun 2016 07:33:52 -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 60B8812D594; Wed, 8 Jun 2016 07:33:52 -0700 (PDT)
Received: from [10.0.1.4] (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 u58EXjhX070122 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 8 Jun 2016 09:33:45 -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.4]
From: Ben Campbell <ben@nostrum.com>
To: Francois Le Faucheur <flefauch@gmail.com>
Date: Wed, 08 Jun 2016 09:33:50 -0500
Message-ID: <3850695D-BA08-46E3-9D85-A098C3FB0369@nostrum.com>
In-Reply-To: <CCFC316B-04CD-4EAB-87EC-618FE6166931@gmail.com>
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> <A4F4089F-DAB0-4BE2-AE95-6B3BABB52D04@niven-jenkins.co.uk> <59AB96A8-B811-443A-8256-54D45141F96E@gmail.com> <CCFC316B-04CD-4EAB-87EC-618FE6166931@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_MailMate_99FAA1CE-9221-45A5-9232-ADD613CAA33E_="
Content-Transfer-Encoding: 8bit
X-Mailer: MailMate (1.9.4r5234)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cdni/NdqvtoI9JP5ym_a1zC_gE2EwbDU>
Cc: cdni@ietf.org, cdni-chairs@ietf.org, The IESG <iesg@ietf.org>, draft-ietf-cdni-logging@ietf.org, Stephen Farrell <stephen.farrell@cs.tcd.ie>
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: Wed, 08 Jun 2016 14:33:55 -0000
That paragraph works for me in general, with one comment: Maybe I missed something in the conversation, but is there a reason to describe (2) as no _legal_ reasons? Could you drop the word "legal"? Thanks! Ben. On 8 Jun 2016, at 4:07, Francois Le Faucheur wrote: > Folks, > > Here is the rewritten paragraph about the potential privacy concerns > related to communicating details information to the uCDN: > > " > When HTTP redirection is used between the uCDN and the dCDN, 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). When DNS redirection is used between the uCDN and the > dCDN, there are cases where there is no privacy concern in making > detailed CDNI logging information known to the uCDN; this may be > the > case, for example, where (1) it is considered that because the uCDN > has the authority (with respect to the CSP) and control on how the > requests are delivered (including whether it is served by the uCDN > itself or by a dCDN), the uCDN is entitled to access all detailed > information related to the corresponding deliveries, and (2) there > is > no legal reasons to restrict access by the uCDN to all these > detailed > information. Conversely, still when DNS redirection is used > between > the uCDN and the dCDN, there are cases where there may be some > privacy concern in making detailed CDNI logging information known > to > the uCDN; this may be the case, for example, because the uCDN is in > a > different jurisdiction to the dCDN resulting is some legal reasons > to > restrict access by the uCDN to all the detailed information related > to the deliveries. In this latter case, the privacy concern can be > taken into account when the uCDN and dCDN agree about which fields > are to be conveyed inside the CDNI Logging Files and which privacy > protection mechanism is to be used as discussed in the definition > of > the c-groupid field specified in Section 3.4.1. > “ > > Cheers > > Francois > > > > >> On 1 Jun 2016, at 18:47, Francois Le Faucheur <flefauch@gmail.com> >> wrote: >> >> Folks, >> >> My conclusion from that thread is: >> * the current argument for why there is no privacy concern in >> communicating the CDNI Logging File to the uCDN holds for HTTP >> * for DNS, the current argument does not hold as currently written >> * for DNS, my proposal is to: >> - capture Ben NJ’s argument (but with a caveat): because the uCDN >> is the “authoritative” CDN (i.e. the CDN that has control about >> how the request is delivered and by itself of by another CDN) and has >> the responsibility of each and every delivery, it _may_ not be a >> privacy concern to communicate detailed logging information to the >> uCDN. >> - in scenarios where there are some privacy concerns (e.g. because >> of different regulations applying to uCDN and dCDN), then this can be >> taken into account when uCDN and dCDN agree on which fields to convey >> inside the CDNI Logging Files and which privacy protection mechanisms >> are to be used (such as the c-groupid, and which mapping is used for >> the c-groupid). >> >> Let me know if that is not acceptable, and can be improved. >> >> Cheers >> >> Francois >> >> >>> On 19 May 2016, at 17:42, Ben Niven-Jenkins >>> <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 >>>>> 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 >>> >>
- [CDNi] Ben Campbell's Discuss on draft-ietf-cdni-… Ben Campbell
- Re: [CDNi] Ben Campbell's Discuss on draft-ietf-c… Ben Niven-Jenkins
- Re: [CDNi] Ben Campbell's Discuss on draft-ietf-c… Stephen Farrell
- Re: [CDNi] Ben Campbell's Discuss on draft-ietf-c… Ben Niven-Jenkins
- Re: [CDNi] Ben Campbell's Discuss on draft-ietf-c… Stephen Farrell
- Re: [CDNi] Ben Campbell's Discuss on draft-ietf-c… Ben Campbell
- Re: [CDNi] Ben Campbell's Discuss on draft-ietf-c… Ben Niven-Jenkins
- Re: [CDNi] Ben Campbell's Discuss on draft-ietf-c… Ben Niven-Jenkins
- Re: [CDNi] Ben Campbell's Discuss on draft-ietf-c… Stephen Farrell
- Re: [CDNi] Ben Campbell's Discuss on draft-ietf-c… Ben Niven-Jenkins
- Re: [CDNi] Ben Campbell's Discuss on draft-ietf-c… Spencer Dawkins at IETF
- Re: [CDNi] Ben Campbell's Discuss on draft-ietf-c… Francois Le Faucheur
- Re: [CDNi] Ben Campbell's Discuss on draft-ietf-c… Francois Le Faucheur
- Re: [CDNi] Ben Campbell's Discuss on draft-ietf-c… Francois Le Faucheur
- Re: [CDNi] Ben Campbell's Discuss on draft-ietf-c… Ben Campbell
- Re: [CDNi] Ben Campbell's Discuss on draft-ietf-c… Francois Le Faucheur