Skip to main content
Resources

Protection of IGO and INGO Identifiers in All gTLDs Policy

Please note that the English language version of all translated content and documents are the official versions and that translations in other languages are for informational purposes only.

On 21 February 2024, an updated version of the Policy was published to reflect changes required to implement the Registration Data Policy. Click here to view the updated version of this policy. You may view the changes in the redline.

On 18 February 2020, this policy was revised to account for implementation of the Board adopted policy recommendations for Red Cross & Red Crescent names. See the redline against the previous version.

  1. Scope

    This Consensus Policy covers Generic Names Supporting Organization (GNSO) policy recommendations adopted by the ICANN Board on 30 April 2014 and 27 January 2019 concerning protection for certain names of the Red Cross, International Olympic Committee (IOC), International Governmental Organizations (IGOs), and International Non-Governmental Organizations (INGOs) which are not inconsistent with advice from the Governmental Advisory Committee (GAC) to the ICANN Board.

  2. Policy Effective Dates

    2.1. For those Red Cross, IOC, and IGO names approved by the Board on 30 April 2014, the Policy is effective for all gTLD Registry Operators and ICANN-accredited Registrars no later than 1 August 2018.

    2.2. For those INGO names approved by the Board on 30 April 2014, the Policy is effective for all gTLD Registry Operators and ICANN-accredited Registrars 12-months after the release of the INGO Claims System Specification.

    2.3. For those Red Cross & Red Crescent names approved by the Board on 27 January 2019 (i.e. Section 4 titled "Red Cross: The International Red Cross and Red Crescent Movement and its components" of the reserved names for new gTLDs list), the Policy is effective for all gTLD Registry Operators and ICANN-accredited Registrars no later than 1 August 2020.

    Transitional Provision: Until 1 August 2020 or until a gTLD Registry Operator completes its implementation of the list of Red Cross & Red Crescent names that were approved by the Board on 27 January 2019, whichever first occurs, the gTLD Registry Operator MUST continue to reserve the names included on the Red Cross & Red Crescent Identifier List as of 1 August 2018. For the avoidance of doubt, the updated Red Cross & Red Crescent Identifier List will replace the 1 August 2018 list in its entirety as of 1 August 2020. Links to both lists are available on the Reserved Names for gTLDs.

  3. Definitions. For purposes of this Policy, the following definitions will apply:

    3.1. Reserve means to withhold from registration or to allocate to Registry Operator, but not register to third parties, delegate, use, activate in the DNS or otherwise make available a character string within the TLD.

    3.2. INGO Claims Notification means a notice containing the information of the relevant INGO, which is displayed by the Registrar to a potential domain name registrant attempting to register a domain name that is an exact match of a name on the INGO Identifier List.

    3.3. INGO Claims Service refers to a process by which a domain name registrant and the relevant INGO are notified that the domain name being registered is an exact match of the INGO's name on the INGO Identifier List.

    3.4. INGO Claims System refers to a system that allows contracted parties to access the database of DNS labels corresponding to the INGO Identifier List and provides registration information for the associated processes for notifications.

    3.5. INGO Identifier List refers to a list containing second level, exact match, full names of protected INGOs and their corresponding DNS labels that are permitted to participate in the 90-day INGO Claims Notification process.

    3.6. Red Cross, IOC and IGO Identifier List refers to a list containing second level, exact match, full names of protected Red Cross and IOC organizations, IGOs and their corresponding DNS labels designated to receive certain protection under this policy.

    3.7. The keywords "MUST" "MUST NOT" "SHOULD", "SHOULD NOT", andMAY" in this document are to be interpreted as described in RFC 2119, which is available at http://www.ietf.org/rfc/rfc2119.txt.

  4. Red Cross, IOC and IGO Full Name Reservation at the Second-Level

    4.1. Reservation. All gTLD Registry Operators MUST either Reserve from registration or allocate to Registry Operator the second-level domain names corresponding to the DNS label(s) of all identifiers recorded on the Red Cross, IOC, and IGO Identifier List found on the Reserved Names for gTLDs1. Upon conclusion of Registry Operator's designation as operator of the registry for the TLD, all such protected identifiers shall be transferred as specified by ICANN. Registry Operator may self-allocate and renew such names without use of an ICANN accredited registrar, which will not be considered Transactions for purposes of Section 6.1 of the Agreement.

    4.2. Existing Registrations in gTLDs. If a domain name, containing an exact match name from the Red Cross, IOC, and IGO Identifier List, is registered before this Consensus Policy effective date or before the label is added to the Red Cross, IOC and IGO Identifier List, the Registry Operator MUST permit renewals of the domain name and MUST permit transfers of the domain name. If a domain name, containing an exact match name from the Red Cross, IOC and IGO Identifier List, is registered before the label is added to the Red Cross, IOC and IGO Identifier List, and is subsequently deleted, the Registry Operator MUST Reserve the domain name from registration or allocate the domain name to Registry Operator.

    4.3. Registration by Red Cross, IOC and IGO Organizations. Red Cross, IOC and IGO organizations MAY request registration of domain names matching their identifiers otherwise withheld from registration at the second-level under this Policy. Registry Operators and Registrars MUST provide a method for registration of the reserved names by Red Cross, IOC and IGO organizations.2

    4.4. Red Cross, IOC and IGO Identifier List Changes: Names may be added to or deleted from the Red Cross, IOC and IGO Identifier List upon ten (10) calendar days' notice from ICANN to Registry Operator. ICANN will consult with the GAC and GNSO in relation to proposed changes to the names on the Red Cross, IOC, and IGO Identifier List on the Reserved Names for gTLDs.

  5. INGO Claims Services at the Second-Level

    Scope. The INGO Claims Service only applies to gTLDs delegated after this Consensus Policy effective date. Registry Operators and Registrars MUST provide the INGO Claims Services, as described below and as specified in the INGO Claims System Specification3, for INGO names and their corresponding DNS Label(s) that are an exact match on the INGO Identifier List. The INGO identifier names and corresponding DNS label(s) are found on the INGO Identifier List4.

    5.1. INGO Claims Service

    5.1.1. Registry Operator MUST provide the INGO Claims Service for the first ninety (90) calendar days for which the domain name is available for registration or prior to Effective Allocation5 if the domain name is not going to be available for registration during General Registration6.

    5.1.2. During the registration process, prior to the execution of the registration, the Registrar MUST notify the potential registrant that the name requested for registration is an exact match of a name on the INGO Identifier List and that the name MAY be subject to ICANN's Protection of IGO and INGO Identifiers in All gTLDs Policy by displaying an INGO Claims Notification.

    5.1.3. Registrars MUST clearly and conspicuously display the INGO Claims Notification, containing the claims notice information, to the potential domain name registrant and inquire as to whether the potential domain name registrant wishes to continue with the registration.

    5.1.4. The INGO Claims Notification MUST be provided by the Registrar at the time of potential registration in real time, without cost to the prospective domain name registrant, and MUST be in the form specified in the INGO Claims Notification in Appendix A.

    5.1.5. The INGO Claims Notification MUST require an affirmative confirmation by the potential domain name registrant to continue with the registration (i.e. acceptance box MUST NOT be pre-checked).

    5.1.6. The INGO Claims Notification MUST be provided by the Registrar to the potential domain name registrant in English and SHOULD be provided by the Registrar to the potential domain name registrant in the language of the registration agreement.

    5.1.7. Upon registration, the Registry Operator MUST provide a notification in the INGO Claims System that the name in the INGO Claims System has been registered. The INGO Claims System then generates a notice to the relevant INGO that their name has been registered. An example of the INGO Notification of Registered Name is provided in Appendix B.

    5.1.8. During the INGO Claims Period, if the Registry Operator has established IDN variant policies for Effective Allocation of domain names in the TLD, the Registry Operator MUST provide notification for all labels in a variant set.

    5.1.9. Registry Operators MUST complete successful integration testing with the INGO Claims System prior to providing the INGO Claims Service.

    5.1.10. INGO Identifier List Changes. Names may be added to or deleted from the INGO Identifier List. ICANN will consult with the United Nations Department of Economic and Social Affairs about proposed changes to INGO names on the INGO Identifier List.

