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