Many class of IoT devices, especially in automotive world, act as proxy/gateway to smaller modules - these smaller modules/units have firmware that can be independently updated.
Continuing on the auto example, a car will have many control modules and only specific ones will have connectivity to the external world - usually the telematics module. However there are separate firmware that get released for each module and the telematics module acts as the gateway to receive the firmware and delegate it to respective module for actual update.
In this scenario, the telematics module ( being considered as a "IoT Device" ) will be envisioned to have a lwm2m stack built into it to support lwm2m based remote management. In order to support firmware update of the the various modules that the telematics unit represents, from a LwM2M server plane, there is need to represent each module as an "instance" of the Firmware Update Object (/5).
That way, the lwm2m device is able to distinguish a specific firmware for a given module and have it updated independently.
We have this implemented using our own extended notion of a Firmware Update object, modelling the notion of "modules" as instances - primarily due to the fact that the spec restricts the object /5 to be of only SINGLE instance.
I am sure this is not an isolated use-case where a single lwm2m device needs to act as proxy to other smaller devices (which may not have connectivity), and in these situations its imperative that that single device has ability to represent the smaller device via "instances" - for example for firmware update and other lwm2m functions.
With this background, would like to request the Board to consider making the firmware update object as supporting "multiple" instance types.
Did you took a look at object /9?
Firmware Update has been updated for clarification (May TS 1.0 release) ; but multi-instance proposal has been rejected with the objection (which has still to be better expressed in the spec) that this firmaware update is for the LWM2M Client only. Otherwise the Sw Update Object ( object 9) has to be used .
There is also the issue that you can easily include many different firmware imagines in a single package since you most likely know as a developer how to distribute the software/firmware update on your embedded device anyway.
Furthermore, you will have problems with using the firmware update mechanism as currently specified since it does not use CoAP over TCP / TLS nor block-wise transfer. For this reason you will run into the CoAP message size limitation of 64KB (if you don't run into the problem of IP layer fragmentation earlier).
Issue closed per Thierry and Hannes comments above