Markdown Version | Recording 1 | Recording 2 | Recording 3 | Recording 4 | Recording 5

Session Date/Time: 14 Mar 2023 15:00

SATP

Summary

This was the first official interim meeting of the SATP Working Group, held using MeetEcho. The primary focus of the session was to review updates to the architecture and SATP core protocol documents, and to discuss the crucial concepts of "Context ID" and "Session ID," including a proposed "Stage 0" flow that precedes the core SATP protocol. The group also made plans and identified action items for the upcoming IETF 116 working group session.

Key Discussion Points

• Platform Experience: Initial discussion covered the use of MeetEcho, with participants noting better performance with Firefox or Chrome compared to Safari.
• Architecture and SATP Core Document Updates (Thomas):
  • Both the architecture document and the SATP core protocol document have been updated to align with version 16 of the working group's color flow diagram, specifically for messages within the "inner lane" (between gateways).
  • Terminology for "Context ID" and "Session ID" has been added to the architecture document, with the expectation that these definitions will eventually be moved into a dedicated terminology document for the working group.
  • The latest version of the core document now explicitly includes a "Session ID" in every flow. This Session ID is intended to remain constant throughout a session, uniquely identifying the instance of the transfer, and allowing assets to be bound to it without needing to be repeated in each message.
  • A suggestion was made to define the "lock assertion" JSON in a way that allows for an optional network-specific or vendor-specific body, enabling the inclusion of unique cryptographic proofs from the origin network.
  • Initial queries arose regarding the determination of the Session ID in a "Stage 0" phase, with Thomas noting that this is often application-driven and happens "out of band" from the core SATP protocol.
• Pre-SATP "Stage 0" Flow Proposal (Dennis):
  • Dennis presented a potential sequence diagram outlining a "Stage 0" process that would occur before the SATP protocol is initiated. The goal of this stage is to establish preconditions necessary for SATP, such as how gateways connect and how assets are bound to a transfer context.
  • Proposed Flow Highlights:
    1. Client 1 requests a transfer from Gateway 1.
    2. Gateway 1 provides a "transfer context" (a unique identifier, potentially signed by the Gateway).
    3. Client 1 binds the assets to be transferred to this context within its local network/DLT.
    4. Client 1 communicates the transfer context to Client 2.
    5. Client 1 instructs Gateway 1 to begin the transfer.
    6. Client 2's local system is notified of an incoming transfer.
    7. Client 2 provides the transfer context to Gateway 2.
    8. Gateway 2 contacts Gateway 1, returning the context, enabling the gateways to connect and recognize the transfer.
    9. The SATP protocol (in gray box) then commences between Gateway 1 and Gateway 2.
    10. Clients can subsequently query their respective gateways for the transfer's completion status.
  • Discussion on Stage 0:
    • The "transfer context" could be a composite data structure (e.g., JSON) including the session ID and other relevant information.
    • Clarification was provided that the "session ID" uniquely identifies the instance of the transfer, not necessarily the asset itself. Assets are bound to this transfer context.
    • The chair reiterated the working group's focus on the core SATP protocol and the need to avoid getting "lost in the detail" of pre-SATP negotiation. While Stage 0 is important for context, the WG's deliverables should focus on SATP.
    • Thomas noted that the SATP core document still alludes to Type 1 APIs (application to gateway) from earlier versions but lacks detailed text.
    • There was a shared understanding that while a detailed protocol for Stage 0 might be out of scope, the preconditions or post-conditions of Stage 0 (i.e., what state the gateways must be in, and what information must be available to them) are critical for SATP to function and therefore need to be explicitly defined.

Decisions and Action Items

