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

Notes and action items: EPDP Phase 2 Meeting #60 - 26 May 2020
by Caitlin Tubergen 26 May '20

26 May '20

Dear EPDP Team: Please find below the notes and action items from today’s meeting. The next EPDP Phase 2 meeting will be Thursday, 28 May at 14:00 UTC. Best regards, Marika, Berry, and Caitlin -- Action Items 1. EPDP Team members to review and provide input on the discussion table for Recommendation 15<https://docs.google.com/document/d/1e2kdKDoLH04OqNfZLJMd1qbDM07an2tZFs9rJOP…> (financial sustainability) and review the updated Recommendation 19<https://docs.google.com/document/d/1-npFkABPc-u3To6uYe2v6MTFHlrEOUD5i6x8LrH…> (evolutionary mechanism) and include “cannot live with items” in the chart within the document by COB Tuesday, 26 May. 2. EPDP Support Staff to update Recommendation 10, 12, 13, 14, and 17 based on the EPDP Team’s recent discussions and post the updated recommendations by Friday, 29 May. EPDP Phase 2 - Meeting #60 Proposed Agenda Tuesday 26 May 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) * As a result of the discussion during the last meeting, Janis sent questions to ICANN org re: ICANN’s interaction with the SSAD 4. Recommendation #13 Terms of Use (15 min) 1. Review discussion items gleaned from input provided on terms of use discussion table<https://docs.google.com/document/d/1sBVjsUf3JNQclGMpMS4PXBaffarVF5galoWxpVj…> * The Privacy Policy SHOULD or SHALL: * Could members that disagree with the use of SHOULD please speak up? Should seems to better reflect the way the group is moving in terms of flexibility * Should the group try and agree upon a minimum set of standards here and create a floor rather than a ceiling? If there is a SHOULD, it is not enforceable, which means it would have very little utility. * To address the earlier concern, these should be a requirement that is enforceable by ICANN. The flexibility is how this is interpreted by the contracted party. * This is in reference to the privacy policy with SSAD users – want to clarify that we are all talking about the same thing. * What privacy policy is this talking about? Is it how the SSAD will treat requestors’ data? * This seems like chapters of a privacy policy – all of these items have to be in there. * Should the follow bullets be added? Transparency requirements, Data security requirements, Accountability measures (privacy by design, by default, DPO above certain size, etc) * No objections. * Relevant data protection principles, for example * Delete the bullet point, but reword the intro sentence: The EPDP recommends, at a minimum, relevant data protection principles, for example: * Further consideration should be given during implementation whether updates to the RAA are necessary to ensure compliance with these recommendations. – Should this sentence be removed? * This is likely captured somewhere else. Registrars are required to notify data subjects about when their data is collected. This language is needed. * When the Team is finished, this policy will be amending the RAA, and someone should be going over the RAA with a fine-tooth comb. * Proposal is to remove this sentence from this rec and include it in a preamble somewhere else in the policy. * A consensus policy is incorporated into the RAA and RA by reference. * Caution the use of the word “amend” – while it would require modifications to the contract, the word amend is incorrect * “further consideration should be given in implementation” – this does not mean the IRT will draft amendments to the RAA and RA. This needs to be triggered by the CPs * This sentence should be deleted. * Based on this conversation, this sentence should be deleted. * Agree to keep “SHALL” and not have “SHOULD” * Change to from controllers to requestors * Is the last set of bullets required for Contracted Parties or requestors? * Believe this is for the SSAD as it relates to disclosures via the system * The agreement is with the SSAD and Contracted Parties should be at the table for this discussion. * The last four bullets are part of the overall terms of use of SSAD and will be applied as a blanket requirement to all requests after disclosure. 1. Confirm next steps 5. Recommendation #17 Logging (15 min) 1. Review discussion items gleaned from input provided on logging discussion table<https://docs.google.com/document/d/1YaHV2F49-9FpbmJdciCgkYeGCiwNNVTvfmqqnlP…> * What specific items should be logged be the CGM? * In the context of reporting requirements, there are requirements for reporting that needs to be reported upon. * With respect to the retention period should not say “as long as is necessary” – we should set a task that the retention period needs to be set in a concrete and transparent way for the data subject to know how long the data will be retained. * We need to be exceptionally careful as to what is in the logs. If the log has to be kept centrally, CPs will have an issue – a lot of liability will be added to who is holding the data. We need to be careful what additional liabilities we are creating here. We need to set realistic expectations of what we can achieve here. * It is sufficient to say: the logs will have no personal data. If you maintain an index of requestors, you don’t need to maintain personal data. Microsoft, for example, could be #999. If there is a ticketing system, you could work backwards from the ticket number. * Even if you use an index number, that could be considered private data if you could use the index number to trace back to an individual. (maybe use a hash that is not traced back to a specific requestor). * A hash number can be an index number. Privacy by design – the two tables you do not want joined have to be segregated. The segregation and prevention of easy joining is the concept of privacy by design. * Need to better understand who will be doing the auditing here – is it ICANN, the DPAs, the Contracted Parties? * Do not understand the reference to auditing here. * If there are six purposes for auditing and no agreement to how the data will be pseudonymized or anonymized – there needs to be more clarity around this. * The question is: for the moment, the CGM would perform logging regarding the query and the results of the query, including the status. Should the CGM also keep logs of the disclosure and nondisclosure and recommendations of the CGM. * If it’s OK with the group, will send a draft DPIA to the group. * Proposal to add three bullet points in the question to the logging of the CGM. * For question 2, it should be MAY. Logged data is not required in all circumstances all the time. * Some logged data must be disclosed under certain circumstances and other logged data will be available under other circumstances. For example, you do not need to see what the disclosure rates are to see if the system is functioning properly, but you may need to see it in other circumstances. * This applies the whole log must be disclosed, but we are only talking about specific entries. This should be a MAY b/c we do not mean that you are disclosing everything all the time. The AND should be changed to a BUT. Logged data will remain confidential BUT MAY be disclosed in the following circumstances. * We have where legally permissible sprinkled all of the way through these policy recommendations, which permits operators and jurisdictions that do not have data protection law to ignore things where a data protection authority or data protection law does not apply. and that can allow people to get out of compliance with the law. * Logged data is not shared by default, but it may be disclosed in very specific circumstances the team identified. * Logged data MUST remain confidential, BUT relevant logged data MUST be disclosed where legally permissible in the following circumstances: (first 3 bullet points). Relevant logged data must be disclosed for general technical operations to ensure proper running of the system. * There may be other circumstances where logged data can be disclosed – want to make sure this would not preclude ICANN org from publishing reports based on the logged data. * Not clear whether reporting recommendation overrides this – unless it is clear that reporting overrides this, we may need a fifth requirement here – the logs may be used in the reporting recommendation. * Do not understand why ICANN would need the rationale since this is about the procedure, not the decision itself. Not comfortable putting any decision-making in escrow. There is a lot of duplication here, and we should not be considering escrow – that is up to the individual controller. * Handing an edge case may not warrant putting this data in escrow. * This sentence can be deleted. * Suggest that “disclosure decision including written rationale must be stored” be kept and the rest of the sentence be deleted. * The issue of who bears the cost of audits is not something that needs to be further considered at this time – it is a necessary part of the SSAD. * “decisions” should be replaced by adherence to the process * The point seems to be that all CPs follow the same standardized approach * “structured” should be deleted from this bullet point, and support to keep commonly used machine readable format * Already addressed question 8 – if all personal info has been removed from logs, is there any issues here? The logged info would be used in the context of reporting. 1. Confirm next steps 6. Recommendation #18 Audits (15 min) 1. Review discussion items gleaned from input provided on audits discussion table<https://docs.google.com/document/d/14ctH4bAqrWTWK_XqnmvaFG7CnPcJdODQ5XaEwMw…> * Question 2 will be cross-checked once the new GAC version is completed * In the new version, there will be auditing of accredited governmental entities, but not by ICANN * Question 3: expense of auditing requirements should be considered further? If you have recommendations that auditing takes place, there may not be further need to elaborate on this. * Auditing is part of operational cost * There are already a number of auditing requirements that are included in the RA and the RAA – is it necessary to include these obligations in this, or only the auditing obligations that do not exist by data protection laws? * With respect to Question 4, prefer to leave as is and sort this out in implementation. 1. Confirm next steps 7. Implementation guidance I (15 min) 1. Review discussion items gleaned from input provided on implementation guidance i<https://docs.google.com/document/d/1C9Z4Rv-sdtYmGcUqOBG-3-XsvovXUAPQ0y6gbMY…> discussion table 2. Confirm next steps 8. Recommendation #15 Financial Sustainability (25 min) 1. Review discussion items gleaned from input provided on Financial Sustainability<https://docs.google.com/document/d/1e2kdKDoLH04OqNfZLJMd1qbDM07an2tZFs9rJOP…> discussion table 2. Confirm next steps 9. Recommendation #19 Evolution Mechanism (20 min) 1. Review follow-on draft of Evolution Mechanism<https://docs.google.com/document/d/1t_0pPy3ZQqOC-if91JfW5u80OIafHSKLpaMQguZ…> and Discussion Table<https://docs.google.com/document/d/1r3NBfZeGtQEdWZ89NkXJ8gWCJ0WOtCjuBoBqTHe…> as reference 2. Confirm next steps 10. Wrap and confirm next EPDP Team meeting (5 minutes): 1. Thursday 28 May at 14.00 UTC. Topic to be addressed: high level review of public comments received on the addendum. 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, 26 May 2020 at 14:00 UTC
by Terri Agnew 26 May '20

