<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. <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
