Last Call Review of draft-ietf-dnsop-5966bis-04
review-ietf-dnsop-5966bis-04-genart-lc-carpenter-2015-11-30-00

Request Review of draft-ietf-dnsop-5966bis
Requested rev. no specific revision (document currently at 06)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2015-12-07
Requested 2015-11-23
Authors John Dickinson, Sara Dickinson, Ray Bellis, Allison Mankin, Duane Wessels
Draft last updated 2015-11-30
Completed reviews Genart Last Call review of -04 by Brian Carpenter (diff)
Genart Telechat review of -05 by Brian Carpenter (diff)
Opsdir Last Call review of -04 by Rick Casarez (diff)
Assignment Reviewer Brian Carpenter 
State Completed
Review review-ietf-dnsop-5966bis-04-genart-lc-carpenter-2015-11-30
Reviewed rev. 04 (document currently at 06)
Review result Almost Ready
Review completed: 2015-11-30

Review
review-ietf-dnsop-5966bis-04-genart-lc-carpenter-2015-11-30

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at
<

http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-dnsop-5966bis-04.txt
Reviewer: Brian Carpenter
Review Date: 2015-11-30
IETF LC End Date: 2015-12-07
IESG Telechat date:

Summary: Almost ready
--------

Comment: I read all the text and have no technical issues.
--------

Major Issues:
-------------

This draft replaces RFC 5966, which formally updates RFC 1035 and 1123. Therefore,
logically this draft must also formally update RFC 1035 and 1123.

Specifically:

"Section 6.1.3.2 of [RFC1123] states:

      DNS resolvers and recursive servers MUST support UDP, and SHOULD
      support TCP, for sending (non-zone-transfer) queries."

Please make an explicit statement that this SHOULD is changed to MUST.

Minor Issues:
-------------

1) The last sentence of the Introduction says
"It should be noted that failure to support TCP (or the
blocking of DNS over TCP at the network layer) may result in
resolution failure and/or application-level timeouts."

Isn't "may" understating the risk these days? I would have thought that
"will probably result in ... failure" was justified.

2) If you want people to update existing code, the section "Changes to RFC 5966"
should be kept when "Appendix B. Changes between revisions" is deleted. Also,
please check which of the more recent changes need to be noted as changes compared
to RFC 5966. For example, these all seem to be substantive changes that might need
code updates:

implementations MUST NOT send the TCP framing 2 byte length field
in a separate packet to the DNS message.

servers should answer all pipelined queries even if sent very close together.

servers MAY use 0 idle timeout

more discussion on DoS mitigation

new text on recommendations for client idle behaviour