ASDF virtual intermin meeting
2025-01-28 17:00 CET
Meetecho:
https://meetings.conf.meetecho.com/interim/?group=0ab09219-9777-4897-ba2a-f0ce403d08a6
Agenda and notes:
https://notes.ietf.org/notes-ietf-interim-2025-asdf-01-asdf
meeting is 16:00 to 17:15 (UTC)
Present:
Draft agenda:
(Noting slides have interim-02/2025-02-28, which is wrong)
Logistics for Meeting
WG status update and planning (Chairs)
Proposed next date for virtual interim meeting: Tuesday 2025-02-25, same
time?
Carsten presented status. RFC editor processing slow these days. Around
summer could have RFC published.
Bart presenting.
OpenAPI model updated. Commments on the PR and now in pushed to main.
Implemented the changes in draft-04 branch. Few changes in API based on
implementation experience. Few more updates needed before new draft
published. Model seems OK.
New here that SCIM object IDs in the path. Useful when seeing large
networks with multiple NIPC servers; can proxy to proper NIPC server
serving a device.
Moved from registering events and properties to registering SDF models
with those affordances.
Now need just instance ID from SCIM and SDF model to do operations. Also
groups supported.
Protocol mappings for for device type (e.g. BLE) details.
Using CBOR based telemetry over MQTT or HTTP.
New SDF model registration API. Models registered for a group (could be
empty). Protocol maps used to map definitions to BLE etc.
Also data application registration API.
Sometimes want to do connection management explicitly; embedded protocol
mapping (slide 9) for this. Can be used without registered SDF model.
Broadcast API allows network to broadcast messages.
Also RPC style property read/write option, for legacy reasons. Can be
leveraged but not in principle required.
IANA registry for NIPC extension. Bulk API already using this.
MCR: need for role based access control (RBAC)? SDF extension or NIPC
specific thing?
BB: definitely need for rule based access control. 3 top-level roles;
who is allowed to onboard, execute operations, receive data. But even
inside NIPCs APIs one app could allow firmware updates another read
data?
MCR: e.g. allowed to query states of light but not change them? Anyone
could do former but not the latter.
BB: have auth based on onboarding now
MCR: affordances in SDF should describe "sensitivity". Difference in FW
update and increasing temperature by 1 degree.
BB: if believe that is per device type attribute, would be in SDF, if
per device instance, would be in SCIM. Perhaps belongs in SDF.
EL: question really is -- one thing to describe authorization -- RBAC
related or something else -- but needs to be externalized of
internalized. SDF description would externalize.
MCR: each kind of affordance needs to describe sensitivity, for lack of
better word. Outside in SCIM space to decide which category/client falls
into. Don't expect SDF to describer admins and users, but could do "this
is more sensitive than that"
CB: question "who may do what" is business logic question. Generally we
try to minimize constrained devices executing biz logic. Not entirely
sure SDF model should desc the actual authorization, but could provide
some grouping and categorizing. Number of requests that are widely
available and number that require other level of authorization. Could
say "this group/role can read temperature but can't change it".
BB: would map attribute like "firemen authorization". Not who but input
on the type.
CB: depends on what you want to be able to do with the auth model. If
"anything" becomes complicated. SDF model might be able to -- so you can
write a simple model. "This role can do all affordances reserved for
fire dep in the SDF model".
NW: safety labels for affordances was discussed already before ASDF
group started. Another way to communicate sensitivity of API
BB continuing (slide 11)
Went from single model/file to multiple. One with core NIPC operations.
Protocol mappings where can do IANA registered mappings. Two extensions,
one for vendor specific. Also CDDL for data subscriptions. Created a few
examples that tested with; also in the NIPC SDF example directory. Few
SDF models of real devices that we tested APIs with. In the process of
implementation -- have used individual affordance regs, not SDF models.
now with our own examples will have our app partners creating SDF
models. Will see how goes. Ari pointed a web-based tool; will see if
have them using it. If OK with it could add these to the example area.
From model perspective in good shape, will continue to work on the draft
text now. Should be available in a few weeks.
AK: wondering about the "legacy API" with more detailed connection
control. Are they independaet? Or can be used together with the
SDF-based API?
BB: If one does explicit connection management, then do GET, then that
still uses an sdf reference to the affordance. Can use together too.
CB: more things than open/close connection. Especially managing
connections. Could be e.g. timer based connection. Need to think a bit
what we want to specify here.
BB: looking forward to ideas here!
Hyunjeong presenting. Change in the draft using the merged doc examples.
Need to consider what is "non affordance information" for the new draft.
Suggesting to change the track of the draft from standard to
informational per Dublin discussion.
Will develop this document (splitting to normative and informational) as
suggested by Ari in Dublin.
MCR: changing status WG decision; not sure if understand why
AK: suggested to split "how to use non affordance info for digital
twins" into informational and a new standards track draft with the
extension mechanism
CB: talking about non-affordance stuff. 8 slides!
...
Difference between translating data models (what SDF does) and
translating the data exchanged (latter demonstrated recently for LwM2M
to Matter in T2TRG).
Instance information, something different for each intance of the model.
Identity of a device for example. But also could be address of device.
Also things like purpose in life, physical aspects (how installed;
device may have no idea of this).
SDF base models interaction model in class level. Applies to all devices
of that model. Data read from a device would be unique to device but the
model is common.
With NIPC crossing the boundary to modeling interaction messages; use
the interaction model to derive information model level view of what the
actual message will be. Need to look at what exactly need to do for BLE
message to understand certain BLE device. Some aspects implied by the
interaction model, describes high level message (input/output data), but
need ecosystem specific info. One aspect; the other: not everything fits
into interaction model.
Some data that you want to attach to an idea of device (e.g., IP
address). Some can get from affordance, like network affordance could
give IP address -- but just class of information. ... Is device on asset
management system or when last calibrated. Information that is available
for different kind of system, e.g., system linked to a device. Need to
model that.
And also need to model process of instantiation. Want to be able to say
"you need this info to instantiate".
Also instance info message model, e.g., date of purchase. Can't model at
class level; class doesn't have actual device specific location.
Information needs to live somewhere else.
Thing-to-Thing RG meeting on Thursday will have more discussion on this
and the relationship between different models.
NW: thanks for reminding of the design ideas of SDF and the Thursday
meeting
MCR: next virtual interim Tuesday 25th?
If have friends who want to become RFC authors, bring them here :-)
LC: clear on my side; will try to join Thursday T2TRG. Looking forward
to it. Will be reviewing the NIPC meanwhile.