Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-logging-05.txt

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Fri, 27 Sep 2013 12:42:44 +0000

Hi Kevin,

Your comments below have been addressed in -06 that was just posted today in teh folowing way:

On 29 Jul 2013, at 11:18, Kevin J Ma <[email-masked]> wrote:

> Hi all,
> 
>  some comments on the logging draft:
> 
> section 2.1: "benefit form" -> "benefit from"

Done.

> 
> section 2.2.: "is obviously only indicative" -> "is obviously only an example"

Done.

> section 2.2.5.1: wrt CDNI, are we saying that logging should enable
>                 the uCDN to debug the performance issues in the dCDN?

No. The text has been tweaked to avoid suggesting that.

> 
> section 3.3: in general, should occurance be more precise?

Yes.

>  e.g.:
>    UUID: "there MUST be one and only one instance of this directive."
>          should specify "per CDNI Logging File"

Done. And similar change done for the other directives.

>    Fields: "The first instance of this directive for a given
>             Record-Type MUST precede any CDNI Logging Record for this
>             Record-Type."
>            should specify before the next Fields directive.
>            i.e., it is not required to group all the records for a
>            given Fields directive into a single block in the log file?

I agree with the point you make.
The text for "directive value" and "Occurrence" has been tweaked to reflect that. eg:
"
directive value: this lists the names of all the fields for
         which a value is to appear in the CDNI Logging Records that
         follow the instance of this directive (until another instance
         of this directive). 
"

> section 3.3: for Verified-Origin, when would this be propogated?
>             Is the use case a transit CDN forwarding a log verbatim
>             from dCDN to uCDN?

The use-case is really for the uCDN receiving the CDNI Logging File to store the fact that it has verified the Origin itself at the time it received and stored the file. For example, the uCDN may use HTTP/HTTPS mechanisms to authenticate the dCDN providing teh CDNI Logging File, then it can record teh authenticated dCDN in the "Verified-Origin".
IMHO this is not intended to be propagated, because it is not a universal authentication. It is just an authentication by the uCDN based on its own authentication method.

> 
> section 3.3: for Integrity-Hash, it states that the hash is computed
>             "by the entity that transmits the CDNI Logging File."
>             though it is possible that the entity that generated the
>             log file is not the same entity that (re)transmits it.
>             does the integrity hash need to be recalculated?

Right.
The text has been changed to say:
"The valid Integrity-Hash value is included in this directive by the entity that transmits the CDNI Logging File".
This allows all scenario: ie the trsnmitting entity computes it itself, or it trusts some other entity that has already computed it.

> 
> section 3.3: the protocol, sc-status, and sc-total-bytes fields are
>             all mandatory, and HTTP-specific.  In the case of
>             non-HTTP delivery, are these fields just left blank?
>             Or do we only support HTTP delivery (not that theres
>             anything wrong with that)?

I believe we discussed this and agreed this record-type is exclusively for HTTP delivery. Hence the record-type name of "cdni_http_request_v1".

> 
>             sc-entity-bytes, cs(header), and sc(header) are also
>             HTTP-specific, but not required,
> 
> section 3.3: the s-cached flag is for:
>             "whether the Surrogate could serve the request using
>              content already stored on its local cache" 
>             Should it be fore whether the Surrogate "did serve the
>             request from content already stored in its local cache"?

Agreed. Fixed.

> in section 3: "agreements) ." -> "agreements)."

Done.
> thanx.

Thank you for these thoughtful comments.

Francois

> 
> --  Kevin J. Ma
> 
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf Of
>> [email-masked]
>> Sent: Friday, July 12, 2013 7:47 AM
>> To: [email-masked]
>> Cc: [email-masked]
>> Subject: [CDNi] I-D Action: draft-ietf-cdni-logging-05.txt
>> 
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> This draft is a work item of the Content Delivery Networks
>> Interconnection Working Group of the IETF.
>> 
>> 	Title           : CDNI Logging Interface
>> 	Author(s)       : Francois Le Faucheur
>>                          Gilles Bertrand
>>                          Iuniana Oprescu
>>                          Roy Peterkofsky
>> 	Filename        : draft-ietf-cdni-logging-05.txt
>> 	Pages           : 44
>> 	Date            : 2013-07-12
>> 
>> Abstract:
>>   This memo specifies the Logging interface between a downstream CDN
>>   (dCDN) and an upstream CDN (uCDN) that are interconnected as per the
>>   CDN Interconnection (CDNI) framework.  First, it describes a
>>   reference model for CDNI logging.  Then, it specifies the CDNI
>>   Logging File format and the actual protocol for exchange of CDNI
>>   Logging Files.
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-cdni-logging
>> 
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-ietf-cdni-logging-05
>> 
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-logging-05
>> 
>> 
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>> 
>> _______________________________________________
>> CDNi mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/cdni
> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni