I'm not talking about restricting the cases where an overlay operator also wants to have control on what's allowed on the overlay. However, I'm talking about not restricting that to be the only deployment possibility.
By mingling kinds and usages into the overlay configuration document, we are placing that restriction. If we separated those out, a particular deployment can always collocate it into the same entity and it is not a problem. Vidya > -----Original Message----- > From: Bruce Lowekamp [mailto:[email protected]] > Sent: Thursday, March 26, 2009 7:43 PM > To: Narayanan, Vidya > Cc: [email protected] > Subject: Re: Separation of identity assignment and service provider > roles (RE: [P2PSIP] Configuration Updates in RELOAD) > > 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
