November 2018 - Gnso-epdp-team

Outstanding administrative initial report items - for mailing list discussion
by Caitlin Tubergen Nov. 9, 2018

Nov. 9, 2018

Dear EPDP Team, As noted in support staff’s email of Tuesday, 6 November and the subsequent discussion during Tuesday’s EPDP Team meeting, support staff organized the outstanding issues in the draft Initial Report based on proposed method of review. The EPDP Leadership Team deemed the final group of items as less controversial, and therefore, recommended a confirmation/discussion over the email list so that the more difficult items could be dealt with during our limited EPDP meeting time. Below, please find a short description of the mailing list review items. In short, if you have feedback on any of the below issues, please consider responding to the list, or, alternatively, noting any concerns in the Initial Report Input Google Doc. (For ease of mark up, the corresponding page in the draft Initial Report and the relevant charter question (if any) are noted below.) Please note that bracketed text indicates draft text proposed by support staff. Please provide any feedback by COB Tuesday, 13 November. Topic: Consensus Policy Updates Initial Report Page: 36 Draft preliminary recommendation: [The EPDP Team recommends that as part of the implementation of these policy recommendations, updates are made to the following existing policies / procedures, and any others that may have been omitted, to ensure consistency with these policy recommendations as a number of these refer to administrative and/or technical contact which will no longer be required data elements: • Registry Registration Data Directory Services Consistent Labeling and Display Policy • Thick WHOIS Transition Policy for .COM, .NET, .JOBS • Rules for Uniform Domain Name Dispute Resolution Policy • WHOIS Data Reminder Policy • Transfer Policy • Uniform Rapid Suspension System (URS) Rules] Question to EPDP Team: Does the draft recommendation accurately reflect the EPDP Team’s discussion at ICANN63 that in order to ensure consistency across ICANN policies, ICANN’s Consensus Policies may have to be updated following adoption of the EPDP Team’s policy recommendations? Topic: Policy Implementation Initial Report Page: 36 Draft recommendation/text: [Although the objective is to keep the timeframe for implementation to a minimum, additional time will be necessary to implement these policy recommendations. As such, the EPDP Team is considering how to avoid a gap between the adoption of these policy recommendations by the ICANN Board and the subsequent implementation, noting the impending expiration of the Temporary Specification requirements. The EPDP Team is considering various options, such as the adoption of an interim policy in the form of the Temporary Specification for a set timeframe or recommending that the Temporary Specification requirements remain in place until the completion of implementation of these policy recommendations. The EPDP Team expects to obtain further guidance from ICANN Org on the options in this regard and make a recommendation accordingly in the Final Report.] Question to EPDP Team: The draft recommendation aims to provide an approach for the potential gap between the adoption of these policy recommendations by the ICANN Board and the subsequent implementation, noting the impending expiration of the Temporary Specification requirements. The recommendation is based on previous discussions, e.g., the discussion from the CPH – ICANN Board meeting at ICANN63. Are there any concerns with the proposed text on p. 36? Topic: Policy Change Impact Analysis Initial Report Page: 37 Draft recommendation/text: [If the WG concludes with any recommendations, the EPDP must include a policy impact analysis and a set of metrics to measure the effectiveness of the policy change, including source(s) of baseline data for that purpose (from the EPDP Team Charter: Determine the policy goals for this exercise, within the parameters set by the Temporary Interim Specification. Identify potential policy goals that were omitted in the Temporary Specification and set aside for further Council deliberation. Determine a set of questions which, when answered, provide the insight necessary to achieve the policy goals. Determine the types of data that may assist the WG in better scoping the issues and identify whether it can be collected within the timeframe, and assemble or substitute information that can be analyzed to help answer each question. Determine a set of metrics which can be applied to the data, analysis, and achievement of policy objectives. Collect this data to the extent feasible, and determine a process for ongoing metric analysis and program evaluation to measure success of this policy process.] [Per the EPDP Team’s Charter, the goal of this effort is to determine if the Temporary Specification for gTLD Registration Data should become an ICANN Consensus Policy, as is or with modifications, while complying with the GDPR and other relevant privacy and data protection law. As part of this determination, the EPDP Team is, at a minimum, expected to consider the elements of the Temporary Specification as outlined in the charter and answer the charter questions. The EPDP Team shall consider what subsidiary recommendations it might make for future work by the GNSO which might be necessary to ensure relevant Consensus Policies, including those related to registration data, are reassessed to become consistent with applicable law”. The EPDP Team will further consider a set of metrics to help inform the evaluation to measure success of these policy recommendations, but would welcome input during the public comment period on the set of metrics that should be considered.] Question to EPDP Team: The draft recommendation notes that further consideration to an impact analysis and corresponding proposed metrics will need to be assessed in the next phase of the EPDP Team’s work. Is this proposed text on p. 37 acceptable for inclusion in the Initial Report? Topic: Length of Public Comment Period Initial Report Page: 4 Draft Text: This Initial Report will be posted for public comment for [30 days]. Question to EPDP Team: Is the EPDP Team OK with a 30-day public comment period? Note: the minimum public comment period for an EPDP Initial Report is 30 days, and this minimum period is suggested due to the short timeline the EPDP Team for completing its work. Topic: Sunsetting WHOIS requirements Initial Report Page: 35-36 Charter question(s): q) Sunsetting WHOIS Contractual Requirements q1) After migration to RDAP, when can requirements in the Contracts to use WHOIS protocol be eliminated? q2) If EPDP Team’s decision includes a replacement directory access protocol, such as RDAP, when can requirements in the Contracts to use WHOIS protocol be eliminated? Proposed Text: [At the time of publication of this Initial Report, the EPDP Team elected to prioritize its policy recommendations with respect to the Temporary Specification. The EPDP Team believes addressing eventual migration to RDAP and sunsetting of WHOIS requirements is premature at this time, i.e., before the policy recommendations are finalized. Following receipt of further feedback from the ICANN Community and Data Protection Authorities (if received), the EPDP Team will finalize its recommendations with respect to the Temporary Specification. In the process of this finalization, the EPDP Team will consider drafting implementation guidance regarding the eventual migration to RDAP and consequent sunsetting of WHOIS requirements. While the exact date of the possible elimination of WHOIS requirements will be determined in the policy implementation phase, the EPDP Team notes any current WHOIS requirements negated or made redundant by eventual policy recommendations will no longer be required.] Question to EPDP Team: Is the EPDP Team OK with this proposed text as a response to Charter Questions q1 and q2? Thank you. Best regards, Marika, Berry and Caitlin

