Re: [Gen-art] Gen-ART review of draft-ietf-dnsop-edns-key-tag-03

["Wessels, Duane" <[e-mail]>]

> On Jan 4, 2017, at 10:24 AM, Christer Holmberg <[e-mail]> wrote:
> 
> 
> I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>
> 
> Document:                       draft-ietf-dnsop-edns-key-tag-03.txt
> Reviewer:                         Christer Holmberg
> Review Date:                   4 January 2017
> IETF LC End Date:           10 January 2017
> IETF Telechat Date:        19 January 2017
> 
> Summary: The document is well written, and almost ready for publication. However, I have one issue, and a few minor editorial issues in the Abstract/Introduction that I ask the authors to address.
> 

Thank you for the review!


> Major Issues:
> 
> Q1_Abstract:
> ------------------
> 
> The text says:
> 
>   "The reason there are two methods instead of one is some people see significant problems with each method."
> 
> This text looks very strange to an outsider like myself. I can understand that people sometimes have different preferences, but when you say "people see significant problems" it makes me wonder why a publication request has been done in the first place. Don't we normally publish RFCs because we want to SOLVE problems - not because we want to (at least not intentionally) create new ones? :)
> 
> I think it would be good to talk about people having different preferences (and within the document the reasons can be described in more detail) instead of people seeing problems.
> 
> Also, I am not sure whether the Abstract needs to talk about the reason for having two methods. I think  a statement saying that the background and reason for two methods are described within the document would be enough within the Abstract.

Agreed.  I've removed that second paragraph and modified the first (now only) paragraph of the Abstract to read:

   This document specifies two different
   ways for validating resolvers to signal to a server which keys are
   referenced in their chain-of-trust (see Section 1.1 for the
   rationale).  The data from such signaling allow zone administrators
   to monitor the progress of rollovers in a DNSSEC-signed zone.



> 
> 
> Minor Issues: Note
> 
> 
> Editorial Issues:
> 
> Q2_Section_1:
> --------------------
> 
> In order to use consistent terminology, please replace "This draft" with "This document".


Done.


> 
> 
> Q3_Section_1:
> --------------------
> 
> The text says:
> 
> "This is done in two ways:"
> 
> I suggest to replace the text with the statement found in the Abstract:
> 
>   "This document describes two independent methods for validating
>   resolvers to publish their referenced keys:"

Edited so that paragraph now reads:

   This document specifies how validating resolvers can tell a server,
   in a DNS query, which DNSSEC key(s) they would use to validate the
   server's responses.  It describes two independent methods for
   conveying Key Tag information bewteen clients and servers: ...



> 
> Q4_Section_1-1:
> ----------------------
> 
> The text says:
> 
>   "Initially this document was named draft-edns-key-tag and proposed
>   including Key Tag values in a new EDNS(0) option code.  It was
>   modeled after [RFC6975], which provides DNSSEC algorithm signaling."
> 
> Why do you include the name of the initial draft? Initial drafts can be called anything. I think it is enough to instead talk about the initially suggested mechanism. Something like:
> 
>   "Initially, when the work on this document started, it proposed
>   including Key Tag values in a new EDNS(0) option code.  It was
>   modeled after [RFC6975], which provides DNSSEC algorithm signaling."

Done.


> 
> 
> Q5_Section_1-1:
> ----------------------
> 
> The text says:
> 
> "The authors received feedback from Working Group participants"
> 
> Please write the name of the Working Group. The name of the WG is currently only mentioned in the Acknowledgements.
> 

Done.


DW