Pillar SLA

Describes the pillar characteristics which needs to be defined, besides the ones defined in the RepositorySettings.

General

• Which progress responses should be used.
• Which file exchange protocols are supported.

GetFile

• Must TimeToDeliver be included in IdentifyPillarsForGetFileResponse and what should the meaning of these be.
• Must FileSize be included in  the GetFileFinalResponse.
• Does the pillar support get the FilePart parameter.

PutFile

• The precise interpretation of a PutFileFinalResponse. Does it mean that:
  • The file been received and checksummed by the pillar.
  • The file been stored on the final media.
  • The file been checksummed on the final media.
  • Has the final media been placed in the final physical 

Checksums

• Max checksums age: Defines the (maximum) interval between checksum recalculations.
• Must upload of results via the file exchange protocol be supported.
• Which non-default checksums are supported (SHA1, SHA256, SHA384, SHA512, HMAC_MD5, HMAC_SHA1, HMAC_SHA256, HMAC_SHA384, HMAC_SHA512, OTHER).
• Is Paging supported. Note that if this is unsupported the scalability will be limited, eg. max number of checksums will be around 50000 depending on memory allocation to the different components.

FileIDs 

• Is Paging supported. Note that if this is unsupported the scalability will be limited, eg. max number of files will be around 50000 depending on memory allocation to the different components.

Audit trails

• Which types of audit trails to be generate or not to be generate. The following types needs special consideration.
  
  • CHECKSUM_CALCULATED: Enabling this type of audit trails may increase the size f the audit trails significantly.
• Is Paging supported. Note that if this is unsupported the scalability will be limited, eg. max number of audit trails will be around 50000 depending on memory allocation to the different components.
• Should Offline/online audit events be generated for pillars with offline capabilities.