> On Jan 4, 2017, at 10:24 AM, Christer Holmberg > <[email protected]> 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 _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
