August 2018 - Gnso-epdp-team

**Added view only Adobe Connect room option/ Audio cast information for alternates and observers / 16 August 2018, 13:00 UTC
by Terri Agnew Aug. 15, 2018

Aug. 15, 2018

Dear all, Non-members can follow the EPDP call taking place on Tuesday’s and Thursday’s at 13: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 Listen in application such as iTunes: http://stream.icann.org:8000/stream01.m3u Agenda wiki page: https://community.icann.org/x/owtpBQ Kind regards, Terri

1 0

Re: [Gnso-epdp-team] [Ext] Re: For your review - EPDP Team Communications Plan
by Marika Konings Aug. 15, 2018

Aug. 15, 2018

Hah, someone just had the same problem with Becky’s presentation so I too quickly assumed it was that document you were referring to. Here is the communications plan – hopefully now everyone has what they need and is able to open it! Best regards, Marika From: Chris Disspain <chris(a)disspain.uk> Date: Wednesday, August 15, 2018 at 19:50 To: Marika Konings <marika.konings(a)icann.org> Cc: "gnso-epdp-team(a)icann.org" <gnso-epdp-team(a)icann.org> Subject: Re: [Ext] Re: [Gnso-epdp-team] For your review - EPDP Team Communications Plan It opens fine but is the wrong document…. :-) Cheers, Chris On 15 Aug 2018, at 18:48, Marika Konings <marika.konings(a)icann.org<mailto:marika.konings@icann.org>> wrote: Apologies, I have been having some issues with my attachments lately. Hopefully the attached version does not have the same issues. If it does, the slides can also be downloaded from here: https://gnso.icann.org/sites/default/files/file/field-file-attach/picket-fe… [gnso.icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_sites_d…>. Best regards, Marika From: Chris Disspain <chris(a)disspain.uk<mailto:chris@disspain.uk>> Date: Wednesday, August 15, 2018 at 19:31 To: Marika Konings <marika.konings(a)icann.org<mailto:marika.konings@icann.org>> Cc: "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: [Ext] Re: [Gnso-epdp-team] For your review - EPDP Team Communications Plan Marika, The attachment won't open so may be corrupt. It’s labelled as a ‘mail attachment' which doesn't look right. Cheers, Chris On 15 Aug 2018, at 17:09, Marika Konings <marika.konings(a)icann.org<mailto:marika.konings@icann.org>> wrote: Dear All, Following yesterday’s meeting, please find attached for your review the proposed EPDP Team Communications Plan that has been developed with the support of our colleague Arial Liang. You are encouraged to provide any suggestions, comments and/or input you may have. Thanks, 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 [learn.icann.org]<https://urldefense.proofpoint.com/v2/url?u=http-3A__learn.icann.org_courses…> and visiting the GNSO Newcomer pages[gnso.icann.org]<https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_sites_gn…>. <Mail Attachment>_______________________________________________ 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 <Picket Fence Presentatino - Becky Burr.pdf>

1 0

Re: [Gnso-epdp-team] [Ext] Re: For your review - EPDP Team Communications Plan
by Marika Konings Aug. 15, 2018

Aug. 15, 2018

Apologies, I have been having some issues with my attachments lately. Hopefully the attached version does not have the same issues. If it does, the slides can also be downloaded from here: https://gnso.icann.org/sites/default/files/file/field-file-attach/picket-fe…. Best regards, Marika From: Chris Disspain <chris(a)disspain.uk> Date: Wednesday, August 15, 2018 at 19:31 To: Marika Konings <marika.konings(a)icann.org> Cc: "gnso-epdp-team(a)icann.org" <gnso-epdp-team(a)icann.org> Subject: [Ext] Re: [Gnso-epdp-team] For your review - EPDP Team Communications Plan Marika, The attachment won't open so may be corrupt. It’s labelled as a ‘mail attachment' which doesn't look right. Cheers, Chris On 15 Aug 2018, at 17:09, Marika Konings <marika.konings(a)icann.org<mailto:marika.konings@icann.org>> wrote: Dear All, Following yesterday’s meeting, please find attached for your review the proposed EPDP Team Communications Plan that has been developed with the support of our colleague Arial Liang. You are encouraged to provide any suggestions, comments and/or input you may have. Thanks, 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 [learn.icann.org]<https://urldefense.proofpoint.com/v2/url?u=http-3A__learn.icann.org_courses…> and visiting the GNSO Newcomer pages [gnso.icann.org]<https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_sites_gn…>. <Mail Attachment>_______________________________________________ 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

