June 2026 - Gnso-ssad - lists.icann.org

SSAD SRT - updated Rec 8 language
by Anderson, Marc June 26, 2026

June 26, 2026

SSAD SRT members, The strawperson document has been updated with revised Rec 8 language. https://docs.google.com/document/d/17N6Y3yYUmbfbAFO6QwR8S1u0uZY0HxKYc8HaadB… Please take a look and provide feedback either in the google document or on the list. If you have issues or concerns with the language; proposing new text to address is helpful. You will see in the document that staff has kept the side-by-side text with redlines. Following that, staff has added a new section with a clean version of the proposed draft recommendation to help with review. In addition, staff has also provided the following changelog of the high-level changes made following our discussion at ICANN 86: Recommendation 8 * Personal Data has been capitalized and added to the glossary. (The glossary definition matches the definition in the Registration Data Policy.) * 8.1 has been crossed out due to a comment that a Contracted Party can determine how to review requests and could determine, based on its own risk assessment, that it can review certain requests in bulk. (In other words, the policy should not dictate this.) * 8.3 has been modified slightly to address multiple concerns expressed during ICANN86: * the Contracted Party MUST consider if the impact on the human rights of the data subject prevents disclosure and * MAY conduct a balancing test as part of its review. (A footnote has been added to clarify that a Contracted Party may choose to apply a GDPR balancing test for all disclosure requests, even those falling outside of GDPR, and this policy would not prevent this.) * 8.4 has been modified to clarify that Contracted Parties MUST disclose if they are able to under applicable law, subject to human rights assessment and applied balancing tests. Thank you, Marc Anderson

5 7

Notes and Action Items - SSAD SRT Meeting - 23 June 2026
by Caitlin Tubergen June 23, 2026

June 23, 2026

Dear SSAD SRT Members, Below, please find the notes and action items from the SSAD SRT meeting on Tuesday, 23 June 2026. Thank you. Best regards, Caitlin on behalf of the SSAD SRT GNSO Support Team -- Action Items For SSAD SRT members: * By Tuesday, 30 June: In preparation for our next meeting on Tuesday, 30 June, please familiarize yourselves with the original recommendation text<https://gnso.icann.org/sites/default/files/file/field-file-attach/epdp-phas…> and the feedback from the RDRS Standing Committee<https://gnso.icann.org/sites/default/files/policy/2025/draft/rdrs-sc-findin…> on Recs. 4, 9, and 18. * By Tuesday, 7 July: Please review the straw person text<https://docs.google.com/document/d/17N6Y3yYUmbfbAFO6QwR8S1u0uZY0HxKYc8HaadB…> and provide feedback for Recs. 3, 5, and 7. Additional feedback can be provided in the straw person document or via the email list. Where possible, SRT members are requested to provide proposed text to address concerns. * Continue reviewing the updated text for Rec. 6 and Rec. 8 and provide additional feedback in the document or on list, including proposed text to address your concerns, where possible. For SSAD SRT Leadership: * Leadership to create and distribute a chart to track: * Recommendations where initial readouts are completed, including dates when these were completed * Recommendations where initial readouts are outstanding, including the projected dates these will take place * Recommendations where updated proposed text has been distributed, including associated due dates and dates for planned future discussion Notes 1. Welcome (5 min) · Thank you for the hard work during ICANN86. · The plan for today’s meeting is to have a short recap of the discussions at ICANN86. · Because our main agenda for today is to do an initial readout of Recs. 3, 5, and 7, we will not spend a lot of time going over the substance of ICANN86 discussions. · There will, however, be additional time to revisit these recommendations. · As promised during ICANN86, we plan to do an initial readout of all 18 SSAD recommendations since the recommendations are very interconnected and interrelated. Going forward with an initial readout is important so that the team can understand how the 18 recommendations fit together and see if there is potential overlap. · Following the progress made during ICANN86, the Leadership Team has been working on a detailed work plan, which we will be sharing soon. · As we go through the recommendations, if a topic warrants a smaller, more nimble discussion, we have the option to schedule targeted small group meetings. · Lastly, I did want to make one note about the updated timing of the meeting. · Prior to ICANN86, we identified a time leading up to ICANN86 with the understanding that we would send another Doodle poll following ICANN86 to see if that time still worked. At the time, several members said the original time did not work well for them. · I am aware the new meeting time poses different challenges to other colleagues. · Our group is spread across many time zones, so it will be difficult to find a time that accommodates everyone. · However, other GNSO groups have rotated their call times to ensure that all members are able to participate during a favorable time zone. Leadership is currently discussing a meeting rotation to ensure do not disadvantage any geographic region. 2. ICANN86 Recap (10 min) · We spent ICANN86 discussing the five recommendations that the RDRS SC marked as high level of effort to modify: · Rec 1 and 2 (Authentication) · Rec 6 (Priority Levels) · Rec 8 (Contracted Party Authorization) · Rec 10 (SLAs) · We spent our Day 0 meeting focusing on Recommendations 1, 2, and 10. · We then had three work sessions and discussed Rec. 6 and Rec. 8. · These recs, in theory, will have the most substantive changes based on the learnings from the RDRS pilot. · Feedback from SRT: · SRT members received some feedback that non-members are interested in participating in discussions, so perhaps during the sessions at ICANN87, we could consider opening up sessions or providing dedicated time for non-members to provide feedback and suggestions. · This could be disruptive, so perhaps consider a short, non-working session where we seek broader feedback from the community at ICANN87. · The slides and previous notes and straw person documents summarize the discussions at ICANN86, so we will not take time to read through these now. 3. Review of Rec 3, 5, and 7 (55 min) * During our discussions at ICANN86, we touched on other related recommendations, including Rec. 3 (what elements are required in a request), Rec. 5 (response requirements, which is closely related to Contracted Party Authorization), and Rec. 7 (requestor purposes). * Rec. 3 was highlighted as a low level of effort to modify, so there are a few small change suggestions for the group to discuss. * Rec. 5 was highlighted as a medium level of effort to modify and deals with response requirements. This topic sounds familiar because it is closely related to Rec. 8 (Contracted Party Authorization), and we will discuss that overlap. * Rec. 7 was considered low level of effort to modify, and there are very few changes to the strawman text for Rec. 7. * Generally speaking, a low level of effort to modify means that there should only be minor to moderate modifications based on the RDRS findings. * You will have seen that the straw person text is very similar to the original text. * As we review the text, please consider if the proposed modifications by the Leadership Team are acceptable. If not, what is missing or needs further modification? * If there is a concern, proposing updated redline text is always appreciated. * Suggestion from the SRT - consider changing the term data controller to data holder, as data controller may not always be relevant for entities like ccTLDs. * Recommendation 3 * The Standing Committee found Rec. 3 to be a low level of effort to modify. * The Standing Committee’s discussions focused largely around ensuring the SSAD form is user-friendly and easy for requestors to understand. * The Standing Committee noted that during implementation, there could be a focus group of requestors and contracted parties to ensure the request form is user-friendly but provides Contracted Parties what they need. * There was the suggestion of including tool tips and other features to help requestors in filling out forms correctly. * Some SC members suggested simplifying the form and removing GDPR-specific language to avoid most requestors choosing “other” as their basis for the request. * Additionally, some requestors noted the lack of ability for IP holders to provide documentation certifying their IP rights. * The next two slides have been provided to show the elements in a complete RDRS request, and the request categories. These slides are provided for background information. * SSAD SRT Initial Feedback to Straw Text for Rec. 3: * The form should inform the requestor about respecting the data subject’s human rights. For 3.7, feedback should also be solicited from end users and registrants - not just requestors and Contracted Parties. * For 3.3, do these features need to be built into the SSAD? * The original recommendations had recommended a Central Gateway Manager would perform certain reviews before sending the request to the Contracted Party. Based on learning from the RDRS, that concept is not likely moving forward. 3.3 is now looking at what needs to be included in the SSAD. If the text is hard to read, we recommend providing alternative text. * In 3.2.3, this is the wrong example question b/c it’s necessary for the Requestor to ask for this data because it is not public. Instead, a better question may be, “How will the requested data support pursuit of that legitimate interest or lawful basis?” * At the end of 3.3 - this should be a capital must. * The Must in 3.3 should be should. * This discussion is an initial reaction. We will have time to get into more detail on the straw text. * Please review the text and provide additional feedback in the document or on the mailing list. Proposed updated text makes the process more efficient. The amount of feedback and comments provided assists Leadership in determining how much meeting time to allot to a particular recommendation. * We try to allot meeting time to the more difficult topics, so we encourage the team to continue diligently working in the document and on the mailing list. * Question: has anything been decided about how this will be implemented? * In the initial work, the Team tried to be agnostic to this question. * In general, it is best to leave up to ICANN org re: how to determine the best way to implement recommendations, whether in house or outsourcing. This is best left to a later decision. The important questions now are - what are the requirements? * The language should be neutral. * Recommendation 5 * Recommendation 5 deals with Response Requirements. * The RDRS Standing Committee’s feedback on Rec. 5 is similar to feedback on other closely related recommendations. * For example, the Standing Committee noted Requestor dissatisfaction with the rationales provided by Registrars for denying requests. * Specifically, requestors noted that the choices from the RDRS “pick list” were insufficient to thoroughly explain the reason for denial. * In light of this, the RDRS Standing Committee discussed requiring more detailed, easily understood reasons for denial (this may sound similar to the discussion the SRT has already had in reference to Recommendation 8). * The idea behind this is for the mutual benefit of Contracted Parties and Requestors - improved requests. * Similar to Recommendation 8, the RDRS Standing Committee discussed the addition of a two-way communication method between requestors and contracted parties. * Also, similar to the discussions the SRT had regarding Rec. 8, the RDRS Standing Committee noted that the Contracted Party should ask the requestor for additional information before denying the request (noting that this functionality does not exist in the RDRS but should for the SSAD). * For background information, the next slide shows the “pick list” of response denial reasons. This is provided for the group’s information. * As EPDP background, Rec. 5 was completed earlier in the process, and Rec. 8 was added later, but there was not appetite to revisit Rec. 5 - that may have led to two recommendations that say the same thing slightly differently. * There could be issues in implementation if we proceed with two recommendations, so the SRT should consider whether to consolidate the recommendations. * SSAD SRT Initial Feedback on Straw Text for Rec. 5 * Consolidating Rec. 5 and Rec. 8 seems appropriate here. Part of our remit is to ensure the modified recommendation make sense. * Agree there is a lot of overlap, and Rec. 5 and Rec. 8 need to be aligned. We also need to align this with the Registration Data Policy. * Agree to streamlining these recommendations. This is part of what the Council means by looking at the recommendations as a package. The end product should be a package of new recommendations that work together as a unit. * There was a lot of feedback on Rec. 5 from the Standing Committee. Most of this has been accounted for in Rec. 8, but we want to make sure that RDRS SC feedback is not lost when potentially combining recommendations. * Ensure that in merging recommendations, there are no points that are lost or unaccounted for. * From the requestor’s point of view, there is a big difference in whether the Registrar is trying to communicate what is insufficient in the request or if the request will be rejected no matter what - it is often hard to understand the intention of the registrar. * The response should explain why the request was denied - the reason for rejection should be clear to the requestor about what was missing * There is also a section in draft Rec. 8, if the request cannot be determined based on what was provided, then the responding party should say so; however, if the response is an outright denial, the rationale will be provided in the response. * Some businesses may choose to be more helpful to requestors. * Recommendation 7 * Recommendation 7 provides a non-exhaustive list of requestor purposes for submitting a disclosure request through the SSAD. * Ultimately, the Standing Committee noted this Recommendation should remain as is. * Similar to Rec. 3 and Rec. 5, the Standing Committee noted that additional tool tips or explanatory language could be added to the SSAD to assist Requestors in submitting proper requests. * I’ll now turn the floor back over to Marc to walk through the recommendation language. * Rec. 7 was very important to the requestor community, and the SC did not think this needed to be modified, in part because the recommendation includes a non-exhaustive list. * Rationale text and additional implementation guidance has been added. * 7.1.3 notes the Standing Committee’s recommendation to assist requestors by providing tool tips to submit proper requests. * SSAD SRT Initial Feedback to Straw Text for Rec. 7 * The language re: data verification requests seems difficult to implement. Should this be adjusted? * This is a situation where a client is going to purchase a corporation and needs to do due diligence on domain name portfolios. This was added because this type of situation is not accounted for in the above examples. * If there are ways to make this more clear or implementable, we have the mandate to do this. * How were the examples chosen for 7.1.1? Is this supposed to be a dropdown or freeform? * This was not intended to translate directly to a dropdown box or form; that is where Rec. 3 comes into play - what is necessary for a request. Rec. 7 is providing a non-exhaustive list of requestor purposes. * Do we need Rec. 7? We already have Rec. 3 - maybe this is not needed. * SRT to consider whether Rec. 7 is needed. 4. Next Steps on Rec Review (15 min) · After today’s call, we will have done an initial readout of 10 of the 18 recommendations. · We will have an initial readout of the remaining 8 recommendations over the next three meetings. · As we go through our work, we’ll be getting updated text out to the group. Please continue providing input, and to the extent possible, provide proposed text to address your concerns. · Looking ahead, we will review Recs. 4, 9, and 18, at our next meeting, and we plan to run the meeting very similarly to this meeting. With that in mind, please familiarize yourself with the language of the original recommendations for Recs 4, 9, and 18. · There will be time to discuss the proposed changes and comments in the straw document as a group before moving to clean text. · It would be helpful for the Leadership Team to provide a chart of what has been reviewed, where updated text has been provided, and the schedule of upcoming review. · We have circulated updated text from Rec. 6 and Rec. 8. · The text was updated based on the discussion at ICANN86. The slides reiterate what was covered via email, so we won’t go over this now. · The straw person now adds a current clean version of the text for ease of reading - this is not meant to foreclose or discourage further discussion. 5. AOB (5 min) * None.

