AT-LARGE GATEWAY

At-Large Website

ALAC

RALOs

At-Large Regional Policy Engagement Program (ARPEP)

At-Large Governance

At-Large Reports

Policy Comments & Advice

Working Groups

ICANN Meetings

At-Large Summit (ATLAS III)

At-Large Review Implementation Plan Development

ALAC and RALO Elections, Selections, and Appointments

At-Large Priority Activities - 2021

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 21 Next »

Comment Close
Date		Statement
Name 

Status

Assignee(s)

Call for
Comments Open		Call for
Comments
Close 		Vote
Announcement 		Vote OpenVote
Reminder		Vote CloseDate of SubmissionStaff Contact and EmailStatement Number
10.07.2014Introduction of Two-Character Domain Names in the New gTLD NamespaceADOPTED 13Y, 0N, 2ADev Anand Teelucksingh08.08.201411.08.2014 20:00 UTC11.08.2014 23:00 UTC11.08.2014 23:00 UTC15.08.201416.08.2014 23:00 UTC16.08.2014
Krista Papac
krista.papac@icann.org
AL-ALAC-ST-0814-01-00-EN


For information about this PC, please click here 

Brief Overview

To obtain community input on the proposed amendments to the Registry Agreements of several registry operators to implement a new registry service which would permit the introduction of two-character domain names for registration in the new gTLD namespace resulting from the recently processed Registry Services Evaluation Process (RSEP) requests submitted by several registries.

Comment Period: 12 Jun 2014 - 10 Jul 2014 23:59 UTC
Reply Period: 11 Jul 2014 - 1 Aug 2014 23:59 UTC

Section I: Description, Explanation, and Purpose

Specification 5 (Schedule of Reserved Names), Section 2 of the New gTLD RegistryAgreement addresses reservations of two-character labels. As provided in Specification 5:

All two-character ASCII labels shall be withheld from registration or allocated toRegistry Operator at the second level within the TLD. Such labels may not be activated in the DNS, and may not be released for registration to any person or entity other than Registry Operator, provided that such two-character label strings may be released to the extent that Registry Operator reaches agreement with the related government and country-code manager of the string as specified in theISO 3166-1 alpha-2 standard. The Registry Operator may also propose the release of these reservations based on its implementation of measures to avoid confusion with the corresponding country codes, subject to approval by ICANN.

The New gTLD registry operators noted below submitted requests to ICANN through theRegistry Services Evaluation Process (RSEP) to release certain two-character strings. In total, the requests concern 148 New gTLDs. Implementation of the proposal would require an amendment to the Exhibit A of the respective Registry Agreements, which is being posted for public comment.

Proposal

TLD

Registry Name

Documents

2014011MultipleTLDsDonuts, Inc.; submitted by Binky Lake, LLC*Binky Lake, LLC Request 09 May 2014[PDF, 19 KB]
2014010kredKredTLD Pty LtdKredTLD Pty Ltd Request 11 March 2014[PDF, 18 KB]
2014009bestBestTLD Pty LtdBestTLD Pty Ltd Request 11 March 2014[PDF, 18 KB]
2014008ceoCEOTLD Pty LtdCeoTLD Pty Ltd Request 11 March 2014[PDF, 18 KB]
2014007wikiTop Level Design, LLCTop Level Design LLC Request 11 March 2014 [PDF, 196 KB]
2014006globoGlobo Comunicação e Participações S.AGlobo Comunicação e Participações SA Request 05 February 2014 [PDF, 18 KB]

*Note: Binky Lake, LLC has submitted a RSEP request on behalf of Donuts, Inc. for 143gTLDs.

As part of these requests, each registry operator described which two-character domain names in which it would offer these registrations. These RSEP requests were posted for public information on the Registry Service Evaluation Process webpage, available athttps://www.icann.org/resources/pages/rsep-2014-02-19-en.

