Received-SPF: pass (google.com: best guess record for domain of linux-bluetooth-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Mon, 1 Jul 2019 11:20:52 +0200
From:   "michal.lowas-rzechonek@silvair.com" 
        <michal.lowas-rzechonek@silvair.com>
To:     "Gix, Brian" <brian.gix@intel.com>
Cc:     "jakub.witowski@silvair.com" <jakub.witowski@silvair.com>,
        "linux-bluetooth@vger.kernel.org" <linux-bluetooth@vger.kernel.org>,
        "Stotland, Inga" <inga.stotland@intel.com>
Subject: Re: Was: mesh: Added ImportLocalNode call with its API --> Multiple
 Methods?
Message-ID: <20190701092052.24dxntjvvdcylp6r@mlowasrzechonek2133>
Mail-Followup-To: "Gix, Brian" <brian.gix@intel.com>,
        "jakub.witowski@silvair.com" <jakub.witowski@silvair.com>,
        "linux-bluetooth@vger.kernel.org" <linux-bluetooth@vger.kernel.org>,
        "Stotland, Inga" <inga.stotland@intel.com>
References: <20190625143855.29889-1-jakub.witowski@silvair.com>
 <1561568468.22940.16.camel@intel.com>
 <14abe0f2129a2334d32aa14f2167380a5208880b.camel@intel.com>
 <CAMCw4t3pXTbtt05RD694jzF_MNT_J9dcFMtA7iuD4ujZT9FDbg@mail.gmail.com>
 <1561660267.7802.29.camel@intel.com>
 <20190627195127.payxcdeexiamsi24@kynes>
 <1561732182.7802.47.camel@intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <1561732182.7802.47.camel@intel.com>
User-Agent: NeoMutt/20180716
Sender: linux-bluetooth-owner@vger.kernel.org
Precedence: bulk

Hi,

On 06/28, Gix, Brian wrote:
> > The application can do all the configuration using loopback Config
> > Server messages, so I don't think we need a Migrate() call at all. The
> > application already receives current node configuration when
> > Attach()ing, so it can determine if something needs to be reconfigured.
>
> I don't see this actually working very well.  Firstly, these
> "Loop-back" Config Server messages do not all actually work unless the
> node is a Provisioner, which will *not* be required of most nodes.

I don't think this is true. Application can send messages from the
application to its node using straightforward Send() call with key index
0x7fff, and they are processed correctly. While this might be considered
a "hack", you've seen that I am currently working on DevKeySend() API.

As far as I can tell, a node always has its own Device Key in the
keyring, so loopback messaging via DevKeySend() is going to work even on
non-provisioner nodes.

> And However, even if the App went through all of the restoration of
> all the settings under the control of the Provisioner via this Config
> Server loop-back method, there is still the critical issue of Sequence
> numbers.

Indeed. I would propose simply adding starting sequence number to the
dictionary passed to ImportLocalNode() call. It can be made optional,
i.e. when the application doesn't provide it, the imported node starts
counting from 0.

> If we want a single method (avoid API bloat) I don't think we have any
> choice but to use a well developed structure (like JSON or XML) that
> faithfully sets up the node in the state it was in prior to Migration.
>
> We can perhaps "Overload" this functionality by allowing a minimal
> JSON with only Prov Data parts, if we are looking for a Provisioning
> shortcut, and always requiring the ObjectManager calls fetch the
> Composition (if the JSON was minimal) and to Sanity check the
> Composition (if the JSON contains a fully developed/configured
> Migrated node).

Ok, that sounds better. We could start by implementing the "Provisoining
shortcut" variant, and add full-blown migration when it's needed.

Would that be OK from your POV?

regards
-- 
Michał Lowas-Rzechonek <michal.lowas-rzechonek@silvair.com>
Silvair http://silvair.com
Jasnogórska 44, 31-358 Krakow, POLAND