[core] Re: Éric Vyncke's Discuss on draft-ietf-core-groupcomm-bis-15: (with DISCUSS and COMMENT)

[Esko Dijk <[e-mail]>]

Hi Eric,

Meanwhile we've addressed your final comments by adding commits to the 
PR [1]. The results of all PRs will be merged very soon, so that you can 
easily inspect the end result as a new draft version!

On the use of the multicast address  ff35:30:2001:db8:f1::8000:1 which 
we copied from RFC 9176 : we've now rephrased in such a way that the 
address literal is not mentioned anymore - there wasn't a clear need for it.
However we do believe that the address itself is correct and doesn't 
need an erratum, based on some analysis that was in the later part of 
our reply.

In summary: the address is not in the ff3x::/32 range, and it's not 
intended to be. It doesn't intend to use SSM in any way. Based on RFCs 
3306 / 7371 it has flags P=1 and T=1 (flgs=0x3), to create a 
unicast-prefix-based multicast address.
It has plen=0x30 (48) so it's based on a documentation prefix 
2001:db8:f1::/48.  Within that prefix's address space, it picks group ID 
(32-bits) 8000:0001 .

In any case by excluding the address, this discussion would not be 
relevant anymore in groupcomm-bis scope perhaps :)
Thanks again, and happy new year to you also!

Esko

[1] https://github.com/core-wg/groupcomm-bis/pull/58 
<https://github.com/core-wg/groupcomm-bis/pull/58>

