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

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

Hi Ben,
  Looks good.  thanx!

  wrt the registry:

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

  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:[e-mail]] 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,

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

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


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

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"

Changed to using ‘Redirection interface’ throughout.


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

Done.

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

Done.


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

Done


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

Done.


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

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?


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

Done.


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

Good catch. Done.


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

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.

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

Done.


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

Done.


- section 4.8: suggested edit:

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

Done.


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

Done.


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

Done.


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

Done.


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

Done.


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

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.


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

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


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

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