1 0

Proposed Agenda - EPDP Team Meeting #5 - 16 August at 13.00 UTC
by Marika Konings Aug. 15, 2018

Aug. 15, 2018

Dear All, Please find below the proposed agenda for the next EPDP Team meeting which is scheduled for Thursday 16 August at 13.00 UTC. Note that the slides and other documents will follow later as survey responses have not all been received yet. Best regards, Caitlin, Berry and Marika EPDP Meeting #5 Agenda Thursday, 16 August 2018 1. Roll Call & SOI Updates 1. Welcome and Updates from EPDP Team Chair 1. Summary of responses to EPDP Input Survey Part 3 - Results for Appendix D: Uniform Rapid Suspension, Appendix E: Uniform Domain Name Dispute Resolution Policy, Appendix G: Supplemental Procedures to the Transfer Policy 1. Substantive Discussion of Temporary Specification: * Part 3 of the Survey can be found at https://www.surveymonkey.com/r/7PWQPP7 * Appendix D: Uniform Rapid Suspension * Appendix E: Uniform Domain Name Dispute Resolution Policy * Appendix G: Supplemental Procedures to the Transfer Policy 1. Confirmation of action items and questions for ICANN Org, if any 1. Wrap and confirm next meeting to be scheduled for Tuesday 21 August at 13.00 UTC. (Part 4 Survey results due Sunday, 19 August by 19.00 UTC) 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<http://learn.icann.org/courses/gnso> and visiting the GNSO Newcomer pages<http://gnso.icann.org/sites/gnso.icann.org/files/gnso/presentations/policy-…>.

1 0

Picket fence presentation
by Marika Konings Aug. 15, 2018

Aug. 15, 2018