1 0

Post Call | SSAD Supplemental Recommendations Team | Tuesday, 23 June 2026
by Terri Agnew June 23, 2026

June 23, 2026

Dear all, All recordings for the SSAD Supplemental Recommendations Team call held on Tuesday, 23 June 2026 at 16:30 UTC can be found on the small team wiki page <https://icann-community.atlassian.net/wiki/x/AYB2P> . Agenda wiki page includes: * Agenda * Audio recording * Zoom recording (including audio, visual, rough transcript, and chat.) * Attendance For additional information, you may consult the mailing list archives<https://lists.icann.org/hyperkitty/list/gnso-ssad@icann.org/> and the wiki page<https://icann-community.atlassian.net/wiki/x/AYB2P>. Thank you. Kind regards, Terri Policy Team Supporting the GNSO

1 0

Re: | Meeting Follow-up | SSAD SRT Meeting | Tuesday, 23 June 2026 - RDRS Requestor Questionnaire
by Lisa Carter June 23, 2026

June 23, 2026

Dear all, As promised on our call, please find attached the RDRS Requestor Questionnaire. The document provides the list of requestor questions and includes the question label, the data type for each question (string, checkbox, etc.), answer options (if there is a picklist), whether the question is required, and notes on whether the question has any conditions or other restrictions. Please let me know if you have any questions. Kind regards, Lisa From: Terri Agnew via Gnso-ssad <gnso-ssad(a)icann.org> Reply-To: Terri Agnew <terri.agnew(a)icann.org> Date: Monday, June 22, 2026 at 5:14 AM To: "gnso-ssad(a)icann.org" <gnso-ssad(a)icann.org> Cc: GNSO-Secs <gnso-secs(a)icann.org> Subject: [Gnso-ssad] REMINDER | Meeting Invite | SSAD SRT Meeting | Tuesday, 23 June 2026 Dear all, The next SSAD Supplemental Recommendations Team meeting is scheduled for Tuesday, 23 June 2026 at 16:30 UTC for 90 minutes (occurs weekly on Tuesdays, 23 June – 06 October 2026). Join Zoom Meeting https://icann.zoom.us/j/94379024946?pwd=gb0blhnNZ50pJORTKSVnWTnkILIBCR.1 [icann.zoom.us] Meeting ID: 943 7902 4946 Passcode: 7!&u3WB3PU Join instructions https://icann.zoom.us/meetings/94379024946/invitations?signature=QtZ9x-U2Za… [icann.zoom.us] ALL: Before joining the call: Please send apologies and dial out requests to gnso-secs(a)icann.org only Please be sure you have read the ICANN Expected Standards of Behavior , the ICANN Community Anti-Harassment Policy and the ICANN Community Participant Code of Conduct. Visit the 2026 Wiki Agenda meeting pages: https://icann-community.atlassian.net/wiki/x/AYB2P [icann-community.atlassian.net] Thank you. Kind regards, Julie Policy Team Supporting the GNSO

