Glossary

The glossary below provides the meaning of and, if applicable, acronyms for terms that may commonly appear in the Applicant Guidebook. Terms have been sorted in alphabetical order for easy reference. This list is non-exhaustive.

Table G1: Glossary

Term	Acronym	Meaning
2012 Round		The application round of the New gTLD Program that opened in 2012.
2026 Round		The round of the New gTLD Program that opened in April 2026 and is the subject of this Applicant Guidebook.
A-Label		An "A-label" is the ASCII-Compatible Encoding (ACE) form of an IDN string. An A-label begins with the prefix "xn--", followed by a string that is a valid output of the Punycode algorithm [RFC3492], with a maximum of 59 ASCII characters in length.
Accountability Mechanisms		Mechanisms established in the ICANN Bylaws that enable review and reconsideration of ICANN’s actions (see Section 2.7 Accountability Mechanisms). These mechanisms are: the Empowered Community, Reconsideration, the Independent Review Process, and the Ombudsman.
Administrative Check and Preparation for Reveal Day		A manual process that performs administrative due diligence (see Section 3.2 Administrative Check and Preparation for Reveal Day) and verifies whether the evaluation fees have been received as well as provides time for ICANN to prepare for Reveal Day (see Section 3.4 Reveal Day).
Advice		Input to the ICANN Board provided by an Advisory Committee.
Advisory Committee	AC	A formally recognized body, under the ICANN Bylaws¹, charged with advising the ICANN Board on policies within ICANN's mission and scope. The Bylaws recognize four ACs: the At-Large Advisory Committee, the Governmental Advisory Committee, the Root Server System Advisory Committee, and the Security and Stability Advisory Committee.
Affirmations		Affirmations from the SubPro Final Report² indicate that the Working Group believes that an element of the 2012 New gTLD Program was, and continues to be, appropriate, or at a minimum acceptable, to continue in subsequent procedures.
Affirmations with Modifications		Similar to affirmations, as described in the SubPro Final Report, but used in cases where the Working Group recommends a relatively small adjustment to the 2012 New gTLD Program's policies or implementation.
American Standard Code for Information Interchange	ASCII	A character encoding standard for representing a particular set of 95 (English language focused) printable and 33 control characters – a total of 128 code points.
Appeals Process	Appeal	A mechanism that allows for relevant parties to appeal an Objection Panel Determination of an objection. See Section 4.5.9.1 Filing an Appeal.
Applicant		An entity that has applied to ICANN for a new gTLD by submitting its application during the application submission period.
Applicant Evaluation		Applicant Evaluation occurs after the application has either (a) passed String Evaluation and is not part of a contention set, or (b) passed String Evaluation and has prevailed in the contention set. It is conducted in parallel with Application Evaluation (see Module 7 String and Application Evaluation Procedures) based on the application’s priority number, unless other processes prevent the application from proceeding. Applicant evaluation consists of two mandatory assessments: Background Screening and Financial and Operational Evaluation. See Sections 6.1 Background Screening Section 6.2 Financial and Operational Evaluation.
Applicant Guidebook	AGB	The gTLD Applicant Guidebook, describing the requirements of the application and evaluation processes.
Applicant Support Program	ASP	A separate program from the gTLD application process, it offers a reduction in ICANN fees related to the New gTLD Program to qualified applicants with demonstrated financial need. See Appendix 11 Applicant Support Program.
Application		An application for a new gTLD lodged in connection with the terms and conditions of the Applicant Guidebook. An application includes the completed application questions, any supporting documents, and any other information that may be submitted by the applicant at ICANN's request. See Appendix 1 Application Questions.
Application Change Request	ACR	Applicants have the opportunity to request changes to their applications including, but not limited to, the addition or modification of Registry Voluntary Commitments or Community Registration Policy, in response to concerns raised in an objection, via an Application Change Request. See Section 3.8 Application Change Requests.
Application Evaluation		Application evaluation includes the following evaluations: Registry Service Provider Review, Geographic Names Review, Reserved Names Review, Name Collision High-Risk Mitigation Plan Evaluation, Code of Conduct Exemption Evaluation, Registry Commitment Evaluation (including Community Registration Policies Evaluation), .Brand TLD Eligibility Evaluation, and Variant String Evaluation. Among these, only the Registry Services Provider Review is mandatory. See Module 7 String and Application Evaluation Procedures.
Application Priority		Each application will receive a priority number via the Prioritization Draw (see Section 3.7 Order of Application Processing and Prioritization Draw). The priority number establishes the order of processing for all applications in a round.
Application Questions		The set of questions to which applicants provide responses. In the 2012 Round it was included as an attachment to Module 2 of the Applicant Guidebook. See Appendix 1 Application Questions.
Application Round		The complete succession of stages for processing the applications received during one application submission period for gTLDs. The terms and conditions of the Applicant Guidebook are for one application round (see Appendix 10 Terms and Conditions). Any subsequent application rounds will be subject to updated guidebook information (see Section 2.8 Subsequent Application Rounds).
Application submission period		The time range during which applications may be created and submitted. See Section 3.1.1 Application Submission Period.
Application system		A system that allows applicants to securely submit information required to apply for one or more components of the New gTLD Program. This may include Applicant Support Program applicants, Registry Service Provider Pre-Evaluation applicants, and gTLD applicants. See TLD Management System (TAMS).
Applied-for gTLD string		A string that is the subject of a gTLD application.
Background Screening		Background screening protects the public interest in the allocation of critical Internet resources by ensuring that only established corporations, organizations, or institutions in good standing are allowed to operate a new gTLD. See Section 6.1 Background Screening.
Base Registry Agreement	Base RA	The form of registry agreement with ICANN that successful gTLD applicants would enter into prior to delegation of a new gTLD. It sets out the legal, operational, technical, and other obligations for a registry operator managing a gTLD, as well as ICANN’s corresponding rights and responsibilities. Based on the evaluation result and individual circumstance of each gTLD, one or more specifications can be added to the Base Registry Agreement. The Base Registry Agreement is the product of extensive community consultation. ICANN will only consider modification to the agreement in extraordinary circumstances, such as unique legal, jurisdictional, or regulatory issues that would legally prevent an entity from executing the Base Registry Agreement as-is.
Blocked Names		Certain strings, including their allocatable variant strings, that are not eligible for application or delegation in any future gTLD round under existing policy. Blocked Names are not subject to exception processes and cannot be applied for by any entity. See Section 7.2.1 Blocked Names.
Blocked Names Identification		When an applicant fills in the name of the applied-for string, the system will automatically check whether the applicant’s chosen string, along with any applicable variant strings, is a Blocked Name.
.Brand TLD		A designation for a TLD that is operated by and for an entity under its trademarked name as outlined in the entity’s Registry Agreement with ICANN. See Section 7.7 .Brand Eligibility Evaluation and Appendix 4 Base Registry Agreement. To qualify as a .Brand TLD, a registry operator must apply for the .Brand TLD designation and the brand’s trademark must be recorded in the Trademark Clearinghouse.
.Brand TLD Eligibility Evaluation		The .Brand TLD Eligibility Evaluation confirms that the applicant meets the criteria for a .Brand TLD designation. A successful designation will result in Specification 13 being added to the applicant’s Base Registry Agreement, provided the applicant successfully completes all phases of evaluation. See Section 7.3 .Brand TLD Eligibility Evaluation.
CCT Final Report		The Competition, Consumer Trust, and Consumer Choice Review Final Report ³ dated 8 September 2018.
Clarifying Question	CQ	An evaluation panel may issue clarifying questions to obtain more information from an applicant. See Section 1.2.12 Clarifying Questions.
Closed generic		According to the SubPro Policy Development Process Working Group's Final Report, a closed generic is "a TLD representing a string that is a generic name or term under which domains are registered and usable exclusively by the registry operator or its affiliates." See Section 3.1.7 Closed Generics/Exclusive Generic Strings.
Code of Conduct Exemption Evaluation		If an applicant proposes to register all domain names in the gTLD exclusively for the registry operator’s own use or for use by its affiliates, and wishes to waive the protection for itself and its affiliates, ICANN may grant an exemption to the Code of Conduct (Specification 9 of the Base Registry Agreement), provided the gTLD is not a generic string and the registry operator meets the exemption criteria. See Section 7.4 Code of Conduct Exemption Evaluation.
Collision String List		A list of strings maintained by ICANN which ICANN has determined to present a high risk of Name Collision (see Section 7.7 Name Collision).
Community		ICANN follows a multistakeholder model in which individuals, non-commercial stakeholder groups, industry, and governments collectively called the ICANN community, play important roles in its community-based, consensus-driven, policy-making approach.
Community application		An application for a gTLD string with an intended use of being operated for the benefit of a clearly delineated community.See Section 5.4 Community Priority Evaluation. Such a designation is entirely at the discretion of the applicant. An applicant designating its application as a community must be prepared to substantiate its status as representative of the community it names in the application.
Community Objection		An objection made on the grounds that there is substantial opposition to a gTLD application from a significant portion of the community to which the gTLD string may be explicitly or implicitly targeted. See Section 4.5.10.4 Principles: Community.
Community Priority Evaluation	CPE	A process by which to resolve string contention, which may be elected by a Community Applicant. See Section 5.4 Community Priority Evaluation.
Community Registration Policies		Registry Agreement Community Registration Policies (“Community Registration Policies”) are policies required for Community Applications to include in the applicable Registry Agreement. See Section 7.8.4 Community Registration Policies.These should define, at a minimum, who can register in the applied-for gTLD and under what conditions a second-level domain name can be accepted by the registry. Community gTLD registry operators may have additional registration policies outside of the Registry Agreement, so long as they are not contrary to requirements under applicable ICANN agreements and policies.
Community Registration Policies Evaluation		Proposed Community Registration Policies are also subject to ICANN evaluation and approval before they can be included in Specification 12 of the Base Registry Agreement. See Section 7.8.4 Community Registration Policies.
Community gTLD		A Community gTLD is operated for the benefit of a clearly delineated community.
Consensus policy		A policy created through the GNSO policy development process listed in Annex A of the ICANN Bylaws⁴. A list of current consensus policies is available on the Contracted Parties website⁵.
Contention		The situation in which there is more than one application for an identical or Similar string. See Section 5.2 String Contention and Contention Resolution Procedures.
Contention set		A group of applications that were determined to be identical or similar visually, aurally or in meaning to other applied-for gTLD strings as per String Similarity Evaluation or after a String Confusion Objection.
Controlled interruption		A state that newly delegated gLTDs need to establish for at least 90 days during which a specific response is provided for all queries to that top-level domain to help users understand that a Name Collision has occurred. See Section 7.7 Name Collision.
Country Code Top-Level Domain	ccTLD	The class of top-level domains reserved for use by countries, territories, and geographical locations identified in the ISO 3166-1 Country Codes list. See Root Zone Database⁶.
Delegation		The process through which the root zone is edited to include a new TLD, and the management of domain name registrations under the TLD is turned over to the registry operator.
Dispute Resolution Service Provider	DRSP	An entity approved by ICANN to adjudicate dispute resolution proceedings in response to objections. See Section 4.5.3 Dispute Resolution Service Providers.
DNS Stability Review		The DNS Stability Review uses an automated system designed to review all applied-for primary and variant strings. See Section 3.1.8.3 DNS Stability Review. This evaluation ensures all strings conform to the mandatory string requirements, specifically DNS and hostname requirements, IDNA 2008 requirements for IDNs, and the RZ-LGR. Applicants are warned if the string does not meet these requirements and can request a review of the automated assessment.
Domain name		A unique string of letters consisting of two or more levels (for example, john.smith.name) maintained in a registry database.
Domain Name System	DNS	The global hierarchical system of domain names.
Domain Name System Security Extensions	DNSSEC	DNSSEC secures domain name lookups on the Internet by incorporating a chain of digital signatures into the DNS hierarchy.
Evaluation Challenge		A mechanism that allows an applicant to challenge certain evaluation results based on a system, factual or procedural error.
Evaluation Panel		A panel that has expertise in the area that is being reviewed (for example, String Similarity Evaluation Panel). Evaluation panels use the community-established criteria to assess whether or not an applicant has met the criteria.
Existing TLD		A string included on the Root Zone Database⁷ list.
Extended Evaluation	EE	Extended Evaluation allows applicants an additional time period to pass evaluations begun in Initial Evaluation. The second stage of evaluation is applicable for applications that do not pass Initial Evaluation, but are eligible for further review. See Section 1.2.14.1 Extended Evaluation.
Extensible Provisioning Protocol	EPP	A protocol used for electronic communication between a registrar and a registry for provisioning domain names.
Final contention set		Final contention sets come as a result of a String Similarity Evaluation. See Section 7.10 String Similarity Evaluation.
Final Report on the New gTLD Program Subsequent Procedures Policy Development Process	SubPro Final Report	The Final Report⁸ on the New gTLD Subsequent Procedures Policy Development Process, dated 20 January 2021.
Finalized contention set		A contention set that meets the following auction eligibility criteria: Complete string evaluation Complete all applicable objections, appeals, and challenges Complete CPE, if applicable Have no open change requests Have no pending accountability mechanisms
Financial and Operational Evaluation		The Financial and Operational Evaluation assesses whether an applicant has the financial and operational capacity to sustain the registry long-term and has implemented reasonable safeguards to ensure robust business operations and address abuse concerns. See Section 6.2 Financial and Operational Evaluation.
Future Rounds		The New gTLD Program assesses applications in rounds. Future rounds (or “subsequent application rounds”) refers to all rounds that will occur after the 2026 Round. See Section 2.8 Subsequent Application Rounds.
GAC Consensus Advice on New gTLDs		Advice provided to the ICANN Board by the GAC in relation to one or more gTLD applications. See Section 4.3 GAC Consensus Advice.
GAC Member Early Warning		A notice issued by the GAC concerning a gTLD application indicating that the application is seen as potentially sensitive or problematic by one or more governments. See Section 4.2 GAC Member Early Warnings.
Generic Names Supporting Organization	GNSO	ICANN's policy-development body⁹ for generic TLDs, which developed the policy recommendations for the introduction of new gTLDs.
Generic top-level domain	gTLD	The class of top-level domains that includes general-purpose domains such as .com, .net, .edu, and .org. This class also includes domains associated with the New gTLD Program, which includes names such as .futbol, .istanbul, and .pizza, and names in other alphabets and languages. ICANN coordinates the development of the rules and policies that govern the registration of domain names within gTLDs.
Geographic Name		A generic top-level domain and its allocatable variant label(s) is a Geographic Name if it meets any of these criteria: It is the name (in any language) of a capital city of any country or territory listed in the ISO3166-1 standard; it is the name of a city or region where the applicant declares that it intends to use the gTLD for purposes associated with that name; it is an exact match of a sub-national place name such as a county, province, or state listed in the ISO3166-2 standard; or of a name listed as a UNESCO region¹⁰ or appearing on the UN Geographic Regions section M49.¹¹ Each category has different qualifications. See Section 7.5 Geographic Names.
Geographic Names Identification		As part of the Geographic Names Identification, a panel will review all of the applied-for strings and identify which strings may be considered a Geographic Name, as described in Section 7.5 Geographic Names. This is separate from the more substantive verification process called Geographic Names Review (Section 7.5.3.2) that would take place as part of Application Evaluation.
Geographic Names Panel	GNP	A panel of experts charged by ICANN with reviewing applied-for TLD strings to identify, and confirm required documentation for, geographic names.
Geographic Names Review		A verification and substantive review of application responses for strings determined to be geographic. This review takes place as part of Application Evaluation. See Section 7.5.3.2 Geographic Names Review.
Governmental Advisory Committee	GAC	The GAC constitutes the voice of Governments and Intergovernmental Organizations (IGOs) in ICANN's multistakeholder structure. Created under the ICANN Bylaws, the GAC is an advisory committee to the ICANN Board. The GAC's key role is to provide advice to ICANN on issues of public policy, and especially where there may be an interaction between ICANN's activities or policies and national laws or international agreements.
gTLD Application Fee		The fee due from each applicant to obtain consideration of its application. The fee may consist of a partial deposit and payment of the full fee amount for each application submitted.
High-Risk Mitigation Plan		Section 7.7.5 Name Collision High-Risk Mitigation Plan Evaluation outlines the specific preventative and corrective actions the applicant will take to mitigate the risk of Name Collisions, including any communication activities with affected end-users. Each mitigation action must have a specific time frame for implementation. The total time frame must not exceed two years.
ICANN Auction		An auction conducted by ICANN according to the string contention procedures.
ICANN Board		The body that reviews policy recommendations developed by the ICANN community and sends approved policies to the ICANN organization for implementation. The Board¹² also performs strategic oversight for ICANN org, ensuring that the organization acts within its mission and operates effectively, efficiently, and ethically.
ICANN Community	“The Community”	ICANN follows a multistakeholder model in which individuals, non-commercial stakeholder groups, industry, and governments, collectively called the ICANN community, play important roles in its community-based, consensus-driven, policy-making approach.
ICANN organization	org/ICANN org	The entity¹³ that implements the ICANN community’s recommendations at the direction of the ICANN Board.
ICANN-accredited registrar		An entity that has entered into a Registrar Accreditation Agreement¹⁴ with ICANN. The registrar has access to make changes to a registry by adding, deleting, or updating domain name records.
Implementation Guidance	IG	One of the outputs from the SubPro Final Report. In this case, the Working Group strongly recommends the stated action, with a presumption that it will be implemented, but recognizes that there may exist valid reasons in particular circumstances to not take the recommended action exactly as described. However, the party to whom the action is directed must make all efforts to achieve the purpose behind the recommended action (as expressed in the rationale and the recommendation to which the implementation guidance is linked, if applicable), even if done through a different course. In all cases, the full implications must be understood and carefully weighed before choosing a different course. Implementation guidance commonly refers to how a recommendation should be implemented. Implementation guidance typically uses the term “should,” indicating that the Working Group expects the action to take place, noting the caveats above.
Implementation Review Team	IRT	An Implementation Review Team is a voluntary ICANN community team that reviews proposed implementation plans as drafted by ICANN org and checks for consistency with ICANN Board-approved GNSO recommendations. The team also answers questions and gathers clarifications from ICANN org as needed. It provides advice on technical and operational details concerning the recommendations in question.
Independent Objector	IO	A party selected by ICANN to act solely in the best interests of the public. The Independent Objector (see Section 4.5.4 Independent Objectors) may file objections to applications on the grounds of Limited Public Interest (see Section 4.5.1.3 Ground for Objection: Limited Public Interest) and Community (see Section 4.5.1.4 Ground for Objection: Community).
Intergovernmental Organization	IGO	An IGO is an organization composed primarily of sovereign states or of other intergovernmental organizations. IGOs are established by treaty or other agreement that acts as a charter creating the group. Examples include the United Nations, the World Bank, and the European Union.
Internationalized Domain Name	IDN	A domain name in which one or more of its strings contain characters other than ASCII letters, digits, or hyphens. Because IDNs support the use of Unicode characters, they can include characters from local languages and scripts. For example, 실례.테스트, is a domain name composed entirely of Hangul characters.
Internet Assigned Numbers Authority	IANA	The suite of Internet coordination functions relating to ensuring the assignment of globally unique protocol parameters, including management of the root of the DNS and the Internet Protocol address space. The IANA functions are delivered by Public Technical Identifiers, an affiliate of ICANN.
Legal Rights Objection		An objection filed on the grounds that the applied-for gTLD string infringes the existing legal rights of the objector. See Section 4.5.1.2 Ground for Objection: Legal Rights.
Limited Public Interest Objection		An objection filed on the grounds that the applied-for gTLD string is contrary to generally accepted legal norms of morality and public order that are recognized under principles of international law. See Section 4.5.1.3 Ground for Objection: Limited Public Interest.
Main Registry Service Provider	Main RSP	The main Registry Service Provider provides at least Extensible Provisioning Protocol and Registration Directory Services, and generates and sends data escrow deposits to the approved data escrow agent for the gTLD.
Mandatory Public Interest Commitments	Mandatory PICs	Mandatory Public Interest Commitments (see Section 7.8.1 Mandatory Public Interest Commitments) are rules or guidelines mandated by ICANN that a registry operator for a gTLD must adhere to, in order to protect the public interest and consumer rights. These are often implemented in response to concerns raised by the GAC.
Name Collision Analysis Project	NCAP	In 2017, the Board directed SSAC to establish NCAP to conduct studies related to name collision, which refers to the situation where a name that is defined and used in one namespace may also appear in another. Users and applications intending to use a name in one namespace may actually use it in a different one, and an unexpected behavior may result where the intended use of the name is not the same in both namespaces. The circumstances that lead to a name collision could be accidental or malicious.
Name Collision High-Risk Mitigation Plan Evaluation		An applicant for a string that ICANN has deemed to present a high risk of Name Collision and has cleared contention may submit a High-Risk String Mitigation Plan for review. This plan will be reviewed by technical experts. See Section 7.7.5 Name Collision High-Risk Mitigation Plan Evaluation.
Name Collision Initial Assessment		The Name Collision Initial Assessment aims to identify strings with a high risk of name collision, as described in Name Collision. See Section 7.7.2 Name Collision Initial Assessment. If a string is found to be high-risk, the applicant will have an opportunity to submit a Mitigation Plan for evaluation, which will allow the application to proceed if approved.
Naming Services portal	NSp	An online service available through the ICANN website that provides a central location for contracted parties (for example, contracted registry operators and accredited registrars) to conduct business with the ICANN organization. The portal helps streamline operational processes and is customized with community-requested features such as case tracking, multiuser company access, and structured workflows. Users can ask questions, submit information, and request approvals through the portal.
Naming System		See RFC 9499, section 2: https://www.rfc-editor.org/rfc/rfc9499.html#name-names.
Objection		An objection filed with a Dispute Resolution Service Provider in accordance with that provider’s procedures. See Section 4.5 Objections and Appeals.
Objector		A person or entity that has filed an objection against a new gTLD application with the appropriate DRSP.
Organizational Account Record		The organizational information collected during the application pre-submission phase. This information includes, but is not limited to, applicant information, primary and secondary contact information, and proof of legal establishment. See Question Set 4 Applying Entity Background and Organization in Appendix 1 Application Questions for questions related to Organizational Account Record.
Outputs		The affirmations, policy recommendations, and implementation guidance stemming from the Final Report.
Personally Identifiable Information	PII	Any representation of information that permits the identity of an individual to whom the information applies to be inferred.
Pre-Submission String Validations		Validations on the primary and variant strings, including replacement strings, are automatically incorporated into and implemented via TAMS. See Section 3.1.8 Pre-Submission String Validations.
Preliminary contention		All identical string applications on Reveal Day (see Section 3.4 Reveal Day) will be considered to be in preliminary contention.
Program Implementation Review Report	PIRR	A report produced by ICANN org in 2016 which is a collection of staff experiences during the operational implementation of the 2012 Round in the New gTLD Program.¹⁵
Public Interest Commitment Dispute Resolution Procedures	PICDRP	The PICDRP is a dispute resolution mechanism that, in certain cases, utilizes an evaluation panel. For those gTLDs with Registry Agreements that incorporate the PICDRP, the procedure is available to any party harmed by a registry operator's failure to comply with its PICs. The PICs and the PICDRP are one of the safeguards for the community created as part of the 2012 New gTLD Program.
Public Interest Commitments	PICs	Public Interest Commitments are binding obligations that gTLD registry operators have with the Internet community under their contracts with ICANN org. They are subject to compliance oversight and enforcement by ICANN org. (See also PICDRP and RVCs.)
Registrar	Rr	An organization through which individuals and entities (registrants) register domain names. During the registration process, a registrar verifies that the requested domain name meets registry requirements, and submits the name to the appropriate registry operator. Registrars are also responsible for collecting required information from registrants and making the information available through RDDS.
Registration Restrictions Dispute Resolution Procedure	RRDRP	A formal procedure that gives established institutions a way to resolve disputes related to the registration restrictions in the Registry Agreement for gTLDs.
Registry	Ry	The authoritative master database of all domain names registered in each top-level domain. The registry operator keeps the master database and also generates the zone file that allows computers to route Internet traffic to and from top-level domains anywhere in the world.
Registry Agreement	RA	The contract between ICANN and the registry operator of a designated gTLD which defines the rights, obligations, and provisions for the registry operator to operate the gTLD. See Appendix 4 Base Registry Agreement.
Registry Commitments Evaluation	RCE	Each submitted RVC or Community Registration Policy proposed for inclusion in the applicable Registry Agreement is subject to this evaluation by ICANN to determine whether it meets all criteria set out in this AGB. See Section 7.8.3.2 Registry Commitments Evaluation.
Registry Operator	RO	The organization that maintains the master database (registry) of all domain names registered in a particular TLD. ROs receive requests from registrars to add, delete, or modify domain names, and they make the requested changes in the registry. An RO also operates the TLD’s authoritative name servers and generates the zone file. This information enables recursive name servers across the Internet to translate domain names into Internet Protocol addresses, so devices on the Internet can connect to one another.
Registry Service Provider	RSP	A registry service provider refers to an entity providing certain technical operations for a registry operator.
Registry Service Provider (RSP) Evaluation Program		This program allows registry service providers to be evaluated once for the services they intend to provide to applicants. Successful applicants will become pre-approved for the 2026 Round. Applicants that incorporate a pre-approved RSP into their applications will not need to undergo a technical evaluation as long as the RSP remains pre-approved.
Registry Services Evaluation Policy	RSEP	The policy that governs the evaluation of proposed registry services by a registry operator or applicant.
Registry Services Technical Evaluation Panel	RSTEP	A group of experts in the design, management, and implementation of the complex systems and standards-protocols used in the Internet infrastructure and DNS. RSTEP members are selected by its chair. All RSTEP members and the chair have executed an agreement requiring that they consider the issues before the panel neutrally and according to the specified definitions of security and stability.
Registry Voluntary Commitments	RVCs	RVCs are generally optional commitments applicants may propose to overcome third-party concerns with an applied-for gTLD string, or to promote public interest, community trust, or additional safeguards with regard to the operation of the gTLD. After being approved by ICANN following the Registry Commitments Evaluation (RCE), they are expected to be included in the Base Registry Agreement Specification 11 as contractual obligations.
Reserved Names		Certain strings, including their allocatable variant strings, that are generally unavailable for registration because they are set aside for specific entities. Reserved Names include those associated with certain international and intergovernmental organizations (Limited International IGO-INGOs). These names may be applied for only by the relevant entity through an exception process, which requires appropriate documentation as outlined in the applicable procedures.
Reserved Names Identification		When an applicant fills in the name of the applied-for string, the system will automatically check whether the applicant’s chosen string, along with any applicable variant strings, appears on the Reserved Names list. See Section 7.2.2.2 Reserved Names Identification.
Reserved A Names Review		The Reserved Names evaluation process will determine whether the appropriate organization has applied for the reserved string and will verify the supporting documentation, as described in Reserved Names. See Section 7.2.2.3 Reserved Names Review.
Rights Protection Mechanism	RPM	A mechanism that helps safeguard intellectual property rights in the Domain Name System. RPMs include the Uniform Domain Name Dispute Resolution Policy, Uniform Rapid Suspension, and Trademark Post-Delegation Dispute Resolution Procedure.
Root zone		The root zone database represents the delegation details of top-level domains, including gTLDs and ccTLDs. As manager of the DNS root zone, IANA is responsible for coordinating these delegations in accordance with its policies and procedures.
Safeguard Assessment		The Safeguard Assessment will determine if an applied-for string will be required to have specific safeguards as it relates to consumer protection, sensitive strings, and regulated markets. See Section 7.8.2 Safeguard Public Interest Commitments.
Safeguard PIC		Safeguard PICs were developed and implemented in response to the GAC Consensus Advice in the ICANN46 Beijing Communiqué and subsequent ICANN Board Resolution during the 2012 Round of the New gTLD Program. ICANN classifies gTLDs needing Safeguard PICs (see Section 7.8.2.2 Applicable Safeguard PICs by String Category) into four risk-based groups: Regulated Sectors/Open Entry Requirements: Strings invoking consumer trust but with heightened risks; Highly Regulated Sectors/Closed Entry Requirements: Strings associated with industries requiring licensing or accreditation; Potential for Cyber Bullying/Harassment: Strings that could facilitate harassment; Inherently Governmental Functions: Strings associated with government domains.
Script		A collection of letters and other written signs used to represent textual information in one or more writing systems. For example, Russian is written with a subset of the Cyrillic script; Ukrainian is written with a different subset. The Japanese writing system uses several scripts.
Singular/Plural Notification Evaluation		ICANN will review the materials submitted as part of the Singular/Plural Notifications process and will determine whether certain strings represent the singular and plural forms of the same word in the same language. See Section 4.4 Singular/Plural Notifications.
String		The string of characters comprising an applied-for gTLD or its variant string.
String Confusion Objection		An objection filed on the grounds that the applied-for gTLD string is confusingly similar to an existing TLD or to another applied-for gTLD string in the same round of applications. See Section 4.5.1.1 Ground for Objection: String Confusion.
String Contention		The scenario in which there is more than one qualified applicant for the same gTLD or for gTLDs that are so confusingly similar that they create a probability of user confusion if more than one of the strings is delegated into the root zone. See Section 5.2 String Contention and Contention Resolution Procedures.
String Evaluation		String Evaluation (see Section 1.2.4 String Evaluation) focuses solely on the evaluation of the applied-for strings and their allocatable variant strings. String Evaluation consists of five elements, which will be assessed concurrently: String Similarity Evaluation (see Section 7.10 String Similarity Evaluation), Name Collision Initial Assessment (see Section 7.7.2 Name Collision Initial Assessment), Safeguard Assessment (see Section 7.8.2 Safeguard Public Interest Commitments), Geographic Names Identification (see Section 7.5 Geographic Names), Singular/Plural Notifications Evaluation (see Section 4.4 Singular/Plural Notifications).
String Similarity Evaluation		String Similarity Evaluation (see Section 7.10 String Similarity Evaluation) determines Visual Similarity of gTLD applications against other gTLD applications, as well as existing TLDs, previously applied-for gTLDs and ccTLDs that are still in those processes, Blocked Names (see Section 7.2 Blocked and Reserved Names Overview), and any two-character ASCII string (that is, a potential future ccTLD).
Subsequent Procedures	SubPro	Introduction of new gTLDs beyond the 2012 Round. Related to the New gTLD Subsequent Procedures Policy Development Process and the Final Report¹⁶ which included the set of outputs related to the 2026 Round of the New gTLD Program.
Temporary Delegation		Strings (including variant strings) that are not identified as high-risk during the Initial Assessment (see Section 7.7.2 Name Collision Initial Assessment) will be queued for Temporary Delegation (see Section 7.7.3 Temporary Delegation and Final Assessment). Temporary Delegation will start once the Initial Assessment has been concluded, even if other evaluations that are part of String Evaluation are still being performed. The prioritization of Temporary Delegation will be determined based on the application’s assigned priority number.
TLD Application Management System	TAMS	A system that allows applicants to securely submit information required to apply for one or more components of the New gTLD Program. This may include Applicant Support Program applicants, Registry Service Provider Pre-Evaluation applicants, and gTLD applicants.
Top-Level Domain	TLD	Top-level domains (TLDs) are the names at the top of the DNS naming hierarchy. They appear in domain names as the string of letters following the last dot, such as “NET” in www.example.net. The TLD administrator controls what second-level names are recognized in that TLD. The administrators of the root domain or root zone control what TLDs are recognized by the DNS.
Trademark Clearinghouse	TMCH	A mechanism designed to help protect the rights of trademark holders. The Trademark Clearinghouse verifies and records rights information from all over the world. This verified information is used during domain name registration processes, especially when new gTLDs launch.
Trademark Database	TMDB	The Trademark Database is part of the Trademark Clearinghouse. It provides an interface for registries and registrars via which they can meet the requirements of certain Rights Protection Mechanisms.
Uniform Domain Name Dispute Resolution Policy	UDRP	A policy for resolving disputes arising from alleged abusive registrations of domain names (for example, cybersquatting), allowing expedited administrative proceedings that a trademark rights holder initiates by filing a complaint with an approved dispute resolution service provider.
Uniform Rapid Suspension	URS	An expedited administrative procedure that rights holders can initiate for certain types of domain name disputes. The URS procedure is a tool for quickly addressing clear-cut cases of trademark infringement.
United Nations official languages	UN6 languages	The six languages used by the United Nations: Arabic, Chinese, English, French, Spanish, and Russian.
Variant String Evaluation		An applicant seeking one or more allocatable variant strings of an applied-for primary string or existing gTLD must justify the need for each applied-for variant string. This justification will be evaluated (see Section 7.6 Variant String Evaluation) by a panel based on the criteria specified in the relevant IDN EPDP Phase 1 policy recommendation. Successfully evaluated variant gTLDs will be included in Specification 14 of the Base Registry Agreement. See Appendix 4 Base Registry Agreement.
Variant String		A string considered “same” as another string by the relevant script community, and, therefore, generated as a variant of a primary string according to a particular set of Label Generation Rules (LGR). For top-level, Variant String of another string is defined by the Root Zone Label Generation Rules (RZ-LGR).
Variant-string-set		The primary, allocatable and blocked variant strings together are called a variant-string-set. For an existing gTLD, it is considered the primary string against which its variant-string-set will be calculated and submitted. For the top-level, a Variant-string-set is created by applying the Root Zone Label Generation Rules (RZ-LGR) to the primary string.
Visual Similarity -or- Visually Similar		Visual Similarity occurs when two or more strings are Visually Similar such that they would create a probability of user confusion if allowed to coexist. See Section 5.2 Contention and Contention Resolution Procedures.
Working Group	WG	A temporary group formed by a Supporting Organization or Advisory Committee to solve a specific problem or carry out a particular assignment.
Zone File		A file on an authoritative name server that defines the contents of a zone in the Domain Name System. Resource records (RRs) in a zone file identify the IP addresses of the hosts (for example, web servers, mail servers) and name servers within the name server’s zone. A zone file can also contain other types of RRs (such as ones containing digital signatures) as determined by the zone owner. The RRs in a zone file enable an authoritative name server to respond definitively to DNS queries about the contents of a zone.

