Long-Term Archive Service Requirements
draft-ietf-ltans-reqs-10

[Ballot comment]
characteristics subject to verification will vary.  For example,
  authentication of an originator may be possible in all cases, e.g.,
s/may be/may not be/

  where the object submitted to the archive is not signed or where the
  object does not include the necessary information to authenticate the
  object's signer.

[Ballot discuss]
I am concerned about the treatment of metadata related to the archived objects.  The document says:

A long-term archive service must permit clients to request the
  following basic operations:
...
- specify metadata associated with an archived data object

and

  Submitters should be able to specify metadata that, for example, can
  be used to enable retrievers to render the data correctly, to locate
  data in an archive or to place data in a particular context.
  Examples include, classification codes, type of format, contributors,
  title, author, date.  Alternatively, such information may be included
  in the content of an archived data object.

First, it appears that the metadata includes the fundamental type data
and the information for rendering.  It is a very good and useful to
recognize that long term archives should store this information.  They should
also recognize, however, that there are formats which can store multiple
representations, and that the specification of type can indicate which of those
representations is rendered (A very simple example is the image type and
its alternate text as rendered in web pages).  There is no necessary connection
between the semantic content of the alternate representations (again, using the
simple example, bad actors use dictionary attacks in alt text to draw people to
pictures which have unrelated content).

Did the working group consider a requirement for tracking changes to the metada?
Did the working group consider the authority setting specific policies for changes
in this area (in particular, is change to the metadata part of "manage data objects"
as is set out in 4.4.1?")

I have to say that I find this section:

  For example, the submitter (or other authorized entity)
  could periodically retrieve data, convert the data and re-submit it
  in new format.  Additional mechanisms, applications or tools may be
  needed to preserve the value of evidence records associated with
  original archived data object.

also a bit problematic, as I'm not sure that the relationship post-conversion
to the data pre-conversion is being described adequately here.  I assume that
the LTA will track and maintain records for each of these actions and may
maintain the prior objects for the life of the storage, and that these choices will
be set out in the policy.  But some reassurrance that the WG recognizes that
anything that allows transformation of this type may rely on one representation
from an object that could store multiple representations would be valuable.

[Ballot discuss]
I am concerned about the treatment of metadata related to the archived objects.  The document says:

A long-term archive service must permit clients to request the
  following basic operations:
...
- specify metadata associated with an archived data object

and

  Submitters should be able to specify metadata that, for example, can
  be used to enable retrievers to render the data correctly, to locate
  data in an archive or to place data in a particular context.
  Examples include, classification codes, type of format, contributors,
  title, author, date.  Alternatively, such information may be included
  in the content of an archived data object.

First, it appears that the metadata includes the fundamental type data
and the information for rendering.  It is a very good and useful to
recognize that long term archives should store this information.  They should
also recognize, however, that there are formats which can store multiple
representations, and that the specification of type can indicate which of those
representations is rendered (A very simple example is the image type and
its alternate text).  There is no necessary connection between the semantic
content of the alternate representations (again, using the simple example,
people use dictionary attacks in alt text to draw people to pictures which have
unrelated content).

Did the working group consider a requirement for tracking changes to the metada?
Did the working group consider the authority setting specific policies for changes
in this area (in particular, is change to the metadata part of "manage data objects"
as is set out in 4.4.1?"

I have to say that I find this section:

  For example, the submitter (or other authorized entity)
  could periodically retrieve data, convert the data and re-submit it
  in new format.  Additional mechanisms, applications or tools may be
  needed to preserve the value of evidence records associated with
  original archived data object.

also a bit problematic, as I'm not sure that the relationship post-conversion
to the data pre-conversion is being described adequately here.  I assume that
the LTA will track and maintain records for each of these actions and may
maintain the prior objects for the life of the storage, and that these choices will
be set out in the policy.  But some reassurrance that the WG recognizes that
anything that allows transformation of this type may rely on one representation
from an object that could store multiple representations would be valuable.

[Ballot comment]
Is "archivation" a recognized term of art in this community?  It's use here seems to be avoid the slightly longer but much more clear "archival storage".

PROTO Write-up

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Answer:
Tobias Gondrom is the Document Shepherd for this document and believes
the document is ready for publication.


(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

Answer:
The document has received review from key WG members. The Document
Sheppard does not have concerns about the depth/breadth of the reviews
conducted by WG members.


(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

Answer:
No. The document covers the requirements for the following
specifications developed by the WG. The WG input for this document was
from a great variety of people and the Document Shepherd is sure all
important input for this document has been received. The documents
resulting from the requirements established in this draft, e.g., ERS and
LTAP, may warrant a broader review.


(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if those issues have been discussed in the WG and the
WG has indicated that it still wishes to advance the document,
detail those concerns here.

Answer:
No specific concerns are known at this time.


(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

Answer:
The draft has completed WG last call. The WG is fairly small so a few
individuals is probably accurate, but there is consensus within the
community.


(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire will
be entered into the ID Tracker.)

Answer: No.


(1.g) Has the Document Shepherd verified that the document satisfies
all ID nits? (See http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough.

Answer:
There is one nit, the document lacks an IANA considerations section.


(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

Answer:
The document only has Informative References. There are no Normative
References.


(1.i) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up. Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:


Answer:
Technical Summary

There are many scenarios in which users must be able to prove the
existence of data at a specific point in time and be able to demonstrate
the integrity of data since that time, even when the duration from time
of existence to time of demonstration spans a large period of time.
Additionally, users must be able to verify signatures on digitally
signed data many years after the generation of the signature. This
document describes a class of long-term archive services to support such
scenarios and the technical requirements for interacting with such
services.


Working Group Summary
This document is a product of the Long-Term Archive and Notary Services
(LTANS) Working Group. The document was reviewed by LTANS WG members
and chairs.

Document Quality
This document does not specify a protocol. It documents the requirements
for protocols and data structures defined in other documents. There
exist two or more implementations of at least a protocol and a data
structure that address the requirements asserted in this document.