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

From: "Alissa Cooper" <[email-masked]>
Date: Fri, 25 Mar 2016 11:27:19 -0700

Alissa Cooper has entered the following ballot position for
draft-ietf-cdni-logging-23: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-cdni-logging/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I appreciate all the work that has gone into this document. It was
originally up for IESG review when I was on leave, so I was not able to
review it at that time. The document needs one more ballot to progress,
so I told Spencer I would review it. I realize it's probably frustrating
to see another DISCUSS at this point but these should be straightforward
to resolve I think.

(1)
I am wondering about a potential inconsistency that I see in Section
3.4.1. I see with the definition of the c-groupid field that there is
inherent support for reporting about clients as aggregates, which is
great, and even when reporting is done about individual clients there are
a bunch of normative recommendations to try to reduce the chances that a
logging field will be tied back to an individual user or host. Excellent.
But then with the definition of the cs(insert_HTTP_header_name_here)
field and discussion about it, there is no equivalent normative guidance
given about not including headers that could potentially be used to
identify an individual user or host. There is discussion about cookies
but none of it is normative, and cookies are not the only headers that
could be identifying. In fact, one of the examples given -- User-Agent --
is known to be identifying in some cases.

Given the extent to which the specification of c-groupid goes to support
masking the identity of the host, I would expect normative guidance about
the use of the header field. That is, if an implementation is using
c-groupid to represent an aggregate, it would make sense to me that it
MUST NOT include header fields that could be uniquely identifying. I also
wonder if the recommendations about cookies in 3.4.1 could be made
normative. I will say that based on the use cases for these logs listed
in 2.2.5 it's hard to understand what a uCDN needs headers like cookies
for on a consistent basis; if they're needed for an occasional
troubleshoot, logging them consistently seems like overkill.

(2)
Section 7.1 says:

"In an environment where any such protection is required, mutually
   authenticated encrypted transport MUST be used to ensure
   confidentiality of the logging information.  To that end, TLS MUST be
   used (including authentication of the remote end) by the server-side
   and the client-side of the CDNI Logging feed, as well as the server-
   side and the client-side of the CDNI Logging File pull mechanism."

I know this text has been the subject of much discussion and careful
editing, and that I raised an issue on this on the redirection draft.
What I don't understand from reading this is whether the expectation is
that all servers and clients implementing this specification will use
TLS. The first sentence seems to indicate that there will be cases when
that is not true. The second sentence says MUST use, which means use in
every case. Which is it?

----------------------------------------------------------------------
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.

