On 7 Oct 2014, at 18:27, Tim Wicinski <[email protected]> wrote: > All > > We have two drafts expiring shortly and I wanted to get the sense of the > working group. > > These are the two EDNS extensions worked on by Mr. Paul Wouters. They > initially had no home, and we gave them a home, and there was a lot of > discussion around them, and paul turned these documents several times to > address issues. > > DNSOP went and got their charter changed, to address work like this. Since > then we've had no discussion on them. However, I am confident that the > previous rounds gave these documents a strong vetting. They have been adopted > as working group documents some time ago. > > The documents are: > > https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-chain-query/ > > https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-tcp-keepalive/
I do NOT support adoption of edns-tcp-keepalive. It appears to be a solution for a problem that does not exist, based on a misunderstanding of how TCP clients and servers are already supposed to interact and a misrepresentation of the recommended shortening of the standard timeout for TCP sessions that happened in RFC 5966. The latter is mentioned in the abstract where the draft asserts this makes "making use of TCP only suitable for individual queries generated as a fallback protocol for truncated UDP answers”. This assertion is not supported (or even mentioned) anywhere else in the text. Like HTTP/1.1, DNS over TCP sessions should _already_ be considered persistent, albeit with shorter timeouts since RFC 5966 (I see that Apache 2.2 uses a 5 second timeout). There’s no need to use an option to ask for it, nor IMHO any need for the value of the timeout to be communicated between client and server (or vice versa). There’s a small group of us that are looking at an update to 5966 to reflect lessons learnt since that was published in August ’10 and to propose further clarifications. On discussion with one of that group a few days ago the primary missing feature I could see relating to socket handling in TCP over DNS was an analogue of the HTTP/1.1 “Connection: close” flag from server to client - in effect the server asking the client nicely to close the connection from its end. This puts the TCP TIME_WAIT burden on the client instead of the server and could be trivially accomplished with a single bit flag in the EDNS flags. kind regards, Ray _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
