本文引用ICANN文档 来源>> 27 June 2013

This REGISTRAR ACCREDITATION AGREEMENT (this "Agreement")is by and between the Internet Corporation forAssigned Names and Numbers,a California non-profit,public benefit corporation (“ICANN”),and [Registrar Name],a Organization type and jurisdiction,and shall be deemed made on at Los Angeles,California,USA. 1.DEFINITIONS. For purposes of this Agreement,the following definitions shall apply: 1.1 “Account Holder”means the person or entity thatis paying for the Registered Name or otherwise controls the management of the registered name,when that person or entity is not the Registered Name Holder. 1.2 "Accredited"or“Accreditation”means to identify and set minimum standards for the performance of registration functions,to recognize persons or entities meeting those standards,and to enter into an accreditation agreement that sets forth the rules and procedures applicable to the provision of RegistrarServices. 1.3 “Affiliate”means a person or entity that,directly or indirectly,through one or more intermediaries,Controls,is controlled by,or is under common control with, the person or entity specified.

1.4 “Affiliated Registrar”is another Accredited registrar thatis an Affiliate of Registrar. 1.5 “Applicable Registrar Family”means,with respect to Affiliated Registrars,such Affiliated Registrar as a group. 1.6 “Consensus Policy”has the meaning set forth in the Consensus Policiesand Temporary Policies Specification attached hereto. 1.7 “Control”(including the terms“controlled by"and“under common control with")means the possession,directly or indirectly,of the power to direct or cause the direction of the management or policies of a person or entity,whether through the ownership of securities,as trustee or executor,by serving as an employee ora

member of aboard of directors or equivalent governing body, by contract, by credit arrangement or otherwise. 1.8 "DNS" refers to the Internet domain-name system. 1.9 The "Effective Date" is . 1.10 The "Expiration Date" is . 1.11 "gTLD" or “gTLDs” refers to the top-level domain(s) of the DNS delegated by ICANN pursuant to a registry agreement that is in full force and effect, other than any country code TLD (ccTLD) or internationalized domain name (IDN) country code TLD. 1.12 "gTLD Zone-File Data" means all data contained in a DNS zone file for the registry, or for any subdomain for which Registry Services are provided and that contains Registered Names, as provided to nameservers on the Internet. 1.13 “Illegal Activity” means conduct involving use of a Registered Name sponsored by Registrar that is prohibited by applicable law and/or exploitation of Registrar’s domain name resolution or registration services in furtherance of conduct involving the use of a Registered Name sponsored by Registrar that is prohibited by applicable law. 1.14 “Personal Data" refers to data about any identified or identifiable natural person. 1.15 "Registered Name" refers to a domain name within the domain of agTLD, whether consisting of two (2) or more (e.g., john.smith.name) levels, about which a gTLD Registry Operator (or an Affiliate or subcontractor thereof engaged in providing Registry Services) maintains data in a Registry Database, arranges for such maintenance, or derives revenue from such maintenance. A name in a Registry Database maybe a Registered Name eventhough it does not appear in a zone file (e.g., a registered but inactive name). 1.16 "Registered Name Holder" means the holder of a Registered Name. 1.17 The word "registrar," when appearing without an initial capital letter, refers to a person or entity that contracts with Registered Name Holders and with a Registry Operator and collects registration data about the Registered Name Holders and submits registration information for entry in the Registry Database. 1.18 “Registrar Approval” means the receipt of either of the following approvals: 1.18.1 The affirmative approval of Applicable Registrars accounting for 90% of the Total Registered Names Under Management by the Applicable Registrars; provided that, for purposes of calculating the Total Registered

Names Under Management by Applicable Registrars, the Total Registered Names Under Management by each Applicable Registrar Family shall not exceed the Total Registered Names Under Management of the Applicable Registrar Family that is the fifth largest Applicable Registrar Family (measured by number of Registered Names Under Management),both for purposes of the numerator and the denominator; or 1.18.2 The affirmative approval of 50% plus one of the Applicable Registrars that participate in the process to approve or disapprove (i.e. vote for or against,but not abstain or otherwise fail to vote) aproposed amendment under Section 6, and the affirmative approval of Applicable Registrars accounting for 66.67% of the Total Registered Names Under Management by all Applicable Registrars; provided that, for purposes of calculating the Total Registered Names Under Management by Applicable Registrars, the Total Registered Names Under Management by each Applicable Registrar Family shall not exceed the total Registered Names Under Management of the Applicable Registrar Family that is the fifth largest Applicable Registrar Family (measured by number of Registered Names Under Management), both for purposes of the numerator and the denominator. An example of these calculations is set forth in Appendix 1 attached hereto. 1.19 "Registrar Services" means the services subject to this Agreement provided by a registrar in connection with agTLD, and includes contracting with Registered Name Holders, collecting registration data about the Registered Name Holders, and submitting registration information for entry in the Registry Database. 1.20 "Registry Data" means all Registry Database data maintained in electronic form, and shall include gTLD Zone-File Data, all data used to provide Registry Services and submitted by registrars in electronic form, and all other data used to provide Registry Services concerning particular domain name registrations or nameservers maintained in electronic form in a Registry Database. 1.21 "Registry Database" means a database comprised of data about one or more DNS domain names within the domain of a registry that is used to generate either DNS resource records that are published authoritatively or responses to domain- name availability lookup requests or Whois queries, for some or all of those names. 1.22 A "Registry Operator" is the person or entity then responsible, in accordance with an agreement between ICANN (or its assignee) and that person or entity (those persons or entities) or, if that agreement is terminated or expires, in accordance with an agreement between the US Government and that person or entity (those persons or entities), for providing Registry Services for a specific gTLD. 1.23 "Registry Services," with respect to a particular gTLD, shall have the meaning defined in the agreement between ICANN and the Registry Operator for that gTLD.

1.24 A “Reseller” is a person or entity that participates in Registrar’s distribution channel for domain name registrations (a) pursuant to an agreement, arrangement or understanding with Registrar or (b) with Registrar’s actual knowledge, provides some or all Registrar Services, including collecting registration data about Registered Name Holders, submitting that data to Registrar, or facilitating the entry of the registration agreement between the Registrar and the Registered Name Holder. 1.25 “Restricted Amendment” means (i) an amendment of the Consensus Policies and Temporary Policies Specification or (ii) the term of this Agreement as specified in Section 5.1, as such term maybe extended pursuant to Section 5.2. 1.26 A Registered Name is "sponsored" by the registrar that placed the record associated with that registration into the registry. Sponsorship of a registration may be changed at the express direction of the Registered Name Holder or, in the event a registrar loses Accreditation, in accordance with then-current ICANN Specifications and Policies. 1.27 “Specifications and/or Policies” include Consensus Policies, Specifications (such as the Whois Accuracy Program Specification) referenced in this Agreement, and any amendments, policies, procedures, or programs specifically contemplated by this Agreement or authorized by ICANN’sBylaws. 1.28 "Term of this Agreement" begins on the Effective Date and continues to the earlier of (a) the Expiration Date, or (b) termination of this Agreement. 1.29 “Total Registered Names Under Management” means the total number of Registered Names sponsored by all Applicable Registrars as reflected in the latest monthly reports submitted to ICANN by Registrars. 1.30 “Whois Accuracy Program Specification” means the Whois Accuracy Program Specification attached hereto, as updated from time to time in accordance with this Agreement. 1.31 “Whois Specification” means the Registration Data Directory Service (Whois) Specification attached hereto, as updated from time to time in accordance with this Agreement. 1.32 “Working Group” means representatives of the Applicable Registrars and other members of the community that the Registrar Stakeholder Group appoints, from time to time,to serve as a working group to consult on amendments to the Applicable Registrar Agreements (excluding bilateral amendments pursuant to Section 6.9).

2. ICANN OBLIGATIONS.

2.1 Accreditation. During the Term of this Agreement and subject to the terms and conditions of this Agreement, Registrar is hereby Accredited by ICANN to act as a registrar (including to insert and renew registration of Registered Names in the Registry Database) for gTLDs. 2.2 Registrar Use of ICANN Name, Website and Trademarks. ICANN hereby grants to Registrar anon-exclusive, worldwide, royalty-free license during the Term of this Agreement (a) to state that it is Accredited by ICANN as a registrar for gTLDs, and (b) to link to pages and documents within the ICANN website. Subject to the terms and conditions set forth in the Logo License Specification attached hereto, ICANN hereby grants to Registrar anon-exclusive, worldwide right and license to use the Trademarks (as defined in the Logo License Specification). No other use of ICANN's name, website or Trademarks is licensed hereby. This license may not be assigned or sublicensed by Registrar to any other party, including, without limitation, any Affiliate of Registrar or any Reseller. 2.3 General Obligations of ICANN. With respect to all matters that impact the rights, obligations, or role of Registrar, ICANN shall during the Term of this Agreement: 2.3.1 exercise its responsibilities in an open and transparent manner; 2.3.2 not unreasonably restrain competition and, to the extent feasible, promote and encourage robust competition; 2.3.3 not apply standards, policies, procedures or practices arbitrarily, unjustifiably, or inequitably and not single out Registrar for disparate treatment unless justified by substantial and reasonable cause; and 2.3.4 ensure, through its reconsideration and independent review policies, adequate appeal procedures for Registrar, to the extent it is adversely affected by ICANN standards, policies, procedures or practices. 2.4 Use of ICANN Accredited Registrars. In order to promote competition in the registration of domain names, and in recognition of the value that ICANN-Accredited registrars bring to the Internet community, ICANN has ordinarily required gTLD registries under contract with ICANN to use ICANN-Accredited registrars, and ICANN will during the course of this agreement abide by any ICANN adopted Specifications or Policies requiring the use of ICANN-Accredited registrars by gTLD registries.

3. REGISTRAR OBLIGATIONS.

3.1 Obligations to Provide Registrar Services. During the Term of this Agreement, Registrar agrees that it will operate as a registrar for one or more gTLDs in accordance with this Agreement. 3.2 Submission of Registered Name Holder Data to Registry. During the Term of this Agreement: 3.2.1 As part of its registration of Registered Names in agTLD, Registrar shall submit to, or shall place in the Registry Database operated by, the Registry Operator for the gTLD the following data elements: 3.2.1.1 The name of the Registered Name being registered; 3.2.1.2 The IP addresses of the primary nameserver and secondary nameserver(s) for the Registered Name; 3.2.1.3 The corresponding names of those nameservers; 3.2.1.4 Unless automatically generated by the registry system, the identity of the Registrar; 3.2.1.5 Unless automatically generated by the registry system, the expiration date of the registration; and 3.2.1.6 Any other data the Registry Operator requires be submitted to it. The agreement between the Registry Operator of agTLD and Registrar may, if approved by ICANN in writing, state alternative required data elements applicable to that gTLD, in which event, the alternative required data elements shall replace and supersede Subsections 3.2.1.1 through 3.2.1.6 stated above for all purposes under this Agreement but only with respect to that particular gTLD. When seeking approval for alternative required data elements, the data elements set forth in Subsections 3.2.1.1 through 3.2.1.6 should be considered suggested minimum requirements. 3.2.2 Within seven (7) days after receiving any updates from the Registered Name Holder to the data elements listed in Subsections 3.2.1.2, 3.1.2.3, and 3.2.1.6 for any Registered Name that Registrar sponsors, Registrarshall submit the updated data elements to, or shall place those elements in the Registry Database operated by, the relevant Registry Operator. 3.2.3 In order to allow reconstitution of the Registry Database in the event of an otherwise unrecoverable technical failure or a change in the designated Registry Operator, within ten (10) days of any such request by ICANN,

Registrarshall submit an electronic database containing the data elements listed in Subsections 3.2.1.1 through 3.2.1.6 for all active records in the registry sponsored by Registrar, in a format specified by ICANN, to the Registry Operator for the appropriate gTLD. 3.3 Public Access to Data on Registered Names. During the Term of this Agreement: 3.3.1 At its expense, Registrarshall provide an interactive webpage and, with respect to any gTLD operating a “thin” registry, a port 43 Whois service (each accessible via both IPv4 and IPv6) providing free public query-based access to up-to-date (i.e., updated at least daily) data concerning all active Registered Names sponsored by Registrar in any gTLD. Until otherwise specified by a Consensus Policy, such data shall consist of the following elements as contained in Registrar's database: 3.3.1.1 The name of the Registered Name; 3.3.1.2 The names of the primary nameserver and secondary nameserver(s) for the Registered Name; 3.3.1.3 The identity of Registrar (which maybe provided through Registrar's website); 3.3.1.4 The original creation date of the registration; 3.3.1.5 The expiration date of the registration; 3.3.1.6 The name and postal address of the Registered Name Holder; 3.3.1.7 The name, postal address,e-mail address, voice telephone number, and (where available) fax number of the technical contact for the Registered Name; and 3.3.1.8 The name, postal address,e-mail address, voice telephone number, and (where available) fax number of the administrative contact for the Registered Name. The agreement between the Registry Operator of agTLD and Registrar may, if approved by ICANN in writing, state alternative required data elements applicable to that gTLD, in which event, the alternative required data elements shall replace and supersede Subsections 3.3.1.1 through 3.3.1.8 stated above for all purposes under this Agreement but only with respect to that particular gTLD. 3.3.2 Upon receiving any updates to the data elements listed in Subsections 3.3.1.2, 3.3.1.3, and 3.3.1.5 through 3.3.1.8 from the Registered Name Holder,

Registrarshall promptly update its database used to provide the public access described in Subsection 3.3.1. 3.3.3 Registrar may subcontract its obligation to provide the public access described in Subsection 3.3.1 and the updating described in Subsection 3.3.2, provided that Registrarshall remain fully responsible for the proper provision of the access and updating. 3.3.4 Registrarshall abide by any Consensus Policy that requires registrars to cooperatively implement a distributed capability that provides query- based Whois search functionality across all registrars. If the Whois service implemented by registrars does not in a reasonable time provide reasonably robust, reliable,and convenient access to accurate and up-to-date data, the Registrarshall abide by any Consensus Policy requiring Registrar, if reasonably determined by ICANN to be necessary (considering such possibilities as remedial action by specific registrars), to supply data from Registrar's database to facilitate the development of a centralized Whois database for the purpose of providing comprehensive Registrar Whois search capability. 3.3.5 In providing query-based public access to registration data as required by Subsections 3.3.1 and 3.3.4, Registrarshall not impose terms and conditions on use of the data provided, except as permitted by any Specification or Policy established by ICANN. Unless and until ICANN establishes a different Consensus Policy, Registrarshall permit use of data it provides in response to queries for any lawful purposes except to: (a) allow, enable, or otherwise support the transmission bye-mail, telephone, postal mail, facsimile or other means of mass unsolicited, commercial advertising or solicitations to entities other than the data recipient's own existing customers; or (b) enable high volume, automated, electronic processes that send queries or data to the systems of any Registry Operator or ICANN- Accredited registrar, except as reasonably necessary to register domain names or modify existing registrations. 3.3.6 In the event that ICANN determines, following analysis of economic data by an economist(s) retained by ICANN (which data has been made available to Registrar), that an individual or entity is able to exercise market power with respect to registrations or with respect to registration data used for development of value-added products and services by third parties, Registrarshall provide third-party bulk access to the data subject to public access under Subsection 3.3.1 under the following terms and conditions: 3.3.6.1 Registrarshall make a complete electronic copy of the data available at least one (1) time per week for download by third parties who have entered into a bulk access agreement with Registrar.

3.3.6.2 Registrar may charge an annual fee, not to exceed US$10,000, for such bulk access to the data. 3.3.6.3 Registrar's access agreementshall require the third party to agree not to use the data to allow, enable, or otherwise support any marketing activities, regardless of the medium used. Such media include but are not limited toe-mail, telephone, facsimile, postal mail, SMS, and wireless alerts. 3.3.6.4 Registrar's access agreementshall require the third party to agree not to use the data to enable high-volume, automated, electronic processes that send queries or data to the systems of any Registry Operator or ICANN-Accredited registrar, except as reasonably necessary to register domain names or modify existing registrations. 3.3.6.5 Registrar's access agreement must require the third party to agree not to sell or redistribute the data except insofar as it has been incorporated by the third party into a value-added product or service that does not permit the extraction of a substantial portion of the bulk data from the value-added product or service for use by other parties. 3.3.7 To comply with applicable statutes and regulations and for other reasons,ICANN may adopt a Consensus Policy establishing limits (a) on the Personal Data concerning Registered Names that Registrar may make available to the public through a public-access service described in this Subsection 3.3 and (b) on the manner in which Registrar may make such data available. Registrarshall comply with any such Consensus Policy. 3.3.8 Registrarshall meet or exceed the requirements set forth in the Whois Specification. 3.4 Retention of Registered Name Holder and Registration Data. 3.4.1 For each Registered Name sponsored by Registrar within agTLD, Registrarshall collect and securely maintain, in its own electronic database, as updated from time to time: 3.4.1.1 the data specified in the Data Retention Specification attached hereto for the period specified therein; 3.4.1.2 The data elements listed in Subsections 3.3.1.1 through 3.3.1.8; 3.4.1.3 the name and (where available) postal address, e-mail address, voice telephone number, and fax number of the billing contact;

3.4.1.4 any other Registry Data that Registrar has submitted to the Registry Operator or placed in the Registry Database under Subsection 3.2; and 3.4.1.5 the name, postal address,e-mail address, and voice telephone number provided by the customer of any privacy service or licensee of any proxy registration service, in each case, offered or made available by Registrar or its Affiliates in connection with each registration. Effective on the date that ICANN fully implements a Proxy Accreditation Program established in accordance with Section 3.14, the obligations under this Section 3.4.1.5 will cease to apply as to any specific category of data (such as postal address) that is expressly required to be retained by another party in accordance with such Proxy Accreditation Program. 3.4.2 During the Term of this Agreement and for two (2) years thereafter, Registrar (itself or by its agent(s)) shall maintain the following records relating to its dealings with the Registry Operator(s) and Registered Name Holders: 3.4.2.1 In electronic form, the submission date and time, and the content, of all registration data (including updates) submitted in electronic form to the Registry Operator(s); 3.4.2.2 In electronic, paper, or microfilm form, all written communications constituting registration applications, confirmations, modifications, or terminations and related correspondence with Registered Name Holders, including registration contracts; and 3.4.2.3 In electronic form, records of the accounts of all Registered Name Holders with Registrar. 3.4.3 During the Term of this Agreement and for two (2) years thereafter, Registrarshall make the data, information and records specified in this Section 3.4 available for inspection and copying by ICANN upon reasonable notice. In addition, upon reasonable notice and request from ICANN, Registrarshall deliver copies of such data, information and records to ICANN in respect to limited transactions or circumstances that maybe the subject of a compliance-related inquiry; provided, however, that such obligationshall not apply to requests for copies of the Registrar’s entire database or transaction history. Such copies are to be provided at Registrar’s expense. In responding to ICANN’s request for delivery of electronic data, information and records, Registrar may submit such information in a format reasonably convenient to Registrar and acceptable to ICANN so as to minimize disruption to the Registrar’s business. In the event Registrar believes that the provision of any such data, information or records to ICANN would

violate applicable law or any legal proceedings, ICANN and Registrar agree to discuss in good faith whether appropriate limitations, protections, or alternative solutions can be identified to allow the production of such data, information or records incomplete or redacted form, as appropriate. ICANN shall not disclose the content of such data, information or records except as expressly required by applicable law, any legal proceeding or Specification or Policy. 3.4.4 Notwithstanding any other requirement in this Agreement or the Data Retention Specification, Registrarshall not be obligated to maintain records relating to a domain registration beginning on the date two (2) years following the domain registration's deletion or transfer away to a different registrar. 3.5 Rights in Data. Registrar disclaims all rights to exclusive ownership or use of the data elements listed in Subsections 3.2.1.1 through 3.2.1.3 for all Registered Names submitted by Registrar to the Registry Database for, or sponsored by Registrar in, each gTLD for which it is Accredited. Registrar does not disclaim rights in the data elements listed in Subsections 3.2.1.4 through 3.2.1.6 and Subsections 3.3.1.3 through 3.3.1.8 concerning active Registered Names sponsored by it in each gTLD for which it is Accredited, and agrees to grant non-exclusive, irrevocable, royalty-free licenses to make use of and disclose the data elements listed in Subsections 3.2.1.4 through 3.2.1.6 and 3.3.1.3 through 3.3.1.8 for the purpose of providing a service or services (such as a Whois service under Subsection 3.3.4) providing interactive, query-based public access. Upon a change in sponsorship from Registrar of any Registered Name in each gTLD for which it is Accredited, Registrar acknowledges that the registrar gaining sponsorshipshall have the rights of an owner to the data elements listed in Subsections 3.2.1.4 through 3.2.1.6 and 3.3.1.3 through 3.3.1.8 concerning that Registered Name, with Registrar also retaining the rights of an owner in that data. Nothing in this Subsection prohibits Registrar from (1) restricting bulk public access to data elements in a manner consistent with this Agreement and any Specifications or Policies or (2) transferring rights it claims in data elements subject to the provisions of this Subsection 3.5. 3.6 Data Escrow. During the Term of this Agreement, on a schedule, under the terms, and in the format specified by ICANN, Registrarshall submit an electronic copy of the data described in Subsections 3.4.1.2 through 3.4.1.5 to ICANN or, at Registrar's election and at its expense, to a reputable escrow agent mutually approved by Registrar and ICANN, such approval also not to be unreasonably withheld by either party. The data shall beheld under an agreement among Registrar, ICANN, and the escrow agent (if any) providing that (1) the data shall be received and held in escrow, with no use other than verification that the deposited data is complete, consistent, and in proper format, until released to ICANN; (2) the data shall be released from escrow upon expiration without renewal or termination of this Agreement; and (3) ICANN's rights under the escrow agreementshall be assigned with any assignment of this Agreement. The escrowshall provide that in

the event the escrow is released under this Subsection, ICANN (or its assignee) shall have anon-exclusive, irrevocable, royalty-free license to exercise (only for transitional purposes) or have exercised all rights necessary to provide Registrar Services. 3.7 Business Dealings, Including with Registered Name Holders. 3.7.1 In the event ICANN adopts a Specification or Policy that is supported by a consensus of ICANN-Accredited registrars as reflected in the Registrar Stakeholder Group (or any successor group), establishing or approving a Code of Conduct for ICANN-Accredited registrars, Registrarshall abide by that Code of Conduct. 3.7.2 Registrarshall abide by applicable laws and governmental regulations. 3.7.3 Registrarshall not represent to any actual or potential Registered Name Holder that Registrar enjoys access to a registry for which Registrar is Accredited that is superior to that of any other registrar Accredited for that registry. 3.7.4 Registrarshall not activate any Registered Name unless and until it is satisfied that it has received a reasonable assurance of payment of its registration fee. For this purpose,a charge to a credit card, general commercial terms extended to creditworthy customers, or other mechanism providing a similar level of assurance of paymentshall be sufficient, provided that the obligation to pay becomes final and non-revocable by the Registered Name Holder upon activation of the registration. 3.7.5 At the conclusion of the registration period, failure by or on behalf of the Registered Name Holder to consent that the registration be renewed within the time specified in a second notice or remindershall, in the absence of extenuating circumstances, result in cancellation of the registration by the end of the auto-renew grace period (although Registrar may choose to cancel the name earlier). 3.7.5.1 Extenuating circumstances are defined as: UDRP action, valid court order, failure of a Registrar's renewal process (which does not include failure of a registrant to respond), the domain name is used by a nameserver that provides DNS service to third-parties (additional time maybe required to migrate the records managed by the nameserver), the registrant is subject to bankruptcy proceedings, payment dispute (where a registrant claims to have paid for a renewal, or a discrepancy in the amount paid),billing dispute (where a registrant disputes the amount on a bill), domain name subject to litigation in a court of competent jurisdiction, or other circumstance as approved specifically by ICANN.

3.7.5.2 Where Registrar chooses, under extenuating circumstances, to renew a domain name without the explicit consent of the registrant, the registrar must maintain a record of the extenuating circumstances associated with renewing that specific domain name for inspection by ICANN consistent with clauses 3.4.2 and 3.4.3 of this registrar accreditation agreement. 3.7.5.3 In the absence of extenuating circumstances (as defined in Section 3.7.5.1 above),a domain name must be deleted within 45 days of either the registrar or the registrant terminating a registration agreement. 3.7.5.4 Registrarshall provide notice to each new registrant describing the details of their deletion and auto-renewal policy including the expected time at which anon-renewed domain name would be deleted relative to the domain's expiration date, or a date range not to exceed ten (10) days in length. If a registrar makes any material changes to its deletion policy during the period of the registration agreement, it must make at least the same effort to inform the registrant of the changes as it would to inform the registrant of other material changes to the registration agreement (as defined in clause 3.7.7 of the registrars accreditation agreement). 3.7.5.5 If Registrar operates a website for domain name registration or renewal, details of Registrar's deletion and auto-renewal policies must be clearly displayed on the website. 3.7.5.6 If Registrar operates a website for domain registration or renewal, it should state, both at the time of registration and in a clear place on its website, any fee charged for the recovery of a domain name during the Redemption Grace Period. 3.7.5.7 In the event that a domain which is the subject of a UDRP dispute is deleted or expires during the course of the dispute, the complainant in the UDRP dispute will have the option to renew or restore the name under the same commercial terms as the registrant. If the complainant renews or restores the name, the name will be placed in Registrar HOLD and Registrar LOCK status, the WHOIS contact information for the registrant will be removed, and the WHOIS entry will indicate that the name is subject to dispute. If the complaint is terminated, or the UDRP dispute finds against the complainant, the name will be deleted within 45 days. The registrant retains the right under the existing redemption grace period provisions to recover the name at anytime during the Redemption Grace Period, and retains the right to renew the name before it is deleted.

3.7.6 Registrarshall not insert or renew any Registered Name in any gTLD registry in a manner contrary to (i) any Consensus Policy stating a list or specification of excluded Registered Names that is in effect at the time of insertion or renewal, or (ii) any list of names to be reserved from registration as required by the specific Registry Operator for which the Registrar is providing Registrar Services. 3.7.7 Registrarshall require all Registered Name Holders to enter into an electronic or paper registration agreement with Registrar including at least the provisions set forth in Subsections 3.7.7.1 through 3.7.7.12, and which agreementshall otherwise set forth the terms and conditions applicable to the registration of a domain name sponsored by Registrar. The Registered Name Holder with whom Registrar enters into a registration agreement must be a person or legal entity other than the Registrar, provided that Registrar maybe the Registered Name Holder for domains registered for the purpose of conducting its Registrar Services, in which case the Registrarshall submit to the provisions set forth in Subsections 3.7.7.1 through 3.7.7.12 and shall be responsible to ICANN for compliance with all obligations of the Registered Name Holder asset forth in this Agreement and Specifications and Policies. Registrarshall use commercially reasonable efforts to enforce compliance with the provisions of the registration agreement between Registrar and any Registered Name Holder that relate to implementing the requirements of Subsections 3.7.7.1 through 3.7.7.12 or any Consensus Policy. 3.7.7.1 The Registered Name Holdershall provide to Registrar accurate and reliable contact details and correct and update them within seven (7) days of any change during the term of the Registered Name registration, including: the full name, postal address,e-mail address, voice telephone number, and fax number if available of the Registered Name Holder; name of authorized person for contact purposes in the case of an Registered Name Holder that is an organization, association, or corporation; and the data elements listed in Subsections 3.3.1.2, 3.3.1.7 and 3.3.1.8. 3.7.7.2 A Registered Name Holder's willful provision of inaccurate or unreliable information, its willful failure to update information provided to Registrar within seven (7) days of any change, or its failure to respond for over fifteen (15) days to inquiries by Registrar concerning the accuracy of contact details associated with the Registered Name Holder's registrationshall constitute a material breach of the Registered Name Holder-registrar contract and be a basis for suspension and/or cancellation of the Registered Name registration. 3.7.7.3 Any Registered Name Holder that intends to license use of a domain name to a third party is nonetheless the Registered Name

