[CDNi] Shepherd Review of draft-ietf-cdni-redirection-14.txt

[Kevin Ma J <[e-mail]>]

Hi Ben/Ray,

  (as chair) I've completed my shepherd's review of the document and have enclosed some questions comments below.  Most are nits, but the IANA Considerations and Normative/Informative Reference comments at the end need to be addressed.

thanx!

--  Kevin J. Ma


- general: there is inconsistency in the use of "Redirection Interface" and "Redirection interface"; it seems to be a problem in all the docs, but logging mostly uses the lowercase "i"

- general: "e.g. " -> "e.g., ", "i.e. " -> "i.e., ", and "For example " -> "For example, "

- section 3: The bulleted items are not complete sentences, perhaps:

     "The final Surrogate, which may be in the dCDN that returned the RI
      response to the uCDN, or another CDN (if the dCDN delegates the
      delivery to another CDN)." ->
     "The final Surrogate, which may be in the dCDN that returned the RI
      response to the uCDN, or another CDN (if the dCDN delegates the
      delivery to another CDN); or"

- section 3: comma after "Therefore":

  "Therefore the scope of this document is limited to Recursive
   Request Redirection." ->
  "Therefore, the scope of this document is limited to Recursive
   Request Redirection."

- section 3: the colon should be a semi-colon:

  "domain in the URL dereferenced to reach the uCDN: without operational
   precautions, and in the absence of DNSSEC, this can make a legitimate
   redirection look like a DNS-based attack" ->
  "domain in the URL dereferenced to reach the uCDN; without operational
   precautions, and in the absence of DNSSEC, this can make a legitimate
   redirection look like a DNS-based attack"

- section 4: Though it mentions being extensible, we do not give any guidance on how to extend the RI.  Should we?  Or should we just leave it?

  "Finally, the RI is easily extendable to support other User Agent
   request redirection methods (e.g.  RTMP 302 redirection)."

  One thought is that the way to extend this would be: write a new RFC, with new RI JSON objects, and registering a new redirection mode capability?

- section 4.1: suggested edit:

     "The scope of the response (if it is cacheable) signaled the HTTP
      response body of the RI response.  For example whether the
      response applies to a wider range of IP addresses than what was
      included in the RI request." ->
     "The scope of a cacheable response signaled via the HTTP
      response body of the RI response, for example, whether the
      response applies to a wider range of IP addresses than what was
      included in the RI request."

- section 4.3: the reference to RFC7336 (Framework) should be to RFC7736 (Media Type)

- section 4.4.2: Should this also state that the dns dictionary MUST contain the rcode and name keys?

  "If a dns dictionary is included in the RI
   response, it MUST include at least one of the following keys: a,
   aaaa, cname."

- section 4.5.2: missing "and":

  "it MUST include at least the following keys: sc-
   status, sc-version, sc-reason, cs-uri, sc-(location)." ->
  "it MUST include at least the following keys: sc-
   status, sc-version, sc-reason, cs-uri, and sc-(location)."

- section 4.8: this implies that the CDN knows the dCDN's provider ID?  Is that typically true?  Would it be simpler to have CDNs check just their own provider ID?  I would suggest removing this sentence?

  "Transit CDNs MUST check the cdn-
   path and not cascade the RI request to dCDNs that are already listed
   in cdn-path."

- section 4.8: suggested edit:

  "As well as loops within the RI itself," ->
  "Beside loops within the RI itself,"

- section 4.8: missing commas:

  "for example if the IP
   address(es) or URI(s) returned in RI responses do not resolve
   directly to a surrogate in the final dCDN there is the possibility" ->
  "for example, if the IP
   address(es) or URI(s) returned in RI responses do not resolve
   directly to a surrogate in the final dCDN, there is the possibility"

- section 4.8: typo: "continuosly" -> "continuously"

- section 5.1: bullet punctuation:

     "the dCDN and uCDN to authorize each other (to ensure they are
      transmitting/receiving CDNI Redirection messages to/from an
      authorized CDN)" ->
     "the dCDN and uCDN to authorize each other (to ensure they are
      transmitting/receiving CDNI Redirection messages to/from an
      authorized CDN);"

     "CDNI Redirection interface messages to be transmitted with
      confidentiality." ->
     "CDNI Redirection interface messages to be transmitted with
      confidentiality; and"

- section 5.2: the rest of the doc uses "an RI", but this section uses "a RI"; should make it consistent.

- section 5.2: the first 11 words of section 5.2 are identical to the first 11 words of section 5; maybe just remove them from section 5.2?

  "Information passed over the RI could be considered personal or
   sensitive.  In particular, parts" ->
  "Parts"

- section 5.2: suggested edit:

  "do obtain information regarding End User IP addresses
   and requested URIs that they wouldn't had the RI not been used." ->
  "do obtain information regarding End User IP addresses
   and requested URIs that they wouldn't have, had the RI not been used."

- section 6.2: should this be a "subregistry within the "Content Delivery Network Interconnection (CDNI) Parameters" registry."?

- section 6.2: do we want to specify the RFC5226 policy?  is it Expert
  Review?  not Specification required?

     "Specification: An optional reference to a specification that
      defines in the error code in more detail."

- section 8: there's an extra space in my name: "Kevin J.  Ma" -> "Kevin J. Ma"

- section 9.1: There is a normative reference to the informational Framework draft.  Does this need to be normative?  If so, why?  Note: It is informative in the other interface specifications.

- section 9.2: the (missing) reference to RFC7736 should be informative

> -----Original Message-----
> From: CDNi [mailto:[e-mail]] On Behalf Of Ben Niven-Jenkins
> Sent: Tuesday, January 05, 2016 5:14 AM
> To: Content Delivery Networks Interconnection Discussion List
> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-redirection-14.txt
> 
> Colleagues,
> 
> This version uses Jon’s text covering DNSSEC etc and fixes a typo Rob
> spotted.
> 
> Ben
> 
> > On 4 Jan 2016, at 18:56, [e-mail] wrote:
> >
> >
> > 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-14.txt
> > 	Pages           : 30
> > 	Date            : 2016-01-04
> >
> > Abstract:
> >   The Request Routing Interface comprises of (1) the asynchronous
> >   advertisement of footprint and capabilities by a downstream Content
> >   Delivery Network (CDN) that allows an 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:
> > https://tools.ietf.org/html/draft-ietf-cdni-redirection-14
> >
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-redirection-14
> >
> >
> > 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/cdni
> 
> _______________________________________________
> CDNi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cdni