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