<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
<div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 16px; ">
<div>
<div>Public forum topics are <a href="http://costarica43.icann.org/node/29713">here</a> and listed below.</div>
</div>
</div>
<span id="OLK_SRC_BODY_SECTION" style="color: rgb(0, 0, 0); font-size: 16px; font-family: Calibri, sans-serif; ">
<div>
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
<blockquote style="margin:0 0 0 40px; border:none; padding:0px;">
<div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 16px; ">
ICANN Acting in the Public Interest</div>
<div><font class="Apple-style-span" face="Calibri,sans-serif">Document Availability and Scheduling of ICANN Meetings</font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif">Conflicts of Interest</font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif">Implementation issues for new gLD rollout</font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif">Contract Compliance</font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif"><br>
</font></div>
</blockquote>
<div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 16px; ">
Attached and below is the BC's Feb-27 letter with implementation improvements for new gTLD program</div>
</div>
</div>
</span>
<div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 16px; ">
<br>
</div>
<div>
<div><span class="Apple-style-span" style="font-family: Calibri, sans-serif; ">27-February-2012</span></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif"><br>
</font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif">To:<span class="Apple-tab-span" style="white-space:pre">
</span>Dr. Stephen Crocker </font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif">Chair, ICANN Board of Directors </font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif"><br>
</font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif">Mr. Rod Beckstrom</font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif">CEO & President, ICANN</font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif"><br>
</font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif">ICANN’s Business Constituency (BC) sees much to gain from a well-executed expansion of top-level domains. But we also worry that there is much to lose if this expansion fails to meet ICANN’s commitment
to improve trust and choice among global Internet users.</font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif"><br>
</font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif">This letter follows our Chair’s letter of January 4, 2012, where we asked ICANN to note that implementation improvements should be addressed before strings are added to the root. We noted that the
BC has raised these concerns before and that we fully support the ICANN model and process. This letter describes the BC’s priority improvements for the new gTLD program. </font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif"><br>
</font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif">The current trajectory of the new gTLD program raises critical concerns that can and should be addressed during implementation. This letter defines those concerns and offers specific recommendations
to help the new gTLD plan fulfill its promises and avoid predictable problems. The BC believes that failure to address these concerns will put at-risk the multi-stakeholder governance model we so strongly support.</font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif"><br>
</font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif">Implementation Improvements:</font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif"><br>
</font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif">1) Ensure that ICANN can enforce all registry restrictions and commitments made to potential objectors. Perhaps the most important promise ICANN made to the GAC and to its government representatives
was to allow early warnings and objections to proposed TLDs that may offend cultural, religious or national sensibilities. However, the BC is concerned that the planned process won't empower ICANN to deliver on that promise.</font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif"><br>
</font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif">While ICANN is asking governments and other stakeholders to base their response to proposed strings on the proposed terms in the application, those terms won't actually be enforceable unless they
are included as part of the formal Registry Agreement. This raises the risk that for some applicants, promised restrictions on registrants or uses of domain names could be ignored after their applications are approved. That would leave ICANN with little leverage
to hold TLD operators to the restrictions that were relied upon to satisfy governments and other potential objectors. </font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif"><br>
</font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif">This loophole should be closed before the first applications are accepted, or ICANN risks breaking a critical promise made to governments that are already skeptical of the multi-stakeholder model. </font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif"><br>
</font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif">2) Ensure that this gTLD expansion includes TLDs serving multiple languages and scripts. Internationalized domain names (IDNs) are the major benefit ICANN has promised to global Internet users, as
required in the Affirmation of Commitments. Of all the new gTLDs that will be created in this expansion, IDNs have the greatest potential to serve the next billion global Internet users, most of whom don't use the Latin alphabet as their primary script for
reading and writing. </font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif"><br>
</font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif">However, based on current activity in the new gTLD applicant community, it appears that IDN applications may represent only a small fraction of the total applicant pool, thereby leaving underserved
linguistic groups behind. It would be a missed opportunity—even a broken promise—if global users did not see multiple new IDN domains emerge from this first round of applications. The BC and other ICANN stakeholders have offered proposals to increase IDNs
in this round, but ICANN’s board and management have thus far shown little interest. </font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif"><br>
</font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif">2.1) Aside from efforts to assist financially disadvantaged applicants, ICANN should also explore incentives and other ways to encourage applicants to offer additional versions of their gTLD in underserved
scripts and languages. ICANN staff has long acknowledged cost savings of consolidating applicant and technical evaluations for applicants who propose multiple versions of their gTLD. These cost savings could be shared with applicants as an incentive to
serve smaller linguistic communities that might not otherwise be served. </font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif"><br>
</font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif">2.2) In the evaluation process, applicants who propose multiple language and IDN strings should not be penalized by strict string similarity tests that prevent additional linguistic versions of their
own gTLD. </font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif"><br>
</font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif">ICANN must take seriously its commitment to serve global Internet users. IDN prioritization will help underserved Internet users and the governments that represent them at the UN. </font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif"><br>
</font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif">3) Rights protection measures (RPMs) must be monitored and adjusted for effectiveness. If an RPM is working effectively, it should be extended; if an RPM is not effective, ICANN must be prepared
to adjust or expand the measure. </font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif"><br>
</font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif">The issue of rights protection and fraud prevention has been a centerpiece of the new gTLD debate, and still dominates discussion about the program outside of the ICANN community. The Internet ecosystem
includes businesses – large and small – that are driving e-commerce and online services. Those businesses should be supporting an expansion of domains to serve global registrants and users. But many businesses are not supportive of ICANN’s new gTLD program,
and some want to stop the expansion altogether.</font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif"><br>
</font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif">The ICANN community developed a suite of RPMs to minimize costs of defensive registrations and mitigate the risk of fraud and abuse in new gTLDs. But most of these new RPMs are untested and must
therefore be closely monitored and adjusted to improve their effectiveness. Here are several improvements that can and should be explored:</font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif"><br>
</font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif">3.1) Manage the Trademark (TM) Clearinghouse centrally, to ensure standardized streamlined submission processes for those trademark holders using it.</font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif"><br>
</font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif">3.2) Require TM claims notices at all times. Trademark claims notices — based on strings in the Trademark Clearinghouse database – are only required for 60 days after the launch of each new gTLD.
If TM notices are effective at reducing abusive registrations, it makes no sense to stop giving these notices once a gTLD is 60 days old. If TM claims are working as expected, ICANN should require them to continue indefinitely. </font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif"><br>
</font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif">3.3) Require a standardized Sunrise approach to minimize the confusion and costs to registrants to participate in Sunrise in multiple gTLDs.</font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif"><br>
</font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif">3.4) Extend Sunrise for new gTLDs for a mandatory 60 days. Single-registant TLDs could be excluded from this requirement.</font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif"><br>
</font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif">3.5) Operate the Uniform Rapid Suspension (URS) process initially as a sole vendor, supervised by ICANN. Monitor the disposition of URS cases to determine whether names subject to a URS are rapidly
re-registered by others. If this is the case, additional measures should be taken, such as making these names ineligible for future registration. Create sanctions for accredited registrars/resellers who violate such lists. </font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif"><br>
</font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif">3.6) Successful URS complainants should have option to transfer or suspend the name, and such names should generate TM Claims Notice for subsequent registrations.</font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif"><br>
</font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif">3.7) If required RPMs are not effective in preventing cybersquatting and fraudulent registrations in new gTLDs, ICANN should be ready to implement additional RPMs based on the TM Clearinghouse.</font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif"><br>
</font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif">4) Amend the Registrar Accreditation Agreement (RAA) for registrars distributing names in new gTLDS. With all the focus on new registry agreements, the new gTLD program missed the opportunity to
strengthen ICANN's contractual agreements with registrars who will sell and manage names in new TLDs. When millions of new registrants enter the market, it is registrars — not registries — they will be dealing with. New TLDs are just as important for registrars
as for registries, especially now that cross-ownership and vertical integration are permitted. </font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif"><br>
</font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif">With the benefit of hindsight, the ICANN community probably should have pushed for an improved registrar agreement as a requirement to sell names in new TLDs. But it is not too late to create a
new registrar agreement—one that incorporates the consensus recommendations of law enforcement agencies from around the world. </font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif"><br>
</font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif">Citing urgency to address law enforcement issues, ICANN’s Board adopted a resolution in Dakar directing RAA negotiations to commence immediately. While ICANN has a protective and often prolonged
process for amending existing contracts like the RAA, these negotiations can quickly generate a new RAA covering new gTLDs.</font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif"><br>
</font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif">ICANN should require registrars to comply with the amended RAA in order to gain accreditation to distribute names in new gTLDs. At a minimum, ICANN should encourage each new gTLD registry to require
this improved RAA for any registrar distributing or managing its domain names.</font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif"><br>
</font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif">5) Review the criteria for community facing TLDs to avoid sending such applications to auction mechanisms, particularly for non-profit and charitable organizations. </font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif"><br>
</font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif">6) Review the conditions under which a trademark name might end up being sent to auction mechanisms.</font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif"><br>
</font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif">7) Require validation of WHOIS data for new gTLDs. </font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif"><br>
</font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif">8) Add a “do not register” or “registry block” service based on the Trademark Clearinghouse, allowing any trademark holder to pay a one time fee to permanently prevent registration of names that
are an identical match or include the identical match trademark name. </font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif">The fee per name should be a one time fee that covers all new gTLDs through a database of ‘reserve names’. Operate this service for two years, then evaluate its continuation.</font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif"><br>
</font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif">9) Improve and modify the Communications Plan to focus more on information and education about mechanisms for those who do not want to operate a gTLD registry. </font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif"><br>
</font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif">10) Board has committed to second Round after a trademark study which would start 1 year after 75 new gTLDs in the root. The dates can be contingent on first round milestones and adjustments, but
the commitment must be firm enough to show potential applicants that they can obtain a gTLD soon enough to match competitors or participate in emerging trends. </font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif"><br>
</font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif"><br>
</font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif">The above improvements are achievable within the present implementation plan for new gTLDs. </font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif"><br>
</font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif">We fully understand that the ICANN community, staff and Board have become fatigued with the new gTLD process. But now is not the time to stand back and let the TLD chips fall where they may.</font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif"><br>
</font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif">Governments and stakeholders who support ICANN’s role will also hold ICANN to its promises to maximize global benefits and minimize harms to registrants and users. As we saw in Dakar, it does not
suffice to tell governments or other stakeholders with legitimate concerns that ICANN enforcement is constrained to its Guidebook, or that improvements to new registrar agreements must go through a protracted Policy Development Process. Much of the process
that needs to change is in the arena of implementation, and ICANN staff can work with the community to affect these improvements to the gTLD Guidebook.</font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif"> </font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif">All stakeholders have options to pursue other means if ICANN does not provide effective and responsive mechanisms to address their concerns. The BC goal is to ensure that ICANN is the relevant space
to work on effective safeguards for those who would otherwise bear significant financial and resource costs in the introduction of new gTLDs. </font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif"> </font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif">The BC has supported a responsible, managed introduction of new gTLDs, but we do so with a commitment that effective protections are in place for registrants and trademark holders, in full recognition
of the concerns raised by governments and law enforcement. We are committed to working with ICANN, the GAC, and with other stakeholders to achieve improvements that are essential to addressing the concerns of trademark holders regarding defensive registrations,
and other key elements of the Guidebook.</font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif"><br>
</font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif"><br>
</font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif"><br>
</font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif">Marilyn S. Cade</font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif">Chair, Business Constituency</font></div>
<div><font class="Apple-style-span" face="Calibri,sans-serif"><br>
</font></div>
</div>
</body>
</html>