• Decision: The working group will define the preconditions required for the SATP protocol to commence, outlining the necessary information and state that must be established during a pre-SATP "Stage 0." The group will focus on these preconditions rather than specifying a detailed Stage 0 protocol flow. (A sense of those present indicated agreement on this approach.)
• Action Item (Thomas, Rama, Dennis, Alex, Martin): Authors of the architecture, core protocol, terminology, and use cases drafts are requested to submit their most up-to-date versions to the chairs by Wednesday, March 29th, to allow for pre-upload and preparation for the IETF 116 session.
• Action Item (Dennis): Refine the "Stage 0" proposal to describe the preconditions or post-conditions of Stage 0 that are essential for SATP. This revised description will be discussed on the mailing list. Dennis will also email the presented diagram to the mailing list.
• Action Item (Alex and Dennis): Coordinate offline on GitHub to collaboratively edit and compile the terminology document, taking ownership of the editing process based on group submissions and consensus.
• Action Item (Thomas): Reach out to individuals who have requested flip-flopping time zones for interim meetings (particularly in Australia and Pacific US) to gather preferred timings. The chair will then assess options.
• Action Item (Volunteer): A note-taker was assigned for this official interim meeting (unnamed in transcript, but requested by chair).

Next Steps

• The next working group session will be held at IETF 116 in Yokohama, Japan, on Friday, March 31st, starting at 9 AM Japan time for a two-hour slot.
• Document authors (Thomas, Rama, Dennis, and others) are expected to prepare brief (5-minute) introductions to their respective drafts, followed by open floor discussion by the working group.
• The mailing list will be used for continued discussion on the preconditions for SATP as refined by Dennis.
• The chairs will explore options for adjusting interim meeting time zones to accommodate participants in different geographic regions.
• Participants are encouraged to ensure they have registered for IETF 116.
• Any additional agenda points for the IETF 116 session should be communicated to the chairs.

Session Date/Time: 14 Mar 2023 15:00

SATP

Summary

This was the first official interim meeting of the SATP Working Group, held using MeetEcho. The primary focus of the session was to review updates to the architecture and SATP core protocol documents, and to discuss the crucial concepts of "Context ID" and "Session ID," including a proposed "Stage 0" flow that precedes the core SATP protocol. The group also made plans and identified action items for the upcoming IETF 116 working group session.

Key Discussion Points

• Platform Experience: Initial discussion covered the use of MeetEcho, with participants noting better performance with Firefox or Chrome compared to Safari.
• Architecture and SATP Core Document Updates (Thomas):
  • Both the architecture document and the SATP core protocol document have been updated to align with version 16 of the working group's color flow diagram, specifically for messages within the "inner lane" (between gateways).
  • Terminology for "Context ID" and "Session ID" has been added to the architecture document, with the expectation that these definitions will eventually be moved into a dedicated terminology document for the working group.
  • The latest version of the core document now explicitly includes a "Session ID" in every flow. This Session ID is intended to remain constant throughout a session, uniquely identifying the instance of the transfer, and allowing assets to be bound to it without needing to be repeated in each message.
  • A suggestion was made to define the "lock assertion" JSON in a way that allows for an optional network-specific or vendor-specific body, enabling the inclusion of unique cryptographic proofs from the origin network.
  • Initial queries arose regarding the determination of the Session ID in a "Stage 0" phase, with Thomas noting that this is often application-driven and happens "out of band" from the core SATP protocol.