Dear All, As per the action item of yesterday’s meeting, please find attached the presentation that was provided by Becky Burr to the GNSO Council during its Strategic Planning Session that took place in January of this year. Below you will also find the notes from this session that have been excerpted from GNSO Council Strategic Planning Meeting Report. Best regards, Caitlin, Berry and Marika =================== From the GNSO Council Strategic Planning Meeting Report (see http://mm.icann.org/pipermail/council/attachments/20180307/1b480812/GNSOCou…) Objective: Explain the “picket fence” and ICANN SO/AC structure in the context of history of the organization and how this impacts on the GNSO’s role and function within ICANN High level notes: See presentation provided by Becky Burr (https://gnso.icann.org/en/picket-fence-concept-overview-29jan18-en.pdf) * ICANN’s picket fence – what is it and where did it come from? * In October 1998 agreement to transition from Verisign as sole registry and registrar for .com, .net and .org, followed by naming of competing registrars in April 1999. * First registry agreement and registrar accreditation agreement signed on 10 November 1999. * ICANN needed the ability to uniformly enforce obligations, including the ability to add additional obligations without contractual negotiations. As part of that discussion, there was a need to identify the areas in which such additional contractual obligations could be added, tied to ICANN’s mission as well as a process by which such additional contractual obligations could be developed. * The “picket fence” characterized this area that would delineate the topics for which ICANN could enforce additional contractual obligations that would have gone through an agreed upon process; anything outside of that area would need to be the subject of contract negotiations. * Registry and registrar agreements cover the picket fence in slightly divergent ways. A number of examples were included in the agreements to provide an illustration of what topics would be considered within the picket fence. * Picket fence incorporated into the post-transition Bylaws: * The mission of the Internet Corporation for Assigned Names and Numbers (“ICANN”) is to ensure the stable and secure operation of the Internet’s unique identifier systems … (the “Mission”). Specifically, ICANN: * Coordinates the allocation and assignment of names in the root zone of the Domain Name System (“DNS”) and coordinates the development and implementation of policies concerning the registration of second-level domain names in generic top-level domains (“gTLDs”). In this role, ICANN’s scope is to coordinate the development and implementation of policies: * For which uniform or coordinated resolution is reasonably necessary to facilitate the openness, interoperability, resilience, security and/or stability of the DNS including, with respect to gTLD registrars and registries, policies in the areas described in Annex G-1 and Annex G-2; and * That are developed through a bottom-up consensus-based multistakeholder process and designed to ensure the stable and secure operation of the Internet’s unique names systems. * Annex G-2 (Registry specification): * The topics, issues, policies, procedures and principles referenced in Section 1.1(a)(i) with respect to gTLD registries are: * Issues for which uniform or coordinated resolution is reasonably necessary to facilitate interoperability, security and/or stability of the Internet or DNS; * functional and performance specifications for the provision of registry services; * security and stability of the registry database for a TLD; * registry policies reasonably necessary to implement Consensus Policies relating to registry operations or registrars; * resolution of disputes regarding the registration of domain names (as opposed to the use of such domain names); or * restrictions on cross-ownership of registry operators and registrars or registrar resellers and regulations and restrictions with respect to registry operations and the use of registry and registrar data in the event that a registry operator and a registrar or registrar reseller are affiliated. * Registrar specification (G-1) only differs with regards to domain name use. * As a result of the transition-related work, namely the CCWG-Accountability recommendations, the picket fence was incorporated into the Bylaws as part of ICANN’s mission. The mission is now clarified to include the constraints that are in place with regards to ICANN’s authority and ability to enforce contractual obligations on the topics as outlined in the Bylaws. * It was necessary from a contracted parties’ perspective to balance out ICANN’s need to develop policies and impose them on contracted parties, where those policies are necessary for security and stability reasons. Incorporating the picket fence into ICANN’s mission provides some measure of predictability and stability that businesses like contracted parties need. This sets up a unique situation whereby a contracting party is legally bound to terms which may not be consented to. * Picket fence circumscribes ICANN’s authority with regards to names. * Effective policy-making requires that affected stakeholders be able to participate, hence the structure of the GNSO Council. * In addition to examples of what is within the picket fence, the base registry and registrar agreements also contain certain examples of matters outside of the picket fence, such as pricing, fees paid to ICANN, etc. * Picket fence concept is inherently based on consensus-driven process. There is more predictability in the sense that there is more discussion and understanding of the different positions, that you may not get in a voting model. Consensus provides balance against capture. It is also the tradition by which decisions are made in the technical community. * ICANN Board has committed to tying decisions and actions explicitly to relevant Bylaws provisions that empower the Board to act or not act for any decisions going forward. SO/ACs will be encouraged to adopt this approach going forward. 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<http://learn.icann.org/courses/gnso> and visiting the GNSO Newcomer pages<http://gnso.icann.org/sites/gnso.icann.org/files/gnso/presentations/policy-…>.

1 0

Notes and action items from today's EPDP Team Meeting - 14 August 2018
by Marika Konings Aug. 14, 2018

Aug. 14, 2018

Dear All, Below, please find notes and action items from today’s EPDP Team Call. As a reminder, our next meeting will be Thursday, 16 August, 13:00 UTC. Best regards, Caitlin, Berry, and Marika =============== EPDP Team Meeting - 14 August 2018 Tuesday, August 14, 2018 High-level Notes/Actions: 1. The next meeting is Tuesday 16 August at 13.00 UTC. The deadline for submission of Part 3 of the survey is Wednesday, 15 August at 19:00 UTC. 2. In response to a request for better access to the meeting proceedings, ICANN will provide a “read-only” Adobe Connect room where Alternates and Observers can see the presentations and chat and listen to the audio. The room was tested in today’s meeting and should be available for the next meeting. 3. In a discussion of the role of this “Triage” portion of the work it was pointed out that: * combining sections for comment can result in a result that there is not consensus on an issue where there often is agreement on the heart of the issue * the utility of the Triage discussion was also questioned as, after some issue identification, we skip over substantive discussion * by way of suggestion, if more “wordy” comments were submitted, support / non-support and root issues will be more easily identified * the goal of the Triage is to form the required deliverable for the GNSO where the comments provide a basis for the next round of discussions 1. Additional materials requested of ICANN: * “Picket Fence” presentation from by Becky Burr * Library and summation (e.g., staff notes and annotations) of communications between ICANN and EDPB and other similarly situated entities 2. ICANN’s role as a data controller should be noted and communicated for discussion at the appropriate time to ICANN in secs. 5.1 et.sec., particularly Data Escrow Questions for ICANN Org from the EPDP team: 1. Can ICANN summarize in some searchable form the contacts and engagements with the EDPB and/or other DPAs in relation to the Temporary Specification for gTLD Registration Data? 2. In section 5.7 of the Temporary Specification (and other sections), what is the meaning of “reasonable access”? Is it access to personal data reasonably provided? Does “reasonably” relate to the effort necessary to retrieve it? Does it mean how criteria for releasing it are applied, i.e., legitimate and not overcome by the rights of others? Should it just be “access”? All Action items: · Staff to circulate proposed Communication Plan with EPDP Team for input and review · EPDP Team to review communications plan and provide feedback · Staff to share instructions for use of alternate AC room with AC streaming prior to Thursday's meeting. · Council liaison, Rafik Dammak, to provide update on participation of alternates to GNSO Council and determine whether there any concerns about the proposed approach for live streaming the AC room to facilitate read-only access to AC. · Staff to share “Picket Fence” presentation that Becky Burr provided to GNSO Council with EPDP Team. · Staff to forward message from Kavouss regarding selection of meeting venue with ICANN CEO and ICANN Board Chair (completed) and his spoken message in today’s meeting · EPDP Team members to complete survey part 3 by Wednesday, 15 August at 19:00 UTC 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 · 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 Chair · F2F meeting · Scheduled to be held in Los Angeles from Monday 24 - Wednesday 27 September 2018. Plan for full three day meetings. · Concerns expressed about visa ban that will prevent attendance of some members of certain nationalities. This has also affected attendance of members for other meetings such as ICANN60 in Puerto Rico. Request avoiding any future meetings in any country or geographic territory which impose an entry ban for certain nationals. This request has also been communicated to the ICANN CEO and Chairman of the ICANN Board. · Are alternates able to attend in person, if they would desire so? There may be space limitations that need to be factored in, but the leadership team is looking into options. Some disagree with the ability of alternates to attend - their role is to replace members in their absence not participate in addition to members. · Communications Plan · One of the requirements of the charter is to communicate on a regular basis with the GNSO Council and broader community. ICANN Staff has put together a plan & road map that outlines various ways of communicating regular updates. Action item #1: Staff to circulate proposed Communication Plan with EPDP Team for input and review Action item #2: EPDP Team to review communications plan and provide feedback · Access for Alternates · Request for read-only access to Adobe Connect room to facilitate alternates to follow deliberations. This could be done through using a shadow room. · Recommended that if there is support from GNSO SG/Cs for this request, to request Rafik as the GNSO Liaison to take this back to the GNSO Council for its consideration. · Proposed approach is to live stream the Adobe Connect room for alternates/observers to observe - this will allow for real time view of chat and slides. Testing is currently occurring with the hope that this solution can be rolled out by Thursday's meeting. Action item #3: Staff to share instructions for use of alternate AC room with AC streaming prior to Thursday's meeting. Action item #4: Council liaison, Rafik Dammak, to provide update on participation of alternates to GNSO Council and determine whether there any concerns about the proposed approach for live streaming the AC room to facilitate read-only access to AC. · Draft Triage report · Still work in progress - the hope is to share the draft triage report shortly with the EPDP Team for review. 3. Summary of responses to EPDP Input Survey Part 2 a. Results for Sections 5-7 (Requirements Applicable to Registry Operators and Registrars) b. Appendices B (Supplemental Data Escrow Requirements) & F (Bulk Registration Data Access to ICANN) See summary table of results in slide deck 4. Substantive Discussion of Temporary Specification (beginning with Sections 5, 6, 7, Appendix B, & Appendix F) a. Part 2 of the Survey can be found at https://www.surveymonkey.com/r/7BMRCNS b. Responses and issue summaries are in the Spreadsheet accompanying this agenda Section 5. Requirements Applicable to Registry Operators and Registrars 5.1. Publication of Registration Data 5.2. Registrar and Registry Operator Service Level Agreement. Issue Summary: 5.1: There are many comments but none object to the incorporation of the Appendix into the Specification via this clause. 5.2: It was noted that the required date for the closure of SLA negotiation is past and should be reset to one quarter out or dealt with in some other way. Other comments state that discussions on access should not occur until after all gating questions have been answered, and Contracted Parties are data processors only to the extent necessary to fulfill the objectives clearly articulated within ICANN's mission statement. · Most comments pointed to the appendix not the section itself. · Add to the summary for 5.1 that there is disagreement regarding the content of the Appendices. Issue Summary: 5.3-5.4: Most groups support these clauses as incorporating the Appendix into the specification. There is disagreement regarding the content of the Appendices. 5.5: Discussion required to ensure this wording adequately addresses all possible combinations of countries involved in data transfer. · ICANN is not mentioned as party here, this is problematic. Need to make relationship clear - data agreement between escrow agents and ICANN. · ALAC comment was more of a question than an objection in relation to 5.5. Wording in the section refers to adequate processes but not clear whether in all cases there are adequate processes available. Should be clarified. Issue Summary: Many support sections 5.6 - 5.7. ICANN & this team should define "reasonable access" in Section 5.7. Those not in support of 5.7 state that ICANN needs to ensure that access is narrowly tailored for this purpose. There is a question as to why ICANN needs access to registration data for compliance purposes. Another group states ICANN should have full access to registration data. · Need to define "reasonable access" as part of 5.7 · Need to be precise in what data elements ICANN needs to get access to for what type of compliance action. Section 6. Requirements Applicable to Registry Operators Only Issue Summary: Several groups support 6.1 - 6.3; one noted that (1) section 6.3.2 should be amended to reflect that approval of RRA updates is necessary and (2) the community should strive to have a single, standardized approach on GDPR provisions in general, and international transfers in particular. Other comments: (1) amend the timeline in 6.2; (2) clarify the definition of periodic access in 6.1, the reporting requirements in Section 6.2, and the language around international data processing in 6.3; (3) Test 6.1 and 6.2 against data minimization principles · RySG suggested eliminating section 6.2 and suggested clarifications to 6.3. Do model clauses even apply in all circumstances? For 6.2 date is in the past so language is not relevant as it has been superseded by what has happened in practice. 6.3 goes into the limits of the picket fence, this gets into an area that goes beyond the picket fence. Encourage everyone to review specification 1 to the new gTLD Registry Agreement which sets out the parameters of what consensus policy can cover - this seems to go beyond that? This may need further analysis as not everyone may agree that this falls outside the picket fence - let's not make assumptions. If need be, specific questions could be asked of ICANN staff? · What are additional reporting requirements? What is meant with that? Clarification needed. · In relation to section 6, consider having registrar operators contributing to this contribution as they impose requirements on a blanket basis. Up to contracted parties to pass on any obligations to parties they have contractual agreements with. May confuse things if downstream parties are included in this conversation? · Need to consider whether article 6 approach is taken which would involve joint controller agreement between ICANN and contracted parties. · ICANN's Model RRA-Data Processing Agreement refers to the concept of Shared Personal Data (which is a subset of Personal Data and not mentioned in the Temp Spec.) General comments on triage effort · Objective of this exercise was originally to try and establish where there was agreement / support for certain sections but also understand where there is disagreement and why. Summaries aim to provide succinct summary of the main comments in each section. Tool for driving the discussions in the next phase where the EPDP Team will hone in on the substance and possible path forward. Individual comments will of course also be part of that. · Grouping of certain sections may unfairly indicate support or lack thereof as sometimes issues are with a very specific part. In certain cases a ‘No’ response may support the concept but may have objected to the actual phrasing. Need to figure out where there is agreement and/or minor issues that can be easily addressed so focus can be on the significant disagreements. · We do the triage exercise to establish which parts of the temporary specification are controversial and what the reasons for objections are. Therefore, suggestion is to indicate the level of support and be a little more wordy on the reasons for objections. That can probably help avoid discussions on these calls. · Need for proper definition of terms to be able to express views. · Maybe should have focused on, do you agree in principle with this section to weed out minor issues vs. substantial ones. Action item #5: Staff to share presentation that Becky Burr provided to GNSO Council with EPDP Team. Section 7. Requirements Applicable to Registrars Only Issue Summary 7.1 - 7.1.8: Some comments indicated this provision is too prescriptive and, as such, is likely to: (1) give a false impression that following this direction provides full GDPR compliance, (2) not address privacy regimes in other jurisdictions, and (3) does not accommodate different business models. It would be better to generally require GDPR notice requirements. This clause does not include ICANN’s role and notice requirements as a data controller. Some supported this detailed direction but indicated additional detail and definition of terms (e.g., legitimate interest”) is necessary. · Who decides what is commercially reasonable? Issue Summary 7.1.9 – 7.1.15: Some groups believe more precision and detail is needed to cover all aspects of GDPR ("consent" should used as in list of defined terms), but contracted parties believe that the sections are too prescriptive, and each registrar and registry must figure out how to comply given its business model · May need single policy across all registries and registrars - EPDP Team's role to define what that is. Issue Summary (7.2 - 7.2.4): The potential implementers of Section 7.2 note (1) the difficulty of gaining consent to publish "additional contact information" and more clarity is needed around the purposes of collecting additional contact information; (2) the difficulty of multiple parties (other that the registrant) providing consent; (3) making each field "selectable" with regard to consent; It is also pointed out that GDPR-compliant consent is still not defined, and that consent should be clear in any case. Those seeking information seek to (1) accelerate the Consent capability implementation (faster than commercially reasonable) and (2) that any contact within the Whois set of contacts and others can consent to disclosure. · Some limited use cases in which registrants have provided consent to share data - not a clear process yet for how to communicate this with the registry, or how consent is obtained from other contacts that have been listed. Consent is a complicated matter. · Consent has to be as easily withdrawn as given - tracking the status of the consent is a challenge and as such may not be reliable basis compared to some of the other legal basis. · What happens if consent is withdrawn? Issue Summary 7.3 - 7.4: This clause is generally acceptable but the Appendix G to which it refers is likely flawed as it denigrates the position / rights of the gaining registrar. The rest of the team looks forward to a briefing by registrars of this issue so there might be agreement that the revised transfer policy is GDPR compliant. Appendix B - Data Processing Requirements Issue Summary - 1: It is suggested that this Section should be struck as the data that is escrowed under the RAA is different that Whois data and so this specification does not apply. It is also suggested that ICANN be identified as the Data Controller here for imposing this requirement and recommended that the RySG suggests that the escrow providers and contracted parties are best placed to work out how to operate escrow services in accordance with the GDPR. Issue Summary - 2: There are parallels to be drawn between data escrow transfers between countries and Whois data transfers between countries - are they both subject to the safeguards listed in Chapter V and what are the implications of that to Whois access? Also, it was pointed out that data escrow is governed by a set of agreements among ICANN (a data controller), the contracted parties and the data escrow provider and might be better left for those parties to negotiate. · There are already contractual obligations in relation to data escrow - does this belong in a temporary specification? Issue Summary - 3: Most agree with this provision but those that do not state that the EPDP needs to clarify ICANN's approach to data escrow agreements and the relationships (i.e. controller / processor) between the parties. This issue highlights the greater need to clarify roles and responsibilities of parties and the structure data sharing agreements. The escrow providers and contracted parties are best placed to work out how to operate escrow services in accordance with the GDPR. Issue Summary - 4: This section is supported. It was pointed out that data escrow is governed by a set of agreements among ICANN (a data controller), the contracted parties and the data escrow provider and might be better left for those parties to negotiate. · Should establish for a fact that ICANN Org is the data controller for this part and contracted parties are carrying this out on ICANN Org's behalf. · Negotiation should not only be left to CP and ICANN. Appendix F: Bulk Registration Data Access to ICANN Issue Summary: This section is supported. It was pointed out that domain names themselves may also be personal information and so this processing activity needs to be analyzed for purpose and legal ground. · Does ICANN Org have a plan in place for storing of this information? Isn't personal data stripped out of bulk registration data? Not clear what process is currently used. · Not clear how a domain name registration can be personal information. · Need to make sure that the way reporting is done is legally compliant. · Need to assess whether there are things that ICANN as the processor needs to do to ensure it complies with GDPR. · Is this a problem for the EPDP Team to solve or is this for ICANN Org to solve? Shouldn't this be ICANN Org's determination to make? 5. Review action items and questions for ICANN Org, if any Questions for ICANN Org from the EPDP team: 1. Is there a list and summary of ICANN contacts and engagements with the EDPB and/or other DPAs in relation to the Temporary Specification for gTLD Registration Data? All Action items: · Staff to circulate proposed Communication Plan with EPDP Team for input and review · EPDP Team to review communications plan and provide feedback · Staff to share instructions for use of alternate AC room with AC streaming prior to Thursday's meeting. · Council liaison, Rafik Dammak, to provide update on participation of alternates to GNSO Council and determine whether there any concerns about the proposed approach for live streaming the AC room to facilitate read-only access to AC. · Staff to share presentation that Becky Burr provided to GNSO Council with EPDP Team. · EPDP Team members to complete survey part 3 by Wednesday, 15 August at 19:00 UTC 6. Wrap and confirm next meeting to be scheduled for Thursday 16 August at 13.00 UTC. (Part 3 Survey results due Wednesday, 15 August by 19:00 UTC.) 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<http://learn.icann.org/courses/gnso> and visiting the GNSO Newcomer pages<http://gnso.icann.org/sites/gnso.icann.org/files/gnso/presentations/policy-…>.

1 0

Fwd: [Iwgdpt-list] Press Release of the Secretariat: Working Paper "Standards for data protection in cross-border data requests" released
by Stephanie Perrin Aug. 14, 2018

Aug. 14, 2018

Colleagues might be interested in this paper on cross border law enforcement issues and data protection standards. Stephanie Perrin -------- Weitergeleitete Nachricht -------- Betreff: [Internationale-presse-liste] Press Release / Working Paper "Data Protection in cross-border data requests" released Datum: Tue, 14 Aug 2018 12:10:38 +0200 Von: Presse <presse(a)datenschutz-berlin.de> An: internationale-presse-liste(a)datenschutz-berlin.de PRESS RELEASE Data protection in cross-border data requests for law enforcement purposes Berlin Group calls for standards The International Working Group on Data Protection in Telecommunications (so-called Berlin Group), chaired by the Berlin Commissioner for Data Protection and Freedom of Information, Maja Smoltczyk, has adopted the Working Paper ‘Standards for data protection and personal privacy in cross-border data requests for criminal law enforcement purposes’ at its 63 rd meeting in Budapest (Hungary) on 9 and 10 April 2018. Law enforcement has become an international undertaking. As data is more and more exchanged and stored around the world law enforcement authorities increasingly seek access to personal data held beyond their national borders in criminal investigations. In the light of this development transborder access to cloud data has been identified as high priority by governments and led them to take actions in this field. However, cross-border data requests present difficult questions of compliance with national and international data protection and privacy standards. Traditional arrangements to facilitate international coordination by law enforcement agencies as they work now are said to be overburdened by the increasing frequency and complexity of cross-border data requests. However, alternate arrangements for transferring data, like voluntary arrangements between providers and foreign governments, can be subject to varied or unknown standards, do not have force of law, and so provide little assurance of protection for the rights of data subjects. In its recently published Working Paper the Berlin Group urges that current and future legal frameworks must maintain strong data protection standards and makes recommendations for appropriate safeguards. The Working Group calls on governments and international organisations to preserve data protection and privacy interests while encouraging prompt and adequate processing of legitimate cross-border data requests. The Working Paper is available for download at http://www.berlin-privacy-group.org About the International Working Group on Data Protection in Telecommunications (“Berlin Group”) The International Working Group on Data Protection in Telecommunications (IWGDPT, a.k.a. “Berlin Group”) includes representatives from Data Protection Authorities and international organisations dealing with privacy matters from all over the world. It was founded in 1983 in the framework of the International Conference of Data Protection and Privacy Commissioners at the initiative of the Berlin Commissioner for Data Protection, who has since then been chairing the Group. The Group has adopted numerous recommendations (“Common Positions” and “Working Papers”) aimed at improving the protection of privacy in telecommunications. Since the beginning of the 90s the Group has focused particularly on the protection of privacy on the Internet. More information about the Work of the Group and the documents adopted by the Group are available for download on the website of the Group at http://www.berlin-privacy-group.org. -- International Working Group on Data Protection in Telecommunications - Secretariat - Berlin Commissioner for Data Protection and Freedom of Information (Germany) Berliner Beauftragter für Datenschutz und Informationsfreiheit An der Urania 4 - 10 D - 10787 Berlin Germany Phone: +49 30 13889 - 0 Fax: +49 30 215 50 50 E-Mail: IWGDPT(a)datenschutz-berlin.de http://www.berlin-privacy-group.org

1 0

Recordings, attendance & AC chat from the GNSO Temp Spec gTLD RD EPDP held Tuesday, 14 August 2018
by Andrea Glandon Aug. 14, 2018

Aug. 14, 2018

Dear all, Please find the attendance and AC chat attached to this email. The MP3 and AC recording below from the GNSO Temp Spec gTLD RD EPDP call held on Tuesday, 14 August 2018 at 13:00 UTC. These have also been posted on the agenda wiki page: https://community.icann.org/x/oQtpBQ MP3: https://audio.icann.org/gnso/gnso-epdp-gtld-registration-data-specs-14aug18… <https://urldefense.proofpoint.com/v2/url?u=https-3A__audio.icann.org_gnso_g…> AC Recording: https://participate.icann.org/p62crjhwq48/<https://participate.icann.org/p62crjhwq48/?OWASP_CSRFTOKEN=e491c17805cccb72…> ** 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

Consensus: more granular approach needed
by Tatiana Tropina Aug. 14, 2018

Aug. 14, 2018

Dear all, My name is Tatiana Tropina, I'm an alternate for Milton Mueller for the next few days because he can't attend today's call. I would like to forward his comments (which I fully agree with) on the approach to consensus. Please see below. =================== In determining whether consensus exists on certain key elements of the temp spec, I think we are suffering from the way items were grouped. Some SG’s said “No” because they objected to one thing in the group, but a more granular approach might find wider agreement on certain elements within that grouping. My example here is the responses to Appendix A 2.4., 2.5., 2.5.1. - 2.5.1.3., 2.5.2., 2.6., which deals with how the temp spec redacts certain PII from public Whois. NCSG strongly supports those redactions, and in fact we think ICANN has little choice about it because of the GDPR. However, on the survey we see only 2 SGs supporting that question. If we look closer, however, there is actually not much disagreement with the redaction. Registrars support redaction “but questions whether this data should continue to be collected as they are not necessary, and do not comply with data minimization principle.” So the registrars are conflating the collection issue with the public display issue here. They do support redaction of the data elements listed in the temp spec. So do the Registries. Ry SG comments call attention to the litigation around collection of the redacted data and has some other comments unrelated to the question whether the temp spec’s redaction requirements are acceptable. So again we have a debate about collection rather than display. Even the GAC comments do not dispute that the data should be redacted. They call for changing “redacted for privacy” to “redacted for data protection” in the display, and call for additional text with instructions about how to get access to redacted data. Both SSAC and IPC also do not question that redaction is required for GDPR compliance but question the scope of the redaction, saying that it may not be necessary in cases where GDPR does not apply (however they overlook or ignore the existence of similar data protection laws in other jurisdictions). SSAC also make a somewhat irrelevant call for 2 years data retention (which the EDPB has already questioned). In short, a careful review of the comments shows that there is almost no opposition to the selection of data that the temp spec asks to be redacted. We are close to consensus on that vital issue. If it is lumped in with a bunch of other issues, however, more SGs and ACs can find something they don’t like. Since the redaction is fundamental to the temp spec, let’s pull that out and indicate something close to consensus on it. Dr. Milton L. Mueller Professor, School of Public Policy Georgia Institute of Technology ========= Warm regards, Tatiana

2 1

Request for Adobe Access (Read-only) for Alternates
by Rosette, Kristina Aug. 13, 2018

Aug. 13, 2018

All, On behalf of the RySG, I'm writing to request that EPDP Alternates be granted read-only access to the Adobe Connect room. We are finding that, without access to the Adobe room, it is difficult for the Alternates to follow the meeting fully, to assist Members during the meeting, and to prepare for direct participation (when doing so for a Member). If it would be possible for us to add this request to our agenda for tomorrow (as an AOB), the RySG would appreciate it. I apologize for the short notice, but I had drafted another version of this email on Friday, where it got stuck in my pre-vacation Outbox. Thank you. Kristina Kristina Rosette Senior Corporate Counsel, IP - Domains rosettek(a)amazon.com<mailto:rosettek@amazon.com> | 703.407.1354

1 0