Melinda,
On 1/15/16 4:27 AM, Karen Seo wrote:
There are a number of issues (for the non-log components) that WG
members have asked be addressed that the existing 6962-bis text doesn't
cover.
It's becoming extremely difficult to gauge consensus because
we're getting so few comments on these proposals, and I
think we're getting so few comments because it probably seems
to many participants that we (the working group) are being
pecked to death by ducks. I'm particularly concerned that
we're being asked to do work that is technically correct but
unlikely to be actually helpful to implementers (who, it
should be pointed out, have implementations underway without
these documents).
I am generally skeptical of the value of non-specification
documents, particularly given that we're living in a time
where working group charter proposals are getting scrupulous,
detailed review. My actual concern, however, is that this is
precisely the sort of thing that is slowing down the production
of implementable specifications and causing palpable harm to the
IETF and to individual working groups.
Not sure to which documents you are referring in the paragraphs above.
The threat analysis is not a requirements spec, but it is an
already-accepted
WG doc and I will post changes to it base on the feedback from Rich and
Eran.
The architecture doc also is not a requirements spec and it has not been
adopted by
the WG. However, the comments from Rich and Eran were mostly very
positive and a new
version of it also will be posted next week, with changes based on their
comments.
The three docs that Karen, David, and I wrote and posted at the end of
last year are
requirements specification docs, addressing the CT system elements that
we feel are not
well-addressed in 6962-bis. They are companions to the architecture doc.
We have provided
specific, suggested edits for 6962-bis so that its discussions of
non-log components
do not use requirements language, leaving that to the three docs that we
posted. We have
yet to receive comments on these docs; Eran, at the end of his comments
on the architecture
doc even asked what was preventing us from writing them!
Finally, in response to your query about who is implementing what: BBN
has explored
design aspects of the Monitor and Auditor functions, as well as browser
behavior.
In my role as a member of the technical advisory board for Let's Encrypt
I have
discussed these CT system element design issues with some of the Let's
Encrypt folks.
They are planning to implement Monitor and Auditor functions. The
Mozilla folks
with whom I communicate are interested in the browser behavior topics
that we have
described in our browser/browser-vendor spec.
Steve
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
