The edns-tcp-keepalive EDNS0 Option
draft-ietf-dnsop-edns-tcp-keepalive-06

-- Section 1 --

   Long-lived
   TCP connections can result in lower request latency than the case
   where UDP transport is used and truncated responses are received,
   since clients that have fallen back to TCP transport in response to a
   truncated response typically only uses the TCP session for a single
   (request, response) pair, continuing with UDP transport for
   subsequent queries.

This is a really long, awkward sentence, and it appears to have an error 
in it that makes it unparseable.  May I suggest a replacement?:

NEW
   Responses over UDP might be truncated, and when that happens many
   clients will retry the query over TCP.  Such retries typically use
   the TCP session only for one request/response pair, and the clients
   then revert back to UDP for subsequent queries.  Using long-lived
   TCP connections in the first place avoids these situations and can
   result in lower request latency.
END   

In general, calling the retry over TCP "fallback" is misleading, and I 
suggest not doing that.  The term "fallback" generally refers to a 
situation where an optimization fails, and you "fall back" to the 
non-optimized method.  That's not the case here; here, UDP is the normal 
method, and you retry over TCP when the response is too big to work with 
UDP.

The use of "fall back to UDP" in Section 3.4 is an apt use of "fall back", 
in that sense, as is the use of "fallback" in Section 3.5.  But the use in 
the abstract and at the top of page 4 are not.  I suggest "clients 
commonly use TCP only for retries" in the abstract, and "received over UDP 
with retries over TCP" on page 4.

- 3.2.2:

I think it would be helpful to give some more guidance about the “timeout” period. That is, when does it start, does it reset when a new query is sent, etc? This is somewhat implied by the term “idle”, but it would be better to be explicit.

-3.3.2:
I understand from later in the draft that the  OPT RR in a query does not necessarily need to have include edns-tcp-keepalive for the server to include it in the response.  A careless reader might easily miss that distinction. It would be helpful to emphasize it here.

=== Editorial===
- Abstract:
The abstract is rather long. The first paragraph might be better left to the introduction section.

- 1:
The introduction sort of buries the lede. The idea that clients and servers need to manage idle connections is not mentioned until paragraphs 8 and 9. That's the whole point of the document.

Thanks for the quick resolution to my DISCUSS point. The proposed change is recorded below for posterity.

OLD:

It SHOULD honour the timeout and initiate close of the connection before the timeout expires.

NEW:

It SHOULD honour the timeout received in that response (overriding any previous timeout) and initiate close of the connection before the timeout expires.

Two comments for your considerations:

1) Section 3.3.2 is talking about this "It is reasonable for this value to change [...] or in consideration of  intermediary behaviour (for example TCP middleboxes or NATs)."
Can you please clarify how the DNS client or server is able to inspect the behaviour of intermediated devices and adapt its behaviour accordingly? This smells a bit like a half-baked idea which does not belong into a standards track document. 


2) Section 3.6. talks about using Multipath TCP. Please note that Multipath TCP is still experimental and has known security issues, which are dealt with right now. Further, I would recommend to move this to a non-normative appendix, noting that this is a potential future way forward, but that is has not yet been tested and deployed. This would also honor that RFC 6824 is listed in the informative part of the references.