gTLD	Full Legal Name	E-mail suffix	Detail
.bank	fTLD Registry Services LLC	fsround.org	View

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

1.1 .bank Abuse Prevention and Mitigation Implementation Plan

fTLD Registry Services, LLC (FRS) will employ a comprehensive approach toward mitigating abusive and⁄or non-compliant registrations within the .bank name space that is modeled in part after the tapestry approach first proposed by ICANN’s Implementation Recommendation Team (IRT). This tapestry approach includes, but is not limited
to, the following requirements: registrant eligibility; name selection criteria; content and use restrictions; escalated compliance, response and takedown procedures; annual registry and registrar audits; prohibition against proxy registration; semi-annual Whois verification that requires affirmative acknowledgement from the registrant; and elevated security⁄technical requirements for the Registry, Registrars and Registrants. Each of these individual elements are described in greater detail in FRS’ response to Question 30.

These requirements which were formally proposed to ICANN in December 2011 (see Attachment 28-1) by the American Bankers Association (ABA) and BITS (the technology policy division of The Financial Services Roundtable (Roundtable)) Security Standards Working Group, have since been incorporated and referenced in question 30 of ICANN’s Applicant Guidebook. FRS will contractually hard code these requirements into both the Registry-Registrar Agreement (RRA) as well as the Registrant Registration Agreement to ensure that it has the legal means to enforce these obligations.

FRS believes this comprehensive approach toward abuse prevention and mitigation is a best in class solution that will leverage the dedication and commitment of FRS staff and its members, as well as the established track record of its selected backend registry infrastructure provider, Verisign.


1.2 Policies for Handling Complaints Regarding Abuse

As required by the ICANN template Registry Agreement, FRS will establish, publish, and maintain on its website a single point of contact for handling abuse complaints. This contact will be a role account, e.g., abuse@registry.bank. All email inquiries will immediately receive an automated response indicating that the inquiry has been received and docketed into FRS’ ticketing system, a telephone number will also be provided for those individuals and or entities that may require immediate interaction with the registry. It is important to note, however, that as part of the Enhanced Security Standards proposed by the Security Standards Working Group, both FRS and all .bank accredited registrars will be required to have a telephone number dedicated to handling complaints about abuse available on their website. For those inquiries which are not received via email and automatically entered into the ticketing system, there will be a means for FRS staff to enter complaints into the ticketing system.

When a complaint has been received from a trusted⁄verified source or independently identified by FRS, FRS will use commercially reasonable efforts to verify the information in the complaint. Once FRS is able to verify the credibility of the complaint, it will be immediately forwarded to the Registrar for investigation and appropriate action within twelve hours. If the complaint falls within the scope of FRS’ Abuse Policy Listed below, the default action for a Registrar that is unable to resolve the issue is for the Registrar to disable the domain name by placing the domain name on hold. If the Registrar has not taken the necessary action to stop the abuse within the allotted time of twelve hours, and has not provided FRS with a compelling reason to keep the domain name in the zone file, FRS will place the domain name in question on hold. This action by FRS will remove the domain name from the zone file, but still leaves the underlying Whois information associated with the domain name available for public access⁄review.

In accordance with the Security Standards Working Group recommendations, there will be a contractual requirement between FRS and all .bank accredited registrars for the mandatory sharing of information regarding instances of abuse, where legally applicable. This qualification is necessary as there may be instances where registration
authorities are prohibited by law from sharing information with third parties.

The role email account identified above will have multiple FRS staff recipients to allow for monitoring on a 24X7 basis. In addition the phone number provided that will be answered by FRS staff during normal working hours, calls will be forwarded to a professional answering service for expedited processing by the appropriate FRS staff who will operate on a rotational on-call basis, and supplemented by external qualified consultants as needed.

With regard to inquiries from law enforcement, FRS will respond to inquiries from legitimate law enforcement agencies within one business day. If any of the actions fall within the scope of FRS’ Abuse Policy identified below, FRS will follow the actions identified above for the timely resolution of the matter, or the domain name will be placed on hold.


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. FRS’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 FRS abuse plan are provided in Section 2 of this response.

1.5 Measures to Promote Whois Accuracy

Ensuring the accuracy of Whois information is of paramount importance to FRS in the operation of the .bank gTLD. As noted in the Enhanced Security Standards, FRS will maintain on its website valid primary contact information (e.g., name, email address, and phone number). All .bank accredited registrars will be contractually required to do the same.

FRS will employ the following mechanism to promote Whois accuracy.
1) There will be a strict prohibition against the use of proxy registration services;
2) Domain names will not be active in the DNS until they have been validated against eligibility criteria which requires validating the identity of the registrant;
3) The Registrant Whois must be affirmatively revalidated semi-annually. Unlike current industry practices which just involve sending an email to a registrant asking them to confirm the accuracy of the Whois data, this semi-annual re-validation will require positive affirmation from the Registrant; and,
4) FRS will maintain a web-based form for third parties to submit claims regarding false and or inaccurate Whois data and FRS will forward credible claims to the Registrar for investigation⁄resolution. FRS will follow up after 30 days to verify that the claim has been satisfactorily resolved. Failure of the Registrar or Registrant to resolve the problem will result in FRS placing the domain name on hold, absent extraordinary circumstances. This proactive approach is much more robust than the current process which ICANN has implemented.


