The ICANN community is ever closer to realization of its goal to bring long-overdue consumer choice and competition to Internet naming. Regrettably, but perhaps predictably, reliance on the Final Applicant Guidebook (AGB) is being challenged at the last minute by recent proposals from the Business and Intellectual Property Constituencies (BC/IPC), which demand “improvements” to the already extensive trademark protections that will be part of the new gTLD landscape.

Equally disturbing is ICANN staff’s apparent willingness to accommodate the demands with an end-around process that may grant intrusive changes. The end result could be one that violates ICANN’s accountability principles and its commitment to marketplace fairness, and scoffs at the community’s extensive collaboration on the issue of rights protections.

Fundamental Fairness Issues

Rights protection mechanisms (RPMs) for new gTLDs (importantly, only for new gTLDs—the same requirements aren’t yet imposed on existing gTLDs or ccTLDs) were finalized as part of the Applicant Guidebook (AGB). Some applicants—Donuts included—have elected to add further RPMs that make sense for their own registries. These were not mandated by ICANN, nor should they be.

Most of the BC/IPC proposals to create new RPMs come too late in the process to implicate only new gTLD registries. The issue of RPMs for new gTLDs were discussed and debated over a four-year period and were finally resolved in the Final Guidebook. I agree with the NTIA, which states in its recent letter to ICANN that “we encourage ICANN to explore additional trademark protections across all TLDs, existing and new, through community dialogues and appropriate policy development processes in the coming year.” (emphasis added) Any new RPM proposals should be made through a community policy development process and not through a staff-driven, last-minute attempt to change longstanding agreements impacting only new gTLD registries.

As articulated by Dr. Crocker and other Board members at the Toronto ICANN meeting, any new proposals for RPMs should have GNSO Council support to be considered at this late hour. Proposals from a “consensus” of only one of several GNSO Stakeholder Groups is not the same as broad community support. Mandating new RPMs on applicants at this point would be no different from ICANN announcing it was increasing the application fee to $250,000 and all applicants had to pay another $65,000.

Applicants relied on the terms of the AGB and the terms of their application agreements with ICANN. Changes without applicant support impacting only new TLDs generally are unwarranted and untenable.

The ICANN Board has announced that the RPM issue was finalized for New TLDs. Several of the BC/IPC demands were raised and discussed many times before (and in some instances agreed to by the IPC). ICANN must keep its word that the issue is closed for applicants and push proposals for new RPMs to the policy process where it belongs. To do otherwise, especially absent broad community support, is an invitation to encourage future bad behavior and to discourage future cooperation.

Analysis of Strawman Proposal

As to the specifics of the so-called Strawman Proposal, each proposal needs to be analyzed by two standards. The first is whether the proposal should be considered implementation of a policy or measure agreed to by the ICANN community and ratified by the Board, or either a change in policy or measure (or creation of a new policy or measure) agreed to by the community and ratified by the Board.

The second is whether the proposal would change the terms of the AGB relied on by new registries when they applied. If a proposal does change the terms of the AGB, then ICANN must determine if such changes would create “a material hardship” to applicants, and if so, ICANN must work with applicants to mitigate any negative consequences of the change. (See AGB Module 6, Section 14). Under Section 14, ICANN’s right to alter the AGB unilaterally changed dramatically once applicants “completed and submitted” their applications. Failure to analyze the second test could result in a very unfair result for applicants and the potential of unwanted and unnecessary dispute resolution expense for ICANN.

ICANN has incorrectly analyzed the first test in the strawman and has failed sufficiently to analyze the second test at all. I will take each proposal one at a time and weigh them against the two tests.

1. Sunrise Notice Requirement – minimum 30-day notice period + 30-day sunrise

A. Policy vs. Implementation – I agree with ICANN’s analysis that adding a 30-day notice period does not materially change the policy or measures approved by the community and ratified by the Board. As such, I agree that ICANN staff could implement this change.

B. AGB Change/Material Hardship – the new requirement is a change to the AGB, but a short notice period to trademark holders about sunrise rules and opportunities should not cause a material hardship to applicants, especially when provided pre-launch.

2. Claims 1 – Trademark Claims (TC) minimum requirement extended from 60 to 90 days

A. Policy vs. Implementation – The Special Trademark Issues Review Team (STI), by unanimous consensus, found that TC should be an available pre-launch RPM (Sec. 5.1) and a rough consensus of the STI agreed that post-launch use of TC should not be required at all (See Sec. 7.1: IPC approved and BC/ALAC offered minority statement on this point). The ICANN Board ratified the timing of TC when it limited the minimum time period to “60 days from launch” (See GAC-Board Scorecard 6.1.2). Indeed, in Fadi’s 19 September letter to U.S. Congressional leaders he wrote, “[f]or the first round of new gTLDs, ICANN is not in a position to unilaterally require today an extension of the 60 day minimum length of the trademark claims service. The 60 day period was reached through a multi-year, extensive process with the ICANN community.” (emphasis added). Extending the TC period from 60 to 90 days should be viewed as reversing an agreed-upon policy and measure (days after reaffirming it to Congress). ICANN should send this change to the GNSO for review.

B. AGB Change/Material Hardship – The change from 60 to 90 days minimum requirement could cause material hardship for certain registries. Some registrars, especially those with a wholesale business model, may choose not to build a complicated TC process that would impact their reseller customers. Therefore, this change could cause another 30-day delay in having domain names available during general availability on first-come, first-served basis through many sources. We should keep in mind that the STI and the GNSO voted unanimously to require either Sunrise or TC, but not both. By sending this proposed change to the GNSO for a policy process, ICANN would have a better argument that it attempted to mitigate the harms of the change by getting broad community support.

3. Claims 2 – New TC Claims, fee-based option for trademark holders, but required on registries/registrars with a “lighter” claims notice

A. Policy vs. Implementation – Claims 2 is a new measure that requires community input, review, and approval before it could be implemented. As noted above, post-launch TC was rejected by a rough consensus of the community (including the IPC) and the Board and GAC reached agreement that the first 60-days of TC claims was a sufficient minimum. How could this not be considered a policy proposal that requires community input? If this is not considered policy, then the debate about which policy matters are within the so-called “picket fence” would get much hazier. There are scores of issues that would have to be worked out with this proposal: How much development cost will be incurred? What are the fee levels? How would the fees be assessed and divided? What should the claims notice say? What would the impact be on registries, registrars, resellers, users and trademark holders? Finding these kinds of answers is the very purpose of a community policy process—to understand the impacts of a potential policy and make a recommendation. ICANN would be well-advised to utilize a community policy process to entertain this proposal (which could very well receive community support in the end).

B. AGB Change/Material Hardship – Claims 2 is a brand new RPM with new requirements and guidelines and obviously is a change to the AGB. Additionally, it is a post-launch process that impacts only new gTLDs. As such, it would cause new entrants material harm vis-a-vis incumbent registries. Some registrars might not build the systems to deal with Claims 2 and only sell incumbent gTLDs. By sending this change to the GNSO for policy consideration, ICANN would not be requiring something of new entrants that it doesn’t require of incumbents. Also, if ICANN argues that new Claims 2 proposal was not “policy” for new gTLDs, how could it argue that it is policy for incumbents? If it isn’t policy for incumbents, it would not be part of the picket fence and could never be subject to a binding Consensus Policy.

4. Scope of Trademark Claims – extending beyond “exact match”

A. Policy vs. Implementation – ICANN’s position that extending TC beyond exact match may be implementing approved policy is absolutely shocking. The STI voted with “Broad Consensus” to limit TC to only identical match (See STI Sec. 4.3: BC was the only dissenter, IPC approved). Moreover, the ICANN Board stated in no uncertain terms that the TC service should be limited only identical match trademarks. How can staff possibly think that it has the authority to overturn a longstanding policy decision by the GNSO and the Board merely by announcing that it is implementation? What are they implementing? If staff’s argument is that it is just implementing the original GNSO policy that strings shouldn’t infringe on the rights of others, then staff could use that “rationale” to implement any new RPM it desires, regardless of the terms—nonsensical on any level of interpretation. Fadi wrote in his recent letter, “[i]t is important to note that the Trademark Clearinghouse is intended be a repository for existing legal rights, and not an adjudicator of such rights or creator of new rights. Extending the protections offered through the Trademark Clearinghouse to any form of name . . . would potentially expand rights beyond those granted under trademark law and put the Clearinghouse in the role of making determinations as to the scope of particular rights.” (emphasis added)

B. AGB Change/Material Hardship – This proposal, which has been rejected numerous times before, could create a material hardship on new TLD registries, as it could create more false positives and could harm legitimate registrants. The community has found in the past that the harms of this proposal would outweigh the benefits. As such it should be rejected as it violates longstanding policy and the terms of the AGB, and would harm registries and legitimate registrants alike.

ICANN Must Keep its Word

The ICANN staff and Board should not do an end-run around longstanding settled agreements and the delicately balanced policy process. As suggested by the NTIA, RPMs should be considered in a community PDP that would apply to all gTLDs—new and existing. The community should take the time to do it right, and to do it fairly. With the current proposal they are doing neither.