Hi,

It is my assumption that they want to ban these names in gTLD (generic
top level domains) space and not ccTLDs (country code top level domains).

I agree, though, ccTLDs are a best buy, and I have been focusing on
them, especially .is for a while now as a source of domain names.

avri

On 03-Oct-14 15:49, Carlos Raúl G. wrote:
> Dear Robin,
> 
> What if, under the same concept of subsidiarity, instead of
> Governments, this responsibility would be delegated to the respective
> ccTLDs? Would it be more or less legitimate? Let me tell you that at
> least in the case of Costa Rica, our Government is more accountable
> and far more bottom up than the ccTLD chosen by ICANN.
> 
> After the sour experience with .amazon and .patagonia I certainly
> agree that changes are necessary, probably at many levels.
> 
> If you have a better suggestion, I would love to hear it.
> 
> Best
> 
> Carlos Raúl Gutiérrez +506 8335 2487 Enviado desde mi iPhone
> 
>> El 3/10/2014, a las 13:17, Robin Gross <[log in to unmask]>
>> escribió:
>> 
>> I think we should submit comments on this proposal from a GAC
>> Sub-group on Geographic Names in future gtld rounds to "respect
>> national sensitivities".
>> 
>> In short, the GAC proposal calls for a change in the policy in the
>> applicant guidebook to require applicants to obtain the permission
>> of governments before they can use a word that could be considered
>> a country, territory or place name, and country, territory or
>> regional language or people descriptions.
>> 
>> GAC wants to override the GNSO's policy from 2008 and the AGB.  GAC
>> relies heavily on the presumption that restricting gtlds in this
>> fashion is automatically in the public interest and therefore ICANN
>> must do it.  Of course it will have the effect of dramatically
>> restricting speech in tlds and further empowering governments over
>> people's use of the Internet.  Unfortunately the GACification of
>> ICANN continues apace.  Sigh.
>> 
>> Robin
>> 
>> https://gacweb.icann.org/display/gacweb/Governmental+Advisory+Committee
>>
>> 
Draft document from GAC Sub-group on Geographic Names - Community input
sought
>> The GAC Sub-group on Geographic Names (a Sub-group of the GAC
>> Working Group on Future New gTLDs) has developed a draft document
>> for future New gTLD rounds outlining several public policy aspects
>> related to geographic names and is currently seeking community
>> input on this document:
>> 
>> The protection of geographic names in the new gTLDs process.
>> 
>> A previous version of this draft was presented in a public session
>> during the London ICANN/GAC meetings and a similar session is
>> planned for the October ICANN/GAC meetings in Los Angeles.  The
>> Working Group believes the receipt of community input on the
>> current draft document would be beneficial to the October
>> discussions, and further welcomes comments from all interested
>> parties by October 31, 2014.
>> 
>> Comments may be submitted to [log in to unmask]
>> .
>> 
>> Comments received will be posted on the Community Input page at:
>> http://tinyurl.com/nc4knhn.
>> 
>> ----------------------- Paper's Conclusion:
>> 
>> ... Suggested changes in the Applicant Guide Book
>> 
>> Taking into consideration that the Durban Communiqué states that
>> “The GAC recommends that ICANN collaborate with the GAC in
>> refining, for future rounds, the Applicant Guidebook with regard to
>> the protection of terms with national, cultural, geographic and
>> religious significance, in accordance with the 2007 GAC Principles
>> on New gTLDs”, a new text is suggested regarding the geographic
>> names, in the case that the same text of the present AGB will be
>> used as ground document:
>> 
>> To include in the paragraph 2.2.1.4 of the AGB the following
>> sentence:
>> 
>> “ICANN should avoid country, territory or place names, and country,
>> territory or regional language or people descriptions, unless in
>> agreement with the relevant governments or public authorities”.
>> 
>> Also the following paragraph appears in the section “2.2.1.4.2
>> Geographic Names Requiring Government Support” of the AGB. It
>> should be a general statement or principle regarding geographic
>> names, in order to clarify and reinforce the importance of the
>> previous communication between the Applicants and the Governments,
>> even in case of any doubt.
>> 
>> “Nevertheless, in the event of any doubt, it is in the applicant’s
>> interest to consult with relevant governments and public
>> authorities and enlist
>> 
>> their support or non-objection prior to submission of the
>> application, in order to preclude possible objections and
>> pre-address any ambiguities concerning the string and applicable
>> requirements.”
>> 
>> A specific reference to the Geographic Names Repository described
>> in section 6.b of this document must be also included.
>> 
>> The suggested changes in the Applicant Guide Book, paragraph
>> 2.2.1.4 of the AGB should read as follows:
>> 
>> “2.2.1.4 Geographic Names Review
>> 
>> Applications for gTLD strings must ensure that appropriate
>> consideration is given to the interests of governments or public
>> authorities in geographic names, taking into consideration that,
>> according with the 2007 GAC Principles regarding New gTLDs, ICANN
>> should avoid country, territory or place names, and country,
>> territory or regional language or people descriptions, unless in
>> agreement with the relevant governments or public authorities. The
>> requirements and procedure ICANN will follow in the evaluation
>> process are described in the following paragraphs. Applicants
>> should review these requirements even if they do not believe their
>> intended gTLD string is a geographic name. All applied-for gTLD
>> strings will be reviewed according to the requirements in this
>> section, regardless of whether the application indicates it is for
>> a geographic name.
>> 
>> “Nevertheless, in the event of any doubt, it is in the applicant’s
>> interest to consult with relevant governments and public
>> authorities and enlist their support or non-objection prior to
>> submission of the application, in order to preclude possible
>> objections and pre-address any ambiguities concerning the string
>> and applicable requirements.”
>> 
>> 
>