(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.

---

From: Barry Leiba <[email-masked]>
Date: Fri, 25 Mar 2016 15:38:51 -0400

For the authors/chairs:
There's quite a premium on getting Alissa's comments resolved to
everyone's satisfaction by the end of March.  If we can't, then three
ballots become invalid (mine, Brian's, and Martin's), and Spencer will
need to get three more reviews from among the five who didn't ballot
and the three new ADs.  That's certainly possible, but you can see how
it'll be much easier if Alissa's can be the last ballot needed.

Let's not let haste push us into bad decisions... but let promptness
and quick work rule here.  Thanks.

Barry

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Fri, 25 Mar 2016 21:59:10 +0000

Noted. I will work on this next Tuesday. 
Up in the mountains till then. 
Thanks

Sent from my iPhone

> On 25 Mar 2016, at 20:38, Barry Leiba <[email-masked]> wrote:
> 
> For the authors/chairs:

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Sat, 26 Mar 2016 17:06:22 -0500

Thank all of you for the last minute effort here.

I'll be traveling on Thursday evening/Friday morning, but will be watching
closely otherwise.

If you'll be traveling, please travel safely!

Spencer

On Friday, March 25, 2016, Francois Le Faucheur (flefauch) <
[email-masked]> wrote:

> > On 25 Mar 2016, at 20:38, Barry Leiba <[email-masked]
> <javascript:;>> wrote:
> >
> > For the authors/chairs:
> >> On Fri, Mar 25, 2016 at 2:27 PM, Alissa Cooper <[email-masked]
> <javascript:;>> wrote:
> >> Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html

---

From: Francois Le Faucheur <[email-masked]>
Date: Wed, 30 Mar 2016 22:51:55 +0200

Hello Alissa,

This makes sense, and Stephen Farrell expressed the same concern. He suggested to add the following text, which was incorporated in section 3.4.1 right after the definition of all fields:

"Logging some specific fields from HTTP requests and responses can
   introduce serious security and privacy risks.  For example, cookies
   will often contain (months) long lived token values that can be used
   to log into a service as the relevant user.  Similar values may be
   included in other header fields or within URLs or elsewhere in HTTP
   requests and responses.  Centralising such values in a CDNI Logging
   File can therefore represent a significant increase in risk both for
   the user and the web service provider, but also for the CDNs
   involved.  Implementations ought therefore to attempt to lower the
   probability of such bad outcomes e.g. by only allowing a configured
   set of headers to be added to CDNI Logging Records, or by not
   supporting wildcard selection of HTTP request/response fields to add.
   Such mechanisms can reduce the probability that security (or privacy)
   sensitive values are centralised in CDNI Logging Files.  Also, when
   agreeing on which HTTP request/response fields are to be provided in
   CDNI Logging Files, the uCDN and dCDN administrators ought to
   consider these risks.
“
Does that work for you?
Or do you feel there ought to be some normative language (suggestions welcome)?

> that is not true. The second sentence says MUST use, which means use in

The answer to your question is meant to be conveyed by “To that end”.
In other words: When protection is needed, authenticated encrypted transport MUST be used. And when this is done, it MUST be achieved using TLS.

Can you leave with "to that end” ?

If not, how about:
  confidentiality of the logging information, and to do so TLS MUST be
?

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.

> 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.

Thanks

Francois

---

From: Francois Le Faucheur <[email-masked]>
Date: Wed, 30 Mar 2016 22:55:26 +0200

Folks,

Francois

---

From: Kevin Ma J <[email-masked]>
Date: Wed, 30 Mar 2016 21:00:00 +0000

I thought the time was always UTC?

https://tools.ietf.org/html/rfc3339#section-4.1

> -----Original Message-----
> From: CDNi [mailto:[email-masked]] On Behalf Of Francois Le
> Faucheur
> Sent: Wednesday, March 30, 2016 4:55 PM
> To: <[email-masked]>
> Subject: [CDNi] Time Format for cdni-logging (Fwd: Alissa Cooper's Discuss
> on draft-ietf-cdni-logging-23)
> 
> Folks,
> 
> > 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.
> 
> Francois
> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 31 Mar 2016 01:20:17 +0100

All,

I’m not an author on this document but for what it’s worth my 2p opinion is inline below.

> On 30 Mar 2016, at 21:51, Francois Le Faucheur <[email-masked]> wrote:

IMO no, there should not be any normative language. Including normative language presupposes that the set of header fields that expose user identifiable material is well known and well defined and that is not the case. Logging these fields exposes no more to the content provider than they would obtain had they not used a CDN. CDNs (uCDNs & dCDNs in the case of CDNI) are gateways/“delegated origins” operating on behalf of the content provider. Who are we to tell a content provider what they can & cannot log?

A user agent under the control of the content provider (e.g. mobile application) can send header fields containing anything the content provider desires and there is no way to account for all those scenarios in the document. It doesn’t even have to be header fields. I am aware of deployments where the user’s username & zip code are included as query parameters in the URL. That’s horrible for user privacy but there’s no way to construct normative language that will account for that case and no way to construct normative language that accounts for user identifying header fields either because from the perspective of the dCDN, the values of the URL or special headers are opaque to the dCDN.

Having some discussion of the risks (as the above text outlines) is fine & probably a good thing IMO, trying to construct normative text serves no purpose IMO except giving folks a warm fuzzy feeling that they’ve protected user privacy without doing actually doing so. I thought our role here was to produce interoperable standards, not to be the Internet privacy police.

I also wonder whether including normative text for this would actually achieve the opposite of the desired effect - i.e. having normative text may cause some implementers to assume that all privacy-related scenarios have been covered and lead folks to follow the normative text and not consider the privacy implications of header fields/etc not explicitly called out by the document?

>  side and the client-side of the CDNI Logging File pull mechanism."

Personally I find the relentless wordsmithing of this text to be incredibly tiresome. Way back at the beginning we had text that essentially said “you need to authenticate & encrypt the transport and in the absence of anything else use TLS” and we’ve slowly creeped towards “MUST use TLS and nothing else”. I must have missed the memo that said that TLS is the panacea for authenticated & encrypted transport and that VPNs and other approaches have been deprecated in favour of TLS.

I’ve said in other threads that for the CDNI documents I edit, I’ll include whatever text is agreed for this logging document and I will do that, but I strongly believe that folks will implement what their customers’ want and that folks will deploy what makes sense for them irrespective of what we write in our documents. Further wordsmithing of the text is pure theatre IMO and adds no additional value or clarity to the document IMO.

IMO this is a good example of the IESG demanding edits that go beyond what is required to meet the bar for Proposed Standard. I see nothing in the original text (or any of the previous versions of the same section) that contradicts the requirements for Proposed Standard described in section 3.1 of RFC7127 or that will materially improve interoperability. Changing the text does nothing except waste more time in tiresome debate IMO. We should just accept the text as-is and move on to more important things IMO.

> 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 s…

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. 

> 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: Francois Le Faucheur <[email-masked]>
Date: Thu, 31 Mar 2016 08:04:14 +0200

All,

UTC works fine. But I think we need to be explicit about it. Let me know if you have any comment on this proposed change:

OLD:
"
   o  time:

      *  format: TIME

      *  field value: the time at which the processing of request completed on the Surrogate.
“

NEW:
“
   o  time:

      *  format: TIME

      *  field value: the time, expressed in Coordinated Universal Time (UTC), at which the processing of request
         completed on the Surrogate.
"

Francois

> On 30 Mar 2016, at 23:00, Kevin Ma J <[email-masked]> wrote:
>

---

From: Kevin Ma J <[email-masked]>
Date: Thu, 31 Mar 2016 11:06:02 +0000

The proposed text works for me.  thanx.

Sent from my iPhone

> On Mar 31, 2016, at 2:04 AM, Francois Le Faucheur <[email-masked]> wrote:
> 
> All,
>

---

From: Francois Le Faucheur <[email-masked]>
Date: Thu, 31 Mar 2016 18:18:52 +0200

Alissa,

(as document editor)

In an attempt to work towards closure, please see below:

> On 31 Mar 2016, at 02:20, Ben Niven-Jenkins <[email-masked]> wrote:
> 
> All,
> 

I think Ben makes a valid argument that a CDN may not be in a position to comply to any normative behaviour.
So can we stick to the text above recommended by Stephen to discuss the issue, raise concern and make suggestions and leave it at that?

> IMO this is a good example of the IESG demanding edits that go beyond what is required to meet the bar for Proposed Standard. I see nothing in the original text (or any of the previous versions of…

I agree with Ben we need to move on on that topic. But I think the change I propose above is purely editorial and for clarification, so doing that last change should not destabilise anything. So, Alissa, please tell us whether the current text is acceptable, or if you prefer the proposed change text.

> 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. 

This is back to the earlier point. Given, as Ben points out, that the CDN may not be in a position to comply to any normative language and given there is text recommended by Stephen to discuss the issue, raise concern and make suggestions, can we leave it at that?

> My vote is for partial-time expressed in UTC.

As agreed on the list, the next rev will specify the “time” field value is expressed in UTC, which solves the concern.

Francois

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 31 Mar 2016 10:11:51 -0700

Hi Ben and all,

> On Mar 30, 2016, at 5:20 PM, Ben Niven-Jenkins <[email-masked]> wrote:
> 
> All,
> 

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. 

> IMO this is a good example of the IESG demanding edits that go beyond what is required to meet the bar for Proposed Standard. I see nothing in the original text (or any of the previous versions of…

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.”

Alissa

---

From: [email-masked]
Date: Thu, 31 Mar 2016 18:10:07 +0100

Hello all,

(as document editor as well)

I think the change regrading the time stamps being UTC is a valid point and once it's cleared that should allow us to move this document forward. 

Regarding the other comments, I think they are valuable and would certainly make the specification very privacy-friendly. Unfortunately we don't really have the time and I have personally lost motivation to make it perfect. The conversation about the cookie header being logged was an indication of how things could become privacy unfriendly and we established that CDNI cannot go and do a thorough analysis of all possible combinations of headers and what information can be inferred from them. I think a thorough analysis of what is a perfectly private profile for logging would take a very long time. I think the statements currently included in the draft are good enough and if we're happy with "good enough" and done now rather than "perfect" and done in another year or so, then we can stick with the current text.

Alissa, how strongly do you feel about your previous comments? Are they absolutely essential and are they a show stopper?

Thanks every for the effort put into this,
--iuniana

---

From: Francois Le Faucheur <[email-masked]>
Date: Thu, 31 Mar 2016 19:20:14 +0200

>>>> side and the client-side of the CDNI Logging File pull mechanism.”
>>>> ?
> 
> This is better, thanks.
> 
> Alissa

Change incorporated in the next rev.

Thanks

Francois

---

From: Francois Le Faucheur <[email-masked]>
Date: Thu, 31 Mar 2016 19:26:32 +0200

Hi Alissa,

Thanks for updating your Discuss to Abstain.

> 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…

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?

> 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…

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

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 31 Mar 2016 10:17:59 -0700

Hi Francois,

> On Mar 31, 2016, at 9:18 AM, Francois Le Faucheur <[email-masked]> wrote:
> 
> 
>> 
>> 
>>>> (2)
>>>> Section 7.1 says:
>>>> 

This is better, thanks.

Alissa

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 31 Mar 2016 10:22:05 -0700

Hi Iuniana,

> On Mar 31, 2016, at 10:10 AM, [email-masked] wrote:
> 
> Hello all,
> 

I moved to abstain.

Alissa

---

From: Francois Le Faucheur <[email-masked]>
Date: Thu, 31 Mar 2016 19:51:53 +0200

> 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,
>> 
> 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.
> 
>> 
> 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?

Thanks for providing a specific suggestion.

Francois

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 31 Mar 2016 10:43:48 -0700

> 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. So let’s see if I can get there.

Alissa

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 31 Mar 2016 10:58:35 -0700

> 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] <mailto:[email-masked]>> wrote:
>> 
>> 
>>> On Mar 31, 2016, at 10:26 AM, Francois Le Faucheur <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> Hi Alissa,
>>> 

WFM

---

From: Francois Le Faucheur <[email-masked]>
Date: Thu, 31 Mar 2016 20:00:51 +0200

I will post a new version with all the agreed text as soon as posting reopens.

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] <mailto:[email-masked]>> wrote:
>> 
>>>

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 31 Mar 2016 11:06:08 -0700

> On Mar 31, 2016, at 11:00 AM, Francois Le Faucheur <[email-masked]> wrote:
> 

Great. I’ll update my ballot when it gets posted.

Alissa

>> On 31 Mar 2016, at 19:58, Alissa Cooper <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 31 Mar 2016 20:10:39 -0500

> Great. I’ll update my ballot when it gets posted.

As the AD responsible for this draft, I'd like to thank everyone for the
quick and intense responses.

Spencer

p.s. I think the time difference is immaterial now (Friday versus Monday
when posting reopens anyway, and I suspect that at least half the people
who would need to notice the new version are either at the airport or about
to be at the airport), but I routinely approve draft postings when they're
in IESG evaluation and automatic posting is closed.

Just so people can file that away, for future use.

> 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.
>
> 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.
>
>
> 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 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 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.
>
> 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.
>