- Integrity correct process (and communication including messages) is missing analysis, especially regarding effective correction, where pillars may transmit correct objects directly, instead of using temporary storage pointed out by the integrity client.
- Handling audit trails needs further analysis. it can also be considered whether parts of chashe database can be reestablised from audit trails.
- Integrity check needs further analysis, especially regarding the cases where a pillar is exchanged by another.
- Handling more checksumsalgorithms needs further analysis
- More analysis on whether behavior is sufficient in cases where pillars are representing a bit repository, or when integrity client report to other bit repository. For example: this may raise a requirement saying that a pillar must be able to request a copy from another pillar (in connection with correct)
- Investigate the needed procedures to handle restore after a mass loss without using the protocol.
- Investigate possibilities to specify patterns of fiel ids as file id specification
- Investigate need for politics/SLA for how to request checksums for effeciency reasons.
Der kan være forskellige scenarier hvor der er lige så billigt blot at lave enkelt request fremfor at udvælge specifikke checksums man ønsker. For eksempel hvis alle checksummer ligger i en slags front end for et ben, så kan det være lige så let at få alle og overlade til clienten kun at opdatere informationer om nyudregnede checksummer. Derimod hvis der kun er tale om et meget begrænset antal checkesummer som udregnes direkte, så kan det være bedre at om hver enkel. Dette kunne evt. også være en opsætningsparameter til klienten.
Missing specification of needed integrity information in "database".