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

[Sara Dickinson <[e-mail]>]

> On 5 Jan 2016, at 22:29, Martin Stiemerling <[e-mail]> wrote:
> 
> 
> 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. 

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

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

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.