gTLD	Full Legal Name	E-mail suffix	Detail
.beats	Beats Electronics, LLC	beatsbydre.com	View

29.1 Rights Protection Mechanisms

Beats is firmly committed to the protection of Intellectual Property rights and to implementing the mandatory rights protection mechanisms contained in the Applicant Guidebook and detailed in Specification 7 of the Registry Agreement. .beats recognizes that although the New gTLD program includes significant protections beyond those that were mandatory for a number of the current TLDs, a key motivator for .beatsʹs selection of Neustar as its registry services provider is Neustarʹs experience in successfully launching a number of TLDs with diverse rights protection mechanisms, including many the ones required in the Applicant Guidebook. More specifically, .beats will implement the following rights protection mechanisms in accordance with the Applicant Guidebook as further described below:

-Trademark Clearinghouse: a one-stop shop so that trademark holders can protect their trademarks with a single registration.
-Sunrise and Trademark Claims processes for the TLD.
-Implementation of the Uniform Dispute Resolution Policy to address domain names that have been registered and used in bad faith in the TLD.
-Uniform Rapid Suspension: A quicker, more efficient and cheaper alternative to the Uniform Dispute Resolution Policy to deal with clear cut cases of cybersquatting.
-Implementation of a Thick WHOIS making it easier for rights holders to identify and locate infringing parties

29.1.1 Trademark Clearinghouse Including Sunrise and Trademark Claims

The first mandatory rights protection mechanism (RPM) required to be implemented by each new gTLD Registry is support for, and interaction with, the trademark clearinghouse. The trademark clearinghouse is intended to serve as a central repository for information to be authenticated, stored and disseminated pertaining to the rights of trademark holders. The data maintained in the clearinghouse will support and facilitate other RPMs, including the mandatory Sunrise Period and Trademark Claims service. Although many of the details of how the trademark clearinghouse will interact with each registry operator and registrars, .beats is actively monitoring the developments of the Implementation Assistance Group (IAG) designed to assist ICANN staff in firming up the rules and procedures associated with the policies and technical requirements for the trademark clearinghouse. In addition, .beatsʹs back-end registry services provider is actively participating in the IAG to ensure that the protections afforded by the clearinghouse and associated RPMs are feasible and implementable.

Utilizing the trademark clearinghouse, all operators of new gTLDs must offer: (i) a sunrise registration service for at least 30 days during the pre-launch phase giving eligible trademark owners an early opportunity to register second-level domains in new gTLDs; and (ii) a trademark claims service for at least the first 60 days that second-level registrations are open. The trademark claim service is intended to provide clear noticeʺ to a potential registrant of the rights of a trademark owner whose trademark is registered in the clearinghouse.

.beatsʹs registry service provider, Neustar, has already implemented Sunrise and⁄or Trademark Claims programs for numerous TLDs including .biz, .us, .travel, .tel and .co and will implement the both of these services on behalf of .beats.

29.1.1.1 Neustarʹs Experience in Implementing Sunrise and Trademark Claims Processes

In early 2002, Neustar became the first registry operator to launch a successful authenticated Sunrise process. This process permitted qualified trademark owners to pre-register their trademarks as domain names in the .us TLD space prior to the opening of the space to the general public. Unlike any other Sunrise plans implemented (or proposed before that time), Neustar validated the authenticity of Trademark applications and registrations with the United States Patent and Trademark Office (USPTO).

Subsequently, as the back-end registry operator for the .tel gTLD and the .co ccTLD, Neustar launched validated Sunrise programs employing processes. These programs are very similar to those that are to be employed by the Trademark Clearinghouse for new gTLDs.

Below is a high level overview of the implementation of the .co Sunrise period that demonstrates Neustarʹs experience and ability to provide a Sunrise service and an overview of Neustarʹs experience in implementing a Trademark Claims program to trademark owners for the launch of .BIZ. Neustarʹs experience in each of these rights protection mechanisms will enable it to seamlessly provide these services on behalf of .beats as required by ICANN.

a) Sunrise and .co

The Sunrise process for .co was divided into two sub-phases:

-Local Sunrise giving holders of eligible trademarks that have obtained registered status from the Colombian trademark office the opportunity apply for the .CO domain names corresponding with their marks
-Global Sunrise program giving holders of eligible registered trademarks of national effect, that have obtained a registered status in any country of the world the opportunity apply for the .CO domain names corresponding with their marks for a period of time before registration is open to the public at large.

