Public Notary Transparency
charter-ietf-trans-01

Thanks for addressing my Blocking concern and the second of my Comments. I leave the unaddressed comment here in case it worries you that your current text is ambiguous and causes chuckles ("hashes of more-or-less anything that is structured in such a way as to provide...")

Would be nice to clean up the long sentences to avoid run-on subordinate
clauses that are ambiguous. Thus...
OLD
A
cryptographically verifiable log is an append-only log of hashes of more-or-less
anything that  is structured in such a way as to provide efficiently-accessible,
cryptographically-supported evidence of correct log behaviour.
NEW
A
cryptographically verifiable log is an append-only log of hashes of more-or-less
anything.  The log is structured in such a way as to provide efficiently-accessible,
cryptographically-supported evidence of correct log behaviour.
END

Here's my official comment about the name: "Transparency" won't do it.  Don't bikeshed on it, but come up with something better.

For some reason, I think the background motivation (mapping) and the main work item (cryptographic logs). Maybe I'm just slow today or it is too late, but I would have been happy with the explanation of cryptographic logs and that the working group is going to work on them. And I agree about the name with other ADs.

This at least clarifies it to the point that I understand what they intend to do. I still think it's a shame that they won't be able to work on generic CT for TLS (as against CT for HTTPS) without a re-charter, but that's between the proponents and Stephen.

COMMENT 1: 
It's important for this charter to be very clear about what logs do and do not do.  They do not correct errors; they only make them visible.  Then you use other things (e.g., cert revocation) to correct the errors.

OLD: "Cryptographically verifiable logs can help to ameliorate these
problems by making it possible to discover and rectify errors before
they can cause harm."
NEW: "Cryptographically verifiable logs can help to ameliorate these
problems by making it possible to discover errors quickly, so that other
mechanisms can be applied to rectify them."


COMMENT 2:
The paragraph starting "These logs can potentially also..." seems speculative and not especially helpful here.


COMMENT 3:
BLOCK 1:
The first deliverable seems to conflate a few things:
  1. How certs get into the logs
  2. How relying parties get information from the logs
  3. How relying parties use information from the logs in validation
The third of these seems quite different from the first two.  For example, the DANE considerations only apply to (3).  Would it be useful to disaggregate these into say two deliverables?  One for log operators (1/2), and one for clients (2/3)?

I agree with Barry's suggestion to change the fabulously vague name, and it looks like that's been accepted, modulo an actual suggestion that works :-)

Thanks for addressing my concern