Comment Close
Date
Statement
Name 

Status

Assignee(s)

Call for
Comments Open
Call for
Comments
Close 
Vote OpenVote CloseDate of SubmissionStaff Contact and EmailStatement Number
 

Use of Country and Territory Names as Top-Level Domains

ADOPTED 15Y, 0N, 0A

Main penholder: Maureen Hilyard

In consultation with: Cheryl Langdon-Orr

  

 

ALAC & Regional Leadership Wrap-Up Session

 

ALAC & Regional Leadership Wrap-Up Session

 
Glen de Saint Géry Glen@icann.org
Lars Hoffmann lars.hoffmann@icann.org
AL-ALAC-ST-1015-03-00-EN

For information about this Public Comment, please click here 

 

FINAL VERSION TO BE SUBMITTED IF RATIFIED

Click here to download the document below.



FINAL DRAFT VERSION TO BE VOTED UPON BY THE ALAC

ALAC Statement on the Use of Country and Territory Names as Top-Level Domains 

In putting this statement together, the ALAC appreciates the contributions that have been made by members of the At-Large Community. The statement reflects the many viewpoints that arose out of the consultation and discussions. 

Consensus within the community was that all 3-character TLDs should not be reserved solely for ccTLDs but there was a split as to whether there was any merit in reserving 3-letter codes for use by ccTLDs at all.

If 3 letter codes were to be used for country codes, the same standard that was applied to the 2-letter codes should also be applied to 3-letter codes as in the ISO 3166-1 list. ISO alpha-3 codes could be reserved as an alternative standard for country and territory codes in the same way that other standards have been reserved, such as ISO 4217 for currencies and ISO 639 for languages. This would open up the rest of the 3-letter options as gTLDs. 

An advantage of such a policy would be for ccTLD operators to have 3 character ccTLDs that may be marketed as complementary to two character ccTLDs.  Reserving all 3-letter ccTLDs would allow for future changes to the ISO 3166 alpha-3 to be reflected on the countries and territories being designated with new codes. The disadvantage of such a policy is that it blocks future 3-letter ccTLDs for use as possible gTLDs. There is also a risk of end-user confusion as to what policies would apply to the different TLDs. gTLD registries have contracts with ICANN which stipulate certain conditions that must be met (RAA, WHOIS, PICs, etc) and enforce such policies via contractual compliance; ccTLDs don't have any such contracts with ICANN and can implement any policy as the ccTLD administrator wants.

As an alternative, 3-letter codes listed as ccTLDs in ISO 3166-1 could be made available as gTLDs as long as they did not conflict with existing alpha-3 codes from the ISO 3166-1 list or were not marketed or used as pseudo-ccs. Policing or enforcing this could be problematic. It was also noted that the ISO 3166 alpha-3 (and alpha-2 for that matter) codes themselves are not static documents, as they are updated to reflect changes to countries and territories. Hence, there is a risk that a new country or territory can be allocated a new 3-letter code that could be taken by a gTLD. This would give rise to newer countries and territories being treated differently from existing countries. A new country or territory could be "locked out" of the use of its 3 character code, whilst older counties retained the use of theirs. If such governments or public authorities feel they are better recognized or identified by three character codes already in the ISO 3166-1 alpha-3, such entities could file objections to their use as gTLDs via their GAC representatives or apply to the 3166-MA which assigns country code elements.  Consultation with the relevant government/public authority would be prudent.

There are already examples where 3-letter country codes are currently being used as gTLDs by other organisations (eg .com, as COM is the ISO 3166-1 alpha 3 code for Comoros). Current exceptions to the reservation standard did not invalidate the standard moving forward but there must be caution in creating exceptions which could diminish trust in ICANN and subsequently trust in the stability of the DNS. 

There was an opposing view that there is no merit in reserving 3-letter codes due to several reasons. First, current 3-letter country codes are not widely used and some organisations are already using country codes other than the ISO ones. The IOC (International Olympic Committee) and the FIFA (Fédération Internationale de Football Association) use other codes. For example, the ISO code for South Africa is ZAF while IOC and FIFA use RSA; whereas the ISO and FIFA code for Barbados is BRB, IOC uses BAR. Thus if ISO 3166-1 codes were reserved, would one need to reserve IOC & FIFA codes too? Second, as every geographical area has a 2-letter country code and there are plenty of 2-letter codes remaining, countries may not need to use their assigned 3-letter code as well. The call by the opposing group was to open the 3-letter codes to all, and to maintain the 2-letter codes for ccTLDs.  

While some 3-letter country codes are easily identifiable as referring to specific countries and territories, there are still other country codes that would also be very desirable as 3-letter gTLDs. A reserved list would restrict access to good codes for gTLDs, especially when they were unlikely ever to be used as ccTLDs.

The ISO 3166-1 alpha-3 list does not use IDN characters and it is not clear if a definitive list of 3 character IDN strings exists that could be used to represent countries and territories. Blocking all 3 IDN characters would likely delay the expansion of IDN gTLDs. If there are 3 character IDN strings that represent a geographic name (the name of a country, territory, or state names as in the current Applicant Guidebook), then such strings should be rejected as gTLDS as per the Applicant Guidebook. As ICANN has decided that IDN ccTLDs will be delegated to the same registries as hold their existing ccTLDs, it is recommended that this precedent should be referred to when the delegation of alpha-3 codes arises.

There were opposing views as to the appropriateness of either the GNSO or the ccNSO as the manager of the 3-letter country/territory codes. Some resistance was expressed with regards to the GNSO taking charge of Alpha-3 codes in competition with Alpha-2 codes run by the ccNSO. 

With regards to the many arguments for and against the reservation of 3-letter ccTLDs with the potential for creating much confusion amongst the user community, there was very strong agreement among the At-Large respondents that there is a need for a moratorium where a full evaluation should be made of the potential impacts of the current expansion of the existing new gTLD programme. It has also been recommended, in order to increase user confidence in navigating the enlarged domain space, that along with a time-framed moratorium, promotional and educational resources and activities related to the introduction of the new gTLDs be developed in areas (geographical, political, social, economic, etc) that were not served well in the first run.

 


FIRST DRAFT SUBMITTED

Version 3 - 30 Sep 2015 

Consensus within the At-Large community was that all 3-character TLDs should not be reserved solely for ccTLDs but the community was split as to whether there was any merit in reserving 3-letter codes for use by ccTLDs at all.

If 3 letter codes were to be used for country codes, the same standard that was applied to the 2-letter codes should also be applied to 3-letter codes as in the ISO 3166-1 list. ISO alpha-3 codes could be reserved as an alternative standard for country and territory codes in the same way that other standards have been reserved - ISO 4217 (for currencies) and ISO 639 (for languages). This would open up the rest of the 3-letter options as gTLDs. 

An advantage of such a policy would be for ccTLD operators to have 3 character ccTLDs that may be marketed as complementary to two character ccTLDs. If the ISO 3166 alpha-3 codes are applied, reserving all 3-letter ccTLDs would allow for future changes to the ISO 3166 alpha-3 to reflect changes to countries and territories being designated with new codes. The disadvantage of such a policy is that it blocks any future 3-letter TLDs for use as possible gTLDs. There is a risk of end-user confusion as to what policies would apply to the different TLDs especially as gTLD registries have contracts with ICANN which stipulates certain conditions that must be met (RAA, WHOIS, PICs, etc). ICANN enforces such policies via contractual compliance. ccTLDs don't have any such contracts with ICANN and can implement any policy as the ccTLD administrator wants.

As an alternative, 3-letter codes listed as ccTLDs in ISO 3166-1 could be made available as gTLDs as long as they did not conflict with existing alpha-3 codes from the ISO 3166-1 list or were not marketed or used as pseudo-ccs. Policing or enforcing this could be problematic but it was also noted that the ISO 3166 alpha-3 (and alpha-2 for that matter) codes themselves are not static documents. They are updated to reflect changes to countries and territories. So there is a risk that a new country or territory can be allocated a new 3-letter code that could be taken by a gTLD. This would give rise to newer countries and territories being treated differently from existing countries, with a new country or territory "locked out" of the use of their 3 character code whilst older counties retaining the use of their 3-letter code. If such  governments or public authorities feel they are better recognized or identified by a three character code that is already in the ISO 3166-1 alpha-3, such entities could file objections to its use as a gTLD via their GAC representatives or apply to the 3166-MA which assigns country code elements. Having support and non-objection in hand from the relevant government/public authority would be prudent.

There are already examples where 3-letter country codes are currently being used as gTLDs by other organisations (eg .com). Current exceptions to the reservation standard did not invalidate the standard moving forward but there must be caution in creating exceptions which could diminish trust in ICANN and subsequently trust in the stability of the DNS. 

There was an opposing view that there is no merit in reserving 3-letter codes, firstly because current 3-letter country codes are not widely used and often as not countries use codes other than the ISO ones, e.g ANG for Angola. Secondly, as every geographical area has a 2-letter country code and there are plenty of 2-letter codes remaining, countries may not use their assigned 3-letter code as well.  The call by this group was to open the 3-letter codes to all, and maintain the 2-letter codes for ccTLDs.  

While some 3-letter country codes are easily identifiable as referring to specific countries /territories and others less so, there are still others that would be very desirable as 3-letter gTLDs.  A reserved list would restrict access to good codes for gTLDs even if they were unlikely ever to be used as ccTLDs.

The ISO 3166-1 alpha3 list doesn't use IDN characters and its not clear if there exists a definitive list of 3 character IDN strings that could be used to represent countries and territories. Blocking all 3 IDN characters can likely delay the expansion of IDNs gTLDs. If there are 3 character IDN strings that represent a geographic name (the name of a country or territory, permutations thereof and state names as in the current Applicant Guidebook) then such strings should be rejected as gTLDS as per the Applicant Guidebook. However, guidance from the At-Large IDN WG would be helpful.  As ICANN has decided that IDN ccTLDs will be delegated to the same registries as hold their existing ccTLDs, it is recommended that this precedent should be referred to when the delegation of alpha-3 codes arises.

There were opposing views as to the appropriateness of either the GNSO or the ccNSO as manager of the 3-letter country/territory codes, but some resistance was expressed with regards to the GNSO taking charge of Alpha-3 codes in competition with Alpha-2 codes run by the ccNSO. 

With regards to the many arguments for and against the reservation of 3-letter ccTLDs with the potential for creating much confusion amongst the user community, there was very strong agreement among the At-Large respondents that there is a need for a moratorium where a full evaluation should be made of the potential impacts of the current expansion of the existing new gTLD programme. It has also been recommended, in order to increase user confidence in navigating the enlarged domain space, that along with a time-framed moratorium, promotional and educational resources and activities related to the introduction of the new gTLDS be developed in areas (geographical, political, social, economic, etc) that were not served well in the first run.

Version 2 - 29 Sep 2015 

Version 1 - 28 Sep 2015 

  • No labels

