(other points, i.e., not TCP mandatory or timeouts) In your previous mail you wrote:
> this means that while it's not ideal, it's not as broken as it could be. > with changes to recommended initiator behaviour, we could make these > existing servers more broken, or we could preserve their present level > of brokenness, but we cannot make them less broken. i'm going to argue, > below, for preserving their present level of brokenness. => IMHO this means we need to introduce a bit of signaling before trying a better behaviour at any side, so legacy initiators and servers are recognized. > i am comfortable with this approach, but i would like to also specify > (in one of the tcp related documents now circulating, or in a new one, > that's a detail) that initiators SHOULD NOT remain connected and idle > unless they are acting under some later specification under which > idleness has been explicitly negotiated. => at the exception of the SOA + xXFR case I don't believe that idling initiators are common today. > obviously, any existing > initiators will not obey the SHOULD NOT, but i would like to preserve > the responders' present level of brokenness by not adding any new TCP > connection idlers until and unless there is a protocol change by which a > responder can signal its willingness to participate in an idle mesh. => I fully agree and fortunately we can publish 3966bis before even adopting one of the signaling proposal. > note that > <http://tools.ietf.org/html/draft-ietf-dnsop-edns-tcp-keepalive-01> is > an example of a protocol revision by which idleness could be explicitly > negotiated. i think a simpler approach could work, like adding one bit > of the EDNS extended-flags mask to say "the sender of this message would > be happy about remaining connected but idle". my reason for thinking > this would be enough is, there's no way to reliably tune specific idle > periods, and a TCP speaker who signals their willingness to remain idle > must also be prepared to close least-recently-used connections when the > pool of potential connections is running dry. => the advantage of the keepalive proposal is the server can give the timeout it wants to use. And a bit carries too few infos, e.g., how to announce the initiator is smart but in this case allows (or wants) the server to close after the response? Thanks [email protected] _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
