usTLD Requirements Document (PWS) clean.pdf

1 | P a g e

CUI//PROCURE//FEDCON

REQUIREMENTS DOCUMENT

ADMINISTRATION OF THE UNITED STATES COUNTRY

CODE TOP LEVEL DOMAIN

FOR

THE NATIONAL TELECOMMUNICATIONS AND

INFORMATION ADMINISTRATION

2 | P a g e

1.0 Requirements Document Overview

This Requirements Document (RD):

1.1. Outlines the background, objectives, scope of services, and description of services requested for the administration of the United States country code Top Level Domain (usTLD) registry; and

1.2. Establishes Baseline Performance Objectives (BPO) which put forward the baseline requirements and require the submission of a Work Statement that will include:

1.2.1. Policy and technical approaches that modernize, improve, and otherwise enhance the usTLD and its services, and

1.2.2. Programs or other actions to advance the multistakeholder approach to Internet governance.

2.0 Background

The mission of the Department of Commerce (DOC) is to create conditions for economic growth and opportunities for all communities. As one of 13 bureaus under the DOC, the National Telecommunications and Information Administration (NTIA) is the Executive Branch agency principally responsible for advising the President on telecommunications and information policy issues. NTIA serves as the interagency expert on policy pertaining to governance of the internet’s unique identifier systems, including the Domain Name System (DNS). NTIA supports a multistakeholder approach to coordination of the DNS to ensure that the internet serves as an engine for innovation and economic growth.

The country code Top Level Domain (ccTLD) for the United States (the usTLD or .us) was established in 1985. It was originally administered by the Information Sciences Institute (ISI) at the University of Southern California.1 Later, ISI subcontracted the administration with Network Solutions in a five-year contract that expired on September 30, 1998.2 Oversight of the usTLD was transferred to NTIA in 1998. NTIA sought public input on the future of .us management, followed by public meetings, and an additional call for comments regarding the draft statement of work for administration of the usTLD registry, in 2000.3 The original contract for usTLD administration was awarded in 2001, and NTIA has since supervised the administration of the usTLD under a series of contracts. These contracts are at no cost to the U.S. Government but enable the Contractor to generate revenue. Relevant documents are available at:

1 Request for Comments on the Enhancement of the .us Domain Space, National Telecommunications and

Information Admini (Aug. 3, 1998), https://www.ntia.gov/federal-register-notice/request-comments-enhancement-us-domain-space.

2 Improvement of Technical Management of Internet Names and Addresses; Proposed Rule, National Telecommunications and Information Admini (Feb. 20, 1998), https://www.ntia.gov/federal-register-notice/improvement-technical-management-internet-names-and-addresses-proposed-rule.

3 Requesting comments on draft statement of work regarding .us, National Telecommunications and Information Admini (Aug. 17, 2000), https://www.ntia.gov/federal-register-notice/requesting-comments-draft-statement-work-regarding-us. See generally, Verisign Cooperative Agreement, Verisign Cooperative Agreement | National Telecommunications and Information Administration and more specifically Amendments 19 and 21.

https://www.ntia.gov/federal-register-notice/requesting-comments-draft-statement-work-regarding-us https://www.ntia.gov/federal-register-notice/requesting-comments-draft-statement-work-regarding-us https://www.ntia.gov/program/verisign-cooperative-agreement#:%7E:text=The%20Verisign%20Cooperative%20Agreement%20is%20an%20agreement%20between,time.%20Below%20is%20an%20overview%20of%20this%20evolution.

https://www.ntia.gov/program/verisign-cooperative-agreement#:%7E:text=The%20Verisign%20Cooperative%20Agreement%20is%20an%20agreement%20between,time.%20Below%20is%20an%20overview%20of%20this%20evolution.

3 | P a g e https://www.ntia.gov/page/us-domain-space.

