ICANN 83

Event
Process	ICANN
Date	Jun. 9, 2025 – Jun. 12, 2025
Region	EUR
Country	Czechia
City	Prague
Venue	Prague Congress Center
Websites	meetings.icann.org/en/meetings/icann83
← ICANN 82 ICANN 84 →

ICANN 83 was ICANN's 83rd Public Meeting and the 2025 Policy Forum. It was held in Prague, Czech Republic, from June 9-12, 2025 at the Prague Congress Centre, with the support of local host CZ.NIC, operator of .cz. It was the second ICANN Public Meeting held in Prague, following ICANN 44 in 2012.

Overview

ICANN 83 took place during June 9-12, 2025 as a four-day Policy Forum focused on ongoing policy development and advisory work. Prep Week webinars were held on May 27-28, 2025. According to ICANN communications, the meeting was framed against several broader milestones:

• Preparations for the 20-year review of the World Summit on the Information Society outcomes (WSIS+20), including how the multistakeholder model would be presented and defended in intergovernmental venues.
• Continued work on the New gTLD Program: Next Round, including Applicant Support, and publication of the draft Applicant Guidebook (AGB) for Public Comment in May 2025.
• Intensified focus on DNS Abuse and the effectiveness of contractual and non-contractual tools to mitigate it.
• Cross-community reflection on Universal Acceptance, IDNs, and multilingualism.
• Internal process reviews such as the "How We Meet" initiative to adjust the structure of ICANN Public Meetings.

The official schedule was published on May 19, 2025 on ICANN's Sched instance.

GNSO

GNSO Council Public Meeting

The GNSO Council held its public meeting on June 11, 2025. The agenda combined status updates on key small-team efforts (Board readiness, registration data accuracy, DNS abuse), a broader discussion on ICANN-wide reviews, and an open mic where community members highlighted priorities such as the Uniform Domain Name Dispute Resolution Policy (UDRP).

Board Readiness Small Team

The Council received a detailed update from the Board Readiness Small Team, which had been examining how the ICANN Board has handled several sets of GNSO policy recommendations, including Registration Data (Phases 1 and 2) and the New gTLD Subsequent Procedures (SubPro). The goal was not to re-litigate specific Board decisions, but to improve how future GNSO policy development is framed and documented so that recommendations are more robust when they reach the Board.

The Small Team reported on its interviews with Board members focused on how and why specific GNSO recommendations were accepted, rejected, or modified, including issues such as wording problems, perceived bylaw conflicts, cost concerns, and implementation feasibility.

The discussion emphasized extracting “lessons learned” that could be translated into practical tools for future GNSO work, for example, checklists for PDP chartering, guidance on anticipating GAC and ALAC advice, and ways to structure PDP outputs so that the Board can act more coherently on them.

Councilors highlighted the value of using these findings in future strategic planning sessions (e.g. the Council Strategic Planning Session) and in the SCCI’s work on PDP-related continuous improvement.

GNSO Council Registration Data Accuracy Small Team

The GNSO Council Registration Data Accuracy Small Team presented a progress update based on work that included analysis of the INFERMAL study and documentation from registrars on current validation practices.

The Small Team was exploring options to improve outcomes in handling accuracy complaints, with particular attention to shortening the time window for registrants to respond to accuracy-related notices as a way to reduce the window of malicious activity associated with inaccurate contact data.

Councilors from registrar and non-commercial communities flagged tensions between, on the one hand, pressure to shorten response timelines to reduce abuse and, on the other, concerns about due process and privacy impacts. The update stressed that the INFERMAL study is used as one input rather than definitive evidence and that any recommendations must respect privacy and human-rights considerations.

The Small Team was working towards preliminary recommendations that could lead to further Council deliberations or future GNSO policy work (for example, a scoped PDP or new guidance to existing policies).

DNS Abuse Small Team

The DNS Abuse Small Team reported on its ongoing effort to compile and analyze a comprehensive “gap matrix” mapping DNS abuse-related issues across ICANN policies, contracts, and community work.

