Registration Data Access Protocol Sample Clauses

Registration Data Access Protocol. Within ten calendar days following the date ICANN provides notice to registry operators under registry agreements that are the same or substantially similar to the “Base Registry Agreement” (defined as the registry agreement set forth at xxxxx://xxx.xxxxx.xxx/resources/pages/registries/registries-agreements-en, as may be amended from time to time) setting forth the effective date of an amendment (the “RDAP Global Amendment”) to such registry agreements implementing RDAP (the “Global Amendment Notice Date”), either party may send the other written notice to initiate good faith negotiations to revise the terms of Appendix 5B (and other terms of the Agreement solely as are necessary to incorporate the terms set forth in the RDAP Global Amendment), including adding new terms (as appropriate), related to RDDS (as defined in Appendix 5A), the RDAP Service (as defined in Appendix 5B) and/or sunsetting of the Whois Service (“RDAP Negotiation Request”). Upon such RDAP Negotiation Request, the parties agree to negotiate in good faith to revise Appendix 5B, provided (i) one or more terms set forth in the RDAP Global Amendment differ from those set forth in Appendix 5B or other provisions of the Agreement; (ii) the terms requested to be negotiated do not remove or lessen protections set forth in Section 1.7, Section 1.8 and Sections 2.3 through Section 2.9 of Appendix 5B, provided, however, the Parties agree that if there is a fundamental change to the definition of RDAP Service, as set forth in Section 1.3 of Appendix 5B (provided that a change to the RDAP Response Profile as referenced in Appendix 5B, Section 1.3 will not be considered a fundamental change for purposes of this subsection), then the Parties will extend the timeframe set forth in the definition of “Ramp- up Period” in Section 2.4 of Appendix 5B by 90 days, and extend the timeframe set forth in Section 2.3(i) of Appendix 5B by six months; and (iii) the terms are reasonably applicable to the TLD. In addition, except to the extent in the reasonable judgment of Registry Operator, the implementation of any such terms could jeopardize the security and stability of the TLD, the parties agree that the terms set forth in the RDAP Global Amendment related to RDDS (as defined in Appendix 5A), the RDAP Service (as defined in Appendix 5B) and/or sunsetting of the Whois Service shall be incorporated into Appendix 5B (and other terms of the Agreement solely as are necessary to incorporate such terms), in the form an...
AutoNDA by SimpleDocs

Related to Registration Data Access Protocol

  • 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.

  • 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.

  • Data Access Access to Contract and State Data The Contractor shall provide to the Client Agency access to any data, as defined in Conn. Gen Stat. Sec. 4e-1, concerning the Contract and the Client Agency that are in the possession or control of the Contractor upon demand and shall provide the data to the Client Agency in a format prescribed by the Client Agency and the State Auditors of Public Accounts at no additional cost.

  • Registration Data Directory Services Until ICANN requires a different protocol, Registry Operator will operate a WHOIS service available via port 43 in accordance with XXX 0000, 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.

  • System and Data Access Services a. System. Subject to the terms and conditions of this Addendum and solely for the purpose of providing access to Fund Data as set forth herein, State Street hereby agrees to provide the Fund, or certain third parties approved by State Street that serve as the Fund`s investment advisors, investment managers or fund accountants (the "Fund Accountants") or as the Fund`s independent auditors (the "Auditor"), with access to State Street`s Multicurrency HORIZONR Accounting System and the other information systems described in Attachment A (collectively, the "System") on a remote basis solely on the computer hardware, system software and telecommunication links described in Attachment B (the "Designated Configuration") or on any designated substitute or back-up equipment configuration consented to in writing by State Street, such consent not to be unreasonably withheld.

  • 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.

  • Publication of Registration Data Registry Operator shall provide public access to registration data in accordance with Specification 4 attached hereto (“Specification 4”).

  • Data Access Control Persons entitled to use data processing systems gain access only to the Personal Data that they have a right to access, and Personal Data must not be read, copied, modified or removed without authorization in the course of processing, use and storage.

  • Data Encryption Contractor must encrypt all State data at rest and in transit, in compliance with FIPS Publication 140-2 or applicable law, regulation or rule, whichever is a higher standard. All encryption keys must be unique to State data. Contractor will secure and protect all encryption keys to State data. Encryption keys to State data will only be accessed by Contractor as necessary for performance of this Contract.

  • Originating Switched Access Detail Usage Data A category 1101XX record as defined in the EMI Telcordia Practice BR-010-200- 010.

Draft better contracts in just 5 minutes Get the weekly Law Insider newsletter packed with expert videos, webinars, ebooks, and more!