1 0

Meeting Invite | SSAD SRT Meeting | Tuesday, 30 June 2026
by Terri Agnew June 23, 2026

June 23, 2026

Dear all, The next SSAD Supplemental Recommendations Team meeting is scheduled for Tuesday, 30 June 2026 at 16:30 UTC for 90 minutes (occurs weekly on Tuesdays, 23 June – 06 October 2026). Join Zoom Meeting https://icann.zoom.us/j/94379024946?pwd=gb0blhnNZ50pJORTKSVnWTnkILIBCR.1 Meeting ID: 943 7902 4946 Passcode: 7!&u3WB3PU Join instructions https://icann.zoom.us/meetings/94379024946/invitations?signature=QtZ9x-U2Za… ALL: Before joining the call: * Please send apologies and dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only * Please be sure you have read the ICANN Expected Standards of Behavior<https://urldefense.com/v3/__https:/www.icann.org/resources/pages/expected-s…> , the ICANN Community Anti-Harassment Policy<https://www.icann.org/resources/pages/community-anti-harassment-policy-2017…> and the ICANN Community Participant Code of Conduct<https://www.icann.org/en/system/files/files/adopted-icann-community-partici…>. * Visit the 2026 Wiki Agenda meeting pages: https://icann-community.atlassian.net/wiki/x/AYB2P Thank you. Kind regards, Terri Policy Team Supporting the GNSO

2 1

**Starting in 15 minutes | Meeting Invite | SSAD SRT Meeting | Tuesday, 23 June 2026
by Terri Agnew June 23, 2026

June 23, 2026

**Starting in 15 minutes Dear all, The next SSAD Supplemental Recommendations Team meeting is scheduled for Tuesday, 23 June 2026 at 16:30 UTC for 90 minutes (occurs weekly on Tuesdays, 23 June – 06 October 2026). Join Zoom Meeting https://icann.zoom.us/j/94379024946?pwd=gb0blhnNZ50pJORTKSVnWTnkILIBCR.1 Meeting ID: 943 7902 4946 Passcode: 7!&u3WB3PU Join instructions https://icann.zoom.us/meetings/94379024946/invitations?signature=QtZ9x-U2Za… ALL: Before joining the call: * Please send apologies and dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only * Please be sure you have read the ICANN Expected Standards of Behavior<https://urldefense.com/v3/__https:/www.icann.org/resources/pages/expected-s…> , the ICANN Community Anti-Harassment Policy<https://www.icann.org/resources/pages/community-anti-harassment-policy-2017…> and the ICANN Community Participant Code of Conduct<https://www.icann.org/en/system/files/files/adopted-icann-community-partici…>. * Visit the 2026 Wiki Agenda meeting pages: https://icann-community.atlassian.net/wiki/x/AYB2P Thank you. Kind regards, Julie Policy Team Supporting the GNSO

1 0

SSAD SRT - 23 June meeting
by Anderson, Marc June 22, 2026

June 22, 2026

SSAD SRT members, Friendly reminder that we have our next SRT meeting tomorrow 23 June at 1630 UTC. We have the following agenda: 1. Welcome (5 min) 2. ICANN86 Recap (10 min) 3. Review of Rec 3, 5, and 7 (55 min) 4. Next Steps on Rec Review (15 min) 5. AOB (5 min) Slides and agenda will be posted to the wiki page shortly: https://icann-community.atlassian.net/wiki/spaces/gnsocouncilmeetings/pages… Thank you, Marc Anderson

1 0

SSAD SRT - updated Rec 6 language
by Anderson, Marc June 22, 2026

June 22, 2026

