News

New gTLD Next Steps

Posted by:  /  Tags: , , ,

Share

As we look ahead to the next ICANN International Public Meeting this June in Brussels, we thought it would be a good opportunity to take a look at some of the topics that are on the the table for public comment.

The public comment process is a crucial element in ICANN’s overall goal for transparency. Through public comment the internet community can raise issues or give consent to policies before they are decided on by the ICANN board. We encourage all perspective New gTLD applicants to let their voices be heard on these key issues.

A full list of items up for public comment can be found here. Current issues related to the New gTLD Program are which are open for public comment are listed below.

Trademark Protection Mechanism Closes
1. URS (Uniform Rapid Suspension) 4/1/2010
2. Trademark Clearinghouse 4/1/2010
3. Post Delegation Dispute Resolution Procedure (PPDRP) 4/1/2010
4. Registry Restrictions Dispute Resolution Procedure (RRDRP) 4/1/2010
Stability and Security Closes
1. High Security Top-Level Domain (HSTLD) -
Draft Program Development Snapshot
4/1/2010
2. Zone File Access Concept Paper 4/8/2010
Internationalized Domain Name (IDN) Closes
1. IDN 3 Character Requirements 4/1/2010
2. IDN Variants 4/1/2010

Trademark Protection Mechanisms

The Generic Names Supporting Organization (GNSO), is currently developing new Rights Protection Mechanisms (RPMs) to assist in protecting trademark owner’s from cybersquatting abuse. The chart below shows the various RPMs throughout the life-cycle of a registry pre-launch, launch (ongoing operations), and post-launch.

Pre-Launch
The pre-launch phase of the registry refers to the start of registry operations, before the TLD is officially open to the public for registrations, but has been delegated into the root DNS servers.

The TM Clearinghouse is a central database which will contain authenticated registered trademarks. The two main functions of the database will be to, validate trademarks and provide trademark validation support to registries during the sunrise period.

The concern was that the implementation of several hundred new gTLDs would be a burden on trademark holders due to the different verification databases that could potentially exist. The TM Clearinghouse has been designed to alleviate that burden by only allowing one Trademark verification database.

The issue of cost has yet to be decided.

Post-Launch
Currently, the only ICANN policy that allows trademark holders recourse if their name is squatted is the Uniform Dispute Resolution Policy (UDRP). This policy was established by ICANN in 2000, and is the international standard for the resolution of disputes related to domain name rights.

The Uniform Rapid Suspension System (URS) is a policy which is intended to identify clear cases of infringement in an rapid, in a cost effective manner. Similar to the UDRP, Complainants are required to prove the same three elements as the UDRP policy, to be successful; however, the complainant has a much higher burden of proof.

The fees for filing a compliant under the URS have not yet been determined, but are expected to be in the 300 USD range. The remedy a complainant can seek is suspension of the domain name. The complainant would need to submit a complaint under the UDRP in order to have the domain name cancelled or deleted.

Other Dispute Policies Under Consideration

  1. Registry Restrictions DRP The RRDRP is a policy aimed at community-based gTLD registry operators who do not meet the term they set forth in their registry agreement with ICANN. http://www.icann.org/en/public-comment/#rrdrp
  2. Trademark Post Delegation DRP The Trademark PDDRP is a policy which would essentially allow trademark holders to go after a registry which is using the TLD improperly or acting in bad faith by knowingly allowing infringing registrations, or registering domain names with the intent to profit from those registrations. http://www.icann.org/en/public-comment/#pddrp


Stability and Security

Two new programs have been suggested in order to improve security in new Top-Level Domains. Both of the programs, High Security Zone TLD (HSTLD) and Zone File Access (“ZFA”), are both a work in progress and have been approved by the ICANN Board for further work.

High Security Top Level Domain
This is a voluntary program to intended to create trusted top level-domains, through higher security requirement. The program is currently under evaluation and is a work in progress. It is thought that a program such as this will add incentive for registry providers to create a more secure zone for its users and their customers.
http://www.icann.org/en/public-comment/#hstld

Zone File Access
This procedure aims to create a more unified approach for the distribution of zone files. With the potential addition of hundreds of new TLDs it is being debated that the current process is lacking viability and needs to be re-evaluated. The creation of this policy could also be potentially beneficial to those who legitimately use the registry zone files for informational purposes, because it aims to simplify the process of gaining access to multiple registries zone files, and ccTLD registries could be enticed to come aboard and make their zones available.

http://www.icann.org/en/public-comment/#zfa

Internationalized Domain Name (IDN)

The ICANN Board voted unanimously to allow the application of two-character gTLDs for certain languages where characters cannot be confused with ASCII. The items up for public comment discuss the policy work in greater detail.

IDN 3 Character Requirements
The previous requirement, set in the DAG v3, calls for a three character minimum in all gTLD strings. An independent Implementation Working team found that this requirement was considered problematic for some languages, and the team released a recommendation to relax the requirement in some cases, to a minimum of two characters.
http://www.icann.org/en/public-comment/#3-char

IDN Variants
ICANN sought the help of an independent Implementation Working team to propose a new approach to IDN variants, for both gTLD and ccTLD IDN implementations. The goal now is to develop a straight-forward set of procedures for the development of IDN tables, and variant TLD allocation. The current recommendation is to not delegate variants TLDs and instead use DNS as a mechanism to test future variant delegation.

http://www.icann.org/en/public-comment/#variants