Hi Peter, DPRIVE folks-- On Thu 2022-02-03 11:03:35 +0100, Peter van Dijk wrote: > Speaking only for myself: some of the parts still seem too prescriptive > to me (but I know I haven't been clear on what parts!). Examples: 4.3.1 > seems too focused on some specific load balancer implementations, and > causes a terrible combinatorial state explosion.
§4.3.1 ("Separate State for Each of the Recursive Resolver's Own IP
Addresses") was added specifically in response to concerns raised by
load balancer operators, in coordination with §3.1 (guidance to the pool
operators themselves), with a goal of convincing anyone interested that
the system isn't going to be overwhelming as long as everyone involved
sticks to a few simple and plausible guidelines.
I don't think that there is a combinatorial state explosion here --
every system that queries from a different outbound address just keeps
its own copy of its state, no? This seems no worse than having to track
established connections based on which local IP address they are
attached to, which is pretty standard.
It's possible that some other set of choices can offer equally
unthreatening system analysis, but if we're proposing an alternative, we
should write it down explicitly so that people can identify potential
problems. Being able to reason about the system as a whole is an
important part of this kind of description.
> 4.5 could perhaps use some words along the lines of "we describe an
> algorithm here; you could use another algorithm if it fits your
> implementation better, as long as it has similar outcomes". I do like
> that it mentions happy eyeballs without prescribing them.
Thanks, this is useful feedback too.
I think the goal of the draft is to concretely describe a specific
algorithm so that implementers don't have to invent one from scratch.
I'm happy with the terminology you use above, with the slight caveat that
we'd want to be pretty clear about what "similar outcomes" means. In
particular, i want "similar outcomes" to encompass not only "did the end
user get the right data?" and "did the proportion of
recursive-to-authoritative queries that was served under encrypted
transport actually improve?" but also "does the alternate algorithm
discourage authoritative servers from deploying secure transport?" and
"will you be able to integrate signalling mechanisms for stronger
connections when they become available"?
One reason to be concerned about divergence from the described approach
is if it interacts poorly with someone else's *different* divergence
from approaches described in the draft, for example the guidance around
operating and dealing with pools that we're discussing above ☺
> Speaking for both myself and Paul Hoffman: we are happier with your
> document than with our currently adopted work. We strongly suggest that
> the WG adopts unilateral-probing so we can work out what it would take
> to get some implementation work going.
Thanks for the vote of confidence! I know that Joey and i would both be
fine with WG adoption of this draft, and I think we'd both be game to
volunteer to continue on as editors were the WG to take over authorship.
We'd also be fine with having an additional editor or two on the draft
if someone is interested in stepping up and game to share the workload.
Joey, please correct me if i'm misrepresenting you on any of this!
--dkg
signature.asc
Description: PGP signature
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