During ICANN 83 the team used discussions in Prague, including the CPH DNS Abuse Community Update, ALAC’s DNS abuse plenary, and GAC-related sessions, to refine the list of gaps and source documents and to solicit further input from stakeholder groups and advisory committees.

The work plan foresaw structuring and clustering identified gaps, then prioritizing them and feeding the result into a GNSO issue report. That issue report could in turn form the basis for one or more PDPs or other policy mechanisms, depending on the scope and community bandwidth.

The Council discussed whether DNS Abuse issues should be grouped into a single issue report or split into several, and how to balance proactive and reactive measures while being mindful of potential human-rights implications and the limits of policy as a tool for every identified gap.

Latin Script Diacritics PDP

At ICANN 83, the Latin Script Diacritics PDP Working Group used two working sessions to review input from GNSO Stakeholder Groups, Constituencies, and other SO/ACs on its charter questions and to start shaping preliminary recommendations for its Initial Report. The discussion focused on how closely related ASCII and diacritic variants of Latin-script strings should be treated in gTLD policy (for example, whether and when they should be considered effectively equivalent labels) and what safeguards would be needed to avoid user confusion or abuse if multiple variants were delegated. By the end of the meeting, the group had agreed on an outline for its Initial Report and identified a first set of policy options to be refined on its post-Prague calls.

ICANN Reviews

Under the agenda item on ICANN reviews, the Council discussed information from SO/AC leadership discussions and the ICANN Board’s deferral of the next Accountability and Transparency Review (ATRT4) in favor of a possible “review of reviews” and related bylaw amendments.

Councilors debated whether deferring ATRT4 risks non-compliance with existing bylaw timelines versus the benefits of rationalizing the “pile-up” of overlapping organizational and structural reviews.

Several interventions stressed that the community should treat any bylaw changes as a community-driven process, with the Empowered Community playing a central role, and that the opportunity should be used to make reviews more fit-for-purpose and better synchronised with policy and implementation cycles.

From a GNSO perspective, participants linked the discussion to the Council’s own continuous-improvement efforts and to the need to ensure that review outcomes can be implemented in a timely fashion rather than simply accumulating new obligations.

EPDP on IDNs and IDNs IRT

The Expedited Policy Development Process on Internationalized Domain Names (EPDP-IDNs) had completed both its Phase 1 and Phase 2 work prior to ICANN 83, and the focus in Prague was on implementation through the IDNs sub-track of the New gTLD Subsequent Procedures IRT.

The EPDP-IDNs addressed the lack of an agreed definition of variant TLDs and a mechanism for variant management. The work was structured into two phases: Phase 1 on top-level gTLD definition and variant management; Phase 2 on second-level variant management.

The GNSO Council approved the Phase 1 Final Report (69 Outputs) on December 21, 2023; the ICANN Board subsequently adopted 56 of 58 Phase 1 recommendations by September 7, 2024.

The Council later approved all 20 Phase 2 Outputs (14 recommendations and 6 implementation guidance) on November 13, 2024 and transmitted them to the Board in December 2024.

At ICANN 83, the EPDP working group itself did not meet. Instead, an IDNs IRT sub-track session was held on June 10 to advance implementation issues and align IDN variant management with the broader SubPro implementation timeline for the Next Round.

ASO

At ICANN 83 the Address Supporting Organization (ASO) and its Address Council (ASO AC) used their Prague agenda primarily to progress work on a new Regional Internet Registry (RIR) governance document that would replace the nearly 25-year-old "Internet Coordination Policy 2 (ICP-2)". The draft document under discussion would:

• Establish the formal rules by which ICANN and the ASO recognize RIRs.
• Define processes for monitoring RIR adherence to agreed criteria.
• Set out conditions and procedures for derecognizing and replacing an RIR, should that ever be necessary.

During ICANN 83, the ASO's main task around this topic was to review feedback received through an ICANN Public Comment proceeding and parallel consultations in each RIR community, and to consider whether further edits to the governance text were needed before it could move forward.

The ASO schedule also included several joint sessions that positioned number-resource issues inside broader ICANN debates:

• A joint ASO–ALAC session to exchange views on IPv4 exhaustion, IPv6 deployment and how address policy intersects with end-user connectivity.
• A joint ASO–RSSAC session focusing on how address distribution policy and routing practices interact with root server operations.
• A joint meeting with the GNSO ISPCP Constituency that allowed access and transit providers to raise operational concerns related to address management.
• A joint ASO–GAC session to brief governments on the status of RIR governance discussions and how public authorities participate in RIR policy processes.

GAC

The Governmental Advisory Committee (GAC) scheduled around 20 hours of programming at ICANN 83, combining policy discussions, joint meetings and internal planning, with most of the time concentrated on three topics: the New gTLD Program: Next Round (including Applicant Support), registration data and data protection, and DNS Abuse.

Agenda focus and capacity building

GAC sessions began on June 9 with an overview of ICANN 83 and introductions from participating delegations, followed by a chair’s review of:

• Recent GAC correspondence.
• Interactions with the ICANN Board arising from "Issues of Importance" flagged in the ICANN 82 GAC Communiqué.
• Preparations for the joint GAC–Board meeting in Prague.

In Prague, capacity-building sessions were tailored to the Next Round, including:

• An explanatory session on the draft Applicant Guidebook and the Applicant Support Program.
• Exchanges with ccTLD managers to help governments understand how to use both existing and new gTLD processes to meet public-policy objectives.

Key policy themes and joint sessions

On policy, GAC discussions in Prague centred on:

• The New gTLD Program: Next Round, particularly Applicant Support, safeguards, and how GAC advice might shape implementation.
• gTLD registration data services and data protection policies, including the future of registration data access now that RDRS metrics were available.
• DNS Abuse mitigation, including review of recent studies and initiatives and consideration of what additional advice might be warranted.

Operationally, the GAC continued work on its own strategic planning, tracking of its annual work plan, and a process to potentially revise term lengths and limits for GAC chairs and vice-chairs.

The GAC met with the ICANN Board, ALAC, GNSO Council, ASO, and SSAC at ICANN 83, using these bilateral sessions to:

• Reiterate public-policy expectations on the Next Round, DNS Abuse and registration data.
• Clarify how GAC advice would be formulated or updated in light of Prague discussions.
• Coordinate with technical and end-user communities on security and stability issues.

A significant portion of the late-week schedule was reserved for drafting the ICANN 83 GAC Communiqué.

ccNSO

The Country Code Names Supporting Organization (ccNSO) in Prague concentrated on three clusters of work: DNS abuse in the ccTLD space, Internet governance linkages (including WSIS+20), and financial contribution models for ccTLDs.

The ccNSO program included:

• Tech Day: an open technical workshop for ccTLD and other registry operators focusing on DNS operational and security topics.
• A ccNSO welcome and IANA update session, where ccTLD operators received operational and service updates related to the IANA functions.
• A meeting of the ccNSO Internet Governance Liaison Committee (IGLC) examining how WSIS principles had been implemented over the past two decades and the role of ccTLD managers in national and regional Internet governance processes.
• A session of the ccNSO Universal Acceptance Committee (UAC) analysing why many ccTLDs have not prioritized Universal Acceptance work, the practical obstacles they face, and whether coordination with national regulators or other authorities could accelerate UA adoption.
• Presentation of the Second ccNSO Finance (FIN2) Working Group’s final recommendations on voluntary financial contribution models for ccTLDs, based on a survey of ccTLD managers conducted in April 2025. The recommendations aimed to rebalance contributions while preserving their voluntary nature and were scheduled to be taken up by the ccNSO Council in Prague.

The ccNSO also held:

• A ccTLD News Session for operational updates from different regions.
• A DNS Abuse Standing Committee (DASC) session focused specifically on online scams and financial crime linked to domain name abuse, with emphasis on how ccTLDs detect such activity and coordinate response with national authorities.
• A joint session between the ccNSO and the GNSO Registry Stakeholder Group (RySG) to identify areas of collaboration and possible convergence of practices across ccTLDs and gTLD registries.

The ccNSO Council meeting at ICANN 83 was expected to consider how to move forward with the FIN2 recommendations and to provide guidance to working groups on next steps.