On 23-12-2025 17:27, Eric Vyncke (evyncke) wrote:
> Hello Esko,
>
> Thanks for your message, the PR, and the replies. To be honest, with 
> the 3 PR (for Brian, Ketan, and myself), I cannot have a global view 
> of what would be the merge result. Notably on the use of wrong ASM 
> addresses. I.e., I cannot tell whether I would clear my DISCUSS before 
> seeing the revised I-D. But, it seems that we are close to solving all 
> the issues raised in my ballot & int-dir review.
>
> See in-line for EV> (my corporate Outlook makes things more 
> complicated...)
>
> Regards and Happy New Year!
>
> -éric
>
> *From: *Esko Dijk <[e-mail]>
> *Date: *Monday, 22 December 2025 at 14:17
> *To: *Eric Vyncke (evyncke) <[e-mail]>, The IESG <[e-mail]>
> *Cc: *[e-mail] 
> <[e-mail]>, [e-mail] 
> <[e-mail]>, [e-mail] <[e-mail]>
> *Subject: *Re: [core] Éric Vyncke's Discuss on 
> draft-ietf-core-groupcomm-bis-15: (with DISCUSS and COMMENT)
>
> Hello Éric,
>
> Thanks for your review! Below, inline are the detailed replies to your 
> comments by the authors.
> 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.
>
> best regards,
> Esko & Marco
>
> [PR] https://github.com/core-wg/groupcomm-bis/pull/58
>
> On 8-10-2025 17:38, Éric Vyncke via Datatracker wrote:
>
>     Éric Vyncke has entered the following ballot position for
>     draft-ietf-core-groupcomm-bis-15: Discuss When responding, please
>     keep the subject line intact and reply to all email addresses
>     included in the To and CC lines. (Feel free to cut this
>     introductory paragraph, however.) Please refer to
>     https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
>     for more information about how to handle DISCUSS and COMMENT
>     positions. The document, along with other ballot positions, can be
>     found here:
>     https://datatracker.ietf.org/doc/draft-ietf-core-groupcomm-bis/
>     ----------------------------------------------------------------------
>     DISCUSS:
>     ----------------------------------------------------------------------
>     # Éric Vyncke, INT AD, comments for
>     draft-ietf-core-groupcomm-bis-15 CC @evyncke Thank you for the
>     work put into this document. A generic comment (and I am also
>     partly 'guilty' as I did not make the connection between group and
>     multicast at first sight), as it has a multicast component, it
>     should have gained a deep multicast review by requesting an
>     Internet Directorate review. At this point, I am balloting a
>     DISCUSS mainly to defer to request an Internet directorate review
>     to double check the multicast points as this I-D does not appear
>     to have a mboned/pim review.
>
>
> We have received the INTDIR review from Brian Haberman archived at [2].
> To address his comments, we have created a separate PR at 
> https://github.com/core-wg/groupcomm-bis/pull/51
>
> [2] 
> https://mailarchive.ietf.org/arch/msg/core/lXv9zpyB3LxGrLyYdMWTyDalkhQ/
>
>     Please find below two blocking DISCUSS points (one easy to
>     address), some non-blocking COMMENT points/nits (replies would be
>     appreciated even if only for my own education). Special thanks to
>     Carsten Bormann for the shepherd's detailed write-up including the
>     WG consensus *but it lacks* the justification of the intended
>     status. Other thanks to Petr Špaček, the DNS directorate reviewer:
>     https://datatracker.ietf.org/doc/review-ietf-core-groupcomm-bis-15-dnsdir-telechat-spacek-2025-09-29/
>     (all is good as the comments were addressed) I hope that this
>     review helps to improve the document, Regards, -éric ## DISCUSS
>     (blocking) As noted in
>     https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/,
>     a DISCUSS ballot is a request to have a discussion on the points
>     below; I really think that the document would be improved with a
>     change here, but can be convinced otherwise. ### Section 1.1 The
>     use of "we" in `we expect many of the considerations` is
>     ambiguous... Is it the authors ? The CORE WG ? The IETF ? Suggest
>     using the passive voice or paraphrasing.
>
>
> We have rephrased as below:
>
> OLD
>
>     Although UDP/IP multicast transport is assumed in most of the text
>     in this document, we expect many of the considerations for UDP/IP
>     multicast can be re-used for alternative transport protocols.
>
> NEW (emphasis mine)
>
>     Although UDP/IP multicast transport is assumed in most of the text
>     in this document, it is expected that many of the considerations
>     for UDP/IP multicast can be re-used for alternative transport
>     protocols.
>
>
> EV> this indeed a good fix, but there are *TWO* occurrences of `we` 
> and both must be fixed 😉
>
>     ### Multicast addressing This is the part where my multicast
>     knowledge is not bullet-proof (hence the defer for a review by
>     multicast expert). Happy to stand corrected. #### Section 2.2.1.2
>     Previous text (`Only the Any Source Multicast (ASM) mode` in
>     section 1.1) specifies that only ASM mcast is used but the example
>     `ff35:30:2001:db8:f1:0:8000:1` is SSM and not ASM...
>
>
> This point came up also in the review from Ketan Talaulikar [1] and in 
> the recent INTDIR review from Brian Haberman [2]. In fact, it was 
> addressed when processing the review from Ketan, see the commit at [3] 
> as part of the PR at [4].
>
> To summarize, there are four instances of the address 
> ff35:30:2001:db8:f1:0:8000:1 , i.e., two in Section 2.2.1.2, one in 
> Appendix B, and one in Appendix B.1.
>
> As to the instances in 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.
>
>
> EV> I am sorry, but there is no reason to rely on an error in RFC 
> 9176. There should be an erratum for the appendix A of RFC 9176.
>
> EV> Bottom line, all occurrences must be changed.
>
> 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
>
> As to the instances in Appendix B and Appendix B.1, we have changed 
> them 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
>
> Specifically about the SSM mode, RFC 4607 says:
>
>     For IP version 6 (IPv6), the address prefix FF3x::/32 is reserved
>     for source-specific multicast use.
>
> That is, an SSM address starts with ff3x:0000, which is not the case 
> for the address ff35:30:2001:db8:f1::8000:1 used in the example of RFC 
> 9176 and used in the present document.
>
> Therefore, besides the fact that the address is only mentioned in the 
> context of an external example, there should not be need for a 
> clarification related to ASM or SSM either.
>
> [1] 
> https://mailarchive.ietf.org/arch/msg/core/SG7fpMILV2a4qrJYHz0xhUw-V50/
>
> [2] 
> https://mailarchive.ietf.org/arch/msg/core/lXv9zpyB3LxGrLyYdMWTyDalkhQ/
>
> [3] 
> https://github.com/core-wg/groupcomm-bis/commit/330949121919a790a6397a095221b883de79fdac#diff-e9763af996c2597da4d48083e55a8c2d9e47750929f9f4b785b81bd041d44b93R382-R383
>
> [4] https://github.com/core-wg/groupcomm-bis/pull/50
>
>
>
>     #### Section 2.2.2 `For IPv6 CoAP groups, common multicast address
>     ranges from which group addresses can be taken are ff1x::/16 and
>     ff3x::/16.` but ff3x::/16 is for SSM and not ASM.
>
>
> When addressing a comment in the review from Ketan Talaulikar (see 
> commit at [5]), we have updated the text as below, in order to leave 
> the choice to network operators and administrators. This update 
> removes the need for possible clarifications/fixes on SSM and ASM.
>
> OLD
>
>     For IPv6 CoAP groups, common multicast address ranges from which
>     group addresses can be taken are ff1x::/16 and ff3x::/16.
>
> 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.
>
> [5] 
> https://github.com/core-wg/groupcomm-bis/commit/e9610346e5cbcf94175bd64a422fc08f252723c0
>
> In any case, RFC 4607 says:
>
>     For IP version 6 (IPv6), the address prefix FF3x::/32 is reserved
>     for source-specific multicast use.
>
> That is, an SSM address starts with ff3x:0000, which is not 
> necessarily the case for an address in the range ff3x::/16.
>
>
> EV> this sounds like a good fix, but I would prefer to see the merged 
> result.
>
>     ----------------------------------------------------------------------
>     COMMENT:
>     ----------------------------------------------------------------------
>     ## COMMENTS (non-blocking) Is there any reason why the filename is
>     not rfc7390-bis ? even if only for clarity ;-)
>
>
> We just started from the name of the draft that became RFC 7390, i.e., 
> draft-ietf-core-groupcomm, and simply appended “-bis” to produce the 
> document name of the present document.
>
> EV> let's learn a lesson about this 😉
>
>     ### UDP ports may become useless for mcast As noted by Erik and
>     Gunter, draft-ietf-intarea-multicast-application-port tends to
>     remove the use of UDP port for mcast traffic. In a constrained
>     environment, this could be useful (even with 6LO compression) to
>     remove the 8-octet UDP header. This draft should at least be
>     mentioned.
>
>
> As we understand it, that document is actually meant to “[assign] a 
> UDP port that may be used with multicast applications: the Multicast 
> Application Port.” Also, “[the use] of this port is optional because 
> there may be circumstances where assigning a port is preferred.”
>
> In any case, yes, it is good to mention. Please note that, when it 
> comes specifically to CoAP:
>
>  *
>
>     The concept of “endpoint” is just intrinsic to the protocol.
>
>  *
>
>     It is a fact that a pair (address, port number) identifies a CoAP
>     endpoint that “lives” at a host, with the port number defaulting
>     to 5683.
>
>     In the present document, that concept is extended to identify a
>     set of CoAP endpoints that is configured to receive CoAP group
>     messages that are sent to the group’s associated IP multicast
>     address and UDP port. This information is practically indicated in
>     the authority component of the group URI identifying the group.
>
>  *
>
>     It is already possible to configure different CoAP groups by not
>     explicitly saying anything anywhere about the port number. When
>     doing so, all such groups are distinguished only by their
>     different multicast addresses and all share the same default port
>     number 5683.
>
> Like done when addressing the comment from Erik Kline’s review, we 
> have added draft-ietf-intarea-multicast-application-port among the 
> informative references and added a sentence in the first paragraph of 
> Section 3.4 “Port Selection for UDP Transport”:
>
> OLD
>
>     A server that is a member of a CoAP group listens for CoAP request
>     messages on the group’s IP multicast address and port number. The
>     group’s port number is usually the CoAP default UDP port number
>     5683, or alternatively another non-default UDP port number if
>     configured. Regardless of …
>
> NEW (emphasis mine)
>
>     A server that is a member of a CoAP group listens for CoAP request
>     messages on the group’s IP multicast address and port number. The
>     group’s port number is usually the CoAP default UDP port number
>     5683, or alternatively another non-default UDP port number if
>     configured. If any is assigned in the future, a UDP port number
>     designated for multicast applications can be used as the group’s
>     port number (e.g., see [I-D.ietf-intarea-multicast-application-port]).
>
>     Regardless of …
>
>
> EV> should be OK
>
>     ### Section 1 Humm I wonder whether `Both unsecured and secured
>     CoAP group communication are specified in this document` is
>     correct as most of the security aspects are in the companion
>     draft-ietf-core-oscore-groupcomm.
>
>
> The word “specified” is probably too strong. What is mandated is the 
> use of Group OSCORE when enforcing secure communication, but the 
> specification of Group OSCORE is indeed in another document.
>
> We have rephrased as below:
>
> OLD
>
>     Both unsecured and secured CoAP group communication are specified
>     in this document.
>
> NEW (emphasis mine)
>
>     Both unsecured and secured CoAP group communication are covered in
>     this document.
>
>
> EV> looks good to me
>
>     ### Section 2.1.4 Thanks for using SVG artwork, the HTML rendering
>     is much nicer and more readable.
>
>
> Good!
>
>     ### Section 2.2.1.1 Thanks for using ff15::1234 for a transient
>     site-local multicast example, but I think that section 3 of RFC
>     6676 (Multicast Addresses for Documentation) would rather prefer
>     ff05:db8::1234 even if this RFC is informational. Also, making the
>     UDP port 5683 by default will be incompatible with
>     draft-ietf-intarea-multicast-application-port. Can this part of
>     the I-D be removed to avoid future issues ?
>
>
> Let’s take the two points separately.
>
> On the first point, it came up also in the review from Ketan 
> Talaulikar [1]. In fact, it was addressed when processing his review, 
> see the commit at [3] as part of the PR at [4].
>
> That is, in Section 2.2.1.1 we have made the updates below:
>
> OLD
>
>     ff15::1234
>
> NEW
>
>     ff05::db8:0:1
>
> On the second point, we are not making 5683 the default port number 
> for CoAP as a new definition in this document. It is already defined 
> to be the default port number in RFC 7252 and there should be no 
> problem with keeping it so. (Problems would likely arise if that is 
> changed, instead)
>
> Here too, the reasons are the same as explained when replying to the 
> previous comment titled “UDP ports may become useless for mcast”. We 
> have clarified this point as follows.
>
> First, like for that previous comment and when address Erik Kline’s 
> review, we have added a sentence in the first paragraph of the later 
> Section 3.4 “Port Selection for UDP Transport”:
>
> OLD
>
>     A server that is a member of a CoAP group listens for CoAP request
>     messages on the group’s IP multicast address and port number. The
>     group’s port number is usually the CoAP default UDP port number
>     5683, or alternatively another non-default UDP port number if
>     configured. Regardless of …
>
> NEW (emphasis mine)
>
>     A server that is a member of a CoAP group listens for CoAP request
>     messages on the group’s IP multicast address and port number. The
>     group’s port number is usually the CoAP default UDP port number
>     5683, or alternatively another non-default UDP port number if
>     configured. If any is assigned in the future, a UDP port number
>     designated for multicast applications can be used as the group’s
>     port number (e.g., see [I-D.ietf-intarea-multicast-application-port]).
>
>     Regardless of …
>
> Second, like when addressing Gunter Van de Velde’s review, we have 
> made the following two updates in the earlier Section 2.1.1 “CoAP 
> Group” as below.
>
> OLD
>
>     A CoAP group is defined as a set of CoAP endpoints, where each
>     endpoint is configured to receive CoAP group messages that are
>     sent to the group’s associated IP multicast address and UDP port.
>     That is, CoAP groups have relevance at the level of IP networks
>     and CoAP endpoints.
>
>     An endpoint may be a member of multiple CoAP groups, …
>
> NEW (emphasis mine)
>
>     A CoAP group is defined as a set of CoAP endpoints, where each
>     endpoint is configured to receive CoAP group messages that are
>     sent to the group’s associated IP multicast address and UDP port.
>     That is, CoAP groups have relevance at the level of IP networks
>     and CoAP endpoints.
>
>     This is aligned with the notion of CoAP endpoint as identified by
>     an IP address and a UDP port number, both for unsecure group
>     communication using the NoSec mode and secure group communication
>     using Group OSCORE. In either case, the default port number is 5683.
>
>     An endpoint may be a member of multiple CoAP groups, …
>
> and
>
> OLD
>
>     A CoAP group is identified by information encoded within a group
>     URI. Further details on identifying a CoAP group are provided in
>     Section 2.2.1.1.
>
> NEW (emphasis mine)
>
>     A CoAP group is identified by information encoded within a group
>     URI, which can contain a UDP port number in the authority
>     component (see Section 1.2). If no UDP port number is present,
>     then the port number used to identify the CoAP group is the
>     default port number 5683.
>
>     Consequently, a configuring entity can choose to rely only on IP
>     multicast addresses (or corresponding hostnames) in order to
>     practically identify different CoAP groups, without specifying
>     port numbers. As a result, those CoAP groups will be identified by
>     a pair (IP address, port number), where different CoAP groups use
>     a different IP multicast address and all use the same default port
>     number 5683.
>
>     Further details on identifying a CoAP group are provided in
>     Section 2.2.1.1.
>
> [1] 
> https://mailarchive.ietf.org/arch/msg/core/SG7fpMILV2a4qrJYHz0xhUw-V50/
>
> [3] 
> https://github.com/core-wg/groupcomm-bis/commit/330949121919a790a6397a095221b883de79fdac#diff-e9763af996c2597da4d48083e55a8c2d9e47750929f9f4b785b81bd041d44b93R382-R383
>
> [4] https://github.com/core-wg/groupcomm-bis/pull/50
>
>
> EV> again a little hard to see the final result from the pieces, but 
> this looks promising at least ;-)
>
>     ### Section 2.2.3.2 Please add the addresses rather than `to the
>     "All CoAP Nodes" multicast address (see Section 12.8 of
>     [RFC7252])` and forcing readers to jump to another RFC ;-) (but
>     keep the reference of course)
>
>
> Ok, we have rephrased as below:
>
> OLD
>
>     As discussed below, such a GET request may be sent to the IP
>     multicast address of an already known CoAP group associated with
>     one or more application groups; or to the “All CoAP Nodes”
>     multicast address (see Section 12.8 of [RFC7252]), thus targeting
>     all reachable CoAP servers in any CoAP group. Also, the GET
>     request may specify a query component, in order to filter the
>     application groups of interest.
>
> NEW
>
>     As discussed below, such a GET request may be sent to the IP
>     multicast address of an already known CoAP group associated with
>     one or more application groups. Alternatively, the GET request may
>     be sent to the “All CoAP Nodes” IPv4 multicast address 224.0.1.187
>     or IPv6 multicast address ff0x::fd (see Section 12.8 of
>     [RFC7252]), thus targeting all reachable CoAP servers in any CoAP
>     group. Also, the GET request may specify a query component (see
>     Section 4.1 of [RFC6690]), in order to filter the application
>     groups of interest.
>
>
> EV> thanks
>
>     ### Section 3.4 Does the IETF really want to have a PS with `One
>     way to create multiple CoAP groups is using different UDP ports
>     with the same IP multicast address` ? At least over Wi-Fi, this
>     could easily kill the devices batteries (even those of non-members).
>
>
> The paragraph that includes the quoted text is already discussing that 
> this is inconvenient in terms of additional, wasted processing. At the 
> same time, it might be the only viable option, if the number of 
> available multicast addresses is very limited, which can be the case 
> in constrained device IPv6 stacks.
>
> We have updated the paragraph as below, making that an exception to 
> something otherwise not recommended:
>
> OLD
>
>     One way to create multiple CoAP groups is using different UDP
>     ports with the same IP multicast address, in case the devices’
>     network stack only supports a limited number of multicast address
>     subscriptions. However, it must be taken into account that this
>     incurs additional processing overhead … discarded at the UDP layer
>     by most nodes.
>
> NEW (emphasis mine)
>
>     It is NOT RECOMMENDED to create multiple CoAP groups by using
>     different UDP ports with the same IP multicast address. An allowed
>     exception is the presence of constrained devices whose network
>     stack only supports a limited number of multicast address
>     subscriptions. The use of such an approach for creating CoAP
>     groups incurs additional processing overhead … discarded at the
>     UDP layer by most nodes.
>
>
> EV> superb :-)
>
>     ### Section 3.9.2 Should a reference be added for IEEE 802.15.4 ?
>
>
> Yes. We have updated the first paragraph in Section 3.9.2 to use the 
> following informative reference:
>
>     IEEE, “802.15.4-2024 - IEEE Standard for Low-Rate Wireless
>     Networks”, DOI 10.1109/IEEESTD.2024.10794632, December 2024,
>     https://ieeexplore.ieee.org/document/10794632.
>
> We have also updated the text in Section 3.6.1 to use the same 
> reference, i.e.:
>
> OLD
>
>     the default is calculated based on a baseline IEEE 802.15.4
>     6LoWPAN network situation …
>
> NEW
>
>     the default is calculated based on a baseline IEEE 802.15.4
>     [IEEE802.15.4] 6LoWPAN network situation …
>
>     _______________________________________________ core mailing list
>     -- [e-mail] To unsubscribe send an email to [e-mail]
>
>
> --
> *IoTconsultancy.nl* | Email/Teams: [e-mail] | +31 6 
> 2385 8339
>

-- 
*IoTconsultancy.nl* | Email/Teams: [e-mail] | +31 6 
2385 8339