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

[Esko Dijk <[e-mail]>]

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 tohttps://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.


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

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.



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

> ### 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 …



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


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


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


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



> ### 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 [e-mail]

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