ICANN ICANN Email List Archives

[gtld-evaluation]


<<< Chronological Index >>>    <<< Thread Index >>>

Comments on Standard for String Confusion

  • To: gtld-evaluation@xxxxxxxxx
  • Subject: Comments on Standard for String Confusion
  • From: Eric Brunner-Williams <ebw@xxxxxxxxxxxxxxxxxxxx>
  • Date: Fri, 05 Dec 2008 23:00:58 -0500

This comment is the written statement of informal remarks made to Kurt during the Cairo meeting concerning this issue. Note that the hypothetical I offer here is just that, my hypo.

Comments on Module 2 -- Evaluation Procedures

1. 2.1.1.1 String Confusion Review at Page 2-3 Standard for String Confusion, reads in part "or strings requested in ccTLD processes", and later at Page 2-4, "ICANN will take steps to resolve the conflict", and at 2.1.1.4, Geographical Names, page 2-9, expands the range of strings from the two-byte sequences allocated as iso3166-1 to "meaningful representation of a country or territory name ... in any of six [] languages", and subnational place name, such as those listed in iso3166-2, or city names (with some intent offered) and "string which represents a continent or [] region".

This clearly co-mingles immediate and important issues like gTLD applications for strings that look like country codes, and non-immediate and possibly non-important issues potentially posed by gTLD applications for well-known terms refering to place names which pre-exist all present governments.

An example of the first class of real issues, suppose the .us operator files a gTLD application for the Chinese language sequence 美国 (pinyin Měiguó meaning "beautiful country", aka the US, in Chinese), and offering a Chinese language IDN of a "US zone" under a different set of constraints than the ccTLD. More generally, any gTLD applicant who is "more aware" than any ccTLD operator could, if this restriction were absent, apply for, and apply before, a ccTLD operator becomes able to start up its IDN registry, with or without "fast-track". Most ccTLD operators fall into "not ready" category, and the pathological case to prevent is denial of an existing service by a government in the scripts used by that government.

An example of the second class of is a gTLD application for Africa, or Paris, or Appalachia, for which no ccTLD in any script is possible, with the exception of one ccTLD which is assigned to a country which is a continent. In this case the pathological case to prevent is denial of a new service by a government which is incapable of ever offering a service.

I proposed X.121 regions to Dr. Postel, to resolve the problems created by excessive dependence upon iso3166 -- the rise of non-functional nationalism in network operations, and the inability to accommodate non-national user populations. If we're never going to have a .africa, it should be for better reasons than assuming that some dysfunctional state has a problem with someone attempting to offer useful service, or the actual demand by one or more dysfunctional states that their perverted construction of Jon's choice of a text to allow scaling has promoted them to a position to conduct a denial of service on an entire continent, or region, of users.

I propose that the second class be removed, and 2.1.1.4 be moved to a supporting materials reference, and we test for collision with ccTLD Fast Track only.

Eric Brunner-Williams
CTO, CORE and FOJ




<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy