Application number: 1-1035-75923 for fTLD Registry Services LLC

fTLD Registry Services LLC

+1 202 589 2532

+1 202 628 2492

Mr. Craig Scott Schwartz

General Manager, Registry Programs

+1 202 589 2532

+1 202 628 2492

craig.schwartz@fsround.org

Mr. Doug Johnson

Vice President, Risk Managment Policy

+1 202 663 5059

djohnson@aba.com

Limited Liability Company

Jurisdictional law is the State of Delaware.

Not Available

Craig Scott Schwartz
Director
Doug Johnson
Director
Paul Nicholas Smocer
Director
Samuel Carl Lisker
Director

Corporation for American Banking, LLC
Not Applicable
The Financial Services Roundtable
Not Applicable

insurance

Not Available

fTLD Registry Services, LLC forsees no known operational or rendering problems concerning .insurance as it is an ASCII string.

fTLD Registry Services, LLC (FRS) is submitting this application on behalf of the U.S. insurance community to ensure that the .insurance gTLD will serve as a trusted, hierarchical, and intuitive namespace for this community and the consumers it serves. All registrants within this gTLD will be vetted prior to registration to ensure their identity and their commitment to industry best standards developed by FRS before they are able to register in the .insurance gTLD. In addition, the registry will employ a network of active and passive safeguards in the operation of the registry to make certain these registrants continue to abide by the terms and conditions set forth in the registration agreement. The .insurance gTLD will also provide the industry with an innovative space to explore cutting edge business opportunities and mechanisms to better serve consumers using the Internet. Over time, one of the goals of this gTLD is to become the consumer’s choice for information about the insurance industry.

As awareness and use of the .insurance gTLD increases over time, Internet users will come to learn, understand and trust that websites ending in .insurance are operated by legitimate members of the insurance community. FRS’ implementation of stringent registration restrictions, enhanced security standards created by the financial services industry, content⁄use requirements and rigid enforcement will contribute to the security, stability, and resiliency of the .insurance gTLD, ultimately resulting in increased consumer trust and confidence in the gTLD. 

The Internet represents a critical component of the trade and commerce engine and the .insurance gTLD is expected to address some of the online security challenges faced by the insurance industry. Regrettably, the industry’s reputation has been marred by criminal and fraudulent activities that undermine consumer trust and enforcement agency confidence. Internet users, many of whom are consumers, are increasingly challenged by opportunists and charlatans who pretend to be legitimate online businesses. This is a particular concern of the insurance industry because their consumers are asked to entrust sensitive financial information to external third parties. Rogue online operators engage in cybersquatting and ʺphishingʺ attacks that often involve false websites designed to mimic legitimate businesses, including insurance companies and⁄or agents. 

Due to the strict vetting process that will occur before an .insurance domain is awarded, the number of phishing attacks will be greatly reduced in the .insurance gTLD. FRS will work with the insurance industry to create a strategy that significantly reduces the risk of insurance-related phishing and other malicious activities that are perpetrated on the Internet.

Registrations within the community may initially be made by the following businesses, individuals or organizations:
- Licensed insurance companies regulated by a government entity
- Licensed insurance agents and brokers regulated by a government entity 
- Associations whose members include licensed insurance companies, agents or brokers (if approved by the FRS Board)
 -Organizations that are majority controlled by insurance companies (if approved by the FRS Board)
- Entities whose operations are principally dedicated to serving insurance companies (if approved by the FRS Board) 
- Specialized organizations (e.g., research or risk coordination) (if approved by the FRS Board)

Why FRS?
In 2008, the American Bankers Association (ABA) and The Financial Services Roundtable’s (Roundtable) executives and members allocated resources to work in conjunction with member committees to examine the potential impact the Internet Corporation for Assigned Names and Numbers’ (ICANN) new gTLD program could have on the financial services industry and to make recommendations regarding next steps. Marked concern arose regarding the expansion program, especially in light of the resources and expenditures currently dedicated to stem existing online abuses. 
During the last four years, the ABA and the Roundtable united to play an active role in ICANN’s development of its new gTLD program. Both organizations engaged with ICANN to voice community concerns about the program, and were successful in raising awareness about the need to protect brands and intellectual property. In addition, the ABA and Roundtable were successful with their request to ICANN for a modification to the Security Policy question in the Applicant Guidebook and it now includes that gTLDs with unique trust implications, such as those that are financial services-oriented, are expected to deploy appropriate levels of security.  However, absent assurances that .insurance, .bank and other financial gTLDs would be protected, the Executive Committee and Board of each respective organization voted and authorized staff to take all actions necessary to secure financial gTLDs, specifically, .insurance and .bank. 

At the behest and approval of both the ABA and the Roundtable members and Boards, FRS was formed in 2011 for the explicit purpose of applying for and operating financial services-related gTLDs. In addition, FRS seeks to protect the brand space, improve the protection available for a more secure Internet ecosystem, collaborate on delivering more innovative and secure products and services, and zealously advocate for the interests of the insurance community with ICANN. 

The Operating Managers of FRS:
Founded in 1875, the American Bankers Association represents banks of all sizes and charters and is the voice for the U.S. banking industry’s $13 trillion and 2 million employees. ABA marshals the talent, energy and perspectives of its members to bring about positive change for the banking industry. In conjunction with the financial services community, the ABA has developed and continues to own a number of innovative systems that support the financial services industry. The ABA Routing Number (RTN) system was developed in 1910 and serves to identify the specific financial institution responsible for the payment of a negotiable instrument. In 1964, the ABA organized the Committee on Uniform Security Identification Procedures (CUSIP), for the purpose of developing an identifier for financial instruments. ABA is also an active member of the International Banking Federation, formed in March 2004 to represent the combined views of a group of national banking associations. Collectively, the countries represented by the Federation reach more than 18,000 banks with 275,000 branches. 

The American Bankers Insurance Association (ABIA), a subsidiary of the ABA, is the leading bank-insurance industry trade association in the U.S. ABIA members include banking institutions of all asset sizes, including insurance companies, service providers, consultants, and associations. 

The first of the Roundtableʹs predecessor organizations, the Association of Reserve City Bankers, was formed in 1912. The Bank Holding Company Act of 1956 led to the 1958 formation of another independent organization, the Association of Registered Bank Holding Companies. The two organizations merged in July 1993, and became The Bankers Roundtable in October 1993. In early 2000, the first members from the securities, investment, and insurance sectors joined their banking brethren as founding members of The Financial Services Roundtable. Today, the Roundtable represents 100 of the largest integrated financial services companies providing insurance, banking, and investment products and services to the American consumer. 

FRS has actively engaged several insurance-related trade associations to inform them of FRS’ activities and what it could mean for their members. As of April 10, 2012, FRS’ endorsers of the .insurance initiative include The Allstate Corporation, American Bankers Insurance Association, Nationwide, Prudential Financial Inc., and State Farm Insurance Companies.

The .insurance gTLD will serve as a trusted destination on the Internet for insurers, insurance services providers, consumers and Internet users. The .insurance gTLD will seek to reach insurance professionals, their employees and partners while modeling a template of trust for online commercial interactions. The pre-registration and screening conducted by FRS will serve the industry by allowing it to congregate under one umbrella gTLD. This presents consumers with clear choices in an environment that will encourage .insurance registrants to be innovative and provide maximum value to consumers in their online experience, while providing significant competition to existing gTLDs.

Additionally, the proposed .insurance gTLD will offer the following benefits: 
- Provide a trusted online marketplace for consumers seeking to access insurance products and services; 
- Provide FRS and its community members with memorable Internet addresses and improve navigation to products, services, advertising campaigns, public interest content, public awareness initiatives, etc.;
- Protect the namespace for the benefit of institutions, consumers and the overall insurance community;
- Provide a variety of high value-added services through its backend registry services provider; and
- Create an opportunity to design innovative online products and services for the insurance industry and its consumers.

18(b)(i) What is the goal of your proposed gTLD in terms of areas of specialty, service levels, of reputation?

FRS was founded by organizations that hold a leadership role in the U.S. insurance industry. FRS’ Board and Advisory Board will be composed of insurers and insurance associations and therefore it is uniquely situated to understand the needs and goals of registrants in the insurance industry. FRS’ goal is that there will be no confusion for Internet users when they encounter a .insurance website. Every .insurance registrant will be a legitimate member of the insurance community, committed to a trustworthy commercial transaction experience for its clients and consumers. Registrants will work with FRS and adhere to the strictest terms of service and security standards, generated specifically by the global financial services community for this undertaking. 

18(b)(ii) What do you anticipate your proposed gTLD will add to the current space, in terms of competition, differentiation, or innovation?

FRS’ primary driving factor is to provide a vetted and therefore, more secure online environment for businesses and consumers to interact with the insurance community. The success of the gTLD will not be measured by the number of registrants, but rather by the level of institutional and consumer recognition and trust placed in the .insurance gTLD. Using this benchmark, FRS will strive to build recognition and trust that rises to a level meeting or exceeding that found in the .edu and .gov gTLDs. 

As noted above, FRS is committed to serving the insurance community as it increasingly relies upon emerging technologies to securely deliver information between institutions and about insurance products and services to its consumers. The .insurance gTLD has the potential to serve as the cornerstone of this type of online strategy for the industry. FRS seeks to become a trusted source for inter-institution exchanges and transactions and a platform for more secure, consumer-facing insurance activities, including the purchase of insurance products and services.

In addition to the education and outreach initiative discussed above, FRS is keen to continue its work with ICANN and the broader Internet community in promoting security controls within gTLDs that require enhanced security measures, such as financial gTLDs. Its most recent effort in this area was the creation of security requirements formally proposed to the ICANN Board in December 2011 by the joint ABA and BITS (the technology policy division of the Roundtable) Security Standards Working Group. Following its submission to ICANN, the requirements have since been referenced in question 30 of the Applicant Guidebook. FRS will contractually incorporate these requirements into both its Registry-Registrar Agreement (RRA) and the end Registrant Registration Agreement to ensure that it has the legal means to enforce these obligations.

The creation of the .insurance gTLD will provide the insurance community with opportunities to explore and create new products and services that support the community in addressing the Internet based issues and concerns referenced above. It will also provide the insurance community with a space to innovate, improve current insurance services, and address the increasing consumer demand for faster and more convenient transactions. 

FRS plans for its operation of the .insurance gTLD to provide significant benefits to the larger Internet community in the following ways:

1. Trust
The .insurance gTLD will allow the Internet user, before he or she even clicks on a search engine result, to know that the site belongs to a trusted member of the insurance community. 

Among the results that would arise in a typical search of existing gTLDs are fraudulent businesses that intend to put Internet users, especially consumers and their personally identifiable information, including, but not limited to, financial data, at serious risk. Often, these rogue online operators register domains that look similar to legitimate domains to intentionally mislead users, resulting in increased costs to the industry and consumers. FRS’ ultimate goal on behalf of the industry is that the .insurance gTLD will reduce the efficacy of such attacks, as users on a bona fide .insurance site would know that their information was safe with a vetted insurance provider.
 
2. Ease of search
As the amount of information available online continues to grow, it will become increasingly more difficult for consumers to choose which websites to visit for their desired insurance services and products. However, consumers will know that Internet search results listing websites ending in .insurance belong to legitimate members of the insurance community. Will a typical Internet search produce legitimate insurance providers via the Internet? Yes. But, will the individual performing the search have the tools at hand to determine which of the results are trustworthy and legitimate? Not necessarily, but with .insurance they will. 

3. Vetting and Oversight
The reason Internet users will be able to trust a .insurance domain is because FRS will aggressively govern both the issuance and continued use of a second-level .insurance domain. More information on the vetting and oversight can be found in 18(b)(iv) below.

18(b)(iii) What goals does your proposed gTLD have in terms of user experience?

FRS will ensure that the .insurance gTLD will create an enhanced user experience both for registrants and Internet users. FRS’ goal is to operate the .insurance gTLD in a manner that instills trust and confidence in the domain names and websites associated with the gTLD. For users this means a small, specialized, highly controlled environment, free from much of the abusive behaviors found in existing gTLDs. 

1. Registrants
The number of .insurance registrants will be relatively small. As such, registrants will receive higher levels of customer service than can reasonably be expected in existing gTLDs. Once granted a .insurance domain, registrants will benefit through the domain nameʹs positive brand identity and consumer trust. Likewise, .insurance’s reputation will benefit from the upstanding efforts of second-level domain operators seeking to maintain their registration status.

2. Internet users
As stated above in 18(b)(ii), the restricted and manageable size of the .insurance community will provide both a trusted and secure online experience. The controls managing the community will foster competition among registrants to compete on a user-experience basis for Internet users. 

18(b)(iv) Provide a complete description of the applicantʹs intended registration policies in support of the goals listed above.

To ensure a trusted environment, FRS will restrict registrations to a select group and will limit the types of activities that may take place within the gTLD with a series of policies meant to prevent and address negative behavior. These policies include:

Registrations within the community may initially be made by the following for-profit and not-for-profit businesses, individuals or organizations: 
- Licensed insurance companies regulated by a government entity
- Licensed insurance agents and brokers regulated by a government entity
- Associations whose members include licensed insurance companies, agents or brokers (if approved by the FRS Board)
- Organizations that are controlled by insurance companies (if approved by the FRS Board)
- Entities whose operations are dedicated to serving insurance companies (if approved by the FRS Board)
- Specialized organizations (e.g., research or risk coordination) (if approved by the FRS Board)

In working on behalf of the insurance industry, FRS understands its responsibilities to the industry. Because of the proposed insurance-service activities that will occur within the .insurance namespace, it is essential that registrations only be permitted by verified members of the insurance community. In addition to validating the eligibility of the registrant, the domain name to be registered must comply with appropriate name selection and use requirements.

To ensure strict compliance with these policies, FRS will develop and implement a Registrant Eligibility Evaluation Process. This process will require .insurance accredited registrars to collect registrant information that will be used by FRS, or its designated third party service provider, to validate that the registrant is a member of the insurance community. These requirements will be incorporated into FRS’ Registry-Registrar Agreement (RRA).

As part of the registration process, potential registrants must provide its registrar with the following information:
- Full legal name
- Business address
- Professional title of representative of the administrative contact of the potential applicant 
- Business name
- Point of contact within the business who can verify their representation of the business
- Phone
- Email
- Another proof of identity, necessary to establish that the registrant is an eligible member of the appropriate .insurance gTLD community
- For insurance companies, the state regulatory authority issuing its charter
- For agents and brokers, the state licensing agency
- For organizations that are majority controlled by insurance companies (if approved by the FRS Board), list of and proof of its owner(s)
- For entities whose operations are principally dedicated to serving insurance companies (if approved by the FRS Board), corporate operating agreement or like document(s) as determined necessary to validate alignment with the goals of the community
- For specialized organizations (e.g., research or risk coordination) (if approved by the FRS Board), a copy of the corporate operating agreement if for-profit or the mission statement if non-profit (or like document(s) as determined necessary to validate alignment with the goals of the community)

Applicants who meet the eligibility requirements and have been validated as legitimate members of the community will then be able to register their domains in .insurance. 

Domain names that pass the vetting process will enter a 5-day Add Grace Period (AGP), or Pending Create, before becoming valid. Applicants whose domain name fails the vetting process will be notified with reasons for denial and procedures for appeal. Any applicant who is rejected for either a non-eligibility criteria or use of domain evaluation can appeal the validator’s decision to FRS. 

FRS will audit approved registrants and their strings to ensure compliance with all applicable eligibility and use requirements.

Domains initially registered in the .insurance gTLD must correspond to a trademark, trade name or other service mark owned by the registrant. Initially, all other registrations (e.g., geographic, generic, etc.) will not be allowed. FRS will reserve a set of generic domain names prior to launch. These reserved domain names will either be used by FRS in its capacity as Registry Operator for the management, operation and purpose of the gTLD, or they will be equitably allocated to members of the community. The subset of domain names reserved for FRS’ use is necessary to create a trusted, hierarchical, and intuitive framework for the .insurance namespace to facilitate the ease by which consumers can navigate the gTLD. 

Although these reserved words will be commonly used words and phrases and⁄or geographic terms, FRS will provide an enhanced Rights Protection Mechanism that will provide trademark owners with an avenue to challenge the reservation and potential use of these domain names. This challenge process will be modeled after the highly successful dotAsia Pioneering Program.

18(b)(v) Will your proposed gTLD impose any measures for protecting the privacy or confidential information of registrants or users? If so, please describe any such measures. 

The .insurance gTLD will be governed by strict guidelines and policies regarding issues of privacy and the protection of confidential registrant information. The policies will be transparent and rigorous. Each level of the gTLD (registry, registrar and registry services provider) will have privacy and security policies in place to protect against unauthorized access to confidential information.

Privacy and security will be key elements of the .insurance Acceptable Use Policy (AUP), which will govern how a registrant may use its registered name. Draft AUP language specifically addresses privacy by noting that a registrant may not use a .insurance domain for any activity that ʺviolates the privacy or publicity rights of another member of the .insurance gTLD community or any other person or entity, or breaches any duty of confidentiality that you owe to another member of the .insurance gTLD community or any other person or entity.ʺ 

Members of the .insurance gTLD community operate under the highest standards of privacy and protection of personally identifiable information and financial data. Such protection is an essential component of the insurance industry and a legal necessity for any Internet enterprise. State insurance regulators and the National Association of Insurance Commissioners support strong laws and regulations that protect the privacy of individual consumer information. Every state has adopted comprehensive privacy laws to protect the extensive personal information collected by insurers to underwrite and administer insurance policies. Insurance regulators also support efforts to mandate fair treatment and notification to consumers when their private information is improperly disclosed to third parties, especially where such unauthorized disclosures may result in identity theft. It is in the best interest of an insurance provider or affiliate to continue to provide maximum privacy protections for consumers, and this will continue to be their responsibility in operating a .insurance gTLD. FRS will implement the latest online technology (e.g., DNSSEC and multi-factor authentication) and services to help ensure the .insurance domain is synonymous with trust. These steps will align with actions instituted by .insurance registrants, working in lockstep with FRS. This is a manifestation of the larger goal of .insurance, that of a trusted source of safe online transactions, as stipulated in 18(a).

The protection of privacy and confidential data is of paramount importance, especially in an industry as highly regulated as insurance services. Not only will the registry have its own set of measures, but each individual institution or registrant will be required to remain compliant with existing laws and regulations in place regarding privacy and the protection of customer data. FRS will accomplish this, in part, through the inclusion of contractual language in its RRA that is modeled after similar language in Registry Agreements of existing ICANN gTLD registry operators. Specifically, some of this language will include the following: 
- Registry Operator shall notify the Registrar of the purposes for which Personal Data submitted to Registry Operation by Registrar is collected, the intended recipients (or categories of recipients) of such Personal Data, and the mechanism for access to and correction of such Personal Data. 
- Registry Operator shall take reasonable steps to protect Personal Data from loss, misuse, unauthorized disclosure, alteration or destruction. 
- Registry Operator shall not use or authorize the use of Personal Data in a way that is incompatible with the notice provided to registrars. 
- Registry Operator may, from time to time, use the demographic data collected for statistical analysis, provided that this analysis will not disclose individual Personal Data and provided that such use is compatible with the notice provided to registrars regarding the purpose and procedures for such use.

The draft AUP informs registrants that FRS maintains ʺcomplete enforcement rights over registrant’s use of their .insurance domain name. If registrant violates this AUP, registrant will be subject to a rapid domain name compliance action, be in material breach of the Agreement, and along with all other rights and remedies under this Agreement with respect to such a breach, FRS reserves the right to revoke, suspend, terminate, cancel or otherwise modify registrant’s rights to the domain name.ʺ

On a regular basis, FRS will audit domain names, or require an attestation by second-level domain holders, registered in the .insurance gTLD space to ensure compliance with all eligibility and use criteria. If a violation is discovered, an investigation will begin immediately to rectify the violation. If an applicant chooses to appeal, FRS will review the appeal to determine if there is any material change to the action or activity. FRS will retain the right to assign the dispute to an ombudsman if necessary.

A more detailed discussion of FRS’ privacy policies, specifically steps to avoid unauthorized access to sensitive information, can be found in responses to question 30.

Describe whether and in what ways outreach and communications will help to achieve your projected benefits.

Outreach and communications with the insurance services community will be critical to the success of this project and has already begun over the past four years by FRS’ founding members. FRS’ founding members have discussed possible impacts to the industry with domestic insurance associations as well as ICANN’s Governmental Advisory Committee (GAC). Current conversations with and among insurance companies and members of the industry include ways to reach the insurance community and build an infrastructure that includes all members of the insurance services community. Ultimately, a communications strategy and plan will be implemented by FRS and its Board to guide its efforts. Advisory groups and committees will also be consulted to ensure continued alignment. 

FRS and its Board will utilize all existing channels of communication to increase the awareness of the value and merit of the .insurance gTLD. Finally, the gTLD will be promoted by registrants themselves. Insurance providers will have an incentive to direct consumers to the .insurance sites they operate, and thus will promote their second-level domains containing .insurance throughout existing media channels. 

The adoption of rules and elimination of social costs for the insurance community are at the core of FRS’ strategy. Its proposed operating rules will provide the insurance community, businesses and consumers with a trusted online environment, and in turn minimize operating and social costs. Registrations for domains in the .insurance gTLD will be reserved exclusively for those members of the industry who meet the previously described eligibility criteria. This, coupled with a stringent name selection policy, will eliminate the need for an insurance provider company trademark and for brand owners to defensively register second-level domains in the .insurance gTLD. The goal is that this verified ecosystem will be poised to offer consumers with a place to find trusted sources of insurance information, products and services with a substantially lower risk of fraud and⁄or scams. In addition, FRS’ processes are designed to protect the trademark rights of insurance companies and their affiliates. These strategies will serve to minimize financial costs both within the insurance industry and the Internet community as a whole.

18(c)(i) How will multiple applications for a particular domain name be resolved, for example, by auction or on a first-come⁄first-serve basis?

As detailed in FRS’ response to question 29, FRS suggests running two different Sunrise periods followed by a Real Time Registration Period (i.e., first come, first served approach during general availability) for the entire insurance community. Due to the limited and restrictive nature of the .insurance namespace, FRS does not envision many significant issues regarding multiple insurance community members vying for the same domain name. 

However, when there are multiple registrations for a domain name during either the Founder’s Sunrise (the first sunrise for members of FRS’ Founder’s Program, which will operate on a first come, first served basis) or General Sunrise for the broader community, a three-step process will determine which registrant receives the domain. First, within the guidelines set forth by ICANN for protecting trademark⁄registered name rights, first preference will be given to the applicant with proven rights to the name. Second, if all contending registrants have an equal right, all will be asked to submit a proposed use plan and application fee to demonstrate how the domain name will be used. Emphasis will be placed on developing and deploying the domain. FRS may employ an independent arbiter to review and make the initial recommendation to FRS’ Board of Directors regarding awarding the domain. Third, in the event that there is not a clear cut winner after these two steps are undertaken, the parties will proceed to a mechanism of last resort: auction.

After the Sunrise periods, FRS plans to move to a Real Time Registration Period where members of the .insurance gTLD community can register strings that comply with registration policies on a first come, first served basis. 

18(c)(ii) Explain any cost benefits for registrants you intend to implement (e.g., advantageous pricing, introductory discounts, bulk registration discounts).

FRS has proposed a Founder’s Sunrise Program that would allow members of the insurance community that have financially supported this initiative, to register their domain names in the .insurance gTLD before the General Sunrise Period. Potential registrants participating in the Founder’s Program are eligible for discounted registrations. The registration and use of these domain names would be contingent upon the registration restrictions and eligibility requirements. At this time, FRS does not anticipate any other price discount programs, but reserves the right to revisit this question in conjunction with its Board of Directors and Advisory Board. 

Except for the FRS Founder’s discount noted in this section, FRS does not envision any pricing, introductory discounts, or bulk registration discounts because these marketing⁄commercial initiatives are inconsistent with the mission and purpose of the .insurance gTLD as a trusted online source identifier. 

18(c)(iii) Note that the Registry Agreement requires that registrars be offered the option to obtain initial domain name registrations for periods of one to ten years at the discretion of the registrar, but no greater than ten years. Additionally, the Registry Agreement requires advance written notice of price increases. Do you intend to make contractual commitments to registrants regarding the magnitude of price escalation? If so, please describe your plans.

FRS is committed to providing domain name registration services in accordance with the periods set forth in the Registry Agreement and providing domain name registrants with pricing predictability. FRS further acknowledges that the current template Registry Agreement requires that the Registry Operator “shall offer registrars the option to obtain registration periods for one to ten years at the discretion of the registrar.” If price increases are necessary, FRS intends to follow all necessary guidelines in terms of announcing them to registrars.

In connection with any premium domain names program, FRS will set pricing for premium domain names, as well as renewal terms, before offering these domains for registration. However, in connection with this premium class of domain names, there may be additional requirements necessary for registration. All additional terms necessary to legally bind registrants in connection with a registration of this type would be provided to registrants in advance. 

Yes

The U.S. insurance community is a clearly delineated industry that has evolved over hundreds of years into a
critical commercial enterprise within the global economy. While fTLD Registry Services, LLC’s (FRS) members are
based and regulated in the United States, the growth, reach and impact of the larger insurance services community is
global. Due to the common characteristics that define the insurance community, it is a logical candidate for
identification as a community under the Internet Corporation for Assigned Names and Numbers’ (ICANN) guidelines.
Further, since FRS was requested by members of this well-defined community to apply for and operate the .insurance
gTLD for the community’s benefit, FRS’ .insurance gTLD is well positioned to serve the community and apply a
straightforward approach to approve its potential registrants.
The community is defined under the subheads below.
• How the community is delineated from Internet users generally. Such descriptions may include, but are not limited
to, the following: membership, registration, or licensing processes, operation in a particular industry, use of a
language.
The insurance community is composed of a specialized group of individuals and commercial entities including, but not limited to corporations dedicated to providing insurance services. Nearly all Internet users purchase products or
participate in programs through this community of providers.
The regulatory framework for the U.S. insurance industry has evolved over the past two centuries with a trend toward
consistent regulations among states with increased federal oversight. Each insurance company is subject to all
applicable state regulations within the states it chooses to operate and must remain in compliance with them in
order to maintain the authority to offer insurance products in that state. The U.S. Supreme Court’s ruling in 1944
in U.S. v. South-Eastern Underwriters Association made the insurance industry subject to the Commerce Clause of the U.S. Constitution. Since then, Federal regulation of the community has grown.
This framework is critical to understanding the insurance community. The existing framework provides clear lines for
defining the community. Further, FRS’ knowledge of and relationships within the insurance services industry, as
outlined below, will support it in providing a successful mechanism to approve solely those entities that belong
within this community. The .insurance gTLD will be built to accommodate any shifts in the insurance community due to changes in regulations or laws. Only, those entities that maintain .insurance gTLD registration restrictions will be
eligible to join. Those that leave the insurance community and no longer meet .insurance gTLD membership standards will be subject to domain name forfeiture if they are unable to remain in good standing.
• How the community is structured and organized. For a community consisting of an alliance of groups, details about
the constituent parts are required.
There are many complexities in the insurance industry. Among them are the structure and organization of the
industry, which depends largely upon the size of the company and the types of insurance the company has the state
authority to offer. Major U.S. insurance companies often reside within a holding company structure typically owned
by multiple admitted and surplus insurers, and at times also own excess insurers and reinsurers. Insurance holding
companies also differ as to how various business functions are divided among subsidiaries or outsourced to third
parties. In addition to the size of insurance companies, the community consists of two major components – the
insurance companies themselves and the agents and brokers (also known in the industry as “producers”) who interface with consumers to sell insurance products and services. Some of these agents and brokers are independent and sell the insurance products of multiple insurance companies and some are affiliates of a single insurance company and sell only the products of that agency. Agents and brokers must be state licensed in order to sell product and, therefore, represent a readily identifiable and distinguishable group.
Type of insurance policy is another way the community is organized. There are many variations of insurance on the
market. As a rule, they can be categorized under the following types:
For individuals, the market includes Vehicle Insurance (e.g., automobile, motorcycle, recreational vehicle, and boat
insurance), Property Insurance (e.g., homeowners, renters, personal umbrella liability, and flood insurance), Life
Insurance (e.g., term life, whole life, and universal life insurance), and Specialty Insurance (e.g., Accident
Medical, General Liability, Travel Services, Farm Insurance, Identity Theft Coverage).
For businesses, the market includes General Business Coverage (e.g., business owners policy, general liability,
crime insurance, commercial auto, business property, surety and other bonds, business interruption), Employee
Benefits (e.g., Group benefit offerings, employee retention, participant accident medical, retirement plans,
business travel insurance) and Agribusiness (e.g., farm and ranch insurance, commercial agribusiness coverage,
insurance risk management).
• When the community was established, including the date(s) of formal organization, if any, as well as a description
of community activities to date.
The history of the insurance industry in the United States goes back nearly three hundred (300) years to 1732 when
an insurance company that underwrote fire insurance was founded in Charleston, South Carolina. The evolution of the
industry and its regulatory framework is articulated above. Originally, the insurance community was dominated by
small, local, single-line mutual companies and member societies. However, a significant change in the community
occurred in the 1950s, when laws began to permit multi-line charters. Increasingly, the community began to feature
multi-line, multi-state and even multi-national insurance conglomerates and holding companies.
• The current estimated size of the community, both as to membership and geographic extent.
The .insurance gTLD will be operated by FRS on behalf of the U.S. insurance industry. This includes 3,750 companies (according to a 2010 report by the National Association of Insurance Commissioners) and 2,250,000 agents and brokers (according to a 2010 report by the National Insurance Producer Registry). It also includes over 233 state insurance associations and 52 other types of insurance-related associations. The 2010 statistics were the most currently available information with FRS prepared its application.

FRS was recently created by two established financial services associations - the American Bankers Association (ABA) and The Financial Services Roundtable (Roundtable). Between them, they have over 200 years of history representing the financial services industry in the United States. FRS was formed for the explicit purpose of applying for and operating financial services-related gTLDs including .insurance.
As of April 10, 2012, endorsers of the FRS .insurance initiative include the American Bankers Insurance Association,
The Allstate Corporation, Nationwide, Prudential Financial, Inc., and State Farm Insurance Companies.
The first of the Roundtableʹs predecessor organizations, the Association of Reserve City Bankers, was formed in
1912. The Bank Holding Company Act of 1956 led to the 1958 formation of another independent organization, the
Association of Registered Bank Holding Companies. The two organizations merged in July 1993, and became The Bankers Roundtable in October 1993. In early 2000, the first members from the securities, investment, and insurance sectors joined their banking brethren as founding members of The Financial Services Roundtable. Today, the Roundtable represents 100 of the largest integrated financial services companies providing insurance, banking, and investment products and services to the American consumer.
Founded in 1875, the ABA represents banks of all sizes and charters and is the voice for the nationʹs $13 trillion
banking industry and its 2 million employees. ABA marshals the talent, energy and perspectives of its members to
bring about positive change for the financial services community. Through an effective collaboration between ABA
members and staff, it combines experience and insights, in-depth expertise, unmatched resources and extensive
products to make its members more successful. Examples include the ABA’s ownership and⁄or support of several
existing financial services standards and businesses, including CUSIP and routing number. Further, ABA currently
serves as registrar of several ISO standards, including, ISO 7812.
The American Bankers Insurance Association (ABIA), a subsidiary of the ABA, is the leading bank-insurance industry
trade association in the U.S. ABIA members include banking institutions of all asset sizes, including insurance
companies, service providers, consultants, and associations. The membership makeup is approximately 55% banking institutions and 45% all other providers. A study by Michael White Associates for ABIA found that in 2009, U.S. bank holding companies generated total insurance revenue of a record $15.08 billion, led by insurance operations at
Citigroup, Inc., Bank of America Corporation and Wells Fargo & Company.
Activities of the ABA, ABIA, Roundtable, and their members include, but are not limited to:
- Supporting policies and activities that allow financial institutions to sustain the integrity and versatility of
the payments system to meet customer needs and preferences efficiently and safely;
- Supporting efforts to combat the continuous problem of identity theft and the means to identify and address
emerging threats to consumers;
- Supporting efforts to protect the nonpublic, personal information privacy of financial services customers;
- Facilitating legitimate electronic communications between financial institutions and their customers and other
businesses; and
- Educating employees of the financial services community on the latest industry regulations and sound practices.
• Relations to the community and its constituent parts⁄groups.
The ABA’s and Roundtable’s members include representatives in the U.S. insurance community. These organizations represent the community’s interests in Washington and around the globe. As such, these organizations maintain relationships, both formal and informal, with all sectors of the insurance community, through conferences, published research, best-practices projects, and representation on policy matters. The hybrid nature of ABA and the
Roundtable--insurance organizations partnered with other financial institutions--perfectly reflects the U.S.
insurance industry, as explained above in 20(a).
The .insurance gTLD will serve the needs of, and provide benefits to, the insurance industry that does business in
the U.S. Members of the community are clearly defined by law and include, licensed insurance companies regulated by a government entity, licensed insurance agents and brokers regulated by a government entity, associations whose
members include licensed insurance companies, agents or brokers (if approved by the FRS Board), organizations that are majority controlled by insurance companies (if approved by the FRS Board), entities whose operations are
principally dedicated to serving insurance companies (if approved by the FRS Board), and specialized organizations
(e.g., research or risk coordination) (if approved by the FRS Board). What all of the above have in common is that
they operate within, for the benefit of and⁄or support entities that are regulated and those regulations set the
parameters of what is included in, or excluded from, the insurance community.
This is not a gTLD designed for widespread registrations. Instead, registrants and registrations will be restricted
by guidelines included in 20(e) below. Containing recognized members of a regulated community under one gTLD will provide Internet users with a safe and convenient way to seek insurance information and services from vendors and entities that have already been vetted. As such, the .insurance gTLD will be initially reserved for the exclusive
use of members of the U.S. insurance community clearly defined above.
• Accountability mechanisms of the applicant to the community.
The insurance community and the .insurance gTLD will exist in a synergistic relationship. FRS will employ multiple
mechanisms to assure its ongoing accountability to the community including:
- Oversight by FRS’ Board of Directors that consists of representatives from insurance institutions and an Advisory
Board as set forth below. Individual insurance institution directors will represent the interests of the community
as direct community participants.
- The Advisory Board will contain a group of additional members whose sole purpose is to represent the insurance and financial services community. Insurance associations may be selected to represent the broad cross-section of the community as well as the collective interest of their members. Additional insurance companies or support members will be chosen from organizations and associations within the insurance community to ensure diversified
representation of the community’s interests and needs.
- The ABA and Roundtable, whose collective members expressed concerned about the protection of financial gTLDs, led the formation of FRS to protect the insurance community, including, its institutions and, most especially, the
consumers of insurance services. Both will continue their involvement in two significant ways. First, they will be
Directors on FRS’ Board. Further, they will provide continuing oversight of the management of FRS, the operator of
.insurance and will have as part of their ongoing service and mission the ability to communicate with and represent
the entire insurance community as associations.
- Collectively, this broad community of key insurance leaders will continually assess the policies, processes and
operations of .insurance and assure that it continues to operate in the best interest of the insurance community and
in the spirit of FRS’ mission.
Lastly, the community will hold FRS accountable to ensure that applicants for .insurance domains are thoroughly
vetted and agree to adhere to the strict set of operating rules and security standards that govern the licensing and
operation of a .insurance domain.

• Intended registrants in the TLD.
As stated above and in Question 18, the .insurance community will be clearly defined along the same lines as the
current U.S. insurance community is defined by regulation and law. Registrations within the community may initially
be made by the following for-profit and not-for-profit businesses, individuals or organizations:
- Licensed insurance companies regulated by a government entity
- Licensed insurance agents and brokers regulated by a government entity
- Associations whose members include licensed insurance companies, agents or brokers (if approved by the FRS Board)
- Organizations that are majority controlled by insurance companies (if approved by the FRS Board)
- Entities whose operations are principally dedicated to serving insurance companies (if approved by the FRS Board)
- Specialized organizations (e.g., research or risk coordination) (if approved by the FRS Board)
• Intended end-users of the TLD.
End users will not only include the registrants of the .insurance gTLD, but also millions of the industry’s current
and potential consumers. Once .insurance is established as a trusted gTLD for products, services and matters related to the insurance industry, consumers will acknowledge the security and stability associated with the .insurance gTLD.
• Related activities the applicant has carried out or intends to carry out in service of this purpose.
FRS is submitting this application on behalf of the insurance community to ensure that the .insurance gTLD shall
serve as a trusted, hierarchical, and intuitive namespace for this community and the consumers that it serves. All
registrants within this gTLD will be vetted prior to registration to validate their identity, chartering or licensing entity where appropriate and commitment to industry best standards developed by FRS before they are able to register in the .insurance gTLD (see 20(e) below). In addition, the registry will employ a network of both active and passive safeguards to the operation of the registry to ensure that these registrants continue to abide by the terms and conditions set forth in the registration agreement. Security standards, created by the financial services community for use specifically by financial gTLDs, will be employed by FRS (the details of which have already been worked out with FRS’ backend registry operator).
Marketing and promotion of the .insurance gTLD will be conducted on an ongoing basis to ensure acceptance,
familiarity and trust among members of the community. FRS has actively engaged several insurance-related trade
associations to inform them of FRS’ activities and what it could mean for their respective members. However, the
registry will also be promoted by the Board of Directors and registrants due to the security features and standards
employed within this space. Insurance providers and affiliates will have an incentive to direct consumers to the
.insurance sites they operate, and thus promote their second-level domains containing .insurance across all media.
Consumers will quickly become familiar with .insurance and see that its use is limited to trusted organizations
within the insurance industry.
• Explanation of how the purpose is of a lasting nature.
The .insurance gTLD will ensure that consumers are aware of a gTLD that provides trustworthy and vetted entities
with legitimate insurance products and services, absent some of the abuses seen currently on the internet. This gTLD
has a lasting nature because it shifts the burden of confirming authenticity from the consumer to the registry or its designated third-party service provider. Further, it will allow the consumer to conduct a simple search, within the domain, that will result in a limited pool of legitimate second-level registrants. The beauty of this streamlined search and worry-free access to insurance providers would best ensure the lasting nature of .insurance and result in a successful .insurance launch.
As stated in 20(b) above, the continued success of .insurance is centered on its role as a trusted and safe
environment. The Internet user increasingly finds him or herself challenged by opportunists and charlatans that
present themselves as legitimate online businesses. This is a particular challenge in the insurance industry because
consumers that are not well informed about the legitimacy of online businesses may provide and entrust sensitive
personal and financial information to non-insurance providers.
Rogue online operators register domains in other gTLDs that look similar to legitimate members of the insurance
community because they also have second-level domains registered in other gTLDs. Consumers are consistently lured into ʺphishingʺ attacks by email either promising them unrealistic deals or posing as their own insurance providers. These online practices cost the insurance industry and consumers in time and dollars.
RSA, a premier provider of security, risk and compliance management solutions for business, provided the following
in their Online Fraud Report of January 2012:
- In 2011, approximately one in every 300 emails was deemed to contain phishing elements, most targeted to the
public sector, followed by the SME business sector.
- The cumulative number of phishing attacks recorded through 2011 was 279,580—a 37% increase from 2010.
- In 2011, phishing attacks targeted brands from 31 different geographies and emails communicated in 16 different
languages – reaching an even more diverse crowd of Internet users. The top countries in which the most brands were
attacked include: the U.S., the UK, Australia, Canada, India, and Brazil. Phishing has become easier with more
automated toolkits available. On average, every phishing attack yields a $4,500 profit.
- The U.S. was the second-most targeted country with 28% of all phishing attacks. Only the United Kingdom was
targeted more.
- Together, the U.S. and UK accounted for 43% of the world’s targeted brands, while the brands of 14 additional
countries accounted for a total of 39% of phishing attacks in December.
FRS seeks to minimize the incidence of this type of online behavior within the .insurance gTLD by the strict vetting
planned for each second-level .insurance domain. With the addition of employing security standards developed by the
financial services industry, FRS plans to significantly diminish the risk of insurance-related phishing for millions of insurance consumers.

• Relationship to the established name, if any, of the community.
The .insurance gTLD is perfectly aligned with the needs and services of the insurance community as defined in 20(a),
providers of insurance and their affiliates, and the gTLD name - the industry product sold – solidly identifies the
community and its products. Founding members from the insurance industry have reported to FRS that based on their
consumers’ online and search behavior, “insurance” is the term that consumers associate most with the insurance
industry. As a result, FRS’ Board of Directors, comprised of members of the insurance industry, voted and approved
that it move forward with an application for the .insurance gTLD. Consumers will understand the connection between
the gTLD and the existing business. As already established in 20(c), any second-level domain registrant in the
.insurance space will have been vetted to ensure they are an eligible member of the community.
As .insurance gains more registrants and those registrants promote their .insurance URLs to consumers on the
Internet, the .insurance name will become increasingly more familiar to the online community. The key goal will be
that the .insurance gTLD be linked in the consumer’s mind with the community identified in 20(a), specifically
insurance providers and affiliates. As stated above, the .insurance gTLD is not intended for widespread distribution, so with no registrants outside the defined community, there will be little confusion on the part of consumers or potential registrants.
• Relationship to the identification of community members.
Members of the community are insurance providers and their affiliates. Vertical and horizontal integration are found
within the community, but all potential registrants shall have the criteria established in 20(c) in common. As such,
registrants include licensed insurance companies regulated by a government entity, licensed agents and brokers
regulated by a government entity, associations whose members include licensed insurance companies, agents or brokers (if approved by the FRS Board), organizations that are majority controlled by insurance companies (if approved by the FRS Board), entities whose operations are principally dedicated to serving insurance companies (if approved by the FRS Board), and specialized organizations (e.g., research or risk coordination) (if approved by the FRS Board). 
The creation of FRS was requested by insurance providers; it represents insurance community members and therefore has a direct stake in ensuring the trustworthiness and reliability of .insurance and its governance. FRS’ broad reach in the insurance industry provides it with an advantage in its operation of .insurance. FRS’s Board of
Directors and Advisory Board will serve as representatives of the insurance community. FRS’ Operating Managers, ABA and the Roundtable, represent the insurance community and each has members that are insurance providers. As is the case in such organizations, FRS and its Operating Managers have strict governance protocols to ensure no one insurance industry player unduly influences or controls the organization. Further, that strong governance protocol
carries vertically to FRS and to the operation of .insurance. Potential .insurance registrants will be aware that FRS will operate the .insurance gTLD without bias toward any particular sector or player within the broader insurance community.
• any connotations the string may have beyond the community.
None.

• Eligibility: who is eligible to register a second-level name in the gTLD, and how will eligibility be determined?
Registrations within the community may initially be made by the following business, individuals or organizations:
- Licensed insurance companies regulated by a government entity
- Licensed insurance agents and brokers regulated by a government entity
- Associations whose members include licensed insurance companies, agents or brokers (if approved by the FRS Board)
- Organizations that are majority controlled by insurance companies (if approved by the FRS Board)
- Entities whose operations are principally dedicated to serving insurance companies (if approved by the FRS Board)
- Specialized organizations (e.g., research or risk coordination) (if approved by the FRS Board)
As the potential operator of .insurance, FRS considers its commitment to both the insurance industry and the
consumers it serves of paramount importance. The nature of the activity that will be conducted in .insurance
requires that registrations only be permitted by verified members of the insurance community. In addition to
validating the eligibility of the registrant, the domain name must comply with name selection and use policies.
To ensure strict compliance with these policies, FRS will develop and implement a Registrant Eligibility Criteria
Process. This process will require .insurance accredited registrars to gather materials from proposed registrants
that will be used by the registry or its designated third party services provider, to authenticate the registrants’
eligibility to register in .insurance.
The registration process for a .insurance name includes that potential registrants must provide the registrar with
the following information:
- Full legal name
- Business address
- Professional title of representative of the administrative contact of the potential applicant
- Business name
- Point of contact within the business who can verify their representation of the business
- Phone
- Email
- Another proof of identity necessary to establish that the registrant is an eligible member of the .insurance gTLD
community
- For insurance companies, the state regulatory authority issuing its charter
- For agents and brokers, the state licensing agency issuing its permission to act as an agent or broker
- For organizations that are majority controlled by insurance companies (if approved by the FRS Board), list of and
proof of its owner(s)
- For entities whose operations are principally dedicated to serving insurance companies (if approved by the FRS
Board), corporate operating agreement or like document(s) as determined necessary to validate alignment with the
goals of the community
- For specialized organizations (e.g., research or risk coordination) (if approved by the FRS Board), a copy of its
corporate operating agreement if for-profit or its mission statement if non-profit (or like document(s) as determined necessary to validate alignment with the goals of the community)
Applicants who meet the eligibility requirements and have been authenticated will then be permitted to register
domains in .insurance.
Domain names that pass the vetting process will enter a 5-day Add Grace Period (AGP), or Pending Create, before
becoming valid. Applicants whose domain name fails the vetting process will be notified with reasons for denial and
procedures for appeal. Any applicant who is rejected for any reason can appeal the decision to FRS.
FRS will audit all approved registrants and their domains to ensure compliance with all applicable eligibility and
use requirements.
• Name selection: what types of second-level names may be registered in the gTLD.
Domains initially registered in .insurance must correspond to a trademark, trade name or other service mark owned by the registrant. Initially, all other registrations (e.g., geographic, generic, etc.) will not be allowed. FRS will
reserve a set of generic domain names prior to launch. These domain names will either be used by FRS in its capacity as Registry Operator for the management, operation, and purpose of the gTLD or they will be equitably allocated to community members at a date and time to be determined by FRS’ Board. The subset of domain names reserved for FRS’ use is necessary to create a trusted, hierarchical, and intuitive framework for the .insurance gTLD.
Although these reserved words will be commonly used words and phrases and or geographic terms, FRS will provide an enhanced Rights Protection Mechanism that will offer trademark owners with an avenue to challenge the reservation and potential use of these domain names. This challenge process will be modeled after the highly successful dotAsia Pioneering Program.
• Content⁄Use: what restrictions, if any, the registry operator will impose on how a registrant may use its
registered name?
FRS will have an Acceptable Use Policy (AUP) that will govern how a registrant may use its registered name. A DRAFT
version of the policy (which may be amended from time to time) follows:
All .insurance domains must be used to serve the needs of the insurance community. By registering a name in a gTLD operated by FRS, you agree to be bound by the terms of this Acceptable Use Policy (AUP). In using your domain, you may not:
1. Use your domain for any purposes prohibited by the laws of the jurisdiction(s) in which you do business or any
other applicable law. For insurance companies, agents and brokers specifically, use your domain name for any
purposes prohibited by the insurance regulations of the regulator or government agency that issued your charter or
license is strictly prohibited.
2. Use your domain for any purposes or in any manner that violates a statute, rule or law governing use of the
Internet and⁄or electronic commerce (specifically including “phishing,” ʺpharming,ʺ and⁄or distributing Internet
viruses and other destructive activities).
3. Use your domain for the following types of activity:
- Violating the privacy or publicity rights of another member of the insurance community or any other person or
entity, or breaching any duty of confidentiality that you owe to another member of the .insurance gTLD community or
any other person or entity;
- Promoting or engaging in hate speech, hate crime, terrorism, violence against people, animals, or property, or
intolerance of or against any protected class;
- Promoting or engaging in defamatory, harassing, abusive or otherwise objectionable behavior;
- Promoting or engaging in pornography;
- Promoting or engaging in any spam or other unsolicited bulk email, or computer or network hacking or cracking;
- Promoting or engaging in any money laundering or terrorist financing activity;
- Infringing on the intellectual property rights of another member of the .insurance gTLD community or any other
person or entity;
- Engaging in activities designed to impersonate any third party or create a likelihood of confusion in sponsorship;
- Interfering with the operation of .insurance gTLD or services offered by FRS;
- Distributing or installing any viruses, worms, bugs, Trojan horses or other code, files or programs designed to,
or capable of, disrupting, damaging or limiting the functionality of any software or hardware;
- Disseminating content that contains false or deceptive language, or unsubstantiated or comparative claims,
regarding FRS;
- Licensing your domain to any third party during the period of your registration; or
- Engaging in behavior that is anti-competitive, boycotts or otherwise violates anti-trust laws.
You are responsible for the usage of your domain at all times during the period of your registration.
Proxy registrations are prohibited for all gTLDs operated by FRS.
By “use,” “usage” or “using” your domain name we mean any use involving the Internet, including but not limited to
website(s) and⁄or any pages thereof resolving at your domain, either directly or indirectly (including redirection,
framing, pop-up windows⁄browsers, linking, etc.) and email distribution and⁄or reception.
As part of the AUP, FRS will have complete enforcement rights over registrants’ use of domain names.
• Enforcement: what investigation practices and mechanisms exist to enforce the policies above, what resources are
allocated for enforcement, and what appeal mechanisms are available to registrants?
FRS proposes the use of both active and passive enforcement mechanisms to enforce the policies outlined above. As part of the AUP, FRS will have complete enforcement rights over registrant’s use of .insurance domain names.
If Registrant violates this AUP, Registrant will be subject to a rapid domain name compliance action, be in material
breach of the Agreement, and along with all other rights and remedies under this Agreement with respect to such a
breach, FRS reserves the right to revoke, suspend, terminate, cancel or otherwise modify Registrant’s rights to the
domain name.
On a regular basis, FRS will audit domain names registered in the .insurance gTLD to ensure compliance with all
eligibility and use criteria. If a violation is discovered, an investigation will immediately begin to rectify the violation.
If a registrant chooses to appeal, FRS will review the appeal to determine if there are any material changes to the
action or activity. FRS will retain the right to assign the dispute to an ombudsman if necessary. This appeal or referral process will operate on a cost-recovery basis.

Not Available

No

22.1 fTLD Registry Services, LLC (FRS) has Properly Researched this Topic 

FRS is keenly aware of the sensitivity of national governments in connection with protecting country and territory identifiers in the DNS. In preparation for answering this question, FRS reviewed the following relevant background material regarding the protection of geographic names in the DNS:

- ICANN Board Resolution 01-92 regarding the methodology developed for the reservation and release of country names in the .INFO top-level domain, see http:⁄⁄www.icann.org⁄en⁄minutes⁄minutes-10sep01.htm;
- ICANN’s Proposed Action Plan on .INFO Country Names, see http:⁄⁄www.icann.org⁄en⁄meetings⁄montevideo⁄action-plan-country-names-09oct01.htm;
- Second WIPO Internet Domain Name Process – The Recognition and Rights and the Use of Names in the Internet Domain Name System, Section 6, Geographical Identifiers, see http:⁄⁄www.wipo.int⁄amc⁄en⁄processes⁄process2⁄report⁄html⁄report.html;
- The GAC Principles Regarding New gTLDs, see https:⁄⁄gacweb.icann.org⁄download⁄attachments⁄1540128⁄gTLD_principles_0.pdf?version=1&modificationDate=1312358178000
- ICANN’s Generic Names Supporting Organization Reserved Names Working Group – Final Report, see http:⁄⁄gnso.icann.org⁄issues⁄new-gtlds⁄final-report-rn-wg-23may07.htm

22.2 Initial Reservation of Country and Territory Names

FRS is committed to initially reserving the country and territory names contained in the internationally recognized lists described in article 5 of Specification 5 attached to New gTLD Applicant Guidebook at the second level and at all other levels within .insurance gTLD at which FRS will provide for registrations. Specifically, FRS will reserve;

1. the short form (in English) of all country and territory names contained on the ISO 3166-1 list, as updated from time-to-time, including the European Union, which is exceptionally reserved on the ISO 3166-1 list, and its scope extended in August 1999 to any application needing to represent the name European Union 〈http:⁄⁄www.iso.org⁄iso⁄support⁄country_codes⁄iso_3166_code_lists⁄iso-3166- 1_decoding_table.htm#EU〉;

2. the United Nations Group of Experts on Geographical Names, Technical Reference Manual for the Standardization of Geographical Names, Part III Names of Countries of the World; and

3. the list of United Nations member states in 6 official United Nations languages prepared by the Working Group on Country Names of the United Nations Conference on the Standardization of Geographical Names.

22.3 Fair & Non-Misleading Use of Geographical Identifiers

The members of the financial services community are a highly regulated industry in their respective countries, and thus have a compelling interest to make sure that any use of geographic identifiers in advertising is fair and non-misleading. In fact many members of the financial services community make regular use of geographical identifiers at the second level or third level in domain name registrations usually coupled with their company name or trademark. This is in addition to registration of their company name and other trademarks across a wide number of gTLDs and ccTLDs. 

FRS would like to provide a hierarchical and intuitive framework for the .insurance namespace by using geographical identifiers as a second-level domain name. This use of geographical identifiers to the left of the TLD and as part of the domain name itself, upon information and belief is belief to have a direct and material impact on search engine algorithms and their corresponding query results. As ICANN has largely premised this new gTLD round on promoting innovation, FRS would like to see if this type of hierarchical and intuitive use of second-level domain name within a TLD provides increased consumer functionality.

22.4 The Legal Protection of Geographical Identifiers

One of the more authoritative resources on the current state of the law in connection with the protection of geographical identifiers was authored by the World Intellectual Property Organization (WIPO) in its 2001 Second WIPO Internet Domain Name Process, The Recognition of Rights and the Use of Names in the Internet Domain Name System (DNS). Chapter six of this report was devoted exclusively to the protection of Geographical Identifiers.

In analyzing the well-established framework against the misuse of geographical identifiers at the international, regional and national levels, WIPO identified the following two elements for the protection of geographical identifiers: (i) a prohibition of false descriptions of the geographical source of goods; and (ii) a more extensive set of rules prohibiting the misuse of one class of geographical source indicators, known as geographical indications. See Second WIPO Internet Domain Name Process (Paragraphs 206 and 210).

Notwithstanding WIPO’s recommendation that the protection of geographical identifiers is “a difficult area on which views are not only divided, but also ardently held” (Paragraph 237) national governments within the ICANN Governmental Advisory Committee (GAC) and other international fora have continued to advocate for increased safeguards to protect against the misuse of geographical identifiers within the domain name system.

FRS and the members of the financial services community parent, as responsible international businesses, seek to minimize any potential business practices that might mislead consumers. However, at the same believe that it is important to be able to use geographical identifiers in a fair use and non-misleading manner, if such use can benefit users as proposed in FRS’ proposed business model.

22.5 Fair & Non-Misleading Use of Geographical Identifiers

In undertaking a thorough research of this subject matter prior to filing this application, FRS’ subject matter experts were able to uncover the following representative sampling of fair and non-misleading use of geographical identifiers used in the existing gTLD domain name space:

Fair Use of National Geographical Identifiers

〈AUSTRALIA.COOP〉 – Is operated by Co-operatives Australia the national body for State Co-operative Federations and provides a valuable resource about cooperatives within Australia.

〈UK.COOP〉 – Is operated by Co-operatives UK the national trade body that campaigns for co-operation and works to promote, develop and unite co-operative enterprises within the United Kingdom. 

〈NZ.COOP〉 – Is operated by the New Zealand Cooperatives Association which brings together the country’s cooperative mutual business in a not-for-profit incorporated society.

〈USA.JOBS〉 - Is operated by DirectEmployers Association (DE). While Employ Media the registry operator of the .JOBS gTLD is currently in a dispute with ICANN regarding the allocation of this and other domain names. Direct Employers has a series of partnerships and programs with the United States Department of Labor, the National Association of State Workforce Agencies and Facebook to help unemployed workers find jobs. 

〈MALDIVIAN.AERO〉 - Is the dominant domestic air carrier in Maldives, and provides a range of commercial and leisure air transport services. 

Fair Use Regional ⁄Local

〈TEXAS.JOBS〉 - Is operated a joint effort between DE, Texas Workforce Commission and the National Labor Exchange to connect job seekers with approximately 96,000 job openings. An additional domain name operated by this joint effort was 〈WORKINTEXAS-VETERANS.JOBS〉 a resource devoted to helping Texas veterans translate their military skills to jobs in the civil marketplace.

〈BOISE.COOP〉 - Is operated by Boise Co-op a member owned cooperative, founded in 1973 by a few dozen individuals who shared a mutual interest in buying healthy and organic food at reasonable prices.

〈BROOKLYN.COOP〉 - Is operated by Brooklyn Cooperative Federal Credit Union who began as a modest storefront business in 2001, but is now New York City’s fastest growing credit union and a model for community development credit unions nationwide. 

〈HYDERABAD.AERO〉 - Is operated by the Hyderabad International Airport and provides a range of interactive services and information for both business and leisure travelers. 

〈SACRAMENTO.AERO〉 - Is portal website operated by Sacramento county to provide links to each of the airports serving the Sacramento area: Sacramento International Airport (SMF), Mather Airport (MHR), Executive Airport (SAC) and Franklin Field (F72).

22.6 Protection of Regional and Local Geographic Names for Misleading Use

Although FRS has stated its intention to use non-reserved geographic identifiers as part of a hierarchical and intuitive framework in a fair and non-misleading use to help consumers navigate the .insurance namespace. FRS is committed to operating the .insurance namespace in a manner that minimizes potential consumer confusion, and will with actively work with others in the ICANN community regarding any future policy development in this area. 

22.7 Potential Future Release of Initially Reserved Names

FRS and the other members of the global financial services community look forward to working in connection with other new gTLD registry operators (especially those financial service community members that might be securing their own .brand TLD) in potentially working with ICANN’s Governmental Advisory Committee to explore potential processes that could permit the release of initially reserved country names (including ISO-3166 two characters). Specifically, FRS is interested in exploring other Registry Service Evaluation Process (RSEP) requests that have been filed by existing gTLD registry operators in releasing previously reserved domain names. 

22.8 Dispute Resolution

Applicant does not envision any potential disputes from governments or public authorities in connection with the registration and use of geographic names within the .insurance gTLD based upon its proposed use set forth in Answer 18 above. 

However, FRS is committed to working with governments, public authorities, or Intergovernmental Organizations (IGOs) that may have a concern regarding the registration of names with national or geographic significance at the second level within the .insurance gTLD. Therefore, should there arise any potential disputes, FRS will undertake an immediate policy development process as identified below.

22.9 Creation and Updating the Policies

If there should arise some future need for the creation or updating of the policies regarding this class of domain names, FRS will act in an open and transparent manner consistent with its prior practices within the global financial services community to develop such a policy and⁄or recommendation.

FRS is also committed to continually reviewing and updating these lists to prevent misleading use of geographical identifiers. Consistent with this commitment, FRS intends to remain an active participant in any ongoing ICANN policy discussion regarding the protection of geographic names within the DNS.

1 CUSTOMARY REGISTRY SERVICES

As fTLD Registry Services, LLC’s (FRS) selected provider of backend registry services, Verisign provides a comprehensive system and physical security solution that is designed to ensure a TLD is protected from unauthorized disclosure, alteration, insertion, or destruction of registry data. Verisign’s system addresses all areas of 
security including information and policies, security procedures, the systems development lifecycle, physical security, system hacks, break-ins, data tampering, and other disruptions to operations. Verisign’s operational environments not only meet the security criteria specified in its customer contractual agreements, thereby 
preventing unauthorized access to or disclosure of information or resources on the Internet by systems operating in accordance with applicable standards, but also are subject to multiple independent assessments as detailed in the response to Question 30, Security Policy. Verisign’s physical and system security methodology follows a mature, ongoing lifecycle that was developed and implemented many years before the development of the industry standards with which Verisign currently complies. Please see the response to Question 30, Security Policy, for details of the security features of Verisign’s registry services. 

Verisign’s registry services fully comply with relevant standards and best current practice RFCs published by the Internet Engineering Task Force (IETF), including all successor standards, modifications, or additions relating to the DNS and name server operations including without limitation RFCs 1034, 1035, 1982, 2181, 2182, 2671, 3226, 3596, 3597, 3901, 4343, and 4472. Moreover, Verisign’s Shared Registration System (SRS) supports the following IETF Extensible Provisioning Protocol (EPP) specifications, where the Extensible Markup Language (XML) templates and XML schemas are defined in RFC 3915, 5730, 5731, 5732, 5733, and 5734. By strictly adhering to these RFCs, Verisign helps to ensure its registry services do not create a condition that adversely affects the throughput, response time, consistency, or coherence of responses to Internet servers or end systems. Besides its leadership in authoring RFCs for EPP, Domain Name System Security Extensions (DNSSEC), and other DNS services, Verisign has created and contributed to several now well-established IETF standards and is a regular and long-standing participant in key 
Internet standards forums.

Attachment 23-1 summarizes the technical and business components of those registry services, customarily offered by a registry operator (i.e., Verisign), that support this application. These services are currently operational and support both large and small Verisign-managed registries. Customary registry services are provided in the same manner as Verisign provides these services for its existing gTLDs.

Through these established registry services, Verisign has proven its ability to operate a reliable and low-risk registry that supports millions of transactions per day. Verisign is unaware of any potential security or stability concern related to any of these services. 

Registry services defined by this application are not intended to be offered in a manner unique to the new generic top-level domain (gTLD) nor are any proposed services unique to this application’s registry. 

As further evidence of Verisign’s compliance with ICANN mandated security and stability requirements, Verisign allocates the applicable RFCs to each of the five customary registry services (see items A – E in Attachment 23-1). For each registry service, Verisign also provides evidence in Attachment 23-2 of Verisign’s RFC compliance and includes relevant ICANN prior-service approval actions. 

1.1 Critical Operations of the Registry 

i. Receipt of Data from Registrars Concerning Registration of Domain Names and Name Servers 
See Item A in Attachment 23-1 and Attachment 23-2. 

ii. Provision to Registrars Status Information Relating to the Zone Servers
Verisign is FRS’ selected provider of backend registry services. Verisign registry services provisions to registrars status information relating to zone servers for the TLD. The services also allow a domain name to be updated with clientHold, serverHold status, which removes the domain name server details from zone files. This ensures that DNS queries of the domain name are not resolved temporarily. When these hold statuses are removed, the name server details are written back to zone files and DNS queries are again resolved. Attachment 23-3 describes the domain name status information and zone insertion indicator provided to registrars. The zone insertion indicator determines whether the name server details of the domain name exist in the zone file for a given domain name status. Verisign also has the capability to withdraw domain names from the zone file in near-real time by changing the domain name statuses upon request by customers, courts, or legal authorities as required. 

iii. Dissemination of TLD Zone Files
See Item B in Attachment 23-1 and Attachment 23-2. 

iv. Operation of the Registry Zone Servers
Verisign is FRS’ selected provider of backend registry services. Verisign, as a company, operates zone servers and serves DNS resolution from 76 geographically distributed resolution sites located in North America, South America, Africa, Europe, Asia, and Australia. Currently, 17 DNS locations are designated primary sites, offering greater capacity than smaller sites comprising the remainder of the Verisign constellation. Verisign also uses Anycast techniques and regional Internet resolution sites to expand coverage, accommodate emergency or surge capacity, and support system availability during maintenance procedures. Verisign operates FRS’ gTLD from a minimum of eight of its primary sites (two on the East Coast of the United States, two on the West Coast of the United States, two in Europe, and two in Asia) and expands resolution sites based on traffic volume and patterns. Further details of the geographic diversity of Verisign’s zone servers are provided in the response to Question 34, Geographic Diversity. Moreover, additional details of Verisign’s zone servers are provided in the response to Question 32, Architecture 
and the response to Question 35, DNS Service. 

v. Dissemination of Contact and Other Information Concerning Domain Name Server Registrations
See Item C in Attachment 23-1 and Attachment 23-2. 

2 OTHER PRODUCTS OR SERVICES THE REGISTRY OPERATOR IS REQUIRED TO PROVIDE BECAUSE OF THE ESTABLISHMENT OF A CONSENSUS POLICY

Verisign, FRS’ selected provider of backend registry services, is a proven supporter of ICANN’s consensus-driven, bottom-up policy development process whereby community members identify a problem, initiate policy discussions, and generate a solution that produces effective and sustained results. Verisign currently provides all of the products or services (collectively referred to as services) that the registry operator is required to provide because of the establishment of a Consensus Policy. For the .insurance gTLD, Verisign implements these services using the same proven processes and procedures currently in-place for all registries under Verisign’s management. Furthermore, Verisign executes these services on computing platforms comparable to those of other registries under Verisign’s management. Verisign’s extensive experience with consensus policy required services and its proven processes to implement these services greatly minimize any potential risk to Internet security or stability. Details of these services are provided in the following subsections. It shall be noted that consensus policy services required of registrars (e.g., Whois Reminder, Expired Domain) are not included in this response. This exclusion is in accordance with the direction provided in the question’s Notes column to address registry operator services. 

2.1 Inter-Registrar Transfer Policy (IRTP)
Technical Component: In compliance with the IRTP consensus policy, Verisign, FRS’ selected provider of backend registry services, has designed its registration systems to systematically restrict the transfer of domain names within 60 days of the initial create date. In addition, Verisign has implemented EPP and “AuthInfo” code 
functionality, which is used to further authenticate transfer requests. The registration system has been designed to enable compliance with the five-day Transfer grace period and includes the following functionality:
- Allows the losing registrar to proactively ‘ACK’ or acknowledge a transfer prior to the expiration of the five-day Transfer grace period
- Allows the losing registrar to proactively ‘NACK’ or not acknowledge a transfer prior to the expiration of the five-day Transfer grace period 
- Allows the system to automatically ACK the transfer request once the five-day Transfer grace period has passed if the losing registrar has not proactively ACK’d or NACK’d the transfer request.

Business Component: All requests to transfer a domain name to a new registrar are handled according to the procedures detailed in the IRTP. Dispute proceedings arising from a registrarʹs alleged failure to abide by this policy may be initiated by any ICANN-accredited registrar under the Transfer Dispute Resolution Policy. FRS’ 
compliance office serves as the first-level dispute resolution provider pursuant to the associated Transfer Dispute Resolution Policy. As needed Verisign is available to offer policy guidance as issues arise. 

Security and Stability Concerns: Verisign is unaware of any impact, caused by the service, on throughput, response time, consistency, or coherence of the responses to Internet servers or end-user systems. By implementing the IRTP in accordance with ICANN policy, security is enhanced as all transfer commands are authenticated using the AuthInfo code prior to processing. 

ICANN Prior Approval: Verisign has been in compliance with the IRTP since November 2004 and is available to support FRS in a consulting capacity as needed. 

Unique to the TLD: This service is not provided in a manner unique to the .insurance TLD.

2.2 Add Grace Period (AGP) Limits Policy

Technical Component: Verisign’s registry system monitors registrars’ Add grace period deletion activity and provides reporting that permits FRS to assess registration fees upon registrars that have exceeded the AGP thresholds stipulated in the AGP Limits Policy. Further, FRS accepts and evaluates all exemption requests received from registrars and determines whether the exemption request meets the exemption criteria. FRS maintains all AGP Limits Policy exemption request activity so that this material may be included within FRS’ Monthly Registry Operator Report to ICANN.

Registrars that exceed the limits established by the policy may submit exemption requests to FRS for consideration. FRS’ compliance office reviews these exemption requests in accordance with the AGP Limits Policy and renders a decision. Upon request, FRS submits associated reporting on exemption request activity to support reporting in accordance with established ICANN requirements.

Business Component: The Add grace period (AGP) is restricted for any gTLD operator that has implemented an AGP. Specifically, for each operator: 

- During any given month, an operator may not offer any refund to an ICANN-accredited registrar for any domain names deleted during the AGP that exceed (i) 10% of that registrarʹs net new registrations (calculated as the total number of net adds of one-year through ten-year registrations as defined in the monthly reporting requirement of Operator Agreements) in that month, or (ii) fifty (50) domain names, whichever is greater, unless an exemption has been granted by an operator. 
- Upon the documented demonstration of extraordinary circumstances, a registrar may seek from an operator an exemption from such restrictions in a specific month. The registrar must confirm in writing to the operator how, at the time the names were deleted, these extraordinary circumstances were not known, reasonably could not have been known, and were outside the registrarʹs control. Acceptance of any exemption will be at the sole and reasonable discretion of the operator; however ʺextraordinary circumstancesʺ that reoccur regularly for the same registrar will not be deemed extraordinary. 

In addition to all other reporting requirements to ICANN, FRS identifies each registrar that has sought an exemption, along with a brief description of the type of extraordinary circumstance and the action, approval, or denial that the operator took. 

Security and Stability Concerns: Verisign is unaware of any impact, caused by the policy, on throughput, response time, consistency, or coherence of the responses to Internet servers or end-user systems.

ICANN Prior Approval: Verisign, FRS’ backend registry services provider, has had experience with this policy since its implementation in April 2009 and is available to support FRS in a consulting capacity as needed. 

Unique to the TLD: This service is not provided in a manner unique to the .insurance gTLD.

2.3 Registry Services Evaluation Policy (RSEP)

Technical Component: Verisign, FRS’ selected provider of backend registry services, adheres to all RSEP submission requirements. Verisign has followed the process many times and is fully aware of the submission procedures, the type of documentation required, and the evaluation process that ICANN adheres to. 

Business Component: In accordance with ICANN procedures detailed on the ICANN RSEP website (http:⁄⁄www.icann.org⁄en⁄registries⁄rsep⁄), all gTLD registry operators are required to follow this policy when submitting a request for new registry services.

Security and Stability Concerns: As part of the RSEP submission process, Verisign, FRS’ backend registry services provider, identifies any potential security and stability concerns in accordance with RSEP stability and security requirements. Verisign never launches services without satisfactory completion of the RSEP process and resulting approval.

ICANN Prior Approval: Not applicable.

Unique to the TLD: gTLD RSEP procedures are not implemented in a manner unique to the .insurance gTLD.

3 PRODUCTS OR SERVICES ONLY A REGISTRY OPERATOR IS CAPABLE OF PROVIDING BY REASON OF ITS DESIGNATION AS THE REGISTRY OPERATOR

Verisign, FRS’ selected backend registry services provider, has developed a Registry-Registrar Two-Factor Authentication Service that complements traditional registration and resolution registry services. In accordance with direction provided in Question 23, Verisign details below the technical and business components of the service, identifies any potential threat to registry security or stability, and lists previous interactions with ICANN to approve the operation of the service. The Two-Factor Authentication Service is currently operational, supporting multiple registries under ICANN’s purview. 

FRS is unaware of any competition issue that may require the registry service(s) listed in this response to be referred to the appropriate governmental competition authority or authorities with applicable jurisdiction. ICANN previously approved the service(s), at which time it was determined that either the service(s) raised no competitive concerns or any applicable concerns related to competition were satisfactorily addressed.

3.1 Two-Factor Authentication Service

Technical Component: The Registry-Registrar Two-Factor Authentication Service is designed to improve domain name security and assist registrars in protecting the accounts they manage. As part of the service, dynamic one-time passwords 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.

Business Component: 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.

Security and Stability Concerns: Verisign is unaware of any impact, caused by the service, on throughput, response time, consistency, or coherence of the responses to Internet servers or end-user systems. The service is intended to enhance domain name security, resulting in increased confidence and trust by registrants.

ICANN Prior Approval: ICANN approved the same Two-Factor Authentication Service for Verisign’s use on .com and .net on 10 July 2009 (RSEP Proposal 2009004) and for .name on 16 February 2011 (RSEP Proposal 2011001). 

Unique to the TLD: This service is not provided in a manner unique to the .insurance gTLD.

3.2 Premium Domain Name Registration

One of the first new registry operators to provide a Premium Domain Name Registration service offering was mTLD during the launch of the .MOBI. mTLD which combined an RFP and auction process to allocate a set of premium commonly used words and phrases that had been complied and reserved prior to the general launch of the registry. To safeguard against any potential trademark violations, the registry operator provided an administrative challenge process administered by the World Intellectual Property Organization (WIPO) for trademark owners to remove a potential trademark from the premium list. FRS believes that the use of a Premium Domain Name Registration service may offer it the opportunity to ensure that highly attractive and sought after domain names are allocated in a manner that 
best serves the interest of the Registry.

Technical Component: The only technical component above and beyond a standard domain name registration is that FRS must register⁄reserve the premium domain names in advance of the general launch of the registry. In addition, when allocating a premium domain name FRS must provide the prospective registrant with an authorization code to transfer the domain name to an ICANN-accredited registrar. 

There are a variety of ways in which Verisign, FRS’ selected backend registry services provider, can reserve premium domain names from general registrations. The easiest includes placing the premium domain names in a special “client” account associated with the FRS, whereas some backend registry operators such as VeriSign have written specific Extensible Provisioning Protocol (EPP) extension mapping to handle Premium Domain Name Registration services. These various technical implementations of Premium Domain Name Registration services is something FRS has taken into account with choosing Verisign as its backend registry operator.

FRS may elect to utilize an auction as part of the Premium Domain Name Registration equitable allocation process and there may be the need to use a third party auction provider. In light of a recent controversy within the domain name industry involving auction fraud, there is the need to safeguard the integrity of the auction process particularly when that auction provider may have ties to registration authorities (registrars and⁄or registries). The need to proactively address any potential allegations of fraud is exactly what dotAsia did during its launch. 

Business Components: There are a number of business components that need to be proactively addressed by FRS in any Premium Domain Name Registration services including but not limited to: ensuring that any RFP process is conducted in accordance with industry best practices; ensuring adequate safeguards to mitigate against auction fraud; and the potential use of auditors or third party dispute resolution service providers to resolve any challenges in connection with premium domain name allocations. 

It is a critical challenge for all new registries to ensure that commonly used words and phrases that Internet users are likely to key in as a second-level domain name resolve to quality content. If Internet users are directed to parked or pay per click pages, this is likely to negatively impact the image⁄brand of the new gTLD. Premium Domain Name Registration services, particularly in advance of general registration services, allows a Registry Operator to convey a positive image to prospective registrants. This approach was successfully used by mTLD in connection with its Show Case Names and dotAsia’s Pioneering Names. FRS will undertake ongoing outreach and marketing research to determine the best approach toward the allocation of these premium domain names, as ICANN’s intention to allocate an 
unlimited number of new gTLDs is likely to impact historical metrics and data points.

Security⁄Stability Components: There should be no security⁄stability concerns beyond those referenced in the Standard Domain Name Registration Service. However, Verisign, FRS’ selected provider of backend registry services, may have to exercise some enhanced security protocols when transferring EPP auth codes to successful registrants to allow them to transfer the domain name to a registrar of their choice.

1 ROBUST PLAN FOR OPERATING A RELIABLE SRS

1.1 High-Level Shared Registration System (SRS) System Description

Verisign, fTLD Registry Services, LLC’s (FRS) selected provider of backend registry services, provides and operates a robust and reliable SRS that enables multiple registrars to provide domain name registration services in the top-level domain (TLD). Verisign’s proven reliable SRS serves approximately 915 registrars, and Verisign, as a company, has averaged more than 140 million registration transactions per day. The SRS provides a scalable, fault-tolerant platform for the delivery of gTLDs through the use of a central customer database, a web interface, a standard provisioning protocol (i.e., Extensible Provisioning Protocol, EPP), and a transport protocol (i.e., Secure Sockets Layer, SSL). 

The SRS components include:

- Web Interface: Allows customers to access the authoritative database for accounts, contacts, users, authorization groups, product catalog, product subscriptions, and customer notification messages.
- EPP Interface: Provides an interface to the SRS that enables registrars to use EPP to register and manage domains, hosts, and contacts.
- Authentication Provider: A Verisign developed application, specific to the SRS, that authenticates a user based on a login name, password, and the SSL certificate common name and client IP address. 

The SRS is designed to be scalable and fault tolerant by incorporating clustering in multiple tiers of the platform. New nodes can be added to a cluster within a single tier to scale a specific tier, and if one node fails within a single tier, the services will still be available. The SRS allows registrars to manage the .insurance gTLD domain names in a single architecture.

To flexibly accommodate the scale of its transaction volumes, as well as new technologies, Verisign employs the following design practices:

- Scale for Growth: Scale to handle current volumes and projected growth.
- Scale for Peaks: Scale to twice base capacity to withstand “registration add attacks” from a compromised registrar system.
- Limit Database CPU Utilization: Limit utilization to no more than 50 percent during peak loads.
- Limit Database Memory Utilization: Each user’s login process that connects to the database allocates a small segment of memory to perform connection overhead, sorting, and data caching. Verisign’s standards mandate that no more than 40 percent of the total available physical memory on the database server will be allocated for these functions. 

Verisign’s SRS is built upon a three-tier architecture as illustrated in Attachment 24-1 and detailed here: 

- Gateway Layer: The first tier, the gateway servers, uses EPP to communicate with registrars. These gateway servers then interact with application servers, which comprise the second tier.
- Application Layer: The application servers contain business logic for managing and maintaining the registry business. The business logic is particular to each TLD’s business rules and requirements. The flexible internal design of the application servers allows Verisign to easily leverage existing business rules to apply to the .insurance gTLD. The application servers store FRS’ data in the registry database, which comprises the third and final tier. This simple, industry-standard design has been highly effective with other customers for whom Verisign provides backend registry services.
- Database Layer: The database is the heart of this architecture. It stores all the essential information provisioned from registrars through the gateway servers. Separate servers query the database, extract updated zone and Whois information, validate that information, and distribute it around the clock to Verisign’s worldwide domain name resolution sites.
 
Scalability and Performance. Verisign, FRS’ selected backend registry services provider, implements its scalable SRS on a supportable infrastructure that achieves the availability requirements in Specification 10. Verisign employs the design patterns of simplicity and parallelism in both its software and systems, based on its experience that these factors contribute most significantly to scalability and reliable performance. Going counter to feature-rich development patterns, Verisign intentionally minimizes the number of lines of code between the end user and the data delivered. The result is a network of restorable components that provide rapid, accurate updates. Attachment 24-2 depicts EPP traffic flows and local redundancy in Verisign’s SRS provisioning architecture. As detailed in the figure, local redundancy is maintained for each layer as well as each piece of equipment. This built-in redundancy enhances operational performance while enabling the future system scaling necessary to meet additional demand created by this or future registry applications. 

Besides improving scalability and reliability, local SRS redundancy enables Verisign to take down individual system components for maintenance and upgrades, with little to no performance impact. With Verisign’s redundant design, Verisign can perform routine maintenance while the remainder of the system remains online and unaffected. For the .insurance gTLD registry, this flexibility minimizes unplanned downtime and provides a more consistent end-user experience. 

1.2 Representative Network Diagrams

Attachment 24-3 provides a summary network diagram of FRS’ selected backend registry services provider’s (Verisign’s) SRS. This configuration at both the primary and alternate-primary Verisign data centers provides a highly reliable backup capability. Data is continuously replicated between both sites to ensure failover to the alternate-primary site can be implemented expeditiously to support both planned and unplanned outages. 

1.3 Number of Servers

As FRS’ selected provider of backend registry services, Verisign continually reviews its server deployments for all aspects of its registry service. Verisign evaluates usage based on peak performance objectives as well as current transaction volumes, which drive the quantity of servers in its implementations. Verisign’s scaling is based on the following factors:

- Server configuration is based on CPU, memory, disk IO, total disk, and network throughput projections.
- Server quantity is determined through statistical modeling to fulfill overall performance objectives as defined by both the service availability and the server configuration. 
- To ensure continuity of operations for the .insurance gTLD, Verisign uses a minimum of 100 dedicated servers per SRS site. These servers are virtualized to meet demand. 

1.4 Description of Interconnectivity with Other Registry Systems

Attachment 24-4 provides a technical overview of the FRS’ selected backend registry services provider’s (Verisign’s) SRS, showing how the SRS component fits into this larger system and interconnects with other system components. 
 
1.5 Frequency of Synchronization Between Servers

As FRS’ selected provider of backend registry services, Verisign uses synchronous replication to keep the Verisign SRS continuously in sync between the two data centers. This synchronization is performed in near-real time, thereby supporting rapid failover should a failure occur or a planned maintenance outage be required.

1.6 Synchronization Scheme

Verisign uses synchronous replication to keep the Verisign SRS continuously in sync between the two data centers. Because the alternate-primary site is continuously up, and built using an identical design to the primary data center, it is classified as a “hot standby.” 

2 SCALABILITY AND PERFORMANCE ARE CONSISTENT WITH THE OVERALL BUSINESS APPROACH AND PLANNED SIZE OF THE REGISTRY

Verisign 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 “Total Critical Registry Function Cash Outflows” (Template 1, Line IIb.G) within the Question 46 financial projections response.

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

Verisign, the FRS’ selected provider of backend registry services, 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 provided to FRS fully accounts for this personnel-related cost, 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 SRS performance:

- Application Engineers: 19
- Database Administrators: 8 
- Database Engineers: 3
- Network Administrators: 11 
- Network Architects: 4 
- Project Managers: 25
- Quality Assurance Engineers: 11 
- SRS System Administrators: 13 
- Storage Administrators: 4
- 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.

4 EVIDENCE OF COMPLIANCE WITH SPECIFICATION 6 AND 10 TO THE REGISTRY AGREEMENT

Section 1.2 (EPP) of Specification 6, Registry Interoperability and Continuity Specifications. Verisign, FRS’ selected backend registry services provider, provides these services using its SRS, which complies fully with Specification 6, Section 1.2 of the Registry Agreement. In using its SRS to provide backend registry services, Verisign implements and complies with relevant existing RFCs (i.e., 5730, 5731, 5732, 5733, 5734, and 5910) and intends to comply with RFCs that may be published in the future by the Internet Engineering Task Force (IETF), including successor standards, modifications, or additions thereto relating to the provisioning and management of domain names that use EPP. In addition, Verisign’s SRS includes a Registry Grace Period (RGP) and thus complies with RFC 3915 and its successors. Details of the Verisign SRS’ compliance with RFC SRS⁄EPP are provided in the response to Question 25, Extensible Provisioning Protocol. Verisign does not use functionality outside the base EPP RFCs, although proprietary EPP extensions are documented in Internet-Draft format following the guidelines described in RFC 3735 within the response to Question 25. Moreover, prior to deployment, FRS will provide to ICANN updated documentation of all the EPP objects and extensions supported in accordance with Specification 6, Section 1.2.

Specification 10, EPP Registry Performance Specifications. Verisign’s SRS meets all EPP Registry Performance Specifications detailed in Specification 10, Section 2. Evidence of this performance can be verified by a review of the .com and .net Registry Operator’s Monthly Reports, which Verisign files with ICANN. These reports detail Verisign’s operational status of the .com and .net registries, which use an SRS design and approach comparable to the one proposed for the .insurance gTLD. These reports provide evidence of Verisign’s ability to meet registry operation service level agreements (SLAs) comparable to those detailed in Specification 10. The reports are accessible at the following URL: http:⁄⁄www.icann.org⁄en⁄tlds⁄monthly-reports⁄. 
In accordance with EPP Registry Performance Specifications detailed in Specification 10, Verisignʹs SRS meets the following performance attributes:

- EPP service availability: less than or equal to 864 minutes of downtime (~98%)
- EPP session-command round trip time (RTT): less than or equal to 4000 milliseconds (ms), for at least 90 percent of the commands
- EPP query-command RTT: less than or equal to 2000 ms, for at least 90 percent of the commands
- EPP transform-command RTT: less than or equal to 4000 ms, for at least 90 percent of the commands

1 COMPLETE KNOWLEDGE AND UNDERSTANDING OF THIS ASPECT OF REGISTRY TECHNICAL REQUIREMENTS

Verisign, fTLD Registry Services, LLC’s (FRS) selected backend registry services provider, has used Extensible Provisioning Protocol (EPP) since its inception and possesses complete knowledge and understanding of EPP registry systems. Its first EPP implementation— for a thick registry for the .name generic top-level domain (gTLD)—was in 2002. Since then Verisign has continued its RFC-compliant use of EPP in multiple TLDs, as detailed in Attachment 25-1. 

Verisign’s understanding of EPP and its ability to implement code that complies with the applicable RFCs is unparalleled. Mr. Scott Hollenbeck, Verisign’s director of software development, authored the Extensible Provisioning Protocol and continues to be fully engaged in its refinement and enhancement (U.S. Patent Number 7299299 – Shared registration system for registering domain names). Verisign has also developed numerous new object mappings and object extensions following the guidelines in RFC 3735 (Guidelines for Extending the Extensible Provisioning Protocol). Mr. James Gould, a principal engineer at Verisign, led and co-authored the most recent EPP Domain Name System Security Extensions (DNSSEC) RFC effort (RFC 5910).

All registry systems for which Verisign is the registry operator or provides backend registry services use EPP. Upon approval of this application, Verisign will use EPP to provide the backend registry services for this gTLD. The .com, .net, and .name registries for which Verisign is the registry operator use an SRS design and approach comparable to the one proposed for this gTLD. Approximately 915 registrars use the Verisign EPP service, and the registry system performs more than 140 million EPP transactions daily without performance issues or restrictive maintenance windows. The processing time service level agreement (SLA) requirements for the Verisign-operated .net gTLD are the strictest of the current Verisign managed gTLDs. All processing times for Verisign-operated gTLDs can be found in ICANN’s Registry Operator’s Monthly Reports at http:⁄⁄www.icann.org⁄en⁄tlds⁄monthly-reports⁄. 

Verisign has also been active on the Internet Engineering Task Force (IETF) Provisioning Registry Protocol (provreg) working group and mailing list since work started on the EPP protocol in 2000. This working group provided a forum for members of the Internet community to comment on Mr. Scott Hollenbeck’s initial EPP drafts, which Mr. Hollenbeck refined based on input and discussions with representatives from registries, registrars, and other interested parties. The working group has since concluded, but the mailing list is still active to enable discussion of different aspects of EPP.

1.1 EPP Interface with Registrars

Verisign, FRS’ selected backend registry services provider, fully supports the features defined in the EPP specifications and provides a set of software development kits (SDK) and tools to help registrars build secure and stable interfaces. Verisign’s SDKs give registrars the option of either fully writing their own EPP client software to integrate with the Shared Registration System (SRS), or using the Verisign-provided SDKs to aid them in the integration effort. Registrars can download the Verisign EPP SDKs and tools from the registrar website (http:⁄⁄www.Verisign.com⁄domain-name-services⁄current-registrars⁄epp-sdk⁄index.html). 

The EPP SDKs provide a host of features including connection pooling, Secure Sockets Layer (SSL), and a test server (stub server) to run EPP tests against. One tool—the EPP tool—provides a web interface for creating EPP Extensible Markup Language (XML) commands and sending them to a configurable set of target servers. This helps registrars in creating the template XML and testing a variety of test cases against the EPP servers. An Operational Test and Evaluation (OT&E) environment, which runs the same software as the production system so approved registrars can integrate and test their software before moving into a live production environment, is also available. 

2 TECHNICAL PLAN SCOPE⁄SCALE CONSISTENT WITH THE OVERALL BUSINESS APPROACH AND PLANNED SIZE OF THE REGISTRY

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 “Total Critical Registry Function Cash Outflows” (Template 1, Line IIb.G) within the Question 46 financial projections response.

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

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 the provisioning of EPP services:
- Application Engineers: 19 
- Database Engineers: 3 
- Quality Assurance Engineers: 11 

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 TLD, 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.

4 ABILITY TO COMPLY WITH RELEVANT RFCS 

Verisign, FRS’ selected backend registry services provider, incorporates design reviews, code reviews, and peer reviews into its software development lifecycle (SDLC) to ensure compliance with the relevant RFCs. Verisign’s dedicated QA team creates extensive test plans and issues internal certifications when it has confirmed the accuracy of the code in relation to the RFC requirements. Verisign’s QA organization is independent from the development team within engineering. This separation helps Verisign ensure adopted processes and procedures are followed, further ensuring that all software releases fully consider the security and stability of the TLD. 

For the .insurance gTLD, the Shared Registration System (SRS) complies with the following IETF EPP specifications, where the XML templates and XML schemas are defined in the following specifications:

- EPP RGP 3915 (http:⁄⁄www.apps.ietf.org⁄rfc⁄rfc3915.html): EPP Redemption Grace Period (RGP) Mapping specification for support of RGP statuses and support of Restore Request and Restore Report (authored by Verisign’s Scott Hollenbeck)
- EPP 5730 (http:⁄⁄tools.ietf.org⁄html⁄rfc5730): Base EPP specification (authored by Verisign’s Scott Hollenbeck)
- EPP Domain 5731 (http:⁄⁄tools.ietf.org⁄html⁄rfc5731): EPP Domain Name Mapping specification (authored by Verisign’s Scott Hollenbeck)
- EPP Host 5732 (http:⁄⁄tools.ietf.org⁄html⁄rfc5732): EPP Host Mapping specification (authored by Verisign’s Scott Hollenbeck)
- EPP Contact 5733 (http:⁄⁄tools.ietf.org⁄html⁄rfc5733): EPP Contact Mapping specification (authored by Verisign’s Scott Hollenbeck)
- EPP TCP 5734 (http:⁄⁄tools.ietf.org⁄html⁄rfc5734): EPP Transport over Transmission Control Protocol (TCP) specification (authored by Verisign’s Scott Hollenbeck)
- EPP DNSSEC 5910 (http:⁄⁄tools.ietf.org⁄html⁄rfc5910): EPP Domain Name System Security Extensions (DNSSEC) Mapping specification (authored by Verisign’s James Gould and Scott Hollenbeck)

5 PROPRIETARY EPP EXTENSIONS

Verisign, FRS’ selected backend registry services provider, uses its SRS to provide registry services. The SRS supports the following EPP specifications, which Verisign developed following the guidelines in RFC 3735, where the XML templates and XML schemas are defined in the specifications:

- IDN Language Tag (http:⁄⁄www.verisigninc.com⁄assets⁄idn-language-tag.pdf): EPP internationalized domain names (IDN) language tag extension used for IDN domain name registrations
- RGP Poll Mapping (http:⁄⁄www.verisigninc.com⁄assets⁄whois-info-extension.pdf): EPP mapping for an EPP poll message in support of Restore Request and Restore Report
- Whois Info Extension (http:⁄⁄www.verisigninc.com⁄assets⁄whois-info-extension.pdf): EPP extension for returning additional information needed for transfers
- EPP ConsoliDate Mapping (http:⁄⁄www.verisigninc.com⁄assets⁄consolidate-mapping.txt): EPP mapping to support a Domain Sync operation for synchronizing domain name expiration dates
- NameStore Extension (http:⁄⁄www.verisigninc.com⁄assets⁄namestore-extension.pdf): EPP extension for routing with an EPP intelligent gateway to a pluggable set of backend products and services
- Low Balance Mapping (http:⁄⁄www.verisigninc.com⁄assets⁄low-balance-mapping.pdf): EPP mapping to support low balance poll messages that proactively notify registrars of a low balance (available credit) condition

As part of the 2006 implementation report to bring the EPP RFC documents from Proposed Standard status to Draft Standard status, an implementation test matrix was completed. Two independently developed EPP client implementations based on the RFCs were tested against the Verisign EPP server for the domain, host, and contact transactions. No compliance-related issues were identified during this test, providing evidence that these extensions comply with RFC 3735 guidelines and further demonstrating Verisign’s ability to design, test, and deploy an RFC-compliant EPP implementation.

5.1 EPP Templates and Schemas

The EPP XML schemas are formal descriptions of the EPP XML templates. They are used to express the set of rules to which the EPP templates must conform in order to be considered valid by the schema. The EPP schemas define the building blocks of the EPP templates, describing the format of the data and the different EPP commands’ request and response formats. The current EPP implementations managed by Verisign, FRS’ selected backend registry services provider, use these EPP templates and schemas, as will the proposed TLD. For each proprietary XML template⁄schema Verisign provides a reference to the applicable template and includes the schema.


XML templates⁄schema for idnLang-1.0
- Template: The templates for idnLang-1.0 can be found in Chapter 3, EPP Command Mapping of the relevant EPP documentation, http:⁄⁄www.verisigninc.com⁄assets⁄idn-language-tag.pdf. 
- Schema: This schema describes the extension mapping for the IDN language tag. The mapping extends the EPP domain name mapping to provide additional features required for the provisioning of IDN domain name registrations.

〈?xml version=ʺ1.0ʺ encoding=ʺUTF-8ʺ?〉

〈schema targetNamespace=ʺhttp:⁄⁄www.Verisign.com⁄epp⁄idnLang-1.0ʺ
 xmlns:idnLang=ʺhttp:⁄⁄www.Verisign.com⁄epp⁄idnLang-1.0ʺ
 xmlns=ʺhttp:⁄⁄www.w3.org⁄2001⁄XMLSchemaʺ
 elementFormDefault=ʺqualifiedʺ〉

〈annotation〉
 〈documentation〉
 Extensible Provisioning Protocol v1.0 domain name
 extension schema for IDN Lang Tag.
 〈⁄documentation〉
〈⁄annotation〉

〈!--
Child elements found in EPP commands.
--〉
 〈element name=ʺtagʺ type=ʺlanguageʺ⁄〉

 〈!--
 End of schema.
 --〉
〈⁄schema〉


XML templates⁄schema for rgp-poll-1.0
- Template: The templates for rgp-poll-1.0 can be found in Chapter 3, EPP Command Mapping of the relevant EPP documentation, http:⁄⁄www.verisigninc.com⁄assets⁄rgp-poll-mapping.pdf.
- Schema: This schema describes the extension mapping for poll notifications. The mapping extends the EPP base mapping to provide additional features for registry grace period (RGP) poll notifications.

〈?xml version=ʺ1.0ʺ encoding=ʺUTF-8ʺ?〉

〈schema targetNamespace=ʺhttp:⁄⁄www.Verisign.com⁄epp⁄rgp-poll-1.0ʺ
 xmlns:rgp-poll=ʺhttp:⁄⁄www.Verisign.com⁄epp⁄rgp-poll-1.0ʺ
 xmlns:eppcom=ʺurn:ietf:params:xml:ns:eppcom-1.0ʺ
 xmlns:rgp=ʺurn:ietf:params:xml:ns:rgp-1.0ʺ
 xmlns=ʺhttp:⁄⁄www.w3.org⁄2001⁄XMLSchemaʺ
 elementFormDefault=ʺqualifiedʺ〉

〈!--
Import common element types.
--〉
〈import namespace=ʺurn:ietf:params:xml:ns:eppcom-1.0ʺ
 schemaLocation=ʺeppcom-1.0.xsdʺ⁄〉
〈import namespace=ʺurn:ietf:params:xml:ns:rgp-1.0ʺ
 schemaLocation=ʺrgp-1.0.xsdʺ⁄〉

〈annotation〉
 〈documentation〉
 Extensible Provisioning Protocol v1.0
 Verisign poll notification specification for registry grace period
 poll notifications.
 〈⁄documentation〉
〈⁄annotation〉

〈!--
Child elements found in EPP commands.
--〉
〈element name=ʺpollDataʺ type=ʺrgp-poll:pollDataTypeʺ⁄〉

〈!--
Child elements of the 〈notifyData〉 element for the
redemption grace period.
--〉
〈complexType name=ʺpollDataTypeʺ〉
 〈sequence〉
 〈element name=ʺnameʺ type=ʺeppcom:labelTypeʺ⁄〉
 〈element name=ʺrgpStatusʺ type=ʺrgp:statusTypeʺ⁄〉
 〈element name=ʺreqDateʺ type=ʺdateTimeʺ⁄〉
 〈element name=ʺreportDueDateʺ type=ʺdateTimeʺ⁄〉
 〈⁄sequence〉
〈⁄complexType〉
〈
!--
End of schema.
--〉
〈⁄schema〉


XML templates⁄schema for whoisInf-1.0
- Template: The templates for whoisInf-1.0 can be found in Chapter 3, EPP Command Mapping of the relevant EPP documentation, http:⁄⁄www.verisigninc.com⁄assets⁄whois-info-extension.pdf.
- Schema: This schema describes the extension mapping for the Whois Info extension. The mapping extends the EPP domain name mapping to provide additional features for returning additional information needed for transfers.

〈?xml version=ʺ1.0ʺ encoding=ʺUTF-8ʺ?〉

〈schema targetNamespace=ʺhttp:⁄⁄www.Verisign.com⁄epp⁄whoisInf-1.0ʺ
 xmlns:whoisInf=ʺhttp:⁄⁄www.Verisign.com⁄epp⁄whoisInf-1.0ʺ
 xmlns:eppcom=ʺurn:ietf:params:xml:ns:eppcom-1.0ʺ
 xmlns=ʺhttp:⁄⁄www.w3.org⁄2001⁄XMLSchemaʺ
 elementFormDefault=ʺqualifiedʺ〉

〈import namespace=ʺurn:ietf:params:xml:ns:eppcom-1.0ʺ
 schemaLocation=ʺeppcom-1.0.xsdʺ⁄〉

〈annotation〉
 〈documentation〉
 Extensible Provisioning Protocol v1.0
 extension schema for Whois Info
 〈⁄documentation〉
〈⁄annotation〉

〈!--
Possible Whois Info extension root elements.
--〉
〈element name=ʺwhoisInfʺ type=ʺwhoisInf:whoisInfTypeʺ⁄〉
〈element name=ʺwhoisInfDataʺ type=ʺwhoisInf:whoisInfDataTypeʺ⁄〉

〈!--
Child elements for the 〈whoisInf〉 extension which
is used as an extension to an info command.
--〉
〈complexType name=ʺwhoisInfTypeʺ〉
 〈sequence〉
 〈element name=ʺflagʺ type=ʺbooleanʺ⁄〉
 〈⁄sequence〉
〈⁄complexType〉

〈!--
Child elements for the 〈whoisInfData〉 extension which
is used as an extension to the info response.
--〉
〈complexType name=ʺwhoisInfDataTypeʺ〉
 〈sequence〉
 〈element name=ʺregistrarʺ type=ʺstringʺ⁄〉
 〈element name=ʺwhoisServerʺ type=ʺeppcom:labelTypeʺ
 minOccurs=ʺ0ʺ⁄〉
 〈element name=ʺurlʺ type=ʺtokenʺ minOccurs=ʺ0ʺ⁄〉
 〈element name=ʺirisServerʺ type=ʺeppcom:labelTypeʺ
 minOccurs=ʺ0ʺ⁄〉
 〈⁄sequence〉
 〈⁄complexType〉

〈⁄schema〉


XML templates⁄schema for sync-1.0 (consoliDate)
- Template: The templates for sync-1.0 can be found in Chapter 3, EPP Command Mapping of the relevant EPP documentation, http:⁄⁄www.verisigninc.com⁄assets⁄consolidate-mapping.txt.
- Schema: This schema describes the extension mapping for the synchronization of domain name registration period expiration dates. This service is known as ʺConsoliDate.ʺ The mapping extends the EPP domain name mapping to provide features that allow a protocol client to end a domain name registration period on a specific month and day.


 〈?xml version=ʺ1.0ʺ encoding=ʺUTF-8ʺ?〉

 〈schema targetNamespace=ʺhttp:⁄⁄www.Verisign.com⁄epp⁄sync-1.0ʺ
 xmlns:sync=ʺhttp:⁄⁄www.Verisign.com⁄epp⁄sync-1.0ʺ
 xmlns=ʺhttp:⁄⁄www.w3.org⁄2001⁄XMLSchemaʺ
 elementFormDefault=ʺqualifiedʺ〉

 〈annotation〉
 〈documentation〉
 Extensible Provisioning Protocol v1.0 domain name
 extension schema for expiration date synchronization.
 〈⁄documentation〉
 〈⁄annotation〉

 〈!--
 Child elements found in EPP commands.
 --〉
 〈element name=ʺupdateʺ type=ʺsync:updateTypeʺ⁄〉

 〈!--
 Child elements of the 〈update〉 command.
 --〉
 〈complexType name=ʺupdateTypeʺ〉
 〈sequence〉
 〈element name=ʺexpMonthDayʺ type=ʺgMonthDayʺ⁄〉
 〈⁄sequence〉
 〈⁄complexType〉

 〈!--
 End of schema.
 --〉
 〈⁄schema〉


XML templates⁄schema for namestoreExt-1.1
- Template: The templates for namestoreExt-1.1 can be found in Chapter 3, EPP Command Mapping of the relevant EPP documentation, http:⁄⁄www.verisigninc.com⁄assets⁄namestore-extension.pdf.
- Schema: This schema describes the extension mapping for the routing with an EPP intelligent gateway to a pluggable set of backend products and services. The mapping extends the EPP domain name and host mapping to provide a sub-product identifier to identify the target sub-product that the EPP operation is intended for.

〈?xml version=ʺ1.0ʺ encoding=ʺUTF-8ʺ?〉

〈schema targetNamespace=ʺhttp:⁄⁄www.Verisign-grs.com⁄epp⁄namestoreExt-1.1ʺ
 xmlns=ʺhttp:⁄⁄www.w3.org⁄2001⁄XMLSchemaʺ
 xmlns:namestoreExt=ʺhttp:⁄⁄www.Verisign-grs.com⁄epp⁄namestoreExt-1.1ʺ
 elementFormDefault=ʺqualifiedʺ〉

〈annotation〉
 〈documentation〉
 Extensible Provisioning Protocol v1.0 Namestore extension schema
 for destination registry routing.
 〈⁄documentation〉
〈⁄annotation〉

〈!-- General Data types. --〉
〈simpleType name=ʺsubProductTypeʺ〉
 〈restriction base=ʺtokenʺ〉
 〈minLength value=ʺ1ʺ⁄〉
 〈maxLength value=ʺ64ʺ⁄〉
 〈⁄restriction〉
〈⁄simpleType〉

〈complexType name=ʺextAnyTypeʺ〉
 〈sequence〉
 〈any namespace=ʺ##otherʺ maxOccurs=ʺunboundedʺ⁄〉
 〈⁄sequence〉
〈⁄complexType〉

〈!-- Child elements found in EPP commands and responses. --〉
〈element name=ʺnamestoreExtʺ type=ʺnamestoreExt:namestoreExtTypeʺ⁄〉

〈!-- Child elements of the 〈product〉 command. --〉
〈complexType name=ʺnamestoreExtTypeʺ〉
 〈sequence〉
 〈element name=ʺsubProductʺ
 type=ʺnamestoreExt:subProductTypeʺ⁄〉
 〈⁄sequence〉
〈⁄complexType〉

〈!-- Child response elements. --〉
〈element name=ʺnsExtErrDataʺ type=ʺnamestoreExt:nsExtErrDataTypeʺ⁄〉

〈!-- 〈prdErrData〉 error response elements. --〉
〈complexType name=ʺnsExtErrDataTypeʺ〉
 〈sequence〉
 〈element name=ʺmsgʺ type=ʺnamestoreExt:msgTypeʺ⁄〉
 〈⁄sequence〉
 〈⁄complexType〉

〈!-- 〈prdErrData〉 〈msg〉 element. --〉
〈complexType name=ʺmsgTypeʺ〉
 〈simpleContent〉
 〈extension base=ʺnormalizedStringʺ〉
 〈attribute name=ʺcodeʺ
 type=ʺnamestoreExt:prdErrCodeTypeʺ use=ʺrequiredʺ⁄〉
 〈attribute name=ʺlangʺ type=ʺlanguageʺ default=ʺenʺ⁄〉
 〈⁄extension〉
 〈⁄simpleContent〉
〈⁄complexType〉

〈!-- 〈prdErrData〉 error response codes. --〉
〈simpleType name=ʺprdErrCodeTypeʺ〉
 〈restriction base=ʺunsignedShortʺ〉
 〈enumeration value=ʺ1ʺ⁄〉
 〈⁄restriction〉
〈⁄simpleType〉

〈!-- End of schema. --〉
〈⁄schema〉

XML templates⁄schema for lowbalance-poll-1.0
- Template: The templates for lowbalance-poll-1.0 can be found in Chapter 3, EPP Command Mapping of the relevant EPP documentation, http:⁄⁄www.verisigninc.com⁄assets⁄low-balance-mapping.pdf.
- Schema: This schema describes the extension mapping for the account low balance notification. The mapping extends the EPP base mapping so an account holder can be notified via EPP poll messages whenever the available credit for an account reaches or goes below the credit threshold.

〈?xml version=ʺ1.0ʺ encoding=ʺUTF-8ʺ?〉

〈schema targetNamespace=ʺhttp:⁄⁄www.Verisign.com⁄epp⁄lowbalance-poll-1.0ʺ
 xmlns:lowbalance-poll=ʺhttp:⁄⁄www.Verisign.com⁄epp⁄lowbalance-poll-1.0ʺ
 xmlns:eppcom=ʺurn:ietf:params:xml:ns:eppcom-1.0ʺ
 xmlns=ʺhttp:⁄⁄www.w3.org⁄2001⁄XMLSchemaʺ
 elementFormDefault=ʺqualifiedʺ〉

〈!-- Import common element types.--〉
〈import namespace=ʺurn:ietf:params:xml:ns:eppcom-1.0ʺ
 schemaLocation=ʺeppcom-1.0.xsdʺ⁄〉

〈annotation〉
 〈documentation〉
 Extensible Provisioning Protocol v1.0
 Verisign poll notification specification for low balance notifications.
 〈⁄documentation〉
〈⁄annotation〉

〈!--Child elements found in EPP commands.--〉
〈element name=ʺpollDataʺ type=ʺlowbalance-poll:pollDataTypeʺ⁄〉

〈!--Child elements of the 〈notifyData〉 element for the low balance.--〉
〈complexType name=ʺpollDataTypeʺ〉
 〈sequence〉
 〈element name=ʺregistrarNameʺ type=ʺeppcom:labelTypeʺ⁄〉
 〈element name=ʺcreditLimitʺ type=ʺnormalizedStringʺ⁄〉
 〈element name=ʺcreditThresholdʺ
 type=ʺlowbalance-poll:thresholdTypeʺ⁄〉
 〈element name=ʺavailableCreditʺ type=ʺnormalizedStringʺ⁄〉
 〈⁄sequence〉
〈⁄complexType〉

〈complexType name=ʺthresholdTypeʺ〉
 〈simpleContent〉
 〈extension base=ʺnormalizedStringʺ〉
 〈attribute name=ʺtypeʺ
 type=ʺlowbalance-poll:thresholdValueTypeʺ
 use=ʺrequiredʺ⁄〉
 〈⁄extension〉
 〈⁄simpleContent〉
〈⁄complexType〉

〈simpleType name=ʺthresholdValueTypeʺ〉
 〈restriction base=ʺtokenʺ〉
 〈enumeration value=ʺFIXEDʺ⁄〉
 〈enumeration value=ʺPERCENTʺ⁄〉
 〈⁄restriction〉
〈⁄simpleType〉

〈!-- End of schema.--〉
〈⁄schema〉

6 PROPRIETARY EPP EXTENSION CONSISTENCY WITH REGISTRATION LIFECYCLE 

FRS’ selected backend registry services provider’s (Verisign’s) proprietary EPP extensions, defined in Section 5 above, are consistent with the registration lifecycle documented in the response to Question 27, Registration Lifecycle. Details of the registration lifecycle are presented in that response. As new registry features are required, Verisign develops proprietary EPP extensions to address new operational requirements. Consistent with ICANN procedures Verisign adheres to all applicable Registry Services Evaluation Process (RSEP) procedures. 

1 COMPLETE KNOWLEDGE AND UNDERSTANDING OF THIS ASPECT OF REGISTRY TECHNICAL REQUIREMENTS

Verisign, fTLD Registry Services, LLC’s (FRS) selected backend registry services provider, has operated the Whois lookup service for the gTLDs and ccTLDs it manages since 1991, and will provide these proven services for the .insurance gTLD registry. In addition, it continues to work with the Internet community to improve the utility of Whois data, while thwarting its application for abusive uses.

1.1 High-Level Whois System Description

Like all other components of FRS’ selected backend registry services provider’s (Verisign’s) registry service, Verisign’s Whois system is designed and built for both reliability and performance in full compliance with applicable RFCs. Verisign’s current Whois implementation has answered more than five billion Whois queries per month for the TLDs it manages, and has experienced more than 250,000 queries per minute in peak conditions. The proposed gTLD uses a Whois system design and approach that is comparable to the current implementation. Independent quality control testing ensures Verisign’s Whois service is RFC-compliant through all phases of its lifecycle. 

Verisignʹs redundant Whois databases further contribute to overall system availability and reliability. The hardware and software for its Whois service is architected to scale both horizontally (by adding more servers) and vertically (by adding more CPUs and memory to existing servers) to meet future need.

Verisign can fine-tune access to its Whois database on an individual Internet Protocol (IP) address basis, and it works with registrars to help ensure their services are not limited by any restriction placed on Whois. Verisign provides near real-time updates for Whois services for the TLDs under its management. As information is updated in the registration database, it is propagated to the Whois servers for quick publication. These updates align with the near real-time publication of Domain Name System (DNS) information as it is updated in the registration database. This capability is important for the .insurance gTLD registry as it is Verisign’s experience that when DNS data is updated in near real time, so should Whois data be updated to reflect the registration specifics of those domain names.

Verisign’s Whois response time has been less than 500 milliseconds for 95 percent of all Whois queries in .com, .net, .tv, and .cc. The response time in these TLDs, combined with Verisign’s capacity, enables the Whois system to respond to up to 30,000 searches (or queries) per second for a total capacity of 2.6 billion queries per day.
The Whois software written by Verisign complies with RFC 3912. Verisign uses an advanced in-memory database technology to provide exceptional overall system performance and security. In accordance with RFC 3912, Verisign provides a website at whois.nic.〈TLD〉 that provides free public query-based access to the registration data. 
Verisign currently operates both thin and thick Whois systems. 
Verisign commits to implementing a RESTful Whois service upon finalization of agreements with the IETF (Internet Engineering Task Force).

Provided Functionalities for User Interface

To use the Whois service via port 43, the user enters the applicable parameter on the command line as illustrated here:
- For domain name: whois EXAMPLE.TLD
- For registrar: whois ʺregistrar Example Registrar, Inc.ʺ
- For name server: whois ʺNS1.EXAMPLE.TLDʺ or whois ʺname server (IP address)ʺ

To use the Whois service via the web-based directory service search interface:
- Go to http:⁄⁄whois.nic.〈TLD〉
- Click on the appropriate button (Domain, Registrar, or Name Server)
- Enter the applicable parameter:
 o Domain name, including the TLD (e.g., EXAMPLE.TLD)
 o Full name of the registrar, including punctuation (e.g., Example Registrar, Inc.)
 o Full host name or the IP address (e.g., NS1.EXAMPLE.TLD or 198.41.3.39)
- Click on the Submit button.

Provisions to Ensure That Access Is Limited to Legitimate Authorized Users and Is in Compliance with Applicable Privacy Laws or Policies

To further promote reliable and secure Whois operations, Verisign, FRS’ selected backend registry services provider, has implemented rate-limiting characteristics within the Whois service software. For example, to prevent data mining or other abusive behavior, the service can throttle a specific requestor if the query rate exceeds a configurable threshold. In addition, QoS technology enables rate limiting of queries before they reach the servers, which helps protect against denial of service (DoS) and distributed denial of service (DDoS) attacks. 

Verisign’s software also permits restrictions on search capabilities. For example, wild card searches can be disabled. If needed, it is possible to temporarily restrict and⁄or block requests coming from specific IP addresses for a configurable amount of time. Additional features that are configurable in the Whois software include help files, headers and footers for Whois query responses, statistics, and methods to memory map the database. Furthermore, Verisign is European Union (EU) Safe Harbor certified and has worked with European data protection authorities to address applicable privacy laws by developing a tiered Whois access structure that requires users who require access to more extensive data to (i) identify themselves, (ii) confirm that their use is for a specified purpose and (iii) enter into an agreement governing their use of the more extensive Whois data. 

1.2 Relevant Network Diagrams

Attachment 26-1 provides a summary network diagram of the Whois service provided by Verisign, FRS’ selected backend registry services provider. The figure details the configuration with one resolution⁄Whois site. For the .insurance gTLD Verisign provides Whois service from 6 of its 17 primary sites based on the proposed gTLD’s traffic volume and patterns. A functionally equivalent resolution architecture configuration exists at each Whois site. 

1.3 IT and Infrastructure Resources

Attachment 26-2 summarizes the IT and infrastructure resources that Verisign, FRS’ selected backend registry services provider, uses to provision Whois services from Verisign primary resolution sites. As needed, virtual machines are created based on actual and projected demand.

1.4 Description of Interconnectivity with Other Registry Systems

Attachment 26-3 provides a technical overview of the registry system provided by Verisign, FRS’ selected backend registry services provider, and shows how the Whois service component fits into this larger system and interconnects with other system components. 

1.5 Frequency of Synchronization Between Servers

Synchronization between the SRS and the geographically distributed Whois resolution sites occurs approximately every three minutes. Verisign, FRS’ selected backend registry services provider, uses a two-part Whois update process to ensure Whois data is accurate and available. Every 12 hours an initial file is distributed to each resolution site. This file is a complete copy of all Whois data fields associated with each domain name under management. As interactions with the SRS cause the Whois data to be changed, these incremental changes are distributed to the resolution sites as an incremental file update. This incremental update occurs approximately every three minutes. When the new 12-hour full update is distributed, this file includes all past incremental updates. Verisign’s approach to frequency of synchronization between servers meets the Performance Specifications defined in Specification 10 of the Registry Agreement for new gTLDs. 

2 TECHNICAL PLAN SCOPE⁄SCALE CONSISTENT WITH THE OVERALL BUSINESS APPROACH AND PLANNED SIZE OF THE REGISTRY

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 “Total Critical Registry Function Cash Outflows” (Template 1, Line IIb.G) within the Question 46 financial projections response.

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

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 Whois services:
- Application Engineers: 19
- Database Engineers: 3
- Quality Assurance Engineers: 11

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.

4 COMPLIANCE WITH RELEVANT RFC

FRS’ selected backend registry services provider’s (Verisign’s) Whois service complies with the data formats defined in Specification 4 of the Registry Agreement. Verisign will provision Whois services for registered domain names and associated data in the top-level domain (TLD). Verisign’s Whois services are accessible over Internet Protocol version 4 (IPv4) and Internet Protocol version 6 (IPv6), via both Transmission Control Protocol (TCP) port 43 and a web-based directory service at whois.nic.〈TLD〉, which in accordance with RFC 3912, provides free public query-based access to domain name, registrar, and name server lookups. Verisign’s proposed Whois system meets all requirements as defined by ICANN for each registry under Verisign management. Evidence of this successful implementation, and thus compliance with the applicable RFCs, can be verified by a review of the .com and .net Registry Operator’s Monthly Reports that Verisign files with ICANN. These reports provide evidence of Verisign’s ability to meet registry operation service level agreements (SLAs) comparable to those detailed in Specification 10. The reports are accessible at the following URL: http:⁄⁄www.icann.org⁄en⁄tlds⁄monthly-reports⁄. 

5 COMPLIANCE WITH SPECIFICATIONS 4 AND 10 OF REGISTRY AGREEMENT

In accordance with Specification 4, Verisign, FRS’ selected backend registry services provider, provides a Whois service that is available via both port 43 in accordance with RFC 3912, and a web-based directory service at whois.nic.〈TLD〉 also in accordance with RFC 3912, thereby providing free public query-based access. Verisign acknowledges that ICANN reserves the right to specify alternative formats and protocols, and upon such specification, Verisign will implement such alternative specification as soon as reasonably practicable.

The format of the following data fields conforms to the mappings specified in Extensible Provisioning Protocol (EPP) RFCs 5730 – 5734 so the display of this information (or values returned in Whois responses) can be uniformly processed and understood: domain name status, individual and organizational names, address, street, city, state⁄province, postal code, country, telephone and fax numbers, email addresses, date, and times.

Specifications for data objects, bulk access, and lookups comply with Specification 4 and are detailed in the following subsections, provided in both bulk access and lookup modes. 

Bulk Access Mode. This data is provided on a daily schedule to a party designated from time to time in writing by ICANN. The specification of the content and format of this data, and the procedures for providing access, shall be as stated below, until revised in the ICANN Registry Agreement. 

The data is provided in three files:
- Domain Name File: For each domain name, the file provides the domain name, server name for each name server, registrar ID, and updated date.
- Name Server File: For each registered name server, the file provides the server name, each IP address, registrar ID, and updated date.
- Registrar File: For each registrar, the following data elements are provided: registrar ID, registrar address, registrar telephone number, registrar email address, Whois server, referral URL, updated date, and the name, telephone number, and email address of all the registrarʹs administrative, billing, and technical contacts.

Lookup Mode. Attachment 26-4 through Attachment 26-6 provide the query and response format for domain name, registrar, and name server data objects.

5.1 Specification 10, RDDS Registry Performance Specifications

The Whois service meets all registration data directory services (RDDS) registry performance specifications detailed in Specification 10, Section 2. Evidence of this performance can be verified by a review of the .com and .net Registry Operator’s Monthly Reports that Verisign files monthly with ICANN. These reports are accessible from the ICANN website at the following URL: http:⁄⁄www.icann.org⁄en⁄tlds⁄monthly-reports⁄. 

In accordance with RDDS registry performance specifications detailed in Specification 10, Verisignʹs Whois service meets the following proven performance attributes:
- RDDS availability: less than or equial to 864 min of downtime (~98%)
- RDDS query RTT: less than or equal to 2000 ms, for at least 95% of the queries
- RDDS update time: less than or equal to 60 min, for at least 95% of the probes

6 SEARCHABLE WHOIS

Verisign, FRS’ selected backend registry services provider, provides a searchable Whois service for the .insurance gTLD. Verisign has experience in providing tiered access to Whois for the .name registry, and uses these methods and control structures to help reduce potential malicious use of the function. The searchable Whois system currently uses Apache’s Lucene full text search engine to index relevant Whois content with near-real time incremental updates from the provisioning system.

Features of the Verisign searchable Whois function include:

- Provision of a web-based searchable directory service
- Ability to perform partial match, at least, for the following data fields: domain name, contacts and registrant’s name, and contact and registrant’s postal address, including all the sub-fields described in EPP (e.g., street, city, state, or province)
- Ability to perform exact match, at least, on the following fields: registrar ID, name server name, and name server’s IP address (only applies to IP addresses stored by the registry, i.e., glue records)
- Ability to perform Boolean search supporting, at least, the following logical operators to join a set of search criteria: AND, OR, NOT 
- Search results that include domain names that match the selected search criteria

Verisign’s implementation of searchable Whois is EU Safe Harbor certified and includes appropriate access control measures that help ensure that only legitimate authorized users can use the service. Furthermore, Verisign’s compliance office monitors current ICANN policy and applicable privacy laws or policies to help ensure the solution is maintained within compliance of applicable regulations. Features of these access control measures include: 

- All unauthenticated searches are returned as thin results.
- Registry system authentication is used to grant access to appropriate users for thick Whois data search results.
- Account access is granted by the FRS’ defined .insurance gTLD admin user.

Potential Forms of Abuse and Related Risk Mitigation. Leveraging its experience providing tiered access to Whois for the .name registry and interacting with ICANN, data protection authorities, and applicable industry groups, Verisign, FRS’ selected backend registry services provider, is knowledgeable of the likely data mining forms of abuse associated with a searchable Whois service. Attachment 26-7 summarizes these potential forms of abuse and Verisign’s approach to mitigate the identified risk. 

1 COMPLETE KNOWLEDGE AND UNDERSTANDING OF REGISTRATION LIFECYCLES AND STATES

Starting with domain name registration and continuing through domain name delete operations, fTLD Registry Services, LLC’s (FRS) selected backend registry services provider’s (Verisign’s) registry implements the full registration lifecycle for domain names supporting the operations in the Extensible Provisioning Protocol (EPP) specification. The registration lifecycle of the domain name starts with registration and traverses various states as specified in the following sections. The registry system provides options to update domain names with different server and client status codes that block operations based on the EPP specification. The system also provides different grace periods for different billable operations, where the price of the billable operation is credited back to the registrar if the billable operation is removed within the grace period. Together Attachment 27-1 and Attachment 27-2 define the registration states comprising the registration lifecycle and explain the trigger points that cause state-to-state transitions. States are represented as green rectangles within Attachment 27-1.

1.1 Registration Lifecycle of Create⁄Update⁄Delete

The following section details the create⁄update⁄delete processes and the related renewal process that Verisign, FRS’ selected backend registry services provider, follows. For each process, this response defines the process function and its characterization, and as appropriate provides a process flow chart. 

Create Process. The domain name lifecycle begins with a registration or what is referred to as a Domain Name Create operation in EPP. The system fully supports the EPP Domain Name Mapping as defined by RFC 5731, where the associated objects (e.g., hosts and contacts) are created independent of the domain name.

Process Characterization. The Domain Name Create command is received, validated, run through a set of business rules, persisted to the database, and committed in the database if all business rules pass. The domain name is included with the data flow to the DNS and Whois resolution services. If no name servers are supplied, the domain name is not included with the data flow to the DNS. A successfully created domain name has the created date and expiration date set in the database. Creates are subject to grace periods as described in Section 1.3 of this response, Add Grace Period, Redemption Grace Period, and Notice Periods for Renewals or Transfers. 

The Domain Name Create operation is detailed in Attachment 27-3 and requires the following attributes:
- A domain name that meets the string restrictions.
- A domain name that does not already exist.
- The registrar is authorized to create a domain name in .insurance.
- The registrar has available credit.
- A valid Authorization Information (Auth-Info) value.
- Required contacts (e.g., registrant, administrative contact, technical contact, and billing contact) are specified and exist.
- The specified name servers (hosts) exist, and there is a maximum of 13 name servers.
- A period in units of years with a maximum value of 10 (default period is one year).
Renewal Process. The domain name can be renewed unless it has any form of Pending Delete, Pending Transfer, or Renew Prohibited.

A request for renewal that sets the expiry date to more than ten years in the future is denied. The registrar must pass the current expiration date (without the timestamp) to support the idempotent features of EPP, where sending the same command a second time does not cause unexpected side effects.

Automatic renewal occurs when a domain name expires. On the expiration date, the registry extends the registration period one year and debits the registrar account balance. In the case of an auto-renewal of the domain name, a separate Auto-Renew grace period applies. Renewals are subject to grace periods as described in Section 1.3 of this response, Add Grace Period, Redemption Grace Period, and Notice Periods for Renewals or Transfers.

Process Characterization. The Domain Name Renew command is received, validated, authorized, and run through a set of business rules. The data is updated and committed in the database if it passes all business rules. The updated domain name’s expiration date is included in the flow to the Whois resolution service. 

The Domain Name Renew operation is detailed in Attachment 27-4 and requires the following attributes:
- A domain name that exists and is sponsored by the requesting registrar.
- The registrar is authorized to renew a domain name in .insurance.
- The registrar has available credit.
- The passed current expiration date matches the domain name’s expiration date.
- A period in units of years with a maximum value of 10 (default period is one year). A domain name expiry past ten years is not allowed.

Registrar Transfer Procedures. A registrant may transfer his⁄her domain name from his⁄her current registrar to another registrar. The database system allows a transfer as long as the transfer is not within the initial 60 days, per industry standard, of the original registration date. 

The registrar transfer process goes through many process states, which are described in detail below, unless it has any form of Pending Delete, Pending Transfer, or Transfer Prohibited.

A transfer can only be initiated when the appropriate Auth-Info is supplied. The Auth-Info for transfer is only available to the current registrar. Any other registrar requesting to initiate a transfer on behalf of a registrant must obtain the Auth-Info from the registrant.

The Auth-Info is made available to the registrant upon request. The registrant is the only party other than the current registrar that has access to the Auth-Info. Registrar transfer entails a specified extension of the expiry date for the object. The registrar transfer is a billable operation and is charged identically to a renewal for the same extension of the period. This period can be from one to ten years, in one-year increments.

Because registrar transfer involves an extension of the registration period, the rules and policies applying to how the resulting expiry date is set after transfer are based on the renewal policies on extension.

Per industry standard, a domain name cannot be transferred to another registrar within the first 60 days after registration. This restriction continues to apply if the domain name is renewed during the first 60 days. Transfer of the domain name changes the sponsoring registrar of the domain name, and also changes the child hosts (ns1.sample.xyz) of the domain name (sample .xyz). 

The domain name transfer consists of five separate operations:
- Transfer Request (Attachment 27-5): Executed by a non-sponsoring registrar with the valid Auth-Info provided by the registrant. The Transfer Request holds funds of the requesting registrar but does not bill the registrar until the transfer is completed. The sponsoring registrar receives a Transfer Request poll message.
- Transfer Cancel (Attachment 27-6): Executed by the requesting registrar to cancel the pending transfer. The held funds of the requesting registrar are reversed. The sponsoring registrar receives a Transfer Cancel poll message.
- Transfer Approve (Attachment 27-7): Executed by the sponsoring registrar to approve the Transfer Request. The requesting registrar is billed for the Transfer Request and the sponsoring registrar is credited for an applicable Auto-Renew grace period. The requesting registrar receives a Transfer Approve poll message.
- Transfer Reject (Attachment 27-8): Executed by the sponsoring registrar to reject the pending transfer. The held funds of the requesting registrar are reversed. The requesting registrar receives a Transfer Reject poll message.
- Transfer Query (Attachment 27-9): Executed by either the requesting registrar or the sponsoring registrar of the last transfer.

The registry auto-approves a transfer if the sponsoring registrar takes no action. The requesting registrar is billed for the Transfer Request and the sponsoring registrar is credited for an applicable Auto-Renew grace period. The requesting registrar and the sponsoring registrar receive a Transfer Auto-Approve poll message. 

Delete Process. A registrar may choose to delete the domain name at any time. 

Process Characterization. The domain name can be deleted, unless it has any form of Pending Delete, Pending Transfer, or Delete Prohibited.

A domain name is also prohibited from deletion if it has any in-zone child hosts that are name servers for domain names. For example, the domain name “sample.xyz” cannot be deleted if an in-zone host “ns.sample.xyz” exists and is a name server for “sample2.xyz.”

If the Domain Name Delete occurs within the Add grace period, the domain name is immediately deleted and the sponsoring registrar is credited for the Domain Name Create. If the Domain Name Delete occurs outside the Add grace period, it follows the Redemption grace period (RGP) lifecycle.

Update Process. The sponsoring registrar can update the following attributes of a domain name:
- Auth-Info
- Name servers
- Contacts (i.e., registrant, administrative contact, technical contact, and billing contact)
- Statuses (e.g., Client Delete Prohibited, Client Hold, Client Renew Prohibited, Client Transfer Prohibited, Client Update Prohibited)

Process Characterization. Updates are allowed provided that the update includes the removal of any Update Prohibited status. The Domain Name Update operation is detailed in Attachment 27-10. 

A domain name can be updated unless it has any form of Pending Delete, Pending Transfer, or Update Prohibited.
 
1.2 Pending, Locked, Expired, and Transferred 

Verisign, FRS’ selected backend registry services provider, handles pending, locked, expired, and transferred domain names as described here. When the domain name is deleted after the five-day Add grace period, it enters into the Pending Delete state. The registrant can return its domain name to active any time within the five-day Pending Delete grace period. After the five-day Pending Delete grace period expires, the domain name enters the Redemption Pending state and then is deleted by the system. The registrant can restore the domain name at any time during the Redemption Pending state.

When a non-sponsoring registrar initiates the domain name transfer request, the domain name enters Pending Transfer state and a notification is mailed to the sponsoring registrar for approvals. If the sponsoring registrar doesn’t respond within five days, the Pending Transfer expires and the transfer request is automatically approved.

EPP specifies both client (registrar) and server (registry) status codes that can be used to prevent registry changes that are not intended by the registrant. Currently, many registrars use the client status codes to protect against inadvertent modifications that would affect their customers’ high-profile or valuable domain names. 

Verisign’s registry service supports the following client (registrar) and server (registry) status codes:
- clientHold
- clientRenewProhibited
- clientTransferProhibited
- clientUpdateProhibited
- clientDeleteProhibited
- serverHold
- serverRenewProhibited
- serverTransferProhibited
- serverUpdateProhibited
- serverDeleteProhibited 

1.3 Add Grace Period, Redemption Grace Period, and Notice Periods for Renewals or Transfers

Verisign, FRS’ selected backend registry services provider, handles Add grace periods, Redemption grace periods, and notice periods for renewals or transfers as described here.
- Add Grace Period: The Add grace period is a specified number of days following the initial registration of the domain name. The current value of the Add grace period for all registrars is five days. 
- Redemption Grace Period: If the domain name is deleted after the five-day grace period expires, it enters the Redemption grace period and then is deleted by the system. The registrant has an option to use the Restore Request command to restore the domain name within the Redemption grace period. In this scenario, the domain name goes to Pending Restore state if there is a Restore Request command within 30 days of the Redemption grace period. From the Pending Restore state, it goes either to the OK state, if there is a Restore Report Submission command within seven days of the Restore Request grace period, or a Redemption Period state if there is no Restore Report Submission command within seven days of the Restore Request grace period. 
- Renew Grace Period: The Renew⁄Extend grace period is a specified number of days following the renewal⁄extension of the domain name’s registration period. The current value of the Renew⁄Extend grace period is five days. 
- Auto-Renew Grace Period: All auto-renewed domain names have a grace period of 45 days. 
- Transfer Grace Period: Domain names have a five-day Transfer grace period. 

1.4 Aspects of the Registration Lifecycle Not Covered by Standard EPP RFCs

FRS’ selected backend registry services provider’s (Verisign’s) registration lifecycle processes and code implementations adhere to the standard EPP RFCs related to the registration lifecycle. By adhering to the RFCs, Verisign’s registration lifecycle is complete and addresses each registration-related task comprising the lifecycle. No aspect of Verisign’s registration lifecycle is not covered by one of the standard EPP RFCs and thus no additional definitions are provided in this response.

2 CONSISTENCY WITH ANY SPECIFIC COMMITMENTS MADE TO REGISTRANTS AS ADAPTED TO THE OVERALL BUSINESS APPROACH FOR THE PROPOSED gTLD

The registration lifecycle described above applies to the .insurance gTLD as well as other TLDs managed by Verisign, FRS’ selected backend registry services provider; thus Verisign remains consistent with commitments made to its registrants. No unique or specific registration lifecycle modifications or adaptations are required to support the overall business approach for the .insurance gTLD.
 
To accommodate a range of registries, Verisign’s registry implementation is capable of offering both a thin and thick Whois implementation, which is also built upon Verisign’s award-winning ATLAS infrastructure.

3 COMPLIANCE WITH RELEVANT RFCs

FRS’ selected backend registry services provider’s (Verisign’s) registration lifecycle complies with applicable RFCs, specifically RFCs 5730 – 5734 and 3915. The system fully supports the EPP Domain Name Mapping as defined by RFC 5731, where the associated objects (e.g., hosts and contacts) are created independent of the domain name.

In addition, in accordance with RFCs 5732 and 5733, the Verisign registration system enforces the following domain name registration constraints:
- Uniqueness⁄Multiplicity: A second-level domain name is unique in the .insurance database. Two identical second-level domain names cannot simultaneously exist in .insurancek. Further, a second-level domain name cannot be created if it conflicts with a reserved domain name.
- Point of Contact Associations: The domain name is associated with the following points of contact. Contacts are created and managed independently according to RFC 5733. 
- Registrant
- Administrative contact
- Technical contact
- Billing contact
- Domain Name Associations: Each domain name is associated with:
- A maximum of 13 hosts, which are created and managed independently according to RFC 5732
- An Auth-Info, which is used to authorize certain operations on the object
- Status(es), which are used to describe the domain name’s status in the registry
- A created date, updated date, and expiry date

4 DEMONSTRATES THAT TECHNICAL RESOURCES REQUIRED TO CARRY THROUGH THE PLANS FOR THIS ELEMENT ARE ALREADY ON HAND OR READILY AVAILABLE

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 the registration lifecycle:
- Application Engineers: 19 
- Customer Support Personnel: 36 
- Database Administrators: 8 
- Database Engineers: 3 
- Quality Assurance Engineers: 11 
- SRS System Administrators: 13 

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.

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.

1 MECHANISMS DESIGNED TO PREVENT ABUSIVE REGISTRATIONS

Rights protection is a core objective of fTLD Registry Services, LLC (FRS).

Members of the .insurance gTLD community are all too familiar with the problems of abusive registrations, and many times, find themselves victims of such activity. The mission of the .insurance gTLD is to serve as a trusted, hierarchical and intuitive namespace for the insurance community and the consumers it serves. FRS will implement and adhere to all Rights Protection Mechanisms (RPMs) that may be mandated periodically by ICANN, including each mandatory RPM set forth in the Trademark Clearinghouse model contained in the template Registry Agreement, Specification 7. FRS acknowledges that, at a minimum, ICANN requires a Sunrise period, a Trademark Claims period, and interaction with the Trademark Clearinghouse with respect to the registration of domain names for the .insurance gTLD. 

In addition to ICANN’s baseline requirements, FRS plans to introduce enhanced measures to ensure that abusive registrations do not occur in the .insurance gTLD. It should be noted that because ICANN, as of the time of this application submission, has not issued final guidance with respect to the Trademark Clearinghouse, FRS cannot fully detail the specific implementation of the Trademark Clearinghouse within this application. FRS will adhere to all processes and procedures to comply with ICANN once this final guidance has been issued. 

As described in this response, FRS will implement a multi-tier approach to rights protection that seeks to minimize the potential for abusive registrations and to expeditiously address them should they occur. Measures will be deployed at the registry, registrar and registrant levels to ensure a comprehensive approach to these critical objectives. Policies and processes designed to prevent and mitigate abusive registrations include:

- Registrant Eligibility Criteria 
- Stringent Name Selection Policy
- Acceptable Use Policy
- Deployment of Enhanced Security Standards
- Trademark Claims Service
- Sunrise Service
- Rapid Takedown or Suspension
- Anti-Abuse Process 
- Enhanced Authentication
- Malware Code Identification
- DNSSEC Signing Service
- Semi-Annual WHOIS Verification 
- Active Participation in Anti-Abuse Community Activities

Certain aspects of the Sunrise Period and⁄or Trademark Claims Service will be administered on behalf of FRS by its FRS-accredited registrars or by contracted third parties of FRS, such as its selected backend registry services provider, Verisign. 

Registrant Eligibility Criteria

As the operator of the .insurance gTLD, FRS has undertaken responsibilities based upon experience and concerns expressed by the insurance community. It is essential that only registrations of verified members of the insurance community be permitted. In addition to validating the eligibility of the registrant, the domain name to be registered must comply with appropriate name selection and use requirement policies.

To ensure strict compliance with these policies, FRS will develop and implement a Registrant Eligibility Evaluation Process. This process requires .insurance accredited registrars to collect registrant information that will be used by FRS or an independent third-party service provider to authenticate that the registrant is a member of the insurance community. These requirements will be hard coded into FRS’ Registry-Registrar Agreement (RRA).

Registrations within the community may initially be made by the following for-profit and not-for-profit businesses, individuals or organizations:
- Licensed insurance companies regulated by a government entity
- Licensed insurance agents and brokers regulated by a government entity 
- Associations whose members include licensed insurance companies, agents or brokers (if approved by the FRS Board) 
- Organizations that are majority controlled by insurance companies (if approved by the FRS Board)  
- Entities whose operations are principally dedicated to serving insurance companies (if approved by the FRS Board) 
- Specialized organizations (e.g., research or risk coordination) (if approved by the FRS Board)

As part of the registration process, potential applicants must provide the registrar with the following information:
- Full legal name
- Business address
- Professional title of representative of the administrative contact of potential registrant 
- Business name
- Point of contact within the business who can verify their representation of the business
- Phone
- Email
- Another proof of identity necessary to establish that the registrant is an eligible member of the .insurance gTLD community
- For insurance companies, the state regulatory authority issuing its charter
- For agents and brokers, the state licensing agency
- For organizations that are majority controlled by insurance companies in category (a), list of and proof of its owner(s)
- For entities whose operations are principally dedicated to serving insurance companies (if approved by the FRS Board), corporate operating agreement or like document(s) as determined necessary to validate alignment with the goals of the community
- For specialized organizations (e.g., research or risk coordination) (if approved by the FRS Board), a copy of its corporate operating agreement if for-profit or its mission statement if non-profit (or like document(s) as determined necessary to validate alignment with the goals of the community)

The Registrant Eligibility Evaluation Process serves several purposes which will reduce the incidents of abusive registrations that impact the rights of others, as well as impact the security of the gTLD including:
- Ensuring the registrant information is complete, true and accurate, thereby contributing to accurate Whois information for all domains in the gTLD.
- Verifying, where necessary, supplemental documentation submitted to establish eligibility within the insurance community.

Applicants who pass these eligibility tests will then be permitted to register their domain name. Applicants who do not pass the eligibility test will have the opportunity to appeal to the registry, but determination of eligibility rests solely with FRS. In the case of a dispute, an adjunct ombudsman will be used.


Stringent Name Selection Policy

Domains registered in the .insurance gTLD must correspond to a trademark, trade name or other service mark owned by the registrant. All other registrations (e.g., geographic, generic, etc.) will be reserved by the registry for its use or to be allocated in the future under an equitable allocation plan. The registry will develop a list of reserved names that are intended to be released in the future and the procedures governing their release will be developed in an open and transparent manner. In addition, FRS will ensure that all domain names meet the technical requirements set forth in applicable Requests for Comments (RFCs) (e.g., max character length), as well as domain name reservations as set forth in Specification 5 of the template Registry Agreement.


Acceptable Use Policy
FRS will have an Acceptable Use Policy (AUP) that will govern how a registrant may use its registered name. A DRAFT version of the policy follows (which may be amended from time to time):

All .insurance domains must be used to serve the needs of the insurance community. By registering a name in a gTLD operated by FRS, you agree to be bound by the terms of this Acceptable Use Policy (AUP). You may not:

1. Use your domain for any purposes prohibited by the laws of the jurisdiction(s) in which you do business or any other applicable law. For insurance companies, agents and brokers specifically, use of your domain name for any purposes prohibited by the insurance regulations of the regulator or government agency that issues your charter or license is strictly prohibited.

2. Use your domain for any purposes or in any manner that violates a statute, rule or law governing use of the Internet and⁄or electronic commerce (specifically including phishing, pharming, distributing Internet viruses and other destructive activities).

3. Use your domain for the following types of activity:

- Violating the privacy or publicity rights of another member of the insurance community or any other person or entity, or breaching any duty of confidentiality that you owe to another member of the .insurance gTLD community or any other person or entity; 
- Promoting or engaging in hate speech, hate crime, terrorism, violence against people, animals, or property, or intolerance of or against any protected class;
- Promoting or engaging in defamatory, harassing, abusive or otherwise objectionable behavior; 
- Promoting or engaging in pornography;
- Promoting or engaging in any spam or other unsolicited bulk email, or computer or network hacking or cracking; 
- Promoting or engaging in any money laundering or terrorist financing activity;
- Infringing on the intellectual property rights of another member of the .insurance gTLD community or any other person or entity; 
- Engaging in activities designed to impersonate any third party or create a likelihood of confusion in sponsorship;
- Interfering with the operation of the .insurance gTLD or services offered by FRS; 
- Distributing or Installing any viruses, worms, bugs, Trojan horses or other code, files or programs designed to, or capable of, disrupting, damaging or limiting the functionality of any software or hardware, or distributing false or deceptive language, or unsubstantiated or comparative claims, regarding FRS;
- Disseminating content which contains false or deceptive language or unsubstantiated comparative claims, regarding FRS; 
- Licensing your domain to any third party during the period of your registration; or, 
- Engaging in behavior that is anti-competitive, boycotts or otherwise violates anti-trust laws.

You are responsible for the usage of your domain at all times during the period of your registration.

Proxy registrations are prohibited for all gTLDs operated by FRS.

By “use,” “usage” or “using” your domain name, we mean any use involving the Internet including, but not limited to, website(s) and⁄or any pages thereof resolving at your domain, either directly or indirectly (including redirection, framing, pop-up windows⁄browsers, linking, etc.), and email distribution and⁄or reception.

As part of the AUP, FRS will have complete enforcement rights over registrant’s use of domain names.

If Registrant violates this AUP, Registrant will be subject to a rapid domain name compliance action, be in material breach of this Agreement, and along with all other rights and remedies under this Agreement with respect to such a breach, FRS reserves the right to revoke, suspend, terminate, cancel or otherwise modify Registrant’s rights to the domain name.

On a regular basis, FRS will audit domain names, or require an attestation by second-level domain holders, registered in the .insurance gTLD space to ensure compliance with all eligibility and use criteria. If a violation is discovered, an investigation will begin immediately to rectify the violation.

If an applicant chooses to appeal, FRS will review the appeal to determine if there are any material changes to the action or activity. FRS will retain the right to assign the dispute to an ombudsman if necessary. This appeal or referral process will operate on a cost-recovery basis.

Deployment of Enhanced Security Standards

In January 2010, ABA and the Roundtable (through its BITS division) - founding organizations of FRS - committed to forming a global, industry-wide working group whose goal was to develop enhanced security standards that should be implemented in financial Top Level Domains or any domain that requires increased security. The Security Standards Working Group (SSWG) was comprised of representatives from the financial services and domain name industries, as well as security and technical experts. For a complete list of organizations that endorsed the SSWG’s standards, see Attachment 29-1. 

The SSWG developed a list of 31 Enhanced Security Standards that should be implemented in any financial gTLD. See Attachment 29-2 for the full list of Enhanced Security Standards. Included in the most recent version of the Applicant Guidebook, ICANN has cited these security standards as an example of what an independent standard could look like so that other financial services gTLD applicants could use it for guidance. FRS, as the steward of the .insurance gTLD, is implementing all 31 of these Enhanced Security Standards to ensure that the gTLD meets the necessary security requirements designed to provide security for the financial services community. 

It is important to note that the proposed standards are consistent with the recommendations and concerns put forth by international law enforcement that are “designed to aid in the prevention and disruption of efforts to exploit domain registration procedures by criminal groups for criminal purposes.” The law enforcement proposals have the support of ICANN’s Governmental Advisory Committee (GAC), the U.K. Serious Organized Crimes Agency, and the U.S. Federal Bureau of Investigation. Further, the GAC noted in its Nairobi Communiqué that law enforcement proposals were favorably viewed by the high tech crime experts in the G8 and Interpol.

A more thorough description of the Enhanced Security Standards can be found in our answers to question 30.


Sunrise Period. As provided by the Trademark Clearinghouse model set forth in the ICANN Applicant Guidebook, the Sunrise service pre-registration procedure for domain names continues for at least 30 days prior to the launch of the general registration of domain names in the gTLD (unless FRS decides to offer a longer Sunrise period). 

During the Sunrise period, holders of marks that have been previously validated by the Trademark Clearinghouse receive notice of domain names that are an identical match (as defined in the ICANN Applicant Guidebook) to their mark(s). Such notice is in accordance with ICANN’s requirements and is provided by FRS either directly or through FRS-accredited registrars. 

FRS requires all registrants, either directly or through FRS-accredited registrars, to 1) affirm that said registrants meet the Sunrise Eligibility Requirements (SER) and 2) submit to the Sunrise Dispute Resolution Policy (SDRP), consistent with Section 6 of the Trademark Clearinghouse model. At a minimum, FRS will recognize and honor all word marks for which a proof of use was submitted and validated by the Trademark Clearinghouse, in addition to any additional eligibility requirements as specified earlier in this question.

During the Sunrise period, FRS and⁄or FRS-accredited registrars, as applicable, are responsible for determining whether each domain name is eligible to be registered (including in accordance with the SER).

To execute a successful Sunrise Period that meets all of ICANN’s necessary requirements, as well as ensures appropriate protection for rights holders, FRS will seek to engage an external third-party service provider with prior experience in the design and administration of sunrise periods. Once ICANN finalizes the implementation details and scope of the Trademark Clearinghouse, FRS plans to incorporate such details into its Sunrise efforts. The current proposed model anticipates that FRS will run two different Sunrise periods followed by a Real Time Registration Period for the entire insurance community. The current proposal is set forth below:

Founder’s Sunrise - This Sunrise will be offered to those participants in the FRS Founder’s Program. They will have the first opportunity to secure .insurance second-level domains that represent their trademarks, trade names or service marks and will operate on a first come, first served basis. As the universe of founding members is quite small, we do not anticipate many registration conflicts. 

General Sunrise for the larger .insurance gTLD community - Following the Founder’s Sunrise, this Sunrise period will allow eligible members of the .insurance gTLD community to register domains that represent their trademarks, trade names or service marks. This Sunrise will run for a period of time, but will not operate on a first come, first served basis. Due to the limited and restrictive nature of the .insurance namespace, FRS does not envision many significant issues regarding multiple financial service community members vying for the same domain name. However, in the event there are multiple registrations a domain name during General Sunrise, a two-step process will determine which registrant receives the domain. Within the guidelines set forth by ICANN for protecting trademark⁄registered name rights, first preference will be given to the applicant with proven (registered) rights to a name. If all contending registrants have an equal right, all will be asked to submit a proposed use plan and application fee to demonstrate to FRS how the TLD will be used. Emphasis will be placed on developing and deploying the domain. FRS will employ an independent arbiter to review and make the initial recommendation regarding awarding the domain to FRS Board of Directors. In the event that there is not a clear cut winner after these steps are undertaken, the parties may opt to proceed to a mechanism of last resort: auction. 
 

Trademark Claims Service. As provided by the Trademark Clearinghouse model set forth in the ICANN Applicant Guidebook, all new gTLDs will have to provide a Trademark Claims Service for a minimum of 60 days after the launch of the general registration of domain names in the gTLD (Trademark Claims Period).

During the Trademark Claims Period, in accordance with ICANN’s requirements, FRS or the FRS-accredited registrar will send a Trademark Claims Notice to any prospective registrant of a domain name that is an identical match (as defined in the ICANN Applicant Guidebook) to any mark validated in the Trademark Clearinghouse. The Trademark Claims Notice will include links to the Trademark Claims as listed in the Trademark Clearinghouse and will be provided at no cost.

Prior to registration of said domain name, FRS, or the FRS-accredited registrar, will require each prospective registrant to provide the warranties dictated in the Trademark Clearinghouse model set forth in the ICANN Applicant Guidebook. Those warranties will include receipt and understanding of the Trademark Claims Notice and confirmation that registration and use of said domain name will not infringe on the trademark rights of the mark holders listed. Without receipt of said warranties, FRS, or the FRS-accredited registrar, will not process the domain name registration.

Following the registration of a domain name, the FRS-accredited registrar will provide a notice of domain name registration to the holders of marks that have been previously validated by the Trademark Clearinghouse and are an identical match. This notice will be as dictated by ICANN. At a minimum, FRS will recognize and honor all word marks validated by the Trademark Clearinghouse. 

Reserve Name Challenge Process. As noted in the response to Question 18, FRS will reserve a set of domain names prior to launch. These domain names will either be used by FRS in its capacity as Registry Operator for the management, operation, and purpose of the gTLD as set forth in Specification 9 of the template Registry Agreement, or they will be equitably allocated to members of the .insurance gTLD community. The subset of domain names reserved for use by the FRS is necessary to create a trusted, hierarchical, and intuitive framework for the insurance namespace to facilitate the ease by which consumers can navigate the gTLD. 

Although these reserved words will be commonly used words and phrases and⁄or geographic terms, FRS wants to provide an enhanced RPM that will provide trademark owners with the option to challenge the reservation⁄potential use of these domain names. This challenge process will be modeled after the highly successful dotAsia Pioneering Program.



2 MECHANISMS DESIGNED TO IDENTIFY AND ADDRESS THE ABUSIVE USE OF REGISTERED NAMES ON AN ONGOING BASIS

In addition to the Sunrise and Trademark Claims services described in Section 1 of this response, FRS will implement and adhere to RPMs post-launch as mandated by ICANN, and confirm that registrars accredited for the .insurance gTLD are in compliance with these mechanisms. Certain aspects of these post-launch RPMs may be administered on behalf of FRS by FRS-accredited registrars or by contracted third parties of FRS, such as its selected backend registry services provider, Verisign. Where applicable, these measures will be incorporated into the Registry-Registrar Agreement (RRA), which governs the legal relationship between FRS and its accredited registrars. 

These post-launch RPMs include the established Uniform Domain-Name Dispute-Resolution Policy (UDRP), as well as the newer Uniform Rapid Suspension System (URS) and Trademark Post-Delegation Dispute Resolution Procedure (PDDRP). Where applicable, FRS will implement all determinations and decisions issued under the corresponding RPM.

After a domain name is registered, trademark holders can object to the registration through the UDRP or URS. Objections to the operation of the gTLD can be made through the PDDRP.

The following descriptions provide implementation details of each post-launch RPM for the .insurance gTLD: 

- UDRP: The UDRP provides a mechanism for complainants to object to domain name registrations. The complainant files its objection with a UDRP provider and the domain name registrant has an opportunity to respond. The UDRP provider makes a decision based on the papers filed. If the complainant is successful, ownership of the domain name registration is transferred to the complainant. If the complainant is unsuccessful, ownership of the domain name remains with the domain name registrant. FRS and entities operating on its behalf adhere to all decisions rendered by UDRP providers. The UDRP must be incorporated by reference into the Registration Agreement developed by .insurance accredited registrars. Prospective registrants must agree to be bound by the terms and conditions in connection with the UDRP in order to successfully register a name. These requirements will also be included in the RRA to ensure register compliance.

- URS: As provided in the Applicant Guidebook, all registries are required to implement the URS. Similar to the UDRP, a complainant files its objection with a URS provider. The URS provider conducts an administrative review for compliance with filing requirements. If the complaint passes review, the URS provider notifies the registry operator and locks the domain. A lock means that the registry restricts all changes to the registration data, but the name will continue to resolve. After the domain is locked, the complaint is served to the domain name registrant, who has an opportunity to respond. If the complainant is successful, the registry operator is informed and the domain name is suspended for the balance of the registration period; the domain name will not resolve to the original website, but to an informational webpage provided by the URS provider. If the complainant is unsuccessful, the URS is terminated and full control of the domain name registration is returned to the domain name registrant. Similar to the existing UDRP, FRS and entities operating on its behalf will comply with decisions rendered by the URS providers. In addition, the URS must be incorporated by reference into the Registration Agreement developed by .insurance accredited registrars. Prospective registrants must agree to be bound by the terms and conditions in connection with the URS in order to successfully register a name. These requirements will also be included in the RRA to ensure register compliance.

- PDDRP: As provided in the Applicant Guidebook, all registries are required to implement the PDDRP. The PDDRP provides a mechanism for a complainant to object to the registry operator’s manner of operation or use of the gTLD. The complainant files its objection with a PDDRP provider, who performs a threshold review. The registry operator has the opportunity to respond and the provider issues its determination based on the papers filed, although there may be opportunity for further discovery and a hearing. FRS will participate in the PDDRP process as specified in the Applicant Guidebook.

- Additional Measures Specific to Rights Protection. FRS provides additional measures against potentially abusive registrations. These measures help mitigate phishing, pharming and other Internet security threats. The measures exceed the minimum requirements for RPMs defined by Specification 7 of the Registry Agreement and are available at the time of registration. These measures include:

- Rapid Takedown or Suspension Based on Court Orders: FRS will comply promptly with any order from a court of competent jurisdiction that directs it to take any action on a domain name that is within its technical capabilities as a gTLD registry. 

- Anti-Abuse Process: FRS will implement an anti-abuse process that is executed based on the type of domain name takedown requested. The anti-abuse process is for malicious exploitation of the DNS infrastructure, such as phishing, botnets, and malware. 
 
- Authentication Procedures: Verisign, FRS’ selected backend registry services provider, uses two-factor authentication to augment security protocols for telephone, email, and chat communications.

- Malware Code Identification: This safeguard reduces opportunities for abusive behaviors that use registered domain names in the gTLD. Registrants are often unknowing victims of malware exploits. As FRS’ backend registry services provider, 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.

- DNSSEC Signing Service: Domain Name System Security Extensions (DNSSEC) helps mitigate pharming attacks that use cache poisoning to redirect unsuspecting users to fraudulent websites or addresses. It uses public key cryptography to digitally sign DNS data when it comes into the system and then validate it at its destination. The .insurance gTLD is DNSSEC-enabled as part of Verisign’s core backend registry services. 


Semi-annual Whois Verification 

As part of their RRA all .insurance registrars will be required to revalidate Whois data for each record they have registered in the gTLD. The registry will leave the ultimate determination of how to implement this procedure to each registrar, but it must include one of the following approved methods: 
1) Email with a verification link that must be acted upon within a set time frame.
2) If the email verification is not acted upon in the proscribed timeframe, an outbound telemarketing effort to the individual listed as the administrative contact for the domain must be initiated to manually confirm the information contained in the Whois record. 
 
Each method will require the use of two factor authentication to ensure the respondent is the original registrant.

Verification process for each registered domain name must take place twice a year within the following schedule:
1) Mid-registration Verification: No sooner than 120 days after initial registration or subsequent renewal, and no later than 200 days after initial registration or subsequent renewal.
2) Renewal Verification: No later than 30 days prior to expiration and no sooner than 90 days prior to expiration. 

FRS, as operator of the registry, will perform audits of verified Whois information to ensure compliance and accuracy. In addition, the registry will allow interested parties to report cases of inaccurate Whois information via an inbound reporting mechanism on the .insurance gTLD webpage.


Active Participation in Anti-abuse Community Activities

FRS and its founding member organizations are, and will continue to be, active participants in the anti-abuse community. As this is a perpetual process, we take participation in various organizations, seminars and conferences very seriously and look to learn from the experience of others as well as share our experiences with said others to promote a safer online space. As the ABA and Roundtable led the development of the enhanced security standards for financial gTLDs, FRS and its member organizations will continue to take leadership roles to ensure that all financial related gTLDs are operated in a safe and secure manner that reflects the unique nature of their offering.



3 RESOURCING PLANS

Resource Planning

FRS is committed to operating the .insurance gTLD in a manner that benefits the financial services community, specifically the insurance industry, 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 three 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 Banking Association and The Financial Services Roundtable. This support will include, but not be limited to, legal, finance and other services necessary to ensure the successful operation of the .insurance gTLD. 

As the .insurance gTLD is a community supported effort, it is also expected that members of the insurance and financial services communities will advise and support FRS in implementing the policies and procedures developed to 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 Rights Protection Mechanisms: 
- 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 gTLD. 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 the .insurance 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 Line IIb.G, Total Critical Registry Function Cash Outflows, 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 over 13 years for .com, proving Verisign’s ability to align personnel resource growth to the scale increases of Verisign’s gTLD 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 the implementation of RPMs:
- Customer Affairs Organization: 9
- Customer Support Personnel: 36
- Information Security Engineers: 11 

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 gTLDs. 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 gTLDs instead of creating a new entity to manage only this proposed gTLD, Verisign realizes significant economies of scale and ensures its gTLD 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 gTLDs (i.e., .com and .net). Moreover, by augmenting existing teams, Verisign provides new employees with 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.

1 DETAILED DESCRIPTION OF PROCESSES AND SOLUTIONS DEPLOYED TO MANAGE LOGICAL SECURITY ACROSS INFRASTRUCTURE AND SYSTEMS, MONITORING AND DETECTING THREATS AND SECURITY VULNERABILITIES AND TAKING APPROPRIATE STEPS TO RESOLVE THEM

fTLD Registry Services, LLC’s (FRS) selected backend registry services provider’s (Verisign’s) comprehensive security policy has evolved over the years as part of managing some of the world’s most critical TLDs. Verisign’s Information Security Policy is the primary guideline that sets the baseline for all other policies, procedures, and standards that Verisign follows. This security policy addresses all of the critical components for the management of backend registry services, including architecture, engineering, and operations. 

Verisign’s general security policies and standards with respect to these areas are provided as follows:
- Architecture
 - Information Security Architecture Standard: This standard establishes the Verisign standard for application and network architecture. The document explains the methods for segmenting application tiers, using authentication mechanisms, and implementing application functions.
 - Information Security Secure Linux Standard: This standard establishes the information security requirements for all systems that run Linux throughout the Verisign organization.
 - Information Security Secure Oracle Standard: This standard establishes the information securityrequirements for all systems that run Oracle throughout the Verisign organization.
 - Information Security Remote Access Standard: This standard establishes the information security requirements for remote access to terminal services throughout the Verisign organization.
 - Information Security SSH Standard: This standard establishes the information security requirements for the application of Secure Shell (SSH) on all systems throughout the Verisign organization.

- Engineering
 - Secure SSL⁄TLS Configuration Standard: This standard establishes the information security requirements for the configuration of Secure Sockets Layer⁄Transport Layer Security (SSL⁄TLS) for all systems throughout the Verisign organization.
 - Information Security C++ Standards: These standards explain how to use and implement the functions and application programming interfaces (APIs) within C++. The document also describes how to perform logging, authentication, and database connectivity.
 - Information Security Java Standards: These standards explain how to use and implement the functions and APIs within Java. The document also describes how to perform logging, authentication, and database connectivity.

- Operations
 - Information Security DNS Standard: This standard establishes the information security requirements for all systems that run DNS systems throughout the Verisign organization.
 - Information Security Cryptographic Key Management Standard: This standard provides detailed information on both technology and processes for the use of encryption on Verisign information security systems.
 - Secure Apache Standard: Verisign has a multitude of Apache web servers,which are used in both production and development environments on the Verisign intranet and on the Internet. They provide a centralized, dynamic, and extensible interface to various other systems that deliver information to the end user. Because of their exposure and the confidential nature of the data that these systems host, adequate security measures must be in place. The Secure Apache Standard establishes the information security requirements for all systems that run Apache web servers throughout the Verisign organization.
 - Secure Sendmail Standard: Verisign uses sendmail servers in both the production and development environments on the Verisign intranet and on the Internet. Sendmail allows users to communicate with one another via email. The Secure Sendmail Standard establishes the information security requirements for all systems that run sendmail servers throughout the Verisign organization.
 - Secure Logging Standard: This standard establishes the information security logging requirements for all systems and applications throughout the Verisign organization. Where specific standards documents have been created for operating systems or applications, the logging standards have been detailed. This document covers all technologies.
 - Patch Management Standard: This standard establishes the information security patch and upgrade management requirements for all systems and applications throughout Verisign.

- General
 - Secure Password Standard: Because passwords are the most popular and, in many cases, the sole mechanism for authenticating a user to a system, great care must be taken to help ensure that passwords are “strong” and secure. The Secure Password Standard details requirements for the use and implementation of passwords.
 - Secure Anti-Virus Standard: Verisign must be protected continuously from computer viruses and other forms of malicious code. These threats can cause significant damage to the overall operation and security of the Verisign network. The Secure Anti-Virus Standard describes the requirements for minimizing the occurrence and impact of these incidents.

Security processes and solutions for the .insurance gTLD are based on the standards defined above, each of which is derived from Verisign’s experience and industry best practice. These standards comprise the framework for the overall security solution and applicable processes implemented across all products under Verisign’s management. The security solution and applicable processes include, but are not limited to:
- System and network access control (e.g., monitoring, logging, and backup) 
- Independent assessment and periodic independent assessment reports
- Denial of service (DoS) and distributed denial of service (DDoS) attack mitigation
- Computer and network incident response policies, plans, and processes
- Minimization of risk of unauthorized access to systems or tampering with registry data
- Intrusion detection mechanisms, threat analysis, defenses, and updates 
- Auditing of network access
- Physical security

Further details of these processes and solutions are provided in Part B of this response.

1.1 Security Policy and Procedures for the Proposed Registry

Specific security policy related details, requested as the bulleted items of Question 30 – Part A, are provided here. 

Independent Assessment and Periodic Independent Assessment Reports. To help ensure effective security controls are in place, FRS, through its selected backend registry services provider, Verisign, conducts a yearly American Institute of Certified Public Accountants (AICPA) and Canadian Institute of Chartered Accountants (CICA) SAS 70 audit on all of its data centers, hosted systems, and applications. During these SAS 70 audits, security controls at the operational, technical, and human level are rigorously tested. These audits are conducted by a certified and accredited third party and help ensure that Verisign in-place environments meet the security criteria specified in Verisign’s customer contractual agreements and are in accordance with commercially accepted security controls and practices. Verisign also performs numerous audits throughout the year to verify its security processes and activities. These audits cover many different environments and technologies and validate Verisign’s capability to protect its registry and DNS resolution environments. Attachment 30A-1 lists a subset of the audits that Verisign conducts. For each audit program or certification listed in Attachment 30A-1, Verisign has included, as attachments to the Part B component of this response, copies of the assessment reports conducted by the listed third-party auditor. From Verisign’s experience operating registries, it has determined that together these audit programs and certifications provide a reliable means to ensure effective security controls are in place and that these controls are sufficient to meet ICANN security requirements and therefore are commensurate with the guidelines defined by ISO 27001.

Augmented Security Levels or Capabilities. See Section 5 of this response. 

Commitments Made to Registrants Concerning Security Levels. See Section 4 of this response.

2 SECURITY CAPABILITIES ARE CONSISTENT WITH THE OVERALL BUSINESS APPROACH AND PLANNED SIZE OF THE REGISTRY

Consistency of Business Approach and Planned Size of Registry

Since the introduction of the first Applicant Guidebook, FRSʹ founding member organizations, the American Bankers Association (ABA) and The Financial Services Roundtable (Roundtable), have advocated that ICANN and the community at large require a higher standard of security, stability and resiliency for all financial services gTLDs. In December 2011, BITS, the technology policy division of the Roundtable, and the ABA sent to ICANN 31 proposed Enhanced Security Standards developed by their Security Standards Working Group (SSWG). Members of the SSWG included noted security experts, domain name system subject matter experts, and global representatives of the financial services industry. In the most recent version of the Applicant Guidebook, ICANN calls out the Enhanced Security Standards as an example of what private organizations can do to ensure security standards are commensurate with the business approach of the registry.
 
To ensure that the level of security, stability and resiliency is commensurate with the nature of the .bank gTLD, FRS will be voluntarily implementing all 31 Enhanced Security Standards. FRS is deploying these measures as a commitment to the .bank community that due the unique nature of a financial services gTLD these policies and procedures will ensure a higher level of security and trust for not only the registrants but also the broader Internet community who will be using this gTLD. Because of the stringent eligibility and registration procedures put in place to govern the operation of the .bank gTLD, FRS does not expect this to become a large TLD when compared to some of the existing gTLDs. The .bank gTLD is specifically designed NOT to be a gTLD for just anyone. 

Consistency of Backend Registry Services with Business Approach and Planned Size of Registry

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 “Total Critical Registry Function Cash Outflows” (Template 1, Line IIb.G) within the Question 46 financial projections response.

3 TECHNICAL PLAN 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 insurance 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 insurance 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 Security Policy of the gTLD: 

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 role, which is described in Section 5 of the response to Question 31, Technical Overview of Proposed 
Registry, to support its security policy:

- Information Security Engineers: 11

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.

4 SECURITY MEASURES ARE CONSISTENT WITH ANY COMMITMENTS MADE TO REGISTRANTS REGARDING SECURITY LEVELS

The .insurance gTLD is designed to provide the financial services community a gTLD with higher levels of security than currently exist in other commercially available non-restricted gTLDs. Once deployed, the .insurance gTLD will signal to registrants and the people who use these websites that operators of these domains are members of the financial services community that have been verified and authenticated. The result of FRS’ vetting process will establish a new level of trust within the .insurance gTLD. 

As described in the answer to section 2 of this question, FRS will implement all 31 Enhanced Security Standards developed by the SSWG. Implementation of these standards will increase the security, stability, resiliency and reputation of the .insurance gTLD. Further detail on the 31 standards can be found in Appendix C to FRS’ Security Policy that is presented in Attachment 30B-5 of the response to question 30b. 

5 SECURITY MEASURES ARE APPROPRIATE FOR THE APPLIED-FOR gTLD STRING (FOR EXAMPLE, APPLICATIONS FOR STRINGS WITH UNIQUE TRUST IMPLICATIONS, SUCH AS FINANCIAL SERVICES-ORIENTED STRINGS, WOULD BE EXPECTED TO PROVIDE A COMMENSURATE LEVEL OF SECURITY)

As defined in Section 1 of this response, Verisign, FRS’ selected backend registry services provider, commits to providing backend registry services in accordance with the following international and relevant security standards:
- American Institute of Certified Public Accountants (AICPA) and Canadian Institute of Chartered Accountants (CICA) SAS 70 
- WebTrust⁄SysTrust for Certification Authorities (CA)

The ICANN Applicant Guidebook expressly recognizes the need for increased security standards for strings with unique trust implications, noting this need specifically for financial services-oriented gTLDs. As stated in previous portions of this question, FRS will implement all 31 Enhanced Security Standards developed by the SSWG to ensure that the security measures in place are appropriate for the nature of the .insurance gTLD. A copy of the standards can be found in Attachment 30A-2. Further detail on the 31 standards can be found in Appendix C to FRS’ Security Policy that is presented in Attachment 30B-5 of the response to question 30b. 

FRS is firmly committed to operating new financial service-oriented top-level domains in a responsible and secure manner and will take all necessary steps to ensure the output from the SSWG are implemented at the Registry, Registry Operator and Registrar levels.