Some resources from Device Object should be made mandatory.

[javypm]

The spec marks the resources like Manufacturer, Hardware version, Firmware version, Software version etc, as *optional.

However from a management server perspective, these attributes are critical to model and provide value add services like software management, firmware management, provisioning, data-analytic etc.

So to make the lwm2m spec more "server" friendly as well, it is requested that the basic attributes that distinguish a device ( to the server management plane ) be made mandatory.

I had brought this up w/ Padmakumar, while he was at the OMA event @ San Diego, and jotting it down here for formal consideration.

• Javed Padinhakara

[DavidAntliff]

I agree that it's important to have a set of identifying resources, but the question is which set of resources are sufficient? It depends on the context and device. So keeping them all as optional allows implementers to choose which resources make up their identifying set.

[javypm]

It may provide flexibility to client implementors, but server implementors are left amputed. The whole IOT device management market will evolve to have server implementation which are not necessarily from same vendor who is providing client implementation. So thinking from a management server aspect, which support heterogenous client implementations, its a big gap if clients do not let know their profile characteristics.

IMO we start with manufacturer, firmware,software,hardware revision fields to be mandatory ( since firmware update is an imp. object being promoted in lwm2m ) and keep adding others as it evolves.

This problem has been similarly solved in device management space in other domains like networking, storage etc.

[DavidAntliff]

Software and Firmware might seem straight forward at first, but it is possible for them to be composite and handled by another object like the (new) Software Management object instead (e.g. software might consist of multiple modules or packages with no top-level version number). The absence of both/either could inform the server to try looking for other standard objects that provide that functionality.

[javypm]

Expecting server to attempt trail&error technique to do a basic classification/profiling of each device that connects to it ( and that can be millions at server plane ) may put additional stress. Much of the value add of server is at a higher plane than basic discovery/classification - doing interesting things like big data analytics , applying common policies to a class of devices , etc - and the server resources be better utilized for that.

Is there too many constraints at the client space to provide these basic identification attributes ?

[Megan-OMA]

@javypm - will you please comment the release date of the TS document you are referring to / version of the spec? This helps Padhu and the Working Group locate the issue much quicker.

[HAli786]

@Megan-OMA The issue raised by @javypm applis to all TS. But to help you here is the most recent version OMA-TS-LightweightM2M-V1_0-20151214-C

Thanks H. Ali

[javypm]

Thanks @HAli786 for pointing to the spec. @Megan-OMA , to be specific, the item under discussion in the section which describes the standard Device object ( http://dev_devtoolkit.openmobilealliance.org/IoT/LWM2M10/doc/TS/index.html#!Documents/lwm2mobjectdevice.htm ).

Hope that helps in getting the right (and overdue :) traction!

[ThGarnier]

During the OMA Interim meeting (Sept 2016) it has been statued that it was not possible to define these set of mandatory resources on which everyone has consensus. Sorry => to be closed

[Megan-OMA]

Issue closed per Thierry's comment above