Skip to main content

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.