[Trans] trans doc issues

[Stephen Kent <[e-mail]>]

Ben,

I agree that some aspects of CT operation are procedural matters that fall
outside the scope of what the IETF usually specifies when defining a 
protocol.
But, readers cannot evaluate the effectiveness of a proposed system (CT is
a system, not just a protocol) without a clear picture of what the system
designers envision wrt to operational issues. You might want to look at 
the suite
of RFCs published by the SIDR WG, defining the RPKI, as an example of 
how to address
the full range of issues associated with a big, complex system. Most of 
the RFCs are
standards track, but a few are informational; together they provide a 
fairly clear
picture of what is expected of each element of the system, and how the 
elements
are intended to work together. Topics such as key rollover were party of 
the initial
set of RFCs, as well as discussion of the expected frequency with which 
relying
parties would query repositories, etc.

I don't agree that specifying behavior for browsers is out of scope for this
WG. (Pardon me if I misunderstood part of your response.) To define the 
CT system
one needs to specify behavior for TLS servers, TLS clients,  Web PKI 
CAs, log operators,
monitors, and Auditors. The current doc does some of this, but there are 
a number of gaps.
If browser vendors are to play a major role in managing config info in 
support info
for CT, e.g, providing pointers to log and public key for logs, then 
this should be
stated explicitly.

I've just completed a detailed analysis of the CT I-D and will begin 
posting my comments,
questions, and suggested edits on Monday. No need to dump this on the 
list on a Friday :-).
The analysis is about 18 pages, so I'll break it into separate messages, 
each dealing with
a section of the I-D, plus a message offering overall comments.

Steve