- Gnso-epdp-team - lists.icann.org

RrSG proposed Recommendation #11
by Sarah Wyld Jan. 25, 2019

Jan. 25, 2019

Hello All, For Recommendation 11, the RrSG has the following proposed new text and comments: *New text:* 1) The EPDP team recommends that ICANN, as soon as is practicable, undertakes a review of all its active processes and procedures so as to identify and document the instances in which personal data are requested from a registrar beyond the period of the 'life of the registration'. Retention periods for specific data elements should then be identified and documented, and relied upon to establish the required relevant and specific minimum data retention expectations for registrars. 2) In the interim, the EPDP team has recognized that the Transfer Dispute Resolution Policy (“TDRP”) has been identified as one such process. The EPDP team therefore recommends that ICANN should direct registrars to retain only those data elements deemed necessary for the purposes of the TDRP, for a period of one year following the life of the registration. This retention is grounded on the stated policy stipulation within the TDRP that claims under the policy may only be raised for a period of 12 months after the alleged breach (FN: see TDRP section 2.2) of the Transfer Policy (FN: see Section 1.15 of TDRP). Such retained data may only be used in relation to a specific TDRP complaint; should a Registrar use the retained data for any other purpose, they would do so under their own Controllership. 3) The EPDP team recognizes that Contracted Parties may have needs or requirements for different retention periods in line with local law or other requirements. The EPDP team recommends that nothing in this recommendation, or in separate ICANN-mandated policy, should prohibit contracted parties from setting their own retention periods beyond that which is expected in ICANN policy. Similarly, should local law prevent retention for the minimum period as set by ICANN, the ePDP team recommends that a suitable waiver procedure is put in place that can address such situations. In addition, the waiver procedure should be reviewed to determine if it would be appropriate for other CPs to “join” themselves to an existing waiver upon demonstration of being subject to the same law or other requirement that grounded the original waiver application. *Notes:* - incorporates suggested new text & comments from email list discussion (thanks Alan W for your insights!) - spells out that the data can only be used for specified retention purposes (or, if used for other purpose, that would be a separate Controller decision) -- Sarah Wyld Domains Product Team Tucows +1.416 535 0123 Ext. 1392

2 1

Response from ICANN Compliance re. registrations under the 2009 RAA
by Marika Konings Jan. 25, 2019

Jan. 25, 2019

Dear EPDP Team, Hereby the response from ICANN Compliance in relation to a question that was raised during this week’s meeting: 1. What happens to registrations that were made under the 2009 RAA? Is the registrar now required to collect additional contact information that is required under the 2013 RAA? Registrars are not required to collect additional contact information for 2009 Registrar Accreditation Agreement (RAA) registrations. However, registrars may be required to update existing contact information for 2009 RAA registrations when there is a triggering event under the 2013 RAA that may require them to do so (e.g., the domain name is an inbound transfer, the registrant changes, there is information to suggest the current contact information is incorrect). This response will get posted here: https://community.icann.org/x/ahppBQ. Best regards, Caitlin, Berry and Marika 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

Notes, action items and outcomes of today's EPDP Team meeting
by Marika Konings Jan. 25, 2019

Jan. 25, 2019

Dear EPDP Team, Please find below the notes, action items and outcomes of today’s EPDP Team meeting. Best regards, Caitlin, Berry and Marika ================= EPDP Team Meeting #38 Tuesday, 22 January 2019 Notes and Action Items EPDP Team Outcomes: * Recommendation #3 agreement to leave as is in the Initial Report. EPDP Team to ensure that check is done at the time of access model discussions to ensure that accuracy requirements are not impaired. * Recommendation #14: update language to caveat that this recommendation represents the best thinking of the group based on the analysis to date, but there is an iterative process as this Recommendation will be affected by the finalization of the necessary agreements that would define the roles and responsibilities. Staff support team to review final work product on data elements workbooks to ensure consistency with the tables under this recommendations. Should further guidance become available before finalization of the Final Report, EPDP Team can reconsider. High-level Notes/Actions: Action item #1: Kurt to draft question for submission to legal committee for Ruth re. what accuracy requirements under GDPR mean and what the impact could/should be on the EPDP Team recommendations. Action item #2: City field: EPDP Team to reconsider information provided and viewpoints expressed in relation to publication of city field. Should positions change on the basis of that reconsideration, this should be communicated to the list. In accordance with Stephanie’s formal request, the EPDP Legal Committee will discuss drafting a question regarding the city field to legal counsel. Action item #3: Staff support team to put forward proposed revisions to recommendation #14 in line with the agreement that was reached in principle. Action item #4: EPDP Team to review general comments and bring to the list which other items need further consideration now, which could be addressed later and which are / may be addressed by other groups. Action item #5: Leadership team to review general comments discussion table and put forward a proposal for how each item is to be addressed or should be addressed. Action item #6: EPDP Team to commence their review on the draft Final Report as soon as possible. Questions for ICANN Org from the EPDP Team: None Notes & Action items These high-level notes are designed to help the EPDP Team navigate through the content of the call and are not meant as a substitute for the transcript and/or recording. The MP3, transcript, and chat are provided separately and are posted on the wiki at: https://community.icann.org/x/ZwPVBQ. Proposed Agenda: 1. Roll Call & SOI Updates * Attendance will be taken from Adobe Connect * Remember to mute your microphones when not speaking and state your name before speaking for transcription purposes. * Please remember to review your SOIs on a regular basis and update as needed. Updates are required to be shared with the EPDP Team. 2. Welcome and Updates from EPDP Team Chair (5 minutes) a. Recap from F2F meeting and next steps b. Review of outstanding action items c. Other updates, if applicable * Thank you for all your efforts and work in Toronto * Make sure to have PCRTs and comment summaries available (see https://community.icann.org/x/U4cWBg) * Please make sure to review emails that have and will be circulated - important to flag by the deadline when items need to be discussed further. * Request to reconsider travel support for Kobe. Will likely be in phase 2. Would require additional budget allocation. General methodology for how GNSO meetings are run is expected to be applied - remote participation will be available. * ARS - is it possible to modify compliance purpose to cover also ARS. Could it be part of accuracy discussion? Need to separate accuracy from data quality (ARS). 3. Continue review of public comments on Initial Report a. Recommendation #3 WHOIS Accuracy – “The EPDP Team recommends that requirements related to the accuracy of registration data under the current ICANN contracts and consensus policies shall not be affected by this policy” (30 minutes) i. Silent review of comments received (see PCRT and discussion table at https://community.icann.org/x/U4cWBg) (5 minutes) ii. Question for team: which concerns merit group discussion? Specifically, do any of the concerns present new information the EPDP Team has not discussed during its formulation of this purpose or recommendation? (20 minutes) iii. Confirmation of agreement reached or next steps to come to agreement (5 minutes) * See SSAC comments. Linked to phase 2. Not intended to change the existing recommendation. * Would it be worth asking Ruth to clarify what accuracy requirements entail under GDPR? Legal committee to consider question on this topic. The group has different interpretations as to what 'accuracy' means under GDPR. Legal advice is not expected to change this recommendation but may help inform future work. Make sure that any question is specific as possible, e.g. Does controller have any responsibilities in relation to accuracy and if so, what would those be? * Consider moving this work to phase 2? * This appears to be a policy issue, not GDPR compliance. Could be dealt with later. * Should EPDP Team evaluate whether existing accuracy procedures comply with GDPR? * The party collecting data must make sure that the data is accurately put into their system. So this is a requirement for the registrars in particularly to ensure that the data - as provided by the data subject - is processed accurately. * Need to ensure that compliance has the ability to do their job - aligns with how recommendation is worded at the moment. * EPDP Team agreement to leave recommendation #3 as is. EPDP Team to ensure that check is done at the time of access model discussions to ensure that accuracy requirements are not impaired. Action item #1: WHOIS accuracy - Kurt to draft question for submission to legal committee for Ruth re. what accuracy requirements under GDPR mean and what the impact could/should be on the EPDP Team recommendations. b. Recommendation 9 – Data redaction - City (30 minutes) i. Review of ICANN Org response to question on this topic (see https://mm.icann.org/pipermail/gnso-epdp-team/2019-January/001250.html) (5 minutes) ii. Deliberate (20 minutes) iii. Confirmation of agreement reached or next steps to come to agreement (5 minutes) * Initial Report recommended to keep Temp Spec requirements for City which means redaction, with IPC/BC noting that it should be unredacted. * Discussed during F2F meeting with several expressing support for not redacting. ICANN Org information shared re. rationale for redaction. * Response from Org speaks to City and postal code, not specifically city. Combination of city and postal code is what could be problematic, not necessarily just city. * In smaller places, identifying city could be an issue. * See also discussion held by RDS PDP WG on this topic. * Redaction of city is compliant per the Temporary Specification, so why change it now. * Useful field for the reasons of jurisdiction. * Need to assess support across different groups and determine whether consensus exists. * Everyone encouraged to review the information that has been provided on this subject to be able to opine. Consider asking for legal guidance. * Show of hands of those who cannot live with sticking with the temporary specification requirement of redacting city field: IPC, GAC, BC. Document in the Final Report those that cannot live with it. Action item #2: City field: EPDP Team to reconsider information provided and viewpoints expressed in relation to publication of city field. Should positions change on the basis of that reconsideration, this should be communicated to the list. In accordance with Stephanie’s formal request, the EPDP Legal Committee will discuss drafting a question regarding the city field to legal counsel. 10 minute break c. Recommendation #14 Responsible Parties (30 minutes) i. Silent review of comments received (see PCRT and discussion table at https://community.icann.org/x/U4cWBg) (5 minutes) ii. Question for team: which concerns merit group discussion? Specifically, do any of the concerns present new information the EPDP Team has not discussed during its formulation of this purpose or recommendation? (20 minutes) iii. Confirmation of agreement reached or next steps to come to agreement (5 minutes) * Comments do not seem to focus on specific changes * Some of this may get determined / dictated by the agreements that are put in place. Should a small team review the table and determine whether any updates need to be made? * What concerns have been raised that need to be addressed in the recommendation? * These are issues where there is disagreement, but it is not a matter of what the parties say but it is a matter law. * Caveat the analysis in some way. Further work is being done. This could help inform those deliberations but it cannot be determinative. Best thinking of the group based on the analysis to date, but there is an iterative process in the form of the necessary agreements which would define the roles and responsibilities. CPH will need to have appropriate agreements with ICANN with regard to data processing. * Will need to review the processing flows after purposes are finalized and data element workbooks have been finished. For example, UDRP is one area where data processing flows are not clear. Note that a small team will meet later today to work on the data elements workbooks. Focus is on post-filing data flows. * Will need to be further detailed in the context of the discussions on the appropriate agreements between CP and ICANN Org. * Path for settling is greater than the time this group has available. * This is dependent on appropriate agreements being in place, as these would inform these recommendations. See also recommendation #13. Obligation for ICANN Org to come to the table. * EPDP Team outcome on recommendation #14: update language to caveat that this recommendation represents the best thinking of the group based on the analysis to date, but there is an iterative process as this Recommendation will be affected by the finalization of the necessary agreements that would define the roles and responsibilities. Staff support team to review final work product on data elements workbooks to ensure consistency with the tables under this recommendations. Should further guidance become available before finalization of the Final Report, EPDP Team can reconsider. Action item #3: Staff support team to put forward proposed revisions to recommendation #14 in line with the agreement that was reached in principle. d. General Comments (30 minutes) i. Silent review of comments received (see PCRT and discussion table at https://community.icann.org/x/U4cWBg) (5 minutes) ii. 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 in the context of the Initial Report? (20 minutes) iii. Confirmation of agreement reached or next steps to come to agreement (5 minutes) * Some issues flagged have already been taken up or have been addressed. * Need to further consider Thick WHOIS recommendation as well as P/P recommendation. * Thick WHOIS - may be mixing topics. Group has discussed transfer of data from registrar to registry, but that may not be the same as a registry displaying THICK WHOIS output. EPDP Team should consider disclosure at registry level. What needs to happen in phase 1 and what needs to happen in phase 2, and what is best left to another group? Different options to consider on the table. Consider this topic further in the context of recommendation #5, noting that disclosure is a separate topic from transfer. Or should this be taken up in phase 2? * P/P - additional recommendation as to how to handle P/P registrations: "In the case of a domain name registration where a privacy/proxy service used (e.g. where data associated with a natural person is masked), Registrar MUST return in response to any query full WHOIS data, including the existing proxy/proxy pseudonymized email". What was in the Temporary Specification - need to confirm. Current language is: 2.6. Notwithstanding Sections 2.2, 2.3, 2.4, and 2.5 of this Appendix, in the case of a domain name registration where a privacy/proxy service used (e.g. where data associated with a natural person is masked), Registrar MUST return in response to any query full WHOIS data, including the existing proxy/proxy pseudonymized email. Need to consider this further and implications on GDPR. * Consider deferring these issues to another group to further review. * Consider doing further triage – does it require changes to our Initial Report recommendations, does it require phase two work, or is there another group who is / should deal with this. * Leadership team to review and make a proposal * Look at suggestion of reconsidering definition of gTLD registration data – bring this to the list. Action item #4: EPDP Team to review general comments and bring to the list which other items need further consideration now, which could be addressed later and which are / may be addressed by other groups. Action item #5: Leadership team to review general comments discussion table and put forward a proposal for how each item is to be addressed or should be addressed. 4. Next steps to get to Final Report (15 minutes) a. See draft Final Report circulated to the mailing list (see https://drive.google.com/a/icann.org/file/d/1E6W-daNTaadOhG5BRlzNJQbrT9MSoK…) b. Initial thoughts and suggestions c. Process for review (see https://docs.google.com/document/d/1sVZ9odV0qK1Bk8a4bDwWe5RW_PBzOnYBhHW_GnL…) Action item #6: EPDP Team to commence their review on the draft Final Report as soon as possible. 5. Wrap and confirm next meeting to be scheduled for Thursday, 24 January 2019 at 14.00 UTC (5 minutes) a. Confirm action items b. Confirm questions for ICANN Org, if any 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…>.

