Subject: [DNSOP] Stephen Farrell's Yes on draft-ietf-dnsop-edns-tcp-keepalive-05: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Thu, 07 Jan 2016 07:19:03 -0800

Stephen Farrell has entered the following ballot position for
draft-ietf-dnsop-edns-tcp-keepalive-05: Yes

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

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)