ASDF interim -11

date: 2025-12-05, 07:00 UTC.

Agenda bash

Lorenzo Corneo (LC): Instance information, NIPC and protocol mappings on
agenda.

New note well on chair slide 4.

Instance information

Jan Romann (JR) presenting

Covers two most recent revisions. Incorporating discussions since IETF
124 with ETRI and OneDM (slides 3-> )

Still open questions on constructor messages; may not use exact same
structure for constructor and report (s6).

MCR: slide 8 suggests you are obsoleting old types with archetypes?
JR: that's the intention, but will use old types as examples for the use
cases.
Carsten Bormann (CB): difference in what we need to define formally for
interop and something descriptive, e.g., "why was this message
generated". Difference between proofshot/context snapshot/identity
manifest, but same structure (arhectype). Different reasons to use the
archetype. Terms not going away but not formal terms that need to be
defined and understood in technical way.

JR: Have now clear separation of model and instance information in
messages. Still number of open questions: relationship with
sdfProtocolMap, debate with sdfContext and sdfProperty -- think the
context keyword is useful, need to think how to model state of actions
and events (maybe event history but actions tricker and needs more
discussion).

Ari Keränen (AK): Great to see this getting mature and stable. Have you
applied this to running code and use cases?
JR: have started experimenting, next steps to get more experience and
will inform when something to try out

Jungha Hong (JH): slide 8, identity manifest here belongs to status
report -- needs to go to construction message as well.
JR: would consider identity for setting up device
JH: yes. On slide 6, what is the different media type here
JR: something like application/sdf-status-report+json. Something that
identifies the message archetype. Arhetypes would have
application/sdf-<type>+json style media types.

Hyunjeong Lee (HL): purpose of message ID? message type and device ID
enough?
JR: to be able to refer to previous message; enables to link two
messages together. Could maybe also use thing ID but ideally having
unique ID for message can't hurt. Makes easier to establish link between
two messages.
MCR: think that messages can be out of order? More than one so need
partial ordering?
JR: could be the case; something to discuss if needed. Or some other
way(s) for ordering could be used. Good point. Still open question if
want to move time stamp and ID to info block so not just regular context
information but info of special kind used to identify and match the
message. Something to think about.
HL: message ID in messages will be better (?)

MCR: doc ready for adoption?
AK: haven't read the latest version but seems mature and right direction
based on all presented and discussed
LC: no objections? Can proceed here.
MCR issued Call for Adoption with 2025-12-19 as object-by date (DT says
2025-12-16)

SDF protocol mapping

Rohit Mohan (RM) presenting.

New -02 published today. Changes small. Couple of open issues: inclusion
of IP based protocol mappings (HTTP, OpenAPI, CoAP). Some objections to
it. Spoke with Eliot and recommended to take out of draft since we don't
fully know yet what we cover and don't have running code yet. Can
someone make a PoC here?

CB: think would be good to have that, but not sure we have to wait until
examples are of quality we can WGLC them. Could open another doc that
has those parts and process that in staggered timeframe.

LC: +1 to CB. This doc should go before NIPC if we wait for perfect
examples everything gets delayed. Even for CoAP we should hold back and
come back with new draft that is linked to the registry.

RM: can remove the OpenAPI version to new draft.
LC: can link that and then up to what ever piece of SW parsing OpenAPI,
gives comprehensive description, but still up to the parser what to do
with it. Something to take into further dev

JR: agree with LC, can try to contribute to the CoAP based mapping.

AK: agree, and good to have a hint towards how to do IP-based in the new
draft referenced from the upcoming RFC.

CB (in chat): Right. Slim this one down so we doAgenda bash: setting up
for n't run into IESG blockers. We can start the next draft now!

RM: sdfProtocolMap used in SDF doc not outside API now. Should add
something for the API?
Bart Brinckman (BB): in NIPC draft areas where we return protocol
specific information, like BLE GATT database. Thinking we need another
keyword in the API for that, and different way to include that in the
NIPC API. Sec 4.4 of NIPC spec. Maybe use different key word that allows
to return protocol specific information. Haven't really gone into depth
on the. Issue AK raised earlier.

CB (in chat): sdfProtocolInformation +1

MCR (chat): Do we need GATT clue here? Christian A has that...

CB (chat): We definitely should keep some synchronization between the
CoRE GATT work and this

NIPC

BB presenting.

Released -15 yesterday. 12 issues closed in -15. 7 issues remaining.
Lots of reviews, edits, and enhancements for readability. Only section
not ready is the connection management. Related to issue discussed
above. See details of completed issues on slide 5.

Added section to explain why went with query parameters with % encoding
issue. Draft not named "non-IP" anymore but "Non-Internet Connected
Physical Components". All refs to "non-IP" changed. Good progress. Doc
in much better shape now.

BB: Application gateway function is work in progress.
MCR: something for another doc?
BB: think can put something together in coming weeks. Will propose
something by next interim and if good can leave in
CB: specifies bridging function or points that the protocol is such that
it's possible to build one?
BB: would like to have one specified. ZigBee has binding functionality
similar to that. Would like to implement this in ZigBee prototype to
test this out. Work in progress but hope can include this.

Need to talk with problem type RFC folks on our approach using that.
CDDL in APIs completed except for the connection management where might
need some CDDL or to protocol mapping. Only big item is the GW function
and what to do with protocol map information.

Goal to resolve remaining issues and have a draft ready for Christmas.
Next year can get good WG reviews and docs through the process. Have 3
normative refs for drafts: SCIM device schema, SDF base, and SDF
protocol map.
CB: where problem? The normative refs don't need to be RFCs before this
is published

MCR: can result in weird linkage between normative and informative docs,
but don't need to worry about that.

LC: great progress.

Next meetings

2026-01-07 does not work for many.
2026-02-04 is tentative date for Feb meeting

2026-01-07 meeting will be moved to Jan 21.
Feb meeting move 3 weeks forward?

Will not meet at IETF125.

MCR: SDF base status?
CB: stuck answering 7 remaining RFC editor questions, which are 6
questions each. Everyone needs to do full re-read to answer those
questions. With authors now. MJK said he is doing full re-read right
now. Making progress.