Baseline Member Node implementation requirements
================================================
**status: draft**

All Member Nodes, regardless of Tier, share the same baseline requirement of
managing their object collection such that:

**1. All objects are identified by a globally unique identifier.**

  Identifiers provide the primary mechanism for users to access a specific
  item. Identifiers must conform to the DataONE persistent identifier
  specification.

**2. The original bytes of submitted objects are always available using the
original identifier.**

  To satisfy DataONE's preservation policy, the content bound to an identifier
  does not change and is thus immutable. Organizations starting with systems
  that allow overwrites will need additional mechanisms to ensure access to
  older versions (via `MN_Read.get()`)

**3. Content access policies are respected.**

  Tier 2 and higher nodes satisfy this requirement by implementing the API and
  following the functional requirements for access control implementation. By
  implication, Tier 1 nodes can only host and expose public objects.

**4. Updates are treated as a separate objects.**

  An update to an existing object causes creation of a new object and a new
  identifier, and the object being replaced is archived. (Archiving removes
  the object from the search index, but leaves it available via `MN_Read.get()`.
  The *isObsoletedBy / obsoletes* relationship is established in the system
  metadata of both objects to allow navigation through the version chain.)

**5. Voluntary deletes are handled as archive actions.**

  Objects published to DataONE are not deleted, but archived. This helps
  ensure DataONE's preservation requirements are upheld. An archived object
  has its `archived` field set to `true` in its systemMetadata, and the object
  remains accessible by its identifier. This applies to all objects ever
  exposed through the DataONE API regardless of how the content is added to a
  Member Node. For example, if a Member Node manages their collection with
  external tools, the system should behave such that deleted content is
  treated as archived, rather than actually deleted.

**6. Compulsory (or administrative) deletes, are coordinated and executed via
the DataONE Coordinating Nodes.**

  These are true deletes where the content is removed from all nodes, and is
  done ONLY in cases when illegal or inappropriate content is discovered and
  needs to be removed. Because content may be replicated to other nodes,
  a Member Node performing a compulsory delete must notify DataONE of the
  action to ensure any replicas are also removed. Otherwise the content
  may remain discoverable and accessible at other nodes.


Note that the Tier 3 MN_Storage API implements requirements 4, 5, and 6, and
exposes that functionality to authorized users. Tier 1 and 2 member nodes
still implement the same functionality, however they do not expose the
functionality through the DataONE MN_Storage API. Instead, creates, updates,
and archives are handled through non-DataONE mechanisms.