Shared Registry System Sample Clauses

Shared Registry System. 8.1. The Registry hereby grants Registrar a personal, non-transferable, non-sub- licensable and non-exclusive right to use the Shared Registry System, and the WHOIS Service for rendering the Domain Name Registration Services and related services to its Customers. 8.2. Registrar shall connect to the Shared Registry System using (i) the IP addresses notified by the Registrar to the Registry from time to time, and (ii) the SSL certificate authentication methods (handshake) notified by the Registry to the Registrar from time to time. Parties shall exclusively use the EPP protocol for any transactions to do with the domain name registration life cycle for each particular TLD. 8.3. The Registry shall have the right to temporarily suspend or restrict the Registrar’s access to the Shared Registry System, in whole or in part, with or without prior notice to the Registrar, in case such suspension is necessary in order to ensure and/or improve the stability of the Shared Registry System and/or the operation or functioning of the TLD(s), without the Registrar being entitled to any damages as a result thereof. 8.4. Technical details regarding the operation of the Shared Registry System and the WHOIS Service are found on the Registry website, which contain sufficient technical and operational specifications and requirements to enable Registrar to connect to the Shared Registry System. The Registry shall provide the Registrar with updates thereof as soon as they become available.
AutoNDA by SimpleDocs
Shared Registry System. 8.1. The Registry Operator hereby grants Registrar a personal, non-transferable, non-sub- licensable and non-exclusive right to use the Shared Registry System, and the WHOIS Service for rendering the Domain Name Registration Services and related services to its Customers. 8.2. Registrar shall connect to the Shared Registry System using (i) the IP addresses notified by the Registrar to the Registry Operator from time to time, and (ii) the SSL certificate authentication methods (handshake) notified by the Registry Operator to the Registrar from time to time. Parties shall exclusively use the EPP protocol for any transactions to do with the domain name registration life cycle for each particular TLD, whether directly through an EPP interface or indirectly through a web based Registrar panel. 8.3. The Registry Operator shall have the right to temporarily suspend or restrict the Registrar’s access to the Shared Registry System, in whole or in part, with or without prior notice to the Registrar, in case such suspension is necessary in order to ensure and/or improve the stability of the Shared Registry System and/or the operation or functioning of the TLD(s), without the Registrar being entitled to any damages as a result thereof. 8.4. Technical details regarding the operation of the Shared Registry System and the WHOIS Service will be made available on the Registry Website and will contain sufficient technical and operational specifications and requirements to enable Registrar to connect to the Shared Registry System. The Registry Operator shall provide the Registrar with updates thereof as soon as they become available.

Related to Shared Registry System

  • DTC DIRECT REGISTRATION SYSTEM AND PROFILE MODIFICATION SYSTEM (a) Notwithstanding the provisions of Section 2.04, the parties acknowledge that the Direct Registration System (“DRS”) and Profile Modification System (“Profile”) shall apply to uncertificated American Depositary Shares upon acceptance thereof to DRS by DTC. DRS is the system administered by DTC pursuant to which the Depositary may register the ownership of uncertificated American Depositary Shares, which ownership shall be evidenced by periodic statements issued by the Depositary to the Owners entitled thereto. Profile is a required feature of DRS which allows a DTC participant, claiming to act on behalf of an Owner of American Depositary Shares, to direct the Depositary to register a transfer of those American Depositary Shares to DTC or its nominee and to deliver those American Depositary Shares to the DTC account of that DTC participant without receipt by the Depositary of prior authorization from the Owner to register such transfer. (b) In connection with and in accordance with the arrangements and procedures relating to DRS/Profile, the parties understand that the Depositary will not verify, determine or otherwise ascertain that the DTC participant which is claiming to be acting on behalf of an Owner in requesting a registration of transfer and delivery as described in subsection (a) has the actual authority to act on behalf of the Owner (notwithstanding any requirements under the Uniform Commercial Code). For the avoidance of doubt, the provisions of Sections 5.03 and 5.08 shall apply to the matters arising from the use of the DRS. The parties agree that the Depositary’s reliance on and compliance with instructions received by the Depositary through the DRS/Profile System and in accordance with this Deposit Agreement shall not constitute negligence or bad faith on the part of the Depositary.

  • TLD Nameservers ICANN will use commercially reasonable efforts to ensure that any changes to the TLD nameserver designations submitted to ICANN by Registry Operator (in a format and with required technical elements specified by ICANN at xxxx://xxx.xxxx.xxx/domains/root/ will be implemented by ICANN within seven (7) calendar days or as promptly as feasible following technical verifications.

  • PFPC System PFPC shall retain title to and ownership of any and all data bases, computer programs, screen formats, report formats, interactive design techniques, derivative works, inventions, discoveries, patentable or copyrightable matters, concepts, expertise, patents, copyrights, trade secrets, and other related legal rights utilized by PFPC in connection with the services provided by PFPC to the Fund.

  • Registry Services “Registry Services” are, for purposes of the Agreement, defined as the following: (a) those services that are operations of the registry critical to the following tasks: the receipt of data from registrars concerning registrations of domain names and name servers; provision to registrars of status information relating to the zone servers for the TLD; dissemination of TLD zone files; operation of the registry DNS servers; and dissemination of contact and other information concerning domain name server registrations in the TLD as required by this Agreement; (b) other products or services that the Registry Operator is required to provide because of the establishment of a Consensus Policy as defined in Specification 1; (c) any other products or services that only a registry operator is capable of providing, by reason of its designation as the registry operator; and (d) material changes to any Registry Service within the scope of (a), (b) or (c) above.

  • Registry Functions Activity Report This report shall be compiled in a comma separated-value formatted file as specified in RFC 4180. The file shall be named “gTLD-activity-yyyymm.csv”, where “gTLD” is the gTLD name; in case of an IDN-TLD, the A-label shall be used; “yyyymm” is the year and month being reported. The file shall contain the following fields: 01 operational-registrars number of operational registrars at the end of the reporting period 02 ramp-up-registrars number of registrars that have received a password for access to OT&E at the end of the reporting period 03 pre-ramp-up-registrars number of registrars that have requested access, but have not yet entered the ramp-up period at the end of the reporting period 06 web-whois-queries number of Web-based Whois queries responded during the reporting period, not including searchable Whois 09 dns-udp-queries-responded number of DNS queries received over UDP transport that were responded during the reporting period 10 dns-tcp-queries-received number of DNS queries received over TCP transport during the reporting period 11 dns-tcp-queries-responded number of DNS queries received over TCP transport that were responded during the reporting period 12 srs-dom-check number of SRS (EPP and any other interface) domain name “check” requests responded during the reporting period 13 srs-dom-create number of SRS (EPP and any other interface) domain name “create” requests responded during the reporting period 14 srs-dom-delete number of SRS (EPP and any other interface) domain name “delete” requests responded during the reporting period 15 srs-dom-info number of SRS (EPP and any other interface) domain name “info” requests responded during the reporting period 16 srs-dom-renew number of SRS (EPP and any other interface) domain name “renew” requests responded during the reporting period 17 srs-dom-rgp-restore-report number of SRS (EPP and any other interface) domain name RGP “restore” requests delivering a restore report responded during the reporting period 18 srs-dom-rgp-restore-request number of SRS (EPP and any other interface) domain name RGP “restore” requests responded during the reporting period 19 srs-dom-transfer-approve number of SRS (EPP and any other interface) domain name “transfer” requests to approve transfers responded during the reporting period 20 srs-dom-transfer-cancel number of SRS (EPP and any other interface) domain name “transfer” requests to cancel transfers responded during the reporting period 21 srs-dom-transfer-query number of SRS (EPP and any other interface) domain name “transfer” requests to query about a transfer responded during the reporting period 22 srs-dom-transfer-reject number of SRS (EPP and any other interface) domain name “transfer” requests to reject transfers responded during the reporting period 23 srs-dom-transfer-request number of SRS (EPP and any other interface) domain name “transfer” requests to request transfers responded during the reporting period 24 srs-dom-update number of SRS (EPP and any other interface) domain name “update” requests (not including RGP restore requests) responded during the reporting period 25 srs-host-check number of SRS (EPP and any other interface) host “check” requests responded during the reporting period 26 srs-host-create number of SRS (EPP and any other interface) host “create” requests responded during the reporting period 27 srs-host-delete number of SRS (EPP and any other interface) host “delete” requests responded during the reporting period 28 srs-host-info number of SRS (EPP and any other interface) host “info” requests responded during the reporting period 29 srs-host-update number of SRS (EPP and any other interface) host “update” requests responded during the reporting period 30 srs-cont-check number of SRS (EPP and any other interface) contact “check” requests responded during the reporting period 32 srs-cont-delete number of SRS (EPP and any other interface) contact “delete” requests responded during the reporting period 33 srs-cont-info number of SRS (EPP and any other interface) contact “info” requests responded during the reporting period 34 srs-cont-transfer-approve number of SRS (EPP and any other interface) contact “transfer” requests to approve transfers responded during the reporting period 35 srs-cont-transfer-cancel number of SRS (EPP and any other interface) contact “transfer” requests to cancel transfers responded during the reporting period 36 srs-cont-transfer-query number of SRS (EPP and any other interface) contact “transfer” requests to query about a transfer responded during the reporting period 37 srs-cont-transfer-reject number of SRS (EPP and any other interface) contact “transfer” requests to reject transfers responded during the reporting period 38 srs-cont-transfer-request number of SRS (EPP and any other interface) contact “transfer” requests to request transfers responded during the reporting period 39 srs-cont-update number of SRS (EPP and any other interface) contact “update” requests responded during the reporting period The first line shall include the field names exactly as described in the table above as a “header line” as described in section 2 of RFC 4180. No other lines besides the ones described above shall be included. Line breaks shall be <U+000D, U+000A> as described in RFC 4180. For gTLDs that are part of a single-instance Shared Registry System, the Registry Functions Activity Report may include the total contact or host transactions for all the gTLDs in the system. REGISTRATION DATA PUBLICATION SERVICES

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

  • Posting licensed content on any Website The following terms and conditions apply as follows: Licensing material from an Elsevier journal: All content posted to the web site must maintain the copyright information line on the bottom of each image; A hyper-text must be included to the Homepage of the journal from which you are licensing at xxxx://xxx.xxxxxxxxxxxxx.xxx/science/journal/xxxxx or the Elsevier homepage for books at xxxx://xxx.xxxxxxxx.xxx; Central Storage: This license does not include permission for a scanned version of the material to be stored in a central repository such as that provided by Heron/XanEdu. Licensing material from an Elsevier book: A hyper-text link must be included to the Elsevier homepage at xxxx://xxx.xxxxxxxx.xxx . All content posted to the web site must maintain the copyright information line on the bottom of each image.

  • Statewide HUB Program Statewide Procurement Division Note: In order for State agencies and institutions of higher education (universities) to be credited for utilizing this business as a HUB, they must award payment under the Certificate/VID Number identified above. Agencies, universities and prime contractors are encouraged to verify the company’s HUB certification prior to issuing a notice of award by accessing the Internet (xxxxx://xxxxx.xxx.xxxxx.xx.xx/tpasscmblsearch/index.jsp) or by contacting

  • Registry Lock Registry Operator may offer the Registry Lock service, which is a registry service that allows an authorized representative from the sponsoring Registrar, request the activation or deactivation of any of the following EPP statuses: serverUpdateProhibited, serverDeleteProhibited and⁄or serverTransferProhibited.

  • Unbundled Sub-Loop Feeder 2.8.4.1 Unbundled Sub-Loop Feeder (USLF) provides connectivity between BellSouth's central office and cross-box (or other access point) that serves an end user location. 2.8.4.2 USLF utilized for voice traffic can be configured as 2-wire voice (USLF-2W/V) or 4-wire voice (USLF-4W/V). 2.8.4.3 USLF utilized for digital traffic can be configured as 2-wire ISDN (USLF-2W/I); 2-wire Copper (USLF-2W/C); 4-wire Copper (USLF-4W/C); 4-wire DS0 level loop (USLF-4W/D0); or 4-wire DS1 and ISDN (USLF-4W/DI). 2.8.4.4 USLF will provide access to both the equipment and the features in the BellSouth central office and BellSouth cross box necessary to provide a 2W or 4W communications pathway from the BellSouth central office to the BellSouth cross- box. This element will allow for the connection of Lightyear’s loop distribution elements onto BellSouth's feeder system.

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