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
AL-ALAC-ST-0814-01-01-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

 

FINAL VERSION TO BE SUBMITTED IF RATIFIED

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

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

22 Comments

  1. Various registries for multiple gTLDs are applying for exceptions to Specification 5, Section 2 of the New gTLD Registry Agreement ("Specification 5") with some registries suggesting the release of 2 character ASCII labels not on the current ISO 3166 standard would suffice. 
    While this seems harmless, there is a possibility of new countries and territories being created, and then allocated a new two character ASCII label by ISO 3166/MA (see https://web.archive.org/web/20111101141651/http://www.iso.org/iso/country_codes/iso-3166-1_decoding_table.htm ).

    Any new country or territory created after 2014 would therefore not receive the same protection as those in the 2014 ISO 3166-2 list and would find that their new 2 character label is "given away", should they wish for their 2 character ASCII label to be protected, as per Specification 5.

    Now, should the principle established by Specification 5 protecting 2 character ASCII labels even be in the New gTLD Registry Agreement? Many would say, especially given the prevalence of two character labels in existing TLDs like .com, .org and .net that this principle shouldn't be applied to new gTLDs. 
    However, this (IMO) is a separate issue to the question being asked for in the public comment. 
    If Specification 5 is meant to defend the principle that country codes in ISO 3166-2 should be protected in new gTLDs, then it should be enforced to ensure future countries and territories with new 2 character ASCII labels are protected in the same way as those territories and countries in today's ISO 3166-2 list.

    Therefore, the proposals by Donuts for 143 of its new gTLDS, .kred by KredTLD Pty Ltd, .best by BestTLD Pty Ltd and .ceo by CEOTLD Pty Ltd. should be turned down in keeping with the principle of Specification 5. 

    The proposal by .wiki by Top Level Design LLC which specifies that the two character ASCII labels will only be used for languages identified by ISO 639-1 does appear to meet the threshold that the use will not be confused with the corresponding country codes, as per Specification 5 and could be approved.
    Similarly, the proposal by .globo by Globo Comunicação e Participações S.A which proposed the use of two character ASCII labels that are not letters or by two characters where only one of the character is a letter are labels that would not be used by ISO 3166-2 and could be approved.
  2. While not disagreeing with Dev's careful analysis, I do have a comment and a question:

    • Similar requests have already been approved for other TLDs. Refusing these could be seen as inequitable.
    • If the GAC and governments are not opposing such changes, is there really a user component that implies that we should comment?

     

  3. DEV The question that focuses the subject and then transcribe says to see:

    If Specification 5 is intended to defend the principle that the ISO 3166-2 country codes must be protected in the new gTLDs, then you must meet to ensure that countries and future territories with new tags 2 ASCII characters are protected from same way as the regions and countries in today.

    Specification 5 is transcribed at the site
    https://community.icann.org/display/alacpolicydev/At-Large+Introduction+of+Two-Character+Domain+Names+in+the+New+gTLD+Namespace+Workspace:

    This Specification 5 says:

    "All the labels of two ASCII characters will be excluded from enrollment or assignment to Registry Operator in the second level in the TLD. Such labels may not be active in the DNS, and may not be delivered for registration to any person or entity not registry operator if such label strings two characters may be it released to the extent that the Registry Operator reaches agreement with the related government and the head of country code string as specified in the ISO 3166-1 alpha-2. Registry Operator may also propose release of these reservations based on the introduction of measures to avoid confusion with the codes of the countries concerned, subject to the approval of ICANN. "

    It is clear that the wording of this clause is restrictive. It also has not revealed requirements are met: Missing accordance with the related government and the country manager of the chain code. Also appears not fulfilled the measures applied in each country to avoid confusion with country codes as required by the standard.

    I further understand that the request for all brands indiscriminately, as is done request is not covered by the standard. It is a restrictive rule and assumes that calls to a country and not globally.

    Specification 5 is the first purely protective of country codes. Allowed only by exception and with many requirements, with the agreement of the country besides himself. The criterion is clearly to give prevalence to the country domain. Demands that also met the above requirements presented measures to avoid confusion with the country itself. It is very restrictive and gives a very strict protection for country codes.

    From the point of view of the end user country code on the Internet is increasingly important for the sense of identity of a people, an idiosyncrasy, a paradigm, also with regard to himself and his country. Something like the flag of each country. This affirms confidence in global recognition through the local as part and within the global.

     

     

  4. I am a bit confused on several levels.

    First:

    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.  

    I have certainly heard that comment from some (notably Evan), but I did not think that it was generally agreed upon. I thought there were a number of people (Dev included) that had concern over possible confusion, specifically for readily recognizable ccTLD strings.

    The final conclusion, that IF Spec 5.2 is maintained and the exceptions granted, then:

    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.

    I like throwing down a gauntlet as much as anyone, but ICANN is certainly not going to repossess such codes in they are added to the list. So what this translated to is if a name is added, it can no longer be registered (but could be renewed). If that is what we are suggesting, we should say so clearly. I have not read the contract carefully in this respect, but I suspect that is already implied (since at new registration time, the code would be restricted).

    Lastly, I am a bit unsure if we really want to raise the issue of the unprotected new country names.

    Alan





     

    1. Dear Alan:

      I had mentioned something about Dev in conjunction with the interpretation of paragraph 5.2. This in the sense of protecting and reserve point for country codes two letters. On the one hand, the wording of the provision in context is clear.

        The rule is restrictive and has two requirements, in exceptional cases, be authorized to use two letters to applicants who are not country code.

      The underlying rationale for this is to avoid confusion about country codes, simplifying identification to the fullest. The restriction that applicants from other areas is not seem as bad because they have all the rest of the alphabet and letter combinations to choose from.

      Even if a contrary approach, as I said it seems contrary to the rule in cases not requested saw were satisfied these two requirements are accepted.

         The repeal of the rule that is mentioned could be a solution for applicants, but I understand that would not be relevant.

      Recognition of the community that is each country is a recognition of the autonomy of the countries that still exist and function, which have different laws generally respond to different idiosyncrasies and towns. Today can not remove national borders completely.

      The comments that you heard, in my opinion, do not take into account that the point at issue not only has the rule is in effect (5.2) and only the technological, but also exist in this other rights violated by not respecting or remove that rule.

      Are the rights of communities of users who are identified with their country's national identity, which still exists and is very strong in many cases, human rights beyond economic interests or other well beyond the obvious globalization .

        The other, which is important in the case: even if the opposite conclusion is accepted, applicants are now presented did not justify having met the two requirements that are required to lead to this exception. At least that does not arise from the information we have.

      Dev was going to do a draft declaration to present on that basis. It is the last information I have about it.

       

       

       

  5. I am also a bit confused in a similar sense than Alan.

    Third paragraph of the draft states: “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”.

     

    Specification 5, Section 2 states: “2. Two-­‐character labels. All two-­‐character ASCII labels shall be withheld from registration or allocated to Registry 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 the ISO 3166-­‐1 alpha-­‐2 standard ”.

     

    Fifth paragraph states: “…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?”

    I find some contradiction between third and fifth paragraph. First you recommend that the Specification 5, Section 2 should be removed (in my understanding this specification is protecting the new countries and territories) and then you show concern about new countries and territories.

    Do I understand this draft in a wrong sense? I will be happy to receive clarifications to understand it correctly.  

    1. The original specification is somewhat confusing in its own right.

      Spec 5.2 says that ALL two-letter combinations shall not be registered as 2nd level domains. BUT that a two-letter string that corresponds to a ccTLD may be used by the registry operator IF they get the agreement of the related government and ccTLD manager.

      The exemptions being applied for generally are to be able to register 2-letter strings that are not in the 3166 table.

      The first statement (our paragraph 3) says that At-Large believes there should be NO 2-letter strings protected. Although this corresponds to *my* belief, I was questioning whether it was in fact a general belief.

      If I understand it correctly, the last part of the draft statement, says that if Spec 5.2 stays, and if ICANN grants the RSEPs, then we are pointing out that newly adopted ccTLD (ie those added to 3166 at some time in the future) will not have the same protection as those that are there today.

      It also points out that full country names that do not yet exist, will similarly have no protection if the names are registered before the country comes into existence.

       

      1. Hello Alan

        Indeed, you are correct. Re: the statement that should be no 2 ASCII letter strings protected at the 2nd level, I think this is the sentiment by many in At-Large, judging from the comments here and on mailing lists for the reasons given (its already happening at ccTLDs at the 2nd level, shorter domains are desirable to potential registrants, and the 2 letter strings are used for alternative meanings that those for the ISO list)

        The 2nd concern is regarding the logic being used for the many RSEP requests which releases 2 letter strings not in the current ISO list, on the pretext that this would satisfy Specification 5 Section 2 ("based on its implementation of measures to avoid confusion with the corresponding country codes").

        What I was attempting to say the registries' proposed implementation is not sufficient (in my opinion). The the ISO list is not static and is updated to reflect changes in countries and territories. Such future countries and territories could find themselves without the protections given to existing countries and territories regarding their two letter strings at the 2nd level. It would give rise to some countries and territories being protected and some countries and territories not protected. 

        Reviewing the GNSO NewTLDs Committee Reserved Names Working Group Report in 2007, I see that for Recommendation 7 ("Two Letters at the Top Level"), this was clearly done ("We recommend that the current practice of allowing two letter names at the top level, only for ccTLDs, remain at this time."). 

        An email from Kim Davies explains the point clearly why this should happen http://forum.icann.org/lists/gnso-rn-wg/msg00163.html and has happened.

        Recommendation 8 ("Any Combination of two letters, digits at the second level"), says "We recommend that registries may propose release of two letter and/or digit strings at the second level, provided that measures to avoid confusion with any corresponding country codes are implemented." which is the language used in Specification 5, Section 2. 


        It makes no sense to treat countries and territories differently, so if principles are being applied in registry agreements to protect countries and territories (both the names and ISO codes at the top level and the ISO codes and country names at the 2nd level), then the protections should apply equally for all countries and territories, current and future. If protections can't be established for all current and future countries and territories, then such implementations principles should be re-considered.

        Granting the RSEP requests today would result in confusion in the future as to why ICANN, through its registry agreements, is seemingly protecting some countries and territories and ignoring others. Hence my suggestion in the statement ("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.")

        Dev Anand


        P.S  I do greatly appreciate the conversation on this topic.

        1. I agree that it is possible that for some future territory/country, they may find that their two-character code is already allocated in some gTLDs, and that at some level this is "unfair".

          I am not particularly concerned about it, because as has been pointed out, even current well-known ccTLD codes are already used for some (grandfathered) TLDs. The new ones, which almost always are codes that bear little resemblance to the actual territory name, are not likely to cause mass confusion.

          The suggestion of some (including me!) that we do not really need any such 2-letter protection at the 2nd level would cause far more confusion (although since I would support the change, I don't think it is all that onerous).

          So we should either agree with accepting the RSEPs, and accept a bit of potential confusion for some future country/territories, or reject them due to this possible confusion (and accept the unlevel playing filed where some TLDs have the exemption and other don't.

          All I am saying is pick one position, or decide to not comment.

           

  6. Fátima:

    I agree with you hat the interpretation is confusing and seems contradictory. Is subject to various interpretations, one of which may be that of Alan, given what I said before the exception I mentioned already in section 5.2 of the current statement

     But exactly the problem is this. One thing is to admit the situation as an exception and only because two conditions involving the consent of the country concerned itself together in two ways: an agreement with the government of the affected country and another administrator point country. The double standard is being violated constraint because a vested right of a country. The legal rule in these cases is that you can only affect the law with the consent of the affected. Paragraph 5.2 is only the particular expression of that legal standard. 


    Another different thing is what is proposed to generalize without requiring the extent that double consent. Removing the requirements and generalize the procedure, would be leaving aside the rights of communities of users from different countries, which are not only economic but of national identity, location of their culture among others. This change order to benefit other parties can respond to any type interests, including economic. I do not disagree with the importance of economic and individual interests. But I understand always within limits recognition of rights of communities that represent a more general interest such as national communities. This is my humble personal opinion.

  7. Hello all,

    I have kept my own view and now shared them so far so as to see where the debate took us.

    I personally do not understand the existence of this rule in the Applicant Guidebook. Coming from a country which had .co.uk and .ac.uk, never understood to be Colombia or Ascension Island, having used ms.com never thought as Montserrat and, back in the early days of Internet, one of the earliest networks called cs.net, never confused for Czechoslovakia.

    And if we start making provisions for 2-character codes of potential new countries, where are we with fb.com ?

    And there are many more, with some prominent companies listed on: http://en.wikipedia.org/wiki/Single-letter_second-level_domain   — and this is only the .com space!

    In fact, the use of 2nd level domain as a country code commercialisation stems solely from one organisation marketing those. This is also listed on the WIKI page.

    I do not understand why new gTLDs have new restrictions applied on them that are currently not in operation for legacy gTLD operators. Was there ever a problem to start with? In my view, this is a case of the Applicant Guidebook focussing and spending time on stuff that doesn't matter whilst completely ignoring blatant public interest issues elsewhere.

  8.  i also recognise there is some good points on Dev statement, but at the same time, other TLDs, and even ccTLDs ( not subject to other rules than SS, have been using this solution ( .bb.br  here for instance)  for a while. The most relevant issue is that this does not bring any concern  related to stability and security. Regarding eventual new countries created after this decision, since there is no real direct conflict being second level with the new cc itself , I believe that  information to this new countries that a named TLD is using as second level there short version of the name for me is enough. TLDs using those then became alerted that in the future, may new county demands some change. I believe this is the maximum ICANN can state to be fair with the new ones that are demanding such convenience versus the old ones already using the two characters 

  9. As pointed out in the discussions above, the proposal to restrict two-letter names in the second position seems to be unnecessary, as:

    • It seems to be a non-issue for end-users in view of prior use of popular two-letter second-level domain names (as .co.uk, .bb.br or .co.in)
    • It would be arbitrary & unfair to refuse this convenience to new applicants 

    Since such two-letter names do not seem to impact the security and stability of the domain name system, and as there have been no concerns articulated so far by Governments, I am of the opinion that this restriction should be removed.

    Regarding protection for new territories or countries, there is no guarantee, in any case, that the primary choice of ccTLD of the new country is not already taken (by an existing country).  

    1. Regarding the last point ("Regarding protection for new territories or countries, there is no guarantee, in any case, that the primary choice of ccTLD of the new country is not already taken (by an existing country)"), indeed the ISO 3166 Maintenance Authority would have to figure out what unique 2 letter code to allocate to a new country or territory, not ICANN or IANA.

  10. I am in agreement with the statement and Olivier's comments.

     

    As a matter of clarity, I would offer one (I hope friendly) modification:

    Change

    "Absent any security or stability issues"

    to

    "Absent any DNS-related security or stability issues"


    It is possible that some entities may claim that protection of a string is a security security issue as a matter of politics. I would add the change to emphasise that our exception for be for matters of purely technical stability and not a politically-motivated claim citing cultural or national stability.

    1. Indeed, DNS-related security or stability issues was the intent and expliciting stating so would make the proposed statement clearer.

  11. The prohibition was not a bone thrown to the GAC in this round. It goes WAY back. It is in the 2001 .com agreement and was added to the .net agreement in at the time of the 2005 renewal. The current specification is in line with the recommendation of the New gTLD Reserved Names WG in 2007. The existing names predate the restriction

    Curiously, Verisign requested removal of the restriction for non-cc strings in 2010 and then withdrew the request. I do not recall the reason. Other gTLDs have been granted such a request before and after.

    While I agree that the prohibition makes little sense to me (and Olivier's statement gives great examples why), I note that we can certainly make such a statement, but that is not the subject of the current consultations.

    For these the question is whether or not ICANN should grant an exemption for the allocation of non-3166 strings.

    My concern with the draft statement is that while it makes the above (not-asked issue) of whether it the spec makes any sense at all, it also argues both for the release of non-cc strings and issues a warning about such a release. If we are trying to send a clear message, this is not happening.

     

     

     

     

     

    1. See GNSO New TLDs Committee / Reserved Names Working Group Report, issued May 2007 http://gnso.icann.org/en/issues/new-gtlds/final-report-rn-wg-23may07.htm in particular "RECOMMENDATION SEVEN: TWO LETTERS AT THE TOP LEVEL"  and RECOMMENDATION EIGHT: ANY COMBINATION OF TWO LETTERS, DIGITS AT THE SECOND LEVEL

       

       

       

       

       

      1. Not sure what you are saying. Rec Seven is for TLDs, not 2nd/3rd level, and Rec 8 is what I referred to above as the source of the Spec in question:

        We recommend that registries may propose release of two letter and/or digit strings at the second level, provided that measures to avoid confusion with any corresponding country codes are implemented. A standardized approach should be used which ensures consultation with appropriate parties, including the ccNSO and ISO-3166 Maintenance Agency, and where security and stability issues are identified, RSTEP.

    2. "I note that we can certainly make such a statement, but that is not the subject of the current consultations."
       

      It is worth reminding, again, that the ALAC is not bound by any comment process or scope of subject. It is bylaw-empowered to advise on any issue at any time.

      The issue of two-letter domains in one specific instance has been raised. It is wholly appropriate for the ALAC to take this opportunity to give higher-level analysis that, in part, addresses the specifics of this particular consultation.

      Quite explicit in the broader statement proposed is the absence of any objection to allowing two-letter domains, including those proposed in this specific instance.

      1. Of course we may comment on anything at any time. My point was that this particular comment will be analyzed by people empowered to approve or reject the RSEPs in question - that 's all.

        As I tried to say, if we had said "since we don't think there should be ANY restriction on 2-letter 2nd-level registrations, we certainly do not object to what the registries are asking for", that would be just dandy. But since the draft comment also includes a rationale for NOT allowing two-letter codes that might at some future time be in the 3166 list, it is trying to be on both sides of the argument.

        If we are attempting to influence what might happen in future rounds, the DG just formed (and meeting tomorrow for the first time) is a reasonable forum (and the PDP which will eventually follow).

        If we are trying to get the Spec removed from existing TLDs, that requires a PDP to alter existing contracts. The ALAC is empowered to raise this issue, but I am not sure of the user impact that would justify it. I could see the user impact in putting in place such a rule if it didn't exist, to reduce user confusion - the this is going in the opposite direction.

         

         

         

         

  12. Pity my original comments on the list did not make it here.

    But FWIW, unless we are willing to say existing 2-char 2nd level names be they ISO 3166 codes or not are illegal, then equity demands that a restriction on future holdings is discriminatory.  That horse has already bolted.

    So if the ALAC statement is just to say, 'so long as it doesn't have any DNS-related and system stability impacts' then the ALAC is advised to sit this out.

    -Carlton