DNS Transport over TCP - Implementation Requirements
draft-ietf-dnsop-5966bis-06

I'm balloting "yes" under the assumption this is intended as proposed standard.

6.2.1.1:
Now that clients SHOULD pipeline, is it enough to say servers SHOULD expect it? Seems like a MUST would be in order.

=== Editorial===
-1: "... TCP is henceforth a REQUIRED ..."
Since the normative language is strengthened in section 5, the REQUIRED seems redundant here. I'd suggest stating this without the 2119 keyword.

- 5, 2nd to last paragraph:
I concur with Barry on the unclear antecedent of "It".

While I am not a fan of standards-track requirements documents, I understand the history of 5966 and support the publication of this document. I do have a couple of comments for your consideration.

1. Is it worth mentioning in the Intro that another drive towards more TCP-based DNS exchanges may be the desire to re-use existing security associations for DNS privacy solutions?

2. Is there a reference to back up the statement "However, transport of UDP packets that exceed the size of the path  MTU causes IP packet fragmentation, which has been found to be unreliable in many circumstances."? It would be good to be able to gauge just how unreliable this issue has become.

3. I agree with Martin's suggested re-wording in Section 8.

One comment and request for clarification:

In the first paragraph of Section 8:
"   DNS clients and servers SHOULD pass the two-octet length field, and
   the message described by that length field, to the TCP layer at the
   same time (e.g., in a single "write" system call) to make it more
   likely that all the data will be transmitted in a single TCP segment.
   This is both for reasons of efficiency and to avoid problems due to
   some DNS server implementations behaving undesirably when processing
   TCP segments (due to a lack of clarity in previous standards).  For
   example, some DNS server implementations might abort a TCP session if
   the first TCP segment does not contain both the length field and the
   entire message.
"

This paragraphs says that DNS servers process segments. This is slightly inaccurate, at least under the assumption that DNS clients and servers are user land processes. 
Such a user land process does not see segments but data being read or written to the sockets. And such data might be one or multiple segments concatenated. 

I do understand the text, but I would like to propose a change (though the proposed text might not be perfect):

   This is both for reasons of efficiency and to avoid problems due to
   some DNS server implementations behaving undesirably when reading
   data from TCP  (due to a lack of clarity in previous standards).  For
   example, some DNS server implementations might abort a TCP session if
   the first data part read from TCP does not contain both the length field and the
   entire message.

In this text:

   It is however noted that certain primary/secondary
   configurations with many busy zones might need to use more than one
   TCP connection for zone transfers for operational reasons.
   
could "for operational reasons" be a bit more precise? I think I know the problem that's being solved, but I'm guessing, and other readers might not know.

Thanks for addressing my issue about TFO & DPRIVE.