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

From: Adam Roach <[email-masked]>
Date: Mon, 17 Dec 2018 19:03:01 -0800

Adam Roach has entered the following ballot position for
draft-ietf-httpbis-cdn-loop-01: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-httpbis-cdn-loop/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks to everyone who worked on this document. In general it looks good,
although I have a handful of suggestions that the authors may wish to
consider.

---------------------------------------------------------------------------

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.

---------------------------------------------------------------------------

General:

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.

---------------------------------------------------------------------------

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.

---------------------------------------------------------------------------

§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..."

---------------------------------------------------------------------------

§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.

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 18 Dec 2018 14:21:33 +1100

Hi Adam,

Responses below.

> On 18 Dec 2018, at 2:03 pm, Adam Roach <[email-masked]> wrote:
> 
> General:
> 

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).

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

>>  terminating loop. The new header field is used to identify the error

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

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

> second-level domain allocated by RFC 2606.

Will do.

Thanks,

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