Summary

  • RFC 10020 distinguishes the CoAP receiver group, the resource-sharing application group and the security group; they may overlap without becoming one population or one authority.
  • A protected group request and some replies establish useful protocol evidence. They do not establish that every intended endpoint received the request, was permitted to act, executed the same command or produced the claimed effect.

RFC 10020 replaced an earlier CoAP group-communication specification at a moment when constrained systems have more realistic security machinery available. Its central contribution is not a promise that every lamp, valve, sensor or actuator will move together. It is a vocabulary for being precise about what kind of group is under discussion.

A CoAP group is about endpoints configured to receive requests sent to an associated IP multicast address and UDP port. An application group is about server endpoints sharing a set of CoAP resources. A security group is about the material and membership needed to participate in protected group communication. RFC 10020 deliberately allows many-to-many relationships among those groups. A device can belong to several of them. A client can send to a CoAP group without being one of its receiving server endpoints.

An application population can be organized one way while the multicast population and the cryptographic population are organized another way.

That separation is not bureaucratic taxonomy. It prevents a common but expensive inference: “the command went to the group, therefore the intended business population acted.” Addressing answers where a packet was sent. Configuration answers which endpoints were arranged to listen. A resource model answers what an endpoint may expose. Security-group participation can establish that a protected message came from a credible group member and has not simply been replayed.

None of those observations settles whether a particular endpoint was the intended operational subject, whether its local policy admitted the request, or whether its application made a durable state change.

Response behaviour adds a second reason not to collapse the chain. Multicast requests cannot safely demand that every server immediately speak at once. RFC 10020 retains response suppression and delayed response patterns; congestion controls also matter in constrained links. A small response set may mean that other servers were intentionally quiet. Silence may reflect suppression, loss, sleep, local filtering, a resource mismatch, an authorization refusal that is not externally represented, or a device that never received the packet. It is evidence with a stated scope, not a census of completed work.

Group OSCORE changes the quality of the evidence, not its category. A receiving server can verify replay conditions and the claimed origin of a protected group request. Source authentication, confidentiality and freshness controls can sharply reduce the risk that a stranger injected the message. But security at the group-message layer is not the same as approval at the resource or business layer. One eligible group sender can still lack authority for a particular valve position; one server can still reject an action under local state; a legitimate command can still fail after admission because a physical dependency is absent.

The practical danger is a dashboard verb such as “completed” that quietly joins all of those predicates. It turns one send into delivery, delivery into interpretation, interpretation into authorization, authorization into execution and execution into effect. The standard supports none of those silent joins. Its value is greater when operators preserve them.

Heng Lu's minimum-specification doctrine is useful here. A portable group mechanism should make an initial common layer available without impersonating every subsequent local choice. Running code is equally relevant: a packet trace and a configuration snapshot describe parts of reality, while the claim that a control action worked belongs to a reconciled execution record. RFC 10020 gives the group message a disciplined place in that record; it does not own the rest of it.