COM Registry Agreement (1 December 2024) REGISTRY AGREEMENT

(1 December 2024)

This REGISTRY AGREEMENT (this "Agreement") is entered into as of December 1, 2024 by and between Internet Corporation for Assigned Names and Numbers, a California nonprofit public benefit corporation ("ICANN"), and VeriSign, Inc. a Delaware corporation (“Verisign”). This Agreement amends and restates in its entirety the Registry Agreement, dated December 1, 2012 by and between ICANN and Verisign, as amended by the First Amendment to the .COM Registry Agreement, dated October 20, 2016, the Second Amendment to the .COM Registry Agreement, dated March 27, 2019, and the Third Amendment to the .COM Registry Agreement, dated March 27, 2020, by and between ICANN and Verisign (collectively, the “Prior Agreement”).

ARTICLE I INTRODUCTION

Section 1.1 Effective Date. The “Effective Date” for purposes of this Agreement shall be December 1, 2024.

Section 1.2 Top-Level Domain. The Top-Level Domain to which this Agreement applies is .com ("TLD").

Section 1.3 Designation as Registry Operator. Upon the Effective Date and through the Term (as defined in Section 4.1 hereof), unless earlier terminated pursuant to Article 6 hereof, ICANN shall continue to designate Verisign as the sole registry operator for the TLD ("Registry Operator").

ARTICLE II REPRESENTATIONS AND WARRANTIES

Section 2.1 Registry Operator's Representations and Warranties.

(a) Organization; Due Authorization and Execution. Registry Operator is a corporation, duly organized, validly existing and in good standing under the laws of Delaware, and Registry Operator has all requisite power and authority to enter into this Agreement. All corporate approvals and actions necessary for the entrance by Registry Operator into this Agreement have been obtained and this Agreement has been duly and validly executed and delivered by Registry Operator.

(b) Statements made During Negotiation Process. The factual statements made in writing by both parties in negotiating this Agreement were true and correct in all material respects at the time made. A violation or breach of this subsection shall not be a basis for termination, rescission or other equitable relief, and, instead shall only give rise to a claim for damages.

Section 2.2 ICANN's Representations and Warranties.

(a) Organization; Due Authorization and Execution. ICANN is a nonprofit public benefit corporation duly organized, validly existing and in good standing under the laws of California. ICANN has all requisite corporate power and authority to enter into this Agreement. All corporate approvals and actions necessary for the entrance by ICANN into this Agreement have been obtained and this Agreement has been duly and validly executed and delivered by ICANN.

ARTICLE III COVENANTS

Section 3.1 Covenants of Registry Operator. Registry Operator covenants and agrees with ICANN as follows:

(a) Preserve Security and Stability.

(i) ICANN Temporary Specifications or Policies. Registry Operator shall comply with and implement all specifications or policies established by the ICANN Board of Directors on a temporary basis, if adopted by the ICANN Board of Directors by a vote of at least two-thirds of its members, so long as the ICANN Board of Directors reasonably determines that immediate temporary establishment of a specification or policy on the subject is necessary to maintain the Stability or Security (as defined in Section 3.1(d)(iv)(G)) of Registry Services or the DNS ("Temporary Specification or Policies"). Such proposed specification or policy shall be as narrowly tailored as feasible to achieve those objectives. In establishing any specification or policy under this provision, the ICANN Board of Directors shall state the period of time for which the specification or policy is temporarily adopted and shall immediately implement the Consensus Policy development process set forth in ICANN's Bylaws. ICANN shall also issue an advisory statement containing a detailed explanation of its reasons for adopting the temporary specification or policy and why the Board believes the specification or policy should receive the consensus support of Internet stakeholders. If the period of time for which the specification or policy is adopted exceeds 90 days, the ICANN Board shall reaffirm its temporary adoption every 90 days for a total period not to exceed one year, in order to maintain such policy in effect until such time as it shall become a Consensus Policy as described in Section 3.1(b) below. If during such one year period, the temporary policy or specification does not become a Consensus Policy meeting the standard set forth in Section 3.1(b) below, Registry Operator shall no longer be required to comply with or implement such temporary policy or specification.

(b) Consensus Policies.

(i) At all times during the Term of this Agreement and subject to the terms hereof, Registry Operator will fully comply with and implement all Consensus Policies found at ▇▇▇▇▇://▇▇▇.▇▇▇▇▇.▇▇▇/▇▇▇▇▇▇▇▇▇-▇▇▇▇▇▇▇▇, as of the Effective Date and as may in the future be developed and adopted in accordance with ICANN's Bylaws and as set forth below.

(ii) "Consensus Policies" are those specifications or policies established (1) pursuant to the procedure set forth in ICANN's Bylaws and due process, and (2) covering those topics listed in Section 3.1(b)(iv) below. The Consensus Policy development process and procedure set forth in ICANN's Bylaws may be revised from time to time in accordance with ICANN's Bylaws, and any Consensus Policy that is adopted through such a revised process and covering those topics listed in Section 3.1(b)(iv) below shall be considered a Consensus Policy for purposes of this Agreement.

(iii) For all purposes under this Agreement, the policies identified at ▇▇▇▇▇://▇▇▇.▇▇▇▇▇.▇▇▇/▇▇▇▇▇▇▇▇▇-▇▇▇▇▇▇▇▇ shall be treated in the same manner and have the same effect as "Consensus Policies."

(iv) Consensus Policies and the procedures by which they are developed shall be designed to produce, to the extent possible, a consensus of Internet stakeholders, including the operators of gTLDs. Consensus Policies shall relate to one or more of the following: (1) issues for which uniform or coordinated resolution is reasonably necessary to facilitate interoperability, security and/or stability of the Internet or DNS; (2) functional and performance specifications for the provision of Registry Services (as defined in Section 3.1(d)(iii) below); (3) Security and Stability of the registry database for the TLD; (4) registry policies reasonably necessary to implement Consensus Policies relating to

registry operations or registrars; or (5) resolution of disputes regarding the registration of domain names (as opposed to the use of such domain names). Such categories of issues referred to in the preceding sentence shall include, without limitation:

(A) principles for allocation of registered names in the TLD (e.g., first-come, first-served, timely renewal, holding period after expiration);

(B) prohibitions on warehousing of or speculation in domain names by registries or registrars;

(C) reservation of registered names in the TLD that may not be registered initially or that may not be renewed due to reasons reasonably related to (a) avoidance of confusion among or misleading of users, (b) intellectual property, or (c) the technical management of the DNS or the Internet (e.g., establishment of reservations of names from registration);

(D) maintenance of and access to accurate and up-to-date information concerning domain name registrations;

(E) procedures to avoid disruptions of domain name registration due to suspension or termination of operations by a registry operator or a registrar, including procedures for allocation of responsibility for serving registered domain names in a TLD affected by such a suspension or termination; and

(F) resolution of disputes regarding whether particular parties may register or maintain registration of particular domain names.

(v) In addition to the other limitations on Consensus Policies, they shall not:

(A) prescribe or limit the price of Registry Services;

(B) modify the standards for the consideration of proposed Registry Services, including the definitions of Security and Stability (set forth below) and the standards applied by ICANN;

(D) modify ICANN's obligations to Registry Operator under Section 3.2 (a), (b), and (c);

(E) modify the limitations on Consensus Policies or Temporary Specifications or Policies;

(F) modify the definition of Registry Services;

(G) modify the terms of Sections 7.2 and 7.3, below; and

(H) alter services that have been implemented pursuant to Section 3.1(d) of this Agreement (unless justified by compelling and just cause based on Security and Stability).

(vi) Registry Operator shall be afforded a reasonable period of time following notice of the establishment of a Consensus Policy or Temporary Specifications or Policies in which to comply with such policy or specification, taking into account any urgency involved.

In the event of a conflict between Registry Services (as defined in Section 3.1(d)(iii) below), on the one hand, and Consensus Policies developed in accordance with this Section 3.1(b) or any Temporary Specifications or Policies established pursuant to Section 3.1(a)(i) above, on the other hand, the Consensus Policies or Temporary Specifications or Policies shall control, notwithstanding any other provisions contained within this Agreement.

(i) Data Escrow. Registry Operator shall establish at its expense a data escrow or mirror site policy for the Registry Data compiled by Registry Operator. Registry Data, as used in this Agreement, shall mean the following: (1) data for domains sponsored by all registrars, consisting of domain name, server name for each nameserver, registrar id, updated date, creation date, expiration date, status information, and DNSSEC delegation signer ("DS") data; (2) data for nameservers sponsored by all registrars consisting of server name, each IP address, registrar id, updated date, creation date, expiration date, and status information; (3) data for registrars sponsoring registered domains and nameservers, consisting of registrar id, registrar address, registrar telephone number, registrar e-mail address, whois server (which shall continue to be provided after January 28, 2025, if provided by registrar), referral URL, updated date and the name, telephone number, and e-mail address of all the registrar's administrative, billing, and technical contacts; and (4) any domain name registrant data collected by the Registry Operator from registrars as part of or following registration of a domain name. The escrow agent or mirror-site manager, and the obligations thereof, shall be mutually agreed upon by ICANN and Registry Operator on commercially reasonable standards that are technically and practically sufficient to allow a successor registry operator to assume management of the TLD. Registry Operator shall comply with the registry data escrow specifications set forth in Appendix 1 (Data Escrow Specification) and the parties will comply with the executed Escrow Agreement substantially in the form of Appendix 2 (Escrow Agreement (Template Format)).

(ii) Personal Data. Registry Operator shall notify registrars sponsoring registrations in the registry for the TLD of the purposes for which Personal Data (as defined below) submitted to Registry Operator by registrars, if any, is collected, the intended recipients (or categories of recipients) of such Personal Data, and the mechanism for access to and correction of such Personal Data. Registry Operator shall take reasonable steps to protect Personal Data from loss, misuse, unauthorized disclosure, alteration or destruction. Registry Operator shall not use or authorize the use of Personal Data in a way that is incompatible with the notice provided to registrars. "Personal Data" shall refer to all data about any identified or identifiable natural person.

(iii) Bulk Zone File Access. Registry Operator will make available bulk access to zone files to third parties and ICANN in accordance with the terms of Appendix 3 (Zone File Access).

(iv) Monthly Reporting. Within twenty (20) calendar days following the end of each calendar month, Registry Operator shall prepare and deliver to ICANN reports providing such data, and in the format, set forth in Appendix 4 (Format and Content for Registry Operator Monthly Reporting).

(v) Registration Data Directory Services. Registry Operator shall provide the registration data as set forth in Appendix 5A (Registration Data Publication Services Specification) and Appendix 5B (Registration Data Access Protocol Service Specification) relevant to the type of top level domain operated (e.g. “thick” or “thin” registry model). As of the Effective Date, the TLD is a “thin” registry model.

(vi) [RESERVED]

(vii) Public Interest Commitments. Registry Operator shall comply with the public interest commitments set forth in Appendix 11 (Public Interest Commitments).

(d) Registry Operations.

(i) Registration Restrictions. Registry Operator shall reserve, and not register any TLD strings appearing on the list of reserved TLD strings attached as Appendix 6 hereto.

(ii) Functional and Performance Specifications. Functional and Performance Specifications for operation of the TLD shall be as set forth in Appendix 7 (Functional and Performance Specifications), Section 3 of Appendix 5B (Service Level Requirements) and Section 4.5 of Appendix 5B (No Interference) hereto, and shall address without limitation DNS services; operation of the shared registration system; RDDS; and nameserver operations. Registry Operator shall keep technical and operational records sufficient to evidence compliance with such specifications for at least one year.

(iii) Registry Services. Registry Services are, for purposes of this Agreement, defined as the following: (a) those services that are both (i) operations of the registry critical to the following tasks: the receipt of data from registrars concerning registrations of domain names and name servers; provision to registrars of status information relating to the zone servers for the TLD; dissemination of TLD zone files; operation of the registry zone servers; and dissemination of contact and other information concerning domain name server registrations in the TLD as required by this Agreement; and (ii) provided by the Registry Operator for the .com registry as of March 31, 2006, as the case may be; (b) other products or services that the Registry Operator is required to provide because of the establishment of a Consensus Policy (as defined in Section 3.1(b) above); (c) any other products or services that only a registry operator is capable of providing, by reason of its designation as the registry operator; and (d) material changes to any Registry Service within the scope of (a), (b) or (c) above. Only Registry Services defined in (a) and (b) above are subject to the maximum price provisions of Section 7.3, below.

(iv) Process for Consideration of Proposed Registry Services. Following written notification by Registry Operator to ICANN that Registry Operator may make a change in a Registry Service within the scope of the preceding paragraph:

(A) ICANN shall have 15 calendar days to make a "preliminary determination" whether a Registry Service requires further consideration by ICANN because it reasonably determines such Registry Service: (i) could raise significant Security or Stability issues or (ii) could raise significant competition issues.

(B) Registry Operator must provide sufficient information at the time of notification to ICANN that it may implement such a proposed Registry Service to enable ICANN to make an informed "preliminary determination." Information provided by Registry Operator and marked "CONFIDENTIAL" shall be treated as confidential by ICANN. Registry Operator will not designate "CONFIDENTIAL" information necessary to describe the purpose of the proposed Registry Service and the effect on users of the DNS.

(C) ICANN may seek expert advice during the preliminary determination period (from entities or persons subject to confidentiality agreements) on the competition, Security or Stability implications of the Registry Service in order to make its "preliminary determination." To the extent ICANN determines to disclose confidential information to any such experts, it will provide notice to Registry Operator of the identity of the expert(s) and the information it intends to convey.

(D) If ICANN determines during the 15 calendar day "preliminary determination" period that the proposed Registry Service, does not raise significant Security or Stability (as defined below), or competition issues, Registry Operator shall be free to deploy it upon such a determination.

(E) In the event ICANN reasonably determines during the 15 calendar day "preliminary determination" period that the Registry Service might raise significant competition issues, ICANN shall refer the issue to the appropriate governmental competition authority or authorities with jurisdiction over the matter within five business days of making its determination, or two business days following the expiration of such 15 day period, whichever is earlier, with notice to Registry Operator. Any such referral communication shall be posted on ICANN's website on the date of transmittal. Following such referral, ICANN shall have no further responsibility, and Registry Operator shall have no further obligation to ICANN, with respect to any competition issues relating to the Registry Service. If such a referral occurs, the Registry Operator will not deploy the Registry Service until 45 calendar days following the referral, unless earlier cleared by the referred governmental competition authority.

(F) In the event that ICANN reasonably determines during the 15 calendar day "preliminary determination" period that the proposed Registry Service might raise significant Stability or Security issues (as defined below), ICANN will refer the proposal to a Standing Panel of experts (as defined below) within five business days of making its determination, or two business days following the expiration of such 15 day period, whichever is earlier, and simultaneously invite public comment on the proposal. The Standing Panel shall have 45 calendar days from the referral to prepare a written report regarding the proposed Registry Service's effect on Security or Stability (as defined below), which report (along with a summary of any public comments) shall be forwarded to the ICANN Board. The report shall set forward the opinions of the Standing Panel, including, but not limited to, a detailed statement of the analysis, reasons, and information upon which the panel has relied in reaching their conclusions, along with the response to any specific questions that were included in the referral from ICANN staff. Upon ICANN's referral to the Standing Panel, Registry Operator may submit additional information or analyses regarding the likely effect on Security or Stability of the Registry Service.

(G) Upon its evaluation of the proposed Registry Service, the Standing Panel will report on the likelihood and materiality of the proposed Registry Service's effects on Security or Stability, including whether the proposed Registry Service creates a reasonable risk of a meaningful adverse effect on Security or Stability as defined below:

Security: For purposes of this Agreement, an effect on security by the proposed Registry Service shall mean (1) the unauthorized disclosure, alteration, insertion or destruction of Registry Data, or (2) the unauthorized access to or disclosure of information or resources on the Internet by systems operating in accordance with all applicable standards.

Stability: For purposes of this Agreement, an effect on stability shall mean that the proposed Registry Service (1) is not compliant with applicable relevant standards that are authoritative and published by a well-established, recognized and authoritative standards body, such as relevant Standards-Track or Best Current Practice RFCs sponsored by the IETF or (2) creates a condition that adversely affects the throughput, response time, consistency or coherence of responses to Internet servers or end systems, operating in accordance with applicable relevant standards that are authoritative and published by a well-established, recognized and authoritative standards body, such as relevant Standards-Track or Best Current Practice RFCs and relying on Registry Operator's delegation information or provisioning services.

(H) Following receipt of the Standing Panel's report, which will be posted (with appropriate confidentiality redactions made after consultation with Registry Operator) and available for public

comment, the ICANN Board will have 30 calendar days to reach a decision. In the event the ICANN Board reasonably determines that the proposed Registry Service creates a reasonable risk of a meaningful adverse effect on Stability or Security, Registry Operator will not offer the proposed Registry Service. An unredacted version of the Standing Panel's report shall be provided to Registry Operator upon the posting of the report. The Registry Operator may respond to the report of the Standing Panel or otherwise submit to the ICANN Board additional information or analyses regarding the likely effect on Security or Stability of the Registry Service.

(I) The Standing Panel shall consist of a total of 20 persons expert in the design, management and implementation of the complex systems and standards-protocols utilized in the Internet infrastructure and DNS (the "Standing Panel"). The members of the Standing Panel will be selected by its Chair. The Chair of the Standing Panel will be a person who is agreeable to both ICANN and the registry constituency of the supporting organization then responsible for generic top level domain registry policies. All members of the Standing Panel and the Chair shall execute an agreement requiring that they shall consider the issues before the panel neutrally and according to the definitions of Security and Stability. For each matter referred to the Standing Panel, the Chair shall select no more than five members from the Standing Panel to evaluate the referred matter, none of which shall have an existing competitive, financial, or legal conflict of interest, and with due regard to the particular technical issues raised by the referral.

(e) Fees and Payments. Registry Operator shall pay the Registry-Level Fees to ICANN on a quarterly basis in accordance with Section 7.2 hereof.

(f) Traffic Data. Nothing in this Agreement shall preclude Registry Operator from making commercial use of, or collecting, traffic data regarding domain names or non-existent domain names for purposes such as, without limitation, the determination of the availability and Security and Stability of the Internet, pinpointing specific points of failure, characterizing attacks and misconfigurations, identifying compromised networks and hosts, and promoting the sale of domain names; provided, however, that such use does not disclose domain name registrant, end user information or other Personal Data as defined in Section 3.1(c)(ii) for any purpose not otherwise authorized by this Agreement. In this regard, in the event the TLD registry is a "thick" registry model, the traffic data that may be accessible to and used by Registry Operator shall be limited to the data that would be accessible to a registry operated under a "thin" registry model. The process for the introduction of new Registry Services shall not apply to such traffic data. Nothing contained in this Section 3.1(f) shall be deemed to constitute consent or acquiescence by ICANN to a re-introduction by Registry Operator of the SiteFinder service previously introduced by the Registry Operator on or about September 15, 2003, or the introduction of any other service employing a universal wildcard function, except that this sentence shall not prohibit the provision of nameservice or any other non-registry service for a domain or zone used for other than registration services to unaffiliated third parties by a single entity (including its affiliates) for domain names registered through an ICANN-accredited registrar. To the extent that traffic data subject to this provision is made available, access shall be on terms that are non-discriminatory.

(g) Security and Stability Review. Twice annually Registry Operator shall engage in discussions with executive staff of ICANN and the Chairman of the Board of ICANN on trends impacting the Security and/or Stability of the Registry, the DNS or the Internet pursuant to the terms of confidentiality agreements executed both by the executive staff of ICANN and the Chairman of the Board.

(h) Business Continuity. To preserve and enhance the security, stability and resiliency of the TLD and the Internet, Registry Operator and ICANN agree that internal subject matter experts in critical registry functions, operations and security from both parties will meet and discuss how: (i) the parties may address business continuity under various scenarios, including appropriate criteria for triggering any business continuity mechanisms; and (ii) to mitigate risks to the TLD and Internet resulting from such business continuity scenarios. Such discussions will be held every month at a time and place mutually agreed to by the parties and shall occur over a period of at least 180 days following the Effective Date, unless the parties agree to a shorter time frame in writing (which may be via email). Following completion of the discussions described herein, the parties will use commercially reasonable efforts to determine the implementation of any business continuity practices that are reasonably appropriate for the TLD. The parties agree that such implementation may include amendments to this Agreement mutually agreed upon by the parties in writing.

Section 3.2 Covenants of ICANN. ICANN covenants and agrees with Registry Operator as follows:

(a) Open and Transparent. Consistent with ICANN's expressed mission and core values, ICANN shall operate in an open and transparent manner.

(b) Equitable Treatment. ICANN shall not apply standards, policies, procedures or practices arbitrarily, unjustifiably, or inequitably and shall not single out Registry Operator for disparate treatment unless justified by substantial and reasonable cause.

(c) TLD Zone Servers. In the event and to the extent that ICANN is authorized to set policy with regard to an authoritative root server system, it will ensure that (i) the authoritative root will point to the TLD zone servers designated by Registry Operator for the Registry TLD throughout the Term of this Agreement; and (ii) any changes to the TLD zone server designation submitted to ICANN by Registry Operator will be implemented by ICANN within seven days of submission.

(d) Nameserver Changes. Registry Operator may request changes in the nameserver delegation for the Registry TLD. Any such request must be made in a format, and otherwise meet technical requirements, specified from time to time by ICANN. ICANN will use commercially reasonable efforts to have such requests implemented in the Authoritative Root-Server System within seven calendar days of the submission.

(e) Root-zone Information Publication. ICANN's publication of root-zone contact information for the Registry TLD will include Registry Operator and its administrative and technical contacts. Any request to modify the contact information for the Registry Operator must be made in the format specified from time to time by ICANN.

Section 3.3 Cooperation. The parties agree to cooperate with each other and share data as necessary to accomplish the terms of this Agreement.

Section 3.4 Contractual and Operational Compliance Audits.

(a) ICANN may from time to time (not to exceed once per calendar quarter) conduct, or engage a third party to conduct, contractual compliance audits to assess compliance by Registry Operator with its representations and warranties contained in Article II of this Agreement and its covenants contained in Article III of this Agreement. Such audits shall be tailored to achieve the purpose of assessing compliance, and ICANN will (i) give reasonable advance notice of any such audit, which notice shall specify in reasonable detail the categories of documents, data and other information

requested by ICANN, and (ii) use commercially reasonable efforts to conduct such audit in such a manner as to not unreasonably disrupt the operations of Registry Operator. As part of such audit and upon request by ICANN, Registry Operator shall timely provide all responsive documents, data and any other information necessary to demonstrate Registry Operator's compliance with this Agreement. Upon no less than five (5) business days notice (unless otherwise agreed to by Registry Operator), ICANN may, as part of any contractual compliance audit, conduct site visits during regular business hours to assess compliance by Registry Operator with its covenants contained in Section 3.1.

(b) Any audit conducted pursuant to Section 3.4(a) will be at ICANN's expense, unless (i) the audit relates to Registry Operator's compliance with Section 3.1(c)(iv) and such audit reveals a material discrepancy or discrepancies in the data provided by Registry Operator, or (ii) the audit is related to a discrepancy in the fees paid by Registry Operator hereunder in excess of 5% to ICANN's detriment. In either such case of (i) or (ii) above, Registry Operator shall reimburse ICANN for all reasonable costs and expenses associated with such audit and such reimbursement will be paid together with the next Registry-Level Fee payment due following the date of transmittal of the cost statement for such audit.

ARTICLE IV TERM OF AGREEMENT

Section 4.1 Term. The term of this Agreement shall begin on the Effective Date and continue through November 30, 2030 (“Initial Registry Agreement Term”), as extended by any renewal terms pursuant to Section 4.2 (Renewal) (each a “Renewal Registry Agreement Term”). Together the Initial Registry Agreement Term and all Renewal Registry Agreement Terms shall constitute the (“Term”).

Section 4.2 Renewal. This Agreement shall be renewed upon the expiration of the Initial Registry Agreement Term set forth in Section 4.1 above and each Renewal Registry Agreement Term, unless the following has occurred: (i) following notice of breach to Registry Operator in accordance with Section 6.1 and failure to cure such breach within the time period prescribed in Section 6.1, an arbitrator or court has determined that Registry Operator has been in fundamental and material breach of Registry Operator's obligations set forth in Sections 3.1(a), (b), (d) or (e); Section 5.2 or Section 7.3 and (ii) following the final decision of such arbitrator or court, Registry Operator has failed to comply within ten days with the decision of the arbitrator or court, or within such other time period as may be prescribed by the arbitrator or court. Upon renewal, in the event that the terms of this Agreement are not similar to the terms generally in effect in the Registry Agreements of the 5 largest gTLDs (determined by the number of domain name registrations under management at the time of renewal), renewal shall be upon terms reasonably necessary to render the terms of this Agreement similar to such terms in the Registry Agreements for those other gTLDs. The preceding sentence, however, shall not apply to the terms of this Agreement regarding the price of Registry Services; the standards for the consideration of proposed Registry Services, including the definitions of Security and Stability and the standards applied by ICANN in the consideration process; the terms or conditions for the renewal or termination of this Agreement; ICANN's obligations to Registry Operator under Section 3.2 (a), (b), and (c); the limitations on Consensus Policies or Temporary Specifications or Policies; the definition of Registry Services; or the terms of Section 7.3.

Section 4.3 Failure to Perform in Good Faith. In the event Registry Operator shall have been repeatedly and willfully in fundamental and material breach of Registry Operator's obligations set forth in Sections 3.1(a), (b), (d) or (e); Section 5.2 or Section 7.3, and arbitrators in accordance with Section 5.1(b) of this Agreement repeatedly have found Registry Operator to have been in

fundamental and material breach of this Agreement, including in at least three separate awards, then the arbitrators shall award such punitive, exemplary or other damages as they may believe appropriate under the circumstances.

ARTICLE V DISPUTE RESOLUTION

Section 5.1 Resolution of Disputes.

(a) Cooperative Engagement. In the event of a disagreement between Registry Operator and ICANN arising under or out of this Agreement, either party may by notice to the other invoke the dispute resolution provisions of this Article V. Provided, however, that before either party may initiate arbitration as provided in Section 5.1(b) below, ICANN and Registry Operator must attempt to resolve the dispute by cooperative engagement as set forth in this Section 5.1(a). If either party provides written notice to the other demanding cooperative engagement as set forth in this Section 5.1(a), then each party will, within seven calendar days after such written notice is deemed received in accordance with Section 8.8 hereof, designate a single executive officer as its representative under this Section 5.1(a) with full authority to act on such party's behalf to resolve the dispute. The designated representatives shall, within 2 business days after being designated, confer by telephone or in person to attempt to resolve the dispute. If they are not able to resolve the dispute during such telephone conference or meeting, they shall further meet in person at a location reasonably designated by ICANN within 7 calendar days after such initial telephone conference or meeting, at which meeting the parties shall attempt to reach a definitive resolution. The time schedule and process set forth in this Section 5.1(a) may be modified with respect to any dispute, but only if both parties agree to a revised time schedule or process in writing in advance. Settlement communications within the scope of this paragraph shall be inadmissible in any arbitration or litigation between the parties.

(b) Arbitration. Disputes arising under or in connection with this Agreement, including requests for specific performance, shall be resolved through binding arbitration conducted as provided in this Section 5.1(b) pursuant to the rules of the International Court of Arbitration of the International Chamber of Commerce ("ICC"). The arbitration shall be conducted in the English language and shall occur in Los Angeles County, California, USA only following the failure to resolve the dispute pursuant to cooperative engagement discussions as set forth in Section 5.1(a) above. There shall be three arbitrators: each party shall choose one arbitrator and, if the two arbitrators are not able to agree on a third arbitrator, the third shall be chosen by the ICC. The prevailing party in the arbitration shall have the right to recover its costs and reasonable attorneys' fees, which the arbitrators shall include in their awards. Any party that seeks to confirm or vacate an arbitration award issued under this Section 5.1(b) may do so only pursuant to the applicable arbitration statutes. In any litigation involving ICANN concerning this Agreement, jurisdiction and exclusive venue for such litigation shall be in a court located in Los Angeles County, California, USA; however, the parties shall also have the right to enforce a judgment of such a court in any court of competent jurisdiction. For the purpose of aiding the arbitration and/or preserving the rights of the parties during the pendency of an arbitration, the parties shall have the right to seek a temporary stay or injunctive relief from the arbitration panel or a court, which shall not be a waiver of this agreement to arbitrate.

Section 5.2 Specific Performance. Registry Operator and ICANN agree that irreparable damage could occur if any of the provisions of this Agreement was not performed in accordance with its specific terms. Accordingly, the parties agree that they each shall be entitled to seek from the arbitrators

specific performance of the terms of this Agreement (in addition to any other remedy to which each party is entitled).

Section 5.3 Limitation of Liability. ICANN's aggregate monetary liability for violations of this Agreement shall not exceed an amount equal to the Registry-Level Fees paid by Registry Operator to ICANN within the preceding twelve-month period pursuant to Section 7.2 of this Agreement. Registry Operator's aggregate monetary liability to ICANN for violations of this Agreement shall be limited to an amount equal to the fees and monetary sanctions, if any, due and owing to ICANN under this Agreement within the preceding twelve month period. In no event shall either party be liable for special, indirect, incidental, punitive, exemplary, or consequential damages arising out of or in connection with this Agreement or the performance or nonperformance of obligations undertaken in this Agreement, except as provided pursuant to Section 4.3 of this Agreement. EXCEPT AS OTHERWISE EXPRESSLY PROVIDED IN THIS AGREEMENT, REGISTRY OPERATOR DOES NOT MAKE ANY WARRANTY, EXPRESS OR IMPLIED, WITH RESPECT TO THE SERVICES RENDERED BY ITSELF, ITS SERVANTS, OR ITS AGENTS OR THE RESULTS OBTAINED FROM THEIR WORK, INCLUDING, WITHOUT LIMITATION, ANY IMPLIED WARRANTY OF MERCHANTABILITY, NON-INFRINGEMENT, OR FITNESS FOR A PARTICULAR PURPOSE.

ARTICLE VI TERMINATION PROVISIONS

Section 6.1 Termination by ICANN. ICANN may terminate this Agreement if and only if: (i) Registry Operator fails to cure any fundamental and material breach of Registry Operator's obligations set forth in Sections 3.1(a), (b), (d) or (e); Section 5.2 or Section 7.3 within thirty calendar days after ICANN gives Registry Operator written notice of the breach, which notice shall include with specificity the details of the alleged breach; and (ii) (a) an arbitrator or court has finally determined that Registry Operator is, or was, in fundamental and material breach and failed to cure such breach within the prescribed time period and (b) following the decision of such arbitrator or court, Registry Operator has failed to comply with the decision of the arbitrator or court.

Section 6.2 Bankruptcy. This Agreement shall automatically terminate in the event Registry Operator shall voluntarily or involuntarily be subject to bankruptcy proceedings.

Section 6.3 Transition of Registry upon Termination of Agreement. Upon any termination of this Agreement as provided in Sections 6.1 and 6.2, the parties agree to work cooperatively to facilitate and implement the transition of the registry for the TLD in accordance with this Section 6.3. Registry Operator shall agree to provide ICANN or any successor registry authority that may be designated for the TLD with any data regarding operations of the registry for the TLD necessary to maintain operations that may be reasonably requested in addition to that data escrowed in accordance with Section 3.1(c)(i) hereof.

Section 6.4 Rights in Data. Registry Operator shall not be entitled to claim any intellectual property rights in Registry Data. In the event that Registry Data is released from escrow as set forth in Section 3.1(c)(i), rights, if any, held by Registry Operator in the data shall automatically be licensed on a non-exclusive, irrevocable, royalty-free, paid-up basis to ICANN or to a party designated in writing by ICANN.

Section 6.5 No Reimbursement. Any and all expenditures, capital investments or other investments made by Registry Operator in connection with this Agreement shall be at Registry Operator's own

risk and ICANN shall have no obligation to reimburse Registry Operator for any such expense, capital expenditure or investment. Registry Operator shall not be required to make any payments to a successor registry operator by reason of registry fees paid to Registry Operator prior to the effective date of (i) any termination or expiration of this Agreement or (ii) transition of the registry, unless any delay in transition of the registry to a successor operator shall be due to the actions of Registry Operator.

ARTICLE VII SPECIAL PROVISIONS

Section 7.1 Registry-Registrar Agreement.

(a) Access to Registry Services. Registry Operator shall make access to Registry Services, including the shared registration system, available to all ICANN-accredited registrars, subject to the terms of the Registry-Registrar Agreement attached as Appendix 8 hereto. Subject to Section 7.1(d), Registry Operator shall provide all ICANN-accredited registrars following execution of the Registry-Registrar Agreement, provided registrars are in compliance with such agreement, operational access to Registry Services, including the shared registration system for the TLD. Such nondiscriminatory access shall include without limitation the following:

(i) All registrars (including any registrar affiliated with Registry Operator, if any) can connect to the shared registration system gateway for the TLD via the Internet by utilizing the same maximum number of IP addresses and SSL certificate authentication;

(ii) Registry Operator has made the current version of the registrar toolkit software accessible to all registrars and has made any updates available to all registrars on the same schedule;

(iii) All registrars have the same level of access to customer support personnel via telephone, e-mail and Registry Operator's website;

(iv) All registrars have the same level of access to registry resources to resolve registry/registrar or registrar/registrar disputes and technical and/or administrative customer service issues;

(v) All registrars have the same level of access to data generated by Registry Operator to reconcile their registration activities from Registry Operator's Web and ftp servers;

(vi) All registrars may perform basic automated registrar account management functions using the same registrar tool made available to all registrars by Registry Operator; and

(vii) The shared registration system does not include, for purposes of providing discriminatory access, any algorithms or protocols that differentiate among registrars with respect to functionality, including database access, system priorities and overall performance.

Such Registry-Registrar Agreement may be revised by Registry Operator from time to time, provided however, that any such revisions must be approved in advance by ICANN.

(b) Registry Operator Shall Not Act as Own Registrar. Registry Operator shall not act as a registrar with respect to the TLD. This shall not preclude Registry Operator from registering names within the TLD to itself through a request made to an ICANN-accredited registrar. In addition, where there is an imminent threat to the Security and Stability of the TLD or the Internet, this provision shall not preclude Registry Operator, for the purpose of protecting the Security and Stability of the TLD or the Internet, from temporarily preventing the registration of one or more names; provided, as soon as practicable but no later than 3 business days of taking such action, Registry Operator provides ICANN with a written notice of such action, which notice shall list all affected names, state the

expected length of time that such names will not be available for registration, and explain why Registry Operator took such action. The contents of such notice shall be treated as confidential to the extent permitted by law. If ICANN disagrees with such action, it will instruct Registry Operator to release such names and Registry Operator shall immediately release such names upon receipt of such written instructions from ICANN.

(c) Restrictions on Acquisition of Ownership or Controlling Interest in Registrar. Registry Operator shall not acquire, directly or indirectly, control of, or a greater than fifteen percent ownership interest in, any ICANN-accredited registrar for the TLD.

(d) Compliance Actions. Registry Operator acknowledges that all ICANN-accredited registrars must enter into a registrar accreditation agreement ("RAA") with ICANN and ICANN may take certain compliance actions in response to an emergency or in accordance with the terms of the RAA, including suspension or termination of a registrar's accreditation or suspension of a registrar's ability to create new registered names or initiate inbound transfers of registered names. ICANN may require Registry Operator to take specific actions consistent with ICANN's authority under the terms of the RAA to: (i) suspend or terminate a registrar's ability to create new registered names or (ii) transfer registered names to a registrar designated by ICANN.

Section 7.2 Fees to be Paid to ICANN.

(a) Registry-Level Fees. Registry Operator shall pay ICANN a registry-level fee equal to (i) the “Registry Fixed Fee” of US$6,250 per calendar quarter by the 20th day following the end of each calendar quarter (i.e., on January 20, April 20, July 20, and October 20), (ii) the Registry-Level Transaction Fee (as defined below), (iii) the Sync Transaction Fee (as defined below) and (iv) the Variable Registry-Level Fee (as defined in Section 7.2(b) below) (collectively subclauses (i)-(iv), the “Registry-Level Fees”). Registry Operator shall pay ICANN a “Registry-Level Transaction Fee” equal to the number of annual increments of an initial or renewal domain name registration (at one or more levels, and including renewals associated with transfers from one ICANN-accredited registrar to another), during the applicable calendar quarter multiplied by US$0.25. Registry Operator shall pay the Registry-Level Transaction Fee by the 20th day following the end of each calendar quarter (i.e., January 20, April 20, July 20, and October 20 for the calendar quarters ending December 31, March 31, June 30, and September 30) of the year to an account designated by ICANN. For each domain name registration in the TLD for which a registrar extends the registration term pursuant to the Registry Operator’s Consolidate/Sync Service (“Sync Service”) (referenced in Appendix 9 (Approved Services)) on or after the Effective Date, Registry Operator shall pay ICANN an additional fee, prorated from the amount of US$0.25, based on the number of days the domain name registration is extended past its expiry date through the Sync Service (“Sync Transaction Fee”). Registry Operator shall pay ICANN the Sync Transaction Fee by the 20th calendar day following the end of the calendar quarter in which the Sync Services occurred (i.e., January 20, April 20, July 20, and October 20).

(b) Variable Registry-Level Fee. For fiscal quarters in which ICANN does not collect a variable accreditation fee from all registrars, upon receipt of written notice from ICANN, Registry Operator shall pay ICANN a Variable Registry-Level Fee (the “Variable Registry-Level Fee”). The fee will be calculated and invoiced by ICANN on a quarterly basis, and shall be paid by Registry Operator within sixty (60) calendar days with respect to the first quarter of such ICANN fiscal year (July 1-September 30) and within twenty (20) calendar days with respect to each remaining quarter of such ICANN

fiscal year, of receipt of the invoiced amount by ICANN. The Registry Operator will invoice and collect the fees from the registrars who are party to a Registry-Registrar Agreement with Registry Operator. The Variable Registry-Level Fee will consist of two components; each component will be calculated by ICANN for each registrar:

(i)The transactional component of the Variable Registry-Level Fee shall be specified by ICANN in accordance with the budget adopted by the ICANN Board of Directors for each ICANN fiscal year but shall not exceed US$0.25.

(ii)The per-registrar component of the Variable Registry-Level Fee shall be specified by ICANN in accordance with the budget adopted by the ICANN Board of Directors for each ICANN fiscal year.

(c) Interest on Late Payments. For any payments ten days or more overdue pursuant to Section 7.2, Registry Operator shall pay interest on late payments at the rate of 1.5% per month or, if less, the maximum rate permitted by applicable law.

(d) Adjustments to Fees. Notwithstanding any of the fee limitations on the amount of Registry-Level Fees to be paid by Registry Operator to ICANN under Section 7.2(a) or 7.2(b) of this Agreement, commencing upon December 1st of each year during the Term, the then-current fees set forth in Section 7.2(a) and Section 7.2(b) may be adjusted, at ICANN’s discretion, by a percentage equal to the percentage change, if any, in (i) the Consumer Price Index for All Urban Consumers, U.S. City Average (1982-1984 = 100) published by the United States Department of Labor, Bureau of Labor Statistics, or any successor index (the “CPI”) for the month which is one (1) month prior to the commencement of the applicable year, over (ii) the CPI published for the month which is one (1) month prior to the commencement of the immediately prior year. In the event of any such increase, ICANN shall provide notice to Registry Operator specifying the amount of such adjustment. Any fee adjustment under this Section 7.2(d) shall be effective as of the first day of the first calendar quarter following at least thirty (30) days after ICANN’s delivery to Registry Operator of such fee adjustment notice.

(e) Fee Adjustment Practice. ICANN agrees that if it exercises its right under Section 7.2(d) to adjust Registry-Level Fees, ICANN shall also exercise its right under multiple other registry agreements in a manner that does not single out Registry Operator.

(f) ICANN and Registry Operator hereby agree that if ICANN delivers notice of a fee adjustment to other registry operators after November 1, 2024 and prior to the Effective Date, ICANN may concurrently deliver such fee adjustment notice to Registry Operator, in which case the provisions of Section 7.2(d) shall be deemed to have applied at the time such notice was sent.

Section 7.3 Pricing for Domain Name Registrations and Registry Services.

(a) Scope. The Registry Services to which the provisions of this Section 7.3 shall apply are:

(i) the Registry Services defined in Section 3.1(d)(iii)(a), above, and

(ii) other products or services that the Registry Operator is required to provide within the scope of Section 3.1(d)(iii)(b), above, because of the establishment of a Consensus Policy (as defined in Section 3.1(b) above):

(1) to implement changes in the core functional or performance specifications for Registry Services (as defined in Section 3.1(d)(iii)(a)); or

(2) that are reasonably necessary to facilitate: (A) Security and/or Stability of the Internet or DNS; (B) Security and Stability of the registry database for the TLD; or (C) resolution of disputes regarding the registration of domain names (as opposed to the use of such domain names).

Nothing contained herein shall be construed to apply the provisions of this Section 7.3 to the services enumerated in Appendix 9 of this Agreement.

(b) No Tying. Registry Operator shall not require, as a condition of the provision or use of Registry Services subject to this Section 7.3 in accordance with the requirements of this Agreement, including without limitation Section 7.1 and Appendix 10, that the purchaser of such services purchase any other product or service or refrain from purchasing any other product or service. Notwithstanding any other offering that may include all or any portion of the Registry Services at any price, Registry Operator shall offer to all ICANN-accredited registrars the combination of all Registry Services subject to this Section 7.3 at a total price for those Registry Services that is no greater than the Maximum Price calculated pursuant to Section 7.3(d) and that otherwise complies with all the requirements of Section 7.3.

(c) Price for Registry Services. The price for all Registry Services subject to this Section 7.3 shall be the amount, not to exceed the Maximum Price, that Registry Operator charges for each annual increment of a new and renewal domain name registration and for each transfer of a domain name registration from one ICANN-accredited registrar to another.

(d) Maximum Price. The Maximum Price for Registry Services subject to this Section 7.3 shall be as follows:

(i) Subject to increase pursuant to Section 7.3(d)(ii) and Section 7.3(d)(iii), the Maximum Price for Registry Services shall be US $10.26;

(ii) Registry Operator is entitled to increase the Maximum Price by the smaller of (A) the Maximum Price for the preceding Pricing Year (as defined in Section 7.3(d)(iii) below), multiplied by 1.07, or (B) the highest price charged by Registry Operator for Registry Services during the preceding Pricing Year, multiplied by 1.07, and in the case of (A) or (B), in each Pricing Year of the final four Pricing Years of every six year period, with the first six year period beginning on October 26, 2018; and

(iii) Registry Operator is entitled to increase the Maximum Price by an amount sufficient to cover any additional incremental costs incurred, or to be incurred, by Registry Operator due to the imposition of any new Consensus Policy or documented extraordinary expense resulting from an attack or threat of attack on the Security or Stability of the DNS (“Consensus Policy or Documented Extraordinary Expense”) in each Pricing Year by an amount not to exceed the smaller of (A) the Maximum Price for the preceding Pricing Year, multiplied by 1.07, or (B) the highest price charged by Registry Operator for Registry Services during the preceding Pricing Year, multiplied by 1.07, provided that, Registry Operator may only increase the Maximum Price for a Consensus Policy or Documented Extraordinary Expense pursuant to this Section 7.3(d)(iii) in a Pricing Year where Registry Operator has not, and will not, increase the Maximum Price for Registry Services pursuant to Section 7.3(d)(ii) above. For purposes of Section 7.3, “Pricing Year” shall mean the period from October 26 to October 25.

(e) No price discrimination. Registry Operator shall charge the same price for Registry Services subject to this Section 7.3, not to exceed the Maximum Price, to all ICANN-accredited registrars (provided that volume discounts and marketing support and incentive programs may be made if the same opportunities to qualify for those discounts and marketing support and incentive programs is available to all ICANN-accredited registrars).

(f) Adjustments to Pricing for Domain Name Registrations. Registry Operator shall provide no less than six months prior notice in advance of any increase for new and renewal domain name registrations and for transferring a domain name registration from one ICANN-accredited registrar to another and shall continue to offer for periods of up to ten years new and renewal domain name registrations fixed at the price in effect at the time such offer is accepted. Registry Operator is not required to give notice of the imposition of the Variable Registry-Level Fee set forth in Section 7.2(b).

(g) Maximum Price does not include ICANN Variable Registry-Level Fee. The Maximum Price does not include, and shall not be calculated from a price that includes, all or any part of the ICANN Variable Registry-Level Fee set forth in Section 7.2(b), above, or any other per-name fee for new and renewal domain name registrations and for transferring a domain name registration from one ICANN-accredited registrar to another.

ARTICLE VIII MISCELLANEOUS

Section 8.1 Indemnification of ICANN.

(a) Registry Operator shall indemnify, defend, and hold harmless ICANN (including its directors, officers, employees, and agents) from and against any and all third-party claims, damages, liabilities, costs, and expenses, including reasonable legal fees and expenses, arising out of or relating to: (a) ICANN's reliance, in connection with its decision to delegate the TLD to Registry Operator or to enter into this Agreement, on information provided by Registry Operator in its application for the TLD; (b) Registry Operator's establishment or operation of the registry for the TLD; (c) Registry Operator's provision of Registry Services; (d) collection or handling of Personal Data by Registry Operator; (e) any dispute concerning registration of a domain name within the domain of the TLD for the registry; and (f) duties and obligations of Registry Operator in operating the registry for the TLD; provided that Registry Operator shall not be obligated to indemnify, defend, or hold harmless ICANN to the extent the claim, damage, liability, cost, or expense arose due to a breach by ICANN of any obligation contained in this Agreement or any willful misconduct of ICANN. For avoidance of doubt, nothing in this Section 8.1 shall be deemed to require Registry Operator to reimburse or otherwise indemnify ICANN for the costs associated with the negotiation or execution of this Agreement, or with the monitoring or management of the parties' respective obligations under this Agreement. Further, this section shall not apply to any request for attorney's fees in connection with any litigation or arbitration between or among the parties.

(b) For any claims by ICANN for indemnification whereby multiple registry operators (including Registry Operator) have engaged in the actions or omissions that gave rise to the claim, Registry Operator's aggregate liability to indemnify ICANN with respect to such claim shall be limited to a percentage of ICANN's total claim, calculated by dividing the number of total domain names under registration with Registry Operator within the TLD (which names under registration shall be calculated consistently with Section 7.2 hereof for any applicable quarter) by the total number of domain names under registration within all TLDs for which the registry operators thereof that are

engaging in the same acts or omissions giving rise to such claim. For the avoidance of doubt, in the event that a registry operator is engaged in the same acts or omissions giving rise to the claims above, but such registry operator(s) do not have the same or similar indemnification obligations to ICANN at set forth in 8.1(a) above, the number of domains under management by such registry operator(s) shall nonetheless be included in the calculation in the preceding sentence.

Section 8.2 Indemnification Procedures. If ICANN receives notice of any third-party claim that is indemnified under Section 8.1 above, ICANN shall promptly notify Registry Operator of such claim. Registry Operator shall be entitled, if it so elects, in a notice promptly delivered to ICANN, to immediately take control of the defense and investigation of such claim and to employ and engage attorneys reasonably acceptable to the indemnified party to handle and defend the same, at the indemnifying party's sole cost and expense, provided that in all events ICANN shall be entitled to control at its sole cost and expense the litigation of issues concerning the validity or interpretation of ICANN policies or conduct. ICANN shall cooperate, at its own cost, in all reasonable respects with Registry Operator and its attorneys in the investigation, trial, and defense of such claim and any appeal arising therefrom; provided, however, that the indemnified party may, at its own cost and expense, participate, through its attorneys or otherwise, in such investigation, trial and defense of such claim and any appeal arising therefrom. No settlement of a claim that involves a remedy affecting ICANN other than the payment of money in an amount that is indemnified shall be entered into without the consent of ICANN. If Registry Operator does not assume full control over the defense of a claim subject to such defense in accordance with this Section, Registry Operator may participate in such defense, at its sole cost and expense, and ICANN shall have the right to defend the claim in such manner as it may deem appropriate, at the cost and expense of Registry Operator.

Section 8.3 No Offset. All payments due under this Agreement shall be made in a timely manner throughout the Term of this Agreement and notwithstanding the pendency of any dispute (monetary or otherwise) between Registry Operator and ICANN.

Section 8.4 Use of ICANN Name and Logo. ICANN grants to Registry Operator a non-exclusive royalty-free license to state that it is designated by ICANN as the Registry Operator for the Registry TLD and to use a logo specified by ICANN to signify that Registry Operator is an ICANN-designated registry authority. This license may not be assigned or sublicensed by Registry Operator.

Section 8.5 Assignment and Subcontracting. Any assignment of this Agreement shall be effective only upon written agreement by the assignee with the other party to assume the assigning party's obligations under this Agreement. Moreover, neither party may assign this Agreement without the prior written approval of the other party, which shall not be unreasonably withheld. Notwithstanding the foregoing, ICANN may assign this Agreement in conjunction with a reorganization or re-incorporation of ICANN, to another nonprofit corporation organized for the same or substantially the same purposes. Registry Operator must provide notice to ICANN of any subcontracting arrangements, and any agreement to subcontract portions of the operations of the TLD must mandate compliance with all covenants, obligations and agreements by Registry Operator hereunder. Any subcontracting of technical operations shall provide that the subcontracted entity become party to the data escrow agreement mandated by Section 3.1(c)(i) hereof.

Section 8.6 Amendments and Waivers. No amendment, supplement, or modification of this Agreement or any provision hereof shall be binding unless executed in writing by both parties. No waiver of any provision of this Agreement shall be binding unless evidenced by a writing signed by

the party waiving compliance with such provision. No waiver of any of the provisions of this Agreement or failure to enforce any of the provisions hereof shall be deemed or shall constitute a waiver of any other provision hereof, nor shall any such waiver constitute a continuing waiver unless otherwise expressly provided.

Section 8.7 No Third-Party Beneficiaries. This Agreement shall not be construed to create any obligation by either ICANN or Registry Operator to any non-party to this Agreement, including any registrar or registered name holder.

Section 8.8 Notices, Designations, and Specifications. All notices to be given under or in relation to this Agreement shall be given either (i) in writing at the address of the appropriate party as set forth below or (ii) via electronic mail as provided below, unless that party has given a notice of change of postal or email address, as provided in this Agreement. Any change in the contact information for notice below shall be given by the party within 30 days of such change. Any notice required by this Agreement shall be deemed to have been properly given (i) if in paper form, when delivered in person or via courier service with confirmation of receipt or (ii) by electronic mail, upon confirmation of receipt by the recipient's email server. Whenever this Agreement shall specify a URL address for certain information, Registry Operator shall be deemed to have been given notice of any such information when electronically posted at the designated URL. In the event other means of notice shall become practically achievable, such as notice via a secure website, the parties shall work together to implement such notice means under this Agreement.

If to ICANN, addressed to:

Internet Corporation for Assigned Names and Numbers
▇▇▇▇▇ ▇▇▇▇▇▇▇▇▇▇ ▇▇▇▇▇, ▇▇▇▇▇ ▇▇▇
▇▇▇ ▇▇▇▇▇▇▇, ▇▇ ▇▇▇▇▇-▇▇▇▇
Telephone: ▇-▇▇▇-▇▇▇-▇▇▇▇

Attention: President and CEO
With a Required Copy to: General Counsel
Email: (As specified from time to time.)

If to Registry Operator, addressed to:

VeriSign, Inc.
▇▇▇▇▇ ▇▇▇▇▇▇▇▇ ▇▇▇,
▇▇▇▇▇▇, ▇▇▇▇▇▇▇▇ ▇▇▇▇▇
Telephone: ▇-▇▇▇-▇▇▇-▇▇▇▇

Attention: SVP, Deputy General Counsel
With a Required Copy to: General Counsel
Email: (As specified from time to time.)

Section 8.9 Language; Calendar Days. Notices, designations, determinations, and specifications made under this Agreement shall be in the English language. Notwithstanding anything to the contrary, unless specified as “business days,” the word “days” used in this Agreement shall mean “calendar days.”

Section 8.10 Counterparts. This Agreement may be executed in one or more counterparts, each of which shall be deemed an original, but all of which together shall constitute one and the same instrument.

Section 8.11 Entire Agreement. Upon execution, this Agreement amends and restates the Prior Agreement in its entirety. This Agreement (including its Appendices, which form a part of it) constitutes the entire agreement of the parties hereto pertaining to the operation of the TLD and supersedes all prior agreements, understandings, negotiations and discussions, whether oral or written, between the parties on that subject. In the event of a conflict between the provisions in the body of this Agreement and any provision in its Appendices, the provisions in the body of the Agreement shall control.

[signature page follows]

IN WITNESS WHEREOF, the parties hereto have caused this Agreement to be executed by their duly authorized representatives.

INTERNET CORPORATION FOR ASSIGNED NAMES AND NUMBERS

By: /s/ ▇▇▇▇▇ ▇▇▇▇▇▇▇▇▇

▇▇▇▇▇ ▇▇▇▇▇▇▇▇▇
Interim President and Chief Executive Officer

Date: November 25, 2024

VeriSign, Inc.

By: /s/ D. ▇▇▇▇▇ ▇▇▇▇▇▇

D. ▇▇▇▇▇ ▇▇▇▇▇▇
Executive Chairman, President and Chief Executive Officer

Date: November 25, 2024

.com Registry Agreement Appendix 1

Data Escrow Specification

Registry Operator will engage an independent entity to act as data escrow agent (the “Escrow Agent”) for the provision of data escrow services related to the Agreement pursuant to an agreement substantially in the form of Appendix 2, as the same may be revised from time to time, among ICANN, Registry Operator and the Escrow Agent.

Changes to the schedule, content, format, and procedure set forth herein may be made only with the mutual written consent of ICANN and Registry Operator (which neither party shall unreasonably withhold) or through the establishment of a Consensus Policy as outlined in Section 3.1(b) of the Agreement.

TECHNICAL SPECIFICATIONS

1Deposits. There will be two types of Deposits: Full and Differential. For both types, the universe of Registry objects to be considered for data escrow are those objects necessary in order to offer all of the approved Registry Services.

1.1“Full Deposit” will consist of data in the registry through 00:00:00 UTC (Coordinated Universal Time) on the day that such Full Deposit is submitted to Escrow Agent.

1.2“Differential Deposit” means data that reflects all transactions that were not reflected in the last previous Full or Differential Deposit, as the case may be. Each Differential Deposit will contain all database transactions since the previous Deposit was completed including data through 00:00:00 UTC of each day, but Monday. Differential Deposits must include complete escrow records as specified below that were not included or changed since the most recent Full or Differential Deposit (i.e., all additions, modifications or removals of data since the last deposit).

2Schedule for Deposits. Registry Operator will submit a set of escrow files on a daily basis as follows:

2.1Each Monday, a Full Deposit must be submitted to the Escrow Agent by 23:59 UTC.

2.2The other six (6) days of the week, a Full Deposit or the corresponding Differential Deposit must be submitted to Escrow Agent by 23:59 UTC.

3Escrow Format Specification.

3.1 Deposit’s Format. Registry objects, such as domains, contacts, name servers, registrars, etc. will be compiled into a file constructed as described in RFC 8909, see Section 9, reference 1 of this Appendix and RFC 9022, see Section 9,

reference 2 of this Appendix (collectively, the “DNDE Specification”). The DNDE Specification describes some elements as optional; Registry Operator will include those elements in the Deposits if they are available. UTF-8 character encoding will be used.

3.2 Extensions. If Registry Operator offers additional Registry Services that require submission of additional data, not included above, additional “extension schemas” shall be defined in a case by case basis to represent that data. These “extension schemas” will be specified as described in Section 9, reference 2 of this Appendix. Data related to the “extensions schemas” will be included in the deposit file described in Section 3.1 of this Appendix. ICANN and Registry Operator shall work together to agree on such new objects’ data escrow specifications.

4.Processing of Deposit files. The use of compression is recommended in order to reduce electronic data transfer times, and storage capacity requirements. Data encryption will be used to ensure the privacy of registry escrow data. Files processed for compression and encryption will be in the binary OpenPGP format as per OpenPGP Message Format - RFC 4880, see Section 9, reference 3 of this Appendix. Acceptable algorithms for Public-key cryptography, Symmetric-key cryptography, Hash and Compression are those enumerated in RFC 4880, not marked as deprecated in OpenPGP IANA Registry, see Section 9, reference 4 of this Appendix, that are also royalty-free. The process to follow for the data file in original text format is:

1)The XML file of the deposit as described in Section 9, reference 1 of this Appendix must be named as the containing file as specified in Section 5 but with the extension xml.

2)The data file(s) are aggregated in a tarball file named the same as (1) but with extension tar.

3)A compressed and encrypted OpenPGP Message is created using the tarball file as sole input. The suggested algorithm for compression is ZIP as per RFC 4880. The compressed data will be encrypted using the escrow agent’s public key. The suggested algorithms for Public-key encryption are Elgamal and RSA as per RFC 4880. The suggested algorithms for Symmetric-key encryption are TripleDES, AES128 and CAST5 as per RFC 4880.

4)The file may be split as necessary if, once compressed and encrypted, it is larger than the file size limit agreed with the Escrow Agent. Every part of a split file, or the whole file if not split, will be called a processed file in this section.

5)A digital signature file will be generated for every processed file using the Registry Operator’s private key. The digital signature file will be in binary OpenPGP format as per RFC 4880 Section 9, reference 3, and will not be compressed or encrypted. The suggested algorithms for Digital signatures are

DSA and RSA as per RFC 4880. The suggested algorithm for Hashes in Digital signatures is SHA256.

6)The processed files and digital signature files will then be transferred to the Escrow Agent through secure electronic mechanisms, such as, SFTP, SCP, HTTPS file upload, etc. as agreed between the Escrow Agent and the Registry Operator. Non-electronic delivery through a physical medium such as CD- ROMs, DVD-ROMs, or USB storage devices may be used if authorized by ICANN.

7)The Escrow Agent will then validate every (processed) transferred data file using the procedure described in Section 8 of this Appendix.

5.File Naming Conventions. Files will be named according to the following convention: {gTLD}_{YYYY-MM-DD}_{type}_S{#}_R{rev}.{ext} where:

5.1 {gTLD} is replaced with the gTLD name; in case of an IDN-TLD, the ASCII- compatible form (A-Label) must be used;

5.2 {YYYY-MM-DD} is replaced by the date corresponding to the time used as a timeline watermark for the transactions; i.e. for the Full Deposit corresponding to 2009-08-02T00:00Z, the string to be used would be “2009-08-02”;

5.3 {type} is replaced by:

1)“full”, if the data represents a Full Deposit;

2)“diff”, if the data represents a Differential Deposit;

3)“thin”, if the data represents a Bulk Registration Data Access file, as specified in Section 5.1 of Appendix 5A;

4)"thick-{gurid}", if the data represents Registration Data from a specific registrar, as defined in Section 5.2 of Appendix 5A. The {gurid} element must be replaced with the IANA Registrar ID associated with the data.

5.4 {#} is replaced by the position of the file in a series of files, beginning with “1”; in case of a lone file, this must be replaced by “1”;

5.5 {rev} is replaced by the number of revision (or resend) of the file beginning with “0”: and

5.6 {ext} is replaced by “sig” if it is a digital signature file of the quasi-homonymous file. Otherwise it is replaced by “ryde”.

6.Distribution of Public Keys. Each of Registry Operator and Escrow Agent will distribute its public key to the other party (Registry Operator or Escrow Agent, as the case may be) via email to an email address to be specified. Each party will confirm receipt of the other party’s public key with a reply email, and the distributing party will subsequently reconfirm the authenticity of the key transmitted via offline methods, like in person meeting, telephone,

etc. In this way, public key transmission is authenticated to a user able to send and receive mail via a mail server operated by the distributing party. Escrow Agent, Registry Operator and ICANN will exchange public keys by the same procedure.

7.Notification of Deposits. Along with the delivery of each Deposit, Registry Operator will deliver to Escrow Agent and to ICANN (using the API described in draft-▇▇▇▇▇▇-icann- registry-interfaces, see Section 9, reference 5 of this Appendix (the “Interface Specification”)) a written statement from Registry Operator (which may be by authenticated e-mail) that includes a copy of the report generated upon creation of the Deposit and states that the Deposit has been inspected by Registry Operator and is complete and accurate. The preparation and submission of this statement must be performed by Registry Operator or its designee, provided that such designee may not be the Escrow Agent or any of Escrow Agent’s affiliates. Registry Operator will include the Deposit’s “id” and “resend” attributes in its statement. The attributes are explained in Section 9, reference 1 of this Appendix.

If not already an RFC, Registry Operator will use the most recent draft version of the Interface Specification as of December 1, 2024. Registry Operator may at its election use newer versions of the Interface Specification after December 1, 2024. Once the Interface Specification is published as an RFC, Registry Operator will implement that version of the Interface Specification, no later than one hundred eighty (180) calendar days after such publishing.

8.Verification Procedure.

1)The signature file of each processed file is validated.

2)If processed files are pieces of a bigger file, the latter is put together.

3)Each file obtained in the previous step is then decrypted and uncompressed.

4)Each data file contained in the previous step is then validated against the format defined in Section 9, reference 1 of this Appendix.

5)The data escrow agent extended verification process, as defined below in Section 9, reference 2 of this Appendix, as well as any other data escrow verification process contained in such reference.

If any discrepancy is found in any of the steps, the Deposit will be considered incomplete.

9.References.

1)Registry Data Escrow Specification, ▇▇▇▇▇://▇▇▇.▇▇▇-▇▇▇▇▇▇.▇▇▇/▇▇▇/▇▇▇▇▇▇▇.▇▇▇

2)Domain Name Registration Data (DNRD) Objects Mapping, ▇▇▇▇▇://▇▇▇.▇▇▇-▇▇▇▇▇▇.▇▇▇/▇▇▇/▇▇▇▇▇▇▇.▇▇▇

3)OpenPGP Message Format, ▇▇▇▇▇://▇▇▇.▇▇▇-▇▇▇▇▇▇.▇▇▇/▇▇▇/▇▇▇▇▇▇▇.▇▇▇

4)OpenPGP parameters, ▇▇▇▇▇://▇▇▇.▇▇▇▇.▇▇▇/▇▇▇▇▇▇▇▇▇▇▇/▇▇▇-▇▇▇▇▇▇▇▇▇▇/▇▇▇-▇▇▇▇▇▇▇▇▇▇.▇▇▇▇▇

5)ICANN interfaces for registries and data escrow agents, ▇▇▇▇▇://▇▇▇▇▇▇▇▇▇▇▇.▇▇▇▇.▇▇▇/▇▇▇/▇▇▇▇▇-▇▇▇▇▇▇-▇▇▇▇▇-▇▇▇▇▇▇▇▇-▇▇▇▇▇▇▇▇▇▇

.com Registry Agreement Appendix 2

Escrow Agreement (Template Format)

