[Gnso-epdp-team] Purpose 2

Alan Woods alan at donuts.email
Thu Mar 5 15:41:46 UTC 2020


The pedant in me demands that I note "Officious" not "Auspicious"
bystander ... That would have eaten me alive! :D

[image: Donuts Inc.] <http://donuts.domains>
Alan Woods
Senior Compliance & Policy Manager, Donuts Inc.
------------------------------
Suite 1-31,
Block D, Iveagh Court
Harcourt Road
Dublin 2, County Dublin
Ireland

<https://www.facebook.com/donutstlds>   <https://twitter.com/DonutsInc>
<https://www.linkedin.com/company/donuts-inc>

Please NOTE: This electronic message, including any attachments, may
include privileged, confidential and/or inside information owned by Donuts
Inc. . Any distribution or use of this communication by anyone other than
the intended recipient(s) is strictly prohibited and may be unlawful.  If
you are not the intended recipient, please notify the sender by replying to
this message and then delete it from your system. Thank you.


On Thu, Mar 5, 2020 at 2:27 PM Alan Woods <alan at donuts.email> wrote:

> HI all,
>
> I truly cannot believe we are still having the same conversations
>
> Let me 1st  deal with Alan's statement re "SOME 3rd party requests are in
> fact in support of ICANN's mission"
>
> Agreed, Alan. "Support" - not "contracted to", not "obliged to" or not
> anything that denotes that they are in any way an actual legal and direct
> part of the data processing which we have been discussing for years now.
> These 3rd parties maintain their own, completely separate , possibly quite
> aligned, purposes to us. They may share a goal, an Ideal or a mission, but
> they are legal strangers to this CLOSED data processing ecosystem. By
> continuously invoking their aligned but legally separate 'purposes' - that
> is conflation.
>
>
> For the wider questions, I think we need to be crystal clear here. I think
> we need to call out 3 very important things are causing a lot of
> misunderstandings both in the past week and indeed beyond:
>
>
> *1) IS SSR a purpose?:*
>
> The URS is a purpose. The UDRP is a purpose. Contacting a registrant to
> deal with issues with the Domain, is a purpose: but let's be clear SSR is
> far bigger than a mere purpose. To be especially clear,  nothing the EPDP
> will do or say, can change that, as it is enshrined at ICANN's core.
>
> ICANN (Community, org, GNSO process) may decide to process data in a
> manner that they believe is reasonable for the protection of SSR. They
> don't need the EPDP's permission to do so.
>
> To draw a clumsy analogy, (bear with me) Think of SSR as a very large
> building. That building has rooms that make up the individual efforts (such
> as the URS, UDRP, Spec 11 (3)b etc.)  These rooms are the purposes which
> must be described on our policy. - a visitor to the 'SSR building' may look
> at the building but they will have no idea of what's in there or where they
> are supposed to go. They consult the building directory/map ( which is the
> privacy policy) and they can see which rooms are in that building and more
> importantly what each room contains.
>
> Weird analogy aside, as an example. the processing of data for URS or UDRP
> - this is a tangible thing that has stated rules, processes, procedures  -
> all of which try to outline the use of any personal data in that process.
> The URS and the UDRP are without a doubt a part of the SSR efforts of the
> community,  but were I but an auspicious bystander - If I was merely told
> that my data will be used for the purposes of SSR ... and not told
> specifically about the URS / UDRP,  I would be utterly clueless as how my
> data may be used. That is the very problem we apparently are stuck on here
> - SSR grounds a purpose - but it is not a purpose in it's own right.
>
>
> *NOTE: just seeing Hadia's email now - her suggestion to further define a
> purpose with further purposes - is EXACTLY the point here, and why Purpose
> 2 is considered far too broad to be effective. *
>
>
> 2) * If SSR is not stated as a 'purpose'*, *then ICANN can't process data
> for SSR*.
>
> *This is absolutely not true.*
>
> Policies can continue to be created that add to the efforts to protect the
> SSR. NOTHING stops ICANN and the community from creating any new purposes
> with SSR at its core. To use the building analogy again (sorry) - The
> Building is the Bylaws -It's already built -  we can create as many rooms
> in that building as we can imagine, as long as they are up the Building's
> standards and where there will be people staying in those rooms, that they
> meet the GDPR building regulations (including giving all existing tenants
> notice of the new rooms).
>
> We should also note that where policy necessitates a change to the manner
> in which the CPs or ICANN handle personal data, then obviously as our
> privacy policies are not governed by consensus policy, but any competent
> data controller, would merely ensure a process of registrant notification
> and necessary updates to our individual privacy policies. Again this is not
> a block to us implementing additional data processing, just that we need to
> ensure that we fulfil our legal obligations to inform the data subjects
> appropriately about the change, impact etc..
>
> ICANN holds a very unique and very strong position to sponsor and enforce
> such policy creation, not because the EPDP somehow granted a 'purpose to
> create purposes for SSR' - but because it is the actual mission and reason
> for being of ICANN as is helpfully enshrined in its bylaws and mission..
>
> *Finally and this is as HUGE one*
>
> 3) *Nothing in the conversation relating to Purpose II, affects or is
> intended to affect, or in ANY WAY prevent the SSAD from occurring.*
>
> That is completely separate. SSAD is the operationalization of a process
> for disclosure of data to third parties. That remains completely possible *regardless
> of Purpose II or NOT *- we do not need to create a purpose to disclose
> data to 3rd parties - that's the way the law is written. Phase II is
> defining this process for disclosure, making a process that currently
> EXISTS (in reality and as permitted by law) so that it is in a more
> streamlined and predictable manner. Any suggestion otherwise is simply not
> true.
>
>
> Sorry about the length as per usual, but I think we need to move past
> certain assumptions, so that we can focus on our actual task at hand.
>
> Thank you!
>
>
>
>
>
> [image: Donuts Inc.] <http://donuts.domains>
> Alan Woods
> Senior Compliance & Policy Manager, Donuts Inc.
> ------------------------------
> Suite 1-31,
> Block D, Iveagh Court
> Harcourt Road
> Dublin 2, County Dublin
> Ireland
>
> <https://www.facebook.com/donutstlds>   <https://twitter.com/DonutsInc>
> <https://www.linkedin.com/company/donuts-inc>
>
> Please NOTE: This electronic message, including any attachments, may
> include privileged, confidential and/or inside information owned by Donuts
> Inc. . Any distribution or use of this communication by anyone other than
> the intended recipient(s) is strictly prohibited and may be unlawful.  If
> you are not the intended recipient, please notify the sender by replying to
> this message and then delete it from your system. Thank yo
>
> On Thu, Mar 5, 2020 at 10:41 AM Volker Greimann <vgreimann at key-systems.net>
> wrote:
>
>> I fully agree with your first sentence. For this reason, specificity of
>> the actual purposes is required instead of the blanket statement proposed
>> up to now.
>>
>> Ultimately, any ICANN purpose must be specifically defined by the
>> questions of what is collected for what specific purpose for and with whom
>> it may be shared.
>>
>> Say we take escrow as a purpose, which is likely univerally agreed as a
>> valid ICANN purpose:
>>
>> ICANN will collect registration data to: protect the ownership of a data
>> subject in his registered domain names in case of a registry or registrar
>> failure or de-accreditation. For this purpose, the data may be shared with
>> escrow service providers x,y,z (and potentially others) as well as other
>> contracted parties who may be assigned to take over the management of the
>> affected domain name registrations.
>>
>> The language is not perfect, but I hope this illustrates the level of
>> specificity I am seeking here. If ICANN has purposes (and I think we agree
>> that it does), we need to specify these purposes by saying what, how and
>> why.
>>
>> Best,
>>
>> Volker
>>
>>
>>
>> Am 05.03.2020 um 11:21 schrieb Hadia Abdelsalam Mokhtar EL miniawi:
>>
>> We need not forget that data subjects need to know with whom their data
>> might be shared and for what purposes. To this end purpose 2 is important
>> as it establishes one core purpose for processing the data related to
>> ICANN's mission and stated in its bylaws. Also in the EC letter to Joran in
>> May 2019 under purposes of processing and access model, the EC say "For
>> this reason we would recommend revising the formulation of purpose two by
>> excluding the second part of the purpose "through enabling responses to
>> lawful data disclosure requests" and maintaining a broader purpose "
>> Contribute to the maintenance of the security, stability and resiliency of
>> the Domain Name System in accordance with ICANN's mission"
>>
>>
>>
>> This was the recommendation of the EC to us in May 2019, the question now
>> is why don't we want to follow this recommendation? Maintaining the SSR of
>> the internet is ICANN's core mission and is indeed a purpose for which data
>> might be processed why don't we want to be clear about this.
>>
>>
>>
>> Hadia
>>
>> *From:* Gnso-epdp-team [mailto:gnso-epdp-team-bounces at icann.org
>> <gnso-epdp-team-bounces at icann.org>] *On Behalf Of *Alan Greenberg
>> *Sent:* Thursday, March 05, 2020 2:18 AM
>> *To:* Margie Milam; brian.kingATmarkmonitor.com; gnso-epdp-team at icann.org
>> *Subject:* Re: [Gnso-epdp-team] Purpose 2
>>
>>
>>
>> I have to agree with Margie. These are all important things and we cannot
>> be left at some later date being told that we cannot do this because it was
>> never mentioned to registrants.
>>
>> I could live with a much more general statement, but we have been told by
>> the CPH that they need something less vague to put in their policies to
>> registrants.
>>
>> Although I do not believe there is any merit in pursuing it, I will
>> restate that SOME 3rd party requests are in fact in support of ICANN's
>> mission (those that directly protect the SSR of the DNS) and I believe that
>> the statement that we were conflating 3rd-party purposes with our own was
>> partially in error.
>>
>> Alan
>>
>> At 04/03/2020 05:50 PM, Margie Milam wrote:
>>
>>
>> We support Brian’s proposed Purpose 2 below, and note that without it –
>> theere are many gaps, including:
>>
>>    - Operationalizing and implementing new policies and contract
>>    provisions (RDAP, transfers, TM Clearinghouse, etc.)
>>    - Conducting research using the contacts
>>    - Coordinating cyber-attack responses such as Conficker & other cyber
>>    attacks
>>    - Publishing Accuracy Reporting System (ARS) reports
>>    - Conducting testing of new registrar/registries to ensure that the
>>    WHOIS systems work in the manner required by the contract
>>    - Implementing & testing escrow deposits with 3rd party escrow
>>    providers
>>
>>
>> All the best,
>>
>> Margie, Mark & Steve
>> On behalf of the BC
>>
>>
>>
>> *  Margie Milam *IP Enforcement & DNS Policy Lead | Facebook Legal
>> NOTICE: This email (including any attachments) may contain information
>> that is private, confidential, or protected by attorney-client or other
>> privilege.  Unless you are the intended recipient, you may not use, copy,
>> or retransmit the email or its contents.
>>
>>
>>
>> *From: *Gnso-epdp-team <gnso-epdp-team-bounces at icann.org>
>> <gnso-epdp-team-bounces at icann.org> on behalf of "King, Brian via
>> Gnso-epdp-team" <gnso-epdp-team at icann.org> <gnso-epdp-team at icann.org>
>> *Reply-To: *"brian.kingATmarkmonitor.com" <brian.king at markmonitor.com>
>> <brian.king at markmonitor.com>
>> *Date: *Wednesday, March 4, 2020 at 10:12 AM
>> *To: *"gnso-epdp-team at icann.org" <gnso-epdp-team at icann.org>
>> <gnso-epdp-team at icann.org> <gnso-epdp-team at icann.org>
>> *Subject: *[Gnso-epdp-team] Purpose 2
>>
>> Hi all,
>>
>> Following last week’s conversation about some EPDP members’ desire to
>> have a bit more specificity in Purpose 2 (the irony of which is not lost on
>> the IPC ), I propose the below:
>>
>> Contributing to the maintenance of the security, stability, and
>> resiliency of the Domain Name System in accordance with ICANN’s mission,
>> specifically “maintenance of and access to accurate and up-to-date
>> information concerning registered names and name servers.†(ICANN Bylaws,
>> Annex G-1; ICANN Bylaws, Annex G-2)
>>
>> *Brian J. King *
>> Director of Internet Policy and Industry Affairs
>>
>> T +1 443 761 3726
>> markmonitor.com
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.markmonitor.com&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=_4XWSt8rUHZPiRG6CoP4Fnk_CCk4p550lffeMi3E1z8&m=Q65Or6H39_7X6LJk1SN78sszy_Hne8qlISmI8kN7Wh8&s=72C7v9XA12IEQxdYxgz5IDlXPMnrRUz4uW6aDcYmwcU&e=>
>>
>>
>> *MarkMonitor *Protecting companies and consumers in a digital world
>>
>> _______________________________________________
>> Gnso-epdp-team mailing list
>> Gnso-epdp-team at icann.org
>> https://mm.icann.org/mailman/listinfo/gnso-epdp-team
>> _______________________________________________
>> By submitting your personal data, you consent to the processing of your
>> personal data for purposes of subscribing to this mailing list accordance
>> with the ICANN Privacy Policy ( https://www.icann.org/privacy/policy)
>> and the website Terms of Service ( https://www.icann.org/privacy/tos).
>> You can visit the Mailman link above to change your membership status or
>> configuration, including unsubscribing, setting digest-style delivery or
>> disabling delivery altogether (e.g., for a vacation), and so on.
>>
>> _______________________________________________
>> Gnso-epdp-team mailing listGnso-epdp-team at icann.orghttps://mm.icann.org/mailman/listinfo/gnso-epdp-team
>> _______________________________________________
>> By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
>>
>> --
>> Volker A. Greimann
>> General Counsel and Policy Manager
>> *KEY-SYSTEMS GMBH*
>>
>> T: +49 6894 9396901
>> M: +49 6894 9396851
>> F: +49 6894 9396851
>> W: www.key-systems.net
>>
>> Key-Systems GmbH is a company registered at the local court of
>> Saarbruecken, Germany with the registration no. HR B 18835
>> CEO: Alexander Siffrin
>>
>> Part of the CentralNic Group PLC (LON: CNIC) a company registered in
>> England and Wales with company number 8576358.
>> _______________________________________________
>> Gnso-epdp-team mailing list
>> Gnso-epdp-team at icann.org
>> https://mm.icann.org/mailman/listinfo/gnso-epdp-team
>> _______________________________________________
>> By submitting your personal data, you consent to the processing of your
>> personal data for purposes of subscribing to this mailing list accordance
>> with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and
>> the website Terms of Service (https://www.icann.org/privacy/tos). You
>> can visit the Mailman link above to change your membership status or
>> configuration, including unsubscribing, setting digest-style delivery or
>> disabling delivery altogether (e.g., for a vacation), and so on.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-epdp-team/attachments/20200305/e33230a3/attachment-0001.html>


More information about the Gnso-epdp-team mailing list