Like the new gTLD process set forth in the Applicant Guidebook, trademark owners had to have their rights validated by a Clearinghouse provider prior to the registration being accepted by the Registry. The Clearinghouse used a defined process for checking the eligibility of the legal rights claimed as the basis of each Sunrise application using official national trademark databases and submitted documentary evidence.

Applicants and⁄or their designated agents had the option of interacting directly with the Clearinghouse to ensure their applications were accurate and complete prior to submitting them to the Registry pursuant to an optional Pre-validation Process. Whether or not an applicant was pre-validated, the applicant had to submit its corresponding domain name application through an accredited registrar. When the Applicant was pre-validated through the Clearinghouse, each was given an associated approval number that it had to supply the registry. If they were not pre-validated, applicants were required to submit the required trademark information through their registrar to the Registry.
As the registry level, Neustar, subsequently either delivered the:

-Approval number and domain name registration information to the Clearinghouse
-When there was no approval number, trademark information and the domain name registration information was provided to the
Clearinghouse through EPP (as is currently required under the Applicant Guidebook).

Information was then used by the Clearinghouse as either further validation of those pre-validated applications, or initial validation of those that did not go through pre-validation. If the applicant was validated and their trademark matched the domain name applied-for, the Clearinghouse communicated that fact to the Registry via EPP.

When there was only one validated sunrise application, the application proceeded to registration when the .co launched. If there were multiple validated applications (recognizing that there could be multiple trademark owners sharing the same trademark), those were included in the .co Sunrise auction process. Neustar tracked all of the information it received and the status of each application and posted that status on a secure Website to enable trademark owners to view the status of its Sunrise application.

Although the exact process for the Sunrise program and its interaction between the trademark owner, Registry, Registrar, and IP Clearinghouse is not completely defined in the Applicant Guidebook and is dependent on the current RFI issued by ICANN in its selection of a Trademark Clearinghouse provider, Neustarʹs expertise in launching multiple Sunrise processes and its established software will implement a smooth and compliant Sunrise process for the new gTLDs.

b) Trademark Claims Service Experience

With Neustarʹs biz TLD launched in 2001, Neustar became the first TLD with a Trademark Claims service. Neustar developed the Trademark Claim Service by enabling companies to stake claims to domain names prior to the commencement of live .biz domain registrations.

During the Trademark Claim process, Neustar received over 80,000 Trademark Claims from entities around the world. Recognizing that multiple intellectual property owners could have trademark rights in a particular mark, multiple Trademark Claims for the same string were accepted. All applications were logged into a Trademark Claims database managed by Neustar.
The Trademark Claimant was required to provide various information about their trademark rights, including the:

-Particular trademark or service mark relied on for the trademark Claim
-Date a trademark application on the mark was filed, if any, on the string of the domain name
-Country where the mark was filed, if applicable
-Registration date, if applicable
-Class or classes of goods and services for which the trademark or service mark was registered
-Name of a contact person with whom to discuss the claimed trademark rights.

Once all Trademark Claims and domain name applications were collected, Neustar then compared the claims contained within the Trademark Claims database with its database of collected domain name applications (DNAs). In the event of a match between a Trademark Claim and a domain name application, an e-mail message was sent to the domain name applicant notifying the applicant of the existing Trademark Claim. The e-mail also stressed that if the applicant chose to continue the application process and was ultimately selected as the registrant, the applicant would be subject to Neustarʹs dispute proceedings if challenged by the Trademark Claimant for that particular domain name.

The domain name applicant had the option to proceed with the application or cancel the application. Proceeding on an application meant that the applicant wanted to go forward and have the application proceed to registration despite having been notified of an existing Trademark Claim. By choosing to cancel, the applicant made a decision in light of an existing Trademark Claim notification to not proceed.

If the applicant did not respond to the e-mail notification from Neustar, or elected to cancel the application, the application was not processed. This resulted in making the applicant ineligible to register the actual domain name. If the applicant affirmatively elected to continue the application process after being notified of the claimantʹs (or claimantsʹ) alleged trademark rights to the desired domain name, Neustar processed the application.

