Some resources from Device Object should be made mandatory. #87

Closed
javypm opened this Issue Jan 21, 2016 · 9 comments

Projects

None yet

5 participants

@javypm
javypm commented Jan 21, 2016

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
javypm commented Jan 21, 2016

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
javypm commented Jan 22, 2016

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 Megan-OMA added the TS label Mar 2, 2016
@Megan-OMA
Contributor

@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
HAli786 commented Mar 3, 2016

@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

@ThGarnier ThGarnier added the P4 label Apr 14, 2016
@javypm
javypm commented Apr 15, 2016

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 ThGarnier added To be Closed and removed P4 labels Sep 19, 2016
@ThGarnier ThGarnier removed the To be Closed label Oct 12, 2016
@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
Contributor

Issue closed per Thierry's comment above

@Megan-OMA Megan-OMA closed this Nov 9, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment