Deficiencies in Interconnection Request Sample Clauses

Deficiencies in Interconnection Request. An Interconnection Request will not be considered to be a valid request until all items in Section 3.3.1 have been received by Transmission Provider. If an Interconnection Request fails to meet the requirements set forth in Section 3.3.1, Transmission Provider shall notify Interconnection Customer within five (5) Business Days of receipt of the initial Interconnection Request of the reasons for such failure and that the Interconnection Request does not constitute a valid request. Interconnection Customer shall provide Transmission Provider the additional requested information needed to constitute a valid request within ten (10) Business Days after receipt of such notice. Failure by Interconnection Customer to comply with this Section 3.3.3 shall be treated in accordance with Section 3.6.
Sample 1Sample 2Sample 3See All (27)
AutoNDA by SimpleDocs
Deficiencies in Interconnection Request. An Interconnection Request will not be considered to be a valid request until all items in Section 30.3.3.1 have been received by the ISO and the applicable solicitation window has closed for any Interconnection Request that is submitted for a proposed project subject to the ISO’s competitive selection process in the ISO’s Comprehensive System Planning Process in Attachment Y to the ISO OATT. If an Interconnection Request fails to meet the requirements set forth in Section 30.3.3.1, the ISO shall notify the Developer and Connecting Transmission Owner within ten (10) Business Days of receipt of the initial Interconnection Request of the reasons for such failure and that the Interconnection Request does not constitute a valid request. However, for any Interconnection Request that is submitted for a proposed project subject to the ISO’s competitive selection process in the ISO’s Comprehensive System Planning Process in Attachment Y to the ISO OATT and that fails to meet the requirements set forth in Section 22.4.2.1, the ISO shall notify the Developer and the Connecting Transmission Owner(s) no later than ten (10) Business Days following the close of the applicable solicitation window. The Developer shall provide the ISO the additional requested information needed to constitute a valid request within ten (10) Business Days after receipt of such notice. The ISO shall promptly forward such information to the Connecting Transmission Owner; provided, however, for any Interconnection Request that is submitted for a proposed project subject to the ISO’s competitive selection process in the ISO’s Comprehensive System Planning Process in Attachment Y of the ISO OATT, such information will not be forwarded to the Connecting Transmission Owner(s) until the close of the applicable solicitation window. Failure by Developer to comply with this Section 30.3.3.3 shall be treated in accordance with Section 30.3.6.
Sample 1Sample 2Sample 3See All (4)
Deficiencies in Interconnection Request. Interconnection Customer shall provide Transmission Provider all items in Section 3.4.1. An Interconnection Request will not be considered to be a valid request until all items in Section 3.4.1 have been received by Transmission Provider. If an Interconnection Request fails to meet the requirements set forth in Section 3.4.1, Transmission Provider shall notify Interconnection Customer within twenty (20) Business Days of receipt of the initial Interconnection Request of the reasons for such failure and that the Interconnection Request does not constitute a valid request and is deemed withdrawn.
Sample 1Sample 2
Deficiencies in Interconnection Request. An Interconnection Request will not be considered to be a valid request until all items in Section 3.4.1 have been received by Transmission Provider. If an Interconnection Request fails to meet the requirements set forth in Section 3.4.1, Transmission Provider shall notify Interconnection Customer within five (5) Business Days of receipt of the initial Interconnection Request of the reasons for such failure and that the Interconnection Request does not constitute a valid request. Interconnection Customer shall provide Transmission Provider the additional requested information needed to constitute a valid request within ten (10) Business Days after receipt of such notice. Failure by Interconnection Customer to comply with this Section 3.3.3 shall be treated in accordance with Section 3.7. A Surplus Interconnection Service request may be made by the existing Interconnection Customer or one of its affiliates. Surplus Interconnection Service requests also may be made by a non-affiliate. Transmission Provider shall provide a process for Surplus Interconnection Service. Studies for Surplus Interconnection Service shall consist of reactive power, short circuit/fault duty, stability analyses, and any other appropriate studies. Steady-state (thermal/voltage) analyses may be performed as necessary to ensure that all required reliability conditions are studied. If the Surplus Interconnection Service was not studied under off-peak conditions, off-peak steady state analyses shall be performed to the required level necessary to demonstrate reliable operation of the Surplus Interconnection Service. If the original System Impact Study is not available for the Surplus Interconnection Service, both off-peak and peak analysis may need to be performed for the existing Generating Facility associated with the request for Surplus Interconnection Service. The reactive power, short circuit/fault duty, stability, and steady-state analyses for Surplus Interconnection Service will identify any additional Interconnection Facilities and/or Network Upgrades necessary
Sample 1
Deficiencies in Interconnection Request. ‌ An Interconnection Request will not be considered to be a valid request until all items in Section 3.3.1 have been received by Transmission Provider and Transmission Provider has determined that such items meet the requisites for a valid request. If an Interconnection Request fails to meet the requirements set forth in Section 3.3.1, Transmission Provider shall notify Interconnection Customer within ten (10) Business Days of receipt of the initial Interconnection Request of the reasons for such failure and that the Interconnection Request does not constitute a valid request. Interconnection Customer shall provide Transmission Provider the additional requested information and/or items needed to constitute a valid request within ten (10) Business Days after receipt of such notice. Failure by Interconnection Customer to comply with this Section 3.3.3 shall be treated as a withdrawal in accordance with Section 3.6.
Sample 1
Deficiencies in Interconnection Request. 13 - 3.3.4 Scoping Meeting .................................................................... - 13 - 3.5 Coordination with Affected Systems .................................................. - 14 - 3.6 Withdrawal ........................................................................................... - 14 -
Sample 1

