Session Date/Time: 11 Jul 2023 14:00

SATP

Summary

The SATP Working Group met to discuss updates on the vocabulary, architecture, and message flow drafts, as well as progress on session resumption. Key technical changes to the message flow (version 19) and sat-core (version 02) were presented, including modifications to Stage 1 negotiation and Stage 3 commit procedures. Plans for presentations and informal gatherings at IETF 117 in San Francisco were also discussed.

Key Discussion Points

Vocabulary Draft Progress: Alex reported progress on making the vocabulary document a standalone draft rather than an appendix. He is working on the XML drafting process and will send an email to the mailing list for review shortly.
Architecture and Use Cases Draft Updates: Rama provided minor updates, noting text added to the architecture draft comparing SATP with ISO 20022. He also referenced a Bank for International Settlements (BIS) report highlighting limitations of current messaging schemes for tokenization, indicating SATP's relevance. He also has an update for the use cases draft. Due to the draft upload cutoff, these updates will be submitted on the Monday of the IETF week.
Message Flow Diagram (v19) and sat-core-02 Revisions (Thomas):
- Stage 1 Changes:
  - The "transfer commence" message and its acknowledgment have been moved to Stage 1. This re-prioritizes Stage 2 to exclusively focus on the locking and lock assertion mechanism, while Stage 1 covers all initial preparation and agreement.
  - sat-core-02 introduces a "Transfer Proposal Claims" section (7.1) for agreement on asset-related information (e.g., identities, addresses) and a "Network Capability Claims" section (7.2) for network-specific details (e.g., locking mechanism, lock duration).
  - A multi-round negotiation loop (sections 7.3-7.5) was introduced for G1 and G2 to agree on claims. This includes:
    - Transfer Proposal (G1 proposes claims).
    - Transfer Proposal Receipt (G2 acceptance, suggested renaming to Transfer Proposal Acceptance for clarity).
    - Conditional rejection with a counter-proposal (G2 suggests alternative claims).
    - Explicit Transfer Proposal Reject (G2 terminates negotiation).
  - The mechanism for gateways to handle counter-proposals (e.g., using policy databases) was discussed, and suggestions for refining the loop expression are welcome.
- Stage 3 Changes:
  - The "Acknowledgment Prepare" (3.2) message was deemed redundant for unidirectional one-to-one asset transfers and has been grayed out in the diagram, with plans for its removal in the next version (v20). The current scope of SATP is explicitly unidirectional, one-sender, one-receiver.
  - Discussion around the "heuristic deadlock state" (message 3.5 commit prepare) led to clarification that "deadlock" is too strong a term. The issue describes an "awkward and stuck state" where an asset is extinguished in Network 1 but self-assigned to G2 in Network 2 (not Bob) if G2 crashes before receiving 3.5.
  - The importance of transport reliability for message 3.5 was emphasized, as well as implications for crash recovery.
Session Resumption (Raphael):
- Progress on Section 10 of sat-core-02 regarding session resumption, supported by an implementation in Hyperledger Cacti.
- The proposed mechanism is based on a primary-backup model, where backup gateways are defined during setup.
- New messages (recover, recover-update, recover-success) are defined to manage the state alignment between a recovering gateway (or its backup) and the counterparty.
- The full details of the crash recovery mechanism itself are currently considered out of scope for the SATP core draft, but the core design is informed by such architectures. Further details are being ported from academic work to a separate crash recovery draft.
Asset Movement in Burn-and-Mint Model: David questioned where the asset "moves" from G1 to G2. Thomas and Alex clarified that in the burn-and-mint model, the asset is formally moved by message 3.7. The asset exists simultaneously on both networks for a period (mint-then-burn), and the effective "move" occurs when it is deleted from the initial network.
Hyperledger Cacti Implementation: Rama highlighted that a project under the Hyperledger Cacti mentorship program is actively working on implementing SATP using Relay-Company-3 gateway components, and feedback on ease of implementation will be shared.
IETF 117 Logistics: The SATP WG session is scheduled for Thursday morning, July 27th, at IETF 117 in San Francisco. Attendees were invited to an informal group lunch.

