January 2019 - Gnso-epdp-team

Recordings, Attendance & AC Chat / GNSO Temp Spec gTLD RD EPDP / Thursday, 24 January 2019
by Andrea Glandon Jan. 24, 2019

Jan. 24, 2019

Dear all, Please find the attendance and AC chat attached to this email, and the MP3 and AC recording below from the GNSO Temp Spec gTLD RD EPDP call held on Thursday, 24 January 2019 at 14:00 UTC. These have also been posted on the agenda wiki page: https://community.icann.org/x/9JUWBg MP3: https://audio.icann.org/gnso/gnso-epdp-gtld-registration-data-specs-24jan19… AC Recording: https://participate.icann.org/p3qcfj7oeex/ <https://participate.icann.org/p3qcfj7oeex/?OWASP_CSRFTOKEN=84cf656755a5fb62…>** Please let me know if your name has been left off the list ** Mailing list archives of the GNSO Temp Spec gTLD RD EPDP : https://mm.icann.org/pipermail/gnso-epdp-team/ Main wiki page for the working group: https://community.icann.org/x/IYEpBQ Thank you. Kind Regards, Andrea Glandon

1 0

Re: [Gnso-epdp-team] Updated language for Recommendation #10
by Ayden Férdeline Jan. 24, 2019

Jan. 24, 2019

Hi all, I have a question here. Could someone please explain what information/data elements they would reasonably expect to be contained within these log files? Thank you. Kind regards, Ayden Férdeline > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > On Thursday, January 24, 2019 3:22 PM, Marika Konings <marika.konings(a)icann.org> wrote: > >> Dear EPDP Team, >> >> In Toronto, we reached agreement in principle on recommendation #10 but did not have time to develop language to which the team agreed. To move that discussion forward, the support team has developed the proposed language below for discussion and inclusion in the Final Report. Note that the bold language below (bullets 2 and 3) are the new additions, bullet 1 is identical to the language in the Initial Report. Please review this language with your group to ensure it aligns with the agreement that was reached. If you are of the view that it does not conform to the agreement, please: >> >> - Outline your concerns, focusing on how the proposed language does not reflect the principle agreement reached, and; >> >> - Propose edits that would address your concerns that are in line with the agreement reached. >> >> The deadline for doing so is Monday 28 January so that there is sufficient time to review and discuss any concerns. If no concerns are raised, this language will be incorporated into the draft Final Report for your review. >> >> Best regards, >> >> Caitlin, Berry and Marika >> >> ========== >> >> Recommendation #10 – Email Communication >> >> 1) In relation to facilitating email communication between third parties and the Registered Name Holder, the EPDP Team recommends that current requirements in the Temporary Specification that specify that a Registrar MUST provide an email address or a web form to facilitate email communication with the relevant contact, but MUST NOT identify the contact email address or the contact itself, remain in place. >> >> 2) The EPDP Team recommends Registry Operators and Registrars MUST maintain Log Files associated with the transmission of email communications between the Registry Operator/Registrar and the Registered Name Holder. >> >> 3) The EPDP notes operational difficulties having to do with contacting registered name holders through webforms (where there is no confirmation that the message sent was received) and pseudonymized email addresses (that often can be readily "hacked" to discover the identity of the addressee), and recommends the GNSO Council initiates work to develop a reliable, safe ways of contacting registrants in cases where their email cannot be displayed. >> >> Marika Konings >> >> Vice President, Policy Development Support – GNSO, Internet Corporation for Assigned Names and Numbers (ICANN) >> >> Email: marika.konings(a)icann.org >> >> Follow the GNSO via Twitter @ICANN_GNSO >> >> Find out more about the GNSO by taking our [interactive courses](https://urldefense.proofpoint.com/v2/url?u=http-3A__learn.icann.or… and visiting the [GNSO Newcomer pages](https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_s….

2 1

Notes, action items and outcomes of today's EPDP Team meeting - 24 January 2019
by Caitlin Tubergen Jan. 24, 2019

Jan. 24, 2019

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.

1 0

Updated language for Recommendation #10
by Marika Konings Jan. 24, 2019

Jan. 24, 2019

