openmobilealliance / lwm2m-registry Goto Github PK

OMNA LwM2M Registry Vorto links have stopped working:
An issue has been created in eclipse : eclipse/vorto#1350
Once resolved the links will be update

The xml & technical specification validation has highlighted the following errors with the submission of Open-AIS objects:
Objects / Resources:
PRs need to be issued against "Open-AIS" branch: https://github.com/OpenMobileAlliance/lwm2m-registry/tree/Open-AIS

• 3388

  • 4001, range-enumeration is different from the value defined in the OMNA Registry
  • 4001, units are different from the value defined in the OMNA Registry
  • 504, incorrect "Type" value. It should be "Corelnk". This value is only defined in v1.1 of the lwm2m schema.

• 3389

  • 4001, range-enumeration is different from the value defined in the OMNA Registry
  • 4001, units are different from the value defined in the OMNA Registry

• 3390

  • 909, incorrect "Type" value

• 3391

  • 909, incorrect "Type" value

• 3392

  • 909, incorrect "Type" value

• 3393

  • 909, incorrect "Type" value

• 3394

  • 909, incorrect "Type" value

• 3395

  • 909, incorrect "Type" value

• 3396

  • 4001, range-enumeration is different from the value defined in the OMNA Registry
  • 4001, units are different from the value defined in the OMNA Registry

• 3397

  • 4001, range-enumeration is different from the value defined in the OMNA Registry
  • 4001, units are different from the value defined in the OMNA Registry

• 3398

  • 4001, range-enumeration is different from the value defined in the OMNA Registry
  • 4001, units are different from the value defined in the OMNA Registry

• 3399

  • 4001, range-enumeration is different from the value defined in the OMNA Registry
  • 4001, units are different from the value defined in the OMNA Registry

• 3400

  • 4001, range-enumeration is different from the value defined in the OMNA Registry
  • 4001, units are different from the value defined in the OMNA Registry

• 3401

  • 4001, range-enumeration is different from the value defined in the OMNA Registry
  • 4001, units are different from the value defined in the OMNA Registry

• 3402

  • 909, incorrect "Type" value

• 3403

  • 4001, range-enumeration is different from the value defined in the OMNA Registry
  • 4001, units are different from the value defined in the OMNA Registry

• 3404

  • 4001, range-enumeration is different from the value defined in the OMNA Registry
  • 4001, units are different from the value defined in the OMNA Registry

• 3406

  • 4001, range-enumeration is different from the value defined in the OMNA Registry
  • 4001, units are different from the value defined in the OMNA Registry

The following Object 10260, was updated to version 2.0.
However, the old object is still available and fail validation. See issues below:

Suggestion
Remove the Object 10260 version 1.0 from the registry as it causes validation errors

This issue was initially reporting in the "ipso-wg" repository: rhttps://github.com/OpenMobileAlliance/ipso-wg/issues/171

Object 3380 registered by GSMA has failed validation due to Reusable Resource 6038.
The Type value for this Reusable Resource inside of the Object is set to "Boolean" but the same Reusable Resource in OMNA has been defined as "Integer".

The group needs to decide what is the Object Version to apply here.
According to the TS- Core:

“7.2.1 General Policy
…
Object versioning aims at identifying the LwM2M Object modifications which can be categorized in 2 types defined below:
Evolution of type I: representing non-backward-compatible ("breaking") evolutions, namely:
a Resource characteristic (optional vs mandatory, data type, supported operations) is changed in the Object
a mandatory Resource is added to or removed from the Object.
a feature which is only defined by a new LwM2M Enabler, is added to the Object.
Evolution of type II: representing backward-compatible ("non-breaking") evolutions
an optional Resource is added or removed in the Object”
The staff can resolve this problem by creating and registering a new version 2.0 but as this was done by your company, we think that it is better to let you know and you can decide.

Is the new Object Version 2.0?

I work for a sensor manufacturer for environmental monitoring. Generally speaking I like what IPSO sensor objects have to offer. However, I'm frustrated that 'Application Type' -resource is missing in many sensor objects (3200-3350). Let's take an example Temperature /3303 that contains no Application Type. Our weather stations can contain multiple temperature sensors: air temperature, road surface temperature, sensor heating (rain gauge during winter) temperature, weather station ambient temperature, not to mention calculated temperatures reported by the station: dew point temperature, wind chill etc. It is absolutely necessary to identity application type of the measurement. I ask you to harmonize IPSO sensor objects so that they all contain 'Application Type'.

Object 10282
Mandatory resource has the incorrect value applied as either Yes or No
Element to be updated to the correct value of either Mandatory or Optional

Comments from Open - AIS experience:

However, I do think some of the learnings should trigger some clarification / discussion at your side:

-x- decide / document the correct and acceptable way to define string length:
A:
String
0-16 bytes

B:
String
0-16
byte

-x- consider new types / additional documentation to avoid some common "opaque“ types:
—> IPv6 Address / Adresses.
—> Vector Data (Vectors consist of multiple single types, that are packed into a single resource.
(My Suggestion / input for the vector discussion):
Vector
JSON-STRING, where the JSON-STRING given documents the components and structure of the vector data.

-x- suggest to allow for bit- or bytecount length definition within the RangeEnumeration field:
Actual: 0-18446744073709551615
Proposed alternative: 64 bits or .8 bytes

-x- With shared resources allow for specific Range definitions where the template definition is open:
e.g. the use of shared resource 4001: 0-16 bytes should be seen as compliant with the template / definition that says

Practical issue: It would be helpful to have an XML template that allows to copy-paste the xml-snippet for a shared resource. This would ease the interpretation work substantially.

We request modify the Object name and the company name.

Object name should be "Shareparkinglot".
Company name should be "XiangYiIOT Technologies Co., Ltd. ".

Thanks a lot.

R&A Review - From 2019-01-31 at 08:00 GMT to 2019-02-13 at 18:00 GMT

Submission of comments to enhance the current Object/RR guidelines

• http://member.openmobilealliance.org/ftp/Public_documents/DM/Permanent_documents/OMA-ORG-Guidelines_Creation_Registration_LwM2M_Objects_Resources-V1_0_1-20190115-A.zip

I work for a sensor manufacturer for environmental monitoring. Generally speaking I like what IPSO sensor objects have to offer. What we would like to see in sensor objects are harmonized resources for 1) average value (read) and 2) statistical period (read/write). Averaging is business as usual in weather station sensors, which are able to report current, min, max and averaged measurement values. For example, we use IPSO Rate object /3346 for reporting wind speed. Wind speed needs to reported as speed now, speed in gust (max) and standard 10 minute rolling average wind speed. Currently IPSO sensors already have min and max statistical values, which is nice, but not enough because there is no information about statistical period and no place for averaged value.

Object 10282 is registered as an x-label object, however the object urn has incorrectly been applied with ext - urn:oma:lwm2m:ext:10282, so this should be updated to x - urn:oma:lwm2m:x:10282