The original hierarchical structure of the usTLD was based upon the political geography of the United States.4 Names under this structure contain two-letter state abbreviations and are further divided into cities, counties, parishes, townships, and/or local names (e.g., https://www.harrisonburg.k12.va.us/). A handful of “affinity” designations were later added to the hierarchy.5 Examples of affinity names include STATE, FED, K12, LIB and NSN (Native Sovereign Nation, e.g., Squamish.nsn.us). This part of the usTLD zone is referred to as the “locality space.”

In the early days of the usTLD, individuals, organizations, and state and local governments received .us delegations to provide registry and registration services in the locality space. These “delegated managers” supported a widely distributed hierarchy within the usTLD. Prior to NTIA’s oversight, locality space delegations occurred without adequate records, or service and technical requirements. The original contractor assumed responsibility for a deeply hierarchical, legacy, locality-based usTLD structure, for which no authoritative records of delegations and sub-delegations existed. The contractor developed a management framework for policies and procedures specifically for the usTLD locality space. The direct relationship between the usTLD contractor and the delegated managers continues today. There are 112 usTLD delegated managers as of February 2025.

Delegated managers are responsible for the maintenance, support, and administration of .us locality domain names registered by localities, schools, state agencies, federal agencies, distributed national institutes, and general independent entities. Continued administrative oversight by the Contractor is necessary to ensure that the minimum technical and service requirements are met, both by delegated managers and locality-based registrants. For example, the Contractor may need to step in to provide services to locality-based registrants if their delegated manager retires or otherwise ceases operations.

In 2001, the Department authorized the expansion of the usTLD structure beyond the “locality space” formula, enabling domain name registrants to register names directly beneath the .us Top Level Domain (e.g., “organization.us”). The usTLD currently serves both purposes and is therefore composed of “locality space” registrations and “second-level” registrations. Further expansion of the usTLD is possible, for example by offering non-Latin scripts or one or two-character names at the second level. As of February 2025, there are more than 2.4 million usTLD registrations in total.

As the internet and DNS have evolved, so too have the usTLD and its policies. For example, in 2014, NTIA required the contractor to provide a proactive, multistakeholder process for community consultation on usTLD policy. This requirement led to the formation of the .US Stakeholder Council. The Council has served as the home for debate over various policy aspects of the usTLD including, most notably, discussion on how to

4 As defined by Dr. Jon Postel in IETF RFC 1480, “The US Domain.”

5 See RFC 1480, the US Domain, https://www.rfc-editor.org/rfc/rfc1480.

https://www.ntia.gov/page/us-domain-space https://www.rfc-editor.org/rfc/rfc1480

4 | P a g e balance access to domain name registration data with .us registrant privacy.6 The Department continues to support transparent and multistakeholder policy development processes for the usTLD.

The regulatory environment has also evolved to address increasing cybersecurity threats.

For example, the Cyber Incident Reporting for Critical Infrastructure Act of 2022 may impose new requirements on the operator of the usTLD. Cybercrime and DNS abuse in its various forms demand a robust response from the Contractor to ensure that the usTLD sets a world-class standard for other country code Top Level Domain operators to follow.

3.0 Objective

The Department seeks an Administrator for the usTLD to provide both the baseline services described, as well as a comprehensive work statement covering innovative program ideas and services sought, in accordance with this RD.

4.0 Scope of Services

4.1 The Contractor shall provide centralized management and coordination of registry, registrar (where specified), database, and information services for the usTLD. In doing so, the Contractor must ensure that policy and procedures for the administration of the usTLD support a secure, stable, and resilient DNS. (See e.g. Sections 6.3, 6.10).

4.2 The Contractor shall not serve as a registrar in the usTLD space, unless otherwise noted in this RD.

4.3 The Contractor shall create, maintain, and evolve, as appropriate, a policy-rich environment for the usTLD that meets or exceeds ccTLD industry best practices.

4.4 The Contractor shall accredit, and establish contractual arrangements with, usTLD registrars (Registrars), incorporating usTLD policy requirements as described in this RD.

The Contractor shall require each Registrar to implement an agreement with its usTLD registrants (Registrants), requiring the latter to agree to all applicable usTLD policies. The Contractor shall ensure that Registrars further ensure Registrant compliance with this agreement.

4.5 The Contractor shall advocate for, and actively participate in, the multistakeholder system of internet governance, both domestically and internationally. In particular, the Contractor, in coordination with NTIA, shall engage in the Internet Corporation of Assigned Names and Numbers (ICANN) Country Code Name Supporting Organization (ccNSO) as the administrator for the usTLD. The Contractor shall also detail programs or other actions to advance the multistakeholder approach to internet governance.

4.6 The Contractor shall coordinate with NTIA in developing paths for transparent, 6 A Proposal for More Privacy in Domain Name Personal Data, National Telecommunications and Information Administration (May 5, 2023), https://www.ntia.gov/blog/2023/proposal-more-privacy-domain-name-personal-data.

5 | P a g e multistakeholder participation in usTLD policy development processes.

4.7 The Contractor shall detail its plan for the implementation of policies or programs consistent with the RD as, for example, indicated in the potential revitalization of the kids.us domain (Section 6.30).

4.8 The Contractor shall ensure the continued stability of the usTLD, during transition from the current management structure to the Contractor's proposed structure and to any successor Contractor's structure.

4.9 The Contractor shall establish and maintain consistent communication with the Contracting Officer's Representative (COR) and Contracting Officer (CO), including regarding the review and development of plans, policies and deliverables.

4.10 The Contractor shall serve as the usTLD Administrator, overseeing all of the services listed herein (see Section 6.16). Certain services may be subcontracted to other entities including those services listed in 4.1. Any services not performed directly by the Contractor, must comply with all of the requirements and policies listed herein including the applicable standards enumerated in section 6.0. All subcontracts are subject to prior CO and COR review and approval.

5.0 Description of Services

5.1 The Contractor shall manage, maintain, and operate the usTLD under NTIA's supervision. The Contractor shall perform the required services for this acquisition as the prime Contractor, not as an agent or subcontractor. The Contractor may, however, provide the required services by coordinating the resources and services of entities other than the prime Contractor. In doing so, the Contractor as the usTLD Administrator shall actively oversee all of those services that may be contracted to other entities to ensure that the standards and policies required herein are complied with throughout the usTLD ecosystem. See also, sections 4.10 and 6.16.

5.2 The Contractor shall be: A United States entity or organization that is (i) incorporated within one of the fifty (50) U.S. states, the District of Columbia, or any of the United States possessions or territories.

5.3 The Contractor shall possess and maintain through the performance of this procurement a physical address within the United States and must be able to demonstrate that all primary registry services will remain within one of the fifty (50) U.S. states, the District of Columbia, or any of the United States possessions or territories.

5.4 The Contractor shall provide the necessary personnel, material, equipment, services, and facilities to perform the requirements outlined in this RD without any cost to the U.S.

Government.

6 | P a g e

5.5 On or after the effective date of this contract, the Contractor may establish and collect fees from third parties, other than the U.S. Government, for the requirements performed under this Contract. The Contracting Officer shall approve such fees before they take effect, the review of which will include whether the fees are fair and reasonable, in the public interest, and within the range of market price. A possibility exists that the expenses incurred to perform the Contract may exceed the fees received during the base period or any option period of the Contract. Any such expenses incurred are the sole responsibility of the Contractor.

5.6 In addition, the Contractor shall not implement any policies, procedures, rules, mechanisms, or execute any agreements or subcontracts in fulfillment of the Contract's requirements, without the prior approval of the COR and CO.

6.0 Baseline Performance Objectives

The following section describes the Baseline Requirements the Contractor is expected to fulfill in the implementation of the Contract and notes which requirements the Contractor will further describe in a Work Statement (WS).

6.1 The Contractor shall implement policies, procedures, rules, and/or mechanisms to give effect to the requirements listed in this section and execute agreements or subcontracts in fulfillment of these requirements, including agreements with domain name registrars accredited to offer registration services within the usTLD (Registrars).

6.2 The Contractor shall provide, at a minimum, all systems, software, hardware, facilities, infrastructure, cloud services, and operation for the functions listed below.

These functions are not exhaustive of the requirements sought.

6.3 The Contractor shall ensure the secure, stable, and reliable operation of the usTLD as it performs core usTLD registry functions, including:

6.3.1 Operation of secure and resilient authoritative nameservers for the usTLD zone file in IPv4/v6, ensuring global, always-available DNS resolution with low latency;

6.3.2 Compilation, generation, and propagation of the usTLD zone data;

6.3.3 Operation and maintenance of usTLD registry databases;

6.3.4 Maintenance of a Shared Registration System by which an unlimited number of accredited competing registrars may register, transfer, and update domain names for their customers in the usTLD;

6.3.5 Development and distribution of provisioning protocol software and procedures to accredited Registrars to facilitate a secure and efficient interface with the usTLD registry; and

6.3.6 The provision of technical support to accredited registrars for usTLD systems.

6.4 The Contractor shall develop, implement and maintain a comprehensive risk management program in line with ISO 31000 to identify and mitigate risks to the

7 | P a g e core domain name registry functions;

6.5 The Contractor shall not serve as a registrar in the usTLD space, except for the following:

6.5.1 Reserved name registrations, including those in the kids.us second-level domain, and

6.5.2 All locality domain names not serviced by a delegated manager subject to an agreement with the Contractor.

6.5.3 Any temporary role the Contractor may serve as part of a Department-approved registrar re-accreditation process. (see 6.14, infra).

6.6 The Contractor shall comply with applicable Internet Engineering Task Force (IETF) RFCs and Internet Corporation for Assigned Names and Numbers (ICANN) policies.

6.7 The Contractor shall implement and support Domain Name System Security Extensions (DNSSEC) for the usTLD and publish a statement of security practices and provisions which are applied to the administration and operation of DNSSEC in the TLD.

6.8 With regard to any IP address blocks (prefixes) which it utilizes for public facing services (IPv4 and IPv6), the Contractor shall create and publish Route Origin Authorizations in the Resource Public Key Infrastructure repository hosted or delegated by the American Registry of Internet Numbers or the appropriate regional Internet registry, or provide a valid explanation for not implementing.

6.9 The Contractor shall demonstrate the existing or planned capabilities of their applications, devices, and systems to enable the Universal Acceptance of Internationalized Domain Names (IDNs) and Email Addresses (IEAs).

6.9.1 WS Submission: Detailing how the Contractor would further support Universal Acceptance through its subcontractors, including registrars, hosting providers, data center providers, and data escrow providers.

6.10 Security and Privacy Practices. The Contractor shall adopt and maintain security practices that are effective and appropriate for its business operations in accordance with this RD.

6.10.1 Information Security Risk Management. The Contractor must adopt and maintain an effective “Information Security Management System” in compliance with ISO 27001 and provide the Department with evidence of compliance, whether through a certificate of compliance or otherwise.

6.10.2 Cybersecurity Controls. Without limitation to any other provisions in this RD, the Contractor shall implement risk-appropriate cybersecurity controls, such as those found in the Department of Homeland Security Cyber and

8 | P a g e

Infrastructure Security Agency’s Cybersecurity Performance Goals, to ensure a comprehensive security and privacy program of physical, technical, and organizational measures in alignment with ISO 27001.

6.11 Registry-Registrar Agreement. The Contractor shall, upon the CO and COR’s review and approval, put in place an agreement with accredited Registrars that gives effect to the policies included within this RD.

6.11.1 WS Submission: Detail how the Contractor would initiate a usTLD Registry-Registrar agreement that creates the conditions for a secure, innovative, and prosperous usTLD space.

6.12 Registrar Accreditation. The Contractor shall ensure that all usTLD Registrars satisfy the minimum criteria, below:

6.12.1 Corporate Criteria. All Registrars must meet one of following:

6.12.1.1 The Registrar is an entity incorporated in one of the fifty (50) U.S.

states, the District of Columbia, or any of the United States possessions or territories; or

6.12.1.2 If the Registrar is a foreign entity, the Registrar must be registered to validly operate and carry on business under applicable laws of the United States, or otherwise have an affiliate or subsidiary incorporated under the laws of the United States. Additionally, the Registrar must have a United States address for service of process and applicable law.

6.12.2 Operational Criteria. The Registrar must have the capability to provide services to Registrants in accordance with this RD, where applicable, including a sufficient number of staff, and adequate systems and procedures, to handle policy compliance checks for domain name registrations.

6.12.3 Security Criteria. The Registrar must hold either a (i) current effective “Information Security Management System” in compliance with ISO 27001, or (ii) other equivalent recognized security standard or framework.

6.13 Registrar-Registrant Agreement. The Contractor shall require the Registrar to require all usTLD Registrants to enter into a legally binding agreement with the Registrar that implements the applicable policies included within this RD, and require that the Registrar support implementation of DNSSEC, DMARC and DANE by Registrants, where applicable.

6.13.1 WS Submission: Contractor shall detail how a usTLD Registrar-Registrant Agreement would provide, among other things, the Contractor with an efficient and effective role in fostering Registrant compliance with usTLD policy.

6.14 Re-Accreditation of Existing usTLD Registrars. The Contractor shall provide, for

9 | P a g e the Department’s review and approval, a process to re-accredit existing usTLD Registrars based upon the criteria in Section 5.12. Re-Accreditation shall take place within one year of the award of the contract. That process should include a timeline and incorporate, at a minimum:

6.14.1 Sufficient notice to all usTLD Registrars of the re-accreditation process;

and

6.14.2 A requirement for the Registrar to agree to take all necessary steps to comply with the new accreditation criteria set forth by the Department, and for the Registrar to acknowledge that failure to meet the re-accreditation criteria by the specified deadline may result in the termination or non-renewal of its accreditation.

6.15 Registration Transfer Plan. In the event the Registrar is unable to qualify for re-accreditation pursuant to the new criteria established by the Department, the Contractor shall facilitate the secure transfer of all domain registrations under management of disqualified Registrars to accredited Registrars as part of a transfer plan. The transfer shall occur in accordance with applicable laws and privacy practices to ensure the protection of domain registrants' rights and interests. Further, the transfer should be conducted in accordance with best practices to ensure that the registrant experiences no down-time.

6.15.1 The Contractor will require any disqualified Registrar to notify their customers of the impending transfer, providing reasonable notice before initiating the transfer process.

6.15.2 The Contractor will require the disqualified Registrar and the receiving Registrar to fully cooperate with the transfer process to facilitate the transfer of domain registration(s). This includes, but is not limited to, providing access to domain registration data, authentication codes, and any other relevant information necessary to complete the transfer process. The Contractor shall require the disqualified Registrar to ensure that all relevant information is accurate, complete, and up to date at the time of transfer.

6.15.3 The Contractor may serve temporarily as a “holding registrar” for registrants to ensure continuity of services, and as registrants select their new, accredited usTLD Registrar.

6.16 Oversight of Contractor and Subcontractor Policy Implementation. It shall be the ongoing responsibility of the Contractor as the usTLD Administrator to oversee, audit, and enforce compliance of usTLD policies with all Registrars and subcontractors.

6.16.1 WS Submission: The Contractor shall articulate the process and procedures by which it would proactively oversee these agreements and compliance with usTLD policies, including, but not limited to, oversight of DNS Abuse, Nexus, and Accuracy requirements.

10 | P a g e

6.17 United States Nexus Requirement The Contractor shall run the usTLD as a country code Top Level Domain intended to serve businesses, individuals, and not-for-profit organizations with a residence or bona fide presence in the United States, the District of Columbia, or any of the United States possessions or territories, as well as state and local governments. The Contractor shall implement a United States Nexus Requirement policy which ensures that only those individuals or organizations that have a substantive lawful connection to the United States are permitted to be usTLD domain name registrants.

6.17.1 Nexus Categories Registrants in the usTLD must fall into one of three Nexus Categories, being either:

6.17.1.1 A natural person (i) who is a United States citizen, (ii) who is a permanent resident of the United States of America or any of its possessions or territories, or (iii) whose primary place of domicile is in the United States of America, the District of Columbia, or any of the United States possessions or territories [Nexus Category 1],

6.17.1.2 A United States entity or organization that is (i) incorporated within one of the fifty (50) U.S. states, the District of Columbia, or any of the United States possessions or territories, or (ii) organized or otherwise constituted under the laws of a state of the United States of America, the District of Columbia, or any of its possessions or territories (including a federal, state, or local government of the United States or a political subdivision thereof, and non-commercial organizations based in the United States) [Nexus Category 2], or

6.17.1.3 A foreign entity or organization that has a bona fide presence in the United States of America the District of Columbia, or any of the United States possessions or territories such that that presence is a substantive lawful connection to the United States and the entity is therefore subject to the jurisdiction of the United States [Nexus Category 3].

6.17.2 Nexus Compliance and Enforcement:

WS Submission: The Contractor shall detail how it would ensure that the United States Nexus Requirement is implemented effectively and continuously throughout the usTLD through compliance and enforcement programs. At a minimum, this WS submission shall address:

• Registrar requirements for the implementation of Nexus validation and verification review measures that meet or exceed industry best practices;

• The use of tools and industry best practices for the Contractor to receive and process complaints, reports, and analysis to determine Nexus non-compliance; and effective enforcement processes, including:

o A structured plan for conducting a defined number of random registrant audits per month.

11 | P a g e o An initial audit on the current registrant database to determine gaps in Nexus compliance and, if necessary, include a process to ensure the current registrant database reflects accurate data.

6.17.3 Nexus Disputes. The Contractor shall establish a Nexus Dispute Policy that sets forth the terms and conditions in connection with a dispute between the Registrant and any party, other than the Registrar or the Contractor, over the registration and use of an internet domain name registered in violation of the Nexus Requirements.

6.18 DNS Abuse and Other Malicious Conduct in the usTLD

WS Submission: The Contractor will detail comprehensive policy approaches for the prevention, disruption, and mitigation of malicious conduct in the usTLD, including DNS Abuse and practices that harm, mislead, or confuse consumers. DNS Abuse includes techniques that harm consumers, such as malware (including ransomware), botnets, phishing, pharming, and spam (when spam serves as a delivery mechanism for the other forms of DNS Abuse).

Approaches should meet or exceed industry best practices regarding DNS abuse mitigation and include, at a minimum, the following:

6.18.1 Contractor DNS Abuse Point of Contact provided to the CO/COR which can be shared with U.S. Government agencies for managing DNS Abuse and other cases of malicious conduct.

6.18.2 Proactive DNS Abuse Measures to proactively prevent DNS Abuse.

Specifically, the Contractor shall present automated tools, monitoring systems, incentive programs, or early-warning mechanisms that would effectively detect potential threats and preemptively safeguard the usTLD.

The Contractor must detail how it would adapt to emerging DNS Abuse tactics, and what strategies the Contractor would put in place to minimize the risk of abuse before it occurs. The Contractor must detail how they would incentivize and/or require Registrars to take action to prevent and/or mitigate DNS Abuse.

6.18.3 Evidence-Based DNS Abuse Reporting must be used to track, document, and analyze DNS Abuse incidents. The Contractor will include examples of the types of data and metrics the vendor would collect, as well as how this data would be used to act against DNS Abuse. The Contractor will offer solutions that ensure the accuracy, reliability and transparency of DNS Abuse reports, and detail the proposed mechanisms that would verify and validate the integrity of the data.

6.18.4 Reactive DNS Abuse Measures the Contractor would use to outline the process that the Contractor will use, including the obligations of Registrars, to address reports of DNS Abuse (e.g., the different responsibilities between the Registry and the Registrar in the application of EPP codes to a registration, and the Registrars’ obligations towards the Registrant).

12 | P a g e

6.18.5 Transparency Reporting mechanisms that describe the actions the Registry would take in response to DNS Abuse, trusted notifier activity, Intellectual Property Rights infringement, court orders, and requests from law enforcement. For each area, The Contractor will outline the frequency level of detail, and key metrics that would be included in these reports.

Contractor should describe how and when these reports would be made public, shared with researchers, as well as provided to CO/COR.

6.18.6 Due Process and Appeals Mechanisms for Anti-Abuse Actions that allow Registrants to appeal actions taken under any applicable anti-abuse policies. Specifically, the Contractor must outline the steps that would be involved in the appeal process, including any timelines, fees, and requirements for Registrants. These plans must disclose mechanisms through which, when applicable, Registrants can appeal decisions to an independent third party. Further, the Contractor should offer recommendations on the type of third-party entities that should be involved in the appeals process. Finally, the Contractor must detail how its plan would align to the principles of fairness and transparency while adhering to relevant legal and regulatory standards in handling appeals.

6.19 Trusted Notifiers

WS Submission: The Contractor will detail trusted notifier arrangements to address website content abuses associated with usTLD registrations including, at a minimum, Child Sexual Abuse Materials (CSAM), the illicit distribution of opioids and narcotics online, business/governmental “impersonation,” commercial piracy, and other illegal or abusive website content within the usTLD. The Contractor must detail how it will utilize expert third-party organizations and trusted partnerships in these areas (e.g., law enforcement, government agencies, NGOs, or industry groups) to ensure a comprehensive and effective response to website content abuse. The Contractor must outline a plan to ensure that these collaborations inform and enhance the aforementioned approach to addressing website content abuses associated with usTLD registrations.

6.20 Intellectual Property Protection. In addition to the Trusted Notifier program noted above, the Contractor shall adequately protect intellectual property in the usTLD through at least the following means. In the event of further expansion of the usTLD space, the Contractor shall implement: 1) a "sunrise period" for qualified trademark owners to pre-register their trademarks as domain names prior to the wider registration for non-trademark owners; and 2) a dispute resolution procedure to address "cybersquatting" conflicts between trademarks and domain names in the usTLD.

6.21 usTLD Locality Space. The usTLD Locality Space is a unique and historical aspect of the usTLD based upon the political geography of the United States. The

13 | P a g e

Contractor shall, at a minimum, incorporate the following into its policies and procedures for the locality-based usTLD structure:

6.21.1 The Contractor shall provide service and support for existing delegees and registrants in the locality-based usTLD structure.

6.21.2 The Contractor shall develop and implement a procedure and a mechanism to ensure all delegated managers abide by usTLD policies and maintain certain minimum technical and service requirements for the locality spaces that they serve. This shall include, at a minimum, the following:

6.21.2.1 The Contractor shall develop or continue appropriate minimum technical and service requirements for delegated managers;

6.21.2.2 The Contractor shall develop a mechanism that facilitates each delegated manager's compliance with usTLD policies and requirements;

6.21.2.3 With the consent of the CO and COR, the Contractor shall rescind the delegation for delegated managers unwilling to agree to or abide by the usTLD policies and maintain minimum technical and service requirements;

6.21.2.4 The Contractor shall serve as the delegated manager for a locality space when the Contractor has rescinded the delegation for any delegated manager as described in (3) above, or when the delegated manager for that locality space voluntarily relinquishes its delegation or seeks to change its status to become a locality registrant;

6.21.3 Provide Services for Undelegated Third Level Sub-Domains. The Contractor as the usTLD Administrator shall provide direct registry and registrar services for all other undelegated third-level locality sub-domains, including services for those names registered below CO (county) and CI (city) (e.g., Montgomery.co.us), and, undelegated affinity domains, such as those names registered below STATE, FED, K12, LIB, and NSN (e.g., agency.fed.us). This technical service may be subcontracted with the prior approval of the CO and COR.

6.21.4 Maintain Modernized Locality-Based usTLD Processes. The Contractor must safeguard the usTLD Delegated space by focusing, at a minimum, on: the current status (ensuring the Contractor accounts for all locality-based registrants at all levels); Delegated Managers; regular audits (including meeting minimum service requirements and compliance with usTLD policies); trends and updates; and proposed changes of services for those that remain utilizing this space, including both those administered by the Contractor and those administered by Delegated Managers. The Contractor must detail transition plans for existing locality-based registrants from Delegated Managers that may close operations, are otherwise not providing adequate services, etc.

6.21.5 Maintain and Update a usTLD Delegated Manager Database. The Contractor shall maintain and update a Delegated Manager Database with

14 | P a g e accurate, verified, and validated contact information for all Delegated Managers in the usTLD, including locality-level and affinity second-level (where delegated) administrators and, where applicable, for all sub-delegations made by such locality-level or second level administrators. This information will be contained in the usTLD Database described below in 6.22.

6.21.5.1 The Delegated Manager Database shall, at a minimum, consist of the following elements:

6.21.5.1.1 The name of the delegated manager;

6.21.5.1.2 The Internet Protocol (IP) address of the primary nameserver and secondary nameserver(s) for the delegation, if used;

6.21.5.1.3 corresponding names of such nameservers;

6.21.5.1.4 The date of delegation;

6.21.5.1.5 The name, postal address, e-mail address, and telephone number of the delegated manager;

6.21.5.1.6 The name, postal address, e-mail address, and telephone number of the technical contact for the delegated manager;

6.21.5.1.7 The name, postal address, e-mail address, and telephone number of the administrative contact for the delegated manager;

6.21.5.1.8 The website or other contact information through which the delegated manager accepts registrations under that delegation;

and

6.21.5.1.9 The Nexus category for the delegated manager and each of the other contacts listed above.

6.22 usTLD Registration Data. The Contractor shall maintain and update a usTLD registration data database (usTLD Database) with accurate, verified, and validated contact information for all usTLD registrations, including locality space registrations and delegated manager information. The Contractor shall operate the usTLD Database at the registry level (not at the level of individual accredited Registrars, i.e., not a thin Registry database) and shall ensure that Registrant data is not openly published online.

6.22.1 The usTLD Database, at a minimum, shall consist of the following elements:

6.22.1.1 The name of the second level domain registered;

6.22.1.2 The IP address of the primary nameserver and secondary nameserver(s) for the registered domain name;

6.22.1.3 The corresponding names of such nameservers;

6.22.1.4 The identity of the Registrar or the name of the delegated manager

(if applicable);

6.22.1.5 The creation and expiration dates of the registration;

6.22.1.6 The name, postal address, e-mail address, and telephone number of the domain name holder (Registrant);

15 | P a g e

6.22.1.7 The name, postal address, e-mail address, and telephone number of the technical contact for the domain name holder;

6.22.1.8 The name, postal address, e-mail address, and telephone number of the administrative contact for the domain name holder; and

6.22.1.9 The Nexus category for the domain name holder and technical and administrative contacts.

6.22.1.10 A means to distinguish between the information of legal and natural persons.

6.22.2 The Contractor shall establish a data escrow for usTLD zone file and domain name registration information, including all registration and Delegated Manager data. The Contractor shall provide the CO/COR with information regarding the location of the data escrow and the terms and conditions of any data escrow agreement, including security arrangements. Any such agreement must acknowledge the Department’s rights in the data.

6.22.3 The Contractor shall implement a prohibition of proxy and anonymous services offered by Registrars, Registrar affiliates and partners, and Delegated Managers. The Contractor shall regularly monitor the current practices of Registrars and Delegated Managers to ensure compliance with this requirement.

6.22.4 Secure and Accountable Access to usTLD Registration Data WS Submission: Contractor shall detail a system encompassing the necessary processes and mechanisms for managing registration data disclosures in response to legitimate, validated third-party requests. The system, with limited exceptions, must track requestor use to ensure accountability and therefore protect Registrant privacy. The Contractor must define the process for handling registration data access requests and include details on how requests are verified, assessed, and processed, and what criteria are used to determine legitimacy. It must also address, at a minimum, the following:

6.22.4.1 Defining allowable and/or disallowable access purposes and data, noting that commercial requests are not supported;

6.22.4.2 Supporting access requests for investigatory purposes from governmental and non-governmental entities;

6.22.4.3 Enabling appeals of denied disclosures and reporting of abuses;

6.22.4.4 Enabling changes in applied policy as necessary;

6.22.4.5 Quality of service thresholds for availability and response time;

6.22.4.6 Enabling bulk access for cybersecurity researchers;

6.22.4.7 Returning near real time access to registration data for non-marketing uses;

6.22.4.8 Protecting the confidentiality of law enforcement investigations;

6.22.4.9 Generating data on who needs access to registration data and for what purposes;

16 | P a g e

6.22.4.10 Safeguards used to ensure the secure transmission of registration data response to requests.

6.23 Accuracy of usTLD Registration Data.

WS Submission: Contractor shall detail compliance and enforcement programs that would ensure the accuracy of registration data obtained from usTLD Registrants, including Delegated Managers and locality registrations. The Contractor must address, at a minimum:

• Registrar requirements for the validation and verification review measures that meet or exceed industry best practices;

• the use of tools and industry best practices for the Contractor to receive and process complaints, reports, and analysis to determine the accuracy of usTLD registration data;

• and effective enforcement processes.

6.24 Mutistakeholder Engagement in usTLD Policy Development Processes.

WS Submission: Contractor shall outline how they will work with NTIA to facilitate meaningful multistakeholder engagement in usTLD policy development. The Contractor will detail how it would ensure that processes are conducted in a neutral, unbiased manner, and how it would encourage broad participation by various constituencies, which may be assisted through the use of government-run processes such as a Notice of Inquiry, Request for Comment, or other mechanisms. Submissions should include or address, at a minimum, the following:

6.24.1 Specific examples of past or current advisory councils or stakeholder engagement initiatives that the Contractor has led;

6.24.2 Objectives, structure, and frequency of these engagements;

6.24.3 A description of how stakeholder input has influenced decision-making, policy development, or operational improvements in other work performed by the Contractor;

6.24.4 Strategies for engaging and incorporating feedback from stakeholders with varying interests and perspectives;

6.24.5 Key methodologies, tools, or frameworks used to facilitate meaningful stakeholder engagement.

6.25 Advocacy for and Participation in Multistakeholder Internet Governance. In particular, the Contractor, in coordination with NTIA, shall engage in the Internet Corporation of Assigned Names and Numbers (ICANN) Country Code Name Supporting Organization (ccNSO) as the usTLD Administrator.

6.25.1 WS Submission: Contractor shall provide unique, innovative, and creative concepts for participation in and support of multistakeholder internet governance in addition to ccNSO participation at ICANN. These concepts could, for example, offer an innovative solution to revitalize the IGF-USA platform or establish a standing working group for the North America TLDs.

17 | P a g e

6.26 Other Policies. Additionally, the Contractor shall implement and enforce policies concerning:

6.26.1 Registrant Acceptable Use Policy. The Contractor shall establish

Registrant acceptable use policies with strong and clearly articulated terms for the policy requirements in this RD;

6.26.2 Data Rights and Use. The Contractor shall prohibit the use of Registrant and other data obtained from Registrars and Delegated Managers for purposes other than providing usTLD administration services.

6.26.3 Domain Name Transfers. The Contractor shall implement a mechanism that facilitates the transfer of a domain name registration from one usTLD Registrar to another usTLD Registrar at the request of the domain name registrant.

6.26.4 Redemption Grace Period. The Contractor shall implement a policy that allows registrants to restore domain name within a reasonable time period after their expiration.

6.26.5 Domain Name Review. The Contractor shall implement a policy that allows the Contractor the right to reasonably refuse registration of any domain name in the usTLD.

6.26.6 Reserved Domain Names List. The Contractor shall implement a policy to manage a list of permanently reserved names not available for registration, and, if appropriate, the release of certain names that are currently reserved.

6.27 Other Innovative Concepts. The Contractor shall detail other policies, amendments to current polices in the RD or Work Statement Submissions, or additional procedures or mechanisms not mentioned in this section as necessary to fulfill the Contract's requirements and increase the use of, or otherwise facilitate continued improvement of, the usTLD. For example, the Department welcomes concepts for the modernization and possible expansion of the usTLD, including by offering Internationalized Domain Names (IDNs) at the second level.

6.28 Adhere to a Code of Conduct and Conflict of Interest Policy. The Contractor shall adopt a code of conduct requiring it to administer the usTLD impartially and without discriminating among or between eligible registrants, operate the usTLD in the public interest, and protect proprietary information of usTLD Registrars. The Contractor shall take measures to avoid any activity or situation that could compromise, or give the appearance of compromising, the impartial and objective performance of the Contract. The Contractor shall maintain a written, enforced/enforceable, conflict of interest policy7 that defines what constitutes a

7 Per FAR 52.203-16 Preventing Personal Conflicts of Interest, “Personal conflict of interest means a situation in which a covered employee has a financial interest, personal activity, or relationship that could impair the employee’s ability to act impartially and in the best interest of the Government when performing under the

18 | P a g e potential or actual conflict of interest for the Contractor. At a minimum, this policy must address conflicts based on personal relationships or bias, financial conflicts of interest, possible direct or indirect financial gain from Contractor's policy decisions, and employment and post-employment activities. The conflict of interest policy must include appropriate sanctions in case of non-compliance, including suspension, dismissal, and/or other penalties.

6.29 Audits. The Contractor shall generate and retain security process and financial statement audit data and provide an annual audit report to the CO and COR. The Contractor shall also provide specific audit data to the CO and COR upon request.

6.30 Kids.us.

WS Submission: The Contractor shall offer one or more innovative approaches to revitalize the use of the kids.us domain that are consistent with its objective of providing a safe space on the internet for children age 13 or younger as intended by the Dot Kids Act, including how the Contractor will actively work with usTLD stakeholders, children's advocacy groups, and other interested parties in this effort.

Such alternative uses could include: employing kids.us as a proxy to automatically redirect to corresponding websites satisfying relevant guidelines (a draft of which may be included as part of the proposal); or utilizing kids.us as a resource hub for children’s health and safety on the internet, with designated subdomains addressing different stakeholders or information types. The Contractor shall prepare and submit an implementation plan for any NTIA-selected alternative. In the event a decision is made to reactivate the kids.us domain without any changes to the Dot Kids Act or selection of alternative uses, the Contractor shall be prepared to maintain and operate the second-level kids.us domain as specified by the Dot Kids Act.

7.0 Fee Overview. The Contractor shall provide a narrative overview of its fees for administration of the usTLD registry, as well as a detailed budget. The overview should include, at a minimum: 1) the wholesale price it will charge Registrars per usTLD name; 2) the fees associated with any additional services (e.g. a Secure and Accountable usTLD Registration Data Access service, DNS Abuse, registration transfer, dispute resolution processes, etc.); and 3) pricing guidance, if any, it intends to pass on to Registrars (e.g. a reduction in price based upon low DNS abuse rates, a price floor for usTLD names, or marketing incentives). All fees must be in the public interest, reasonable, and market based. The narrative overview must include appropriate justifications addressing these principles for all fees.

8.0 Period of Performance

Contract.” Examples may include, but are not limited to, gifts received, compensation or consulting relationships received or given, investment through stocks or bond ownerships, etc.

19 | P a g e

The total period of performance with all options exercised is for 7 Years from date of award.

Base Period: 3 Years Option Period I: 1 Year Option Period II: 1 Year Option Period III: 1 Year Option Period IV: 1 Year

9.0 Travel

Travel ☒ is ☐ is not required under this Contract.

The Contractor shall travel to attend ICANN and other meetings, as appropriate, to fulfill the requirements of this contract. The Contractor will be responsible for the full cost of all travel expenses.

10.0 Data Rights

The Government has unlimited rights to all documents/material produced under this Contract including all usTLD Registry Data. All documents and materials produced including all usTLD Registry Data including Locality space data, Delegated Manager Data, Registrant data and all data required to be collected or escrowed shall be Government owned and the property of the Government with all rights and privileges of ownership belonging exclusively to the Government. These documents and materials may not be used by the Contractor except as described in this RD. All materials supplied to the Government shall be the sole property of the Government. This right does not abrogate any other Government rights in the Registry Data.

11.0 Correspondence and Engagement

The CO, COR, and other Government personnel, as appropriate, may meet periodically with the Contractor to review the Contractor's performance. At these meetings the CO will apprise the Contractor of how the Government views the Contractor's performance and the Contractor will apprise the Government of problems, if any, being experienced.

Appropriate action shall be taken to resolve outstanding issues. These meetings shall be at no additional cost to the Government. The CO may use the Performance Requirements Standard to assess the performance of the Contractor. The Contractor will communicate to the CO and COR when issues arise in the operation of the usTLD.

12.0 Reports and Deliverables

The Contractor shall provide the CO and COR (CO/COR) with the reports listed, below.

The Contractor and the CO/COR will determine how and when these reports will be made public, shared with researchers, as well as provided to the CO/COR. Offerors are welcome to propose additional deliverables alongside their proposed solutions, 20 | P a g e interventions, and/or services.