Results 1 to 5 of 5

Thread: .mobi TLD Sponsorship Agreement with ICANN

  1. #1
    Administrator Andres Kello's Avatar
    Join Date
    Jun 2007
    Location
    Barcelona
    Posts
    3,548

    Default .mobi TLD Sponsorship Agreement with ICANN

    This is the entire agreement between mTLD and ICANN with all applicable amendments and appendices as of September 20, 2010 all on one page :


    .mobi TLD Sponsorship Agreement
    (Signed 10 July 2005)
    On 10 July 2005, ICANN and mTLD Top Level Domain, Ltd. entered into a TLD Sponsorship Agreement under which mTLD Top Level Domain, Ltd. sponsors the .mobi top-level domain. Generally speaking, a "sponsored" TLD is a specialized TLD that has a sponsor representing the particular community that is most affected by the TLD. The sponsor carries out delegated policy-formulation responsibilities over many matters concerning the TLD. The .mobi TLD Sponsorship Agreement and its attachments may be viewed by following the links below:








    .MOBI Registry Agreement
    (10 July 2005, amended 27 March 2007)


    This SPONSORED TLD REGISTRY AGREEMENT (this "Agreement") is entered into as of July 10, 2005 by and between Internet Corporation for Assigned Names and Numbers, a California nonprofit public benefit corporation, and mTLD Top Level Domain, Ltd., an Irish Limited Liability Company.
    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 Operator. ICANN shall promptly notify Registry Operator in writing of such delegation.
    Section 1.2 Top-Level Domain. The Top-Level Domain to which this Agreement applies is .mobi ("TLD").
    Section 1.3 Designation as Registry Operator. Upon the Effective Date, until the Expiration Date as defined in Section 4.1 hereof, ICANN hereby designates mTLD Top Level Domain, Ltd. as the sponsoring organization, and sole registry operator for the sponsored TLD ("Registry Operator"). ICANN hereby delegates to Registry Operator 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 Operator's Representations and Warranties.
    • Organization; Due Authorization and Execution. Registry Operator is a Limited Liability Company, duly organized, validly existing and in good standing under the laws of Ireland, and Registry Operator has all requisite power and authority to enter into this Agreement. All corporate approvals and actions necessary for the entrance by Registry Operator into this Agreement have been obtained and this Agreement has been duly and validly executed and delivered by Registry Operator.
    • Statements made During Application Process. The factual statements contained in Registry Operator’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, except as set forth in Appendix S, Part 8 are true and correct in all material respects as of the date this Agreement is entered into set forth above.
    Section 2.2 ICANN's Representations and Warranties.

    • 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.
    • Best Efforts. As of the date of execution of this Agreement first set forth above, notwithstanding the fact that ICANN currently does not exercise exclusive authority over the constellation of DNS root-nameservers specified, from time to time, in the file <ftp://ftp.internic.net/domain/named.root>, as further described in ICP 3 (the “Authoritative Root-Server System”), ICANN agrees to work in good faith, using best efforts, to ensure that the TLD shall be delegated to Registry Operator, and that the Authoritative Root will point to the TLD zone servers designated by Registry Operator for the Registry TLD throughout the Term of this Agreement.
    ARTICLE III COVENANTS
    Section 3.1 Covenants of Registry Operator. Registry Operator covenants and agrees with ICANN as follows:

    • Preserve Security and Stability.
      • ICANN Temporary Specifications or Policies. Registry Operator shall comply with and implement all specifications or policies established by the ICANN Board of Directors on a temporary basis, if adopted by the ICANN Board of Directors by a vote of at least two-thirds of its members, so long as the ICANN Board of Directors reasonably determines that immediate temporary establishment of a specification or policy on the subject is necessary to maintain the Stability or Security (as defined in Section 3.1(d)(iv)(G)) of Registry Services or the DNS (“Temporary Specification or Policies”). Such proposed Temporary Specification or Policy shall be as narrowly tailored as feasible to achieve those objectives. In establishing any Temporary Specification or Policy under this provision, the ICANN Board of Directors shall state the period of time for which the Temporary Specification or Policy is temporarily adopted and shall immediately implement the 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 Temporary 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 Temporary Specification or 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 Specification or Policy does not become a Consensus Policy meeting the standard set forth in Section 3.1(b) below, Registry Operator shall no longer be required to comply with or implement such Temporary Specification or Policy.
    • Consensus Policies.
      • At all times during the term of this Agreement and subject to the terms hereof, Registry Operator will fully comply with and implement all Consensus Policies as the same may be applicable to sponsored TLDs, found at http://www.icann.org/general/consensus-policies.htm, as of the Effective Date and as may in the future be developed and adopted in accordance with ICANN’s Bylaws and as set forth below.
      • Consensus Policies" are those specifications or policies established (1) pursuant to the policy development procedure set forth in ICANN's Bylaws and due process, and (2) covering those topics listed in Section 3.1(b)(iv) below. The policy development process and procedure set forth in ICANN's Bylaws may be revised from time to time in accordance with ICANN’s Bylaws, and any Consensus Policy that is adopted through such a revised process and covering those topics listed in Section 3.1(b)(iv) below shall be considered a Consensus Policy for purposes of this Agreement.
      • For all purposes under this Agreement, the policies identified at http://www.icann.org/general/consensus-policies.htm as of the date hereof shall be treated in the same manner and have the same effect as "Consensus Policies."
      • Consensus Policies and the procedures by which they are developed shall be designed to produce, to the extent possible, a consensus of Internet stakeholders. Consensus Policies shall relate to one or more of the following: (1) issues for which uniform or coordinated resolution is reasonably necessary to facilitate interoperability, Security and/or Stability of the Internet or DNS; (2) functional and performance specifications for the provision of Registry Services (as defined in Section 3.1(d)(iii) below); (3) Security and Stability of the registry database for the TLD; (4) registry policies reasonably necessary to implement Consensus Policies relating to registry operations or registrars; or (5) resolution of disputes regarding the registration of domain names (as opposed to the use of such domain names). Such categories of issues referred to in the preceding sentence shall include, without limitation:
        • principles for allocation of registered names in the TLD (e.g., first-come, first-served, timely renewal, holding period after expiration);
        • prohibitions on warehousing of or speculation in domain names by registries or registrars;
        • reservation of registered names in the TLD that may not be registered initially or that may not be renewed due to reasons reasonably related to (a) avoidance of confusion among or misleading of users, (b) intellectual property, or (c) the technical management of the DNS or the Internet (e.g., establishment of reservations of names from registration);
        • maintenance of and access to accurate and up-to-date information concerning domain name registrations;
        • procedures to avoid disruptions of domain name registration due to suspension or termination of operations by a registry operator or a registrar, including procedures for allocation of responsibility for serving registered domain names in a TLD affected by such a suspension or termination; and
        • resolution of disputes regarding whether particular parties may register or maintain registration of particular domain names.
      • Registry Operator shall be afforded a reasonable period of time following notice of the establishment of a Consensus Policy or Temporary Specifications or Policies in which to comply with such policy or specification, taking into account any urgency associated with the Security or Stability of the Internet or DNS. In the event of a direct conflict between Registry Services (as defined in Section 3.1(d)(iii) below), on the one hand, and Consensus Policies developed in accordance with this Section 3.1(b) or any Temporary Specifications or Policies established pursuant to Section 3.1(a)(i) above, on the other hand, the Consensus Polices or Temporary Specifications or Policies shall control as clarified in the adopting language thereof, notwithstanding any other provisions contained within this Agreement.
    • Handling of Registry Data.
      • Data Escrow. Registry Operator shall establish at its expense a data escrow or mirror site policy for the Registry Data compiled by Registry Operator. Registry Data, as used in this Agreement, shall mean the following: (1) data for domains sponsored by all registrars, consisting of domain name, server name for each nameserver, registrar id, updated date, creation date, expiration date, status information, and DNSSEC-related key material following such time as Registry Operator shall implement the relevant DNSSEC standards; (2) data for nameservers sponsored by all registrars consisting of server name, each IP address, registrar id, updated date, creation date, expiration date, and status information; (3) data for registrars sponsoring registered domains and nameservers, consisting of registrar id, registrar address, registrar telephone number, registrar e-mail address, whois server, referral URL, updated date and the name, telephone number, and e-mail address of all the registrar's administrative, billing, and technical contacts; (4) domain name registrant data collected by the Registry Operator from registrars as part of or following registration of a domain name; and (5) the DNSSEC-related material necessary to sign the TLD zone (e.g., public and private portions of TLD zone key-signing keys and zone-signing keys), following such time as Registry Operator shall implement the relevant DNSSEC standards. The escrow agent or mirror-site manager, and the obligations thereof, shall be mutually agreed upon by ICANN and Registry Operator on commercially reasonable standards that are technically and practically sufficient to allow a successor registry operator to assume management of the TLD. To this end, Registry Operator 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 Operator and ICANN, such approval not to be unreasonably withheld by either party. In addition, Registry Operator will deposit into escrow that data collected from registrars as part of offering Registry Services introduced after the Effective Date of this Agreement. 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 Operator (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 Operator, and the escrow agent.
      • Personal Data. Registry Operator shall notify registrars sponsoring registrations in the registry for the TLD of the purposes for which Personal Data (as defined below) submitted to Registry Operator by registrars, if any, is collected, the intended recipients (or categories of recipients) of such Personal Data, and the mechanism for access to and correction of such Personal Data. Registry Operator shall take reasonable steps to protect Personal Data from loss, misuse, unauthorized disclosure, alteration or destruction. Registry Operator shall not use or authorize the use of Personal Data in a way that is incompatible with the notice provided to registrars. "Personal Data" shall refer to all data about any identified or identifiable natural person.
      • Bulk Zone File Access. Registry Operator shall provide bulk access to the zone files for the registry for the TLD to ICANN on a commercially reasonable basis and in a commercially reasonable manner as specified by ICANN 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 Operator (which consent neither party shall unreasonably withhold).
      • Monthly Reporting. Within 20 days following the end of each calendar month, Registry Operator shall prepare and deliver to ICANN a report providing such data and in the format specified in Appendix 4. ICANN may audit Registry Operator's books and records for the preceding 12 months relating to data contained in monthly reports from time to time upon no less than 10 days advance written notice, provided that such audits shall not exceed one per quarter. Any such audit shall be at ICANN's cost, unless the results of such audit shall demonstrate a material discrepancy or discrepancies in the data provided by Registry Operator. In the latter event, Registry Operator 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 or the aggregate, result in an understatement in excess of 5% of the fees owed to ICANN by Registry Operator under Section 7.2.
      • Whois Service. Registry Operator shall provide such whois data as set forth in Appendix 5
    • Registry Operations.
      • Registration Restrictions.
        • Registry Operator shall establish policies, in conformity with the charter included in Appendix S hereto (the "Charter"), for the naming conventions within the sponsored TLD and for requirements of registration, consistent with Section 3.1(g).
        • Registry Operator shall establish procedures for the enforcement of applicable Charter restrictions on registration within the TLD as described in Appendix S, which Appendix shall also include the description of the sponsored community and the delegated authority with respect thereto.
        • Registry Operator 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.
      • 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 Operator shall keep technical and operational records sufficient to evidence compliance with such specifications for at least one year, which records ICANN may audit from time to time upon no less than 10 days advance written notice, provided that such audits shall not exceed one per quarter. Any such audit shall be at ICANN's cost.
      • Registry Services. Registry Services are, for purposes of this Agreement, defined as the following: (a) those services listed on the product list contained in the Start-Up Plan set forth in Appendix S Section Part 4 hereto as of the Effective Date; (b) 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; (c) other products or services that the Registry Operator is required to provide because of the establishment of a Consensus Policy (as defined in Section 3.1(b) above); (d) any other products or services that only a registry operator is capable of providing, by reason of its designation as the registry operator; and (e) material changes to any Registry Service within the scope of (a), (b) or (c) above.
      • Process for Consideration of Proposed Registry Services. Following written notification by Registry Operator to ICANN that Registry Operator may make a change in a Registry Service within the scope of the preceding paragraph:
        • 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, as such terms are defined below.
        • Registry Operator must provide sufficient information at the time of notification to ICANN that it may implement such a proposed Registry Service to enable ICANN to make an informed “preliminary determination.” Information provided by Registry Operator and marked “CONFIDENTIAL” shall be treated as confidential by ICANN. Registry Operator will not designate “CONFIDENTIAL” information necessary to describe the purpose of the proposed Registry Service and the effect on users of the DNS.
        • ICANN may seek expert advice during the preliminary determination period (from entities or persons subject to confidentiality agreements) on the competition, Security or Stability implications of the Registry Service in order to make its “preliminary determination.” To the extent ICANN determines to disclose confidential information to any such experts, it will provide notice to Registry Operator of the identity of the expert(s) and the information it intends to convey. ICANN shall respect Registry Operator's reasonable objection based on equitable or competitive grounds to the proposed disclosure to a particular expert.
        • If ICANN determines during the 15 calendar day “preliminary determination” period that the proposed Registry Service, does not raise significant Security or Stability (as defined below), or competition issues, Registry Operator shall be free to deploy it upon such a determination.
        • In the event ICANN reasonably determines during the 15 calendar day “preliminary determination” period that the Registry Service might raise significant competition issues, ICANN shall refer the issue to the appropriate governmental competition authority or authorities with jurisdiction over the matter within five business days of making its determination, or two business days following the expiration of such 15 day period, whichever is earlier, with notice to Registry Operator. Any such referral communication shall be posted on ICANN's website on the date of transmittal. Following such referral, ICANN shall have no further responsibility, and Registry Operator shall have no further obligation to ICANN, with respect to any competition issues relating to the Registry Service. If such a referral occurs, the Registry Operator will not deploy the Registry Service until 45 calendar days following the referral, unless earlier cleared by the referred governmental competition authority.
        • In the event that ICANN reasonably determines during the 15 calendar day “preliminary determination” period that the proposed Registry Service might raise significant Stability or Security issues (as defined below), ICANN will refer the proposal to a Standing Panel of experts (as defined below) within five business days of making its determination, or two business days following the expiration of such 15 day period, whichever is earlier, and simultaneously invite public comment on the proposal. The Standing Panel shall have 45 calendar days from the referral to prepare a written report regarding the proposed Registry Service’s effect on Security or Stability (as defined below), which report (along with a summary of any public comments) shall be forwarded to the ICANN Board. The report shall set forward the opinions of the Standing Panel, including, but not limited to, a detailed statement of the analysis, reasons, and information upon which the panel has relied in reaching their conclusions, along with the response to any specific questions that were included in the referral from ICANN staff. Upon ICANN’s referral to the Standing Panel, Registry Operator may submit additional information or analyses regarding the likely effect on Security or Stability of the Registry Service.
        • Upon its evaluation of the proposed Registry Service, the Standing Panel will report on the likelihood and materiality of the proposed Registry Service’s effects on Security or Stability, including whether the proposed Registry Service creates a reasonable risk of a meaningful adverse effect on Security or Stability as defined below: Security: For purposes of this Agreement, an effect on security by the proposed Registry Service shall mean (1) the unauthorized disclosure, alteration, insertion or destruction of Registry Data, or (2) the unauthorized access to or disclosure of information or resources on the Internet by systems operating in accordance with all applicable standards.
          Stability: For purposes of this Agreement, an effect on stability shall mean that the proposed Registry Service (1) is not compliant with applicable relevant standards that are authoritative and published by a well-established, recognized and authoritative standards body, such as relevant Standards-Track or Best Current Practice RFCs sponsored by the IETF or (2) creates a condition that adversely affects the throughput, response time, consistency or coherence of responses to Internet servers or end systems, operating in accordance with applicable relevant standards that are authoritative and published by a well-established, recognized and authoritative standards body, such as relevant Standards-Track or Best Current Practice RFCs and relying on Registry Operator's delegation information or provisioning services.
        • Following receipt of the Standing Panel’s report, which will be posted (with appropriate confidentiality redactions made after consultation with Registry Operator) and available for public comment, the ICANN Board will have 30 calendar days to reach a decision. In the event the ICANN Board reasonably determines that the proposed Registry Service creates a reasonable risk of a meaningful adverse effect on Stability or Security, Registry Operator will not offer the proposed Registry Service. An unredacted version of the Standing Panel’s report shall be provided to Registry Operator upon the posting of the report. The Registry Operator may respond to the report of the Standing Panel or otherwise submit to the ICANN Board additional information or analyses regarding the likely effect on Security or Stability of the Registry Service.
        • The Standing Panel shall consist of a total of 20 persons expert in the design, management and implementation of the complex systems and standards-protocols utilized in the Internet infrastructure and DNS (the “Standing Panel”). The members of the Standing Panel will be selected by its Chair. The Chair of the Standing Panel will be a person who is agreeable to both ICANN and the registry constituency of the supporting organization then responsible for generic top level domain registry policies. All members of the Standing Panel and the Chair shall execute an agreement requiring that they shall consider the issues before the panel neutrally and according to the definitions of Security and Stability. For each matter referred to the Standing Panel, the Chair shall select no more than five members from the Standing Panel to evaluate the referred matter, none of which shall have an existing competitive, financial, or legal conflict of interest, and with due regard to the particular technical issues raised by the referral.
    • Fees and Payments. Registry Operator shall pay the Registry-Level Fees to ICANN on a quarterly basis in accordance with Section 7.2 hereof.
    • Cooperation. Registry Operator shall cooperate with ICANN in efforts to promote and facilitate the Security and Stability of the Internet and the DNS. To this end, Registry Operator shall provide such data and assistance related to these issues to ICANN as it may reasonably request from time to time.
    • General Obligations of Registry Operator to Sponsored Community. During the Term of this Agreement, Registry Operator shall, in developing or enforcing standards, policies, procedures, or practices with respect to the TLD:
      • publish such standards, policies, procedures, and practices so they are available to members of the sponsored TLD community;
      • conduct its policy-development activities in a manner that reasonably provides opportunities for interested members of the sponsored TLD community to discuss and participate in the development of such standards, policies, procedures, or practices;
      • maintain the representativeness of its policy-development and implementation process by establishing procedures that provide an opportunity for participation by a broad cross-section of the sponsored TLD community; and
      • 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 Operator as follows:

    • Open and Transparent. Consistent with ICANN’s expressed mission and core values as set forth in its Bylaws, ICANN shall operate in an open and transparent manner.
    • Equitable Treatment. ICANN shall not apply standards, policies, procedures or practices arbitrarily, unjustifiably, or inequitably and shall not single out Registry Operator for disparate treatment unless justified by substantial and reasonable cause.
    • TLD Zone Servers. In the event and to the extent that ICANN is authorized to set policy with regard to the Authoritative Root-Server System, and in any case consistent with its obligations set forth in Section 2.2(b) above, it will ensure that (i) the authoritative root will point to the TLD zone servers designated by Registry Operator for the Registry TLD throughout the Term of this Agreement; and (ii) any changes to the TLD zone server designation submitted to ICANN by Registry Operator will be implemented by ICANN within seven days of submission.
    • Nameserver Changes. Registry Operator may request changes in the nameserver delegation for the Registry TLD. Any such request must be made in a format, and otherwise meet reasonable 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.
    • Root-zone Information Publication. ICANN's publication of root-zone contact information for the Registry TLD will include Registry Operator and its administrative and technical contacts. Any request to modify the contact information for the Registry Operator must be made in the format reasonably specified from time to time by ICANN.
    ARTICLE IV TERM OF AGREEMENT
    Section 4.1 Term. The initial term of this Agreement shall expire ten years from the Effective Date (the "Expiration Date"), as extended by any renewal terms. Registry Operator 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 Operator for the TLD, unless, with respect to termination under the foregoing clause (ii), Registry Operator 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 term set forth in Section 4.1 above and each renewal term, unless : (i) an arbitrator or court has determined that Registry Operator has been in fundamental and material breach of Registry Operator’s obligations set forth in Sections 3.1(a), (b), (d) or (e); Section 5.2 or Section 7.3 and (ii) following the final decision of such arbitrator or court, Registry Operator has failed to comply within ten days with the decision of the arbitrator or court, or within such other time period as may be prescribed by the arbitrator or court. Upon renewal, in the event that the terms of this Agreement are not similar to the terms generally in effect in the Registry Agreements of the five TLDs most reasonably comparable to .mobi (provided, however, that if less than five TLDs shall be reasonably comparable, then comparison shall be made with such lesser number), renewal shall be upon terms reasonably necessary to render the terms of this Agreement similar to such terms in the Registry Agreements for those other TLDs. Upon renewal, Registry Fees payable to ICANN may be reasonably modified so long as any increase in such fees shall not exceed the average of the percentage increase in Registry Fees for the five most reasonably comparable TLDs (or such lesser number as provided above), during the prior three-year period.
    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, without limitation, to Section 7.2 regarding fees and payments to ICANN.
    Section 4.4 Failure to Perform in Good Faith. In the event Registry Operator shall have been repeatedly and willfully in fundamental and material breach of Registry Operator’s obligations set forth in Sections 3.1(a), (b), (d) or (e); Section 5.2 or Section 7.3, and arbitrators in accordance with Section 5.1(b) of this Agreement repeatedly have found Registry Operator to have been in fundamental and material breach of this Agreement, including in at least three separate awards, then ICANN may

    • request the arbitrators award such punitive, exemplary or other damages as they may believe appropriate under the circumstances, which monetary damages shall not, however, commencing with the first full calendar year following the Effective Date exceed (A) US$2,000,000 during the first calendar year, (B) US$5,000,000 during the second through sixth calendar years, and (C) US$10,000,000 during the seventh through tenth calendar years, and any renewal terms of this Agreement; or
    • terminate this Agreement in writing effective fourteen (14) days from the date of such notice, subject to Registry Operator’s right under Section 5.1 (b) to seek a temporary stay or injunctive relief from the arbitration panel or a court.
    Notwithstanding the foregoing, ICANN is not precluded from seeking any other remedy available to it under this Agreement including seeking any available remedy from an arbitrator.
    ARTICLE V DISPUTE RESOLUTION
    Section 5.1 Resolution of Disputes.

    • Cooperative Engagement. In the event of a disagreement between Registry Operator and ICANN arising under or out of this Agreement, either party may by notice to the other invoke the dispute resolution provisions of this Article V. Provided, however, that before either party may initiate arbitration as provided in Section 5.1(b) below, ICANN and Registry Operator must attempt to resolve the dispute by cooperative engagement as set forth in this Section 5.1(a). If either party provides written notice to the other demanding cooperative engagement as set forth in this Section 5.1(a), then each party will, within seven calendar days after such written notice is deemed received in accordance with Section 8.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 within 7 calendar days of the initial telephone conference or meeting, at a location reasonably designated by ICANN, 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.
    • 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 ICC shall choose the third. The prevailing party in the arbitration shall have the right to recover its costs and reasonable attorneys' fees, which the arbitrators shall include in their awards. Any party that seeks to confirm or vacate an arbitration award issued under this Section 5.1(b) may do so only pursuant to the applicable arbitration statutes. In any litigation involving ICANN concerning this Agreement, jurisdiction and exclusive venue for such litigation shall be in a court located in Los Angeles County, California, USA; however, the parties shall also have the right to enforce a judgment of such a court in any court of competent jurisdiction. For the purpose of aiding the arbitration and/or preserving the rights of the parties during the pendency of an arbitration, the parties shall have the right to seek a temporary stay or injunctive relief from the arbitration panel or a court, which shall not be a waiver of this agreement to arbitrate.
    Section 5.2 Specific Performance. Registry Operator and ICANN agree that irreparable damage could occur if any of the provisions of this Agreement was not performed in accordance with its specific terms. Accordingly, the parties agree that they each shall be entitled to seek from the arbitrators specific performance of the terms of this Agreement (in addition to any other remedy to which each party is entitled).
    Section 5.3 Limitation of Liability. ICANN's aggregate monetary liability for violations of this Agreement shall not exceed the amount of Registry-Level Fees paid by Registry Operator to ICANN within the preceding twelve-month period pursuant to Section 7.2 of this Agreement. Registry Operator's aggregate monetary liability to ICANN for violations of this Agreement shall be limited to fees set forth in Section 7.2 below or, in the case of Section 4.4, the monetary sanctions due and owing to ICANN under this Agreement. In no event shall either party be liable for special, indirect, incidental, punitive, exemplary, or consequential damages arising out of or in connection with this Agreement or the performance or nonperformance of obligations undertaken in this Agreement, except as provided pursuant to Section 4.4 of this Agreement. EXCEPT AS OTHERWISE EXPRESSLY PROVIDED IN THIS AGREEMENT, REGISTRY OPERATOR DOES NOT MAKE ANY WARRANTY, EXPRESS OR IMPLIED, WITH RESPECT TO THE SERVICES RENDERED BY ITSELF, ITS SERVANTS, OR ITS AGENTS OR THE RESULTS OBTAINED FROM THEIR WORK, INCLUDING, WITHOUT LIMITATION, ANY IMPLIED WARRANTY OF MERCHANTABILITY, NON-INFRINGEMENT, OR FITNESS FOR A PARTICULAR PURPOSE.
    ARTICLE VI TERMINATION PROVISIONS
    Section 6.1 Termination.

    • Termination by ICANN. ICANN may terminate this Agreement if Registry Operator fails to cure any fundamental and material breach of Registry Operator’s obligations set forth in Sections 3.1(a), (b), (d) or (e); Section 5.2 or Section 7.3 despite notice and a reasonable opportunity to cure in accordance with Section 6.3.
    • Termination by Registry Operator. Registry Operator may terminate this Agreement and its designation as Registry Operator for the TLD pursuant to 120 days prior notice in writing to ICANN, and subject to compliance with Section 6.4 hereof.
    Section 6.2 Bankruptcy. This Agreement shall automatically terminate in the event Registry Operator shall voluntarily or involuntarily be subject to bankruptcy proceedings and such proceeding is not dismissed within sixty (60) days. For the avoidance of doubt, the termination provisions of this Section 6.2 shall not apply in the event of any reconstruction, reorganization (or similar business recombination) of Registry Operator not arising out of insolvency.
    Section 6.3 Notice; Opportunity to Cure. This Agreement may be terminated in the circumstances described in Section 6.1 above only following written notice to Registry Operator and Registry Operator's failure to cure within 30 days or such other reasonably prescribed time period following receipt of notice hereunder, with Registry Operator being given a reasonable opportunity during that time to initiate arbitration under Section 5.1(b) to determine the appropriateness of termination under this Agreement. In the event Registry Operator initiates arbitration concerning the appropriateness of termination by ICANN, Registry Operator may at the same time request that the arbitration panel stay the termination until the arbitration decision is rendered, and that request shall have the effect of staying the termination until the decision or until the arbitration panel has granted an ICANN request for lifting of the stay.
    Section 6.4 Transition of Registry upon Termination of Agreement. Upon any termination of this Agreement as provided in Sections 6.1 and 6.2, the parties agree to work cooperatively to facilitate and implement the transition of the registry for the TLD in accordance with this Section 6.4. Registry Operator shall agree to provide ICANN or any successor registry authority that may be designated for the TLD with any data regarding operations of the registry for the TLD necessary to maintain operations that may be reasonably requested in addition to that data escrowed in accordance with Section 3.1(c)(i) hereof.
    Section 6.5 Rights in Data. Registry Operator shall not be entitled to claim any intellectual property rights in Registry Data. In the event that Registry Data is released from escrow as set forth in Section 3.1(c)(i), rights, if any, held by Registry Operator in the data shall automatically be licensed on a non-exclusive, irrevocable, royalty-free, paid-up basis to ICANN or to a party designated in writing by ICANN, provided, however, that such release shall not effect a transfer of any intellectual property rights of Registry Operator other than the Registry Data itself.
    Section 6.6 No Reimbursement. Any and all expenditures, capital investments or other investments made by Registry Operator in connection with this Agreement shall be at Registry Operator’s own risk and ICANN shall have no obligation to reimburse Registry Operator for any such expense, capital expenditure or investment. Registry Operator shall not be required to make any payments to a successor registry operator by reason of registry fees paid to Registry Operator prior to the effective date of (i) any termination or expiration of this Agreement or (ii) transition of the registry, unless any delay in transition of the registry to a successor operator shall be due to the actions of Registry Operator.
    ARTICLE VII SPECIAL PROVISIONS
    Section 7.1 Registry-Registrar Agreement.

    • Access to Registry Services. Registry Operator 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 as set forth in Appendix S. Following execution of the Registry-Registrar Agreement between Registry Operator and the ICANN-accredited registrar, and subject to such registrar's compliance with the Registry-Registrar Agreement, Registry Operator shall provide operational access to Registry Services, including the shared registration system for the TLD. Such nondiscriminatory access to such registrars shall include without limitation the following:
      • All registrars (including any registrar affiliated with Registry Operator) 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;
      • Registry Operator has made the current version of the registrar toolkit software accessible to all registrars and has made any updates available to all registrars on the same schedule;
      • All registrars have the same level of access to customer support personnel via telephone, e-mail and Registry Operator's website;
      • 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;
      • All registrars have the same level of access to data generated by Registry Operator to reconcile their registration activities from Registry Operator's Web and ftp servers;
      • All registrars may perform basic automated registrar account management functions using the same registrar tool made available to all registrars by Registry Operator; and
      • The shared registration system does not include, for purposes of providing discriminatory access, any algorithms or protocols that differentiate among registrars with respect to functionality, including database access, system priorities and overall performance.
      Such Registry-Registrar Agreement may be revised by Registry Operator from time to time, provided however, that any such revisions must be approved in advance by ICANN.
    • Registry Operator Shall Not Act as Own Registrar. Registry Operator shall not act as a registrar with respect to a “domain name registration” as that term is defined in Section 7.2(b) below. This shall not preclude Registry Operator from registering names within the TLD to itself through a request made to an ICANN-accredited registrar.
    • Restrictions on Acquisition of Ownership or Controlling Interest in Registrar. Registry Operator shall not acquire, directly or indirectly, control of, or a greater than fifteen percent ownership interest in, any ICANN-accredited registrar, without ICANN's prior approval in writing, which approval shall not be unreasonably withheld.
    Section 7.2 Fees to be Paid to ICANN.

    • 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





    .MOBI Registry Agreement
    Amendment 1
    (27 March 2007)

    Amendment No. 1 to Registry Agreement
    Amendment No. 1 effective as of 1 January 2007 ("Amendment") to the Registry Agreement dated 10 July 2005 ("Agreement"), by and between the Internet Corporation for Assigned Names and Numbers, a not-for-profit California corporation ("ICANN"), and mTLD Top Level Domain, Ltd., an Irish Limited Liability Company ("Registry Operator"). Capitalized terms used but not defined herein shall have that meaning ascribed to them in the Agreement.
    Whereas, at the 13 March 2007 meeting of the ICANN Board of Directors, the Board of Directors approved certain revisions to the Agreement.
    Now, therefore, in consideration of the mutual agreements contained herein and intending to be legally bound hereby, the parties hereto amend the Agreement as follows:
    Article VII, Section 7.2(b) to the Agreement is hereby deleted in entirety and replaced with the attachment to this amendment.
    (b) Registry-Level Fee.

    1. For purposes of this Section 7.2(b), 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.tel) levels, about which Registry Operator or an affiliate thereof maintains Registry Operator Data on behalf of Registry Operator.
    2. Commencing as of 1 January 2007, Registry Operator shall pay ICANN a Registry-Level Fee each quarter in accordance with the payment schedule provided in Section 7.2(a) above equal to the greater of:
      1. US$12,500, or
      2. payment calculated under clause 1., 2., or 3. below, as applicable:
        1. for quarters during which the average price of registrations during the quarter is US$3.00 or less, the Registry-Level Fee shall be US$0.15 multiplied by the number of annual increments of an initial or renewal domain name registration during such quarter (including renewals associated with transfers from one ICANN-accredited registrar to another); or
        2. for quarters during which the average price of registrations during the quarter is more than US$3.00 and less than US$15.00, the Registry-Level fee shall be US$0.15 plus US$0.01 for each increase by US$0.20 in the average price of domain name registrations, multiplied by the number of annual increments of an initial or renewal domain name registration during such quarter (including renewals associated with transfers from one ICANN-accredited registrar to another); or
        3. for quarters during which the average price of registrations during the quarter is more than US$15.00, the Registry-Level Fee shall be US$0.75 for each annual increment of an initial or renewal domain name registration during the calendar quarter to (including renewals associated with transfers from one ICANN-accredited registrar to another).
    Except as expressly amended hereby, the Agreement and the Appendices thereto shall remain and continue in full force and effect. This Amendment may be executed in any number of counterparts, all of which together shall constitute one and the same instrument.
    The parties have duly executed this Amendment as of the date first written above.
    THE INTERNET CORPORATION mTLD Top Level Domain LLB
    FOR ASSIGNED NAMES AND NUMBERS
    By:_____________________________ By:_____________________________
    Name: John Jeffrey Name: Neil Edwards
    Title: General Counsel Title: CEO
    Comments concerning the layout, construction and functionality of this site
    should be sent to [email protected].

    Page Updated 3-April-2007
    (c) 2007 The Internet Corporation for Assigned Names and Numbers. All rights reserved.

    Amendment No. 2 to Registry Agreement (.mobi)
    (14 November 2008 )
    Amendment No. 2 to the .MOBI Sponsored TLD Agreement
    ICANN and mTLD Top Level Domain, Ltd. agree that the following modification is made to Appendix 6 of the 10 July 2005 .MOBI TLD Sponsorship Agreement:
    [old text]
    B. Additional Second-Level Reservations. In addition, the following names shall be reserved at the second level:

    • All single-character labels.
    [new text]
    B. Additional Second-Level Reservations. In addition, the following names shall be reserved at the second level:


    • All single-character labels – the Registry may also allocate single-character second-level labels (such as a.mobi, 4.mobi, etc.) through ICANN-accredited registrars, based upon its implementation of a process using evaluation criteria to meet the needs of the DotMobi sponsored community.
    The parties have duly executed this Amendment as of the date below.
    THE INTERNET CORPORATION FOR ASSIGNED NAMES AND NUMBERS

    By:_______________________________
    Name: Kurt Pritz
    Title: Senior Vice President, Services
    mTLD Top Level Domain, Ltd.

    By:_______________________________
    Name: Trey Harvin
    Title: Chief Executive Officer




    Comments concerning the layout, construction and functionality of this site
    should be sent to [email protected].

    Page Updated 09-Dec-2008
    © 2008 The Internet Corporation for Assigned Names and Numbers. All rights reserved.


    Appendix 1

    Data Escrow Specification
    This Appendix 1 to the Sponsored TLD Registry Agreement consists of four of the five exhibits to the Data Escrow Agreement that constitutes Appendix 2 to the Sponsored TLD Registry Agreement:
    Exhibit A-Schedule for Escrow Deposits
    Exhibit B-Escrow Deposit Format Specification
    Exhibit C-Escrow Transfer Process
    Exhibit D-Escrow Verification Procedures
    The fifth exhibit (Exhibit E), which sets forth Escrow Agent's fees, is subject to negotiation between Registry Operator and Escrow Agent.


    Exhibit A
    SCHEDULE FOR ESCROW DEPOSITS

    Full Deposit Schedule
    Full Deposits shall consist of data that reflects the state of the registry as of 0000 UTC on each Sunday. Pending transactions at that time (i.e. transactions that have not been committed to the Registry Database) shall not be reflected in the Full Deposit.
    Full Deposits shall be made, according to the transfer process described in Exhibit C below, within a four-hour window beginning at 0400 UTC on the same Sunday.
    Incremental Deposit Schedule
    Incremental Deposits shall reflect database transactions made since the most recent Full or Incremental Deposit. Incremental Deposits for Mondays shall include transactions completed through 0000 UTC on that day that had not been committed to the registry database at the time the last Full Deposit was taken. Incremental Deposits on Tuesday through Saturday shall include transactions completed through 0000 UTC on the day of the deposit that were not reflected in the immediately prior Incremental Deposit.
    Incremental Deposits shall be made, according to the transfer process described in Exhibit C below, within a four-hour window beginning at 0400 UTC on the day to which the Incremental Deposit relates.


    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:
    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 ("mobis"), 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="mobis" report="domain" date="26-Aug-2001 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. status: The domain status code.
    b. id: Unique identifier of the domain name
    c. owned-by: An identification of the sponsoring registrar of the domain. The sponsoring registrar is designated by a number uniquely assigned by the IANA.
    d. ens-authid: ENS authorization code.
    e. maintainer-url: URL of site of maintainer of domain name.
    f. created-code: A reference to the transaction that created the domain object.
    g. created-on: The date/time the domain object was originally created.
    h. 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.
    i. renewed-on: The date/time the domain was last renewed.
    j. expires-on: The date the registration expires.
    k. 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.
    l. updated-on: The date/time the domain object was last updated.
    m. 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.
    n. transferred-on: The date/time when the domain object was last transferred.
    o. transferred-code: A reference to the transaction that last transferred the domain object.
    p. host: Up to thirteen (13) host names that are nameservers for the domain to which the domain object relates.
    q. 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:
    <domain fqdn="example.xxx">
    <id>AAA-0001</id>
    <status>ACTIVE</status>
    <owned-by>REG-042</owned-by>
    <ens-authid>MOBIS-1221</ens-authid>
    <maintainer-url>http://example.xxx</maintainer-url>
    <created-code>12345678</created-code>
    <created-on>1-Jul-2001 12:34:56AM</created-on>
    <created-by>REG-042</created-by>
    <renewed-on></renewed-on>
    <expires-on>1-Jul-2003</expires-on>
    <updated-by>42</updated-by>
    <updated-on>1-Jul-2001 12:34:56AM</updated-on>
    <transferred-by></transferred-by>
    <transferred-on></transferred-on>
    <transferred-code></transferred-code>
    <host>dns1.example.xxx</host>
    <host>dns2.example.xxx</host>
    <contact-id type="Registrant">PER-0001</contact-id>
    <contact-id type="Administrative">PER-0002</contact-id>
    <contact-id type="Technical">PER-0003</contact-id>
    <contact-id type="Billing">PER-0004</contact-id>
    </domain>
    4. The Host Element. The host element has the property "fqdn" (the fully qualified name of the host) and is a container consisting of the following elements:
    a. id: Identifier of the host.
    b. owned-by: An identification of the sponsoring registrar of the host. The sponsoring registrar is designated by a number uniquely assigned by the IANA.
    c. created-code: A reference to the transaction that created the host object.
    d. created-on: The date/time the host object was originally created.
    e. updated-by: An identification of the registrar that last updated the host object. The sponsoring registrar is designated by a number uniquely assigned by the IANA.
    f. updated-on: The date/time the host object was last updated.
    g. transferred-by: An identification of the registrar that last transferred the host object. A number uniquely assigned by the IANA designates the sponsoring registrar.
    h. transferred-on: The date/time when the host object was last transferred.
    i. ip-address: Any number of IP addresses associated with this host.
    An example host container appears below:
    <host fqdn="dns1.example.xxx">
    <id>HST-0001</id>
    <owned-by>REG-042</owned-by>
    <created-code>12345679</created-code>
    <created-on>1-Jul-2001 12:40:32AM</created-on>
    <updated-by>42</updated-by>
    <updated-on>1-Jul-2001 12:40:32AM</updated-on>
    <transferred-by></transferred-by>
    <transferred-on></transferred-on>
    <ip-address>192.168.1.1</ip-address>
    <ip-address>192.168.122.1</ip-address>
    </host>
    5. The Contact Element. The contact element has the property "id" and is a container consisting of the following elements:
    a. name: The name of the contact.
    b. organization: The organization for the contact.
    c. street1: The first part of the street address of the contact.
    d. street2: The second part of the street address of the contact.
    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. owned-by: An identification of the sponsoring registrar of the contact. The sponsoring registrar is designated by a number uniquely assigned by the IANA.
    n. created-code: A reference to the transaction that created the contact object.
    o. 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.
    p. created-on: The date/time the contact object was originally created.
    q. 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.
    r. updated-on: The date/time the contact object was last updated.
    s. 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.
    t. transferred-on: The date/time when the contact object was last transferred.
    u. transferred-code: A reference to the transaction that last transferred the contact object.
    v. 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>[email protected]</email>
    <owned-by>42</owned-by>
    <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.
    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>


    Exhibit C
    ESCROW TRANSFER PROCESS

    Deposit Transfer Process. Registry Operator shall prepare and transfer the Deposit file by the following steps, in sequence:
    1. The Reports making up the Deposit will first be created according to the format specification. (See Exhibit B above, "Escrow Deposit Format Specification").
    2. The Reports making up the Deposit will be concatenated. The resulting file shall be named according to the following format: "mobisSEQN,” where "SEQN" is a four digit decimal number that is incremented as each report is prepared.
    3. Next, the Deposit file will be processed by a program (provided by ICANN) that will verify that it complies with the format specification and contains reports of the same date/time (for a Full Deposit), count the number of objects of the various types in the Deposit, and append to the file a report of the program's results.
    4. Registry Operator may optionally split the resulting file using the Unix SPLIT command (or equivalent) to produce files no less than 1 GB each (except the final file). If Deposit files are split, a .MDS file (produced with MDSSUM or equivalent) must be included with the split files to isolate errors in case of transfer fault.
    5. The Deposit file(s) will then be encrypted using Escrow Agent's public key for PGP and signed using Registry Operator's private key for PGP, both version 6.5.1 or above, with a key of DH/DSS type and 2048/1024-byte length. (Note that PGP compresses the Deposit file(s) in addition to encrypting it (them).)
    The formatted, encrypted and signed Deposit file(s) will be sent, by anonymous file transfer, to Escrow Agent's ftp server within the specified time window.


    Exhibit D
    ESCROW VERIFICATION PROCEDURES

    Verification Procedures. Escrow Agent will verify the format and completeness of each Deposit by the following steps:
    1. At the conclusion of the deposit window, all Deposit files will be moved to a not-publicly-accessible directory and the existence and size of each will be noted.
    2. Each Deposit file will be decrypted using Escrow Agent's private key for PGP and authenticated using Registry Operator's public key for PGP. (In this step, PGP will also automatically decompress the escrow file).
    3. If there are multiple files, they will be concatenated in sequence.
    4. Escrow Agent will run a program (to be supplied by ICANN) on the Deposit file (without report) that will split it in to its constituent reports (including the format report prepared by the Registry Operator and appended to the Deposit) check its format, count the number of objects of each type, and verify that the data set is internally consistent. This program will compare its results with the results of the Registry-generated format report, and will generate a Deposit format and completeness report. The program will encrypt the report using ICANN's public key for PGP and signed using Escrow Agent's private key for PGP, both versions 6.5.1 or above, with a key of DH/DSS type and 2048/1024-byte length. (Note that PGP compresses the Deposit file(s) in addition to encrypting it (them).)
    5. The decrypted Deposit file will be destroyed to reduce likelihood of data loss to intruders in case of partial security failure.
    Distribution Of Public Keys. Each of Registry Operator and Escrow Agent will distribute its public key to the other party (Registry Operator or Escrow Agent, as the case may be) via email to an email address to be specified. Each party will confirm receipt of the other party's public key with a reply email, and the distributing party will subsequently reconfirm the authenticity of the key transmitted. In this way, public key transmission is authenticated to a user able to send and receive mail via a mail server operated by the distributing party. Escrow Agent, Sponsor and ICANN shall exchange keys by the same procedure.


    Appendix 2

    Escrow Agreement
    This Registry Data Escrow Agreement ("Agreement") is made as of this [enter date] (the "Beginning Date"), by and between DotMobi ("Registry Operator"), [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 Operator and ICANN ("Sponsored TLD Registry Agreement").
    Recitals
    A. Registry Operator and ICANN have entered into the Sponsored TLD Registry Agreement, which requires Registry Operator, during the term of the 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 Sponsored TLD Registry Agreement, Registry Operator 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 Sponsored TLD Registry Agreement (each such delivery referred to as a "Deposit").
    C. Registry Operator 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 are not reflected in the last previous Full Deposit or Incremental Deposit, as the case may be.
    2. Schedule for Deposits. Registry Operator 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 Sponsored TLD Registry Agreement. Registry Operator 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 Operator 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 Operator (or Registry Operator’s agent at Registry Operator’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 Operator and ICANN of such nonconformity within forty-eight hours of discovery. Upon notification of such verification failure, Registry Operator shall 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 Operator 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 Operator 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 requirement pursuant to Sections 9.1.6, 11.2, and 13 of this Agreement), Escrow Agent shall notify Registry Operator and ICANN within seven days or as soon as practicable and reasonably cooperate with Registry Operator and/or ICANN in any contest of the disclosure. Should any contest prove unsuccessful, Escrow Agent shall not be held liable for any disclosure pursuant to such governmental, legislative, judicial, or arbitral order, statute, rule, regulation, or other requirement.
    8. Duplication. Escrow Agent may duplicate any Deposit by any commercially reasonable means in order to comply with the terms and provisions of this Agreement, provided that Registry Operator shall bear the expense of such duplication. Alternatively, Escrow Agent, by notice to Registry Operator, may reasonably require Registry Operator to promptly oversee the duplication of any Deposit.
    9. Release of Deposits. Within five business days after receipt of any required documents and/or notices specified in this Section 9, Escrow Agent shall deliver all Deposits in Escrow Agent's possession (i) to Registry Operator in the event of a release pursuant to any of Sections 9.1.2, or 9.1.5, 9.1.6, 9.1.7 and 9.1.8 or (ii) to ICANN in the event of a release pursuant to Sections 9.1.1, 9.1.4, 9.1.7, or 9.1.8, or (iii) the party designated in the event of a release pursuant to Section 9.1.3, in the event that the Escrow Agent receives all of the items required by Sections 9.1, 9.2, 9.3, and 9.4 below:
    9.1 One of the following notices:
    9.1.1 A written notice by ICANN that the Sponsored TLD Registry Agreement has: (i) expired without renewal, pursuant to Subsection 4.1 of the Sponsored TLD Registry Agreement, or (ii) been terminated in accordance with Article VI of the Sponsored TLD Registry Agreement; or
    9.1.2 A written notice by Registry Operator that the Registry Agreement has expired without renewal or been terminated; or
    9.1.3 A written notice by Registry Operator, Sponsor, and ICANN requesting Escrow Agent to effect such delivery to Sponsor, ICANN, or replacement escrow agent; or
    9.1.4 A written notice by ICANN that it has received no successful verification report from Escrow Agent relating to a Full Deposit reflecting the Registry Database as of any date within the past month; or
    9.1.5 A written notice by Registry Operator that all of the following have occurred:
    9.1.5.1 Registry Operator failed, with respect to (a) any Full Deposit or (b) five Incremental Deposits within any calendar month, to receive, within five calendar days after the Deposit's scheduled delivery date, notification of receipt from Escrow Agent; and
    9.1.5.2 Registry Operator gave notice to Escrow Agent of that failure; and
    9.1.5.3 Registry Operator has not, within seven calendar days after the notice under Section 9.1.5.2, received notice from Escrow Agent that the Deposit has or the Deposits have been received; or
    9.1.6 A written notice by Registry Operator that all of the following have occurred:
    9.1.6.1 Registry Operator has received notification from Escrow Agent of failed verification of a Full Deposit or of failed verification of five Incremental Deposits within any calendar month; and
    9.1.6.2 Registry Operator gave notice to Registry Operator’s agent of that receipt; and
    9.1.6.3 Registry Operator has not, within seven calendar days after the notice under Section 9.1.6.2, received notice from Escrow Agent of verification of a remediated version of the Deposit; or
    9.1.7 A written notice by ICANN that release of the Deposits is mandated by non-payment of any fees due to Escrow Agent, pursuant to Section 15 of this Agreement; or
    9.1.8 A written notice by ICANN or Registry Operator that a court, arbitral, legislative, or government agency of competent jurisdiction has issued an order, rule, statute, regulation, or other requirement that mandates the release of the Deposits to ICANN and/or Registry Operator; and
    9.2 Evidence satisfactory to Escrow Agent that ICANN or Registry Operator (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 in compliance with the laws of Ireland applicable to the use of personal data and any related 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 Operator or a replacement escrow agent, Escrow Agent shall at the same time deliver to Registry Operator a photostatic copy of the notice it received from Registry Operator and/orICANN under Sections 9.1.1 to 9.1.8, as applicable.
    10. Release of Deposit to Registry Operator. Escrow Agent shall deliver all Deposits to Registry Operator 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 Operator pursuant to Section 9, Registry Operator (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 Operator shall have thirty calendar days to 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 Operator 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 Operator 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 Operator 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 Operator 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 Operator's discretion, the Deposits received under Section 9.
    12. Indemnity. Registry Operator 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 Operator and ICANN, and each of their respective directors, officers, agents, employees, members, and stockholders ("Indemnitees") absolutely and forever, from and against any and all claims, actions, damages, suits, liabilities, obligations, costs, fees, charges, and any other expenses whatsoever, including reasonable attorneys' fees and costs, that may be asserted by a third party against any Indemnitee in connection with the misrepresentation, negligence, or misconduct of Escrow Agent, its directors, officers, agents, employees, 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 Operator 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 ninety days prior to the end of the Initial Term or an Additional Term, a party notifies the other parties that it wishes to terminate this Agreement at the end of such term. In the event a party gives the other parties such notice of termination, and Registry Operator and ICANN cannot agree to resolve, by the end of the then-current term, any disputes regarding the renewal of this Agreement or the establishment of a replacement escrow agent: (i) Registry Operator and ICANN shall resolve any such disputes through Subsection 5.1 of the Sponsored TLD Registry Agreement; (ii) this Agreement shall continue to remain in effect during the resolution of any such disputes; and (iii) Escrow Agent shall have the right to invoice either Registry Operator or ICANN for the data escrow services provided during this dispute resolution period at the rates listed in Exhibit E to this Appendix 1.
    14.2 Termination. This Agreement shall terminate upon the occurrence of any of the following:
    14.2.1 Termination of this Agreement by Registry Operator and ICANN, upon having delivered to Escrow Agent a written notice signed by ICANN stating their common intent to terminate this Agreement upon ninety days' notice;
    14.2.2 Termination of this Agreement by Escrow Agent pursuant to Section 15; or
    14.2.3 As provided in Section 14.1.
    15. Fees and Payments. Registry Operator shall pay to Escrow Agent the applicable fees and charges listed in Exhibit E as compensation for Escrow Agent's services under this Agreement. If Registry Operator fails to pay any fees or charges invoiced by Escrow Agent by the due date(s), Escrow Agent shall give written notice to Registry Operator of non-payment of any such past-due fees hereunder and, in that event, the Registry Operator shall have the right to pay the past-due fee(s) within ten business days after receipt of the notice from Escrow Agent. Upon payment of the past-due fee by Registry Operator, this Agreement shall continue in full force and effect. If Registry Operator fails to pay the past-due fee(s) within the applicable periods under this Section 15, Escrow Agent shall have the right to terminate this Agreement immediately by sending notice of termination to all other parties, and, upon termination, Escrow Agent shall deliver to ICANN all Deposits held by Escrow Agent.
    16. Ownership of Deposit Materials. Subject to the provisions of the Sponsored TLD Registry Agreement (including Subsection 6.5), the parties recognize and acknowledge that ownership of the Deposit materials during the effective term of this Agreement shall remain with the Registry Operator at all times.
    17. Miscellaneous.
    17.1 Remedies. For the purposes of fulfilling its obligations under this Agreement, Escrow Agent may act in good faith reliance on, and shall not be held liable for, any written notice, instruction, instrument, or other writing signed or presented by a person with apparent authority to act on behalf of Registry Operator or ICANN.
    17.2 Dispute Resolution. Registry Operator and ICANN agree to resolve any disputes they may have as between or among themselves under this Agreement, including any objections to release of the Deposits pursuant to Section 9.1, solely pursuant to the dispute-resolution procedures in the Sponsored TLD Registry Agreement.
    17.3 Limitation of Liability. The parties shall not be liable to each other for special, indirect, incidental, or consequential damages hereunder. As between Registry Operator and ICANN the liability limitations of the Sponsored TLD Registry Agreement also apply. Neither Registry Operator nor ICANN shall be liable to each under for monetary damages under this Agreement.
    17.4 Independent Contractor. Escrow Agent is an independent contractor and is not an employee or agent of Registry Operator or ICANN.
    17.5 No Third-Party Beneficiaries. This Agreement shall not be construed to create any obligation by Registry Operator, ICANN, or Escrow Agent to any non-party to this Agreement, including but not limited to any domain-name holder or registrar.
    17.6 Amendments. This Agreement shall not be modified or amended except in writing executed by each of the parties.
    17.7 Assignment. Neither Registry Operator nor ICANN may assign or transfer this Agreement (by merger, sale of assets, operation of law, or otherwise), except that the rights and obligations of Registry Operator or ICANN automatically shall be transferred to the assignee of one of those parties' rights and obligations under the Sponsored TLD Registry Agreement. Escrow Agent may not assign or transfer this Agreement without the prior written consent of Registry Operator 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 Operator and ICANN acknowledge and agree that, as between themselves, the Sponsored TLD Registry Agreement (including all its appendices) is intended to co-exist with this Agreement; this Agreement is supplementary to the Sponsored TLD Registry Agreement; and the Sponsored TLD Registry Agreement shall control in the event of any conflict between this Agreement and the 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. 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.

    Appendix 2

    Escrow Agreement
    This Registry Data Escrow Agreement ("Agreement") is made as of this [enter date] (the "Beginning Date"), by and between DotMobi ("Registry Operator"), [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 Operator and ICANN ("Sponsored TLD Registry Agreement").
    Recitals
    A. Registry Operator and ICANN have entered into the Sponsored TLD Registry Agreement, which requires Registry Operator, during the term of the 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 Sponsored TLD Registry Agreement, Registry Operator 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 Sponsored TLD Registry Agreement (each such delivery referred to as a "Deposit").
    C. Registry Operator 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 are not reflected in the last previous Full Deposit or Incremental Deposit, as the case may be.
    2. Schedule for Deposits. Registry Operator 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 Sponsored TLD Registry Agreement. Registry Operator 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 Operator 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 Operator (or Registry Operator’s agent at Registry Operator’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 Operator and ICANN of such nonconformity within forty-eight hours of discovery. Upon notification of such verification failure, Registry Operator shall 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 Operator 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 Operator 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 requirement pursuant to Sections 9.1.6, 11.2, and 13 of this Agreement), Escrow Agent shall notify Registry Operator and ICANN within seven days or as soon as practicable and reasonably cooperate with Registry Operator and/or ICANN in any contest of the disclosure. Should any contest prove unsuccessful, Escrow Agent shall not be held liable for any disclosure pursuant to such governmental, legislative, judicial, or arbitral order, statute, rule, regulation, or other requirement.
    8. Duplication. Escrow Agent may duplicate any Deposit by any commercially reasonable means in order to comply with the terms and provisions of this Agreement, provided that Registry Operator shall bear the expense of such duplication. Alternatively, Escrow Agent, by notice to Registry Operator, may reasonably require Registry Operator to promptly oversee the duplication of any Deposit.
    9. Release of Deposits. Within five business days after receipt of any required documents and/or notices specified in this Section 9, Escrow Agent shall deliver all Deposits in Escrow Agent's possession (i) to Registry Operator in the event of a release pursuant to any of Sections 9.1.2, or 9.1.5, 9.1.6, 9.1.7 and 9.1.8 or (ii) to ICANN in the event of a release pursuant to Sections 9.1.1, 9.1.4, 9.1.7, or 9.1.8, or (iii) the party designated in the event of a release pursuant to Section 9.1.3, in the event that the Escrow Agent receives all of the items required by Sections 9.1, 9.2, 9.3, and 9.4 below:
    9.1 One of the following notices:
    9.1.1 A written notice by ICANN that the Sponsored TLD Registry Agreement has: (i) expired without renewal, pursuant to Subsection 4.1 of the Sponsored TLD Registry Agreement, or (ii) been terminated in accordance with Article VI of the Sponsored TLD Registry Agreement; or
    9.1.2 A written notice by Registry Operator that the Registry Agreement has expired without renewal or been terminated; or
    9.1.3 A written notice by Registry Operator, Sponsor, and ICANN requesting Escrow Agent to effect such delivery to Sponsor, ICANN, or replacement escrow agent; or
    9.1.4 A written notice by ICANN that it has received no successful verification report from Escrow Agent relating to a Full Deposit reflecting the Registry Database as of any date within the past month; or
    9.1.5 A written notice by Registry Operator that all of the following have occurred:
    9.1.5.1 Registry Operator failed, with respect to (a) any Full Deposit or (b) five Incremental Deposits within any calendar month, to receive, within five calendar days after the Deposit's scheduled delivery date, notification of receipt from Escrow Agent; and
    9.1.5.2 Registry Operator gave notice to Escrow Agent of that failure; and
    9.1.5.3 Registry Operator has not, within seven calendar days after the notice under Section 9.1.5.2, received notice from Escrow Agent that the Deposit has or the Deposits have been received; or
    9.1.6 A written notice by Registry Operator that all of the following have occurred:
    9.1.6.1 Registry Operator has received notification from Escrow Agent of failed verification of a Full Deposit or of failed verification of five Incremental Deposits within any calendar month; and
    9.1.6.2 Registry Operator gave notice to Registry Operator’s agent of that receipt; and
    9.1.6.3 Registry Operator has not, within seven calendar days after the notice under Section 9.1.6.2, received notice from Escrow Agent of verification of a remediated version of the Deposit; or
    9.1.7 A written notice by ICANN that release of the Deposits is mandated by non-payment of any fees due to Escrow Agent, pursuant to Section 15 of this Agreement; or
    9.1.8 A written notice by ICANN or Registry Operator that a court, arbitral, legislative, or government agency of competent jurisdiction has issued an order, rule, statute, regulation, or other requirement that mandates the release of the Deposits to ICANN and/or Registry Operator; and
    9.2 Evidence satisfactory to Escrow Agent that ICANN or Registry Operator (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 in compliance with the laws of Ireland applicable to the use of personal data and any related 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 Operator or a replacement escrow agent, Escrow Agent shall at the same time deliver to Registry Operator a photostatic copy of the notice it received from Registry Operator and/orICANN under Sections 9.1.1 to 9.1.8, as applicable.
    10. Release of Deposit to Registry Operator. Escrow Agent shall deliver all Deposits to Registry Operator 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 Operator pursuant to Section 9, Registry Operator (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 Operator shall have thirty calendar days to 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 Operator 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 Operator 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 Operator 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 Operator 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 Operator's discretion, the Deposits received under Section 9.
    12. Indemnity. Registry Operator 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 Operator and ICANN, and each of their respective directors, officers, agents, employees, members, and stockholders ("Indemnitees") absolutely and forever, from and against any and all claims, actions, damages, suits, liabilities, obligations, costs, fees, charges, and any other expenses whatsoever, including reasonable attorneys' fees and costs, that may be asserted by a third party against any Indemnitee in connection with the misrepresentation, negligence, or misconduct of Escrow Agent, its directors, officers, agents, employees, 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 Operator 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 ninety days prior to the end of the Initial Term or an Additional Term, a party notifies the other parties that it wishes to terminate this Agreement at the end of such term. In the event a party gives the other parties such notice of termination, and Registry Operator and ICANN cannot agree to resolve, by the end of the then-current term, any disputes regarding the renewal of this Agreement or the establishment of a replacement escrow agent: (i) Registry Operator and ICANN shall resolve any such disputes through Subsection 5.1 of the Sponsored TLD Registry Agreement; (ii) this Agreement shall continue to remain in effect during the resolution of any such disputes; and (iii) Escrow Agent shall have the right to invoice either Registry Operator or ICANN for the data escrow services provided during this dispute resolution period at the rates listed in Exhibit E to this Appendix 1.
    14.2 Termination. This Agreement shall terminate upon the occurrence of any of the following:
    14.2.1 Termination of this Agreement by Registry Operator and ICANN, upon having delivered to Escrow Agent a written notice signed by ICANN stating their common intent to terminate this Agreement upon ninety days' notice;
    14.2.2 Termination of this Agreement by Escrow Agent pursuant to Section 15; or
    14.2.3 As provided in Section 14.1.
    15. Fees and Payments. Registry Operator shall pay to Escrow Agent the applicable fees and charges listed in Exhibit E as compensation for Escrow Agent's services under this Agreement. If Registry Operator fails to pay any fees or charges invoiced by Escrow Agent by the due date(s), Escrow Agent shall give written notice to Registry Operator of non-payment of any such past-due fees hereunder and, in that event, the Registry Operator shall have the right to pay the past-due fee(s) within ten business days after receipt of the notice from Escrow Agent. Upon payment of the past-due fee by Registry Operator, this Agreement shall continue in full force and effect. If Registry Operator fails to pay the past-due fee(s) within the applicable periods under this Section 15, Escrow Agent shall have the right to terminate this Agreement immediately by sending notice of termination to all other parties, and, upon termination, Escrow Agent shall deliver to ICANN all Deposits held by Escrow Agent.
    16. Ownership of Deposit Materials. Subject to the provisions of the Sponsored TLD Registry Agreement (including Subsection 6.5), the parties recognize and acknowledge that ownership of the Deposit materials during the effective term of this Agreement shall remain with the Registry Operator at all times.
    17. Miscellaneous.
    17.1 Remedies. For the purposes of fulfilling its obligations under this Agreement, Escrow Agent may act in good faith reliance on, and shall not be held liable for, any written notice, instruction, instrument, or other writing signed or presented by a person with apparent authority to act on behalf of Registry Operator or ICANN.
    17.2 Dispute Resolution. Registry Operator and ICANN agree to resolve any disputes they may have as between or among themselves under this Agreement, including any objections to release of the Deposits pursuant to Section 9.1, solely pursuant to the dispute-resolution procedures in the Sponsored TLD Registry Agreement.
    17.3 Limitation of Liability. The parties shall not be liable to each other for special, indirect, incidental, or consequential damages hereunder. As between Registry Operator and ICANN the liability limitations of the Sponsored TLD Registry Agreement also apply. Neither Registry Operator nor ICANN shall be liable to each under for monetary damages under this Agreement.
    17.4 Independent Contractor. Escrow Agent is an independent contractor and is not an employee or agent of Registry Operator or ICANN.
    17.5 No Third-Party Beneficiaries. This Agreement shall not be construed to create any obligation by Registry Operator, ICANN, or Escrow Agent to any non-party to this Agreement, including but not limited to any domain-name holder or registrar.
    17.6 Amendments. This Agreement shall not be modified or amended except in writing executed by each of the parties.
    17.7 Assignment. Neither Registry Operator nor ICANN may assign or transfer this Agreement (by merger, sale of assets, operation of law, or otherwise), except that the rights and obligations of Registry Operator or ICANN automatically shall be transferred to the assignee of one of those parties' rights and obligations under the Sponsored TLD Registry Agreement. Escrow Agent may not assign or transfer this Agreement without the prior written consent of Registry Operator 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 Operator and ICANN acknowledge and agree that, as between themselves, the Sponsored TLD Registry Agreement (including all its appendices) is intended to co-exist with this Agreement; this Agreement is supplementary to the Sponsored TLD Registry Agreement; and the Sponsored TLD Registry Agreement shall control in the event of any conflict between this Agreement and the 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. 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.



    Appendix 4

    Registry Operator's Monthly Report
    Registry Operator shall provide the following information in its monthly reports. Reports shall be submitted via email to <[email protected]>. ICANN shall use reasonable commercial efforts to preserve the confidentiality of the information reported until three months after the end of the month to which the report relates.
    1. Accredited Registrar Status. State the number of registrars in each of the following three categories: (1) operational, (2) ramp-up (registrars that have received a password for access to OT&E), and (3) pre-ramp-up (registrars that have requested access, but have not yet entered the ramp-up period).
    2. Service Level Agreement Performance. Compare Service Level Agreement requirements with actual performance measures for the reporting month.
    3. TLD Zone File Access Activity. State the total number of zone file access passwords at end of the reporting month.
    4. Completed System Software Releases. Describe significant releases during the reporting month, including release name, features, and completion date.
    5. Whois Service Activity. State the number of Whois queries during the reporting month.
    6. Total Number of Transactions by Subcategory by Month. State the total number of transactions during the reporting month, in the following subcategories: adds, deletes, modifies, checks, renews, transfers, restores.
    7. Daily Transaction Range. Tabulate the number of total daily transactions. The range of transaction volume should be shown for each month, along with the average daily transaction volume.
    8. Per-Registrar Activity Report. This report shall be transmitted to ICANN electronically in comma or pipe separated-value format, using the following fields per registrar:
    Field #
    Field Name
    Notes
    01
    registrar-name
    registrar's full corporate name
    02
    iana-id
    http://www.iana.org/assignments/registrar ids
    03
    total-domains
    total domains under sponsorship
    04
    total-nameservers
    total nameservers registered
    05
    net-adds-1-yr
    domains successfully added (and not deleted within the add grace period)
    06
    net-adds-2-yr
    number of domains successfully registered with an initial term of two years
    07
    net-adds-3-yr
    number of domains successfully registered with an initial term of three years
    08
    net-adds-4-yr
    etc.
    09
    net-adds-5-yr
    " "
    10
    net-adds-6-yr
    " "
    11
    net-adds-7-yr
    " "
    12
    net-adds-8-yr
    " "
    13
    net-adds-9-yr
    " "
    14
    net-adds-10-yr
    " "
    15
    net-renews-1-yr
    domains renewed either automatically or by command (and not deleted within the renew grace period)
    16
    net-renews-2-yr
    number of domains successfully renewed with a new renewal period of two years
    17
    net-renews-3-yr
    number of domains successfully renewed with a new renewal period of three years
    18
    net-renews-4-yr
    etc.
    19
    net-renews-5-yr
    " "
    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-noreport
    total number of restored names for which the registrar failed to submit a restore report



    Appendix 5

    Whois Specifications
    Public Whois Specification


    Public Whois for the Sponsored TLD will be provided according to the specification described in Appendix S.


    Whois Provider Data Specification


    Registry Operator shall ensure the provision of bulk access to up-to-date data concerning domain name and nameserver registrations maintained on behalf of
    Registry Operator in connection with the Sponsored TLD 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 Operator 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 Operator for the purpose of providing free public query-based Whois access as described in Section 3.1(c)(v) of the 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 Operator as soon as practicable.


    3. The Designated Recipient must take such technical and organizational security measures as are, at a minimum, equivalent to those implemented by the Registry Operator with respect to such data.


    4. Except for providing free public query-based access according to item 1 above, the Designated Recipient shall not transfer the data to any third party for any purpose except in the event that such third party becomes bound in the same manner as a Designated Recipient by the provisions of this Appendix and the Whois License Agreement.


    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 the
    Sponsored TLD Registry Agreement. This Appendix is subject to change by agreement of Registry Operator and ICANN during the design process as well as during the IETF standards process. In addition, Registry Operator agrees to ensure the implementation of 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 provides the target architecture and initial functionality.


    A. Procedures for Providing Access


    Registry Operator shall ensure the preparation of (i) full data sets for one day of each week (the day to be designated by ICANN) and (ii) incremental data sets for all seven days of each week. Full and incremental 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.
    (Note that on the ICANN-designated day both an incremental and a full data set are prepared.)


    1. Preparation of Files Containing Data Sets. Each full and incremental 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: For full data sets: "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). For incremental data sets: "wiYYMMDD" where "YYMMDD" follows the same format.


    b. The Registry Operator 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 in case of transfer fault. The Registry Operator may optionally specify to compress the document using the Unix GZIP command (or equivalent) to reduce the file size.


    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.) The Data Recipient's public key will be used for the encryption and the Registry Operator's private key will be used for the signature. Public keys will be exchanged between the Registry Operator and the Designated Recipient 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 either by the procedures for incremental data sets described in item A (3) below or, at the option of either the Registry Operator or the Designated
    Recipient, by writing the full data set to DAT tape (or other media mutually agreed by Registry Operator and the Designated Recipient) and sending it to the
    Designated Recipient by expedited delivery service (such as FedEx or DHL). If sent by expedited delivery service, the full data set will be scheduled for arrival no later than the second calendar day following the day to which the full backup relates.


    3. Transmission of Incremental Data Sets. To permit the transmission of incremental data sets, Registry Operator shall specify to make them available for download by the Designated Recipient by Internet File Transfer Protocol.
    Incremental data sets will be made available for download no later than 2000 UTC on the day to which they relate.


    B. Content


    The data sets (whether full or incremental) will consist of four types of objects:


    1. Domain Objects. One type of object is the domain object, which corresponds to a single Registered Name. Each domain object includes the following data:


    Domain ID
    Domain Name
    Sponsoring Registrar (IANA-assigned identifier)
    Domain Status
    ENS_AuthId
    Registrant, Administrative, Technical and Billing Contact Information (references to appropriate contact objects)
    Maintainer URL
    Names of Nameservers associated with this domain
    Created by Registrar (IANA-assigned identifier)
    Last Updated by Registrar (IANA-assigned identifier)
    Last Transferred Date
    Additional fields (Registry Operator specified)
    Domain Registration Date
    Domain Expiration Date
    Domain Last Updated Date


    2. Nameserver Objects. A second type of object is the nameserver object, which corresponds to a single registered nameserver. The nameserver object includes the following data:


    Nameserver ID
    Nameserver Name
    IP Addresses associated
    Sponsoring Registrar (IANA-assigned identifier)
    Created by Registrar (IANA-assigned identifier)
    Nameserver Last Updated by Registrar (IANA-assigned identifier)
    Created Date
    Last Updated Date
    Last Transferred Date


    3. Contact Objects. A third type of object is the contact object, which corresponds to a single contact (whether registrant, administrative, technical, or billing contact). The contact object includes the following data:


    Contact ID
    Contact Name
    Contact Organization
    Contact Address, City, State/Province, Country
    Contact Postal Code
    Contact Phone, Fax, E-mail
    Contact Registration Date
    Contact Last Updated Date
    Currently Associated
    Contact Status
    Additional fields (Registry Operator specified)
    Sponsoring Registrar (IANA-assigned identifier)
    Created Registrar (IANA-assigned identifier)
    Last Transferred Date


    4. Registrar Object. The final type of object corresponds to a single registrar. It includes the following data:


    Registrar ID (conforming to the IANA registrar-ids registry)
    Registrar Name
    Registrar Status
    Registrar Address, City, State/Province, Country
    Registrar Postal Code
    Registrar Phone, Fax, E-mail
    Registrar Administrative Contacts
    Registrar Technical Contacts
    Registrar Billing Contacts


    5. Objects Contained in Full and Incremental Data Sets. Full data sets include one domain object for each Registered Name within the Sponsored TLD; and nameserver, contact, and registrar objects for each nameserver, contact, and registrar referred to in any domain object. Incremental data sets consist of (a) those of the objects constituting a full data set that have been added or updated since the last incremental data set and (b) notations of deletion of any objects since the last incremental data set.


    C. Format


    Full and incremental data sets will be XML version 1.0, UTF-8 encoded documents conforming to the following document type definition:


    <! DOCTYPE whois-data [<! ELEMENT whois-data (domain*, del-domain*, nameserver*, del-nameserver*, contact*, del-contact*, registrar*, del-registrar*) >
    <! -- Del-domain, del-nameserver, del-contact, and del-registrar child elements are only meaningful where the attribute type= "Incremental" -->
    <!ATTLIST whois-data
    tld NMTOKEN #FIXED "jobs"
    date CDATA #REQUIRED
    type (Full | Incremental)
    version CDATA #FIXED "1.0" >
    <!ELEMENT domain (name, url)>
    <!ATTLIST domain
    dom-id ID #REQUIRED
    registrar-id IDREF #REQUIRED
    registrant-id IDREF #REQUIRED
    ENS_AuthId IDREF #REQUIRED
    admin-id IDREF #REQUIRED
    tech-id IDREF #REQUIRED
    billing-id IDREF #REQUIRED
    nameserver-id IDREFS #IMPLIED
    status (NEW | ACTIVE | INACTIVE | HOLD | LOCK | CLIENT-HOLD | CLIENTLOCK| PENDING-TRANSFER | PENDING-DELETE)
    created-by IDREF #REQUIRED
    updated-by IDREF #REQUIRED
    cre-date CDATA #REQUIRED
    exp-date CDATA #REQUIRED
    upd-date CDATA #REQUIRED
    xfer-date CDATA #REQUIRED>
    <!ELEMENT del-domain EMPTY >
    <!-the presence of this element in an incremental data set indicates that the
    domain has been deleted since the last incremental data set -->
    <!ATTLIST del-domain
    dom-id ID #REQUIRED >
    <!ELEMENT nameserver (name, ip, ip+) >
    <!ATTLIST nameserver
    nameserver-id ID #REQUIRED
    registrar-id IDREF #REQUIRED
    created-by IDREF #REQUIRED
    updated-by IDREF #REQUIRED
    cre-date CDATA #REQUIRED
    upd-date CDATA #REQUIRED
    xfer-date CDATA #REQUIRED >
    <!ELEMENT del-nameserver EMPTY >
    <!-the presence of this element in an incremental data set indicates that the
    nameserver has been deleted since the last incremental data set -->
    <!ATTLIST del-nameserver
    nameserver-id ID #REQUIRED >
    <!ELEMENT contact (name, org, address, post-code, country, phone, fax-, email)
    >
    <!ATTLIST contact
    contact-id ID #REQUIRED
    registrar-id IDREF #REQUIRED
    created-by IDREF #REQUIRED
    updated-by IDREF #REQUIRED
    cre-date CDATA #REQUIRED
    upd-date CDATA #REQUIRED
    xfer-date CDATA #REQUIRED >
    <!ELEMENT del-contact EMPTY >
    <!-the presence of this element in an incremental data set indicates that the
    contact has been deleted since the last incremental data set -->
    <!ATTLIST del-contact
    contact-id ID #REQUIRED >
    <!ELEMENT registrar (reg-status, url) >
    <!ATTLIST registrar
    registrar-id ID #REQUIRED
    contact-id IDREF #REQUIRED
    admin-id IDREFS #REQUIRED
    tech-id IDREFS #REQUIRED
    billing-id IDREFS #REQUIRED
    cre-date CDATA #REQUIRED
    upd-date CDATA #REQUIRED>
    <!ELEMENT del-registrar EMPTY >
    <!-the presence of this element in an incremental data set indicates that the
    registrar has been deleted since the last incremental data set -->
    <!ATTLIST del-registrar
    registrar-id ID #REQUIRED >
    <!ELEMENT name (#PCDATA) >
    <!ELEMENT ip (#PCDATA) >
    <!ELEMENT org (#PCDATA) >
    <!ELEMENT address (#PCDATA) >
    <!ELEMENT post-code (#PCDATA) >
    <!ELEMENT country EMPTY >
    <!ATTLIST country cc (AF | AL | DZ | AS | AD | AO | AI | AQ | AG | AR | AM |
    AW | AU | AT | AZ | BS | BH | BD | BB | BY | BE | BZ | BJ | BM | BT | BO | BA |
    BW | BV | BR | IO | BN | BG | BF | BI | KH | CM | CA | CV | KY | CF | TD | CL | CN
    | CX | CC | CO | KM | CG | CD | CK | CR | CI | HR | CU | CY | CZ | DK | DJ | DM |
    DO | TP | EC | EG | SV | GQ | ER | EE | ET | FK | FO | FJ | FI | FR | GF | PF | TF |
    GA | GM | GE | DE | GH | GI | GR | GL | GD | GP | GU | GT | GN | GW | GY | HT |
    HM | VA | HN | HK | HU | IS | IN | ID | IR | IQ | IE | IL | IT | JM | JP | JO | KZ | KE |
    KI | KP | KR | KW | KG | LA | LV | LB | LS | LR | LY | LI | LT | LU | MO | MK | MG |
    MW | MY | MV | ML | MT | MH | MQ | MR | MU | YT | MX | FM | MD | MC | MN |
    MS | MA | MZ | MM | NA | NR | NP | NL | AN | NC | NZ | NI | NE | NG | NU | NF |
    MP | NO | OM | PK | PW | PS | PA | PG | PY | PE | PH | PN | PL | PT | PR | QA |
    RE | RO | RU | RW | SH | KN | LC | PM | VC | WS | SM | ST | SA | SN | SC | SL |
    SG | SK | SI | SB | SO | ZA | GS | ES | LK | SD | SR | SJ | SZ | SE | CH | SY | TW
    | TJ | TZ | TH | TG | TK | TO | TT | TN | TR | TM | TC | TV | UG | UA | AE | GB |
    US | UM | UY | UZ | VU | VE | VN | VG | VI | WF | EH | YE | YU | ZM | ZW | AC |
    GG | IM | JE | UK ) >
    <!ELEMENT phone (#PCDATA) >
    <!ELEMENT fax (#PCDATA) >
    <!ELEMENT e-mail (#PCDATA) >
    <!ELEMENT reg-status (#PCDATA) >
    <!ELEMENT url (#PCDATA) >


    Whois Data Specification – ICANN


    Registry Operator shall ensure the provision of bulk access by ICANN to up-to date data concerning domain name and nameserver registrations maintained by Registry Operator in connection with the Sponsored TLD on a daily schedule, only for purposes of verifying and ensuring the operational stability of Registry Services, the DNS, and the Internet.


    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 the Sponsored TLD Registry Agreement. This Appendix is subject to change by agreement of Registry Operator and ICANN during the design process as well as during the IETF standards process. In addition, Registry Operator 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 Operator 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 Operator 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 Operator may optionally compress the document using the Unix GZIP command (or equivalent) to reduce the file size.


    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 Operator's private key will be used for the signature. Public keys will be exchanged between the Registry 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 Sponsor and Registry Operator's option, according to paragraph b below:


    a. Registry Operator 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 Operator 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 “Public WhoIs” section of Appendix S.


    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.



    Appendix 6
    (14 November 2008) Schedule of Reserved Names
    Except to the extent that ICANN otherwise expressly authorizes in writing, the Registry Operator shall reserve names formed with the following labels from initial (i.e. other than renewal) registration within the TLD:
    A. Labels Reserved at All Levels. The following names shall be reserved at the second level and at all other levels within the TLD at which Registry Operator makes registrations:
    ICANN-related names:

    • aso
    • gnso
    • icann
    • internic
    • ccnso
    IANA-related names:

    • afrinic
    • apnic
    • arin
    • example
    • gtld-servers
    • iab
    • iana
    • iana-servers
    • iesg
    • ietf
    • irtf
    • istf
    • lacnic
    • latnic
    • rfc-editor
    • ripe
    • root-servers
    B. Additional Second-Level Reservations. In addition, the following names shall be reserved at the second level:

    • All single-character labels - the Registry may also allocate single-character second-level labels (such as a.mobi, 4.mobi) through ICANN-accredited registrars, based upon its implementation of a process using evaluation criteria to meet the needs of the DotMobi sponsored community.
    • All two-character labels shall be initially reserved. The reservation of a two-character label string shall be released to the extent that the Registry Operator reaches agreement with the government and country-code manager, or the ISO 3166 maintenance agency, whichever appropriate. The Registry Operator may also propose release of these reservations based on its implementation of measures to avoid confusion with the corresponding country codes.
    C. Tagged Domain Names. All labels with hyphens in the third and fourth character positions (e.g., "bq--1k2n4h4b" or "xn--ndk061n")
    D. Second-Level Reservations for Registry Operations. The following names are reserved for use in connection with the operation of the registry for the Registry TLD. Registry Operator may use them, but upon conclusion of Registry Operator's designation as operator of the registry for the Registry TLD they shall be transferred as specified by ICANN:

    • nic
    • whois
    • www
    E. Geographic and Geopolitical Names. All geographic and geopolitical names contained in the ISO 3166-1 list from time to time shall initially be reserved at both the second level and at all other levels within the TLD at which the Registry Operator provides for registrations. All names shall be reserved both in English and in all related official languages.
    In addition, Registry Operator 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 Operator 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.




    Appendix 7

    Functional and Performance Specifications
    Pursuant to the responsibility delegated to it in Appendix S, Registry Operator will prescribe functional requirements for Registry Services provided for the Sponsored TLD that shall ensure that at least the following minimum functional capabilitiesare 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 Sponsored TLD MUST be operated in compliance with the following Requests for Comments (RFCs): 1034, 1035, 1101, 2181, 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 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.
    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 under 300 ms and measured packet loss of under 10%. Cross-network Nameserver performance measurements will be conducted by ICANN at times of it’s choosing, in the following manner:
    The measurements will be conducted by sending strings of DNS request packets from each of four measuring locations to each of the Nameservers and observing the responses from the Nameservers. (These strings of requests and responses are referred to as a "CNNP Test".) The measuring locations will be four root nameserver locations (on the US East Coast, US West Coast, Asia, and Europe).
    Each string of request packets will consist of 100 UDP packets at 10-second intervals requesting ns records for arbitrarily selected second-level domains in the Sponsored TLD, preselected to ensure that the names exist in the Sponsored TLD and are resolvable. The packet loss (i.e. the percentage of response packets not received) and the average Round-trip time for response packets received will be noted.
    To meet the packet loss and Round-trip-time requirements for a particular CNNP Test, all three of the following must be true:
    The Round-trip time and packet loss from each measurement location to at least one Nameserver must not exceed the required values.
    The Round-trip time to each of 75% of the Nameservers from at least one of the measurement locations must not exceed the required value.
    The packet loss to each of the Nameservers from at least one of the measurement locations must not exceed the required value.
    Any failing CNNP Test result obtained during an identified Core Internet Service Failure shall not be considered.
    To ensure a properly diverse testing sample, ICANN will conduct the CNNP Tests at varying times (i.e. at different times of day, as well as on
    different days of the week). The cross-network Nameserver performance requirement will be deemed to have not been met only if the Nameservers persistently fail the CNNP Tests with no less than three consecutive failed CNNP Tests to be considered to have persistently failed.
    In the event of persistent failure of the CNNP Tests, ICANN will give Registry Operator written notice of the failures (with backup data) and Registry Operator will have sixty days to cure the failure.
    If, following Registry Operator's opportunity to cure, the Nameservers continue to persistently fail CNNP Tests and Registry Operator fails to resolve the problem within thirty days after written notice of the continuing failures, Registry Operator will be in breach of its obligations under the Registry Agreement.
    Sixty days before the commencement of testing under this provision, ICANN will provide Registry Operator with the opportunity to evaluate the
    testing tools and procedures to be used by ICANN. In the event that Registry Operator does not approve of such tools and procedures, ICANN
    will work directly with Registry Operator to make necessary modifications.
    Whois Service Availability. The committed Performance Specification for Whois Service is 99.4% measured in Monthly Timeframes.
    Whois Service Performance Level. The Whois Service will, on average, be able to handle 50 queries per second.
    Whois Service Response Times. The Whois Service will have a maximum whois query response time of 1.5 seconds. Failure of the Whois Service to respond to three (3) consecutive rcPing commands initiated by the Registry Operator at regular intervals within such maximum processing time shall mean the Whois Service is considered unavailable.
    Whois Service Updates. The data provided by the Whois Service will be updated on at least a daily basis.
    8. Location of Data Centers
    The back-end provider will provide data centers for registration services, currently Afilias Limited. The primary data center is currently located in St. Louis, Missouri, USA. Back-up data centers are currently located in Secaucus, New Jersey, USA and Toronto, Canada.
    9. Fail Over Practice
    The registry shall practice fail over between data centers not less frequently than once every two years.


    Appendix S

    Appendix S
    Part 1.
    DotMobi Charter
    This sTLD Charter (the “Charter”) identifies (a) the purposes for which the .mobi sTLD (the “sTLD”) is delegated, and (b) the community to be served by its delegation.
    Subject to Registry Operator’s compliance with this Registry Operator TLD Registry Agreement, including all attachments and appendices thereto (the “Agreement”) and any Temporary Specifications or Policies or Consensus Policies as defined in the Agreement:

    1. The sTLD will serve:


      1. Mobile consumers, including both individual and business consumers of products, services, devises, content and other items used or accessed while connected over mobile or wireless and organizations that represent such Consumers; and


      1. Providers of those products, services, content, and other items to Consumers and other Providers in connection with their use or access while connected over mobile or wireless, and organizations that represent such Providers.

    1. The sTLD community consists of those Consumers, Providers, and the Representatives of such Consumers and Providers and other parties (each as further defined in Part 3 of this Appendix S) interested in participating in the creation and development of the sTLD for the purpose of delivering a consistent and therefore predictable, high quality user experience across products, services, and content made available through domain names registered within the sTLD namespace.

    1. The sTLD will be managed in accordance with the provisions of the Agreement.

    1. Registry Operator will manage the sTLD in accordance with the provisions of this Agreement and will, without limitation:


      1. Establish policies and procedures for the sTLD;


      1. Establish registration requirements for the sTLD, which may, without limitation, include obligations related to verification of registrant eligibility, willingness to adhere to style guides and other policies and procedures for the sTLD;


      1. Permit Consumers, Providers, and Representative Organisations to register names within the sTLD in accordance with the sTLD policies;


      1. Operate a web site located at www.dotmobi.mobi to inform prospective registrants about registration policies and procedures;


      1. Post on its web site information about its activities, procedures and policies, along with meeting minutes and information about decisions taken so that interested members of the community will have an opportunity to be aware of and respond to Registry Operator's actions and understand how to participate in the sTLD;


      1. Permit creation of and participation in one or more self-organising bodies intended to facilitate participation in the development of policy for the sTLD in an open and transparent manner by:



        1. Providers that have voluntarily agreed to be bound by the provisions of this Charter and have committed to adhere to all sTLD policies developed and published in accordance with the Agreement; and



        1. Consumers and Representative Organisations.
    Appendix S
    Part 2
    Delegated Authority
    Subject to Registry Operator’s compliance with this Registry Operator TLD Registry Agreement, including all attachments and appendices thereto (the “Agreement”) and any Temporary Specifications or Policies or Consensus Policies as defined in the Agreement, and provided the scope of the Charter is not exceeded:
    Registry Operator shall have delegated authority to develop policy for the sTLD in the following areas:
    Product Management

    1. Establishment of domain naming conventions to be used in the Registry Operator TLD.

    1. Functional and performance specifications for Registry Services, other than those specified in the Appendix 7 of the Agreement.

    1. Consistent with any condition under which a Registry Service has been approved, management responsibility for all Registry Services and products, including but not limited to:


      1. Variations, modifications, or extensions of Registry Services that do not represent material changes to a previously approved Registry Service.


      1. Changes to policies and restrictions associated with or necessitated by approved Registry Services (e.g. changes to style guides) as outlined in Clauses 6, 7 and 8 below.


      1. Pricing.


      1. Promotions and promotional products, packaging or pricing.


      1. Branding, naming, or other marketing activity.


      1. Modification of deployment timelines, rollout plans, and implementation details for approved Registry Services.


      1. Withdrawal and suspension of all but basic Registry Services (second level registrations); provided, however, that obligations with registrants existing at the time of the withdrawal or suspension are honored.

    1. Reservation of names to be offered for registration other than on a first-come, first-served basis and creation of the policies and procedures under which such names may be registered.

    1. Identification and reservation of names that are not available for second level registrations and as to which third level names will be offered for registration to end users.
    Restrictions on Registration and Policies for Use of Domain Names

    1. Reservation of names to be withheld from reservation in the sTLD (in addition to those names reserved by ICANN and set forth in a schedule by ICANN).

    1. Policies regarding eligibility to register a domain name in the sTLD, which need not be uniform for all names within the sTLD.

    1. Restrictions and policies on how registered names may be used, which need not be uniform for all names within the sTLD, and which may vary, for example, by type, name, or registrant category.

    1. Establishment of policies applicable to registrants and/or registrars related to mobile content, formatting, services, end-user addressing, operations, eligibility verification, and registration procedures within the domain, consistent with industry and technology standards and practices.
    Operational Policy and Performance Management

    1. Except as specifically set forth in the Agreement, matters related to operation of the registry and the sTLD, including, without limitation:


      1. Performance of eligibility and name-selection services (ENS), either directly by the Registry Operator or by one or more organizations or individuals to which it delegates the responsibility for performing such services;


      1. Operational capability decisions, including location, staffing, organisation structure, capital expenditure, suppliers and, consistent with ICANN approved policies related to selection and management of ICANN-Accredited Registrars, distribution and promotional channels;


      1. Other operations-related processes and procedures, including but not be limited to:



        1. Internal operations of the Registry Operator;



        1. Registry/Registrar relations and channel management, including the terms and conditions contained in the registry/registrar agreement;



        1. Terms and conditions required to be included in the end-user registration agreement;



        1. Management, support, and interactions with the Membership Advisory Group (MAG) and Policy Advisory Board (PAB);



        1. Mechanisms for resolution of disputes between owners of rights in names (such as trademarks) and registrants;



        1. Mechanisms for enforcement of registration restrictions and policies; and



        1. Provisions for publication of registry and registrar data.
    Other

    1. Any other policies or practices not inconsistent with the Agreement, ICANN Temporary Specifications and Policies, or Consensus Policy.
    Appendix S
    Part 3
    Description of the sTLD Community
    Subject to Registry Operator’s compliance with this Registry Operator TLD Registry Agreement, including all attachments and appendices thereto (the “Agreement”) and any Temporary Specifications or Policies or Consensus Policies as defined in the Agreement, and provided the scope of the Charter is not exceeded:
    The Registry Operator TLD community will be defined as all self-identified participants that have a stake in the Charter of the sTLD as described in Part 1 of this Appendix S.

    1. We anticipate the following to be the major beneficiaries and stakeholders in the community:


      1. Mobile consumers, including both individual and business consumers of products, devises, and Internet based services, content and other items used or accessed while connected over mobile or wireless (“Consumers”) and organizations that represent such Consumers; and


      1. Business and other providers (“Providers”) of those products, services, content, applications, and other items to Consumers and other Providers in connection with their use or access while connected over mobile or wireless, and organizations that represent such Providers. Providers include, without limitation:



        1. Providers of content, services, devices, features, and applications for mobile consumption;



        1. Developers and distributors of mobile content, applications and other services that are designated to be usable while mobile;



        1. Mobile operators providing wireless two-way connectivity to Consumers on the move;



        1. Mobile equipment and device manufacturers, vendors, and/or distributors, including, without limitation, handset, networks, software and services vendors; and



        1. Vendors of IT based technologies, hardware, clients, and servers dedicated to serving the mobility community by delivering products or services for Consumers or other Providers.


      1. Representatives of Consumers and Providers and other interested parties (“Representatives”), including, without limitation:



        1. Consumer advocacy organizations;



        1. Mobile technology, mobile media, mobile services and mobile entertainment stakeholder consortia;



        1. Standards and other technical bodies;



        1. Trade and other not-for-profit associations; and



        1. Entrepreneurs, academia, university consortia, researchers, private sector non-governmental organizations.

    1. Registry Operator may modify and/or expand the description of the sTLD Community, consistent with the Agreement, to reflect evolution of the mobile industry and its consumers.
    Appendix S
    Part 4
    Start-up Plan

    Subject to Registry Operator’s compliance with this Registry Operator TLD Registry Agreement, including all attachments and appendices thereto (the “Agreement”) and any Temporary Specifications or Policies or Consensus Policies as defined in the Agreement, and provided the scope of the Charter is not exceeded:

    Registry Operator will implement the following start-up plan:
    BACKGROUND
    The start-up plan provides for the introduction of the sTLD in an orderly, transparent, and logical way, for the purpose of ensuring competition, fairness and reliability for ICANN-Accredited Registrars, registrants, and the sTLD Community (as defined in Part 3 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.
    The plan consists of a multiphase process that will be executed by the Registry Operator.
    TIMELINE
    Registry Operator 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.
    Date
    Event
    In-Process

    • Registry Operator formation and staffing
    • Agreement and Policy development
    Contract Date (“CD”)

    • ICANN contract execution
    • Registry Operator start-up period begins
    • Third-party party registry services provider contract awarded
    CD + 90 Days

    • Registry Operator publishes revised operations timeline
    • Registry Operator publishes Registrar agreements
    CD + 180 Days

    • Registry Operator publishes initial registrant agreements with applicable policy (styleguides)
    • All Registrar agreements complete
    • OT&E testing begins
    CD + 210 days

    • Registrant agreements finalized
    • Premium Names auction process published
    CD + 240 days

    • OT&E testing ends
    • Premium Names auction schedule published
    CD + 270 days

    • Sunrise period registration begins (90 day window)
    • Premium Names first auction conducted
    CD + 360 days

    • SLD name sales begin through ICANN Accredited Registrars
    • Full operations begin
    • Establish timeline for other products and services
    AGREEMENT AND POLICY DEVELOPMENT
    Registry Operator has commenced development of the various agreements and policies needed in connection with the operation of the sTLD and will continue during the start-up period with publication and execution as outlined in the Timeline section. The development of any policy will include a review and update process with Registry Operator’s Policy Advisory Board (“PAB”) and Membership Advisory Group (“MAG).
    The goal of the agreement and policy development period will be to establish a structure that best serves the sTLD Community.
    THIRD PARTY REGISTRY SERVICES PROVIDER
    Registry Operator will conclude contract negotiations with its third party provider of outsourced registry operations for the registry. Outsourced registry operations (“ORO”) will include, but are not limited to, interfaces for registrars, WHOIS-database, 24x7 customer service and technical support.
    Contracting with the ORO provider is designed to enable a quick start-up of sTLD operations with an ICANN knowledgeable registry back-end service provider that has a track record of proven reliability and stability.
    OT&E TESTING
    Registry Operator and ORO provider will conduct comprehensive testing of the registry system and registration procedures (including the interfaces with Registrars and the ENS Services provider(s)). This testing will occur in cooperation with a select group of ICANN accredited registrars (the “Testbed Registrars”) with in put from sTLD Community members as appropriate.
    The goal of OT&E testing is the confirmation that all entities involved in the registration process are prepared for the commencement of full operations and that escalation, support and reporting processes are in place and ready.
    SUNRISE PERIOD
    The Sunrise Period will allow intellectual property owners to register trademarks to which they have title as domain names in the sTLD prior to opening registrations through ICANN Accredited Registrars. Registrants must validate their ownership interests in requested domains through a trademark validation process to avoid abusive or ineligible registrations. The Sunrise Period is currently scheduled for a period of 90 days.
    During the Sunrise period, Registry Operator will closely monitor the day-to-day operation of the registry and the ORO provider and adjust policies and processes as necessary to ensure stable registry operation and prepare for commencement of full operations.
    The goal of the Sunrise period is to ensure, prior to full operations, that only trademark owners can register their trademark as a domain name in the STLD and to resolve disputes among individuals and entities claiming inconsistent or overlapping rights in sTLD names.
    FULL OPERATIONS
    Full operations will commence with the acceptance of domain name registration requests from all eligible registrants through ICANN Accredited Registrars who have executed a contact with Registry Operator (“Participating Registrars”).
    Registrations will generally be accepted on a first-come, first served basis. The UDRP will be used to resolve trademark or name resolution disputes.
    Registry Operator may from time to time update registration operations and procedures and include new products and services consistent with the Registry Agreement.
    The goal of the full operations period is provide continuous and stable registry operation to the Internet Community.
    PRODUCTS AND SERVICES
    Registry Operator intends to make the products and services described in Attachment 1 hereto available to registrants.
    In accordance with the Agreement, Registry Operator may offer additional or modified Registry Services (as defined in the Agreement).
    Registry Operator reserves the right to introduce mini start-up plans for new products and services similar to the above-described initial Start-up Plan. These plans will include appropriate testing periods and service validation for the interface with Registrars and registration process.
    REGISTRY RESERVED NAMES
    Registry Operator intends to reserve certain names, to be permanently reserved or allocated on an other than first-come, first-served basis.
    Appendix S
    Part 4
    Start-up Plan
    Attachment 1:
    DotMobi Product List
    T = Timeline. Launch, 1st year, 2nd year, 3rd year, etc.
    F/S = Domain Feature or Domain Service. Feature means optional new function for existing product with no price change at registry level, Service is an add-on to Domain that that includes additional fee.
    DR = Domain Requirements. Service implementation requirements (style guides) for services implemented
    RGP = Redemption Grace Period. Service to delay availability of a domain for re-assignment after its expiry

    mTLD Product
    Description
    T
    F/S
    Target Market
    Business Model
    Launch Product










    Sunrise SLD w/trademark validation
    Second level domains sold with DR to trademark owners 90 days prior to service launch. Renewal after 5yr initial period via Generic SLD process. Trademark validation service required.
    L
    D
    Trademark owners worldwide
    5yr purchase


    Trademark Validation Service (TVS).
    L
    S


    One time fee during sunrise period
    Generic SLD w/UDRP, RGP
    (ex. somename.mobi)
    Second level domain sold via accredited registrars with DR restrictions that is not already sold or reserved by the registry. Sold on First-come, first-served basis with ICANN UDRP for dispute resolution.
    L
    D
    Mobile service providers
    1yr to 10yr purchase


    Redemption Grace Period (RGP) Service – restored domain pursuant to the Redemption Grace Period Policy (checked for ICANN policy)
    L
    S


    One time fee for redemption
    Premium Names – One time initial purchase
    (ex. travel.mobi, auto.mobi)
    High-value names sold by registry at auction with DR in partnership with selected registrars. Renewal after initial purchase via standard SLD renewal terms. Purchaser must have credible new or existing business in domain description.
    L
    D
    Mobile service providers
    Online auction – high bidder receives name. 1yr initial purchase.
    Bulk Whois
    Whois requests greater than 50/day.
    L
    S
    Internet domains
    Service fee for high-volume Whois requests












    Future Products










    Premium names sold via multi-year fee structure
    High-value names sold by registry at auction with DR where fee is collected over multi-year payment schedule. The payment schedule allows for smaller companies to participate and to ensure that the names are sold for real businesses, not for speculation. Purchaser must have credible new or existing business in domain description.
    1
    S


    Online auction – high bidder receives name with multi-year payment schedule
    Bulk Transfer
    Bulk transfer of domain names from one registrar to another. Subject to compliance with ICANN consensus policies on transfers <http://www.icann.org/transfers>.
    1
    S
    Internet domains
    Fee per transaction size as number of domain names and period: 50000 names transferred per transaction or month – whichever comes first
    Consumer third level domains w/RGP
    Third level domain sold via accredited registrars with DR restrictions that is not already sold or reserved by the registry (johnjones.name.mobi or equivalent) - Allowing owner to move between registrars as needed. Sold on First-come, first-served basis.
    1
    D
    Consumers
    1yr to 10yr purchase
    Local names (seattle.local.mobi)


    Third level domain sold via accredited registrars with DR restrictions for major worldwide cities – previously reserved by registry (seattle.local.mobi or equivalent). Purchaser must have credible new or existing business in domain description.
    1
    D
    Mobile
    Online auction – high bidder receives name. 1yr initial purchase.
    Multi-Lingual Domain Registration Service


    Multi-lingual registration service, offered through ICANN-Accredited Registrars, allowing registrants to register domain names in their native languages. This service will be introduced consistent with ICANN's IDN Guidelines. <http://www.icann.org/general/idn-guidelines-20jun03.htm>.
    1
    F
    Expanded international mobile service providers
    Added to Domain sales when available for no additional fee.
    .mobiMonitor


    This service will allow monitoring of a .mobi domain name, or a keyword and its domains associated with the keywords. Any changes to the domain name data for the linked domains will result in a notification being generated
    1
    S
    Internet domain owners
    Yearly fee for Domain owner.
    .mobiSecure


    JV recognizes the registrants' need to safeguard their data. The mobiLock service intends to provide registrants with the ability to prevent modifications, transfers, or deletions of domain names without explicit permission from the registrant. The service's main purposes are to prevent malicious domain hijacking and domain transfer errors. The registrant will be contacted before any changes are made to their accounts for confirmation of the requested change. The registry, or registrar, under certain special conditions to be determined at a later date, may override a mobiLock
    1
    S
    Internet domain owners
    Yearly fee for Domain owner.
    mobiGuard (restricted WHOIS)
    JV contemplates providing a service in conjunction with registrars that allows organizations and consumers to protect portions of their WHOIS information from the general public. This will protect organizations from spamming, and can be useful to organizations that require a level of anonymity (such as free speech or human rights organizations that operate in politically unfriendly countries). The WHOIS data will remain available, under safeguarding policies and procedures, to qualified entities such as law enforcement bodies and UDRP dispute resolution service providers. This service will not be offered until proper consultation with the Intellectual Property Community to ensure that the enforcement of intellectual property rights are not compromised. Subject to compliance with ICANN consensus policies related to Whois data and privacy.
    1
    F or S
    Internet domain owners
    Added to Domain service when available. Fee to be determined
    Digital Certificates


    JV will investigate offering digital certification services in conjunction with registrars to benefit .mobi registrants.
    Digital certificates could be available at the 40-, 56-, and 128-bit encryption levels. Registrants will need to provide appropriate credentials to verify their organization and their right to use their .mobi domain name. Certificates give the end users of Web sites a higher level of trust; ensure their privacy, and providing a secure mechanism for any online financial transactions. JV might offer a distribution mechanism (currently, a Secure-Socket Layer (SSL) web server farm) that will hold a registrant's public certifications and public PGP keys, allowing for secure yet easy access to these crucial pieces to identity
    1
    S
    Internet domain owners - May be external product
    Added to Domain service when available. Fee to be determined
    Domain Auto Renewal


    When a domain reaches its expiration date the registry will automatically renew the domain for one additional year. A registrar has the duration of the auto-renewal grace period to delete the domain and receive a refund for the automatic renewal. JV’s policy will restrict the maximum outstanding expiration period to ten years.
    1
    S
    Internet domain owners
    Added to Domain sales when available for no additional fee.
    mobiLink


    JV will research providing a service that allows related organizations to provide navigational links to each other, similar to existing Web rings
    1
    S
    Internet domain owners
    Added to Domain sales when available for no additional fee.
    .mobiList


    A pay for placement listing service that provides summary information about all organizations that are registered in the .mobi domain. Registrants can choose to opt-in (or opt-out), during or after domain name registration
    1
    S
    Internet domain owners
    Added to Domain sales when available for no additional fee.
























    Appendix S
    Part 5
    Selection of Registrars
    Subject to Registry Operator’s compliance with this Registry Operator TLD Registry Agreement, including all attachments and appendices thereto (the “Agreement”) and any Temporary Specifications or Policies or Consensus Policies as defined in the Agreement, and provided the scope of the Charter is not exceeded:
    Registry Operator will select registrars from among ICANN-Accredited Registrars in a manner that promotes the following characteristics in the group of authorized ICANN-Accredited Registrars:
    1. Recognition of the specific aspects of the mobile services community to be supported by the sTLD and a willingness to participate in that spirit;
    2. Thorough understanding of the principles and goals underlying sTLD policies, including without limitation the domain name management policy;
    3. Demonstrated ability to provide Eligibility and Name-Selection Services (ENS Services) and demonstrated familiarity with the needs of the sTLD Community in the language and region(s) served by the registrar, and established modes for reflecting these needs in the ENS Services processes;
    4. 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 Operator;
    5. Broad geographic distribution and language diversity of registrars;
    6. Established collaborative contact with one or several associations representing Providers and Representatives (as defined in Part 3 above) in the language and geographical region or sector served by the registrar;
    7. Dedicated willingness and ability to act together with the mobile communications community in the processing of registration requests.
    8. Established business relationships with substantial numbers (proportionate to the size of the registrar) of Providers and Representatives in the region(s) served by the registrar;
    9. Demonstrated willingness and ability to publicize and market the sTLD, to follow all sTLD marketing guidelines, and to develop and use sTLD marketing materials as appropriate, as reflected by a minimum committed marketing budget of an amount proportionate to the size of the registrar;
    10. Demonstration that sufficient staff resources are available and able to interface with automated and manual elements of the sTLD registry process and a willingness to implement modifications and revisions reasonably deemed by the Registry Operator to be required based on the characteristics and functions of the sTLD;
    11. The existence of proven systems designed to avoid submission of unqualified or incomplete applications that will burden the ENS system or make it impossible for Registry Operator to fulfill its commitments to ICANN;
    12. The existence of proven systems to avoid transfer disputes among registrars;
    13. Demonstrated willingness to share relevant marketing information with the Registry Operator, including, consistent with applicable law, information about current registrants with whom the registrar has relationships who are eligible for registration.
    14. Willingness to provide reduced fee or free services to Providers and Representatives from developing countries who meet minimum criteria reasonably established by Registry Operator for special assistance; and
    15. Willingness and ability to post and refresh a minimum deposit against which fees will be drawn.
    This Part 5 of this Appendix S specifies the criteria for Registry Operator’s selection of ICANN Accredited Registrars wishing to enter into a Registry-Registrar Agreement to register domain names in the sTLD. Registry Operator will determine the initial number of ICANN-Accredited Registrars to be selected and, in collaboration wit the sTLD Community, will review and revise its selection of registrars and registrar criteria from time to time as appropriate.
    Appendix S
    Part 6
    Public Whois Specification
    Subject to Registry Operator’s compliance with this Registry Operator TLD Registry Agreement, including all attachments and appendices thereto (the “Agreement”) and any Temporary Specifications or Policies or Consensus Policies as defined in the Agreement, and provided the scope of the Charter is not exceeded:
    Registry Operator will implement the following public WHOIS specification:

    PURPOSE

    Provision of a WHOIS database for the sTLD will assist registrants and appointed contact persons for associated registrations to protect their rights to use the registered domain names.
    SPECIFICATION
    Subject to any future policy regarding WHOIS data adopted by ICANN, domain name registrants will be required to provide correct contact information and, as permitted by applicable law, consent to selected information being made public for legitimate purposes.
    A participating registrar, at the registrar’s expense, will be required to provide those wishing to query the WHOIS database (other than for marketing purposes or other purposes contrary to sTLD policy) with access to complete and up-to-date data for each registered domain name record (subject to applicable privacy policies) including, but not limited to the following:

    • Domain name and the TLD in which the domain name is registered;
    • Status of the domain name, e.g., "on hold" or "pending delete";
    • Registrant's name and postal address;
    • Administrative/technical contacts' name, postal address, e-mail address, telephone number and (if any) facsimile number;
    • Original registration date, expiration date and date on which the database was last updated;
    • Internet Protocol addresses and corresponding names of primary and secondary
    • Name servers for the domain name; and
    • Registrar's identification information.
    In order to assist complainants under the UDRP to determine whether a pattern of "bad faith" has been demonstrated by a particular registrant, the information set forth above will be available on a publicly accessible database, subject to applicable privacy policies, which will be searchable by domain name, registrant's name, registrant's postal address, contacts' names, Registrars Contact IDs and Internet Protocol address without arbitrary limit. In order to provide an effective WHOIS database, Boolean search capabilities may be offered.
    Registrars will be required to participate in the operation of a cross-registry WHOIS database, which will provide searching capabilities and access to all information concerning domain name registrations regardless of which TLD the domain name is registered in or which registrar processed the domain name application.
    Registry Operator will require the registrars to adhere to a compliance review policy. As part of that policy, each registrar will be required to designate a contact point to which evidence of false or fraudulent contact data may be reported. Registrars will institute procedures for investigating claims that registrations may contain false information, and for registrations found to contain false information, requiring their speedy and efficient correction, or otherwise cancellation. Interested third parties may invoke these procedures.
    Registry Operator will provide RFC954-conformant WHOIS service. This Appendix is subject to change by agreement of Registry Operator and ICANN during the design process as well as during the IETF standards process. However, the following provides the target architecture and initial functionality. In addition, Registry Operator agrees to implement changes to this Appendix specified by ICANN to conform to 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].
    RFC954-Conformant WHOIS
    The standard WHOIS service is intended as a lookup service for registries, registrars, registrants, as well as for other individuals and businesses that wish to query details of domain names or nameservers stored in the registry. The standard WHOIS service will provide a central location for all authoritative .mobi TLD data. The registry provides a front-end web interface to allow convenient user access to the WHOIS service.
    The RFC954-conformant WHOIS service will be engineered to handle moderate transaction load and be integral to the standard suite of Registry Services. The WHOIS service will return a single response per domain name or nameserver query. The RFC954-conformant WHOIS service will conform to the requirements of Appendix 6 and 7.
    The RFC954-conformant service provided by the registry will have the following features:

    • Standard protocol accessible over port 43.
    • Batch-style or near real time updates.
    • Additional fields capability.
    • WHOIS Service Data Elements
    WHOIS Service Data Elements
    The RFC954-conformant service will include the following data elements:

    • The name of the domain name registered;
    • The IP addresses of the primary nameserver and secondary nameserver(s) of the name registered, if applicable, i.e. nameserver has a .mobi name;
    • The corresponding names of those nameservers;
    • The identity of the Registry Operator registrar;
    • The original creation date and term of the registration;
    • The name, postal address, e-mail address, voice telephone number, and (where available) fax number of the domain name registrant;
    • The name, postal address, e-mail address, voice telephone number, and (where available) fax number of the technical contact for the name registered;
    • The name, postal address, e-mail address, voice telephone number, and (where available) fax number of the administrative contact for the name registered; and
    • The Maintainer URL (email or website). The maintainer is a person that has been designated by the Registrar for the registration of the domain (for example a reseller, could also depend on the registrant).
    Minimum Data Update Frequency
    Registry Operator shall make reasonable efforts to update the data continuously as requests are processed, in a matter of seconds or minutes. The typical update cycle will be 30 seconds but may be different depending on performance considerations. Registry Operator shall ensure that records in the WHOIS server are updated no later than 24 hours after the completion of the registration or modification transaction with the registrar.
    Additional Fields Capability
    If necessary, Registry Operator may introduce after a 6 to 12 month period of operational stability some additional fields to the list of WHOIS fields. Those fields will be preceded and identified by appropriate tags. Additional fields will not contain any information that could be used to facilitate ENUM applications.
    Privacy Capability
    Registry Operator may introduce the optional ability to associate privacy labels to a record in the Registry Database. These fields would appear in an "additional information" section of the WHOIS data. The maximum number of custom fields allowed per record is yet to be determined. The privacy label capability allows certain data to be associated with an indication of any special disclosure or handling restrictions. This characteristic may be used e.g. to comply with potential regulatory or other telecom subscription related requirements, which mobile operators need to implement in their services.
    Query Control - Object Type Control
    The following keywords restrict a search to specific object type:

    • Domain: Search only by domain objects. The input string is searched in the Name field.
    • Contact: Search only contact objects. The input string is searched in the ID field.
    • Nameserver: Search only by nameserver objects. The input string is searched in the nameserver field or the IP address field.
    • Registrar: Search only registrar objects. The input string is searched in the Name field.
    By default, if no object type control is specified, then the Name field of the Domain object is searched.
    WHOIS Output Fields
    Domain Record:
    A WHOIS query that results in domain information will return the following fields from the Domain object and the associated data from host and contact objects. This set of data is also referred to as the Domain Record.
    Domain ID
    Domain Name
    Domain Status
    Registry Operating Registrar (IANA-assigned identifier)
    Registrant, Administrative, Technical and Billing Contact Information including:
    Contact ID
    Contact Name
    Contact Organization
    Contact Address, City, State/Province, Country
    Contact Postal Code
    Contact Phone, Fax, E-mail
    Maintainer URL
    Names of Nameservers associated with this domain
    Created by Registrar (IANA-assigned identifier)
    Last Updated by Registrar (IANA-assigned identifier)
    Last Transferred Date
    Additional fields (Registry Operator specified, will be defined later, if required)
    Domain Registration Date
    Domain Expiration Date
    Domain Last Updated Date
    Nameserver Record:
    Nameserver ID
    Nameserver name
    Currently Associated (true/false)
    Nameserver status
    IP addresses associated (if applicable)
    Created by Registrar (IANA-assigned identifier)
    Registry Operator Registrar (IANA-assigned identifier)
    Last Updated by Registrar (IANA-assigned identifier)
    Created Date
    Last Updated Date
    Last Transferred Date
    Additional fields
    Note: Any additional fields will be Registry Operator specified, to be defined later if required.
    Contact Record:
    A WHOIS query that results in contact information will return the following. This set of information is referred to as the Contact Record.
    Contact ID
    Contact Name
    Contact Organization
    Contact Address, City, State/Province, Country + 3 street fields
    Contact Postal Code
    Contact Phone, Fax, E-mail
    Contact Registration Date
    Contact Last Updated Date
    Currently Associated
    Contact Status
    Additional fields (Registry Operator specified)
    Registry Operator Registrar (IANA-assigned identifier)
    Created by Registrar (IANA-assigned identifier)
    Last Transferred Date
    Registrar Record:
    A WHOIS query that results in registrar information will return the following. This set of information is referred to as the Registrar Record.
    Registrar ID (conforming to the IANA registrar-ids registry)
    Registrar Name
    Registrar Status
    Registrar Address, City, State/Province, Country
    Registrar Postal Code
    Registrar Phone, Fax, E-mail
    Registrar Administrative Contacts
    Registrar Technical Contacts
    Registrar Billing Contacts

    Sample WHOIS Output

    This section provides sample output from the WHOIS server for each type of Registry Object: Domain, Contact, Nameserver, and Registrar. The output is structured as key/value pairs, which simplifies machine-readability. In the Input section, the quoted string represents the string actually passed to the server in the request packet.
    Domain Record:
    Input: WHOIS "domain = billing.mobi"
    Output: Domain ID: AAA-0001
    Domain Name: BILLING.MOBI
    Registry Operator Registrar: REG-01
    Domain Status: ACTIVE
    Registrant ID: PER-00001
    Registrant Name: FRED SMITH
    Registrant Organization: BILLING, LTD
    Registrant Address: 1 HIGH STREET
    Registrant City: GUILDFORD
    Registrant State/Province: SURREY
    Registrant Country: UK
    Registrant Postal Code: GU1
    Registrant Phone Number: +44-20-123-4567
    Registrant Facsimile Number: +44-20-123-4568
    Registrant Email: [email protected]
    Admin ID: PER-00002
    Admin Name: FRED SMITH
    Admin Organization: BILLING, LTD
    Admin Address: 1 HIGH STREET
    Admin City: GUILDFORD
    Admin State/Province: SURREY
    Admin Country: UK
    Admin Postal Code: GU1
    Admin Phone Number: +44-20-123-4567
    Admin Facsimile Number: +44-20-123-4568
    Admin Email: [email protected]
    Tech ID: PER-00002
    Tech Name: FRED SMITH
    Tech Organization: BILLING, LTD
    Tech Address: 1 HIGH STREET
    Tech City: GUILDFORD
    Tech State/Province: SURREY
    Tech Country: UK
    Tech Postal Code: GU1
    Tech Phone Number: +44-20-123-4567
    Tech Facsimile Number: +44-20-123-4568
    Tech Email: [email protected]
    Billing ID: PER-00002
    Billing Name: FRED SMITH
    Billing Organization: BILLING, LTD
    Billing Address: 1 HIGH STREET
    Billing City: GUILDFORD
    Billing State/Province: SURREY
    Billing Country: UK
    Billing Postal Code: GU1
    Billing Phone Number: +44-20-123-4567
    Billing Facsimile Number: +44-20-123-4568
    Billing Email: [email protected]
    Name Server: NIC.MOBI.ORG
    Name Server: WWW.ICOM.ORG
    Maintainer: [email protected]
    Created By: REG-02
    Updated By: REG-01
    Created On: 2002-01-02
    Expires On: 2004-01-02
    Updated On: 2002-03-02
    Transferred On: 2002-03-02
    Nameserver Record:
    Input: WHOIS "nameserver nic.billing.mobi" or WHOIS "nameserver 130.242.24.6"

    Output:
    Nameserver ID: HST-1
    Nameserver name: NIC.BILLING.MOBI
    Currently Associated (true/false):T
    Nameserver status: ACTIVE
    IP addresses associated: 130.242.28.6
    Registry Operator Registrar: REG-01
    Created By: REG-02
    Updated By: REG-01
    Created On: 2002-01-02
    Updated On: 2002-03-02
    Transferred On: 2002-03-02
    Additional fields (Registry Operator specified, will be defined later, if required)
    Contact Record:
    Input: WHOIS "contact = PER-00002"
    Output: Contact ID: PER-00002
    Name: FRED SMITH
    Organization: BILLING, LTD
    Address: 1 HIGH STREET
    City: GUILDFORD
    State: SURREY
    Country: UK
    Postal Code: GU1
    Phone Number: +44-20-123-4567
    Facsimile Number +44-20-123-4568
    E-mail: [email protected]
    Status: Active
    Registry Operator Registrar: REG-01
    Created By: REG-01
    Created On: 2002-01-02
    Updated On: 2002-01-02
    Transferred On: 0000-00-00
    Registrar Record:
    Input:
    WHOIS "registrar SAMPLE"
    Output:
    Registrar ID: REG-01
    Registrar Name: SAMPLE
    Registrar Status: ACTIVE
    Registrar Address 1: 123 Some Street
    Registrar Address 2:
    Registrar City: Acity
    Registrar State/Province: RE
    Registrar Country: CC
    Registrar Postal Code: 12345
    Registrar Phone: +11-11-1111-1111
    Registrar Fax: +22-22-2222-2222
    Registrar E-mail: [email protected]
    Admin Contact ID: PER-00003
    Tech Contact ID: PER-00004
    Billing Contact Name: PER-00005






    Appendix S
    Part 7
    Additional Provisions
    Interpretation
    For purposes of this Agreement, and for the avoidance of doubt, Registry Operator and ICANN agree that a material failure by ICANN to comply with the provisions of Section 3.1(d) in accordance with its specific terms shall entitle Registry Operator to pursue all remedies under the Agreement otherwise available to it.
    TLD Differentiation
    ICANN and Registry Operator acknowledge that a criterion included in the application process in which the .mobi TLD was selected, and in the previous TLD application expansion round, was that a new TLD be “clearly differentiated from existing TLD’s.” ICANN, when undertaking to effect the delegation of new TLDs, shall take into consideration Internet community input received, including any objections interested third parties may have under policy considerations or applicable law or otherwise, regarding the creation of new TLD strings.
    Appendix S
    Part 8
    Changes
    In accordance with Section 2.1(b) of the Agreement, the following reflects material changes from statements contained in Registry Operator’s application for the TLD, or made by Registry Operator in negotiating this Agreement:
    The following members of the sponsored community are investors in the DotMobi joint venture:
    Handset/ Mobile Infrastructure Manufacturers
    Nokia
    Ericsson
    Samsung
    Mobile Communications Operators
    Vodafone
    T-Mobile
    Telefonica
    TIM
    Hutchison
    GSM
    IT/ Internet Content and Service Providers
    Microsoft
    Sun Microsystems
    Syniverse Technologies
    My .mobi's: Dating.mobi | Dubai.mobi | Adult.mobi | Banking.mobi | Student.mobi | Call.mobi | Horoscope.mobi | Messenger.mobi | Classifieds.mobi | LiveTV.mobi

    Developed: Yup.mobi | Mobility
    | Why .mobi? | Banking | Vuelos | Airline Complaints | Random Site | Whois | Free Mobile Dating | Free Dictionary | Free Thesaurus | Horoscope | Astrology | Free Translation | Exchange Rates


  2. #2
    Senior Member keithmt's Avatar
    Join Date
    Jul 2007
    Location
    Detroit, MI.
    Posts
    1,991

    Default

    This is quite a bit of info to take in! Are you posting this because of concerns you may have with a possible breach of contract by Mtld?

  3. #3
    Senior Member gogo's Avatar
    Join Date
    Oct 2007
    Location
    planet Gogon - M25 class planet
    Posts
    3,452

    Default

    Look at this part:

    Quote Originally Posted by Andres Kello View Post

    Appendix S

    Appendix S
    Part 1.
    DotMobi Charter
    This sTLD Charter (the “Charter”) identifies (a) the purposes for which the .mobi sTLD (the “sTLD”) is delegated, and (b) the community to be served by its delegation.
    Subject to Registry Operator’s compliance with this Registry Operator TLD Registry Agreement, including all attachments and appendices thereto (the “Agreement”) and any Temporary Specifications or Policies or Consensus Policies as defined in the Agreement:

    1. The sTLD will serve:


      1. Mobile consumers, including both individual and business consumers of products, services, devises, content and other items used or accessed while connected over mobile or wireless and organizations that represent such Consumers; and


      1. Providers of those products, services, content, and other items to Consumers and other Providers in connection with their use or access while connected over mobile or wireless, and organizations that represent such Providers.

    1. The sTLD community consists of those Consumers, Providers, and the Representatives of such Consumers and Providers and other parties (each as further defined in Part 3 of this Appendix S) interested in participating in the creation and development of the sTLD for the purpose of delivering a consistent and therefore predictable, high quality user experience across products, services, and content made available through domain names registered within the sTLD namespace.

    1. The sTLD will be managed in accordance with the provisions of the Agreement.

    1. Registry Operator will manage the sTLD in accordance with the provisions of this Agreement and will, without limitation:


      1. Establish policies and procedures for the sTLD;


      1. Establish registration requirements for the sTLD, which may, without limitation, include obligations related to verification of registrant eligibility, willingness to adhere to style guides and other policies and procedures for the sTLD;


      1. Permit Consumers, Providers, and Representative Organisations to register names within the sTLD in accordance with the sTLD policies;


      1. Operate a web site located at www.dotmobi.mobi to inform prospective registrants about registration policies and procedures;


      1. Post on its web site information about its activities, procedures and policies, along with meeting minutes and information about decisions taken so that interested members of the community will have an opportunity to be aware of and respond to Registry Operator's actions and understand how to participate in the sTLD;


      1. Permit creation of and participation in one or more self-organising bodies intended to facilitate participation in the development of policy for the sTLD in an open and transparent manner by:



        1. Providers that have voluntarily agreed to be bound by the provisions of this Charter and have committed to adhere to all sTLD policies developed and published in accordance with the Agreement; and



        1. Consumers and Representative Organisations.
    Appendix S
    Part 2
    Delegated Authority
    Subject to Registry Operator’s compliance with this Registry Operator TLD Registry Agreement, including all attachments and appendices thereto (the “Agreement”) and any Temporary Specifications or Policies or Consensus Policies as defined in the Agreement, and provided the scope of the Charter is not exceeded:
    Registry Operator shall have delegated authority to develop policy for the sTLD in the following areas:
    Product Management

    1. Establishment of domain naming conventions to be used in the Registry Operator TLD.

    1. Functional and performance specifications for Registry Services, other than those specified in the Appendix 7 of the Agreement.

    1. Consistent with any condition under which a Registry Service has been approved, management responsibility for all Registry Services and products, including but not limited to:


      1. Variations, modifications, or extensions of Registry Services that do not represent material changes to a previously approved Registry Service.


      1. Changes to policies and restrictions associated with or necessitated by approved Registry Services (e.g. changes to style guides) as outlined in Clauses 6, 7 and 8 below.


      1. Pricing.


      1. Promotions and promotional products, packaging or pricing.


      1. Branding, naming, or other marketing activity.


      1. Modification of deployment timelines, rollout plans, and implementation details for approved Registry Services.


      1. Withdrawal and suspension of all but basic Registry Services (second level registrations); provided, however, that obligations with registrants existing at the time of the withdrawal or suspension are honored.

    1. Reservation of names to be offered for registration other than on a first-come, first-served basis and creation of the policies and procedures under which such names may be registered.

    1. Identification and reservation of names that are not available for second level registrations and as to which third level names will be offered for registration to end users.
    Restrictions on Registration and Policies for Use of Domain Names

    1. Reservation of names to be withheld from reservation in the sTLD (in addition to those names reserved by ICANN and set forth in a schedule by ICANN).

    1. Policies regarding eligibility to register a domain name in the sTLD, which need not be uniform for all names within the sTLD.

    1. Restrictions and policies on how registered names may be used, which need not be uniform for all names within the sTLD, and which may vary, for example, by type, name, or registrant category.

    1. Establishment of policies applicable to registrants and/or registrars related to mobile content, formatting, services, end-user addressing, operations, eligibility verification, and registration procedures within the domain, consistent with industry and technology standards and practices.
    Operational Policy and Performance Management

    1. Except as specifically set forth in the Agreement, matters related to operation of the registry and the sTLD, including, without limitation:


      1. Performance of eligibility and name-selection services (ENS), either directly by the Registry Operator or by one or more organizations or individuals to which it delegates the responsibility for performing such services;


      1. Operational capability decisions, including location, staffing, organisation structure, capital expenditure, suppliers and, consistent with ICANN approved policies related to selection and management of ICANN-Accredited Registrars, distribution and promotional channels;


      1. Other operations-related processes and procedures, including but not be limited to:



        1. Internal operations of the Registry Operator;



        1. Registry/Registrar relations and channel management, including the terms and conditions contained in the registry/registrar agreement;



        1. Terms and conditions required to be included in the end-user registration agreement;



        1. Management, support, and interactions with the Membership Advisory Group (MAG) and Policy Advisory Board (PAB);



        1. Mechanisms for resolution of disputes between owners of rights in names (such as trademarks) and registrants;



        1. Mechanisms for enforcement of registration restrictions and policies; and



        1. Provisions for publication of registry and registrar data.
    Other

    1. Any other policies or practices not inconsistent with the Agreement, ICANN Temporary Specifications and Policies, or Consensus Policy.
    Appendix S
    Part 3
    Description of the sTLD Community
    Subject to Registry Operator’s compliance with this Registry Operator TLD Registry Agreement, including all attachments and appendices thereto (the “Agreement”) and any Temporary Specifications or Policies or Consensus Policies as defined in the Agreement, and provided the scope of the Charter is not exceeded:
    The Registry Operator TLD community will be defined as all self-identified participants that have a stake in the Charter of the sTLD as described in Part 1 of this Appendix S.

    1. We anticipate the following to be the major beneficiaries and stakeholders in the community:


      1. Mobile consumers, including both individual and business consumers of products, devises, and Internet based services, content and other items used or accessed while connected over mobile or wireless (“Consumers”) and organizations that represent such Consumers; and


      1. Business and other providers (“Providers”) of those products, services, content, applications, and other items to Consumers and other Providers in connection with their use or access while connected over mobile or wireless, and organizations that represent such Providers. Providers include, without limitation:



        1. Providers of content, services, devices, features, and applications for mobile consumption;



        1. Developers and distributors of mobile content, applications and other services that are designated to be usable while mobile;



        1. Mobile operators providing wireless two-way connectivity to Consumers on the move;



        1. Mobile equipment and device manufacturers, vendors, and/or distributors, including, without limitation, handset, networks, software and services vendors; and



        1. Vendors of IT based technologies, hardware, clients, and servers dedicated to serving the mobility community by delivering products or services for Consumers or other Providers.


      1. Representatives of Consumers and Providers and other interested parties (“Representatives”), including, without limitation:



        1. Consumer advocacy organizations;



        1. Mobile technology, mobile media, mobile services and mobile entertainment stakeholder consortia;



        1. Standards and other technical bodies;



        1. Trade and other not-for-profit associations; and



        1. Entrepreneurs, academia, university consortia, researchers, private sector non-governmental organizations.

    1. Registry Operator may modify and/or expand the description of the sTLD Community, consistent with the Agreement, to reflect evolution of the mobile industry and its consumers.
    Appendix S
    Part 4
    Start-up Plan

    Subject to Registry Operator’s compliance with this Registry Operator TLD Registry Agreement, including all attachments and appendices thereto (the “Agreement”) and any Temporary Specifications or Policies or Consensus Policies as defined in the Agreement, and provided the scope of the Charter is not exceeded:

    Registry Operator will implement the following start-up plan:
    BACKGROUND
    The start-up plan provides for the introduction of the sTLD in an orderly, transparent, and logical way, for the purpose of ensuring competition, fairness and reliability for ICANN-Accredited Registrars, registrants, and the sTLD Community (as defined in Part 3 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.
    The plan consists of a multiphase process that will be executed by the Registry Operator.

  4. #4
    Senior Member gogo's Avatar
    Join Date
    Oct 2007
    Location
    planet Gogon - M25 class planet
    Posts
    3,452

    Default

    Post on its web site information about its activities, procedures and policies, along with meeting minutes and information about decisions taken so that interested members of the community will have an opportunity to be aware of and respond to Registry Operator's actions and understand how to participate in the sTLD;
    So where are those minutes for us to read?

    How do we find out about their decisions and participate as ICANN require?

  5. #5
    Senior Member gogo's Avatar
    Join Date
    Oct 2007
    Location
    planet Gogon - M25 class planet
    Posts
    3,452

    Default

    What is most interesting is what is actually NOT there:

    There is no mention of the Dotmobi trustmark or requirements for how .mobi domains are used, or whether such standards must exist or be enforced. So they are in fact optional.

    There is just this:

    1. The sTLD will be managed in accordance with the provisions of the Agreement.

    1. Registry Operator will manage the sTLD in accordance with the provisions of this Agreement and will, without limitation:


      1. Establish policies and procedures for the sTLD;


      1. Establish registration requirements for the sTLD, which may, without limitation, include obligations related to verification of registrant eligibility, willingness to adhere to style guides and other policies and procedures for the sTLD;
    In other words, the trustmark, use and style requirements are NOT hardcoded into the ICANN agreement, so Dotmobi can delete them if they want. In practice they already have, but confusing info about use requirements for Dotmobi domains remains on their site, meaning they retain all of the drawbacks and none of the advantages of having a trustmark that guaranteed you would find mobile content on .mobi domains.

Similar Threads

  1. icann
    By eric mobile investor in forum News & Discussion
    Replies: 0
    Last Post: 10-03-2009, 12:19 AM
  2. The House of ICANN
    By Carlton in forum Mobile Marketing
    Replies: 9
    Last Post: 03-20-2009, 02:30 PM
  3. The Mexico City meeting at http://icann.mobi.
    By Gerry in forum News & Discussion
    Replies: 15
    Last Post: 03-09-2009, 05:46 AM
  4. ICANN - A BIG THREAT TO .MOBI
    By JeremyPadawer in forum News & Discussion
    Replies: 35
    Last Post: 06-02-2008, 03:27 PM
  5. ICANN(T) are so confused...
    By gogo in forum News & Discussion
    Replies: 4
    Last Post: 11-02-2007, 10:35 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
A Yup.mobi Mobile Site
Mobile Dating