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

From: <[email-masked]>
Date: Thu, 28 Nov 2013 00:15:56 +0100

Hey Kevin and all,

I guess I should thank you for this extensive review of the draft. I suppose you like Daryl more than me, because this is making his life easier but is giving François and me more work. :)

I did take into account your comments until somewhere in the middle of section 3.4.1 and did the editorial nits. See below:

- section 3.3: I think we should define a restriction on DIRNAME to be

not COLON (":")? Perhaps even just alphanumberic plus

dash and underscore? This should be enforced by the

IANA reviewer?

[IO] You are definitely right about excluding ":". I suggest to add the following paragraph in section 5.1:

The IANA is requested to create a new registry, CDNI Logging Directive Names. A Directive Name is an alphanumeric character string with the additional characters "-" and "_" that can be optionally used.

[IO] In 3.1 Rules, we add:

ALPHA = %x41-5A / %x61-7A ; A-Z / a-z

ALPHANUM = ALPHA / DIGIT

DIRNAME = ALPHANUM 0*1( "-" / "_" ) *ALPHANUM

[IO] Is this DIRNAME too constrained now?

- section 3.3: The DIRVAL should be specified by the reference

document in the CDNI Logging Directive Names registry

(Section 5.1). The BNF should note that. The fact

that the initial directives are defined in this

document is a degenerate case of generic DIRVALs.

" DIRVAL = <directive value as specified below for each directive

name>"

[IO] Do you want to specify a directive value for each directive in the ABNF and then have them as alternatives enumerated in the generic DIRVAL rule?

DIRVAL-Version = "CDNI" "/" 1*DIGIT "." 1*DIGIT

DIRVAL-UUID = NHTABSTRING

DIRVAL-Claimed-Origin = host

DIRVAL-Verified-Origin = host

DIRVAL-Record-Type = NHTABSTRING

DIRVAL-Fields = FIENAME *<HTAB FIENAME>

DIRVAL-Integrity-Hash = 32HEXDIG

DIRVAL = DRIVAL-Version / DIRVAL-UUID / DIRVAL-Claimed-Origin / DIRVAL-Verified-Origin /DIRVAL-Record-Type / DIRVAL-Fields / DIRVAL-Integrity-Hash

- section 3.3: For any directive with a format defined as NHTABSTRING,

don't we also need to exclude CRLF from the string?

[IO] Yes, I think it's more precise to exclude HTAB and CRLF. So in 3.1 NHTABSTRING = *NHTAB; where NHTAB = <any OCTET excluding HTAB and CRLF>.

- section 3.3: For the Record-Type directive, I think it would be more

clear to change: "precede any CDNI Logging Record" ->

"MUST precede all CDNI Logging Records"

[IO] OK. The last phrase in Record-Type becomes "The first instance of this

directive MUST precede a Fields directive and MUST precede all CDNI

Logging Records."

- section 3.3: I think we should define a restriction on FIENAME to be

not HTAB and not CRLF? Perhaps even just alphanumberic

plus dash and underscore? This should be enforced by

the IANA reviewer?

[IO] I think excluding HTAB and CRLF would be ok in theory. I think alphanumeric plus "-" and "_" is maybe just too rigid?

- section 3.3: It was not clear to me initially, what this sentance is

attempting to say. 3.4 has an example of a logging

record and its list of fields, but it's not the only

possible logging record, it's just the first one

defined. When I first read this, I interpreted it as

all possible logging records are defined in 3.4.

" The names of the fields, as well as their

possible occurrences, are specified for each type of CDNI

Logging Records in Section 3.4."

Perhaps it couldbe clarified to say something like:

" The names of the fields, as well as their

possible occurrences, MUST be specified in the referenced

document of the CDNI Logging Record-types registry (Section

5.2), for each CDNI Logging Record-Type. This document

defines the names of the fields, as well as their possible

occurrences, for the "cdni_http_request_v1" Record-Type in

Section 3.4.1."

[IO] Done by François.

- section 3.3: Just to clarify, this statement asserts that the file

is "non-corrupted", but makes no guarantee that it is

tamper-proof or tamper-evident (a la MITM attack)?

" If the

two values are equal, then the received CDNI Logging File MUST

be considered non-corrupted."

[IO] That is correct. Remember the long discussions we had about non-repudiation? In the end, I think the general idea was that authentication and confidentiality for the logging files are handled by using HTTPS in the ATOM protocol.

- section 3.4.1: For any field value with a format defined as

NHTABSTRING, don't we also need to exclude CRLF from

the string?

[IO] Done.

- section 3.4.1: For protocol, do we want this to be extensible to

HTTP/2.0? Does the normative reference to RFC2616

restrict this to HTTP/1.0 and HTTP/1.1?

I had assumed that the v1 in "cdni_http_request_v1"

referred to the Logging Record version, but perhaps

it instead refers to the HTTP version? This is

probably worth clarifying.

[IO] Added the following to the description of Record-Type: "Note that the cdni_http_request_v1 Record-Type directive refers strictly to the set of Logging Records encompassed by the current version of this document. At the time of publishing, it includes HTTP/1.0 and HTTP/1.1 requests as specified in RFC 2616".

- section 3.4.1: In the sc-total-bytes and sc-entity-bytes field value

descriptions, the parenthetical references to HTTP

headers seems to imply some inherent relationship

between the headers and the status line, which I do

not believe exists, per section 6 of RFC2616.

" This includes the bytes of the Status-Line (including HTTP

headers)"

" This does not include the bytes of the Status-Line

(and therefore does not include the bytes of the HTTP headers)".

I think it would be clearer to say:

" This includes the bytes of the Status-Line and the bytes

of the HTTP headers"

" This does not include the bytes of the Status-Line

or the bytes of the HTTP headers".

[IO] Done.

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

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

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

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

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

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

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

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

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

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

- 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]);"

- 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)?

- 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)?

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

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

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

Note: The privacy section (6.3) talks about

anonymization between dCDN and uCDN, however,

this is more about leaking even anonymized data.

- appendix A: Is this going to be removed?

[IO] From what I hear, yes. Do you want to keep it? :)

nits:

- section 1.1: "real time" -> "real-time"

- section 2.1: ", uCDN uses" -> ", the uCDN uses"

- section 2.1: "delivery operated by" -> "delivery performed by"

- section 2.1: "non real-time" -> "non-real-time"

- section 2.1: "to CSP." -> "to the CSP."

- section 2.1: ", uCDN merges" -> ", the uCDN merges"

- section 2.1: ". uCDN may also" -> ". the uCDN may also"

- section 2.1: "on his behalf." -> "on the CSP's behalf."

- section 2.1: "e.g., dCDN-3" -> "i.e., dCDN-3"

- section 2.1: "format that are" -> "formats that are"

- section 2.2: "more or less" -> "more or fewer"

- section 2.2: "i.e., there may be" -> "e.g., there may be"

- section 2.2.3: "may require to" -> "may be required to"

- section 2.2.3: "by every Surrogate" -> "by each Surrogate"

- section 2.2.3: "hostnames is not" -> "hostnames are not"

- section 2.2.4: "real time" -> "real-time"

- section 2.2.5.6.2: "uCDN and dCDN may" -> "the uCDN and dCDN may"

- section 2.2.5.6.2: "Top 10 of the most" -> "Top 10 most"

- section 3.2: "CDNI logging field" -> "CDNI Logging Field"

- section 3.2: "close to intra-CDN logging format" ->

"close to the intra-CDN Log format"

- section 3.3: "File ." -> "File."

- section 3.3: "to HTTP request" -> "to HTTP requests"

- section 3.3: "each type of CDNI Logging Records" ->

"each type of CDNI Logging Record"

- section 3.4.1: "prededing" -> "preceding"

- section 3.4.1: "any number of instance" -> "any number of instances"

- section 3.4.1: "dCDN i.e." -> "dCDN, i.e., "

- section 3.4.1: "MUST list all the fields name whose" ->

"MUST contain all the field names whose"

- section 3.4.1: "The fields name" -> "The field names"

- section 3.4.1: "cs- method" -> "cs-method"

- section 3.4.1: "sc- total-bytes" -> "sc-total-bytes"

- section 4: "each of these CDNI Logging File" ->

"each of these CDNI Logging Files"

- section 4: "at the uCDN convenience" -> "at the uCDN's convenience"

- section 4: "as per the present document generating CDNI Logging file" ->

", as per the present document, generating CDNI Logging files"

- section 4: "as per the present document consuming CDNI Logging file" ->

", as per the present document, consuming CDNI Logging files"

- section 4: "document ." -> "document."

- section 4.1.2: "MAY be unable to serve" ->

"MAY indicate its inability to serve"

- section 4.1.3: "redundancy, CDNI Logging" -> "redundancy. CDNI Logging"

- section 4.2: "( [RFC2616])" -> "[RFC2616]"

- section 4.2: "MAY be unable to serve" ->

"MAY indicate its inability to serve"

- section 6.3: "such as how much bytes of the content has been watched" ->

"such as how many bytes of the content have been watched"

[IO] Nits are done.

_________________________________________________________________________________________________________________________

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: Wed, 27 Nov 2013 19:01:43 -0500

Hi Iuniana,

  My goal is your unequivocal success in pre-empting Daryl.  ;-P

> [IO] Is this DIRNAME too constrained now?

  I was primarily concerned with the colon.
  I don't feel strongly about the alphanumeric thing.

> [IO] I think excluding HTAB and CRLF would be ok in theory. I think
> alphanumeric plus "-" and "_" is maybe just too rigid?

  Same here.  My primary concern is the CRLF

> " DIRVAL = <directive value as specified below for each directive name>"
>
> [IO] Do you want to specify a directive value for each directive in the
> ABNF and then have them as alternatives enumerated in the generic DIRVAL
> rule?

  I was actually just thinking that the text be changed to something like:

  " DIRVAL = <directive value as specified in the reference for the
    associated DIRNAME in the CDNI Logging Directive Names registry
    (Section 5.1)>"

  to match the DIRNAME definition

  " DIRNAME = any CDNI Logging Directive name registered in the CDNI
    Logging Directive Names registry (Section 5.1)."

> [IO] From what I hear, yes. Do you want to keep it? :)

  Definitely not.  But, I did not bother to review it, so if it ends up
  staying, I need to go back and look it over.

thanx.

--  Kevin J. Ma

> -----Original Message-----
> From: CDNi [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Wednesday, November 27, 2013 6:16 PM
> To: <[email-masked]>
> Subject: [CDNi] review of draft-ietf-cdni-logging-08 [Batch 3]
>
> Hey Kevin and all,
>
> I guess I should thank you for this extensive review of the draft. I
> suppose you like Daryl more than me, because this is making his life
> easier but is giving François and me more work. :)
>
>
>
> I did take into account your comments until somewhere in the middle of
> section 3.4.1 and did the editorial nits. See below:
>
>
>
> The IANA is requested to create a new registry, CDNI Logging Directive
> Names. A Directive Name is an alphanumeric character string with the
> additional characters "-" and "_" that can be optionally used.
>
> [IO] Do you want to specify a directive value for each directive in the
> ABNF and then have them as alternatives enumerated in the generic DIRVAL
> rule?
>
> DIRVAL = DRIVAL-Version / DIRVAL-UUID / DIRVAL-Claimed-Origin / DIRVAL-
> Verified-Origin /DIRVAL-Record-Type / DIRVAL-Fields / DIRVAL-Integrity-
> Hash
>
>
>
> [IO] Yes, I think it's more precise to exclude HTAB and CRLF. So in 3.1
> NHTABSTRING = *NHTAB; where NHTAB = <any OCTET excluding HTAB and CRLF>.
>
> [IO] I think excluding HTAB and CRLF would be ok in theory. I think
> alphanumeric plus "-" and "_" is maybe just too rigid?
>
>
>
> [IO] That is correct. Remember the long discussions we had about non-
> repudiation? In the end, I think the general idea was that authentication
> and confidentiality for the logging files are handled by using HTTPS in
> the ATOM protocol.
>
> [IO] Added the following to the description of Record-Type: "Note that the
> cdni_http_request_v1 Record-Type directive refers strictly to the set of
> Logging Records encompassed by the current version of this document. At
> the time of publishing, it includes HTTP/1.0 and HTTP/1.1 requests as
> specified in RFC 2616".
>
> __________________________________________________________________________
> _______________________________________________
>
> 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;
> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni