Re: [decade] reorganized -req

["Y. Richard Yang" <[e-mail]>]

Hi Peng,

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

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

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

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