Last Call Review of draft-ietf-httpbis-expect-ct-07

Request Review of draft-ietf-httpbis-expect-ct
Requested rev. no specific revision (document currently at 08)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2018-08-14
Requested 2018-07-31
Draft last updated 2018-08-08
Completed reviews Opsdir Last Call review of -07 by Qin Wu (diff)
Genart Last Call review of -07 by Vijay Gurbani (diff)
Secdir Last Call review of -07 by Adam Montville (diff)
Assignment Reviewer Vijay Gurbani
State Completed
Review review-ietf-httpbis-expect-ct-07-genart-lc-gurbani-2018-08-08
Reviewed rev. 07 (document currently at 08)
Review result Ready with Nits
Review completed: 2018-08-08


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-expect-ct-??
Reviewer: Vijay K. Gurbani
Review Date: 2018-08-08
IETF LC End Date: 2018-08-14
IESG Telechat date: Not scheduled for a telechat

Summary: Ready with nits.

Major issues: 0

Minor issues: 4

Nits/editorial comments: 3

1/ S1, s/future/subsequent/

2/ S2.1, list item 4: "UAs must not attempt to fix" --> any reason "must not"
 is not normative?  (Okay to leave it like this, I am just curious as to
 why not simply make it normative.)

3/ S2.3.2.1: Why the qualification "error-free TLS conection"?  Does that
 imply that other TLS connections are error-prone?  I suspect that the
 "error-free" qualifier to the "TLS connection" has to do with the
 validation in S2.4 (as indicated by the text in brackets).  If so, then
 perhaps this is better stated as "Upon receipt of the Expect-CT response
 header field over a TLS connection validated as described in Section 2.4,
 the UA ..."

4/ S7: Does it make sense to enumerate one or more means on how UAs
 should explain the reason?  A specific HTTP header?  JSON body?  May
 help doing so for the sake of being explicit while designing protocols,
 and perhaps it can help interoperability.

1/ Abstract: either one of the following substitutions will work better:
 s/header field, named Expect-CT, that/header field named Expect-CT, which/
 s/header field, named Expect-CT, that/header field, Expect-CT, which/

 (There are other examples like this that should be edited.
 Another one appears in S2.3.2: "If the UA receives, over a secure transport,
 an HTTP response that includes ..." => this can be better worded as "If
 the UA receives an HTTP response over a secure transport that includes ...")

2/ S2.1: list item 4: s/value data, that/value data that/

3/ S4: s/could themselves only cure/can mitigate/