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

[Francesca Palombini <[e-mail]>]

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.

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?

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.

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"?

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.

2.2.1.3:
- "specific of" => "specific to"?
- "request for" => "request"

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/?

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

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

3.2: Reword the first paragraph?

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.

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

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.

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.

3.6:
- s/respond 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?

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

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?

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

6.2.3:
- "be often correctly inferable" => "often be correctly inferred"
- "assert" => "confirm" or "verify"?
- "prevents that ... can be" => "prevents ... from being"

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.

6.8.2: "many multiple" -- choose one

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.

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