ICANN ICANN Email List Archives

[2gtld-guide]


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

Minds + Machines Comments on the new Draft Application Guidebook

  • To: 2gtld-guide@xxxxxxxxx
  • Subject: Minds + Machines Comments on the new Draft Application Guidebook
  • From: Antony Van Couvering <avc@xxxxxxxxxxxxxxxxxxxx>
  • Date: Mon, 13 Apr 2009 12:58:47 -0700

Thank you for the opportunity to comment.

First, we would like to thank ICANN staff for their diligent work in producing a much-improved draft of the Application Guidebook. While the new guidebook is much improved, we believe there is room for additional improvement in the following areas.


I.  Evaluation Panel Procedures:
At present, there is no published procedures on selecting Comparative Evaluation panelists. In order to preserve fairness, we would like to see clarification of how panelists will be selected. Specifically, we would like to see ICANN conduct a conflict of interest check. Given the small size of the ICANN community (and therefore, of qualified panelists), the risk of conflict interest is great. We would like ICANN to conduct (and stand by) a conflict of interest check, and require panelists to provide a written conflict of interest statement specifying where they might have a conflict.

II.  Scoring for Community Applications
A score of 12 (instead of 14) should be sufficient to be qualified as a community under the Comparative Evaluation procedures. We are concerned that the current high bar, although useful for making sure that the TLD serves the community, is so restrictive that it may cause registries to fail because they will be unable to attract qualified applicants, for two reasons: (1) the vetting of applications would be so cumbersome that it would discourage registrations, and (2) that qualified applicants would be refused. For instance, if .NYC wanted to score a 14 by restricting registrations to registered residents, it might be unable to allow native-born New Yorkers who now live in Florida to register under .NYC, or to allow companies headquartered elsewhere to register, even though they have significant presence in New York City.

III. String Contention
We are concerned that current string contention policies based on meaning (as opposed to string similarity) may discourage valid applications. The best way to illustrate this is through an example: .VIN vs. .WINE. These two strings, while referring to the same commodity, could serve entirely different needs and communities.

There is a currently announced .VIN, which would serve the French wine community. A .WINE might serve the U.S. wine community. There is no necessary conflict between these two strings, which serve different communities.

Therefore, if two or more applications serve, and are backed by, two different communities, ICANN should find a way to allow both.

IV. Auction Procedures
We are concerned about gaming of the auction procedures, and about the possibility of illegitimate auction contenders. Let us suppose that an applicant for .STRING realizes that there is going to be an auction, and that while they do not have the funds to win, they wish to (a) drive up the cost for the competition, or (b) get paid off to go away.

To prevent this kind of behavior, we propose the following:

1. ICANN should require proof of ability to pay
2. 20% of each bid increment should be non-refundable to prevent non- serious bidding. 3. The parties should be contractually obligated to pay in case they win.

At present, there is no disincentive to drive up the bidding by a non- serious party.

V. Existing ccTLDs and Geographic TLDs
There may be legitimate applications for territory, country, or regional gTLDs which may appear to conflict with existing ccTLDs. But because existing ccTLDs may have very high prices, or very restrictive registration policies, the relevant governmental authority, along with the community affected, may strongly support a new gTLD. If a community and/or government authority wishes to support a gTLD application, this should be allowed.

VI. Multiple labels for the same geographical term
From both an IDN and ASCII perspective, current ICANN rules require double (or triple) payment. For instance, .koln, .köln, koeln, cologne. Cities or regions which are widely referred to by multiple labels should be given an opportunity to use all of these labels for the same price.

VII. Rights Protection Mechanisms
We are highly encouraged by the procedures recommended by different parties to help solve the besetting problem of protecting the rights of intellectual property owners. First, the trademark validation database put forward by Bart Lieben of Lada is, we believe, a way to provide for inexpensive and error-free Sunrise periods (or similar pre-launch registration opportunities). Second, Demand Media's rapid takedown proposal offers a less-expensive and far quicker method to deal with obvious cybersquatting attempts.

With thanks again for the Guidebook and the process for improving it,

Antony Van Couvering
CEO, Minds + Machines


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

Privacy Policy | Terms of Service | Cookies Policy