Thursday, January 30th, 16:00 UTC
Video: https://youtu.be/v_BCilp2mFM
Repo: https://github.com/t2trg/2025-01-data-models
Carsten Bormann (CB) gave intro to the meeting. This group is focused on
research, but works closely with IETF for standards. SDF is an example
of work based on what was first discussed at the T2TRG that later turned
into IETF work at the ASDF WG.
This meeting is focused on data modeling, with three talks.
Machine-readable information, especially across ecosystems, is useful
for IoT. There has been related work at T2TRG already since 2016/2017
and the WISHI workshop.
Back in 2016 you needed to write ~N^2 converters to interop with N
ecosystems. This was solved by providing a central model that can be
converted from/to, as worked out with WISHI. It's not just a single
specification, one starts noting layers that can be taken care of with
standardization activities. It largely involves semantic and structural
interaction model, and protocol mapping, all to keep in mind for
achieving interoperability.
There's a difference between translating models (of data) and data
(between models). We were planning to have talk today also on data
translation but due to speaker availability will need to take that
later.
Overview of first talk from BB, on supporting non-IP IoT ecosystems
(e.g., Bluetooth). Using SDF with extensions.
Overview of second talk from MG, following up on SenML-YANG. SenML is a
generic data model, and like SenML data, YANG can be efficiently encoded
in CBOR. There are similarities between SenML and YANG CBOR, which
deserves investigation for possible benefits.
Overview of third talk from CB, on the two dimensions of model evolution
(derivation and instantiation).
On expected next meetings: a security focused one in Feb/March, and one
focused on data models again around March/April. A F2F summary meeting
is likely for July in Madrid at IETF 123.
Bart Brinckman (BB) presenting. In enterprise deployments with non-IP
(e.g., Bluetooth) devices see many proprietary stovepipes and vertically
integrated solutions. Wanted to create a common API and standardizing
such would make sense. Started bottom-up and with API with 1)
provisioning to onboard devices to a network 2) gateway APIs to control
and communicate with devices 3) API for streaming telemetry from devices
to applications. For 1 settled on SCIM, IETF protocol from SCIM WG.
Heavily used for transferring user and group information. Added device
schema to onboard devices. Extensions for declaring BLE device and
extension would determine what version of BLE supported, how to connect,
is security supported, etc. Focused on instance of a device and
onboarding. NIPC protocol in the ASDF working group. Goal to be gateway
API for multiple non-IP protocols. Also telemetry interface based on
CBOR over MQTT/HTTP. Allows streaming data and broadcasting connection
state.
Relatively early in the work needed to register properties that are
mapped to protocol specific properties, e.g., "heart rate" mapped to BLE
service and characteristic IDs. Started with registering individually
but realized that data models like SDF can help to register whole thing,
including properties, actions, and events.
(p4) Declare the instance first with SCIM, then the interaction model
with SDF. Have protocol mapping between SDF affordances and device
(e.g., bluetooth) IDs. Then can perform NIPC operations against SDF
affordance. Bluetooth mapping no longer required. Finally the events are
published.
(p5) A simple model includes a network gateway (SCIM and NIPC server).
Here the application imports an SDF model, then registers (part of) it
against the network gateway that understands the model's properties. The
registration API can be used, but the SDF model can also be included in
the manifest, as a reference.
(p6) Other use case has app middleware. Typically network gatweay on
premise speaking to middleware in cloud and app talk to the middleware.
Operations in middleware and gateway same but application using SDF
model will tell middleware which SCIM model to reference and embedded
SDF in the SCIM model will be used.
(p7) Showing how to instruct the gateway about interactions and how to
perform actions / handle events, through protocol mapping.
Gateway will make SDF affordances available to the application. The
affordances contain protocol mappings (device details). Also API for
applications registering other applications to receive data.
(p8) A protocol mapping is tied to an SDF affordance (a property in the
shown example). It has a reference to the protocol in the protocol map,
together with other parameters. This has to be extensible if new
protocols come up. BLE and Zigbee now but could add e.g., EnOcean later.
(p9) Overview of NIPC APIs, as to operations on properties and events.
(p10) NIPC has been deployed though work is in progress. There's both
open-source and vendor-based implementations. Used for tracking assets
and people, monitoring patients and processes, enforcing physical access
control (e.g., doorlock) and more broadly connecting buildings. It can
use non-IP radios through access points. Deployments have reached a
large scale, up to 100k+ non-IP devices.
SDF really simplifies the approach and makes it easier application
partners to integrate with NIPC. Believe SDF makes it easier for apps to
support NIPC and devices.
(p11) References to IETF draft and Github repos with source code.
Ari Keränen (AK): Regarding the scale of deployment, p10 mentioned 100k+
non-IP devices. Which kind?
BB: That's a typo. It should be "IoT devices".
AK: Mentioned that customers make SDF files already. Can you have those
models available for people to use?
BB: We have some on the repos for the devices we use for testing, but we
should ask implementers to make their models available too.
CB: On p3, it's showing two non-IP ecosystems (enterprise/network), but
then also ZigBee and Thread. Can you elaborate?
BB: three different arrows; provisioning interface could use for both IP
and non-IP devices. Gateway is both SCIM and NIPC server. Sometimes
require the SCIM functionality but not NIPC functionality.
AK: What would be available as implementation for testing?
BB: by february in open source. End of fall in the field.
Lorenzo Corneo (LC): On p7, what's the rationale to have the ID
parameter as first element in the path?
BB: when talk scale, may end up with single gateway not able to serve
entire network. Typically built from IoT radios, centralized control
element, and gateway function. See scenarios where need multiple gateway
functions. Need a (preferably HTTP) proxy function. Specific device
attached to specific radio. If we have ID in the path can look up in
proxy which gateway is serving device and find the right gateway.
CB: Can you say something on broadcast/multicast? How do you find a
device in a broadcast fashion, e.g., based on its capabilities?
BB: broadcast heavily used for fire and forget. Modeled as event app can
subscribe to. See in many protocols that most broadcasts are not
interesting. Broadcasts are a NIPC event type; can subscribe with
specific ID. Basically just receive the broadcasts you want to receive.
CB: So these are broadcast messages from the devices to the
infrastructure. Do you also cover the opposite direction?
BB: yes, broadcast API as well, that wasn't shown. Discussed in last
ASDF meeting. Some APIs do explicit connection management, and broadcast
is one of them.
Manoj Gudi (MG) presenting. Follow-up from the Dublin meeting.
MG: We previously covered the main idea, this is a recap and a
follow-up.
(p2) The motivation is trying to find and take advantage of apparent
similarities between CORECONF-CBOR (YANG-CBOR) and SenML-CBOR. Can
compress better than CBOR SenML (example 98 bytes vs. 93 for two
records). Packed CBOR can further ensure that data are sent with no/less
redundancy. Also opportunity avoiding sending static structures every
time.
(p3) YANG allows you to add constraints, so corresponding rules have to
be checked by implementations (there's good support for this in today's
libraries).
(p4) The interesting point is the arguable path SenML--YANG--SDF--Matter
(and other ecosystems). SDF is a widely interoperable ontological model.
YANG model allows adding more semantic information to the SenML data.
(p5) Exploring issues about the manual assignment of SIDs (identifiers)
to SenML-YANG, being able to represent the label "n" that is 0 (though
delta 0 is not admitted in YANG-CBOR), narrowing the available options
in SenML-YANG
(p6-9) Handling of representing the label "n", which should be 0. One
option is to literally keep it as "n", but it would break the YANG-CBOR
specification. Another option is giving "n" another numeric label
different from 0, which would also break things in terms of
compatibility. Another option is to never have an actual name, but
instead a base name every time, which is less efficient but at least is
backward compatible.
(p10) Open point: how big is compatibility an issue? How widely is SenML
used today? What's the best/easiest way to fix this? Let's find out
together. There are likely other problems to explore beyond this.
AK: On backward compatibility, that feels easier to fix on the YANG side
since don't have many implementations there yet. Interesting to see if
we can have these different pieces co-existing and working together can
act as the red star bridging different ecosystems.
MG: It becomes otherwise tricky with heterogeneous devices.
AK: Wonder how we can build on that line but with a focus on the data
too.
CB: We can also continue this discussion on the mailing list.
CB presenting.
(p2) This looks simple but it's deceptive. Gets complicated when you
have more than one of each kind.
(p3) We end up instantiating and deriving models for IoT devices, which
then we use in messages.
(p4) Summary of the SDF class-level information, with nothing specific
on instances. Some hints on data on information model level. Which
direction to involve this to have better coverage on what we want to do.
In the ASDF WG discussing location information, that applies to
instances.
(p5) The different models evolve. To deal with that, we have versioning,
but versions are just labels without a structure. YANG has elaborate
backwards-compatible/not rules. In particular we can't refer to
subranges of versions. It's also undefined who is in charge of the next
version number to be used for what and when. When ecosystem using
versions they are in control, but in general not solved.
For model derivation can use sdfRef for structural reference, but
relationship between the base model and the derived one is not defined.
(p6) Example with sdfRef, which uses Curies (short way of writing URIs).
If base model changes here, we may run into problems.
(p7) sdfRef is really simple, possible to implement in a few hours.
Other things are suboptimal: no support for controlling derivation in
the base model; changes in the base model can be breaking to derived
models
(p8) The derivation is subclassing-oriented, but it might not be fully
compatible with some languages.
Even if substitute is OK on the digital side, may not be in the physical
side. For example changing light switch to a dimmer may break in the
physical world.
(p9) Derivation is needed in many use cases, e.g., for creating a
variant of a given device, or for revising a model (fixing, maintenance,
extension), or for adapting to more ecosystems
(p10) Now we can reference a base model by URI. Referencing specific
version, there's no automatic pickup of bug fixes but we're in full
control. Another option is the URI pointing to just any revision (rather
than the latest one) but it can be dangerous as the result might not be
the desired one. Or one can specify a subrange of model revisions, with
control to some extent. May want to make semver available as feature in
sdfRef.
(p11) On instance information, it includes pieces of information about
identity, purpose and physical side
(p12) Instance information has to be made available during
instantiation, which is an affordance and might be described by the
interaction model. A few problems: lack of control, information may
change and not be in the device.
(p13) SDF provides the information model, but not the data model and
corresponding serialization. Those have to come from the specific
standards and ecosystems using SDF.
MG: versioning, does version flag offer information about compatibility.
Major number matches is backward compatible, or similar?
AK: Now we don't specify versioning in that detail, we can't compare in
general. Ecosystems may choose to use the version in semver way.
Milan Milenkovic (MM): Where does W3C Web of Things fit here?
CB: WoT was developed in pretty close contact with what we were doing.
WoT was not designed to be the red star that SDF aims to be. From SDF
point of view, consider it as another ecosystem.
AK: running over time now but we can continue the detailed discussions
on the topic in the upcoming meetings. Please follow the mailing list
for announcements.