[Gnso-epdp-team] EPDP Consensus Call #1

Kurt Pritz kurt at kjpritz.com
Thu Feb 7 00:06:19 UTC 2019

Hello Everyone: 

Below please find the GAC response to the EPDP Consensus Call #1 - i.e., for the first bundle of recommendations - the Processes for processing registration data. I believe in my email, I asked that responsesbe sent to “me” when I meant that they could be published to the entire team. When I asked, the GAC representatives asked me to forward this on to you. 

Best regards,


> From: "Heineman, Ashley" <AHeineman at ntia.doc.gov>
> Subject: RE: [Gnso-epdp-team] EPDP Consensus Call #1
> Date: February 6, 2019 at 1:07:41 PM PST
> To: Kurt Pritz <kurt at kjpritz.com>
> Cc: "gac-epdp at icann.org" <gac-epdp at icann.org>

Dear Kurt,
The GAC does not object to the assessment of consensus on data processing purposes and accepts that it be sent to the GNSO council. However, it should be ensured that all the purposes be checked against previous EDPB guidance, in particular:
●       explicitly define legitimate purposes in a way which comports with the requirements of GDPR (1)
●       take care in defining purposes in a manner which corresponds to its own organizational mission and mandate / do not conflate purpose (2)
●       that purposes be detailed enough (3)
(1)   In its 11 April 2018 letter <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fen%2Fsystem%2Ffiles%2Fcorrespondence%2Fjelinek-to-marby-11apr18-en.pdf&data=02%7C01%7CAHeineman%40ntia.doc.gov%7Ce2204584c473437d457a08d68c5fb63f%7Cd6cff1bd67dd4ce8945dd07dc775672f%7C0%7C0%7C636850740046289987&sdata=xlH%2F6oT0XqWoA%2BbTPuq99ocnzoFC6F7J5BEKFatCDIM%3D&reserved=0>, WP29 stressed: “the importance of explicitly defining legitimate purposes in a way which comports with the requirements of the GDPR. It therefore urges ICANN to revisit its current definition of “purposes” in light of these requirements. Use of the word “include” suggests that not all purposes are made explicit, which would also be incompatible with article 5(1)b GDPR.”
(2)   In its 11 April 2018 letter <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fen%2Fsystem%2Ffiles%2Fcorrespondence%2Fjelinek-to-marby-11apr18-en.pdf&data=02%7C01%7CAHeineman%40ntia.doc.gov%7Ce2204584c473437d457a08d68c5fb63f%7Cd6cff1bd67dd4ce8945dd07dc775672f%7C0%7C0%7C636850740046299975&sdata=Y3YoFIiBNzOm9p5Db9YM8DlQ04wA1uvfelIVm5hTr8s%3D&reserved=0>, WP29 stated: “ICANN should take care in defining purposes in a manner which corresponds to its own organisational mission and mandate, which is to coordinate the stable operation of the Internet's unique identifier systems. Purposes pursued by other interested third parties should not determine the purposes pursued by ICANN. The WP29 cautions ICANN not to conflate its own purposes with the interests of third parties, nor with the lawful grounds of processing which may be applicable in a particular case.” In its 5 July 2018 letter <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fen%2Fsystem%2Ffiles%2Fcorrespondence%2Fjelinek-to-marby-05jul18-en.pdf&data=02%7C01%7CAHeineman%40ntia.doc.gov%7Ce2204584c473437d457a08d68c5fb63f%7Cd6cff1bd67dd4ce8945dd07dc775672f%7C0%7C0%7C636850740046319645&sdata=eAe4gU6EtOX9W70GL3TtsDGON8RGg89T9yT8QkGplsU%3D&reserved=0>, the EDPB stated: “the EDPB considers it essential that a clear distinction be maintained between the different processing activities that take place in the context of WHOIS and the respective purposes pursued by the various stakeholders involved.” 
(3)   In its 11 April 2018 letter <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fen%2Fsystem%2Ffiles%2Fcorrespondence%2Fjelinek-to-marby-11apr18-en.pdf&data=02%7C01%7CAHeineman%40ntia.doc.gov%7Ce2204584c473437d457a08d68c5fb63f%7Cd6cff1bd67dd4ce8945dd07dc775672f%7C0%7C0%7C636850740046329633&sdata=qJTRk7RBh%2FJCG7IU0BYzd4USXdlFtyvHs4wInRiOwZw%3D&reserved=0>, WP29 clarified: “that purposes specified by the controller must be detailed enough to determine what kind of processing is and is not included within the specified purpose, and to allow that compliance with the law can be assessed and data protection safeguards applied.”
From: Gnso-epdp-team <gnso-epdp-team-bounces at icann.org> On Behalf Of Kurt Pritz
Sent: Sunday, February 3, 2019 4:43 PM
To: EPDP <gnso-epdp-team at icann.org>
Subject: [Gnso-epdp-team] EPDP Consensus Call #1
Hi Everyone: 
This is a long email but each of the points here is important to me, so please read it. 
This email launches what will be at least three "consensus calls" that will conclude the first phase of our work. The process and timing for this step has been so often discussed that I am afraid it appears to some than a much a bigger step than it really is, which is to reconfirm the state of our work. During earlier stages of our work, I was of a mind to conduct these consensus calls as we came to individual conclusions - so that these steps would not seem like so much of a big deal. 
To me, the big deal occurred when we came to agreement on each of the seven “purposes” that are now part of our recommendations. We started out with the 13 purposes that were in the Temporary Specification and, after many hours of discussion and compromise, developed the current list of seven.  I think that is what this group did best. Even though there has been a time gap between each of our agreements and this consensus call, this final step should be treated as the natural follow-on to our discussion.
There are a few particulars in the published guidelines of the consensus calls process that I wish to call out to explain why we are following this methodology (and why I believe you can treat this step as a natural follow-on to our previous work).  
1) We are making this call via email because,  "Consensus calls should always involve the entire Working Group and, for this reason, should take place on the designated mailing list to ensure that all Working Group members have the opportunity to fully participate in the consensus process.”
2) I am making these assignments as to the level of agreement on my own and then I am checking them with you because, "It is the role of the Chair to designate which level of consensus is reached and announce this designation to the Working Group. Members of the Working Group should be able to challenge the designation of the Chair as part of the Working Group discussion.”
3) I believe we have satisfied the requirement that, "After the group has discussed an issue long enough for all issues to have been raised, understood and discussed, the Chair makes an evaluation of the designation and publish it for the group to review,” because we discussed each issue (either led by CBI or me), and there was a significant pause at the end of each conclusion to check for other viewpoints. (There were mild complaints by some that this was done to excess.) The conclusions were then published for team review: in meeting notes, on the team wiki page, and in drafts of final reports. 
This is the time in this email for me to state that this is not the time for revisions or the re-opening of discussion. While we have completed this phase of work in a relatively short time, each discussion was thorough and knowledgable. (Even today, a small team is reviewing every data element and processing step in the data workbooks in order that the final report reflects the competence of our work.) Memories of our extended discussion to arrive at the current set of recommendations are likely buried under the avalanche of the work in attending to the remaining issues. While the particulars of those earlier discussions might be forgotten, we should have confidence that the earlier debates need not be repeated. The penalties for not completing our work by the due date (as imposed by others) has become more clear over time and we are not afforded the luxury of re-checking our work. 
The language in many of these recommendations makes it clear that these are the product of compromise - I think every group on this team has made a significant concession along the way. Given that, I am making a slight perturbation in the way your feedback to each of my designations is collected. 
The way the process is described in the working group guidelines is that for each of the recommendations (including each of the purposes for collecting registration data), I am obligated to indicate the degree of agreement that has been reached on each: full consensus, consensus, strong support, divergence, and minority view. (The definitions of each are in an attached document.)
Generally, minority statements by groups in opposition to “consensus" or "strong agreement” can be published. Given the degree of compromise that has occurred, I also want to give a voice to groups who go along with the consensus position but that want to preserve an argument for the record or for a later date. I think that groups who had the courage to compromise and support agreement on an issue should not be prevented from publishing supplemental thoughts. If your group wishes to provide a supplementary statement to accompany your support of consensus, that will be accepted for publication along with the final report. If offered, each of these statements should begin with some affirmation of the consensus position. 
So with that, we’ve divided these emails into three sections of the team’s work. We did this to make the process easier for you to manage (avoiding 20+ emails), and to start this process while the last issues are being completed. We will The three sections are: 
The Purposes for Processing Registration Data: 
Purpose 1 - Establish the rights of a Registered Name Holder
Purpose 2 - Maintaining SSR through enabling of lawful access
Purpose 3 - Enable communication with RNH
Purpose 4 - Safeguarding RNH's Registration Data
Purpose 5 - Handling Contractual Compliance
Purpose 6 - Resolution of DRPs
Purpose 7 - gTLD registration policy eligibility criteria
Recommendations considered completed in our earlier discussions: 