3 3

Organization Field - Updated - Recommendation #9
by Kurt Pritz Jan. 25, 2019

Jan. 25, 2019

Hi Everyone: In the ongoing and seemingly never-ending attempt to close discussion on Recommendations for the Final Report via email discussion, below please find amended wording for Recommendation 9, having to do with the publication / redaction of the Organization field. After posting of the initial version, I read the email list comment and was drawn to James’ rather clean outline, as opposed to my less clear earlier proposal. Therefore, I took the liberty of reorganizing the proposed Recommendation somewhat, taking into account not only James structure but also the email comments before and after that (as well as the meeting notes). The result is below. I also placed the procedure itself as part of our “implementation advice” as there will be operational details to figure out. The implementation effort can ensure that those “details” are consonant with the policy goals. Proposed Recommendation #9 The EPDP Team recommends that: - The Organization field will be published if that publication is acknowledged or confirmed by the registrant via a process that can be determined by each registrar. If the registered name holder does not confirm the publication, the Organization field can be redacted or the field contents deleted at the option of the registrar. - The implementation will have a phase-in period to allow registrars the time to deal with existing registrations and develop procedures. - In the meantime, registrars will be permitted to redact the Organization Field. Implementation advice: the implementation review team should consider the following implementation model discussed by the EPDP Team: For existing registrations, the first step will be to confirm the correctness / accuracy of the existing Organization field data. For the period between the adoption of EPDP policy recommendations and some future “date certain” to be determined by the implementation review: 1) Registrars will redact the Organization field 2) Registrars will contact the registered name holders that have entered data in the Organization field and request review and confirmation that the data is correct. a. If the registered name holder confirms or corrects the data the data will remain in the Organization field. b. If the registrant declines, or does not respond to the query, the Registrar may redact the Organization field, or delete the field contents. If necessary, the registration will be re-assigned to the Registered Name Holder. 3) If Registrar chooses to publish the Registrant Organization field, it will notify these registered name holders that of the “date certain,” the Organization field will be treated as non-personal data and be published, for those Registered Names Holders who have confirmed the data and agreed to publication. For new registrations, beginning with the “date certain”: 1) New registrations will present some disclosure, disclaimer or confirmation when data is entered in the Organization field. Registrars are free to develop their own process (e.g., opt-in, pop-up advisory or question, locked/grayed out field). 2) If the registered name holder confirms the data and agrees to publication: a. the data in the Organization field will be published, b. The Organization will be listed as the Registered Name Holder. c. The name of the registered name holder (a natural person) will be listed as the point of contact at the Registrant Organization. Actions: 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 for comment: Tuesday 29 Jan. Thank you and best regards, Kurt

