Emergency Transition Registry Operator agrees that, in the event that any of the emergency thresholds for registry functions set forth in Section 6 of Specification 10 is reached, ICANN may designate an emergency interim registry operator of the registry for the TLD (an “Emergency Operator”) in accordance with ICANN’s registry transition process (available at <xxxx://xxx.xxxxx.xxx/en/resources/registries/transition-‐processes>) (as the same may be amended from time to time, the “Registry Transition Process”) until such time as Registry Operator has demonstrated to ICANN’s reasonable satisfaction that it can resume operation of the registry for the TLD without the reoccurrence of such failure. Following such demonstration, Registry Operator may transition back into operation of the registry for the TLD pursuant to the procedures set out in the Registry Transition Process, provided that Registry Operator pays all reasonable costs incurred (i) by ICANN as a result of the designation of the Emergency Operator and (ii) by the Emergency Operator in connection with the operation of the registry for the TLD, which costs shall be documented in reasonable detail in records that shall be made available to Registry Operator. In the event ICANN designates an Emergency Operator pursuant to this Section 2.13 and the Registry Transition Process, Registry Operator shall provide ICANN or any such Emergency Operator with all data (including the data escrowed in accordance with Section 2.3) regarding operations of the registry for the TLD necessary to maintain operations and registry functions that may be reasonably requested by ICANN or such Emergency Operator. Registry Operator agrees that ICANN may make any changes it deems necessary to the IANA database for DNS and WHOIS records with respect to the TLD in the event that an Emergency Operator is designated pursuant to this Section 2.13. In addition, in the event of such failure, ICANN shall retain and may enforce its rights under the Continued Operations Instrument.
Emergency Thresholds The following matrix presents the emergency thresholds that, if reached by any of the services mentioned above for a TLD, would cause the emergency transition of the Registry for the TLD as specified in Section 2.13 of this Agreement. Critical Function Emergency Threshold DNS Service (all servers) 4-hour total downtime / week DNSSEC proper resolution 4-hour total downtime / week EPP 24-hour total downtime / week RDDS (WHOIS/Web-based WHOIS) 24-hour total downtime / week Data Escrow Breach of the Registry Agreement as described in Specification 2, Part B, Section 6.
Funding Availability This Contract is at all times subject to state appropriations. The Department makes no express or implied representation or guarantee of continued or future funding under this Contract. The Department has, as of the date of the execution of this Contract, obtained all requisite approvals and authority to enter into and perform its obligations under this Contract, including, without limitation, the obligation to make the initial payment or payments required to be made under this Contract on the date or dates upon which such initial payment or payments may otherwise be disbursed during the current contract period, (i.e., Sept ember 1, 2015, through August 31, 2017). The Grantee acknowledges the Department’s authority to make such payments is contingent upon the Texas Legislature's appropriation to the Department of sufficient funds and the availability of funds to the Department for such purpose. If the State of Texas or the federal government terminates its appropriation through the Department or fails to pay the full amount of the allocation for the operation of any grant or reimbursement program hereunder , or the funds are otherwise unavailable, the Department may immediately and without penalty reduce payments or terminate this Contract, in whole or in part. Upon termination of the Contract or reduction of payments, the Grantee shall return to the Department any unexpended funds already disbursed to the Grantee. Neither the Department nor the State of Texas shall incur liability for damages or any loss that may be caused or associated with such termination or reduction of payments. The Department shall not be required to give prior notice for termination or reduction of payments.
Fund Availability Financial obligations of the University payable after the current Fiscal Year are contingent upon funds for that purpose being appropriated, budgeted, and otherwise made available.
High Availability Registry Operator will conduct its operations using network and geographically diverse, redundant servers (including network-‐level redundancy, end-‐node level redundancy and the implementation of a load balancing scheme where applicable) to ensure continued operation in the case of technical failure (widespread or local), or an extraordinary occurrence or circumstance beyond the control of the Registry Operator. Registry Operator’s emergency operations department shall be available at all times to respond to extraordinary occurrences.
System Availability System Availability percentage is calculated as follows: Total MinutesintheMonth −Downtime System Availability%age = Total MinutesintheMonth *100 System Availability SLA (“SLA”) 99.5% System Availability percentage during each Month for productive versions Credit 2% of Monthly Subscription Fees for each 1% below SLA, not to exceed 100% of Monthly Subscription Fees Excluded Downtime Total Minutes in the Month attributable to: (i) a Scheduled Downtime for which a Regular Maintenance Window is described in Section 4 below, or (ii) any other Scheduled Downtime according to Section 4 for which the customer has been notified at least five (5) business days prior to such Scheduled Downtime or (iii) unavailability caused by factors outside of SAP’s reasonable control, such as unpredictable and unforeseeable events that could not have been avoided even if reasonable care had been exercised. Scheduled Downtime Scheduled Downtime for the applicable Cloud Services to which customer has subscribed is set forth in Section 4 below entitled “Maintenance Windows for Cloud Services”.
DNS name server availability Refers to the ability of a public-‐DNS registered “IP address” of a particular name server listed as authoritative for a domain name, to answer DNS queries from an Internet user. All the public DNS-‐registered “IP address” of all name servers of the domain name being monitored shall be tested individually. If 51% or more of the DNS testing probes get undefined/unanswered results from “DNS tests” to a name server “IP address” during a given time, the name server “IP address” will be considered unavailable.
Non-Emergency Transportation Routine medical transportation to and from Medicaid-covered scheduled medical appointments is covered by the non-emergency medical transportation (NEMT) broker Medicaid program. This includes transportation via multi-passenger van services and common carriers such as public railways, buses, cabs, airlines, ambulance as appropriate, and private vehicle transportation by individuals. The NEMT broker must approve ambulance, multi-passenger van services, and transportation by common carriers. The MCO must inform enrollees of how to access non-emergency transportation as appropriate.
DNS service availability Refers to the ability of the group of listed-‐as-‐authoritative name servers of a particular domain name (e.g., a TLD), to answer DNS queries from DNS probes. For the service to be considered available at a particular moment, at least, two of the delegated name servers registered in the DNS must have successful results from “DNS tests” to each of their public-‐DNS registered “IP addresses” to which the name server resolves. If 51% or more of the DNS testing probes see the service as unavailable during a given time, the DNS service will be considered unavailable.
EPP service availability Refers to the ability of the TLD EPP servers as a group, to respond to commands from the Registry accredited Registrars, who already have credentials to the servers. The response shall include appropriate data from the Registry System. An EPP command with “EPP command RTT” 5 times higher than the corresponding SLR will be considered as unanswered. If 51% or more of the EPP testing probes see the EPP service as unavailable during a given time, the EPP service will be considered unavailable.
