Bootstrap Server Account cannot be properly handled during the bootstrap procedure

[kFYatek]

As described in the current revision of TS 1.0, section 5.2 "Bootstrap Interface", to perform either Client Initiated Bootstrap or Server Initiated Bootstrap, the LWM2M Client needs to have an "LWM2M Bootstrap Server Account", which is an instance of the LWM2M Security (0) object with the resource "Bootstrap Server" (1) set to true.

The Bootstrap Server communicates with the Client over the Bootstrap Interface, which defines only two operations on the data model, BOOTSTRAP WRITE and BOOTSTRAP DELETE (as BOOTSTRAP REQUEST and BOOTSTRAP FINISH can be described as control commands rather than actual operations)

It means that the Bootstrap Server can only perform the bootstrap procedure "blindly", as it cannot read the client's data model in any way. This is not a big problem for the typical bootstrap case, as "BOOTSTRAP DELETE /" can be used to clear the data model, then the Bootstrap Server may create the essential objects from scratch, and the rest of the configuration procedure can be done by ordinary LWM2M Servers (which may in fact cooperate, or even be physically integrated, with the Bootstrap Server).

However, as section 5.2.5.2 states, "BOOTSTRAP DELETE /" operation:

MUST delete all the existing Object Instances - except LWM2M Bootstrap Server Account - in the LWM2M Client

Since the Bootstrap Server Account is necessary for communication with the Bootstrap Server, it effectively means that the "BOOTSTRAP DELETE /" operation will always put the data model in a state in which exactly one configurable Object Instance is present - the Bootstrap Server Account.

However, its Instance ID is unknown to the Bootstrap Server. This means that when the Bootstrap Server wants to perform the BOOTSTRAP WRITE operation in order to create a Security Object Instance for a regular LWM2M Server, it cannot be sure whether that operation will create a new Instance, or (with effectively 1/65535 probability, which makes it a bit of a Bootstrap Russian Roulette 😉) overwrite the Bootstrap Server Account.

A possible workaround for this problem would be for the Bootstrap Server to recreate its own Bootstrap Server Account in addition to creating instances for regular servers. However, this could (again, with 65534/65535 probability 😉) violate the requirement stated in 5.2.1:

The LWM2M Client MUST have at most one LWM2M Bootstrap Server Account.

However, the result of Bootstrap Server making an attempt to violate this requirement is not well specified. If such attempt results in the Client returning a 4.00 Bad Request response (the only applicable error permitted by 8.5 "Response Codes"), it allows for a possibly somewhat interoperable way of operation for the Bootstrap Server - after having performed "BOOTSTRAP DELETE /", it may attempt to write its own Bootstrap Server Account on some Instance ID - if the client responds with 4.00 Bad Request, it means that the ID is unused and it can then proceed with writing a regular server account onto it. Such flow is, however, extremely convoluted, counter-intuitive, inefficient, and probably not in line with the intentions of the specification authors.

I believe that the proper solution would be to:

• Explicitly define the Bootstrap Server Account Instance ID, e.g. define that Bootstrap Server Account is always the /0/0 Object Instance; it may also make sense for that designated ID to be reserved only for the Bootstrap Server Account,

and/or:

• Add some new operations to the Bootstrap interface that would allow the Bootstrap Server some degree of read access to the data model.

[ThGarnier]

What about letting the Client - regarding the Security Object only - to allocate from its own, the
Security Object Instance ID (and so Client will "avoid" to reuse the existing Bootstrap Security Object Instance ID) . This automatic allocation is already used in the certain case for the CREATE on another Interface. In fact on the Bootstrap Interface, it is not (strictly) forbidden, since in the WRITE command itself the Object Instance ID is not required (only the notes says this Object Instance ID must be present in the TLV or JSON payload). So the spec has not to be changed too much (commands are not modified), few text should have to be added saying that in the particular case of the Instanciation of the Security Object (only the WRITE on the BOOTSTRAP interface is concerned) the Instance ID - when provided - is ignored by the Client which will automatically allocate the ID (which is in fact used by no one I guess) make sense ?

[kFYatek]

So, you're suggesting allowing to call BOOTSTRAP WRITE with the Location URI set to e.g. /0, with payload in TLV format containing multiple Resource entries without a root entry, which would be semantically equivalent to a similar call to CREATE from a regular server?

I guess that would solve the issue, although I personally find it semantically ugly, because it would make a "write" operation behave like "create", which is somewhat counter-intuitive. Even more so, considering the fact that on the CoAP layer, BOOTSTRAP WRITE maps to a PUT request, which is required to be idempotent as per RFC 7252, 5.1. Allowing BOOTSTRAP WRITE to create new instances with unspecified IDs would violate this requirement.

[FredRodermund]

Wouldn't this be the simplest way forward:
Define that Bootstrap Server Account is always the /0/0 Object Instance ?

[kFYatek]

Yes, this would be an acceptable solution, I think. But there are still some issues that would need to be addressed with such change:

• Would the IID=0 be reserved for Bootstrap Server Account (i.e. any regular LWM2M Server Security account MUST NOT have IID=0) or merely the only allowed value for it (i.e. when there is no Bootstrap Server, a regular LWM2M Server Security account MAY have IID=0).
• If IID=0 would be reserved for Bootstrap Server Account, then the Bootstrap Server Resource (/0/*/1) would be superfluous and removing it would make some sense.
• 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/*, so it might make some sense to define a separate LWM2M Object (with different Object ID and defined as having 0 or 1 instance) just for the purpose of holding the Bootstrap Server Account.

These are just my remarks about @FredRodermund's idea, which I believe need consideration before merging it into the spec.

[jpradocueva]

Agreed with DM Working Group to close.