Last Call Review of draft-ietf-dnsop-edns-key-tag-03

Request Review of draft-ietf-dnsop-edns-key-tag
Requested rev. 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 Kumari, Paul Hoffman
Draft 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 Kelly (diff)
Genart Telechat review of -04 by Christer Holmberg (diff)
Assignment Reviewer Christer Holmberg 
State Completed
Review review-ietf-dnsop-edns-key-tag-03-genart-lc-holmberg-2017-01-04
Reviewed rev. 03 (document currently at 05)
Review result Ready with Issues
Review completed: 2017-01-04


I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <>

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:


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:


In order to use consistent terminology, please replace "This draft" with "This document".


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:"


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."


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.