Holder of record and is responsible for providing its own full contact information and for providing and updating accurate technical and administrative contact information adequate to facilitate timely resolution of any problems that arise in connection with the Registered Name. A Registered Name Holder licensing use of a Registered Name according to this provisionshall accept liability for harm caused by wrongful use of the Registered Name, unless it discloses the current contact information provided by the licensee and the identity of the licensee within seven (7) days to a party providing the Registered Name Holder reasonable evidence of actionable harm. 3.7.7.4 Registrarshall provide notice to each new or renewed Registered Name Holder stating: 3.7.7.4.1 The purposes for which any Personal Data collected from the applicant are intended; 3.7.7.4.2 The intended recipients or categories of recipients of the data (including the Registry Operator and others who will receive the data from Registry Operator); 3.7.7.4.3 Which data are obligatory and which data, if any, are voluntary; and 3.7.7.4.4 How the Registered Name Holder or data subject can access and, if necessary, rectify the data held about them. 3.7.7.5 The Registered Name Holdershall consent to the data processing referred to in Subsection 3.7.7.4. 3.7.7.6 The Registered Name Holdershall represent that notice has been provided equivalent to that described in Subsection 3.7.7.4 to any third-party individuals whose Personal Data are supplied to Registrar by the Registered Name Holder, and that the Registered Name Holder has obtained consent equivalent to that referred to in Subsection 3.7.7.5 of any such third-party individuals. 3.7.7.7 Registrarshall agree that it will not process the Personal Data collected from the Registered Name Holder in away incompatible with the purposes and other limitations about which it has provided notice to the Registered Name Holder in accordance with Subsection 3.7.7.4 above. 3.7.7.8 Registrarshall agree that it will take reasonable precautions to protect Personal Data from loss, misuse, unauthorized access or disclosure, alteration, or destruction.

3.7.7.9 The Registered Name Holdershall represent that, to the best of the Registered Name Holder's knowledge and belief, neither the registration of the Registered Name nor the manner in which it is directly or indirectly used infringes the legal rights of any third party. 3.7.7.10 For the adjudication of disputes concerning or arising from use of the Registered Name, the Registered Name Holdershall submit, without prejudice to other potentially applicable jurisdictions, to the jurisdiction of the courts (1) of the Registered Name Holder's domicile and (2) where Registrar is located. 3.7.7.11 The Registered Name Holdershall agree that its registration of the Registered Name shall be subject to suspension, cancellation, or transfer pursuant to any Specification or Policy, or pursuant to any registrar or registry procedure not inconsistent with any Specification or Policy, (1) to correct mistakes by Registrar or the Registry Operator in registering the name or (2) for the resolution of disputes concerning the Registered Name. 3.7.7.12 The Registered Name Holdershall indemnify and hold harmless the Registry Operator and its directors, officers, employees, and agents from and against any and all claims, damages, liabilities, costs, and expenses (including reasonable legal fees and expenses) arising out of or related to the Registered Name Holder's domain name registration. 3.7.8 Registrarshall comply with the obligations specified in the Whois Accuracy Program Specification. In addition, notwithstanding anything in the Whois Accuracy Program Specification to the contrary, Registrarshall abide by any Consensus Policy requiring reasonable and commercially practicable (a) verification, at the time of registration, of contact information associated with a Registered Name sponsored by Registrar or (b) periodic re- verification of such information. Registrarshall, upon notification by any person of an inaccuracy in the contact information associated with a Registered Name sponsored by Registrar, take reasonable steps to investigate that claimed inaccuracy. In the event Registrar learns of inaccurate contact information associated with a Registered Name it sponsors, it shall take reasonable steps to correct that inaccuracy. 3.7.9 Registrarshall abide by any Consensus Policy prohibiting or restricting warehousing of or speculation in domain names by registrars. 3.7.10 Registrarshall publish on its website(s) and/or provide a link to the Registrants’ Benefits and Responsibilities Specification attached hereto and shall not take any action inconsistent with the corresponding provisions of this Agreement or applicable law.

3.7.11 Registrarshall make available a description of the customer service handling processes available to Registered Name Holders regarding Registrar Services, including a description of the processes for submitting complaints and resolving disputes regarding the Registrar Services. 3.7.12 Nothing in this Agreement prescribes or limits the amount Registrar may charge Registered Name Holders for registration of Registered Names. 3.8 Domain-Name Dispute Resolution. During the Term of this Agreement, Registrarshall have in place a policy and procedures for resolution of disputes concerning Registered Names. Until ICANN adopts an alternative Consensus Policy or other Specification or Policy with respect to the resolution of disputes concerning Registered Names, Registrarshall comply with the Uniform Domain Name Dispute Resolution Policy (“UDRP”) identified on ICANN's website (www.icann.org/general/consensus-policies.htm),as maybe modified from time to time. Registrarshall also comply with the Uniform Rapid Suspension (“URS”) procedure or its replacement, as well as with any other applicable dispute resolution procedure as required by a Registry Operator for which Registrar is providing Registrar Services. 3.9 Accreditation Fees. As a condition of Accreditation, Registrarshall pay Accreditation fees to ICANN. These fees consist of yearly and variable fees. 3.9.1 Registrarshall pay ICANN a yearly Accreditation fee in an amount established by the ICANN Board of Directors, in conformity with ICANN's bylaws and articles of incorporation. This yearly Accreditation feeshall not exceed US$4,000. Payment of theyearly feeshall be due within thirty (30) days after invoice from ICANN, provided that Registrar may elect to pay the yearly fee in four (4) equal quarterly installments. 3.9.2 Registrarshall pay the variable Accreditation fees established by the ICANN Board of Directors, in conformity with ICANN's bylaws and articles of incorporation, provided that in each case such fees are reasonably allocated among all registrars that contract with ICANN and that any such fees must be expressly approved by registrars accounting, in the aggregate, for payment of two-thirds of all registrar-level fees. Registrarshall pay such fees in a timely manner for so long as all material terms of this Agreement remain in full force and effect, and notwithstanding the pendency of any dispute between Registrar and ICANN. 3.9.3 For any payments thirty (30) days or more overdue, Registrarshall pay interest on late payments at the rate of 1.5% per month or, if less, the maximum rate permitted by applicable law from later of the date of the invoice or the date the invoice is sent pursuant to Section 7.6 of this Agreement. On reasonable notice given by ICANN to Registrar, accountings submitted by Registrarshall be subject to verification by an audit of

Registrar's books and records by an independent third-party designated by ICANN that shall preserve the confidentiality of such books and records (other than its findings as to the accuracy of, and any necessary corrections to,the accountings). 3.9.4 The Accreditation fees due under this Agreement are exclusive of tax. All taxes, duties, fees and other governmental charges of any kind (including sales, turnover, services, use and value-added taxes) that are imposed by or under the authority of any government or any political subdivision thereof on the Accreditation fees for any services, software and/or hardware shall be borne by Registrar and shall not be considered apart of, a deduction from, or an offset against such Accreditation fees. All payments due to ICANN shall be made without any deduction or withholding on account of any tax, duty, charge, or penalty except as required by applicable law, in which case, the sum payable by Registrar from which such deduction or withholding is to be made shall be increased to the extent necessary to ensure that, after making such deduction or withholding, ICANN receives (free from any liability with respect thereof) a net sum equal to the sum it would have received but for such deduction or withholding being required. 3.10 Insurance. Registrarshall maintain in force commercial general liability insurance or similar liability insurance as specified by ICANN with policy limits of at least US$500,000 covering liabilities arising from Registrar's registrar business during the Term of this Agreement. 3.11 Obligations of Registrars under common controlling interest. Registrarshall be in breach of this Agreement if: 3.11.1 ICANN terminates an Affiliated Registrar's accreditation agreement with ICANN (an "Affiliate Termination"); 3.11.2 Affiliated Registrar has not initiated arbitration challenging ICANN's right to terminate the Affiliated Registrar's accreditation agreement under Section 5.8 of this Agreement, or has initiated such arbitration and has not prevailed; 3.11.3 the Affiliate Termination was the result of misconduct that materially harmed consumers or the public interest; 3.11.4 a second Affiliated Registrar has pursued, after the Affiliate Termination, the same course of conduct that resulted in the Affiliate Termination; and 3.11.5 ICANN has provided Registrar with written notice that it intends to assert the provisions of this Section 3.11 with respect to Registrar, which noticeshall identify in reasonable detail the factual basis for such assertion,

and Registrar has failed to cure the impugned conduct within fifteen (15) days of such notice. 3.12 Obligations Related to Provision of Registrar Services by Third Parties. Registrar is responsible for the provision of Registrar Services for all Registered Names that Registrar sponsors being performed in compliance with this Agreement, regardless of whether the Registrar Services are provided by Registrar or a third party, including a Reseller. Registrar must enter into written agreements with all of its Resellers that enable Registrar to comply with and perform all of its obligations under this Agreement. In addition, Registrar must ensure that: 3.12.1 Its Resellers do not display the ICANN or ICANN-Accredited Registrar logo, or otherwise represent themselves as Accredited by ICANN, unless they have written permission from ICANN to do so. 3.12.2 Any registration agreement used by resellershall include all registration agreement provisions and notices required by the ICANN Registrar Accreditation Agreement and any ICANN Consensus Policies, and shall identify the sponsoring registrar or provide a means for identifying the sponsoring registrar, such as a link to the InterNIC Whois lookup service. 3.12.3 Its Resellers identify the sponsoring registrar upon inquiry from the customer. 3.12.4 Its Resellers comply with any ICANN-adopted Specification or Policy that establishes a program for accreditation of individuals or entities who provide proxy and privacy registration services (a “Proxy Accreditation Program”). Among other features, the Proxy Accreditation Program may require that: (i) proxy and privacy registration services may only be provided in respect of domain name registrations by individuals or entities Accredited by ICANN pursuant to such Proxy Accreditation Program; and (ii) Registrarshall prohibit Resellers from knowingly accepting registrations from any provider of proxy and privacy registration services that is not Accredited by ICANN pursuant the Proxy Accreditation Program. Until such time as the Proxy Accreditation Program is established, Registrarshall require Resellers to comply with the Specification on Privacy and Proxy Registrations attached hereto. 3.12.5 Its Resellers'customers are provided with a link to an ICANN webpage detailing registrant educational information, as detailed in subsection 3.16 below. 3.12.6 In the event Registrar learns that a Reseller is causing Registrar to be in breach of any of the provisions of this Agreement, Registrarshall take reasonable steps to enforce its agreement with such Reseller so as to cure and prevent further instances of non-compliance.

3.12.7 Its Resellers shall publish on their website(s) and/or provide a link to the Registrants’ Benefits and Responsibilities Specification attached hereto and shall not take any action inconsistent with the corresponding provisions of this Agreement or applicable law. Registrarshall use commercially reasonable efforts to enforce compliance with the provisions of the agreement between Registrar and any Reseller that relate to the provisions of Registrar Services.

3.13 Registrar Training. Registrar's primary contact as identified in Subsection 7.6 below or designee (so long as the designee is employed by Registrar or an Affiliated Registrar) shall complete a training course covering registrar obligations under ICANN policies and agreements. The course will be provided by ICANN at no expense to Registrar, and shall be available in an online format. 3.14 Obligations Related to Proxy and Privacy Services. Registrar agrees to comply with any ICANN-adopted Specification or Policy that establishes a Proxy Accreditation Program. Registrar also agrees to reasonably cooperate with ICANN in the development of such program. Until such time as the Proxy Accreditation Program is established, Registrar agrees to comply with the Specification on Privacy and Proxy Registrations attached hereto. 3.15 Registrar Self-Assessment and Audits. Registrarshall complete and deliver to ICANN on a schedule and in the form specified by ICANN from time to time in consultation with registrars a Registrar self-assessment. Registrarshall complete and deliver to ICANN within twenty (20) days following the end of each calendar year, in a form specified by ICANN a certificate executed by the president, chief executive officer, chief financial officer or chief operating officer (or their equivalents) of Registrar certifying compliance with the terms and conditions of this Agreement. ICANN may from time to time (not to exceed twice per calendar year) conduct, or engage a third party to conduct on its behalf, contractual compliance audits to assess compliance by Registrar with the terms and conditions of this Agreement. Any audits pursuant to this Section 3.15 shall be tailored to achieve the purpose of assessing compliance, and ICANN will (a) give reasonable advance notice of any such audit, which noticeshall specify in reasonable detail the categories of documents, data and other information requested by ICANN, and (b) use commercially reasonable efforts to conduct such audit in such a manner as to not unreasonably disrupt the operations of Registrar. As part of such audit and upon request by ICANN, Registrarshall timely provide all responsive documents, data and any other information necessary to demonstrate Registrar’s compliance with this Agreement. Upon no less than ten (10) days notice (unless otherwise agreed to by Registrar), ICANN may, as part of any contractual compliance audit, conduct site visits during regular business hours to assess compliance by Registrar with the terms and conditions of this Agreement. ICANN shall not disclose Registrar confidential information gathered through such audits except as required by applicable law, legal proceedings, or as expressly permitted by any Specification or

