Hi Sara,
Am 06.01.16 um 17:13 schrieb Sara Dickinson:
On 5 Jan 2016, at 22:29, Martin Stiemerling <mls.i...@gmail.com>
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.
ok, thanks!
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?
That works for me.
Thanks for addressing my concerns,
Martin
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
