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

IPC/BC/RySG and others: requesting an extension on can't live with items
by King, Brian July 10, 2020

July 10, 2020

Hello EPDP Staff and Leadership, On behalf of the IPC/BC/RySG and other groups who I know feel similarly but with whom we have not yet been able to caucus officially: We have been diligently working through the report during this silent week, and many of us have found it quite challenging to provide thoughtful and constructive comments on each recommendation in this short a timeframe. While we work recommendation-by-recommendation, many of us are also grappling with the report as a whole, and we need time to confer within our constituencies to understand which are our most pressing “can’t live with” items, and to come up with creative solutions if needed to come to consensus. We note that many of our most challenging and contentious issues were the ones discussed most recently. Taking just five or so days to review new language on our most important issues with our constituencies has proven to be quite challenging, if not impossible. Frankly, it would not do justice to all the hard work we have put in to get this far if we rush through the most important parts, particularly if consensus will depend on more thoughtful review and constructive conversation. In light of the difficulty to accomplish substantive review and discussion in the requested timeframe, and with the goal of achieving consensus in Phase 2, we would like to request an additional two weeks to work through our “can’t live with” items. If granted, we can commit to providing thoughtful, constructive suggestions on any remaining items by COB on Friday, July 24. Thank you for your consideration. Brian J. King Director of Internet Policy and Industry Affairs, IP Group T +1 443 761 3726 clarivate.com [D39D107B] Confidentiality note: This e-mail may contain confidential information from Clarivate. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this e-mail is strictly prohibited. If you have received this e-mail in error, please delete this e-mail and notify the sender immediately.

8 10

**Updated date and duration | Meeting Invitation | Observers | GNSO Temp Spec gTLD RD EPDP-P2 call | Tuesday, 21 July 2020
by Terri Agnew July 10, 2020

July 10, 2020

**Adjusted date from Tuesday, 14 July 2020, 2 hours to Tuesday, 21 July 2020, 3 hours (see update below). As a result of various requests to facilitate observers to follow the EPDP Phase 2 deliberations in real time, zoom webinar room will be made available for the EPDP plenary meetings. As a reminder, the zoom recording, audio recording, chat transcript and transcript of the EPDP plenary meetings will be publicly posted as soon as available on the EPDP wiki page and GNSO master calendar. Dear all, The next meeting of the GNSO Temp Spec gTLD RD EPDP – Phase 2 is scheduled on Tuesday, 21 July 2020 at 14:00 UTC for 3 hours Zoom room information: Main Zoom Webinar link: please join via this link: https://icann.zoom.us/j/98917212893?pwd=dTRQaEMwK0tweStXTVhpVERsVjdhZz09 [icann.zoom.us]<https://urldefense.proofpoint.com/v2/url?u=https-3A__icann.zoom.us_j_989172…> Password: 953887 Going forward, observers will now join via zoom webinar room vs audio cast. Observers will have ability to view member chat and information shared in the zoom webinar room. Observers will not be able to use chat or raise hands. Before joining the call: Please send dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only Please be sure you have read the Please be sure you have read the Expected Standards of Behavior [icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_resource…> Visit the Wiki agenda page: https://community.icann.org/x/dgJcC Check your time zone: https://tinyurl.com/yb8rhmxb The recordings and transcriptions of the calls are posted on the GNSO Master Calendar page: https://gnso.icann.org/en/group-activities/calendar<https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_en_grou…> If you are joining via audio only: iPhone one-tap : US: +16699006833,,98917212893#,,#,953887# or +13462487799,,98917212893#,,#,953887# Dial in directly with your chosen number [icann.zoom.us]<https://urldefense.proofpoint.com/v2/url?u=https-3A__icann.zoom.us_u_acwzlz…> and provide the following information: Webinar ID: 989 1721 2893 Thank you. Kind regards, Terri

1 0

EPDP Phase 1, Rec 17.2 Study: Legal/Natural Differentiation
by Eleeza Agopian July 9, 2020

July 9, 2020

Dear EPDP team, Please see the below note and attached study on legal/natural differentiation from Karen Lentz, Senior Director, Policy Research & Data Services. Thank you, Eleeza and Dan ICANN org liaisons ------ Dear EPDP Team, Attached is the report on risks, costs, and feasibility of differentiation between legal and natural persons, per the EPDP Phase 1 recommendation 17.2. Some key points are summarized below. · We were asked to respond to the Phase 1 recommendation 17.2 on evaluating the risks, costs, and feasibility of differentiating between legal and natural persons in registration data directory services. · The report is to help inform the policy deliberations, and does not provide policy recommendations. As discussed with the EPDP Team, providing recommendations or normative assessments as to the differentiation between Legal and Natural persons was not in scope for the study. · The report reviews available analysis on this topic, including a review of academic literature and legal advice, as well as inputs from a questionnaire sent to the EPDP Team and ICANN Community with questions on differentiation. · The study uses a model that illustrates how risks, costs/benefits and feasibility are affected under different policy scenarios. The aim is to demonstrate how changing a variable at the policy level affects the system as a whole. · The report finds that differentiation would, in effect, redistribute the risks and costs associated with processing registration data. · End-users of registration data noted a number of risks and costs from having access to fewer data records as a result of the data redaction associated with applicable laws and policies (e.g., decreased cybercrime and/or intellectual property enforcement capabilities). · The model presented illustrates how this redistribution of risks and costs might change under a policy requiring differentiation. In such a scenario, contracted parties would bear many of the costs and risks associated with differentiation, such as the cost of devising and implementing an accurate and reliable method to differentiate, as well as the risk of legal liability should such a method fail to accurately differentiate. · Differentiation could pose a cost to natural person registrants, if it results in some proportion of natural person registrant data being published as a result of error or negligence. · The benefits of differentiation, as well as the impact of measures to mitigate the risks and costs of differentiation, may outweigh these risks and costs under a scenario in which differentiation is a policy requirement. It remains for the EPDP Team to determine the relative balance of these factors as they deliberate on the topic. I understand the Phase 2 team is closing with its work plan and will not be addressing the differentiation issue in its Final Report. Nonetheless we wanted to share the information, which can also be used as a basis for continuing discussion, as the GNSO Council is discussing how to proceed with the priority 2 issues. I also acknowledge that the report delivery is later than we hoped. We appreciate the team’s interest in this and can support further discussion at the relevant phase, and when the Team has had an opportunity to review. Best regards, Karen -- Karen Lentz Senior Director, Policy Research & Data Services Internet Corporation for Assigned Names and Numbers (ICANN) Mobile: +1 310 895 3637 www.icann.org

