<<<
Chronological Index
>>> <<<
Thread Index
>>>
RE: [council] suggestions for the Toronto agenda
- To: Thomas Rickert <rickert@xxxxxxxxxxx>, GNSO Council List <council@xxxxxxxxxxxxxx>
- Subject: RE: [council] suggestions for the Toronto agenda
- From: "Neuman, Jeff" <Jeff.Neuman@xxxxxxxxxx>
- Date: Fri, 14 Sep 2012 08:58:42 -0400
- Accept-language: en-US
- Acceptlanguage: en-US
- In-reply-to: <7D20BAD6-426A-46BF-BB9E-9B832FC5B3E8@anwaelte.de>
- List-id: council@xxxxxxxxxxxxxx
- References: <7D20BAD6-426A-46BF-BB9E-9B832FC5B3E8@anwaelte.de>
- Sender: owner-council@xxxxxxxxxxxxxx
- Thread-index: Ac2SdGQB3yGtXxxgRSypnddeQl72QQAAmcng
- Thread-topic: [council] suggestions for the Toronto agenda
Thomas,
Thank you for these suggestions.
1. On the first topic, the registries (and new gTLD applicants) pursued this
line of discussion way back in 2008/2009 when the new registry agreements were
first being discussed. There were many reasons which ICANN had at the time for
selecting California law and for only having a single governing law selected,
not the least includes the notion of equitable treatment and forum shopping.
ICANN has also stated that they cannot force any party to an agreement to
violate the laws of the jurisdiction in which that entity is located and
therefore, even if California law governs the contract, ICANN would be unable
to enforce a provision of an agreement against an entity located in a
jurisdiction in which that provision would violate the law. This is always the
case with all contracts. Finally, nothing prohibits any registry from
initiating bi-lateral negotiations with ICANN to change the governing law if
indeed there are issues. But I do not believe these are policy issues for the
GNSO to actively discuss, despite the fact that I believe these are real
issues. The issue is incredibly complex and must be a decision made by those
that have fiduciary obligations to the corporate organization (i.e., the Board
of Directors) and the other party to those negotiations. I am not sure this is
an issue we should discuss at this point as a council.
2. The issues you point out on WHOIS verification and data retention are I
believe still under discussion as part of the RAA process and I do believe have
policy implications just as I believe does the issue of proxy/private
registration accreditation programs. The registries and registrars expressed
as much in our response to the WHOIS RT Final Report and we believe these are
ripe for PDPs. I would support a discussion on these items as part of the
larger discussions on the WHOIS RT Final Report and the RAA negotiations.
Jeffrey J. Neuman
Neustar, Inc. / Vice President, Business Affairs
-----Original Message-----
From: owner-council@xxxxxxxxxxxxxx [mailto:owner-council@xxxxxxxxxxxxxx] On
Behalf Of Thomas Rickert
Sent: Friday, September 14, 2012 5:09 AM
To: GNSO Council List
Subject: [council] suggestions for the Toronto agenda
Stéphane, Wolf-Ulrich and Jeff, all,
since we did not have the time to discuss agenda items for Toronto, I would
like to propose two topics now.
1. At the moment, all contracts with ICANN are governed by the laws of
California. For ICANN to be globally inclusive, it would seem appropriate to me
if ICANN would offer contracts at least one in each of the regions under one
regional law. I would like to kick-off a discussion on that.
2. In the course of the RAA negotiations there are, amongst others, requests
for (i) validation prior to the resolution of domain names and annual
re-verification to increase Whois accuracy as well as for (ii) data retention
for two years past the life of the registration. Particularly these two areas
will have an enormous impact on the whole community. Yet, there does not seem
to be community-wide attention to that and the practical and legal implications
thereof. Let me clarify that this it not meant to affect the Registrars'
mandate to negotiate or change the Council's role. It is more about raising
awareness.
Thanks for all your work on putting the agenda together, Thomas
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|