Subject: [CDNi] Alexey Melnikov's Discuss on draft-ietf-cdni-logging-25: (with DISCUSS and COMMENT)

From: "Alexey Melnikov" <[email-masked]>
Date: Wed, 18 May 2016 06:40:30 -0700

Alexey Melnikov has entered the following ballot position for
draft-ietf-cdni-logging-25: 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 know this document has long history and I want to get it done as well.
Below is a list of small issues that I think need to be addressed:

Is version directive value case-insensitive? The IANA registration is in
lowercase, but all examples show uppercase.

On page 28: SHA-3, AES-GCM and base64 all need normative references.

(Use "Section 4 of [RFC4648]" for base64, as RFC 4648 defines 2 base54
encodings).

On page 33: where does the "missing field value is denoted by -"
specified in ABNF? If this is not defined in ABNF, it would be good to
have an example record with a field missing.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

In 7.1, last sentence: TLS only provides for protection from tampering
when in transit, not when a log file being stored.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 20 May 2016 15:20:47 -0500

Dear Authors,

> https://datatracker.ietf.org/doc/draft-ietf-cdni-logging/

I haven't seen a response to Alexey's ballot yet - did I miss it?

The Discuss seems pretty straightforward. Please let me know if you need
help absorbing it.

Thanks,

Spencer

---

From: Francois Le Faucheur <[email-masked]>
Date: Wed, 25 May 2016 19:53:56 +0200

Hello Alexey and all,

Thanks much for the review. Please see below for resolution of all the comments.

Yes, the version directive value is case-insensitive (like the directive names, the record-types  and the field names).

There is already a statement about that at the beginning of "section 6: IANA Considerations"
"
When IANA allocates new extensions to CDNI Logging Directive Names
   Registry, CDNI Logging File version Registry, CDNI Logging record-
   type Registry or CDNI Logging fields Registry, IANA MUST take into
   account that the directive names are case-insensitive as per the
   basic ABNF([RFC5234]).
“

To make it easier to for the reader, I have added a statement about case-insensitive under section "6.2.  CDNI Logging File version Registry” (and section 6.3 and section 6.4 for that matter) like there was already under 6.1.

> On page 28: SHA-3, AES-GCM and base64 all need normative references.

I added 

[SHA-3]    NIST, "SHA-3 STANDARD: PERMUTATION-BASED HASH AND
              EXTENDABLE OUTPUT FUNCTIONS", August 2015,
              <http://dx.doi.org/10.6028/NIST.FIPS.202>.

I tweaked the text to say:
"and the encryption algorithm SHOULD be 128-bit AES [AES] in Galois Counter Mode (GCM) [GCM] (AES-GCM) or better.”

with : 
"
   [AES]      NIST, "Advanced Encryption Standard (AES)", August 2015,
              <FIPS 197>.

   [GCM]      NIST, "Recommendation for Block Cipher Modes of Operation:
              Galois/Counter Mode (GCM) and GMAC", November 2007, <SP
              800-38D>.
"

I tweaked the text to say:
"The encrypted value SHOULD be hex encoded or base64 encoded (as specified in section 4 of [RFC4648]).”

with:
“
   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
              Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
              <http://www.rfc-editor.org/info/rfc4648>.
"

Please let me know if they are better references to use.

> (Use "Section 4 of [RFC4648]" for base64, as RFC 4648 defines 2 base54

Thanks for the tip !

> have an example record with a field missing.

I assume you are referencing to the following sentence:
"if the value for the field is not available, this MUST be conveyed via a dash character ("-“).”
Right?

It is not explicitly discussed in the ABNF description (although for all the fields of format NHTABSTRING it is allowed by the ABNF description).
But I like your suggestion and added an example at the bottom of section "3.6.  CDNI Logging File Examples”:

"
 Say, that for some reason (for example a Surrogate bug), dCDN-1 could
   not collect the total number of bytes of the responses sent by
   the Surrogate (in other words, the value for sc-total-bytes is not
   available).  Then the corresponding CDNI Logging records would
   contain a dash character ("-") in lieu of the value for the sc-total-
   bytes field (as specified in Section 3.4.1).  In that case, the CDNI
   Logging File that would be communicated by dCDN-1 to uCDN is shown
   below in Figure 5.

   #version:<HTAB>cdni/1.0<CRLF>

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

   #claimed-origin:<HTAB>cdni-logging-entity.dcdn-1.example.com<CRLF>

   #record-type:<HTAB>cdni_http_request_v1<CRLF>

   #fields:<HTAB>date<HTAB>time<HTAB>time-taken<HTAB>c-groupid<HTAB>
   cs-method<HTAB>u-uri<HTAB>protocol<HTAB>
   sc-status<HTAB>sc-total-bytes<HTAB>cs(User-Agent)<HTAB>
   cs(Referer)<HTAB>s-cached<CRLF>

   2013-05-17<HTAB>00:38:06.825<HTAB>9.058<HTAB>US/TN/MEM/38138<HTAB>
   GET<HTAB>
   http://cdni-ucdn.dcdn-1.example.com/video/movie100.mp4<HTAB>
   HTTP/1.1<HTAB>200<HTAB>-<HTAB>"Mozilla/5.0
   (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like
   Gecko) Chrome/5.0.375.127 Safari/533.4"<HTAB>
   "host1.example.com"<HTAB>1<CRLF>

   2013-05-17<HTAB>00:39:09.145<HTAB>15.32<HTAB>FR/PACA/NCE/06100<HTAB>
   GET<HTAB>
   http://cdni-ucdn.dcdn-1.example.com/video/movie118.mp4<HTAB>
   HTTP/1.1<HTAB>200<HTAB>-<HTAB>"Mozilla/5.0
   (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like
   Gecko) Chrome/5.0.375.127 Safari/533.4"<HTAB>
   "host1.example.com"<HTAB>1<CRLF>

   2013-05-17<HTAB>00:42:53.437<HTAB>52.879<HTAB>US/TN/MEM/38138<HTAB>
   GET<HTAB>
   http://cdni-ucdn.dcdn-1.example.com/video/picture11.mp4<HTAB>
   HTTP/1.0<HTAB>200<HTAB>-<HTAB>"Mozilla/5.0
   (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like
   Gecko) Chrome/5.0.375.127 Safari/533.4"<HTAB>
   "host5.example.com"<HTAB>0<CRLF>

   #SHA256-hash:<HTAB> 64-hexadecimal-digit hash value <CRLF>

      Figure 5: CDNI Logging File Example With A Missing Field Value

Agreed. I changed the sentence to say:
“
Protection against third party tampering when the CDNI Logging File is communicated over the CDN Logging Interface can be achieved as discussed above through the use of TLS.
“

Thanks

Francois

---

From: Francois Le Faucheur <[email-masked]>
Date: Wed, 25 May 2016 22:47:17 +0200

Alexey and all,

I just posted -26 that includes all the resolutions of your comments as discussed below.
Let us know if anything else is required from your end.

I will work on Ben’s comments soon.

Cheers

Francois

htmlized version available at:
https://tools.ietf.org/html/draft-ietf-cdni-logging-26 <https://tools.ietf.org/html/draft-ietf-cdni-logging-26>

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-logging-26 <https://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-logging-26>

> On 25 May 2016, at 19:53, Francois Le Faucheur <[email-masked]> wrote:
> 
> Hello Alexey and all,
> 
>