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 (18)
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.

  • 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.

  • 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 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, Statement of Work.

  • 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 6.1 NCR Voyix will use commercially reasonable efforts to make the Service available to you at or above the Availability Rate set forth at xxxxx://xxx.xxx.xxx/support/aloha-sla. If NCR Voyix does not meet the Availability Rate, you are entitled to request a service-level credit subject to the terms of this Agreement. This credit is calculated as a percentage of the monthly recurring bill (or monthly pro rata share of billing, if billing does not occur monthly) for the Service for the month in which the Availability Rate was not met. The Availability Rate is determined by: (a) dividing the total number of valid outage minutes in a calendar month by the total number of minutes in that month; (b) subtracting that quotient from 1.00; (c) multiplying that difference by 100; and (d) rounding that result to two decimal places in accordance with standard rounding conventions. The number of outage minutes per day for a given service is determined by the lesser of the number of outage minutes.

  • Service Levels All service level requirements will be set forth in Exhibit A (“XXXX.xxx Referral Service Level Requirements”). Recipient Xxxxxx agrees to adhere, and encourage Recipient Agent’s adherence, with the version of the XXXX.xxx Referral Service Level Requirements in effect at the time XXXX.xxx identifies the Referral to Recipient Broker/Agent.

Draft better contracts in just 5 minutes Get the weekly Law Insider newsletter packed with expert videos, webinars, ebooks, and more!