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

From: [email-masked]
Date: Mon, 10 Nov 2014 15:39:55 -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           : Request Routing Redirection Interface for CDN Interconnection
        Authors         : Ben Niven-Jenkins
                          Ray van Brandenburg
	Filename        : draft-ietf-cdni-redirection-05.txt
	Pages           : 29
	Date            : 2014-11-10

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

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

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: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 10 Nov 2014 23:41:25 +0000

Colleagues,

This update just contains a small number of editorial changes the editors noticed when preparing for IETF91.

Regards
Ben

On 10 Nov 2014, at 23:39, [email-masked] wrote:

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

---

From: Kevin Ma J <[email-masked]>
Date: Fri, 28 Nov 2014 22:33:20 +0000

Hi Ben/Ray,

  Per the chairs' request, I've reviewed the latest doc; comments/questions below.

thanx.

--  Kevin J. Ma

General:

- There is a lot of mixed use of "Upstream CDN" vs. "uCDN" and
  "Downstream CDN" vs. "dCDN".  To make the document consistent,
  I would change all instances of the former to the latter.

- There is inconsistent use of "a RI" vs. "an RI".  The latter seems
  more natural to me, but it would be good to make it consistent.

- There are a number of places where commas might help readability,
  e.g., "For example " -> "For example, ", "i.e." -> "i.e.,", "e.g." -> "e.g.,"

- There are a number of somewhat long sentences that could be broken up
  or punctuated for readability, e.g.:

  "For example, a dCDN may know that it will always select
   the same Surrogates for a given set of User Agent IP addresses and in
   order to reduce request volume across the RI or to remove the
   additional latency associated with an RI request, the dCDN may wish
   to indicate that set of User Agent IP addresses to the uCDN in the
   initial RI response."

  to something like:

  "For example, a dCDN may know that it will always select
   the same Surrogates for a given set of User Agent IP addresses; in
   order to reduce request volume across the RI, or to remove the
   additional latency associated with an RI request, the dCDN may wish
   to indicate that set of User Agent IP addresses to the uCDN, in the
   initial RI response."

Section 3:

- RI is necessary for recursive redirection, but interconnection could
  still occur with interactive redirection?  Might want to rephrase this:

    "main building blocks required in order to interconnect"

- I would split this into a second sentence starting with "Depending" 

    "and depending on the returned Redirection Target"

- "in dCDN or another CDN" -> "in the dCDN or another CDN"

- I think that this:

  "that will be using a
   redirection protocol (DNS or HTTP) which may or may not be the
   same as the original redirection protocol."

  is trying to say the following:

  "that may use a different redirection protocol (DNS or HTTP)
   than the one specified in the RI request."

  Is that the only time the RI would ever point to a request router?

- this can be simplified:

  "To enable communication
   over the Redirection Interface, the two interconnected CDNs need to
   know the end point (URI) in the other CDN to query.  For example, an
   Upstream CDN needs to know the URI (end point) in a Downstream CDN to
   send its CDNI request routing queries to."

  to this:

  "To enable communication
   over the Redirection Interface, the uCDN needs to know the URI (end
   point) in the dCDN to which it may CDNI send request routing queries."

- "CDNI control interface" -> "CDNI Control interface"

- Is the following statement true?  I thought the idea of advertising
  support for redirection mode was so that a given CDN did not have to
  support both mechanisms?

  "CDNI solutions are required to support both of the request routing
   mechanisms illustrated in section 2.1 of [RFC7336], namely Iterative
   Request Redirection and Recursive Request Redirection."

  When using the RI, it doesn't matter if the dCDNs support either;
  they could support neither.  As long as the uCDN supported one, the
  other, or both, and the dCDNs returned surrogate addresses over the
  RI, then, it should just work?

- I think this can be simplified:

  "Therefore, the Redirection Interface is only relevant in the case of
   Recursive Request Redirection and so this document will not discuss
   Iterative Request Redirection further."

  to say:

  "This document will therefore only focus on Recursive Request Redirection."

- "it is down to the uCDN" -> "it is up to the uCDN"

- "or otherwise reject the" -> "or otherwise rejects the"

- "However the Redirection Interface" -> "However. the RI"

- I think it would be useful to list the actual requirements
  (i assume this is referring to GEN-11 and RI-5) and
  possibly have a reference to the requirements RFC7337.

  "Also, according to the CDNI generic and request routing interface
   requirements, the CDNI solution shall support mechanisms to prevent
   and detect RI request loops"
 
  e.g.:

  "CDNI requirements GEN-11 and RI-5 [RFC7337] specify that 
   the CDNI solution shall support mechanisms to prevent
   and detect RI request loops"