Policy (including ICANN’s Documentary Information Disclosure Policy, as such policy maybe amended from time to time); provided, however, that, except as required by applicable law or legal proceedings, ICANN shall not release any information that Registrar has marked as, or has otherwise designated in writing to ICANN as, a “confidential trade secret,” “confidential commercial information” or “confidential financial information” of Registrar. If any applicable law, legal proceeding or Specification or Policy permits such disclosure, ICANN will provide Registrar no less than fifteen (15) days notice of its intent to disclose such information, unless such notice is prohibited by law or legal proceeding. Such notice shall include to whom and in what manner ICANN plans to disclose such information. 3.16 Link to Registrant Educational Information. ICANN has published an educational webpage summarizing the terms of the Registrar Accreditation Agreement and related Consensus Policies (as of the date of this Agreement, located at:http://www.icann.org/en/registrars/registrant-rights-responsibilities-en.htm). Registrarshall provide a link to such webpage on any website it may operate for domain name registration or renewal clearly displayed to its Registered Name Holders at least as clearly as its links to policies or notifications required to be displayed under ICANN Consensus Policies. ICANN may, in consultation with registrars, update the content and/or URL for this website. 3.17 Registrar Contact, Business Organization and Officer Information. Registrar shall provide to ICANN and maintain accurate and current information as specified in the Registrar Information Specification to this Agreement. In addition, Registrar shall publish on each website through which Registrar provides or offers Registrar Services the information specified as requiring such publication in the Registrar Information Specification. Registrarshall notify ICANN within five (5) days of any changes to such information and update Registrar’s website(s) within twenty (20) days of any such changes. 3.18 Registrar’s Abuse Contact and Duty to Investigate Reports of Abuse. 3.18.1 Registrarshall maintain an abuse contact to receive reports of abuse involving Registered Names sponsored by Registrar, including reports of Illegal Activity. Registrarshall publish an email address to receive such reports on the homepage of Registrar's website (or in another standardized place that maybe designated by ICANN from time to time). Registrarshall take reasonable and prompt steps to investigate and respond appropriately to any reports of abuse. 3.18.2 Registrarshall establish and maintain a dedicated abuse point of contact, including a dedicated email address and telephone number that is monitored 24 hours a day, seven days a week, to receive reports of Illegal Activity by law enforcement, consumer protection, quasi-governmental or other similar authorities designated from time to time by the national or

territorial government of the jurisdiction in which the Registrar is established or maintains a physical office. Well-founded reports of Illegal Activity submitted to these contacts must be reviewed within 24 hours by an individual who is empowered by Registrar to take necessary and appropriate actions in response to the report. In responding to any such reports, Registrar will not be required to take any action in contravention of applicable law. 3.18.3 Registrarshall publish on its website a description of its procedures for the receipt, handling, and tracking of abuse reports. Registrarshall document its receipt of and response to all such reports. Registrarshall maintain the records related to such reports for the shorter of two (2) years or the longest period permitted by applicable law, and during such period, shall provide such records to ICANN upon reasonable notice. 3.19 Additional Technical Specifications to Implement IPV6, DNSSEC andIDNs. Registrarshall comply with the Additional Registrar Operations Specification attached hereto. 3.20 Notice of Bankruptcy, Convictions and Security Breaches. Registrar will give ICANN notice within seven (7) days of (i) the commencement of any of the proceedings referenced in Section 5.5.8. (ii) the occurrence of any of the matters specified in Section 5.5.2 or Section 5.5.3 or (iii) any unauthorized access to or disclosure of registrant account information or registration data. The notice required pursuant to Subsection (iii) shall include a detailed description of the type of unauthorized access, how it occurred, the number of registrants affected, and any action taken by Registrar in response. 3.21 Obligations of Registrars Affiliated with Registry Operators. In the event Registrar is Affiliated with any Registry Operator or back-end registry operator (an “Affiliated Relationship”) during the Term of this Agreement, Registrarshall comply with all ICANN Specifications and Policies that maybe developed from time to time with respect to such Affiliated Relationships, and will notify ICANN within thirty (30) days of the occurrence of the event that created the Affiliate relationship (e.g., the closing of any merger, acquisition or other transaction, or the execution of any agreement, in each case, giving rise to such Affiliated Relationship). 3.22 Cooperation with Emergency Registry Service Providers. In the event that ICANN transitions the operation of a registry for agTLD in which Registrar sponsors Registered Names to an emergency registry service provider, Registrarshall cooperate in all reasonable respects with such emergency registry service provider, including by entering into a registry-registrar agreement with such provider necessary to effect the transition and by providing all Registered Name Holder data reasonably requested by such emergency operator for the purpose of facilitating an efficient transition of the registry for the gTLD.

4. PROCEDURES FOR ESTABLISHMENT OR REVISION OF SPECIFICATIONS AND POLICIES.

4.1 Compliance with Consensus Policies and Temporary Policies. During the Term of this Agreement, Registrarshall comply with and implement all Consensus Policies and Temporary Policies in existence as of the Effective Date found at http://www.icann.org/general/consensus-policies.htm,and as may in the future be developed and adopted in accordance with the ICANN Bylaws, provided such future Consensus Policies and Temporary Policies are adopted in accordance with the procedures and relate to those topics and subject to those limitations set forth in the Consensus Policies and Temporary Policies Specification to this Agreement. 5. TERM, TERMINATION AND DISPUTE RESOLUTION. 5.1 Term of Agreement. This Agreementshall be effective on the Effective Date and shall have an initial term running until the Expiration Date, unless sooner terminated. 5.2 Renewal. This Agreement and Registrar’s Accreditation will be renewed for successive periods of five (5) years upon the Expiration Date and the expiration of each successive five-year term thereafter under the terms and conditions of this Agreement, unless: 5.2.1 at the time of such renewal, Registrar no longer meets the ICANN registrar Accreditation criteria then in effect; 5.2.2 Registrar is not in compliance with its obligations under this Agreement at the time of the Expiration Date or at the expiration of any successive five (5) year term thereafter; 5.2.3 Registrar has been given notice by ICANN of three (3) or more material breaches of this Agreement within the two (2) years preceding the Expiration Date or the date of expiration of any successive five (5) year term thereafter; or 5.2.4 this Agreement has terminated prior to the Expiration Date or the expiration date of any successive five (5) year term thereafter. In the event Registrar intendstorenew this Agreement pursuant to this Section 5.2, Registrarshall provide ICANN written notice thereof during the period that is no more than ninety (90) days and no less than sixty (60) days prior to the Expiration Date and each successive five (5) year term thereafter. The provision of such notice shall not be a condition to renewal hereunder. Pursuant to its customary practices (as maybe modified by ICANN), ICANN will provide notice to Registrar of the Expiration Date and the date of expiration of any subsequent term hereunder.

5.3 Right to Substitute Updated Agreement. In the event that, during the Term of this Agreement, ICANN adopts a revised form Registrar accreditation agreement (the “Updated RAA”), Registrar (provided it has not received (i) a notice of breach that it has not cured or (ii) a notice of termination or suspension of this Agreement under this Section 5) may elect, by giving ICANN written notice, to enter into the Updated RAA. In the event of such election, Registrar and ICANN shall as soon as practicable enter into the Updated RAA for the term specified in the Updated RAA, and this Agreement will be deemed terminated. 5.4 Termination of Agreement by Registrar. This Agreement maybe terminated before its expiration by Registrar by giving ICANN thirty (30) days written notice. Upon such termination by Registrar, Registrarshall not be entitled to any refund of fees paid to ICANN pursuant to this Agreement. 5.5 Termination of Agreement by ICANN. This Agreement maybe terminated before its expiration by ICANN in any of the following circumstances: 5.5.1 There was a material misrepresentation, material inaccuracy, or materially misleading statement in Registrar's application for Accreditation or renewal of Accreditation or any material accompanying the application. 5.5.2 Registrar: 5.5.2.1 is convicted by a court of competent jurisdiction of a felony or other serious offense related to financial activities, or is judged by a court of competent jurisdiction to have: 5.5.2.1.1 committed fraud, 5.5.2.1.2 committed a breach of fiduciary duty, or 5.5.2.1.3 with actual knowledge (or through gross negligence) permitted Illegal Activity in the registration or use of domain names or in the provision to Registrar by any Registered Name Holder of inaccurate Whois information; or 5.5.2.1.4 failed to comply with the terms of an order issued by a court of competent jurisdiction relating to the use of domain names sponsored by the Registrar; or is the subject of a judicial determination that ICANN reasonably deems as the substantive equivalent of any of the foregoing; or 5.5.2.2 is disciplined by the government of its domicile for conduct involving dishonesty or misuse of funds of others; or

5.5.2.3 is the subject of anon-interlocutory order issued by a court or arbitral tribunal, in each case of competent jurisdiction, finding that Registrar has, directly or through an Affiliate, committed a specific violation(s) of applicable national law or governmental regulation relating to cybersquatting or its equivalent; or 5.5.2.4 is found by ICANN, based on its review of the findings of arbitral tribunals, to have been engaged, either directly or through its Affiliate, in a pattern and practice of trafficking in or use of domain names identical or confusingly similar to a trademark or service mark of a third party in which the Registered Name Holder has no rights or legitimate interest, which trademarks have been registered and are being used in bad faith. 5.5.3 Registrar knowingly employs any officer that is convicted of a misdemeanor related to financial activities or of any felony, or is judged by a court of competent jurisdiction to have committed fraud or breach of fiduciary duty, or is the subject of a judicial determination that ICANN reasonably deems as the substantive equivalent of any of the foregoing and such officer is not terminated within thirty (30) days of Registrar’s knowledge of the foregoing; or any member of Registrar’s board of directors or similar governing body is convicted of a misdemeanor related to financial activities or of any felony, or is judged by a court of competent jurisdiction to have committed fraud or breach of fiduciary duty, or is the subject of a judicial determination that ICANN reasonably deems as the substantive equivalent of any of the foregoing and such member is not removed from Registrar’s board of directors or similar governing body within thirty (30) days of Registrar’s knowledge of the foregoing. 5.5.4 Registrar fails to cure any breach of this Agreement within twenty- one (21) days after ICANN gives Registrar notice of the breach. 5.5.5 Registrar fails to comply with a ruling granting specific performance under Sections 5.7 or 7.1. 5.5.6 Registrar has been in fundamental and material breach of its obligations under this Agreement at least three (3) times within a twelve (12) month period. 5.5.7 Registrar continues acting in a manner that ICANN has reasonably determined endangers the stability or operational integrity ofthe Internet after receiving three (3) days notice of that determination. 5.5.8 (i) Registrar makes an assignment for the benefit of creditors or similar act; (ii) attachment, garnishmentor similar proceedings are commenced against Registrar, which proceedings area material threat to Registrar’s ability to provide Registrar Services for gTLDs, and are not

dismissed within sixty (60) days of their commencement; (iii) atrustee, receiver, liquidator or equivalent is appointed in place of Registrar or maintains control over any of Registrar’s property; (iv) execution is levied upon any property of Registrar, (v) proceedings are instituted by or against Registrar under any bankruptcy, insolvency, reorganization or other laws relating to the relief of debtors and such proceedings are not dismissed within thirty (30) days of their commencement, or (vi) Registrar files for protection under the United States Bankruptcy Code, 11 U.S.C. Section 101 et seq., or a foreign equivalent or liquidates, dissolves or otherwise discontinues its operations. 5.6 Termination Procedures. This Agreement maybe terminated in circumstances described in Subsections 5.5.1 though 5.5.6 above only upon fifteen (15) days written notice to Registrar (in the case of Subsection 5.5.4 occurring after Registrar's failure to cure), with Registrar being given an opportunity during that time to initiate arbitration under Subsection 5.8 to determine the appropriateness of termination under this Agreement. This Agreement maybe terminated immediately upon notice to Registrar in circumstances described in Subsections 5.5.7 and 5.5.8. 5.7 Suspension. 5.7.1 Upon the occurrence of any of the circumstances set forth in Section 5.5, ICANN may, in ICANN’s sole discretion, upon delivery of a notice pursuant to Subsection 5.7.2, elect to suspend Registrar’s ability to create or sponsor new Registered Names or initiate inbound transfers of Registered Names for any or allgTLDs for a period of up to a twelve (12) months following the effectiveness of such suspension. Suspension of a Registrar does not preclude ICANN’s ability to issue a notice of termination in accordance with the notice requirements of Section 5.6. 5.7.2 Any suspension under Subsections 5.7.1 will be effective upon fifteen (15) days written notice to Registrar, with Registrar being given an opportunity during that time to initiate arbitration under Subsection 5.8 to determine the appropriateness of suspension under this Agreement. 5.7.3 Upon suspension, Registrarshall notify users, by posting a prominent notice on its website, that it is unable to create or sponsor new gTLD domain name registrations or initiate inbound transfers of Registered Names. Registrar’s noticeshall include a link to the notice of suspension fromICANN. 5.7.4 If Registrar acts in a manner that ICANN reasonably determines endangers the stability or operational integrity of the Internet and upon notice does not immediately cure, ICANN may suspend this Agreement for five (5) working dayspending ICANN's application for more extended specific performance or injunctive relief under Subsection 7.1. Suspension

of the Agreement under this Subsection may, at ICANN’s sole discretion, preclude the Registrar from (i) providing Registration Services for gTLDs delegated by ICANN on or after the date of delivery of such notice to Registrar and (ii) creating or sponsoring new Registered Names or initiating inbound transfers of Registered Names for any gTLDs. Registrar must also post the statement specified in Subsection 5.7.3. 5.8 Resolution of Disputes Under this Agreement. Subject to the limitations set forth in Section 6 and Section 7.4, disputes arising under or in connection with this Agreement, including (1) disputes arising from ICANN's failure to renew Registrar's Accreditation and (2) requests for specific performance, shall be resolved in a court of competent jurisdiction or, at the election of either party, by an arbitration conducted as provided in this Subsection 5.8 pursuant to the International Arbitration Rules of the American Arbitration Association ("AAA"). The arbitration shall be conducted in English and shall occur in Los Angeles County, California, USA. Except asset forth in Section 7.4.5, there shall be one (1) arbitrator agreed by the parties from a list of AAA arbitrators, or if parties do not agree on an arbitrator within fifteen (15) days of the AAA request that the parties designate an arbitrator, the AAA shall choose and appoint an arbitrator, paying due regard to the arbitrator’s knowledge of the DNS. The parties shall bear the costs of the arbitration in equal shares, subject to the right of the arbitrator to reallocate the costs in their award as provided in the AAA rules. The parties shall bear their own attorneys'fees in connection with the arbitration, and the arbitrator may not reallocate the attorneys' fees in conjunction with their award. The arbitratorshall render its decision within ninety (90) days of the conclusion of the arbitration hearing. In the event Registrar initiates arbitration to contest the appropriateness of termination of this Agreement by ICANN pursuant to Section 5.5 or suspension of Registrar by ICANN pursuant to Section 5.7.1, Registrar may at the sametime request that the arbitration panel stay the termination or suspension until the arbitration decision is rendered. The arbitration panelshall order a stay: (i) upon showing by Registrar that continued operations would not be harmful to consumers or the public interest, or (ii) upon appointment by the arbitration panel of a qualified third party to manage the operations of the Registrar until the arbitration decision is rendered. In furtherance of sub-clause (ii) above, the arbitration panel is hereby granted all necessary authority to appoint a qualified third-party to manage the operations of the Registrar upon the Registrar’s request and if the panel deems it appropriate. In selecting the third-party manager, the arbitration panelshall take into consideration, but shall not be bound by, any expressed preferences of Registrar. Any order granting a request for a stay must be issued within fourteen (14) days after the filing of the arbitration. If an order granting a request for a stay is not issued within fourteen (14) days, ICANN has the right to proceed with the termination of this Agreement pursuant to Section 5.5 or suspension of the Registrar pursuant to Section 5.7.1. In the event Registrar initiates arbitration to contest an Independent Review Panel's decision under Subsection 4.3.3 sustaining the ICANN Board of Director's determination that a specification or policy is supported by consensus, Registrar may at the sametime request that the arbitration

panel stay the requirement that it comply with the policy until the arbitration decision is rendered, and that requestshall have the effect of staying the requirement until the decision or until the arbitration panel has granted an ICANN request for lifting of the stay. In all litigation involving ICANN concerning this Agreement (whether in a case where arbitration has not been elected or to enforce an arbitration award), jurisdiction and exclusive venue for such litigation shall be in a court located in Los Angeles, 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 temporary or preliminary injunctive relief from the arbitration panel or in a court located in Los Angeles, California, USA, which shall not be a waiver of this arbitration agreement. 5.9 Limitations on Monetary Remedies for Violations of this Agreement. ICANN's aggregate monetary liability for violations of this Agreementshall not exceed an amount equal to the Accreditation fees paid by Registrar to ICANN under Subsection 3.9 of this Agreement during the preceding twelve-month period. Registrar's monetary liability to ICANN for violations of this Agreementshall be limited to Accreditation fees owing to ICANN under this Agreement and, except in the case of a good faith disagreement concerning the interpretation of this agreement, reasonable payment to ICANN for the reasonable and direct costs including attorney fees, staff time, and other related expenses associated with legitimate efforts to enforce Registrar compliance with this agreement and costs incurred by ICANN to respond to or mitigate the negative consequences of such behavior for Registered Name Holders and the Internet community. In the event of repeated willful material breaches of the agreement, Registrarshall be liable for sanctions of up to five (5) times ICANN's enforcement costs, but otherwise in no eventshall either party be liable for special, indirect, incidental, punitive, exemplary, or consequential damages for any violation of this Agreement. 6. AMENDMENT AND WAIVER. 6.1 If the ICANN Board of Directors determines that an amendment to this Agreement (including to the Specifications referred to herein, unless such Specifications expressly do not permit amendment thereto) and all other registrar agreements between ICANN and the Applicable Registrars (the “Applicable Registrar Agreements”) is desirable (each, a “Special Amendment”), ICANN may adopt a Special Amendment pursuant to the requirements of and process set forth in this Section 6; provided that a Special Amendment may not be a Restricted Amendment. 6.2 Prior to submitting a Special Amendment for Registrar Approval, ICANN shall first consult in good faith with the Working Group regarding the form and substance of such Special Amendment. The duration of such consultationshall be reasonably determined by ICANN based on the substance of the Special Amendment. Following

such consultation, ICANN may propose the adoption of a Special Amendment by publicly posting such amendment on its website for no less than thirty (30) calendar days (the “Posting Period”) and providing notice of such proposed amendment to the Applicable Registrars in accordance with Section 7.6. ICANN will consider the public comments submitted on a Special Amendment during the Posting Period (including comments submitted by the Applicable Registrars). 6.3 If, within one hundred eighty (180) calendar days following the expiration of the Posting Period (the “Approval Period”), the ICANN Board of Directors approves a Special Amendment (which maybe in a form different than submitted for public comment, but must address the subject matter of the Special Amendment posted for public comment, as modified to reflect and/or address input from the Working Group and public comments), ICANN shall provide notice of, and submit, such Special Amendment for approval or disapproval by the Applicable Registrars. If, during the sixty (60) calendar day period following the date ICANN provides such notice to the Applicable Registrars, such Special Amendment receives Registrar Approval, such Special Amendmentshall be deemed approved (an “Approved Amendment”) by the Applicable Registrars, and shall be effective and deemed an amendment to this Agreement on the date that is sixty (60) calendar days following the date ICANN provided notice of the approval of such Approved Amendment to Registrar (the “Amendment Effective Date”). In the event that a Special Amendment does not receive Registrar Approval, the Special Amendmentshall be deemed not approved by the Applicable Registrars (a “Rejected Amendment”). A Rejected Amendment will have no effect on the terms and conditions of this Agreement, except asset forth below. 6.4 If the ICANN Board of Directors reasonably determines that a Rejected Amendment falls within the subject matter categories set forth in Section 1.2 of the Consensus Policies and Temporary Policies Specification, the ICANN Board of Directors may adopt a resolution (the date such resolution is adopted is referred to herein as the “Resolution Adoption Date”) requesting an Issue Report (as such term is defined in ICANN’s Bylaws) by the Generic Names Supporting Organization (the “GNSO”) regarding the substance of such Rejected Amendment. The policy development process undertaken by the GNSO pursuant to such requested Issue Report is referred to herein as a “PDP.” If such PDP results in a Final Report supported by a GNSO Supermajority (as defined in ICANN’s Bylaws) that either (i) recommends adoption of the Rejected Amendment as Consensus Policy or (ii) recommends against adoption of the Rejected Amendment as Consensus Policy, and, in the case of (i) above, the Board adopts such Consensus Policy, Registrarshall comply with its obligations pursuant to Section 4 of this Agreement. In either case, ICANN will abandon the Rejected Amendment and it will have no effect on the terms and conditions of this Agreement. Notwithstanding the foregoing provisions of this Section 6.4, the ICANN Board of Directors shall not be required to initiate a PDP with respect to aRejected Amendment if, at anytime in the twelve (12) month period preceding the submission of such Rejected Amendment for Registrar Approval pursuant to Section 6.3, the subject matter of such Rejected Amendment was the

subject of a concluded or otherwise abandoned or terminated PDP that did not result in a GNSO Supermajority recommendation. 6.5 If (i) a Rejected Amendment does not fall within the subject matter categories set forth in Section 1.2 of the Consensus Policies and Temporary Policies Specification , (ii) the subject matter of a Rejected Amendment was, at anytime in the twelve (12) month period preceding the submission of such Rejected Amendment for Registrar Approval pursuant to Section 6.3, the subject of a concluded or otherwise abandoned or terminated PDP that did not result in a GNSO Supermajority recommendation, or (iii) a PDP does not result in a Final Report supported by a GNSO Supermajority that either (a) recommends adoption of the Rejected Amendment as Consensus Policy or (b) recommends against adoption of the Rejected Amendment as Consensus Policy (or such PDP has otherwise been abandoned or terminated for any reason), then, in any such case, such Rejected Amendment may still be adopted and become effective in the manner described below. In order for the Rejected Amendment to be adopted, the following requirements must be satisfied: 6.5.1 the subject matter of the Rejected Amendment must be within the scope of ICANN’s mission and consistent with a balanced application of its core values (as described in ICANN’s Bylaws); 6.5.2 the Rejected Amendment must be justified by a Substantial and Compelling Reason in the Public Interest, must be likely to promote such interest, taking into account competing public and private interests that are likely to be affected by the Rejected Amendment, and must be narrowly tailored and no broader than reasonably necessary to address such Substantial and Compelling Reason in the Public Interest; 6.5.3 to the extent the Rejected Amendment prohibits or requires conduct or activities, imposes material costs on the Applicable Registrars, and/or materially reduces public access to domain name services, the Rejected Amendment must be the least restrictive means reasonably available to address the Substantial and Compelling Reason in the Public Interest; 6.5.4 the ICANN Board of Directors must submit the Rejected Amendment, along with awritten explanation of the reasoning related to its determination that the Rejected Amendment meets the requirements set out in subclauses (i) through (iii) above, for public comment for a period of no less than thirty (30) calendar days; and 6.5.5 following such public comment period, the ICANN Board of Directors must (i) engage in consultation (or direct ICANN management to engage in consultation) with the Working Group, subject matter experts, members of the GNSO, relevant advisory committees and other interested stakeholders with respect to such Rejected Amendment for a period of no less than sixty

(60) calendar days; and (ii) following such consultation, reapprove the Rejected Amendment (which maybe in a form different than submitted for Registrar Approval, but must address the subject matter of the Rejected Amendment, as modified to reflect and/or address input from the Working Group and public comments) by the affirmative vote of at least two-thirds of the members of the ICANN Board of Directors eligible to vote on such matter, taking into account any ICANN policy affecting such eligibility, including ICANN’s Conflict of Interest Policy (a “Board Amendment”). Such Board Amendmentshall, subject to Section 6.6, be deemed an Approved Amendment, and shall be effective and deemed an amendment to this Agreement on the date that is sixty (60) calendar days following the date ICANN provided notice of the approval of such Board Amendment to Registrar (which effective dateshall be deemed the Amendment Effective Date hereunder). Notwithstanding the foregoing, a Board Amendment may not amend the registrar fees charged by ICANN hereunder, or amend this Section 6. 6.6 Notwithstanding the provisions of Section 6.5, a Board Amendmentshall not be deemed an Approved Amendment if, during the thirty (30) calendar day period following the approval by the ICANN Board of Directors of the Board Amendment, the Working Group, on the behalf of the Applicable Registrars, submits to the ICANN Board of Directors an alternative to the Board Amendment (an “Alternative Amendment”) that meets the following requirements: 6.6.1 sets forth the precise text proposed by the Working Group to amend this Agreement in lieu of the Board Amendment; 6.6.2 addresses the Substantial and Compelling Reason in the Public Interest identified by the ICANN Board of Directors as the justification for the Board Amendment; and 6.6.3 compared to the Board Amendment is: (a) more narrowly tailored to address such Substantial and Compelling Reason in the Public Interest, and (b) to the extent the Alternative Amendment prohibits or requires conductor activities, imposes material costs on Affected Registrars, or materially reduces access to domain name services, is a less restrictive means to address the Substantial and Compelling Reason in the Public Interest. Any proposed amendment that does not meet the requirements of subclauses 6.6.1 through 6.6.3 in the immediately preceding sentenceshall not be considered an Alternative Amendment hereunder and therefore shall not supersede or delay the effectiveness of the Board Amendment. If, following the submission of the Alternative Amendment to the ICANN Board of Directors, the Alternative Amendment receives Registrar Approval, the Alternative Amendmentshall supersede the Board Amendment and shall be deemed an Approved Amendment hereunder (and shall be effective and deemed an amendment to this Agreement on

the date that is sixty (60) calendar days following the date ICANN provided notice of the approval of such Alternative Amendment to Registrar, which effective dateshall deemed the Amendment Effective Date hereunder), unless, within a period of sixty (60) calendar days following the date that the Working Group notifies the ICANN Board of Directors of Registrar Approval of such Alternative Amendment (during which time ICANN shall engage with the Working Group with respect to the Alternative Amendment), the ICANN Board of Directors by the affirmative vote of at least two-thirds of the members of the ICANN Board of Directors eligible to vote on such matter, taking into account any ICANN policy affecting such eligibility, including ICANN’s Conflict of Interest Policy, rejects the Alternative Amendment. If (A) the Alternative Amendment does not receive Registrar Approval within thirty (30) days of submission of such Alternative Amendment to the Applicable Registrars (and the Working Groupshall notify ICANN of the date of such submission), or (B) the ICANN Board of Directors rejects the Alternative Amendment by such two-thirds vote, the Board Amendment (and not the Alternative Amendment) shall be effective and deemed an amendment to this Agreement on the date that is sixty (60) calendar days following the date ICANN provided notice to Registrar (which effective date shall deemed the Amendment Effective Date hereunder). If the ICANN Board of Directors rejects an Alternative Amendment, the boardshall publish a written rationale setting forth its analysis of the criteria set forth in Sections 6.6.1 through 6.6.3. The ability of the ICANN Board of Directors to reject an Alternative Amendment hereunder does not relieve the Board of the obligation to ensure that any Board Amendment meets the criteria set forth in Section 6.5.1 through 6.5.5. 6.7 In the event that Registrar believes an Approved Amendment does not meet the substantive requirements set out in this Section 6 or has been adopted in contravention of any of the procedural provisions of this Section 6,Registrar may challenge the adoption of such Special Amendment pursuant to the dispute resolution provisions set forth in Section 5.8, except that such arbitration shall be conducted by a three-person arbitration panel. Any such challenge must be brought within sixty (60) calendar days following the date ICANN provided notice to Registrar of the Approved Amendment, and ICANN may consolidate all challenges brought by registrars (including Registrar) into asingle proceeding. The Approved Amendment will be deemed not to have amended this Agreement during the pendency of the dispute resolution process. 6.8 Registrar may apply in writing to ICANN for an exemption from the Approved Amendment (each such request submitted by Registrar hereunder, an “Exemption Request”) during the thirty (30) calendar day period following the date ICANN provided notice to Registrar of such Approved Amendment. 6.8.1 Each Exemption Request will set forth the basis for such request and provide detailed support for an exemption from the Approved Amendment. An Exemption Request may also include a detailed description and support for any alternatives to, or a variation of, the Approved Amendment proposed by such Registrar.

6.8.2 An Exemption Request may only be granted upon a clear and convincing showing by Registrar that compliance with the Approved Amendment conflicts with applicable laws or would have a material adverse effect on the long-term financial condition or results of operations of Registrar. No Exemption Request will be granted if ICANN determines, in its reasonable discretion, that granting such Exemption Request would be materially harmful to registrants or result in the denial of a direct benefit to registrants. 6.8.3 Within ninety (90) calendar days of ICANN’s receipt of an Exemption Request, ICANN shall either approve (which approval maybe conditioned or consist of alternatives to or a variation of the Approved Amendment) or deny the Exemption Request in writing, during which time the Approved Amendment will not amend this Agreement. 6.8.4 If the Exemption Request is approved by ICANN, the Approved Amendment will not amend this Agreement; provided, that any conditions, alternatives or variations of the Approved Amendment required by ICANN shall be effective and, to the extent applicable, will amend this Agreement as of the Amendment Effective Date. If such Exemption Request is denied by ICANN, the Approved Amendment will amend this Agreement as of the Amendment Effective Date (or, if such date has passed, such Approved Amendmentshall be deemed effective immediately on the date of such denial), provided that Registrar may, within thirty (30) calendar days following receipt of ICANN’s determination, appeal ICANN’s decision to deny the Exemption Request pursuant to the dispute resolution procedures set forth in Section 5.8. 6.8.5 The Approved Amendment will be deemed not to have amended this Agreement during the pendency of the dispute resolution process. For avoidance of doubt, only Exemption Requests submitted by Registrar that are approved by ICANN pursuant to this Article 6 or through an arbitration decision pursuant to Section 5.8 shall exempt Registrar from any Approved Amendment, and no Exemption Request granted to any other Applicable Registrar (whether by ICANN or through arbitration), shall have any effect under this Agreement or exempt Registrar from any Approved Amendment. 6.9 Except asset forth in Section 4, Subsection 5.3, this Section 6, Section 7.4 and as otherwise set forth in this Agreement and the Specifications hereto, no amendment, supplement or modification of this Agreement or any provision hereof shall be binding unless executed in writing by both parties, and nothing in this Section 6 or Section 7.4 shall restrict ICANN and Registrar from entering into bilateral amendments and modifications to this Agreement negotiated solely between the two parties. No waiver of any provision of this Agreementshall be binding unless evidenced by a writing signed by the party waiving compliance with such provision. No waiver of any of the provisions of this Agreement or failure to

enforce any of the provisions hereof shall be deemed or shall constitute a waiver of any other provision hereof, nor shall any such waiver constitute a continuing waiver unless otherwise expressly provided. For the avoidance of doubt, nothing in this Section 6 or Section 7.4 shall be deemed to limit Registrar’s obligation to comply with Section 4. 6.10 Notwithstanding anything in this Section 6 to the contrary, (a) if Registrar provides evidence to ICANN’s reasonable satisfaction that the Approved Amendment would materially increase the cost of providing Registrar Services, then ICANN will allow up to one-hundred eighty (180) calendar days for the Approved Amendment to become effective with respect to Registrar, and (b) no Approved Amendment adopted pursuant to Section 6 shall become effective with respect to Registrar if Registrar provides ICANN with an irrevocable notice of termination pursuant to Section 5.4. 7. MISCELLANEOUS PROVISIONS. 7.1 Specific Performance. While this Agreement is in effect, either party may seek specific performance of any provision of this Agreement in the manner provided in Section 5.8, provided the party seeking such performance is not in material breach of its obligations. 7.2 Handling by ICANN of Registrar-Supplied Data. Before receiving any Personal Data from Registrar, ICANN shall specify to Registrar in writing the purposes for and conditions under which ICANN intends to use the Personal Data. ICANN may from time to time provide Registrar with a revised specification of such purposes and conditions, which specificationshall become effective no fewer than thirty (30) days after it is provided to Registrar. ICANN shall not use Personal Data provided by Registrar for a purpose or under conditions inconsistent with the specification in effect when the Personal Data was provided. ICANN shall take reasonable steps to avoid uses of the Personal Data by third parties inconsistent with the specification. 7.3 Assignment; Change of Ownership or Management. 7.3.1 Except asset forth in this Section 7.3.1, either party may assign or transfer this Agreement only with the prior written consent of the other party, which shall not be unreasonably withheld. If ICANN fails to expressly provide or withhold its consent to any requested assignment (an “Assignment Request”) of this Agreement by Registrar within thirty (30) calendar days of ICANN’s receipt of notice of such Assignment Request (or, if ICANN has requested additional information from Registrar in connection with its review of such request, sixty (60) calendar days of the receipt of all requested written information regarding such request) from Registrar, ICANN shall be deemed to have consented to such requested assignment. Notwithstanding the foregoing, (i) ICANN may assign this Agreement without the consent of Registrar upon approval of the ICANN Board of Directors in conjunction with

areorganization, reconstitution or re-incorporation of ICANN upon such assignee’s express assumption of the terms and conditions of this Agreement, (ii) Registrar may assign this Agreement without the consent of ICANN to a wholly-owned subsidiary of Registrar upon such subsidiary’s express assumption of the terms and conditions of this Agreement, and (iii) ICANN shall be deemed to have consented to an Assignment Request in which the assignee associated with such Assignment Request is a party to a Registrar Accreditation Agreement with ICANN on the terms set forth in this Agreement (provided that such assignee is then in compliance with the terms and conditions of such Registrar Accreditation Agreement in all material respects), unless ICANN provides to Registrar a written objection to such Assignment Request within ten (10) calendar days of ICANN’s receipt of notice of such Assignment Request pursuant to this Section 7.3.1. 7.3.2 To the extent that an entity acquires a Controlling interest in Registrar’s stock, assets or business, Registrarshall provide ICANN notice within seven (7) days of such an acquisition. Such notificationshall include a statement that affirms that Registrar meets the Specification or Policy on Accreditation criteria then in effect, and is in compliance with its obligations under this Agreement. Within thirty (30) days of such notification, ICANN may request additional information from the Registrar establishing compliance with this Agreement, in which case Registrar must supply the requested information within fifteen (15) days. Any disputes concerning Registrar's continued Accreditation shall be resolved pursuant to Section 5.8. 7.4 Negotiation Process. 7.4.1 If either the Chief Executive Officer of ICANN (“CEO”) or the Chairperson of the Registrar Stakeholder Group (“Chair”) desires to discuss any revision(s) to this Agreement, the CEO or Chair, as applicable, shall provide written notice to the other person, which shall set forth in reasonable detail the proposed revisions to this Agreement (a “Negotiation Notice”). Notwithstanding the foregoing, neither the CEO nor the Chair may (i) propose revisions to this Agreement that modify any Consensus Policy then existing, (ii) propose revisions to this Agreement pursuant to this Section 7.4 on or before June 30, 2014, or (iii) propose revisions or submit a Negotiation Notice more than once during any twelve month period beginning on July 1, 2014. 7.4.2 Following receipt of the Negotiation Notice by either the CEO or the Chair, ICANN and the Working Groupshall consult in good faith negotiations regarding the form and substance of the proposed revisions to this Agreement, which shall be in the form of a proposed amendment to this Agreement (the “Proposed Revisions”), for a period of at least ninety (90) calendar days (unless a resolution is earlier reached) and attempt to reach a mutually acceptable agreement relating to the Proposed Revisions (the “Discussion Period”).

7.4.3 If, following the conclusion of the Discussion Period, an agreement is reached on the Proposed Revisions, ICANN shall post the mutually agreed Proposed Revisions on its website for public comment for no less than thirty (30) calendar days (the “Posting Period”) and provide notice of such revisions to all Applicable Registrars in accordance with Section 7.6. ICANN and the Working Group will consider the public comments submitted on the Proposed Revisions during the Posting Period (including comments submitted by the Applicable Registrars). Following the conclusion of the Posting Period, the Proposed Revisions shall be submitted for Registrar Approval and approval by the ICANN Board of Directors. If such approvals are obtained, the Proposed Revisions shall be deemed an Approved Amendment by the Applicable Registrars and ICANN, and shall be effective and deemed an amendment to this Agreement upon sixty (60) calendar days notice from ICANN to Registrar. 7.4.4 If, following the conclusion of the Discussion Period, an agreement is not reached between ICANN and the Working Group on the Proposed Revisions, either the CEO or the Chair may provide the other person written notice (the “Mediation Notice”) requiring each party to attempt to resolve the disagreements related to the Proposed Revisions through impartial, facilitative (non-evaluative) mediation in accordance with the terms and conditions set forth below. In the event that a Mediation Notice is provided, ICANN and the Working Groupshall, within fifteen (15) calendar days thereof, simultaneously post the text of their desired version of the Proposed Revisions and a position paper with respect thereto on ICANN’swebsite. 7.4.4.1 The mediation shall be conducted by a single mediator selected by the parties. If the parties cannot agree on a mediator within fifteen (15) calendar days following receipt by the CEO or Chair, as applicable, of the Mediation Notice, the parties will promptly select a mutually acceptable mediation provider entity, which entity shall, as soon as practicable following such entity’sselection, designate a mediator, who is a licensed attorney with general knowledge of contract law and, to the extent necessary to mediate the particular dispute, general knowledge of the domain name system. Any mediator must confirm in writing that he or she is not, and will not become during the term of the mediation, an employee, partner, executive officer, director, or security holder of ICANN or an Applicable Registrar. If such confirmation is not provided by the appointed mediator, then a replacement mediatorshall be appointed pursuant to this Section 7.4.4.1. 7.4.4.2 The mediatorshall conduct the mediation in accordance with the rules and procedures for facilitative mediation that he or she determines following consultation with the parties. The parties shall

discuss the dispute in good faith and attempt, with the mediator’s assistance, to reach an amicable resolution of the dispute. 7.4.4.3 Each party shall bear its own costs in the mediation. The parties shall share equally the fees and expenses of the mediator. 7.4.4.4 If an agreement is reached during the mediation, ICANN shall post the mutually agreed Proposed Revisions on its website for the Posting Period and provide notice to all Applicable Registrars in accordance with Section 7.6. ICANN and the Working Group will consider the public comments submitted on the agreed Proposed Revisions during the Posting Period (including comments submitted by the Applicable Registrars). Following the conclusion of the Posting Period, the Proposed Revisions shall be submitted for Registrar Approval and approval by the ICANN Board of Directors. If such approvals are obtained, the Proposed Revisions shall be deemed an Approved Amendment by the Applicable Registrars and ICANN, and shall be effective and deemed an amendment to this Agreement upon sixty (60) days notice from ICANN to Registrar. 7.4.4.5 If the parties have not resolved the dispute for any reason by the date that is ninety (90) calendar days following receipt by the CEO or Chair, as applicable, of the Mediation Notice, the mediation shall automatically terminate (unless extended by agreement of the parties). The mediatorshall deliver to the parties a definition of the issues that could be considered in future arbitration, if invoked. Those issues are subject to the limitations set forth in Section 7.4.5.2 below. 7.4.5 If, following mediation, ICANN and the Working Group have not reached an agreement on the Proposed Revisions, either the CEO or the Chair may provide the other person written notice (an “Arbitration Notice”) requiring ICANN and the Applicable Registry Operators to resolve the dispute through binding arbitration in accordance with the arbitration provisions of Section 5.8, subject to the requirements and limitations of this Section 7.4.5. 7.4.5.1 If an Arbitration Notice is sent, the mediator’sdefinition of issues, along with the Proposed Revisions (be those from ICANN, Registrars or both) shall be posted for public comment on ICANN’s website for a period of no less than thirty (30) calendar days. ICANN and the Working Group will consider the public comments submitted on the Proposed Revisions during the Posting Period (including comments submitted by the Applicable Registrars),and information regarding such comments and considerationshall be provided to the a three (3) person arbitrator panel. Each party may modify is Proposed Revisions before and after the Posting Period. The arbitration

proceeding may not commence prior to the closing of such public comment period, and ICANN may consolidate all challenges brought by registrars (including Registrar) into asingle proceeding. Except as set forth in this Section 7.4.5.1, the arbitration shall be conducted pursuant to Section 5.8. 7.4.5.2 No dispute regarding the Proposed Revisions maybe submitted for arbitration to the extent the subject matter of the Proposed Revisions (i) relates to Consensus Policy, (ii) falls within the subject matter categories set forth in Section 1.2 of the Consensus Policies and Temporary Policies Specification , or (iii) seeks to amend any of the following provisions or Specifications of this Agreement: Sections 2, 4 and 6; subsections 3.1, 3.2, 3.3, 3.4, 3.5, 3.7, 3.8, 3.9, 3.14, 3.19, 3.21, 5.1, 5.2 or 5.3; and the Consensus Policies and Temporary Policies Specification, Data Retention Specification, WHOIS Accuracy Program Specification, Registration Data Directory Service (WHOIS) Specification or the Additional Registrar Operation Specification. 7.4.5.3 The mediator will brief the arbitrator panel regarding ICANN and the Working Group’s respective proposals relating to the Proposed Revisions. 7.4.5.4 No amendment to this Agreement relating to the Proposed Revisions maybe submitted for arbitration by either the Working Group or ICANN,unless, in the case of the Working Group, the proposed amendment has received Registrar Approval and, in the case of ICANN, the proposed amendment has been approved by the ICANN Board of Directors. 7.4.5.5 In order for the arbitrator panel to approve either ICANN or the Working Group’s proposed amendment relating to the Proposed Revisions, the arbitrator panel must conclude that such proposed amendment is consistent with a balanced application of ICANN’s core values (as described in ICANN’s Bylaws) and reasonable in light of the balancing of the costs and benefits to the business interests of the Applicable Registrars and ICANN (as applicable), and the public benefit sought to be achieved by the Proposed Revisions asset forth in such amendment. If the arbitrator panel concludes that either ICANN or the Working Group’s proposed amendment relating to the Proposed Revisions meets the foregoing standard, such amendment shall be effective and deemed an amendment to this Agreement upon sixty (60) calendar days notice from ICANN to Registrar and deemed an Approved Amendment hereunder.

7.4.6 With respect to an Approved Amendment relating to an amendment proposed by ICANN, Registrar may apply in writing to ICANN for an exemption from such amendment pursuant to the provisions of Section 6.8. 7.4.7 Notwithstanding anything in this Section 7.4 to the contrary, (a) if Registrar provides evidence to ICANN’s reasonable satisfaction that the Approved Amendment would materially increase the cost of providing Registrar Services, then ICANN will allow up to one-hundred eighty (180) calendar days for the Approved Amendment to become effective with respect to Registrar, and (b) no Approved Amendment adopted pursuant to Section 7.4 shall become effective with respect to Registrar if Registrar provides ICANN with an irrevocable notice of termination pursuant to Section 5.4. 7.5 No Third-Party Beneficiaries. This Agreementshall not be construed to create any obligation by either ICANN or Registrar to any non-party to this Agreement, including any Registered Name Holder. 7.6 Notices and Designations. Except as provided in Section 4.4 and Section 6, all notices to be given under this Agreementshall be given in writing at the address of the appropriate party asset forth below, unless that party has given a notice of change of address in writing. Each party shall notify the other party within thirty (30) days of any change to its contact information. Any written notice required by this Agreementshall be deemed to have been properly given when delivered in person, when sent by electronic facsimile with receipt of confirmation of delivery, when scheduled for delivery by internationally recognized courier service, or when delivered by electronic means followed by an affirmative confirmation of receipt by the recipient’s facsimile machine or email server. For any notice of a new Specification or Policy established in accordance with this Agreement, Registrar shall be afforded a reasonable period of time after notice of the establishment of such Specification or Policy is e-mailed to Registrar and posted on the ICANN website in which to comply with that specification, policy or program, taking into account any urgency involved. Notices and designations by ICANN under this Agreementshall be effective when written notice ofthem is deemed given to Registrar. If to ICANN, addressed to: Attention: Registrar Accreditation Notices Internet Corporation for Assigned Names and Numbers 12025 Waterfront Drive, Suite 300 Los Angeles, California 90094-2536 USA Telephone: +1 310 823-9358 Facsimile: +1 310 823-8649 If to Registrar, addressed to: [Registrar Name]

[Courier Address] [Mailing Address] Attention: [contact person] Registrar Website URL: [URL] Telephone: [telephone number] Facsimile: [fax number] e-mail: [e-mail address] 7.7 Dates and Times. All dates and times relevant to this Agreement or its performanceshall be computed based on the date and time observed in Los Angeles, California, USA. 7.8 Language. All notices, designations, and Specifications or Policies made under this Agreementshall be in the English language. 7.9 Counterparts. This Agreement maybe executed in one or more counterparts, each of which shall be deemed an original, but all of which together shall constitute one and the same instrument. 7.10 Entire Agreement. Except to the extent (a) expressly provided in a written agreement executed by both parties concurrently herewith or (b) of written assurances provided by Registrar to ICANN in connection with its Accreditation, this Agreement (including the specifications, which form part of it) constitutes the entire agreement of the parties pertaining to the Accreditation of Registrar and supersedes all prior agreements, understandings, negotiations and discussions, whether oral or written, between the parties on that subject. 7.11 Severability. If one or more provisions of this Agreement are held to be unenforceable under applicable law, the parties agree to renegotiate such provision in good faith. In the event that the parties cannot reach a mutually agreeable and enforceable replacement for such provision, then (a) such provisionshall be excluded from this Agreement; (b) the balance of this Agreementshall be interpreted as if such provision were so excluded; and (c) the balance of this Agreementshall be enforceable in accordance with its terms. [signature page follows]

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

ICANN

By: Name: Title:

[Registrar]

By: Name: Title:

WHOIS ACCURACY PROGRAM SPECIFICATION

Registrarshall implement and comply with the requirements set forth in this Specification, as well as any commercially practical updates to this Specification that are developed by ICANN and the Registrar Stakeholder Group during the Term of the Registrar Accreditation Agreement.

1. Except as provided for in Section 3 below, within fifteen (15) days of (1) the registration of a Registered Name sponsored by Registrar, (2) the transfer of the sponsorship of a Registered Name to Registrar, or (3) any change in the Registered Name Holder with respect to any Registered Name sponsored by Registrar, Registrar will, with respect to both Whois information and the corresponding customer account holder contact information related to such Registered Name: a. Validate the presence of data for all fields required under Subsection 3.3.1 of the Agreement in a proper format for the applicable country or territory. b. Validate that all email addresses are in the proper format according to RFC 5322 (or its successors). c. Validate that telephone numbers are in the proper format according to the ITU-T E.164 notation for international telephone numbers (or its equivalents or successors). d. Validate that postal addresses are in a proper format for the applicable country or territory as defined in UPU Postal addressing format templates, the S42 address templates (as they maybe updated) or other standard formats. e. Validate that all postal address fields are consistent across fields (for example: street exists in city, city exists in state/province, city matches postal code) where such information is technically and commercially feasible for the applicable country or territory. f. Verify: i. the email address of the Registered Name Holder (and, if different, the Account Holder) by sending an email requiring an affirmative response through a tool-based authentication method such as providing a unique code that must be returned in a manner designated by the Registrar, or ii.the telephone number of the Registered Name Holder (and, if different, the Account Holder) by either (A) calling or sending an SMS to the Registered Name Holder’s telephone number providing a unique code that must be returned in a manner designated by the Registrar, or (B) calling the Registered Name Holder’s telephone number and requiring the Registered Name Holder to provide a unique code that was sent to the

Registered Name Holder via web, email or postal mail. In either case, if Registrar does not receive an affirmative response from the Registered Name Holder, Registrarshall either verify the applicable contact information manually or suspend the registration, until such time as Registrar has verified the applicable contact information. If Registrar does not receive an affirmative response from the Account Holder, Registrarshall verify the applicable contact information manually, but is not required to suspend any registration. 2. Except as provided in Section 3 below, within fifteen (15) calendar days after receiving any changes to contact information in Whois or the corresponding customer account contact information related to any Registered Name sponsored by Registrar (whether or not Registrar was previously required to perform the validation and verification requirements set forth in this Specification in respect of such Registered Name), Registrar will validate and, to the extent required by Section 1, verify the changed fields in the manner specified in Section 1 above. If Registrar does not receive an affirmative response from the Registered Name Holder providing the required verification, Registrarshall either verify the applicable contact information manually or suspend the registration, until such time as Registrar has verified the applicable contact information. If Registrar does not receive an affirmative response from the Account Holder, Registrar shall verify the applicable contact information manually, but is not required to suspend any registration. 3. Except asset forth in paragraph 4 below, Registrar is not required to perform the above validation and verification procedures in Section 1(a) through 1(f) above, if Registrar has already successfully completed the validation and verification procedures on the identical contact information and is not in possession of facts or knowledge of circumstances that suggest that the information is no longer valid. 4. If Registrar has any information suggesting that the contact information specified in Section 1(a) through 1(f) above is incorrect (such as Registrar receiving a bounced email notification or non-delivery notification message in connection with compliance with ICANN’s Whois Data Reminder Policy or otherwise) for any Registered Name sponsored by Registrar (whether or not Registrar was previously required to perform the validation and verification requirements set forth in this Specification in respect of such Registered Name), Registrar must verify or re-verify, as applicable, the email address(es) as described in Section 1.f (for example by requiring an affirmative response to a Whois Data Reminder Policy notice). If, within fifteen (15) calendar days after receiving any such information, Registrar does not receive an affirmative response from the Registered Name Holder providing the required verification, Registrarshall either verify the applicable contact information manually or suspend the registration, until such time as Registrar has verified the applicable contact information. If, within fifteen (15) calendar days after receiving any such information, Registrar does not receive an affirmative response from the customer paying for the Registered Name, if applicable, providing the required verification, Registrarshall verify the applicable

contact information manually, but is not required to suspend any registration. 5. Upon the occurrence of a Registered Name Holder's willful provision of inaccurate or unreliable WHOIS information, its willful failure promptly to update information provided to Registrar, or its failure to respond for over fifteen (15) calendar days to inquiries by Registrar concerning the accuracy of contact details associated with the Registered Name Holder's registration, Registrarshall either terminate or suspend the Registered Name Holder’s Registered Name or place such registration on clientHold and clientTransferProhibited, until such time as Registrar has validated the information provided by the Registered Name Holder. 6. The terms and conditions of this Specificationshall be reviewed by ICANN in consultation with the Registrar Stakeholder Group on or about the first anniversaryof the date that the form of this Agreement is first executed by a registrar. 7. Nothing within this Specificationshall be deemed to require Registrar to perform verification or validation of any customer account holder information where the customer account holder does not have any Registered Names under sponsorship of Registrar.

WHOIS ACCURACY PROGRAM SPECIFICATION

Registrarshall implement and comply with the requirements set forth in this Specification, as well as any commercially practical updates to this Specification that are developed by ICANN and the Registrar Stakeholder Group during the Term of the Registrar Accreditation Agreement.

1. Except as provided for in Section 3 below, within fifteen (15) days of (1) the registration of a Registered Name sponsored by Registrar, (2) the transfer of the sponsorship of a Registered Name to Registrar, or (3) any change in the Registered Name Holder with respect to any Registered Name sponsored by Registrar, Registrar will, with respect to both Whois information and the corresponding customer account holder contact information related to such Registered Name: a. Validate the presence of data for all fields required under Subsection 3.3.1 of the Agreement in a proper format for the applicable country or territory. b. Validate that all email addresses are in the proper format according to RFC 5322 (or its successors). c. Validate that telephone numbers are in the proper format according to the ITU-T E.164 notation for international telephone numbers (or its equivalents or successors). d. Validate that postal addresses are in a proper format for the applicable country or territory as defined in UPU Postal addressing format templates, the S42 address templates (as they maybe updated) or other standard formats. e. Validate that all postal address fields are consistent across fields (for example: street exists in city, city exists in state/province, city matches postal code) where such information is technically and commercially feasible for the applicable country or territory. f. Verify: i. the email address of the Registered Name Holder (and, if different, the Account Holder) by sending an email requiring an affirmative response through a tool-based authentication method such as providing a unique code that must be returned in a manner designated by the Registrar, or ii.the telephone number of the Registered Name Holder (and, if different, the Account Holder) by either (A) calling or sending an SMS to the Registered Name Holder’s telephone number providing a unique code that must be returned in a manner designated by the Registrar, or (B) calling the Registered Name Holder’s telephone number and requiring the Registered Name Holder to provide a unique code that was sent to the

Registered Name Holder via web, email or postal mail. In either case, if Registrar does not receive an affirmative response from the Registered Name Holder, Registrarshall either verify the applicable contact information manually or suspend the registration, until such time as Registrar has verified the applicable contact information. If Registrar does not receive an affirmative response from the Account Holder), Registrarshall verify the applicable contact information manually, but is not required to suspend any registration. 2. Except as provided in Section 3 below, within fifteen (15) calendar days after receiving any changes to contact information in Whois or the corresponding customer account contact information related to any Registered Name sponsored by Registrar (whether or not Registrar was previously required to perform the validation and verification requirements set forth in this Specification in respect of such Registered Name), Registrar will validate and, to the extent required by Section 1, verify the changed fields in the manner specified in Section 1 above. If Registrar does not receive an affirmative response from the Registered Name Holder providing the required verification, Registrarshall either verify the applicable contact information manually or suspend the registration, until such time as Registrar has verified the applicable contact information. If Registrar does not receive an affirmative response from the Account Holder, Registrar shall verify the applicable contact information manually, but is not required to suspend any registration. 3. Except asset forth in paragraph 4 below, Registrar is not required to perform the above validation and verification procedures in Section 1(a) through 1(f) above, if Registrar has already successfully completed the validation and verification procedures on the identical contact information and is not in possession of facts or knowledge of circumstances that suggest that the information is no longer valid. 4. If Registrar has any information suggesting that the contact information specified in Section 1(a) through 1(f) above is incorrect (such as Registrar receiving a bounced email notification or non-delivery notification message in connection with compliance with ICANN’s Whois Data Reminder Policy or otherwise) for any Registered Name sponsored by Registrar (whether or not Registrar was previously required to perform the validation and verification requirements set forth in this Specification in respect of such Registered Name), Registrar must verify or re-verify, as applicable, the email address(es) as described in Section 1.f (for example by requiring an affirmative response to a Whois Data Reminder Policy notice). If, within fifteen (15) calendar days after receiving any such information, Registrar does not receive an affirmative response from the Registered Name Holder providing the required verification, Registrarshall either verify the applicable contact information manually or suspend the registration, until such time as Registrar has verified the applicable contact information. If, within fifteen (15) calendar days after receiving any such information, Registrar does not receive an affirmative response from the customer paying for the Registered Name, if applicable, providing the required verification, Registrarshall verify the applicable

contact information manually, but is not required to suspend any registration. 5. Upon the occurrence of a Registered Name Holder's willful provision of inaccurate or unreliable WHOIS information, its willful failure promptly to update information provided to Registrar, or its failure to respond for over fifteen (15) calendar days to inquiries by Registrar concerning the accuracy of contact details associated with the Registered Name Holder's registration, Registrarshall either terminate or suspend the Registered Name Holder’s Registered Name or place such registration on clientHold and clientTransferProhibited, until such time as Registrar has validated the information provided by the Registered Name Holder. 6. The terms and conditions of this Specificationshall be reviewed by ICANN in consultation with the Registrar Stakeholder Group on or about the first anniversary of the date that the form of this Agreement is first executed by a registrar. 7. Nothing within this Specificationshall be deemed to require Registrar to perform verification or validation of any customer account holder information where the customer account holder does not have any Registered Names under sponsorship of Registrar.

REGISTRATION DATA DIRECTORY SERVICE (WHOIS) SPECIFICATION

1. Registration Data Directory Services. Until ICANN requires a different protocol, Registrar will operate a WHOIS service available via port 43 in accordance with RFC 3912, and a web-based Directory Service providing free public query-based access to at least the elements set forth in Section 3.3.1.1 through 3.3.1.8 of the Registrar Accreditation Agreement in the format set forth in Section 1.4 of this Specification. ICANN reserves the right to specify alternative formats and protocols, and upon such specification, the Registrarwill implement such alternative specification as soon as reasonably practicable. Following the publication by the IETF of a Proposed Standard, Draft Standard or Internet Standard and any revisions thereto (as specified in RFC 2026) relating to the web-based directory service as specified in the IETF Web Extensible Internet Registration Data Service working group, Registrarshall implement the directory service specified in any such standard (or any revision thereto) no later than 135 days after such implementation is requested by ICANN. Registrar shall implement internationalized registration data publication guidelines according to the specification published by ICANN following the work of the ICANN Internationalized Registration Data Working Group (IRD-WG) and its subsequent efforts, no later than 135 days after it is approved by the ICANN Board.

1.1. The format of responses shall follow a semi-free text format outline below, followed by ablank line and a legal disclaimer specifying the rights of Registrar, and of the user querying the database. 1.2. Each data objectshall be represented as a set of key/value pairs, with lines beginning with keys, followed by a colon and a space as delimiters, followed by the value. 1.3. For fields where more than one value exists, multiple numbered key/value pairs with the same keyshall be allowed (for example to list multiple name servers). The first key/value pair after a blank line should be considered the start of a new record, and should be considered as identifying that record, and is used to group data, such as hostnames and IP addresses, or a domain name and registrant information, together. 1.4.Domain Name Data: 1.4.1. Query format: whois –h whois.example-registrar.tld EXAMPLE.TLD 1.4.2. Response format: The format of responses shall contain all the elements and follow a semi-free text format outline below. Additional data elements can be added at the end of the text

format outlined below. The data element may, at the option of Registrar, be followed by a blank line and a legal disclaimer specifying the rights of Registrar, and of the user querying the database (provided that any such legal disclaimer must be preceded by such blank line). Domain Name: EXAMPLE.TLD Registry Domain ID: D1234567-TLD Registrar WHOIS Server: whois.example-registrar.tld Registrar URL:http://www.example-registrar.tld Updated Date: 2009-05-29T20:13:00Z Creation Date: 2000-10-08T00:45:00Z Registrar Registration Expiration Date: 2010-10-08T00:44:59Z Registrar: EXAMPLE REGISTRAR LLC Registrar IANA ID: 5555555 Registrar Abuse Contact Email:email@registrar.tld Registrar Abuse Contact Phone:+1.1235551234 Reseller: EXAMPLE RESELLER1 Domain Status: clientDeleteProhibited2 Domain Status: clientRenewProhibited Domain Status: clientTransferProhibited Registry Registrant ID: 5372808-ERL3 Registrant Name: EXAMPLE REGISTRANT4 Registrant Organization: EXAMPLE ORGANIZATION Registrant Street: 123 EXAMPLE STREET Registrant City: ANYTOWN Registrant State/Province: AP5 Registrant Postal Code: A1A1A16 Registrant Country: AA Registrant Phone: +1.5555551212 Registrant Phone Ext: 12347 Registrant Fax: +1.5555551213 Registrant Fax Ext: 4321 Registrant Email:EMAIL@EXAMPLE.TLD Registry Admin ID: 5372809-ERL8

1 Data element maybe deleted, provided that if the data element is used, it must appear at this location. 2 Note: all applicable statuses must be displayed in the Whois output. 3 Maybe left blank if not available from Registry. 4 For the Registrant, Admin and Tech contact fields requiring a “Name” or “Organization”, the output must include either the name or organization (or both, if available). 5 All “State/Province” fields maybe left blank if not available. 6 All “Postal Code” fields maybe left blank if not available. 7 All “Phone Ext”, “Fax” and “Fax Ext” fields maybe left blank if not available. 8 Maybe left blank if not available from Registry.

Admin Name: EXAMPLE REGISTRANT ADMINISTRATIVE Admin Organization: EXAMPLE REGISTRANT ORGANIZATION Admin Street: 123 EXAMPLE STREET Admin City: ANYTOWN Admin State/Province: AP Admin Postal Code: A1A1A1 Admin Country: AA Admin Phone: +1.5555551212 Admin Phone Ext: 1234 Admin Fax: +1.5555551213 Admin Fax Ext: 1234 Admin Email:EMAIL@EXAMPLE.TLD Registry Tech ID: 5372811-ERL9 Tech Name: EXAMPLE REGISTRANT TECHNICAL Tech Organization: EXAMPLE REGISTRANT LLC Tech Street: 123 EXAMPLE STREET Tech City: ANYTOWN Tech State/Province: AP Tech Postal Code: A1A1A1 Tech Country: AA Tech Phone: +1.1235551234 Tech Phone Ext: 1234 Tech Fax: +1.5555551213 Tech Fax Ext: 93 Tech Email:EMAIL@EXAMPLE.TLD Name Server: NS01.EXAMPLE-REGISTRAR.TLD10 Name Server: NS02.EXAMPLE-REGISTRAR.TLD DNSSEC: signedDelegation URL of the ICANN WHOIS Data Problem Reporting System: http://wdprs.internic.net/

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

1.5. The format of the following data fields: domain status, individual and organizational names, address, street, city, state/province, postal code, country, telephone and fax numbers, email addresses, date and times must conform to the mappings specified in EPP RFCs 5730-5734 (or its successors),and IPv6 addresses format should conform to RFC 5952 (or its successor), so that the display of this information (or values returned in WHOIS responses) can be uniformly processed and understood. 2. Service Level Agreement for Registration Data Directory Services (RDDS) 2.1 Definitions

9 Maybe left blank if not available from Registry. 10 All associated nameservers must be listed.

o IP address. Refers to IPv4 or IPv6 addresses without making any distinction between the two. When there is need to make a distinction, IPv4 or IPv6 is used. o Probes. Network hosts used to perform tests (see below) that are located at various global locations. o RDDS. Registration Data Directory Services refers to the collective of WHOIS and Web based WHOIS services. o RTT. Round-Trip Time or RTT refers to the time measured from the sending of the first bit of the first packet of the sequence of packets needed to make a request until the reception of the last bit of the last packet of the sequence needed to receive the response. If the client does not receive the whole sequence of packets needed to consider the response as received, the request will be considered unanswered. o SLR. Service Level Requirement is the level of service expected for a certain parameter being measured in a Service Level Agreement (SLA). 2.2 Service Level Agreement Matrix

Parameter SLR (monthly basis)

RDDS RDDS availability less than or equal to 864 min of downtime RDDS query RTT less than or equal to 4000 ms, for at least 95% of the queries RDDS update time less than or equal to 60 min, for at least 95% of the probes

Registrar is encouraged to do maintenance for the different services at the times and dates of statistically lower traffic for each service. Since substantial downtime is already incorporated in the availability metric, planned outages or similar; any downtime, be it for maintenance or due to system failures, will be noted simply as downtime and counted for SLA purposes. 2.2.1 RDDS availability. Refers to the ability of all the RDDS services for the Registrar to respond to queries from an Internet user with appropriate data from the relevant registrar system. If 51% or more of the RDDS testing probes see any of the RDDS services as unavailable during a given time, the RDDS will be considered unavailable. 2.2.2 WHOIS query RTT. Refers tothe RTT of the sequence of packets from the start of the TCP connection to its end, including the reception of the WHOIS response. If the RTT is 5-times or more the corresponding SLR, the RTTwill be considered undefined. 2.2.3 Web-based-WHOIS query RTT. Refers tothe RTT of the sequence of packets from the start of the TCP connection to its end, including the

reception of the HTTP response for only one HTTP request. If Registrar implements a multiple-step process to get to the information, only the last stepshall be measured. If the RTT is 5-times or more the corresponding SLR, the RTT will be considered undefined. 2.2.4 RDDS query RTT. Refers to the collective of “WHOIS query RTT” and “Web-based- WHOIS query RTT”. 2.2.5 RDDS update time. Refers to the time measured from the receipt of an EPP confirmation to a transform command on a domain name, host or contact, up until the servers of the RDDS services reflect the changes made. 2.2.6 RDDS test. Means one query sent to a particular “ IP address” of one of the servers of one of the RDDS services. Queries shall be about existing objects in the registrar system and the responses must contain the corresponding information otherwise the query will be considered unanswered. Queries with an RTT 5 times higher than the corresponding SLR will be considered as unanswered. The possible results to an RDDS test are: anumber in milliseconds corresponding to the RTT orundefined/unanswered. 2.2.7 Measuring RDDS parameters. Every 5 minutes, RDDS probes will select one IP address from all the public-DNS registered “IP addresses” of the servers for each RDDS service of the Registrar being monitored and make an “RDDS test” to each one. If an “RDDS test” result is undefined/unanswered, the corresponding RDDS service will be considered as unavailable from that probe until it is time to make a new test. 2.2.8 Collating the results from RDDS probes. The minimum number of active testing probes to consider a measurement valid is 10 at any given measurement period, otherwise the measurements will be discarded and will be considered inconclusive; during this situation no fault will be flagged against the SLRs. 2.2.9 Placement of RDDS probes. Probes for measuring RDDS parameters shall be placed inside the networks with the most users across the different geographic regions; care shall betaken not to deploy probes behind high propagation-delay links, such as satellite links. 2.3 Covenants of Performance Measurement Registrarshall not interfere with measurement Probes, including any form of preferential treatment of the requests for the monitored services. Registrarshall respond to the measurement tests described in this Specification as it would do with any other request from Internet users (for RDDS).

CONSENSUS POLICIES AND TEMPORARY POLICIES SPECIFICATION

1. Consensus Policies.

1.1. “Consensus Policies” are those policies established (1) pursuant to the procedure set forth in ICANN's Bylaws and due process, and (2) covering those topics listed in Section 1.2 of this document. The Consensus Policy development process and procedure set forth in ICANN's Bylaws maybe revised from time to time in accordance with the process set forth therein. 1.2. Consensus Policies and the procedures by which they are developed shall be designed to produce, to the extent possible, a consensus of Internet stakeholders, including registrars. Consensus Policies shall relate to one or more of the following: 1.2.1. issues for which uniform or coordinated resolution is reasonably necessary to facilitate interoperability, security and/or stability of the Internet, Registrar Services, Registry Services, or the Domain Name System (“DNS”); 1.2.2. functional and performance specifications for the provision of Registrar Services; 1.2.3. registrar policies reasonably necessary to implement Consensus Policies relating to agTLD registry; 1.2.4. resolution of disputes regarding the registration of domain names (as opposed to the use of such domain names, but including where such policies take into account use of the domain names); or 1.2.5. restrictions on cross-ownership of registry operators and registrars or Resellers and regulations and restrictions with respect to registrar and registry operations and the use of registry and registrar data in the event that a registry operator and a registrar or Reseller are affiliated. 1.3. Such categories of issues referred to in Section 1.2 shall include, withoutlimitation: 1.3.1. principles for allocation of registered names in a TLD (e.g., first-come/first-served, timely renewal, holding period after expiration); 1.3.2. prohibitions on warehousing of or speculation in domain names by registries or registrars; 1.3.3. reservation of registered names in a TLD that may not be registered initially or that may not be renewed due to reasons reasonably related to (i) avoidance of confusion among or misleading of users, (ii) intellectual property, or (iii) the technical management of the DNS or the Internet (e.g., establishment of reservations of names from registration); 1.3.4. maintenance of and access to accurate and up-to-date information concerning Registered Names and nameservers; 1.3.5. procedures to avoid disruptions of domain name registrations due to suspension or termination of operations by a registry operator or a registrar, including procedures for allocation of responsibility among continuing registrars of the Registered Names sponsored in a TLD by a registrar losing accreditation; and 1.3.6. the transfer of registration data upon a change in registrar sponsoring one or more Registered Names.

1.4. In addition to the other limitations on Consensus Policies, they shall not: 1.4.1. prescribe or limit the price of Registrar Services; 1.4.2. modify the limitations on Temporary Policies (defined below) or Consensus Policies; 1.4.3. modify the provisions in the Registrar Accreditation Agreement regarding terms or conditions for the renewal, termination or amendment of the Registrar Accreditation Agreement or fees paid by Registrar to ICANN; or 1.4.4. modify ICANN’s obligations to not apply standards, policies, procedures or practices arbitrarily, unjustifiably, or inequitably and to not single out Registrar for disparate treatment unless justified by substantial and reasonable cause, and exercise its responsibilities in an open and transparent manner. 2. Temporary Policies. Registrarshall comply with and implement all specifications or policies established by the ICANN Board of Directors (the “Board”) on a temporary basis, if adopted by the Board by a vote of at least two-thirds of its members, so long as the Board reasonably determines that such modifications or amendments are justified and that immediate temporary establishment of a specification or policy on the subject is necessary to maintain the stability or security of Registrar Services, Registry Services or the DNS or the Internet ("Temporary Policies"). 2.1. Such proposed specification or policy shall be as narrowly tailored as feasible to achieve those objectives. In establishing any Temporary Policy, the Boardshall state the period of time for which the Temporary Policy is adopted and shall immediately implement the Consensus Policy development process set forth in ICANN's Bylaws. 2.1.1. ICANN shall also issue an advisory statement containing a detailed explanation of its reasons for adopting the Temporary Policy and why the Board believes such Temporary Policy should receive the consensus support of Internet stakeholders. 2.1.2. If the period of time for which the Temporary Policy is adopted exceeds 90 days, the Board shall reaffirm its temporary adoption every 90 days for a total period not to exceed one year,in order to maintain such Temporary Policy in effect until such time as it becomes a Consensus Policy. If the one year period expires or, if during such one year period, the Temporary Policy does not become a Consensus Policy and is not reaffirmed by the Board, Registrarshall no longer be required to comply with or implement such Temporary Policy.

3. Notice and Conflicts. Registrarshall be afforded a reasonable period of time following notice of the establishment of a Consensus Policy or Temporary Policy in which to comply with such policy or specification, taking into account any urgency involved. In the event of a conflict between Registrar Services and Consensus Policies or any Temporary Policy, the Consensus Polices or Temporary Policy shall control, but only with respect to subject matter in conflict. For the avoidance of doubt, Consensus Policies that meet the requirements of this Specification may supplement or supersede provisions of the agreements between Registrar and ICANN, but only to the extent that such Consensus Policies relate to the matters set forth in Section 1.2 and

1.3 of this Specification.

SPECIFICATION ON PRIVACY AND PROXY REGISTRATIONS Until the earlier to occur of (i) January 1, 2017, and (ii) the date ICANN establishes and implements a Privacy and Proxy Accreditation Program as referenced in Section 3.14 of the Registrar Accreditation Agreement, Registrar agrees to comply, and to require its Affiliates and Resellers to comply, with the terms of this Specification, provided that ICANN and the Working Group may mutually agree to extend the term of this Specification. This Specification may not be modified by ICANN orRegistrar.

1. Definitions. For the purposes of this Specification, the following definitions shall apply.

1.1 “P/P Customer” means, regardless of the terminology used by the P/P Provider, the licensee, customer, beneficial user, beneficiary, or other recipient of Privacy Services and Proxy Services. 1.2 “Privacy Service” is a service by which a Registered Name is registered to its beneficial user as the Registered Name Holder, but for which alternative, reliable contact information is provided by the P/P Provider for display of the Registered Name Holder’s contact information in the Registration Data Service (Whois) or equivalent services. 1.3 ”Proxy Service” is a service through which a Registered Name Holder licenses use of a Registered Name to the P/P Customer in order to provide the P/P Customer use of the domain name, and the Registered Name Holder's contact information is displayed in the Registration Data Service (Whois) or equivalent services rather than the P/P Customer’s contact information. 1.4 “P/P Provider” or “Service Provider” is the provider ofPrivacy/Proxy Services,including Registrar and its Affiliates, as applicable. 2. Obligations of Registrar. For any Proxy Service or Privacy Service offered by the Registrar or its Affiliates, including any of Registrar's or its Affiliates’ P/P services distributed through Resellers, and used in connection with Registered Names Sponsored by the Registrar, the Registrar and its Affiliates must require all P/P Providers to follow the requirements described in this Specification and to abide by the terms and procedures published pursuant to this Specification. 2.1 Disclosure of Service Terms. P/P Providershall publish the terms and conditions of its service (including pricing), on its website and/or Registrar’swebsite.

2.2 Abuse/Infringement Point of Contact. P/P Providershall publish a point of contact for third parties wishing to report abuse or infringement of trademarks (or other rights). 2.3 Disclosure of Identity of P/P Provider. P/P Providershall publish its business contact information on its website and/or Registrar’swebsite. 2.4 Terms of service and description of procedures. The P/P Providershall publish on its website and/or Registrar’s website a copy of the P/P Provider service agreement and description of P/P Provider’s procedures for handling the following: 2.4.1 The processor facilities to report abuse of a domain name registration managed by the P/P Provider; 2.4.2 The processor facilities to report infringement of trademarks or other rights of third parties; 2.4.3 The circumstances under which the P/P Provider will relay communications from third parties to the P/P Customer; 2.4.4 The circumstances under which the P/P Provider will terminate service to the P/P Customer; 2.4.5 The circumstances under which the P/P Provider will reveal and/or publish in the Registration Data Service (Whois) or equivalent service the P/P Customer’sidentity and/orcontact data; and 2.4.6 A description of the support services offered by P/P Providers to P/P Customers, and how to access these services. 2.5 Escrow of P/P Customer Information. Registrarshall include P/P Customer contact information in its Registration Data Escrow deposits required by Section 3.6 of the Agreement. P/P Customer Information escrowed pursuant to this Section 2.5 of this Specification may only be accessed by ICANN in the event of the termination of the Agreement or in the event Registrar ceases business operations. 3. Exemptions. Registrar is under no obligation to comply with the requirements of this specification if it can be shown that: 3.1 Registered Name Holder employed the services of a P/P Provider that is not provided by Registrar, or any of its Affiliates;

3.2 Registered Name Holder licensed a Registered Name to another party (i.e., is acting as a Proxy Service) without Registrar’s knowledge; or 3.3 Registered Name Holder has used P/P Provider contact data without subscribing to the service or accepting the P/P Provider terms and conditions.

DATA RETENTION SPECIFICATION

1. During the Term of this Agreement, for each Registered Name sponsored by Registrar within agTLD, Registrarshall collect and securely maintain in its own electronic database (as updated from time to time) the data specifiedbelow:

1.1. Registrarshall collect the following information from registrants at the time of registration of a domain name (a “Registration”) and shall maintain that information for the duration of Registrar’s sponsorship of the Registration and for a period of two additional years thereafter: 1.1.1. First and lastname or full legal name of registrant; 1.1.2. First and lastname or, in the event registrant is a legal person, the title of the registrant’s administrative contact, technical contact, and billing contact; 1.1.3. Postal address of registrant, administrative contact, technical contact, and billing contact; 1.1.4. Email address of registrant, administrative contact, technical contact, and billing contact; 1.1.5. Telephone contact for registrant, administrative contact, technical contact, and billing contact; 1.1.6. WHOIS information, asset forth in the WHOIS Specification; 1.1.7. Types of domain name services purchased for use in connection with the Registration; and 1.1.8. To the extent collected by Registrar, “card on file,” current period third party transaction number, or other recurring payment data. 1.2. Registrarshall collect the following information and maintain that information for no less than one hundred and eighty (180) days following the relevant interaction: 1.2.1. Information regarding the means and source of payment reasonably necessary for the Registrar to process the Registration transaction, or a transaction number provided by a third party payment processor; 1.2.2. Log files, billing records and, to the extent collection and maintenance of such records is commercially practicable or consistent with industry-wide generally accepted standard practices within the industries in which Registrar operates, other

records containing communications source and destination information, including, depending on the method of transmission and without limitation: (1) Source IP address, HTTP headers, (2) the telephone, text, or fax number; and (3) email address, Skype handle,or instant messaging identifier, associated with communications between Registrar and the registrant about the Registration; and 1.2.3. Log files and, to the extent collection and maintenance of such records is commercially practicable or consistent with industry- wide generally accepted standard practices within the industries in which Registrar operates, other records associated with the Registration containing dates, times, and timezones of communications and sessions, including initialregistration. 2. If, based on the receipt of either (i) a written legal opinion from a nationally recognized law firmin the applicable jurisdiction that states that the collection and/or retention of any data element specified herein by Registrar is reasonably likely to violate applicable law (the “Opinion”) or (ii) a ruling of, or written guidance from, a governmental body of competent jurisdiction providing that compliance with the data collection and/or retention requirements of this Specification violates applicable law, Registrar determines in good faith that the collection and/or retention of any data element specified in this Specification violates applicable law, Registrar may provide written notice of such determination to ICANN and request a waiver from compliance with specific terms and conditions of this Specification (a “Waiver Request”). Such written noticeshall: (i) specify the relevant applicable law, the allegedly offending data collection and retention elements, the manner in which the collection and/or retention of such data violates applicable law, and a reasonable description of such determination and any other facts and circumstances related thereto, (ii) be accompanied by a copy of the Opinion and governmental ruling or guidance, as applicable, and (iii) be accompanied by any documentation received by Registrar from any governmental authority, in each case, related to such determination, and such other documentation reasonably requested by ICANN. Following receipt of such notice, ICANN and Registrarshall discuss the matter in good faith in an effort to reach a mutually acceptable resolution of the matter. Until such time as ICANN’s Procedure for Handling Whois Conflicts with Privacy Law is modified to include conflicts relating to the requirements of this Specification and if ICANN agrees with Registrar’s determination, ICANN's office of general counsel may temporarily or permanently suspend compliance and enforcement of the affected provisions of this Specification and grant the Waiver Request. Prior to granting any exemption hereunder, ICANN will post its determination on its website for a period of thirty (30) calendar days. Following such modification of ICANN’s Procedure for Handling Whois Conflicts with Privacy Law, all Waiver Requests (whether granted or denied) shall be resolved pursuant to such modified procedures.

3. If (i) ICANN has previously waived compliance with the requirements of any requirement of this Data Retention Specification in response to a Waiver Request from aregistrar that is located in the same jurisdiction as Registrar and (ii) Registrar is subject to the same applicable law that gave rise to ICANN’s agreement to grant such waiver, Registrar may request that ICANN to grant a similar waiver, which requestshall be approved by ICANN, unless ICANN provides Registrar with a reasonable justification for not approving such request, in which case Registrar may thereafter make an Waiver Request pursuant to Section 2 of this Data Retention Specification.
4. Any modification of this Data Retention Specification to address violations of applicable lawshall only apply during the period of time that the specific provisions of the applicable law giving rise to such violations remain in effect. If the applicable law is repealed or modified (or preempted) in a manner that would no longer prohibit the collection and/or retention of data andinformation as originally specified in this Data Retention Specification, Registrar agrees that the original version of this Specification will apply to the maximum extent permitted by such modified applicable law.

REGISTRAR INFORMATION SPECIFICATION Registrarshall provide to ICANN the information specified below, which shall be maintained in accordance with Section 3.17 of the Agreement. With regard to information identified below, ICANN will hold such information pursuant to the disclosure requirements set forth in Section 3.15 of the Agreement. General Information

1. Full legal name of Registrar.
2. Legal form of the Registrar (e.g., LLC, Corporation, Government Body, Intergovernmental Organization, etc.).
3. The jurisdiction in which the Registrar’s business is registered for legal and financial purposes.
4. The Registrar’s business registration number and the name of the authority that issued this number.
5. Every business name and/or trade name used by the Registrar.
6. Provide current documentation demonstrating that the Registrar entity is

   legally established and in good standing. For proof of establishment, provide charter documents or other equivalent document (e.g., membership agreement) of the entity. If the Registrar is a government body or organization, provide a certified copy of the relevant statute, governmental decision or other instrument under which the government body or organization has been established. With respect to an entity other than a government body or organization, where no such certificates or documents are available in the Registrar's jurisdiction, an affidavit drafted and signed by a notary public or a legal practitioner duly qualified in the courts of the Registrar's jurisdiction, declaring that the organization is established and in good standing, must be provided.

7. Correspondence address for the Registrar.* This address will be used for

   contractual purposes, and the Registrar must be able to accept notices and service of legal process at this address. No Post Office boxes are allowed.

8. Primary phone number where the Registrar can be reached for contractual purposes.
9. Primary Fax number where the Registrar can be reached for contractual purposes.

10. Primary Email address where the Registrar can be reached for contractual purposes.

11. If the location or address of Registrar’s principal place of business is different from the address provided in 7, provide details including address, phone number, fax number and email address.* Provide ICANN with current documentation demonstrating that the Registrar is legally entitled to do business in the principal place of business.

12. Any other addresses where the Registrar will be operated or managed, if different from either its principal place of business or correspondence address provided above. (If so, please explain.) Provide ICANN with current documentation demonstrating that the Registrar is legally entitled to do business in each location identified.

13. Primary contact name: Title Address Phone number Fax number Email address

14. URL and Location of Port 43 WHOIS server. Ownership, Directors and Officers Information

15. Full name, contact information, and position of any persons or entities owning at least 5% of the ownership interest in Registrar’s current business entity. For each person listed, please specify such person’s percentage ownership.

16. Full name, contact information, and position of all directors of the Registrar.

17. Full name, contact information, and position of all officers of the Registrar.* (Officer names and positions must be publicly displayed.)

18. Full name, contact information, and position of all senior management and other key personnel overseeing the provision of Registrar Services.

19. For every person or entity mentioned in the answers to questions 15 to 18, indicate if that person or entity: a) within the past ten years, has been convicted of a felony or of a misdemeanor related to financial activities, or has been judged by a court to have committed fraud or breach of fiduciary duty, or has been the subject of a judicial determination that is similar or related to any of these; b) within the past ten years, has been disciplined by any government or industry regulatory body for conduct involving dishonesty or misuse of funds of others;

c) is currently involved in any judicial or regulatory proceeding that could result in a conviction, judgment, determination, or discipline of the type specified in items 19(a) or 19(b); or d) is the subject of a disqualification imposed by ICANN. Provide details if any of the above events in (a)-(d) have occurred. 20. List all Affiliated Registrars, if any, and briefly describe the Affiliation. 21. For any entities listed in item 20, must provide information required in items 1-14 above. 22. List the ultimate parent entity of the Registrar, if applicable.* Other 23. Does the Registrar or any of its Affiliates offer any Privacy Service or Proxy Service (as such terms on defined in the Specification on Privacy and Proxy Registrations)? If yes, list the entities or individuals providing the Privacy Service or Proxy Service. 24. For any entities listed in item 23, provide information required in 1-14 above. 25. Does the Registrar utilize or benefit from the services of Resellers? 26. If yes, provide alist of all such Resellers known to Registrar. The information specified in this item 26 shall be made available to ICANN upon request. At such time as ICANN develops a secure method for the receipt and retention of such information, such information shall thereafter be provided to ICANN in accordance with Section 3.17 of the Agreement.

Items marked with “” must also be published on Registrar’swebsite.

ADDITIONAL REGISTRAR OPERATION SPECIFICATION

This Specification maybe modified by ICANN from time to time after consultation with the Registrar Stakeholder Group (or its successor), provided that such updates are commercially practical with respect to the registrar industry, taken as a whole.

