1/5: Community Priority Evaluation not fair enough

[Amadeu Abril i Abril <amadeu.abril@xxxxxxxxxxx>]

[This is the first of a series of five comments on Community Priority 
Evaluation]

CORE raises once again its concerns with the now called Community Priority 
Evaluation Procedure. While we are not completely convinced that this sort of 
detailed and fractioned bit/no bit scoring is the best procedure (see our other 
comments in this same Forum), we will not challenge the mechanism here. But we 
are seriously concerned that the criteria as defined and the scoring needed (14 
out of 16) might exclude and penalize a fair number of perfectly desirable 
“real” community-based applications. 

We welcome the use of examples, and note with interest that “linguistic” or 
“geographic” TLDs are mentioned several times. Our concern is that, given the 
current rules, and depending on their interpretation, existing test-cases such 
as .cat (or even .mmuseum or .coop) and city TLDs such as the proposed .paris, 
.berlin or .bcn would most probably fail in this exercise. We know that this is 
not ICANN’s goal, quite the contrary, so there must be a misunderstanding on 
our side, or an error in the scoring mechanism. In our evaluation, for 
instance, .cat (and similar TLD proposals) would score probably a 12; may be a 
13, even perhaps a 14 under certain (not eveidnet) interpretation of some 
concepts.   Let’s see where the main problems are detected.

A) “Delineation”.

ICANN should clarify whether a proposal such as the existing .cat would score a 
1 or a 2. DAGv4 seems still to be completely hostage to the notion of 
“community is a group of clones carrying a membership card with an ID stored in 
a cnetral registry”. Most communitites are not ID-carrying ones. While the 
community of those using Catalan (or Galician or Welsh) for their online 
communications can be easily defined and identified, it is not a an exercise 
that can be done perfectly “ex ante”. There is a degree of ex post delineation. 
It is not a bout “inventing” a community, or circularly defining it by the fact 
of registering the doa¡main name. It is simply a reality check: communities are 
often something else than membership associations. 

So ICANN should more clearly delineate the notion of “clearly delineated 
community”, and when is it “bound” or unbound” and the consequences of 
definitions such as the onlu workable ones for linguistic and cultural TLDs as 
to the scoring in this area.

B)Uniqueness of the name

The problem here is the balance between the meaningul connection with the 
community, and the accidental meaning it might have in any language even if 
completely unrelated to the community. We fail to grasp the real meaning of the 
examples provided. Would .cat miss a point beacuse “cat” is the name of an 
animal in English? It does seem so. And .gal because in informal English it is 
a youg woman? And in Breton is a French person? What about .paris: here is in 
French, the most relevant language for the proposed city TLD, it does mean 
“bets”, in plural. So, yes, we can bet that most users would be really confused 
when seeing toureiffel.paris and would thin k it is a site to bet on the real 
height of the tower:-)

We think that a) ICANN should introduce an element of likely confusion, and b) 
some intentional attempt by the applicant to engage in double-use of the TLD 
should also be detected. Penalizing applicants because of accidental an 
unintended similarities to words in other languages is absolutely unfair. For 
.cat, any other choice would have been artificial, and difficult to understand 
by the relevant community. Losing 1 point (half the total amount an application 
can risk in this exercise!) because of an accidental similarity, and penalising 
this exactly with the same amount as, for insantce, not having any sensible 
eligibility rules or enforcement mechanism seems unfair, counter-intuitive and 
counter-productive. 

C( Registration policies

Here lies our main concern. As we saw under “Delineation”, the obsession with 
ID-carrying membership associations as the desired model carries here with the 
need to apply strict eligibility rules on a previously identified population. 
Therefore, using again the language-based TLD, example, the very nature of the 
TLD, independently of the willingness to apply strict registration policies 
cause the loss of a second point, almost automatically.

Even more frustrating is that name selection rules carry the same scoring as 
eligibility rules, content rules and even enforcement. Neither a linguistic nor 
a city TLD can enforce name selection beyond launch/sunrise periods. It simply 
does not make sense. I might be eligible for a .cat or .bcn name. I might 
respect all their content and usage constraints. But how could name selection 
be enforced? should I only be allowed to register my legal name? in which form? 
amadeuabriliabril.TLD? amadeuabril.TLD? abril.TLD? amadeu-abril.TLD? 
amadeu.TLD? all of them? Some are my name, but not the legal expression of my 
name. And why would .cat or .bcn prevent me or wish to prevent me from 
registring a “fantasy name” for my personal blog, such as “nightowl.cat” or 
“Amadeufavoriterestuaurants.bcn”? Oh, yes, simply to score an extra point in 
the evaluation process.  Name selection makes sense for .museum ad proved not 
to make sense for .coop. Nor for .cat or many others. It does not mean that 
.coop or .cat are irresponsible or fake community TLDs at any rate. Quite the 
contrary. They achieve similar results by way or either eligibility or content 
ruels + enforcment. Having any language or city TLd, or any other community TLD 
proposal lose 1 point for not invienting unworkable name slection rules, 
exactly the same as if they had opposition within their community or lacked 
nexus between community and name makes no sense at all.

We think that what ICANN wants are sensible registration policies. They can be 
achieved by a combination of eligibility, naming and content rules. A 
combination, but sometimes eligibility + content rules will make name selection 
redundant, useless or simply unworkable.  Therefore they have to be combined 
into one examination, scoring from 0 to 3, depending on the consistency between 
the proposed system and the definition of community.

Or, at very least, Eligibility rules should have a wider range of scoring, 
allowing for more granularity than he current binary proposal, where many 
applications risk getting a 0 because they do have eligibility rules, but not 
the maximum airtight kind of rules. This should have more weight than name 
selection, for sure. 

D) Scoring

If ICANN wants to keep the current scoring system, we propose, as we have 
said,, that eligibility rules have an extended range, and/or all registration 
policies are examined together. We would also ask for a wider range under 
community delineation, bringing the total to 17 or perhaps 18. Under this 
system that somehow imposes double penalties (delineation and eligibility for 
non-membership based communities, for instance) and provides for accidental 
“fails” outisde the control of the applicant (lack of “uniqueness” due to some 
coincidence  or similarity in any other language) having the ability to miss a 
third point is critical even for most reasonable, archetypical, well-thought, 
fully supported, responsibly policed proposals.

We look forward running the scores" on existing and model applications with 
ICANN staff, as we have done in the past, to verify these inefficacies.

Amadeu Abril i Abril
CORE Internet Council of Registrars