Subject: [DNSOP] Barry Leiba's No Objection on draft-ietf-dnsop-edns-tcp-keepalive-04: (with COMMENT)

From: "Barry Leiba" <[email-masked]>
Date: Tue, 05 Jan 2016 23:57:20 -0800

Barry Leiba has entered the following ballot position for
draft-ietf-dnsop-edns-tcp-keepalive-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-tcp-keepalive/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

-- 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.

---

From: Sara Dickinson <[email-masked]>
Date: Wed, 6 Jan 2016 11:50:57 +0000

> On 6 Jan 2016, at 07:57, Barry Leiba <[email-masked]> wrote:
> 
> in it that makes it unparseable.  

Point taken. I have re-worded it to make it clearer. 

>  But the use

Yes, I think this is clearer. I have updated as suggested. 

Changes are in the -05 version published this morning. 

Regards

Sara.

---

From: Barry Leiba <[email-masked]>
Date: Wed, 6 Jan 2016 20:33:59 +0800

Thanks for the quick response, Sara, and for addressing my comments.

Barry

On Wednesday, January 6, 2016, Sara Dickinson <[email-masked]> wrote:

>
> > On 6 Jan 2016, at 07:57, Barry Leiba <[email-masked]
> <javascript:;>> wrote:
> >