Bootstrap server security instance should have always been at "/0/0" ?

[sbernard31]

I don't know why ... but I was thinking that "/0/0" (instance 0 of Security object) was reserved to Bootstrap server.
There are some hints in OMA github which go in that way but I found nothing in the specification :

• Is it mandatory to have bootstrap server information in 0/0 always? #245 (comment)
• Bootstrap Server Account cannot be properly handled during the bootstrap procedure #152 (comment)

This simple idea had many benefits :

• a Bootstrap server always know that if it want to modify bootstrap credential it must target /0/0
• a Client can more easily validate that it has at most 1 bootstrap server.

At first sight, it's really hard to me to understand why the OMA (remove or not introduce) this idea.

A classic simple/minimal use case for a bootstrap server is to :

• set 1 LWM2M server.
• eventually change bootstrap credentials.

As this constraint was removed (or not added 😕), a Bootstrap server can not apply a simple and safe bootstrap without doing a bootstrap discover...

Why ?
because it doesn't know which security instance contains the bootstrap server information (it could be any instance Id)
A solution could be to delete /0 and /1 before but it doesn't work because Bootstrap Delete says :

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.

(source core§Bootstrap-Delete-Operation)

Leshan user recently face interoperability issue because of this : eclipse-leshan/leshan#986 (comment)
Without surprise because adding discover and create a bootstrap config depending of discover result bring with more complexity at client and bootstrap server side ...

Maybe I'm wrong but from an exterior point of view this looks like as community feedback was not so encouraged.
See #152 (comment) :

• @kFYatek perfectly explain the issue (In a general way, I found its feedback are really good)
• @FredRodermund and @kFYatek sounds OK with a solution.
  And finally this discussion was close without any feedback, explanation about the OMA choice or even asking to community if the solution chosen by OMA sounds good.

This is too bad because this is frustrating for community 😞 and I guess OMA could benefits a lot to leverage community expertise.

[dnav]

@kFYatek comment summarizes the issues with such a choice. IMHO, the main one is:

However, then the philosophy of Multiple Instance Objects would be broken, as /0/0 would be something fundamentally different (requiring different interpretation) than any other /0/*(...)

In the LwM2M relased Technical Specifications, the instance 0 of the Security Object was never reserved to the Bootstrap Server Account. Hence the need for the mandatory boolean resource 1: "Bootstrap-Server".

As @ThGarnier wrote, the Bootstrap-Discover command allows a BS Server to determine which instance of the Security Object is associated to which LwM2M Server or Bootstrap Server account.

But I agree that if the BS Server could delete everything in the Security Object then initial Bootstraps would be simpler to perform. This is a proposal I made but could not convince others on the benefits.

However I encourage you to consider the LwM2M 1.2 Bootstrap-Pack feature.

Regarding your last remark, community feedback is encouraged, this repo being one of the channel, Testfests are another one. See https://omaspecworks.org/events/testfests-registration/. Note that there is one at this moment.

But the OMA is still a membership-based organization. Chances are that when this particular matter was discussed in the working group, the members saw more issues than benefits with the solution proposed by @kFYatek and @FredRodermund (whose companies are members).

[sbernard31]

However, then the philosophy of Multiple Instance Objects would be broken, as /0/0 would be something fundamentally different (requiring different interpretation) than any other /0/*(...)

The specification already did this kind of exception (e.g. you can not delete /3/0 or bootstrap server account)
In a general way, I agree with trying to respecting philosophy but when this means create over complicated solution instead I'm a bit perplex.

But I agree that if the BS Server could delete everything in the Security Object then initial Bootstraps would be simpler to perform. This is a proposal I made but could not convince others on the benefits.

Really too bad. This would have mitigate the issue a lot.
To me the question is more what is the benefits to forbid to delete the Bootstrap server Security instance. 🤔

Chances are that when this particular matter was discussed in the working group, the members saw more issues than benefits with the solution proposed by @kFYatek and @FredRodermund (whose companies are members).

It's really hard to me to understand this choice but I guess that if the reason was given in the corresponding issue this could help a little bit.

[dnav]

Really too bad. This would have mitigate the issue a lot.
To me the question is more what is the benefits to forbid to delete the Bootstrap server Security instance. 🤔

Actually I remembered the reasoning while answering your other questions:

It is forbidden to prevent bricking the device. 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.

[sbernard31]

But the OMA is still a membership-based organization.

I'm not sure to understand but I guess this means that member have more right than none-member.
Discussing the issue in an open written channel sounds not incompatible to me with this idea.
See :

• community open a issue.
• member discuss with community to find the better solution.
• if there is no consensus at the end member decide.

This is pretty much the same thing than an open source project. contributor vs committer/membership.

At the end this changes not so much but there is :

• written public history of decision making.
• community is more involved (with probably more chance to do better choice)

[sbernard31]

It is forbidden to prevent bricking the device. 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.

That was my guess, but :
a) this doesn't prevent really the issue as bad bootstrap config can be written anyway
b) there is another kind of idea to prevent that in the spec :

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.

[sbernard31]

(by the way thx a lot @dnav to take time to answer me 🙏 !)

[dnav]

But the OMA is still a membership-based organization.

I'm not sure to understand but I guess this means that member have more right than none-member.

Well, member have more rights because non-members have no rights.

Discussing the issue in an open written channel sounds not incompatible to me with this idea.

Sure. But then there is question of time and manpower. Meeting minutes exist but they are not public.

• community open a issue.
• member discuss with community to find the better solution.
• if there is no consensus at the end member decide.

Well, it is more:

• community open a issue.
• issue is raised in the WG
• WG decide if the issue needs to be adressed or not
• hopefully community is notified
• if a member of the group consider that this issue needs a fix, they can contribute a change in the next release
• the group needs to reach a consensus on the change

So to go with your analogy, the members are the contributors and the working group is the committer.

Note that members open a lot of issues too. Just not in this repo.

[sbernard31]

At Leshan we will strongly encourage to use the convention : Instance ID 0 should be reserved for LWM2M bootstrap server for Object Security(0) and OSCORE(21).

[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 ?