Subject: [CDNi] CDNI Framework WG Chair Review - Part 1

From: Daryl Malas <[email-masked]>
Date: Tue, 8 Oct 2013 19:41:34 +0000

All,

This is a fairly large draft, and I've been struggling to get time to review it in detail.  With this in mind, I'm going to break up my review in a couple of parts, so the authors and others can respond, argue or comment on my comments.

--Daryl

------Part 1--------
Abstract (minor change):

"CDN Interconnection requires the specification of several
interfaces and mechanisms to address issues such as request routing,
distribution metadata exchange, and logging information exchange
across CDNs."

Suggest we remove "several," since do not know exactly how many interfaces end up being defined.

Section 1 – Introduction:
Change [I-D.ietf-cdni-use-cases] to reference RFC 6770.  Change throughout as necessary.

Abstract and Introduction have a lot of redundancy.

"CDN Interconnection requires the specification of several
interfaces and mechanisms to address issues such as request routing,
distribution metadata exchange, and logging information exchange
across CDNs. The intent of this document is to outline what each
interface needs to accomplish, and to describe how these interfaces
and mechanisms fit together, while leaving their detailed
specification to other documents."

"CDN Interconnection requires the
specification of several interfaces and mechanisms to address issues
such as request routing, metadata exchange, and the acquisition of
content by one CDN from another. The intent of this document is to
describe how these interfaces and mechanisms fit together, leaving
their detailed specification to other documents."

Can you tell which one is the abstract and which is the introduction?  I suggest we either remove the duplication or change the wording to better describe our intent with the draft.

"The purpose of this
document is to provide an overview of the various components
necessary to interconnect CDNs."

I think it would be more accurate to say, "The purpose of this
document is to describe the functions of the interfaces and related components
necessary to interconnect CDNs.

Section 1.1:

Change, "This document draws freely on the core terminology defined in RFC
6707." to "This document uses the core terminology defined in RFC 6707."

(minor) "It also introduce the following terms:" to "It also introduces the following terms:"

Recursive CDI Request Redirection -
"Note that the Downstream CDN may elect to have the request redirected
directly to a Surrogate inside the Downstream CDN, to the Request
Routing System of the Downstream CDN, to another CDN, or to any other
system that the Downstream CDN sees as fit for handling the
redirected request."

I  have concerns with the last part of this, "the Downstream CDN sees as fit for handling the
redirected request."  This implies the Upstream CDN (or, specifically, the CDN domain) has no say in how the request is ultimately delivered to the subscriber.  I think we are implying a business implication here.  I suggest we change this to, "…or as necessary in order to handle the redirected request appropriately."

(minor) Suggest we capitalize the first letter of "Synchronous, Asynchronous and Trigger" for consistency.

Section 1.2:

In Figure 1, create consistency in the lines considered outside the scope of CDNI.  Having both **** and ….creates confusion.  We ran into this during the AD review of the "requirements" draft.  I suggest you talk with Kent Leung to ensure consistency across the two.

In the 2nd paragraph after "Figure 1: CDNI Expanded…" the term uCDN starts being used without being defined previously as a shortened form of upstream CDN.  Afterwards, the text returns to spelling it out.  I suggest we define this early on and try to create some level of consistency of use throughout the document.  The first time I see these defined is in Section 3.

CDNI Metadata interface (MI) - change "May include a combination of:" to "It may include a combination of:"

Page 7 – We have a reference to a new "caller" and "callee".  Whom do these reference?  I can surmise from the text, but they should be defined for clarity to readers who have never participated in the CDNI WG.  From what I can tell these are never used again in the document.  Can we leverage existing terms that are more consistent through the document?

Page 7 – Update reference to "I-D.brandenburg-cdni-has" to "RFC 6983".

Section 2.1.1 – What is the purpose of stating, "...although the user is
free to choose other DNS servers (e.g., OpenDNS, Google Public DNS)."

I suggest we remove that.  I don't think it adds any value to the explanation.

Also, there is some editorial error in the 2nd paragraph, "…to the end user-\u002Dthe user…"

Page 9, 2nd paragraph, "(1) there is a limit to the number alternate…" to "(1) there is a limit to the number of alternate…"

Last paragraph of this section, there is another editorial error "…to the client-\u002Dthe LDNS server…"

Page 12 – The example on step 7 seems redundant with step 4.  I understand the step, but I think the example seems redundant.  I suggest changing the example.

Page 15 – Editorial issues in Step 2.

Page 15 – Does it provide better clarity in step 4 to change "replacing the hostname by a subdomain" to "replacing the hostname with a subdomain"?

>end –Part 1

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Wed, 16 Oct 2013 10:43:49 +0000

Daryl, Larry and all,

Thoughts embedded below about two comments.
I personally agree with all other comments/suggestions from Daryl.

I think it is useful to convey the idea that the user may be using a "DNS" that is fairly local (ie whose location provides some hint about where the enduser itself is located) or a non-local DNS (ie whose location is completly un-correlated with the enduser location). This helps understanding the subsequent paragraph bringing up the inaccucary drawback of the DNS method.

However, the text in the subsequent paragraph is currently inconsistent because it only mentions the case of the LDNS:
"On the other hand, DNS redirection is
   problematic because the DNS request comes from the LDNS server, not
   the end-user.
"
This may have to do with an ambiguous use of the term "LDNS".

My suggestion is that the edited text:
* indicates that the user can use different DNS servers
* with some DNS servers (eg DNS server run by network operator), the location of the DNS server may provide some indication of the enduser location. With some DNS servers (eg global DNS server), it does not.
* DNS redirection only sees the IP address of teh DNS server and not enduser and therefore has limited or no information on enduser location which affects redirection accuracy.

I don't see why step 4 and 7 are redundant. Step 4 is using Redirection Interface while Step 7 is over Metadata Interface.

Francois

---

From: Daryl Malas <[email-masked]>
Date: Wed, 16 Oct 2013 15:48:04 +0000

In line...

From: "Francois Le Faucheur (flefauch)" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, October 16, 2013 4:43 AM
To: Daryl Malas <[email-masked]<mailto:[email-masked]>>
Cc: "Francois Le Faucheur (flefauch)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [CDNi] CDNI Framework WG Chair Review - Part 1

Daryl, Larry and all,

[DM] OK.

[DM] The example use of the interfaces is what I'm contending is redundant.  There are other uses of the Metadata Interface, so I suggest expanding the example rather than repeating the purpose with a different interface.  Yes, it works.  I'm just suggesting we avoid redundancy across interfaces in order to make the example more "interesting."

Francois