This process is very similar to the one ultimately adopted by ICANN and incorporated in the latest version of the Applicant Guidebook. Although the collection of Trademark Claims for new gTLDs will be by the Trademark Clearinghouse, many of the aspects of Neustarʹs Trademark Claims process in 2001 are similar to those in the Applicant Guidebook. This makes Neustar uniquely qualified to implement the new gTLD Trademark Claims process.

29.1.2 Uniform Dispute Resolution Policy (UDRP) and Uniform Rapid Suspension (URS)

29.1.2.1 UDRP

Prior to joining Neustar, Mr. Neuman was a key contributor to the development of the Uniform Dispute Resolution Policy (UDRP) in 1998. This became the first Consensus Policy of ICANN and has been required to be implemented by all domain name registries since that time. The UDRP is intended as an alternative dispute resolution process to transfer domain names from those that have registered and used domain names in bad faith. Although there is not much of an active role that the domain name registry plays in the implementation of the UDRP, Neustar has closely monitored UDRP decisions that have involved the TLDs for which it supports and ensures that the decisions are implemented by the registrars supporting its TLDs. When alerted by trademark owners of failures to implement UDRP decisions by its registrars, Neustar either proactively implements the decisions itself or reminds the offending registrar of its obligations to implement the decision.

29.1.2.2 URS

In response to complaints by trademark owners that the UDRP was too cost prohibitive and slow, and the fact that more than 70 percent of UDRP cases were clear cut cases of cybersquatting, ICANN adopted the IRTʹs recommendation that all new gTLD registries be required, pursuant to their contracts with ICANN, to take part in a Uniform Rapid Suspension System (URS). The purpose of the URS is to provide a more cost effective and timely mechanism for brand owners than the UDRP to protect their trademarks and to promote consumer protection on the Internet.

The URS is not meant to address Questionable cases of alleged infringement (e.g., use of terms in a generic sense) or for anti-competitive purposes or denial of free speech, but rather for those cases in which there is no genuine contestable issue as to the infringement and abuse that is taking place.

Unlike the UDRP which requires little involvement of gTLD registries, the URS envisages much more of an active role at the registry-level. For example, rather than requiring the registrar to lock down a domain name subject to a UDRP dispute, it is the registry under the URS that must lock the domain within 24hours of receipt of the complaint from the URS Provider to restrict all changes to the registration data, including transfer and deletion of the domain names.

In addition, in the event of a determination in favor of the complainant, the registry is required to suspend the domain name. This suspension remains for the balance of the registration period and would not resolve the original website. Rather, the nameservers would be redirected to an informational web page provided by the URS Provider about the URS.
Additionally, the WHOIS reflects that the domain name will not be able to be transferred, deleted, or modified for the life of the registration. Finally, there is an option for a successful complainant to extend the registration period for one additional year at commercial rates.

.beats is fully aware of each of these requirements and will have the capability to implement these requirements for new gTLDs. In fact, during the IRTʹs development of f the URS, Neustar began examining the implications of the URS on its registry operations and provided the IRT with feedback on whether the recommendations from the IRT would be feasible for registries to implement.

Although there have been a few changes to the URS since the IRT recommendations, Neustar continued to participate in the development of the URS by providing comments to ICANN, many of which were adopted. As a result, Neustar is committed to supporting the URS for all of the registries that it provides back-end registry services.

29.1.3 Implementation of Thick WHOIS

The .beats registry will include a thick WHOIS database as required in Specification 4 of the Registry agreement. A thick WHOIS provides numerous advantages including a centralized location of registrant information, the ability to more easily manage and control the accuracy of data, and a consistent user experience.

29.1.4 Policies Handling Complaints Regarding Abuse

In addition the Rights Protection mechanisms addressed above, Beats will implement a number of measures to handle complaints regarding the abusive registration of domain names in its TLD as described in .beatsʹs response to Question 28.

29.1.4.1 Registry Acceptable Use Policy

One of the key policies each new gTLD registry is the need to have is an Acceptable Use Policy that clearly delineates the types of activities that constitute abuse and the repercussions associated with an abusive domain name registration. The policy must be incorporated into the applicable Registry-Registrar Agreement and reserve the right for the registry to take the appropriate actions based on the type of abuse. This may include locking down the domain name preventing any changes to the contact and nameserver information associated with the domain name, placing the domain name on hold rendering the domain name non-resolvable, transferring to the domain name to another registrar, and⁄or in cases in which the domain name is associated with an existing law enforcement investigation, substituting name servers to collect information about the DNS queries to assist the investigation. .beatsʹs Acceptable Use Policy, set forth in our response to Question 28, will include prohibitions on phishing, pharming, dissemination of malware, fast flux hosting, hacking, and child pornography. In addition, the policy will include the right of the registry to take action necessary to deny, cancel, suspend, lock, or transfer any registration in violation of the policy.