This Escrow Agreement ("Escrow Agreement") is made as of [ ] (“Effective Date”), by and between VeriSign, Inc. ("Registry Operator"), [ ]("Escrow Agent"), and the Internet Corporation for Assigned Names and Numbers ("ICANN").

Preliminary Statement. Registry Operator intends to deliver the "Deposits” to Escrow Agent as defined and provided for herein. Registry Operator desires Escrow Agent to hold the Deposits and, upon certain events described herein, deliver the Deposits (or a copy thereof) to ICANN in accordance with the terms hereof.

Now, therefore, in consideration of the foregoing, of the mutual promises hereinafter set forth, and for other good and valuable consideration, the receipt and sufficiency of which are hereby acknowledged, the parties agree as follows:

1. Delivery by Registry Operator. Registry Operator shall be solely responsible for delivering to Escrow Agent the Deposits, as defined and described in the "Data Escrow Specification," attached as Appendix 1A or Appendix 1, as applicable, to the .com Registry Agreement between Registry Operator and ICANN (the "Registry Agreement") and incorporated herein by this reference ("Appendix 1A" or “Appendix 1,” as applicable). Registry Operator may elect to deliver the Deposits to Escrow Agent in accordance with Appendix 1A or Appendix 1, as applicable, or in a manner mutually agreed upon by Escrow Agent and Registry Operator. Upon receipt of the Deposits, Escrow Agent shall immediately process the Deposits in accordance with Appendix 1A or Appendix 1, as applicable, and generate a file listing, which Escrow Agent shall, within ten (10) business days of the end of each calendar month, forward to Registry Operator, via email or United States mail. Within two (2) business days after receiving the Deposits, Escrow Agent shall verify that the Deposits are in the proper format and appear to be complete by performing the verification procedure specified in Appendix 1A or Appendix 1, as applicable. Unless Escrow Agent and ICANN agree on another method for the delivery of Escrow Agent’s written certification that it has performed the verification procedure described in Appendix 1A or Appendix 1, as applicable, and a copy of the verification reports generated by that procedure, Escrow Agent shall deliver, on the last business day of each month, a written certification to ICANN that it has performed the verification procedure described in Appendix 1A or Appendix 1, as applicable, on all Deposits received during the last month and shall deliver to ICANN a copy of the verification reports generated by that procedure. If Escrow Agent discovers that any Deposits fail the verification procedure, Escrow Agent shall notify ICANN and Registry Operator of such nonconformity within forty-eight (48) hours. Escrow Agent shall then hold the Deposits in accordance with the terms and conditions hereof.

2. Duplication. Escrow Agent may duplicate the Deposits by any means in order to comply with the terms and provisions of this Escrow Agreement. Alternatively, Escrow Agent, by notice to Registry Operator, may reasonably require Registry Operator to promptly duplicate the Deposits and forward the same to Escrow Agent.

3. Notification of Deposits; Distribution of Public Keys.

(a)Along with the delivery of each Deposit to the Escrow Agent, Registry Operator shall deliver to Escrow Agent and to ICANN a written statement from Registry Operator pursuant to the terms and conditions of Section 7 (Notification of Deposits) of Appendix 1A or Appendix 1, as applicable. Escrow Agent shall, within two (2) business days of receipt of any Deposit, send notification to Registry Operator either by email or telephone, or as may be otherwise requested by Registry Operator, and to ICANN electronically using the API described in the “internet draft” of the ICANN Registry Interfaces specification located at ▇▇▇▇▇://▇▇▇▇▇▇▇▇▇▇▇.▇▇▇▇.▇▇▇/▇▇▇/▇▇▇▇▇-▇▇▇▇▇▇-▇▇▇▇▇-▇▇▇▇▇▇▇▇-▇▇▇▇▇▇▇▇▇▇ as of the Effective Date of this Escrow Agreement, that it has received from Registry Operator such Deposit. In addition, Escrow Agent shall also include a copy of the verification report as confirmation that it has run the verification process.

(b)Each of Registry Operator and Escrow Agent will distribute its public key to the other party (Registry Operator or Escrow Agent, as the case may be) via email to an email address to be specified. Each party will confirm receipt of the other party’s public key with a reply email, and the distributing party will subsequently reconfirm the authenticity of the key transmitted via offline methods, like in person meeting, telephone, etc. In this way, public key transmission is authenticated to a user able to send and receive mail via a mail server operated by the distributing party. Escrow Agent, Registry Operator and ICANN will exchange public keys by the same procedure.

4. Delivery by Escrow Agent

4.1 Delivery by Escrow Agent to ICANN. Escrow Agent shall deliver the Deposits, or a complete copy thereof, to ICANN only in the event that:

(a)Registry Operator notifies Escrow Agent to effect such delivery to ICANN at a specific address, the notification being accompanied by a payment remittance advice to evidence a payment to Escrow Agent in the amount of one hundred dollars ($100.00); or

(b)Escrow Agent receives from ICANN:

(i)Written notification that the Registry Agreement has been finally, validly and legally terminated under Section 6 of the Registry Agreement and no injunction or similar order has been obtained from an arbitrator or court prohibiting ICANN from securing the data in this escrow ("Registry Termination");

(ii)a written statement that ICANN has previously notified Registry Operator of such Registry Termination in writing;

(iii)a written demand that the Deposits be released and delivered to ICANN;

(iv)a written undertaking from ICANN that the Deposits being supplied to ICANN will be used only as permitted under the terms of the Registry Agreement;

(v)specific instructions from ICANN for this delivery; and

(vi)a payment remittance advice to evidence a payment from Registry Operator, or evidence of payment via email from ICANN (who will then be reimbursed by Registry Operator), to Escrow Agent in the amount of one hundred dollars ($100.00); or

(c)a release occurs according to Section 8(c) below.

4.2 Delivery at Registry Operator's Request. If the provisions of Section 4.1(a) above are satisfied, Escrow Agent shall, within twenty-four (24) hours after receipt of the notification and check specified in Section 4.1(a), deliver the Deposits in accordance with the applicable instructions.

4.3 Delivery at ICANN's Request. If the provisions of Section 4.1(b) or 4.1(c) above are satisfied, Escrow Agent shall, within twenty-four (24) hours after receipt of all the documents specified in those sections, deliver the following: (i) to Registry Operator, a copy of all such documents; (ii) to ICANN, as specifically instructed by ICANN, electronic copies of the Deposits; provided, however, that if the delivery is commenced by reason of Section 4.1(c) above, Registry Operator may make the payment owing to Escrow Agent during the twenty-four (24) hour period referenced above, and Escrow Agent shall not thereafter deliver to ICANN the materials specified in subpart (ii) of this section, above. Following receipt of the notice to Registry Operator under subpart (i) of this section, Registry Operator shall have thirty (30) days from the date on which Registry Operator receives such documents ("Objection Period") to notify Escrow Agent of its objection ("Objection Notice") to the release of the Deposits to ICANN and request that the issue of entitlement to a copy of the Deposits be submitted to arbitration in accordance with the following provisions:

(a)The sending of an Objection Notice shall not delay delivery of the Deposits to ICANN.

(b)If Registry Operator shall send an Objection Notice to Escrow Agent during the Objection Period, the matter shall be submitted to and settled by arbitration by a panel of three (3) arbitrators chosen by the American Arbitration Association in accordance with the rules of the American Arbitration Association. The arbitrators shall apply the law of California exclusive of its conflicts of laws rules. At least one (1) arbitrator shall be reasonably familiar with the Internet industry. The decision of the arbitrators shall be binding and conclusive on all parties involved, and judgment upon their decision may be entered in a court of competent jurisdiction. All costs of the arbitration incurred by Escrow Agent, including reasonable attorneys' fees and costs, shall be paid by the party which does not prevail in the arbitration; provided, however, if the arbitration is settled prior to a decision by the arbitrators, the parties involved in the arbitration shall each pay an equal percentage of all such costs.

(c)Notwithstanding Section 4.3(b) above, the parties agree that any arbitration brought pursuant to this Section 4.3 shall not re-evaluate, reconsider, or otherwise subject to review any issues, causes

of action, or other claims which were decided, in an arbitration or court decision involving the parties hereto concerning the Registry Agreement and/or the Cooperative Agreement, and that any decision regarding such issues or claims in an arbitration brought pursuant to Section 4.3 would be invalid, unenforceable, and not binding. The propriety, validity, legality, or effectiveness of any terminations or actions under the Registry Agreement and/or Cooperative Agreement shall be determined solely through procedures and remedies provided for by those respective agreements, not through any arbitration brought pursuant to Section 4.3. Any arbitration proceeding brought pursuant to Section 4.3 shall be limited to a determination of whether Sections 4.1(b) and (c) have been satisfied.

(d)Registry Operator may, at any time prior to the commencement of arbitration proceedings, notify Escrow Agent that Registry Operator has withdrawn the Objection Notice. Upon receipt of any such notice from Registry Operator, Escrow Agent shall promptly deliver the Deposits to ICANN in accordance with the instructions provided by ICANN.

(e)If the release of materials to ICANN pursuant to Section 4.3 is judged to be proper in any arbitration brought in accordance with Section 4.3, Escrow Agent shall promptly deliver to ICANN, in accordance with the instructions specified in Section 4.1(b)(v) above, any Deposits that have not previously been delivered. All parties agree that Escrow Agent shall not be required to deliver such Deposits until all such fees then due to Escrow Agent have been paid.

(f)If the release of the Deposits to ICANN pursuant to Section 4.3 is judged to have been improper in any arbitration brought in accordance with Section 4.3, ICANN shall promptly return or destroy, at Registry Operator's discretion, those Deposits that were received by ICANN pursuant to Section 4.3.

4.4 Delivery by Escrow Agent to Registry Operator. Escrow Agent shall release and deliver the Deposits to Registry Operator upon termination of this Escrow Agreement in accordance with Section 7(a) or 7(b) hereof.

5. Indemnity.

General Indemnity. Subject to the limitation imposed under Section 11(a) below, Registry Operator and ICANN shall jointly and severally indemnify and hold harmless Escrow Agent and each of its directors, officers, agents and employees ("Escrow Agent Indemnitees") absolutely and forever, from and against any and all claims, actions, damages, suits, liabilities, obligations, costs, fees, charges, and any other expenses whatsoever, including reasonable attorneys' fees and costs, that may be asserted by a third party against any Escrow Agent Indemnitee in connection with this Escrow Agreement or the performance of Escrow Agent or any Escrow Agent Indemnitee hereunder, except for any claims, actions, damages, suits, liabilities, obligations, costs, fees, charges, or any other expenses arising in connection with the misrepresentation, negligence, or misconduct of Escrow Agent, its directors, officers, agents, employees or contractors. Subject to the limitation imposed under Section 11(a), Escrow Agent shall likewise indemnify and hold harmless Registry Operator and ICANN, and each of their respective directors, officers, agents, and employees ("Indemnitees") absolutely and forever, from and against any and all claims, actions, damages, suits, liabilities, obligations, costs, fees, charges, and any other expenses whatsoever,

including reasonable attorneys' fees and costs, that may be asserted by a third party against any Indemnitee in connection with the misrepresentation, negligence, or misconduct of Escrow Agent, its directors, officers, agents, employees and contractors.

6. Disputes and Interpleader.

(a) Escrow Agent may submit any dispute under this Escrow Agreement to any court of competent jurisdiction in an interpleader or similar action other than a matter submitted to arbitration after Escrow Agent's receipt of an Objection Notice under Section 4 above and the parties under this Escrow Agreement submit the matter to such arbitration as described in Section 4 of this Escrow Agreement. Any and all costs incurred by Escrow Agent in connection therewith, including reasonable attorneys' fees and costs, shall be borne 50% by each of Registry Operator and ICANN.

(b) Escrow Agent shall perform any acts ordered by any court of competent jurisdiction, without any liability or obligation to any party hereunder by reason of such act.

7. Term and Renewal.

(a)The initial term of this Escrow Agreement shall commence on the Effective Date hereof and continue for five (5) years thereafter (the "Initial Term"). This Escrow Agreement shall be automatically extended for additional terms of one year (each an "Additional Term") at the end of the Initial Term and at the end of each Additional Term hereunder. The Initial Term and each Additional Term shall be referred to collectively as the “term.” Escrow Agent acting alone or Registry Operator, with the concurrence of ICANN, may terminate this Escrow Agreement at any time upon giving the other parties ninety (90) days notice.

(b)In the event Registry Operator gives notice of its intent to terminate pursuant to Section 7(a) above, and ICANN fails to concur according to Section 7(a), ICANN shall be responsible for payment of all subsequent fees and shall have the right to seek reimbursement of such fees from Registry Operator and to terminate this Escrow Agreement at any time upon giving the other parties ninety (90) days notice.

(c)In the event of termination of this Escrow Agreement in accordance with Section 7(a) or 7(b) hereof, Registry Operator shall pay all fees due Escrow Agent and shall promptly notify ICANN that this Escrow Agreement has been terminated and that Escrow Agent shall return to Registry Operator all copies of the Deposits then in its possession.

8. Fees and Invoice.

(a) Fees. Registry Operator shall pay Escrow Agent the Annual Fee set forth in Exhibit A (incorporated by this reference) in advance in accordance with Section 8 (Fees and Invoice) in exchange for Escrow Agent's services under this Escrow Agreement.

(b) Invoice Payment. Registry Operator shall pay valid and properly submitted invoices within thirty (30) days of the date of such invoice; provided, however, that Registry Operator shall not be obligated to pay any amounts disputed in good faith. Registry Operator shall notify Escrow Agent in writing in the event Registry Operator in good faith disputes the invoice or any portion thereof setting forth the reasons of such dispute, and the parties agree to negotiate in good faith a resolution to such disputed invoice; provided, however, that if the parties cannot reasonably agree on the disputed charges, the parties shall escalate such dispute to the appropriate director/vice president level to resolve such dispute. Payments to Escrow Agent shall be sent to the remittance address set forth on Escrow Agent’s invoice.

(c) Nonpayment. In the event of non-payment of any fees or charges invoiced by Escrow Agent, Escrow Agent shall give notice of non-payment of any fee due and payable hereunder to Registry Operator and, in such an event, Registry Operator shall have the right to pay the unpaid fee within ten (10) business days after receipt of notice from Escrow Agent. If Registry Operator fails to pay in full all fees due during such ten (10) day period, Escrow Agent shall give notice of non-payment of any fee due and payable hereunder to ICANN and, in such event, ICANN shall have the right to pay the unpaid fee within ten (10) business days of receipt of such notice from Escrow Agent. Upon payment of the unpaid fee by either Registry Operator or ICANN, as the case may be, this Escrow Agreement shall continue in full force and effect until the end of the applicable term. Upon a failure to pay the unpaid fee under this Section 8(c) by either Registry Operator or ICANN, or by Registry Operator under Section 4.3, the Escrow Agent shall proceed as set forth in Section 4.3 as though ICANN had requested delivery of the Deposits.

(d) Invoice Submission Address. Escrow Agent shall invoice Registry Operator the Annual Fee on the Effective Date of this Escrow Agreement and on the anniversary of the Effective Date for each year thereafter during the term of this Escrow Agreement. In the event this Escrow Agreement is terminated prior to the end of the then current term, Escrow Agent shall refund to Registry Operator, or to ICANN for fees paid by ICANN to Escrow Agent under Section 8(c), a prorated portion of the Annual Fee based on the date of termination. For any additional work that may be agreed upon by the parties in a signed writing, ▇▇▇▇▇▇ Agent shall submit detailed and timely invoices not more frequently than once a month and not later than ninety (90) days after the work performed for such additional services has been completed. All invoices issued hereunder shall reference the Purchase Order number assigned to the work performed under this Escrow Agreement. Escrow Agent shall not submit any invoices to Registry Operator that do not reference the applicable Purchase Order number provided that Registry Operator shall be responsible for timely providing Escrow Agent such applicable Purchase Order number. Escrow Agent shall submit original invoices solely to Registry Operator’s Accounts Payable department at the mailing or electronic mailing address as set forth below:

Invoice Submission Address:

VeriSign, Inc.

▇▇▇▇▇ ▇▇▇▇▇▇▇▇ ▇▇▇

Reston, Virginia 20190

Attn: Accounts Payable

Or Invoices may be submitted electronically to: ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇@▇▇▇▇▇▇▇▇.▇▇▇

9. Ownership of Deposits. The parties recognize and acknowledge that ownership of the Deposits during the effective term of this Escrow Agreement shall remain with Registry Operator at all times.

10. Retention and Confidentiality.

(a)Retention. Escrow Agent shall hold and maintain the Deposits for a period of no less than three hundred and sixty-five (365) days in a secure, locked, and environmentally safe facility which is accessible only to authorized representatives of Escrow Agent. Escrow Agent shall use commercially reasonable efforts to protect the integrity of the Deposits. Each of ICANN and Registry Operator shall have the right to inspect Escrow Agent's written records with respect to this Escrow Agreement upon reasonable prior notice and during normal business hours.

(b)Confidentiality. Escrow Agent shall at all times protect the confidentiality of the Deposits. Except as provided in this Escrow Agreement, Escrow Agent shall not disclose, transfer, make available, or use any Deposits (or any copies of any Deposits). Should Escrow Agent be put on notice that it is required to disclose any Deposits by statute, rule, regulation, order, or other requirement of a governmental agency, legislative body, court of competent jurisdiction, or binding arbitral body (other than any requirement pursuant to Sections 4 or 8(c) of this Escrow Agreement), Escrow Agent shall notify ICANN and Registry Operator within seven (7) days or as soon as practicable and reasonably cooperate with Registry Operator and/or ICANN in any contest of the disclosure. Should any contest prove unsuccessful, Escrow Agent shall not be held liable for any disclosure pursuant to such governmental, legislative, judicial, or arbitral order, statute, rule, regulation, or other requirement.

11. Miscellaneous.

(a)Remedies; Limitation of Liability.

(i)Except for liability arising from (i) death or bodily injury; or (ii) gross negligence, or willful misconduct, in any dispute between Registry Operator and/or ICANN on the one hand and Escrow Agent on the other hand, all liability of Escrow Agent, Registry Operator and/or ICANN related to this Escrow Agreement, if any, whether arising in contract, tort (including negligence) or otherwise, shall be limited to an amount equal to the then annual fees paid to Escrow Agent under this Escrow Agreement.

(ii)As between Registry Operator and ICANN the liability limitations of the Registry Agreement also apply.

(iii)In no event shall any party to this Escrow Agreement be liable to another party for any incidental, special, punitive or consequential damages, lost profits, any costs or expenses for the procurement of substitute services (excluding substitute escrow services), or any other indirect damages, whether arising in contract, tort (including negligence) or otherwise even if the possibility thereof may be known in advance to one or more parties.

(iv)Each party expressly reserves all rights in law or equity to enforce the provisions of this Escrow Agreement, subject only to the limitations set forth in this Section 11(a).

(b)Permitted Reliance and Abstention. Escrow Agent may rely and shall be fully protected in acting or refraining from acting upon any notice or other document believed by ▇▇▇▇▇▇ Agent in good faith to be genuine and to have been signed or presented by the proper person or entity. Escrow Agent shall have no duties or responsibilities except those expressly set forth herein.

(c)Independent Contractor. Escrow Agent is an independent contractor and is not an employee or agent of either Registry Operator or ICANN.

(d)Amendments. This Escrow Agreement shall not be modified or amended except by another agreement in writing executed by each of the parties hereto.

(e)Assignment. Neither Registry Operator nor ICANN may assign or transfer this Escrow Agreement (by merger, sale of assets, operation of law, or otherwise), except that the rights and obligations of Registry Operator or ICANN automatically shall be transferred to the assignee of one of those parties' rights and obligations under the Registry Agreement. However, Escrow Agent shall have no obligation in performing this Escrow Agreement to recognize any successor or assign of Registry Operator or ICANN unless Escrow Agent receives clear, authoritative and conclusive written evidence of the change of parties. Escrow Agent may not assign or transfer this Escrow Agreement without the prior written consent of both Registry Operator and ICANN, which consent shall not be unreasonably delayed or withheld.

(f)Entire Agreement. This Escrow Agreement, including all exhibits hereto (if any), supersedes all prior discussions, understandings and agreements between Escrow Agent and the other parties with respect to the matters contained herein, and constitutes the entire agreement between Escrow Agent and the other parties with respect to the matters contemplated herein. Appendix 1A or Appendix 1, as applicable, of the Registry Agreement is by this reference made a part of this Escrow Agreement and incorporated herein.

(g)Counterparts; Governing Law. This Escrow Agreement may be executed in counterparts, each of which when so executed shall be deemed to be an original and all of which when taken together shall constitute one and the same agreement. This Escrow Agreement shall be governed by and interpreted in accordance with the laws of California, without regard to its conflicts of law principles. Except as specifically provided for herein, all of the parties additionally consent to the personal jurisdiction of California, acknowledge that venue is proper in any state and Federal court in California, agree to any action related to this Escrow Agreement properly brought in one of these courts, and waive any objection it has or may have in the future with respect to any of the foregoing.

(h)Notices. All notices, requests, demands or other communications required or permitted to be given or made under this Escrow Agreement shall be in writing and shall be delivered by hand or by commercial overnight delivery service which provides for evidence of receipt, or mailed by certified

mail, return receipt requested, postage prepaid. If delivered personally or by commercial overnight delivery service, the date on which the notice, request, instruction or document is delivered shall be the date on which delivery is deemed to be made, and if delivered by mail, the date on which such notice, request, instruction or document is received shall be the date on which delivery is deemed to be made. Any party may change its address for the purpose of this Escrow Agreement by notice in writing to the other parties as provided herein.

(i)Survival. Sections 5, 6, 8, 9, 10 and 11 shall survive any termination of this Escrow Agreement.

(j)No Waiver. No failure on the part of any party hereto to exercise, and no delay in exercising any right, power or single or partial exercise of any right, power or remedy by any party will preclude any other or further exercise thereof or the exercise of any other right, power or remedy. No express waiver or assent by any party hereto to any breach of or default in any term or condition of this Escrow Agreement shall constitute a waiver of or an assent to any succeeding breach of or default in the same or any other term or condition hereof.

IN WITNESS WHEREOF each of the parties has caused its duly authorized officer to execute this Escrow Agreement as of the Effective Date.

[ ]

By:

Title:

Print Name:

Date:

Address:

Phone:

E-mail:

VeriSign, Inc.

By:

Title:

Print Name:

Date:

Address:

Phone:

E-mail:

Internet Corporation for Assigned Names and Numbers

By:

Title:

Print Name:

Date:

Address:

Phone:

E-mail:

Exhibit A to Appendix 2

1. Annual Fee. The Annual Fee shall be [ ] United States Dollars.

2. Testing Period. Notwithstanding anything to the contrary in this Escrow Agreement, upon the Effective Date of the Escrow Agreement until reasonably determined by Registry Operator as indicated by notice, which may be via email, from Registry Operator to ICANN and Escrow Agent, Escrow Agent shall perform the services set forth in this Escrow Agreement in parallel with the legacy escrow agent for the purposes of demonstrating that the Escrow Agent is performance ready (the “Testing Period”). ICANN understands and agrees that during the Testing Period, the legacy escrow agent shall continue to be the sole authoritative source of escrow services.

.com Registry Agreement Appendix 3

Zone File Access

1.Third-Party Zone File Access

1.1Zone File Access Agreement. Registry Operator will enter into an agreement with any Internet user, which will allow such user to access an Internet host server or servers designated by Registry Operator and download zone file data. The agreement will be standardized, facilitated and administered by a Centralized Zone Data Access Provider, which may be ICANN or an ICANN designee (the “CZDA Provider”). Registry Operator (optionally through the CZDA Provider) will provide access to zone file data per Section 1.3 of this Appendix and do so using the file format described in Section 1.4 of this Appendix. Notwithstanding the foregoing,

(a) the CZDA Provider may reject the request for access of any user that does not satisfy the credentialing requirements in Section 1.2 of this Appendix; (b) Registry Operator may reject the request for access of any user that does not provide correct or legitimate credentials under Section 1.2 of this Appendix or where Registry Operator reasonably believes will violate the terms of Section 1.5 of this Appendix; and, (c) Registry Operator may revoke access of any user if Registry Operator has evidence to support that the user has violated the terms of Section 1.5 of this Appendix.

1.2Credentialing Requirements. Registry Operator, through the facilitation of the CZDA Provider, will request each user to provide it with information sufficient to correctly identify and locate the user. Such user information will include, without limitation, company name, contact name, address, telephone number, facsimile number, email address and IP address.

