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

From: [email-masked]
Date: Thu, 13 Feb 2014 05:10:11 -0800

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
        Authors         : Francois Le Faucheur
                          Gilles Bertrand
                          Iuniana Oprescu
                          Roy Peterkofsky
	Filename        : draft-ietf-cdni-logging-09.txt
	Pages           : 45
	Date            : 2014-02-13

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

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-logging-09

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Thu, 13 Feb 2014 13:19:59 +0000

Hi Kevin and all,

We just posted the updated version of cdni-logging that addresses Kevin's review comments as discussed on the list (including latest comment about privacy).

Could you please review and let us know if you have additional comments before we move on to the next step (as agreed in Vancouver) which is to submit the document to Working Group Last Call?

Thanks

Francois & Iuniana

On 13 Feb 2014, at 14:10, <[email-masked]> <[email-masked]> wrote:

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

---

From: Kevin J Ma <[email-masked]>
Date: Tue, 18 Feb 2014 20:00:01 -0500

Hi Francois and Iuniana,

  I went through the updated doc.  It looks good.
  A couple of questions/comments/typos/notes below.
  (Note: It's a much shorter list this time.  ;)

thanx!

--  Kevin J. Ma

section 2.1, first bullet:
     "dCDN, control" -> "dCDN or control"?

     both "customization" and "customisation" are used.
     do we care about consistency wrt "z"s?  (same in fourth bullet)

     should we just remove this reference to CI/MI?
     "We note
      that the CDNI Control interface or the CDNI Metadata interface
      appear as candidate interfaces on which to potentially build such
      a customisation mechanism in the future.  "

     "Before such a" -> "Until such a"

     "UCDN" -> "uCDN"

     I don't follow the use of parentheticals here:
     "to generate (respectively, expect) in dCDN
      (respectively, in uCDN)."
     It wasn't clear to me what this is trying to say, so
     I don't have a proposed alternative.

section 2.1: In thinking about the dCDN log aggregation, it occured to
             me that logs would not be temporally coherent, as logs
             from dCDNs will be off by N x M, where N is the depth of
             the dCDN and M is the non-real-time log retrieval
             interval.  I don't think it's an issue, but I don't
             recall if we ever discussed or mentioned it.

section 2.2.5.6.2:
     "such as the one averaged on a long period" ->
     "such as those averaged over long periods"

     "non-real- time" -> "non-real-time"

section 3.1:
     technically CRLF is two octets; not sure if the BNF cares?
     "NHTAB = <any OCTET excluding HTAB and CRLF>"

section 3.4.1: for cs(<HTTP-header-name>) and sc(<HTTP-header-name>)
      do we want to limit this to zero or one, per <HTTP-header-name> value?
        "occurrence: there MAY be zero, one or any number of instances
         of this field."
      an alternative might be to restrict the definition of the Fields
      directive to disallow duplicate FIENAMEs?

section 4.1.4: "dcdn.example" -> "dcdn.example.com"?

section 4.2: client-side requirements, third bullet, missing semicolon:
      "in the CDNI Logging Feed" -> ""in the CDNI Logging Feed;"

section 4.2: "unability to serve" -> "inability to serve"

section 5.x: Jon had a comment on the FCI semantics draft to remove
             normative language from IANA instructions (which we also
             applied to the MI draft).  We probably want to do the
             same here?

section 5.2: "Field i.e.," -> "Field, i.e.,"

section 5.3: "a semantics that is" -> "semantics that are"

section 6.1: "appropraite" -> "appropriate"

section 6.3: "independently of IP" -> "independent of IP"

> -----Original Message-----
> From: Francois Le Faucheur (flefauch) [mailto:[email-masked]]
> Sent: Thursday, February 13, 2014 8:20 AM
> To: Kevin J Ma
> Cc: Francois Le Faucheur (flefauch); [email-masked]
> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-logging-09.txt
> 
> Hi Kevin and all,
> 
> We just posted the updated version of cdni-logging that addresses Kevin's
> review comments as discussed on the list (including latest comment about
> privacy).
> 
> Could you please review and let us know if you have additional comments
> before we move on to the next step (as agreed in Vancouver) which is to
> submit the document to Working Group Last Call?
> 
> Thanks
> 
> Francois & Iuniana
> 
> 
> > This draft is a work item of the Content Delivery Networks
> Interconnection Working Group of the IETF.
> >

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Thu, 20 Feb 2014 11:48:03 +0000

Hi Kevin

On 19 Feb 2014, at 02:00, Kevin J Ma <[email-masked]> wrote:

> Hi Francois and Iuniana,
> 
>  I went through the updated doc.

Thanks much.

>  It looks good.

Great.

>  (Note: It's a much shorter list this time.  ;)

There are only 2 items that need more discussions:
=====================================

>      directive to disallow duplicate FIENAMEs?

It is not obvious to me that it will never be valid in HTTP to have the same header appear more than once. Or is there a fundamental principle of HTTP that guarantees this won’t (usefully) happen?

>             applied to the MI draft).  We probably want to do the

We’ll need some guidance here. I’ll bring that separately on the list.

==============================================
All other comments have been resolved (see below for details):

>     "dCDN, control" -> "dCDN or control”?

fixed.

>     do we care about consistency wrt "z"s?  (same in fourth bullet)

all instances turned to “z”.

>      a customisation mechanism in the future.  “

This was useful at the time when we were unsure as to whether this woudl be in/out of scope and when we explored the candidate mechanisms. Today, I agree that this sentence does not bring much. Removed.

>     "Before such a" -> "Until such a”

done.

>     "UCDN" -> “uCDN"

fixed

>     I don't have a proposed alternative.

rephrased to:
“
Until such a mechanism is available, the uCDN and dCDN are expected to agree off-line on what exact set of CDNI Logging information is to be provided by the dCDN to the uCDN, and to rely on management plane actions to configure the CDNI Logging functions in the dCDN to generate this information set and in the uCDN to expect this information set.
"

>             me that logs would not be temporally coherent,

agreed.

> as logs
>             interval.

I don’t think the time lag has to be as bad as NxM, but the key point is that log files are not synchronised so they cannot be coherent.

>  I don't think it's an issue, but I don't

I don’t think this raises a special issue. More of an operational consideration. I think there may be quite a set of operational considerations involved in inter-operator logging exchange, but I don't really see them in scope for this document.

>     "such as those averaged over long periods”

fixed

>     "non-real- time" -> "non-real-time”

fixed

>     technically CRLF is two octets; not sure if the BNF cares?

that’s broken

>     "NHTAB = <any OCTET excluding HTAB and CRLF>”

replaced by :
"NHTAB = <any OCTET excluding HTAB, CR and LF>”
this avoids any potential confusion with our CRLF line separator.

>      directive to disallow duplicate FIENAMEs?

It is not obvious to me that it will never be valid in HTTP to have the same header appear more than once. Or is there a fundamental principle of HTTP that guarantees this won’t (usefully) happen?

> 
> section 4.1.4: "dcdn.example" -> "dcdn.example.com”?

“.example” is also a recommended example domain name, and it is also the one used in teh latest version of cdni-framework.

>      "in the CDNI Logging Feed" -> ""in the CDNI Logging Feed;”

fixed

> 
> section 4.2: "unability to serve" -> "inability to serve”
> section 6.1: "appropraite" -> “appropriate"
> 

4 above fixed.

> section 6.3: "independently of IP" -> "independent of IP”

I think the adverb, and not the adjective, is needed here, so I kept “independently” for now.

Thanks !!!

---

From: Rob Murray <[email-masked]>
Date: Thu, 20 Feb 2014 12:05:10 +0000

> It is not obvious to me that it will never be valid in HTTP to have the same header appear more than once. Or is there a fundamental principle of HTTP that guarantees this won’t (usefully) happen?

It can't usefully happen - http header values can be lists separated by commas, in which case the header can appear more than once in the response but semantically there's only one value (and I'd think it should be logged as one value).

Or, if a header appears more than once but it isn't a list, the cache can treat the response as invalid. Or it might decide to pick one of the given values. (Multiple values for one header shouldn't happen, but there's nothing stopping a server from doing it by mistake.)

>From RFC2616, section 4.2 ...

   Multiple message-header fields with the same field-name MAY be
   present in a message if and only if the entire field-value for that
   header field is defined as a comma-separated list [i.e., #(values)].
   It MUST be possible to combine the multiple header fields into one
   "field-name: field-value" pair, without changing the semantics of the
   message, by appending each subsequent field-value to the first, each
   separated by a comma. The order in which header fields with the same
   field-name are received is therefore significant to the
   interpretation of the combined field value, and thus a proxy MUST NOT
   change the order of these field values when a message is forwarded.

Rob.

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Thu, 20 Feb 2014 13:41:31 +0000

Hi Rob, Kevin,

Good info.

So for both cs(<HTTP-header-name>) and sc(<HTTP-header-name>), I modified the text to :
"occurrence: there MAY be zero, one or any number of instances of this field. For a given <HTTP-header-name>, there MUST be zero or exactly one instance of this field.”

Cheers

Francois

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Thu, 20 Feb 2014 13:50:49 +0000

Hi Jon,

In his review comments on cdni-logging, Kevin said:

>             applied to the MI draft).  We probably want to do the

Was the reason for which you recommended that the FCI semantics I-D removes normative language from IANA instructions the fact that FCI semantics is going for Informational Track?
If yes, then that would not apply to cdni-logging.
If no, can you describe the reason and whether/how you see that impacting (or not) cdni-logging, given the current IANA section wording?

Thanks

Francois

---

From: yiqiuchao <[email-masked]>
Date: Fri, 21 Feb 2014 11:38:13 +0800

Hi Francois, 
I have read the draft and leant a lot, thanks. 
And I have some comments as below which are highlighted in red：
1. Page 7:
   6.   Assuming that dCDNn is selected as a serving dCDN provider, the
        end-user does a DNS lookup using dCDNn’s distinguished
        CDN-domain (peer-dCDNn-1.dCDNn.net).  dCDNn-1’s (dCDNn's)DNS resolver
        returns the IP address of a request router for dCDNn.
   7.   The request router for dCDN1(dCDNn) processes the HTTP request and
        selects a suitable delivery node to serve the end-user request,
        and returns a 302 redirect message for a new URL constructed by
        replacing the hostname by a subdomain of the dCDNn’s
        distinguished CDN-domain that points to the selected delivery
        node.
   and the figure 1 in Page 6 should be modified as well.

2. Page 10, typos:

3. I think the CNAMEed domain name should be added to the end of the original one, so the dCDN1.cdn.csp.com showed in the above figure should be cdn.csp.com.dCDN1.net.

yiqiuchao from China Mobile

From: Francois Le Faucheur (flefauch)
Date: 2014-02-13 21:19
To: Kevin J Ma
CC: [email-masked]
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-logging-09.txt
Hi Kevin and all,

Thanks

Francois & Iuniana

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Fri, 21 Feb 2014 08:44:17 +0000

Hello,

I think these comments actually related to cdni-framework (and not cdni-logging), so handing over to the corresponding editors.

Cheers

Francois

On 21 Feb 2014, at 04:38, yiqiuchao <[email-masked]<mailto:[email-masked]>> wrote:

Hi Francois,
        CDN-domain (peer-dCDNn-1.dCDNn.net<http://peer-dCDNn-1.dCDNn.net>).  dCDNn-1’s (dCDNn's)DNS resolver

2. Page 10, typos:

3. I think the CNAMEed domain name should be added to the end of the original one, so the dCDN1.cdn.csp.com<http://dCDN1.cdn.csp.com> showed in the above figure should be cdn.csp.com.dCDN1.net.
________________________________
yiqiuchao from China Mobile

From: Francois Le Faucheur (flefauch)<mailto:[email-masked]>
Date: 2014-02-13 21:19
To: Kevin J Ma<mailto:[email-masked]>
CC: [email-masked]<mailto:[email-masked]>
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-logging-09.txt
Hi Kevin and all,

Thanks

Francois & Iuniana

On 13 Feb 2014, at 14:10, <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>> wrote:

> until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.
>
> [email-masked]<mailto:[email-masked]>

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