Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

This part of the iSHARE Trust Framework is considered normative and is therefore compliant with RFC 2119.

...

Anchor
AvailabilityCP
AvailabilityCP

Availability

Availability is a measure of the time a service is in a functioning condition. It includes the availability window and the maintenance window.

Availability window

The availability window includes the times at which Satellite/Certified Party guarantees the availability of their service.

...

*Planned maintenance does NOT count as unavailability 

Maintenance window

The maintenance window includes the times at which Satellite/Certified Party can perform planned maintenance, that is likely to result in downtime, to their service(s). If no downtime is expected, maintenance can take place outside of the maintenance window. Planned maintenance does NOT include incident resolution, as this can take place outside the maintenance window as described under incidents

...

Anchor
PerformanceCP
PerformanceCP

Performance

Norm:

  • The maintenance window includes the nights from Friday to Saturday and from Saturday to Sunday, from 00:00-5.59h;
  • Maintenance MUST be announced to the impacted parties directly as well as to the Satellite/Scheme Owner**;
  • Announcements MUST be made at least 10 working days before the maintenance and MUST include date, time, and impacted service(s).

...

Anchor
IncidentsCP
IncidentsCP

Incidents

An incident is an event, not part of the standard service operation, that results in a potential impact or risk with regards to the quality, availability, confidentiality and/or integrity of (data within) the iSHARE Trust Framework. This ONLY includes the data used for identification, authentication and authorisation purposes in the context of data exchange, but not the contents of the actual data exchange. 

...

  • All incidents MUST be communicated by the Satellite/Certified Party(ies) to the Scheme Owner/Satellite directly after they are discovered;
  • Communication MUST include date, time, incident level as estimated by the Satellite/Certified Party(ies), argumentation including impacted service(s), and a potential incident manager;
  • In case of a calamity or crisis, the Satellite/Certified Party MUST have an incident manager available during working days, and SHOULD have an incident manager available 24 * 7;
  • An update on the incident MUST be communicated to the Satellite/Scheme Owner*:
    • For minor incidents, at the end of each working day;
    • For calamities, within 2 hours of every significant update and at the end of each working day;
    • For crises, within 2 hours of every significant update and every 4 hours.
  • All incidents SHOULD be handled by the Satellite/Certified Party (in cooperation with the Scheme Owner/Satellite as per the
  •  incident management process) within 3 working days after being appointed as the responsible party - unless agreed otherwise.

*In line with the incident management process, the Scheme Owner/Satellite presents an overview of current calamities and crises on its website


Anchor
SupportCP
SupportCP

Support

Support by Satellite includes answering questions and requests from Adhering and Certified Parties.

...

Anchor
ReportingCP
ReportingCP

Reporting

Reports are meant to monitor both compliance to the service level agreements and the (growing) use of the iSHARE network, as described in the management reporting process. The 

...



Certified party
Satellite
AvailabilityYesYes
Number of relations with Adhering PartiesYesOnly if operating standalone (disconnected from the distributed ledger)
Number of transactionsYesNo
Number of transactions per Adhering PartyYesNo

Number of incidents.

YesYes

Satellite/Certified Parties are expected to collect management information about each month: 0:00h on the first day to 23:59h on the last.

...