Dear All, Please find below the notes and action items from today’s small team B meeting. Best regards, Caitlin, Berry and Marika Small Team B Meeting #1 Thursday, 8 January 2019 Notes and Action Items Small Team B Participants: * James Bladel (Sarah Wyld - alternate) (RrSG) * Hadia El Miniawi (ALAC) * Amr Elsadr & Ayden Férdeline (NCSG) * Chris Lewis-Evans (GAC) * Steve DelBianco (BC) * Marc Anderson & Kristina Rosette (RySG) * Thomas Rickert (ISPCP) * Brian King (IPC) * Benedict Addis (SSAC) * Leon Sanchez (ICANN Board Liaison) * Trang Nguyen (ICANN Org Liaison -GDD) * Rafik Dammak (GNSO Council Liaison) Proposed approach to address concerns expressed (for review by EPDP Team): * For Purpose 3: Proposed rewording ‘Enable communication with the Registered Name Holder on matters relating to the Registered Name’. * For Recommendation #19: No change or updates needed. Actions Items: Action item #1: Small team to further consider, possibly in consultation with their respective groups, if/how recommendation #16 should be modified to address concern. Steve, Brian, James and Kristina specifically requested to look at this jointly and see if they can come back with a proposed path forward by Thursday's meeting. Action item #2: Kristina to put together a chart that sets out the specific requested changes in relation to purpose 5 with the objective to identify a potential compromise. Come back to this on Thursday. Action item #3: Staff will update the discussion tables with the proposed responses to the comments based on the discussion today for small team B review. Action item #4: Small team members are expected to update their colleagues on the progress and deliberations of today’s small team B meeting. Action item #5: Small team members are to review the PCRTs and discussion tables for the remaining topics and flag, if possible, prior to the meeting which comments require further discussion. 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 1. Roll Call * 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. Introduction * See message that was circulated yesterday with the proposed approach * Some discussion on the list in relation to the approach - appreciate all input. All focused on moving forward. * Objective is to complete the work within the time allocated. * Small team approach is focused on multiplying our efforts, but significant time will need to be devoted by everyone in preparation for the F2F meeting. * Need to find a way to confirm and/or reconsider if deemed necessary conclusions in the Initial Report. * Collective responsibility of EPDP Team to review and consider input received and deliver Final Report. * Encourage to take the task of review of comments as a group task and look beyond comments that have been submitted by respective groups and consider the bigger picture. * Request to give this approach a try - leadership will review after this meeting and course correct, if needed. * CPH is of the view that this will overcomplicate the process and will add additional time and wants to formally note it objection. Noted by leadership and appreciate willingness to continue. a. Purpose 3 - Enable communication with RNH * See Discussion Table - concerns have been grouped together where possible to facilitate consideration. * 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? * Concerns may be addressed by simple edits? Could frame things more briefly (e.g. enable communication with RNH of issues with a Registered Name). This would simplify and address the concerns raised (e.g. delegated agents do not need to be called out as if acting on RNH they would be covered). However, there may be situations where the RNH is not the direct user, for example where web-site is used by contract (enable communication with RNH or delegated agents with a Registered Name). * How to balance specificity with making sure no exclusions? Would it be easier to just add 'legal' and be specific? Issues / matters relating to the registered domain name would pass muster re specificity. * People could assume that anything not called out is excluded here - that should be avoided. Original references to technical and administrative issues were derived from existing admin / tech contact, there is no such contact currently for legal so better to be general so all issues in relation to domain name registration are covered. * EPDP Team could run this by external counsel to see if they raise any issues with being less specific. * RySG does not consider it appropriate to include a reference to delegated agent - not clear if this is appropriate under GDPR. * Same purpose would apply to the delegated agent, if the RNH is legally allowed to do so. * Notification is understood to be covered as part of communication. * Comment in relation to 'billing' - not considered within scope of processing data as an ICANN purpose, is part of registrar purpose. * Deletion of comment - not supported as this purpose is needed to allow for communication, is not covered by purpose 1. * ALAC initially expressed concern about removing delegated agent - but later stated with regard to purpose 3 their agreement on removing the delegated agent with the understanding that it goes without saying the purpose applies to the designated agent and that this has nothing to do with removing or keeping second contacts. Ability to delegate is important, but may not need to be explicitly listed here. This is a purpose for the processing of registration data, this is not about whether or not a RNH can or cannot delegate his/her responsibilities. * Does limiting it to issues with a Registered Name mean that it could involve issues that are outside of ICANN's scope? Proposed approach to address concerns expressed (for review by EPDP Team) in relation to Purpose 3: * Proposed rewording to put forward to EPDP Team for consideration: Enable communication with the Registered Name Holder on matters relating to the Registered Name. b. Recommendation #16 - Instructions for RPM PDP WG * See Discussion Table - concerns have been grouped together where possible to facilitate consideration. * 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? * Concerns are addressed by the recommendation, apart from possibly the first one which was already discussed in the context of this recommendation (no consensus to include it in the recommendation). Proposal to acknowledge commenters and note that these concerns will be addressed by the RPM WG once the Council has instructed that effort to focus on these issues. * Recommendations should also ask to look at disclosure for access under 'reasonable' access category. (BC, IPC, Microsoft). The request is actually to add another recommendation directing a question to the RPM WG to request disclosure when there is a demonstrable connection between the registrant pre-filing. Note that this has been raised previously and was considered. Proposed additional recommendation: EPDP Team also recommends that the GNSO Council instructs the review of all RPMs PDP WG to consider, as part of its deliberations, whether there is a need to develop policy around pre-filing registrant disclosure requests for of a limited number of registrants when there is a good faith belief that the registrants are acting in bad faith and there is an demonstrable connection between the registrants. * For the same reasons that RySG did not support turning this into a recommendation or a purpose, it should not be either passed on to another effort. * Considered extensively but general concern that it is punting a small hole in a damn. As long as referral is not overly prescriptive, it may be possible to consider this, with as little as possible presumption about the outcome. Agreement with that notion. * Would also need to consider what safeguards would need to be put in place to protect the RNH. * Need to review data elements table in relation to disclosure as it currently only reflects that it is provided to DRP and does not factor in disclosure to complainant. Those discussions may better inform this issue. * Groups to consider this with their respective groups, factoring in the notes of today's meeting, and aim to come back by Thursday with a possible path forward. * Note that there is support for recommendation #16 as written. Action item #1: Small team to further consider, possibly in consultation with their respective groups, if/how recommendation should be modified to address concern. Steve, Brian, James and Kristina specifically requested to look at this jointly and see if they can come back with a proposed path forward by Thursday's meeting. c. Recommendation #19 - Transfer Policy * See Discussion Table - concerns have been grouped together where possible to facilitate consideration. * 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? * This concern is being addressed by tech op groups in the GNSO - note this to the commenter in the response. See https://bestpractice.domains/ and https://docs.google.com/document/d/1MfbvbhXnT1aA4iQfxcVoNyLKJb3trMAwJdBKK2re.... Proposed approach to address concerns expressed (for review by EPDP Team) in relation Recommendation #19: * No change or updates needed. d. Purpose 5 - Handling Contractual Compliance * See Discussion Table - concerns have been grouped together where possible to facilitate consideration. * 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? * First concern - broader issue that has been discussed and still under discussion. Take closer look at recommendation #13 and to see the extent to which further refinement would be needed here. Any transfer of data requires some type of agreement. * Second concern - there are a number of different proposals / revisions. Would be helpful to look at this a bit more closely at edits provided and see if/how these can be brought together. For example, RySG has suggested separating out handling, monitoring, audits and complaints submitted. * Third concern - embodied within GDPR complies * Fourth concern - may need some further investigation. Some suggested this should be considered. * Fifth concern - Team is of the view that this is clearly a separate purpose. Action item #2: Kristina to put together a chart that sets out the specific requested changes in relation to purpose 5 with the objective to identify a potential compromise. Come back to this on Thursday. e. Recommendation #10 - Email communication * See Discussion Table - concerns have been grouped together where possible to facilitate consideration. * 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? * Issues at hand seem to be: What technical service, run by whom and whether mandatory or not? Mandatory in two dimensions: for registrar and also for registrant. Consider structuring discussion along those lines. * Some consider web-form not good enough - unredacted email is important, some flag that communications should not have to go through the registrar channel. Web-form is not a good solution for anyone as it would also require additional work/effort on the registrar side. Registrars cannot agree to publicly disclose the email address in order to facilitate this communication. * In relation to no confirmation from web-form, if this is a requirement, compliance could enforce if it is not delivered * Email address disclosure could result in sharing personal information publicly. * Some comments also want email address as an identifier, to (for example) correlate malicious activity. May need to acknowledge that an email address has different functions but recognize that identification is not part of this purpose, need to focus on the communication mechanism. * Come back to this on Thursday -in the meantime, small team to consider how different concerns can be addressed. If no resolution is found, it may have to be brought to the plenary for consideration. Next steps Action item #3: Staff will update the discussion tables with the proposed responses to the comments based on the discussion today for small team B review. Action item #4: Small team members are expected to update their colleagues on the progress and deliberations of today’s small team B meeting. Action item #5: small team members are to review the PCRTs and discussion tables for the remaining topics and flag, if possible, prior to the meeting which comments require further discussion. Marika Konings Vice President, Policy Development Support – GNSO, Internet Corporation for Assigned Names and Numbers (ICANN) Email: marika.konings@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_gns...>.