Section 4:

- "for brevity, only" -> "for brevity; only"

- "either DNS request or HTTP request" -> "either DNS or HTTP"
  "it recognizes" -> "recognizes"
  "or that CDN B is one" -> "CDN B may be one"

- "is well formed, etc." -> "is well formed,"

Section 4.1:

- "ought to" -> "SHOULD" ?

- Could add subsections to separate request and response text.

- "return additional policy to" -> "return additional policy information to"
  "the Upstream CDN to help the Upstream CDN" -> "the uCDN to help it"

- This is a little confusing as to whether the indication is in the
  HTTP header or if the response is in the HTTP header.  I assume we
  mean the former, so perhaps rearranging this:

  "An indication of the cacheability of the response carried in the
   HTTP response headers

  to something like this:

  "Cacheability indicators signaled via HTTP response headers"

  Similarly, this:

  "The scope of the response (if it is cacheable) carried within the
   body of the HTTP response."

  could be changes to something like this:

  "The scope signaled in the HTTP response body."

  Might want to add a reference to Section 4.8.

- Is the scope only signaled when the response cacheable?
  Is the scope only allowed to be signaled when the response is cacheable?
  The scope only really makes sense when it's cacheable, but is it an
  error to send a scope if the response is not cacheable?

Section 4.2:

- This might be clearer if directed specifically at the table:

  "The following top level keys are defined along with whether they are
   applicable to RI requests, RI responses or to both RI requests and
   responses:"

  maybe something like:

  "The following table defines the top level keys, along with whether
   they are applicable to RI requests, RI responses, or both:"

  The table itself might be easier to understand, however, if it was
  split into two separate tables, one for request keys and another for
  response keys, rather than having to parse the description text.

- In the table, cdn-path is listed as "Both", however, the description
  talks about "this request".  Presumably, the list is present in the
  response, containing the final list of CDN Provider IDs as known to
  the respondent, associated with the request to which it is
  responding?  Might want to make that more explicit.

- "crudely" -> "coarsely"

- Though the cdn-path MAY be reflected back, are the transit CDNs
  allowed to remove themselves (and all further dCDNs) from the chain
  as they respond, or are they required to maintain the full chain, if
  they choose to include cdn-path in the response.

  Similarly, is any CDN in the chain allowed to remove cdn-path from
  the response, even if further downstream CDNs have included it
  (i.e., the ultimate CDN decided to reflect)?

Section 4.4.1:

- What is the use case for the dns-only flag?  Is it intended to
  improve delivery performance?  Would it be configured by the
  content owner to enforce request routing properties?

- If dns-only is set to true, and the transit CDN does not support DNS
  redirection, is it always safe to propagate the request (assuming
  the hop count and loop detection don't error out)?  Presumably there
  is eventually either a dCDN that supports DNS or an error?

  It's not clear to me how this flag should be used (see also
  questions on next section)?  If the authoritative CDN is returning
  the DNS resolution to the UA, but the address provided by the dCDN
  is a CNAME, does the dCDN have to honor that flag in subsequent DNS
  queries to the dCDN?

Section 4.4.2:

- These might be clearer with the surrogate/request router as the object:

  "o  The IP address(es) of (or the CNAME of) the RT (if the dCDN is
      performing DNS based redirection directly to a surrogate); or

   o  The IP address(es) of (or the CNAME of) a RT which is a Request
      Router (if the dCDN is performing HTTP based redirection)."

  maybe something like:

  "o  The IP address(es) of (or the CNAME of) the dCDN surrogate as
      the RT (if the dCDN is allowing the uCDN to perform DNS redirection); or

   o  The IP address(es) of (or the CNAME of) the dCDN request router
      as the RT (if the dCDN will perform request redirection itself)."

- If the dCDN returned a CNAME to be resolved by its request router,
  could the dCDN at that point choose to do either DNS or HTTP
  redirection, or is the dCDN, at the time of the RI request,
  promising not to do HTTP redirection when resolving the CNAME?

  "o  The IP address(es) of (or the CNAME of) a RT which is a Request
      Router (if the dCDN is performing HTTP based redirection).  A dCDN
      MUST NOT return a RT which is a Request Router if the dns-only key
      is set to True in the RI request."

- Can we add the units for "ttl" to the description?  Should be seconds?

  This is the TTL for the DNS response?  Is there an implied scope for
  the RI response?  Should the uCDN not try to glean anything from it?
  Either way, we might want to explicitly state whether or not the
  uCDN can use that information (especially if the information
  conflicts with the scope information in the HTTP response headers of
  the RI response).

Section 4.5.1:

- For "cs-uri", is this the RFC2616 Request-URI from the HTTP request,
  or is this the RFC7230 Effective Request URI?  Could/Should/Would
  the uCDN ever transform the URI to make it understandable to the dCDN?

- "User Agent's DNS query/request." -> "User Agent's HTTP request."

Section 4.5.2:

- I think this is confusing because the dCDN is not performing HTTP
  redirection so much as it is allowing the uCDN to perform HTTP
  redirection; the dCDN is just responding to the RI request?

  "o  A URL pointing to the selected RT (if the dCDN is performing HTTP
      based redirection directly to a surrogate); or"

  Perhaps it would be more clear with something like:

  "o  A URL pointing to the selected surrogate as the RT (if the dCDN
      is allowing the uCDN to directly address the surrogate); or"

  If the dCDN returns a URL with a DNS name rather than an IP address,
  then the dCDN may still do DNS redirection?  There's no way to tell
  from the URL returned via the RI whether the dCDN is doing any
  further redirection (DNS or HTTP)?

- This could be modified like the one in 4.4.2:

  "o  A URL pointing to a RT which is a Request Router (if the dCDN is
      not redirecting the User Agent directly to a surrogate)."

  to something like:

  "o  The IP address(es) of the dCDN request router
      as the RT (if the dCDN will perform request redirection itself)."

- Why is there a special case for "sc(cache-control)" in the table?
  It is not mandatory and already covered by "sc(<headername>)"?

  This is the cacheability of the HTTP response.  Is there an implied
  scope for the RI response?  Should the uCDN not try to glean
  anything from it?  Either way, we might want to explicitly state
  whether or not the uCDN can use that information (especially if the
  information conflicts with the scope information in the HTTP
  response headers of the RI response).

- "some or all" -> "any or all"

Section 4.6:

- "except for the c-ip field" -> "except for the c-ip field,"

Section 4.7:

- "for a dCDN not being able" -> "for a dCDN to be unable"

- "diagnostics of issues" -> "diagnosis of issues"

- "The resolution of such issues is outside the scope of this
   document and this document therefore does not specify the consequent
   actions a uCDN should take upon receiving a particular error code." ->

  "The resolution of such issues is outside the scope of this
   document; this document does not specify any consequent
   actions a uCDN should take upon receiving a particular error code."

- Are error-codes generally vendor implementation/deployment dependent?

  "A three-digit numeric code defined by the server"

  Should there be a registry for all error codes?
  If the registry is mandatory, and/or if conflicts are disallowed,
  might want to note that.  If we are allowing vendors to define
  overlapping error codes at will, is it just left up to the uCDN to
  figure out what to do with them?

- Depending on the answer to the dns-only question above, should there
  also be an error code for "dCDN does not support DNS redirection and
  does not want to give a surrogate address and dns-only set to true"?
  Would that just be a 500?

- Is it valid for the dCDN to set the Cache-Control header for an
  error response, e.g., out of capacity for the next 20 min?

- Is it necessary to have both of these requirements?  If the transit
  CDNs never forward to looped dCDNs, the dCDNs should never be able
  to detect a loop (assuming a uCDN doesn't sent to itself)?

  "When receiving RI requests a dCDN MUST check
   the cdn-path and reject any RI requests which already contain the
   downstream CDN's Provider ID in the cdn-path.  Transit CDNs MUST
   check the cdn-path and not cascade the RI request to downstream CDNs
   that are already listed in cdn-path."

  I don't see any harm in listing both checks, just to be safe, but I
  didn't know if I was missing something?

- Why aren't the 502 and 503 errors a MUST?

  "If a downstream CDN receives a RI request whose cdn-path already
   contains that downstream CDN's Provider ID the downstream CDN SHOULD
   send a RI response with an error code of 502."

  "If a downstream CDN receives a RI request where the number of CDN
   Provider IDs in cdn-path is greater than max-hops, the downstream CDN
   SHOULD send a RI response with an error code of 503."

- "As well as loops with the RI itself, there" -> "There"

Section 5:

- Should we make TLS a MUST?  Using similar text to the triggers draft?

> -----Original Message-----
> From: CDNi [mailto:[email-masked]] On Behalf Of Ben Niven-Jenkins
> Sent: Monday, November 10, 2014 6:41 PM
> To: [email-masked]
> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-redirection-05.txt
> 
> Colleagues,
>