** Comments
* Section 5.3.1
> If operators do offer a service that sends the ECS options upstream
>   they should use the shortest prefix that is operationally feasible
>   (NOTE: the authors believe they will be able to add a reference for
>   advice here soon) and ideally use a policy of whitelisting upstream
>   servers to send ECS to in order to minimize data leakage.  Operators
>   should make clear in any policy statement what prefix length they
>   actually send and the specific policy used.
Whitelisting instead of automatically detecting ECS on authoritative
servers has much more overhead.

* Section 6.2.5. Comparison
For the comparison tables [8, 9] on github, I will discuss with you
directly about Google Public DNS.

** Minor Comments

* Section 5.2.1
> Data access should be minimized to only those personal who require
>       access to perform operational duties.
personal -> personnel

* Section 5.3.2
> At the time of writing there are no standardized or widely recognized
>    techniques to preform such obfuscation or bulk pre-fetches.
preform -> perform

On Mon, Jul 2, 2018 at 1:59 PM Sara Dickinson <[email protected]> wrote:
>
> Hi All,
>
> An update to draft-dickinson-bcp-op (with a minor name change generating a 
> -00 version) is now available.
>
> The major differences to draft-dickinson-bcp-op-00 are :
>
> * Reworked the Terminology, Introduction and Scope
> * Added Document section
> * Reworked the Recommendations section to describe threat mitigations, 
> optimizations and other options.
> * Split the recommendations up into 3 subsections: on the wire, at rest and 
> upstream
> * Added much more information on data handling and IP address 
> pseudonymization and anonymization
> * Added more details and comparison of some existing policy/privacy policies
> * Applied virtually all of Amelia Andersdotter's suggested changes.
>
> When re-writing this draft in terms of privacy threats and mitigations it 
> became clear that a ‘bis' to RFC7626 that included threat assessments from 
> all the privacy related work that has happened since it was written (e.g. 
> DNS-over-TLS) would be very helpful. That bis document is also now available 
> (see below) and going forward the hope is the these two will be companion 
> documents with RFC7626-bis describing the threats and the BCP describing the 
> mitigations.
>
> When reviewing, please note that due to time constraints I haven’t managed to 
> get the cross references to the very latest draft versions updated in the 
> documents, but will do so when draft submission re-opens.
>
> Best regards
>
> Sara.
>
>
> Begin forwarded message:
>
> From: [email protected]
> Subject: New Version Notification for draft-dickinson-dprive-bcp-op-00.txt
> Date: 2 July 2018 at 18:31:13 BST
> To: "Sara Dickinson" <[email protected]>, "Benno J. Overeinder" 
> <[email protected]>, "Benno Overeinder" <[email protected]>, "Allison 
> Mankin" <[email protected]>, "Roland M. van Rijswijk-Deij" 
> <[email protected]>, "Roland van Rijswijk-Deij" 
> <[email protected]>
>
>
> A new version of I-D, draft-dickinson-dprive-bcp-op-00.txt
> has been successfully submitted by Sara Dickinson and posted to the
> IETF repository.
>
> Name: draft-dickinson-dprive-bcp-op
> Revision: 00
> Title: Recommendations for DNS Privacy Service Operators
> Document date: 2018-07-02
> Group: Individual Submission
> Pages: 32
> URL:            
> https://www.ietf.org/internet-drafts/draft-dickinson-dprive-bcp-op-00.txt
> Status:         
> https://datatracker.ietf.org/doc/draft-dickinson-dprive-bcp-op/
> Htmlized:       https://tools.ietf.org/html/draft-dickinson-dprive-bcp-op-00
> Htmlized:       
> https://datatracker.ietf.org/doc/html/draft-dickinson-dprive-bcp-op
>
>
> Abstract:
>   This document presents operational, policy and security
>   considerations for DNS operators who choose to offer DNS Privacy
>   services.  With the recommendations, the operator can make deliberate
>   decisions which services to provide, and how the decisions and
>   alternatives impact the privacy of users.
>
>   This document also presents a framework to assist writers of DNS
>   Privacy Policy and Practices Statements (analogous to DNS Security
>   Extensions (DNSSEC) Policies and DNSSEC Practice Statements described
>   in [RFC6841]).
>
>
>
>
> Begin forwarded message:
>
> From: [email protected]
> Subject: New Version Notification for 
> draft-bortzmeyer-dprive-rfc7626-bis-00.txt
> Date: 2 July 2018 at 18:54:30 BST
> To: "Sara Dickinson" <[email protected]>, "Stephane Bortzmeyer" 
> <[email protected]>
>
>
> A new version of I-D, draft-bortzmeyer-dprive-rfc7626-bis-00.txt
> has been successfully submitted by Sara Dickinson and posted to the
> IETF repository.
>
> Name: draft-bortzmeyer-dprive-rfc7626-bis
> Revision: 00
> Title: DNS Privacy Considerations
> Document date: 2018-07-02
> Group: Individual Submission
> Pages: 22
> URL:            
> https://www.ietf.org/internet-drafts/draft-bortzmeyer-dprive-rfc7626-bis-00.txt
> Status:         
> https://datatracker.ietf.org/doc/draft-bortzmeyer-dprive-rfc7626-bis/
> Htmlized:       
> https://tools.ietf.org/html/draft-bortzmeyer-dprive-rfc7626-bis-00
> Htmlized:       
> https://datatracker.ietf.org/doc/html/draft-bortzmeyer-dprive-rfc7626-bis
>
>
> Abstract:
>   This document describes the privacy issues associated with the use of
>   the DNS by Internet users.  It is intended to be an analysis of the
>   present situation and does not prescribe solutions.
>
>
> _______________________________________________
> 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

Reply via email to