1.3Grant of Access. Each Registry Operator (optionally through the CZDA Provider) will provide the Zone File SFTP (or other Registry supported) service for an ICANN-specified and managed URL (specifically, <TLD>.▇▇▇.▇▇▇▇▇.▇▇▇ where <TLD> is the TLD for which the registry is responsible) for the user to access the Registry’s zone data archives. Registry Operator will grant the user a non‐exclusive, nontransferable, limited right to access Registry Operator’s (optionally CZDA Provider's) Zone File hosting server, and to transfer a copy of the top-level domain zone files, and any associated cryptographic checksum files no more than once per 24 hour period using SFTP, or other data transport and access protocols that may be prescribed by ICANN. For every zone file access server, the zone files are in the top-level directory called

<zone>.zone.gz, with <zone>.zone.gz.md5 and <zone>.zone.gz.sig to verify downloads. If the Registry Operator (or the CZDA Provider) also provides historical data, it will use the naming pattern <zone>-yyyymmdd.zone.gz, etc.

1.4File Format Standard. Registry Operator (optionally through the CZDA Provider) will provide zone files using a subformat of the standard Master File format as originally defined in

RFC 1035, Section 5, including all the records present in the actual zone used in the public DNS. Sub-format is as follows:

1.Each record must include all fields in one line as: <domain‐name> <TTL> <class> <type>

<RDATA>.

2.Class and Type must use the standard mnemonics and must be in lower case.

3.TTL must be present as a decimal integer.

4.Use of \X and \DDD inside domain names is allowed.

5.All domain names must be in lower case.

6.Must use exactly one tab as separator of fields inside a record.

7.All domain names must be fully qualified.

8.No $ORIGIN directives.

9.No use of “@” to denote current origin.

10.No use of “blank domain names” at the beginning of a record to continue the use of the domain name in the previous record.

11.No $INCLUDE directives.

12.No $TTL directives.

13.No use of parentheses, e.g., to continue the list of fields in a record across a line boundary.

14.No use of comments.

15.No blank lines.

16.The SOA record should be present at the top and (duplicated at) the end of the zone file.

17.With the exception of the SOA record, all the records in a file must be in alphabetical order.

18.One zone per file. If a TLD divides its DNS data into multiple zones, each zone goes into a separate file named as above, with all the files combined using tar into a file called

<tld>.zone.tar.

1.5Use of Data by User. Registry Operator will permit user to use the zone file for lawful purposes; provided that (a) user takes all reasonable steps to protect against unauthorized access to, use of, and disclosure of the data, and (b) under no circumstances will Registry

Operator be required or permitted to allow user to use the data to (i) allow, enable or otherwise support any marketing activities to entities other than the user’s existing customers, regardless of the medium used (such media include but are not limited to transmission by e-mail, telephone, facsimile, postal mail, SMS, and wireless alerts of mass unsolicited, commercial advertising or solicitations to entities), (ii) enable high volume, automated, electronic processes that send queries or data to the systems of Registry Operator or any ICANN-accredited registrar, or (iii) interrupt, disrupt or interfere in the normal business operations of any registrant.

1.6Term of Use. Registry Operator, through CZDA Provider, will provide each user with access to the zone file for a period of not less than three (3) months. Registry Operator will allow users to renew their Grant of Access.

1.7No Fee for Access. Registry Operator will provide, and CZDA Provider will facilitate, access to the zone file to user at no cost.

2.Co‐operation

2.1 Assistance. Registry Operator will co-operate and provide reasonable assistance to ICANN and the CZDA Provider to facilitate and maintain the efficient access of zone file data by permitted users as contemplated under this Appendix.

2.2 ICANN Access. Registry Operator shall provide bulk access to the zone files for the TLD to ICANN or its designee on a continuous basis in the manner ICANN may reasonably specify from time to time. Access will be provided at least daily. Zone files will include SRS data committed as close as possible to 00:00:00 UTC.

.com Registry Agreement Appendix 4

Format and Content for Registry Operator

Monthly Reporting

Registry Operator shall provide the following monthly reports, each as described in greater detail below, for the TLD: (1) the Service Level Agreement Performance Report; (2) the Per-Registrar Transactions Report; and (3) the Registry Functions Activity Report. The Service Level Agreement Performance Reports shall be submitted to ICANN via email to <registry- ▇▇▇▇▇▇▇@▇▇▇▇▇.▇▇▇>. The Per-Registrar Transactions Reports and the Registry Functions Activity Reports shall be submitted to ICANN using the API described in draft-▇▇▇▇▇▇-icann- registry-interfaces, see ▇▇▇▇▇://▇▇▇▇▇▇▇▇▇▇▇.▇▇▇▇.▇▇▇/▇▇▇/▇▇▇▇▇-▇▇▇▇▇▇-▇▇▇▇▇-▇▇▇▇▇▇▇▇-▇▇▇▇▇▇▇▇▇▇ (the “Registry Interfaces Specification”). If not already an RFC, Registry Operator will use the most recent draft version of the Registry Interfaces Specification available as of December 1, 2024. Registry Operator may at its election use newer versions of the Registry Interfaces Specification after December 1, 2024. Once the Registry Interfaces Specification is published as an RFC, Registry Operator will implement the RFC version no later than one hundred eighty (180) calendar days after it is published.

ICANN may request in the future that the reports be delivered by other means and using other formats. For each of the reports, ICANN will use reasonable commercial efforts to preserve the confidentiality of the information reported until three (3) months after the end of the month to which the reports relate. Unless set forth in this Appendix 4, any reference to a specific time refers to Coordinated Universal Time (UTC). Monthly reports shall consist of data that reflects the state of the registry at the end of the month (UTC).

1.Service Level Agreement Performance Report. This report shall compare the Service Level Agreement requirements with actual performance measures for the reporting month: (a) in accordance with Section 7.2 of Appendix 7; and (b) in accordance with Section 3.2 of Appendix 5B.

2.Per-Registrar Transactions Report. This report shall be compiled in a comma separated- value formatted file as specified in RFC 4180. The file shall be named “com-transactions-yyyymm.csv.” The file shall contain the following fields per registrar:


Field #	Field name	Description
01	registrar-name	Registrar’s full corporate name as registered with IANA
02	iana-id	For cases where the registry operator acts as registrar (i.e., without the use of an ICANN accredited registrar) either 9998 or 9999 should be used depending on registration type, otherwise the sponsoring Registrar IANA id should be used as specified in ▇▇▇▇▇://▇▇▇.▇▇▇▇.▇▇▇/▇▇▇▇▇▇▇▇▇▇▇/▇▇▇▇▇▇▇▇▇-▇▇▇


03	total-domains	total domain names under sponsorship in any EPP status but pendingCreate that have not been purged
04	total-nameservers	total name servers (either host objects or name server hosts as domain name attributes) associated with domain names registered for the TLD in any EPP status but pendingCreate that have not been purged
05	net-adds-1-yr	number of domains successfully registered (i.e., not in EPP pendingCreate status) with an initial term of one (1) year (and not deleted within the add grace period). A transaction must be reported in the month the add grace period ends.
06	net-adds-2-yr	number of domains successfully registered (i.e., not in EPP pendingCreate status) with an initial term of two(2) years (and not deleted within the add grace period). A transaction must be reported in the month the add grace period ends.
07	net-adds-3-yr	number of domains successfully registered (i.e., not in EPP pendingCreate status) with an initial term of three (3) years (and not deleted within the add grace period). A transaction must be reported in the month the add grace period ends.
08	net-adds-4-yr	number of domains successfully registered (i.e., not in EPP pendingCreate status) with an initial term of four (4) years (and not deleted within the add grace period). A transaction must be reported in the month the add grace period ends.


09	net-adds-5-yr	number of domains successfully registered (i.e., not in EPP pendingCreate status) with an initial term of five (5) years (and not deleted within the add grace period). A transaction must be reported in the month the add grace period ends.
10	net-adds-6-yr	number of domains successfully registered (i.e., not in EPP pendingCreate status) with an initial term of six (6) years (and not deleted within the add grace period). A transaction must be reported in the month the add grace period ends.


11	net-adds-7-yr	number of domains successfully registered (i.e., not in EPP pendingCreate status) with an initial term of seven (7) years (and not deleted within the add grace period). A transaction must be reported in the month the add grace period ends.
12	net-adds-8-yr	number of domains successfully registered (i.e., not in EPP pendingCreate status) with an initial term of eight (8) years (and not deleted within the add grace period). A transaction must be reported in the month the add grace period ends.
13	net-adds-9-yr	number of domains successfully registered (i.e., not in EPP pendingCreate status) with an initial term of nine (9) years (and not deleted within the add grace period). A transaction must be reported in the month the add grace period ends.
14	net-adds-10-yr	number of domains successfully registered (i.e., not in EPP pendingCreate status) with an initial term of ten (10) years (and not deleted within the add grace period). A transaction must be reported in the month the add grace period ends.
15	net-renews-1-yr	number of domains successfully renewed (i.e., not in EPP pendingRenew status) either automatically or by command with a new renewal period of one (1) year (and not deleted within the renew or auto-renew grace period). A transaction must be reported in the month the renew or auto-renew grace period ends.


16	net-renews-2-yr	number of domains successfully renewed (i.e., not in EPP pendingRenew status) either automatically or by command with a new renewal period of two (2) years (and not deleted within the renew or auto-renew grace period). A transaction must be reported in the month the renew or auto-renew grace period ends.
17	net-renews-3-yr	number of domains successfully renewed (i.e., not in EPP pendingRenew status) either automatically or by command with a new renewal period of three (3) years (and not deleted within the renew or auto- renew grace period). A transaction must be reported in the month the renew or auto-renew grace period ends.


18	net-renews-4-yr	number of domains successfully renewed (i.e., not in EPP pendingRenew status) either automatically or by command with a new renewal period of four (4) years (and not deleted within the renew or auto-renew grace period). A transaction must be reported in the month the renew or auto-renew grace period ends.
19	net-renews-5-yr	number of domains successfully renewed (i.e., not in EPP pendingRenew status) either automatically or by command with a new renewal period of five (5) years (and not deleted within the renew or auto-renew grace period). A transaction must be reported in the month the renew or auto-renew grace period ends.
20	net-renews-6-yr	number of domains successfully renewed (i.e., not in EPP pendingRenew status) either automatically or by command with a new renewal period of six (6) years (and not deleted within the renew or auto-renew grace period). A transaction must be reported in the month the renew or auto-renew grace period ends.
21	net-renews-7-yr	number of domains successfully renewed (i.e., not in EPP pendingRenew status) either automatically or by command with a new renewal period of seven (7) years (and not deleted within the renew or auto- renew grace period). A transaction must be reported in the month the renew or auto-renew grace period ends.


22	net-renews-8-yr	number of domains successfully renewed (i.e., not in EPP pendingRenew status) either automatically or by command with a new renewal period of eight (8) years (and not deleted within the renew or auto- renew grace period). A transaction must be reported in the month the renew or auto-renew grace period ends.
23	net-renews-9-yr	number of domains successfully renewed (i.e., not in EPP pendingRenew status) either automatically or by command with a new renewal period of nine (9) years (and not deleted within the renew or auto- renew grace period). A transaction must be reported in the month the renew or auto-renew grace period ends.


24	net-renews-10-yr	number of domains successfully renewed (i.e., not in EPP pendingRenew status) either automatically or by command with a new renewal period of ten (10) years (and not deleted within the renew or auto- renew grace period). A transaction must be reported in the month the renew or auto-renew grace period ends.
25	transfer-gaining-successful	number of domain transfers initiated by this registrar that were successfully completed (either explicitly or automatically approved) and not deleted within the transfer grace period. A transaction must be reported in the month the transfer grace period ends.
26	transfer-gaining-nacked	number of domain transfers initiated by this registrar that were rejected (e.g., EPP transfer op="reject") by the other registrar
27	transfer-losing-successful	number of domain transfers initiated by another registrar that were successfully completed (either explicitly or automatically approved)
28	transfer-losing-nacked	number of domain transfers initiated by another registrar that this registrar rejected (e.g., EPP transfer op="reject")
29	transfer-disputed-won	number of transfer disputes in which this registrar prevailed (reported in the month where the determination happened)


30	transfer-disputed-lost	number of transfer disputes this registrar lost (reported in the month where the determination happened)
31	transfer-disputed-nodecision	number of transfer disputes involving this registrar with a split or no decision (reported in the month where the determination happened)
32	deleted-domains-grace	domains deleted within the add grace period (does not include names deleted while in EPP pendingCreate status). A deletion must be reported in the month the name is purged.


33	deleted-domains-nograce	domains deleted outside the add grace period (does not include names deleted while in EPP pendingCreate status). A deletion must be reported in the month the name is purged.
34	restored-domains	domain names restored during reporting period
35	restored-noreport	total number of restored names for which a restore report is required by the registry, but the registrar failed to submit it
36	agp-exemption-requests	total number of AGP (add grace period) exemption requests
37	agp-exemptions-granted	total number of AGP (add grace period) exemption requests granted
38	agp-exempted-domains	total number of names affected by granted AGP (add grace period) exemption requests
39	attempted-adds	number of attempted (both successful and failed) domain name create commands
40	consolidate-transaction-days	total number of days added to the expiration date of all domain names via consolidate/sync transactions. The number of days of a consolidate/sync transaction must be reported here in the month the transaction took place.
41	consolidate-transactions	total number of consolidate/sync transactions. A transaction must be reported in the month the transaction took place.

The first line shall include the field names exactly as described in the table above as a “header line” as described in section 2 of RFC 4180. The last line of each report shall include totals for each column across all registrars; the first field of this line shall read “Totals” while the second field shall be left empty in that line. No other lines besides the ones described above shall be included. Line breaks shall be <U+000D, U+000A> as described in RFC 4180.

3.Registry Functions Activity Report. This report shall be compiled in a comma separated- value formatted file as specified in RFC 4180. The file shall be named “com-activity-yyyymm.csv.” The file shall contain the following fields:


Field #	Field Name	Description
01	operational-registrars	number of operational registrars in the production system at the end of the reporting period
02	zfa-passwords	number of active zone file access passwords at the end of the reporting period; "CZDS" may be used instead of the number of active zone file access passwords, if the Centralized Zone Data Service (CZDS) is used to provide the zone file to the end user
03	whois-43-queries	number of WHOIS (port-43) queries responded during the reporting period
04	web-whois-queries	number of web-based WHOIS queries responded during the reporting period, not including searchable WHOIS
05	searchable-whois-queries	number of searchable WHOIS queries responded during the reporting period
06	dns-udp-queries-received	number of DNS queries received over UDP transport during the reporting period
07	dns-udp-queries-responded	number of DNS queries received over UDP transport that were responded during the reporting period
08	dns-tcp-queries-received	number of DNS queries received over TCP transport during the reporting period
09	dns-tcp-queries-responded	number of DNS queries received over TCP transport that were responded during the reporting period
10	srs-dom-check	number of SRS (EPP and any other interface) domain name “check” requests responded during the reporting period
11	srs-dom-create	number of SRS (EPP and any other interface) domain name “create” requests responded during the reporting period
12	srs-dom-delete	number of SRS (EPP and any other interface) domain name “delete” requests responded during the reporting period


13	srs-dom-info	number of SRS (EPP and any other interface) domain name “info” requests responded during the reporting period
14	srs-dom-renew	number of SRS (EPP and any other interface) domain name “renew” requests responded during the reporting period
15	srs-dom-rgp-restore-report	number of SRS (EPP and any other interface) domain name RGP “restore” requests delivering a restore report responded during the reporting period
16	srs-dom-rgp-restore-request	number of SRS (EPP and any other interface) domain name RGP “restore” requests responded during the reporting period
17	srs-dom-transfer-approve	number of SRS (EPP and any other interface) domain name “transfer” requests to approve transfers responded during the reporting period
18	srs-dom-transfer-cancel	number of SRS (EPP and any other interface) domain name “transfer” requests to cancel transfers responded during the reporting period
19	srs-dom-transfer-query	number of SRS (EPP and any other interface) domain name “transfer” requests to query about a transfer responded during the reporting period
20	srs-dom-transfer-reject	number of SRS (EPP and any other interface) domain name “transfer” requests to reject transfers responded during the reporting period
21	srs-dom-transfer-request	number of SRS (EPP and any other interface) domain name “transfer” requests to request transfers responded during the reporting period
22	srs-dom-update	number of SRS (EPP and any other interface) domain name “update” requests (not including RGP restore requests) responded during the reporting period
23	srs-host-check	number of SRS (EPP and any other interface) host “check” requests responded during the reporting period


24			srs-host-create			number of SRS (EPP and any other interface) host “create” requests responded during the reporting period


25	srs-host-delete	number of SRS (EPP and any other interface) host “delete” requests responded during the reporting period
26	srs-host-info	number of SRS (EPP and any other interface) host “info” requests responded during the reporting period
27	srs-host-update	number of SRS (EPP and any other interface) host “update” requests responded during the reporting period
28	srs-cont-check	number of SRS (EPP and any other interface) contact “check” requests responded during the reporting period
29	srs-cont-create	number of SRS (EPP and any other interface) contact “create” requests responded during the reporting period
30	srs-cont-delete	number of SRS (EPP and any other interface) contact “delete” requests responded during the reporting period
31	srs-cont-info	number of SRS (EPP and any other interface) contact “info” requests responded during the reporting period
32	srs-cont-transfer-approve	number of SRS (EPP and any other interface) contact “transfer” requests to approve transfers responded during the reporting period
33	srs-cont-transfer-cancel	number of SRS (EPP and any other interface) contact “transfer” requests to cancel transfers responded during the reporting period
34	srs-cont-transfer-query	number of SRS (EPP and any other interface) contact “transfer” requests to query about a transfer responded during the reporting period
35	srs-cont-transfer-reject	number of SRS (EPP and any other interface) contact “transfer” requests to reject transfers responded during the reporting period


36	srs-cont-transfer-request	number of SRS (EPP and any other interface) contact “transfer” requests to request transfers responded during the reporting period
37	srs-cont-update	number of SRS (EPP and any other interface) contact “update” requests responded during the reporting period
38	rdap-queries	number of RDAP queries responded during the reporting period.

The first line shall include the field names exactly as described in the table above as a “header line” as described in section 2 of RFC 4180. No other lines besides the ones described above shall be included. Line breaks shall be <U+000D, U+000A> as described in RFC 4180.

For the TLD that is a part of a single-instance Shared Registration System: (1) the fields whois-43-queries, web-whois-queries, searchable-whois-queries and rdap-queries in the Registry Functions Activity Report should match the sum of queries reported for the TLDs in the single-instance Shared Registration System, and Registry Operator has the flexibility to choose how to allocate those queries across the TLDs utilizing the single-instance Shared Registration System, (2) in case of queries related to the fields in (1) above for which the Registry Operator cannot determine the TLD to count the query to (e.g., a registrar lookup query for a registrar operating in more than one TLD sharing the same RDAP base URL), registry operator has the flexibility to choose how to allocate those queries across the TLDs utilizing the single-instance Shared Registration System, and (3) the Registry Functions Activity Report may include the total contact or host transactions for all the TLDs in the system.

.com Registry Agreement Appendix 5A

Registration Data Publication Services Specification

A. Definitions.

i. Registration Data Directory Services. Registration Data Directory Services or “RDDS” refers to the collective of WHOIS Data Directory Services (as defined in this Appendix 5A) and RDAP Directory Services, as defined in Appendix 5B.

ii. WHOIS Data Directory Services. WHOIS Data Directory Services refers to the collective of WHOIS service available via port 43 in accordance with RFC 3912 and a web-based WHOIS service providing free public query-based access to registration data.

1. WHOIS Data Directory Services. Registry Operator will operate a WHOIS service available via port 43 in accordance with RFC 3912, and a web-based WHOIS Service at <▇▇▇.▇▇▇▇▇▇▇▇.▇▇▇/▇▇▇▇▇> providing free public query-based access to at least the following elements in the following format.

1.1 The format of responses shall follow a semi-free text format outlined below, followed by a blank line and a legal disclaimer specifying the rights of Registry Operator, and of the user querying the database.

1.2 Each data object shall be represented as a set of key/value pairs, with lines beginning with keys, followed by a colon and a space as delimiters, followed by the value.

1.3 For fields where more than one value exists, multiple key/value pairs with the same key shall be allowed (for example to list multiple name servers). The first key/value pair after a blank line should be considered the start of a new record, and should be considered as identifying that record, and is used to group data, such as hostnames and IP addresses, or a domain name and registrant information, together.

1.4 The fields specified below set forth the minimum output requirements. Registry Operator must implement only those sections of the Registry Registration Data Directory Services Consistent Labeling and Display Policy (▇▇▇▇▇://▇▇▇.▇▇▇▇▇.▇▇▇/▇▇▇▇▇▇▇▇▇/▇▇▇▇▇/▇▇▇▇-▇▇▇▇▇▇▇▇-▇▇▇▇▇▇-▇▇▇▇-▇▇-▇▇-▇▇) in conjunction with this Appendix 5A that are relevant to the type of TLD operated, e.g., “thick” or “thin” registry model (e.g. exclude information from any contact: registrant, admin, tech, billing etc.). As of the Effective Date, the .com TLD is considered a “thin” registry model.

1.5 Domain Name Data

1.5.1 Query format: whois EXAMPLE.TLD

1.5.2 Response format:

Domain Name: EXAMPLE.TLD

Registry Domain ID: D1234567-TLD

Registrar WHOIS Server: whois.example.tld

Registrar URL: ▇▇▇▇://▇▇▇.▇▇▇▇▇▇▇.▇▇▇ Updated Date: 2009-05-29T20:13:00Z

Creation Date: 2000-10-08T00:45:00Z

Registry Expiry Date: 2010-10-08T00:44:59Z

Registrar Registration Expiration Date: 2010-10-08T00:44:59Z11

Registrar: EXAMPLE REGISTRAR LLC

Registrar IANA ID: 5555555

Registrar Abuse Contact Email: ▇▇▇▇▇@▇▇▇▇▇▇▇▇▇.▇▇▇

Registrar Abuse Contact Phone: +1.1235551234

Reseller: EXAMPLE RESELLER12

Domain Status: clientDeleteProhibited

Domain Status: clientRenewProhibited

Domain Status: clientTransferProhibited Domain Status: serverUpdateProhibited

Registry Registrant ID: 5372808-ERL

Registrant Name: EXAMPLE REGISTRANT

Registrant Organization: EXAMPLE ORGANIZATION

Registrant Street: ▇▇▇ ▇▇▇▇▇▇▇ ▇▇▇▇▇▇

Registrant City: ANYTOWN

Registrant State/Province: AP

Registrant Postal Code: A1A1A1

Registrant Country: EX

Registrant Phone: +1.5555551212

Registrant Phone Ext: 1234

Registrant Fax: +1.5555551213

Registrant Fax Ext: 4321

Registrant Email: ▇▇▇▇▇@▇▇▇▇▇▇▇.▇▇▇

Registry Admin ID: 5372809-ERL

Admin Name: EXAMPLE REGISTRANT ADMINISTRATIVE

Admin Organization: EXAMPLE REGISTRANT ORGANIZATION

Admin Street: ▇▇▇ ▇▇▇▇▇▇▇ ▇▇▇▇▇▇

Admin City: ANYTOWN

Admin State/Province: AP

Admin Postal Code: A1A1A1

Admin Country: EX

1 Field is optional.

2 Field is optional.

Admin Phone: +1.5555551212

Admin Phone Ext: 1234

Admin Fax: +1.5555551213

Admin Fax Ext:

Admin Email: ▇▇▇▇▇@▇▇▇▇▇▇▇.▇▇▇ Registry Tech ID: 5372811-ERL

Tech Name: EXAMPLE REGISTRAR TECHNICAL

Tech Organization: EXAMPLE REGISTRAR LLC

Tech Street: ▇▇▇ ▇▇▇▇▇▇▇ ▇▇▇▇▇▇

Tech City: ANYTOWN

Tech State/Province: AP

Tech Postal Code: A1A1A1

Tech Country: EX

Tech Phone: +1.1235551234

Tech Phone Ext: 1234

Tech Fax: +1.5555551213

Tech Fax Ext: 93

Tech Email: ▇▇▇▇▇@▇▇▇▇▇▇▇.▇▇▇

Name Server: NS01.EXAMPLEREGISTRAR.TLD

Name Server: NS02.EXAMPLEREGISTRAR.TLD

DNSSEC: signedDelegation

DNSSEC: unsigned

URL of the ICANN Whois Inaccuracy Complaint Form: ▇▇▇▇▇://▇▇▇.▇▇▇▇▇.▇▇▇/▇▇▇▇/

>>> Last update of WHOIS database: 2009-05-29T20:15:00Z <<<

1.6 Registrar Data

1.6.1 Query format: whois “registrar Example Registrar, Inc.”

1.6.2 Response format:

Registrar: Example Registrar, Inc.

Street: ▇▇▇▇ ▇▇▇▇▇▇▇▇▇ ▇▇▇

City: Marina del Rey State/Province: CA

Postal Code: 90292

Country: US

Phone Number: +1.3105551212

Fax Number: +1.3105551213

Email: ▇▇▇▇▇▇▇▇▇@▇▇▇▇▇▇▇.▇▇▇

Registrar WHOIS Server: whois.example-registrar.tld

Registrar URL: ▇▇▇▇://▇▇▇.▇▇▇▇▇▇▇-▇▇▇▇▇▇▇▇▇.▇▇▇ Admin Contact: ▇▇▇ ▇▇▇▇▇▇▇▇▇

Phone Number: +1.3105551213

Fax Number: +1.3105551213

Email: ▇▇▇▇▇▇▇▇▇▇▇▇@▇▇▇▇▇▇▇-▇▇▇▇▇▇▇▇▇.▇▇▇

Admin Contact: ▇▇▇▇ Registrar

Phone Number: +1.3105551214

Fax Number: +1.3105551213

Email: ▇▇▇▇▇▇▇▇▇▇▇▇▇@▇▇▇▇▇▇▇-▇▇▇▇▇▇▇▇▇.▇▇▇

Technical Contact: ▇▇▇▇ ▇▇▇▇

Phone Number: +1.3105551215

Fax Number: +1.3105551216

Email: ▇▇▇▇▇▇▇▇@▇▇▇▇▇▇▇-▇▇▇▇▇▇▇▇▇.▇▇▇

>>> Last update of WHOIS database: 2009-05-29T20:15:00Z <<<

1.7 Nameserver Data:

1.7.1 Query format: whois “nameserver (nameserver name)”, or whois “nameserver (IP Address).” For example: whois “nameserver NS1.EXAMPLE.TLD”.

1.7.2 Response format:

Server Name: NS1.EXAMPLE.TLD

IP Address: 192.0.2.123

IP Address: 2001:0DB8::1

Registrar: Example Registrar, Inc.

Registrar WHOIS Server: whois.example-registrar.tld

Registrar URL: ▇▇▇▇://▇▇▇.▇▇▇▇▇▇▇-▇▇▇▇▇▇▇▇▇.▇▇▇

>>> Last update of WHOIS database: 2009-05-29T20:15:00Z <<<

1.8 The format of the following data fields: domain status, individual and organizational names, address, street, city, state/province, postal code, country, telephone and fax numbers (the extension will be provided as a separate field as shown above), email addresses, date and times should conform to the mappings specified in EPP RFCs 5730-5734 so that the display of this information (or values return in WHOIS responses) can be uniformly processed and understood.

2. RDDS Policy and Educational Materials. Registry Operator shall provide a link on the primary website for the TLD (i.e., the website provided to ICANN for publishing on the ICANN website) to a web page designated by ICANN containing RDDS policy and educational materials.

3. Searchability. Offering searchability capabilities for the registration data provided via RDDS is optional but if offered by the Registry Operator it shall comply with the specification described in this section.

3.1 Registry Operator will offer searchability as a web-based service.

3.2 Registry Operator will offer partial match capabilities on each of the following fields: domain name, contacts and registrant’s name, and contact and registrant’s postal address, including all the sub-fields described in EPP (e.g., street, city, state or province, etc.), and may offer partial match capabilities on other fields, in each case subject to applicable law.

3.3 Registry Operator will offer exact-match capabilities, at least, on the following fields: Registrar ID, name server name, and name server’s IP address (only applies to IP addresses stored by the registry, i.e., glue records).

3.4 Registry Operator will offer Boolean search capabilities supporting, at least, the following logical operators to join a set of search criteria: AND, OR, NOT.

3.5 Search results will include domain names matching the search criteria.

3.6 Registry Operator will: 1) implement appropriate measures to avoid abuse of this feature (e.g., permitting access only to legitimate authorized users); and 2) ensure the feature is in compliance with any applicable privacy laws and ICANN Consensus Policies and Temporary Policies.

3.7 Registry Operator shall only offer the searchability capabilities required in the RDAP Technical Implementation Guide and RDAP Response Profile in the RDAP Directory Services, as described in Section 2.1 of Appendix 5B.

4. Registration Data Directory Services (RDDS) Requirements. As of December 1, 2024, Registry Operator shall comply with the following requirements:

4.1. Registry Operator shall offer public IPv6 and IPv4 transports for its RDDS.

4.2. In order to ensure that authoritative information about the TLD remains publicly available, Registry Operator shall submit a change request to the IANA functions operator updating any outdated or inaccurate DNS, WHOIS or RDAP base URL of the RDAP Directory Services records of the TLD. Registry Operator shall use commercially reasonable efforts to submit any such change request no later than seven (7) calendar days after the date any such DNS, WHOIS or RDAP base URL of the RDAP service records becomes outdated or inaccurate. Registry Operator must submit all change requests in accordance with the procedures set forth at ▇▇▇▇▇://▇▇▇.▇▇▇▇.▇▇▇/▇▇▇▇▇▇▇/▇▇▇▇.

4.3. Personal data included in the registration data must be redacted in accordance with ICANN Consensus Policies and Temporary Policies.

4.4. Registry Operator must adhere to the requirements related to additional fields of the Consistent Labeling and Display Consensus Policy if Registry Operator chooses to add data fields.

4.5 In the event of a conflict between the Registration Data Directory Service requirements and Consensus Policies or any Temporary Policy, the Consensus Policies or Temporary Policy shall control, but only with respect to subject matter in conflict and in accordance with Section 3.1(b) (Consensus Policies) of the Agreement.

4.6. Until such time that updates are made and effective for Consensus Policies and procedures pursuant to the Phase 1 GNSO Consensus Policy recommendations of the Expedited Policy Development Process on the Temporary Specification for gTLD Registration Data, adopted by the ICANN Board in May 2019, the following terms in such policies will be interpreted as follows:

4.6.1 With the exception of “Searchable Whois” and the “Whois contact lookup service”, the following terms: “WHOIS”, “Whois”, “Whois service”, “Publicly accessible Whois”, and variations thereof shall be interpreted to refer to RDDS as defined in this Appendix.

4.6.2 “Whois data”, “WHOIS information”, “Whois contact information”, “WHOIS query data”, “WHOIS details”, “Whois output”, “Whois record”, “Whois entry”, and variations thereof shall be interpreted to refer to registration data as referenced in this Appendix.

4.7. Cooperation with Transition Studies. If ICANN initiates or commissions a study on the transition of WHOIS Data Directory Services to RDAP Directory Services, Registry Operator shall reasonably cooperate with such study, including by delivering to ICANN or its designee conducting such study, both quantitative and qualitative data related to its experience offering RDAP Data Directory Services. If the data request is beyond what the Registry Operator collects in the ordinary course of its operations and beyond the data that Registry Operator is required to collect and provide to ICANN org pursuant to this Agreement, Registry Operator should voluntarily cooperate to provide the requested information or provide an explanation to ICANN why the Registry Operator is not able to provide the requested information. The terms of this section do not require Registry Operator to provide data to ICANN that is beyond what Registry Operator is obligated to provide ICANN pursuant to other sections of this Agreement. Any data delivered to ICANN or its designee pursuant to this section that is appropriately marked as confidential shall be treated as confidential information of Registry Operator, provided that, notwithstanding the Agreement, if ICANN or its designee aggregates and makes anonymous such data, ICANN or its designee may disclose such data to any third party. Following completion of the transition study for which Registry Operator has provided data, ICANN will destroy all data provided by Registry Operator pursuant to this section that has not been aggregated and made anonymous.

5. Bulk Registration Data Access to ICANN

5.1 Periodic Access to Thin Registration Data. In order to verify and ensure the operational stability of the Registry Services, analyze the operational stability of the DNS and facilitate compliance checks and audits of accredited registrars, Registry Operator will provide ICANN on a daily basis with up-to-date registration data as specified in this Section 5.1. Data will include data committed as of 00:00:00 UTC on the previous day. On an annual basis, ICANN will publish a summary of the research projects that utilized this data in the preceding year, along with a listing of any organizations the raw data was shared with to conduct the research.

5.1.1 Contents. Registry Operator will provide the following data for all registered domain names: domain name, domain name repository object id (roid), Registrar ID (IANA ID), statuses, last updated date, creation date, expiration date, and name server names. For sponsoring registrars, Registry Operator will provide: registrar name, registrar ID (IANA ID), hostname of registrar WHOIS server (which shall continue to be provided after January 28, 2025, if provided by registrar) and URL of registrar. Registry Operator shall not provide any additional data elements.

5.1.2 Format. The data will be provided in the format specified in Appendix 1 Data Escrow Specification (including encryption, signing, etc.) but including only the fields mentioned in the previous section, i.e., the file will only contain Domain and Registrar objects with the fields mentioned above.

5.1.3 Access. Registry Operator will have the file(s) ready for download as of 00:00:00 UTC for retrieval by ICANN. The file(s) will be made available for download by SFTP, though ICANN may request other means in the future.

5.2 Exceptional Access to Thick Registration Data. This Section 5.2 shall only apply on or after the date the TLD is operated as a “thick” registry model, if any. In case of a registrar failure, deaccreditation, court order, etc. that prompts the temporary or definitive transfer of its domain names to another registrar, at the request of ICANN, Registry Operator will provide ICANN with up-to-date data for the domain names of the losing registrar. The data will be provided in the format specified in Appendix 1 Data Escrow Specification. The file will only contain data related to the domain names of the losing registrar. Registry Operator will provide the data as soon as commercially practicable, but in no event later than five (5) calendar days following ICANN’s request. Unless otherwise agreed by Registry Operator and ICANN, the file will be made available for download by ICANN in the same manner as the data specified in Section 5.1 of this Appendix.

.com Registry Agreement Appendix 5B

Registration Data Access Protocol

Service Specification

1Scope and Definitions.

1.1. [RESERVED]

1.2. [RESERVED]

1.3“Registration Data Access Protocol” or “RDAP” is an Internet protocol that provides “RESTful” web services to retrieve registration metadata from domain name registries and regional internet registries.

1.4. “RDAP Directory Services” or “RDAP-RDDS” refers to a Registration Data Directory Service using the RDAP described in STD 95 (▇▇▇▇▇://▇▇▇.▇▇▇-▇▇▇▇▇▇.▇▇▇/▇▇▇▇/▇▇▇-▇▇▇▇▇.▇▇▇), and its successor standards.

1.5. “RDAP-query RTT” refers to the round-trip time (“RTT”) of the sequence of packets from the start of an RDAP-RDDS testing probe’s TCP connection to its end, including the reception of the HTTPS response for only one HTTPS request. If the RTT is 5 times or more the corresponding SLR/performance specifications, the RTT will be considered undefined.

1.6. “RDAP Availability” refers to the ability of the RDAP-RDDS service for the TLD, to respond to queries from an Internet user with appropriate data from the relevant Registry System. If 51% or more of the RDAP testing probes see the RDAP-RDDS service as unavailable during a given time, the RDAP-RDDS service will be considered unanswered.

1.7. “RDAP Update Time” refers to the time measured from the receipt of an EPP confirmation to a transform command on a domain name, host or contact, up until at least 51% of the verifiably working RDAP-RDDS testing probes detect the changes made.

2. RDAP Directory Services.

2.1 Registry Operator shall implement the most recent version of the RDAP Technical Implementation Guide and RDAP Response Profile posted at ▇▇▇▇▇://▇▇▇▇▇.▇▇▇/▇▇▇▇-▇▇▇▇-▇▇▇▇▇▇▇. Registry Operator will implement new versions of the RDAP Technical Implementation Guide and RDAP Response Profile no later than one hundred eighty (180) calendar days after notification from ICANN.

2.2 Registry Operator shall provide lookup query support for:

2.2.1 domain information as described in the section “Domain Path Segment Specification” of RFC 9082.

2.2.2 nameserver information as described in the section “Nameserver Path Segment Specification” of RFC 9082; provided, however, that Registry Operator shall not be required to (but may still choose to) support nameserver lookup if Registry Operator specifies name servers as domain attributes in EPP.

2.2.3 registrar information as described in the section “Entity Path Segment Specification” of RFC 9082.

2.2.4 help information as described in the section "Help Path Segment Specification" of RFC 9082.

3. Service Level Requirements. Registry Operator shall meet each of the following Service Level Requirements:

3.1. Service Level Requirements Matrix


	Parameter	Service Level Requirements (SLR)/Performance Specification (monthly basis)
RDAP-RDDS	RDAP Availability	≦ 864 min of downtime (98%)
	RDAP query RTT	≦ 4000 ms, for at least 95% of the queries
	RDAP Update Time	≦ 60 min, for at least 95% of the updates

3.2. Registry Operator shall monitor and measure its performance of the RDAP-RDDS Service Level Requirements set forth in Section 3.1 above using Registry Operator’s

monitoring probes for the sole purpose of: (a) determining Registry Operator’s performance of the RDAP-RDDS service for the calculation of SLA Credits to registrars, if any; and (b) providing RDAP Service Level Requirement performance data to ICANN in accordance with Appendix 4, Section 1 (Service Level Agreement Performance Report).

3.3. Registry Operator is encouraged to do maintenance for RDAP at the times and dates of statistically lower traffic for each parameter. However, there is no provision for planned outages or similar periods of unavailability; any downtime, be it for maintenance or due to system failures, will be noted simply as downtime and counted for Service Level Requirement measurement purposes.

3.3.1 In the event that Registry Operator plans RDAP maintenance, it will provide notice to the ICANN emergency operations department, at least, twenty-four (24) hours ahead of that maintenance. ICANN’s emergency operations department will note planned maintenance times and suspend emergency escalation services for the monitored services during the expected maintenance outage period.

3.4. The remedies for a failure to meet an RDAP Service Level Requirement set forth in Section 3.1 shall be equivalent to the remedies under this Agreement for a failure to meet the corresponding Performance Specification for the WHOIS service, provided, however, that in the event of a failure of the RDAP-RDDS service and WHOIS service in a given month, SLA Credits, if applicable, for Registrars shall not exceed the total amount of SLA Credits attributable solely to the failure of the service level requirement for the WHOIS service, pursuant to Registry Operator’s Agreement.

3.5. [RESERVED].

3.6. The parties agree that the SLA Credits as described in Section 3.4 above are the total credits, penalties and/or liabilities that may be assessed to Registry Operator and the sole remedies available to registrar for Registry Operator’s failure to meet the Service Level Requirements for the RDAP-RDDS service.

3.7. Registry Operator will use commercially reasonable efforts to restore the RDAP-RDDS service functionality within 24 hours after the termination of a force majeure event. Outages due to a force majeure will not be considered service unavailability for purposes of Appendix 7 or the Service Level Requirements.

3.8. Registry Operator shall not be liable to ICANN or registrars for any credits or penalties, or be deemed to be in breach of any of its obligations under the Agreement, if it fails to meet a Service Level Requirement for the RDAP-RDDS service as a result of its compliance with any Consensus Policy

established after the Effective Date, to the extent and for so long as, the failure to meet the Service Level Requirement for the RDAP-RDDS service is unavoidable by commercially reasonable efforts due to Registry Operator's compliance with such Consensus Policy.

3.9. The Service Level Requirements set forth in Section 3 of this Appendix 5B for the RDAP-RDDS service and the RDAP Measurement Parameters set forth in Section 4.5 of this Appendix 5B for the RDAP-RDDS service shall be considered “Performance Specifications” and the “RDAP-RDDS” service shall be considered a “System Service” for purposes of this Agreement and shall be treated as though set forth in Appendix 7.

3.10. In order to determine the appropriate credit level and calculation of an SLA Credit due to a failure by the Registry Operator to meet a Service Level Requirement, the credit level and calculation shall be based on the equivalent reference set forth in the chart below and in accordance with this Agreement.


RDAP-RDDS Service Level Requirement			Equivalent Reference for Purposes of Calculating the Credit Level of the SLA Credit
RDAP Availability			Service Availability--Whois
RDAP-query RTT			Processing Time--Whois Query
RDAP Update Time			Update Frequency--Whois

3.11. The notice requirement in Section 8.1 of Appendix 7 to be provided by the losing registrar in a Bulk Transfer After Partial Portfolio Acquisition shall include a description of how the RDDS record will change after such bulk transfer occurs.

4. RDAP Measurement Parameters.

4.1. RDAP test. Means one query sent to a particular IP address of one of the servers of the RDAP-RDDS service. Queries shall be about existing objects in the Registry System and the responses must contain the corresponding information otherwise the query will be considered unanswered. Queries with an RTT 5 times higher than the corresponding SLR will be considered as unanswered. The possible results to an RDAP test are: a number in milliseconds corresponding to the RDAP-query RTT or unanswered.

4.2. Measuring RDAP parameters. Every 5 minutes, each of the RDAP-RDDS probes will select one IP address from all the public-DNS registered “IP addresses” of the servers of the RDAP-RDDS service of the TLD being monitored and make an “RDAP test”. If an RDAP test result is unanswered, the corresponding RDAP-RDDS service will be considered as unavailable from that probe until it is time to make a new test.

4.3. Collating the results from RDAP-RDDS probes. The minimum number of active testing working RDAP-RDDS testing probes to consider a measurement valid is 10 at any given measurement period, otherwise the measurements will be discarded and will be considered “inconclusive”; during this situation no fault will be flagged against the SLRs.

4.4. Placement of RDAP-RDDS probes. ICANN will use commercially reasonable efforts to deploy probes for measuring RDAP parameters in data centers with carrier grade connectivity in each of the ICANN geographic regions.

4.5. No interference. Registry Operator shall not interfere with measurement probes, including any form of preferential treatment of the requests for the monitored services. Registry Operator shall respond to the measurement tests described in this Appendix as it would to any other request from an Internet user for RDAP.

4.6. Emergency Escalation. Registry Operator and ICANN shall provide the contact information of their respective emergency operations departments to the other party for the purposes of this Section and such contact information shall be maintained and kept current at all times by both Registry Operator and ICANN. ICANN shall issue an emergency escalation notice informing Registry Operator of any possible or potential issues in relation to the monitored RDAP-RDDS service. Upon the issuance of an emergency escalation notice, Registry Operator and ICANN shall cooperate and use commercially reasonable efforts to diagnose and/or resolve the identified issue(s), including through the sharing of appropriate measurement data. The initiation of any emergency escalation and the subsequent cooperation to diagnose and/or resolve the identified issue(s) do not in themselves imply or otherwise establish that the monitored RDAP-RDDS service has failed the applicable Service Level Requirements set forth in Section 3.1 above.

5. ICANN reserves the right to specify alternative formats and protocols approved as “Internet Standards” (as opposed to Informational or Experimental standards) through the applicable IETF processes with respect to registration data referenced in Appendix 5A and Appendix 5B. Upon such specification, ICANN shall: (a) work collaboratively with Registry Operator and other gTLD registries and ICANN-accredited registrars to define all operational requirements necessary to implement the applicable standard; and (b) if applicable, initiate negotiations with Registry Operator to define all reporting requirements (if any), and reasonable service level requirements commensurate with similarly situated services and as applicable to the TLD.

.com Registry Agreement Appendix 6

Schedule of Reserved Names

Except to the extent that ICANN otherwise expressly authorizes in writing, the Registry Operator shall reserve names formed with the following labels from initial (i.e. other than renewal) registration within the TLD:

A. Labels Reserved at All Levels. The following names shall be reserved at the second level and at all other levels within the TLD at which Registry Operator makes registrations:

ICANN-related names:

•aso

•gnso

•icann

•internic

•ccnso

IANA-related names:

•afrinic

•apnic

•arin

•example

•gtld-servers

•iab

•iana

•iana-servers

•iesg

•ietf

•irtf

•istf

•lacnic

•latnic

•rfc-editor

•ripe

•root-servers

B. Additional Second-Level Reservations. In addition, the following names shall be reserved at the second level:

•All single-character labels. Notwithstanding this reservation the single-character label ▇.▇▇▇ may be released pursuant to the ▇.▇▇▇ Service (defined in Appendix 7, Section 8.2).

•All two-character labels shall be initially reserved. The reservation of a two-character label string shall be released to the extent that the Registry Operator reaches agreement with the government and country-code manager, or the ISO 3166 maintenance agency, whichever appropriate. The Registry Operator may also propose release of these reservations based on its implementation of measures to avoid confusion with the corresponding country codes.

C. Tagged Domain Names. All labels with hyphens in the third and fourth character positions (e.g., "bq--1k2n4h4b" or "xn--ndk061n")

D. Second-Level Reservations for Registry Operations. The following names are reserved for use in connection with the operation of the registry for the Registry TLD. They may be used by Registry Operator, but upon conclusion of Registry Operator's designation as operator of the registry for the Registry TLD they shall be transferred as specified by ICANN:

•nic

•whois

•www

.com Registry Agreement Appendix 7

Functional and Performance Specifications

These functional specifications for the Registry TLD consist of the following parts:

1. Registry Operator Registrar Protocol;

2. Supported initial and renewal registration periods;

3. Grace period policy;

4. Nameserver functional specifications;

5. Patch, update, and upgrade policy;

6. Performance Specifications;

7. Responsibilities of the Parties;

8. Additional Services; and

9. Implementation of New Standards

1. Registry Operator Registrar Protocol

1.1 Extensible Provisioning Protocol

Registry Operator shall maintain the Extensible Provisioning Protocol ("EPP") in conformance with the Proposed Standard and Informational RFCs 5730, 5731, 5732, 5734, 5910, and 3915 (and in the event Registry Operator accepts thick registration data RFC 5733) published by the Internet Engineering Task Force ("IETF") and/or any successor standards, versions, modifications or additions thereto as Registry Operator deems reasonably necessary. Registry Operator will support EPP in conformance with the aforementioned standards. If Registry Operator requires the use of functionality outside of EPP RFCs, Registry Operator must document EPP extensions using Internet-Draft format following the guidelines described in RFC 3735. Registry Operator is not required to submit documented EPP extensions to the IETF but to consider the recommendations on standardization described in section 2.1 of RFC 3735. Registry Operator will provide and update the relevant documentation of all the EPP objects and Extensions supported to ICANN prior to deployment.

Registry Operator shall be able to accept IPv6 addresses as glue records in its Registry System and publish them in the DNS. Registry Operator shall offer public IPv6 transport for its Shared Registration System (SRS) to any Registrar, no later than six months after receiving the first request in writing from a gTLD accredited Registrar willing to operate the SRS over IPv6.

Registry Operator shall take action to remove orphan glue records (as defined at ▇▇▇▇://▇▇▇.▇▇▇▇▇.▇▇▇/▇▇/▇▇▇▇▇▇▇▇▇▇/▇▇▇▇▇▇▇▇/▇▇▇▇▇▇.▇▇▇) when provided with evidence in written form that such records are present in connection with malicious conduct.

2. Supported initial and renewal registration periods

2.1. Initial registrations of Registered Names (where available according to functional specifications and other requirements) may be made in the registry for terms of up to ten years.

2.2. Renewal registrations of Registered Names (where available according to functional specifications and other requirements) may be made in the registry for terms not to exceed a total of ten years.

2.3. Upon change of sponsorship of the registration of a Registered Name from one Registrar to another, according to Part A of the ICANN Policy on Transfer of Registrations between Registrars, the term of registration of the Registered Name shall be extended by one year, provided that the maximum term of the registration as of the effective date of sponsorship change shall not exceed ten years.

2.4. The change of sponsorship of registration of Registered Names from one Registrar to another, according to Part B of the ICANN Policy on Transfer of Registrations between Registrars shall not result in the extension of the term of the registrations and Registry Operator may assist in such change of sponsorship.

3. Grace period policy

This section describes Registry Operator's practices for operational "Grace" and "Pending" periods, including relationships among sequential operations that occur within given time frames. A Grace Period refers to a specified number of calendar days following a Registry operation in which a domain action may be reversed and a credit may be issued to a Registrar. Relevant registry operations in this context are:

•Registration of a new domain,

•Renewal of an existing domain,

•Auto-Renew of an existing domain;

•Transfer of an existing domain; and

•Deletion of an existing domain.

Extension of a registration period is accomplished using the EPP RENEW command or by auto-renewal; registration is accomplished using the EPP CREATE command; deletion/removal is accomplished using the EPP DELETE command; transfer is accomplished using the EPP TRANSFER command or, where ICANN approves a bulk transfer under Part B of the ICANN Policy on Transfer of Registrations between Registrars, using the procedures specified in that Part. Restore is accomplished using the EPP UPDATE command.

There are five grace periods provided by Registry Operator's Shared Registration System: Add Grace Period, Renew/Extend Grace Period, Auto-Renew Grace Period, Transfer Grace Period, and Redemption Grace Period.

A Pending Period refers to a specified number of calendar days following a Registry operation in which final Registry action is deferred before the operation may be completed. Relevant Registry operations in this context are:

•Transfer of an existing domain,

•Deletion of an existing domain, and

•Restoration of a domain name in Redemption Grace Period.

3.1. Grace Periods

3.1.1 Add Grace Period

The Add Grace Period is a specified number of calendar days following the initial registration of a domain. The current value of the Add Grace Period for all Registrars is five calendar days. If a Delete, Extend (EPP Renew command), or Transfer operation occurs within the five calendar days, the following rules apply:

Delete. If a domain is deleted within the Add Grace Period, the sponsoring Registrar at the time of the deletion is credited for the amount of the registration; provided, however, that Registry Operator shall have the right to charge Registrars a fee as may be set forth in its Registry-Registrar Agreement for disproportionate deletes during the Add Grace Period. The domain is deleted from the Registry database and is immediately available for registration by any Registrar. See Section 3.2 for a description of overlapping grace period exceptions.

Extend (EPP Renew command). If a domain is extended within the Add Grace Period, there is no credit for the add. The expiration date of the domain registration is extended by the number of years, up to a total of ten years, as specified by the Registrar's requested Extend operation.

Transfer (other than ICANN-approved bulk transfer). Transfers under Part A of the ICANN Policy on Transfer of Registrations between Registrars may not occur during the Add Grace Period or at any other time within the first 60 days after the initial registration. Enforcement is the responsibility of the Registrar sponsoring the domain name registration and is enforced by the SRS.

Bulk Transfer (with ICANN approval). Bulk transfers with ICANN approval may be made during the Add Grace Period according to the procedures in Part B of the ICANN Policy on Transfer of Registrations between Registrars. The expiration dates of transferred registrations are not affected. The losing Registrar's account is charged for the initial add.

3.1.2. Renew/Extend Grace Period

The Renew/Extend Grace Period is a specified number of calendar days following the renewal/extension of a domain name registration period through an EPP Command Renew. The current value of the Renew/Extend Grace Period is five calendar days. If a Delete, Extend, or Transfer occurs within that five calendar days, the following rules apply:

Delete. If a domain is deleted within the Renew/Extend Grace Period, the sponsoring Registrar at the time of the deletion receives a credit of the renew/extend fee. The domain immediately goes into the Redemption Grace Period. See Section 3.2 for a description of overlapping grace period exceptions.

Extend ("EPP Command 'Renew'"). A domain can be extended within the Renew/Extend Grace Period for up to a total of ten years. The account of the sponsoring Registrar at the time of the additional extension will be charged for the additional number of years the registration is extended.

Transfer (other than ICANN-approved bulk transfer). If a domain is transferred within the Renew/Extend Grace Period, there is no credit. The expiration date of the domain registration is extended by one year and the years added as a result of the Extend remain on the domain name up to a total of 10 years.

Bulk Transfer (with ICANN approval). Bulk transfers with ICANN approval may be made during the Renew/Extend Grace Period according to the procedures in Part B of the ICANN Policy on Transfer of Registrations between Registrars. The expiration dates of transferred registrations are not affected. The losing Registrar's account is charged for the Renew/Extend operation.

3.1.3. Auto-Renew Grace Period

The Auto-Renew Grace Period is a specified number of calendar days following an auto-renewal. An auto-renewal occurs if a domain name registration is not renewed by the expiration date; in this circumstance the registration will be automatically renewed by the system the first day after the expiration date. The current value of the Auto-Renew Grace Period is 45 calendar days. If a Delete, Extend, or Transfer occurs within the Auto-Renew Grace Period, the following rules apply:

Delete. If a domain is deleted within the Auto-Renew Grace Period, the sponsoring Registrar at the time of the deletion receives a credit of the Auto-Renew fee. The domain immediately goes into the Redemption Grace Period. See Section 3.2 for a description of overlapping grace period exceptions.

Extend. A domain can be extended within the Auto-Renew Grace Period for up to a total of ten years. The account of the sponsoring Registrar at the time of the additional extension will be charged for the additional number of years the registration is extended.

Transfer (other than ICANN-approved bulk transfer). If a domain is transferred within the Auto-Renew Grace Period, the losing Registrar is credited with the Auto-Renew charge and the year added by the Auto-Renew operation is cancelled. The expiration date of the domain is extended by one year up to a total maximum of ten and the gaining Registrar is charged for that additional year, even in cases where a full year is not added because of the 10-year registration term maximum limitation.

Bulk Transfer (with ICANN approval). Bulk transfers with ICANN approval may be made during the Auto-Renew Grace Period according to the procedures in Part B of the ICANN Policy on Transfer of Registrations between Registrars. The expiration dates of transferred registrations are not affected. The losing Registrar's account is charged for the Auto-Renew.

3.1.4. Transfer Grace Period

The Transfer Grace Period is a specified number of calendar days following the transfer of a domain according to Part A of the ICANN Policy on Transfer of Registrations between Registrars. The current value of the Transfer Grace Period is five calendar days. If a Delete, Extend, or Transfer occurs within that five calendar days, the following rules apply:

Delete. If a domain is deleted within the Transfer Grace Period, the sponsoring Registrar at the time of the deletion receives a credit of the transfer fee. The domain immediately goes into the Redemption Grace Period. See Section 3.2 for a description of overlapping grace period exceptions.

Extend. If a domain registration is extended within the Transfer Grace Period, there is no credit for the transfer. The Registrar's account will be charged for the number of years the registration is extended. The expiration date of the domain registration is extended by the number of years, up to a maximum of ten years, as specified by the Registrar's requested Extend operation.

Transfer (other than ICANN-approved bulk transfer). If a domain is transferred within the Transfer Grace Period, there is no credit. The expiration date of the domain registration is extended by one year up to a maximum term of ten years. The ICANN Policy on Transfer of Registrations between Registrars does not allow transfers within the first 60 days after another transfer has occurred; it is the Registrar's responsibility to enforce this restriction.

Bulk Transfer (with ICANN approval). Bulk transfers with ICANN approval may be made during the Transfer Grace Period according to the procedures in Part B of the ICANN Policy on Transfer of Registrations between Registrars. The expiration dates of transferred registrations are not affected. The losing Registrar's account is charged for the Transfer operation that occurred prior to the Bulk Transfer.

3.1.5. Bulk Transfer Grace Period

There is no grace period associated with Bulk Transfer operations. Upon completion of the Bulk Transfer, any associated fee is not refundable.

3.1.6 Redemption Grace Period

A domain name is placed in REDEMPTIONPERIOD status when a Registrar requests the deletion of a domain that is not within the Add Grace Period. A name that is in REDEMPTIONPERIOD status will not be included in the zone file. A Registrar cannot modify or purge a domain in REDEMPTIONPERIOD status. The only action a Registrar can take on a domain in REDEMPTIONPERIOD is to request that it be restored. Any other Registrar requests to modify or otherwise update the domain will be rejected. Unless restored, the domain will be held in REDEMPTIONPERIOD status for a specified number of calendar days. The current length of this Redemption Period is 30 calendar days.

3.2. Overlapping Grace Periods

If an operation is performed that falls into more than one grace period, the actions appropriate for each grace period apply (with some exceptions as noted below).

•If a domain is deleted within the Add Grace Period and the Extend Grace Period, then the Registrar is credited the registration and extend amounts, taking into account the number of years for which the registration and extend were done.

•If a domain is auto-renewed, then extended, and then deleted within the Extend Grace Period, the Registrar will be credited for any Auto-Renew fee charged and the number of years for the extension.

3.2.1. Overlap Exception

•If a domain registration is extended within the Transfer Grace Period, then the current Registrar's account is charged for the number of years the registration is extended.

Note: If several billable operations, including a transfer, are performed on a domain and the domain is deleted within the grace periods of each of those operations, only those operations that were performed after the latest transfer, including the latest transfer, are credited to the current Registrar.

3.3. Pending Periods

3.3.1. Transfer Pending Period

The Transfer Pending Period is a specified number of calendar days following a request from a Registrar (Registrar A) to transfer a domain in which the current Registrar of the domain (Registrar B) may explicitly approve or reject the transfer request. The current value of the Transfer Pending Period is five calendar days for all Registrars. The transfer will be finalized upon receipt of explicit approval or rejection from the current Registrar (Registrar B). If the current Registrar (Registrar B) does not explicitly approve or reject the request initiated by Registrar A, the Registry Operator will approve the request automatically after the end of the Transfer Pending Period. During the Transfer Pending Period:

▇. ▇▇▇ TRANSFER request or EPP RENEW request is denied.
b. SYNC is not allowed.
▇. ▇▇▇ DELETE request is denied.
d. Bulk Transfer operations are allowed.
▇. ▇▇▇ UPDATE request is denied.

After a transfer of a domain, the EPP TRANSFER request may be denied for 60 days.

3.3.2. Pending Delete Period

A domain name is placed in PENDING DELETE status if it has not been restored during the Redemption Grace Period. A name that is in PENDING DELETE status will not be included in the zone file. All Registrar requests to modify or otherwise update a domain in PENDING DELETE status will be rejected. A domain name is purged from the registry database a specified number of calendar days after it is placed in PENDING DELETE status. The current length of this Pending Delete Period is five calendar days.

4. Nameserver functional specifications

Nameserver operations for the Registry TLD shall comply with RFCs 1034, 1035, 1982, 2181, 2182, 2671, 3226, 3596, 3597, 4343, and 5966 published by the Internet Engineering Task Force ("IETF") and/or any successor standards, versions, modifications or additions thereto.

Registry Operator shall sign its TLD zone files implementing Domain Name System Security Extensions ("DNSSEC"). Registry Operator shall comply with RFCs 4033, 4034, 4035, 4509 and their successors, and the parties agree that best practices described in RFC 4641 and its successors are recommended but not mandatory. If Registry Operator implements Hashed Authenticated Denial of Existence for DNS Security Extensions, it shall comply with RFC 5155 and its successors. Registry Operator shall accept public-key material from child domain names in a secure manner according to industry best practices. Registry shall also publish in its website the DNSSEC Practice Statements (DPS) describing critical security controls and procedures for key material storage, access and usage for its own keys and secure acceptance of registrants' public-key material. Registry Operator shall publish its DPS following the format described in RFC 6841.

Registry Operator shall offer public IPv6 transport for, at least, two of the Registry's name servers listed in the root zone with the corresponding IPv6 addresses registered with IANA. Registry Operator should follow "DNS IPv6 Transport Operational Guidelines" as described in BCP 91 and the recommendations and considerations described in RFC 4472.

For domain names which are either not registered, or the registrant has not supplied valid records such as NS records for listing in the DNS zone file, or their status does not allow them to be published in the DNS, the use of DNS wildcard Resource Records as described in RFCs 1034 and 4592 or any other method or technology for synthesizing DNS Resources Records or using redirection within the DNS by the Registry Operator is prohibited. When queried for such domain names the authoritative name servers must return a "Name Error" response (also known as ▇▇▇▇▇▇▇▇), RCODE 3 as described in RFC 1035 and related RFCs. This provision applies for all DNS zone files at all levels in the DNS tree for which the Registry Operator (or an affiliate engaged in providing Registration Services) maintains data, arranges for such maintenance, or derives revenue from such maintenance but this provision shall not apply to the provision of nameservice or any other non-registry service for a domain or zone used for other than registration services to unaffiliated third parties by a single entity (including its affiliates) for domain names registered through an ICANN-Accredited Registrar.

If the Registry Operator offers Internationalized Domain Names ("IDNs"), it shall comply with RFCs 5890, 5891, 5892, 5893 and their successors. Registry Operator shall comply with the ICANN IDN Guidelines at ▇▇▇▇▇://▇▇▇.▇▇▇▇▇.▇▇▇/▇▇/▇▇▇▇▇▇/▇▇▇/▇▇▇▇▇▇▇▇▇▇▇▇▇▇-▇▇▇▇▇▇▇▇▇▇.▇▇▇, as they may be amended, modified, or superseded from time to time. Registry Operator shall publish and keep updated its IDN Tables and IDN Registration Rules in the IANA Repository of IDN Practices.

5. Patch, update, and upgrade policy

Registry Operator may issue periodic patches, updates or upgrades to the Software, EPP or APIs ("Licensed Product") licensed under the Registry-Registrar Agreement (the "Agreement") that will enhance functionality or otherwise improve the Shared Registration System under the Agreement. For the purposes of this Section 5 of Appendix 7, the following terms have the associated meanings set forth herein.

5.1 A "Patch" means minor modifications to the Licensed Product made by Registry Operator during the performance of error correction services. A Patch does not constitute a Version.

5.2 An "Update" means a new release of the Licensed Product which may contain error corrections, minor enhancements, and, in certain circumstances, major enhancements, and which is indicated by a change in the digit to right of the decimal point in the version number of the Licensed Product.

5.3 An "Upgrade" means a new release of the Licensed Product which involves the addition of substantial or substantially enhanced functionality and which is indicated by a change in the digit to the left of the decimal point in the version of the Licensed Product.

5.4 A "Version" means the Licensed Product identified by any single version number.

Each Update and Upgrade causes a change in version.
* Patches do not require corresponding changes to client applications developed, implemented, and maintained by each Registrar.
* Updates may require changes to client applications by each Registrar in order to take advantage of the new features and/or capabilities and continue to have access to the Shared Registration System.
* Upgrades require changes to client applications by each Registrar in order to take advantage of the new features and/or capabilities and continue to have access to the Shared Registration System.

Registry Operator, in its sole discretion, will deploy Patches during scheduled and announced Shared Registration System maintenance periods.

For Updates and Upgrades, Registry Operator will give each Registrar notice prior to deploying the Updates and Upgrades into the production environment. The notice shall be at least ninety (90) days. Such notice will include an initial notice before deploying the Update that requires changes to client applications or the Upgrade into the Operational Test and Evaluation ("OT&E") environment to which all Registrars have access. Registry Operator will maintain the Update or Upgrade in the OT&E environment for at least thirty (30) days, to allow each Registrar the opportunity to modify its client applications and complete testing, before implementing the new code in the production environment.

This notice period shall not apply in the event Registry Operator's system is subject to the imminent threat of a failure or a material security threat, the discovery of a major security vulnerability, or a Denial of Service (DoS) attack where the Registry Operator's systems are rendered inaccessible by being subject to:

i) excessive levels of data traffic
ii) unauthorized traffic
iii) data traffic not conforming to the protocols used by the Registry

6. Performance Specifications

These Performance Specifications provide a means to measure Registry Operator's delivery of SRS, DNS Name Server and Whois services for the Registry TLD and serve as the basis for the Service Level Agreements Credits ("SLA Credits") set forth in Appendix 10.

6.1 Definitions. Capitalized terms used in this Section 6 and not otherwise defined shall have the meaning ascribed to them in the Registry Agreement.

6.1.1 "Core Internet Service Failure" means an extraordinary and identifiable event beyond the control of Registry Operator affecting the Internet services to be measured pursuant to this Section 6. Such events include, but are not limited to congestion collapse, partitioning, power grid failures, and routing failures.

6.1.2 "Credit Level" means the credit levels set forth in the Table SLA Credits in Section 2 of Appendix 10 that outlines the total credits, penalties and/or liabilities that may be assessed to Registry Operator and sole remedies available to ICANN-Accredited Registrars for Registry Operators failure to meet Performance Specifications outlined in this Appendix 7.

6.1.3 "DNS Name Server" means the service complying with RFC 1034, 1035 and related RFCs made available on TCP/UDP port 53 on Registry Operator's selected servers.

6.1.4 "ICANN-Accredited Registrar" means an ICANN-Accredited Registrar that has a Registry-Registrar Agreement in effect with Registry Operator.

6.1.5 "Monthly Timeframe" means each single calendar month beginning and ending at 0000 Coordinated Universal Time (UTC).

6.1.6 "Performance Specifications" means a description of the measurable functional attributes of a particular System Services.

6.1.7 "Registrar Community" means all of the ICANN-Accredited Registrars who have Registry-Registrar Agreements in effect with Registry Operator for the Registry TLD and who have registered greater than 150 net new .com domain names in the prior thirty (30) calendar day period.

6.1.8 "Round-trip" means the amount of measured time that it takes for a reference query to make a complete trip from the SRS gateway, through the SRS system, back to the SRS gateway.

6.1.9 "Service Level Agreement (SLA)" means the service level agreements attached as Appendix 10 to the Registry Agreement outlining performance standards levels.

6.1.10 "SRS" means the Shared Registration System, a system that the Registry Operator provides to the Registrar Community via a defined protocol (EPP) for registry-registrar interaction. Specifically, it refers to the ability of ICANN-Accredited Registrars to add, modify, and delete (create, update and delete) information associated with registered domain names and associated DNS Name Servers.

6.1.11 "System Services" means the SRS, DNS Name Server and Whois services for the Registry TLD for which availability and Performance Specifications are established.

6.1.12 "Whois" refers to the Registry Operator's Whois service provided in accordance with Appendix 5A.

6.2 Service Availability. Service availability is defined as the time, in minutes, that the Registry Operator's System Services are each individually responding to its users ("Service Availability") as further defined in Sections 6.2.1 through 6.2.4.

6.2.1 Service Availability is measured as follows:

Service Availability % = {[(MTM - POMU) - UOM] / (MTM - POMU)}*100 where:

MTM = Monthly Timeframe Minutes calculated as the number days in that month times 24 hours times 60 minutes. For example, the MTM for January is 31 days * 24 hours * 60 minutes or MTM = 44,640 minutes.

POMU = Planned Outage Minutes Used equals the number of minutes of a Planned Outage (as defined in Section 6.3 below) or Extended Planned Outage (as defined in Section 6.4 below) for that Monthly Timeframe for each individual System Service. No Monthly Timeframe shall have both a Planned and an Extended Planned Outage.

UOM = Unplanned Outage Minutes equals the total number of minutes the System Services is unavailable excluding any Planned Outages (as defined in Section 6.3 below) or Extended Planned Outage (as defined in Section 6.4 below) for that Monthly Timeframe.

The Service Availability calculation shall be calculated by the Registry Operator and the results reported for each Monthly Timeframe for SRS, Whois and DNS Name Server availability. For Service Availability Performance Specifications measured by calendar year, Yearly Timeframe Minutes (YTM) shall be substituted for Monthly Timeframe Minutes (MTM) in the calculation above. Yearly Timeframe Minutes calculated as 365 days * 24 hours * 60 minutes = 525,600 minutes. Results will be reported to the Registrar Community via e-mail and to ICANN according to Appendix 4.

6.2.2 Service Availability--SRS = 99.99% per calendar year. Service Availability as it applies to the SRS refers to the ability of the SRS to respond to ICANN-Accredited Registrars that access the SRS through the EPP protocol. SRS unavailability, except for Planned Outages (as defined in

Section 6.3 below) and Extended Planned Outages (as defined in Section 6.4 below), will be logged with the Registry Operator as Unplanned Outage Minutes. Unavailability will not include any events affecting individual ICANN-Accredited Registrars locally.

SRS unavailability as it applies to the SRS shall mean when, as a result of a failure of systems within the Registry's control, an ICANN-Accredited Registrar is unable to establish a session with the SRS gateway; provided, however, that SRS unavailability shall not include an ICANN-Accredited Registrar's inability to establish a session with the SRS gateway that results from it exceeding its designated number of sessions. Establishing a session with the SRS gateway shall be defined as:

a) successfully complete a TCP session start,

b) successfully complete the SSL or TLS authentication handshake, and

c) successfully complete the Extensible Provisioning Protocol (EPP) login command.

Registry Operator will log SRS unavailability once an ICANN-Accredited Registrar reports an occurrence to Registry Operator's customer service help desk in the manner required by the Registry Operator (i.e., e-mail, fax, telephone). The committed Service Availability for SRS is 99.99% per calendar year. The SRS Service Availability metric is a Credit Level 2.

6.2.3 Service Availability--DNS Name Server = 100% per Monthly Timeframe. Service Availability as it applies to the DNS Name Server refers to the ability of the DNS Name Server to resolve a DNS query from an Internet user. DNS Name Server unavailability will be logged with the Registry Operator as Unplanned Outage Minutes. Registry Operator will log DNS Name Server unavailability (a) when such unavailability is detected by monitoring tools, or (b) once an ICANN-Accredited Registrar reports an occurrence to Registry Operator's customer service help desk in the manner required by the Registry Operator (i.e., e-mail, fax, telephone) and Registry Operator confirms that the occurrence is not unique to the reporting Registrar.

DNS Name Server unavailability shall mean less than eight (8) sites on the Registry Operator's constellation are returning answers to queries with less than 1% packet loss averaged over a Monthly Timeframe or 5% packet loss for any five minute period.

The committed Service Availability for DNS Name Server is 100% per Monthly Timeframe. The DNS Name Server Service Availability metric is a Credit Level 1.