1 0

Notes and action items from today's EPDP Team meeting - 8 November 2018
by Caitlin Tubergen Nov. 8, 2018

Nov. 8, 2018

Dear All, Please find below the notes and action items from today’s EPDP Team meeting. Best regards, Marika, Berry and Caitlin EPDP Team Meeting #24 8 November 2018 High-level Notes/Action Items 1. Any EPDP Team members wishing to work with Thomas and the small group on the responsible parties/joint controllership discussion, should reach out to Thomas and complete the small group doodle poll as soon as possible. 2. Support Staff will the rework language for natural vs. legal persons to the mailing list so that EPDP Team members can include and/or correct their own viewpoints. Please propose edits by tomorrow, Friday, 9 November. 3. Berry Cobb described inconsistencies in the data matrices and proposed changes to resolve the consistencies. After receiving feedback in today’s meeting, Berry will summarize the revised changes made to the data elements matrix as a result of this discussion and send the summary of proposed changes to the mailing list shortly. Question to ICANN Org: Is making the natural vs. legal persons distinction in WHOIS within the picket fence, i.e., a suitable topic for policy discussion? Notes 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/2IpHBQ. 1. Roll Call & SOI Updates Attendance will be taken from Adobe Connect Please 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 a. Review of outstanding action items Thank you for timely completing all action items from Tuesday’s meeting. Support staff will send open administrative issues within the Initial Report today. Please provide feedback via the Initial Report Input Google Doc by Tuesday, 13 November. b. Other updates, if applicable The Team will announce the F2F location as details become available. Please refer to the Initial Report Input Google Doc to submit any comments or concerns with respect to the draft Initial Report. Support Staff will send an email with outstanding items following this meeting. Please review and note questions or concerns (if any). 3. Review of Responsible Parties Recommendations (Thomas) a. Review and discuss draft recommendations During the last call, Thomas noted there may need to be revisions to the references to responsible parties for the Initial Report. The suggested changes begin on line 900 of the draft Initial Report. The draft recommendation is for ICANN to enter into Joint Controller Agreements (JCA) with the contracted parties. The attachment to Thomas’s email provides more detail about the definitions and the relevant liabilities. Based on this attachment, the table appearing on line 988 would need be be updated to reflect the text in the attachment. The EPDP Team will need to confirm the draft text, the current allocation of responsible parties, and confirm if the EPDP Team would like to liaise with ICANN as to whether ICANN org has concerns about entering into JCAs with contracted parties. Question for EPDP Team: should the EPDP Team assist in the drafting of an JCA or drafting the framework of the JCA? Does the team believe a policy recommendation regarding ICANN and Contracted Parties being joint controllers should be added to the report? EPDP Team Feedback The primary purpose of a JCA is the apportioning of liability. The Team needs to recognize it is apportioning liability, and the utmost care needs to be taken with respect to this. It may be inappropriate for the EPDP Team to draft a specific legal agreement; however, recommending a negotiation b/w ICANN and contracted parties could be an appropriate recommendation. There are parts of this agreement that may be outside the picket fence; however, multi-party negotiations often take a long time, and the extent the Team could provide language or a sample agreement as a starting point could be helpful in this instance. The Team could specify the objectives or guiding principles of the JCA. The Team should not negotiate contract language at this time; the Team's current focus should be on answering the charter questions. The JCA negotiation is best left to attorneys. However, the previous suggestion regarding adding principles or the objective of the JCA into the Initial Report makes sense. With respect to the workbooks, how should the team proceed? The group needs to take one of two approaches: the (1) Thomas approach (adding proposed language to body of Initial report) or (2) ensuring consistency in the workbooks with respect to responsible parties. Joint controller agreements are similar to data processing agreements - if the Team provides a draft it would lay out the processing activities and responsible parties and it could help ICANN apply the Team's policy work. Defining roles and responsibilities is within the Team's charter, and the answers to the relevant charter questions could help inform the eventual JCA. Question to the Team: does the Team support Thomas, Diane and ICANN org fleshing out the memo to draft a policy recommendation? The Team has resistance to drafting a JCA, so perhaps the drafting should be put aside. The question that needs to be answered first and foremost, how far does the question on responsibilities go? Does it end with who should be responsible for what? It may be helpful for the community to have more context within the Initial Report. The Team needs to look at the responsibilities in the workbooks. Regardless to what extent the team may draft a JCA, this would not be a policy recommendation - it will just be an aid to those implementing the policy recommendations. Encourage the team to reread the relevant charter questions and make sure the questions are answered in the Initial Report. b. Confirm next steps, if any Those who would like to assist with the JCA recommendation should send an email to Thomas Rickert and respond to the doodle poll referenced above. 4. Review proposed updates to staff-suggested Natural vs. Legal persons text a. Review and discuss draft approach Support Staff has been rapidly updating this language as suggestions come in. For the next iteration, the language will include direct quotes from both sides. The request for research was agreed to by the small team. This did not suggest contract updates, so the Team may be overthinking this. Rather than declaring where the consensus is, it is clear that some positions will not obtain consensus. In other words, presenting an option that many are not considering should not be included in the Initial Report. Minority opinions should be represented in the discussion, but it should be made clear that some positions may not obtain consensus. The Team should be very clear in the Final Report on what are consensus recommendations and what are not. In order to get the best responses in the public comment period, the views need to be clear. There does not have to be a formal consensus call before the Initial Report is published. Team Members can continue to write their views to the list for inclusion in the Initial Report language. It is inappropriate to make statements regarding consensus at this time. Also, this is within the picket fence as it relates to WHOIS. Question to ICANN: is making natural vs. legal persons distinction in WHOIS within the picket fence? Sweeping statements about issues never reaching consensus is inappropriate. Perhaps we can come to consensus on research the natural vs. legal. More research especially on who bears liability when data subjects identify themselves as legal persons seems logical - especially in posing this question to the EPDB. This policy recommendation could send the group backwards. The CPH is saying this is not currently possible, why do some EPDP members continue to say this distinction is necessary? b. Confirm next steps, if any EPDP Team Members to provide additional feedback on this by tomorrow (Friday, 9 Nov) 5. Review of Consolidated Data Elements Matrix Please refer to the attachments from Berry's email of 7 November. The consolidated matrix combines the similar processing activities, e.g., collection, transfer, disclosure, into one document. The first page shows the processing activities where registrars are asked to collect data. The second page shows the processing activities where registrars are asked to transfer data to registries. This matrix shows what is currently denoted in the workbooks. On the far right, there is a column listed as transmission logic - this analyzes all of the columns to the left. If the item is optional, it is denoted in yellow. If an item is required, it is denoted in green. Data elements that are not required or optional are denoted in red. In reviewing registry escrow, the Team agreed that registries would only escrow the data elements that are transferred to them - in other words, the green and yellow elements in this matrix. Within the current workbook for purpose M, there are many data elements that are requested to go from the registrar to the registry. In the macro sense - this brings up three questions: 1. Post GDPR, is the compliance team's assessment correct that registrars do not need to transfer data to registries for this purpose? 2. At any point when a provider needs to have the registration data revealed, in all cases, the Provider contacts the registrar to acquire that data, so does that mean transfer of certain data elements from registrar to registry is not warranted under Purpose M? 3. In looking at the PDDRP and RRDRP, if one of these RPMs is invoked, does data need to be transferred from the registrar to the registry? Feedback from EPDP Team: For the URS, there is a justified transfer for purposes of the URS. In pre-GDPR complaints, wouldn't the Provider have to go to the registrar for underlying data in a privacy/proxy case? This issue may need to be flagged for the RPMs working group. The matrix may not translate for Initial Report purposes, so a more concise summary could be helpful here. This is done on p. 3. The main intent of these charts to to cross-check and test the logic of the content of the workbooks. In a post-GDPR world, there are cases where the providers are requesting registration data from registries and not registrars, so a draft recommendation for the RPM WG or another PDP to streamline that process. The proposed approach we have listed here is not accurate, so the processing activity of transferring data from a registrar to a registry is correct. It may be reasonable to update the UDRP, and we could include a recommendation that the UDRP be updated to reflect the current realities. For Issue 2, under Purpose A the only two data elements that are transferred are domain name and name servers under 6(1)(b). For the transfer of other data elements, they could be transferred under 6(1)(f). DNSSEC and glue records should be a 6(1)(b). Elements not provided by the registrant are also included in the list elements and should fall into a separate category. For Issue 4, for items flagged as red, we want to confirm some of these may still be necessary – such as registry/registrant ID. There is a notion that the data elements we’re looking at – some are collected by the data subject, while some are generated via the EPP server at the registrar or registry. We are acknowledging that this is the case and some fields marked in red cannot die on the vine as they are used for other policies or inner workings of the DNS. For Issue 3, there are some small inconsistencies for optional data elements. For collection of data by the registrar, for purposes B and C, the Team has identified three optional fields for the tech contact. The tech email is not currently marked as optional, so support staff is suggesting to mark it as optional to ensure consistency across the workbooks. 6. Wrap and confirm next meeting to be scheduled for Tuesday 13 November at 14.00 UTC. a. Confirm action items b. Confirm questions for ICANN Org, if any

1 0

Meeting Invitation: Alternates & Observers / GNSO Temp Spec gTLD RD EPDP call / Tuesday, 13 November 2018 at 14:00 UTC
by Andrea Glandon Nov. 8, 2018

Nov. 8, 2018

Dear all, Non-members can follow the EPDP call taking place on Tuesdays and Thursdays at 14:00 UTC 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/VgPVBQ Thank you. Kind Regards, Andrea

1 0

Re: [Gnso-epdp-team] Purpose M - UDRP Information
by Marika Konings Nov. 8, 2018

Nov. 8, 2018

Thanks, Margie. Per the action item, could you provide further details as to how this disclosure to the complainant is different from the disclosure that is already foreseen under Purpose B (“Maintaining the security, stability and resiliency of the Domain Name System in accordance with ICANN’s mission through the enabling of lawful access for legitimate third-party interests to data elements collected for other purposes identified herein”)? Also, if this disclosure is deemed consistent with Purpose M, in your view, does this mean the UDRP would need to be modified accordingly as it currently does not foresee a step in which the complainant reaches out to the registrar for this information before filing a UDRP? If so, this would need to be noted accordingly in the Initial Report. Best regards, Caitlin, Berry and Marika From: Gnso-epdp-team <gnso-epdp-team-bounces(a)icann.org> on behalf of Margie Milam <margiemilam(a)fb.com> Date: Friday, November 2, 2018 at 8:00 PM To: "gnso-epdp-team(a)icann.org" <gnso-epdp-team(a)icann.org> Subject: [Gnso-epdp-team] Purpose M - UDRP Information Hi- Following up on the action items for this item, please find attached our suggested changes to Purpose M, which include input from the IPC and the BC. We have asked for these additions because it is important to ensure that the complainant is able to fully assess the strength of the claim and the nature of the bad faith of the registrant in order to prove the elements of the dispute resolution process (URS/UDRP). To avoid the filing of ungrounded UDRP complaints, this purpose is fulfilled by making the disclosure before the complaint is filed. Also with regard to the other dispute resolution processes, we note that PDDRPs can be brought based on systemic registrant behavior, and thus there may be instances where this purpose would be relied on to access registrant contact data. Under the PDDRP, the subject matter of the dispute is the gTLD and its use by the operator - including any second-level domain names registered to the registry operator or a related third-party, to the extent the registry operator is complicit in trademark infringement. Similarly RRDRPs are available to complainants to prove a registry is not complying with its registration restrictions, which may require access to registration data, as it relates to the registration restriction. For example, if there is a TLD that is limited to registrants located in a particular geographic region, those elements would need to be accessed for this purpose. There are also registries that have specific RPMs that would fall under this purpose. For example some registries have voluntarily adopted RPMs in their contracts, which would also appear to fall in this Purpose M category (for example, .XXX added a “Rapid Evaluation Service Policy” procedure in their registry agreement to address abusive registrations). Finally, to address Kristina’s concern about potential abuse, there are ways to address this so that it is not grounds for a phishing expedition, such as: * Requiring the trademark holder to represent that they have a good faith intent to file a UDRP or other dispute resolution mechanism or cybersquatting action * Dispute resolution providers should be able to audit requests to ensure that the requester filed a UDRP/URS or legal complaint, or in good faith determined that no grounds existed. Have a great weekend everybody! Margie

7 6

FW: [Ext] RE: Notes and action items from today's EPDP Team meeting
by Marika Konings Nov. 8, 2018

Nov. 8, 2018

Forwarding as this seems to have not have made it to the list. From: "Rosette, Kristina" <rosettek(a)amazon.com> Date: Tuesday, November 6, 2018 at 11:43 PM To: Marika Konings <marika.konings(a)icann.org>, "gnso-epdp-team(a)icann.org" <gnso-epdp-team(a)icann.org> Subject: [Ext] RE: [Gnso-epdp-team] Notes and action items from today's EPDP Team meeting Greetings from Seattle! With apologies for the delay, here’s a link to the Google Doc for the proposed revised Purpose N. https://docs.google.com/document/d/1X4Xx2h_sL8BSQqtxm3ed1sRc7JTtcrDvhQ7Zw7G… [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_docume…> I shared it with Milton and Amr, but forgot to send to the list (and didn’t remember until I started listening to the Adobe connect recording of today’s call). Apologies! Please let me know if anyone has any questions or is unclear on the specific proposed changes. K From: Gnso-epdp-team [mailto:gnso-epdp-team-bounces@icann.org] On Behalf Of Marika Konings Sent: Tuesday, November 06, 2018 8:46 AM To: gnso-epdp-team(a)icann.org Subject: [Gnso-epdp-team] Notes and action items from today's EPDP Team meeting Dear All, Please find below the notes and action items from today’s EPDP Team meeting. Best regards, Caitlin, Berry and Marika EPDP Team Meeting #23 Tuesday, 6 November 2018 Notes and Action Items High-level Notes/Actions: Action item #1: EPDP Team to save the date for the next F2F meeting on January 16-18 2019 (Wednesday-Friday). Support team to send out save the date calendar invite for the F2F meeting Action item #2: EPDP Team to review proposed language in relation to natural vs. legal person for inclusion in the Initial Report and come prepared to discuss this on Thursday's meeting. Action item #3: Support team to draft proposed language for inclusion in the Initial Report reflecting today's discussion regarding provision for Technical contact. Action item #4: Support team to mark language in relation to data retention as agreed in the Initial Report and harmonize data retention periods across data elements workbooks. Action item #5: Thomas to translate slides into policy recommendations and edits to the tables for proposed inclusion in the Initial Report for EPDP Team consideration prior to Thursday’s meeting. Questions for ICANN Org from the EPDP Team: Is indemnification provided by ICANN through a joint controller agreement an option? If EPDP agrees on policy that requires ICANN to indemnify, would the ICANN legal team and Board oppose it? 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/2IpHBQ. 1. Roll Call & SOI Updates (5 minutes) * Attendance will be taken from Adobe Connect * Please 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. Proposed approach for reviewing and finalizing the Initial Report * See https://community.icann.org/x/5QDVBQ * Important that people provide input as soon as possible - the timeline is determined by the end goal of having new policy recommendations in place by 25 May 2019. Any additional time needed will affect the time available for other phases of the work. b. Update on F2F planning Action item #1: EPDP Team to save the date for the next F2F meeting on January 16-18 2019 (Wednesday-Friday). Support team to send out save the date calendar invite for the F2F meeting c. Proposed next steps in relation to small team #1 and #2 language for inclusion in the Initial Report See email sent by Kurt which was followed by proposed language for inclusion in the Initial Report. Action item #2: EPDP Team to review proposed language in relation to natural vs. legal person for inclusion in the Initial Report and come prepared to discuss this on Thursday's meeting. d. Review of outstanding action items * See https://community.icann.org/x/NwSNBQ e. Other updates, if applicable * Responsible parties for processing - need further info on what should be updated / discussed. To be added to agenda for Thursday's meeting. See also new agenda item 5. 3. Review of outstanding items for Initial Report and proposed approach Objective of discussion: 1. Confirm list of outstanding items to be considered in relation to Initial Report and approach for addressing these a. Review outstanding issues punch list (to be circulated) b. Confirm approach for addressing these c. Confirm next steps, if any * See email sent by Caitlin re. outstanding issues. * Idea is to introduce certain topics via email followed by EPDP Team call, certain topics can hopefully be addressed via email, some items where volunteers are needed. * Objective of the document and table is to track items that have been flagged as requiring further discussion and proposed approach. 4. Commence addressing outstanding items a. Technical contact redaction – any concerns in relation to proposed language for inclusion in the Initial Report? * Possible language to address this issue: In accordance with the EDPB’s guidance that GDPR does not apply to legal persons and personal data identifying individual employees (or third parties) acting on behalf of the registrant should not be made publicly available by default in the context of WHOIS: If the Registered Name Holder elects to provide contact information for a technical contact that differs from the Registered Name Holder, the Registrar is required to obtain consent from the technical contact prior to publication. One suggested method of obtaining this consent is to include this consent in the WHOIS Accuracy Program Specification Section 1.f.i. verification email. * Concerns expressed about relying on consent, especially if it is not provided by the data subject directly. If a RNH provides Tech contact data without consent, isn't the RNH responsible, not the registrar? * Adding on to an existing system could be problematic - something that needs further consideration, but not within the context of the current deliberations. * Previous agreement reached to continue to collect limited set of data elements (optional for RNH to provide) for technical contact, namely name, email and telephone. Concept of optional captured in data elements workbook C based on previous preliminary agreement: Optional data elements for the Registered Name Holder (RNH) to provide, but required for the registrar to offer as data elements the RNH may provide. * How do contracted parties currently handle tech contact info collection? Some registrars have stopped collecting that data - see also EPAG court case. Some are still collecting but have noted this is a potential vulnerability. * Should it also be optional for registrars to provide noting some of the issues? In that case a registrant can choose a registrar that provides this option if this is important for the registrant to provide. * Consent is used by others such as .CAT and ccTLDs so it is not necessarily a path that cannot be pursued. * Note that EDPB advice states: "registrants should be provided with the option of providing contact details for persons other than themselves if they wish to delegate these functions and facilitate direct communication with the persons concerned". In this context it is also noted that "it should be ensured that the individual concerned is informed". Consider asking a clarifying question to the EDPB concerning how this information process should take place and what, if any, additional obligations are there for the registrar, or whether this is purely a registrant responsibility. * The registrant is responsible for breaching the other individual's privacy, if such is the case. However, the registrar is responsible for ensuring that consent was obtained. * Individual registrars may voluntarily take on this risk and offer this option, if this is no longer a requirement. * EDPB advice should alleviate some of the legal concerns - may require further clarification from EDPB. * Document in the Initial Report the possible technical and legal challenges involved and outline the two different positions in relation to whether this should be required or optional for registrars to provide. Indicate that clarifying questions will be asked from the EDPB to further help inform deliberations in relation to this topic. Note that registrars may have legal liability for a RNH providing data about a third party, which is why they want the option. Action item #3: Support team to draft proposed language for inclusion in the Initial Report reflecting today's discussion. b. Data retention – any concerns in relation to proposed language for inclusion in the Initial Report? * Good reasoning to set out data retention period based on all the work that went into the data elements workbooks to discuss retention. * No opposition to include this in the Initial Report. * Consider harmonizing the data retention period across all the data elements workbooks. Action item #4: Support team to mark language in relation to data retention as agreed in the Initial Report and harmonize data retention periods across data elements workbooks. c. Confirm next steps, if any 5. Responsibilities - data processing See slides presented by Thomas Rickert Starting point: * We wanted to make a distinction between ICANN Purposes and other purposes * Reason was to identify which the areas that ICANN should govern and enforce are * We kept the language and called everything „ICANN purposes“ – that causes confusion * We have removed the things that ICANN should not govern – good. * We should make adjustments, though Status Quo / legal background: * Controller, Joint Controller and Processors are mentioned * Let‘s look at the Art. 29 (WP 169) distinctions * Let‘s discuss the micro vs the macro level * Liability issues – two layers * Data subjects claims – joint and several responsibility (indemnifications to balance) * Authorities‘ sanctions (Authorities will go after the wrongdoer) * Let‘s not be afraid of a joint controller scenario Way forward * Let‘s make everything part of a joint controller agreement * Let‘s specify the roles and responsibilities in there * Let‘s make indemnifications match the roles * We can still have parties outsourcing work (EBERO and Escrow e.g.) * Suggestion to change the language referring to "ICANN purposes" but describe that these are purposes that are governed by ICANN through consensus policies. * Determine for whole document that parties are joint-controllers, and document in joint controller agreement for which areas which party is responsible (for example, for Ebero and escrow only one party would be responsible). * Need to clarify the role of the different parties - important aspect of the Initial Report. Need a fair reflection of who asks for what and who does what. Those parties should take responsibility. * Indemnification by ICANN - would ICANN be willing to do this? Would change risk Question for ICANN Org: Is indemnification provided by ICANN through a joint controller agreement an option? (proposed rewording: if EPDP agrees on policy that requires ICANN to indemnify, would the ICANN legal team and Board oppose it?) Action item #5: Thomas to translate slides into language for proposed inclusion in the Initial Report for EPDP Team consideration prior to Thursday’s meeting. 5. Wrap and confirm next meeting to be scheduled for Thursday 8 November at 14.00 UTC. a) Confirm action items b) Confirm questions for ICANN Org, if an 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

Updated language for inclusion in the Initial Report re. Technical Contact
by Marika Konings Nov. 7, 2018

Nov. 7, 2018

Dear All, In relation to Action item #3: Support team to draft proposed language for inclusion in the Initial Report reflecting EPDP Team’s discussion regarding provision for Technical contact, please find attached the proposed update to the relevant section in the Initial Report. We hope this accurately reflects the discussion and the different positions expressed for inclusion in the Initial Report. 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

Input on responsibilities
by Thomas Rickert Nov. 7, 2018

Nov. 7, 2018

All, Please find attached language - that will surely require further tweaking - describing the points I outlined in our call on Tuesday. Please note that I used text we wrote for the eco GDPR Domain Industry Playbook as a basis to save me some drafting work. I am not trying to sell the playbook, though, so we can completely rewrite things. I know that Diane, Dan, Trang and others have offered to work on this, but due to other commitments, I have not been able to consult with them because staff asked me to share something on the list today in preparation of tomorrow’ call. I am sorry for this as I would have preferred to work with a small team on this before bothering the entire group with the input. All the best, Thomas Changes to be made to the initial report as of line 900 EPDP Team Preliminary Recommendation #17 The EPDP Team recommends that ICANN enters into a Joint Controller Agreement (JCA) with the contracted parties. In addition to the legally required components of such agreement, the JCA shall specify the responsibilities of the respective parties for the processing activities as described below. Indemnification clauses shall ensure that the risk for certain data processing is borne by either one or multiple parties that have the primary interest in the processing Rationale and background: The text in the attached document should follow. When the table starting line 988 comes: Instead of ICANN purposes, the following language should be used: Purposes for processing personal data that should be governed by ICANN Org via a Consensus Policy. Note there are additional purposes for processing personal data, which the contracted parties might pursue, such as billing customers, but these are outside of what ICANN and its community should develop policy on or contractually enforce. Then, as a starting point, in the „responsible party“ column, we should just mention the party or parties tagged as controllers or joint controllers, but delete the words joint controller, processors or controllers, so that we only have the responsible parties listed. This, we will need to review as a team.

1 0

NCSG reactions to (part of) the interim report
by Mueller, Milton L Nov. 7, 2018

Nov. 7, 2018

Marika NCSG cannot accept big portions of the proposed text regarding the legal/natural persons distinction. We note that the text disregards statements from the contracted parties and NCSG. We would respectfully ask you to revise the text in a way that respects and reflects clearly stated and strongly held positions of at least three stakeholder groups. To be specific, the CPH has stated, in regard to the legal/natural persons and geographic distinctions: “Contracted Parties oppose/reject any recommendations for new contractual requirements in the ePDP Draft Initial Report, and will remain opposed to these recommendations as we move towards final recommendations.” NCSG shares this opposition to requiring distinctions between legal and natural persons and geographic distinctions. In our comment on small team 1 we stated: “The main risk is that the difficulty of distinguishing between the two at the point of registration could lead to the unintended publication of the private data of many natural persons.” This assessment of risk is not reflected in the report. We also proposed deleting the entire paragraph on research because researching how various entities make this distinction basically assumes that making this distinction is a live option for the ePDP. In terms of consensus requirements, all indications are that it is not a real option. It is abundantly clear that no requirement for a distinction between legal and natural persons will survive a consensus recommendation process. At least three stakeholder groups – ¾ of the GNSO and roughly half of the ePDP – are rejecting it as an option. We think the report should move the process forward by explicitly recognizing this fact. Instead, we have Kurt stating on list that there was “an agreement” to do research on the feasibility of differentiating between natural and legal persons. This statement can only come from completely disregarding the interventions NCSG members made in Barcelona, on the latest call, and in an email sent Tuesday to the list by Amr elSadr. To quote from Amr’s email regarding Kurt’s statement regarding research: “I don’t believe that [research on legal/natural] was, in any way, reflective of a consensus to proceed with this recommendation among the Small Team members. To me, it was only an acknowledgement that this view was expressed, discussed, and subsequently required consideration by the whole team.” Kurt has not responded to this email. We will raise these concerns on the call tomorrow. In general, I think the team is in danger of losing sight of its primary mission, which is to quickly bring Whois into compliance with GDPR and to turn the temp spec into a legitimate policy. It seems that some people are seizing on the debate over the temp spec to impose new requirements on contracted parties. I understand that the chair and staff are trying their best to move things along, but we are disturbed by an apparent tendency to ignore or disregard clear position statements from SGs. One of the most important jobs of the ePDP chair is to recognize where consensus exists and where it does not. Some proposals are just not real options: they will never survive a council vote or a consensus call in the ePDP. It is unthinkable that the chair or staff would substitute their own preferences for the rough consensus of the working group. Let’s recognize the parameters of what people can live with and move forward from there. Eliminating options is progress, too. Milton Mueller, on behalf of NCSG From: Gnso-epdp-team [mailto:gnso-epdp-team-bounces@icann.org] On Behalf Of Marika Konings Sent: Monday, November 5, 2018 11:49 PM To: Kurt Pritz <kurt(a)kjpritz.com>; gnso-epdp-team(a)icann.org Subject: Re: [Gnso-epdp-team] Contracted Parties and Small Teams #1 and #2 Following on from Kurt’s message, please find hereby the proposed language for inclusion in the Initial Report. Attached is the document that would be linked so that those interested would be able to review the different perspectives and proposals put forward. h3) Should Contracted Parties be allowed or required to treat legal and natural persons differently, and what mechanism is needed to ensure reliable determination of status? h4) Is there a legal basis for Contracted Parties to treat legal and natural persons differently? h5) What are the risks associated with differentiation of registrant status as legal or natural persons across multiple jurisdictions? (See EDPB letter of 5 July 2018). The EPDP Team discussed these questions extensively (see [include link to attached document which includes the different proposals]) and although the EPDP Team agrees that Contracted Parties should be allowed to treat legal and natural persons differently, the EPDP Team did not agree on whether this should be required and/or what further steps could or should be undertaken to determine what mechanism is needed to ensure reliable determination of status. The EPDP Team further agrees under GDPR there is a legal basis to treat legal and natural persons differently, but does not agree on whether that means Contracted Parties should be required to do so, or whether the challenges and legal risks involved in doing so result in leaving this optional. Similarly, the EPDP Team discussed the implication of other data protection regimes which could have different requirements that impact both natural and/or legal persons that would need to be factored in. The EPDP Team identified a number of risks, including: * While legal persons don’t have the same protections under GDPR, natural persons employed by a legal person (and who may be designated as the registrant, admin or technical contact) are still natural persons enjoying rights and protections under GDPR. Some noted that this risk may be minimized through clear explanatory language beneath each field when filling in data fields within domain name registrations. * There may be situations in which it can be difficult to separate the data of natural persons from that of legal persons. This can be the case, for example, if the legal person is a sole proprietorship, if the name of a person appears in the company’s name, if the business address is a natural person’s residence, or if an email address is assigned to a single individual (“john.doe(a)company.example.com<mailto:john.doe@company.example.com>” as opposed to “info(a)company.example.com. The EPDP has discussed whether this risk may be somewhat mitigated through educational resources. Some in the EPDP Team expressed caution, as a stated necessity to rely on educational resources may not be considered to be compatible with the concepts of privacy by default or privacy by design i.e. where additional ‘educational resources’ are deemed necessary, the process itself is likely not established or presented in a sufficiently clear manner. To help further inform the EPDP Team’s deliberations on this topic as the team works towards a Final Report, the EPDP Team would like to request that GDD staff, who will design the implementation of these policy recommendations, commences research by investigating how ccTLDs and contracted parties currently distinguish between natural and legal persons to inform the EPDP Team. In addition, the EPDP Team would like to request input on the following questions in relation to this topic: · Are there examples from other industries or areas, e.g. ccTLDs, where a mechanism has been successfully developed and implemented to distinguish between natural and legal person, factoring in some of the challenges identified above? · Should the EPDP Team decide to recommend requiring distinguishing between natural and legal persons, how should implementation be carried out, especially considering legacy registrations? · Should the EPDP Team decide to recommend that further research is undertaken, beyond the information that GDD staff may encounter, what and how should this research be carried out? · (For the EDPB) If registrars allow registrants to self-identify at the time as a natural or legal person, who will be held liable if the registrant incorrectly self-identifies and personal information is publicly displayed? Apart from self-identification, are there any other ways in which risk of liability could be mitigated by registrars? The research requested and input on these charter questions will help the EPDP Team further analyze if it is possible and desirable to make this distinction in the context of domain name registrations, in a manner that is commercially reasonable, implementable and does not result in unreasonable liability for contracted parties. Best regards, Caitlin, Berry and Marika From: Gnso-epdp-team <gnso-epdp-team-bounces(a)icann.org<mailto:gnso-epdp-team-bounces@icann.org>> on behalf of Kurt Pritz <kurt(a)kjpritz.com<mailto:kurt@kjpritz.com>> Date: Monday, November 5, 2018 at 7:45 PM To: "gnso-epdp-team(a)icann.org<mailto:gnso-epdp-team@icann.org>" <gnso-epdp-team(a)icann.org<mailto:gnso-epdp-team@icann.org>> Subject: Re: [Gnso-epdp-team] Contracted Parties and Small Teams #1 and #2 Hi Everyone: After all of this thought and writing, I think we have two paths forward that are relatively straightforward to describe. Rather than recap the arguments made here, I will just go right into my recommendations for next step and why. The Support Team will follow this with a better summation of what has transpired and how that leads to the recommendations below. It is clear that camps within our the team are at loggerheads with regard to how geographic basis and natural v legal persons should be handled within the proposed policy recommendations. Current situation and recent developments: Coming out of the small group meeting #1 during a teleconference, there was an agreement in principle that it was necessary to perform research in order to inform the policy discussion regarding the feasibility of differentiating between legal and natural persons. That agreement survived its initial introduction into the whole team where the comments centered around: (1) the adjectives used to describe the sense of urgency concerning the work, and (2) sharpening the detail regarding steps to be taken after the research. (There was never an agreement about how to proceed regarding differentiation of data subjects based on geographical considerations.) Starting Friday, substantial markups to the legal v natural agreement on doing research initiated this current three-day email chain. Preferred Recommendation (there are two): Go back to the agreement in principle that was reached in the small team with representatives from all groups to undertake research to determine if, how and to what extent we can distinguish between legal and natural persons. Then extend that research on to the geographic basis issue. A small group of us can contribute to the terms of reference for this research after the initial report is issued. Here is my rationale for this recommendation: 1) The various arguments laid out in all these emails on this list make the case themselves for the need to do research. For example, if the ICO says that processors can rely on data subject-provided information, does that mean that personal information mistakenly disclosed can be published without liability? We don’t know. We are setting up this and other questions for DPAs. Isn’t that … research? There are other scenarios in the emails that will take research to sort through: whether ccTLD experiences are relevant, or whether a registrant boarding a train and leaving the EU for China while another registrant boarding a ferry for Marseilles will both be protected by GDPR. All this takes research to sort out. Nearly all of the emails on this list have to do with scenarios in support of one position or another - but all need to be studied in order for us to determine if and how distinctions can be made. 2) Many of the arguments laid out are conclusory or without authority. I don’t think the research can have a preordained outcome. To make one point for each line of thinking: a) In the case of natural vs legal data subjects, some seek to build in in an implementation plan without knowing if or to what degree a solution is implementable b) In the case of Geographical distinctions between registrants, some are stating that such a distinction is categorically unimplementable without authority or evidence provided. I think the “truth will out” on these questions and we should not try to push research or our arguments to a pre-ordained outcome. 3) This will provide time to take the effects of existing laws in other jurisdictions into account - if that is deemed desirable. 4) This will take this discussion out of the critical path of finishing our reports, without leaving a blank. 5) The results of the research still must be considered by this team (or its successor) and a consensus derived. Research informs policy; it does not create policy. 6) If we agree to this approach, we can start the research now. If we temporize, there will be little done that will resolve this issue set over the next few months. Taking action in an attempt to understand all the complexity is the responsible thing to do. 7) These are complicated questions and research-based policy-making is required to answer them. How do we meet the timeline and still act in a thorough, detailed manner? By launching research and, in the meantime, going back to the rest of our questions. Whatever our policy conclusions are, even if we are deadlocked in several months time, we should be informed by information garnered from DPAs and other sources. The only other recommendation: MemorialIze the differences between the two sides on each of the two issues, explaining the arguments for each and asking for public comment on these issues. Here is my rationale for and against this recommendation: 1) It will allow us to publish the initial report and, properly framed, can garner specific public comment. However, other factors really argue against maintaining the current status and not taking some action: 2) In the time allotted for public comment, no commenter will be able to perform any meaningful research either. There might be reference to a study that partially informs our work, but not a dispositive study. At the end of the comment period, we are likely to be in the same place. 3) It is hard to see how the public comment will differ from our discussion, in this list, to date. 4) Even if we take the preferred research path above, we can still conduct the comment period on the current position of the parties. 5) If we have no outcome on this issue, the result, to me, is unknown and represent a risk to all parties at the table. Conclusion I thought is was remarkable that we came together and agreed to undertake this research on this difficult topic. It was a significant, meaningful compromise that embodied our reason for being here. I don’t see anything in all the emails that indicate another compromise is possible unless that discussion is informed with significant, new information. I believe the appropriate path for this group is to recognize the differences cannot be resolved without something new and to take this path. Talk to you soon and best regards, Kurt On Nov 5, 2018, at 4:38 PM, Mark Svancarek (CELA) via Gnso-epdp-team <gnso-epdp-team(a)icann.org<mailto:gnso-epdp-team@icann.org>> wrote: Sorry for being dense, I still have questions. 1. It is not surprising that the addition of a new process step would generate short term inefficiencies. It’s 5 years later – are the verification rates improved from 2014? 2. How would an optional “let me self-identify as a corporation” capability be likely to cause verification disruptions? /marksv From: James M. Bladel <jbladel(a)godaddy.com<mailto:jbladel@godaddy.com>> Sent: Monday, November 5, 2018 13:28 To: Mark Svancarek (CELA) <marksv(a)microsoft.com<mailto:marksv@microsoft.com>>; gnso-epdp-team(a)icann.org<mailto:gnso-epdp-team@icann.org> Subject: Re: Contracted Parties and Small Teams #1 and #2 Mark – Shortly following the launch of the 2013 RAA’s requirements for WHOIS Verification, registrars noted that approx. 800,000 domains had been suspended in the first few months. The number continued to climb for a few years, and most were categorized as “false positives” Here’s some coverage of that data at the time. https://domainnamewire.com/2014/06/24/over-800000-domain-names-suspended-du…<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdomainname…> Any program that depends on Registrant self-categorization, self-declaration, or receipt & acting upon a notice has a huge error factor. For GoDaddy in 2014, the RAA verification rate was in the high 70% or low 80%, meaning that service to tens of thousands of customers was delayed or disrupted. It’s this experience that causes Contracted Parties (but particularly Registrars) to be skeptical of any requirement to just “send an email” or “have the Registrant check a box.” It doesn’t scale. J. ------------- James Bladel GoDaddy From: "Mark Svancarek (CELA)" <marksv(a)microsoft.com<mailto:marksv@microsoft.com>> Date: Monday, November 5, 2018 at 15:14 To: "James M. Bladel" <jbladel(a)godaddy.com<mailto:jbladel@godaddy.com>>, "gnso-epdp-team(a)icann.org<mailto:gnso-epdp-team@icann.org>" <gnso-epdp-team(a)icann.org<mailto:gnso-epdp-team@icann.org>> Subject: RE: Contracted Parties and Small Teams #1 and #2 James, can you clarify this: “many of whom could lose access to their registrations.” From: Gnso-epdp-team <gnso-epdp-team-bounces(a)icann.org<mailto:gnso-epdp-team-bounces@icann.org>> On Behalf Of James M. Bladel Sent: Monday, November 5, 2018 10:57 To: gnso-epdp-team(a)icann.org<mailto:gnso-epdp-team@icann.org> Subject: [Gnso-epdp-team] Contracted Parties and Small Teams #1 and #2 ePDP Colleagues and WG Leadership - This morning, Registry and Registrar representatives met to discuss the status of potential recommendations from Small Group #1 (Legal vs. Natural) and Small Group #2 (Geographic Regions) in our Draft Initial Report. We concluded that there are some legal bases supporting these distinctions under GDPR and other data protection laws, and note that our Initial Report supports this. However, we reiterate our numerous high-level concerns against making any Consensus Policy recommendations for contractual requirements in these areas. Our concerns involve: * Legal - Aside from GDPR, other data protection laws are less clear on the distinction between legal and natural persons. Future regulations may contain contrary requirements. Furthermore, data of legal entities may contain or consist of personal information of natural persons, which would be entitled to protection under the GDPR and similar data protection regimes. Likewise, the geographic distinctions also create uncertainties. * Technical - Contracted Parties are uniquely situated to assess the current level of the technological means available to us, and it is our stated position that a technical basis to reliably and confidently make such a distinction does not exist. Especially because any distinction schema would be dependent upon Registrant Self-Identification, which is fraught with error. * Commercial - Developing and deploying this technology will involve significant costs, which may be prohibitive for smaller organizations and a barrier to market entry. Regardless of whether the distinction(s) are applied to new registrations or legacy domain names, it would be a logistical nightmare for Contracted Parties, and a source of confusion for Registrants, many of whom could lose access to their registrations. * Asymmetrical Risks vs. Benefits - Contracted Parties would assume all regulatory risks of such an obligations, exclusively for the benefit of unburdened third parties. * Scope - The distinction between Legal and Natural persons, or geographic regions, does not currently exist in the Domain Name System. Therefore, any recommendation mandating this change is outside the scope of the ePDP, and possibly the “picket fence” of Registrar and Registry contracts. As a result, and for the avoidance of doubt, Contracted Parties oppose/reject any recommendations for new contractual requirements in the ePDP Draft Initial Report, and will remain opposed to these recommendations as we move towards final recommendations. Thank you, J. ------------- James Bladel GoDaddy _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team(a)icann.org<mailto:Gnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team

2 1

RESENDING FOR EMAIL ARCHIVE URL LINK PURPOSE / Recording, Attendance & AC chat from the call to discuss Independent legal counsel to assist the EPDP held on Wednesday, 10 October 2018 at 22:00 UTC.
by Terri Agnew Nov. 7, 2018

Nov. 7, 2018

Please note: RESENDING FOR EMAIL ARCHIVE URL LINK PURPOSE ONLY (as the original URL link in email archives does not format properly) Dear all, Please find the attendance and AC chat attached to this email. The AC recording below from the call to discuss Independent legal counsel to assist the EPDP held on Wednesday, 10 October 2018 at 22:00 UTC. AC Recording: https://participate.icann.org/p5oj3aetof9/ ** 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, Terri Agnew

1 0

***REMINDER*** Meeting Invitation: Alternates & Observers / GNSO Temp Spec gTLD RD EPDP call / Thursday, 08 November 2018 at 14:00 UTC
by Julie Bisland Nov. 7, 2018

Nov. 7, 2018

Dear all, Non-members can follow the EPDP call taking place on Tuesdays and Thursdays at 14:00 UTC 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/qg68BQ Thank you. Kind Regards, Andrea

1 0