> On 7 Oct 2015, at 18:17, 神明達哉 <jin...@wide.ad.jp> 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
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to