6.2.4 Service Availability--Whois = 100% per Monthly Timeframe. Service Availability as it applies to Whois refers to the ability of Internet users to access and use the Whois. Whois unavailability, except for Planned Outages (as defined in Section 6.3 below) and Extended Planned Outages (as defined in Section 6.4 below), will be logged with the Registry Operator as Unplanned Outage Minutes. Registry Operator will log Whois unavailability (a) when such unavailability is detected by Registry Operator's monitoring tools, or (b) once an ICANN-Accredited Registrar reports an occurrence to Registry Operator's customer service help desk in the manner required by the Registry Operator (i.e., e-mail, fax, telephone). The committed Service Availability for Whois is 100% per Monthly Timeframe. The Whois Service Availability metric is a Credit Level 2.

6.3 Planned Outage. From time to time the Registry Operator will require an outage for regular maintenance or the addition of new functions or features ("Planned Outage").

6.3.1 Planned Outage Duration. Planned Outage duration defines the maximum allowable time, in minutes, that the Registry Operator is permitted to take the System Services out of service for regularly scheduled maintenance ("Planned Outage Duration"). Planned Outages are planned in advance and the Registrar Community is provided notification prior to an outage.

The Planned Outage Duration for the System Services is as follows:

(i) Planned Outage Duration - SRS = 45 minutes per Monthly Timeframe;

(ii) Planned Outage Duration - DNS Name Server = no Planned Outages allowed; and

(iii) Planned Outage Duration - Whois = no Planned Outages allowed.

The Planned Outage Duration metric is a Credit Level 6.

6.3.2 Planned Outage Timeframe. The Planned Outage Timeframe defines the hours and days in which a Planned Outage may occur ("Planned Outage Timeframe"). The Planned Outage Timeframe for the System Services is as follows:

(i) Planned Outage Timeframe - SRS = 0100-0900 UTC Sunday;

(ii) Planned Outage Timeframe - DNS Name Server = no Planned Outages allowed; and

(iii) Planned Outage Timeframe - Whois = no Planned Outages allowed.

The Planned Outage Timeframe metric is a Credit Level 5.

6.3.3 Planned Outage Notification. The Registry Operator shall notify all ICANN-Accredited Registrars of any Planned Outage ("Planned Outage Notification"). The Planned Outage Notification shall set forth the date and time of the Planned Outage. The number of days prior to a Planned Outage that the Registry Operator shall notify the Registrar Community is as follows:

(i) Planned Outage Timeframe - SRS = 30 days for general maintenance and 90 days for Updates or Upgrades as defined in the Patch, Update and Upgrade Policy in Section 5 of this Appendix 7;

(ii) Planned Outage Timeframe - DNS Name Server = no Planned Outages allowed; and

(iii) Planned Outage Timeframe - Whois = no Planned Outages allowed.

The Planned Outage Notification metric is a Credit Level 5.

6.4 Extended Planned Outage. In some cases, such as major software upgrades and platform replacements, an extended maintenance timeframe is required ("Extended Planned Outage"). Extended Planned Outages will be less frequent than Planned Outages but their duration may be longer.

6.4.1 Extended Planned Outage Duration. The Extended Planned Outage duration defines the maximum allowable time, in hours and minutes that the Registry Operator is permitted to take the System Services out of service for extended maintenance ("Extended Planned Outage Duration"). Extended Planned Outages are planned in advance and the Registrar Community is provided notification in accordance with Section 6.4.3. Extended Planned Outage periods may not occur in the same Monthly Timeframe as a Planned Outage. The Extended Planned Outage Duration for the System Services is as follows:

(i) Extended Planned Outage Duration - SRS = 4 hours (240 minutes) per calendar year and one Extend Planned Outage of 8 hours (480) minutes every 3 years;

(ii) Extended Planned Outage Duration - DNS Name Server = no Extended Planned Outages allowed; and

(iii) Extended Planned Outage Duration - Whois = no Extended Planned Outages allowed.

The Extended Planned Outage Duration metric is a Credit Level 6.

6.4.2 Extended Planned Outage Timeframe. The Extended Planned Outage Timeframe defines the hours and days in which the Extended Planned Outage may occur ("Extended Planned Outage Timeframe"). The Extended Planned Outage Timeframe for the System Services is as follows:

(i) Extended Planned Outage Timeframe - SRS = 0100 - 1300 UTC Sunday;

(ii) Extended Planned Outage Timeframe - DNS Name Server = no Extended Planned Outages allowed; and

(iii) Extended Planned Outage Timeframe - Whois = no Extended Planned Outages allowed.

The Extended Planned Outage Timeframe metric is a Credit Level 5.

6.4.3 Extended Planned Outage Notification. The Registry Operator must notify the Registrar Community of any Extended Planned Outage ("Extended Planned Outage Notification"). The Extended Planned Outage Notification shall set forth the date and time of the Extended Planned Outage. The number of days prior to an Extended Planned Outage that the Registry Operator must notify ICANN-Accredited Registrars is as follows:

(i) Extended Planned Outage Timeframe - SRS = 90 Days;

(ii) Extended Planned Outage Timeframe - DNS Name Server = no Extended Planned Outages allowed; and

(iii) Extended Planned Outage Timeframe - Whois = no Extended Planned Outages allowed.

The Extended Planned Outage Notification metric is a Credit Level 5.

6.5 Processing Time. Processing time is a measurement of Service Availability and equals the Round-trip for the System Services ("Processing Time"). The Registry Operator will log the Processing Time for all of the protocol transactions (i.e. Check, Add/Create, Modify/Update and Delete). Processing Time will be measured in a Monthly Timeframe and reported on a monthly basis to ICANN in accordance with Appendix 4. Should the total volume of protocol transactions (measured individually) added by all ICANN-Accredited Registrars for a Monthly Timeframe exceed Registry Operator's actual volume of protocol transactions for the previous Monthly Timeframe by more than 20%, then ICANN-Accredited Registrars shall not be eligible for any SLA credit, and Registry Operator shall have no liability to ICANN, if Registry Operator fails to meet a Processing Time Performance Specification set forth in this Section 6.5.

6.5.1 Processing Time--Check Domain = 25 milliseconds for 95%.

(i) The Processing Time for Check Domain is applicable to the SRS as accessed through the defined protocol (EPP) for registry-registrar interaction and measures the Processing Time for an availability check of a specific domain name.

(ii) The performance specification for Check Domain is 25 milliseconds Round-trip for 95% of the transactions during a Monthly Timeframe.

The Processing Time for Check Domain metric is a Credit Level 3.

6.5.2 Processing Time--Add/Create = 50 milliseconds for 95%.

(i) The Processing Time for Add/Create is applicable to the SRS as accessed through the defined protocol (EPP) for registry-registrar interaction and measures the Processing Time for add/create transactions associated with domain names.

(ii) The Performance Specification for Add/Create is 50 milliseconds for Round-trip for 95% of the transactions processed during a Monthly Timeframe.

The Processing Time for Add/Create metric is a Credit Level 3.

6.5.3 Processing Time--Modify/Update and Delete Domain = 100 milliseconds for 95%.

(i) The Processing Time for Modify/Update and Delete is applicable to the SRS as accessed through the defined protocol (EPP) for registry-registrar interaction and measures the Processing Time for Modify/Update and Delete transactions associated with domain names.

(ii) The Performance Specification for Modify/Update and Delete is 100 milliseconds Round-trip for 95% of the transactions processed during a Monthly Timeframe.

The Processing Time for Modify/Update and Delete metric is a Credit Level 3.

6.5.4 Processing Time--Whois Query = 5 milliseconds for 95%.

(i) The Processing Time for Whois query is applicable to the Whois and measures the Processing Time for a Whois query.

(ii) The Performance Specification for a Whois query is 5 milliseconds for 95% of the transactions during a Monthly Timeframes. That is, 95% of the transactions during a Monthly Timeframe will take 5 milliseconds or less from the time the Whois receives a query to the time it responds.

The Processing Time for Whois Query metric is a Credit Level 3.

6.5.5 Processing Time--DNS Name Server Resolution = 100 milliseconds for 95%.

(i) The Processing Time for DNS Name Server Resolution is applicable to the DNS Name Server and measures the processing time for a DNS query.

(ii) The Performance Specification for DNS Name Server Resolution is 100 milliseconds for 95% of the transactions during a Monthly Timeframe. That is, 95% of the transactions during a Monthly Timeframe will take 100 milliseconds or less from the time the name server receives the DNS query to the time it provides a response.

The Processing Time for the DNS Name Server metric is a Credit Level 3.

6.6 Update Frequency. The Registry Operator makes timely updates to the data on the DNS Name Servers and Whois. ICANN-Accredited Registrars record these updates through the SRS. The SRS then updates the DNS Name Server and the Whois. Registry Operator processes these updates on a near real time basis.

The committed performance specification with regards to Update frequency for both the DNS Name Server and the Whois is 3 minutes for 95% of the transactions during a Monthly Timeframe. That is, 95% of the updates to the DNS Name Servers and Whois during a Monthly Timeframe will be completed within 3 minutes. Update frequency is measured from the time that the Registry Operator confirms the update to the time the update appears in the DNS Name Server and Whois.

Update frequency performance will be reported on a monthly basis to ICANN in accordance with Appendix 4.

6.6.1 Update Frequency--DNS Name Server = 3 minutes for 95% during a Monthly Timeframe.

The Update frequency--DNS Name Server is 3 minutes for 95% during a Monthly Timeframe.

The Update frequency metric for DNS Name Server is Credit Level 4.

6.6.2 Update Frequency--Whois - 3 minutes for 95% during a Monthly Timeframe.

The Update frequency--Whois is 3 minutes for 95% during a Monthly Timeframe.

The Update frequency metric for Whois is Credit Level 4.

6.7 Cross-Network Name Server Performance Requirements. DNS Name Server Round-trip and packet loss from the Internet are important elements of the quality of service provided by the Registry Operator. These characteristics, however, are affected by Internet performance and, therefore, cannot be closely controlled by Registry Operator. Accordingly, these requirements are not matters subject to SLA Credits under the Service Level Agreement set forth on Appendix 10 or obligations upon which a breach by Registry Operator of the Registry Agreement may be asserted.

The committed performance specification for cross-network name server performance is a measured Round-trip of under 300 milliseconds and measured packet loss of under 1% averaged over the course of a Monthly Timeframe and no greater than 5% for any five (5) minute period over the course of the Monthly Timeframe. Cross-network name server performance measurements may be conducted by ICANN at the times of its choosing, in the following manner:

6.7.1 The measurements may be conducted by sending strings of DNS request packets from different measuring locations to each of the .com DNS Name Servers and observing the responses from the .com DNS Name Servers. (These strings of requests and responses are referred to as a "CNNP Test".) The measuring locations will be distributed around the Internet.

6.7.2 Each string of request packets will consist of UDP or TCP packets requesting nameserver (NS) records for arbitrarily selected .com second-level domains, preselected to ensure that the names exist in the Registry TLD and are resolvable. The packet loss (i.e. the percentage of response packets not received) and the average Round-trip time for response packets received may be noted.

6.7.3 To meet the packet loss and Round-trip requirements for a particular CNNP Test, all three of the following must be true:

6.7.3.1 The Round-trip and packet loss from each measurement location to at least one .com name server must not exceed the required values;

6.7.3.2 The packet loss to each of the .com name servers from at least one of the measurement locations must not exceed the required value; and

6.7.3.3 Any failing CNNP Test result obtained during an identified Core Internet Service Failure shall not be considered.

6.7.4 To ensure a properly diverse testing sample, ICANN will conduct the CNNP Tests at varying times (i.e. at different times of the day, as well as on different days of the week). Registry Operator may only be deemed to have persistently failed to meet the cross-network name server performance requirement only if the .com DNS Name Servers fail the CNNP Tests (see Section 6.7.3 above) with no less than three consecutive failed CNNP Tests.

6.7.5 In the event of persistent failure of the CNNP Tests, ICANN will give Registry Operator written notice of the failures (with backup data) and Registry Operator will have sixty days to cure the failure.

6.7.6 Sixty days prior to the commencement of testing under this provision, ICANN will provide Registry Operator with the opportunity to evaluate the testing tools, measuring locations and procedures to be used by ICANN. In the event that Registry Operator does not approve of such tools and procedures, ICANN will work directly with Registry Operator to make necessary modifications.

7. Responsibilities of the Parties.

7.1 Except in the case of DNS Name Server performance measurements, Registry Operator will perform monitoring from internally located systems as a means to verify that the availability and performance measurements in this document are being met.

7.2 The Registry Operator will provide system performance and availability reports monthly to the Registrar Community via e-mail and to ICANN according to Appendix 4.

7.3 The Registry Operator will provide the Whois Service as specified in Appendix 5A.

7.4 The Registry Operator will use commercially reasonable efforts to restore the critical systems of the System Services within 24 hours after the termination of a force majeure event and restore full system functionality within 48 hours after the termination of a force majeure event. Outages due to a force majeure will not be considered service unavailability for purposes of this Appendix 7 or the SLA.

7.5 Registry Operator shall not be liable to ICANN or ICANN-Accredited Registrars for any credits or penalties or be deemed to be in breach of any of its obligations under the Registry Agreement if it fails to meet a Performance Specification as a result of its compliance with any Consensus Policy established after the Effective Date to the extent and for so long as the failure to meet a Performance Specification is unavoidable by commercially reasonable efforts due to Registry Operator's compliance with such Consensus Policy.

7.6 Registry Operator shall provide to ICANN and publish on its website its accurate contact details including a valid email address or webform and mailing address as well as a primary contact for handling reports related to malicious conduct in the TLD, including DNS Abuse, as defined in Appendix 11, Section (c) (Public Interest Commitments), and will provide ICANN with prompt notice of any changes to such contact details. Upon receipt of such reports, Registry Operator shall provide the reporter with confirmation that it has received the report.

8. Additional Services

8.1 Bulk Transfer After Partial Portfolio Acquisition (BTAPPA)

Bulk Transfer After Partial Portfolio Acquisition (BTAPPA) is a Registry service available to consenting Registrars in the circumstance where one ICANN-Accredited Registrar purchases, by

means of a stock or asset purchase, merger or similar transaction, a portion but not all, of another ICANN-Accredited Registrar's domain name portfolio in the .com top-level domain.

At least fifteen days before completing a BTAPPA, the losing Registrar must provide to all domain name registrants for names involved in the bulk transfer, written notice of the bulk change of sponsorship. The notice must include an explanation of how the Whois record will change after the bulk transfer occurs, and customer support and technical contact information of the gaining Registrar.

If a domain is transferred under the BTAPPA service during any applicable Grace Period as described in Section 3 above, there is no credit. The expiration dates of transferred registrations are not affected.

Domain names in the following statuses at the time of the Transfer Request will not be transferred in a BTAPPA: "pending transfer", "redemption grace period (RGP)", or "pending delete". Domain names that are within the auto-renew grace window are subject to bulk transfer, but Verisign may decline to provide a credit for those names deleted after the bulk transfer, but prior to the expiration of the auto-renew grace window.

Verisign has discretion to reject a BTAPPA request if there is reasonable evidence that a transfer under BTAPPA is being requested in order to avoid fees otherwise due to Verisign or ICANN, or if a Registrar with common ownership or management or both has already requested BTAPPA service within the preceding six-month period.

8.2 Registration of one .com Domain Name with a Single-Character Label. Registry Operator may allocate the single-character label ▇.▇▇▇ in accordance with the ▇.▇▇▇ Service Description attached as Schedule 1 to this Appendix 7 and the following specific conditions (the “▇.▇▇▇ Service”):

(i)Registry Operator shall not, directly or indirectly, receive any proceeds from the sale, allocation, transfer or renewal of ▇.▇▇▇ and will only receive the standard registry fee for the registration of ▇.▇▇▇, in accordance with the Maximum Price set forth in Section 7.3(d) of the Agreement.

(ii)Notwithstanding Appendix 7, Section 3.1.1 (Add Grace Period) of the Agreement, ▇.▇▇▇ shall not have an Add Grace Period.

(iii)Notwithstanding Appendix 7, Section 3.1.2 (Renew/Extend Grace Period) of the Agreement, ▇.▇▇▇ will not have a Renewal Grace Period up to and including the twenty-fifth year the winning registrant renews ▇.▇▇▇ (if applicable). Beginning on the twenty-sixth year the winning registrant renews ▇.▇▇▇ and thereafter (if applicable) a Renewal Grace Period will apply to ▇.▇▇▇.

(iv)Notwithstanding Appendix 7, Section 3.1.3 (Auto-Renew Grace Period) of the Agreement, ▇.▇▇▇ will be automatically renewed under the Auto-Renew Grace Period, each for a single year period.

(v)Notwithstanding Appendix 7, Section 3.3.2 (Pending Delete Period) of the Agreement, ▇.▇▇▇ shall not be included on the .com registry’s Pending Delete Report if deleted, and will be held by Registry Operator until Registry Operator makes ▇.▇▇▇ available via a later auction or other allocation process.

9. Implementation of New Protocols

Registry Operator and ICANN agree to engage in good faith negotiations at regular intervals (at least once every eighteen months following the Effective Date) regarding possible implementation of new RFCs related to the matters addressed in Appendices 1 (Data Escrow Specification), 5A (Registration Data Publication Services Specification), 5B (Registration Data Access Protocol Service Specification) and 7 (Functional and Performance Specifications).

Schedule 1 to Appendix 7

▇.▇▇▇ Service Description

▇.▇▇▇ Service

Registry Operator will register ▇.▇▇▇ (the “SCDN”) in the manner in which it registers other domain names, with the exceptions set forth below. In addition, the SCDN will be allocated through an auction managed by a third party auction service provider selected by Registry Operator. The registration of the SCDN will be allocated through a pro-competitive and fair auction process and any potential registrant may participate in the auction process and select any ICANN-accredited registrar for the management of the SCDN if awarded to their registrant. No restrictions will be placed on how the registrant may select the .com ICANN-accredited registrar. Prior to the auction, Registry Operator will provide registrars with a minimum advanced notice of 60 days as part of its efforts to notify potential registrants.

Nonprofit Beneficiary

Consistent with its sole role as service provider and with its lack of any ownership in the SCDN, Registry Operator will not be paid, nor receive, nor touch any part of the SCDN auction proceeds. Instead, Registry Operator will only receive the standard registry fee for the registration of the SCDN, which fee shall be in compliance with registry fee pricing provisions under Section 7.3(d) of the Agreement for the registration of any other .com domain name at the time.

Proceeds derived from the auction of the SCDN will be provided to one or more nonprofit organizations, or its successors, as set forth in Exhibit A attached hereto and agreed by ICANN and Registry Operator to be “CONFIDENTIAL” pursuant to Section 3.1(d)(iv)(B) of the Agreement (“Nonprofit List”). None of the auction proceeds will directly or indirectly be used to benefit Registry Operator, its affiliates, or its directors, officers, or employees, other than to the de minimis extent those proceeds are used by the nonprofit(s) to benefit the Internet community in general. The nonprofit's, including its successor's, mission will align the use of funds resulting from the auction of the SCDN toward areas of public good of the Internet community, which may include one or more of the following:

odevelopment, evolution, and use of open Internet protocols

oenhancing the cybersecurity readiness and response of public and private sector entities

oonline safety for children

oimproving security, stability and universal accessibility of the Internet

ocapacity building for the benefit of the Internet community (such as assisting those in developing areas in applying to become registries and registrars)

None of the nonprofit organizations, including their respective successors, as set forth in the Nonprofit List, have or will make any contributions, or conduct any activities directed by, or on behalf of, Registry Operator.

Disbursement of Proceeds to the Nonprofit Beneficiary

The winning registrant will submit the auction proceeds to an independent tax-exempt trust that will be set up by the third party auction service provider (the "Trust"). An independent third party trustee (the "Third Party Trustee") will (i) select the nonprofit organization(s) to receive the auction proceeds as outlined above and (ii) manage the receipt and distribution of the auction proceeds to the nonprofit(s). Registry Operator and its affiliates, directors, officers, or employees, will not be (i) acting as a trustee of the Trust, (ii) named in the Trust, or (iii) named as a party to the Trust. The Third Party Trustee will not conduct any activities directed by, or on behalf of, Registry Operator except as set forth herein.

Provisioning

Under the ▇.▇▇▇ Service, Registry Operator intends for the SCDN to be allocated via an auction. Receipt of payment in the amount of the winning bid will entitle the registrant to obtain an initial five (5) year registration. The auction will be managed by a third party auction service provider selected by Registry Operator. The SCDN will be allocated through an auction administered by the third party auction service provider as described below.

The third party auction service provider will be required to pre-qualify potential registrants for participation in the auction, which may include asking potential registrants to submit documentation to the third party auction service provider describing the planned marketing and usage of the registered domain name, demonstrating the ability to pay, and additional requirements as may be required by the third party auction service provider. A team formed by the third party auction service provider will review and approve the proposals based upon pre-determined qualifications.

The winning registrant must: (i) submit the entire amount of the winning bid directly to the Trust within fourteen (14) calendar days from the date on which it was determined to be the winner (the "First Installment of the Winning Bid"); and (ii) commit to submitting to the Trust five percent (5%) of the First Installment of the Winning Bid for each year that the SCDN is renewed after expiration of the initial five (5) year registration period (each a "Subsequent Installment") up until, and including, the twenty-fifth (25th) year the winning registrant renews the SCDN (the "Expiration of the Subsequent Installment"). The Subsequent Installments are intended to encourage a continuous funding stream to the nonprofit organization(s) up until the Expiration of the Subsequent Installment. By way of example, if the auction took place in 2020 and the winning bid was $10,000, the First Installment of the Winning Bid for the SCDN would be $10,000 and be paid in 2020, and the Subsequent Installment for each year after the five (5) year initial term would be $500 and be paid in 2026 through 2045 (i.e., 5% of the First Installment of the Winning Bid).

In the event a winning registrant fails to complete the payment transaction within the fourteen (14) day time period, the: (i) registrant will forfeit its right to register the SCDN, and (ii) SCDN may be made available to the second highest bidder. This process will continue until a full payment is received.

Upon completion of the First Installment of the Winning Bid payment, the third party auction service provider will issue an authorization code to the winning registrant. The winning registrant

will provide this authorization code to its registrar of choice. This registrar-of-record for the winning registrant must provide the authorization code to Registry Operator to complete the initial registration. The initial term will expire five (5) years from the date of creation. Registry Operator will charge the registrar the then-applicable registration fee for each annual increment of a new domain name registration (multiplied by five (5) increments for a five year term) for the SCDN, which may be paid using its account associated with the current Verisign System or its Payment Security (as defined in the .com Registry-Registrar Agreement).

Because Registry Operator is not processing the payment of any auction proceeds, the registrar-of-record for the winning registrant will not be permitted to use the account associated with the current Verisign System or its Payment Security to secure payment of the winning bid, either in whole or in part.

After registration, the registrar-of-record will be able to execute any updates for the SCDN requested by its registrant in the same manner in which all updates are currently executed.

Should Registry Operator determine that the winning registrant is not complying with the terms of the auction agreement executed by the winning registrant to participate in the auction (the "Auction Agreement"), including failing to provide to the nonprofit(s) any Subsequent Installments when due, Registry Operator will have the right to terminate the registration and the SCDN will enter the standard Redemption Grace Period. The registrar-of-record will be able to restore the SCDN only if the issue is successfully cured during the Redemption Grace Period. Following the 5-day Pending Delete period, the SCDN will be held by the registry for re-auction or other allocation process at a future date and time.

Following the initial registration, the specifications of Appendix 7 to the Agreement will apply for all EPP operations except as otherwise set forth herein or in Appendix 7, Section 8.2.

The winning registrant may renew the SCDN for as many years as the Agreement will permit, provided the winning registrant submits the Subsequent Installment(s) of the Winning Bid to the Trust up until the Expiration of the Subsequent Installment and standard registration fees to the registry. Prior to the Expiration of the Subsequent Installment, in order to renew the SCDN, the winning registrant must submit the Subsequent Installment of the Winning Bid to the Trust, and following Registry Operator's receipt of notification from the Third Party Trustee confirming payment, the registrar-of-record for the SCDN may submit the renewal request to Registry Operator and will be charged the then-applicable fee for each annual increment of a new domain name registration. After the Expiration of the Subsequent Installment, in order to renew the SCDN, the registrar-of-record for the SCDN will submit the renewal request to Registry Operator and will be charged the then-applicable fee for each annual increment of a new domain name registration.

Prior to the Expiration of the Subsequent Installment, payment of the Subsequent Installment of the Winning Bid and the then-applicable registration fee will also apply to transfers of the SCDN, as applicable, because an additional year will be added to the term of the SCDN, subject to the 10-year maximum, as part of the transfer process in accordance with standard domain name lifecycle.

If the SCDN is not explicitly renewed prior to the expiration date, it will be automatically renewed for a single year in the same manner as non-single-character domain names. Prior to the Expiration of the Subsequent Installment, the winning registrant must complete the payment of the Subsequent Installment of the Winning Bid and the registrar of record must complete the payment of the then-applicable registration fee within fourteen (14) days of the auto-renewal, or the registry reserves the right to explicitly delete the registration and make the SCDN available through a subsequent auction or other allocation method. If the SCDN is not renewed, then the winning registrant will be released from its commitment to pay a future Subsequent Installment of the Winning Bid.

If a deletion by the registrar of record occurs for the SCDN, the SCDN will enter the standard 30-day Redemption Grace Period. If the SCDN is not restored during this period, the SCDN will enter a 5-day Pending Delete Period and the SCDN will not be available for re-registration and may be re-auctioned or placed through another allocation method.

Fees

The First Installment of the Winning Bid will be paid by the winning registrant to the Trust and will be allocated by the Third Party Trustee as follows:

oAn amount agreed upon in advance will be paid to (i) the third party auction service provider for auction administration services and (ii) the Third Party Trustee for services relating to the management and distribution of the funds in the Trust;

oAn amount, not more than $1,000,000, will be held by the Trust as a reserve for expenses the Third Party Trustee may incur to enforce (a) the Auction Agreement and (b) requirements the selected nonprofit organization(s) must meet in order to receive the funds, such as using the funds toward areas of public good of the Internet community; and

oThe remaining amount of the First Installment of the Winning Bid will be distributed to the selected nonprofit organization(s), as discussed above.

Each Subsequent Installment of the Winning Bid will be paid by the winning registrant to the Trust and will be allocated by the Third Party Trustee as follows:

oAn amount agreed upon in advance will be paid to the Third Party Trustee for services relating to the management and distribution of the funds in the Trust; and

oThe remaining amount of the Subsequent Installment(s) of the Winning Bid will be distributed to the nonprofit organization(s) discussed above. The Third Party Trustee will notify Registry Operator upon receipt of payment.

Exhibit A to Schedule I of Appendix 7 - CONFIDENTIAL

To Schedule 1 to Appendix 7 (▇.▇▇▇ Service Description)

Security and Stability Research

•Center for Internet Security - ▇▇▇▇▇://▇▇▇.▇▇▇▇▇▇▇▇▇▇.▇▇▇/

•DNS-OARC

•National Cyber-Forensics and Training Alliance (NCFTA)

•National Cyber Security Alliance (NCSA)

Internet Governance, Development and Capacity Building

•Internet Society (ISOC)

•The Endowment for the Sustainability of the IETF - ▇▇▇▇://▇▇▇.▇▇▇▇▇▇▇▇▇▇▇.▇▇▇

Online Safety

•▇▇▇▇▇▇▇▇.▇▇▇ - ▇▇▇▇://▇▇▇.▇▇▇▇▇▇▇▇.▇▇▇/▇▇▇▇-▇▇▇▇▇-▇▇▇-▇▇▇▇▇▇-▇▇▇▇▇▇/

•Child Rescue Network - ▇▇▇▇://▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇.▇▇▇/

•iKeepSafe - ▇▇▇▇://▇▇▇▇▇▇▇▇▇.▇▇▇/

•ConnectSafely - ▇▇▇▇://▇▇▇.▇▇▇▇▇▇▇▇▇▇▇▇▇.▇▇▇/

•Kids in Danger - ▇▇▇▇://▇▇▇.▇▇▇▇▇▇▇▇▇▇▇▇.▇▇▇/

•SAFECode - ▇▇▇▇://▇▇▇.▇▇▇▇▇▇▇▇.▇▇▇/

•Savvy Cyber Kids - ▇▇▇▇://▇▇▇.▇▇▇▇▇▇▇▇▇▇▇▇▇▇.▇▇▇/

.com Registry Agreement Appendix 8

.com Registry-Registrar Agreement

This Registry-Registrar Agreement (the "Agreement") is entered into by and between VeriSign, Inc., a Delaware corporation, with a place of business located at ▇▇▇▇▇ ▇▇▇▇▇▇▇▇ ▇▇▇, ▇▇▇▇▇▇, ▇▇ ▇▇▇▇▇, and its wholly owned subsidiaries, including VeriSign Sarl and VeriSign Naming and Directory Services LLC ("VNDS LLC") (collectively, "Verisign"), and , a

, with its principal place of business located at ("Registrar"), through their authorized representatives, and takes effect on the date executed by the final Party (the "Effective Date"). Verisign and Registrar may be referred to individually as a "Party" and collectively as the "Parties."

WHEREAS, multiple registrars provide Internet domain name registration services within the

.COM top-level domain wherein Verisign operates and maintains certain TLD servers and zone files;

WHEREAS, Registrar wishes to register second-level domain names in the multiple registrar system for the .COM TLD.

NOW, THEREFORE, for and in consideration of the mutual promises, benefits and covenants contained herein and for other good and valuable consideration, the receipt, adequacy and sufficiency of which are hereby acknowledged, Verisign and Registrar, intending to be legally bound, hereby agree as follows:

1.DEFINITIONS

1.1."Confidential Information" means all information and materials including, without limitation, computer software, data, information, databases, protocols, reference implementation and documentation, and functional and interface specifications, provided by the disclosing party to the receiving party and marked or otherwise identified as Confidential, provided that if a communication is oral, the Disclosing Party will notify the Receiving Party in writing within 15 days of the disclosure.

1.2."DNS" refers to the Internet domain name system.

1.3."EPP" means the Extensible Provisioning Protocol.

1.4."ICANN" refers to the Internet Corporation for Assigned Names and Numbers.

1.5."IP" means Internet Protocol.

1.6.The "Licensed Product" refers to the intellectual property required to access the Supported Protocol, and to the APIs, and software, collectively.

1.7."Personal Data" refers to data about any identified or identifiable natural person.

1.8."Registered Name" refers to a domain name within the domain of the Registry TLD, whether consisting of two or more (e.g., ▇▇▇▇.▇▇▇▇▇.▇▇▇▇) levels, about which Verisign or an affiliate engaged in providing registry services maintains data in a registry database, arranges for such maintenance, or derives revenue from such maintenance. A name in a registry database may be a Registered Name even though it does not appear in a TLD zone file (e.g., a registered but inactive name).

1.9.“Registered Name Holder(s)” means the holder(s) of a Registered Name.

1.10.“Registrar Accreditation Agreement” means that certain Registrar Accreditation Agreement between Registrar and ICANN pursuant to which ICANN has accredited Registrar to act as a registrar for one or more TLDs.

1.11."Registry TLD" means the .COM TLD.

1.12."Supported Protocol" means Verisign's implementation of EPP, or any successor protocols, supported by the System.

1.13.The "System" refers to the shared registration system operated by Verisign for registration of Registered Names in the Registry TLD.

1.14.A "TLD" is a top-level domain of the DNS.

2.OBLIGATIONS OF THE PARTIES

2.1.System Operation and Access. Throughout the term of this Agreement, Verisign shall operate the System and provide Registrar with access to the System to transmit domain name registration information for the Registry TLD to the System. Nothing in this Agreement entitles Registrar to enforce any agreement between Verisign and ICANN.

