Versions Compared

Key

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

For Adhering Parties, the following service levels apply

...

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

...

The availability window includes the times at which Adhering Parties guarantee the availability of their service.

No norm is set for Adhering Parties' availability window, to leave Service Providers free to run their service whenever they deem appropriate (e.g. a trucking company does not need to leave its trucks' board computers on 24 hours * all days of the year). 

...

Before an Adhering Party knows whether it may respond to a request, however, it often needs to request (more) information from one or more certified parties; e.g. delegation info or authorisation info. It therefore needs to send out a new message itself, and wait for this message to be responded to by a certified party. While Certified Parties' response times are short, the process of sending out and receiving (sometimes several) new messages before the original request can be answered takes time. Consequently, no norm is set for Adhering Parties' total performance. The following guidelines are set:

  • 95% of Adhering Parties' messages SHOULD be responded within 2 seconds of receiving all information needed from certified parties;
  • 99% of Adhering Parties' messages SHOULD be responded within 5 seconds of receiving all information needed from certified parties;
  • Each Adhering Party SHOULD be able to process at least 100 simultaneous messages while meeting above requirements.


Anchor
IncidentsAP
IncidentsAP

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

Three classifications of incidents are recognised within iSHARE, as explained in the incident management process:

  • Minor incident;
  • Calamity;
  • Crisis.

Norm:

  • All incidents MUST be communicated by the Adhering Party(s)to the Scheme Owner directly after they are discovered;
  • Communication MUST include date, time, incident level as estimated by the Adhering Party(s), argumentation including impacted service(s), and a potential incident manager;
  • In case of a calamity or crisis, the Adhering 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 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 Adhering Party (in cooperation with the Scheme Owner 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 presents an overview of current calamities and crises on its website

 

Anchor
SupportAP
SupportAP

Support

...

No norm is set for Adhering Parties as it is a matter between them (and other Adhering Parties). The following guidelines are set, however:

  • Adhering Parties are available for support via e-mail;
  • They SHOULD confirm receiving a question/request within 1 working day. They SHOULD send an underpinned reaction (with an answer/solution or at the very least a direction) within 5 working days.