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:   Tue, 27 Aug 2019 22:02:36 +0200
From:   "michal.lowas-rzechonek@silvair.com" 
        <michal.lowas-rzechonek@silvair.com>
To:     "Gix, Brian" <brian.gix@intel.com>
Cc:     "Stotland, Inga" <inga.stotland@intel.com>,
        "linux-bluetooth@vger.kernel.org" <linux-bluetooth@vger.kernel.org>
Subject: Re: [PATCH BlueZ 0/2] mesh: Implement org.bluez.mesh.Node1 properties
Message-ID: <20190827200236.kyhdu5jjgq7roevw@kynes>
Mail-Followup-To: "Gix, Brian" <brian.gix@intel.com>,
        "Stotland, Inga" <inga.stotland@intel.com>,
        "linux-bluetooth@vger.kernel.org" <linux-bluetooth@vger.kernel.org>
References: <20190827090844.21394-1-michal.lowas-rzechonek@silvair.com>
 <4f4cc80d57738604b3b38049a1aecb6b75e57be2.camel@intel.com>
 <20190827182356.2pbseooolxfazg3g@kynes>
 <a1642e6a33df45cbc41c1bcd42878dabbc7576b3.camel@intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <a1642e6a33df45cbc41c1bcd42878dabbc7576b3.camel@intel.com>
User-Agent: NeoMutt/20180716
Sender: linux-bluetooth-owner@vger.kernel.org
Precedence: bulk

Brian, Inga,

On 08/27, Gix, Brian wrote:
> > The address part is useful when application would like to talk to its
> > own node's Config or Health Server.
> > (...)
> 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.

Ack.

> > As for sequence number part (...) 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.

Ok, fair enough. I'm gonna drop this property in v2.

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