Amendment No. 2 to the .COOP Registry Agreement


The Internet Corporation for Assigned Names and Numbers and DotCooperation LLC agree, effective as of (“Amendment Effective Date”), that the modifications set forth below are now made to the 1 July 2007 Registry Agreement (“Agreement”).


  1. Section 3.1 (c)(i) of the Agreement is deleted in its entirety and replaced as follows:


    3.1 (c)(i) Data Escrow. Registry Operator shall comply with the registry data escrow procedures set forth in Appendix 1 attached hereto (“Appendix 1”).


  2. Section 3.1 (c)(iii) of the Agreement is deleted in its entirety and replaced as follows:

    3.1 (c)(iii) Bulk Zone File Access. Registry Operator shall comply with the registry bulk zone file access procedures set forth in Appendix 3 attached hereto (“Appendix 3”).


  3. Section 3.1 (c)(v) of the Agreement is deleted in its entirety and replaced as follows:

    3.1 (c)(v) Publication of Registration Data. Registry Operator shall provide public access to registration data in accordance with Appendix 5 attached hereto.


  4. Section 3.1 (d)(ii) of the Agreement is deleted in its entirety and replaced as follows:

    [Old Text]

    Functional and Performance Specifications. Functional and Performance Specifications for operation of the TLD shall be as set forth in Appendix 7 hereto, and shall address without limitation minimum requirements for DNS services; operation of the shared registration system; and nameserver operations. Sponsor shall keep and ensure Registry Operator shall keep technical and operational records sufficient to evidence compliance with such specifications for at least one year, which records ICANN may audit from time to time upon reasonable advance written notice, provided that such audits shall not exceed one per quarter. Any such audit shall be at ICANN's cost.


    [New Text]

    Emergency Transition. Registry Operator agrees that, in the event that any of the emergency thresholds for registry functions set forth in Section 6 of Appendix 7 is reached, ICANN may designate an emergency interim registry operator of the registry for the TLD (an “Emergency Operator”) in accordance with ICANN’s registry transition process (available at <http://www.icann.org/en/resources/registries/transition-­‐processes>) (as the same may be amended from time to time, the “Registry Transition Process”) until such time as Registry Operator has demonstrated to ICANN’s reasonable satisfaction that it can resume operation of the registry for the TLD without the reoccurrence of such failure. Following such demonstration, Registry Operator may transition back into operation of the registry for the TLD pursuant to the procedures set out in the Registry Transition Process,

    provided that Registry Operator pays all reasonable costs incurred (i) by ICANN as a result of the designation of the Emergency Operator and (ii) by the Emergency Operator in connection with the operation of the registry for the TLD, which costs shall be documented in reasonable detail in records that shall be made available to Registry Operator. In the event ICANN designates an Emergency Operator pursuant to this Section 3.1 (d)(ii) and the Registry Transition Process, Registry Operator shall provide ICANN or any such Emergency Operator with all data (including the data escrowed in accordance with Section 3.1 (c)(i)) regarding operations of the registry for the TLD necessary to maintain operations and registry functions that may be reasonably requested by ICANN or such Emergency Operator. Registry Operator agrees that ICANN may make any changes it deems necessary to the IANA database for DNS and WHOIS records with respect to the TLD in the event that an Emergency Operator is designated pursuant to this Section 3.1 (d)(ii).


  5. Appendix 1 is deleted in its entirety and replaced in the form attached to this Amendment.

  6. Appendix 2, subject to the provisions of clause XII of this Amendment set forth below, will be deleted in its entirety and hereinafter forever labeled as “RESERVED.”

  7. Appendix 3 is deleted in its entirety and replaced in the form attached to this Amendment.

  8. Appendix 4 is deleted in its entirety and replaced in the form attached to this Amendment.

  9. Appendix 5 is deleted in its entirety and replaced in the form attached to this Amendment.

  10. Appendix 7 is deleted in its entirety and replaced in the form attached to this Amendment.

  11. Part V of Appendix S is deleted in its entirety.

  12. Registry Operator will have ninety (90) days from the Amendment Effective Date to comply with the terms of the Agreement as modified by this Amendment, during which time Registry Operator remains obligated to comply with the provisions of the Agreement as they existed prior to the Amendment Effective Date. On or prior to expiration of this period, Registry Operator must procure and provide to ICANN a Registry Data Escrow Agreement that meets compliance with the terms of Appendix 1 of the Agreement as modified by this Amendment.

The parties agree that, except as set forth in this Amendment, the terms of the Agreement will remain in full force and effect. All capitalized terms not defined will have the meaning given to them in the Agreement.

AGREED:


INTERNET CORPORATION FOR ASSIGNED NAMES AND NUMBERS


By:

Akram Atallah

President, Global Domains Division


DOTCOOPERATION, LLC


By:

Patricia Brownell Sterner

Chief Operating Officer, National Cooperative Business Association

APPENDIX 1

Data Escrow Requirements


Registry Operator will engage an independent entity to act as data escrow agent (“Escrow Agent”) for the provision of data escrow services related to the Registry Agreement. The following Technical Specifications set forth in Part A, and Legal Requirements set forth in Part B, will be included in any data escrow agreement between Registry Operator and the Escrow Agent, under which ICANN must be named a third-­‐party beneficiary. In addition to the following requirements, the data escrow agreement may contain other provisions that are not contradictory or intended to subvert the required terms provided below.

PART A – TECHNICAL SPECIFICATIONS

  1. Deposits. 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. Full Deposit” will consist of data that reflects the state of the registry as of 00:00:00 UTC (Coordinated Universal Time) on the day that such Full Deposit is submitted to Escrow Agent.

    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., newly added or modified domain names).

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

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

    2. The 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.

  3. Escrow Format Specification.

    1. Deposit’s Format. Registry objects, such as domains, contacts, name servers, registrars, etc. will be compiled into a file constructed as described in draft-­‐arias-­‐noguchi-­‐registry-­‐data-­‐escrow, see Part A, Section 9, reference 1 of this Appendix and draft-­‐arias-­‐noguchi-­‐dnrd-­‐objects-­‐mapping, see Part A, 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. If not already an RFC, Registry Operator will use the most recent draft version of the DNDE Specification available at the Effective Date. Registry Operator may at its election use newer versions of the DNDE Specification after the Effective Date. Once the DNDE Specification is published as an RFC, Registry Operator will implement that version of the DNDE Specification, no later than one hundred eighty (180) calendar days after. UTF-­‐8 character encoding will be used.

    2. Extensions. If a 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 Part A, Section 9, reference 2 of this Appendix. Data related to the “extensions schemas” will be included in the deposit file described in Part A, Section 3.1 of this Appendix. ICANN and the respective 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 Part A, 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 Part A, 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 Part A, 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 Part A, 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:

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

    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”;

    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 2 of Appendix 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. {rev} is replaced by the number of revision (or resend) of the file beginning with “0”:

    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-­‐lozano-­‐icann-­‐registry-­‐interfaces, see Part A, Section 9, reference 5 of this Appendix (the “Interface Specification”)) a written statement (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. 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 Appendix.

    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.


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

    5. If Part A, Section 9, reference 1 of this Appendix includes a verification process, that will be applied at this step.

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


  9. References.

  1. Domain Name Data Escrow Specification (work in progress), http://tools.ietf.org/html/draft-­‐arias-­‐noguchi-­‐registry-­‐data-­‐escrow

  2. Domain Name Registration Data (DNRD) Objects Mapping, http://tools.ietf.org/html/draft-­‐arias-­‐noguchi-­‐dnrd-­‐objects-­‐mapping

  3. OpenPGP Message Format, http://www.rfc-­‐editor.org/rfc/rfc4880.txt

  4. OpenPGP parameters,

    http://www.iana.org/assignments/pgp-­‐parameters/pgp-­‐parameters.xhtml

  5. ICANN interfaces for registries and data escrow agents, http://tools.ietf.org/html/draft-­‐lozano-­‐icann-­‐registry-­‐interfaces

PART B – LEGAL REQUIREMENTS

  1. Escrow Agent. Prior to entering into an escrow agreement, the Registry Operator must provide notice to ICANN as to the identity of the Escrow Agent, and provide ICANN with contact information and a copy of the relevant escrow agreement, and all amendments thereto. In addition, prior to entering into an escrow agreement, Registry Operator must obtain the consent of ICANN to (a) use the specified Escrow Agent, and (b) enter into the form of escrow agreement provided. ICANN must be expressly designated as a third-­‐party beneficiary of the escrow agreement. ICANN reserves the right to withhold its consent to any Escrow Agent, escrow agreement, or any amendment thereto, all in its sole discretion.

  2. Fees. Registry Operator must pay, or have paid on its behalf, fees to the Escrow Agent directly. If Registry Operator fails to pay any fee by the due date(s), the Escrow Agent will give ICANN written notice of such non-­‐payment and ICANN may pay the past-­‐due fee(s) within fifteen (15) calendar days after receipt of the written notice from Escrow Agent. Upon payment of the past-­‐due fees by ICANN, ICANN shall have a claim for such amount against Registry Operator, which Registry Operator shall be required to submit to ICANN together with the next fee payment due under the Registry Agreement.

  3. Ownership. Ownership of the Deposits during the effective term of the Registry Agreement shall remain with Registry Operator at all times. Thereafter, Registry Operator shall assign any such ownership rights (including intellectual property

    rights, as the case may be) in such Deposits to ICANN. In the event that during the term of the Registry Agreement any Deposit is released from escrow to ICANN, any intellectual property rights held by Registry Operator in the Deposits will automatically be licensed to ICANN or to a party designated in writing by ICANN on a non-­‐exclusive, perpetual, irrevocable, royalty-­‐free, paid-­‐up basis, for any use related to the operation, maintenance or transition of the TLD.

  4. Integrity and Confidentiality. Escrow Agent will be required to (i) hold and maintain the Deposits in a secure, locked, and environmentally safe facility, which is accessible only to authorized representatives of Escrow Agent, (ii) protect the integrity and confidentiality of the Deposits using commercially reasonable measures and (iii) keep and safeguard each Deposit for one (1) year. ICANN and Registry Operator will be provided the right to inspect Escrow Agent’s applicable records upon reasonable prior notice and during normal business hours. Registry Operator and ICANN will be provided with the right to designate a third-­‐party auditor to audit Escrow Agent’s compliance with the technical specifications and maintenance requirements of this Appendix 1 from time to time.

    If Escrow Agent receives a subpoena or any other order from a court or other judicial tribunal pertaining to the disclosure or release of the Deposits, Escrow Agent will promptly notify the Registry Operator and ICANN unless prohibited by law. After notifying the Registry Operator and ICANN, Escrow Agent shall allow sufficient time for Registry Operator or ICANN to challenge any such order, which shall be the responsibility of Registry Operator or ICANN; provided, however, that Escrow Agent does not waive its rights to present its position with respect to any such order. Escrow Agent will cooperate with the Registry Operator or ICANN to support efforts to quash or limit any subpoena, at such party’s expense. Any party requesting additional assistance shall pay Escrow Agent’s standard charges or as quoted upon submission of a detailed request.

  5. Copies. Escrow Agent may be permitted to duplicate any Deposit, in order to comply with the terms and provisions of the escrow agreement.

  6. Release of Deposits. Escrow Agent will make available for electronic download (unless otherwise requested) to ICANN or its designee, within twenty-­‐four (24) hours, at the Registry Operator’s expense, all Deposits in Escrow Agent’s possession in the event that the Escrow Agent receives a request from Registry Operator to effect such delivery to ICANN, or receives one of the following written notices by ICANN stating that:

    1. the Registry Agreement has expired without renewal, or been terminated; or

    2. ICANN has not received a notification as described in Part B, Sections 7.1 and 7.2 of this Appendix from Escrow Agent within five (5) calendar days

      after the Deposit’s scheduled delivery date; (a) ICANN gave notice to Escrow Agent and Registry Operator of that failure; and (b) ICANN has not, within seven (7) calendar days after such notice, received the notification from Escrow Agent; or

    3. ICANN has received notification as described in Part B, Sections 7.1 and 7.2 of this Appendix from Escrow Agent of failed verification of the latest escrow deposit for a specific date or a notification of a missing deposit, and the notification is for a deposit that should have been made on Sunday (i.e., a Full Deposit); (a) ICANN gave notice to Registry Operator of that receipt; and (b) ICANN has not, within seven (7) calendar days after such notice, received notification as described in Part B, Sections 7.1 and 7.2 of this Appendix from Escrow Agent of verification of a remediated version of such Full Deposit; or

    4. ICANN has received five notifications from Escrow Agent within the last thirty (30) calendar days notifying ICANN of either missing or failed escrow deposits that should have been made Monday through Saturday (i.e., a Differential Deposit), and (x) ICANN provided notice to Registry Operator of the receipt of such notifications; and (y) ICANN has not, within seven (7) calendar days after delivery of such notice to Registry Operator, received notification from Escrow Agent of verification of a remediated version of such Differential Deposit; or

    5. Registry Operator has: (i) ceased to conduct its business in the ordinary course; or (ii) filed for bankruptcy, become insolvent or anything analogous to any of the foregoing under the laws of any jurisdiction anywhere in the world; or

    6. Registry Operator has experienced a failure of critical registry functions; or

    7. a competent court, arbitral, legislative, or government agency mandates the release of the Deposits to ICANN; or

    8. pursuant to contractual and operational compliance audits as specified.

      Unless Escrow Agent has previously released the Registry Operator’s Deposits to ICANN or its designee, Escrow Agent will deliver all Deposits to ICANN upon expiration or termination of the Registry Agreement or the Escrow Agreement.

  7. Verification of Deposits.

    1. Within twenty-­‐four (24) hours after receiving each Deposit or corrected Deposit, Escrow Agent must verify the format and completeness of each Deposit and deliver to ICANN a notification generated for each

      Deposit. Reports will be delivered electronically using the API described in draft-­‐lozano-­‐icann-­‐registry-­‐interfaces, see Part A, Section 9, reference 5 of this Appendix.

    2. If Escrow Agent discovers that any Deposit fails the verification procedures or if Escrow Agent does not receive any scheduled Deposit, Escrow Agent must notify Registry Operator either by email, fax or phone and ICANN (using the API described in draft-­‐lozano-­‐icann-­‐registry-­‐interfaces, see Part A, Section 9, reference 5 of this Appendix) of such nonconformity or non-­‐ receipt within twenty-­‐four (24) hours after receiving the non-­‐conformant Deposit or the deadline for such Deposit, as applicable. Upon notification of such verification or delivery failure, Registry Operator must begin developing modifications, updates, corrections, and other fixes of the Deposit necessary for the Deposit to be delivered and pass the verification procedures and deliver such fixes to Escrow Agent as promptly as possible.

  8. Amendments. Escrow Agent and Registry Operator shall amend the terms of the Escrow Agreement to conform to this Appendix 1 within ten (10) calendar days of any amendment or modification to this Appendix 1. In the event of a conflict between this Appendix 1 and the Escrow Agreement, this Appendix 1 shall control.

  9. Indemnity. Escrow Agent shall indemnify and hold harmless Registry Operator and ICANN, and each of their respective directors, officers, agents, employees, members, and stockholders (“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.


APPENDIX 3

Zone File Access Agreement


  1. Third-­‐Party Access

    1. Zone 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.1.3 of this Appendix and do so using the file format described in Section 1.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.1.2 below; (b) Registry Operator may reject the request for access of any user that does not provide correct or legitimate credentials under Section 1.1.2 below or where Registry Operator reasonably believes will violate the terms of Section 1.1.5. below; 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.1.5 below.

      1. Credentialing 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.

      2. Grant of Access. Each Registry Operator (optionally through the CZDA Provider) will provide the Zone File FTP (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 FTP, 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.

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

        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 goes into a separate file named as above, with all the files combined using tar into a file called <tld>.zone.tar.

      4. 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 and use 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 the transmission by email, telephone, or facsimile of mass unsolicited, commercial advertising or solicitations to entities other than user’s own existing customers, or (ii) enable high volume, automated, electronic processes that send queries or data to the systems of Registry Operator or any ICANN-­‐accredited registrar.

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

      6. No 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

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

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


APPENDIX 4

Registry Operator's Monthly Reports

Registry Operator shall provide one set of monthly reports per gTLD, using the API described in draft-­‐lozano-­‐icann-­‐registry-­‐interfaces, see Appendix 1, Part A, Section 9, reference 5, with the following content.

ICANN may request in the future that the reports be delivered by other means and using other formats. 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. 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 “gTLD-­‐transactions-­‐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 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) 9999 should be used, otherwise the sponsoring Registrar IANA id should be used as specified in http://www.iana.org/assignments/registrar-­‐ids

    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-­‐successfully

    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 from redemption period

    35

    restored-­‐noreport

    total number of restored names for which the registrar failed to submit a restore report

    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


    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.

  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 at the end of the reporting period

02

ramp-­‐up-­‐registrars

number of registrars that have received a

Field #

Field Name

Description

password for access to OT&E at the end of the reporting period

03

pre-­‐ramp-­‐up-­‐registrars

number of registrars that have requested access, but have not yet entered the ramp-­‐up period at the end of the reporting period

04

zfa-­‐passwords

number of active zone file access passwords at the end of the reporting period

05

whois-­‐43-­‐queries

number of WHOIS (port-­‐43) queries responded during the reporting period

06

web-­‐whois-­‐queries

number of Web-­‐based Whois queries responded during the reporting period, not including searchable Whois

07

searchable-­‐whois-­‐ queries

number of searchable Whois queries responded during the reporting period, if offered

08

dns-­‐udp-­‐queries-­‐ received

number of DNS queries received over UDP transport during the reporting period

09

dns-­‐udp-­‐queries-­‐ responded

number of DNS queries received over UDP transport that were responded during the reporting period

10

dns-­‐tcp-­‐queries-­‐received

number of DNS queries received over TCP transport during the reporting period

11

dns-­‐tcp-­‐queries-­‐ responded

number of DNS queries received over TCP transport that were responded during the reporting period

12

srs-­‐dom-­‐check

number of SRS (EPP and any other interface) domain name “check” requests responded during the reporting period

13

srs-­‐dom-­‐create

number of SRS (EPP and any other interface) domain name “create” requests responded during the reporting period

14

srs-­‐dom-­‐delete

number of SRS (EPP and any other interface) domain name “delete” requests responded during the reporting period

15

srs-­‐dom-­‐info

number of SRS (EPP and any other interface) domain name “info” requests responded during the reporting period

16

srs-­‐dom-­‐renew

number of SRS (EPP and any other interface)

Field #

Field Name

Description

domain name “renew” requests responded during the reporting period

17

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

18

srs-­‐dom-­‐rgp-­‐restore-­‐ request

number of SRS (EPP and any other interface) domain name RGP “restore” requests responded during the reporting period

19

srs-­‐dom-­‐transfer-­‐ approve

number of SRS (EPP and any other interface) domain name “transfer” requests to approve transfers responded during the reporting period

20

srs-­‐dom-­‐transfer-­‐cancel

number of SRS (EPP and any other interface) domain name “transfer” requests to cancel transfers responded during the reporting period

21

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

22

srs-­‐dom-­‐transfer-­‐reject

number of SRS (EPP and any other interface) domain name “transfer” requests to reject transfers responded during the reporting period

23

srs-­‐dom-­‐transfer-­‐ request

number of SRS (EPP and any other interface) domain name “transfer” requests to request transfers responded during the reporting period

24

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

25

srs-­‐host-­‐check

number of SRS (EPP and any other interface) host “check” requests responded during the reporting period

26

srs-­‐host-­‐create

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

27

srs-­‐host-­‐delete

number of SRS (EPP and any other interface) host “delete” requests responded during the reporting period

28

srs-­‐host-­‐info

number of SRS (EPP and any other interface) host

Field #

Field Name

Description

“info” requests responded during the reporting period

29

srs-­‐host-­‐update

number of SRS (EPP and any other interface) host “update” requests responded during the reporting period

30

srs-­‐cont-­‐check

number of SRS (EPP and any other interface) contact “check” requests responded during the reporting period

31

srs-­‐cont-­‐create

number of SRS (EPP and any other interface) contact “create” requests responded during the reporting period

32

srs-­‐cont-­‐delete

number of SRS (EPP and any other interface) contact “delete” requests responded during the reporting period

33

srs-­‐cont-­‐info

number of SRS (EPP and any other interface) contact “info” requests responded during the reporting period

34

srs-­‐cont-­‐transfer-­‐ approve

number of SRS (EPP and any other interface) contact “transfer” requests to approve transfers responded during the reporting period

35

srs-­‐cont-­‐transfer-­‐cancel

number of SRS (EPP and any other interface) contact “transfer” requests to cancel transfers responded during the reporting period

36

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

37

srs-­‐cont-­‐transfer-­‐reject

number of SRS (EPP and any other interface) contact “transfer” requests to reject transfers responded during the reporting period

38

srs-­‐cont-­‐transfer-­‐request

number of SRS (EPP and any other interface) contact “transfer” requests to request transfers responded during the reporting period

39

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.

APPENDIX 5

REGISTRATION DATA PUBLICATION SERVICES

  1. Registration Data Directory Services. Until ICANN requires a different protocol, Registry Operator will operate a WHOIS service available via port 43 in accordance with RFC 3912, and a web-­‐based Directory Service at <whois.nic.TLD> providing free public query-­‐based access to at least the following elements in the following format. ICANN reserves the right to specify alternative formats and protocols, and upon such specification, the Registry Operator will implement such alternative specification as soon as reasonably practicable.

    Registry Operator shall implement a new standard supporting access to domain name registration data (SAC 051) no later than one hundred thirty-­‐five (135) days after it is requested by ICANN if: 1) the IETF produces a standard (i.e., it is published, at least, as a Proposed Standard RFC as specified in RFC 2026); and 2) its implementation is commercially reasonable in the context of the overall operation of the registry.

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

    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.

    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.

    4. The fields specified below set forth the minimum output requirements. Registry Operator may output data fields in addition to those specified below, subject to approval by ICANN, which approval shall not be unreasonably withheld.

    5. Domain Name Data:

      1. Query format: whois EXAMPLE.TLD

      2. Response format:

        Domain Name: EXAMPLE.TLD Domain ID: D1234567-­‐TLD

        WHOIS Server: whois.example.tld Referral URL: http://www.example.tld Updated Date: 2009-­‐05-­‐29T20:13:00Z Creation Date: 2000-­‐10-­‐08T00:45:00Z

        Registry Expiry Date: 2010-­‐10-­‐08T00:44:59Z Sponsoring Registrar: EXAMPLE REGISTRAR LLC Sponsoring Registrar IANA ID: 5555555 Domain Status: clientDeleteProhibited

        Domain Status: clientRenewProhibited Domain Status: clientTransferProhibited Domain Status: serverUpdateProhibited Registrant ID: 5372808-­‐ERL

        Registrant Name: EXAMPLE REGISTRANT Registrant Organization: EXAMPLE ORGANIZATION Registrant Street: 123 EXAMPLE 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: EMAIL@EXAMPLE.TLD Admin ID: 5372809-­‐ERL

        Admin Name: EXAMPLE REGISTRANT ADMINISTRATIVE

        Admin Organization: EXAMPLE REGISTRANT ORGANIZATION Admin Street: 123 EXAMPLE STREET

        Admin City: ANYTOWN Admin State/Province: AP Admin Postal Code: A1A1A1 Admin Country: EX

        Admin Phone: +1.5555551212 Admin Phone Ext: 1234 Admin Fax: +1.5555551213

        Admin Fax Ext:

        Admin Email: EMAIL@EXAMPLE.TLD Tech ID: 5372811-­‐ERL

        Tech Name: EXAMPLE REGISTRAR TECHNICAL

        Tech Organization: EXAMPLE REGISTRAR LLC Tech Street: 123 EXAMPLE 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: EMAIL@EXAMPLE.TLD

        Name Server: NS01.EXAMPLEREGISTRAR.TLD Name Server: NS02.EXAMPLEREGISTRAR.TLD

        DNSSEC: signedDelegation DNSSEC: unsigned

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

    6. Registrar Data:

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

      2. Response format:

        Registrar Name: Example Registrar, Inc. Street: 1234 Admiralty Way

        City: Marina del Rey State/Province: CA Postal Code: 90292 Country: US

        Phone Number: +1.3105551212

        Fax Number: +1.3105551213 Email: registrar@example.tld

        WHOIS Server: whois.example-­‐registrar.tld Referral URL: http://www.example-­‐registrar.tld Admin Contact: Joe Registrar

        Phone Number: +1.3105551213

        Fax Number: +1.3105551213

        Email: joeregistrar@example-­‐registrar.tld Admin Contact: Jane Registrar

        Phone Number: +1.3105551214

        Fax Number: +1.3105551213

        Email: janeregistrar@example-­‐registrar.tld Technical Contact: John Geek

        Phone Number: +1.3105551215

        Fax Number: +1.3105551216

        Email: johngeek@example-­‐registrar.tld

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

    7. Nameserver Data:

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

      2. Response format:

        Server Name: NS1.EXAMPLE.TLD IP Address: 192.0.2.123

        IP Address: 2001:0DB8::1

        Registrar: Example Registrar, Inc.

        WHOIS Server: whois.example-­‐registrar.tld Referral URL: http://www.example-­‐registrar.tld

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

    8. Contact Data:

      1. Query format: whois "contact 5372809-­‐ERL"

      2. Response format:

        Contact ID: 5372808-­‐ERL Name: EXAMPLE REGISTRANT

        Organization: EXAMPLE ORGANIZATION Street: 123 EXAMPLE STREET

        City: ANYTOWN

        State/Province: AP Postal Code: A1A1A1 Country: EX

        Phone: +1.5555551212

        Phone Ext: 1234

        Fax: +1.5555551213

        Fax Ext: 4321

        Email: EMAIL@EXAMPLE.TLD

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


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

    10. In order to be compatible with ICANN’s common interface for WHOIS (InterNIC), WHOIS output shall be in the format outline above.

    11. Searchability. Offering searchability capabilities on the Directory Services is optional but if offered by the Registry Operator it shall comply with the specification described in this section.

      1. Registry Operator will offer searchability on the web-­‐based Directory Service.

      2. Registry Operator will offer partial match capabilities, at least, on 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.).

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

      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.

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

      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 or policies.

    12. 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 WHOIS policy and educational materials.

  2. Zone File Access

    1. Third-­‐Party Access

      1. Zone 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

        2.1.3 of this Appendix 5 and do so using the file format described in Section 2.1.4 of this Appendix 5. 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 2.1.2 below; (b) Registry Operator may reject the request for access of any user that does not provide correct or legitimate credentials under Section 2.1.2 below or where Registry Operator reasonably believes will violate the terms of Section 2.1.5. below; 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 2.1.5 below.

      2. Credentialing 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.

      3. Grant of Access. Each Registry Operator (optionally through the CZDA Provider) will provide the Zone File FTP (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 FTP, 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.

      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.

        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 goes into a separate file named as above, with all the files combined using tar into a file called <tld>.zone.tar.

      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 and use

        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 the transmission by email, telephone, or facsimile of mass unsolicited, commercial advertising or solicitations to entities other than user’s own existing customers, or (ii) enable high volume, automated, electronic processes that send queries or data to the systems of Registry Operator or any ICANN-­‐accredited registrar.

      6. Term 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.

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

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

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

    4. Emergency Operator Access. Registry Operator shall provide bulk access to the zone files for the TLD to the Emergency Operators designated by ICANN on a continuous basis in the manner ICANN may reasonably specify from time to time.

  3. Bulk Registration Data Access to ICANN

    1. Periodic Access to Thin Registration Data. In order to verify and ensure the operational stability of Registry Services as well as to facilitate compliance checks on accredited registrars, Registry Operator will provide ICANN on a weekly basis (the day to be designated by ICANN) with up-­‐to-­‐ date Registration Data as specified below. Data will include data committed as of 00:00:00 UTC on the day previous to the one designated for retrieval by ICANN.

      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 repository object id (roid), hostname of registrar Whois server, and URL of registrar.

      2. Format. The data will be provided in the format specified in Appendix 1 for Data Escrow (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. Registry Operator has the option to provide a full deposit file instead as specified in Appendix 1.

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

    2. Exceptional Access to Thick Registration Data. 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 for Data Escrow. 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 3.1 of this Appendix.


  1. Definitions

    APPENDIX 7

    REGISTRY PERFORMANCE SPECIFICATIONS


    1. DNS. Refers to the Domain Name System as specified in RFCs 1034, 1035, and related RFCs.

    2. DNSSEC proper resolution. If Registry Operator sign its TLD zone, there is a valid DNSSEC chain of trust from the root trust anchor to a particular domain name, e.g., a TLD, a domain name registered under a TLD, etc.

    3. EPP. Refers to the Extensible Provisioning Protocol as specified in RFC 5730 and related RFCs.

    4. IP address. Refers to IPv4 or IPv6 addresses without making any distinction between the two. When there is need to make a distinction, IPv4 or IPv6 is used.

    5. Probes. Network hosts used to perform (DNS, EPP, etc.) tests (see below) that are located at various global locations.

    6. RDDS. Registration Data Directory Services refers to the collective of WHOIS and Web-­‐based WHOIS services as defined in Appendix 5 of this Agreement.

    7. RTT. Round-­‐Trip Time or RTT refers to the time measured from the sending of the first bit of the first packet of the sequence of packets needed to make a request until the reception of the last bit of the last packet of the sequence needed to receive the response. If the client does not receive the whole sequence of packets needed to consider the response as received, the request will be considered unanswered.

    8. SLR. Service Level Requirement is the level of service expected for a certain parameter being measured in a Service Level Agreement (SLA).

  2. Service Level Agreement Matrix


    Parameter

    SLR (monthly basis)

    DNS

    DNS service availability

    0 min downtime = 100% availability

    DNS name server availability

    432 min of downtime ( 99%)

    TCP DNS resolution RTT

    1500 ms, for at least 95% of the queries

    UDP DNS resolution RTT

    500 ms, for at least 95% of the queries

    DNS update time

    60 min, for at least 95% of the probes

    RDDS

    RDDS availability

    864 min of downtime ( 98%)

    RDDS query RTT

    2000 ms, for at least 95% of the queries

    RDDS update time

    60 min, for at least 95% of the probes

    EPP

    EPP service availability

    864 min of downtime ( 98%)

    EPP session-­‐command RTT

    4000 ms, for at least 90% of the commands

    EPP query-­‐command RTT

    2000 ms, for at least 90% of the commands

    EPP transform-­‐command RTT

    4000 ms, for at least 90% of the commands


    Registry Operator is encouraged to do maintenance for the different services at the times and dates of statistically lower traffic for each service. However, note that there is no provision for planned outages or similar periods of unavailable or slow service; any downtime, be it for maintenance or due to system failures, will be noted simply as downtime and counted for SLA purposes.

  3. DNS

    1. DNS service availability. Refers to the ability of the group of listed-­‐as-­‐ authoritative name servers of a particular domain name (e.g., a TLD), to answer DNS queries from DNS probes. For the service to be considered available at a particular moment, at least, two of the delegated name servers registered in the DNS must have successful results from “DNS tests” to each of their public-­‐DNS registered “IP addresses” to which the name server resolves. If 51% or more of the DNS testing probes see the service as unavailable during a given time, the DNS service will be considered unavailable.

    2. DNS name server availability. Refers to the ability of a public-­‐DNS registered “IP address” of a particular name server listed as authoritative for a domain name, to answer DNS queries from an Internet user. All the public DNS-­‐registered “IP address” of all name servers of the domain name being monitored shall be tested individually. If 51% or more of the DNS testing probes get undefined/unanswered results from “DNS tests” to a name server “IP address” during a given time, the name server “IP address” will be considered unavailable.

    3. UDP DNS resolution RTT. Refers to the RTT of the sequence of two packets, the UDP DNS query and the corresponding UDP DNS response. If the RTT is 5 times greater than the time specified in the relevant SLR, the RTT will be considered undefined.

    4. TCP DNS resolution RTT. Refers to the RTT of the sequence of packets from the start of the TCP connection to its end, including the reception of the DNS response for only one DNS query. If the RTT is 5 times greater

      than the time specified in the relevant SLR, the RTT will be considered undefined.

    5. DNS resolution RTT. Refers to either “UDP DNS resolution RTT” or “TCP DNS resolution RTT”.

    6. DNS update time. Refers to the time measured from the reception of an EPP confirmation to a transform command on a domain name, until the name servers of the parent domain name answer “DNS queries” with data consistent with the change made. This only applies for changes to DNS information.

    7. DNS test. Means one non-­‐recursive DNS query sent to a particular “IP address” (via UDP or TCP). If DNSSEC is offered in the queried DNS zone, for a query to be considered answered, the signatures must be positively verified against a corresponding DS record published in the parent zone or, if the parent is not signed, against a statically configured Trust Anchor. The answer to the query must contain the corresponding information from the Registry System, otherwise the query will be considered unanswered. A query with a “DNS resolution RTT” 5 times higher than the corresponding SLR, will be considered unanswered. The possible results to a DNS test are: a number in milliseconds corresponding to the “DNS resolution RTT” or, undefined/unanswered.

    8. Measuring DNS parameters. Every minute, every DNS probe will make an UDP or TCP “DNS test” to each of the public-­‐DNS registered “IP addresses” of the name servers of the domain name being monitored. If a “DNS test” result is undefined/unanswered, the tested IP will be considered unavailable from that probe until it is time to make a new test.

    9. Collating the results from DNS probes. The minimum number of active testing probes to consider a measurement valid is 20 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.

    10. Distribution of UDP and TCP queries. DNS probes will send UDP or TCP “DNS test” approximating the distribution of these queries.

    11. Placement of DNS probes. Probes for measuring DNS parameters shall be placed as near as possible to the DNS resolvers on the networks with the most users across the different geographic regions; care shall be taken not to deploy probes behind high propagation-­‐delay links, such as satellite links.

  4. RDDS

    1. RDDS availability. Refers to the ability of all the RDDS services 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 RDDS testing probes see any of the RDDS services as unavailable during a given time, the RDDS will be considered unavailable.

    2. WHOIS query RTT. Refers to the RTT of the sequence of packets from the start of the TCP connection to its end, including the reception of the WHOIS response. If the RTT is 5-­‐times or more the corresponding SLR, the RTT will be considered undefined.

    3. Web-­‐based-­‐WHOIS query RTT. Refers to the RTT of the sequence of packets from the start of the TCP connection to its end, including the reception of the HTTP response for only one HTTP request. If Registry Operator implements a multiple-­‐step process to get to the information, only the last step shall be measured. If the RTT is 5-­‐times or more the corresponding SLR, the RTT will be considered undefined.

    4. RDDS query RTT. Refers to the collective of “WHOIS query RTT” and “Web-­‐based-­‐ WHOIS query RTT”.

    5. RDDS update time. Refers to the time measured from the reception of an EPP confirmation to a transform command on a domain name, host or contact, up until the servers of the RDDS services reflect the changes made.

    6. RDDS test. Means one query sent to a particular “IP address” of one of the servers of one of the RDDS services. 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 RDDS test are: a number in milliseconds corresponding to the RTT or undefined/unanswered.

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

    8. Collating the results from RDDS probes. The minimum number of active 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.

    9. Placement of RDDS probes. Probes for measuring RDDS parameters shall be placed inside the networks with the most users across the different geographic regions; care shall be taken not to deploy probes behind high propagation-­‐delay links, such as satellite links.


  5. EPP

    1. EPP service availability. Refers to the ability of the TLD EPP servers as a group, to respond to commands from the Registry accredited Registrars, who already have credentials to the servers. The response shall include appropriate data from the Registry System. An EPP command with “EPP command RTT” 5 times higher than the corresponding SLR will be considered as unanswered. If 51% or more of the EPP testing probes see the EPP service as unavailable during a given time, the EPP service will be considered unavailable.

    2. EPP session-­‐command RTT. Refers to the RTT of the sequence of packets that includes the sending of a session command plus the reception of the EPP response for only one EPP session command. For the login command it will include packets needed for starting the TCP session. For the logout command it will include packets needed for closing the TCP session. EPP session commands are those described in section 2.9.1 of EPP RFC 5730. If the RTT is 5 times or more the corresponding SLR, the RTT will be considered undefined.

    3. EPP query-­‐command RTT. Refers to the RTT of the sequence of packets that includes the sending of a query command plus the reception of the EPP response for only one EPP query command. It does not include packets needed for the start or close of either the EPP or the TCP session. EPP query commands are those described in section 2.9.2 of EPP RFC 5730. If the RTT is 5-­‐times or more the corresponding SLR, the RTT will be considered undefined.

    4. EPP transform-­‐command RTT. Refers to the RTT of the sequence of packets that includes the sending of a transform command plus the reception of the EPP response for only one EPP transform command. It does not include packets needed for the start or close of either the EPP or the TCP session. EPP transform commands are those described in section

      2.9.3 of EPP RFC 5730. If the RTT is 5 times or more the corresponding SLR, the RTT will be considered undefined.

    5. EPP command RTT. Refers to “EPP session-­‐command RTT”, “EPP query-­‐ command RTT” or “EPP transform-­‐command RTT”.

    6. EPP test. Means one EPP command sent to a particular “IP address” for one of the EPP servers. Query and transform commands, with the exception of “create”, shall be about existing objects in the Registry System. The response shall include appropriate data from the Registry System. The possible results to an EPP test are: a number in milliseconds corresponding to the “EPP command RTT” or undefined/unanswered.

    7. Measuring EPP parameters. Every 5 minutes, EPP probes will select one “IP address” of the EPP servers of the TLD being monitored and make an “EPP test”; every time they should alternate between the 3 different types of commands and between the commands inside each category. If an “EPP test” result is undefined/unanswered, the EPP service will be considered as unavailable from that probe until it is time to make a new test.

    8. Collating the results from EPP probes. The minimum number of active testing probes to consider a measurement valid is 5 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.

    9. Placement of EPP probes. Probes for measuring EPP parameters shall be placed inside or close to Registrars points of access to the Internet across the different geographic regions; care shall be taken not to deploy probes behind high propagation-­‐delay links, such as satellite links.

  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 3.1(d)(ii) of this Agreement.


    Critical Function

    Emergency Threshold

    DNS Service (all servers)

    4-­‐hour total downtime / week

    DNSSEC proper resolution

    4-­‐hour total downtime / week

    EPP

    24-­‐hour total downtime / week

    RDDS (WHOIS/Web-­‐based WHOIS)

    24-­‐hour total downtime / week

    Data Escrow

    Breach of the Registry Agreement as described in Appendix 2, Part B, Section 6.

  7. Emergency Escalation

    Escalation is strictly for purposes of notifying and investigating possible or potential issues in relation to monitored services. The initiation of any escalation and the subsequent cooperative investigations do not in themselves imply that a monitored service has failed its performance requirements.

    Escalations shall be carried out between ICANN and Registry Operators, Registrars and Registry Operator, and Registrars and ICANN. Registry Operators and ICANN must provide said emergency operations departments. Current contacts must be maintained between ICANN and Registry Operators and published to Registrars, where relevant to their role in escalations, prior to any processing of an Emergency Escalation by all related parties, and kept current at all times.

    1. Emergency Escalation initiated by ICANN

      Upon reaching 10% of the Emergency thresholds as described in Section 6 of this Appendix, ICANN’s emergency operations will initiate an Emergency Escalation with the relevant Registry Operator. An Emergency Escalation consists of the following minimum elements: electronic (i.e., email or SMS) and/or voice contact notification to the Registry Operator’s emergency operations department with detailed information concerning the issue being escalated, including evidence of monitoring failures, cooperative trouble-­‐ shooting of the monitoring failure between ICANN staff and the Registry Operator, and the commitment to begin the process of rectifying issues with either the monitoring service or the service being monitoring.

    2. Emergency Escalation initiated by Registrars

      Registry Operator will maintain an emergency operations department prepared to handle emergency requests from registrars. In the event that a registrar is unable to conduct EPP transactions with the registry for the TLD because of a fault with the Registry Service and is unable to either contact (through ICANN mandated methods of communication) the Registry Operator, or the Registry Operator is unable or unwilling to address the fault, the registrar may initiate an emergency escalation to the emergency operations department of ICANN. ICANN then may initiate an emergency escalation with the Registry Operator as explained above.

    3. Notifications of Outages and Maintenance

      In the event that a Registry Operator plans 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.

      If Registry Operator declares an outage, as per its contractual obligations with ICANN, on services under a service level agreement and performance requirements, it will notify the ICANN emergency operations department. During that declared outage, ICANN’s emergency operations department will note and suspend emergency escalation services for the monitored services involved.

  8. Covenants of Performance Measurement

    1. 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 DNS and RDDS) or registrar (for EPP).

    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.

  9. DNSSEC

Registry Operator shall sign its TLD zone files implementing Domain Name System Security Extensions (“DNSSEC”). During the Term, Registry Operator shall comply with RFCs 4033, 4034, 4035, 4509 and their successors, and follow the best practices described in RFC 4641 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.