--- a/ace-key-groupcomm-review.txt	Wed Oct 25 22:36:22 2023 +0100
+++ b/ace-key-groupcomm-review.txt	Fri Oct 27 15:31:55 2023 +0100
@@ -30,6 +30,11 @@
 If the Dispatcher is untrusted, how can communication be secure?
 There is no discussion of the Dispatcher in the Security section.
 
+Section 5: I don't see how authority to institute forced deletion is
+established.  Indeed the means for forced deletion don't appear to be
+defined at all.  Section 4.8 (and 4.8.3) explicitly requires that only
+the Client can send a Delete request, and only for themselves.
+
 *Minor points*
 
 Section 1. I note that one of the two referenced examples of candidate
@@ -46,6 +51,21 @@
 Resource Server _per ACE_.  Simply adding ", per ACE," to "Resource
 Server" in para 2 of Section 1 would fix this for me.
 
+Section 6: It might be helpful to include ASCII-art diagrams of the
+different communication pathways described for accomplishing rekeying.
+
+Sections 3.1 & 7: The example scopes include Verifier and Monitor
+roles.  Although there is a parenthetical reference to the [Vv]erifier
+role in Section 3.3.1, no other mention of Monitor is given, and in
+general the role of roles is not explained anywhere. There is a
+"Request inconsistent with the current roles" error code defined in
+section 9, but no tabulation of roles allowed/required for particular
+requests, which one might expect.
+
+If all this is something defined in one of the many referenced specs,
+and so familiar to likely readers, that's OK, otherwise perhaps
+something should be added.
+
 *Nits*
 
 Section 1 / Appendix A:  The use of REQ[n] and OPT[n] in conjunction