Session Date/Time: 05 Jul 2024 14:00

ASDF

Summary

This interim meeting of the ASDF Working Group covered updates on the WG's status, the progress of the core SDF document towards RFC publication, a significant discussion on the nipy draft, and a brief update on the digital twin location draft. Key discussions centered around editorial improvements for the SDF document, architectural choices for nipy's Pub/Sub API format, and the conceptual integration of nipy with the SDF model, including the role of skim. A follow-up design team meeting was proposed to delve deeper into the nipy integration topics.

Key Discussion Points

Working Group Status Update:
- The ASDF WG was chartered in October 2020.
- The initial SDF document (draft-ietf-asdf-sdf) has been submitted to the IESG for publication.
- A new WG Charter has been adopted.
- The nipy draft (draft-ietf-asdf-nipy) has been adopted as a working group document.
- A call for adoption is out for the digital twin location draft (draft-jangi-asdf-digital-twin-location). Review and feedback on the mailing list are encouraged.
- The WG will not meet at IETF 117 in Vancouver due to unavailability. Two interims are planned for September and October, with potential to meet in Dublin.
SDF Document Status (draft-ietf-asdf-sdf):
- The draft is currently undergoing IESG review.
- Significant editorial comments have been received from the AD, Melchior, and particularly Susan Harris (around 40 comments).
- Work has begun on addressing these comments, with the aim to improve readability for new readers.
- A new draft version addressing these comments is expected to be submitted when the IETF repository reopens, likely for review in early August.
- The focus is on text clarification to streamline the RFC editor process, with little technical discussion needed.
nipy Discussion (draft-ietf-asdf-nipy):
- Draft Readability Improvements: Authors plan to improve the draft's readability by moving schema definitions upfront, referencing them, and using JSON examples instead of tables for API calls.
  - The large OpenAPI model (100+ pages) will remain included in the document, as it's useful for implementers and IETF policy doesn't prohibit comprehensive specifications.
  - It was suggested to add guidance on how to extract the OpenAPI model from the XML version of the draft.
- Pub/Sub API Format (Protobuf vs. JSON+CBOR):
  - Currently, the Pub/Sub API uses Protobuf over MQTT, chosen for binary data efficiency and common use in affiliated systems.
  - Concerns were raised regarding Protobuf's version control issues, which require coordinated software updates on both sides of communication, posing a problem for internet-style applications.
  - JSON+CBOR was proposed as a more internet-friendly alternative.
  - It was agreed that while important, a decision on the Pub/Sub format could be deferred. Further architectural work and potential prototyping of both approaches would be beneficial.
- Binary Data in RESTful Interface: Briefly noted that JSON and CBOR are easily convertible, reducing concerns for mixed data types.
- Protocol Extensions for Non-IP Wireless (BLE, Zigbee):
  - nipy currently defines extensions for BLE and Zigbee.
  - The architecture aims for pluggability, allowing other ecosystems (e.g., KNX) to define their own extensions.
  - An IANA registry for these extensions was suggested.
  - The design separates common attribute operations from protocol-specific definitions (e.g., an attribute "temperature" mapped to specific BLE service/characteristic IDs).
- API Extensions: Potential for custom bulk APIs by combining multiple calls, and simplifying existing binding/connection APIs into a single one.
- Integration with SDF:
  - The proposal separates skim+nipy for "connectivity" (device identity, onboarding, radio extensions) from SDF for "application context" (device function, properties, events, actions).
  - A library would sit on top of skim+nipy, interpreting SDF models and mapping them to skim/nipy APIs.
  - Mapping examples: SDF properties -> nipy attributes, subscriptions, broadcasts, files, connections; SDF actions -> nipy get/put/post/delete on properties; SDF events -> nipy pub/sub topics (connection, broadcast, subscription).
  - A proposed integration mechanism involves adding a new "nipy property" quality to the SDF specification (similar to data quality extensions) which would be a JSON object containing the protocol-specific extension (e.g., BLE service/characteristic IDs).
  - Discussion arose about where information should reside: the nipy Gateway knows the specific device details on the non-IP side, and could potentially provide an SDF description. The perspective was offered that skim could carry SDF device descriptions, allowing the proxy (Gateway) to handle this marrying of information rather than the client application. Concern was raised about moving application context (e.g., "heart rate") into the network vs. keeping it at the application layer.
Digital Twin Location Update (draft-jangi-asdf-digital-twin-location):
- Yong Jangi presented an update proposing to add stdf:location to the SDF model.
- Location can be described using GPS coordinates or postal addresses for physical locations, and strings or integers for relative locations.
- The proposal is to add stdf:location at the level of stdf:property, stdf:action, and stdf:event to describe the location of an stdf:thing and stdf:object.
- The draft aims to enable extensive reuse and interoperability for location data.
- The author suggested adding a timestamp to stdf:location to indicate duration.
- A call for review and adoption was reiterated.

Decisions and Action Items

Decision: The OpenAPI model within the nipy draft will remain included to be useful for implementers.
Decision: The choice between Protobuf and JSON+CBOR for nipy's Pub/Sub API will be deferred for further architectural discussion and potential prototyping.
Action Item: Bart (and nipy authors) to proceed with planned readability improvements for the nipy draft (schema section, JSON examples).
Action Item: Carsten to provide examples of IETF documents that include models and guidance on how to extract them from the XML version of a draft.
Action Item: Nicholas (Chair) to organize a "design team meeting" after the Vancouver IETF to continue the detailed discussion on nipy/skim/SDF integration and architectural concepts.
Action Item: All WG participants are encouraged to review draft-jangi-asdf-digital-twin-location and provide feedback on the mailing list to support its adoption.

Next Steps

Continue addressing editorial comments for the core SDF document (draft-ietf-asdf-sdf) in preparation for a new version submission.
Conduct the planned "design team meeting" post-Vancouver to resolve architectural questions regarding nipy, skim, and SDF integration.
Review and discuss the draft-jangi-asdf-digital-twin-location for potential adoption.
Further interims are planned for September and October.