Decisions and Action Items

Alex: Send an email to the mailing list for review of the vocabulary draft once the XML drafting process is complete.
Rama: Upload updated architecture and use cases drafts on the Monday of IETF 117. Send link/PDF of the BIS report to interested parties on the mailing list.
Thomas: Update the message flow diagram and sat-core document to replace "deadlock" with "heuristic state" or similar appropriate terminology for the stuck state.
Working Group: Continue work on the three core SATP drafts (core, architecture, use cases) while also continuing development on related drafts like crash recovery, which may be formally adopted later.
All Attendees: Prepare for presentations and discussions at the IETF 117 session.

Next Steps

Present detailed updates on sat-core-02 (message flow changes, session resumption) and other drafts at the IETF 117 meeting in San Francisco.
Engage in further discussion on refining the negotiation loop mechanism in Stage 1 and the specific content of session resumption messages.
Gather feedback on the ongoing Hyperledger Cacti implementation of SATP.

Session Date/Time: 11 Jul 2023 14:00

SATP

Summary

Key Discussion Points

Vocabulary Draft Progress: Alex reported progress on making the vocabulary document a standalone draft rather than an appendix. He is working on the XML drafting process and will send an email to the mailing list for review shortly.
Architecture and Use Cases Draft Updates: Rama provided minor updates, noting text added to the architecture draft comparing SATP with ISO 20022. He also referenced a Bank for International Settlements (BIS) report highlighting limitations of current messaging schemes for tokenization, indicating SATP's relevance. He also has an update for the use cases draft. Due to the draft upload cutoff, these updates will be submitted on the Monday of the IETF week.
Message Flow Diagram (v19) and sat-core-02 Revisions (Thomas):
- Stage 1 Changes:
  - The "transfer commence" message and its acknowledgment have been moved to Stage 1. This re-prioritizes Stage 2 to exclusively focus on the locking and lock assertion mechanism, while Stage 1 covers all initial preparation and agreement.
  - sat-core-02 introduces a "Transfer Proposal Claims" section (7.1) for agreement on asset-related information (e.g., identities, addresses) and a "Network Capability Claims" section (7.2) for network-specific details (e.g., locking mechanism, lock duration).
  - A multi-round negotiation loop (sections 7.3-7.5) was introduced for G1 and G2 to agree on claims. This includes:
    - Transfer Proposal (G1 proposes claims).
    - Transfer Proposal Receipt (G2 acceptance, suggested renaming to Transfer Proposal Acceptance for clarity).
    - Conditional rejection with a counter-proposal (G2 suggests alternative claims).
    - Explicit Transfer Proposal Reject (G2 terminates negotiation).
  - The mechanism for gateways to handle counter-proposals (e.g., using policy databases) was discussed, and suggestions for refining the loop expression are welcome.
- Stage 3 Changes:
  - The "Acknowledgment Prepare" (3.2) message was deemed redundant for unidirectional one-to-one asset transfers and has been grayed out in the diagram, with plans for its removal in the next version (v20). The current scope of SATP is explicitly unidirectional, one-sender, one-receiver.
  - Discussion around the "heuristic deadlock state" (message 3.5 commit prepare) led to clarification that "deadlock" is too strong a term. The issue describes an "awkward and stuck state" where an asset is extinguished in Network 1 but self-assigned to G2 in Network 2 (not Bob) if G2 crashes before receiving 3.5.
  - The importance of transport reliability for message 3.5 was emphasized, as well as implications for crash recovery.
Session Resumption (Raphael):
- Progress on Section 10 of sat-core-02 regarding session resumption, supported by an implementation in Hyperledger Cacti.
- The proposed mechanism is based on a primary-backup model, where backup gateways are defined during setup.
- New messages (recover, recover-update, recover-success) are defined to manage the state alignment between a recovering gateway (or its backup) and the counterparty.
- The full details of the crash recovery mechanism itself are currently considered out of scope for the SATP core draft, but the core design is informed by such architectures. Further details are being ported from academic work to a separate crash recovery draft.
Asset Movement in Burn-and-Mint Model: David questioned where the asset "moves" from G1 to G2. Thomas and Alex clarified that in the burn-and-mint model, the asset is formally moved by message 3.7. The asset exists simultaneously on both networks for a period (mint-then-burn), and the effective "move" occurs when it is deleted from the initial network.
Hyperledger Cacti Implementation: Rama highlighted that a project under the Hyperledger Cacti mentorship program is actively working on implementing SATP using Relay-Company-3 gateway components, and feedback on ease of implementation will be shared.
IETF 117 Logistics: The SATP WG session is scheduled for Thursday morning, July 27th, at IETF 117 in San Francisco. Attendees were invited to an informal group lunch.

Decisions and Action Items

Alex: Send an email to the mailing list for review of the vocabulary draft once the XML drafting process is complete.
Rama: Upload updated architecture and use cases drafts on the Monday of IETF 117. Send link/PDF of the BIS report to interested parties on the mailing list.
Thomas: Update the message flow diagram and sat-core document to replace "deadlock" with "heuristic state" or similar appropriate terminology for the stuck state.
Working Group: Continue work on the three core SATP drafts (core, architecture, use cases) while also continuing development on related drafts like crash recovery, which may be formally adopted later.
All Attendees: Prepare for presentations and discussions at the IETF 117 session.

Next Steps

Present detailed updates on sat-core-02 (message flow changes, session resumption) and other drafts at the IETF 117 meeting in San Francisco.
Engage in further discussion on refining the negotiation loop mechanism in Stage 1 and the specific content of session resumption messages.
Gather feedback on the ongoing Hyperledger Cacti implementation of SATP.

Session Date/Time: 11 Jul 2023 14:00

SATP

Summary

Key Discussion Points

Vocabulary Draft Progress: Alex reported progress on making the vocabulary document a standalone draft rather than an appendix. He is working on the XML drafting process and will send an email to the mailing list for review shortly.
Architecture and Use Cases Draft Updates: Rama provided minor updates, noting text added to the architecture draft comparing SATP with ISO 20022. He also referenced a Bank for International Settlements (BIS) report highlighting limitations of current messaging schemes for tokenization, indicating SATP's relevance. He also has an update for the use cases draft. Due to the draft upload cutoff, these updates will be submitted on the Monday of the IETF week.
Message Flow Diagram (v19) and sat-core-02 Revisions (Thomas):
- Stage 1 Changes:
  - The "transfer commence" message and its acknowledgment have been moved to Stage 1. This re-prioritizes Stage 2 to exclusively focus on the locking and lock assertion mechanism, while Stage 1 covers all initial preparation and agreement.
  - sat-core-02 introduces a "Transfer Proposal Claims" section (7.1) for agreement on asset-related information (e.g., identities, addresses) and a "Network Capability Claims" section (7.2) for network-specific details (e.g., locking mechanism, lock duration).
  - A multi-round negotiation loop (sections 7.3-7.5) was introduced for G1 and G2 to agree on claims. This includes:
    - Transfer Proposal (G1 proposes claims).
    - Transfer Proposal Receipt (G2 acceptance, suggested renaming to Transfer Proposal Acceptance for clarity).
    - Conditional rejection with a counter-proposal (G2 suggests alternative claims).
    - Explicit Transfer Proposal Reject (G2 terminates negotiation).
  - The mechanism for gateways to handle counter-proposals (e.g., using policy databases) was discussed, and suggestions for refining the loop expression are welcome.
- Stage 3 Changes:
  - The "Acknowledgment Prepare" (3.2) message was deemed redundant for unidirectional one-to-one asset transfers and has been grayed out in the diagram, with plans for its removal in the next version (v20). The current scope of SATP is explicitly unidirectional, one-sender, one-receiver.
  - Discussion around the "heuristic deadlock state" (message 3.5 commit prepare) led to clarification that "deadlock" is too strong a term. The issue describes an "awkward and stuck state" where an asset is extinguished in Network 1 but self-assigned to G2 in Network 2 (not Bob) if G2 crashes before receiving 3.5.
  - The importance of transport reliability for message 3.5 was emphasized, as well as implications for crash recovery.
