Hi Sara, On 03/12/2015 02:52, Sara Dickinson wrote: > >> On 29 Nov 2015, at 21:16, Brian E Carpenter <brian.e.carpen...@gmail.com> >> wrote: >> >> Comment: I read all the text and have no technical issues. > > Hi Brian, > > Many thanks for the review. After a discussion amongst the authors and Tim, > responses below. > > >> -------- >> >> 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. > > The bis reproduces 2 statements verbatim from RFC5966 with regard to this. In > paragraph 4 of the Introduction: > > “This document therefore updates the core DNS protocol specifications > such that support for TCP is henceforth a REQUIRED part of a full DNS > protocol implementation." > > and in the first sentence of Section 5 > > “All general-purpose DNS implementations MUST support both UDP and TCP > transport.” > > In light of this do you still think we need another statement to this effect?
Well, this may seem picky, but since you quote the text, I think that a clear statement that you are changing it is useful. IMHO, YMMV, of course. Adding the "Updates: 1035, 1123" is necessary, though. Thanks for the rest, your proposals are fine. Rgds Brian > >> >> 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. > > Again, the wording here was lifted exactly from RFC5966, but the suggested > change seems an improvement. I have updated the working copy with the new > text. > >> >> 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. > > This is an excellent point. In the working copy I have moved the “Changes to > RFC5966” section to a separate Appendix and updated the wording: > > "Appendix C. Changes to RFC5966 > > [Note to RFC Editor: please leave this section in the final > document.] > > This document obsoletes [RFC5966] and differs from it in several > respects. An overview of the most substantial changes/updates that > implementors should take note of is given below: > > 1. A Terminology section (Section 3) is added defining several new > concepts. > > 2. Paragraph 3 of Section 5 puts TCP on a more equal footing with > UDP than RFC5966. For example it states: > > 1. TCP MAY be used before sending any UDP queries. > > 2. TCP ought to be considered a valid alternative transport to > UDP, not purely a fallback option. > > 3. Section 6.2.1 adds a new recommendation that TCP connection- > reuse SHOULD be supported. > > 4. Section 6.2.1.1 adds a new recommendation that DNS clients > SHOULD pipeline their queries and DNS servers SHOULD process > pipelined queries concurrently. > > 5. Section 6.2.2 adds new recommendations on the number and usage > of TCP connections for client/server interactions. > > 6. Section 6.2.3 adds a new recommendation that DNS clients SHOULD > close idle sessions unless using a signalling mechanism. > > 7. Section 7 clarifies that servers are RECOMMENDED to prepare TCP > responses in parallel and send answers out-of-order. It also > clarifies how TCP queries and responses should be matched by > clients. > > 8. Section 8 adds a new recommendation about how DNS clients and > servers should handle the 2 byte message length field for TCP > messages. > > 9. Section 9 adds a non-normative discussion of the use of TCP Fast > Open. > > 10. The Section 11 adds new advice regarding DoS mitigation > techniques.” > > > Regards > > Sara. > _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
