Content Distribution Network Interconnection (CDNI) Logging Interface
RFC 7937

Note: This ballot was opened for revision 15 and is now closed.

(Richard Barnes) Discuss

Discuss (2015-03-04 for -15)
I'm concerned that the information model of this log format encourages the sharing of far more granular information than is justified by the use cases.  All of the use cases in Section 2 are focused on statistical information, in which case collecting things like individual IP addresses and ports is unnecessary.

(Pete Resnick) Discuss

Discuss (2015-03-04 for -15)
I am very concerned about the syntax specification here. I'm not convinced it's complete and correct. I am certainly willing to be talked out of my concern, but I think this could use a massive edit by someone who knows ABNF, as well as a discussion about intended contents. Details:

3.1: I always prefer to import the rules you are using simply by reference rather than of copying them. Prevents silly errors.

On these, let's see if you really mean what you say you mean:

      NAMEFORMAT = ALPHANUM *(ALPHANUM / "_" / "-")
      
So, are you really OK with a NAMEFORMAT of "1---___---"? Often what people really want is:

      NAMEFORMAT = ALPHANUM *(["_" / "-"] ALPHANUM)
      
Is that what you want?

On the next bit:

      QSTRING = DQUOTE *NDQUOTE DQUOTE ; where

         NDQUOTE = <any OCTET excluding DQUOTE> / 2DQUOTE ; whereby a
         DQUOTE is conveyed inside a QSTRING unambiguously by repeating
         it.

      NHTABSTRING = *NHTAB ; where

         NHTAB = <any OCTET excluding HTAB, CR and LF>

(By way of formatting, outdent NDQUOTE and NHTAB, and get rid of "; where".)

When you say <any OCTET excluding ...>, is that what you really mean? You want to allow control characters? Seems to me that that is going to introduce a whole new set of security considerations. Also, the fact that you call these things xSTRING sends up a flag for me that you maybe want them to be textual. Are you allowing for things outside of US-ASCII? Section 3.2 seems to say only US-ASCII. Finally, do you really want NDQUOTE to allow for CR, LF, and HTAB? That means that parsers have to be a bit smarter, and the line in 3.2 that says, "Each line ... MUST contain either a directive of a CDNI Logging Record", and the line in 3.4 that says, "CDNI Logging Fields MUST be separated by the HTAB character", both seem bogus. So, assuming you want only US-ASCII and that you don't want CR LF or HTAB in any of these, these should be:

      QSTRING = DQUOTE *NDQUOTE DQUOTE

      NDQUOTE = SP / %x21 / %x23-7E / (DQUOTE DQUOTE)
       ; DQUOTE is conveyed inside a QSTRING unambiguously by repeating
       ; it.

      NHTABSTRING = *NHTAB

      NHTAB = SP / VCHAR

or if you like, simply:

      NHTABSTRING = *( SP / VCHAR )

If you want non-US-ASCII, I'd include UTF-8 and call that out. I can tell you how to do that, but I hope you're not doing that.

If you want CR and LF in both QSTRING and NHTABSTRING, and HTAB in QSTRING, you need to fix the lines in 3.2 and 3.4. If don't want them, you're going to have to describe how to unfold and de-tab the HTTP header field values somewhere.

3.2:

      RECLINE = <CDNI Logging Record> CRLF

      RECGROUP = *RECLINE

      <CDNI Logging File> = 1*<DIRGROUP RECGROUP>
    
These seem kind of a cop-out. Seems like you could easily define RECLINE as:

       RECLINE    = date HTAB time HTAB time-taken HTAB ...
       date       = DATE
       time       = TIME
       time-taken = DEC
       [...]

The last line is nowhere near legitimate ABNF. How about just defining a proper LOGFILE as:

       LOGFILE    = 1*(DIRGROUP RECGROUP)
    
If you're going to bother with ABNF, use ABNF. The explanations can still appear in 3.3 and 3.4.1.

3.3: The top-level ABNF for DIRNAME and DIRVAL give the implementer no help with regard to what is legitimate syntax. You mention the syntax for DIRNAME in 6.1, but that's not where it belongs. At least you should put in:

       DIRNAME = NAMEFORMAT

For DIRVAL, you should probably have at least the most general format of:

       DIRVAL = NHTABSTRING / QSTRING

and then give specifics below. But you could also change 3.2 and say something like:

        DIRGROUP = version
                   uuid
                   [claimed-orig]
                   [established-orig]
                   1*record-type
                   1*fields
                   [integrity-hash]
                   *new-dir

Then in 3.3, you could define:

        version   = "Version:" HTAB "CDNI" "/" 1*DIGIT "." 1*DIGIT
        uuid      = "UUID:" HTAB NHTABSTRING
        ...
        new-dir   = <Newly registered directives>

and indicate that unknown directives must be ignored, or something like that.

This is wrong:

   o  Fields:

      *  format: FIENAME *<HTAB FIENAME>