1.5.1 Authentication of Registrant Information

FRS has contractually required all .bank potential Registrants to be verified against FRS’s Registrant Eligibility and Name Selection criteria. This verification process will therefore necessitate the authentication of a Registrant prior to registration. In addition, the fact that most corporate registrars have an existing long standing
relationship with financial service community members adds an additional layer of social authentication into the process. These long standing relationships as well as other technical trends, provide the ability for FRS to run automated queries associated with the .bank zone files to identify potential anomalous registrations.

1.5.2 Regular Monitoring of Registration Data for Accuracy and Completeness

As part of their Registry-Registrar Agreement, all .bank Registrars will be required to revalidate Whois data for each record they have registered on a semi-annual basis. This revalidation will require the Registrant to affirmatively respond to a confirmation email sent out within a set period of time. While FRS reserves the right to suspend domain names that are not verified in a timely manner, FRS will engage in other outreach to the Registrant prior to suspending any domain name, FRS will conduct post-registration audits to verify Whois information to ensure compliance and accuracy. In addition, the registry will allow interested parties to report cases of inaccurate Whois information via the .bank TLD website, and FRS will undertake an investigation as identified above. FRS founding members have been actively involved in ICANN’s policy development process and will continue to do so in conjunction with this issue.

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

During the pendency of the ICANN application process, FRS will undertake a preliminary survey of the Registrars currently used by most members of the financial service community. FRS will focus its initial outreach and accreditation efforts on these Registrars. As noted above, all FRS Registrars will be contractually required to verify the Registrant eligibility criteria of all .bank Registrants. In addition, all Registrars will be required to certify annually to ICANN and the Registry Operator, its compliance with the Registry-Registrar Agreement. Due to these stringent requirements, FRS does not anticipate a large number of Registrars will be interested in providing domain name registration services in the .bank gTLD. However, FRS believes that a number of corporate-centric Registrars will be interested in providing service in the .bank gTLD as part of their desire to provide a full range of services to these clients.


1.6 Malicious or Abusive Behavior Definitions, Metrics, and Service Level Requirements for Resolution

FRS’s definition of Abuse or Malicious behavior is set forth in the FRS Abuse Policy.


1.7 Controls to Ensure Proper Access to Domain Functions

In addition to the security features that FRS Registrars will be incorporating at the Registrar level, FRS will implement the following enhancements at the Registry level.

1.7.1 Multi-Factor Authentication

To ensure proper access to domain functions, FRS 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 Attachment 28-2, 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 Unique Points of Contact

In light of the implementation of two-factor authentication at both the registrant and registrar levels, the requirement for unique points of contact is not necessary.


1.7.3 Requiring the Notification of Multiple, Unique Points of Contact

In light of the implementation of two-factor authentication at both the registrant and registrar levels, the requirement for unique points of contact is not necessary.


2. TECHNICAL PLAN THAT IS ADEQUATELY RESOURCED IN THE PLANNED COSTS DETAILED IN THE FINANCIAL SECTION

Resource Planning

fTLD Registry Services, LLC (FRS) is committed to operating the .bank gTLD in a manner that benefits the banking industry, specifically, and the financial services community while demonstrating the highest levels of security, stability and resiliency. FRS strategically chose Verisign as its registry services provider because of their excellent track record in operating some of the worldʹs most complex and critical gTLDs. Verisignʹs support for the .bank gTLD will help ensure its success.

FRS will employ 3 full-time professionals to coordinate the operation of the .bank gTLD. In addition to its full-time staff, FRS will be supported by professionals at its founding organizations including, but not limited to the American Bankers Association and The Financial Services Roundtable. This support will include, but not be limited to legal, finance and other services necessary for the successful operation of the .bank gTLD.

As the .bank gTLD is a community supported effort, it is also expected that members of the banking and financial services community will advise on and support FRS in implementing policies and procedures developed that govern the gTLD. This type of community effort has already taken place with the Security Standards Working Group and their development of Enhanced Security Standards for financial services gTLDs.

The following FRS professionals will be used to support the Abuse Prevention and Mitigation plan:

- Managing Director
- Director of Operations
- Manager, Community Relations

Resource Planning Specific to Backend Registry Activities

Verisign, FRS’ 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 FRS 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 .bank gTLD as described in this application, Verisign, FRS’ 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


3.1 Start-Up Anti-Abuse Policies and Procedures

Listed below is draft framework for a .bank Abuse and Use Policy. Prior to finalizing this policy, FRS will undertake a review of other Abuse and Acceptable Policies from similarly situated gTLD registry operators to develop a best-in-class policy to take prompt and decisive action when necessary. While FRS is currently envisioning a
separate standalone Abuse Policy, it reserves the right to incorporate this Abuse Policy into a broader Acceptable Use Policy.

PROPOSED .BANK ABUSE AND USE POLICY

Registry Operator 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, as it deems necessary, in its unlimited and sole discretion and without notice, either temporarily or permanently: (a) to protect the integrity, security and stability of the Domain Name system (DNS); (b) to comply with any applicable court orders, laws, government rules or requirements, requests of law enforcement or other governmental agency or organization, or any dispute resolution process; (c) to avoid any liability, civil or criminal, on the part of FRS, as well as its affiliates, subsidiaries, officers, directors, and employees; (d) per the terms of the registration agreement, (e) to respond to or protect against any form of malware (defined to include, without limitation, malicious code or software that might affect the operation of the Internet), (f) to comply with specifications adopted by any industry group generally recognized as authoritative with respect to the Internet (e.g., RFCs), (g) to correct mistakes made by Registry Operator, backend registry infrastructure provider, or Registrar in connection with a domain name registration, or (h) for the non-payment of fees. Registry Operator also reserves the right to place a domain name on registry lock during the resolution of a dispute.The following are a non-exhaustive list of activities that are subject to rapid domain name compliance action:
- Botnet Command and Control: Services run on a domain name that is used to control a collection of compromised computers or “zombies,” or to direct Distributed Denial of Service attacks (DDoS attacks)
- Pornography: The storage, publication, display and⁄or dissemination of pornographic materials;
- Distribution of Malware: The intentional creation and intentional or unintentional distribution of “malicious” software designed to infiltrate a computer system without the owner’s consent, including, without limitation, computer viruses, worms, keyloggers, and Trojans.
- Fast Flux Attacks⁄Hosting: A technique used to shelter Phishing, Pharming, and Malware sites and networks from detection and to frustrate methods employed to defend against such practices, whereby the IP address associated with fraudulent sites are changed rapidly so as to make the true location of the sites difficult to find.
- Hacking: Unauthorized access to a computer network;
- Phishing: The use of email and counterfeit web pages that are designed to trick recipients into divulging sensitive data such as personally identifying information, usernames, passwords, or financial data;
- Pharming: The redirecting of unknown users to fraudulent sites or services, typically through, but not limited to, DNS hijacking or poisoning;
- 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 spamming of websites and Internet forums.
- Publication of Inappropriate Materials: Conducting activities that are prohibited by the entity’s charter or country regulator. This term also applies to language and visual content.

3.2 Ongoing Anti-Abuse Policies and Procedures

3.2.1 Policies and Procedures That Identify Malicious or Abusive Behavior

Verisign, FRS’ selected backend registry services provider, provides the following service to FRS 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.
FRS has incorporated a number of policies and procedures into the operation of the registry that provide registrants within the .bank namespace and their customers heightened security. FRS’ approach toward tackling abusive registrations is part of a much boarder compliance and abuse philosophy which is founded on the following pillars⁄principles: timely verification; timely investigation; timely remediation; and timely follow-up.

TIMELY VERIFICATION: While FRS is committed to bring all of its available resources to timely investigate and resolve any abusive activity and⁄or non-compliance within the .bank namespace, the first prerequisite is the need to verify the authenticity of the request. Some ICANN reporting mechanisms have been subject to misuse by third parties in the past. Therefore, FRS will have to undertake a preliminary analysis to verify if a complaint has been received from a trusted⁄verified source or independently identified by FRS. In making this initial determination, FRS will rely upon internal FRS, as well as potential consultation with its backend provider Verisign and other external consultants.

While FRS does not anticipate a high volume of complaints due to the restrictive nature of the namespace, FRS proposes the following prioritizing for verification of processed complaints. Complaints from legitimate law enforcement agencies will be processed within 24 hours, although FRS will strive for a shorter window of response, e.g., 6 to 12 hours. As FRS fosters and develops deeper working relationships with governmental and law enforcement officials this shorter response window should be achievable. The second highest prioritization will be assigned to complaints involving third-party reports involving security, stability, or criminal activity. FRS will use commercially reasonable efforts to verify these complaints within one business day. The lowest prioritization for investigation will be assigned to complaints of non-compliance that to not rise to a level of security, stability or criminal activity. FRS will use commercially reasonable efforts to verify these complaints within five business days.

TIMELY INVESTIGATION: FRS will prioritize all investigates in a similar order as identified in the preceding section: law enforcement complaints; third party security, stability or criminal complaints; and third party non-security, non-stability, or non-criminal complaints. While FRS staffing levels are suitable to handle expected volumes of complaints and the associated verification⁄investigation⁄remediation⁄follow-up tasks, FRS will have qualified external consultants on call to supplement FRS staffing needs to meet the timelines set forth herein. While FRS will use commercially reasonable efforts to timely investigate verified complaints, it is difficult to set arbitrary timelines for resolution as some issues can require in-depth investigation. Notwithstanding these facts, FRS commits to provide a preliminary investigation status update within 24 hours following verification in connection with complaints from legitimate law enforcement. FRS will seek to establish a close and open dialog with law enforcement during these types of investigations and will always respond within 24 hours during the pendency of the investigation. In connection with third-party complaints involving security, stability, or criminal activity, FRS will use commercially reasonable efforts to provide a preliminary investigation status update within one business day of verification, and a similar one business day time frame for any subsequent follow-up regarding the investigation. In connection with third-party complaints that do not involve security, stability or criminal activity, FRS will use commercially reasonable efforts to provide a preliminary investigation status update within five business days of verification, and a similar five business day time frame for any subsequent follow-up regarding the investigation.

