Public Forum Comment Regarding .COOP Registry Agreement

["Michael Palage" <Michael@xxxxxxxxxx>]

06-June-2007     

 

Dr. Paul Twomey

President and CEO

Internet Corporation for Assigned Names and Numbers

4676 Admiralty Way, Suite 330

Marina del Rey, CA 90292-6601 
USA

 

Ref: Public Forum Comment Regarding .COOP Registry Agreement

 

Dear Paul,

 

As an advisor to the .COOP TLD sponsor and as someone that was directly
involved in negotiating the currently proposed sponsorship agreement, I
wanted to submit this correspondence to dispel some of the
misunderstandings and misconceptions involving certain provisions
contained in the proposed sponsorship agreement.  Specifically I want to
address the concerns expressed about the provision that allows the
sponsor to request from ICANN a potential exemption from specific
consensus policies.

 

What is the exemption that is being requested?

 

Although some people have turned this issue into a sound bite about
DotCooperation LLC (dotCoop) not wanting to honor consensus policies
developed through the policy development process, it appears that they
have not stopped to read in detail what is actually being proposed. All
dotCoop is seeking is that " [i]n the event that the Sponsor has a
reasonable basis to believe that the established Consensus Policy is not
relevant, or may represent an unreasonable burden to the Sponsored
Community, Sponsor shall have the right to seek an exemption from
ICANN." 

 

In negotiating this specific term it was my understanding that ICANN
specifically encompassed the explicit approval of both the ICANN staff
and ICANN board.  Therefore, the only time an exemption would be granted
would be in the case where dotCoop presented a sound case that
demonstrated that the policy would not be relevant or that is was going
to present a burden to the community AND the ICANN staff agreed AND the
ICANN board approved such exemption in accordance with the procedures
that it has currently enacted to ensure openness and transparency.
Simply stated, in negotiating this specific provision we placed our
trust in ICANN to allow dotCoop to continue to act on behalf of the best
interest of the cooperative community as it has done for the past six
years.

 


Differences between the 2000 and 2004 sponsored TLDs


 

In light of some recent developments regarding the economic viability of
a 2004 sponsored TLD registry operator, it is important to note the
fundamental difference between the original 2000 sponsored TLDs and
those selected in the 2004 round. As you may recall the original 2000
sponsored TLDs were required by Paragraph 4.2.5 of their sponsorship
agreement to "ensure that any revenues received by a sponsor or any
affiliated entity directly or indirectly from the provision of registry
services are used solely for the benefit of the sponsored TLD
community." This provision was consistent with the corporate structure
of the original applicants that were either not-for-profit entities or
cooperative societies. 

 

When ICANN commenced the 2004 sTLD process there was detailed discussion
within the community and the Board regarding this contractual
restriction and how it might limit future TLD applicants. In connection
with Board Resolutions 03.169 thru 03.171 the ICANN Board radically
changed this governance construct when it approved the following text:
"the Board also recognizes general community agreement that the
appropriate form of sponsoring organizations for new sTLDs should not
necessarily be restricted to not-for-profit entities, but could include
other forms of entity that otherwise meet the criteria for a sponsoring
organization."

 

This change in the 2004 contracts created a potential conflict of
interest where the fiduciary duty of a for-profit registry operator to
maximize profits to the shareholders might conflict with the duty of the
sponsor to develop and implement policies in the best interest of the
sponsored community. 

 

An additional consideration that you yourself acknowledged during the
recent Marina del Rey new gTLD consultative process is that many of the
"sponsoring" organizations in the 2004 round were formed primarily for
the purposes of securing a TLD. This is unlike the organizations behind
the 2000 sponsored TLDs that had long and deep ties to the proposed
communities. These fundamental differences are likely why the original
2004 sponsorship evaluation committee rejected eight out of the ten
applications. While the ICANN Board acted within its authority to
ultimately approve five of the sponsored TLD applications rejected by
the sponsorship evaluation committee, those actions should not prevent
the continuation of the diversity of the TLD community by supporting the
sponsored TLD communities identified in 2000.

 

Indeed, as ICANN is on the verge of expanding the name space in
connection with the current new gTLD policy development process, it is
important to look at the lessons learned in connection with ICANN's past
efforts to normalize relationship with over 240 plus ccTLD
administrators. Until ICANN adopted the current accountability framework
document, most ccTLD administrators elected not to enter formal
relations with ICANN.  While .COOP is not seeking the flexibility
granted under the accountability framework document, it is seeking a
slight modification to the current gTLD registry language to account for
the unique set of circumstances that were originally embodied in its
2000 agreement. 

 