16 Comments

  1. Questions by the CWG-UCTN on 3-character codes with regard to the use of country and territory names as top-level domains - COMMENTS PLEASE

     

    Dear At-Large members

    Country codes are traditionally a 2-letter string. The new gTLD process is enabling country and territory codes to be expanded to 3-letters (or even as whole names).

    The “Cross Community Working Group for the Use of Country and Territory Names as Top Level Domains” is asking: 

    1. Should these new 3-letter country/territory codes be reserved ONLY as ccTLDs OR should they be open to everyone as gTLDs?  (This question refers to 3-letter code IDN ccTLDs and IDN gTLDs as well)

    2. What advantages or disadvantages does your answer offer either group (ccTLDs or gTLDs)?

  2. For those who would like to contribute to other questions, please continue:

    1. In future, should all three-character top-level domains be eligible for use as gTLDs as long as they are not in conflict with the existing alpha-3 codes from the ISO 3166-1 list; i.e. the three-character version of the same ISO list that is the basis for current ccTLD allocation? What would be the advantage or disadvantage of such a policy?

    2. In future, should three-character strings be eligible for use as gTLDs if they are not in conflict with existing alpha-3 codes form the ISO 3166-1 list and they have received documentation of support or non-objection from the relevant government or public authority? What would be the advantage or disadvantage of such a policy?

    3. In future, should there be unrestricted use of three-character strings as gTLDs if they are not conflicting with any applicable string similarity rules? What would be the advantage or disadvantage of such a policy?

    4. In future, should there be unrestricted use of IDN three-character strings if they are not in conflict with existing TLDs or any applicable string similarity rules? What would be the advantage or disadvantage of such a policy?

    5. In future, should all IDN three-character strings be reserved exclusively as ccTLDs and be ineligible as IDN gTLDs? What would be the advantage or disadvantage of such a policy?

    6. Do you have any additional comments that may help the CWG-UCTN in its discussion on three-character strings as top-level domains?
  3. COMMUNITY RESPONSES:

    Evan Leibovitch

    To me the answer is self-evident.  The codes that ICANN uses for ccTLDs, especially ones that are non-intuitive to foreigners (such as .ch for Switzerland, .za for South Africa or .kh for Cambodia) are based on an ISO standard, ISO 3166-1, with one notable exception (use of ,uk when the ISO code for the United Kingdom is GB).
    This same standard also defines three-lettter codes. Because of the definition of a publicly-understood standard, anything besides allocating these ISO codes to the appropriate ccTLDs would cause substantial public confusion.
    Carlton Samuels
    +1
    Evan Leibovitch
    I note that I did not fully answer Maureen's questions.  The comments of my last message refer only to the ISO-defined three-letter strings. Full-length names (such as .deutchland) are not protected this way; though I believe the allocation of country-full-name strings to third parties to be stupid and generally against the public interest, the case against them is not as obvious as for the ISO codes.  Having said this, I personally believe that there should be a moratorium of any new gTLD applications until a full evaluation of the effect of the current expansion is complete.
    Carlton Samuels
    ++1
    Christopher Wilkinson
    Maureen:
    1. The ISO alpha-3 codes should be reserved in the same way as the alpha-2 codes, which are exclusively used for ccTLDs.
     The ISO-4217 alpha-3 codes should also be reserved because they represent currencies.
     For instance EUR represents the Euro (€) and definitely should not be used for anything other than official representation of the Euro.
    2. I agree with Evan that there should be a moratorium on any new gTLDs until there has been a thorough evaluation of the existing new gTLD programme.
    In any event the whole issue of the representation of country names will go to the GAC if it is not already there.
    Olivier Crepin-Leblond
    Agreed - and there's another process to comment on wrt this topic.  https://community.icann.org/x/zIdYAw
    Yasiuchi Kitamura
    > 1. Should these new 3-letter country/territory codes be reserved ONLY as ccTLDs OR should they be open to everyone as gTLDs?  (This question refers to 3-letter code IDN ccTLDs and IDN gTLDs as well)
    They should be reserved.
    >  2. What advantages or disadvantages does your answer offer either group (ccTLDs or gTLDs)?
    ccTLD:  advantages: some countries who know well about Internet structure at this moment won’t get problems in the future
    disadvantages: ccTLD will have to fight with some companies who happen to be the same 3 letters as those 3 letter ccTLDs.
    gTLD:  advantages: they can make the clear answer to those requesters why they can’t use some 3 letter domains.
    disadvantages: messy, maybe?
    Christian de Larrinaga
    A *full* evaluation could be a long ... hiatus :-)That horse bolted and took the stable  (ICANN) with it. I doubt it can be put back in its box.
    It will be hard to argue against *any* new domains unless there is clear instability to the DNS in their creation and use.
    I do agree with the limitation to keep 2 and 3 character domains restricted for the time being until enough dust has settled from the expansion and user confidence in navigating the enlarged domain space is sufficient to let that go - if ever.
    Evan Leibovitch
    On 22 September 2015 at 12:09, Christian de Larrinaga <cdel@firsthand.net> wrote:
    A *full* evaluation could be a long ... hiatus :-)
    What's wrong with that?
    That horse bolted and took the stable (ICANN with it.. I doubt it can be put back in its box.
    Why not?

    Nadira Alaraj

    Country codes are traditionally a 2-letter string. The new gTLD process is enabling country and territory codes to be expanded to 3-letters (or even as whole names). 

    Giving the ccTLDs to manage their country's whole name or country's common Acronyms in the new gTLD or IDNs is great move. 

    The “Cross Community Working Group for the Use of Country and Territory Names as Top Level Domains” is asking: 

    1. Should these new 3-letter country/territory codes be reserved ONLY as ccTLDs OR should they be open to everyone as gTLDs?  (This question refers to 3-letter code IDN ccTLDs and IDN gTLDs as well)

    It would be very restricting to reserve the 3-letter country codes to only ccTLDS. It would be good to reserve a list of possible acronyms as well as whole country names to ccTLDs and open the rest as gTLDs. The suggested list must be solicited from all countries.

    2. What advantages or disadvantages does your answer offer either group (ccTLDs or gTLDs)?

    It gives registrar wider choice for their registrants.  It open creativity of different choices to the new gTLDs

    Jordi Ipparraguirre

    Hi, thanks Maureen for forwarding the questionnaire.   I concur with Evan and Christopher but I'd like to add a note.
    On one side it does make sense to reserve ISO 3166-2 and 4217.
    On the other side, following he tradition set by .cat 10 years ago and some new gTLDs, (.bzh, .gal, .eus, etc) I'd propose to allow 3-char to gTLDS for communities ISO 396 could be a bit of a guide for that.
     
    Robert Gaetano

     I agree about the moratorium, but I strongly disagree about the alpha-3 ISO-3166 codes. There are already 3-letter gTLDs that are conflicting with alpha-3 codes. If there is a generalized use of alpha-3 codes, it will be extremely confusing if “some” 3-letter codes would not respect this rule.

     If, on the other hand, there is no generalized use of alpha-3 codes, unlike alpha-2 codes, then why reserve them?  I think that we just have to accept the fact that there is a limit to what you can reserve for specific use (smile)

    John Levine

    There are already 3-letter gTLDs that are conflicting with alpha-3 codes.

    Whew, I thought I was the only person who noticed that.  COM is the Comoros islands, that horse left the barn 30 years ago.
    Every geographical area that's eligible for a country code has a two letter country code, and lots of existing software has special cases to treat two letter TLDs differently.  (Yes, we know about the IDNs.)  There are plenty of two letter codes left, they're not going to run out.
    I can think of no reason to reserve the remaining 3 letter country codes other than as a makework project for bureaucrats with too little to do. Surely we have enough of those already.

    Karl Auerbach

    Every geographical area that's eligible for a country code has a two letter country code, and lots of existing software has special cases to treat two letter TLDs differently.  (Yes, we know about the IDNs.) There are plenty of two letter codes left, they're not going to run out.
    I can think of no reason to reserve the remaining 3 letter country codes other than as a makework project for bureaucrats with too little to do.  Surely we have enough of those already.

    I fully agree with John Levine on this.

  4. COMMUNITY RESPONSES DAY 2

    Le 22/09/2015 10:13, Evan Leibovitch a écrit :

     I note that I did not fully answer Maureen's questions.

    The comments of my last message refer only to the ISO-defined  three-letter strings. Full-length names (such as .deutchland) are not protected this way; though I believe the allocation of country-full-name strings to third parties to be stupid and generally against the public interest, the case against them is not as obvious as for the ISO codes.

    Elisabeth Porteneuve

     Are "foreigners" native English speakers?  
    I do not believe anyone have problem to recognise Confédération Helvétique - Swiss Confederation, using 4 official administrative languages, that means: French, German, Italian and Romansh.

     Khmer is the autonym for the language of the nation of Cambodia, similar to Deutsch for the nation of Germany. Therefore .kh and .de, easy.

    Apparently even native English speakers know "Full-length names (such as .deutchland)" ;-)
    >     The codes that ICANN uses for ccTLDs, especially ones that are
    >     non-intuitive to foreigners (such as .ch for Switzerland, .za for
    >     South Africa or .kh for Cambodia) are based on an ISO standard, ISO
    >     3166-1 <https://en.wikipedia.org/wiki/ISO_3166-1>, with one notable
    >     exception (use of ,uk when the ISO code for the United Kingdom is GB).

    Mathematicaly speaking you cannot have 250 alpha-2 codes, all of them with 2 initial letters of country name in foreign language (English). Not even with 2 inital letters corresponding to the autonym country name.
    Best,
    Elisabeth Porteneuve
    (yes, I work for ISO 3166)    (no, I have no opinion about TLD names, not after 17 years of ICANN)

    Evan Leibovitch

    On 23 September 2015 at 09:43, Porteneuve Elisabeth (labo)
    <elisabeth.porteneuve@latmos.ipsl.fr> wrote:

    > I do not believe anyone have problem to recognise Confédération Helvétique - Swiss Confederation, using 4 official administrative languages, that means: French, German, Italian and Romansh.
    I stand by what I said. If you think that  "Confédération Helvétique" is a globally-recognized name for Switzerland, you need to travel more  ;-).
    But Switzerland seems uniquely weird in this way. It has four official languages, but national institutions either use three of them (post office and railway) or they abandon all of them and use English (the national airline) or Latin (the ccTLD). The only docs I have seen use all four official languages at once are government signage and
    letterhead.
    (And speaking of Latin, I would assert that more people recognize the term "Helvetica" as a font than a country.)

    > Khmer is the autonym for the language of the nation of Cambodia, similar to Deutsch for the nation of Germany. Therefore .kh and .de, easy.
    Why do you assume that what comes easy to you comes easy to others?

    > Apparently even native English speakers know "Full-length names (such as .deutchland)" ;-)
    Some, not all, not even most. Don't assume.
    (I had to see a hockey tournament to know the native full-length name of Finland (ccTLD: .fi). How many non-Scandinavians and non-sports-fans here would know it without looking it up?)
    (back on-topic}
    The full-country-name situation is wildly diverse in its multilingual state and can not really be policed. (could all possible multi-lingual forms of a country name -- such as "frankreich" -- be restricted?).
    OTOH, I still assert that ISO, an actual treaty body, has far more public authority and trust than ICANN could ever dream of having. As such, its designated three-letter names should remain off-limits.
    In any case, this may be moot to argue, at least for now, as I imagine that the GAC will be pretty forceful about this.

    Seun Ojedeji

    On 22 Sep 2015 20:39, "John Levine" <john.levine@cauce.org> wrote:

    There are already 3-letter gTLDs that are conflicting with alpha-3 codes.
    Whew, I thought I was the only person who noticed that.  COM is the Comoros islands, that horse left the barn 30 years ago.
    Every geographical area that's eligible for a country code has a two letter country code, and lots of existing software has special cases to treat two letter TLDs differently.  (Yes, we know about the IDNs.)  There are plenty of two letter codes left, they're not going to run out.
    I can think of no reason to reserve the remaining 3 letter country codes other than as a makework project for bureaucrats with too little to do. Surely we have enough of those already.

    My +1 to this sentiment/rationale.

    McTim

    +1 to Karl and John.

    Potential user confusion is not something I am concerned about as much as censorship and giving governments more sway inside ICANN.  The GAC has already won far too many concessions OUTSIDE the GNSO policy arena, we shouldn't give them any more for minor reasons.

     Olivier Crepin Leblond

    Hello Tim & all,
    I am not sure I'm 100% in agreement here. I have concerns that so far we've had ccTLDs that were running country-related TLDs and now we might see more Country Codes, this time 3-letter country codes, used and run as gTLDs - hence falling under the remit of the GNSO = more US-based legislation and less legislation that happens in the country itself. This, to me, smells like a concentration of more power within ICANN's walls, when if we insisted on keeping CCs (2 & 3 letters) in ccNSO hands, wouldn't it do the opposite?

     Evan Leibovitch

    At its core, this is about putting public property (ie, an existing international standard) in proprietary hands... like having a troll trying to assert copyright on the flags of the world. 

     The fact that there are exceptions to reservation of the standard (.com, .uk) does not negate the validity of the standard going forward. Going after it will simply diminish trust in ICANN even below its current awful levels, and at some point this diminishing trust will affect DNS stability.

    As for the GACophobia...  fine. As Olivier suggests, punt it to the ccNSO first and see what they think. That's critical feedback to this issue. 

    Seun Ojedeji

     Hi Olivier, all

    I understand the sentiments and I somewhat agree with you on the fact the there is need for some form of "power" distribution. I will personally say apart from power, orderliness and structure is another aspect we may be loosing once the 3 letter is opened up in the manner proposed. This was actually why I added a +1 to John as i read his mail to mean "let the the 3 letters be open to all" and maintain the 2 letters to ccTLDs".  I don't know of any instance where a country(new) could not get alpha-2 codes. The alpha-2 is closer to the work of IANA as its what is also used within the IETF within IETF as well.
    That said, there is also merit in reserving the corresponding alpha-3 letter of each country and then opening up to the Gs. The advantage in that is that some level of consistency will be ensured so the registry managing for instance .ng will also manage .ngr

    Maureen Hilyard

    Adding my own 2c worth to this conversation I would agree with Seun's recommendations

    Olivier Crepin Leblond

     On 23/09/2015 16:18, Seun Ojedeji wrote:
    That said, there is also merit in reserving the corresponding alpha-3 letter of each country and then opening up to the Gs. The advantage in that is that some level of consistency will be ensured so the registry managing for instance .ng will also manage .ngr
    If .NG is under ccNSO and .NGR under GNSO there is no guarantee that this would be the case. Could .NGR be run by a Registry based outside Nigeria? Would this introduce competition to the local ccTLD? Would this siphon money out of Nigeria rather than keeping it in the local economy?

    McTim

    On Wed, Sep 23, 2015 at 10:56 AM, Evan Leibovitch <evanleibovitch@gmail.com> wrote:

     At its core, this is about putting public property (ie, an existing international standard) in proprietary hands

     Is it?  I'm not seeing it.  It DOES mean that 3 letter codes could be used as gTLD (the ccTLD manager could apply as well and use it as a psuedo-ccTLD if they wanted).  Nation States do not OWN the codes, or the standard (ISO).  Nation States have, in theory, asserted authority over 2 letter ccTLDs, but in practice that hasn't always been the case in practice. The Tunis Agenda that asserted sovereignty is a non-binding agreement.

     ... like having a troll trying to assert copyright on the flags of the world.

    The fact that there are exceptions to reservation of the standard (.com, .uk) does not negate the validity of the standard going forward. Going after it will simply diminish trust in ICANN even below its current awful levels, and at some point this diminishing trust will affect DNS stability.

     red-herring IMHO. 

     As for the GACophobia...

     I am not GAC phobic, I just want them to understand their role and not assert more authority than they have on paper. In practice, they have done end-arounds to implement the blocking of thousands of strings at the second level without appropriate GNSO action as just one example of how they would like to have more power.

     fine. As Olivier suggests, punt it to the ccNSO first and see what they think. That's critical feedback to this issue. 

     Why?  The ccNSO doesn't have ALL cc's as Member's nor do they have authority over 3 letter codes.  This would be a radical shift done without a PDP.


    Evan Leibovitch in response to McTim
    > I am not GAC phobic, I just want them to understand their role and not assert more authority than they have on paper.
    Good luck with that. The more ICANN goes rogue on the public interest, the more it invites governments to do their own thing. Keep it going, guys.
    ICANN's authority is not by treaty (like ISO), it is only by tacit and informal international consent. That consent can be withdrawn or modified at any time by any state(s). The GAC is ICANN's only buffer against that, on paper or not.
    Or ... maybe it can do another PR campaign for "universal acceptance".
    > In practice, they have done end-arounds to implement the blocking of thousands of strings at the second level without appropriate GNSO action as just one example of how they would like to have more power.
    I didn't expect to find humour in this debate, but that gave me a chuckle.
    Governments have ZERO obligation to honour the GNSO. That's one of the little unfortunate truths that people tend to forget inside the bubble called ICANN.
    Governments are sovereign over their territories in exactly the way that ICANN is not. They already possess all the power you complain that they seek; the industry just screams like a baby whenever that power is asserted, as if it is magically entitled to a veto.
    Especially in the absence of international oversight, it is the GNSO that needs to demonstrate that it deserves the trust of the world's governments to operate, not vice versa. Right now that trust is in short supply and on the decrease; making a land-grab on the 3-letter ISO country codes would go a long way to eroding it even faster.
    Yeah, you tell the GAC -- you tell the global public -- that this issue needs a PDP, that the domain industry gets to hold court on it.
    This'll be fun to watch,

     Seun Ojedeji

    In response to, Olivier MJ Crepin-Leblond <ocl@gih.com> (On Wed, Sep 23, 2015 at 4:46 PM)
    While there are still a few ccTLDs that is still being run by registries based outside the region, I think that decision making process should remain with the respective countries. So such situation described above is a bottleneck that needs to be avoided at ICANN level; .NGR for instance should not be run under the GNSO. If the 3 letter TLD is to be opened as gTLD then it would be preferred to reserve the corresponding country codes for ccTLDs. I would expect that necessary processes will be put in place to ensure that the alpha-3 reserved in the 3 letter TLDs are operated in similar manner used by the alpha-2 (both at operation and policy level).

    That said, there is still the question of whether current ccTLD registries will be willing to maintain an extra tld. Nevertheless, i think it should be done in the interest of avoiding ambiguity, ensuring clarity and proper structure; It will be good for ICANN to ensure that a country alpha-3 code does not get delegated to an "unauthorised" registry. I fear the future politics within ICANN will be more complicated than we know it if that is not done
    Jaap Akkerhuis  in response to Seun
    I cannot resist to remark that NGR is not an ISO 3166 alpha-3 code.  Check the database at <https://www.iso.org/obp/ui/> for the code and notice it is actually NGA.
    Seun Ojedeji
    Thats right, NGR is the IOC code. Thanks for catching that.

    Evan Leibovitch

    On 23 September 2015 at 18:54, Seun Ojedeji <seun.ojedeji@gmail.com> wrote:
    While there are still a few ccTLDs that is still being run by registries based outside the region, I think that decision making process should remain with the respective countries. So such situation described above is a
     bottleneck that needs to be avoided at ICANN level; .NGA for instance should not be run under the GNSO. If the 3 letter TLD is to be opened as gTLD then it would be preferred to reserve the corresponding country codes for ccTLDs.
    +1
    > That said, there is still the question of whether current ccTLD registries will be willing to maintain an extra tld.

     Perhaps, but that's their call. They could always put a park page there. ;-)

    Christopher Wilkinson

    So, then one would have alpha-3 code gTLDs being run with GNSO policies, in competition with alpha-2 code ccTLDs being run with ccNSO policies (+ GAC and other governmental policies as the case may be).

    I don't think so!
    BTW, that would be a clear invitation for numbers of governments to intervene directly in GNSO matters. Is that what one wants?
    Furthermore, ICANN, having decided that the IDN ccTLDs would be delegated to the same Registries as hold their existing ccTLDs ('fast track'), someone would no doubt point to that precedent if and when the question of delegating the alpha-3 codes might arise.
    Regards
    CW (In my personal capacity with no axe to grind: the alpha-3 code EUR will in any event be embargoed because it is also in ISO-4217, currency code for the €.)
    PS:  Has anyone asked ISO? My recollection is that at the time the European Commission asked ISO specifically for permission to use the EU alpha-2 code as a ccTLD (they agreed).  A fortiori, ISO might have views about how their alpha-3 codes could be used.

    Alan Greenberg

    A couple of thoughts, not in response to any particular message in this list.
    The concept of the alpha-3 codes being restricted was introduced, somewhat out of the blue, in the New gTLD implementation. Some of them are pretty recognizable as references to the country/territory, some much less so. A few of them would likely to be pretty desirable 3-letter gTLDs.
    I could easily live with them being available as gTLDs under the provision that they could not be marketed or used as pseudo country codes (So you could get GEO for the collectors of the now long-gone General Motors car, but not to market as a country-related TLD for Georgia. I have no idea how you could policie or enfoce that, or for that matter, decide how some 3-letter codes could be made available for generic use and some for real country codes

     So although I have a problem restricting what could be good codes for g-use when they are unlikely to be used for cc-use, I am not sure it is worth the effort to do it.

    Evan Leibovitch

    Alan,  There are many precedents of how ccTLDs have been used as pseudo-gTLDs. (.LY, .FM), some deliberately marketed that way (.CO, .ME, .LA) as well as ccTLDs that *could* have been marketed that way yet were limited by their registry (.IT and .US come to mind but I'm sure that readers can think of others.)
       The same thing can be done once ccTLD registries are given authority over the three-letter ISO codes. If a registry operator has a use for, say .CAN, it can make a pitch to the appropriate operator to use it as a generic. if the offer is good enough and/or the ccTLD operator has no specific plans, the registry operator can strike a deal that might be cheaper and faster than going through the ICANN process. Obviously deals like this have already been done in two-letter space.
       So, none of the "generic-capable" 3-letter ISO codes need go to waste if the will exists to use them, even if they are first assigned to the CC operators. Doing it this way eliminates the need for the policing requirement you indicated.
       The alternative is allowing the usual free-for-all, waiting for the next round and enduring a fairly complete, unmoving and successful set of GAC objections. Might make this round's objection phase look simple by comparison.
       Why not be proactive on the matter rather than waiting for that?

    Roberto Gaetano

     Disclaimer: I have been working  8 solid ye a rs  for a standardization organization , so please understand that I am biased.

     In the standardization community it is often said that standards are as good as they are being used.

     In other words, a little used standard is not worth much.

     My question is: how much is the ISO-3166-3 used ?

        There might be some obscure (to the end user) applications,  although  Eli sabeth can prove me wrong, but I am under the impression that, while the ISO-3166-2 are widely used (and therefore recognized), the ISO-3166-3 are not.  

     Who can name ISO-3166-3 applications?

     About ISO-3166-2 I can name ccTLDs, IBAN,  currencies (in the sense that the  3-letter  currency code  has the alpha-2 as its first 2 letters), and more. But the alpha-3?

    And that's exactly pointed out by Seun's "mistake"  and Jaap's "correction".

    The fact is that there are plenty of three-letters country codes, created by different bodies .  IOC is one, but FIFA also has its own, plus the international car license plates , and many more.

    Let's go for a few examples.

      ·         the Holy See,  VA in ISO-3166-2,  is VAT  (yes, like Value Added Tax) in ISO-3166-3, but SCV in license plates.  They are not a member neither of IOC nor FIFA (although I have learned to play football - soccer in North  America    - in the  neighborhood    catholic  parish) , but God only knows what their code would be in the sports environment. Now, to the point, ask any person in Italy, and in Rome in particular, what a 3-letter code for the Holy See would be, and I bet the answer would be SCV. Ask them what VAT means, and you all can guess what the answer would be. So, what ’s the point in reserving VAT, that is widely used for something else, and not SCV, that is recognized as belonging to the Holy See?

    ·        Angola, AO in alpha-2, AGO in alpha-3.  Why on earth? Simply because AN was taken by Dutch Antilles (now discontinued).  The alpha-3 was mirrored on alpha-2, and makes an equally incomprehensible (by the man in the street) code.  But their IOC and FIFA codes are ANG, and if I were to create a TLD to pretend I am authoritative for Angola, I would obviously choose ANG, n ot AGO. So to protect AGO is pointless.  

      ·       Just take the time to browse the codes.  Tell me which codes  y ou would use to “fake ” a country’s authority. For Algeria,  DYA or ALG? For  Denmark, DNK or DEN?  For Ireland, IRL or EIR? What would  y ou think about  “regional” accepted codes, some of which have become or are becoming gTLDs, like CAT, SCO, etc .    – should  we “protect” them also, on top of the ISO-3166-3 codes’

     As ALAC, we should be concerned, IMHO, about avoiding “consumer confusion”. To “protect ” country codes that are by and large unused and unknown by people – unless they happen to correspo nd to widely known codes like IOC or FIFA or license plates, does not make a lot of sense to me.  

     If we have a moratorium on new gTLDs (not an endless one, but a time frame that allows to have some serious thought about the shortcomings of the first run ) we can possibly have  promotio n/education  activities related  t o  gTLDs in the areas  (geographical, political, social, eco nomic, and whatever else)  that were not well served in the first run .

    I believe that in a couple of years  c ountr ies  would  be sufficiently aware of the issues to  raise an objection to the use by a  “rogue” party of a TLD that  they consider (rightfully or not – but  that’s  not ICANN  s role to decide)  “their ” property.

    Tijani BenJamaa

    I fully support John Levine opinion.

  5. Summary – second draft (amended)

    Consensus within the At-Large community was that all 3-character TLDs should not be reserved solely for ccTLDs but the community was split as to whether there was any merit in reserving 3-letter codes for use by ccTLDs at all.

    If 3 letter codes were to be used for country codes, the same standard that was applied to the 2-letter codes should also be applied to 3-letter codes as in the ISO 3166-1 list. ISO alpha-3 codes could be reserved as an alternative standard for country and territory codes in the same way that other standards have been reserved - ISO 4217 (for currencies) and ISO 639 (for languages). This would open up the rest of the 3-letter options as gTLDs. 

    An advantage of such a policy would be for ccTLD operators to have 3 character ccTLDs that may be marketed as complementary to two character ccTLDs. If the ISO 3166 alpha-3 codes are applied, reserving all 3-letter ccTLDs would allow for future changes to the ISO 3166 alpha-3 to reflect changes to countries and territories being designated with new codes. The disadvantage of such a policy is that it blocks any future 3-letter TLDs for use as possible gTLDs. There is a risk of end-user confusion as to what policies would apply to the different TLDs especially as gTLD registries have contracts with ICANN which stipulates certain conditions that must be met (RAA, WHOIS, PICs, etc). ICANN enforces such policies via contractual compliance. ccTLDs don't have any such contracts with ICANN and can implement any policy as the ccTLD administrator wants.

    As an alternative, 3-letter codes listed as ccTLDs in ISO 3166-1 could be made available as gTLDs as long as they did not conflict with existing alpha-3 codes from the ISO 3166-1 list or were not marketed or used as pseudo-ccs. Policing or enforcing this could be problematic but it was also noted that the ISO 3166 alpha-3 (and alpha-2 for that matter) codes themselves are not static documents. They are updated to reflect changes to countries and territories. So there is a risk that a new country or territory can be allocated a new 3-letter code that could be taken by a gTLD. This would give rise to newer countries and territories being treated differently from existing countries, with a new country or territory "locked out" of the use of their 3 character code whilst older counties retaining the use of their 3-letter code. If such  governments or public authorities feel they are better recognized or identified by a three character code that is already in the ISO 3166-1 alpha-3, such entities could file objections to its use as a gTLD via their GAC representatives or apply to the 3166-MA which assigns country code elements. Having support and non-objection in hand from the relevant government/public authority would be prudent.

    There are already examples where 3-letter country codes are currently being used as gTLDs by other organisations (eg .com). Current exceptions to the reservation standard did not invalidate the standard moving forward but there must be caution in creating exceptions which could diminish trust in ICANN and subsequently trust in the stability of the DNS. 

    There was an opposing view that there is no merit in reserving 3-letter codes, firstly because current 3-letter country codes are not widely used and often as not countries use codes other than the ISO ones, e.g ANG for Angola. Secondly, as every geographical area has a 2-letter country code and there are plenty of 2-letter codes remaining, countries may not use their assigned 3-letter code as well.  The call by this group was to open the 3-letter codes to all, and maintain the 2-letter codes for ccTLDs.  

    While some 3-letter country codes are easily identifiable as referring to specific countries /territories and others less so, there are still others that would be very desirable as 3-letter gTLDs.  A reserved list would restrict access to good codes for gTLDs even if they were unlikely ever to be used as ccTLDs.

    The ISO 3166-1 alpha3 list doesn't use IDN characters and its not clear if there exists a definitive list of 3 character IDN strings that could be used to represent countries and territories. Blocking all 3 IDN characters can likely delay the expansion of IDNs gTLDs. If there are 3 character IDN strings that represent a geographic name (the name of a country or territory, permutations thereof and state names as in the current Applicant Guidebook) then such strings should be rejected as gTLDS as per the Applicant Guidebook. However, guidance from the At-Large IDN WG would be helpful.  As ICANN has decided that IDN ccTLDs will be delegated to the same registries as hold their existing ccTLDs, it is recommended that this precedent should be referred to when the delegation of alpha-3 codes arises.

    There were opposing views as to the appropriateness of either the GNSO or the ccNSO as manager of the 3-letter country/territory codes, but some resistance was expressed with regards to the GNSO taking charge of Alpha-3 codes in competition with Alpha-2 codes run by the ccNSO. 

    With regards to the many arguments for and against the reservation of 3-letter ccTLDs with the potential for creating much confusion amongst the user community, there was very strong agreement among the At-Large respondents that there is a need for a moratorium where a full evaluation should be made of the potential impacts of the current expansion of the existing new gTLD programme. It has also been recommended, in order to increase user confidence in navigating the enlarged domain space, that along with a time-framed moratorium, promotional and educational resources and activities related to the introduction of the new gTLDS be developed in areas (geographical, political, social, economic, etc) that were not served well in the first run.

  6. This draft doesn't accurately represent the views of people who think the proposal to reserve three letter codes has no merit. Please note that the ISO three letter codes are not widely used, and as often as not countries use codes other than the ISO ones, e.g., ANG for Angola. If there is a problem with domain applicants squatting on names of any length associated with geographic places, there's already a process to deal with it, as seen with the .patagonia and .amazon applications.

    1. John Levine says:

      "If there is a problem with domain applicants squatting on names of any length associated with geographic places, there's already a process to deal with it, as seen with the .patagonia and .amazon applications."

      There is a process to deal with it? The GAC objected and the ICANN Board had to make a choice themselves. The applicants for .patagonia saw that it would be a costly exercise and withdrew their application. Amazon appealed. At present we are in a deadlock re: Amazon. The Brazilian Government & Amazon should really work this out between themselves, but both are complaining that there was no process in ICANN. This is likely to end in court with the question on whether a country's sovereignty over an unregistered territory name has more rights that a corporation using a name - bearing in mind Amazon is actually registered as Amazon.com Inc., not Amazon Inc. for those very reasons.

      It's just become very messy.

      I gather we're trying to reduce the likelihood of lawsuits, aren't we? So .patagonia & .amazon are not good examples to take because they are messy cases.

      I do agree though with your reference to IOC names (ANG for Angola). If we start reserving ISO 3 letter names, then IOC then FIFA codes then we'll just completely drop the idea of a 3 letter code altogether because they'll be reserves one way or other.... and that would also be very messy.

      1. I really don't understand what the point of this proposal is other than make-work. 

        For over 30 years we've had names in .COM, and nobody has ever claimed they were confused because they weren't in the Comoros. Why is it a problem now? It's like a weird form of statism, everything belongs to the state unless the state's given it away, and if we missed some of it for 30 years, well, better late than never. There's no chance of lawsuits–these codes were assigned in the 1970s, and it's hard to imagine a basis on which they just discovered now that they were damaged. I also note that they're not trademarks.

        I wouldn't underestimate the make-work opportunities. Can a state waive use of its name if someone else wants it? If so, who issues the waiver? The existing ccTLD registry? The government? If it's a name like ASM or PRI or GLP, is it the local government or the national one? If a country's name is in use by someone else, does the country get compensation? If so, who's going to explain that to Verisign? What about ATA which has no government? And so on and so forth. Please kill this bad idea now.

  7. Thank you John. I will try to make this point more clear.

    How about the addition:  The opposing view proposes that there is no merit in reserving 3-letter codes, firstly because current 3-letter codes are not widely used and often as not countries use codes other than the ISO ones, e.g ANG for Angola. Secondly, as every geographical... etc

    And I have added your second point about domain squatting at the end of this paragraph. 

  8. Are there better examples then to demonstrate how we deal with domain squatting?

    1. I am unaware of any domain squatting at the TLD level. There were a few arguable attempts in the latest TLD round but none of them got very far.

      1. It depends what one means by domain squatting. Definitely at TLD level, I am not aware of squatting either today. Historically though, several ccTLDs were originally registered by people having nothing to do with the country relating to the country code.

        Today, some of these services still remain, although with the agreement of the country concerned.

        https://en.wikipedia.org/wiki/Domain_hack

  9. I tend to agree with Roberto Gaetano.  ISO 3166 for two letters is known, used, understood.  And it is those that (with only a couple of exceptions) are managed by the ccTLDs. I also am persuaded by his discussion as to what three letters would necessarily refer to a country - and why have ccTLDs manage both two letters and  three letters for country codes.

    I understand OCL's point about more power in the GNSO, but ask why solve that problem by putting both two letters and three letters in the hands of the ccNSO.

    There are plenty of other issues about new gTLDs (the application book, PICs, compliance, etc) for there to be a reason to sort out all the issues - this can be one, but I don't think this should be the sole reason.

  10. Some thoughts:

    1) No to "should all three-character top-level domains be reserved as ccTLDs only and be ineligible for use as gTLDs?"

    Given the presence of many 3 character TLDs as gTLDs, it doesn't seem prudent to reserve all future 3 character TLDs for ccTLDs, given the confusion as to which 3 characters would be a ccTLD and which is a TLD.

    An advantage to such a policy would be for ccTLDs to have 3 character ccTLDs that may be marketed as complimentary to two character ccTLDs. ccTLD operators will get such TLDs at low cost compared to applying (and paying for) such 3 characters as a gTLD. If the principle of ccTLDs being able to secure the ISO 3166 alpha-3 codes is applied, reserving all 3 characters as ccTLDs would allow for future changes to the ISO 3166 alpha-3 to reflect changes to countries and territories being designated with new codes.

    The disadvantage of such a policy is that it blocks any future three character TLDs for use as possible gTLDs. With many 3 character TLDs already delegated as gTLDs, there is the risk of end user confusion as to what policies would apply to TLD - gTLD registries have contracts with ICANN which stipulates certain conditions that must be met (RAA, WHOIS, PICs, etc) and ICANN enforces such policies via contractual compliance. ccTLDs don't have any such contracts with ICANN and can implement any policy as the ccTLD administrator wants.

     

    2) No to "In future, should all three-character top-level domains be eligible for use as gTLDs as long as they are not in conflict with the existing alpha-3 codes from the ISO 3166-1 list; i.e. the three-character version of the same ISO list that is the basis for current ccTLD allocation?"

    The problem with such a policy is that the ISO 3166 alpha-3 (and alpha-2 for that matter) codes are not static documents, they are updated to reflect changes to countries and territories. So there is a risk that a new country or territory can be allocated a new 3 letter code that would be taken by a gTLD. This would give rise to newer countries and territories being treated differently than the present existing countries with a new country or territory "locked out" of use of their 3 character code whilst older counties having use of their 3 character code.

     

    3) Yes with caveats, to "In future, should three-character strings be eligible for use as gTLDs if they are not in conflict with existing alpha-3 codes form the ISO 3166-1 list and they have received documentation of support or non-objection from the relevant government or public authority? What would be the advantage or disadvantage of such a policy?

    This question appears poorly worded. If a three-character string doesn't exist in the ISO 3166-1 alpha-3 list, there is no relevant government or authority that has any claim to those three characters. If the question is asking "In future, should three-character strings be eligible for use as gTLDs if they are not in conflict with existing alpha-3 codes OR if in conflict with existing alpha-3 codes, such gTLD applications must receive support or non-objection from the relevant government or public authority", then the answer is Yes.

    If there are governments or public authorities that feel they are better recognized or identified by the three character code in the ISO 3166-1 alpha-3, such entries could file objections via their GAC representatives on community or limited public interest grounds or convince the GAC to issue consensus advice against such a gTLD application. Having support and non-objection in hand from the relevant government/public authority would be prudent.

     

    4) No to ""In future, should there be unrestricted use of three-character strings as gTLDs if they are not conflicting with any applicable string similarity rules? What would be the advantage or disadvantage of such a policy?"

    Since some governments or public authorities may feel very strongly that feel they are better recognized or identified by the three character code in the ISO 3166-1 alpha-3, unrestricted use can result in objection challenges by Governments (via GAC consensus advice or filing an objection on community or limited public interest grounds). To facilitate consensus in ICANN's multistakeholder community, it seems prudent to not have unrestricted use of three-character strings.

     

    5) No to "In future, should all IDN three-character strings be reserved exclusively as ccTLDs and be ineligible as IDN gTLDs? What would be the advantage or disadvantage of such a policy?"

    The ISO 3166-1 alpha3 list doesn't use IDN characters and its not clear if there exists an definitive list of 3 character IDN strings that could be used to represent countries and territories. Blocking all 3 IDN characters can likely delay the expansion of IDNs gTLDs. If there are 3 character IDN strings that represent a geographic name (the name of a country or territory, permutations thereof and state names as in the current Applicant Guidebook) then such strings should be rejected as per the Applicant Guidebook. However, I would support any guidance from the At-Large IDN WG

    6) Yes to "In future, should there be unrestricted use of IDN three-character strings if they are not in conflict with existing TLDs or any applicable string similarity rules? What would be the advantage or disadvantage of such a policy?""

    I'm not seeing any strong disadvantages to say no to this, however, I would support any guidance from the At-Large IDN WG

     

     

     

     

  11. I find these comments from Dev closely reasoned and argued and I'm inclined to give them a lot of credence.

    Here's the  thing. We now have existing 2-char & 3-char ISO country standards.  We appear to accept the restrictions for 2-char gTLD delegations imposed by 2-char ISO list.  Our concern seems not to extend to how the 2-char ccTLD could be marketed and used.  All good so far.

    Per the IANA list, we have existing 3-char generic, 3-char country, 3-char sponsored, 3-char generic-restricted TLDs. Do we have evidence of consumer confusion between these categories now and if so, how is that resolved today?

    The ISO can add new 3-char country codes at their time of choosing. Same thing for 2-char country codes. So, we assume there is a process that is employed by the ISO. Could the ISO add 3-char country codes and 2-char country codes that could be confused with existing 3-char and 2-char TLDs?  Maybe. Do we know the process used by the ISO to deliver either set of codes? Is part of that process an environmental scan and, thereafter, maybe a rejection of proposals for codes that already exist and are used for one or other qualified thing?

    The answers we get will give guidance towards how we could bell this cat. And, I daresay, even who should be doing so!

    I know of one case where the application for a 3-char gTLD from a small company in a developing economy was denied, allegedly for violation of the 3-char ISO country code.  This led to another conundrum when the applicant put in a change request for a string, not on any reserved list that I can find but exhibited as part of a valuable (question) domain name at the second level. That application was never evaluated, allegedly for cause.

    There are real life implications with the answers here.  My position is one of verifiable decisions. Which is to say, some agreed means to audit them. Yes indeed, I very much prefer trust with verification.

     

  12. To respond to Carlton, I found a buried page about ICANN and ISO. Quite informative:

    https://www.icann.org/resources/pages/icann-iso-3166-2012-05-09-en