Subject: Re: [CDNi] Alissa Cooper's Discuss on draft-ietf-cdni-logging-23: (with DISCUSS and COMMENT)

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 4 Apr 2016 16:04:34 -0300

Hi, Alissa,

On Thu, Mar 31, 2016 at 3:06 PM, Alissa Cooper <[email-masked]> wrote:

>
> On Mar 31, 2016, at 11:00 AM, Francois Le Faucheur <[email-masked]>
> wrote:
>
> I will post a new version with all the agreed text as soon as posting
> reopens.
>
>
> Great. I’ll update my ballot when it gets posted.
>

I've read through this version (-24) and am ready to send the approval
e-mail when you clear.

And I echo Francois's thanks.

Spencer

> Alissa
>
>
> Thanks a lot for working with us.
>
> Francois
>
>
> On 31 Mar 2016, at 19:58, Alissa Cooper <[email-masked]> wrote:
>
>
> On Mar 31, 2016, at 10:51 AM, Francois Le Faucheur <[email-masked]>
> wrote:
>
>
> On 31 Mar 2016, at 19:43, Alissa Cooper <[email-masked]> wrote:
>
>
> On Mar 31, 2016, at 10:26 AM, Francois Le Faucheur <[email-masked]>
> wrote:
>
> Hi Alissa,
>
> Thanks for updating your Discuss to Abstain.
>
>
> As several ADs have pointed out to me offline, it turns out abstain
> doesn’t help you, you need one more yes or no-objection.
>
>
> Right.
>
> So let’s see if I can get there.
>
>
> It may be a moot point now, but just for the record:
>
>
>
>
> Maybe I wasn’t clear in articulating my point. The spec clearly supports
> the ability for the dCDN to decide to send logs about an aggregate of
> clients. That isn’t “telling a content provider” what to log or not, but it
> is providing support for a dCDN to not report a piece of data that would
> have been delivered to the content provider if there were no CDN. If that
> is the point of specifying c-groupid the way that it is specified —
> including normative recommendations clearly designed to ensure that the
> c-groupid does indeed identify an aggregate and not a single client — then
> it seems to me to undermine the whole point of providing an identifier for
> an aggregate if the dCDN then includes a bunch of header fields that
> identify an individual client. The spec shouldn’t pretend to support
> provision for some protections that it actually doesn’t provide given the
> way it’s expected to be implemented. I think at a minimum the draft needs
> to point this out in the paragraph Francois quoted. Personally I don’t
> think making the recommendations in the text about cookies normative gives
> anyone a fuzzier feeling than the text does as-is, but I’m not going to say
> that it’s not worth holding up the document over.
>
>
> Double negations sometimes get me, but I think you meant:
> "but I’m not going to say that it’s worth holding up the document over “,
> right?
>
>
> Sorry for that, writing too quickly. Let’s see if making a concrete
> suggestion will help.
>
> I feel that we shouldn’t specify features that give the pretense of
> privacy protection but don’t actually provide it, without at least making
> that clear. So here is what I would suggest after the paragraph about
> cookies:
>
> "Furthermore, implementers making use of c-groupid to identify an
> aggregate of clients rather than individual clients should realize that by
> logging certain header fields they may create the possibility to
> re-identify individual clients. In these cases heeding the above advice, or
> not logging header fields at all, is particularly important if the goal is
> to provide logs that do not identify individual clients.”
>
>
> I am fine with that extra text.
>
> Just two minor editorials:
> * I would just propose to replace “implementers” by “CDNs” in your text
> above because in the document “implementations” refer to software
> supporting the functionality , while the folks deploying the
> software/functionality are referred to as the “CDNs”. Is that OK?
> * I would propose to replace “should realize” by “ought to realize"
> All good?
>
>
> WFM
>
>
> Thanks for providing a specific suggestion.
>
> Francois
>
>
>
> Alissa
>
>
>
>
>
> I did not demand any edits. I asked a question because the text isn’t
> clear. I don’t care if the standard is MUST use TLS (which means all the
> time) or SHOULD use TLS (which means sometimes). “MUST use TLS sometimes”
> is not a legitimate choice. This is relevant for the IESG to comment on
> because MUST means something specific everywhere we use it, not just in
> this document, and I’d rather not establish a precedent that MUST means
> “use it sometimes.”
>
>
> As discussed, the text was not intended to say “use it sometimes” but
> rather “under such circumstances, it MUST be used” which I believe is a
> perfectly IESG-friendly way to use “MUST”  8^). I think the updated text
> reflects that more clearly now.
>
> Thanks again for working fast with us to resolution.
>
> Francois
>
>
>
> Alissa
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> (1) Per my first DISCUSS point above, I wonder if it makes sense to
> specify a field where the dCDN could report a sanitized version of the
> client User-Agent string. This would allow a uCDN to calculate the
> "terminal type" KPI listed in 2.2.5.5.2 without requiring full,
> potentially identifying User-Agent strings to be logged.
>
>
> I see the idea.
> But I think there are several fields which may contain user identifying
> information.
> So how about we add a statement following the text provided by Stephen to
> the effect that when fields (e.g. User Agent) contain user-identifying
> information they SHOULD be sanitised to remove the sensitive information
> while keeping non-sensitive information (e.g. terminal type) and that the
> sanitisation is to be agreed upon by uCDN and dCDN.
>
>
> Which assumes the uCDN & dCDN are in a position to know which fields
> contains sensitive information and which do not, which in the general case
> neither the uCDN or dCDN are in a position to know.
>
> (2) I think the use of partial-time in 3.4.1 means that the timestamps
> have no time zone information. It's not clear to me how the uCDN uses
> these timestamps in an absolute sense anyway, but I'm wondering if that
> could create problems if the uCDN does not know what time zone the dCDN
> is in. The time information in that case is somewhat meaningless if the
> uCDN needs to know the actual time at which something occurred.
>
>
> I think this is a problem. We could either move to full-time, or stick
> with partial-time but specify that time is always expressed in GMT. I will
> poll the list on that.
>
>
> My vote is for partial-time expressed in UTC.
>
> Ben
>
>
>
>
>

---

From: Barry Leiba <[email-masked]>
Date: Mon, 4 Apr 2016 15:32:21 -0400

> And I echo Francois's thanks.

And yay!  We're now there: Alissa has moved to No Objection.

b