Registry Registrar Protocol Clause Samples

The Registry Registrar Protocol clause defines the rules and procedures governing the interaction between a domain name registry and its accredited registrars. It typically outlines the technical and operational requirements for registrars to connect to the registry system, such as authentication methods, data formats, and transaction processes for domain registrations, renewals, and updates. By establishing a standardized protocol, this clause ensures secure, efficient, and consistent communication between parties, thereby reducing errors and facilitating smooth domain management operations.
Registry Registrar Protocol. Subject to the Migration to Extensible Provisioning Protocol Plan described in Section 6 below, Registry Operator will support Registry Registrar Protocol (“RRP”) Version 2.1.2 in accordance with the patch, update, and upgrade policy below, or any successor standards, versions, upgrades, modifications or additions thereto as it deems reasonably necessary. Registry Operator will provide the current version of the protocol for download on its website by registrars.
Registry Registrar Protocol. Subject to the Migration to Extensible Provisioning Protocol Plan described in Part 6 below, Registry Operator will support Registry Registrar Protocol ("RRP") Version 2.1.2 in accordance with the patch, update, and upgrade policy below, or any successor standards, versions, upgrades, modifications or additions thereto as it deems reasonably necessary. Registry Operator will provide the current version of the protocol for download on its website by registrars.Registry Operator shall be able to accept IPv6 addresses as glue records in its Registry System and publish them in the DNS. Registry Operator shall offer public IPv6 transport for its Shared Registration System (SRS) to any Registrar, no later than six months after receiving the first request in writing from a gTLD accredited Registrar willing to operate the SRS over IPv6.
Registry Registrar Protocol. Subject to the Migration to Extensible Provisioning Protocol Plan described in Part 6 below, Registry Operator will support Registry Registrar Protocol (“RRP”)

