> On 15 Oct 2015, at 02:29, 神明達哉 <jin...@wide.ad.jp <mailto:jin...@wide.ad.jp>> > wrote: > > At Wed, 14 Oct 2015 11:55:02 +0100, > > I have no objection to this text per se, but the described reason why > the client might want to do this is different from what I intended. I > was more concerned about the case where the client only includes the > option in the first query and the server can't send updated > notification. And, in that sense, > while the text looks good to me, I thought it would be safer to use > some RFC2119 keyword here. Combining these, what I would have > proposed is something like this: > > 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. If a client include the > option in the first query, it SHOULD include the 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 specifically when to include the option in > subsequent queries is out of scope of this document and is left up > to the implementor and/or operator.
My hesitation here is that if it is a SHOULD, then I think the document would need a bit more detail regarding what ‘regularly’ means, rather than simply saying the precise behaviour is out of scope. I like to think that when something is specified as a SHOULD then it should be relatively easy to determine if an implementation is compliant with that requirement, and without specifying more detail here I don’t think that would be easy. Do you have any thoughts on that? IIRC there were some discussions among the authors about this prior to the -02 version and we deliberately left this out because how to time these subsequent signals isn’t obvious. However maybe this isn’t really necessary and the above text is acceptable. A couple of details to consider: 1) If the client is regularly sending messages with an EDNS0 OPT RR, then the server can respond to these by adding the edns-tcp-keepalive option and there is no need for the client to specifically send the edns-tcp-keepalive option in the query. See Section 3.3.2: A DNS server that receives a query sent using TCP transport that includes an OPT RR MAY include the edns-tcp-keepalive option in the response to signal the expected idle timeout on a connection. 2) Also, it is perfectly possible that a client opens a connection, sends a single message but does not have any further queries for that server before the timeout expires. I don’t think there is any desire to have clients send ‘fake’ heartbeat-like messages to check on the timeout during the idle period, so I think it would be useful to clarify that. The best wording I can come up with to try to cover this is: If a client includes the edns-tcp-keepalive option in the first query, it SHOULD include an EDNS0 OPT RR periodically in any further messages it sends during the TCP session. This will increase the chance of the client being notified should the server modify the timeout associated with a session. Regards Sara.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
