Registry Services Agreement: Definitions, ICANN Oversight, and Data Access, Study notes of Business

Download Registry Services Agreement: Definitions, ICANN Oversight, and Data Access and more Study notes Business in PDF only on Docsity! FINAL DRAFT LAI-2199788v2 [THIS DRAFT AGREEMENT IS SUBJECT TO APPROVAL AND FURTHER CHANGE] SPONSORED TLD REGISTRY AGREEMENT This SPONSORED TLD REGISTRY AGREEMENT (this "Agreement") is entered into as of ___________, 2005 by and between Internet Corporation for Assigned Names and Numbers, a California nonprofit public benefit corporation, and Fundació puntCAT, Fundació Privada, a Catalonia private foundation. ARTICLE I INTRODUCTION Section 1.1 Effective Date. The Effective Date for purposes of this Agreement shall be the date on which the TLD (as defined below) is delegated within the authoritative root- server system to nameservers designated by Registry. Section 1.2 Top-Level Domain. The Top-Level Domain to which this Agreement applies is .CAT ("TLD"). Section 1.3 Designation as Registry . Upon the Effective Date, until the Expiration Date as defined in Section 4.1 hereof, ICANN hereby designates Fundació puntCAT as the sponsoring organization, and sole registry for the sponsored TLD ("Registry "). ICANN hereby delegates to Registry the authority to develop policies for the sponsored TLD consistent with the requirements of Section 3.1(g) of this Agreement ARTICLE II REPRESENTATIONS AND WARRANTIES Section 2.1 Registry's Representations and Warranties. (a) Organization; Due Authorization and Execution. Registry is a Private Foundation, duly organized, validly existing and in good standing under the laws of the Autonomous Community of Catalonia; the Kingdom of Spain and the European Union, in their respective areas of competence, and Registry has all requisite power and authority to enter into this Agreement. All corporate approvals and actions necessary for the entrance by Registry into this Agreement have been obtained and this Agreement has been duly and validly executed and delivered by Registry. (b) Statements made During Application Process. The factual statements contained in Registry’s application for the TLD, or made by Registry Operator in negotiating this Agreement, were true and correct in all material respects at the time the application was submitted to ICANN and are true and correct in all material respects as of the date this Agreement is entered into set forth above. ICANN's Representations and Warranties. - 2 - LAI-2199788v2 (a) Organization; Due Authorization and Execution. ICANN is a nonprofit public benefit corporation duly organized, validly existing and in good standing under the laws of California. ICANN has all requisite corporate power and authority to enter into this Agreement. All corporate approvals and actions necessary for the entrance by ICANN into this Agreement have been obtained and this Agreement has been duly and validly executed and delivered by ICANN. ARTICLE III COVENANTS Section 3.1 Covenants of Registry. Registry covenants and agrees with ICANN as follows: (a) Preserve Security and Stability. (i) ICANN Temporary Specifications or Policies. Registry shall comply with and implement all specifications or policies established by the ICANN Board of Directors on a temporary basis, if adopted by the ICANN Board of Directors by a vote of at least two-thirds of its members, so long as the ICANN Board of Directors reasonably determines that immediate temporary establishment of a specification or policy on the subject is necessary to maintain the Stability or Security (as defined in Section 3.1(d)(iv)(G)) of Registry Services or the DNS (“Temporary Specification or Policies”). Such proposed specification or policy shall be as narrowly tailored as feasible to achieve those objectives. In establishing any specification or policy under this provision, the ICANN Board of Directors shall state the period of time for which the specification or policy is temporarily adopted and shall immediately implement the Consensus Policy development process set forth in ICANN's Bylaws. ICANN shall also issue an advisory statement containing a detailed explanation of its reasons for adopting the temporary specification or policy and why the Board believes the specification or policy should receive the consensus support of Internet stakeholders. If the period of time for which the specification or policy is adopted exceeds 90 days, the ICANN Board shall reaffirm its temporary adoption every 90 days for a total period not to exceed one year, in order to maintain such policy in effect until such time as it shall become a Consensus Policy as described in Section 3.1(b) below. If during such one year period, the temporary policy or specification does not become a Consensus Policy meeting the standard set forth in Section 3.1(b) below, Registry shall no longer be required to comply with or implement such temporary policy or specification. - 5 - LAI-2199788v2 and private portions of TLD zone key-signing keys and zone-signing keys). The escrow agent or mirror-site manager, and the obligations thereof, shall be mutually agreed upon by ICANN and Registry on commercially reasonable standards that are technically and practically sufficient to allow a successor registry operator to assume management of the TLD. To this end, Registry shall periodically deposit into escrow all Registry Data on a schedule (not more frequently than weekly for a complete set of Registry Data, and daily for incremental updates) and in an electronic format mutually approved from time to time by Registry and ICANN, such approval not to be unreasonably withheld by either party. In addition, Registry will deposit into escrow that data collected from registrars as part of offering Registry Services introduced after the Effective Date of this Agreement. The escrow shall be maintained, at Registry's expense, by a reputable escrow agent mutually approved by Registry and ICANN, such approval also not to be unreasonably withheld by either party. The schedule, content, format, and procedure for escrow deposits shall be as reasonably established by ICANN from time to time, and as set forth in Appendix 1 hereto. Changes to the schedule, content, format, and procedure may be made only with the mutual written consent of ICANN and Registry (which neither party shall unreasonably withhold) or through the establishment of a Consensus Policy as outlined in Section 3.1(b) above. The escrow shall be held under an agreement, substantially in the form of Appendix 2, as the same may be revised from time to time, among ICANN, Registry , and the escrow agent. The escrow will contain DNSSEC-related material only after Registry implements it in the future. (ii) Personal Data. Registry shall notify registrars sponsoring registrations in the registry for the TLD of the purposes for which Personal Data (as defined below) submitted to Registry by registrars, if any, is collected, the intended recipients (or categories of recipients) of such Personal Data, and the mechanism for access to and correction of such Personal Data. Registry shall take reasonable steps to protect Personal Data from loss, misuse, unauthorized disclosure, alteration or destruction. Registry shall not use or authorize the use of Personal Data in a way that is incompatible with the notice provided to registrars. "Personal Data" shall refer to all data about any identified or identifiable natural person. (iii) Bulk Zone File Access. Registry shall provide bulk access to the zone files for the registry for the TLD to ICANN on a reasonable basis in the manner ICANN may specify from time to time. Bulk access to the zone files shall be provided to third parties on the terms set forth in the TLD zone file access agreement reasonably established by ICANN, which initially shall be in the form attached as Appendix 3 hereto. Changes to the zone file access agreement may be made upon the mutual written consent of ICANN and Registry (which consent neither party shall unreasonably withhold). - 6 - LAI-2199788v2 (iv) Monthly Reporting. Within 20 days following the end of each calendar month, Registry shall prepare and deliver to ICANN a report providing such data and in the format specified in Appendix 4. ICANN may audit Registry 's books and records relating to data contained in monthly reports 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, unless such audit shall reflect a material discrepancy or discrepancies in the data provided by Registry . In the latter event, Registry shall reimburse ICANN for all costs and expenses associated with such audit, which reimbursement shall be paid together with the next Registry-Level Fee payment due following the date of transmittal of the cost statement for such audit. For purposes of this section, a "material discrepancy or discrepancies" shall be a discrepancy or discrepancies that, in the singular for the aggregate, result in an understatement in excess of 5% of the fees owed to ICANN by Registry under section 7.2. (v) Whois Service. Registry shall provide such whois data as set forth in Appendix 5 and Part VI of Appendix S. (d) Registry Operations. (i) Registration Restrictions. (A) Registry shall be responsible for establishing policies, in conformity with the charter, for the naming conventions within the sponsored TLD and for requirements of registration, consistent with Section 3.1(g). (B) Registry shall be responsible for establishing procedures for the enforcement of applicable Charter restrictions on registration within the TLD, as described in more detail in the sponsored TLD charter attached as Part I to Appendix S. (C) Registry shall reserve, and not register any TLD strings (i) appearing on the list of reserved TLD strings attached as Appendix 6 hereto or (ii) located at http://data.iana.org/TLD/tlds-alpha-by- domain.txt for initial (i.e., other than renewal) registration at the second level within the TLD. (ii) 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. Registry shall keep technical and operational records sufficient to evidence compliance with such specifications for at least one year, which records ICANN may audit from - 7 - LAI-2199788v2 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. (iii) Registry Services. Registry Services are, for purposes of this Agreement, defined as the following: (a) those services that are operations of the registry critical to the following tasks: the receipt of data from registrars concerning registrations of domain names and name servers; provision to registrars of status information relating to the zone servers for the TLD; dissemination of TLD zone files; operation of the registry zone servers; and dissemination of contact and other information concerning domain name server registrations in the TLD as required by this Agreement; (b) other products or services that the Registry is required to provide because of the establishment of a Consensus Policy (as defined in Section 3.1(b) above); (c) any other products or services that only a Registry operator is capable of providing, by reason of its designation as the registry operator; and (d) material changes to any Registry Service within the scope of (a), (b) or (c) above. (iv) Process for Consideration of Proposed Registry Services. Following written notification by Registry to ICANN that Registry may make a change in a Registry Service within the scope of the preceding paragraph: (A) ICANN shall have 15 calendar days to make a “preliminary determination” whether a Registry Service requires further consideration by ICANN because it reasonably determines such Registry Service: (i) could raise significant Security or Stability issues or (ii) could raise significant competition issues. (B) Registry must provide sufficient information at the time of notification to ICANN that it may implement such a proposed Registry Service to enable ICANN to make an informed “preliminary determination.” Information provided by Registry and marked “CONFIDENTIAL” shall be treated as confidential by ICANN. Registry will not designate “CONFIDENTIAL” information necessary to describe the purpose of the proposed Registry Service and the effect on users of the DNS. (C) ICANN may seek expert advice during the preliminary determination period (from entities or persons subject to confidentiality agreements) on the competition, Security or Stability implications of the Registry Service in order to make its “preliminary determination.” To the extent ICANN determines to disclose confidential information to any such experts, it will provide notice to Registry of the identity of the expert(s) and the information it intends to convey. - 10 - LAI-2199788v2 agreement requiring that they shall consider the issues before the panel neutrally and according to the definitions of Security and Stability. For each matter referred to the Standing Panel, the Chair shall select no more than five members from the Standing Panel to evaluate the referred matter, none of which shall have an existing competitive, financial, or legal conflict of interest, and with due regard to the particular technical issues raised by the referral. (e) Fees and Payments. Registry shall pay the Registry-Level Fees to ICANN on a quarterly basis in accordance with Section 7.2 hereof. (f) Cooperation. Registry shall cooperate with ICANN in efforts to promote and facilitate the security and stability of the Internet and maintain a reliable and stable DNS. To this end, Registry shall provide such data and assistance to ICANN as it may reasonably request from time to time. (g) General Obligations of Registry to Sponsored Community. During the Term of this Agreement, Registry shall, in developing or enforcing standards, policies, procedures, or practices with respect to the TLD: (i) publish such standards, policies, procedures, and practices so they are available to members of the sponsored TLD community; (ii) conduct its policy-development activities in a manner that reasonably provides opportunities for members of the sponsored TLD community to discuss and participate in the development of such standards, policies, procedures, or practices; (iii) maintain the representativeness of its policy-development and implementation process by establishing procedures that facilitate participation by a broad cross-section of the sponsored TLD community; and (iv) ensure, through published procedures, adequate opportunities for members of the sponsored TLD community to submit their views on and objections to the establishment or revision of standards, policies, procedures, and practices or the manner in which standards, policies, procedures, and practices are enforced. Section 3.2 Covenants of ICANN. ICANN covenants and agrees with Registry as follows: (a) Open and Transparent. Consistent with ICANN’s expressed mission and core values, ICANN shall operate in an open and transparent manner. (b) Equitable Treatment. ICANN shall not apply standards, policies, procedures or practices arbitrarily, unjustifiably, or inequitably and shall not single out - 11 - LAI-2199788v2 Registry for disparate treatment unless justified by substantial and reasonable cause. (c) TLD Zone Servers. In the event and to the extent that ICANN is authorized to set policy with regard to an authoritative root server system, it will ensure that (i) the authoritative root will point to the TLD zone servers designated by Registry for the Registry TLD throughout the Term of this Agreement; and (ii) any changes to the TLD zone server designation submitted to ICANN by Registry will be implemented by ICANN within seven days of submission. (d) Nameserver Changes. Registry may request changes in the nameserver delegation for the Registry TLD. Any such request must be made in a format, and otherwise meet technical requirements, specified from time to time by ICANN. ICANN will use commercially reasonable efforts to have such requests implemented in the Authoritative Root-Server System within seven calendar days of the submission. (e) Root-zone Information Publication. ICANN's publication of root-zone contact information for the Registry TLD will include Registry and its administrative and technical contacts. Any request to modify the contact information for the Registry must be made in the format specified from time to time by ICANN. ARTICLE IV TERM OF AGREEMENT Section 4.1 Term. The initial term of this Agreement shall be ten (10) years from the Effective Date (the “Expiration Date”). Registry agrees that upon the earlier of (i) termination of this Agreement by ICANN in accordance with Article VI below or (ii) the Expiration Date, it will cease to be the Registry for the TLD, unless, with respect to termination under the foregoing clause (ii), Registry and ICANN agree on terms for renewal of the Agreement as set forth in Section 4.2 below prior to the Expiration Date. Section 4.2 Renewal. This Agreement shall be renewed upon the expiration of the initial term set forth in Section 4.1 above, and following any renewal term, unless: (i) an arbitrator or court has determined that Registry has been in fundamental and material breach of Registry’s obligations set forth in Sections 3.1(a), (b), (d) or (e); Section 5.2 or Section 7.3 despite notice and an opportunity to cure in accordance with Article VI hereof and (ii) following the final decision of such arbitrator or court, Registry has failed to correct the conduct found to constitute such breach. Provided, however, that Registry agrees that any renewal of this Agreement is conditioned on its negotiation of renewal terms acceptable to ICANN, including, but not limited to, provisions relating to registry- level fees. Section 4.3 Changes. While this Agreement is in effect, the parties agree to engage in good faith negotiations at regular intervals (at least once every three calendar years following the Effective Date) regarding possible changes to the terms of the Agreement, including to Section 7.2 regarding fees and payments to ICANN. - 12 - LAI-2199788v2 Section 4.4 Failure to Perform in Good Faith. In the event Registry shall have been repeatedly and willfully in fundamental and material breach of Registry Operator’s obligations set forth in Sections 3.1(a), (b), (d) or (e); Section 5.2 or Section 7.3, and arbitrators in accordance with Section 5.1(b) of this Agreement repeatedly have found Registry to have been in fundamental and material breach of this Agreement, including in at least three separate awards, then ICANN may request the arbitrators award such punitive, exemplary or other damages as they may believe appropriate under the circumstances. ARTICLE V DISPUTE RESOLUTION Section 5.1 Resolution of Disputes. (a) Cooperative Engagement. In the event of a disagreement between Registry and ICANN arising under or out of this Agreement, either party may by notice to the other invoke the dispute resolution provisions of this Article V. Provided, however, that before either party may initiate arbitration as provided in Section 5.1(b) below, ICANN and Registry must attempt to resolve the dispute by cooperative engagement as set forth in this Section 5.1(a). If either party provides written notice to the other demanding cooperative engagement as set forth in this Section 5.1(a), then each party will, within seven calendar days after such written notice is deemed received in accordance with Section 8.6 hereof, designate a single executive officer as its representative under this Section 5.1(a) with full authority to act on such party's behalf to resolve the dispute. The designated representatives shall, within 2 business days after being designated, confer by telephone or in person to attempt to resolve the dispute. If they are not able to resolve the dispute during such telephone conference or meeting, they shall further meet in person at a location reasonably designated by ICANN within 7 calendar days after such initial telephone conference or meeting, at which meeting the parties shall attempt to reach a definitive resolution. The time schedule and process set forth in this Section 5.1(a) may be modified with respect to any dispute, but only if both parties agree to a revised time schedule or process in writing in advance. Settlement communications within the scope of this paragraph shall be inadmissible in any arbitration or litigation between the parties. (b) Arbitration. Disputes arising under or in connection with this Agreement, including requests for specific performance, shall be resolved through binding arbitration conducted as provided in this Section 5.1(b) pursuant to the rules of the International Court of Arbitration of the International Chamber of Commerce ("ICC"). The arbitration shall be conducted in the English language and shall occur in Los Angeles County, California, USA only following the failure to resolve the dispute pursuant to cooperative engagement discussions as set forth in Section 5.1(a) above. There shall be three arbitrators: each party shall choose one arbitrator and, if the two arbitrators are not able to agree on a third arbitrator, the third shall be chosen by the ICC. The prevailing party in the arbitration shall have the right to recover its costs and reasonable attorneys' fees, which the - 15 - LAI-2199788v2 payments to a successor registry operator by reason of registry fees paid to Registry prior to the effective date of (i) any termination or expiration of this Agreement or (ii) transition of the registry, unless any delay in transition of the registry to a successor operator shall be due to the actions of Registry. ARTICLE VII SPECIAL PROVISIONS Section 7.1 Registry-Registrar Agreement. (a) Access to Registry Services. Registry shall make access to Registry Services, including the shared registration system, available to ICANN-accredited registrars. The criteria for the selection of Registrars shall be set forth in Appendix S, part V. Following execution of the Registry-Registrar Agreement, provided registrars are in compliance with such agreement, operational access to Registry Services, including the shared registration system for the TLD. Such nondiscriminatory access shall include without limitation the following: (i) All registrars (including any registrar affiliated with Registry) can connect to the shared registration system gateway for the TLD via the Internet by utilizing the same maximum number of IP addresses and SSL certificate authentication; (ii) Registry has made the current version of the registrar toolkit software accessible to all registrars and has made any updates available to all registrars on the same schedule; (iii) All registrars have the same level of access to customer support personnel via telephone, e-mail and Registry 's website; (iv) All registrars have the same level of access to registry resources to resolve registry/registrar or registrar/registrar disputes and technical and/or administrative customer service issues; (v) All registrars have the same level of access to data generated by Registry to reconcile their registration activities from Registry's Web and ftp servers; (vi) All registrars may perform basic automated registrar account management functions using the same registrar tool made available to all registrars by Registry; and (vii) The shared registration system does not include, for purposes of providing discriminatory access, any algorithms or protocols that differentiate among registrars with respect to functionality, including database access, system priorities and overall performance. - 16 - LAI-2199788v2 Such Registry-Registrar Agreement may be revised by Registry from time to time, provided however, that any such revisions must be approved in advance by ICANN. (b) Registry Shall Not Act as Own Registrar. Registry shall not act as a registrar with respect to the TLD. This shall not preclude Registry from registering names within the TLD to itself through a request made to an ICANN-accredited registrar. (c) Restrictions on Acquisition of Ownership or Controlling Interest in Registrar. Registry shall not acquire, directly or indirectly, control of, or a greater than fifteen percent ownership interest in, any ICANN-accredited registrar. Section 7.2 Fees to be Paid to ICANN. (a) Payment Schedule. Registry shall pay the Registry-Level Fees specified in Sections 7.2(b) and (c) below, and Section 7.2(d), if applicable, by the 20th day following the end of each calendar quarter (i.e., on April 20, July 20, October 20 and January 20 for the calendar quarters ending March 31, June 30, September 30 and December 31) of the year to an account designated by ICANN. The first quarterly payment of the Fixed Registry-Level Fee shall be prorated from the Effective Date until the end of the calendar quarter in which the Effective Date falls. (b) Fixed Registry-Level Fee. Commencing on the Effective Date, Registry shall pay ICANN a quarterly Fixed Registry-Level Fee in an amount equal to US$2,500 for each quarter during the twelve-month period ending June 30, 2006. Such fee is subject to increase on July 1 of each year thereafter in an amount established by ICANN’s Board of Directors, but not to exceed a sum equal to 115% of the prior year’s fee. One dollar (USD) of the Fixed Registry-Level Fee shall be waived for each dollar that the Registry-Level Transaction Fee exceeds US$2,000,000 per annum. (c) Registry-Level Transaction Fee. Commencing as of the Effective Date Registry shall pay ICANN a Registry-Level Transaction Fee in an amount equal to US$1.00 for each annual increment of an initial or renewal domain name registration or for transferring a domain name registration from one ICANN- accredited registrar to another during the calendar quarter to which the Registry- Level Transaction Fee pertains. For purposes of this Section 7.2(c), a “domain name registration” shall include a domain name within the registry for the TLD, whether consisting of two or more (e.g., john.smith.name) levels, about which Registry or an affiliate thereof maintains Registry Data. The Registry-Level Transaction fee shall not apply to domain names registered according to those services described in Part VII of Appendix S (d) Variable Registry-Level Fee. For fiscal quarters in which ICANN does not collect a variable accreditation fee from all registrars, upon receipt of reasonable notice in writing from ICANN of not less than 45 days, Registry shall pay ICANN - 17 - LAI-2199788v2 a Variable Registry-Level Fee. The fee will be calculated by ICANN, paid to ICANN by the Registry in accordance with the Payment Schedule in Section 7.2(a), and the Registry will invoice and collect the fees from the registrars who are party to a Registry-Registrar Agreement with Registry. The fee will consist of two components; each component will be calculated by ICANN for each registrar. (i) The transactional component of the Variable Registry-Level Fee shall be specified by ICANN in accordance with the budget adopted by the ICANN Board of Directors for each fiscal year but shall not exceed eighty percent (80%) of the registrar level transaction fee as established pursuant to the approved 2004-2005 ICANN Budget. (ii) The per-registrar component of the Variable Registry-Level Fee shall be specified by ICANN in accordance with the budget adopted by the ICANN Board of Directors for each fiscal year, but the sum of the per registrar fees calculated for all registrars shall not exceed the total Per- Registrar Variable funding established pursuant to the approved 2004- 2005 ICANN Budget. (e) Interest on Late Payments. For any payments ten days or more overdue, Registry shall pay interest on late payments at the rate of 1.5% per month or, if less, the maximum rate permitted by applicable law. ARTICLE VIII MISCELLANEOUS Section 8.1 Indemnification of ICANN. Registry shall indemnify, defend, and hold harmless ICANN (including its directors, officers, employees, and agents) from and against any and all claims, damages, liabilities, costs, and expenses, including reasonable legal fees and expenses, arising out of or relating to: (a) the selection of Registry to operate the registry for the TLD; (b) the entry of this Agreement; (c) establishment or operation of the registry for the TLD; (d) Registry Services; (e) collection or handling of Personal Data by Registry; (f) any dispute concerning registration of a domain name within the domain of the TLD for the registry; and (g) duties and obligations of Registry in operating the registry for the TLD; provided that, with respect to item (g) only, Registry shall not be obligated to indemnify, defend, or hold harmless ICANN to the extent the claim, damage, liability, cost, or expense arose due to a breach by ICANN of any obligation contained in this Agreement. For avoidance of doubt, nothing in this Section 8.1 shall be deemed to require Registry to reimburse or otherwise indemnify ICANN for the costs associated with the negotiation or execution of this Agreement, or with the monitoring or management of the parties' respective obligations under this Agreement. Further, this section shall not apply to any request for attorney's fees in connection with any litigation or arbitration between or among the parties. Section 8.2 Indemnification Procedures. If any third-party claim is commenced that is indemnified under Section 8.1 above, notice thereof shall be given to ICANN as promptly as practicable. Registry shall be entitled, if it so elects, in a notice promptly - 20 - LAI-2199788v2 Section 8.10 Counterparts. This Agreement may be executed in one or more counterparts, each of which shall be deemed an original, but all of which together shall constitute one and the same instrument. Section 8.11 Entire Agreement. This Agreement (including its Appendices, which form a part of it) constitutes the entire agreement of the parties hereto pertaining to the operation of the TLD and supersedes all prior agreements, understandings, negotiations and discussions, whether oral or written, between the parties on that subject. In the event of a conflict between the provisions in the body of this Agreement and any provision in its Appendices, the provisions in the body of the Agreement shall control. - 21 - LAI-2199788v2 IN WITNESS WHEREOF, the parties hereto have caused this Agreement to be executed by their duly authorized representatives. INTERNET CORPORATION FOR ASSIGNED NAMES AND NUMBERS By:_____________________________ [insert name of official] [insert title of official] Date: Fundació puntCAT By:_____________________________ [insert name of official] [insert title of official] Date: .CAT SPONSORED TLD REGISRY AGREEMENT LIST OF APPENDICES Appendix 1 Data Escrow Specification Exhibit A Schedule For Escrow Deposits Exhibit B Escrow Deposit Format Specification Exhibit C Escrow Transfer Process Exhibit D Escrow Verification Procedures Appendix 2 Escrow Agreement Appendix 3 Zone File Access Agreement Appendix 4 Registry's Monthly Report Appendix 5 Whois Specifications Appendix 6 Schedule Of Reserved Names Appendix 7 Functional And Performance Specifications Appendix S Part I .cat sTLD Charter Part II Delegated Authority Part III Description of .cat Sponsored TLD Community Part IV Start-Up Plan Part V Selection of Registrars Part VI Public Whois Part VII Additional Provisions Exhibit A Community-Assigned Names - 4 - Appendix 1 - Exhibit B ESCROW DEPOSIT FORMAT SPECIFICATION Each Full and Incremental Deposit consists of a series of reports that are concatenated in the escrow process. Full Deposit Contents. The reports involved in a Full Deposit are: Domain Object Report – This reports on the contents of all domain objects in the registry database. Host Object Report – This reports on the contents of all host objects in the registry database. Contact Object Report – This reports on the contents of all contact objects in the registry database. Registrar Object Report – This reports on the contents of all registrar objects in the registry database. Incremental Deposit Contents. The report involved in an Incremental Deposit is: Transaction Report – This reports on the contents of all transaction records included in the Incremental Deposit. Format of Reports. All reports are to be formatted in XML format. In compliance with the XML 1.0 specification, certain characters in the data must be escaped, as described in item 1 below. Each Report shall then be prepared according to the general XML format described in items 2 to 7 below. Item 2 describes the report container that is common to all reports. Items 3 to 7 describe the structure of the contents of the report container for each of the specific reports. 1. Escape-Character Requirements. In compliance with the XML 1.0 specification, in data escrowed using the XML format the following characters in any data elements must be replaced with the corresponding escape sequences listed here: - 5 - Character Escape Sequence " &quot; & &amp; ' &apos; < &lt; > &gt 2. The Report Container. At its highest level, the XML format consists of an escrow container with header attributes followed by escrow data. The header attributes are required and include the version of escrow (1.0), the Sponsored TLD (".cat"), the report type (domain, host, contact, registrar, or transaction), and database-committed date and time as to which the escrow relates. The date and time of the escrow will be specified in UTC. The general format of the report container is as follows: <?xml version="1.0" encoding='UTF-8' ?> <!DOCTYPE escrow SYSTEM "whois-export.dtd" > <escrow version="1.0" tld="cat" report="domain" date="26-Aug-2005 3:15:00AM"> {Here the report contains the actual data being escrowed. It contains one element for each object of the type (domain, host, contact, registrar, or transaction) covered by the report. The specific format for each report is described in items 3 to 7 below.} </escrow> 3. The Domain Element. The domain element has the property "fqdn" (the fully qualified name of the domain) and is a container consisting of the following elements: a. variant: optional multiple IDN variant names. b. idn-language: the language associated with the IDN c. status: The domain status code. d. id: Unique identifier of the domain name e. owned-by: An identification of the sponsoring registrar of the domain. - 6 - The sponsoring registrar is designated by a number uniquely assigned by the IANA. f. ens-auth-id: ENS authorization code. g. authinfo: the EPP authentication information. h. maintainer-url: URL of site of maintainer of domain name. i. created-code: A reference to the transaction that created the domain object. j. created-on: The date/time the domain object was originally created. k. created-by: An identification of the registrar that created the domain object. The sponsoring registrar is designated by a number uniquely assigned by the IANA. l. renewed-on: The date/time the domain was last renewed. m. expires-on: The date the registration expires. n. updated-by: An identification of the registrar that last updated the domain object. The sponsoring registrar is designated by a number uniquely assigned by the IANA. o. updated-on: The date/time the domain object was last updated. p. transferred-by: An identification of the registrar that last transferred the domain object. The sponsoring registrar is designated by a number uniquely assigned by the IANA. q. transferred-on: The date/time when the domain object was last transferred. r. transferred-code: A reference to the transaction that last transferred the domain object. s. host: Up to thirteen (13) host names that are nameservers for the domain to which the domain object relates. t. contact-id: Multiple contact-ids that reference the contact records for this domain. Contact-id has the property "type" to denote the type of contact. "Type" can be one of: Registrant, Administrative, Technical, or Billing An example domain container appears below: - 9 - e. street3: The third part of the street address of the contact. f. city: The name of the city of the contact. g. state-province: The name of the state/province of the contact. h. postal-code: The postal/zip code of the contact. i. country: The two letter ISO 3166 code for the contact's country. j. voice: The voice phone number of the contact in E164a format. k. fax: The fax number of the contact in E164a format. l. email: The e-mail address of the contact. m. authinfo: the EPP authentication information. n. maintainer-url: URL of site of maintainer of contact. o. owned-by: An identification of the sponsoring registrar of the contact. The sponsoring registrar is designated by a number uniquely assigned by the IANA. p. created-code: A reference to the transaction that created the contact object. q. created-by: An identification of the registrar that created the contact object. The sponsoring registrar is designated by a number uniquely assigned by the IANA. r. created-on: The date/time the contact object was originally created. s. updated-by: An identification of the registrar that last updated the contact object. The sponsoring registrar is designated by a number uniquely assigned by the IANA. t. updated-on: The date/time the contact object was last updated. u. transferred-by: An identification of the registrar that last transferred the contact object. The sponsoring registrar is designated by a number uniquely assigned by the IANA. v. transferred-on: The date/time when the contact object was last transferred. w. transferred-code: A reference to the transaction that last transferred the - 10 - contact object. x. status: Contact status. An example contact container appears below: <contact id="1"> <name>John Doe</name> <organization>aol</organization> <street1>1234 East 11th Street</street1> <street2></street2> <street3></street3> <city>New York</city> <state-province>NY</state-province> <postal-code>12345</postal-code> <country>US</country> <voice>+212.1234567</voice> <fax>+212.1234568</fax> <email>jdoe@example.cat</email> <authinfo>anotherSecret</authinfo> <owned-by>42</owned-by> <maintainer-url>http://example.cat</maintainer-url> <created-code>12345680</created-code> <created-by>REG-042</created-by> <created-on>1-Jul-2001 12:42:22AM</created-on> <updated-by>42</updated-by> <updated-on>1-Jul-2001 12:42:22AM</updated-on> <transferred-by></transferred-by> <transferred-on></transferred-on> <transferred-code></transferred-code> <status>ACTIVE</status> </contact> 6. The Registrar Element. The registrar element has the property "id" and is a container consisting of the following elements: a. password: The password for the registrar. b. name: The name of the registrar. c. status: The registrar status code. - 11 - d. contact-id: Any number of contact-id associated with this registrar. Contact-id has the property "type" to denote the type of contact. "Type" can be one of: Registrar, Administrative, Technical or Billing An example registrar container appears below: <registrar id="REG-042"> <password>registrarrus</password> <name>Registrar R Us</name> <status>ACTIVE</status> <contact-id type="Registrar">PER-0009</contact-id> <contact-id type="Administrative">PER-0010</contact-id> <contact-id type="Administrative">PER-0011</contact-id> <contact-id type="Technical">PER-0012</contact-id> <contact-id type="Technical">PER-0013</contact-id> <contact-id type="Billing">PER-0014</contact-id> </registrar> 7. The Transaction Element. The transaction element has the properties "operation" and "type.” "Operation" can be one of: add, modify or delete. "Type" can be one of: domain, host, contact or registrar. The transaction element is a container consisting of elements from the corresponding "type" element. For example, a transaction element with a "type" of "registrar" will have the same set of elements as a Registrar element. An example transaction container appears below: <transaction operation="modify" type="registrar"> <password>new password</password> <name>Registrar R Us</name> <status>ACTIVE</status> <contact-id type="Administrative">10</contact-id> <contact-id type="Administrative">11</contact-id> <contact-id type="Technical">12</contact-id> <contact-id type="Technical">13</contact-id> <contact-id type="Billing">14</contact-id> </transaction> - 14 - Appendix 2 Escrow Agreement This Registry Data Escrow Agreement ("Agreement") is made as of this [enter date] (the "Beginning Date"), by and between Fundació puntCAT ("Registry"), [name of Escrow Agent] ("Escrow Agent"), and the Internet Corporation for Assigned Names and Numbers ("ICANN"). All capitalized terms not defined herein shall have the meaning set forth in the Sponsored TLD Registry Agreement dated [insert date of Sponsored TLD Registry Agreement] by and between Registry and ICANN ("Sponsored TLD Registry Agreement"). Recitals A. Registry and ICANN have entered into the .cat Sponsored TLD Registry Agreement, which requires Registry, during the term of the .cat Sponsored TLD Registry Agreement, to ensure the submission of certain domain name registration data to a reputable escrow agent to be held in escrow. B. Pursuant to the .cat Sponsored TLD Registry Agreement, Registry shall ensure the periodic delivery to Escrow Agent of an electronic copy of all Registry Data, as detailed in Subsection 3.1(c) of the .cat Sponsored TLD Registry Agreement (each such delivery referred to as a "Deposit"). C. Registry and ICANN each desire Escrow Agent to hold each Deposit, and, upon certain events, release any retained Deposits (or a copy of the Deposits) to ICANN, in accordance with the terms of this Agreement or as ordered by a court of competent jurisdiction. Now, therefore, in consideration of the premises and mutual obligations contained herein and for other good and valuable consideration, the receipt and sufficiency of which are hereby acknowledged, the parties agree as follows: Agreement 1. Content of Deposits. Deposits will be of two kinds: Full Deposits and Incremental Deposits. Each Full Deposit will consist of Registry Data that reflects the current and complete Registry Database. Incremental Deposits will consist of data that reflects all transactions involving the database that - 15 - are not reflected in the last previous Full Deposit or Incremental Deposit, as the case may be. 2. Schedule for Deposits. Registry must instruct the creation and delivery to Escrow Agent of a Full Deposit once each week, according to the schedule specified in Exhibit A of Appendix 1 to the .cat Sponsored TLD Registry Agreement. Registry must instruct the creation and delivery to Escrow Agent of an Incremental Deposit once each day during which a Full Deposit is not made, according to the schedule specified in Exhibit A of Appendix 1. 3. Format of Deposits. The data in each Full Deposit and in each Incremental Deposit shall follow the data format specified in the Escrow Deposit Format Specification (the "Format Specification"), attached as Exhibit B of Appendix 1. 4. Procedure for Deposits. Each properly formatted Full Deposit and Incremental Deposit shall be processed and electronically delivered in encrypted form to Escrow Agent according to the transfer process described in Exhibit C of Appendix 1. 5. Notification of Deposits. Simultaneous with the delivery to Escrow Agent of any Full or Incremental Deposit, Registry shall instruct the delivery to Escrow Agent and ICANN of a written statement (which may be by authenticated e-mail) that includes a copy of the report generated upon creation of the Full or Incremental Deposit by the ICANN-provided software (as described in Exhibit C of Appendix 1) and states that the Full or Incremental Deposit (as the case may be) has been inspected by Registry (or Registry ’s agent at Registry ’s direction) according to the procedures described in Exhibit C of Appendix 1 and is complete and accurate. Escrow Agent shall notify ICANN of all Deposits received, within two business days of receipt. 6. Verification. Within two business days after receiving each Full or Incremental Deposit, Escrow Agent shall verify the format and completeness of each Deposit by performing the verification procedures specified in Exhibit D of Appendix 1 and shall deliver to ICANN a copy of the verification report generated for each Deposit (which may be by authenticated e-mail). If Escrow Agent discovers that any Deposit fails the verification procedures, Escrow Agent shall notify, including by email and fax, Registry and ICANN of such nonconformity within forty-eight hours of discovery. Upon notification of such verification failure, Registry shall - 16 - instruct the beginning of the development of modifications, updates, corrections, and other fixes of the Full or Incremental Deposit necessary for the Deposit to pass the verification procedures and shall instruct the delivery of such fixes to Escrow Agent as promptly as possible. Escrow Agent shall verify the accuracy or completeness of any such corrected Deposit pursuant to the procedures in this Section 6 and shall send ICANN a copy of the successful report within twenty-four hours. The failure of any Full or Incremental Deposit to meet verification procedures and any efforts by Registry to remedy such failure shall not delay the delivery of any subsequent scheduled Full or Incremental Deposits pursuant to the schedule in Exhibit A of Appendix 1. Escrow Agent shall deliver, on the first business day of each month, (i) a written certification to ICANN that Escrow Agent has performed such verification procedures on each Deposit received during the last month, and (ii) copies of the verification reports generated for each Deposit received during the last month. 7. Retention and Confidentiality. 7.1 Retention. Escrow Agent shall hold and maintain the Deposits in a secure, locked, and environmentally safe facility that is accessible only to authorized representatives of Escrow Agent. Escrow Agent shall use commercially reasonable efforts to protect the integrity of the Deposits. ICANN and Registry shall have the right to inspect Escrow Agent's written records with respect to this Agreement upon reasonable prior notice and during normal business hours. 7.2 Destruction of Deposits. At all times, Escrow Agent shall retain the four most recent Full Deposits and all Incremental Deposits after the earliest of those four Full Deposits, all of which must have passed the verification procedures specified in Exhibit D of Appendix 1. Escrow Agent may destroy any Deposits reflecting the Registry Database prior to these four most recent Full Deposits. 7.3 Confidentiality. Escrow Agent shall use commercially reasonable efforts to protect the confidentiality of the Deposits. Except as provided in this Agreement, Escrow Agent shall not disclose, transfer, make available, or use any Deposit (or any copies of any Deposit). Should Escrow Agent be put on notice that it is required to disclose any Deposits by statute, rule, regulation, order, or other requirement of a governmental agency, legislative body, court of competent jurisdiction, or binding arbitral body (other than any - 19 - other requirement that mandates the release of the Deposits to ICANN and/or Registry; and 9.2 Evidence satisfactory to Escrow Agent that ICANN or Registry (whichever gave the notice under Section 9.1) has previously notified the other party in writing; and 9.3 Written instructions from ICANN or a replacement escrow agent (see Section 9.1.3) that the Deposits be released and delivered to whichever of them provided such written instructions; and 9.4 A written undertaking by the party(ies) receiving the Deposits (ICANN or a replacement escrow agent) that the Deposits will be used only as permitted under the terms of the Sponsored TLD Registry Agreement and undertakings made in writing to registrants at registration including with respect to the collection and use of personal information about the registrant for marketing purposes. Upon release of any Deposits to ICANN, Registry or a replacement escrow agent, Escrow Agent shall at the same time deliver to Registry a photostatic copy of the notice it received from Registry and/or ICANN under Sections 9.1.1 to 9.1.8, as applicable. 10. Release of Deposit to Registry . Escrow Agent shall deliver all Deposits to Registry upon termination of this Agreement in accordance with Sections 14.1 and 14.2.1 of this Agreement. 11. Procedure After Release. 11.1 Right to Use Deposits. Upon release of any Deposits to Registry pursuant to Section 9, Registry (or its assignee in accordance with the TLD Sponsorship Agreement), and subject to Section 9.4 above, shall immediately have the right to exercise or have exercised all rights in the Deposits necessary to provide registry services. Upon release of any Deposits to ICANN pursuant to Section 9, ICANN (or its assignee in accordance with the Sponsored TLD Registry Agreement) shall immediately have the right, subject to Section 9.4 above, to exercise or have exercised all rights in the Deposits pursuant to the Sponsored TLD Registry Agreement, including as necessary to provide registry services. 11.2 Objection Notices. Upon release of any Deposits to ICANN pursuant to Section 9, Registry shall have thirty calendar days to - 20 - notify Escrow Agent and ICANN in writing (the "Objection Notice") of its objection to the release of the Deposits to ICANN and request that the issue of entitlement to the Deposits be resolved pursuant to the dispute resolution procedures in the Sponsored TLD Registry Agreement. Registry and ICANN agree to resolve any disputes they may have as between or among themselves under this Agreement according to Section 17.2. The parties agree that (i) Registry shall have no rights (other than pursuant to this Section 11.2) to object to any release of the Deposits, and (ii) the delivery of an Objection Notice and the commencement of Dispute Resolution Procedures shall not delay release of any Deposits to ICANN pursuant to Section 9. 11.3 Dispute-Resolution Procedures. Registry and ICANN each agrees that it may not challenge, in proceedings for the resolution of disputes between or among those parties under this Agreement, the resolution of any issues, claims, or defenses that were decided, or which it had a reasonable opportunity and motive to raise, in proceedings to which it was a party under the Sponsored TLD Registry Agreement. 11.4 Withdrawal of Objection Notice. A party providing an Objection Notice may, at any time, notify the other parties that it wishes to withdraw its Objection Notice. Upon receipt of notice of such withdrawal, Escrow Agent shall promptly deliver to Registry and/or ICANN any Deposits that have not previously been delivered. 11.5 Dispute Resolution Decisions. 11.5.1 If the release of Deposits under Section 9 is determined in dispute-resolution procedures to have been proper, Escrow Agent shall promptly deliver, in accordance with the instructions specified in Section 9.3, any Deposits that have not previously been delivered. 11.5.2 If the release of Deposits under Section 9 is determined in dispute-resolution procedures to have been improper, the party(ies) receiving the Deposits shall promptly return or destroy, at Registry 's discretion, the Deposits received under Section 9. - 21 - 12. Indemnity. Registry and ICANN shall, jointly and severally, indemnify and hold harmless Escrow Agent and each of its directors, officers, agents, employees, members, and stockholders ("Escrow Agent Indemnitees") absolutely and forever, from and against any and all claims, actions, damages, suits, liabilities, obligations, costs, fees, charges, and any other expenses whatsoever, including reasonable attorneys' fees and costs, that may be asserted by a third party against any Escrow Agent Indemnitees in connection with this Agreement or the performance of Escrow Agent or any Escrow Agent Indemnitees hereunder (with the exception of any claims based on the misrepresentation, negligence, or misconduct of Escrow Agent, its directors, officers, agents, employees, contractors, members, and stockholders). Escrow Agent shall likewise indemnify and hold harmless Registry 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, contractors, members, and stockholders. 13. Interpleader. 13.1 Escrow Agent may submit any dispute under this Agreement to any court of competent jurisdiction in an interpleader or similar action. Any and all costs incurred by Escrow Agent in connection therewith, including reasonable attorneys' fees and costs, shall be borne equally by each of Registry and ICANN that are parties to such interpleader or similar action. 13.2 Escrow Agent shall perform any acts ordered by any court of competent jurisdiction, without any liability or obligation to any party hereunder by reason of such act. 14. Term and Termination. 14.1 Term. The initial term of this Agreement shall be [insert period of at least one year], commencing on the Beginning Date (the "Initial Term"). This Agreement shall be automatically renewed for an additional term of one year ("Additional Term") at the end of the Initial Term and each Additional Term hereunder unless, on or before - 24 - Registry Agreement. Escrow Agent may not assign or transfer this Agreement without the prior written consent of Registry and ICANN. 17.8 Entire Agreement. This Agreement, including all exhibits referenced herein, supersedes all prior discussions, understandings, and agreements between Escrow Agent and the other parties with respect to the data escrow services. Registry and ICANN acknowledge and agree that, as between themselves, the .cat Sponsored TLD Registry Agreement (including all its appendices) is intended to co-exist with this Agreement; this Agreement is supplementary to the .cat Sponsored TLD Registry Agreement; and the .cat Sponsored TLD Registry Agreement shall control in the event of any conflict between this Agreement and the .cat Sponsored TLD Registry Agreement. 17.9 Counterparts. This Agreement may be executed in counterparts, each of which when so executed shall be deemed to be an original and all of which when taken together shall constitute one and the same Agreement. 17.10 Governing Law. This Agreement shall be construed and enforced in accordance with the laws of the State of California, without regard to its conflicts-of-laws principles. The parties consent and agree that jurisdiction and venue for any legal proceedings relating to this Agreement shall lie with the state and federal courts of Los Angeles County in the State of California. 17.11 Notices. All notices, requests, demands or other communications required or permitted to be given or made under this Agreement shall be in writing and shall be delivered by hand, by commercial overnight delivery service which provides for evidence of receipt, by certified mail, return receipt requested, postage prepaid, by facsimile, or by e-mail (e-mail to be followed promptly at receiver's request by a copy delivered by one of the other means of delivery) to the corresponding addresses listed on the signature page of this Agreement. If delivered personally, by commercial overnight delivery service, by facsimile, or by e-mail, the date on which the notice, request, instruction, or document is delivered shall be the date on which delivery is deemed to be made, and if delivered by mail, the date on which such notice, request, instruction, or document is received shall be the date on which delivery is deemed to be made. - 25 - Any party may change its address for the purpose of this Agreement by notice in writing to the other parties as provided herein. 17.12 Survival. The obligation of confidentiality in Section 7, Sections 9, 10, 11, 12, 13, and this Section 17.12 shall survive any termination of this Agreement. 17.13 No Waiver. No failure on the part of any party hereto to exercise, and no delay in exercising any right, power, or single or partial exercise of any right, power, or remedy by any party will preclude any other or further exercise of that or any other right, power, or remedy. No express waiver or assent by any party to any breach of or default in any term or condition of this Agreement shall constitute a waiver of or an assent to any succeeding breach of or default in the same or any other term or condition. - 26 - Appendix 3 Zone File Access Agreement 1. Parties The User named in this Agreement hereby contracts with Fundació puntCAT("Registry") for a non-exclusive, non-transferable, limited right to access an Internet host server or servers designated by Registry from time to time, and to transfer a copy of the described Data to the User's Internet host machine specified below, under the terms of this Agreement. Upon execution of this Agreement by Registry, Registry will return a copy of this Agreement to you for your records with your UserID and Password entered in the spaces set forth below. 2. User Information (a) User: _________________________________________ (b) Contact Person: _________________________________ (c) Street Address: _________________________________ (d) City, State or Province: ___________________________ (e) Country and Postal Code: _________________________ (f) Telephone Number: ______________________________ including area/country code) (g) Fax Number: __________________________________ (including area/country code) (h) E-Mail Address: _______________________________ (i) Specific Internet host machine that will be used to access Registry's server to transfer copies of the Data: Name: ________________________________________ IP Address: ____________________________________ (j) Purpose(s) for which the Data will be used: During the term of this Agreement, you may use the data for any legal purpose not prohibited under Section 4 below. You may incorporate some or all of the Data in your own products or services, and distribute those - 29 - contain the same notice that appears on and in the Data obtained under this Agreement. 7. Method Of Access Registry reserves the right, with the approval of ICANN, to change the method of access to the Data at any time. You also agree that, in the event of significant degradation of system processing or other emergency, Registry may, in its sole discretion, temporarily suspend access under this Agreement in order to minimize threats to the operational stability and security of the Internet. 8. No Warranties The Data is being provided "as-is.” Registry disclaims all warranties with respect to the Data, either expressed or implied, including but not limited to the implied warranties of merchantability, fitness for a particular purpose, and non-infringement of third party rights. Some jurisdictions do not allow the exclusion of implied warranties or the exclusion or limitation of incidental or consequential damages, so the above limitations or exclusions may not apply to you. 9. Severability In the event of invalidity of any provision of this Agreement, the parties agree that such invalidity shall not affect the validity of the remaining provisions of this Agreement. 10. No Consequential Damages In no event shall Registry be liable to you for any consequential, special, incidental or indirect damages of any kind arising out of the use of the Data or the termination of this Agreement, even if Registry has been advised of the possibility of such damages. 11. Governing Law This Agreement shall be governed and construed in accordance with the laws of the Kingdom of Spain. You agree that any legal action or other legal proceeding relating to this Agreement or the enforcement of any provision of this Agreement shall be brought or otherwise commenced in the courts of Barcelona (Catalonia; Spain). You expressly and irrevocably agree and consent to the personal jurisdiction and venue of the Courts of First Instance of Barcelona for matters arising in connection with this Agreement - 30 - or your obtaining, use, or distribution of the Data. The United Nations Convention on Contracts for the International Sale of Goods is specifically disclaimed. 12. Termination You may terminate this Agreement at any time by erasing the Data you obtained under this Agreement from your Internet host machine together with all copies of the Data and providing written notice of your termination to Registry at [address of Registry]. Registry has the right to terminate this Agreement immediately if you fail to comply with any term or condition of this Agreement. You agree upon receiving notice of such termination of this Agreement by Registry or expiration of this Agreement to erase the Data you obtained under this Agreement together with all copies of the Data. 13. Definition "Data" means all data contained in a DNS zone file for the .cat Sponsored TLD as provided to TLD nameservers on the Internet. 14. Entire Agreement This is the entire agreement between you and Registry concerning access and use of the Data, and it supersedes any prior agreements or understandings, whether written or oral, relating to access and use of the Data. Fundació puntCAT By: (sign) Name: (print) Title: Date: User: By: (sign) Name: (print) Title: Date: ASSIGNED USERID AND PASSWORD (To be assigned by Registry upon execution of this Agreement): USERID: PASSWORD: - 31 - - 34 - 20 net-renews-6-yr " " 21 net-renews-7-yr " " 22 net-renews-8-yr " " 23 net-renews-9-yr " " 24 net-renews-10- yr " " 25 transfer- gaining- successful transfers initiated by this registrar that were ack'd by the other registrar – either by command or automatically 26 transfer- gaining-nacked transfers initiated by this registrar that were n'acked by the other registrar 27 transfer-losing- successful transfers initiated by another registrar that this registrar ack'd – either by command or automatically 28 transfer-losing- nacked transfers initiated by another registrar that this registrar n'acked 29 transfer- disputed-won number of transfer disputes in which this registrar prevailed 30 transfer- disputed-lost number of transfer disputes this registrar lost 31 transfer- disputed- nodecision number of transfer disputes involving this registrar with a split or no decision 32 deleted- domains-grace domains deleted within the add grace period 33 deleted- domains- nograce domains deleted outside the add grace period 34 restored- domains domain names restored from redemption period 35 restored- total number of restored names for which the - 35 - noreport registrar failed to submit a restore report - 36 - Appendix 5 Whois Specifications Public Whois Specification Public Whois for the .cat Sponsored TLD will be provided according to the specification described in Part VI of Appendix S. Whois Provider Data Specification Registry shall ensure the provision of bulk access to up-to-date data concerning domain name and nameserver registrations maintained on behalf of Registry in connection with the .cat sTLD on a daily schedule, only for purposes of providing free public query-based access to up-to-date data concerning domain name and nameserver registrations in multiple TLDs, to a party designated from time to time in writing by ICANN (the "Designated Recipient"). Any agreement between ICANN and a Designated Recipient for the license of such data (a "Whois License Agreement") will provide Registry with the right to enforce the Designated Recipient's obligations under this Appendix and the Whois License Agreement directly against the Designated Recipient, whether through being made a party to or third-party beneficiary of such agreement or through such other means as may be appropriate. In addition, any Whois License Agreement will include the following provisions governing the use of such data by the Designated Recipient: 1. The Designated Recipient shall only use the data provided by the Registry for the purpose of providing free public query-based Whois access as described in Section 3.1(c)(v) of the .cat Sponsored TLD Registry Agreement. The Designated Recipient may not use such data for any other purpose. 2. The Designated Recipient shall use best efforts to implement any corrections to the data provided by the Registry as soon as practicable. 3. The Designated Recipient must take such technical and organizational security measures as are, at a minimum, equivalent to - 39 - B. Content The XML format is designed to represent both complete and incremental registry data sets. • The escrow format describes domain, host, contact and registrar objects stored in the registry repository. • The full escrow describes a snapshot of the given date, while the incremental escrow represents a transaction log. In the full escrow, only the "domain", "host", "contact" and "registrar" elements appear, while in the incremental escrow, the other elements may also appear. • For the incremental escrow, three additional attributes are specified: the "actor" denotes the entity that caused the modification. This is either a registrar ID, the ID of a support staff member or the name of an internal process of the SRS that performed the modification automatically (like auto-renew). The "timestamp" documents the point in time when the modification has taken place. The "txn" is an identifier that further details the precise activity. • To allow a differentiation between the creation and updates of an object within an incremental escrow, the "domain", "host", "contact" and "registrar" elements contain an "action" attribute that provides this information. The following core data is reproduced in the escrow file: Domain the internal ID of the domain object the domain name, including the assigned language and the reserved IDN domain name variants. the internal ID of the sponsoring registrar the IDs of the registrant, administrative, technical and billing contact the status values the ENS authorization ID the EPP authentication information - 40 - the maintainer URL the creation, expiration, update and transfer dates Host the internal ID of the host object the domain name the assigned IP addresses the internal ID of the sponsoring registrar the status values the maintainer URL the creation, update and transfer dates Contact the ID of the contact object the name, organization, streets, city, state, postal code and country code the phone and fax numbers and the e-mail address. the EPP authentication information the maintainer URL the creation and update dates Registrar the internal ID of the registrar object the organization, streets, city, state, postal code, country code, phone and fax number, e-mail address, web server address the creation and update dates the IDs of the administrative, technical and billing contact C. Format - 41 - The document type declaration (DTD) for the XML formatted escrow files is the following: <?xml version="1.0" encoding="UTF-8"?> <!ELEMENT esrow-data (domain | del-domain | tr-domain | renew-domain | host | del-host | contact | del-contact | registrar | del-registrar)*> <!ATTLIST escrow-data tld NMTOKEN #REQUIRED date CDATA #REQUIRED type (full | incremental) #REQUIRED version CDATA #FIXED "1.0" > <!ELEMENT domain (idn-domainname)> <!ATTLIST domain dom-id NMTOKEN #REQUIRED registrar-id NMTOKEN #REQUIRED registrant-id NMTOKEN #REQUIRED admin-id NMTOKEN #REQUIRED tech-id NMTOKEN #REQUIRED billing-id NMTOKEN #REQUIRED nameserver-ids NMTOKENS #IMPLIED status NMTOKENS #REQUIRED ens-auth-id NMTOKEN #IMPLIED authinfo CDATA #IMPLIED maintainer-url CDATA #IMPLIED period CDATA #IMPLIED cre-date CDATA #REQUIRED exp-date CDATA #REQUIRED upd-date CDATA #REQUIRED xfer-date CDATA #IMPLIED action (create | update) #IMPLIED actor NMTOKEN #IMPLIED timestamp CDATA #IMPLIED txn CDATA #IMPLIED > <!ELEMENT del-domain EMPTY> <!ATTLIST del-domain dom-id NMTOKEN #REQUIRED actor NMTOKEN #REQUIRED - 44 - actor NMTOKEN #REQUIRED timestamp CDATA #REQUIRED txn CDATA #REQUIRED > <!ELEMENT domainname (#PCDATA)> <!ELEMENT idn-domainname (basename, variant*)> <!ATTLIST idn-domainname lang NMTOKEN #IMPLIED > <!ELEMENT basename (#PCDATA)> <!ELEMENT variant (#PCDATA)> <!ELEMENT ip (#PCDATA)> <!ELEMENT addr (name, org, street, street?, street?, city, state, post-code, country-code)> <!ELEMENT name (#PCDATA)> <!ELEMENT org (#PCDATA)> <!ELEMENT street (#PCDATA)> <!ELEMENT city (#PCDATA)> <!ELEMENT state (#PCDATA)> <!ELEMENT post-code (#PCDATA)> <!ELEMENT country-code (#PCDATA)> <!ELEMENT phone (#PCDATA)> <!ATTLIST phone ext CDATA #IMPLIED > <!ELEMENT fax (#PCDATA)> <!ATTLIST fax ext CDATA #IMPLIED > <!ELEMENT e-mail (#PCDATA)> <!ELEMENT url (#PCDATA)> Whois Data Specification – ICANN Registry shall ensure the provision of bulk access by ICANN to up-to date data concerning domain name and nameserver registrations maintained by Registry (or on Registry’s behalf) in connection with the .cat Sponsored TLD on a daily schedule, only for purposes of verifying and ensuring the operational stability of Registry Services, the DNS, and the Internet. - 45 - The procedures for providing access, and the specification of the content and format of this data, will be as stated below, until changed according to this .cat Sponsored TLD Registry Agreement. This Appendix is subject to change by agreement of Registry and ICANN during the design process as well as during the IETF standards process. In addition, Registry shall implement changes to this Appendix specified by ICANN to conform to the IETF provreg working group's protocol specification no later than 135 days after the IETF specification is adopted as a Proposed Standard [RFC 2026, section 4.1.1]. Accordingly, the following represents the target architecture and initial functionality. A. Procedures for Providing Access Registry shall ensure the preparation of a full data set for one day of each week (the day to be designated by ICANN). Full data sets shall be up-to date and coherent as of 1200 UTC on the day to which they relate. Until a different day is designated by ICANN, the full data sets will be prepared for Sundays. 1. Preparation of Files Containing Data Sets. Each full data set consists of an XML document meeting the content and format requirements of Parts B and C of this document. Once the XML document is generated, the following preparation steps will be performed: a. The XML document will be placed in a file named according to the following convention: "wfYYMMDD" where "YYMMDD" is replaced with the date (YY=last two digits of year; MM=number of month; DD=day; in all cases a single-digit number should be left-padded with a zero). b. The Registry, or its technical operator on its behalf, may optionally specify to split the document using the Unix SPLIT command (or equivalent) to produce files no less than 1GB each (except the final file). If files are split, an .MD5 file (produced with MD5SUM or equivalent) must be included with the resulting files to isolate errors. The Registry may optionally compress the document using the Unix GZIP command (or equivalent) to reduce the file size. - 46 - c. The file(s) will then be encrypted and signed using PGP, version 6.5.1 or above, with a key of DH/DSS type and 2048/1024-byte length. (Note that PGP compresses the escrow file in addition to encrypting it.) An ICANN public key will be used for the encryption and the Registry technical operator’s private key will be used for the signature. Public keys will be exchanged between the Registry, Registry’s technical operator and ICANN by e-mail, physical delivery of floppy diskettes or other agreed means. 2. Transmission of Full Data Sets. Once prepared, full data sets will be provided according to paragraph a below or, at Registry’s option, according to paragraph b below: a. Registry shall specify to make full data sets available for download by ICANN by Internet File Transfer Protocol (FTP) (FTP access will be password protected and limited to prespecified IP ranges). The data sets will be made available for download beginning no later than 2000 UTC on the day to which they relate and until the next full data set becomes available for download. b. Registry shall specify to write the full data set to DAT (DDS- 4) tape (or other media specified by ICANN) and ensure the tape is sent to ICANN by expedited delivery service (such as FedEx or DHL). The full data set will be scheduled for arrival at ICANN no later than the second calendar day following the day to which the data set relates. B. Content The full data sets will consist of the objects and contents described for full data sets in the Part VI of Appendix S (“Public Whois”). C. Format Full data sets will be XML version 1.0, UTF-8 encoded documents conforming to the schema/document type declaration set forth in Exhibit B of Appendix 1. - 49 - In addition, Registry shall reserve names of territories, distinct economies, and other geographic and geopolitical names as ICANN may direct from time to time. Such names shall be reserved from registration during any sunrise period, and shall be registered in ICANN's name prior to start-up and open registration in the TLD. Registry shall post and maintain an updated listing of all such names on its website, which list shall be subject to change at ICANN's direction. Upon determination by ICANN of appropriate standards and qualifications for registration following input from interested parties in the Internet community, such names may be approved for registration to the appropriate authoritative body. - 50 - Appendix 7 Functional and Performance Specifications Pursuant to the responsibility delegated to it in Appendix S, Registry will prescribe functional requirements for Registry Services provided for the .cat sTLD that shall ensure that at least the following minimum functional capabilities are provided. 1. Conventions The key words "MUST,” "MUST NOT,” "REQUIRED,” "SHALL", "SHALL NOT,” "SHOULD,” "SHOULD NOT,” "RECOMMENDED,” "MAY,” and "OPTIONAL" in this document are to be interpreted as described in IETF RFC 2119. 2. Nameserver Requirements The nameservers for the .cat Sponsored TLD MUST be operated in compliance with the following Requests for Comments (RFCs): 1034, 1035, 1101, 2181, and 2182. In clarification of the statement of host-name rules in these RFCs, all Registered Names SHALL comply with the following syntax in augmented Backus-Naur Form (BNF) as described in RFC 2234: dot = %x2E ; "." dash = %x2D ; "-" alpha = %x41-5A / %x61-7A ; A-Z / a-z digit = %x30-39 ; 0-9 ldh = alpha / digit / dash id-prefix = alpha / digit label = id-prefix [*61ldh id-prefix] sldn = label dot label; not to exceed 254 characters hostname = *(label dot) sldn; not to exceed 254 characters There MUST be nameservers for the .cat Sponsored TLD on at least five different network segments. So that the IANA has zone-file access, zone- file transfers MUST be enabled at all nameservers for transfers to at least 128.9.0.0/16 and 192.0.32.0/20. - 51 - 3. Registry System Requirements The registry system MUST enforce the name reservations and Charter requirements set forth in Appendix S. 4. Whois Service Requirements Whois service MUST meet at least the functional specifications set forth in Appendix 5. 5. Data Escrow Requirements Data escrow MUST meet at least the functional specifications set forth in Appendix 1. The Registry shall be capable of storing the data to be escrowed. 6. Reporting Requirements The Registry system MUST provide data sufficient to meet the reporting requirements set forth in Appendix 4. 7. Performance Specifications DNS Service Availability. Service availability as it applies to the DNS Service refers to the ability of the Nameservers, as a group, to resolve a DNS query from an Internet user. The committed Performance Specification is 99.999% measured in Monthly Timeframes. Performance Level. At any time at which it is available, each Nameserver (including a cluster of Nameservers addressed at a shared IP address) MUST be able to handle a load of queries for DNS data that is three times the measured daily peak (averaged over the Monthly Timeframe) of such requests on the most loaded Nameserver. Cross-Network Nameserver Performance Requirements. The committed Performance Specification for cross-network Nameserver performance is a measured Round-trip time of less than 300 ms and measured packet loss of fewer than 10%. Cross-network Nameserver performance measurements will be conducted by ICANN at times of it’s choosing, in the following manner: - 54 - Appendix S Part I .cat sTLD Charter Part II Delegated Authority Part III Description of .cat Sponsored TLD Community Part IV Start-Up Plan Part V Selection of Registrars Part VI Public Whois Part VII Additional Provisions Exhibit A Community-Assigned Names - 55 - Appendix S – Part I .CAT Charter I The .cat TLD will be established to serve the needs of the Catalan Linguistic and Cultural Community on the Internet (the “Community”) The Community consists of those who use the Catalan language for their online communications, and/or promote the different aspects of Catalan culture online, and/or want to specifically address their online communications to that Community. II The .cat TLD will be managed by Fundació puntCAT in accordance with (i) the provisions of this Charter (the “Charter”); (ii) the interests of the Community; (iii) Consensus Policies and Temporary Specifications or Policies (as defined in Section 3.1 (a) of the Agreement), as they may be applicable to Sponsored TLDs, and (iv) the interests of the global Internet community, with special consideration for interoperability, technical stability, and security aspects. Fundació puntCAT shall be responsible for establishing registration requirements for second-level domains in the .cat TLD, consistent with this Charter. III For the purposes of this Charter, without being exhaustive, and as may be amended or clarified from time to time as contemplated by item IV, below, the Registry’s policies may permit registrations in .cat TLD to the following: • Universities, schools, research institutions and other academic entities that use Catalan in their academic activities or teach/promote aspects of Catalan culture • public or private entities whose aim is promoting the Catalan culture • writers, translators, correctors and journalists publishing (or contributing to) works in Catalan • publishing companies that publish works in the Catalan language or - 56 - relating to the Catalan culture • media using the Catalan language for their communications • individuals, groups, businesses, organizations, entities or initiatives, however constituted, carrying online communications in Catalan • individuals, groups, businesses, organizations, entities or initiatives, however constituted, proving their belonging to the Community by way of sponsorship from other members of the Community in the form established in the Registration Policies • members of Fundació puntCAT IV The Registry may amend, clarify, extend or re-enumerate the industry sectors identified in clause III, above, provided that such changes are within the scope of the definition set out in clause I, above. The Registry will promptly inform ICANN of such changes. - 59 - 25. Other areas of responsibility as agreed to in writing by both ICANN and Registry 26. Any other policies or practices not inconsistent with the Agreement, ICANN Temporary Specifications and Policies, or Consensus Policy. - 60 - Appendix S – Part III Description of Sponsored TLD Community The .cat TLD is intended to serve the needs of the Catalan Linguistic and Cultural Community on the Internet (the “Community”). “Catalan Linguistic and Cultural Community” refers to those individuals, groups, businesses, organizations, entities or initiatives, however constituted, eligible to register in the .cat TLD according to this Agreement and the .cat Charter (Part I to this Appendix S). The Community includes those who (1) use the Catalan language for their online communications, (2) and/or promote the different aspects of Catalan culture online, (3) and/or want to specifically address their online communications to that Community. The Registry may extend or amend the description of the Community consistent with the terms of the Agreement and the .cat Charter. - 61 - APPENDIX S – PART IV Start-Up Plan Registry will implement the following Start-up Plan for the .cat Sponsored TLD: BACKGROUND The Start-up Plan provides for the orderly introduction of the .cat sTLD for the purpose of ensuring competition, fairness and reliability for ICANN- Accredited Registrars, registrants, and the .cat Community (as defined in Part III of this Appendix S). It is intended to create a stable and effective registration process for the benefit of the Internet community in general, and effected stakeholders in particular, while minimizing the number of conflicts within the Community or with third parties. TIMELINE Registry plans to introduce and begin to support products and services on the following approximate and estimated timeline. All referenced dates are based on the Effective Date of the Registry Agreement (ED). POLICY & STRUCTURE DATE EVENT 2003-In Process • Policy Development • Community Awareness ED + 30 • Publication of Draft Registration Agreement • Publication of Draft Dispute Resolution Mechanisms (15 days comment period) ED + 30 • Registry selects Dispute Resolution Provider for .cat specific DR policies ED + 30 • Registry signs contract with technical operator ED + 30 • Registrar Accreditation begins ED + 60 • Publication of Final version of - 64 - Phases for validations and domain name delegations. FULL OPERATIONS The goal of the full operations period is to provide continuous and stable registry operation to the Community. Registry may from time to time update registration operations and procedures and include new products and services consistent with the .cat Sponsored TLD Registry Agreement. MODIFICATION OF TIMELINE Registry will publish within 30 days of the Effective Date a new Timeline. - 65 - Appendix S – Part V Selection of Registrars Registry will select among ICANN-accredited registrars wishing to register domain names in .cat Sponsored TLD in a manner that promotes the foollowing characteristics: 1. Thorough and demonstrated understanding of the principles and intentions underlying .cat TLD policies and procedures; 2. Recognition of the specific nature of the .cat Sponsored TLD and demonstrated willingness to participate in providing registrar services to registrants in full support of the policy requirements established for Eligibility and Name Selection [ENS]; 3. Dedicated willingness and ability to propagate and enforce sTLD policies in an observant and diligent manner and in accordance with policies and procedures prescribed by Registry; 4. Demonstration that sufficient staff resources are available and that the Registrar has the technical ability to interface with automated and manual elements of the .cat TLD registry; 5. Demonstrated systems designed to avoid submission of unqualified or incomplete applications that will burden the ENS system or make it impossible for Registry to fulfill its commitments to ICANN; 6. Demonstrated systems designed to avoid any disputes regarding transfers among Registrars and acceptance of any .cat policies and procedures established in that regard; 7. Acceptance of Registry policies and designated procedures for grace periods for registrants; 8. Willingness and ability to post and refresh a minimum deposit against which fees will be drawn; 9. Demonstrated willingness and ability to publicize and market the .cat TLD, and to follow all .cat TLD marketing guidelines and to use its materials as appropriate; Registry has not established a minimum or maximum number of Registrars that will be selected for the .cat TLD. Registry will evaluate and, in its reasonable discretion, determine whether to qualify an applicant Registrar to serve as a Registrar for the TLD. - 66 - Registry will accept applications from any ICANN-accredited Registrar and will enter into agreements with Registrars only after a decision with respect to the selection of each applicant to serve as a Registrar based on all of the above criteria and will periodically review and, as appropriate, revise its selection of Registrars based on such criteria. - 69 - Either the “Domain Name”, “Domain Name ACE” or “Application ID” field is used. Only valid during the sunrise period. Registrar Search for registrar objects in the “Registrar ID” or “Registrar Organization” field In addition, the following search options are available: Keywords (case insensitive) Option Id Search is performed in the respective ID field Ace Search is performed in the respective ACE field In general, domain names in the input are considered as being Internationalized Domain Names (IDNs, as defined in section 2, “Terminology”, RFC 3490). By using the ace option, a given domain name is considered as being an ACE domain name. The use of the option does not have an influence on the response. The output can be controlled by the following keywords: Keywords (case insensitive) Option =, full Always return the complete data, even if multiple entries are found sum, summary Always return summarized data, even if only a single entry is found The last token in the input is taken as the search parameter. If the search parameter is “help” and no object type is given, no search is performed, but a short summary about the input format is returned. OUTPUT FORMAT SPECIFICATION - 70 - The results of the query are encoded using either the US-ASCII character set or, if a valid character set has been specified via the -C option, the selected character set. If the output contains characters for which no encoding does exist, it is handled in different ways depending on the location. For domain names, they are replaced with a question mark and a respective warning comment is added to the beginning of the output: [note: the following two warnings are provided as an example] % WARNING: THIS RESPONSE IS NOT AUTHENTIC % % The selected character encoding "XXX" is not able to % represent all characters in this output. Those % characters that could not be represented have been % replaced with "?". Please resubmit your query with a % suitable character encoding in order to receive an % authentic response. % Within contact fields, accented letters are replaced by their non-accented equivalent letters (which are part of the ASCII character set) and a respective warning comment is added to the beginning of the output: % WARNING: THIS RESPONSE IS NOT AUTHENTIC % % The selected character encoding "XXX" is not able to % represent all characters in this output. Those % characters that could not be represented have been % replaced with the unaccented ASCII equivalent. Please % resubmit your query with a suitable character encoding % in order to receive an authentic response. % If both cases appear, a suitable combined warning is generated. The different handling of characters that cannot be represented lies in the different importance of the correct spelling. While it is a common practice to remove accents from names and addresses in order to further process them in ASCII-only contexts, such a methodology is considered harmful regarding domain names. In this case it is better to produce an invalid - 71 - domain name with question marks in it instead of a name that might be considered as the actual spelling. All lines are terminated by CR/LF pairs. Lines that contain comments, legal notes or similar, start with a percent sign (‘%’). If the output consists of multiple objects, they are separated by at least one empty line. The objects themselves (including the related subobjects, like referenced contacts of a domain) do not contain empty lines. If no objects match the search query, “NOT FOUND” is returned. The object data is composed of multiple key- value lines. Key and value of a key-value pair are separated by a colon (‘:’). The key may contain space characters. For domain names that appear in the output, both the IDN version and the ACE version are supplied, even if the IDN consists of LDH characters only and is identical to the ACE representation. This applies to names of domains and hosts as well as name server references in domains. It does not apply to e-mail addresses (which contain domain names as part of the address) in the contact data. Example: ... Domain Name: fundació.cat Domain Name ACE: xn—fundaci-r0a.cat ... Name Server: blau.exemple.cat 192.0.2.1 Name Server: marró.exemple.cat 192.0.2.2 Name Server ACE: blau.exemple.cat 192.0.2.1 Name Server ACE: xn—marr-tqa.exemple.cat 192.0.2.2 ... Domain Data Format Depending on the query and options, either a short or a long format is produced. Short format: Domain ID: D38482 Domain Name: exemple.cat Domain Name ACE: exemple.cat Full Format: - 74 - Full format: Host ID: H38473 Host Name: ns3.exemple.cat Host Name ACE: ns3.exemple.cat Registrar ID: IANA-15 Created On: 2001-07-23 17:53:02 GMT Last Updated On: 2002-11-01 09:21:47 GMT Status: ok IP Address: 192.0.2.3 IP Address: 3FFE:3273:1002::FE99:3BC7 Contact Data Format Short format: Contact ID: C394583 Name: Núria Ferrer i Puig Full format: Contact ID: C394583 Status: ok Name: Núria Ferrer i Puig Organization: Street: Plaça de l'Església, 1 City: Castelló d’Empúries State/Province: Catalunya Postal Code: 17486 Country: ES Phone: +34.123456789 Phone Ext: Fax: +34.987654321 Fax Ext: Email: nuria.ferrer@exemple.cat The actual published data depends on the registry policy and the contact's disclosure settings (see RFC 3733). If data is not disclosed, the respective key-value pair is omitted. In contrast, empty fields (like the organization in the given example), are included. This allows the client to differentiate between the two cases. - 75 - Application Format During the Sunrise period, the Whois is enabled to return information about pending applications. Since multiple applications may be possible for a single domain name, a query using a domain name may return more than one record. Similar to the wild card search, the short report format is used by default if more than one record is found. Short Format: Application ID: A38482 Domain Name: exemple.cat Domain Name ACE: exemple.cat Name: Núria Ferrer i Puig Organization: Full format: Application ID: A38482 Domain Name: exemple.cat Variant Name: éxemple.cat Variant Name: exemplè.cat Domain Name ACE: exemple.cat Variant Name ACE: xn--xemple-9ua.cat Variant Name ACE: xn--exampl-8ua.cat Domain Language: ca Registrar ID: IANA-15 Created On: 2001-07-23 17:53:02 GMT Last Updated On: 2002-11-01 09:21:47 GMT Expiration Date: 2005-07-23 17:53:02 GMT Status: pending Registrant ID: C343238 Registrant Name: CORE Internet Council Of Registrars Registrant Organization: CORE Internet Council Of Registrars Registrant Street: WTC II, 29 route de Pre-Bois Registrant City: Geneva Registrant State/Province: Geneva Registrant Postal Code: 1215 Registrant Country: CH Registrant Phone: +41.229295744 - 76 - Registrant Phone Ext: Registrant Fax: +41.229295745 Registrant Fax Ext: Registrant Email: secretariat@corenic.org Admin ID: C343238 Admin Name: CORE Internet Council Of Registrars Admin Organization: CORE Internet Council Of Registrars Admin Street: WTC II, 29 route de Pre-Bois Admin City: Geneva Admin State/Province: Geneva Admin Postal Code: 1215 Admin Country: CH Admin Phone: +41.229295744 Admin Phone Ext: Admin Fax: +41.229295745 Admin Fax Ext: Admin Email: secretariat@corenic.org Tech ID: C343238 Tech Name: CORE Internet Council Of Registrars Tech Organization: CORE Internet Council Of Registrars Tech Street: WTC II, 29 route de Pre-Bois Tech City: Geneva Tech State/Province: Geneva Tech Postal Code: 1215 Tech Country: CH Tech Phone: +41.229295744 Tech Phone Ext: Tech Fax: +41.229295745 Tech Fax Ext: Tech Email: secretariat@corenic.org Billing ID: C343238 Billing Name: CORE Internet Council Of Registrars Billing Organization: CORE Internet Council Of Registrars Billing Street: WTC II, 29 route de Pre-Bois Billing City: Geneva Billing State/Province: Geneva Billing Postal Code: 1215 Billing Country: CH Billing Phone: +41.229295744 Billing Phone Ext: