Re: Ben Campbell's No Objection on draft-ietf-httpbis-cdn-loop-01: (with COMMENT)

[Mark Nottingham <[e-mail]>]

Hi Ben,

> On 20 Dec 2018, at 10:58 am, Ben Campbell <[e-mail]> wrote:
> 
> *** Substantive Comments ***
> 
> I agree with Alissa's comments, and Adam's comments about configurations that
> intentionally cross a CDN more than once.
> 
> - abstract: The abstract could use some more meat. What does the new header
> accomplish?

I think these are all addressed now.

> §2:
> -- first paragraph: Seems like this header helps "detect" loops, rather than
> "prevent" them.

Good point. I've changed "prevent" to "detect" throughout -- including in the document title.

> -- last paragraph: "To be effective, intermediaries - including
> Content Delivery Networks - MUST NOT remove this header field,"
> 
> Does that put normative requirements on things that do not implement the spec?

That's a good question. If this is an issue, I think we could address it by either updating RFC7231, or removing the requirement and making this prose.

Do people have a preference there?


> §3, first paragraph: How can CDNs stop their customer from modifying the header?

That depends on what capabilities that they offer to their customers; if they allow customers to configure a header modification, they'll need to make an exception for this header field name. Doing so is common; e.g., most CDNs don't allow you to modify headers like Connection or Content-Length, because doing so would break HTTP.

> ** Editorial Comments ***
> 
> §1,
> -- 4th paragraph: "loops between multiple CDNs be used as an
> attack vector" Missing word(s) around "CDNs be"?

Fixed, thanks.

> -- last paragraph: The last sentence os convoluted. Can it be broken into
> simpler sentences?

I've rewritten to:

"""
This specification defines the CDN-Loop HTTP request header field to help prevent such attacks and accidents among implementing forwarding CDNs, by disallowing its modification by their customers.
"""

Cheers,


--
Mark Nottingham   https://www.mnot.net/