Session Date/Time: 22 Apr 2024 14:00

ASDF

Summary

The ASDF interim meeting focused on the status of the ASDF base specification, reviewing proposals for new work to extend ASDF capabilities, and discussing the evolution of the working group's charter. Key technical discussions revolved around mechanisms for modeling instance-specific information (including location), defining ecosystem-specific mappings, extending link capabilities, and integrating ASDF with non-IP device control (nipy). The primary goal was to clarify the working group's intended deliverables and milestones to address feedback on the proposed charter.

Key Discussion Points

ASDF Base Specification Status:
- The ASDF base specification (draft-ietf-asdf-sdf) was submitted as an Individual Draft (ID) on February 29th and a publication request was sent to the ISG on March 29th.
- The document is currently in AD evaluation, with review comments expected to lead to a -09 revision.
- Anticipated timeline includes IETF last call (expected around mid-May), directory reviews, further ISG evaluation (including "discuss" and "comment" feedback), and eventual approval (May/June).
- Following approval, the document will proceed through RFC editor stages (edit, RFC editor, OFF 48), with publication potentially in July or August. Registries associated with the specification will be created early in the RFC editor process.
Proposed ASDF Extensions (Carsten Bormann):
- Modeling Infrastructure:
  - Mapping Files: There is a recognized need for a mechanism to attach ecosystem-specific information (e.g., numeric identifiers from OMA LwM2M) to ASDF models, going beyond the common base model. A draft exists, but the term "mapping file" is considered problematic and needs refinement.
  - Instance Information: ASDF currently focuses on modeling class-level information. A clear need exists to model instance-specific information such as identity, supplementary links, physical wiring configurations, and location. This is straightforward for properties but less clear for other interaction types. Current practice of "stuffing" such information into sdf:properties is not ideal as it doesn't represent an affordance.
- Tool Support:
  - A compact notation for ASDF is being developed as an informational document to aid in whiteboard discussions and presentations.
  - Drafts describing translation tools (e.g., Yang-to-SDF) exist, but the working group's scope is not to standardize tools.
- New Qualities (Extension Points):
  - Links: The base specification lacks specific support for links, which can be URIs or more complex RFC 8288 structures. Distinction is needed between links internal to an ASDF model and links describing relationships between instances (e.g., a light switch controlling a specific light). Two drafts (relations and sdf-type-link) address these aspects and are strong candidates for adoption.
  - Location Information: Identified as a key example of instance-specific, non-traditional information that needs to be integrated into the ASDF meta-model, requiring robust instance vs. class support.
  - Non-IP Device Control (nipy): Requires ASDF to capture additional application-layer information and provide mappings to specific non-IP protocols.
Nipy Integration with ASDF (Bart van der Put):
- Presented a conceptual mapping of nipy operations (connectable status, read/write/subscribe/broadcast attributes) and registrations (topic, attribute name, file) to ASDF constructs.
- An ASDF property could represent a nipy:device object, containing device attributes like MAC address, manufacturer, and security models (e.g., BLE, Zigbee).
- ASDF property could be associated with nipy attributes (regular, subscription, broadcast).
- ASDF action could map to writing a nipy attribute (e.g., changing a light's color) or activating/deactivating a subscription.
- ASDF event could map to broadcast or subscription messages received from a device.
- Nipy registrations (e.g., attribute names, topics) map naturally to ASDF property and event names.
- The goal is to enable applications to interact with non-IP devices via a nipy Gateway using only their ASDF definitions.
- Next Step: Bart will develop concrete ASDF examples to illustrate these mappings.
Location Information Work (Yun Yong):
- Motivated by the fact that object actions and events can be location-dependent, positioning location information as distinct from standard properties.
- Proposed adding sdf:location at the sdf:object, sdf:property, sdf:event, and sdf:action levels within the SDF model.
- Examples included geographical location for a boat and relative location for a heater inside the boat.
- Suggested adding a type to sdf:location to indicate duration.
Charter Evolution and Deliverables:
- The existing charter proposal received a "discuss" from an AD, primarily due to a perceived lack of specificity regarding deliverables and milestones, and ambiguity around the scope of "digital twin" work.
- Scope of Digital Twins: The working group clarified that it is not working on "digital twins" as a broad topic, but rather on ASDF features (e.g., location, mechanisms for expressing non-affordance information about instances) that support modeling digital twins. The aim is to provide modeling capabilities that enable use cases for digital twins, not to define digital twin solutions themselves.
- Nipy Deliverable: It was agreed to start with one draft for nipy integration, with flexibility for additional drafts if technical needs arise. Milestones should reflect discussion in future interims, aiming for a call for adoption around July and WG approval in approximately one year.
- SDF Infrastructure Deliverables (Mapping, Instance, Links): These are considered high-priority, foundational work, particularly the mapping mechanisms and instance information, as other extensions depend on them.
- Milestones: While precise dates are difficult, milestones should clearly indicate the order and potential parallelism of work items.
- The current ISG review is internal; an external evaluation period and a second ISG review will follow.

Decisions and Action Items

Decision: The ASDF Working Group's charter is intended for specific deliverables to be completed, rather than being a long-term maintenance group.
Action Item: Chairs (Michael and Nicholas) to refine the charter language, making deliverables and milestones more explicit. This includes clarifying the scope of "digital twin" work to focus on ASDF mechanisms that enable digital twin modeling (e.g., non-affordance instance information, location), rather than broad digital twin solutions.
Action Item: Chairs to engage in a direct, private conversation with AD Roman to ensure full understanding of his feedback and propose consolidated language addressing his concerns.
Action Item: Bart to develop concrete SDF examples for nipy integration to facilitate deeper technical discussions.
Action Item: The working group will work on language to clearly explain "non-affordance information" in the ASDF context to a broader audience.

Next Steps

Charter Refinement: The chairs will draft an updated charter proposal, incorporating the refined deliverables, milestones, and clarified scope for digital twin-related work, and circulate it for working group review.
Nipy Design Team Meeting: A dedicated design team meeting (or similar focused discussion) will be scheduled in approximately 3-4 weeks to delve into the technical details and SDF examples for nipy integration.
SDF Infrastructure Focus: Early discussions and work will prioritize mapping mechanisms and instance information documents, as these are foundational for other proposed extensions.
Mailing List Discussion: Continue detailed technical and charter-related discussions on the ASDF mailing list.