Empty <Operations> values for Server object resources /1/X/13..1/X/20

[pelya]

The definition of Server object /1 at LWM2M_Server-v1_1_1.xml has empty tags for resources from /1/X/13 to /1/X/20. I suppose they all should have "RW" permissions, but you at least have to specify "R" permission, otherwise the only command the server is allowed to do to these resources is Discover.

Just look what this broken object definition did to Leshan:

[seanmcilroy29]

Comment submitted directly to PR #520 (comment).

• Unfortunately, the object that you would like to change the "LwM2M Server" is maintained by the DMSE working group.
  This registry doesn't accept direct changes on Object that have been created by OMA Working Groups.
  If you think that it is not correct, then please raise the issue here: https://github.com/OpenMobileAlliance/OMA_LwM2M_for_Developers/issues the DMSE will review your comments and provide a response to your suggestion.

[pelya]

Thanks, I've submitted the issue to the DMSE:
OpenMobileAlliance/OMA_LwM2M_for_Developers#500

[sbernard31]

Those was fixed in LWM2M 1.2, I strongly think that this fix should be backported on version_history/1-1_1.xml

@jpradocueva @hannestschofenig what do you think about this ?

[jpradocueva]

Changes to the LwM2M Objects are guided (partially) by the principles of Semantic Versioning.
I say partially because unfortunately, we used only two digits for the version (VX.Y) rather than the suggested three digits (VX.Y.Z).

Each time that an Object changes, the group needs to evaluate the type of changes, see 7.2.1 General Policy

If we follow the current policy, if Object 1 v1.1 changes, it implies that v1.1 is kept as it is and the object now will be superseded by the next version v1.2.
Unless I am misunderstanding the comment, OMA will have to change the way they implement changes on their Objects as currently, it is not possible to re-write Object 1, v1.1 with the addition of the "Read" operation in Resources 13 to 20 and still calling the revised Object v1.1.

[sbernard31]

I'm not sure if using only 2 digits for versioning is a good idea but keeping bugged version of model doesn't make sense to me.
I mean in this particular case, we have several resource without any Operation, how this can be used ?
Either we need to remove it or add value to the operation field. (probably to add value)

If none of this is done, what will do implementers ?

• either they will continue to use a bugged/partially unusable version
• or they will fix this on its side. (with the risk that each one do it in a different way and so with interoperability issue)

If we follow the current policy, if Object 1 v1.1 changes, it implies that v1.1 is kept as it is and the object now will be superseded by the next version v1.2.

Of course for bug fixes this doesn't make sense, eventually we can live without PATCH number(only 2 digits) but we should be able to fix an existing version without change the MINOR number. And repository should contains at least last fixed version of each MINOR release.

Unless I am misunderstanding the comment, OMA will have to change the way they implement changes on their Objects as currently, it is not possible to re-write Object 1, v1.1 with the addition of the "Read" operation in Resources 13 to 20 and still calling the revised Object v1.1.

You get me correctly, we need a way to bug fix model already released without incrementing MINOR version.

[jpradocueva]

@sbernard31 thanks for the clarification. I will bring this issue to tomorrow's IPSO/DMSE meeting

[pelya]

If none of this is done, what will do implementers ? either they will continue to use a bugged/partially unusable version or they will fix this on its side. (with the risk that each one do it in a

different way and so with interoperability issue) That's what we did in our client, the spec is pretty clear that these resources should have at least the Read permission, and the scheme has a typo, so we implemented Read operation.

[dnav]

Personal opinion:

Using version 1.1 of the Object with different operations than those defined in the XML can only lead to interoperability issues.

Version 1.1 contains buggy but optional Resources. If these Resources are needed for your use-case, you should consider using the version 1.2 of the Object.

[sbernard31]

Using version 1.1 of the Object with different operations than those defined in the XML can only lead to interoperability issues.

I agree

If these Resources are needed for your use-case, you should consider using the version 1.2 of the Object.

But the version v1.2 of this object targets LWM2M v1.2 as minimal version.
So if you are using LWM2M v1.1 you can not bump to the version 1.2 of this object. 😞

This kind of scenario show why we need a way to release bug fix for object model.

[sbernard31]

thanks for the clarification. I will bring this issue to tomorrow's IPSO/DMSE meeting

@jpradocueva do you have any update about how managing this kind of issue ?

There are needs of this for LWM2M v1.1 in Leshan (see : eclipse-leshan/leshan#1393)
Do you advice Leshan team to embedded a fixed but not official version of the model for v1.1 ?

[jpradocueva]

@sbernard31, the only thing I can do is bring it to the group's attention again. I will mention that the problem has not been resolved.

[sbernard31]

the only thing I can do is bring it to the group's attention again

@jpradocueva thx for doing this 🙏

Do you know what was the "conclusion" of this discussion last time that was reported to the working group ?

[jpradocueva]

@sbernard31, the group has not formally reviewed your request yet. It is on next week's agenda.

[dnav]

This is the official answer from the DMSE group from the 2023-03-14 meeting:

The Resources 13 to 20 in the version 1.1 of the LwM2M Server Object (ID: 1) do not have defined operations. This means that only the LwM2M Bootstrap Server can set these Resources during the Bootstrap procedure. This was intentional.

With experience and new use cases, in the version 1.2 of the LwM2M Server Object, the Resources 13 to 20 were changed to allow the Read operation. Resources 14, 17, 18, 19, and 20 also allow the Write operation from LwM2M Servers. With this later change, LwM2M Servers can configure the delays and retries of the Single Ordered or Unordered Server Procedure to adapt to changing network conditions (if authorized by the ACL).

Note that a LwM2M 1.1 Client could use the version 1.2 of the Object, and choose to not implement the Resources 24 to 27. Its Registration payload would be:

</1>;ver=1.2,</1/0>,</3/0>,...

Regards,

[sbernard31]

Thx a lot for clarification, that's really help 🙏

About,

Note that a LwM2M 1.1 Client could use the version 1.2 of the Object, and choose to not implement the Resources 24 to 27.

I'm not so comfortable with the idea to allow a LWM2M 1.1 client to use an object model with <LWM2MVersion>1.2</LWM2MVersion>.

[jaimejim]

@sbernard31 is there anything actionable for the DMSE to be done here or can we close the issue at this point?

[sbernard31]

@jaimejim, I think we can close this. Thx again for clarification.

[mkgillmore]

Group agreed to close 4-4-2023