On Wed, Mar 25, 2009 at 12:50 PM, Narayanan, Vidya <[email protected]> wrote: > <snip> > >> I'd like to see a clear separation >> in functionality between the enrollment server and any involvement in >> actual operations of the overlay, including the types of services that >> are offered on the overlay. I think this functional separation is >> essential to ensure that we provide flexible deployment options. >> > >> >> There is a clear separation. The only thing linking the two is the >> need to have the key used to sign the configuration document. >> > > That doesn't sound like clear separation to me. Let me put it another way - > I'm looking for no dependencies between the operation of kinds/usages on an > overlay and the overlay management itself (configuration being one aspect of > the latter). These functions may be provided and managed by different > entities and we need to allow for such a model. >
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 actually OK with this, I just think that the result of the process needs to be that there is a configuration document that gets updated reflecting what's going on in the overlay. The short summary, I think, is what we would need would be a draft specifying how a group of peers decide to update the overlay config in a completely ad hoc case where there is no central administrator of any type (not even the home owner running a control panel on their PC). Here's why I think this is important. Split the kinds into two types based on whether they're IANA registered or not. If they are IANA registered, then the data-model and access-control attributes are predefined. The only ones that are allowed to vary by overlay are max-count and max-size. Personally, I think these are useful to specify, but I don't think it would be that big a deal if they weren't in unmanaged cases. So the only purpose of the configuration file here is so that devices don't need to constantly query IANA for the complete list of all registered kinds, even ones they don't care about. More importantly, let's look at non-IANA kinds. Here the configuration file serves two purposes: - define the access control - establish the kind-id to be used on the overlay. I still disagree that access control can be defined on a per-user basis, since I think there will be lots of problems if two devices arrive expecting different access control policies for the same kind, and I think allowing this opens up a number of other security attacks that don't exist otherwise. But, more importantly, how do you determine kind-ids without a config document that is updated either by an overlay manager or by a distributed algorithm? If two devices from the same manufacturer are on the same overlay, they need to be using the same kind-id if there is any intent to share data. So, I'm OK without a central overlay manager, but I think the only alternative is to write a protocol for distributed generation of the config file. Bruce > <snip> > >> > >> > Pardon my ignorance - what's a CE overlay? >> > >> >> Sorry, consumer electronics. So suppose KodMinNik offers both cameras >> and digital picture frames that form an overlay in the home. The >> first generation products all have the same types, and thus the same >> overlay config file signed by KodMinNik. When the second generation >> of products are released, there are a couple new types, and thus a new >> config file signed by KodMinNik. When a 2nd generation product is >> introduced into a home for the first time, the 1st generation devices >> will see the new config file and update their copy. Even though >> KodMinNik has no direct contact with the individual overlay, any >> device that requires the new types will have a signed config document >> that all the old devices would recognize, so the overlay is managed >> and reliability is ensured by KodMinNik without an active presence. >> > > Interesting that you explain overlay as an element provided and managed by > entities that offer devices and see the overlay as operating just among those > devices. I look at it entirely differently. Consider the case of a Kodak > camera, a Sony TV, my Verizon phone, my PC at home that is on the Comcast > network all forming an overlay. This is an overlay of all my personal > devices. This is also a perfect candidate for not needing an enrollment > server at all - a shared secret based admission control works fine. However, > when a new photo display application pops up, for instance, I'd like my > camera and TV to support it such that I can display the photos from my camera > on my TV. Once I get the necessary upgrades to support the new kinds, from > say, the provider of this photo display app, Foo, there is no reason why my > PC or phone or any other part of the overlay functions on my camera or TV > even should trust a certificate signed by Foo. The only entities that need > to trust it are the new usage instances on the camera and TV. > > Imagine the overlay to be analogous to the Internet. All usages on the > overlay are like services on the Internet. You may need access control to > get on the overlay (just like you need to log into Comcast or Yahoo to get on > the Internet) - but, that provider has nothing to do with the services that > run on it. Ultimately, you trust Amazon's certificate when you are using > Amazon's services; not Comcast's. > > The point in all this is clearly not to debate particular deployment models > or what will eventually succeed - but, it is that we must be making different > deployment models feasible. > > Best, > Vidya > _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
