Back

28 Abuse Prevention and Mitigation

gTLDFull Legal NameE-mail suffixDetail
.cfaCFA Institutecfainstitute.orgView
1. COMPREHENSIVE ABUSE POLICIES, WHICH INCLUDE CLEAR DEFINITIONS OF WHAT CONSTITUTES ABUSE IN THE TLD, AND PROCEDURES THAT WILL EFFECTIVELY MINIMIZE POTENTIAL FOR ABUSE IN THE TLD

Applicant will function, per the ICANN-Registry Operator Registry Agreement, as a Specification 9 exempt system whereby all domain name registrations in the TLD shall be registered to and maintained by Applicant and Applicant will not sell, distribute or transfer control of domain name registrations to any party that is not an Affiliate of Applicant as defined in the ICANN-Registry Operator Registry Agreement. All domain name registrations intended to be used within Applicant’s registry will be registered to and controlled and maintained by Applicant and for the benefit of Applicant and its users, parents, sisters and Affiliates.

Several precise measures for discouraging the registration in the Applicant’s TLD of domain names that infringe the intellectual property rights of others are detailed within this section, in the response to question #29 and throughout other portions of the application. Additionally, it is noted that a major concern of other TLDs, namely, trademark infringement, is of lesser concern as such relates to the Applicant’s TLD, as (i) Applicant will implement and comply with all ICANN-mandated rights protection mechanisms (see response to question #29), and (ii) the Applicant’s current policies will prohibit any registrations by any party that is not the Applicant, and (iii) all registrations will be approved and executed by Applicant, there will be little to no risk that any trademark.cfa subdomains or the like will be registered and Applicant believes sufficient protection for famous names and trademarks will be provided. This means that there will be little pressure on current trademark holders to believe that they have to defensively obtain all of their trademarks within the TLD. One event in which a trademark right may be affected is the unlikely instance in which a commonly known name which is identical or confusingly similar to a trademark is registered. In this event, a trademark holder may submit a request to Applicant to remove the registration or cease use of the subdomain. Applicant is committed to making every attempt to resolve such disputes in a fair and equitable manner and demonstrating the high value Applicant places on intellectual property rights, including rights associated with trademarks. Alternatively or in addition, the trademark holder is free to file a URS, UDRP or any other dispute resolution action pursuant to the ICANN-approved new gTLD guidelines. Applicant will comply with any and all decisions and orders issued by the authorities of these dispute resolution procedures. However, Applicant believes that there will be little to no likelihood of confusion between the trademark holder and Applicant. Namely, due to strict restrictions set forth in this application, all registrations in the Applicant’s TLD will be limited to the Applicant itself and the registration will be intimately associated with Applicant and its users and Affiliates, and more particularly the content and branded material associated with those entities, and as users come to know Applicant’s TLD, they will come to understand that any and all content associated with the TLD is also associated with Applicant and its users and Affiliates, and no other party.

Furthermore, Applicant will provide to ICANN and publish on its website the abuse policy and contact details (as included below and including a valid email and mailing address) to be responsible for addressing matters requiring attention and to handle inquiries related to malicious conduct in the TLD in a timely manner.

Protection for trademark holders will be provided during the implementation phase of the Trademark Clearinghouse in compliance with protection mechanisms related to the requirements of Specification 7 of the Registry Agreement, the Trademark Clearinghouse and any other relevant rights protections mechanisms (see response to question #29 below).

A reserved list of names will be employed to prevent inappropriate name registrations. This list may be updated periodically based on ICANN directives and guidance. This list will include, among others, ICANN’s list of reserved names in the AGB, and certain geographic identifiers as enumerated in the response to question #22, unless such names have been released pursuant to the procedures outlined in Specification 5.

The Applicant’s TLD will comply with all applicable trademark and anti-cybersquatting legislation. In the event of an inconsistency between such legislation and the procedures of Applicant’s TLD, Applicant will revise its procedures to be in compliance therewith.

As a Specification 9 exempt applicant, Applicant will restrict the transfer of registrations of domain names within its TLD to third parties.

1.1 .cfa Abuse Prevention and Mitigation Implementation Plan
Applicant has attached its proposed Abuse Prevention Policy, which details procedures intended to minimize abuse registrations and other activities that have a negative impact on Internet users.
1.2 Policies for Handling Complaints Regarding Abuse
Please see the attached Abuse Prevention Policy.
1.3 Proposed Measures for Removal of Orphan Glue Records
Although orphan glue records often support correct and ordinary operation of the Domain Name System (DNS), registry operators will be required to remove orphan glue records (as defined at http:⁄⁄www.icann.org⁄en⁄committees⁄security⁄sac048.pdf) when provided with evidence in written form that such records are present in connection with malicious conduct. Applicant’s selected backend registry services provider’s (Verisign’s) registration system is specifically designed to not allow orphan glue records. Registrars are required to delete⁄move all dependent DNS records before they are allowed to delete the parent domain.
To prevent orphan glue records, Verisign performs the following checks before removing a domain or name server:

Checks during domain delete:
Parent domain delete is not allowed if any other domain in the zone refers to the child name server.
If the parent domain is the only domain using the child name server, then both the domain and the glue record are removed from the zone.

Check during explicit name server delete:
Verisign confirms that the current name server is not referenced by any domain name (in-zone) before deleting the name server.

Zone-file impact:
If the parent domain references the child name server AND if other domains in the zone also reference it AND if the parent domain name is assigned a serverHold status, then the parent domain goes out of the zone but the name server glue record does not.
If no domains reference a name server, then the zone file removes the glue record.

1.4 Resourcing Plans
Details related to resourcing plans for the initial implementation and ongoing maintenance of Applicant’s abuse plan is provided in Section 2 of this response.
1.5 Measures to Promote Whois Accuracy
Applicant will maintain a shared registration system for the Registrar for Applicants subdomains. WHOIS access will be facilitated in compliance with ICANN policies, including without limitation the Registry Agreement. It is anticipated that information will be provided which is consistent with the WHOIS information currently provided in other TLDs, including identification of the registrant and contact information therefore, administrative, technical and billing contacts, creation and expiration date and DNS settings. One way that Applicant may ensure compliance with all applicable policies is to mandate that all requests for domains will be required to come from an internal corporate channel to ensure that the requestor is affiliated with Applicant. Such requests will be subject to an internal review and approval process that may be amended from time to time. In addition, Applicant may provide for additional measures, such as to conduct audits (e.g., compliance with requirements to make WHOIS available, and with the annual WHOIS Data Reminder Policy (WDRP)); investigate complaints of non-compliance (e.g., responses to WHOIS Data Problem Service (WDPRS) notifications); develop documented internal processes and training for personnel assigned by Applicant to complete Whois data to ensure that data is provided completely and accurately.

At this point, Applicant anticipates that the identity or information regarding the Registrants will not be made generally available unless as required by ICANN, applicable law or other regulatory bodies. An exception may be made for URS, UDRP or any other dispute resolution action pursuant to the ICANN-approved new gTLD guidelines, but confidentiality may be required by a recipient in such a situation.

For technical details regarding how a complete, up-to-date, reliable and conveniently accessible WHOIS database will be provided, see response to question #26.

Applicant ensures that the WHOIS database and access thereto will comply with emerging ICANN privacy policies, if and when they become approved.

1.5.1 Authentication of Registrant Information
The Applicant will function, per the ICANN-Registry Operator Registry Agreement, as a Specification 9 exempt system whereby all domain name registrations in the gTLD shall be registered to and maintained by Applicant and Applicant will not sell, distribute or transfer control of domain name registrations to any party that is not an Affiliate of Applicant as defined in the ICANN-Registry Operator Registry Agreement. Registrations will only be permitted will be from the Applicant entity.
1.5.2 Regular Monitoring of Registration Data for Accuracy and Completeness
The Applicant will function, per the ICANN-Registry Operator Registry Agreement, as a Specification 9 exempt system whereby all domain name registrations in the gTLD shall be registered to and maintained by Applicant and Applicant will not sell, distribute or transfer control of domain name registrations to any party that is not an Affiliate of Applicant as defined in the ICANN-Registry Operator Registry Agreement. As the only registrations permitted will be from the Applicant entity, the monitoring of the accuracy of registration data will be minimal but Applicant will periodically (on at least on annual basis) monitor the accuracy and completeness of such information. Verisign, Applicant’s selected backend registry services provider, has established policies and procedures to encourage registrar compliance with ICANN’s Whois accuracy requirements. Verisign provides the following services to Applicant for incorporation into its full-service registry operations.
Registrar self-certification. The self-certification program consists, in part, of evaluations applied equally to all operational ICANN accredited registrars and conducted from time to time throughout the year. Process steps are as follows:
Verisign sends an email notification to the ICANN primary registrar contact, requesting that the contact go to a designated URL, log in with his⁄her Web ID and password, and complete and submit the online form. The contact must submit the form within 15 business days of receipt of the notification.
When the form is submitted, Verisign sends the registrar an automated email confirming that the form was successfully submitted.
Verisign reviews the submitted form to ensure the certifications are compliant.
Verisign sends the registrar an email notification if the registrar is found to be compliant in all areas.
If a review of the response indicates that the registrar is out of compliance or if Verisign has follow-up questions, the registrar has 10 days to respond to the inquiry.
If the registrar does not respond within 15 business days of receiving the original notification, or if it does not respond to the request for additional information, Verisign sends the registrar a Breach Notice and gives the registrar 30 days to cure the breach.
If the registrar does not cure the breach, Verisign terminates the Registry-Registrar Agreement (RRA).

Whois data reminder process. Verisign regularly reminds registrars of their obligation to comply with ICANN’s Whois Data Reminder Policy, which was adopted by ICANN as a consensus policy on 27 March 2003 (http:⁄⁄www.icann.org⁄en⁄registrars⁄wdrp.htm). Verisign sends a notice to all registrars once a year reminding them of their obligation to be diligent in validating the Whois information provided during the registration process, to investigate claims of fraudulent Whois information, and to cancel domain name registrations for which Whois information is determined to be invalid.
1.5.3 Use of Registrars
At the appropriate time, between post-submission of this application and prior to the .cfa launch, Applicant will identify, determine and engage the proper service provider (e.g. Applicant-approved registrar and⁄or selected backend registry services provider, Verisign) to support its provision of registration and abuse policies. Any engagement for the implementation and provision of such services shall be in compliance with all ICANN-mandated regulations, agreements, guidance and policies, as it is of paramount importance of the Applicant to protect the rights of all rightsholders.
1.6 Malicious or Abusive Behavior Definitions, Metrics, and Service Level Requirements for Resolution
The following definitions and policy (“Applicant Domain Anti-Abuse Policy”) is announced pursuant to the Registry-Registrar Agreement (“RRA”) that will be entered into between Applicant and its registrar, and is effective upon thirty days’ notice by Applicant to registrar.

Abusive use(s) of .cfa domain names should not be tolerated. The nature of such abuses creates security and stability issues for the registry, registrars and registrants, as well as for users of the Internet in general. Applicant defines abusive use as the wrong or excessive use of power, position or ability, and includes, without limitation, the following:

• Illegal or fraudulent actions;
• Spam: The use of electronic messaging systems to send unsolicited bulk messages. The term applies to email spam and similar abuses such as instant messaging spam, mobile messaging spam, and the spamming of websites and Internet forums. An example, for purposes of illustration, would be the use of email in denial-of-service attacks;
• Phishing: The use of counterfeit web pages that are designed to trick recipients into divulging sensitive data such as usernames, passwords, or financial data;
• Pharming: The redirecting of unknowing users to fraudulent sites or services, typically through DNS hijacking or poisoning;
• Willful distribution of malware: The dissemination of software designed to infiltrate or damage a computer system without the ownerʹs informed consent. Examples include, without limitation, computer viruses, worms, keyloggers, and trojan horses;
• Fast flux hosting: Use of fast-flux techniques to disguise the location of websites or other Internet services, or to avoid detection and mitigation efforts, or to host illegal activities. Fast-flux techniques use DNS to frequently change the location on the Internet to which the domain name of an Internet host or name server resolves. Fast flux hosting may be used only with prior permission of LDH;
• Botnet command and control: Services run on a domain name that are used to control a collection of compromised computers or ʺzombies,ʺ or to direct denial-of-service attacks (DDoS attacks);
• Distribution of child pornography; and
• Illegal Access to Other Computers or Networks: Illegally accessing computers, accounts, or networks belonging to another party, or attempting to penetrate security measures of another individualʹs system (often known as ʺhackingʺ). Also, any activity that might be used as a precursor to an attempted system penetration (e.g., port scan, stealth scan, or other information gathering activity).

Because Applicant is a Specification 9 exempt organization, and all second level domains will be registered and operated by Applicant and its affiliates, the risk of abuse is low. However, in response to any allegations or incidents of abuse, Applicant may, in its reasonable discretion, deny, cancel or transfer any registration or transaction, or place any domain name(s) on registry lock, hold or similar status, that it deems necessary, in its discretion; (1) to protect the integrity and stability of the registry; (2) to comply with any applicable laws, government rules or requirements, requests of law enforcement, or any dispute resolution process; (3) to avoid any liability, civil or criminal, on the part of Applicant, as well as its affiliates, subsidiaries, officers, directors, and employees; (4) per the terms of the registration agreement or (5) to correct mistakes made by Applicant or its registrar in connection with a domain name registration.

Applicant also reserves the right to place upon registry lock, hold or similar status a domain name during resolution of a dispute.

Abusive uses, as defined above, undertaken with respect to .cfa domain names shall give rise to the right of Applicant to take such actions as per its RRA in its sole discretion.

All reports of abuse should be sent to abuse@cfa, or such other email address that Applicant designates to ICANN and the public.

1.7 Controls to Ensure Proper Access to Domain Functions
The Applicant will function, per the ICANN-Registry Operator Registry Agreement, as a Specification 9 exempt system whereby all domain name registrations in the gTLD shall be registered to and maintained by Applicant and Applicant will not sell, distribute or transfer control of domain name registrations to any party that is not an Affiliate of Applicant as defined in the ICANN-Registry Operator Registry Agreement. Registrations will only be permitted by the Applicant entity. Access to domain functions will be limited to Applicant and its engaged service provider partners by implementing and complying with their established safeguards and access features as articulated below.
1.7.1 Multi-Factor Authentication
To ensure proper access to domain functions, Applicant incorporates Verisign’s Registry-Registrar Two-Factor Authentication Service into its full-service registry operations. The service is designed to improve domain name security and assist registrars in protecting the accounts they manage by providing another level of assurance that only authorized personnel can communicate with the registry. As part of the service, dynamic one-time passwords (OTPs) augment the user names and passwords currently used to process update, transfer, and⁄or deletion requests. These one-time passwords enable transaction processing to be based on requests that are validated both by “what users know” (i.e., their user name and password) and “what users have” (i.e., a two-factor authentication credential with a one-time-password).
Registrars can use the one-time-password when communicating directly with Verisign’s Customer Service department as well as when using the registrar portal to make manual updates, transfers, and⁄or deletion transactions. The Two-Factor Authentication Service is an optional service offered to registrars that execute the Registry-Registrar Two-Factor Authentication Service Agreement. As shown in Figure 28-1, the registrars’ authorized contacts use the OTP to enable strong authentication when they contact the registry. There is no charge for the Registry-Registrar Two-Factor Authentication Service. It is enabled only for registrars that wish to take advantage of the added security provided by the service.

1.7.2 Requiring Multiple, Unique Points of Contact
Unique points of contact (POC) and their respective actions will be determined by Applicant at the appropriate time prior to the implementation of the gTLD.

1.7.3 Requiring the Notification of Multiple, Unique Points of Contact
Unique points of contact (POC) and their respective actions will be determined by Applicant at the appropriate time prior to the implementation of the gTLD.
2 TECHNICAL PLAN THAT IS ADEQUATELY RESOURCED IN THE PLANNED COSTS DETAILED IN THE FINANCIAL SECTION
Resource Planning
Applicant projects it will use the following personnel roles to support the implementation of the policies articulated in this section:
o 1 head level employee
o 1 manager level employee
o 1 web services professional

To implement and manage the .cfa gTLD as described in this application, Applicant can scale and utilize additional resources as needed. In particular, personnel currently involved in the operation of Applicant’s existing .org business can assist with the needs of this new gTLD. In addition to these individuals, Applicant will support implementation of these policies through additional outside resources on an as-needed basis. Internal support will include access to the law department, finance department, information systems, technical support, human resources and such other administrative support that may be required. In particular, we anticipate using outside advisors and lawyers to assist in managing any disputes which must be resolved. Once the top level domain has been awarded, we do not anticipate disputes beyond what is frequently encountered in operating the .org. However, given the expanded opportunities associated with operating the top level domain, we have increased the likelihood of disputes, take down notices or such other matters and increased the .org dispute resolution budget. We will utilize outside advisors to provide the additional talent and resources and specialized knowledge that we cannot cost effectively maintain internally. Projected costs associated with these resources are further discussed in the response to Question 47 below.
Resource Planning Specific to Backend Registry Activities
Verisign, Applicant’s selected backend registry services provider, is an experienced backend registry provider that has developed a set of proprietary resourcing models to project the number and type of personnel resources necessary to operate a TLD. Verisign routinely adjusts these staffing models to account for new tools and process innovations. These models enable Verisign to continually right-size its staff to accommodate projected demand and meet service level agreements as well as Internet security and stability requirements. Using the projected usage volume for the most likely scenario (defined in Question 46, Template 1 – Financial Projections: Most Likely) as an input to its staffing models, Verisign derived the necessary personnel levels required for this gTLD’s initial implementation and ongoing maintenance. Verisign’s pricing for the backend registry services it provides to Applicant fully accounts for cost related to this infrastructure, which is provided as “Total Critical Registry Function Cash Outflows” (Template 1, Line IIb.G) within the Question 46 financial projections response.
Verisign employs more than 1,040 individuals of which more than 775 comprise its technical work force. (Current statistics are publicly available in Verisign’s quarterly filings.) Drawing from this pool of on-hand and fully committed technical resources, Verisign has maintained DNS operational accuracy and stability 100 percent of the time for more than 13 years for .com, proving Verisign’s ability to align personnel resource growth to the scale increases of Verisign’s TLD service offerings.
Verisign projects it will use the following personnel roles, which are described in Section 5 of the response to Question 31, Technical Overview of Proposed Registry, to support abuse prevention and mitigation:
3 Application Engineers: 19
4 Business Continuity Personnel: 3
5 Customer Affairs Organization: 9
6 Customer Support Personnel: 36
7 Information Security Engineers: 11
8 Network Administrators: 11
9 Network Architects: 4
10 Network Operations Center (NOC) Engineers: 33
11 Project Managers: 25
12 Quality Assurance Engineers: 11
13 Systems Architects: 9

To implement and manage the .cfa gTLD as described in this application, Verisign, Applicant’s selected backend registry services provider, scales, as needed, the size of each technical area now supporting its portfolio of TLDs. Consistent with its resource modeling, Verisign periodically reviews the level of work to be performed and adjusts staff levels for each technical area.
When usage projections indicate a need for additional staff, Verisign’s internal staffing group uses an in-place staffing process to identify qualified candidates. These candidates are then interviewed by the lead of the relevant technical area. By scaling one common team across all its TLDs instead of creating a new entity to manage only this proposed gTLD, Verisign realizes significant economies of scale and ensures its TLD best practices are followed consistently. This consistent application of best practices helps ensure the security and stability of both the Internet and this proposed gTLD, as Verisign holds all contributing staff members accountable to the same procedures that guide its execution of the Internet’s largest TLDs (i.e., .com and .net). Moreover, by augmenting existing teams, Verisign affords new employees the opportunity to be mentored by existing senior staff. This mentoring minimizes start-up learning curves and helps ensure that new staff members properly execute their duties.
3 POLICIES AND PROCEDURES IDENTIFY AND ADDRESS THE ABUSIVE USE OF REGISTERED NAMES AT STARTUP AND ON AN ONGOING BASIS
Start-Up Anti-Abuse Policies and Procedures

Please see the attached Abuse Prevention Policy, which details procedures intended to minimize abuse registrations and other activities that have a negative impact on Internet users. Please also see Applicant’s response to question 29.
Ongoing Anti-Abuse Policies and Procedures
3.1 Policies and Procedures That Identify Malicious or Abusive Behavior
Verisign, Applicant’s selected backend registry services provider, provides the following service to Applicant for incorporation into its full-service registry operations.
Malware scanning service. Registrants are often unknowing victims of malware exploits. Verisign has developed proprietary code to help identify malware in the zones it manages, which in turn helps registrars by identifying malicious code hidden in their domain names.
Verisign’s malware scanning service helps prevent websites from infecting other websites by scanning web pages for embedded malicious content that will infect visitors’ websites. Verisign’s malware scanning technology uses a combination of in-depth malware behavioral analysis, anti-virus results, detailed malware patterns, and network analysis to discover known exploits for the particular scanned zone. If malware is detected, the service sends the registrar a report that contains the number of malicious domains found and details about malicious content within its TLD zones. Reports with remediation instructions are provided to help registrars and registrants eliminate the identified malware from the registrant’s website.
3.2 Policies and Procedures That Address the Abusive Use of Registered Names
Suspension processes. In addition to the safeguards and mechanisms additionally provided for above and below and those required by ICANN and applicable law, rightsholders will have the opportunity to provide written notification of claimed abuse and Applicant will investigate notices of abuse and take appropriate actions pursuant to the policies articulated herein and those required by ICANN and applicable law.
Suspension processes conducted by backend registry services provider. In the case of domain name abuse, Applicant will determine whether to take down the subject domain name. Verisign, Applicant’s selected backend registry services provider, will follow the following auditable processes to comply with the suspension request.
Verisign Suspension Notification. Applicant submits the suspension request to Verisign for processing, documented by:
4 Threat domain name
5 Registry incident number
6 Incident narrative, threat analytics, screen shots to depict abuse, and⁄or other evidence
7 Threat classification
8 Threat urgency description
9 Recommended timeframe for suspension⁄takedown
10 Technical details (e.g., Whois records, IP addresses, hash values, anti-virus detection results⁄nomenclature, name servers, domain name statuses that are relevant to the suspension)
11 Incident response, including surge capacity

Verisign Notification Verification. When Verisign receives a suspension request from Applicant, it performs the following verification procedures:
12 Validate that all the required data appears in the notification.
13 Validate that the request for suspension is for a registered domain name.
14 Return a case number for tracking purposes.

Suspension Rejection. If required data is missing from the suspension request, or the domain name is not registered, the request will be rejected and returned to Applicant with the following information:
15 Threat domain name
16 Registry incident number
17 Verisign case number
18 Error reason

Registrar Notification (this optional service may be utilized by Applicant). Once Verisign has performed the domain name suspension, and upon Applicant request, Verisign notifies the registrar of the suspension. Registrar notification includes the following information:
19 Threat domain name
20 Registry incident number
21 Verisign case number
22 Classification of type of domain name abuse
23 Evidence of abuse
24 Anti-abuse contact name and number
25 Suspension status
26 Date⁄time of domain name suspension

Registrant Notification (this optional service may be utilized by Applicant). Once Verisign has performed the domain name suspension, and upon Applicant request, Verisign notifies the registrant of the suspension. Registrant notification includes the following information:
27 Threat domain name
28 Registry incident number
29 Verisign case number
30 Classification of type of domain name abuse
31 Evidence of abuse
32 Registrar anti-abuse contact name and number

Upon Applicant request, Verisign can provide a process for registrants to protest the suspension.
Domain Suspension. Verisign places the domain to be suspended on the following statuses:
33 serverUpdateProhibited
34 serverDeleteProhibited
35 serverTransferProhibited
36 serverHold

Suspension Acknowledgement. Verisign notifies Applicant that the suspension has been completed. Acknowledgement of the suspension includes the following information:
37 Threat domain name
38 Registry incident number
39 Verisign case number
40 Case number
41 Domain name
42 Applicant abuse contact name and number, or registrar abuse contact name and number
43 Suspension status

4. WHEN EXECUTED IN ACCORDANCE WITH THE REGISTRY AGREEMENT, PLANS WILL RESULT IN COMPLIANCE WITH CONTRACTUAL REQUIREMENTSAPPLICANT WILL ENSURE THAT THE IMPLEMENTATION AND EXECUTION OF THE POLICES, PLANS

Please see the attached Abuse Prevention Policy. Applicant believes that its policies are in compliance with the Registry Agreement; however, Applicant would be pleased to remedy any deficiencies noted by ICANN.
5. TECHNICAL PLAN SCOPE⁄SCALE THAT IS CONSISTENT WITH THE OVERALL BUSINESS APPROACH AND PLANNED SIZE OF THE REGISTRY
Scope⁄Scale Consistency
The Applicant will function, per the ICANN-Registry Operator Registry Agreement, as a Specification 9 exempt system whereby all domain name registrations in the gTLD shall be registered to and maintained by Applicant and Applicant will not sell, distribute or transfer control of domain name registrations to any party that is not an Affiliate of Applicant as defined in the ICANN-Registry Operator Registry Agreement. All domain name registrations intended to be used within Applicant’s registry will be registered to and controlled and maintained by Applicant and for the benefit of Applicant and its users, parents, sisters and Affiliates. Furthermore, to date Applicant does not intend to register in excess of around one thousand registrations at most. Within that context, Applicant will continue to ensure that the execution and implementation of these policies are consistent with the plan objective and size of the registry.
Scope⁄Scale Consistency Specific to Backend Registry Activities
Verisign, Applicant’s selected backend registry services provider, is an experienced backend registry provider that has developed and uses proprietary system scaling models to guide the growth of its TLD supporting infrastructure. These models direct Verisign’s infrastructure scaling to include, but not be limited to, server capacity, data storage volume, and network throughput that are aligned to projected demand and usage patterns. Verisign periodically updates these models to account for the adoption of more capable and cost-effective technologies.
Verisign’s scaling models are proven predictors of needed capacity and related cost. As such, they provide the means to link the projected infrastructure needs of the .cfa gTLD with necessary implementation and sustainment cost. Using the projected usage volume for the most likely scenario (defined in Question 46, Template 1 – Financial Projections: Most Likely) as an input to its scaling models, Verisign derived the necessary infrastructure required to implement and sustain this gTLD. Verisign’s pricing for the backend registry services it provides to Applicant fully accounts for cost related to this infrastructure, which is provided as “Other Operating Cost” (Template 1, Line I.L) within the Question 46 financial projections response.
gTLDFull Legal NameE-mail suffixDetail
.diyLifestyle Domain Holdings, Inc.wolfe-sbmc.comView
1. COMPREHENSIVE ABUSE POLICIES, WHICH INCLUDE CLEAR DEFINITIONS OF WHAT CONSTITUTES ABUSE IN THE TLD, AND PROCEDURES THAT WILL EFFECTIVELY MINIMIZE POTENTIAL FOR ABUSE IN THE TLD
Applicant intends to request from ICANN an exemption from Specification 9 of the ICANN-Registry Operator Registry Agreement. As such, Applicant intends to function in such a way that all domain name registrations in the TLD shall be registered to and maintained by Applicant and Applicant will not sell, distribute or transfer control of domain name registrations to any party that is not an Affiliate of Applicant as defined in the ICANN-Registry Operator Registry Agreement. All domain name registrations intended to be used within Applicant’s registry will be registered to and controlled and maintained by Applicant and for the benefit of Applicant and its users, parents, sisters and Affiliates.

In the event that Applicant is not granted an exemption from Specification 9, Applicant will partner with a corporate registrar with expertise in running a registry to support such efforts. Applicant intends to partner with its current corporate registrar or one of similar technical capability and expertise and allocate the appropriate funds and human resources to ensure that both itself, as the registry operator, and its selected registrar are at all times in compliance with ICANN guidelines.

Several measures for discouraging domain name abuse in the Applicant’s TLD and the registration in the Applicant’s TLD of domain names that infringe the intellectual property rights of others are detailed within this section, in the response to question #29 and throughout other portions of the application. Additionally, it is noted that a major concern of other TLDs, namely, trademark infringement, is of lesser concern as such relates to the Applicant’s TLD. There will be little to no risk of domain name abuse and improper registration of any infringing subdomains or the like in the TLD and Applicant believes sufficient protection for famous names and trademarks will be provided for because of the fact that: (i) Applicant’s TLD intends to function as a Specification 9 exempt TLD and, thus, all registrations will be approved by and registered only to Applicant; (ii) Applicant will implement and comply with all ICANN-mandated rights protection mechanisms (see response to question #29), and (iii) Applicant’s current policies will prohibit any registrations by any party that is not the Applicant and registrations will be associated with Applicant and its users, parents, sisters and Affiliates, and more particularly, the content and branded material associated with those entities. For that reason, in any case, Applicant believes that there will be little to no likelihood of confusion between the trademark holder and Applicant. As users come to know Applicant’s TLD, they will come to understand that any and all content associated with the TLD is also associated with Applicant and its users, parents, sisters and Affiliates, and no other party.

This means that there will be little pressure on current trademark holders to believe that they have to defensively obtain all of their trademarks within the TLD. One event in which a trademark right may be affected is the unlikely instance in which a commonly known name which is identical or confusingly similar to a trademark is registered. In this event, a trademark holder may submit a request to Applicant to remove the registration or cease use of the subdomain. Applicant is committed to making every attempt to resolve such disputes in a fair and equitable manner and demonstrating the high value Applicant places on intellectual property rights, including rights associated with trademarks. Alternatively, or in addition, the trademark holder is free to file a URS, UDRP or any other dispute resolution action pursuant to the ICANN-approved new gTLD guidelines. Applicant will comply with any and all decisions and orders issued by the adjudicating bodies of these dispute resolution authorities and procedures. In particular, protection for trademark holders will be provided, without limitation, during the implementation phase of the Trademark Clearinghouse in compliance with protection mechanisms related to the requirements of Specification 7 of the Registry Agreement, the Trademark Clearinghouse and any other relevant rights protections mechanisms.

Furthermore, Applicant will provide to ICANN in this application and publish on its website the abuse policy and contact details (as included below and including a valid email and mailing address) to be responsible or addressing matters requiring attention and to handle inquiries related to malicious conduct in the TLD in a timely manner.

Additionally, a reserved list of names will be employed to prevent inappropriate name registrations. This list may be updated periodically based on ICANN directives and guidance. This list will include, among others, ICANN’s list of reserved names in the Registry Agreement, and certain geographic identifiers as enumerated in the response to question #22. The list of names reserved from reservation is enumerated below:

• ICANN and IANA-related names (reserved at second and at all other levels)
o aso
o gnso
o icann
o internic
o ccnso
o afrinic
o apnic
o arin
o example
o gtld-servers
o iab
o iana
o iana-servers
o iesg
o ietf
o irtf
o istf
o lacnic
o latnic
o rfc-editor
o ripe
o root-servers
• Single-character and two-character labels (reserved at the second level)
• Tagged domains – labels with hyphens in the third and fourth character positions
• Registry operations names – (reserved at the second level) reserved for use in connection with the operation of the registry for the Registry TLD. Registry Operator may use them, but upon conclusion of Registry Operator’s designation as operator of the registry for the Registry TLD they shall be transferred as specified by ICANN:
o NIC
o WHOIS
o WWW
• TLD labels (e.g., aero, arpa, biz, com, etc.)
• Geographic and Geopolitical Names. All geographic and geopolitical names contained in the ISO 3166-1 list from time to time shall initially be reserved at both the second level and at all other levels within the TLD at which the Registry Operator provides for registrations. All names shall be reserved both in English and in all related official languages as may be directed by ICANN or the GAC.

o In addition, Registry Operator shall reserve names of territories, distinct geographic locations, and other geographic and geopolitical names as ICANN may direct from time to time. Such names may be reserved from registration during any sunrise period, and may be registered in ICANNʹs name prior to start-up and open registration in the TLD. Registry Operator may post and maintain an updated listing of all such names on its website, which list may be subject to change at ICANNʹs direction. Upon determination by ICANN of appropriate standards and qualifications for registration following input from interested parties in the Internet community, such names may be approved for registration to the appropriate authoritative body.

The Applicant’s TLD will comply with all applicable trademark and anti-cybersquatting legislation. In the event of an inconsistency between such legislation and the procedures of Applicant’s TLD, Applicant will revise its procedures to be in compliance therewith.

Should Applicant function as a Specification 9 exempt Registry Operator, Applicant will restrict the transfer of registrations of domain names within its TLD to third parties.

1.1 Abuse Prevention and Mitigation Implementation Plan
In addition to developing ICANN policies and the Applicant policies as articulated above, below and pursuant to the attached Abuse Prevention and Mitigation Implementation Plan, the registration process will limit abusive registration practices commonly associated with TLDs in which abusive registrants use false contact information to evade identification or legal process. Applicant’s TLD intends to function, per the ICANN-Registry Operator Registry Agreement, as a Specification 9 exempt TLD whereby all domain name registrations in the TLD shall be registered to and maintained by Applicant and Applicant will not sell, distribute or transfer control of domain name registrations to any party that is not an Affiliate of Applicant as defined in the ICANN-Registry Operator Registry Agreement. All domain name registrations intended to be used within Applicant’s registry will be registered to and controlled and maintained by Applicant and its verified and authenticated Affiliates and for the benefit of Applicant and its users, parents, sisters and Affiliates. All registrations must be requested through one of Applicant’s internal channels and must be verified and approved before registration. The verification process will be in operation on an ongoing basis. The verification process is designed to establish that a prospective registrant meets the registration criteria.
a. A variety of automated and manual procedures will be utilized for verification, including a cross-check of registration against information held by Applicant.
b. Eligibility of prospective registrants will be verified prior to the addition of a name to the Applicant’s TLD zone file, including but not limited to, review of the request for registration by Applicant’s compliance staff who will attempt to manually verify the affiliation of the prospective registrant with the Applicant.
c. Applicant will verify contact⁄WHOIS data for prospective registrants prior to the addition of a name to the Applicant’s TLD zone file.
d. Applicant will maintain verified contact data for the actual registrant as well as for any proxy services utilized by registrant. Proxy services eligible for use are limited to services that have demonstrated responsible and responsive business services.
e. Prospective registrants must represent and warrant that neither the registration of the desired string, nor the manner in which the registration will be used, infringes the legal rights of third parties.
f. Prospective registrants will disclose their intended use for the domain. Registration will be refused to those who do not indicate at least one acceptable use of the domain. Acceptable uses of the TLD include, but are not limited to the bona fide use or bona fide intent to use the domain name or any content, software, materials, graphics or other information thereon to permit Internet users to access one or more host computers through the DNS:
• to exchange goods, services or property of any kind;
• in the ordinary course of trade or business; or
• to facilitate the exchange of goods, services, information, or property of any kind, or the ordinary course of trade or business.
Additionally, Applicant will implement a number of mechanisms pursuant to all ICANN guidelines and the Registry Agreement for those who are not affiliated with the Applicant to protect their intellectual property.
a. Pre-Reservation Service: Applicant may enable existing holders of a trademark to block Applicant’s TLD registrations that correspond to their existing registrations in other ICANN recognized TLDs.
b. Trademark Clearinghouse: Trademark owners will have an extended period in which they can register their trademarks with the Trademark Clearinghouse. Once registration begins, if a registrant attempts to register a name that has been registered with the Trademark Clearinghouse, the prospective registrant will be notified of the existence of the registration with the Trademark Clearinghouse.
Dispute Resolution Procedures: Registered domains will be subject to challenge under ordinary domain dispute procedures set forth by ICANN, including but not limited to, Uniform Domain-Name Dispute-Resolution Policy (UDRP), Uniform Rapid Suspension system (URS), Trademark Post-Delegation Dispute Procedure (PDDRP), and Registration Restriction Dispute Resolution Procedure (RRDRP). Applicant agrees to implement and adhere to any remedies imposed by decision makers under such procedures.
1.2 Policies for Handling Complaints Regarding Abuse
Applicant reserves the right to deny, cancel or transfer any registration or transaction, or place any domain name(s) on registry lock, hold or similar status, that it deems necessary, in its discretion; (1) to protect the integrity and stability of the registry; (2) to comply with any applicable laws, government rules or requirements, requests of law enforcement, or any dispute resolution process; (3) to avoid any liability, civil or criminal, on the part of Applicant, as well as its Affiliates, subsidiaries, officers, directors, and employees; (4) per the terms of the Registration Agreement; or (5) to correct mistakes made by Applicant or its registrar in connection with a domain name registration.
During review of any complaint, Applicant will consider the standards set forth in the ICANN UDRP, in addition to the following modifications:
a. Evidence that a domain name is identical or confusingly similar to a trademark or service mark in which the complainant has rights can include evidence that the domain name is “...confusingly similar to a trademark, service mark or trade name in which the complainant has rights or the name under which the complainant does business....” This will grant standing to an entity based upon the entity’s trade name or name under which it does business.
b. Evidence that a domain has been registered and is being used in bad faith will require a showing that the domain has been registered and⁄or is being used in bad faith. This will allow a claim based upon bad faith on the part of the registrant during either registration or use.
c. Additional indicia of bad faith use will be considered. These indicia will include (1) use of the domain name inconsistent with the Code, and (2) use of the domain name in connection with a list of prohibited uses, which will include pornography, hacks⁄cracks content, etc. The list of prohibited uses may be compiled by Applicant and outside advisors.
d. Enumerated circumstances for proving a right and legitimate interest will include trade names and names under which business is done where trademarks and service marks currently are noted. A showing of bad faith registration or use, however, will be considered as prima facie evidence of no legitimate interest.
Applicant also reserves the right to place upon registry lock, hold or similar status a domain name during resolution of a dispute.
All reports of abuse should be sent to an email address that will be publicly identified by Applicant for receiving reports of abuse.
1.3 Proposed Measures for Removal of Orphan Glue Records
Although orphan glue records often support correct and ordinary operation of the Domain Name System (DNS), registry operators will be required to remove orphan glue records (as defined at http:⁄⁄www.icann.org⁄en⁄committees⁄security⁄sac048.pdf) when provided with evidence in written form that such records are present in connection with malicious conduct. Applicant’s selected backend registry services provider’s (Verisign’s) registration system is specifically designed to not allow orphan glue records. Registrars are required to delete⁄move all dependent DNS records before they are allowed to delete the parent domain.
To prevent orphan glue records, Verisign performs the following checks before removing a domain or name server:

Checks during domain delete:
• Parent domain delete is not allowed if any other domain in the zone refers to the child name server.
• If the parent domain is the only domain using the child name server, then both the domain and the glue record are removed from the zone.

Check during explicit name server delete:
• Verisign confirms that the current name server is not referenced by any domain name (in-zone) before deleting the name server.

Zone-file impact:
• If the parent domain references the child name server AND if other domains in the zone also reference it AND if the parent domain name is assigned a serverHold status, then the parent domain goes out of the zone but the name server glue record does not.
• If no domains reference a name server, then the zone file removes the glue record.

1.4 Resourcing Plans
Details related to resourcing plans for the initial implementation and ongoing maintenance of the Applicant’s abuse plan are provided in Section 2 of this response.
1.5 Measures to Promote WHOIS Accuracy
Applicant will maintain a shared registration system for Applicant’s selected registrar. WHOIS access will be facilitated in compliance with ICANN policies, including without limitation the Registry Agreement. It is anticipated that information will be provided which is consistent with the WHOIS information currently provided in other TLDs, including identification of the registrant and contact information therefore, administrative, technical and billing contacts, creation and expiration date and DNS settings. One way that Applicant may ensure compliance with all applicable policies is to mandate that all requests for domains will be required to come from a verified internal corporate channel to ensure that the requestor is affiliated with Applicant. Such requests will be subject to an internal review and approval process that may be amended from time to time. In addition, Applicant may provide for additional measures, such as to conduct audits (e.g., compliance with requirements to make WHOIS available, and with the annual WHOIS Data Reminder Policy (WDRP)); investigate complaints of non-compliance (e.g., responses to WHOIS Data Problem Service (WDPRS) notifications); develop documented internal processes and training for personnel assigned by Applicant to complete WHOIS data to ensure that data is provided completely and accurately.

At this point, Applicant anticipates that registrant information will be protected or made available as required by ICANN, applicable law or other regulatory bodies. For technical details regarding how a complete, up-to-date, reliable and conveniently accessible WHOIS database will be provided, see response to question #26.

Applicant ensures that the WHOIS database and access thereto will comply with emerging ICANN privacy policies, if and when they become approved.
1.5.1 Authentication of Registrant Information
Applicant intends to function, per the ICANN-Registry Operator Registry Agreement, as a Specification 9 exempt TLD whereby all domain name registrations in the TLD shall be registered to and maintained by Applicant and Applicant will not sell, distribute or transfer control of domain name registrations to any party that is not an Affiliate of Applicant as defined in the ICANN-Registry Operator Registry Agreement. All domain name registrations intended to be used within Applicant’s registry will be registered to and controlled and maintained by Applicant and for the benefit of Applicant and its users, parents, sisters and Affiliates. See also section 1.1 above.
1.5.2 Regular Monitoring of Registration Data for Accuracy and Completeness
Applicant intends to function, per the ICANN-Registry Operator Registry Agreement, as a Specification 9 exempt TLD whereby all domain name registrations in the TLD shall be registered to and maintained by Applicant and Applicant will not sell, distribute or transfer control of domain name registrations to any party that is not an Affiliate of Applicant as defined in the ICANN-Registry Operator Registry Agreement. All domain name registrations intended to be used within Applicant’s registry will be registered to and controlled and maintained by Applicant and for the benefit of Applicant and its users, parents, sisters and Affiliates. As the only registrations permitted will be from the Applicant entity, the monitoring of the accuracy of registration data will be reasonable and Applicant will periodically (on at least an annual basis) monitor the accuracy and completeness of such information. Verisign, Applicant’s selected backend registry services provider, has established policies and procedures to encourage registrar compliance with ICANN’s WHOIS accuracy requirements. Verisign provides the following services to Applicant for incorporation into its full-service registry operations.
Verisign, the Applicant’s selected backend registry services provider, has established policies and procedures to encourage registrar compliance with ICANN’s WHOIS accuracy requirements. Verisign provides the following services to the Applicant for incorporation into its full-service registry operations.
Registrar self-certification. Applicant intends to function, per the ICANN-Registry Operator Registry Agreement, as a Specification 9 exempt TLD whereby all domain name registrations in the TLD shall be registered to and maintained by Applicant and Applicant will not sell, distribute or transfer control of domain name registrations to any party that is not an Affiliate of Applicant as defined in the ICANN-Registry Operator Registry Agreement. All domain name registrations intended to be used within Applicant’s registry will be registered to and controlled and maintained by Applicant and for the benefit of Applicant and its users, parents, sisters and Affiliates.

WHOIS data reminder process. Verisign regularly reminds registrars of their obligation to comply with ICANN’s WHOIS Data Reminder Policy, which was adopted by ICANN as a consensus policy on 27 March 2003 (http:⁄⁄www.icann.org⁄en⁄registrars⁄wdrp.htm). Verisign sends a notice to all registrars once a year reminding them of their obligation to be diligent in validating the WHOIS information provided during the registration process, to investigate claims of fraudulent WHOIS information, and to cancel domain name registrations for which WHOIS information is determined to be invalid. Notwithstanding the above, Applicant intends to function, per the ICANN-Registry Operator Registry Agreement, as a Specification 9 exempt TLD whereby all domain name registrations in the TLD shall be registered to and maintained by Applicant and Applicant will not sell, distribute or transfer control of domain name registrations to any party that is not an Affiliate of Applicant as defined in the ICANN-Registry Operator Registry Agreement. All domain name registrations intended to be used within Applicant’s registry will be registered to and controlled and maintained by Applicant and for the benefit of Applicant and its users, parents, sisters and Affiliates.
1.5.3 Use of Registrars
Applicant intends to function, per the ICANN-Registry Operator Registry Agreement, as a Specification 9 exempt TLD whereby all domain name registrations in the TLD shall be registered to and maintained by Applicant and Applicant will not sell, distribute or transfer control of domain name registrations to any party that is not an Affiliate of Applicant as defined in the ICANN-Registry Operator Registry Agreement. All domain name registrations intended to be used within Applicant’s registry will be registered to and controlled and maintained by Applicant and for the benefit of Applicant and its users, parents, sisters and Affiliates.

At the appropriate time, between post-submission of this application and prior to the Applicant’s TLD launch, Applicant will identify, determine and engage the proper service provider (e.g. Applicant-approved registrar and⁄or selected backend registry services provider, Verisign) to support its provision of registration and abuse policies. Any engagement for the implementation and provision of such services shall be in compliance with all ICANN-mandated regulations, agreements, guidance and policies, as it is of paramount importance of the Applicant to protect the rights of all rightsholders.
1.6 Malicious or Abusive Behavior Definitions, Metrics, and Service Level Requirements for Resolution
Pursuant to the attached Abuse Prevention and Mitigation Implementation Plan, Applicant shall implement the following anti-abuse policy as a guideline:

The following definitions and policy (“Applicant Domain Anti-Abuse Policy”) shall be in effect between Applicant and its registrar:

Abusive use(s) of domain names in this TLD should not be tolerated. The nature of such abuses creates security and stability issues for the registry, registrars and registrants, as well as for users of the Internet in general. Applicant defines abusive use as the wrong or excessive use of power, position or ability, and includes, without limitation, the following:

• Illegal or fraudulent actions;
• Spam: The use of electronic messaging systems to send unsolicited bulk messages. The term applies to email spam and similar abuses such as instant messaging spam, mobile messaging spam, and the spamming of websites and Internet forums. An example, for purposes of illustration, would be the use of email in denial-of-service attacks;
• Phishing: The use of counterfeit web pages that are designed to trick recipients into divulging sensitive data such as usernames, passwords, or financial data;
• Pharming: The redirecting of unknowing users to fraudulent sites or services, typically through DNS hijacking or poisoning;
• Willful distribution of malware: The dissemination of software designed to infiltrate or damage a computer system without the ownerʹs informed consent. Examples include, without limitation, computer viruses, worms, keyloggers, and trojan horses;
• Fast-flux hosting: Use of fast-flux techniques to disguise the location of websites or other Internet services, or to avoid detection and mitigation efforts, or to host illegal activities. Fast-flux techniques use DNS to frequently change the location on the Internet to which the domain name of an Internet host or name server resolves. Fast-flux hosting may be used only with prior permission of LDH;
• Botnet command and control: Services run on a domain name that are used to control a collection of compromised computers or ʺzombies,ʺ or to direct denial-of-service attacks (DDoS attacks);
• Distribution of child pornography; and
• Illegal Access to Other Computers or Networks: Illegally accessing computers, accounts, or networks belonging to another party, or attempting to penetrate security measures of another individualʹs system (often known as ʺhackingʺ). Also, any activity that might be used as a precursor to an attempted system penetration (e.g., port scan, stealth scan, or other information gathering activity).

Applicant reserves the right to deny, cancel or transfer any registration or transaction, or place any domain name(s) on registry lock, hold or similar status, that it deems necessary, in its discretion; (1) to protect the integrity and stability of the registry; (2) to comply with any applicable laws, government rules or requirements, requests of law enforcement, or any dispute resolution process; (3) to avoid any liability, civil or criminal, on the part of Applicant, as well as its Affiliates, subsidiaries, officers, directors, and employees; (4) per the terms of the registration agreement or (5) to correct mistakes made by Applicant or its registrar in connection with a domain name registration.

Applicant also reserves the right to place upon registry lock, hold or similar status a domain name during resolution of a dispute.

Abusive uses, as defined above, undertaken with respect to domain names in this TLD shall give rise to the right of Applicant to take such actions as per its RRA in its sole discretion.

All reports of abuse should be sent to an email address that will be publicly identified by Applicant for receiving reports of abuse.
1.7 Controls to Ensure Proper Access to Domain Functions
Applicant intends to function, per the ICANN-Registry Operator Registry Agreement, as a Specification 9 exempt TLD whereby all domain name registrations in the TLD shall be registered to and maintained by Applicant and Applicant will not sell, distribute or transfer control of domain name registrations to any party that is not an Affiliate of Applicant as defined in the ICANN-Registry Operator Registry Agreement. All domain name registrations intended to be used within Applicant’s registry will be registered to and controlled and maintained by Applicant and for the benefit of Applicant and its users, parents, sisters and Affiliates. Access to domain functions will be limited to Applicant and its engaged service provider partners by implementing and complying with their established safeguards and access features as articulated below.
1.7.1 Multi-Factor Authentication
To ensure proper access to domain functions, the Applicant incorporates Verisign’s Registry-Registrar Two-Factor Authentication Service into its full-service registry operations. The service is designed to improve domain name security and assist registrars in protecting the accounts they manage by providing another level of assurance that only authorized personnel can communicate with the registry. As part of the service, dynamic one-time passwords (OTPs) augment the user names and passwords currently used to process update, transfer, and⁄or deletion requests. These one-time passwords enable transaction processing to be based on requests that are validated both by “what users know” (i.e., their user name and password) and “what users have” (i.e., a two-factor authentication credential with a one-time-password).
Registrars can use the one-time-password when communicating directly with Verisign’s Customer Service department as well as when using the registrar portal to make manual updates, transfers, and⁄or deletion transactions. The Two-Factor Authentication Service is an optional service offered to registrars that execute the Registry-Registrar Two-Factor Authentication Service Agreement. As shown in Figure 28-1, the registrars’ authorized contacts use the OTP to enable strong authentication when they contact the registry. There is no charge for the Registry-Registrar Two-Factor Authentication Service. It is enabled only for registrars that wish to take advantage of the added security provided by the service.
1.7.2 Requiring Multiple, Unique Points of Contact
Unique points of contact (POC) and their respective actions will be determined by Applicant at the appropriate time prior to the implementation of the gTLD.
1.7.3 Requiring the Notification of Multiple, Unique Points of Contact
Unique points of contact (POC) and their respective actions will be determined by Applicant at the appropriate time prior to the implementation of the gTLD.
2. TECHNICAL PLAN THAT IS ADEQUATELY RESOURCED IN THE PLANNED COSTS DETAILED IN THE FINANCIAL SECTION
Resource Planning
Applicant projects it will use the following personnel roles to support the implementation of the policies articulated in this section:
o 1 senior level executive
o 1 marketing⁄business manager
o 1 technical manager
o 1 administrative professional

To implement and manage Applicant’s gTLD as described in this application, Applicant can scale as needed, and utilize resources provided by our parent company, as defined above. In particular, personnel currently involved in the operation of parent entity’s existing .com business can assist with the needs of this new gTLD and may be transitioned over to supporting the gTLD as the .com businesses wind down in favor of the new gTLD. In addition to these individuals, Applicant parent entity will support implementation of these policies through the provision of their resources as well as additional outside resources on an as-needed basis. Support from our parent company will include access to a law department, finance department, information systems, technical support, human resources and such other administrative support that may be required. In particular, we anticipate using outside advisors and lawyers to assist in managing any disputes which must be resolved. Once the top level domain has been awarded, we do not anticipate disputes beyond what is frequently encountered in operating the .com. However, given the expanded opportunities associated with operating the top level domain, we have increased the likelihood of disputes, take down notices or such other matters and increased the .com dispute resolution budget. We will utilize outside advisors to provide the additional talent and resources and specialized knowledge that we cannot cost effectively maintain internally. Projected costs associated with these resources are further discussed in the response to Question 47 below.
Resource Planning Specific to Backend Registry Activities
Verisign, the Applicant’s selected backend registry services provider, is an experienced backend registry provider that has developed a set of proprietary resourcing models to project the number and type of personnel resources necessary to operate a TLD. Verisign routinely adjusts these staffing models to account for new tools and process innovations. These models enable Verisign to continually right-size its staff to accommodate projected demand and meet service level agreements as well as Internet security and stability requirements. Using the projected usage volume for the most likely scenario (defined in Question 46, Template 1 – Financial Projections: Most Likely) as an input to its staffing models, Verisign derived the necessary personnel levels required for this gTLD’s initial implementation and ongoing maintenance. Verisign’s pricing for the backend registry services it provides to the Applicant fully accounts for cost related to this infrastructure, which is provided as “Total Critical Registry Function Cash Outflows” (Template 1, Line IIb.G) within the Question 46 financial projections response.
Verisign employs more than 1,040 individuals of which more than 775 comprise its technical work force. (Current statistics are publicly available in Verisign’s quarterly filings.) Drawing from this pool of on-hand and fully committed technical resources, Verisign has maintained DNS operational accuracy and stability 100 percent of the time for more than 13 years for .com, proving Verisign’s ability to align personnel resource growth to the scale increases of Verisign’s TLD service offerings.
Verisign projects it will use the following personnel roles, which are described in Section 5 of the response to Question 31, Technical Overview of Proposed Registry, to support abuse prevention and mitigation:
• Application Engineers: 19
• Business Continuity Personnel: 3
• Customer Affairs Organization: 9
• Customer Support Personnel: 36
• Information Security Engineers: 11
• Network Administrators: 11
• Network Architects: 4
• Network Operations Center (NOC) Engineers: 33
• Project Managers: 25
• Quality Assurance Engineers: 11
• Systems Architects: 9

To implement and manage the TLD as described in this application, Verisign, the Applicant’s selected backend registry services provider, scales, as needed, the size of each technical area now supporting its portfolio of TLDs. Consistent with its resource modeling, Verisign periodically reviews the level of work to be performed and adjusts staff levels for each technical area.
When usage projections indicate a need for additional staff, Verisign’s internal staffing group uses an in-place staffing process to identify qualified candidates. These candidates are then interviewed by the lead of the relevant technical area. By scaling one common team across all its TLDs instead of creating a new entity to manage only this proposed gTLD, Verisign realizes significant economies of scale and ensures its TLD best practices are followed consistently. This consistent application of best practices helps ensure the security and stability of both the Internet and this proposed gTLD, as Verisign holds all contributing staff members accountable to the same procedures that guide its execution of the Internet’s largest TLDs (i.e., .com and .net). Moreover, by augmenting existing teams, Verisign affords new employees the opportunity to be mentored by existing senior staff. This mentoring minimizes start-up learning curves and helps ensure that new staff members properly execute their duties.
3. POLICIES AND PROCEDURES IDENTIFY AND ADDRESS THE ABUSIVE USE OF REGISTERED NAMES AT START-UP AND ON AN ONGOING BASIS
3.1 Start-Up Anti-Abuse Policies and Procedures
a. Pre-Reservation Service: Applicant may enable existing holders of a trademark to block Applicant registrations that correspond to their existing registrations in other ICANN recognized TLDs.
b. Trademark Clearinghouse: Trademark owners will have an extended period in which they can register their trademarks with the Trademark Clearinghouse. Once registration begins, if a registrant attempts to register a name that has been registered with the Trademark Clearinghouse, the prospective registrant will be notified of the existence of the registration with the Trademark Clearinghouse.
3.2 Ongoing Anti-Abuse Policies and Procedures
3.2.1 Policies and Procedures That Identify Malicious or Abusive Behavior
Verisign, the Applicant’s selected backend registry services provider, provides the following service to the Applicant for incorporation into its full-service registry operations.
Malware scanning service. Registrants are often unknowing victims of malware exploits. Verisign has developed proprietary code to help identify malware in the zones it manages, which in turn helps registrars by identifying malicious code hidden in their domain names.
Verisign’s malware scanning service helps prevent websites from infecting other websites by scanning web pages for embedded malicious content that will infect visitors’ websites. Verisign’s malware scanning technology uses a combination of in-depth malware behavioral analysis, anti-virus results, detailed malware patterns, and network analysis to discover known exploits for the particular scanned zone. If malware is detected, the service sends the registrar a report that contains the number of malicious domains found and details about malicious content within its TLD zones. Reports with remediation instructions are provided to help registrars and registrants eliminate the identified malware from the registrant’s website.
3.2.2 Policies and Procedures That Address the Abusive Use of Registered Names
Suspension processes. In addition to the safeguards and mechanisms additionally provided for above and below and those required by ICANN and applicable law, rightsholders will have the opportunity to provide written notification of claimed abuse and Applicant will investigate notices of abuse and take appropriate actions pursuant to the policies articulated herein and those required by ICANN and applicable law.
Dispute Resolution Procedures: Registered domains will be subject to challenge under ordinary domain dispute procedures set forth by ICANN, including but not limited to, Uniform Domain-Name Dispute-Resolution Policy (UDRP), Uniform Rapid Suspension system (URS), Trademark Post-Delegation Dispute Procedure (PDDRP), and Registration Restriction Dispute Resolution Procedure (RRDRP). Applicant agrees to implement and adhere to any remedies imposed by decision makers under such procedures.
Compliance with Court Orders and Law Enforcement Requests: Applicant reserves the right, but disclaims any obligation or responsibility, to (a) refuse to post or communicate or remove any submission from any Applicant site that is deemed to be abusive and (b) identify any user to third parties, and⁄or disclose to third parties any submission or personally identifiable information, when we believe in good faith that such identification or disclosure will either (i) facilitate compliance with laws, including, for example, compliance with a court order or subpoena, or (ii) help to enforce these policies and⁄or other Applicant rules or regulations, and⁄or protect the safety or security of any person or property, including any Applicant site. Moreover, we retain all rights to remove Submissions at any time for any reason or no reason whatsoever. Applicant reserves the right to provide information to third parties pursuant to a contractual or legal obligation.
Takedown Procedures: Applicant will comply with the terms set forth in the Uniform Rapid Suspension (URS) procedure, Trademark Post-Delegation Dispute Procedure (PDDRP), and Registration Restriction Dispute Resolution Procedure (RRDRP). Applicant agrees to implement and adhere to any remedies imposed by decision makers under such procedures. Takedown or Suspension requests provided directly to Applicant must demonstrate the following:
• The complaint must include complainant’s name, address, and email or telephone number (preferably both), and any legal counsel actively representing you in the matter, including their contact information.
• The complaint must include specific details concerning the alleged Terms violation, including but not limited to: (i) exact URL(s) where we can see the violation, (ii) for matters where URLs cannot be used (i.e., spam and⁄or phishing allegations), copies of files used as part of the violation and evidence as to their origins (i.e., emails including full headers), and (iii) any other supporting evidence such as screen shots and⁄or server log files.
• The terms violation must currently be in active and verifiable use at the time we investigate the matter.
• Applicant will suspend a registered domain on orders from a court or authority in an ICANN-approved dispute resolution procedure. The domain name will be unsuspended in view of an executive proceeding on the matter rejecting the request for suspension or upon a showing that the matter has been resolved in favor of the registrant. Appeals will be handled through the authority issuing the suspension request.

Suspension processes conducted by backend registry services provider. In the case of domain name abuse, the Applicant will determine whether to take down the subject domain name. Verisign, the Applicant’s selected backend registry services provider, will follow the following auditable processes (shown in Figure 28-2) to comply with the suspension request.
Verisign Suspension Notification. The Applicant submits the suspension request to Verisign for processing, documented by:
• Threat domain name
• Registry incident number
• Incident narrative, threat analytics, screen shots to depict abuse, and⁄or other evidence
• Threat classification
• Threat urgency description
• Recommended timeframe for suspension⁄takedown
• Technical details (e.g., WHOIS records, IP addresses, hash values, anti-virus detection results⁄nomenclature, name servers, domain name statuses that are relevant to the suspension)
• Incident response, including surge capacity

Verisign Notification Verification. When Verisign receives a suspension request from the Applicant, it performs the following verification procedures:
• Validate that all the required data appears in the notification.
• Validate that the request for suspension is for a registered domain name.
• Return a case number for tracking purposes.
Suspension Rejection. If required data is missing from the suspension request, or the domain name is not registered, the request will be rejected and returned to the Applicant with the following information:
• Threat domain name
• Registry incident number
• Verisign case number
• Error reason

4. WHEN EXECUTED IN ACCORDANCE WITH THE REGISTRY AGREEMENT, PLANS WILL RESULT IN COMPLIANCE WITH CONTRACTUAL REQUIREMENTS
The Applicant’s proposed Abuse Prevention and Mitigation Implementation Plan is and shall be consistent with the draft Registry Agreement provided by ICANN, including all Specifications, and when executed, Applicant will be compliant with the contractual requirements of the Registry Agreement, including relevant specifications, as well as any and all emerging ICANN policies, if and when they become approved. In the event that Applicant’s proposed Abuse Prevention and Mitigation Implementation Plan is not consistent with the Registry Agreement, Applicant will amend the Abuse Prevention and Mitigation Implementation Plan to result in compliance.
5. TECHNICAL PLAN SCOPE⁄SCALE THAT IS CONSISTENT WITH THE OVERALL BUSINESS APPROACH AND PLANNED SIZE OF THE REGISTRY
Scope⁄Scale Consistency
Applicant intends to function, per the ICANN-Registry Operator Registry Agreement, as a Specification 9 exempt TLD whereby all domain name registrations in the TLD shall be registered to and maintained by Applicant and Applicant will not sell, distribute or transfer control of domain name registrations to any party that is not an Affiliate of Applicant as defined in the ICANN-Registry Operator Registry Agreement. All domain name registrations intended to be used within Applicant’s registry will be registered to and controlled and maintained by Applicant and for the benefit of Applicant and its users, parents, sisters and Affiliates. Applicant does not intend to register in excess of around one thousand registrations at most. Within that context, Applicant will continue to ensure that the execution and implementation of these policies are consistent with the plan, objective and size of the registry.
Scope⁄Scale Consistency Specific to Backend Registry Activities
Verisign, the Applicant’s selected backend registry services provider, is an experienced backend registry provider that has developed and uses proprietary system scaling models to guide the growth of its TLD supporting infrastructure. These models direct Verisign’s infrastructure scaling to include, but not be limited to, server capacity, data storage volume, and network throughput that are aligned to projected demand and usage patterns. Verisign periodically updates these models to account for the adoption of more capable and cost-effective technologies.
Verisign’s scaling models are proven predictors of needed capacity and related cost. As such, they provide the means to link the projected infrastructure needs of the TLD with necessary implementation and sustainment cost. Using the projected usage volume for the most likely scenario (defined in Question 46, Template 1 – Financial Projections: Most Likely) as an input to its scaling models, Verisign derived the necessary infrastructure required to implement and sustain this gTLD. Verisign’s pricing for the backend registry services it provides to the Applicant fully accounts for cost related to this infrastructure, which is provided as “Other Operating Cost” (Template 1, Line I.L) within the Question 46 financial projections response.