Brian, On 07/18, Gix, Brian wrote: > There are no use case allowed in the specification that allows any > Config Client except an authorized Provisioner to communicate with a > Config Server (even the local Config Server)... Any changes to a > nodes configuration states should be tracked by provisioners in a > master database, and this is not really possible if any node is > allowed to change it's own CFG Server states. OTOH, there is nothing in the spec that forbids it. For example, it's perfectly legal to create a vendor model that extends Config Server and adds a few additional opcodes that affect Config Server states. Another example is multiple Configuration Clients - the spec only says that synchronizing Provisioners is implementation specific, and it's not Provisioners who talk to Config Servers - it's a Configuration Client, a different role. And sychronizing Configuration Clients is not even mentioned. Also, for Device Keys, the spec says they are "known by nodes". Splitting the node into a "daemon" and an "application" is a bluez-specific architectural decision that has nothing to do with the standard. While I appreciate there are reasons to implement the stack in this manner, I am very much against adding arbitrary restrictions on the things one can do with such a stack. One of these restrictions is denying access to keys. This is fine, but the application needs to be able to use these keys *as if it knew them*. For example, it should be possible to implement an application-side server model that uses DevKey security. At the moment this is not doable, because there is no API to send a message encrypted with *local* device key. regards -- Michał Lowas-Rzechonek <michal.lowas-rzechonek@xxxxxxxxxxx> Silvair http://silvair.com Jasnogórska 44, 31-358 Krakow, POLAND
