DECADE                                                             Y. Gu
Internet-Draft                                                    Huawei
Intended status: Informational                                  D. Bryan
Expires: September 13, 2012 February 7, 2013                                  Polycom, Inc.
                                                                 Y. Yang
                                                         Yale University
                                                                P. Zhang
                                                Tsinghua University/Yale
                                                              University
                                                                R. Alimi
                                                                  Google
                                                          March 12,
                                                          August 6, 2012

                          DECADE Requirements
                       draft-ietf-decade-reqs-06
                       draft-ietf-decade-reqs-07

Abstract

   The target of the DECoupled Application Data Enroute (DECADE) system
   is to provide an open and standard in-network storage system for
   applications, primarily P2P (peer-to-peer) applications, to store,
   retrieve and manage their data.  This draft enumerates and explains
   requirements, not only for storage and retrieval, but also for data
   management, access control and resource control, that should be
   considered during the design and implementation of a DECADE-
   compatible system.  These are requirements on the entire system; some
   of the requirements may eventually be implemented by an existing
   protocol with/without some extensions (e.g., a protocol used to read
   and write data from the storage system).  The requirements in this
   document are intended to ensure that a DECADE-compatible system
   architecture includes all of the desired functionality for intended
   applications.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 13, 2012. February 7, 2013.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
   2.  Terminology and Concepts . . .  . . . . . . . . . . . . . . . .  6
   3.  Requirements Structure . . . . . . . . .  6
     2.1.  DECADE-compatible Client . . . . . . . . . . .  7
   4.  Protocol Requirements . . . . . .  6
     2.2.  DECADE-compatible Server . . . . . . . . . . . . . .  7
     4.1.  Overall Protocol Requirements . . .  6
     2.3.  DECADE Storage Provider  . . . . . . . . . . .  7
       4.1.1.  Connectivity Concerns . . . . . .  6
     2.4.  DECADE Account . . . . . . . . . .  7
         4.1.1.1.  NATs and Firewalls . . . . . . . . . . . .  6
     2.5.  Resource Provider  . . . .  8
         4.1.1.2.  Connections to Clients . . . . . . . . . . . . . .  8
       4.1.2.  Security . .  6
     2.6.  Resource Consumer  . . . . . . . . . . . . . . . . . . . .  6
     2.7.  Content Distribution Application .  8
         4.1.2.1.  Secure Transport . . . . . . . . . . . .  6
     2.8.  Target Application . . . . .  8
         4.1.2.2.  Gaming Prevention . . . . . . . . . . . . . . .  7
     2.9.  Application End-Point  .  8
       4.1.3.  Error and Failure Conditions . . . . . . . . . . . . .  9
         4.1.3.1.  Overload Condition . . . .  7
     2.10. Data Object  . . . . . . . . . . . .  9
         4.1.3.2.  Insufficient Resources . . . . . . . . . . .  7
     2.11. DECADE-compatible System . . .  9
         4.1.3.3.  Unavailable and Deleted Data . . . . . . . . . . . 10
         4.1.3.4.  Insufficient Permissions . . .  7
     2.12. DECADE Resource Protocol (DRP) Functions . . . . . . . . .  7
     2.13. DECADE Standard Data Transfer Protocol (SDT) Functions . 10
         4.1.3.5.  Redirection .  7
   3.  System and Protocol Components . . . . . . . . . . . . . . . .  8
   4.  Requirements Structure . . 10
     4.2.  Transfer Requirements . . . . . . . . . . . . . . . . . . 11
       4.2.1.  9
   5.  Data Object Size Requirements . . . . . . . . . . . . . . . . . . . 11
     4.3.  9
     5.1.  Data Access Requirements . Name Uniqueness . . . . . . . . . . . . . . . . 11
       4.3.1.  Reading/Writing Own Storage . . .  9
     5.2.  Verifiable Name-Object Binding . . . . . . . . . . 11
       4.3.2.  Access by Remote Clients . . . . 10
     5.3.  Data Object Size . . . . . . . . . . . 11
       4.3.3.  Negotiable Data Transport Protocol . . . . . . . . . . 12
       4.3.4.  Separation of 10
     5.4.  Data and Control Policies  . . Object Attributes . . . . . 12
     4.4.  Data Management Requirements . . . . . . . . . . . . . 10
     5.5.  Application-defined Object Properties and Metadata . . 12
       4.4.1.  Agnostic of reliability . . 11
   6.  Access and Authorization Requirements  . . . . . . . . . . . . 11
     6.1.  Provider Access  . 12
       4.4.2.  Data Object Attributes . . . . . . . . . . . . . . . . 13
       4.4.3.  Time-to-live for Written Data Objects . . . . 11
     6.2.  Secure Authorization . . . . 13
       4.4.4.  Application-defined Properties and Metadata . . . . . 13
       4.4.5.  Offline Usage . . . . . . . . . . 11
     6.3.  Consumer Access  . . . . . . . . . . 14
     4.5.  Data Naming Requirements . . . . . . . . . . . 12
     6.4.  Provider Authorization When Offline  . . . . . . 14
       4.5.1.  Unique Names . . . . . 12
     6.5.  Local Authorization  . . . . . . . . . . . . . . . . 14
     4.6.  Resource Control . . . 12
     6.6.  Access Control Granularity . . . . . . . . . . . . . . . . 12
     6.7.  Default Access Permissions . . 15
       4.6.1.  Multiple Applications . . . . . . . . . . . . . . 12
     6.8.  Connectivity Supporting NAT and Firewall Traversal . . 15
       4.6.2.  Per-Remote-Client, Per-Data Control . . 13
     6.9.  DECADE Server Discovery  . . . . . . . 15
       4.6.3.  Resource Control Set . . . . . . . . . . 13
   7.  Data Transfer Requirements . . . . . . . 16
       4.6.4.  Server Involvement . . . . . . . . . . . 13
     7.1.  Negotiable Standard Data Transport Protocol  . . . . . . . 16
     4.7.  Authorization 13
     7.2.  Atomic or Partial Read/Write . . . . . . . . . . . . . . . 14
     7.3.  Secure Data Transport  . . . . . . . 16
       4.7.1.  Per-Remote-Client, Per-Data Read Access . . . . . . . 16
       4.7.2.  Per-User Write Access . . . . 14
     7.4.  Concurrent Read  . . . . . . . . . . . . 17
       4.7.3.  Default Access Permissions . . . . . . . . . 14
     7.5.  Concurrent Write . . . . . 17
       4.7.4.  Authorization Checks . . . . . . . . . . . . . . . . . 17
       4.7.5.  Cryptographic Credentials  . . . . . . . . . . . . . . 17
       4.7.6.  Server Involvement . . . . . 14
     7.6.  Read Before Write Complete . . . . . . . . . . . . . 18
       4.7.7.  Protocol Reuse . . . 15
     7.7.  Redirection of Transport . . . . . . . . . . . . . . . . . 18
   5.  Storage 15
   8.  Resource Control Requirements  . . . . . . . . . . . . . . . . 16
     8.1.  Multiple Applications Sharing Resources  . . . . . 18
     5.1.  Immutable Data . . . . . . 16
     8.2.  Per-Client Resource Policy . . . . . . . . . . . . . . . . 18
     5.2.  Explicit Deletion of Data 16
     8.3.  Distributed Resource Sharing Specification . . . . . . . . 16
     8.4.  Resource Set . . . . . . . . 19
     5.3.  Multiple writing . . . . . . . . . . . . . . . 17

   9.  Error and Failure Handling Requirements  . . . . . . 19
     5.4.  Multiple reading . . . . . 17
     9.1.  Illegal Data Object  . . . . . . . . . . . . . . . . 19
     5.5.  Reading before completely written . . . 17
     9.2.  Invalid Access Authorization . . . . . . . . . 19
     5.6.  Writing model . . . . . . 18
     9.3.  Insufficient Resources . . . . . . . . . . . . . . . . 20
     5.7.  Storage Status . . 18
     9.4.  Overload Condition . . . . . . . . . . . . . . . . . . . . 20
   6.  Discovery Requirements 18
     9.5.  Attack Mitigation  . . . . . . . . . . . . . . . . . . . . 21
     6.1. 19
   10. Management Info Requirements . . . . . . . . . . . . . . . . . 19
     10.1. Account Status . . . . . . 21
       6.1.1.  Support for Clients Behind NATs and Firewalls  . . . . 21
       6.1.2.  Prefer Existing Protocols . . . . . . . . . . . . . . 21
   7. 19
   11. Security Considerations  . . . . . . . . . . . . . . . . . . . 21
     7.1. 19
     11.1. Authentication and Authorization . . . . . . . . . . . . . 21
     7.2.  Encrypted Data 20
     11.2. Confidentiality  . . . . . . . . . . . . . . . . . . . . . 20
     11.3. Attack Mitigation  . 22
     7.3.  Protection against Gaming . . . . . . . . . . . . . . . . 22
   8. . . . 20
   12. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 22
   9. 20
   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
     9.1. 20
     13.1. Normative References . . . . . . . . . . . . . . . . . . . 22
     9.2. 20
     13.2. Informative References . . . . . . . . . . . . . . . . . . 22 20
   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 23 21
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 21

1.  Introduction

   The object of the DECoupled Application Data Enroute (DECADE) system
   is to provide an open and standard in-network storage for content
   distribution applications, where data is typically broken into one or
   more chunks and then distributed.  This may already include many
   types of applications including P2P applications, IPTV (Internet
   Protocol Television), and VoD (Video on Demand).  (For a precise
   definition of the applications targeted in DECADE system, see the
   definition for Target Application in Section 2.)  Instead of always
   transferring data directly from a source/owner client to a requesting
   client, the source/owner client can write to and manage its content
   on its in-network storage.  The requesting client can get the address
   of the in-network storage pertaining to the source/owner client and
   read data from the storage.

   This draft enumerates and explains the rationale behind specific
   requirements on the protocol design and on any data store
   implementation that may be used to implement DECADE servers that
   should be considered during the design and implementation of a
   DECADE-compatible system.  As such, it does not include general
   guiding principles.  General design considerations, explanation of
   the problem being addressed, and enumeration of the types of
   applications to which a DECADE-compatible system may be suited is not
   considered in this document.  For general information, please see
   [I-D.ietf-decade-problem-statement] and [I-D.ietf-decade-arch].

   This document enumerates the requirements to enable target
   applications to utilize in-network storage.  In this context, using
   storage resources includes not only basic capabilities such as
   writing, reading, and managing data, but also controlling access for
   particular remote clients with which it is sharing data.
   Additionally, we also consider controlling the resources used by
   remote clients when they access data as an integral part of utilizing
   the network storage.

   This document discusses requirements pertaining to DECADE-compatible
   protocol(s).  In certain deployments, several logical in-network
   storage systems could be deployed (e.g., within the same
   administrative domain).  These in-network storage systems can
   communicate and transfer data through internal or non-standard
   communication messages that are outside of the scope of these
   requirements, but they should use DECADE-compatible protocol(s) when
   communicating with other DECADE-compatible in-network storage
   systems.

2.  Terminology and Concepts

   This document uses the term 'In-network storage' which is defined in
   [I-D.ietf-decade-problem-statement].

   This document also defines these additional terminology:

   Target Application: An application (typically installed at end-hosts)
   with the ability to explicitly control usage of network terms:

2.1.  DECADE-compatible Client

   A DECADE-compatible client uploads and/or
   storage resources to deliver content to a large number of users.
   This includes scenarios where multiple applications or entities
   cooperate, such as with P2P, CDN, and hybrid P2P/CDN architectures.
   Such applications distribute large amounts of content (e.g., a large
   file, or video stream) by dividing retrieves data from DECADE-
   compatible servers.  We use the content into smaller blocks
   for more flexible distribution (e.g., over multiple application-level
   paths).  The distributed content shorter term "client" if there is immutable (though it may be
   deleted no
   ambiguity.

2.2.  DECADE-compatible Server

   A DECADE-compatible server stores data inside the network, and
   thereafter manages both the stored data and replaced). access to those data.  We
   use the shorter term Target Application to refer
   to the type of applications that are explicitly (but not exclusively)
   supported by "server" if there is no ambiguity.

2.3.  DECADE system.

   DECADE-compatible server: Storage Provider

   A physical entity that can control and
   manage in-network storage DECADE Storage Provider, or a logical control and management
   component on in-network storage. Storage Provider for short, deploys
   and/or manages DECADE-compatible client: server(s) within a network.

2.4.  DECADE Account

   An interface for target applications to
   make use account of in-network storage in DECADE system.  DECADE client is
   usually a software hosted DECADE-compatible server has associated cryptographic
   credentials for access control, and resource allocation attributes on a end device, such as a PC or laptop.
   the server.

2.5.  Resource Provider

   A
   DECADE-compatible client be employed by a target applications to
   communicate with DECADE server to make use which has the account cryptographic credentials of in-network storage.

   DECADE-compatible protocol: A protocol between a DECADE-compatible
   client and DECADE
   account at a DECADE-compatible server.  In this document, a DECADE-
   compatible protocol represents  We use the protocols, both existing and
   potential new protocols, that can be used by a DECADE-compatible short term
   "Provider" if there is no ambiguity.

2.6.  Resource Consumer

   A client and DECADE-compatible server to communicate with each other.

   DECADE service provider: the provider who provides DECADE service which tries to access a DECADE-compatible client. DECADE service provider can be account but does not have the
   account's cryptographic credentials.  We use the short term
   "Consumer" if there is no ambiguity.

2.7.  Content Distribution Application

   A Content Distribution Application is an in-
   network storage provider, application (e.g., P2P,
   traditional CDN, or service provider who serve users hybrid P2P/CDN) designed for dissemination of
   DECADE-compatible clients by renting a
   large amounts of content (e.g., files, or purchasing in-network storage
   from in-network storage provider.

   DECADE-compatible system: video streams) to multiple
   content consumers.  Content Distribution Applications may divide
   content into smaller blocks for dissemination.

2.8.  Target Application

   An application with that includes a system which is composed DECADE-compatible client along
   with other application functionalities to explicitly control the
   usage of resources of DECADE-
   compatible clients, DECADE-compatible servers and in-network storage. to deliver content to
   other users.  A DECADE-compatible protocol is used for communication between
   DECADE-compatible clients primary type of Target Application we consider is
   Content Distribution Applications.  A Target Application divides
   content into smaller blocks for more flexible distribution (e.g.,
   over multiple application-level paths).  We use the term Target
   Application to refer to the type of applications that are explicitly
   (but not exclusively) supported by DECADE system.

2.9.  Application End-Point

   An Application End-Point is an instance of a Target Application.  A
   particular Application End-Point might be a Provider, a Consumer, or
   both.  For example, an Application End-Point might be an instance of
   a video streaming client, or it might be the source providing the
   video to a set of clients.

