> -----Original Message----- > From: dane [mailto:[email protected]] On Behalf Of Viktor Dukhovni > Sent: Sunday, December 01, 2013 1:34 PM > To: [email protected] > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/dane _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
