Subject: Re: [CDNi] Comments on draft-he-cdni-routing-request-redirection-03.txt

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Thu, 7 Mar 2013 15:03:49 +0000

Hello Ben and co-authors,

Thanks for addressing my comments.

This is definitely going in the right direction.

Below are a bunch of comments on the latest version (some editorial, some more significant).

Francois

Title: 
"Routing Request Redirection"  --->  "Request Routing Redirection Interface"

too many authors

* section 1:
I would suggest:
	* compressing/removing the 1st two paragraphs and simply refer to RFC6707
	* incorporate here the text that you currently have in the abstract which re-explains the break-down of the request routing interface into FCI and RI. This is the right place to remind the reader of how the Redirection Interface fits in the overall picture. It is also the right place to introduce the RI acronym.

* section 2:
"Examples of an application level redirection are HTTP and RTMP 302 redirections."
--> "Examples of an application level redirection are HTTP 302 Redirection and RTMP 302 Redirection."

* section 2:
at the end of the HTTP Redirection definition add:
"HTTP Redirection is a particular case of Application Level Redirection".

*section 3:
1st "Editors' note:. This discusses an interesting point. I suggest in next rev you replace this with a paragraph that basically says:
	* how upstream CDN decides which dCDN to talk to via RI is a local policy of uCDN and outside the scope of this doc
	* a typical example would be where the uCDN selects the dCDN for the request, and then queries that dCDN via RI and then redirects to the Redirection Target.
	* a more complex example would be where the  uCDN selects the dCDN for the request, and then queries that dCDN via RI and got a reject from dCDN. Then uCDN selects an alternative dCDN and then queries that dCDN via RI and then redirects to the Redirection Target.
	* yet an even more complex example would be where the uCDN selects two candidate dCDNs and queries both via RI before selecting one and using the Redirection Target provided by that dCDN.

* section 3:
"The Redirection Interface operates between a pair of interconnected CDNs."
--> " The Redirection Interface operates between the Request Routing systems of a pair of interconnected
   CDNs."

* everywhere:
	"Iterative Request Routing"  --> "Iterative Request Redirection" 
	"Recursive Request Routing"   --> "Recursive Request Redirection"
	"CDNi" --> "CDNI"

* section 3:
OLD:
"
In the case of Recursive Request Routing, an Upstream CDN forwards a
   CDNI request routing redirection request from a user agent to a
   Downstream CDN for the Downstream CDN to select a Redirection Target.
"
NEW:
"
In the case of Recursive Request Redirection, in order to perform redirection of a request received from a User Agent , the Upstream CDN queries the Downstream CDN so that the Downstream CDN can select and provide a Redirection Target.
"

* section 3:
"The initial Upstream CDN->User Agent redirection protocols" --> "The Upstream CDN->User Agent redirection protocols"

* "3.1.  Discussion on protocol type for CDNI RRRI"
there is no "RRRI" acronym defined.

* section 3.1:
I still have a problem with the content of that section and with Table1. In particular:
	* In the 3rd column ("dCDN response"). first the column heading should say "dCDN RI response". Then , it is misleading to say that the dCDN response is "DNS with…" or "HTTP 302": The dCDN response is actually an RI Response that allows the uCDN to build a DNS response or a HTTP 302 response.
	* in the 4th column ("Notes"). It is incorrect to say that "dCDN uses DNS" or "dCDN uses HTTP redirection" because all you know is that the uCDN will use DNS or HTTP, but the dCDN could actually decide to use whatever it wants. For example, the dCDN can provide a CNAME in the RI response that points to the dCDN request Router. as a result the USer-Agent the uCDN may perform DNS redirection but the dCDN will perform HTTP redirection.
This section needs to be cleaned up. The kyy points that have to be conveyed are:
	* one protocol (DNS or HTTP) is used between User-Agent and uCDN RR
	* RI is used between uCDN and dCDN, and dCDN uses that to provide a Redirection Target in the format that is compatible with the protocol used between User-Agent and uCDN RR
	* the dCDN has freedom in the Redirection Target it provides. Depending on the returned Redirection Target, we may see the following scenario:
		- the request is redirected to the final Surrogate (i.e. no more redirection)
		- the request is redirected to a request router that will be using a redirection protocol (DNS or HTTP) which may be the same as first redirection or may be different. This is controlled by the dCDN   

