Subject: [dane] WGLC reminder.

From: Warren Kumari <[email-masked]>
Date: Tue, 21 Feb 2012 19:53:52 -0500

Hi there all,

Firstly, thank you very much for all of your feedback, input and discussions -- Last Call certainly has a way of stimulating discussions :-)

We will be going through all of the mail in the next few days and trying to determine consensus on the threads -- something that would certainly make our lives much simpler is if folk who feel that their issues have been addressed / a compromise has been reached would *clearly* state so.

Again, thank you all for your assistance,
W

--
Don't be impressed with unintelligible stuff said condescendingly.
    -- Radia Perlman.

---

From: "Marco Davids (SIDN)" <[email-masked]>
Date: Wed, 22 Feb 2012 09:59:33 +0100

On 02/22/12 01:53, Warren Kumari wrote:
> something that would certainly make our lives much simpler is if folk who feel that their issues have been addressed / a compromise has been reached would *clearly* state so.

I hereby state that.
(is that proper English?)

--
Marco

---

From: John Gilmore <[email-masked]>
Date: Wed, 22 Feb 2012 23:48:41 -0800

> something that would certainly make our lives much simpler is if
> folk who feel that their issues have been addressed / a compromise
> has been reached would *clearly* state so.

I found many nits, and many other issues, in dane-protocol-16.  Some
nits have clearly been recognized for correction.  Other issues I
raised have provoked more discussion.  Some have provoked no
discussion at all.  I'd like to see a -17 before determining whether
my issues have been addressed.

I should also note for the record that I gave up on raising more
issues at a certain point in the discussion.  When it became clear to
me that the editors were objecting to making substantial changes to
the document (where "substantial" refers to things like inserting
four or five short paragraphs of text already written by someone
else), I narrowed my subsequent email contributions to merely the
kinds of nits that not even a recalcitrant editor could ignore; and to
the kind of major issues that I felt were fundamental to the document
(like how the various usage types affect the TLS protocol).

The idea that the document should be comprehensible to system
administrators deploying TLSA records in their own domains, rather
than just programmers implementing them in software, was also
apparently rejected, with the suggestion that a second, unofficial
document should be written by someone else (perhaps me) instead of
inserting context or clarifying the prose in the official document.

The suggestion that document should avoid the passive voice was not
acknowledged or accepted, despite the advice of the RFC Style Guide:

  https://www.rfc-editor.org/rfc-style-guide/rfc-style-manual-08.txt

   *  Passive voice (e.g., "The dog was kicked by you") may be used but
      is frowned upon.  Text should be written in active voice (e.g.,
      "You kicked the dog").

In some cases linked suggestions were separated and then rejected.
E.g. the idea that we should (1) explain the certificate usages in the
document from simplest to most complex, and (2) renumber the
certificate usages from simplest to most complex.  This was rejected
with the remark that we should of course present the certificate
usages in numerical order (the idea of renumbering was ignored).

An issue that I raised which saw little discussion was that the term
"Certificate Association", which is used about 36 times in the
document, is not well defined.  Here is its definition:

1.1.  Certificate Associations

   A certificate association is formed from a piece of information
   identifying a certificate with the domain name where the data is
   found.

That sentence may tell you how it's formed, but it doesn't tell you
what it is.  An object may be formed from metal, but what is it?  A
paperclip, a fire extinguisher, or an engine block?  The generalities
in the definition leach almost all the meaning from the sentence.  "A
piece of information"?  All computing is composed of pieces of
information, can we not be more specific?  "Where the data is found"?
What data?  Who is finding it?  To misquote Radia, "Don't be impressed
with unintelligible stuff, period."

We also use the bare word "association" in phrases like this:

   An example of a hashed (SHA-256) association of a PKIX CA
   certificate:  ...

This is not the King's English ("association" is usually followed by
"with" or "between" to define the two things being associated, or by
"of" to name a plural noun like "scientists").  Nor is it a well known
term of computing art, nor is it a term that we defined clearly in the
document.  We should either define it clearly, or avoid the term.

Is a certificate association a relationship (between a cert and a
domain name)?  If not, what is it?  An assertion, perhaps?  If it is a
relationship or an assertion, why not say so?  My proposed replacement
text was:

  A "certificate association" is a relationship formed by securely
  identifying a certificate with a domain name.

This lack of clarity in a concept so fundamental to the RFC (which
even appears in the abbreviated title at the bottom of each page of
the draft, "DNS Cert Association for TLS"), combined with the editors'
reluctance to clarify it, is why I suggested that the document be
revised in those 36 places to refer to "TLSA records" rather than to
"certificate associations".  We all agree on what a TLSA record is,
and the document defines it clearly.

> Again, thank you all for your assistance,

You're welcome.

	John

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 23 Feb 2012 08:22:58 -0800

> (like how the various usage types affect the TLS protocol).

That's a pretty weird reaction to me asking if others wanted the same changes you wanted. I didn't "object": I voiced an opinion that it was not useful, but made it clear that was just one opinion. If you have followed the WG at all, you will know that sometimes Jakob and I voice an opinion that the WG disagrees with, and *every time* we reflect the WG's consensus in the document.

--Paul Hoffman