Last Call Review of draft-ietf-trans-rfc6962-bis-31
review-ietf-trans-rfc6962-bis-31-tsvart-lc-iyengar-2019-03-13-00

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-art@ietf.org if you reply to or forward this review.

This document is very clearly written and explains the goals of Certificate
Transparency, the mechanisms by which the goals are accomplished, and details
for implementing various CT components.

My comments below are perhaps worth addressing in the draft, but they aren't
critical.

1/ Section 4 discusses log format and operation, but it is predominantly about
format.  Section 4.13 is entirely an operational consideration, and it sticks
out a bit. It left me thinking if it made sense to separate it out into an "Log
Operational Considerations" section. It might be an overkill to have a separate
section, but see below for more.

2/ Are there other operational considerations worth talking about?  Are there,
for instance, DoS vectors that a Log operator needs to be aware of that might
be specific to running a Log?

3/ How many logs should a submitter submit a newly issued certificate to? What
are the considerations here? I did not see any recommendations for submitters.
Is this worth discussing in the document?

4/ I was wondering what might happen if cert lifetimes were too small. What are
the consequences? Is there value in discussing this?