26 May '20

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

26 May '20

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, 28 May 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 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/6YLsBw Check your time zone: https://tinyurl.com/ybprrm94 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

Data flow diagrams for various SSAD systems
by Mark Svancarek (CELA) 26 May '20

26 May '20

As discussed on call today, here are some data flow diagrams for hypothetical SSAD designs. DPIAs to follow (ASAP when I finish them). Feedback welcomed. /marksv

1 0

Proposed agenda - EPDP Team Call #60 - 26 May 2020
by policy＠bacinblack.com 26 May '20

26 May '20

Dear EPDP Team: Please find below the proposed agenda for the next EPDP Team call on Tuesday, 26 May at 14:00 UTC. You may notice the agenda is ambitious, but you can think of this as the agenda for the full week. We will strive to work through item #7 so that we can devote the 28 May meeting to items #8, #9 and Addendum items. <<<< IMPORTANT NOTE >>>>> We thank the BC, IPC and RrSG for having started/completed their homework in preparation for Recs #13, #17, #18 and Implementation Guidance i. The Leadership team urges the other groups to complete their homework by CoB the 25th, or before hand since next Monday is a US holiday. Full input assists staff in development of the discussion item documents to help facilitate the calls. For the remaining items, all groups are encouraged to review through the discussion tables for RECs #15, #19 and the Addendum, all of which are posted on the wiki page, https://community.icann.org/x/Hi6JBw. Best regards, Marika, Berry, and Caitlin --EPDP Phase 2 - Meeting #60 Proposed Agenda Tuesday 26 May 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. Recommendation #13 Terms of Use (15 min) a. Review discussion items gleaned from input provided on terms of use discussion table <https://docs.google.com/document/d/1sBVjsUf3JNQclGMpMS4PXBaffarVF5galoWxpVj…> b. Confirm next steps 5. Recommendation #17 Logging (15 min) a. Review discussion items gleaned from input provided on logging discussion table <https://docs.google.com/document/d/1YaHV2F49-9FpbmJdciCgkYeGCiwNNVTvfmqqnlP…> b. Confirm next steps 6. Recommendation #18 Audits (15 min) a. Review discussion items gleaned from input provided on audits discussion table <https://docs.google.com/document/d/14ctH4bAqrWTWK_XqnmvaFG7CnPcJdODQ5XaEwMw…> b. Confirm next steps 7. Implementation guidance I (15 min) a. Review discussion items gleaned from input provided on implementation guidance i <https://docs.google.com/document/d/1C9Z4Rv-sdtYmGcUqOBG-3-XsvovXUAPQ0y6gbMY…> discussion table b. Confirm next steps 8. Recommendation #15 Financial Sustainability (25 min) a. Review discussion items gleaned from input provided on Financial Sustainability <https://docs.google.com/document/d/1e2kdKDoLH04OqNfZLJMd1qbDM07an2tZFs9rJOP…> discussion table b. Confirm next steps 9. Recommendation #19 Evolution Mechanism (20 min) a. Review follow-on draft of Evolution Mechanism <https://docs.google.com/document/d/1t_0pPy3ZQqOC-if91JfW5u80OIafHSKLpaMQguZ…> and Discussion Table <https://docs.google.com/document/d/1r3NBfZeGtQEdWZ89NkXJ8gWCJ0WOtCjuBoBqTHe…> as reference b. Confirm next steps 10. Wrap and confirm next EPDP Team meeting (5 minutes): a. Thursday 28 May at 14.00 UTC. Topic to be addressed: high level review of public comments received on the addendum. b. Confirm action items a. Confirm questions for ICANN Org, if any