2 1

EPDP - Member wiki page check/SOI check
by Julie Bisland July 6, 2020

July 6, 2020

Dear all, In an effort to ensure accuracy, please take a moment to check your GNSO SOI and make any needed updates (ensure you are signed in and select EDIT CONTENTS at the top of the page). In addition, would all members, alternates, and observers kindly visit the WG Members wiki page: https://community.icann.org/x/kBdIBg, select the top, most recent roster dated 06 June 2020 and please verify your information is correctly displayed. For any updates to the member wiki page or if assistance is needed with your GNSO SOI, please email gnso-secs(a)icann.org<mailto:gnso-secs@icann.org>. Please note all updates to SOIs must be done by you, as staff we are unable to update. Much thanks to you all, GNSO SO/AC Support -- Julie Bisland GNSO SO/AC Support coordinator Internet Corporation for Assigned Names and Numbers (ICANN) Skype ID: 79613b691cb8a6c1 Find out more about the GNSO by visiting: https://learn.icann.org/<https://urldefense.proofpoint.com/v2/url?u=https-3A__learn.icann.org_&d=DwM…> Follow @GNSO on Twitter: https://twitter.com/ICANN_GNSO<https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_ICANN-5FGN…> Transcripts and recordings of GNSO Working Group and Council events are located on the GNSO Master Calendar <https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_en_grou…>

1 0

Latest version of Final Report posted for review - silent week starts now!
by Marika Konings July 5, 2020

July 5, 2020

