Skip to main content

The edns-tcp-keepalive EDNS0 Option
RFC 7828

Yes

(Joel Jaeggli)

No Objection

Alvaro Retana
(Alia Atlas)
(Alissa Cooper)
(Benoît Claise)
(Deborah Brungard)
(Jari Arkko)
(Kathleen Moriarty)
(Spencer Dawkins)

Note: This ballot was opened for revision 04 and is now closed.

Alvaro Retana No Objection

(Joel Jaeggli; former steering group member) Yes

Yes (for -04)

                            

(Stephen Farrell; former steering group member) (was Discuss) Yes

Yes (2016-01-07 for -05)
This used be a discuss but since the answer is probably
that no change is needed, Joel said he'd figure it out
with the WG.

Before I ballot yes on this I have a question to ask.
Most likely the answer will be the obvious one and we'll be
done, but I want to check and if the answer is not the
obvious one then holding the discuss as we fix stuff would
be correct I think.

The question: how does this option play with DNS over
DTLS? [1] 

The reason I ask is that there may be a need in that case
for some similar option (or a TLS extension maybe) though
for the DTLS session lifetime and not a TCP session
lifetime. At present you are saying that this option is
not it. And that's a fine answer but you could also have
said that this could also be used for DTLS session
lifetime handling. And that last might make sense for
operational reasons (not sure really, but could be).  

   [1] https://tools.ietf.org/html/draft-ietf-dprive-dnsodtls-03

old comments
- intro: "However, TCP transport as currently deployed has
expensive setup overhead." That seems a bit wrong as the
3-way h/s is an inherent part of TCP and isn't really
specific to DNS with TCP trasnport not is it a deployment
issue. I'd suggest just delete the sentence and merge the
remaining part of tha para with the next.

- 3.3.2: What's the last sentence of this section about?
A case where a TCP session is handed over? Might be no
harm saying why (via a reference to anything would be
fine)

(Alia Atlas; former steering group member) No Objection

No Objection (for -05)

                            

(Alissa Cooper; former steering group member) No Objection

No Objection (for -04)

                            

(Barry Leiba; former steering group member) No Objection

No Objection (2016-01-05 for -04)
-- 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.

(Ben Campbell; former steering group member) No Objection

No Objection (2016-01-06 for -05)
- 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.

(Benoît Claise; former steering group member) No Objection

No Objection (for -05)

                            

(Brian Haberman; former steering group member) (was Discuss) No Objection

No Objection (2016-01-05 for -04)
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.

(Deborah Brungard; former steering group member) No Objection

No Objection (for -04)

                            

(Jari Arkko; former steering group member) No Objection

No Objection (for -05)

                            

(Kathleen Moriarty; former steering group member) No Objection

No Objection (for -05)

                            

(Martin Stiemerling; former steering group member) No Objection

No Objection (2016-01-05 for -04)
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.

(Spencer Dawkins; former steering group member) No Objection

No Objection (for -05)