Dear EPDP Team,
Please find notes and action item’s from today’s call below.
Best regards,
Marika, Berry, and Caitlin
Action Items
Alan Woods to provide the data elements tables associated to a bifurcated Purpose 1. For ease of reference, the language provided in the RySG’s public comment:
i. 1a. IN ACCORDANCE WITH THE RELEVANT REGISTRY AGREEMENTS AND REGISTRAR ACCREDITATION AGREEMENTS, ACTIVATE A REGISTERED NAME AND ALLOCATE IT TO THE REGISTERED NAME HOLDER.
ii. 1b. AS SUBJECT TO REGISTRY AND REGISTRAR TERMS, CONDITIONS AND POLICIES, AND ICANN CONSENSUS POLICIES: (i) ESTABLISH THE RIGHTS OF A REGISTERED NAME HOLDER IN A REGISTERED NAME, AND (ii) ENSURE THAT A REGISTERED NAME HOLDER MAY EXERCISE ITS RIGHTS IN THE USE AND DISPOSITION OF THE REGISTERED NAME.
Alex Deacon to provide proposed updated language for Recommendation 12 (reasonable access) for EPDP Team review. Proposed updated language is a result of small team discussion in Toronto.
Alan Greenberg to draft question to ICANN org regarding the implication to contact data if a registrar transitions from the 2009 RAA to the 2013 RAA. Is the registrar now required to collect additional contact information that is required under the 2013 RAA?
EPDP Team to review Alan Woods’ proposed language for Recommendation 11 (data retention) and provide feedback.
Support Team to provide consolidated table of outstanding work and due dates to EPDP Team.
EPDP Leadership to provide proposed language to append Recommendation 4 to account for today's discussion.
EPDP Team Call #39
Thursday, 24 January 2019 at 14:00 UTC
Proposed Agenda:
1. Roll Call & SOI Updates (5 minutes)
2. Welcome and Updates from EPDP Team Chair (5 minutes)
a. Update on Data Elements Small Team
b. Update on Legal Committee
c. Other updates, if applicable
If the team has suggestions about how the Support Team can organize the outstanding items, please let us know.
Regarding Purpose 1, we are waiting for the RySG updated language and the accompanying data elements workbooks.
Regarding reasonable access, we are waiting for proposed updated language from Alex Deacon.
3. Continue review of public comments on Initial Report (See Question 3 PCRT)
a. Geographic Basis
Discussion in Legal Committee meeting - crafted a question for Ruth on geographic scope issue based on establishment. It may be better to wait for the answer from legal counsel before continuing this discussion. If ICANN, through its activities and establishment, would certainly affect the discussion of this issue.
The EDPB guidance on territorial scope of GDPR did mention the issue of whether a controller has stable establishments within the EU - there are situations where irrespective of where the processing takes place, the controller is subject to GDPR. Now that we have access to legal counsel, it may be helpful to seek further guidance on this.
One key note in the public comments - there are a lot of statements saying it must be made mandatory, but none of these comments say: it must be mandatory, and this is how to achieve this. Public comments do not change the practicalities of the situation; the temp spec language seems to be the path forward here.
Agree to wait for a legal opinion. No one has addressed the global nature of ICANN policies - question for ICANN - why isn't ICANN defending a global uniform approach? If we can use a rules engine to determine what policies and laws apply based on jurisdiction of the registrant, why do we need ICANN? We could just rely on local law.
This appears to be a policy question the community should decide. However, if the Team would like us to, we can go back to our colleagues with this question.
Should think of national sovereignty and how ICANN fits into this. How will ICANN respond when one jx exercises its sovereignty.
It is a pretty clear and compelling argument that carving something in stone as an ICANN policy will not be useful for Rys and Rrs - flexibility is needed as the ground shifts. Even since the adoption of the temp spec, displayed fields have had to change. Key takeaway: flexibility and discretion needs to lie with the CPH. If there is any doubt, lean toward protection of the individual.
Comment from George K. - WHOIS is being redacted against his wishes - this is a consent to publication issue. This is an important comment to be referenced during another topic.
If there is legal opinion that will say we have to redact everything, this conversation is moot. Re: protecting privacy, refer to the bylaws. It's not our job to decide what level of privacy is given to what registrants. That is for governments to decide.
Re: no one having provided a solution - the BC comment references a rules engine. If the Team comes up with a global policy, we want to avoid having a conflict issue in the future. A rules engine isn't necessarily software - it could be a chart as to what applies where. Perhaps we can mimic the language from legal vs. natural and discuss this in Phase 2.
We are working on the disclosure and access question. Perhaps we should try to put the question to a later stage too. Need to look at this at the legal/compliance level and the policy level. While we are currently looking at GDPR, there are new laws emerging. We are not using the power we have. We can make policy, keeping in mind the global level. We may be on the verge of giving that power away. We should keep in mind "one world, one internet" as we develop this policy. There may be a waiver system for global applicability to the Asian registrar example - we do not have the technical vehicle to differentiate now.
Answer the question - whether a policy for TLDs can be applied based on geographic location. There are ccTLDs currently doing this. Is it feasible? yes. The geographic distinction is relevant for data processing flows. It sounds like many are in favor of a common denominator approach. If we give the opportunity for the Rt to consent to publish - this will alleviate many concerns.
We are out of runway for Phase 1. For Phase 1, propose to keep the language of the Temp Spec, and move this discussion for Phase 2.
No one has mentioned the burden on the individual respondent.
This is a complex problem. For the recommendation - temp spec language is left alone for the time being, and it will be discussed further in Phase 2
Small edit: we're OK with temp spec language persisting as we are working through the attendant issues in Phase 2
b. Meaning of Optional (See Rec. 4 PCRT (Question 2))
We are still awaiting legal advice on this re: if notification to the tech contact would obviate legal liability of the Rr
It is not sufficient to just use the word optional to describe what we mean in our recommendation. Using the example of nameserver field, the nameserver is optional - it is optional for the Rt to provide the info, but it is required for the Ry/Rr to support that field. However, in some cases, we may mean it is optional for Rr/Ry to support that field.
Should optional mean a. rt can fill it in if they wish or b. the rr can offer the field. We cannot answer that question unless we go to the access discussion. What happens if the Rr does not offer or Rt does not fill it in for query for technical field. What are the implications of making it optional at either level? The implications of not having technical contact information available break the reason WHOIS was invented.
The question was been detached by the purposes for which we are collecting data. Traditional WHOIS and technical contact field predates the Ry/Rr split. The Rr is the technical contact as they handle the technical configuration of the name. This issue has also been litigated in Germany.
We have a purpose related to the technical contact - that is purpose 2.
The answer to Alan's previous question is - if there is no tech contact, the Rt contact info is provided. If the Rt info is redacted, it becomes an access question.
Rrs don't seem opposed to providing the option to the Rrs. This would provide consistency - this should not be a burden for Rrs to implement.
Should be optional for the registrar to offer. It's important to demonstrate compliance, and there have not been compelling arguments offered as to the lawful purpose for this collection.
The legal basis could be the customer wants to provide this data and it provides a benefit to the DNS.
Question: green means it is required for registrars to offer the option. Red is Rr is NOT required to offer the option.
Document the status and await further legal advice on this issue.
c. Recommendation 4 – Data elements to be collected by registrars: the team will review the public comments while small teams will review the data elements (30 minutes)
According to the 2009 RAA, the Rt contact (phone and email) were optional, so there may be registrations that do have Rt contact. If eliminate admin altogether, it is conceivable that some registrations will have no contact information associated to them. What is the interpretation of RAA from ICANN org and Compliance - if a Rr collected info validly under the 2009 RAA - what happens when Rrs sign onto the 2013 RAA?
Action item: Alan Greenberg to draft question regarding switch from 2009 RAA to 2013 RAA and what, if any, the Rr may be required to do with respect to data fields not required under 2009 RAA.
The Admin and Tech fields are used in Consensus policies, and these are important consumer safeguards
Do we have the proper anchors in place? How we handle Rt data that they have provided in good faith is important.
Include policy statement - EPDP Leadership to come up with a policy statement to append to Recommendation 4 to account for today's discussion.
Data Retention
Alan Woods proposed language re: data retention period - action - read Alan's proposal and respond.
Transfer of Data from Registrar to Registry
Look at public comments and consider if any comments warrant further conversation. Helpful if Marc A. could write up his thoughts for the group to consider.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-epdp-team/attachments/20190124/d7abe78a/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-team/attachments/20190124/d7abe78a/smime-0001.p7s>