Subject: Re: [CDNi] review of draft-ietf-cdni-logging-08 [Batch 4]

From: <[email-masked]>
Date: Mon, 3 Feb 2014 20:27:43 +0100

Hello fellows IETF-ers,

Last batch of comments from Kevin has been taken care of. Overall, I would like opinions about whether we need to widen the scope of s-sid to go beyond HAS (is it useful in other contexts?) and whether people think we need to say more about 6.3. Privacy (now with Snowden and all that jazz).
See below if you are satisfied with the changes in the text.

If you manage to read until the last line of this e-mail, you get the privilege of buying me a beer in London :)

- section 3.4.1: For all the fields values whos format is QSTRING, the

field value description should be updated to indicate

that the value is not actually "as received" or "as

it appears in the response", etc., but rather that

value encased in double quotes with any double quotes

in that value escaped by an additional double quote?

[IO] Added: Note that the received value consists of
            the characters encased in double quotes with any double quotes
            in that character chain escaped by an additional double quote 
            (e.g., ""double quote"" is received and "double quote" is the 
            actual field value).

- section 3.4.1: I found the following text odd, in that the normative

statement is that the value must be either something or

nothing, which is somewhat tautological. Should this

just be a MAY since its optional?

" there MUST be zero, one or any number of instance"

[IO] I's a MAY now.

- section 3.4.1: For the s-sid field, is the only allowable use of

this field for HAS delivery? Or can the field be

used to group requests for any content? If it is

really the latter, this should be clarified.

" this contains the value of a Session IDentifier

generated by the dCDN for a specific HTTP Adaptive Streaming

(HAS) session"

[IO] I am inclided to think the text is aimed at HAS delivery only, so in my mind the only usage is for HAS. Do people feel that this might be useful for non-HAS sessions?

- section 3.4.1: Is it really the logging implementation that selects

the fields? That does not sound correct to me? I

would suggest removing: "by the implementation

generating the CDNI Logging File" from this text:

"The set

of such fields name actually listed in the "Fields" directive is

selected by the implementation generating the CDNI Logging File based

on agreements between the interconnected CDNs established through"

[IO] Replaced with: "The set of such field names actually listed in the "Fields"
          directive is selected by the CDN generating the CDNI Logging File 
          based on agreements between the interconnected CDNs established [...]"

- section 3.4.1: I would suggestion removing "in that case, " from

this sentance:

"When such a field name is listed in the "Fields"

directive, the corresponding field value MUST be included in the

Logging Record; in that case, if the value for the field is not

available, this MUST be conveyed via a dash character ("-")."

[IO] Done.

- section 3.4.1: Just to clarify, the following text is defining the

MTI fields for dCDNs.

"A dCDN-side implementation of the CDNI Logging interface MUST support

the ability to include valid values for the following Logging Fields"

Would it be valid to always put a dash ("-")? Dash

is a valid value, but does not require the dCDN to

actually support parsing/producing any given field.

[IO] Yes, from what I understand and what I meant when we discussed this, dash "-" is a valid value and those are all fields that are mandatory to implement by the dCDN. So it must be able to produce a logging file containing all of the fields mentioned in the list, even if the only present value is dash "-".

[IO] I added "The following list includes all the logging fields that are mandatory to implement by the CDN producing the logging file."

- section 3.5: The UUID directive is not QSTRING, its NHTABSTRING, so

can I assume that the double quotes are actually part

of the UUID? Or is this example incorrect?

" #UUID:<HTAB>"urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6"<CRLF>"

[IO] I think we were being over-zealous with the double quotes. Pretty impressive attention span and eyesight!!!

- section 4.1: The terms "server-side" and "client-side" essentially

refer to the "dCDN" and "uCDN", respectively, correct?

I think it would be easier to follow if we used "dCDN"

and "uCDN" since client and server are used for other

purposes with other meanings in other parts of the draft.

[IO] I don't understand where the confusion comes from. In this paragraph, client is used as in "the entity issuing a request" and server as in "the entity delivering a response to a previous request". I'm willing to change the text, but to me the current one says pretty clearly that the uCDN implements the client side and the dCDN the server side.

[IO] Is this any better: "An implementation of the CDNI Logging interface as per the present document on the dCDN side (the entity generating the CDNI Logging file) MUST support the server side of the CDNI Logging feed and the server side of the CDNI Logging pull mechanism."?

- section 4.1.1: What is an "IRI"? Should that be "URI" or "URN"?

[IO] URI. Done.

- section 4.1.2: Just to clarify, the "archive document" refers to

past contents of the atom feed, correct? This

section makes no statement about how long old logging

files should be kept for, only how long old atom feed

documents are held for? Should we?

[IO] I think we don't need to over-specify that, as it can be agreed upon between the dCDN and uCDN. There's some text about that in 4.2.1: "The potential retention limits (e.g. sliding time window) within which the dCDN is to retain and be ready to serve an archive document is outside the scope of the present document and is expected to be agreed upon by uCDN and dCDN via other means (e.g.  human agreement). The server-side implementation MUST retain, and be ready to serve,    any archive document within the agreed retention limits.  Outside these agreed limits, the server-side implementation MAY be unable to serve (e.g., with HTTP status code 404) an archive document or MAY refuse to serve it (e.g., with HTTP status code 403 or 410)."

- section 4.2: Do we have thoughts on future HTTP/2.0 support? Not

that I necessarily think that things like multiplexing

would necessarily be beneficial to log retrieval, but

should we consider the possibility of HTTP/2.0

obsoleting HTTP/1.1 in a few years? Would we have to

rev the LI RFC at that point?

" MUST use HTTP v1.1 ( [RFC2616]);"

[IO] Yes, I think we will need to do a revision of the CDNI Logging interface when HTTP/2.0 gets out there. Also applicable to the fields that we have in the current draft, not just for the Logging file transport mechanism.

- section 5.1: Should we add instructions to the implied expert

reviewer requiring that each specification defining a

new directive contain the same type of information for

each directive as in 3.3 (i.e., format, directive

value, and occurrence)?

[IO] Done.

- section 5.2: Should we add instructions to the implied expert

reviewer requiring that each specification defining a

new record-type contain the same type of information

for each field as in 3.4.1 (i.e., field name, format,

field value, and occurrence)?

[IO] Done.

- section 5.3: Should the Field Names registry really be a subregistry

under the Record-types registry? Without the scope of

the Record-Type, these field names cannot be used for

any other Record-Type, e.g., "date" and "time" can only

ever be used by cdni_http_request_v1? Or at a minimum,

they must have the exact same meaning? If that is the

intent, then we may want to make that explicit in the

text.

[IO] I think it's better if we restrict the Field Names to the scope of the Record-type that they are defined in. I'm thinking that because of future extensions: it's easier for people to just copy and paste or refer to a definition of an existing field rather than try to come up with other fields names that might be similar to "date" and "time", but do not have identical meaning as the ones we defined already. 

[IO] Added: "The above Field Name Registry MUST be used only within the scope of the currently defined Record-Type (i.e., cdni_http_request_v1)."

- section 6.1: I believe this is implying that mutual authentication

SHOULD be used? Should that be made explicit?

" the dCDN and uCDN to authenticate each other (to ensure they are

transmitting/receiving CDNI Logging File from an authenticated

CDN)

[IO] Added: "Both parties of the transaction (uCDN and dCDN) SHOULD use mutual authentication." 

- section 6.1: Do we want to make an explicit statement about privacy

of End-User information? And possibly an explicit

statement about the acceptability of alternate methods

for ensuring confidentiality of End-User information

(e.g., an IPSec tunnel between CDNs, or physically

secured internal network between two CDNs owned by the

same corporate entity)?

" the CDNI Logging information to be transmitted with

confidentiality"

[IO] Added: "Alternate methods MAY be used for ensuring the confidentiality of the information in the logging files such as setting up an IPsec tunnel between the two CDNs or a physically secured internal network between two CDNs owned by the same corporate entity."

Note: The privacy section (6.3) talks about

anonymization between dCDN and uCDN, however,

this is more about leaking even anonymized data.

[IO] Oh, this is going to be a long argument and I'm not armed for that. In my opinion, if you don't have the IP address, then you cannot accurately geolocate the End-User. Plus, we're supposed to be hanfling the logging files on top of TLS. Do you have a precise suggestion of what you'd like to be included in this 6.3. Privacy section?

Thank you, Kevin, for this extremely thorough review. Hopefully, now we have a better draft and can soon go to WGLC in London. See you there!

-- iuniana

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Kevin J Ma <[email-masked]>
Date: Mon, 3 Feb 2014 15:39:03 -0500

Iuniana, I guess I owe you a beer.  ;)

> [IO] I don't understand where the confusion comes from. In this paragraph,
> client is used as in "the entity issuing a request" and server as in "the
> entity delivering a response to a previous request". I'm willing to change
> the text, but to me the current one says pretty clearly that the uCDN
> implements the client side and the dCDN the server side.

In section 3.4, client refers to the user-agent and server refers to
the dCDN surrogate.  I agree that section 4 declares the server-side
and client-side of the "CDNI Logging interface" to be the dCDN and the
uCDN, respectively, but it still uses the same terms client and server
for different actors, whereas using dCDN and uCDN would avoid the
naming overlap all together.  I don't feel strongly about this.  If no
one else cares, then we can leave it.

> [IO] Oh, this is going to be a long argument and I'm not armed for that.
> In my opinion, if you don't have the IP address, then you cannot
> accurately geolocate the End-User. Plus, we're supposed to be hanfling the
> logging files on top of TLS. Do you have a precise suggestion of what
> you'd like to be included in this 6.3. Privacy section?

