Hi dkg, Peter, dprive,
On Thu, Feb 3, 2022 at 7:00 PM Daniel Kahn Gillmor <[email protected]>
wrote:
> 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.
>
+1, other perspectives can (and some already have) be(en) included. I think
that if the text starts getting too specific or unclear for different
implementations, then a generalization could be kept in the main text and
implementation-specific guidelines could populate the Appendix, but it has
indeed been a goal of us to cover enough scenarios as to dissuade
hesitation to adopt/implement.
> 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.
>
Very!
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"?
>
+1, we could then possibly add a section covering these "similar outcomes"
at some point
> > 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.
>
Thank you for the support! I'm also fully onboard with the draft going for
adoption and with all subsequent WG decisions, remaining available in any
capacity as needed : )
Thank you all,
--
Joey
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
