Back

29 Rights Protection Mechanisms

gTLDFull Legal NameE-mail suffixDetail
.beatsBeats Electronics, LLCbeatsbydre.comView
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.
gTLDFull Legal NameE-mail suffixDetail
.KREDKredTLD Pty Ltdrodenbaugh.comView
29.1. Rights Protection Mechanisms

Even though it is intended to operate as a single-registrant TLD, .KRED is firmly committed to the protection of Intellectual Property rights and to implementing the mandatory rights protection mechanisms detailed in Specification 7 of the Registry Agreement. .KRED will implement the following rights protection mechanisms in accordance with the Registry Agreement 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 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. Although nobody other than the Registry Operator is eligible to register, we still will offer these ICANN-required features for the Registry Operator.

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 are yet to be developed, .KRED 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, Neustar, .KRED’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 for general registration. The trademark claim service is intended to provide “clear noticeʺ to a potential registrant – i.e. the Registry Operator, of the rights of a trademark owner whose trademark is registered in the clearinghouse.

.KRED’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 both of these services on behalf of .KRED.

B. 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 very similar to those that are to be employed with respect to 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 .KRED as ultimately required by ICANN.

i. 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 to apply for the .CO domain names corresponding with their marks for a period of time before registration was 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.

At the registry level, Neustar, subsequently either delivered the:
- Approval number and domain name registration information to the Clearinghouse; or,
- 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 in the draft Registry Agreement).

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 TLD re-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 Trademark Clearinghouse is not completely defined in the draft Registry Agreement 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 .KRED.

ii. 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 the draft Registry Agreement. 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

The UDRP has been required to be implemented by all domain name registries and registrars since 1999. The UDRP is intended as an alternative dispute resolution process to cancel or transfer domain names from those that have registered and used domain names which are 1) confusingly similar to another’s trademark; 2) with no legitimate interest demonstrated by the registrant; and 3) with bad faith intent to profit. 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. With respect to the single-registrant .KRED model, domains will not be eligible for registration to any other party, and thus transfers will not be possible.

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 a requirement 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), but rather is intended only 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 24 hours of receipt of the complaint from the URS Provider. This will 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, during which time the domain name will 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 record for a suspended domain will reflect 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.

.KRED is fully aware of each of these requirements and will have the capability to implement these requirements, even though it is expected that they will never be used because of .KRED’s strict eligibility and registration requirements, and other mechanisms to quickly address any abuse within the TLD, if any. In any event, 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 .KRED registry will include a thick WHOIS database as required in Specification 4 of the draft 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.

D. Policies Handling Complaints Regarding Abuse

In addition to the Rights Protection mechanisms addressed above, .KRED will implement a number of measures to handle complaints regarding the abusive registration of domain names in its TLD – as more completely described in our response to Question 28.

Registry Acceptable Use Policy

.KRED will have 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 will reserve the right of the registry to take appropriate actions based on the type of abuse. This may include locking down the domain name and thus 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, and⁄or in cases in which the domain name is associated with an existing law enforcement investigation and at the request of such law enforcement entity, substituting name servers to collect information about the DNS queries to assist the investigation. .KRED’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

.KRED 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 an investigation by law enforcement. .KRED intends to employ Neustar’s Registry Cyber Threat Mitigation⁄Intelligence Service, further described in Question 28 and within the attached documentation. This service proactively monitors for abusive behavior, receives complaints and intelligence about abusive domain name registration, and provides mitigation services to address complaints of abuse.

Once a complaint is received from a trusted source, law enforcement entity or other third-party, or malicious activity is 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 commercially reasonable satisfaction of the Registry, then the sponsoring registrar will be notified and be given 12 hours to investigate the activity and either 1) take down the domain name by placing the domain name on hold or by deleting the domain name in its entirety, or 2) provide 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), then the Registry may place the domain on “ServerHold”. Although this action removes the domain name from the TLD zone, the domain name record still would appear 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

.KRED acknowledges that ICANN has developed a number of mechanisms over the past decade that are intended to address the issue of inaccurate WHOIS information. However the best mechanism is to maintain tight control over who can register names, and then monitor such usage for any signs of abuse.

Policies and Procedures Ensuring Compliance

When .KRED or any .KRED registrar receives a notice of false WHOIS information or other activity which violates our Acceptable Use Policy, the relevant registrar will be required to promptly acknowledge the notice, conduct a reasonable investigation, and report to the complainant and to .KRED the results of such investigation – whether appropriate action was taken, whether further information is required in order to evaluate the complaint, or whether the complaint was found invalid.

29.3 Malware Scan

In addition to ICANN-require RPMs primarily intended to address intellectual property concerns, .KRED sees great value in continually monitoring all domains in the TLD for websites or servers that are hosting malware which might infect visitors to such domains. Therefore, .KRED intends to perform a periodic malware scan of the TLD zone, to analyse all websites hosted within the TLD zone, scan for malware, then determine if there is malicious content that may infect visitors, and report same to the affected registrar and registrant with remediation instructions. We believe this will help mitigate damage from ‘drive by downloads’ that cause a great deal of identity theft and computer system damage today.

29.4 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 Neustar’s Engineering team, with guidance from its Product Management team. Neustar’s and .KRED’s Customer Support, and Legal teams play a critical role in enforcing certain policies such as the rapid suspension processes. 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

These resources, coupled with .KRED’s own resources, are more than adequate to support the rights protection mechanisms of the .KRED registry.