Dear EPDP Team, The latest version of the EPDP Team Phase 2 Final Report has been posted for your review (see https://community.icann.org/x/K4LsBw) Please note that we have posted three versions: 1. Clean version with line numbers in pdf format – please use this version to reference your comments / input. 2. Clean version in word format 3. Redline version in word format – note this version includes the redlines from the 10 June version as well as the updates that have been made since. We have tried as much as possible to flag in the form of comments the origin of the changes since the 10 June version but as you will see, there is a lot of redline that may make reviewing this version slightly more challenging. Please provide your group’s input in the google doc (https://docs.google.com/document/d/17RIW9Zpz_IV84L0NFiNFkK5yzaOV3ogt/edit) by Friday 10 July at the latest. To facilitate your input, we have created three categories: * Category 1) Cannot live with (not able to support this recommendation and/or report if this is not addressed) * Category 2) Would really like to see this change, if it does not create heartburn for others, but not willing to die in a ditch for it * Category 3) Non-substantive / minor edits for consistency / editorial. Please try to avoid reopening previously agreed issues. Also, if your group does have concerns, please provide specific suggestions for how these concerns be addressed while also factoring in the positions of others. Happy reading! Please do not hesitate to reach out to us if you have any questions. Best regards, Caitlin, Berry and Marika

1 0

EPDP-P2 Project Package - 30 June 2020
by policy＠bacinblack.com July 3, 2020

July 3, 2020

Dear All, Please find attached the EPDP-Phase 2 Project package that closes out June of 2020. Note, this version does not account for the tasks completed this past week. Additionally, staff would like to thank Ambassador Karklins for his leadership during this EPDP. We enjoyed collaborating with him on this project. Key Highlights: * Project Timing, Status and Health: * Project duration is listed at 94% which reflects a revised completion date of 31 July 2020. * Percent complete is 95% reduced from prior period of 96% due to the additional time required to deliver the Final Report by 31 July 2020. * Status has returned to "Revised Schedule" upgraded from "Target will be missed" due to the Project Change Request reviewed by the GNSO Council at its June meeting. * Health remains at "At-Risk" due to unstable agreements of key recommendations of the SSAD. * Project Budget: * The EPDP-P2 was granted $760,000 following two resource requests from the GNSO Council to the ICANN Board. * ICANN Org's fiscal year closed 30 June 2020, for which the remaining budget was credited back to the reserve fund. * 42.1% or $320,461 of the budget was utilized for professional services and travel. $439,539 budget remained. * Of the $300K committed for travel, $136,287.48 was expensed. Note, this is subject to a revision <$1K awaiting final expense reconciliation. * Of the $300K committed for legal services, $111,899.35 was invoiced and paid. * The remainder of expenses were used for facilitation and remote participation services. * No additional expenses to deliver the SSAD Final Report are foreseen. You can find the individual work products on the wiki: https://community.icann.org/x/6BdIBg. As noted in our meeting on 2 July 2020, the following schedule is proposed: * 5 July: distribution of updated draft Final Report. * 6 - 10 July: silent week - opportunity for EPDP Team to review draft Final Report and flag any minor edits (no reopening of previously discussed & addressed issues). * 14 July: tentative EPDP Team meeting to address any issues that may require EPDP Team input / guidance. * 17 July: distribution of Final Report and consensus designations. As a reminder, the Chair will make an evaluation of the support achieved for the recommendations and publish its designation for the group to review. * 20 - 24 July: opportunity for EPDP Team to respond to consensus designations, review by Chair of input received, if any, confirmation by Chair of designation. * 24 July: deadline for minority statements. * 31 July: No later than date for submission of Final Report to the GNSO Council Please inform the leadership team if you have any questions. Thank you. B Berry Cobb @berrycobb GNSO Policy Consultant

1 0

Notes and action items - EPDP Phase 2 Meeting #71 - 2 July 2020
by Caitlin Tubergen July 2, 2020

July 2, 2020

Dear EPDP Team: Please find below the notes and action items from today’s meeting. Thank you. Best regards, Marika, Berry, and Caitlin -- Action Items 1. EPDP Team Members to review the remaining yellow items<https://docs.google.com/document/d/10IQOJDwEpHj5meIb4P8JAIW2qb2A0oVp/edit>, provide additional information in response to questions, and indicate items that are still “cannot live with” and provide alternate text that is acceptable by COB Friday, 3 July. EPDP Phase 2 - Meeting #71 Proposed Agenda Thursday 2 July 2020 at 14.00 UTC 1. Roll Call & SOI Updates (5 minutes) 2. Confirmation of agenda (Chair) 3. Welcome and housekeeping issues (Chair) (5 minutes) 4. Consider outstanding items / questions in relation to recommendation 7/16 (automation) [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_docume…> * The draft on the screen was developed by the Staff Support Team after the Team’s last discussion of this item * A small team worked with staff on this version but did not come to any agreement on this version * The first change was to number the various paragraphs here * Updating processed in an automated manner instead of automatically disclose * In 16.4, the footnote now appears in the text and explains how a CP can notify ICANN org of a situation where the CP cannot automate a certain category of use cases * Following the notification, some members suggested a notice and comment process * As soon as CP becomes aware that the exemption is no longer applicable, it is required to notify ICANN org to resume the processing * Updates to implementation guidance – updated to make the text clearer. In this specific recommendation, four use cases have been identified. a. Review outstanding items / questions b. EPDP Team Feedback * Footnote 3 conflicts with text regarding decisions where there may be some manual review – suggest deleting footnote 3 * On 16.4, confused why a waiver only addresses the legal permissibility issue and not the technical or commercial feasibility issue – these should be included in the exemption process. * For 16.5 – all that is required is for a CP to get this waiver is to send a notification to ICANN. How did the small team envision this working? In the spirit of automation, this should be automated as well. * Regarding a data subject’s rights to object to processing based solely on automation – where would that fit into all of this? * Have to resolve the conflict b/w footnote 3 and 16.11 in the recommendation. The “may” is unclear as to when it is invoked. Would envision that a use case could be approved, subject to there being human intervention, but the wording does not seem to allow for the fact that human intervention must be required. * The last sentence of 16.8 seems to belong in 16.5 * This can be put in a separate section for the sake of clarity * Need confirmation from ICANN org that it can refuse exemption requests that are not deemed to be reasonable * Confused as to how we ended up with processing of disclosure decisions instead of automated disclosure decisions – this text changes fundamentally what this section means – suggest automated disclosure decisions and related processing. * Regarding determination of permissibility and feasibility – this needs to be made by the contracted party. For 16.4 – there is the word “demonstrates,” this conflicts with 16.5 and the word notifies. 16.4 should be changed to notified. 16.5 is a good solution – had originally objected to a process akin to the data retention waiver process. * By having CPs prove to ICANN that it has a legal issue, it puts the onus on a CP to prove that something is not legally permissible, and this should be the other way around. Could “demonstrate” in 16.4 be changed to “determine”? * If there has been an exemption request that has been determined and notified, and that exemption request is granted – there should be a mechanism where similarly-situated contracted parties could get the same exemption. * Re: automated disclosure and automated processing, it sounded like terms were redefined. Where we talk about legally permissible, and technically and commercially feasible, technically feasible and commercially feasible need to be broken out. There could be standardization for automation. Overall concern regarding Org’s agility to facilitate this waiver process. * Automation is technically feasible – full stop. Legally permissible – we’re on the right track with a jurisdictional opt out. For commercially feasible – this is a chance to improve this and not leave it to the sole discretion of contracted parties. What types of scenarios would make it not commercially feasible for a contracted party to automate? If CPs are not commercially able to connect to the SSAD, that is a problem. We need some guardrails around commercial feasibility. * In this final report we determined a few areas where automated disclosure must be done, and then recommendation 19 kicks in. Do not see a place where CPs can opt out of commercial feasibility. * Agree that if you are not up to the task to be contracted party, there are other options (like becoming a reseller). For when a registrar that is not commercially feasible, it could be a registrar with no registrations or only has a small number of corporate registrations * For 16.1 and 16.2 – any problems with proposed text? * No. * For 16.3 – any problems? * No problem with 16.3 if commercially and technically feasible could be added to 16.4; otherwise, the “must” is problematic * Prefer the obligation to be to demonstrate that what is proposed is not legally permissible * The right for data subjects to object is already covered under legal permissibility * Footnote 3 is a footnote to the title of the section – when will we discuss this? * In 16.4, would the technical and commercial feasibility apply in the same way that legal permissibility is captured here? * If “demonstrates” becomes “determines,” this would be OK * On 16.4, could we say “the CP can get an exemption from automated processing but must notify ICANN” – the current language implies that ICANN will decide whether the exemption applies or not. * With the language in 16.5, this is OK. * IPC has a concern with changing demonstrates to determines – the right to unilaterally determine whether they are going to follow the policy or not is unacceptable without the ability to follow some guardrails. Technically and commercially feasible is too subjective. * The potential with abuse here is not negligible, but uncomfortable with ICANN determining what is commercially feasible for a contracted party. * Suggest doing a copy/paste including demonstrate with commercial and technical feasibility (without the DPIA clause) * Do not know why we are adding commercially and technically feasible * Could live with determine for legal feasibility, but the technical/commercial, it needs to be demonstrated due to the subjective nature of this For implementation purposes, how would the CP demonstrate this is not technically and commercially feasible, who would they demonstrate this to and how? * For clarity, if a Contracted Party demonstrates that automated processing of disclosure decisions for the use cases specified in this recommendation or through the processes detailed in Recommendation #19 is not commercially or technically feasible, the Contracted Party MUST notify ICANN Org it requires an exemption from automated processing of disclosure decisions of the identified use case(s). * The technical and commercial feasibility is determined in 16.3 and in Rec. 19 – do not agree to adding this paragraph. The CP would need to demonstrate this to ICANN. * Couple of issues to address: the technical feasibility needs to go – it will be technically feasible full stop. For commercially feasible – before we can agree that there is some reason for it to be NOT commercially feasible, there needs to be guardrails * Do not think we should make a determination now over what would be technically or commercially feasible * Have a problem with a unilateral determination of commercial feasibility. Smaller registrars in developing countries may have commercial issues. Could we create a special exemption based on economic hardship in developing countries? * Can the group live without 16.4bis? * Do CPs really need exemptions for commercial and technical feasibility? * Yes, but we need to find a way so that this is not abused. * Suggest adding in 16.4bis – after contracted party, especially small in size, operating in developing economies * Small in size is not a guardrail – how small? How is that defined? How is developing economy defined? If you can’t do this, it’s a key part of the DNS, so you can’t be a registrar. Cannot live with this as is. Alternative proposal is to deleted 16.4bis. * Small registrars have the option of automating this – they could voluntarily ask the CGM to automate decisions for them. * Small in size is not the right number. Not sure how to close the gap between now and the day where someone releases an opensource AI. * CPS may or may not automate their own decision processes on whether to disclose. Thought we were talking about disclosure when SSAD has made the decision. * 16.5 * All that CPs are asking for a path or open door – what about through implementation and allowing for the opting out of edge cases and remove 16.4 * For 16.5 – if this is for a legal reason, this would be the only way to do this * Question from ICANN org – the language in 16.6 seems to contemplate a notice and comment process – regarding the supporting information, what is the supporting information? * If a CP determines that there is a legal impermissibility, they have to provide the supporting documentation. * MUST the DPIA be included for public comment? * The CP needs to provide the documentation that led them to determine that there is a legal issue. * Concerned about the language in this exemption, particularly the language regarding DPIA. This sounds like a WHOIS Conflicts procedure. There shouldn’t be a DPIA to stop disclosing. All the CP needs is short text with a sound argument as to why it can’t release the data. Do not need to overcomplicate this. If ICANN org is willing to perform a mediation process, that is fine – but have to remember that the burden is on the CP to comply with law. * "Supporting documentation" that is, what information supports the claim that the automation is no longer legally permissible. * This only kicks in if a CP exemption is challenged – goes to reason that CP that sought the exemption has their supporting rationale, and the CP would provide the supporting information as part of the process in 16.6 * If input needs to be replaced by supporting information, that could be helpful. * This language leaves out important questions – must the CP provide the supporting information to ICANN – may ICANN publish it? Can the Rr mark it as confidential? What if the parties cannot come to agreement, then what happens? * For 16.6, instead of input, say supporting documentation. Add further details will be developed during the implementation phase. * Affected stakeholders want to see the supporting documentation, but there is no clarity on whether ICANN org can publish this or share it with affected stakeholders. * Consider adding in case of challenge, ICANN must provide notice and comment process. * ICANN providing a notice and comment process is how affected stakeholders would become aware of this. * Intent under 16.4, and this may not have been clear enough, as part of notification, supporting information would be provided. There may need to be questions worked out in implementation regarding confidentiality. ICANN received this notification, for these reasons, are there concerns with this? * MUST the info be presented to ICANN, can it be marked as confidential, must it be published, how would disputes be resolved? Need further information. * Could this be sorted out in implementation? * Helpful that it would be published and there would be an opportunity for comment. If everything is left to implementation, this would be a years-long process. * Regarding changing input to supporting information – this change was likely made in error. Supporting documentation is more restrictive than input * In 16.4, make clear that notification to ICANN org also includes supporting information and move 16.6 back to its original state * 16.7 * No issues. * 16.8 * Last sentence of 16.8 – what is subject to review? What action could be taken by ICANN org in response? * This last sentence should be separated from 16.8 * 16.8bis “Unreasonable notifications may be subject to review,” * As a structural drafting matter – this probably belongs higher and attach onto 16.4. The MAY language needs to be changed. This is an exemption to ICANN Consensus Policy – language “ICANN Compliance MUST review exemption notifications” * How is ICANN to make a determination on what is a reasonable exemption? * ICANN Compliance should be ICANN org to allow more flexibility * Under what circumstances would a review take place? * Based on this policy, it’s not clear what ICANN is to do if an exemption is unreasonable? * How does ICANN enforce this? This is enforced by ICANN Compliance. * ICANN org MUST reverse the exemption if it is found by ICANN to be incorrect, abusive, or no longer applicable. * This will be added to 16.4 * 16.9 * No issues. * 16.10 * No issues * 16.11 * Delete footnote 3 when 16.11 is endorsed * Instead of 16.4bis, consider: add a footnote in 16.3 where it says ‘commercially’ that says something like: “During implementation, further consideration will need to be given to the commercial feasibility for registrars that may receive a very limited number of requests that will meet the criteria for automated processing of disclosure decisions and whether the financial burden of enabling this automated processing is of such a nature that an exemption may need to be provided. As part of this consideration, the CGM also should consider how it can facilitate the integration of a CP’s system with the SSAD to reduce any potential burden of automated processing of disclosure decisions.” * Is this footnote acceptable to everyone? * All can live with this. * It is conceivable that we have use cases but they can only be automated with human intervention at the SSAD. Propose the following text: "The SSAD MAY use human review for any automated SSAD decisions, but there may be specific classes of disclosure requests approved for automation where human review MUST be included" – proposed footnote to 16.11 * ALAC put in a comment that the SSAD should allow for centralized decisions – 16.11 said which may involve non-automated review at the central gateway. The SSAD could make a decision, but there must be human review at the SSAD. Not saying they will do this, just allowing for it * Do not read 16.11 for the CGM to involve itself in the automated disclosure or intervene in the disclosure process itself – the above-proposed footnote for 16.11 is confusing * The confusion here may be over the word “making a decision”. For use case on UDRP verification, the legal guidance said there is a legal effect on data subject, so it cannot be automated. Maybe a way to address the concern – could the CGM see that there is a legitimate request and since the CGM confirmed the criteria are met, but by allowing a human to review whether the criteria for automation have been met, but the disclosing of the data is directed and automated. * What is confusing is we are not actually spelling out who is accountable for the disclosure decision in these hybrid decisions. At the end of the day, this needs to be decided in controllership agreements. The relevant question – who is the controller that made this decision, and does it require intervention from the contracted parties * Expectation – there could be personal data transferred as part of this * This is not a prohibition, but it is the expectation. * This was added for a concern by contracted parties – it’s a MAY and there is nothing from prohibiting a CP from sending over personal data * Implementation guidance – remove parenthetical in first paragraph (no human intervention) * Support Staff to number the implementation guidance * If the use cases move into policy, this could complicate Rec. 19 * When the conversation happens on particular use cases, the responsible parties would need to say yes or no * Leave it to Contracted Parties until there is definitive guidance the CGM would be solely liable * The purpose of the mechanism is to address this – this language makes it seem that one party can decide on its own outside of the mechanism. The mechanism is intended to look at the law, determine if there is a use case for automation, and if the CPs agreed as a whole, that would stand. * Seem to be batting the automation issue b/w Rec. 16 and Rec. 19. Automation rec says if it meets the requirements, it must be automated * 16.4 is about individual contracted parties believing something is not legally permissible * This language was added what is legally permissible and by whom * Does anyone object to leaving the language as is? * No. * Should 6(1)(e) automation be taken out? * GAC reps asked for this inclusion – 6(1)(e) lawful basis – this was accepted by the rest of the team * If this part of the policy, should specify that we’re talking about GDPR c. Confirm next steps 5. Continue run through of yellow items [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_docume…> (items identified for further discussion / clarification) a. Consider yellow items identified for recommendations (continuing with rec #15 and moving down the list) * Suggest going to Rec. 8 * Alternative language provided for Rec. 8 * Team has decided that it’s up to the CP to determine the request – the new language is confusing. What is Compliance supposed to do exactly and how is this supposed to work * Wanted to preserve a roll for ICANN compliance to investigate disclosures from a single entity that are problematic * ICANN org – ICANN compliance can only enforce what the policy says, and the policy just says to evaluate – what is compliance supposed to do about that? * Conflict b/w first and second sentence – if you can’t do the first sentence, you can’t do the second sentence. * There are plenty of things ICANN Compliance can do in terms of metrics * If a reporter makes requests of a similar nature, and one registrar always accepts them and another denies them, Compliance could ask for a reason of how you did the balancing test. * There are some things in the recommendation that compliance should be able to act on request is denied solely based on x, for example * Concerned that the language that is highlighted is of two minds – will not address the merits but will address unreasonable denials * Could ICANN enforce MUST provide reasonable access? Would it help if the language is updated to say “typically” * MUST provide access where reasonable instead of must provide reasonable access * Proposal to accept Laureen’s proposed updated language * Recommendation 2, Accreditation of Governmental Entities – 86 suggestion from ICANN org to replace data controller to relevant contracted party or Central Gateway Manager, or applicable * OK with this change. * Item 87 – footnote that says IGOs and how they could get accredited. * Would the current wording allow for the host to accredit the IGO? * Next list of items deal with Logging Recommendation * Are identity providers required to log, or is this something that could be determined in the implementation phase? * Leave as is. * Isn’t the general category of denial sent to the gateway and the requestor under Rec. 6? * Item 82 – question for the BC – change that was made that says disclosure decisions including a written rationale must be stored. Is written necessary? * Concern can be addressed now that rationale = reason for decision b. EPDP Team feedback c. Confirm next steps * All other yellow items should be handled online – provide written input and focus on what you “cannot live with” that needs to get addressed in the report. 6. Wrap and confirm next steps (5 minutes): i. 5 July: distribution of updated draft Final Report. ii. 6 - 10 July: silent week – opportunity for EPDP Team to review draft Final Report and flag any minor edits (no reopening of previously discussed & addressed issues). iii. 14 July: tentative EPDP Team meeting to address any issues that may require EPDP Team input / guidance. iv. 17 July: distribution of Final Report and consensus designations. As a reminder, the Chair will make an evaluation of the support achieved for the recommendations and publish its designation for the group to review. v. 20 - 24 July: opportunity for EPDP Team to respond to consensus designations, review by Chair of input received, if any, confirmation by Chair of designation. vi. 24 July: deadline for minority statements. vii. At the latest by 31 July: submission of Final Report to the GNSO Council

1 0

Post Call | GNSO Temp Spec gTLD RD EPDP – Phase 2 | Thursday, 02 July 2020 at 14:00 UTC
by Terri Agnew July 2, 2020

July 2, 2020

Dear all, All recordings for the GNSO Temp Spec gTLD RD EPDP – Phase 2 held on Thursday, 02 July 2020 at 14:00 UTC can be found on the agenda wiki page <https://community.icann.org/x/IoNIC> (attendance included) and the GNSO Master calendar <https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_en_group…> . These include: * Attendance (please let me know if your name has been left off the attendance list) * Audio recording * Zoom chat archive * Zoom recording (including audio, visual, rough transcript) * Transcript As a reminder only members and alternates can join the call as panelist, observers can join as an attendee to listen. For additional information, you may consult the mailing list archives <https://mm.icann.org/pipermail/gnso-epdp-team/> and the main wiki page<https://community.icann.org/x/IYEpBQ>. Thank you. With kind regards, Terri

1 0

Meeting Invitation | Observers | GNSO Temp Spec gTLD RD EPDP-P2 call | Tuesday, 14 July 2020
by Terri Agnew July 2, 2020

July 2, 2020

As a result of various requests to facilitate observers to follow the EPDP Phase 2 deliberations in real time, zoom webinar room will be made available for the EPDP plenary meetings. As a reminder, the zoom recording, audio recording, chat transcript and transcript of the EPDP plenary meetings will be publicly posted as soon as available on the EPDP wiki page and GNSO master calendar. Dear all, The next meeting of the GNSO Temp Spec gTLD RD EPDP – Phase 2 is scheduled on Tuesday, 14 July 2020 at 14:00 UTC for 2 hours Zoom room information: Main Zoom Webinar link: please join via this link: https://icann.zoom.us/j/98917212893?pwd=dTRQaEMwK0tweStXTVhpVERsVjdhZz09 Password: 953887 Going forward, observers will now join via zoom webinar room vs audio cast. Observers will have ability to view member chat and information shared in the zoom webinar room. Observers will not be able to use chat or raise hands. Before joining the call: Please send dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only Please be sure you have read the Please be sure you have read the Expected Standards of Behavior [icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_resource…> Visit the Wiki agenda page: https://community.icann.org/x/dgJcC Check your time zone: https://tinyurl.com/y7pde7ak The recordings and transcriptions of the calls are posted on the GNSO Master Calendar page: https://gnso.icann.org/en/group-activities/calendar<https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_en_grou…> If you are joining via audio only: iPhone one-tap : US: +16699006833,,98917212893#,,#,953887# or +13462487799,,98917212893#,,#,953887# Dial in directly with your chosen number [icann.zoom.us]<https://urldefense.proofpoint.com/v2/url?u=https-3A__icann.zoom.us_u_acwzlz…> and provide the following information: Webinar ID: 989 1721 2893 Thank you. Kind regards, Terri

1 0

Notes and action items - EPDP Meeting #70 - 1 July 2020
by Caitlin Tubergen July 2, 2020

July 2, 2020

Dear EPDP Team, Please find below the notes and action items from today’s meeting. The next meeting will be tomorrow, 2 July at 14:00 UTC and will run for 4.5 hours (if needed). Best regards, Marika, Berry, and Caitlin -- Action Items 1. In advance of tomorrow’s meeting, EPDP Team members to please review the updated Rec. 16/7<https://docs.google.com/document/d/1dlOhPn5djTVLFBw7TROID0rWKgGIRhrr/edit> and provide “cannot live with” items with both an accompanying rationale for why this is a “cannot live with” item and specific suggestions for how the concern can be addressed. 2. For the remaining yellow items<https://docs.google.com/document/d/10IQOJDwEpHj5meIb4P8JAIW2qb2A0oVp/edit>, EPDP Team members to please provide additional clarification in advance of tomorrow’s meeting. EPDP Phase 2 - Meeting #70 Proposed Agenda Wednesday 1 July 2020 at 14.00 UTC 1. Roll Call & SOI Updates (5 minutes) 2. Confirmation of agenda (Chair) 3. Welcome and housekeeping issues (Chair) (5 minutes) * Rec. 6 issue – paragraph 5 – no objection to including the language, “nor can refusal to disclose be solely based on the fact that the request is founded on alleged intellectual property infringement” * Can the Team live with this change? * EPDP Support Staff to apply change 1. Consider outstanding items / questions in relation to recommendation #19 – Mechanism [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_docume…> a. Review outstanding items / questions * Can the EPDP Team provide additional guidance on how the difference between policy and implementation can be further delineated? For example, the following items were included in a previous iteration. Which of the below (if any) can be considered changes to implementation? i. SLAs (recommendation #9) ii. Automated use cases (recommendation #16/7) – review and assess possible updates to implementation of types of disclosure requests that can be automated; iii. Third-party purposes / justifications (recommendation #4) – review and assess possible updates to third-party purposes / justifications; iv. Financial sustainability (recommendation #15) – review and assess possible updates to implementation guidance in relation to financial sustainability. v. Operational and system enhancements - only for those items where ICANN org is looking for guidance from the GNSO Standing Committee. * Items that stay within the SSAD could be an implementation change. Items that flow through to contracted parties as obligations by ICANN Compliance would be new policy work, not implementation. As a starting point, ii would be policy, not implementation. * For third party purposes as a policy change, when we drew this list, it was about populating the drop box with a standardized formulation of purposes. * The scope is broad, and the standing committee can look at all of the issues of SSAD. It may be that the Standing Committee identifies it is a policy issue and refers it to the GNSO as a policy issue. * One of the most pleasing parts of this mechanism is that it has a broad scope of that the standing committee can consider – not in favor of earlier suggestion. Want to ensure that Advisory Committees are consulted vis-à-vis the charter * This mechanism does not go far enough with what the evolutionary mechanism is meant to address – the policy, for example, the policy would be automatically updated for a new legal purpose. Section 4.2 of the Temp Spec said that if there is legal clarity given from the EDPB that clarifies legal purposes, that would update the requirements. * It is not an issue of whether the group can discuss it or not, it’s an issue of how this can be resolved. If it is deemed policy, and therefore a PDP would need be created, that is not what we agreed to. That is the crux of this. CPs would have to agree with recommendations of the Standing Committee, but for use cases that will not create liability, they need to be automated without a PDP. * The Team should not create a mechanism that would bypass the bylaws and the PDP process. For automation use cases, for example, the policy recommendation suggests that use cases are automated when it is legally permissible, it needs to be automated * Cannot make a mechanism that bypasses the policy development process – this seems to be what other members are saying. This committee can make recommendations to the Council, but it can’t just change what is legally permissible. What does it mean to say things that are automatically adjusted – based on what? This is not acceptable. * There are two ways to get binding policy obligations into a contract – a GNSO PDP or direct negotiations b/w contracted parties and ICANN org. We cannot create a mechanism that creates a third way to create binding policy obligations. * If there is a policy consideration, the Council could then launch a PDP * What if we get legal guidance and, on the fly, adjust the contractual obligations of contracted parties – this is not something that CPs can agree to as part of this PDP. That is a fundamental change to the bylaws. Saying that CPs have a veto still does not make this OK. This circumvents the GNSO policy development process. Do not understand the use case others have raised – we have established that CPs can automate. If others are trying to force automation, do not see how this could be interpreted as anything other than policy. * For Mark Sv’s list of use cases – the Team said it could be handled in evolution. If a decision is made to implement the ARS, the info would need to be released to ICANN – it would not impact privacy, and there would be no liability to the contracted party, that would be something that could be automated without changing the policy. That is the point that a number of others agree to – if there is agreement from CPs that it does not increase liability, it is not a change in policy, it is an implementation of policy. * Understood that the mechanism would be the place where future legal clarity would be considered. This would not be a policy change if the law evolves to a place where another legal basis is added or another purpose where it is permissible to access data. This would not go outside the bylaws, it’s just implementation of a broad policy recommendation that has been vetted by this group. * The conversation that we’re having here that cases where it is commercially feasible, is a statement of policy. What if six months from now after this policy is implemented, the EDPB said – the UAM presented by ICANN org to the EDPB is absolutely compliant with GDPR and the only controller with respect to transfer of data to the third party is the CGM. That suggests that use cases could be automated, but does that go all the way to adopting the UAM? You could say theoretically it is just implementation of policy, but that turns on other policy changes being adopted – moving from SSAD to a UAM would clearly be a major policy change * There is more to data protection law than disclosing data to third parties – CPs are still responsible for handing data over. * What may constitute policy and what may constitute implementation of existing policy. Does it give CPs any comfort to know that there would not be any automatic adjustment of automated use cases, but if there is new legal advice, this would be a subject for the standing committee to grapple with. The standing committee would still need to ensure it is dealing with implementation and not policy. * There are two levels of safeguards – one is within the standing committee itself, and one is within the Council * What we’re looking for is not policy development. The UAM has some key differences from what is developed here. We’re looking for types of automation and centralization that is allowable with further legal guidance. Section 4.2 of the Temp Spec – as soon as there is legal guidance from a competent body, CPs need to provide data within 90 days of guidance being published. Adding new automation use cases is not a policy change. What is legally, commercially and technically viable will change over time, and we need to get this updated without having a PDP. * The Team discussed centralization but decided not to take that path. Automation may replace centralization in the future. * Do not agree that Rec. 19 could change or evolve into a totally different model like a UAM. This is not possible through Rec. 19. Ask CPs to pinpoint what items could not be addressed because of contractual obligations. * Limiting the language to automation is OK for CPs, but decision making could be done at the CGM that is not fully automated * If the Team wants to achieve consensus, evolutionary mechanism needs to be a part of it. It appears that every group is a bit uncomfortable with this recommendation, which means there is balance. * Is there anything under paragraph b that groups cannot live with? * The text on the screen is not the problem. It is the unspoken part that is not OK. If the CPs agree that there are some use cases which could be implemented b/c they have been demonstrated to be legal and there is not a liability increase for CPs. If these, instead, would have to go to a PDP – ALAC cannot agree to this. This hinges on what is unsaid. * It seems that ALAC is saying that this committee, after doing its due diligence determines that something is legally permissible, the output of this committee would be a requirement for CPs to automate. NCSG would not agree that there are use cases that may be identified later that meet these criteria that would require them to automate. This is something that contracted parties need to determine themselves during a PDP. * Thought the Team had crafted the Rec. 16 carefully enough that automation is a MUST if legally permissible, technically and commercially feasible * The default voting threshold for GNSO Council motions that are not explicitly called out in the Bylaws have a simple majority threshold. * The GNSO has clearly established procedures for voting thresholds, and it takes into account the bicameral nature of the GNSO. Changing GNSO operating procedures and voting thresholds is not in the scope of this group. It needs to be clearer here that consensus requires for support from Contracted Parties. * The preceding sentence should be majority consensus, not full consensus. * If we were to go for unanimity, this may not be operational b/c one group could block consensus. * ALAC introduced having ICANN org liaisons to the committee – understand where that may be helpful – need to be clear on what the role would be. Since this is under the consensus section, it seems that ICANN org would be part of the consensus – this seems incorrect. * Consensus should consider equally the views of all. * B/c of potential liability and fines, CPs are specifically called out. * Some degree of consent for CPs is required – no one submits to ICANN’s authority except voluntarily * SSAD operator should have a veto and should be a party to any new recommendation * Does the scope for the GNSO Standing Committee require further limitation? Note: there is a proposal from the RrSG to include the following sentence, but GAC has expressed disagreement: “The Charter must not be restrictive in allowing the Committee to address any operational issues involving the SSAD, but should be clear that issues already addressed (meaning discussed, if not necessarily resolved) within Phase 1 or 2, including Phase 2 Priority 2 issues, are not part of this team’s purview.” * How will the GNSO deal with recommendations from the GNSO Standing Committee, i.e., what is the voting threshold to approve, and upon approval, do the recommendations go to ICANN Org for implementation or require a GNSO Policy Process? * Does the consensus process require additional updates? Some members have noted full consensus is difficult to achieve, and others have noted full CP consensus should not be required for every update (but may be required for updates to SLAs, for example). Can the Team provide further guidance on when full consensus or full consensus of the CPs is required? * RrSG proposes to remove the following items from the bulleted list in paragraph 1, noting these should only be b/w the CP and the SSAD operator. Does the EPDP Team agree to this removal? * Number of disclosure requests automated by the Central Gateway; * Number of disclosure requests automated by the Contracted Parties; * Number of requests processed manually * This bulleted list was included in the previous proposals – it was just to reflect that data points could feed into this. * Do not understand why these bullets are proposed to be removed * Consider changing to number of decision requests automated * Note – this is a minimum list of requirements * The data we’re talking about here will be produced by the CGM and will not require CPs to manually prepare data * Issue with changing “no later” to “no earlier” – not comfortable leaving it completely open ended – propose a cap – no earlier than 3 months, no later than 9 months * Instead of specifying a status report, it may be possible to implement these statistics on a rolling basis * Consensus = consensus plus (with CPs), NOT full consensus * Concerned that full consensus was taken out – this consensus puts the NCSG at a disadvantage against the commercial stakeholders group * If the Team is going to insist on representation for EPDP, that would be 25 people – that cannot work. If full consensus is required, ALAC or GAC could veto. * Suggest to add two additional hours to tomorrow’s call b. EPDP Team Feedback c. Confirm next steps 1. Continue run through of yellow items [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_docume…> (items identified for further discussion / clarification) a. Consider yellow items identified for recommendations (continuing with rec #15 and moving down the list) b. EPDP Team feedback c. Confirm next steps 1. Consider outstanding items / questions in relation to recommendation 7/16 (automation) [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_docume…> a. Review outstanding items / questions b. EPDP Team Feedback c. Confirm next steps 1. Wrap and confirm next EPDP Team meeting (5 minutes): a. Thursday 2 July at 14.00 UTC. Topics to be addressed: Any remaining items. b. Confirm action items c. Confirm questions for ICANN Org, if any

1 0