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

Post Call | EPDP-P2 small group call to discuss recommendation 16/7 updates | Monday, 22 June 2020 at 16:00 UTC
by Terri Agnew June 22, 2020

June 22, 2020

Dear all, All recordings for the EPDP-P2 small group call to discuss recommendation 16/7 updates held on Monday, 22 June 2020 at 16:00 UTC can be found on the agenda wiki page <https://community.icann.org/x/NIRIC> . 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) As a reminder only members and alternates can join the call, observers can listen to the recordings and read the zoom transcript afterwards. 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

Post Call | GNSO Temp Spec gTLD RD EPDP – Phase 2 - Small Team | Monday, 22 June 2020 at 14:00 UTC
by Terri Agnew June 22, 2020

June 22, 2020

Dear all, All recordings for the GNSO Temp Spec gTLD RD EPDP – Phase 2 – Small Team held on Monday, 22 June 2020 at 14:00 UTC can be found on the agenda wiki page <https://community.icann.org/x/s4FIC> . 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) As a reminder only members and alternates can join the call, observers can listen to the recordings and read the zoom transcript afterwards. 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

**Reminder** Meeting Invitation | Observers | GNSO Temp Spec gTLD RD EPDP-P2 call | Tuesday, 23 June 2020
by Julie Bisland June 22, 2020

June 22, 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 [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/fQgdC Check your time zone: https://tinyurl.com/y7sx435h [tinyurl.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__tinyurl.com_y7sx435h&d…> 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

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