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

Important Update - ICANN68 to be Held as Zoom Webinars - ICANN
by Nathalie Peregrine June 22, 2020

June 22, 2020

https://www.icann.org/news/blog/important-update-icann68-to-be-held-as-zoom… Important Update - ICANN68 to be Held as Zoom Webinars [icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_news_blo…> [icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_news_blo…> [icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_news_blo…> [icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_news_blo…> [icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_news_blo…> [icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_news_blo…> On the first day of ICANN68, several sessions were subject to instances of disruption, or “Zoombombing.” This occurs when Internet trolls interrupt public Zoom meetings and use Zoom’s features to share offensive audio, images, and video. The individuals responsible for these disruptions were removed from the sessions by the Meetings Technical Services team as quickly as possible. To reduce these types of interruptions in the short term, some participant features were disabled, including the ability for participants to unmute their own microphones and rename themselves on the participant list. In other instances, chat between participants was also disabled. We do not take these incidents lightly and are working diligently to mitigate any future disruptions. All remaining ICANN68 sessions will be held using a password-protected Zoom Webinar format, with the exception of the Governmental Advisory Committee (GAC), pending further evaluation by GAC leadership. The event schedule, https://68.schedule.icann.org/ [68.schedule.icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__68.schedule.icann.org_…>, will be updated daily to reflect the changes to the Zoom participation links. All other services, such as remote simultaneous interpretation and real time transcription, are not impacted by this change. Please note that if you have exported any session information to your calendar, the links will not update automatically. To update your calendar, you will need to export the new information as it becomes available. The Participation Tools [68.schedule.icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__68.schedule.icann.org_…> section of the event website has been updated with information on how to use Zoom Webinars. We encourage all participants who are unfamiliar with how to participate in Zoom Webinars to review this information. We appreciate your understanding and will provide additional information as it becomes available. Details · ICANN Blog · Author: Ashwin Rangan, SVP, Engineering & Chief Information Officer · Sent from my iPhone David A. Olive Senior Vice President Policy Development Support Internet Corporation for Assigned Names and Numbers (ICANN)

1 0

Proposed Agenda - EPDP Team Meeting #67 - Tuesday 23 June at 14.00 UTC
by Marika Konings June 22, 2020

June 22, 2020

Dear EPDP Team, Please find below the proposed agenda for the next EPDP Team meeting which is scheduled for Tuesday 23 June at 14.00 UTC. As a reminder: * EPDP Team members to review the Recommendation Input Review tables<https://community.icann.org/display/EOTSFGRD/g.+Draft+Final+Report+-+Phase+2> and provide further information in response to clarifying questions for the remaining yellow items (beginning at Item 42 for Recommendation 9) in advance of the next meeting on Tuesday, 23 June. Input on the remaining yellow items can be provided here: https://docs.google.com/document/d/1gSdkEf4EyBM7z3YXAzGjTb-AULxOrDeC/edit. * EPDP Team members to review updated recommendation #6<https://docs.google.com/document/d/1F0wmMEh6gopJVsDFDF5pe5mGAUHhr9CV/edit> by Monday 22 June and flag ‘cannot live with items’. Best regards, Caitlin, Berry and Marika =============== EPDP Phase 2 - Meeting #67 Proposed Agenda Tuesday 23 June 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) 1. Status of small team deliberations on recommendation #19 (mechanism for SSAD evolution) 4. Continue run through of yellow items (items identified for further discussion / clarification) 1. Consider yellow items identified for recommendations (continuing with rec #9 and moving down the list) 2. EPDP Team feedback 3. Confirm next steps 5. Wrap and confirm next EPDP Team meeting (5 minutes): 1. Tuesday 30 June at 14.00 UTC. Topics to be addressed: continue run through of yellow items. 2. Confirm action items 1. Confirm questions for ICANN Org, if any

1 0

Input on remaining 'yellow items' list
by Marika Konings June 19, 2020

June 19, 2020

Dear EPDP Team, To facilitate your input under #1, the staff support team has posted an updated version of the ‘yellow items’ list which you can use to provide your input on the items from #43 onwards. Note that this version also includes some additional input that has been received on recommendation #2 (see end of the document) and the item flagged by the GAC under recommendation #8. You can either provide your groups input for an item in the right hand column or in the form of a comment. Please see https://docs.google.com/document/d/1gSdkEf4EyBM7z3YXAzGjTb-AULxOrDeC/edit. Your input would be appreciated by Monday 22 June COB. As a reminder, all google docs can also be found on the wiki page (https://community.icann.org/x/K4LsBw) Best regards, Caitlin, Berry and Marika From: Gnso-epdp-team <gnso-epdp-team-bounces(a)icann.org> on behalf of Caitlin Tubergen <caitlin.tubergen(a)icann.org> Date: Friday, June 19, 2020 at 06:10 To: "gnso-epdp-team(a)icann.org" <gnso-epdp-team(a)icann.org> Subject: [Gnso-epdp-team] Notes and action items: EPDP Phase 2 Meeting #66 - 18 June 2020 Dear EPDP Team: Please find below the notes and action items from today’s EPDP Team meeting. Best regards, Marika, Berry, and Caitlin -- Action Items 1. EPDP Team members to review the Recommendation Input Review tables<https://community.icann.org/display/EOTSFGRD/g.+Draft+Final+Report+-+Phase+2> and provide further information in response to clarifying questions for the remaining yellow items (beginning at Item 42 for Recommendation 9) in advance of the next meeting on Tuesday, 23 June. 2. Brian and Matt S. to work together on an updated formulation of Rec. 7 (must vs. should, footnote 43), taking into account the team’s discussion. 3. Support Staff to update the draft final report in accordance with the agreements from today’s meeting. EPDP Phase 2 - Meeting #66 Proposed Agenda Thursday 18 June 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) * Propose discussing Rec. 6 at our next team and allow staff to rewrite the recommendation based on yesterday’s discussion 4. Continue run through of yellow items (items identified for further discussion / clarification) 1. EPDP Team feedback * Item 35 – second paragraph in this recommendation: “The SSAD MUST allow for the automated disclosure of data in response to” – this update should be rejected as this may unnecessarily limit the automation part of the recommendation. Can this go back to the original formulation? * We requested that we allow for centralized decisions not only automated decisions * Automated disclosure narrows the sentence – automated processing allows for more automation * As long as it’s clear that the SSAD will allow automated decisions * Would like to explicitly mention the disclosure of the data – perhaps say “allow for automation of the processing, including the automation of the disclosure of data” * Everyone is OK with automating the receipt and processing requests, and now members are trying to shoehorn automated decision making here. This paragraph has no reason to be here because it is dealt with in Recommendation 7. Either we stick with the original language or delete the paragraph; the current modification is unacceptable. * Agreement to revert to the original formulation. * Items 36 – in one of the previous meetings, we discussed this part of the recommendation extensively. The language was originally SHOULD, and it was changed to MUST, but CPs were concerned about forced disclosure without any exemption. Footnote 43 outlines a process where CPs can notify ICANN Compliance when it believes is unable to automate the processing. * CPs have provided alternative language * Can the Team agree up front that there will be automated decision making in limited circumstances (where technically, legally, and commercially feasible), and that this is fundamental to the report? * There should be a way for CPs to put the brakes on if they cannot automate. Concerned about FN 43 to put the brakes on immediately, but there doesn’t seem to be the ability to assess if the brakes were properly applied. This seems to be a one-way street – there needs to be more meat on this so that ICANN can assess whether the concern is justified. There is an imbalance here. * There should be a procedure where the impacted groups are able to weigh in if they are in agreement with what has been designated as automated no longer is in light of guidance – there needs to be some kind of notice and comment process. * Not comfortable with the use of the word “MUST” – need to use “SHOULD”. Data protection law is generally a risk management decision, so there will inevitably be different interpretations of what is “legally permissible”. We all promote the concept of making this simple and inexpensive where feasible, but let’s not pretend that something is feasible when it’s not. * NCSG has moved far outside of its comfort zone – what would be the operational difference b/w must and should? Believe footnote 43 should be part of the main policy. Now, the concern is we are kicking the football to implementation guidance and the mechanism outlined in Rec. 19. Before we accept this language, what is happening in Rec. 19? If there is an acceptable process for Rec. 19, we can accept this language. If Rec. 19 turns into an alternative policy-making process, we cannot accept this. * The team can provisionally agree on this rec before Rec. 19 – if there is no agreement on Rec. 19, we can revisit this language. * Footnote 43 should be incorporated into the policy; footnotes should not have important text. * “Must automatically disclose data for any categories, subject to [caveat]” instead of “automatically process”. * From the RySG perspective, Rys had concerns with “should” to “must” and did not feel like the footnote language was sufficient to address the concerns. Rr suggestion is good here, in that they leave in the MUST but as a balance, but they leave it to the CP to determine what is technically and commercially feasible and legally permissible. CPs reside in different jx, so where the CP makes this determination that must automatically process is OK – strikes a good balance. It also allows for evolution. * If CPs make the determination, there is no need for a footnote. * IPC cannot live with CP in its sole discretion to decide whether to automate. This would not be enforceable by ICANN compliance. Interested in working on this exception process and how this would work. * Proposal – maintain the text as is on the screen where CPs must automatically process and elevate FN 43 into the policy (rather than a FN). * We have not done a DPIA despite certain parties screaming for it. In order for a CP to stop automate processing where they believe it is legally impermissible, they will have to do a DPIA. This is not cost-free, and we do not have a proper scoping of this. * This should be a SHOULD and there should not a high bar for a CP to get out of this if they believe the processing is not technically or commercially feasible or legally permissible * The change from SHOULD to MUST needs guardrails. If it is a must, the CP needs to make the decision. * Technically and commercially feasible may need to be treated separately. If this is a bilateral agreement b/w two parties, this could be discussed; however, with thousands of agreements, this is unworkable. Technically and commercially feasible should be separated out. * Rrs cannot have a process where the onus of proving that something is not legally permissible is on the Rr to prove. The DPIA needs to be done by ICANN. Just b/c something is legally impermissible in one jx, that doesn’t mean it needs to be pushed through for all jx. This language needs a lot more work. * The role of ICANN Compliance should be a check that this exemption request process is not being abused. This would be close to a rubber stamp process by Compliance – just to guard against abuse. * Item 39 from ICANN org asks some of the questions the Team has been speaking. * Some colleagues are still OK with automating based on what they believe is legally permissible. The language Rrs suggested allows CPs to make their own determination. This may result in more automation; in some cases, it will result in less automation. It’s very hard to come up with a one-size-fits-all solution. While we have focused on GDPR, there are other laws that may be applicable. * No amount of guardrails or caveats can turn a should into a must if there are so many unknowns * What should the role of ICANN be? This refers to ICANN Compliance, and policy should probably refer to ICANN org instead of ICANN Compliance specifically as it’s not a foregone conclusion that ICANN Compliance will handle this * Item 40 – even for decisions where the central gateway may direct automated disclosure, there may be manual processing at the central gateway, so there is some language added here – the CGM MAY request additional information to determine if the criteria for automated disclosure has been met. * Additional information may not be always be personal information * Do not see the harm in allowing this and it gives flexibility for the future * Why do we have this in if we cannot think of a concrete example? If it’s not clear to the CGM at the beginning, it doesn’t meet the criteria, and it should be manual. * Example – data previously disclosed – has this ever been disclosed before? If yes, it could be automated * The CGM makes determination on whether the criteria for automation has been met * What this is allowing is that the evolutionary mechanism may come up with new scenarios where the SSAD could disclose information – as CPs have pointed out repeatedly, Rrs are in many jx – some may be in a position to release information to the SSAD. This just allows flexibility to future decisions. * If we make sure that there is no transfer of personal data, that would be acceptable * Limiting this to no personal data unnecessarily limits this * Item 41 – GAC team requested an addition. RySG is asking for further context. * Based on Chris L-E’s explanation, OK with the particular edit, but the B&B analysis did not take this into account but neither were a lot of other law enforcement requests. This edit is OK, but there may be other problems. * “or processing is to be carried out under an Article 2 exemption” – the or is ambiguous * Chris to look at the sentence * “applicable” doesn’t always mean it’s only law enforcement – some jx may be able to request data subject to contract or treaty, there are also Rrs are set up in multiple countries * “or” could go after jurisdictions “or where processing is to be carried out under Article 2 * With either (i) local jx or (ii) confirmed article 2 exemption * Item 42 – Priority matrix should not be implementation guidance as there is text that is part of policy rec and part is implementation guidance. If the team agrees, which part should be in the policy language? (also relevant in the context of rec. 19 b/c anything that is the policy rec. cannot be changed except through a PDP) * If it’s moved into the policy rec., we would be locked in place * Policy rec could be such – initial rec is: [x] but this can be adjusted per the evolutionary model so it gives the flexibility that we intended to give. * Understanding is that at the very least the numbers in the third column were initial numbers that could be changed in implementation without changing the policy. * Item 43 – is this to be negotiations b/w ICANN org and CPs or are these policy requirements? * This may be tied to the Rec. 19 conversation. * When did the Team decide on one business day? * This is still an open question as to what business day means. * Recollection that we are still discussing business days. * Team to provide input by the next meeting. * In the Google docs, if groups want to provide input on the clarifying questions on what has been flagged, please add this to the Google doc. 1. Confirm next steps 5. Wrap and confirm next EPDP Team meeting (5 minutes): 1. Monday, 22 June at 14:00 UTC – Small Team for Rec. 19 2. Tuesday, 23 June at 14:00 UTC – continue run-through of yellow items 3. Confirm action items 1. Confirm questions for ICANN Org, if any

1 0

Notes and action items: EPDP Phase 2 Meeting #66 - 18 June 2020
by Caitlin Tubergen June 19, 2020

June 19, 2020

Dear EPDP Team: Please find below the notes and action items from today’s EPDP Team meeting. Best regards, Marika, Berry, and Caitlin -- Action Items 1. EPDP Team members to review the Recommendation Input Review tables<https://community.icann.org/display/EOTSFGRD/g.+Draft+Final+Report+-+Phase+2> and provide further information in response to clarifying questions for the remaining yellow items (beginning at Item 42 for Recommendation 9) in advance of the next meeting on Tuesday, 23 June. 2. Brian and Matt S. to work together on an updated formulation of Rec. 7 (must vs. should, footnote 43), taking into account the team’s discussion. 3. Support Staff to update the draft final report in accordance with the agreements from today’s meeting. EPDP Phase 2 - Meeting #66 Proposed Agenda Thursday 18 June 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) * Propose discussing Rec. 6 at our next team and allow staff to rewrite the recommendation based on yesterday’s discussion 4. Continue run through of yellow items (items identified for further discussion / clarification) 1. EPDP Team feedback * Item 35 – second paragraph in this recommendation: “The SSAD MUST allow for the automated disclosure of data in response to” – this update should be rejected as this may unnecessarily limit the automation part of the recommendation. Can this go back to the original formulation? * We requested that we allow for centralized decisions not only automated decisions * Automated disclosure narrows the sentence – automated processing allows for more automation * As long as it’s clear that the SSAD will allow automated decisions * Would like to explicitly mention the disclosure of the data – perhaps say “allow for automation of the processing, including the automation of the disclosure of data” * Everyone is OK with automating the receipt and processing requests, and now members are trying to shoehorn automated decision making here. This paragraph has no reason to be here because it is dealt with in Recommendation 7. Either we stick with the original language or delete the paragraph; the current modification is unacceptable. * Agreement to revert to the original formulation. * Items 36 – in one of the previous meetings, we discussed this part of the recommendation extensively. The language was originally SHOULD, and it was changed to MUST, but CPs were concerned about forced disclosure without any exemption. Footnote 43 outlines a process where CPs can notify ICANN Compliance when it believes is unable to automate the processing. * CPs have provided alternative language * Can the Team agree up front that there will be automated decision making in limited circumstances (where technically, legally, and commercially feasible), and that this is fundamental to the report? * There should be a way for CPs to put the brakes on if they cannot automate. Concerned about FN 43 to put the brakes on immediately, but there doesn’t seem to be the ability to assess if the brakes were properly applied. This seems to be a one-way street – there needs to be more meat on this so that ICANN can assess whether the concern is justified. There is an imbalance here. * There should be a procedure where the impacted groups are able to weigh in if they are in agreement with what has been designated as automated no longer is in light of guidance – there needs to be some kind of notice and comment process. * Not comfortable with the use of the word “MUST” – need to use “SHOULD”. Data protection law is generally a risk management decision, so there will inevitably be different interpretations of what is “legally permissible”. We all promote the concept of making this simple and inexpensive where feasible, but let’s not pretend that something is feasible when it’s not. * NCSG has moved far outside of its comfort zone – what would be the operational difference b/w must and should? Believe footnote 43 should be part of the main policy. Now, the concern is we are kicking the football to implementation guidance and the mechanism outlined in Rec. 19. Before we accept this language, what is happening in Rec. 19? If there is an acceptable process for Rec. 19, we can accept this language. If Rec. 19 turns into an alternative policy-making process, we cannot accept this. * The team can provisionally agree on this rec before Rec. 19 – if there is no agreement on Rec. 19, we can revisit this language. * Footnote 43 should be incorporated into the policy; footnotes should not have important text. * “Must automatically disclose data for any categories, subject to [caveat]” instead of “automatically process”. * From the RySG perspective, Rys had concerns with “should” to “must” and did not feel like the footnote language was sufficient to address the concerns. Rr suggestion is good here, in that they leave in the MUST but as a balance, but they leave it to the CP to determine what is technically and commercially feasible and legally permissible. CPs reside in different jx, so where the CP makes this determination that must automatically process is OK – strikes a good balance. It also allows for evolution. * If CPs make the determination, there is no need for a footnote. * IPC cannot live with CP in its sole discretion to decide whether to automate. This would not be enforceable by ICANN compliance. Interested in working on this exception process and how this would work. * Proposal – maintain the text as is on the screen where CPs must automatically process and elevate FN 43 into the policy (rather than a FN). * We have not done a DPIA despite certain parties screaming for it. In order for a CP to stop automate processing where they believe it is legally impermissible, they will have to do a DPIA. This is not cost-free, and we do not have a proper scoping of this. * This should be a SHOULD and there should not a high bar for a CP to get out of this if they believe the processing is not technically or commercially feasible or legally permissible * The change from SHOULD to MUST needs guardrails. If it is a must, the CP needs to make the decision. * Technically and commercially feasible may need to be treated separately. If this is a bilateral agreement b/w two parties, this could be discussed; however, with thousands of agreements, this is unworkable. Technically and commercially feasible should be separated out. * Rrs cannot have a process where the onus of proving that something is not legally permissible is on the Rr to prove. The DPIA needs to be done by ICANN. Just b/c something is legally impermissible in one jx, that doesn’t mean it needs to be pushed through for all jx. This language needs a lot more work. * The role of ICANN Compliance should be a check that this exemption request process is not being abused. This would be close to a rubber stamp process by Compliance – just to guard against abuse. * Item 39 from ICANN org asks some of the questions the Team has been speaking. * Some colleagues are still OK with automating based on what they believe is legally permissible. The language Rrs suggested allows CPs to make their own determination. This may result in more automation; in some cases, it will result in less automation. It’s very hard to come up with a one-size-fits-all solution. While we have focused on GDPR, there are other laws that may be applicable. * No amount of guardrails or caveats can turn a should into a must if there are so many unknowns * What should the role of ICANN be? This refers to ICANN Compliance, and policy should probably refer to ICANN org instead of ICANN Compliance specifically as it’s not a foregone conclusion that ICANN Compliance will handle this * Item 40 – even for decisions where the central gateway may direct automated disclosure, there may be manual processing at the central gateway, so there is some language added here – the CGM MAY request additional information to determine if the criteria for automated disclosure has been met. * Additional information may not be always be personal information * Do not see the harm in allowing this and it gives flexibility for the future * Why do we have this in if we cannot think of a concrete example? If it’s not clear to the CGM at the beginning, it doesn’t meet the criteria, and it should be manual. * Example – data previously disclosed – has this ever been disclosed before? If yes, it could be automated * The CGM makes determination on whether the criteria for automation has been met * What this is allowing is that the evolutionary mechanism may come up with new scenarios where the SSAD could disclose information – as CPs have pointed out repeatedly, Rrs are in many jx – some may be in a position to release information to the SSAD. This just allows flexibility to future decisions. * If we make sure that there is no transfer of personal data, that would be acceptable * Limiting this to no personal data unnecessarily limits this * Item 41 – GAC team requested an addition. RySG is asking for further context. * Based on Chris L-E’s explanation, OK with the particular edit, but the B&B analysis did not take this into account but neither were a lot of other law enforcement requests. This edit is OK, but there may be other problems. * “or processing is to be carried out under an Article 2 exemption” – the or is ambiguous * Chris to look at the sentence * “applicable” doesn’t always mean it’s only law enforcement – some jx may be able to request data subject to contract or treaty, there are also Rrs are set up in multiple countries * “or” could go after jurisdictions “or where processing is to be carried out under Article 2 * With either (i) local jx or (ii) confirmed article 2 exemption * Item 42 – Priority matrix should not be implementation guidance as there is text that is part of policy rec and part is implementation guidance. If the team agrees, which part should be in the policy language? (also relevant in the context of rec. 19 b/c anything that is the policy rec. cannot be changed except through a PDP) * If it’s moved into the policy rec., we would be locked in place * Policy rec could be such – initial rec is: [x] but this can be adjusted per the evolutionary model so it gives the flexibility that we intended to give. * Understanding is that at the very least the numbers in the third column were initial numbers that could be changed in implementation without changing the policy. * Item 43 – is this to be negotiations b/w ICANN org and CPs or are these policy requirements? * This may be tied to the Rec. 19 conversation. * When did the Team decide on one business day? * This is still an open question as to what business day means. * Recollection that we are still discussing business days. * Team to provide input by the next meeting. * In the Google docs, if groups want to provide input on the clarifying questions on what has been flagged, please add this to the Google doc. 1. Confirm next steps 5. Wrap and confirm next EPDP Team meeting (5 minutes): 1. Monday, 22 June at 14:00 UTC – Small Team for Rec. 19 2. Tuesday, 23 June at 14:00 UTC – continue run-through of yellow items 3. Confirm action items 1. Confirm questions for ICANN Org, if any

1 0

Updated recommendation #6 - Contracted Party Authorization posted for your review
by Marika Konings June 18, 2020

June 18, 2020

Dear EPDP Team, The staff support team had an action item to try and edit and reorganize recommendation #6 (Contracted Party Authorization) in line with the input that was provided during Wednesday’s meeting as well as input provided as part of the yellow items list. This has resulted in a significant overhaul which will hopefully simplify and clarify the requirements as well as the process steps expected to be followed. For ease of reading, we have posted a clean version for your review (see https://docs.google.com/document/d/1F0wmMEh6gopJVsDFDF5pe5mGAUHhr9CV/edit) – for those interested in seeing a redline version, please let us know off list (but note as a result of all the moving around, the whole recommendation basically shows up as redline). The main changes we made are: * Added introductory language to make clear that these requirements apply to disclosure requests that are sent to Contracted Party for review, not disclosure requests that are subject to recommendation 16/7 (automation); * Separated out general requirements and authorization determination requirements (steps to be taken). For the latter, we also tried to organize these in a more logical way; * Moved a number of the SHOULD items to the implementation guidance section to also allow for further updating in the future as new guidance may become available. As noted, due to the overhaul it will look completely different at first sight, but it should still include all the elements that groups have indicated as being important and necessary. Please review this updated recommendation by Monday 22 June and indicate if there are still any remaining ‘cannot live with’ items. Thanks, Caitlin, Berry and Marika

