Comparative Evaluation: trying to minimize contention

[Amadeu Abril i Abril <Amadeu@xxxxxxxxx>]

[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