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

["Ben Campbell" <[e-mail]>]

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 <[e-mail]> 
>> 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 
>>> <[e-mail]> wrote:
>>>
>>>
>>>> On 19 May 2016, at 02:41, Stephen Farrell 
>>>> <[e-mail]> 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
>>>
>>