Draft - IGO/INGO Identifiers Protection Policy

IGO/INGO Identifiers Protection Policy [1]

This Consensus Policy covers policy recommendations adopted by the ICANN Board on 30 April 2014, which were not inconsistent with GAC Advice.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in RFC 2119, which is available at http://www.ietf.org/rfc/rfc2119.txt .

Consensus Policy Effective Date :  This Policy is effective for all gTLD Registry Operators and ICANN-accredited Registrars beginning on 1 August 2017.

  1. Red Cross, IOC, and IGO Full Name Reservation at the Second-Level
    1. Reservation. All gTLD Registry Operators SHALL either withhold from registration or allocate to Registry Operator the second level DNS labels corresponding to all identifiers recorded on the Red Cross, IOC, and IGO Identifier List found here: https://community.icann.org/display/IIPIRT/Protected+Identifier+Lists+-+Draft+Page+for+IRT+Use+Only , unless otherwise specified.
    2. Existing Registrations   in gTLDs. If a domain name, containing a matching label from the Red Cross, IOC, and IGO Identifier List, is registered before the label is added to the list , the Registry Operator SHALL permit renewal or transfer of the domain name. If a domain name, containing a matching label from the Red Cross, IOC, and IGO Identifier List, is registered before the label is added to the list , and is subsequently deleted, the Registry SHALL withhold the domain name from registration or allocate the domain name to Registry Operator.
    3. Registration by Red Cross, IOC, and IGO Organizations. Relevant protected organizations MAY request registration of a domain name matching their identifier otherwise reserved at the second-level of this Policy. Registry Operators and Registrars MUST provide a method for registration of the reserved names by Red Cross, IOC, and IGO organizations. [DC1]
    4. Identifier List Changes: Names may be added or deleted to the Protected Identifier List upon ten (10) calendar days notice from ICANN to Registry Operator. ICANN will consult with the GAC about changes to the Red Cross, IOC, and IGO Names on Identifier List.
  2. INGO Claims Service at the Second-Level
    1. Scope. R egistry Operator MUST provide the INGO Claims Services for the first ninety (90) calendar days name is available for registration. The domain names delegated by any gTLD Registry Operator after this Policy Effective Date that contain a matching second level label on the INGO Identifier List will be subject to the 90-day INGO Claims Services. Registrars MUST provide INGO Claims Notification service for Identifiers on the INGO Identifier List as described in section 2.2. The INGO identifier names and DNS labels on the INGO Identifier List are provided here: https://community.icann.org/display/IIPIRT/Protected+Identifier+Lists+-+Draft+Page+for+IRT+Use+Only
    2. 90-day INGO Claims Services.  The 90-day INGO Claims Service under this policy, is a process by which a registrant and the INGOs are notified that the domain name being registered contains a label on the INGO Identifier List. R egistry Operator MUST provide the Claims Services for the first ninety (90) calendar days name is available for registration. Registrars MUST clearly and conspicuously display the Claims Notice, 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. The Claims Notice 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 Claims Notice Form (see Appendix A) . The Claims Notice 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). The Claims Notice 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.
    3. INGO Claims Notification .
      1.    Registrant Notification . During the registration process, prior to the execution of the registration, the Registrar SHALL notify the potential registrant that the identifier requested for registration is an exact match of a label on the INGO list and that the identifier MAY be subject to ICANN’s IGO/INGO Identifiers Protection Policy. The content of this notification SHALL be in accordance with the INGO Claims Notice in Appendix A.
      2.    Notification of Registered Name to INGOs .  Upon registration, the Registry Operator SHALL notify the INGO Claims System [2] that the name in the INGO Claims System has been registered. The INGO Claims System then notifies the INGO that their identifier has been registered. The notification SHALL be in accordance with the INGO Notification of Registered Name in Appendix B.
    4. Identifier List Changes: Names may be added or deleted to the Protected Identifier List upon ten (10) calendar days notice from ICANN to Registry Operators and Registrars. ICANN will consult with the UNDESA [3] about changes to the ECOSOC [4] list of the International Non-Government Organizations (INGO) Identifiers in the INGO Identifier List.