RSSAC

The Root Server System Advisory Committee (RSSAC) agenda in Prague revolved around work on an updated version of RSSAC001, "Service Expectations of Root Server Operators". At ICANN 83, the RSSAC work session was tasked with advancing RSSAC001v3, which:

• Revisits the expectations placed on root server operators in light of operational experience since RSSAC001v2.
• Updates criteria related to performance, monitoring, reporting and resilience for the Root Server System (RSS).

RSSAC also:

• Held a joint session with the ASO, connecting root server considerations with routing and address policy questions.
• Conducted its monthly RSSAC meeting.
• Co-hosted with SSAC an open-microphone session on RSS and DNS security topics, intended to surface concerns or suggestions from the wider community about RSS operations and recent RSSAC publications.

SSAC

The Security and Stability Advisory Committee (SSAC) used ICANN 83 to combine community-facing technical outreach with internal work party sessions.

A central item was the "DNSSEC and Security Workshop", a recurring event where operators and experts share deployment experience. By 2025 DNSSEC had become routine for many registries and ISPs, and the Prague workshop spotlighted:

• Operational lessons from wide-scale DNSSEC deployment.
• New tooling and practices for managing keys and validating resolvers.
• Security incidents and trends observed since the previous ICANN meeting.

Beyond DNSSEC, SSAC sessions at ICANN 83 included:

• Lightning talk slots where SSAC members and invited experts presented short technical briefings.
• A presentation on technical insights from an upcoming SSAC report on DNS blocking, aimed at clarifying the security and collateral-damage implications of different blocking techniques.
• A work session on free and open-source software and responsible integration into the DNS ecosystem.
• A DNSSEC Operational Considerations work-party session dealing with operational aspects of DNSSEC at the registry and resolver level.

Joint sessions brought the SSAC together with:

• ALAC, to review the Safer Cyber Campaign, name collision, and DNS blocking from an end-user protection angle.
• GAC, to discuss technical underpinnings of issues that often appear in GAC advice.
• The GNSO Contracted Parties House, to exchange views on security and stability aspects of registry and registrar practices.

Internationalized Domain Name

Generic Names Supporting Organization. Develops and recommends to the Board substantive policies relating to generic top-level domains and other responsibilities set forth in the Bylaws (ICANN Bylaws).

Policy Development Process

Contracted Parties House. Includes the Registries Stakeholder Group and the Registrars Stakeholder Group (ICANN Bylaws).

At-Large Advisory Committee. Considers and provides advice on the activities of ICANN related to the interests of individual Internet users (ICANN Bylaws). Not to be confused with the Non-Commercial Stakeholder Group.

Governmental Advisory Committee. Considers and provides advice on the activities of ICANN as they relate to concerns of governments, particularly matters where there may be an interaction between ICANN's policies and various laws and international agreements or where they may affect public policy issues (ICANN Bylaws).

Policy Development Process

American Standard Code for Information Interchange

Generic Top-level Domain

Expedited Policy Development Process

Top-Level Domain

Internationalized Domain Name

Address Supporting Organization. Advises the Board with respect to policy issues relating to the operation, assignment, and management of Internet addresses (ICANN Bylaws).

Regional Internet Registry

Country code top-level domain. Determined by "ISO 3166-1: Codes for the representation of names of countries and their subdivisions — Part 1: Country codes".

Security and Stability Advisory Committee. Advises the ICANN community and Board on matters relating to the security and integrity of the Internet's naming and address allocation systems (ICANN Bylaws).

Country Code Names Supporting Organization. Develops and recommends to the Board global policies relating to country-code top-level domains (ICANN Bylaws).

Country code top-level domain. Determined by "ISO 3166-1: Codes for the representation of names of countries and their subdivisions — Part 1: Country codes".

Internet Assigned Numbers Authority

Root Server System Advisory Committee. Advises the ICANN community and Board on matters relating to the operation, administration, security, and integrity of the Internet's Root Server System (ICANN Bylaws).

Domain Name System Security Extensions

Internet Service Provider