On Thu, 15 Dec 2016 10:09:16 +0100, Stephane Bortzmeyer wrote: >On Wed, Dec 14, 2016 at 08:57:56AM -0800, > John Heidemann <[email protected]> wrote > a message of 49 lines which said: > >> There's a bunch of possible trade-offs: client latency, server >> memory, client memory, novelty vs. maturity of design, maturity of >> libraries, support by other groups, design complexity, ... > >Added to the future next version of the draft ><https://github.com/bortzmeyer/ietf-dprive-step-2/commit/5779cbf94605fbcd174bd5d57544150fc636e620>
If you're updating, you might also add out protocol agility, something else that has come up in this thread and before. >> You suggested earlier in the thread that rfc7858 was weaker than >> some alternatives for recurisive-to-auth traffic, so I was trying to >> figure out for which metrics you think it is weaker. > >The point was raised by Mukund Sivaraman at the Seoul meeting. If I >remember correctly, his main concern was the state to keep in the >client, because a resolver will talk to hundreds, even thousands of >authoritative name servers. Thank you---state for outgoing connections on a recursive resolver could be an issue, and to my knowledge it has not been studied yet. My initial guess is it's not much different from state for incoming connections on a large authoritative, and that resource limits can be handled the same way (start closing when you're low on resources). But a careful study here would be useful. And of course, there is still state on the recursive resolver if queries are sent over DTLS or IPsec, it's just different state in a slightly different place in the stack. -John Heidemann _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
