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

From: "Martin Stiemerling" <[email-masked]>
Date: Tue, 05 Jan 2016 14:29:32 -0800

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

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.

---

From: Sara Dickinson <[email-masked]>
Date: Wed, 6 Jan 2016 16:13:13 +0000

> On 5 Jan 2016, at 22:29, Martin Stiemerling <[email-masked]> wrote:
> 
> 

I've checked with the other authors and we are fine with removing the statement about intermediary behaviour.

> also honor that RFC 6824 is listed in the informative part of the

This was picked up in an earlier review and in the -05 version the last sentence was reworded to be more suitable for an experimental RFC reference:

“It might be possible for
   anycast servers to avoid disruption due to topology changes by making
   use of TCP multipath [RFC6824] to anchor the server side of the TCP
   connection to an unambiguously-unicast address.”

Does this address your concerns sufficiently?

Regards

Sara.

---

From: Martin Stiemerling <[email-masked]>
Date: Wed, 6 Jan 2016 22:19:41 +0100

Hi Sara,

Am 06.01.16 um 17:13 schrieb Sara Dickinson:
>> 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.
>

ok, thanks!

>> 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.
>
> This was picked up in an earlier review and in the -05 version the
> last sentence was reworded to be more suitable for an experimental
> RFC reference:
>
> “It might be possible for anycast servers to avoid disruption due to
> topology changes by making use of TCP multipath [RFC6824] to anchor
> the server side of the TCP connection to an unambiguously-unicast
> address.”
>

That works for me.

Thanks for addressing my concerns,

  Martin