Let's make sure we're talking about the same thing. If someone wants to (I don't, but some do) create a competitor to Skype, and they deploy the appropriate servers, I want them to be able to specify exactly what may be stored on their overlay (in this case the resources that their application uses, with exactly their rules).
Similarly, if someone wants to deploy another OpenDHT, I think they should be able to. (I don't want to do this either, FTR.) Your answer seems to say that a provider should not be able to use this protocol to deploy an overlay that only stores what they want it to do. Is that really what you're saying? Philosophically, I guess we could have a debate whether a provider *should* do this, but I don't believe we should try to forbid it within the protocol. Bruce On Thu, Mar 26, 2009 at 8:10 PM, Narayanan, Vidya <[email protected]> wrote: > >> So let's break this up into two questions: >> >> First, is the entity that forms the overlay the one that decides what >> goes in it? >> >> I would say the answer to this is clearly yes. I hope we can agree on >> that, subject to the second question. >> >> Second question is whether that entity can decide that what they >> really want to do is support an anything-goes overlay? >> > > I'm afraid there is a fundamental difference here between what we are saying. > Unfortunately, my answer to your first (and second) question(s) is no. > > Going back to my Internet analogy, the entity providing identities and > credentials to access the overlay may be entirely different from the one or > more entities that may be providing services on the overlay. Clubbing the > two is analogous to saying that the entity that provides me with an IP > address today gets to tell me what applications or web sites to access on my > laptop. Certainly, that would be undesirable. Even in the mobile market, > things are going the other way. What applications run on the iPhone or the > GPhone are not really determined by the operator any more (of course, outside > the North American market, this has been true for a while now). > > An overlay configuration document handled by the overlay provider must not > have anything to do with kinds or usages on the overlay which may be coming > from various services offered on the overlay from different providers. > Otherwise, we are creating a model which is going to limit deployment options > and I don't think our intent here is to create a walled garden for overlays. > > Best, > Vidya > _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
