| Comment Close Date | Statement Name | Status | Assignee(s) | Call for Comments Open | Call for Comments Close | Vote Announcement | Vote Open | Vote Reminder | Vote Close | Date of Submission | Staff Contact and Email | Statement Number |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 10.07.2014 | Introduction of Two-Character Domain Names in the New gTLD Namespace | ADOPTED 13Y, 0N, 2A | Dev Anand Teelucksingh | 08.08.2014 | 11.08.2014 20:00 UTC | 11.08.2014 23:00 UTC | 11.08.2014 23:00 UTC | 15.08.2014 | 16.08.2014 23:00 UTC | 16.08.2014 | Krista Papac | AL-ALAC-ST-0814-01-01-EN |
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.
22 Comments
Dev Anand Teelucksingh
Alan Greenberg
While not disagreeing with Dev's careful analysis, I do have a comment and a question:
Aida Noblia
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.
Alan Greenberg
I am a bit confused on several levels.
First:
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:
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
Aida Noblia
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.
Fatima Cambronero
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.
Alan Greenberg
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.
Dev Anand Teelucksingh
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.
Dev Anand
P.S I do greatly appreciate the conversation on this topic.
Alan Greenberg
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.
Aida Noblia
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.
Olivier Crepin-Leblond
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.
Vanda Scartezini
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
Satish Babu
As pointed out in the discussions above, the proposal to restrict two-letter names in the second position seems to be unnecessary, as:
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).
Dev Anand Teelucksingh
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.
Evan Leibovitch
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.
Dev Anand Teelucksingh
Indeed, DNS-related security or stability issues was the intent and expliciting stating so would make the proposed statement clearer.
Alan Greenberg
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.
Dev Anand Teelucksingh
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
Alan Greenberg
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:
Evan Leibovitch
"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.
Alan Greenberg
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.
Carlton Samuels
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