Inflexible consensus policies do not scale - domain name taste testing 


 

ICANN recently published a staff report on domain name testing at the
request of the At Large Advisory Committee (ALAC). While this is a
practice whose negative impacts need to be studied more carefully, it is
important to note that .COOP is unlikely to have issues with taste
testing because of the verification procedures in place and the
designated community. Therefore, requiring the .COOP registry operator
to expend its modest technical resources to solve a problem that does
not exist simply does not make sense. Moreover, even if any consensus
policies were approved that involved minimal costs, such as the
elimination of the add grace period, such action would negatively impact
the .COOP community.

 

To clearly illustrate the unintended consequences that the removal of
the add grace period would have on the cooperative community, please
refer to the redacted communication included in Appendix A to this
correspondence. This correspondence shows an exchange between the .COOP
registry sponsor and a credit union registrant that had registered a
portfolio of names. Because some of these names involved the rather
disparaging term 'sucks" these names were immediately flagged by the
registry sponsor for additional verification. Upon contacting the
designated representative at the credit union to verify the authenticity
of the domain name requests, the representative was pleased to learn
that the registration procedures in place by the sponsor negated the
need to register these defensive registrations as they had done in other
gTLDs. Upon learning of these safeguards, the registrant asked if it was
possible to cancel these unwanted domain names. As these names had been
registered within the grace period, the sponsor worked with the
registrant and registrar to cancel the unwanted domain names. This shows
the true spirit of how the five-day add grace period was intended to be
used, before being gamed by traffic aggregators for commercial gain.

  

The commercial gamesmanship involved with add storms by registrants
trying to register deleting domain names is another problem foreign to
the .COOP TLD, although this problem has plagued other gTLD registries
in the past.  Unfortunately, the unspoken reality of the gTLD policy
development process is that it primarily focuses on solutions that work
for the large, unsponsored gTLDs, and most importantly the .COM crown
jewel.  While this does address the needs of the majority of
registrants, it has the potential of largely ignoring the sponsored TLDs
and their registrants and communities.  

 

Inflexible consensus policies impede innovation and the diversity of
infrastructure providers

 

DotCoop has designated Mid-Counties Cooperative Domains as the registry
operator for the .COOP TLD. Unlike other registry operators that provide
backend infrastructure services for multiple TLDs, MCD currently only
provides registry services for the .COOP TLD. Therefore, the ability of
these larger infrastructure providers such as VeriSign, Afilias, and
NeuStar to spread developmental costs and expenses across multiple TLDs
places MCD at a competitive disadvantage especially when the proposed
changes are not needed for the community served by the .COOP TLD.

 

Several ICANN Governmental Advisory Committee (GAC) members during a
recent teleconference talked about the need to increase the diversity of
registry infrastructure providers to prevent the concentration of these
important services in the hands of a select few companies, see
<http://gnso.icann.org/meetings/transcript-gac-gnso-new-gtlds-16apr07.pd
f>
http://gnso.icann.org/meetings/transcript-gac-gnso-new-gtlds-16apr07.pdf
. Requiring registry infrastructure providers to bear developmental
costs that provide no value or benefit to the community potentially
impedes the ability for new geographically diverse infrastructure
providers to enter the market, or worse, prevent the portability of
registries between infrastructure providers. 

 


DotCoop's Goal - To serve its Community-


 

There may be some that will attempt to quickly dismiss dotCoop's
exemption request as a non-economically viable registry that is
unwilling or unable to pay for minimal consensus safeguards needed to
protect registrants. DotCoop's past actions speak louder than words in
showing its commitment to safeguarding the interests of the cooperative
community. 

 

The original consensus policy in connection with inter-registrar
transfers included an opt-out provision for the sponsored registries,
see  <http://www.icann.org/transfers/> http://www.icann.org/transfers/.
Notwithstanding this exemption from an ICANN Board approved consensus
policy, dotCoop and its registry operator worked in conjunction  to
voluntarily incorporate this safeguard. In addition, it provided an
additional option for its registrars and registrants that built on its
community support and small size to provide additional direct support
during the transfer process.  Unlike some for-profit entities that might
have forgone this change to benefits its shareholder's bottom line,
dotCoop's obligation to the cooperative community focused on doing the
right thing.

 


Working with ICANN and the Internet Community


 

