[NCUC-DISCUSS] Update #1 GNSO EPDP on Temporary Specification for gTLD Registration Data

Tue Aug 7 06:06:14 EEST 2018

Thanks Zhou and Farrell for raising an interesting point about scope, territoriality, and competing legal frameworks. While ICANN is a global standard-setting body, the environment can be very US/Euro-centric. I therefore find it useful to contextualize — and problematize — proceedings in this way.

That being said, I think there’s a risk of getting too involved in the details of the problem and missing out on the EPDP’s potential. As members of the Non-Commercial Stakeholder Group, our mission <https://gnso.icann.org/sites/default/files/filefield_25801/ncsg-charter-05may11-en.pdf> to represent the interest and concerns of noncommercial internet users is unique in the ICANN environment. Over the years, privacy and free expression have surfaced as salient human rights for the groups the NCSG represents (civil society organizations, religious groups, academics, etc).

Because there's an entire constituency dedicated exclusively to furthering the interests of intellectual property holders, I believe it would diminish the NCSG’s value within the ICANN community (and undermine our stated values) if we were to advance the notion that intellectual property and privacy rights could be weighted equally. Moreover, the topic at hands is data protection, not rights protection, so prioritizing privacy is a given in my mind.

Finally, on the topic of legal focus: of course, the EPDP is squarely Euro-centric. There are many extant data protection regimes around the world, and surely more to come. But trying to make a one-size-fits-all solution on this breakneck timeframe or, worse, negating the process because of its narrow scope forfeits this golden opportunity to advance the NCSG’s mission and values in a way that has escaped us perviously.

As David pointed out, the idea is that a normal PDP will be created (resuscitated?) to deal with broader issues related to registration data services. I think that furthering privacy standards in the GDPR EPDP serves our mission, by raising the standard of privacy for all users, and could moreover facilitate compliance with future data protection legislation.

Greetings from London,
Collin

--
Collin Kurre
ARTICLE 19

> On Aug 7, 2018, at 9:52 AM, David Cake <dave at DAVECAKE.NET> wrote:
> 
> On the one hand, the Temporary specification, and the narrow scope of the EPDP, have come about specifically due to the GDPR (and ICANNs delay in properly dealing with it). It is a very accelerated and narrowly scoped process because the GDPR issue is urgent. The TS and the EPDP can’t effectively deal with all future privacy law issues, particularly purely hypothetical future ones.
> 
> On the other hand,  I would hope that whatever policy the EPDP produces will be of general utility enough that it can be adapted to future privacy law issues, and to some extent that is why I feel that the process needs to be guided by privacy rights under the Universal Declaration of Human Rights, not just the specifics of the GDPR.
> 
> Ultimately, the EPDP can not hope to deal with all potential privacy law issues - I hope that once the EPDP is done, we can return to something like the suspected Next Generation RDS working group, and continue work to address not just GDPR but  the many many other issues we would hope to address in a new RDS, but with some of the more intransigent and difficult issues settled in the EPDP so we can get back a productive approach to the bigger task of RDS redesign - including a more general approach to how we might address differing privacy laws in other domains.
> 
> David
> 
> 
>> On 7 Aug 2018, at 4:27 pm, Farell FOLLY <farell at BENIN2POINT0.ORG <mailto:farell at BENIN2POINT0.ORG>> wrote:
>> 
>> Dear all,
>> 
>> This is an incredibly interesting thread that I thank Zhou for bringing. I have a very narrow background in dealing with law issues, however with some stronger knowledge in regulatory subjects I must say again that I, too, do not feel comfortable that ICANN, at strategy level, is specifically targeting a particular jurisdiction (there can be many to deal with).
>> 
>> The TS seems (intentionally or not) to target mainly the GDPR while wishing (with the ePDP) to address all similars cases within the ICANN ecosystem. What if Africa comes its own “GDPR”? What if ASIA comes with its own “GDPR”?. This is where, in my opinion, mentioning explicitly the GDPR as a big focus is not a good idea, I would prefer a more generic term encompassing any jurisdiction that has rules/policies in conflict with existing WHOIS process. That said, I hope ICANN will develop more specifications in the future if new “GDPRs” bear. I would like to be wrong or to have misunderstood something.
>> 
>> @Amr, Even with the “Additional Provisions….”, it looks like those cases are considered “miscellaneous”.  In addition, nothing guarantees that ICANN will add more provisions to change the 2013 RAA, following the term of the ePDP WG.
>> 
>> @__f_f__
>> 
>> Best Regards
>> ____________________________________
>> 
>> (Ekue) Farell FOLLY
>> NCUC Rep. to the NCSG Policy Committee
>> linkedin.com/in/farellf <http://linkedin.com/in/farellf>
>> 
>> 
>> 
>> 
>> 
>> 
>>> On 6 Aug 2018, at 20:51, Amr Elsadr <aelsadr at ICANNPOLICY.NINJA <mailto:aelsadr at ICANNPOLICY.NINJA>> wrote:
>>> 
>>> Hi,
>>> 
>>> Thanks for the response, Zhou Heng. If you scroll towards the bottom of the temporary specification, you’ll find section 3 of Appendix A: Registration Data Directory Services, which states:
>>> 
>>> "Additional Provisions Concerning Processing Personal Data in Public RDDS Where Processing is not Subject to the GDPR
>>> Registry Operator and Registrar MAY apply the requirements in Section 2 of this Appendix (i) where it has a commercially reasonable purpose to do so ,or (ii) where it is not technically feasible to limit application of the requirements as provided in Section 2.1 of this Appendix."
>>> 
>>> Section 2 of the appendix being referred to here explains the requirements for processing personal data in public RDDS where processing is subject to the GDPR.
>>> 
>>> The definition of “MAY” is provided in an earlier provision in the temp spec, as opposed to “MUST” or “SHALL”, which would place the requirement on a Chinese or Canadian gTLD Registry Operator, as you suggest. As you can see here, that is not the case.
>>> 
>>> Furthermore, there are several provisions in the 2013 RAA (as well as the Registry Agreement) that address contractual obligations to ICANN that may conflict with applicable law. Certainly, in a case where a court order in China requiring that a China-based registrar disclose the PII of a registrant (regardless of the registrant location) is issued, it is fully expected that the registrar complies with the court order.
>>> 
>>> I hope that I have understood your concern correctly.
>>> 
>>> Thanks.
>>> 
>>> Amr
>>> 
>>>> On Aug 6, 2018, at 4:00 PM, Zhou Heng <socata at ruc.edu.cn <mailto:socata at ruc.edu.cn>> wrote:
>>>> 
>>>> Dear Amr and Stephanie,
>>>> 
>>>> Definitely I agree with your word "The topic of this EPDP (Expedited Policy Development Process) has a very narrow scope as set by the Charter <https://community.icann.org/display/EOTSFGRD/EPDP+Team+Charter> adopted by the GNSO Council, which is to review the temporary specification on gTLD registration data <https://www.icann.org/resources/pages/gtld-registration-data-specs-en> adopted by the ICANN Board. The EPDP Team is tasked to recommend whether this specification should be adopted via a GNSO process as-is, or whether changes should be recommended." , which is exactly the reason why I sent this emails to the discussion list. Even through I am not a member of EPDP team, I still hope to discuss this topic to enhance the understanding towards this issue in the community.
>>>> 
>>>> However, I believe the Temporary Specification should not be narrowly explained only for the contractual parties in EU. Actually, the article 1.2 of the Temporary specification says "1.2. This Temporary Specification applies to all gTLD Registry Operators and ICANN-accredited Registrars." Hence, the temporary specification may not be understood as a narrow scope policy issued by ICANN only for dealing with the conflict with GDPR. Even a registry in China/ Canada should also follow the Temporary Specification. Even through the article 32 of China Domain Name Governance Rule <http://www.miit.gov.cn/n1146295/n1146557/n1146624/c5778555/content.html> did mention the protection of Personal Privacy for domain registrant, there are significant differences between the protection in China and in GDPR. In addition, the article 31 of China Domain Name Governance rule requires the registrar and registry to provide the public query service for domain name registration information.
>>>> 
>>>> Here we may have a simple example, if there is a german individual who set up a website named wangzhihe.com <http://wangzhihe.com/> in a China-based registrar, which is conflicted with a famous trademark Wangzhihe in China, just like the famous case resolved by Munich Higher Regional Court (for details you may check the judgment of 23 April 2009 - 29 U 5712/07 -, juris). Then, the court in China dealing with this case sends a information inquiry to the registrar, what should the registrar do?
>>>> 
>>>> According to article 31 of China Domain Name Governance rule, the registrar have to provide a public query service for the domain name registration information, which is forbidden by Temporary Specification for the information is a EU citizen's personal information. According to 4.1 of appendix A, it is hard to say an intellectual property rights is overweight than personal privacy, through those two rights are equally mentioned in Charter of Fundamental Rights of the European Union. According to 4.2 of appendix A, clearly a China court is not a relevant court of competent jurisdiction concerning the GDPR, so the court order from China court would probably not suit for the situation. In addition, there is no issued China law or regulation have mentioned the solution towards non-public information, which is almost not exit before GDPR.
>>>> 
>>>> Of course I agree the key factor of Temporary Specification is for the limitation to ICANN in accordance with personal privacy law. However, I want to mention some expression in Temporary Specification may be inappropriate, and may incur the conflict over internet governance issue.
>>>> 
>>>> I am happy to discuss this stuff with the community, and your words really help me better understanding the Temporary Specification and EPDP. Thanks!
>>>> 
>>>> --
>>>> Zhou Heng
>>>> Ph.d Candidate
>>>> Renmin University of China
>>>> 
>>>> 在 2018-08-05 23:00:22，Amr Elsadr <aelsadr at icannpolicy.ninja <mailto:aelsadr at icannpolicy.ninja>> 写道：
>>>> Hi Zhou Heng,
>>>> 
>>>> I’m not subscribed to the NCUC-DISCUSS list, so I hope you don’t mind me switching the recipient of this email to NCSG-DISCUSS.
>>>> 
>>>> If I understand your comment below correctly, I don’t agree with it. Let me explain why.
>>>> 
>>>> The topic of this EPDP (Expedited Policy Development Process) has a very narrow scope as set by the Charter <https://community.icann.org/display/EOTSFGRD/EPDP+Team+Charter> adopted by the GNSO Council, which is to review the temporary specification on gTLD registration data <https://www.icann.org/resources/pages/gtld-registration-data-specs-en> adopted by the ICANN Board. The EPDP Team is tasked to recommend whether this specification should be adopted via a GNSO process as-is, or whether changes should be recommended. The whole purpose of the temporary specification was to ensure that ICANN, through its contracts with contracted parties (gTLD Registry Operators and Registrars) does not require these parties to process and disclose gTLD domain name registration data in a manner that conflicts with the EU GDPR. So the narrow scope here does not cover other privacy/data protection regimes, and a narrowly scoped policy issue is required in order for the GNSO Council to initiate an Expedited PDP, as opposed to a traditional PDP.
>>>> 
>>>> However, this does not mean that only EU-based actors need to be consulted. Note that there are several non-EU based members on the EPDP Team, as the GDPR affects not only contracted parties that are geographically based in the EU, but also any party that serves EU-based customers, as well as stakeholders around the world that have an interest in accessing this data.
>>>> 
>>>> Furthermore, the hypothetical scenario that you describe is not accurate. If a Chinese court requires a China-based registrar to disclose data on a registrant located in China, the GDPR is not to my knowledge at all applicable. That would mean that in this scenario, this temporary specification is also not applicable.
>>>> 
>>>> I’m multitasking right now, so hope that my explanation is helpful and clear enough, and that I have not misrepresented the facts. I am happy to be corrected, if I am wrong. Perhaps others would like to weigh in.
>>>> 
>>>> Thanks.
>>>> 
>>>> Amr
>>>> 
>>>>> On Aug 5, 2018, at 2:47 PM, Zhou Heng <socata at ruc.edu.cn <mailto:socata at ruc.edu.cn>> wrote:
>>>>> 
>>>>> Dear Community and EPDP WG members,
>>>>> 
>>>>> I would like to make one comment towards the Temporary Specification:
>>>>> 
>>>>> 26. Please consider Appendix A: Registration Data Directory Services
>>>>> 4.1.  Registrar and Registry Operator MUST provide reasonable access to Personal Data inRegistration Data to third parties on the basis of a legitimate interests pursued by the third party,except where such interests are overridden by the interests or fundamental rights and freedomsof the Registered Name Holder or data subject pursuant to Article 6(1)(f) GDPR.
>>>>> 
>>>>> 4.2.  Notwithstanding Section 4.1 of this Appendix, Registrar and Registry Operator MUST providereasonable access to Personal Data in Registration Data to a third party where the Article 29 Working Party/European Data Protection Board, court order of a relevant court of competentjurisdiction concerning the GDPR, applicable legislation or regulation has provided guidance that the provision of specified non- public elements of Registration Data to a specified class of thirdparty for a specified purpose is lawful.
>>>>> Registrar and Registry Operator MUST provide such reasonable access within 90 days of the
>>>>> date ICANN publishes any such guidance, unless legal requirements otherwise demand an earlierimplementation.
>>>>> 
>>>>> As I have said in this mail-list, ICANN is an organization running for the Global Internet Key infrastructure Resource; hence, the regulation made by ICANN should consider the opinion not only from EU, but from the Global Community. The expression from article 4.1/ 4.2 of appendix A here indicates that even if a court from China wants the details data from a registrar based in China, they may require the permission from Article 29 WG or follow the instruction from article 6(1)(f) of GDPR, which would be probably inappropriate.
>>>>> 
>>>>> If I have any  misunderstanding towards this regulation, or you have any words towards this issue, please do not hesitate to contact me. I am looking forward the response, thanks!
>>>>> 
>>>>> Best regards
>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> Zhou Heng
>>>>> Ph.d Candidate
>>>>> Renmin University of China
>>>>> 
>>>>> 在 2018-08-03 22:40:54，Amr Elsadr <aelsadr at ICANNPOLICY.NINJA <mailto:aelsadr at ICANNPOLICY.NINJA>> 写道：
>>>>> Hi,
>>>>> 
>>>>> The first GNSO EPDP on Temporary Specification for gTLD Registration Data took place on Wednesday, 1 August 2018. The notes, action items and recordings for this call can be found on the meeting’s wiki page here: https://community.icann.org/x/ugBpBQ <https://community.icann.org/x/ugBpBQ>
>>>>> 
>>>>> As per action item 5 (which I believe should be action item 6), the NCSG appointed members and alternates are considering our responses to the first part of a 4-part survey. The first part of the survey is due on Monday, 6 August 2018 at 19:00 UTC. This deadline is in a few days, as the responses provided by the different GNSO SGs/Cs, as well as the different ICANN SOs/ACs participating in the EPDP will be reviewed during the next EPDP Team call on Tuesday, 7 August 2018.
>>>>> 
>>>>> We’ve created a google doc to collaborate on the responses we submit. You can find this google doc here: https://docs.google.com/document/d/1GcE0Q_Fq8rXF8_Dt_bcNDdp5-1uKwcRRJjKmQbnkvoQ/edit?usp=sharing <https://docs.google.com/document/d/1GcE0Q_Fq8rXF8_Dt_bcNDdp5-1uKwcRRJjKmQbnkvoQ/edit?usp=sharing>
>>>>> 
>>>>> Permission rights for the google doc only allow NCSG-appointed members and alternates of the EPDP Team to comment and edit the document, but anyone with the link can view it. So if anyone within the broader NCSG membership has comments or input, please start a new thread to share and discuss those here on NCSG-DISCUSS.
>>>>> 
>>>>> For those who don’t have access to google services, staff have exported the survey questions to a MS Word document, which is attached to this email. You won’t be able to view any edits or comments made on the google doc, but this is the best we could right now (apologies for that).
>>>>> 
>>>>> If you have any additional questions for your representatives on the EPDP Team, please don’t hesitate to ask.
>>>>> 
>>>>> Thanks.
>>>>> 
>>>>> Amr
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> Ncuc-discuss mailing list
>>>>> Ncuc-discuss at lists.ncuc.org <mailto:Ncuc-discuss at lists.ncuc.org>
>>>>> https://lists.ncuc.org/cgi-bin/mailman/listinfo/ncuc-discuss <https://lists.ncuc.org/cgi-bin/mailman/listinfo/ncuc-discuss>
>>>> 
>>>> 
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ncsg.is/pipermail/ncsg-discuss/attachments/20180807/a40d8b36/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.ncsg.is/pipermail/ncsg-discuss/attachments/20180807/a40d8b36/attachment.sig>