28 Abuse Prevention and Mitigation

Prototypical answer:

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.

Similar gTLD applications: (20)