Request Routing Redirection Interface for Content Delivery Network (CDN) Interconnection
RFC 7975

Thanks for explaining the parts I didn't get and addressing the rest of my DISCUSS.

I do still think the CGN example in 5.2 is not clear as written -- probably needs further explanation or removal as Ben suggested.

I have a few comments and questions:

# Substantive: #

- 3, last paragraph: "Any operational
   mechanisms this requires, e.g., private key distribution to
   surrogates and request routers in dCDNs, are outside the scope of
   this document.  Further mechanisms to notify User Agents of trusted
   redirection are also outside the scope of this document."

Is it in scope _somewhere_? As it is, this seems like an excuse to avoid HTTPS, which is not optimal.

-4, first paragraph:
Was any thought given to using or supporting HTTP/2?

-- step 1 after figure 1:
I am I correct to infer an assumption that CDN A acts as the UAs DNS server? Is that assumption documented somewhere?

- 4.2, last paragraph (note)
This explicitly makes an IPv6 only CDN non-compliant. Is that the intent?

- 4.4.1, table, entry for dns-only:
The description says "MUST include RTs". That doesn't seem to consider error cases. 

- 4.8, 3rd and 4th paragraph:
I'm curious why they SHOULDs are not MUSTs. Are there times it might be reasonable to do something different; maybe even choosing not to send an error at all? I wonder if these should be of the form of "MUST send an error which SHOULD be XXX"

-5.1, 2nd to last paragraph:
" In an environment where any such protection is required...," is a pretty weak recommendation. Would you consider making the default behavior secure? Or at least saying something to the effect of "Except in networks where similar protections are provided by some other means,..."?

-5.2, First paragraph:
I have trouble imagining situations where information passed over the RI might not be sensitive.
-- third paragraph:
I wish the text wasn't so dismissive of attempts to anonymize some RI request data. I agree doing so may reduce RI effectiveness in some cases. But that needs to be balanced with privacy needs, and that balance may not always land on the side of RI effectiveness. And  the inability to correlate UAs between requests can be a feature in some circumstances. 

# Editorial: #

- General:
There's quite a bit of repetition and redundant text, including redundant normative text.

- abstract: 
s/"The Request Routing Interface..."/ "The Content Delivery Network Interface (CDNI) Request Routing Interface..."
s/"comprises of"/"comprises"

- 4, 2nd paragraph: "The same HTTP interface is used for both DNS and HTTP redirection of
User Agent requests,..."
From the rest of the sentence, I assume this means the RI uses the same interface to communicate information about DNS and HTTP redirects—but the first part sounds like it is saying that the actual redirection (i.e. interacting with the UA) occurs over the same interface.

-- 4th paragraph:
s/"try and"/"try to"

- 4.1, 2nd to last paragraph: "... signaled the HTTP response body
      of the RI response ..."
Missing word? (perhaps "... signaled in the HTTP response body ..."

-4.2, paragraph 4:
This paragraph is redundant to section 4.8.

-4.5.1, last paragraph before example: "For example, it MAY only
   send the contents of the first occurrence of the HTTP Headers
   instead."
s/MAY/might.

Thanks for handling my discuss point. I didn't check the comments
below but am happy to chat about them if needed.

----- OLD COMMENTS BELOW


- I support Alissa's discuss points.

- section 3: false-negative? don't you mean false-positive?
And in any case, those warnings are not false from the browser
perspective. I'd suggest s/false-negative//

- section 3: phrases like "trusted re-direction" are a bad
idea - you need to say who is trusting whom for what for this
to be meaningful and not misleading (people get misled by such
phrases all the time). I'd just delete the sentence or
s/trusted//

- 4.4.2: a JSON "string" is not the same as a DNS name is it?
What about i18n? (ULABEL or ALABEL?) what about odd characters
allowed in JSON but not in DNS names?  In general the fields
in this dictionary (and others) seem underspecified to me.