Re: [dane] I-D Action: draft-ietf-dane-registry-acronyms-03.txt

Viktor, 

On Jan 16, 2014, at 10:41 PM, Viktor Dukhovni <viktor1dane@dukhovni.org> 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
> dane@ietf.org
> https://www.ietf.org/mailman/listinfo/dane