Vidya, Thanks for writing up your thoughts on the usage-agnostic draft. It might have been put together fast, but it's more than enough to get started with.
I shouldn't speak for him, but Henning, in particular among the authors, has some thoughts about the data model along these lines. We made a few changes a couple revisions ago (I think going into draft-ietf-p2psip-reload-00) in the direction of allowing dynamic data models, but like you said in your draft, the picture isn't clear in reload. I think your draft does a good job starting a conversation about the issue. <tangent> First, I want to try to be careful about terminology here. A usage defines certain kinds, and the permissions model is specific to that kind (which can be important if it's used in a second usage). So I think I would say that what you propose is a kind-agnostic permissions model. (And I freely admit that the base draft may not be completely consistent in its usage of these terms, either.) There's an implementation detail that it may be a usage-plugin implementing the security model, but that's somewhat separate from the protocol. </tangent> As I understand your draft, it proposes a data permissions model where the resource-id is calculated with a known fixed formula and where all data stored is required to be signed by the identity (user name) used to calculate the resource-id. Please correct me if that's an incorrect summary. (and will probably have to disregard the remainder of this email) That's a very valid model that solves the problems you've identified, but I'm not sure it's sufficient for all purposes. For example, how could you implement voicemail stored in the overlay for offline users? If Bob leaves a message for Alice, he can maybe store the message keyed under his own username, but still needs to somehow store a pointer to that message in something alice knows to check. I can't figure out how that could be done with your permissions model. The other problem with allowing dynamic kind-id usage is that it offers a very easy way to DoS the overlay, since a single rogue peer can flood the overlay with an unbounded number of resources. Of course, if all resource id's are calculated the same way, then a single peer winds up being responsible for them, so it only DoSes a single peer at a time, but that's still not a good result. Having said that, I think there are very valid use-cases for this type of model. Here's a possibility: - an overlay should have a default data permissions model specified in the overlay configuration. These could be usage-defined-kinds-only, default-open-security (no requirement of identity ownership for storing a resource), or default-identity-security (what your draft describes) - in all three models, a usage can define its own data permissions model that is different than the default I think that allows flexibility to meet the security requirements of different deployments. In an overlay with usage-defined-kinds-only security, there's still the question of how you migrate to requiring a new kind on the overlay. ASP had a sketch of a solution for upgrading protocols that essentially maintained two separate overlays until a sufficient portion of peers had updated at which point the old overlay was discontinued. I think you could do something with having peers periodically check the overlay configuration (or another source) to see if new kind-ids are going to be required and apply appropriate updates to their software. The overlay could run with the two different kind-ids being used until a sufficient amount of time had passed. That's a little complicated, but I think it would work. I don't see a need to define it as part of the base protocol right now, since I don't think all deployments will need it (and it's pretty complicated). Bruce On Sat, Nov 15, 2008 at 2:58 AM, Narayanan, Vidya <[EMAIL PROTECTED]> wrote: > > At the moment, some of the overlay operation semantics in RELOAD are not > usage agnostic and there is also an inherent assumption that all nodes in the > overlay support the same set of usages and kinds. One big problem with this > is that it will then require a flag day to upgrade all nodes when usages > evolve to continue having a functional overlay. This is quite unrealistic in > a distributed system and hence, there is a huge benefit to keeping the > overlay level operations themselves usage agnostic. This also nicely allows > creation of multi and heterogeneous usage overlays - i.e., not all nodes will > then be required to support all usages (or the same usage versions) in the > overlay. > > In order to avoid writing a long email to explain the problem and potential > solutions, I wrote it up in a draft instead. For now, I've posted it at > http://www.geocities.com/hellovidya/draft-vidya-p2psip-usage-agnostic-reload-00.txt. > > It is a very quick and dirty writeup - so, apologies for any oversights and > blatant errors. The main body of the draft is reasonably short - I'd > appreciate people reading and sending their thoughts on the issues and > proposed solutions to those. > > 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
