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 Ops Directorate (opsdir)
Deadline 2018-08-14
Requested 2018-07-31
Draft last updated 2018-08-07
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 Qin Wu
State Completed
Review review-ietf-httpbis-expect-ct-07-opsdir-lc-wu-2018-08-07
Reviewed rev. 07 (document currently at 08)
Review result Ready
Review completed: 2018-08-07


I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments.

This document defines"Expect-CT" response header field. It can be used by server to indicate that UAs should evaluate connections to the host emitting the header field for CT compliance. I believe this document is ready for publication. However I have a few comments which I like authors of this document can consider:
1.Section 1, Introduction,3 paragraph said:
"Web host operators are
   advised to deploy Expect-CT with caution, by using the reporting
   feature and gradually increasing the interval where the UA remembers
   the host as a Known Expect-CT Host.
To consistent with the next sentence in paragraph 3, s/caution/precautions
I believe this interval is related to max-age, if the answer is yes, I would suggest to change interval into waiting time or hold on time, in addition, change remembers into regards

2.Section 2.1 Expected-CT field syntax
Not sure Response header field name should use upper case.

3.Section 2.1.2 said:
"When both the "enforce" directive and "report-uri" directive
   (as defined in Figure 2) are present, the configuration is referred
   to as an "enforce-and-report" configuration"

Section 3, failure-mode said:
   o  "failure-mode": the value indicates whether the Expect-CT report
      was triggered by an Expect-CT policy in enforce or report-only
      mode.  The value is provided as a string.  The UA MUST set this
      value to "enforce" if the Expect-CT metadata indicates an
      "enforce" configuration, and "report-only" otherwise.
I am wondering how these two quoted text related to each other? Why failure-mode doesn't support enforce-and-report mode?
4.Section 3.1
s/reporting server/report server
5.Section 4.1
Section 4.1 said UA experience denials of service.
Section 7 said:
7.  Usability Considerations

   When the UA detects a Known Expect-CT Host in violation of the UA's
   CT Policy, users will experience denials of service.  It is advisable
   for UAs to explain the reason why.

Section 5 last paragraph said:
"Because Expect-CT causes remotely-detectable behavior, it's advisable
   that UAs offer a way for privacy-sensitive users to clear currently
   noted Expect-CT hosts, and allow users to query the current state of
   Known Expect-CT Hosts.
I am wondering who experience denials of service, who are users referred in section 7? Expect-CT hosts or report server?
Who are privacy-sensitive users in section 5? UA? From where can the user query the current state of Known Expect-CT Hosts? Report server or Server? Does this document define mechanism which allow user to get access to the current state of known expected-ct hosts?

6. Section 7 said:
It is advisable for UAs to explain the reason why.
Explain the reason why to who? Web client or webserver? If it is the latter,Isn’t violation report defined in section 3.2 and 3.3 doing this job? If it is former,does this introduce security risk?