Subject: Re: [decade] Reviews of the Decade Requirements draft

From: "Woundy, Richard" <[email-masked]>
Date: Mon, 6 Jun 2011 15:20:05 +0000

Folks, just a reminder that we are looking for reviews of the DECADE Requirements draft to be posted to the mailing list by today. If you need a little extra time, let me know.

-- Rich

From: Woundy, Richard
Sent: Monday, May 23, 2011 11:04 AM
To: [email-masked]
Cc: Songhaibin; Woundy, Richard
Subject: Reviews of the Decade Requirements draft

Folks,

We would like to prepare the requirements draft, draft-ietf-decade-reqs-02<http://datatracker.ietf.org/doc/draft-ietf-decade-reqs/>, for working group last call in late June / July.

The chairs are looking for document reviews to be sent to the mailing list by Monday June 6. We already have three volunteers from our session in Prague. Additional draft reviews by the deadline would be timely and greatly appreciated.

After the authors incorporate the feedback from the reviews in a new draft iteration, the chairs expect to take the draft to WGLC.

-- Rich

---

From: "Mcdysan, David E" <[email-masked]>
Date: Mon, 6 Jun 2011 17:06:07 -0400

Here is my review of the Decade requirements draft.

There are numerous grammatical and wording suggestions that I have sent to
the authors and chairs in a revision marked Word document. The comments
are also placed in context

Dave
----------------------------
Terminology 
- Suggest defining what is meant by "data transport" (e.g., access to
stored data) since the term "transport" has another meaning in the IETF.

- Read, write used in many places; but other verb pairs also used (e.g.,
retrieve, store). Pick one set of verbs and use consistently.

Section 2, last paragraph  define what is meant by "multipath."

Section 2, last paragraph  - Suggest deleting the last sentence. It adds
no new thought.

Section 4, Unnecessary level of indentation for 4.1  suggest removal.

4.1.1.2.1.  NATs
and Firewalls  Suggest including Enterprises in list of users of
firewalls.

4.1.1.2.2. 
Connections to Clients  Describe the default behavior (e.g., block
incoming connections)

4.1.1.3.1. Secure Transport

Is there an option for the stored content to be encrypted? Is the
assumption that access control provides adequate security? If so, then
this should be stated.

4.1.1.3.2.  Connections to Clients

This text is almost identical to 4.1.1.2.2. Only need to state this in one
place.

4.1.1.4.1.  Overload Condition - First sentence of Rationale is same
thought as requirement -- suggest deletion.

4.1.2.2.  Indirect Transfer - Suggest adding "if authorized and
authenticated as described in
requirement (insert reference)" to the end of the requirement

4.1.3.2.  Access by Other Users
* Suggest there be a default mode where read access can be performed by
any user.
* Suggest stating that use of already standardized
access control and authoritzation protocols is desirable. If this requires
configuration of access control lists, this becomes a significant amount of
configuration. (This differs from the architecture draft which focuses on
token-based authentication, which would seem to scale better).

4.1.5.1.  Unique Names

Need to state the scope of uniqueness   a single storage provider or all
storage providers?

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

- Need to specify the types of quotas to be supported by the protocol in
the requirement text, not just in the rationale.

4.1.6.3.  Server Involvement

Where are resource control policies specified? Is this the same as quotas?
If so, suggest using only one term.

4.1.7.  Authorization
These requirements seem similar to 4.1.3.2.. Suggest merging these
requirements.

6.1.1.  Explicit Deletion of Stored Data

Not sure how this relates to the unique naming requirement.  Is this
intended to replace
a delete and write with a single operation to be more efficient?

6.1.6.  Writing model

Append implies ordering to me, while the rationale states the motivation
for writing out of order data. Seems like you are specifying random
(write) access to the object.

6.1.7.  Storage Status

Regarding information on resource usage by other clients; Is this on a per
client basis, or a summation across all clients? (Summation would seem to
scale better.)

6.2.1.  No ability to update

Unless the Overwrite flag is present? See 6.1.1.

Section 7/8:    Removal of Duplicate Records Across Servers: The circular
references between sections  7 and 8 is unnecessary. Suggest picking one
place to state this issue.

Section 9: Suggest adding access control to this section with a discussion
of its uses when scaling is not an issue.

From:  "Woundy, Richard" <[email-masked]>
Date:  Mon, 23 May 2011 11:03:50 -0400
To:  "[email-masked]" <[email-masked]>
Subject:  [decade] Reviews of the Decade Requirements draft

>Folks,
> 
>We would like to prepare the requirements draft,
>draft-ietf-decade-reqs-02
><http://datatracker.ietf.org/doc/draft-ietf-decade-reqs/>, for working
>group last call in late June / July.
> 
>The chairs are looking for document reviews to be sent to the mailing
>list by Monday June 6. We already have three volunteers from our session
>in Prague. Additional draft reviews by the deadline would be timely and
>greatly appreciated.
> 
>After the authors incorporate the feedback from the reviews in a new
>draft iteration, the chairs expect to take the draft to WGLC.
> 
>-- Rich

---

From: Börje Ohlman <[email-masked]>
Date: Tue, 7 Jun 2011 16:03:39 +0200

Dear All,

Here is my review of the Decade Architecture draft.

Best regards,
			Börje

Overall comments
------------------------

The overall impression of the draft is very good. I find it clear and coherent, on most accounts. It is also well structured and seems to be fairly complete.

I can see two types of management and charging operations in decade. One type is when a decade client is managing its resources at a decade server. Another type is when a decade service provider is managing the resources at a decade server. I feel that these two types of management and charging operations are not clearly separated in the current draft.

There is a 'Data index' box in figure 1, but it is not described in the current draft. Some explanation of its functionality and purpose would help. In a number of places the concept 'index' is referred to, I assume that are references to this 'Data index', but that is not clear from the current draft. This also makes the paragraphs referring to the 'index' hard to fully comprehend.

There is a 'Data Search Capability' defined. To me the purpose of this is unclear. It is especially unclear if this should be part of the decade layer or if it should be part of the application layer. Maybe this will be clearer when the 'Data index' is described as it seems that the Search is using the index.

Is it allowed for decade service providers to oversell the resources of their servers (both bandwidth and storage), similar to airline overbooking? I think overbooking should be allowed to maximize resource utilization. Especially regarding bandwidth I think it is unavoidable. It would be good if this was addressed in the draft, e.g. in 4.2.

When decade accepts an object for storage, does it offer persistent storage (e.g. in case of node failures) or not? This should be made clear. If not, there should be a way to check if an object is still there. How should that be done? Could the status message in 5.1.3 be used for this? Another place where this should be explicitly mentioned is in 5.2.1.

Neither 'DECADE client' nor 'DECADE user' is defined in section 2.

Specific comments
------------------------

Abstract:
The abstract should be less p2p specific and make clear that decade can well be used in other contexts than p2p.

p5 §1
Same comment as abstract.
Please spell out abbreviations.
s/On the other hand, it can be cheaper to upgrade the core infrastructure, which involves fewer components that are shared by many subscribers./Therefore, it can be cheaper to upgrade the core infrastructure, which involves fewer components that are shared by many subscribers./

2.3
I suggest to add: "Content providers might be mobile."

2.6 §2
It is unclear what this § is trying to say, it is unclear what a "swarm" is here. Please reformulate and explain or remove.

3.1 §6
"By Application, we mean the broad sense that includes other control plane protocols." It is unclear what this sentence is trying to say. Please reformulate and explain or remove.

4.1.3.2
The concept 'index' needs to be explained, see overall comments.

4.2..1 §2
Also lack of server resources could be a reason, at least if overbooking is allowed, also see overall comments.

4.2.3
The draft should not refer to 'disks' as the only storage medium. A technology neutral term should be used.

4.3 §2
It is not clear what 'evolve' refers to, it could be decade, DRP or SDT. I think all three are possible and it would be good to make this explicit.

4.3.2
Mention explicitly that decade will allow for a limited number of alternatives.

4.6 §2
It is unclear to me what this § is trying to say. Especially I don't understand what 'complex behavior' is referring to. An example might help. If § not explained better remove it.

4.6.3
There is a 'Data Search Capability' defined. To me the purpose of this is unclear. It is especially unclear if this should be part of the decade layer or if it should be part of the application layer. Maybe this will be clearer when the 'Data index' is described as it seems that the Search is using the index.

4.6.4
"All methods of access control are supported: public-unrestricted, public-restricted and private." Who must support them? Must all decade instances support 'all' methods?. Is the three methods listed here the only possible ones? It would be good with a reference defining these methods.

4.6.5
To avoid confusion I think it would be good to mention very explicitly that this interface is for the users to manage the server resources that they have been allocated by the decade service provider and that how the service provider is allocating the resources to the individual users is done via a different interface. Also see overall comments.

4.6.6
"This is outside the scope of the DECADE architecture." Why is the discovery mechanism out of scope? I would see it as a key architectural component. Please provide a motivation why it is out of scope.

5.1
"and DRP allows one instance of such an application, e.g., an application endpoint, to configure access control and resource sharing policies on a set of servers." Does this imply that an operation can be performed on 'a set of servers' at once or is the intention just to state that one application instance can employ many servers? It would be good to be clear if multiple servers can be configured with one 'command' or if they have to be addressed individually.

5.1.2
"Expiration time" I think it also makes sense to have an "Earliest time" when the token becomes valid, e.g. to make redistribution of large numbers of tokens possible. I suggest to change "Expiration time" to something like "Valid time", with both a start and a stop time, either could of course be optional. One could even consider allowing for more elaborate time schedules making tokens valid during certain parts of a day or week (e.g. only during working hours).

5.1.3 §1
"DRP provides a request service for status information that DECADE clients can use to request information from a DECADE server."
In 3.5.2 it is stated that resources are granted per user, not per decade client. I think the terminology should be consistent and it should be made clear the relationship between 'user' and 'decade client'.
Also it is unclear how the storage provider get information about the status of a specific decade server. If that is out of scope (which I'm not sure it should be) I think it would be good to mention that explicitly.
Neither 'DECADE client' nor 'DECADE user' is defined in section 2.

5.1.3§2
"status information per application context on a specific server:"
Either beginning of sentence is missing, or just  a capital 'S'. 
Also it would be good if 'application context' was defined, it is a term that can be interpreted in many ways.

5.1.4
"TTL" I think, also here (see 5.1.2), that it also makes sense to have a "Going live time" when the object becomes available, e.g. to make it possible to pre-populate caches. I suggest to change "TTL" to something like "Valid time", with both a start and a stop time, either could of course be optional. One could even consider allowing for more elaborate time schedules making objects available during certain parts of a day or week (e.g. x-rated movies).

5.2.1 §4
s/MUST not/MUST NOT/

5.2.1 at the end…
"OK:  The object has been uploaded successfully and has replaced an
         existing object with the same name."
Why should someone ever want to replace an immutable object with an exact copy of the same object? See no reason to have this response.
(Also see general comment on persistent storage of object and status check of objects).

7.2.2
s/The same object might be uploaded for multiple times/The same object might be uploaded multiple times/

A.1.2.  
s/HTTP Support for DECADE Standard Transport Protocol Primitives/HTTP Support for DECADE Standard Data Transport Protocol Primitives/

On 25 maj 2011, at 15.11, Woundy, Richard wrote:

> Folks,
>  
> We would like to prepare the architecture draft, draft-ietf-decade-arch-01, for working group last call in July.
>  
> The chairs are looking for document reviews to be sent to the mailing list by Monday June 13. We already have three volunteers from our session in Prague. Additional draft reviews by the deadline would be timely and greatly appreciated.
>  
> _______________________________________________
> decade mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/decade

---

From: "Mcdysan, David E" <[email-masked]>
Date: Mon, 13 Jun 2011 10:48:48 -0400

Here is my review of the DECADE architecture draft.

I plan to send minor edits, suggested rewording, etc, to the authors and
cc the chairs in a revision marked Word Document.

Dave
-----------------
Overall comments:

The draft is well written, but the structure of the text that covers
Figure 1 is "flat" and may be difficult for first time readers to grasp
the main concepts. A suggestion is to construct a simpler Figure that
captures the main functional blocks that introduces the main features of
the architecture and provides a roadmap and references to the sections
which contain more detail.

There are a number of instances in the document where statements of the
form "Š foo will be covered in a subsequent version of this document Š."
These need to be removed before a last call. Also, a decision needs to be
made if any of this future work is actually needed for last call. (I think
not, but this should be discussed on the list). Also, documents covering
these areas in further detail may be a basis for WG rechartering.

Suggest defining what is meant by "data transport" (e.g., access to stored
data) since the term "transport" has another meaning in the IETF and make
this consistent with the requirements draft.

Specific Comments:

1. Introdcution, 1st para:
Here, and in some other places where the scope is described as P2P
applications, suggest making the applicable applications the same as
stated in the requirements draft. That is, add IPTV and VoD to P2P.

3.2.  Immutable Data Objects

The definition for multipath (different blocks may be fetched from
different content sources in
parallel) should be added to the requirements draft.

3.5.2.  User Delegations, 2nd para

"Instead of granting resources to an application, the server grants a
share of the resources to a user."

Not clear what is meant by the first phrases. Suggest elaboration and
giving a few examples.

Is user synonymous with DECADE client? (If so, this should be changed to
be consistent for all occurrences.)

4.2.2.  Resource Scheduling, 2nd para

"In order to access this data, another Application End-Point may use the
granted access along with its own available resources to store or
retrieve data from a DECADE Server."

I agree with this, but don¹t recall it being clearly stated in the
requirements draft.

4.4.1.  DECADE Data Object Naming Schema, 2nd bullet

* Unique names (with high probability[DM1]

Would really like to see more description of what is the behavior when
non-unique names are generated. Is there a possible solution to ensure
that object names can be unique within a certain scope?For example, could
a disambiguating field be added to the name in the event of a collision?

4.5.  Token-based Authentication and Resource Control, 3rd para

"This is a simple scheme, but has multiple important advantages
over an alternate approach in which a DECADE Client explicitly manipulates
an Access
Control List (ACL) associated with each DECADE data object."

My reading of the requirements draft was that ACLs and some authentication
method are mandatory.

IMO, the token approach described in this draft is much more scalable and
useful. Suggest making the ACL style controls in requirements as SHOULD
for the reasons stated here.

5.1.2.  Token-based Authentication and Resource Control, 4th list item

"Priority for bandwidth"

Not clear what this means. Suggest elaboration, give example(s).

5.1.3.  Status Information

The text of "access information per application context on a specific
server:" references section 3.5.

This needs some clarification, since 3.5 states that per user (and not per
application) delegation is supported.

From:  "Woundy, Richard" <[email-masked]>
Date:  Wed, 25 May 2011 09:11:39 -0400
To:  "[email-masked]" <[email-masked]>
Subject:  [decade] Reviews of the Decade Architecture draft

>Folks,
> 
>We would like to prepare the architecture draft,
>draft-ietf-decade-arch-01, for working group last call in July.
> 
>list by Monday June 13. We already have three volunteers from our session
>in Prague. Additional draft reviews by the deadline would be timely
> and greatly appreciated.
>