[Gnso-epdp-legal] Notes and action items from Meeting 2 of EPDP legal committee

[Caitlin Tubergen]

Dear All,

 

Please find notes and action items from Wednesday’s legal committee call below. As a reminder, our next Legal Committee meeting is Wednesday, 8 January at 14:00 UTC.

 

Best regards,

 

Marika, Berry and Caitlin

 

--

 

EPDP Small meeting on Legal Committee Framework  

Wednesday, 02 January 2019 

 

Action Items:
Margie to draft conflict of interest language for this team to review by tomorrow, 3 January. (complete)
Legal Committee to review Margie’s proposed language
Support Staff to provide information on previous law firms engaged with ICANN.
 

Notes: 

 
Guidelines on ICANN Org's procurement process can be found here: https://www.icann.org/resources/pages/general-2014-01-06-en
In terms of engagement with outside legal counsel, the process is led by ICANN's general counsel's office
Turnaround time for engagement will depend on this legal committee's guidelines as well as previous engagement with ICANN (if firm was previously engaged, the timeline would be shortened)
The timeline could be as early as one week to much longer - the largest dependency is conflict of interest. 
What does the team need to provide to ICANN to begin the procurement process?
The team needs to come forward with basic parameters - for example, is the team OK with a previously-engaged firm, or should ICANN engage a "new" firm?
Once the team has settled on basic parameters, the procurement process can begin.
The team may wish to refer to Thomas' previous email, in which he stated: 
1. The EPDP Team has discussed ways to ensure that the legal compliance work is conducted in a cost-efficient manner. An approach that we think is worthwhile considering is to use the same independent outside counsel for both the EPDP Team and ICANN Org. 
2. We trust that both ICANN Org and our team will need answers to the same questions. Therefore, reaching out to one firm helps avoid duplicate cost and also potentially conflicting advice. 
3. Since we are working on a solution that is fair to all parties facing compliance challenges, we do think that using an independent firm can help to find a balanced solution in which burdens and risks as well as benefits are appropriately shared.
Any additional feedback?
Prefer pragmatic approach - a hard-and-fast rule regarding using previously-engaged firms is probably too severe. 
ICANN may have previously disagreed with points made within the Hamilton memo, so it may be problematic to engage the Hamilton law firm.
It's likely inevitable that there will be a perception of conflict if we use a firm that has been used before. It would therefore be optimal to use a new firm. However, if we use a new firm, it would be best if the procurement process could be fast-tracked.
The crucial issue would be to work with a firm that has not been encumbered with historical disagreements. It would be helpful to get a list of issues the firm has advised ICANN on. 
It would be good to get suggestions for other firms that have not previously worked with ICANN.
Action item: EPDP Support Staff to provide a list or previously-engaged law firms and links of work that has been done (if applicable).
Is the team just concerned with advice to ICANN or is advice to large contracted parties also a concern?
Question 2: Laureen, Kristina, Margie
(For the EDPB) If registrars allow registrants to self-identify at the time as a natural or legal person, who will be held liable if the registrant incorrectly self-identifies and personal information is publicly displayed? Apart from self-identification, and educational materials to inform the registrant, are there any other ways in which risk of liability could be mitigated by registrars? (p. 53 of Initial Report)
Kristina's proposed edit:
If a registrar permits a registrant, at the time of domain name registration, to self-identify as a natural or legal person, does a registrant’s incorrect self-identification that results in the public display of personal data create liability under GDPR?   If so, please advise, for each possible participant in the domain name registration process listed below, if that participant incurs liability.
Registrar
Reseller
Registry Operator
Backend service provider (for registrar and/or registry operator)
Would providing educational materials to the registrant mitigate any liability risk and, if so, to what extent and for which participant(s)?  Please identify any other measures that would mitigate liability risk and, for each, advise on (i) the extent to which that measure mitigates liability risk; and (ii) for which participant(s) in the domain name registration process does that measure mitigate liability risk?
It may be helpful to provide background information (definitions of contracted parties, etc.) along with previous advice from the EDPB before presenting the question
Is it necessary to include parties that have no contract with ICANN? (reseller, backend service provider)
We may want to clarify what educational materials mean
More context needs to be added here
This question should be framed - who or what is the liability risk involved with the treatment of data of the RNH which may lead to the inadvertent publication of personal data?
We may want to consider asking the advisor to respond at two levels:
1. what is the risk for data subject against parties involved

2. what is the risk if there is a methodological system issue? Here there may be claims from data subjects and data authorities.
All questions should be written in the same format: (1) "ICANN slang" (2) the advice we've previously received (3) the question
It may be helpful to work in small groups to refine these questions before discussing on the LC call.
EPDP Support Team to look into existing ICANN publications on the domain name registration process
It may be helpful to meet for a few hours in Toronto 
Wrap and confirm next meeting to be scheduled for Wednesday 9 January 2019 at 14.00 UTC
 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-epdp-legal/attachments/20190104/064598c7/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4621 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/gnso-epdp-legal/attachments/20190104/064598c7/smime-0001.p7s>