2.10.  Data Object

   A data object is the unit of data stored and retrieved from a DECADE-
   compatible server.  The data object is a string of raw bytes.  The
   server maintains metadata associated with each data object, but the
   metadata is not included in the data object.

2.11.  DECADE-compatible servers. System

   A system which is composed of DECADE-compatible clients, DECADE-
   compatible servers and in-network storage.  A DECADE-compatible
   system MUST obey all the requirements defined in this document.

3.  Requirements Structure

2.12.  DECADE Resource Protocol (DRP) Functions

   A DECADE-compatible protocol is intended to sit between Target
   Applications set of functions for communication of access control and resource
   scheduling policies from a storage system.  This document does not intend DECADE client to
   develop yet another storage system or a new protocol, but rather to
   explore the requirements for the server, as well as
   between servers.

2.13.  DECADE protocols, either existing
   ones or Standard Data Transfer Protocol (SDT) Functions

   A set of functions to be used to transfer data objects to and from a potential new one,
   DECADE server.

3.  System and storage Protocol Components

   To organize requirements, we consider that a DECADE-compatible system to enable Target
   Applications to make use
   consists of storage within the network, leaving
   specific storage system considerations to the implementation two logical sets of the
   storage servers as much functions, as possible.  For this reason, shown in Figure 1.  The
   first set of functions, which we have
   divided refer to as the DECADE Resource
   Protocol (DRP) functions, is responsible for communication of access
   control and resource scheduling policies from a client to a server,
   as well as between servers.  A DECADE-compatible system will include
   exactly one DRP for interoperability and a common format through
   which these policies can be communicated.

                         Native Application
         .-------------.      Protocol(s)     .-------------.
         | Application | <------------------> | Application |
         |  End-Point  |                      |  End-Point  |
         |             |                      |             |
         | .--------.  |                      | .--------.  |
         | | DECADE |  |                      | | DECADE |  |
         | | Client |  |                      | | Client |  |
         | `--------'  |                      | `--------'  |
         `-------------'                      `-------------'
             |     ^                              |     ^
     DECADE  |     | Standard                     |     |
    Resource |     |   Data                   DRP |     | SDT
    Protocol |     | Transfer                     |     |
     (DRP)   |     |   (SDT)                      |     |
             |     |                              |     |
             |     |                              |     |
             |     |                              |     |
             |     |                              |     |
             |     |                              |     |
             |     |                              |     |
             v     V                              v     V
         .=============.         DRP          .=============.
         |   DECADE    | <------------------> |   DECADE    |
         |   Server    | <------------------> |   Server    |
         `============='         SDT          `============='

              Figure 1: Protocol Components and Generic Flow

   Second, the second set of functions, referred to as the Standard Data
   Transfer (SDT) functions, will be used to transfer data objects to
   and from a server.  A DECADE-compatible system may support multiple
   SDT's.  If there are multiple SDT's, a negotiation mechanism will be
   used to determine a suitable SDT between the client and server.

   The two sets of functions (DRP and SDT) will be either separate or
   combined on the wire.  If they are combined, DRP messages can be
   piggy-backed within some extension fields provided by certain SDT
   protocols.  In such a scenario, DRP is technically a data structure
   (transported by other protocols), but it can still be considered as a
   logical protocol that provides the services of configuring DECADE-
   compatible resource usage.  If the protocols are physically separate
   on the wire, DRP can take the form of a separate control connection
   open between the a DECADE-compatible client and server.  Hence, this
   document considers SDT and DRP as two separate, logical functional
   components for clarity.

4.  Requirements Structure

   This document specifies the requirements into for the DECADE DRP and SDT
   functions, either existing ones or new ones, and storage system to
   enable Target Applications to make use of storage within the network,
   leaving specific storage system considerations to the implementation
   of the storage servers as much as possible.  For this reason, we
   consider two primary categories: categories of requirements:

   o  Protocol Requirements: Protocol requirements for Target
      Applications to make use of in-network storage within their own
      data dissemination schemes.  Development of these requirements is
      guided by a study of data access, search and management
      capabilities used by Target Applications.  These requirements may
      be met by a combination of existing protocols and new protocols.

   o  Storage Requirements: Functional requirements necessary for the
      back-end storage system employed by the DECADE server.
      Development of these requirements is guided by a study of the data
      access patterns used by Target Applications.  These requirements
      should be met by the underlying data transport used by DECADE
      system.  In this document, we use "data transport" to refer to a
      protocol used to read and write data from in-network storage.

   This specification discusses the requirements of functionality
   implemented with a storage system and within applications, to permit
   interoperable communications concerning the manipulation of stored
   content.

4.  Protocol

5.  Data Object Requirements

   This section details the requirements of DECADE-compatible
   protocol(s) that can be used in a DECADE-compatible system
   implementation.  The DECADE protocols can be existing protocols, as
   long as they satisfy the requirements specified in this document, or
   a new protocol which must obey all the requirements too.

4.1.  Overall Protocol Requirements

4.1.1.  Connectivity Concerns
4.1.1.1.  NATs and Firewalls

5.1.  Data Name Uniqueness
   REQUIREMENT(S):  Each Data Object should be named to allow access.
       DECADE-compatible protocol(s) MUST be usable across
       firewalls and NAT (Network Address Translation) devices.  DECADE
       protocol MUST NOT pass literal IP addresses in messages.

   RATIONALE:  Firewalls and NATs are widely used in the Internet today,
       both in ISP (Internet Service Provider) and Enterprise networks
       and by consumers.  Deployment of support a DECADE-compatible system must
       not require modifications to such devices (beyond, perhaps,
       reconfiguration).  This requirement applies to both potential new
       protocol data object naming
       scheme that may ensures a high probability of uniqueness, with no
       coordination among multiple Storage Providers.  In other words,
       two Data Objects with the same name should be developed by the DECADE Working Group and
       any data transport used same content
       with DECADE protocol.

4.1.1.2.  Connections to Clients

   REQUIREMENT(S):  Network connections between DECADE-compatible client
       and high probability.  A DECADE-compatible server MUST SHOULD be initiated by the client
       (i.e., the server must not initiate a connection with the
       client).

   RATIONALE:  Many household networks and operating systems have
       firewalls and NATs configured by default able
       to respond to block incoming
       connections.  To ease deployment by avoiding configuration
       changes and help mitigate security risks, a DECADE-compatible client must with an error indicating
       potential name conflicts.

   RATIONALE:  Although the intention of unique names is to avoid name
       collisions, it does not be required have to listen for any incoming network
       connections (beyond what be an absolutely zero
       possibility.  Hence, it is required by any other already-
       deployed application).

4.1.2.  Security

4.1.2.1.  Secure Transport

   REQUIREMENT(S):  A secure transport MUST be implemented for all
       communications between to provide a collision
       handling mechanism.

   EXCEPTION:  While a DECADE-compatible client and DECADE-
       compatible server. server is overloaded or
       consider a request as an attack, it does not to generate a
       response to indicate name collisions.

5.2.  Verifiable Name-Object Binding

5.3.  Data Object Size

   REQUIREMENT(S):  DECADE MUST allow for efficient storage and data
       transfer of small data objects (e.g., 16KB) without large control
       overhead.

   RATIONALE:  Though Target Applications may wish are frequently used to write sensitive data.  To
       satisfy this use case, share
       large amounts of data (e.g., continuous streams or large files),
       the communication between a DECADE-
       compatible client and DECADE-compatible server must be
       transported over a secure transport protocol data itself is typically subdivided into smaller data objects
       (chunks) for flexibility (e.g., SSL/TLS).

