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 protected] [mailto:[email protected]] >On Behalf Of Narayanan, Vidya >Sent: Friday, April 17, 2009 1:46 AM >To: Cullen Jennings >Cc: [email protected] >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 protected]] >> Sent: Friday, April 10, 2009 1:34 PM >> To: Narayanan, Vidya >> Cc: [email protected] >> 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 protected] >> > https://www.ietf.org/mailman/listinfo/p2psip > >_______________________________________________ >P2PSIP mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