SSAD SRT members, The straw-person document has been updated with revised Rec 6 language. https://docs.google.com/document/d/17N6Y3yYUmbfbAFO6QwR8S1u0uZY0HxKYc8HaadB…<https://secure-web.cisco.com/1kocAUOJ7r66jAUl0_Vphnos8M-ocnijxcMsytRInv6V7A…> Please take a look and provide feedback either in the google document or on the list. If you have issues or concerns with the language; proposing new text to address is helpful. Like with Rec 8, staff has kept the side-by-side text with redlines. Following that, they have added a new section with a clean version of the proposed draft recommendation to help with review. In addition, staff has also provided the following changelog of the high-level changes made following our discussion at ICANN 86: Recommendation 6 * Critical Infrastructure has been added to the glossary and matches the definition in the Registration Data Policy. (There was a comment during ICANN 86 that NCSG members may wish to add illustrative examples of critical infrastructure.) * 6.4, 6.4.1, and 6.5 have been crossed out based on comments that this text is more relevant (if at all) under Recommendation 10 and should be relocated there for further discussion. * A new 6.5 has been added to clarify that if a Requestor is of the view that its request was improperly recategorized by the Contracted Party, the Requestor MAY file a complaint with ICANN Org. ICANN Org will then investigate complaints regarding improper categorization under its standard enforcement processes. * Additional text has been added to the rationale, explaining the preliminary agreement that the SSAD SRT will proceed with two priority levels instead of three. In explaining the removal of the original Priority 2 (ICANN administrative proceedings), the rationale now notes that due to discussions outside of this group on how to mitigate against false ICANN administrative claims, the SSAD SRT ultimately decided to remove the separate category from Recommendation 6. In removing the ICANN administrative proceedings category, however, the SSAD SRT noted two things: (1) the response times required under existing Consensus Policies, e.g., 2 business days for responding to UDRP registrar verification requests, remain in place and are NOT affected by the SLAS under this policy, and (ii) the SSAD SRT is not intending to restrict the use of SSAD for administrative proceedings in the future. Thank you, Marc Anderson

1 0

REMINDER | Meeting Invite | SSAD SRT Meeting | Tuesday, 23 June 2026
by Terri Agnew June 22, 2026

June 22, 2026

Dear all, The next SSAD Supplemental Recommendations Team meeting is scheduled for Tuesday, 23 June 2026 at 16:30 UTC for 90 minutes (occurs weekly on Tuesdays, 23 June – 06 October 2026). Join Zoom Meeting https://icann.zoom.us/j/94379024946?pwd=gb0blhnNZ50pJORTKSVnWTnkILIBCR.1 Meeting ID: 943 7902 4946 Passcode: 7!&u3WB3PU Join instructions https://icann.zoom.us/meetings/94379024946/invitations?signature=QtZ9x-U2Za… ALL: Before joining the call: * Please send apologies and dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only * Please be sure you have read the ICANN Expected Standards of Behavior<https://urldefense.com/v3/__https:/www.icann.org/resources/pages/expected-s…> , the ICANN Community Anti-Harassment Policy<https://www.icann.org/resources/pages/community-anti-harassment-policy-2017…> and the ICANN Community Participant Code of Conduct<https://www.icann.org/en/system/files/files/adopted-icann-community-partici…>. * Visit the 2026 Wiki Agenda meeting pages: https://icann-community.atlassian.net/wiki/x/AYB2P Thank you. Kind regards, Julie Policy Team Supporting the GNSO

1 0

Meeting Invite | SSAD SRT Meeting | Tuesday, 23 June 2026
by Julie Bisland June 19, 2026

June 19, 2026

Dear all, The next SSAD Supplemental Recommendations Team meeting is scheduled for Tuesday, 23 June 2026 at 16:30 UTC for 90 minutes (occurs weekly on Tuesdays, 23 June – 06 October 2026). Join Zoom Meeting https://icann.zoom.us/j/94379024946?pwd=gb0blhnNZ50pJORTKSVnWTnkILIBCR.1 Meeting ID: 943 7902 4946 Passcode: 7!&u3WB3PU Join instructions https://icann.zoom.us/meetings/94379024946/invitations?signature=QtZ9x-U2Za… ALL: Before joining the call: * Please send apologies and dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only * Please be sure you have read the ICANN Expected Standards of Behavior<https://urldefense.com/v3/__https:/www.icann.org/resources/pages/expected-s…> , the ICANN Community Anti-Harassment Policy<https://www.icann.org/resources/pages/community-anti-harassment-policy-2017…> and the ICANN Community Participant Code of Conduct<https://www.icann.org/en/system/files/files/adopted-icann-community-partici…>. * Visit the 2026 Wiki Agenda meeting pages: https://icann-community.atlassian.net/wiki/x/AYB2P Thank you. Kind regards, Julie Policy Team Supporting the GNSO

1 0