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

Wed Mar 4 19:02:50 UTC 2015

Paragraph 129 (attached) is a good reminder that the bottom-up process is
itself an accountability mechanism, where many often disparate parties have
the opportunity to come together and agree on, or disagree with, something.
Any appeals system needs to sit within that unique ICANN context.

[image: Inline images 1]

Jacob Malthouse
Co-founder & Director, Big Room Inc.
778-960-6527
http://www.bigroom.ca/

On 4 March 2015 at 05:36, Erika Mann <erika at erikamann.com> wrote:

> Yes Mathieu, I will talk to Beck. I had a chat with her already but need
> to talk to her again.
>
> Thanks,
> Erika
>
> +32 498 12 13 54
>
> On Wed, Mar 4, 2015 at 11:09 AM, Mathieu Weill <mathieu.weill at afnic.fr>
> wrote:
>
>>  Dear Erika,
>>
>> This kind of insights would be very valuable indeed ! Can I suggest you
>> liaise with Becky as WP2 rapporteur ? Enhancing the review / redress
>> processes is very high on Becky's group agenda right now so she can
>> certainly use your help and insights.
>>
>> Best
>> Mathieu
>>
>> Le 04/03/2015 10:54, Erika Mann a écrit :
>>
>> 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
>>>
>>>
>>
>>
>> _______________________________________________
>> Accountability-Cross-Community mailing listAccountability-Cross-Community at icann.orghttps://mm.icann.org/mailman/listinfo/accountability-cross-community
>>
>>
>> --
>> *****************************
>> Mathieu WEILL
>> AFNIC - directeur général
>> Tél: +33 1 39 30 83 06mathieu.weill at afnic.fr
>> Twitter : @mathieuweill
>> *****************************
>>
>>
>> _______________________________________________
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/accountability-cross-community/attachments/20150304/60633df4/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: https___www_icann_org_en_system_files_files_final-declaration-03mar15-en_pdf.png
Type: image/png
Size: 183732 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/accountability-cross-community/attachments/20150304/60633df4/https___www_icann_org_en_system_files_files_final-declaration-03mar15-en_pdf.png>