Re: Genart last call review of draft-ietf-httpbis-expect-ct-07

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@nokia.com>
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/
>
>
>
>
>
>
>