Leshan Bootstrap new Sequence mode

[JaroslawLegierski]

Question

Some of devices DO NOT handle the DISCOVER operation during the Bootstrap Sequence. Unfortunately, we do not know in advance if a device will support it or not.

Currently in Leshan, you can choose between 2 modes:

• Mode A) Leshan does NOT perform any DISCOVER and uses the instance number 0 as the one used for Bootstrap Server.

• Mode B) Leshan does a DISCOVER in order to get the information on what is the instance number used by the device to hold Bootstrap Server informations. This is the Opt area named autoIdForSecurityObject == true below

Our problem is that it is difficult to know in advance if a specific device will supports the Bootstrap Discover correctly or not. Which is quite impossible to know in advance if we should use Mode A) or Mode B).

We would like to implement a new mode, which can be summarized in this way:

• Mode C) Leshan do start with Mode B), but if the DISCOVER fails, then it continue as a failover to Mode A) instead of failing the Bootstrap Sequence.

[sbernard31]

Yep, I get the issue.

The current idea in Leshan :
There is 2 ways to provide "requests to apply during a bootstrap session" :

• a pretty simple way but feature limited via BootstrapConfigStore interface.
• a full feature one via BootstrapTaskProvider interface.

And also, if you just want to do minor changes you can just extend default Leshan implementation of those classes.

A solution at short term :
You can create your own BootstrapConfigStoreTaskProvider and change the default behavior.
FMPOV, this is OK to do that. I mean I don't see that as a workaround but a normal usage of API.
Leshan does not plan to support all cases but try to have an open enough API to change behavior.

The remaining question:
Do we want to add this mode C) to BootstrapConfigStore API ?
I'm must confess that I don't know...
This is always a trade-off between "providing more feature" and "limit the scope to try to keep the library maintainable".
In this particular case, this is not too much of code, so maybe we can add it ...

Another solution is to change BootstrapConfigStoreTaskProvider to make easier to customize the way discover response is handled ?

[JaroslawLegierski]

I prepared this PoC . (apologies for the frontend part - not too familiar with vue 😉 ) What do you think - can we implement something similar in Leshan ?

[sbernard31]

Yep this is what I understood when I read your very well described issue.

But I'm still not sure this should be in Leshan library like I explained just above ☝️
So I would like to clarify this before.

On your side Is it a behavior :

• you need in production / real life ?
• or something you think it would be good to add to Leshan to make it better ?
• or both ?

I know it seems I always try to limit new additions in Leshan but my goal is to limit the scope as much as possible at the LWM2M specification itself. Adding too many features makes maintenance or future refactoring harder. Here this sounds small changes but last time I rewrite the UI completely, all the small feature makes the migration very long. (I even decide to remove some of them)

Anyway, I'm counting on you to help me to keep the scope of Leshan small enough to be maintainable 🙏

About this new mode I have some concerns:

• if you don't know how to bootstrap your device in production, the mode "NONE" auto mode could lead to serious problem : see Bootstrap server security instance should have always been at "/0/0" ? OpenMobileAlliance/OMA_LwM2M_for_Developers#522 and Need client behavior clarification with bad bootstrap configuration. OpenMobileAlliance/OMA_LwM2M_for_Developers#523. So a mode which fallback on it sounds not so good.
• I'm not sure we want to multiply the number of mode as I said BootstrapConfigStore is the very simple API. The full feature one is BootstrapTaskProvider

[sbernard31]

(not too familiar with vue)

Me too 😅