Need client behavior clarification with bad bootstrap configuration.

[sbernard31]

I try to understand what should be the right behavior of leshan-client in different unexpected bootstrap situation.
(This question comes when I try to resolve : eclipse-leshan/leshan#986)

I have many use case that I'm not sure how I should handle it. But let's begin with only 2 cases, this will maybe clarify the other cases I have in mind.

1 Replace Bootstrap Instance security object into Server Instance.

Considering a client with a bootstrap security information at "/0/0" and a bootstrap server send a write request on "/0/0" with data for a LWM2M server (resource "/0/0/1"=false).

1.1 Should the client accept this ? (I see nothing in the specification which prevent this)
1.2 If this is acceptable, this looks like a way to delete a bootstrap server but the spirit of the spec seems to allow bootstrap deletion only with purge feature (0/?/12 : Bootstrap-Server Account Timeout) because Bootstrap Delete is not allowed to delete a security instance about bootstrap server ?

Only in the Bootstrap Interface, the "Bootstrap-Delete" operation MAY target any Instance or all Instances of any Object including the Security Object (ID:0), supported by the LwM2M Client. The two exceptions are the LwM2M Bootstrap-Server Account, potentially including an associated Instance of an OSCORE Object ID:21, and the single Instance of the mandatory Device Object (ID:3), which are not affected by any Delete operation.

2 Add a new bootstrap security instance

Still considering a client with a bootstrap security information at "/0/0" and a bootstrap server send a write request on "/0/1" with data for a LWM2M bootstrap server (resource "/0/0/1"=true).

Reading the specification I see nothing which prevents to accept the write request.
But the spec says :

The LwM2M Client MUST have at most one LwM2M Bootstrap-Server Account.

and

When a Bootstrap Information is loaded in the LwM2M Client, any detected inconsistency MUST be reported in sending an error response code to the Bootstrap-Finish operation.

If Bootstrapping was unsuccessful, the Bootstrap-Server Account MUST retain the values it had before the unsuccessful Bootstrapping sequence started and further statements below in Step #3 do not apply.

2.1 What happens then ? Client has now 2 bootstrap server account and the spec says that you can not delete LwM2M Bootstrap-Server Account.
2.2 Should client remove automatically the new Bootstrap Server Account ?

---

Bonus question, could you clarify this 🙏 :

In case the Bootstrap-Server Account has to be replaced, the replacement and the purge of the previous Bootstrap-Server Account MUST properly take place before the Client sends the Bootstrap-Finish response message back to the Bootstrap-Server; otherwise a "Not Acceptable" Response MUST be returned, and the previous Bootstrap-Server Account is still the only one active.

I can not understand : "Bootstrap-Server Account MUST properly take place before the Client sends the Bootstrap-Finish response message back to the Bootstrap-Server"

If this is a replacement, I guess a bootstrap write was used and so this obviously already done or I missed something ? 🤔
and if this is a purge (I understand "purge" as /0/?/12 Bootstrap-Server Account Timeout is used), I understand that I need to wait the end of the timeout to send the Bootstrap-Finish response which does not make too much sense to me ? 🤔
I probably don't get this at all 😓

[dnav]

Note: these are my personnal views until the issue is discussed in the OMA DMSE working group.

1.1 I'd say yes.

1.2 The spirit of the spec is more "Do not risk bricking the Client." Doing a Bootstrap-Delete /0, Bootstrap-Delete /1, then a Bootstrap-Finish is valid but the Client would end up with no Server account at all.
If the BS Server wants to replace the BS Server account, it can overwrite it.

2.1 Checking that there is a unique BS Server Account should be done during the Consistency Check. So the Boostrap-Write would be succesful but an error code would be returned to the Bootstrap-Finish command.

2.2 Most of the time, the Bootstrap-Server can not fix the problem. The Client should ignore all the changes made during the failed Bootstrap. But this is not clearly stated in the spec.

Bonus question This whole purge feature is not clear for me either...

[sbernard31]

2.2)

Most of the time, the Bootstrap-Server can not fix the problem.

I agree, it's hard to me to imagine to implement this part of the spec 👇 :

On receipt of the error response code to the Bootstrap-Finish operation, 
the Bootstrap-Server MAY take corrective actions before issuing a new Bootstrap-Finish operation.

The Client should ignore all the changes made during the failed Bootstrap. But this is not clearly stated in the spec.

The spec says :

If Bootstrapping was unsuccessful, the Bootstrap-Server Account MUST retain the values it had 
before the unsuccessful Bootstrapping sequence started and further statements below in Step #3 do not apply.

But this is not crystal clear to me.

You mean a whole rollback of all changes done during the bootstrap session. This could be not so easy to implement. Is it something you already implemented successfully ?

Theoretically, you just need to back-up the bootstrap server info as if there is other issue, you are still able re-bootstrap until you get a valid config 🤔. To prevent even more risk you should keep the previous working bootstrap information until you successfully connect with the new one.

But keeping only bootstrap information is not so easy to do as bootstrap connection information are mixed with DM servers ones in Security and OSCORE object.

I guess that separating bootstrap data from dm data (#152 (comment)) or reserving instance 0 of Security and OSCORE object could have did the trick (#522)

(For device without bootstrap server information, this is less an issue because I guess you can change server credential manually, IF NOT your device will be a brick one day or another 😅)

[mkgillmore]

Group agrees that this issue is resolved and can be closed 10/31/2023

[sbernard31]

@mkgillmore can you elaborate ?

Resolved by what ? and in which version of the specification ?