29.1.4.2 Monitoring for Malicious Activity

.beats is committed to ensuring that those domain names associated with abuse or malicious conduct in violation of the Acceptable Use Policy are dealt with in a timely and decisive manner. These include taking action against those domain names that are being used to threaten the stability and security of the TLD, or is part of a real-time investigation by law enforcement.

Once a complaint is received from a trusted source, third-party, or detected by the Registry, the Registry will use commercially reasonable efforts to verify the information in the complaint. If that information can be verified to the best of the ability of the Registry, the sponsoring registrar will be notified and be given 12 hours to investigate the activity and either take down the domain name by placing the domain name on hold or by deleting the domain name in its entirety or providing a compelling argument to the Registry to keep the name in the zone. If the registrar has not taken the requested action after the 12-hour period (i.e., is unresponsive to the request or refuses to take action), the Registry will place the domain on ServerHold. Although this action removes the domain name from the TLD zone, the domain name record still appears in the TLD WHOIS database so that the name and entities can be investigated by law enforcement should they desire to get involved.

29.2 Safeguards against Unqualified Registrations

IN THE EVENT, .BEATS IS VERIFYING INFORMATION SUPPLIED BY REGISTRANTS TO ENSURE THAT A REGISTRANT IS QUALIFIED TO REGISTER A DOMAIN, INFORMATION FROM THE APPLICANT SHOULD BE INSERTED IN THIS SECTION. IT IS NOT REQUIRED BY ICANN IN ORDER TO SCORE A 1 MEETS REQUIREMENTS, BUT MAY BE REQUIRED TO GET A SCORE OF 2 ON THIS QUESTION. THIS IS NOT PART OF NEUSTARʹS REGISTRY SERVICES OFFERING.

29.3 Resourcing Plans

The rights protection mechanisms described in the response above involve a wide range of tasks, procedures, and systems. The responsibility for each mechanism varies based on the specific requirements. In general the development of applications such as sunrise and IP claims is the responsibility of the Engineering team, with guidance from the Product Management team. Customer Support and Legal play a critical role in enforcing certain policies such as the rapid suspension process. These teams have years of experience implementing these or similar processes.

The necessary resources will be pulled from the pool of available resources described in detail in the response to Question 31. The following resources are available from those teams:

-Development⁄Engineering 19 employees
-Product Management- 4 employees
-Customer Support 12 employees

The resources are more than adequate to support the rights protection mechanisms of the .beats registry.

gTLD	Full Legal Name	E-mail suffix	Detail
.gay	dotgay llc	spimarketing.com	View

29.1. Rights Protection Mechanisms
dotgay LLC is firmly committed to the protection of Intellectual Property rights and to implementing the mandatory rights protection mechanisms contained in the Applicant Guidebook. dotgay LLC recognizes that although the New gTLD program includes significant protections beyond those that were mandatory for a number of the current TLDs, a key motivator for dotgay LLC’s selection of Neustar as its registry services provider is Neustar’s experience in successfully launching a number of TLDs with diverse rights protection mechanisms, including many the ones required in the Applicant Guidebook. More specifically, dotgay LLC will implement the following rights protection mechanisms in accordance with the Applicant Guidebook as further described below:

• Trademark Clearinghouse: a one-stop shop so that trademark holders can protect their trademarks with a single registration.
• Sunrise and Trademark Claims processes for the TLD.
• Implementation of the Uniform Dispute Resolution Policy to address domain names that have been registered and used in bad faith in the TLD.
• Uniform Rapid Suspension: A quicker, more efficient and cheaper alternative to the Uniform Dispute Resolution Policy to deal with clear cut cases of cybersquatting.
• Implementation of a Thick WHOIS making it easier for rights holders to identify and locate infringing parties

