[Ws2-jurisdiction] ISSUE - absence of choice of law clause in registry agreements

Raphaël BEAUREGARD-LACROIX raphael.beauregardlacroix at sciencespo.fr
Thu Aug 17 09:57:45 UTC 2017


Dear all,

I would like to officially submit this issue to the attention of our
subgroup.

I attach here
-the case in which I raised this as an issue
-the question we formulated to ICANN legal
-the response we got from ICANN legal.
-the follow up
-the response to the follow up
I can also refer you all to an email from Bernie dated 26 July which
contains links to these.

and for reference purposes
-The standard registry agreement (RA)

I did not find ICANN legal's answer to be fully satisfying, especially
regarding registries, and I would thus like this issue to be included in
the final report, with a solution that we will hopefully all agree to!

Because of the nature of the dispute resolution clause in RAA's concluded
with registrars, I think they should be treated as a separate issue, if at
all. At any rate, this submission is already long enough as it is!

*Issue*

ICANN's standardised contracts with registries do not include a choice of
law provisions and are subject to dispute resolution by arbitration under
ICC rules. See RA, art. 5.2

As for RAA's concluded with registrars, they can be litigated in court or
in arbitration under American Arbitration Association rules. For the simple
reason that they can be litigated in court, this makes this issue less of
an issue for them.

For RA litigation, the above clause means that in effect, the arbitrators
are free to decide the applicable law according to various factors or
methods generally accepted in private international law practice. See ICC
Rules of Arbitration art. 21:

*1)*
*The parties shall be free to agree upon the rules of law to be applied by
the arbitral tribunal to the merits of the dispute. In the absence of any
such agreement, the arbitral tribunal shall apply the rules of law which it
determines to be appropriate.*
*2)*
*The arbitral tribunal shall take account of the provisions of the
contract, if any, between the parties and of any relevant trade usages.*

This also means that we cannot rely on Californian private international
law to predict which law is applicable. Moreover, as far as my
understanding of commercial arbitration goes, arbitrators would always
decide on a single law for the whole of the contract and will not start
carving up legal niches here and there.

Reasonably, there are two options as for the applicable law to these
contracts: California law, or the law applicable to the registry, whether
it be the law of its main place of business or its own company law.

I would like to quote here ICANN legal's answer to our follow-up:

*"Historically, not having a choice of law clause seems to have worked out
well in practice. *

*The lack of a choice of law clause, as far as ICANN is aware, has not
presented big **problems for either ICANN or contracted parties. *

*The plain language of the agreement has generally been sufficient to
resolve questions between the parties and allow the parties **to interpret
the performance requirements, their rights and obligations in the ordinary
course.*

*Reliance on the plain language of the agreements normally does not depend
on a choice of which jurisdiction’s laws would apply. *

*As to why the contracts have evolved in this manner, it has essentially
been a compromise that allows the choice of law issue to be handled on an
issue-specific basis that takes into account the specific conduct being
reviewed, the needs **of the parties and ICANN’s global coordination
function"*

I fail to see how the RA would satisfy registries outside of the US. Would
not they prefer to have a set choice of law rather than an undefined one?
And not there being a problem does not mean it cannot be improved.
Registries can very well refuse to litigate because of the costs, and this
will look like an absence of problem from ICANN's perspective.

Moreover, I plainly reject the contention that *"The plain language of the
agreement *(allows)* the parties to interpret the performance requirements,
their rights and obligations in the ordinary course."* The only time this
can be true is between US parties. This is just wrong for parties outside
the US.

We can all see that these contracts are drafted with US law in mind. I do
not even want to imagine what kind of mess would result of trying to fit
this contract into any continental European legal system! Or any other
legal system for that matter. And even more so if you try to divide
obligations between the parties and ascribe them a different governing
law...

The issue I see with this is that this situation 1) is detrimental to
ICANN's accountability and 2) results in more costs for registries in case
of dispute.

As for 1), I believe it is detrimental because being accountable is also
being predictable. ICANN has the means to figure out these legal questions
well in advance and do a proper risk assessment, while registries and
registrars (especially considering the small players) might not.

As for 2), an undetermined choice of law means you need to hire a lawyer
(and not just your ordinary lawyer, a specialised one) to do first and
foremost an assessment of which law would be applicable and which is most
likely to be applied by the arbitrator(s). This means more money (maybe too
much money) gone into legal fees for the small businesses.

*Solution*
Set the choice of law in those contracts. Given their drafting style,
California would make most sense. Now to jump the gun on some criticism
that I can see coming, I do believe that most if not all lawyers who can
handle domain name industry/ICANN disputes do know California law anyway.
This is for the sake of predictability, not for the sake of favouring the
US above anyone else.

I went well beyond the "12 standard lines" rule, but I do hope I made it
clear and understandable.

Best,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ws2-jurisdiction/attachments/20170817/4b39d5fa/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Employ Media LLC v ICANN_v2.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 19922 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/ws2-jurisdiction/attachments/20170817/4b39d5fa/EmployMediaLLCvICANN_v2-0001.docx>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: JurisdictionQuestiontoICANNLegalv2.doc (1).docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 16276 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/ws2-jurisdiction/attachments/20170817/4b39d5fa/JurisdictionQuestiontoICANNLegalv2.doc1-0001.docx>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ICANN Responses to WS2 Jurisdiction Questions-SE.pdf
Type: application/pdf
Size: 167991 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/ws2-jurisdiction/attachments/20170817/4b39d5fa/ICANNResponsestoWS2JurisdictionQuestions-SE-0001.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Follow Up on ICANN Legal Answers v1dot1.pdf
Type: application/pdf
Size: 494081 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/ws2-jurisdiction/attachments/20170817/4b39d5fa/FollowUponICANNLegalAnswersv1dot1-0001.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Follow Up on ICANN Legal Answers- RESPONSE FROM ICANN.pdf
Type: application/pdf
Size: 569681 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/ws2-jurisdiction/attachments/20170817/4b39d5fa/FollowUponICANNLegalAnswers-RESPONSEFROMICANN-0001.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: RA-31jul17-en.pdf
Type: application/pdf
Size: 1101183 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/ws2-jurisdiction/attachments/20170817/4b39d5fa/RA-31jul17-en-0001.pdf>


More information about the Ws2-jurisdiction mailing list