**Session Date/Time:** 28 Jan 2025 16:00

# [ASDF](../wg/asdf.html)

**Date:** January 28, 2025
**Time:** 16:00 - 17:07 UTC
**Attendees:** Nicholas (Chair), Carsten, Bart, Michael, Elliot, Yong-Jae (Hong), Lorenzo, and others.

## Summary

This interim meeting covered significant progress on the Base SDF specification, an update on the nipy draft, and discussions around the Digital Twin Location draft and the broader topic of modeling non-affordance information. Key decisions included setting a date for the next virtual interim.

## Key Discussion Points

*   **Logistics and Administrative:**
    *   The Notewell, IPR, and Code of Conduct pages were presented. Participants were reminded that the meeting was being recorded.
    *   The chair noted a wrong date on the slides, confirming the meeting date as January 28th, 2025.
*   **Working Group Status Update:**
    *   The ASDF WG was chartered in October 2020.
    *   The nipy draft has been adopted.
    *   The Digital Twin Location draft is currently in a call for adoption, with ongoing discussions.
*   **Future Meeting Plans:**
    *   It was decided not to meet in person in Bangkok due to anticipated low key contributor attendance, as discussed previously in Dublin.
    *   A virtual interim was proposed for the **end of February 2025, specifically February 28th**. The time slot would be similar to the current meeting. This proposal will be confirmed on the mailing list.
    *   The intention is to meet in person in Madrid in the summer.
*   **Base SDF Draft Status (Carsten)**:
    *   The first IETF Last Call for the Base SDF draft (d-18) was completed, generating numerous editorial comments.
    *   Draft d-19 has been created to address these comments and is now undergoing its second IETF Last Call.
    *   Following this, a d-20 revision is expected, leading to ISG evaluation, and potentially d-21/d-22 revisions.
    *   Publication as an RFC is optimistically targeted for **summer to early fall 2025**, acknowledging the RFC editor's current processing speed.
    *   Carsten was thanked for his persistence in driving the draft forward.
*   **nipy Update (Bart)**:
    *   The OpenAPI model was updated in December following feedback from the Dublin meeting and hackathon, and subsequently merged into the main branch.
    *   Implementation efforts are ongoing, with a draft 04 branch reflecting model changes discovered during implementation. Text updates for draft 04 are pending.
    *   **New Features:**
        *   nipy operations now leverage SCIM objects (device/group ID) in API paths, facilitating larger networks and proxying requests to appropriate nipy servers.
        *   Moved from multiple individual affordance registration APIs to a single API for registering a complete SDF model, encompassing all affordances.
        *   nipy operations require both a SCIM instance and an SDF interaction model.
        *   SDF affordances (properties, actions, events) leverage protocol mappings (e.g., for BLE service and characteristic IDs).
        *   A PubSub interface supports streaming events (device broadcasts, connection state) using CBOR over MQTT or HTTP.
        *   SDF Model Registration: POST/GET APIs allow registering SDF models for device or group IDs. Multiple models can be registered. The top-level of an SDF model must be an SDF Thing or Object, and protocol mappings are required within it.
        *   Application Registration: Allows nipy applications to register other authorized applications to receive specific events.
        *   Protocol Mappings: Designed for extensibility via IANA registration. Currently defined for standard properties, events, broadcasts, service discovery (for BLE), and protocol-specific error codes. Can be embedded in SDF models or used directly in nipy APIs.
        *   nipy APIs: Standard APIs for GET/UPDATE Properties, ENABLE/DISABLE/GET Events, and PUT Actions. Connection management is implied unless explicitly controlled.
        *   Additional APIs: Explicit connection management (implemented as actions for efficiency in sequential operations), Broadcast API, and RPC-style property read/write (for legacy use without SDF model registration).
        *   Extensions: Support compound APIs combining multiple nipy operations into a single call, extensible via IANA registration or vendor-specific. Examples include Bulk API, File Transfer, and Firmware Upgrade.
    *   **Discussion on Role-Based Access Control (RBAC)**:
        *   Michael inquired about the need for RBAC and whether it's an SDF extension or nipy-specific.
        *   Bart confirmed the need for RBAC, identifying top-level roles (onboarding, nipy APIs, data reception) and suggesting finer-grained control for specific affordances (e.g., firmware upgrade vs. light control).
        *   Elliot proposed that SDF affordances should describe their "sensitivity" or categorization.
        *   Carsten clarified that authorization logic is typically business-specific, but SDF can provide categorizations (e.g., "installer only," "fire department access") within the model to facilitate simpler RBAC implementation, allowing roles to map to groups of affordances.
    *   **SDF Model Structure**: The model has been broken into multiple files (OpenAPI definition, protocol mappings, extensions, CDDL for data subscriptions). Examples for real devices have been created. The next step is for application partners to create SDF models for their devices, with potential use of web-based tools.
