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

[Alice Munyua]

Dear Colleagues,

As you may be aware, the African Union Commission endorsed application 
for the new gTLD (dot Africa) has been the subject of a series of 
applications for review by another applicant including the IRP initiated 
in October 2013.

Article 4 Section 3 of the Bylaws, which state (amongst others) that:

  * "The IRP Panel should strive to issue its written declaration no
    later than six months after the filing of the request for
    independent review.
  * In order to keep the costs and burdens of independent review as low
    as possible, the IRP Panel should conduct its proceedings by email
    and otherwise via the Internet to the maximum extent feasible. Where
    necessary, the IRP Panel may hold meetings by telephone. In the
    unlikely event that a telephonic or in-person hearing is convened,
    the hearing shall be limited to argument only
  *


The IR Panel has so far

oApplied interim protections stopping ICANN from progressing any 
application for dot Africa until the Panel has concluded its work;

oDetermined that a formal hearing, including calling of witnesses, 
should occur;

oDecided to convene an in person hearing including cross-examination of 
witnesses, which has not taken place yet due to the withdrawal of a 
panel member.

oNot set a time for completion, despite the By Laws requiring a Panel to 
strive to issue its written declaration no later than six months after 
the filing of a Request (Article IV, s.3)

Our observation is that this important accountability (IRP) process in 
its current form is dysfunctional and does not seem to benefit any of 
the affected parties.

While we focus on strengthening review and redress mechanisms for 
example by making them more accessible (through lower costs and easier 
"standing" to make a complaint) and applicable to a wider range of Board 
decisions, etc, we would also like to provisions put in place to ensure 
thatthere is redress against the dispute resolution provider in the 
event that the process goes off-track.

There are several possible inputs to the enhancing ICANN accountability 
process that draw on the dot Africa experience to date.

oCommunity Empowerment (WP1)

§Community empowerment with regard to ICANN functions needs to be 
exercised responsibly: If there are checks and balances on ICANN, what 
checks and balances apply to different sections of the ICANN community?

§Process issues need to be considered from the viewpoint of those who 
are simply trying to conduct legitimate business with ICANN.

§There is a need to avoid legitimate public policy, commercial and 
technical objectives, for example from new gTLD applicants in 
underserved regions, being frustrated by lengthy procedural delays 
through no fault of those trying to achieve them

oReview and Redress (WP2)

§Grounds for review, especially at the IRP stage, should be clearly 
specified.

§All review processes should have some form of time limit for each 
stage, but allowing for some flexibility in specified circumstances.

§Any proposal for ICANN to be bound by an arbitration process needs to 
be considered carefully and subject to rigorous appraisal.

§Redress against the dispute resolution provider in the event that the 
process goes off-track.

oStress Testing (or Contingencies)

§These should include the risk of gridlocking ICANN decision-making 
through use of cascading review mechanisms.

§Any of the parties exploited ICANN's hands-off approach to the 
detriment of other stakeholders and affected parties. Any accountability 
process should in turn have its own accountability fail-safes.

  Best regards
Alice Munyua
African Union Commission (AUC)





On 06/03/2015 02:34, Kieren McCarthy wrote:
> 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 
> <mailto: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
>     <mailto:Accountability-Cross-Community at icann.org>
>     https://mm.icann.org/mailman/listinfo/accountability-cross-community
>
>
>
>
>
> _______________________________________________
> 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/20150306/1b2a827f/attachment.html>