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

Proposed Agenda - EPDP Team Meeting #71 - Thursday 2 July at 14.00 UTC
by Marika Konings July 1, 2020

July 1, 2020

Dear EPDP Team, Please find below the proposed agenda for the next EPDP Team meeting which has been scheduled for Thursday 2 July at 14.00 UTC. As a reminder, the meeting has been extended to 4 hours plus a 30 min break to allow for sufficient time to address outstanding issues. You are encouraged to review the relevant google docs under agenda item #4 and #5 and provide your input ahead of the meeting which may facilitate resolving outstanding issues. Best regards, Caitlin, Berry and Marika EPDP Phase 2 - Meeting #71 Proposed Agenda Thursday 2 July 2020 at 14.00 UTC 1. Roll Call & SOI Updates (5 minutes) 2. Confirmation of agenda (Chair) 3. Welcome and housekeeping issues (Chair) (5 minutes) 4. Consider outstanding items / questions in relation to recommendation 7/16 (automation)<https://docs.google.com/document/d/1dlOhPn5djTVLFBw7TROID0rWKgGIRhrr/edit> 1. Review outstanding items / questions 2. EPDP Team Feedback 3. Confirm next steps 5. Continue run through of yellow items<https://docs.google.com/document/d/10IQOJDwEpHj5meIb4P8JAIW2qb2A0oVp/edit> (items identified for further discussion / clarification) 1. Consider yellow items identified for recommendations (continuing with rec #15 and moving down the list) 2. EPDP Team feedback 3. Confirm next steps 6. Wrap and confirm next steps (5 minutes): * 5 July: distribution of updated draft Final Report. * 6 - 10 July: silent week – opportunity for EPDP Team to review draft Final Report and flag any minor edits (no reopening of previously discussed & addressed issues). * 14 July: tentative EPDP Team meeting to address any issues that may require EPDP Team input / guidance. * 17 July: distribution of Final Report and consensus designations. As a reminder, the Chair will make an evaluation of the support achieved for the recommendations and publish its designation for the group to review. * 20 - 24 July: opportunity for EPDP Team to respond to consensus designations, review by Chair of input received, if any, confirmation by Chair of designation. * 24 July: deadline for minority statements. * At the latest by 31 July: submission of Final Report to the GNSO Council

1 0

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

July 1, 2020

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

July 1, 2020