Session Resumption (Raphael):
- Progress on Section 10 of sat-core-02 regarding session resumption, supported by an implementation in Hyperledger Cacti.
- The proposed mechanism is based on a primary-backup model, where backup gateways are defined during setup.
- New messages (recover, recover-update, recover-success) are defined to manage the state alignment between a recovering gateway (or its backup) and the counterparty.
- The full details of the crash recovery mechanism itself are currently considered out of scope for the SATP core draft, but the core design is informed by such architectures. Further details are being ported from academic work to a separate crash recovery draft.
Asset Movement in Burn-and-Mint Model: David questioned where the asset "moves" from G1 to G2. Thomas and Alex clarified that in the burn-and-mint model, the asset is formally moved by message 3.7. The asset exists simultaneously on both networks for a period (mint-then-burn), and the effective "move" occurs when it is deleted from the initial network.
Hyperledger Cacti Implementation: Rama highlighted that a project under the Hyperledger Cacti mentorship program is actively working on implementing SATP using Relay-Company-3 gateway components, and feedback on ease of implementation will be shared.
IETF 117 Logistics: The SATP WG session is scheduled for Thursday morning, July 27th, at IETF 117 in San Francisco. Attendees were invited to an informal group lunch.

Decisions and Action Items

Alex: Send an email to the mailing list for review of the vocabulary draft once the XML drafting process is complete.
Rama: Upload updated architecture and use cases drafts on the Monday of IETF 117. Send link/PDF of the BIS report to interested parties on the mailing list.
Thomas: Update the message flow diagram and sat-core document to replace "deadlock" with "heuristic state" or similar appropriate terminology for the stuck state.
Working Group: Continue work on the three core SATP drafts (core, architecture, use cases) while also continuing development on related drafts like crash recovery, which may be formally adopted later.
All Attendees: Prepare for presentations and discussions at the IETF 117 session.

Next Steps

Present detailed updates on sat-core-02 (message flow changes, session resumption) and other drafts at the IETF 117 meeting in San Francisco.
Engage in further discussion on refining the negotiation loop mechanism in Stage 1 and the specific content of session resumption messages.
Gather feedback on the ongoing Hyperledger Cacti implementation of SATP.

Session Date/Time: 11 Jul 2023 14:00

SATP

Summary

Key Discussion Points

Vocabulary Draft Progress: Alex reported progress on making the vocabulary document a standalone draft rather than an appendix. He is working on the XML drafting process and will send an email to the mailing list for review shortly.
Architecture and Use Cases Draft Updates: Rama provided minor updates, noting text added to the architecture draft comparing SATP with ISO 20022. He also referenced a Bank for International Settlements (BIS) report highlighting limitations of current messaging schemes for tokenization, indicating SATP's relevance. He also has an update for the use cases draft. Due to the draft upload cutoff, these updates will be submitted on the Monday of the IETF week.
Message Flow Diagram (v19) and sat-core-02 Revisions (Thomas):
- Stage 1 Changes:
  - The "transfer commence" message and its acknowledgment have been moved to Stage 1. This re-prioritizes Stage 2 to exclusively focus on the locking and lock assertion mechanism, while Stage 1 covers all initial preparation and agreement.
  - sat-core-02 introduces a "Transfer Proposal Claims" section (7.1) for agreement on asset-related information (e.g., identities, addresses) and a "Network Capability Claims" section (7.2) for network-specific details (e.g., locking mechanism, lock duration).
  - A multi-round negotiation loop (sections 7.3-7.5) was introduced for G1 and G2 to agree on claims. This includes:
    - Transfer Proposal (G1 proposes claims).
    - Transfer Proposal Receipt (G2 acceptance, suggested renaming to Transfer Proposal Acceptance for clarity).
    - Conditional rejection with a counter-proposal (G2 suggests alternative claims).
    - Explicit Transfer Proposal Reject (G2 terminates negotiation).
  - The mechanism for gateways to handle counter-proposals (e.g., using policy databases) was discussed, and suggestions for refining the loop expression are welcome.
