Alternativ Path & Bootstrap about oma_lwm2m_for_developers HOT 10 CLOSED

OMA-TS-LightweightM2M-V1_0-20160407-C, 5.3.1

Still mentions the alternative path, and the bootstrap still doesn't cover that feature!

from oma_lwm2m_for_developers.

For example a device registers with:

</lwm2m>;rt="oma.lwm2m", < /1/1>, < /1/2>, < /2/0>, < /2/1>, < /2/2>, < /3/0>,< /4/0>,< /5>

so the URI accessing the LWM2M device object instance would be </lwm2m/3/0> and </3/0> is not valid on that device or may point to a different (none LWM2M) resouce.

If such a device executes a bootstrap, how should the bootstrap server know, that </lwm2m/3/0> MUST be used and not </3/0>?

from oma_lwm2m_for_developers.

I think we have the same issue with the LWM2M version and maybe the list of Objects supported and Object Instances available on the LWM2M Client.
Such information are probably needed by the bootstrap server too.

Maybe a solution could be to add this parameters to the BOOTSTRAP REQUEST, but this means that the bootstrap server initiated should be changed or dropped.

from oma_lwm2m_for_developers.

Maybe, a server initated bootstrap just triggers the client to do a client initiated bootstrap (with the added required informations).

from oma_lwm2m_for_developers.

If "trigger" means "send a coap request to the client on a specific resource". This resource should not be under the client rootpath (as we don't know it). This will be a bit strange, isn't it ? (but maybe there is no other solution)

from oma_lwm2m_for_developers.

Your right, it's strange :-).

from oma_lwm2m_for_developers.

The last OMA-TS-LightweightM2M-V1_0-20161031-D TS say :
"When using the Bootstrap Interface, the LWM2M Bootstrap-Server MUST use CoAP paths only in the form /{Object ID}/{Object Instance ID}/{Resource ID}. It is the responsibility of the LWM2M Client to map these paths to its alternate path."

It seems to be a tentative to partially fix this issue, but this not fix the LWM2M version and supported object issue.

Am I the only one which consider a bit strange that the LWM2M client was able to translate automagically CoAP URI for bootstrap server but was not able to do that for DM server ?
This means two different way to handle alternate path for implementation.

I still prefer adding parameter on boostrap request (like register request) and adding a trigger for server initiated like boaks proposed

from oma_lwm2m_for_developers.

In the scope of LWM2M 1.0, version is not an issue. Regarding supported Object, either the Bootstrap Server has out-of-band knowledge or it sould stick to Objects 0, 1 and 2.

from oma_lwm2m_for_developers.

In the scope of LWM2M 1.0, version is not an issue. Regarding supported Object, either the Bootstrap Server has out-of-band knowledge or it sould stick to Objects 0, 1 and 2.

it sounds ok for LWM2M 1.0, this means that for LWM2M 1.1 this part will change a lot.

The solution exposed above allow to get a similar behavior for bootstrap server and dm server and could be reused for LWM2M 1.1.

from oma_lwm2m_for_developers.

OMA-TS-LightweightM2M-V1_0-20170208-A, 8.2.2.

When using the Bootstrap Interface, the LwM2M Bootstrap-Server MUST use CoAP paths only in the form /{Object ID}/{Object Instance ID}/{Resource ID}. It is the responsibility of the LwM2M Client to map these paths to its alternate path.

OK, may be not as I would like it but defined.

from oma_lwm2m_for_developers.