[Int-dir] Re: draft-ietf-core-groupcomm-bis-15 telechat Intdir review

[Marco Tiloca <[e-mail]>]

Hello Brian,

Thanks a lot for your review! Please find in line below our detailed replies to your comments.

A GitHub PR where we have addressed your comments is available at [PR].

Unless any concern is raised, we plan to soon merge this PR (and the other ones related to other received reviews) and to submit the result as version -16 of the document.

Thanks,
/Marco

[PR] https://github.com/core-wg/groupcomm-bis/pull/51

________________________________
From: Brian Haberman via Datatracker <[e-mail]>
Sent: Tuesday, October 14, 2025 4:28 PM
To: [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: draft-ietf-core-groupcomm-bis-15 telechat Intdir review

Document: draft-ietf-core-groupcomm-bis
Title: Group Communication for the Constrained Application Protocol (CoAP)
Reviewer: Brian Haberman
Review result: Almost Ready

I am an assigned INT directorate reviewer for draft-ietf-core-groupcomm-bis.
These comments were written primarily for the benefit of the Internet Area
Directors. Document editors and shepherd(s) should treat these comments just
like they would treat comments from any other IETF contributors and resolve
them along with any other Last Call comments that have been received. For more
details on the INT Directorate, see
https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fgroup%2Fintdir%2Fabout%2F&data=05%7C02%7Cmarco.tiloca%40ri.se%7C62656afe540e429fa41e08de0b2e3130%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638960490183585429%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=6XSfj%2BM9D3R4MgSBlGsGoPTIhVVczwPer6r%2Flq09Tqw%3D&reserved=0<https://datatracker.ietf.org/group/intdir/about/>

I was asked to look at this document from the multicast address perspective, so
these comments focus on that area of the document driven by the DISCUSS
comments related to multicast addressing.

# Use of ff35:30:2001:db8:f1:0:8000:1 - FF35::/32 is an SSM range per RFC 3306
and RFC 4607. But, the referenced multicast address does not fall in that range
since it has values in the last 8 bits of the prefix. This makes it an IPv6
multicast address with an embedded IPv6 unicast prefix.

==>MT

As to Section 2.2.1.2, the address ff35:30:2001:db8:f1::8000:1 is the one used in Appendix A of RFC 9176 that we are simply referring to as-is. We are not defining the address here.

A related point was raised in the review from Ketan Talaulikar, which we have addressed in the commit at https://github.com/core-wg/groupcomm-bis/commit/330949121919a790a6397a095221b883de79fdac#diff-e9763af996c2597da4d48083e55a8c2d9e47750929f9f4b785b81bd041d44b93R382-R383

In particular, for consistency, in Section 2.2.1.2 we have edited the address to use exactly the same compact notation as in RFC 9176, i.e.:

OLD
> ff35:30:2001:db8:f1:0:8000:1

NEW
> ff35:30:2001:db8:f1::8000:1

Also, the address also appears in Appendix B and Appendix B.1 of the present document. There we have changed it to use an address from the range FF0X:0:0:0:0:DB8::/96 provided for documentation [RFC6676], i.e.:

OLD
> ff35:30:2001:db8:f1:0:8000:1

NEW
> ff05::db8:8000:1

Since this update is already part of the Pull Request at https://github.com/core-wg/groupcomm-bis/pull/50 , we prefer to not make it again in the Pull Request addressing this review, in order to minimize conflicts when merging the different Pull Requests.

<==


# The above confusion probably stems from a lack of explanatory text around the
multicast prefixes mentioned in the document. Given that, I would recommend the
following:

## The mention of "one-to-many" and ASM in section 1.1 may be confusing. The
purpose of the first sentence appears to be to indicate that this document only
defines CoAP group communication over multicast-capable transport protocols.
But, even that does not limit things to ASM. It seems like this document is
defining how many-to-many communication is carried out over multicast-capable
transport protocols.

==>MT

We believe that "one-to-many" is a good expression, but it also has to be clear what it does not mean.

Section 1.1 of RFC 7390 says:

> Group communication involves a one-to-many relationship between CoAP endpoints. Specifically, a single CoAP client can simultaneously get (or set) resources from multiple CoAP servers using CoAP over IP multicast.

Building on the above, we have made the following rephrasing in this document.

OLD (Section 1)
> One-to-many group communication can be achieved in CoAP, by a client using UDP/IP multicast data transport to send multicast CoAP request messages. In response, each server in the addressed group ...

NEW (Section 1, emphasis mine)
> One-to-many group communication can be achieved in CoAP, by a client using UDP/IP multicast data transport to send multicast CoAP request messages **to all servers in a group. Within a given group, multiple clients can send multicast CoAP request messages**. In response, each server in the addressed group ...

OLD (Section 1.1)
> For group communication, only those solutions that use CoAP messages over a "one-to-many" (i.e., non-unicast) transport protocol are in the scope of this document. There are ...

NEW (Section 1.1, emphasis mine)
> For group communication, only those solutions that use CoAP messages over a "one-to-many" (i.e., non-unicast) transport protocol are in the scope of this document. **By using such a transport protocol, any client in a group can send a multicast CoAP request message to all servers in the group. That is, "one-to-many" refers to the delivery of a given message from one sender to multiple recipients, and the sender, the recipients, or both can change on a per-message basis.**
>
> There are ...

We do not think that it is needed to clarify this again in Section 3.5.2 and Appendix F, where "one-to-many transport" is also used.

<==


## In the 2nd paragraph of section 1.1, I would suggest replacing "CoAP group
requests" with "CoAP group messages" as it seems like responses can be sent to
multicast groups as well.

==>MT

At least as per this document, responses cannot be sent over multicast. Therefore, using "CoAP group requests" is actually most appropriate.

More in detail:

* "Group request" is consistently used many times in the document to clearly refer to requests sent to the group over UDP/IP multicast (like the referred paragraph says).

* The Group OSCORE document draft-ietf-core-oscore-groupcomm uses the same term in the same way.

* The document draft-ietf-core-observe-multicast-notifications is defining the concept of responses sent over multicast, but it would be greatly confusing to bring the concept up here.

<==


## Section 2.2.2

### I would suggest providing supporting text for the use of FF1x::16 and
FF3x::/16. This should include references to RFCs 3306, 3956, and 7371
(possibly).

### The text essentially says that assignment of multicast addresses is done by
an administrator. I would suggest adding text to guide administrators in the
selection of multicast prefixes, multicast scopes, and possible group IPs. This
would benefit from a reference to RFC 3307. Please note that 3307 is in the
process of being updated by draft-ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id.

==>MT

Quoting for context:

> For IPv6 CoAP groups, common multicast address ranges from which group addresses can be taken are ff1x::/16 and ff3x::/16.

When addressing a comment in the review from Ketan Talaulikar, we have updated the text as below, in order to leave the choice to network operators and administrators, see commit at https://github.com/core-wg/groupcomm-bis/commit/e9610346e5cbcf94175bd64a422fc08f252723c0

NEW
> For IPv6 CoAP groups, this document does not suggest or recommend any particular multicast address ranges from which group addresses can be taken. It is up to network operators and managers to appropriately select addresses from the multicast address space with the intended multicast address scope.

Taking into account the present comment, we have further extended that paragraph by adding the following sentence at its end:

> Guidelines for selecting and assigning IPv6 multicast addresses are compiled in [RFC3307].

RFC 3307 can simply be an informative reference. Also, it is safer and still adequate to use RFC 3307 instead of draft-ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id (which is currently in IETF Last Call).

<==