Thanks for the comments! I've addressed these in https://github.com/httpwg/http-extensions/commit/98ba23ab8c7435f46f5e677cbea54cc215e07d24 (with some replies inline).
On Fri, Aug 31, 2018 at 8:53 AM Vijay Gurbani <vijay.gurbani@xxxxxxxxx> wrote:
Review result: Ready with Nits
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
<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
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
Minor:
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.)
This was already fixed in a previous editor's draft.
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 ..."
"Error-free" here is meant to refer to RFC 5280 certificate chain validation as well as any other validation that UAs apply to TLS connections, in addition to the validation described in Section 2.4. I've added a parenthetical to clarify that.
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.
This is meant to be end-user-facing, e.g. a certificate error page in a web browser, which I've tried to clarify in the text.
Nits:
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/