As a result of various requests to facilitate observers to follow the EPDP Phase 2 deliberations in real time, zoom webinar room will be made available for the EPDP plenary meetings. As a reminder, the zoom recording, audio recording, chat transcript and transcript of the EPDP plenary meetings will be publicly posted as soon as available on the EPDP wiki page and GNSO master calendar. Dear all, The next meeting of the GNSO Temp Spec gTLD RD EPDP – Phase 2 is scheduled on Thursday, 02 July 2020 at 14:00 UTC for 4.5 hours. (2 hours, ½ hour break, then 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/IoNIC Check your time zone: https://tinyurl.com/ycoejsyu 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

Recommendation #6
by King, Brian July 1, 2020

July 1, 2020

Hello EPDP Colleagues, Apologies that I had to leave the call about 15 minutes early today. I was confused and disappointed to read in the recap that after I left the call that some folks wanted to strike the Rec 6 language which previously prohibited CPs from denying requests solely because they pertain to intellectual property content on a website. Please help me understand: why do CPs need to have the ability to deny requests solely because the complained activity is occurring on a website? Insisting on the need to deny requests on this basis alone has very bad optics, especially when CPs already have broad discretion to deny requests based on a subjective balancing test, which Compliance has committed not to second-guess, and when this has already been agreed in the Privacy/Proxy policy. This may very likely be a “hill to die on” for the IPC. I should note that replacing “denied” with some form of “disposition” language was not agreed previously and is not acceptable to the IPC. It should go without saying that we cannot agree to remove IP from the list of categories for which CPs may otherwise automate at their voluntary discretion. I would be surprised if CPs wanted to limit their own flexibility in this regard either. To be clear, we are not trying to expand ICANN’s remit to include policing website content, nor are we saying that IP-related requests must be approved, nor are we asking CPs to suspend or delete domain names based on content. We are merely attempting to reflect the language that was agreed in the Privacy/Proxy policy, and which addresses a huge problem for our Constituency – that far too frequently IP requests are swept aside as “IP = UDRP needed = case closed.” While we are happy to engage in more substantive debate about that separately in the DNS Abuse context, this is a very different conversation. In this conversation, we cannot accept an outcome that allows denial of access to the data needed for self-help solely because the substantive issue is IP-related. It is true that the web host is often not the same entity as the registrar, and the web host is often better suited to address content-related issues. When addressing content issue enforcement, IP owners should go to the web host. However, when domain names are used in connection with content on a website and IP owners need RDS data to enforce IP rights with the domain name registrant, this is within ICANN’s remit. We agreed on this language during our face-to-face meeting in January, and it stood for months thereafter. Given its benign impact on CPs and its overwhelming importance to the IPC, I can’t understand how or why the IPC is expected to agree to remove it now. Please, let’s put this back, put it aside, and focus our work on coming to consensus on real issues. Brian J. King Director of Internet Policy and Industry Affairs, IP Group T +1 443 761 3726 clarivate.com [D39D107B] Confidentiality note: This e-mail may contain confidential information from Clarivate. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this e-mail is strictly prohibited. If you have received this e-mail in error, please delete this e-mail and notify the sender immediately.

2 2

Re: [Gnso-epdp-team] Proposed agenda - EPDP Team meeting #69 - Wednesday 1 July at 14.00 UTC
by Caitlin Tubergen June 30, 2020

June 30, 2020

Dear EPDP Team: Please find attached the outstanding issues and questions for Agenda Item #4 (Rec. 19). Thank you. Best regards, Marika, Berry, and Caitlin From: Gnso-epdp-team <gnso-epdp-team-bounces(a)icann.org> on behalf of Marika Konings <marika.konings(a)icann.org> Date: Tuesday, June 30, 2020 at 12:29 PM To: "gnso-epdp-team(a)icann.org" <gnso-epdp-team(a)icann.org> Subject: [Gnso-epdp-team] Proposed agenda - EPDP Team meeting #69 - Wednesday 1 July at 14.00 UTC Dear EPDP Team, Please find below the proposed agenda for the next EPDP Team meeting which is scheduled for Wednesday 1 July at 14.00 UTC. Please also note that an updated version of recommendation 7/16 (automation) has been posted for your review (see https://docs.google.com/document/d/1dlOhPn5djTVLFBw7TROID0rWKgGIRhrr/edit [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_docume…>). This is the version that the staff support team prepared after the last EPDP Team discussion on this topic (18/6) and which was provided to the small team (Brian, Matt and Sarah) as a starting point. However, the small team was not able to come to agreement on how to address some of the concerns identified by the small team, but the small team members have been encouraged to provide their perspectives and suggestions to the EPDP Team to help inform further deliberations on this recommendation. Best regards, Caitlin, Berry and Marika ============== EPDP Phase 2 - Meeting #69 Proposed Agenda Wednesday 1 July 2020 at 14.00 UTC 1. Roll Call & SOI Updates (5 minutes) 2. Confirmation of agenda (Chair) 3. Welcome and housekeeping issues (Chair) (5 minutes) 4. Consider outstanding items / questions in relation to recommendation #19 – Mechanism [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_docume…> 1. Review outstanding items / questions 2. EPDP Team Feedback 3. Confirm next steps 5. Continue run through of yellow items [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_docume…> (items identified for further discussion / clarification) 1. Consider yellow items identified for recommendations (continuing with rec #15 and moving down the list) 2. EPDP Team feedback 3. Confirm next steps 6. Consider outstanding items / questions in relation to recommendation 7/16 (automation) [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_docume…> 1. Review outstanding items / questions 2. EPDP Team Feedback 3. Confirm next steps 7. Wrap and confirm next EPDP Team meeting (5 minutes): 1. Thursday 2 July at 14.00 UTC. Topics to be addressed: Any remaining items. 2. Confirm action items 3. Confirm questions for ICANN Org, if any

1 0

Proposed agenda - EPDP Team meeting #69 - Wednesday 1 July at 14.00 UTC
by Marika Konings June 30, 2020

June 30, 2020

Dear EPDP Team, Please find below the proposed agenda for the next EPDP Team meeting which is scheduled for Wednesday 1 July at 14.00 UTC. Please also note that an updated version of recommendation 7/16 (automation) has been posted for your review (see https://docs.google.com/document/d/1dlOhPn5djTVLFBw7TROID0rWKgGIRhrr/edit) This is the version that the staff support team prepared after the last EPDP Team discussion on this topic (18/6) and which was provided to the small team (Brian, Matt and Sarah) as a starting point. However, the small team was not able to come to agreement on how to address some of the concerns identified by the small team, but the small team members have been encouraged to provide their perspectives and suggestions to the EPDP Team to help inform further deliberations on this recommendation. Best regards, Caitlin, Berry and Marika ============== EPDP Phase 2 - Meeting #69 Proposed Agenda Wednesday 1 July 2020 at 14.00 UTC 1. Roll Call & SOI Updates (5 minutes) 2. Confirmation of agenda (Chair) 3. Welcome and housekeeping issues (Chair) (5 minutes) 4. Consider outstanding items / questions in relation to recommendation #19 – Mechanism<https://docs.google.com/document/d/17gGzz6K-zKuSK71FluHCowZo3p6tFEd3/edit> 1. Review outstanding items / questions 2. EPDP Team Feedback 3. Confirm next steps 5. Continue run through of yellow items<https://docs.google.com/document/d/10IQOJDwEpHj5meIb4P8JAIW2qb2A0oVp/edit> (items identified for further discussion / clarification) 1. Consider yellow items identified for recommendations (continuing with rec #15 and moving down the list) 2. EPDP Team feedback 3. Confirm next steps 6. Consider outstanding items / questions in relation to recommendation 7/16 (automation)<https://docs.google.com/document/d/1dlOhPn5djTVLFBw7TROID0rWKgGIRhrr/edit> 1. Review outstanding items / questions 2. EPDP Team Feedback 3. Confirm next steps 7. Wrap and confirm next EPDP Team meeting (5 minutes): 1. Thursday 2 July at 14.00 UTC. Topics to be addressed: Any remaining items. 2. Confirm action items 3. Confirm questions for ICANN Org, if any

1 0

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

June 30, 2020

Dear EPDP Team: Please find below the notes and action items from today’s meeting. Our next meeting will be tomorrow, Wednesday, 1 July at 14:00 UTC. Thank you. Best regards, Marika, Berry, and Caitlin Action Items 1. As noted during today's call, for any flagged issues that were deemed non-substantive or were of a clarifying nature, the Staff Support Team suggested a proposed approach / clarification for your review (in bold), based on deliberations to date and/or feedback that has been provided by team members. (Please see attached document.) If this has resulted in any ‘CANNOT LIVE WITH’ items, EPDP Team members to flag this by the end of today (Tuesday, 30 June) so that these can be further considered. For any items flagged as CANNOT LIVE WITH, please provide both an accompanying rationale for why this is a ‘cannot live with’ item and specific suggestions for how the concern can be addressed. EPDP Phase 2 - Meeting #68 Proposed Agenda Tuesday 30 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. Proposed timeline for next steps: Leadership counted back from 31 July to plan out the remaining schedule detailed below * 30 June / 1-2 July: finalize review of outstanding cannot live with items, rec #6 (CP Authorization), rec #7/16 (automation) and rec #19 (mechanism). * 5 July: distribution of updated draft Final Report. * 6 - 10 July: silent week – opportunity for EPDP Team to review draft Final Report and flag any minor edits (no reopening of previously discussed & addressed issues). * 14 July: tentative EPDP Team meeting to address any issues that may require EPDP Team input / guidance. * 17 July: distribution of Final Report and consensus designations. As a reminder, the Chair will make an evaluation of the support achieved for the recommendations and publish its designation for the group to review. * 20 - 24 July: opportunity for EPDP Team to respond to consensus designations, review by Chair of input received, if any, confirmation by Chair of designation. * 24 July: deadline for minority statements. * At the latest by 31 July: submission of Final Report to the GNSO Council * When it comes the SSAD recommendations, they should be seen altogether – either the Team is prepared to live with this or not. It would be impossible to work on a system where only parts are agreed to. * Earlier this year, the GNSO passed PDP 3.0, which includes the implementation of project change requests if a group is going to miss its projected deadline. The Council granted the group’s change request from 11 June target to 31 July. The Council did have consternation over this project change request. As noted above, there is no slack in this schedule. If there is no agreement, there will likely be no appetite for the Council to extend the deadline beyond 31 July. 4. Consider outstanding items / questions in relation to recommendation #6 – Contracted Party Authorization 1. Review outstanding items / questions i. Action item: If the Team is of the view that the bolded proposals result in “cannot live with” items, please flag them by COB today. ii. Leadership boiled remaining questions to four outstanding questions. * In all instances where a request is approved or denied, does the EPDP team intend for the rationale to be documented and communicated to the Central Gateway Manager? * Yes – uploaded to Central Gateway * Disagree – needs to be uploaded to Central Gateway, just need to make sure there is nothing confidential uploaded. * Unless there is a co-controller arrangement, this data cannot be further processed without a separate reason * This is an important part of the recommendation process, so the answer is – every instance needs to be documented at the central gateway * If the SSAD cannot produce statistics on how well this is working, there is no longer even a glorified ticketing system – even what we’re left with is not worthwhile if there can’t be proper reporting * This is a hybrid system and decentralized disclosure decisions – no problem with keeping track of what decisions were made, but have a problem with recommendation system from the central gateway manager which is then going to bypass the hybrid model * Have a problem with full details of why a decision was denied, but reluctant to move ahead with this b/c of bureaucracy, overhead, and how long it will take to review each ticket * Instead of “rationale” use “reason for denial” – communicate reason for denial * If there is a dropdown menu, that could work, but that it isn’t how the recommendation is worded right now. This could result in added costs to registrants * The group needs to reread Recs. 1 – 19 to see how these recommendations interact – for example, for logging and auditing, CPs need to document their reason for denial – for this question – do CPs need to feed the CGM all information? * Problem NCSG has with this rationale documentation is not based only on the cost. The more fundamental issue is the training mechanism for automated decision-making, which takes the team away from the agreed upon hybrid model. * In the sentence of 8.2, CP must document the rationale of its denial – change this to “communicate the reason of denial to the CGM” which is less than the rationale * Reason could be “insufficient data” or “insufficient power” but wary of agreeing to vague, high-level language that will be tossed to the implementation group * The Team seems to be in agreement that what will be conveyed to the CGM will be a reason in a fact-less manner, and the detailed decision will be held at the CP * ICANN org liaisons were really asking – 9.2 – deny the request but not details about the rationale – this was a consistency question – any time the CP denies a request – should they document it? * “indicate the category for its denial” – here, there is no chance there will be personal data in the category * The question – what should be shared with the CGM, and Support Staff has sufficient information here – a simpler reason for denial that is provided to the CGM * This rationale does belong in section 9.2 as well – we may need to get rid of the “not” in the legally prohibited “and indicate the category for denial” * Can the EPDP team please clarify what is meant by “whether further balancing or review is required” in 7.2.3? On what basis would a Contracted Party make this determination? Would “further balancing or review” be conducted in addition to the “substantive review of the request” in Authorization Determination Requirements, paragraph 7? In addition, it is unclear how to enforce Authorization Determination Requirements 8.1 and 8.2 without further clarification on the intent of 7.2.3. * Further balancing or review was used to not be too GDPR specific * 7.2.1 – the CP is going through its decision-making – lawful basis – may need to conduct a balancing test. 7.2.3 now discusses whether further balancing – when is further balancing required when there was already a 7.2.1 balancing * If the lawful basis wouldn’t require you to do a balancing test, this a catch-all for when a balancing test wasn’t done in the first place * Paragraphs 8 and 9 are tied to 7.2.3 – this is only tied to when further balancing is required * A balancing test is implied in 7.2.1 already b/c 6(1)(f) may be the lawful basis, and a balancing test is required at this point * From a staff perspective, the way this was split up – CP would look at lawful basis for disclosure, if 6(1)(f), 7.2.3 would be part of that consideration. As part of 7.2.1, the CP could start the balancing, but this is called out. If this gives more sense of comfort, section 7 could be noted, instead of 7.2.3. * Consider deleting “further” or whether balancing was required as section 7.2.1 * Concern has been expressed about the addition: “MUST determine its own lawful basis, if a lawful basis is required, for the processing related to the disclosure decision.”, which was made in response to a comment by ICANN Org (“As a lawful basis is not always required for a disclosure decision, ICANN org suggests editing the requirement to make this clear”.) The ISPCP noted that: “addition not supported. We are dealing with a global policy and therefore, there should be no distinction between the local laws. That would erode the protection for the users and lead to fragmentation in the marketplace. * Lawful basis for disclosure is a GDPR concept. If I’m processing data in New Mexico, and I’m not required to have a lawful basis, is this now making it a global requirement? * This is supposed to be a global policy. Thought that for each and every disclosure, you need a lawful basis. * If you are in a case where GDPR applies, you need a reason to disclose. If GDPR is not applicable, the concept of lawful basis does not apply. * Modeled the policy around GDPR – having done so, GDPR and the lawful bases are now applicable to registrants throughout the world. We cannot erode the fundamental principles of modeling the policy after GDPR * If the concept of lawful basis does not exist in my jx, do not want to prohibit disclosure – it is appropriate to carve out language for jx where this applies. Compliance may be in a tough position to apply this standard for jx where there is no lawful basis – how would those CPs apply this? * In Phase 1, Rec. 16 allows Rrs and Rys to distinguish based on a geographic basis, so want to be consistent with this recommendation. * This text cannot remain in there – it would allow for forum shopping * The concept of lawful basis is a GDPR concept – how should ICANN explain to a Chinese registrar that it needs a lawful basis? * Do not see a problem here – lawful basis could mean the legal ability to disclose. When building this system and providing advice to contracted parties, can explain what is meant by that. * In compliance with the policy, there is no conflict what we’re looking at now and Phase 1 rec re: geographic differentiation * It’s confusing to use the term lawful basis – could replace with “if applicable” * Add a footnote that notes where the concept does not exist in other jx, not that if it is not legally prohibited * When writing footnote, please make sure that there is not geographic jx assumed * It was proposed that “in content on a website associated” (“nor can the disposition of a request be solely based on the fact that the request is founded on alleged intellectual property infringement in content on a website associated with the domain name”) be deleted because “Issues related to content on a website should NOT be addressed with the registrar or registry. (see: https://www.icann.org/resources/pages/spam-phishing-2017-06-20-en & Section 1.1.(c) of ICANN bylaws)”. The BC has noted that the link provided in the RrSG rationale for deletion “is related to abuse notices, presumably leading to take-down requests, whereas the Rec is intended for something completely different (request for data disclosure)”. Does this clarification address the RrSG concern? * If you cannot say the word content within the document, this will be a problem. You cannot always say no for no other reason than if we’re asking about something on a website * Cannot live with word disposition here – this causes a conflict b/w this recommendation and the recommendation to automate requests. Re: content on a website – we’re not talking about abuse – we’re saying in language taken from the PPSAI policy – ONLY b/c of content on a website * Content on a website may be relevant to an infringement proceeding – that is still a domain name case, not a content case – there is nothing risked here by getting rid of this language, and there are risks for keeping it in here. * Content may be relevant – this is not talking about a Rr/Ry to take action – it’s allowing the requestor to find out who is behind a website – purposes are not limited to strings in a domain name – this could be relevant for phishing. * Cannot agree to content being in this. * But if UDRP and URS are based on content, can you agree? * Agree to delete final clause: nor can the disposition of a request be solely based on the fact that the request is founded on alleged intellectual property infringement in content on a website associated with the domain name 1. EPDP Team Feedback 2. Confirm next steps 5. Consider outstanding items / questions in relation to recommendation #19 – Mechanism for evolution * Rec. 19 proposal – the outstanding issues are scope, and the delineation b/c policy and implementation issues – how is this to be addressed and further clarified. There is concern around the decision-making process. There is also concern around guaranteeing that ACs are also involved in the scoping of the effort. There are some minor issues that have been flagged whether some of the data is necessary. * Could the standing committee as a method raises any difficulty – can anyone not live with the GNSO Standing Committee model? * The problem from an ALAC side is how it makes decisions and how those decisions are handled – what is the scope, and how are decisions made? * On the scope: the only sticking point was around automation – Amr suggested not limiting the scope of the group only to these items, but having flexibility * There were several motivations behind this proposal – one having a GNSO standing committee instead of an ICANN-chartered group – this should go through the GNSO first. Having it as a standing committee to make sure that the committee’s work is not under the gun to finish its work. With separating the scoping issue out of here and focus on policy disagreements elsewhere and create a low required threshold to introduce topics into the committee – do not mind a few examples being listed here is a problem. Low threshold to introduce topics; a high threshold to adopt them. * By leaving a number of critical issues unspoken here, this process could have the same problems the GGP did; we just do not know at this point. Vagueness may be helpful to get agreement, but not sure this evolve into something that is acceptable. 1. EPDP Team feedback 2. Confirm next steps 6. Continue run through of yellow items (items identified for further discussion / clarification) 1. Consider yellow items identified for recommendations (continuing with rec #15 and moving down the list 2. EPDP Team feedback 3. Confirm next steps 7. Wrap and confirm next EPDP Team meeting (5 minutes): 1. Wednesday 1 July at 14.00 UTC. Topics to be addressed: Recommendation #7/16 (automation), Recommendation #19 (mechanism). 2. Confirm action items 3. Confirm questions for ICANN Org, if any

1 0

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

June 30, 2020

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

June 30, 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, 01 July 2020 at 14:00 UTC for 2 hours. Zoom room information: Main Zoom Webinar link: please join via this link: https://icann.zoom.us/j/98917212893?pwd=dTRQaEMwK0tweStXTVhpVERsVjdhZz09 Password: 953887 Going forward, observers will now join via zoom webinar room vs audio cast. Observers will have ability to view member chat and information shared in the zoom webinar room. Observers will not be able to use chat or raise hands. Before joining the call: Please send dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only Please be sure you have read the Please be sure you have read the Expected Standards of Behavior [icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_resource…> Visit the Wiki agenda page: https://community.icann.org/x/IINIC Check your time zone: https://tinyurl.com/y9fhxeav 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

FW: The final stretch
by Mueller, Milton L June 30, 2020

June 30, 2020

Brian: > Primarily, we need a way to ensure that we have as close to the > centralized model as possible, as quickly as possible...<snip> When we > shifted to working on the decentralized model To me, this seems like a very odd construction. Because we should all know by know that neither a centralized nor a decentralized model was acceptable; we were working with a hybrid model. Hybrid was defined as: Centralized request processing, decentralized disclosure decisions, with some exceptions for agreed automated disclosure types. We can't go back on the hybrid model consensus, because it was fundamental to everything we did. Dr. Milton L Mueller Georgia Institute of Technology School of Public Policy

1 0