Subject: [Gen-art] Gen-ART Last Call review of draft-ietf-dnsop-5966bis-04

From: Brian E Carpenter <[email-masked]>
Date: Mon, 30 Nov 2015 10:16:42 +1300

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