Subject: [dane] DANE protocol spec complete rewrite

From: Zack Weinberg <[email-masked]>
Date: Fri, 4 Nov 2011 21:21:17 -0700

With the WG face-to-face meeting next Monday (alas, I cannot attend),
now seemed like a good time to finish and post that complete spec
rewrite that I've been threatening to do for months :)  Despite the
radical changes to the document, it is not my intention to take over
the editor's hat from the present team, merely to offer improvements.

I have tried not to make any normative changes, except where draft 12
was ambiguous.  One notable exception to that is the code numbers in
the RR, which have been rationalized.  Where I consciously made
normative changes, I indicated them with [[comments in double square
brackets]]; these also indicate spots where there are remaining
ambiguities or omissions that I either don't know enough about to
produce text, or do not feel it is appropriate for me to resolve
unilaterally. All open issues except #10, #35, and #38 are at least
mentioned in these annotations, and most of them have suggested
resolutions.

Editorially, however, I have changed everything from the terminology
on up.  My principal goal was clarity, particularly relating to how
the client is supposed to behave.  To that end, I have replaced the
non-normative pseudocode Appendix B with a normative section 3 that
states a prose algorithm which clients must match in results, although
not in implementation.  Given the well-known ambiguities and
controversies surrounding the interpretation of PKIX, I have also
removed as many dependencies on that spec as possible, even in
terminology.  Appendix A has been cut down a bit and moved into the
main body of the document.  Finally, I added some items to the various
"considerations" sections on my own motion, and a new "usage
scenarios" section.

Since I have not been able to find the (presumed) xml2rfc source of
draft 12 anywhere, I did not preserve all of the formatting
(particularly not the page headers and footers), the IESG boilerplate,
or the bibliography.  If the present editors of the document are
willing to provide me with the source, I will happily do the legwork
to finish out the draft.

zw

---

From: Richard Barnes <[email-masked]>
Date: Sun, 6 Nov 2011 22:18:48 -0500

I have reviewed this document, and would not recommend that it serve as the basis for further working group documents.  It is much less clearly written than the current document, in large part due to sloppy use of terminology.  

That said, there are some useful things in here.  This document makes the algorithm for evaluating a certificate in the context of TLSA records much more explicit, and the usage examples could be helpful to people.

Rather than submitting a bunch of changes all at once like this, it would be much more helpful to work with the editors on the specific changes you think need to be made.  For instance, I would support efforts to make the processing/decision algorithm more explicit and to incorporate some usage examples.

--Richard

On Nov 5, 2011, at 5:21 AM, Zack Weinberg wrote:

> <draft-ietf-dane-protocol-12+zw.txt>_______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

---

From: Zack Weinberg <[email-masked]>
Date: Sun, 6 Nov 2011 20:10:29 -0800

> I have reviewed this document, and would not recommend that it serve as the basis for further working group documents.  It is much less clearly written than the current document, in large part due…

A primary goal of the rewrite was to make the terminology much more
precise than the present draft; therefore, I would appreciate an
explanation of exactly what you find to be "sloppier" than the status
quo.  Note that I deliberately avoided terminology which people
*think* has a precise meaning, but that meaning is contested among two
or more usage groups, so it's not actually unambiguous; instead I used
terminology that I made up, so that it would mean exactly what I
wanted it to mean.  Perhaps that is what you do not like?
Unfortunately, under the circumstances, I don't think we have a
choice.

> Rather than submitting a bunch of changes all at once like this, it would be much more helpful to work with the editors on the specific changes you think need to be made.  For instance, I would sup…

I do not think it is practical to make some of the changes that I want
made without a wholesale rewrite, and this particularly goes for
terminology.  I cannot support the present draft's terminology; it is
asking for incompatible implementations.

zw

---

From: Zack Weinberg <[email-masked]>
Date: Tue, 8 Nov 2011 20:34:36 -0800

On reflection, this message was too crabby.  I apologize.  Please
allow me to try to rephrase the sentiment:

I intended to produce a document that was more clearly written than
the current draft, and obviously _I_ think I succeeded, otherwise I
would not have posted it.  That you think it is _less_ clearly written
is a disappointment, but I would like to know in more detail what you
think is wrong with the revision, so I can try to make it an
improvement in everyone's eyes.

zw