See below for a summary of each RSEP request:

  • .ventures - request made 9 May 2014 by Binky Lake, LLC (on behalf of 143 Donuts, Inc. operated TLDs). The proposal requests the release of all two-character ASCII labels that do not appear on the ISO 3166-1 alpha-2 list and for which there is no corresponding government or country-code operator. To avoid user confusion with the two-character country codes, the registry operator noted in its RSEP that "the release of these two-character ASCII labels poses no risk of confusion with any country-code, as this initial request relates only to two character labels where there is no corresponding country code and no relevant government or corresponding country-code operator. Therefore, the restrictions placed on this set of two-character ASCII labels are unwarranted and should be lifted forthwith."

  • .kred - request made 11 March 2014 by PeopleBrowser. which proposes to amend contractual language and implement an equitable phased allocation program that will permit the introduction of two-character domains, while still reserving two-letter domains that correspond to the two-letter country code names found on the ISO-3166 list.

  • .best - request made 11 March 2014 by PeopleBrowser, which proposes to amend contractual language and implement an equitable phased allocation program that will permit the introduction of two-character domains, while still reserving two-letter domains that correspond to the two-letter country code names found on the ISO-3166 list.

  • .ceo - request made 11 March 2014 by PeopleBrowser, which proposes to amend contractual language and implement an equitable phased allocation program that will permit the introduction of two-character domains, while still reserving two-letter domains that correspond to the two-letter country code names found on the ISO-3166 list.

  • .wiki - request made 11 March 2014 by Top Level Design, LLC. The proposal requests approval of the release of all two-letter language identifiers used for the language versions of Wikipedia. Wikipedia's codes are all based off the internationally recognizedISO 639-1 and ISO 639-2 lists. The former is made up of 2 letter codes while the latter are 3 letter codes. In the proposal, the registry operator notes that there may be some overlap between the two-character labels proposed to be released, and the country codes on the ISO 3166-1 list. The registry operator states that, "it should be noted that they are directly taken from another internationally developed and recognized list, theISO 369-1 list of 2-letter language identifiers. As their name implies, both of these lists were developed through the representative and consensus policies of the International Organization for Standardization (ISO), headquartered in Geneva and founded in 1947. Thus, the countries whose ccTLDs may be affected by this initiative, as designated by their ISO 3166-1 list, are already well aware that these ISO 3166-1 identifiers correspond or overlap with an identifier on the ISO 369-1 list; our research shows that this has not been a major issue of concern in the past, and the ongoing, simultaneous use of both lists further implies no such issue."

  • .globo - request made 5 February 2014 by Globo Comunicação e Participações S.A. The proposal requests approval of the registration of non-two-letter two-character domains, which are domains that are composed by two characters that are not letters or by two characters where only one of the character is a letter, provided they are valid according to RFC 2181 and all other applicable RFCs, STDs and BCPs.

As provided by the Registry Services Evaluation Policy, ICANN has undertaken a preliminary determination on whether the proposals might raise significant competition, security or stability issues. ICANN's preliminary review (based on the information provided) did not identify any such issues for these requests.

To note, in its 27 March 2014 Singapore Communiqué, the GAC noted that it "discussed the Brand Registry Group proposal for a streamlined process under an addendum to theRegistry Agreement for the approval of country names and 2-letter and character codes at the second level." The GAC stated that it "has no major concerns about brand owners seeking approval for such names," but that the approval should be "done directly with the countries concerned rather than through a GAC-level operational process." The GAC noted that "individual GAC members could assist with proposals relevant to their particular country if requested," and the GAC suggested that "consideration be given to establishing a register of countries that do not require individual requests to be made." The GAC will be informed of this public comment period.

Section II: Background

In 2006, .name requested for a limited release of reserved two-character names whichICANN staff performed an initial technical evaluation, and referred the matter to the RegistryServices Technical Evaluation Panel (RSTEP) process. The RSTEP panel considered the security and stability impacts of the proposal, which focused on unexpected responses being received from the DNS for both existing and non-existing domains, as well as simply user confusion where the idea of two letter second-level domains is unfamiliar. Based on the report of the RSTEP Panel, internal experts and other public comments, there were no significant security and stability issues related to introduction of the proposal, and the board adopted a resolution on 16 January 2007 to authorize ICANN to amend the .name RegistryAgreement to implement the proposed registry services

From 2007 to 2012, ICANN processed various RSEP proposals related to the release of two-character labels for 11 TLDs (.jobs, .coop, .mobi, .biz, .pro, .cat, .info, .travel, .tel, .asia, and .org).

