In your previous mail you wrote: > If you see a use case for the EDNS tcp-keepalive option as originally > discussed, please say so, on the list, by February 4, 2015.
=> I have one (more later). > If you want to pursue the connection-close draft, please say so, on the > list, by February 4, 2015, especially if you're willing to work on it. => I can't see what is the benefit of this proposal because: - RFC 1035 already said the connection close should be initiated by the client - almost all current clients send a single query and close the connection when they receive the response - a server is allowed to close a connection when it wants (more later) BTW the 2 proposals are not incompatible, the first (tcp-keepalive) is just more powerful and can provide the same function than the second (connection-close) with a server sending a zero timeout option (note the draft says 0 codes infinity, IMHO this must be changed). (more details) I don't understand some of the discussion about TCP and out-of-order responses: if a client is sophiticated enough to have more than one query on the fly on a TCP connection I can't believe it doesn't know to map responses to queries using the transaction ID. Nevertheless the next bind code will provide an access-list to disable out-of-order responses (proposed by Mark Andrews during code review) as stupidity is a good example of something without bounds... To come back to the tcp-keepalive option, I believe it is a better alternative for a client than sending junk queries to keep the connection not idle. And it can be used the other ways, i.e., by signaling a smaller timeout, and for the from server to client signaling. Now about the DNS over TCP scaling issue: as I said at the last meeting DNS over TCP won't scale until servers will be allowed to use any timeout they want, including a zero timeout (which means the connection is closed if there is no pending query to read). Regards francis.dup...@fdupont.fr (and also fdup...@isc.org) _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
