AD review of draft-ietf-httpbis-expect-ct-07

Hi,

The document is well written, but I have a short list of issues I would 
like to discuss:

2.1.  Response Header Field Syntax

    Expect-CT           = #expect-ct-directive
    expect-ct-directive = directive-name [ "=" directive-value ]
    directive-name      = token
    directive-value     = token / quoted-string

               Figure 1: Syntax of the Expect-CT header field

    Optional white space ("OWS") is used as defined in Section 3.2.3 of

I don't see "OWS" used above. Should it be used around the "=" character?

It looks like you've copied syntanx from RFC 6797, which used old HTTP 
ABNF with "implied *LWS" rule.
So you need to update it to explicitly insert OWS. (It is already a part 
of #expect-ct-directive construct though.)



2.1.1.  The report-uri Directive

The first mention of HSTS in Section2.1.1 needs a reference to [RFC6797].


    UAs SHOULD limit the rate at which they send reports.  For example,
    it is unnecessary to send the same report to the same "report-uri"
    more than once.

"More than once" in which period. Ever? I think you need to 
elaborate/clarify here.


In Section 3.1:

      *  The "serialized_sct" key, with a string value.  If the value of
          the "version" key is "1", the UA MUST set this value to the
          base64 encoded [RFC4648] serialized

Which base64 alphabet? There is one in section 4 and another one in 
section 5 of that RFC.

          "SignedCertificateTimestamp" structure from Section 3.2 of
          [RFC6962].  If the value of the "version" key is "2", the UA
          MUST set this value to the base64 encoded [RFC4648] serialized

As above.

          "TransItem" structure representing the SCT, as defined in
          Section 4.5 of [I-D.ietf-trans-rfc6962-bis].


6.1.  Header Field Registry

    This document registers the "Expect-CT" header field in the
    "Permanent Message Header Field Names" registry located at
    https://www.iana.org/assignments/message-headers [4].

    Header field name:  Expect-CT

    Applicable protocol:  http

    Status:  standard


As per 3864, I think this field has to have the value "experimental":

    Status:
       Specify "standard", "experimental", "informational", "historic",
       "obsoleted", or some other appropriate value according to the type
       and status of the primary document in which it is defined. For
       non-IETF specifications, those formally approved by other
       standards bodies should be labelled as "standard"; others may be
       "informational" or "deprecated" depending on the reason for
       registration.

Best Regards,

Alexey