• Pre-SATP "Stage 0" Flow Proposal (Dennis):
  • Dennis presented a potential sequence diagram outlining a "Stage 0" process that would occur before the SATP protocol is initiated. The goal of this stage is to establish preconditions necessary for SATP, such as how gateways connect and how assets are bound to a transfer context.
  • Proposed Flow Highlights:
    1. Client 1 requests a transfer from Gateway 1.
    2. Gateway 1 provides a "transfer context" (a unique identifier, potentially signed by the Gateway).
    3. Client 1 binds the assets to be transferred to this context within its local network/DLT.
    4. Client 1 communicates the transfer context to Client 2.
    5. Client 1 instructs Gateway 1 to begin the transfer.
    6. Client 2's local system is notified of an incoming transfer.
    7. Client 2 provides the transfer context to Gateway 2.
    8. Gateway 2 contacts Gateway 1, returning the context, enabling the gateways to connect and recognize the transfer.
    9. The SATP protocol (in gray box) then commences between Gateway 1 and Gateway 2.
    10. Clients can subsequently query their respective gateways for the transfer's completion status.
  • Discussion on Stage 0:
    • The "transfer context" could be a composite data structure (e.g., JSON) including the session ID and other relevant information.
    • Clarification was provided that the "session ID" uniquely identifies the instance of the transfer, not necessarily the asset itself. Assets are bound to this transfer context.
    • The chair reiterated the working group's focus on the core SATP protocol and the need to avoid getting "lost in the detail" of pre-SATP negotiation. While Stage 0 is important for context, the WG's deliverables should focus on SATP.
    • Thomas noted that the SATP core document still alludes to Type 1 APIs (application to gateway) from earlier versions but lacks detailed text.
    • There was a shared understanding that while a detailed protocol for Stage 0 might be out of scope, the preconditions or post-conditions of Stage 0 (i.e., what state the gateways must be in, and what information must be available to them) are critical for SATP to function and therefore need to be explicitly defined.

Decisions and Action Items

• Decision: The working group will define the preconditions required for the SATP protocol to commence, outlining the necessary information and state that must be established during a pre-SATP "Stage 0." The group will focus on these preconditions rather than specifying a detailed Stage 0 protocol flow. (A sense of those present indicated agreement on this approach.)
• Action Item (Thomas, Rama, Dennis, Alex, Martin): Authors of the architecture, core protocol, terminology, and use cases drafts are requested to submit their most up-to-date versions to the chairs by Wednesday, March 29th, to allow for pre-upload and preparation for the IETF 116 session.
• Action Item (Dennis): Refine the "Stage 0" proposal to describe the preconditions or post-conditions of Stage 0 that are essential for SATP. This revised description will be discussed on the mailing list. Dennis will also email the presented diagram to the mailing list.
• Action Item (Alex and Dennis): Coordinate offline on GitHub to collaboratively edit and compile the terminology document, taking ownership of the editing process based on group submissions and consensus.
• Action Item (Thomas): Reach out to individuals who have requested flip-flopping time zones for interim meetings (particularly in Australia and Pacific US) to gather preferred timings. The chair will then assess options.
• Action Item (Volunteer): A note-taker was assigned for this official interim meeting (unnamed in transcript, but requested by chair).

Next Steps

• The next working group session will be held at IETF 116 in Yokohama, Japan, on Friday, March 31st, starting at 9 AM Japan time for a two-hour slot.
• Document authors (Thomas, Rama, Dennis, and others) are expected to prepare brief (5-minute) introductions to their respective drafts, followed by open floor discussion by the working group.
• The mailing list will be used for continued discussion on the preconditions for SATP as refined by Dennis.
• The chairs will explore options for adjusting interim meeting time zones to accommodate participants in different geographic regions.
• Participants are encouraged to ensure they have registered for IETF 116.
• Any additional agenda points for the IETF 116 session should be communicated to the chairs.

Session Date/Time: 14 Mar 2023 15:00

SATP

Summary

This was the first official interim meeting of the SATP Working Group, held using MeetEcho. The primary focus of the session was to review updates to the architecture and SATP core protocol documents, and to discuss the crucial concepts of "Context ID" and "Session ID," including a proposed "Stage 0" flow that precedes the core SATP protocol. The group also made plans and identified action items for the upcoming IETF 116 working group session.

Key Discussion Points

