Re: [lac-discuss-en] Re "Introduction of Two-Character Domain Names in the New gTLD Namespace" Public comment



This is a user issue and country issue (i.e. GAC). If one looks at the
amount of unassigned 2 character labels  in the ISO 3166-1 table,  It might
difficult to make an argument for protection only to ensure that future
countries and territories have access...especially when one looks at the
rate at which that happens. From a purely user perspective one may well
argue that the more domains available the better.

Lance


On Thu, Jul 10, 2014 at 2:04 AM, Dev Anand Teelucksingh <devtee@xxxxxxxxx>
wrote:

> Regarding the public comment on "Introduction of Two-Character Domain Names
> in the New gTLD Namespace" at https://community.icann.org/x/VqzhAg
> which ends July 10 2014, I've posted the following at
> https://community.icann.org/x/VqzhAg
> for consideration:
>
> "Various registries for multiple gTLDs are applying for exceptions to
> Specification 5, Section 2 of the New gTLD Registry Agreement
> ("Specification 5") with some registries suggesting the release of 2
> character ASCII labels not on the current ISO 3166 standard would suffice.
>
> While this seems harmless, there is a possibility of new countries and
> territories being created, and then allocated a new two character ASCII
> label by ISO 3166/MA (see
>
> https://web.archive.org/web/20111101141651/http://www.iso.org/iso/country_codes/iso-3166-1_decoding_table.htm
> ).
>
> Any new country or territory created after 2014 would therefore not receive
> the same protection as those in the 2014 ISO 3166-2 list and would find
> that their new 2 character label is "given away", should they wish for
> their 2 character ASCII label to be protected, as per Specification 5.
>
> Now, should the principle established by Specification 5 protecting 2
> character ASCII labels even be in the New gTLD Registry Agreement? Many
> would say, especially given the prevalence of two character labels in
> existing TLDs like .com, .org and .net that this principle shouldn't be
> applied to new gTLDs.
> However, this (IMO) is a separate issue to the question being asked for in
> the public comment.
>
> If Specification 5 is meant to defend the principle that country codes in
> ISO 3166-2 should be protected in new gTLDs, then it should be enforced to
> ensure future countries and territories with new 2 character ASCII labels
> are protected in the same way as those territories and countries in today's
> ISO 3166-2 list.
>
> Therefore, the proposals by Donuts for 143 of its new gTLDS, .kred by
> KredTLD Pty Ltd, .best by BestTLD Pty Ltd and .ceo by CEOTLD Pty Ltd.
> should be turned down in keeping with the principle of Specification 5.
>
> The proposal by .wiki by Top Level Design LLC which specifies that the two
> character ASCII labels will only be used for languages identified by ISO
> 639-1 does appear to meet the threshold that the use will not be confused
> with the corresponding country codes, as per Specification 5 and could be
> approved.
>
> Similarly, the proposal by .globo by Globo ComunicaÃÃo e ParticipaÃÃes S.A
> which proposed the use of two character ASCII labels that are not letters
> or by two characters where only one of the character is a letter are labels
> that would not be used by ISO 3166-2 and could be approved."
>
> Thoughts?
>
> Kind Regards,
>
> Dev Anand Teelucksingh
> _______________________________________________
> lac-discuss-en mailing list
> lac-discuss-en@xxxxxxxxxxxxxxxxxxxxxxx
> https://atlarge-lists.icann.org/mailman/listinfo/lac-discuss-en
>



-- 
Lance Hinds
Chief Technology Officer
BrainStreet Group
287 'C' Albert St.
Georgetown Guyana




This message contains information that may be privileged and/or
confidential and is the property of BrainStreet Technologies or BrainStreet
Learning. The information contained herein is intended only for the
individual or entity to whom it is addressed and others authorized to
receive it . If you are not the intended recipient, you are not authorized
to read, print, retain, copy, disseminate, distribute, or take  any action
in reliance to the contents of this information or any part thereof and it
may be unlawful to do so. If you receive this message in error, please
notify the sender immediately and delete all copies of this message from
your system. BrainStreet Technologies or BrainStreet Learning are neither
liable for the proper and complete transmission of the information
contained in this communication nor any delay in its receipt.
_______________________________________________
lac-discuss-en mailing list
lac-discuss-en@xxxxxxxxxxxxxxxxxxxxxxx
https://atlarge-lists.icann.org/mailman/listinfo/lac-discuss-en