2.2.Maintenance of Registrations Sponsored by Registrar. Subject to the provisions of this Agreement, ICANN requirements, and Verisign requirements, including, without limitation, those authorized by ICANN, Verisign shall maintain the registrations of Registered Names sponsored by Registrar in the System during the term for which Registrar has paid the fees required by Subsection 5.1.

2.3.Distribution of EPP, APIs and Software. No later than three (3) business days after the Effective Date of this Agreement, Verisign shall make available to Registrar (i) full documentation of the Supported Protocol, (ii) "C" and/or "Java" application program interfaces ("APIs") to the Supported Protocol with documentation, and (iii) reference client software ("Software") that will allow Registrar to develop its system to register second-level domain names through the System for the Registry TLD. If Verisign elects to modify or upgrade the APIs and/or Supported Protocol, Verisign shall provide updated

APIs to the Supported Protocol with documentation and updated Software to Registrar promptly as such updates become available.

2.4.Registrar Responsibility for Customer Support. Registrar shall provide

(i) support to accept orders for registration, cancellation, modification, renewal, deletion or transfer of Registered Names and (ii) customer service (including domain name record support) and billing and technical support to Registered Name Holders. Registrar shall, consistent with ICANN policy, provide to Registered Name Holders emergency contact or 24/7 support information for critical situations such as domain name hijacking.

2.5.Data Submission Requirements. As part of its registration and sponsorship of Registered Names in the Registry TLD, Registrar shall submit complete data as required or permitted: (a) by Verisign’s Registry Agreement with ICANN, as may be amended from time to time; and/or (b) by technical specifications of the System that are made available to Registrar by Verisign from time to time (collectively the “Required Data Elements”). Registrar shall submit any corrections or updates from a Registered Name Holder relating to the registration information for a Registered Name to Verisign in a timely manner.

2.6.License. Registrar grants Verisign a non-exclusive, royalty-free, nontransferable (except to ICANN or its designee pursuant to Verisign’s Registry Agreement with ICANN) worldwide limited license to the Required Data Elements: (a) for use as required or permitted by technical specifications of the System as made available to Registrar by Verisign from time to time; and/or (b) for use and display as required or permitted by Verisign's Registry Agreement with ICANN, as may be amended from time to time.

2.7.Registrar's Registration Agreement and Domain Name Dispute Policy.

(a)Registrar shall have in effect a valid and enforceable electronic or paper registration agreement with each Registered Name Holder which may be amended from time to time by Registrar, provided a copy is made available to Verisign. Registrar shall provide a copy of Registrar's registration agreement upon request for same by Verisign. Registrar shall include in its registration agreement those terms required by this Agreement and other terms that are consistent with Registrar's obligations to Verisign under this Agreement. Registrar shall employ in its domain name registration business the Uniform Domain Name Dispute Resolution Policy and the Inter-Registrar Transfer Policy, each as adopted by the ICANN Board on 26 August 1999 and 7 November 2008 and as each may be amended from time to time.

(b)Registrar’s registration agreement with each Registered Name Holder shall also include the following:

(i)a provision prohibiting the Registered Name Holder from distributing malware, abusively operating botnets, phishing, pharming, piracy, trademark or copyright infringement, fraudulent or deceptive practices, counterfeiting or

otherwise engaging in activity contrary to applicable law and providing (consistent with applicable law and any related procedures) consequences for such activities, including suspension of the registration of the Registered Name;

(ii)a provision that requires the Registered Name Holder to acknowledge and agree that Verisign reserves the right to deny, cancel, redirect or transfer any registration or transaction, or place any domain name(s) on registry lock, hold or similar status, as it deems necessary, in its unlimited and sole discretion: (1) to comply with specifications adopted by any industry group generally recognized as authoritative with respect to the Internet (e.g., RFCs), (2) to correct mistakes made by Verisign or any Registrar in connection with a domain name registration, (3) for the non-payment of fees to Verisign, (4) to protect against imminent and substantial threats to the security and stability of the Registry TLD, System, Verisign’s nameserver operations or the internet, (5) to ensure compliance with applicable law, government rules or regulations, or pursuant to any legal order or subpoena of any government, administrative or governmental authority, or court of competent jurisdiction, and/or (6) to stop or prevent any violations of any terms and conditions of this Agreement, the Operational Requirements, or pursuant to Verisign’s Registry Agreement with ICANN; and

(iii)a provision requiring the Registered Name Holder to indemnify, defend and hold harmless Verisign and its subcontractors, and its and their directors, officers, employees, agents, and affiliates from and against any and all claims, damages, liabilities, costs and expenses, including reasonable legal fees and expenses arising out of or relating to, for any reason whatsoever, the Registered Name Holder's domain name registration. The registration agreement shall further require that this indemnification obligation survive the termination or expiration of the registration agreement.

2.8.Secure Connection.

(a)Registrar agrees to develop and employ in its domain name registration business all necessary technology and restrictions to ensure that its connection to the System is secure. All data exchanged between Registrar's system and the System shall be protected to avoid unintended disclosure of information. Registrar shall employ commercially reasonable measures to prevent its access to the System granted hereunder from being used to (i) allow, enable, or otherwise support the transmission by e-mail, telephone, or facsimile of mass unsolicited, commercial advertising or solicitations to entities other than its own existing customers; or (ii) enable high volume, automated, electronic processes that send queries or data to the systems of Verisign, any other registry operated under an agreement with ICANN, or any ICANN-accredited registrar, except as reasonably necessary to register domain names or modify existing registrations in accordance with any Operational Requirements.

(b)Each EPP session shall be authenticated and encrypted using two-way secure socket layer ("SSL") protocol. Registrar agrees to authenticate every EPP client connection with the System using both an X.509 server certificate issued by a commercial Certification Authority identified by the Registry and its Registrar password, which it shall disclose only to its employees with a need to know. Registrar agrees to notify Registry within four (4) hours of learning that its Registrar password has been compromised in any way or if its server certificate has been revoked by the issuing Certification Authority or compromised in any way.

(c)Upon prior written notification to Registrar, Verisign may require other industry standard security provisions, practices or technology to ensure that the System is secure and stable, which Verisign may adopt from time to time in its sole and complete discretion.

2.8.1.Handling of Personal Data.

Verisign shall notify Registrar of the purposes for which Personal Data submitted to Verisign by Registrar is collected, the intended recipients (or categories of recipients) of such Personal Data, and the mechanism for access to and correction of such Personal Data. Verisign shall take reasonable steps to protect Personal Data from loss, misuse, unauthorized disclosure, alteration or destruction. Verisign shall not use or authorize the use of Personal Data in a way that is incompatible with the notice provided to registrars. Verisign may from time to time use the demographic data collected for statistical analysis, provided that this analysis will not disclose individual Personal Data and provided that such use is compatible with the notice provided to registrars regarding the purpose and procedures for such use.

2.8.2.Authorization Codes. Registrar shall not provide identical Registrar- generated authorization <authinfo> codes for domain names registered by different Registered Name Holders with the same Registrar. Verisign in its sole discretion may choose to modify <authinfo> codes for a given domain and shall notify the sponsoring registrar of such modifications via EPP compliant mechanisms (i.e., EPP<poll> or EPP<domain:Info>). Documentation of these mechanisms shall be made available to Registrar by Verisign. The Registrar shall provide the Registered Name Holder with timely access to the authorization code along with the ability to modify the authorization code. Registrar shall respond to any inquiry by a Registered Name Holder regarding access to and/or modification of an authorization code within five (5) calendar days.

2.9.Domain Name Lookup Capability. Registrar agrees to employ in its domain name registration business Verisign's registry domain name lookup capability to determine if a requested domain name is available or currently unavailable for registration. Registrar also agrees, at its expense, to provide a Registration Data Directory Service providing free public query-based access to up-to-date (i.e., updated at least daily) data concerning all active Registered Names sponsored by Registrar for the Registry TLD. The data accessible shall consist of elements that are designated from time

to time according to an ICANN adopted specification or policy or the Registrar Accreditation Agreement between Registrar and ICANN.

2.10.Transfer of Sponsorship of Registrations. Registrar agrees to implement transfers of Registered Name registrations from another registrar to Registrar and vice versa or from one Registered Name Holder to another pursuant to the Inter-Registrar Transfer Policy as may be amended from time to time by ICANN (the "Transfer Policy").

2.11.Time. Registrar agrees that in the event of any dispute concerning the time of the entry of a domain name registration into the registry database, the time shown in the Verisign records shall control.

2.12.Compliance with Operational Requirements. Registrar shall comply with each of the following requirements, and further shall include in its registration agreement with each Registered Name Holder, as applicable, an obligation for such Registered Name Holder to comply with each of the following requirements:

(a)ICANN standards, policies, procedures, and practices for which Verisign has monitoring responsibility in accordance with the Registry Agreement or other arrangement with ICANN; and

(b)Operational standards, policies, procedures, and practices for the Registry TLD established from time to time by Verisign in a non-arbitrary manner and applicable to all registrars ("Operational Requirements"), including affiliates of Verisign, and consistent with Verisign's Registry Agreement with ICANN, as applicable, upon Verisign's notification to Registrar of the establishment of those terms and conditions.

2.13.Resolution of Technical Problems or Breach of Agreement. Registrar agrees to employ necessary employees, contractors, or agents with sufficient technical training and experience to respond to and fix all technical problems concerning the use of the Supported Protocol, the APIs and the systems of Verisign in conjunction with Registrar's systems. Registrar agrees that in the event of significant degradation of the System or other emergency, or upon Registrar's violation of Operational Requirements or breach of this Agreement, Verisign may, in its sole discretion, temporarily suspend or restrict access to the System. Such temporary suspensions or restrictions shall be applied in a non-arbitrary manner and shall apply fairly to any registrar similarly situated.

2.14.Prohibited Domain Name Registrations. In addition to complying with ICANN standards, policies, procedures, and practices limiting domain names that may be registered, Registrar agrees to comply with applicable statutes and regulations limiting the domain names that may be registered. Registrar further acknowledges and agrees that Verisign reserves the right to deny, cancel, redirect or transfer any registration or transaction, or place any domain name(s) on registry lock, hold or similar status, as it deems necessary, in its unlimited and sole discretion, for the purposes set forth in Section 2.7(b)(ii) of this Agreement.

2.15.ICANN Requirements. Verisign's obligations hereunder are subject to modification at any time as the result of ICANN-mandated requirements, including consensus policies. Notwithstanding anything in this Agreement to the contrary, Registrar shall comply with any such ICANN requirements in accordance with the timeline defined by ICANN.

2.16.Accredited Registrar. During the term of this Agreement, Registrar shall maintain in full force and effect the Registrar Accreditation Agreement and its accreditation by ICANN as a registrar for the Registry TLD.

3.LICENSE

3.1.License Grant. Subject to the terms and conditions of this Agreement, Verisign hereby grants Registrar and Registrar accepts a non-exclusive, royalty-free, nontransferable, worldwide limited license to use for the term and purposes of this Agreement the Licensed Product, as well as updates and redesigns thereof, to provide domain name registration services in the Registry TLD only and for no other purpose. The Licensed Product, as well as updates and redesigns thereof, will enable Registrar to register domain names in the Registry TLD with the Registry on behalf of its Registered Name Holders. Registrar, using the Licensed Product, as well as updates and redesigns thereof, will be able to invoke the following operations on the System: (i) check the availability of a domain name, (ii) register a domain name, (iii) re-register a domain name, (iv) cancel the registration of a domain name it has registered, (v) update the nameservers of a domain name, (vi) transfer a domain name from another registrar to itself with proper authorization, (vii) query a domain name registration record, (viii) register a nameserver, (ix) update the IP addresses of a nameserver, (x) delete a nameserver, (xi) query a nameserver, and (xii) establish and end an authenticated session.

3.2.Limitations on Use. Notwithstanding any other provisions in this Agreement, except with the written consent of Verisign, Registrar shall not: (i) sublicense the Licensed Product or otherwise permit any use of the Licensed Product by or for the benefit of any party other than Registrar, (ii) publish, distribute or permit disclosure of the Licensed Product other than to employees, contractors, and agents of Registrar for use in Registrar's domain name registration business, (iii) decompile, reverse engineer, copy or re-engineer the Licensed Product for any unauthorized purpose, (iv) use or permit use of the Licensed Product in violation of any federal, state or local rule, regulation or law, or for any unlawful purpose. Registrar agrees to employ the necessary measures to prevent its access to the System granted hereunder from being used to (i) allow, enable, or otherwise support the transmission by e-mail, telephone, or facsimile of mass unsolicited, commercial advertising or solicitations to entities other than Registrar's customers; or (ii) enable high volume, automated, electronic processes that send queries or data to the systems of Verisign, any other registry operated under an agreement with ICANN, or any ICANN- Accredited Registrar, except as reasonably necessary to register domain names or modify existing registrations in accordance with any Operational Requirements.

3.3.Changes to Licensed Materials. Verisign may from time to time replace or make modifications to the Licensed Product licensed hereunder. Verisign will provide Registrar with at least ninety (90) days’ notice prior to the implementation of any material changes to the Supported Protocol, APIs or software licensed hereunder.

4.SUPPORT SERVICES

4.1.Engineering Support. Verisign agrees to provide Registrar with reasonable engineering telephone support (between the hours of 9 a.m. to 5 p.m. EST or at such other times as may be mutually agreed upon) to address engineering issues arising in connection with Registrar's use of the System.

4.2.Customer Service Support. During the term of this Agreement, Verisign will provide reasonable telephone, web based and e-mail customer service support to Registrar, not Registered Name Holder or prospective customers of Registrar, for nontechnical issues solely relating to the System and its operation. Verisign will provide Registrar with a telephone number and e-mail address for such support during implementation of the Supported Protocol, APIs and Software. First-level telephone support will be available on a 7-day/24-hour basis.

5.FEES

5.1.Registration Fees.

(a)Registrar agrees to pay Verisign the non-refundable fees set forth in Exhibit A, or such other amount as may be established in accordance with the notice provision set forth in Section 5.1(b) below, for initial and renewal registrations and other incidental and ancillary services provided by Verisign (collectively, the "Registration Fees").

(b)Verisign reserves the right to adjust the Registration Fees, provided that any price increase shall be made only upon six (6) months prior notice to Registrar (by e-mail, hand, by registered mail, or by courier or express delivery service), and provided that such adjustments are consistent with Verisign's Registry Agreement with ICANN.

(c)Registrars shall provide Verisign a payment security comprised of an irrevocable letter of credit or cash deposit (the "Payment Security"). The amount of the Payment Security establishes Registrar's credit limit in the Verisign System and should be based on anticipated monthly level of registrations and other billable transactions. Registrar agrees to modify its Payment Security to support increases in billable transaction volumes as required by the Verisign credit and billing policies. Verisign will invoice Registrar monthly in arrears for each month's Registration Fees. All Registration Fees are due immediately upon receipt of Verisign's monthly invoices. In order to satisfy any outstanding account balances, Verisign may

draw upon the Registrar's Payment Security. If this occurs, Registrar agrees to replenish Payment Security to the pre-draw level immediately upon completion of draw. If Registrar's Payment Security is depleted, registration of domain names for the Registrar will be suspended and new registrations will not be accepted until the Payment Security is replenished.

(d)The Registration Fees due under this Agreement are exclusive of tax. All taxes, duties, fees and other governmental charges of any kind (including business, levy, sales, turnover, services, use and value-added taxes, but excluding taxes based on the net income of Verisign) which are imposed by or under the authority of any government or any political subdivision thereof on the fees for any services, software and/or hardware shall be borne by Registrar and shall not be considered a part of, a deduction from or an offset against such Registration Fees. All payments due to Verisign shall be made without any deduction or withholding on account of any tax, duty, charge or penalty except as required by law, in which case, the sum payable by Registrar from which such deduction or withholding is to be made shall be increased to the extent necessary to ensure that, after making such deduction or withholding, Verisign receives and retains (free from any liability with respect thereof) a net sum equal to the sum it would have received but for such deduction or withholding being required.

5.2.Change in Registrar Sponsoring Domain Name. Registrar may assume sponsorship of a Registered Name Holder's existing domain name registration from another registrar by following the Transfer Policy.

(a)For each transfer of the sponsorship of a domain-name registration under the Transfer Policy, Registrar agrees to pay Verisign the renewal registration fee associated with a one-year extension, as set forth above. The losing registrar's Registration Fees will not be refunded as a result of any such transfer.

(b)For a transfer approved by ICANN under Part B of the Transfer Policy, Registrar agrees to pay Verisign US $0 (for transfers of 50,000 names or fewer) or US

$50,000 (for transfers of more than 50,000 names).

Fees under this Section 5.2 shall be due immediately upon receipt of Verisign's invoice pursuant to the Payment Security.

5.3.Charges for ICANN Fees. Registrar agrees to pay to Verisign, within five (5) days of the date when due, any variable registry-level fees paid by Verisign to ICANN, which fees shall be secured by the Payment Security. The fee will consist of two components; each component will be calculated by ICANN for each registrar:

(a)The transactional component of the Variable Registry-Level Fee shall be specified by ICANN in accordance with the budget adopted by the ICANN

Board of Directors for each fiscal year but shall not exceed the amount set forth in the Registry Agreement.

(b)The per-registrar component of the Variable Registry-Level Fee shall be specified by ICANN in accordance with the budget adopted by the ICANN Board of Directors for each fiscal year, but the sum of the per registrar fees calculated for all registrars shall not exceed the total Per-Registrar Variable funding established pursuant to the approved ICANN Budget.

5.4.Non-Payment of Fees. Timely payment of fees owing under this Section 5 is a material condition of performance under this Agreement. In the event that Registrar fails to pay its fees within five (5) days of the date when due, Verisign may: (i) stop accepting new initial or renewal registrations from Registrar; (ii) delete the domain names associated with invoices not paid in full from the Registry database; (iii) give written notice of termination of this Agreement pursuant to Section 6.1(b) below; and (iv) pursue any other remedy under this Agreement.

6.MISCELLANEOUS

6.1.Term of Agreement and Termination.

(a)Term of the Agreement; Revisions. The duties and obligations of the Parties under this Agreement shall apply from the Effective Date through and including the last day of the calendar month sixty (60) months from the Effective Date (the "Initial Term"). Upon conclusion of the Initial Term, all provisions of this Agreement will automatically renew for successive five (5) year renewal periods until the Agreement has been terminated as provided herein, Registrar elects not to renew, or Verisign ceases to operate the registry for the Registry TLD. In the event that revisions to Verisign's Registry-Registrar Agreement are approved or adopted by ICANN, Registrar shall have thirty (30) days from the date of notice of any such revision to review, comment on, and execute an amendment substituting the revised agreement in place of this Agreement, or Registrar may, at its option exercised within such thirty (30) day period, terminate this Agreement immediately by giving written notice to Verisign; provided, however, that in the event Verisign does not receive such executed amendment or notice of termination from Registrar within such thirty (30) day period of the date of the notice, Registrar shall be deemed to have executed such amendment as of the thirty-first (31st) day after the date of the notice.

(b)Termination For Cause. In the event that either Party materially breaches any term of this Agreement including any of its representations and warranties hereunder and such breach is not substantially cured within thirty (30) calendar days after written notice thereof is given by the other Party, then the non-

breaching Party may, by giving written notice thereof to the other Party, terminate this Agreement as of the date specified in such notice of termination.

(c)Termination at Option of Registrar. Registrar may terminate this Agreement at any time by giving Verisign thirty (30) days’ notice of termination.

(d)Termination Upon Loss of Registrar's Accreditation. This Agreement shall terminate immediately in the event Registrar's accreditation for the Registry TLD by ICANN, or its successor, is terminated or expires without renewal.

(e)Termination in the Event that Successor Registry Operator is Named. This Agreement shall terminate in the event that the U.S. Department of Commerce or ICANN, as appropriate, designates another entity to operate the registry for the Registry TLD.

(f)Termination in the Event of Bankruptcy. Either Party may terminate this Agreement if the other Party is adjudged insolvent or bankrupt, or if proceedings are instituted by or against a Party seeking relief, reorganization or arrangement under any laws relating to insolvency, or seeking any assignment for the benefit of creditors, or seeking the appointment of a receiver, liquidator or trustee of a Party's property or assets or the liquidation, dissolution or winding up of a Party's business.

(g)Effect of Termination. Upon expiration or termination of this Agreement, Verisign will, to the extent it has the authority to do so, complete the registration of all domain names processed by Registrar prior to the date of such expiration or termination, provided that Registrar's payments to Verisign for Registration Fees are current and timely. Immediately upon any expiration or termination of this Agreement, Registrar shall (i) transfer its sponsorship of Registered Name registrations to another licensed registrar(s) of the Registry, in compliance with Part B of the Transfer Policy, or any other procedures established or approved by the U.S. Department of Commerce or ICANN, as appropriate, and (ii) either return to Verisign or certify to Verisign the destruction of all Confidential Information it has received under this Agreement. In the event of termination, Verisign reserves the right to immediately contact any and all Registered Name Holders to facilitate the orderly and stable transition of Registered Name Holders to other ICANN-accredited registrars. All fees owing to Verisign shall become immediately due and payable.

(h)Survival. In the event of termination of this Agreement, the following shall survive: (i) Sections 2.6 (License), 2.7 (Registrar's Registration Agreement and Domain Name Dispute Policy), 2.8.1 (Handling of Personal Data), 6.1(g) (Effect of Termination), 6.1(h) (Survival), 6.2 (No Third Party Beneficiaries; Relationship of the Parties), 6.5 (Amendment in Writing), 6.6 (Attorneys' Fees),

6.7 (Dispute Resolution; Choice of Law; Venue), 6.8 (Notices), 6.10 (Use of Confidential Information), 6.11 (Delays or Omissions; Waivers), 6.12 (Limitation of Liability), 6.13 (Construction), 6.14 (Intellectual Property), 6.15(c) (Disclaimer of Warranties), 6.16 (Indemnification), and 6.17 (Entire Agreement; Severability); (ii) the Registered Name ▇▇▇▇▇▇'s obligations to indemnify, defend, and hold harmless Verisign, as stated in Section 2.7(b)(iii); and (iii) Registrar's payment obligations as set forth in Section 5 with respect to fees incurred during the term of this Agreement.

6.2.No Third Party Beneficiaries; Relationship of the Parties. This Agreement does not provide and shall not be construed to provide third parties (i.e., non-parties to this Agreement), including any Registered Name Holder, with any remedy, claim, cause of action or privilege. Nothing in this Agreement shall be construed as creating an employer- employee or agency relationship, a partnership or a joint venture between the Parties.

6.3.Force Majeure. Neither Party shall be responsible for any failure to perform any obligation (other than payment obligations) or provide service hereunder because of any Act of God, strike, work stoppage, cyberattack, to protect against imminent and substantial threats to the security and stability of the Registry TLD, System, Verisign’s name server operations or the internet, governmental acts or directives, war, riot or civil commotion, equipment or facilities shortages which are being experienced by providers of telecommunications services generally, or other similar force beyond such Party's reasonable control.

6.4.Further Assurances. Each Party hereto shall execute and/or cause to be delivered to each other Party hereto such instruments and other documents, and shall take such other actions, as such other Party may reasonably request for the purpose of carrying out or evidencing any of the transactions contemplated by this Agreement.

6.5.Amendment in Writing. Except as otherwise provided in this Agreement, any amendment or supplement to this Agreement shall be in writing and duly executed by both Parties. Any new services approved by ICANN and purchased by Registrar will be subject to such terms and conditions as may be established by Verisign through an appendix to this Agreement or such other agreement executed by Registrar and Verisign.

6.6.Attorneys' Fees. If any legal action or other legal proceeding (including arbitration) relating to the performance under this Agreement or the enforcement of any provision of this Agreement is brought against either Party hereto, the prevailing Party shall be entitled to recover reasonable attorneys' fees, costs and disbursements (in addition to any other relief to which the prevailing Party may be entitled).

6.7.Dispute Resolution; Choice of Law; Venue. The Parties shall attempt to resolve any disputes between them prior to resorting to litigation. This Agreement is to be construed in accordance with and governed by the internal laws of the Commonwealth of Virginia, United States of America without giving effect to any choice of law rule that

would cause the application of the laws of any jurisdiction other than the internal laws of the Commonwealth of Virginia to the rights and duties of the Parties. Any legal action or other legal proceeding relating to this Agreement or the enforcement of any provision of this Agreement shall be brought or otherwise commenced in any state or federal court located in the eastern district of the Commonwealth of Virginia. Each Party to this Agreement expressly and irrevocably consents and submits to the jurisdiction and venue of each state and federal court located in the eastern district of the Commonwealth of Virginia (and each appellate court located in the Commonwealth of Virginia) in connection with any such legal proceeding.

6.8.Notices. Any notice or other communication required or permitted to be delivered to any Party under this Agreement shall be in writing and shall be deemed properly delivered, given and received when delivered (by hand, by registered mail, by courier or express delivery service, by e-mail or by telecopier during business hours) to the address or telecopier number set forth beneath the name of such Party below, unless Party has given a notice of a change of address in writing:

if to Registrar:

Customer Name:

Attention:

Physical Address:

City, State Postal:

Telephone Number:

Facsimile Number:

E-Mail:

with a copy to:

Customer Name:

Attention:

Physical Address:

City, State Postal:

Telephone Number:

Facsimile Number:

E-Mail:

if to Verisign:

VeriSign, Inc.

▇▇▇▇▇ ▇▇▇▇▇▇▇▇ ▇▇▇

Reston, VA 20190 Attn: General Counsel

Telephone: ▇▇ ▇▇▇ ▇▇▇ ▇▇▇▇

Facsimile: ▇▇ ▇▇▇ ▇▇▇ ▇▇▇▇ E-Mail: ▇▇▇▇▇@▇▇▇▇▇▇▇▇.▇▇▇

With a copy to (which shall not constitute notice):

VeriSign, Inc.

▇▇▇▇▇ ▇▇▇▇▇▇▇▇ ▇▇▇

Reston, VA 20190

Attn: Customer Affairs Office Telephone: ▇▇ ▇▇▇ ▇▇▇ ▇▇▇▇

Facsimile: ▇▇ ▇▇▇ ▇▇▇ ▇▇▇▇

E-Mail: ▇▇▇@▇▇▇▇▇▇▇▇-▇▇▇.▇▇▇

6.9.Assignment/Sublicense. Except as otherwise expressly provided herein, the provisions of this Agreement shall inure to the benefit of and be binding upon, the successors and permitted assigns of the Parties hereto. Registrar shall not assign, sublicense or transfer its rights or obligations under this Agreement to any third person without the prior written consent of Verisign. Verisign may assign its rights or obligations under this Agreement to an affiliate without the consent of Registrar.

6.9.1.Assignment in Connection with Assignment of Agreement with ICANN. In the event that Verisign's Registry Agreement with ICANN for the Registry TLD is validly assigned, Verisign's rights under this Agreement shall be automatically assigned to the assignee of the Registry Agreement, provided that the assignee assumes the duties of Verisign under this Agreement. In the event that Registrar's Registrar Accreditation Agreement with ICANN for the Registry TLD is validly assigned, Registrar's rights under this Agreement shall be automatically assigned to the assignee of Registrar’s Registrar Accreditation Agreement, provided that the subsequent registrar assumes the duties of Registrar under this Agreement.

6.10.Use of Confidential Information. During the term of this Agreement, each Party (the "Disclosing Party") may disclose its Confidential Information to the other Party (the "Receiving Party"). Each Party's use and disclosure of Confidential Information disclosed hereunder are subject to the following terms and conditions:

(a)The Receiving Party shall treat as strictly confidential, and use all reasonable efforts to preserve the secrecy and confidentiality of, all Confidential Information of the Disclosing Party, including implementing reasonable physical security measures and operating procedures.

(b)The Receiving Party agrees that it will use any Confidential Information of the Disclosing Party solely for the purpose of exercising its right or performing its obligations under this Agreement and for no other purposes whatsoever.

(c)The Receiving Party shall make no disclosures whatsoever of any Confidential Information of the Disclosing Party to others; provided, however, that if the Receiving Party is a corporation, partnership, or similar entity, disclosure is permitted to the Receiving Party's officers, employees, contractors and agents who have a demonstrable need to know such Confidential Information, provided the Receiving Party shall advise such personnel of the confidential nature of the Confidential Information and take reasonable steps to maintain the confidentiality thereof.

(d)The Receiving Party shall not modify or remove any confidentiality legends and/or copyright notices appearing on any Confidential Information of the Disclosing Party.

(e)The Receiving Party agrees not to prepare any derivative works based on the Confidential Information.

(f)Notwithstanding the foregoing, this Subsection 6.10 imposes no obligation upon the parties with respect to information that (i) is disclosed in the absence of a confidentiality agreement and such disclosure was agreed to by the Disclosing Party in writing prior to such disclosure; or (ii) is or has entered the public domain through no fault of the Receiving Party; or (iii) is known by the Receiving Party prior to the time of disclosure; or (iv) is independently developed by the Receiving Party without use of the Confidential Information; or (v) is made generally available by the Disclosing Party without restriction on disclosure, or (vi) is required to be disclosed by law, regulation or court order; provided, that in the event the Receiving Party is required by law, regulation or court order to disclose any of Disclosing Party's Confidential Information, Receiving Party will promptly notify Disclosing Party in writing prior to making any such disclosure in order to facilitate Disclosing Party seeking a protective order or other appropriate remedy from the proper authority, at the Disclosing Party's expense. Receiving Party agrees to cooperate with Disclosing Party in seeking such order or other remedy. Receiving Party further agrees that if Disclosing Party is not successful in precluding the requesting legal body from requiring the disclosure of the Confidential Information, it will furnish only that portion of the Confidential Information that is legally required.

6.11.Delays or Omissions; Waivers. No failure on the part of either Party to exercise any power, right, privilege or remedy under this Agreement, and no delay on the part of either Party in exercising any power, right, privilege or remedy under this Agreement, shall operate as a waiver of such power, right, privilege or remedy; and no single or partial exercise or waiver of any such power, right, privilege or remedy shall preclude any other or further exercise thereof or of any other power, right, privilege or remedy. No Party shall be deemed to have waived any claim arising out of this Agreement, or any power, right, privilege or remedy under this Agreement, unless the waiver of such claim, power, right, privilege or remedy is expressly set forth in a written instrument duly

100

executed and delivered on behalf of such Party; and any such waiver shall not be applicable or have any effect except in the specific instance in which it is given.

6.12.Limitation of Liability.

(a)IN NO EVENT WILL VERISIGN BE LIABLE TO REGISTRAR FOR ANY SPECIAL, INDIRECT, INCIDENTAL, PUNITIVE, EXEMPLARY OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES RESULTING FROM LOSS OF PROFITS, ARISING OUT OF OR IN CONNECTION WITH THIS AGREEMENT, EVEN IF VERISIGN HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH ▇▇▇▇▇▇▇.▇▇ NO EVENT SHALL THE MAXIMUM AGGREGATE LIABILITY OF THE PARTIES EXCEED THE LESSER OF (I) THE TOTAL AMOUNT PAID TO VERISIGN UNDER THE TERMS OF THIS AGREEMENT FOR THE IMMEDIATELY PRECEDING TWELVE (12) MONTH PERIOD, OR (ii) $500,000 USD.

(b)THE LIABILITY CAP AND EXCLUSION OF DAMAGES SET FORTH IN SECTION 6.12(a) SHALL NOT APPLY TO SECTION 6.10 (CONFIDENTIALITY) AND SECTION 6.16 (INDEMNIFICATION).

6.13.Construction. The Parties agree that any rule of construction to the effect that ambiguities are to be resolved against the drafting Party shall not be applied in the construction or interpretation of this Agreement.

