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

From: Kevin Ma J <[email-masked]>
Date: Wed, 13 Jan 2016 23:16:51 +0000

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:[email-masked]] 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, [email-masked] 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
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/cdni
> 
> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Wed, 27 Jan 2016 19:43:21 +0000

Kevin,

I’ve made most of the changes you suggested, comments/what I’ve done are below.

I’ve pushed -15 with the changes, diff to -14 is here:

https://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-redirection-15 <https://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-redirection-15>

Let me know if there are any other changes you want to the document.

> On 13 Jan 2016, at 23:16, Kevin Ma J <[email-masked]> wrote:
> 
> Hi Ben/Ray,
> 
> - 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"

Changed to using ‘Redirection interface’ throughout.

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

Done.

>      delivery to another CDN); or”

Done.

>   Request Redirection.”

Done

>   redirection look like a DNS-based attack”

Done.

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

I changed the sentence to:

Finally, the RI is easily extendable to support other User Agent request redirection methods (e.g., RTMP 302 redirection) by defining additional protocol specific keys for RI requests and responses along with a specification how to process them.

to try and expand a bit on how extensions could be done. I don’t think it’s the role of this document to specify exactly what is required, e.g. mandating an RFC. If you think it needs more explanation on how to extend it I can look at crafting some more detailed text?

>      included in the RI request.”

Done.

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

Good catch. Done.

>   aaaa, cname.”

Done. I integrated it into the existing sentence about including one of a, aaaa, came so it now reads:

If a dns dictionary is included in the RI response, it MUST include the rcode and name keys and it MUST include at least one of the following keys: a, aaaa, came.

>   status, sc-version, sc-reason, cs-uri, and sc-(location).”

Done.

>   in cdn-path.”

Done.

>  "Beside loops within the RI itself,”

Done.

>   directly to a surrogate in the final dCDN, there is the possibility”

Done.

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

Done.

>      confidentiality; and”

Done.

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

Done.

>  “Parts"

I think the repetition is OK and provides a refresh of the context. As privacy is likely to be a topic folks nit pick at during IETF LC/IESG review I’d rather be cautious and repeat myself and leave it to the RFC editor to tweak for readability.

>   and requested URIs that they wouldn't have, had the RI not been used.”

Done.

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

I don’t think so. What we’re defining a registry for is a set of numeric response codes & their meanings for returning in a RI (error) response. It is not obvious to me how that registry is related to the CDNI parameters registry (assuming by CDNI Parameters registry you mean the Media Type parameter registry).

>      defines in the error code in more detail.”

I made it Specification Required, added a normative reference to RFC5226 and tweaked the existing wording to be inline with RFC7736. it now reads:

“”"
This document establishes a new IANA registry for CDNI RI Error response codes.  Additions to the "RI Error response registry” will be made via "Specification Required" as defined in [RFC5226].

The Designated Expert will verify that new error code registrations do not duplicate existing error code definitions (in name or functionality), ensure that the new error code is in accordance with the error classes defined in section Section 4.7 of this document, prevent gratuitous additions to the namespace, and prevent any additions to the namespace that would impair the interoperability of CDNI implementations.
“””

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

Wow you have eagle eyes :-) It seems xml2rfc mistakes the “.” for a full stop (period) and automatically starts every sentence with 2 spaces. I’ve changed it to “Kevin J Ma” to avoid the double space but can change it back it you prefer it with the full stop (period).

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

Changed to informative.

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

Added.

Ben

---

From: Kevin Ma J <[email-masked]>
Date: Wed, 27 Jan 2016 20:21:53 +0000

Hi Ben,
  Looks good.  thanx!

  > I don’t think so. What we’re defining a registry for is a set of numeric response codes & their meanings for returning in a RI (error) response. It is not obvious to me how that registry is relat…

  I think the CDNI Parameters "registry" is just the grouping for all CDNI related registries, and the CDNI Payload Types (the media type parameter registry) is underneath that (see the "Content Delivery Network Interconnection (CDNI) Parameters" heading at https://www.iana.org/protocols).  I didn't have anything originally in the media type draft, and then was asked to add text in which I referred to it as a "category", but the editors changed it to the "subregistry" text above.  I assume we need that text, so that all the CDNI registries are in one place; else we'll likely get asked about it in IESG review.

  Other than that, I think we're ready to go.

thanx!

--  Kevin J. Ma

From: CDNi [mailto:[email-masked]] On Behalf Of Ben Niven-Jenkins
Sent: Wednesday, January 27, 2016 2:43 PM
To: Content Delivery Networks Interconnection Discussion List
Subject: Re: [CDNi] Shepherd Review of draft-ietf-cdni-redirection-14.txt

Kevin,

https://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-redirection-15

On 13 Jan 2016, at 23:16, Kevin Ma J <[email-masked]<mailto:[email-masked]>> wrote:

Hi Ben/Ray,

thanx!

--  Kevin J. Ma

Done.

Done.

Done

Done.

Done.

Good catch. Done.

Done.

Done.

Done.

 "for example if the IP

Done.

Done.

Done.

Done.

Done.

“”"

Changed to informative.

Added.

Ben

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 28 Jan 2016 12:06:31 +0000

Hi Kevin,

OK. I just pushed -16 which uses similar text to RFC7736, the complete section on RI error response registry now reads:

6.2.  RI Error response registry

   IANA is requested to create a new "CDNI RI Error response code"
   subregistry within the "Content Delivery Network Interconnection
   (CDNI) Parameters" registry.  The "CDNI RI Error response code"
   namespace defines the valid values for the error-code key in RI error
   responses.  The CDNI RI Error response code MUST be a three digit
   integer.

   Additions to the "RI Error response registry" will be made via
   "Specification Required" as defined in [RFC5226].

   The Designated Expert will verify that new error code registrations
   do not duplicate existing error code definitions (in name or
   functionality), ensure that the new error code is in accordance with
   the error classes defined in section Section 4.7 of this document,
   prevent gratuitous additions to the namespace, and prevent any
   additions to the namespace that would impair the interoperability of
   CDNI implementations.

   New registrations are required to provide the following information:

      Code: A three-digit numeric error-code, in accordance with the
      error classes defined in section Section 4.7 of this document.

      Reason: A string that provides further information related to the
      error that will be included in the JSON error dictionary with the
      'reason'-key.  Depending on the error-code semantics, the value of
      this field may be determined dynamically.  In that case, the
      registration should set this value to '<reason>' and define its
      semantics in the description field.

      Description: A brief description of the error code semantics.

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

   The entries in Table 1 are registered by this document.

Regards
Ben

> On 27 Jan 2016, at 20:21, Kevin Ma J <[email-masked]> wrote:
> 
> Hi Ben,
>   Looks good.  thanx!
>  
>   wrt the registry:
>  
>   I think the CDNI Parameters "registry" is just the grouping for all CDNI related registries, and the CDNI Payload Types (the media type parameter registry) is underneath that (see the "Content Delivery Network Interconnection (CDNI) Parameters" heading athttps://www.iana.org/protocols <https://www.iana.org/protocols>).  I didn't have anything originally in the media type draft, and then was asked to add text in which I referred to it as a "category", but the editors changed it to the "subregistry" text above.  I assume we need that text, so that all the CDNI registries are in one place; else we'll likely get asked about it in IESG review.
>  
> On 13 Jan 2016, at 23:16, Kevin Ma J <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hi Ben/Ray,
>

---

From: Kevin Ma J <[email-masked]>
Date: Thu, 28 Jan 2016 15:00:07 +0000

Hi Ben,

  Looks good.  thanx!

  I've submitted the shepherd writeup.  Thanks to all who've contributed over the years.  Congrats!

--  Kevin J. Ma

From: Ben Niven-Jenkins [mailto:[email-masked]]
Sent: Thursday, January 28, 2016 7:07 AM
To: Kevin Ma J
Cc: Content Delivery Networks Interconnection Discussion List
Subject: Re: [CDNi] Shepherd Review of draft-ietf-cdni-redirection-14.txt

Hi Kevin,

Regards
Ben

On 27 Jan 2016, at 20:21, Kevin Ma J <[email-masked]<mailto:[email-masked]>> wrote:

Hi Ben,
  Looks good.  thanx!

  > I don’t think so. What we’re defining a registry for is a set of numeric response codes & their meanings for returning in a RI (error) response. It is not obvious to me how that registry is relat…

  I think the CDNI Parameters "registry" is just the grouping for all CDNI related registries, and the CDNI Payload Types (the media type parameter registry) is underneath that (see the "Content Delivery Network Interconnection (CDNI) Parameters" heading athttps://www.iana.org/protocols).  I didn't have anything originally in the media type draft, and then was asked to add text in which I referred to it as a "category", but the editors changed it to the "subregistry" text above.  I assume we need that text, so that all the CDNI registries are in one place; else we'll likely get asked about it in IESG review.

thanx!

--  Kevin J. Ma

Kevin,

Hi Ben/Ray,

thanx!

--  Kevin J. Ma

Done.

Done.

Done

Done.

Done.

Good catch. Done.

Done.

Done.

Done.

 "for example if the IP

Done.

Done.

Done.

Done.

Done.

“”"

Changed to informative.

Added.

Ben