TIMELY REMEDIATION: While FRS is fully committed to using all available resources to resolve abusive and⁄or non-compliant activity within the .bank namespace, including but not limited to domain name suspension and or cancelation, FRS has developed the following remediation plan. In connection with credible threats which significantly impact or threaten the security, stability of the Internet or the .bank namespace, or which is causing direct and material harm to others, FRS’ default option will be the suspension of the domain name within twelve hours of completing a preliminary investigation. The only exception would be unless FRS after consulting with its team of legal, technical and policy advisories (both internal and external) decided that there was a compelling reason not to suspend the domain name. If such a determination is made by FRS, this decision and an explanation will be provided to either law enforcement or the third party.

In all other complaints not involving security, stability or criminal activity, FRS will seek to resolve the matter through an escalated notification process: email, telephone, certified mail. While FRS is fully committed to ensuring that all registrant comply with the contractual requirements set forth in their domain name registrant agreement, FRS wants to avoid prematurely suspending and⁄or cancelling a domain name that may have a larger impact of a much larger community of users. Similar to above, FRS will consult with its team of legal, technical and policy advisories (both internal and external) before deciding to suspend⁄cancel a domain name. During the pendency of this remediation, FRS will remain in dialog with the original third-party complainant.

TIMELY FOLLOW-UP: FRS does not view its commitment to the community as stopping just after a threat has been neutralized. Instead, FRS will follow-up in connection with each complaint to either re-activate a domain name after the abusive⁄non-compliant activity has been resolved, or help educate the registrant as to how to avoid future
remediation actions.

Listed below are details on how FRS will interact with its designated backend registry service provider Verisign to implement the policy and procedures set forth above.
Suspension processes conducted by backend registry services provider (see Attachment 28-3). In the case of domain name abuse, FRS will determine whether to take down the subject domain name. Verisign, FRS’ selected backend registry services provider, will follow the following auditable processes to comply with the suspension request.Verisign Suspension Notification. FRS 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 FRS, 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 FRS with the following information:
- Threat domain name
- Registry incident number
- Verisign case number
- Error reason

Registrar Notification. Once Verisign has performed the domain name suspension, and upon FRS request, Verisign notifies the registrar of the suspension. Registrar notification includes the following information:
- Threat domain name
- Registry incident number
- Verisign case number
- Classification of type of domain name abuse
- Evidence of abuse
- Anti-abuse contact name and number
- Suspension status
- Date⁄time of domain name suspension

Registrant Notification. Once Verisign has performed the domain name suspension, and upon FRS request, Verisign notifies the registrant of the suspension. Registrant notification includes the following information:
- Threat domain name
- Registry incident number
- Verisign case number
- Classification of type of domain name abuse
- Evidence of abuse
- Registrar anti-abuse contact name and number

Upon FRS 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:
- serverUpdateProhibited
- serverDeleteProhibited
- serverTransferProhibited
- serverHold

Suspension Acknowledgement. Verisign notifies FRS that the suspension has been completed. Acknowledgement of the suspension includes the following information:
- Threat domain name
- Registry incident number
- Verisign case number
- Case number
- Domain name
- FRS abuse contact name and number, or registrar abuse contact name and number
- Suspension status


4. WHEN EXECUTED IN ACCORDANCE WITH THE REGISTRY AGREEMENT, PLANS WILL RESULT IN COMPLIANCE WITH CONTRACTUAL

REQUIREMENTS

FRS believes that the proposed tapestry of protections that involve both proactive and reactive mechanism will provide an unmatched level of security and anti-abuse activity within the .bank gTLD. These mechanisms will be hard coded into both the Registry-Registrar Agreement as well as the Registrant Registration Agreement.


5. TECHNICAL PLAN SCOPE⁄SCALE THAT IS CONSISTENT WITH THE OVERALL BUSINESS APPROACH AND PLANNED SIZE OF THE

REGISTRY

Scope⁄Scale Consistency

FRS is confident that the distribution of validation⁄verification services between itself and .bank accredited Registrars will provide the level of protection needed to minimize potential abuse activity within the gTLD given the relatively small scale of FRS full-time staff and external consultants.

Scope⁄Scale Consistency Specific to Backend Registry Activities

Verisign, FRS’ 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 .bank 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 FRS 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.

gTLD	Full Legal Name	E-mail suffix	Detail
.insurance	fTLD Registry Services LLC	fsround.org	View

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

1.1 .insurance Abuse Prevention and Mitigation Implementation Plan

fTLD Registry Services, LLC (FRS) will employ a comprehensive approach toward mitigating abusive and⁄or non-compliant registrations within the .insurance name space that is modeled in part after the tapestry approach first proposed by ICANN’s Implementation Recommendation Team (IRT). This tapestry approach includes, but is not limited to, the following requirements: registrant eligibility; name selection criteria; content and use restrictions; escalated compliance, response and takedown procedures; annual registry and registrar audits; prohibition against proxy registration; semi-annual Whois verification that requires affirmative acknowledgement from the registrant; and elevated security⁄technical requirements for the Registry, Registrars and Registrants. Each of these individual elements are described in greater detail in FRS’ response to Question 30.

These requirements which were formally proposed to ICANN in December 2011 (see Attachment 28-1) by the American Bankers Association (ABA) and BITS (the
technology policy division of The Financial Services Roundtable (Roundtable)) Security Standards Working Group, have since been incorporated and referenced in question 30 of ICANN’s Applicant Guidebook. FRS will contractually hard code these requirements into both the Registry-Registrar Agreement (RRA) as well as the Registrant Registration Agreement to ensure that it has the legal means to enforce these obligations.

FRS believes this comprehensive approach toward abuse prevention and mitigation is a best in class solution that will leverage the dedication and commitment of FRS staff and its members, as well as the established track record of its selected backend registry infrastructure provider, Verisign.

1.2 Policies for Handling Complaints Regarding Abuse

As required by the ICANN template Registry Agreement, FRS will establish, publish, and maintain on its website a single point of contact for handling abuse complaints. This contact will be a role account, e.g., abuse@registry.insurance. All email inquiries will immediately receive an automated response indicating that the inquiry
has been received and docketed into FRS’ ticketing system, a telephone number will also be provided for those individuals and or entities that may require immediate interaction with the registry. It is important to note, however, that as part of the Enhanced Security Standards proposed by the Security Standards Working Group, both FRS and all .insurance accredited registrars will be required to have a telephone number dedicated to handling complaints about abuse available on their website. For those inquiries which are not received via email and automatically entered into the ticketing system, there will be a means for FRS staff to enter complaints into the ticketing system.

When a complaint has been received from a trusted⁄verified source or independently identified by FRS, FRS will use commercially reasonable efforts to verify the
information in the complaint. Once FRS is able to verify the credibility of the complaint, it will be immediately forwarded to the Registrar for investigation and appropriate
action within twelve hours. If the complaint falls within the scope of FRS’ Abuse Policy Listed below, the default action for a Registrar that is unable to resolve the issue is for the Registrar to disable the domain name by placing the domain name on hold. If the Registrar has not taken the necessary action to stop the abuse within the
allotted time of twelve hours, and has not provided FRS with a compelling reason to keep the domain name in the zone file, FRS will place the domain name in question on hold. This action by FRS will remove the domain name from the zone file, but still leaves the underlying Whois information associated with the domain name available for public access⁄review.

In accordance with the Security Standards Working Group recommendations, there will be a contractual requirement between FRS and all .insurance accredited registrars for the mandatory sharing of information regarding instances of abuse, where legally applicable. This qualification is necessary as there may be instances where registration authorities are prohibited by law from sharing information with third parties.

The role email account identified above will have multiple FRS staff recipients to allow for monitoring on a 24X7 basis. In addition the phone number provided that will be
answered by FRS staff during normal working hours, calls will be forwarded to a professional answering service for expedited processing by the appropriate FRS staff who will operate on a rotational on-call basis, and supplemented by external qualified consultants as needed.

With regard to inquiries from law enforcement, FRS will respond to inquiries from legitimate law enforcement agencies within one business day. If any of the actions fall
within the scope of FRS’ Abuse Policy identified below, FRS will follow the actions identified above for the timely resolution of the matter, or the domain name will be
placed on hold.


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. FRS’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 FRS abuse plan are provided in Section 2 of this response.

1.5 Measures to Promote Whois Accuracy

Ensuring the accuracy of Whois information is of paramount importance to FRS in the operation of the .insurance gTLD. As noted in the Enhanced Security Standards, FRS will maintain on its website valid primary contact information (e.g., name, email address, and phone number). All .insurance accredited registrars will be contractually required to do the same.

FRS will employ the following mechanism to promote Whois accuracy.
1) There will be a strict prohibition against the use of proxy registration services;
2) Domain names will not be active in the DNS until they have been validated against eligibility criteria which requires validating the identity of the registrant;
3) The Registrant Whois must be affirmatively revalidated semi-annually. Unlike current industry practices which just involve sending an email to a registrant asking them to confirm the accuracy of the Whois data, this semi-annual re-validation will require positive affirmation from the Registrant; and,
4) FRS will maintain a web-based form for third parties to submit claims regarding false and or inaccurate Whois data and FRS will forward credible claims to the Registrar for investigation⁄resolution. FRS will follow up after 30 days to verify that the claim has been satisfactorily resolved. Failure of the Registrar or Registrant to resolve the problem will result in FRS placing the domain name on hold, absent extraordinary circumstances. This proactive approach is much more robust than the current process which ICANN has implemented.


1.5.1 Authentication of Registrant Information

FRS has contractually required all .insurance potential Registrants to be verified against FRS’s Registrant Eligibility and Name Selection criteria. This verification process will therefore necessitate the authentication of a Registrant prior to registration. In addition, the fact that most corporate registrars have an existing long standing
relationship with financial service community members adds an additional layer of social authentication into the process. These long standing relationships as well as other technical trends, provide the ability for FRS to run automated queries associated with the .insurance zone files to identify potential anomalous registrations.

1.5.2 Regular Monitoring of Registration Data for Accuracy and Completeness

As part of their Registry-Registrar Agreement, all .insurance Registrars will be required to revalidate Whois data for each record they have registered on a semi-annual basis. This revalidation will require the Registrant to affirmatively respond to a confirmation email sent out within a set period of time. While FRS reserves the right to suspend domain names that are not verified in a timely manner, FRS will engage in other outreach to the Registrant prior to suspending any domain name, FRS will conduct post-registration audits to verify Whois information to ensure compliance and accuracy. In addition, the registry will allow interested parties to report cases of inaccurate Whois information via the .insurance TLD website, and FRS will undertake an investigation as identified above. FRS founding members have been actively
involved in ICANN’s policy development process and will continue to do so in conjunction with this issue.

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

During the pendency of the ICANN application process, FRS will undertake a preliminary survey of the Registrars currently used by most members of the financial
service community. FRS will focus its initial outreach and accreditation efforts on these Registrars. As noted above, all FRS Registrars will be contractually required to
verify the Registrant eligibility criteria of all .insurance Registrants. In addition, all Registrars will be required to certify annually to ICANN and the Registry Operator, its
compliance with the Registry-Registrar Agreement. Due to these stringent requirements, FRS does not anticipate a large number of Registrars will be interested in providing domain name registration services in the .insurance gTLD. However, FRS believes that a number of corporate-centric Registrars will be interested in providing service in the .insurance gTLD as part of their desire to provide a full range of services to these clients.


1.6 Malicious or Abusive Behavior Definitions, Metrics, and Service Level Requirements for Resolution

FRS’s definition of Abuse or Malicious behavior is set forth in the FRS Abuse Policy.


1.7 Controls to Ensure Proper Access to Domain Functions

In addition to the security features that FRS Registrars will be incorporating at the Registrar level, FRS will implement the following enhancements at the Registry level.

1.7.1 Multi-Factor Authentication

To ensure proper access to domain functions, FRS 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 Attachment 28-2, 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 Unique Points of Contact

In light of the implementation of two-factor authentication at both the registrant and registrar levels, the requirement for unique points of contact is not necessary.


1.7.3 Requiring the Notification of Multiple, Unique Points of Contact

In light of the implementation of two-factor authentication at both the registrant and registrar levels, the requirement for unique points of contact is not necessary.


2. TECHNICAL PLAN THAT IS ADEQUATELY RESOURCED IN THE PLANNED COSTS DETAILED IN THE FINANCIAL SECTION

Resource Planning

fTLD Registry Services, LLC (FRS) is committed to operating the .insurance gTLD in a manner that benefits the banking industry, specifically, and the financial services
community while demonstrating the highest levels of security, stability and resiliency. FRS strategically chose Verisign as its registry services provider because of their
excellent track record in operating some of the worldʹs most complex and critical gTLDs.Verisignʹs support for the .insurance gTLD will help ensure its success.

FRS will employ 3 full-time professionals to coordinate the operation of the .insurance gTLD. In addition to its full-time staff, FRS will be supported by professionals at its
founding organizations including, but not limited to the American Bankers Association and The Financial Services Roundtable. This support will include, but not be
limited to legal, finance and other services necessary for the successful operation of the .insurance gTLD.

As the .insurance gTLD is a community supported effort, it is also expected that members of the insuranceing and financial services community will advise on and support FRS in implementing policies and procedures developed that govern the gTLD. This type of community effort has already taken place with the Security Standards Working Group and their development of Enhanced Security Standards for financial services gTLDs.

The following FRS professionals will be used to support the Abuse Prevention and Mitigation plan:

- Managing Director
- Director of Operations
- Manager, Community Relations

Resource Planning Specific to Backend Registry Activities

Verisign, FRS’ 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 FRS 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 .insurance gTLD as described in this application, Verisign, FRS’ 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


3.1 Start-Up Anti-Abuse Policies and Procedures

Listed below is draft framework for a .insurance Abuse and Use Policy. Prior to finalizing this policy, FRS will undertake a review of other Abuse and Acceptable
Policies from similarly situated gTLD registry operators to develop a best-in-class policy to take prompt and decisive action when necessary. While FRS is currently envisioning a separate standalone Abuse Policy, it reserves the right to incorporate this Abuse Policy into a broader Acceptable Use Policy.

PROPOSED .INSURANCE ABUSE AND USE POLICY

Registry Operator 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, as it
deems necessary, in its unlimited and sole discretion and without notice, either temporarily or permanently: (a) to protect the integrity, security and stability of the
Domain Name system (DNS); (b) to comply with any applicable court orders, laws, government rules or requirements, requests of law enforcement or other governmental agency or organization, or any dispute resolution process; (c) to avoid any liability, civil or criminal, on the part of FRS, as well as its affiliates, subsidiaries, officers, directors, and employees; (d) per the terms of the registration agreement, (e) to respond to or protect against any form of malware (defined to include, without limitation, malicious code or software that might affect the operation of the Internet), (f) to comply with specifications adopted by any industry group generally recognized as authoritative with respect to the Internet (e.g., RFCs), (g) to correct mistakes made by Registry Operator, backend registry infrastructure provider, or Registrar in connection with a domain name registration, or (h) for the non-payment of fees. Registry Operator also reserves the right to place a domain name on registry lock during the resolution of a dispute.The following are a non-exhaustive list of activities that are subject to rapid domain name compliance action:
- Botnet Command and Control: Services run on a domain name that is used to control a collection of compromised computers or “zombies,” or to direct Distributed Denial of Service attacks (DDoS attacks)
- Pornography: The storage, publication, display and⁄or dissemination of pornographic materials;
- Distribution of Malware: The intentional creation and intentional or unintentional distribution of “malicious” software designed to infiltrate a computer system without the
owner’s consent, including, without limitation, computer viruses, worms, keyloggers, and Trojans.
- Fast Flux Attacks⁄Hosting: A technique used to shelter Phishing, Pharming, and Malware sites and networks from detection and to frustrate methods employed to defend against such practices, whereby the IP address associated with fraudulent sites are changed rapidly so as to make the true location of the sites difficult to find.
- Hacking: Unauthorized access to a computer network;
- Phishing: The use of email and counterfeit web pages that are designed to trick recipients into divulging sensitive data such as personally identifying information,
usernames, passwords, or financial data;
- Pharming: The redirecting of unknown users to fraudulent sites or services, typically through, but not limited to, DNS hijacking or poisoning;
- 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 spamming of websites and Internet forums.
- Publication of Inappropriate Materials: Conducting activities that are prohibited by the entity’s charter or country regulator. This term also applies to language and visual
content.

3.2 Ongoing Anti-Abuse Policies and Procedures


3.2.1 Policies and Procedures That Identify Malicious or Abusive Behavior

Verisign, FRS’ selected backend registry services provider, provides the following service to FRS 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.

FRS has incorporated a number of policies and procedures into the operation of the registry that provide registrants within the .insurance namespace and their customers heightened security. FRS’ approach toward tackling abusive registrations is part of a much boarder compliance and abuse philosophy which is founded on the following pillars⁄principles: timely verification; timely investigation; timely remediation; and timely follow-up.

TIMELY VERIFICATION: While FRS is committed to bring all of its available resources to timely investigate and resolve any abusive activity and⁄or non-compliance
within the .insurance namespace, the first prerequisite is the need to verify the authenticity of the request. Some ICANN reporting mechanisms have been subject to
misuse by third parties in the past. Therefore, FRS will have to undertake a preliminary analysis to verify if a complaint has been received from a trusted⁄verified source or independently identified by FRS. In making this initial determination, FRS will rely upon internal FRS, as well as potential consultation with its backend provider Verisign and other external consultants.

While FRS does not anticipate a high volume of complaints due to the restrictive nature of the namespace, FRS proposes the following prioritizing for verification of processed complaints. Complaints from legitimate law enforcement agencies will be processed within 24 hours, although FRS will strive for a shorter window of response, e.g., 6 to 12 hours. As FRS fosters and develops deeper working relationships with governmental and law enforcement officials this shorter response window should be achievable. The second highest prioritization will be assigned to complaints involving third-party reports involving security, stability, or criminal activity. FRS will use commercially reasonable efforts to verify these complaints within one business day. The lowest prioritization for investigation will be assigned to complaints of non-compliance that to not rise to a level of security, stability or criminal activity. FRS will use commercially reasonable efforts to verify these complaints within five business
days.

TIMELY INVESTIGATION: FRS will prioritize all investigates in a similar order as identified in the preceding section: law enforcement complaints; third party security,
stability or criminal complaints; and third party non-security, non-stability, or non-criminal complaints. While FRS staffing levels are suitable to handle expected
volumes of complaints and the associated verification⁄investigation⁄remediation⁄follow-up tasks, FRS will have qualified external consultants on call to supplement FRS staffing needs to meet the timelines set forth herein. While FRS will use commercially reasonable efforts to timely investigate verified complaints, it is difficult to set
arbitrary timelines for resolution as some issues can require in-depth investigation. Notwithstanding these facts, FRS commits to provide a preliminary investigation status update within 24 hours following verification in connection with complaints from legitimate law enforcement. FRS will seek to establish a close and open dialog with law enforcement during these types of investigations and will always respond within 24 hours during the pendency of the investigation. In connection with third-party complaints involving security, stability, or criminal activity, FRS will use commercially reasonable efforts to provide a preliminary investigation status update within one business day of verification, and a similar one business day time frame for any subsequent follow-up regarding the investigation. In connection with third-party complaints that do not involve security, stability or criminal activity, FRS will use commercially reasonable efforts to provide a preliminary investigation status update within five business days of verification, and a similar five business day time frame for any subsequent follow-upregarding the investigation.

TIMELY REMEDIATION: While FRS is fully committed to using all available resources to resolve abusive and⁄or non-compliant activity within the .insurance namespace, including but not limited to domain name suspension and or cancelation, FRS has developed the following remediation plan. In connection with credible threats which
significantly impact or threaten the security, stability of the Internet or the .insurance namespace, or which is causing direct and material harm to others, FRS’ default option will be the suspension of the domain name within twelve hours of completing a preliminary investigation. The only exception would be unless FRS after consulting with its team of legal, technical and policy advisories (both internal and external) decided that there was a compelling reason not to suspend the domain name. If such a determination is made by FRS, this decision and an explanation will be provided to either law enforcement or the third party.

In all other complaints not involving security, stability or criminal activity, FRS will seek to resolve the matter through an escalated notification process: email, telephone, certified mail. While FRS is fully committed to ensuring that all registrant comply with the contractual requirements set forth in their domain name registrant
agreement, FRS wants to avoid prematurely suspending and⁄or cancelling a domain name that may have a larger impact of a much larger community of users. Similar to above, FRS will consult with its team of legal, technical and policy advisories (both internal and external) before deciding to suspend⁄cancel a domain name. During the pendency of this remediation, FRS will remain in dialog with the original third-party complainant.

TIMELY FOLLOW-UP: FRS does not view its commitment to the community as stopping just after a threat has been neutralized. Instead, FRS will follow-up in
connection with each complaint to either re-activate a domain name after the abusive⁄non-compliant activity has been resolved, or help educate the registrant as to how
to avoid future remediation actions.

Listed below are details on how FRS will interact with its designated backend registry service provider Verisign to implement the policy and procedures set forth above.

Suspension processes conducted by backend registry services provider (see Attachment 28-3). In the case of domain name abuse, FRS will determine whether to take down the subject domain name. Verisign, FRS’ selected backend registry services provider, will follow the following auditable processes to comply with the suspension request.

Verisign Suspension Notification. FRS 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 FRS, 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 FRS with the following information:
- Threat domain name
- Registry incident number
- Verisign case number
- Error reason

Registrar Notification. Once Verisign has performed the domain name suspension, and upon FRS request, Verisign notifies the registrar of the suspension. Registrar notification includes the following information:
- Threat domain name
- Registry incident number
- Verisign case number
- Classification of type of domain name abuse
- Evidence of abuse
- Anti-abuse contact name and number
- Suspension status
- Date⁄time of domain name suspension

Registrant Notification. Once Verisign has performed the domain name suspension, and upon FRS request, Verisign notifies the registrant of the suspension. Registrant notification includes the following information:
- Threat domain name
- Registry incident number
- Verisign case number
- Classification of type of domain name abuse
- Evidence of abuse
- Registrar anti-abuse contact name and number

Upon FRS 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:
- serverUpdateProhibited
- serverDeleteProhibited
- serverTransferProhibited
- serverHold

Suspension Acknowledgement. Verisign notifies FRS that the suspension has been completed. Acknowledgement of the suspension includes the following information:
- Threat domain name
- Registry incident number
- Verisign case number
- Case number
- Domain name
- FRS abuse contact name and number, or registrar abuse contact name and number
- Suspension status


4. WHEN EXECUTED IN ACCORDANCE WITH THE REGISTRY AGREEMENT, PLANS WILL RESULT IN COMPLIANCE WITH CONTRACTUAL REQUIREMENTS

FRS believes that the proposed tapestry of protections that involve both proactive and reactive mechanism will provide an unmatched level of security and anti-abuse activity within the .insurance gTLD. These mechanisms will be hard coded into both the Registry-Registrar Agreement as well as the Registrant Registration Agreement.


5. TECHNICAL PLAN SCOPE⁄SCALE THAT IS CONSISTENT WITH THE OVERALL BUSINESS APPROACH AND PLANNED SIZE OF THE REGISTRY

Scope⁄Scale Consistency

FRS is confident that the distribution of validation⁄verification services between itself and .insurance accredited Registrars will provide the level of protection needed to
minimize potential abuse activity within the gTLD given the relatively small scale of FRS full-time staff and external consultants.

Scope⁄Scale Consistency Specific to Backend Registry Activities

Verisign, FRS’ 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 .insurance 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 FRS 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.