ASDF

Summary

The ASDF session covered updates and key discussion points for two main drafts: the SDF Protocol Mapping and Nipsy. For the SDF Protocol Mapping, discussions revolved around managing instance-level information (like IP or MAC addresses) in conjunction with class-level protocol maps and streamlining the draft's scope to fast-track its completion. For Nipsy, significant updates included API changes, clarification on terminology ("onboarding," "registrations"), and a decision to broaden its scope beyond strictly "non-IP" devices, requiring a name change. Cross-technology bindings were also discussed as a potential future feature.

Key Discussion Points

SDF Protocol Mapping

Draft Status: The SDF Protocol Mapping draft has been adopted and a 01 version published. Changes included updated CDDL definitions, an added scheme extension for SDS, and a new IANA registration for the sdf URI scheme.
Instance vs. Class Level Information: A core discussion focused on how to represent and link instance-specific information (e.g., an IP address for CoAP, a MAC address for BLE) with class-level protocol maps. Karsten presented examples showing how an IP address could be defined as an SDF type at the class level but only be available as instance information, to be referenced by the protocol map.
- The challenge is how this context (instance info) finds its way to the protocol map entry.
- The concept of SDF-type-link (also known as "Core Dynlink" from the CoRE working group) was mentioned as a related mechanism for defining links with semantics.
Draft Scope and Fast-tracking: A proposal was made to simplify the SDF Protocol Map draft by focusing solely on defining the registry and including only essential initial registrations (specifically BLE and Zigbee) that Nipsy depends on. Other protocol mappings (e.g., Open API) would be removed or handled in separate drafts/examples to expedite the SDF Protocol Map document's completion.
SDF Scheme Extension Placement: Discussion around whether the CDDL definition for the SDF scheme extension should be in an informative appendix or a normative part of the document, especially if it's meant to be referenced by other specifications. The current suggestion from an editor was for informative, but a counter-argument was made for normative placement.

Nipsy Updates

Draft 14 Release: Draft 14 was released, addressing 24 fixed items. 9 items were slated for discussion in this session, and 5 remain work in progress.
API Update: Group Events: An API update was made to the groupID events API to include deviceID in each element of the return array. This ensures per-device status is available when querying events for a group.
"Onboarding" Terminology: The use of "onboarding" terminology in Nipsy was discussed. The decision was to retain it due to its consistent use in SCIM and other related drafts, with the understanding that the Nipsy document will clearly define its meaning and reference the SCIM definition.
"Registration" Terminology: The "registrations" collection, used for SDF model and data app registrations, was reviewed. It was decided to keep this collection as it logically groups various registrations required for gateway operations.
Example GUIDs: A request was made to use more distinct GUIDs in examples to improve readability and avoid confusion.
Cross-Technology Bindings: Michael brought up the interesting concept of Nipsy enabling cross-technology bindings (e.g., a BLE actuator turning on a Zigbee light). This was seen as a valuable idea for future investigation, possibly leveraging mechanisms like SDF-type-link/Core Dynlink. It was acknowledged that this might be an instance-level binding, not directly part of the class-level SDF model.
Nipsy Naming ("Non-IP Control"): A significant discussion centered on the current name "Non-IP Control" and whether Nipsy should be restricted to non-IP devices. There was strong consensus that Nipsy should be applicable to both non-IP and IP-based devices (e.g., in mixed environments, for devices transitioning to IP, or where IP connectivity is tunneled).
Implementations Section: The purpose of the implementations section (for ISG review, not normative) was clarified.
CDDL vs. OpenAPI Definitions: The redundancy of having both CDDL (data model) and OpenAPI (API + data model) definitions was discussed. The importance of having extension points for various data definition languages was highlighted.
Limited Power Budget: Briefly mentioned, to be followed up offline.

Decisions and Action Items

SDF Protocol Map Scope:
- Decision: Simplify the SDF Protocol Map draft to define the registry and include BLE and Zigbee as normative initial registrations.
- Action: Remove other protocol mappings (e.g., Open API) or relegate them to non-normative examples to fast-track draft completion.
SDF Scheme Extension:
- Action: Rohit to follow up on the discussion regarding making the SDF scheme extension's CDDL definition normative, potentially moving it from the appendix to the core document.
Nipsy API Update:
- Decision: The addition of deviceID to the groupID events API return value is accepted.
Nipsy Terminology - "Onboarding":
- Decision: Keep "onboarding" terminology, ensuring the document provides a clear definition and references SCIM.
Nipsy Terminology - "Registrations":
- Decision: Keep the "registrations" collection as is.
Nipsy Examples:
- Action: Update examples to use more distinct GUIDs (Michael).
Nipsy Naming:
- Decision: Change the name of Nipsy (using a retronym) to reflect its broader applicability to both non-IP and IP-based devices.
- Action: The working group to determine a suitable retronym.
Cross-Technology Bindings:
- Action: Investigate cross-technology bindings further, potentially leveraging SDF-type-link/Core Dynlink. This is likely not for the current revision of the Nipsy draft.

Next Steps

Nipsy Draft:
- Address all comments and outcomes from the discussions.
- Finish remaining work-in-progress items.
- Thoroughly proofread the entire document.
- Conduct another round of working group reviews.
- An interim meeting may be scheduled to follow up on progress.
SDF Protocol Map Draft:
- Continue work on the streamlined draft, incorporating decisions on scope and scheme extension placement.

Session Date/Time: 05 Nov 2025 17:00

ASDF Session Meeting Minutes

Summary

The ASDF working group discussed ongoing progress on the SDF Context draft, focusing on distinguishing between instance properties and context information. Discussions also covered the SDF Modeling for Digital Twin draft and proposed changes to the SDF Protocol Mapping for HTTP, particularly regarding the use of Open API. The group made decisions on scheduling future virtual interims and identified key action items for progressing the drafts towards Working Group Last Call.

Key Discussion Points

1. SDF Extension for Non-Affordance Information (SDF Context)

Draft Status and Evolution: The draft, initially "SDF Extension for Non-Aff Information," has been adopted as a working group document and renamed "SDF Context." Revisions include adding use cases and clarifying the class name.
"Design Team" Progress: An informal "design team" has been collaborating to harmonize concepts between the "non-affordance" and "instance" drafts.
SDF Context Definition:
- Represents non-affordance, descriptive information about an object.
- It is a peer to state, property, action, and event.
- Definitions under SDF context are read-only.
- Examples include location, manufacturer details, calibration parameters, installation attributes, and serial identifiers.
Distinction between Property and Context:
- SDF context: descriptive, read-only information (e.g., serial number, installation location).
- SDF property: dynamic, real sensing values (e.g., live temperature readings).
Litmus Tests: Work is underway to develop "litmus tests" and guidance to help determine when to use SDF context versus SDF property. These will be added as an appendix to the draft.
Message Type Harmonization: Discussions are ongoing to define common message formats and distinctions for:
- Context snapshot (descriptive identity) vs. Proof shot (dynamic sensing values).
- Context patch (partial update of non-affordance metadata) vs. Delta (partial update of operational state).
- Identity manifest (immutable identity) vs. Construction messages (initial device parameters).
Security Considerations for Instance Information:
- The need to expose instance-specific security identity for protocols like TLS/DTLS was discussed, challenging the view that such information is solely internal to the security protocol.
- The group explored how to represent security parameters (e.g., cipher suites, preferences) without interfering with or invalidating security protocol handshakes.
- The need to avoid repetition of sdf security map per property was highlighted, suggesting a shared structure like SDF context.
Modeling Philosophy: Discussion centered on what information is truly essential for consumers versus implementers, and how to effectively separate class-level from instance-level information to reduce redundancy and manage updates (e.g., IP addresses). The historical use of const quality for unchanging values in the data model was deemed confusing for instance information.

2. SDF Modeling for Digital Twin

Draft Status: The "SDF Modeling for Digital Twin version 2" draft has been adopted as a working group document.
Key Changes: Added SDF protocol map and tables, a new healthcare system example, and restructured chapters for clarity.
Marine System Example: Demonstrated modeling components (heater, battery, thermostat) as SDF objects and their relationships using SDF relations.
Healthcare System Example: Illustrated modeling contextual information (patient ID) with SDF context and alarms with SDF event or SDF relation.
SDO Adaptability: SDF-based digital twin modeling is being adapted for other SDOs like ITU and ITB documents.

3. SDF Protocol Mapping (HTTP/OpenAPI)

Proposal for HTTP Mapping: A proposal was made to change the "Open API" SDF protocol mapping to "HTTP" and include a type field (e.g., type: "OpenAPI") to specify the mapping type.
Discussion on Normative Status: The intent was to make this mapping normative.
Trade-offs and Concerns:
- Participants raised concerns about the trade-offs of this approach and whether OpenAPI itself might be considered a protocol map rather than just a description of HTTP access.
- The potential complexity of interpreting method statements within OpenAPI if this route is taken was noted.
- A sense of those present indicates the need for further discussion on this point.
Open Issues: The group decided an issue should be opened to further discuss this change.

4. General Draft Progress

Remaining Work for SDF Protocol Mapping:
- Document percent-based encoding using query parameters.
- Seek feedback on Nipsey problem types.
- Add an example leveraging content format in the SDF model.
- Clarify application and connection management details.
- Finalize CDDL for all API schemas (CDDL in text, OpenAPI in appendix).
Document Review: A thorough proofreading of the entire document is needed due to numerous changes, followed by another round of detailed reviews before Working Group Last Call.

Decisions and Action Items

Decisions:

Two virtual interims will be scheduled:
- The first Wednesday in December at 9 a.m. Eastern European Time (7 a.m. UTC).
- A second virtual interim during the second week of January (the first week is typically avoided due to holidays).

Action Items:

Chairs: Post details for the upcoming virtual interims via email and Datatracker.
Zhang (Etri): Continue work on "litmus tests" and common message formats for SDF Context, planning to add guidance and CDDL to the appendix.
Working Group Participants:
- Volunteer to review the "SDF Extension for Non-Affordance Information" (SDF Context) draft.
- Provide feedback on the proposed HTTP/OpenAPI protocol mapping (an issue will be opened for this).
- Conduct a thorough proofread and review of the SDF Protocol Mapping and SDF Context drafts for overall flow and consistency.
Hjongli (Etri): Continue to add more examples (smart buildings, factories) and consider SDF instance in examples for the "SDF Modeling for Digital Twin" draft.
Bart/Rohit: Open an issue in the Datatracker for the discussion around the HTTP/OpenAPI protocol mapping.
Chairs: Aim to bring some documents to Working Group Last Call before the next plenary meeting.

Next Steps

Virtual Interims: Participants are encouraged to attend the scheduled virtual interims to continue technical discussions and progress on drafts.
Document Reviews: Engage in active review of the "SDF Context," "SDF Modeling for Digital Twin," and "SDF Protocol Mapping" drafts, focusing on technical content and consistency.
Issue Resolution: Address open issues, particularly the HTTP/OpenAPI protocol mapping, with further discussion and feedback.
Integration Clarity: Improve the clarity of integration points between the Digital Twin draft and other SDF core concepts.
IETF IoT Ops Plug: Daniel Swollen encouraged ASDF participants to attend his presentation on "privacy preference declarations" at the IoT Ops session, highlighting its relevance to data flow properties, taxonomies, and policy definitions for IoT devices, which might relate to non-affordance information.