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

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.

Received on Tuesday, 18 December 2018 03:03:33 UTC