Angle brackets don't appear like that in ABNF.

3.4: Again, incorrect ABNF, if that's what it's meant to be.

(Spencer Dawkins) Yes

Barry Leiba (was Discuss, No Objection) Yes

Comment (2016-03-18 for -23)
No email
send info
The ABNF issues have all been fixed; thanks for all the work on this.

(Jari Arkko) (was Discuss) No Objection

Comment (2015-03-05 for -15)
No email
send info
Thanks for working on this very useful specification. I think it is soon ready to move forward, but there are a couple of things that we should try to address before the final approval. Martin raised a number of comments in the Gen-ART review, and I'd like to see the resolution of those. For me, I think the following issues at least deserve a document change:

I'm not sure the definition of <CDNI Logging File> is correct. I would simply do

   CDNI-LOG-FILE = 1*(DIRGROUP / RECGROUP)

For the reasons that Martin outlined. Also, Section 3.4.1 needs an update, given that HTTP 2 specifications have been approved. I suspect you could simply say that the work applies to both HTTP 1 and 2, and that any new information derived from HTTP 2 specifically is outside the scope of this spec.

Security considerations should rather refer to existing mandates in TLS specifications (such as the UTA document that was recently approved) rather than make their own specific crypto requirements.

(Alia Atlas) No Objection

Deborah Brungard No Objection

(Ben Campbell) (was Discuss) No Objection

Comment (2016-06-08)
No email
send info
Thanks for addressing my DISCUSS and COMMENT points.

Alissa Cooper (was Abstain, Discuss) No Objection

Comment (2016-04-04 for -24)
No email
send info
Thanks for resolving my DISCUSS points.

I will note that I don't think the issue with partial-time has been completely resolved, because the document still says it uses partial-time as defined in RFC 3339, and partial-time by definition does not have a time zone associated with it, whereas the document text now says all times are reported in UTC. Bit of a detail, but it might make sense to use full-time since you are specifying the time zone offset. There are probably other folks who know better than I do what standard practice is here.

(Adrian Farrel) No Objection

Comment (2015-03-03 for -15)
No email
send info
I have No Objection to the publication of this document.


I don't think the use of "MAY" in section 5 adds anything over "may"

(Stephen Farrell) (was Discuss) No Objection

Comment (2016-03-02 for -22)
No email
send info
Thanks for the additional text in -22, which clears
up the last of my discuss points.

old comments below, I didn't check 'em

- in the description of c-groupid, "the address 
with a shared secret that is pre-synchronised
and rotated at a predefined time interval" isn't
very clear. I know what you mean but I don't 
think you state it very clearly. Could be that a
bit of text earlier in the document that describes
the basic idea would be better than doing it all
inline as you have in -21.

OLD COMMENTS Below, not updated for -21, I didn't
check if you took 'em on board, feel free to chat about
'em if that's useful  - I'm happy to do so anyway.

- I support Richard's discuss. Isn't it ironic that the dCDN's
privacy (that of a company) is better supported than that of
the end user (a person) 

- 2.2.1 - why is per-chunk always needed? 

- 2.2.5.3: what's "track audience" mean?

- 2.2.5.4: there are more security goals in the universe

- 2.2.5.4: seems like the user is the enemy, that's odd

- 2.2.5.6.2: there is no "browser type header" that I know of,
but there is the well-known UA string. Being specific about
that is better.

- 3.1: SS.S - does that imply a time granularity of 100ms?  If
so, please say so.

- 3.4.4: cs-uri: please not that these can be privacy
sensitive, though presumably less so than e.g.  logged URIs on
a search engine.

- 3.4.4: foo-uri: do these contain fragments or not?

(Brian Haberman) No Objection

(Joel Jaeggli) No Objection

Suresh Krishnan No Objection

Mirja K├╝hlewind No Objection

Comment (2016-05-17 for -25)
No email
send info
I still agree to the privacy concerns that have been raised earlier by Richard Barnes but don't see a solution that would justify a "DISCUSS" to hold up the document.

Further I think it's important that TLS is mandatory and it could be useful to already state this earlier in the doc and not only Section 7.

(Ted Lemon) No Objection

Comment (2015-03-05 for -15)
No email
send info
I support Stephen's DISCUSS, but don't otherwise object.

(Terry Manderson) No Objection

Alexey Melnikov (was Discuss) No Objection

Comment (2016-06-08)
No email
send info
Thank you for addressing my DISCUSS points.

(Kathleen Moriarty) (was Discuss) No Objection

Comment (2015-04-20 for -18)
No email
send info
Thanks for your work on this draft.  I've cleared my prior discusses. Although for the first one I would have preferred my suggested text over what you wound up with from the SecDir review after I had provided the suggestions just because I think it covers the points a bit more cleanly.

Alvaro Retana No Objection

(Martin Stiemerling) No Objection