2013 Registrar Accreditation Agreement
本文引用ICANN文档 来源>>27 June 2013 This REGISTRAR ACCREDITATION AGREEMENT (this "Agreement")is by andbetween the Internet Corporation forAssigned Names and Numbers,a Californianon-profit,public benefit corporation (“ICANN”),and [Registrar Name],aOrganization 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 thatperson 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 entitiesmeeting 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 controlwith")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 Namesponsored by Registrar that is prohibited by applicable law and/or exploitation of Registrar’s domain name resolution or registration services in furtherance ofconduct 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 inproviding Registry Services) maintains data in a Registry Database, arranges forsuch 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 andsubmits 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 ApplicableRegistrars; 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; or1.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 oragainst,but not abstain or otherwise fail to vote) aproposed amendmentunder Section 6, and the affirmative approval of Applicable Registrarsaccounting 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 TotalRegistered Names Under Management by each Applicable Registrar Family shall not exceed the total Registered Names Under Management of theApplicable 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 RegisteredName 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 RegistryServices and submitted by registrars in electronic form, and all other data used to provide Registry Services concerning particular domain name registrations ornameservers 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 accordancewith 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 aboutRegistered Name Holders, submitting that data to Registrar, or facilitating the entry of the registration agreement between the Registrar and the Registered NameHolder.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 recordassociated 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 theearlier of (a) the Expiration Date, or (b) termination of this Agreement.1.29 “Total Registered Names Under Management” means the total number ofRegistered 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 andother 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). ICANN OBLIGATIONS.2.1 Accreditation. During the Term of this Agreement and subject to the termsand 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 theRegistry Database) for gTLDs.2.2 Registrar Use of ICANN Name, Website and Trademarks. ICANN herebygrants 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 theterms 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 beassigned 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 thisAgreement: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 disparatetreatment unless justified by substantial and reasonable cause; and2.3.4 ensure, through its reconsideration and independent review policies, adequate appeal procedures for Registrar, to the extent it is adverselyaffected by ICANN standards, policies, procedures or practices.2.4 Use of ICANN Accredited Registrars. In order to promote competition in theregistration of domain names, and in recognition of the value that ICANN-Accredited registrars bring to the Internet community, ICANN has ordinarily required gTLDregistries under contract with ICANN to use ICANN-Accredited registrars, andICANN will during the course of this agreement abide by any ICANN adoptedSpecifications or Policies requiring the use of ICANN-Accredited registrars by gTLD registries. 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, theRegistry 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; and3.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 elementsapplicable to that gTLD, in which event, the alternative required dataelements shall replace and supersede Subsections 3.2.1.1 through 3.2.1.6stated 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, and3.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 theregistry 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 activeRegistered 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 telephonenumber, and (where available) fax number of the technical contact for the Registered Name; and3.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 elementsapplicable to that gTLD, in which event, the alternative required dataelements shall replace and supersede Subsections 3.3.1.1 through 3.3.1.8stated 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 Subsections3.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 serviceimplemented 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, ifreasonably determined by ICANN to be necessary (considering suchpossibilities 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 Whoissearch capability.3.3.5 In providing query-based public access to registration data asrequired 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 anySpecification or Policy established by ICANN. Unless and until ICANNestablishes 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, postalmail, facsimile or other means of mass unsolicited, commercial advertising or solicitations to entities other than the data recipient's own existingcustomers; 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 madeavailable 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 anymarketing activities, regardless of the medium used. Such mediainclude 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, electronicprocesses that send queries or data to the systems of any RegistryOperator or ICANN-Accredited registrar, except as reasonablynecessary 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 otherreasons,ICANN may adopt a Consensus Policy establishing limits (a) on the Personal Data concerning Registered Names that Registrar may makeavailable to the public through a public-access service described in thisSubsection 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 underSubsection 3.2; and3.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 ProxyAccreditation 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 expresslyrequired 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 recordsrelating 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 writtencommunications constituting registration applications, confirmations, modifications, or terminations and related correspondence withRegistered Name Holders, including registration contracts; and3.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 thisSection 3.4 available for inspection and copying by ICANN upon reasonablenotice. 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 ortransaction history. Such copies are to be provided at Registrar’s expense. In responding to ICANN’s request for delivery of electronic data, informationand records, Registrar may submit such information in a format reasonably convenient to Registrar and acceptable to ICANN so as to minimizedisruption 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 todiscuss in good faith whether appropriate limitations, protections, oralternative 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 DataRetention Specification, Registrarshall not be obligated to maintain records relating to a domain registration beginning on the date two (2) yearsfollowing 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 RegisteredNames submitted by Registrar to the Registry Database for, or sponsored byRegistrar 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 Subsections3.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 inSubsections 3.2.1.4 through 3.2.1.6 and 3.3.1.3 through 3.3.1.8 for the purpose ofproviding a service or services (such as a Whois service under Subsection 3.3.4)providing interactive, query-based public access. Upon a change in sponsorshipfrom 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 and3.3.1.3 through 3.3.1.8 concerning that Registered Name, with Registrar alsoretaining the rights of an owner in that data. Nothing in this Subsection prohibitsRegistrar from (1) restricting bulk public access to data elements in a mannerconsistent 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 mutuallyapproved by Registrar and ICANN, such approval also not to be unreasonablywithheld by either party. The data shall beheld under an agreement amongRegistrar, 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 beassigned 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 fortransitional 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 aCode 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 RegisteredName 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 itsregistration fee. For this purpose,a charge to a credit card, generalcommercial 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 renewedwithin 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 (additionaltime maybe required to migrate the records managed by thenameserver), the registrant is subject to bankruptcy proceedings,payment dispute (where a registrant claims to have paid for arenewal, or a discrepancy in the amount paid),billing dispute (where a registrant disputes the amount on a bill), domain name subject tolitigation 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 byICANN 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 inSection 3.7.5.1 above),a domain name must be deleted within 45 days of either the registrar or the registrant terminating a registrationagreement.3.7.5.4 Registrarshall provide notice to each new registrantdescribing the details of their deletion and auto-renewal policyincluding 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 theregistration agreement, it must make at least the same effort to inform the registrant of the changes as it would to inform the registrant ofother 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 orrenewal, 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 domainname during the Redemption Grace Period.3.7.5.7 In the event that a domain which is the subject of a UDRPdispute is deleted or expires during the course of the dispute, thecomplainant in the UDRP dispute will have the option to renew orrestore the name under the same commercial terms as the registrant. If the complainant renews or restores the name, the name will beplaced in Registrar HOLD and Registrar LOCK status, the WHOIScontact information for the registrant will be removed, and theWHOIS entry will indicate that the name is subject to dispute. If the complaint is terminated, or the UDRP dispute finds against thecomplainant, the name will be deleted within 45 days. The registrant retains the right under the existing redemption grace periodprovisions 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 orspecification of excluded Registered Names that is in effect at the time ofinsertion or renewal, or (ii) any list of names to be reserved from registration as required by the specific Registry Operator for which the Registrar isproviding Registrar Services.3.7.7 Registrarshall require all Registered Name Holders to enter into anelectronic 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 whichagreementshall otherwise set forth the terms and conditions applicable tothe registration of a domain name sponsored by Registrar. The RegisteredName Holder with whom Registrar enters into a registration agreement must be a person or legal entity other than the Registrar, provided that Registrarmaybe 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 shallbe 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 compliancewith the provisions of the registration agreement between Registrar and any Registered Name Holder that relate to implementing the requirements ofSubsections 3.7.7.1 through 3.7.7.12 or any Consensus Policy.3.7.7.1 The Registered Name Holdershall provide to Registraraccurate and reliable contact details and correct and update themwithin seven (7) days of any change during the term of the Registered Name registration, including: the full name, postal address,e-mailaddress, voice telephone number, and fax number if available of the Registered Name Holder; name of authorized person for contactpurposes in the case of an Registered Name Holder that is anorganization, 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 orunreliable information, its willful failure to update informationprovided to Registrar within seven (7) days of any change, or itsfailure to respond for over fifteen (15) days to inquiries by Registrar concerning the accuracy of contact details associated with theRegistered 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 timelyresolution of any problems that arise in connection with theRegistered Name. A Registered Name Holder licensing use of aRegistered Name according to this provisionshall accept liability for harm caused by wrongful use of the Registered Name, unless itdiscloses the current contact information provided by the licensee and the identity of the licensee within seven (7) days to a partyproviding 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; and3.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 toRegistrar 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 incompatiblewith 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 ordisclosure, 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 theregistration of the Registered Name nor the manner in which it isdirectly or indirectly used infringes the legal rights of any third party.3.7.7.10 For the adjudication of disputes concerning or arising fromuse 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 anyregistrar or registry procedure not inconsistent with any Specification or Policy, (1) to correct mistakes by Registrar or the RegistryOperator 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 holdharmless 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 WhoisAccuracy Program Specification. In addition, notwithstanding anything inthe Whois Accuracy Program Specification to the contrary, Registrarshallabide by any Consensus Policy requiring reasonable and commerciallypracticable (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 anyperson of an inaccuracy in the contact information associated with aRegistered 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 orrestricting 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 regardingRegistrar 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 disputesconcerning 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 DisputeResolution 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 disputeresolution 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'sbylaws 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 fullforce 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 theinvoice or the date the invoice is sent pursuant to Section 7.6 of thisAgreement. 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 thereofon 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, thesum 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 forsuch deduction or withholding being required.3.10 Insurance. Registrarshall maintain in force commercial general liabilityinsurance or similar liability insurance as specified by ICANN with policy limits of at least US$500,000 covering liabilities arising from Registrar's registrar businessduring 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 AffiliateTermination, the same course of conduct that resulted in the Affiliate Termination; and3.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, whichnoticeshall 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 RegisteredNames that Registrar sponsors being performed in compliance with this Agreement, regardless of whether the Registrar Services are provided by Registrar or a thirdparty, 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 bythe 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 AccreditationProgram”). Among other features, the Proxy Accreditation Program may require that: (i) proxy and privacy registration services may only beprovided 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 registrationsfrom any provider of proxy and privacy registration services that is notAccredited by ICANN pursuant the Proxy Accreditation Program. Until such time as the Proxy Accreditation Program is established, Registrarshallrequire 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 takereasonable 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 underICANN 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 ProxyAccreditation Program. Registrar also agrees to reasonably cooperate with ICANN in the development of such program. Until such time as the Proxy AccreditationProgram 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 inconsultation 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, chiefexecutive officer, chief financial officer or chief operating officer (or theirequivalents) 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 complianceaudits to assess compliance by Registrar with the terms and conditions of thisAgreement. 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 ofdocuments, data and other information requested by ICANN, and (b) usecommercially reasonable efforts to conduct such audit in such a manner as to notunreasonably disrupt the operations of Registrar. As part of such audit and uponrequest by ICANN, Registrarshall timely provide all responsive documents, data and any other information necessary to demonstrate Registrar’s compliance with thisAgreement. 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 theterms and conditions of this Agreement. ICANN shall not disclose Registrarconfidential information gathered through such audits except as required byapplicable 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 anyinformation that Registrar has marked as, or has otherwise designated in writing toICANN as, a “confidential trade secret,” “confidential commercial information” or “confidential financial information” of Registrar. If any applicable law, legalproceeding or Specification or Policy permits such disclosure, ICANN will provide Registrar no less than fifteen (15) days notice of its intent to disclose suchinformation, unless such notice is prohibited by law or legal proceeding. Such noticeshall include to whom and in what manner ICANN plans to disclose such information.3.16 Link to Registrant Educational Information. ICANN has published aneducational webpage summarizing the terms of the Registrar AccreditationAgreement 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 fordomain name registration or renewal clearly displayed to its Registered NameHolders 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 RegistrarInformation 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 ofIllegal Activity. Registrarshall publish an email address to receive suchreports on the homepage of Registrar's website (or in another standardized place that maybe designated by ICANN from time to time). Registrarshalltake 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 ofcontact, 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 isestablished or maintains a physical office. Well-founded reports of IllegalActivity submitted to these contacts must be reviewed within 24 hours by an individual who is empowered by Registrar to take necessary and appropriateactions 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. Registrarshalldocument its receipt of and response to all such reports. Registrarshallmaintain 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 Specificationattached hereto.3.20 Notice of Bankruptcy, Convictions and Security Breaches. Registrar will giveICANN notice within seven (7) days of (i) the commencement of any of theproceedings 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 noticerequired 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 eventRegistrar 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 thatICANN transitions the operation of a registry for agTLD in which Registrar sponsors Registered Names to an emergency registry service provider, Registrarshallcooperate in all reasonable respects with such emergency registry service provider,including by entering into a registry-registrar agreement with such providernecessary 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. 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 athttp://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 theprocedures and relate to those topics and subject to those limitations set forth in the Consensus Policies and Temporary Policies Specification to this Agreement. 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 soonerterminated.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 thisAgreement, 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 thisAgreement 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 morematerial breaches of this Agreement within the two (2) years preceding the Expiration Date or the date of expiration of any successive five (5) year termthereafter; or5.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 nomore 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 theExpiration 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 theUpdated 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, ormaterially 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 acourt of competent jurisdiction to have:5.5.2.1.1 committed fraud,5.5.2.1.2 committed a breach of fiduciary duty, or5.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; or5.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; or5.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 specificviolation(s) of applicable national law or governmental regulation relating to cybersquatting or its equivalent; or5.5.2.4 is found by ICANN, based on its review of the findings ofarbitral tribunals, to have been engaged, either directly or through its Affiliate, in a pattern and practice of trafficking in or use of domainnames 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 arebeing used in bad faith.5.5.3 Registrar knowingly employs any officer that is convicted of amisdemeanor related to financial activities or of any felony, or is judged by acourt of competent jurisdiction to have committed fraud or breach offiduciary duty, or is the subject of a judicial determination that ICANNreasonably deems as the substantive equivalent of any of the foregoing and such officer is not terminated within thirty (30) days of Registrar’sknowledge 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 ajudicial determination that ICANN reasonably deems as the substantiveequivalent 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 itsobligations 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 arecommenced 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 ormaintains control over any of Registrar’s property; (iv) execution is leviedupon any property of Registrar, (v) proceedings are instituted by or against Registrar under any bankruptcy, insolvency, reorganization or other lawsrelating to the relief of debtors and such proceedings are not dismissedwithin thirty (30) days of their commencement, or (vi) Registrar files forprotection under the United States Bankruptcy Code, 11 U.S.C. Section 101 etseq., 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) dayswritten notice to Registrar (in the case of Subsection 5.5.4 occurring afterRegistrar's failure to cure), with Registrar being given an opportunity during that time to initiate arbitration under Subsection 5.8 to determine the appropriatenessof termination under this Agreement. This Agreement maybe terminatedimmediately 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 noticepursuant to Subsection 5.7.2, elect to suspend Registrar’s ability to create orsponsor new Registered Names or initiate inbound transfers of Registered Names for any or allgTLDs for a period of up to a twelve (12) monthsfollowing the effectiveness of such suspension. Suspension of a Registrar does not preclude ICANN’s ability to issue a notice of termination inaccordance 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 anopportunity 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 determinesendangers the stability or operational integrity of the Internet and uponnotice does not immediately cure, ICANN may suspend this Agreement for five (5) working dayspending ICANN's application for more extendedspecific 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 toRegistrar and (ii) creating or sponsoring new Registered Names or initiating inbound transfers of Registered Names for any gTLDs. Registrar must alsopost the statement specified in Subsection 5.7.3.5.8 Resolution of Disputes Under this Agreement. Subject to the limitations setforth 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 arbitrationconducted as provided in this Subsection 5.8 pursuant to the InternationalArbitration 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 theparties from a list of AAA arbitrators, or if parties do not agree on an arbitratorwithin 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 equalshares, 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 inconnection 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. Thearbitration panelshall order a stay: (i) upon showing by Registrar that continuedoperations would not be harmful to consumers or the public interest, or (ii) uponappointment by the arbitration panel of a qualified third party to manage theoperations of the Registrar until the arbitration decision is rendered. In furtherance of sub-clause (ii) above, the arbitration panel is hereby granted all necessaryauthority to appoint a qualified third-party to manage the operations of theRegistrar upon the Registrar’s request and if the panel deems it appropriate. Inselecting the third-party manager, the arbitration panelshall take intoconsideration, 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 thetermination of this Agreement pursuant to Section 5.5 or suspension of theRegistrar 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 issupported by consensus, Registrar may at the sametime request that the arbitration panel stay the requirement that it comply with the policy until the arbitrationdecision is rendered, and that requestshall have the effect of staying therequirement until the decision or until the arbitration panel has granted an ICANN request for lifting of the stay. In all litigation involving ICANN concerning thisAgreement (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 competentjurisdiction. 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 thisarbitration agreement.5.9 Limitations on Monetary Remedies for Violations of this Agreement. ICANN's aggregate monetary liability for violations of this Agreementshall not exceed anamount equal to the Accreditation fees paid by Registrar to ICANN under Subsection 3.9 of this Agreement during the preceding twelve-month period. Registrar'smonetary liability to ICANN for violations of this Agreementshall be limited toAccreditation 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 toenforce Registrar compliance with this agreement and costs incurred by ICANN torespond to or mitigate the negative consequences of such behavior for RegisteredName 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 beliable for special, indirect, incidental, punitive, exemplary, or consequential damages for any violation of this Agreement. 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 suchSpecifications expressly do not permit amendment thereto) and all other registrar agreements between ICANN and the Applicable Registrars (the “ApplicableRegistrar Agreements”) is desirable (each, a “Special Amendment”), ICANN mayadopt 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 RestrictedAmendment.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 reasonablydetermined by ICANN based on the substance of the Special Amendment. Following such consultation, ICANN may propose the adoption of a Special Amendment bypublicly posting such amendment on its website for no less than thirty (30) calendar days (the “Posting Period”) and providing notice of such proposed amendment tothe 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 publiccomment, but must address the subject matter of the Special Amendment posted for public comment, as modified to reflect and/or address input from the WorkingGroup and public comments), ICANN shall provide notice of, and submit, suchSpecial 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 RegistrarApproval, such Special Amendmentshall be deemed approved (an “ApprovedAmendment”) by the Applicable Registrars, and shall be effective and deemed anamendment 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 toRegistrar (the “Amendment Effective Date”). In the event that a Special Amendment does not receive Registrar Approval, the Special Amendmentshall be deemed notapproved 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 RejectedAmendment falls within the subject matter categories set forth in Section 1.2 of the Consensus Policies and Temporary Policies Specification, the ICANN Board ofDirectors 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 policydevelopment 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 Reportsupported 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, Registrarshallcomply 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 periodpreceding 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 PoliciesSpecification , (ii) the subject matter of a Rejected Amendment was, at anytime in the twelve (12) month period preceding the submission of such RejectedAmendment for Registrar Approval pursuant to Section 6.3, the subject of aconcluded 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 Reportsupported by a GNSO Supermajority that either (a) recommends adoption of the Rejected Amendment as Consensus Policy or (b) recommends against adoption ofthe 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 followingrequirements 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 andCompelling Reason in the Public Interest, must be likely to promote suchinterest, taking into account competing public and private interests that arelikely to be affected by the Rejected Amendment, and must be narrowly tailored and no broader than reasonably necessary to address suchSubstantial 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/ormaterially 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; and6.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 theRejected Amendment (which maybe in a form different than submitted forRegistrar Approval, but must address the subject matter of the RejectedAmendment, as modified to reflect and/or address input from the WorkingGroup 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, includingICANN’s Conflict of Interest Policy (a “Board Amendment”).Such Board Amendmentshall, subject to Section 6.6, be deemed an ApprovedAmendment, 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 bedeemed 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 ICANNBoard 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 PublicInterest identified by the ICANN Board of Directors as the justification for the Board Amendment; and6.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 conductoractivities, 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 anAlternative Amendment hereunder and therefore shall not supersede or delay the effectiveness of the Board Amendment. If, following the submission of theAlternative Amendment to the ICANN Board of Directors, the AlternativeAmendment receives Registrar Approval, the Alternative Amendmentshallsupersede 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 ICANNBoard of Directors of Registrar Approval of such Alternative Amendment (duringwhich time ICANN shall engage with the Working Group with respect to theAlternative 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 dateshall deemed the Amendment Effective Date hereunder). If the ICANN Board ofDirectors rejects an Alternative Amendment, the boardshall publish a writtenrationale 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 AlternativeAmendment 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 incontravention of any of the procedural provisions of this Section 6,Registrar may challenge the adoption of such Special Amendment pursuant to the disputeresolution provisions set forth in Section 5.8, except that such arbitration shall beconducted by a three-person arbitration panel. Any such challenge must be broughtwithin sixty (60) calendar days following the date ICANN provided notice toRegistrar 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 thependency 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 ICANNprovided 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 ApprovedAmendment conflicts with applicable laws or would have a material adverse effect on the long-term financial condition or results of operations ofRegistrar. No Exemption Request will be granted if ICANN determines, in its reasonable discretion, that granting such Exemption Request would bematerially 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 denythe 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 ApprovedAmendment 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 byICANN, 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 daysfollowing receipt of ICANN’s determination, appeal ICANN’s decision to deny the Exemption Request pursuant to the dispute resolution procedures setforth 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. Foravoidance of doubt, only Exemption Requests submitted by Registrar that are approved by ICANN pursuant to this Article 6 or through an arbitrationdecision pursuant to Section 5.8 shall exempt Registrar from any Approved Amendment, and no Exemption Request granted to any other ApplicableRegistrar (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, noamendment, supplement or modification of this Agreement or any provision hereof shall be binding unless executed in writing by both parties, and nothing in thisSection 6 or Section 7.4 shall restrict ICANN and Registrar from entering intobilateral amendments and modifications to this Agreement negotiated solelybetween the two parties. No waiver of any provision of this Agreementshall bebinding 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 thisSection 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 ApprovedAmendment would materially increase the cost of providing Registrar Services, then ICANN will allow up to one-hundred eighty (180) calendar days for the ApprovedAmendment 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. 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 fromtime to time provide Registrar with a revised specification of such purposes andconditions, which specificationshall become effective no fewer than thirty (30) days after it is provided to Registrar. ICANN shall not use Personal Data provided byRegistrar 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 ortransfer 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 “AssignmentRequest”) of this Agreement by Registrar within thirty (30) calendar days ofICANN’s receipt of notice of such Assignment Request (or, if ICANN hasrequested 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 deemedto have consented to such requested assignment. Notwithstanding theforegoing, (i) ICANN may assign this Agreement without the consent ofRegistrar upon approval of the ICANN Board of Directors in conjunction with areorganization, reconstitution or re-incorporation of ICANN upon suchassignee’s express assumption of the terms and conditions of this Agreement, (ii) Registrar may assign this Agreement without the consent of ICANN to awholly-owned subsidiary of Registrar upon such subsidiary’s expressassumption of the terms and conditions of this Agreement, and (iii) ICANNshall be deemed to have consented to an Assignment Request in which theassignee associated with such Assignment Request is a party to a RegistrarAccreditation Agreement with ICANN on the terms set forth in this Agreement (provided that such assignee is then in compliance with the terms andconditions of such Registrar Accreditation Agreement in all materialrespects), 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 inRegistrar’s stock, assets or business, Registrarshall provide ICANN noticewithin seven (7) days of such an acquisition. Such notificationshall include a statement that affirms that Registrar meets the Specification or Policy onAccreditation 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 compliancewith 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 theChairperson of the Registrar Stakeholder Group (“Chair”) desires to discussany revision(s) to this Agreement, the CEO or Chair, as applicable, shallprovide 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 orbefore 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 thisAgreement, which shall be in the form of a proposed amendment to thisAgreement (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 agreedProposed 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 theWorking Group will consider the public comments submitted on the Proposed Revisions during the Posting Period (including comments submitted by theApplicable 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, theProposed Revisions shall be deemed an Approved Amendment by theApplicable Registrars and ICANN, and shall be effective and deemed anamendment 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 ProposedRevisions, 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 andconditions 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 ProposedRevisions and a position paper with respect thereto on ICANN’swebsite.7.4.4.1 The mediation shall be conducted by a single mediatorselected by the parties. If the parties cannot agree on a mediatorwithin fifteen (15) calendar days following receipt by the CEO orChair, 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 generalknowledge 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 anApplicable Registrar. If such confirmation is not provided by theappointed 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 accordancewith 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, ICANNshall 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 willconsider the public comments submitted on the agreed ProposedRevisions 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 RegistrarApproval and approval by the ICANN Board of Directors. If suchapprovals 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 mediationshall 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 notreached 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’swebsite for a period of no less than thirty (30) calendar days. ICANNand the Working Group will consider the public comments submitted on the Proposed Revisions during the Posting Period (includingcomments submitted by the Applicable Registrars),and informationregarding 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 publiccomment 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 conductedpursuant to Section 5.8.7.4.5.2 No dispute regarding the Proposed Revisions maybesubmitted for arbitration to the extent the subject matter of theProposed Revisions (i) relates to Consensus Policy, (ii) falls within the subject matter categories set forth in Section 1.2 of the ConsensusPolicies 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 regardingICANN 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 WorkingGroup or ICANN,unless, in the case of the Working Group, theproposed 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 proposedamendment 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 theApplicable Registrars and ICANN (as applicable), and the publicbenefit sought to be achieved by the Proposed Revisions asset forth in such amendment. If the arbitrator panel concludes that eitherICANN 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 anexemption 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) ifRegistrar provides evidence to ICANN’s reasonable satisfaction that theApproved Amendment would materially increase the cost of providingRegistrar 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 Section7.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 ofchange 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 inperson, 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 newSpecification 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 ICANNwebsite in which to comply with that specification, policy or program, taking into account any urgency involved. Notices and designations by ICANN under thisAgreementshall be effective when written notice ofthem is deemed given to Registrar.If to ICANN, addressed to:Attention: Registrar Accreditation NoticesInternet Corporation for Assigned Names and Numbers12025 Waterfront Drive, Suite 300Los Angeles, California 90094-2536 USA Telephone: +1 310 823-9358Facsimile: +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 itsperformanceshall 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 writtenagreement executed by both parties concurrently herewith or (b) of writtenassurances 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 beunenforceable under applicable law, the parties agree to renegotiate such provision in good faith. In the event that the parties cannot reach a mutually agreeable andenforceable replacement for such provision, then (a) such provisionshall beexcluded from this Agreement; (b) the balance of this Agreementshall beinterpreted 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 byICANN and the Registrar Stakeholder Group during the Term of the Registrar Accreditation Agreement. Except as provided for in Section 3 below, within fifteen (15) days of (1) theregistration of a Registered Name sponsored by Registrar, (2) the transfer of thesponsorship of a Registered Name to Registrar, or (3) any change in the RegisteredName 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 orsuccessors).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 S42address 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 applicablecountry 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, orii.the telephone number of the Registered Name Holder (and, if different,the Account Holder) by either (A) calling or sending an SMS to theRegistered Name Holder’s telephone number providing a unique codethat must be returned in a manner designated by the Registrar, or (B)calling the Registered Name Holder’s telephone number and requiringthe 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 contactinformation manually or suspend the registration, until such time asRegistrar has verified the applicable contact information. If Registrar doesnot receive an affirmative response from the Account Holder, Registrarshall verify the applicable contact information manually, but is not required tosuspend any registration. 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 accountcontact information related to any Registered Name sponsored by Registrar (whetheror not Registrar was previously required to perform the validation and verificationrequirements 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. 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 Registrarhas already successfully completed the validation and verification procedures on the identical contact information and is not in possession of facts or knowledge ofcircumstances that suggest that the information is no longer valid. If Registrar has any information suggesting that the contact information specified inSection 1(a) through 1(f) above is incorrect (such as Registrar receiving a bouncedemail notification or non-delivery notification message in connection with compliance with ICANN’s Whois Data Reminder Policy or otherwise) for any Registered Namesponsored 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 emailaddress(es) as described in Section 1.f (for example by requiring an affirmativeresponse 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, Registrarshalleither 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 notreceive 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. Upon the occurrence of a Registered Name Holder's willful provision of inaccurate orunreliable WHOIS information, its willful failure promptly to update informationprovided to Registrar, or its failure to respond for over fifteen (15) calendar days toinquiries by Registrar concerning the accuracy of contact details associated with theRegistered Name Holder's registration, Registrarshall either terminate or suspend the Registered Name Holder’s Registered Name or place such registration on clientHoldand clientTransferProhibited, until such time as Registrar has validated the information provided by the Registered Name Holder. The terms and conditions of this Specificationshall be reviewed by ICANN inconsultation 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. Nothing within this Specificationshall be deemed to require Registrar to performverification or validation of any customer account holder information where thecustomer 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 byICANN and the Registrar Stakeholder Group during the Term of the Registrar Accreditation Agreement. Except as provided for in Section 3 below, within fifteen (15) days of (1) theregistration of a Registered Name sponsored by Registrar, (2) the transfer of thesponsorship of a Registered Name to Registrar, or (3) any change in the RegisteredName 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 orsuccessors).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 S42address 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 applicablecountry 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, orii.the telephone number of the Registered Name Holder (and, if different,the Account Holder) by either (A) calling or sending an SMS to theRegistered Name Holder’s telephone number providing a unique codethat must be returned in a manner designated by the Registrar, or (B)calling the Registered Name Holder’s telephone number and requiringthe 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 asRegistrar has verified the applicable contact information. If Registrar doesnot receive an affirmative response from the Account Holder), Registrarshall verify the applicable contact information manually, but is not required tosuspend any registration. 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 accountcontact information related to any Registered Name sponsored by Registrar (whetheror not Registrar was previously required to perform the validation and verificationrequirements 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. 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 Registrarhas already successfully completed the validation and verification procedures on the identical contact information and is not in possession of facts or knowledge ofcircumstances that suggest that the information is no longer valid. If Registrar has any information suggesting that the contact information specified inSection 1(a) through 1(f) above is incorrect (such as Registrar receiving a bouncedemail notification or non-delivery notification message in connection with compliance with ICANN’s Whois Data Reminder Policy or otherwise) for any Registered Namesponsored 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 emailaddress(es) as described in Section 1.f (for example by requiring an affirmativeresponse 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, Registrarshalleither 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 notreceive 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. Upon the occurrence of a Registered Name Holder's willful provision of inaccurate orunreliable WHOIS information, its willful failure promptly to update informationprovided to Registrar, or its failure to respond for over fifteen (15) calendar days toinquiries by Registrar concerning the accuracy of contact details associated with theRegistered Name Holder's registration, Registrarshall either terminate or suspend the Registered Name Holder’s Registered Name or place such registration on clientHoldand clientTransferProhibited, until such time as Registrar has validated the information provided by the Registered Name Holder. The terms and conditions of this Specificationshall be reviewed by ICANN inconsultation 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. Nothing within this Specificationshall be deemed to require Registrar to performverification or validation of any customer account holder information where thecustomer account holder does not have any Registered Names under sponsorship of Registrar. REGISTRATION DATA DIRECTORY SERVICE (WHOIS) SPECIFICATION Registration Data Directory Services. Until ICANN requires a differentprotocol, Registrar will operate a WHOIS service available via port 43 inaccordance with RFC 3912, and a web-based Directory Service providing freepublic query-based access to at least the elements set forth in Section 3.3.1.1through 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 specifyalternative 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 ExtensibleInternet Registration Data Service working group, Registrarshall implement the directory service specified in any such standard (or any revision thereto) nolater than 135 days after such implementation is requested by ICANN. Registrar shall implement internationalized registration data publication guidelinesaccording 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 ofRegistrar, 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, befollowed 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.TLDRegistry Domain ID: D1234567-TLDRegistrar WHOIS Server: whois.example-registrar.tld Registrar URL:http://www.example-registrar.tldUpdated Date: 2009-05-29T20:13:00Z Creation Date: 2000-10-08T00:45:00ZRegistrar Registration Expiration Date: 2010-10-08T00:44:59ZRegistrar: EXAMPLE REGISTRAR LLC Registrar IANA ID: 5555555Registrar Abuse Contact Email:email@registrar.tld Registrar Abuse Contact Phone:+1.1235551234Reseller: EXAMPLE RESELLER1Domain Status: clientDeleteProhibited2Domain Status: clientRenewProhibitedDomain Status: clientTransferProhibited Registry Registrant ID: 5372808-ERL3Registrant Name: EXAMPLE REGISTRANT4Registrant Organization: EXAMPLE ORGANIZATION Registrant Street: 123 EXAMPLE STREETRegistrant City: ANYTOWNRegistrant State/Province: AP5 Registrant Postal Code: A1A1A16 Registrant Country: AARegistrant Phone: +1.5555551212 Registrant Phone Ext: 12347Registrant Fax: +1.5555551213 Registrant Fax Ext: 4321Registrant 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 ADMINISTRATIVEAdmin Organization: EXAMPLE REGISTRANT ORGANIZATION Admin Street: 123 EXAMPLE STREETAdmin City: ANYTOWNAdmin State/Province: AP Admin Postal Code: A1A1A1 Admin Country: AAAdmin Phone: +1.5555551212Admin Phone Ext: 1234Admin Fax: +1.5555551213 Admin Fax Ext: 1234Admin Email:EMAIL@EXAMPLE.TLD Registry Tech ID: 5372811-ERL9Tech Name: EXAMPLE REGISTRANT TECHNICAL Tech Organization: EXAMPLE REGISTRANT LLC Tech Street: 123 EXAMPLE STREETTech City: ANYTOWNTech State/Province: AP Tech Postal Code: A1A1A1 Tech Country: AATech Phone: +1.1235551234Tech Phone Ext: 1234Tech Fax: +1.5555551213 Tech Fax Ext: 93Tech Email:EMAIL@EXAMPLE.TLDName Server: NS01.EXAMPLE-REGISTRAR.TLD10 Name Server: NS02.EXAMPLE-REGISTRAR.TLDDNSSEC: signedDelegationURL 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 andorganizational 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 itssuccessors),and IPv6 addresses format should conform to RFC 5952 (or its successor), so that the display of this information (or values returned inWHOIS responses) can be uniformly processed and understood. 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 isused.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 sequenceneeded to receive the response. If the client does not receive the wholesequence 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 downtimeRDDS query RTT less than or equal to 4000 ms, for at least 95% of the queriesRDDS 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 timesand dates of statistically lower traffic for each service. Since substantial downtime is already incorporated in the availability metric, planned outages or similar; anydowntime, 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 theRegistrar to respond to queries from an Internet user with appropriate data from the relevant registrar system. If 51% or more of the RDDS testingprobes 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 Registrarimplements a multiple-step process to get to the information, only the laststepshall 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 theservers of one of the RDDS services. Queries shall be about existing objects in the registrar system and the responses must contain the correspondinginformation otherwise the query will be considered unanswered. Querieswith an RTT 5 times higher than the corresponding SLR will be considered as unanswered. The possible results to an RDDS test are: anumber inmilliseconds corresponding to the RTT orundefined/unanswered.2.2.7 Measuring RDDS parameters. Every 5 minutes, RDDS probes will selectone IP address from all the public-DNS registered “IP addresses” of theservers 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 activetesting probes to consider a measurement valid is 10 at any givenmeasurement period, otherwise the measurements will be discarded and will be considered inconclusive; during this situation no fault will be flaggedagainst 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 differentgeographic regions; care shall betaken not to deploy probes behind high propagation-delay links, such as satellite links.2.3 Covenants of Performance MeasurementRegistrarshall not interfere with measurement Probes, including any form ofpreferential treatment of the requests for the monitored services. Registrarshallrespond 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 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 thisdocument. 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 tofacilitate 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 toagTLD 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); or1.2.5. restrictions on cross-ownership of registry operators and registrars or Resellers and regulations and restrictions with respect to registrar and registry operations andthe 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 orregistrars;1.3.3. reservation of registered names in a TLD that may not be registered initially or thatmay not be renewed due to reasons reasonably related to (i) avoidance of confusion among or misleading of users, (ii) intellectual property, or (iii) the technicalmanagement 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 concerningRegistered 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; and1.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; or1.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 itsresponsibilities in an open and transparent manner. 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 reasonablydetermines 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 ("TemporaryPolicies").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 theConsensus 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 suchTemporary 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 toexceed 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 notreaffirmed by the Board, Registrarshall no longer be required to comply with or implement such Temporary Policy. 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 suchpolicy or specification, taking into account any urgency involved. In the event of a conflictbetween Registrar Services and Consensus Policies or any Temporary Policy, the ConsensusPolices 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 and1.3 of this Specification. SPECIFICATION ON PRIVACY AND PROXY REGISTRATIONSUntil the earlier to occur of (i) January 1, 2017, and (ii) the date ICANN establishesand implements a Privacy and Proxy Accreditation Program as referenced in Section 3.14 of the Registrar Accreditation Agreement, Registrar agrees to comply, and torequire 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. 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 whichalternative, 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 Holderlicenses use of a Registered Name to the P/P Customer in order toprovide 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. 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 withRegistered 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/orRegistrar’swebsite. 2.2 Abuse/Infringement Point of Contact. P/P Providershall publish a point of contact for third parties wishing to report abuse orinfringement of trademarks (or other rights).2.3 Disclosure of Identity of P/P Provider. P/P Providershall publish itsbusiness 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/PProvider 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 nameregistration managed by the P/P Provider;2.4.2 The processor facilities to report infringement of trademarks orother rights of third parties;2.4.3 The circumstances under which the P/P Provider will relaycommunications from third parties to the P/P Customer;2.4.4 The circumstances under which the P/P Provider will terminateservice to the P/P Customer;2.4.5 The circumstances under which the P/P Provider will revealand/or publish in the Registration Data Service (Whois) orequivalent service the P/P Customer’sidentity and/orcontact data; and2.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/PCustomer 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. 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; or3.3 Registered Name Holder has used P/P Provider contact data without subscribing to the service or accepting the P/P Provider terms andconditions. DATA RETENTION SPECIFICATION During the Term of this Agreement, for each Registered Name sponsored byRegistrar 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 thetime of registration of a domain name (a “Registration”) and shall maintain that information for the duration of Registrar’s sponsorship of theRegistration 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, thetitle of the registrant’s administrative contact, technical contact, and billing contact;1.1.3. Postal address of registrant, administrative contact, technicalcontact, and billing contact;1.1.4. Email address of registrant, administrative contact, technicalcontact, and billing contact;1.1.5. Telephone contact for registrant, administrative contact, technicalcontact, 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 connectionwith the Registration; and1.1.8. To the extent collected by Registrar, “card on file,” current periodthird party transaction number, or other recurring payment data.1.2. Registrarshall collect the following information and maintain thatinformation for no less than one hundred and eighty (180) days following the relevant interaction:1.2.1. Information regarding the means and source of paymentreasonably necessary for the Registrar to process the Registration transaction, or a transaction number provided by a third partypayment processor;1.2.2. Log files, billing records and, to the extent collection andmaintenance of such records is commercially practicable orconsistent with industry-wide generally accepted standardpractices within the industries in which Registrar operates, other records containing communications source and destinationinformation, 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 withcommunications between Registrar and the registrant about the Registration; and1.2.3. Log files and, to the extent collection and maintenance of suchrecords is commercially practicable or consistent with industry-wide generally accepted standard practices within the industries inwhich Registrar operates, other records associated with the Registration containing dates, times, and timezones ofcommunications and sessions, including initialregistration. If, based on the receipt of either (i) a written legal opinion from a nationallyrecognized law firmin the applicable jurisdiction that states that the collectionand/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 writtenguidance from, a governmental body of competent jurisdiction providing thatcompliance with the data collection and/or retention requirements of thisSpecification violates applicable law, Registrar determines in good faith that the collection and/or retention of any data element specified in this Specificationviolates applicable law, Registrar may provide written notice of suchdetermination to ICANN and request a waiver from compliance with specificterms and conditions of this Specification (a “Waiver Request”). Such writtennoticeshall: (i) specify the relevant applicable law, the allegedly offending datacollection and retention elements, the manner in which the collection and/orretention of such data violates applicable law, and a reasonable description ofsuch determination and any other facts and circumstances related thereto, (ii) be accompanied by a copy of the Opinion and governmental ruling or guidance, asapplicable, 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. Followingreceipt 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 suchtime as ICANN’s Procedure for Handling Whois Conflicts with Privacy Law ismodified to include conflicts relating to the requirements of this Specificationand if ICANN agrees with Registrar’s determination, ICANN's office of generalcounsel 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 suchmodification of ICANN’s Procedure for Handling Whois Conflicts with Privacy Law, all Waiver Requests (whether granted or denied) shall be resolvedpursuant to such modified procedures. If (i) ICANN has previously waived compliance with the requirements of anyrequirement of this Data Retention Specification in response to a WaiverRequest 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’sagreement to grant such waiver, Registrar may request that ICANN to grant a similar waiver, which requestshall be approved by ICANN, unless ICANNprovides 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. Any modification of this Data Retention Specification to address violations ofapplicable lawshall only apply during the period of time that the specificprovisions 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 thatwould 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 extentpermitted by such modified applicable law. REGISTRAR INFORMATION SPECIFICATIONRegistrarshall provide to ICANN the information specified below, which shall be maintained in accordance with Section 3.17 of the Agreement. With regard toinformation identified below, ICANN will hold such information pursuant to the disclosure requirements set forth in Section 3.15 of the Agreement.General Information Full legal name of Registrar. Legal form of the Registrar (e.g., LLC, Corporation, Government Body, Intergovernmental Organization, etc.). The jurisdiction in which the Registrar’s business is registered for legal and financial purposes. The Registrar’s business registration number and the name of the authority that issued this number. Every business name and/or trade name used by the Registrar. Provide current documentation demonstrating that the Registrar entity islegally established and in good standing. For proof of establishment, provide charter documents or other equivalent document (e.g., membership agreement) of theentity. If the Registrar is a government body or organization, provide a certifiedcopy of the relevant statute, governmental decision or other instrument underwhich 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 goodstanding, must be provided. Correspondence address for the Registrar.* This address will be used forcontractual purposes, and the Registrar must be able to accept notices and service of legal process at this address. No Post Office boxes are allowed. Primary phone number where the Registrar can be reached for contractual purposes. Primary Fax number where the Registrar can be reached for contractual purposes. Primary Email address where the Registrar can be reached for contractual purposes. 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 documentationdemonstrating that the Registrar is legally entitled to do business in the principal place of business. Any other addresses where the Registrar will be operated or managed, ifdifferent from either its principal place of business or correspondence addressprovided above. (If so, please explain.) Provide ICANN with current documentation demonstrating that the Registrar is legally entitled to do business in each location identified. Primary contact name:TitleAddressPhone number Fax numberEmail address URL and Location of Port 43 WHOIS server.Ownership, Directors and Officers Information 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. Full name, contact information, and position of all directors of the Registrar. Full name, contact information, and position of all officers of the Registrar.* (Officer names and positions must be publicly displayed.) Full name, contact information, and position of all senior management and other key personnel overseeing the provision of Registrar Services. 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 amisdemeanor 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 orindustry regulatory body for conduct involving dishonesty or misuse of fundsof others; c) is currently involved in any judicial or regulatory proceeding that could result in a conviction, judgment, determination, or discipline of the typespecified in items 19(a) or 19(b); ord) is the subject of a disqualification imposed by ICANN.Provide details if any of the above events in (a)-(d) have occurred. List all Affiliated Registrars, if any, and briefly describe the Affiliation. For any entities listed in item 20, must provide information required in items 1-14 above. List the ultimate parent entity of the Registrar, if applicable.*Other Does the Registrar or any of its Affiliates offer any Privacy Service or ProxyService (as such terms on defined in the Specification on Privacy and ProxyRegistrations)? If yes, list the entities or individuals providing the Privacy Service or Proxy Service. For any entities listed in item 23, provide information required in 1-14 above. Does the Registrar utilize or benefit from the services of Resellers? 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 suchtime as ICANN develops a secure method for the receipt and retention of suchinformation, such information shall thereafter be provided to ICANN in accordancewith 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. 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 DSresource 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 anddigest 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 EPPextensions specified in RFC 5910 or its successors. 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. IDN If the Registrar offers Internationalized Domain Name (“IDN”) registrations, all new registrations must comply with RFCs 5890, 5891, 5892, 5893 and theirsuccessors. Registrarshall also comply with the IDN Guidelines athttp://www.icann.org/en/topics/idn/implementation-guidelines.htmwhichmaybe 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: 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. 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 nameregistrations, including through any proxy or privacy services made available by your Registrar. You shall not be subject to false advertising or deceptive practices by yourRegistrar or though any proxy or privacy services made available by yourRegistrar. This includes deceptive notices, hidden fees, and any practices that are illegal under the consumer protection law of your residence. Domain Name Registrants’ Responsibilities: You must comply with the terms and conditions posted by your Registrar, including applicable policies from your Registrar, the Registry and ICANN. You must review your Registrar’s current Registration Agreement, along with any updates. You will assume sole responsibility for the registration and use of your domain name. You must provide accurate information for publication in directories such as WHOIS, and promptly update this to reflect any changes. 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 domainname 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天通过一次临时政策,总期间不超过一年,以保持该临时政策有 效,直到其成为协商一致政策为止。如一年期间届满,或在该一年期间,临时政策 未成为共识政策,并未得到董事会的重申,则注册主任将不再被要求遵守或执行该 临时政策。 通知 和 冲突。注册官应在收到建立协商一致政策或临时政策的通知后,向其提供一段合理的 时间,并考虑到所涉及的任何紧急情况。如果注册服务与一致政策或任何临时政策之间存在冲突,则一致政策或临时政策应控制,但仅涉及冲突的主题。为免生疑问,符合本规范要求 的协商一致政策可补充或取代注册官与ICANN之间协议的规定,但仅在该等协商一致政策与第1.2条中规定的事项和 本规范的1.3。 关于隐私和代理注册的规范 在(i)2017年1月1日和(ii)ICANN建立并实施注册商认证协议第3.14节中引用的 隐私和代理认证计划的日期之前,注册商同意遵守,并要求其关联方和分销商遵 守本规范的条款,前提是ICANN和工作组可以共同同意延长本规范的期限。本规范 不得由ICANN或注册官修改。 定义。对于本规范而言,应适用以下定义。 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)天内回复您的注册人员的查询,并保持您的注册人员帐户 数据的最新状态。如果您选择让您的域名注册自动更新,您还必须保持您的 支付信息的最新状态。
实现企业总分部大型网络互联互通
1. 背景 随公司的发展规模不断扩大,为提高办公效率,提升企业管理水平,往往需要搭建各类项目管理系统软件(如OA、财务系统、ERP等)进行运作管理,但由于公司分部在不同地区,大都没有真实公网IP,总部与各分部间的互联互通往往需要依靠到第三方软件来实现,且总部网络规则设置太多,网络较为复杂,部署与维护也成为了难题。 2. 实施难点 1.总分部位于不同地区,且宽带网络不同; 2.传统联网方案需要借用第三方软件实现; 3.环境限制不能改变两地原有的网络结构; 4.部署维护难度大,安全性稳定性无保障。 3. 解决方案 蒲公英路由器是由贝锐自主研发的一款智能组网路由器,能够实现在不改变原有网络结构的前提下,实现公司两地的网络互联。 在总部和分部的一级路由下连接蒲公英路由器,搭配蒲公英旁路设置功能,即可实现两端设备相互通信。下面来看看详细操作步骤。 4. 操作步骤 4.1 登录云管理平台 1、各点蒲公英路由器接线,并进入本地管理页面配置对应上网方式,使其正常联网。 接着在浏览器访问地址https://pgybox.oray.com 登录蒲公英云管理平台,输入总部蒲公英路由器的SN码(路由器背面可查看)及默认密码(admin)登录。 2、蒲公英路由器首次使用需要初始化操作,即更改路由器的初始管理密码。点击“提交”按钮即可。 4.2 绑定贝锐账号 (1)初次登录云管理平台,需先绑定贝锐账号。 (2)绑定账号后,点击【智能组网】->【成员列表】->【我要组网】,跳转至蒲公英管理平台进行组网。 4.3 创建智能组网 【点击查看智能组网教程】 4.4 设置旁路路由 组网创建完成后,选择【网络设置】-【旁路设置】,点击“添加旁路”。 添加旁路路由: 选项 描述 选择旁路路由 选择总部下面的蒲公英路由器为旁路路由 目标类型 IP网络段 目标地址 192.168.1.0。总部蒲公英上层服务器网段 子网掩码 255.255.255.0,若子网掩码的位数不是24位,请根据实际情况填写正确的) 生效对象 生效的网络组/成员 释义:给网络中的成员定义规则,当访问设置的目标地址段时,找对应的蒲公英路由器。 继续添加旁路路由,目标地址是分部路由器的上层设备。添加完成如下图: 上面添加的两条旁路路由,目的是分别实现: 1、分部蒲公英能访问总部的一级路由下的设备; 2、总部蒲公英能访问分部一级路由下的设备。 4.5 设置静态路由 1、登录到总部的一级路由器管理页面,进行静态路由设置,如下图: 选项 描述 目标地址 192.168.2.0(分部一级路由器网段) 子网掩码 255.255.255.0 下一跳(接口) 192.168.1.2(总部二级蒲公英路由器的WAN口IP) 2、登录到分部的一级路由器管理页面,进行静态路由设置,如下图: 选项 描述 目标地址 192.168.1.0(总部一级路由器网段) 子网掩码 255.255.255.0 下一跳(接口) 192.168.2.2(分部二级蒲公英路由器的WAN口IP) 注意:两端蒲公英路由器建议设置静态绑定IP上网。 4.6 开启WAN口转发 将总部和分部蒲公英路由器的WAN口转发功能开启,蒲公英的上级路由成员才能访问到蒲公英组网。 4.7 Ping测试 通过ping测的方式,在分部一级路由下的电脑ping下总部一级路由下的服务器IP地址。 5. 方案优点 1.在不改变总部网络环境下,实现据跨网络传输、跨地区通信; 2.可靠性,单个节点故障,不影响其它分点连接; 3.无限并发数,具有很强的灵活性和可扩展性; 4.部署操作简单,维护难度大大降低。
公司文件共享解决方案
1. 应用背景 企业的日常办公中已经习惯利用网盘或在线传输服务来进行文件传输和分享,面对一系列层出不穷的数据泄露和黑客行为,企业也越来越担心隐私泄露的问题,并寻找真正存储私有化的解决方案。 2. 实施难点 (1)要保证文件共享服务器与家里电脑互联互通的过程是安全的; (2)保证每个用户访问文件的权限在一定范围内; (3)网络连接的速度各方面需要达到理想效果。 3. 方案设计 3.1 产品清单 蒲公英企业访问端 3.2 方案优点 方案采用客户端软件组网方式实现分支机构与总部互联,轻松打造企业私有云。 (1)灵活的部署方式,具备高扩展性,满足任意规模企业增删除成员的要求; (2)安全性高,信息数据资源共享是企业发展和趋势必然要求,在企业内部搭建共享文件,蒲公英智能组网提供强大的服务器群支持组网环境,并采用银行级别的非对称RSA/AES算法加密; (3)数据传输速度快,蒲公英组网支持多种数据传输模式,点对点、自动转发、强制转发,企业和分支机构组网后,跨地域跨宽带也能无障碍高速传输。 4. 解决方案 4.1 产品清单 ①蒲公英企业访问端,点击下载; ②蒲公英服务器端,点击下载; 4.2 方案部署 (1)进入蒲公英网络管理平台 ,输入贝锐账号(如未注册账号点击注册)登录。 (2)【点击查看智能组网教程】 (3)添加成功后,组网列表会自动生成软件成员的UID和SID信息。(SID是服务器端登录使用); (4)共享文件服务器上安装蒲公英服务器端,并使用软件成员的SID和设置的登录密码进行登录(下载地址); (5)在网络资源中设置相应的文件共享访问地址; 设置路径:【网络成员】-【基础设置】-【基本信息】-【网络资源】; (6)在windows电脑中安装蒲公英企业版访问端并登录,即可在网络资源中查看到共享的文件夹。 5. 用户体验 在未使用蒲公英实现文件共享前,异地办公室,居家办公人员无法从外网访问公司内部的共享文件服务器,不能上传下载服务器数据,经过网盘或邮件中转方式还有可能导致重要信息丢失。 使用蒲公英搭建文件共享后,很好地解决了异地文件重要文档资料的安全传输问题,并增加了居家办公人员访问共享文件的应用,防止了重要文件在微信QQ等互联网工具上传播。 总体来说,蒲公英组网方案实现文件共享,可以让企业获得以下的好处: (1)在内网整合现有的设施和系统进行部署,避免重复建设,无需按照传统结构投入大量的冗余资源; (2)简单化的组网步骤,运维人员可轻松掌握,帮助企业化繁为简,专注核心业务; (3)前期部署按实际需求采购软件资源,后期灵活增加新成员对原网络不造成影响,具备高扩展性和灵活性。
总部旁路,分部一级组网方案
1. 应用场景 随公司的发展规模不断扩大,为提高办公效率,提升企业管理水平,往往需要搭建各类项目管理系统软件(如OA、财务系统、ERP等)进行运作管理,但由于公司分部在不同地区,大都没有真实公网IP,总部与各分部间的互联互通往往需要依靠到第三方软件来实现,且总部网络规则设置太多,网络较为复杂,部署与维护也成为了难题。 2. 实施难点 1、都在不同地区,处于不同网络; 2、联机需要借用第三方软件实现; 3、总部网络结构复杂; 4、部署维护难度大,稳定性低。 3. 解决方案 3.1 产品清单 蒲公英路由器X3 3.2 方案部署 在总部交换机下接上蒲公英,分部则可以直接替换原来的一级路由器,让所有的分部的电脑都接在分部的蒲公英下面。 利用蒲公英路由器上的智能组网功能,将总分部的蒲公英创建成一个虚拟局域网络,使各节点之间互相通信,主机之间可以直接通过局域网IP地址进行访问。 3.2.1 安装及配置蒲公英 各点蒲公英正常接线后,浏览器输入oraybox.com登录进入管理地址进行上网配置; 上网正常后,首次进入管理页面,需修改管理密码。 3.2.2 创建智能组网 【点击查看组网教程】 3.2.3 添加旁路设置 组网创建完成后,选择【网络设置】-【旁路设置】,点击“添加旁路”;在弹窗中添加旁路路由: | 选择旁路路由:选择总部下面的蒲公英路由器为旁路路由 | 目标地址:192.168.1.0:总部蒲公英上层服务器网段(192.168.1.0表示网段,子网掩码为:255.255.255.0。) 点击“确定”保存旁路设置后,页面将显示我们添加的旁路规则。 3.2.4 Ping测试 通过ping测的方式,在分部下的电脑ping下总部上面的服务器IP地址。 注:为了提高P2P连通率,建议开启网关路由的UPNP功能。 4. 方案优点 1、在不改变总部网络环境下,实现据跨网络传输、跨地区通信; 2、可靠性,单个节点故障,不影响其它分点连接; 3、无限并发数,具有很强的灵活性和可扩展性; 4、采用P2P通道进行连接,访问速度快; 5、部署操作简单,维护难度大大降低。 5. 注意事项 1、组建虚拟局域网时,每个路由器成员的IP地址不能相同,否则会造成网络冲突; 2、添加旁路若目标类型选择的是“IP网络段”,子网掩码也要跟随变化; 3、需要注意路由器成员的IP不能与旁路的目标IP相同。 如果按照以上步骤操作后,遇到产品相关问题,您可创建工单寻求技术人员协助。
多分支企业OA协同办公解决方案
1. 行业背景 中小型企业或大型企业通常都有众多分支机构和不同的业务板块,涉及到的业务系统如OA办公系统等,如今办公系统已经不单单是日常协同办公的平台,更是一个企业或组织的管理支撑平台,担负着更加复杂、综合的作用,一套好的OA系统,能够为企业内不同的人员随时随地提供其所需的信息,由于分支机构分布在不同地区,如何实现高效协同办公及方便管理,是当下企业所面临的问题。 2. 行业需求 具有多分支机构或子公司的企业,若还使用传统模式办公,会存在很多复杂及困难的地方,实现企业内部流程和信息的畅通,必须克服地域、网络和系统上的障碍,由于地区不同网络不同,各分支机构互联存在着难度。 3. 实施难点 1、使用第三方硬件如虚拟局域网,部署和维护难度大; 2、公司机构分布各地,互联受到网络限制; 3、若数据走第三方传输,安全与稳定性无法得到保障; 4、出差或在家无法完成协同办公的流程,拖延工作进度。 4. 解决方案 4.1 产品清单 (1)蒲公英X系列路由器×2台 4.2 方案部署 协同办公系统繁杂,找人困难、操作复杂、连不通、接不上、投资大等等这些都不是问题,蒲公英产品针对这种多分支记否办公的企业提供简单、高效的解决方案,在公司总部与分部分别放置一台蒲公英路由器,外部员工可通过登录蒲公英客户端软件,由贝锐自主研发采用云虚拟局域网技术实现智能组网,前台美眉都能通过两个步骤轻松创建异地虚拟局域网络,能连接互联网即可实现组网,不受宽带类型限制。(组网详细教程戳我) 蒲公英产品针对需要协同办公的企业提供简单、高效的解决方案。同时亦能满足企业发展的需要,企业将来若改管理模式或有其他的发展,蒲公英组网能长期适应企业不同的应用及场景。 4.3 方案优点 使用蒲公英路由器组网实现OA系统互联,实现企业内部信息共享。高效地协同工作,改变过去复杂低效的手工办公方式,实现办公自动化。 (1)无需专业IT运维人员,维护从此变得很简单 蒲公英智能组网,采用统一账号管理所有路由,组网成员灵活删除增加,非专业人士也能轻松搞定; (2)利用休息时间快速办公 即使周六日休息时间,也能在家远程连接公司的OA系统处理事务,大大降低交通时间的成本; (3)无需担心公司数据泄露? 蒲公英智能组网,访问数据通过加密传输,不用再担心总分部之间的管理系统及数据互访的安全问题。
低成本打造个人私有云盘
行业背景 目前国内各大免费网盘纷纷关停,导致普通用户对存储空间的需求变得更加迫切,普通用户选择网盘首要考虑的因素是成本及安全性的问题,而收费的网盘不管是容量,还是带宽,都有一定的限制,网盘的安全性也无法得到保障。 行业需求 有部分用户将数据资料存储在本地NAS设备,利用NAS作为一个数据存储空间,但一台NAS的价格普遍昂贵,对于许多普通用户来说,价格太高并不切合实际,从普通用户角度来看,对于存储空间的需求,不外乎是方便、安全、低成本这三个要素。 实施难点 1)NAS虽然可以保持时刻在线,但是价格昂贵及易用性不佳; 2)移动硬盘虽好,但是不方便携带; 3)数据存放及传输的安全性要得到保证; 4)兼容性强,要能适应不同的操作系统及网络环境; 5)前期搭建及后期管理维护的难度不能太高。 解决方案 1、产品清单 (1)蒲公英X系列路由器×1台 (2)蒲公英客户端 2、方案部署 蒲公英智能路由器除了能组建虚拟局域网的功能外,还能摇身一变成为一个安全可靠方便的私有云。X3-2151和X5-2253这两个型号的蒲公英自带USB接口,支持U盘或硬盘接入,与客户端组网后轻松实现外网存取文件的功能。出门在外或上班时,使用电脑或手机登录客户端,即可与家里的蒲公英路由器连成一个网络,随时随地存取数据。 利用蒲公英+外接硬盘,把困难的网络设定流程简单化,并且数据的传输加密,这样一来可以保证数据的安全,还可以实现容量超大的个人网盘,也不需要很高的成本和技术,完美解决数据安全及存储的问题。(查看详细步骤) 3、方案优点 (1)兼容性 网络和系统兼容性高。数据资料能集中存放,支持各终端自由存取和管理,适应不同的操作系统。同时实现跨网络互联,不局限于特定的网络环境; (2)方便性 通过点对点技术打通网络隧道,实现数据传输。在外网能随时随地访问远端蒲公英路由器的文件,进行资料的存取,就像在本地使用一样; (3)成本低 蒲公英路由器成本低,组网技术含量低,同时也意味着管理和维护的难度低; (4)安全性 数据通过加密传输,安全有保证;资料掌握在手中,不用担心资料流失。
旁路模式轻松实现企业分部与总部互通
1. 行业背景 Micheal是一家快递公司的IT运维人员,因公司业务发展迅速,新增网点的速度非常快,各网点需将每天的数据都上传到总部服务器,及平时需要向总部服务器查询一些数据,总部的主路由是一台带有防火墙功能的企业路由,为确保公司内部信息安全,已经针对不同的域设定好安全策略,具有不可替代及更改的作用。 2. 行业需求 为了公司总部与新增网点之间能够实现共享资源,以及网点业务数据的及时上报,企业需要建立虚拟局域网络隧道来实现上述需求。 3. 实施难点 利用Internet搭建虚拟局域网络,除了要有扎实的网络技术,同时对网络环境也有较高的要求: 1、搭建虚拟局域网络网络需公网IP环境,现今公网IP资源缺乏,多数宽带分配的是私网IP地址; 2、公司总部的网络结构不可更改,新增网点速度快,选取的虚拟局域网络方案必须具有灵活性和可扩展性; 3、总部与各网点之间的网络部署成本和人力成本必须控制在预算内; 4、各网点互联需要打破不同网络运营商之间的限制,提高可操作性。 4. 解决方案 4.1 产品清单 (1)蒲公英X系列路由器×2台 4.2 方案部署 蒲公英智能组网中的旁路功能,能实现不改变总部网络结构的前提下,各门店网点与总部服务器互通,蒲公英组网采用云虚拟局域网技术,代替传统的虚拟局域网络,能将分布在异地不同的网络,通过路由器快速组建成一个虚拟网络,在分部网点访问总部服务器,与局域网内的访问方式一样,无需其他的配置或修改,从而实现网点与总部间的互联互通。 在总部交换机下接上蒲公英,其他网点则可以直接替换原来的一级路由器,让所有网点的电脑都接在网点的蒲公英下面。由于总部服务器没有直接接在蒲公英下面,分部网点无法直接访问。需要设置旁路,将总部蒲公英作为旁路路由,使得网点电脑访问总部主路由下的设备时经过蒲公英,达到访问总部服务器的目的。详细操作步骤 4.3 方案优点 这种模式适合在网络结构复杂的总部,或者网络部署困难的环境。对于中小企业来说确实是个方便简单的办法,无需运行其他的软件组建网络,适用于各种宽带网络,无需依赖宽带分配公网IP,私网用户也能轻松组网。 (1)零技术要求 组网仅需简单两步,帮助企业IT运维人员节省精力和时间,无需改变总部网络原有结构,旁路路由提供完美解决方案,简化安全管理操作。 (2)数据传输安全 蒲公英智能组网通过AES/RSA非对称加密的方式进行数据传输,保障用户的企业信息安全。 (3)灵活性高 蒲公英组网成员可根据具体需求进行增加删减,操作可以直接通过浏览器上进行设置并立即生效,对网络中的其他成员不会有任何影响,灵活便捷。 (4)成本低 使用蒲公英路由器组网实现低成本搭建异地虚拟局域网络,路由器也有专门的云管理平台,不需要技术人员常年出差维护,为公司节省不少差旅费。
医药连锁系统信息化管理解决方案
1. 行业背景 医药连锁店普遍都是分布在不同地区,就连锁医药企业自身的发展和市场竞争力来说,医药连锁店需要实现信息化的管理,并且要向跨区域连锁,规模化的方向发展,才能适应现代激烈的竞争要求。 2. 行业需求 由于连锁行业的特性,从药品采购、入库,到销售、调货等环节,都要实现全程信息化管理,才能满足管理的要求,但现有的管理模式难以适应要求,因医药门店分布广,药品的种类和批次多,靠手工处理容易导致出错,而且门店系统的信息和其他事务的申请无法及时汇总到总部,门店之间的销售和库存情况无法实时查看,总部也无法进行统一的管理和调控。 3. 实施难点 在实现医药门店系统和总部互联过程中,出现了以下的难题: (1)连锁门店分布地区各不同,实现互联的网络成本居高不下; (2)总部的IT运维人员有限,各地奔波调试和维护系统会产生高额的差旅费用; (3)普遍的虚拟局域网通常需要公网IP为前提,现今公网IP资源短缺; (4)连锁店的扩张迅速,网络维护的灵活性要高。 4. 解决方案 4.1 产品清单 (1)蒲公英X系列路由器×多台 4.2 方案部署 利用蒲公英路由器组建异地智能网络,实现总部和门店之间的医药系统互联成统一的网络系统,达到信息传递顺畅,数据高度共享,同时能提高总部的办公和决策效率,及时对各门店经营中的各种信息进行有效处理,实现业务信息的系统全程记录和把控,全面提升连锁药店的经营管理水平。 实现总部与门店之间的互联,只需在总部及各门店部署蒲公英路由器,通过蒲公英管理平台进行组建网络,无需运维人员奔波于各门店之间,而且组网不依赖公网环境。(查看详细步骤) 4.3 方案优点 (1)实现管理的科学化 组网后门店医药系统互联,通过局域网地址能访问到总部,能及时获取药品库存,销售等信息,方便门店快速灵活完成相关业务; (2)简单的网络维护和管理 蒲公英组网不需要有扎实的网络基础,零网络基础的小白用户也能轻松完成组网; (3)良好的网络兼容性 各门店所在的地区及网络都不一样,蒲公英组网支持多种网络接入,能实现不同网络直接的互联互通,不依赖具有公网IP的网络环境; (4)较强灵活性和易扩展性 智能组网通过统一平台进行管理,增加、删除、修改成员只需在web上操作,操作简便。
远程访问公司系统解决方案
1. 行业现状 公司随着企业发展通常都会设有不同的业务板块,涉及业务系统往往多达10+,包括OA办公自动化系统、ERP进销存软件和文件服务器等等,如今办公系统已经不单单是日常协同办公的平台,更是一个企业或组织的管理支撑平台,担负着更加复杂、综合的作用。 企业管理人员或运维工程师,休假在家或在外出差期间,想远程访问公司内部系统数据或调试服务器,必须克服地域、网络和系统上的障碍,由于地区不同网络不同,使远程办公互联成为难题。针对这种情况,蒲公英给出了一套完善的解决方案,接下来就为大家详细地介绍一下(查看PDF格式介绍手册请戳我)。 2. 蒲公英优势 1、打破地域与网络限制,无需公网IP,能联网即可异地组网; 2、出差人员也可通过蒲公英客户端实现远程办公,兼容各大系统平台; 3、组网功能操作简单,技术门槛低,网络小白也可简单三步骤轻松搭建; 4、组网传输通过加密处理,保障企业内部数据安全,有效降低时间成本。 3. 搭建步骤 3.1 接线上网 3.1.1 设备接线 ①将网线一端接入路由器蓝色WAN 口,一端接入因特网(如宽带猫、光猫等); ②路由器黄色LAN 口可接入NAS、计算机等联网设备; 注:如果您希望通过笔记本电脑、平板、手机等无线方式配置路由器,此处可不连计算机。 ③连接电源适配器。 3.1.2 设备联网 蒲公英路由器提供了简单易用的Web 配置页面,您可通过Web 向导轻松完成上网配置。 配置前,请确保计算机已连接到路由器的黄色网口(LAN口),并且设置好了自动获取 IP 地址。 蒲公英路由器默认使用DHCP自动获取IP联网,若需修改上网方式,可通过浏览器访问蒲公英默认出厂IP:10.168.1.1,进入本地管理页面,选择相应的上网方式进行配置; 若蒲公英路由器可正常联网,则自动跳转至云管理平台,输入SN码及默认密码admin登录后,修改管理密码完成初始化。 3.2 组建网络 3.2.1 创建网络 (1)点击 <+创建网络> 创建智能组网; (2)填写网络名称,选择网络类型。 网络类型 说明 对等网络 组网内的所有成员均可互相访问 集散网络 将组网成员区分为中心节点与普通成员,普通成员间无法互访,只能与中心节点互通 自定义网络 自定义成员之间的访问权限,仅支持纯软件组网 「注意」:服务等级为体验版的用户,网络类型仅支持创建对等网络和集散网络。 3.2.2 添加成员 (3)创建组网后,点击右上方【添加成员】,添加组网的硬件成员及软件成员。 3.2.2.1 硬件成员 在弹窗内选择对应的硬件类型、并输入硬件设备的SN码,选择添加成员的网络后,点击“确定”即可; 「注意」:蒲公英路由器在云管理平台上绑定对应的贝锐账号后,将自动添加至硬件成员列表中。组网中添加其硬件成员,需点击【添加成员】->【未组网成员】,将其未组网的硬件成员添加至组网中。 3.2.2.2 软件成员 在弹窗内选择对应的软件成员类型(客户端/服务器端)、成员名称、并设置登录密码、手机号,选择添加成员的网络后,点击“确定”即可。接下来就可以使用新生成的UID和预设的密码登录蒲公英访问端; 组网完成后,网络类型为对等网络的组网,组网成员间可进行互访。 3.3 异地远程访问 3.3.1 访问前提 要实现外网访问公司总部的办公系统,前提是总部的办公系统在公司本地局域网内访问正常。 以Windows搭建IIS为例,公司网络环境下能够通过服务器的IP在浏览器上正常打开IIS网站服务。 3.3.2 家里蒲公英 家里蒲公英路由器下的电脑主机,无需额外安装任何软件客户端,即可如同在公司内网一样,直接输入总部服务器地址访问即可。 ①IIS系统: ②办公系统: 3.3.3 外网移动端 外出移动人员,可在相应的电脑或手机上安装蒲公英访问端,访问公司总部数据。 蒲公英客户端支持市场上各大主流操作系统,用户可访问蒲公英官网下载页(跳转戳我),选择相应操作系统的版本进行下载安装登录。 3.3.3.1 电脑端 下面以Windows访问端为例(具体教程请戳) (1)登录客户端 ①贝锐蒲公英客户端支持多种登录方式,如免密登录、账号登录、微信登录、认证登录、扫码登录。 ②登录相应的客户端账号后,点击“网络图标”,选中对应成员,点击网络测试的“PING”即可进行PING测试,若有收到回复,则表示组网通道已建立; 此时移动办公人员的电脑也可如同在公司内网一样,直接通过总部服务器的IP地址访问即可。 IIS系统: 3.3.3.2 手机端 下面以iOS客户端为例具体教程请戳 (1)登录客户端 贝锐蒲公英客户端支持多种登录方式,如免密登录、账号登录、微信登录、苹果登录、认证登录。 ②手机登录贝锐蒲公英客户端后,点击设备列表的组网管理,可将未加入组网的设备快速添加至默认的智能组网中。点击【组网管理】->【编辑】,勾选未授权的设备,勾选后点击【完成】,设备已加入至组网中。 ②访问办公系统 访问总部硬件成员下的办公服务器,直接通过服务器所获取的内网IP地址即可。 至此,蒲公英智能组网远程办公操作指南介绍结束,感谢您的观看!
连锁门店视频监控方案
1. 应用场景 对于超市、门店、仓库甚至是住宅区等,监控系统的应用已经非常普通,可以实时监控并通过电脑存储成录像进行回看。但是监控系统目前也只支持同一个局域网内进行查看,对于一些连锁型企业,想要实时查看各分店的监控则比较麻烦,只能借助第三方工具实现。 需要在监控中心同时查看三个连锁店的视频监控,需要在监控中心和各各门店放置一台蒲公英路由器,并且进行组网,实现互联互通即可。 2. 实施难点 (1)住宅区网络无公网IP,且公网IP价格昂贵 (2)数据存放及传输的安全性要得到保证; (3)网络连接的速度各方面需要达到理想效果。 3. 解决方案 3.1 产品清单 (1)蒲公英路由器X5 3.2 方案部署 (1)将蒲公英路由器连接电源,根据所处网络环境选择相应的上网方式。确保路由器可正常联网。 点击查看【上网设置指南】 (2)监控中心及各个连锁店的路由器绑定同一贝锐账号,并加入至同一组网中。 点击查看【(硬件+硬件)组网教程】 (3)组网之后,在监控中心网络里的电脑上,点击开始菜单,找到“运行”,输入“cmd”回车,调出命令提示符(或直接按快捷键“win+R”),输入ping 10.168.7.2,成功ping通其中一间连锁店的设备IP。 目前已成功打开连锁店三的监控系统进行查看。 3.3 方案优点 1、部署简单,投入成本低; 2、连接稳定,使用方便。 4. 注意事项 1、组建虚拟局域网时,成员间的IP不能冲突; 2、添加旁路若目标类型选择的是“IP网络段”,子网掩码也要跟随变化; 3、蒲公英路由器是二级路由器时需要在一级路由器设置静态路由。
SOHO人员异地获取文件解决方案
1. 行业背景 SOHO是一种自由、弹性而新型的工作方式,跟传统上班族不同是工作地点不限,时间自由。互联网的兴起使SOHO成为可能,通过在家里安装传真机、打印机、电脑等办公设备,可以让办公人员摆脱时间和空间的束缚。 2. 行业需求 Ivan现在从事外贸SOHO工作,家里的台式电脑存储着大量的客户资料、货源信息等。当外出拜访客户、到工厂验货时,通常会随身携带笔记本方便工作。需要查询以往的客户、工厂或货源资料时往往是无从下手,外面无网络也无法连接回去家里的电脑获取资料,工作起来不完全协调,也因此耽误了很多客户。 3. 实施难点 SOHO一族外出工作时,要求的是移动办公的方便性,同时安全性也应引起重视。首先,要保证笔记本等设备能连接上互联网;其次,在外网与家里电脑连接时要保证数据传输的安全。如何能简单快速实现外出办公与家里电脑实现完美互联,成为了SOHO人员的一道难关: 1、外出的环境经常没有免费网络,自己手机WIFI的流量有限; 2、要保证便携设备(笔记本/手机)与家里电脑互联互通的过程是安全而且稳定的; 3、要将网络费用需要控制在一定范围内; 4、SOHO人员通常对网络知识连接不深入,内外网互联的技术和维护难度不能太高。 4. 解决方案 4.1 产品清单 (1)蒲公英路由器X1 (2)蒲公英客户端 4.2 方案部署 为了帮助SOHO人员解决以上的难题,贝锐推出蒲公英智能组网路由器,帮助SOHO人员在任何时间、任何地点、使用任何终端都能安全地与家里的电脑进行连接。零技术也能组建虚拟局域网络,通过蒲公英管理平台可以轻松对组成员进行管理。(查看详细教程) 同时,蒲公英有针对不同的使用环境下不同型号的路由器,家里的台式电脑登录蒲公英客户端软件,外出时携带支持USB网卡上网的X1,即可以和家里设备进行互联。无论在哪里,可以随时随地登录家里的电脑,摆脱空间和地域的限制。 4.3 方案优点 1、低成本组建虚拟局域网络,网络不受限制; 2、X1方便携带,支持无线上网,提高便利性与环境适应性; 3、智能组网的部署和维护简单,无需技术含量; 4、组网后操作简便,与局域网内一样。
企业分部间轻松访问OA、ERP等系统
行业背景 公司随着企业发展通常都会设有分支机构和不同的业务板块,涉及业务系统往往多达10+,包括OA系统、ERP软件和文件服务器等等,如今办公系统已经不单单是日常协同办公的平台,更是一个企业或组织的管理支撑平台,担负着更加复杂、综合的作用,一套好的OA系统,能够为企业内不同的人员随时随地提供其所需的信息,由于分支机构分布在不同地区,如何实现高效协同办公及方便管理,是当下企业所面临的问题。 行业需求 多分支机构或子公司的企业,若使用传统模式办公,要实现企业内部流程和信息的畅通,必须克服地域、网络和系统上的障碍。由于地区不同网络不同,使各分支机构互联成为难题。 实施难点 1、使用第三方平台,部署难度大; 2、公司机构分布各地,互联受到网络限制; 3、若数据走第三方传输,安全与稳定性无法得到保障; 4、规模逐步扩大,网络管理节点变多,日常运维工作复杂 。 解决方案 1、产品清单 (1)蒲公英X系列路由器×2台 2、方案部署 在总部与分部分别放置蒲公英路由器,出差员工则可通过登录蒲蒲公英客户端软件,由贝锐自主研发采用Cloud VPN技术实现智能组网,前台美眉都能通过两个步骤轻松创建异地虚拟局域网络,能连接互联网即可实现组网,不受宽带类型限制。 3、方案优点 (1)可随时随地远程连接公司管理系统软件处理事务,大大降低交通时间的成本;(如果升职加薪是梦,那蒲公英就是帮你圆梦的选择。) (2)蒲公英智能组网,访问数据通过加密传输,总分部之间的管理系统及数据互访不再是难题,同时安全性与稳定性也得到了根本的保障; (3)蒲公英组网成员可根据具体需求进行增删,设置后立即生效,对网络中的其他成员不会有任何影响,灵活便捷。(组网详细教程戳我)
企业远程办公解决方案(P5+访问端)
习近平总书记在主持中央政治局常委会会议时指出,经过艰苦努力,疫情形势出现积极变化,防控工作取得积极成效。疫情形势“向好”并不等于防疫可以“松懈”,尤其是随着返工返学的人群流动高峰到来,疫情防控更是面临着诸多的风险和挑战。 由于疫情的关系现在远程办公大火,55%的企业都在用远程办公。待在家中远程办公仍然是最佳抉择,迫不得已需要返工的伙伴途中一定要做好防护。 有些企业在远程复工时遇到了困难:公司没有提前部署远程办公的环境,短时间内从传统的集中办公过渡到远程办公,最大的挑战是员工的工作进度不可控,如访问不了公司内网的系统,文件留存在公司电脑,导致工作没法进行。 1. 面临难点 如果是平时网络工程师能轻松搞定,如采用MPLS构建企业IP专网、或根据企业业务特色部署云ERP、搭建企业云盘存储文件等等。 但在疫情期间,公司的网络与系统毫无准备: (1)办公系统和NAS只允许内网设备访问; (2)硬件远程办公产品由于成本昂贵、维护费用高、配置复杂等因素,将大多数中小企业拒之门外; (3)网络工程师也因各种管控,无法到达办公室部署。 2. 解决方案 用蒲公英P5旁路盒子,即插即用,支持远程部署,无需赶回公司修改网络结构、设置服务器。这是一款能满足中小企业和个人用户需求的远程办公的硬件产品,结合软件使用,帮助远程用户、公司、分支机构与公司的内网建立可信的安全连接,并保证数据的安全传输。这种方式能够支持用户的日常办公需求,包括访问局域网中的文件服务器、内部数据库、CRM、ERP等等,而不仅仅是远程控制。 只要有一位员工(无需技术背景)在公司总路由器下插入一个蒲公英P5旁路盒子,网络工程师就能远程把全国同事的设备和公司内网连城一个局域网实现互通,像这样: 3. 远程部署P5 首先将P5交给现场人员,请他们帮忙将P5接入公司主路由器下并接通电源,确认P5显示灯是蓝色后,网络管理员在自己的笔记本电脑远程连接P5路由器进行初始化后进行智能组网设置。 (1)在浏览器访问地址https://pgybox.oray.com 登录蒲公英云管理平台,输入总部蒲公英路由器的SN码(路由器背面可查看)及默认密码(admin)登录。 (2)蒲公英路由器首次使用需要初始化操作,即更改路由器的初始管理密码。点击“提交”按钮即可。 (3)初次登录云管理平台,需先绑定贝锐账号。 (4)绑定账号后,点击【智能组网】->【成员列表】->【我要组网】,跳转至蒲公英管理平台进行组网。 (5)创建组网,根据提示和需求添加对应硬件成员和软件成员点击【确定】,就可以轻松组网了。技术人员可在蒲公英管理平台自定义设置组网成员的备注名称,绑定相应员工的手机号,便于员工登录并访问公司NAS、OA。 【点击查看智能组网教程】 组网完成。 4. 轻松访问 完成后就意味着组网成功,在公司与外网远程访问端都需要安装并登录蒲公英访问端。 外网员工登录成功后,即可查看到组网内的成员,双击服务器成员可进行ping测试,若能够正常ping通,则代表组网已经连接成功。 然后就可以在外网访问公司OA、CRM系统,或者NAS了。 在这特殊时期,推广远程办公既可以有效地进行自我隔离,防止疫情扩散。又能减低公司和员工的成本,希望大家都能快速熟悉掌握远程办公的管理方式。
连锁超市收银系统互联方案
1. 应用场景 收银系统现在已经不止单一的局限于大型超市的结账应用上了。它现在几乎遍布于大大小小、形形色色的各种业态下的店铺中。它可以帮助快速的运营店铺的生意,提高结账工作的效率和准确程度。并且还能起到一定的后台管理作用,它可以实时显示销售数据,也可以查询一段时间内的经营数据状况。 但是对于一些收银前台和后台不在同一个局域网的,例如连锁店等,就到导致前台的结账数据无法同步到后台,后台无法实现统计和管理。针对这个问题,贝锐推出蒲公英智能企业级路由器组网解决方案。 2. 实施难点 (1)数据需要及时同步传输; (2)兼容性强,要能适应不同的操作系统及网络环境; (3)网络连接的速度各方面需要达到理想效果。 3. 解决方案 3.1 产品清单 (1)蒲公英路由器X5 3.2 方案部署 (1)总部是服务器收银后台,自营店和加盟店是收银前台,分别有POS机。现在将三台蒲公英分别安装到这三个店面。 (2)将蒲公英路由器连接电源,根据所处网络环境选择相应的上网方式。确保路由器可正常联网。 点击查看【上网设置指南】 (3)总部、自营店及加盟店的路由器绑定同一贝锐账号,并加入至同一组网中。 点击查看【(硬件+硬件)组网教程】 (4)组网成功后,加盟店的前台主机成功Ping通总部设备。 (5)已正常登录系统并将当天的数据同步到后台。的确非常实用,而且直接输入服务器的内网IP即可同步到后台。 3.3 方案优点 1、无需改变网络环境,部署简单; 2、直接用内网IP访问,连接方便、稳定、速度快。 4. 注意事项 1、 组建虚拟局域网时,成员间的IP不能冲突; 2、 蒲公英客户端要保持运行不能退出; 3、客户端与总部的设备无法ping通时,需留意电脑防火墙和杀毒软件是否已经关闭。
组建工厂多分支间异地虚拟局域网
1. 行业背景 随着现代化企业制度在我国的普及和深化发展,工厂信息化建设不断深入,特别是大型工厂都加快了信息化网络平台的建设,各工厂都正逐步转向利用网络和计算机集中处理管理生产、销售、物流、售后服务等重要环节产生的大量数据。 2. 行业需求 在制造行业中,大多企业由于业务发展,为提高生产效率,会在全国各地设立分厂,但由于总部与各个分厂处于不同的网络环境,实现管理系统数据的互联互通成为了一个难题。 3. 实施难点 1.各工厂处于不同区域,不同网络宽带; 2.IPv4地址资源枯竭,总部宽带无分配真实公网IP地址; 3.管理系统互联依赖第三方平台,部署维护难度加大,传输速度受限; 4.系统涉及到公司机密信息,通过第三方传输,安全性与稳定性无法保障。 4. 解决方案 4.1 产品清单 (1)蒲公英X系列路由器×3台 4.2 方案部署 通过贝锐自主研发的一款由Cloud VPN技术实现智能组网的企业级路由器——蒲公英,为不同区域的制造工厂搭建灵活、高效、弹性可扩展的生产管理信息化平台,提高各工厂间的协同生产效率。 4.3 方案优点 (1)网络兼容 蒲公英智能组网与传统VPN(需依赖宽带分配公网IP)性质不同,蒲公英组网无需公网IP地址,只要能够连接到互联网,即可轻松创建虚拟局域网络。 (2)操作配置 蒲公英智能组网仅需两步:①将组网成员绑定到贝锐进行统一管理;②在贝锐官网进行创建智能组网。即使是技术小白,也可以轻松创建虚拟局域网络。 (3)管理维护 蒲公英智能组网具有很强的灵活性及可扩展性,组网成员的增删改都可以直接通过浏览器操作,一个贝锐账号即可实现全盘管理。 (4)信息安全 蒲公英访问总部搭建的进销存系统,通过AES/RSA非对称加密的方式进行数据传输,保障用户的企业信息安全。
多分支机构间异地数据互通教程
1. 应用场景 随着公司业务的不断发展和规模的不断扩大,公司决定在北京总部搭建了项目管理系统软件,以及在广州分部搭建了文件共享管理系统,以提高办公效率,提升企业管理水平。领导就把实现总部与分部实现互通的任务下发给了我。 但由于子公司分布在全国不同的地区,大多都没有真实公网IP,总部与各分部间依靠到第三方软件来实现互联互通的话,部署与维护也成为了难题,且稳定性与解析速度无法保障,让我实在是头疼不已。 2. 实施难点 1、各分支机构的网络不尽相同,且大多没有公网IP; 2、异地数据互联互通只能通过第三方平台,部署维护难度加大; 3、公司总部与各分支部之间数据传输的安全性及稳定性无法得到根本保障。 3. 解决方案 3.1 产品清单 (1)蒲公英路由器X3 3.2 方案部署 (1)将蒲公英路由器连接电源,根据所处网络环境选择相应的上网方式。确保路由器可正常联网。 点击查看【上网设置指南】 (2)多地分支机构的路由器绑定同一贝锐账号,并加入至同一组网中。 点击查看【(硬件+硬件)组网教程】 (3)访问测试 在上海分部电脑的浏览器上直接输入北京总部项目管理系统软件的IP地址(10.0.5.100),连接成功。 4. 方案优点 (1)组网不受宽带网络限制,能连接互联网即可实现异地虚拟组网; (2)通过AES/RSA非对称加密的方式进行传输,保证访问的安全性; (3)维护成本低,维护方便。 5. 注意事项 (1)组网时每个路由器的IP地址不能相同,否则会导致网址冲突; (2)若蒲公英当二级路由,一级路由开启UPNP功能有助于打通网络P2P,提高网络传输速率。
异地连锁门店数据备份解决方案
1. 行业背景 在移动互联网时代,连锁企业不断发展壮大起来。由于经营方式与组织结构所独具的优势,连锁经营的模式也呈持续发展的良好态势。不少线下连锁经营的企业抓住时代的浪潮,快速调整业务模式,更借助信息化手段扩展经营手段,希望能在激烈的竞争和巨大的冲击中,能进一步巩固在市场竞争中的有利地位。而互联网的关键是数据互联互通,将各连锁店+顾客+商品三者的数据进行联系,这样才能进入连锁经营的“智慧商业”时代。很多连锁企业者都意识到这一点,可是具体如何实现呢,很多连锁企业经营者都迫切想得到答案。 2. 行业需求 连锁门店具有多终端,地域分散的特点,随着信息化程度的不断加深,连锁企业的IT设备面临着新一轮的淘汰与更新,这些连锁门店分布广、业务繁忙且无法中断,又要实现各门店数据的无缝结合,在此面临着诸多瓶颈。 3. 实施难点 1、管理成本:分支多,管理系统的维护和升级需到现场; 2、时间成本:IT人员缺少,无法同时跑多个门店; 3、交通成本:多点奔波产生的交通费和住宿费惊人; 4、沟通成本:多地不同负责人,沟通成大难题,容易影响业务进度。 4. 解决方案 4.1 产品清单 (1)蒲公英X系列路由器×3台 4.2 方案部署 蒲公英智能组网技术能突破传统地域,宽带,环境的限制,实现异地互联,实现方式非常简单,只需要在总部与各连锁门店放置一台蒲公英路由器,轻松两步,零技术基础的小白也可轻松创建异地虚拟局域网络,实现各个连锁门店都能访问到总部的收银系统。(组网详细教程戳我) 总店与各门店的蒲公英只需要通过一个账号就可以进行全盘管理,增删改查均可通过统一管理平台进行操作,大大降低了配置管理的难度以及维护的成本。 4.3 方案优点 蒲公英智能组网,实现跨平台连接,让所有的连锁店铺数据能实时同步,打破信息传输壁垒,实现快速、高效、无死角、无缝接对接沟通。移动互联网时代,大数据和信息技术已成零售企业的重要竞争力。对零售连锁企业来说,在终端海量数据和顾客行为跟踪基础上的门店精细化管理、营销、服务迫在眉睫,而这一切,先从门店数据的互联互通开始。 (1)网络兼容性高 组网不受宽带网络限制,能连接互联网即可实现异地虚拟组网。 (2)降低运维成本 组网仅需两步即可实现,维护设置通过一个账号即可全盘管理。 (3)保障数据安全 通过AES/RSA非对称加密的方式进行传输,保证访问的安全性。
企业居家办公解决方案
1. 行业背景 企业现有的办公软件和各类业务系统的应用实现了日常办公的无纸化,极大地加快了文件、工作信息的流转速度,工作效率得到了很大的提高,随着企业对事务处理的高效性、时效性要求不断提高,传统的企业业务管理水平已不能满足需求。 2. 行业需求 以企业的OA办公系统为例,企业人员将远程办公作为内部办公延伸,存在以下的问题: 1、员工只能在公司的PC上使用OA系统,一旦脱离特定环境,系统无法使用; 2、非上班时间,当一些突发和意外情况发生时,不能及时登录OA系统进行业务的处理; 3、业务人员在家时,业务有新进展时无法第一时间进行上报、传达。 3. 实施难点 灵活的办公方式有助于提高员工工作热情,也有助于提升企业生产效率和业务经营的作用。而目前公司的管理系统、协同办公系统等都需在公司这个特定环境才能使用,要实现企业人员居家办公,面临着以下难题: 1、员工数量之多,每人所处的网络环境都是分离且独立的,网络互联受到限制; 2、建立PPTP/L2TP/IPSec等虚拟局域网络,要求公司必须有公网IP,配置复杂; 3、企业内部交流的协同性较高,互联方式必须是安全稳定及简便的。 4. 解决方案 4.1 产品清单 (1)蒲公英X系列路由器×1台 (2)蒲公英客户端 4.2 方案部署 蒲公英路由器智能组网,结合客户端软件使用,能与企业内部连成一个网络。企业员工居家时,通过在手机或笔记本上安装蒲公英客户端,使得手机/笔记本具备了办公功能,摆脱了必须在固定场所、固定设备、固定环境上办公的限制。提高了企业移动办公的便利性和快捷性。(查看详细教程) 在家就能使用手机/笔记本实现日常办公业务,不仅使得办公变得随心,轻松。而且借助组网后的方便,使用者无论身处何种紧急情况下,都能高效迅捷地开展工作,特别是对于突发性事件的处理、应急性事件的部署有极为重要的意义。 4.3 方案优点 (1)及时性 在家通过登录蒲公英软件,确保与企业内部使用的办公系统完全同步,能实时接收企业内外邮件和系统发来的待办事项,能及时回复和办理,确保了处理工作的及时性; (2)方便性 蒲公英客户端适配Android及iOS端,摆脱回家必带笔记本的包袱,员工或管理人员在任何有手机信号的地方,都能通过手机办公,如同在办公室使用PC处理工作一样方便; (3)规范性 居家办公,管理人员能与在公司PC一样地操作文件审批等,也不用将自己的信息系统密码告诉别人,自己亲自处理紧急事件,保证企业管理的规范性; (4)全面性 蒲公英组网将居家办公与公司办公系统有机结合,实现任何办公地点和办公事件的无缝接入,提高办公效率,简化繁杂的办公程序,有网的地方就能实现居家办公,加速企业内部信息的快速流动,对提升企业的运营效率有着重要积极的意义,是全面提升企业综合竞争力的有效途径之一,能为企业带来长远的经济效益和社会效应。
蒲公英+向日葵助力企业远程办公
现正处于全民抗击新型肺炎疫情的关键时期,我们响应国家号召不出门,不聚集,最大限度地减少交叉感染的机会,把疫情传播的风险降到最低。 而对于急需恢复生产工作秩序的公司组织来说,远程办公成为了“刚需”,在疫情的影响下,企业可统筹员工在家办公。 以贝锐为例,贝锐是国内知名提供SaaS服务的软件商,有着业内熟知的花生壳、向日葵、蒲公英三款主打连接的旗舰产品。为了员工的身体健康,以及确保公司各项业务的正常运作,与全国大多数企业一样,贝锐从2-10起实行了远程办公。 在实施远程办公时,贝锐从以下3个方面来考虑的: 1、居家办公期间如何保证员工的考勤、工作效率; 2、所使用到的业务系统和共享文件系统是内外网隔离的,如何让居家员工能顺利访问到; 3、针对像财务、开发部门这些涉及到敏感信息的部门,财务信息、代码对私密性要求较高的,如何保证远程过程中的安全? 有以上的考量,是因为远程办公不同于传统的办公模式,居家办公时,你得面临无处不在的干扰,甚至工作时间会被切割得支离破碎;员工无法面对面沟通工作需求;业务系统、工作文件也不是随时能访问到。 我们贝锐是这么解决的: 1、系统打卡+视频会议+早计划晚汇报 ①按照正常作息上班打卡 ,进入公司打卡系统,进行在线打卡; ②打卡后,公司通过企业微信视频的方式,查看员工的办公状态,避免精神萎靡、睡眼朦胧; ③上午开会制定当天工作内容,下班再开会,确认工作完成进度; ④最后通过企业微信汇总今日工作,形成日报上传。 2、蒲公英:访问内部业务系统、传输文件 公司内部的业务系统涉及许多技术、客户资料等商业机密,所以并不允许随意在外网访问。使用蒲公英VPN组网+绑定员工电脑的mac地址,来确保员工远程使用公司内部业务系统的安全。 实施步骤: (1)员工将家里电脑的mac地址提交给网络管理员,由管理员将mac地址绑定至系统中,只允许绑定了mac地址的电脑访问系统; (2)将蒲公英旁路盒子P5连接在公司一级路由器下,使得其与内部业务系统服务器处于同一层级; (3)接线完成后,访问http://pgybox.oray.com 根据提示完成初始化操作,并绑定到管理员注册的贝锐账号下。 (4)在【蒲公英网络管理平台】->【异地组网】->【网络成员】中,点击 <+创建网络> 创建智能组网; (5)填写网络名称,选择网络类型。 网络类型 说明 对等网络 组网内的所有成员均可互相访问 集散网络 将组网成员区分为中心节点与普通成员,普通成员间无法互访,只能与中心节点互通 自定义网络 自定义成员之间的访问权限,仅支持纯软件组网 「注意」:服务等级为体验版的用户,网络类型仅支持创建对等网络和集散网络。 (6)创建组网后,点击右上方【添加成员】,添加组网的硬件成员及软件成员。 硬件成员 在弹窗内选择对应的硬件类型、并输入硬件设备的SN码,选择添加成员的网络后,点击“确定”即可; 「注意」:蒲公英路由器在云管理平台上绑定对应的贝锐账号后,将自动添加至硬件成员列表中。组网中添加其硬件成员,需点击【添加成员】->【未组网成员】,将其未组网的硬件成员添加至组网中。 软件成员 在弹窗内选择对应的软件成员类型(客户端/服务器端)、成员名称、并设置登录密码、手机号,选择添加成员的网络后,点击“确定”即可。接下来就可以使用新生成的UID和预设的密码登录蒲公英访问端; (7)根据需求添加相应的成员后,点击确定,组网创建成功。 (8)在绑定了mac地址的电脑上,员工下载并安装对应系统版本的蒲公英客户端软件,使用手机号码+验证码方式登录蒲公英客户端软件,能顺利访问到公司内部的业务系统,随时处理工作事务。(下载地址) (9)除了可以访问公司内部的业务系统,还能以局域网的方式打开NAS的内网IP 地址,访问到公司内部搭建共享文件夹,特殊疫情时期居家办公员工轻松获得企业内部资源的共享。 以上蒲公英智能组网实现远程访问内部业务系统和共享文件传输的好处是,无需修改公司内部的网络结构和繁复的设置步骤,提高贝锐远程办公的灵活性和降低的营成本,让远程办公进行得更舒心! 3、向日葵:远程桌面亲临公司 除了访问公司内部的业务系统,在远程办公期间,员工需要获取远在公司的电脑上的文件,或者像财务的机器只能在现场操作,敏感信息远程传输并不利于企业信息的安全。 而通过向日葵直接远程控制公司电脑,即可让居家远程办公的员工立即享有如亲临在公司内的办公环境的体验。 实施步骤: (1) 网管帮忙打开办公室电脑,并下载安装向日葵企业版客户端。可先自行注册好向日葵账号,并生成主机,由网管人员输入指定的葵码登录; (2)员工居家电脑/手机安装向日葵控制端,登录与客户端相同的向日葵账号。 (3)在主机列表中,点击公司电脑的主机图标,有“远程桌面”、“远程文件”等功能选项。 (4)选择“远程桌面”可连接至公司电脑的桌面,即使员工家里与企业相隔千里,建立远程连接也有流畅的体验。 第一次使用只需请网管同事帮忙安装向日葵客户端,不关机情况下,以后使用直接连接即可,向日葵可以轻松满足居家远程办公人员文件、和特定设备远程操作的需求。 向日葵还支持屏幕录像功能,三种屏幕录像方案,任君挑选:被控端本地录像、控制端屏幕录像、云监控录像(7天/30天) 可以做到远程桌面的操作可追溯,避免安全事故的发生。 现在员工通过已登录了蒲公英客户端服务器的特定虚拟IP,即可访问到公司内网的服务系统,让更多即使在异地的员工也能连回公司内网;向日葵满足居家远程办公人员文件、数据传输的需求。真正实现在家也能办公,达到助力企业高效协作运转和减少人群聚集的目的。 利用蒲公英+向日葵能帮助疫情防控时期下的广大企业/个人实现远程办公,减少企业经济损失,与全国人民一起共渡难关。
远程查看视频监控服务
众所周知,视频监控是安防系统的重要组成部分,几乎所有的日常场景都会用到,如:街道、社区、商店、景点、学校等等。监控系统目前也只支持同一个局域网内进行查看,对于一些连锁型企业,想要实时查看各分店的监控则比较麻烦。 王总所在的连锁型企业为了需要观看在不同门店的海康威视监控情况,打算部署基于网络传输的远程视频监控系统。 1. 搭建阻力 连锁型企业具有多终端,地域分散的特点,要实现各门店的视频监控能在总公司监控中心查看,在此面临着诸多瓶颈: 1、由于历史原因导致监控视频设备的型号新旧不同、存储数据格式多样; 2、各分点所使用的网络宽带品牌不一,网络复杂,使各路视频监控系统彼此独立; 3、同时各分点运维人员不足,对视频监控缺乏有效的管理措施,导致设备维护不到位,视频资源可用性差。 2. 解决方案 针对以上的难题,可以使用蒲公英智能组网路由器搭建虚拟局域网,实现远程轻松查看监控。 3. 组网步骤 (1)在总部和各分部分别部署蒲公英路由器设备,蒲公英路由下联监控设备。 (2)将总部和分部的路由器绑定同一贝锐账号,并加入至同一组网中。【点击查看硬件组网教程】 (3)完成组网。 (4)组网之后,路由器成员间的通讯直接通过各自的局域网IP来进行。测试ping其中一门店的海康威视监控设备: (5)在总部监控中心,测试能ping通各门店的监控设备IP地址后,可直接在浏览器输入监控设备的IP地址去访问到对应的画面。 若是使用海康威视专门的视频软件查看监控的,直接将各门店的设备的IP添加进去即可。
抱歉,没有找到与“digital-marketing-courses-8.online”相关的内容。请尝试其他搜索词
抱歉,没有找到与“digital-marketing-courses-8.online”相关的内容。
请尝试其他搜索词
抱歉,您输入的内容为空,请尝试其他搜索词
抱歉,您输入的内容为空。