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

Wed Mar 4 09:54:44 UTC 2015

Avri, Colleagues - Happy to develop a first draft proposal for input/
review based on WTO processes, taken into consideration the ICANN specific
obligations and values.

Can do a first draft next week.

Erika

On Wed, Mar 4, 2015 at 9:44 AM, Avri Doria <avri at acm.org> wrote:

>  Hi,
>
> I think this is an excellent idea and have heard it suggested before.
> Might be good to have someone lay out the features of the procedure.
>
> avri
>
>
>
> On 04-Mar-15 08:54, Erika Mann wrote:
>
>  Reviewing the comments made in this email thread, I refer in particular
> to Chris LaHatte's comment, posted below. I think he is right, we need to
> establish a dispute resolution system that values each case based on its
> individual parameters - keeping international law parameters and DNS
> specific legal parameters into consideration. My idea always was to 'copy'
> the WTO dispute settlement procedure. It is sufficient flexible, keeps
> involved complainants and third party interests in balance and it must
> respect global public interest parameters as well. I have 15 years
> experience in this area, happy to help.
> Erika
>
>
>  (From Chris LaHatte) "Accountability and a general
> sense is already being fully discussed. However the more difficult issue is
> designing a dispute resolution system which has the flexibility to discuss
> the issues graphically illustrated by this case. Do we want to set up a
> quasi-judicial system within ICANN with a level of review or appeal? Should
> we try and harmonise all of the existing review systems so that there is a
> common procedure and a review/appeal level?"
>
> On Wed, Mar 4, 2015 at 7:54 AM, Chris Disspain <ceo at auda.org.au> wrote:
>
>> Hi Bruce,
>>
>>  From my understanding  - the complainant basically wants the decision
>> from the string similarity panel that found .hotels and .hoteis to be
>> similar to be reviewed again on its merits.   Neither the Reconsideration
>> Process or IRP is currently designed to do this.    I assume that the
>> applicants for .hotels and .hoteis would want the ability to make
>> submissions and perhaps both would agree that there is not a  risk of
>> consumer confusion because the two strings address different markets
>> (English speaking versus Portuguese speaking etc).   The applicants could
>> even agree on a process to avoid confusion between the two strings.   e.g.
>> some mechanism that would ensure that Hilton.hotels and Hilton.hoteis were
>> managed by the same registrant - but have content in different languages.
>>
>>
>>  Absolutely. And if you’re correct then the review would be of the
>> merits of an independent panel decision. Whilst such a review mechanism
>> seems equitable to me I think the key point is that this would need to be
>> built in to a future new gTLD process, presumably arising from policy
>> review and recommendations of the gNSO. Thus, I’m unsure that the real
>> issue in this case can be solved by the work of the CCWG.
>>
>>  I think we are all keen to see the processes and appeal mechanisms
>> improved.
>>
>>
>>  100% agree. And that is work that I think the CCWG can do.
>>
>>
>>
>>  Cheers,
>>
>>
>>  Chris
>>
>>  On 4 Mar 2015, at 17:42 , Bruce Tonkin <Bruce.Tonkin at melbourneit.com.au>
>> wrote:
>>
>> Hello Chris,
>>
>>
>>  And, as a separate question, in respect to your comments below about
>> mechanisms that go directly to the merits of a decision, what decision
>> would that apply to in this case?
>>
>>
>> From my understanding  - the complainant basically wants the decision
>> from the string similarity panel that found .hotels and .hoteis to be
>> similar to be reviewed again on its merits.   Neither the Reconsideration
>> Process or IRP is currently designed to do this.    I assume that the
>> applicants for .hotels and .hoteis would want the ability to make
>> submissions and perhaps both would agree that there is not a  risk of
>> consumer confusion because the two strings address different markets
>> (English speaking versus Portuguese speaking etc).   The applicants could
>> even agree on a process to avoid confusion between the two strings.   e.g.
>> some mechanism that would ensure that Hilton.hotels and Hilton.hoteis were
>> managed by the same registrant - but have content in different languages.
>>
>> I could see how this could be built into a future new gTLD process.
>>
>> e.g the String Similarity panel could first identify strings that are
>> potentially confusing and should be in a contention set - e.g. .hotels and
>> .hoteis.   Then a separate panel could be convened (perhaps with three
>> panellists) to consider the case on its merits taking submissions from both
>> parties and any other interested members of the global public.
>>
>> Another common scenario  we have seen is where third parties (ie
>> non-applicants, and not ccTLD managers or gTLD operators) have disputed
>> that two strings should have been found as similar but were not  - e.g.
>> .car and .cars.   Again such a situation could perhaps be appealed to a
>> larger panel to consider on its merits - I would assume those bringing the
>>  dispute would have some standing to raise the issue - e.g. perhaps the Car
>> Industry etc. - on the basis that they could be materially affected by
>> having the two strings.
>>
>> I think it is important to remember that this was a major program that
>> was rolled out and there are lots of learnings.   Part of being accountable
>> is to address those short-comings in the next release of the process.   We
>> have been very careful about changing the rules of the process while it is
>> underway.   It is not that dissimilar to planning processes for building
>> approvals etc.   When a new area of a city is released for development -
>> the rules may need to be changed to prevent undesirable developments that
>> were not originally foreseen (e.g. buildings too tall, or buildings not
>> fireproof, earthquake proof etc).   However the changes need to be made
>> through a community consultation process - rather than the Board imposing
>> new or changed rules along the way.
>>
>> I think we are all keen to see the processes and appeal mechanisms
>> improved.   I have personally spent many hours reviewing reconsideration
>> requests.   As  a general rule for every loser in the panel and dispute
>> process - this has resulted in reconsideration as the cost to reconsider
>> versus the cost to apply  for a new gTLD was very low.   In quite a few of
>> those you could see fairly clearly that the right decision had been made on
>> its merits, and in other cases I could see how a different panel might make
>> a different decision on its merits.    Most of the reconsideration requests
>> spend most of their submission arguing the merits of their original case -
>> and few have been able to identify errors in the process.
>>
>> 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 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
>
>
>
>
> ------------------------------
>    <http://www.avast.com/>
>
> This email has been checked for viruses by Avast antivirus software.
> www.avast.com
>
>
> _______________________________________________
> 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/20150304/1fa4d960/attachment.html>