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)天内回复您的注册人员的查询,并保持您的注册人员帐户 数据的最新状态。如果您选择让您的域名注册自动更新,您还必须保持您的 支付信息的最新状态。
向日葵SDK文档
概述SLAPI是贝锐有限公司开发的一套基于产品向日葵的开发库,该库可以实现以点对点为通讯方式的远程桌面、远程文件、远程开机以及用户自定义的远程数据通讯。使用该开发库时,开发者无须关心点到点之间的通讯细节,以及通讯方式。SLAPI会以P2P或服务器中转等方式为通讯提供可靠的数据传输服务。 开发者账号使用SLAPI之前,你需要先拥有一个贝锐帐户,可以通过https:www.oray.com的右上角的注册按钮进行注册。如图: 拥有帐户后,进入http://open.oray.com(开放平台的网址),进入开发者认证页面,填写必要资料并提交开发者申请。如图: 注册后,进入我的应用页面创建应用,创建成功后,在应用详情中看到自己的APPID 和 APP KEY,有了这两个信息,就可以使用SLAPI来开发自己的应用了。如图: 支持平台目前SLAPI支持Window,Linux,Mac系列平台,而其他系统平台也将会尽快推出。 支持语言目前SLAPI以纯C加二进制库实现方式提供接口,只要你的开发环境可以调用C函数即可。 模型通常情况下开发出的应用会是2个APP,一个主控制端,一个被控制端,当然为了主控端得到被控端的连接信息,你可能会需要第三个自行开发的应用充当中间人的角色来传递连接信息。以下为一个完整应用的拓扑图: 主控与被控是两个大的对象,在它们内部维护了很多会话,这些会话可以动态的创建与销毁,每个会话都有各自特殊的功能,如图:Desktop会话可以实现主控与被控之间的远程桌面,File会话可以实现远程文件功能。 “你的服务器”用来传递被控端的连接信息与会话信息,让主控制端可以与被控制端进行通讯。 而“OrayServer”则默默的在背后为你的应用程序提供必要的通讯服务,保证你应用的数据传输。 使用规范 目录结构在开发库下你可以看到以下目录include、lib、bin、doc、samples。 include目录:所有SLAPI使用的API头文件,目前只有slsdk.h文件,用户只需要包含该文件即可使用SLAPI所有功能 bin目录:放有SLAPI运行时库,Windows下为slsdk.dll文件,运行时请将它放到运行程序所在的目录。放有SLAPI编译所需要的链接库,Windows下为slsdk.lib,编译时请链接该库 doc目录:所有SLAPI的使用说明与相关文档 samples目录:所有SLAPI应用实例 使用开发库分为三个阶段,1:环境初始化,2:创建主/被控制端,3:创建会话。 环境初始化使用SLInitialize函数初始化SLAPI环境。同样在进程退出前请调用SLUninitialize函数退出并析构整个环境。 另外在整个生命期中,可以使用SLGetLastError函数来获取当前的错误代码,方便你调试自己的应用程序,也可以使用SLSetLastError函数来设置当前的错误代码。最后,可以使用SLGetErrorDesc函数将错误代码转化为文本信息,方便查看。 创建被控制端使用SLCreateClient函数创建被控制端,然后使用SLSetClientCallback函数设置被控制端的事件回调函数,这样就可以获取控制端的状态和事件信息。 使用SLClientLogin函数来登录到贝锐服务器,登录成功后利用SLGetClientAddress函数来获取被控制端的连接信息,使用此信息主控端就可以与被控制端通讯了。注意:当回调事件为SLCLIENT_EVENT_ONLOGIN时,才算登录成功。 当不再使用这个被控制端时,可以使用SLDestroyClient函数将其销毁。 创建主控制端使用SLCreateRemote函数创建主控制端。 使用SLDestroyRemote函数销毁主控制端 创建被控制端会话当被控制端创建完后,就可以创建会话了,每种功能的会话都有固定的API来创建,如SLCreateClientSession函数用来创建远程桌面的会话,所有创建后的会话,都可以使用SLDestroyClientSession函数来销毁。 被控制端创建的所有会话都有一个会话序列号(字符串形式),使用该序列号,主控制端就可以连接指定会话了,这个序列号可以使用SLGetSessionName函数来获取。 最后所有的会话在API中都定义为SLSESSION类型,主控制端也是如此。 注意:被控端会话只能使用一次,一旦被主控端连接该会话后就失效,不能再连接。请销毁后再创建新的使用。被控端会话可以同时创建多个 创建主控制端会话当主控制端创建完后,就可以创建会话了,每种功能的会话都有固定的API来创建,如SLCreateRemoteSession函数用来创建远程桌面的会话,该函数创建的会话用来和被控制端使用SLCreateClientSession创建出来的会话对接并通讯。 主控制端创建会话与被控制端创建会话略有不同,它需要提供被控制端的连接信息和会话序列号信息,这两个信息可以使用上面所提到的SLGetClientAddress函数和SLGetSessionName函数来获取。 快速集成集成的大致流程如下图所示。如果远程只是软件产品的一小部分,可直接在发起远程的时候顺序调用上述API,而不必在程序初始化阶段就调用登录的API(这样做相当于是与服务器保持长连接,Demo示例为此模式),建议是在需要远程的时候登录,断开远程的时候销毁。 WEB 服务当开启了web服务后,可以用websocket连接进来控制或获取被控端的状态。 协议说明Web服务传输协议用的是json格式数据包。每个json数据包里都应该包含id和name字段。Id是一个不重复的整形,name是调用的方法名。 例子: { “id” : 1, //包id “name” : “newsession” //方法名,newsession为创建一个新的远程会话 “type” : type //会话类型 }如果调用的方法有附带参数,要把参数放在data字段下。 例子: { “id” : 2, //包id “name” : “destroysession”, //方法名,destroysession为销毁会话 “data” : { “sessionid” : 1 //销毁sessionid等于1的会话 } }服务端收到请求数据后,返回请求的id、name以及处理结果code,code等于0表示成功,其他值参考SLGetLastError的返回值 例子: { “id” : 1, //包id “name” : “newsession”, //方法名,newsession为创建一个新的远程桌面会话 “code” : 0, //操作结果,0表示成功 “data” : { “sessionid” : 0 //sessionid “address” : “xxxxxx” //服务器地址 “sessionname” : “xxxxxx” //session } }客户端接收到返回值后,应该判断id是否为发出请求的id,确保正确的收到返回结果。 Web 服务提供的方法Web每一次发送请求都会得到对应请求操作的执行结果,即一问一答;对于特定的事件,服务器内部会创建额外的监听,当状态发生改变,会主动以事件通知的形式推送给客户端。为了保证Web多连接的同步,服务器的被动响应和主动通知都采用广播的形式,一旦外部操作或内部变化,所有的连接都能及时收到同一通知。 下表1-7为web的请求方式及返回说明,8为服务器主动通知事件,9为会话回调通知。 1.OPENID登录 name: ”login_openid” 参数: openid:开发者的ID号 openkey:开发者ID对应的验证码 例子: { “id” : 1, “name” : “login_openid”, “data” : { “openid” : “xxxxxx”, “openkey” : “xxxxxx” } } 返回: { “id” : 1, “name” : “login\_openid”, “data” : “”, “code” : 0 //参考10.错误代码 } 2.License登录 name: ”login\_license” 参数: address:服务器地址 license:服务器license 例子: { “id” : 1, “name” : “login\_license”, “data” : { “address” : “xxxxxx”, “license” : “xxxxxx” } } 返回: { “id” : 1, “name” : “login\_license”, “data” : “”, “code” : 0 //参考10.错误代码 } 3.注销 name: ”logout” 例子: { “id” : 2, “name” : “logout”, } 返回: { “id” : 2, “name” : “logout”, “code” : 0 //参考10.错误代码 } 4.创建远程桌面会话 name: ”newsession” 例子: { “id” : 3, “name” : “newsession” “type” :0 } 返回: { “id” : 3, “name” : “newsession”, “code” : 0, //参考10.错误代码 “data” : { “address” : “xxxxxx”, “sessionid” : 0, “sessionname” : “xxxxxx” } } 5.销毁会话 name: ”destroysession” 参数: sessionid: 要销毁的sessionid 例子: { “id” : 4, “name” : “destroysession”, “data” : { “sessionid” : 1 } } 返回: { “id” : 4, “name” : “destroysession”, “data” : “”, “code” : 0 //参考10.错误代码 } 6.开启远程桌面 name: ”assist” 参数: address: 地址 session:会话 例子: { “id” : 5, “name” : “assist”, “data” : { “address” : “xxxxxx”, “session” : ”xxxxxx” } } 返回: { “id” : 5, “name” : “assist”, “data” : “”, “code” : 0 //参考10.错误代码 } 7.获取当前状态 name: ”get_status” 例子: { “id” : 6, “name” : “get\_status”, } 返回: { “id” : 6, “name” : “get\_status”, “code” : 0, //参考10.错误代码 “data” : { “is\_logginned” : true, “session” : [ { “addr” : “xxxxxx”, “connected” : true, “name” : “xxxxxx”, “sessionid” : 0 } { .... } ... { ... } ] //session集合 } } 8.事件通知 事件通知是服务端主动推送的,为了防止id重复,所以json包是不带id字段的 name: ”event” 参数: evnet: 事件ID 例子: { “name” : “evnet”, “data” : { “evnet” : 1 //参考11.被控端事件代码 } } 注:登录会触发连接,登录成功(or失败)事件,注销会触发断开连接事件。 9.会话回调通知 当创建一个会话后,会建立一个关于此会话的回调接口,当此会话状态发生变化时,会触发此回调事件。 name: ”sessionevt” 参数: evt: 事件ID id: 会话ID 例子: { “name” : “sessionevt”, “data” : { “evnet” : 1, //参考12.会话事件代码 “id” : 0 //会话ID } } 注:assist会触发其连接事件,destory和手动关闭会触发其断开连接事件。 扩展可以根据自己的需求对协议进行扩展。调用APISlSetWebServerFilter方法可以设置一个过滤方法,在过滤方法里,你可以尽情发挥。 提示: SlWebServerSend方法可以想web客户端发送数据。 过滤方法里返回true,代表已经处理了该数据,底层将不会再处理 API 详细说明 SLInitialize原型:bool SLInitialize(void); 功能:初始化正个SLAPI环境 返回:是否初始化成功 说明:在调用所有其他任何API之前调用,总之是应用程序中第一个调用的API SLUninitialize原型:bool SLUninitialize(void); 功能:退出并析构整个SLAPI环境 返回:是否成功 说明:程序退出前调用,总之是应用程序中最后一个调用的API SLGetLastError原型:SLERRCODE SLGetLastError(void) 功能:获取最后的错误码 返回:返回SLERRCODE错误码 说明:除了SLInitialize函数之外,任何API函数返回错误时,都可以用该API来获取失败的原因。该错误码是基于TLS的,线程上保持安全。 SLSetLastError原型:bool SLSetLastError(SLERRCODE errCode) 功能:设置最后的错误码 返回:是否设置成功 说明:通常情况下用户不需要使用该API来设置错误码。 SLGetErrorDesc原型:const char* SLGetErrorDesc(SLERRCODE errCode) 功能:获取错误码详细说明 返回:详细信息,如果错误码不存在则返回“未知错误” SLCreateClient原型:SLCLIENT SLCreateClient(void) 功能:创建一个被控制端环境 返回:返回被控制端环境值,如果创建失败则返回SLCLIENT_INVAILD 说明:返回值将用于后面很多的被控制端API函数中 SLDestroyClient原型:bool SLDestroyClient(SLCLIENT client) 功能:销毁一个被控制端环境 参数:client 由SLCreateClient创建出来的值 返回:是否销毁成功 说明:参数必须是由SLCreateClient函数创建出来的值,否则可能产生未定义后果 SLStartWebServer原型:SUNLOGIN_API bool SLStartWebServer(SLCLIENT client, unsigned int nPort=0); 功能:开启web监听服务,用户可以用websocket连接进来控制或查看状态 参数: client 由SLCreateClient创建出来的被控制端环境 nPort 要监听的端口号,默认是17801 返回:如果创建失败则返回false 说明:web监听服务的协议参考 SLStopWebServer原型:SUNLOGIN_API bool SLStopWebServer(SLCLIENT client); 功能:关闭web监听服务 参数: client 由SLCreateClient创建出来的被控制端环境 返回:如果失败则返回false SlSetWebServerFilter原型:SUNLOGIN_API bool SlSetWebServerFilter(SLCLIENT client,SLWEB_FILTER filter); 功能:关闭web监听服务 参数: client 被控制端环境 filter 函数指针 返回:如果失败则返回false SlWebServerSend原型:SUNLOGIN_API bool SlWebServerSend(SLCLIENT client,const void* pdata,unsigned int size); 功能:向web客户端发送数据 参数: client 被控制端环境 data 指向数据的指针 size 数据长度 返回:如果失败则返回false SLSetClientCallback原型:bool SLSetClientCallback(SLCLIENT client, SLCLIENT_CALLBACK pfnCallback, unsigned long custom) 功能:设置被控制端事件回调函数 参数: client 由SLCreateClient创建出来的被控制端环境 pfnCallback 回调函数,当被控制端发生事件时,会通过该函数回调 cusom 用户自定义参数,回调时内部程序会将此参数一并回调 返回:是否设置成功 SLClientLoginWithOpenID原型:bool SLClientLoginWithOpenID(SLCLIENT client, const char pstrOpenID, const char pstrOpenKey, const char* pstrDomain = “”, bool bUseSSL = false) 功能:被控制端登录服务器 参数: client 由SLCreateClient创建出来的被控制端环境 pstrOpenID 开发者的ID号 pstrOpenKey 开发者ID对应的验证码 pstrDomain OpenID登陆验证所指定的服务器的域名(可以默认) bUseSSL 配合pstrDomain使用,是否使用SSL 返回:是否登录出错,登录错出会返回false,但返回true不代码登录成功,如果想知道登录成功,必须通过回调SLCLIENT_EVENT_ONLOGIN事件得知 说明:开发者ID和验证码获取方式可参见本文“开发者账号”段落 SLClientLoginWithLicense原型:bool SLClientLoginWithLicense(SLCLIENT client, const char szAddr, const char szLic) 功能:被控制端登录服务器 参数: client 由SLCreateClient创建出来的被控制端环境 szAddr 服务器地址 szLic 服务器lincese 返回:是否登录出错,登录错出会返回false,但返回true不代码登录成功,如果想知道登录成功,必须通过回调SLCLIENT_EVENT_ONLOGIN事件得知 说明:该方法是提供给购买了定制服务器的用户使用的 SLClientIsOnLoginned原型:bool SLClientIsOnLoginned(SLCLIENT client) 功能:被控制端是否已经登录服务器 参数: client 由SLCreateClient创建出来的被控制端环境 返回:是否已经登录服务器 SLCreateClientSession原型:SLSESSION SLCreateClientSession(SLCLIENT client, ESLSessionType eType) 功能:在被控制端环境中创建一个远程会话 参数: client 由SLCreateClient创建出来的被控制端环境 eType 会话类型 返回:会话,如果失败则返回SLSESSION_INVAILD SLDestroyClientSession原型:bool SLDestroyClientSession(SLCLIENT client, SLSESSION session) 功能:销毁一个会话 参数: client 由SLCreateClient创建出来的被控制端环境 session 会话 返回:是否销毁成功 说明:session必须是由SLCreateClient***Session函数创建出来的Session值,不然可能产生未定义后果 SLEnumClientSession原型:unsigned int SLEnumClientSession(SLCLIENT client, SLSESSION* pSessionArray, unsigned int nArraySize) 功能:销毁一个会话 参数: client 由SLCreateClient创建出来的被控制端环境 pSessionArray 会话数组用于返回数据 nArraySize 会话数组长度,一般填256 返回:返回了多少个会话 说明:session必须是由SLCreateClient***Session函数创建出来的Session值,不然可能产生未定义后果 SLGetClientAddress原型:const char* SLGetClientAddress(SLCLIENT client) 功能:获取被控制端连接地址 参数:client 由SLCreateClient创建出来的被控制端环境 返回:地址 说明:必须在收到SLCLIENT_EVENT_ONLOGIN事件后,即使用开发者账号登录成功后才能调用本API,不然返回的值将是无效值。将该返回值告诉主控端,主控端就可以和该被控制端通讯了 SLGetClientSessionName原型:const char* SLGetClientSessionName(SLCLIENT client, SLSESSION session) 功能:获取被控制端某个会话的值 参数: client 由SLCreateClient创建出来的被控制端环境 session 会话 返回:会话值 说明:通过该值主控制端才能使用该会话的服务 SLClientSessionSendData原型:unsigned long SLClientSessionSendData(SLCLIENT client, SLSESSION session, const char* lpData, unsigned long nLen) 功能:会话发送数据 参数: client 由SLCreateClient创建出来的被控制端环境 session 会话 lpData 发送的数据 nLen 发送的数据长度 返回:实际发送的字节数,返回0表示出错 说明:目前只适用于DataTrans类型的会话 SLClientSessionRecvData原型:unsigned long SLClientSessionRecvData(SLCLIENT client, SLSESSION session, char* lpData, unsigned long nLen) 功能:会话接收数据 参数: client 由SLCreateClient创建出来的被控制端环境 session 会话 lpData 接收数据 nLen 准备接收的数据长度 返回:实际收到的字节数,返回0表示出错 说明:目前只适用于DataTrans类型的会话 SLGetClientSessionOpt原型:bool SLGetClientSessionOpt(SLCLIENT client, SLSESSION session, ESLSessionOpt eOpt, char* pOptVal, unsigned int nOptLen) 功能:获取被控制端某个会话某个属性值 参数: client 由SLCreateClient创建出来的被控制端环境 session 会话 eOpt 属性名 pOptVal 属性值 nOptLen 属性值长度 返回:是否获取成功 SLSetClientSessionOpt原型:bool SLSetClientSessionOpt(SLCLIENT client, SLSESSION session, ESLSessionOpt eOpt, const char* pOptVal, unsigned int nOptLen) 功能:设置被控制端某个会话某个属性值 参数: client 由SLCreateClient创建出来的被控制端环境 session 会话 eOpt 属性名 pOptVal 属性值 nOptLen 属性值长度 返回:是否设置成功 SLCreateRemote原型:SLREMOTE SLCreateRemote(void) 功能:创建一个控制端环境 返回:返回被控制端环境值,如果创建失败则返回SLREMOTE_INVAILD 说明:返回值将用于后面很多的主控制端API函数中 SLDestroyRemote原型:bool SLDestroyRemote(SLREMOTE remote) 功能:销毁一个控制端环境 参数:remote 由SLCreateRemote创建出来的主控制端环境 返回:是否销毁成功 说明:参数必须是由SLCreateRemote函数创建出来的值,否则可能产生未定义后果 SLSetRemoteCallback原型:bool SLSetRemoteCallback(SLREMOTE remote, SLREMOTE_CALLBACK pfnCallback, unsigned long custom) 功能:设置主控制端事件回调函数 参数: remote 由SLCreateRemote创建出来的主控制端环境 pfnCallback 回调函数,当被控制端发生事件时,会通过该函数回调 cusom 用户自定义参数,回调时内部程序会将此参数一并回调 返回:是否设置成功 SLCreateRemoteSession原型:SLSESSION SLCreateRemoteSession(SLREMOTE remote, ESLSessionType eType, const char pstrAddress, const char pstrSession) 功能:创建远程会话 参数: remote 由SLCreateRemote创建出来的主控制端环境 eType 会话类型 pstrAddress 远程被控制端地址,由SLGetClientAddress函数返回的值 pstrSession 远程桌面会话名,由SLGetSessionName函数返回的值 返回:会话,如果失败则返回SLSESSION_INVALD SLCreateRemoteEmptySession原型:SLSESSION SLCreateRemoteEmptySession(SLREMOTE remote, ESLSessionType eType) 功能:创建远程空会话 参数: remote 由SLCreateRemote创建出来的主控制端环境 eType 会话类型 返回:会话,如果失败则返回SLSESSION_INVALD 说明:和SLCreateRemoteSession不同的是创建一个空会话,不进行连接,后面必须再使用SLConnectRemoteSession来连接会话 SLConnectRemoteSession原型:SLSESSION SLConnectRemoteSession(SLREMOTE remote, SLSESSION session, const char pstrAddress, const char pstrSession) 功能:连接远程空会话 参数: remote 由SLCreateRemote创建出来的主控制端环境 pstrAddress 远程被控制端地址,由SLGetClientAddress函数返回的值 pstrSession 远程桌面会话名,由SLGetSessionName函数返回的值 返回:会话,如果失败则返回SLSESSION_INVALD 说明:只用于SLCreateRemoteEmptySession创建出来的会话 SLDestroyRemoteSession原型:bool SLDestroyRemoteSession(SLREMOTE remote, SLSESSION session) 功能:销毁一个会话 参数: remote 由SLCreateRemote创建出来的主控制端环境 session 由SLCreateRemote***Session创建出来的会话值 返回:是否销毁成功 说明:session必须是由SLCreateRemote***Session函数创建出来的Session值,不然可能产生未定义后果 SLRemoteSessionSendData原型:unsigned long SLRemoteSessionSendData(SLCLIENT client, SLSESSION session, const char* lpData, unsigned long nLen) 功能:会话中发送数据,另一端会话会收到数据 参数: remote 由SLCreateRemote创建出来的主控制端环境 session 会话 lpData 发送的数据 nLen 发送的数据长度 返回:实际发送的字节数 说明:目前只适用于DataTrans类型的会话 SLRemoteSessionRecvData原型:unsigned long SLRemoteSessionRecvData(SLREMOTE remote, SLSESSION session, char* lpData, unsigned long nLen) 功能:会话接收数据 参数: remote由SLCreateRemote创建出来的主控制端环境 session 会话 lpData 接收数据 nLen 准备接收的数据长度 返回:实际收到的字节数,返回0表示出错 说明:目前只适用于DataTrans类型的会话 SLGetRemoteSessionOpt原型:bool SLGetRemoteSessionOpt(SLCLIENT client, SLSESSION session, ESLSessionOpt eOpt, char* pOptVal, unsigned int nOptLen) 功能:获取主控制端某个会话某个属性值 参数: client 由SLCreateRemote创建出来的主控制端环境 session 会话 eOpt 属性名 pOptVal 属性值 nOptLen 属性值长度 返回:是否获取成功 SLSetRemoteSessionOpt原型:bool SLSetRemoteSessionOpt(SLREMOTE remote, SLSESSION session, ESLSessionOpt eOpt, const char* pOptVal, unsigned int nOptLen) 功能:设置主控制端某个会话某个属性值 参数: remote由SLCreateRemote创建出来的主控制端环境 session 会话 eOpt 属性名 pOptVal 属性值 nOptLen 属性值长度 返回:是否设置成功 SLSetDesktopSessionPos原型:bool SLSetDesktopSessionPos(SLREMOTE remote, SLSESSION session, int x,int y,int width,int height) 功能:设置远程桌面窗口的大小 参数: remote 由SLCreateRemote创建出来的主控制端环境 session 会话 x x坐标 y y坐标 width宽度 height高度 返回:是否设置成功 SLSetClientProxy原型:bool SLSetClientProxy(SLCLIENT client, const SLPROXY_INFO& proxy) 功能:设置被控端代理 参数: client 由SLCreateClient创建出来的被控制端环境 proxy代理信息 返回:是否设置成功 SLSetRemoteProxy原型:bool SLSetRemoteProxy(SLREMOTE remote, const SLPROXY_INFO& proxy) 功能:设置被控端代理 参数: remote由SLCreateRemote创建出来的主控制端环境 proxy代理信息 返回:是否设置成功 SLSetDesktopSessionVisible原型:bool SLSetDesktopSessionVisible( SLREMOTE remote, SLSESSION session ) 功能:设置显示远程桌面 参数: remote由SLCreateRemote创建出来的主控制端环境 session 会话 返回:是否设置成功 SLGetDesktopSessionOriginSize原型:bool SLGetDesktopSessionOriginSize( SLREMOTE remote, SLSESSION session, int width, int height ); 功能:获取远程桌面原图大小 参数: remote由SLCreateRemote创建出来的主控制端环境 session 会话 width 桌面原图宽度 height 桌面原图高度 返回:是否设置成功 SLLoginWithOpenID原型:bool SLLoginWithOpenID(SLCLIENT client, const char pstrOpenID, const char pstrOpenKey, const char* pstrDomain = “”, bool bUseSSL = false) 功能:功能同SLClientLoginWithOpenID, 简化名称 参数: client 由SLCreateClient创建出来的被控制端环境 pstrOpenID 开发者的ID号 pstrOpenKey 开发者ID对应的验证码 pstrDomain OpenID登陆验证所指定的服务器的域名(可以默认) bUseSSL 配合pstrDomain使用,是否使用SSL 返回:是否设置成功 SLClientSendFile原型:SLUINT32 SLAPI SLClientSendFile(SLCLIENT client, SLSESSION session, const wchar_t* filepath, bool resume ) 功能:发送一个文件 参数: client 由SLCreateClient创建出来的被控制端环境 session 会话 filepath 发送文件的路径 resume 是否断点续传,否则重新发送文件 返回:文件id, 0代表失败 SLClientKillFile原型:bool SLAPI SLClientKillFile(SLCLIENT client, SLSESSION session, SLUINT32 fid ) 功能:取消发送文件 参数: client 由SLCreateClient创建出来的被控制端环境 session 会话 fid 文件id 返回:是否成功 SLClientGetFileName原型:const wchar_t* SLAPI SLClientGetFileName( SLCLIENT client, SLSESSION session, SLUINT32 fid ) 功能:获取文件路径名称 参数: client 由SLCreateClient创建出来的被控制端环境 session 会话 fid 文件id 返回:文件路径名称 SLClientGetFileSize原型:SLUINT64 SLAPI SLClientGetFileSize( SLCLIENT client, SLSESSION session, SLUINT32 fid ) 功能:获取传输的文件大小 参数: client 由SLCreateClient创建出来的被控制端环境 session 会话 fid 文件id 返回:文件大小 SLClientGetFileTransfered原型:SLUINT64 SLAPI SLClientGetFileTransfered( SLCLIENT client, SLSESSION session, SLUINT32 fid ) 功能:获取文件已传输的大小 参数: client 由SLCreateClient创建出来的被控制端环境 session 会话 fid 文件id 返回:文件已传输的大小 SLClientFileIsTransfering原型:bool SLAPI SLClientFileIsTransfering( SLCLIENT client, SLSESSION session, SLUINT32 fid ) 功能:文件是否正在传输中 参数: client 由SLCreateClient创建出来的被控制端环境 session 会话 fid 文件id 返回:true 正在传输,false 其他状态 SLClientFileIsDone原型:bool SLAPI SLClientFileIsDone( SLCLIENT client, SLSESSION session, SLUINT32 fid ); 功能:文件传输是否完成 参数: client 由SLCreateClient创建出来的被控制端环境 session 会话 fid 文件id 返回:true 传输完成 false 其他状态 SLClientFileIsKilled原型:bool SLAPI SLClientFileIsKilled( SLCLIENT client, SLSESSION session, SLUINT32 fid ); 功能:文件是否被取消传输 参数: client 由SLCreateClient创建出来的被控制端环境 session 会话 fid 文件id 返回:true 传输被取消 false 其他状态 SLRemoteSendFile原型:SLUINT32 SLAPI SLRemoteSendFile(SLREMOTE remote, SLSESSION session, const wchar_t* filepath, bool resume ) 功能:发送一个文件 参数: remote由SLCreateRemote创建出来的主控制端环境 session 会话 filepath 发送文件的路径 resume 是否断点续传,否则重新发送文件 返回:文件id, 0代表失败 SLRemoteKillFile原型:bool SLAPI SLRemoteKillFile(SLREMOTE remote, SLSESSION session, SLUINT32 fid ) 功能:取消发送文件 参数: remote由SLCreateRemote创建出来的主控制端环境 session 会话 fid 文件id 返回:是否成功 SLRemoteGetFileName原型:const wchar_t* SLAPI SLRemoteGetFileName( SLREMOTE remote, SLSESSION session, SLUINT32 fid ) 功能:获取文件路径名称 参数: remote由SLCreateRemote创建出来的主控制端环境 session 会话 fid 文件id 返回:文件路径名称 SLRemoteGetFileSize原型:SLUINT64 SLAPI SLRemoteGetFileSize(SLREMOTE remote, SLSESSION session, SLUINT32 fid ) 功能:获取传输的文件大小 参数: remote由SLCreateRemote创建出来的主控制端环境 session 会话 fid 文件id 返回:文件大小 SLRemoteGetFileTransfered原型:SLUINT64 SLAPI SLRemoteGetFileTransfered(SLREMOTE remote, SLSESSION session, SLUINT32 fid ) 功能:获取文件已传输的大小 参数: remote由SLCreateRemote创建出来的主控制端环境 session 会话 fid 文件id 返回:文件已传输的大小 SLRemoteFileIsTransfering原型:bool SLAPI SLRemoteFileIsTransfering(SLREMOTE remote, SLSESSION session, SLUINT32 fid ) 功能:文件是否正在传输中 参数: remote由SLCreateRemote创建出来的主控制端环境 session 会话 fid 文件id 返回:true 正在传输,false 其他状态 SLRemoteFileIsDone原型:bool SLAPI SLRemoteFileIsDone( SLREMOTE remote, SLSESSION session, SLUINT32 fid ); 功能:文件传输是否完成 参数: remote由SLCreateRemote创建出来的主控制端环境 session 会话 fid 文件id 返回:true 传输完成 false 其他状态 SLRemoteFileIsKilled原型:bool SLAPI SLClientFileIsKilled( SLREMOTE remote, SLSESSION session, SLUINT32 fid ); 功能:文件是否被取消传输 参数: remote由SLCreateRemote创建出来的主控制端环境 session 会话 fid 文件id 返回:true 传输被取消 false 其他状态 SLCreateClientEx原型:bool SLAPI SLCreateClientEx( SLMODE mode ); 功能:根据应用(UI,Service)场景创建向日葵客户端 参数: mode - 应用场景 返回:返回被控制端环境值,如果创建失败则返回SLCLIENT_INVAILD SLOpenClientLog原型:bool SLAPI SLOpenClientLog(SLCLIENT client, const char* path); 功能:启用被控制端的日志输出 参数: client 由SLCreateClient创建出来的被控制端环境 path 日志的输出路径 返回:是否设置成功 SLOpenRemoteLog原型:bool SLAPI SLOpenRemoteLog(SLREMOTE remote, const char* path); 功能:启用主控制端的日志输出 参数: remote由SLCreateRemote创建出来的主控制端环境 path 日志的输出路径 返回:是否设置成功 SLSetCmdSessionPos原型:bool SLSetCmdSessionPos(SLREMOTE remote, SLSESSION session, int x,int y,int width,int height) 功能:设置远程CMD窗口的大小 参数: remote 由SLCreateRemote创建出来的主控制端环境 session 会话 x x坐标 y y坐标 width宽度 height高度 返回:是否设置成功 SLSetCameraSessionPos原型:bool SLSetCameraSessionPos(SLREMOTE remote, SLSESSION session, int x,int y,int width,int height) 功能:设置远程摄像头窗口的大小 参数: remote 由SLCreateRemote创建出来的主控制端环境 session 会话 x x坐标 y y坐标 width宽度 height高度 返回:是否设置成功 SLRemoteCameraOpen原型:bool SLAPI SLRemoteCameraOpen(SLREMOTE remote, SLSESSION session, LONG dev_id); 功能:打开一个远程摄像头设备 参数: remote 由SLCreateRemote创建出来的主控制端环境 session 会话 dev_id 摄像头的唯一标识,由SLRemoteCameraGetList函数获取 返回:是否打开成功 SLRemoteCameraClose原型:bool SLAPI SLRemoteCameraClose(SLREMOTE remote, SLSESSION session); 功能:关闭当前正在使用的远程摄像头设备 参数: remote 由SLCreateRemote创建出来的主控制端环境 session 会话 返回:是否关闭成功 SLRemoteCameraSetDefinition原型:bool SLAPI SLRemoteCameraSetDefinition(SLREMOTE remote, SLSESSION session, ESLVideoDefinition eVD); 功能:设置当前摄像头的清晰度 参数: remote 由SLCreateRemote创建出来的主控制端环境 session 会话 eVD ESLVideoDefinition枚举值,主要有标清,高清,超清 返回:是否设置成功 SLRemoteCameraGetList原型:unsigned int SLAPI SLRemoteCameraGetList(SLREMOTE remote, SLSESSION session, CAMERA_INFO* infos = NULL, unsigned int nSize = 0); 功能:获取远程摄像头列表并返回摄像头个数,当infos为空时,此函数仅返回摄像头个数 参数: remote 由SLCreateRemote创建出来的主控制端环境 session 会话 infos CAMERA_INFO结构体数组,用于保存摄像头列表 nSize 结构体数组大小 返回:返回摄像头设备个数 SLDiscoverWoiDevice原型:bool SLAPI SLDiscoverWoiDevice(SLCLIENT client); 功能:扫描局域网内的开机棒设备,并通过SLCLIENT_WOI_CALLBACK回调返回设备的SN号 参数: client 由SLCreateClient创建出来的被控制端环境 返回:发送扫描请求成功或失败 SLBindWoiDevice原型:bool SLAPI SLBindWoiDevice(SLCLIENT client, const char pstrSN, const char pstrMac, const char* pstrPassword); 功能:绑定局域网内的开机棒设备,并通过SLCLIENT_WOI_CALLBACK回调返回绑定结果 参数: client 由SLCreateClient创建出来的被控制端环境 pstrSN 要绑定的开机棒的SN号 pstrMac 要绑定开机的MAC地址(AABBCCDDEEFF) pstrPassword 远程开机密码,与MAC地址一起唤醒设备 返回:发送绑定设备请求成功或失败 SLUnBindWoiDevice原型:bool SLAPI SLUnBindWoiDevice(SLCLIENT client, const char pstrSN, const char pstrMac, const char* pstrPassword); 功能:解绑局域网内的开机棒设备,并通过SLCLIENT_WOI_CALLBACK回调返回解绑结果 参数: client 由SLCreateClient创建出来的被控制端环境 pstrSN 要解绑的开机棒的SN号 pstrMac 要绑定开机的MAC地址(AABBCCDDEEFF) pstrPassword 远程开机密码,与MAC地址一起解绑设备 返回:发送解绑设备请求成功或失败 SLSetClientWOICallback原型:bool SLAPI SLSetClientWOICallback(SLCLIENT client, SLCLIENT_WOI_CALLBACK pfnCallback, unsigned long custom); 功能:设置远程开机棒事件回调,包括发现,绑定和解绑 参数: client 由SLCreateClient创建出来的被控制端环境 pfnCallback 回调函数,当操作开机棒发生事件时,会通过该函数回调 cusom 用户自定义参数,回调时内部程序会将此参数一并回调 返回:设置回调成功或失败 SLSetRemoteWOIControl原型:bool SLSetRemoteWOIControl(SLREMOTE remote, const char* pstrAddress, unsigned int nPort); 功能:设置远程开机服务器的ip和控制端口 参数: remote 由SLCreateRemote创建出来的主控制端环境 pstrAddress 远程开机服务器的IP地址 nPort 远程开机服务器的web控制端口 返回:设置成功或失败 SLSendWakeupCommand原型:bool SLAPI SLSendWakeupCommand(SLREMOTE remote, const char pstrMac, const char pstrPassword); 功能:发送远程唤醒指令 参数: remote 由SLCreateRemote创建出来的主控制端环境 pstrMac 待唤醒设备的Mac地址(AABBCCDDEEFF) pstrPassword 远程开机密码,与MAC地址一起唤醒设备 返回:发送唤醒成功或失败 SLSetRemoteWOICallback原型:bool SLAPI SLSetRemoteWOICallback(SLREMOTE remote, SLREMOTE_WOI_CALLBACK pfnCallback, unsigned long custom); 功能:设置远程开机事件回调 参数: remote 由SLCreateRemote创建出来的主控制端环境 pfnCallback 回调函数,当远程开机指令响应时,会通过该函数回调 cusom 用户自定义参数,回调时内部程序会将此参数一并回调 返回:设置回调成功或失败 SLGetRemoteSysinfo原型:unsigned int SLAPI SLGetRemoteSysinfo(SLREMOTE remote, SLSESSION session, const char pstrQuery, const char pstrContent); 功能:获取远程客户端的系统信息 参数: remote 由SLCreateRemote创建出来的主控制端环境 session 会话 pstrQuery 查询字符串\<参见13> pstrContent 查询内容\<参见13> 返回:当前操作的执行的编号(自1开始递增) SLHideRemoteDesktopToolbarItem原型:bool SLAPI SLHideRemoteDesktopToolbarItem(SLREMOTE remote, SLSESSION session, SLDesktopControlType eType); 功能:根据枚举值隐藏远程桌面工具栏上的对应模块 参数: remote 由SLCreateRemote创建出来的主控制端环境 session 主控端桌面会话 eType 远程桌面工具栏上各控制模块的枚举值[SLDesktopControlType] 返回:是否设置成功 SLGetRemoteDesktopDevList原型:unsigned int SLAPI SLGetRemoteDesktopDevList(SLREMOTE remote, SLSESSION session, SLDesktopDevType eType, SLBASE_INFO* infos = 0, unsigned int nSize = 0); 功能:获取远程桌面屏幕,会话,分辨率的信息列表并返回相应模块的个数,当infos为空时,此函数仅返回模块个数 参数: remote 由SLCreateRemote创建出来的主控制端环境 session 主控端桌面会话 eType 远程桌面中各信息模块的枚举值[SLDesktopDevType] infos SLBASE_INFO结构体数组,用于保存基本信息列表 nSize 结构体数组大小 返回:返回模块个数 SLSendRemoteDesktopCommand原型:bool SLAPI SLSendRemoteDesktopCommand(SLREMOTE remote, SLSESSION session, SLDesktopCommandType eType, unsigned int nIndex = 0); 功能:发送远程桌面控制命令 参数: remote 由SLCreateRemote创建出来的主控制端环境 session 主控端桌面会话 eType 远程桌面中各命令模块的枚举值[SLDesktopCommandType] nIndex 索引值,只针对于切换屏幕,切换会话,切换分辨率等选择性的命令有效 返回:是否执行成功 SLGetRemoteDesktopCurState原型:bool SLAPI SLGetRemoteDesktopCurState(SLREMOTE remote, SLSESSION session, SLDesktopStateType eType, unsigned int& nState); 功能:得到枚举的模块的当前状态值 参数: remote 由SLCreateRemote创建出来的主控制端环境 session 主控端桌面会话 eType 远程桌面中各状态模块的枚举值[SLDesktopStateType] nState [in]状态值,保存状态模块的当前状态值或索引值 返回:是否执行成功 SLRemoteDesktopScreenShot原型:bool SLAPI SLRemoteDesktopScreenShot(SLREMOTE remote, SLSESSION session, const char* filepath); 功能:截取一张远程桌面图像并保存 参数: remote 由SLCreateRemote创建出来的主控制端环境 session 主控端桌面会话 filepath 截屏文件的绝对路径(包含文件名) 返回:是否截屏成功 SLRemoteDesktopStartRecord原型:bool SLAPI SLRemoteDesktopStartRecord( SLREMOTE remote, SLSESSION session, const char* filepath ); 功能:远程桌面时,开启录像功能开始录像 参数: remote由SLCreateRemote创建出来的主控制端环境 session 主控端桌面会话 filepath 保存的录屏文件的全路径,包含文件名(后缀一般为.ts) 返回:是否开启录像成功 SLRemoteDesktopStopRecord原型:void SLAPI SLRemoteDesktopStopRecord( SLREMOTE remote, SLSESSION session ); 功能:远程桌面时,停止当前录像 参数: remote由SLCreateRemote创建出来的主控制端环境 session 主控端桌面会话 返回:无 SLSetRemoteDesktopPlatform原型:bool SLAPI SLSetRemoteDesktopPlatform(SLREMOTE remote, SLSESSION session, SLPlatformType eType); 功能:远程桌面时手动设置被控制端的平台信息,主要用于在主控端显示不同样式的控制菜单 参数: remote由SLCreateRemote创建出来的主控制端环境 session 主控端桌面会话 eType被控端平台枚举值[SLPlatformType] 返回:是否设置成功 SLClientStartChat原型:bool SLAPI SLClientStartChat(SLCLIENT client, SLSESSION session, bool bShow = true); 功能:被控端主动发起聊天,弹出聊天窗口 参数: client由SLCreateClient创建出来的被控制端环境 session 被控端桌面会话 bShow 是否显示窗口。如果为true,则为初始化创建窗口(仅针对Mac OSX有效) 返回:是否发起成功 SLClientEnableControl原型:bool SLAPI SLClientEnableControl(SLCLIENT client, SLSESSION session, bool bEnable); 功能:被控端切换控制/观看模式 参数: client由SLCreateClient创建出来的被控制端环境 session 被控端桌面会话 bEnable是否为控制模式 返回:是否切换成功 SLGetClientSessionConnection原型:bool SLAPI SLGetClientSessionConnection(SLCLIENT client, SLSESSION session, bool& isp2p, bool& islocal); 功能:获取被控端当前会话的连接信息(是否是p2p连接,是否是本地局域网互联) 参数: client由SLCreateClient创建出来的被控制端环境 session 会话 isp2p 是否是p2p连接 islocal 是否是本地局域网互联 返回:是否获取成功 SLGetRemoteSessionConnection原型:bool SLAPI SLGetRemoteSessionConnection(SLREMOTE remote, SLSESSION session, bool& isp2p, bool& islocal); 功能:获取主控端当前会话的连接信息(是否是p2p连接,是否是本地局域网互联) 参数: remote由SLCreateRemote创建出来的主控制端环境 session 会话 isp2p 是否是p2p连接 islocal 是否是本地局域网互联 返回:是否获取成功 SLSetSshSessionPos原型:bool SLSetSshSessionPos(SLREMOTE remote, SLSESSION session, int x,int y,int width,int height) 功能:设置远程SSH窗口的大小 参数: remote 由SLCreateRemote创建出来的主控制端环境 session 会话 x x坐标 y y坐标 width宽度 height高度 返回:是否设置成功 SLSetFileMgrSessionPos原型:bool SLSetFileMgrSessionPos(SLREMOTE remote, SLSESSION session, int x,int y,int width,int height) 功能:设置远程文件管理窗口的大小 参数: remote 由SLCreateRemote创建出来的主控制端环境 session 会话 x x坐标 y y坐标 width宽度 height高度 返回:是否设置成功 会话属性 概述每种类型的会话都可以设置其属性达到不同的效果,如远程桌面可以设置eSessionOpt_window来设置其远程桌面的显示窗口,同样也可以获取某个属性的属性值。 ESLSessionOpt枚举了所有可以使用的会话属性,你可以使用SLGetClientSessionOpt和SLSetRemoteSessionOpt来获取会话属性,可以使用SLSetClientSessionOpt和SLSetRemoteSessionOpt来设置会话属性。 有的属性只能用在被控制端,有的属性只能用在主控制端,有的两者都可以使用,有的属性只能设置不能获取,有的属性只能获取不能设置。以下将详细介绍各个属性的使用方式。 eSLSessionOpt_window适用环境:主控制端环境 适用会话:远程桌面会话,远程CMD会话,远程摄像头会话 适用方式:设置 功能:设置主控制端显示远程桌面的窗口句柄 参数: pOptVal 窗口句柄指针,在Windows下为HWND* nOptLen 窗口句柄字节数,在Windows下为sizeof(HWND) eSLSessionOpt_deviceSource适用环境:被控制端环境 适用会话:远程声音会话 适用方式:设置/获取 功能:设置被控制端传出声音是从声卡上传出还是麦克风传出 参数: pOptVal 是否为麦克风传出,bool类型,true为是,false为否(即声卡传出) nOptLen bool类型长度,即1个字节 eSLSessionOpt_connected适用环境:被控制端环境 适用会话:所有会话 适用方式:获取 功能:获取当前会话是否已经连接还是未连接 参数: pOptVal 是bool类型,true为已连接,false为未连接 nOptLen bool类型长度,即1个字节 eSLSessionOpt_ipport适用环境:主控制端环境 适用会话:所有会话 适用方式:设置 功能:设置端口转发的本地服务的ip地址和端口 参数: pOptVal const char*类型,格式为 ip:port,具体请参考示例程序 nOptLen const char*类型长度 eSLSessionOpt_savepath适用环境:主控被控制端环境 适用会话:所有会话 适用方式:设置 功能:设置文件传输保存路径 参数: pOptVal const wchar_t* 类型 nOptLen const wchar_t 类型长度 2,具体请参考示例程序 错误代码代码(code) 定义 说明0 SLERRCODE_SUCCESSED 成功1 SLERRCODE_INNER 内部错误2 SLERRCODE_UNINITIALIZED 未初始化3 SLERRCODE_ARGS 参数错误4 SLERRCODE_NOTSUPPORT 不支持5 SLERRCODE_CONNECT_FAILED 网络连接失败6 SLERRCODE_CONNECT_TIMEOUT 网络连接超时7 SLERRCODE_SESSION_NOTEXIST 会话不存在8 SLERRCODE_SESSION_OVERFLOW 会话溢出9 SLERRCODE_SESSION_WRONGTYPE 会话类型错误10 SLERRCODE_EXPIRED OPENID过期11 SLERRCODE_REQUEST_FREQUENT 请求频繁 被控端事件代码代码(code) 定义 说明0 SLCLIENT_EVENT_ONCONNECT 连接成功1 SLCLIENT_EVENT_ONDISCONNECT 断开连接2 SLCLIENT_EVENT_ONLOGIN 登录成功3 SLCLIENT_EVENT_ONLOGINFAIL 登录失败4 SLCLIENT_EVENT_ONCHANNELSFULL 连接通道已满5 SLCLIENT_EVENT_ONCHECKCFAIL 检查通道数失败 会话事件代码代码(code) 定义 说明1 eSLSessionEvent_OnConnected 连接成功2 eSLSessionEvent_OnDisconnected 断开连接3 eSLSessionEvent_OnDisplayChanged 分辨率改变4 eSLSessionEvent_OnNewFiletrans 新文件传输5 eSLSessionEvent_OnGetRemoteSysinfo 远程系统信息回调 远程客户端系统信息当主控端和被控端建立远程系统信息的连接后,主控端可以调用SLGetRemoteSysinfo函数来获取和修改被控端系统的一些基本信息,其中包括性能检测、事件查看、进程信息、服务、本地用户和组、共享资源和环境变量等信息。具体指令和响应数据结构如下表所示(获取信息返回xml数据结构,执行命令返回JSON数据结构): 系统信息 参数1(QueryStri
中英文CN域名在线注册服务协议
感谢您选择上海贝锐信息科技股份有限公司(以下简称“贝锐”)的中英文CN域名在线注册服务。 请您认真细致地阅读以下的贝锐中英文CN域名在线注册服务条款。用户只有同意了下述服务条款才能正式进入域名在线注册程序。如果您愿意接受我们的服务并同意此条款,请点击“我同意”继续进行注册;否则,请点击“我不同意”并退出。贝锐建议用户在接受本服务条款之时打印一份存档。 中英文CN域名在线注册服务条款 用户在此保证所填写的用户信息是真实、准确、完整的,并且没有任何引人误解或者虚假的陈述。违反本规定的一切责任由用户自行承担。 贝锐有权根据《中国互联网络域名管理办法》的规定对用户提供的域名注册申请进行审核,对于违反《中国互联网络域名管理办法》规定的域名予以删除,并对此删除行为所造成的影响及后果不承担责任。但上述内容不能解释为贝锐具有审核用户域名注册申请的义务;同时,贝锐也不对用户所填写信息的真实、准确及完整性承担任何责任。 用户同意此域名在线注册服务条款之效力如同用户亲自签字、盖章的书面条款一样,对用户具有法律约束力。 用户进一步同意,用户正式进入在线域名注册程序即意味着用户同意了本在线服务条款的所有条款和CNNIC的域名争议解决方案。CNNIC的投诉邮箱是:supervise@cnnic.cn 第一条 项目和术语解释 1-1 用户委托贝锐在国际互联网(Internet)上注册用户申请注册的域名。 1-2 域名注册的术语含义如下: 1-2-1 中英文CN域名注册: 是指用户委托贝锐向CNNIC进行的国内中英文域名注册,本条款中国内中文英文域名是指 “.com.cn”、“.net.cn”、“.gov.cn”、“.org.cn”、“.cn”结尾的英文域名 以及指 “.中国”、 “.公司”、 “.网络”结尾的中文域名。 1-2-2 域名注册成功:指用户申请注册的域名被域名注册管理机构确认没有在先的相同域名注册或者没有违反域名注册的有关强制性规定并且在规定的期限内收到用户支付的域名注册管理费用以及符合规定的域名申请资料,并由域名管理机构赋予用户一定期限的对该域名的所有权。域名注册是否成功的确认权在域名管理机构。 1-2-3 CNNIC:中国互联网络信息中心,中英文CN域名的注册管理机构。 第二条 用户的陈述与保证 2-1 用户承诺并保证已阅读并完全理解了本条款的所有内容,同意按照规定支付款项,遵守用户应承担的所有义务。用户进一步承诺遵守国家域名主管机关和域名注册管理机构CNNIC的相关管理政策和规定,包括但不限于《中国互联网络域名管理办法》、《中国互联网络信息中心域名注册实施细则》、《中国互联网络信息中心域名争议解决办法》、《中国互联网络信息中心域名争议解决办法程序规则》、《中国互联网络信息中心域名注册服务机构变更办法》等。CNNIC的域名注册管理办法和域名争议解决办法发生变化或被修改以后,用户拥有的域名继续适用新的CNNIC域名注册管理办法和域名争议解决办法。用户在每次续期时缴纳费用的行为即表示同意接受续期时的注册申请协议的全部条款。 2-2 用户承诺接受本在线条款不会违反用户以前签署的其他文件,也不会置贝锐于违约或者违法的境地。 2-3 如果用户提交的域名注册申请涉及任何争议、纠纷、诉讼、仲裁等,用户将立即通知贝锐,并且应使贝锐及其雇员、董事不受任何损害。 第三条 费用支付 3-1 用户同意按照贝锐所公布的收费标准和缴费时间向贝锐缴纳相关费用,并同意每一次续期都应适用续期时的收费标准。在接受本条款之同时,用户应将注册域名的全部款项支付给贝锐,用户理解域名注册成功后,所缴纳的费用不可退回。 3-2 在用户接受本条款后至贝锐收到用户款项并向域名管理机构支付款项之前发生用户申请注册的域名被“抢注”的,贝锐不承担任何责任。 3-3 用户应真实、准确、完整地填写用户信息,在付款时应使用与注册时完全一致的用户名称并注明该款项所对应的域名和用户名等以便贝锐核对。若因用户或者其代理人未按照前述要求办理而导致域名未注册成功或者导致域名被域名管理机构取消的,或者发生域名被他人抢注的,均由用户自行承担责任。 3-4 域名注册成功后,贝锐将为用户提供域名续费服务以延长用户持有域名的有效期。如用户希望在域名有效期届满后继续拥有该等域名的所有权及贝锐相关服务的,应在服务期限届满前完成续费,并保证贝锐在域名到期前已经收到用户的续费款项。贝锐会在域名到期前一定期限内向用户发送续费通知,但用户没有收到贝锐的续费通知不能成为用户不按时缴费或者续费的理由和解释。 3-5 用户按照规定续费且域名注册管理机构接受用户续费的,贝锐的服务期限延长至域名注册管理机构认可的域名有效期满之日。若用户所注册域名、注册信息存在不真实、不准确或不完整的情况,贝锐有权不提供域名续费服务。 3-6 用户理解并同意,域名续费成功与否,取决于相关域名法规政策、域名注册管理机构的决定等,贝锐不保证一定能续费成功。 3-7 过期域名续费,用户理解并同意,如用户的域名在到期前未完成续费,贝锐仍可以按照用户的要求为到期域名进行续费并向注册管理机构提交,如果贝锐决定为到期域名进行续费的,则用户将拥有贝锐提供的续费宽限期。用户在续费宽限期内可以通过向贝锐支付域名正常续费费用的方式,为该域名进行续费。鉴于域名已过期,在续费宽限期内,贝锐除了保留您续费的权利外,用户不再享有服务期内的各项权利及相关服务。 3-8在遵守域名管理机构政策的前提下,贝锐有权自行决定、调整续费宽限期的具体时长。 3-9用户理解并同意,域名宽限期内续费成功与否,取决于相关域名法规政策、域名注册管理机构的决定等,贝锐不保证一定能续费成功。 3-10如用户在续费宽限期内成功续费的,该域名有效期将在原域名到期日的基础上按照成功续费的期限对应增加;如用户未能续费成功,贝锐除退回所收取的该域名的相应续费费用外,无须承担其他任何责任。 3-11 过期域名的赎回,贝锐为用户提供过期域名赎回服务,即:如用户在续费宽限期内仍未能完成过期域名的成功续费,该域名在续费宽限期满后将进入赎回期。用户在赎回期内,仍可按贝锐公布的收费标准和缴费时间缴纳赎回费用,申请赎回域名。鉴于域名已过期,在赎回期内,用户不再享有服务期内的各项权利及相关服务,贝锐仅保留用户可以申请赎回过期域名的权利。 3-12在遵守域名管理机构政策的前提下,贝锐有权自行决定、调整赎回期的具体时长。 3-13用户理解并同意,过期域名赎回能否成功,取决于相关域名法规政策、注册管理机构的决定等,贝锐不保证一定能赎回成功。 3-14 如用户通过支付赎回费用成功赎回该过期域名且成功续费的,该域名有效期将在原域名到期日的基础上按照成功续费的期限对应增加;如用户在赎回期支付了赎回费用,但最终未能成功赎回该域名的,贝锐除退回所收取的该域名的相应赎回费用外,无须承担其他任何责任。 第四条 服务期限 4-1 贝锐的服务期限为所注册成功的中英文CN域名有效期内。 4-2下列情形贝锐的服务期提前终止: 4-2-1 双方协商一致变更的。 4-2-2 双方签署的其他合同另有约定的。 4-2-3 用户违反本条款、法律规定或者域名管理机构的规定/政策等,贝锐根据规定或有权机关作出的决定、通知等停止服务的。 4-2-4 域名管理机构终止服务或者通知贝锐终止服务的。 4-2-5 贝锐按照法院、仲裁机构裁决终止服务的。 4-2-6 用户采取欺骗、隐瞒等方式获得域名注册的或者采用非法手段获得域名注册的,贝锐可以立即终止服务。 4-2-7 用户未按时缴费的。 4-2-8 一方当事人主体资格不存在或者消亡的。 4-3 用户按照5-8的规定续费且域名管理机构接受用户续费的,贝锐的服务期限延长至域名管理机构认可的域名有效期满之日。 第五条 用户的权利和义务 5-1 如果贝锐受理并同意用户此次注册申请,则用户所申请的域名由CNNIC负责在域名数据库中给予注册并分配给用户,与该域名注册有关的一切法律责任由用户自行承担。 5-2 用户可以在域名注册成功之后的任何时候,将域名保留在贝锐的域名服务器或者转移到其他用户指定的域名服务器上(按照贝锐及域名管理机构对于域名转移注册商的规定执行)。 5-3 用户一旦申请域名注册即意味着用户承诺遵守域名注册管理机构现行的及今后修正的对域名注册和争议解决的政策、办法、规定及国家法律法规的有关规定。 5-4 用户保证申请注册的域名,没有侵犯贝锐或者任何第三方的合法权利包括但不限于他人的名称权、商标权和域名权利。如果该申请注册的域名侵犯了贝锐或者任何第三方的权利,由用户承担一切责任。用户承诺承担此次域名注册全过程产生的权利和义务及违反本条款规定产生的后果。 5-5 用户认识到域名注册申请的成功与否是由申请本身及申请时间等因素决定的,贝锐仅以代理身份代为办理有关手续,对域名能否成功注册不提供任何担保。在未与贝锐核实之前,用户不得对外声称自己是该申请域名的所有者,也不得断定域名注册成功或者注册不成功。用户在递交域名注册申请后应主动到CNNIC的网站上查询该域名的法律状态。 5-6 用户应向贝锐出具授权委托书,向域名管理机构/贝锐提供有关信息并为贝锐的工作提供必要的协助。 5-7 用户应按时足额向贝锐缴纳所需的全部费用。另外,如果用户申请的域名注册需要提供CNNIC规定的合格的域名注册申请资料。如果在规定的时间内没有提供规定的合格的域名申请注册资料,将被视为自动放弃所注册域名,用户应承担全部后果(包括但不限于被域名注册管理机构取消该域名的注册)。 5-8 用户希望在服务期限届满后继续拥有域名所有权及贝锐的相关服务,用户应在服务期限届满之前支付相应的金额进行域名或服务续费;用户未按照上述进行的,贝锐将视为用户不委托贝锐续费并在服务期限届满之日停止服务。 5-9 用户同意贝锐没有义务审查用户拟申请注册的域名是否侵犯他人的在先权利;贝锐也没有义务审查他人拟申请注册的域名是否侵犯用户的在先权利。发生上述情形,均与贝锐无关。若有任何第三方对用户注册的域名主张权利,由用户与相关当事人自行协商解决或者通过法律或其他途径解决。用户保证使贝锐不涉入任何上述争议并且不会因此而受到任何损害,否则用户应弥补贝锐遭受的所有损失。 5-10 用户在利用所注册的域名进行信息传播和自我服务时,应严格遵守《计算机信息网络国际联网安全保护管理办法》《中华人民共和国计算机信息网络国际联网管理暂行规定》《中华人民共和国计算机信息系统安全保护条例》《中华人民共和国电信条例》《全国人大常委会关于维护互联网安全的决定》、《互联网信息服务管理办法》、《互联网电子公告服务管理规定》、《互联网站从事登载新闻业务管理暂行规定》、《互联网等信息网络传播视听节目管理办法》、《互联网文化管理暂行规定》和国家其他有关法律、法规、行政规章,不得制作、复制、发布、传播任何法律法规禁止的有害信息。用户对其经营行为和发布的信息违反上述规定而引起的任何的政治责任法律责任和给贝锐造成的经济损失承担全部责任。 5-11 用户充分认识到贝锐根据用户手册所赠送的服务为贝锐的一次性额外优惠,并不得对赠送的服务提出任何异议。用户使用所赠送的服务必须遵守国家法律、行政法规、规章、社会公共道德及计算机和互联网的行业规范,贝锐有权根据自己谨慎的判断决定用户对赠送服务的使用行为是否对上述构成违反并决定是否继续向用户提供该赠送服务。所有赠送服务的内容均以本协议有效期为期限,但用户手册中有明确期限规定的除外。 5-12 用户承诺承担此次域名注册全过程产生的一切权利和义务。用户保证申请注册的域名没有侵犯贝锐或者任何第三方的合法权利包括但不限于他人的名称权、商标权和域名权利。如果因该注册域名侵犯了贝锐或者任何第三方的权利,用户将承担一切责任。 5-13 用户保证所申请的域名的注册不是为了任何非法目的,也不具有恶意,并且该域名的使用将不违反任何有关法律、法规、行政规章、国家政策以及计算机和互联网行业的行业规范和惯例。 5-14 用户同意如果其所持有的域名因受到第三方的投诉而产生域名争议时,用户应接受争议发生时CNNIC域名争议解决办法条款的约束。用户同意,在域名争议期间不擅自修改和变更其域名注册信息。在域名争议期间发生的域名注册信息变更或者域名转让无效。 5-15 用户未经信息产业部同意不得在其注册的域名下对公众提供下一级域名的注册服务。 第六条 贝锐的权利和义务 6-1 贝锐为用户办理域名注册的申请注册手续,提交规定的文件并代用户缴纳有关费用。贝锐不以任何明示或者暗示的方式担保用户申请注册的域名能够成功注册。 6-2 贝锐提交用户委托的域名注册申请以当时在域名管理机构的域名数据库中的注册情况和查询结果为基础,但查询时没有冲突并不表明该域名一定能够注册成功。 6-3 贝锐可以把用户信息录入可被公众查询的数据库和出版物中。 6-4 用户超过5-8规定的期限向贝锐提交书面续费通知或贝锐在上述期限之后收到用户提交的款项的,贝锐仍可按照用户的要求向注册管理机构提交,双方认可此种情况属于贝锐为用户注册新域名,双方同意按照本条款对于域名注册的相关规定执行,贝锐按照第七条承担责任。 6-5 贝锐有权按照CNNIC的相关规定,不批准用户提交的注册申请。贝锐不对由于拒绝接受上述注册申请所造成的影响及后果负责。 6-6 注册域名出现下列情形时,贝锐有权予以注销: 6-6-1 用户或其代理人申请注销域名的; 6-6-2 用户提交的注册信息不真实、不准确、不完整或变更后未及时更新的; 6-6-3 用户未按规定缴纳相应费用的; 6-6-4 根据域名主管机关、法院或域名争议解决机构的决定、判决或裁决,应当注销的; 6-6-5 违反本协议及其他相关法律、法规规定的。 第七条 服务的解除、终止及违约责任 7-1 在有效服务期限内,如果用户将域名转移注册商到除贝锐以外的其他域名注册服务机构,贝锐的服务义务即告终止。 7-2 在有效服务期结束后,双方愿意继续合作的,双方同意按照届时有效的新的价格和条款另行商议合作事宜。 7-3 如果用户所需域名未能注册成功,贝锐将收取的该域名的相应费用退还用户,贝锐无须承担其他任何责任。 7-4 用户充分理解因贝锐的网络故障、服务器故障而造成的延误或者给用户带来的损失均不应由贝锐承担责任。 7-5 用户如果不遵守本在线注册条款或者CNNIC的任何规定,都可能被认为是一次严重违约。此时贝锐可以向用户发出一个书面通知并说明违约。如果在收到通知15日内,用户没有提供或不能提供关于没有违约的合理证据,贝锐将删除用户注册的域名。贝锐以前没有对违约行为采取措施不能成为用户违约或者抗辩的理由和解释。 第八条 争议解决 8-1 因本服务条款有关的一切争议,双方当事人应通过友好协商方式解决。 8-2 本服务条款适用有关域名管理机构(包括但不限于ICANN、Verisign和CNNIC等)的域名管理办法、政策和争议解决方案。具体内容详见上述机构的网站www.icann.org; www.verisign.org; www.cnnic.net.cn等。 8-3 若发生任何第三人注册的域名与用户的在先权利发生冲突的,或者发生“抢注用户域名”的,由用户与该第三方自行协商解决、通过法律或者其他途径解决。贝锐对此不应承担任何责任。 8-4 若发生用户拟注册的域名与他人的在先权利发生冲突的,或者发生“抢注他人域名”的,由用户与该第三方自行协商解决、通过法律或者其他途径解决。贝锐对此不应承担任何责任。8-5 用户理解并同意若因 贝锐 重大过错导致用户申请、注册的域名丢失、被注销的,贝锐的责任上限为该用户当年向贝锐交纳的域名年度运行管理费。而且, 贝锐 不应对用户的其他直接或间接损失、商机的消失、利润的损失、侵权、其他无形损失及基于用户与他人签署的合同而遭受的损失承担责任。 8-6 用户同意,域名注册成功后,域名注册管理机构-中国互联网络信息中心CNNIC因过错对用户造成损害的,中国互联网络信息中心的责任上限为该用户当年向 贝锐交纳的域名年度运行管理费。 第九条 免责条款 以下(并且不限于以下)原因导致的结果,贝锐不承担任何的损失和责任: 9-1 用户在线填写域名注册申请表时,域名被其他人抢注; 9-2 由于电信线路和设备问题造成用户的域名被别人抢注; 9-3 用户须填写详细的信息,由于信息不详而造成用户域名被他人抢注; 9-4 用户须填写正确的信息,由于信息不正确可能引起所有权纠纷和使用问题; 9-5 用户未严格按照提示填写申请表,或者由于填写不规范造成注册延误或被他人抢注; 9-6 用户未严格按照规定的期限递交域名注册材料的; 9-7 由于域名注册管理机构的系统故障或操作失误导致注册失败或延误; 9-8 由于贝锐无法预测或无法控制的因素导致用户域名注册不成功; 9-9 由于技术问题造成的损失或责任; 9-10 由于未被授权者使用或误用用户的账号引起的损失或责任; 9-11 由于用户原因导致的损失或责任,包括(不仅包括)未能按时缴纳域名年度运行管理费; 9-12 由于适用争议解决办法而引起的损失或责任; 9-13 用户同意鉴于互联网的特殊性,停电、通讯线路中断、他人蓄意破坏、黑客攻击、计算机病毒入侵或发作、电信部门技术、政策、政府管制等及其他不可预见,不可避免,不可克服和不可控制的不可抗力和事件影响网络正常运营等非贝锐原因给用户或者第三方造成的损失不应由贝锐承担; 第十条 其他约定 10-1 有关条款若被权威机关认定为无效,不影响其他条款的效力,也不影响本条款的解释、违约责任及争议解决的有关约定的效力。 10-2 本服务条款的效力、解释、履行和争议的解决均适用中华人民共和国法律法规、有关域名管理机构的域名争议解决办法/政策和计算机行业的规范。 10-3 如果本服务条款任何规定根据适用的现行法律被确定为无效或无法实施,其他所有条款将继续有效。 10-4 一方变更通知、通讯地址或其他联系方式,应自变更之日起30日内将变更后的地址、联系方式通知另一方,否则变更方应对此造成的一切后果承担责任。用户同意,贝锐的有关通知只需在贝锐有关网页上发布即视为送达用户。 10-5 对条款的理解与解释应依据条款目的和文本原义及业界通行的理解和惯例进行,标题不应影响条款的解释。 10-6 有关条款或者约定若与双方以前签署的有关条款或者贝锐的有关陈述不一致或者相抵触的,以本服务条款为准。 10-7 在有效服务期内,因贝锐上市、被收购、与第三方合并、名称变更等事由,用户同意贝锐可以将其权利和/或义务转让给相应的贝锐权利/义务的承受者。 10-8 贝锐有权在必要时修改服务条款,贝锐 服务条款一旦发生变动,将会在其网站的重要页面上提示有关内容。用户如果不同意所改动的内容,可以主动取消获得的服务;如果用户继续接受服务,则视为接受本服务条款的变动。 10-9 如注册服务机构被终止认证资格时,用户同意注册服务机构有权在10日内对其所负责注册的域名在中国互联网络信息中心(CNNIC)认证的其他注册服务机构之间进行选择和分配。如果逾期未做或未完成选择与分配,服从中国互联网络信息中心(CNNIC)对域名注册服务机构的选择和分配。 10-10 在域名处于司法程序、仲裁程序或域名争议解决程序期间,申请人不得申请转让或注销被争议的域名,但域名受让方以书面形式同意接受司法裁判、仲裁裁决或争议解决机构裁决约束的除外。 用户在此再次保证已经完全阅读并理解了上述在线域名注册服务条款并自愿正式进入在线域名注册程序,接受上述所有条款的约束。
常用名词解析
1、什么是域名? Internet域名是Internet网络上的一个服务器或一个网络系统的名字,在全世界,没有重复的域名。域名的形式是以若干个英文字母或数字组成,由“.”分隔成几部分,如Oray.net就是一个域名。 2、什么是顶级域名? 互联网上的域名可谓千姿百态,但从域名的结构来划分,总体上可把域名分成两类,一类称为“国际顶级域名”(简称“国际域名”),一类称为“国内域名”。 一般国际域名的最后一个后缀是一些诸如 .com,.net,.gov,.edu 的“国际通用域”,这些不同的后缀分别代表了不同的机构性质。比如.com表示的是商业机构,.net表示的是网络服务机构,.gov表示的是政府机构,.edu表示的是教育机构。 3、什么是三级域名? 三级域名可分为两类:类别域名和行政区划域名,如:cnnic.ac.cn 。 类别域名是依照申请机构的性质划分出来的域名,具体包括: 域名 性质 ac 科研机构 com 工、商、金融等企业 edu 教育机构 gov 政府部门 net 互联网络、接入网络的信息中心(NIC)和运行中心(NOC) org 各种非盈利性的组织 您可以按照您的机构性质选择适合您单位使用的三级域名。 行政区划域名是按照中国的各个行政区划划分而成的,其划分标准依照原国家技术监督局发布的国家标准而定,包括"行政区域名"34个,适用于我国的各省、自治区、直辖市。例如北京的机构可以选择如cnnic.bj.cn的域名。 4、什么是域名解析? 机器间互相只识别IP地址,要让域名与IP地址之间一一对应,必须使用DNS解析(域名解析服务)。DNS解析需要由专门的域名解析服务器来完成,整个过程是自动进行的。 5、什么是DNS? 域名管理系统DNS(Domain Name System)是域名解析服务器的意思。它在互联网的作用是:把域名转换成为网络可以识别的Ip地址。比如:我们上网时输入的www.oray.net 会被解析到IP为61.152.96.116的服务器。 6、什么是A记录? A(Address)记录是用来指定主机名(或域名)对应的IP地址记录。用户可以将该域名下的网站服务器指向到自己的web server上。同时也可以设置您域名的二级域名。 7、什么是 MX记录? 即邮件交换记录,是域名在DNS服务器上的一个记录,告诉那台计算机负责为系统处理邮件。MX记录存在于域名的DNS文件中,用于将某个域名的电子邮件指向到对应的邮件服务器处理。 8、什么是CName记录? CName(Canonical Name)记录,通常称别名指向。在这里,您可以定义一个主机别名,比如设置www.A.com, 用来指向一个主机www.B.com, 那么以后就可以用 www.A.com 来代替访问 www.B.com 了。但成功设置CNAME记录后您可能需要在主机www.B.com 设置相应服务策略规则进行对应该域名,才能真正实现CName功能。 9、什么是Url? URL(Uniform Resource Locator:统一资源定位器)是WWW页的地址,它从左到右由下述部分组成: ①Internet资源类型(scheme):指出WWW客户程序用来操作的工具。如“http://” 表示WWW服务器,“ftp://” 表示 FTP 服务器,“gopher://” 表示Gopher服务器,而“new:”表示Newgroup新闻组 ②服务器地址(host):指出 WWW页所在的服务器域名 ③端口(port):有时(并非总是这样),对某些资源的访问来说,需给出相应的服务器提供端口号 ④路径(path):指明服务器上某资源的位置(格式与DOS系统中的格式一样,通常有目录/子目录/文件名这样结构组成)。与端口一样,路径并非总是需要的 URL地址格式排列为:scheme://host:port/path 例如http://www.oray.net /Default.asp就是一个典型的URL地址。 10、什么叫做Url指向服务? URL指向是当您已经有了现成的网页,并希望将新注册的域名指到已经有的网页去,以省去了重新设立网页的烦恼。举个例来说:如果您现在163的主页空间里已拥有了 http://yourdomain.go.163.com 网页且正在运作,您也同时要将相同的内容放在 www.yourdomain.com 里。那么,您只需将域名转接到yourdomain.go.163.com的网址就行了。 需要说明的是,在这一点上面,我们是完全免费的,而且是用户自己控制。 11、什么是泛域名? 泛域名解析是指将.域名解析到同一IP。 在域名前添加任何子域名,均可访问到所指向的WEB地址。也就是客户的域名a.com之下所设的.a.com全部解析到同一个IP地址上去。 比如客户设b.a.com就会自已自动解析到与a.com同一个IP地址上去。 12、什么是动态IP地址? 通过Modem、 ISDN、xDSL等方式上网的计算机一般不具备固定IP地址,而是由ISP动态分配暂时的一个IP地址到其网络设备中。普通人一般不需要去了解动态IP 地址,这些都是计算机系统自动完成的。 13、什么是静态IP地址? 静态IP地址是长期固定分配给一台计算机使用的公网IP地址,一般专业的服务器才需要拥有静态IP地址。现在静态IP的资源非常的有限,如果要使用静态IP往往需要付出高昂的使用费用。 14、域名的结构是什么? ·顶级域名 域名由两个或两个以上的词构成,中间由点号分隔开。最右边的那个词称为顶级域名。下面是几个常见的顶级域名及其用法: .com-- 用于商业机构。它是常见的顶级域名。任何人都可以注册.com形式的域名。 .net-- 最初是用于网络组织,例如因特网服务商和维修商。现在任何人都可以注册以.net结尾的域名。 .org-- 是为各种组织包括非盈利组织而定的。现在,任何人都可以注册以.org结尾的域名。 国家代码由两个字母组成的顶级域名如.cn,.uk,.de和.jp称为国家代码顶级域名(ccTLDs),其中.cn是中国专用的顶级域名,其注册归CNNIC管理,以.cn结尾的二级域名我们简称为国内域名。注册国家代码顶级域名下的二级域名的规则和政策与不同的国家的政策有关。您在注册时应咨询域名注册机构,问清相关的注册条件及与注册相关的条款。某些域名注册商除了提供以.com,.net和.org结尾的域名的注册服务之外,还提供国家代码顶级域名的注册。ICANN并没有特别授权注册商提供国家代码顶级域名的注册服务。 ·二级域名 顶级域名的下一级,就是我们所说的二级域名。domainpeople.com,域名注册人在以.com结尾的顶级域名中,提供一个二级域名。域名形式也可能是something.domainpeople.com。在这种情况下,something称为主名或分域名。 国际域名管理机构ICANN是一个近年成立的的非盈利机构,其主要职能包括管理因特网域名及地址系统。 有关ICANN的信息可在网址http://www.icann.org中查询。 15、为什么要注册域名? Internet域名如同商标,是您在因特网上的标志之一。Internet上的域名是非常有限的,因为每个域名都只有一个。如果您公司的名字是Intellectual Business Management Ltd.,您想把公司的域名注册成IBM.COM,国际商用机器公司(IBM)同您相比并不具有什么优先权,然而这个域名早已被它抢到手了!在美国,连街头上的小百货店和小加油站都在注册他们的域名,以便在网上宣传自己的产品和服务。作为有头脑、有远见的商人,越早行动,越有可能获得您所需要的域名。 16、为什么要为域名续费? 互联网上的域名都有使用年限,如果不为域名续费,那么这个域名将被禁用甚至被释放。 用户如需要为域名续费时,可从联机服务网站中的域名服务中心-服务续费功能页面中对所需域名进行续费。 17、何谓域名抢注? 域名是企业在因特网上的标识,是企业进入互联网,网络用户访问和联络企业的途径,它不仅可以有效保护企业的公众形象和无形资产;而且是企业迈入信息化社会,融入国际大市场,进行电子商务应用的标志,因此有着巨大的商业价值。如果您的企业还没有域名,那就意味着您在网上还没有一个正式的“门面”,其它用户或企业就无法在网络上找到您。光是企业,个人也可以注册国际顶级域名。域名抢注就是一个域名在被别人注册之前, 抢先将此域名以注册人的名义注册下来的行为。 18、如何选择域名注册商? 首先您要搞清楚他可提供给您的相关域名管理的权限,很多域名注册商都不提供给客户管理权限,有的即使提供了管理权限,但是所提供的功能也是不全的。比如,客户在自助控制平台中不能生成三级域名,不能修改A记录、MX记录、CNAME记录等常用功能。甚至有的域名商会针对用户域名的操作进行收费。 19、何谓以域名结尾的邮箱? 申请了域名后,可通过设置邮件MX记录指向到对应邮件服务器的主机,并且在该主机上建立一套邮件服务接口,即可使用所注册的顶级域名作为邮件域名通过邮件服务器接口对外收发邮件。 20、在什么情况下域名需要进行备案? 目前信息产业局要每一个向互联网提供电子信息服务的个人或企业对所提供服务的域名进行备案操作。我们希望各位用户能配合信息产业局与Oray.net的工作,域名已经备案以及提供的内容是合法的前提下,能完全地使用 Oray.net每一项功能。对于还没有备案以及向互联网提供非法信息的站点,在将来不排除采取停止服务的措施。
域名基本概念
域名是用来确定网址的独特的名称。当互联网用户寻找网站时,域名允许网域名称系统( DNS )下的计算机确认该网站。例如:oray.com。 1.域名级别 域名级别 内容 根域名 . 顶级域名 .com,.net,.cn等 二级域名 即顶级域名的子域名,example.com,example.net,example.cn等 三级域名 即主域名的子域名,abc.example.com,abc.example.net,abc.example.cn等 四级域名,以此类推,在上一级域名最左侧进行域名级别的拓展 2.域名格式 ①域名以点号分隔成多个字符串 ②单个字符串由各国文字的特定字符集、字母、数字、连字符(-)组成,字母不区分大小写,连字符(-)不得出现在字符串的头部或者尾部 ③单个字符串长度不超过63个字符 ④字符串间以点分割,且总长度(包括末尾的点)不超过254个字符 3.域名后缀类型 客户可通过贝锐享受多达20种域名注册服务。(具体后缀可点击查看) 当您通过选择域名进行注册时,需要选择不同的域名后缀,即顶级域名(Top-level Domains)。顶级是指域名的最后一部分,比如 .com、.cn、或 .net。 顶级域名分为三种类型: ①通用顶级域名(Generic Top-Level Domains,gTLDs)。该类型顶级域名通常可以表明网站的类型。例如, .com代表工商企业,.net代表网络提供商 ②国家代码顶级域名(Country Code Top-Level Domains,ccTLDs)。该类型顶级域名与国家、地区或者城市等地理区域有关。例如,.cn代表中国,.us代表美国 ③新顶级域名(New gTLD)。例如,.xyz代表通用、.top代表高端 、.red代表红色的、.men代表人 4.域名注册 4.1 域名注册要求 ①域名只能包含字符A-Z ,0-9 ②域名可含有连字号 - ,但不能以连字符作为开头或结尾 ③空格及特殊字符,如问号( ? ) ,感叹号( ! ) ,和下划线( _ )是不允许使用的 ④所有域名在任何时候都必须有至少2个名称服务器和IPs列表 ⑤域名不能用连字符作为第三和第四个字符(预留作多语种域名注册,例如: xn--example.com) ⑥在域名注册申请中所提供的信息是真实的、正确的、最新的、完整的 ⑦注册人必须随时保持域名的WHOIS信息为最新的 4.2 域名注册过程 域名注册过程涉及域名注册商和域名注册机构,其过程如图所示。 更多帮助:注册域名操作指导 4.2.1 域名注册商 域名注册商(Domain Name Registrar)旨在处理特定顶级域 (TLD) 的域名注册,是经互联网名称与数字地址分配机构( Internet Corporation for Assigned Names and Numbers,ICANN)认可,或一个国家代码顶级域名(ccTLD)域名注册局委派的商业实体或组织。 域名注册商(Domain Name Registrar)是一个由互联网名称与数字地址分配机构(Internet Corporation for Assigned Names and Numbers,ICANN)或者一个国家代码顶级域名(Country Code Top-Level Domains,ccTLDs)域名注册局委派的商业实体或组织。域名注册商管理指定域名注册数据库中的互联网域名,向用户提供域名注册服务。 4.2.2 域名注册机构 域名注册机构(Domain Name Registry)是有权销售特定顶级域下域名的公司。例如,VeriSign是一个有权销售 .com顶级域下域名的注册机构。域名注册机构可以定义注册相应域名的规则,比如限制某个国家代码顶级域名注册中注册人的地理所在地址。 域名注册机构还负责维护具有相同TLD的所有域名的权威数据库。注册机构的数据库中包含域名联系人和域名的DNS服务器等信息。 4.3 域名注册信息 域名注册时,需要提交域名的域名所有者类型、域名所有者、域名联系人以及各类联系方式等注册信息到注册机构的数据库,并同步更新到公共的Whois数据库中。 根据注册局规定,除域名注册之外,在如下多个场景中也需要使用域名注册信息: ①域名过户(域名所有者类型及域名所有者变更) ②域名转入 为了简化操作,建议您通过注册人模板定义域名注册信息。 域名注册完成后,可以通过WHOIS平台查询域名注册信息,但是域名所有者的私人信息将会被隐藏。 说明 在域名到期被删除后,域名注册信息也会被同步删除。 5.常见问题 5.1 贝锐提供哪几种国际化域名( IDN )? 贝锐目前提供二级IDN域名:.com、.net、.cn,我们提供中文注册。 5.2 每个域名费用是多少? 客户可参考贝锐域名服务里的价格列表(点击查看) 5.3 我想使用贝锐默认的DNS ,什么是DNS?是否收费? 贝锐默认的DNS是ns1.oray.net和ns2.oray.net,使用是否收费分两种情况: ①顶级域名注册商是贝锐,可以免费使用贝锐提供的DNS服务 ②顶级域名注册商不是贝锐,需要转入解析至贝锐,才可以使用贝锐提供的DNS服务。转入解析费用40元/年,在贝锐购买转入解析服务后,需要用户在域名的原注册商处将域名的NS记录改为ns1.oray.net和ns2.oray.net,修改完等生效即可 5.4 贝锐在域名注册同时提供的增值服务是什么? 在贝锐注册域名 ,您不仅可以获得您想要的域名。如果域名指向我们默认的DNS ,可以升级DNS增值服务包括:CNAME记录设置,URL跳转设置,泛域名支持,可添加无限子域名,TXT记录,SRV记录。 进一步的细节,请参阅:http://service.oray.com/question/199.html 5.5 我的客户能够用中文域名访问我的网站吗? 目前正在浏览器中使用i-Nav plug-in的客户和正在使用支持IDN功能的浏览器的客户,可以用中文域名访问您的网站。然而,由于供应商将不再提供i-Nav plug-in的服务,因此,该功能将于2011年6月7日后不再被支持。我们建议网站访问者在资源情况下安装一个支持IDN功能的浏览器,并用其自己的语言,使用IDN浏览网站。目前支持IDN的少数浏览器如下: Microsoft Internet Explorer 网址: http://www.microsoft.com/windows/downloads/ie/getitnow.mspx 平台: Microsoft Windows XP , Windows Server 2003 版本: 7.0和更高 Netscape Navigator (只有英文版) 网址: http://browser.netscape.com/ns8/ 平台: Windows 版本: 7.0和更高 OPERA网页浏览器 网址: http://www.opera.com 平台: Windows , Mac OS X中, Linux 版本: 7.2或更高
.NET域名帮助
1.什么是.NET? 答:.NET是互联网提供商的简写通用顶级域(简称 gTLD)。 2.谁可以注册.NET域名?注册.NET域名有什么特别的要求/限制吗? 答:对于注册.NET域名的资格并没有任何限制。任何一个国家的个人或企业均可注册.NET域名。 3.NET域名长度为多少? 答:不能少于3个字符,多于63个字符。 4.域名注册期限多长? 答:.NET的注册期限为1-10年。 5.如何进行.NET域名注册? 答:客户可以通过贝锐网站域名服务子站注册域名。 6.注册后可删除域名吗? 答:不可以。 7.续期期限是多长? 答:续期期限从1-10年不等。 8.NET域名续期宽限期多长?要如何进行续期? 答:.NET域名续期宽限期30天,域名注册客户可以在贝锐网站域名管理平台进行续费。 9.NET域名有赎回宽限期(RGP)吗? 答:.NET域名赎回宽限期是30天。 10.过期且不再续期的域名,多久可以再次公开注册? 答:当.NET域名过期后,它将会经过以下的生命周期: 30天续期宽限期→30天赎回宽限期→5天等待删除。 如果客户不续期或赎回域名,域名将在过期后的大约75天将会对公众开放注册。 注意 域名重新注册将遵循先到先得的原则。 11.可以转移.NET域名吗?怎样转入? 答:是的,客户可以进行.NET域名转移注册商。.NET域名转入贝锐将在完成转入注册商后延长一年有效期限。 12.如何管理.NET域名? 答:域名注册客户可以在贝锐网站域名管理平台进行管理域名。 13.贝锐是否为.NET提供国际化域名(简称IDN)? 答:是的,可以提供国际化.NET域名注册。
.CN域名帮助
1、什么是.CN? 答:.CN是中国的国家代码顶级域(ccTLD)。 2、谁可以注册.CN域名?注册.CN域名有什么特别的要求/限制吗? 答:仅向持有中国有效身份证明的组织或个人开放注册,注册时需提供中国有效身份证明材料信息。 3、.CN域名长度为多少? 答:不能低于3个字符,多于63个字符。 4、域名注册期限多长? 答:.CN的注册期限为1-10年。 5、如何进行.CN域名注册? 答:客户可以通过贝锐网站域名服务子站注册域名。 6、注册后可删除域名吗? 答:不可以。 7、续期期限是多长? 答:续期期限从1-10年。 8、.CN域名续期宽限期多长?要如何进行续期? 答:.CN域名续期宽限期30天,域名注册客户可以在贝锐网站域名管理平台进行续费。 9、.CN域名有赎回宽限期(RGP)吗? 答:.CN域名赎回宽限期是15天。 10、过期且不再续期的域名,多久可以再次公开注册? 答:当.CN域名过期后,它将会经过以下的生命周期: 30天的宽限期->15天内赎回的宽限期->无待删除期限 如果客户不续期或赎回域名,域名将在过期后的大约55天后将会对公众开放注册。 注意 域名重新注册将遵循先到先得的原则。 11、可以转移.CN域名吗?怎样转入? 答:是的,客户可以进行.CN域名转移注册商。.CN域名转入贝锐将在完成转入注册商后延长一年有效期限。 12、如何管理.CN域名? 答:域名注册客户可以在贝锐网站域名管理平台进行管理域名。 13、贝锐是否为.CN提供国际化域名(简称IDN)? 答:暂不提供国际化.CN域名注册。
CN域名注册流程
CN域名已向个人开放注册 (除gov.cn外),个人注册CN域名注册联系人与注册所有人必须一致。 1. 如何注册CN域名 (1)进入贝锐域名官网,查询你要注册的域名是否可以注册。 (2)查询结果域名后面出现 <立即注册> 按钮,代表此域名未被注册。若显示域名已被注册,需要重新输入前缀搜索。 (3)点击 <立即注册> 进入注册页面,选择注册人模板后点击 <下一步> 。 更多帮助 注册域名操作指导(点击查看) (4)在【选择产品服务】页面,选择域名的选配和注册年限,选择完成后点击 <去下单> 。 (5)确认购买产品并点击 <立即购买> 。 注意 用户成功支付订单后本服务合同即刻生效,用户应按照贝锐平台系统提醒按时提交必要的资料。若因用户原因无法提供所需资料,贝锐不予退款处理。 (6)若账号余额足够,直接点击支付,若账号余额不足,可通过银行转账或在线支付补差价。 2. 注册CN域名注意事项 (1)CN域名包括 国内英文域名(.cn/.com.cn/.net.cn/.org.cn/.各行政区域名)和国内中文域名(.中国/ .公司/ .网络)。 (2)制作以下电子版CN域名注册申请材料 ① 企业证件(常规证件需含统一社会信用代码号码) ② 注册联系人身份证明(需包含身份证正反两面) 注意 电子版资料中的企业证明资料、个人身份证明资料为原件拍照或原件扫描件(彩色),证件上文字、印章需清晰可见,否则视为无效。 (3)CN域名注册,特殊组织提供证件要求说明: a.注册人组织为外国驻华使领馆,无需提交注册联系人身份证明和组织机构代码证。可以提交加盖该使领馆公章的公函(中文),公函中应写明 ①申请的域名 ②域名的注册联系人为该使领馆工作人员 b.注册人组织为国家部委、省级的人大常委会、党委、政协和人民政府,无法提交组织机构代码证时,可以提交加盖注册人组织(办公厅)公章的公函,公函中应写明 ①申请的域名 ②域名的注册联系人为该组织的工作人员 c.消防部门无组织机构代码证,可以建议注册单位出具盖公章的说明文件作为组织证明。 d.香港地区注册用户注册人ID实名制注册要求 香港企业用户,需要提交有效期内的商业登记证(BR证证件)和注册人身份证明材料。注册局可通过香港政府公司注册处的官方网站对企业真实性进行审核。 要求企业登记证的机构名称与注册人模板的域名所属单位名称一致。 注意 由于当前无法验证香港个人证件信息,暂时不受理香港个人用户注册 e.台湾、澳门及海外地区注册用户暂不受理
我的CN域名被停止解析了吗?
关于国内中英文CN域名实名认证工作相关情况的说明: 从2009年12月开始,CNNIC开展国内中英文CN域名注册信息专项治理。 随后的几个月中,贝锐在网站首页发布一系列新闻公告,提醒用户尽快办理国内中英文CN域名实名认证,同时将通知通过电子邮件发送到所有CN域名用户的账号绑定邮箱,并根据用户账号资料中的联系方式进行短信和电话通知。 自2010年1月起,贝锐全面开展域名注册信息的核对工作,并在网站设立专门通道,帮助用户办理CN域名实名认证。 2010年9月,CNNIC发布《关于落实工业和信息化部要求做好域名注册信息核对工作的通告》明确表示,尚未提交合格信息证明材料的国内域名,将被暂停解析。贝锐也再次提醒仍未办理办理CN域名实名认证的用户尽快提交资料。 贝锐已调动公司所有可用资源,主动联系、提醒所有在贝锐注册有CN域名的用户,尽快办理CN域名实名认证手续。很多用户已经办理并通过实名认证。但部分用户未在账号资料中留下正确的邮箱和电话号码,导致我们的邮件通知和短信提醒无法送达、电话无法打通。 贝锐再次提醒广大用户,请在账号资料中填写您正确的联系方式 ,并确保您的账号绑定的邮箱能够收到邮件。
首次备案
备案准备 为了节约备案时间和顺利通过备案,建议您提前了解 备案流程 因各地管局要求不同,需准备的材料也有所不同。建议您提前了解各省、自治区、直辖市管局的备案要求,以及相关备案限制。 ① 备案准备 ② 备案材料清单 备案流程 1. 基础信息校验 (1)登录 腾讯云网站备案控制台,进入 “我的备案” 管理页面。 (2)单击开始备案,查看 备案准备 信息,并单击已了解,下一步,进入 “基础信息校验” 页面。如下图所示: 字段名称 说明 主办单位信息 备案省份 备案省份选择与单位证件一致即可。 主办单位性质 请选择相应的主办者性质。 主办单位名称 请输入主办单位名称,需与单位证件上的名称及账号实名认证名称一致。 证件类型 请选择相应的主办单位证件类型。详情请查看备案材料。 证件号码 请输入证件号码,需与账号实名认证的单位证件号码保持一致。 网络域名 请输入需要进行备案的域名。域名要求请查看 备案域名。。 云资源 云资源填写备案授权码,由贝锐提供的备案授权码,(若不清楚备案授权码请咨询售后技术人员) (3)完成 “基础信息” 填写后,单击立即验证,进入 “主体信息” 步骤。 2. 主体信息 (1)在“主体信息” 模块,填写相关信息。如下图所示: 字段名称 说明 地域 地域信息选择与实际通信地址一致即可。 主办单位性质 请选择相应的主办者性质。 主办单位名称 请输入主办单位名称,需与单位证件上的名称及账号实名认证名称一致。 证件类型 请选择相应的主办单位证件类型。 营业执照 单击上传相应的主办单位证件,例如营业执照等。 证件号码 上传营业执照之后,系统会自动识别并填充证件号码,其他证件类型请自行填写。 证件住址 请输入单位证件上的地址。 法定代表人 请输入法定代表人姓名。 法定代表人证件号码 请输入法定代表人的证件号码。 通信地址 请输入通信地址,精确到门牌号或房间号。 备注 可添加相关主体备注信息。 「说明」 若您的账号实名认证信息不符合备案要求,您可以根据备案要求修改您的账号实名认证信息。详情请查看实名认证变更指引。 (2)在“主体负责人” 模块,填写相关信息。如下图所示: 字段名称 说明 证件类型 请选择主体负责人的证件类型。 负责人姓名 请输入单位主体负责人(例如法定代表人)的姓名。 证件号码 请输入主体负责人的证件号码。 联系方式 请输入主体负责人的手机号码。 验证码 请输入主体负责人的手机号码后,单击获取验证码并填写。 电子邮箱 请输入主体负责人的邮箱。 (3)单击下一步,进入填写 “网站信息” 步骤。 3. 网站信息 (1)在“网站信息” 模块,填写相关信息。如下图所示: 字段名称 说明 网站名称 请参考 网站名称命名要求 进行填写。 云服务资源 可选择账号内符合备案要求的云服务器、轻量应用服务器、使用 Serverless 服务、或输入其他关联账号申请的备案授权码。详情请查看 备案云服务。 域名 待接入网站的域名信息(需备案的域名)。 网站服务内容 根据网站类型,选择相应的网站服务内容。 备注 请输入网站备注信息。 前置审批类型 若网站内容中涉及出版、新闻等相关领域,需到相关主管部门办理前置审批文件;否则选择 “以上都不涉及”。详情请查看前置审批相关。 (2)在 “网站负责人” 模块,上传相关材料以及填写相关信息。如下图所示: 「说明」 单击点击上传,请使用手机打开微信并单击扫一扫,扫描页面提供的二维码,并按照要求上传相关信息。 字段名称 说明 证件照人面像 请使用原件拍照上传。 证件照国徽面 请使用原件拍照上传。 视频核身 相关要求请查看视频核身注意事项。 负责人姓名 请输入网站负责人的姓名。 备案省份 请选择相应的主办者性质。 证件类型 请选择相应的主办单位证件类型。详情请查看备案材料。 证件号码 请输入网站负责人的证件号码。 联系方式 请选择网站负责人的手机号码。 验证码 请输入网站负责人的手机号码后,单击获取验证码并填写。 电子邮箱 请输入网站负责人的邮箱。 (3)在“网站补充材料” 模块,上传相关材料。如下图所示: 字段名称 说明 域名证书 若域名注册商为贝锐,在域名管理平台—顶级域名—点击需获取域名证书的域名,在【其他服务】中点击“域名证书”。若域名注册商非贝锐,请咨询对应的域名注册商获取域名证书。 网站法定代表人授权书 上传网站负责人/法定代表人授权书。详情请参看授权书。 域名实名认证截图 需提供 “域名实名认证信息” 截图。请您在域名注册商处获取实名认证信息,截图中需包含域名、域名所有者、所有者证件类型、所有者证件号码、域名过期时间。若域名注册商为贝锐,在域名管理平台—顶级域名—点击需获取域名证书的域名,在【其他服务】中点击“域名证书”。若域名注册商非贝锐,请咨询对应的域名注册商获取域名实名认证信息截图。 (4)单击保存当前网站,即可完成网站信息的填写。如下图所示: 「说明」 如需备案多个网站,则可单击添加备案网站,添加新的网站信息。 (5)单击下一步,在弹出的 “补充材料” 窗口中,上传您本次备案所需的其他备案材料。例如承诺书等。如下图所示:(6)单击提交,进入 “提交备案” 步骤。 4. 提交备案 (1)在“备案订单” 预览信息页面中,请仔细核对您的备案信息,确认无误后,阅读和勾选同意,并阅读《信息安全管理协议》和《协助更改备案信息服务在线服务条款》,并单击提交审核。如下图所示: 「注意」 审核专员会在1 - 2个工作日内进行审核并电话联系您沟通确认订单问题,请确保您填写的联系方式真实且可接通。若审核专员首次拨打电话未联系到您,会在1个小时左右再次与您联系。若仍未能与您取得联系,您的备案申请将被驳回。 若初审通过,初审结果将会在1 - 2个工作日之内通过您提供的电子邮件和电话号码发送给您。 若初审未通过,请根据系统的提示修改备案信息并再次提交。 (2)腾讯云初审通过后,腾讯云将提交您的备案信息至当地管局进行最终审核。 5. 短信核验 根据工信部最新要求,自2020年8月17日起,各省市进行备案申请时需通过工信部备案管理系统进行短信核验,详情请查看 备案短信核验说明。 6. 通过审核,完成备案 管局审核后,腾讯云会以短信和邮件的形式通知您。 「说明」 您可以通过登录腾讯云网站备案小程序或腾讯云网站备案控制台,查看已备案的主体信息和备案网站信息。 您可以关注腾讯云助手小程序,接收备案提醒,实时查看备案进度。 用户在腾讯云完成域名备案后,需联系售后客服告知备案完成,到时我司会将对应顶级域名调至国内线路。 可通过以下方式联系我们: ①联系客服:https://service.oray.com/ ②电话联系:400-601-0000转3
花生壳域名诊断不同情况的处理办法
1、设置内网穿透后,诊断信息提示“内网连接失败” (1)确认服务器内网IP与端口填写正确; (2)确认服务器本机及局域网内其他设备能正常访问到对应的服务; (3)测试服务器本地端口是否通,在cmd命令行输入格式为:“telnet 服务器IP 端口”的命令,然后回车。若本地端口不通,请自行检查服务应用。【点击查看电脑如何开启telnet服务】 2、设置内网穿透后,诊断信息提示“域名解析失败”或“映射连接失败” (1)等待几分钟后,重新刷新诊断信息,或者重登、重启客户端; (2)检查域名是否设置过A记录或CNAME记录,若有请删除; (3)缓存原因,可更改电脑DNS后重登花生壳重试;【点击查看如何修改电脑DNS】 (4)若是顶级域名,需查看顶级域名是否已通过实名认证,域名状态serverhold情况下需联系售后客服协助; (5)是否在多台设备上分别登录了花生壳客户端(可联系技术客服协助排查),若有,请及时修改花生壳账号的密码,并保持花生壳客户端登录的唯一性(一台设备、一个客户端)。 3、设置内网穿透后,诊断信息提示“连接成功”,外网访问映射失败 (1)检查局域网内访问服务器是否正常; (2)检查账号是否有多处登录的情况; (3)检查映射类型是否设置错误,例如Web服务误设置为TCP类型; (4)若是解析延迟,请尝试重登花生壳客户端。或者设置本机网卡DNS为223.5.5.5或119.29.29.29。【点击查看如何修改电脑DNS】 4、设置内网穿透后,诊断信息提示“域名未被激活内网穿透功能” (1)查看域名是否未开启花生壳功能; (2)手动关闭再开启映射,或重新刷新诊断信息; (3)检查域名是否过期或者因长期未实名导致被锁定,若有请及时续费或办理实名。 5、设置内网穿透后,诊断信息提示“域名指向IP与服务器不一致” (1)点击设置栏清除DNS缓存,等待几分钟后,重新刷新诊断信息,或者重登、重启客户端; (2)缓存原因,可更改电脑DNS后重登花生壳重试。【点击查看如何修改电脑DNS】 6、管理平台,映射诊断信息提示“域名-连接失败” (1)查看域名是否未开启花生壳功能; (2)手动关闭再开启映射,或重新刷新诊断信息; (3)检查域名是否过期或者因长期未实名导致被锁定,若有请及时续费或办理实名 7、管理平台,映射诊断信息提示“请求超时,请刷新网络或重启客户端” (1)请求诊断接口超时,检查网络状态或重启客户端; (2)映射数量过多导致请求诊断接口超时,可参考客户端诊断信息。 8、使用花生壳公网版功能时,诊断信息提示“域名解析失败”,查询域名IP地址指向0.0.0.0 (1)查看域名是否未开启花生壳功能; (2)顶级域名未办理域名实名认证,前往官网管理中心进行办理; (3)缓存问题导致域名指向未更新,可尝试修改电脑或路由器的DNS为223.5.5.5或119.29.29.29。【点击查看如何修改电脑DNS】 9、在使用公网版功能时,诊断信息提示“域名解析失败”及“域名指向IP错误” (1)检查账号是否存在多处登录(多台设备、多个客户端)的情况,修改花生壳账号密码并保持登录的唯一性; (2)当前网络无真实有效的公网IP地址,可尝试联系当地宽带运营商获取; (3)缓存问题导致域名指向未更新,可尝试修改电脑或路由器的DNS为223.5.5.5或119.29.29.29。【点击查看如何修改电脑DNS】 10、设置内网穿透后,诊断信息提示“请检查内网主机IP和端口” (1)确认服务器内网IP与端口填写正确; (2)确认服务器本机及局域网内其他设备能正常访问到对应的服务; (3)测试服务器本地端口是否通,在cmd命令行输入格式为:“telnet 服务器IP 端口”的命令,然后回车。若本地端口不通,请自行检查服务应用。如【点击查看如何开启telnet服务】 11、设置内网穿透后,诊断信息提示“域名解析失败”或“映射连接失败” (1)等待几分钟后,重新刷新诊断信息,或者重登、重启客户端; (2)检查域名是否设置过A记录或CNAME记录,若有请删除;进入【域名管理平台】->【域名列表】->【顶级域名】,选中对应的域名后,点击“域名解析”进行查看 (3)缓存原因,可更改电脑DNS后重登花生壳重试;(修改教程戳我); (4)若是顶级域名,需查看顶级域名是否已通过实名认证,域名状态serverhold情况下需联系售后客服协助; (5)是否在多台设备上分别登录了花生壳客户端(可联系技术客服协助排查),若有,请及时修改花生壳账号的密码,并保持花生壳客户端登录的唯一性(一台设备、一个客户端)。 12、设置内网穿透后,诊断信息提示“连接成功”,外网使用域名访问失败 (1)检查局域网内访问服务器是否正常; (2)检查账号是否有多处登录的情况; (3)检查映射类型是否设置错误,例如Web服务误设置为TCP类型; (4)若是解析延迟,请尝试重登花生壳客户端。或者设置本机网卡DNS为223.5.5.5或119.29.29.29。 (修改教程戳我) 若按照以上方法排查问题未得到解决,请提供诊断信息截图及日志文件联系技术客服进行协助。
上海贝锐信息科技股份有限公司国际域名在线注册服务条款
感谢您选择上海贝锐信息科技股份有限公司的国际域名在线注册服务。请您认真细致地阅读以下的国际域名在线注册服务条款。用户只有同意了下述服务条款才能正式进入域名在线注册程序。如果您愿意接受我们的服务并同意此条款,请点击我同意继续进行注册;否则,请点击我不同意并退出。贝锐 建议用户在接受本服务条款之时打印一份存档。以下条款中上海贝锐信息科技股份有限公司简称为贝锐。 用户在此保证所填写的用户信息是真实、准确、完整的,并且没有任何引人误解或者虚假的陈述。用户同意此域名在线注册服务条款之效力如同用户亲自签字、盖章的书面条款一样,对用户具有法律约束力。用户进一步同意,用户正式进入在线域名注册程序即意味着用户同意了本在线服务条款的所有条款和争议解决方案。 第一条项目和术语解释 用户委托 贝锐 在国际互联网(Internet)上为其申请注册域名。 域名注册的术语含义如下: 国际域名注册:是指用户预先按照 贝锐 规定的价款和拟注册域名个数向 贝锐 足额付清款项后委托 贝锐向 ICANN 或 CNNIC 下任意一个或多个国际域名注册机构进行的国际域名注册,本服务条款中国际域名是指以.com、.net、.org、.cn 类、.info、.biz、.hk 类、.tw 类、.cc、.tv、.name或以.ws结尾的顶级域名。 域名注册成功:指用户申请注册的域名被域名注册管理机构确认没有在先的相同域名注册或者没有违反域名注册的有关强制性规定并且在规定的期限内收到用户支付的域名注册管理费用以及符合规定的域名申请资料,并由域名管理机构赋予用户一定期限的对该域名的所有权。域名注册是否成功的确认权在国际域名注册机构。 第二条用户的陈述与保证 不可提交注册涉及以下相关内容词汇的中英文 CN 域名: 带有负面含义的词汇; 国际奥林匹克运动会; 世界博览会; 涉及公众利益类的词汇; 涉及军事类的词汇; 用户承诺并保证已阅读并完全理解了本服务条款的所有内容,同意按照规定支付款项,遵守用户应承担的所有义务。用户进一步承诺遵守域名注册机构(包括但不限于 ICANN 下任意一个国际域名注册机构和CNNIC 等)的相关政策和规定以及域名争议解决的办法。 用户承诺接受本在线服务条款不会违反用户以前签署的其他文件,也不会置 贝锐 于违约或者违法的境地。 如果因用户提交的域名注册而引起的或与其有关的任何索赔、损害、债务、费用和开支(包括合理的法律费用和开支),用户应对域名注册管理机构(包括但不限于 ICANN 下任意一个国际域名注册机构,如VeriSign 等)、注册运营商(包括但不限于 贝锐)及其股东、董事、高级职员、员工和代理人进行赔偿,保护其免受任何损害。 第三条费用支付 用户同意按照 贝锐 所公布的收费标准和缴费时间向 贝锐 缴纳相关费用,并同意每一次续期都应适用续期时的收费标准。在接受本服务条款之同时,用户应将注册域名的全部款项支付给 贝锐,用户申请注册的域名注册成功后,所缴纳的费用不可退回。 在用户接受本服务条款后至贝锐收到用户款项并向域名管理机构支付款项之前发生用户申请注册的域名抢注的,贝锐 不承担任何责任。 用户应真实、准确、完整地填写用户信息,在付款时应按照 贝锐 所定义的付款流程对 贝锐 电子帐户进行充值。若因用户未按照前述要求办理而导致域名未注册成功或者导致域名被域名管理机构取消的,或者发生域名被他人抢注的,均由用户自行承担责任。 用户没有收到 贝锐 的缴费通知不能成为用户不按时缴费或者续费的理由和解释。 第四条服务期限 贝锐 的服务期限为所注册成功的国际域名有效期内。 下列情形贝锐的服务期提前终止: 双方协商一致变更的。 双方签署的其他合同另有约定的。 用户将域名转移注册商到其他注册商。 用户违反本服务条款、法律规定或者域名管理机构的规定/政策等,贝锐 根据规定或有权机关作出的决定、通知等停止服务的。 域名管理机构终止服务或者通知贝锐终止服务的。 用户按照本服务条款第五条第八款的规定续费且域名管理机构接受用户续费的,贝锐 的服务期限延长至域名管理机构认可的域名有效期满之日。 第五条用户的权利和义务 用户对以其名义注册成功的域名拥有 Internet 域名注册管理机构(包括但不限于 ICANN 下任意一个国际域名注册机构和/或 CNNIC,下同)赋予的相应的所有权。 用户可以在域名注册成功之后的任何时候,将域名保留在 贝锐 的域名服务器或者转移到其他用户指定的域名服务器上。 用户一旦申请域名注册即意味着用户承诺遵守域名注册管理机构现行的及今后修正的对域名注册和争议解决的政策、办法、规定及国家法律法规的有关规定。 用户保证申请注册的域名,没有侵犯 贝锐 或者任何第三方的合法权利包括但不限于他人的名称权、商标权和域名权利。如果该申请注册的域名侵犯了 贝锐 或者任何第三方的权利,由用户承担一切责任。用户承诺承担此次域名注册全过程产生的权利和义务及违反本服务条款规定产生的后果。 用户认识到域名注册申请的成功与否是由申请本身及申请时间等因素决定的,贝锐 仅以代理身份代为办理有关手续,对域名能否成功注册不提供任何担保。在未与 贝锐 核实之前,用户不得对外声称自己是该申请域名的所有者,也不得断定域名注册成功或者注册不成功。用户在递交域名注册申请后应主动到国际域名注册/管理机构网站上的 Whois 国际域名查询数据库查询该域名的法律状态。 用户应向 贝锐 出具授权委托书,向域名管理机构/贝锐 提供有关信息并为 贝锐 的工作提供必要的协助。 用户成功支付订单后本服务合同即刻生效,用户应按照贝锐平台系统提醒按时提交必要的资料。若因用户原因无法提供所需资料,贝锐不予退款处理。 用户应按时足额向 贝锐 缴纳所需的全部费用。如果在规定的时间内没有足额交费或者提供规定的合格的域名申请注册资料,将被视为自动放弃所注册域名,用户应承担全部后果(包括但不限于被域名注册管理机构取消该域名的注册)。 用户希望在服务期限届满后继续拥有域名所有权及 贝锐 的相关服务,用户应在服务期限届满之前支付相应的金额进行域名或服务续费;用户未按照上述进行的,贝锐 将视为用户不委托 贝锐 续费并在服务期限届满之日停止服务。 用户同意 贝锐 没有义务审查用户拟申请注册的域名是否侵犯他人的在先权利;贝锐 也没有义务审查他人拟申请注册的域名是否侵犯用户的在先权利。发生上述情形,均与 贝锐 无关。若有任何第三方对用户注册的域名主张权利,由用户与相关当事人自行协商解决或者通过法律或其他途径解决。用户保证使贝锐 不涉入任何上述争议并且不会因此而受到任何损害,否则用户应弥补 贝锐 遭受的所有损失。 用户在利用所注册的域名进行信息传播和自我服务时,应严格遵守《计算机信息网络国际联网安全保护管理办法》《中华人民共和国计算机信息网络国际联网管理暂行规定》《中华人民共和国计算机信息系统安全保护条例》《中华人民共和国电信条例》《全国人大常委会关于维护互联网安全的决定》、《互联网信息服务管理办法》、《互联网电子公告服务管理规定》、《互联网站从事登载新闻业务管理暂行规定》、《互联网等信息网络传播视听节目管理办法》、《互联网文化管理暂行规定》和国家其他有关法律、法规、行政规章,不得制作、复制、发布、传播任何法律法规禁止的有害信息。用户对其经营行为和发布的信息违反上述规定而引起的任何而引起的政治责任、法律责任和给 贝锐 造成的经济损失承担全部责任。 第六条 贝锐的权利和义务 贝锐 为用户办理域名注册的申请注册手续,提交规定的文件并代用户缴纳有关费用。贝锐 不以任何明示或者暗示的方式担保用户申请注册的域名能够成功注册。 贝锐 提交用户委托的域名注册申请以当时在域名管理机构的域名数据库中的注册情况和查询结果为基础,但查询时没有冲突并不表明该域名一定能够注册成功。 因域名注册管理机构的原因造成用户域名注册争议的以及出现下列情形的,贝锐 不承担任何责任: 用户在线填写域名注册申请表时,域名被其他人抢注; 由于电信线路和设备问题造成用户的域名被别人抢注; 用户须填写详细的信息,由于信息不详其注册申请可能被域名注册机构驳回而造成用户域名被他人抢注; 用户须填写的注册信息,由于信息不正确可能引起所有权纠纷和问题; 用户未严格按照提示填写申请表,或者由于填写不规范造成注册延误或被他人抢注; 用户未严格按照规定的期限递交域名注册材料的; 因域名注册管理机构的系统故障或操作失误导致注册失败或延误; 因域名注册涉及侵犯第三方权利(包括但不限于他人的名称权、商标权和域名权利)而被域名注册管理机构注销; 因 贝锐 无法预测或无法控制的因素导致用户域名注册不成功; 用户超过本服务条款第五条第八款规定的期限向 贝锐 提交书面续费通知或 贝锐 在上述期限之后收到用户提交的款项的,贝锐 仍可按照用户的要求向注册管理机构提交,双方认可此种情况属于 贝锐 为用户注册新域名,双方同意按照本服务条款对于域名注册的相关规定执行,贝锐 按照第七条承担责任。 第七条服务的解除、终止及违约责任 在有效服务期限内,如果用户将域名转移注册商到除 贝锐 以外的其他域名服务器,贝锐 的服务义务即告终止。 在有效服务期结束后,双方愿意继续合作的,双方同意按照届时有效的新的价格和条款另行商议合作事宜。 用户充分理解因 贝锐 的网络故障、服务器故障而造成的延误或者给用户带来的损失均不应由 贝锐 承担责任。 第八条争议解决 因本服务条款有关的一切争议,双方当事人应通过友好协商方式解决。如协商不成,双方约定于上海市杨浦区人民法院提起诉讼。 本服务条款适用有关域名管理机构(包括但不限于 ICANN、CNNIC、Verisign、NSI、Bulkregister 等)的域名管理办法、政策和争议解决方案。具体内容详见上述机构的网站 www.icann.org;www.nsi.com; www.internic.com; www.cnnic.net.cn;www.bulkregister.com;www.verisign.org;www.register.com; www.registrars.com 等。 若发生任何第三方注册的域名与用户的在先权利发生冲突的,或者发生抢注用户域名的,由用户与该第三方自行协商解决、通过法律或者其他途径解决。贝锐 对此不应承担任何责任。 若发生用户拟注册的域名与他人的在先权利发生冲突的,或者发生抢注他人域名的,由用户与该第三方自行协商解决、通过法律或者其他途径解决。贝锐 对此不应承担任何责任。 用户理解并同意若因 贝锐 重大过错导致用户申请、注册的域名丢失、被注销的,贝锐 的责任上限为该用户当年向 贝锐 交纳的域名年度运行管理费。并且 贝锐 不应对用户的其他直接或间接损失、商机的消失、利润的损失、侵权、其他无形损失及基于用户与他人签署的合同而遭受的损失承担责任。贝锐 也不承担由于以下(并且不限于以下)事项引起的任何和全部的损失和责任: (1)由于技术问题造成的损失或责任; (2)由于不可抗力造成的损失或责任; (3)由于未被授权者使用或误用用户的账号引起的损失或责任; (4)由于用户原因导致的损失或责任,包括未能按时缴纳域名年度运行管理费; (5)由于适用争议解决办法而引起的损失或责任。 第九条不可抗力 因不可抗力或者其他意外事件,使得本服务履行不可能、不必要或者无意义的,遭受不可抗力、意外事件的一方不承担责任。 不可抗力、意外事件是指不能预见、不能克服并不能避免且对一方或双方当事人造成重大影响的客观事件,包括但不限于自然灾害如洪水、地震、瘟疫流行和风暴等以及社会事件如战争、动乱、政府行为等。 用户同意鉴于互联网的特殊性,黑客攻击、互联网连通中断或者系统故障、电信部门原因造成的连通中断等非 贝锐 原因给用户或者第三方造成的损失不应由 贝锐 承担。 第十条其他约定 有关条款若被权威机关认定为无效,不影响其他条款的效力,也不影响本服务条款的解释、违约责任及争议解决的有关约定的效力。 本服务条款的效力、解释、履行和争议的解决均适用中华人民共和国法律法规、有关域名管理机构的域名争议解决办法/政策和计算机行业的规范。 如果本服务条款任何规定根据适用的现行法律被确定为无效或无法实施,其他所有条款将继续有效。 一方变更通知、通讯地址或其他联系方式,应自变更之日起及时将变更后的地址、联系方式通知另一方,否则变更方应对此造成的一切后果承担责任。用户同意,贝锐 的有关通知只需在 贝锐 有关网页上发布即视为送达用户。 对条款的理解与解释应依据条款目的和文本原义及业界通行的理解和惯例进行,标题不应影响条款的解释。 有关条款或者约定若与双方以前签署的有关条款或者 贝锐 的有关陈述不一致或者相抵触的,以本服务条款为准。 在有效服务期内,因 贝锐 上市、被收购、与第三方合并、名称变更等事由,用户同意 贝锐 可以将其权利和/或义务转让给相应的 贝锐 权利/义务的承受者。 贝锐 有权在必要时修改服务条款,贝锐 服务条款一旦发生变动,将会在其网站的重要页面上提示有关内容。用户如果不同意所改动的内容,可以主动取消获得的服务;如果用户继续接受服务,则视为接受本服务条款的变动。 用户在此再次保证已经完全阅读并理解了上述在线域名注册服务条款并自愿正式进入在线域名注册程序,接受上述所有条款的约束。 上海贝锐信息科技股份有限公司国际域名在线注册服务条款补充协议(域名自动续费) 本协议由上海贝锐信息科技股份有限公司(以下简称乙方)与向上海贝锐信息科技股份有限公司购买域名并接受上海贝锐信息科技股份有限公司域名自动续费服务的用户(以下简称甲方)经友好协商签订。 一. 服务内容 针对甲方对域名自动续费的需求,避免甲方因为疏忽或者其它原因导致域名未能及时续费所带来的损失,乙方为甲方提供自动续费服务。 适用域名:贝锐 提供注册的所有顶级后缀的域名。 二. 双方权利和义务 甲方的权利和义务: 1 甲方有权监督和处理协议执行情况,对于域名续费行为进行及时的追认、确定。 2 甲方有义务对已经确认续费的域名,及时交纳相应的域名续费费用。 乙方的权利与义务: 1 乙方可以为已选择了自动续费服务的域名在域名到期前十日内立即续费,并有权对已经自动续费成功的域名续费费用进行追缴。 2 如甲方帐户仍有足够余额,乙方可直接通过帐户收取域名续费金,乙方应在甲方域名续费成功后,发送续费成功通知信,通知甲方续费完成。 3 乙方确认甲方帐户余额不足时,则发邮件通知甲方续费, 甲方十日内入款,乙方将在甲方入款后及时办理域名续费事宜。 三.违约责任 甲方在域名到期前十日内没有及时入款,乙方将不办理该域名自动续费事宜。由于甲方入款迟延造成有关该域名的任何后果,甲方自行承担。 四.免责条款 若甲方已选择自动续费服务的域名,在续费时,注册局已停止此类域名的续费服务,乙方不承担与此相关的一切责任。 五.附则 甲乙双方应本着诚实信用的原则完整履行本协议。 本协议作为双方所签订域名注册协议补充协议,与域名注册协议具有同等法律效力。本协议未约定部分,须参照双方所签订域名注册协议确定。
添加CNAME记录
1.定义 CNAME(Canonical Name)记录,通常称别名指向。在这里,您可以定义一个主机别名,比如设置 www.A.com, 用来指向一个主机 www.B.com, 那么以后就可以用 www.A.com 来代替访问www.B.com 了。但成功设置CNAME记录后您可能需要在主机 www.B.com 设置相应服务策略规则进行对应该域名,才能真正实现CNAME功能。 2.操作步骤 (1)操作路径:【域名管理平台】->【域名列表】->【顶级域名】 登录域名管理平台,在【域名列表】界面,选择需设置解析的域名。 (2)在【域名详情】界面,点击<域名解析>。 (3)在【域名解析】界面,点击 <添加记录> 按钮。 (4)在弹窗内选择添加解析记录,并填写相关信息: 选项 说明 主机记录 解析域名的前缀例如现操作的顶级域名为example.com,其“主机记录”设置举例:①www:用于网站解析,表示解析的域名为“www.example.com”②abc:用于子域名解析,表示解析的域名为“example.com”的子域名“abc.example.com”③mail:常用于邮箱解析,表示解析的域名为“mail.example.com”④:用于泛解析,表示解析的域名为“.example.com”,匹配“example.com”的所有子域名⑤空:用于网站解析,表示解析的域名为“example.com”。主机记录置为空,还可用于为空头域名“@”添加解析 记录类型 CNAME一般用于CDN加速场景,将域名指向另一个域名,实现用 A 域名访问到 B 域名 记录值 CNAME 指向的域名,若单指向IP,不一定就能访问对应的网站,需要对应的网站服务器允许绑定了这个域名访问,才可以访问。只可以填写域名 TTL TTL 即 Time To Live,指地方 DNS 缓存域名记录信息的时间,缓存失效后会再次到贝锐获取记录 3600秒(1小时)如果 IP 极少变动(一年几次),建议选择3600秒,数值越小,解析速度越快(可按需修改为其他值) 确认内容填写无误,点击 <确定> 即可。 (5)添加成功。 3.测试访问 (1)进入命令状态;(开始菜单 - 运行 - CMD[回车]); (2)输入命令" nslookup -q=cname cname.xxx.top ",查看返回的结果与设置的是否一致即可。
.gov.cn域名注册流程
注册.gov .cn域名,需要注意以下事项: 1、因CNNIC规定.gov.cn域名目前仅向政府机关单位开放注册 注意 在《中华人民共和国组织机构代码证》中的机构类型必需为机关法人。 2、为保证域名注册成功,请您在申请注册该域名后48小时内向我们提供以下的资料: ①法人类型为机关法人代表的政府事业单位的证件,建议在上面注明用途"仅作为申请 xxxx 域名的 凭证" ②注册联系人身份证明(需包含身份证正反两面), 建议在上面注明用途"仅作为申请 xxxx 域名 的凭证" ③加盖公章的《域名注册申请表》(原件),请在域名预注册成功后,根据后台页面提示下载、打印并填写完整。其中所属注册服务机构一栏请填写上海贝锐信息科技股份有限公司,域名注册人ID栏目请留空,申请单位(盖章)一栏需要加盖域名注册企业的红印公章并由域名注册联系人在印章中空白处签名(红印章压着签名,但签名和公章不可重叠不清) 注意 ①建议通过扫描仪、数码相机或手机拍照方式制作以上电子版注册申请材料 ②逾期不提供资料将取消注册,如因资料延误导致域名被取消注册,由域名注册人自行承担 ③用户成功支付订单后本服务合同即刻生效,用户应按照贝锐平台系统提醒按时提交必要的资料。若因用户原因无法提供所需资料,贝锐不予退款处理 ④提交域名注册后(且已结算),请到【管理中心】—>【域名】—>【业务状态】页面上传上述域名注册申请资料,以便我们协助您完成域名注册申请事宜 3、资料邮寄地址: 地 址:广州市天河区中山大道建工路15号首层 收件人:上海贝锐信息科技股份有限公司-贝锐域名部 邮 编:510665 电 话:400-601-0000 4、中国互联网信息中心(CNNIC)现已开始对新注册的.gov.cn域名进行电话回访,内容包括:注册单位是否申请该域名、域名注册信息中管理联系人及联系电话是否为注册单位人员和电话。若CNNIC电话回访仍无法联系到注册单位、注册单位明确表示未注册该域名、域名注册信息经核实不真实、不准确,域名注册申请将被审核拒绝。在此提醒各域名注册者,请确保提交的.gov.cn域名注册信息的真实、准确、完整。 5、注册流程图:
域名转入解析
1. 什么是转入域名解析? 转入域名管理是指您将非贝锐注册的顶级域名DNS记录指向到我们的DNS服务器,并由贝锐为您的域名提供DNS解析的域名管理平台。贝锐默认的域名DNS服务器为ns1.oray.net和ns2.oray.net。 非贝锐注册的顶级域名办理转入域名管理业务后即可使用所有由贝锐提供的域名解析服务,包括: 1、标准级别的花生壳动态域名解析服务; 2、独立域名记录、泛域名记录以及无限制三级域名记录的生成,动态/静态资源指向设置域名记录的备份URL重定向跳转; 3、A、CNAME、MX、URL转发解析服务; 4、域名根与域名记录的转让和授权等域名增值服务。 【点击进入域名转入解析页面】 【点击进入域名管理平台】 2. 如何办理转入域名解析? (1)进入转入解析页面,输入需要办理转入解析服务器的顶级域名后,点击“查询”; (2)购买转入域名管理服务基本服务; ![]( https://storage-cdn.oray.com/help/6f490f98a2991293fb09579b2872e581)**注意:转入域名管理服务基本服务费用是40元起/年/域名(支持域名的A记录、MX记录及可添加5个子域名记录),用户可根据自身需求选择域名功能配件。** (3)联系您域名域名注册商,把需要转入解析的域名NS记录修改成ns1.oray.net和ns2.oray.net。48小时后,转入解析成功。![]( https://storage-cdn.oray.com/help/6f490f98a2991293fb09579b2872e581)**注意**1.若域名的NS记录除ns1.oray.net 和 ns2.oray.net 之外还存在其他DNS,那么域名解析会受到一定的影响;请确保您的域名只有ns1.oray.net 和ns2.oray.net 这两条NS记录。 2.DNS的转移一般需要48小时,您可以使用以下命令进行检查 DNS 是否成功转移:nslookup -q=ns 【YourDomain】 202.96.128.166。 3.域名成功转入后,该域名的注册续费以及修改该域名信息等操作还在您的原注册商中进行;国际域名可以登录http://www.internic.net 检查您的域名注册商,国内域名请登录 http://ewhois.cnnic.cn 查询。 3. 贝锐顶级域名如何修改域名NS记录? (1)登录域名管理平台,点击【域名列表】->【顶级域名】->【选择域名】; (2)点击 <修改DNS> ; (3)点击 <修改DNS服务器> ; (4)根据实际情况,选择“贝锐DNS解析”或“自定义填写DNS地址”。
不在贝锐注册的域名如何使用花生壳服务
在进行顶级域名转入时,请确定你的账号里至少有40元到账金额(贝锐要对转入的顶级域名收取40元起/个的域名管理费)。在域名转入解析页面【点击进入】,输入需办理转入服务的顶级域名后,点击查询并进行相应操作。 ![]( https://storage-cdn.oray.com/help/6f490f98a2991293fb09579b2872e581)**注意 1. 在域名转入前,请联系您的域名注册商,把需要转入的域名的NS记录修改成 ns1.oray.net 和 ns2.oray.net,注意,如果您的域名的 NS 除了 ns1.oray.net 和 ns2.oray.net 之外还存在其他DNS,那么域名解析会受到一定的影响;因此,请确保您的域名只有ns1.oray.net 和ns2.oray.net 这两条 NS记录。 2. DNS的转移一般需要48小时,您可以使用以下命令进行检查 DNS 是否成功转移:nslookup -q=ns YourDomain 202.96.128.166 。 3. 请确保您的账号下的可用余额可用以支付域名管理费,如果账号余额不足的情况下,可在线支付。 4. 域名成功转入后,您可以通过域名管理的顶级域名记录功能根据用户提交转入DNS服务时选择域名功能配件,为这个域名添加域名记录(子域名),并可以设置各域名记录(子域名)的DNS资源记录(A记录、CNAME记录、MX记录)。 5. 域名成功转入后,该域名的注册续费以及修改该域名信息等操作还在您的原注册商中进行;国际域名可以登录http://www.internic.net 检查您的域名注册商,国内域名请登录http://ewhois.cnnic.cn 查询。 6.域名管理费从域名成功转入后开始扣除,服务年限为一年,请注意在次年为您的域名缴纳新一年的域名管理费。**
IT运维解决方案
1. 背景 伴随着科技智能的发展,企业在运营过程中会运用诸多网络设备,如服务器、员工办公电脑等。IT部门的作用就是协助企业解决日常IT支撑、业务系统等方面的问题,为企业提供稳定的运营条件,从容应对快速变化的用户需求和激烈的市场竞争。 IT运维工作包含网络硬件设备的调配及维护、软件的升级管理及故障排查和通讯终端的日常管理维护等,所涉及到的行业知识范围广泛,在实际工作中,要求IT运维人员不仅需拥有大量专业性的知识,更需要具备快速的响应能力,以便在遇到故障能够快速的解决,保证企业设备顺利运行。 2. 实施难点 面对日益激增的IT复杂性和业务需求的快速变化,IT应用在运行过程中发生性能下降或者服务不可用等故障的可能性大大增加。 如何更高效、更智能地开展IT运维,保证业务的连续性和IT系统的稳定性,成为企业业务发展的迫切需要。 传统运维手段,越来越难以满足企业业务高速发展的需求。 传统的企业运维存在以下的IT运维问题: (1)传统运维方式响应慢、效率低,故障时间长导致业务中断 (2)终端设备地域分布广、平台不一、网络环境复杂,难以实现集中管理 (3)设备数量多、涉及多个业务部门,须处理不同的设备权限并保障信息安全,管理难度大 (4)对运维人员及业务操作缺少有效监管,存在安全隐患 3. 方案部署 在IT运维管理工作中,部署便捷、易于管理、功能完善的运维方案能填补常规运维的不足,进而搭建一个立体化的运维体系。 向日葵IT运维解决方案主要针对无人值守设备,向日葵的多系统支持,能完整覆盖,如内部的服务器、外部广告大屏、自动售卖机,连锁门店收银机等设备;在对大量设备统一管理上,向日葵提供大数量级设备的快速布属与管理方案,支持设备状态告警策略,同时拥有设备屏幕墙,消息群发、文件分发等多种IT运维管理功能。 以下为向日葵IT运维解决方案部署步骤: 3.1 精细化授权 在企业运维管理工作中,管理员使用第三方导入或自定义组织架构为员工设置对应的向日葵角色权限,并创建独立的向日葵账号。 还可通过角色权限和账号模块功能,根据人员职权的高低和角色需求进行动态授权。 3.1.1 完成企业信息 完成企业信息的企业名称、企业别名的设置。 企业别名是企业的唯一标识,用于登录企业账号,完成企业认证(推荐)后可使用向日葵管理平台完整功能。企业别名一旦确认将无法修改。 3.1.2 账号管理 在向日葵管理平台,可通过第三方导入企业组织架构,形成向日葵账号架构体系。也可以据企业原先架构,自定义创建组织架构,并为每位运维人员创建账号,以及划分所属部门和角色权限。支持直接导入原有的组织及账号信息,无需重复设置。企业管理员可通过角色和账号模块功能,根据人员职权去授权远程运维企业设备,提高运维效率,企业信息安全更为保障。 3.1.2.1 第三方导入 第三方导入账号架构体系,目前支持导入和企业微信导入。若企业已在使用飞书和企业微信为协作工具,可通过设置授权,直接同步企业部门架构在内的组织信息。 点击“第三方接入”按钮,选择第三方接入的协作工具,快速同步企业组织及成员,实现快速部署,实现统一管理,帮助降低企业人力成本。 附: 飞书授权配置说明帮助 企业微信授权配置说明帮助 3.1.2.2 自定义组织架构 操作路径:【向日葵管理平台】->【账号体系】->【账号管理】->【组织架构】 可添加子部门并划分其所属部门,支持创建多层级部门。 支持重命名部门名称及调整部门的层级排序,亦可批量给整个部门授权可管理的设备。 (具体功能描述,请见下文3.1.4章节) (1)添加账号 操作路径:【向日葵管理平台】->【账号体系】->【账号管理】 角色创建完成后,接着为每位员工创建独立的账号,用于远程运维时登录控制端软件。 点击“添加账号”按钮,设置员工账号基础信息(姓名、账号、手机、邮箱等),以及设定账号所属部门和角色。 (2)批量导入 下载模板后根据企业原有组织、角色、账号信息填写,一次性导入,无需再次设置部门、角色,一步到位。 3.1.3 角色授权 根据企业人员职能赋予对应的向日葵软件操作权限。 如:添加IT运维角色权限,远控基础权限及控制端权限均允许使用,但不可查看管理平台设备列表。 角色权限添加路径:【向日葵管理平台】->【账号体系】->【角色权限】->【角色名称】->【+】 创建角色名称后可添加该角色关联的账号以及设置关联账号的远控权限、控制端权限及管理权限。 添加角色账号 设置角色权限 3.1.4 授权账号管理设备 IT运维管理者对不同等级的运维人员的权限和责任进行规范化管理,根据运维人力去分配授权所负责的设备。 如:授权资深IT运维卢小新可管理上海行政二部的所有设备。 操作路径:【账号体系】->【账号管理】->【选中指定员工账号】->【可管理设备】 点击账号对应的可管理设备后,勾选上海行政二部的所有设备。可管理设备添加成功后,员工账号上显示可管理设备数目。 且使用其账号登录向日葵企业控制端,设备列表中将显示其可管理的设备。 若授权设备分组,后续分组中新增设备将自动授权,简化管理。 除通过管理员在管理平台授权账号管理设备外,员工可以通过登录自己的企业账号认领该设备进行管理。 (1)在被控设备中,下载安装企业客户端并使用员工的企业账号进行登录; (2)员工在当前设备下载控制端并使用员工的企业账号进行登录,员工可在控制端的设备列表中管理被控设备,如发起桌面控制。 3.2 安装部署 IT运维管理者可在管理平台定制专属客户端。 安装包定制,可使用「批量部署」或「定制软件」进行软件部署。【批量部署】仅可自定义部署基础设置和安全设置,若需自定义更多功能,可选择【定制软件】。定制软件在批量部署的基础上,还支持VI定制,有助于提升企业形象和员工归属感。 企业+办公Pro版账号服务不支持【定制软件】,需额外增购该功能服务。 服务级别 行业青春版 行业版 办公Pro版 标准版 高级版 畅享版 至尊版 批量部署 支持 支持 支持 支持 支持 支持 支持 定制软件 不支持 支持Win控制端和Win客户端 需增购 支持 支持 支持 支持 (1)定制软件 定制软件可为企业定制具备企业风格的专属远程控制软件,个性化程度高,如软件皮肤、图标、颜色和功能等,预配置安装包属性,免去后期逐一设置的烦恼。 登录向日葵管理平台,点击【设备管理】->【安装部署】->【软件定制】,选择适用的系统类型客户端。 1)定制向日葵软件的名称、皮肤、logo标识等,拥有独立企业风格的员工办公软件,提升员工对企业的归属感。 2)定制向日葵软件的界面显示功能、安装包名称或主机名后缀等,在“设备授权账号”设置项中,选择为“所有账号(当前账号及企业内其他账号)”登录。 3)客户端定制完成后,员工在办公电脑安装管理员提供的定制包软件。安装后账号默认绑定到企业内部,无需员工手动输账号密码登录。注:3.5.0.51346及以上版本的定制包,支持登录企业账号及企业设备认领,员工可通过登录自己的企业账号认领该设备,无需管理员授权。 3.2.1 软件推送更新 操作路径:【向日葵管理平台】->【设备管理】->【安装部署】 针对使用批量部署和软件定制部署向日葵软件的企业,可通过向日葵管理平台批量推送更新。 企业可选择部分已部署向日葵WIndows客户端的设备执行软件升级,快速升级部署。令企业更安全、有效管理企业设备。 注意:目前支持Windows客户端 更多帮助:升级已部署设备(点击查看) 3.2.2 修改安装包策略 操作路径:【向日葵管理平台】->【设备管理】->【安装部署】 IT运维管理者可以随时在管理后台调整策略内容,调整后策略将会实时下发实时生效。 以定制软件的安装包为例: (1)选择需要修改策略的安装包。 (2)在客户端策略界面,选择策略状态和修改安装包策略设置,并点击<保存>。 (3)修改安装包策略成功。 注意:开启策略状态后,客户端软件配置将以策略为准,且设备本地无法修改。 更多帮助: 批量部署(点击查看) 软件定制(点击查看) 3.3 设备管理 企业可根据业务或者管理需求,授权账号去管理指定的设备,也可以对设备添加可管理的账号。 在企业IT运维工作中,将企业设备进行分组管理,可按部门、按地区等进行划分。支持将整个分组划分给IT运维人员进行管理,运维人员使用企业分配的员工账号登录控制端的设备列表,可以看到自己可管理的设备,实现分部门、分区域、分权管理。 3.3.1 授权管理设备账号 向日葵管理平台的【设备管理】->【设备列表】可统一对设备进行管理。IT运维管理员可根据企业架构、设备类型等创建分组,企业可以将指定部门或指定设备的管理权限划分到指定的IT运维人员账号。 路径:【设备管理】->【设备列表】->【选中指定设备】->【授权】 在【设备列表】中,选中要授权管理的设备,点击“授权”,授权企业内部或外部账号去管理指定的设备。 运维人员使用其账号登录向日葵企业控制端,设备列表中将显示已授权管理的设备,其他未授权管理的账号无法管理该设备。 在【设备列表的】中,设备组可授权至企业内部的部门组进行管理。授权后,设备组新增设备或者部门组新增人员将自动形成其授权管理的关系。 3.3.2 控制端设备列表 账号所属的角色授权什么远控功能,在控制端上将显示对应的功能。运维人员使用分配的员工账号在企业版控制端登录,通过设备列表中可看到管理员授权给自己管理的设备,可快速、便捷管理设备。 运维人员通过桌面控制功能,快速又安全地访问分散在外的设备,无需到达现场,实现无人值守,远程故障诊断、排除和解决业务系统设备等效果。 如:上述授权资深IT运维陈小明可管理多部门的设备,其角色权限为所有的远程操作功能(CDM/SSH、桌面控制、桌面观看、摄像头、远程文件、远程管理)均可操作。 3.3.3 屏幕墙 向日葵企业版控制端的屏幕墙监控,支持同时查看多台电脑画面,设备使用情况一目了然。运维人员可对关键设备创建屏幕墙,通过屏幕墙监控设备运行情况,方便快速发现突发故障。 3.4 安全设置与审计 向日葵为IT远程运维提供多维度的安全保护,支持登录行为审计和添加水印保护,确保身份环境可信。并提供远控事件信息、控制端和客户端日志,可以起到监控预防和事后追溯的作用。 3.4.1系统安全设置 向日葵提供多因子安全保护和新设备登录验证机制,以确保企业登录设备的身份环境可信。只在授权的环境中才允许登录,有效防止了员工在不安全的网络下或使用公共电脑登录,规避了企业信息泄露的风险,从而保障企业设备安全。 3.4.1.1 账号保护 管理员开启【设备验证登录保护】后,员工在新设备登录向日葵控制端需要进行身份验证,登录过的设备需要重新验证。 3.4.1.2 登录限制 管理员开启登录限制后,企业账号在登录控制端或管理平台时,系统除了校验账号密码外,还会检验登录设备是否符合登录限制设定的条件规则,为账号安全提供更高级别的保障。 3.4.1.3 员工控制端设备 仅记录员工的登录设备数据,方便管理员查看整个企业的登录设备记录,如发现非常用设备或其他异常情况时,可以随时将异常设备踢下线。 3.4.1.4 管理员端控制端设备 仅记录管理员的登录设备记录。同样,当管理员发现某项登录记录存在异常时,可将其踢下线或删除。 3.4.2 水印策略 操作路径:【向日葵管理平台】->系统管理】->【安全设置】 企业管理员在管理平台定制水印规则,规范敏感岗位的运维行为,对运维人员进行有效告警。 开启后,IT运维人员远控公司设备时远控窗口自动添加水印,基于运维人员身份、远程运维时间等信息进行告警。加强终端的信息安全,以防止员工泄漏企业信息,即使信息遭泄漏也有迹可循。 注:开启水印策略教程(点击查看) 3.4.3 安全审计 安全审计功能对日常的运维事件生成日志记录,包括远控、被控、控制端、客户端和操作日志,可以起到监控预防和事后追溯的作用。 在日常的运维工作中,管理员可以从审计日志中及时发现各类安全隐患,快速对隐患进行处理,从而避免安全事件的发生。当出现违规操作、设备运行异常或安全事件时,可以通过安全审计产生的日志记录,分析设备、事件、登录时间/地点等因素,追溯安全事件的轨迹;可以对事件记录进行细粒度审计,还原操作的真相。 附:审计功能说明 向日葵IT运维解决方案可根据账号职能与角色需求进行动态授权, 让企业管理更加便捷、灵活。自由授权设备权限,实现什么人员管理什么设备。提供事前、中、后多维度的安全保护,从身份、权限、行为上进行全方位管控,为企业提供可信赖的安全技术和成熟的管理框架,让每一次远程运维都做到可防、可管、可查。 若有更多需求,请联系我们为您量身打造的专属IT运维解决方案。
域名
1 ) 什么是域名? 域名是用来确定网址的独特的名称。当互联网用户寻找网站时,域名允许网域名称系统( DNS )下的计算机确认该网站。例如:oray.com。 2)我为什么要拥有域名? 拥有域名,可以使人们在万维网上快速、方便地找到该网站。这是一个不可或缺的工具,它向公众介绍业务;企业往往通过注册域名来保护他们的网站,以免遭到侵害或未经授权的使用。 3 )注册域名有哪些要求? 域名只能包含字符A-Z , 0-9; 域名可含有连字号 - ,但不能以连字符作为开头或结尾; 空格及特殊字符,如问号( ? ) ,感叹号( ! ) ,和下划线( _ )是不允许使用的; 所有域名在任何时候都必须有至少2个名称服务器和IPs列表; 域名不能用连字符作为第三和第四个字符(预留作多语种域名注册,例如: xn--example.com); 在域名注册申请中所提供的信息是真实的、正确的、最新的、完整的; 注册人必须随时保持域名的WHOIS信息为最新的。 4 )贝锐提供哪些网域后缀? 客户可通过贝锐享受多达800种域名注册服务。具体后缀可参考域名注册 http://domain.oray.com/more/ 5 )每个域名费用是多少? 客户可参考贝锐域名服务里的价格列表 http://domain.oray.com/price/ 6 )贝锐提供哪几种国际化域名( IDN )? 贝锐目前提供二级IDN域名:.com、.net、.cn、.tv、.tw、.biz、.cc,我们提供中文注册。 7 )确定域名是否可用? 贝锐可以尝试通过域名服务页面注册域名,如果名称仍然可用,系统会自动提示进行下一步。如果域名已经被注册,请键入一个新名称并再次搜索。 8 )我的客户能够用中文域名访问我的网站吗? 目前正在浏览器中使用i-Nav plug-in的客户和正在使用支持IDN功能的浏览器的客户,可以用中文域名访问您的网站。然而,由于供应商将不再提供i-Nav plug-in的服务,因此,该功能将于2011年6月7日后不再被支持。我们建议网站访问者在资源情况下安装一个支持IDN功能的浏览器,并用其自己的语言,使用IDN浏览网站。目前支持IDN的少数浏览器如下: Microsoft Internet Explorer 网址: http://www.microsoft.com/windows/downloads/ie/getitnow.mspx 平台: Microsoft Windows XP , Windows Server 2003 版本: 7.0和更高 Netscape Navigator (只有英文版) 网址: http://browser.netscape.com/ns8/ 平台: Windows 版本: 7.0和更高 OPERA网页浏览器 网址: http://www.opera.com 平台: Windows , Mac OS X中, Linux 版本: 7.2或更高 9 )贝锐在域名注册同时提供的增值服务是什么? 在贝锐注册域名 ,您不仅可以获得您想要的域名。如果域名指向我们默认的DNS ,可以升级DNS增值服务包括:CNAME记录设置,URL跳转设置,泛域名支持,可添加无限子域名,TXT记录,SRV记录。进一步的细节,请参阅http://service.oray.com/question/199.html 10 )我想使用贝锐默认的DNS ,什么是DNS?是否收费? 贝锐默认的DNS位于ns1.oray.net和ns2.oray.net。 使用贝锐默认的DNS对所有客户都是免费的。
管理APP for Android & iOS
为了方便广大用户使用和管理花生壳,推出了手机端管理APP。管理APP支持远程管理花生壳,比如新增/编辑映射、管理智能硬件等。 下面请看花生壳管理APP的使用步骤(以Android端为例)。 1. APP下载与登录 1.1 下载 ① 在应用市场搜索并下载; ② 花生壳官网或客户端扫码下载。 1.2 登录 花生壳管理APP支持以下的登录方式,选择其中一种完成登录即可: ① 账号密码登录; ② 微信授权登录; ③ 免密登录(手机号码+验证码方式); ④ Apple ID登录(仅限iOS设备)。 2. 界面介绍 2.1 映射 此界面可以查看当前帐号或子帐号的在线/离线状态、服务等级、自定义映射及场景映射信息等,并支持在贝锐花生壳管理上直接创建和修改映射内容。 2.1.1 帐号与服务 (1)帐号信息 ① 显示帐号名、服务版本和到期时间 ② 可为本帐号修改备注,查看登录信息、花生壳状态(在线or离线)、公网IP(当前网络出口IP)和重登花生壳(发送指令重登花生壳客户端) ③ 点击界面上方帐号切换按钮,可以选择添加子帐号、切换登录 (2)服务 ① 查看当前服务版本 ② 点击<续费>跳转至操作页面 2.1.2 配件 显示当前帐号的配置内容,如配件中心、映射数、超级带宽。 2.1.2.1 配件中心 可以查看帐号下所拥有的配置功能,支持对配件进行管理。帐号等级不同,支持开通的配置内容有所不同,下面以精英版服务的帐号为例。 (1)辅助配件 选项 描述 超级带宽 超级带宽5M起步,性价比高延迟低 夜间带宽 开启后,18:00~次日8:00所有映射带宽提升100% 固定端口 查看帐号下已有的固定端口,作用是删除映射重建,可复用购买的端口号 国内线路迁移 顶级域名设置映射默认走海外转发服务器,购买线路迁移服务并完成域名备案后,可将顶级域名的映射迁移到国内服务器,以提升映射访问速度和稳定性 免费流量 付费用户每月不限流量使用 域名 查看帐号下所拥有的域名,及其诊断信息 (2)映射、安全配件 配件类型 选项 描述 映射配件 HTTPS加密映射 自动化部署HTTPS证书以加密访问HTTP协议应用,用户服务器无需部署SSL证书,内网穿透HTTP转化为HTTPS使用443端口映射 映射保留 30天无流量的映射自动保留,系统不自动删除 安全配件 访问IP白名单 指定白名单内的IP地址能访问帐号下的映射 访问IP黑名单 指定黑名单内的IP地址禁止访问帐号下的映射 (3)特殊配件 选项 描述 请求头扩展 支持通过X-Forward-for获取真实访问来源的IP 通道直连模式 根据访问量选择适合的链接模式 访问IP策略 可设置IPV4、IPV6的访问策略 登录线路设置 提供七大线路选择,选择与服务器当前网络相同的登录线路获得更流畅的网络体验 客户端通信加密 花生壳客户端通过SSL的方式与花生壳服务器建立连接,使数据更加安全。同时兼容适配各类特殊的网络,可在有防火墙和使用特殊协议的环境下开通使用 2.1.3 自定义映射 在贝锐花生壳管理上可以添加、删除、编辑映射。 2.1.3.1 添加映射 点击<+>新增映射按钮,根据实际情况填写映射信息。有四种映射类型选择:TCP、HTTPS、HTTP、Socks5。 名称 功能 TCP 用于准确性要求高的数据传输,如文件传输、远程访问等,不支持创建网站或在浏览器访问 HTTPS 用于安全性要求高的网站类数据传输,外网端口443,花生壳已自动部署SSL证书,本地无需额外部署支持在用户和服务器之间实现加密访问,有效防止隐私信息被窃取,提升客户对企业网站的信任度;花生壳HTTPS映射已自动部署加密证书,本地应用无需再次部署 HTTP 用于搭建HTTP协议的站点,非加密访问,默认端口80 Socks5 用于特殊环境下需要使用代理才能访问的应用,禁止用于违法违规应用 为了响应《互联网信息服务管理办法》及配合公安部门对违法行为的打击,Socks5映射仅提供给付费级别的特殊用户使用,如有需要请联系客服 2.1.3.2 示例 (1)下面以创建TCP映射(发布Windows远程桌面)为例,演示映射内容如何填写; 选项 描述 映射名称 为当前映射设置名称,以方便区分和记忆 映射类型 选择TCP 映射模板 选择Windows远程桌面 外网域名 选择用于外网访问的域名地址 外网端口 动态端口指生成映射后由系统自动分配5位数的端口号;固定端口需另外购买,在有效期内即使映射删除后也可重复使用。根据实际情况选择即可 内网主机 填写服务器的局域网IP地址 内网端口 填写当前服务应用的内网端口号 带宽 用户根据帐号等级可分配给当前映射的带宽数量,也可以根据需求升级带宽,带宽升级后可有效提升映射的访问速度,每条映射可分配的带宽上限为10Mbps 确认映射内容填写无误,点击<保存>即可。 2.1.3.3 其他操作 在“自定义映射”列表中,对选中的映射左滑,可进行诊断、编辑和删除操作。 (1)编辑映射 点击<编辑>,支持修改映射的应用名称、内网主机IP、内网端口和带宽的参数。 (2)诊断、删除 ① 点击<诊断>,可查看当前映射的诊断信息,其中包含了域名解析是否成功、是否连接转发服务器成功以及内网服务的诊断状态。当遇到映射异常或无法使用时,可将诊断信息截图后提供给技术工程师协助判断问题 ② 点击<删除>,可将当前的映射删除。若当前映射的外网端口是动态端口,删除后端口无法恢复 2.1.4 场景映射 花生壳提供单独付费的场景映射服务,特点有: ① 不占用帐号原有的映射数 ② 每条映射带宽为3M(用于远程群晖NAS设备映射可享10M标准带宽) ③ 目前支持场景映射类型:幻兽帕鲁、远程群晖NAS设备、我的世界游戏联机、3389远程桌面、远程 MySQL数据库、远程SQL Server数据库、远程SSH服务等 场景映射需单独开通后才可使用,开通后,系统会为你自动创建对应的映射,外网端口为系统随机分配的5位数端口(使用HTTPS协议的映射除外),内网端口不支持修改,仅能修改内网IP。 注意:场景映射价格以官网为准。 2.1.5 文件分享 花生壳提供文件分享服务,特点有: ① 本地化存储文件 ② 共享空间不限量 ③ 通过浏览器即可远程访问,隐私安全有保障 文件分享需单独开通后才可使用,选择需购买文件库数量,确认无误后结算即可开通完成。【点击查看花生壳文件分享帮助教程】 2.2 设备 这里可以管理帐号下已绑定的智能硬件,包括花生壳硬件设备以及内嵌了花生壳功能的其它设备。 2.2.1 添加设备 2.2.1.1 通过SN码添加 在右上角点击<+>按钮,选择“添加设备”,根据提示输入设备的SN码添加设备。 2.2.1.2 扫描二维码添加 在右上角点击<+>按钮,选择“扫一扫”,扫描花生壳智能硬件背面的二维码进行添加。 2.2.1.3 局域网扫描添加 在右上角点击<+>按钮,选择“局域网扫描”,贝锐花生壳管理会自动扫描与手机连接相同网络的花生壳硬件设备。 扫描完成后,输入设备密码,即可将花生壳硬件绑定到当前登录的帐号下。 2.2.2 管理设备 在设备列表中,点击对应在线的智能硬件设备,可对设备进行管理。 选项 描述 设备信息 显示设备型号、SN码和MAC地址 登录帐号 查看或更换设备当前登录的帐号,可登录其他贝锐帐号登录 网络设置 可修改智能硬件的上网方式,支持DHCP和静态IP方式上网 内核版本 查看或检查更新当前硬件的内核版本 重启和重置 重启或重置当前硬件(重置后需重新绑定及登录帐号) 2.2.2.1 激活设备 ① 如果添加的是已激活的设备,无需重复激活 ② 如果添加的是全新或已重置的花生壳硬件,需激活设备才能正常使用 激活步骤如下: 在设备列表中,点击对应在线需激活的花生壳智能硬件设备,选择设备登录帐号,等待设备激活成功后,即可成功绑定在帐号下。 2.2.3 解绑设备 已添加到帐号下的设备,在设备列表中,长按对应的设备,点击<解除管理>,可将此智能设备从当前帐号下中移除,不影响智能设备已登录帐号登录状态。 2.3 发现 在【发现】模块中,可以查看花生壳相关的干货教程、学生计划。 2.4 我的 在【我的】模块中,可以查看帐号名称、服务代码、进入硬件商城、阳光小店、查看我的兑换、实名认证、我的消息、使用手册、联系我们的方式和关于花生壳等。 2.4.1 硬件商城 点击<硬件商城>,跳转到花生壳硬件的购买页面,可自行选购。 2.4.2 阳光小店 点击<阳光小店>,进入贝锐阳光小店,可通过做任务的方式收集阳光,收集的阳光可兑换相关的服务内容。 2.4.3 我的兑换 在<我的兑换>中,可输入兑换码进行兑换贝锐产品。 2.4.4 实名认证 查看帐号实名认证状态和信息,支持进行实名认证操作和更新实名认证信息。 2.4.5 我的消息 查看我的消息通知。 2.4.6 使用手册 查看花生壳软硬件产品的详细使用教程。 2.4.7 联系我们 通过不同方式向花生壳工作人员寻求帮助。 2.4.8 关于花生壳 查看花生壳官网地址、官方微信公众号、隐私政策、用户许可协议、当前版本是否为最新以及提交意见至花生壳以促进产品改进优化。 2.5 设置 在客户端右上角点击<设置>图标按钮,进入贝锐花生壳管理的设置界面。 2.5.1 修改手机号 修改花生壳帐号绑定的手机号,经原手机号码或邮箱验证后可修改。 2.5.2 修改密码 修改花生壳帐号登录密码,经原手机号码或邮箱验证通过后可修改。 2.5.3 绑定微信 绑定微信帐号后可使用微信方式登录贝锐花生壳管理。 2.5.4 个性化推荐 开启后,系统根据个性化为用户推荐不同的信息。 2.5.5 主题模式 开启后,贝锐花生壳管理将跟随系统打开或关闭暗黑模式。 2.5.6 消息设置 根据实际需要开启/关闭帐号或系统的通知消息。 2.5.7 系统权限设置 设置系统的相机、麦克风、拨打电话和通知的权限。 2.5.8 个人信息收集清单 查看贝锐花生壳管理个人信息收集清单。 2.5.9 第三方信息共享清单 查看贝锐花生壳管理第三方信息共享清单。 2.5.10 注销帐号 彻底注销帐号,经原手机号码或邮箱验证通过后,按照指示完成注销。 2.5.11 退出当前帐号 点击<退出当前帐号>,花生壳帐号自动退出,并返回到登录界面。 关于贝锐花生壳管理安卓版软件的使用介绍到此结束,如果在使用过程中遇到问题,可登录官网发起工单咨询,感谢您的观看。 2.1 映射 2.1.1 界面功能介绍 (1)自定义映射 此界面可以查看当前账号或子账号的在线/离线状态、服务等级、配件服务等;点击“升级“或“续费”可开通服务和配件; (2)场景映射 可查看添加的自定义映射及场景映射信息,并支持在花生壳管理APP上直接创建和修改映射内容。 2.1.2 新增映射 点击新增映射按钮“+”,根据页面要求完善映射信息: 选项 描述 映射名称 为当前映射设置名称,以方便区分和记忆 映射类型 提供TCP、HTTPS类型选择,根据所搭建的应用服务选择映射类型。如网站服务可选HTTPS、远程桌面选择TCP 映射模板 提供了Windows远程桌面、SSH服务和SQL Server服务的模板,选择模板后自动填充映射的内网主机和端口信息(支持修改) 外网域名 选择用于外网访问的域名地址 外网端口 动态端口:生成映射后由系统自动分配5位数的端口号;固定端口:需另外购买,在有效期内即使映射删除后也可重复使用。根据实际情况选择即可 内网主机 填写服务器的局域网IP地址 内网端口 填写当前服务应用的内网端口号 带宽 用户根据账号等级可分配给当前映射的带宽数量,也可以根据需求升级带宽,带宽升级后可有效提升映射的访问速度,每条映射可分配的带宽上限为10Mbps 以上映射信息内容确认填写无误后,点击“保存”,映射添加成功。(下图以远程桌面为例) ![]( https://storage-cdn.oray.com/help/6f490f98a2991293fb09579b2872e581) 注意: ①花生壳程序是映射本地内网服务实现外网访问 ②若异地登录花生壳,将会导致已设置的本地内网服务映射失效 ③若有多个地点的服务需要发布,建议通过多个账号进行映射操作 2.1.3 诊断、编辑和删除 在“自定义映射”列表中,对选中的映射左滑,可进行诊断、编辑和删除操作。 (1)编辑映射 点击“编辑”,支持修改映射的应用名称、内网主机IP、内网端口和带宽的参数; (2)诊断、删除 ① 点击“诊断”,可查看当前映射的诊断信息,其中包含了域名解析是否成功、是否连接转发服务器成功以及内网服务的诊断状态。当遇到映射异常或无法使用时,可将诊断信息截图后提供给技术工程师协助判断问题; ② 点击“删除”,可将当前的映射删除,若映射的外网端口是动态端口,删除后端口无法恢复。 2.2 设备 在【设备】界面,展示当前账号下可管理的硬件设备,包括花生壳硬件设备以及内嵌了花生壳功能的其它设备(如蒲公英设备内嵌的花生壳)。 2.2.1 添加设备 可通过添加设备(输入设备SN码)、扫一扫(扫描设备二维码)和局域网扫描3种方式把设备绑定在账号下进行管理。 2.2.2 管理设备 点击已绑定在账号下的花生壳硬件设备,可以查看设备的详细信息及对设备进行管理: 选项 描述 设备信息 显示设备型号、SN码和MAC地址 登录账号 管理设备所登录的账号,可登录其他贝锐账号登录,或当前绑定花生棒设备的账号登录 网络设置 若设备为花生壳盒子/花生棒,支持设置其网络 内核版本 查看或检查更新当前硬件的内核版本 重启和重置 重启或重置当前硬件(重置后需重新绑定及登录账号) 2.3 发现 (1)干货 可查看花生壳软件和硬件相关的使用小技巧,以及不同场景下的应用案例干货。 (2)计划 可查看花生壳当前正在进行的活动内容。 2.4 我的 (1)设置 在【我的】界面右上角点击设置图标按钮,进入设置界面。 选项 描述 修改手机号 按提示操作可更换账号绑定的手机号 修改密码 修改账号密码 绑定微信 将账号与微信绑定后,即可通过微信登录花生壳管理APP 个性化推荐 个性化推送促销优惠活动 主题模式 可选择手动开启/关闭或跟随系统启用不同的主题模式 消息设置 可设置接收/拒收花生壳推送的账号通知或系统消息 系统权限设置 获取手机系统相关权限设置 个人信息收集清单 使用本软件的个人信息收集清单 第三方信息共享清单 使用本软件的第三方信息共享清单 注销账号 注销登录当前账号 退出当前账号 退出当前登录账号并返回至登录界面。 (2)【我的】界面主要有以下功能 选项 描述 功能入口 硬件商城、阳光小店和我的兑换功能入口 实名认证 查看账号实名认证状态和信息,支持进行实名认证操作和更新实名认证信息 我的消息 查看我的消息通知 使用手册 查看花生壳软硬件产品的详细使用教程 联系我们 通过个不同方式向花生壳工作人员寻求帮助 关于花生壳 查看花生壳官网、官网微信、隐私政策、用户许可协议,并检查花生壳管理APP的更新情况 关于移动端花生壳管理APP的使用介绍到此结束,如果在使用过程中遇到问题,欢迎咨询花生壳工作人员获得帮助,感谢您的观看。 联系方式: ① 技术工单 ② 电话联系:400-601-0000转3
G5 - 上网设置指南
1. 产品简介 1.1 功能简介 蒲公英路由器G5——采用SD-WAN技术的企业级智能组网路由器。 蒲公英路由器使用智能组网服务,可搭配“客户端”(适合于移动办公),是一种全新的联网技术,能将异地局域网通过蒲公英路由器快速组建成虚拟专用网络,进行加密传输,替代传统VPN网络,以简捷的方式实现设备之间的互联互通。 本文将会详细介绍蒲公英G5的上网设置方式,点击查看G5部署指南。 1.2 产品外观 1.2.1 前面板 蒲公英G5前面板左边为LED指示灯,右边显示路由器型号G5。 指示灯说明如下图所示。 1.2.2 接口介绍 注:全千兆网口带防雷设计,可保证蒲公英路由器更稳定地使用。 2. 产品安装 3. 上网配置 3.1 设置主机网络 在您登录路由器的Web 配置界面之前,您需要设置计算机的 IP 地址,才能确保您能正常访问路由器的 Web 配置界面。 以Win10系统为例,成功通过网线连接好蒲公英G5后,根据以下流程进行设置。 单击桌面右下角的网络图标,选择“打开网络和Internet设置” 左键单击“更改适配器选项”,右键单击“以太网”,选择“属性” 双击“Internet协议版本4(TCP/IPv4)” 选择“自动获取IP地址”和“自动获得DNS服务器地址”,单击“确定” 3.2 连接到路由 蒲公英路由器提供了简单易用的Web 配置页面,您可通过Web 向导轻松完成上网配置。 配置前,请确保计算机已连接到路由器的黄色网口(LAN口),并且设置好了自动获取 IP 地址。 1.启动计算机浏览器访问http://oraybox.com 注:蒲公英G5默认为获取动态IP上网,会有3秒倒数提示,若能正常联网,会自动跳转至云管理平台。 2.输入蒲公英路由器的SN码(可在路由器背面查看)与默认密码(admin)进入管理页面; 3.进入蒲公英管理平台,路由器首次使用需进行初始化,输入对应信息点击提交; 4.若无法联网,会进入蒲公英本地管理页面,根据网络情况设置上网方式。 3.3 设置上网方式 宽带拨号:通过输入宽带运营商提供的账号密码进行登录。 动态IP:自动获取上层设备分配下来的IP地址进行联网。 静态IP:手动设置IP、子网掩码以及网关进行联网。 3G/4G USB适配器:通过连接3G/4G上网适配器联网。(点击查看支持型号) 3.4 路由器本地管理 3.4.1 系统信息 可查看G5的网口状态、上网信息、局域网信息和路由信息,并支持相关的设置。 3.4.2 上网设置 可查看蒲公英G5当前的上网方式以及IP地址、子网掩码、默认网关、DNS、备用网络等信息。 点击“切换上网方式”,可重新设置的联网方式,各个选项的具体含义请参考3.3小节。 3.4.3 局域网设置 可设置蒲公英G5所使用的局域网IP以及子网掩码。 3.4.4 本地设备 可查看蒲公英G5下所连接的终端设备及相应的网络信息,并可对设备进行网速限制或上网限制。
抱歉,没有找到与“650.net.cn”相关的内容。请尝试其他搜索词
抱歉,没有找到与“650.net.cn”相关的内容。
请尝试其他搜索词
抱歉,您输入的内容为空,请尝试其他搜索词
抱歉,您输入的内容为空。