1. DNSSEC

Registrar must allow its customers to use DNSSEC upon request by relaying orders to add, remove or change public key material (e.g., DNSKEY or DS resource records) on behalf of customers to the Registries that support DNSSEC. Such requests shall be accepted and processed in a secure manner and according to industry best practices. Registrars shall accept any public key algorithm and digest type that is supported by the TLD of interest and appears in the registries posted at: <http://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec- alg-numbers.xml> and <http://www.iana.org/assignments/ds-rr-types/ds-rr- types.xml>. All such requests shall be transmitted to registries using the EPP extensions specified in RFC 5910 or its successors.

2. IPv6

To the extent that Registrar offers registrants the ability to register nameserver addresses, Registrar must allow both IPv4 addresses and IPv6 addresses to be specified.

3. IDN

If the Registrar offers Internationalized Domain Name (“IDN”) registrations, all new registrations must comply with RFCs 5890, 5891, 5892, 5893 and their successors. Registrarshall also comply with the IDN Guidelines at http://www.icann.org/en/topics/idn/implementation-guidelines.htmwhich maybe amended, modified, or superseded from time to time. Registrar must use the IDN tables published by the relevant registry.

Registrants’ Benefits and Responsibilities

Domain Name Registrants’ Rights:

1. Your domain name registration and any privacy/proxy services you may use in conjunction with it must be subject to a Registration Agreement with an ICANN Accredited Registrar.

• You are entitled to review this Registration Agreement at anytime, and download a copy for your records.

2. You are entitled to accurate and accessible information about: • The identity of your ICANN Accredited Registrar; • The identity of any proxy or privacy service provider affiliated with your Registrar; • Your Registrar’s terms and conditions, including pricing information, applicable to domain name registrations; • The terms and conditions, including pricing information, applicable to any privacy services offered by your Registrar; • The customer support services offered by your Registrar and the privacy services provider, and how to access them; • How to raise concerns and resolve disputes with your Registrar and any privacy services offered by them; and • Instructions that explain your Registrar’s processes for registering, managing, transferring, renewing, and restoring your domain name registrations, including through any proxy or privacy services made available by your Registrar.

3. You shall not be subject to false advertising or deceptive practices by your Registrar or though any proxy or privacy services made available by your Registrar. This includes deceptive notices, hidden fees, and any practices that are illegal under the consumer protection law of your residence.

Domain Name Registrants’ Responsibilities:

1. You must comply with the terms and conditions posted by your Registrar, including applicable policies from your Registrar, the Registry and ICANN.

2. You must review your Registrar’s current Registration Agreement, along with any updates.

3. You will assume sole responsibility for the registration and use of your domain name.

4. You must provide accurate information for publication in directories such as WHOIS, and promptly update this to reflect any changes.

5. You must respond to inquiries from your Registrar within fifteen (15) days, and keep your Registrar account data current. If you choose to have your domain name registration renew automatically, you must also keep your payment information current.

本文引用ICANN文档 来源>> 2013 年 6 月 27 日

本注册商委任协议(以下简称“本协议”)由互联网名称与数字地址分配机构（ICANN）与贝锐签署，应视为在美国加州的洛杉矶签订。 1.定义。针对本协议，应适用以下定义：
1.1“账户持有人”是指为注册名称支付费用或以其他方式控制注册名称管理的 个人或实体，但该个人或实体不是注册名称持有人。
1.2“认可”或“认可”是指确定和设定履行注册职能的最低标准，认可符合这 些标准的个人或实体，并签订一份认可协议，规定适用于提供注册服务的规则和 程序。
1.3“关联公司”是指直接或间接通过一个或多个中介机构控制，受或与指定的 个人或实体共同控制的个人或实体。
1.4“附属注册商”是另一个认可注册商的附属注册商。
1.5“适用注册人家庭”是指，就附属注册人而言，该附属注册人作为一个团体。
1.6“共识政策”的含义具有本协议附件中的共识政策和临时政策规范中规 的含义。
1.7“控制”(包括术语“控制”和“共同控制”)是指拥有，直接或间接的权力直接或导致的方向管理或政策的个人或实体，是否通过证券的所有权，作为受托人或执行人，作为一个雇员或 通过合同担任董事会或同等管理机构的成员，通过信贷安排或其他方式。 1.8“DNS ”是指互联网域名系统。 .
1.9“gTLD ”或“gTLD ”是指ICANN根据完全有效的注册协议委托的DNS的顶级 域名，但任何国家代码TLD（ccTLD）或国际化域名（IDN）国家代码TLD除外。
1.10“gTLD区域-文件数据 ”是指注册表的DNS区域文件中包含的所有数据，或 提供注册表服务并包含注册名称的任何子域，如提供给互联网上的名称服务器。
1.11“非法活动 ”是指使用注册官赞助的注册名称和/或利用注册官的域名决议 或注册服务以促进使用注册官赞助的注册名称的行为。
1.12“个人资料 ”是指有关任何已识别或可识别的自然人的资料。
1.13“注册名称 ”是指一个域名的域名，是否包括两(2)或更多的（如john.smith.name）水平，关于gTLD注册表运营商（或其子公司或分包商从事提供 注册服务）维护注册数据库数据，安排这样的维护，或从维护中获得收入。注册 表数据库中的名称可以是已注册的名称，即使它没有出现在区域文件中（例如，已注册但不活动的名称）。
1.14“注册姓名持有人 ”是指拥有注册姓名的持有人。
1.15“注册商 ”一词在没有首字母大写字母时，是指与注册姓名持有人和注册表运营商签订合同，收集有关注册姓名持有人的登记数据并提交登记信息进入注册 表数据库的个人或实体。
1.16“注册商批准 ”是指收到下列任一项批准：
1.16.1适用注册机构占其管理的注册名称总数的90%的肯定批准；但为计算注册总数由适用注册家族成员管理的名称，每个适用注册家族成员管理的注册名 称总数不得超过第五大适用注册家族（由管理的注册家族成员管理的注 册名称总数），包括分子和分母；或250%的肯定批准加上参与流程的适用注册机构的批准。投票赞成或反对，但不弃权或以其他方式不投票)根据第6条提出的修正案，以及占所有适用注册机构管理的注册名称总数的66.67%的适用注册机构的肯定批准，但在计算适用注册机构管理的注册姓名总数时，每个适用注册机构家庭管 理的注册姓名总数不得超过第五大适用注册机构家庭管理的注册人数总数) , 包括分子和分母的目的。这些计算的一个示例见本文附录1。
1.17“注册商服务 ”是指注册商就gTLD提供的本协议规定的服务，包括与注册姓名持有人签订合同，收集注册姓名持有人的注册数据，以及提交注册数据库的注册信息。
1.18“注册数据 ”是指以电子形式保存的所有注册数据库数据，包括gTLD区域文件数据、用于提供注册服务和注册商提交的所有数据，以及用于提供注册服 务相关的注册服务的所有其他数据。
1.19“注册表数据库 ”是指数据库组成的数据关于一个或多个DNS域名的注册表, 用于生成DNS资源记录，发布权威或响应域名可用性查询请求或Whois查询，一些或所有这些名字。
1.20“注册运营商 ”是根据ICANN（或其受让人）与该个人或实体（该个人或实体 ) 之间的协议负责的个人或实体，如果该协议终止或到期，根据美国政府与该个 人或实体（该个人或实体）之间的协议为特定gTLD提供注册服务的个人或实体。
1.21关于特定gTLD的“注册中心服务 ”应具有ICANN和注册中心运营商之间关于 该gTLD的协议中定义的含义。
1.22“经销商 ”是一个人或实体参与注册的分销渠道域名注册(a)依照协议，安排或理解注册或(b)注册的实际知识，提供部分或全部注册服务，包括收集注册名称持有人注册数据，提交注册，或促进注册和注册名称持有人之间的注册协议。
1.23“限制性修订 ”系指(i)对共识政策和临时政策规范的修订，或（ii）第5节中规定的本协议条款。1、如该期限可根据第5.2条延长。
1.24注册名称是由将与该注册相关的记录纳入登记机构的注册机构“赞助 ”的。 注册的赞助可以在注册姓名持有人的明确指示下更改，或者如果注册商失去认证 , 根据当时的ICANN规范和政策更改。
1.25“规范和/或政策 ”包括本协议中引用的共识政策、规范（如Whois准确性程序规范），以及本协议特别规定的或ICANN章程授权的任何修订、政策、程序 或程序。
1.26“本协议条款 ”从生效日期开始，并持续至(a)到期日或(b)终止。
1.27“管理下的注册名称总数 ”是指注册机构向ICANN提交的最新月度报告中所 反映的由所有适用注册机构赞助的注册名称总数。
1.28“Whois准确性程序规范 ”系指根据本协议不时更新的Whois准确性程序规范。
1.29“Whois规范 ”是指根据本协议不时更新的注册数据目录服务（Whois）规范。
1.30“工作组 ”是指注册官利益相关者集团不时任命的适用注册官和社区其他 成员的代表，负责协商适用注册官协议的修订（不包括根据第6.9条进行的双边修订）。

2.ICANN义务。
2.1认证。在本协议有效期内，根据本协议的条款和条件，注册商经ICANN授权，注册商作为g tld的注册商（包括在注册数据库中插入和更新注册名称的注册）。
2.2 登记员使用 的 赋值名称与数字互联网公司名称，网站和商标。在ICANN期 间，ICANN特此向注册商授予非排他性、全球、免版税的许可， (a)声明其被ICANN 认证为g tld注册商
(b)链接到ICANN网站内的页面和文件。根据本协议所附的商 标许可规范中规定的条款和条件，ICANN特此授予注册商非排他性的、全球范围内的使用商标的权利和许可（在商标许可规范中定义）。此处不得许可对ICANN的名称、网站或商标的其他使用。注册商不得将本许可转让或再授权给任何其他方，包括但不限于注册商的任何附属机构或任何经销商。
2.3 将军义务的赋值名称与数字互联网公司对于影响注册官的权利、义务或角色的所有事项，ICANN应在本协议有效期内：
2.3.1以公开、透明的方式履行其职责；
2.3.2没有不合理地限制竞争，并在可行的范围内促进和鼓励激烈的竞争；
2.3.3不得任意、不合理或不公平地适用标准、政策、程序或做法，除 非有实质性和合理的理由，否则不得对登记官给予不同的待遇；
2.3.4通过其复议和独立的审查政策，在受到ICANN标准、政策、程序或做法的不利影响时，确保注册官有适当的上诉程序。
2.4 使用的赋值名称与数字互联网公司认可的 注册机构。为了促进竞争的域名注 册，和认可的价值ICANN认证注册商带给互联网社区，ICANN通常要求gTLD注册注 册合同使用ICANN认证注册，和ICANN将在本协议期间遵守任何ICANN采用规范或政策要求使用ICANN认证注册gTLD注册。

3.登记员义务。
3.1 义务向提供登记员服务在本协议有效期内，注册官同意其将根据本协议作 为一个或多个gtld的注册商。
3.2 提交的已注册名称支持物数据向注册表。在本协议的有效期限内：
3.2.1作为其在gTLD中注册名称的一部分，注册员应向gTLD提交以下数 据元素，或将由注册表操作员操作的注册数据库：
3.2.1.1正在注册的注册名称；
3.2.1.2注册名称的主名称服务器和辅助名称服务器（多个名称) 的IP地址；
3.2.1.3这些名称服务器的相应名称；
3.2.1.4除非由注册系统自动生成，否则注册人的身份；
3.2.1.5除非由注册系统自动生成，否则注册的截止日期；
3.2.1.6注册表操作员要求提交的任何其他数据。
其中，注册表运营商与注册表之间的协议，如经ICANN书面批准，可说明 适用于该gTLD的替代要求数据元素，在这种情况下，替代要求数据元素应 替换和取代第3款。上述2.1.1至3.2.1.6规定的内容为本协议项下的所有 目的，但仅针对该特定的gTLD。在寻求批准所需的替代数据元素时，第3.2.1.1至3.2.1.6小节中规定的数据元素应被视为建议的最低要求。
3.2.2在收到注册姓名持有人对第3.2小节中所列数据元素的任何更新后的 七(7)天内。1.2, 3.1.2.3，和3.2.1.6对于任何注册名称，注册运营商应 将更新的数据元素提交给相关注册运营商，或将这些元素放入相关注册操 作员操作的注册数据库中。
3.2.3为了允许在发生无法恢复的技术故障或指定注册表运营商的变更时， 在ICANN提出任何请求的十（10）天内，注册官须将包含第3.2.1.1至3.2.1.6款所列的数据元素的电子资料库， 提交由注册官赞助的所有有效记录，以获得适当的gTLD。
3.3 平民访问权限向数据在…上已注册 名称。在本协议的有效期限内:
3.3.1注册官应自费提供一个交互式网页，对于任何操作“瘦 ”注册表的gTLD，应提供一个端口43 Whois服务（每个服务都可通过IPv4和IPv6访问) , 提供免费的基于公共查询的最新访问(至少每日更新)有关在任何gTLD中由注册官赞助的所有有效注册名称的数据。在协商一致政策另有规定之前，该等数据应包括注册官数据库中所载的以下要素：
3.3.1.1已注册名称的名称；
3.3.1.2已注册名称的主名称服务器和次名称服务器的名称 ;
3.3.1.3注册官的身份（可通过注册官的网站提供）；
3.3.1.4注册的原始创建日期；
3.3.1.5注册的截止日期；
3.3.1.6注册姓名持有人的姓名和邮寄地址；
3.3.1.7已注册姓名的技术联系人的姓名、邮寄地址、电子邮件地址 、语音电话号码和（如可用）传真号码；
3.3.1.8已注册名称的管理联系人的姓名、邮寄地址、电子邮件 地址、语音电话号码和（如可用）传真号码。
如果经ICANN书面批准，注册表运营商和注册商之间的协议可以说明适用 于该gTLD的替代要求数据元素，在这种情况下，替代要求数据元素应替换 和取代上述第3至3.3.1.8款，但仅针对该特定的gTLD。.3.1.1
3.3.2在收到对第3.3小节中列出的数据元素的任何更新后。1.2, 3.3.1.3 和3.3.1.5至3.3.1.8，注册官应及时更新其用于提供第3.3.1款所述的公众访问的数据库。
3.3.3注册官可分包其提供第3.3.1款所述的公众访问和第3.3.2款所述的更 新的义务，但注册官仍应对适当的访问和更新负全部责任。
3.3.4注册商应遵守任何共识政策，要求注册商合作实施一种分布式功能，为所有注册商提供基于查询的Whois搜索功能。如果注册官实施的Whois服务未能在合理时间内提供相当可靠、可靠和方便地获取准确和最新的数据, 则注册官须遵守任何共识政策，要求ICANN合理确定（考虑特定注册官的 补救行动），从注册官的数据库提供数据，以促进开发集中的Whois数据库, 以提供全面的Whois搜索能力。
3.3.5在按照第3.3.1和3.3.4款的要求提供基于查询的公众的注册数据访问时，注册官不得对所提供数据的使用施加条款和条件，除非ICANN制定的任 何规范或政策允许。除非和直到ICANN建立不同的共识政策，注册应当允许 使用数据提供的查询任何合法目的，除了： (a)允许，启用或支持传输通过电子邮件、邮件、邮政邮件、传真或其他方式的主动，商业广告或请求以外的实体数据接收者自己的现有客户；或(b)支持大量的、 自动化的电子 流程，将查询或数据发送到任何注册中心运营商或icann认证注册中心的系统，除非有注册域名或修改现有注册的合理需要。
3.3.6如果ICANN根据ICANN保留的经济学家分析经济数据（该数据已提供 给注册官），确定个人或实体能够对注册或第三方开发增值产品和服务的 注册数据行使市场权力，注册官应根据第3.3.1款提供第三方大量访问数 据：
3.3.6.1注册官应每周至少提供一(1)份数据的完整电子副本，供已 与注册官签订批量访问协议的第三方下载。
3.3.6.2注册商可对大量访问该数据收取不超过10,000美元的年费。
3.3.6.3注册商的访问协议应要求第三方同意不使用该数据来允许、启用或以其他方式支持任何营销活动，无论使用何种媒介。这些媒体包括但不限于电子邮件、电话、传真、邮政邮件、短信和无线警报。
3.3.6.4注册商的访问协议应要求第三方同意不使用该数据来实现大容量、 自动化、电子流程，将查询或数据发送到任何注册中心运营商或icann认证注册商的系统，除非有注册域名或修改现有注册的合理需要。
3.3.6.5注册商的访问协议必须要求第三方同意不出售或重新分发的数据，除非它已经被第三方纳入一个增值产品或服务，不允许提取的大部分批量数据的增值产品或服务供其他各方使用。
3.3.7遵守适用的法规和其他原因，ICANN可能采取共识政策建立限制(a)个 人数据有关注册姓名注册可以向公众通过公共访问服务描述本小节3.3和(b) 注册的方式提供这样的数据。注册官须遵守任何该等协商一致政策。
3.3.8注册官应满足或超过Whois规范规定的要求。
3.4 保留的已注册名称支持物和注册数据。
3.4.1对于由注册官在gTLD内赞助的每个注册名称，注册官应按不时更新的情况，在其自己的电子数据库中收集并安全维护：
3.4.1.1本协议所附的数据保留规范中规定的数据；
3.4.1.2在第3.3.1.1至3.3.1.8小节中列出的数据元素；
3.4.1.3该账单联系人的姓名和（如果可用的话）邮政地址、 电子邮件地址、语音电话号码和传真号码；
3.4.1.4注册商根据第3.2款提交或列入注册商数据库的任何其他注册商数据；
3.4.1.5任何隐私服务或任何代理注册服务的被许可人提供的名称、邮寄地址、电子邮件地址和语音电话号码，在每种情况下，由注册商或其附属机构提供或提供的。 自ICANN完全实施根据第3条建立的 代理认证计划之日起生效。14、本第3.4.1.5条下的义务将不再适用 于另一方根据该代理认证计划明确要求保留的任何特定类别的数据（如邮政地址）。
3.4.2在本协议有效期内以及之后的两(2)年内，注册机构（其代理人） 应保存其与注册机构运营商和注册姓名持有人交易的以下记录：
3.4.2.1以电子形式提交给注册表运营商的所有注册数据（包括更新）的提交日期、时间和内容；
3.4.2.2以电子、纸质或缩微胶片形式，指构成注册申请、确认、修 改或终止的所有书面通信，以及与注册姓名持有人的相关通信，包括注册合同；
3.4.2.3以电子形式，所有注册姓名持有人与注册官的帐户记录。
3.4.3在本协议有效期内及此后的两(2)年内，注册官应在收到合理通知后 , 将本第3.4条规定的数据、信息和记录提供供ICANN检查和复制。此外， 在ICANN的合理通知和要求后，注册官应将可能涉及ICANN的有限交易或情况的数据、信息和记录的副本交付ICANN；但该等义务不适用于要求注册官 整个数据库或交易历史的副本。这些副本的费用由注册官提供。在回应 ICANN要求提供电子数据、资料和记录的要求时，注册官可以合理方便及ICANN可接受的格式提交该等资料，以尽量减少对注册官业务的干扰。如果 注册官认为向ICANN提供任何该等数据、信息或记录将会违反适用法律或任何法律程序，ICANN和注册官同意真诚地讨论是否可以确 定适当的限制、保护或替代解决方案，以允许以完整或修订的形式生产此 类数据、信息或记录。除非适用法律、任何法律程序或规范或政策明确要 求，否则ICANN不得披露此等数据、信息或记录的内容。
3.4.4尽管本协议或数据保留规范中有任何其他要求，注册商没有义务在域 名注册被删除或转移到另一个注册商后的两(2)年开始保存与域名注册相关 的记录。
3.5 权利 在 数据。注册官拒绝对注册官提交给注册表数据库的或在第3.2.1至3.2.3.3小节中列出的数据元素的独家所有权或使用的所有权利。.1.3注册官不否 认第3.2.1.4至3.2.1.6款和第3.3.1至3.3.3.1.8款中有关主动注册名称的权利，并同意授予非排他性、不可撤销、免版税的许可来使用和披露第3.2款中列出的数 据元素。1.4至3.3.1.3.3.3.1.8，提供3.2.1.6和3.3.3.1.3至3.3.1.8服务)。在 注册主任更改其认可后，注册主任承认获得赞助的注册主任须拥有业主对第3.2.1.4至3.2.1.6款及3.3.3.1.3至3.3.1.8款所列有关该注册名称的资料要素的 权利，注册主任亦保留该资料中拥有人的权利。本款不禁止注册官(1)以与本协议 和任何规范或政策一致的方式限制大量公众访问数据元素，或(2)根据本协议第3.5款的规定转让其在数据元素中主张的权利。
3.6 数据 托管。在本协议期限内，注册官应按照ICANN规定的格式向ICANN将第3.4.1.2至3.4.1.5款所述数据的电子副本提交给ICANN，或由注册官和ICANN共同 批准的信誉良好的托管代理，任何一方也不得无理拒绝此类批准。数据应根据注 册官、ICANN和托管代理（如有）之间的协议保存，规定 (1)数据应接收和托管， 除非验证所保存的数据，直到交给ICANN；
(2)数据到期时无需续期或终止；
(3)ICANN在托管协议下的权利应随本协议的任何转让而转让。第三方托管应在如果根据本款解除托管，ICANN（或其受让人）应享有非排他性、不可撤销、免版 税的行使许可（仅用于过渡性目的）或已行使提供注册服务所需的所有权利。
3.7 业务交易，包括和已注册名称持有人。
3.7.1如果ICANN采用了ICANN利益相关者集团（或任何后续集团）中反映 的ICANN认可注册商共识支持的规范或政策，建立或批准ICANN认可注册商 的行为准则，注册商应遵守该行为准则。
3.7.2注册官应遵守适用的法律和政府法规。
3.7.3注册官不得向任何实际或潜在的注册姓名持有人代表注册官享有超 过任何其他注册商的注册权限。
3.7.4注册官不得启用任何注册名称，除非及直至其信纳已收到支付其注册 费的合理保证。为此目的，收取信用卡，一般商业条款扩展到有信誉良好 的客户，或其他机制提供类似水平的支付保证，只要支付义务成为最终和不可撤销的注册姓名持有人激活注册。
3.7.5在注册期结束时，如果注册姓名持有人或其代表未能同意在第二次通 知或提醒规定的时间内更新注册，则在没有减轻处罚的情况下，将导致在 自动续期宽限期结束前取消注册（尽管注册官可选择提前取消该姓名）。
3.7.5.1详尽的情况被定义为： UDRP行动，有效的法院命令，失败 的注册的更新过程（不包括注册人未能响应），域名使用名称提供 DNS服务第三方（可能需要额外的时间迁移记录管理的名称），注册 人受到破产程序，支付纠纷（注册人声称支付续期，或支付金额的 差异），账单争议（注册人对账单上的金额有争议），域名须在有 管辖权的法院提起诉讼，或经ICANN特别批准的其他情况。
3.7.5.2注册官选择，在可有可原的情况下，更新域名没有明确同意 的注册人，注册必须保持记录的情况下更新的特定域名ICANN检查符 合条款3.4.2和3.4.3注册认证协议。
3.7.5.3在没有可减轻责任的情况下（如上文第3.7.5.1节所定义） , 必须在注册商或注册人终止注册协议后45天内删除域名。 3.7.5.4注册官应向每个新注册人提供通知，说明其删除和自动更新 政策的细节，包括未更新的域名相对于域名的到期日被删除的预期 时间，或不超过十（10）天的日期范围。如果注册商在注册协议期 间对其删除政策做出任何重大变更，则必须至少以同样的努力通知 注册商变更以通知注册商，如注册商（如注册商认证协议第3.7.7条中定义）。
3.7.5.5如果注册商经营一个域名注册或更新的网站，注册商的删 除和自动更新政策的细节必须在网站上清楚地显示。
3.7.5.6如果注册商经营一个域名注册或续期的网站，它应在注册 时和在其网站上明确声明，在赎回宽限期内收回域名所收取的任何费用。
3.7.5.7如果作为UDRP争议主体的域名在争议过程中被删除或到期 , 在UDRP争议中的申诉人将有权选择按照与注册人相同的商业条款 更新或恢复该名称。如果投诉人更新或恢复该名称，该名称将被放 置在注册人持有和注册人锁定状态，注册人的WHOIS联系信息将被 删除，而WHOIS条目将表明该名称存在争议。如果投诉被终止，或UDRP争议发现针对申诉人，该名称将在45天内被删除。注册人保留 现有赎回宽限期规定在赎回宽限期内任何时候收回名称的权利，并 保留在删除前更新名称的权利。
3.7.6注册不得插入或更新任何注册名称注册的方式违反(i)任何共识政策 声明列表或规范的排除注册名称插入或更新时生效，或（ii）任何名单保 留注册要求的特定注册运营商注册提供注册服务。
3.7.7注册官应要求所有注册姓名持有人与注册官签订电子或纸质注册协议 , 至少包括第3.7.7.7.1至3.7.7款中的规定。12，以及该协议另应规定适 用于由注册官赞助的域名的注册的条款和条件。与注册主任签订注册协议 的注册姓名持有人必须是注册官以外的个人或法人，但注册官可是注册域 名的注册姓名持有人，在这种情况下，注册主任须提交第3款所述的条文。
3.7.7.1至3.7.7.12，并应向ICANN负责遵守本协议、规范和政策中规定的注 册姓名持有人的所有义务。注册官应尽商业上合理的努力，强制执行注册 官与任何注册姓名持有人之间有关执行第3.7.7.7.1至3.7.7.12.款或任何 共识政策要求的注册协议的规定。
3.7.7.1注册姓名持有人应向注册员提供准确和可靠的联系方式，并 在注册姓名注册期限内进行更正和更新，包括：注册姓名持有人的 完整姓名、邮寄地址、电子邮件地址、语音电话号码和传真号码；
对于作为组织、协会或公司的注册姓名持有人，被授权人的姓名； 以及第3.3款中列出的数据元素。1.2、3.3.1.7和3.3.1.8。
3.7.7.2注册姓名持有人故意提供不准确或不可靠的信息，故意未在 任何更改后七(7)天内更新向注册商提供的信息，或未在超过十五 (15）天内询问与注册姓名持有人注册相关的联系方式的准确性，将 构成对注册姓名持有人-注册商合同的重大违约，并作为暂停和/或 取消注册姓名注册的依据。
3.7.7.3任何打算许可使用域名给第三方的注册名称持有人仍然是注册名称记录持有人，并负责提供自己的完整的联系信息，并提供和更新准 确的技术和行政联系信息，以方便及时解决与注册名称有关的任何 问题。注册姓名持有人根据本规定许可使用注册姓名应承担因错误 使用注册姓名而造成的损害的责任，除非它向提供注册姓名持有人 合理的可起诉损害证据的一方披露被许可人提供的当前联系信息和 被许可人的身份。
3.7.7.4注册官应向每位新或更新的注册姓名持有人提供通知 , 说明：
3.7.7.4.1拟从申请人处收集的任何个人资料的目的；
3.7.7.4.2数据的预期接收者或接收者的类别（包括注册表操 作员和其他将从注册表操作员接收数据的人）；
3.7.7.4.3哪些数据是强制性的，如果有，哪些数据是自愿的；
3.7.7.4.4注册姓名持有人或数据主体如何访问，并在必要时 纠正其持有的数据。
3.7.7.5注册姓名持有人应同意第3.7.7.4款中提到的数据处 理。
3.7.7.6注册姓名持有人应声明已向第3.7.7.4款所述的个人资料 提供与第3.7.7.4款相同的通知，且注册姓名持有人已获得与第3.7.7.5款所述的任何此等第三方个人的同意。
3.7.7.7注册官应同意，它不会以与其根据上述第3.7.7.4款向注册 姓名持有人发出通知的目的和其他限制不兼容的方式处理从注册姓名持有人收集的个人资料。
3.7.7.8注册官应同意，其将采取合理的预防措施，以保护个人数 据不受丢失、误用、未经授权的访问或披露、更改或销毁。
3.7.7.9注册姓名持有人应声明，据注册姓名持有人所知和相信，注册姓名或注册姓名直接或间接使用的方式均不侵犯任何第三方的合法权利。
3.7.7.10对于有关使用注册名称或因使用注册名称而引起的争议， 注册姓名持有人应在不损害其他可能适用的司法管辖区的情况下， 提交注册姓名持有人的住所(1)和(2)注册官所在地的法院的管辖权。
3.7.7.11注册名称持有人应同意其注册名称应根据任何规范或政策 , 或根据任何注册机构或注册程序， (1)纠正注册机构或注册机构在 注册名称时的错误，或(2)解决有关注册名称的争议。
3.7.7.12注册姓名持有人应赔偿和保持注册运营商及其董事、官员 、雇员和代理人的任何索赔、损害、责任、成本、费用和费用（包 括合理的法律费用和费用）。
3.7.8注册官应遵守Whois准确性程序规范中规定的义务。此外，尽管在Whois准确性程序规范相反，注册官应遵守任何共识政策要求合理和商业上可行的(a)验证，在注册时，联系信息与注册名称由注册官或(b)定期再验 证的信息。注册官须在任何人通知与注册官赞助的注册姓名有关的联系资 料不准确后，应采取合理步骤调查所声称的不准确。如果注册官获悉与其 赞助的注册名称有关的联系信息不准确，则应采取合理措施纠正该不准确。
3.7.9注册商应遵守任何禁止或限制注册商的域名仓储或投机的共识政策。
3.7.10注册人应在其网站上发布(/或提供所附的注册人利益和责任规范的 链接，不得采取任何违反本协议或适用法律相应规定的行动。
3.7.11注册官应向注册姓名持有人提供有关注册官服务的客户服务处理 过程的描述，包括提交投诉和解决有关注册官服务的争议的过程的说明。
3.7.12本协议未规定或限制注册医师向注册姓名持有人收取的注册注册金额。
3.8 域名争议 解决方案。在本协议有效期内，注册官应制定解决有关注册名称争 议的政策和程序。在ICANN就解决注册名称争议采取其他共识政策或其他规范或政 策之前，注册官应遵守ICANN网站上确定的统一域名争议解决政策（ “UDRP ”）(www.icann.组织/一般/共识政策。，可能不时修改。注册官还应遵守统一快速暂 停（ “URS ”）程序或更换程序，以及注册官为其提供注册官服务的注册官运营商 所要求的任何其他适用的争议解决程序。
3.9认证 费用。作为认证的条件，注册官须向ICANN支付认可费。这些费 用包括年费和可变费用。
3.9.1注册官应按照ICANN的公司章程和公司章程，按ICANN董事会规定的 金额向ICANN支付年度认证费。该年度认证费用不得超过4,000美元。年费 的支付应在ICANN开具发票后三十（30）天内到期，但注册官可选择按四 (4)个等额季度分期支付年费。
3.9.2注册官应支付ICANN董事会制定的符合ICANN章程的可变认证费用，但 在每种情况下，此类费用合理分配给与ICANN签订合同的所有注册商，且任 何此类费用必须经注册商明确批准，以支付所有注册商级费用的三分之二。只要注册官与本协议的所有重要条款仍然完全有效，且注册官与ICANN之间存在任何争议，注册官应及时支付这些费用。
3.9.3对于逾期三十（30）天或以上的任何付款，注册官应按每月1.5%的 利率支付利息，或者少于适用法律允许的发票日期或根据本协议第7.6条 发送发票的日期。在ICANN向注册官发出合理通知后，注册官提交的帐目 须经审计后进行核实由ICANN指定的独立第三方提供的注册官的账簿和记录，该第三方应保留 该等账簿和记录的机密性（其对账目的准确性和任何必要的更正除外）。
3.9.4本协议项下到期的认证费用不含税费。任何政府或其任何政治部门征 收的任何形式的政府费用（包括销售、营业额、服务、使用和增值税）均应由注册官承担，不得视为认证费用的扣除或抵销的一部分。除适用法律 规定外，ICANN的所有付款不得因任何税款、关税、收费、罚款而扣除或预 扣，在这种情况下，注册官在扣除或预扣后应增加等于扣除或预扣的金额的净额。
3.10 保险。注册员应维持ICANN规定的商业一般责任保险或类似责任保险，保险 单限额至少为500,000美元，包括本协议期间注册员业务产生的责任。
3.11义务 的 注册机构在…下面常见的控制兴趣如果下列情况，注册官应违反本协议：
3.11.1 ICANN终止一个附属注册商与ICANN的认证协议（一个“ 附属公司 终止 ”）；
3.11.2附属注册官未就ICANN根据本协议第5.8条终止附属注册商认可协 议的权利发起仲裁，或发起该仲裁且未胜诉；
3.11.3子公司的终止是由于严重损害消费者或公共利益的不当行为造成的;
3.11.4第二附属注册机构，在附属机构终止后，追求导致附属机构 终止的相同行为过程；
3.11.5 ICANN已向注册官发出书面通知，说明它打算主张本第3.11条关 于注册官的规定，该通知应合理详细地确定该主张的事实依据，而登记官未能在该通知发出后十五（15）天内纠正被指控的行为。
3.12义务相关向准备金的登记员服务通过 第三 各方。注册商负责为注册商赞 助商按照本协议提供的所有注册名称提供注册商服务，无论注册商服务是否由注 册商或第三方提供，包括经销商。注册商必须与其所有经销商签订书面协议，使 注册商能够遵守并履行其在本协议项下的所有义务。此外，注册官必须确保：
3.12.1其经销商不显示ICANN或ICANN认证的注册商标志，或以其他方式代 表自己被ICANN认证，除非他们得到ICANN的书面许可。
3.12.2经销商使用的任何注册协议均应包括经销商所要求的所有 注册协议规定和通知ICANN注册认证协议和任何ICANN共识政策，并应确定赞助注册或提供确 定赞助注册的方法，如到InterNIC Whois查询服务的链接。
3.12.3其经销商在客户询问后确认赞助注册商。
3.12.4其经销商遵守任何icann采用的规范或政策，这些规范或政策为提供 代理和隐私注册服务的个人或实体建立了认证计划（ “代理认证计划 ”）。除其他功能外，代理认证计划可能要求： (i)代理和隐私注册服务仅由 ICANN根据该代理认证计划认证的个人或实体就域名注册提供域名注册；以 及（ii）注册商应禁止经销商在知情的情况下接受未经ICANN根据代理认证 计划认证的代理和隐私注册服务提供商的注册。在代理认证计划建立之前 , 注册商应要求分销商遵守本协议所附的隐私和代理注册规范。
3.12.5为其经销商的客户提供了一个指向ICANN网页的链接，其中 详细介绍了注册人的教育信息，详见下文第3.16小节。
3.12.6如果注册商发现经销商导致经销商违反本协议的任何规定，注册商 应采取合理步骤执行与分销商的协议，以纠正和防止进一步的不遵守情况。
3.12.7其经销商应在其网站上发布(/或提供所附的注册人利益和责任规范 的链接，不得采取任何与本协议相应规定或适用法律相一致的行动。注册商须尽商业上合理的努力，强制执行注册商与任何转售商之间的协议的规定。
3.13注册官 训练下文第7.6款所述的注册人的主要联系人或指定人（只要指定人 受雇于注册人或附属注册人）应完成一门涵盖ICANN政策和协议下注册人义务的 培训课程。本课程将由ICANN免费提供给注册主任，并须以网上格式提供。
3.14义务 相关 向 代表权 和 隐私权 服务注册官同意遵守icann采用的任何建立代 理认证计划的规范或政策。注册官还同意与ICANN合理合作开发该项目。在代理认 证计划建立之前，注册官同意遵守本协议所附的隐私和代理注册规范。
.153注册员 自我评估 和 审计。注册员须不时与注册员协商，按ICANN指定的表格 , 填写并向ICANN提交注册员自我评估。注册官应在每个日历年结束后的二十（20 ) 天内，以ICANN指定的形式，向ICANN交付由总统、首席执行官、首席财务官或 首席运营官（或其同等人员）签署的证书，证明符合本协议的条款和条件。ICANN 可以不时（每日历年不超过两次）进行行为，或聘请第三方代表其进行合同符合 性审计，以评估注册官是否遵守本协议的条款和条件。根据本第3.15条进行的任 何审计应达到评估合规性的目的，ICANN将(a)提供合理的提前通知，该通知应合 理详细说明ICANN要求的文件、数据和其他信息的类别， (b)使用商业合理努力以 不不合理地干扰注册操作的方式进行此类审计。作为审计的一部分，应ICANN的要 求，注册官应及时提供所有响应文件、数据和任何其他必要的信息，以证明注册 官遵守本协议。在不少于十（10）天的通知后（除非注册官另有同意），ICANN可 以作为任何合同合规审计的一部分，在定期营业时间进行现场访问，以评估注册 官是否遵守本协议的条款和条件。除非适用法律、法律程序或任何规范明确允许 的要求，ICANN不得披露通过此类审计收集的注册员机密信息政策（包括ICANN的文件信息披露政策，该政策可不时修订）；但是，除适用法律 或法律程序要求外，ICANN不得发布任何注册官标记为或书面指定给ICANN为“机 密商业秘密 ”、“机密商业信息 ”或“机密财务信息 ”的信息。如果任何适用的 法律、法律程序或规范或政策允许披露，ICANN将在不少于十五（15）天内通知注 册官其披露该信息的意图，除非法律或法律程序禁止该通知。该等通知应包括ICANN计划向谁以及以何种方式披露该等信息。
3.16链接向 注册人 教育 信息ICANN已经发布了一个教育网页，总结了注册商认可 协议的条款和相关的共识政策 （截至本协议签订之日，位于：
http://www.icann.org/en/registrars/registrant-rights-responsibilities- en.htm）.注册官须在其可能运营的任何网站上提供该网页的链接，至少与ICANN 共识政策要求显示的政策或通知链接一样清晰。ICANN可与注册商协商，更新本网 站的内容和/或网址。
3.17注册官 联系 业务 组织 和 军官 信息注册官应向ICANN提供信息，并保持本协 议注册官信息规范中规定的准确和最新的信息。此外，注册官须在注册官提供或 提供服务的每个网站上公布《注册官信息规范》中指明的资料。注册官应在该等 信息的任何更改的五(5)天内通知ICANN，并在任何更改后的二十（20）天内更新 注册官的网站。
3.18注册官 滥用联系和 责任 向 调查 报告ofAbuse.
3.18.1注册官应保持虐待联系，以接收由注册官赞助的涉及注册姓名的虐 待报告，包括非法活动的报告。注册官须在注册官网站的主页（或在ICANN可能不时指定的其他标准化地点）公布一个电子邮件地址，以接收 该等报告。登记官应采取合理和迅速的步骤，调查任何有关滥用职权的报 告，并作出适当的回应。
3.18.2注册应当建立和维护一个专用的滥用接触点，包括一个专用的电 子邮件地址和电话号码监控一天24小时，一周七天，收到报告的非法活 动由执法、消费者保护、准政府或其他类似当局不时指定的国家或设立或维持实体办事处的司法辖区的领土政府。提交给这些联系人的有充 分根据的非法活动报告必须在24小时内进行审查，注册官授权该个人对该 报告采取必要和适当的行动。在回应任何此类报告时，注册官无须采取任 何违反适用法律的行动。
3.18.3注册官应在其网站上发布其接收、处理和跟踪滥用报告的程序。注 册官应记录其收到和对所有此类报告的答复。注册官应保存与该报告有关 的两(2)年或适用法律允许的最长期限，并在该期间，应在合理通知后向 ICANN提供该记录。
3.19附加 技术的 技术规格 向 实施 IPV6, 数据存储器 和 idn。注册官应遵守本 协议所附的附加注册操作规范。
3.20通知 的 破产， 定罪 和 保护措施 违反。注册官将在(i)第5.5.8条所述的任何 法律程序开始后的七(7)天内发出ICANN通知。（ii）发生第5.5.2条或第5.5.3条 规定的任何事项，或（iii）对注册人帐户信息或登记数据的任何未经授权的访问 或披露。根据第（iii）款所要求的通知，须包括未经授权进入的类型、如何发生 、受影响的注册人数，以及注册官为此而采取的任何行动。
3.21义务 的 注册机构 附属机构 和 注册表 操作员。如果注册官在本协议有效期内 隶属于任何注册运营商或后端注册运营商（一种“ 附属关系 ”），注册官应遵守 所有ICANN规范和政策，并将在产生附属关系的事件发生后三十（30）天内通知ICANN(e。g., 完成任何合并、收购或其他交易，或执行任何协议，在每种情况下 , 产生此种关联关系)。
3.22合作 和 紧急情况 注册表 服务 提供商。如果ICANN将注册商赞助注册名称的注 册操作转换到紧急注册服务提供者，注册商应在所有合理方面与紧急注册服务提 供者合作，包括与该提供商签订注册协议，并提供紧急提供商合理要求的所有注 册名称持有人数据，以促进gTLD注册的有效过渡。

4.制定或修订规范和政策的程序。
4.1 合规性 和 共识 政策 和 临时的 政策。在本协议有效期内，注册官应遵守并执 行截至生效日为止存在的所有共识政策和临时政策
http://www.icann.org/general/consensus-policies.htm，可能在未来开发和采 用按照ICANN章程，提供这样的未来的共识政策和临时政策采用按照程序和有关这 些主题和这些限制提出的共识政策和临时政策规范本协议。
5.期限、终止和争议解决。
5.1 期限 的 协议。本协议于生效日生效，初始期限持续至到期日，除非提前终止。
5.2 续订。本协议和注册商认证将在本协议有效期内连续延长五(5)年，此后根 据本协议条款规定的每个有效期为5年，除非：
5.2.1在续期时，注册商不再符合当时有效的ICANN注册商认证标准；
5.2.2注册商在到期日期或之后任何连续五(5)年期限到期时未履行其 在本协议项下的义务；
5.2.3注册官已在到期日前两(2)年或之后任何连续五(5)年到期日期内通 知本协议三(3)项或以上的重大违约；
5.2.4本协议已在到期日或此后任何连续五(5)年期限的到期日之前终 止。
如果注册官打算根据本第5.2条续签本协议，注册官应在有效期届满前不超过九十 （90）天和不少于六十（60）天以及此后的连续五(5)年内向ICANN提供书面通知 。该等通知的规定不应作为本协议项下续期的条件。根据其惯例（可能由ICANN进 行修改），ICANN将向注册官提供关于本协议项下的任何后续期限的到期日期和到 期日期的通知。
5.3 右边的 向 替代品 已更新 协议。如果在本协议期限内，ICANN采用修订形式的 注册商认可协议（ “更新的RAA ”），注册商（如果未收到(i)未补救的违约通知 或（ii）根据本第5条终止或中止本协议的通知）可通过给予ICANN书面通知选择 加入更新的RAA。如果发生此类选择，注册官和ICANN应尽快进入更新的RAA中规 定的期限的更新的RAA，本协议将被视为终止。
5.4 终止 的 协议 通过 注册官。注册官可在本协议期满前给予ICANN三十（30）天 的书面通知以终止。在注册官终止后，注册官无权获得根据本协议向ICANN支付 的任何费用的退款。
5.5 终止 的 协议 通过 赋值名称与数字互联网公司有下列情况之一的，ICANN 可在本协议到期前终止：
5.5.1注册官对认证或更新认证的申请或与申请相关的任何材料中存在重 大失实陈述、重大不准确或重大误导性陈述。
5.5.2 注册人：
.5.2.15被有管辖权的法院判定为与金融活动有关的重罪或其他严重罪 行，或被有管辖权的法院判定有：
5.5.2.1.1犯欺诈
5.5.2.1.2违反了受托责任
5.5.2.1.3在实际了解（或通过重大疏忽）的情况下，允许在 注册或使用域名或向注册人员提供不准确的组织信息时进行 非法活动；
5.5.2.1.4未能遵守由有管辖权的法院发出的有关使用由注册 官赞助的域名的命令的条款；
或ICANN合理认为与上述任何规定实质等同的司法裁定的主体；
5.5.2.2因涉及不诚实或滥用他人资金的行为而受到其住所地政府 的处分；
5.5.2.3是法院或仲裁法庭发布的非中间命令的主体，在每个有管辖 权的案件中，发现注册官直接或通过关联公司具体违反了与域名抢 注或其同等法规相关的适用国家法律或政府法规；
5.5.2.4由ICANN发现，基于其审查仲裁法庭的结果，已经从事，直 接或通过其子公司，在模式和实践贩卖或使用域名相同或令人困惑 的商标或服务的商标第三方商标注册的持有人没有权利或合法权益 , 商标已经注册和被恶意使用。
5.5.3注册官故意雇佣任何官员被判轻罪与金融活动或任何重罪，或由法院 管辖犯有欺诈或违反信托责任，或司法决心的主题ICANN合理认为实质性相 当于上述任何，这样的官员不会在注册的知识三十（30）天内终止；或任 何注册的董事会或类似管理机构的成员被判轻罪与金融活动或任何重罪，或由法院的管辖权犯有欺诈或违反信托责任，或司法决定，ICANN合理认为 实质性相当于上述的任何成员不会在注册了解上述三十（30）天内从注册 董事会或类似的管理机构。
5.5.4注册官未能在ICANN发出违约通知后的第20天（21）天内纠正任何 违反本协议的行为。
5.5.5注册官未能遵守第5.7或7.1条授予具体履行的裁决。
5.5.6注册官在十二（12）个月内至少三(3)次严重违反了本协议项下 的义务。
5.5.7注册官在收到三(3)天的通知后，继续以ICANN合理确定危及互联网 的稳定性或操作完整性的方式行事。
5.5.8 (i)注册官为债权人的利益或类似行为作出转让；（ii）对注册 官提起扣押、扣押或类似程序，这些程序对注册官为g tld提供注册服务 的能力构成重大威胁，而不是在其生效后六十（60）天内被驳回；（iii）指定受托人、接管人、清算人 或同等人员或控制注册官的财产；（iv）对注册官的任何财产执行， (v)注 册官根据任何破产、破产、重组或其他有关债务人救济的法律提起诉讼，此类程序在其生效后三十（30）天内不被驳回，或（vi）注册官根据美国 破产法，11 U.S.C.提出的保护申请第101节等。或外国同等物或清算、解 散或以其他方式停止其经营。
5.6 终止 程序。在上述第5.5.1款至第5.5.6款所述的情况下，本协议只能在向注 册官发出十五（15）天的书面通知后（在第5.5.4款的情况下）终止，在此期间， 注册官有机会根据第5款发起仲裁。8.以确定在本协议项下终止合同的适当性。在 第5.5.7款和第5.5.8款所述的情况下，本协议可在通知注册官后立即终止。
5.7 悬浮
5.7.1在发生第5.5条规定的任何情况后，ICANN可根据ICANN自行决定，在 根据第5.7.2款的规定发出通知后，选择暂停注册官创建或赞助新注册名 称或发起注册域名的任何或所有注册域名生效后的十二（12）个月。注册官的暂停并不排除ICANN根据第5.6条的通知要求发出终止通知的能力。
5.2.7第5.7.1款下的任何暂停将在给注册官十五（15）天书面通知后生效 , 在此期间注册官有机会根据第5.8款发起仲裁，以确定本协议下暂停的 适当性。
5.7.3在暂停后，注册官应通过在其网站上发布突出公告通知用户，它无法 创建或赞助新的gTLD域名注册或发起注册名称的入站转移。注册官的通知 须包括与ICANN的暂停通知的链接。
5.7.4如果注册官以ICANN合理确定危及互联网的稳定性或操作完整性的 方式行事，并且经通知不立即补救，ICANN可暂停本协议五(5)个工作日 , 等待ICANN根据第7.1款申请更多延长的具体性能或禁令救济。悬浮本款的协议，在ICANN的唯一判断，排除注册(i)提供注册服务委托注册通 知的日期注册和（ii）创建或赞助新的注册名称或发起入站转移注册名称 的注册域名。注册官还必须张贴第5.7款中规定的声明。
5.8 分辨率 的 争议 位于……之下 这 协议。根据第6节和第7.4节规定的限制，本协 议或与本协议有关的争议，包括(1)ICANN未能续签注册认证引起的争议和(2)具体 履行的请求，应在有管辖权的法院解决，或根据美国仲裁协会（AAA）通过第5.8 款规定的仲裁解决。仲裁应以英语进行，并应在美国加利福尼亚州的洛杉矶县进 行。除第7.4.5节规定外，双方从AAA仲裁员名单中约定一(1)名仲裁员，或者如果 双方在AAA要求双方指定仲裁员的十五（15）天内未同意仲裁员，AAA应选择并指 定一名仲裁员，充分考虑仲裁员对DNS的了解。双方应以同等的份额承担仲裁费用 , 但仲裁员有权按照AAA规则的规定在其裁决中重新分配仲裁费用。当事人应当自 行承担与仲裁有关的律师费，仲裁员不得根据裁决结果重新分配律师费。仲裁员 应在仲裁听证会结束后的九十（90）天内作出裁决。如果注册员发起仲裁，对ICANN根据第5.5条终止本协议或ICANN根据第5.7条暂停终止注册员是否合适提出 异议。注册官可同时要求仲裁小组中止终止或中止，直至作出仲裁决定。仲裁小 组应下令中止： (i)注册官证明继续经营不会损害消费者或公众利益，或（ii）仲 裁小组指定合格的第三方来管理注册官的运作，直至作出仲裁决定。为促进上述 第（ii）款，仲裁委员会特此获得一切必要的权力，根据注册委员会的要求，任 命一名合格的第三方来管理注册官的运作。在选择第三方经理时，仲裁小组应考 虑到注册官所表达的任何偏好，但不受其约束。任何批准暂缓执行请求的命令，必须在提交仲裁后的十四（14）天内发出。如果在十四（14）天内未发出批准延 期请求的命令，ICANN有权根据第5.5条继续终止本协议，或根据第5.7.1条暂停注 册官。如果注册官发起仲裁，对独立审查小组根据第4.3.3款提出的决定提出异议 , 以维持ICANN董事会认为一个规范或政策得到协商一致支持的决定，注册官可同 时要求仲裁在仲裁决定作出之前，委员会应保留遵守该政策的要求，而该要求应保留直到该 决定或仲裁小组批准ICANN解除中止请求的要求。在涉及本协议的ICANN的所有诉 讼中（无论是在未选择仲裁或执行仲裁裁决的情况下），此类诉讼的管辖权和专 属地点应在位于美国加利福尼亚州洛杉矶的法院；但是，双方也有权在任何有管 辖权的法院执行该法院的判决。为了帮助仲裁和/或保存当事人的权利在悬而未决 的仲裁，当事人有权寻求临时或初步禁令救济仲裁小组或法院位于洛杉矶，加利 福尼亚州，美国，不得放弃本仲裁协议。
5.9 限制 在…上 货币补救措施 为了违规行为 的 这 协议。ICANN违反本协议的行 为的总总额不等于注册官根据第3款向ICANN支付的认证费用。本协议在前12个月 内。注册官因违反本协议而向ICANN承担的金钱责任应限于ICANN在本协议项下的 认证费用，除对本协议的解释存在善意分歧外，应向ICANN支付合理的、直接的费 用，包括律师费、员工时间和与合法努力相关的其他相关费用，以及ICANN为应对 或减轻此类行为对注册姓名持有人和互联网社区的负面后果而产生的费用。如果 反复故意严重违反本协议，注册官应承担高达ICANN执行费用的五(5)倍的制裁，但在其他情况下，任何一方均不对任何违反本协议的特殊、间接、附带、惩罚性 、惩戒性或相应的损害赔偿负责。

6.修正案和弃权。
6.1如果ICANN董事会确定需要修订本协议（包括此处提及的规范，除非该规范 明确不允许修订）和ICANN与适用注册机构之间的所有其他注册协议（ “适用注 册协议 ”）（每个均为“特别修订 ”），则ICANN可根据本第6节规定的要求和 程序采用特别修订；但特别修订不得为限制性修订。
6.2在提交特别修正案供注册官批准之前，ICANN应首先就该特别修正案的形式和 实质与工作组进行真诚的协商。该等协商的持续时间应由ICANN根据特别修正案的 实质内容合理确定。接下来的在此等协商中，ICANN可建议通过在其网站上公开张贴不少于三十（30）个日历天 （“张贴期 ”），并根据第7.6条的规定。ICANN将考虑在发布期间就特别修正案 提交的公众意见（包括适用注册机构提交的意见）。
6.3如果在发布期（ “批准期 ”）到期后一百八十（180）个日历日内，ICANN董事 会批准特别修订（可能与提交公众意见的形式不同，但必须处理提交公众意见的 特别修订的主题，以反映和/或处理工作组的输入和公众意见进行修改），ICANN 应提供通知并提交该特别修订，供适用注册机构批准或不批准。如果在ICANN向适 用注册官发出通知后的六十（60）个日历日内，该特别修订收到注册官批准，该 特别修订应视为适用注册官批准（ “批准修订 ”），并在ICANN发出批准注册官通 知后的六十（生效日期）被视为本协议的修订。如果特别修订未获注册官批准，则特别修订应视为未获适用注册官批准（ “被拒绝修订 ”）。除以下规定外，被 拒绝的修正案对本协议的条款和条件没有任何影响。
6.4如果ICANN董事会合理地确定被拒绝修正案属于共识政策和临时政策规范第1.2 节规定的主题类别，ICANN董事会可以通过通用名称支持机构（ “GNSO ”）通过决 议（通过该决议的日期称为“决议采纳日期 ”），要求该决议发布报告（ICANN章 程中定义）。GNSO根据所要求的发布报告进行的政策制定过程在此被称为“PDP ” 。如果这样的PDP结果最终报告支持GNSO绝对多数（定义在ICANN的章程）， (i)建 议采用拒绝的修正案作为共识政策或（ii）建议反对采用拒绝修正案作为共识政策 ，，在上述(i)，董事会采用这样的共识政策，注册官应遵守其根据本协议第4条的 义务。在任何一种情况下，ICANN都将放弃被拒绝的修正案，它对本协议的条款和 条件没有任何影响。尽管上述规定的6.4节，ICANN董事会不得启动PDP对拒绝修正 案，如果在任何时候在十二（12）个月之前提交的拒绝修正案注册批准根据第6.3 节，拒绝修正案的主题终止或被放弃或终止PDP的主体。
6.5如果(i)被拒绝的修正案不属于共识政策和临时政策规范第1.2节规定的主题类 别，（ii）被拒绝修正案的主题是在提交第6节之前的十二（12）个月内的任何时 候。3、结论的主题或放弃或终止PDP没有导致GNSO绝对多数建议，或（iii）PDP不导致最终报告支持GNSO绝对多数(a)建议采用拒绝修正案共识政策或(b)建议反 对采用拒绝修正案共识政策（或等PDP已被放弃或终止的任何原因），然后，在任 何这种情况下，这种被拒绝的修正案仍可以下列方式获得通过并生效。为了通过 被拒绝的修正案，必须满足以下要求：
6.5.1被拒绝的修正案的主题必须在ICANN的任务范围内，并与其核心价 值观的平衡应用相一致（如ICANN的章程所述）；
6.5.2拒绝修正案必须合理的实质性和令人信服的原因在公共利益，必须 可能促进这样的利益，考虑竞争公共和私人利益可能受到拒绝修正案，并 且必须勉强定制，没有比合理必要的解决这样的实质性和令人信服的原因 在公共利益；
6.5.3程度拒绝修正案禁止或要求行为或活动，征收物质成本适用的注册 , 和/或大大减少公众访问域名服务，拒绝修正案必须最少限制手段合理 可以解决公共利益的实质性和令人信服的原因；
6.5.4ICANN董事会必须提交被拒绝修正案，以及关于被拒绝修正案符合上 述(i)至（iii）款规定要求的理由的书面解释，供不少于三十条的公众评 论（30） 日历日；
6.5.5这样的公众评论期后，ICANN董事会必须(i)参与协商（或直接ICANN 管理参与协商）与工作组，主题专家，GNSO的成员，相关咨询委员会和其 他相关利益相关者对这样的拒绝修正案一段不少于六十（60） 日历日；（ii）协商后，以投票的工作组和公众的意见），并考虑 影响ICANN的任何政策，包括ICANN的利益冲突政策（ “董事会修正案 ”） 。根据第6.6条，此类董事会修正案应视为批准修正案，并在ICANN提供的六十（60 ) 个日历日内生效（生效日期应视为本协议项下的修正案生效日期）。尽管有上 述规定，董事会修正案不得修改ICANN根据本协议收取的注册员费用，也不得修改 本第6条。
6.6尽管有第6.5节的规定，如果在ICANN董事会批准后的三十（30）个日历日的董 事会修正案期间，工作组代表适用注册人向ICANN董事会提交替代董事会修正案 ( “替代修正案 ”），则董事会修正案不应被视为批准修正案：
6.6.1阐述了工作组提出的修改本协议以代替董事会修正案的精确文本；
6.6.2陈述了由ICANN董事会确定的作为董事会修正案的理由的实质性和令 人信服的公共利益理由；
6.6.3相比董事会修正案是： (a)更狭窄地解决这样的实质性和令人信服的 原因在公共利益，和(b)在某种程度上替代修正案禁止或要求行为或活动， 强加材料成本影响注册官，或实质性减少访问域名服务，是一个较严格的手段来解决实质性和引人注目的原因在公共利益。不符合第6.6.1至6.6款要求的任何拟议修正案。3.在前一句中，不得被视为本协 议项下的替代修正案，因此不得取代或延迟董事会修正案的效力。如果在向ICANN董事会提交替代修正案后，替代修正案获得注册官的批准，替代修正案将 取代董事会修正案，并应被视为本协议下批准的修正案(并应有效并被视为对本 协议的修改ICANN向注册官提供批准该替代修订的通知后的六十（60）个日历日内，该生效日 期应视为本协议项下的修订生效日期)，除非在工作组通知ICANN董事会批准该替 代修订之日起的六十（60）个日历日内（在此期间ICANN应就替代修订与工作组接 触），ICANN董事会通过至少三分之二的ICANN董事会成员的赞成票投票，考虑到 任何ICANN政策，包括ICANN的利益冲突政策，拒绝替代修正案。如果(A)替代修正 案在提交适用注册机构的替代修正案后三十（30）天内未获得注册机构批准（工 作组应通知ICANN），或(B)ICANN董事会通过三分之二投票拒绝替代修正案，董事 会修正案（而非替代修正案）应在ICANN提供注册机构通知日期后六十（60）个日 历日（生效日期应视为本协议项下的修正案生效日期）生效。如果ICANN董事会拒 绝了一个替代修正案，董事会应发布一份书面理由，阐述其对第6.6.1至6.6节中 所列标准的分析。3.ICANN董事会拒绝本协议项下的替代修正案的能力并不免除董 事会确保任何董事会修正案符合第6.5.1至第6.5.5条中规定的标准的义务。
6.7如果注册官认为经批准的修正案不符合本第6条规定的实质性要求，或违反本 第6条的任何程序规定，注册官可根据第5.8条规定的争议解决条款对该特别修正 案的通过提出质疑，但该仲裁应由三人仲裁小组进行。任何此类质疑必须在ICANN 向已批准修正案的注册人发出通知后的六十（60）个日历日内提出，ICANN可将注 册人（包括注册人）提出的所有质疑合并为单一程序。经批准的修正案将被视为 在争议解决过程的未决期间没有修改本协议。
6.8注册官可在ICANN发出经批准的修正案通知后的三十（30）个日历日内，以书 面形式向ICANN申请豁免经批准的修正案（每次由注册官提出的“豁免申请 ”）。
6.8.1每个豁免请求都将阐明该请求的基础，并为豁免于经批准的修正案提 供详细的支持。豁免申请还可包括对该等注册官提出的已批准修正案的任 何替代方案或变更的详细描述和支持。
6.8.2只有在注册官明确和令人信服的证明，遵守已批准的修正案与适用 法律相冲突，或会对注册官的长期财务状况或经营结果产生重大不利影响 时，才可批准豁免申请。如果ICANN根据其合理的酌情权确定，批准该等 豁免请求将对注册人造成重大损害，或导致拒绝对注册人提供直接利益， 则不会批准任何豁免请求。
6.8.3在ICANN收到豁免请求后九十（90） 日历日内，ICANN应批准（批准可 能具有条件或包括批准修正案的替代或变更）或书面拒绝豁免请求，在此 期间批准的修正案不会修改本协议。
6.8.4如果豁免请求经ICANN批准，则批准的修改将不会修改本协议；但ICANN要求的批准修改的任何条件、替代或变更应有效，且在适用范围内， 将在修改生效日期之前对本协议进行修改。如果ICANN拒绝该豁免请求，则 批准的修正案将在修正案生效日期修改本协议（或者如果该日期已通过，该批准的修正案应视为立即生效），但注册官可在收到ICANN决定后三十 ( 30）个日历日内对ICANN根据第5.8条规定的争议解决程序拒绝豁免请求的 决定提出上诉。
6.8.5经批准的修改将被视为在争议解决过程的未决期间没有修改本协议。 .8为免生疑问，只有注册官根据本第6条经ICANN批准或根据第5条通过的仲 裁决定提交的豁免申请才能免除注册官任何已批准的修订，而向任何其他 适用注册官提交的豁免申请（通过ICANN或仲裁）不得具有本协议的效力或 免除注册官任何已批准的修订。
6.9除第4节、第5.3节、第6节、第7.4节以及本协议和规范另有规定外，本协议 或本协议的书面规定，且本第6节或第7节均无约束力。4应限制ICANN和注册商对 双方单独协商的本协议进行双边修改和修改。对本协议任何条款的放弃均不具有 约束力，除非由放弃遵守该条款的一方签署的书面文件证明。不放弃本协议的任 何条款或未能放弃执行本协议的任何规定应被视为或构成对本协议任何其他条款的放弃，除非另有 明确规定，任何此类放弃均不构成继续放弃。为免生疑问，本节第6节或第7节中 无任何内容。4应被视为限制注册官遵守第4条的义务。
6.10尽管本第6条有任何相反的规定， (a)如果注册官提供证据证明ICANN合理满意 批准的修正案将大大增加提供注册服务的成本，那么ICANN将允许一百八十（180 ) 日历天的批准修正案对注册官生效，如果注册官根据第5.4条向ICANN提供不可 撤销的终止通知， (b)根据第6条通过的任何批准修正案将对注册官生效。

7.杂项规定。
7.1 具体的 表演虽然本协议有效，但任何一方均可按照第5.8条规定的方式寻求 具体履行本协议的任何条款，但要求履行该等义务的一方并非重大违反其义务。
7.2 处理 通过 赋值名称与数字互联网公司 的 注册商提供 数据。在收到注册官提供 的任何个人资料前，ICANN须以书面形式向注册官指明ICANN打算使用该等个人资 料的目的和条件。ICANN可不时向注册官提供有关该等目的和条件的修订规范，该 规范应在向注册官提供后不少于三十（30）天内生效。ICANN不得将注册官提供的 个人资料用于与提供个人资料时有效的规范不一致的目的或条件。ICANN应采取合理措施，避免第三方使用与规范不一致的个人数据。 7.3转让； 变更 的 所有权 或 经营7.3.1本7.3节规定除外。1、任何一方只有在另一方事先书面同意后方可转 让或转让本协议，不得无理拒绝。如果ICANN未能在收到转让请求通知后三 十（30）个日历日内明确提供或拒绝同意本协议的任何请求转让（ “转让请 求 ”）（或者，如果ICANN要求注册官提供有关审查该请求的额外信息，在 收到有关该请求的所有书面信息后的六十（60）个日历日内），ICANN应被 视为同意该请求的转让。尽管有上述规定， (i)经ICANN董事会批准，ICANN 可未经注册官同意而转让本协议重组、重组或重组ICANN等受让人的明确承担本协议的条款和条件，（ii）注册可以分配本协议不同意ICANN注册的全资子公司的子公司的明示承担本 协议的条款和条件，和（iii）ICANN应被视为同意转让请求，其中与该转让 请求相关的受让人与ICANN签订了注册认证协议（前提是该受让人在所有重 要方面均符合该注册认证协议的条款和条件），除非ICANN在根据本第7.3.1 条收到该转让请求通知后十（10）个日历日内向注册官对该转让请求提出书 面异议。
7.3.2如果一个实体获得了注册官的股票、资产或业务的控股权益，注册官 应在该等收购后的七(7)天内提供ICANN通知。该等通知应包括一份声明，确 认注册人员符合当时有效的认证规范或政策标准，并符合其在本协议项下的 义务。在通知后三十（30）天内，ICANN可以向注册官提供额外的信息，以 遵守本协议，在这种情况下，注册官必须在十五（15）天内提供所要求的信 息。任何有关注册官继续认证的争议，应根据第5.8条予以解决。
7.4 谈判 过程。
7.4.1如果是ICANN的首席执行官（ “CEO ”）或注册利益相关者集团主席（ “主席 ”）希望讨论本协议的任何修订，首席执 行官或主席应向对方提供书面通知，合理详细说明本协议的建议修订（ “谈 判通知 ”）。尽管有上述规定，首席执行官和主席均不得(i)修改本协议，（ii）在2014年6月30日或之前根据第7.4节修改本协议，或（iii）在2014 年7月1日开始的任何12个月期间提出修改或提交谈判通知。
7.4.2在收到首席执行官或该公司的谈判通知后ICANN主席和工作组应就本协议拟议修订的形式和实质进行真诚协商（本 协议拟议修订），至少九十（90）个日历天（除非提前达成决议），并试 图就拟议修订达成双方可接受的协议（ “讨论期 ”）。
7.4.3如果，在讨论期结束后，一个协议是就拟议修订达成协议，ICANN应在其网站上不少于三十（30）个日历天（ “ 发布期 ”）发布双方同意的建议修订以征求公众意见，并根据第7.6条向所 有适用的注册商提供此类修订的通知。ICANN和工作组将审议在发布期间对 拟议修订所提交的公众意见（包括适用登记处所提交的意见）。在发布期结 束后，建议的修订应提交注册官批准和ICANN董事会批准。如果获得此类批 准，建议的修订应被适用的注册官和ICANN视为批准的修订，并在ICANN向注 册官发出六十（60）个日历天的通知后被视为对本协议的修订。
7.4.4如果，在讨论期结束后，一个协议是ICANN与拟议修订工作组未达成协议，首席执行官或主席可提供对方书面通 知（ “调解通知 ”），要求双方根据以下条款和条件通过公正、促进（非评 估）调解来解决与拟议修订相关的分歧。如果提供了调解通知，ICANN和工 作组应在其十五（15）个日历日内，同时在ICANN的网站上发布他们所需的 建议修订版本的文本和与其相关的立场文件。
7.4.4.1调解应由双方选定的一名调解员进行。如果双方不能在收到 调解通知的首席执行官或主席后的十五（15）个日历日内就调解人 达成一致，双方将立即选择一个双方都可接受的中介供应商实体，该实体应在该实体的选择后尽快指定一名调解员，并在调解特定争 议的必要程度上，具有域名系统的一般知识。任何调解人必须以书 面确认他或她不是，在调解期间也不会成为ICANN的雇员、合伙人、 执行董事、董事或证券持有人或适用的注册官。如果指定的调解员 未提供此类确认，则应根据本节第7.4.4.1条指定一名替代调解员。
7.4.4.2调解人应按照其与当事人协商后确定的便利性调解的规则和 程序进行调解。双方应真诚地讨论争议，并试图在调解人的协助下，友好解决争议。
7.4.4.3当事各方应自行承担调解费用。双方应当平分调解人的 费用和费用。
7.4.4.4如果在调解期间达成协议，ICANN应在其网站上发布双方同意的建议修订，并根据第7节ICANN向所有适用的注册机构发出 通知，工作组将考虑在发布期间对商定的建议修订提交的公众意见 （包括适用注册机构提交的意见）。在发布期结束后，建议的修订 应提交注册官批准和ICANN董事会批准。如果获得此等批准，建议的 修订应作为适用注册官和ICANN批准的修订，并在ICANN向注册官发 出六十（60）天通知后视为对本协议的修订。
7.4.4.5如果双方在调解通知首席执行官或主席收到调解通知后九 十（90）个日历日内未因任何原因解决争议，调解将自动终止（除 非经双方同意延长）。调解人应向各方提供在未来仲裁中可能考虑 的问题的定义。这些问题受以下第7.4.5.2节规定的限制。
7.4.5.如果经过调解，ICANN和工作组没有就拟议修订达成协议，首席执行官或主席可提供他人书面通知（ “仲裁通知 ”) , 要求ICANN和适用注册运营商通过有约束力的仲裁通过仲裁解决争议 , 遵守本第7.4.5节的要求和限制。
7.4.5.1如果发出仲裁通知，调解人对问题的定义以及拟议的修订 ( 来自ICANN、注册官或两者的修订）应张贴在ICANN的网站上供公众 评论，为期不少于三十（30）个日历天。ICANN和工作组将审议在发 布期间对拟议修订提交的公众意见（包括适用注册官提交的意见）, 有关此类意见和审议的信息应提供给三(3)人仲裁员小组。各方可 以在发布期之前和之后进行建议修改。仲裁程序不得在该公众评论期结束前开始，ICANN可将登记官（包括登 记官）提出的所有挑战合并为单一程序。但本节第7.4.5节中规定 的除外。1、仲裁应按照第5条的规定进行.8.7.4.5.2对于拟议修订的争议， (i)涉及共识政策，（ii）属于共识 政策和临时政策规范第1.2节规定的主题类别；或（iii）寻求修改 本协议的以下任何条款或规范：第2、第4和第6节；第3小节。1,3.2, 3.3, 3.4, 3.5, 3.7, 3.8, 3.9, 3.14, 3.19, 3.21, 5.1、5.2或5.3；以及共识政策和临时政策规范、数据保留规范、WHOIS精 度程序规范、注册数据目录服务（WHOIS）规范或附加注册商操作规范。
7.4.5.3调解人将向仲裁员小组介绍ICANN和工作组各自关于建议修 订的建议。
7.4.5.4本协议有关建议修订的修正案不得提交工作组或ICANN仲裁 , 除非工作组的建议修正案已获得注册官批准，而对于ICANN，建议的修正案已获得ICANN董事会的批准。
7.4.5.5为了让仲裁小组批准ICANN或工作组提出的与建议修订有关 的修正案，仲裁小组必须认为，该提出的修订符合ICANN的核心价值（见ICANN的章程），并且根据适用的注册商和ICANN（如适用）的 业务利益的成本和利益，以及该修订中规定的建议修订寻求实现的 公共利益。如果仲裁小组认为ICANN或工作组提出的修正案符合上述 标准，则在ICANN通知注册官后视为本协议的修订，并视为本协议项 下的批准修正案。
7.4.6就ICANN提出的已批准的修订，注册主任可根据第6.8条的规定以书 面向ICANN申请豁免该修订。
7.4.7尽管本第7.4节有任何相反的规定， (a)如果注册提供证据ICANN的合理满意度，批准修正案将大大增加了提供注册服务 的成本，然后ICANN将允许180（180） 日历天批准修正案对注册生效，和(b) 根据第7.4条通过的任何批准修正案，如果注册向ICANN提供根据第5.4条不 可撤销的终止通知，对注册生效。
7.5 不 第三方 受益人。本协议不应被解释为ICANN或注册商对本协议的任何非参 与方承担任何义务，包括任何注册姓名持有人。
7.6 注意事项 和 指定。除第4.4条和第6条规定外，根据本协议发出的所有通知应 在下列相关方的地址以书面形式发出，除非该方已发出书面地址变更通知。（如 有变更，双方应在三十（30）天内通知另一方。本协议要求的任何书面通知应被 视为亲自送达，通过电子传真并确认送达，通过国际公认的快递服务计划送达，或通过电子方式送达，然后通过收件人的传真机或电子邮件服务器肯定确认收到 。对于根据本协议建立的新规范或政策的任何通知，注册官应在通过电子邮件通 知给注册官并发布在ICANN网站上，以遵守该规范、政策或计划的任何紧急情况后 , 给予一段合理的时间。ICANN根据本协议项下的通知和指定在视为书面通知注册 官时生效。
7.7 日期 和 乘以与本协议或其履行相关的所有日期和时间应根据美国加利福尼亚州洛杉矶的日期和时间计算。
7.8 语言根据本协议所发出的所有通知、名称、规格或政策均应使用英文版本。
7.9 对应的。本协议可签署一份或多份副本，每一份均应视为正本，但所有副本 均应构成同一份文书。
7.10 全部的 协议。除非(a)在双方同时签署的书面协议或(b)注册官向ICANN提供
的书面保证，否则本协议（包括构成认证一部分的规范）构成双方关于注册认证 的全部协议，并取代双方之前的所有协议、谅解、谈判和讨论，无论是口头的还 是书面的。 7.11可分割性。如果本协议的一项或多项条款在适用法律下被认为不可执行，双 方同意善意地重新协商该条款。如果双方不能就该条款达成双方同意和可执行的 替代协议，则(a)该条款应被排除在本协议之外； (b)本协议的余额应解释为该条 款被排除； (c)本协议的余额应根据其条款强制执行。

WHOIS精度程序规范

注册官应执行并遵守本规范中规定的要求，以及ICANN和注册官利益相关者集团在注册官 认证协议期限内对本规范进行的任何商业实用更新。
1.除下文第3条规定外，在(1)注册官赞助的注册名称注册后十五（15）天内将注册名 称转交给注册官，或(3)注册名称持有人对注册官赞助的任何注册名称的任何变更 , 注册官将就Whois信息和与该注册名称相关的相应客户帐户持有人联系信息：
a.在适用的国家或地区，以适当的格式验证本协议第3.3.1款所要求的所有领域的 数据的存在。
b.根据RFC5322（或其后继者），验证所有的电子邮件地址都是正确的格式。
c.根据ITU-T E，验证电话号码的格式是否正确。164国际电话号码（或其等效或 后继号码）。
d.验证邮政地址是否符合UPU邮政寻址格式模板、S42地址格式中定义的适用国家 或地区)或其他标准格式的适当格式。
e.验证所有邮政地址字段在不同字段之间是一致的（例如：城市存在街道，城市 位于州/省，城市与邮政编码匹配），这些信息在技术上和商业上在适用的国家或地区是可行的。
f.验证：
i.注册姓名持有人的电子邮件地址（如果不同，还有帐户持有人的电子 邮件地址），通过基于工具的认证方法，如提供必须以注册官指定的 方式返回的唯一代码，
ii.注册姓名持有人的电话号码（如果不同，账户持有人）通过(A)电话或 发送短信到注册姓名持有人的电话号码提供一个独特的代码，必须返回 以注册官指定的方式，或(B)叫注册姓名持有人的电话号码，要求注册 姓名持有人提供一个唯一的代码发送到通过网络、电子邮件或邮政邮件。
在任何一种情况下，如注册官没有收到注册姓名持有人的肯定答复，注册 官应手动核实适用的联系信息，或暂停注册，直到注册官核实适用的联系 信息为止。如果注册官没有收到帐户持有人的肯定答复，注册官应手动核 实适用的联系信息，但不需要暂停任何注册。
2.除下文第3节规定外，在收到Whois中的联系信息或与注册官赞助的任何注册名称相关 的相应客户帐户联系信息的任何变更后的十五（15）个日历日内（无论注册官之前是 否需要执行本规范中关于该注册名称的验证和验证要求），注册官将在第1节要求的 范围内，按照上述第1节规定的方式验证更改的字段。如果注册官没有收到提供所需 验证的注册姓名持有人的肯定答复，注册官应手动核实适用的联系信息，或暂停注册 , 直到注册官核实适用的联系信息为止。如果注册官没有收到帐户持有人的肯定答复 , 注册官应手动核实适用的联系信息，但不需要暂停任何注册。
3.除下文第4段规定外，如果注册官已经成功完成了对相同联系信息的验证和验证程序， 且不知道该信息不再有效，则注册官不需要执行上述第1(a)至1(f)条中的上述验证和 验证程序。
4.如果注册官有任何信息表明上述第1(a)至1(f)节中指定的联系信息不正确（如注册官 收到符合ICANN的Whois数据提醒政策的退回电子邮件通知或未送达通知信息）（无论 注册官之前是否需要执行本规范中关于该注册名称的验证和验证要求），注册官必须 验证或重新验证第1节中所述的电子邮件地址（es）。f（例如，要求对Whois数据提 醒政策通知作出肯定的回应）。如果注册官在收到任何此类信息后十五（15）个日历 日内未收到提供所需验证的注册姓名持有人的肯定答复，注册官应手动核实适用的联 系信息或暂停注册，直到注册官核实适用的联系信息。如果注册官在收到任何此类信 息后的十五（15）个日历日内，注册官没有收到支付注册名称的客户的肯定答复，如 果适用，提供必要的验证，注册官应核实适用手动提供联系信息，但不需要暂停任何注册。
5.如果注册姓名持有人故意提供不准确或不可靠的WHOIS信息，故意未能及时更新提供给 注册官的信息，或注册官超过十五（15）个日历询问与注册姓名持有人注册相关的联 系方式的准确性，注册官应终止或暂停注册姓名持有人的注册姓名，或在客户和客户 上注册，直到注册官确认注册姓名持有人提供的信息为止。
6.本规范的条款和条件应在本协议形式的第一天或前后由ICANN与注册利益相关者集团 协商审查本规范的条款和条件。
7.如果客户账户持有人没有任何注册名称，则本规范中的任何内容均不得视为要求注 册官对任何客户账户持有人信息进行验证或验证。

注册数据目录服务（WHOIS）规范

1.注册数据目录服务。在ICANN需要不同的协议之前，注册商将根据RFC 3912运行 通过端口43可用的WHOIS服务，以及基于web的目录服务，提供至少对第3.3.1.1至3.3.1节中规定的元素的免费公共查询访问。按照本规范第1.4节中 规定的格式签署注册商认证协议。ICANN保留指定替代格式和协议的权利，根 据该规范，注册官将在合理可行的范围内尽快实施该替代规范。在IETF发布有关IETF标准、可扩展互联网注册数据服务工作组中规定的基于 IETF的标准及其任何修订（RFC2026中规定）后，注册官应在ICANN要求后135 天内实施任何此类标准（或任何修订）中规定的目录服务。注册官应在ICANN 国际化注册数据工作组（IRD-WG）的工作及其在ICANN董事会批准后135天内， 根据ICANN发布的规范实施国际化注册数据发布指南。
1.1.答复的格式应遵循以下半免费文本格式，后面是空行和法律免责声明， 说明注册官和用户查询数据库的权利。
1.2.每个数据对象应表示为一组键/值对，行以键开头，后面是冒号，空格作 为分隔符，后面是值。
1.3.对于存在多个值的字段，应允许具有相同键的多个编号键/值对（例如，列出多个名称服务器）。空白行之后的第一个键/值对应被视为新记录的 开始，并应被视为识别该记录，并用于将数据，如主机名和IP地址，或域 和注册人信息分组在一起。
1.4.域名数据：
1.4.1.查询格式：whois-hwhois。注册商示例。tld示例。.4.2.TLD 1响 应格式：回复的格式应包含所有元素，并遵循以下半自由文本格式的大纲。可以在文本的 末尾添加其他数据元素格式概述如下。根据注册官的选择，数据元素后面可以有一个空行和一个法律免 责声明，说明注册官和用户查询数据库的权利的免责声明（但任何此类法律免责 声明之前必须有该空行）。
域名：示例。TLD
注册表域ID： D1234567-TLD
WHOIS服务器： whois。注册商示例。tld
注册网址： http://www。注册商示例。tld 更新日期：2009年05月29日T20：13：00Z
创建日期：2000年10-08T00：45：00Z
注册商注册截止日期：2010年10-08T00：44：59Z注册商：示 例注册商有限责任公司
注册官IANA身份证：55555555
注册商滥用联系电子邮件：电子邮件@注册商。tld 注册员滥用联系电话： +1。1235551234
经销商：示例经销商1
域状态：禁止删除的客户端2 域状态：客户端禁止更新
域状态：客户端禁止传输
注册表注册人号： 5372808-ERL3 注册人姓名：实例注册人4
注册者组织：示例组织
登记人街： 123号例子街 注册城市：任何城镇
注册国家/省：AP5
注册商邮政编码：A1A1A16 注册国：AA
注册人电话： +1.5555551212 注册电话分机： 12347
注册人传真： +1.5555551213 注册人传真分机： 4321
注册者电子邮件：电子邮件@示例。TLD 注册表管理ID： 5372809-ERL8

1可以删除数据元素，但如果使用了数据元素，则它必须出现在这个位置。
2注意：所有适用的状态都必须显示在Whois输出中。
3如果不能从注册表中获得此信息，则可以留空。
4对于需要“名称 ”或“组织 ”的注册人、管理员和技术联系人字段，输出必须 包括名称或组织（如果有，两者都包括）。
5如果不可用，所有“州/省 ”字段可能保留为空。
6如果不可用，所有“ 邮政编码 ”字段可能保留为空。
7如果无法提供电话，所有“传真 ”和“传真 ”字段可以留空。
8如果不能从注册表中获得此信息，则可以留空。

管理机构：注册人组织管理机构： 123号街
管理城市：任何城镇 管理州/省：AP
管理邮政编码：A1A1A1 管理国家：AA
管理员电话： +1.5555551212 行政电话分机：1234
管理员传真： +1.5555551213 管理传真分机：1234
管理员电子邮件： EMAIL@EXAMPLE.TLD 注册表技术ID： 5372811-ERL9
技术名称：实例注册人的技术
技术组织：实例注册人有限责任公司 科技街： 123例街
科技城：任何城镇 技术国家/省：AP
技术邮政编码：A1A1A1 技术国家：AA
技术电话： +1。1235551234 技术电话分机：1234
技术传真： +1.5555551213 技术传真分机：93
电子邮件：电子邮件@示例。TLD
名称服务器： NS01。注册商示例。TLD10 名称服务器： NS02。注册商示例。TLD
DNSSEC：签署代表团
ICANN WHOIS数据问题报告系统的URL：http://wdprs.国 际的。net/

最近更新的WHOIS数据库： 2009-05-29T20：15：00Z <<<

1.5.以下数据字段的格式：域状态、个人和组织名称、地址、街道、城市、
州/省、邮政编码、国家、电话和传真号码、电子邮件地址、 日期和时间必须符合EPPRFC5730-5734（或其后继者）中指定的映射，IPv6地址格式 应符合RFC5952（或其后继者），以便这些信息（或WHOIS响应中返回的值 ) 可以统一处理和理解。
2.注册数据目录服务的服务级别协议（RDDS）
9如果不能从注册表中获得此信息，则可以留空。
10必须列出所有关联的名称服务器。
o IP地址。指IPv4或IPv6地址，但两者之间没有任何区别。当需要进行区分 时，将使用IPv4或IPv6。
o探测器。用于执行位于不同全局位置的测试（见下文）的网络主机。
o RDDS.注册数据目录服务是指WHOIS和基于Web的WHOIS服务的集合。 o RTT.往返时间或RTT是指从发送发出请求所需的分组序列的第一分组的第一 比特到接收接收响应所需的序列的最后一个比特的时间。如果客户端没有 接收到考虑所收到的响应所需的整个数据包序列，则该请求将被视为未被 响应。
o SLR.服务级别要求是服务级别协议（SLA）中测量的某个参数的服务级别。
2.2服务水平协议矩阵

参数 单反（月）

睡眠呼吸障碍 RDDS可用 小于或等于864 min的停机时 间 RDDS查询RTT 小于或等于4000 ms，至少有95%的 查询 RDDS更新 时间 小于或等于60 min，至少为95%的 探针

鼓励注册官在每项服务的流量较低的时间和日期为不同的服务进行维修。由于大 量停机已经纳入可用性指标、计划停机或类似指标；任何停机时间，无论是维护 或系统故障，都将被简单地记录为停机时间，并计入SLA目的。
2.2.1 RDDS可用性。指所有RDDS服务，注册员可以使用相关注册员系统的适当数 据响应互联网用户的查询。如果51%或更多的RDDS测试探测器在给定的时 间内认为任何一个RDDS服务都不可用，则该RDDS将被视为不可用。
2.2.2 WHOIS查询RTT。是指从TCP连接开始到其结束的数据包序列的RTT，包括接 收WHOIS响应。如果RTT是相应单反的5倍或以上，则RTT将被视为未定义。 2.2.3基于Web的-WHOIS查询RTT。是指从TCP连接开始到其结束的数据包序列的RTT，包括仅接收到一个HTTP请求的HTTP响应。如果注册官实施多步骤获取信息，只 测量最后一步。如果RTT是相应单反的5倍或以上，则RTT将被视为未定义。
2.2.4 RDDS查询RTT。是指“WHOIS查询RTT ”和“基于web的WHOIS查询 RTT ”的集合。
2.2.5 RDDS更新时间。指从收到EPP确认到域名、主机或联系人的转换命令的时间 , 直到RDDS服务的服务器反映所做的更改。
2.2.6 RDDS测试。表示发送到一个RDDS服务的服务器的特定“IP地址 ”的一个查 询。查询应在注册商系统中关于现有的对象，并且响应必须包含相应的信 息，否则查询将被视为未应答。RTT比相应的单反高5倍的查询将被视为未 应答。RDDS测试的可能结果是：以毫秒对应的RTT为单位的数字或未定义/ 未回答的数字。
2.2.7测量RDDS参数。每5分钟，RDDS探测将从所有注册商的每个RDDS服务服务器 的dns注册“IP地址 ”中选择一个IP地址，并对每个服务器进行“RDDS测试 ”。如果“RDDS测试 ”结果未定义/未回答，相应的RDDS服务将被视为从该 探测不可用，直到需要进行新的测试。
2.2.8整理来自RDDS探针的结果。在任何给定的测量周期内，认为测量有效的最小 数量为10，否则测量将被丢弃并被认为不确定；在这种情况下，单反不会 标记故障。
2.2.9放置RDDS探针。测量RDDS参数的探头应放置在不同地理区域内用户最多的 网络内；应注意不要在高传播延迟链路后部署探头，如卫星链路。
2.3绩效测量的契约
注册官不得干涉测量探头，包括对被监控服务请求的任何形式的优惠待遇。注册 官应像响应互联网用户（对于RDDS）的任何其他要求一样，响应本规范中所述的 测量测试。

共识政策和临时政策规范

1.共识政策。
1.1.“共识政策 ”是指(1)根据ICANN的章程和正当程序制定的程序，以及(2)涵盖本文件第1.2 节所列主题的政策。ICANN章程中规定的共识政策制定程序和程序可根据其中规定的程序不 时进行修订。
1.2.协商一致政策及其制定程序的设计应尽可能使包括登记商在内的互联网利益相关者达成 共识。共识政策应涉及以下一种或多项政策：
1.2.1.合理需要统一或协调解决的问题
促进因特网、注册商服务、注册表服务或域名系统（ “DNS ”）的互操作 性、安全性和/或稳定性；
1.2.2.提供注册官服务的功能和性能规范；
1.2.3.注册商的政策合理必要，以执行有关的共识政策 一个gTLD注册表；
1.2.4.解决有关域名注册的争议(与使用此类域名，但包括此类政策考虑使用域名的情况）；或 1.2.5.对注册中心经营者和注册商或经销商的交叉所有权的限制和如果注册商运营商和注册商或分销商有关联，有关注册商和注册商操作以及使 用注册商和注册商数据的法规和限制。.3.1第1.2节中所述的此类问题应包括，但不限于：
1.3.1.TLD中注册名称的原则(如先到/先得， 及时续期，到期后的持有期）；
1.3.2.禁止注册机构或域名的仓储或投机 主管注册者
1.3.3.在TLD中注册名称的保留，可能最初注册或
不得因与(i)避免用户之间的混淆或误导，（ii）知识产权，或（iii）DNS或互联 网的技术管理(e。g.，设立登记时姓名的保留处)；
1.3.4.维护和获取准确的和最新的信息有关已注册的名称和名称服务器；
1.3.5.避免因注册运营商或注册商暂停或终止业务而中断域名注册的程序，包括在失去 认可的注册商在TLD中赞助的持续注册商之间分配责任的程序；
1.3.6.在注册主任更改赞助一个或多个注册资料时，转移注册资料 注册名称。
1.4.除对协商一致意见政策的其他限制外，它们不得：
1.4.1.规定或限制注册商服务的价格；
1.4.2.修改对临时政策（定义如下）或协商一致政策的限制； 1.4.3.修改注册注册商认可协议中有关条款或注册商续期、终止或修改认可协议的条件，或注册商向ICANN支付的费用；或 1.4.4.修改ICANN对不适用标准、政策、程序或实践的义务武断、不合理或不公平，除非有实质性和合理的理由，否则不得给予不同的待遇 , 并以公开和透明的方式行使其责任。 2.临时的 政策。 注册官应遵守并实施ICANN董事会（ “董事会 ”）临时制定的所有规范或政策， 如果董事会由至少三分之二的成员投票通过，只要董事会合理地确定这些修改或修订是合理 的，并且必须立即临时建立关于该主题的规范或政策，以维持注册服务、注册服务或DNS或互 联网（“临时政策”）的稳定或安全。
.1.2.建议的规范或政策应尽可能狭隘以实现这些目标。在制定任何临时政策时，董事会应说明采用临时政策的时间，并应立即实施 ICANN章程中规定的共识政策制定过程。
.1.1.2 ICANN还应发布一份包含其详细说明的咨询声明采用临时政策的理由，以及董事会认为这种临时政策应得到互联网利益攸关方 的一致支持。
2.1.2.如果采用临时保单的时间超过90天，则委员会应重申每90天通过一次临时政策，总期间不超过一年，以保持该临时政策有 效，直到其成为协商一致政策为止。如一年期间届满，或在该一年期间，临时政策 未成为共识政策，并未得到董事会的重申，则注册主任将不再被要求遵守或执行该 临时政策。
3. 通知 和 冲突。注册官应在收到建立协商一致政策或临时政策的通知后，向其提供一段合理的 时间，并考虑到所涉及的任何紧急情况。如果注册服务与一致政策或任何临时政策之间存在冲突，则一致政策或临时政策应控制，但仅涉及冲突的主题。为免生疑问，符合本规范要求 的协商一致政策可补充或取代注册官与ICANN之间协议的规定，但仅在该等协商一致政策与第1.2条中规定的事项和 本规范的1.3。

关于隐私和代理注册的规范

在(i)2017年1月1日和（ii）ICANN建立并实施注册商认证协议第3.14节中引用的 隐私和代理认证计划的日期之前，注册商同意遵守，并要求其关联方和分销商遵 守本规范的条款，前提是ICANN和工作组可以共同同意延长本规范的期限。本规范 不得由ICANN或注册官修改。

1. 定义。对于本规范而言，应适用以下定义。

1.1“损益客户 ”是指，无论损益所使用的术语隐私服务和代理服务的提供者、被许可人、客户、受益用户、受益 人或其他接受者。
1.2“隐私服务 ”是一种注册注册姓名的服务作为注册姓名持有人的受益用户，但P/P提供商提供替代可靠的联系信 息，以便在注册数据服务（Whois）或同等服务中显示注册姓名持有人 的联系信息。
1.3“代理服务 ”是指注册姓名持有人通过的服务许可使用注册名称给P/P客户，以提供P/P客户使用该域名的机会，注 册名称持有人的联系信息显示在注册数据服务（Whois）或同等服务中 , 而不是P/P客户的联系信息。
1.4“P/P提供商 ”或“服务提供商 ”是隐私/代理的提供商 服务，包括注册官及其附属公司。
2.义务 的 注册官。 对于注册商或其关联公司提供的任何代理服务或隐私服务 , 包括注册商或其关联公司通过经销商分销的P/P服务，并与注册商赞助， 注册商及其关联公司必须要求所有P/P供应商遵循本规范中描述的要求，并 遵守根据本规范发布的条款和程序。
2.1 公开 的 服务 条款。损益提供商应公布条款和其服务条件（包括定价），在其网站和/或注册商的网站上。
2.2 Abuse/Infringement 观点 的 联系 损益供应商应发布希望报告滥用或侵犯商标（或其他权利）的第三方的联络 点。
2.3 公开 的 身份 的 P/P 提供程序。 损益提供商应公布其信息 在其网站和/或注册商的网站上的商业联系信息。
2.4 条款 的 服务 和 描述 的 程序P/P供应商应在其网站和/或注册商网站上发布一份供应商供应商服务协议及 供应商处理以下程序的说明：
2.4.1报告滥用域名的进程或工具 由损益提供商管理的注册；
2.4.2报告商标或商标侵权行为的程序或设施 第三方的其他权利；
2.4.3损益供应商将中继的情况 第三方与损益客户的沟通；
2.4.4损益提供商将终止的情况 为损益表客户提供服务；
2.4.5损益表提供商将披露的情况和/或在注册数据服务（Whois）或同等服务中发布损益客户 的身份和/或联系数据；
2.4.6由损益表供应商提供的支持服务的描述 P/P客户，以及如何访问这些服务。
2.5 托管 的 P/P 客户信息注册官应包括P/P本协议第3.6条要求的其登记数据托管存款中的客户联系信息。只有 在本协议终止或注册商终止业务运营的情况下，ICANN才能访问根据 本规范第2.5节托管的P/P客户信息。
3.豁免。如果可以证明以下情况，注册官没有义务遵守本规范的 要求：
3.1注册姓名持有人使用损益供应商的服务 未由注册官或其任何附属公司提供；
3.2注册姓名持有人将注册姓名许可给另一方（即在注册员不知情的情况下充当代理服务）；
3.3注册姓名持有人使用P/P提供者联系数据订阅该服务或接受P/P供应商的条款和条件。

数据保留规范

1.在本协议有效期内，对于注册官在gTLD内赞助的每个注册名称，注册官应收集 并安全地保存在其自己的电子数据库（不时更新）以下数据：
1.1.注册人须向注册人收集以下资料域名的注册时间（以下简称“注册 ”），并须在注册官赞助注册期间及 其后的额外两年内保存该资料：
1.1.1 注册人姓名或法定全称；
1.1.2 姓名和姓，或如果注册人是法人，则为注册人的行政联系人、技术联系人和账单联系人的头衔；
1.1.3 注册人的邮寄地址、行政联系人、技术联系人、账单联系人；
1.1.4 注册人的电子邮件地址、行政联系人、技术联系人、账单联系人；
1.1.5 注册人的电话联系人、行政联系人、技术联系人和账单联系人；
1.1.6 WHOIS信息，如WHOIS规范中所述；
1.1.7.购买供连接的域名服务类型 与注册；
1.1.8.在注册官收集的范围内，“卡片存档 ”，当期 第三方交易编号，或其他经常性支付数据。
1.2.注册官应收集以下资料并维持相关互动后不少于一百八十（180）天的信息：
1.2.1.有关付款方式和付款来源的信息注册官处理注册交易或第三方支付处理者提供的交易号码；
1.2.2. 日志文件，账单记录，以及收集和维持该等记录在商业上是可行的，或符合注册商经营的行业内 普遍公认的标准做法包含通信源和目的地信息的记录，包括，根据传输方式，但不 限于： (1)源IP地址、HTTP头、 (2)电话、文本或传真号码； (3) 与注册人和注册人之间的通信相关的电子邮件地址、注册处理 或即时通讯标识符；
1.2.3. 日志文件和，包括收集和维护这些文件记录在商业上是可行的，或符合注册商经营的行业内全行业普遍 接受的标准惯例，而与注册相关的其他记录则包括通信和会议的 日期、时间和时区，包括初始注册。
2.如果收到(i)适用司法管辖区的国家认可律师事务所的书面法律意见，声明注册 官收集和/或本协议规定的任何数据元素的保留有可能违反适用法律（ “意见 ” ) , 或（ii）具有司法管辖权的政府机构的裁决或书面指导，规定遵守本规范 的数据收集和/或保留要求违反适用法律，注册官真诚地确定，收集和/或保留 本规范中规定的任何数据元素违反了适用法律，注册官可向ICANN提供书面通知 , 并要求放弃遵守本规范的特定条款和条件（ “放弃请求 ”）。该书面通知应 ： (i)规定相关适用法律、涉嫌违规的数据收集和保留要素、收集和/或保留违 反适用法律的方式，以及对该裁定和与之相关的任何其他事实和情况的合理描 述，（ii）附一份意见和政府裁决或指导的副本，以及（iii）注册从任何政府 当局收到的任何文件，以及ICANN合理要求的其他文件。在收到该通知后，ICANN和注册官应真诚地讨论该事项，以努力达成双方都可接受的解决方案。直 到ICANN处理Whois与隐私法冲突的程序被修改为包括与本规范要求相关的冲突 , 如果ICANN同意注册官的决定，ICANN总法律顾问办公室可暂时或永久暂停遵 守本规范受影响的规定，并授予豁免请求。在授予本协议项下的任何豁免之前 , ICANN将在其网站上发布其决定，为期三十（30）个日历日。在ICANN处理与 隐私法冲突的程序修改后，所有弃权请求（无论批准或拒绝）应按照修改后的 程序解决。
3.如果(i) ICANN先前响应位于注册商同一管辖区的注册商的放弃请求而放弃遵 守本数据保留规范的任何要求；（ii）注册商受导致ICANN同意授予该放弃的 同一适用法律约束，注册商可要求ICANN批准类似的放弃，该请求应由ICANN 批准，除非ICANN向注册商提供了不批准该请求的合理理由，在这种情况下， 注册官可根据本数据保留规范第2节提出弃权请求。
4.本数据保留规范针对违反适用法律的任何修改仅适用于适用法律的具体规定仍 然有效的时间内。如果适用法律被废除或修改（或抢占）的方式不再禁止收集 和/或保留数据保留规范，注册同意本规范的原始版本将适用于修改适用法律 允许的最大程度。

注册商信息规范

注册官应向ICANN提供以下规定的信息，这些信息应按照本协议第3.17条进行 维护。关于以下确定的信息，ICANN将根据本协议第3.15节中规定的披露要求 持有此类信息。
一般信息
1.注册官的法定姓名。
2.司法常务官的法律形式（例如，有限责任公司、公司、政府机构、政 府间组织等）。
3.注册官的业务为法律和财务目的而注册的司法管辖区。
4.注册官的商业注册号码和发出该号码的当局的名称。
5.注册官使用的每一个商业名称和/或商名称。
6.提供现有的文件，证明注册官实体是合法建立的，并且信誉良好。对于成立证 明，请提供实体的特许文件或其他同等文件（如会员协议）。如果注册官是一个 政府机构或组织，请提供一份已建立政府机构或组织的相关法规、政府决定或其 他文书的认证副本。对于政府机构或组织以外的实体，如注册官管辖范围内没有 此类证书或文件，则由公证人或注册官管辖法院的合法执业者起草并签署的宣誓书，宣布该组织已成立并成立 站立，必须提供。
7.注册主任的通讯地址。此地址将用于合同目的，注册官必须能够接受此地址的 通知和法律程序服务。不允许使用邮政信箱。
8.为合同目的可以联系登记官的主要电话号码。
9.为合同目的可以联系注册官的主要传真号码。
10.为合同目的联系注册官的主要电子邮件地址。
11.如注册主任的主要营业地点或地址与7中提供的地址不同，请提供包括地址、 电话号码、传真号码和电子邮件地址。向ICANN提供现有文件，证明注册官有权 在主要营业地点做生意。
12.注册官将经营或管理的任何其他地址，如果与上述提供的主要营业地点或通 信地址不同。（如果有，请进行解释。）向ICANN提供当前的文件，证明注册官 在法律上有权在确定的每个地点做生意。
13.主要联系人姓名：
标题 地址
电话号码 传真号码
电子邮件地址
14.43 WHOIS服务器的URL和位置。
所有权、董事和高级管理人员信息 15.拥有注册商当前业务实体至少5%所有权权益的任何个人或实体的完整姓名、联 系信息和职位。对于列出的每个人，请指定该人的所有权百分比。
16.注册主任所有董事的全部姓名、联系信息和职位。
17.注册官所有官员的姓名、联系信息和职位。（官员的姓名和职位必须公开 显示。）
18.所有高级管理人员和监督注册人员服务提供的其他关键人员的完整姓名、 联系信息和职位。
19.对于问题15至18的回答中提到的每一个人或实体，表明该人或实体：
a)在过去十年内，被判犯有重罪或与金融活动有关的轻罪，或被法院判定有欺诈或违反信托责任，或一直是一个主题 与这些事项类似或相关的司法裁定；
b)在过去十年内，曾因涉及不诚实或滥用他人资金的行为而受到任何政府 或行业监管机构的纪律处分；
c)目前参与的任何司法或监管程序，可能导致第19(a)或第19(b)项中规 定的类型的定罪、判决、裁定或纪律；
d)是被ICANN强制取消资格的对象。如果在(a)-(d)中发生了上述任何一个事件，请提供详细信息。
20.列出所有附属注册人，如果有的话，并简要描述附属机构。
21.对于第20项中列出的任何实体，必须提供上述第1-14项中要求的信息。
22.如果适用，请列出注册商的最终父实体。
23.注册商或其任何附属公司是否提供任何隐私服务或代理服务（如隐私和代理注 册规范中定义的条款）？如果是，请列出提供隐私服务或代理服务的实体或个人。
24.对于第23项所列的任何实体，请提供上述第1-14项所要求的信息。 25.注册官是否利用或从经销商的服务中获益？
26.如果是，请提供注册官已知的所有此类经销商的名单。本项目26中规定的信 息应根据要求提供给ICANN。在ICANN制定接收和保留此类信息的安全方法时，该 信息应根据本协议第3.17条提供给ICANN。
标有“ ”的物品亦必须在注册主任的网站上公布。

附加的注册商操作规范

ICANN可在与注册商利益相关者集团（或其继任者）协商后，不时修改本规范，但 此等更新对整个注册商行业具有商业实用性。
1.数据存储器

注册商必须允许其客户根据要求使用DNSSEC，并代表客户向注册商发送添加、 删除或更改公钥材料（如DNSKEY或DS资源记录）的订单，以支持DNSSEC。此类 请求应以安全的方式和根据行业最佳实践进行接受和处理。注册商应接受由相 关TLD支持并出现在位于： <http://www.iana.org/assignments/dns-sec-alg -numbers/dns-sec-地址号的注册商中的任何公钥算法和摘要类型。xml>和http://www.iana.org/assignments/ds-rr-types/ds-rr-类型。xml.所有此 类请求都应使用RFC 5910中规定的EPP扩展或其后续版本传输给注册中心。
2.IPv6
如果注册商向注册商提供注册名称服务器地址的能力，则注册商必须允许同 时指定IPv4地址和IPv6地址。
3.综合数字网

如果注册商提供国际化域名（ “IDN ”）注册，所有新注册必须符合注册注册 证书5890、5891、5892、5893及其继任者。注册官还应遵守IDN指南
http://www.icann.org/en/topics/idn/implementation-guidelines.htm是哪 个可不时被修改、修改或取代。注册商必须使用相关注册表发布的IDN表。

