Re: [Gen-art] genART review of draft-ietf-cdni-logging-15

[Martin Thomson <[e-mail]>]

On 5 March 2015 at 07:21, Francois Le Faucheur (flefauch)
<[e-mail]> wrote:
...
> I have added this at the end of S3.3:
>
> NEW:
> “
> An uCDN-side implementation of the CDNI Logging interface MUST reject a CDNI
> Logging File that does not comply with the occurences specified above for
> each and every directive. For example, an uCDN-side implementation of the
> CDNI Logging interface receiving a CDNI Logging file with zero occurence of
> the Version directive, or with two occurences of the Integrity-hash, SHOULD
> reject this CDNI Logging File.
> "

That SHOULD needs to be qualified somehow.  Why would an
implementation ignore the SHOULD and not reject the file?


> And also edited the end of S3.4 as per the following:
>
> OLD:
> "
>  An uCDN-side implementation of the CDNI Logging interface MUST be
>    able to accept CDNI Logging Files with CDNI Logging Records of
>    Record-Type "cdni_http_request_v1" containing any CDNI Logging Field
>    defined in Section 3.4.1 as long as the CDNI Logging Record and the
>    CDNI Logging File are compliant with the present document.
> “
> NEW:
> “
>  An uCDN-side implementation of the CDNI Logging interface MUST be
>    able to accept CDNI Logging Files with CDNI Logging Records of
>    Record-Type "cdni_http_request_v1" containing any CDNI Logging Field
>    defined in Section 3.4.1 as long as the CDNI Logging Record and the
>    CDNI Logging File are compliant with the present document.
>
> In case, an uCDN-side implementation of the CDNI Logging interface receives
> a CDNI Logging File with HTTP Request Logging Records that do not contain
> field values for exactly the set of field names actually listed in the
> preceding “Fields” directive, the implementation SHOULD reject those HTTP
> Request Logging Records, and SHOULD accept the other HTTP Request Logging
> Records .
> "

Again, SHOULD is weak without some support.

> NEW:
> “
> The entity transmitting a CDNI Logging File as per the present document MUST
> set the value to "CDNI/1.0”. In the future, other versions of CDNI Logging
> File might be specified; those would use a value different to "CDNI/1.0”
> allowing the entity receiving the CDNI Logging File to identify the
> corresponding version.
> "

This doesn't tell a receiver what to do with "CDNI/1.1".  It needs to do that.

> NEW:
> "
>  The general TLS usage guidance in [I-D.ietf-uta-tls-bcp] SHOULD be
>    followed.
> “

In this case, a SHOULD is OK, I suppose.

> S 3.4.1
>   o  cs(<HTTP-header-name>):
> HTTP header fields, esp. in HTTP/2 can contain HTAB, even if that
> isn't permitted by the grammar.  You probably want to describe how
> that is handled.
>
>
> Since the value of the HTTP header is encoded as a “quoted string”
> (QSTRING), is it not OK to have a HTAB within the HTTP header value as long
> as it is properly bracketed by the Quotes?

Header field *names* aren't quoted.

My point was that even though this is a bug in the sender, you are
going to see these in the wild and they are going to screw up the
logging file.

> The document says that "client-side implementation of the CDNI Logging
> interface MAY pull, at its convenience, a CDNI Logging File “ using standard
> HTTP. Since range request is just a standard HTTP mechanism, the clien-side
> may use it if it sees fit.
> Do you feel it is worth specifically calling out that range requests can be
> used?
> No problem in doing that if you feel it is useful.

Nah, that's OK.