**Session Date/Time:** 03 Dec 2025 07:00 # [ASDF](../wg/asdf.html) ## Summary The 11th ASDF interim meeting focused on updates to three key drafts: "Instance Information", "SDF Protocol Mapping", and "NIPC". Significant progress was reported on the NIPC draft, with many issues closed. Discussions around the "Instance Information" draft led to a consensus for an adoption call. The "SDF Protocol Mapping" draft will see IP-based protocol mappings moved to a separate document to facilitate its progression. Meeting scheduling for upcoming interims was also addressed, with the January interim rescheduled and the February interim tentatively set. ## Key Discussion Points ### Instance Information Draft (draft-ietf-asdf-sdf-instance-information-07) * **Presenter:** Jan * **Key Changes:** * Incorporated discussions from IETF 124 and conceptual convergence with the non-affordance draft. * Formalized a unified message format with CDDL definitions, covering previous six message types. * Proposed four message archetypes: `status report`, `status report update`, `construction message`, and `state patch`. These are distinguished by content (freestanding vs. relative) and intended effect (state exposure vs. state change). * Media types will be defined for these archetypes (e.g., `application/sdf-status-report+json`). * Old descriptive terms like "proof shots" and "identity manifests" are now considered use-case examples covered by the `status report` archetype, rather than distinct formal message types. * The draft emphasizes a clear separation of model and instance information and suggests instance-related messages are built into SDF, not the interaction model (with `construction message` being a potential exception aligning with action affordances). * **Open Questions:** * The exact structure for `construction message` vs. `status report` still requires clarification, especially regarding the interpretation of concrete values and information needed for setting up a thing instance. * The placement and special handling of `timestamp` and `thing ID` in the info block is under debate. * The relationship between SDF protocol maps and constant context information (initial proposal uses JSON portals). * The modeling of the state of actions and events (e.g., event history for events, actions are trickier). * **Discussion:** * Younga questioned whether an `identity manifest` could also be considered a `construction message` if used for device setup. Jan confirmed this was a good point. * Yun Yong questioned the necessity of a `message ID` if `timestamp` and `device ID` are available, particularly if messages are expected to be in order. Jan explained `message ID` allows explicit linking between messages and helps with out-of-order scenarios, but acknowledged it's an area for further consideration. * **Implementation Status:** Jan is developing a Proof of Concept (POC) and will provide updates on experiences and refinement needs. ### SDF Protocol Mapping Draft (draft-ietf-asdf-sdf-protocol-mapping-02) * **Presenter:** Rohit * **Key Changes:** Moved OpenAPI definitions for protocol mappings from the NIPC draft to this draft. * **Open Issues & Discussion:** * **Inclusion of IP-based Protocol Mappings (HTTP/OpenAPI, CoAP):** Karsten and Eliot had previously objected to their inclusion due to a lack of running code/POCs. * **Consensus:** The working group agreed to remove these IP-based protocol mappings from the current draft. * **Action:** A separate document will be created to house these mappings (e.g., CoAP), allowing the core SDF Protocol Mapping draft to proceed with already-implemented mappings (BLE, Zigbee). Jan offered to contribute to a CoAP-based protocol mapping document. * **NIPC APIs and `sdf-protocol-map` key:** Currently, NIPC APIs reuse the `sdf-protocol-map` key for returning protocol-specific information (e.g., BLE-GATT database in connection requests). This is problematic as the key is intended for mapping SDF affordances in an SDF document, not for arbitrary protocol information in an external API. * **Proposed Solution (preliminary):** Bart suggested a new keyword (e.g., `SDF protocol information`) to distinguish this use case from an actual SDF affordance mapping. This issue will be discussed further during the NIPC section of future meetings. ### NIPC Draft (draft-ietf-asdf-nipsc-02) * **Presenter:** Bart * **Progress on Draft 15:** * Closed 24 issues from Draft 14 and 12 additional issues. Only 7 issues remain open (4 in progress, 3 to start). * Added new Security Consideration and Implementation Status sections. * The text was thoroughly reviewed, edited, and enhanced for readability, aligning with IETF key terms (`MUST`, `SHOULD`, etc.). * **Completed Issues Highlights:** * Addressed Jetty servlet implementation issue by using query parameters for path-based percent encoding. * Included text explaining `content-format-quality`. * Renamed the draft from "non-IP" to "Non-Internet Connected Physical Component". * Addressed Ari's comments on limited power budgets. * Improved UUID uniqueness. * Fixed issues in `get registration models` return value. * Moved protocol mapping OpenAPI definitions to the SDF Protocol Mapping draft appendix, now referenced. * **Open/In-Progress Issues:** * **Bridging Function (Michael's suggestion):** Exploring functionality for a NIPC-connected device to invoke an action on another device. Bart intends to fully specify this, potentially implementing it in a Zigbee prototype. * **IANA Considerations:** Section is largely complete, but requires discussion with HTTP API and problem type RFC authors. * **CDDL and API Definitions:** Mostly complete, pending resolution of the connection management section. * **Connection Management Section (4.4):** This section is still open, pending resolution of the issue regarding distinguishing generic protocol information from `sdf-protocol-map`. * **Summary of Remaining Major Items:** The two major remaining items are the handling of protocol information that is not an SDF protocol map (linked to connection management) and the bridging function. ## Decisions and Action Items * **Instance Information Draft:** A poll of the room indicated no objections to starting an adoption call. An adoption call will be initiated in the coming weeks. * **SDF Protocol Mapping Draft:** * **Decision:** IP-based protocol mappings (HTTP/OpenAPI, CoAP) will be removed from the current draft. * **Action:** A separate document will be created to develop and prototype these IP-based mappings. * **NIPC Draft:** * **Action:** Authors to address the issue of distinguishing protocol-specific information in NIPC APIs from SDF affordance mappings (e.g., propose a new keyword). * **Action:** Authors to make a proposal for the bridging/linking functionality. * **Action:** Authors to perform a final author review and aim to have the draft ready for working group review by Christmas. * **SDF Document:** * **Action:** Authors to work on answering the remaining RFC editor questions (estimated at six questions per original question). * **Meeting Schedule:** * **Decision:** The January interim meeting originally scheduled for January 7th is cancelled due to author unavailability. * **Decision:** The January interim meeting is rescheduled to **January 21st**. * **Decision:** The February interim meeting is tentatively scheduled for **February 4th**. Any conflicts or need for rescheduling will be discussed at the January 21st meeting. * **Decision:** The working group is not planning a physical meeting at IETF 125 in Shenzhen due to anticipated low attendance from the group. ## Next Steps * Initiate a working group adoption call for the "Instance Information" draft. * Progress the "SDF Protocol Mapping" draft by removing IP-based mappings and opening a new document for their development. * Finalize the "NIPC" draft text, resolve remaining open issues, and prepare it for working group review, with a target for completion by the end of the year. * Authors of the core "SDF" document to address remaining RFC editor comments. * Hold the next interim meetings on January 21st and (tentatively) February 4th.