<HTML>
<HEAD>
<TITLE>Last Call: BC Position on New TLD Registry Agreement Amendments DAG v3</TITLE>
</HEAD>
<BODY>
<FONT FACE="Optima, Times New Roman"><SPAN STYLE='font-size:10pt'>Last call, folks. Below is the draft BC position on new TLD Registry Agreement Amendments. <BR>
<BR>
Ron Andruff and Jon Nevett provided the draft. I’ve signaled my agreement, as did Berry Cobb.<BR>
<BR>
Absent objections by COB tomorrow, we will file as consensus BC comments on 1-Apr-2010. <BR>
<BR>
--Steve<BR>
<BR>
<BR>
</SPAN></FONT>
<P ALIGN=CENTER>
<FONT FACE="Optima, Times New Roman"><SPAN STYLE='font-size:10pt'><B>Business & Commercial Users’ Constituency (BC) <BR>
Position/Comments on Process for Amendments to New gTLD Registry Agreements<BR>
</B>
</SPAN></FONT>
<P>
<FONT FACE="Optima, Times New Roman"><SPAN STYLE='font-size:10pt'>The Commercial and Business Users Constituency (BC) welcomes the opportunity to comment on the New gTLD Program Explanatory Memorandum on the Process for Amendments to New gTLD Registry Agreements, which was published for public comment on February 15, 2010 (see <a href="http://icann.org/en/announcements/announcement-4-15feb10-en.htm">http://icann.org/en/announcements/announcement-4-15feb10-en.htm</a> ).<BR>
<BR>
ICANN seeks comment as to a fair process to amend New TLD registry agreements. In DAG v.3, ICANN proposed that it could unilaterally amend registry agreements even after a majority of the registry operators rejected such amendments. The Registries Stakeholder Group (RySG) recently has proposed a system of good faith negotiations between ICANN and the registry operators, but that each registry would have a veto on proposed changes to that registry agreement.<BR>
As a matter of policy, the BC believes that businesses should not be subject to agreements where the other party has the unilateral right to amend such an agreement. ICANN’s proposal in which the ICANN Board could unilaterally impose a change to registry agreements notwithstanding the objections of a majority of registry operators, the BC, or any other ICANN organization is an anathema to ICANN’s bottom-up policy making roots. <BR>
<BR>
Similarly, the RySG’s proposal, in which each individual registry has the ability to veto a proposed change, also is inconsistent with the efficient functioning and scalability of the New gTLD program. This issue requires a “balanced” approach that satisfies both parties. <BR>
The BC analyzes the issue based on whether proposed changes are within the so-called “picket fence” – and subject to Consensus Policy – or not. All contractual changes should be made in a transparent manner with input from the community. <BR>
<BR>
For issues within the picket fence, there is an existing Policy Development Process that carries the power to change all registry and registrar agreements. As described in current and proposed registry contracts, the picket fence includes most conceivable ways that community and BC members would need to control registry practices:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Optima, Times New Roman"><SPAN STYLE='font-size:10pt'>1.2.1. issues for which uniform or coordinated resolution is reasonably necessary to facilitate interoperability, security and/or stability of the Internet or DNS;<BR>
<BR>
1.2.2. functional and performance specifications for the provision of registry services; <BR>
<BR>
1.2.3. Security and stability of the registry database for the TLD;<BR>
<BR>
1.2.4. registry policies reasonably necessary to implement Consensus Policies relating to registry operations or registrars; or<BR>
<BR>
1.2.5. resolution of disputes regarding the registration of domain names (as opposed to the use of such domain names).<BR>
<BR>
1.3.1. principles for allocation of registered names in the TLD (e.g., first-come/first-served, timely renewal, holding period after expiration);<BR>
<BR>
1.3.2. prohibitions on warehousing of or speculation in domain names by registries or registrars;<BR>
<BR>
1.3.3. reservation of registered names in the TLD that may not be registered initially or that may not be renewed due to reasons reasonably related to (i) avoidance of confusion among or misleading of users, (ii) intellectual property, or (iii) the technical management of the DNS or the Internet (e.g., establishment of reservations of names from registration); and<BR>
<BR>
1.3.4. maintenance of and access to accurate and up-to-date information concerning domain name registrations; and procedures to avoid disruptions of domain name registrations due to suspension or termination of operations by a registry operator or a registrar, including procedures for allocation of responsibility for serving registered domain names in a TLD affected by such a suspension or termination.<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE="Optima, Times New Roman"><SPAN STYLE='font-size:10pt'><BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Optima, Times New Roman"><SPAN STYLE='font-size:10pt'>Source: <FONT COLOR="#0000FF"><U><a href="http://icann.org/en/topics/new-gtlds/draft-agreement-specs-clean-04oct09-en.pdf">http://icann.org/en/topics/new-gtlds/draft-agreement-specs-clean-04oct09-en.pdf</a></U></FONT> <BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE="Optima, Times New Roman"><SPAN STYLE='font-size:10pt'> <BR>
By way of example, a picket fence PDP was how the BC and other community members put a stop to domain tasting that was occurring by abuse of the add-grace period. While many felt that a 2-year PDP and implementation process took too long, this experience showed that the system works, generating a policy outcome that became part of all registrar and registry agreements.<BR>
<BR>
Therefore, ICANN shouldn’t have the ability to unilaterally change such agreements without community consent, and the BC does not see any need for a separate process for amendment on top of the current PDP process. The ICANN community is tasked with making policy; not the ICANN Board or staff. We have a process to make changes now. If that process needs improvement, let’s improve it. Giving ICANN the ability to unilaterally amend the Registry contract is not the answer.<BR>
Certain other issues outside the picket fence also should not be subject to unilateral changes, such as pricing, ICANN fees, and other similar topics where neither party can unilaterally amend an agreement without consent of the other party to the contract. <BR>
<BR>
There are some issues outside the picket fence, however, where ICANN and/or the community should be able to amend registry agreements without the specific consent of every single registry operator, as long as there is a consensus of the community. These issues should include security and stability issues, enforcement tools, registrant protections, and promoting a stable marketplace, and should be enforceable against all registry operators. For example, compliance staff must have the tools to enforce the registry agreements against potential bad actor registries. One rogue registry should not be able to veto changes that the rest of the community supports. Similar changes to the Registrar Accreditation Agreement were recently adopted without each registrar being able to veto the changes. <BR>
<BR>
Even with such rogue issues, neither the ICANN staff nor the Board should be able to amend registry agreements without community involvement and input from the registry operators. All changes – regardless of the issue -- must be transparent and exhibit the appropriate level of accountability to the community. <BR>
<BR>
ICANN needs to strike a balance in the manner in which registry agreements are amended. In the BC’s view, neither the current ICANN proposal nor the RySG proposal succeeds in doing so yet. <BR>
<BR>
<BR>
<BR>
</SPAN></FONT>
</BODY>
</HTML>