**Session Date/Time:** 04 Sep 2024 15:30

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

## Summary

The ASDF working group held its third interim meeting of the year. Key topics included the status of the ASDF core specification, a discussion and decision regarding an in-person meeting at IETF 121 in Dublin, an update and discussion on the Digital Twin draft (specifically regarding location information), and significant progress on the Nipy draft, including API alignment with SDF, a decision on the data format for telemetry, and an exploration of deployment models.

## Key Discussion Points

*   **ASDF Core Specification Update**: The ASDF core specification (`draft-ietf-asdf-sdf`) is nearing completion, with only minor fixes remaining. Carson is working on wrapping up the final document.
*   **IETF 121 Dublin Meeting**:
    *   The chairs raised the question of meeting in person at IETF 121 in Dublin.
    *   There was a sense among those present that an in-person meeting would be beneficial, especially to foster progress on Nipy/SDF integration and potentially enable a hackathon or side meeting for more in-depth design discussions.
    *   A poll of the room indicated interest in requesting a meeting.
*   **Digital Twin Draft (Location Information)**:
    *   The author presented version 3 of the draft, focusing on requirements for Digital Twin with reference to ISO 23247 part 1.
    *   The draft describes location using conventional GPS coordinates or postal addresses, and introduces concepts for relative indoor locations (e.g., "heaters in the boat" inheriting the boat's location and having a relative indoor address).
    *   **Discussion Points**:
        *   Ari emphasized the importance of location information and suggested validating the current design against existing standards (e.g., W3C geolocation) and reuse cases to ensure robustness and completeness.
        *   Ari proposed integrating location as part of a larger "non-affordance information" concept, rather than a top-level entity. Non-affordance information would cover data that does not directly come from a device's affordances but from external sources.
        *   Michael sought clarification on the concept of relative vs. absolute location and the proposed representation of relative addresses.
        *   A suggestion was made to rename the draft to something more specific to "location-based" rather than "digital twin" to better reflect its current scope.
    *   **Adoption Call**: It was determined that the draft is not yet ready for a working group adoption call. Further design work is needed, particularly on the higher-level "non-affordance information" framework.
*   **Nipy Draft Update**:
    *   The Nipy draft has been adopted as `draft-asdf-nipy-01`.
    *   **API Alignment**: The Nipy API structure and nomenclature have been reworked to align with the SDF specification, categorizing operations under SDF actions, using SDF properties for attributes, and events for data interfaces (replacing pub/sub topics). The updated OpenAPI definition is available on GitHub.
    *   **Data Format for Telemetry**:
        *   The discussion revisited the message format for MQTT telemetry data, specifically Protobuf, JSON, and CBOR.
        *   Rohit presented the results of prototyping efforts:
            *   Protobuf is compact but requires an external schema, which can be problematic with changes.
            *   JSON is widely used but not compact for binary data, requiring base64 encoding.
            *   CBOR is compact (though slightly less than Protobuf), includes schema within the message, and is well-suited for binary data. Prototyping confirmed its suitability.
        *   Ari, Michael, and others strongly favored CBOR due to its schema management benefits (better evolution), cultural compatibility with IETF standards, and no significant performance/resource impact compared to Protobuf for typical use cases.
    *   **Deployment Models for Nipy in SDF**:
        *   Bart presented two potential deployment models:
            1.  **Application-to-Gateway**: An application directly interacts with a Nipy Gateway using an SDF model with mappings to Nipy actions/events. The application understands the SDF model and translates commands/data.
            2.  **Application-to-Middleware-to-Gateway**: An application middleware layer sits between the application and the Nipy Gateway. This middleware could interpret SDF models (potentially embedded in a SKIM object) and provide application-aware APIs to the application, while still communicating with the Nipy Gateway in its connectivity context.
        *   **Key Principle**: The Network Gateway should ideally only have a "connectivity context" and not interpret the payload data (e.g., to uphold privacy, security, and regulatory compliance). The application (or middleware) holds the "application context" and the SDF model.
        *   **Identifiers**: Discussion on device identifiers revealed that Nipy Gateways assign UUIDs to SKIM objects to abstract away dynamic/rotating lower-layer identifiers (e.g., MAC addresses), thus allowing the application to address devices without exposing sensitive network-layer details.
    *   **Mapping Nipy into SDF**: Bart expressed a preference for a "native mapping" of Nipy into SDF rather than relying on a generic mapping construct, feeling that the work done to align Nipy with SDF justifies a more direct integration. He plans to discuss this with Carson.

## Decisions and Action Items

*   **Decision**: The ASDF working group will request a 1-hour meeting slot for IETF 121 in Dublin, with potential for a side meeting or hackathon focusing on Nipy/SDF integration.
    *   **Action Item**: (Chairs) Coordinate the Dublin meeting request and scheduling.
*   **Decision**: For the Nipy draft, **CBOR** will be adopted as the recommended data format for streaming telemetry over MQTT, replacing Protobuf.
    *   **Action Item**: (Nipy Draft Authors) Update the Nipy draft (`draft-asdf-nipy`) to reflect the API alignment changes and the decision to use CBOR for telemetry data. The updated text should be available before the next interim meeting.
*   **Action Item**: (Digital Twin Draft Author) Provide more detailed descriptions for GPS and relative location mechanisms in the next version of the `draft-asdf-digital-twin-location`.
*   **Action Item**: (Ari) Draft a proposal for a "non-affordance information" general mechanism and provide a rough sketch for how it would host location information, to be discussed with the Digital Twin draft author before the next meeting.
*   **Action Item**: (Bart) Follow up with Carsten to discuss the preferred "native mapping" approach for Nipy into SDF.

## Next Steps

*   The next ASDF interim meeting is scheduled for early October.
*   Further discussions on the Digital Twin draft will focus on the proposed "non-affordance information" framework and the details of location description, comparing the current draft's approach with new proposals. An adoption call for the Digital Twin draft will be reconsidered at the next meeting.
*   Continued work on the Nipy draft, specifically on the text for API alignment and the CBOR data format, and further exploration of native SDF integration and deployment models.
*   Planning for the in-person meeting at IETF 121 in Dublin, including potential side meetings for deeper technical discussions.