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

IPC's non-substantive items
by Journoud, Franck 22 Jul '20

22 Jul '20

EPDP Team - with my apologies for their lateness, I wanted to let you know I've just input the IPC's non-substantive, aka Category 3 items, in Marika's July 18 Google doc https://docs.google.com/document/d/1E7NQQpXob_2Rmsq5UbNyxtySsJVUUzH4/edit This extends the total number of items of any categories from 240 to 273. I wish you a most enjoyable reading. -Franck Franck Journoud Vice President, Technology Policy E franck_journoud(a)motionpictures.org<mailto:franck_journoud@motionpictures.org> O (202) 378-9127 | M (202) 285-7322 MOTION PICTURE ASSOCIATION 1600 Eye Street NW, Washington, DC 20006 CONFIDENTIALITY NOTICE: This e-mail communication and any attachments may contain confidential and privileged information for the use of the designated recipients named above. If you are not the intended recipient, you are hereby notified that you have received this communication in error and that any review, disclosure, dissemination, distribution or copying of it or its contents is strictly prohibited. If you have received this communication in error, please notify the sender by return e-mail and delete and/or destroy all copies of this communication and any attachments.

1 0

Proposed Agenda - EPDP Team Meeting #74 - Thursday 23 July at 14.30 UTC
by Caitlin Tubergen 22 Jul '20

22 Jul '20

Dear EPDP Team, Please find below the proposed agenda for the next EPDP Team meeting scheduled for Thursday, 23 July at 14:30 UTC (for 90 minutes). Thank you. Best regards, Marika, Berry, and Caitlin EPDP Phase 2 - Meeting #74 Proposed Agenda Thursday 23 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) 1. Expected approach for consensus designation and timeline: From the GNSO Working Group Guidelines: The recommended method for discovering the consensus level designation on recommendations should work as follows: i. After the group has discussed an issue long enough for all issues to have been raised, understood and discussed, the Chair, or Co-Chairs, make an evaluation of the designation and publish it for the group to review. ii. After the group has discussed the Chair's estimation of designation, the Chair, or Co-Chairs, should reevaluate and publish an updated evaluation. iii. Steps (i) and (ii) should continue until the Chair/Co-Chairs make an evaluation that is accepted by the group. iv. In rare case, a Chair may decide that the use of polls is reasonable. Some of the reasons for this might be: o A decision needs to be made within a time frame that does not allow for the natural process of iteration and settling on a designation to occur. o It becomes obvious after several iterations that it is impossible to arrive at a designation. This will happen most often when trying to discriminate between Consensus and Strong support but Significant Opposition or between Strong support but Significant Opposition and Divergence. Modified timeline: * 22 – 26 July – continuation of online dialogue on category 2 items * 27 July – confirmation in google doc of proposed agreements on category 2 items by staff support team – by 28 July groups to confirm if they cannot live with the proposed agreements (if cannot live, proposed agreements will NOT be applied) * 23 24 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. * 243 - 27 29 July: opportunity for EPDP Team to respond to consensus designations, review by Chair of input received, if any, confirmation by Chair of designation. * 27 29 July: deadline for minority statements. * 31 July: No later than date for submission of Final Report to the GNSO Council 4. Finalization of review of cannot live with items: 1. Priority 2 related items * Item #1 * Item #37-41 1. Any further items flagged after review of proposed approach for cannot live with items documented in google doc<https://docs.google.com/document/d/16BICriVfOPiEeve4A-x6TYKPbgRKqvhX/edit> following 21/22 calls or following review of updated rec #8 language<https://docs.google.com/document/d/10xb5eE3CxTvx5tFNmhsO_F7OdOIRMJFH/edit> 1. Category 2 items (groups to prioritize which items they would like to flag / discuss) * Item #95 * Item #101 5. Wrap and confirm next steps (5 minutes):

1 0

Notes and action items - EPDP Phase 2 Meeting #73 - 22 July 2020
by Caitlin Tubergen 22 Jul '20

22 Jul '20

Dear EPDP Team: Please find below notes and action items from today’s EPDP meeting. The next EPDP meeting will be Thursday, 23 July at 14:30 UTC. Best regards, Marika, Berry, and Caitlin -- 1. Following today’s call, Support Staff to update the Google Doc<https://docs.google.com/document/d/16BICriVfOPiEeve4A-x6TYKPbgRKqvhX/edit> to reflect (i) EPDP agreements reached on the call, and (ii) proposed updated text based on the Team’s discussions. EPDP Team to review updates. 2. EPDP Team to review the updated version of Rec. 8<https://docs.google.com/document/d/10xb5eE3CxTvx5tFNmhsO_F7OdOIRMJFH/edit> and note if any groups cannot live with the updated text by COB today, 22 July. If so, groups to propose updated text they can live, factoring in the discussions to date. 3. EPDP Team to review proposed language for items 37 – 41 (Priority 2)<https://docs.google.com/document/d/16BICriVfOPiEeve4A-x6TYKPbgRKqvhX/edit> and see what text (if any) is acceptable for inclusion in the Final Report. (Note that how these issues are reflected does not change the policy recommendations, nor does it change what the Council is expected to vote on.) 4. EPDP Team members to flag any Category 2 items<https://docs.google.com/document/d/1E7NQQpXob_2Rmsq5UbNyxtySsJVUUzH4/edit> that would benefit from plenary discussion by COB today, 22 July. EPDP Phase 2 - Meeting #73 Proposed Agenda Wednesday 22 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) * The group did make significant progress on resolving most of the ‘cannot live with items’ that were discussed during yesterday’s meeting. * Hopeful that the constructive and pragmatic approach displayed yesterday can be continued for today’s meeting * As noted yesterday, if time remains at the end of today’s call, I will ask you to prioritize which category 2 items should be considered in a plenary setting so we can focus on those. However, as it is likely that we have limited time left we may not be able to get to many or any. As a result, I’ve discussed with the staff support team and we would like to propose to offer additional online time for you to resolve category 2 items. We know this is not ideal, but as the category 2 items did not amount to ‘cannot live with’ items, these should not impact the consensus designation or finalization of the other parts of the report, as long as everyone is clear that further changes would only be applied if there is online agreement between the proposer and those that have expressed concerns (and of course, anyone else that may have concerns once they see the final result). The onus will be on those having proposed the changes to engage in a dialogue with those having expressed concern to find an agreement. Agreement will need to be clearly flagged in the google doc so others can also review and flag if the proposed changes have resulted in cannot live with items. We hope this is acceptable to you as a way to allow for further time to continue dialogue while not jeopardizing our overall timeline. We will share the proposed deadlines for this online dialogue at the end of the call. 4. Continue review of cannot live with items: Recommendation #9 – Automation 1. Item #21 & 22 * Both comments concern the same section in the automation recommendation, namely 9.4 which addresses the use cases that meet the legally permissible criteria based on the input from Bird & Bird. * The first comment from the BC/IPC notes normative language is missing which should be reinstated. Staff support can confirm that as this language originally moved from the policy section to the implementation section, the normative language had been removed, but now that it is back in the policy section, it seems appropriate to reinstate the ‘MUST’. * The second comment from the RySG concerns this same section, and revisions have been suggested to more accurately reflect the analysis provided by Bird & Bird on the automation use cases. As the RySG stated in a follow up comment, their issue is with the misstatement of what the legal opinion states. The legal opinion is not a confirmation of legality but an indication of legality. * Possible compromise combining these two points could be: * “9.4 Per the legal guidance obtained (see here), the EPDP Team recommends that the following types of disclosure requests, for which legal permissibility has been indicated legally permissible under GDPR for full automation (in-take as well as processing of disclosure decision), These disclosure requests MUST be automated from the start:” * Possible footnote that would state: “The EPDP team notes that the advice received was based on several specific underlying assumptions and any derogation from such conditions may affects the validity of the advice received”. * For Item 22, the ICANN org comment is important. The legal permissibility term is dependent on 9.4, but if this is revised, 9.4 would also need to be revised. * The compromise version still references legal permissibility, but now says indicated instead of confirmed * B&B memo mentions lowered risk, not if something is legal. This language is not getting at what the B&B memo talked about. It’s potentially dangerous for the EPDP Team to make a comment about what is and is not legally permissible in this context. What would happen, for example, if something is proven to be legally impermissible? * Want to make sure that we have taken local law into account and data flow. Legal permissibility under GDPR does not take into account any charter requirements. * If we leave legal permissibility to CPs, that will be a problem. * Dealing with a worldwide policy, and B&B was applying a GDPR analysis. It is correct that B&B only provide an indication. For us to say that this is legal everywhere is not correct. Moving forward, it is assumed that what B&B said is probably legally implementable but not in every situation for every contracted party. * Ry comments are not meant to say Rys would not rely on B&B input, but having the policy state categorically what is or is not legal is problematic. * Articles 44 – 49 of the GDPR deal with cross-border transfers. There will always be risk, irrespective of automation. There is no such thing as no risk. 1. Item #23 * Proposed addition by the BC/IPC: “9.X Per the legal guidance obtained the EPDP Team recommends that the following types of disclosure requests are legally permissible under GDPR for centralized disclosure evaluation (in-take as well as processing of disclosure decision) at the Centralized Gateway Manager when subject to manual processing and review from the start: * Automated disclosure decisions for clear-cut “domain matching trademark” requests * Automated disclosure decisions for clear-cut cases of phishing ICANN org is the controller when processing this disclosure decision.” * Question for the group: is there support for adding this new paragraph to the report? * Not clear on what IPC/BC are asking for. The two use case bullets – no input on clear-cut cases of phishing – not sure how that would be achieved. Second bullet regarding trademark requests – this is not a high enough bar for centralized decision-making or automation. Domain names that match trademarks, even an exact match, is not, in itself a clear-cut issue on anything. UDRP requires bad faith, for example. * It is too late to bring in these use cases at this hour – these require subjective review. Who will certify that there is clear-cut phishing? * This is not new; the group has been discussing this for a while. Concerned now re: how evolution would look. This tracks with B&B advice. As long as there is manual intervention (by the gateway), these could be automated. This is very important to the BC/IPC. * The DNS abuse framework is distinct from disclosure of data. The discussion of the DNS abuse framework is a red herring and should not be further discussed in this context. * This aligns with the B&B memo. * Tried a number of times to use centralization, and for better or worse, the group defined automation as possibly including manual steps. Support these use cases. * There does not appear to be enough support within the Team to add this language. 1. Item #24 * Proposed deletion by IPC / BC of 9.14 “In the context of further consideration of potential use cases that are deemed legally permissible in the context of recommendation #18, legally permissible is expected to be determined, in the absence of authoritative guidance (e.g. EDPB, European Court of Justice (ECJ), new law), by the party/parties bearing liability for the automated processing of disclosure decisions”. * The deletion of this section was discussed last week, and there was no agreement to delete it. Has this changed? * Do not support this deletion. Recommendation #8 – Contracted Party Authorization 1. Review of proposal (Amr) to address items #12, #13 #14 * If small team comes up with proposal, consider introducing proposal and giving group 5 minutes to review / consider? * This proposal was worked on by Amr, Chris, and Alan Woods. Concern was that the language mandates differentiation based on geographic location of registrants. The update lets CPs to differentiate but does not obligate them to. GAC raised a concern in response to some of the fixes, which may have resulted in the presumption that the balancing test is to be performed for every request. There are other lawful bases in Article 6. There is now text that references Recommendation 16 – this creates a distinction b/w CPs who differentiate and those who do not. For those who do choose to differentiate, these CPs would not be subject to 8.8 and 8.9. Additionally, a number of changes were made later in the document. Instead of referencing applicable law, it references the lawful basis of the CP. This is important to NCSG b/c there seemed to be a suggestion that if a CP is not required by law to provide a lawful basis, then CP would be obliged to disclose requested data. This is problematic b/c it depended on location of CPs and registrants. The lawful basis should be either lawful bases in GDPR or the applicable law of the CP. * Have these changes resulted in “cannot live with” items? * ALAC cannot support the addition at the top of the policy re: Rec. 16. EPDP Team should not express preferences in this report, especially b/c there is no consensus on this. Propose to strike this sentence, or strike everything after “although” or change the EPDP Team to “some members of the EPDP Team” * The last sentence in the first paragraph expresses a sentiment of the NCSG but may not be representative of the EPDP Team, but was under the impression that since we are building a standardized system that disclosure decisions should be treated as uniformly as possible * In light of the fact that there is no differentiation, have an issue with this statement. Striking the second half of the sentence addresses the main concern. * Status quo in Phase 1 – allows CPs to differentiate. This statement should be included here as there is no work currently planned. * First part of sentence does need to stay in – text after although needs to be stricken * Question from ICANN Org – 8.17 – when reviewing Rec. 8 to define a lawful basis in reference to implementation guidance. The change to this guidance is confusing – what does “lawful basis under ICANN policy” mean? * The ICANN policy referred to is this one. Under terms of this policy, what should be applied is what is under ICANN policy – it would only be when ICANN policy contradicts with local law, that local law would trump * This is an admirable position to take, but it is not within the Team’s charter. * Support Staff to post this recommendation after the call and groups can respond by COB today. 1. Item #16 * BC/IPC proposal to modify 8.7.1 as follows: “Replace the first sentence of 8.7.1 with the following: “8.7.1. If, following the evaluation of the underlying data, the Contracted Party determines that disclosing the requested data elements would not result in the disclosure of personal data, the Contracted Party MUST disclose the data, unless the disclosure is expressly prohibited under applicable law. For clarity, if the disclosure would not result in the disclosure of personal data, the Contracted Party does not have to further evaluate the request. * Staff follow up question asked who would be responsible for making this assessment if the proposed edit is applied and the CP reference is removed. * The BC has responded noting that: “this is an example where ICANN Compliance can evaluate whether the initial assessment by the CP is accurate. * How that would work in practice? Would a CP send its assessment to ICANN org for review / audit? Also, by removing it here, it just leaves it vague who would do the implementation so if the intent is to also have a role for ICANN org, and there is agreement on that, it might be better to specify that instead of taking out who is responsible for this specific part here. * This is not a question of CPs evaluating it; the question is can the determination be subsequently raised with Compliance re: if there is no personal data? This is a factual question as to whether the record includes personal information. If the determination is factually incorrect, then it gives the ability for the requestor to make a request through ICANN Compliance. * What will this complaint be based on? How would the requestor know if the data is legal/natural – this does not make sense. The language as proposed needs to stay. * If you look at the WHOIS record, you could look at the WHOIS record whether there is personal information or not. This is different than the balancing test, which is different than an on-its-face determination. * Not sure how this proposed deletion would prevent complaint submission * This should be a factual determination. The CP reasonably determines instead of determines * Margie to propose an update in the chat * “the Contracted Party reasonably determines that disclosing the requested data” * No objection to this change Recommendation #6 – Priority Levels 1. Item #8 * We briefly touched upon this yesterday. There is a proposal from the GAC and BC to change from MAY to MUST ability for CP to prioritize requests that have been flagged by requestors as concerning a consumer protection issue (phishing, malware or fraud). * As a reminder, the ability for requestors to indicate a consumer protection issue and allow the CP to prioritize it accordingly is included in this way as the EPDP Team did not agree on a definition and criteria for consumer protection issues. It is the expectation that experience gained following implementation might help inform further evolution of a possible priority designation which could be tied to certain requirements. Staff noted that without these criteria and specificity on what a CP is expected to do, it may not possible to enforce a MUST requirement. * The GAC team provided further input noting that: “When CP’s review requests (which they likely must do to assess whether or not to disclose), they would need to flag requests that relate to consumer protection, (including phishing, malware, fraud) and then prioritize these requests ahead of other Priority 3 requests. Another option would be to create another priority level for consumer Protection requests (Priority 3) and let the remaining requests go to Priority 4. BC/IPC may have additional thoughts.” * First question is whether there is concern about this change from other groups and a second related one is whether, if there is support for making this change, there is sufficient information for CPs to know what is expected of them and for ICANN org to enforce this obligation. * Disagree with this new category addition at the last minute. The terminology of what constitutes a consumer protection complaint does not exist. * There is little benefit to allowing requestors to indicate priority requests – just how we have zzz participants go to the bottom of the line, there should be an easy way to move them to the top of the line. The new priority isn’t as important as an obligation to deal with requests flagged in this way first * Thought these requests are coming from accredited consumer protection organization – this should already be flagged in accreditation, so this should not be problematic to implement this. * Timing for dealing with these requests is the same for priority 3, but these requests would jump to the top of the queue * If MUST is not acceptable and MAY is not enough, could SHOULD be a midway – there is an expectation that contracted parties prioritize these requests? * Should in unenforceable – opposed to SHOULD. * There is a concern with deadline to respond to disclosure requests even if the priority doesn’t change. * Uncomfortable with this concept – there seems to be an attempt to micromanage the queues of contracted parties. Agreed to three priority levels, and this is about the request for disclosure of data. Abuse can also be dealt with in other ways (abuse queue, phone, etc.) * There could be, during implementation, where there are timelines within which to do sorting so that that there is no paying Paul and robbing Peter. This is speculative to assume that you’re sorting consumer protection requests over other requests. * Can change to “should” but that is not enough for some. This will be reflected in terms of the consensus designation. Recommendation #7 - Requestor Purposes 1. Items 10 & 11 * Proposed deletion by RySG of “obligations applicable to digital service providers (DSP)” from “Requestors MAY submit data disclosure requests for specific purposes such as but not limited to: (i) criminal law enforcement, national or public security, (ii) non law enforcement investigations and civil claims, including, intellectual property infringement and UDRP and URS claims, (iii) consumer protection, abuse prevention, obligations applicable to digital service providers (DSP) and network security”. Rationale: from a practical perspective, we think naming one specific regulated entity while omitting all others creates confusion and implies that we are intending to favor the requirements of this regulation above all others (in fact, as written we are even omitting other regulated entities under the same NIS regulation that may have similar obligations, e.g. Operator of Essential Services). There are numerous regulated entities globally that may assert that they require data to fulfill regulatory obligations and future laws will almost certainly create ones that don’t exist today. A categorical approach that captures the types of obligations that regulated entities have (e.g. network security, consumer protection, abuse prevention) provides greater flexibility and future-proofs the policy. * Subsequently, BC provided a proposed footnote: ““For the purposes of this Recommendation, the obligations of DSPs are specified under EU NIS Directive of 2018 <https://ico.org.uk/for-organisations/the-guide-to-nis/key-concepts-and-defi….> However, RySG has noted that BC addition does not address the RySG concern stated. * BC/RySG to discuss how this concern can be addressed. * Important to remember that this is a ‘MAY’ as well as ‘such as but not limited to’ phrase. * Important to reference this, even though it is a may * There a number of regulations that create obligations for parties that request data – by including one and omitting all others, we are implied that the entities under this one statute are differently situated than others. Should not have to enumerate all entities, and should not enumerate one at the exclusion of others * Nothing in the policy is preventing anyone from submitting a request * This is a last-minute request by the CPs to take this out. The specification of internet security requests is important * BC and RySG to take this issue offline Recommendation #5 / #8 – footnote re. ICANN org compliance review 1. Items #7 & 18 * Discussed during yesterday’s meeting. * Note ICANN org liaisons proposal: ICANN org suggests deleting footnotes 22 and 29 to avoid confusion with the requirements in this report. The footnotes were intended to add clarity to these recommendations, but now seem to contemplate new obligations or reinterpret existing obligations. For clarity in implementation, ICANN org would recommend deleting both of these footnotes. * Could live with the removal of the footnote – just want to make sure this is covered elsewhere * Agree with removal of footnote Recommendation #10 – SLAs 1. Item #25 * Discussed during yesterday’s meeting – RrSG proposal to change SLA for urgent requests from ‘1 business day, not to exceed 3 calendar days’ to ‘1 business day, not to exceed 5 calendar days’. * Proposal put forward after yesterday’s discussion: Addition of Footnote (based on Laureen’s proposal) for Priority Requests: During the implementation phase, ICANN org should consider an exemption process for smaller registrars for whom it may be difficult to meet the Priority 1 SLA requirement. In considering an exemption process, note that the CP may recategorize a request if it determines that the request does not meet the criteria for Priority 1 (urgent requests). When the CP determines the criteria for an urgent request have not been met, it is not required to respond under the Priority 1 SLA requirement. * If this is not acceptable, possible compromise approach is to make it 4 calendar days? * There is a provision that allows a CP to recategorize the request. If they do that, they need to provide an indication of why it was recategorized. * Registrars cannot agree to 3 calendar days. * If we cannot come to agreement, this previous agreement will stand, correct? * Yes. * Doubtful that this very narrow category of requests will create a problem. Recommendation #14 - Financial Sustainability 1. Item #27 * Proposed addition by ALAC and supported by BC, IPC and SSAC: "The prospective users of the SSAD, as determined based on the implementation of the accreditation process and Identity Providers to be used, must be fully involved in the discussions on setting usage fees for the SSAD. In particular, those potential SSAD requestors who are not part of the ICANN community must explicitly be included.” * This was also one of the proposals flagged in the yellow items and at the time, opposition was noted from RrSG and ISPCP. Furthermore, the ICANN org liaisons had noted that “The proposed new language seems to be phrased as Implementation Guidance. ICANN org notes that fees are typically derived from a variety of sources, including financial analysis, projections, and others. This could include consultation with potential users as described here; however, it may not be possible to arrive at a fee model supported by all potential stakeholders”. * Could groups live with this addition? In order to address the concern expressed by ICANN org, the group may want to consider adding something like: “however, involvement in the discussions does not mean that the final model must be supported by all before it can be implemented.” * The IRT will go on a long time, the vast majority of issues have nothing to do with the costs. * A reasonable suggestion – these people join the IRT, even if only for the financial sustainability discussion, or to provide public comments. * “should be consulted” or “may be offered the opportunity to comment” seems fine * This system has to pay for itself – the only definite form of income we have identified is the users of the system. There should be a consultation process and users can provide comment on. * The word comment is weak – would prefer “comment and interact” – the issue here is not whether they will pay or not, but it’s really about the payment structure – is it per use or a yearly subscription. * Proposed updated version: The prospective users of the SSAD, as determined based on the implementation of the accreditation process and Identity Providers to be used, should be consulted on setting usage fees for the SSAD. In particular, those potential SSAD requestors who are not part of the ICANN community must have the opportunity to comment and interact with the IRT. This input should help inform the IRT deliberations on this topic. * NCSG can live with this if 14.2 is not altered   Recommendation #18 – GNSO Standing Committee 1. Item #34 * Proposed addition by ALAC / BC to this section: “Recommendations concerning implementation guidance shall be sent to the GNSO Council for consideration and adoption, after which they will be sent to ICANN for further implementation work. Recommendations which require changes being made to existing ICANN Consensus Policies shall be recorded and maintained, to be used in the issues scoping phase of future policy development and/or review.” Proposed addition: For avoidance of doubt, recommendations related to disclosure decisions to be made by the SSAD in accordance with Section 9.3 are deemed to be implementation and do not require policy development." * Input already provided: NCSG: In our deliberations there was an explicit recognition that some recommendations may require policy changes. Insofar as this request says that anything the Standing Committee recommends is not a policy change, it is a non-starter” Response from ALAC: “The sentence does NOT say that ANYTHING recommended by the Standing Committee are not policy. The Standing Committee may discuss anything and some of that may indeed be a recommendation to the GNSO to initiate a PDP (or other policy process). Recommendations that are in line with the Policy from this PDP and in accordance with the strict limitation of 9.3 should not be among those.” * The staff support team also noted that this addition seems to preempt the ability for the Standing Committee to determine what aspects are deemed operational / implementation, and limit the ability for the GNSO Council to provide oversight over this distinction. * All this says – if a recommendation is about a use case for disclosure, it is not policy. * This is a critical issue for ALAC support * BC’s view of hybrid model is that it could move from decentralized decision-making to centralized decision-making without a policy change * IPC also agrees that this is needed in order for IPC support of this recommendation * The absence of this clarification * Seems to be one disagreement with current formulation – chair to take note for consensus designation 1. Item #36 * Do not disagree in principle, but concerned about this implementation of this – who makes this determination, is there an escalation path, etc. * Members could appeal to the chair of the GNSO Chair – that goes for any ruling, and especially rulings re: consensus. * Not everything can be escalated to the GNSO Council. The original proposal was for full consensus; the change in this was a compromise. This would be an additional compromise, and do not agree with this. Prefer full consensus. * There is not agreement to add this language. Priority 2 related items 1. Item #1 2. Item #37-41 * All these items concern priority 2 topics, and especially legal/natural and accuracy and how these are (or aren’t reflected in the report). From reviewing the comments, it is clear that members have different perspectives of what the status or perceived agreements / conclusions are, as such, the proposal here as to clarify in the report which topics are not addressed (legal / natural & feasibility of unique contacts) and clarify that the Council is already discussing how to address these topics, in addition to accuracy, but leave it at that. Of course, if you are all able to agree on a way to summarize the status of these issues, we have no problem to include this, but from what we’ve seen, versions are far apart. * Note that how these issues are reflected does not change the recommendations or what the Council is expected to vote upon. * Group to review the proposed language and see what they could live with. * For tomorrow’s meeting, we may have limited time to discuss Category 2 items. We hope to give people additional online time to see if compromise can be reached. If some items would benefit from plenary discussion, members to flag them. If time remains: 1. Category 2 items (groups to prioritize which items they would like to flag / discuss) * If time allows, consider tackling items #95 and #101. * Groups should be asked to identify which items they consider a priority. 5. Wrap and confirm next steps (5 minutes): 1. Expected approach for consensus designation (Chair) 2. Remaining timeline: * 22 – 26 July – continuation of online dialogue on category 2 items * 27 July – confirmation in google doc of proposed agreements on category 2 items by staff support team – by 28 July groups to confirm if they cannot live with the proposed agreements (if cannot live, proposed agreements will NOT be applied) * 23 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. * 23 - 27 July: opportunity for EPDP Team to respond to consensus designations, review by Chair of input received, if any, confirmation by Chair of designation. * 27 July: deadline for minority statements. * 31 July: No later than date for submission of Final Report to the GNSO Council

