Markdown Version | Recording 1 | Recording 2
Session Date/Time: 18 Jun 2025 12:00
ASDF
Summary
The ASDF working group held its fifth inter-meeting to discuss updates on several drafts. Key discussions included the SDF extension for non-affordance information, SDF modeling for digital twins, and a detailed review of open issues for the NIPY draft. Several NIPY issues were addressed and closed, while others, particularly regarding device-model linkage and content-format, require further discussion. A NIPY hackathon and an additional virtual interim meeting were planned.
Key Discussion Points
Welcome and Notewell
- The chairs opened the meeting, welcoming participants and reviewing the IETF Notewell, IPR guidelines, and Code of Conduct.
SDF Extension for Non-Affordance Information (Junga Hong)
- Junga Hong presented updates to the "SDF extension for non-affordance information" draft.
- The primary update addressed previous questions on why a new
SDF non-affordanceclass was introduced instead of usingSDF property. The rationale is to semantically distinguish non-interactive, contextual, or setting metadata from actionable device features. - The extension is organized into two parts:
- Design-time model definition: Contextual metadata is embedded directly in the SDF document under the new
SDF non-affordanceclass. - Runtime context messaging: Introduces three JSON envelopes (
context snapshot,identity manifest,context patch) for deployed devices to report changes to this metadata over time, keeping it outside the affordance model.Context snapshot: Conveys the full current set of non-affordance fields.Identity manifest: Declares immutable identity data.Context patch: Transmits only changed keys to minimize bandwidth.
- Design-time model definition: Contextual metadata is embedded directly in the SDF document under the new
- Carsten Bormann commented on the need to ensure the architecture fits with SDF's overall design, especially regarding ecosystem variants and how actual messages (snapshots, manifests, patches) integrate. He also noted that patch/delta mechanisms could be useful for other (non-affordance) use cases like configuration updates. He mentioned an upcoming T2TRG meeting where model derivation, related to these issues, would be discussed.
- Michael Koster questioned the criticality of the
context patchfor non-affordance information, particularly if bandwidth savings are significant given the typical size of such metadata. Junga Hong clarified that it is intended for partial updates to minimize data transmission. - Ari Keränen found the life cycle management aspects interesting and suggested a potential side meeting in Madrid to explore them further.
SDF Modeling for Digital Twin (Yunjong Lee)
- Yunjong Lee presented the "SDF modeling for digital twin" draft (version 8), co-authored with Dr. Hong.
- The draft maps Digital Twin elements from ISO 23247 Part 3 to SDF thing structures to promote interoperability.
- The approach uses
SDF thingas the main abstraction. Information attributes like identifier, location, and owner are defined viaSDF non-affordance, allowing metadata modeling without implying interaction capabilities. - An updated modeling example demonstrates how static (non-affordance) and dynamic (property, event) attributes can be modeled.
- Future plans include extending modeling with historical data and object relationships, providing use case examples, and developing guidance for registration, discovery, and development of SDF-based digital twins.
- Ari Keränen asked about the "TBD" status of relationship information in the mapping table and suggested considering the
SDF relationquality or determining if it needs extension. Yunjong Lee agreed to investigate this further. - Michael Koster noted the draft's long history and questioned its fit into the working group's milestones.
- Ari Keränen suggested the working group review the draft with the perspective that it should serve as a "how-to" guide for modeling digital twin information using SDF. He emphasized that adoption indicates interest, not a final publication state.
NIPY Draft Issues (Bart van der Poel)
- Bart van der Poel announced a NIPY hackathon in Madrid, with Cisco and open-source implementations planned, encouraging participation for testing. He also raised concerns about the large number of open issues (35) and whether the allocated face-to-face time in Madrid would be sufficient, suggesting a side meeting or hackathon focus.
- The following NIPY issues were discussed and actions noted:
- Issue #1 (Broadcast Action): Originally an action in Draft 6. It was moved to
extensionsunder/manageas atransmitoperation. Rationale: it's a network-to-device broadcast (primarily BLE), not an action on a device's SDF affordance. Device-originated broadcasts are modeled as SDF events. Decision: Closed. - Issue #2 (Example Protocol Mapping): Related to #1. ID was removed from the payload, and
protocol mappingfor broadcast was simplified to just the "B" keyword. Moved underextensions. Decision: Closed. - Issue #3 (Action API Method): Changed to a
POSTmethod. It now returns a handle (Locationheader) which can be used with aGETrequest to retrieve status.octet-streamandJSONdata types were added. Multi-value input will be tracked as a separate issue. Ari Keränen questioned if the OpenAPI specification restricts content types compared toSDF content-formatquality. Bart will investigate if NIPY API can express more specific content types and addcontent-formatexamples to SDF. A new issue will be created for this. Decision: Closed (new issue for content-format). - Issue #4 (Event API Method): Similar to action API, changed to
POSTand returns a handle for status retrieval. Decision: Closed. - Issue #5 (Get ID Property Read All - #98): Request to retrieve all properties of a device. The current NIPY model does not explicitly associate an SDF model with a specific device instance; applications determine which model to use. This design avoids complexity in maintaining mappings (e.g., during firmware upgrades) but makes a "read all" property API difficult. Michael Koster noted this makes diagnostics harder. Ari Keränen highlighted the value of linkage for gateway validation and centralized model provisioning/discovery, suggesting an optional API for this. Bart van der Poel expressed strong reservations about an optional linkage due to significant implementation differences. It was suggested this might be more of a
schemeproblem. Decision: Remains open for further discussion. - Issue #6 (Write Multiple Properties - #97): Simplified the request body for writing multiple properties to a simple list/array. Decision: Closed.
- Issue #7 (Path Element Naming - #96): Path elements were changed from singular to plural (e.g., "property" to "properties", "event" to "events", "action" to "actions") for consistency with collections. Decision: Closed.
- Issue #8 (OpenAPI Descriptions - #95): All OpenAPI descriptions were updated in Draft 7. Decision: Closed.
- Issue #9 (Rename Property Parameter - #94): The parameter "property" was renamed to "property name" in path elements, and similarly for "event name" and "action name." Decision: Closed.
- Issue #10 (Less Detail in Responses - #93): Responses were simplified, e.g., using
204 No Contentfor success, and removing redundant parameters. Support foroctet-streamandJSONfor raw values was clarified. Decision: Closed (response details forcontent-formatto be added to the new issue). - Issue #11 (Data Types - #92): Discussion largely covered under
content-format. Decision: To be covered by the new issue. - Issue #12 (IANA Consideration - #91): The IANA consideration section has not yet been updated. Decision: Remains open.
- Issue #13 (API ID Parameter - #90): The first path element now uses a keyword (
device,group,registration,manage) followed by the ID, improving programmatic clarity. Decision: Closed. - Issue #14 (NIPY API with Embedded Protocol Mapping - #88):
Embedded protocol mappingwas largely removed or deprecated. Explicit connection API is under/manage; broadcast moved to extensions; read/write are deprecated in favor ofget propertyAPIs. Rohit noted one instance in the draft text still needs updating. Decision: Closed after text update.
- Issue #1 (Broadcast Action): Originally an action in Draft 6. It was moved to
Decisions and Action Items
- Non-Affordance: A side meeting in Madrid was suggested to further explore life cycle management aspects.
- Digital Twin: The working group will review the "SDF modeling for digital twin" draft, focusing on its role in demonstrating how to use SDF for digital twin information modeling, ahead of a potential call for adoption. Ari Keränen will drop an email to the list regarding
SDF relationshortcomings for digital twins. - NIPY:
- A NIPY hackathon will be held in Madrid.
- Bart van der Poel will create a new issue to track discussion of
content-formatin NIPY API and SDF examples. - Bart van der Poel will provide a one-sentence summary for each closed issue on the mailing list for historical record.
- Rohit will update the draft text to fully remove references to
embedded protocol mapping. - Issue #98 (Get ID Property Read All / Device-Model Linkage) remains open for further discussion.
- A virtual interim meeting is scheduled for July 2nd to continue reviewing remaining NIPY issues.
Next Steps
- Participants are encouraged to review the NIPY draft, especially Draft 7, in preparation for the upcoming virtual interim on July 2nd.
- Review the "SDF modeling for digital twin" draft for potential working group adoption.
- Bart van der Poel will follow up on creating the new NIPY issue and writing summaries for closed issues.
- Rohit will update the NIPY draft text.
- Discussions on NIPY issues, including #98, will continue at the next virtual interim and potentially at a side meeting or during the hackathon in Madrid.
- The chairs encouraged participants to recruit colleagues for document reviews and shepherd assignments.
Session Date/Time: 18 Jun 2025 12:00
ASDF
Summary
The ASDF working group held its fifth inter-meeting to discuss updates on several drafts. Key discussions included the SDF extension for non-affordance information, SDF modeling for digital twins, and a detailed review of open issues for the NIPY draft. Several NIPY issues were addressed and closed, while others, particularly regarding device-model linkage and content-format, require further discussion. A NIPY hackathon and an additional virtual interim meeting were planned.
Key Discussion Points
Welcome and Notewell
- The chairs opened the meeting, welcoming participants and reviewing the IETF Notewell, IPR guidelines, and Code of Conduct.
SDF Extension for Non-Affordance Information (Junga Hong)
- Junga Hong presented updates to the "SDF extension for non-affordance information" draft.
- The primary update addressed previous questions on why a new
SDF non-affordanceclass was introduced instead of usingSDF property. The rationale is to semantically distinguish non-interactive, contextual, or setting metadata from actionable device features. - The extension is organized into two parts:
- Design-time model definition: Contextual metadata is embedded directly in the SDF document under the new
SDF non-affordanceclass. - Runtime context messaging: Introduces three JSON envelopes (
context snapshot,identity manifest,context patch) for deployed devices to report changes to this metadata over time, keeping it outside the affordance model.Context snapshot: Conveys the full current set of non-affordance fields.Identity manifest: Declares immutable identity data.Context patch: Transmits only changed keys to minimize bandwidth.
- Design-time model definition: Contextual metadata is embedded directly in the SDF document under the new
- Carsten Bormann commented on the need to ensure the architecture fits with SDF's overall design, especially regarding ecosystem variants and how actual messages (snapshots, manifests, patches) integrate. He also noted that patch/delta mechanisms could be useful for other (non-affordance) use cases like configuration updates. He mentioned an upcoming T2TRG meeting where model derivation, related to these issues, would be discussed.
- Michael Koster questioned the criticality of the
context patchfor non-affordance information, particularly if bandwidth savings are significant given the typical size of such metadata. Junga Hong clarified that it is intended for partial updates to minimize data transmission. - Ari Keränen found the life cycle management aspects interesting and suggested a potential side meeting in Madrid to explore them further.
SDF Modeling for Digital Twin (Yunjong Lee)
- Yunjong Lee presented the "SDF modeling for digital twin" draft (version 8), co-authored with Dr. Hong.
- The draft maps Digital Twin elements from ISO 23247 Part 3 to SDF thing structures to promote interoperability.
- The approach uses
SDF thingas the main abstraction. Information attributes like identifier, location, and owner are defined viaSDF non-affordance, allowing metadata modeling without implying interaction capabilities. - An updated modeling example demonstrates how static (non-affordance) and dynamic (property, event) attributes can be modeled.
- Future plans include extending modeling with historical data and object relationships, providing use case examples, and developing guidance for registration, discovery, and development of SDF-based digital twins.
- Ari Keränen asked about the "TBD" status of relationship information in the mapping table and suggested considering the
SDF relationquality or determining if it needs extension. Yunjong Lee agreed to investigate this further. - Michael Koster noted the draft's long history and questioned its fit into the working group's milestones.
- Ari Keränen suggested the working group review the draft with the perspective that it should serve as a "how-to" guide for modeling digital twin information using SDF. He emphasized that adoption indicates interest, not a final publication state.
NIPY Draft Issues (Bart van der Poel)
- Bart van der Poel announced a NIPY hackathon in Madrid, with Cisco and open-source implementations planned, encouraging participation for testing. He also raised concerns about the large number of open issues (35) and whether the allocated face-to-face time in Madrid would be sufficient, suggesting a side meeting or hackathon focus.
- The following NIPY issues were discussed and actions noted:
- Issue #1 (Broadcast Action): Originally an action in Draft 6. It was moved to
extensionsunder/manageas atransmitoperation. Rationale: it's a network-to-device broadcast (primarily BLE), not an action on a device's SDF affordance. Device-originated broadcasts are modeled as SDF events. Decision: Closed. - Issue #2 (Example Protocol Mapping): Related to #1. ID was removed from the payload, and
protocol mappingfor broadcast was simplified to just the "B" keyword. Moved underextensions. Decision: Closed. - Issue #3 (Action API Method): Changed to a
POSTmethod. It now returns a handle (Locationheader) which can be used with aGETrequest to retrieve status.octet-streamandJSONdata types were added. Multi-value input will be tracked as a separate issue. Ari Keränen questioned if the OpenAPI specification restricts content types compared toSDF content-formatquality. Bart will investigate if NIPY API can express more specific content types and addcontent-formatexamples to SDF. A new issue will be created for this. Decision: Closed (new issue for content-format). - Issue #4 (Event API Method): Similar to action API, changed to
POSTand returns a handle for status retrieval. Decision: Closed. - Issue #5 (Get ID Property Read All - #98): Request to retrieve all properties of a device. The current NIPY model does not explicitly associate an SDF model with a specific device instance; applications determine which model to use. This design avoids complexity in maintaining mappings (e.g., during firmware upgrades) but makes a "read all" property API difficult. Michael Koster noted this makes diagnostics harder. Ari Keränen highlighted the value of linkage for gateway validation and centralized model provisioning/discovery, suggesting an optional API for this. Bart van der Poel expressed strong reservations about an optional linkage due to significant implementation differences. It was suggested this might be more of a
schemeproblem. Decision: Remains open for further discussion. - Issue #6 (Write Multiple Properties - #97): Simplified the request body for writing multiple properties to a simple list/array. Decision: Closed.
- Issue #7 (Path Element Naming - #96): Path elements were changed from singular to plural (e.g., "property" to "properties", "event" to "events", "action" to "actions") for consistency with collections. Decision: Closed.
- Issue #8 (OpenAPI Descriptions - #95): All OpenAPI descriptions were updated in Draft 7. Decision: Closed.
- Issue #9 (Rename Property Parameter - #94): The parameter "property" was renamed to "property name" in path elements, and similarly for "event name" and "action name." Decision: Closed.
- Issue #10 (Less Detail in Responses - #93): Responses were simplified, e.g., using
204 No Contentfor success, and removing redundant parameters. Support foroctet-streamandJSONfor raw values was clarified. Decision: Closed (response details forcontent-formatto be added to the new issue). - Issue #11 (Data Types - #92): Discussion largely covered under
content-format. Decision: To be covered by the new issue. - Issue #12 (IANA Consideration - #91): The IANA consideration section has not yet been updated. Decision: Remains open.
- Issue #13 (API ID Parameter - #90): The first path element now uses a keyword (
device,group,registration,manage) followed by the ID, improving programmatic clarity. Decision: Closed. - Issue #14 (NIPY API with Embedded Protocol Mapping - #88):
Embedded protocol mappingwas largely removed or deprecated. Explicit connection API is under/manage; broadcast moved to extensions; read/write are deprecated in favor ofget propertyAPIs. Rohit noted one instance in the draft text still needs updating. Decision: Closed after text update.
- Issue #1 (Broadcast Action): Originally an action in Draft 6. It was moved to
Decisions and Action Items
- Non-Affordance: A side meeting in Madrid was suggested to further explore life cycle management aspects.
- Digital Twin: The working group will review the "SDF modeling for digital twin" draft, focusing on its role in demonstrating how to use SDF for digital twin information modeling, ahead of a potential call for adoption. Ari Keränen will drop an email to the list regarding
SDF relationshortcomings for digital twins. - NIPY:
- A NIPY hackathon will be held in Madrid.
- Bart van der Poel will create a new issue to track discussion of
content-formatin NIPY API and SDF examples. - Bart van der Poel will provide a one-sentence summary for each closed issue on the mailing list for historical record.
- Rohit will update the draft text to fully remove references to
embedded protocol mapping. - Issue #98 (Get ID Property Read All / Device-Model Linkage) remains open for further discussion.
- A virtual interim meeting is scheduled for July 2nd to continue reviewing remaining NIPY issues.
Next Steps
- Participants are encouraged to review the NIPY draft, especially Draft 7, in preparation for the upcoming virtual interim on July 2nd.
- Review the "SDF modeling for digital twin" draft for potential working group adoption.
- Bart van der Poel will follow up on creating the new NIPY issue and writing summaries for closed issues.
- Rohit will update the NIPY draft text.
- Discussions on NIPY issues, including #98, will continue at the next virtual interim and potentially at a side meeting or during the hackathon in Madrid.
- The chairs encouraged participants to recruit colleagues for document reviews and shepherd assignments.