Related to Registry Registrar Protocol

  • Registrar Data 1.6.1 Query format: whois “registrar Example Registrar, Inc.” 1.6.2 Response format: Registrar Name: Example Registrar, Inc. Street: ▇▇▇▇ ▇▇▇▇▇▇▇▇▇ ▇▇▇ City: Marina del Rey State/Province: CA Postal Code: 90292 Country: US Phone Number: +1.▇▇▇▇▇▇▇▇▇▇ Fax Number: +1.3105551213 Email: ▇▇▇▇▇▇▇▇▇@▇▇▇▇▇▇▇.▇▇▇ WHOIS Server: whois.example-­‐registrar.tld Referral URL: ▇▇▇▇://▇▇▇.▇▇▇▇▇▇▇-­‐registrar.tld Admin Contact: ▇▇▇ Registrar Phone Number: +1.3105551213 Fax Number: +1.3105551213 Email: joeregistrar@example-­‐registrar.tld Admin Contact: ▇▇▇▇ Registrar Phone Number: +1.3105551214 Fax Number: +1.3105551213 Email: janeregistrar@example-­‐registrar.tld Technical Contact: ▇▇▇▇ Geek Phone Number: +1.3105551215 Fax Number: +1.3105551216 Email: johngeek@example-­‐registrar.tld >>> Last update of WHOIS database: 2009-­‐05-­‐29T20:15:00Z <<<

  • NERC Registration The NTO shall register or enter into agreement with a NERC registered entity for all required NERC functions applicable to the NTO, that may include, without limitation, those functions designated by NERC to be: “Transmission Owner” and “Transmission Planner” and “Transmission Operator.” The Parties agree to negotiate in good faith the compliance obligations for the NERC functions applicable to, and to be performed by, each Party with respect to the NTO’s facilities. Notwithstanding the foregoing, the ISO shall register for the “Transmission Operator” function for all NTO Transmission Facilities under ISO Operational Control identified in Appendix A-1 of this Agreement.

  • USER REGISTRATION You may be required to register with the Site. You agree to keep your password confidential and will be responsible for all use of your account and password. We reserve the right to remove, reclaim, or change a username you select if we determine, in our sole discretion, that such username is inappropriate, obscene, or otherwise objectionable.

  • Per-­‐Registrar Transactions Report This report shall be compiled in a comma separated-­‐value formatted file as specified in RFC 4180. The file shall be named “gTLD-­‐transactions-­‐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 per registrar: Field # Field name Description 01 registrar-­‐name Registrar’s full corporate name as registered with IANA 02 iana-­‐id For cases where the registry operator acts as registrar (i.e., without the use of an ICANN accredited registrar) 9999 should be used, otherwise the sponsoring Registrar IANA id should be used as specified in ▇▇▇▇://▇▇▇.▇▇▇▇.▇▇▇/assignments/registrar-­‐ids 03 total-­‐domains total domain names under sponsorship in any EPP status but pendingCreate that have not been purged 04 total-­‐nameservers total name servers (either host objects or name server hosts as domain name attributes) associated with domain names registered for the TLD in any EPP status but pendingCreate that have not been purged 05 net-­‐adds-­‐1-­‐yr number of domains successfully registered (i.e., not in EPP pendingCreate status) with an initial term of one (1) year (and not deleted within the add grace period). A transaction must be reported in the month the add grace period ends.

  • ICANN testing registrar Registry Operator agrees that ICANN will have a testing registrar used for purposes of measuring the SLRs described above. Registry Operator agrees to not provide any differentiated treatment for the testing registrar other than no billing of the transactions. ICANN shall not use the registrar for registering domain names (or other registry objects) for itself or others, except for the purposes of verifying contractual compliance with the conditions described in this Agreement. 1. Registry Operator will use only ICANN accredited registrars that are party to the Registrar Accreditation Agreement approved by the ICANN Board of Directors on 27 June 2013 in registering domain names. A list of such registrars shall be maintained by ICANN on ICANN’s website. 2. (Intentionally omitted. Registry Operator has not included commitments, statements of intent or business plans provided for in its application to ICANN for the TLD.) 3. Registry Operator agrees to perform the following specific public interest commitments, which commitments shall be enforceable by ICANN and through the Public Interest Commitment Dispute Resolution Process established by ICANN (posted at ▇▇▇▇://▇▇▇.▇▇▇▇▇.▇▇▇/en/resources/registries/picdrp), which may be revised in immaterial respects by ICANN from time to time (the “PICDRP”). Registry Operator shall comply with the PICDRP. Registry Operator agrees to implement and adhere to any remedies ICANN imposes (which may include any reasonable remedy, including for the avoidance of doubt, the termination of the Registry Agreement pursuant to Section 4.3(e) of the Agreement) following a determination by any PICDRP panel and to be bound by any such determination. a. Registry Operator will include a provision in its Registry-­‐Registrar Agreement that requires Registrars to include in their Registration Agreements a provision prohibiting Registered Name Holders from distributing malware, abusively operating botnets, phishing, piracy, trademark or copyright infringement, fraudulent or deceptive practices, counterfeiting or otherwise engaging in activity contrary to applicable law, and providing (consistent with applicable law and any related procedures) consequences for such activities including suspension of the domain name. b. Registry Operator will periodically conduct a technical analysis to assess whether domains in the TLD are being used to perpetrate security threats, such as pharming, phishing, malware, and botnets. Registry Operator will maintain statistical reports on the number of security threats identified and the actions taken as a result of the periodic security checks. Registry Operator will maintain these reports for the term of the Agreement unless a shorter period is required by law or approved by ICANN, and will provide them to ICANN upon request. c. Registry Operator will operate the TLD in a transparent manner consistent with general principles of openness and non-­‐discrimination by establishing, publishing and adhering to clear registration policies. d. Registry Operator of a “Generic String” TLD may not impose eligibility criteria for registering names in the TLD that limit registrations exclusively to a single person or entity and/or that person’s or entity’s “Affiliates” (as defined in Section 2.9(c) of the Registry Agreement). “Generic String” means a string consisting of a word or term that denominates or describes a general class of goods, services, groups, organizations or things, as opposed to distinguishing a specific brand of goods, services, groups, organizations or things from those of others.