Subject: [CDNi] Coments on draft-ietf-cdni-redirection-01.txt

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Wed, 6 Nov 2013 04:02:38 +0000

Ben and all,

Some comments:
=============

***
OLD:
"
If the RI is used between the uCDN
   and one or more dCDNs.  The dCDN's RI response may contain a
   Redirection Target ... 
"
NEW:
"
If the RI is used between the uCDN
   and one or more dCDNs, the dCDNs' RI response will typically contain a
   Redirection Target ... 
"

***
OLD:
"
where the attributes of a User
   Agent's requests are encapsulated along with any other data that can
   aid the downstream CDN in processing the requests.  The RI response
   encapsulates the attributes
"
NEW:
"
where the attributes of a User
   Agent's requests are conveyed along with any other data that can
   aid the downstream CDN in processing the requests.  The RI response
   conveys the attributes
"
[as discussed before, "encapsulates" incorrectly suggests they are conveyed by embedding their native format]

***
OLD:
"
To assist the routing decision of a Downstream CDN, the Upstream CDN
   shall convey as much information as possible to the Downstream CDN,
   for example the URI of the requested content and the User Agent's
   location information, when those are known by the uCDN Request
   Routing system.
"
NEW:
"
To assist the routing decision of a Downstream CDN, the Upstream CDN
   conveys the necessary information to the Downstream CDN,
   for example the URI of the requested content and the User Agent's
   location information, when those are known by the uCDN Request
   Routing system. Based on its policy, the Upstream CDN can decide to also convey additional information about the request (e.g. HTTP request headers) to allow the Downstream CDN to make a more informed decision.

"

*** section 4.2, table illustrating "Top-Level keys in RI requests/responses"
The table (or the text that follow it) needs to indicate more exhaustively which key is Mandatory or not (separately for request and for response).

*** section 4.2, table illustrating "Top-Level keys in RI requests/responses"
"Transit CDNs should check the cdn-path and not cascade the RI request to downstream CDNs that are already listed in cdn-path."  This wording is redundant with some text further in teh document also discussing use of cdn-path and it is not worded properly with RFC2119 keywords. I suggest removing it from the table.

***
OLD:
"
The dns dictionary of a RI request for DNS based redirection MUST
   contain the following keys: resolver-ip, qtype, qclass, qname and the
   value of each MUST be the value of the appropriate part of the User
   Agent's DNS query/request.
"
NEW:
"
The dns dictionary of a RI request for DNS based redirection MUST
   contain all the keys identified as Mandatory in the table above, and the
   value of each MUST be the value of the appropriate part of the User
   Agent's DNS query/request.
"
[In general, I think the doc needs a good clean-up to provide more exchaustive description of what is mandatory and what is not and better use of RFC2119 terminology]

*** section 4.4.2
"
   For DNS based redirection the dCDN needs to return one of the
   following to the uCDN in the RI response:
   o  The IP address of (or a CNAME to) the RT (if the dCDN is
      performing DNS based redirection); or
   o  The IP address of (or a CNAME to) a RT which is a Request Router
      (if the dCDN is performing HTTP based redirection).
"
It is a little confusing to read that "for DNS-based redirection, the dCDN needs to return … (if the dCDN is performing HTTP based redirection)". So you need to distinguish more explicitely between the redirection method used between the USer Agent & uCDN  versus the redirection method used by the dCDN. This probably affects also 4.4.1  (and 4.5) since its title refers to the redirection method used between the User Agent & uCDN.

*** section 4.4.2
OLD:
"
Response must contain at least one of a, aaaa, cname.
"
NEW:
"
RI Response for DNS based redirection MUST contain all the keys identified as Mandatory in the table above, as well as at least one of a, aaaa, cname.
"

*** section 4.4.2
why is the name in the response called "name" while it is called "name" in the query? Should it not be also called "qname" (if it is always is equal to the qname of the query) or "rename" (if it can be different in some situations)?

***
OLD:
"
The http dictionary of a RI request for HTTP based redirection MUST
   contain the following keys: c-ip, cs-method, cs-version and cs-uri
   and the value of each MUST be the value of the appropriate part of
   the User Agent's DNS query/request.
"
NEW:
"
The http dictionary of a RI request for HTTP based redirection MUST
   contain all the keys identifed as Mandatory in the previous table and the value of each MUST be the value of the appropriate part of  the User Agent's HTTP request.
"

*** section 4.6
"
Additionally, an RI response MUST NOT be reused unless the request
   from the User Agent would generate an identical RI request to the
   dCDN as the one that resulted in the cached RI response.
"
This "MUST NOT" statement is immediately contradicted by the subsequent paragraph introducing the notion of Scope. So it cannot stay as is.
Also, you need to discuss the case of a request with everything identical except with different HTTP headers. That woudl generate a different RI request, yet can you reuse a previous RI response or not?

