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

[Julien Vermillard <[e-mail]>]

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]> 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
>
> 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]
> https://www.irtf.org/mailman/listinfo/t2trg
>
>