Viktor,
On Jan 16, 2014, at 10:41 PM, Viktor Dukhovni <[email protected]> wrote:
> On Thu, Jan 16, 2014 at 03:49:43PM -0500, Olafur Gudmundsson wrote:
>
>>> - s/confused as what/confused as to what/
>>> - s/column with acronym/column with an acronym/
>>>
>> Fixed
>
> While you're still taking fixes of this sort:
>
> diff --git a/draft-ietf-dane-registry-acronyms-03.xml
> b/draft-ietf-dane-registry-acronyms-03.xml
> index b75515a..27d1d66 100644
> --- a/draft-ietf-dane-registry-acronyms-03.xml
> +++ b/draft-ietf-dane-registry-acronyms-03.xml
> @@ -38,9 +38,9 @@
> <workgroup>DANE</workgroup>
>
> <abstract>
> - <t>Experience has show that people get confused using the three
> - numeric fields the TLSA record. This document specifies
> - descriptive acronyms for the three numeric fields in the TLSA
> + <t>Experience has shown that people get confused using the three
> + numeric fields in the TLSA record. This document specifies
> + descriptive acronyms for the three numeric fields in TLSA
> records.
> This document updates the format of the IANA registry created by
> RFC6698.
> </t>
This looks good I will propose that we apply it, before the document pops out
as an RFC.
> @@ -50,11 +50,12 @@
> <middle>
> <section title="Introduction">
> <t> During discussions on how to add DANE <xref target="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.
> + technology to new protocols/services people have repeatedly
> + been confused as what the numeric values stand for and even
> + the order of the fields in a TLSA record.
> + This document updates the IANA registry definition of the TLSA
> + record to add a column with an acronym for each specified field, so
> + as to reduce confusion.
> This document does not change the DANE protocol in any way.
> </t>
> <t>It is expected that DANE parsers in applications and DNS
Same here,
> @@ -168,8 +169,8 @@
> <section title="Acronym use in a specification example:">
> <t>
> Protocol FOO only allows
> - TLSA records using PKIX-EE and DANE-EE, with selector SPKI and
> - using SHA2-512. </t>
> + TLSA records using PKIX-EE(1) and DANE-EE(3), with selector SPKI(1) and
> + using SHA2-512(2). </t>
> <!-- <t> Sides example: "In the case of FOO for practical cases you
> can treat PKIX-CA == DANE-TE" (see talk at IETF-87 on DANE for
> email) </t> -->
Much better
> @@ -185,7 +186,7 @@
> <section title="Acknowledgements">
> <t>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
> + from an implementor's viewpoint. Jim Schaad, Wes Hardaker and Paul
> Hoffman provided feedback during WGLC.
> </t>
> </section>
> --
Same here
> Viktor.
Thanks for suggestions.
Olafur
> _______________________________________________
> dane mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dane
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