*** section 4.6:
OLD:
"
     "http": {
       "sc-status": 302,
       "cs-uri": "http://www.example.com"
       "sc-location":
         "http://sur1.dcdn.example/ucdn/example.com",
"
NEW:
"
     "http": {
       "sc-status": 302,
       "cs-uri": "http://www.example.com/movie100.mp4"
       "sc-location":
         "http://sur1.dcdn.example/ucdn/example/movie100.mp4",
"

*** section 4.7:
"
[[Editor's note: We've tried to keep error specification light weight
   & provide the hooks needed to help with debugging without trying to
   be overly prescriptive 
"
I see the intent, but I don't get what you are proposing exactly: to not define error values at all? to define a few only and allow implementations to easily define others with (or without?) registering those before?
Perhaps this could be achieved by creating a name based registry, with very easy allocation of new names.

*** section 4.8: In general, the text of that section could read better.
There is overlap between the 3rd paragraph and the first one.
OLD:
"
In order to prevent and detect RI request loops, each CDN MUST insert
   its CDN Provider ID into the cdn-path key of every RI request it
   originates or cascades.
"
NEW:
"
In order to prevent and detect RI request loops, each CDN MUST insert
   its CDN Provider ID into the cdn-path key of every RI request it
   originates, and MUST append its CDN Provider ID into the cdn-path key of every RI request it
   cascades.
"

OLD:
"
Transit CDNs
   should check the cdn-path and not cascade the RI request to
   downstream CDNs that are already listed in cdn-path.  CDNs MUST NOT
   propagate to any downstream CDNs if the number of CDN Provider IDs in
   cdn-path (including the CDN's own Provider ID) is equal to or greater
   than max-hops.
"
NEW:
"
Transit CDNs
   MUST check the cdn-path and not cascade the RI request to
   downstream CDNs that are already listed in cdn-path.  CDNs MUST NOT
   propagate to any downstream CDNs if the number of CDN Provider IDs in
   cdn-path (after appending their own CDN Provider ID) is equal to or greater
   than max-hops.
"

*** section 5:
"
Information passed over the RI could be considered personal or
   sensitive, for example RI requests contain parts of a User Agent's
   original request and RI responses reveal information about the dCDN's
   policy for which surrogates should serve which content/user
   locations.
" 
You can state after that paragraph, that a mitigation approach is for uCDN RI implementation to support a policy that minimises the information conveyed in the RI requests (or even possibly performs some anonimisation of the client IP address).

*** section 5:
"

   The RI interface also provides a mechanism whereby a uCDN could probe
   a dCDN and infer the dCDN's edge topology by making repeated RI
   requests for different content and/or UA IP addresses and correlating
   the responses from the dCDN.  Additionally the ability for a dCDN to
   indicate that a RI response applies more widely that the original
   request (via the scope dictionary) may significantly reduce the
   number of RI requests required to probe and infer the dCDN's edge
   topology.
   The same information could be obtained in the absence of the RI
   interface, but it could be more difficult to gather as it would
   require a distributed set of machines with a range of different IP
   addresses each making requests directly to the dCDN.  However, the RI
   facilitates easier collection of such information as it enables a
   single client to query the dCDN for a redirection/surrogate selection
   on behalf of any UA IP address.
"
You could perhaps state that:
	* by definition, use of recursive redirection assumes that dCDN is willing to provide more vsisbility to uCDN than with iterative. 
	* if that is a concern, dCDN could mitigate the problem by somewhat obfuscating the information returned (eg providing hostnames/CNAMEs that do not map to surrogates 1 to 1), or could return RTs that are subject to a second level resolution (eg regional Request Routers) which, pushed to the extreme, effectively degrades back to iterative redirection.

* section 5:
When discussing benefits of using TLS, please clarifies TLS comes "for free" thanks to the HTTP transport of RI.
Also, mention TLS also provides integrity protection (e.g. a RI response cannot be modified).

Editos:
=====

*** s/(RI) is one of the main building blocks/(RI) is one of the building blocks/
*** s/it is down to the uCDN to decide/it is up to the uCDN to decide/
*** s/in this draft/in this document/   [multiple occurrences]
*** s/and could be extended/and could be extended in future versions/
*** s/to help the Upstream CDN with future RI requests/to help the Upstream CDN handle future RI requests/
*** allocate a TAble number to all the tables, for easier reference in the text.
*** s/cacheable & not stale/cacheable and not stale/
*** s/It should be noted that the loop detection & prevention mechanisms described above only cover preventing and detecting loops within the RI itself./It should be noted that the loop detection and prevention mechanisms described above only prevents and detects loops within the RI itself./
*** s/As well as loops with the RI itself,/In addition to loops with the RI itself,/

On 21 Oct 2013, at 11:27, Ben Niven-Jenkins <[email-masked]> wrote:

> Colleagues,
> 
> This is an update to the redirection interface specification to add additional editorial text around data plane loop detection, media types to use, the JSON encoding and the security considerations.
> 
> There are still some things outstanding within the document but any review or suggestions for additional text would be most welcome :-)
> 
> Ben
> 
> 
> Begin forwarded message:
> 
>> From: [email-masked]
>> Date: 21 October 2013 10:30:41 GMT+01:00
>> To: [email-masked]
>> Cc: [email-masked]
>> Subject: [CDNi] I-D Action: draft-ietf-cdni-redirection-01.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           : Request Routing Redirection Interface for CDN Interconnection
>> 	Author(s)       : Wang Danhua
>>                         Ben Niven-Jenkins
>>                         He Xiaoyan
>>                         Ge Chen
>>                         Ni Wei
>> 	Filename        : draft-ietf-cdni-redirection-01.txt
>> 	Pages           : 24
>> 	Date            : 2013-10-21
>> 
>> Abstract:
>>  The Request Routing Interface comprises of (1) the asynchronous
>>  advertisement of footprint and capabilities by a downstream CDN that
>>  allows a upstream CDN to decide whether to redirect particular user
>>  requests to that downstream CDN; and (2) the synchronous operation of
>>  an upstream CDN requesting whether a downstream CDN is prepared to
>>  accept a user request and of a downstream CDN responding with how to
>>  actually redirect the user request.  This document describes an
>>  interface for the latter part, i.e. the CDNI request routing/
>>  Redirection Interface.
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-cdni-redirection
>> 
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-ietf-cdni-redirection-01
>> 
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-redirection-01
>> 
>> 
>> 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/
>> 
>> _______________________________________________
>> CDNi mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/cdni
> 
> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni