ATTACHMENT J.1 Requirements Document (PWS).pdf

SHARED SERVICES PROCUREMENT OFFICE

REQUIREMENTS DOCUMENT

1 | P a g e

CUI//PROCURE//FEDCON

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 (BPOs) which put forward the baseline requirements and require the submission of Work Statements that detail policy and technical approaches that modernize, improve, and otherwise enhance the usTLD and its services.

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 President’s principal advisor on telecommunications and information policy. NTIA serves as the interagency expert on policy pertaining to governance of the internet’s unique identifier systems, including the Domain Name System (DNS), and works to ensure that the internet remains 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 to Network Solutions in a five-year contract that expired on September 30,

1998.2 Oversight of the usTLD was transferred to NTIA in 1998. In 2000, 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.3 The contract for usTLD administration was awarded in 2001. 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: 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

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

Information Administration (Aug. 3, 1998), available at: 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 Administration (Feb. 20, 1998), available at: 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 Administration (Aug. 17, 2000), available at: https://www.ntia.gov/federal-register-notice/requesting-comments-draft-statement-work-regarding-us.

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

https://www.ntia.gov/page/us-domain-space 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.rfc-editor.org/rfc/rfc1480

3 | P a g e 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 128 usTLD delegated managers as of April 2026.

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. As of April 2026, there are 13,265 locality domains in the usTLD. 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. The Contractor serves as the registrar for around 5,927 of the 13,265 locality domains.

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 one or two-character names at the second level. As of March 2026, 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 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.

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

6 A Proposal for More Privacy in Domain Name Personal Data, National Telecommunications and Information Administration (May 5, 2023), available at: https://www.ntia.gov/blog/2023/proposal-more-privacy-domain-name-personal-data.

4 | P a g e

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 ccTLD operators to follow.

3.0 Objective

The Department seeks a Contractor for the administration of the usTLD to provide the BPOs described, as well as a comprehensive Work Statement covering services sought and innovative program ideas, 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.11).

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

4.3 Affiliates of the Contractor may serve as a registrar in the usTLD space, provided that the registrar is .us-accredited (see 6.13) and signs the registry-registrar agreement (see 6.12) and;

4.3.1 the Contractor registry operator maintains strict operational, data, and governance separation from any affiliated registrars;

4.3.2 equal access, neutrality, and non-discrimination are ensured for all registrars;

and

4.3.3 effective policy, technical, organizational, and governance related obligations are met and safeguards are in place to prevent any affiliated registrar from receiving non-public, confidential, or commercially sensitive information (including data related to other registrars or their customers), and to fully mitigate any organizational conflict of interest.

4.4 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.5 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

5 | P a g e

Contractor shall ensure that Registrars further ensure Registrant compliance with this agreement.

4.6 The Contractor shall actively participate in the multistakeholder system of 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 administrator for the usTLD.

4.7 The Contractor shall coordinate with NTIA in developing paths for transparent, multistakeholder participation in usTLD policy development processes.

4.8 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.31).

4.9 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.10 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.11 The Contractor shall serve as the usTLD Administrator, overseeing all of the services listed herein (see Section 6.17). 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 the requirements and policies listed herein, including the applicable standards enumerated in section 6.0. All subcontracts and subcontract agreements are subject to prior CO and COR review and approval.

5.0 Description of Services

5.1 The Contractor shall manage and maintain the operation of 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 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.11 and 6.17.

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.

6 | P a g e

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 core 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.

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.5.1 All fees charged in connection with the usTLD must be transparent and based in the public interest, and in accordance with standards and policies set forth in this RD.

5.6 In addition, the Contractor shall not implement any major 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 General. 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.1.1 WS Submission: Detailing the teaming agreement, arrangements, and/or consortium that the Offeror would employ to fulfill the Baseline Performance Objectives, including the name, anticipated role(s), and type of agreement/arrangement sought.

6.2 Provisioning. 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 Core Registry Functions. The Contractor shall ensure the secure, stable, and

7 | P a g e reliable operation of the usTLD as it performs core usTLD registry functions, including:

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

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

6.3.3 Operation and maintenance of usTLD registry databases, as specified in

6.23;

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. See also Section 6.27;

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.3.7 WS Submission: Detailing proposed performance specifications and service levels, and associated service credits, for the core usTLD registry functions, including for scheduled maintenance, in accordance with industry standards. The proposal shall also detail the means for independent third-party measurement of compliance with performance specifications and service level agreements, as well as the Contractor’s own monitoring capabilities for reporting on adherence to its service level agreement.

6.4 Risk Management. The Contractor shall develop, implement and maintain a comprehensive risk management program in line with ISO 31000 to identify and mitigate risks to the core domain name registry functions.

6.5 Emergency Communications. The Contractor shall immediately notify the CO/COR of any significant disruption or adverse event impacting the usTLD, including, for example, major security breaches, cyberattacks, or catastrophic outages affecting overall registry operations.

6.5.1 WS Submission: A matrix detailing thresholds and timelines for reportable security or operational incidents, including DNS availability events, and escalation policies that define procedures and timelines for elevating problems to responsible parties for resolution if they are not resolved within the escalation-policy time limits.

6.6 Prohibition regarding Registrar Functions and Exceptions. The Contractor shall not serve as a registrar in the usTLD space, except for the following:

6.6.1 Reserved name registrations, including those in the kids.us second-level domain;

8 | P a g e

6.6.2 All locality domain names not serviced by a delegated manager subject to an agreement with the Contractor; and

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

6.6.4 Affiliates of the Contractor may serve as a .us registrar provided certain conditions are met, per 4.3.

6.7 IETF Standards. The Contractor shall implement applicable Internet Engineering

Task Force (IETF) RFCs and ICANN policies after consulting with, and receiving the approval of, the CO and COR.

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

6.9 Routing Security. 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 (ARIN), or the appropriate regional internet registry, or provide a valid explanation for not implementing.

6.10 Universal Acceptance. The Contractor shall demonstrate the existing or planned capabilities of their applications, services, and systems to enable the Universal Acceptance of all domain names and email addresses.

6.11 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.11.1 Information Security Risk Management. The Contractor must adopt and maintain an effective Information Security Management System in compliance with ISO 27001 or SOC2 and provide the Department with evidence of compliance, whether through a certificate of compliance or otherwise.

6.11.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 Infrastructure Security Agency’s Cybersecurity Performance Goals, to ensure a comprehensive security and privacy program of physical, technical, and organizational measures, in alignment with Section 6.11.1.

6.12 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

9 | P a g e effect to the policies included within this RD.

6.12.1 WS Submission: Detail how the Contractor would develop a usTLD

Registry-Registrar agreement that creates the conditions for a secure, innovative, and prosperous usTLD space.

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

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

6.13.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.13.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.13.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.13.3 Security Criteria. The Registrar must hold either a (i) current effective Information Security Management System certification in compliance with ISO 27001 or SOC2, or (ii) may, under circumstances determined as between the Contractor and the CO and COR, demonstrate its compliance with an equivalent security framework.

6.14 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.14.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.15 Re-Accreditation of Existing usTLD Registrars. The Contractor is required to develop a process to re-accredit existing usTLD Registrars based upon the criteria in Section 6.13. This process shall be conducted in a manner that ensures operational stability and security for the usTLD and minimizes service disruption.

Re-Accreditation shall take place within one year of the award of the contract. The

10 | P a g e process should include a timeline and incorporate, at a minimum:

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

and

6.15.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.3 WS Submission: The Contractor shall outline its proposed process for the re-accreditation of existing usTLD registrars and a registration transfer plan, as described in 6.15 and 6.16. This process may contemplate flexibilities for long-standing registrars with exemplary usTLD policy compliance, a strong security record, satisfaction of the security criteria described in 6.13.3, and a history of proactively mitigating domain name abuse. In considering its proposed re-accreditation process, the Contractor may wish to include a registrar appeal process and opportunities to cure any deficiencies.

6.16 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 usTLD registrants experience no down-time.

6.16.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.16.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 registrations. 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.16.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.17 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

11 | P a g e subcontractors.

6.17.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.

6.18 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.18.1 Nexus Categories. Registrants in the usTLD must fall into one of three Nexus Categories, being either:

6.18.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.18.1.2 A United States legal person (i.e. 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.18.1.3 A foreign legal person (i.e. 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.18.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

12 | P a g e 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 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.

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

o A plan for how the Contractor will work with a registrar to come into compliance with the registrar’s obligations with respect to nexus requirements o A plan to use the data from these audits, complaints and reports to enforce the Nexus policy including suspending or terminating registrant accounts in violation of the nexus requirements.

6.18.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 a .us domain name registered in violation of the Nexus Requirements.

6.19 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.19.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.19.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

13 | P a g e would incentivize and/or require Registrars to take action to prevent and/or mitigate DNS Abuse.

6.19.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 it proposes to collect through abuse reporting, as well as how this data would be used to act against DNS Abuse. The Contractor will explain how it plans to ensure the reliability of DNS Abuse reports received.

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

6.19.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 the CO/COR.

6.19.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.20 Trusted Notifiers.

WS Submission: The Contractor is invited to detail any trusted notifier arrangements it maintains currently, or would propose for the usTLD, to address illegal website content such as Child Sexual Abuse Materials (CSAM), the illicit distribution of opioids to Americans, or commercial piracy. Any such proposals should also describe appropriate safeguards for the protection of free speech online.

6.21 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

14 | P a g e 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.22 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 Contractor shall, at a minimum, incorporate the following into its policies and procedures for the locality-based usTLD structure:

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

6.22.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.22.2.1 The Contractor shall develop or continue appropriate minimum technical and service requirements for delegated managers;

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

6.22.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; and

6.22.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.22.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.22.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

15 | P a g e 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.22.5 Maintain and Update a usTLD Delegated Manager Database. The Contractor shall maintain and update a Delegated Manager Database with 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.23.

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

6.22.5.1.1 The name of the delegated manager;

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

6.22.5.1.3 corresponding names of such nameservers;

6.22.5.1.4 The date of delegation;

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

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

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

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

and

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

6.23 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.23.1 The usTLD Database, at a minimum, shall consist of the following elements:

6.23.1.1 The name of the second level domain registered;

16 | P a g e

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

6.23.1.3 The corresponding names of such nameservers;

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

(if applicable);

6.23.1.5 The creation and expiration dates of the registration;

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

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

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

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

6.23.1.10 A means to distinguish between the information of legal (i.e. entity or organization) and natural persons.

6.23.2 The Contractor shall establish a data escrow for usTLD zone file and domain name registration information, including all registration and Delegated Manager data. Registry data escrow deposits must be made daily, in line with RFC 8909, and with a data escrow agent based in the U.S.

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.23.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.23.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.23.4.1 Defining allowable and/or disallowable access purposes and data, noting that commercial requests are not supported;

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

17 | P a g e

6.23.4.3 Enabling appeals of denied disclosures and reporting of abuses;

6.23.4.4 Enabling changes in applied policy as necessary;

6.23.4.5 Quality of service thresholds for availability and response time;

6.23.4.6 Enabling bulk access for cybersecurity researchers;

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

6.23.4.8 Protecting the confidentiality of law enforcement investigations;

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

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

6.24 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.25 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. This should include how such engagements would maintain compliance with existing laws and regulations (e.g. the Paperwork Reduction Act and the Federal Advisory Committee Act). 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 by 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.25.1 Specific examples of past or current advisory councils or stakeholder engagement initiatives that the Contractor has led;

6.25.2 Objectives, structure, and frequency of these engagements;

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

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

6.25.5 Key methodologies, tools, or frameworks used to facilitate meaningful

18 | P a g e stakeholder engagement.

6.26 Participation in Multistakeholder Internet Governance. 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.27 Other Policies. Additionally, the Contractor shall implement and enforce policies concerning:

6.27.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.27.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. Further, the Contractor shall ensure that the confidential data and operational information, including commercially sensitive information, of each accredited usTLD registrar is protected by appropriate information controls.

6.27.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.27.4 Redemption Grace Period. The Contractor shall implement a policy that allows registrants to restore their domain name within a reasonable time period after their expiration.

6.27.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.27.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.28 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.

6.29 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 against or between eligible registrars and 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

19 | P a g e 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 potential or actual conflict of interest for the Contractor. At a minimum, this policy must address organizational conflicts, as well as 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. Finally, this policy shall outline steps the Contractor will take to mitigate any identified conflicts of interest.

6.30 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.31 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. 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

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

7 See FAR 52.203-16 Preventing Personal Conflicts of Interest; CAR 1352.209-70 Potential Conflict of Interest; and

CAR 1352.209-74 Organizational Conflict of Interest

20 | P a g e

Base Period: 36 Months (3 Years) Option Period I: 12 Months (1 Year) Option Period II: 12 Months (1 Year) Option Period III: 12 Months (1 Year) Option Period IV: 12 Months (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…