[bc-gnso] more background for BC comments at Public Forum

[Steve DelBianco]

Public forum topics are here<http://costarica43.icann.org/node/29713> and listed below.
ICANN Acting in the Public Interest
Document Availability and Scheduling of ICANN Meetings
Conflicts of Interest
Implementation issues for new gLD rollout
Contract Compliance

Attached and below is the BC's Feb-27 letter with implementation improvements for new gTLD program

27-February-2012

To: Dr. Stephen Crocker
Chair, ICANN Board of Directors

Mr. Rod Beckstrom
CEO & President, ICANN

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.

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.

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.

Implementation Improvements:

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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:

3.1) Manage the Trademark (TM) Clearinghouse centrally, to ensure standardized streamlined submission processes for those trademark holders using it.

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.

3.3) Require a standardized Sunrise approach to minimize the confusion and costs to registrants to participate in Sunrise in multiple gTLDs.

3.4) Extend Sunrise for new gTLDs for a mandatory 60 days.  Single-registant TLDs could be excluded from this requirement.

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.

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.

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.

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.

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.

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.

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.

5) Review the criteria for community facing TLDs to avoid sending such applications to auction mechanisms, particularly for non-profit and charitable organizations.

6) Review the conditions under which a trademark name might end up being sent to auction mechanisms.

7) Require validation of WHOIS data for new gTLDs.

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.
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.

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.

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.


The above improvements are achievable within the present implementation plan for new gTLDs.

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.

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.

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.

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.



Marilyn S. Cade
Chair, Business Constituency

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/bc-gnso/attachments/20120315/f3a79215/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: BC request for implementation improvements.pdf
Type: application/pdf
Size: 169664 bytes
Desc: BC request for implementation improvements.pdf
URL: <http://mm.icann.org/pipermail/bc-gnso/attachments/20120315/f3a79215/BCrequestforimplementationimprovements.pdf>