Re: [decade] reorganized -req

[Peng Zhang <[e-mail]>]

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

> Hi Peng,
> 
> Thanks a lot for the feedback! Please see below.
> 
> On Tuesday, July 10, 2012, Zhang Peng wrote:
> 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?
> 
> 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.
> 
>         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.
Yes, I think "resource provider" is a more precise definition.
>  
> 
>         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 use "client" instead?
> 
> 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. 
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:
> 
>                 - 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"
> 
> 
> 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.

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