Difference between Binding (7) and Preferred Transport (22) resources in Server Object

[sbernard31]

There are 2 resources to set transport binding to use in Server Object :

• Binding (7)

This Resource defines the transport binding configured for the LwM2M Client. If the LwM2M Client supports the binding specified in this Resource, the LwM2M Client MUST use that transport for the Current Binding Mode.

• Preferred Transport (22)

Only a single transport binding SHALL be present. When the LwM2M client supports multiple transports, it MAY use this transport to initiate a connection. This resource can also be used to switch between multiple transports e.g. a non-IP device can switch to UDP transport to perform firmware updates.

It's not clear to me what is difference ?

(Tell me if I should rather open this issue at : https://github.com/OpenMobileAlliance/lwm2m-registry)

[asoloway64]

Please refer to clause 6.2.1.2 in the Core Specification:
"Preferred Transport" is an optional resource in the LwM2M Server Object (/1/x/22). If this resource is defined, the
client SHALL use this to initiate a connection over the specified transport, unless unable to do so. If this resource is
not defined, the client SHALL use a client-preferred binding supported by both the server (from the list in the
"binding" resource of the LwM2M server object - /1/x/7) and client (from the list in "Supported Binding and
Modes" resource in the Device object - /3/x/16).

[sbernard31]

@asoloway64 🙏 Thx for the clarification.

Reading §6.2.1.2. Behaviour with Current Transport Binding and Modes, I think this is pretty clear.

But I feel that Binding (7) description is confusing :

This Resource defines the transport binding configured for the LwM2M Client. If the LwM2M Client supports the binding specified in this Resource, the LwM2M Client MUST use that transport for the Current Binding Mode.

Maybe it should be rewritten ? e.g. with something like this (Inspired by resource /3/0/16 Supported Binding) :

Indicates which bindings are supported by the LwM2M Server. The possible values are those listed in the LwM2M Core Specification.

Maybe some resource renaming should be done too ?

• /3/0/13 : Supported Binding and Modes to Supported Bindings
• /1/?/7 : Binding to Supported Bindings
• /1/?/22 : Preferred Transport to Preferred Binding

Maybe a link to §6.2.1.2. Behaviour with Current Transport Binding and Modes could be add to description resource for this 3 resources ?

[asoloway64]

Thank you for your suggestions! We are always striving to improve the specification, so we will consider these changes in future versions.

If you are so inclined, we are always looking for companies to join OMA and actively participate in their areas of interest.

[sbernard31]

Probably a detail, but first paragraph in §6.2.1.2. Behaviour with Current Transport Binding and Modes is maybe a bit confusing too. Especially when you come from LWM2M 1.0, where client MUST use server "Binding" resource as current binding.

Behavior of the LwM2M Server and the LwM2M Client is differentiated by Current Transport Binding and Modes. Current Transport Bindings are decided by "Binding" Resource set by the LwM2M Server. The "Binding" resource contains a combination of supported transports, for example UDP and TCP.

[sbernard31]

If you are so inclined, we are always looking for companies to join OMA and actively participate in their areas of interest.

I try to contribute by giving feedback as an implementer.
Maybe a way to make the process better would be to make the github repository of the specification open.
This way user could :

• open issue directly at the specification repo,
• after discussion with OMA committers, he could either open a PR or review the PR written by a committer relative to this issue.

The other benefits is that users could follow all modifications with open discussion about the choice and could maybe detect issue sooner.

[hannestschofenig]

While there are benefits in opening up the standardization process there are also disadvantages, as you know. My impression is that the members think that the disadvantages are bigger than the advantages in this case.

Luckily you, Simon, work for a member company and hence you would be able to participate in the standards process without any restrictions.

[hannestschofenig]

After further discussions in the group we decided it is not a good idea to add references to the resources of the object because changes to the specification will then lead to further updates to the objects/resources. It is easy for the links to get out of sync. For this reason we avoided references to sections in our objects.

[sbernard31]

It is easy for the links to get out of sync. For this reason we avoided references to sections in our objects.

I can understand this. 👍
and what about other changes proposed ?