1 0

Post Call | GNSO Temp Spec gTLD RD EPDP – Phase 2 | Wednesday, 22 July 2020 at 14:00 UTC
by Julie Bisland 22 Jul '20

22 Jul '20

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

1 0

Meeting Invitation | Observers | GNSO Temp Spec gTLD RD EPDP-P2 call | Thursday, 23 July 2020
by Julie Bisland 22 Jul '20

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

1 0

**Call begins in 15 minutes** Meeting Invitation | Observers | GNSO Temp Spec gTLD RD EPDP-P2 call | Wednesday, 22 July 2020
by Andrea Glandon 22 Jul '20

22 Jul '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 Wednesday, 22 July 2020 at 14:00 UTC for 3 hours Zoom room information: Main Zoom Webinar link: please join via this link: https://icann.zoom.us/j/98917212893?pwd=dTRQaEMwK0tweStXTVhpVERsVjdhZz09 [icann.zoom.us]<https://urldefense.proofpoint.com/v2/url?u=https-3A__icann.zoom.us_j_989172…> Password: 953887 Going forward, observers will now join via zoom webinar room vs audio cast. Observers will have ability to view member chat and information shared in the zoom webinar room. Observers will not be able to use chat or raise hands. Before joining the call: Please send dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only Please be sure you have read the Please be sure you have read the Expected Standards of Behavior [icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_resource…> Visit the Wiki agenda page: https://tinyurl.com/y2oo5a87 [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/y2oo5a87__;!!PtGJab4!toN5Zyy…> Check your time zone: https://tinyurl.com/y6zsms64 [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/y6zsms64__;!!PtGJab4!toN5Zyy…> 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#,,,,,,0#,,953887# or +13462487799,,98917212893#,,,,,,0#,,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 Passcode: 953887 Thank you. Kind regards, Julie

