Last Call Review of draft-ietf-httpbis-cdn-loop-01

Request Review of draft-ietf-httpbis-cdn-loop
Requested rev. no specific revision (document currently at 02)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2018-12-11
Requested 2018-11-27
Authors Stephen Ludin, Mark Nottingham, Nick Sullivan
Draft last updated 2018-12-03
Completed reviews Secdir Last Call review of -01 by Donald Eastlake (diff)
Genart Last Call review of -01 by Joel Halpern (diff)
Tsvart Last Call review of -01 by Colin Perkins (diff)
Assignment Reviewer Joel Halpern
State Completed
Review review-ietf-httpbis-cdn-loop-01-genart-lc-halpern-2018-12-03
Reviewed rev. 01 (document currently at 02)
Review result Ready with Issues
Review completed: 2018-12-03


I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at


Document: draft-ietf-httpbis-cdn-loop-01
Reviewer: Joel Halpern
Review Date: 2018-12-03
IETF LC End Date: 2018-12-11
IESG Telechat date: Not scheduled for a telechat

Summary: This document is ready for publication as a Proposed Standard RFC
                    There are two issues that I think should be addressed before publication

Major issues: N/A

Minor issues:
    This depends upon CDNs which have not been upgraded not stripping this header.  While I can believe that is a reasonable assumption, it seems that a paragraph explaining that it is the case, and if possible what experience leads us to think it is the case, would be helpful.

    This document says that it is to protect against attackers causing loops.  If the attacker is an external customer, the advice in the security considerations section makes sense.  The other apparent attack would be an attacker in the network who strips the information each time it comes past.  I believe the reason this is only an apparent attack is that such an attacker could almost as easily simply generate additional messages instead of producing a loop.  If I have inferred this correctly, it seems useful to state it.

Nits/editorial comments:  N/A