Re: [PATCH BlueZ 0/2] mesh: Implement org.bluez.mesh.Node1 properties

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

On Tue, 2019-08-27 at 20:23 +0200, michal.lowas-rzechonek@silvair.com wrote:
> Hi,
> 
> On 08/27, Stotland, Inga wrote:
> > > adds two additional properties: list of unicast addresses
> > > claimed by the node and the current sequence number value.
> > Could you please explain the justification for adding these two new
> > properties?
> 
> Sure thing.
> 
> The address part is useful when application would like to talk to its
> own node's Config or Health Server. At the moment the address is known
> when calling Import or CreateNetwork (even though the application would
> then need to store it somewhere, so we end up with two sources of
> truth), but after Join() the application won't know the address assigned
> to it.

I think I am OK with this...   It is hard to make the argument that this would be an information leak when the
information has been revealed before. And certain nodes (if they are authorized) need to be able to talk to
their own config servers.

> 
> As for sequence number part, reading is mostly for debugging and
> verification. A few our users had trouble identifying a problem in their
> setup when their node was listed in other nodes' RPL.

I am kind of sympathetic to this for debugging purposes, but I would point out that during the debugging
process, many tools are available, including adding debug logging to the daemon as needed. So adding this info
to the dmsg log for example, would be acceptable...  Especially so that it could be easily turned off at non-
debug times.

However, I don't see a reason for any *deployed* application needing this information.

> In the end I would like to make it writable (increment-only) to enable
> address reuse, but as this stage I'm still looking for a way to
> implement this without causing a race condition, so I left it readonly
> for now.

This is where I start to see actual danger, and difficulty when considering the NVM system is "pre-reserving"
sequence numbers to prevent NVM thrashing during heavy use. In the spirit of keeping an API as small as
possible, giving applications the ability to adjust the SeqNum (even in the legal direction) should have a rock
solid justification.

> regards