On Tue, Jan 21, 2020 at 6:46 AM Vittorio Bertola <vittorio.bertola= [email protected]> wrote:
> > > Il 20/01/2020 22:45 Eric Vyncke (evyncke) <[email protected]> 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 > [email protected] > Office @ Via Treviso 12, 10144 Torino, Italy > > _______________________________________________ > dns-privacy mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dns-privacy >
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