Appendices

Appendix A:  INGO Claims Notice

[Must be provided, at a minimum, in English and the language of the registration agreement]

You have received this INGO (international non-governmental organization) Notice because you have applied for a domain name which matches at least one INGO record in the INGO Identifier Protection 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 [number] of records are listed in the INGO Claims List:

INGO Official Name: <claimINGO:name>

INGO English Name: <claimINGO:englishName>

INGO URL: <claimINGO:url>

INGO Address: <claimINGO:addr>

INGO Phone: <claimINGO:voice>

INGO Fax: <claimINGO:fax>

INGO Email: <claimINGO:email>

INGO Official Name: <INGO:name>

INGO English Name: <INGO:englishName>

INGO URL: <INGO:url>

INGO Address: <INGO:addr>

INGO Phone: <INGO:voice>

INGO Fax: <INGO:fax>

INGO Email: <INGO:email>

Appendix B :  INGO Notice of Registered Name

Dear <tmpl_var name="user_name">,

You have received this Notice of Registered Name because the following domain name(s) matching your INGO record(s) in the INGO Identifier Protection List have been registered during the claims period of a new gTLD.

<tmpl_loop name="body">

<tmpl_var name="mark_name"> (<tmpl_var name="mark_handle">) : <tmpl_var name="idn"> <tmpl_if name="domain_name">(<tmpl_var name="domain_name">)</tmpl_if> <tmpl_var name="reg_date">

</tmpl_loop>

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 Names under these or similar conditions.

For additional information, please refer to the Whois record for the domain name at the applicable registry. A list of gTLD registries is available at http://www.icann.org/en/resources/registries/listing .  

If you encounter any issues, please do not hesitate to contact our customer support service provided to you by clicking on the "Support" button after signing in to the Protected Identifier Claims System web interface.

We thank you for your trust.

Appendix C :  DNS Labels Conversion Rule

1.1.    Matching of protected 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. [5]

1.1.2.        If the resulting string is a valid LDH [6] DNS label, [7] 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, [8] the DNS label will be the corresponding A-label. [9]

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 label produced by this algorithm is not between 1 and 63 there will be no resulting DNS label.

Appendix D: Introduction and Background:

This Policy Development Process (PDP) was initiated to develop policy recommendations for the provision of protection for identifiers of certain International Governmental Organizations (IGOs) and International Non-Governmental Organizations (INGOs), including the Red Cross/Red Crescent Movement (RCRC) and the International Olympic Committee (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 covered 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 RCRC, IOC and IGO names (with an Exception Procedure to be designed for the affected 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 SHALL reserve the gTLDs corresponding to the above-mentioned identifiers, until the gTLDs are applied for by the relevant protected organization.

At the time this Policy was implemented, some of the adopted recommendations, were inconsistent with GAC advice . Accordingly, the inconsistent recommendations will be implemented when the inconsistencies are reconciled between the ICANN Board, the GAC and the GNSO.


[1] This Consensus Policy covers policy recommendations adopted by the ICANN Board on 30 April 2014, which were consistent with GAC Advice (please refer to: https://www.icann.org/resources/board-material/resolutions-2014-04-30-en#2.a ).

[2] INGO Claims System is a database of DNS labels corresponding to the INGO protected identifier

[3] UNDESA is the United Nations Department of Economic and Social Affairs that manages the ECOSOC list of International Nongovernmental Organization (INGO) https://www.un.org/development/desa/en/

 

[4] ECOSOC: United Nations Economics and Social Council https://www.un.org/ecosoc/en/home

 

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

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

[7] For more information, refer to RFC 1034 section 3.1.

[8] See RFC 5890.

[9] See RFC 5890.


[DC1] How would this work?  Discussion point with IRT