IETF Last Call Review of draft-ietf-satp-architecture-10
review-ietf-satp-architecture-10-opsdir-lc-p-2026-10-05-00

Hi,

I have been selected as the Operational Directorate (opsdir) reviewer for this
Internet-Draft.

The Operational Directorate reviews all operational and management-related
Internet-Drafts to ensure alignment with operational best practices and that
adequate operational considerations are covered.

A complete set of _"Guidelines for Considering Operations and Management in
IETF Specifications"_ can be found at
https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5706bis/.

While these comments are primarily for the Operations and Management Area
Directors (Ops ADs), the authors should consider them alongside other feedback
received.

- Document: draft-ietf-satp-architecture-10

- Reviewer: Michael P

- Review Date: 2026-10-05

- Intended Status: Informational

---

## Minor Issues

Thank you for the effort that has gone into this document. I've got a few
points of feedback, all of which I'd consider minor and hope they can support
the document.

From an opsdir perspective, it would be nice to see an Operational
Considerations section alongside the Security, Policy and Compatibility
sections. As acknowledged in
https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5706bis/, this is only
useful in architecture documents where new operational considerations with
normative implications for downstream protocol designs are introduced. I do
think this is the case here, there is already some mention of crash recovery,
logging to recover from failure in the 2PC subprotocol, managing load, so I do
think worth collecting such considerations in their own section. I'd see this
as a nit, rather than an issue.

Section 5 outlines assumptions. I think it would be useful for readers to have
a bit more on how these could be or are currently achieved in practice, even if
just a couple of references.

The main issue that I'll raise is in the strength of some requirements. For
example, in Section 9, we have "several steps that may occur in Stage 1",
including Secure channel establishment, Transfer Proposal message etc. The
current reading of that is that some of those steps could be removed, done
elsewhere, or optionally included. I think the document can be more
prescriptive on which steps are required for the protocol to complete with the
required properties.

On references, this document "seeks to rely on ISO 20022". I think worth
highlighting whether the relevant parts of the standards are open to those who
would operate this protocol if they are needed.

Question on clarity of security properties, which impacts the management of
gateway identities - one part of the document calls for secure channel
establishment which includes mutual verification of device identities. Another
part says we MUST use TLS1.3. Does this enforce use of mTLS or is the intention
to be able to verify identity using other mechanisms? If the latter, examples
may be useful.

---