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

[Ben Niven-Jenkins <[e-mail]>]

> On 19 May 2016, at 01:33, Stephen Farrell <[e-mail]> wrote:
> On 19/05/16 01:24, Ben Niven-Jenkins wrote:
>> 
>>> On 19 May 2016, at 00:46, Stephen Farrell
>>> <[e-mail]> 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 <[e-mail]> 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.
> 
> The relevance is that it shows that your argument wasn't correct
> as stated.

I’m not sure which part wasn’t correct unless we’re debating whether my use of “typically” 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’t have data to say how often the generalised version I stated occurs vs does not occur, so maybe it isn’t “typical” maybe its only “sometimes”. I didn’t consider that relevant and figured “typically” 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). 

> 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’m not trying to re-litigate anything. 

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