openmobilealliance / oma_lwm2m_for_developers Goto Github PK

In the new draft of the Software Management Object (Draft Version 1.0 – 04 Feb 2015), the software "update" (new version of an installed software) is not mentioned anymore.

Following the existing Package Installation State Machine, there is no way to get back to the INITIAL state (unless an uninstall operation is performed).

Is it possible to clarify this point?
Thanks.

The LWM2M Security Object defines both Resources 3 and 4 to carry the PSK Identity, but there is only one. Only for public key cryptography the keys differ for Client and Server.

Is this a copy and paste error?

Test cases 6.2.1 through 6.2.3 use the same label "int-201"

5.3.1 Register
...

„However, devices might be hosting other Resources on an endpoint, 
and there may be the need to place Objects under an alternative path.“

(How) does this feature combine with the current "online" bootstrap definition?
Or does the "alternative path" features exclude a client/server initiated bootstrap?

I've come across situations where a resource of type integer doesn't currently have a value. Usually this occurs when a device supports a feature but some error condition is currently causing that feature to be unavailable.
How should the client handle reads of the value?

The options I've tried so far:

• Return a zero-length text representation or a TLV representation with no resource. Makes sense to me but some servers I've tried generate an error.
• Return some default value. May be OK for some resources but not good in the general case.
• Return 404 not found. It concerns me that some servers may take that to mean "This resource is not implemented", particularly for optional resources.

Figure 17 in 8.2.2 Bootstrap Interface shows 2.03 Valid, This should be a 2.04 Changed.

I'm not sure if this in an issue, but the behaviour seems strange.

LWM2M defines default pmin and pmax values in the Server object, so each server can have a different value. However it also allows them to be set with attributes, which would seem to apply to all servers.

If one server is relying on the default values it wont know that another server has overridden them until it gets inappropriate (extra or none) notifications.

I note that both mechanisms are optional for the client, so one solution would to be to implement one or the other but not both. However I wonder if the default pmin & pmax should be moved to the single-instance Device object to completely remove the server-specific nature? Perhaps a notification should be sent to all affected observers when the attributes are changed?

CoAP supports two official ways to cancel an observe realtionship:

• Proactive through a GET request with Observe=1
• Reactive through empty RSTs in reply to Notifications

GET with Observe=1 should be the preferred way for LWM2M. Reactive cancellation needs to wait for the next incoming Notification and CoAP servers may ignore RSTs for NON Notifications (but MUST mix in a CON Notification once in a while).

These should replace the Write Attribute "cancel" to make use of the available features in CoAP libraries and for conformance with the IETF standard.

When a client receive a :

• CoAP POST on objectID/instanceID/resourceID, this may be a Write with update request or an Execute request.
• CoAP POST on objectID/instanceID, this may be a Write with update request or an Create request.

For the first one (write/execute), if the client know if the resource is executable or writable it could manage this. If the resource is WE, we're lost. (In all case, this complicate the code a lot ...)
For the second one (write/create), there 're no way to know if the server want to create or update.

Maybe, we should always use PUT for Write and add a param in the query to define if we want an update or a replace
The other solution is to remove the replace and define that a create on an instance which already exist do a replace (it this case a create request could receive a 2.04 response) and use PUT to do update but this mean we could not do replace at resource level.

But in all case, a Write with update seems to be idempotent, so this should be a PUT rather than a POST.
http://tools.ietf.org/html/rfc7252#section-5.8.3

When resources are R-only, what must then be obeyed using the operation create or replace on object instances?

Example:
An object (id 50000) defines to have a mandatory R-only resource (ID 1, water level, R, S, M, …).
To create a new instance of 50000, must the resource with ID 1 be provided?
To replace a instance of 50000, must/could the resource with ID 1 be provided?

At §8.5, for register request, the specification say :
4.03 Forbidden The Endpoint Client Name results in a duplicate
entry on the LWM2M Server.

and at §5.2.1 :
If the LWM2M Client sends a “Register” operation to the LWM2M Server even though the LWM2M Server as registration information of the LWM2M Client, the LWM2M Server removes the existing registration information and performs the new “Register” operation. This situation happens when the LWM2M Client forgets the state of the LWM2M Server (e.g., factory reset)

I think the 4.03 response code description should be used instead when a client is not allowed to register on a server. (a typical use case)

The Technical Specification in chapters 5.2.2.3 Client Initiated Bootstrap and 5.2.2.4 Server Initiated Bootstrap states:

The LWM2M Server SHOULD purge the LWM2M Bootstrap Server Account after successful bootstrapping.

But the Bootstrap Server Account is stored in the LWM2M Security which is not accessible to any LWM2M Server.

Moreover the same chapters write:

the LWM2M Client MUST purge the LWM2M Bootstrap Server Account after the timeout value Bootstrap Server Account Timeout, if defined, or immediately after successful bootstrapping if the timeout value is not defined.

Thus the whole unbootstrapping procedure described in chapter E.1.3 seems unreachable since there will never be a bootstrap server to remove a LWM2M server the client is registered to.
It is also impossible to add new LWM2M servers to LWM2M clients during their lifetime without factory-resetting them.

Currently, LWM2M picks specific CoAP response codes to inform about certain outcomes of operations. This does not safe complexity or memory on devices. It only complicates debugging: many errors cannot be described properly, although a corresponding code would exist in CoAP.

LWM2M should make use of all the response codes, in particular the error codes and potentially the diagnostic message. If a constrained device needs to safe memory, it could only evaluate the response code class.

Register

   CLIENT  --> DTLS Client Hello --> SERVER
                   <--      SERVER Hello  <--
                  -->        …                     -->

CoAP indicates that a new session is needed for the following command READ

   CLIENT    <-- DTLS  Client Hello    <--
                    -->     Server Hello         -->
                   <--         …                       <--

It is not clear in the specifications.

TS, section 7.1.1 Pre-Shared Keys.
According to OMA LwM2M TLS_PSK_WITH_AES_128_CBC_SHA256 is mandatory. However in CoAP [RFC7252], only TLS_PSK_WITH_AES_128_CCM_8 is mandatory. And the same in the DICE profile.

Also in TS, section 7.1 indicates:
2) Bootstrapping with a temporary, low-entropy pre-shared secret (such as a PIN, password and private serial number) using the cipher-suite TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA256, as defined in RFC5489.
IETF recommends do not use TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA256, (DICE and UTA Working Group).

It is suggested that TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA256 should be removed from the specifications.

Test Case number –int 302 Firmware Update (via alternative mechanism)

Currently the firmware update objects only provides a package URI without any further description such as length, criticality, etc.

What are the Use Cases for this?

Possible solution is to have an optional resource for package description.

The test cases should primarily be about testing all the different operations on different levels (Object/Instance/Resource). The current test spec randomly tests Object functionality and covers different operations rather by chance.

The OMA-TS-LWM2M_SwMgmt document defines a range of 1-4, while the description lists states 1-5.

Usually state enumerations start with 0 in LWM2M. Thus, fix to range 0-4 in both columns.

The attendees to the Dusseldorf LwM2M TestFest indicated that in general OMA LwM2M specifications define more mandatory functionality than in CoAP.
Friedhelm Rodermund from Vodafone, took an action item on to further investigate this perception.

Is it possible / allowed to add manufacturer specific error codes to Resource ID 11 Error Code of the Device Object (Object ID 3)? If yes, what range can be used?

The XML document for the LWM2M Security Object has a typo in the name field: "LWM2M Server URI" with two spaces

It can happen that the Client receives a request (Read or Write operations) before the registration is completed, (it received 2.01 Created response).

How should the client respond?
What the Server should expect?

Due to UDP re-ordering this can happen any time.
A time out or backoff could cause problems with the sleep mode of the Client.

Expected behaviour must be defined in the TS.

In OMA-TS-LightweightM2M-V1_0-20141126-C some resources were added:
Device: Resource ID 17 - 21
Firmware Update: Resource ID 6 - 7

Will these additional resources be added to the 'object description files' (TXT files) included in the enabled release?

Btw. the resources in the Device object in chapter E.4 (OMA-TS-LightweightM2M-V1_0-20141126-C) are not sorted by Resource ID.

The Bootstrap Interface does not define the Create operation, although the Bootstrap Server expects the Instance not to exist. The example in Figure 17 shows a Delete, after which no Instances should exist.

The Bootstrap Interface is similar to the Device Management and Service Enablement Interface. Thus, the operations should follow the same logic.

TS, section E.1.1.1
Clients and Servers MUST support a PSK Identify of *at least 128 bytes* in length as required by [RFC4279].

But in RFC4279:
5.3 Requirements for TLS Implementations
TLS implementations supporting these ciphersuites MUST support arbitrary PSK identities up to 128 octets in length, and arbitrary PSKs up to 64 octets in length.

This discrepancy should be resolved.

LWM2M Object: Bearer Selection -- Preferred Communications Bearer Resource (ResID 0)

Specification of values incomplete

• Issue: The spec does not define the use of values above 100. This may lead to issues if implementations use these values that may later on be assigned by a revision of the standard
• Suggested Remedy: Make values above 100 (i.e. 101 -- 254) "reserved"; assign at least one value as "vendor-specific".

With the current values available for the update result resource (/5/0/5), there is no way to indicate that the firmware installation has failed.

This is not consistent with the update results defined for the SW update, where the value 10 (Software installation failure) can be used.
Note that value 9 (Device defined update error) is also defined for vendor specific errors. But this is not clear to me how to use and if it is restricted to a single error code.

The TS 20150228 mentions in E1.1.2
„Thus the Certificate Resource would contain a 32 byte public key and the Secret Key Resource a 32 byte private key.“
But ECC uses two public keys (“x” and “y”) each of 32 bytes.
Should public key x and public key y be stored concatenated (xy, 64 bytes) in the "public keys" resources?

Is offline/online only defined by "not sending/receiving a message from the client" for ACK_TIMEOUT?
Must a server stop retransmissions, when not receiving an ACK in time?
Or should the server retry and only stop, when the maxium retries are reached?

A Device Management server is allowed to add new LWM2M Server Instances, for instance, to allow access to Service Enablement Resources for applications. However, LWM2M Security Instances can only be created/written through the Bootstrap Interface.

How should the Device Management server configure the security settings for new LWM2M Server Instances?

Test Case 6.2.2 expects the Object Instance TLV in the Test Procedure, although TS 6.3.3 states that the Instance TLV is omitted for Single Instance Objects.

TS LwM2M section 8.2.5.
CoAP recommends to send 2.05 Content as response code for Notifications but OMA defines 2.04 Changed instead.

OMA-TS-LightweightM2M-V1_0-20141126-C, 7.3.2.3 and 7.3.2.4, both mention, that “observe” MUST be performed by an LWM2M client. But 7.3.2.5 mentions, that the LWM2M client MUST check the LWM2M server read authorization. Though observe initially also reads the value (5.4), this seems to be inconsistent.

TS 8.3, Queue Mode Operation
"If a request is unsuccessful then it is returned to the queue."
may cause serious problems! There may be several reasons for a request to fail.

So define, in which unsuccessful cases the request should be returned to the queue (only ACK timeout?).
When the request should not be returned to the queue (e.g. failed with COAP 4.02 Bad Option), what should be done with the left requests in the queue? Process them may result in unexpected behavior.

When the request should be returned to the queue, should it be returned at the head or at the tail of the queue? Returning at the head may block the communication. Returning at the tail reorders the messages, which may also result in unexpected behavior.

Or are there any (undocumented?) assumptions about the requests usable for queue mode?

LWM2M.xsd version:
version - 1.0
date - 21 Nov 2013

According to the LWM2M specification (OMA-TS-LightweightM2M-V1_0-20141126-C), the Object ID and Resource ID is a 16-bit unsigned integer. But the LWM2M.xsd defines unsignedByte instead of unsignedShort (see line 89 and 162 in http://openmobilealliance.org/tech/profiles/LWM2M.xsd).

In TS, for object 7 (in appendix E):
This LWM2M Objects enables client to collect statistical information and enables the LWM2M Server to retrieve these information, set the collection duration and reset the statistical parameters.

But the collection duration is not really set.
Collection is launched when an EXEC command is sent on /7/0/6 (StartOrReset), so there are no duration concept.
Moreover, it may be not possible to stop a collection "duration", when the collection is launched, it's only possible to reset all counters but not to stop collecting data.
Or do any device reset could be considered as a duration stop ? (meaning that an EXEC command shall be sent on /7/0/6 to launch again the collection ?)

The LwM2m Spec define possible response codes for each request (§8.5).
I think this response code Internal Server Error 500 is really needed, for unexpected situation !

(Currently, when an error occured in leshan we return a bad request but an exception raised at server/client side is not a bad request ...)

Each test case should provide the target URI (object/instance/resource).

CoAP says "The curve secp256r1 MUST be supported" but also "The type and length of the raw public key depends on the cipher suite used". I think that means that it doesn't prohibit other curves.

If that's the case then there needs to be a "curve name" resource in the security object.

The TS should state that the CoAP Accept option is used to choose between different formats.
It should also be a "MUST" to include the CoAP Content-Format option for Write and Create operations.

Consequently, the Register Interface "MUST" also set the Content-Format to "application/link-format".

Normal Flow
a. The server delivers the firmware URI to the device through a WRITE (COAP PUT/POST) operation on firmware/URI
b. The device downloads the firmware from the URI via an alternative mechanism (not COAP)

Comment
The Server just provided an URI for the Client to download it.
It was suggested to add an optional resource for package description.

6.2.6 uses "terminal," which is not defined in LWM2M.

6.5.1 uses "Line Voltage" -- should be "Power Source Voltage"

When attributes are written multiple times, should this be handled as update or as replace?

Example:

1. write attrib /3/0/9?lt=30
2. write attrib /3/0/9?gt=70

Is the result "gt=70" or "lt=30&gt=70"?

“5.1.3 Bootstrap Sequence” doesn’t contain information on what should be done, after the bootstrap started. Especially, it doesn’t contain information, when the client should try to register at a LWM2M server after the bootstrap has started. There is no specification, when the client should assume, that the bootstrap is finished.

Should therefore the "lifetime" be used as timeout for the bootstrap? e..g whon no write nor delete is received for longer then lifetime, the the bootstrap is assumed to be finished and the client shoul try to register ar a LWM2M server.

Anybody can describe IPR issues when one uses LWMWM?
In IoT world, there are many small companies. Therefore, IPR policy should be changed to more free, I think.
First of all, we need to make the IPR declaration list about LWM2M.

In OMA-TS-LightweightM2M-V1_0-20141111-D, Appendix D., section D.1, the Type field is specified as "Data Type indicates the type of Resource value. Data Types used in this enabler are described in Appendix C Data Types.".
I interpret this so that the Type field may never be empty. However, resources only having an "Execute" operation typically have this field blank and the LWM2M.xsd also accepts the blank value as a type.
I would suggest codifying this rule in the Technical specification.

TS, section 5.3.4 Table 9 Write Attribute parameters.
The table doesn't indicate how to handle multiple attributes, e.g. AND, OR.

Clarification is needed to the following use case.

In Chapter 5.1.2 "Attributes Classification" for the following Attributes the Value Type Integer is specified.
Minimum Period
Max imum Period
Greater Than
Less Than
Step

In Chapter 5.4.2 "Discover" some examples are listed in which a floating-point value is used and not the integer value which is specified in Chapter 5.1.2 Attributes Classification.
e.g:
</3/0/7>;ep=1;dim=8;gt=50;lt=42.2,
</3/0/7>;ep=2;dim=8;pmax=300;gt=80;lt=75.5

What Value Type must be used Integer or floating-point?

At the testfest event it was agreed that OMA should register with IANA the following content type: (as it is unique to LwM2M)
application/vnd.oma.lwm2m+tlv

Also, it was discussed that the content type
application/vnd.oma.lwm2m+json
didn't need to be registered with IANA but it was suggested to check with SENML (IETF), still in draft. Matthias Kovatsch agreed to check this point.

Also, later on was suggested that all the content types need to get from CoAP an entry ID (integer value) in the CoAP register.
At the event we used the following types:

• Plain Text - 1541
• TLV - 1542
• JSON - 1543
• Opaque - 1544
  In future events this needs to be resolved.

The following types was suggested that don't need to be registered with IANA as already exist:

• Plain Text
  application/vnd.oma.lwm2m+text
• Opaque
  application/vnd.oma.lwm2m+opaque NO, 42(application/octet-stream)

OMA WG is requested to review this problem and provide a resolution to OMA staff to initiate the necessary steps.

The standard "Lightweight M2M – Connectivity Management Object (LwM2M Object – ConnMgmt), Candidate Version 1.0 – 13 Jan 2015, contains inconsistencies

Inconsistencies

==> LWM2M Object: WLAN connectivity

• Resource definition ID 2 (Radio Enabled) allows only to specify that the system operates in the 2.4GHz or 5GHz bands.
• Resource definition ID 14 (Standard) specifies values for IEEE 802.11ah which operates in sub-1GHz bands.
• As both recource definitions are mandatroy, this causes a conflict for all 802.11 modes that operate outside the 2.4GHz or 5GHz band. It is impossible to have always a valid setting for the "Radio Enabled" and "Standard" resource definitions, e.g. for 802.11ah (Standard resource
  definition) it is impossible to specify sub-1G band in the Radio Enabled resource definition.