Document: 
Intended RFC status: Proposed Standard
Review type: artart - Last Call review
Reviewer: Henry S. Thompson
Review Date: 2023-10-@@
Result: Ready with Issues

*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.

*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]

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
without _some_ good reasons to suppose that there's a community out
there waiting to implement this framework, its future does seem a bit
shaky...  There is of course a chicken-and-egg problem here which may
explain the lack of progress.

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 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.

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