--- a/satp-core-review.txt	Tue Oct 20 19:49:34 2026 +0100
+++ b/satp-core-review.txt	Wed Oct 21 11:01:35 2026 +0100
@@ -31,14 +31,86 @@
   better security than HTTPS with TLS1.3.
 
   There might be an argument for a SHOULD support HTTPS with TLS 1.3,
-  but only if there is a strong case for encouraging
+  but only if there is a strong case for encouraging interop between
+  different gateway implementations.
+
+5.3
+
+  The use of the word 'client' here and and client/server terminology
+  in 5.4 is unnecessarily confusing with respect to the use of
+  'client' as defined in section 3 and used in section 4 (the SATP
+  model) and 5.3.8.  
+
+  The fact that 'client' is used with two different meanings in the
+  section headings of 5.3.8 and 5.3.10 illustrates this unnecessary
+  confusion.
+
+  ARCH uses 'client' only in the 'client application' sense, and
+  'server' not at all, and it would be a good idea to stick with that.
+  Following ARCH, Section 3 defines "sender gateway" and "recipient
+  gateway" and I would very much encourage their use throughout, as
+  already done in 5.3.2.
+
+  For example, 5.3 para 1 could read
+
+   SATP messages are exchanged between peer gateways, where depending
+   on the message type one is the sender gateway and the other the
+   recipient gateway.
+
+  and in 5.3.9
+
+   If the sender gateway transmits a list of supported credential
+   schemes, the recipient gateway selects one acceptable credential
+   scheme from the offered schemes.
+
+  and in 5.3.10
 
-[sender/receiver vs. client/server is confusing at best.  Cf. ARCH
- which tries to be clear wrt "sender gateway" and "recipient gateway",
-but uses "client application" for both "originator" and "beneficiary"]
+    *5.3.10. Sender Gateway Offers Other Supported TLS Schemes*
+
+    If a sender gateway wishes to use TLS schemes other than the basic
+    scheme (AES-128 in GCM mode with SHA-256), then the gateway may
+    may choose to send a JSON object listing the client's supported
+    TLS schemes.
+
+  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:
+
+  5.4.1. Protocol requirements
+
+  Gateways MUST use a secure protocol, HTTPS or successors, in this stage.
+
+  Gateways MUST use the HTTPS POST method or equivalent idempotent
+  [RFC 9110] method in this stage.
+
+7.
+
+  remove ' (client)' and ' (sender)'
+
+8., 9., 10.
+
+  remove and/or replace 'client', 'server' and 'receiver' so that all
+  and only 'sender gateway' and 'recipient gateway' are used
+
 
 *Nits*
 
+3.
+
+ Since you use them both, I suggest including the ARCH definitions of
+'originator' and 'beneficiary' here.
+
+5.3.15
+  'immobile' => 'immobilize' [twice]
+
+  'uses Hashed Time-lock' => 'use Hashed Time-lock'
+
 15.1
 
  RFC 8446 is obsolete, should refer to 9846.