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

["Jim Schaad" <[e-mail]>]

> -----Original Message-----
> From: dane [mailto:[e-mail]] On Behalf Of Viktor Dukhovni
> Sent: Sunday, December 01, 2013 1:34 PM
> To: [e-mail]
> Subject: Re: [dane] Start of WGLC for draft-ietf-dane-registry-acronym
> 
> 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. ]

+1

> 
> 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.
> _______________________________________________
> dane mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dane