注册人的利益和责任

领域名称登记人的权利
1.您的域名注册和您可能同时使用的任何隐私/代理服务必须与ICANN认证注册商 签订注册协议才能进行注册。
您有权随时审阅本注册协议，并下载一份记录副本。

2.您有权获得有关以下方面的准确和可获取的信息：
您的ICANN认证注册官的身份；与您的注册人有关的任何代理或隐私服务提供商的身份；
您的注册人的条款和条件，包括适用于域名注册的价格信息；
该条款和条件，包括价格信息，适用于您的注册官提供的任何隐私服务； 由注册官和隐私服务提供商提供的客户支持服务，以及如何访问它们；
如何与你的注册主任及他们提供的任何隐私服务提出关注及解决纠纷；及 说明你的注册员的注册过程的说明，管理、转移、更新和恢复您的域名注册，包括通过您的注册商提供的任何 代理或隐私服务。
3.您不得受到您的注册官提供的虚假广告或欺骗行为的约束，也不得受到您的注 册官提供的任何代理或隐私服务的约束。这包括欺骗性的通知、隐藏的费用， 以及任何根据你住所的消费者保护法规定的非法行为。

领域名称登记人的职责：
1.您必须遵守您的注册官张贴的条款和条件，包括您的注册官、注册处和 ICANN的适用政策。

2.您必须审查您的注册商的当前注册协议，以及任何更新。

3.您将全权承担注册和使用您的域名的责任。
4.您必须提供准确的信息，以便在WHOIS等目录中发布，并及时更新，以反映 任何更改。

5.您必须在十五（15）天内回复您的注册人员的查询，并保持您的注册人员帐户 数据的最新状态。如果您选择让您的域名注册自动更新，您还必须保持您的 支付信息的最新状态。