Appendices

Appendix A: INGO Claims Notification displayed to Potential Domain Name Registrant

You have received this INGO (international non-governmental organization) Claims Notification because you have applied for a domain name, which is an exact match with at least one INGO name on the INGO Identifier List.

You may or may not be entitled to register the domain name depending on your intended use and whether it is the same or significantly overlaps with the records listed below.

Please read the information below carefully. If you have questions, you may want to consult an attorney or legal expert for guidance.

If you continue with this registration, you represent that you have received and you understand this notice and to the best of your knowledge, your registration and use of the requested domain name will not infringe on any legal rights that the INGO may have in its name. The following record or records are listed on the INGO Claims List:

INGO Official Name: <ingoNotice:ingoName>
     INGO English Name: <ingoNotice:ingoEnglishName>
     INGO URL: <ingoNotice:ingoURL>


INGO Official Name: <ingoNotice:ingoName>
     INGO English Name: <ingoNotice:ingoEnglishName>
     INGO URL: <ingoNotice:ingoURL>7
...

Appendix B: INGO Notice of Registered Name sent to Protected Organization

Dear एक उदाहरण,

You have received this Notice of Registered Name because the following domain name(s) matches your INGO record(s) on the INGO Identifier List and have been registered during the first 90 days the domain name was available for registration.