6.14.Intellectual Property. Subject to Section 2.6 above, each Party will continue to independently own its intellectual property, including all patents, trademarks, trade names, service marks, copyrights, trade secrets, proprietary processes and all other forms of intellectual property.

6.15.Representations and Warranties

(a)Registrar. Registrar represents and warrants that: (1) it is a corporation duly incorporated, validly existing and in good standing under the law of

, (2) it has all requisite corporate power and authority to execute, deliver and perform its obligations under this Agreement, (3) it is, and during the term of this Agreement will continue to be, accredited by ICANN or its successor, pursuant to the Registrar Accreditation Agreement or a successor agreement approved by ICANN, (4) the execution, performance and delivery of this Agreement has been duly authorized by Registrar, and (5) no further approval, authorization or consent of any governmental or regulatory authority is required to be obtained or made by Registrar in order for it to enter into and perform its obligations under this Agreement.

(b)Verisign. Verisign represents and warrants that: (1) it is a corporation duly incorporated, validly existing and in good standing under the laws of the State of Delaware, (2) it has all requisite corporate power and authority to execute,

101

deliver and perform its obligations under this Agreement, (3) the execution, performance and delivery of this Agreement has been duly authorized by Verisign, and (4) no further approval, authorization or consent of any governmental or regulatory authority is required to be obtained or made by Verisign in order for it to enter into and perform its obligations under this Agreement.

(c)Disclaimer of Warranties. The LICENSED PRODUCT, SUPPORTED PROTOCOL, EPP, APIs AND SOFTWARE ARE PROVIDED "AS-IS" AND WITHOUT ANY WARRANTY OF ANY KIND. VERISIGN EXPRESSLY DISCLAIMS ALL WARRANTIES AND/OR CONDITIONS, EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES AND CONDITIONS OF MERCHANTABILITY OR SATISFACTORY QUALITY AND FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. VERISIGN DOES NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE LICENSED PRODUCT, SUPPORTED PROTOCOL, EPP, APIs OR SOFTWARE WILL MEET REGISTRAR'S REQUIREMENTS, OR THAT THE OPERATION OF THE LICENSED PRODUCT, SUPPORTED PROTOCOL, EPP, APIs OR SOFTWARE WILL BE UNINTERRUPTED OR ERROR-FREE, OR THAT DEFECTS IN THE LICENSED PRODUCT, SUPPORTED PROTOCOL, EPP, APIs OR SOFTWARE WILL BE CORRECTED. FURTHERMORE, VERISIGN DOES NOT WARRANT NOR MAKE ANY REPRESENTATIONS REGARDING THE USE OR THE RESULTS OF THE LICENSED PRODUCT, SUPPORTED PROTOCOL, EPP, APIs, SOFTWARE OR RELATED DOCUMENTATION IN TERMS OF THEIR CORRECTNESS, ACCURACY, RELIABILITY, OR OTHERWISE. SHOULD THE LICENSED PRODUCT, SUPPORTED PROTOCOL, EPP, APIs OR SOFTWARE PROVE DEFECTIVE, REGISTRAR ASSUMES THE ENTIRE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION OF REGISTRAR'S OWN SYSTEMS AND SOFTWARE.

6.16.Indemnification. Registrar, at its own expense and within thirty (30) days of presentation of a demand by Verisign under this paragraph, will indemnify, defend and hold harmless Verisign and its employees, directors, officers, representatives, agents and affiliates, against any claim, suit, action, or other proceeding brought against Verisign or any affiliate of Verisign based on or arising from any claim or alleged claim (i) relating to any product or service of Registrar; (ii) relating to any agreement, including Registrar's dispute policy, with any Registered Name Holder of Registrar; or (iii) relating to Registrar's domain name registration business, including, but not limited to, Registrar's advertising, domain name application process, systems and other processes, fees charged, billing practices and customer service; provided, however, that in any such case: (a) Verisign provides Registrar with prompt notice of any such claim, and (b) upon Registrar's written request, Verisign will provide to Registrar all available information

102

and assistance reasonably necessary for Registrar to defend such claim, provided that Registrar reimburses Verisign for its actual and reasonable costs. Verisign shall have the right to control the defense of Verisign to any claim or in litigation, through counsel of its choice, whose fees shall be subject to indemnification as provided herein. Registrar will not enter into any settlement or compromise of any such indemnifiable claim without ▇▇▇▇▇▇▇▇'s prior written consent, which consent shall not be unreasonably withheld. Registrar will pay any and all costs, damages, and expenses, including, but not limited to, reasonable attorneys' fees and costs awarded against or otherwise incurred by Verisign in connection with or arising from any such indemnifiable claim, suit, action or proceeding.

6.17.Entire Agreement; Severability. This Agreement, which includes Exhibits A and B, constitutes the entire agreement between the Parties concerning the subject matter hereof and supersedes any prior agreements, representations, statements, negotiations, understandings, proposals or undertakings, oral or written, with respect to the subject matter expressly set forth herein. If any provision of this Agreement shall be held to be illegal, invalid or unenforceable, each Party agrees that such provision shall be enforced to the maximum extent permissible so as to effect the intent of the Parties, and the validity, legality and enforceability of the remaining provisions of this Agreement shall not in any way be affected or impaired thereby. If necessary to effect the intent of the Parties, the Parties shall negotiate in good faith to amend this Agreement to replace the unenforceable language with enforceable language that reflects such intent as closely as possible.

6.18.Service Level Agreement. Appendix 10, as may be amended from time to time, of the Registry Agreement shall be incorporated into this Agreement and attached hereto as Exhibit B.

103

IN WITNESS WHEREOF, the Parties hereto have executed this Agreement as of the Effective Date.

Verisign

By:

Name:

Title:

Date:

Registrar Company Name:

By:

Name:

Title:

Date: _________________________________

104

Exhibit A to Appendix 8

REGISTRATION FEES

1.Domain-Name Initial Registration Fee

Registrar agrees to pay US $10.26 per annual increment of an initial domain name registration, or such other amount as may be established in accordance with the notice provision set forth in Section 5.1(b) above.

2.Domain-Name Renewal Fee

Registrar agrees to pay US $10.26 per annual increment of a domain name registration renewal, or such other amount as may be established in accordance with the notice provision set forth in Section 5.1(b) above.

3.Domain Name Transfer

Registrar agrees to pay US $10.26 per domain name that is transferred to Registrar from another ICANN-Accredited Registrar, or such other amount as may be established in accordance with the notice provision set forth in Section 5.1(b) above.

4.EPP Update to Restore a Name

Registrar agrees to pay US $40.00 per use of the EPP Update command to restore a domain name, or such other amount as may be established in accordance with the notice provision set forth in Section 5.1(b) above.

5.Sync

Registrar agrees to pay US $2.00, plus $1.00 per month of the sync, for each use of the Supported Protocol Sync command, or such other amount as may be established in accordance with the notice provision set forth in Section 5.1(b) above.

105

Exhibit B to Appendix 8

SERVICE LEVEL AGREEMENT

See Appendix 10 to the .com Registry Agreement, as may be amended from time to time.

106

.com Registry Agreement Appendix 9

Approved Services

The Agreement specifies a "Process for Consideration of Proposed Registry Services." The following Registry Services are specifically identified as having been approved by ICANN prior to the Effective Date. As such, notwithstanding any other provisions of the Agreement, Verisign shall be free to deploy the following Registry Services:

•Consolidate/Sync Service, in accordance with Registry Operator’s Registrar Reference Manual;

•Internationalized Domain Names, in accordance with the Letter from ▇▇▇▇▇ ▇▇▇▇▇ to ▇▇▇▇ ▇▇▇▇▇▇ dated 13 October 2003;

•Restore, which allows use of the RRP Restore or EPP Update command to retrieve a previously deleted domain name registration during the Redemption Grace Period (approved by ICANN in accordance with Registry Operator’s Registrar Reference Manual;

•Wait Listing Service, in accordance with the letter from ▇▇▇▇ ▇. ▇▇▇▇▇▇▇ to ▇▇▇▇▇▇▇ ▇▇▇▇▇ dated 26 January 2004;

•Transfer Dispute Resolution, in accordance with the Registrar Transfer Dispute Resolution Policy, dated 12 July 2004 (as may be amended or superseded by ICANN), and Registry Operator's Supplemental Rules for Registrar Transfer Disputes;

•DNS Update Service, in accordance with ▇▇▇▇▇://▇▇▇.▇▇▇▇▇.▇▇▇/▇▇/▇▇▇▇▇▇/▇▇▇▇▇/▇▇▇▇▇/▇▇▇▇▇-▇▇-▇▇▇▇▇▇▇▇-▇▇▇▇▇▇▇-▇▇.▇▇▇ dated April 11, 2007;

•DNSSEC, in accordance with ▇▇▇▇▇://▇▇▇.▇▇▇▇▇.▇▇▇/▇▇/▇▇▇▇▇▇/▇▇▇▇▇/▇▇▇▇▇/▇▇▇▇▇-▇▇-▇▇▇▇▇▇▇▇-▇▇▇▇▇▇▇-▇▇▇▇▇▇▇-▇▇.▇▇▇ dated November 7, 2009;

•Bulk Transfer after Partial Portfolio Acquisition (“BTAPPA”) Restore, in accordance with ▇▇▇▇▇://▇▇▇.▇▇▇▇▇.▇▇▇/▇▇▇▇▇▇▇▇▇/▇▇▇▇▇-▇▇▇▇▇▇▇▇/▇▇▇▇▇▇▇-▇▇▇▇-▇▇-▇▇-▇▇ dated December 9, 2009;

•Domain Name WhoWas, in accordance with ▇▇▇▇▇://▇▇▇.▇▇▇▇▇.▇▇▇/▇▇/▇▇▇▇▇▇/▇▇▇▇▇/▇▇▇▇▇/▇▇▇▇▇▇▇▇-▇▇▇▇▇▇-▇▇▇▇▇▇▇-▇▇.▇▇▇, dated July 16, 2009;

•IDN DNS Updates, in accordance with ▇▇▇▇▇://▇▇▇.▇▇▇▇▇.▇▇▇/▇▇/▇▇▇▇▇▇/▇▇▇▇▇/▇▇▇▇▇/▇▇▇▇▇-▇▇-▇▇▇▇▇▇▇▇-▇▇▇▇▇▇-▇▇▇▇▇▇▇-▇▇.▇▇▇, dated July 10, 2009;

•Registry Lock Service, in accordance with ▇▇▇▇▇://▇▇▇.▇▇▇▇▇.▇▇▇/▇▇/▇▇▇▇▇▇/▇▇▇▇▇/▇▇▇▇▇/▇▇▇▇▇-▇▇-▇▇▇▇▇▇▇▇-▇▇▇▇▇▇-▇▇▇▇▇▇▇-▇▇.▇▇▇, dated July 10, 2009;

•Registry-Registrar Two-Factor Authentication Services, in accordance with ▇▇▇▇▇://▇▇▇.▇▇▇▇▇.▇▇▇/▇▇/▇▇▇▇▇▇/▇▇▇▇▇/▇▇▇▇▇/▇▇▇▇▇-▇▇-▇▇▇▇▇▇▇▇-▇▇▇▇▇▇-▇▇▇▇▇▇▇-▇▇.▇▇▇, dated July 10, 2009;

•Verification Code Extension for Extensible Provisioning Protocol, in accordance with ▇▇▇▇▇://▇▇▇.▇▇▇▇▇.▇▇▇/▇▇/▇▇▇▇▇▇/▇▇▇▇▇/▇▇▇▇▇▇▇▇▇▇▇▇▇▇/▇▇▇▇▇-▇▇-▇▇▇▇-▇▇▇▇▇▇▇-▇▇.▇▇▇, dated February 27, 2017;

•Registration of ▇.▇▇▇ Domain Name with a Single-Character Label in accordance with the Second Amendment to the .COM Registry Agreement, dated March 27, 2019, available at ▇▇▇▇▇://▇▇▇.▇▇▇.▇▇▇▇▇.▇▇▇/▇▇/▇▇▇▇▇/▇▇▇▇▇▇▇▇-▇▇▇▇▇▇▇▇▇▇/▇▇▇/▇▇▇-▇▇▇▇▇-▇-▇▇▇-▇▇▇▇▇▇▇-▇▇.▇▇▇;

107

•Modification to Verification Code Extension for Extensible Provisioning Protocol, in accordance with ▇▇▇▇▇://▇▇▇.▇▇▇▇▇.▇▇▇/▇▇/▇▇▇▇▇▇/▇▇▇▇▇/▇▇▇▇▇/▇▇▇▇▇▇▇▇▇-▇▇-▇▇▇▇-▇▇▇▇▇▇▇-▇▇.▇▇▇, dated February 14, 2022;

•Two-Factor Authentication Service, in accordance with ▇▇▇▇▇://▇▇▇.▇▇▇▇▇.▇▇▇/▇▇/▇▇▇▇▇▇/▇▇▇▇▇/▇▇▇▇▇▇▇▇▇▇▇▇▇▇/▇▇▇▇▇▇▇▇▇-▇▇-▇▇▇▇▇▇▇-▇▇▇▇▇▇▇-▇▇.▇▇▇, dated July 27, 2022;

•Domain Name Registration Validation Per Applicable Law, in accordance with ▇▇▇▇▇://▇▇▇.▇▇▇▇▇.▇▇▇/▇▇/▇▇▇▇▇▇/▇▇▇▇▇/▇▇▇▇▇▇▇▇▇▇▇▇▇▇/▇▇▇▇▇▇▇▇▇-▇▇-▇▇▇▇▇▇▇-▇▇▇▇▇▇▇-▇▇.▇▇▇, dated September 8, 2022; and

•Extensible Provisioning Protocol Service and Registration Validation per Applicable Law Service, in accordance with ▇▇▇▇▇://▇▇▇.▇▇▇▇▇.▇▇▇/▇▇/▇▇▇▇▇▇/▇▇▇▇▇/▇▇▇▇▇▇▇▇▇▇▇▇▇▇/▇▇▇▇▇▇▇▇▇-▇▇-▇▇▇▇-▇▇▇▇▇▇▇-▇▇.▇▇▇, dated October 25, 2023.

108

.com Registry Agreement Appendix 10

Service Level Agreement (SLA)

VeriSign, Inc. ("Registry Operator") strives to provide a world-class level of service to its customers. This Service Level Agreement ("SLA") provides remedies in the form of SLA Credits (as defined in section 2 below) should the operational performance of Registry Operator fall below certain Performance Specifications identified in Appendix 7.

1. Definitions.

Capitalized terms used herein and not otherwise defined shall have the definitions ascribed to them in the Registry Agreement, including, but not limited to Appendix 7.

2. SLA Credits.

If the Registry Operator fails to meet the Performance Specifications defined in Appendix 7, Section 6 thereof, to which Credit Levels apply, the Registry Operator shall pay credits to ICANN-Accredited Registrar(s) in accordance with the identified Credit Level for such failed Performance Specifications metrics, calculated in accordance with the Credit Level tables set forth in this Section 2 ("SLA Credit"). The SLA Credit due to each ICANN-Accredited Registrar shall be paid as an offset to registrations and other fees owed to Registry Operator by the ICANN-Accredited Registrar. SLA Credits represent the total credits, penalties and/or liabilities that may be assessed to the Registry Operator for a breach of the Performance Specifications set forth in Appendix 7. All SLA Credits shall be paid in U.S. Dollars. The Credit Level Table (Refer to Table SLA Credits) indicates the corresponding Credit Level for each Performance Specification to which Credit Levels apply. This SLA will be reconciled on a quarterly basis and unless otherwise specified in this SLA, SLA Credits will be issued on a quarterly basis.

App. 7 Reference

Performance Specification

SRS

Name Server

Whois

6.2.2,
6.2.3,
6.2.4

Service Availability

Level 2

Level 1

Level 2

6.3.1

Planned Outage - Duration

Level 6

6.3.2

Planned Outage - Timeframe

Level 5

6.3.3

Planned Outage - Notification

Level 5

6.4.1

Extended Planned Outage - Duration

Level 6

6.4.2

Extended Planned Outage - Timeframe

Level 5

109

6.4.3

Extended Planned Outage - Notification

Level 5

6.5.1

Processing Time - Check Domain

Level 3

6.5.2

Processing Time - Add/Create Domain

Level 3

6.5.3

Processing Time - Modify/Update and Delete Domain

Level 3

6.5.4

Processing Time - Whois Query

Level 3

6.5.5

Processing Time - DNS Name Server Resolution

Level 3

6.6.1

Update Frequency - DNS Name Server

Level 4

6.6.2

Update Frequency - Whois

Level 4

2.1 Credit Level 1 - Credit Level 1 is assessed for DNS Name Server Service Availability less than 100% per Monthly Timeframe. If the DNS Name Server Service Availability Performance Specification is not met, the SLA Credit for Credit Level 1 shall be payable to active ICANN-Accredited Registrars 30 days after the applicable calendar month in which the Service Availability Performance Specification was not met. For purposes of this Appendix 10, an "active" ICANN-Accredited Registrar is one who has registered greater than 150 net new .com domain names in the previous Monthly Timeframe.

Each active ICANN-Accredited Registrar that meets the requirements of Section 3 below would be credited an amount equal to such active ICANN-Accredited Registrar's net new .com domain name registrations during the applicable Monthly Timeframe divided by the net amount of new .com domain name registrations for all active ICANN-Accredited Registrars within the applicable Monthly Timeframe times the Monthly Credit Amount set forth in Table Credit Level 1.

Table Credit Level 1


	<30 sec.'s	30-60 sec.'s	1-2 min.'s	2-10 min.'s	10-30 min.'s	over 30 min.'s
SLA Credit Amount	$100,000	$175,000	$250,000	$400,000	$750,000	$1,000,000

2.2 Credit Level 2 - Credit Level 2 is assessed for SRS Service Availability less than 99.99% per calendar year and for Whois Service Availability less than 100% per Monthly Timeframe. If a Service Availability Performance Specification metrics are not met, the SLA Credit for Credit Level 2 shall be credited directly to active ICANN-Accredited Registrar(s) that meet the requirements of Section 3 below in an amount equal to the duration of the outage times (OT) times the average daily number of .com registrations over the previous three (3) months (NRAvg) times the .com wholesale fee divided by the number of minutes per day (1,440 minutes).

110

Active ICANN-Accredited Registrar would be credited:

(.com Registry Fee)*(OT)*(NRAvg)
(1,440 minutes)

Additionally, for any month where the total combined Unplanned Outage of SRS and Whois is greater than 30 minutes, Registry Operator will credit active ICANN-Accredited Registrars that meet the requirements of Section 3 below One Thousand Dollars ($1,000).

2.3 Credit Level 3 - Credit Level 3 is assessed for failure to meet the Performance Specifications for the Processing Time for check domain, add/create, modify/update and delete domain commands, and DNS Name Server Resolution and Whois queries. If the Processing Time Performance Specifications metrics are not met, the SLA Credit for Credit Level 3 (Refer to Table Credit Level 3) shall be payable to active ICANN-Accredited Registrars in an amount based upon the % of time that the Processing Time exceeds the applicable Performance Specifications metric.

Each active ICANN-Accredited Registrar that meets the requirements of Section 3 below would be credited an amount equal to such active ICANN-Accredited Registrar's net new .com domain name registrations during the applicable Monthly Timeframe divided by the net amount of net new .com domain name registrations for all active ICANN-Accredited Registrars within the applicable Monthly Timeframe times the SLA Credit Amount set forth in Table Credit Level 3 within 30 days after the applicable calendar month.

Table Credit Level 3


	5 - <10%	10 - <25%	25 - <50%	≥50%
SLA Credit Amount	$500	$1,000	$2,000	$5,000

2.4 Credit Level 4 - Credit Level 4 is assessed for failure to meet the Performance Specifications for Update frequencies for DNS Name Server and Whois. If the Update frequency Performance Specifications metrics are not met, the SLA Credit for Credit Level 4 (Refer to Table Credit Level 4) shall be payable to active ICANN-Accredited Registrars in an amount based upon the % of time that the Update frequency exceeds the applicable Performance Specifications metric.

Each active ICANN-Accredited Registrar that meets the requirements of Section 3 below would be credited an amount equal to such active ICANN-Accredited Registrar's net new .com domain name registrations during the applicable Monthly Timeframe divided by the net amount of new .com domain name registrations for all active ICANN-Accredited Registrars within the applicable Monthly Timeframe times the SLA Credit Amount set forth in Table Credit Level 4.

Table Credit Level 4


	Up to <15 minutes over	15 minutes to <1 hour	1 hour to <12 hours	≥ 12 hours
SLA Credit Amount	$500	$1,000	$2,000	$5,000

2.5 Credit Level 5 - Credit Level 5 is assessed for failure to meet the Performance Specifications

111

for Planned Outage Timeframe, Planned Outage Notification, Extended Planned Outage Timeframe and Extended Planned Outage Notification. If the Performance Specifications metrics are not met, the SLA Credit for Credit Level 5 shall be payable to each active ICANN-Accredited Registrar that meets the requirements of Section 3 below in an amount equal to such active ICANN-Accredited Registrar's net new .com domain name registrations during the applicable Monthly Timeframe divided by the net amount of new .com domain name registrations for all active ICANN-Accredited Registrars within the applicable Monthly Timeframe times One Thousand Dollars ($1,000).

2.6 Credit Level 6 - Credit Level 6 is assessed for failure to meet the Performance Specifications for Planned Outage Duration and Extended Planned Outage Duration. If the Performance Specifications are not met, the SLA Credit for Credit Level 6 shall be payable directly to active ICANN-Accredited Registrar(s) that meet the requirements of Section 3 below in an amount equal to the Average Daily Volume (ADM) of net .com new adds as averaged over the course of the previous three months times the Planned Duration Overage (PDO) in minutes times the SLA Credit graduated financial penalty set forth in Table Credit Level 6. For purposes of this Appendix 10, PDO is calculated by subtracting the maximum allowable time in hours and minutes for a Planned Outage Duration or Extended Planned Outage Duration, as applicable, from the total outage in hours and minutes.

Table Credit Level 6

1 to <15 minutes

15 minutes to <1 hour

1 to <3 hours

3 –to <6 hours

≥ 6 hours

SLA Credit

ADM*PDO*$0.25

ADM*PDO*$0.5

ADM*PDO*$1

ADM*PDO*$1.50

ADM*PDO*$2

3. Registrar Responsibilities.

In order for ICANN-Accredited Registrars to claim SLA Credits outlined in this Appendix 10, the procedures of this Section 3 must be strictly followed.

3.1 The affected ICANN-Accredited Registrar must report each occurrence of alleged failure by Registry Operator to meet a Performance Specification and make a request for SLA Credit to the Registry Operator's customer service help desk in the manner required by the Registry Operator (i.e., e-mail, fax, telephone) in order to be eligible for a SLA Credit. An affected ICANN Accredited Registrar must initiate a request for SLA Credits within three months of the end of the calendar year in which the failure to meet a Performance Specification occurred.

3.2 Each ICANN-Accredited Registrar must inform the Registry Operator any time its estimated volume of transactions (excluding check domain commands) is expected to exceed the ICANN-Accredited Registrar's previous month's volume by more than 25%. In the event that an ICANN-Accredited Registrar fails to inform Registry Operator of a forecasted increase of volume of transactions of 25% or more and the ICANN-Accredited Registrar's volume increases 25% or more over the previous month, and should the total volume of transactions for the Registry Operator for all ICANN-Accredited Registrars for that month exceed the Registry Operator's actual volume of the previous month's transactions by more than 20%, then the ICANN-

112

Accredited Registrar will not be eligible for any SLA Credits outlined in this SLA in that Monthly Timeframe. An ICANN-Accredited Registrar shall provide such forecast at least 30 days prior to the first day of the applicable calendar month. Registry Operator agrees to provide monthly transaction summary reports to ICANN-Accredited Registrars via e-mail.

3.3 The affected ICANN-Accredited Registrar must provide documentation to support its claim for a SLA Credit. An ICANN-Accredited Registrar shall provide documentation in the form of either:

a) ICANN-Accredited Registrar initiated notification(s) to the Registry Operator of a Performance Specification that exceeded SLA limits or failed to meet SLA requirements, including the trouble ticket number issued by the Registry Operator. The closing ticket(s) should be included as well in order to determine the total downtime (unless the trouble ticket includes this); or

b) Notification from the Registry Operator (with trouble ticket number attached) of a Performance Specification that exceeded SLA limits or failed to meet SLA requirements. The closing ticket(s) should be included as well in order to determine the total downtime (unless the trouble ticket includes this).

3.4 In order to calculate credits, the affected ICANN-Accredited Registrar must include volume figures for the past three (3) calendar months (or, if less, such amount of time that the ICANN-Accredited Registrar has been authorized to register names in the .com registry) and a certification that these numbers accurately reflect the minimum number of registrations that would be covered during the affected period.

3.5 Registry Operator shall perform the required measurements in order to corroborate the total SLA Credits requested by ICANN-Accredited Registrar. Such measurements and associated documentation shall be delivered by e-mail to each of the ICANN-Accredited Registrars requesting a SLA Credit.

3.6 When the above steps have been accurately completed, Registry Operator shall provide notification of the number of SLA Credits that will be entered in the affected ICANN-Accredited Registrar's account that can be used immediately toward .com domain name registrations and other fees owed to Registry Operator by the ICANN-Accredited Registrar.

4. Obligations.

4.1 Except in the case of cross-network name server performance (which is not a subject of this Service Level Agreement), Registry Operator will perform monitoring from at least two external locations and a minimum of one internal location as a means to verify that a) sessions can effectively be established and b) EPP commands can be successfully completed.

4.2 In the event that all ICANN-Accredited Registrars are affected by a SRS unavailability, the Registry Operator is responsible for opening a blanket trouble ticket and immediately notifying all ICANN-Accredited Registrars of the trouble ticket number and details.

4.3 In the event that the System Services are unavailable to an individual ICANN-Accredited Registrar, Registry Operator will use commercially reasonable efforts to re-establish the affected System Services for such ICANN-Accredited Registrar as soon as reasonably practicable. Any System Services unavailability attributable to any individual ICANN-Accredited Registrar that

113

does not represent a System Services outage will not result in SLA Credits or be subject to this SLA.

4.4 ICANN-Accredited Registrar(s) and the Registry Operator agree to use reasonable commercial good faith efforts to establish the cause of any alleged System Services unavailability. If it is mutually determined to be a Registry Operator problem, the System Services unavailability will be subject to this SLA.

4.5 The Registry Operator will use commercially reasonable efforts to restore any System Services within 24 hours after the termination of a force majeure event and restore full system functionality within 48 hours after the termination of a force majeure event. Outages due to a force majeure will not be considered System Services unavailability, impact the Performance Specifications set forth in Appendix 7, or be subject to this SLA.

4.6 The Registry Operator will open incident trouble tickets within a commercially reasonable period of time and will treat all system performance problems in order of decreasing severity and fix them within a commercially reasonable period of time. Incidents flagged by the measurement system will also qualify as ticketed events and will be subject to this SLA.

4.7 The Registry Operator will publish monthly system performance and Service Availability reports.

5. Miscellaneous.

5.1 This SLA is independent of any rights, obligations or duties set forth in the Registry Agreement. In the event of any conflict between the terms and conditions of this SLA and the Registry Agreement, the Registry Agreement shall control.

5.2 As an addendum to the Registry-Registrar Agreement ("RRA"), no provision in this SLA is intended to replace any term or condition in the RRA.

5.3 Dispute Resolution will be handled per RRA Section 6.7.

5.4 Any interruption of System Services that occurs, as a direct result of RRA Sections 2.13 (Resolution of Technical Problems or Breach of Agreement), 5.4 (Non-Payment of Fees), or 6.3 (Force Majeure) or any other applicable provision within the RRA or Registry Operator's compliance with any Consensus Policy established after the Effective Date, will not be subject to this SLA, but only to the extent and for so long as such interruption of System Services is unavoidable by commercially reasonable efforts due to Registry Operator's compliance with such provisions within the RRA or any Consensus Policy established after the Effective Date.

114

.com Registry Agreement Appendix 11

Public Interest Commitments

Registry Operator agrees to perform the following public interest commitments.

a.Registry Operator will ensure that there is a provision in its Registry-Registrar Agreement that requires registrars to include in their registration agreements a provision prohibiting Registered Name Holders from distributing malware, abusively operating botnets, phishing, piracy, trademark or copyright infringement, fraudulent or deceptive practices, counterfeiting or otherwise engaging in activity contrary to applicable law, and providing (consistent with applicable law and any related procedures) consequences (to be enforced by the applicable registrar in accordance with such registrar’s Registrar Accreditation Agreement) for such activities, including suspension of the domain name.

b.Registry Operator will periodically, but no less frequently than on a monthly basis, conduct a technical analysis to assess whether domains in the TLD are being used to perpetrate DNS Abuse. Registry Operator will maintain statistical reports on identified DNS Abuse and the actions taken as a result of the periodic technical analysis. Registry Operator will maintain these reports for the current Term of the Agreement unless a shorter period is required by law or approved by ICANN, and will provide them to ICANN upon request.

c. DNS Abuse Mitigation. Where Registry Operator reasonably determines, based on actionable evidence, that a registered domain name in the TLD is being used for DNS Abuse, Registry Operator must promptly take the appropriate mitigation action(s) that are reasonably necessary to contribute to stopping, or otherwise disrupting, the domain name from being used for DNS Abuse. Such action(s) shall, at a minimum, include: (i) the referral of the domains being used for the DNS Abuse, along with relevant evidence, to the sponsoring registrar; or (ii) the taking of direct action, by Registry Operator, where Registry Operator deems appropriate. Action(s) may vary depending on the circumstances of each case, taking into account the severity of the harm from the DNS Abuse and the possibility of associated collateral damage. For the purposes of this Agreement, “DNS Abuse” is defined as malware, botnets, phishing, pharming, and spam (when spam serves as a delivery mechanism for the other forms of DNS Abuse listed in this definition) as those terms are defined in Section 2.1 of SAC115 (March 19, 2021) <▇▇▇▇▇://▇▇▇.▇▇▇▇▇.▇▇▇/▇▇/▇▇▇▇▇▇/▇▇▇▇▇/▇▇▇▇▇/▇▇▇-▇▇▇-▇▇.▇▇▇>).

d. Incident Reporting. Registry Operator will give ICANN notice within seventy-two (72) hours of Registry Operator’s discovery of any cyber incident, physical intrusion or infrastructure damages concerning the registry system for the TLD that significantly jeopardizes, or is reasonably likely to significantly jeopardize, the integrity, confidentiality or availability of the registry system such as significant:

115

accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to registrar account information, registration data, DNSSEC cryptographic private keys, or other information assets critical to the operation of the registry system. The notice required pursuant to this Section shall include, to the extent known by the Registry Operator after a reasonable investigation, a detailed description of the cyber incident, physical intrusion or infrastructure damages including how it occurred, the registry system impacted, the likely impacts to registrars or registrants, if any, the number of registrars, domain names, and registrants affected, and the actions taken by Registry Operator in response to the cyber incident, physical intrusion or infrastructure damages. If such information is not available initially, Registry Operator shall provide such information when it becomes available without undue delay. ICANN shall not disclose the notice given pursuant to this Section in any manner, absent prior written consent from Registry Operator, or except as required by law or necessary to preserve the security, stability and resiliency of the Internet, in which case disclosure by ICANN shall be limited to the relevant authority or authorities.

e. Network Ingress Filtering. Registry Operator shall implement network ingress filtering checks for its Registry Services as described in BCP 38 and BCP 84, which ICANN will also implement.

116

COM Registry Agreement (1 December 2024) REGISTRY AGREEMENT

Document Metadata

Document Metadata

Table of Contents