Last Call Review of draft-ietf-dnsop-edns-key-tag-03
review-ietf-dnsop-edns-key-tag-03-genart-lc-holmberg-2017-01-04-00
Request | Review of | draft-ietf-dnsop-edns-key-tag |
---|---|---|
Requested revision | No specific revision (document currently at 05) | |
Type | Last Call Review | |
Team | General Area Review Team (Gen-ART) (genart) | |
Deadline | 2017-01-16 | |
Requested | 2017-01-02 | |
Authors | Duane Wessels , Warren "Ace" Kumari , Paul E. Hoffman | |
I-D last updated | 2017-01-04 | |
Completed reviews |
Opsdir Telechat review of -04
by Mahesh Jethanandani
(diff)
Genart Last Call review of -03 by Christer Holmberg (diff) Secdir Last Call review of -03 by Scott G. Kelly (diff) Genart Telechat review of -04 by Christer Holmberg (diff) |
|
Assignment | Reviewer | Christer Holmberg |
State | Completed | |
Request | Last Call review on draft-ietf-dnsop-edns-key-tag by General Area Review Team (Gen-ART) Assigned | |
Reviewed revision | 03 (document currently at 05) | |
Result | Ready w/issues | |
Completed | 2017-01-04 |
review-ietf-dnsop-edns-key-tag-03-genart-lc-holmberg-2017-01-04-00
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. 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. Minor Issues: Note Editorial Issues: Q2_Section_1: -------------------- In order to use consistent terminology, please replace "This draft" with "This document". 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:" 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." 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.