It's also worth noting that almost the same issue exists with the dot-gay community ruling.

A third party evaluator made their evaluation. It doesn't seem right to a lot of people. But ICANN's accountability processes are only capable of looking at process rather than correctness of decision.

I think Bruce's engineer comment is very useful in that it highlights not only how ICANN has got things wrong in some areas but also why there is a significant disconnect between different groups.

The fact is that new gTLDs go beyond mere technical considerations: an "i" looking similar to an "l". They are words, and people associate meaning to them. That is the case both for users and for applicants.

ICANN wants to apply technical rules to human issues and when that doesn't work it calls in legal argument. Legal argument then immediately creates an adversarial relationship between ICANN and whoever want to be heard.

In the human world here is what happens:

* Technical rules fail to account for all possibilities

* As a result there is a bad call

* The person at the end of the bad call wants people to take a look at it

* ICANN refuses to listen

* They get annoyed

In the ICANN world, this is what happens:

* The rules were created by everyone

* The rules were followed

* Someone didn't like the rules so they are trying to force a change to them

* We need to protect the rules or the system will break down

* This person is threatening the organization by challenging the rules

There are two fundamental beliefs that are behind ICANN corporate's inability to see how it needs to change to deal with these persistent problems:

1. You can't admit fault

2. Process is the answer

Both are wrong.

ICANN can - and should - admit fault. It should be able to say: we created these rules to the best of our knowledge but we didn't account for this possibility. In this case the rules did not provide the right answer.

And second, the blind belief in process as a panacea when it often creates distrust and exacerbates the problem. As we have seen from this dot-hotels example, the different process steps kept giving back the same answer because they asked basically the same question each time.

But the right question was never asked. ICANN may have "won" but we all know that the problem that was there at the start is still there and still hasn't been tackled: is "hotels" and "hoteis" really similar in this context? Would they really cause widespread confusion?

As I think George Sadowsky pointed out, the fact is that most content on a "hoteis" website is likely to be in Portuguese. That is going to create a much stronger dissonance than someone mistaking an 'i" for an 'l" in the browser bar.

George was applying human judgment. But ICANN continues to undervalue that approach. It's perhaps not surprising given the organization's technical background and remit. But it is time to change.

Legal process needs to be put at the end of the line, when everything else has failed, not as the first port of call. And human judgement needs to be inserted at the post-implementation stage.

Kieren

On Thu, Mar 5, 2015 at 1:20 PM, Bruce Tonkin <Bruce.Tonkin@melbourneit.com.au> wrote:

Hello Greg,

>> Where the SSRP went awry was in its actual results. I'm not prepared to say this was a design flaw or a process flaw. But the results flabbergasted many people. Somehow it seemed to mutate into a "bad eyesight similarity review," since the only two "positives" were one where "i" gets confused with "l" and one where "rn" gets confused with "m". Meanwhile, singulars were not similar to plurals. So "hotels" is a similar string to "hoteis" but not to "hotel". "Fascinating," as the late Mr. Spock might say.

>> But -- there's no recourse for results, unless a process was not followed. So all of this stands. In a similar vein, it became apparent to many that all of the Objection processes should have an appeal mechanism, if only to deal with inconsistent results (though I tend to think it should be able to revisit the merits of each case as well). This is absolutely a design flaw in my mind. So, I think we can embrace the fact that these processes resulted from multistakeholder activities without believing that this makes them perfect or unassailable.

Yes – one of the original goals from the new gTLD policy was:

“New generic top-level domains (gTLDs) must be introduced in an orderly, timely and predictable way.”

The predictable bit to me – would be that if you formed another panel of experts with respect to string similarity – that the results would basically be the same. I don’t think the current iteration of the string similarity test meets that requirement yet. As an engineer - we would say that we want the results to be deterministic. Ie you get the same result each time you run the process.

It is clear that in some cases applicants or concerned members of the community wanted to get a "second opinion" and that was not available in the process. The challenge then is what to do when the second opinion differs from the first opinion. How do you ensure the second step has more levels of expertise, rigour, due diligence, etc to mean that it should over-ride the first opinion.

Regards,
Bruce Tonkin

_______________________________________________
Accountability-Cross-Community mailing list
Accountability-Cross-Community@icann.org
https://mm.icann.org/mailman/listinfo/accountability-cross-community