Bulk Registration Data Access to Icann Sample Clauses

The "Bulk Registration Data Access to ICANN" clause requires registrars to provide ICANN with access to large sets of domain registration data. In practice, this means that registrars must periodically supply ICANN with up-to-date information about registered domain names, including registrant contact details and other relevant data, typically in a standardized electronic format. This clause ensures that ICANN can monitor compliance, maintain oversight of domain registrations, and address issues such as abuse or policy violations, thereby supporting transparency and accountability within the domain name system.
POPULAR SAMPLE Copied 2 times
Bulk Registration Data Access to Icann. Periodic Access to Thin Registration Data. In order to verify and ensure the operational stability of Registry Services as well as to facilitate compliance checks on accredited registrars, Registry Operator will provide ICANN on a weekly basis (the day to be designated by ICANN) with up-to-date Registration Data as specified below. Data will include data committed as of 00:00:00 UTC on the day previous to the one designated for retrieval by ICANN.
Bulk Registration Data Access to Icann. Periodic Access to Thin Registration Data. In order to verify and ensure the operational stability of Registry Services, analyze the operational stability of the DNS, and facilitate compliance checks on accredited registrars, Registry Operator will provide ICANN on a weekly basis (the day to be designated by ICANN) with up-to-date Registration Data as specified below. Data will include data committed as of 00:00:00 UTC on the day previous to the one designated for retrieval by ICANN. On an annual basis, ICANN will publish a summary of the research projects that utilized this data in the preceding year, along with a listing of any organizations the raw data was shared with to conduct the research.
Bulk Registration Data Access to Icann. The EBERO will provide bulk registration data access to ICANN as described in Section 3 of Specification 4 of the gTLD Registry Agreement, as modified by Appendix F to the Temporary Specification for gTLD Registration Data.
Bulk Registration Data Access to Icann. 5.1 Periodic Access to Thin Registration Data. In order to verify and ensure the operational stability of the Registry Services, analyze the operational stability of the DNS and facilitate compliance checks on accredited registrars, Registry Operator will provide ICANN on a daily basis with up-to-date registration data as specified in this Section 5.1. Data will include data committed as of 00:00:00 UTC on the previous day. On an annual basis, ICANN will publish a summary of the research projects that utilized this data in the preceding year, along with a listing of any organizations the raw data was shared with to conduct the research. 5.1.1 Contents. Registry Operator will provide the following data for all registered domain names: domain name, domain name repository object id (roid), Registrar ID (IANA ID), statuses, last updated date, creation date, expiration date, and name server names. For sponsoring registrars Registry Operator will provide: registrar name, registrar ID (IANA ID), hostname of registrar WHOIS server (this data element may be omitted after the WHOIS Services Sunset Date), and URL of registrar. Registry Operator shall not provide any additional data elements.
Bulk Registration Data Access to Icann 

Related to Bulk Registration Data Access to Icann

  • Exceptional Access to Thick Registration Data In case of a registrar failure, deaccreditation, court order, etc. that prompts the temporary or definitive transfer of its domain names to another registrar, at the request of ICANN, Registry Operator will provide ICANN with up-­‐to-­‐date data for the domain names of the losing registrar. The data will be provided in the format specified in Specification 2 for Data Escrow. The file will only contain data related to the domain names of the losing registrar. Registry Operator will provide the data as soon as commercially practicable, but in no event later than five (5) calendar days following ICANN’s request. Unless otherwise agreed by Registry Operator and ICANN, the file will be made available for download by ICANN in the same manner as the data specified in Section 3.1 of this Specification.

  • Registration Data Directory Services Until ICANN requires a different protocol, Registry Operator will operate a WHOIS service available via port 43 in accordance with ▇▇▇ ▇▇▇▇, and a web-­‐based Directory Service at <whois.nic.TLD> providing free public query-­‐based access to at least the following elements in the following format. ICANN reserves the right to specify alternative formats and protocols, and upon such specification, the Registry Operator will implement such alternative specification as soon as reasonably practicable. Registry Operator shall implement a new standard supporting access to domain name registration data (SAC 051) no later than one hundred thirty-­‐five (135) days after it is requested by ICANN if: 1) the IETF produces a standard (i.e., it is published, at least, as a Proposed Standard RFC as specified in RFC 2026); and 2) its implementation is commercially reasonable in the context of the overall operation of the registry. 1.1. The format of responses shall follow a semi-­‐free text format outline below, followed by a blank line and a legal disclaimer specifying the rights of Registry Operator, and of the user querying the database. 1.2. Each data object shall 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 key/value pairs with the same key shall 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. The fields specified below set forth the minimum output requirements. Registry Operator may output data fields in addition to those specified below, subject to approval by ICANN, which approval shall not be unreasonably withheld.

  • Effectiveness of Registration Statement; Compliance with Registration Requirements; No Stop Order During the period from and after the execution of this Agreement to and including the Closing Date or the Option Closing Date, as applicable: (i) the Company shall have filed the Prospectus with the Commission (including the information required by Rule 430A under the Securities Act) in the manner and within the time period required by Rule 424(b) under the Securities Act; or the Company shall have filed a post-effective amendment to the Registration Statement containing the information required by such Rule 430A, and such post-effective amendment shall have become effective; and (ii) no stop order suspending the effectiveness of the Registration Statement, or any post-effective amendment to the Registration Statement, shall be in effect and no proceedings for such purpose shall have been instituted or threatened by the Commission.