Extended Planned Outage Notification Sample Clauses

Extended Planned Outage Notification. The Registry Operator must notify the Registrar Community of any Extended Planned Outage ("Extended Planned Outage Notification"). The Extended Planned Outage Notification shall set forth the date and time of the Extended Planned Outage. The number of days prior to an Extended Planned Outage that the Registry Operator must notify ICANN-Accredited Registrars is as follows:
Sample 1Sample 2Sample 3See All (16)
AutoNDA by SimpleDocs
Extended Planned Outage Notification. The Registry Operator must notify the Registrar Community of any Extended Planned Outage ("Extended Planned Outage Notification"). The Extended Planned Outage Notification shall set forth the date and time of the Extended Planned Outage. The number of days prior to an Extended Planned Outage that the Registry Operator must notify ICANN-Accredited Registrars is as follows: Extended Planned Outage Timeframe - SRS = 90 Days; Extended Planned Outage Timeframe - DNS Name Server =no Extended Planned Outages allowed; and Extended Planned Outage Timeframe - Whois = no Extended Planned Outages allowed. The Extended Planned Outage Notification metric is a Credit Level 5. Processing Time. Processing time is a measurement of Service Availability and equals the Round-trip for the System Services ("Processing Time"). The Registry Operator will log the Processing Time for all of the protocol transactions (i.e. Check, Add/Create, Modify/Update and Delete). Processing Time will be measured in a Monthly Timeframe and reported on a monthly basis to ICANN in accordance with Appendix 4. Should the total volume of protocol transactions (measured individually) added by all ICANN- Accredited Registrars for a Monthly Timeframe exceed Registry Operator's actual volume of protocol transactions for the previous Monthly Timeframe by more than 20%, then ICANN-Accredited Registrars shall not be eligible for any SLA credit, and Registry Operator shall have no liability to ICANN, if Registry Operator fails to meet a Processing Time Performance Specification set forth in this Section 6.5. Processing Time--Check Domain = 25 milliseconds for 95%. The Processing Time for Check Domain is applicable to the SRS as accessed through the defined protocol (EPP) for registry-registrar interaction and measures the Processing Time for an availability check of a specific domain name. The performance specification for Check Domain is 25 milliseconds Round-trip for 95% of the transactions during a Monthly Timeframe. The Processing Time for Check Domain metric is a Credit Level 3. Processing Time--Add/Create = 50 milliseconds for 95%. The Processing Time for Add/Create is applicable to the SRS as accessed through the defined protocol (EPP) for registry-registrar interaction and measures the Processing Time for add/create transactions associated with domain names. The Performance Specification for ADD/Create is 50 milliseconds for Round-trip for 95% of the transactions processed during a Monthly Timeframe. ...
Sample 1Sample 2
Extended Planned Outage Notification. The usTLD Administrator will notify all of its registrars of any Extended Planned Outage. The Extended Planned Outage Notification Performance Specification defines the number of days prior to an Extended Planned Outage that the usTLD Administrator will notify its registrars. The Extended Planned Outage Notification for the Core Services is as follows:
Sample 1
Extended Planned Outage Notification. The xxxx.xx Administrator will notify all of its registrars of any Extended Planned Outage. The Extended Planned Outage Notification Performance Specification defines the number of days prior to an Extended Planned Outage that the xxxx.xx Administrator will notify its registrars. The Extended Planned Outage Notification for the Core Services is as follows: • Extended Planned Outage Timeframe–SRS = 4 weeks; • Extended Planned Outage Timeframe–Nameserver =(no planned outages allowed); and • Extended Planned Outage Timeframe–Whois = 4 weeks. o Processing Time. Processing Time is an important measurement of transaction- based services like those provided by the xxxx.xx System. The first three Performance Specifications, Service Availability, Planned Outages and Extended Planned Outages, measure the amount of time that the service is available to its users. Processing Time measures the quality of that service. Processing Time refers to the time that the xxxx.xx system receives a request and sends a response to that request. Since each of the xxxx.xx Services has a unique function the Performance Specifications for Processing Time are unique to each of the xxxx.xx Services. For example, a Performance Specification for the Nameserver is not applicable to the SRS and Whois, etc. Processing Time Performance Specifications are a C2 priority level. Processing Time Performance Specifications have a monthly Service Level Measurement Period and will be reported on a monthly basis. The xxxx.xx system will log the processing time for all of the related transactions, measured from the time it receives the request to the time that it returns a response. ▪ Processing Time–Add, Modify, Delete = 3 seconds for 95% • Processing Time–Add, Modify, and Delete is applicable to the SRS as accessed through the EPP protocol. It measures the processing time for add, modify, and delete transactions associated with domain names, nameserver, contacts, and registrar profile information. • The Performance Specification is 3 seconds for 95% of the transactions processed. That is, 95% of the transactions will take 3 seconds or less from the time the xxxx.xx system receives the request to the time it provides a response. ▪ Processing Time–Query Domain = 1.5 seconds for 95% • Processing Time–Query Domain is applicable to the SRS as accessed through the EPP protocol. It measures the processing time for an availability query of a specific domain name. • The performance specification is 1.5 seconds...
Sample 1