INGO Official Name: एक उदाहरण

INGO English Name: Example One

Domain Name: exampleone.example

Creation Date: 2013-09-16T14:21:26.648Z

Note: In certain circumstances, one or more of these domain names may no longer be registered. A domain name can be deleted at any time. Additionally, a domain name that is deleted during the first five calendar days of registration becomes immediately available again for registration. You may receive multiple Notices of Registered Name under these or similar conditions.

For additional information, please refer to the Registration Data Directory Services (Whois) record for the domain name at the applicable registry. A list of gTLD registries and a link to their Whois is available at https://www.icann.org/en/resources/registries/listing.

Implementation Notes

  1. DNS Label Conversion Rules

    Protected identifiers that do not conform to the framework of DNS permissible characters will be converted into DNS labels that contain only letters, digits and hyphens. Some names on the Red Cross, IOC, IGO, and INGO Identifiers Lists include alternative language characters used in the creation of Internationalized Domain Names as well as blanks or space characters that are impermissible in DNS labels. Thus, DNS label conversion rules were developed to convert these names into DNS permissible equivalent characters (for example, the protected organization "Africa Unite" will be converted to "africa-unite" and "africaunite", and "Olímpico" will be converted to "xn--olmpico-8ya" but NOT to "olimpico".) The DNS also places restrictions on the length of the label. As a result, DNS labels will not be assigned to protected identifiers that exceed the number of permissible characters in a label (for example, the length of the label for the protected organization "Chamber of Commerce, Industry and Production of the Argentine Republic" will be eligible for INGO Claims for the 60-character label "chamberofcommerceindustryandproductionoftheargentinerepublic", but not for the 69-character string "chamber-of-commerce-industry-and-production-of-the-argentine-republic" is longer than the maximum permitted length of 63 characters).

    1.1. Matching of Red Cross, IOC, IGO, and INGO Identifiers to DNS labels. Protected identifiers will be converted into DNS labels for protection under section 1, 2 or 3 of this policy according to the following rules:

    1.1.1. Convert each identifier to a UTF-8 string, lowercase it, remove any starting or ending hyphens, and normalize it to Normalization Form C.8

    1.1.2. If the resulting string is a valid LDH9 DNS label,10 no further conversion is needed, the string is the resulting DNS label. If the string is composed exclusively of US-ASCII characters, two labels will be generated: (1) a label resulting from removing non-LDH characters; and (2) a label resulting from substituting any non-LDH character with a hyphen. In both cases, any cluster of two or more contiguous hyphens will be substituted by only one hyphen.

    1.1.3. If the string is a valid U-label,11 the DNS label will be the corresponding A-label.12

    1.1.4. If the string is not composed exclusively of US-ASCII characters, two pre-labels will be generated: (1) a pre-label resulting from removing invalid IDNA2008 characters; and (2) a pre-label resulting from substituting any invalid IDNA2008 character with a hyphen. In both cases, any cluster of two or more contiguous hyphens will be substituted by only one hyphen and then converted to A-label form.

    1.1.5. For any other case, or if the length of any string produced by this algorithm is not between 1 and 63, there will be no resulting DNS label.

  2. DNS Label Format

    2.1. Resulting DNS Labels from the conversion will be provided to the registry operator by ICANN in machine-readable format for those labels requiring reservations by the registry operators.

    2.2. To expedite the process of any changes to the list, ICANN will ensure that the notification to Registry Operators is broken down into at least two parts or that its data fields denote: i) DNS labels added to the list; ii) DNS labels removed from the list.

  3. Source of the INGO Identifier List

    3.1. Names on the INGO Identifier List are provided by the United Nations Department of Economic and Social Affairs via the United Nations Economics and Social Council.13

  4. Rights Protection Mechanism Requirements Applicability

    4.1. Section 2.4.3 of the Rights Protection Mechanism Requirements14 (RPM) does not apply to the second-level domain names corresponding to all identifiers recorded on the Red Cross, IOC and IGOs Identifier List. 