A. Trademark Clearinghouse Including Sunrise and Trademark Claims
The first mandatory rights protection mechanism (“RPM”) required to be implemented by each new gTLD Registry is support for, and interaction with, the trademark clearinghouse. The trademark clearinghouse is intended to serve as a central repository for information to be authenticated, stored and disseminated pertaining to the rights of trademark holders. The data maintained in the clearinghouse will support and facilitate other RPMs, including the mandatory Sunrise Period and Trademark Claims service. Although many of the details of how the trademark clearinghouse will interact with each registry operator and registrars, dotgay LLC is actively monitoring the developments of the Implementation Assistance Group (“IAG”) designed to assist ICANN staff in firming up the rules and procedures associated with the policies and technical requirements for the trademark clearinghouse. In addition, dotgay LLC’s back-end registry services provider is actively participating in the IAG to ensure that the protections afforded by the clearinghouse and associated RPMs are feasible and implementable.

Utilizing the trademark clearinghouse, all operators of new gTLDs must offer: (i) a sunrise registration service for at least 30 days during the pre-launch phase giving eligible trademark owners an early opportunity to register second-level domains in new gTLDs; and (ii) a trademark claims service for at least the first 60 days that second-level registrations are open. The trademark claim service is intended to provide clear noticeʺ to a potential registrant of the rights of a trademark owner whose trademark is registered in the clearinghouse.

dotgay LLC’s registry service provider, Neustar, has already implemented Sunrise and⁄or Trademark Claims programs for numerous TLDs including .biz, .us, .travel, .tel and .co and will implement the both of these services on behalf of dotgay LLC.

Neustar’s Experience in Implementing Sunrise and Trademark Claims Processes
In early 2002, Neustar became the first registry operator to launch a successful authenticated Sunrise process. This process permitted qualified trademark owners to pre-register their trademarks as domain names in the .us TLD space prior to the opening of the space to the general public. Unlike any other “Sunrise” plans implemented (or proposed before that time), Neustar validated the authenticity of Trademark applications and registrations with the United States Patent and Trademark Office (USPTO).

Subsequently, as the back-end registry operator for the .tel gTLD and the .co ccTLD, Neustar launched validated Sunrise programs employing processes. These programs are very similar to those that are to be employed by the Trademark Clearinghouse for new gTLDs.

Below is a high level overview of the implementation of the .co Sunrise period that demonstrates Neustar’s experience and ability to provide a Sunrise service and an overview of Neustar’s experience in implementing a Trademark Claims program to trademark owners for the launch of .BIZ. Neustar’s experience in each of these rights protection mechanisms will enable it to seamlessly provide these services on behalf of dotgay LLC as required by ICANN.

a) Sunrise and .co
The Sunrise process for .co was divided into two sub-phases:

• Local Sunrise giving holders of eligible trademarks that have obtained registered status from the Colombian trademark office the opportunity apply for the .CO domain names corresponding with their marks
• Global Sunrise program giving holders of eligible registered trademarks of national effect, that have obtained a registered status in any country of the world the opportunity apply for the .CO domain names corresponding with their marks for a period of time before registration is open to the public at large.

Like the new gTLD process set forth in the Applicant Guidebook, trademark owners had to have their rights validated by a Clearinghouse provider prior to the registration being accepted by the Registry. The Clearinghouse used a defined process for checking the eligibility of the legal rights claimed as the basis of each Sunrise application using official national trademark databases and submitted documentary evidence.

Applicants and⁄or their designated agents had the option of interacting directly with the Clearinghouse to ensure their applications were accurate and complete prior to submitting them to the Registry pursuant to an optional “Pre-validation Process”. Whether or not an applicant was “pre-validated”, the applicant had to submit its corresponding domain name application through an accredited registrar. When the Applicant was pre-validated through the Clearinghouse, each was given an associated approval number that it had to supply the registry. If they were not pre-validated, applicants were required to submit the required trademark information through their registrar to the Registry.

As the registry level, Neustar, subsequently either delivered the:

• Approval number and domain name registration information to the Clearinghouse
• When there was no approval number, trademark information and the domain name registration information was provided to the Clearinghouse through EPP (as is currently required under the Applicant Guidebook).

Information was then used by the Clearinghouse as either further validation of those pre-validated applications, or initial validation of those that did not go through pre-validation. If the applicant was validated and their trademark matched the domain name applied-for, the Clearinghouse communicated that fact to the Registry via EPP.

