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 revision No specific revision (document currently at 06)
Type IETF 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
I-D last updated 2019-03-16 (Latest revision 2016-01-15)
Completed reviews Genart IETF Last Call review of -04 by Brian E. Carpenter (diff)
Genart Telechat review of -05 by Brian E. Carpenter (diff)
Opsdir IETF Last Call review of -04 by Rick Casarez (diff)
Assignment Reviewer Brian E. Carpenter
State Completed
Request IETF Last Call review on draft-ietf-dnsop-5966bis by General Area Review Team (Gen-ART) Assigned
Reviewed revision 04 (document currently at 06)
Result Almost ready
Completed 2015-11-30
review-ietf-dnsop-5966bis-04-genart-lc-carpenter-2015-11-30-00
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