Re: [T2TRG] Less than 24 hours till implementers' workshop

[Michael Koster <[e-mail]>]

I was working on a proposal last year to add device-to-device support to LWM2M.

The basic enabler is a "peer" management object which is functionally similar to the server management object, but which defines a peer endpoint on the network (and associated ACL objects). One peer object is needed for each other device it is non-exclusively paired with. Each pair may have its own ECDHE handshake or there may be some key dist.

The peer objects may be configured by a server or a peer that has sufficient permission.

Likewise we were working on defining a multicast management object which represents a multicast address "endpoint" on the network, also with associated ACLs.

For the issue of device as server, the idea is to introduce CoAP pub/sub that enables the device to push and pull through the NAT as a client. This integrates with RD at the service end.

JSON and CBOR may coexist, and the JSON equivalent is very useful for interoperable web-facing APIs

Best regards,

Michael

> On Oct 26, 2016, at 6:39 AM, Julien Vermillard <[e-mail]> wrote:
> 
> Some comments after a first read.
> 
> How a LWM2M device can be seen as a server when most of LWM2M adopters use that behind NAT and so the device is not directly able to receive requests.
> The LWM2M device can only receive requests from the LWM2M server when a registration or a registration update created a NAT association which will stay here for 20sec to 180 sec depending on the network configuration. So for me it make much more sense to talk about LWM2M client for the device and LWM2M server for the "server" :D
> 
> I'll use the name device for the CoAP server and LWM2M server for the RD+CoAP client here :)
> 
> Device to device interaction weren't specified because in most of IPV4 NATed networks (cellular networks) the device are not able to directly address another device.
> That explain the focus on centralizing the communication to a "cloud" server.
> 
> On PATCH/FETCH I agree it's something that could be really useful for LWM2M.
> 
> "Beyond what is described in the LWM2M documentation, devices will often talk to each other. Specially in cases when all devices are under the same subnet, this could be pretty common."
> 
> For my today LWM2M applications, we are not any time soon but I would be really interested to know the use cases behind that.
> 
> Also I have an hard time to understand the security model here. Maybe the plan is to use certificate for being able to do thing to thing DTLS?
> 
> for 3.3, I had a hard time to figure how to use HTTP/CoAP proxy when LWM2M makes obverse mandatory. Yes you can use observe for caching the value but that does means the HTTP Client must poll the HTTP/CoAP proxy which is a not a proper solution to me because we want to move a lot of telemetry values from the device to the cloud and it makes the communication pattern quite inefficient.
> 
> For the object model it totally make sense to adopt a more typed representation format like CBOR than the LWM2M specific TLV. and use it also when you use SenML with LWM2M (today only Json SenML is specified in LWM2M).
> Reducing the number of supported format (TXT/JSON/TLV) to only CBOR would keep the same feature set and reduce the implementation complexity.
> 
> Also Object instances are problematic. It's hard to find which object instance you want to address on a device without reading all the object.
> For example you use the object /9 (software management) you have a bunch of installed applications and you want to uninstall the "temperature management" app.
> For finding which object instance you need to address you need to walk though all the /9 instance, find the application called "temperature management" and remove it.
> If you try to do this across a large fleet of device it can be quite painful because on every device the app can have a different object instance id.
> 
> From what I understand from the document you would like to see more T2T and alignment with CoAP from the LWM2M spec (specifically the RD one), but it's quite hard to ignore that LWM2M was built at OMA my telco companies who want to use it for today applications: machine-to-machine device management and thing-to-thing and accessible and static IP on devices are still not a reality in the world we are deploying.
> 
> It would be nice to first work on the requirement and to see if, we want, and how, we can introduce them to LWM2M vision.
> 
> Cool, we have a lot interesting ideas to discuss tomorrow!
> 
> --
> Julien Vermillard
> 
> On Wed, Oct 26, 2016 at 10:08 AM, Carsten Bormann <[e-mail] <mailto:[e-mail]>> wrote:
> In less than 24 hours, the implementer’s workshop will start in Ludwigsburg (Stuttgart area).
> 
> We’ll discuss general directions of leading CoAP/DTLS implementations as well as open issues where it would be good to have a common approach between implementations.  Some standards work might spin off from this, or maybe some best practices documentation.
> 
> Implementations of course address more than the IETF part of the stack.  One interesting angle that got more focus recently is how to help with evolution of the widely recognized LWM2M effort.  There are some organizational aspects to address (which the RG is probably the wrong place for), but there are also technical points.  Jaime Jiménez (who can’t be at the meeting) has a short work in progress document for this that he gave us a glimpse on just now:
> 
> http://jaimejim.github.io/drafts/draft-jimenez-coap-functionality-lwm2m.html <http://jaimejim.github.io/drafts/draft-jimenez-coap-functionality-lwm2m.html>
> 
> More food for thought for those of us that want to further LWM2M; maybe we can even evolve this document in the RG based on our best practices work.
> 
> Grüße, Carsten
> 
> 
> _______________________________________________
> T2TRG mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.irtf.org/mailman/listinfo/t2trg <https://www.irtf.org/mailman/listinfo/t2trg>
> 
> 
> _______________________________________________
> T2TRG mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/t2trg