[OPS-DIR]draft-ietf-satp-usecases-10 ietf last call Opsdir review

[Dan Voyer via Datatracker <[e-mail]>]

Document: draft-ietf-satp-usecases
Title: Secure Asset Transfer (SAT) Use Cases
Reviewer: Dan Voyer
Review result: Has Issues

Document: draft-ietf-satp-usecases-10
Reviewer: Daniel Voyer
Review Date: 2026-09-30
Review Type: OPSDIR IETF Last Call
Summary: Has Issues
I have reviewed this document as part of the Operations Directorate review
process. Please treat these comments as Last Call comments. The document
provides useful background for the SATP work. I found no major operational
issues. I have also read the Gen-ART review. The comments below focus on
additional operational aspects.

Major issues: None.

Minor issues:
1. Sections 2, 4.4, 5.2 and 7: current protocol capabilities
Please distinguish examples directly supported by the current SATP Core
protocol from use cases requiring future interoperability specifications or
application-level coordination. Section 6 of draft-ietf-satp-architecture-10
leaves data sharing and asset exchange to future specifications, while Section
1 of draft-ietf-satp-core-17 describes unidirectional asset transfer. A short
scope statement in Section 7, with corresponding wording adjustments in the
examples, would avoid implying that the current core protocol provides all
these functions.

2. Section 4.3, Figure 6: payment direction
Both the bond and currency transfers are shown from Bank A to Bank B. For the
DvP exchange described here, payment should flow from Bank B to Bank A in
return for the bond. Please reverse the currency-transfer arrow or swap the
account labels in the payment panel.

3. Section 6: coordination with EPP
The example makes token transfer a prerequisite to the EPP operation and says
SATP logs can reveal EPP non-fulfilment. Please briefly identify the
application-level responsibility for correlating EPP outcomes with SATP
evidence and reconciling an EPP operation that remains pending or fails after
token transfer. EPP allows pending, rejected and cancelled transfers (RFC 5731,
Sections 3.2 and 3.2.4); these outcomes do not by themselves establish
registrar non-compliance. Please qualify the detection claim accordingly. A
high-level coordination assumption would suffice; this does not require
specifying the integration protocol in this document.

Thanks,
Dan