Subject: Re: [CDNi] Stephen Farrell's Discuss on draft-ietf-cdni-redirection-17: (with DISCUSS and COMMENT)

From: Ben Niven-Jenkins <[email-masked]>
Date: Sat, 16 Apr 2016 07:44:28 +0100

Hi Stephen,

> On 27 Mar 2016, at 17:36, Stephen Farrell <[email-masked]> wrote:
> On 24/03/16 15:51, Niven - Jenkins, Ben (Nokia - GB) wrote:
>> > On 24 Mar 2016, at 15:49, EXT Stephen Farrell <[email-masked]> wrote:
>>> Can we agree that as-is, the draft is very much
>>> aiming to meet the commercial requirements and is not taking account
>>> or privacy requirements?
>> 
>> Yes I think we can agree that. Ben
> 
> Great. Then I'd suggest that the best next step may be to try get
> a bunch of folks to chat in B-A about how to take privacy into
> account and hopefully that'll also turn out to be a fine way to
> resolve the discuss. (Or if not in B-A then a subsequent concall
> maybe.)

The authors have started a discussion with the advisors Francois & yourself suggested/volunteered to help with this. Will let you know the outcome of that.

I’ve also published a -18 that contains all the editorial/other edits made in response to Ben Campbell’s, Alissa’s & your comments.

The only other outstanding thing in your comments as far as I am aware is this:

> On 24 Mar 2016, at 15:07, Ben Niven-Jenkins <[email-masked]> wrote:
>> On 17 Mar 2016, at 10:10, Stephen Farrell <[email-masked]> wrote:

>> - 4.4.2: a JSON "string" is not the same as a DNS name is it?
>> What about i18n? (ULABEL or ALABEL?) what about odd characters
>> allowed in JSON but not in DNS names?  In general the fields
>> in this dictionary (and others) seem underspecified to me.
> 
> I’m afraid I’m not an expert in JSON strings, unicode or i18n. I think what you’re getting at is that a JSON string can contain more characters than allowed by an ALABEL or a ULABEL and we should be more precise in constraining the allowed characters? And that you think there are other fields in the document that would also benefit from constraining the allowable set of characters. If that’s the case I’m happy to make the edits to improve the document but I will need some help on what the right terminology is and the right references for the allowable characters.

Any suggestions for someone who could help with reviewing the doc from a unicode & i18n angle and helping me get the terminology and set of allowable characters right?

Thanks
Ben

---

From: "Niven - Jenkins, Ben (Nokia - GB)" <[email-masked]>
Date: Fri, 29 Apr 2016 12:00:20 +0000

Hi Stephen,

Following up on this after discussion with the privacy advisors you
suggested/volunteered.

On 16/04/2016 07:44, "EXT Ben Niven-Jenkins" <[email-masked]>
wrote:

>The authors have started a discussion with the advisors Francois &
>yourself suggested/volunteered to help with this. Will let you know the
>outcome of that.

The outcome of that discussion is that neither Rich nor Brian can think of
any privacy protection that would not adversely impact the ability of the
dCDN to effectively do its job.

We are therefore a bit stuck on how to proceed to attempt to clear your
DISCUSS.

The best that the editors & chairs can come up with is to tweak the
language in Section 4.1 a bit:

OLD:
   To assist the routing decision of a dCDN, the uCDN SHOULD convey as
   much information as possible to the dCDN, for example, the URI of the
   requested content and the User Agent's IP address or subnet, when
   those are known by the uCDN Request Routing system.
NEW:
   Generally, dCDNs can provide better routing decisions given additional
information about the content request, e.g., the URI of the   requested
content or the User Agent's IP address or subnet.  A uCDN   MAY wish to
include such information in requests to the dCDN,   however, uCDNs should
only share a User Agent's personal   information with trusted dCDNs
<ref target="5.2 Privacy"/>.

END

Note: [not suggesting we do it in the draft] that in the real world uCDNs
& dCDNs will share whatever they want/need to optimise their deployments,
add value for their customers, etc which will almost certainly include
sharing some/a lot of privacy impacting information.

The other option that was suggested was to stick a warning label somewhere
in the draft that says "not possible to use in a privacy-preserving
manner, please be advised you're advertising your interest in specific
content & potentially private information to an ecosystem full of
companies you've never heard of”

Note: [not suggesting we do it in the draft] that the same warning label
applies to the vast majority of today's Web as well.

How would you like us to proceed here?

>I’ve also published a -18 that contains all the editorial/other edits
>made in response to Ben Campbell’s, Alissa’s & your comments.
>
>> I’m afraid I’m not an expert in JSON strings, unicode or i18n. I think
>>what you’re getting at is that a JSON string can contain more characters
>>than allowed by an ALABEL or a ULABEL and we should be more precise in
>>constraining the allowed characters? And that you think there are other
>>fields in the document that would also benefit from constraining the
>>allowable set of characters. If that’s the case I’m happy to make the
>>edits to improve the document but I will need some help on what the
>>right terminology is and the right references for the allowable
>>characters.
>
>Any suggestions for someone who could help with reviewing the doc from a
>unicode & i18n angle and helping me get the terminology and set of
>allowable characters right?

Nudging again as to whether you have any suggestions for someone to help
out here?

Thanks
Ben