Hello, On Thu, 2021-01-21 at 08:54 -0500, Tim Wicinski wrote: > This starts a Working Group Last Call for draft-ietf-dprive-xfr-over-tls > > Current versions of the draft is available here: > https://datatracker.ietf.org/doc/draft-ietf-dprive-xfr-over-tls/ > > The Current Intended Status of this document is: Standards Track > > Please review the draft and offer relevant comments.
I like most of the draft. Some of it seems 'obvious' but often 'obvious' differs from reader to reader, so it's good to be explicit about a lot of things. So, I'm not here to say 'all of this is so obvious that the draft does not need to exist at all'. However, there's one part that bothers me. The 'intermingling' of multiple XFRs over a single connection (which is a SHOULD, not a MUST, so the document 'gets away with it', or conversely, implementations will get away with not implementing it) feels to me like a lot of additional code complexity for a gain that is not clear to me. XFRs are not latency sensitive to the point that TLS setup is an impediment. In other words, I do not think the goal 'minimize the number of TCP connections between a primary and secondary' warrants the complexity of intermingling XFRs. I'd much rather have a few more TCP connections, a few more TLS states, and a much simpler code base. We (PowerDNS) do not think we will implement the parts of the draft that call for such code complexity, and thus, we will serialise XFRs (serial connection reuse does make sense to me) and/or in fact open multiple TLS connections (like we do with TCP today). At least in our code base, TLS setup would never be the bottleneck for transfers anyway. Do any other vendors actually plan to implement such thorough connection reuse, with primaries actually intermingling multiple XFR responses over a single TCP/TLS session, and with secondaries actually firing off several XFR requests on a single connection to receive the zone chunks in whichever order they may come? Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ _______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