* Section 4:
"where the attributes of User Agent's requests" --> "where the attributes of a User Agent's request"

* section 4:
"The general call flow between Request Routers" --> "The general Recursive Request Redirection message flow between Request Routing systems"

* section 4: Figure with message flow
	- add a Figure Number + Figure Title
	- the numbers of the steps on the right doe snot match the step description under the figure

* section 4.1:
"e.g.  URI of the requested content, the client's location information."
--> "e.g.  URI of the requested content and the client's location information, when those are known by the uCDN Request Routing system."

* section 4.1: re Cacheability of the response.
I wonder if conveying the cache ability of the response _only_ in standards HTTP cache-Control mechanism is really the best way to do it, or should we not also encode it inside the body, just like the scope.
I think that has to do with expected implementations of the uCDN Request Router. If the uCDN RR makes direct use of the cached RI response to process subsequent requests, then it makes sense to have the cache ability encoded only in the HTTP headers. If the uCDN RR actually builds a separate table/database of information derived from the RI responses, then it makes more sense to have both cache ability and scope encoded inside the RI response body. Since the RI responses are not easily indexed via a URI (since they are all posted on the same Redirection Interface URI e.g. rr1.dcdn.example.net/dcdn/ri ) then I'd expect more the latter type of implementation. No?

*4.2 : re JSON encoding
Although the trade-offs may not be exactly the same across all Web Services based CDNI interfaces (RI, MI, Triggers), it would make sense to use the same type of encoding (e.g. JSON or XML) across all the interfaces ; unless there is really a good reason to not do so.
For now, can you add an "Editor's Note" saying that actual choice of encoding is still TBD and all JSON encoding is provided "as an example"?

*4.2:
"[Maybe a use case is
   responses is if the dCDN wants to indicate it is prepared to have a
   DNS redirection directly to it or a HTTP redirection from the uCDN RR
   to the dCDN and wants to indicate both options in a single
   response?]]