When there was only one validated sunrise application, the application proceeded to registration when the .co launched. If there were multiple validated applications (recognizing that there could be multiple trademark owners sharing the same trademark), those were included in the .co Sunrise auction process. Neustar tracked all of the information it received and the status of each application and posted that status on a secure Website to enable trademark owners to view the status of its Sunrise application.

Although the exact process for the Sunrise program and its interaction between the trademark owner, Registry, Registrar, and IP Clearinghouse is not completely defined in the Applicant Guidebook and is dependent on the current RFI issued by ICANN in its selection of a Trademark Clearinghouse provider, Neustar’s expertise in launching multiple Sunrise processes and its established software will implement a smooth and compliant Sunrise process for the new gTLDs.

b) Trademark Claims Service Experience
With Neustar’s biz TLD launched in 2001, Neustar became the first TLD with a Trademark Claims service. Neustar developed the Trademark Claim Service by enabling companies to stake claims to domain names prior to the commencement of live .biz domain registrations.

During the Trademark Claim process, Neustar received over 80,000 Trademark Claims from entities around the world. Recognizing that multiple intellectual property owners could have trademark rights in a particular mark, multiple Trademark Claims for the same string were accepted. All applications were logged into a Trademark Claims database managed by Neustar.
 
The Trademark Claimant was required to provide various information about their trademark rights, including the:

• Particular trademark or service mark relied on for the trademark Claim
• Date a trademark application on the mark was filed, if any, on the string of the domain name
• Country where the mark was filed, if applicable
• Registration date, if applicable
• Class or classes of goods and services for which the trademark or service mark was registered
• Name of a contact person with whom to discuss the claimed trademark rights.

Once all Trademark Claims and domain name applications were collected, Neustar then compared the claims contained within the Trademark Claims database with its database of collected domain name applications (DNAs). In the event of a match between a Trademark Claim and a domain name application, an e-mail message was sent to the domain name applicant notifying the applicant of the existing Trademark Claim. The e-mail also stressed that if the applicant chose to continue the application process and was ultimately selected as the registrant, the applicant would be subject to Neustar’s dispute proceedings if challenged by the Trademark Claimant for that particular domain name.

The domain name applicant had the option to proceed with the application or cancel the application. Proceeding on an application meant that the applicant wanted to go forward and have the application proceed to registration despite having been notified of an existing Trademark Claim. By choosing to “cancel,” the applicant made a decision in light of an existing Trademark Claim notification to not proceed.

If the applicant did not respond to the e-mail notification from Neustar, or elected to cancel the application, the application was not processed. This resulted in making the applicant ineligible to register the actual domain name. If the applicant affirmatively elected to continue the application process after being notified of the claimants’ alleged trademark rights to the desired domain name, Neustar processed the application.

This process is very similar to the one ultimately adopted by ICANN and incorporated in the latest version of the Applicant Guidebook. Although the collection of Trademark Claims for new gTLDs will be by the Trademark Clearinghouse, many of the aspects of Neustar’s Trademark Claims process in 2001 are similar to those in the Applicant Guidebook. This makes Neustar uniquely qualified to implement the new gTLD Trademark Claims process.
.
B. Uniform Dispute Resolution Policy (UDRP) and Uniform Rapid Suspension (URS)

1. UDRP
Prior to joining Neustar, Mr. Neuman was a key contributor to the development of the Uniform Dispute Resolution Policy (“UDRP”) in 1998. This became the first “Consensus Policy” of ICANN and has been required to be implemented by all domain name registries since that time. The UDRP is intended as an alternative dispute resolution process to transfer domain names from those that have registered and used domain names in bad faith. Although there is not much of an active role that the domain name registry plays in the implementation of the UDRP, Neustar has closely monitored UDRP decisions that have involved the TLDs for which it supports and ensures that the decisions are implemented by the registrars supporting its TLDs. When alerted by trademark owners of failures to implement UDRP decisions by its registrars, Neustar either proactively implements the decisions itself or reminds the offending registrar of its obligations to implement the decision.

1. URS
In response to complaints by trademark owners that the UDRP was too cost prohibitive and slow, and the fact that more than 70 percent of UDRP cases were “clear cut” cases of cybersquatting, ICANN adopted the IRT’s recommendation that all new gTLD registries be required, pursuant to their contracts with ICANN, to take part in a Uniform Rapid Suspension System (“URS”). The purpose of the URS is to provide a more cost effective and timely mechanism for brand owners than the UDRP to protect their trademarks and to promote consumer protection on the Internet.

