ICANN/GNSO GNSO Email List Archives

[ga]


<<< Chronological Index >>>    <<< Thread Index >>>

[ga] ISPCP Constituency Statement

  • To: ga@xxxxxxxxxxxxxx
  • Subject: [ga] ISPCP Constituency Statement
  • From: Danny Younger <dannyyounger@xxxxxxxxx>
  • Date: Thu, 1 Dec 2005 09:02:43 -0800 (PST)
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=tgA4BYPE0GJvIq2osBaYQBBpcX6UEUI674HEo14tY1YaURbjuLnR7AhRenNJKPcrAniy4t2dyL3IwZJL/YhlXMv+EexFA+xa5tt+qel7yLD9siPUE5WfXZPoDB5ftRc1IZpTvg3pCbUIcggD0Gw6/OMm14RVPt067JbjJmdFQ9Y= ;
  • Sender: owner-ga@xxxxxxxxxxxxxx

ICANN ISPCP Constituency

Comment on proposed Verisign Settlement and New.COM
Agreement

The ISPCP has considered the proposed settlement
agreement posted on the 24th October
http://www.icann.org/tlds/agreements/verisign/settlement-agreements.htm
and the subsequent information paper posted on 21st
November
http://www.icann.org/tlds/announcements/anoouncement-21nov05.htm.


The ISPCP welcomes some specific aspects of this
proposed settlement, none more so than the end of the
six year litigation process which has proved to be a
major distraction from the core business of ICANN and
has done little to enhance the standing of either
party with the outside world. The benefits to ICANN
from this settlement are clearly recognisable,
including the ending of the substantial costs this
action has, and would continue to incur. Despite the
additional clarifying information provided in
http://www.icann.org/tlds/announcements/anouncement-21nov05.htm
 there remain important fundamental aspects of the
settlement which give serious cause for concern.

Settlement of the Verisign Lawsuit

The ISPCP is pleased to see that as part of this
proposed settlement, Verisign will be advocating for
the private sector solution to the coordination of
Internet names and addresses.  Of course, Verisgin?s
agreement to do so begs the question that but for this
settlement, does Verisign intend to advocate against a
private sector solution of which it is such a vital
participant?  Likewise, in the absence of this
settlement, is Verisign?s intent to encourage and
support third party activities that undermine ICANN?s
role in the technical coordination of the domain name
system (DNS).  Because if these questions are answered
in the affirmative, it seems to the ISP community that
it is not appropriate to craft a settlement with a
party whose goal it is to undermine and destabilize
the larger ICANN community.   Putting that issue
aside, the ISPCP is most concerned about the wisdom of
linking the lawsuit settlement with a decidedly
unrelated renewal of the .COM registry agreement.

The New Registry Agreement

The .COM domain is, by far, the largest registry
operation within the DNS. Whilst accepting that
stability of such an important part of the system is
essential, the guaranteed long term dominance of one
supplier in that space runs counter to the  principles
of competitiveness, innovation, and accountability.
Principles which are not only important to all ICANN
stakeholders, but are the very principles on which
ICANN will be judged by the outside world.  

In the view of the ISPCP it is inappropriate to link
the settlement agreement with a new registry
agreement. By agreeing to include a new registry
agreement as part of the settlement, it seems that
ICANN is bowing to unwarranted pressures to resolve
this dispute; but in so doing, it is compromising its
core mission and responsibility to the ICANN
community.  

Bilateral agreements between parties which result in a
non-competitive arrangement, whereby one party has the
right to a presumptive renewal, coupled with the
guaranteed potential to increase prices annually runs
counter to ICANN?s responsibility to the greater
community at large.   This is particularly damaging as
it comes at a point in time where competition within
the market place is driving prices down, not up.  One
of the aims of ICANN is to promote and sustain a
competitive market environment that will result in
benefits for consumers. The above situation
contradicts that  that goal and goes against ICANNs
owns stated values. 

Although it has been stated that the presumptive right
of renewal already exists in the current .COM
agreement, in fact the reality is that the current
renewal provision cannot be compared to the one in the
proposed agreement.  The conditions that would allow
ICANN to rebid the .COM contract are so limited by the
proposed agrrement, that it essentially guarantees
Verisign?s control over the .COM domain in perpetuity.

This provision is tantamount to a guarantee that 
Verisign is  handed total dominance of more than 50%
of the name space, togetherwith a guaranteed and
continual increase return on capital.  
It is the view of the ISPCP that perpetual renewal of
any gTLD registry contract raises policy issues that
should be considered within the gNSO prior to
inclusion in a proposed agreement. 


Likewise, the notion of exclusive rights to data
obtained from the operation of the .COM domain needs
to be clearly defined and qualified so that any
associated policy aspects are adequately understood
and dealt with in the appropriate forum, i.e., the
gNSO. The lack of clarity in the potential uses and
effects of such data raises serious concerns to the
ISP community.  Without additional specificity in
paragraph 3.1(f), there is large scale potential for
abuse.  

The ISPCP strongly urges the ICANN Board not to adopt 
 the proposed settlement. The terms of this settlement
and the superfluous inclusion of an unrelated issue,
the .COM agreement, results in the perception that
ICANN is bending to the demands of  one party over the
interest of the greater community.  This can only
cause harm and provide ICANN?s detractors with
additional arguments to support their case.    

http://gnso.icann.org/mailing-lists/archives/ispcp/msg00177.html


	
		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com



<<< Chronological Index >>>    <<< Thread Index >>>