DotCoop has been proactive in  honoring its original contractual terms
by presenting its renewal proposal on schedule which was posted way back
in the fourth quarter of 2005, see
<http://www.icann.org/tlds/renewals/coop-renewal-proposal-17nov05.pdf>
http://www.icann.org/tlds/renewals/coop-renewal-proposal-17nov05.pdf.
However, ICANN decided to place the renegotiation of gTLD registry
operators whose contracts had not yet expired in front of .COOP's
negotiations. It would be unfortunate if community opposition to the
negotiations with other registry operators created opposition against
the modest and measured changes that are being sought in the .COOP
sponsor agreement.  

 

Throughout the discussions with ICANN to reach this point, .COOP has
shown a willingness to work within the framework of the existing gTLD
contracts and is fully aware of the issues and concerns within the
Internet community.  However, dotCoop, as the sponsor of the TLD is also
responsible to its community and has proposed this modification to the
standard wording as the way to best serve the interests of that
community while still ensuring that its registrants and registrars can
be assured of the integrity and security of the .COOP TLD within the
ICANN community.

 

Hopefully this clarification will help remedy any confusion that might
have been raised in connection with this provision.

 

Best regards,

 

Michael

 

cc:        ICANN .COOP Public Forum    

Paul Hazen, President & CEO of DotCooperation LLC

            Craig Schwartz, ICANN Chief Registry Liaison

 

 

 


Appendix A


 

From: 

Oscar v.<xxxxxxx@xxxxxx> 

Date: 

Tue, 15 May 2007 12:17:55 -0700 

To: 

coop registry support <support@xxxxxxxxxxxxxxxx> 

Cc: 

Aya K. <xxxxxxxx@xxxxx>, Izobel N. <xxxxx@xxxxxxx> 

Subject: 

Fwd: (Case 60342) Registrations under the xxxxxx organization 

Carolyn,

I can confirm that we requested those domains.

As you seem to have a much more rigourous process around assigning 
domain names than other registries, I don't think we need the names 
with "sucks" at the end. That is just a standard policy we have 
around domain names for protection.
--
Oscar v., Vice President, Technology and Payment Services
xxxxxxxxx
T xxx.xxx.xxxx |  <file://ncbsrdc010795/Share/DotCoop/www.xxxxx>
www.xxxxx |xxxxx@xxxxxxx


Begin forwarded message:

> From: "Izobel N." <xxxx@xxxxxx>
> Date: May 15, 2007 9:30:10 AM PDT (CA)
> To: ".coop registry support" <support@xxxxxxxxxxxxxxxx>
> Cc: "Oscar v." <xxxx@xxxxxx>, "Joe B." 
> <xxxxxx@xxxxx>
> Subject: Re: (
<file://ncbsrdc010795/Share/DotCoop/default.asp?pg=pgEditBug&command=vie
w&ixBug=60342> Case 60342) Registrations under the xxxxxxxxxx
organization
>
> Hi Carolyn,
>
> The only registration I am responsible for is xxxxx.coop
>
> By way of this email, I have forwarded your inquiry to Oscar v., VP,
Technology & Payment Services, and Joe B.
> Application Designer/Webmaster. Either of them should be able to help
> you.
>
> Thank you for checking, Carolyn.
>
> Regards,
>
>
> Izobel.
>
>
>
> On May 15, 2007, at 6:42 AM, .coop registry support wrote:
>
> Dear Izobel,
>
> I wanted to check with you as you are the contact at xxxxxx that I had
> contacted in the past as there were a number of registrations made
> under the xxxxxx name last evening that I wanted to confirm were
> actually made by your organization. The names are:
>
> yyxxxx.coop
> yyxxxxsucks.coop
> yysucks.coop
> zzzzzzzz.coop
> zzzzzzzzyyxxxx.coop
> zzzzzzzzyyxxxxsucks.coop
> zzzzzzzzsucks.coop
> zzzzzzzzxxxx.coop
> zzzzzzzzxxxxsucks.coop
>
> The contact email is Oscar v.
>
> I just wanted to make sure that these were legitimately registered by
> your organization.
>
> Thank you very much.
>
> Yours in cooperation,
>
> Carolyn T. Hoover
> Director, DotCoop Operations
> DotCooperation LLC
> 1401 New York Avenue, N.W. Suite 1100
> Washington, DC 20005
> T: +1.202.383.5453
> F: +1.202.347.1968
> Toll Free: +1.866.288.3154 (see
<file://ncbsrdc010795/Share/DotCoop/www.att.com/traveler>
www.att.com/traveler for free
> overseas access)
>
>
> dotCoop is the sponsor of the .coop domain and responsible for
> management of the .coop registry and verification
> of registrants. It is a wholly owned subsidiary of the National
> Cooperative Business Association, a U.S.-based
> national, cross-industry membership association.