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

[Sara Dickinson <[e-mail]>]

> On 21 Jan 2020, at 14:46, Vittorio Bertola <[e-mail]> wrote:
> 
> 
>> Il 20/01/2020 22:45 Eric Vyncke (evyncke) <[e-mail]> 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.