draft-ietf-ltans-reqs-02.txt

[Peter Sylvester <Peter.Sylvester@xxxxxxxxxx>]

I have some comments to the "archive service requirements":


> Abstract

>   In many scenarios, users need to be able to prove the existence of
>   data at a given time and integrity of data, especially digitally
>   signed data, in a common and reproducible way after an arbitrarily
>   long period.  This document specifies the technical requirements for
>   a long-term archive service to support such scenarios.

Somehow I'd like to see the word "protocol" here. 

"after an arbitrarily long" is a pretty arbitary term avoid
to say nothing precise :-) it seems  slightly misleading
since we forget that some data MUST be destroyed after a
defined time in certain scenarious. 

This could be explained later in the use cases which could benefit
from some important case of let's say a telephone company or an ISP
who has to safely store connection data for a definitely limited
time, ot certified accountants, "exterts compatbles" "Steuerberater"
who must store their raw data for some years but not eternally. 

Thus the following: 

>   Deletion requests must be authorized and an authorization policy must
>   be defined and observed by the long-term archive service (as part of
>   an archive policy).  In some cases, deletion may not involve physical
>   deletion and instead may simply be an early termination of the
>   archivation period.

is somewhat the contrary of what I'd say: Shortening of an
archiving period seems to me rather exceptional, but extension
must be ensured in case of a conflict between the involved parties.
Extension may have some influence of how data can be deleted
on some media, if one stores all data of one months for all customers
of a telephone company, then not deleting data of one customer
may involve that no data are deleted. Such a situation seems bad to me.
The requirement should be IMO that when an extension of
an archiving period occurs, the archiver service should implement
a technique that limits the need of extending other data. 


Reading Larry's comment, I think defining a good abstract
may come in a yoyo technique following the actual texts. 

I stop here, since I prefer that we first "digest" Denis and Larry's
comments in some way.