comparison satp-core-review.txt @ 23:2eda17d4debf default tip

as submitted
author Henry S. Thompson <ht@inf.ed.ac.uk>
date Wed, 21 Oct 2026 17:24:38 +0100
parents f2743a0a4eb7
children
comparison
equal deleted inserted replaced
22:f2743a0a4eb7 23:2eda17d4debf
1 https://datatracker.ietf.org/doc/draft-ietf-satp-core/ 1 https://datatracker.ietf.org/doc/draft-ietf-satp-core/
2 Document: https://www.ietf.org/archive/id/draft-ietf-satp-core-17.html 2 Document: https://www.ietf.org/archive/id/draft-ietf-satp-core-17.html
3 Title: Secure Asset Transfer Protocol (SATP) Core 3 Title: Secure Asset Transfer Protocol (SATP) Core
4 Reviewer: Henry S. Thompson 4 Reviewer: Henry S. Thompson
5 Review Date: Mon Oct 19 13:48:49 2026 5 Review Date: Wed Oct 21 17:12:16 2026
6 6
7 *Summary* 7 *Summary*
8
9 As far as I can tell as a non-specialist, the ... is in good shape.
10 There are ... below.
11 8
12 This draft is part of a package of at least three parts, including 9 This draft is part of a package of at least three parts, including
13 also _Secure Asset Transfer (SAT) Interoperability Architecture_ and 10 also _Secure Asset Transfer (SAT) Interoperability Architecture_ and
14 _Secure Asset Transfer (SAT) Use Cases_. 11 _Secure Asset Transfer (SAT) Use Cases_.
12
13 Its aim is to present a concrete instantiation of the SAT
14 Interoperability Architecture in terms of a specific set of message
15 formats. As far as I can tell as a non-specialist, it achieves that
16 goal.
17
18 But in my opinion it needs work on the presentation, particularly in
19 the area of consistency and transparency of terminology, both
20 internally and in relation to the terminology established by the SAT
21 Interoperability Architecture, which I take to be the senior party in
22 the trilogy.
23
24 All of my comments below under 'Minor points' bar the very first are
25 there, rather than under a more serious heading, only because this is
26 a matter of presentation, not substance, but I think it's important
27 that they be addressed.
15 28
16 *Minor points* 29 *Minor points*
17 30
18 1. 31 1.
19 32
73 TLS schemes. 86 TLS schemes.
74 87
75 Also, later on the terminology used changes from 'recipient gateway' 88 Also, later on the terminology used changes from 'recipient gateway'
76 to 'receiver gateway' -- this should be reverted throughout. 89 to 'receiver gateway' -- this should be reverted throughout.
77 90
78 I've listed all this as 'minor' only because it is a matter of
79 terminology, but I think it's important to fix it.
80
81 5.4.1 91 5.4.1
82 92
83 See above. Here's a simpler version of this whole section: 93 See above. Here's a simpler version of this whole section:
84 94
85 5.4.1. Protocol requirements 95 5.4.1. Protocol requirements
123 133
124 It's never made clear if this just e.g. requires *Transfer Proposal 134 It's never made clear if this just e.g. requires *Transfer Proposal
125 Receipt Message* as the form which the HTTPS response body should 135 Receipt Message* as the form which the HTTPS response body should
126 adopt when responding to an HTTPS POST request in the *Transfer 136 adopt when responding to an HTTPS POST request in the *Transfer
127 Proposal Message* form or, as I read it at first, actually means a 137 Proposal Message* form or, as I read it at first, actually means a
128 _seperate_ HTTPS POST request in the *Transfer Proposal Receipt 138 _separate_ HTTPS POST request in the *Transfer Proposal Receipt
129 Message* format is sent from the recipient gateway. 139 Message* format is sent from the recipient gateway.
130 140
131 That is, are we being told about a single HTTPS exchange, or two? 141 That is, are we being told about a single HTTPS exchange, or two?
132 Or is the intent to allow for either? I think either at the 142 Or is the intent to allow for either? I think either at the
133 beginning of section 8, or somewhere earlier, perhaps section 6, 143 beginning of section 8, or somewhere earlier, perhaps section 6,