On Mon, Oct 5, 2015 at 1:08 PM, Tim WIcinski <tjw.i...@gmail.com> wrote:
> This starts a Working Group Last Call for > draft-ietf-dnsop-edns-tcp-keepalive > Current versions of the draft is available here: > > https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-tcp-keepalive/ > > The chairs feel the authors have spent considerable time addressing > questions and issues raised, and the current document has undergone some > solid revision. We would appreciate if the working group could review the > draft and offer relevant comments. Also, if someone feels the document is > *not* ready for publication, please speak out with your reasons. 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. 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. Although such behavior isn't explicitly prohibited, the following part of Section 3.4 seems to rather expect such subsequent inclusion more commonly: Since servers must be faithful to this specification even on a persistent TCP connection it means that (following the initial exchange of timeouts) a server may not be presented with the opportunity to signal a change in the idle timeout associated with a connection if the client does not send any further requests containing EDNS0 OPT RRs. So it may be better to explicitly say, e.g., that clients MAY include the option in subsequent queries. 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". 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'. I personally don't have a strong opinion, but it seemed to be more consistent with other use of the RFC2119 keywords in this document. 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). -- JINMEI, Tatuya _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
