Following is a list of DPN requirements and assumptions

• DPN is a federated preservation network of preservation archives.
  • All archives act to preserve content, not just as remote storage.
• DPN will have agreements to allow for Succession of content in the event an archive can no longer perform its function as an archive.
• The successor of content will take on the responsibilities of and become the First Node for the failed archive.
  • Brighten content so as to meet the needs of the community of the content.
  • Act as the arbiter of content for clients of the former archi
• In the event of a Succession occurrence, all replicating nodes will recognize the new successor and act in accordance with prior agreements held by the former archive.
• DPN will as much as possible have independent implementations.
• DPN communications will follow best practices and use mutual authentication over secure channels.
• DPN will provide for replication of content from a First Node (originator of content) to Replicating Nodes.
  • The replication of content will happen at the request of the First Node, not a Replicating Node.
• DPN First Nodes will be the authoritative node for content.
  • The First Node will be the arbiter of digital objects until such time as succession takes place.
• DPN will provide recovery of lost content at First Node, or Replicating Nodes (healing).
• DPN will provide a services model so that any of the First Nodes, or Replicating nodes can ascertain if their content is valid.
• DPN will enable organizational audit.
  • Process audit at the DPN federation.
  • Process audit at the Node.
  • Brightening audit (process, test).
  • Audit trails for events.
• DPN will support Content Fixity audit
  • (random, periodic, full)
• DPN will provide status reporting, activity, logging, traffic, volume, events, etc.
  • Global (across federation).
  • At Node level.
  • Periodic Reporting. 
  • Significant event reporting, for example succession events, loss of content, etc.
• DPN will support a DPN UUID.
• DPN will support a common lightweight wrapper (bag) for content transfer.
• DPN will retain ingested content indefinitely. Content may be de-accessioned upon extenuating circumstances (e.g. court order)
• Any critical metadata (TBD) that is placed in the 'registry' will also be placed in the content bags
• DPN content and services will be distributed and federated.
• DPN nodes will all be first class nodes with respect to each other.
• Succession and brightening of content will be difficult, expensive and time consuming. We must test brightening and not assume that the vast institutional knowledge of each repository is easily captured or represented in DPN.
• We will use a registry.
• We will use lightweight packaging, such as bagit bags, but only for wrapping content, specific to DPN.
• The First Node initiates replication and controls changes in registry/database holding information regarding content it is the First Node for.
• Replication and update will take time, the architecture needs to accommodate this.
• Because this is a distributed model, we assume eventual consistency for replication of content and registries.
• Implementations will be de-coupled, but communication will not.
• We can create DPN first class objects that are useful for DPN purposes. These objects will be preserved by all Nodes and useful for DPN preservation functions.
• DPN will have separate inter-node communication channels for
  • content transfer
  • process control
• Communication can be point-to-point and point-to-multi-point.
• Communication will be durable and persistant to support unreliable networks and node failure.
• Support for both synchronous and asynchronous communication as required.

• The goal here is to reduce failures of same implementation.