2017 GLOBAL AMENDMENT TO REGISTRY AGREEMENTS
This 2017 Global Amendment to Registry Agreements (this “2017 Amendment”), effective as of 31 July 2017, amends the registry agreements listed on Schedule A (the “Applicable Registry Agreements”) entered into between Internet Corporation for Assigned Names and Numbers, a California nonprofit public benefit corporation (“ICANN”), and the Applicable Registry Operators party to such Applicable Registry Agreements. This 2017 Amendment is made and is effective pursuant to Section 7.7 of the Applicable Registry Agreements. Capitalized terms used and not defined in this Amendment will have the respective meanings given thereto in the Applicable Registry Agreements.
WHEREAS, the Applicable Registry Agreements may be amended pursuant to the requirements of and process set forth in Section 7.7 of the Applicable Registry Agreements;
WHEREAS, ICANN and the Working Group have consulted in good faith regarding the form and substance of this 2017 Amendment;
WHEREAS, ICANN has publicly posted this 2017 Amendment on its website for no less than 30 calendar days and has provided notice of this 2017 Amendment to the Applicable Registry Operators in accordance with Section 7.9 of the Registry Agreements;
WHEREAS, ICANN and the Working Group have considered the public comments submitted on this 2017 Amendment during the Posting Period;
WHEREAS, on 18 May 2017, this 2017 Amendment was approved by the ICANN Board of Directors;
WHEREAS, on 10 April 2017, this 2017 Amendment received Registry Operator Approval;
WHEREAS, on 1 June 2017, ICANN provided the Registry Operators with notice that this 2017 Amendment was an Approved Amendment (the “2017 Amendment Notice Date”); and
WHEREAS, pursuant to Section 7.7(d)(iv) of the Registry Agreements, this 2017 Amendment will, without any further action by ICANN or the Registry Operators, be effective and deemed an amendment to the Applicable Registry Agreements on 31 July 2017 (the “2017 Amendment Effective Date”), the date that is 60 calendar days from the 2017 Amendment Notice Date.
NOW, THEREFORE, in consideration of the above recitals acknowledged herein by reference, this 2017 Amendment will be deemed an effective amendment to each of the Applicable Registry Agreements as of the 2017 Amendment Effective Date.
1. Section 2.3 is hereby amended and restated in its entirety as follows:
2.3 Data Escrow. Registry Operator shall comply with the registry data escrow procedures set forth in Specification 2 attached hereto (“Specification 2”) within fourteen (14) calendar days after delegation.
2. Section 2.4 is hereby amended and restated in its entirety as follows:
2.4 Monthly Reporting. Within twenty (20) calendar days following the end of each calendar month, commencing with the first calendar month in which the TLD is delegated in the root zone, Registry Operator shall deliver to ICANN reports in the format set forth in Specification 3 attached hereto (“Specification 3”); provided, however, that if the TLD is delegated in the root zone after the fifteenth (15th) calendar day of the calendar month, Registry Operator may defer the delivery of the reports for such first calendar month and instead deliver to ICANN such month’s reports no later than the time that Registry Operator is required to deliver the reports for the immediately following calendar month. Registry Operator must include in the Per-Registrar Transactions Report any domain name created during pre-delegation testing that has not been deleted as of the time of delegation (notably but not limited to domains registered by Registrar IDs 9995 and/or 9996).
3. Section 2.9(a) is hereby amended and restated in its entirety as follows:
(a) All domain name registrations in the TLD must be registered through an ICANN accredited registrar; provided, that Registry Operator need not use a registrar if it registers names in its own name in order to withhold such names from delegation or use in accordance with Section 2.6. Subject to the requirements of Specification 11, Registry Operator must provide non-discriminatory access to Registry Services to all ICANN accredited registrars that enter into and are in compliance with the registry-registrar agreement for the TLD; provided that Registry Operator may establish non-discriminatory criteria for qualification to register names in the TLD that are reasonably related to the proper functioning of the TLD. Registry Operator must use a uniform non-discriminatory agreement with all registrars authorized to register names in the TLD (the “Registry-Registrar Agreement”). Registry Operator may amend the Registry-Registrar Agreement from time to time; provided, however, that any material revisions thereto must be approved by ICANN before any such revisions become effective and binding on any registrar. Registry Operator will provide ICANN and all registrars authorized to register names in the TLD at least fifteen (15) calendar days written notice of any revisions to the Registry-Registrar Agreement before any such revisions become effective and binding on any registrar. During such period, ICANN will determine whether such proposed revisions are immaterial, potentially material or material in nature. If ICANN has not provided Registry Operator with notice of its determination within such fifteen (15) calendar-day period, ICANN shall be deemed to have determined that such proposed revisions are immaterial in nature. If ICANN determines, or is deemed to have determined under this Section 2.9(a), that such revisions are immaterial, then Registry Operator may adopt and implement such revisions. If ICANN determines such revisions are either material or potentially material, ICANN will thereafter follow its procedure regarding review and approval of changes to Registry-Registrar Agreements at <http://www.icann.org/en/resources/registries/rra-amendment-procedure>, and such revisions may not be adopted and implemented until approved by ICANN. Notwithstanding the foregoing provisions of this Section 2.9(a), any change to the Registry-Registrar Agreement that relates exclusively to the fee charged by Registry Operator to register domain names in the TLD will not be subject to the notice and approval process specified in this Section 2.9(a), but will be subject to the requirements in Section 2.10 below.
4. Section 2.10(a) is hereby amended and restated in its entirety as follows:
(a) With respect to initial domain name registrations, Registry Operator shall provide each ICANN accredited registrar that has executed the Registry-Registrar Agreement for the TLD advance written notice of any price increase (including as a result of the elimination of any refunds, rebates, discounts, product tying or other programs which had the effect of reducing the price charged to registrars, unless such refunds, rebates, discounts, product tying or other programs are of a limited duration that is clearly and conspicuously disclosed to the registrar when offered) of no less than thirty (30) calendar days. Registry Operator shall offer registrars the option to obtain initial domain name registrations for periods of one (1) to ten (10) years at the discretion of the registrar, but no greater than ten (10) years.
5. Section 2.10(b) is hereby amended and restated in its entirety as follows:
(b) With respect to renewal of domain name registrations, Registry Operator shall provide each ICANN accredited registrar that has executed the Registry-Registrar Agreement for the TLD advance written notice of any price increase (including as a result of the elimination of any refunds, rebates, discounts, product tying, Qualified Marketing Programs or other programs which had the effect of reducing the price charged to registrars) of no less than one hundred eighty (180) calendar days. Notwithstanding the foregoing sentence, with respect to renewal of domain name registrations: (i) Registry Operator need only provide thirty (30) calendar days notice of any price increase if the resulting price is less than or equal to (A) for the period beginning on the Effective Date and ending twelve (12) months following the Effective Date, the initial price charged for registrations in the TLD, or (B) for subsequent periods, a price for which Registry Operator provided a notice pursuant to the first sentence of this Section 2.10(b) within the twelve (12) month period preceding the effective date of the proposed price increase; and (ii) Registry Operator need not provide notice of any price increase for the imposition of the Variable Registry-Level Fee set forth in Section 6.3. Registry Operator shall offer registrars the option to obtain domain name registration renewals at the current price (i.e., the price in place prior to any noticed increase) for periods of one (1) to ten (10) years at the discretion of the registrar, but no greater than ten (10) years.
6. Section 2.18 is hereby amended and restated in its entirety as follows:
2.18 Personal Data. Registry Operator shall (i) notify each ICANN-accredited registrar that is a party to the Registry-Registrar Agreement for the TLD of the purposes for which data about any identified or identifiable natural person (“Personal Data”) submitted to Registry Operator by such registrar is collected and used under this Agreement or otherwise and the intended recipients (or categories of recipients) of such Personal Data, and (ii) require such registrar to obtain the consent of each registrant in the TLD for such collection and use of Personal Data. Registry Operator shall take reasonable steps to protect Personal Data collected from such registrar 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.
7. Section 4.3(d) is hereby amended and restated in its entirety as follows:
(d) ICANN may, upon notice to Registry Operator, terminate this Agreement if (i) Registry Operator makes an assignment for the benefit of creditors or similar act, (ii) attachment, garnishment or similar proceedings are commenced against Registry Operator, which proceedings are a material threat to Registry Operator’s ability to operate the registry for the TLD, and are not dismissed within sixty (60) calendar days of their commencement, (iii) a trustee, receiver, liquidator or equivalent is appointed in place of Registry Operator or maintains control over any of Registry Operator’s property, (iv) execution is levied upon any material property of Registry Operator that, if levied, would reasonably be expected to materially and adversely affect Registry Operator’s ability to operate the registry for the TLD, (v) proceedings are instituted by or against Registry Operator under any bankruptcy, insolvency, reorganization or other laws relating to the relief of debtors and such proceedings are not dismissed within sixty (60) calendar days of their commencement (if such proceedings are instituted by Registry Operator or its Affiliates) or one hundred and eighty (180) calendar days of their commencement (if such proceedings are instituted by a third party against Registry Operator), or (vi) Registry Operator files for protection under the United States Bankruptcy Code, 11 U.S.C. Section 101, et seq., or a foreign equivalent or liquidates, dissolves or otherwise discontinues its operations or the operation of the TLD.
8. Section 4.3(e) is hereby amended and restated in its entirety as follows:
(e) ICANN may, upon thirty (30) calendar days’ notice to Registry Operator, terminate this Agreement pursuant to a determination by any PDDRP panel or RRDRP panel under Section 2 of Specification 7 or a determination by any PICDRP panel under Section 2, Section 3 or any other applicable Section of Specification 11, subject to Registry Operator’s right to challenge such termination as set forth in the applicable procedure described therein.
9. Unless the Applicable Registry Operator was determined by ICANN at the time of execution of an Applicable Registry Agreement to be an intergovernmental organization or governmental entity or other special circumstances entity, Section 5.2 is hereby amended and restated in its entirety as follows:
5.2 Arbitration. Disputes arising under or in connection with this Agreement that are not resolved pursuant to Section 5.1, including requests for specific performance, will be resolved through binding arbitration conducted pursuant to the rules of the International Court of Arbitration of the International Chamber of Commerce (the “ICC”). The arbitration will be conducted in the English language and will occur in Los Angeles County, California. Any arbitration will be in front of a single arbitrator, unless (i) ICANN is seeking punitive or exemplary damages, or operational sanctions, (ii) the parties agree in writing to a greater number of arbitrators, or (iii) the dispute arises under Section 7.6 or 7.7. In the case of clauses (i), (ii) or (iii) in the preceding sentence, the arbitration will be in front of three arbitrators with each party nominating one arbitrator for confirmation by the ICC and the two selected arbitrators nominating the third arbitrator for confirmation by the ICC. For an arbitration in front of a sole arbitrator, Registry Operator and ICANN may, by mutual agreement, nominate the sole arbitrator for confirmation by the ICC. If the parties fail to nominate a sole arbitrator or, in the case of an arbitration in front of three arbitrators, either party fails to nominate an arbitrator, in each case within thirty (30) calendar days from the date when a party’s request for arbitration has been received by the other party, or within such additional time as may be allowed by the Secretariat of the Court of the ICC, the arbitrator(s) shall be appointed by the ICC. If any nominated arbitrator is not confirmed by the ICC, the party or persons that appointed such arbitrator shall promptly nominate a replacement arbitrator for confirmation by the ICC. In order to expedite the arbitration and limit its cost, the arbitrator(s) shall establish page limits for the parties’ filings in conjunction with the arbitration, and should the arbitrator(s) determine that a hearing is necessary, the hearing shall be limited to one (1) calendar day, provided that in any arbitration in which ICANN is seeking punitive or exemplary damages, or operational sanctions, the hearing may be extended for one (1) additional calendar day if agreed upon by the parties or ordered by the arbitrator(s) based on the arbitrator(s) independent determination or the reasonable request of one of the parties thereto. The prevailing party in the arbitration will have the right to recover its costs and reasonable attorneys’ fees, which the arbitrator(s) shall include in the awards. In the event the arbitrators determine that Registry Operator has been repeatedly and willfully in fundamental and material breach of its obligations set forth in Article 2, Article 6 or Section 5.4 of this Agreement, ICANN may request the arbitrators award punitive or exemplary damages, or operational sanctions (including without limitation an order temporarily restricting Registry Operator’s right to sell new registrations). Each party shall treat information received from the other party pursuant to the arbitration that is appropriately marked as confidential (as required by Section 7.15) as Confidential Information of such other party in accordance with Section 7.15. In any litigation involving ICANN concerning this Agreement, jurisdiction and exclusive venue for such litigation will be in a court located in Los Angeles County, California; however, the parties will also have the right to enforce a judgment of such a court in any court of competent jurisdiction.
10. If the Applicable Registry Operator was determined by ICANN at the time of execution of an Applicable Registry Agreement to be an intergovernmental organization or governmental entity or other special circumstances entity, Section 5.2 is hereby amended and restated in its entirety as follows:
5.2 Arbitration. Disputes arising under or in connection with this Agreement that are not resolved pursuant to Section 5.1, including requests for specific performance, will be resolved through binding arbitration conducted pursuant to the rules of the International Court of Arbitration of the International Chamber of Commerce (the “ICC”). The arbitration will be conducted in the English language and will occur in Geneva, Switzerland, unless another location is mutually agreed upon by Registry Operator and ICANN. Any arbitration will be in front of a single arbitrator, unless (i) ICANN is seeking punitive or exemplary damages, or operational sanctions, (ii) the parties agree in writing to a greater number of arbitrators, or (iii) the dispute arises under Section 7.6 or 7.7. In the case of clauses (i), (ii) or (iii) in the preceding sentence, the arbitration will be in front of three arbitrators with each party nominating one arbitrator for confirmation by the ICC and the two selected arbitrators nominating the third arbitrator for confirmation by the ICC. For an arbitration in front of a sole arbitrator, Registry Operator and ICANN may, by mutual agreement, nominate the sole arbitrator for confirmation by the ICC. If the parties fail to nominate a sole arbitrator or, in the case of an arbitration in front of three arbitrators, either party fails to nominate an arbitrator, in each case within thirty (30) calendar days from the date when a party’s request for arbitration has been received by the other party, or within such additional time as may be allowed by the Secretariat of the Court of the ICC, the arbitrator(s) shall be appointed by the ICC. If any nominated arbitrator is not confirmed by the ICC, the party or persons that appointed such arbitrator shall promptly nominate a replacement arbitrator for confirmation by the ICC. In order to expedite the arbitration and limit its cost, the arbitrator(s) shall establish page limits for the parties’ filings in conjunction with the arbitration, and should the arbitrator(s) determine that a hearing is necessary, the hearing shall be limited to one (1) calendar day, provided that in any arbitration in which ICANN is seeking punitive or exemplary damages, or operational sanctions, the hearing may be extended for one (1) additional calendar day if agreed upon by the parties or ordered by the arbitrator(s) based on the arbitrator(s) independent determination or the reasonable request of one of the parties thereto. The prevailing party in the arbitration will have the right to recover its costs and reasonable attorneys’ fees, which the arbitrator(s) shall include in the awards. In the event the arbitrators determine that Registry Operator has been repeatedly and willfully in fundamental and material breach of its obligations set forth in Article 2, Article 6 or Section 5.4 of this Agreement, ICANN may request the arbitrators award punitive or exemplary damages, or operational sanctions (including without limitation an order temporarily restricting Registry Operator’s right to sell new registrations). Each party shall treat information received from the other party pursuant to the arbitration that is appropriately marked as confidential (as required by Section 7.15) as Confidential Information of such other party in accordance with Section 7.15. In any litigation involving ICANN concerning this Agreement, jurisdiction and exclusive venue for such litigation will be in a court located in Geneva, Switzerland, unless another location is mutually agreed upon by Registry Operator and ICANN; however, the parties will also have the right to enforce a judgment of such a court in any court of competent jurisdiction.”
11. Section 6.3(a) is hereby amended and restated in its entirety as follows:
(a) If the ICANN accredited registrars (accounting, in the aggregate, for payment of two-thirds of all registrar-level fees (or such portion of ICANN accredited registrars necessary to approve variable accreditation fees under the then-current registrar accreditation agreement), do not approve, pursuant to the terms of their registrar accreditation agreements with ICANN, the variable accreditation fees established by the ICANN Board of Directors for any ICANN fiscal year, upon delivery of notice from ICANN, Registry Operator shall pay to ICANN a variable registry-level fee, which shall be paid on a fiscal quarter basis, and shall accrue as of the beginning of the first fiscal quarter of such ICANN fiscal year (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 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 may invoice and collect the Variable Registry-Level Fees from the registrars that are party to a Registry-Registrar Agreement with Registry Operator (which agreement may specifically provide for the reimbursement of Variable Registry-Level Fees paid by Registry Operator pursuant to this Section 6.3); provided, that the fees shall be invoiced to all ICANN accredited registrars if invoiced to any. The Variable Registry-Level Fee, if collectible by ICANN, shall be an obligation of Registry Operator and shall be due and payable as provided in this Section 6.3 irrespective of Registry Operator’s ability to seek and obtain reimbursement of such fee from registrars. In the event ICANN later collects variable accreditation fees for which Registry Operator has paid ICANN a Variable Registry-Level Fee, ICANN shall reimburse the Registry Operator an appropriate amount of the Variable Registry-Level Fee, as reasonably determined by ICANN. If the ICANN accredited registrars (as a group) do approve, pursuant to the terms of their registrar accreditation agreements with ICANN, the variable accreditation fees established by the ICANN Board of Directors for a fiscal year, ICANN shall not be entitled to a Variable-Level Fee hereunder for such fiscal year, irrespective of whether the ICANN accredited registrars comply with their payment obligations to ICANN during such fiscal year.
12. A new Section 6.7 is hereby added as follows:
6.7 Fee Reduction Waiver. In ICANN’s sole discretion, ICANN may reduce the amount of registry fees payable hereunder by Registry Operator for any period of time (“Fee Reduction Waiver”). Any such Fee Reduction Waiver may, as determined by ICANN in its sole discretion, be (a) limited in duration and (b) conditioned upon Registry Operator’s acceptance of the terms and conditions set forth in such waiver. A Fee Reduction Waiver shall not be effective unless executed in writing by ICANN as contemplated by Section 7.6(i). ICANN will provide notice of any Fee Reduction Waiver to Registry Operator in accordance with Section 7.9.
13. Section 7.5(f) is hereby amended and restated in its entirety as follows:
(f) Notwithstanding the foregoing, (i) any consummated change of control shall not be voidable by ICANN; provided, however, that, if ICANN reasonably determines to withhold its consent to such transaction, ICANN may terminate this Agreement pursuant to Section 4.3(g), (ii) ICANN may assign this Agreement without the consent of Registry Operator upon approval of the ICANN Board of Directors in conjunction with a reorganization, reconstitution or re-incorporation of ICANN upon such assignee’s express assumption of the terms and conditions of this Agreement, (iii) Registry Operator may assign this Agreement without the consent of ICANN directly to an Affiliated Assignee, as that term is defined herein below, upon such Affiliated Assignee’s express written assumption of the terms and conditions of this Agreement, and (iv) ICANN shall be deemed to have consented to any assignment, Material Subcontracting Arrangement or change of control transaction in which the Contracting Party is an existing operator of a generic top-level domain pursuant to a registry agreement between such Contracting Party and ICANN (provided that such Contracting Party is then in compliance with the terms and conditions of such registry agreement in all material respects), unless ICANN provides to Registry Operator a written objection to such transaction within ten (10) calendar days of ICANN’s receipt of notice of such transaction pursuant to this Section 7.5. Notwithstanding Section 7.5(a), in the event an assignment is made pursuant to clauses (ii) or (iii) of this Section 7.5(f), the assigning party will provide the other party with prompt notice following any such assignment. For the purposes of this Section 7.5(f), (A) “Affiliated Assignee” means a person or entity that, directly or indirectly, through one or more intermediaries, controls, is controlled by, or is under common control with, the person or entity specified, and (B) “control” (including the terms “controlled by” and “under common control with”) shall have the same meaning specified in Section 2.9(c) of this Agreement.
14. If Exhibit A of the Applicable Registry Agreement contains the following language:
“X. “DNS Service – TLD Zone Contents
Notwithstanding anything else in this Agreement, as indicated in section 2.2.3.3 of the gTLD Applicant Guidebook, permissible contents for the TLD’s zone are:
X.1 Apex SOA record
X.2 Apex NS records and in-bailiwick glue for the TLD’s DNS servers
X.3 NS records and in-bailiwick glue for DNS servers of registered names in the TLD
X.4 DS records for registered names in the TLD
X.5 Records associated with signing the TLD zone (i.e., RRSIG, DNSKEY, NSEC, and NSEC3)
(Note: The above language effectively does not allow, among other things, the inclusion of DNS resource records that would enable a dotless domain name (e.g., apex A, AAAA, MX records) in the TLD zone.)
If Registry Operator wishes to place any DNS resource record type into its TLD DNS zone (other than those listed in Sections 1.1 through 1.5 above), it must describe in detail its proposal and submit a Registry Services Evaluation Process (RSEP) request. This will be evaluated per RSEP to determine whether the service would create a risk of a meaningful adverse impact on security or stability of the DNS. Registry Operator recognizes and acknowledges that a service based on the use of less-common DNS resource records in the TLD zone, even if approved, might not work as intended for all users due to lack of software support.”,
such provision is hereby amended and restated in its entirety as follows (with “X” meaning the applicable number for such provision in the Applicable Registry Agreement):
X. DNS Service – TLD Zone Contents
X.1. For the “Internet” (IN) Class:
X.1.2. Apex NS records and in-bailiwick glue for the TLD’s DNS servers
X.1.3. NS records and in-bailiwick glue for DNS servers of registered names in the TLD
X.1.4. DS records for registered names in the TLD
X.1.5. Records associated with signing the TLD zone (e.g., RRSIG, DNSKEY, NSEC, NSEC3PARAM and NSEC3)
X.1.6. Apex TXT record for zone versioning purposes
X.1.7. Apex TYPE65534 record for automatic dnssec signing signaling
X.2. For the “Chaos” (CH) Class:
X.2.1. TXT records for server version/identification (e.g., TXT records for “version.bind.”, “id.server.”, “authors.bind” and/or “hostname.bind.”)
15. Section 1.2(a) of Part A of Specification 2 is hereby amended and restated in its entirety as follows:
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 as of 00:00:00 UTC of each day, but Sunday. 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).
16. Section 5.3 of Part A of Specification 2 is hereby amended and restated in its entirety as follows:
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 3 of Specification 4;
(4) "thick-{gurid}", if the data represent Thick Registration Data from a specific registrar, as defined in Section 3.2 of Specification 4. The {gurid} element must be replaced with the IANA Registrar ID associated with the data.
17. Section 7 of Part A of Specification 2 is hereby amended and restated in its entirety as follows:
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-lozano-icann-registry-interfaces, see Part A, Section 9, reference 5 of this Specification (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 the 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 Part A, Section 9, reference 1 of this Specification.
If not already an RFC, Registry Operator will use the most recent draft version of the Interface Specification at the Effective Date. Registry Operator may at its election use newer versions of the Interface Specification after the Effective Date. 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.
18. Section 8 of Part A of Specification 2 is hereby amended and restated in its entirety as follows:
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 Part A, Section 9, reference 1 of this Specification.
5. The data escrow agent extended verification process, as defined below in reference 2 of Part A of this Specification 2, 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.
19. Field # 02, 34 and 35 of Section 1 of Specification 3 is hereby amended and restated in their entirety as follows:
Field # |
Field name |
Description |
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 (as described in Specification 5), otherwise the sponsoring Registrar IANA id should be used as specified in http://www.iana.org/assignments/registrar-ids |
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 |
20. Section 2 of Specification 3 is hereby amended and restated in its entirety as follows:
2. 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 “gTLD-activity-yyyymm.csv”, where “gTLD” is the gTLD name; in case of an IDN-TLD, the A-label shall be used; “yyyymm” is the year and month being reported. 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, if offered |
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 |
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 gTLDs that are part of a single-instance Shared Registry System, the Registry Functions Activity Report may include the total contact or host transactions for all the gTLDs in the system.
21. Section 1.7.1 of Specification 4 is hereby amended and restated in its entirety as follows:
1.71 Query format: whois “nameserver (nameserver name)”, or whois “nameserver (IP Address).” For example: whois “nameserver NS1.EXAMPLE.TLD”.
22. Section 1.10.3 of Specification 4 is hereby amended and restated in its entirety as follows:
1.10.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).
23. Section 2.1.3 of Specification 4 is hereby amended and restated in its entirety as follows:
2.1.3 Grant 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>.zda.icann.org 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.
24. Section 2.1.4 of Specification 4 is hereby amended and restated in its entirety as follows:
2.1.4 File 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.
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.
13. No use of parentheses, e.g., to continue the list of fields in a record across a line boundary.
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.
25. Section 2.1.5 of Specification 4 is hereby amended and restated in its entirety as follows:
2.1.5 Use 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.
26. Section 3.1.1 of Specification 4 is hereby amended and restated in its entirety as follows:
3.1.1 Contents. Registry Operator will provide, at least, 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, at least, it will provide: registrar name, registrar id (IANA ID), hostname of registrar Whois server, and URL of registrar.
27. Section 3 of Specification 5 is hereby amended and restated in its entirety as follows:
3. Reservations for Registry Operations.
3.1 The following ASCII labels must be withheld from registration or allocated to Registry Operator at All Levels for use in connection with the operation of the registry for the TLD: WWW, RDDS and WHOIS. The following ASCII label must be allocated to Registry Operator upon delegation into the root zone at All Levels for use in connection with the operation of the registry for the TLD: NIC. Registry Operator may activate WWW, RDDS and WHOIS in the DNS, but must activate NIC in the DNS, as necessary for the operation of the TLD (in accordance with the provisions of Exhibit A, the ASCII label NIC must be provisioned in the DNS as a zone cut using NS resource records). None of WWW, RDDS, WHOIS or NIC may be released or registered to any person (other than Registry Operator) or third party. Upon conclusion of Registry Operator’s designation as operator of the registry for the TLD all such withheld or allocated names shall be transferred as specified by ICANN. Registry Operator may self-allocate and renew such names without use of an ICANN accredited registrar, which will not be considered Transactions for purposes of Section 6.1 of the Agreement. Such domains shall be identified by Registrar ID 9999.
3.1.1 If Exhibit A to the Agreement specifically provides that Registry Operator may offer registration of IDNs, Registry Operator may also activate a language-specific translation or transliteration of the term "NIC" or an abbreviation for the translation of the term "Network Information Center" in the DNS in accordance with Registry Operator’s IDN Tables and IDN Registration Rules. Such translation, transliteration or abbreviation may be reserved by Registry Operator and used in addition to the label NIC to provide any required registry functions. For the avoidance of doubt, Registry Operator is required to activate the ASCII label NIC pursuant to Section 3.1 of this Specification 3.
3.2 Registry Operator may activate in the DNS at All Levels up to one hundred (100) names (plus their IDN variants, where applicable) necessary for the operation or the promotion of the TLD. Registry Operator must act as the Registered Name Holder of such names as that term is defined in the then-current ICANN Registrar Accreditation Agreement (RAA). These activations will be considered Transactions for purposes of Section 6.1 of the Agreement. Registry Operator must either (i) register such names through an ICANN accredited registrar; or (ii) self-allocate such names and with respect to those names submit to and be responsible to ICANN for compliance with ICANN Consensus Policies and the obligations set forth in Subsections 3.7.7.1 through 3.7.7.12 of the then-current RAA (or any other replacement clause setting out the terms of the registration agreement between a registrar and a registered name holder). If Registry Operator chooses option (ii) above, it shall identify these transactions using Registrar ID 9998. At Registry Operator’s discretion and in compliance with all other terms of this Agreement, including the RPMs set forth in Specification 7, such names may be released for registration to another person or entity.
3.3 Registry Operator may withhold from registration or allocate to Registry Operator names (including their IDN variants, where applicable) at All Levels in accordance with Section 2.6 of the Agreement. Such names may not be activated in the DNS, but may be released for registration to Registry Operator or another person or entity at Registry Operator’s discretion, subject to compliance with all the terms of this Agreement, including applicable RPMs set forth in Specification 7. Upon conclusion of Registry Operator’s designation as operator of the registry for the TLD, all such names that remain withheld from registration or allocated to Registry Operator shall be transferred as specified by ICANN. Upon ICANN’s request, Registry Operator shall provide a listing of all names withheld or allocated to Registry Operator pursuant to Section 2.6 of the Agreement. Registry Operator may self-allocate and renew such names without use of an ICANN accredited registrar, which will not be considered Transactions for purposes of Section 6.1 of the Agreement.
3.4 Effective upon the conclusion of the No-Activation Period specified in Section 6.1 of Specification 6, Registry Operator shall allocate the domain name "icann-sla-monitoring.<tld>" to the ICANN testing registrar (as such registrar is described in Section 8.2 of Specification 10). If such domain name is not available for registration in the TLD or is otherwise inconsistent with the registration policies of the TLD, Registry Operator may allocate a different domain name to the ICANN testing registrar in consultation with ICANN. The allocation of any such alternative domain name will be communicated to ICANN following such consultation. The allocation of the domain name "icann-sla-monitoring.<tld>" to the ICANN testing registrar will not (i) be considered a Transaction for purposes of Section 6.1 of the Agreement, (ii) count towards the one hundred domain names available to Registry Operator under Section 3.2 of this Specification 5, or (iii) adversely affect Registry Operator’s qualification as a .BRAND TLD pursuant to Specification 13 (.BRAND TLD Provisions) hereto (as applicable).
28. Section 1 of Specification 6 is hereby amended and restated in its entirety as follows:
1.1 DNS. Registry Operator shall comply with relevant existing RFCs and those published in the future by the Internet Engineering Task Force (IETF), including all successor standards, modifications or additions thereto relating to the DNS and name server operations including without limitation RFCs 1034, 1035, 1123, 1982, 2181, 2182, 3226, 3596, 3597, 4343, 5966 and 6891. DNS labels may only include hyphens in the third and fourth position if they represent valid IDNs (as specified above) in their ASCII encoding (e.g., “xn--ndk061n”).
1.2 EPP. Registry Operator shall comply with relevant existing RFCs and those published in the future by the Internet Engineering Task Force (IETF) including all successor standards, modifications or additions thereto relating to the provisioning and management of domain names using the Extensible Provisioning Protocol (EPP) in conformance with RFCs 5910, 5730, 5731, 5732 (if using host objects), 5733 and 5734. If Registry Operator implements Registry Grace Period (RGP), it will comply with RFC 3915 and its successors. If Registry Operator requires the use of functionality outside the base EPP RFCs, Registry Operator must document EPP extensions in Internet-Draft format following the guidelines described in RFC 3735. Registry Operator will provide and update the relevant documentation of all the EPP Objects and Extensions supported to ICANN prior to deployment.
1.3 DNSSEC. Registry Operator shall sign its TLD zone files implementing Domain Name System Security Extensions (“DNSSEC”). For the absence of doubt, Registry Operator shall sign the zone file of <TLD> and zone files used for in-bailiwick glue for the TLD’s DNS servers. During the Term, Registry Operator shall comply with RFCs 4033, 4034, 4035, 4509 and their successors, and follow the best practices described in RFC 6781 and its successors. 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. DNSSEC validation must be active and use the IANA DNS Root Key Signing Key set (available at https://www.iana.org/dnssec/files) as a trust anchor for Registry Operator’s Registry Services making use of data obtained via DNS responses.
1.4 IDN. 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 <http://www.icann.org/en/topics/idn/implementation-guidelines.htm>, 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.
1.5 IPv6. 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, 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. Registry Operator shall offer public IPv6 transport for its Registration Data Publication Services as defined in Specification 4 of this Agreement; e.g., Whois (RFC 3912), Web based Whois. Registry Operator shall offer public IPv6 transport for its Shared Registration System (SRS) to any Registrar, no later than six (6) months after receiving the first request in writing from a gTLD accredited Registrar willing to operate with the SRS over IPv6.
1.6 IANA Rootzone Database. 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 or WHOIS 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 or WHOIS records becomes outdated or inaccurate. Registry Operator must submit all change requests in accordance with the procedures set forth at <http://www.iana.org/domains/root>.
1.7 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.
29. Section 1 of Specification 7 is hereby amended and restated in its entirety as follows:
1. Rights Protection Mechanisms. Registry Operator shall implement and adhere to the rights protection mechanisms (“RPMs”) specified in this Specification. In addition to such RPMs, Registry Operator may develop and implement additional RPMs that discourage or prevent registration of domain names that violate or abuse another party’s legal rights. Registry Operator will include all RPMs required by this Specification 7 and any additional RPMs developed and implemented by Registry Operator in the Registry-Registrar Agreement entered into by ICANN-accredited registrars authorized to register names in the TLD. Registry Operator shall implement in accordance with requirements set forth therein each of the mandatory RPMs set forth in the Trademark Clearinghouse as of the date hereof, as posted at http://www.icann.org/en/resources/registries/tmch-requirements (the “Trademark Clearinghouse Requirements”), which may be revised in immaterial respects by ICANN from time to time. Registry Operator shall not mandate that any owner of applicable intellectual property rights use any other trademark information aggregation, notification, or validation service in addition to or instead of the ICANN-designated Trademark Clearinghouse. If there is a conflict between the terms and conditions of this Agreement and the Trademark Clearinghouse Requirements, the terms and conditions of this Agreement shall control. Registry Operator must enter into a binding and enforceable Registry-Registrar Agreement with at least one ICANN accredited registrar authorizing such registrar(s) to register domain names in the TLD as follows:
a. if Registry Operator conducts a Qualified Launch Program or is authorized by ICANN to conduct an Approved Launch Program (as those terms are defined in the Trademark Clearinghouse Requirements), Registry Operator must enter into a binding and enforceable Registry-Registrar Agreement with at least one ICANN accredited registrar prior to allocating any domain names pursuant to such Qualified Launch Program or Approved Launch Program, as applicable;
b. if Registry Operator does not conduct a Qualified Launch Program or is not authorized by ICANN to conduct an Approved Launch Program, Registry Operator must enter into a binding and enforceable Registry-Registrar Agreement with at least one ICANN accredited registrar at least thirty (30) calendar days prior to the expiration date of the Sunrise Period (as defined in the Trademark Clearinghouse Requirements) for the TLD; or
c. if this Agreement contains a Specification 13, Registry Operator must enter into a binding and enforceable Registry-Registrar Agreement with at least one ICANN accredited registrar prior to the Claims Commencement Date (as defined in Specification 13).
Nothing in this Specification 7 shall limit or waive any other obligations or requirements of this Agreement applicable to Registry Operator, including Section 2.9(a) and Specification 9.
30. Section 6 of Specification 10 is hereby amended and restated in its entirety as follows:
6. Emergency Thresholds
The following matrix presents the emergency thresholds that, if reached by any of the services mentioned above for a TLD, would cause the emergency transition of the Registry for the TLD as specified in Section 2.13 of this Agreement.
Critical Function |
Emergency Threshold |
DNS Service |
4-hour total downtime / week |
DNSSEC proper resolution |
4-hour total downtime / week |
EPP |
24-hour total downtime / week |
RDDS |
24-hour total downtime / week |
Data Escrow |
Reaching any of the criteria for the release of deposits described in Specification 2, Part B, Section 6.2 through Section 6.6. |
31. Section 8.2 of Specification 10 is hereby amended and restated in its entirety as follows:
8.2 ICANN testing registrar. Registry Operator agrees that ICANN will have a testing registrar used for purposes of measuring the SLRs described above. Registry Operator agrees to not provide any differentiated treatment for the testing registrar other than no billing of the transactions. ICANN shall not use the registrar for registering domain names (or other registry objects) for itself or others, except for the purposes of verifying contractual compliance with the conditions described in this Agreement. Registry Operator shall identify these transactions using Registrar ID 9997.
32. Section 9 of Specification 13 is hereby amended and restated in its entirety as follows:
9. Definitions.
9.1 “Applicable Brand Registry Agreements” means this Agreement and all other registry agreements that contain this Specification 13 between ICANN and the Applicable Brand Registry Operators.
9.2 “Applicable Brand Registry Operators” means, collectively, the registry operators of top-level domains party to a registry agreement that contains this Specification 13, including Registry Operator.
9.3 “.Brand TLDs” are TLDs where:
(i) the TLD string is identical to the textual elements protectable under applicable law, of a registered trademark valid under applicable law, which registered trademark:
a. is recorded with, and issued a signed data mark file by, the Trademark Clearinghouse or any successor or alternative trademark validation authority appointed by ICANN, if such trademark meets the eligibility requirements of such validation authority (provided that Registry Operator is not required to maintain such recordation for more than one year);
b. is owned and used by the Registry Operator or its Affiliate in the ordinary course of Registry Operator’s or its Affiliates’ business in connection with the offering of any of the goods and/or services claimed in the trademark registration;
c. was issued to Registry Operator or its Affiliate prior to the filing of its TLD registry application with ICANN;
d. is used throughout the Term continuously in the ordinary course of business of Registry Operator or its Affiliate in connection with the offering of any of the goods and/or services identified in the trademark registration;
e. does not begin with a period or a dot; and
f. is used by Registry Operator or its Affiliate in the conduct of one or more of its businesses that are unrelated to the provision of TLD Registry Services; and
(ii) only Registry Operator, its Affiliates or Trademark Licensees are registrants of domain names in the TLD and control the DNS records associated with domain names at any level in the TLD;
(iii) the TLD is not a Generic String TLD (as defined in Specification 11); and
(iv) Registry Operator has provided ICANN with an accurate and complete copy of such trademark registration.
9.4 “Brand Registry Operator Approval” means the receipt of each of the following: (i) the affirmative approval of the Applicable Brand Registry Operators whose payments to ICANN accounted for two-thirds of the total amount of fees (converted to U.S. dollars, if applicable, at the prevailing exchange rate published the prior day in the U.S. Edition of the Wall Street Journal for the date such calculation is made by ICANN) paid to ICANN by all the Applicable Brand Registry Operators during the immediately previous calendar year pursuant to the Applicable Brand Registry Agreements, and (ii) the affirmative approval of a majority of the Applicable Brand Registry Operators at the time such approval is obtained. For the avoidance of doubt, with respect to clause (ii), each Applicable Brand Registry Operator shall have one vote for each top-level domain operated by such Registry Operator pursuant to an Applicable Brand Registry Agreement.
9.5 “Trademark Licensee” means any corporation, partnership, limited liability company or similar legal entity (and not a person) that has a written trademark license agreement with Registry Operator or its Affiliate, for use of the registered trademark owned by Registry Operator or its Affiliate, the textual elements of which correspond exactly to the .Brand TLD string operated by Registry Operator, where:
(i) such license is valid under applicable law;
(ii) such license is for the use of such trademark in the regular course of that entity’s business outside of the provision of TLD Registry Services, and is not primarily for the purpose of enabling registration or use of domain names in the TLD;
(iii) such trademark is used continuously in that entity’s business throughout the Term; and
(iv) the domain names in the TLD registered to the Trademark Licensee are required to be used for the promotion, support, distribution, sales or other services reasonably related to any of the goods and/or services identified in the trademark registration.
33. If the Applicable Registry Agreement contains Specification 13, a new Section 11 of Specification 13 is hereby added as follows:
11. Notwithstanding Sections 7.6 and 7.7 of the Agreement, if any amendment contemplated by Section 7.6 or 7.7 of the Agreement (other than bilateral amendments between ICANN and Registry Operator and Board Amendments) would, if effective, amend the express terms of this Specification 13, such amendment shall not amend the express terms of this Specification 13 unless such amendment also receives Brand Registry Operator Approval. For the avoidance of doubt, (i) nothing in this Section 11 of this Specification 13 shall restrict ICANN and Registry Operator from entering into bilateral amendments and modifications to this Specification 13 or any other provision of the Agreement, (ii) the requirements of this Section 11 of this Specification 13 shall not apply to any Board Amendment or otherwise restrict the adoption of Board Amendments pursuant to Section 7.6 of the Agreement, and (iii) if any amendment does not receive the required Registry Operator Approval under Section 7.6 or 7.7 of the Agreement, as applicable, the terms of this Specification 13 shall not be amended by such amendment even if such amendment receives Brand Registry Operator Approval.
Schedule A
.AAA
.AARP
.ABARTH
.ABB
.ABBOTT
.ABBVIE
.ABC
.ABLE
.ABOGADO
.ABUDHABI
.ACADEMY
.ACCENTURE
.ACCOUNTANT
.ACCOUNTANTS
.ACO
.ACTIVE
.ACTOR
.ADAC
.ADS
.ADULT
.AEG
.AETNA
.AFAMILYCOMPANY
.AFL
.AFRICA
.AGAKHAN
.AGENCY
.AIG
.AIGO
.AIRBUS
.AIRFORCE
.AIRTEL
.AKDN
.ALFAROMEO
.ALIBABA
.ALIPAY
.ALLFINANZ
.ALLSTATE
.ALLY
.ALSACE
.ALSTOM
.AMERICANEXPRESS
.AMERICANFAMILY
.AMEX
.AMFAM
.AMICA
.AMSTERDAM
.ANALYTICS
.ANDROID
.ANQUAN
.ANZ
.AOL
.APARTMENTS
.APP
.APPLE
.AQUARELLE
.ARAB
.ARAMCO
.ARCHI
.ARMY
.ART
.ARTE
.ASDA
.ASSOCIATES
.ATHLETA
.ATTORNEY
.AUCTION
.AUDI
.AUDIBLE
.AUDIO
.AUSPOST
.AUTHOR
.AUTO
.AUTOS
.AVIANCA
.AWS
.AXA
.AZURE
.BABY
.BAIDU
.BANAMEX
.BANANAREPUBLIC
.BAND
.BANK
.BAR
.BARCELONA
.BARCLAYCARD
.BARCLAYS
.BAREFOOT
.BARGAINS
.BASEBALL
.BASKETBALL
.BAUHAUS
.BAYERN
.BBC
.BBT
.BBVA
.BCG
.BCN
.BEATS
.BEAUTY
.BEER
.BENTLEY
.BERLIN
.BEST
.BESTBUY
.BET
.BHARTI
.BIBLE
.BID
.BIKE
.BING
.BINGO
.BIO
.BLACK
.BLACKFRIDAY
.BLANCO
.BLOCKBUSTER
.BLOG
.BLOOMBERG
.BLUE
.BMS
.BMW
.BNL
.BNPPARIBAS
.BOATS
.BOEHRINGER
.BOFA
.BOM
.BOND
.BOO
.BOOK
.BOOKING
.BOOTS
.BOSCH
.BOSTIK
.BOSTON
.BOT
.BOUTIQUE
.BOX
.BRADESCO
.BRIDGESTONE
.BROADWAY
.BROKER
.BROTHER
.BRUSSELS
.BUDAPEST
.BUGATTI
.BUILD
.BUILDERS
.BUSINESS
.BUY
.BUZZ
.BZH
.CAB
.CAFE
.CAL
.CALL
.CALVINKLEIN
.CAM
.CAMERA
.CAMP
.CANCERRESEARCH
.CANON
.CAPETOWN
.CAPITAL
.CAPITALONE
.CAR
.CARAVAN
.CARDS
.CARE
.CAREER
.CAREERS
.CARS
.CARTIER
.CASA
.CASE
.CASEIH
.CASH
.CASINO
.CAT
.CATERING
.CATHOLIC
.CBA
.CBN
.CBRE
.CBS
.CEB
.CENTER
.CEO
.CERN
.CFA
.CFD
.CHANEL
.CHANNEL
.CHASE
.CHAT
.CHEAP
.CHINTAI
.CHLOE
.CHRISTMAS
.CHROME
.CHRYSLER
.CHURCH
.CIPRIANI
.CIRCLE
.CISCO
.CITADEL
.CITI
.CITIC
.CITY
.CITYEATS
.CLAIMS
.CLEANING
.CLICK
.CLINIC
.CLINIQUE
.CLOTHING
.CLOUD
.CLUB
.CLUBMED
.COACH
.CODES
.COFFEE
.COLLEGE
.COLOGNE
.COMCAST
.COMMBANK
.COMMUNITY
.COMPANY
.COMPARE
.COMPUTER
.COMSEC
.CONDOS
.CONSTRUCTION
.CONSULTING
.CONTACT
.CONTRACTORS
.COOKING
.COOKINGCHANNEL
.COOL
.CORSICA
.COUNTRY
.COUPON
.COUPONS
.COURSES
.CREDIT
.CREDITCARD
.CREDITUNION
.CRICKET
.CROWN
.CRS
.CRUISE
.CRUISES
.CSC
.CUISINELLA
.CYMRU
.CYOU
.DABUR
.DAD
.DANCE
.DATA
.DATE
.DATING
.DATSUN
.DAY
.DCLK
.DDS
.DEAL
.DEALER
.DEALS
.DEGREE
.DELIVERY
.DELL
.DELOITTE
.DELTA
.DEMOCRAT
.DENTAL
.DENTIST
.DESI
.DESIGN
.DEV
.DHL
.DIAMONDS
.DIET
.DIGITAL
.DIRECT
.DIRECTORY
.DISCOUNT
.DISCOVER
.DISH
.DIY
.DNP
.DOCS
.DOCTOR
.DODGE
.DOG
.DOHA
.DOMAINS
.DOT
.DOWNLOAD
.DRIVE
.DTV
.DUBAI
.DUCK
.DUNLOP
.DUNS
.DUPONT
.DURBAN
.DVAG
.DVR
.EARTH
.EAT
.ECO
.EDEKA
.EDUCATION
.EMERCK
.ENERGY
.ENGINEER
.ENGINEERING
.ENTERPRISES
.EPOST
.EPSON
.EQUIPMENT
.ERICSSON
.ERNI
.ESQ
.ESTATE
.ESURANCE
.ETISALAT
.EUROVISION
.EUS
.EVENTS
.EVERBANK
.EXCHANGE
.EXPERT
.EXPOSED
.EXPRESS
.EXTRASPACE
.FAGE
.FAIL
.FAIRWINDS
.FAITH
.FAMILY
.FAN
.FANS
.FARM
.FARMERS
.FASHION
.FAST
.FEDEX
.FEEDBACK
.FERRARI
.FERRERO
.FIAT
.FIDELITY
.FIDO
.FILM
.FINAL
.FINANCE
.FINANCIAL
.FIRE
.FIRESTONE
.FIRMDALE
.FISH
.FISHING
.FIT
.FITNESS
.FLICKR
.FLIGHTS
.FLIR
.FLORIST
.FLOWERS
.FLY
.FOO
.FOOD
.FOODNETWORK
.FOOTBALL
.FORD
.FOREX
.FORSALE
.FORUM
.FOUNDATION
.FOX
.FREE
.FRESENIUS
.FRL
.FROGANS
.FRONTDOOR
.FRONTIER
.FTR
.FUJITSU
.FUJIXEROX
.FUN
.FUND
.FURNITURE
.FUTBOL
.FYI
.GAL
.GALLERY
.GALLO
.GALLUP
.GAME
.GAMES
.GAP
.GARDEN
.GBIZ
.GDN
.GEA
.GENT
.GENTING
.GEORGE
.GGEE
.GIFT
.GIFTS
.GIVES
.GIVING
.GLADE
.GLASS
.GLE
.GLOBAL
.GLOBO
.GMAIL
.GMBH
.GMO
.GMX
.GODADDY
.GOLD
.GOLDPOINT
.GOLF
.GOO
.GOODHANDS
.GOODYEAR
.GOOG
.GOP
.GOT
.GRAINGER
.GRAPHICS
.GRATIS
.GREEN
.GRIPE
.GROCERY
.GROUP
.GUARDIAN
.GUCCI
.GUGE
.GUIDE
.GUITARS
.GURU
.HAIR
.HAMBURG
.HANGOUT
.HAUS
.HBO
.HDFC
.HDFCBANK
.HEALTH
.HEALTHCARE
.HELP
.HELSINKI
.HERE
.HERMES
.HGTV
.HIPHOP
.HISAMITSU
.HITACHI
.HIV
.HKT
.HOCKEY
.HOLDINGS
.HOLIDAY
.HOMEDEPOT
.HOMEGOODS
.HOMES
.HOMESENSE
.HONDA
.HONEYWELL
.HORSE
.HOSPITAL
.HOST
.HOSTING
.HOT
.HOTELES
.HOTELS
.HOTMAIL
.HOUSE
.HOW
.HSBC
.HTC
.HUGHES
.HYATT
.HYUNDAI
.IBM
.ICBC
.ICE
.ICU
.IEEE
.IFM
.IKANO
.IMAMAT
.IMDB
.IMMO
.IMMOBILIEN
.INDUSTRIES
.INFINITI
.ING
.INK
.INSTITUTE
.INSURANCE
.INSURE
.INTEL
.INTERNATIONAL
.INTUIT
.INVESTMENTS
.IPIRANGA
.IRISH
.ISELECT
.ISMAILI
.IST
.ISTANBUL
.ITAU
.ITV
.IVECO
.IWC
.JAGUAR
.JAVA
.JCB
.JCP
.JEEP
.JETZT
.JEWELRY
.JIO
.JLC
.JLL
.JMP
.JNJ
.JOBS
.JOBURG
.JOT
.JOY
.JPMORGAN
.JPRS
.JUEGOS
.JUNIPER
.KAUFEN
.KDDI
.KERRYHOTELS
.KERRYLOGISTICS
.KERRYPROPERTIES
.KFH
.KIA
.KIM
.KINDER
.KINDLE
.KITCHEN
.KIWI
.KOELN
.KOMATSU
.KOSHER
.KPMG
.KPN
.KRD
.KRED
.KUOKGROUP
.KYOTO
.LACAIXA
.LADBROKES
.LAMBORGHINI
.LAMER
.LANCASTER
.LANCIA
.LANCOME
.LAND
.LANDROVER
.LANXESS
.LASALLE
.LAT
.LATINO
.LATROBE
.LAW
.LAWYER
.LDS
.LEASE
.LECLERC
.LEFRAK
.LEGAL
.LEGO
.LEXUS
.LGBT
.LIAISON
.LIDL
.LIFE
.LIFEINSURANCE
.LIFESTYLE
.LIGHTING
.LIKE
.LILLY
.LIMITED
.LIMO
.LINCOLN
.LINDE
.LINK
.LIPSY
.LIVE
.LIVING
.LIXIL
.LOAN
.LOANS
.LOCKER
.LOCUS
.LOFT
.LOL
.LONDON
.LOTTE
.LOTTO
.LOVE
.LPL
.LPLFINANCIAL
.LTD
.LTDA
.LUNDBECK
.LUPIN
.LUXE
.LUXURY
.MACYS
.MADRID
.MAIF
.MAISON
.MAKEUP
.MAN
.MANAGEMENT
.MANGO
.MAP
.MARKET
.MARKETING
.MARKETS
.MARRIOTT
.MARSHALLS
.MASERATI
.MATTEL
.MBA
.MCD
.MCDONALDS
.MCKINSEY
.MED
.MEDIA
.MEET
.MELBOURNE
.MEME
.MEMORIAL
.MEN
.MENU
.MEO
.MERCKMSD
.METLIFE
.MIAMI
.MICROSOFT
.MINI
.MINT
.MIT
.MITSUBISHI
.MLB
.MLS
.MMA
.MOBI
.MOBILE
.MOBILY
.MODA
.MOE
.MOI
.MOM
.MONASH
.MONEY
.MONSTER
.MONTBLANC
.MOPAR
.MORMON
.MORTGAGE
.MOSCOW
.MOTO
.MOTORCYCLES
.MOV
.MOVIE
.MOVISTAR
.MSD
.MTN
.MTR
.MUTUAL
.NAB
.NADEX
.NAGOYA
.NATIONWIDE
.NATURA
.NAVY
.NBA
.NEC
.NETBANK
.NETFLIX
.NETWORK
.NEUSTAR
.NEW
.NEWHOLLAND
.NEWS
.NEXT
.NEXTDIRECT
.NEXUS
.NFL
.NGO
.NHK
.NICO
.NIKE
.NIKON
.NINJA
.NISSAN
.NISSAY
.NOKIA
.NORTHWESTERNMUTUAL
.NORTON
.NOW
.NOWRUZ
.NOWTV
.NRA
.NRW
.NTT
.NYC
.OBI
.OBSERVER
.OFF
.OFFICE
.OKINAWA
.OLAYAN
.OLAYANGROUP
.OLDNAVY
.OLLO
.OMEGA
.ONE
.ONG
.ONL
.ONLINE
.ONYOURSIDE
.OOO
.OPEN
.ORACLE
.ORANGE
.ORGANIC
.ORIGINS
.OSAKA
.OTSUKA
.OTT
.OVH
.PAGE
.PAMPEREDCHEF
.PANASONIC
.PANERAI
.PARIS
.PARS
.PARTNERS
.PARTS
.PARTY
.PASSAGENS
.PAY
.PCCW
.PET
.PFIZER
.PHARMACY
.PHD
.PHILIPS
.PHONE
.PHOTO
.PHOTOGRAPHY
.PHOTOS
.PHYSIO
.PIAGET
.PICS
.PICTET
.PICTURES
.PID
.PIN
.PING
.PINK
.PIONEER
.PIZZA
.PLACE
.PLAY
.PLAYSTATION
.PLUMBING
.PLUS
.PNC
.POHL
.POKER
.POLITIE
.PORN
.PRAMERICA
.PRAXI
.PRESS
.PRIME
.PRO
.PROD
.PRODUCTIONS
.PROF
.PROGRESSIVE
.PROMO
.PROPERTIES
.PROPERTY
.PROTECTION
.PRU
.PRUDENTIAL
.PUB
.PWC
.QPON
.QUEBEC
.QUEST
.QVC
.RACING
.RADIO
.RAID
.READ
.REALESTATE
.REALTOR
.REALTY
.RECIPES
.RED
.REDSTONE
.REDUMBRELLA
.REHAB
.REISE
.REISEN
.REIT
.RELIANCE
.REN
.RENT
.RENTALS
.REPAIR
.REPORT
.REPUBLICAN
.REST
.RESTAURANT
.REVIEW
.REVIEWS
.REXROTH
.RICH
.RICHARDLI
.RICOH
.RIGHTATHOME
.RIL
.RIO
.RIP
.RMIT
.ROCHER
.ROCKS
.RODEO
.ROGERS
.ROOM
.RSVP
.RUGBY
.RUHR
.RUN
.RWE
.RYUKYU
.SAARLAND
.SAFE
.SAFETY
.SAKURA
.SALE
.SALON
.SAMSCLUB
.SAMSUNG
.SANDVIK
.SANDVIKCOROMANT
.SANOFI
.SAP
.SAPO
.SARL
.SAS
.SAVE
.SAXO
.SBI
.SBS
.SCA
.SCB
.SCHAEFFLER
.SCHMIDT
.SCHOLARSHIPS
.SCHOOL
.SCHULE
.SCHWARZ
.SCIENCE
.SCJOHNSON
.SCOR
.SCOT
.SEARCH
.SEAT
.SECURE
.SECURITY
.SEEK
.SELECT
.SENER
.SERVICES
.SES
.SEVEN
.SEW
.SEX
.SEXY
.SFR
.SHANGRILA
.SHARP
.SHAW
.SHELL
.SHIA
.SHIKSHA
.SHOES
.SHOP
.SHOPPING
.SHOUJI
.SHOW
.SHOWTIME
.SHRIRAM
.SILK
.SINA
.SINGLES
.SITE
.SKI
.SKIN
.SKY
.SKYPE
.SLING
.SMART
.SMILE
.SNCF
.SOCCER
.SOCIAL
.SOFTBANK
.SOFTWARE
.SOHU
.SOLAR
.SOLUTIONS
.SONG
.SONY
.SOY
.SPACE
.SPIEGEL
.SPOT
.SPREADBETTING
.SRL
.SRT
.STADA
.STAPLES
.STAR
.STARHUB
.STATEBANK
.STATEFARM
.STATOIL
.STC
.STCGROUP
.STOCKHOLM
.STORAGE
.STORE
.STREAM
.STUDIO
.STUDY
.STYLE
.SUCKS
.SUPPLIES
.SUPPLY
.SUPPORT
.SURF
.SURGERY
.SUZUKI
.SWATCH
.SWIFTCOVER
.SWISS
.SYDNEY
.SYMANTEC
.SYSTEMS
.TAB
.TAIPEI
.TALK
.TAOBAO
.TARGET
.TATAMOTORS
.TATAR
.TATTOO
.TAX
.TAXI
.TCI
.TDK
.TEAM
.TECH
.TECHNOLOGY
.TEL
.TELECITY
.TELEFONICA
.TEMASEK
.TENNIS
.TEVA
.THD
.THEATER
.THEATRE
.TIAA
.TICKETS
.TIENDA
.TIFFANY
.TIPS
.TIRES
.TIROL
.TJMAXX
.TJX
.TKMAXX
.TMALL
.TODAY
.TOKYO
.TOOLS
.TOP
.TORAY
.TOSHIBA
.TOTAL
.TOURS
.TOWN
.TOYOTA
.TOYS
.TRADE
.TRADING
.TRAINING
.TRAVEL
.TRAVELCHANNEL
.TRAVELERS
.TRAVELERSINSURANCE
.TRUST
.TRV
.TUBE
.TUI
.TUNES
.TUSHU
.TVS
.UBANK
.UBS
.UCONNECT
.UNICOM
.UNIVERSITY
.UNO
.UOL
.UPS
.VACATIONS
.VANA
.VANGUARD
.VEGAS
.VENTURES
.VERISIGN
XN--VERMGENSBERATER-CTB
XN--VERMGENSBERATUNG-PWB
.VERSICHERUNG
.VET
.VIAJES
.VIDEO
.VIG
.VIKING
.VILLAS
.VIN
.VIP
.VIRGIN
.VISA
.VISION
.VISTA
.VISTAPRINT
.VIVA
.VIVO
.VLAANDEREN
.VODKA
.VOLKSWAGEN
.VOLVO
.VOTE
.VOTING
.VOTO
.VOYAGE
.VUELOS
.WALES
.WALMART
.WALTER
.WANG
.WANGGOU
.WARMAN
.WATCH
.WATCHES
.WEATHER
.WEATHERCHANNEL
.WEBCAM
.WEBER
.WEBSITE
.WED
.WEDDING
.WEIR
.WHOSWHO
.WIEN
.WIKI
.WILLIAMHILL
.WIN
.WINDOWS
.WINE
.WINNERS
.WME
.WOLTERSKLUWER
.WOODSIDE
.WORK
.WORKS
.WORLD
.WOW
.WTC
.WTF
.XBOX
.XEROX
.XFINITY
.XIHUAN
.XIN
.XPERIA
.XYZ
.YACHTS
.YAHOO
.YAMAXUN
.YANDEX
.YODOBASHI
.YOGA
.YOKOHAMA
.YOU
.YOUTUBE
.YUN
.ZAPPOS
.ZARA
.ZERO
.ZIP
.ZIPPO
.ZONE
.ZUERICH
XN--D1ACJ3B
XN--80AQECDR1A
XN--J1AEF
XN--80ADXHKS
XN--80ASEHDB
XN--C1AVG
XN--P1ACF
XN--80ASWG
XN--9DBQ2A
XN--MGBCA7DZDO
XN--MGBAAKC7DVF
XN--MGBA3A3EJT
XN--MGBA7C0BBN0A
XN--MGBAB2BD
XN--NGBE9E0A
XN--NGBC5AZD
XN--NGBRX
XN--MGBI4ECEXP
XN--FHBEI
XN--MGBB9FBPOB
XN--4GBRIM
XN--MGBT3DHD
XN--11B4C3D
XN--C2BR7G
XN--I1B6B1A6A2E
XN--42C2D9A
XN--T60B56A
XN--MK1BU44C
XN--CG4BKI
XN--QCKA1PMC
XN--GCKR3F0F
XN--TCKWE
XN--CCK2B3B
XN--1CK2E1B
XN--BCK1B9A5DRE4C
XN--ECKVDTC9D
XN--Q9JYB4C
XN--RHQV96G
XN--FIQ64B
XN--FIQ228C5HS
XN--VHQUV
XN--1QQW23A
XN--VUQ861B
XN--NYQY26A
XN--45Q11C
XN--55QX5D
XN--55QW42G
XN--CZRU2D
XN--CZRS0T
XN--CZR694B
XN--W4RS40L
XN--W4R85EL8FHU5DNRA
XN--3DS443G
XN--3OQ18VL8PN36A
XN--PSSY2U
XN--TIQ49XQYJ
XN--FJQ720A
XN--FCT429K
XN--ESTV75G
XN--XHQ521B
XN--9KRT00A
XN--30RR7Y
XN--6QQ986B3XL
XN--KPUT3I
XN--KPU716F
XN--ZFR164B
XN--MXTQ1M
XN--EFVY88H
XN--9ET52U
XN--ROVU88B
XN--NQV7F
XN--B4W605FERD
XN--UNUP4Y
XN--3PXU8K
XN--PBT977C
XN--6FRZ82G
XN--NQV7FS00EMA
XN--SES554G
XN--HXT814E
XN--5TZM5G
XN--IO0A7I
XN--8Y0A063A
XN--JLQ61U9W7B
XN--FLW351E
XN--G2XX48C
XN--GK3AT1E
XN--3BST00M
XN--FZYS8D69UVGM
XN--KCRX77D1X4A
XN--JVR189M
XN--IMR513N
XN--5SU34J936BGSG