Brian
Thanks for the review - comments in line.
On 11/22/15 8:58 PM, Brian E Carpenter wrote:
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.
For more information, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Document: draft-ietf-dnsop-edns-tcp-keepalive-04.txt
Reviewer: Brian Carpenter
Review Date: 2015-11-23
IETF LC End Date: 2015-11-30
IESG Telechat date:
Summary: Ready with issues
--------
Comment: These are only standards-language issues, nothing fundamental.
--------
Major Issues:
-------------
Last paragraph of section 3.2.2. Receiving Responses:
A DNS client that sent a query containing the edns-keepalive-option
but receives a response that does not contain the edns-keepalive-
option should assume the server does not support keepalive and behave
following the guidance in [DRAFT-5966bis]. This holds true even if a
previous edns-keepalive-option exchange occurred on the existing TCP
connection.
Firstly, shouldn't that "should" be a SHOULD?
Yes, that should be a SHOULD. Good catch
More important, [DRAFT-5966bis] really looks like a normative reference to me.
I couldn't code this without reading that reference. It's already entering
Last Call so hopefully this won't waste much time.
That's interesting. I think we decided to make it informative is that
its covering new discussions.
Section 3.6. Anycast Considerations:
...
Changes in network topology between clients and anycast servers may
cause disruption to TCP sessions making use of edns-tcp-keepalive
more often than with TCP sessions that omit it, since the TCP
sessions are expected to be longer-lived. Anycast servers MAY make
use of TCP multipath [RFC6824] to anchor the server side of the TCP
connection to an unambiguously-unicast address in order to avoid
disruption due to topology changes.
IMHO, [RFC6824] is another normative reference; and it's a downref since
it's an Experimental RFC. I think you could avoid this by weakening
the last sentence a bit:
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's a useful edit. I'll circle back to the authors on this.
thanks again
tim
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
