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

[Ben Niven-Jenkins <[e-mail]>]

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