draft-ietf-decade-reqs-00.txt   draft-ietf-decade-reqs-01.txt 
DECADE Y. Gu DECADE Y. Gu
Internet-Draft Huawei Internet-Draft Huawei
Intended status: Informational D. Bryan Intended status: Informational D. Bryan
Expires: April 21, 2011 Cogent Force, LLC / Huawei Expires: September 15, 2011 Cogent Force, LLC / Huawei
Y. Yang Y. Yang
Yale University Yale University
R. Alimi R. Alimi
Google Google
October 18, 2010 March 14, 2011
DECADE Requirements DECADE Requirements
draft-ietf-decade-reqs-00 draft-ietf-decade-reqs-01
Abstract Abstract
The target of DECoupled Application Data Enroute (DECADE) is to The target of DECoupled Application Data Enroute (DECADE) is to
provide an open and standard in-network storage system for provide an open and standard in-network storage system for
applications, primarily P2P applications, to store, retrieve and applications, primarily P2P applications, to store, retrieve and
manage their data. This draft enumerates and explains requirements, manage their data. This draft enumerates and explains requirements,
not only for store and retrieve, but also for data management, access not only for store and retrieve, but also for data management, access
control and resource control, that should be considered during the control and resource control, that should be considered during the
design and implementation of a DECADE system. These are requirements design and implementation of a DECADE system. These are requirements
skipping to change at page 2, line 10 skipping to change at page 2, line 10
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 21, 2011. This Internet-Draft will expire on September 15, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology and Concepts . . . . . . . . . . . . . . . . . . . 5 2. Terminology and Concepts . . . . . . . . . . . . . . . . . . . 5
3. Requirements Structure . . . . . . . . . . . . . . . . . . . . 6 3. Requirements Structure . . . . . . . . . . . . . . . . . . . . 6
4. Protocol Requirements . . . . . . . . . . . . . . . . . . . . 7 4. Protocol Requirements . . . . . . . . . . . . . . . . . . . . 7
4.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7
4.1.1. Overall Protocol Requirements . . . . . . . . . . . . 7 4.1.1. Overall Protocol Requirements . . . . . . . . . . . . 7
4.1.1.1. Application-independent API . . . . . . . . . . . 7 4.1.1.1. Cross-platform Access . . . . . . . . . . . . . . 7
4.1.1.2. Cross-platform Access . . . . . . . . . . . . . . 7 4.1.1.2. Connectivity Concerns . . . . . . . . . . . . . . 7
4.1.1.3. Connectivity Concerns . . . . . . . . . . . . . . 7 4.1.1.2.1. NATs and Firewalls . . . . . . . . . . . . . . 7
4.1.1.3.1. NATs and Firewalls . . . . . . . . . . . . . . 7 4.1.1.2.2. Connections to Clients . . . . . . . . . . . . 7
4.1.1.3.2. Connections to Clients . . . . . . . . . . . . 8 4.1.1.3. Error and Failure Conditions . . . . . . . . . . . 8
4.1.1.4. Error and Failure Conditions . . . . . . . . . . . 8 4.1.1.3.1. Overload Condition . . . . . . . . . . . . . . 8
4.1.1.4.1. Overload Condition . . . . . . . . . . . . . . 8 4.1.1.3.2. Insufficient Resources . . . . . . . . . . . . 8
4.1.1.4.2. Insufficient Resources . . . . . . . . . . . . 8 4.1.1.3.3. Unavailable and Deleted Data . . . . . . . . . 8
4.1.1.4.3. Unavailable and Deleted Data . . . . . . . . . 9 4.1.1.3.4. Redirection . . . . . . . . . . . . . . . . . 9
4.1.2. Transfer and Latency Requirements . . . . . . . . . . 9 4.1.2. Transfer and Latency Requirements . . . . . . . . . . 9
4.1.2.1. Low-Latency Access . . . . . . . . . . . . . . . . 9 4.1.2.1. Low-Latency Access . . . . . . . . . . . . . . . . 9
4.1.2.2. Indirect Transfer . . . . . . . . . . . . . . . . 9 4.1.2.2. Indirect Transfer . . . . . . . . . . . . . . . . 9
4.1.2.3. Data Object Size . . . . . . . . . . . . . . . . . 10 4.1.2.3. Data Object Size . . . . . . . . . . . . . . . . . 10
4.1.2.4. Communication among In-network Storage Elements . 10 4.1.2.4. Communication among In-network Storage Elements . 10
4.1.3. Data Access Requirements . . . . . . . . . . . . . . . 10 4.1.3. Data Access Requirements . . . . . . . . . . . . . . . 10
4.1.3.1. Reading/Writing Own Storage . . . . . . . . . . . 10 4.1.3.1. Reading/Writing Own Storage . . . . . . . . . . . 10
4.1.3.2. Access by Other Users . . . . . . . . . . . . . . 10 4.1.3.2. Access by Other Users . . . . . . . . . . . . . . 10
4.1.3.3. Negotiable Data Protocol . . . . . . . . . . . . . 11 4.1.3.3. Negotiable Data Protocol . . . . . . . . . . . . . 11
4.1.3.4. Separation of Data Operations from Application 4.1.3.4. Separation of Data Operations from Application
Control . . . . . . . . . . . . . . . . . . . . . 11 Control . . . . . . . . . . . . . . . . . . . . . 11
4.1.4. Data Management Requirements . . . . . . . . . . . . . 12 4.1.4. Data Management Requirements . . . . . . . . . . . . . 12
4.1.4.1. Agnostic of reliability . . . . . . . . . . . . . 12 4.1.4.1. Agnostic of reliability . . . . . . . . . . . . . 12
4.1.4.2. Time-to-live for Stored Data . . . . . . . . . . . 12 4.1.4.2. Time-to-live for Stored Data . . . . . . . . . . . 12
4.1.4.3. Offline Usage . . . . . . . . . . . . . . . . . . 12 4.1.4.3. Offline Usage . . . . . . . . . . . . . . . . . . 12
4.1.5. Resource Control . . . . . . . . . . . . . . . . . . . 12 4.1.5. Resource Control . . . . . . . . . . . . . . . . . . . 12
4.1.5.1. Multiple Applications . . . . . . . . . . . . . . 12 4.1.5.1. Multiple Applications . . . . . . . . . . . . . . 12
4.1.5.2. Per-Peer, Per-Data Control . . . . . . . . . . . . 13 4.1.5.2. Per-Remote-Client, Per-Data Control . . . . . . . 13
4.1.5.3. Server Involvement . . . . . . . . . . . . . . . . 13 4.1.5.3. Server Involvement . . . . . . . . . . . . . . . . 13
4.1.6. Authorization . . . . . . . . . . . . . . . . . . . . 14 4.1.6. Authorization . . . . . . . . . . . . . . . . . . . . 14
4.1.6.1. Per-Peer, Per-Data Read Access . . . . . . . . . . 14 4.1.6.1. Per-Remote-Client, Per-Data Read Access . . . . . 14
4.1.6.2. Per-User Write Access . . . . . . . . . . . . . . 14 4.1.6.2. Per-User Write Access . . . . . . . . . . . . . . 14
4.1.6.3. Authorization Checks . . . . . . . . . . . . . . . 15 4.1.6.3. Authorization Checks . . . . . . . . . . . . . . . 15
4.1.6.4. Credentials Not IP-Based . . . . . . . . . . . . . 15 4.1.6.4. Credentials Not IP-Based . . . . . . . . . . . . . 15
4.1.6.5. Server Involvement . . . . . . . . . . . . . . . . 15 4.1.6.5. Server Involvement . . . . . . . . . . . . . . . . 15
5. Storage Requirements . . . . . . . . . . . . . . . . . . . . . 15 5. Storage Requirements . . . . . . . . . . . . . . . . . . . . . 15
5.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 15 5.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 15
5.1.1. Explicit Deletion of Stored Data . . . . . . . . . . . 15 5.1.1. Explicit Deletion of Stored Data . . . . . . . . . . . 15
5.1.2. Multiple writing . . . . . . . . . . . . . . . . . . . 16 5.1.2. Multiple writing . . . . . . . . . . . . . . . . . . . 16
5.1.3. Multiple reading . . . . . . . . . . . . . . . . . . . 16 5.1.3. Multiple reading . . . . . . . . . . . . . . . . . . . 16
5.1.4. Reading before completely written . . . . . . . . . . 16 5.1.4. Reading before completely written . . . . . . . . . . 16
5.1.5. Writing model . . . . . . . . . . . . . . . . . . . . 16 5.1.5. Hints concerning usage stored data . . . . . . . . . . 16
5.1.6. Storage Status . . . . . . . . . . . . . . . . . . . . 17 5.1.6. Writing model . . . . . . . . . . . . . . . . . . . . 17
5.1.7. Storage Status . . . . . . . . . . . . . . . . . . . . 17
5.2. Non-Requirements . . . . . . . . . . . . . . . . . . . . . 17 5.2. Non-Requirements . . . . . . . . . . . . . . . . . . . . . 17
5.2.1. No ability to update . . . . . . . . . . . . . . . . . 17 5.2.1. No ability to update . . . . . . . . . . . . . . . . . 18
6. Implementation Considerations . . . . . . . . . . . . . . . . 17 6. Implementation Considerations . . . . . . . . . . . . . . . . 18
6.1. Resource Scheduling . . . . . . . . . . . . . . . . . . . 17 6.1. Resource Scheduling . . . . . . . . . . . . . . . . . . . 18
6.2. Removal of Duplicate Records . . . . . . . . . . . . . . . 18 6.2. Removal of Duplicate Records . . . . . . . . . . . . . . . 18
7. Discussion and Open Issues . . . . . . . . . . . . . . . . . . 18 7. Discussion and Open Issues . . . . . . . . . . . . . . . . . . 19
7.1. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 18 7.1. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 19
7.2. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 18 7.2. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 19
8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
10.1. Normative References . . . . . . . . . . . . . . . . . . . 19 10.1. Normative References . . . . . . . . . . . . . . . . . . . 20
10.2. Informative References . . . . . . . . . . . . . . . . . . 19 10.2. Informative References . . . . . . . . . . . . . . . . . . 20
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 20 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
The object of DECoupled Application Data Enroute (DECADE) is to The object of DECoupled Application Data Enroute (DECADE) is to
provide an open and standard in-network storage system for provide an open and standard in-network storage system for
applications, primarily applications that could be implemented using applications, primarily applications that could be implemented using
a content distribution paradigm, where data is broken in to one or a content distribution paradigm, where data is broken in to one or
more chunks and then distributed. This may already include many more chunks and then distributed. This may already include many
types of applications including P2P applications, IPTV, and VoD. types of applications including P2P applications, IPTV, and VoD.
Instead of always transferring data directly from a source-owner peer Instead of always transferring data directly from a source/owner
to a requesting peer, the source-owner peer can store and manage its client to a requesting client, the source/owner client can store and
content on its in-network storage. The requesting peer can get the manage its content on its in-network storage. The requesting client
address of the in-network storage pertaining to the source-owner peer can get the address of the in-network storage pertaining to the
and retrieve data from the storage. source/owner client and retrieve data from the storage.
This draft enumerates and explains the rationale behind SPECIFIC This draft enumerates and explains the rationale behind SPECIFIC
requirements on the protocol design and on any data store requirements on the protocol design and on any data store
implementation that may be used to implement DECADE servers that implementation that may be used to implement DECADE servers that
should be considered during the design and implementation of a DECADE should be considered during the design and implementation of a DECADE
system. As such, it DOES NOT include general guiding principals. system. As such, it DOES NOT include general guiding principals.
General design considerations, explanation of the problem being General design considerations, explanation of the problem being
addressed, and enumeration of the types of applications to which addressed, and enumeration of the types of applications to which
DECADE may be suited is not considered in this document. For general DECADE may be suited is not considered in this document. For general
information, please see the problem statement information, please see the problem statement
[I-D.ietf-decade-problem-statement] and architecture drafts. [I-D.ietf-decade-problem-statement] and architecture drafts.
This document enumerates the requirements to enable target This document enumerates the requirements to enable target
applications to utilize in-network storage. In this context, using applications to utilize in-network storage. In this context, using
storage resources includes not only basic capabilities such as storage resources includes not only basic capabilities such as
storing and retrieving data, and managing data, but also (1) storing and retrieving data, and managing data, but also (1)
controlling access by peers with which it is sharing data and (2) controlling access for particular remote clients with which it is
controlling the resources used by remote peers when accessing data. sharing data and (2) controlling the resources used by remote clients
when they access data.
This document will be updated to track revisions to the problem
statement.
Editors Note: Currently the Architecture document is a WG milestone,
but not yet a WG item. We have made the assumption that there will
be a WG item meeting this milestone going forward.
2. Terminology and Concepts 2. Terminology and Concepts
This document uses terms defined in This document uses terms defined in
[I-D.ietf-decade-problem-statement]. In particular, IAP refers to [I-D.ietf-decade-problem-statement]. In particular, IAP refers to
the In-network storage Access Protocol, which is the protocol used to the In-network storage Access Protocol, which is the protocol used to
communicate between a DECADE client and DECADE server (in-network communicate between a DECADE client and DECADE server (in-network
storage) for access control and resource control. storage) for access control and resource control.
This document also defines additional terminology: This document also defines additional terminology:
Target Application: An application (typically installed at end-hosts) Target Application: An application (typically installed at end-hosts)
with the ability to explicitly control usage of network and/or with the ability to explicitly control usage of network and/or
storage resources to deliver contents to a large number of users. storage resources to deliver contents to a large number of users.
Such applications distribute large contents (e.g., a large file, or This includes scenarios where multiple applications or entities
video stream) by dividing the contents into smaller blocks for more cooperate, such as with P2P/CDN hybrid architectures. Such
applications distribute large contents (e.g., a large file, or video
stream) by dividing the contents into smaller blocks for more
flexible distribution (e.g., multipath). The distributed content is flexible distribution (e.g., multipath). The distributed content is
typically immutable (though it may be deleted). We use the term typically immutable (though it may be deleted). We use the term
Target Application to refer to the type of applications that are Target Application to refer to the type of applications that are
explicitly (but not exclusively) supported by DECADE. explicitly (but not exclusively) supported by DECADE.
3. Requirements Structure 3. Requirements Structure
The DECADE protocol is intended to sit between P2P applications and a The DECADE protocol is intended to sit between Target Applications
back-end storage system. In the development of DECADE, it must be and a back-end storage system. In the development of DECADE, it must
made clear that the intention is to NOT develop yet another storage be made clear that the intention is to NOT develop yet another
system, but rather to create a protocol that enables P2P applications storage system, but rather to create a protocol that enables Target
to make use of storage within the network, leaving specific storage Applications to make use of storage within the network, leaving
system considerations to the implementation of the DECADE servers as specific storage system considerations to the implementation of the
much as possible. For this reason, we have divided the requirements DECADE servers as much as possible. For this reason, we have divided
into three categories: the requirements into two categories:
o General Principles: Overall requirements that a DECADE system must
conform to.
o Protocol Requirements: Protocol requirements for Target o Protocol Requirements: Protocol requirements for Target
Applications to make use of in-network storage within their own Applications to make use of in-network storage within their own
data dissemination schemes. Development of these requirements is data dissemination schemes. Development of these requirements is
guided by a study of data access, search and management guided by a study of data access, search and management
capabilities used by Target Applications. capabilities used by Target Applications. These requirements may
be met by a new protocol to be defined within the DECADE Working
Group.
o Storage Requirements: Functional requirements necessary for the o Storage Requirements: Functional requirements necessary for the
back-end storage system employed by the DECADE server. back-end storage system employed by the DECADE server.
Development of these requirements is guided by a study of the data Development of these requirements is guided by a study of the data
access patterns used by Target Applications. access patterns used by Target Applications. These requirements
should be met by the underling data transport used by DECADE.
It should also be made clear that the approach is to make DECADE a It should also be made clear that the approach is to make DECADE a
simple protocol, while still enabling its usage within many P2P simple protocol, while still enabling its usage within many Target
applications. For this reason, and to further reinforce the Applications. For this reason, and to further reinforce the
distinction between DECADE and a storage system, in some cases we distinction between DECADE and a storage system, in some cases we
also highlight the non-requirements of the protocol. These non- also highlight the non-requirements of the protocol. These non-
requirements are intended to capture behaviors that will NOT be requirements are intended to capture behaviors that will NOT be
assumed to be needed by DECADE's Target Applications and hence not assumed to be needed by DECADE's Target Applications and hence not
present in the DECADE protocol. present in the DECADE protocol.
Finally, some implementation considerations are provided, which while Finally, some implementation considerations are provided, which while
strictly are not requirements, are intended to provide guidance and strictly are not requirements, are intended to provide guidance and
highlight potential points of concern that need to be considered by highlight potential points of concern that need to be considered by
the protocol developers, and later by implementors. the protocol developers, and later by implementors.
4. Protocol Requirements 4. Protocol Requirements
4.1. Requirements 4.1. Requirements
4.1.1. Overall Protocol Requirements 4.1.1. Overall Protocol Requirements
4.1.1.1. Application-independent API 4.1.1.1. Cross-platform Access
REQUIREMENT(S): The DECADE IAP MUST provide a simple, application-
independent API for P2P applications to access in-network
storage.
RATIONALE: Since the majority of existing P2P application APIs don't
support in-network storage management, new application-
independent API must be introduced. The API should be simple to
encourage adoption, as well as to ensure that a minimum set of
functions, and not an entire network storage system is
implemented.
4.1.1.2. Cross-platform Access
REQUIREMENT(S): If DECADE supports the ability to store metadata REQUIREMENT(S): If DECADE supports the ability to store metadata
associated with data objects, the DECADE protocol(s) MUST associated with data objects, the DECADE protocol(s) MUST
transmit any metadata using an operating system-independent and transmit any metadata using an operating system-independent and
architecture-independent format. architecture-independent format.
RATIONALE: If DECADE supports the possibility for storing metadata RATIONALE: If DECADE supports the possibility for storing metadata
(e.g., a description, uploaded date, or object size), a possible (e.g., a description, uploaded date, object size, or access
use for the metadata is to help a DECADE client locate a desired control list), a possible use for the metadata is to help a
data object. Data objects may be stored by DECADE clients DECADE client locate a desired data object. Data objects may be
running on various platforms. To enable metadata to be readable stored by DECADE clients running on various platforms. To enable
regardless of its source it must be transmitted to and from the metadata to be readable regardless of its source it must be
DECADE server in a standard format. transmitted to and from the DECADE server in a standard format.
4.1.1.3. Connectivity Concerns 4.1.1.2. Connectivity Concerns
4.1.1.3.1. NATs and Firewalls 4.1.1.2.1. NATs and Firewalls
REQUIREMENT(S): DECADE SHOULD be usable across firewalls and NATs REQUIREMENT(S): DECADE SHOULD be usable across firewalls and NATs
without requiring additional network support (e.g., Application- without requiring additional network support (e.g., Application-
level Gateways). level Gateways).
RATIONALE: Firewalls and NATs are widely used in the Internet today, RATIONALE: Firewalls and NATs are widely used in the Internet today,
both in ISP networks and within households. Deployment of DECADE both in ISP networks and within households. Deployment of DECADE
must not require modifications to such devices (beyond, perhaps, must not require modifications to such devices (beyond, perhaps,
reconfiguration). reconfiguration). Note that this requirement applies to both any
new protocol developed by the DECADE Working Group and any data
transport used with DECADE.
4.1.1.3.2. Connections to Clients 4.1.1.2.2. Connections to Clients
REQUIREMENT(S): DECADE SHOULD NOT require that network connections REQUIREMENT(S): DECADE SHOULD require that network connections be
be made to DECADE clients (e.g., from a server to a DECADE client made from DECADE clients to DECADE servers (i.e., not to the
or from a DECADE client to another DECADE client). DECADE client).
RATIONALE: Many household networks and operating systems have RATIONALE: Many household networks and operating systems have
firewalls and NATs configured by default. To ease deployment by firewalls and NATs configured by default. To ease deployment by
avoiding configuration changes and help mitigate security risks, avoiding configuration changes and help mitigate security risks,
DECADE should not require clients to listen for any incoming DECADE should not require clients to listen for any incoming
network connections (beyond what is required by any other network connections (beyond what is required by any other
already-deployed application). already-deployed application).
4.1.1.4. Error and Failure Conditions 4.1.1.3. Error and Failure Conditions
4.1.1.4.1. Overload Condition 4.1.1.3.1. Overload Condition
REQUIREMENT(S): In-network storage, which is operating close to its REQUIREMENT(S): In-network storage, which is operating close to its
capacity limit (e.g., too busy servicing other requests), MUST be capacity limit (e.g., too busy servicing other requests), MUST be
able to reject requests. able to reject requests and not be required to generate responses
to additional requests.
RATIONALE: When in-network storage is operating at a limit where it RATIONALE: When in-network storage is operating at a limit where it
may not be able to process additional requests, it should not be may not be able to process additional requests, it should not be
required to generate responses to such additional requests. required to generate responses to such additional requests.
Forcing the in-network storage to do so can impair its ability to Forcing the in-network storage to do so can impair its ability to
service existing requests. service existing requests.
4.1.1.4.2. Insufficient Resources 4.1.1.3.2. Insufficient Resources
REQUIREMENT(S): DECADE MUST support an error condition indicating to REQUIREMENT(S): DECADE MUST support an error condition indicating to
a DECADE client that resources (e.g., storage space) were not a DECADE client that resources (e.g., storage space) were not
available to service a request (e.g., storage quota exceeded when available to service a request (e.g., storage quota exceeded when
attempting to store data). attempting to store data).
RATIONALE: The currently-used resource levels within the in-network RATIONALE: The currently-used resource levels within the in-network
storage are not locally-discoverable, since the resources (disk, storage are not locally-discoverable, since the resources (disk,
network interfaces, etc) are not directly attached. In order to network interfaces, etc) are not directly attached. In order to
allocate resources appropriately amongst peers, a client must be allocate resources appropriately amongst remote clients, a client
able to determine when resource limits have been reached. The must be able to determine when resource limits have been reached.
client can then respond by explicitly freeing necessary resources The client can then respond by explicitly freeing necessary
or waiting for such resources to be freed. resources or waiting for such resources to be freed.
4.1.1.4.3. Unavailable and Deleted Data 4.1.1.3.3. Unavailable and Deleted Data
REQUIREMENT(S): DECADE MUST support error conditions indicating that REQUIREMENT(S): DECADE MUST support error conditions indicating that
(1) data was rejected from being stored, (2) deleted, or (3) (1) data was rejected from being stored, (2) deleted, or (3)
marked unavailable by a storage provider. marked unavailable by a storage provider.
RATIONALE: Storage providers may require the ability to (1) avoid RATIONALE: Storage providers may require the ability to (1) avoid
storing, (2) delete, or (3) quarantine certain data that has been storing, (2) delete, or (3) quarantine certain data that has been
identified as illegal (or otherwise prohibited). DECADE does not identified as illegal (or otherwise prohibited). DECADE does not
indicate how such data is identified, but applications using indicate how such data is identified, but applications using
DECADE should not break if a storage provider is obligated to DECADE should not break if a storage provider is obligated to
enforce such policies. Appropriate error conditions should be enforce such policies. Appropriate error conditions should be
indicated to applications. indicated to applications.
4.1.1.3.4. Redirection
REQUIREMENT(S): DECADE SHOULD support the ability for a DECADE
server to redirect requests to another DECADE server. This may
be in response to either an error or failure condition, or to
support capabilities such as load balancing.
RATIONALE: A DECADE server may opt to redirect requests to another
server to support capabilities such as load balancing, or if the
implementation decides that another DECADE server is in a better
position to handle the request due to either its location in the
network, server status, or other consideration.
4.1.2. Transfer and Latency Requirements 4.1.2. Transfer and Latency Requirements
4.1.2.1. Low-Latency Access 4.1.2.1. Low-Latency Access
REQUIREMENT(S): DECADE SHOULD provide "low-latency" access for REQUIREMENT(S): DECADE SHOULD provide "low-latency" access for
application clients. DECADE MUST allow clients to specify at application clients. DECADE MUST allow clients to specify at
least two classes of services for service: lowest possible least two classes of services for service: lowest possible
latency and latency non-critical. latency and latency non-critical.
RATIONALE: Some applications may have requirements on delivery time RATIONALE: Some applications may have requirements on delivery time
(e.g., live streaming). The user experience may be (e.g., live streaming [PPLive]). The user experience may be
unsatisfactory if the use of in-network storage results in lower unsatisfactory if the use of in-network storage results in lower
performance than connecting directly to peers over a low-speed, performance than connecting directly to remote clients over a
possibly congested uplink. Additionally, the overhead required low-speed, possibly congested uplink. Additionally, the overhead
for control-plane operations in DECADE must not cause the latency required for control-plane operations in DECADE must not cause
to be higher than for a low-speed, possibly congested uplink. the latency to be higher than for a low-speed, possibly congested
While it is impossible to make a guarantee that a system using uplink. While it is impossible to make a guarantee that a system
in-network storage will always outperform a system that does not using in-network storage will always outperform a system that
for every transfer, the overall performance of the system should does not for every transfer, the overall performance of the
be improved compared with direct connections, even considering system should be improved compared with direct connections, even
control overhead. considering control overhead.
4.1.2.2. Indirect Transfer 4.1.2.2. Indirect Transfer
REQUIREMENT(S): DECADE MUST allow a user's in-network storage to REQUIREMENT(S): DECADE MUST allow a user's in-network storage to
directly fetch from other user's in-network storage. directly fetch from other user's in-network storage.
RATIONALE: As an example, a requesting peer may get the address of RATIONALE: As an example, a requesting remote client may get the
the storage pertaining to the source-owner peer and then tell its address of the storage pertaining to the source/owner client and
own in-network storage to fetch the content from the source- then tell its own in-network storage to fetch the content from
owner's in-network storage. This helps to avoid extra transfers the source-owner's in-network storage. This helps to avoid extra
across ISP network links where possible. transfers across ISP network links where possible.
4.1.2.3. Data Object Size 4.1.2.3. Data Object Size
REQUIREMENT(S): DECADE MUST allow for efficient data transfer of REQUIREMENT(S): DECADE MUST allow for efficient data transfer of
small objects (e.g., 16KB) between a DECADE client and in-network small objects (e.g., 16KB) between a DECADE client and in-network
storage with minimal additional latency required by the protocol. storage with minimal additional latency required by the protocol.
RATIONALE: Though P2P applications are frequently used to share RATIONALE: Though Target Applications are frequently used to share
large amounts of data (e.g., continuous streams or large files), large amounts of data (e.g., continuous streams or large files),
the data itself is typically subdivided into smaller chunks that the data itself is typically subdivided into smaller chunks that
are transferred between peers. Additionally, the small chunks are transferred between clients. Additionally, the small chunks
may have requirements on delivery time (e.g., in a live-streaming may have requirements on delivery time (e.g., in a live-streaming
application). DECADE must enable data to be efficiently application). DECADE must enable data to be efficiently
transferred amongst peers at this granularity. transferred amongst clients at this granularity.
4.1.2.4. Communication among In-network Storage Elements 4.1.2.4. Communication among In-network Storage Elements
REQUIREMENT(S): DECADE SHOULD support the ability for two in-network REQUIREMENT(S): DECADE SHOULD support the ability for two in-network
storage elements in different administrative domains to store storage elements in different administrative domains to store
and/or retrieve data directly between each other. If such a and/or retrieve data directly between each other. If such a
capability is supported, this MAY be the same (or a subset or capability is supported, this MAY be the same (or a subset or
extension of) as the IAP used by clients to access data. extension of) as the IAP used by clients to access data.
RATIONALE: Allowing server-to-server communication can reduce RATIONALE: Allowing server-to-server communication can reduce
skipping to change at page 11, line 11 skipping to change at page 11, line 11
data to in-network storage space that it owns. data to in-network storage space that it owns.
4.1.3.2. Access by Other Users 4.1.3.2. Access by Other Users
REQUIREMENT(S): DECADE MUST support the ability for a user to apply REQUIREMENT(S): DECADE MUST support the ability for a user to apply
access control policies to users other than itself for its access control policies to users other than itself for its
storage. The users with whom access is being shared can be under storage. The users with whom access is being shared can be under
a different administrative domain than the user who owns the in- a different administrative domain than the user who owns the in-
network storage. The authorized users may read from or write to network storage. The authorized users may read from or write to
the user's storage. the user's storage.
RATIONALE: Peers in a P2P application may be located across multiple RATIONALE: Endpoints in Target Applications may be located across
ISPs under multiple administrative domains. Thus, to be useful multiple ISPs under multiple administrative domains. Thus, to be
by P2P applications, DECADE allows a user to specify access useful by Target Applications, DECADE allows a user to specify
control policies for users that may or may not be known to the access control policies for users that may or may not be known to
user's storage provider. the user's storage provider.
4.1.3.3. Negotiable Data Protocol 4.1.3.3. Negotiable Data Protocol
REQUIREMENT(S): DECADE MUST support the ability for a DECADE client REQUIREMENT(S): DECADE MUST support the ability for a DECADE client
to negotiate with its In-network storage about which protocol it to negotiate with its in-network storage about which protocol it
can use to read data from and write data to its In-network can use to read data from and write data to its In-network
storage. storage. DECADE MUST specify at least one mandatory 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 RATIONALE: Since typical data transport protocols (e.g., NFS and
WebDAV) already provide read and write operations for network WebDAV) already provide read and write operations for network
storage, it may not be necessary for DECADE to define such storage, it may not be necessary for DECADE to define such
operations in a new protocol. However, because of the particular operations in a new protocol. However, because of the particular
application requirements and deployment considerations, different application requirements and deployment considerations, different
applications may support different protocols. Thus, a DECADE applications may support different protocols. Thus, a DECADE
client must be able to select an appropriate protocol also client must be able to select an appropriate protocol also
supported by the in-network storage. This requirement also supported by the in-network storage. This requirement also
follows as a result of the requirement of Separation of Control follows as a result of the requirement of Separation of Control
skipping to change at page 11, line 48 skipping to change at page 11, line 50
core operations to support diverse policies implemented and core operations to support diverse policies implemented and
desired by Target Applications. desired by Target Applications.
RATIONALE: Target Applications support many complex behaviors and RATIONALE: Target Applications support many complex behaviors and
diverse policies to control and distribute data, such as (e.g., diverse policies to control and distribute data, such as (e.g.,
search, index, setting permissions/passing authorization tokens). search, index, setting permissions/passing authorization tokens).
Thus, to support such Target Applications, these behaviors must Thus, to support such Target Applications, these behaviors must
be logically separated from the data transfer operations (e.g., be logically separated from the data transfer operations (e.g.,
retrieve, store). Some minimal overlap (for example obtaining retrieve, store). Some minimal overlap (for example obtaining
credentials needed to encrypt or authorize data transfer using credentials needed to encrypt or authorize data transfer using
control operations) may be required to be directly supported by control operations) may be required to be directly specified by
DECADE. DECADE.
4.1.4. Data Management Requirements 4.1.4. Data Management Requirements
4.1.4.1. Agnostic of reliability 4.1.4.1. Agnostic of reliability
REQUIREMENT(S): DECADE SHOULD remain agnostic of reliability/ REQUIREMENT(S): DECADE SHOULD remain agnostic of reliability/
fault-tolerance level offered by storage provider. fault-tolerance level offered by storage provider.
RATIONALE: Providers of a DECADE service may wish to offer varying RATIONALE: Providers of a DECADE service may wish to offer varying
skipping to change at page 12, line 40 skipping to change at page 12, line 40
bandwidth optimization. But this is guided by the privacy policy bandwidth optimization. But this is guided by the privacy policy
of the DECADE provider. of the DECADE provider.
4.1.4.3. Offline Usage 4.1.4.3. Offline Usage
REQUIREMENT(S): DECADE MAY support the ability for a user to provide REQUIREMENT(S): DECADE MAY support the ability for a user to provide
authorized access to its in-network storage even if the user has authorized access to its in-network storage even if the user has
no DECADE applications actively running or connected to the no DECADE applications actively running or connected to the
network. network.
RATIONALE: If an application desires, it can authorize peers to RATIONALE: If an application desires, it can authorize remote
access its storage even after the application exits or network clients to access its storage even after the application exits or
connectivity is lost. An example use case is mobile scenarios, network connectivity is lost. An example use case is mobile
where a client can lose and regain network connectivity very scenarios, where a client can lose and regain network
often. connectivity very often.
4.1.5. Resource Control 4.1.5. Resource Control
4.1.5.1. Multiple Applications 4.1.5.1. Multiple Applications
REQUIREMENT(S): DECADE SHOULD support the ability for users to REQUIREMENT(S): DECADE SHOULD support the ability for users to
define resource sharing policies for multiple applications being define resource sharing policies for multiple applications
run/managed by the user. (DECADE clients) being run/managed by the user.
RATIONALE: A user may own in-network storage and share the in- RATIONALE: A user may own in-network storage and share the in-
network storage resources amongst multiple applications. For network storage resources amongst multiple applications. For
example, the user may run a video-on-demand application and a example, the user may run a video-on-demand application and a
live-streaming (or even two different live-streaming live-streaming (or even two different live-streaming
applications) application which both make use of the user's in- applications) application which both make use of the user's in-
network storage. The applications may be running on different network storage. The applications may be running on different
machines and may not directly communicate. Thus, DECADE should machines and may not directly communicate. Thus, DECADE should
enable the user to determine resource sharing policies between enable the user to determine resource sharing policies between
the applications. the applications.
One possibility is for a user to indicate the particular resource One possibility is for a user to indicate the particular resource
sharing policies between applications out-of-band (not using a sharing policies between applications out-of-band (not using a
standard protocol), but this requirement may manifest itself in standard protocol), but this requirement may manifest itself in
passing values over IAP to identify individual applications. passing values over IAP to identify individual applications.
Such identifiers can be either user-generated or server-generated Such identifiers can be either user-generated or server-generated
and do not need to be registered by IANA. and do not need to be registered by IANA.
4.1.5.2. Per-Peer, Per-Data Control 4.1.5.2. Per-Remote-Client, Per-Data Control
REQUIREMENT(S): A DECADE client MUST be able to assign resource REQUIREMENT(S): A DECADE client MUST be able to assign resource
quotas to individual peers for reading from and writing quotas to individual remote clients for reading from and writing
particular data to its in-network storage within a particular particular data to its in-network storage within a particular
range of time. The DECADE server MUST enforce these constraints. range of time. The DECADE server MUST enforce these constraints.
RATIONALE: P2P applications can rely on control of resources on a RATIONALE: Target Applications can rely on control of resources on a
per-peer or per-data basis. For example, application policy may per-remote-client or per-data basis. For example, application
indicate that certain peers have a higher bandwidth share for policy may indicate that certain remote clients have a higher
receiving data. Additionally, certain data (e.g., chunks) may be bandwidth share for receiving data [LLSB08]. Additionally,
distributed with a higher priority. As another example, when certain data (e.g., chunks) may be distributed with a higher
allowing a remote peer to write data to a user's in-network priority. As another example, when allowing a remote client to
storage, the remote peer may be restricted to write only a write data to a user's in-network storage, the remote client may
certain amount of data. Since the client may need to manage be restricted to write only a certain amount of data. Since the
multiple peers accessing its data, it should be able to indicate client may need to manage multiple clients accessing its data, it
the time over which the granted resources are usable. For should be able to indicate the time over which the granted
example, an expiration time for the access could be indicated to resources are usable. For example, an expiration time for the
the server after which no resources are granted (e.g., indicate access could be indicated to the server after which no resources
error as access denied). are granted (e.g., indicate error as access denied).
4.1.5.3. Server Involvement 4.1.5.3. Server Involvement
REQUIREMENT(S): A DECADE client MUST be able to indicate, without REQUIREMENT(S): A DECADE client MUST be able to indicate to a DECADE
contacting the server itself, resource control policies for server, without itself contacting the server, resource control
peers' requests. policies for remote clients' requests.
RATIONALE: One important consideration for in-network storage RATIONALE: One important consideration for in-network storage
elements is scalability, since a single storage element may be elements is scalability, since a single storage element may be
used to support many users. Many P2P applications use small used to support many users. Many Target Applications use small
chunk sizes and frequent data exchanges. If such an application chunk sizes and frequent data exchanges. If such an application
employed resource control and contacted the in-network storage employed resource control and contacted the in-network storage
element for each data exchange, this could present a scalability element for each data exchange, this could present a scalability
challenge for the server as well as additional latency for challenge for the server as well as additional latency for
clients. clients.
An alternative is to let requesting users get the resource An alternative is to let requesting users get the resource
control policies and users can then present the policy to the control policies and users can then present the policy to the
storage directly. This can result in reduced messaging handled storage directly. This can result in reduced messaging handled
by the in-network storage. by the in-network storage.
4.1.6. Authorization 4.1.6. Authorization
4.1.6.1. Per-Peer, Per-Data Read Access 4.1.6.1. Per-Remote-Client, Per-Data Read Access
REQUIREMENT(S): A DECADE Client MUST be able to authorize individual REQUIREMENT(S): A DECADE Client MUST be able to control which
peers to read particular data stored on its in-network storage. individual remote clients are authorized to read particular data
stored on its in-network storage.
RATIONALE: A P2P application can control certain application-level RATIONALE: A Target Application can control certain application-
policies by sending particular data (e.g., chunks) to certain level policies by sending particular data (e.g., chunks) to
peers. It is important that peers not be able to circumvent such certain remote clients. It is important that remote clients not
decisions by arbitrarily reading any currently-stored data in in- be able to circumvent such decisions by arbitrarily reading any
network storage. currently-stored data in in-network storage.
4.1.6.2. Per-User Write Access 4.1.6.2. Per-User Write Access
REQUIREMENT(S): A DECADE Client MUST be able to authorize individual REQUIREMENT(S): A DECADE Client MUST be able to control which
peers to store data into its in-network storage. individual remote clients are authorized to store data into its
in-network storage.
RATIONALE: The space managed by a user in in-network storage can be RATIONALE: The space managed by a user in in-network storage can be
a limited resource. At the same time, it can be useful to allow a limited resource. At the same time, it can be useful to allow
remote peers to write data directly to a user's in-network remote clients to write data directly to a user's in-network
storage. Thus, a DECADE client should be able to grant only storage. Thus, a DECADE client should be able to grant only
certain peers this privilege. certain remote clients this privilege.
Note that it is not (currently) a requirement to check that a Note that it is not (currently) a requirement to check that a
peer stores a particular set of data (e.g., the check that a remote client stores a particular set of data (e.g., the check
remote peer writes the expected chunk of a file). Enforcing this that a remote client writes the expected chunk of a file).
as a requirement would require a client to know which data is Enforcing this as a requirement would require a client to know
expected (e.g., the full chunk itself or a hash of the chunk) which data is expected (e.g., the full chunk itself or a hash of
which may not be available in all applications. Checking for a the chunk) which may not be available in all applications.
particular hash could be considered as a requirement in the Checking for a particular hash could be considered as a
future that could optionally be employed by applications. requirement in the future that could optionally be employed by
applications.
4.1.6.3. Authorization Checks 4.1.6.3. Authorization Checks
REQUIREMENT(S): In-network storage MUST check the authorization of a REQUIREMENT(S): In-network storage MUST check the authorization of a
client before it executes a supplied request. The in-network client before it executes a supplied request. The in-network
storage MAY use optimizations to avoid such authorization checks storage MAY use optimizations to avoid such authorization checks
as long as the enforced permissions are the the same. as long as the enforced permissions are the the same.
RATIONALE: Authorization granted by a DECADE client are meaningless RATIONALE: Authorization granted by a DECADE client are meaningless
unless unauthorized requests are denied access. Thus, the in- unless unauthorized requests are denied access. Thus, the in-
skipping to change at page 15, line 33 skipping to change at page 15, line 36
RATIONALE: DECADE clients may be operating on hosts without constant RATIONALE: DECADE clients may be operating on hosts without constant
network connectivity or without a permanent attachment address network connectivity or without a permanent attachment address
(e.g., mobile devices). To support access control with such (e.g., mobile devices). To support access control with such
hosts, DECADE servers must support access control policies that hosts, DECADE servers must support access control policies that
use information other than IP addresses. use information other than IP addresses.
4.1.6.5. Server Involvement 4.1.6.5. Server Involvement
REQUIREMENT(S): A DECADE client MUST be able to indicate, without REQUIREMENT(S): A DECADE client MUST be able to indicate, without
contacting the server itself, access control policies for peers' contacting the server itself, access control policies for remote
requests. clients' requests.
RATIONALE: See discussion in Section 4.1.5.3. RATIONALE: See discussion in Section 4.1.5.3.
5. Storage Requirements 5. Storage Requirements
5.1. Requirements 5.1. Requirements
5.1.1. Explicit Deletion of Stored Data 5.1.1. Explicit Deletion of Stored Data
REQUIREMENT(S): DECADE MUST support the ability for a DECADE client REQUIREMENT(S): DECADE MUST support the ability for a DECADE client
to explicitly delete data from its own in-network storage. to explicitly delete data from its own in-network storage.
DECADE MAY have an overwrite flag indicating that an object with
the same name should be replaced.
RATIONALE: A DECADE client may continually be writing data to its RATIONALE: A DECADE client may continually be writing data to its
in-network storage. Since there may be a limit (e.g., imposed by in-network storage. Since there may be a limit (e.g., imposed by
the storage provider) to how much total storage can be used, some the storage provider) to how much total storage can be used, some
data may need to be removed to make room for additional data. A data may need to be removed to make room for additional data. A
DECADE client should be able to explicitly remove particular DECADE client should be able to explicitly remove particular
data. This may be implemented using existing protocols. data. This may be implemented using existing protocols.
5.1.2. Multiple writing 5.1.2. Multiple writing
REQUIREMENT(S): DECADE MUST NOT allow multiple writers for the same REQUIREMENT(S): DECADE MUST NOT allow multiple writers for the same
object. Implementations raise an error to one of the writers. object. Implementations raise an error to one of the writers.
RATIONALE: This avoids data corruption in a simple way while RATIONALE: This avoids data corruption in a simple way while
remaining efficient. remaining efficient.
5.1.3. Multiple reading 5.1.3. Multiple reading
REQUIREMENT(S): DECADE MUST allow for multiple readers for an REQUIREMENT(S): DECADE MUST allow for multiple readers for an
object.. object.
RATIONALE: One characteristic of P2P applications is the ability to RATIONALE: One characteristic of Target Applications is the ability
upload an object to multiple peers. Thus, it is natural for to upload an object to multiple clients. Thus, it is natural for
DECADE to allow multiple readers to access the content DECADE to allow multiple readers to read the content
concurrently. concurrently.
5.1.4. Reading before completely written 5.1.4. Reading before completely written
REQUIREMENT(S): DECADE MAY allow readers to read from objects before REQUIREMENT(S): DECADE MAY allow readers to read from objects before
they have been completely written. they have been completely written.
RATIONALE: Some P2P systems (in particular, streaming) can be RATIONALE: Some Target Applications (in particular, P2P streaming)
sensitive to latency. A technique to reduce latency is to remove can be sensitive to latency. A technique to reduce latency is to
store-and-forward delays for data objects (e.g., make the object remove store-and-forward delays for data objects (e.g., make the
available before it is completely stored). Appropriate handling object available before it is completely stored). Appropriate
for error conditions (e.g., a disappearing writer) needs to be handling for error conditions (e.g., a disappearing writer) needs
specified. to be specified.
5.1.5. Writing model 5.1.5. Hints concerning usage stored data
REQUIREMENT(S): DECADE MAY allow writers of new objects to indicate
specific hints concerning how the objects are expected to be used
(e.g., access frequency or time to live).
RATIONALE: Different Target Applications may have different usage
patterns for objects stored at in-network storage. For example,
a P2P live streaming application may indicate to a DECADE server
that the objects are expected to have a shore time-to-live, but
read frequently. The DECADE server may then opt to store the
objects in memory instead of in disk.
5.1.6. Writing model
REQUIREMENT(S): DECADE MUST provide at least a writing model (while REQUIREMENT(S): DECADE MUST provide at least a writing model (while
storing an object) that appends data to data already stored. storing an object) that appends data to data already stored.
RATIONALE: Depending on the object size (e.g., chunk size) used by a RATIONALE: Depending on the object size (e.g., chunk size) used by a
P2P application, the application may need to send data to the Target Application, the application may need to send data to the
DECADE server in multiple packets. To keep implementation DECADE server in multiple packets. To keep implementation
simple, the DECADE must at least support the ability to write the simple, the DECADE must at least support the ability to write the
data sequentially in the order received. Implementations MAY data sequentially in the order received. Implementations MAY
allow application to write data in an object out-of-order (but allow application to write data in an object out-of-order (but
MAY NOT overwrite ranges of the object that have already been MUST NOT overwrite ranges of the object that have already been
stored). stored).
5.1.6. Storage Status 5.1.7. Storage Status
REQUIREMENT(S): A DECADE client MUST be able to retrieve current REQUIREMENT(S): A DECADE client MUST be able to retrieve current
resource usage (including list of stored data) and resource resource usage (including list of stored data), resource quotas,
quotas on its in-network storage. and access permissions for its in-network storage. The returned
information MUST include resource usage resulting from the
client's own usage and usage by other clients that have been
authorized to read/write objects or open connections to that
client's storage.
RATIONALE: The resources used by a client are not directly-attached RATIONALE: The resources used by a client are not directly-attached
(e.g., disk, network interface, etc). Thus, the client cannot (e.g., disk, network interface, etc). Thus, the client cannot
locally determine how such resources are being used. Before locally determine how such resources are being used. Before
storing and retrieving data, a client should be able to determine storing and retrieving data, a client should be able to determine
which data is available (e.g., after an application restart). which data is available (e.g., after an application restart).
Additionally, a client should be able to determine resource Additionally, a client should be able to determine resource
availability to better allocate them to remote peers. availability to better allocate them to remote clients.
5.2. Non-Requirements 5.2. Non-Requirements
5.2.1. No ability to update 5.2.1. No ability to update
REQUIREMENT(S): DECADE SHOULD NOT provide ability to update existing REQUIREMENT(S): DECADE SHOULD NOT provide ability to update existing
objects. That is, objects are immutable once they are stored. objects. That is, objects are immutable once they are stored.
RATIONALE: Reasonable consistency models for updating existing RATIONALE: Reasonable consistency models for updating existing
objects would significantly complicate implementation (especially objects would significantly complicate implementation (especially
if implementation chooses to replicate data across multiple if implementation chooses to replicate data across multiple
servers). If a user needs to update a resource, it can store a servers). If a user needs to update a resource, it can store a
new resource and then distribute the new resource instead of the new resource and then distribute the new resource instead of the
 End of changes. 70 change blocks. 
189 lines changed or deleted 210 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/