Note Well. https://www.ietf.org/about/note-well/
Logistics for Meeting
WG status update (10 min) + mic discussion
Actually, IETF Last Call has occured, but IESG review is still to
come.
SDF NonAffordance discussion
MJK presenting
MJK: need to take a step back. Location good start but big picture
important. Non-affordance information and instance graphs.
CB: in seq instance graph two parts: instance and graph. Don't care of
graph since can do that. Need to focus on the instance part. What is
important: single thing, not model number (etc). In class info would
have "for all my items want to have inventory number", in instance would
have one inventory number. For links need to discuss RDF compatibility
but instance part is independent of that.
MJK: here not much on instance. But gone from JSON schema type
definition to instance, e.g., using const qualities for IDs.
SDF affordances are SW interfaces. Digital Twins have/need more
information: non-affordance info (assets, orgs, equipment, control
graphs).
Made up new name "declared properties" for this. Would have pre-declared
values. Using sdfData definitions. Unsure if would need registry for
keywords. Where to put the definitions so anyone using SDF would have
access to the same data model for location.
from chat:
Matthew Gillmore: In the context of ASDF, what is
the difference between Object vs Thing level?
Carsten Bormann: For historical reasons, Object is a
named package of properties, actions, and events
(and data type definitions going with that).
A Thing is a package of Objects (and P, A, E),
so it can have some substructure.
CB: pointing out use case: have lots of projectors at the university.
Has serial # etc, but really need a system for reserving it and giving
it back. Would call for actions. Would like to keep my mind option to
interactions that we have that are not affordances of a thing but
affordances of another system that is related. That is maintaining some
information about the system.
MJK: yes, could be time series data bases for example. Not from the
device itself. Third category of Things referencable from the device
that are specially handled?
MJK(p5): example of sdFDeclaredProperty. Invoke template with sdfRef.
Declaring individidual waterPump, could declare "housingColor" to "red".
Could be called also "nonAffordanceInfo" here.
MJK: graph may not be difficult since we have links and relations
already. Think there is use case for transforming SDF to RDF. Needs
relations and hyperlinks. But need to run some examples. We don't have
constraint language like SHACL.
...
One way of having instance is singleton class. Also experimenting with
plain JSON and instances conforming schema. The full design pattern open
still.
MG: Look at object/thing as interchangeable. Struggling to understand
object/thing level. What's the difference?
MJK: Object can't contain another Object. Thing can contain Things and
Objects. During development many discussion if should be one base class
only or if we should keep both. Simplicity of Objects not containing
Objects was important for mapping ecosystem models.
CB: See sdfObject as historical artefact. Don't need since sdfthing can
do all. Some cases nice to say "this is atomic", no longer
sub-structured. Kept that in. Focus in future in sdfThing makes sense.
MG: how does a thing handle multiple instances of objects. My example is
how a "Thing" (Refrigerator) that has two separate temperature sensors
1) for refrigeration temps 2) freezer temps (Instances) handled
MJK: instance in SDF format singleton for me. We don't have formatting
for that yet.
MG: simple example: calling thing, freezer and refrig sensor. Both
temperature sensors. Are we just verbose on what we call them?
MJK: Fridge product/thing can have two sub-things: freezer and fridge.
And one temperature object in each.
MG: sounds like have examples coming
...
AK: we have also pattern with endpoint identifier and SDF document
together defining an instance. Used in the NIPC API now. But overall
good for us to look at the various patterns for instantiation and see
what makes sense.
2
3. NonAffordance ideas
4. Discussion and way forward
HL presenting.
[...]
AK: seems we have good agreement on having a new top-level structure
that will be hosting the specific data, like location. We'll need to
work on the details how to structure and whether to use sdfData style
definitions.
BB: presented hackathon report. Two parts: Matter/SDF model translation
and NIPC in SDF.
Looked at integrating SDF with SCIM and NIPC. Mapping NIPC properties
and evens to SDF props/events. NIPC has registration API; looked at can
we replace that with SDF model. Another thing: when onboard specifi
instance of device, how to tell what model that device has: how to
integrate SDF model in SCIM object.
For mapping, current NIPC registration API is essentially protocol
mapping. Giving e.g. BLE specific IDs and mapping to property with a
name.
EL: examples are very helpful for NIPC draft. Need more in the draft.
Looked at CoAP over NIPC for BLE devices earlier this week.
BB: In the new version would use SDF file to register properties and
events. Would need protocol mapping information in the SDF file. NIPC GW
don't need to interpret the whole file, just names of props/events and
mapping to the NIPC qualities. Also cases (like healthcare) where
network should be opaque to the app semantics. Application can also
remove/encrypt information in the SDF file to avoid privacy issues.
Example on slide 11 on nipc mapping.
EL: if service/char IDs are supposed to be encrypted, is it encrypted
per device or class?
BB: these are UUIDs not encrypted. UUIDs would be. Would be blind on SDF
property name and metadata.
EL: came up when looking at CoAP over NIPC, GATT read gets sent over
RESTful channel but response over telemetry channel. Really weird
things.
CB: orange coloring shows what could be part of mapping file.
AK: example of mapping info in-lining here; makes sense for the API use
case to have single document. But could also have processing step before
where we pull these together.
BB: Showing (p13) example of manifest format for SDF model information
that could be used in SCIM/MUD. Thought how we can get right SDF model
for a version of firmware.
EL: manifest can be included with anything that could be associated with
affordance
BB: also FW version not only version what to have. Also need to think
about model integrity. But beginning of a manifest format.
BB: in deployment model 2 can simply send the whole SDF file to the GW.
In model 3 with app middleware. Here embedding the SDF model in SCIM/MUD
can be use. Can now support all of the deployment models.
BB: we could also do a lot more in hackathons. Build dummy NIPC GW.
Create a few SDF models and have full end to end.
EL: have most of that code; dummy device
MCR: could use laptop sensors via I2C?
BB: needs a bit more to use than the server in the cloud approach. Also
would be cool to have SDF model generation tool with NIPC qualities.
Could easily generate SDF model for BLE/Zigbee device. Making easy for
apps to import those models.
EL: need to make a call whether to continue to use RESTful interface or
MQTT. CoAP case gives great pause on how we're doing things. Need to
make sure we like the direction.
MCR: 24 ppl in the meetecho, some Zulip users. 12 ppl in the room. Could
close the WG discussion and go to NIPC discussion.
NIPC update (BB)
BB: The draft and API repo moved to ASDF Github. Make issues and PRs!
Open-source still in the old location.
BB: Updated draft to -03, aligning with ASDF principles and
nomenclatures. Changed data interface from protobuf to CBOR-based. But
still a lot to do (slide 4), e.g., updating registration API to use SDF,
API fixes, SDF model manifest.
BB: can we have
CB: answers would be in IANA section of SDF base. Should be able to do
as suggested.
BB: manifest to separate doc?
EL: don't want to create too many docs, but maybe separate doc. But can
be done in the ASDF group.
BB: NIPC still a good name?
EL: don't care :-)
AK: already got questions if only for Non-IP devices. And it can be also
IP devices. And names matter. Easier to fix now and 1-2 years down the
road.
NW: did SDF use go as expected?
BB: Observable property vs Events doesn't necessarily translate well.
Will have to pick one. Hackathon really helps. Remote and interims more
difficult.
EL: can show a picture about the CoAP discussion
NW: could do design meeting today if time left. ASDF interim early next
year?
MCR: will be enough ppl to be productive?
...
NW: will have interim in mid-Jan. Could also have f2f design team
meeting somewhere.
MCR: like FOSDEM side meeting
NW: also need side meeting on DT topic. Selecting one of the structures
and building on that.
MCR: have virtual meeting planning with US, Europe, Asia.
CB: Bangkok is UTC+7. Almost same as Finland :-)
NW: can decide in the next interim about the Bangkok. And design team
meetings for NIPC and DTs so that we know the structure for location
info and what kind of drafts needed.
EL showing coap.png.
EL: CoAP over NIPC over BLE. Wants to have spontaneous registration.
Steps 1-2 normal HTTP/SCIM. Steps 3-6 about knowing device is online.
Some time later step 7, "hello". Device shows up. Carried over MQTT to
the endpoint app. App wants to setup new notification for CoAP
up-stream. Will tunnel messages from device to the app. CoAP messge as
indication in BLE, gets piped up to app in MQTT. Response done now with
NIPC write HTTP. Maybe want to trim this and go to MQTT. Async API
models maybe.
BB: forgot to mention in summary: NIPC data interface not run only over
MQTT but also CoAP or HTTP.
EL: need to define eventing in HTTP then.
BB: no response expected in BLE
EL: step 11, indication is the only method device has available for the
request. Using event mechanism to do a CoAP request.
AK: could use HTTP long-poll or WS instead of MQTT to simplify here?
EL: using MQTT since very efficient. But will need to discuss and share
more details on the list.