Dear EPDP Team, In Toronto, we reached agreement in principle on recommendation #10 but did not have time to develop language to which the team agreed. To move that discussion forward, the support team has developed the proposed language below for discussion and inclusion in the Final Report. Note that the bold language below (bullets 2 and 3) are the new additions, bullet 1 is identical to the language in the Initial Report. Please review this language with your group to ensure it aligns with the agreement that was reached. If you are of the view that it does not conform to the agreement, please: 1. Outline your concerns, focusing on how the proposed language does not reflect the principle agreement reached, and; 2. Propose edits that would address your concerns that are in line with the agreement reached. The deadline for doing so is Monday 28 January so that there is sufficient time to review and discuss any concerns. If no concerns are raised, this language will be incorporated into the draft Final Report for your review. Best regards, Caitlin, Berry and Marika ========== Recommendation #10 – Email Communication 1) In relation to facilitating email communication between third parties and the Registered Name Holder, the EPDP Team recommends that current requirements in the Temporary Specification that specify that a Registrar MUST provide an email address or a web form to facilitate email communication with the relevant contact, but MUST NOT identify the contact email address or the contact itself, remain in place. 2) The EPDP Team recommends Registry Operators and Registrars MUST maintain Log Files associated with the transmission of email communications between the Registry Operator/Registrar and the Registered Name Holder. 3) The EPDP notes operational difficulties having to do with contacting registered name holders through webforms (where there is no confirmation that the message sent was received) and pseudonymized email addresses (that often can be readily "hacked" to discover the identity of the addressee), and recommends the GNSO Council initiates work to develop a reliable, safe ways of contacting registrants in cases where their email cannot be displayed. Marika Konings Vice President, Policy Development Support – GNSO, Internet Corporation for Assigned Names and Numbers (ICANN) Email: marika.konings(a)icann.org<mailto:marika.konings@icann.org> Follow the GNSO via Twitter @ICANN_GNSO Find out more about the GNSO by taking our interactive courses<https://urldefense.proofpoint.com/v2/url?u=http-3A__learn.icann.org_courses…> and visiting the GNSO Newcomer pages<https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_sites_gn…>.

1 0

Meeting Invitation: Alternates & Observers / GNSO Temp Spec gTLD RD EPDP call / Tuesday, 29 January 2019 at 14:00 UTC for 3 hours
by Andrea Glandon Jan. 24, 2019

Jan. 24, 2019

Dear all, Non-members can follow the EPDP call taking place on Tuesdays and Thursdays via the audio cast or view only Adobe Connect room. As requested and discussed on Tuesday's (14 August 2018) meeting, please note that an additional Adobe Connect room has been created for use by interested alternates and observers to be able to view-only the main EPDP Team Adobe Connect room. The view-only room will also broadcast the audio of the EPDP Team AC room, however, those in the view-only room will not be heard. Note that the audio cast stream will also remain available for now for those that prefer to use that option to listen live to the EPDP Team meeting. View-Only Adobe Connect room for alternates and observers: https://participate.icann.org/gnso-epdp-observers Meeting Audio Cast (for alternates and observers) To join the event, click on the link: Listen in browser: http://stream.icann.org:8000/stream01 [stream.icann.org]<https://urldefense.proofpoint.com/v2/url?u=http-3A__stream.icann.org-3A8000…> Listen in application such as iTunes: http://stream.icann.org:8000/stream01.m3u [stream.icann.org]<https://urldefense.proofpoint.com/v2/url?u=http-3A__stream.icann.org-3A8000…> Agenda wiki page: https://community.icann.org/x/hZoWBg Thank you. Kind Regards, Andrea

1 0

EPDP Recommendation 11 - email list discussion
by Kurt Pritz Jan. 24, 2019

Jan. 24, 2019

Hi Everyone: There were several items (Recommendations) that we agreed to discuss via email with the idea that we could close on them without taking time for discussion in a meeting. This email concerns Recommendation 11, addressing the data retention period. The current recommendation states: The EPDP Team recommends that Registrars are required to retain the herein-specified data elements for a period of one year following the life of the registration. This retention period conforms to the specific statute of limitations within the Transfer Dispute Resolution Policy (“TDRP”). Small Team Discussion (1) The small team noted that “statute of limitation” as used in the Recommendation was probably an inappropriate use of a legal term of art and should be replaced with more appropriate language. This point is addressed in the proposed updated Recommendation below. (2) Some on the small team advocated for a longer retention period, suggesting that a longer retention period could be anchored in existing ICANN policy requirements or other outside requirements. (The current retention period is anchored is the Transfer DRP as the “tall pole” among all the other purposes for processing registration data.) The updated language below, proposed by small team B, clarifies that the proposed data retention period is for ICANN related requirements and different retention periods may apply as a result of local requirements or circumstances. Proposed updated language recommendation 11 – data retention The EPDP Team recommends that: Registrars are required to retain the herein-specified data elements for ICANN-related requirements for a period of one year following the life of registration. This minimum retention period is consistent the requirements of the Transfer Dispute Resolution Procedure, which has the longest retention requirement of any of the enumerated Purposes for Processing Registration Data. Note, Contracted Parties may have needs or requirements for longer retention periods in line with local law or other requirements. This is not prohibited by this language. Similarly, should local law prevent retention for the period of one year, there are waiver procedures in place that can address such situations. Actions Those supporting a retention greater than one year generally should submit rationale for such a retention period including related ICANN policy requirements to which this could be anchored. These submissions will be discussed via email. Submit comments for support for the amended Recommendation or requesting edits to the recommendation with rationale. Deadline: Friday, 24 January, additional email discussion might follow depending on responses. Thank you and best regards, Kurt

4 7

Integrate ARS into Purpose
by Alan Greenberg Jan. 24, 2019

Jan. 24, 2019

I offered to suggest a wording change to Purpose 5 to allow it to include the Accuracy Reporting System (ARS) as previously suggested by Milton. Add to rationale: To allow ICANN to carry out accuracy audits of registration contact data, ICANN may request from Registry Operators and Registrars the minimum data for randomly selected registrations. Under F-PA2 replace "ICANN org compliance" with "ICANN org" (2 places) Under F-PA4 replace "ICANN Compliance" with "ICANN org" and add to Lawful Basis "May go beyond the life of registration in order to complete accuracy audit and compliance processing, not to exceed one year." Data element table will need to include any contact information still in use post EPDP. Alan

2 1

Test
by Kurt Pritz Jan. 23, 2019

Jan. 23, 2019

Hi Everyone: With the goal of progressing on issues via email, the leadership team has considered the discussion provided during the Toronto meeting and suggests the following compromise language to address the different positions expressed. Discussion The language below is the same language proposed by the small team that reviewed the comments, but modified: as suggested by Diane during the meeting to reflect that GDPR Art 28 is unlikely to apply in this situation, and by an addition (bracketed & bolded below) to reference the analysis in the Final Report that this team recommends the creation of Joint Controller Agreements, to appropriately influence the negotiation of GDPR-compliant agreements. This language is intended to strike a balance between those preferring to leave some flexibility for ICANN Org and Contracted Parties to consider the appropriate agreements and those preferring to be specific about the type of agreement to be pursued. I understand this is a complex topic that might require additional discussion but it is also possible that we cannot be dispositive on this issue prior to a lengthy contract formation discussion that extends well beyond our time frames. For that reason, we are taking the liberty of making this recommendation and hope you accept it in the spirit it is offered. Proposed Recommendation #13 Language The EPDP Team recommends that ICANN Org negotiates and enters into required data protection agreements such as a Data Processing Agreement (GDPR Art. 28) or Joint Controller Agreement (Art. 26), as appropriate, with the Contracted Parties. In addition to the legally required components of such agreement, the agreement shall specify the responsibilities of the respective parties for the processing activities as described therein. Indemnification clauses shall ensure that the risk for certain data processing is borne by either one or multiple parties that determine the purpose and means of the processing. [Due consideration should be given to the analysis carried out by the EPDP Team in its Final Report.] Action: Please indicate on the mailing list whether you have any concerns about these modifications and/or what other aspects of this recommendation should be discussed. Deadline: Monday, 28 January, additional email discussion might follow depending on responses. Sincerely, Kurt

1 0

Proposed Agenda for EPDP Team Meeting - Thursday, 24 Jan 1400 UTC
by Caitlin Tubergen Jan. 23, 2019

Jan. 23, 2019

Dear EPDP Team, Please find below the proposed agenda for the next EPDP Team meeting which has been scheduled for Thursday, 24 January at 14.00 UTC. Best regards, Caitlin, Berry and Marika -- EPDP Meeting #39 Agenda Thursday, 24 January 2019 Roll Call & SOI Updates (5 minutes) Welcome and Updates from EPDP Team Chair (5 minutes) Update on Data Elements Small Team Update on Legal Committee Other updates, if applicable Continue review of public comments on Initial Report (See Question 3 PCRT) Geographic Basis Silent review of comments received (see PCRT and discussion table at https://community.icann.org/x/U4cWBg) (5 minutes) Question for team: which concerns / data elements merit group discussion? Specifically, do any of the concerns / data elements suggested present new information the EPDP Team has not discussed during its formulation of this purpose or recommendation? (20 minutes) Confirmation of agreement reached or next steps to come to agreement (5 minutes) Meaning of Optional (See Rec. 4 PCRT (Question 2)) Silent review of comments received (see PCRT and discussion table at https://community.icann.org/x/U4cWBg) (5 minutes) Question for team: which concerns / data elements merit group discussion? Specifically, do any of the concerns / data elements suggested present new information the EPDP Team has not discussed during its formulation of this purpose or recommendation? (20 minutes) Confirmation of agreement reached or next steps to come to agreement (5 minutes) 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) Silent review of comments received (see PCRT and discussion table at https://community.icann.org/x/U4cWBg) (5 minutes) Question for team: which concerns / data elements merit group discussion? Specifically, do any of the concerns / data elements suggested present new information the EPDP Team has not discussed during its formulation of this purpose or recommendation? (20 minutes) Confirmation of agreement reached or next steps to come to agreement (5 minutes) Recommendation 5 – Data elements to be collected by registries: the team will review the public comments while small teams will review the data elements (30 minutes) – TIME PERMITTING Silent review of comments received (see PCRT and discussion table at https://community.icann.org/x/U4cWBg) (5 minutes) Question for team: which concerns / data elements merit group discussion? Specifically, do any of the concerns / data elements suggested present new information the EPDP Team has not discussed during its formulation of this purpose or recommendation? (20 minutes) Confirmation of agreement reached or next steps to come to agreement (5 minutes) Recommendation 11 – Data retention Silent review of comments received (see PCRT and discussion table at https://community.icann.org/x/U4cWBg) (5 minutes) Question for team: which concerns / data elements merit group discussion? Specifically, do any of the concerns / data elements suggested present new information the EPDP Team has not discussed during its formulation of this purpose or recommendation? (20 minutes) Confirmation of agreement reached or next steps to come to agreement (5 minutes) Wrap and confirm next meeting to be scheduled for Tuesday, 29 January 2019 at 14.00 UTC (5 minutes) Confirm action items Confirm questions for ICANN Org, if any

1 0

REMINDER--Meeting Invitation: Alternates & Observers / GNSO Temp Spec gTLD RD EPDP call / Thursday, 24 January 2019 at 14:00 UTC for 3 hours
by Andrea Glandon Jan. 23, 2019

Jan. 23, 2019

Dear all, Non-members can follow the EPDP call taking place on Tuesdays and Thursdays via the audio cast or view only Adobe Connect room. As requested and discussed on Tuesday's (14 August 2018) meeting, please note that an additional Adobe Connect room has been created for use by interested alternates and observers to be able to view-only the main EPDP Team Adobe Connect room. The view-only room will also broadcast the audio of the EPDP Team AC room, however, those in the view-only room will not be heard. Note that the audio cast stream will also remain available for now for those that prefer to use that option to listen live to the EPDP Team meeting. View-Only Adobe Connect room for alternates and observers: https://participate.icann.org/gnso-epdp-observers Meeting Audio Cast (for alternates and observers) To join the event, click on the link: Listen in browser: http://stream.icann.org:8000/stream01 [stream.icann.org]<https://urldefense.proofpoint.com/v2/url?u=http-3A__stream.icann.org-3A8000…> Listen in application such as iTunes: http://stream.icann.org:8000/stream01.m3u [stream.icann.org]<https://urldefense.proofpoint.com/v2/url?u=http-3A__stream.icann.org-3A8000…> Agenda wiki page: https://community.icann.org/x/9JUWBg Thank you. Kind Regards, Andrea

1 0