Related to Extended Planned Outage Notification

  • Termination for Force Majeure In the event of a force majeure that lasts longer than thirty (30) days from the date that a Party claiming relief due to the force majeure event gives notice to the other Party, the Party not claiming relief under the force majeure event may terminate this Agreement upon written notice to the other Party. For the avoidance of doubt, the COVID-19 pandemic does not constitute a force majeure event.

  • Force Majeure Delays In any case where either party hereto is required to do any act (other than the payment of money), delays caused by or resulting from Acts of God or Nature, war, civil commotion, fire, flood or other casualty, labor difficulties, shortages of labor or materials or equipment, government regulations, delay by government or regulatory agencies with respect to approval or permit process, unusually severe weather, or other causes beyond such party’s reasonable control the time during which act shall be completed, shall be deemed to be extended by the period of such delay, whether such time be designated by a fixed date, a fixed time or “a reasonable time.”

  • Commencement Date Delay Except as otherwise provided in the Lease, Delivery of the Premises shall occur when Landlord’s Work has been Substantially Completed, except to the extent that completion of Landlord’s Work shall have been actually delayed by any one or more of the following causes (“Tenant Delay”):

  • Service Level In the event that League InfoSight discovers or is notified by you of the existence of Non-Scheduled Downtime, we will use commercially reasonable efforts to determine the source of the problem and attempt to resolve it as quickly as possible.

  • Network Access Control The VISION Web Site and the Distribution Support Services Web Site (the “DST Web Sites”) are protected through multiple levels of network controls. The first defense is a border router which exists at the boundary between the DST Web Sites and the Internet Service Provider. The border router provides basic protections including anti-spoofing controls. Next is a highly available pair of stateful firewalls that allow only HTTPS traffic destined to the DST Web Sites. The third network control is a highly available pair of load balancers that terminate the HTTPS connections and then forward the traffic on to one of several available web servers. In addition, a second highly available pair of stateful firewalls enforce network controls between the web servers and any back-end application servers. No Internet traffic is allowed directly to the back-end application servers. The DST Web Sites equipment is located and administered at DST’s Winchester data center. Changes to the systems residing on this computer are submitted through the DST change control process. All services and functions within the DST Web Sites are deactivated with the exception of services and functions which support the transfer of files. All ports on the DST Web Sites are disabled, except those ports required to transfer files. All “listeners,” other than listeners required for inbound connections from the load balancers, are deactivated. Directory structures are “hidden” from the user. Services which provide directory information are also deactivated.

  • Excusable Delay The Contractor is entitled to an equitable adjustment of time, issued via Change Order, for delays caused by the following:

  • Statement of Work The Contractor shall provide the services and staff, and otherwise do all things necessary for or incidental to the performance of work, as set forth below:

  • Excusable Delays Except with respect to defaults of subproviders, the Engineer shall not be in default by reason of any failure in performance of this contract in accordance with its terms (including any failure to progress in the performance of the work) if such failure arises out of causes beyond the control and without the default or negligence of the Engineer. Such causes may include, but are not restricted to, acts of God or the public enemy, acts of the Government in either its sovereign or contractual capacity, fires, floods, epidemics, quarantine restrictions, strikes, freight embargoes, and unusually severe weather.

  • Service Level Agreement Subject to the terms and conditions of this Agreement, Bank agrees to perform the custody services provided for under this Agreement in a manner that meets or exceeds any service levels as may be agreed upon by the parties from time to time in a written document that is executed by both parties on or after the date of this Agreement, unless that written document specifically states that it is not contractually binding. For the avoidance of doubt, Bank’s Service Directory shall not be deemed to be such a written document.

  • Service Levels Annex 1 to this Part A of this Call Off Schedule sets out the Service Levels the performance of which the Parties have agreed to measure. The Supplier shall monitor its performance of this Call Off Contract by reference to the relevant performance criteria for achieving the Service Levels shown in Annex 1 to this Part A of this Call Off Schedule (the Service Level Performance Criteria) and shall send the Customer a Performance Monitoring Report detailing the level of service which was achieved in accordance with the provisions of Part B (Performance Monitoring) of this Call Off Schedule. The Supplier shall, at all times, provide the Services in such a manner that the Service Levels Performance Measures are achieved. If the level of performance of the Supplier of any element of the provision by it of the Services during the Call Off Contract Period: is likely to or fails to meet any Service Level Performance Measure or is likely to cause or causes a Critical Service Failure to occur, the Supplier shall immediately notify the Customer in writing and the Customer, in its absolute discretion and without prejudice to any other of its rights howsoever arising including under Clause 12 of this Call Off Contract (Service Levels and Service Credits), may: require the Supplier to immediately take all remedial action that is reasonable to mitigate the impact on the Customer and to rectify or prevent a Service Level Failure or Critical Service Level Failure from taking place or recurring; and if the action taken under paragraph (a) above has not already prevented or remedied the Service Level Failure or Critical Service Level Failure, the Customer shall be entitled to instruct the Supplier to comply with the Rectification Plan Process; or if a Service Level Failure has occurred, deduct from the Call Off Contract Charges the applicable Service Level Credits payable by the Supplier to the Customer in accordance with the calculation formula set out in Annex 1 of this Part A of this Call Off Schedule; or if a Critical Service Level Failure has occurred, exercise its right to Compensation for Critical Service Level Failure in accordance with Clause 13 of this Call Off Contract (Critical Service Level Failure) (including subject, for the avoidance of doubt, the proviso in Clause 13.1.2 of this Call Off Contract in relation to Material Breach). Approval and implementation by the Customer of any Rectification Plan shall not relieve the Supplier of any continuing responsibility to achieve the Service Levels, or remedy any failure to do so, and no estoppels or waiver shall arise from any such Approval and/or implementation by the Customer. SERVICE CREDITS Annex 1 to this Part A of this Call Off Schedule sets out the formula used to calculate a Service Credit payable to the Customer as a result of a Service Level Failure in a given service period which, for the purpose of this Call Off Schedule, shall be a recurrent period of [one Month] during the Call Off Contract Period (the Service Period).

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