> On 7 Oct 2015, at 18:17, 神明達哉 <[email protected]> wrote:
>
>
> I've read the 03 version of draft. It's very well written and I've
> not found any critical technical issues. So I basically think it's
> ready to ship.
>
Hi,
Many thanks for the review.
> I have a couple of minor comments, which the authors might want to
> address/discuss before advancing the draft:
>
> 1. Section 3.2.1
>
> DNS clients MAY include the edns-tcp-keepalive option in the first
> query sent to a server using TCP transport to signal their desire to
> keep the connection open when idle.
>
> I wonder whether we want to explicitly say something about including
> the edns-tcp-keepalive option in subsequent queries on the same TCP
> connection.
> So it may be better to explicitly say, e.g., that clients MAY
> include the option in subsequent queries
Yes, this will definately improve the document. The following has been added to
Section 3.2.1:
DNS clients MAY include the edns-tcp-keepalive option in the first
query sent to a server using TCP transport to signal their desire to
keep the connection open when idle.
+ DNS clients MAY include the edns-tcp-keepalive option in subsequent
+ queries sent to a server using TCP transport to signal their
+ continued desire to keep the connection open when idle.
> We might even want to use
> a stronger requirement like "the client SHOULD occasionally include
> the option in subsequent queries if it includes the option in the
> first query”.
I’m not sure how prescriptive the document should be on this...
Would adding the following paragraph to Section 3.4 on TCP session management
address you concerns?
attractive than a mechanism that establishes default persistence and
then uses a connection close signal (in a similar manner to HTTP 1.1
[RFC7320]).
+ Clients might choose to send the edns-tcp-keepalive option regularly
+ during a TCP session to increase the chance of being notified should
+ the server modify the timeout associated with a session. The
+ algorithm for choosing when to do this is out of scope of this
+ document and is left up to the implementor and/or operator.
>
> 2. Section 3.2.2
>
> A DNS client that receives a response that includes the edns-tcp-
> keepalive option with a TIMEOUT value of 0 should send no more
> queries on that connection and initiate closing the connection as
> soon as it has received all outstanding responses.
>
> I wonder whether this 'should' may better be 'SHOULD’.
Good catch, this is now a SHOULD.
>
> And, one minor editorial nit: In Section 5
>
> [...] When a Nameserver
> detects abusive behaviour, it SHOULD immediately close the TCP
> connection and free the resources used.
>
> Perhaps s/Nameserver/nameserver/? Or, it might even be "DNS server"
> ('[Nn]ameserver' or 'name server' doesn't seem to be used anywhere
> else in the document).
This is now 'DNS server’ which is consistent with the rest of the document.
Regards
Sara.
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
