[core] Re: AD review of draft-ietf-core-groupcomm-bis

[Marco Tiloca <[e-mail]>]

Hello Mike,

Thanks a lot for your review! Please see in line below our detailed reply.

We have addressed your comments in the latest version -14 available at [0].

Best,
/Marco


[0] https://datatracker.ietf.org/doc/html/draft-ietf-core-groupcomm-bis-14


Marco Tiloca
Ph.D., Senior Researcher

Phone: [phone]

RISE Research Institutes of Sweden AB
Box 1263
164 29 Kista (Sweden)

Division: Digital Systems
Department: Computer Science
Unit: Cybersecurity

https://www.ri.se

________________________________
From: Mike Bishop <[e-mail]>
Sent: Wednesday, June 18, 2025 6:08 AM
To: [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>; francesca.palombini <[e-mail]>
Subject: Re: AD review of draft-ietf-core-groupcomm-bis

Since dns-over-coap was turned around so quickly, I'm following up on this one to ensure I didn't miss a reply. I see -13 was posted after Francesca forwarded this review, but most of this still applies.

________________________________
From: Francesca Palombini <[e-mail]>
Sent: Monday, March 10, 2025 7:43 AM
To: Mike Bishop <[e-mail]>; [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: AD review of draft-ietf-core-groupcomm-bis


Hi authors, wg,



Mike, as incoming AD, has completed a review of the groupcomm-bis document. Please see his comments below (fw with permission), and consider them as the AD review, as he will be taking over soon.

Francesca



From: Mike Bishop <[e-mail]>
Date: Thursday, 6 March 2025 at 21:49
To: Francesca Palombini <[e-mail]>
Subject: Review of draft-ietf-core-groupcomm-bis

Overall, a good document that lays out the protocol clearly. I read through it a bit per day as other work permitted, and I'm shooting my notes in your direction. I'll have to pick up the pace for IESG reviews, obviously!



I had a lot of nits, but my biggest high-level critique was that this bis document eliminates a lot of text from the original that helped set CoAP in context with HTTP and describing how group communication is expected to be used in deployment. As someone only lightly familiar with CoAP, I found the original text useful in understanding the context of the document and was surprised not to see equivalent text in the introduction of the bis document. Appendix A appears to have a list of scenarios and is forward referenced in the Introduction, which helps some.



==>MT

Most of that content ended up spread over Section 3.9, Section 3.10, and Appendix A in the draft. However, we agree that the abstract and introduction started abruptly with what this document is about, without providing much context.

We have extended the abstract and introduction, using revised phrasing from the abstract and introduction of RFC 7390.

<==


In 2.2.1.1, an example from RFC7390 is referenced, but this document replaces 7390. I would consider importing the examples to this document. It appears that you already have an example grouping in 2.1.4; could this example be expanded to cover this case?



==>MT

We have made the following updates to Section 2.2.1.1. As explained further below, we have made further, similar updates in other sections, by importing examples originally defined in RFC 7390.

Minor things have been revised in the imported text and figures are now in AASVG :-)

In Section 2.2.1.1, we replaced the last paragraph with the table and final paragraph at the end of Section 2.2 of RFC 7390. For consistency, we changed the ending of the registered domains mentioned in the table, from ".example.com" to ".example".

As to Section 2.1.4, we think that it is better to leave this section as is. Its example considers the three types of groups together, while the comment is specifically about CoAP groups, hence pertinent to Section 2.2.1.1 where it has been addressed better.

As to Appendix A.1.3, this appendix was simply pointing to an example given by Section 3.3 of RFC 7390. We have imported that example here, which in turn required first to import the topology example from Section 3.2 of RFC 7390. The update performed to Appendix A.1.3 can be summarized as below.

As to Appendix A.2.1, we have taken the content of Section 3.4 of RFC 7390 and brought it here in Appendix A.2.1.

<==


5.1 makes it clear that the sender is authenticated in OSCORE, with more discussion in 6.2.2. However, this isn't clearly stated in 2.1.3, which initially leaves open the question of impersonation using the shared keying material, particularly since it talks about handling authorization separately. Consider moving some of the OSCore intro earlier in the document and/or having an explicit forward reference for more detail.



==>MT

We have added the following paragraph at the end of Section 2.1.3.

NEW
When a security group uses the security protocol Group OSCORE [I-D.ietf-core-oscore-groupcomm] to protect group communication (see Section 5 of this document), source authentication is achieved for messages exchanged within the group (see Section 5.1 and Section 6.2.2 of this document). That is, even though the endpoints in the security group do share group security material, a recipient CoAP endpoint is able to verify that a message protected with Group OSCORE has actually been originated and sent by a specific and identified CoAP endpoint as a member of the security group.

<==


Nits follow:



In 1.3, is "admits" the correct word? Perhaps "allows" or "permits"? Or if this is usage that was already happening outside the specification, perhaps "acknowledges"?



==>MT

The intended meaning goes beyond simply "acknowledges", see e.g., the text in Section 3.9.2. We have replaced "admits" with "allows", as it is what we have meant all along.

<==


In 2.2.1.2, consider scoping the "always maps to exactly one application group" statement. In context, I believe this is only meant to apply when the URI authority component method is used, but it could be misconstrued as contradicting 2.1.4's 1..N:1..N relationship.



==>MT

Quoting the whole paragraph for completeness:

> Because the CoAP group is also defined by the same authority component (see Section 2.2.1.1), a given CoAP group always maps to exactly one application group. (See Section 2.1.4 for background on group relationships.)

The quoted text specifically refers to the method using the URI authority component, as its indentation suggests. Of course, its scope can be made more explicit.

However, there is no contradiction with the "2.1.4's 1..N:1..N relationship" shown in Figure 1 of Section 2.1.4. **Regardless of the method used to name it**, a given application group is supposed to rely on a single CoAP group. In fact, Figure 1 shows that as a **1..N:1** relationship (not 1..N:1..N).

The quoted text stresses that the **1..N:1** relationship holds also in this particular case where, just like the CoAP group, also the application group is identified by (part of) the URI authority component. This clarification is not required for the methods based on the URI path or query component, which are not used for naming a CoAP group.

That said, the current quoted text says:

> ..., a given CoAP group always maps to exactly one application group.

Instead, it should be the opposite:

> ..., a given application group always maps to exactly one CoAP group.

Taking all into account, the paragraph has been rephrased as below.

OLD:
Because the CoAP group is also defined by the same authority component (see Section 2.2.1.1), a given CoAP group always maps to exactly one application group. (See Section 2.1.4 for background on group relationships.)

NEW (emphasis mine):
Because the CoAP group is also defined by the same authority component (see Section 2.2.1.1), **even when using this method,** a given application group is always associated with exactly one CoAP group. (See Section 2.1.4 for background on group relationships.)

Note also the sentence towards the end of Section 2.2.3.2 (emphasis mine):

> For each application group, **the** associated CoAP group is obtained as the URI authority component of the corresponding returned link.

<==


2.2.1.3:

- "specific of" => "specific to"?

- "request for" => "request"



==>MT

Fixed.

<==


In 2.2.2, "used to configure" could be interpreted as either the address that has been selected for the group or as being used to perform the configuration. I assume not the latter sense as the previous paragraph described that no such protocol is deployed, but a different wording might still be clearer. Maybe simply s/to configure/for/?

==>MT

Quoting the whole paragraph:

> For IPv6 CoAP groups, common multicast address ranges that are used to configure group addresses from are ff1x::/16 and ff3x::/16.

The proposed substitution as-is does not seem to build a parsable sentence. We have made the following, alternative rephrasing:

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

<==



2.2.3.2:

- "As exclusively intended to support examples throughout this document" is a bit obtuse and similar phrasing occurs several times. Should this be "In examples in this document"?

==>MT

That wording was used to strongly avoid any doubt and not suggest that the URI path segments and resource types were in any sense recommended or to be considered as default.

We have rephrased by using a simpler wording as follows:

OLD Section 2.2.3.2:
> As exclusively intended to support examples throughout this document, the path segment "gp" is used as designated delimiter.

NEW Section 2.2.3.2:
> In examples in this document, the path segment "gp" is used as designated delimiter.

OLD Section 2.2.3.2:
> As exclusively intended to support the examples presented in the following, this document considers such values for the attribute "rt" to have the semantics "g.<GROUPTYPE>", where GROUPTYPE denotes the type of the application group in question.

NEW Section 2.2.3.2:
> In examples presented in the following, this document considers such values for the attribute "rt" to have the semantics "g.<GROUPTYPE>", where GROUPTYPE denotes the type of the application group in question.

OLD Appendix C.1:
> The semantics "g.<GROUPTYPE>" for the values of the attribute "rt" is exclusively intended to support examples in this document.

NEW Appendix C.1:
> The example semantics "g.<GROUPTYPE>" is used for the values of the attribute "rt".

OLD Appendix C.4:
> The semantics "g.<GROUPTYPE>" for the values of the attribute "rt" is exclusively intended to support examples in this document.

NEW Appendix C.4:
> The example semantics "g.<GROUPTYPE>" is used for the values of the attribute "rt".

<==


- 2.2.1.2 discussed three means of identifying an application group from a URI; this assumes only one. Are there examples of the others? Is this one preferred?



More generally, this section states a number of assumptions that the client must already have made before it can discover the groups. The last paragraph of the section addresses this, but after having read the section and been confused by these assumptions. Consider moving this to the start of the section to clarify that this is an illustrative example of a particular deployment, not something specified by the protocol. Given that this section is intended to be normative (per Section 1), also consider whether more of this example should move to the associated (non-normative) Appendix.

==>MT

On the first point of the comment:

* The method that uses the URI path component for naming application groups is the only one considered in this section, and it is RECOMMENDED in Section 2.2.1.2 where it is defined.
* Examples of the different approaches for **naming** application groups are given in Appendix B.
* Consistent with this Section 2.2.3.2, Appendix C gives examples of the different approaches for **discovering** application groups, building on the assumptions of this Section 2.2.3.2, including the use of the URI path component for naming application groups.
* We see little value in having also examples of discovering of application groups where the application groups are identified by using the URI query or authority component.

On the second point of the comment, the last paragraph "Note that the specific ... as group members" has been moved up (with some needed rephrasing), right before the sentence "Full examples for the different methods are provided in Appendix C."

OLD:
> Note that the specific way of using the above methods, including the ways shown by the examples in Appendix C.4, is application-specific. That is, there is currently no standard way of encoding names of application groups and CoAP groups in group URIs and/or CoRE target attributes used with resource links. In particular, the discovery of application groups and CoAP groups through the RD mentioned in Section 2.2.3.1 is only defined for use with an RD, i.e., not directly with CoAP servers as group members.

NEW:
> Note that the specific way of using the methods discussed below is application-specific. That is, there is currently no standard way of encoding names of application groups and CoAP groups in group URIs and/or CoRE target attributes used with resource links. In particular, the discovery of application groups and CoAP groups through the RD mentioned in Section 2.2.3.1 is only defined for use with an RD, i.e., not directly with CoAP servers as group members.

On the final sentence in the comment, we don't think that content from this section should be moved to an Appendix. The content of this section is normative, as it discusses discovery approaches that are part of the specified protocol.

What is just an example here is the set of assumptions on:
* Using the URI path component for naming application groups, with "gp" as delimiter segment.
* Using the rt= target attribute to indicated the group type, according to the semantics "g.<GROUPTYPE>"

These example assumptions make the discussion of the discovery approaches practical in this section and are later on inherited in Appendix C when providing more detailed examples of group discovery through message exchanges.

<==


3.1.2: "to be appropriate, as useful" seems like an incomplete edit


==>MT

OLD:
It is RECOMMENDED that a server supporting this option only takes it into account when processing requests that target resources for which influencing the default suppression has been predetermined to be appropriate, as useful in the application context.

NEW (emphasis mine):
It is RECOMMENDED that a server supporting this option only takes it into account when processing requests that target resources for which influencing the default suppression has been predetermined to be appropriate, **as well as useful,** in the application context.

<==


3.2: Reword the first paragraph?

==>MT

Quoting the paragraph:

> CoAP endpoints that are members of a CoAP group MAY cache responses to a group request as defined in Section 5.6 of [RFC7252]. In particular, these same rules apply to determine the set of request options used as "Cache-Key".

We have rephrased as follows, avoiding the word "rules":

NEW:
> CoAP endpoints that are members of a CoAP group MAY cache responses to a group request as defined in Section 5.6 of [RFC7252]. The set of request options used as "Cache-Key" is also as defined in Section 5.6 of [RFC7252].

<==



3.2: CoAP, like HTTP, supports the same endpoint exposing different resources differentiated by the hostname in the URI (using the Uri-Host option). How does the process of "replacing the authority component of the request URI with the transport-layer source address" interact with this? Does the client still send the group hostname in the revalidation request? If so, this should be stated, since modifying the URI would normally imply modifying/removing the Uri-Host option.

==>MT

Quoting the whole paragraph (emphasis mine).

> A client sending a GET or FETCH group request MAY use a response received from a server, to satisfy a subsequent sent request intended to that server on the related unicast request URI. In particular, **the unicast request URI is obtained by replacing the authority component of the request URI with the transport-layer source address of the cached response message**.

The client does not send the group hostname in the second, unicast request (*).

In the unicast URI targeted by the second request, the host sub-component of the authority component specifies the IP address that was used as source IP address for the response to the group request.

When actually building that unicast request as a CoAP message, the target URI is decomposed into CoAP options added to the request, as per Section 6.4 of RFC 7252. With particular reference to Step 5 in that section, a Uri-Host option is not going to be included in that unicast request, since the host sub-component in the authority component of the unicast URI is an IP address equal to the destination IP address of the request.


(*) The discussed request is not a "revalidation request". Response validation is a separate thing, based on sending a request that specifies one or more ETag values as corresponding ETag options, as detailed in Section 3.2.2.1.

<==


"Forward proxies" and "reverse proxies" aren't generally hyphenated in HTTP; probably they shouldn't be here either.

==>MT

The two terms are hyphenated in CoAP (see their definition in Section 1.2 of RFC 7252) and have consistently been used hyphenated in CoAP-related documents, including in RFC 8075 "Guidelines for Mapping Implementations: HTTP to the Constrained Application Protocol (CoAP)".

<==



3.2.1: Is the reference for proxy caching actually non-normative? If this document didn't attempt to specify proxy behavior and was merely pointing out where the proxy spec was, definitely, but proxy behavior is defined in Section 3.5.

==>MT

Building on RFC 7252 and on the to-be-replaced RFC 7390, Section 3.5 of the present document does define how proxies operate in a group communication setup, as to some basic, general aspects such as:

* Building and using the URI of the request to forward.

* The need for identifying the client as authorized to have a group request proxied.

* General error handling.

As noted in the present document, deploying proxies in such setups results in particular issues and limitations, which the WG editorially preferred to have discussed in Appendices E and F to avoid overloading the document body.

While the present document is simply limited to specifying the basic, general aspects of proxy operations and to highlighting their issues and limitations, the document [1] defines **a** particular method that addresses those issues and **can** specifically be used.

The issues in question are largely about: for how long the proxy should forward responses to a group request back to the client, and according to what delivery approach; how the client can distinguish the different forwarded responses and their originators.

Addressing the latter issue concretely enables the client to benefit of caching (see Section 3.2 of the present document). In addition, as also mentioned in Section 3.2, [1] also defines **a** particular validation model that **can** be specifically used when caching at proxies.

Therefore, we did see it appropriate to have [1] informatively referred to by this document, which instead focuses on specifying the small, common denominator concerning proxies for CoAP group communication that further documents other than [1] might also build on in the future.


[1] https://datatracker.ietf.org/doc/draft-ietf-core-groupcomm-proxy/

<==



3.5.3:

- "each and every of" => "each of"

- Does assigning the proxy P and the server S letters actually add anything here? They don't appear to be referenced.



==>MT

We have made the change s/each and every of/each of

On the second comment, we have rephrased as follows:

OLD
> As a result, each server S accepts only the first copy of the group request received from one of the proxies, say P, while discarding as replay any later copies received from any other proxy.
>
> After that, the server S can reply to the accepted request with multiple responses over time (see Section 3.1.6). All those responses are sent to the same proxy P that forwarded the only accepted request, and that in turn relays those responses to the client.

NEW
> As a result, each server accepts only the first copy of the group request received from one of the proxies, while discarding as replay any later copies received from any other proxy.
>
> After that, the server can reply to the accepted request with multiple responses over time (see Section 3.1.6). All those responses are sent to the same proxy that forwarded the only accepted request, and that in turn relays those responses to the client.

<==


3.6:

- s/respond to/respond/?



==>MT

Yes, we have rephrased as follows.

OLD:
A server may choose not to respond to an IP multicast request if there is nothing useful to respond to, ...

NEW:
A server may choose not to respond to an IP multicast request if there is nothing useful to respond, ...

<==


3.10.1: MLD (not v2) and IGMP (not v3) are mentioned in the section heading, but not the text. Should either the versioned or unversioned names be omitted from the heading?

==>MT

"MLD" is actually used (without version number) in the last paragraph. However, that text refers to RFC 6636, which is specifically about the tuning of MLDv2. Actually, RFC 6636 is also about the tuning of IGMPv3

We have made the following changes:

OLD (section title):
MLD/MLDv2/IGMP/IGMPv3

NEW (section title):
MLDv2 and IGMPv3

OLD (last paragraph):
The guidelines from [RFC6636] on the tuning of MLD for mobile and wireless networks may be useful when implementing MLD in constrained networks.

NEW (last paragraph):
The guidelines from [RFC6636] on the tuning of MLDv2 and IGMPv3 for mobile and wireless networks may be useful when implementing MLDv2 and IGMPv3 in constrained networks.

We have also replaced the references to RFC3810 with references to the recently published RFC9777 obsoleting the former.

We have also replaced the references to RFC3376 with references to the recently published RFC9776 obsoleting the former.

<==



3.10.3: "also other ... may" => "other ... may also"

==>MT

Yes, we have rephrased as follows:

OLD:
also other filtering criteria may be

NEW:
other filtering criteria may also be

<==



5.3: In an HTTP reverse proxy, the client isn't aware of the servers behind the reverse proxy. It seems that end-to-end asymmetric encryption should work, since the client encrypts with its private key and all others in the security group can read; should there be text about how pairwise keys work in this case, if that's supported?

==>MT

There is no "asymmetric encryption" in Group OSCORE. Encryption is always symmetric, either:

* Using a sender key derived from group-shared security material, followed by a signature by means of the sender's private key (group mode).
* Using a pairwise sender key derived from the asymmetric authentication credentials of the sender and the individual intended recipient (pairwise mode).

In the first case (group mode), all the members of the group can indeed decrypt the message and verify its signature. In the second case (pairwise mode), only the individual intended recipient in the group can decrypt and verify the message.

So the group mode and the pairwise mode provide group-level confidentiality and pair-level confidentiality, respectively. Also, both the group mode and the pairwise mode provide source authentication of protected messages.

End-to-end security through Group OSCORE as described above applies in the same way to the case with a forward-proxy and to the case with a reverse-proxy, as noted at the end of the third paragraph in Section 5.3.

<==



6.1: "Therefore ..., also in order to prevent...." => "For these reasons and in order to prevent..., ...."

==>MT

Yes, we have rephrased as follows.

OLD:
Therefore, it is NOT RECOMMENDED to use CoAP group communication in NoSec mode, also in order to prevent proliferation of high-volume amplification attacks as further discussed in Section 6.3.

NEW:
For these reasons and in order to prevent proliferation of high-volume amplification attacks as further discussed in Section 6.3, it is NOT RECOMMENDED to use CoAP group communication in NoSec mode.

<==



6.2.3:

- "be often correctly inferable" => "often be correctly inferred"

- "assert" => "confirm" or "verify"?

- "prevents that ... can be" => "prevents ... from being"



==>MT

Yes, we have rephrased as follows.

* s/be often correctly inferable/often be correctly inferred

* s/can assert that the/can verify whether the

* Changed as

  OLD:
  Group OSCORE prevents that any single member of an OSCORE group can be used as a target for subverting ...

  NEW:
  Group OSCORE prevents any single member of an OSCORE group from being a target for subverting ...

<==


Abbreviation "6LBR" is used multiple times without definition. Based on context, I'm assuming "6LoWPAN Border Router"? Expand on first use, possibly with a reference to another document if warranted.

==>MT

Yes, "6LBR" stands for "6LoWPAN Border Router". An authoritative reference that mentions it in its terminology section is RFC 6775.

"6LBR" appears for the first time in Section 3.10.2, where we have made the following rephrasing:

OLD:
The same DAO mechanism can be used by an edge router (e.g., 6LBR) to learn CoAP group membership information ...

NEW:
The same DAO mechanism can be used by an edge router such as a 6LoWPAN Border Router (6LBR, see [RFC6775]), in order to learn CoAP group membership information ...

<==



6.8.2: "many multiple" -- choose one

==>MT

The original sentence is:

> since the same packet may be replicated over many multiple links.

We have rephrased to use "many links", i.e., the same wording used in Section 5.4.2 of RFC 7390.

<==



B: The IPv6 address ff35:30:2001:db8:f1::8000:1 should be ff35:30:2001:db8:f1:0:8000:1; see Section 4.2.2 of RFC 5952.

==>MT

Good catch! We have fixed the four instances at:

* Section 2.2.1.2 (2 instances)

* Appendix B (1 instance)

* Appendix B.1 (1 instance)

<==



E: "capable to forward" => "able to forward" or "capable of forwarding"

==>MT

We have rephrased to use "capable of forwarding".

<==

==>MT

Thanks again for this review!

<==