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

Fri Mar 6 06:59:06 UTC 2015

Well captured Alice, this is a very good example and scenario.

Regards
On Mar 6, 2015 9:45 AM, "Alice Munyua" <alice at dotafrica.org> wrote:

>  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
>
> o   Applied interim protections stopping ICANN from progressing any
> application for dot Africa until the Panel has concluded its work;
>
> o   Determined that a formal hearing, including calling of witnesses,
> should occur;
>
> o   Decided 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.
>
> o   Not 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 that there
> 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.
>
> o   Community 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
>
> o   Review 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.
>
>
>
> o   Stress 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> 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
>>
>
>
>
>
> _______________________________________________
> Accountability-Cross-Community mailing listAccountability-Cross-Community at icann.orghttps://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/3f2560a3/attachment.html>