Subject: [dns-privacy] Roman Danyliw's No Objection on draft-ietf-dprive-rfc7626-bis-06: (with COMMENT)

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Wed, 07 Oct 2020 05:44:37 -0700

Roman Danyliw has entered the following ballot position for
draft-ietf-dprive-rfc7626-bis-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dprive-rfc7626-bis/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for responding to the SECDIR review (and thank you to Stephen Farrell
for performing the SECDIR review).

** Section 3.5.1.1.  Per “These resolvers may have strong, medium, or weak
privacy policies …”, what are the dimensions of this Likert-style scale?  I
recommend a simpler sentence -- “… may have varied privacy policies”.

** Section 6.1.1.  Per “All major OS's expose the system DNS settings and allow
users to manually override them if desired”, agreed.  However, in managed
environments, users may not be able to manually override these settings.

** Section 6.1.3.  Per “User privacy can also be at risk if there is blocking
(by local network operators or more general mechanisms) …”, what is a “more
general mechanism”?  Also, "local network operator" describes who is doing the
blocking and "general mechanisms" seems to be describing a technique.

** Section 8.  Editorial.  Per “They are used for many reasons – some good,
some bad.”, I’d recommend against making judgements and stick to a rubric of
operational practices and attacker behavior (say RFC7258).  I’m not sure this
sentence is needed.

Editorial nits

-- ** Section 6.1.1.  Editorial.  s/additionally highly dependent/highly
dependent/

-- Section 12.  Typo. s/apprecriated/appreciated/

---

From: Tim Wicinski <[email-masked]>
Date: Thu, 8 Oct 2020 20:01:26 -0400

> https://datatracker.ietf.org/doc/draft-ietf-dprive-rfc7626-bis/
Ok, i've made that change.

> environments, users may not be able to manually override these settings.
Yes. I am leaving this open for now.

> blocking and "general mechanisms" seems to be describing a technique.
I removed the comment in parenthesis

> operational practices and attacker behavior (say RFC7258).  I’m not sure

Ok, I've dropped it.

> -- Section 12.  Typo. s/apprecriated/appreciated/

fixed

thanks
tim