Re: [dane] Start of WGLC for draft-ietf-dane-registry-acronym

[Viktor Dukhovni <[e-mail]>]

On Sun, Dec 01, 2013 at 02:00:41PM -0500, Warren Kumari wrote:

> I'm not sure where these "wise chairs" are, but I believe we have
> consensus for PKIX-TA.  It's not ideal but seems good enough.

[ FWIW, I still maintain that PKIX-CA (being just a constraint and
  not necessarily an anchor for the chain) is correct, while PKIX-TA
  is misleading.  PKIX-CA is quite different from DANE-TA, where the
  association data in fact specifies a trust-anchor.  Multiple
  implementations have failed to correctly capture the semantics
  of DANE-TA, we should not IMNSHO make PKIX-CA and DANE-TA appear
  to be more similar than they are. ]

Suggested word-smithing final touches:

In the Abstract change:

   -----
   Experience has show that people get confused using the three numeric
   fields the TLSA record.
   -----

to:

   -----
   Experience has shown that people are sometimes confused by the
   three numeric fields in the TLSA record.
   -----

Replace the introduction:

   -----
   In discussions on how to add DANE [RFC6698] technology to new
   protocols/services people repeatedly have got confused as what the
   numeric values stand for and even the order of the fields of a TLSA
   record.  This document updates the IANA registry definition for TLSA
   record to add a column with acronym for each specified field, in
   order to reduce confusion.  This document does not change the DANE
   protocol in any way.

   It is expected that DANE parsers in applications and DNS software can
   adopt parsing the acronyms for each field.
   -----

with:

   -----
   In discussions on how to add DANE [RFC6698] technology to new
   protocols/services there has been repeated confusion as to what
   the numeric values stand for and even the order of these fields
   in a TLSA record.  This document updates the IANA registry
   definition for the TLSA record to add an acronym for each
   specified field, in order to reduce confusion.  This document
   does not change the DANE protocol in any way.

   It is expected that parsers in applications and DNS software
   will accept the new acronyms as alternatives to the underlying
   numeric values in the presentation format of TLSA records.
   -----

In "IANA considerations replace:

   -----
   [RFC6698] and this document are both to be the reference documents
   for the three sub-registries.

   As these acronyms are offered for human consumption, case does not
   matter, it is expected that software that parses TLSA records will
   handle either upper or lower case use as input.
   -----

with:

   -----
   [RFC6698] and this document will be the reference documents for
   the three sub-registries.

   As these acronyms are offered for human consumption, case does not
   matter, it is expected that software that parses TLSA records will
   process the acronyms in a case-insensitive manner.
   -----

In "Acknowledgements" replace:

   -----
   Scott Schmit offered real good suggestions to decrease the
   possibility of confusion.  Viktor Dukhovni provided comments from
   expert point of view.  Jim Schaad, Wes Hardaker and Paul Hoffman
   provided feedback during WGLC.
   -----

with

   -----
   The author thanks Jim Schaad, Paul Hoffman, Scott Schmit, Viktor
   Dukhovni and Wes Hardaker for their helpful comments.
   -----

-- 
	Viktor.