Skip to main content

Last Call Review of draft-ietf-httpbis-replay-02

Request Review of draft-ietf-httpbis-replay
Requested revision No specific revision (document currently at 04)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2018-04-23
Requested 2018-04-09
Authors Martin Thomson , Mark Nottingham , Willy Tarreau
Draft last updated 2018-04-23
Completed reviews Genart Last Call review of -02 by Erik Kline (diff)
Secdir Last Call review of -02 by Magnus Nystrom (diff)
Genart Telechat review of -03 by Erik Kline (diff)
Assignment Reviewer Erik Kline
State Completed
Review review-ietf-httpbis-replay-02-genart-lc-kline-2018-04-23
Reviewed revision 02 (document currently at 04)
Result Ready with Nits
Completed 2018-04-23
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-replay-02
Reviewer: Erik Kline
Review Date: 2018-04-23
IETF LC End Date: 2018-04-23
IESG Telechat date: Not scheduled for a telechat


This draft is basically ready for publication, but has nits that should be
fixed before publication.  These nits are mostly about satisfying my ignorance.

Major issues:  None

Minor issues:  None

Nits/editorial comments:

[1] Some bibliography are to old versions (TLS1.3 links to v21, current is
v28).  I assume that’ll just "fix itself" before publication.  =)

[2] Section 3, paragraph 1: not just session cookie, but non-zero
max_early_data_size option? I couldn’t find explicit mention of
max_early_data_size = 0 in TLS13v28, so perhaps it can’t be sent?

[3] Section 3, paragraph LAST-1: “even if the server rejects the request” scans
awkwardly to me in the context of "requests" in the first half of the sentence.
“Even if the server ultimately rejects *one or more* of the requests by sending
a 425...”?  Perhaps I'm completely misreading something.

[4] Section 4, paragraph 4: after “or if the same server accepts early data
multiple times“ is there an implied “for the same session ticket” in the mind
of the expected reader?  Not sure if adding that is clarifying or redundant.

[5] Section 6.1: “SHOULD disable early data” refers to connections toward
servers (or next hops) or toward clients (or previous hops) or both?  (I’m
assuming the first, since doing so on a per-origin-server basis for incoming
requests as they arrived would require examining SNI, but perhaps that's
theoretically doable?)