Approving the amendments to the identified Registry Agreements to implement the proposed new registry service described in the six RSEP proposals would be the first of its kind in the new gTLD space.

Section III: Relevant Resources

Section IV: Additional Information

Staff Contact

Krista Papac
krista.papac@icann.org

 

FINAL VERSION TO BE SUBMITTED IF RATIFIED

Please click here to download a copy of the pdf below.

Error rendering macro 'viewpdf'

com.atlassian.confluence.macro.MacroExecutionException: com.atlassian.confluence.macro.MacroExecutionException: The viewfile macro is unable to locate the attachment "AL-ALAC-ST-0814-01-01-EN.pdf" on this page

Please click here to review the reason for abstention from Fatima Cambronero 

Please click here to review the reason for abstention from Rafid Fatani 

 

FINAL DRAFT VERSION TO BE VOTED UPON BY THE ALAC

The final draft version to be voted upon by the ALAC will be placed here before the vote is to begin.

The At-Large Community has taken note of the many Registry Services Evaluation Process (RSEP) requests submitted to ICANN by many New gTLD Registries applying for exceptions to Specification 5, Section 2 of the New gTLD Registry Agreement (see page 68 of the http://newgtlds.icann.org/en/applicants/agb/agreement-approved-09jan14-en.pdf for the text of Specification 5, Section 2)

Many of the RSEP requests are for the release of two character ASCII labels not on the ISO 3166-1 alpha 2 standard. However, the ISO 3166-1 alpha 2 standard is not a static document ; it will be updated to reflect changes to countries and territories. For example, BQ, CW and SX were added to the ISO 3166-1 alpha 2 standard in late 2010 (see http://www.iso.org/iso/iso_3166-1_newsletter_vi-8_split_of_the_dutch_antilles_final-en.pdf). This gives rise to a potential disparity in the implementation of Specification 5, Section 2 where future countries and territories would be treated differently than those countries and territories on today's ISO 3166-1 alpha 2 list.

However, two character ASCII labels at the second level have been made available for some gTLDs and many ccTLDs. Shorter domains are more desirable to potential registrants and two character ASCII labels can be used for alternative meanings than the one for the ISO 3166-1 alpha-2 standard. For these reasons, absent any DNS-related security or stability issues, the ALAC believes that all the restrictions of two character ASCII labels at the 2nd level within a TLD should ultimately be removed, and has no problem with the current exceptions being approved.


FIRST DRAFT SUBMITTED

The At-Large Community has taken note of the many Registry Services Evaluation Process (RSEP) requests submitted to ICANN by many New gTLD Registries applying for exceptions to Specification 5, Section 2 of the New gTLD Registry Agreement (see page 68 of the http://newgtlds.icann.org/en/applicants/agb/agreement-approved-09jan14-en.pdf for the text of Specification 5, Section 2)

Two character labels at the second level have been made available for some gTLDs and many ccTLDs. Shorter domains are more desirable to potential registrants and two character ASCII labels can be used for alternative meanings than the one for the ISO 3166-1 alpha-2 standard. 

Absent any security or stability issues, the At-Large Community believes there should be no restriction of two character ASCII labels at the 2nd level within the TLD and that Specification 5, Section 2 should be removed.

Many of the RSEP requests are for the release of two character ASCII labels not on the ISO 3166-1 alpha 2 standard. However, the ISO 3166-1 alpha 2 standard is not a static document ; it will be updated to reflect new countries and territories. For example, BQ, CW and SX were added to the ISO 3166-1 alpha 2 standard in late 2010. (http://www.iso.org/iso/iso_3166-1_newsletter_vi-8_split_of_the_dutch_antilles_final-en.pdf).

If RSEP requests are approved by ICANN and the registries make available two character ASCII labels not on today’s ISO 3166-1 alpha 2 list, what happens when future countries and territories with new 2 character codes assigned by ISO want the same protections as per Specification 5, Section 2 and find such codes already allocated by the registries?

Similarly, how would the names of future countries and territories be protected as per Specification 5, Section 4 (Country and Territory Names) of the New gTLD Registry Agreement?

Methods of addressing this disparity of treatment between current and future countries and territories should be established before such RSEP requests are approved by ICANN.

 

  • No labels