# HG changeset patch # User Henry S. Thompson # Date 1792599878 -3600 # Node ID 2eda17d4debf3ca720c14e19d611eebef44a8574 # Parent f2743a0a4eb7f223026d7a5319eda41c9c78556a as submitted diff -r f2743a0a4eb7 -r 2eda17d4debf satp-core-review.txt --- a/satp-core-review.txt Wed Oct 21 15:27:14 2026 +0100 +++ b/satp-core-review.txt Wed Oct 21 17:24:38 2026 +0100 @@ -2,17 +2,30 @@ Document: https://www.ietf.org/archive/id/draft-ietf-satp-core-17.html Title: Secure Asset Transfer Protocol (SATP) Core Reviewer: Henry S. Thompson -Review Date: Mon Oct 19 13:48:49 2026 +Review Date: Wed Oct 21 17:12:16 2026 *Summary* -As far as I can tell as a non-specialist, the ... is in good shape. -There are ... below. - This draft is part of a package of at least three parts, including also _Secure Asset Transfer (SAT) Interoperability Architecture_ and _Secure Asset Transfer (SAT) Use Cases_. +Its aim is to present a concrete instantiation of the SAT +Interoperability Architecture in terms of a specific set of message +formats. As far as I can tell as a non-specialist, it achieves that +goal. + +But in my opinion it needs work on the presentation, particularly in +the area of consistency and transparency of terminology, both +internally and in relation to the terminology established by the SAT +Interoperability Architecture, which I take to be the senior party in +the trilogy. + +All of my comments below under 'Minor points' bar the very first are +there, rather than under a more serious heading, only because this is +a matter of presentation, not substance, but I think it's important +that they be addressed. + *Minor points* 1. @@ -75,9 +88,6 @@ Also, later on the terminology used changes from 'recipient gateway' to 'receiver gateway' -- this should be reverted throughout. - I've listed all this as 'minor' only because it is a matter of - terminology, but I think it's important to fix it. - 5.4.1 See above. Here's a simpler version of this whole section: @@ -125,7 +135,7 @@ Receipt Message* as the form which the HTTPS response body should adopt when responding to an HTTPS POST request in the *Transfer Proposal Message* form or, as I read it at first, actually means a - _seperate_ HTTPS POST request in the *Transfer Proposal Receipt + _separate_ HTTPS POST request in the *Transfer Proposal Receipt Message* format is sent from the recipient gateway. That is, are we being told about a single HTTPS exchange, or two?