Subject: Re: [P2PSIP] Access control rule in RELOAD to support generic keyword-like storage

From: Song Haibin <[email-masked]>
Date: Mon, 04 May 2009 11:40:10 +0800

I think access control is useful and I prefer approach b. If this could be
done somewhere, I think some kind of change track could be useful so that
you can know who updated the record for each time.

Thanks!
Haibin

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of Narayanan, Vidya
>Sent: Friday, April 17, 2009 1:46 AM
>To: Cullen Jennings
>Cc: [email-masked]
>Subject: Re: [P2PSIP] Access control rule in RELOAD to support 
>generic keyword-like storage
>
>Cullen,
>I'm okay going with option b you mention below.  I think 
>disambiguating node and user ids might be useful. 

>And, I 
>don't think it is unreasonable to limit future updates to 
>using the same id that was used at the time of creation.
>

Could you give an example for this, esp. for sip usage? I have some vague
use cases in mind, but they are not related to the sip usage.

-Haibin 

>Cheers,
>Vidya 
>
>> -----Original Message-----
>> From: Cullen Jennings [mailto:[email-masked]]
>> Sent: Friday, April 10, 2009 1:34 PM
>> To: Narayanan, Vidya
>> Cc: [email-masked]
>> Subject: Re: [P2PSIP] Access control rule in RELOAD to 
>support generic 
>> keyword-like storage
>> 
>> 
>> Vidya, I like this and think we should add it to the draft but one 
>> question. I worry about it being a  bit vague of it if is a 
>> certificate with same user id or node id that is allowed to do an 
>> update. I think we need to do one of two things
>> 
>> a) define this so the nodeid and userid are stored and a certificate 
>> that matches either the nodeid or userid is allowed ot update
>> 
>> b) define two new rules here, one that requires the node-id to match 
>> and ones that requires the userid to match. So we would have 
>something 
>> like NO-MATCH-CREATE-WITH-RESTRICTED-NODE-UDPATE
>> and
>> NO-MATCH-CREATE-WITH-RESTRICTED-USER-UDPATE
>> 
>> I'd probably prefer approach b to aproach a but don't feel strongly 
>> either way.
>> 
>> Thougths?
>> 
>> Cullen, in my individual contrubotro role
>> 
>> 
>> On Mar 22, 2009, at 8:31 PM, Narayanan, Vidya wrote:
>> 
>> > In addition to the access control rules defined in section 6.3 of 
>> > the draft, I think there is a need for a rule, where any node is 
>> > allowed to write to a Resource ID, but, only the creator 
>is allowed 
>> > to modify or overwrite the entry by default.  This allows for 
>> > generic keyword-like storage on the overlay which will 
>eventually be 
>> > needed to support various types of kinds and usages on the overlay 
>> > effectively.  The notion here is that no authorization is 
>needed on 
>> > the Resource ID, but access control is applied to the data 
>> > operations, once it exists.  Here is suggestive text for supporting
>> > this:
>> >
>> > "6.3.6.  NO-MATCH-CREATE-WITH-RESTRICTED-UDPATE
>> >
>> > This policy allows storage of data with no constraints on 
>choosing a 
>> > Resource ID.  However, by default, only the creator of the 
>entry is 
>> > allowed to modify or overwrite the stored data once created. The 
>> > user name and/or node id present in the certificate of the 
>> > requesting node MUST be used as the creator of the data.  Upon 
>> > receiving a request to store, a node MUST verify if it already has 
>> > an entry present for the particular kind and Resource ID 
>> > corresponding to the same user name or node id that is 
>contained in 
>> > the Store Request.  If so, the received Store Request MUST be 
>> > treated as an update to the existing data and the 
>appropriate checks 
>> > as described in section 6.4 must be applied.  If no corresponding 
>> > match is found, the StoredData contained in the Store Request 
>> > message MUST be stored as a new entry in accordance with section 
>> > 6.4.  This rule is useful for generic keyword-like storage on the 
>> > overlay, which is likely to be useful for several classes of 
>> > applications that may b e defined for use with RELOAD.  The access 
>> > control allows ensuring that the data created by a given 
>node is not 
>> > randomly overwritten by any other node."
>> >
>> > It may be good to include the Resource Name in the StoredData 
>> > structure as well.  This will allow the storing node to 
>more easily 
>> > create an index of the resources it is storing, which can then be 
>> > used for retrieval of data.  However, I think it will work even 
>> > without it - I'm looking for other thoughts on this.
>> >
>> > Thanks,
>> > Vidya
>> > _______________________________________________
>> > P2PSIP mailing list
>> > [email-masked]
>> > https://www.ietf.org/mailman/listinfo/p2psip
>
>_______________________________________________
>P2PSIP mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/p2psip
>