We use cookies on our site to analyze traffic, enhance your experience, and provide you with tailored content.

For more information visit our privacy policy.

Extensible Provisioning Protocol Sample Clauses

Extensible Provisioning Protocol. Registry Operator shall maintain the Extensible Provisioning Protocol ("EPP") in conformance with the Proposed Standard and Informational RFCs 5730, 5731, 5732, 5734, 5910, and 3915 (and in the event Registry Operator accepts thick registration data RFC 5733) published by the Internet Engineering Task Force ("IETF") and/or any successor standards, versions, modifications or additions thereto as Registry Operator deems reasonably necessary. Registry Operator will support EPP in conformance with the aforementioned standards. If Registry Operator requires the use of functionality outside of EPP RFCs, Registry Operator must document EPP extensions using Internet-Draft format following the guidelines described in RFC 3735. Registry Operator is not required to submit documented EPP extensions to the IETF but to consider the recommendations on standardization described in section 2.1 of RFC 3735. Registry Operator will provide and update the relevant documentation of all the EPP objects and Extensions supported to ICANN prior to deployment. 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 Operator shall take action to remove orphan glue records (as defined at xxxx://xxx.xxxxx.xxx/en/committees/security/sac048.pdf) when provided with evidence in written form that such records are present in connection with malicious conduct.
Sample 1Sample 2Sample 3See All (7)
Extensible Provisioning Protocol. Registry Operator shall comply with relevant existing RFCs and those published in the future by the Internet Engineering Task Force (IETF) including all successor standards, modifications or additions thereto relating to the provisioning and management of domain names using the Extensible Provisioning Protocol (EPP) in conformance with RFCs 3915, 5910, 5730, 5731, 5732, 5733 and 5734. If Registry Operator requires the use of proprietary EPP functionality, Registry Operator must document EPP extensions in Internet- Draft format following the guidelines described in RFC 3735. Registry Operator will provide and update the relevant documentation of all the EPP Objects and Extensions supported to ICANN prior to deployment.
Sample 1Sample 2Sample 3See All (6)
Extensible Provisioning Protocol. Registry Operator intends to implement the Extensible Provisioning Protocol (“EPP”) in conformance with the Proposed Standard and Informational RFCs 3730, 3731, 3732, 3733, 3734, 3735, and 3915 published by the Internet Engineering Task Force (“IETF”) and/or any successor standards, versions, modifications or additions thereto as Registry Operator deems reasonably necessary. Subject to the Migration to Extensible Provisioning Protocol Plan described in Section 6 below, Registry Operator will support EPP in conformance with the aforementioned standards. Implementation of EPP is subject to Registry Operator reasonably determining that (i) the standard can be implemented in a way that minimizes disruption to customers; and (ii) the standard provides a solution for which the potential advantages are reasonably justifiable when weighed against the costs that Registry Operator and its registrar customers would incur in implementing the new standard.
Sample 1Sample 2Sample 3See All (5)
Extensible Provisioning Protocol. Registry Operator shall implement the Extensible Provisioning Protocol (“EPP”) in conformance with the Proposed Standard and Informational RFCs 3730, 3731, 3732, 3734, 3735, and 3915 published by the Internet Engineering Task Force (“IETF”) and/or any successor standards, versions, modifications or additions thereto as Registry Operator deems reasonably necessary.
Sample 1Sample 2See All (5)
Extensible Provisioning Protocol. Registry Operator shall maintain the Extensible Provisioning Protocol ("EPP") in conformance with the RFCs 5730, 5731, 5732, 5734, 5910 and 3915 published by the Internet Engineering Task Force ("IETF") and/or any successor standards, versions, modifications or additions thereto as Registry Operator deems reasonably necessary. Registry Operator will support EPP in conformance with the aforementioned standards. If Registry Operator requires the use of functionality outside of EPP RFCs, Registry Operator must document EPP extensions using Internet-Draft format following the guidelines described in RFC 3735. Registry Operator is not required to submit documented EPP extensions to the IETF but to consider the recommendations on standardization described in section 2.1. of XXX 0000. Registry Operator will provide and update the relevant documentation of all the EPP Objects and Extensions supported to ICANN prior to deployment. 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.
Sample 1
Extensible Provisioning Protocol. Subject to the Migration to Extensible Provisioning Protocol Plan described in Part 6 below, Registry Operator shall implementmaintain the Extensible Provisioning Protocol ("EPP") in conformance with the Proposed Standard and Informational RFCs 3730, 3731, 3732, 3734, 3735,RFCs 5730, 5731, 5732, 5734, 5910 and 3915 published by the Internet Engineering Task Force ("IETF") and/or any successor standards, versions, modifications or additions thereto as Registry Operator deems reasonably necessary. Subject to the Migration to Extensible Provisioning Protocol Plan described in Part 6 below, when Registry Operator implements EPP it will support EPP in conformance with the aforementioned standards. Implementation of EPP is subject to If Registry Operator reasonably determining that (i) the standard can be implemented in a way that minimizes disruption to customers; and (ii) the standard provides a solution for which the potential advantages are reasonably justifiable when weighed against the costs thatrequires the use of functionality outside of EPP RFCs, Registry Operator and its registrar customers would incur in implementingmust document EPP extensions using Internet-Draft format following the guidelines described in RFC 3735. Registry Operator is not required to submit documented EPP extensions to the IETF but to consider the recommendations on standardization described in section 2.1. of XXX 0000. Registry Operator will provide and update the relevant documentation of all the new standard. EPP Objects and Extensions supported to ICANN prior to deployment.
Sample 1
Extensible Provisioning Protocol. Registry Operator has implemented, and shall maintain support of, the Extensible Provisioning Protocol ("EPP") in conformance with the Proposed Standard and Informational RFCs 3730, 3731, 3732, 3734, 3735, and 3915shall comply with relevant existing RFCs and those published in the future by the Internet Engineering Task Force ("IETF") and/or anyincluding all successor standards, versions, modifications or additions thereto asrelating to the provisioning and management of domain names using the Extensible Provisioning Protocol (EPP) in conformance with RFCs 3915, 5910, 5730, 5731, 5732, 5733 and 5734. If Registry Operator deems reasonably necessary.requires the use of proprietary EPP functionality, Registry Operator must document EPP extensions in Internet-Draft format following the guidelines described in RFC 3735. Registry Operator will provide and update the relevant documentation of all the EPP Objects and Extensions supported to ICANN prior to deployment.
Sample 1
Extensible Provisioning Protocol. Registry Operator shall implement the Extensible Provisioning Protocol (“EPP”) in conformance with the Proposed Standard and Informational RFCs 3730, 3731, 3732, 3734, 3735, and 3915comply with relevant existing RFCs and those published in the future by the Internet Engineering Task Force (“IETF”) and/or anyincluding all successor standards, versions, modifications or additions thereto asrelating to the provisioning and management of domain names using the Extensible Provisioning Protocol (EPP) in conformance with RFCs 3915, 5910, 5730, 5731, 5732, 5733 and 5734. If Registry Operator deems reasonably necessary.requires the use of proprietary EPP functionality, Registry Operator must document EPP extensions in Internet-Draft format following the guidelines described in RFC 3735. Registry Operator will provide and update the relevant documentation of all the EPP Objects and Extensions supported to ICANN prior to deployment. II2. Supported initial and renewal registration periods a. Initial registrations of Registered Names (where available according to functional specifications and other requirements) may be made in the registry for terms of up to ten years. b. Renewal registrations of Registered Names (where available according to functional specifications and other requirements) may be made in the registry for terms not exceed a total of ten years. c. Upon change of sponsorship of the registration of a Registered Name from one registrar to another, according to Part A of the ICANN Policy on Transfer of Registrations between Registrars, the term of registration of the Registered Name shall be extended by one year, provided that the maximum term of the registration as of the effective date of the sponsorship change shall not exceed ten years. d. The change of sponsorship of registration of Registered Names from one registrar to another, according to Part B of the ICANN Policy on Transfer of Registrations between Registrars shall not result in the extension of the term of the registration and Registry Operator may assist in such change of sponsorship.
Sample 1
Extensible Provisioning Protocol. Subject to the Migration to Extensible Provisioning Protocol Plan described in Part 6 below, Registry Operator shall implement the Extensible Provisioning Protocol (“EPP”) in conformance with the Proposed Standard and Informational RFCs 3730, 3731, 3732, 3734, 3735, and 3915 published by the Internet Engineering Task Force (“IETF”) and/or any successor standards, versions, modifications or additions thereto as Registry Operator deems reasonably necessary. Subject to the Migration to Extensible Provisioning Protocol Plan described in Part 6 below, when Registry Operator implements EPP it will support EPP in conformance with the aforementioned standards. Implementation of EPP is subject to Registry Operator reasonably determining that (i) the standard can be implemented in a way that minimizes disruption to customers; and (ii) the standard provides a solution for which the potential advantages are reasonably justifiable when weighed against the costs that Registry Operator and its registrar customers would incur in implementing the new standard.
Sample 1

Related to Extensible Provisioning Protocol

  • Public Posting of Approved Users’ Research Use Statement The PI agrees that information about themselves and the approved research use will be posted publicly on the dbGaP website. The information includes the PI’s name and Requester, project name, Research Use Statement, and a Non-Technical Summary of the Research Use Statement. In addition, and if applicable, this information may include the Cloud Computing Use Statement and name of the CSP or PCS. Citations of publications resulting from the use of controlled-access datasets obtained through this DAR may also be posted on the dbGaP website.

  • Selection of Subcontractors, Procurement of Materials and Leasing of Equipment The contractor shall not discriminate on the grounds of race, color, religion, sex, national origin, age or disability in the selection and retention of subcontractors, including procurement of materials and leases of equipment. The contractor shall take all necessary and reasonable steps to ensure nondiscrimination in the administration of this contract. a. The contractor shall notify all potential subcontractors and suppliers and lessors of their EEO obligations under this contract. b. The contractor will use good faith efforts to ensure subcontractor compliance with their EEO obligations.

  • Detailed Description of Services / Statement of Work Describe fully the services that Contractor will provide, or add and attach Exhibit B to this Agreement.

  • System Upgrade Facilities and System Deliverability Upgrades Connecting Transmission Owner shall design, procure, construct, install, and own the System Upgrade Facilities and System Deliverability Upgrades described in Appendix A hereto. The responsibility of the Developer for costs related to System Upgrade Facilities and System Deliverability Upgrades shall be determined in accordance with the provisions of Attachment S to the ISO OATT.

  • Proposed Policies and Procedures Regarding New Online Content and Functionality By October 31, 2017, the School will submit to OCR for its review and approval proposed policies and procedures (“the Plan for New Content”) to ensure that all new, newly-added, or modified online content and functionality will be accessible to people with disabilities as measured by conformance to the Benchmarks for Measuring Accessibility set forth above, except where doing so would impose a fundamental alteration or undue burden. a) When fundamental alteration or undue burden defenses apply, the Plan for New Content will require the School to provide equally effective alternative access. The Plan for New Content will require the School, in providing equally effective alternate access, to take any actions that do not result in a fundamental alteration or undue financial and administrative burdens, but nevertheless ensure that, to the maximum extent possible, individuals with disabilities receive the same benefits or services as their nondisabled peers. To provide equally effective alternate access, alternates are not required to produce the identical result or level of achievement for persons with and without disabilities, but must afford persons with disabilities equal opportunity to obtain the same result, to gain the same benefit, or to reach the same level of achievement, in the most integrated setting appropriate to the person’s needs. b) The Plan for New Content must include sufficient quality assurance procedures, backed by adequate personnel and financial resources, for full implementation. This provision also applies to the School’s online content and functionality developed by, maintained by, or offered through a third-party vendor or by using open sources. c) Within thirty (30) days of receiving OCR’s approval of the Plan for New Content, the School will officially adopt, and fully implement the amended policies and procedures.

  • SERVICE MONITORING, ANALYSES AND ORACLE SOFTWARE 11.1 We continuously monitor the Services to facilitate Oracle’s operation of the Services; to help resolve Your service requests; to detect and address threats to the functionality, security, integrity, and availability of the Services as well as any content, data, or applications in the Services; and to detect and address illegal acts or violations of the Acceptable Use Policy. Oracle monitoring tools do not collect or store any of Your Content residing in the Services, except as needed for such purposes. Oracle does not monitor, and does not address issues with, non-Oracle software provided by You or any of Your Users that is stored in, or run on or through, the Services. Information collected by Oracle monitoring tools (excluding Your Content) may also be used to assist in managing Oracle’s product and service portfolio, to help Oracle address deficiencies in its product and service offerings, and for license management purposes. 11.2 We may (i) compile statistical and other information related to the performance, operation and use of the Services, and (ii) use data from the Services in aggregated form for security and operations management, to create statistical analyses, and for research and development purposes (clauses i and ii are collectively referred to as “Service Analyses”). We may make Service Analyses publicly available; however, Service Analyses will not incorporate Your Content, Personal Data or Confidential Information in a form that could serve to identify You or any individual. We retain all intellectual property rights in Service Analyses. 11.3 We may provide You with the ability to obtain certain Oracle Software (as defined below) for use with the Services. If we provide Oracle Software to You and do not specify separate terms for such software, then such Oracle Software is provided as part of the Services and You have the non-exclusive, worldwide, limited right to use such Oracle Software, subject to the terms of this Agreement and Your order (except for separately licensed elements of the Oracle Software, which separately licensed elements are governed by the applicable separate terms), solely to facilitate Your use of the Services. You may allow Your Users to use the Oracle Software for this purpose, and You are responsible for their compliance with the license terms. Your right to use any Oracle Software will terminate upon the earlier of our notice (by web posting or otherwise) or the end of the Services associated with the Oracle Software. Notwithstanding the foregoing, if Oracle Software is licensed to You under separate terms, then Your use of such software is governed by the separate terms. Your right to use any part of the Oracle Software that is licensed under the separate terms is not restricted in any way by this Agreement.

  • Statement of Work The Statement of Work to which Grantee is bound is incorporated into and made a part of this Grant Agreement for all purposes and included as Attachment A.

  • Data Deletion Google will delete Customer Data in accordance with Section 6 (Data Deletion) of the Data Processing Amendment.

  • Access to Review Materials The Servicer will give the Asset Representations Reviewer access to the Review Materials for all of the Subject Receivables within sixty (60) calendar days after receipt of the review notice in one or more of the following ways in the Servicer’s reasonable discretion: (i) by electronic posting of Review Materials to a password-protected website to which the Asset Representations Reviewer has access, (ii) by providing originals or photocopies of documents relating to the Subject Receivables at one of the properties of the Servicer or (iii) in another manner agreed by the Servicer and the Asset Representations Reviewer. The Servicer may redact or remove PII from the Review Materials so long as all information in the Review Materials necessary for the Asset Representations Reviewer to complete the Asset Review remains intact and unchanged.

  • Review Protocol A narrative description of how the Claims Review was conducted and what was evaluated.

Most Referenced Clauses

Most Referenced Definitions