Recommendation #2 - Commitment to consider a system for Standardized Access to non-public Registration Data
Recommendation #3 - Requirements related to accuracy
Recommendation #15 - URS / UDRP
Recommendation #16 - Instructions for RPM PDP WG
Recommendation #17 - Input from RPM PDP WG to inform subsequent access discussion
Recommendation #18 - Data processing agreements with dispute resolution providers (incl. Question #4)
Recommendation #19 - Transfer Policy
Recommendation #20 - Input to Transfer Policy review (incl. Question #5)
Recommendation #21 - Data processing agreements with non-Contracted Party entities involved in registration data processing
Recommendation #8 - Redaction
Recommendation #13 - Controller Agreement
Recommendation #6 - Escrow Providers
Recommendation #7 - Contractual Compliance
New – Consent to publish additional information
Recommendations in the process of being completed or where there is disagreement: 
Recommendation #9 - Organization field
Recommendation #NEW - City Field
Recommendation #10 - Email communication
Recommendation #14 - Responsible parties
Recommendation #4 - Data elements to be collected by Registrars (incl. Question #2)
Recommendation #5 - Data elements to be transferred from Registrars to Registries
Recommendation #New - Geographic Basis
Recommendation #New - Natural vs. legal
Recommendation #12 - Reasonable access
Recommendation #NEW - Implementation Transition Period
Recommendation #11 - Data retention
Recommendation #22 - Impact on other policies
Recommendation #NEW - Additional Purposes
It will come as no surprise to you that I believe that we have reached agreement on the first two sets of recommendations, and also that I wish to work pretty hard during the time we have on resolving the remaining issues in the third set. The third set these recommendations might be “unbundled” as we come to agreement on some or if we think extending or tolling the discussion might get us to consensus on others.
The attached document contains a summary of the first set of agreements. Each contains the shorthand title and the wording of the recommendation in the final report. It is important to note that the shorthand title does not appear in the final report, just the recommendation itself plus the accompanying explanation that you can read in the currently posted version of the final report. Also, I have added  for your reference the GNSO Guidelines for working group decision making are included. 
In another slight contravention to the standard practice, I have used the label, “Full Consensus / Consensus” as a signal to the GNSO Council that we have reached a consensus position on these issues but also as a salute to or indiction of the degree of teamwork and compromise that has taken place. Either term has an equivalent effect on the Council discussion. 
On this first set, please revert to me by the end of Wednesday if you disagree with my assessment and if you will provide a statement for the final report. Remember that you can support a consensus position and still provide a statement. The second set will be published tomorrow and will ask for feedback by Thursday. If we can in someway extend these deadlines (and we are working to do that), I will let you know. 
Thank you for taking your time to read this. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-epdp-team/attachments/20190206/5f7a5e49/attachment-0001.html>

More information about the Gnso-epdp-team mailing list