diff --git a/README.md b/README.md
index e5dd824..3da43ef 100644
--- a/README.md
+++ b/README.md
@@ -47,13 +47,17 @@ Currently supported session algorithms:
 * HMAC-SHA256
 * HMAC-SHA512
 
-### Wait. You offer a lot of cryptographic primitives there. According to some, 'Cipher-agility' is considered bad in 2021. What gives?
+***
+**A Note on 'cryptographic agility'**
+
+It has been suggested recently to me that offering multiple cryptographic primitives is considered bad in 2021.
 
 An interesting question. See [this write-up for a discussion](https://paragonie.com/blog/2019/10/against-agility-in-cryptography-protocols).
 
-xs implements the philosophy that it is the server admin's prerogitive to allow or deny connection using any particular combination of cryptographic primitives. The protocol makes no allowance for any sort of 'downgrades' or algo substitution during negotiation. The 'negotiation', if you can even call it that, is precisely: (client proposes a KEX, session cipher alg and hash) -- (server accepts or refuses and drops connection). If the server admin wishes, xsd (server) can accept any supported configuration, or a subset, or exactly one.
+xs operates via the philosophy that **it is the server admin's prerogitive to configure local policy wrt. allowed cryptographic primitives**. The connection protocol makes no allowance for any sort of 'downgrades' or algo substitution during negotiation; there is no 'fallback' mode or two-way negotiation of what primitives to use, which would open the possibility of downgrade attacks. Unlike `ssh`, the server does not offer to clients a list of supported algorithms; the client can only offer a single configuration to the server, which it simply accepts or rejects without comment to the client.
 
-Furthermore, the code allows no accidental or implied 'sliding' between one configuration and another -- there is no 'fallback' mode or two-way negotiation of what primitives to use (which would open the possibility of downgrade attacks). HOWEVER, the current code does default to the server (xsd) allowing 'all' combinations unless command-line switches give a restriction list. Perhaps I will invert that, and require a list of allowed configurations instead. This is trivial to implement with the current architecture.
+In all releases to date, absent a specific whitelist of algs to allow, the server allows 'all' combinations of the above cryptographic primitives to be proposed by clients (but again, **only one** combination is proposed by the client in a single connect attempt). If the admin wishes to restrict the accepted algorithms now or at any future time, they may use the `-aK`, `-aC` and `-aH` options when launching the server to define a whitelist which excludes certain primitives. In future releases the default may be changed to accept *no* algs and such a whitelist shall be required. This will have no effect on the connection protocol itself.
+***
 
 
 ### Conn