DECoupled Application Data Enroute (DECADE)
RFC 7069

described in Section 4.5.  The following status information elements
   SHOULD be obtained: a) list of associated data objects (with
   properties); and b) resources used/available.  In addition, the
   following information elements MAY be available: c) list of servers
   to which data objects have been distributed (in a certain time
   frame); and d) list of clients to which data objects have been
   distributed (in a certain time frame).

   For the list of servers/clients to which data objects have been
   distributed to, the server SHOULD be able to decide on time bounds
   for which this information is stored and specify the corresponding
   time frame in the response to such requests.  Some of this
   information may be used for accounting purposes, e.g., the list of
   clients to which data objects have been distributed.

   Access information MAY be provided for accounting purposes, for
   example, when uploading DECADE clients are interested in access
   statistics for resources and/or to perform accounting per user.
   Again, access to such information requires client authorization and
   SHOULD be based on the delegation concept as described in
   Section 4.5.  The following type of access information elements MAY
   be requested: a) what data objects have been accessed by whom and how
   many times; and b) access tokens that a server has seen for a given
   data object.

   The server SHOULD decide on time bounds for which this information is
   stored and specify the corresponding time frame in the response to
   such requests.

6.2.3.  Data Object Attributes

   Data objects that are stored on a DECADE server SHOULD have
   associated attributes (in addition to the object identifier) that
   relate to the data storage and its management.  These attributes may
   be used by the server (and possibly the underlying storage system) to
   perform specialized processing or handling for the data object, or to
   attach related server or storage-layer properties to the data object.
   These attributes have a scope local to a server.  In particular,
   these attributes SHOULD NOT be applied to a server or client to which
   a data object is copied.

   Depending on authorization, clients SHOULD be permitted to get or set
   such attributes.  This authorization is based on the delegation as
   per Section 4.5.  DECADE does not limit the set of permissible
   attributes, but rather specifies a set of baseline attributes that
   SHOULD be supported:

Alimi, et al.                 Informational                    [Page 21]
RFC 7069                         DECADE                    November 2013

   Expiration Time:  time at which the data object can be deleted

   Data Object size:  in bytes

   Media type:  labeling of type as per [RFC6838]

   Access statistics:  how often the data object has been accessed (and
      what tokens have been used)

   The data object attributes defined here are distinct from application
   metadata.  Application metadata is custom information that an
   application might wish to associate with a data object to understand
   its semantic meaning (e.g., whether it is video and/or audio, its
   playback length in time, or its index in a stream).  If an
   application wishes to store such metadata persistently, it can be
   stored within data objects themselves.

6.3.  Data Transfer

   A DECADE server will provide a data access interface, and SDT will be
   used to write data objects to a server and to read (download) data
   objects from a server.  Semantically, SDT is a client-server
   protocol; that is, the server always responds to client requests.

   To write a data object, a client first generates the object's name
   (see Section 6.1), and then uploads the object to a server and
   supplies the generated name.  The name can be used to access
   (download) the object later; for example, the client can pass the
   name as a reference to other clients that can then refer to the
   object.  Data objects can be self-contained objects such as
   multimedia resources, files, etc., but also chunks, such as chunks of
   a P2P distribution protocol that can be part of a containing object
   or a stream.  If supported, a server can verify the integrity and
   other security properties of uploaded objects.

   A client can request named data objects from a server.  In a
   corresponding request message, a client specifies the object name and
   a suitable access and resource control token.  The server checks the
   validity of the received token and its associated properties related
   to resource usage.  If the named data object exists on the server and
   the token can be validated, the server delivers the requested object
   in a response message.  If the data object cannot be delivered, the
   server provides a corresponding status/reason information in a
   response message.  Specifics regarding error handling, including
   additional error conditions (e.g., overload), precedence for returned
   errors and its relation with server policy, are deferred to eventual
   protocol specification.

Alimi, et al.                 Informational                    [Page 22]
RFC 7069                         DECADE                    November 2013

6.4.  Server-Server Protocols

   An important feature of a DECADE system is the capability for one
   server to directly download data objects from another server.  This
   capability allows applications to directly replicate data objects
   between servers without requiring end-hosts to use uplink capacity to
   upload data objects to a different server.

   DRP and SDT SHOULD support operations directly between servers.
   Servers are not assumed to trust each other nor are they configured
   to do so.  All data operations are performed on behalf of clients via
   explicit instruction.  However, the objects being processed do not
   necessarily have to originate or terminate at the client (i.e., the
   data object might be limited to being exchanged between servers even
   if the instruction is triggered by the client).  Clients thus will be
   able to indicate to a server which remote server(s) to access, what
   operation is to be performed, or in which server the object is to be
   stored, and the credentials indicating access and resource control to
   perform the operation at the remote server.

   Server-server support is focused on reading and writing data objects
   between servers.  The data object referred to at the remote server is
   the same as the original data object requested by the client.  Object
   attributes might also be specified in the request to the remote
   server.  In this way, a server acts as a proxy for a client, and a
   client can instantiate requests via that proxy.  The operations will
   be performed as if the original requester had its own client co-
   located with the server.  When a client sends a request to a server
   with these additional parameters, it is giving the server permission
   to act (proxy) on its behalf.  Thus, it would be prudent for the
   supplied token to have narrow privileges (e.g., limited to only the
   necessary data objects) or validity time (e.g., a small expiration
   time).

   In the case of a retrieval operation, the server is to retrieve the
   data object from the remote server using the specified credentials,
   and then optionally return the object to a client.  In the case of a
   storage operation, the server is to store the object to the remote
   server using the specified credentials.  The object might optionally
   be uploaded from the client or might already exist at the server.

6.5.  Potential DRP/SDT Candidates

   Having covered the key DRP/SDT functionalities above, it is useful to
   consider some potential DRP/SDT candidates as guidance for future
   DECADE protocol implementations.  To recap, the DRP is a protocol for
   communication of access control and resource-scheduling policies from
   a DECADE client to a DECADE server, or between DECADE servers.  The

Alimi, et al.                 Informational                    [Page 23]
RFC 7069                         DECADE                    November 2013

   SDT is a protocol used to transfer data objects between a DECADE
   client and DECADE server, or between DECADE servers.  An evaluation
   of existing protocols for their suitability for DRP and SDT is given
   in Appendix A.  Also, [INTEGRATION-EX] provides some experimental
   examples of how to integrate DECADE-like in-network storage
   infrastructure into P2P applications.

7.  How In-Network Storage Components Map to DECADE

   This section evaluates how the basic components of an in-network
   storage system (see Section 3 of [RFC6392]) map into a DECADE system.

   With respect to the data access interface, DECADE clients can read
   and write objects of arbitrary size through the client's Data
   Controller, making use of standard data transfer (SDT).  With respect
   to data management operations, clients can move or delete previously
   stored objects via the client's Data Controller, making use of SDT.
   Clients can enumerate or search contents of servers to find objects
   matching desired criteria through services provided by the content
   distribution application (e.g., buffer-map exchanges, a DHT, or peer
   exchange).  In doing so, Application Endpoints might consult their
   local Data Index in the client's Data Controller (Data Search
   Capability).

   With respect to access control authorization, all methods of access
   control are supported: public-unrestricted, public-restricted, and
   private.  Access control policies are generated by a content
   distribution application and provided to the client's Resource
   Controller.  The server is responsible for implementing the access
   control checks.  Clients can manage the resources (e.g., bandwidth)
   on the DECADE server that can be used by other Application Endpoints
   (Resource Control Interface).  Resource-sharing policies are
   generated by a content distribution application and provided to the
   client's Resource Controller.  The server is responsible for
   implementing the resource-sharing policies.

   Although the particular protocol used for discovery is outside the
   scope of this document, different options and considerations have
   been discussed in Section 5.6.  Finally, with respect to the storage
   mode, DECADE servers provide an object-based storage mode.  Immutable
   data objects might be stored at a server.  Applications might
   consider existing blocks as data objects, or they might adjust block
   sizes before storing in a server.

Alimi, et al.                 Informational                    [Page 24]
RFC 7069                         DECADE                    November 2013

8.  Security Considerations

   In general, the security considerations mentioned in [RFC6646] apply
   to this document as well.  A DECADE system provides a distributed
   storage service for content distribution and similar applications.
   The system consists of servers and clients that use these servers to
   upload data objects, to request distribution of data objects, and to
   download data objects.  Such a system is employed in an overall
   application context (for example, in a P2P application), and it is
   expected that DECADE clients take part in application-specific
   communication sessions.  The security considerations here focus on
   threats related to the DECADE system and its communication services,
   i.e., the DRP/SDT protocols that have been described in an abstract
   fashion in this document.

8.1.  Threat: System Denial-of-Service Attacks

   A DECADE network might be used to distribute data objects from one
   client to a set of servers using the server-server communication
   feature that a client can request when uploading an object.  Multiple
   clients uploading many objects at different servers at the same time
   and requesting server-server distribution for them could thus mount
   massive distributed denial-of-service (DDOS) attacks, overloading a
   network of servers.  This threat is addressed by the server's access
   control and resource control framework.  Servers can require
   Application Endpoints to be authorized to store and to download
   objects, and Application Endpoints can delegate authorization to
   other Application Endpoints using the token mechanism.  Of course the
   effective security of this approach depends on the strength of the
   token mechanism.  See below for a discussion of this and related
   communication security threats.

   Denial-of-service attacks against a single server (directing many
   requests to that server) might still lead to considerable load for
   processing requests and invalidating tokens.  SDT therefore MUST
   provide a redirection mechanism to allow requests to other servers.
   Analogous to how an HTTP reverse proxy can redirect and load balance
   across multiple HTTP origin servers [RFC2616].

8.2.  Threat: Authorization Mechanisms Compromised

   A DECADE system does not require Application Endpoints to
   authenticate in order to access a server for downloading objects,
   since authorization is not based on Endpoint or user identities but
   on a delegation-based authorization mechanism.  Hence, most protocol
   security threats are related to the authorization scheme.  The
   security of the token mechanism depends on the strength of the token
   mechanism and on the secrecy of the tokens.  A token can represent

Alimi, et al.                 Informational                    [Page 25]
RFC 7069                         DECADE                    November 2013

   authorization to store a certain amount of data, to download certain
   objects, to download a certain amount of data per time, etc.  If it
   is possible for an attacker to guess, construct, or simply obtain
   tokens, the integrity of the data maintained by the servers is
   compromised.

   This is a general security threat that applies to authorization
   delegation schemes.  Specifications of existing delegation schemes
   such as [RFC6749] discuss these general threats in detail.  We can
   say that the DRP has to specify appropriate algorithms for token
   generation.  Moreover, authorization tokens should have a limited
   validity period that should be specified by the application.  Token
   confidentiality should be provided by application protocols that
   carry tokens, and the SDT and DRP should provide secure
   (confidential) communication modes.

8.3.  Threat: Spoofing of Data Objects

   In a DECADE system, an Application Endpoint is referring other
   Application Endpoints to servers to download a specified data object.
   An attacker could "inject" a faked version of the object into this
   process, so that the downloading Endpoint effectively receives a
   different object (compared to what the uploading Endpoint provided).
   As a result, the downloading Endpoint believes that is has received
   an object that corresponds to the name it was provided earlier,
   whereas in fact it is a faked object.  Corresponding attacks could be
   mounted against the application protocol (that is used for referring
   other Endpoints to servers), servers themselves (and their storage
   subsystems), and the SDT by which the object is uploaded,
   distributed, and downloaded.

   A DECADE systems fundamental mechanism against object spoofing is
   name-object binding validation, i.e., the ability of a receiver to
   check whether the name it was provided and that it used to request an
   object actually corresponds to the bits it received.  As described
   above, this allows for different forms of name-object binding, for
   example, using hashes of data objects, with different hash functions
   (different algorithms, different digest lengths).  For those
   application scenarios where hashes of data objects are not applicable
   (for example, live streaming), other forms of name-object binding can
   be used.  This flexibility also addresses cryptographic algorithm
   evolution: hash functions might get deprecated, better alternatives
   might be invented, etc., so that applications can choose appropriate
   mechanisms that meet their security requirements.

Alimi, et al.                 Informational                    [Page 26]
RFC 7069                         DECADE                    November 2013

   DECADE servers MAY perform name-object binding validation on stored
   objects, but Application Endpoints MUST NOT rely on that.  In other
   words, Application Endpoints SHOULD perform name-object binding
   validation on received objects.

9.  Acknowledgments

   We thank the following people for their contributions to and/or
   detailed reviews of this document or earlier drafts of this document:
   Carlos Bernardos, Carsten Bormann, David Bryan, Dave Crocker, Yingjie
   Gu, David Harrington, Hongqiang (Harry) Liu, David McDysan, Borje
   Ohlman, Martin Stiemerling, Richard Woundy, and Ning Zong.

10.  References

10.1.  Normative References

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

10.2.  Informative References

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

   [RFC5661]  Shepler, S., Eisler, M., and D. Noveck, "Network File
              System (NFS) Version 4 Minor Version 1 Protocol", RFC
              5661, January 2010.

   [RFC5754]  Turner, S., "Using SHA2 Algorithms with Cryptographic
              Message Syntax", RFC 5754, January 2010.

   [RFC6392]  Alimi, R., Rahman, A., and Y. Yang, "A Survey of In-
              Network Storage Systems", RFC 6392, October 2011.

   [RFC6646]  Song, H., Zong, N., Yang, Y., and R. Alimi, "DECoupled
              Application Data Enroute (DECADE) Problem Statement", RFC
              6646, July 2012.

   [RFC6749]  Hardt, D., "The OAuth 2.0 Authorization Framework", RFC
              6749, October 2012.

   [RFC6838]  Freed, N., Klensin, J., and T. Hansen, "Media Type
              Specifications and Registration Procedures", BCP 13, RFC
              6838, January 2013.

Alimi, et al.                 Informational                    [Page 27]
RFC 7069                         DECADE                    November 2013

   [RFC6920]  Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B.,
              Keranen, A., and P. Hallam-Baker, "Naming Things with
              Hashes", RFC 6920, April 2013.

   [INTEGRATION-EX]
              Zong, N., Ed., Chen, X., Huang, Z., Chen, L., and H. Liu,
              "Integration Examples of DECADE System", Work in Progress,
              August 2013.

   [GoogleFileSystem]
              Ghemawat, S., Gobioff, H., and S. Leung, "The Google File
              System", SOSP '03, Proceedings of the 19th ACM Symposium
              on Operating Systems Principles, October 2003.

   [GoogleStorageDevGuide]
              Google, "Google Cloud Storage - Developer's Guide",
              <https://developers.google.com/storage/docs/
              concepts-techniques>.

   [OpenFlow]
              Open Networking Foundation, "Software-Defined Networking:
              The New Norm for Networks", April 2013,
              <https://www.opennetworking.org/images/stories/downloads/
              sdn-resources/white-papers/wp-sdn-newnorm.pdf>.

   [CDMI]     Storage Networking Industry Association (SNIA), "Cloud
              Data Management Interface (CDMI (TM)), Version 1.0.2",
              June 2012,
              <http://snia.org/sites/default/files/CDMI%20v1.0.2.pdf>.

Alimi, et al.                 Informational                    [Page 28]
RFC 7069                         DECADE                    November 2013

Appendix A.  Evaluation of Candidate Protocols for DECADE DRP/SDT

   In this section we evaluate how well the abstract protocol
   interactions specified in this document for DECADE DRP and SDT can be
   fulfilled by the existing protocols of HTTP, CDMI, and OAuth.

A.1.  HTTP

   HTTP [RFC2616] is a key protocol for the Internet in general and
   especially for the World Wide Web.  HTTP is a request-response
   protocol.  A typical transaction involves a client (e.g., web
   browser) requesting content (resources) from a web server.  Another
   example is when a client stores or deletes content from a server.

A.1.1.  HTTP Support for DRP Primitives

   DRP provides configuration of access control and resource-sharing
   policies on DECADE servers.

A.1.1.1.  Access Control Primitives

   Access control requires mechanisms for defining the access policies
   for the server and then checking the authorization of a user before
   it stores or retrieves content.  HTTP supports a rudimentary access
   control via "HTTP Secure" (HTTPS).  HTTPS is a combination of HTTP
   with SSL/TLS.  The main use of HTTPS is to authenticate the server
   and encrypt all traffic between the client and the server.  There is
   also a mode to support client authentication, though this is less
   frequently used.

A.1.1.2.  Resource Control Primitives for Communication

   Communication resources include bandwidth (upload/download) and the
   number of simultaneously connected clients (connections).  HTTP
   supports bandwidth control indirectly through "persistent" HTTP
   connections.  Persistent HTTP connections allows a client to keep
   open the underlying TCP connection to the server to allow streaming
   and pipelining (multiple simultaneous requests for a given client).

   HTTP does not have direct support for controlling the communication
   resources for a given client.  However, servers typically perform
   this function via implementation algorithms.

Alimi, et al.                 Informational                    [Page 29]
RFC 7069                         DECADE                    November 2013

A.1.1.3.  Resource Control Primitives for Storage

   Storage resources include the amount of memory and lifetime of
   storage.  HTTP does not allow direct control of storage at the server
   endpoint.  However, HTTP supports caching at intermediate points such
   as a web proxy.  For this purpose, HTTP defines cache control
   mechanisms that define how long and in what situations the
   intermediate point may store and use the content.

A.1.2.  HTTP Support for SDT Primitives

   SDT is used to write objects and read (download) objects from a
   DECADE server.  The object can be either a self-contained object such
   as a multimedia file or a chunk from a P2P system.

A.1.2.1.  Writing Primitives

   Writing involves uploading objects to the server.  HTTP supports two
   methods of writing called PUT and POST.  In HTTP, the object is
   called a resource and is identified by a URI.  PUT uploads a resource
   to a specific location on the server.  POST, on the other hand,
   submits the object to the server, and the server decides whether to
   update an existing resource or to create a new resource.

   For DECADE, the choice of whether to use PUT or POST will be
   influenced by which entity is responsible for the naming.  If the
   client performs the naming, then PUT is appropriate.  If the server
   performs the naming, then POST should be used (to allow the server to
   define the URI).

A.1.2.2.  Downloading Primitives

   Downloading involves fetching of an object from the server.  HTTP
   supports downloading through the GET and HEAD methods.  GET fetches a
   specific resource as identified by the URL.  HEAD is similar but only
   fetches the metadata ("header") associated with the resource, not the
   resource itself.

A.1.3.  Primitives for Removing Duplicate Traffic

   To challenge a remote entity for an object, the DECADE server should
   provide a seed number, which is generated by the server randomly, and
   ask the remote entity to return a hash calculated from the seed
   number and the content of the object.  The server may also specify
   the hash function that the remote entity should use.  HTTP supports
   the challenge message through the GET methods.  The message type

Alimi, et al.                 Informational                    [Page 30]
RFC 7069                         DECADE                    November 2013

   ("challenge"), the seed number, and the hash function name are put in
   a URL.  In the reply, the hash is sent in an Entity Tag (ETag)
   header.

A.1.4.  Other Operations

   HTTP supports deleting of content on the server through the DELETE
   method.

A.1.5.  Conclusions

   HTTP can provide a rudimentary DRP and SDT for some aspects of
   DECADE, but it will not be able to satisfy all the DECADE
   requirements.  For example, HTTP does not provide a complete access
   control mechanism nor does it support storage resource controls at
   the endpoint server.

   It is possible, however, to envision combining HTTP with a custom
   suite of other protocols to fulfill most of the DECADE requirements
   for DRP and SDT.  For example, Google Storage for Developers is built
   using HTTP (with extensive proprietary extensions such as custom HTTP
   headers).  Google Storage also uses OAuth [RFC6749] (for access
   control) in combination with HTTP [GoogleStorageDevGuide].  An
   example of using OAuth for DRP is given in Appendix A.3.

A.2.  CDMI

   The Cloud Data Management Interface (CDMI) specification defines a
   functional interface through which applications can store and manage
   data objects in a cloud storage environment.  The CDMI interface for
   reading/writing data is based on standard HTTP requests, with CDMI-
   specific encodings using JavaScript Object Notation (JSON).  CDMI is
   specified by the Storage Networking Industry Association (SNIA)
   [CDMI].

A.2.1.  CDMI Support for DRP Primitives

   DRP provides configuration of access control and resource-sharing
   policies on DECADE servers.

A.2.1.1.  Access Control Primitives

   Access control includes mechanisms for defining the access policies
   for the server and then checking the authorization of a user before
   allowing content storage or retrieval.  CDMI defines an Access
   Control List (ACL) per data object and thus supports access control
   (read and/or write) at the granularity of data objects.  An ACL

Alimi, et al.                 Informational                    [Page 31]
RFC 7069                         DECADE                    November 2013

   contains a set of Access Control Entries (ACEs), where each ACE
   specifies a principal (i.e., user or group of users) and a set of
   privileges that are granted to that principal.

   CDMI requires that an HTTP authentication mechanism be available for
   the server to validate the identity of a principal (client).
   Specifically, CDMI requires that either HTTP Basic Authentication or
   HTTP Digest Authentication be supported.  CDMI recommends that HTTP
   over TLS (HTTPS) is supported to encrypt the data sent over the
   network.

A.2.1.2.  Resource Control Primitives for Communication

   Communication resources include bandwidth (upload/download) and the
   number of simultaneously connected clients (connections).  CDMI
   supports two key data attributes that provide control over the
   communication resources to a client: "cdmi_max_throughput" and
   "cdmi_max_latency".  These attributes are defined in the metadata for
   data objects and indicate the desired bandwidth or delay for
   transmission of the data object from the cloud server to the client.

A.2.1.3.  Resource Control Primitives for Storage

   Storage resources include amount of quantity and lifetime of storage.
   CDMI defines metadata for individual data objects and general storage
   system configuration that can be used for storage resource control.
   In particular, CDMI defines the following metadata fields:

   -cdmi_data_redundancy:  desired number of copies to be maintained

   -cdmi_geographic_placement:  region where object is permitted to be
      stored

   -cdmi_retention_period:  time interval object is to be retained

   -cdmi_retention_autodelete:  whether object should be automatically
      deleted after retention period

A.2.2.  CDMI Support for SDT Primitives

   SDT is used to write objects and read (download) objects from a
   DECADE server.  The object can be either a self-contained object such
   as a multimedia file or a chunk from a P2P system.

Alimi, et al.                 Informational                    [Page 32]
RFC 7069                         DECADE                    November 2013

A.2.2.1.  Writing Primitives

   Writing involves uploading objects to the server.  CDMI supports
   standard HTTP methods for PUT and POST as described in
   Appendix A.1.2.1.

A.2.2.2.  Downloading Primitives

   Downloading involves fetching of an object from the server.  CDMI
   supports the standard HTTP GET method as described in
   Appendix A.1.2.2.

A.2.3.  Other Operations

   CDMI supports DELETE as described in Appendix A.1.4.  CDMI also
   supports COPY and MOVE operations.

   CDMI supports the concept of containers of data objects to support
   joint operations on related objects.  For example, GET may be done on
   a single data object or an entire container.

   CDMI supports a global naming scheme.  Every object stored within a
   CDMI system will have a globally unique object string identifier
   (ObjectID) assigned at creation time.

A.2.4.  Conclusions

   CDMI has a rich array of features that can provide a good base for
   DRP and SDT for DECADE.  An initial analysis finds that the following
   CDMI features may be useful for DECADE:

   -  access control

   -  storage resource control

   -  communication resource control

   -  COPY/MOVE operations

   -  data containers

   -  naming scheme

Alimi, et al.                 Informational                    [Page 33]
RFC 7069                         DECADE                    November 2013

A.3.  OAuth

   As mentioned in Appendix A.1, OAuth [RFC6749] may be used as part of
   the access and resource control of a DECADE system.  In this section,
   we provide an example of how to configure OAuth requests and
   responses for DRP.

   An OAuth request to access DECADE data objects should include the
   following fields:

      response_type: Value should be set to "token".

      client_id: The client_id indicates either the application that is
      using the DECADE service or the end user who is using the DECADE
      service from a DECADE storage service provider.  DECADE storage
      service providers should provide the ID distribution and
      management function.

      scope: Data object names that are requested.

   An OAuth response should include the following information:

      token_type: "Bearer"

      expires_in: The lifetime in seconds of the access token.

      access_token: A token denotes the following information.

      service_uri: The server address or URI which is providing the
      service;

      permitted_operations (e.g., read, write) and objects (e.g., names
      of data objects that might be read or written);

      priority: Value should be set to be either "Urgent", "High",
      "Normal" or "Low".

      bandwidth: Given to requested operation, a weight value used in a
      weighted bandwidth sharing scheme, or an integer in number of bits
      per second;

      amount: Data size in number of bytes that might be read or
      written.

      token_signature: The signature of the access token.

Alimi, et al.                 Informational                    [Page 34]
RFC 7069                         DECADE                    November 2013

Authors' Addresses

   Richard Alimi
   Google

   EMail: ralimi@google.com

   Akbar Rahman
   InterDigital Communications, LLC

   EMail: akbar.rahman@interdigital.com

   Dirk Kutscher
   NEC

   EMail: dirk.kutscher@neclab.eu

   Y. Richard Yang
   Yale University

   EMail: yry@cs.yale.edu

   Haibin Song
   Huawei Technologies

   EMail: haibin.song@huawei.com

   Kostas Pentikousis
   EICT

   EMail: k.pentikousis@eict.de

Alimi, et al.                 Informational                    [Page 35]