1 0

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

June 18, 2020

Dear all, All recordings for the GNSO Temp Spec gTLD RD EPDP – Phase 2 held on Thursday, 18 June 2020 at 14:00 UTC can be found on the agenda wiki page <https://community.icann.org/x/GgIdC> (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, 23 June 2020
by Terri Agnew June 18, 2020

June 18, 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, 23 June 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/fQgdC Check your time zone: https://tinyurl.com/y7sx435h 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 Phase 2 Meeting # - 17 June 2020
by Caitlin Tubergen June 17, 2020

June 17, 2020

Dear EPDP Team: Please find below the notes and action items from today’s EPDP Team meeting. As a reminder, the next meeting will be Thursday, 18 June at 14:00 UTC. Best regards, Marika, Berry, and Caitlin -- Action Items 1. After reviewing the Team’s progress today, Leadership suggests we start with item 35 tomorrow and review Rec. 6 during our meeting on Tuesday, 23 June. In the meantime, Support Staff to rewrite/reorganize Rec. 6 in line with today’s discussion. 2. Laureen to propose alternate wording to footnote 9, factoring in the different positions expressed during today's call. FN9: Compliance will not be in a position to address the merits of the request itself or the legal discretion of the Contracted Party making the determination. Proposal to delete the last clause (or the legal discretion of the CP making the determination). 3. Margie to draft footnote for Rec. 4 regarding NIS EU law. EPDP Phase 2 - Meeting #65 Proposed Agenda Wednesday 17 June 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. Continue run through of yellow items (items identified for further discussion / clarification) * Item 11 (Rec. 8) * Proposed deletion of this sentence: Information resulting from the alert mechanism is also expected to be included in the SSAD Implementation Status Report (see recommendation #19) to allow for further consideration of potential remedies to address abusive behavior. * Can this sentence be moved to the small team for Rec. 19? * Proposal to add this element in the suggested scope of MfE * RySG – suggestion was to delete this sentence entirely; however, proposed a compromise to, instead, add to the scope of Rec. 19. The small group should consider this. * The focus of the mechanism is on implementation aspects only. At the moment, the abuse provisions are part of the policy, so there may be a need to move these elements to implementation. The small team should consider this. * Footnote 9: ICANN Compliance will not be in a position to address the merits of the request itself or the legal discretion of the Contracted Party making the determination. Proposal to delete the last clause (or the legal discretion of the CP making the determination). Unclear what legal discretion means in this context. Additionally, if further guidance is received, ICANN Compliance may be in a position to review how the CP applied this determination. * The footnote should be kept as is * Believe ICANN Compliance expressed an unwillingness to do this * Do not understand why CPs have difficulties with the bracketed language to be discussed in the evolutionary model. Troubled why this section is problematic at this juncture when it has been there for quite some time. * Is there a way to rephrase this footnote – the legal discretion of the CP is not very helpful. Could contemplate scenarios where DPA guidance is received on how to apply the GDPR, whether it’s the balancing test or whether it’s in reference to other permissible lawful basis under Article 6. ICANN should be able to review if subsequent guidance is received. This language forecloses any role for ICANN Compliance to ensure CPs are abiding by the law. * Do not think it is ICANN Compliance’s role or remit to ensure CPs are complying with the law. Need to ensure that policy recs are flexible enough so that CPS can comply with the law. * ICANN Compliance does not interpret the law; ICANN Compliance defers to CPs to interpret the law. * This conversation supposes that every case involves a balancing test; this is not correct – some evaluations do not involve personal data * Confused if ICANN Compliance always grants a waiver if a CP believes it is following its local law – that does not seem correct. * There are paths where data that is not covered by the GDPR is involved; however, you need to see if there is a valid case for disclosure for any case. * Understand good CPs comply, but how do we deal with the bad CPs? The current language seems to give bad CPs a free pass. There is a CP that denies every request, irrespective of it’s a valid request. * Action: Laureen to come up with alternative language for the Team to consider. * Item 12: If a requestor is of the view that its request was denied in violation of the procedural requirements of this policy, a complaint MAY be filed with ICANN Compliance * Significant issue for BC. If there is a situation regarding systemic abuse, there needs to be a mechanism to deal with this. Need the ability to submit substantive requests. * This is a type of guarantee that cannot be given. Even if this language is erased, there is no guarantee that Compliance is going to do anything. You can only complain that CPs are violating the policy. * ICANN Compliance MUST make available an alert mechanism by which requestors as well as data subjects whose data has been disclosed can alert ICANN Compliance if they are of the view that disclosure or non-disclosure is the result of systemic abuse by a Contracted Party. This alert mechanism is not an appeal mechanism – to contest disclosure or non-disclosure affected parties are expected to use available dispute resolution mechanisms such as courts or Data Protection Authorities – but it should help inform ICANN Compliance of potential systemic abuse which should trigger appropriate action * This is not about guarantees; this is about forms of recourse. Being able to report on the number of alerts vs. number of requests will give us statistical guidance to assist in going forward. * This provision is not just meant to address systemic abuse. If there is a domain name with no personal data, ICANN Compliance should be able to enforce disclosure. * Cases where there is no personal data should not be denied; however, this is not a compliance issue – how would you even know if there is no personal data? * The issue is Compliance is not willing to look at the substance. * Item 13 - 14: awaiting GAC input on examples of urgent requests – GAC Team came back recently – no need to further illustrate the categories listed. * Question for the group – any concern with GAC-proposed approach? Adding definition of critical infrastructure? * Agree with GAC Proposal – leave four bullet points and reference the proposed definition in a footnote * Item 15: Remove “or in another standardized place that may be designated by ICANN from time to time.” * No objections – remove language. * Item 16: MAY reassign the priority level during the review of the request, in accordance with the requirements above. Would the EPDP team consider instead that a request that does not meet the requirements for Priority 1 or 2 may be rejected and may be refiled? * This would be an easier approach * However, would not be open to also allowing for a longer response time instead of dealing with the same request twice. * Idea of reassignment as part of evolution may be the right approach. * The steps outlined in the recommendation are logical and could be followed and imposed * Item 17: definition of Priority 2 requests - In Rec #NEW, Priority 2, can the EPDP team please clarify if this priority is intended to be available only to ICANN-approved dispute resolution service providers, or should it also be available to parties and potential parties in administrative proceedings? * This is limited to providers * Clarify this in the text * Item 18: In Rec #NEW, Priority 3 seems to contemplate a bifurcation within this priority level resulting in 4 priority levels. For implementation purposes, the system would require a fourth category, even if the contracted party were to choose to treat the two priority levels the same. Would it make more sense to create a fourth priority level to allow for this? * No need to create a new priority level. This language gives CPs the discretion to prioritize certain types of requests if CPs feel this is warranted * This is not a new priority level, this is a flag that could be put on a request * Leave as is * Item 19: In Rec #NEW, a. Abuse of urgent requests: For clarity during implementation, does the EPDP team contemplate any recommendations regarding abuse of the use of other priority levels? For example, what if a requester regularly incorrectly cites Priority 2, and those requests are downgraded. Would that be considered abuse? * If we limit the ability of Priority 2 requests to providers, this danger is negligible * No change necessary * Item 20: Rec. 4 * Either delete “Digital service provider (DSP)” or clarify what the intended purpose is. * Should not use these terms unless we define what we mean * Do not understand this as a requestor purpose * Keep digital service provider, add a footnote reference for NIS * How does this relate to a purpose for disclosure of registration data? * Purpose is fulfillment of a legal obligation * Even if there is a definition, that does not make it a purpose. Criminal investigation is a purpose; criminal law is not * Margie to draft footnote for Item 20 * Item 21: Unclear that the reference to Paragraph 9 is appropriate. If there is no personal data involved (and not otherwise prohibited by law), the requested data must be disclosed * The change in order has asked the disclosing party to process personal data where it doesn’t have a reason to do so at that stage. When CP gets a request, the CP has to perform a prima facie case to see if it’s a valid request. By changing 7 to number 1, it is creating a legal risk – process should revert back to how it was. * Phase 1 allowed information that is not subject to GDPR to be redacted. SSAD is the way to get access to data that doesn’t need to be redacted. If we can’t do this, we are weakening our ability to comply with GDPR but not over-comply with GDPR. * Couldn’t the CGM’s completeness and syntax check + accreditation allow for the basis to check the data? * This list should not be a step by step, so the order doesn’t really matter – just have to follow steps in a way the individual CP feels is appropriate * Still receive requests that state “give me the data b/c I have a trademark” – if that is the basis of the request, can’t look if there is personal data b/c do not believe that is an appropriate legal basis. * If the CP denies the request on some grounds unrelated to the fact that it is non-personal data when the data does not pertain to a natural person is unacceptable. * Just heard that a request could be rejected before it’s assessed if there is personal data or not * It is not just about what is lawful and what is not. A request can be rejected b/c it was filed improperly. If requestors submit the requests properly, this will not be an issue. * Offered a cure for the problem of legal v. natural – would involve a thorough validation of legal entities – some sort of accreditation that demonstrates existence a company that would be globally applicable * Consider adding – assuming the request is full and complete * Alan Woods to provide example text * Item 23: Delete “without reviewing the underlying data” * Moving step 7 up materially changes the recommendation. The threshold determination in 5 no longer makes sense. * These are steps that each CP must perform, but there is no requirement that they must be performed in this exact order. * Item 24: Can the EPDP team please explain what is the purpose of making a threshold determination? The paragraph used to require a Contracted Party to “make a threshold determination without reviewing the underlying data.” Paragraph 5a) no longer includes this language. Further, Paragraph 7 no longer indicates whether the registration data ought to be evaluated together with the request, rather it only requires the Contracted Party to “evaluate the request.” It is unclear how Paragraphs 5a) and 7 are distinct. Can the EPDP team please clarify? Paragraph 7: ICANN org notes that there do not appear to be any mandatory requirements specifying what it means to “evaluate the request.” Accordingly, ICANN Contractual Compliance would only be able to assess whether the CP has conducted “an evaluation”. Can the EPDP team please confirm there are no mandatory requirements specified for this evaluation? * First issue – if you delete “without reviewing underlying data” – confused about what the threshold determination is. What is the difference b/w this and evaluate? Thought steps were implied that go in a certain order. * Since legal v. natural will not be addressed in Phase 2, the language in the Final Report may need to change. 1. EPDP Team feedback 2. Confirm next steps 5. Wrap and confirm next EPDP Team meeting (5 minutes): 1. Thursday 18 June at 14.00 UTC. Topics to be addressed: continue run through of yellow items. 2. Confirm action items 1. Confirm questions for ICANN Org, if any

1 0

Post Call | GNSO Temp Spec gTLD RD EPDP – Phase 2 | Wednesday, 17 June 2020 at 14:00 UTC
by Terri Agnew June 17, 2020

June 17, 2020

Dear all, All recordings for the GNSO Temp Spec gTLD RD EPDP – Phase 2 held on Wednesday, 17 June 2020 at 14:00 UTC can be found on the agenda wiki page <https://community.icann.org/x/eQgdC> (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 | Thursday, 18 June 2020
by Terri Agnew June 17, 2020

June 17, 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 Thursday, 18 June 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/GgIdC Check your time zone: https://tinyurl.com/ycgp5zos 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