Re: [dns-privacy] Datatracker State Update Notice: <draft-ietf-dprive-rfc7626-bis-04.txt>

On Tue, Jan 21, 2020 at 6:46 AM Vittorio Bertola <vittorio.bertola=
40open-xchange.com@dmarc.ietf.org> wrote:

>
> > Il 20/01/2020 22:45 Eric Vyncke (evyncke) <evyncke@cisco.com> ha
> scritto:
> >
> > But, as section 3.5.1 ("in the recursive resolvers") raised a lot of
> discussions during the first IETF Last Call, and as the authors reacted to
> those comments by deep changes in the text, let's have a new IETF Last Call
> before proceeding with IESG evaluation.
>
> First of all, I'd like to thank Sara for all the effort in rewriting a lot
> of text yet another time to address all the comments. I think the result is
> good, even if I would have preferred other text on certain things.
>
> There is only a minor comment that I still have on 3.5.1. The new version
> has a part about DNS centralization risks, but it only addresses the risks
> deriving from the ISP market, not the newer ones coming from
> "application-specific resolver selection", which were mentioned in -03. I
> have two alternative text proposals to cover this:
>
> 1) in the bullet list in 3.5.1.1, add another bullet:
>
> "* popular applications directing DNS traffic by default to specific
> dominant resolvers"
>
> or
>
> 2) in 3.5.1.1.2., last paragraph, just after "increase or decrease user
> privacy" and before the hyphen, add:
>
> "and promote or counter centralization"
>
> Given Eric's (not Éric's :-) ) comment on the requirements for user
> control in 3.5.1.1.2, i.e. that they also apply to the selection of
> non-encrypted resolvers today, it would be fine for me if they were
> extended to device/OS resolver configuration in general. In that case, I
> would plead for the addition of a point regarding the fact that the user
> should be enabled to configure the resolver for the OS and all the
> applications at once, in a single place.
>

I would not be in favor of this. It's squarely in the zone of controversy.

-Ekr

> I also have an editorial suggestion: to reduce the nesting of sub-sections
> in 3.5, perhaps you could break down section 3 into multiple first-level
> sections and do some renumbering, e.g.
>
> 3. -> 3.
> 3.1, 3.2, 3.3 -> 4.1, 4.2, 4.3 within "4. Risks in the DNS data"
> 3.4 -> "5. Risks on the wire"
> 3.5 -> "6. Risks in the servers"
> 3.6, 3.7 -> 7.1, 7.2 within "7. Other risks"
>
> In any case, I think that we now have a solid document and hope we can
> release it soon.
>
> --
>
> Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
> vittorio.bertola@open-xchange.com
> Office @ Via Treviso 12, 10144 Torino, Italy
>
> _______________________________________________
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>