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

Hi Adam,

Responses below.

> On 18 Dec 2018, at 2:03 pm, Adam Roach <adam@nostrum.com> wrote:
> 
> General:
> 
> SIP has a similar (albeit more rigorously-defined) loop detection model, which
> carefully distinguishes between unwanted loops and what SIP terms "spirals,"
> which are requests that (for valid operational reasons) traverse the same
> entity more than once. Is it possible that CDNs might have similarly
> intentional configurations that cause a request to traverse their network more
> than once? If so, it's probably worth discussing this somewhere in this
> document, so as to increase the chances that implementations have the
> functionality needed by CDN operators.

It is possible, but the CDN is in control of its own implementation by definition, so it can address its needs as it sees fit. 

The important part to standardise is the reservation of the semantics of the header and the prohibition of modifying it by customers -- not defining what to do when a loop is found (see also below).



> This mechanism implies a means for detecting loops, but gives no guidance for a
> uniform way of indicating that such a loop has occurred. I would have expected
> the document to either point to an existing 400- or 500-class response code, or
> define a new 400- or 500-class response code to indicate a loop-induced failure.
> (Compare with SIP's 482 response code).
> 
> Consider adding such guidance and/or a new code.

CDNs have different requirements and practices here; standardising them is premature. For example, in some situations a error response is desirable, whereas in others, using stale content or shortcutting to a different origin might be appropriate.

We might get to that some day, but for now, we're trying to define the minimum required to "win" here.



> Abstract:
> 
>> This specification defines the CDN-Loop request header field for
>> HTTP.
> 
> This description is too sparse to be a useful abstract. The technical summary
> from the document shepherd write-up would seem to be a reasonable bit of text
> to replace it with:
> 
>>  This simple document defines a new request header field for HTTP:
>>  CDN-Loop. CDN-Loop addresses an operational need that occurs when an
>>  HTTP request is intentionally forwarded between CDNs but then is
>>  accidentally re-routed back into the original CDN causing a non
>>  terminating loop. The new header field is used to identify the error
>>  and terminate the loop.

I think that's a good start; will incorporate with some modifications. 


> §2:
> 
>> header field to all requests they generate or forward (creating the
>> header if necessary).
> 
> Nit: "...creating the header field..."
> 
>> As with all HTTP headers defined using the "#" rule, the CDN-Loop
>> header can be added to by comma-separating values, or by creating a
> 
> Nit: "...HTTP header fields..."
> 
> Nit: " ...CDN-Loop header field..."

I'm looking forward to resolving <https://github.com/httpwg/http-core/issues/111>, but in the meantime, will do.


> §2:
> 
>> CDN-Loop: FooCDN, barcdn; host="foo123.bar.cdn"
> 
> While the "cdn" TLD is not yet allocated by ICANN, it remains available for a
> registry to apply for an be granted. Please use a hostname from a TLD or
> second-level domain allocated by RFC 2606.

Will do.

Thanks,


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

Received on Tuesday, 18 December 2018 03:22:04 UTC