> On 21 Jan 2020, at 14:46, 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"
I’ll add this with a reference to section 3.5.1.1.2 > > 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” Sure. > > 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 don’t disagree that this a desirable feature but since the remit of the document is to describe the current situation, and this option is not available today AFAIK I’m not sure it should be included. I suggested to Ekr that text is added at the start of the second paragraph in this section that says: "Such application-specific setting introduce new control points on the end user device for DNS resolution settings in addition to the historically used system settings.” Would that address your concern? > > 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” I like this suggestion and agree it would make the document structure better - thank you, will update. Sara. _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
