# HG changeset patch
# User Henry S. Thompson <ht@inf.ed.ac.uk>
# Date 1792522174 -3600
# Node ID 7f1bd15f2d23ca700c82cdf1c45350cea9cd0d2a
# Parent  d8dde47d0a7f8aafcd85a54b5fe726bd2455a6d7
getting started

diff -r d8dde47d0a7f -r 7f1bd15f2d23 satp-core-review.txt
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/satp-core-review.txt	Tue Oct 20 19:49:34 2026 +0100
@@ -0,0 +1,47 @@
+https://datatracker.ietf.org/doc/draft-ietf-satp-core/
+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
+
+*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_.
+
+*Minor points*
+
+1.
+
+  The restriction to just HTTPS with TLS1.3 is almost certainly not
+  what you want.  The use of HTTP/2 or QUIC, which requires use of
+  TLS1.3, should be allowed.
+
+  In the Introduction, all that's needed is something along these lines:
+
+     Secure transfer mechanisms such as HTTPS with TLS no less than 1.3
+     must be used.
+
+  5.3.9 and 5.4 can actually be simplified by switching to language
+  which allows for successor messaging systems which offer the same or
+  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
+
+[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"]
+
+*Nits*
+
+15.1
+
+ RFC 8446 is obsolete, should refer to 9846.
+
+
+