2 2

*Reminder* Meeting Invitation / Observers / GNSO Temp Spec gTLD RD EPDP-P2 call / Tuesday, 26 May 2020
by Nathalie Peregrine 25 May '20

25 May '20

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, 26 May 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 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/qoYEC Check your time zone: https://tinyurl.com/yblorw58 [tinyurl.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__tinyurl.com_yblorw58&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

Notes and action items - EPDP Phase 2 Meeting #59 - Thursday, 21 May 2020
by Caitlin Tubergen 22 May '20

22 May '20

Dear EPDP Team: Please find below the notes and action items from EPDP Phase 2 Meeting #59 on Thursday, 21 May. Best regards, Marika, Berry, and Caitlin Action items 1. EPDP Team members who have not yet done so – please complete late homework by Monday, 25 May by 18:00 UTC: review and provide input on the discussion tables for Recommendation 17 [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_docume…> (logging), Recommendation 18 [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_docume…> (audits), and implementation guidance i[docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_docume…> (multiple requests). 2. EPDP Team members to review and provide input on the discussion table for Recommendation 15<https://docs.google.com/document/d/1e2kdKDoLH04OqNfZLJMd1qbDM07an2tZFs9rJOP…> (financial sustainability) and review the updated Recommendation 19<https://docs.google.com/document/d/1-npFkABPc-u3To6uYe2v6MTFHlrEOUD5i6x8LrH…> (evolutionary mechanism) and include “cannot live with items” in the chart within the document by COB Tuesday, 26 May. 3. Support Staff to update Recommendation 14 (retention), Recommendation 10 (Acceptable Use Policy) and Recommendation 12 (query policy) following the review of Recommendation 13 so that the recommendations may be considered together to avoid duplication. EPDP Phase 2 - Meeting #59 Proposed Agenda Thursday 21 May 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) * We plan to discuss Rec. 19 with Financial Sustainability on 26 or 28 May, depending on how we progress through the other recommendations * Re: automation – comment from EPDP Team Member – some members were under the impression that with few automated use cases, the Central Gateway would take the decision and instruct the CP to disclose. Others were under the impression that the CGM confirms the request meets the request for automated disclosure and sends to the CGM. Important to have a common understanding of this. 4. Recommendation #14 Data Retention (15 min) 1. Review discussion items<https://community.icann.org/download/attachments/126430750/Recommendation%2…> gleaned from input provided on Data Retention Discussion Table<https://docs.google.com/document/d/1k5w2BMWiPBzpj_HeghcaijX2F2SVd5JHjKgDKIG…> * Do we need to define abuse? Is this a one-time occurrence or multiple occurrences? * This has already been discussed extensively. * What does “this” mean? * Fine with specific text. Can we look at the audit recommendation. * Re: the question if CPs can audit the requestors? This is probably not practical. * No objections to bold language being added. * CPs auditing the requestor for retention of the data is unworkable in practice. It would be difficult to prove a negative here. Bolded language is acceptable. * If requestor who has received the data is not handling it according to GDPR, this requestor would be on the hook. Suggest adding suggested text. * What is the context for adding this in? That said, no objection. * The disclosing party would still be liable if they’re not in control of who they are disclosing the data to. Do not need permission from the SSAD to audit the data a controller discloses. If this is covered by the audit requirements, this does not need to be included. * Action item: Support Staff to verify what can be audited and if this is acceptable * Address this question by including data retention violation in a non-exhaustive list in Rec. 1 * Concerned that we are approving terms of use that permit CPs to audit the parties they disclose data to – this could be a big problem * Is ICANN Compliance OK with this? ICANN org liaisons need to speak with colleagues in Compliance on this. A written question would be helpful here. * ICANN would enforce compliance here * Review the recommendation in the entirety and see what it is about. If the requestor systematically violates the acceptable use policy, the question is – who could ban the requestor from using this. Is it ICANN org or Central gateway? * In terms of the role of ICANN compliance, it may just be on use of the SSAD itself. If violating is de-accreditation, then this is ICANN’s role as a data controller to limit use of the system it’s put in place. * It would be helpful to have a written question. Becoming increasingly uncomfortable of stretching ICANN’s mandate in an attempt to cobble this together. People have been clear about whether ICANN is staying within its mission – no one should assume that ICANN will do this. “ICANN will” is unlikely to come until the Board sees the full picture of the SSAD. * The question is relatively easy to answer. If the SSAD is within ICANN’s remit, then ensuring anyone using the SSAD is playing by the rules is also in ICANN’s remit. Highly likely that ICANN will engage a subtractor to work on its behalf. * This is about whether it’s in ICANN’s mission or not. * If the Team is thinking in the wrong direction, it would be helpful for the ICANN liaisons to steer the team in the right direction * This is a bit late in the process, as if the answer will be no, this would be a problem. * Is ICANN org willing to take on an additional task – now it’s framed much more broadly is that is this within ICANN’s mission to take on the additional task. Does the Board see issues with the policy recommendations? We do not want to end up with presenting this, passing it at the GNSO Council level only to find issues with the Board believing this is out of scope. * Working under assumption that ICANN will do many things. * Want to ensure that we test every assumption that ICANN will do something that is in its mission. If it is as simple as you can no longer have access to the system, that would be one thing – but is this also subject to re-consideration requests, et. al. * Had we sorted out the controllership arrangements, ICANN’s responsibility would be clear. An obligation under the GDPR is to not continue to accredit people who are violating the rules. * Action: Janis to pose relevant questions to ICANN org and share the message with the team. 1. Confirm next steps 5. Recommendation #10 Acceptable Use (15 min) 1. Review discussion items<https://community.icann.org/download/attachments/126430750/RECOMMENDATION%2…> gleaned from input provided on Acceptable Use Policy Discussion Table<https://docs.google.com/document/d/1h2179UY3KNoA3eIC1sdVR8G-GN_brLAN3h89r9f…> * CP should be able to trigger enforcement if they find the AUP has been violated * This should be triggered by ICANN compliance is the right place to do this * There is some overlapping – there are different and distinct items that serve different and distinct purposes * The acceptable use and terms of use are referring to two different things: one is for how users will use the SSAD system and the other is how requestors will use data once it is disclosed to them. * Wondering if to drive the point home about what the Acceptable Use Policy vs. the Terms of Use – would it be helpful to call this Terms and Conditions of using the SSAD * The CGM should just do a check that the requestor has agreed to the terms * This seems to be all the CGM could do in this case – a requestor would not be accredited if it doesn’t agree to the AUP * Not clear on what the new text means. The addition is already covered by b and e of this recommendation. Do not object to the addition but do not think it is necessary. Suggest this NOT be included. Note that we’ve covered elsewhere and move on. * Suggestion – leave the addition out and stick to the original text of the recommendation 1. Confirm next steps 6. Recommendation #12 Query Policy (15 min) 1. Review discussion items gleaned from input provided on query policy discussion table<https://docs.google.com/document/d/1IkLu_tfMCayjjeXZLpivgXL5G2dtCepv440YpVT…> * Comments about assumptions and takeaways – there are a number of items that are said to be addressed in implementation. Ask that where we expect things to be addressed in implementation – we state that in the recommendation. This would be helpful for the implementation phase. * Question 1 will be further described in implementation * Thought the whole idea of not addressing historic data was agreed – this should not be included. While the presumption is accurate, the EPDP Team does not need to report on this in its recommendations. * This text is confusing and contradicts the main principle * Agree to NOT include this text * Each request should be examined on its own merits * Consider on its own merits may predate that the CGM is now doing this – this is for the CP to do * Do not agree with the removal of this * If the gateway cannot review requests on its merits, it can’t perform any recommendations * Much easier if we’re looking at a flowchart of how the SSAD will work * If you have 1000 identical requests from the same requestor, you would not give 1000 similar answers in one click, you would have to go through each request individually. * Ultimately, if there is a centralized version of disclosure, this principle may come into play, so this should be referenced. * Action item: Support Staff to review “examine on the merits” and make sure these are consistent with each other * Here, the idea was in case of many similar requests, each request should be examined individually by a computer 1. Confirm next steps 7. Recommendation #13 Terms of Use (15 min) 1. Review discussion items gleaned from input provided on terms of use discussion table<https://docs.google.com/document/d/1sBVjsUf3JNQclGMpMS4PXBaffarVF5galoWxpVj…> * SSAD users = requestors * The concept that we’re trying to address is there should be input from users and requestors before the contracts are published. This should be similar to how the RAA was negotiated – in other words, there is input from others before the negotiation begins. * In terms of SSAD privacy policy, what was suggested makes sense. * Concerned with dropping the word “requestor” – there may be accredited users who are habitual users and everyone else is not accredited. 1. Confirm next steps 8. Recommendation #17 Logging (15 min) 1. Review discussion items gleaned from input provided on logging discussion table<https://docs.google.com/document/d/1YaHV2F49-9FpbmJdciCgkYeGCiwNNVTvfmqqnlP…> 2. Confirm next steps 9. Recommendation #18 Audits (15 min) 1. Review discussion items gleaned from input provided on audits discussion table<https://docs.google.com/document/d/14ctH4bAqrWTWK_XqnmvaFG7CnPcJdODQ5XaEwMw…> 2. Confirm next steps 10. Implementation guidance I (15 min) 1. Review discussion items gleaned from input provided on implementation guidance i<https://docs.google.com/document/d/1C9Z4Rv-sdtYmGcUqOBG-3-XsvovXUAPQ0y6gbMY…> discussion table 2. Confirm next steps 11. Wrap and confirm next EPDP Team meeting (5 minutes): 1. Tuesday 26 May at 14.00 UTC. Topic to be addressed: financial sustainability, high level review of public comments received on the addendum. 2. Confirm action items 1. Confirm questions for ICANN Org, if any

1 0

Post Call | GNSO Temp Spec gTLD RD EPDP – Phase 2 | Thursday, 21 May 2020 at 14:00 UTC
by Terri Agnew 21 May '20

21 May '20

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

21 May '20

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, 26 May 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 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/qoYEC Check your time zone: https://tinyurl.com/yblorw58 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

Discussion items for recommendation 12 and 13
by Caitlin Tubergen 20 May '20

20 May '20

Dear EPDP Team: In preparation for tomorrow’s call, please find attached the discussion items for Recommendation 12 (Query Policy) and Recommendation 13 (Terms of Use). Please note these documents are also posted on the EPDP Team wiki page<https://community.icann.org/pages/viewpage.action?pageId=126430750>. Best regards, Marika, Berry, and Caitlin

1 0