4.1.2.2.  Gaming Prevention reliability and multi-path
       transmission).

5.4.  Data Object Attributes

   REQUIREMENT(S):  A DECADE-compatible server  DECADE MUST be permitted to
       reject suspicious requests and not be required support the ability to generate
       responses (e.g., if associate a client's rate set
       of requests exceeds system attributes with a pre-
       defined threshold).

   RATIONALE:  Malicious clients may attempt to attack data object with a DECADE-
       compatible server by specifying many chunks scope local to increase total
       throughput or inciting overload conditions.  A a
       DECADE-compatible
       server is permitted to reject or ignore requests that are deemed
       suspicious according to policies server.  In particular, the set by its DECADE service
       provider.

4.1.3.  Error MUST include
       time-to-live (or expiration time), creation timestamp, object
       size, and Failure Conditions

4.1.3.1.  Overload Condition

   REQUIREMENT(S): object type.  A DECADE-compatible server, which is operating close
       to its capacity limit (e.g., too busy servicing other requests), client, with access
       permission, MUST be permitted able to reject requests query the set of system attributes.
       The transmission of the attributes MUST use an operating system-
       independent and not be required to
       generate response architecture-independent standard format.  An
       ability to additional requests.  A DECADE-compatible
       server extend the set of attributes MUST also be permitted to redirect requests (see Section
       4.1.3.5) as a load- shedding technique. exist.

   RATIONALE:  Forcing  The values of attributes associated with a DECADE-compatible server to respond to requests
       when operating close to its capacity can impair its ability to
       service existing requests, and thus is permitted to avoid
       generating response to additional requests.

4.1.3.2.  Insufficient Resources

   REQUIREMENT(S):  A DECADE-compatible server SHOULD be able to provide
       an error condition indicating data object
       are local to a particular DECADE-compatible client that
       resources (e.g., storage space) were not available to service a
       request (e.g., storage quota exceeded when attempting to write
       data).

   RATIONALE:  The currently-used resource levels within the in-network
       storage server.  These
       attributes may not be locally-discoverable.  In order used as hints to allocate
       resources appropriately amongst remote clients, the storage system, internal
       optimizations, or as additional information query-able by DECADE-
       compatible clients.  The particular requirement for including
       time-to-live (TTL) is that a data object written by a DECADE-
       compatible client must may be able to determine when resource limits
       have been reached.  The DECADE-compatible client usable only within a certain window of
       time, such as in a live-streaming P2P application.  Providing a
       time-to-live value for a data object (e.g., at the time it is
       written) can then respond reduce management overhead by explicitly freeing necessary resources or waiting for such
       resources avoiding many 'delete'
       commands sent to be freed.

   EXCEPTION:  While a DECADE-compatible server.  The server is in may still
       retain a data object for bandwidth optimization, but this should
       be guided by the situation that
       is described in Section 4.1.2.2 or Section 4.1.3.1, it need not
       to respond with error condition.

4.1.3.3.  Unavailable privacy policy of the DECADE Storage Provider.

5.5.  Application-defined Object Properties and Deleted Data Metadata

   REQUIREMENT(S):  A  DECADE-compatible server SHOULD clients and DECADE-compatible
       servers MUST NOT be able to provide
       error conditions indicating that (1) associate Application-defined
       properties (metadata) with data was rejected from being
       written, (2) deleted, or (3) marked unavailable objects beyond what is provided
       by a storage
       provider. Section 5.4.

   RATIONALE:  DECADE service providers may require the ability  Associating key-value pairs that are defined by Target
       Applications with data objects introduces substantial complexity.
       If Target Applications wish to associate additional metadata with
       a data object, possible alternatives include (1)
       avoid storing, managing such
       metadata within the Target Application itself, (2) delete, storing
       metadata inside the data object, or (3) quarantine certain data that
       has been identified as illegal (or otherwise prohibited).  It is
       not specified how such storing metadata in a
       different data is identified, but applications
       employing object at the DECADE-compatible servers should not break if a storage
       provider is obligated to enforce such policies.  Appropriate
       error conditions should server.

6.  Access and Authorization Requirements

6.1.  Provider Access

   REQUIREMENT(S):  A Provider MUST be indicated able to applications.

   EXCEPTION:  A access the resources of
       its account.

   RATIONALE:  After a DECADE-compatible server client owns an account on a
       DECADE-compatible server, it should be able to configured
       as not respond to any request to access unavailable or deleted read data on from and
       write data to the in- network storage, for example, for security
       reasons.

4.1.3.4.  Insufficient Permissions server.

6.2.  Secure Authorization

   REQUIREMENT(S):  A DECADE-compatible  Access to an account on a server MUST be able to provide
       error conditions indicating that the requesting client does not
       have sufficient permissions granted to access requested data objects.
       a provider based on cryptographic security.

   RATIONALE:  DECADE-compatible clients may request objects to which
       they do not have sufficient be operating on hosts
       without constant network connectivity or without a permanent
       attachment address (e.g., mobile devices).  To support access permissions, and DECADE-
       compatible
       control with such hosts, DECADE-compatible servers must be able to signal support
       access control policies that this has occurred. use cryptographic credentials, not
       simply by tying access to IP addresses.

6.3.  Consumer Access permissions may

   REQUIREMENT(S):  A Provider MUST be insufficient due able to indicate to its server on
       whether a combination of
       the credentials presented Consumer can access its subscribed resources.

   RATIONALE:  Endpoints in Target Applications may choose different
       servers.  Thus, to be useful by Target Applications, a DECADE-
       compatible client as well as additional
       policies defined by the storage provider.

4.1.3.5.  Redirection

   REQUIREMENT(S):  A DECADE-compatible server SHOULD must be able to
       redirect requests to another specify policies on whether
       other DECADE-compatible server.  This clients can access its resources.  The
       other clients may
       either be in response to an error, failure, or overload
       condition, or to support capabilities such as load balancing.

   RATIONALE:  A DECADE-compatible server may opt not be known to redirect requests the server.

6.4.  Provider Authorization When Offline

   REQUIREMENT(S):  A Provider MUST be able to another server grant access to support capabilities such as load balancing,
       or a
       Consumer even if the implementation decides that another DECADE-compatible
       server Provider is in a better position to handle the request due not actively running or
       connected to
       either its location in the network, server status, or other
       consideration.

   EXCEPTION:  A DECADE-compatible server server.

   RATIONALE:  If an application desires, it can be configured by its
       service provider authorize other clients
       to support access its storage even after the application exits or not support redirection
       functionality.

4.2.  Transfer Requirements

4.2.1.  Data Object Size network
       connectivity is lost.  An example use case is mobile scenarios,
       where a client can lose and regain network connectivity often.

6.5.  Local Authorization

   REQUIREMENT(S):  DECADE-compatible protocol(s)  A Provider MUST allow be able to indicate, without
       contacting its server, access control policies for
       efficient data transfer of small objects (e.g., 16KB) between a Consumers.
       DECADE-compatible client and in-network storage with minimal
       additional latency imposed by the protocol(s).

   RATIONALE:  Though Target Applications are frequently used server MUST be able to share
       large amounts of data (e.g., continuous streams or large files), authenticate the data itself access
       control policies in this situation.

   RATIONALE:  This requirement is typically subdivided into smaller chunks that
       are transferred between clients.  Additionally, clients may be
       sensitive to related with the delivery time of chunks (e.g., preceding
       requirement, but in a live-
       streaming application).  DECADE-compatible protocol(s) must
       enable data to be efficiently transferred amongst DECADE-
       compatible clients at this granularity.

4.3.  Data perspective (i.e., protocol design).  See
       discussions in Section 8.3.

6.6.  Access Requirements

4.3.1.  Reading/Writing Own Storage Control Granularity

   REQUIREMENT(S):  DECADE-compatible protocol(s)  A Provider MUST enable a DECADE-
       compatible client be able to read data from and write data control which individual
       clients are authorized to read/write which particular data
       objects from/to its own in-
       network in-network storage.

   RATIONALE:  Two basic capabilities for any storage system are reading
       and writing data.  A DECADE-compatible client can read Target Application should able to conduct access
       control on the granularity of individual clients, individual data from
       and
       objects.

6.7.  Default Access Permissions
   REQUIREMENT(S):  Unless read or write data access is granted by a
       Provider, the default permission MUST be no access.

   RATIONALE:  This requirement is to in-network storage space that it owns.

4.3.2.  Access protect client privacy by Remote Clients default.

6.8.  Connectivity Supporting NAT and Firewall Traversal

   REQUIREMENT(S):  A DECADE-compatible client MUST be able that is authorized to apply access control policies a server MUST
       be supported to remote conduct NAT (Network Address Translation) and
       firewall traversal.  In particular, network connections between a
       DECADE-compatible clients other
       than itself for its storage.  The remote client and a DECADE-compatible
       clients with whom access is being shared can server MUST be under a different
       administrative domain than
       initiated by the DECADE-compatible client who owns (i.e., the in-network storage. server must not initiate a
       connection to the client).

   RATIONALE:  Endpoints  Firewalls and NATs are widely used in Target Applications may be located across
       multiple ISPs under multiple administrative domains.  Thus, to be
       useful the Internet today,
       both in ISP (Internet Service Provider) and Enterprise networks
       and by Target Applications, consumers.  Many firewalls and NATs are configured by
       default to block incoming connections, which helps to mitigate
       security risks.  Deployment of a DECADE-compatible client system must be
       able
       not require manual modifications to specify access control policies for remote DECADE-
       compatible clients such devices.  This
       requirement applies to both potential new protocol that may or may not be known to
       developed by the client's
       own DECADE service provider.

4.3.3. Working Group and any data transport used
       with DECADE protocol.

6.9.  DECADE Server Discovery

   REQUIREMENT(S):  A mechanism for a Provider to discover and connect
       to its assigned server MUST be supported.  The discovery SHOULD
       leverage existing mechanisms and protocols wherever possible.  No
       new discovery mechanism will be defined unless there is enough
       evidence that no existing mechanism can work.

   RATIONALE:  Existing protocols such as DNS and DHCP are widespread.
       Using existing protocols, or combinations of the protocols that
       have been specified in other contexts, is strictly preferred over
       developing a new discovery protocol.

7.  Data Transfer Requirements

7.1.  Negotiable Standard Data Transport Protocol

   REQUIREMENT(S):  A DECADE-compatible client MUST be able to negotiate
       with DECADE a DECADE-compatible server about which protocol it can use
       to read data from and write data to its in-network storage. data.  DECADE system MUST specify at least
       one mandatory transport protocol to be supported by
       implementations; usage of a different protocol may be selected
       via negotiation.

   RATIONALE:  Since typical data transport protocols (e.g., NFS and
       WebDAV) already provide read and write operations for network
       storage, it may not be necessary to define such operations in a
       new DECADE protocol.  However, because of the particular
       application requirements and deployment considerations, different
       applications may support different protocols.  Thus, a DECADE
       client must be able to select an appropriate protocol also
       supported by the in-network storage.  This requirement also
       follows as a result of the requirement of Separation of Control
       and Data Operations (Section 4.3.4).

4.3.4.  Separation of Data and Control Policies

7.2.  Atomic or Partial Read/Write

   REQUIREMENT(S):  A DECADE-compatible protocol(s) server MUST provide a minimal
       set of core operations to support diverse policies implemented
       and desired by Target Applications, and the ability
       to read/write a complete data object in one request.  It MAY provide additional
       operations.
       support range read/write.

   RATIONALE:  Depending on the object size (e.g., chunk size) used by a
       Target Applications support many complex behaviors and
       diverse policies Application, the application may need to control and distribute data, such as (e.g.,
       search, index, setting permissions/passing authorization tokens).
       Thus, to support such Target Applications, these behaviors must
       be logically separated from the data transfer operations (e.g.,
       read, write).  Some minimal overlap (for example obtaining
       credentials needed to encrypt or authorize send data transfer using
       control operations) is required to be supported by DECADE-
       compatible protocol(s).

4.4. the
       DECADE-compatible server in multiple round.

7.3.  Secure Data Management Requirements

4.4.1.  Agnostic of reliability Transport

   REQUIREMENT(S):  DECADE-compatible protocol(s)  A secure transport MUST remain agnostic
       of reliability/ fault-tolerance level offered by DECADE service
       provider.

   RATIONALE:  Providers of a DECADE service may wish to offer varying
       levels of service be implemented for different applications/users.  However, all
       communications between a
       single DECADE-compatible client must be able and DECADE-
       compatible server.

   RATIONALE:  Target Applications may wish to write sensitive data.  To
       satisfy this use multiple
       DECADE services with differing levels of service.

4.4.2.  Data Object Attributes

   REQUIREMENT(S):  DECADE-compatible protocol(s) MUST support case, the
       ability to associate attributes with data objects with a scope
       local to communication between a DECADE-compatible server, DECADE-
       compatible client and for DECADE-compatible
       clients to query these attributes. DECADE-compatible protocol(s)
       MUST transmit any attributes using an operating system-
       independent and architecture-independent standard format.  If
       there is a need to design any DECADE protocols, they MUST be
       designed such that new attributes can server must be added by later
       transported over a secure transport protocol
       revisions or extensions.

   RATIONALE: (e.g., SSL/TLS).

7.4.  Concurrent Read

   REQUIREMENT(S):  A DECADE-compatible client can associate attributes
       (e.g., a time-to- live, creation timestamp, or object size) with server MUST allow for multiple
       simultaneous readers for a data object.  These attributes are local

   RATIONALE:  One characteristic of Target Applications is the ability
       to a data upload an object
       stored by a particular DECADE-compatible server, and are thus not
       applied to any multiple clients.  Thus, it is natural for
       DECADE-compatible server or client to which allow multiple readers to read the
       data
       same object is copied.  These attributes may be used as hints to
       the storage system, internal optimizations, or as additional
       information query-able by DECADE-compatible clients.

4.4.3.  Time-to-live for Written Data Objects concurrently.

7.5.  Concurrent Write

   REQUIREMENT(S):  A DECADE-compatible client server MUST be able to indicate
       a time-to- live value (or expiration time) indicating a length of
       time until particular data can be deleted by a DECADE-compatible
       server.

   RATIONALE:  Some data objects written by a DECADE-compatible client
       may be usable only within a certain window of time, such as in
       live- streaming P2P applications.  Providing a time-to-live value NOT allow multiple
       simultaneous writers for data objects (e.g., at the time they are written) can reduce
       management overhead by avoiding many 'delete' commands sent to same object.  A DECADE-compatible server.  The in-network storage may still keep
       the data in cache for bandwidth optimization.  But this is guided
       by the privacy policy
       server SHOULD respond to each of the DECADE service provider.

4.4.4.  Application-defined Properties and Metadata
   REQUIREMENT(S):  DECADE-compatible clients and DECADE-compatible
       servers MUST NOT be able to associate Application-defined
       properties (metadata) writers with data objects beyond what is provided
       by Section 4.4.2. an error.

   RATIONALE:  Associating key-value pairs that are defined by Target
       Applications with data objects introduces substantial complexity
       to the protocol(s).  If Target Applications wish to associate
       additional metadata with a data object, possible alternatives
       include (1) managing such metadata within the Target Application
       itself, (2) storing metadata inside of the  This avoids data object, or (3)
       storing metadata corruption in a different data object at simple way while
       remaining efficient.  Alternately, the DECADE-
       compatible server.

4.4.5.  Offline Usage

   REQUIREMENT(S):  A DECADE-compatible client MAY provide authorized
       access from remote clients server
       would need to its in-network storage even if the
       DECADE client is actively running either manage locking, handle write collisions, or connected to a DECADE-
       compatible server.

   RATIONALE:  If an application desires, it can authorize remote
       clients to access its storage even after the application exits or
       network connectivity is lost.  An example use case is mobile
       scenarios, where a client can lose and regain network
       connectivity very often.

4.5.  Data Naming Requirements

4.5.1.  Unique Names

   REQUIREMENT(S):  DECADE-compatible protocol(s) MUST support a data
       object naming scheme that ensures a high probability
       merge data, all of
       uniqueness which reduce efficiency and supports the operation of DECADE-compatible
       servers under diverse administrative domains with no
       coordination.  DECADE-compatible server SHOULD be able to respond
       to DECADE-compatible client with error condition indicating the
       name of the object conflicts with other object.

   RATIONALE:  When writing a data object, a DECADE-compatible Client
       should be able to write it without being concerned over whether
       an object of the same name already exists, unless the existing
       object contains the exact same data.  Although the intention is
       to avoid name collision, it's not absolutely zero possibility.
       As a result, it is required to provide a collision handling
       mechanism. increase
       complexity.

   EXCEPTION:  While a DECADE-compatible server is in situations
       described in Section 4.1.2.2 overloaded or Section 4.1.3.1,
       considers a request as an attack, it need does not to generate a response to the client.

4.6.  Resource Control

4.6.1.  Multiple Applications
       response.

7.6.  Read Before Write Complete

   REQUIREMENT(S):  A DECADE-compatible client MUST be able to indicate
       to a DECADE-compatible server about resource sharing policies for
       multiple target applications being run/managed by the same user.

   RATIONALE:  A user may own in-network storage and share the in-
       network storage resources amongst multiple target applications.
       For example, the user may run one or more video-on-demand
       application(s) and a live-streaming application(s) which both
       make use of the user's in-network storage.  The applications may
       be running on different machines and may not directly
       communicate.  Thus, user should be able to determine resource
       sharing policies between the applications.

       One possibility is for a user to indicate the particular resource
       sharing policies between applications out-of-band (not using a
       standard protocol), but this requirement may manifest itself in
       passing values within DECADE-compatible protocol(s) to identify
       individual applications.  Such identifiers can be either user-
       generated or server-generated and do not need to be registered by
       IANA.

4.6.2.  Per-Remote-Client, Per-Data Control

   REQUIREMENT(S):  A DECADE-compatible client MUST be able to assign
       resource policies (bandwidth share, storage quota, and network
       connection quota) to individual remote clients for reading from
       and writing particular data to its in-network storage within a
       particular range of time.

   RATIONALE:  Target Applications can rely on control of resources on a
       per-remote-client or per-data basis.  For example, application
       policy may indicate that certain remote clients have a higher
       bandwidth share for receiving data [LLSB08].  Additionally,
       bandwidth share for receiving data [LLSB08].  Additionally,
       certain data (e.g., chunks) may be distributed with MAY allow readers to read
       a higher
       priority.  As another example, when allowing data object before it has been completely written.  In case of
       a remote client to write data to error in such a user's in-network storage, case, the remote DECADE-compatible server SHOULD
       respond to the reading client may with an error indicating that the
       write has failed.

   RATIONALE:  Some Target Applications (in particular, P2P streaming)
       can be restricted sensitive to write less than 100MB of latency.  A technique to reduce latency is to
       remove store-and-forward delays for data in total.  Since objects (e.g., make the client may need
       object available before it is completely written).  Appropriate
       handling for error conditions (e.g., a disappearing writer) needs
       to manage multiple clients accessing its
       data, be specified.

   EXCEPTION:  While a DECADE-compatible server is overloaded or
       considers a request as an attack, it should does not generate a
       response.

7.7.  Redirection of Transport

   REQUIREMENT(S):  A DECADE-compatible server SHOULD be able to indicate the time over which the
       granted resources are usable.  For example, an expiration time
       for the access could
       redirect requests to another DECADE-compatible server.  This may
       either be indicated in response to the an error, failure, overload, or to
       support capabilities such as load balancing.

   RATIONALE:  A DECADE-compatible server
       after which no resources are granted (e.g., indicate error may opt to redirect requests
       to another server to support capabilities such as
       access denied).

4.6.3.  Resource Control Set

   REQUIREMENT(S): load balancing,
       or if the implementation decides that another DECADE-compatible protocol(s) MUST define
       server is in a minimum
       set of resource control methods, and MAY add additional set of
       resource control methods.

   RATIONALE:  The minimum set of resource control methods need better position to
       include handle the request due to
       either its location in the most common resource control methods.  Implementors network, server status, or other
       consideration.

   EXCEPTION:  A DECADE-compatible server can add proprietary set of resource control methods in their own
       implementation.

4.6.4.  Server Involvement be configured by its
       service provider to support or not support redirection
       functionality.

8.  Resource Control Requirements

8.1.  Multiple Applications Sharing Resources

   REQUIREMENT(S):  A DECADE-compatible client MUST be able to indicate to a DECADE-compatible server, without itself contacting the
       server, resource control policies for remote clients' requests.
       A DECADE-compatible DECADE-
       compatible server MUST be able to authenticate the about resource control sharing policies in this situation.

   RATIONALE:  One important consideration for a DECADE-compatible
       server is scalability, since a single storage element may be used
       to support many users.  Many among multiple
       Target Applications use small chunk
       sizes and frequent data exchanges.  If such an application
       employed resource control and contacted being run/managed by the DECADE-compatible
       server for each data exchange, this could present same client.

   RATIONALE:  A client owning a scalability
       challenge for DECADE account may provide the server as well as additional latency for
       clients.

       The preferred way is
       account's cryptographic credentials to let requesting clients obtain signed
       resource control policies (in the form multiple Providers of a token) from
       multiple target applications.  For example, the
       owning client, client may run
       one or more video-on-demand application(s) and then requesting clients can present the policy
       to a DECADE-compatible server directly.  This can result in
       reduced messaging handled by live-streaming
       application(s) which both make use of the DECADE-compatible server.

4.7.  Authorization

4.7.1.  Per-Remote-Client, Per-Data Read Access client's in-network
       storage.  The concurrently running applications may be running on
       different machines (e.g., multiple machines at the same home
       network) and may not directly communicate, except through user
       coordination

8.2.  Per-Client Resource Policy

   REQUIREMENT(S):  A DECADE-compatible Client Provider MUST be able to control
       which individual remote clients are authorized specify resource policies
       (bandwidth share, storage quota, and network connection quota) to read particular
       data
       individual Consumers for reading from and writing data to its in-network storage. in-
       network storage within a particular range of time.

   RATIONALE:  A  Target Application Applications can rely on control of resources on a
       per-client basis.  For example, application policy may indicate
       that certain remote clients have a higher bandwidth share for
       receiving data [LLSB08].  Additionally, bandwidth share for
       receiving data [LLSB08].  Additionally, certain application-
       level policies by sending particular data (e.g.,
       chunks) to
       certain remote clients.

4.7.2.  Per-User Write Access

   REQUIREMENT(S):  A DECADE-compatible Client MUST may be able to control
       which individual remote clients are authorized to write data into
       its in-network storage.

   RATIONALE:  The space managed by distributed with a user in in-network storage can be higher priority.  As another
       example, when allowing a limited resource.  At the same time, it can be useful to allow remote clients client to write data directly to a user's
       in-network
       storage.  Thus, a DECADE-compatible storage, the remote client should may be able restricted to
       grant only certain remote clients this privilege.

4.7.3.  Default Access Permissions

   REQUIREMENT(S):  Unless read or write access is granted by a DECADE
       Client to a remote client, the default access MUST be no access.

   RATIONALE:  The current leading proposal for an access control model
       in DECADE working group is via token passing, resulting
       less than 100MB of data in a
       system with little state on the server side.

4.7.4.  Authorization Checks

   REQUIREMENT(S):  A DECADE-compatible server MUST check total.  Since the
       authorization of a client before it executes a supplied request.

   RATIONALE:  The data stored at a DECADE-compatible server is assumed may need to
       manage multiple clients accessing its data, it should be private, and thus not accessible able to a DECADE-enabled client
       unless it is explicitly
       indicate the time over which the granted permission.

4.7.5.  Cryptographic Credentials

   REQUIREMENT(S):  Access MUST resources are usable.
       For example, an expiration time for the access could be able indicated
       to be granted using
       cryptographic credentials.

   RATIONALE: the DECADE-compatible clients may be operating on hosts
       without constant network connectivity or without a permanent
       attachment address server after which no resources are
       granted (e.g., mobile devices).  To support access
       control with such hosts, DECADE-compatible servers must support
       access control policies that use cryptographic credentials, not
       simply by tying indicate error as access to IP addresses.

4.7.6.  Server Involvement denied).

8.3.  Distributed Resource Sharing Specification

   REQUIREMENT(S):  A DECADE-compatible client Provider MUST be able to indicate, indicate to its DECADE-
       compatible server, without itself contacting the server itself, access server, resource
       control policies for
       remote clients' requests. a Consumer.  The DECADE-compatible server
       MUST be able to authenticate the access resource control policies in this situation. policies.

   RATIONALE:  See discussion in Section 4.6.4.

4.7.7.  Protocol Reuse

   REQUIREMENT(S):  DECADE SHOULD reuse existing protocol and mechanisms  One important consideration for Authentication, Access, and Authorization (AAA).  No new AAA
       protocol and mechanism are going to be defined unless there a DECADE-compatible
       server is
       explicit proof that existing protocol scalability, since a single storage element may be used
       to support many users.  Many Target Applications use small chunk
       sizes and mechanisms are not
       applicable.

   RATIONALE: frequent data exchanges.  If possible, reusing such an existing AAA protocol/mechanism
       will minimize the development required by applications, application
       employed resource control and will
       maximize interoperability contacted the DECADE-compatible
       server for each data exchange, this could present a scalability
       challenge for the server as well as additional latency for
       clients.

       The preferred way is to let requesting clients obtain signed
       resource control policies (in the form of a token) from the
       owning client, and then requesting clients can present the policy
       to a DECADE-compatible protocol(s)
       with existing infrastructure.

5.  Storage Requirements server directly.  This section details can result in
       reduced messaging handled by the requirements DECADE-compatible server.

8.4.  Resource Set

   REQUIREMENT(S):  A DECADE-compatible server MUST allow specification
       on the following resources: storage, bandwidth, and number of
       connections, and MAY allow additional types of the underlying storage used resources to support DECADE-compatible protocol(s).

5.1.  Immutable be
       specified.

   RATIONALE:  The minimum set of resources need to include the most
       common resources.

9.  Error and Failure Handling Requirements

9.1.  Illegal Data Object

   REQUIREMENT(S):  The  A DECADE-compatible server SHOULD provide an error
       indicating that (1) data objects MUST be immutable once they are
       written to storage. was rejected from being written, (2)
       deleted, or (3) marked unavailable.

   RATIONALE:  Immutable  DECADE Storage Providers may require the ability to (1)
       avoid storing, (2) delete, or (3) quarantine certain data objects are an important simplification in that
       has been identified as illegal (or otherwise prohibited).  It is
       not specified how such data is identified, but applications
       employing DECADE-compatible system.  Reasonable consistency models for
       updating existing objects would significantly complicate
       implementation (especially servers should not break if implementation chooses a Storage
       Provider is obligated to replicate
       data across multiple servers).  If the content owners have enforce such policies.  Appropriate
       error conditions should be indicated to
       modify the written data objects, there are many ways applications.

   EXCEPTION:  A DECADE-compatible server should be able to do so.
       First, they can use different data names for different object
       versions.  Secondly, they can split single monolithic files into
       fragments, so that new fragment versions could be substituted
       later (e.g. corrections or updated advertising) via a play list.

5.2.  Explicit Deletion of
       configured to suppress Illegal Data Object responses for security
       reasons.

9.2.  Invalid Access Authorization

   REQUIREMENT(S):  A DECADE-compatible client MUST be able to
       explicitly delete data from its own in-network storage. server SHOULD provide an error
       indicating that the request does not have a valid access
       authorization.

   RATIONALE:  A  DECADE-compatible client clients may continually be writing request data objects to its in-network storage.  Since there may be
       which they do not have a limit
       (e.g., imposed by the storage provider) to how much total storage
       can valid authorization, and DECADE-
       compatible servers should be used, some data may need able to signal that this has
       occurred.  Invalid authorization may be removed due to make room for a combination of
       credential issues as well as additional data. policies defined by a
       Storage Provider.

   EXCEPTION:  A DECADE-compatible client server should be able to
       explicitly remove particular data.  This may be implemented using
       existing protocols.

5.3.  Multiple writing

   REQUIREMENT(S):  A DECADE-compatible server MUST NOT allow multiple
       simultaneous writers
       configured to suppress Invalid Authorization responses for the same object.
       security reasons.

9.3.  Insufficient Resources

   REQUIREMENT(S):  A DECADE-compatible server SHOULD respond to each of the writers with error condition provide a response
       indicating the attempt of simultaneous writing.

   RATIONALE:  This avoids data corruption in to a simple way while
       remaining efficient.  Alternately, the DECADE-compatible server
       would need client that resources (e.g.,
       storage space) were not available to service its request (e.g.,
       storage quota exceeded when attempting to either manage locking, handle write collisions, data).

   RATIONALE:  The Insufficient Resources response allows a client to
       back off, free up necessary resources or
       merge data, all of which reduce efficiency and increase
       complexity. waiting for such
       resources to be freed.

   EXCEPTION:  While a  A DECADE-compatible server is in the situation that
       is described in Section 4.1.2.2 or Section 4.1.3.1, it need may not
       generate provide such a response.

5.4.  Multiple reading

   REQUIREMENT(S):  A DECADE-compatible server MUST allow for multiple
       simultaneous readers for an object.

   RATIONALE:  One characteristic of Target Applications is
       response if doing so increases the ability
       to upload an object to multiple clients.  Thus, it is natural for
       DECADE-compatible server to allow multiple readers load or due to read the
       content concurrently.

5.5.  Reading before completely written security
       concerns.

9.4.  Overload Condition

   REQUIREMENT(S):  A DECADE-compatible server MAY allow readers server, which is operating close
       to read
       from objects before they have been completely written.  In case
       of object writing error, DECADE-compatible server SHOULD its capacity limit (e.g., too busy servicing other requests),
       MUST be permitted to reject requests and not be able required to respond
       generate response to the reading additional requests.  A DECADE-compatible client with error
       condition indicating that the object writing is failed.

   RATIONALE:  Some Target Applications (in particular, P2P streaming)
       can
       server MUST also be sensitive to latency.  A technique permitted to reduce latency is redirect requests (see Section
       4.1.3.5) as a load-shedding technique.

   RATIONALE:  The Insufficient Resources response allows a client to
       remove store-and-forward delays for data objects (e.g., make the
       object available before it is completely written).  Appropriate
       handling
       back off, free up necessary resources or waiting for error conditions (e.g., a disappearing writer) needs such
       resources to be specified. freed.

   EXCEPTION:  While a  A DECADE-compatible server is in the situation that
       is described in Section 4.1.2.2 or Section 4.1.3.1, it need may not
       generate provide such a response.

5.6.  Writing model
       response if doing so increases the load or due to security
       concerns.

9.5.  Attack Mitigation

   REQUIREMENT(S):  A DECADE-compatible server MUST provide at least a
       writing model (while writing an object) that appends data be permitted to data
       already written.

   RATIONALE:  Depending on the object size
       reject suspicious requests and not be required to generate
       responses (e.g., chunk size) used by if a
       Target Application, the application client's rate of requests exceeds a pre-
       defined threshold).

   RATIONALE:  Malicious clients may need to send data attempt to the
       DECADE-compatible attack a DECADE-
       compatible server in multiple packets.  To keep
       implementation simple, the by specifying many chunks to increase total
       throughput or inciting overload conditions.  A DECADE-compatible
       server must at least
       support the ability to write the data sequentially in the order
       received.  Implementations MAY allow application is permitted to write data in
       an object out-of-order (but MUST NOT overwrite ranges of the
       object reject or ignore requests that have already been written).

5.7.  Storage are deemed
       suspicious according to policies set by its DECADE service
       provider.

10.  Management Info Requirements

10.1.  Account Status

   REQUIREMENT(S):  A DECADE-compatible server Provider MUST be able to respond
       resource usage and query the resource quotas.  A minimum set of storage
       status supported by DECADE-compatible quota
       as well the current usage.  The response from the server MUST
       include resource usage resulting from both the client's own usage (including
       list of written data objects)
       and usage by other clients that have been authorized to read/write read/
       write objects on that client's
       storage.  A DECADE-compatible server MUST be able to authenticate
       the request. account.

   RATIONALE:  The resources used by a client are not necessarily
       directly-attached (e.g., disk, network interface, etc).  Thus,
       the client cannot locally determine how such much resources are being
       used.  Before storing and retrieving data, a client should be
       able to determine which data is available (e.g., after an
       application restart).

6.  Discovery Requirements

6.1.  Requirements

6.1.1.  Support for Clients Behind NATs and Firewalls

   REQUIREMENT(S):  The mechanism for discovering a DECADE-compatible
       server MUST be operable by DECADE-compatible clients operating
       behind NATs and Firewalls.

   RATIONALE:  NATs and Firewalls are prevalent in network deployments,
       and it is common for Target Applications that include a DECADE-
       compatible client to be deployed behind these devices.

6.1.2.  Prefer Existing Protocols

   REQUIREMENT(S):  The mechanism for discovering a DECADE-compatible
       server SHOULD leverage existing mechanisms and protocols wherever
       possible.  No new discovery mechanism will be defined unless
       there is enough evidence that no existing mechanism can work.

   RATIONALE:  Existing protocols such as DNS and DHCP are widespread.
       Using existing protocols, or combinations of the protocols that
       have been specified in other contexts, is strictly preferred over
       developing a new discovery protocol.

7.

11.  Security Considerations

   The security model is an important component of a DECADE-compatible
   system.  It is crucial for users to be able to manage and limit
   distribution of content to only authorized parties, and the mechanism
   needs to work on the general Internet which spans multiple
   administrative and security domains.  Previous sections have
   enumerated detailed requirements, but this section discusses the
   overall approach and other considerations that do not merit
   requirements.

7.1.

11.1.  Authentication and Authorization

   A DECADE-compatible server must authenticate any DECADE-compatible
   client that attempts validate an request to access the in-network in-
   network storage.  DECADE-
   compatible server is not involved in the authorization between DECADE
   clients and remote clients, or the authorization between DECADE
   system user and DECADE service provider.  In order to authenticate an
   accessing DECADE client, a DECADE-compatible server may need to
   accept the authentication and authorization referral by another
   DECADE-compatible client.

7.2.  Encrypted Data

11.2.  Confidentiality

   DECADE-compatible Servers provide the ability to write raw data
   objects (subject to any policies instituted by the owner/
   administrator of the service provider). Storage Provider).  Thus, DECADE-compatible
   clients may opt to encrypt data before it is transported to the
   server.  However, DECADE-compatible protocol(s) do not provide
   encryption of data objects other than that provided by
   Section 4.1.2.1.

7.3.  Protection against Gaming

11.3.  Attack Mitigation

   The particular resource control policy communicated by DECADE-
   compatible protocol(s) and enforced on DECADE-compatible server may be open to certain gaming attacks
   by clients.  For example by specifying many small chunks to increase
   total throughput or inciting overload conditions are techniques that
   may be used by a client.

8.

12.  IANA Considerations

   There are no IANA considerations with this document.

9.

13.  References

9.1.

13.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [I-D.ietf-decade-problem-statement]
              Song, H., Zong, N., Yang, Y., and R. Alimi, "DECoupled
              Application Data Enroute (DECADE) Problem Statement",
              draft-ietf-decade-problem-statement-03 (work in progress),
              March 2011.

9.2.

13.2.  Informative References

   [I-D.ietf-decade-arch]
              Alimi, R., Yang, Y., Rahman, A., Kutscher, D., and H. Liu,
              "DECADE Architecture", draft-ietf-decade-arch-02 (work in
              progress), July 2011.

   [LLSB08]   Levin, D., LaCurts, K., Spring, N., and B. Bhattacharjee,
              "BitTorrent is an Auction: Analyzing and Improving
              BitTorrent's Incentives", SIGCOMM 2008, August 2008.

   [PPLive]   "PPLive", <http://www.pplive.com>.

Appendix A.  Acknowledgments

   We would also like to thank Haibin Song for substantial contributions
   to earlier versions of this document.  We would also like to thank
   Reinaldo Penno, Alexey Melnikov, Rich Woundy, Ning Zong, Roni Even,
   David McDysan, Borje Ohlman, Dirk Kutscher, Akbar Rahman, Xiao Zhu,
   Yunfei Zhang, Peng Zhang and Jin Peng for contributions and general
   feedback.

Authors' Addresses

   Yingjie Gu
   Huawei
   No. 101 Software Avenue
   Nanjing, Jiangsu Province  210012
   P.R.China

   Phone: +86-25-56624760
   Email: guyingjie@huawei.com

   David A. Bryan
   Polycom, Inc.

   Email: dbryan@ethernot.org

   Yang Richard Yang
   Yale University

   Email: yry@cs.yale.edu

   Peng Zhang
   Tsinghua University/Yale University

   Email: p.zhang@yale.edu
   Richard Alimi
   Google

   Email: ralimi@google.com