• Platform Experience: Initial discussion covered the use of MeetEcho, with participants noting better performance with Firefox or Chrome compared to Safari.
• Architecture and SATP Core Document Updates (Thomas):
  • Both the architecture document and the SATP core protocol document have been updated to align with version 16 of the working group's color flow diagram, specifically for messages within the "inner lane" (between gateways).
  • Terminology for "Context ID" and "Session ID" has been added to the architecture document, with the expectation that these definitions will eventually be moved into a dedicated terminology document for the working group.
  • The latest version of the core document now explicitly includes a "Session ID" in every flow. This Session ID is intended to remain constant throughout a session, uniquely identifying the instance of the transfer, and allowing assets to be bound to it without needing to be repeated in each message.
  • A suggestion was made to define the "lock assertion" JSON in a way that allows for an optional network-specific or vendor-specific body, enabling the inclusion of unique cryptographic proofs from the origin network.
  • Initial queries arose regarding the determination of the Session ID in a "Stage 0" phase, with Thomas noting that this is often application-driven and happens "out of band" from the core SATP protocol.
• Pre-SATP "Stage 0" Flow Proposal (Dennis):
  • Dennis presented a potential sequence diagram outlining a "Stage 0" process that would occur before the SATP protocol is initiated. The goal of this stage is to establish preconditions necessary for SATP, such as how gateways connect and how assets are bound to a transfer context.
  • Proposed Flow Highlights:
    1. Client 1 requests a transfer from Gateway 1.
    2. Gateway 1 provides a "transfer context" (a unique identifier, potentially signed by the Gateway).
    3. Client 1 binds the assets to be transferred to this context within its local network/DLT.
    4. Client 1 communicates the transfer context to Client 2.
    5. Client 1 instructs Gateway 1 to begin the transfer.
    6. Client 2's local system is notified of an incoming transfer.
    7. Client 2 provides the transfer context to Gateway 2.
    8. Gateway 2 contacts Gateway 1, returning the context, enabling the gateways to connect and recognize the transfer.
    9. The SATP protocol (in gray box) then commences between Gateway 1 and Gateway 2.
    10. Clients can subsequently query their respective gateways for the transfer's completion status.
  • Discussion on Stage 0:
    • The "transfer context" could be a composite data structure (e.g., JSON) including the session ID and other relevant information.
    • Clarification was provided that the "session ID" uniquely identifies the instance of the transfer, not necessarily the asset itself. Assets are bound to this transfer context.
    • The chair reiterated the working group's focus on the core SATP protocol and the need to avoid getting "lost in the detail" of pre-SATP negotiation. While Stage 0 is important for context, the WG's deliverables should focus on SATP.
    • Thomas noted that the SATP core document still alludes to Type 1 APIs (application to gateway) from earlier versions but lacks detailed text.
    • There was a shared understanding that while a detailed protocol for Stage 0 might be out of scope, the preconditions or post-conditions of Stage 0 (i.e., what state the gateways must be in, and what information must be available to them) are critical for SATP to function and therefore need to be explicitly defined.

Decisions and Action Items

• Decision: The working group will define the preconditions required for the SATP protocol to commence, outlining the necessary information and state that must be established during a pre-SATP "Stage 0." The group will focus on these preconditions rather than specifying a detailed Stage 0 protocol flow. (A sense of those present indicated agreement on this approach.)
• Action Item (Thomas, Rama, Dennis, Alex, Martin): Authors of the architecture, core protocol, terminology, and use cases drafts are requested to submit their most up-to-date versions to the chairs by Wednesday, March 29th, to allow for pre-upload and preparation for the IETF 116 session.
• Action Item (Dennis): Refine the "Stage 0" proposal to describe the preconditions or post-conditions of Stage 0 that are essential for SATP. This revised description will be discussed on the mailing list. Dennis will also email the presented diagram to the mailing list.
• Action Item (Alex and Dennis): Coordinate offline on GitHub to collaboratively edit and compile the terminology document, taking ownership of the editing process based on group submissions and consensus.
• Action Item (Thomas): Reach out to individuals who have requested flip-flopping time zones for interim meetings (particularly in Australia and Pacific US) to gather preferred timings. The chair will then assess options.
• Action Item (Volunteer): A note-taker was assigned for this official interim meeting (unnamed in transcript, but requested by chair).

Next Steps

• The next working group session will be held at IETF 116 in Yokohama, Japan, on Friday, March 31st, starting at 9 AM Japan time for a two-hour slot.
• Document authors (Thomas, Rama, Dennis, and others) are expected to prepare brief (5-minute) introductions to their respective drafts, followed by open floor discussion by the working group.
• The mailing list will be used for continued discussion on the preconditions for SATP as refined by Dennis.
• The chairs will explore options for adjusting interim meeting time zones to accommodate participants in different geographic regions.
• Participants are encouraged to ensure they have registered for IETF 116.
• Any additional agenda points for the IETF 116 session should be communicated to the chairs.

Session Date/Time: 14 Mar 2023 15:00

SATP

Summary

This was the first official interim meeting of the SATP Working Group, held using MeetEcho. The primary focus of the session was to review updates to the architecture and SATP core protocol documents, and to discuss the crucial concepts of "Context ID" and "Session ID," including a proposed "Stage 0" flow that precedes the core SATP protocol. The group also made plans and identified action items for the upcoming IETF 116 working group session.

Key Discussion Points

• Platform Experience: Initial discussion covered the use of MeetEcho, with participants noting better performance with Firefox or Chrome compared to Safari.
• Architecture and SATP Core Document Updates (Thomas):
  • Both the architecture document and the SATP core protocol document have been updated to align with version 16 of the working group's color flow diagram, specifically for messages within the "inner lane" (between gateways).
  • Terminology for "Context ID" and "Session ID" has been added to the architecture document, with the expectation that these definitions will eventually be moved into a dedicated terminology document for the working group.
  • The latest version of the core document now explicitly includes a "Session ID" in every flow. This Session ID is intended to remain constant throughout a session, uniquely identifying the instance of the transfer, and allowing assets to be bound to it without needing to be repeated in each message.
  • A suggestion was made to define the "lock assertion" JSON in a way that allows for an optional network-specific or vendor-specific body, enabling the inclusion of unique cryptographic proofs from the origin network.
  • Initial queries arose regarding the determination of the Session ID in a "Stage 0" phase, with Thomas noting that this is often application-driven and happens "out of band" from the core SATP protocol.
• Pre-SATP "Stage 0" Flow Proposal (Dennis):
  • Dennis presented a potential sequence diagram outlining a "Stage 0" process that would occur before the SATP protocol is initiated. The goal of this stage is to establish preconditions necessary for SATP, such as how gateways connect and how assets are bound to a transfer context.
  • Proposed Flow Highlights:
    1. Client 1 requests a transfer from Gateway 1.
    2. Gateway 1 provides a "transfer context" (a unique identifier, potentially signed by the Gateway).
    3. Client 1 binds the assets to be transferred to this context within its local network/DLT.
    4. Client 1 communicates the transfer context to Client 2.
    5. Client 1 instructs Gateway 1 to begin the transfer.
    6. Client 2's local system is notified of an incoming transfer.
    7. Client 2 provides the transfer context to Gateway 2.
    8. Gateway 2 contacts Gateway 1, returning the context, enabling the gateways to connect and recognize the transfer.
    9. The SATP protocol (in gray box) then commences between Gateway 1 and Gateway 2.
    10. Clients can subsequently query their respective gateways for the transfer's completion status.
  • Discussion on Stage 0:
    • The "transfer context" could be a composite data structure (e.g., JSON) including the session ID and other relevant information.
    • Clarification was provided that the "session ID" uniquely identifies the instance of the transfer, not necessarily the asset itself. Assets are bound to this transfer context.
    • The chair reiterated the working group's focus on the core SATP protocol and the need to avoid getting "lost in the detail" of pre-SATP negotiation. While Stage 0 is important for context, the WG's deliverables should focus on SATP.
    • Thomas noted that the SATP core document still alludes to Type 1 APIs (application to gateway) from earlier versions but lacks detailed text.
    • There was a shared understanding that while a detailed protocol for Stage 0 might be out of scope, the preconditions or post-conditions of Stage 0 (i.e., what state the gateways must be in, and what information must be available to them) are critical for SATP to function and therefore need to be explicitly defined.

Decisions and Action Items

• Decision: The working group will define the preconditions required for the SATP protocol to commence, outlining the necessary information and state that must be established during a pre-SATP "Stage 0." The group will focus on these preconditions rather than specifying a detailed Stage 0 protocol flow. (A sense of those present indicated agreement on this approach.)
• Action Item (Thomas, Rama, Dennis, Alex, Martin): Authors of the architecture, core protocol, terminology, and use cases drafts are requested to submit their most up-to-date versions to the chairs by Wednesday, March 29th, to allow for pre-upload and preparation for the IETF 116 session.
• Action Item (Dennis): Refine the "Stage 0" proposal to describe the preconditions or post-conditions of Stage 0 that are essential for SATP. This revised description will be discussed on the mailing list. Dennis will also email the presented diagram to the mailing list.
• Action Item (Alex and Dennis): Coordinate offline on GitHub to collaboratively edit and compile the terminology document, taking ownership of the editing process based on group submissions and consensus.
• Action Item (Thomas): Reach out to individuals who have requested flip-flopping time zones for interim meetings (particularly in Australia and Pacific US) to gather preferred timings. The chair will then assess options.
• Action Item (Volunteer): A note-taker was assigned for this official interim meeting (unnamed in transcript, but requested by chair).

Next Steps

• The next working group session will be held at IETF 116 in Yokohama, Japan, on Friday, March 31st, starting at 9 AM Japan time for a two-hour slot.
• Document authors (Thomas, Rama, Dennis, and others) are expected to prepare brief (5-minute) introductions to their respective drafts, followed by open floor discussion by the working group.
• The mailing list will be used for continued discussion on the preconditions for SATP as refined by Dennis.
• The chairs will explore options for adjusting interim meeting time zones to accommodate participants in different geographic regions.
• Participants are encouraged to ensure they have registered for IETF 116.
• Any additional agenda points for the IETF 116 session should be communicated to the chairs.

Session Date/Time: 14 Mar 2023 15:00

SATP

Summary

This was the first official interim meeting of the SATP Working Group, held using MeetEcho. The primary focus of the session was to review updates to the architecture and SATP core protocol documents, and to discuss the crucial concepts of "Context ID" and "Session ID," including a proposed "Stage 0" flow that precedes the core SATP protocol. The group also made plans and identified action items for the upcoming IETF 116 working group session.

Key Discussion Points

• Platform Experience: Initial discussion covered the use of MeetEcho, with participants noting better performance with Firefox or Chrome compared to Safari.
• Architecture and SATP Core Document Updates (Thomas):
  • Both the architecture document and the SATP core protocol document have been updated to align with version 16 of the working group's color flow diagram, specifically for messages within the "inner lane" (between gateways).
  • Terminology for "Context ID" and "Session ID" has been added to the architecture document, with the expectation that these definitions will eventually be moved into a dedicated terminology document for the working group.
  • The latest version of the core document now explicitly includes a "Session ID" in every flow. This Session ID is intended to remain constant throughout a session, uniquely identifying the instance of the transfer, and allowing assets to be bound to it without needing to be repeated in each message.
  • A suggestion was made to define the "lock assertion" JSON in a way that allows for an optional network-specific or vendor-specific body, enabling the inclusion of unique cryptographic proofs from the origin network.
  • Initial queries arose regarding the determination of the Session ID in a "Stage 0" phase, with Thomas noting that this is often application-driven and happens "out of band" from the core SATP protocol.