"
I would think that the uCDN is the one to choose whether it wants to redirect to dCDN via DNS or HTTP. So I don't think the dCDN needs to be able to say it can handle both.
However, this makes me think of a potential other requirements: perhaps it makes sense for the uCDN to influence/control whether the dCDN shoudl be using DNS/HTTP for further redirection. Whether DNS or HTTP redirection is used has visible impact to the enduser and (indirect) impact on the Content Provider. So the Content provider may want to impose one mode of redirection and then the uCDN needs to be able to tell the dCDN whether some mode are required/forbidden. For example, a Content Provider may want to have only DNS redirection used so Interconnected CDNs are transparent to endusers (from URI viewpoint). Then the uCDN may need to tell the dCDN that the dCDN ought to pick a Redirection Target that will achieve full DNS redirection (i.e. the dCDN cannot return as a RT a CNAME who get's resolved as the dCDN RR IP address).
This would call for an additional optional parameter in the RI request indicating required (or excluded) downstream redirection protocols.

*4.3.1:
"   o  The IP address of the User Agent" --> "   o  The IP address or prefix of the User Agent" 

On 16 Feb 2013, at 15:57, Ben Niven-Jenkins <[email-masked]> wrote:

> Francois,
> 
> Closing the loop on this. I've tried to address all your comments in my working copy of draft-he-cdni-routing-request-redirection-04.
> 
> I will be posting it in the next week once I've got feedback from my co-authors.
> 
> When it gets published let me know if you feel your comments below haven;t been addressed. In particular I re-wrote a lot of the document to incorporate the concept of Redirection targets and I'd be interested in your views on the new text.
> 
> Ben
> 
> On 7 Nov 2012, at 14:32, Francois Le Faucheur (flefauch) wrote:
> 
>> Thanks for your responses. Looks like we're synch. Please keep track of those points so they get addressed in the next rev.
>> You may want to bring up some of those today (e.g. need for link to metadata in Redirection request) , specifically during the "discussion slot" for Redirection, so we get input from others.
>> 
>> On 6 Nov 2012, at 10:25, Ben Niven-Jenkins wrote:
>> 
>>> Francois,
>>> 
>>> Please see below for my views.
>>> 
>>> On 5 Nov 2012, at 23:33, Francois Le Faucheur (flefauch) wrote:
>>> 
>>>> Hello,
>>>> 
>>>> (As an Individual).
>>>> 
>>>> In general, I feel this new version is going in the right direction.
>>>> 
>>>> Some high level comments:
>>>> 
>>>> 	* I think the spec should be less prescriptive as to how a dCDN builds its redirection response. For example in section 6.1.1, the text says:
>>>> "If the dCDN decides to use DNS Redirection, where the Downstream CDN
>>>> is redirecting directly to a surrogate in the Downstream CDN: the
>>>> Downstream CDN selects one or more surrogates and returns a CDNI RRRI
>>>> response containing the IP addresses of the selected surrogate(s), ...
>>>> If the dCDN decides to use DNS Redirection, where the Downstream CDN
>>>> is redirecting to a Request Router in the dCDN: : the Downstream CDN
>>>> returns a CDNI RRRI response containing a CNAME of the Downstream
>>>> CDN's Request Router(s), …
>>>> "
>>>> In this example, I think the dCDN should be free to return an IP address or a CNAME of the "redirection target" as it sees fit. The redirection target may be a Surrogate, a Request Router, a set of Surrogates, a 3rd party CDN Req Router, a 3rd party CDN Surrogate in case of cascaded CDNs,... whatever the dCDN sees fit.
>>>> You could possibly mention one of the behavior above as an example of what might happen, but it should just be an example and I recommend the spec be open as to the logic to populate the Redirection response.
>>> 
>>> Fair comment. Describing the different redirection possibilities & their applicability while at the same time talking about CDNI Redirection in a more generic way (so we don't keep repeating all the different nuances) was something we struggled a little with and is certainly an area of the draft (IMO) that needs more work to make the text clearer etc.
>>> 
>>> I like your idea of a 'redirection target' and maybe the right approach is to have a section defining/discussing the possibilities for redirection (A/AAAA/CNAME/Application level 302/etc) to a 'redirection target' in a dCDN and in the rest of the document just talk generically about redirection targets?
>>> 
>>>> * the document keeps talking about "encapsulating the enduser request" inside the Redirection Request. I find this misleading, because this is not about encapsulating the enduser request per-say, but rather to convey the key attributes of the enduser request.
>>> 
>>> Fair comment. We used 'encapsulating end user request' to distinguish between previous versions of the draft where the end user request was proxied to a dCDN via the same protocol that the end user request was made over.
>>> 
>>> Going forward that history doesn't matter and we should use better language to describe what we are actually doing.
>>> 
>>>> * for HTTP, the Redirection Request should allow passing other attributes in addition to client IP address and URI.
>>> 
>>> The draft currently just tries to define the minimum necessary information for a dCDN to be able to perform a redirection. There are probably other attributes that the dCDN would find useful and although it is not explicitly described in the current draft I think the CDNI Redirection 'protocol framework' in draft-he easily allows passing additional optional attributes. Describing how to extend the 'base protocol' with additional attributes is certainly something we should add in a future revision of the draft.
>>> 
>>> Personally, I am reluctant to define lots of theoretical attributes (that no one ends up using) to be included in a CDN Redirection request but I would like to hear views from implementors on the attributes they actually use (or plan to use as part of CDNI) to influence surrogate selection/redirection across a CDN interconnect.
>>> 
>>>> * the document requires that a pointer to Metadata be included in the Redirection request:
>>>> "For DNS redirection, the uCDN also needs to provide in the CDNI RRRI
>>>> request the a link to the associated CDNI Metadata for the host/
>>>> domain being requested."
>>>> Considering that the latest Metadata interface allows the dCDN to walk down the metadata tree for any content without seeding any initial info/pointers, I am not sure there is a benefit in passing a link to metadata inside the Redirection request. If would potentially save the dCDN Request Router to do the lookup on Content-->Metadata , but would require the uCDN Request Router to do the same on its behalf. Besides the dCDN has to do that looup anyways to get the Metadata for serving the content.
>>> 
>>> This is in my slides for Thursday. When I was thinking about CDN Redirection a while ago I convinced myself a link to CDNI Metadata was useful so when I started working on draft-he I included it, but since then I've been struggling to remind myself why I originally thought it was required so I'm certainly open to removing it.
>>> 
>>>> * the redirection interface will need to discuss handling of URI Signing 
>>> 
>>> Sure. Personally I'd like the uri signing/token authorisation work in the WG to mature a bit more first just to avoid having to keep draft-he aligned with a still moving target.
>>> 
>>> At a minimum we should include in the next revision a comment that we still need to factor token authorisation into the document.
>>> 
>>>> * we need to agree on a set of acronyms to refer to the "CDNI Request Routing/Redirection Interface". I will bring that up during the meeting this week.
>>> 
>>> OK
>>> 
>>> Ben
>>> 
>>>> 
>>>> HTH
>>>> 
>>>> Francois
>>>> 
>>>> 
>>>> On 21 Oct 2012, at 23:02, <[email-masked]>
>>>> <[email-masked]> wrote:
>>>> 
>>>>> 
>>>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>>>> 
>>>>> 
>>>>> 	Title           : Routing Request Redirection for CDN Interconnection
>>>>> 	Author(s)       : Wang Danhua (editor)
>>>>>                      He Xiaoyan
>>>>>                      Spencer Dawkins
>>>>>                      Ge Chen
>>>>>                      Ni Wei
>>>>>                      Zhang Yunfei
>>>>>                      Ben Niven-Jenkins
>>>>> 	Filename        : draft-he-cdni-routing-request-redirection-03.txt
>>>>> 	Pages           : 19
>>>>> 	Date            : 2012-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-he-cdni-routing-request-redirection
>>>>> 
>>>>> There's also a htmlized version available at:
>>>>> http://tools.ietf.org/html/draft-he-cdni-routing-request-redirection-03
>>>>> 
>>>>> A diff from the previous version is available at:
>>>>> http://www.ietf.org/rfcdiff?url2=draft-he-cdni-routing-request-redirection-03
>>>>> 
>>>>> 
>>>>> Internet-Drafts are also available by anonymous FTP at:
>>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>> 
>>>>> _______________________________________________
>>>>> I-D-Announce mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/i-d-announce
>>>>> Internet-Draft directories: http://www.ietf.org/shadow.html
>>>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>> 
>>>> _______________________________________________
>>>> CDNi mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/cdni
>>> 
>> 
>

---

From: Scott Wainner <[email-masked]>
Date: Mon, 18 Mar 2013 12:26:20 -0400

|4.2

|A single request or response MUST contain only one of the dns or http keys.

A DNS query to the uCDN can't result in an HTTP response to the client.  
The client or DNS forwarder needs a DNS response. Therefore, I see no 
need for the HTTP key if the RI request type is DNS.

An HTTP query to the uCDN requires an HTTP response to the client. 
Certainly, an HTTP response on the RI request is appropriate. However, a 
DNS response on the uCDN's RI request using an HTTP key would presumably 
mean the target of the RI wasn't satisfactorily and the uCDN RR would 
have to resolve the targets DNS response.  Not sure how valuable that 
would be.

|[Editor's note: Is the cdn-path useful on responses as well?]

Yes, a uCDN RR that is assessing alternate CDN's in parallel would 
presumably need to know if the responses of candidate transit dCDN's 
'converged' at some point.  Consider the case where uCDN is assessing 
multiple options:

     a. uCDN -> dCDN-1 -> dCDN-2
     b. uCDN -> dCDN-2

Most likely, the uCDN would want to choose dCDN-2 directly as opposed to 
using dCDN-1 as a transit.

|[Editor's note: Need some text/section specifying the Media Types for 
RI requests/responses]

Are you thinking classes of content such as video, audio, images or 
explicit MIME types?

Are we assuming that the dCDN will only serve a subset of the content 
classes (e.g. images only, images and audio, but no video)?

|4.3.1

| c-subnet : String : No : The IP address of the UA in CIDR format.

What relevance does this have?  Are we trying to assert some assumed 
scope (i.e. other clients in the same c-subnet)?  I suspect that this 
may be RFC1918 space; therefore, its usefulness is suspect.

|4.4.1 HTTP Redirection requests

transaction_id
     integer
     mandatory
     : identifier created by uCDN for correlating request/responses

session_id
     string
     optional? | mandatory?
     : session identifier reflected from proprietary client HTTP request

method:
     string {http | rtsp | rtmp}
     mandatory
     : describes method of request/response

client_ip:
     format {v4 | v6}
     string
     mandatory
     : extracted from HTTP HEADER x-forwarded-for or client request IP

forwarder:
     format {v4 | v6}
     string
     mandatory
     : extracted from HTTP HEADER via or client request IP

start_avail:
     format {epoch | gmt}
     string
     optional
     : extracted from URL of client request

expiration:
     format {epoch | gmt}
     string
     optional
     : extracted from URL of client request

|4.4.2 HTTP Redirection responses

add

transaction_id
     integer
     mandatory
     : identifier created by uCDN for correlating request/responses

session_id
     string
     optional
     : reflection of uCDN session_id or generated by dCDN

method
     string {http | rtsp | rtmp}
     mandatory
     : describes method of request/response

start_avail:
     format {epoch | gmt}
     string
     optional
     : reflection of uCDN start_avail or generated by dCDN

expiration:
     format {epoch | gmt}
     string
     optional
     : reflection of uCDN expiration or generated by dCDN

| 4.5 Indicating the cache-ability and scope of responses

I think this would only be applicable to URL's that are not signed when 
using the Recursive mode.

I believe most dCDN will want to authenticate each client request. If we 
expand the scope of a dCDN response to include a wider range of subnets, 
that means the uCDN will have to sign URL requests using the chosen 
dCDN's method and algorithms.  The advantage of the RI interface is that 
the uCDN does not need to know the methods of each dCDN; the dCDN can 
sign the URL according to its own rules and simply provide the signed 
URL PATH back to the uCDN as an opaque string.

[NOTE] In contrast, the Iterative mode requires the uCDN to sign the URL 
according to the method of the dCDN (or know that a particular URL can 
remain unsigned when delegating).  Since the client request interface is 
not in scope of CDNI, we can't specify the parameters in the URL given 
back to the client (we have to consider the PATH as an opaque string).

| 4.6 Error responses

method:
     unsupported

client_ip:
     unsupported type

forwarder:
     unsupported type

start_avail:
     premature

expiration:
     too late

| 8. Outstanding considerations

We discussed in the FCI design team the ability for the dCDN to 
advertise an abstract 'footprint' definition associated with a 
capability.  For example, a region might be defined that represents an 
aggregate geographic footprint as follows:

uCDN defines:
     north_america = CA and US and MX
dCDN receives definition in MI:
     footprint 'north_america' = CA and US and MX

Are there any merits in having the uCDN pass via the RI any client 
location attributes? Certainly, the dCDN could respond with an error if 
the client location fell outside the boundaries of the contract.

Scott

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Tue, 19 Mar 2013 00:46:45 +0000

Hi,

(as an Individual)

And another comment regarding:
"

 [[Editor's note: What other attributes of the request should we
   include?  METHOD?  Version? other headers?]]

"
I recommend including the ability to pass on any HTTP-header. Example use cases include:
* select final CDN based on user-agent (e.g. some CDNs maybe know to perform better for some type of streaming)
* select final CDN based on X-forwarded-for

These parameters are easy to include by uCDN request router and can always be trivially ignored by dCDN request router. So the impact of adding that in the base spec should be minimal.

Cheers

Francois

On 7 Mar 2013, at 07:03, Francois Le Faucheur (flefauch) <[email-masked]<mailto:[email-masked]>> wrote:

Francois

Title:

too many authors

* section 1:
I would suggest:

* section 2:

* section 2:

*section 3:

* section 3:

* everywhere:

* section 3:
OLD:
"

* section 3:

* section 3.1:

* Section 4:

* section 4:

* section 4.1:

* section 4.1: re Cacheability of the response.
I wonder if conveying the cache ability of the response _only_ in standards HTTP cache-Control mechanism is really the best way to do it, or should we not also encode it inside the body, just like the scope.
I think that has to do with expected implementations of the uCDN Request Router. If the uCDN RR makes direct use of the cached RI response to process subsequent requests, then it makes sense to have the cache ability encoded only in the HTTP headers. If the uCDN RR actually builds a separate table/database of information derived from the RI responses, then it makes more sense to have both cache ability and scope encoded inside the RI response body. Since the RI responses are not easily indexed via a URI (since they are all posted on the same Redirection Interface URI e.g. rr1.dcdn.example.net/dcdn/ri<http://rr1.dcdn.example.net/dcdn/ri> ) then I'd expect more the latter type of implementation. No?

*4.2 : re JSON encoding

*4.2:
"[Maybe a use case is

*4.3.1:

On 16 Feb 2013, at 15:57, Ben Niven-Jenkins <[email-masked]<mailto:[email-masked]>> wrote:

Francois,

Ben

Francois,

Hello,

(As an Individual).

OK

Ben

HTH

Francois

On 21 Oct 2012, at 23:02, <[email-masked]<mailto:[email-masked]>>
<[email-masked]<mailto:[email-masked]>> wrote:

Abstract:

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

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

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Sun, 31 Mar 2013 17:41:58 +0100

Francois,

> These parameters are easy to include by uCDN request router and can always be trivially ignored by dCDN request router. So the impact of adding that in the base spec should be minimal.

As per discussion/agreement in Orlando, I've added a generic mechanism for uCDN to signal User Agent headers to dCDN in my working copy of draft-he-cdni-routing-request-redirection-05.

Ben

> 
> Cheers
> 
> Francois
> 
> 
> On 7 Mar 2013, at 07:03, Francois Le Faucheur (flefauch) <[email-masked]> wrote:
>

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Sun, 31 Mar 2013 18:58:06 +0100

Francois,

> "Routing Request Redirection"  --->  "Request Routing Redirection Interface"

Done.

> too many authors

Done.

> 	* incorporate here the text that you currently have in the abstract which re-explains the break-down of the request routing interface into FCI and RI. This is the right place to remind the reader…

Done.

> --> "Examples of an application level redirection are HTTP 302 Redirection and RTMP 302 Redirection."

Done.

> "HTTP Redirection is a particular case of Application Level Redirection".

Done.

> 	* yet an even more complex example would be where the uCDN selects two candidate dCDNs and queries both via RI before selecting one and using the Redirection Target provided by that dCDN.

Done.

> --> " The Redirection Interface operates between the Request Routing systems of a pair of interconnected

Done.

> 	"Recursive Request Routing"   --> "Recursive Request Redirection"

Done.

> In the case of Recursive Request Redirection, in order to perform redirection of a request received from a User Agent , the Upstream CDN queries the Downstream CDN so that the Downstream CDN can se…

Done.

> "The initial Upstream CDN->User Agent redirection protocols" --> "The Upstream CDN->User Agent redirection protocols"

Done.

> 		- the request is redirected to a request router that will be using a redirection protocol (DNS or HTTP) which may be the same as first redirection or may be different. This is controlled by the d…

I've added a paragraph to section 3 using your text above as a base and deleted section 3.1.

> "where the attributes of User Agent's requests" --> "where the attributes of a User Agent's request"

Done.

> "The general call flow between Request Routers" --> "The general Recursive Request Redirection message flow between Request Routing systems"

Done.

> 	- the numbers of the steps on the right doe snot match the step description under the figure

Done.

> --> "e.g.  URI of the requested content and the client's location information, when those are known by the uCDN Request Routing system."

Done.

> I think that has to do with expected implementations of the uCDN Request Router. If the uCDN RR makes direct use of the cached RI response to process subsequent requests, then it makes sense to hav…

There is nothing to stop an implementation extracting the cacheability from the Cache-Control header and storing it in its table/database.

The advantage of having the cacheability in the HTTP Cache-Control header is that RI request/responses can be cached by HTTP intermediaries which may be useful in some scenarios. I fear if we put the cacheability in the response body folks will forget to reflect it in the HTTP headers too. It also means we need to specify what to do if the Cache-Control & Response Body values don't match.

> For now, can you add an "Editor's Note" saying that actual choice of encoding is still TBD and all JSON encoding is provided "as an example"?

I think between you writing this and me getting around to replying, we're pretty much agreed to converge on JSON, so I think this editor's note is no longer required.

> This would call for an additional optional parameter in the RI request indicating required (or excluded) downstream redirection protocols.

Does it really require that or just an additional property in the dns key of RI requests as you can't convert a HTTP 302 back into DNS redirection as such.

In my working copy I've added a dns-only property to the dns key with the following description:

If True then dCDN MUST only use DNS redirection to a surrogate and MUST include the dns-only property set to True on any cascaded RI requests. Defaults to False.

> "   o  The IP address of the User Agent" --> "   o  The IP address or prefix of the User Agent" 

Done.

Ben

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Sun, 31 Mar 2013 19:22:27 +0100

Scott,

On 18 Mar 2013, at 16:26, Scott Wainner wrote:

> A DNS query to the uCDN can't result in an HTTP response to the client.  The client or DNS forwarder needs a DNS response.  Therefore, I see no need for the HTTP key if the RI request type is DNS.
> 
> An HTTP query to the uCDN requires an HTTP response to the client.  Certainly, an HTTP response on the RI request is appropriate.  However, a DNS response on the uCDN's RI request using an HTTP key would presumably mean the target of the RI wasn't satisfactorily and the uCDN RR would have to resolve the targets DNS response.  Not sure how valuable that would be.

This was also discussed during the WG session in Orlando and consensus was to restrict the response to only one of the dns or http keys. I have updated my working copy of -05 accordingly.

> Yes, a uCDN RR that is assessing alternate CDN's in parallel would presumably need to know if the responses of candidate transit dCDN's 'converged' at some point.  Consider the case where uCDN is assessing multiple options:
> 
> Most likely, the uCDN would want to choose dCDN-2 directly as opposed to using dCDN-1 as a transit.

OK I have added this to my working copy of -05.

> |[Editor's note: Need some text/section specifying the Media Types for RI requests/responses]
> 
> Are you thinking classes of content such as video, audio, images or explicit MIME types?

No, what I mean is we need to specify the media types to use for the RI requests/responses themselves e.g. application/cdni.rirequest+json

> Are we assuming that the dCDN will only serve a subset of the content classes (e.g. images only, images and audio, but no video)?
> 
> |4.3.1
> 
> What relevance does this have?  Are we trying to assert some assumed scope (i.e. other clients in the same c-subnet)?  I suspect that this may be RFC1918 space; therefore, its usefulness is suspect.

It is for cases such as when the User Agent's DNS resolver supports draft-vandergaast-edns-client-subnet and the uCDN request router is able to pass on more specific IP address details than just the DNS resolver.

> |4.4.1 HTTP Redirection requests

<snip>

In my working copy of -05 I've added the ability for the uCDN to pass any HTTP headers to the dCDN in a generic way which I think addresses what you asked for here.

> |4.4.2 HTTP Redirection responses

<snip>

I have put an Editor's note in -05 asking whether the generic header mechanism used for RI requests should be used for RI responses too. If the mechanism addresses your requirements I'll add it in?

> I think this would only be applicable to URL's that are not signed when using the Recursive mode.
> 
> I believe most dCDN will want to authenticate each client request.  If we expand the scope of a dCDN response to include a wider range of subnets, that means the uCDN will have to sign URL requests using the chosen dCDN's method and algorithms.  The advantage of the RI interface is that the uCDN does not need to know the methods of each dCDN; the dCDN can sign the URL according to its own rules and simply provide the signed URL PATH back to the uCDN as an opaque string.
> 
> [NOTE] In contrast, the Iterative mode requires the uCDN to sign the URL according to the method of the dCDN (or know that a particular URL can remain unsigned when delegating).  Since the client request interface is not in scope of CDNI, we can't specify the parameters in the URL given back to the client (we have to consider the PATH as an opaque string).

Sure but control is completely in the hands of the dCDN. If it wants to authorise every single request and do any resigning itself then it can return uncacheable responses. For other use cases the dCDN has the option of returning cacheable responses if it wants to.

>     too late

I'm sorry but I don't understand what you are asking for here?

> We discussed in the FCI design team the ability for the dCDN to advertise an abstract 'footprint' definition associated with a capability.  For example, a region might be defined that represents an aggregate geographic footprint as follows:
> 
> uCDN defines:
> Are there any merits in having the uCDN pass via the RI any client location attributes? Certainly, the dCDN could respond with an error if the client location fell outside the boundaries of the contract.

I'm not exactly sure what you're suggesting? If it's passing footprint/location information inband with the RI request I don't think we should do that.

Or are you thinking more along the lines of the uCDN expressing the semantic "I [uCDN] geo-located the User-Agent as north_america"?

Thanks
Ben