I was actually thinking about a few things here:
1) even with anonymized IP addresses, course level statistical
   analysis still yields information about traffic patterns.
2) even without IP addresses, cookies and query strings may have
   personal information in them that may be identifying.
3) for the content providers, information about the popularity (or
   the lack there of) of specific assets might be sensitive.
All of this may be obvious to those who view log files regularly and
perhaps it doesn't make sense to list them explicitly.  I only bring
it up because one might infer from Section 6.3 that we think that only
IP addresses matter.  I could go either way on this one.  The whole
privacy thing can be a big rat hole, but I figured I'd bring it up.

thanx.

--  Kevin J. Ma

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, February 03, 2014 2:28 PM
> To: Kevin J Ma; <[email-masked]>
> Subject: RE: [CDNi] review of draft-ietf-cdni-logging-08 [Batch 4]
>
> Hello fellows IETF-ers,
>
> Last batch of comments from Kevin has been taken care of. Overall, I would
> like opinions about whether we need to widen the scope of s-sid to go
> beyond HAS (is it useful in other contexts?) and whether people think we
> need to say more about 6.3. Privacy (now with Snowden and all that jazz).
> If you manage to read until the last line of this e-mail, you get the
> privilege of buying me a beer in London :)
>
>
>
> [IO] I am inclided to think the text is aimed at HAS delivery only, so in
> my mind the only usage is for HAS. Do people feel that this might be
> useful for non-HAS sessions?
>
>
>
> [IO] Yes, from what I understand and what I meant when we discussed this,
> dash "-" is a valid value and those are all fields that are mandatory to
> implement by the dCDN. So it must be able to produce a logging file
> containing all of the fields mentioned in the list, even if the only
> present value is dash "-".
>
> [IO] I added "The following list includes all the logging fields that are
> mandatory to implement by the CDN producing the logging file."
>
>
>
>
> [IO] I think we were being over-zealous with the double quotes. Pretty
> impressive attention span and eyesight!!!
>
>
>
>
> [IO] I don't understand where the confusion comes from. In this paragraph,
> client is used as in "the entity issuing a request" and server as in "the
> entity delivering a response to a previous request". I'm willing to change
> the text, but to me the current one says pretty clearly that the uCDN
> implements the client side and the dCDN the server side.
>
> [IO] Is this any better: "An implementation of the CDNI Logging interface
> as per the present document on the dCDN side (the entity generating the
> CDNI Logging file) MUST support the server side of the CDNI Logging feed
> and the server side of the CDNI Logging pull mechanism."?
>
>
>
>
> [IO] I think we don't need to over-specify that, as it can be agreed upon
> between the dCDN and uCDN. There's some text about that in 4.2.1: "The
> potential retention limits (e.g. sliding time window) within which the
> dCDN is to retain and be ready to serve an archive document is outside the
> scope of the present document and is expected to be agreed upon by uCDN
> and dCDN via other means (e.g.  human agreement). The server-side
> implementation MUST retain, and be ready to serve,    any archive document
> within the agreed retention limits.  Outside these agreed limits, the
> server-side implementation MAY be unable to serve (e.g., with HTTP status
> code 404) an archive document or MAY refuse to serve it (e.g., with HTTP
> status code 403 or 410)."
>
>
>
>
> [IO] Yes, I think we will need to do a revision of the CDNI Logging
> interface when HTTP/2.0 gets out there. Also applicable to the fields that
> we have in the current draft, not just for the Logging file transport
> mechanism.
>
>
>
>
> [IO] I think it's better if we restrict the Field Names to the scope of
> the Record-type that they are defined in. I'm thinking that because of
> future extensions: it's easier for people to just copy and paste or refer
> to a definition of an existing field rather than try to come up with other
> fields names that might be similar to "date" and "time", but do not have
> identical meaning as the ones we defined already.
>
> [IO] Added: "The above Field Name Registry MUST be used only within the
> scope of the currently defined Record-Type (i.e., cdni_http_request_v1)."
>
>
>
>
> [IO] Added: "Alternate methods MAY be used for ensuring the
> confidentiality of the information in the logging files such as setting up
> an IPsec tunnel between the two CDNs or a physically secured internal
> network between two CDNs owned by the same corporate entity."
>
>
>
>
> [IO] Oh, this is going to be a long argument and I'm not armed for that.
> In my opinion, if you don't have the IP address, then you cannot
> accurately geolocate the End-User. Plus, we're supposed to be hanfling the
> logging files on top of TLS. Do you have a precise suggestion of what
> you'd like to be included in this 6.3. Privacy section?
>
>
> Thank you, Kevin, for this extremely thorough review. Hopefully, now we
> have a better draft and can soon go to WGLC in London. See you there!
>
> -- iuniana
>
> __________________________________________________________________________
> _______________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;