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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.