Re: Fwd: New Version Notification for draft-wouters-edns-tcp-chain-query-00.txt
"Dickson, Brian" <[email protected]>
| Newsgroups | gmane.ietf.dnsext |
|---|---|
| Message-ID | <CE562142.D2CE%[email protected]> |
Top-reply (sorry) - agree, sounds great, willing to review and/or contribute ideas/text. BTW - suggestion: include (from the server) info about maximum idle time of an open connection. E.g. no guarantees if you try to use this without keepalives and after 5 minutes has passed. This will often correspond to reaping state on state-ful load balancers. Knowing $REAP_TIME may make operational improvements on implementations where the option has been negotiated. Unusual values of $REAP_TIME may even suggest altering the keep-alive interval on the TCP socket, per server. Brian On 9/11/13 1:00 PM, "Joe Abley" <[email protected]> wrote: >Hey, > >Having now spent more than 15 seconds thinking about this... > >On 2013-09-11, at 11:54, Paul Wouters <[email protected]> wrote: > >> On Wed, 11 Sep 2013, Dave Lawrence wrote: >> >>> It would be useful to have a way to negotiate the TCP connection >>> behavior, including options like signalling that the server may close >>> the connection as soon as the response is sent, or that the client >>> wants to send more than one request. I don't think this meaning >>> should be bundled into the DNSSEC chain query option, however. >> >> I've heard several people tell me this now and I agree. The question is: >> >> 1) do we want to clarify in a separate draft that the TCP connection >> can remain open for re-use? > >Given that this apparently breaks assumptions already present in >widely-deployed software, that sounds like an uphill battle. > >> 2) do we want to use another edns0 option to ask the server to keep the > >> TCP connection, which the server indicates by returning this option >> in its TCP reply? > >I think yes, and upon >15 seconds of reflection I can't think of a reason >why you'd want such an option to be more general than this specific >functionality. Other transport-related signalling can use different edns0 >options. > >> It seems to be 2) is probably a better idea, and I'm happy to write that >> up in a separate document. > >Agree. > > >Joe >_______________________________________________ >dnsext mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/dnsext _______________________________________________ dnsext mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsext