Markdown Version | Session Recording

Session Date/Time: 03 Dec 2025 07:00

ASDF

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.