• Pre-SATP "Stage 0" Flow Proposal (Dennis):
  • Dennis presented a potential sequence diagram outlining a "Stage 0" process that would occur before the SATP protocol is initiated. The goal of this stage is to establish preconditions necessary for SATP, such as how gateways connect and how assets are bound to a transfer context.
  • Proposed Flow Highlights:
    1. Client 1 requests a transfer from Gateway 1.
    2. Gateway 1 provides a "transfer context" (a unique identifier, potentially signed by the Gateway).
    3. Client 1 binds the assets to be transferred to this context within its local network/DLT.
    4. Client 1 communicates the transfer context to Client 2.
    5. Client 1 instructs Gateway 1 to begin the transfer.
    6. Client 2's local system is notified of an incoming transfer.
    7. Client 2 provides the transfer context to Gateway 2.
    8. Gateway 2 contacts Gateway 1, returning the context, enabling the gateways to connect and recognize the transfer.
    9. The SATP protocol (in gray box) then commences between Gateway 1 and Gateway 2.
    10. Clients can subsequently query their respective gateways for the transfer's completion status.
  • Discussion on Stage 0:
    • The "transfer context" could be a composite data structure (e.g., JSON) including the session ID and other relevant information.
    • Clarification was provided that the "session ID" uniquely identifies the instance of the transfer, not necessarily the asset itself. Assets are bound to this transfer context.
    • The chair reiterated the working group's focus on the core SATP protocol and the need to avoid getting "lost in the detail" of pre-SATP negotiation. While Stage 0 is important for context, the WG's deliverables should focus on SATP.
    • Thomas noted that the SATP core document still alludes to Type 1 APIs (application to gateway) from earlier versions but lacks detailed text.
    • There was a shared understanding that while a detailed protocol for Stage 0 might be out of scope, the preconditions or post-conditions of Stage 0 (i.e., what state the gateways must be in, and what information must be available to them) are critical for SATP to function and therefore need to be explicitly defined.

Decisions and Action Items

• Decision: The working group will define the preconditions required for the SATP protocol to commence, outlining the necessary information and state that must be established during a pre-SATP "Stage 0." The group will focus on these preconditions rather than specifying a detailed Stage 0 protocol flow. (A sense of those present indicated agreement on this approach.)
• Action Item (Thomas, Rama, Dennis, Alex, Martin): Authors of the architecture, core protocol, terminology, and use cases drafts are requested to submit their most up-to-date versions to the chairs by Wednesday, March 29th, to allow for pre-upload and preparation for the IETF 116 session.
• Action Item (Dennis): Refine the "Stage 0" proposal to describe the preconditions or post-conditions of Stage 0 that are essential for SATP. This revised description will be discussed on the mailing list. Dennis will also email the presented diagram to the mailing list.
• Action Item (Alex and Dennis): Coordinate offline on GitHub to collaboratively edit and compile the terminology document, taking ownership of the editing process based on group submissions and consensus.
• Action Item (Thomas): Reach out to individuals who have requested flip-flopping time zones for interim meetings (particularly in Australia and Pacific US) to gather preferred timings. The chair will then assess options.
• Action Item (Volunteer): A note-taker was assigned for this official interim meeting (unnamed in transcript, but requested by chair).

Next Steps

• The next working group session will be held at IETF 116 in Yokohama, Japan, on Friday, March 31st, starting at 9 AM Japan time for a two-hour slot.
• Document authors (Thomas, Rama, Dennis, and others) are expected to prepare brief (5-minute) introductions to their respective drafts, followed by open floor discussion by the working group.
• The mailing list will be used for continued discussion on the preconditions for SATP as refined by Dennis.
• The chairs will explore options for adjusting interim meeting time zones to accommodate participants in different geographic regions.
• Participants are encouraged to ensure they have registered for IETF 116.
• Any additional agenda points for the IETF 116 session should be communicated to the chairs.