On quinta-feira, 4 de agosto de 2016 16:55:45 PDT Dave Thaler wrote: > > The question is whether OEMs that opt into BLE will want to bear the > > complexity of 6lo/IPv6 on their OS. > > Some yes, some no.
For those that do, the answer is clear. > > If they're not, does it still make sense to > > talk about OCF payloads? How about security? > > Not that I know of. Those who don't want 6lo/IPv6 already do Bluetooth SIG > profiles today. There is no need to add the complexity of OCF protocols > when there's already an ecosystem of Bluetooth profiles and devices > supporting them today. And note that when we implemented BLE/GATT support last year, there was no 6lo-over-ble spec yet. Only a draft. So we figured, what if there were an actual profile that could be used for this kind of exchange, point-to-point and only relying on Bluetooth's own LL security? > > And if it does, is OCF interested in standardising that kind of protocol? > > I would say no. BTW, ASA went through this same argument a year ago > and came to the same conclusion. The other two approaches were sufficient > and there is no need to add yet a third alternative. Fair enough. Given that there has actually been no movement to do it in two years, you're probably right. The next question is whether IoTivity wants to keep its BLE support, despite OCF not standardising it. It's possible even in the presence of the EP fields: the device simply doesn't add its BLE address. If it responds with no address at all, OIC 1.1 rules apply and the remote side understands as "the address this response came from". And then, if that side is an RD, it can fill in the details of the endpoint that it knows about. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center
