--- a/ace-key-groupcomm-review.txt	Sat Oct 21 16:09:52 2023 +0100
+++ b/ace-key-groupcomm-review.txt	Wed Oct 25 22:36:22 2023 +0100
@@ -2,18 +2,37 @@
 Intended RFC status: Proposed Standard
 Review type: artart - Last Call review
 Reviewer: Henry S. Thompson
-Review Date: 
-IETF Last Call Date: 
+Review Date: 2023-10-@@
+Result: Ready with Issues
 
-Summary: 
+*Summary*
 
 Caveat: I'm not familiar with the group comms family of RFCs or the
 applications they support, so this review is from an outsider's
 perspective.
 
-Minor points
+*Substantive points*
+
+Section 2.  I'm seeing an inconsistency in the way the Dispatcher is
+discussed.  When introduced in the bullet points the last bullet says
+
+ "If it consists of an explicit entity such as a pub-sub Broker or a
+  message relayer, the Dispatcher is comparable to an _untrusted_
+  on-path intermediary, and as such it is _able to read_ the messages
+  sent by Clients in the group." [emphasis added]
 
-Section @. I note that one of the two referenced examples of candidate
+But at the end of section 2 we find
+
+   "5. The joining node can communicate _securely_ with the other group
+       members, using the keying material provided in step 3."
+       [emphasis added]
+
+If the Dispatcher is untrusted, how can communication be secure?
+There is no discussion of the Dispatcher in the Security section.
+
+*Minor points*
+
+Section 1. I note that one of the two referenced examples of candidate
 application profiles, "A publish-subscribe architecture for the
 Constrained Application Protocol (CoAP)" [1], has expired.  I'm not
 sure how much it matters to have reasonably mature examples, but
@@ -25,8 +44,25 @@
 Section 2. This is the first point where the actual connection between
 ACE and this document is made clear, that is, that the KDC is the
 Resource Server _per ACE_.  Simply adding ", per ACE," to "Resource
-Server" in para 2 of Section 1 would do the trick.
+Server" in para 2 of Section 1 would fix this for me.
+
+*Nits*
+
+Section 1 / Appendix A:  The use of REQ[n] and OPT[n] in conjunction
+with REQUIRED and MAY is not explained, nor are they linked to the
+relevant text in Appendix A.  There is an oblique reference to this
+practice in para. 4 of Section 1, which could stand to be expanded to
+explain your conventions.
 
-Nits
+Passim: Please do a thorough spell-check.  The following were found in the
+first 4 sections:
+  recommeded -> recommended
+  memebrs -> members
+  specificaton -> specification
+  acces -> access
+  trasferring -> transferring
+
+ht
+-- 
 
 [1] https://datatracker.ietf.org/doc/html/draft-ietf-core-coap-pubsub-12