Related to Deficiencies in Interconnection Request

  • Interconnection Request This Section 3 shall not apply to any proposed modifications by Interconnection Customer to its facilities for which Interconnection Customer must make an Interconnection Request under the Tariff. In such circumstances, the Interconnection Customer and Transmission Provider shall follow the requirements of Subpart A of Part IV of the Tariff.

  • Network Interconnection Architecture Each Party will plan, design, construct and maintain the facilities within their respective systems as are necessary and proper for the provision of traffic covered by this Agreement. These facilities include but are not limited to, a sufficient number of trunks to the point of interconnection with the tandem company, and sufficient interoffice and interexchange facilities and trunks between its own central offices to adequately handle traffic between all central offices within the service areas at P.01 grade of service or better. The provisioning and engineering of such services and facilities will comply with generally accepted industry methods and practices, and will observe the rules and regulations of the lawfully established tariffs applicable to the services provided.

  • Project Delivery Order Procedures The TIPS Member having approved and signed an interlocal agreement, or other TIPS Membership document, may make a request of the awarded Vendor under this Agreement when the TIPS Member desires goods or services awarded to the Vendor. Notification may occur via phone, the web, courier, email, fax, or in person. Upon notification of a pending request, the awarded Vendor shall acknowledge the TIPS Member’s request as soon as possible, but must make contact with the TIPS Member within two working days. Status of TIPS Members as Related to This Agreement TIPS Members stand in the place of TIPS as related to this agreement and have the same access to the proposal information and all related documents. TIPS Members have all the same rights under the awarded Agreement as TIPS.

  • One-Way Interconnection Trunks 2.3.1 Where the Parties use One-Way Interconnection Trunks for the delivery of traffic from CBB to Verizon, CBB, at CBB’s own expense, shall:

  • Loop Provisioning Involving Integrated Digital Loop Carriers 2.6.1 Where EveryCall has requested an Unbundled Loop and BellSouth uses Integrated Digital Loop Carrier (IDLC) systems to provide the local service to the end user and BellSouth has a suitable alternate facility available, BellSouth will make such alternative facilities available to EveryCall. If a suitable alternative facility is not available, then to the extent it is technically feasible, BellSouth will implement one of the following alternative arrangements for EveryCall (e.g. hairpinning):

  • Project Delivery Order Procedures The TIPS Member having approved and signed an interlocal agreement, or other TIPS Membership document, may make a request of the awarded vendor under this Agreement when the TIPS Member has services that need to be undertaken. Notification may occur via phone, the web, email, fax, or in person. Upon notification of a pending request, the awarded vendor shall make contact with the TIPS Member as soon as possible, but must make contact with the TIPS Member within two working days. Scheduling of Projects Scheduling of projects (if applicable) may be accomplished when the TIPS Member issues a Purchase Order and/or an Agreement or Contract that will serve as “the notice to proceed” as agreed by the Vendor and the TIPS Member. The period for the delivery order will include the mobilization, materials purchase, installation and delivery, design, weather, and site cleanup and inspection. No additional claims may be made for delays as a result of these items. When the tasks have been completed the awarded vendor shall notify the client and have the TIPS Member or a designated representative of the TIPS Member inspect the work for acceptance under the scope and terms in the Purchase Order and/or Agreement or Contract. The TIPS Member will issue in writing any corrective actions that are required. Upon completion of these items, the TIPS Member will issue a completion notice and final payment will be issued per the contractual requirements of the project with the TIPS Member. Any Construction contract prepared by the TIPS Member’s Legal Counsel may alter the terms of this subsection, “Scheduling of Projects”.

  • Escrow Format Specification 3.1. Deposit’s Format. Registry objects, such as domains, contacts, name servers, registrars, etc. will be compiled into a file constructed as described in draft-xxxxx-xxxxxxx-registry-data-escrow, see Part A, Section 9, reference 1 of this Specification and draft-xxxxx-xxxxxxx-dnrd-objects-mapping, see Part A, Section 9, reference 2 of this Specification (collectively, the “DNDE Specification”). The DNDE Specification describes some elements as optional; Registry Operator will include those elements in the Deposits if they are available. If not already an RFC, Registry Operator will use the most recent draft version of the DNDE Specification available at the Effective Date. Registry Operator may at its election use newer versions of the DNDE Specification after the Effective Date. Once the DNDE Specification is published as an RFC, Registry Operator will implement that version of the DNDE Specification, no later than one hundred eighty (180) calendar days after. UTF-8 character encoding will be used.

  • Software Use Case Red Hat Enterprise Linux Developer Suite Subscription Services for Red Hat Enterprise Linux Developer Suite are available for Development Purposes only.

  • Two-Way Interconnection Trunks 2.4.1 Where the Parties have agreed to use Two-Way Interconnection Trunks for the exchange of traffic between Verizon and ICG, ICG shall order from Verizon, and Verizon shall provide, the Two-Way Interconnection Trunks, and the Entrance Facility on which such Trunks will ride, and transport and multiplexing, in accordance with the rates, terms and conditions set forth in this Agreement and Verizon’s applicable Tariffs.

  • Interoffice Transmission Facilities BellSouth shall provide nondiscriminatory access, in accordance with FCC Rule 51.311 and Section 251(c)(3) of the Act, to interoffice transmission facilities on an unbundled basis to <<customer_name>> for the provision of a telecommunications service.

Time is Money Join Law Insider Premium to draft better contracts faster.