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

From: Kevin J Ma <[email-masked]>
Date: Sat, 9 Nov 2013 15:04:04 -0500

Hi All,

  As per the chair's edict, I have produced a detailed review of
  draft-ietf-cdni-logging-08, within the allotted seven days.

  Note: There are a lot of comments.  I was pretty nit-picky in
        the hope of making Daryl's life easier.  Sorry Iuniana.  ;-)

thanx.

--  Kevin J. Ma

comments:

- general: There is inconsistency between the use of "End-User" and
           "End User", with one stray "end user" and a stray "enduser".
           These should be cleaned up for consistency.

- general: There is an inconsistency with comma usage after "i.e." (vs.
           "i.e.,") and "e.g." (vs. "e.g.,").  These should be cleaned
           up for consistency.

- general: What does "in future version of this document" mean?  Does
           it mean a new RFC that obsoletes this RFC?  Should these
           notes instead refer to a future version of the protocol?
           Or should they just state that things are out of scope?

- section 1.1: wrt the following statement:

    "we use the word "Log" only for referring to internal CDN
     logs and we use the word "Logging" for any inter-CDN information
     exchange and processing operations related to CDNI Logging interface."

               should use of the lower case "log" and "logging"
               throughout the document be interpreted as generic
               terms, without distinction for local CDN vs CDNI?
               Certain cases seem as though they should be capitalized.
               I did not enumerate these in this review.

- section 2.2.4: I found this clause to be very confusing:

    "In the case where the log-generating entities have generated during-
     generation aggregate logs"

                 Perhaps it would be easier to just say:

    "In the case where aggregate logs have been generated"

- section 3.2: The first sentance notes that Logging Fields and
               Records are defined in 1.1.  Logging Files are also
               defined in 1.1, but the second sentance caused me to
               second guess this:

    "As defined in Section 1.1 a CDNI logging field is as an atomic
     logging information element and a CDNI Logging Record is a collection
     of CDNI Logging Fields containing all logging information
     corresponding to a single logging event.  This document defines a
     third level of structure, the CDNI Logging File, that is a collection
     of CDNI Logging Records."

                 Perhaps it would be more clear to just say:

    "As defined in Section 1.1: a CDNI logging field is as an atomic
     logging information element, a CDNI Logging Record is a collection
     of CDNI Logging Fields containing all logging information
     corresponding to a single logging event, and a CDNI Logging File
     contains is a collection of CDNI Logging Records."

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

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

- section 3.3: For any directive with a format defined as NHTABSTRING,
               don't we also need to exclude CRLF from the string?

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

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

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

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

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

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

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

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

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"

---

From: Daryl Malas <[email-masked]>
Date: Tue, 12 Nov 2013 01:41:34 +0000

Thanks, Kevin.  I greatly appreciate it, both timing and detail!!  ‹Daryl

On 11/9/13, 1:04 PM, "Kevin J Ma" <[email-masked]> wrote:

>_______________________________________________
>CDNi mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/cdni

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Tue, 12 Nov 2013 17:26:24 +0000

Hi Kevin and all,

(as an editor)

Thanks very much for this timely and exhaustive review.

Please see proposed resolution below for a first batch of comments .

>           These should be cleaned up for consistency.

Converted all occurences to "End User" as defined in RFC 6707.
(BTW, also fixed some "User-Agent"/"User Agent" inconsistencies")

>           "i.e.,") and "e.g." (vs. "e.g.,").  These should be cleaned

Converted to "i.e.," and "e.g.,".

(Just curious: have you published a book before, or just have a rigorous mind?  I'm asking because the very few people I have met so far who paid attention to punctuation after "i.e." had become sensitive to it after going through professionnal edition).

>           Or should they just state that things are out of scope?

Cleaned up to "… is/are for further study and outside the scope of this document."
(except in Appendix A - cleaned up to "in future version of the protocol"- but this Appendix will be removed before publication].

>               I did not enumerate these in this review.

The following sentence was removed altogether:
"
we use the word "Log" only for referring to internal CDN
    logs and we use the word "Logging" for any inter-CDN information
    exchange and processing operations related to CDNI Logging interface."
"

The defintions were cleaned up to:
"
Intra-CDN Logging information: logging information generated and collected within a CDN. The format of the Intra-CDN Logging information may be different to the format of the CDNI Logging information.

CDNI Logging information: logging information exchanged across CDNs using the CDNI Logging Interface.

Logging information: logging information generated and collected within a CDN or obtained from another CDN using the CDNI Logging Interface.
"

The text was cleaned up to use "Intra-CDN Logging information" or "CDNI Logging information" or "Logging information" as appropriate. There is only one or two occurences where "logging information" was used in non-capitalised form because it was a generic reference.

BTW: I also cleaned up many occurences of inconsistent use of "CDNI Logging file" instead of "CDNI Logging File".

> - section 2.2.4: I found this clause to be very confusing:

Agreed.

>    "In the case where aggregate logs have been generated"

Fixed to :
"In the case where aggregate logs have been generated directly by the log-generating entities, "

>     contains is a collection of CDNI Logging Records."

Done.

Cheers

Francois