- Stage 3 Changes:
  - The "Acknowledgment Prepare" (3.2) message was deemed redundant for unidirectional one-to-one asset transfers and has been grayed out in the diagram, with plans for its removal in the next version (v20). The current scope of SATP is explicitly unidirectional, one-sender, one-receiver.
  - Discussion around the "heuristic deadlock state" (message 3.5 commit prepare) led to clarification that "deadlock" is too strong a term. The issue describes an "awkward and stuck state" where an asset is extinguished in Network 1 but self-assigned to G2 in Network 2 (not Bob) if G2 crashes before receiving 3.5.
  - The importance of transport reliability for message 3.5 was emphasized, as well as implications for crash recovery.
Session Resumption (Raphael):
- Progress on Section 10 of sat-core-02 regarding session resumption, supported by an implementation in Hyperledger Cacti.
- The proposed mechanism is based on a primary-backup model, where backup gateways are defined during setup.
- New messages (recover, recover-update, recover-success) are defined to manage the state alignment between a recovering gateway (or its backup) and the counterparty.
- The full details of the crash recovery mechanism itself are currently considered out of scope for the SATP core draft, but the core design is informed by such architectures. Further details are being ported from academic work to a separate crash recovery draft.
Asset Movement in Burn-and-Mint Model: David questioned where the asset "moves" from G1 to G2. Thomas and Alex clarified that in the burn-and-mint model, the asset is formally moved by message 3.7. The asset exists simultaneously on both networks for a period (mint-then-burn), and the effective "move" occurs when it is deleted from the initial network.
Hyperledger Cacti Implementation: Rama highlighted that a project under the Hyperledger Cacti mentorship program is actively working on implementing SATP using Relay-Company-3 gateway components, and feedback on ease of implementation will be shared.
IETF 117 Logistics: The SATP WG session is scheduled for Thursday morning, July 27th, at IETF 117 in San Francisco. Attendees were invited to an informal group lunch.

Decisions and Action Items

Alex: Send an email to the mailing list for review of the vocabulary draft once the XML drafting process is complete.
Rama: Upload updated architecture and use cases drafts on the Monday of IETF 117. Send link/PDF of the BIS report to interested parties on the mailing list.
Thomas: Update the message flow diagram and sat-core document to replace "deadlock" with "heuristic state" or similar appropriate terminology for the stuck state.
Working Group: Continue work on the three core SATP drafts (core, architecture, use cases) while also continuing development on related drafts like crash recovery, which may be formally adopted later.
All Attendees: Prepare for presentations and discussions at the IETF 117 session.

Next Steps

Present detailed updates on sat-core-02 (message flow changes, session resumption) and other drafts at the IETF 117 meeting in San Francisco.
Engage in further discussion on refining the negotiation loop mechanism in Stage 1 and the specific content of session resumption messages.
Gather feedback on the ongoing Hyperledger Cacti implementation of SATP.

Session Date/Time: 11 Jul 2023 14:00

SATP

Summary

Key Discussion Points

Vocabulary Draft Progress: Alex reported progress on making the vocabulary document a standalone draft rather than an appendix. He is working on the XML drafting process and will send an email to the mailing list for review shortly.
Architecture and Use Cases Draft Updates: Rama provided minor updates, noting text added to the architecture draft comparing SATP with ISO 20022. He also referenced a Bank for International Settlements (BIS) report highlighting limitations of current messaging schemes for tokenization, indicating SATP's relevance. He also has an update for the use cases draft. Due to the draft upload cutoff, these updates will be submitted on the Monday of the IETF week.
Message Flow Diagram (v19) and sat-core-02 Revisions (Thomas):
- Stage 1 Changes:
  - The "transfer commence" message and its acknowledgment have been moved to Stage 1. This re-prioritizes Stage 2 to exclusively focus on the locking and lock assertion mechanism, while Stage 1 covers all initial preparation and agreement.
  - sat-core-02 introduces a "Transfer Proposal Claims" section (7.1) for agreement on asset-related information (e.g., identities, addresses) and a "Network Capability Claims" section (7.2) for network-specific details (e.g., locking mechanism, lock duration).
  - A multi-round negotiation loop (sections 7.3-7.5) was introduced for G1 and G2 to agree on claims. This includes:
    - Transfer Proposal (G1 proposes claims).
    - Transfer Proposal Receipt (G2 acceptance, suggested renaming to Transfer Proposal Acceptance for clarity).
    - Conditional rejection with a counter-proposal (G2 suggests alternative claims).
    - Explicit Transfer Proposal Reject (G2 terminates negotiation).
  - The mechanism for gateways to handle counter-proposals (e.g., using policy databases) was discussed, and suggestions for refining the loop expression are welcome.
- Stage 3 Changes:
  - The "Acknowledgment Prepare" (3.2) message was deemed redundant for unidirectional one-to-one asset transfers and has been grayed out in the diagram, with plans for its removal in the next version (v20). The current scope of SATP is explicitly unidirectional, one-sender, one-receiver.
  - Discussion around the "heuristic deadlock state" (message 3.5 commit prepare) led to clarification that "deadlock" is too strong a term. The issue describes an "awkward and stuck state" where an asset is extinguished in Network 1 but self-assigned to G2 in Network 2 (not Bob) if G2 crashes before receiving 3.5.
  - The importance of transport reliability for message 3.5 was emphasized, as well as implications for crash recovery.
Session Resumption (Raphael):
- Progress on Section 10 of sat-core-02 regarding session resumption, supported by an implementation in Hyperledger Cacti.
- The proposed mechanism is based on a primary-backup model, where backup gateways are defined during setup.
- New messages (recover, recover-update, recover-success) are defined to manage the state alignment between a recovering gateway (or its backup) and the counterparty.
- The full details of the crash recovery mechanism itself are currently considered out of scope for the SATP core draft, but the core design is informed by such architectures. Further details are being ported from academic work to a separate crash recovery draft.
Asset Movement in Burn-and-Mint Model: David questioned where the asset "moves" from G1 to G2. Thomas and Alex clarified that in the burn-and-mint model, the asset is formally moved by message 3.7. The asset exists simultaneously on both networks for a period (mint-then-burn), and the effective "move" occurs when it is deleted from the initial network.
Hyperledger Cacti Implementation: Rama highlighted that a project under the Hyperledger Cacti mentorship program is actively working on implementing SATP using Relay-Company-3 gateway components, and feedback on ease of implementation will be shared.
IETF 117 Logistics: The SATP WG session is scheduled for Thursday morning, July 27th, at IETF 117 in San Francisco. Attendees were invited to an informal group lunch.

Decisions and Action Items

Alex: Send an email to the mailing list for review of the vocabulary draft once the XML drafting process is complete.
Rama: Upload updated architecture and use cases drafts on the Monday of IETF 117. Send link/PDF of the BIS report to interested parties on the mailing list.
Thomas: Update the message flow diagram and sat-core document to replace "deadlock" with "heuristic state" or similar appropriate terminology for the stuck state.
Working Group: Continue work on the three core SATP drafts (core, architecture, use cases) while also continuing development on related drafts like crash recovery, which may be formally adopted later.
All Attendees: Prepare for presentations and discussions at the IETF 117 session.

Next Steps

Present detailed updates on sat-core-02 (message flow changes, session resumption) and other drafts at the IETF 117 meeting in San Francisco.
Engage in further discussion on refining the negotiation loop mechanism in Stage 1 and the specific content of session resumption messages.
Gather feedback on the ongoing Hyperledger Cacti implementation of SATP.