Subject: [decade] reorganized -req

From: "Y. Richard Yang" <[email-masked]>
Date: Sun, 08 Jul 2012 00:46:22 +0800

Dear all,

We did a substantial reorganization of the -req documents. It is 
attached to this email. Any early feedback will be greatly appreciated.

Thanks!

Richard

---

From: Zhang Peng <[email-masked]>
Date: Mon, 9 Jul 2012 13:46:27 -0400

Hi Richard and All,

	Here are some comments on the recently revised version of -req document.

	First, I noticed that the protocol flow including DRP and SDT is included in -req. I wonder if this is a good choice, since it is more like a design rather than a requirement. Could someone explain the rationale? 

	For the naming requirements, I suggest that the "the naming scheme should support that consumer can validate the name-object binding, i.e., can check that the object content is what the name claims to be". The rationale is that consumer now obtains the object from DECADE server, and in turn is uploaded by some content provider that is not trustworthy.
	 
	I suggest that the terminology 2.5 "Provider" should better be "content provider". Otherwise, it may be confused with "DECADE storage provider" of 2.3. Also, 2.9 is referring to "content provider", not "provider". Correspondingly, "consumer" should be "content consumer". But we should also comment that we would use shorter term "provider" and "consumer" if there is no ambiguity.

	Section 7.2 is not so clear to me. The rationale has not stated the reason for this very well. 
	
	In section 8.1, the term "user" is not defined by us. Should we use "client" instead?

	In Section 9, should we also include "overload condition" which appear in section 4.1.3.1 of current version?
	
	Some minor revisions: 
	
		- Section 2.3: "that" should be removed;
		- Section 6.1:  Should be "After a DECADE-compatible client owns an account on a DECADE-compatible server, it should be able to read data from and write data to the server once authorized by the server.", and it should be following section 6.2.
		- Section 6.2: I think it is better to be "Access to an account on a server MUST be granted to a provider based on cryptographic security"
		- Section 6.3 "resoutces" -> "resources"
		- Section 6.9 "disovery" -> "discovery"
		- Section 7.5 "enerate" -> "generate"
		- Section 8.4 "stoarge" -> "storage"

	I would like to help revise if you don't have time.

B,

Peng.

On Jul 7, 2012, at 12:46 PM, Y. Richard Yang wrote:

> Dear all,
> 
> We did a substantial reorganization of the -req documents. It is attached to this email. Any early feedback will be greatly appreciated.
> 
> Thanks!
> 
> Richard
> <draft-ietf-decade-reqs-all_v06.txt><draft-ietf-decade-reqs-all_v06.xml>

---

From: "Y. Richard Yang" <[email-masked]>
Date: Tue, 10 Jul 2012 11:34:20 +0800

Hi Peng,

Thanks a lot for the feedback! Please see below.

On Tuesday, July 10, 2012, Zhang Peng wrote:

>         First, I noticed that the protocol flow including DRP and SDT is
> included in -req. I wonder if this is a good choice, since it is more like
> a design rather than a requirement. Could someone explain the rationale?
>
> I feel that they represent a group of functions (and hence represent two
functional components). They help to organize the conceptual model. The
requirements do not use SDT and DRP. What do you think?

        For the naming requirements, I suggest that the "the naming scheme
> should support that consumer can validate the name-object binding, i.e.,
> can check that the object content is what the name claims to be". The
> rationale is that consumer now obtains the object from DECADE server, and
> in turn is uploaded by some content provider that is not trustworthy.
>
> Sounds good.

>         I suggest that the terminology 2.5 "Provider" should better be
> "content provider". Otherwise, it may be confused with "DECADE storage
> provider" of 2.3. Also, 2.9 is referring to "content provider", not
> "provider". Correspondingly, "consumer" should be "content consumer". But
> we should also comment that we would use shorter term "provider" and
> "consumer" if there is no ambiguity.
>
> I thought about this. It is not content provider but rather resource
provider, because A could allow B to upload to A's account, where A owns
the account resource. I am fine to go with Resource Provider though.

        Section 7.2 is not so clear to me. The rationale has not stated the
> reason for this very well.

I will take a look and get back soon.

>         In section 8.1, the term "user" is not defined by us. Should we

Sounds good.

>
>         In Section 9, should we also include "overload condition" which
> appear in section 4.1.3.1 of current version?

I feel that overload is a type of insufficient resources. One possibility
is to distinguish between system overload and insufficient inividual
provider resources. What do you think? But this can be tricky in that the
system can be oversubscribed. So the error message may need to indicate
such.

>                 - Section 6.1:  Should be "After a DECADE-compatible
> client owns an account on a DECADE-compatible server, it should be able to
> read data from and write data to the server once authorized by the
> server.", and it should be following section 6.2.
>                 - Section 6.2: I think it is better to be "Access to an
> account on a server MUST be granted to a provider based on cryptographic
> security"
> It will be great if you can take a pass. Thanks a bunch!

Richard

---

From: Peng Zhang <[email-masked]>
Date: Tue, 10 Jul 2012 00:13:38 -0400

On Jul 9, 2012, at 11:34 PM, Y. Richard Yang wrote:

> I feel that they represent a group of functions (and hence represent two functional components). They help to organize the conceptual model. The requirements do not use SDT and DRP. What do you think?
I still don't quite see the necessity of putting the design model here. It is a little detailed to be here.
> I thought about this. It is not content provider but rather resource provider, because A could allow B to upload to A's account, where A owns the account resource. I am fine to go with Resource Provider though.
Yes, I think "resource provider" is a more precise definition.
> I feel that overload is a type of insufficient resources. One possibility is to distinguish between system overload and insufficient inividual provider resources. What do you think? But this can be tricky in that the system can be oversubscribed. So the error message may need to indicate such. 
Maybe we should distinguish between them. For the insufficient resource, it is due to not enough resources are allocated. By returning this error message, the server may cause the consumer to ask for more resource from the provider. While if it is due to system overload, the error message may cause a redirection to other servers. 

> It will be great if you can take a pass. Thanks a bunch!
You mean that I revise directly on .xml file? Thanks.

Best, 

Peng.

---

From: "Y. Richard Yang" <[email-masked]>
Date: Tue, 10 Jul 2012 12:57:24 +0800

Hi Peng,

> is a little detailed to be here.

Then how about change the wording to say two functional components? I can
change it after you take a pass. Please revise .xml if you can.

Thanks!

Richard

> Maybe we should distinguish between them. For the insufficient resource,
> it is due to not enough resources are allocated. By returning this error
> message, the server may cause the consumer to ask for more resource from
> the provider. While if it is due to system overload, the error message may
> cause a redirection to other servers.
>
>
>
>>         Some minor revisions:
>>

---

From: Peng Zhang <[email-masked]>
Date: Tue, 10 Jul 2012 14:57:01 -0400

Hi Richard,

	Here is the revised version by me. I address my comments in this version, please take a look.
	The txt file is that without acknowledgement included since i don't have the ack.xml file. Please include it in the xml directly if you revise it again. Thanks.

Best,

Peng.

On Jul 10, 2012, at 12:57 AM, Y. Richard Yang wrote:

> Then how about change the wording to say two functional components? I can change it after you take a pass. Please revise .xml if you can.
> 
> Thanks!
> 
> Richard 
>>