*   **Extended SDF for Digital Twin (Non-Affordance Information) Draft (Yong)**:
    *   Version 5 updates were presented, focusing on SDF structure for Digital Twins and incorporating Ari's suggestions for merging SDF documents and info blocks.
    *   **Status Change**: The draft track was updated from Standard to Informational based on Ari's suggestion. This sparked a discussion.
    *   **Clarification on Track Change**: Nicholas clarified that Ari's suggestion, discussed in Dublin, was to split the document: a normative (standard track) document for the *extension mechanism* and an *informative* (informational track) document demonstrating *how to use it* (e.g., for digital twins and non-affordance information). Michael expressed a preference for keeping all related work on the standards track, but recognized the split might be pragmatic. Yong-Jae (Hong) confirmed his willingness to contribute to the normative document.
    *   **Content Updates**: SDF structure for location was added in Clause 5.1, and location examples were clarified in Clauses 5.2-5.4.
    *   **Future Work**: The document will be further developed and potentially split into new documents as suggested, requiring clearer definitions and scope for "non-affordance information."
*   **Modeling Non-Affordance Information (Carsten)**:
    *   Carsten provided a conceptual overview, revisiting core design principles for SDF.
    *   He differentiated between semantic, structural, and syntactic interoperability, noting SDF's focus on semantic.
    *   The architecture includes information, data, and serialization models. SDF primarily concerns the information model.
    *   SDF aims to provide a central format for translating *interaction models* (class-level descriptions of how to interact with a device).
    *   He distinguished between translating data models (model-in-model-out) and translating actual data messages.
    *   **Instance Information**: A key focus is information specific to individual device *instances* (e.g., identity, address, physical installation, purchase order number, last calibration date). This instance-specific data differs from the class-level interaction model.
    *   While SDF Base models interactions at a *class level*, nipy crosses into modeling *interaction messages*, which require ecosystem-specific details (e.g., CBOR for Bluetooth).
    *   Not all instance information is obtained via device affordances (e.g., purchase order or calibration date might reside in an asset management system or digital twin). We need to model how to represent such data, even if it's not directly retrieved from the device via an affordance.
    *   This "non-affordance information" requires consideration in the modeling of device instantiation and its representation within a broader system.
    *   Carsten encouraged participants to attend the Thing-to-Thing Research Group (T2T-RG) meeting on Thursday, January 30th, 2025, for further discussion on these topics.

## Decisions and Action Items

*   **Decision:** The next virtual interim meeting is tentatively scheduled for **Tuesday, February 28th, 2025**, at the same time slot (16:00 UTC).
    *   **Action Item:** Nicholas and Michael to propose and confirm the exact date and time for the next virtual interim on the ASDF mailing list.
*   **Action Item:** The working group will continue discussions on the mailing list regarding the Digital Twin location draft and the approach to splitting it into normative and informative documents.
*   **Action Item:** Bart to continue developing the nipy draft text, aiming for availability in a few weeks.
*   **Action Item:** Carsten to continue pushing the Base SDF draft through its second IETF Last Call and subsequent ISG evaluation.

## Next Steps

*   Monitor the mailing list for confirmation of the next virtual interim date and details.
*   Engage in the discussion on the mailing list regarding the Digital Twin location draft and the structure of normative/informative documents for non-affordance information.
*   Participants are encouraged to attend the Thing-to-Thing Research Group (T2T-RG) meeting on Thursday, January 30th, 2025, for further discussions on modeling and non-affordance information.