Last Call Review of draft-ietf-httpbis-expect-ct-07
review-ietf-httpbis-expect-ct-07-opsdir-lc-wu-2018-08-07-00

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?