> 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. > > 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. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
