[CCWG-ACCT] Declaration issued in the Booking.com v ICANN IRP

[Kieren McCarthy]

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 at 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 at icann.org
> https://mm.icann.org/mailman/listinfo/accountability-cross-community
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/accountability-cross-community/attachments/20150305/48944030/attachment.html>