2 1

Re: [Gnso-epdp-team] Overview of status and deadlines for review
by Marika Konings Jan. 25, 2019

Jan. 25, 2019

Dear EPDP Team, Note that the staff support team has created a wiki page where you can find all the information in relation to the draft Final Report as well as the latest version of the status of review doc and related deadlines, see https://community.icann.org/x/VZwWBg. We hope this is helpful. Best regards, Caitlin, Berry and Marika From: Gnso-epdp-team <gnso-epdp-team-bounces(a)icann.org> on behalf of Marika Konings <marika.konings(a)icann.org> Date: Thursday, January 24, 2019 at 23:20 To: "gnso-epdp-team(a)icann.org" <gnso-epdp-team(a)icann.org> Subject: [Gnso-epdp-team] Overview of status and deadlines for review Dear EPDP Team, As requested, hereby the overview of the different purposes / recommendations for which language has been circulated and the deadline for input: Recommendation / Purpose # Due Date Recommendation #1 Friday, 25 January Recommendation #4 Tuesday 29 January (to be circulated) Recommendation #7 Wednesday, 30 January Recommendation #9 Thursday, 24 January (updated version to be shared shortly addressing input received) Recommendation #10 Monday, 28 January Recommendation #11 Friday, 25 January Recommendation #13 Monday 28 January Recommendation #14 Monday, 28 January Geographic Differentiation Tuesday, 29 January (to be circulated) ICANN Org Questions & Assessment Wednesday, 30 January Attached you will find further details (including the proposed language) on these and other recommendations. Best regards, Caitlin, Berry and Marika 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

Overview of status and deadlines for review
by Marika Konings Jan. 25, 2019

Jan. 25, 2019

Dear EPDP Team, As requested, hereby the overview of the different purposes / recommendations for which language has been circulated and the deadline for input: Recommendation / Purpose # Due Date Recommendation #1 Friday, 25 January Recommendation #4 Tuesday 29 January (to be circulated) Recommendation #7 Wednesday, 30 January Recommendation #9 Thursday, 24 January (updated version to be shared shortly addressing input received) Recommendation #10 Monday, 28 January Recommendation #11 Friday, 25 January Recommendation #13 Monday 28 January Recommendation #14 Monday, 28 January Geographic Differentiation Tuesday, 29 January (to be circulated) ICANN Org Questions & Assessment Wednesday, 30 January Attached you will find further details (including the proposed language) on these and other recommendations. Best regards, Caitlin, Berry and Marika 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…>.

2 1

ICANN Org Questions - draft assessment and topics for further discussion
by Marika Konings Jan. 25, 2019

Jan. 25, 2019

Dear All, The staff support team went through the ICANN Org questions that were submitted in December in relation to the Temporary Specification provisions and the impact of the EPDP Team’s recommendations on those, especially in those case where the team’s recommendations are currently silent. Having gone through the table, it is our assessment that most of the questions have, or are being addressed, or are expected to be addressed in the context of implementation. However, there are a couple of topics where EPDP Team guidance may be necessary so that appropriate provisions can be made in the Initial Report and/or during implementation. Attached you will find the draft assessment (last column on each tab). Of course, if you disagree with the assessment and/or identify additional topics that require EPDP Team consideration, please flag those by Wednesday 30 January. The topics that may require further guidance are: * RDAP and SLAs – what recommendations and/or guidance needs to be included in the Final Report, or is this to be addressed during implementation? * Bulk data registration access to ICANN – should the requirements in the Temp Spec be confirmed by the EPDP Team in the Final Report? * Process for amendments to Registry – Registrar agreements – should the process in the Temp Spec be confirmed as a policy recommendation, or is this to be addressed during implementation? * Does the ‘consent’ provision in the Temporary Specification require confirmation in the Final Report or is this to be addressed during implementation as consent is already defined in the GDPR? * RDDS Search Capabilities - should the requirements in the Temp Spec be confirmed by the EPDP Team in the Final Report or is this to be further considered in phase 2? You are encouraged to share your perspectives on these topics on the mailing list prior to next Thursday’s meeting where we hope to run through these items, and any other topics that may have been flagged, to close on these items. The leadership team may also identify further items for discussion. Best regards, Caitlin, Berry and Marika 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

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