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

GAC input on Rec. 8
by Kapin, Laureen June 17, 2020

June 17, 2020

Hi folks, Apologies for the late submission of input: We missed reporting a "cannot live with" item on Rec#8 footnote 9 The last sentence of that footnote reads: "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" We would like to delete the end of the sentence after "merits of the request." Rationale: * It is unnecessary as guidance provided immediately prior includes how the contracted party applied the balancing test if applicable. * It is unclear what "legal discretion" means in this context. * With DPA guidance, there may be more clarity on how to weigh disclosure decisions and ICANN Compliance may be able to identify and provide guidance on flawed decision making in the future. Thank you Kind regards, Laureen Kapin Counsel for International Consumer Protection Federal Trade Commission (202) 326-3237

1 0

Updated yellow items list for today's EPDP Team meeting (Wednesday 17 June at 14.00 UTC)
by Marika Konings June 17, 2020

June 17, 2020

Dear EPDP Team, In preparation for today’s EPDP Team meeting, please find attached the updated ‘yellow items’ list which now includes a brief summary of the agreement reached on the items covered during yesterday’s meeting as well as a couple of additional items that were added by groups to the input review templates for items not covered yet (see https://community.icann.org/x/K4LsBw) We’ll continue review of the flagged items during today’s meeting starting at item #11. Best regards, Caitlin, Berry and Marika

2 1

Recordings GNSO Pre-ICANN68 Webinar 12:00 UTC 17 June 2020
by Nathalie Peregrine June 17, 2020

June 17, 2020

Dear all, Please find below the Zoom room recordings of the GNSO Pre-ICANN68 webinar 17 June 2020 12:00 UTC: Zoom recording: https://icann.zoom.us/rec/play/6ZMsd735pzw3SIWUsgSDBfZ7W468K_is1yIc-KJZmk-y… Zoom audio: https://icann.zoom.us/rec/play/751_cLiqrzo3HoaRsASDAvJ9W9S4KKys1SgfqPoEzhm9… Zoom chat: https://icann.zoom.us/rec/sdownload/vZd_ce6u_283GNySuASDBf4sW461LP2shndP-vQ… Thank you, Nathalie

1 0

New Zoom room link GNSO Pre-ICANN68 Webinar 12:00 UTC 17 June 2020
by Nathalie Peregrine June 17, 2020

June 17, 2020

Dear all, Please note there is a new Zoom room link for the GNSO Pre-ICANN68 webinar on at 12:00 UTC today, 17 June 2020. Zoom link: https://icann.zoom.us/j/99346771120?pwd=dFlFYW82NGF0eXRaVmZJYUFZeTdBUT09 Thank you! Nathalie Nathalie Peregrine Manager, Operations Support (GNSO) Internet Corporation for Assigned Names and Numbers (ICANN) Skype: nathalie.peregrine.icann 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

For your review: Updated Rec. 2 available
by Caitlin Tubergen June 16, 2020

June 16, 2020

Dear EPDP Team: This is a note to inform you that GAC colleagues have provided an updated version of Recommendation 2 (accreditation of governmental entities), and it is now included in the Recommendation 2 review template<https://drive.google.com/file/d/127RbEGY3hlClG6vUG-i5H77LmfOXR9E5/view?usp=…>. Please review the updated version and flag any “cannot live with” items at the latest by COB tomorrow, Wednesday, 17 June. Thank you. Best regards, Marika, Berry, and Caitlin

1 0

Notes and action items - EPDP Phase 2 Meeting #64 - 16 June 2020
by Caitlin Tubergen June 16, 2020

June 16, 2020

Dear EPDP Team: Please find below the notes and action items from today’s EPDP Team meeting. The next EPDP Team meeting will be tomorrow, 17 June at 14:00 UTC. Best regards, Marika, Caitlin, and Berry -- Action Items 1. For those EPDP Team Members who have not completed homework item below, please complete ASAP today: EPDP Team to carefully review all recommendation review templates<https://community.icann.org/display/EOTSFGRD/g.+Draft+Final+Report+-+Phase+2> and indicate: * any “cannot live with items” with an accompanying rationale and proposed edited text by COB Monday, 15 June. Please provide text in the table at the top of the template and be sure to include the item number. * Incorrect assumptions by the Staff Support Team * Further clarifications for items highlighted in yellow and blue. 1. Support Staff to update the draft Final Report in line with today's discussion. 2. EPDP Team to confirm whether there are other provisions, in addition to 1.4d, that should be referenced in 1.7(b). 3. RySG to review the clauses from Item 4 (1.2c and 1.3e) offline and respond to the questions from ICANN org. EPDP Phase 2 - Meeting #64 Proposed Agenda Tuesday 16 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) * Small Group met yesterday and discussed the scope of the mechanism. There appears to be an understanding on four out of five items, but the group is still discussing the scope of automation. * The second discussion point is the method of the mechanism – how it would be formulated and who would be responsible for reviewing. * The group is currently split according to party lines. 4. Commence run through of yellow items (items identified for further discussion / clarification) 1. Consider yellow items identified for recommendations (commencing with rec #1 and moving down the list) * The document on screen has been circulated; the document includes items Staff Support had already flagged as well as the additional items that had been flagged by the groups. * Some groups may not have gone through all of the recommendations yet. Please flag in the chat which recommendations are still outstanding by your group. * The homework we asked the groups to do – identify what items they could not live with or minor edits. * Staff, with leadership, worked together to propose a path forward for each item. Items flagged as yellow is where further information is sought, or we thought it may create a cannot live with item for other groups. * For each recommendation, we included a separate table, groups were asked to review the tables and flag “cannot live with” items * This list is a compilation of yellow items as well as items that groups flagged as saying this has created an issue for us. * Every group was asked to review the approach and flag “cannot live with” items * NCSG may want to check that input was provided in all recommendations * Item 1 – 1.7 of Rec. 1: * ICANN org – 1.7(a) – this seems to be redundant to Recs. 10-13-14 – would EPDP Team consider referencing those recommendations to provide greater clarity and avoid duplication? * For RySG, not OK with just removing this. In comparing this with Recs. 10-13-14, it does not seem to overlap. Split on whether it’s better to leave where it is or move to Recs. 10-13-14, but agree that it should not be deleted. * At worst, it’s redundant. At best, it’s makes the recommendation clearer and includes items not included in Recs. 10-13-14 * It may be helpful to make clear what is not included in Recs. 10-13-14 so that this does not result in different terms and conditions for different users. * No change. Leave as is. * Item 2 – comment made by RySG, adding a parenthetical, noting that number of SSAD requests will not be restricted (except where…) * Agree to this in principle, but have it be limited to otherwise permitted under Rec. 1.4(d) * Already limited to as is permitted under the recommendations – this should be acceptable * If we are deleting the parenthetical, NCSG does not agree. * BC: if the policy language is “search through the entire document and find places where it might conflict”, do not agree. * NCSG: willingness to trust Staff to go through this and discuss changes is quickly waning – putting rate limitations is reasonable here. * There may be some unresolved systemic issues, and the minor details that we are spending time on may not be the best way to spend the teleconference. * Either Staff or we have to go through the recommendations to see what is not covered under 1.4 * Suggest keeping language as suggested by BC. * or where they may be otherwise permitted under recommendation 1.4(d). * Suggestion to replace “or where they may otherwise permitted under these recommendations” with “where they may be otherwise permitted under recommendation 1.4(d)” * Staff to mark this and review the policy to determine what, if anything, also needs to be included * The problem is not what is in the parenthetical but what comes before that, but the way the current language reads, it includes what is in 1.4(d) – do not understand why this needs to be replaced. * The list should be in 1.4(d) – if not, it will get confusing in the IRT. * Action: EPDP Team to confirm there are no contradictions in the BC-proposed language * Item 3 – ALAC comment for the footnote – what does it mean that the verification will depend on the type of applicant? Having different levels of verification seems problematic. Suggest removing last sentence from FN 12. * Agreement to remove the sentence. * Item 4 – relates to two sentences – 1.2c and 1.3e that discuss a privacy policy. ICANN org – this seems to revisit language that was replaced in 1.2c – what is the difference b/w 1.2c and 1.3e – are they duplicative? * Having trouble seeing the conflict that is being flagged. The existing language deals with a privacy policy, while the suggested addition deals with terms of service for the accredited entity. What is the conflict b/w these two different provisions? * 1.2c and 1.3e do seem duplicative, but they are not the same as the comment from RySG. * If you scroll down on the righthand document – the issue is that the language in 1.2c was replaced to clarify what a specific privacy policy. In 1.3e, there is a reference to terms of service, suggest updating 1.2c to cover the privacy policy and the terms of service. * Question to RySG – should this say terms of service? * If the Accreditation Authority is a processor, they will not be developing a privacy policy. Uncomfortable with this specific privacy policy that they’re free to develop. * Action: RySG to review the clauses from Item 4 offline and respond to the list following this call. * Item 5 (Rec. 3) * MUST include all information necessary for a disclosure decision – question from ICANN org – to clarify for implementation purposes – could a request refer to a signed assertion which may provide all information in b, c, d * RrSG, IPC – yes, this may refer to a signed assertion * No additional input provided * Item 5 (Rec. 5) * Differences of understanding when information is relayed to CPs. What, if anything, is relayed to the CP when it concerns a request that meets the criteria for an automated disclosure decision? Staff’s understanding is that the disclosure request would still be provided to the CP for its records. This relay could be provided at the same as the CP is asked to disclose or at another time. * RrSG: expressed support for Staff’s understanding * IPC: do not agree with understanding, as for automated disclosure, CPs do not need the information, and having the information could open the CP to more liability * ALAC: information should not go to the CP * RySG: leave language as is * IPC: for decisions that are centralized and/or automated, those are decisions that the CP does not have liability for the disclosure. For those requests, the liability will be centralized, and the CGM will be deciding on the request. In this world, it is unclear why the CP would want to expose itself to more liability by getting the information. * Working under an assumption that there is no liability for CPs under certain use cases, but we do not know if this is accurate or not. Do not see how providing the data to CPs increases the CPs liability. Assume that CP involved would want records on the disclosure request. * The CGM does not have the data, it will have to go to CP. Everyone should reread the memo from B&B, where it provides that there would be less liability but not no liability. CPs needs to have information on when data was disclosed and for which reason to fulfill legal obligations. * When a request is filed, the CGM determines whether the request is eligible for an automated response or not. If not, an acknowledgment of receipt is sent to the requestor, and the request is sent to the CP. If the request falls in the scope of automated decisions, then the CGM sends the CP the request and an indication that it falls in the scope of automated decisions. * What will be key to CPs not having the joint and several liability under the micro approach is that they’re not involved in the same processing. * When we discussed how the data should travel, the following principle of data minimization, we decided that CPS will send the data directly to the requestor, so that is why the proposal that CGM does not make automated decision maker but just indicates to CP that request falls within scope of automated decision making. Then computer of CP gathers data and sends it in a secure way to the requestor. This is what is currently in the recommendations, and we should stick to it. * The group is conflating a bunch of issues in the B&B memo. It identified a small number of places where automated processing is permitted (either because the data is not personal, or because the Cps review a recommendations, etc. I don’t think it ever said that the Cps were not potential controllers in all of those scenarios. The point is, that the memo was about permissible automation - where the data is not personal or where the decision making is not automated. * Propose leaving the recommendation as is. * Item 7 – Footnote 23 is currently worded as implementation guidance, but IPC believes it should become part of the policy recommendation. * Footnote 23 reads better as implementation guidance. * We are discussing Footnote 23 – suggestion to move that as a policy recommendation – did not apply this b/c Staff Support was not sure there would be agreement to do this. Is there a concern re: moving this to the policy portion, or is the Team comfortable leaving it in implementation guidance. * Concerned with “it may be provided at another point”. * The explicit statement saying “provided at another time” – have a problem with. * In moving the implementation guidance up, the policy would benefit from clarity. * Recommend keeping the footnote as is with the implementation guidance footnote and move on. * Afraid that this language conflicts with the recommendation for automation. This is silent as to the most important use case for processing. Cannot live for this without a carve out for cases that are automated. * Rec. 5 is lacking “for requests that are not automated,” the CGM must relay the disclosure request to the registrar. * CGM does not possess registration data. When the request comes in, all CGM does is if the request should be reviewed manually or should be reviewed in an automated way. * One issue is the reference is registrar of record – this is something that Staff overlooked – we could change this to the CP instead of registrar of record. This purely speaks about relay of the disclosure request – understand that it needs to be relayed in both instances. * Maintain language of Rec. 5 as shown on the screen and do not change the footnote. * Item 8: bullet e – if the CP determines disclosure…CP must document rationale and communicate to requestor and CP. Question – does the rationale only need to be communicated to ICANN Compliance if requested? * Agree with Rr input, but wondering if ICANN org has something else in mind? * No, ICANN org did not have an alternative in mind. Is the “if requested” only ICANN Compliance or also the requestor? * If requested refers only to ICANN Compliance. Consider moving the (if requested) to before ICANN Compliance * Items 9 – 10 * Relay of request by default to RoR but identify circumstances where it would also go to the Ry. Some believe it should be at the requestor’s discretion to choose Rr or Ry. Outlined some scenarios for when the request may be relayed to the registry. Specific examples included caused issues with the CPs. * Thought that we had agreed on a hybrid model where requests are sent to a centralized point. The idea that the CGM can issue recommendations is one of the workable halfway houses b/w people who are not OK with a decision made by the CP. * The idea behind making the recommendation – if we were to have a mechanism to evolve this, knowing the CGM had already got the decision right and agreed with the CPs would make for an easier evolution. * Records of disclosure request have to go to the Rr as well, even if the request is being processed by the Ry. * The CGM still makes the determination, but there has to be a fallback – some Rrs may not have an SSAD connection. How the CGM makes the determination can be left to implementation. * Can live with text displayed on the screen. 1. EPDP Team feedback 2. Confirm next steps 5. Wrap and confirm next EPDP Team meeting (5 minutes): 1. Wednesday 17 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 | Tuesday, 16 June 2020 at 14:00 UTC
by Terri Agnew June 16, 2020

June 16, 2020

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

June 16, 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 Wednesday, 17 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/eQgdC Check your time zone: https://tinyurl.com/ycydcv9z 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

Re: [Gnso-epdp-team] Proposed Agenda - EPDP Team Meeting #64 - Tuesday 16 June at 14.00 UTC
by Marika Konings June 16, 2020

June 16, 2020

Dear All, Please find attached the document that will be used for agenda item #4 which compiles all the yellow items that were originally flagged for further discussion as well as additional items that were flagged by the different groups in the input review templates to date (see 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 Marika Konings <marika.konings(a)icann.org> Date: Monday, June 15, 2020 at 17:42 To: "gnso-epdp-team(a)icann.org" <gnso-epdp-team(a)icann.org> Subject: [Gnso-epdp-team] Proposed Agenda - EPDP Team Meeting #64 - Tuesday 16 June at 14.00 UTC Dear EPDP Team, Please find below the proposed agenda for the next EPDP Team meeting which is scheduled for Tuesday 16 June at 14.00 UTC. As a reminder: 1. EPDP Team to carefully review all recommendation review templates<https://community.icann.org/display/EOTSFGRD/g.+Draft+Final+Report+-+Phase+2> and indicate: * any “cannot live with items” with an accompanying rationale and proposed edited text by COB Monday, 15 June. Please provide text in the table at the top of the template and be sure to include the item number. * Incorrect assumptions by the Staff Support Team * Further clarifications for items highlighted in yellow and blue. 2. EPDP Team to carefully review the Leadership proposal for Priority 2 items<https://docs.google.com/document/d/1PMZLtUUTFxS-c0C6e3ioPWxoyfGwDmus/edit> and indicate if your group cannot live with the proposed path forward by Monday, 15 June. If there is not sufficient support for the proposed path forward, the topic will not be included in the SSAD Final Report and further consultation will take place with the GNSO Council if/how the priority 2 topic is expected to be addressed. Best regards, Caitlin, Berry and Marika EPDP Phase 2 - Meeting #64 Proposed Agenda Tuesday 16 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. Commence run through of yellow items (items identified for further discussion / clarification) 1. Consider yellow items identified for recommendations (commencing with rec #1 and moving down the list) 2. EPDP Team feedback 3. Confirm next steps 5. Wrap and confirm next EPDP Team meeting (5 minutes): 1. Wednesday 17 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

Proposed Agenda - EPDP Team Meeting #64 - Tuesday 16 June at 14.00 UTC
by Marika Konings June 15, 2020

June 15, 2020

Dear EPDP Team, Please find below the proposed agenda for the next EPDP Team meeting which is scheduled for Tuesday 16 June at 14.00 UTC. As a reminder: 1. EPDP Team to carefully review all recommendation review templates<https://community.icann.org/display/EOTSFGRD/g.+Draft+Final+Report+-+Phase+2> and indicate: * any “cannot live with items” with an accompanying rationale and proposed edited text by COB Monday, 15 June. Please provide text in the table at the top of the template and be sure to include the item number. * Incorrect assumptions by the Staff Support Team * Further clarifications for items highlighted in yellow and blue. 2. EPDP Team to carefully review the Leadership proposal for Priority 2 items<https://docs.google.com/document/d/1PMZLtUUTFxS-c0C6e3ioPWxoyfGwDmus/edit> and indicate if your group cannot live with the proposed path forward by Monday, 15 June. If there is not sufficient support for the proposed path forward, the topic will not be included in the SSAD Final Report and further consultation will take place with the GNSO Council if/how the priority 2 topic is expected to be addressed. Best regards, Caitlin, Berry and Marika EPDP Phase 2 - Meeting #64 Proposed Agenda Tuesday 16 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. Commence run through of yellow items (items identified for further discussion / clarification) 1. Consider yellow items identified for recommendations (commencing with rec #1 and moving down the list) 2. EPDP Team feedback 3. Confirm next steps 5. Wrap and confirm next EPDP Team meeting (5 minutes): 1. Wednesday 17 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