> 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