Comparative Evaluation: trying to minimize contention
[Proposal summarized at the end of the post]PROBLEM: The current draft rightfully attempts to provide a mechanism by which real, representative community-based applications succeed over open applications, and a mechanism for solving string competition in general. But a couple of flaws would lead to undesirable results in a number of cases. One such flaw is the lack of tools for the parties to negotiate, other than money (and, perhaps, threats). The other is trying to sove through “an efficient mechanism” that so far everybody identifies with auctions a situation in which not allocating the TLD would be more efficient to all parties involved (when multiple applicants for the same community-based TLD pass the evaluation and are all of them representative of such community).
SCENARIO.When defining what happens in comparative evaluation in the presence of multiple community-based applications the draft seems to assume that all those applications would represent the same community. And this is not necessarily the case. Let’s imagine an application for .cat, intended for the Catalan Linguistic and Cultural Community, and another .cat for... well, cats. Let’s assume both are community- based (and, if you have difficulties imagining a community of felines being represented, pick any other example ;-). The String Contention procedure starts by asking the parties to privately negotiate... who stays, who goes. But they are not allowed to either change strings or modify their application. So what’s left? Money, indeed. Or gambling (ok, I withdraw my application for XZY if you withdraw yours for ABC and DEF...). This might (and will...) work for open, commercial applications. But most community-based applications, at least the “real”ones, won’t have anything to discuss here. Take the entities that submitted .cat in 2004 (language and sciences’ academies; universities; writers’ associations; shools; cultural enttities; radio associations, etc, etc). Neither do they have the financial ability to participate in such games, nor can they “accept” any money in exchange of the ....name of their language, their culture, their identity. It simply cannot happen. And indeed, they won’t indulge in strategic submissions of “fake” applications (.sex, .web, whatever) just in case they need somehting to bargain with. So they have nothing to negotiate, except explaining why is important to them, and... go to Comparative Evaluation.
But wait: why could not .cat-for-animals change its string to .cats? This would eqully represnt their goal, and could not be confusing in any way with .cat-for-language-and-culture. So both parties could easily agree on this one, but the rules prevent it.
We understand the goal of limiting gaming, or the situations we epxerienced in 2000 (.web/.info; .air/.aero). But here we are not talking about external interventions, arbitrary or not, nor about promoting the gaming of the system. We are dealing with unforeseeable accidents, that cannot be solved through money or “my community is bigger than yours” (or deserves more respect, or whatever).
In this regard, ICANN should consider a limited “string modifying period”, only for these cases (multiple community-based applications, serving different communities; or one community-based and one open...). This should be done in presence of an ICANN-appointed mediator, with a reasoning memorandum justifying the change, and for a very limited period (one week, maximum two weeks). In fact, the agreement would be either easy or impossible. The parties would pay the madiator fee, indeed.
Ideally, this period should be placed immediately before starting the Ealuation. But should not delay such evaluation: the parties would be invidted to participate, the evaluation for their strings and applications would not start until a decision (status quo; changing one or more of the strings) would be agreed (in two weeks maximum, as stated). Alternatively the period could occur once the evaluation (including extended evaluation and RSTEP) and objection procedures would be solved, if any.
We could argue that this mechanism should be offered in fact to all applicants. Coincidences do happen, and in most cases, the intended use and goal of the TLD could be served by another string, allowing both applications to coexist, instead of forcing a shoot-them-dead scenario.
Now let’s imagine the next scenario (used in other comments, as well): Both ccNSO and GNSO apply for .ROOT (or .IANA). Once again, please forget that the strings are reserved, and that those “bodies” do not have legal personality. It’s just an scenario. It could happen that neither GNSO nor ccNSO knew the other entity would apply for .ROOT. Now they face the evidence. As much as we see the need to prevent frivolous changes of submitted applications, this scenario calls also for a possible mediation-overseen period of, again, two weeks, in which the parties could join their forces. But the applications would be different, in policies, technical specifications, governance. Some work to do. The proposal here would be to allow those smae two weeks for reaching the agreement, and one further month for re-submitting the modifications to the (surviving) application. With the understanding that such re-formulated applications go immediately at the end of the queue for evaluation. Or even that they will be evaluated only after completing all steps with the un-modified submissions. We really thing that a delayed (and more expensive, if required) evaluation and approval of such application would be by orders of magnitude a better solution than having the parties (here the ccNSO and the GNSO) shooting one each other, of “buying off” their better right to .ROOT.
But let’s imagine that nothing of this happens or succeeds. And that we end up with more than one community-based applications that pass the Comparative Evaluation (score 11 or 12). Comparing the community and their support does not help much, in the first example of .cat (felines vs. cataln-speaking folks?). And it is even worse in the case of the same community: if all of them are deemed to rpresent an equal, equivalent or at least sixalbe part of their community, the solution is that famous “efficient mechanism” that translates as “auctions-but- we-prefer-not-mentioning-‘em-yet”. No. In those cases (ccNSO against GNSO for .ROOT, differnt Cherokee nations, in the example provided by Eric Brunner-Williams in this same forum ,etc) the best solution, the ONLY solution is not to establish the TLD. ICANN, the Internet and that, divided, community would all be much better off without such an unneeded, contentious solution. ICANN cannot be the place to solve communities’ internal deadlocks. And it cannot foster “civil wars” by artificially declaring winners and losers. It is better to let them think about it and come next time with a feasible solution.
PROPOSED SOLUTIONS:· Establish a two-weeks period for bilateral (or multilateral) “string modification” under the auspices of an ICANN-appointed mediator. This could solve the “unforeseeable conflicts” in some cases (as the mentioned .cats/.cat). This period should happen ideally before the Evaluation Period, or alternatively, after Evaluation (including Extended Evaluation and RSTEP) and Objections Procedures. · Establish a parallel and similarly-limited period for negotiating the merging of proposals whenever there is more than one community-based Application for the same community, also under the control of an ICANN-appointed mediator. If agreement is reached, the parties would have a further month to amend one of the applications, if needed, and such reformed application would be put at the very end of the evaluation queue, not delaying the process for other applicants. · In case more than one community-based TLD passes the Comparative Evaluation (scores 11 or 12), and both applications are deemed to represent or have the support of similar or even sizable parts of the intended community, ICANN should refrain from allocating such TLD in this round, and the parties (both community-based and eventual open applicants) should resubmit it at the next application window, if they wish so.
Amadeu Abril i Abril CORE Internet Council of Registrars