Subject: [dns-privacy] Call for Adoption: draft-dickinson-dprive-bcp-op

From: Tim Wicinski <[email-masked]>
Date: Wed, 18 Jul 2018 14:14:21 -0400

This starts a Call for Adoption for draft-dickinson-dprive-bcp-op

The draft is available here:
https://datatracker.ietf.org/doc/draft-dickinson-dprive-bcp-op/

Please review this draft to see if you think it is suitable for adoption
by DPRIVE, and comments to the list, clearly stating your view.

Please also indicate if you are willing to contribute text, review, etc.

This call for adoption ends: 3 August 2018

Thanks,
DPRIVE co-chair

---

From: Barry Raveendran Greene <[email-masked]>
Date: Wed, 18 Jul 2018 14:25:18 -0400

I support the adoption of this work into the WG. 

> On Jul 18, 2018, at 14:14, Tim Wicinski <[email-masked]> wrote:
> 
> 
> The draft is available here: https://datatracker.ietf.org/doc/draft-dickinson-dprive-bcp-op/
> 
> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy

---

From: Jim Reid <[email-masked]>
Date: Wed, 18 Jul 2018 19:33:10 +0100

> On 18 Jul 2018, at 19:25, Barry Raveendran Greene <[email-masked]> wrote:
> 

+1

---

From: Dan York <[email-masked]>
Date: Wed, 18 Jul 2018 18:48:29 +0000

> On Jul 18, 2018, at 2:14 PM, Tim Wicinski <[email-masked]> wrote:
> 
> 
> The draft is available here: https://datatracker.ietf.org/doc/draft-dickinson-dprive-bcp-op/ <https://datatracker.ietf.org/doc/draft-dickinson-dprive-bcp-op/>
> 

I support the adoption of the document. I think it provides useful operation guidance to operators looking to implement the protocols and mechanisms being implemented in DPRIVE and other groups.

As I stated at the mic at IETF 102, I do feel like the section on creating a "DNS Privacy Policy and Practice Statement" (DPPPS) could be split out into a separate document. My rationale was that:

1. It is a couple of pages of content after 17 pages of more operational guidance;
2. I could see a different audience for a document creating a DPPPS. I could see someone being tasked with going and creating such a policy for an operator - who might be different from the people implementing the other parts of the document; and
3. The DPPPS guidance *might* be more static and therefore a separate document would not need revision while operational guidance might.

However, I'm also sympathetic to the view that it makes sense to keep it all together during these earlier days and because operators will need to create DPPPS documents.  Splitting it out *might* be something to consider as the document continues to evolve, but for now I'm fine leaving it in.

Dan

--
Dan York
Director, Content & Web Strategy, Internet Society
[email-masked]   +1-802-735-1624 
Jabber: [email-masked]  Skype: danyork   http://twitter.com/danyork

http://www.internetsociety.org/

---

From: Amelia Andersdotter <[email-masked]>
Date: Wed, 18 Jul 2018 20:56:23 +0200

+1 on adoption

On 2018-07-18 20:48, Dan York wrote:
>
>
>> On Jul 18, 2018, at 2:14 PM, Tim Wicinski <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>>
> I support the adoption of the document. I think it provides useful
> operation guidance to operators looking to implement the protocols and
> mechanisms being implemented in DPRIVE and other groups.
>
> As I stated at the mic at IETF 102, I do feel like the section on
> creating a "DNS Privacy Policy and Practice Statement" (DPPPS) could
> be split out into a separate document. My rationale was that:
>
> 2. I could see a different audience for a document creating a DPPPS. I
> could see someone being tasked with going and creating such a policy
> for an operator - who might be different from the people implementing
> the other parts of the document; and
> 3. The DPPPS guidance *might* be more static and therefore a separate
> document would not need revision while operational guidance might.
>
> However, I'm also sympathetic to the view that it makes sense to keep
> it all together during these earlier days and because operators will
> need to create DPPPS documents.  Splitting it out *might* be something
> to consider as the document continues to evolve, but for now I'm fine
> leaving it in.
>

Standardised privacy notices (policy+practise) have been studied in
other cases, and are of course useful for overviews (by consumers,
researchers, more broadly etc). See e.g.
https://dl.acm.org/citation.cfm?id=2911988

One could object the source of the requirements on the notices is not
the technical community, but I think the study pretty much exemplifies
what the utlity is of taking the approach of this draft and include it.

Cranor in general has done a lot of work on privacy notices, from a
particular jurisdictional perspective, I guess:
https://scholar.google.com/citations?hl=en&user=kIUqgbcAAAAJ&view_op=list_works&sortby=pubdate

best regards,

Amelia

> [email-masked] <mailto:[email-masked]>   +1-802-735-1624 
> Jabber: [email-masked] <mailto:[email-masked]>
>  Skype: danyork   http://twitter.com/danyork
>

-- 
Amelia Andersdotter
Technical Consultant, Digital Programme

ARTICLE19
www.article19.org

PGP: 3D5D B6CA B852 B988 055A 6A6F FEF1 C294 B4E8 0B55

---

From: "Paul Hoffman" <[email-masked]>
Date: Wed, 18 Jul 2018 16:21:19 -0400

Yes, please!

--Paul Hoffman

---

From: Ulrich Wisser <[email-masked]>
Date: Wed, 18 Jul 2018 23:49:05 +0100

+1

Paul Hoffman <[email-masked]> schrieb am Mi., 18. Juli 2018 um

-- 
Ulrich Wisser
[email-masked]

---

From: Matthijs Mekking <[email-masked]>
Date: Mon, 23 Jul 2018 09:24:20 +0200

>> I support the adoption of this work into the WG.

+1 more