See ICANN Bylaws: https://www.icann.org/en/governance/bylaws.↩︎
See SubPro Final Report: https://gnso.icann.org/sites/default/files/file/field-file-attach/final-report-newgtld-subsequent-procedures-pdp-02feb21-en.pdf.↩︎
See Competition, Consumer Trust, and Consumer Choice Review Final Report: https://www.icann.org/en/system/files/files/cct-rt-final-08sep18-en.pdf.↩︎
See Annex A of the ICANN Bylaws: http://www.icann.org/en/general/bylaws.htm#AnnexA.↩︎
See Contracted Parties website: http://www.icann.org/en/general/consensus-policies.htm.↩︎
See Root Zone Database: http://iana.org/domains/root/db/.↩︎
See Root Zone Database list: http://iana.org/domains/root/db.↩︎
See Final Report on the New gTLD Subsequent Procedures Policy Development Process: https://gnso.icann.org/sites/default/files/file/field-file-attach/final-report-newgtld-subsequent-procedures-pdp-20jan21-en.pdf.↩︎
See GNSO webpage: https://gnso.icann.org/en.↩︎
See UNESCO World Heritage List: https://whc.unesco.org/en/list/&order=region.↩︎
See Geographic Regions section M49: https://unstats.un.org/unsd/methodology/m49/.↩︎
See about the Board: https://www.icann.org/en/board/about.↩︎
See ICANN org website: https://www.icann.org/.↩︎
See List of Accredited Registrars: https://www.icann.org/en/accredited-registrars.↩︎
See 29 January 2016 Program Implementation Review: https://www.icann.org/en/system/files/files/program-review-29jan16-en.pdf.↩︎
See Final Report on the new gTLD Subsequent Procedures Policy Development Process: https://gnso.icann.org/sites/default/files/file/field-file-attach/final-report-newgtld-subsequent-procedures-pdp-02feb21-en.pdf.↩︎