Background

This Policy Development Process (PDP) was initiated to develop policy recommendations for the provision of protection for identifiers of certain IGOs and INGOs, including the Red Cross and the IOC.

This Consensus Policy covers policy recommendations adopted by the ICANN Board on 30 April 2014, which were not inconsistent with GAC advice (please refer to: https://www.icann.org/resources/board-material/resolutions-2014-04-30-en#2.a). Outstanding recommendations which were inconsistent with GAC advice will be addressed as appropriate once differences are reconciled between the ICANN Board, the GAC and the GNSO.

The adopted recommendations relate to protection at the top and second level for specific Red Cross, IOC and IGO names (with an Exception Procedure to be designed for the relevant protected organizations), protection at the top level for specific INGO names and a 90-days Claims Notification process at the second level for certain other INGO names.

This Policy provides requirements for contracted parties with respect to second-level DNS labels. The adopted recommendations also relate to the delegation of gTLD strings. With respect to the delegation of gTLD strings, ICANN MUST reserve the gTLDs corresponding to the above-mentioned identifiers, until the gTLDs are applied for by the relevant protected organization.


1 The Reserved Names List is available here https://www.icann.org/resources/pages/reserved-2013-07-08-en

2 Registrations in the TLD remain subject to Registry Operator's registration restrictions, including community-based eligibility requirements and Public Interest Commitments and IDN Tables.

3 The INGO Claims Specification is available here: https://www.icann.org/resources/pages/ingo-claims-system-specification-2018-01-16-en

4 The INGO Identifier List is available here: https://www.icann.org/resources/pages/ingo-identifier-list-2018-01-16-en

5 The definition of Effective Allocation is available here: https://tools.ietf.org/html/draft-ietf-regext-tmch-func-spec.

6 The definition of General Registration is available here: http://newgtlds.icann.org/en/about/trademark-clearinghouse/rpm-requirements-14may14-en.pdf

7 Elements between the less than and greater than symbols refer to the XML elements in the XML notice described in the INGO Claims Specification. The XML notice is retrieved from the INGO Claims System by the Registrar in order to produce the notice shown to the Registrant.

8 The Unicode Consortium, "Unicode Standard Annex #15: Unicode Normalization Forms", September 2009, http://www.unicode.org/reports/tr15/.

9 Letter Digit Hyphen. For more information, please refer to RFC 5890 section 2.3.1 (https://tools.ietf.org/html/rfc5890).

10 For more information, refer to RFC 1034 section 3.1. https://www.ietf.org/rfc/rfc1034.txt

11 See RFC 5890. https://tools.ietf.org/html/rfc5890

12 See RFC 5890. https://tools.ietf.org/html/rfc5890

13 UNDESA is the United Nations Department of Economic and Social Affairs that manages the ECOSOC list (https://www.un.org/ecosoc/en/home) of INGOs (https://www.un.org/development/desa/en/).

14 The Right Protection Requirements is available here; http://newgtlds.icann.org/en/about/trademark-clearinghouse/rpm-requirements-14may14-en.pdf

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."