Request Routing Redirection Interface for Content Delivery Network (CDN) Interconnection
Note: This ballot was opened for revision 17 and is now closed.
(Barry Leiba) Yes
Alexey Melnikov Yes
(Jari Arkko) No Objection
Alia Atlas No Objection
Deborah Brungard No Objection
Ben Campbell No Objection
Comment (2016-03-15 for -17)
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.
Alissa Cooper (was Discuss) No Objection
Comment (2016-04-26 for -18)
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.
Spencer Dawkins No Objection
(Stephen Farrell) (was Discuss) No Objection
Comment (2016-07-26 for -19)
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.