Comments on Evaluation Procedures
2.1.1.1 String Confusion Review at p2-4. The text "Such category of objection is not limited to visual similarity. Rather, confusion based on any type of similarity (including visual, aural, or similarity of meaning) may be claimed by an objecter.", mid-page 2-4, is novel. I don't recall any GNSO resolution on the issue of confusingly similar, or any ICANN BoD resolution on the same area of policy, originating a policy on "aural similarity". Unless a GNSO Council or ICANN BoD cite can be found authorizing staff to expand the scope of tests for similarity from "visual" to "visual plus something else", this new text must be withdrawn. We've already gone down the path of having to change "air" to "aero" to accommodate a nearly deaf member of the Board, we don't need to have Verisign object to .cym because some people pronounce a Welsh word like the common pronunciation of .com ("u" vs "o" vowelization). 2.1.1.3.2 String Requirements at p2-8 and p2-9. I've previously commented on what I think is an excessive restriction of numeric labels, and while I don't think the issue is solved as minimally as necessary, there are other engineers who are much more conservative on this subject and staff is reasonable in adopting the more conservative view, for the time being. 2.1.1.3.2 String Requirements at p2-11, footnote 4. The three character requirement is clearly wrong for several scripts, and as domain names are identifiers more easily remembered than dotted quads, as well as being potentially more persistent in the presence of periodic renumbering, it is contrary to the design goal of having identifiers to have to pad something memorable and identifying with an extra character. We don't want people to have to write obvious identifiers and have to add one extra well-known garbage character -- the ICANN padding character -- the obvious manifestation of one alphabetic script's users power over all other scripts users, and the indifference of that power to writing correctly in every script other than the Roman script, and mostly just to avoid some odd notion of looking like iso3166 allocations, which is irrelevant to writing in any script at all. 2.1.1.4.1 Categories of Strings Considered Geographical Names at 2-12, footnote 5. My recommendation to Jon shortly after he settled on iso3166 as the tool to delegate zone file editorial work to scale with the growth of new network attached hosts was that we create registries for the continents, using X.121's eight regions, allowing stateless peoples some means to add SLDs. The requirement expressed in the final bullet point of 2-12 and continued on 2-13, for "documentation of support , or non-opposition, will be required from a substantial number of the relevant governments and/or public authorities associated with the continent or the UN region" is problematic. We can use continents to solve problems caused by an excessive reliance upon nationalism, we shouldn't be turning over continents to the very governments which cause the problem we're trying to solve. It is no secret that there is little "service" to Africa, South America, and large parts of Asia. We have to ask, and answer, why .africa has to wait on "a substantial number" of 53 governments, and similarly why the Arab League has to jump through hoops to get a iso3166 label, given the dozen or so non-territorial allocations in the current table (regional IPR allocations). 2.1.1.4.3 Review Procedures for Geographical Names at 2-15 to 2-16 "If there is more than one application for a string representing a certain geographical name ... and the applications are considered complete ..., the applications will be suspended pending resolution by the applicants." This is the outcome we've advocated for divided communities, that the process not go to award. This model should not be restricted to geographical identifiers, it should apply to community identifiers as well. 2.1.2 Applicant Reviews at 2-16 to 2-20 and 2.2 Extended Evaluation at 2-20 2-23. The conduct and competency of the external evaluators in the .org and the later .net redel left a great deal to be desired. While the evaluation of the 2004 applications was substantially improved through the use of better evaluators, the scale of the current round makes it possible that less competent evaluators will be selected. We've suggested during the face-to-face meetings, and in prior public comment, that some subset of the applications we are aware of meet the "safe and sane" test of many of us who have been involved in registry applications and operations over the past decade, that despite our status as competitors, we can look at each other's applications and quickly triage them into "safe", "unsafe" and "takes more thought" baskets. This comment is developed further in Comments on Introduction to New gTLDs Application Process, section 1.1.5, Subsequent Application Rounds, submitted separately. I work for CORE, CORE will submit applications, so this interest in the outcome should be included in my comment. Eric Brunner-Williams |