1 0

For your review - updated recommendation #8 (addressing category 1 items #12, 13 and 14)
by Marika Konings 22 Jul '20

22 Jul '20

Dear EPDP Team, A small group of volunteers (Amr, Chris L-E and Alan W.) worked on further considering the input received during yesterday’s meeting on category 1 items #12, 13, and 14 in relation to Contracted Party Authorization. They would like to put forward the following proposed changes (see redline version attached) that aim to address the different viewpoints expressed. Under agenda item 4d the proposed updates will be further explained, but the group already wanted to give you an opportunity to review and digest in advance of the meeting. Best regards, Caitlin, Berry and Marika

2 1

Proposed agenda: EPDP Meeting #73 - 22 July 2020
by Caitlin Tubergen 21 Jul '20

21 Jul '20

Dear EPDP Team: Please find below the proposed agenda for our next meeting, which will be Wednesday, 22 July 2020 at 14:00 UTC for 3 hours. Best regards, Marika, Berry, and Caitlin -- EPDP Phase 2 - Meeting #73 Proposed Agenda Wednesday 22 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. Continue review of cannot live with items: Recommendation #9 – Automation 1. Item #20 2. Item #21 3. Item #22 4. Item #23 5. Item #24 Recommendation #8 – Contracted Party Authorization 1. Review of proposal (Amr) to address items #12, #13 #14 2. Item #16 Recommendation #6 – Priority Levels 1. Item #8 Recommendation #7 - Requestor Purposes 1. Items 10 & 11 Recommendation #5 / #8 – footnote re. ICANN org compliance review 1. Items #7 & 18 Recommendation #10 – SLAs 1. Item #25 Recommendation #14 - Financial Sustainability 1. Item #27 Recommendation #18 – GNSO Standing Committee 1. Item #34 Priority 2 related items 1. Item #1 2. Item #37-41 If time remains: 1. Category 2 items (groups to prioritize which items they would like to flag / discuss) 5. Wrap and confirm next steps (5 minutes): 1. Expected approach for consensus designation (Chair) 2. Remaining timeline: * 23 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. * 23 - 27 July: opportunity for EPDP Team to respond to consensus designations, review by Chair of input received, if any, confirmation by Chair of designation. * 27 July: deadline for minority statements. * 31 July: No later than date for submission of Final Report to the GNSO Council

1 0

Notes and Action Items - EPDP Phase 2 Meeting #72 - 21 July 2020
by Caitlin Tubergen 21 Jul '20

21 Jul '20

Dear EPDP Team: Please find below the notes and action items from today’s meeting. Thank you. Best regards, Marika, Berry, and Caitlin -- Action Items 1. Following today’s call, Support Staff has updated the Google Doc<https://docs.google.com/document/d/16BICriVfOPiEeve4A-x6TYKPbgRKqvhX/edit> to reflect (i) EPDP agreements reached on the call, and (ii) proposed updated text based on the Team’s discussions. EPDP Team to review updates, and items flagged during today's call (1, 7, 8, 10, 11, 13, 14, 16, 18, 21, 22, 23, 24, 25, 27, 34, 37, 38, 39, 40 and 41) and come prepared to tomorrow's meeting with constructive ideas. 2. EPDP Team members to flag any Category 2 items<https://docs.google.com/document/d/1E7NQQpXob_2Rmsq5UbNyxtySsJVUUzH4/edit> that, if applied, would result in “cannot live with” by COB today, 21 July 2020. EPDP Phase 2 - Meeting #72 Proposed Agenda Tuesday 21 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) a) Recap of proposed approach * Focusing on questions within this doc: https://docs.google.com/document/d/16BICriVfOPiEeve4A-x6TYKPbgRKqvhX/edit 4. Commence review of cannot live with items: 1. Introduction of proposal for item #1 (Staff Support Team) * This issue relates to the executive summary and the conclusions related to Priority 2 items. GAC noted this summary did not address legal vs. natural persons. No agreement was achieved on some topics, so those topics are not reflected here. However, later in this document, there is a suggestion for text re: topics not covered in this report. 1. Deliberate on question for item #2 & #3 (EPDP Team) * These topics relate to the introductory section of Chapter 3. This text is not part of the recommendations. It references that the EPDP considered various models. NCSG put forward additional language that should be included. Comment 3 from the ALAC/BC added additional language. Some members do not agree with these comments. Question – are there concerns about this addition. Please keep in mind this is the intro, and not part of the recommendations. * There is no need for the change suggested, but if we do make it, need to have the addition in 3. * Some members believed a centralized model was not technically or legally possible in the timeframe given. * All groups except NCSG prefer the centralized model. The language here is factually inaccurate and cannot go into the report. We have not rejected the other options; we just do not have sufficient legal clarity at the time of the report publication. * This is not policy, it is a description of what happened. The Team reached a compromise on a hybrid model. To say that everyone but NCSG opposed the centralized model is demonstrably false. To say that a hybrid model is one step away from a centralized model is incorrect. Can live with striking the word “typically”. Did not have agreement on a centralized or decentralized model, but compromised on the hybrid model. * The Team only agreed to discuss the hybrid model as a step to get us to a step to as much centralization and automation as possible. The question remains if this language would remain – cannot live with characterizing this report that is the result of consensus and everyone agreeing to reject the centralized model. * This is not about what the Team prefers but what the legal realities are. The centralized model is never going to happen; the hybrid model may have centralized elements to it, but it will never be fully centralized. * If you take a look at the room – there is not consensus on one view vs another. * Support Staff to put forward language based on the comments and suggestions from the group. 1. Deliberate on question for item #4 (EPDP Team) * Following the last call, and based on Janis’ suggestion, Support Staff added language re: recommendations being interdependent and considered as a package. If this makes the group uncomfortable, should this language be removed? This doesn’t change the fact that there are interdependencies in the report. * If we decide to pass the report to the Board without the evolutionary mechanism, that would be a problem for ALAC. There are strong reasons why the group cannot pick and choose. * Apart from how the EPDP Team considers the interdependencies, is the last sentence correct? Can the Team tell the GNSO Council how to consider the report? * If we tell the Council the option to pick the recommendations apart, would have to advise councilors that if certain recs are pulled, support will have to be pulled. The recs should be considered as a package. * This would be a suggestion to the Council, not a requirement or mandate * Registries raised this procedural concern b/c were surprised to see this in the language, as this was not discussed or agreed to. Not all recommendations are interdependent. Rec. 22 deals with Purpose 2, for example. Agree with points others have made that the recommendations about the SSAD should be a package. * Staff to put language in to reflect input received. 1. Introduction of proposal for item #5 (Staff Support Team) * For those items where there is a proposal, Staff will introduce the proposal but there will be no discussion at this stage. Groups are asked to note which proposals they cannot accept or which require further conversation. * In the introduction, there are many principles and concepts that underpin the development of the SSAD. GAC asked if these should be part of the policy recs. Staff noted that each of these principles can be found in the recommendations as these principles are translated into a number of recommendations. 1. Introduction of proposal for item #7 & 18 (Staff Support Team) * Many comments have been made on these proposals. This relates to a footnote regarding what ICANN org can do. ICANN org has been clear from the start that it cannot address the merits of the request or the CP’s determination. This footnote was also discussed on the last call. BC/IPC have requested to delete text re: the merits of the request or the CP’s decision to disclose or note. Removing this from the footnote may create a false expectation, so propose to leave footnote as it was. Encourage groups to note what is missing here and what is not reflected in the footnote. 1. Introduction of proposal for item #8 & #9 (Staff Support Team) * Recommendation 6 – priority levels re: Priority 3 requests. The group discussed if there should be a separate category for consumer protection issues. There was a debate about what the criteria would be. The conversation ended up with CPS MAY prioritize, and experience gained could lead into a consideration of another category in the Rec. 18. Proposal made by GAC and BC/IPC is to change MAY to prioritize to MUST. From an implementation perspective, this could introduce many challenges. Would be helpful for others to weigh in, particularly Contracted Parties – would this provide sufficient guidance on how to enforce this? 1. Introduction of proposal for item #10 & 11 (Staff Support Team) 2. Deliberate on question for item #12, #13 & #14 (EPDP Team) * Do the same requirements apply to the review of disclosure requests by contracted parties? NCSG proposed to remove a number of sections. CPs have submitted similar proposed additions here. Ry language narrows the scope where it only applies to the disclosure of third parties. Are there any objections to adding this language? If so, what does this mean for sections 8.8 or 8.9, or does 8.9 disappear, and every request is subject to balancing and review? ICANN org noted that this seems to conflict with the Phase 1 rec re: geographic differentiation – would the proposed addition override this requirement? * This is directly counter to a Phase 1 recommendation without explicitly saying this. We have been repeatedly told that we cannot add something because someone wants them. To introduce this on the second to last day is unacceptable at this point. * Do not support the removal of 8.9 – there are different protections based on the legal basis. 6(1)(f) balancing is not required for all requests. 8.9 is crafted where we have to protect data subject’s data, but the balancing test is not required. Is there an extra safeguard that could be added? This is not about removing protections; it is to apply proper data processing rules based on the applicable lawful basis. * NCSG is not proposing that a balancing test is required for each disclosure. If a legal basis is being used other than 6(1)(f), there will be no required balancing test. Trying to have a policy that is globally consistent – just b/c a registrant is not based in the EEA does not mean they should not be entitled to GDPR protections. NCSG has been consistently advocating for not differentiating on a geographic basis. * Could there be a clarification on this – the comments seem to be focused on the geographic distinction. Maintain the philosophy from Phase 1 that a registrar may apply a geo distinction if they so choose. * The language does not make a geographic distinction – there is an overarching policy that provides protection to the data subject. As a way forward, could add something to say that the purpose of this rec is to restrict. * The language does not say what the consensus was – the agreement was that there would be a global policy that would apply. The charter provides human rights, and if this Team fails to consider this in the context of a policy, we will end up in court. * What needs to be emphasized here is that the specific 8.9 is not what was agreed. The idea is that there will be a global policy. The language needs to be changed – if it’s not prohibited, you are required to disclose. That needs to change – that is a cannot live with. 1. Deliberate on question for item #16 (if input is received) (EPDP Team) 2. Deliberate on question for item #20 (if input is received) (Staff Support Team) * Is there any concern for Ry proposed addition? * No concern – recent court decision has made it clear that cross-border transfers are important – * Agree to add 1. Introduction of proposal for item #21 & possible question for item #22 (if input is received) (Staff Support Team – EPDP Team) 2. Introduction of proposal for item #23 (Staff Support Team) 3. Introduction of proposal for item #24 (Staff Support Team) 4. Deliberate on question for item #25 (EPDP Team) * Any concern with business day requirement change? * Do not agree – keep as 1 business day, not to exceed 3 calendar days * These are urgent requests – 3 calendar days was a reasonable concession. Do not buy that smaller registrars cannot operate 24/7 for certain issues as the RAA already has 24/7 requirements for certain items. * Many registrars feel strongly about this. 3 calendar days is a make-or-break – this is not doable. * Asking for more than 3 calendar days is not something other groups can live with. Perhaps there could be implementation guidance a way for small registrar faced with an actual urgent request that it cannot fulfill within 3 days, they could seek a waiver of this requirement. Assumption is this will not happen very often. * Support Staff to write up this compromise. * Had we known we could reopen issues or suggest completely new items, ALAC would have added in more items. * Will take note of registrar disagreement 1. Deliberate on question for item #26 (EPDP Team) * No additional comments. 1. Introduction of proposal for item #27 (Staff Support Team) 2. Deliberate on question for item #28 (EPDP Team) * Does this new requirement mean that all costs of SSAD need to be passed down to accredited requestors? * It’s difficult for gov’t and law enforcement agencies to pay for access. Changing this to a “must” brings up the same issue. * Recognizing this is an issue for law enforcement and public sector users of the SSAD – not trying to revisit this issue. Trying to avoid a situation where there are 1000 accredited users of SSAD and 995 say they cannot pay for access. For the most part, or in general, the operating costs will be borne by accredited users. * Staff to work on language based on this. * The language needs to make clear that there is no prohibition from ICANN funding part of it. * Problem with victims of DNS abuse bearing the brunt of the fees. Proposal to leave the language as is. To bear the brunt of it is not what was agreed and is objectionable. * The Team did agree on this very watered-down language. There is already language regarding exceptions. * Consider changing “may” to “should” – all paid by users in a nonstarter * Changing must to should raises more questions than answers 1. Deliberate on question for item #29 (EPDP Team) 2. Deliberate on question for item #30 (EPDP Team) * First proposal – add a sentence – for purpose of determining level of consensus, each of the 9 groups must have equal weight. This may contradict the language regarding contracted party having a veto. * No intention for there to be a contradiction – if there is, can add “subject to requirement for have CP support” after the word weight * Not sure what the edits will accomplish * In terms of where it needs to be placed, that is OK * Agree to add this language. 1. Deliberate on question for item #31 (EPDP Team) * Proposal from IPC and BC to add to the scope “may include the word centralization” in addition to other topics – is there any concern to adding this? * Do not object to adding centralization to the language but concerned with the rationale and the use of the word “ensure”. There is no certainty that use of this mechanism will result in centralization. * The proposed language is probably OK. * The proposed language will be added (note “ensure” will not be part of the recommendation) * Suggestion to address – update the text to say “this may include but is not limited to…decentralization…” This could capture that this could swing either way and is not a deterministic evolutionary mechanism. 1. Deliberate on question for item #32 (if input is received) (EPDP Team) 2. Deliberate on question for item #33 (EPDP Team) * Proposed addition “if seconded by one other group’s committee member” – any concerns with this addition? * Good clarification. Idea is – if one group wants to talk about a specific topic, that is a really low bar. 1. Introduction of proposal for item #34 (Staff Support Team) 2. Introduction of proposal for item #35 (Staff Support Team) 3. Introduction of proposal for item #36 (Staff Support Team) 4. Introduction of proposal for item #37, #38, #39, #40, #41 (Staff Support Team) If time remains: 1. Groups to indicate which items are flagged for further discussion * Staff proposals were inspired by conversations to date. Ask groups to flag which proposals need to be discussed further in a plenary setting. In certain cases, the groups may have to agree to disagree. The Team can begin its discussion during today’s meeting, and more discussion can take place tomorrow. Will also consider Category 2 items where groups have expressed concerns. * Proposal to save Priority 2 items for tomorrow’s meeting. * Item 12 * Need more time for this particular issue * Item 7 * Question to IPC/BC – by removing this language, what is this intended to achieve? * Trying to develop a policy that can evolve over time – the footnote raises a current issue, but what if this evolves in the future? * There is a problem if ICANN can’t or won’t enforce the policy. * What is the goal of IPC’s comment here? * Disagree with Org interpretation – for example, if there is a legal person’s data, that can be enforced. * ICANN org is OK with deleting procedural. Probably safer if we discuss what ICANN will and will not enforce. ICANN will enforce anything that registrars explicitly MUST do. ICANN can’t second guess the decision making of a CP. * Proposal to add the decision to disclose or not to disclose is not unreasonable. It cannot be an enforcement of procedural aspects of the requirements. 1. Consideration of category 2 and 3 items that have been flagged * Homework to Flag Cat 2 items that you cannot live with. 5. Wrap and confirm next steps (5 minutes): * 22 July – EPDP Team meeting to finalize review of outstanding items and discuss next steps, including further details re. consensus call. * 23 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. * 23 - 27 July: opportunity for EPDP Team to respond to consensus designations, review by Chair of input received, if any, confirmation by Chair of designation. * 27 July: deadline for minority statements. * 31 July: No later than date for submission of Final Report to the GNSO Council

1 0

Post Call | GNSO Temp Spec gTLD RD EPDP – Phase 2 | Tuesday, 21 July 2020 at 14:00 UTC
by Julie Bisland 21 Jul '20

21 Jul '20

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

1 0