Markdown Version | Session Recording
Session Date/Time: 18 Jun 2024 14:00
SATP
Summary
The SATP Working Group held an interim meeting to discuss the progress of its core documents. Key discussions focused on the satp-architecture document's readiness for Working Group Last Call (WGLC) and several critical aspects of the satp-core document. Consensus was reached to initiate WGLC for the architecture document. For the core document, significant progress was made on clarifying the roles of negotiation stages (Stage 0 vs. Stage 1), defining identifier management (transfer context, session ID), and handling explicit acceptance/rejection in the protocol.
Key Discussion Points
- SATP Architecture Document Status:
draft-ietf-satp-architecture-05was identified as ready for WGLC.- The primary recent update was a diagram change suggested by Dennis and implemented by Thomas.
- SATP Core Document - Negotiation Stages:
- Extensive discussion on whether multi-round negotiation (proposal/counter-proposal) should occur within Stage 1 of the core protocol.
- A proposal was made to move detailed negotiation of transfer parameters to "Stage 0" (a pre-Stage 1 phase), which could be an offline or separate protocol.
- The goal for Stage 1 would be a rapid, "trigger-pull" execution, assuming prior agreement on all parameters.
- If negotiation moves to Stage 0, Stage 1 would primarily need explicit acceptance or rejection mechanisms.
- SATP Core Document - Identifier Management:
- Discussion arose regarding a "client number" field in messages versus the existing "session ID." There was a sense that the "client number" was redundant if "session ID" serves a similar purpose.
- Dennis suggested introducing a "transfer context" as a unique, immutable identifier for a complete transfer instance. This transfer context could be a complex data structure containing various IDs, including multiple session IDs (e.g., for recovery scenarios) and asset/network identifiers.
- Thomas clarified the current draft's concept where a context ID (application-layer) could map to multiple SATP session IDs for grouped or bidirectional transfers.
- The group acknowledged the need for a clear, immutable ID to reference a transfer instance, especially for recovery and tracking.
- SATP Core Document - Diagram Alignment:
- Dennis pointed out a missing arrow in the
satp-coredocument's diagram (Section 4.1) from "client to network," which is present in the updatedsatp-architecturedocument's diagram (Section 5.5). It was agreed this should be aligned.
- Dennis pointed out a missing arrow in the
- SATP Core Document - Vendor and IETF Extensions:
- Discussion on how to accommodate vendor-specific extensions and future IETF extensions in the protocol messages.
- Suggestions included defining a placeholder for additional payloads, using naming conventions (e.g.,
vendor:field), and including rules for handling unrecognized fields (e.g., "ignore if not understood"). - The importance of versioning (e.g.,
V1) for future compatibility was noted. - Consideration was given to mandatory-to-recognize fields that would require session abortion if not understood.
- SATP Core Document - Review Feedback:
- A reminder to authors to revisit comments from the HTTP directorate on earlier versions of the
satp-coredraft, as some issues might still be relevant despite significant changes. - The chair indicated an intention to request an early security directorate review due to the protocol's security implications.
- A reminder to authors to revisit comments from the HTTP directorate on earlier versions of the
- SATP Core Document - Settlement Finality:
- A brief discussion ensued regarding the distinction between the protocol's technical consistency (ACID properties, rollback on failure) and the legal or business implications of transaction commitment and "settlement finality."
- It was recognized that while SATP ensures technical consistency, the legal recourse for failures after a certain "Tipping Point" in the transaction is outside the IETF's scope but an important consideration for deployers.
Decisions and Action Items
- Decision: Initiate Working Group Last Call (WGLC) for
draft-ietf-satp-architecture-05. The WGLC period will be approximately four weeks. - Decision (SATP Core Document): The multi-round counter-proposal mechanism will be removed from Stage 1 of the core protocol. Negotiation of transfer parameters will be considered part of Stage 0 (pre-Stage 1).
- Decision (SATP Core Document): Stage 1 will include explicit "accept" and "reject" messages instead of counter-proposals.
- Action Item (Dennis): Draft a proposal on the definition and usage of session ID, transaction ID, and the "transfer context" for the core document, including how it modifies the existing text, and send it to the mailing list for further discussion.
- Action Item (SATP Core Document Authors): Update the diagram in Section 4.1 of the core document to include an arrow from "client to network," aligning it with the diagram in Section 5.5 of the architecture document.
- Action Item (SATP Core Document Authors): Incorporate mechanisms for vendor-specific and future IETF extensions into the core document's message structures (e.g., versioning, explicit extension points, rules for handling unknown fields).
- Action Item (SATP Core Document Authors): Review and address any still-relevant comments from the HTTP directorate's previous review of the core document.
Next Steps
- The WGLC for
draft-ietf-satp-architecture-05will commence shortly. - Continue work on the
satp-coredocument based on the action items and discussions, particularly regarding negotiation stages, identifier management, and extension mechanisms. - Further discussion on the legal and business implications of settlement finality and transaction commitment, possibly at the IETF 120 meeting in Vancouver.