Re: [PATCH BlueZ v5 1/1] mesh: Add APIs for Provisioner and Config Client

["Gix, Brian" <brian.gix@intel.com>]

Hi Michal,

On Thu, 2019-04-18 at 11:27 +0200, Michal Lowas-Rzechonek wrote:
> Hi Brian,
> 
> On 04/17, Gix, Brian wrote:
> > The messages where keys are explicitly sent over-the-air are the only
> > messages we anticipate providing specific D-Bus methods for to
> > minimize D-Bus API bloat.
> > (...)
> > The external Config Client App is responsible for:
> > * deciding *when* to send App and Net key adds and updates
> > * sending all pub/sub/binding/feature settings
> > 
> > so in this case, the controlling Config Client App will be composing
> > all Config Client messages (except for OTA key messages)
> 
> So if I understand correctly, to add a new application key one would
> need to either:
>  - call CreateAppKey to have the daemon generate a new application key
>    internally.
>  - manually create access layer payload for Config Client App Key Add
>    message, then send it to the local node via loopack


Actually no. The Config Client loopback to the local node is intended to just add keys to the local node Config
Server.  Since it seems reasonable to add externally generated App and Net keys to the local nades key ring, I
will also add imports for those two key types.

> 
> After one of these operations, the key can be sent to remote nodes using
> AddAppKey API.
> 
> This seems a bit assymetric: the application that would like to act as a
> Config Client would need to use a mixture of manually constructed
> access payloads (e.g. to configure binds and subscriptions) and a
> higher-level APIs used to add keys.
> 
> I think it would be cleaner to have the application use just the API,
> and relieve it of requirement to implement Config Client messages,
> especially given the fact the daemon implements Config Server internally.
> 
> This would indeed make the API surface larger, which certainly is a
> drawback, but I think it would make it easier to implement actual
> applications, because foundation (and *only* foundation) models (both
> servers and clients) would be provided by the daemon.
> 
> 
> Another point would be adding explicit ImportNetKey and ImportAppKey
> operations, so that an application using external provisioning database
> would be able to inject keys into the daemon's database without sending
> raw Config Client messages. This is similar to Import*Node operations we
> discussed before.
> 

Yes, This ^^^^

regards,
Brian