I have been selected as the Applications Area Directorate reviewer for this 
draft: (for background on appsdir, please see 
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).


Document:

    draft-ietf-decade-reqs-05

Title:

    DECADE Requirements

Reviewer:

    D. Crocker <dcrocker@bbiw.net>

Review Date:

    22 March 2012


Summary:

The document specifies requirements for a DECADE service that caches content 
topologically near "swarms" of consumer clients.  I believe the documents needs 
substantial work.

The motivation for DECADE is stated a  bit differently in the -problem draft 
than in this -reqs draft.  In the -problem draft, the task is to place content 
"near" consumers.  In the current draft, the task is for any sort of separate 
storage service that can be controlled by "P2P applications".

As with the -reqs draft, a number of core terms are not defined.  In some cases, 
they seemed to be used with different or ambiguous meaning. Possibly, different 
terms are used for the same meaning; I can't be sure.

More fundamentally, the considerable range of requirements appears to be 
predicated on one or more functional models -- a storage service overlay -- that 
is unstated, except by intuiting it -- if not completely -- from various of the 
requirements.

The requirements desperately need a functional model/architecture specification 
upon which to build their references and meanings.  It would chart out the 
functional components and their relationships, greatly aiding in discussion of 
actors and actors. The requirements are riddled with assumed characteristics of 
the model.  That is, the model seems clearly to be in the minds of the authors, 
but the reader is left guessing. This needs to be remedied.

By now, those active in the DECADE working group are likely thinking that I 
should have read the -arch document.  First, it wasn't in the set delivered for 
review.  I assume that it is not yet ready?  Second, neither the -problem nor 
-reqs documents are consistent with the -arch document.  My suggestion is to 
complete the -arch document /before/ doing further work on the -reqs document. 
Then when working on -reqs, diligently cite terms and discussion in the -arch 
document to explain the terms and provide the motivation for the requirements. 
(For reference, I've used some possible terms in this review, since they are 
commonly used elsewhere.  While I do suggest re-using established terms that 
have the correct meaning, I don't care which ones are chosen.

As with the -problem document, normative language is used but there is not 
reference that defines them.

I suspect that some of the requirements -- notably the one concerning 
credentials -- entails a security capability that has never been deployed widely 
in the open Internet.  That is, not having required support by large numbers of 
independent administrations.  In general, I suspect that the assertions of 
security requirements are too rigid and will incur unnecessary expense for many 
environments.

The last security-related concern I have is that the model is entirely 
channel-based, permitting no object-based security, such as with S/Mime, OpenPGP 
or even DKIM.  For some uses, the advantage of object-based security is that it 
does not matter what the security properties of the server are!

Organizationally, the document seems to have related requirements that are 
redundant and/or widely separated.  It also makes forward references, a number 
times, which suggestions that re-organization would develop a better foundation 
of requirements.



Detailed Comments:


> DECADE                                                             Y. Gu
> Internet-Draft                                                    Huawei
> Intended status: Informational                                  D. Bryan
> Expires: May 3, 2012                                       Polycom, Inc.
>                                                                  Y. Yang
>                                                          Yale University
>                                                                 R. Alimi
>                                                                   Google
>                                                         October 31, 2011
>
>
>                           DECADE Requirements
>                        draft-ietf-decade-reqs-05
>
> Abstract
>
>    The target of DECoupled Application Data Enroute (DECADE) is to
>    provide an open and standard in-network storage system for
>    applications, primarily P2P (peer-to-peer) applications, to store,

Concerns about terminology that were stated for the "problem" document also 
apply to this document.  In general, all of the major concerns expressed in the 
review of the -problem document should also be imported into this review.


> 1.  Introduction
>
>    The object of DECoupled Application Data Enroute (DECADE) is to
>    provide an open and standard in-network storage system for content

What does "in network" mean?

It seems likely that it does not mean a collection of routers, but the paper 
doesn't define it; yet it uses the term heavily.

As with the -problem document, I believe that what is being postulated is a 
storage server infrastructure, to operate between content producers and content 
consumers.  How these servers are insinuated in the path from producer to 
consumer is not discussed.  I can't tell how important a lack that is.


>    distribution applications, where data is typically broken into one or

By some measures, all applications deliver content.  This paper needs to define 
the content distribution (storage service) that is meant here, in distinct 
technical terms that distinguish the service from other services that are not 
content distribution, that is, which do not qualify as an example of a DECADE 
service.


>    more chunks and then distributed.  This may already include many
>    types of applications including P2P applications, IPTV (Internet

What is P2P?  In technical terms that distinguish it.


>    Protocol Television), and VoD (Video on Demand).  (For a precise
>    definition of the applications targeted in DECADE, see the definition
>    for Target Application in Section 2.)  Instead of always transferring
>    data directly from a source/owner client to a requesting client, the

 From a producer to a consumer.


>    source/owner client can write to and manage its content on its in-
>    network storage.  The requesting client can get the address of the
>    in-network storage pertaining to the source/owner client and read
>    data from the storage.
>
>    This draft enumerates and explains the rationale behind SPECIFIC

Having Rationale segments is extremely useful.


>    requirements on the protocol design and on any data store
>    implementation that may be used to implement DECADE servers that
>    should be considered during the design and implementation of a DECADE
>    system.  As such, it DOES NOT include general guiding principles.
>    General design considerations, explanation of the problem being
>    addressed, and enumeration of the types of applications to which
>    DECADE may be suited is not considered in this document.  For general
>    information, please see the problem statement
>    [I-D.ietf-decade-problem-statement] and architecture
>    [I-D.ietf-decade-arch] drafts.
>
>    This document enumerates the requirements to enable target
>    applications to utilize in-network storage.  In this context, using
>    storage resources includes not only basic capabilities such as
>    writing, reading, and managing data, but also controlling access for
>    particular remote clients with which it is sharing data.
>    Additionally, we also consider controlling the resources used by
>    remote clients when they access data as an integral part of utilizing
>    the network storage.

"remote client" -> consumer (?)


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

What does it mean to have multiple storage systems?  How do they differ?  How 
are they similar?


>
>
> Gu, et al.                 Expires May 3, 2012                  [Page 5]
> 
> Internet-Draft             DECADE Requirements              October 2011
>
>
> 2.  Terminology and Concepts
>
>    This document uses terms defined in
>    [I-D.ietf-decade-problem-statement].
>
>    This document also defines additional terminology:
>
>    Target Application: An application (typically installed at end-hosts)

1. What, exactly, is an 'end-host' for this discussion?

2. In a distributed environment, at the application layer, applications 
typically (always?) are distributed.  That is, The folks consuming content 
presumably are also running part of the application.  Hence, the definition here 
for "target application" sounds an awful lot like a server function or a content 
producer or some other established term for that specific role.  Note that it 
does not cover the consumer side of the equation.  That is, it does not appear 
to cover all of the components of the application, such as the users of the 
application.


>    with the ability to explicitly control usage of network and/or
>    storage resources to deliver content to a large number of users.
>    This includes scenarios where multiple applications or entities
>    cooperate, such as with P2P, CDN, and hybrid P2P/CDN architectures.
>    Such applications distribute large amounts of content (e.g., a large
>    file, or video stream) by dividing the content into smaller blocks
>    for more flexible distribution (e.g., over multiple application-level
>    paths).  The distributed content is typically immutable (though it
>    may be deleted).  We use the term Target Application to refer to the
>    type of applications that are explicitly (but not exclusively)
>    supported by DECADE.

P2P is used throughout but never defined.  What are the technical 
characteristics that make it distinct from basic, client/server models or the 
web or email or the DNS?

What is the difference between "network resources" and "storage resources" and 
what does it mean to control each?  I suspect that the current work is /not/ 
targeted at controlling network resources, yet it appears to imply that such 
control is possible.

Elaborate on the mean of 'flexible distribution' and its technical import for 
DECADE.

 From the above definition, a target application is one that is given some 
controls.  It has a large number of users.  Given the term P2P, are the users 
the first P or the second?  (Yes, I mean the question seriously.)

By 'immutable' does this mean it's static content, that does not change from one 
retrieval to the next?  However what about the case that qualify as targeted 
applications but are not 'typical'?



>
> 3.  Requirements Structure

Good section.  Helpful template.


>    The DECADE protocol is intended to sit between Target Applications
>    and a back-end storage system.  DECADE does not intend to develop yet

"back-end"?  what does that mean.  Note that much of this is likely to be made 
clearer with some diagrams showing components and their relationships.


>    another storage system, but rather to create a protocol that enables
>    Target Applications to make use of storage within the network,

Actually, by defining an access and control interface to a storage system, this 
work is, in effect, defining the system.  That is, it /is/ defining a storage 
system.  It's not defining the internals to the system, but it is defining its 
public face.


>    leaving specific storage system considerations to the implementation
>    of the DECADE servers as much as possible.  For this reason, we have
>    divided the requirements into two primary categories:
>
>    o  Protocol Requirements: Protocol requirements for Target
>       Applications to make use of in-network storage within their own
>       data dissemination schemes.  Development of these requirements is
>       guided by a study of data access, search and management
>       capabilities used by Target Applications.  These requirements may
>       be met by a combination of existing protocols and new protocols.

This covers the producer side of storage access and control, but says nothing 
about the consumer side.  How do consumers access the storage?


>
>    o  Storage Requirements: Functional requirements necessary for the
>       back-end storage system employed by the DECADE server.

Is there a "front-end" storage system?  Again, what is meant by "back-end"?  How 
does that term add to the meaning here?


>       Development of these requirements is guided by a study of the data
>       access patterns used by Target Applications.  These requirements

While the behaviors of the data producer are of course important, I would think 
that the behaviors of the data consumers would be more so.  Yet that appears to 
be missed in the text.


>       should be met by the underlying data transport used by DECADE.  In
>       this document, we use "data transport" to refer to a protocol used
>       to read and write data from DECADE in-network storage.
>
>    Note that a third category also enumerates requirements on the
>    protocol used to discover DECADE Servers.
>
>
>
> Gu, et al.                 Expires May 3, 2012                  [Page 6]
> 
> Internet-Draft             DECADE Requirements              October 2011
>
>
>    It should also be made clear that the approach is to make DECADE a
>    simple protocol, while still enabling its usage within many Target
>    Applications.  For this reason, and to further reinforce the
>    distinction between DECADE and a storage system, in some cases we
>    also highlight the non-requirements of the protocol.  These non-
>    requirements are intended to capture behaviors that will NOT be
>    assumed to be needed by DECADE's Target Applications and hence not
>    present in the DECADE protocol.
>
>    Finally, some implementation considerations are provided, which while
>    not strictly requirements, are intended to provide guidance and
>    highlight potential points that need to be considered by the protocol
>    developers, and later by implementors.
>
>
> 4.  Protocol Requirements
>
>    This section details the requirements of DECADE protocol(s).
>
> 4.1.  Overall Protocol Requirements
>
> 4.1.1.  Connectivity Concerns
>
> 4.1.1.1.  NATs and Firewalls
>
>    REQUIREMENT(S):  DECADE client to server protocols SHOULD be usable
>        across firewalls and NAT (Network Address Translation) devices
>        without requiring additional network support (e.g., Application-
>        level Gateways).

How is that possible?  Given the degree to which NATs and firewalls get in the 
way, this would seem a difficult requirement to satisfy.

And this raises an issue which 'requirements'.  While it is quite good to add 
the rationale, there is also a question of feasibility.


>    RATIONALE:  Firewalls and NATs are widely used in the Internet today,
>        both in ISP (Internet Service Provider) and Enterprise networks
>        and by consumers.  Deployment of DECADE must not require
>        modifications to such devices (beyond, perhaps, 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.2.  Connections to Clients
>
>    REQUIREMENT(S):  DECADE SHOULD require that network connections be
>        made from DECADE clients to DECADE servers (i.e., not from the
>        server to the DECADE client).

This document uses the term 'servers', which the Problem document did not.  It 
is not clear what the term refers to, exactly, in this document.  Perhaps the 
distinction that is meant is producer and consumer?


>    RATIONALE:  Many household networks and operating systems have
>        firewalls and NATs configured by default to block incoming
>        connections.  To ease deployment by avoiding configuration
>        changes and help mitigate security risks, DECADE should not
>
>
>
> Gu, et al.                 Expires May 3, 2012                  [Page 7]
> 
> Internet-Draft             DECADE Requirements              October 2011
>
>
>        require clients to listen for any incoming network connections
>        (beyond what is required by any other already-deployed
>        application).

For many (all?)  p2p -- such at BitTorrent -- any consumer can become a 
producer.  That seems to be entirely at odds with this requirement.


>
> 4.1.2.  Security
>
> 4.1.2.1.  Secure Transport
>
>    REQUIREMENT(S):  DECADE MUST contain a mode in which all
>        communication between a DECADE client and server is over a secure
>        transport that provides confidentiality, integrity, and
>        authentication.

This suggests a transitive trust model of security that is entirely 
channel-based.  It precludes object-based security such as authentication, data 
integrity and confidentiality.  Also, transitive trust, absent quite a bit of 
end2end administrative structure, has a very problematic history when taken to 
Internet scale -- specifically when there is a large number of independent 
administrative domains.

It also means that special environments within an adequately operated 
administrative domain are required to incur overhead they don't need.  That is, 
a group operating with this mechanism, in an environment that permits adequate 
trust without satisfying this requirement, nonetheless will be required to incur 
the cost of this requirement.


>    RATIONALE:  Target Applications may wish to write sensitive data.  To
>        satisfy this use case, DECADE must provide a mode in which all
>        communication between a DECADE client and server occurs over a
>        secure transport protocol (e.g., SSL/TLS).

Note the "may".  The applications also might not want to write sensitive data.

And by the way, is the 'may' here normative?  Probably not.


> 4.1.3.  Error and Failure Conditions
>
> 4.1.3.1.  Overload Condition
>
>    REQUIREMENT(S):  In-network storage, which is operating close to its
>        capacity limit (e.g., too busy servicing other requests), MUST be
>        permitted to reject requests and not be required to generate
>        responses to additional requests.  In-network storage MUST also
>        be permitted to redirect requests (see Section 4.1.3.5) as a
>        load-shedding technique.

"rejection" is usually an active process that includes generating a response.

I assume the actual requirement here is to permit /ignoring/ or /dropping/ 
requests that cannot be serviced.

Also, this model optimizes convenience for the storage component, at the expense 
of the user-side components (content producers and consumers.)  So the 
"customers" have to wait for timeouts.  If the overall system is to have any 
sort of reliability, that means that these users of the storage system will do 
retransmissions, since they won't know whether their request got lost or the 
storage server dropped it.  At a minimum, this requirement therefore imposes 
some sort of exponential backoff on retransmission by the users of the system. 
The requirements need to attend to effects on the IP network, as much as to the 
DECADE storage servers.

In other words, while the design is likely to require some amount of 
retransmission, no matter what the other requirements are, it is likely that 
this requirement makes the mechanism needed more and overall is likely to 
/reduce/ aggregate system performance.  And for reference, rejection notices 
tend to be cheap.

I suspect a more reasonable requirement -- if decent user/storage interaction is 
a goal -- is to have the storage server provide differential behavior, to 
optimize for activities that have priority -- for whatever priority model makes 
sense -- and give worse performance for 'lower' priority requests.

At the least, performance effects of this requirement need to be analyzed and 
documented better.  The rationale that is provided, below, is an entirely 
localized point and ignores larger end2end systems implications.


>    RATIONALE:  Forcing the in-network storage to respond to requests
>        when operating close to its capacity can impair its ability to
>        service existing requests, and thus is permitted to avoid
>        generating responses to additional requests.



> 4.1.3.2.  Insufficient Resources
>
>    REQUIREMENT(S):  DECADE MUST support an error condition indicating to
>        a DECADE client that resources (e.g., storage space) were not
>        available to service a request (e.g., storage quota exceeded when
>        attempting to write data).

As stated here, this requirement is directly at odds with the above 4.1.3.1. 
"Lack of capacity" is an example of resources not being available.


>
>    RATIONALE:  The currently-used resource levels within the in-network
>        storage are not locally-discoverable, since the resources (disk,
>        network interfaces, etc) are not directly attached.  In order to
>        allocate resources appropriately amongst remote clients, a client
>        must be able to determine when resource limits have been reached.
>        The client can then respond by explicitly freeing necessary
>        resources or waiting for such resources to be freed.
>
>
>
> Gu, et al.                 Expires May 3, 2012                  [Page 8]
> 
> Internet-Draft             DECADE Requirements              October 2011
>
>
> 4.1.3.3.  Unavailable and Deleted Data
>
>    REQUIREMENT(S):  DECADE MUST support error conditions indicating that
>        (1) data was rejected from being written, (2) deleted, or (3)
>        marked unavailable by a storage provider.

4.1.3.1-4 ought to be written as a single requirement, with a single sentence 
that dictates the conditions that are covered.  The current micro-granularity 
just makes the document large and actually less informative (since it encourages 
the reader to get lost in the details...)


>
>    RATIONALE:  Storage providers may require the ability to (1) avoid
>        storing, (2) delete, or (3) quarantine certain data that has been
>        identified as illegal (or otherwise prohibited).  DECADE does not
>        indicate how such data is identified, but applications using
>        DECADE should not break if a storage provider is obligated to
>        enforce such policies.  Appropriate error conditions should be
>        indicated to applications.
>
> 4.1.3.4.  Insufficient Permissions
>
>    REQUIREMENT(S):  DECADE MUST support error conditions indicating that
>        the requesting client does not have sufficient permissions to
>        access requested data objects.
>
>    RATIONALE:  DECADE clients may request objects to which they do not
>        have sufficent access permissions, and DECADE servers must be
>        able to signal that this has occurred.  Note that access
>        permissions may be insufficient due to a combination of the
>        credentials presented by a client as well as additional policies
>        defined by the storage provider.
>
> 4.1.3.5.  Redirection

Redirection is not an error condition, per se.  It probably should be handled in 
a section dealing with discovery and routing, to get to the correct server.


>    REQUIREMENT(S):  DECADE SHOULD support the ability for a DECADE
>        server to redirect requests to another DECADE server.  This may
>        either be in response to an error, failure, or overload
>        condition, or to support capabilities such as load balancing.

It might also cover cases in which the data have been moved.  ("it used to be 
here, but now it is stored over there")


>    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.

This implies a rather sophisticated knowledge by servers about other servers.


> 4.2.  Transfer and Latency Requirements
>
> 4.2.1.  Low-Latency Access
>
>
>
>
>
>
>
>
> Gu, et al.                 Expires May 3, 2012                  [Page 9]
> 
> Internet-Draft             DECADE Requirements              October 2011
>
>
>    REQUIREMENT(S):  DECADE SHOULD provide "low-latency" access for
>        application clients.  DECADE MUST allow clients to specify at
>        least two classes of services: lowest possible latency and
>        latency non-critical.

Absent a definition of low-latency, there is no way to tell whether the 
performance requirement is being met.

There also needs to be a much more technical definition of low-latency in terms 
of the overall system.  What pieces of end2end work need to be done differently?


>    RATIONALE:  Some applications may have requirements on delivery time
>        (e.g., live streaming [PPLive]).  The user experience may be
>        unsatisfactory if the use of in-network storage results in lower
>        performance than connecting directly to remote clients over a
>        low-speed, possibly congested uplink.  Additionally, the overhead
>        required for control-plane operations in DECADE must not cause
>        the latency to be higher than for a low-speed, possibly congested
>        uplink.  While it is impossible to make a guarantee that a system
>        using in-network storage will always outperform a system that
>        does not for every transfer, the overall performance of the
>        system should be improved compared with direct low-speed uplink
>        connections, even considering control overhead.
>
> 4.2.2.  Data Object Size
>
>    REQUIREMENT(S):  DECADE MUST allow for efficient data transfer of
>        small objects (e.g., 16KB) between a DECADE client and in-network
>        storage with minimal additional latency imposed by the protocol.

This needs to provide a technical definition of "efficient" as meant here. 
Otherwise there is no basis for telling whether the requirement is being met.

Also, does this apply to /all/ transfers?  Might there be alternate modes, for 
example, with one for small objects and another for large.


>    RATIONALE:  Though Target Applications are frequently used to share
>        large amounts of data (e.g., continuous streams or large files),
>        the data itself is typically subdivided into smaller chunks that
>        are transferred between clients.  Additionally, the small chunks

Frankly, the first sentence doesn't make any sense to me.  Or rather, it asserts 
a fact that doesn't make obvious sense.  This needs more explanation.


>        may have requirements on delivery time (e.g., in a live-streaming

Small data segments can produce lower latencies for individual segments but also 
can dramatically lower overall throughput, since there is higher aggregate 
segment-handling costs.  Worse, when the segments come in rapid streams, the 
collision/congestion issues get worse exponentially.


>        application).  DECADE must enable data to be efficiently
>        transferred amongst clients at this granularity.  It is important
>        to note that DECADE may be used to store and retrieve larger
>        objects, but protocol(s) should not be designed such that usage
>        with smaller data objects cannot meet the requirements of Target
>        Applications.

I believe these are typically competing design requirements.  A protocol good 
for one is typically not very good for the other, unless there's been an advance 
in design that I missed (which is entirely possible.)


>
> 4.2.3.  Communication among DECADE Servers
>
>    REQUIREMENT(S):  DECADE SHOULD support the ability for two in-network
>        storage elements in different administrative domains to write
>        and/or read data directly between each other (if authorized as
>        described in Section 4.7).  If such a capability is supported,
>        this MAY be the same (or a subset or extension of) as the DECADE
>        protocol(s) used by clients to access data.

There has been no previous discussion of administrative domains or permissions. 
  The probably meaning of an ADMD is good, but it needs to be defined.  There is 
also no concept of 'direct' versus 'indirect' reading or writing.

Requirements should be careful to cover all relevant cases.  For example, what 
about data exchange among servers within the /same/ administrative domain?

Also, there needs to be a technical meaning to "direct", here.  From the 
rationale, it appears that the assumed model is to have mediation by some other 
devices?


>
>
>
>
>
>
> Gu, et al.                 Expires May 3, 2012                 [Page 10]
> 
> Internet-Draft             DECADE Requirements              October 2011
>
>
>    RATIONALE:  Allowing server-to-server communication can reduce
>        latency in some common scenarios.  Consider a scenario when a
>        DECADE client is downloading data into its own storage from

Which kind of client?  Also, does downloading mean "retrieving"?  (upload and 
download can be ambiguous.)


>        another client's in-network storage.  One possibility is for the

"client's in-network storage"?  clients do not "have" or "own" storage.  Is the 
upload/download being done "through" the client?  If not, then how is this other 
client relevant?

I suspect this requirement comes from a model that assumes servers do not talk 
to each other and that, therefore, all data between servers goes through their 
clients?  Yet requirement 4.2.3 goes contrary to this.  At a minimum, this 
further suggests the need for there to be a statement of the model, the 
assumptions, and the like, before laying down requirements based on them.

By the way, I thought BitTorrent was a user2user direct transfer mechanism, yet 
it was one of only 2 example scenarios in the -problem document.  That is, it 
has no supporting infrastructure, such as storage servers.


>        client to first download the data itself, and then upload it to
>        its own storage.  However, this uploading causes unnecessary
>        latency and network traffic.  Allowing the data to be downloaded
>        from the remote in-network storage into the client's own in-
>        network storage can alleviate both.
>
> 4.3.  Data Access Requirements
>
> 4.3.1.  Reading/Writing Own Storage
>
>    REQUIREMENT(S):  DECADE MUST support the ability for a DECADE client
>        to read data from and write data to its own in-network storage.
>
>    RATIONALE:  Two basic capabilities for any storage system are reading
>        and writing data.  A DECADE client can read data from and write
>        data to in-network storage space that it owns.

The organization of the requirements in the documents seems odd, if this is 
where such a basic requirement is finally appearing.


>
> 4.3.2.  Access by Other Users
>
>    REQUIREMENT(S):  DECADE MUST support the ability for a user to apply
>        access control policies to users other than itself for its

This implies that particular users "own" particular instances of data.  The 
model for this needs to be stated.  For example, can there be more than one 
owner of a given instance?  Can different instances of the same data have 
different owners and different access control settings; if so, why?

Besides lacking a model, these requirements lack any sense of the scenarios that 
need to be supported.  This would provide much better motivation for many of the 
requirements than do individual rationales.


>        storage.  The users with whom access is being shared can be under
>        a different administrative domain than the user who owns the in-
>        network storage.  The authorized users may read from or write to
>        the user's storage.
>
>    RATIONALE:  Endpoints in Target Applications may be located across

What is an endpoint?  Is it the same as a client or a specific kind of client?


>        multiple ISPs under multiple administrative domains.  Thus, to be

Target applications constitute an application overlay on the Internet.  The 
relevance of routers and connections to them is that it defines a topology, 
determining which components of the application are "near" and which are not. 
However it is not immediately clear how the administrative organization of the 
routers is relevant.

This requirement appears to conflate administrative domains between IP routing 
service providers with administrative domains of target application producers 
and consumers.  Here, again, we need a description of the model that makes this 
relevant.


>        useful by Target Applications, DECADE allows a user to implement
>        access control policies for users that may or may not be known to
>        the user's storage provider.

Ahh.  It appears that the assumption is that storage is operated by an "ISP"?

However servers can be operated by many different types of organizations.  I 
suspect the model will be more useful to simply assert that storage servers can 
be operated by different organizations than those operating clients, and that 
different storage servers can be in different administrative domains -- that is, 
under different administrative author.


>
> 4.3.3.  Negotiable Data Transport Protocol
>
>    REQUIREMENT(S):  DECADE MUST support the ability for a DECADE client
>        to negotiate with its in-network storage about which protocol it
>        can use to read data from and write data to its In-network
>        storage.  DECADE MUST specify at least one mandatory protocol to
>        be supported by implementations; usage of a different protocol
>        may be selected via negotiation.
>
>
>
>
>
>
> Gu, et al.                 Expires May 3, 2012                 [Page 11]
> 
> Internet-Draft             DECADE Requirements              October 2011
>
>
>    RATIONALE:  Since typical data transport protocols (e.g., NFS and
>        WebDAV) already provide read and write operations for network
>        storage, it may not be necessary for DECADE to define such
>        operations in a new protocol.  However, because of the particular
>        application requirements and deployment considerations, different
>        applications may support different protocols.  Thus, a DECADE
>        client must be able to select an appropriate protocol also

The rationale is helpful.  However it implies some storage-related entity with 
which negotiation can be done.  What is it?  How is it operated?


>        supported by the in-network storage.  This requirement also
>        follows as a result of the requirement of Separation of Control
>        and Data Operations (Section 4.3.4).

On the average, it's better to have backward references rather than forward 
references.  Organizing things to support this tends to produce documents that 
establish a foundation before building upon it.


>
> 4.3.4.  Separation of Data and Control Policies
>
>    REQUIREMENT(S):  DECADE Protocol(s) MUST only provide a minimal set
>        of core operations to support diverse policies implemented and
>        desired by Target Applications.

I have no idea what this means.  There is no basis for knowing what satisfies it.

Also, applications don't have desires.

For generic requirements about this kind of basic design philosophy it is often 
most helpful to cast a requirement in terms of tradeoffs.


>
>    RATIONALE:  Target Applications support many complex behaviors and
>        diverse policies to control and distribute data, such as (e.g.,
>        search, index, setting permissions/passing authorization tokens).
>        Thus, to support such Target Applications, these behaviors must
>        be logically separated from the data transfer operations (e.g.,
>        read, write).  Some minimal overlap (for example obtaining
>        credentials needed to encrypt or authorize data transfer using
>        control operations) may be required to be directly specified by
>        DECADE.
>
> 4.4.  Data Management Requirements
>
> 4.4.1.  Agnostic of reliability
>
>    REQUIREMENT(S):  DECADE SHOULD remain agnostic of reliability/
>        fault-tolerance level offered by storage provider.

Latency is a form of service.  So latency matters but reliability and 
fault-tolerance do not?  Why?


>
>    RATIONALE:  Providers of a DECADE service may wish to offer varying
>        levels of service for different applications/users.  However, a
>        single compliant DECADE client should be able to use multiple
>        DECADE services with differing levels of service.
>
> 4.4.2.  Data Object Attributes
>
>    REQUIREMENT(S):  DECADE MUST support the ability to associate
>        attributes with data objects with a scope local to a DECADE
>        server, and for DECADE clients to query these attributes.  DECADE
>        protocol(s) MUST transmit any attributes using an operating
>        system-independent and architecture-independent standard format.

What does it mean to be "architecture-independent"?


>        DECADE protocol(s) MUST be designed such that new attributes can
>        be added by later protocol revisions or extensions.
>
>
>
> Gu, et al.                 Expires May 3, 2012                 [Page 12]
> 
> Internet-Draft             DECADE Requirements              October 2011
>
>
>    RATIONALE:  DECADE supports associating attributes (e.g., a time-to-
>        live, creation timestamp, or object size) with a data object.

Where is the full set of required/permitted attributes specified?

Otherwise, the Rationale is quit helpful.


>        These attributes are local to a data object stored by a
>        particular DECADE server, and are thus not applied to any DECADE
>        server or client to which the data object is copied.  These
>        attributes may be used as hints to the storage system, internal
>        optimizations, or as additional information queryable by DECADE
>        clients.
>
> 4.4.3.  Time-to-live for Written Data Objects
>
>    REQUIREMENT(S):  DECADE MUST support the ability for a DECADE client
>        to indicate a time-to-live value (or expiration time) indicating
>        a length of time until particular data can be deleted by the in-
>        network storage element.
>
>    RATIONALE:  Some data objects written by a DECADE client may be
>        usable only within a certain window of time, such as in live-
>        streaming P2P applications.  Providing a time-to-live value for
>        data objects (e.g., at the time they are written) can reduce
>        management overhead by avoiding many 'delete' commands sent to
>        in-network storage.  The in-network storage may still keep the
>        data in cache for bandwidth optimization.  But this is guided by
>        the privacy policy of the DECADE provider.

It isn't just the "effort" of the commands themselves.  To be able to do the 
commands requires knowing where they are needed.  This means a detailed 
knowledge of every server caching a copy.


>
> 4.4.4.  Offline Usage
>
>    REQUIREMENT(S):  DECADE MAY support the ability for a user to provide
>        authorized access to its in-network storage even if the user has
>        no DECADE applications actively running or connected to the
>        network.

What does it mean for "a user to provide authorized access"?  This again invokes 
an architecture and security model that hasn't been specified.


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

"Data owners can assert persistent data access authorization for other users"?

1. Data owners can assign access to other users.

2. The assignment can persist even when the owner is absent.

3. Users can be "remote" (which presumably means in an other admin domain?)

These are three separate requirements.  It's ok to state them together but each 
needs to be explained in terms of need.  The Rationale provided here really is 
the 'what' not the 'why'.  That is, it provides basic meaning, not an 
explanation of why the requirement is needed.

But again, this all gets clearer with an integrated description of the model and 
architecture, rather than these piecemeal requirements.


>
> 4.5.  Data Naming Requirements
>
> 4.5.1.  Unique Names
>
>    REQUIREMENT(S):  DECADE MUST support a naming scheme that ensures a
>        high probability of uniqueness and supports the operation of
>        DECADE servers under diverse administrative domains with no
>        coordination.  DECADE SHOULD provide a mechanism (minimally
>        rejection) to handle the improbable case of a collision.
>

"uniqueness" can have variable attributes.  Not just statistical, but scope and 
persistence.  What are the requirements for these and why?

The collision-handling requirement presumes that collision will be detected...


>
>
> Gu, et al.                 Expires May 3, 2012                 [Page 13]
> 
> Internet-Draft             DECADE Requirements              October 2011
>
>
>    RATIONALE:  When writing a data object, a DECADE Client should be
>        able to write it without being concerned over whether an object
>        of the same name already exists, unless the existing object
>        contains the exact same data.

Frankly, this rationale is bizarre.  I don't think I've ever seen a scenario 
that supports this and scales.


>    Note that it may be reasonable for
>        DECADE to satisfy this requirement probabilistically (e.g., using
>        a hashing mechanism).  As a result, it is wise to provide a
>        collision handling mechanism, even if the probability of
>        collisions is extremely low.

Again, how can collisions be detected?


> 4.6.  Resource Control
>
> 4.6.1.  Multiple Applications
>
>    REQUIREMENT(S):  DECADE SHOULD support the ability for users to
>        define resource sharing policies for multiple applications
>        (DECADE clients) being run/managed by the user.

What does this mean?  The text in a Rationale should not be required in order to 
understand what a requirement means.


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

"resource sharing policies between applications" does not have an obvious 
meaning for me, especially given the preceding statement that the apps don't 
communicate with each other.


>
>        One possibility is for a user to indicate the particular resource
>        sharing policies between applications out-of-band (not using a
>        standard protocol), but this requirement may manifest itself in
>        passing values within DECADE protocol(s) to identify individual
>        applications.  Such identifiers can be either user-generated or
>        server-generated and do not need to be registered by IANA.
>
> 4.6.2.  Per-Remote-Client, Per-Data Control
>
>    REQUIREMENT(S):  A DECADE client MUST be able to assign resource
>        policies (bandwidth share, storage quota, and network connection
>        quota) to individual remote clients for reading from and writing
>        particular data to its in-network storage within a particular
>        range of time.  The DECADE server MUST enforce these constraints.

It's unlikely the data owner can specify network performance characteristics. As 
stated, this requirement has more to do with the network behavior than the 
server behavior and is unlikely to be met, except in very constrained environments.

Perhaps only server performance characteristics is meant?  This raises a 
question of resolving competing policies amongst servers shared by multiple owners.


>
>    RATIONALE:  Target Applications can rely on control of resources on a
>        per-remote-client or per-data basis.  For example, application
>        policy may indicate that certain remote clients have a higher
>        bandwidth share for receiving data [LLSB08].  Additionally,
>        certain data (e.g., chunks) may be distributed with a higher
>        priority.  As another example, when allowing a remote client to
>        write data to a user's in-network storage, the remote client may
>
>
>
> Gu, et al.                 Expires May 3, 2012                 [Page 14]
> 
> Internet-Draft             DECADE Requirements              October 2011
>
>
>        be restricted to write only a certain amount of data.  Since the
>        client may need to manage multiple clients accessing its data, it
>        should be able to indicate the time over which the granted
>        resources are usable.  For example, an expiration time for the
>        access could be indicated to the server after which no resources
>        are granted (e.g., indicate error as access denied).
>
> 4.6.3.  Server Involvement
>
>    REQUIREMENT(S):  A DECADE client SHOULD be able to indicate to a
>        DECADE server, without itself contacting the server, resource
>        control policies for remote clients' requests.

This appears to require some sort of unstated infrastructure, which is likely to 
reduce to having the client contact the server "indirectly".  In any event, it 
is not obvious what this requirement really does mean, in technical terms.


>
>    RATIONALE:  One important consideration for in-network storage
>        elements is scalability, since a single storage element may be
>        used to support many users.  Many Target Applications use small
>        chunk sizes and frequent data exchanges.  If such an application
>        employed resource control and contacted the in-network storage
>        element for each data exchange, this could present a scalability
>        challenge for the server as well as additional latency for
>        clients.
>
>        Our preferred alternative is to let requesting users obtain
>        signed resource control policies (in the form of a token) from

signed -> assigned (?)


>        the owning user, and then users can then present the policy to
>        the storage directly.  This can result in reduced messaging
>        handled by the in-network storage.

So the architectural point is that a data owner mediates interactions between 
other consumers and the storage server?

However the stated requirement and the given rational appear to cover 
conflicting scenarios.

Perhaps I'm confusing which actors are doing what.  A diagram might help.


>
> 4.7.  Authorization
>
> 4.7.1.  Per-Remote-Client, Per-Data Read Access
>
>    REQUIREMENT(S):  A DECADE Client MUST be able to control which
>        individual remote clients are authorized to read particular data
>        from its in-network storage.

How is this different from 4.6.2?  Why are they in different sections?


>
>    RATIONALE:  A Target Application can control certain application-
>        level policies by sending particular data (e.g., chunks) to
>        certain remote clients.  It is important that remote clients not
>        be able to circumvent such decisions by arbitrarily reading any
>        data in in-network storage.
>
> 4.7.2.  Per-User Write Access

When requirements are only tiny variants of each other, listing them separately 
inflates the document unnecessarily.  Instead, make a single requirement that 
cover the variants together.


>
>
>
>
>
>
>
> Gu, et al.                 Expires May 3, 2012                 [Page 15]
> 
> Internet-Draft             DECADE Requirements              October 2011
>
>
>    REQUIREMENT(S):  A DECADE Client MUST be able to control which
>        individual remote clients are authorized to write data into its
>        in-network storage.
>
>    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
>        remote clients to write data directly to a user's in-network
>        storage.  Thus, a DECADE client should be able to grant only
>        certain remote clients this privilege.
>
> 4.7.3.  Default Access Permissions
>
>    REQUIREMENT(S):  Unless read or write access is granted by a DECADE
>        Client to a remote client, the default access MUST be no access.

This seems to mean that it is not possible to declare some data as fully public 
like a web page, so that it is available to whatever client attempts to consume it?


>
>    RATIONALE:  The current leading proposal for an access control model
>        in DECADE is via token passing, resulting in a system with little
>        state on the server side.
>
> 4.7.4.  Authorization Checks
>
>    REQUIREMENT(S):  In-network storage MUST check the authorization of a
>        client before it executes a supplied request.  The in-network
>        storage MAY use optimizations to avoid such authorization checks
>        as long as the enforced permissions are the same.

In formal terms, I suspect that optimizations are, themselves, a form of 
authorization check.  That is, I suspect this Requirement isn't quite stating 
the actual requirement.


>    RATIONALE:  Authorization granted by a DECADE client are meaningless

are -> is (?)


>        unless unauthorized requests are denied access.  Thus, the in-
>        network storage element must verify the authorization of a
>        particular request before it is executed.
>
> 4.7.5.  Cryptographic Credentials
>
>    REQUIREMENT(S):  Access MUST be able to be granted using
>        cryptographic credentials.

This appears to be universally mandating a very heavyweight security model that 
has little-to-no large-scale deployment over the open Internet...

Perhaps 'cryptographic credentials' means something other than a PKI?


>    RATIONALE:  DECADE clients may be operating on hosts without constant
>        network connectivity or without a permanent attachment address
>        (e.g., mobile devices).  To support access control with such
>        hosts, DECADE servers must support access control policies that
>        use cryptographic credentials, not simply by tying access to IP
>        addresses.

Hmmm.  I think the requirement that is intended here is that requests must 
contain their own authorization?  In addition the requirement is that the 
authorization be based on cryptography?  Why this latter requirement?  Aren't 
there any scenarios that can be satisfied with something simpler?

Also, the concern for a history of a scalable mechanism that satisfies this 
seems to be problematic.


> 4.7.6.  Server Involvement
>
>
>
>
>
>
>
> Gu, et al.                 Expires May 3, 2012                 [Page 16]
> 
> Internet-Draft             DECADE Requirements              October 2011
>
>
>    REQUIREMENT(S):  A DECADE client SHOULD be able to indicate, without
>        contacting the server itself, access control policies for remote
>        clients' requests.
>
>    RATIONALE:  See discussion in Section 4.6.3.

Exactly.  So how is this different and why is it in a separate section?


> 4.7.7.  Protocol Reuse
>
>    REQUIREMENT(S):  If possible, DECADE SHOULD reuse existing protocol
>        and mechanisms for Authentication, Access, and Authorization
>        (AAA).

Isn't this requirement more universal than for AAA?  Doesn't it cover all DECADE 
protocols?


>    RATIONALE:  If possible, reusing an existing AAA protocol/mechanism
>        will minimize the development required by applications, and will
>        maximize interoperability of the DECADE protocol with existing
>        infrastructure.
>
> 4.8.  Non-Requirements
>
> 4.8.1.  Application-defined Properties and Metadata
>
>    REQUIREMENT(S):  DECADE MUST NOT provide a mechanism for associating
>        Application-defined properties (metadata) with data objects
>        beyond what is provided by Section 4.4.2.
>
>    RATIONALE:  Associating key-value pairs that are defined by Target
>        Applications with data objects introduces substantial complexity
>        to the DECADE protocol.  If Target Applications wish to associate
>        additional metadata with a data object, possible alternatives
>        include (1) managing such metadata within the Target Application
>        itself, (2) storing metadata inside of the data object, or (3)
>        storing metadata in a different data object at the DECADE server.

While the suggested alternatives do seem the better approach, it's not clear to 
me that the prohibited feature is all that onerous.  Given the requirement of 
4.4.2, why isn't it reasonably straightforward to expand the capability to cover 
application metadata?

An example of possible benefit for this would be a common way for applications 
to associate operational metadata that the handling system could use, without 
the handling system having to know anything about the nature of the application...


>
> 5.  Storage Requirements
>
>    This section details the requirements of the underlying storage used
>    to support the DECADE protocol(s).
>
> 5.1.  Immutable Data
>
>    REQUIREMENT(S):  DECADE MUST only store and manage data objects that
>        are immutable once they are written to storage.

No javascript in the data?   No web pages that include external data?  Perhaps 
"immutable " needs to be defined precisely?


>
>    RATIONALE:  Immutable data objects are an important simplification in
>        DECADE.  Reasonable consistency models for updating existing
>        objects would significantly complicate implementation (especially
>        if implementation chooses to replicate data across multiple
>
>
>
> Gu, et al.                 Expires May 3, 2012                 [Page 17]
> 
> Internet-Draft             DECADE Requirements              October 2011
>
>
>        servers).  If a user needs to update a resource, it can write a
>        new resource and then distribute the new resource instead of the
>        old one.
>
> 5.2.  Explicit Deletion of Data
>
>    REQUIREMENT(S):  DECADE MUST support the ability for a DECADE client
>        to explicitly delete data from its own in-network storage.
>
>    RATIONALE:  A DECADE client may continually be writing data to its
>        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
>        data may need to be removed to make room for additional data.  A
>        DECADE client should be able to explicitly remove particular
>        data.  This may be implemented using existing protocols.
>
> 5.3.  Multiple writing
>
>    REQUIREMENT(S):  DECADE MUST NOT allow multiple simultaneous writers
>        for the same object.  Implementations MUST raise an error to one
>        of the writers.

1. This implies a locking mechanism?

2. This implies that writes are not atomic?

What is the implied model that permits multiple writers? Different ones are 
possible.


>
>    RATIONALE:  This avoids data corruption in a simple way while
>        remaining efficient.  Alternately, the DECADE server would need
>        to either manage locking, handle write collisions, or merge data,
>        all of which reduce efficiency and increase complexity.
>
> 5.4.  Multiple reading
>
>    REQUIREMENT(S):  DECADE MUST allow for multiple simultaneous readers
>        for an object.
>
>    RATIONALE:  One characteristic of Target Applications is the ability
>        to upload an object to multiple clients.  Thus, it is natural for
>        DECADE to allow multiple readers to read the content
>        concurrently.
>
> 5.5.  Reading before completely written
>
>    REQUIREMENT(S):  DECADE MAY allow readers to read from objects before
>        they have been completely written.

Like playing a show on a DVR before the show has finished broadcast?...


>    RATIONALE:  Some Target Applications (in particular, P2P streaming)
>        can be sensitive to latency.  A technique to reduce latency is to
>        remove store-and-forward delays for data objects (e.g., make the
>        object available before it is completely written).  Appropriate
>        handling for error conditions (e.g., a disappearing writer) needs
>        to be specified.
>
>
>
> Gu, et al.                 Expires May 3, 2012                 [Page 18]
> 
> Internet-Draft             DECADE Requirements              October 2011
>
>
> 5.6.  Hints concerning usage of written 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).

Isn't this the same as 4.4.2 or one of the other requirements that refers to TTL?

Also, what is the set of 'hints'?  Where are/will they be defined?  It's 
difficult to think of TTL as a 'hint'.


>    RATIONALE:  Different Target Applications may have different usage
>        patterns for objects written to in-network storage.  For example,
>        a P2P live streaming application may indicate to a DECADE server
>        that the objects are expected to have a short time-to-live, but
>        read frequently.  The DECADE server may then opt to persist the
>        objects in memory instead of in disk.
>
> 5.7.  Writing model
>
>    REQUIREMENT(S):  DECADE storage MUST provide at least a writing model
>        (while writing an object) that appends data to data already
>        written.

provide at least a writing model...that appends
->
provide a writing model... that at least appends (?)


>
>    RATIONALE:  Depending on the object size (e.g., chunk size) used by a
>        Target Application, the application may need to send data to the
>        DECADE server in multiple packets.  To keep implementation
>        simple, the DECADE must at least support the ability to write the
>        data sequentially in the order received.  Implementations MAY
>        allow application to write data in an object out-of-order (but
>        MUST NOT overwrite ranges of the object that have already been
>        written).
>
> 5.8.  Storage Status
>
>    REQUIREMENT(S):  A DECADE client MUST be able to read current
>        resource usage (including list of written data objects), resource
>        quotas, 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.  DECADE protocol(s) MUST support the ability
>        for a DECADE client to read aggregated resource usage information
>        (across all other clients to which it has authorized access), and
>        MAY support the ability to request this information for each
>        other authorized client.
>
>    RATIONALE:  The resources used by a client are not directly-attached
>        (e.g., disk, network interface, etc).  Thus, the client cannot
>        locally determine how such resources are being used.  Before
>        storing and retrieving data, a client should be able to determine
>        which data is available (e.g., after an application restart).
>        Additionally, a client should be able to determine resource
>
>
>
> Gu, et al.                 Expires May 3, 2012                 [Page 19]
> 
> Internet-Draft             DECADE Requirements              October 2011
>
>
>        availability to better allocate them to remote clients.  Due to
>        scalability issues, it is not required that DECADE support
>        returning usage information broken down by each remote client
>        which has been authorized access, but this feature may be useful
>        in certain deployment scenarios.
>
>
> 6.  Discovery Requirements
>
> 6.1.  Requirements
>
> 6.1.1.  Locating DECADE Servers
>
>    REQUIREMENT(S):  The DECADE Discovery mechanism MUST allow a DECADE
>        Client to identify one or more DECADE Servers to which it is
>        authorized to read/write data and to which it may authorize other
>        DECADE Clients to read/write data, or fail if no such DECADE
>        Servers are available.

Every consumer must be able to redistribute the information or otherwise act as 
an administrator for access to the information?  That seems an onerous 
requirement to have as a MUST.


>
>    RATIONALE:  A basic goal of DECADE is to allow DECADE Clients to
>        read/write data for access by other DECADE Clients or itself.
>        Executing the Discovery process should result in a DECADE Client
>        finding a DECADE Server that it can use for these purposes.  It
>        is possible that no such DECADE Servers are available.  Note that
>        even if a DECADE Client may not successfully locate a DECADE
>        Server that fits these criteria, it may still read/write data
>        from/to a DECADE Server if authorized by another DECADE Client.
>
> 6.1.2.  Support for Clients Behind NATs and Firewalls
>
>    REQUIREMENT(S):  The Discovery mechanism MUST support DECADE Clients
>        operating behind NATs and Firewalls without requiring additional
>        network support (e.g., Application-level Gateways).
>
>    RATIONALE:  NATs and Firewalls are prevalent in network deployments,
>        and it is common for Target Applications that include a DECADE
>        Client to be deployed behind these devices.

How is this different from 4.1.1.1?  Why is it separated from that requirement?


> 6.1.3.  Prefer Existing Protocols
>
>    REQUIREMENT(S):  The DECADE Server discovery mechanism SHOULD
>        leverage existing mechanisms and protocols wherever possible.
>
>    RATIONALE:  Existing protocols such as DNS and DHCP are widespread.
>        Using existing protocols, or combinations of the protocols that
>        have been specified in other contexts, is strictly preferred over
>        developing a new discovery protocol for DECADE.
>
>
>
>
> Gu, et al.                 Expires May 3, 2012                 [Page 20]
> 
> Internet-Draft             DECADE Requirements              October 2011
>
>
> 7.  Future Considerations
>
>    This section enumerates considerations that should be taken into
>    account during the DECADE design and implementation.  They have been

In other words, these are /current/ design considerations...


>    intentionally omitted as requirements since they are either out of
>    scope or implementation-dependent.  Nevertheless, enumerating them
>    may help to guide future application of the requirements included in
>    this document.
>
> 7.1.  Fairness
>
>    To provide fairness among users, the in-network storage provider
>    should assign resource (e.g., storage, bandwidth, connections) quota
>    for users.  This can prevent a small number of clients from occupying
>    large amounts of resources on the in-network storage, while others
>    starve.

There are many approaches to fairness.  A quota system is only one.  What is the 
basis for choosing this?


> 7.2.  Removal of Duplicate Data Objects
>
>    There are actually two possible scenarios.  The first is the case of
>    removing duplicates within one particular DECADE server (or logical
>    server).  While not a requirement, as it does not impact the
>    protocol, a DECADE server may implement internal mechanisms to
>    monitor for duplicate objects and use internal mechanisms to prevent
>    duplication in internal storage.
>
>    The second scenario is removing duplicates across a distributed set
>    of DECADE servers.  DECADE does not explicitly design for this, but
>    does offer a redirection mechanism (Section 4.1.3.5) that is one
>    primitive that may be used to support this feature in certain
>    deployment scenarios.
>
> 7.3.  Gaming of the Resource Control Mechanism
>
>    The particular resource control policy communicated by a DECADE
>    protocol and enforced by the scheduling system of a DECADE
>    implementation may be open to certain gaming by clients. for example
>    by specifying many small peers to increase total throughput or
>    inciting overload conditions at a DECADE server.  Identifying and
>    protecting against all such opportunities for gaming is outside the
>    scope of this document, but DECADE protocol(s) and implementations
>    SHOULD be aware that opportunities to game the system may be
>    attempted.
>
>
> 8.  Security Considerations
>
>    The security model is an important component of DECADE.  It is
>
>
>
> Gu, et al.                 Expires May 3, 2012                 [Page 21]
> 
> Internet-Draft             DECADE Requirements              October 2011
>
>
>    crucial for users to be able to manage and limit distribution of
>    content to only authorized parties, and the mechanism needs to work
>    on the general Internet which spans multiple administrative and
>    security domains.  Previous sections have enumerated detailed
>    requirements, but this section discusses the overall approach and
>    other considerations that do not merit requirements.
>
> 8.1.  Authentication and Authorization
>
>    DECADE only uses authentication when allowing a particular client to
>    access its own storage at a server.  DECADE servers themselves do not
>    authenticate other clients which are reading/writing a client's own
>    storage.  Instead, DECADE relies on clients to authenticate others to
>    access its storage, and then communicate the result of that
>    authentication to the DECADE server so that the DECADE server may
>    implement the necessary authorization checks.

Decade apparently also will not authenticate the data producer?  or the data author?


> 8.2.  Encrypted Data
>
>    DECADE Servers provide the ability to write raw data objects (subject
>    to any policies instituted by the owner/administrator of the DECADE
>    server, which are outside of the scope of this document).  Thus,
>    DECADE clients may opt to encrypt data before it is written to the
>    DECADE Server.  However, DECADE itself does not provide encryption of
>    data objects other than is provided by Section 4.1.2.1.

I believe the correct security term for this is "Confidentiality", parallel to 
"Authentication".  Encryption is merely a technique for performing confidentiality.

Also, this assumes that client and server use the same confidentiality schemes. 
  As a rule, these need to be specified as part of the service definition.


-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net