The URS is not meant to address Questionable cases of alleged infringement (e.g., use of terms in a generic sense) or for anti-competitive purposes or denial of free speech, but rather for those cases in which there is no genuine contestable issue as to the infringement and abuse that is taking place.

Unlike the UDRP which requires little involvement of gTLD registries, the URS envisages much more of an active role at the registry-level. For example, rather than requiring the registrar to lock down a domain name subject to a UDRP dispute, it is the registry under the URS that must lock the domain within 24hours of receipt of the complaint from the URS Provider to restrict all changes to the registration data, including transfer and deletion of the domain names.

In addition, in the event of a determination in favor of the complainant, the registry is required to suspend the domain name. This suspension remains for the balance of the registration period and would not resolve the original website. Rather, the nameservers would be redirected to an informational web page provided by the URS Provider about the URS.

Additionally, the WHOIS reflects that the domain name will not be able to be transferred, deleted, or modified for the life of the registration. Finally, there is an option for a successful complainant to extend the registration period for one additional year at commercial rates.

dotgay LLC is fully aware of each of these requirements and will have the capability to implement these requirements for new gTLDs. In fact, during the IRT’s development of f the URS, Neustar began examining the implications of the URS on its registry operations and provided the IRT with feedback on whether the recommendations from the IRT would be feasible for registries to implement.

Although there have been a few changes to the URS since the IRT recommendations, Neustar continued to participate in the development of the URS by providing comments to ICANN, many of which were adopted. As a result, Neustar is committed to supporting the URS for all of the registries that it provides back-end registry services.

C. Implementation of Thick WHOIS

The .gay registry will include a thick WHOIS database as required in Specification 4 of the Registry agreement. A thick WHOIS provides the ability to more easily manage and control the accuracy of data, and a consistent user experience.

D. Policies Handling Complaints Regarding Abuse

In addition the Rights Protection mechanisms addressed above, dotgay LLC will implement a number of measures to handle complaints regarding the abusive registration of domain names in its TLD as described in dotgay LLC’s response to Question 28.

Registry Acceptable Use Policy
One of the key policies each new gTLD registry is the need to have is an Acceptable Use Policy that clearly delineates the types of activities that constitute “abuse” and the repercussions associated with an abusive domain name registration. The policy must be incorporated into the applicable Registry-Registrar Agreement and reserve the right for the registry to take the appropriate actions based on the type of abuse. This may include locking down the domain name preventing any changes to the contact and nameserver information associated with the domain name, placing the domain name “on hold” rendering the domain name non-resolvable, transferring to the domain name to another registrar, and⁄or in cases in which the domain name is associated with an existing law enforcement investigation, substituting name servers to collect information about the DNS queries to assist the investigation. dotgay LLC’s Acceptable Use Policy, set forth in our response to Question 28, will include prohibitions on phishing, pharming, dissemination of malware, fast flux hosting, hacking, and child pornography. In addition, the policy will include the right of the registry to take action necessary to deny, cancel, suspend, lock, or transfer any registration in violation of the policy.

Monitoring for Malicious Activity
dotgay LLC is committed to ensuring that those domain names associated with abuse or malicious conduct in violation of the Acceptable Use Policy are dealt with in a timely and decisive manner. These include taking action against those domain names that are being used to threaten the stability and security of the TLD, or are part of a real-time investigation by law enforcement as required by due process.

Once a complaint is received from a trusted source, third-party, or detected by the Registry, the Registry will use commercially reasonable efforts to verify the information in the complaint. If that information can be verified to the best of the ability of the Registry and can be shown to be in accordance with due process requirements, the sponsoring registrar will be notified and be given 12 hours to investigate the activity and either take down the domain name by placing the domain name on hold or by deleting the domain name in its entirety or providing a compelling argument to the Registry to keep the name in the zone. If the registrar has not taken the requested action after the 12-hour period (i.e., is unresponsive to the request or refuses to take action), the Registry will place the domain on “ServerHold”. Although this action removes the domain name from the TLD zone, the domain name record still appears in the TLD WHOIS database so that the name and entities can be investigated by law enforcement should they desire to get involved.

29.2 Safeguards against Unqualified Registrations
As a community-based TLD, dotgay LLC is firmly committed to safeguarding against unqualified registrations on .gay, a responsibility directly linked to fulfilling the community-based mission outlined in 18(a). Building a trusted TLD for the gay community requires a strategic and well planned approach and through the participation, input and use of established membership protocol from organizations in the gay community, dotgay LLC has identified several mechanisms to assist with admitting and maintaining qualified registrations, as well as identifying and removing unqualified registrations. More specifically, dotgay LLC will implement the following safeguarding mechanisms as further described below:

• Community Authentication: requirement with a Community Identifier Code (CIC), a unique code used to validate eligibility during name registration
• Authentication Update: periodic requirement for existing registrations
• Community Watch: online reporting
• Audit: periodic scanning and reviews

1. Community Authentication
In order to “qualify to register” a name on the .gay TLD, all registrants will be required to authenticate that they are members of the gay community. The qualifier used by dotgay LLC will draw on the existing practices from the network of membership organizations in the gay community around the world, making membership with these organizations the threshold requirement for admission into the .gay TLD. Membership organizations in the gay community serve as the foundation of the community in all regions of the world, implementing internal policies to identify and admit members of the gay community, while preventing non-community members from taking up membership for reasons primarily focused on misrepresentation and safety. The systems currently employed for admission to the gay community will serve the community-based .gay TLD well since it takes a community approach to who qualifies to register a .gay name. dotgay LLC refers to these organizations as Authentication Partners and they will be comprised of a wide variety of membership organizations in the gay community that focus on human rights, equality, commerce, culture and others designed to serve the gay community (as defined in Question 20e).

Authentication Partners will be the entry point for members of the gay community to begin the process of registering a name on the .gay TLD. Community members will follow an online process with their Authentication Partners to acquire a Community Identifier Code (CIC). The CIC will simultaneously be shared with dotgay LLC and Neustar for future validation during name registration. Each CIC will be good for a one name registration on the .gay TLD and must be provided to the registrar during name registration so that it can be validated with Neustar. If the CIC is confirmed as valid by Neustar, it will permit the name registration to proceed. If the CIC fails validation with Neustar then the name registration will not proceed. By design this process will be the first line of defense for unqualified registrations.

Any transfer of a .gay name, from one registrant to another, will also require that a valid CIC be provided by the registrant taking possession of the name. This is to avoid .gay names from being transferred to non-community members at any point during the registration period.

2. Authentication Update
dotgay LLC will also require authentication updates for all registrations as an ongoing safeguard against unqualified registrations. The authentication updates are intended to provide a double check and ongoing confirmation that registrations are from members of the gay community. To complete an authentication update, registrants will simply return to their chosen Authentication Partner and acquire a new CIC. This CIC will be transmitted directly to dotgay LLC to complete the update. Registrants will be able to update their CIC at any point, or at minimum within the time period required for the authentication update as detailed in the registrant agreement.

3. Community Watch
dotgay LLC will implement an online reporting mechanism to assist in surfacing unqualified registrations that may have fraudulently passed through Community Authentication, or which no longer meet eligibility requirements of the .gay TLD. The community watch approach enables members of the gay community to engage when they have knowledge pertaining to an unqualified registration, by bringing it to the attention of the Registry. The reporting mechanism will require an explanation as to why the registration is believed to not be qualified for the .gay TLD and reports received will be reviewed by the Registry’s Office of the Ombudsman.

4. Audits
dotgay LLC will also reserve the right to conduct an audit on .gay registrations when it becomes aware of CIC abuse or misconduct of Authentication Partners.

29.3 Resourcing Plans
The rights protection mechanisms described in the response above involve a wide range of tasks, procedures, and systems. The responsibility for each mechanism varies based on the specific requirements. In general the development of applications such as sunrise and IP claims is the responsibility of the Engineering team, with guidance from the Product Management team. Customer Support and Legal play a critical role in enforcing certain policies such as the rapid suspension process. These teams have years of experience implementing these or similar processes.

The necessary resources will be pulled from the pool of available resources described in detail in the response to Question 31. The following resources are available from those teams:

Development⁄Engineering – 19 employees
Product Management- 4 employees
Customer Support – 12 employees
Ombudsman function – 1 full time equivalent

The resources are more than adequate to support the rights protection mechanisms of the .gay registry.