Message-ID: <e25c725e-0cf9-4e22-bba3-ab153c2a2a5a@iotconsultancy.nl>
Date: Fri, 19 Dec 2025 11:38:59 +0100
MIME-Version: 1.0
To: Mohamed Boucadair <mohamed.boucadair@orange.com>, The IESG <iesg@ietf.org>
References: 
 <175915494983.2312240.11243640809895187155@dt-datatracker-6c6cdf7f94-h6rnn>
Content-Language: en-US
From: Esko Dijk <esko.dijk@iotconsultancy.nl>
Organization: IoTconsultancy.nl
In-Reply-To: 
 <175915494983.2312240.11243640809895187155@dt-datatracker-6c6cdf7f94-h6rnn>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID-Hash: VTZD3QBY3GSLWE6MMZMTEVEE7MTMUUEU
CC: draft-ietf-core-groupcomm-bis@ietf.org, core-chairs@ietf.org,
 core@ietf.org
Precedence: list
Subject: =?utf-8?q?=5Bcore=5D_Re=3A_Mohamed_Boucadair=27s_Yes_on_draft-ietf-core-grou?=
 =?utf-8?q?pcomm-bis-15=3A_=28with_COMMENT=29?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/core/kI445E07Q69uTR3VhO-9HRHxofc>

Hello Med,

Many thanks for reviewing our document. Below inline are the 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.

best regards,
Esko & Marco

[PR]  https://github.com/core-wg/groupcomm-bis/pull/57


On 29-9-2025 16:09, Mohamed Boucadair via Datatracker wrote:
> Mohamed Boucadair has entered the following ballot position for > draft-ietf-core-groupcomm-bis-15: Yes > > 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/ > > > > 
---------------------------------------------------------------------- > 
COMMENT: > 
---------------------------------------------------------------------- > 
 > > > > > Hi Esko & Marco, > > Many thanks for the effort put into this 
specification. > > The document is well-written. I enjoyed reading it. I 
appreciate the > thoughts and effort to identify and articulate the 
configuration > model and deployment considerations.
Good to hear!

> Please find some comments (ordered following the spec flow), fwiw. > Feel free to grab whatever useful.
We found your comments very useful; it will improve the document 
revision -16 we believe.

> # Implementation frozen in an RFC > > CURRENT: Notable CoAP implementations that support group > 
communication include "Eclipse Californium" [Californium], "Go- > CoAP" 
[Go-CoAP] as well as "libcoap" [libcoap]. > > This might be too late but 
following the guidance in rfc7942 would > be appropriate. Another option 
is to consider adding > related_implementation tag rather than having 
those frozen in an > RFC?
We took the second suggestion and made the following two updates.

First, we have removed the sentence in Section 1 quoted below and the 
three references used.

     Notable CoAP implementations that support group communication 
include “Eclipse Californium” [Californium], “Go-CoAP” [Go-CoAP] as well 
as “libcoap” [libcoap].

Second, we have updated the “Additional resources” section in the 
Datatracker page at [1], which now includes links to the three 
originally referred implementations, i.e.:

   * Implementation in Eclipse Californium - 
https://github.com/eclipse-californium/californium
   * Implementation in Go-CoAP - https://github.com/plgd-dev/go-coap
   * Implementation in libcoap - https://github.com/obgm/libcoap

[1] https://datatracker.ietf.org/doc/draft-ietf-core-groupcomm-bis/


> # Alternate solutions > > CURRENT: One example is Publish-Subscribe [I-D.ietf-core-coap- > 
pubsub] which uses a central broker server that CoAP clients access > 
via unicast communication. These alternative methods may be usable > for 
the same or similar use cases as the ones targeted in this > document. > 
 > Are there any guidance where the use of group communication is more > 
appropriate than these alternative mechanisms?
To add some guidance here, we have updated the text in Section 1.1 as below.

OLD

     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 alternative methods to achieve 
group communication using CoAP, using unicast only. One example is 
Publish-Subscribe …

NEW (*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. *Such solutions are desirable for 
applications that need a request message to be delivered with low 
latency and/or in a synchronous way to multiple recipient servers at 
once. For applications that do not have those requirements, there* are 
alternative methods to achieve group communication using CoAP, using 
unicast only. One example is Publish-Subscribe …

Note that the resolution of a comment from the INTDIR review [2] affects 
the beginning of that paragraph. Taking both comments into account, the 
final text will read as below.

FINAL TEXT TO APPEAR

     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. Such 
solutions are desirable for applications that need a request message to 
be delivered with low latency and/or in a synchronous way to multiple 
recipient servers at once.

     For applications that do not have those requirements, there are 
alternative methods to achieve group communication using CoAP, using 
unicast only. One example is Publish-Subscribe …

[2] https://mailarchive.ietf.org/arch/msg/core/DoUzobQIIUyKBf32q_Jm0trSiBU/

> # ASM-only > > CURRENT: Only the Any Source Multicast (ASM) mode [RFC5110] of IP 
 > multicast operation is in scope. > > I naively thought that having an 
SSM-like mode would be more > appropriate if we want to better control 
who issue the requests. For > example, a controller will behave as a 
CoAP client in such case.
A controller still behaves as a CoAP client in the ASM model. Actuators 
that are not programmed to send out requests will not send out requests, 
so there is no need to control that from their own point of view.

When it comes to security (i.e., source authentication of a message and 
identification of its sender), the knowledge of which endpoint can send 
messages is public. So anyone can spoof the “controller” IP address. 
Instead, source authentication of a message and identification of its 
sender is achieved by using a secure communication protocol, i.e., Group 
OSCORE in this case.

As to SSM, it is typically not implemented in constrained systems/nodes. 
Like in RFC 7390, it is not in the scope of the present document, about 
which we have elaborated in our reply to the TSVART review, see 
https://mailarchive.ietf.org/arch/msg/core/TrRHRrhlj67twA4vChfC-sx9fs8/

While we do not see any fundamental problem using SSM with CoAP 
multicast, there would however be some practical issues:

* A CoAP server would be required to know the IP address of the CoAP 
client (source), which would require to define how sources can be 
discovered in constrained/IoT applications.
* If a proxy is deployed between client and servers, the source address 
of the proxy would be required to be known instead of the origin 
client’s address. We would prefer to not go into such details, since we 
do not currently anticipate constrained/IoT use cases making use of SSM.


> # Demux for Multiple groups > > CURRENT: A node may be a member of multiple CoAP groups, by 
hosting > multiple CoAP server endpoints on different UDP ports. > > Why 
not considering distinct addresses (typically, IPv4 and IPv6) as > 
another way to support that? what is that restricted to port numbers > 
only?
We have updated the text to mention the different possibilities early 
on, in the first sentence of that paragraph.

OLD

     An endpoint may be a member of multiple CoAP groups, by subscribing 
to multiple IP multicast addresses. A node may be a member of multiple 
CoAP groups, by hosting multiple CoAP server endpoints on different UDP 
ports.

NEW (*emphasis* mine)

     An endpoint may be a member of multiple CoAP groups, *e.g.,* by 
subscribing to multiple IP multicast addresses. A node may be a member 
of multiple CoAP groups, by hosting multiple CoAP server endpoints on 
different *combinations of IP address and UDP port*.


> # Deployment assumptions > > CURRENT: There can be a many-to-many relationship between security 
 > groups and CoAP groups, but often it is one-to-one. Also, there can > 
be a many- ^^^^^^^^^ to-many relationship between security groups > and 
application groups, but often it is one-to-one. Such > relationships are 
discussed in more ^^^^^^^^^ detail in Section > 2.1.4. > > The “often” 
part may not be stand (in the future, all cases) as this > is 
deployment-specific. Maybe better to focus on protocol > implications to 
support such schemes. > > I wonder whether we can translate this into an 
operational > consideration such as a controllers/managers should be 
able to > associate multiple groups and avoid restriction by design. 
Also, > endpoints should be able to support such configuration.
When addressing this comment at first, and as tracked in the referred 
GitHub [PR], we have made the rephrasing below.

OLD

     There can be a many-to-many relationship between security groups 
and CoAP groups, but often it is one-to-one. Also, there can be a 
many-to-many relationship between security groups and application 
groups, but often it is one-to-one. Such relationships are discussed in 
more detail in Section 2.1.4.

NEW

     Between security groups and CoAP groups, there can be a 
many-to-many relationship or a one-to-one relationship. Also, between 
security groups and application groups, there can be a many-to-many 
relationship or a one-to-one relationship. Configuring entities can 
establish relationships between groups of different types as appropriate 
for the specific deployment and with no restriction by design. Endpoints 
that are members of security groups are expected to support all such 
relationships, which are discussed in more detail in Section 2.1.4.

However, the first sentence of the old text has been separately updated 
in the more specific PR #56, as below:

     Between CoAP groups and security groups, there can be a 
many-to-many, one-to-many, many-to-one, or one-to-one relationship. 
Also, between application groups and security groups, there can be a 
many-to-many, one-to-many, many-to-one, or one-to-one relationship.

That is, the final version of that paragraph would read as below:

     Between CoAP groups and security groups, there can be a 
many-to-many, one-to-many, many-to-one, or one-to-one relationship. 
Also, between application groups and security groups, there can be a 
many-to-many, one-to-many, many-to-one, or one-to-one relationship. 
Configuring entities can establish relationships between groups of 
different types as appropriate for the specific deployment and with no 
restriction by design. Endpoints that are members of security groups are 
expected to support all such relationships, which are discussed in more 
detail in Section 2.1.4.


> # Preference > > CURRENT: In this case, a CoAP client can join just one of the > 
security groups, based on what it supports and prefers, while a CoAP > 
server in the application group would rather have to join all of > them. 
 > > Is this a local decision or inferred from a local policy? Can we > 
translate this into an operational consideration for this matter?
Yes, the decision can be based on local policy or local configuration - 
constrained by the cryptographic capabilities of the client.

We have clarified by updating the text as below. The text itself is now 
an operational consideration; we do not think that we should go into any 
more detail here.

OLD

     … In this case, a CoAP client can join just one of the security 
groups, based on what it supports and prefers, while a CoAP server in 
the application group would rather have to join all of them.

     Beyond this particular case, …

NEW

     … In this case, a CoAP client can join a subset of these security 
groups, e.g., selected according to a local policy or determined by a 
local configuration. This subset needs to be consistent with the 
security algorithms that the client supports. A CoAP server in the 
application group has to join all of the security groups, in order to 
successfully process group requests from any CoAP clients that have been 
configured to use the application group. This particular case can be 
useful if different CoAP clients have different, incompatible 
requirements for the security algorithms that can be supported.

     Beyond this particular case, …


> > > # Access Policies > > CURRENT: In particular, it is NOT RECOMMENDED 
to use different > security groups to reflect different access policies 
for resources > in the same application group. > > IMO, there is nothing 
broken if that recommendation is not followed > for other reasons (e.g., 
isolation, ease troubleshooting). That is > up to a local deployment. 
The key message here should be that > security groups are not meant to 
enforce access policies; these are > enforced using other means.
Yes, access control to servers’ resources in the application group 
should be enforced by other means than security groups and the 
memberships to those.

Since the security groups are not meant to achieve that, we believe that 
it is still appropriate to normatively “not recommend” them for that task.

We have rephrased as below:

OLD

     In particular, it is NOT RECOMMENDED to use different security 
groups to reflect different access policies for resources in the same 
application group.

NEW

     In particular, different security groups are not meant to reflect 
different access policies, e.g., for enforcing access control to 
resources that are hosted at servers in the same application group. 
Therefore, it is NOT RECOMMENDED to simply take into account memberships 
to security groups as a way to enforce access control within an 
application group, which instead should rely on separate means.


> # UML > > CURRENT: Figure 1 summarizes the relationships between the 
different > types of groups described above in Unified Modeling Language 
(UML) > class diagram notation. > > Consider adding a reference for UML.
In Section 2.1.4, we have added the following informative reference 
about UML:

   * “OMG Unified Modeling Language (OMG UML) Version 2.5.1”, Document 
Number: formal/2017-12-05, Object Management Group Standards Development 
Organization, December 2017, https://www.omg.org/spec/UML/2.5.1/PDF


> # Figure 1 > > From a deployment perspective, which entity has to maintain this > 
view depicted in Figure 1?
The answer comes later in Section 2.2.2 “Group Creation and Membership”, 
which talks about a “configuring entity”.

In the present Section 2.1.4, we have added the sentence below right 
after the quoted sentence:

NEW

     When creating groups (see Section 2.2.2), a configuring entity 
follows and maintains the view depicted in Figure 1.


> # Conflicting actions > > CURRENT: These clients may be temperature/humidity sensors that > 
report measurements periodically to all HVAC devices (Srv5, Srv6) in > 
the Application Group 3, using for example /resC to report > temperature 
and /resD to report humidity. > > When an endpoint belongs to multiple 
application groups, but > conflict actions are being requested for each 
appl, how is that > handled but an endpoint?
The handling of conflicts is usually defined by the application protocol 
standard (if a standard is used) or by the vendor’s own rules.

Especially considering the “endpoint” in question as a server, the way 
it handles conflicts really depends on the (standard) application and 
the specific implementation, which can take into account, e.g., the 
security identity of the client sending a conflicting request, or a 
“priority value” conveyed in the request. It's also possible that 
different application groups are configured on the node with a mutual 
priority level, which is common in building control applications - e.g. 
to ensure an "emergency" controller gets priority above an "energy 
savings" controller for controlling lights.

We do not think that it is necessary to clarify this in the document, as 
it would likely introduce a distraction from the main points that the 
example is trying to present.


> # dual-stack > > CURRENT: The host subcomponent indirectly defines the IP multicast 
 > address of the CoAP group, in case the host consists of a hostname: > 
resolving the hostname to an IP address in this case produces the IP > 
multicast address. > > How this is supposed to work for dual stack 
hosts? I guess two > groups should be defined in such case? but.. > > 
CURRENT: For example, if the two hostnames group1.example and > 
group1.alias.example both resolve to the IP multicast address > 
[ff15::1234], then the following authority components are all names > 
for the same CoAP group. > > This may resolved to an IPv4/IPv6 multicast 
address. From IP > multicast perspective, these are distinct groups, but 
this text > seems to says that these should be handled as single one.
Indeed, a given hostname can resolve to multiple IP addresses, e.g., 
when using DNS. These can be IPv6 addresses, IPv4 addresses, or a mix of 
them. We'd like to cover all of these cases.

Building on this point, we have updated the “groups” model (as defined 
by Figure 1), to allow multiple CoAP groups to be associated with a 
single application group.

This also nicely covers the case that a single application group is used 
with different multicast IP addresses with different scopes at different 
times, such as ff02::fd for link-local scope or ff05::fd for site-local 
scope. CoAP discovery uses this pattern.

More details on this are in the CoRE email thread at [3].

The updates made to the document about this point are tracked in the 
separate PR #56 at [4].

[3] https://mailarchive.ietf.org/arch/msg/core/BIBTYia7EfYowmWXd9kjzunTjsw/
[4]  https://github.com/core-wg/groupcomm-bis/pull/56

> # Non-default port numbers > > CURRENT: Also note that, when using the "coap" scheme, the two > 
authority components <HOST> and <HOST>:5683 both identify the same > 
CoAP group, whose members listen to the CoAP default port number > 5683. 
 > > Do we allow to configure a distinct port number other than the > 
default one?
Yes. This is already covered in the later Section 2.2.2, which says:

     To create a CoAP group, a configuring entity defines an IP 
multicast address (or hostname) for the group and optionally a UDP port 
number in case it differs from the default CoAP port number 5683.


> # Dependency on DNS > > CURRENT: When configuring a CoAP group membership, it is 
recommended > to configure an endpoint with an IP multicast address 
literal, > instead of a group hostname. This is because an 
infrastructure > providing a name resolution service, such as DNS, may 
not be > deployed in many constrained networks. > > The first point is 
reasonable, as a generic statement. However, for > the second sentence, 
wouldn’t this be known to the entity that will > deploy the service?
Yes! We have clarified the reason for the recommendation with focus on 
the network load of name resolution queries (very relevant for 
constrained networks). We have rephrased the text in Section 2.2.1.1 as 
below:

OLD

     When configuring a CoAP group membership, it is recommended to 
configure an endpoint with an IP multicast address literal, instead of a 
group hostname. This is because an infrastructure providing a name 
resolution service, such as DNS, may not be deployed in many constrained 
networks. In case a group hostname is configured, …

NEW (*emphasis* mine)

     When configuring a CoAP group membership, it is recommended to 
configure an endpoint with an IP multicast address literal instead of a 
group hostname, *to avoid network load due to name resolution queries*. 
*In fact, an infrastructure providing a name resolution service, such as 
DNS, may not be deployed in many constrained networks. In such cases, 
using an IP multicast address literal is the only viable option for the 
configuring entity that creates a CoAP group.*

     *If* a group hostname is configured, …



> # Multiple channels > > CURRENT: An application group name can be explicitly encoded in a 
 > group URI. Specifically, it can be encoded within one of the > 
following URI components: > > Should this discuss the case where the 
info is provided in several > channels (may be a side effect of various 
configuring entities), > which one takes priority? At least the text can 
say this is not > recommended?
As we understand your comment, “in several channels” could mean that 
multiple configuring entities operate on a node at different times, and 
could possibly configure different URIs, all of which contain 
application group name information, but encoded using different methods, 
i.e., in different parts of the URI.

In such case, there would be no conflict, because, in practical 
situations like this, the last configuring entity “wins”, i.e., older 
configurations would be overwritten as soon as a new URI or a new 
application group name is provided.

In most practical implementations, there would be a single way in which 
a name is encoded in the URI, as determined by the software of the node, 
and it is not something that a configuring entity could change at 
runtime. Certainly, we do not expect that a node implementation would 
ever be dealing with trying to work with multiple (conflicting) app 
group names in a request at the same time.

So we do not think that the priority discussion needs to be introduced here.


> # Not encoded or encoded? > > CURRENT: Finally, it is also possible to not encode the 
application > group name in the CoAP request, yielding the most compact 
 > representation on the wire. > > I guess you ment “encode”?
No, we do mean “not encode” :-)

For clarity, we have rephrased as below.

OLD

     Finally, it is also possible to not encode the application group 
name in the CoAP request, yielding the most compact representation on 
the wire.

NEW (*emphasis* mine)

     Finally, it is also possible to *omit* the application group name 
*from* the CoAP request, yielding the most compact representation on the 
wire.


> # authorization request > > CURRENT: * A CoAP endpoint may have to request an authorization to 
 > join a specific security group through the respective Group Manager, 
 > > Can we provide examples how to do that?
This point is covered in the later Section 5.1 “Group OSCORE”, which says:

     As recommended in [I-D.ietf-core-oscore-groupcomm], a CoAP endpoint 
can join an OSCORE group by using the method described in 
[I-D.ietf-ace-key-groupcomm-oscore] and based on the ACE framework for 
Authentication and Authorization in constrained environments [RFC9200].

The sentence quoted in the comment actually continues by including a 
forward pointer to Section 5, i.e. (*emphasis* mine):

     A CoAP endpoint may have to request an authorization to join a 
specific security group through the respective Group Manager, *and thus 
obtain the required group security material (see Section 5)*.

We think that it is better to not make this paragraph longer and harder 
to read by explicitly pointing to [I-D.ietf-ace-key-groupcomm-oscore], 
which is anyway mentioned later in Section 5.1, in the presence of more 
and better context information for the reader.


> # Infer nosec mode from the name > > CURRENT: Indications that endpoints can use the NoSec mode MUST 
NOT > rely on setting up and advertising a pseudo security group with 
name > "NoSec" or any of its lowercase/ uppercase combinations. > > I 
would generalize and say that the (no)security mode MUST NOT be > 
inferred from the name (and then provide nosec and its variation as > an 
example).
We do not think that this can be generalized. This sentence is 
meaningful only to talk about the NoSec mode.

The whole section assumes that, irrespective of the name used, the group 
with that name is understood to be a security group in the first place. 
That said:

* This sentence is only and exactly about forbidding (practically fake) 
security groups that are named “NoSec” or “nosec” etc., as a convoluted 
and confusing way to say that unsecured group communication can be used.

* Conversely, if the name of a security group is distributed as 
identifying a security group to use, then secure group communication has 
to be used, in accordance with the configuration of that group.



> # Configuration scope > > CURRENT: The configuring entity can be, for example, a local > 
application with pre-configuration, a user, a software developer, a > 
cloud service, or a local commissioning tool. > > This seems to assume 
that the configuration origin may be any. There > are deployment 
implications of such model. > > If the configuration is done by an 
entity distinct from the one that > deploys, then there might be 
configuration conflicts and even > potential of stale configuration.
To highlight that, we have extended the quoted sentence as below.

OLD

     The configuring entity can be, for example, a local application 
with pre-configuration, a user, a software developer, a cloud service, 
or a local commissioning tool.

NEW (*emphasis* mine)

     *A* configuring entity can be, for example, a local application 
with pre-configuration, a user, a software developer, a cloud service, 
or a local commissioning tool. *In general, the creation of a CoAP group 
can involve multiple configuring entities that might be of different 
types. If the configuring entities are different from the ones entrusted 
with the device deployment, care has to be taken in order to avoid 
configurations that are conflicting or stale*.

In practical systems that are installed, the configuring entity can be 
limited severely e.g. to only a single actor. But in this draft we want 
to stay generic so it could be any of the listed ones.
Any systems that allow a mix of actors to (co)configure the system need 
to have software and/or procedures in place to avoid these potential issues.

> # Remind IPv4 address as well > > CURRENT: For IPv6 CoAP groups, common multicast address ranges 
from > which group addresses can be taken are ff1x::/16 and ff3x::/16. > 
 > I would also remind the IPv4 multicast address.
To address a comment in the review from Ketan Talaulikar [5], we have 
updated the text as below, in order to leave the choice to network 
operators and administrators. Therefore, there is no need to mention 
specific address ranges any more.

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://mailarchive.ietf.org/arch/msg/core/SG7fpMILV2a4qrJYHz0xhUw-V50/



> # Various configuring entities > > CURRENT: To create a security group, a configuring entity defines 
an > initial subset of the related security material. > > Do we assume 
that it is the same entity that configures/control all > the various 
app/sec/etc. groups?
That is not necessarily the case.

We have now added the following new paragraph at the beginning of 
Section 2.2.2:

NEW

     This section discusses the creation of different types of groups, 
as entrusted to a “configuring entity”. The same configuring entity can 
be responsible for creating groups of different types, e.g., both CoAP 
groups and application groups.



> > # Lack of mechanism to retrieve actual configuration > > CURRENT: The 
configuration of groups and membership may be performed > at different 
moments in the life-cycle of a device. For example, it > can occur 
during product (software) creation, in the factory, at a > reseller, 
on-site during first deployment, or on-site during a > system 
reconfiguration operation. > > Given that configuration may done by 
various entities (including > even a software dev as mentioned 
previously), there are some > implication on upgrading/maintaining the 
functionality in a given > network. Support of means to control/retrieve 
embedded > configuration, flushing it out, and also help with 
troubleshooting. > This feature is important for operations.
We have extended the quoted and last paragraph, by adding the text as below:

NEW

     These configurations are likely performed by different configuring 
entities, possibly with minimal or no coordination. Therefore, it is 
important that means are available and supported for controlling, 
retrieving, updating, and retiring configurations, as well as for 
performing related troubleshooting procedures. Further details on such 
means are out of the scope of this document.


> # GET access control > > CURRENT: 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. > > Does this means that every node can discover what is 
available in a > network? Shouldn’t some filtering be in place? > > 
Doesn’t this help to detect which applications to target by a > 
misbehaving node?
For completeness, the previous paragraph in the same section says:

     …, by using a GET request targeting the /.well-known/core resource.

As a first point, what is discoverable is what is available in the 
network AND has been decided to be discoverable, on a per-server basis. 
In RFC 7252, Section 7.2 “Resource Discovery” says:

     It is up to the server which resources are made discoverable (if any).

Furthermore, in RFC 6690 where the /.well-known/core resource is 
defined, Section 6 “Security Considerations” says:

     … The “/.well-known/core” resource MAY be protected, e.g., using 
Datagram Transport Layer Security (DTLS) when hosted on a CoAP server as 
per [COAP], Section 9.1.

     Some servers might provide resource discovery services to a mix of 
clients that are trusted to different levels. (…) Servers that have 
authentication and authorization features SHOULD support authentication 
features of the underlying transport protocols (HTTP or DTLS/TLS) and 
allow servers to return different lists of links based on a client’s 
identity and authorization. While such servers might not return all 
links to all requesters, not providing the link does not, by itself, 
control access to the relevant resource – a bad actor could know or 
guess the right URIs.

Essentially, it is possible to protect and authenticate the discovery 
process too, possibly with different filtering based on the verified 
identity of the requesting client.

We think that the security considerations compiled in RFC 6690 for 
accessing the /.well-known/core resource are simply valid to consider 
and we prefer to not make any restatement/re-explanation of those in the 
present document.



> # This is not a new behavior > > OLD: All CoAP requests that are sent via IP multicast MUST be Non- 
 > confirmable (NON), see Section 8.1 of [RFC7252]. > > NEW: All CoAP 
requests that are sent via IP multicast must be Non- > confirmable 
(NON), see Section 8.1 of [RFC7252]. > > This is redundant with RFC7252.
Yes, good point. In the same spirit, the text should actually be 
extended about being ready to receive Confirmable responses to those 
Non-confirmable requests.

We have rephrased the text in Sectoin 3.1.1 as below:

OLD (Section 3.1.1)

     All CoAP requests that are sent via IP multicast MUST be 
Non-confirmable (NON), see Section 8.1 of [RFC7252]. The Message ID …

NEW (Section 3.1.1, *emphasis* mine)

     All CoAP requests that are sent via IP multicast *must* be 
Non-confirmable (NON), see Section 8.1 of [RFC7252]. *Although a 
corresponding response should be returned in a Non-confirmable message 
as well, clients must be prepared to receive Confirmable responses in 
reply to those requests, see Section 5.2.3 of [RFC7252].* The Message ID …

Also for the same reason, we have turned “MUST” into “must” in three 
sentences that refer to Section 7.1 of RFC 7252, which defines the 
requirement for servers supporting resource discovery to support the 
default port number 5683.

OLD (Sections 3.4, 3.9.1, 3.9.3)

     … the default port number 5683 MUST be supported …

NEW (Sections 3.4, 3.9.1, 3.9.3)

     … the default port number 5683 must be supported …



> # Application context > > CURRENT: This document adds the requirement that a server SHOULD > 
suppress the response in case of error or in case there is nothing > 
useful to respond, unless the application related to a > 
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > 
particular resource requires such a response to be made for that^ > 
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > 
resource. > > How is this technically characterized? Is this managed by 
a policy?
Short answer: yes.

The sentence immediately before the quoted text says:

     A server MAY suppress its response for various reasons given in 
Section 8.2 of [RFC7252].

The beginning of Section 8.2 of RFC 7252 says (*emphasis* mine):

     When a server is aware that a request arrived via multicast, the 
server MAY always ignore the request, in particular if it doesn’t have 
anything useful to respond (e.g., if it only has an empty payload or an 
error response). *The decision for this may depend on the application.* 
(For example, in query filtering as described in [RFC6690], a server 
should not respond to a multicast request if the filter does not match. 
More examples are in [GROUPCOMM].)

We have now extended the quoted text with one more sentence as below 
(*emphasis* mine).

NEW

     …, unless the application related to a particular resource requires 
such a response to be made for that resource. *Such exceptions are 
application-specific and defined by corresponding application policies.*


> # Urgent? > > CURRENT: Therefore, it is more urgent to have a strategy in place 
 > for handling the loss of group requests than the loss of unicast > 
responses. > > What is the purpose of this text?
We have rephrased as below:

OLD

     Therefore, it is more urgent to have a strategy in place for 
handling the loss of group requests than the loss of unicast responses.

NEW

     Therefore, having a strategy in place for handling the loss of 
group requests is even more important than one for handling the loss of 
unicast responses.



> # Tokens > > CURRENT: The CoAP client then sends this group request using a > 
different Message ID (and the same or a different Token value), in > 
which case all servers that received the initial > > To what extent the 
use of same token is conflicting with RFC7252: > > The client SHOULD 
generate tokens in such a way that tokens > currently in use for a given 
source/destination endpoint pair are > unique.
The current text is not supposed to contradict the requirement in the 
quoted Section 5.3.1 of RFC 7252. If the same Token value is used, no 
new Token value is being generated. If a new Token value is used, that 
is supposed to happen by still complying with the requirement in the 
quoted Section 5.3.1 of RFC 7252.

We do not think that this needs to be explicitly clarified in the 
present document. That is, the pertinent requirement from RFC 7252 is 
silently inherited and it applies here too.


> # Delivery of responses > > CURRENT: Due to UDP level multiplexing, the UDP destination port > 
number of the response MUST match to the client endpoint's UDP port > 
number, i.e., to the UDP source port number of the client's request. > > 
In doing so, this response will traverse on-path devices with EIM/ > EIF 
(rfc4787). The response may be filtered if more restrictive > filtering 
is in place (EDF).
In Section 3.1.4, we have added the following new paragraph, right after 
the quoted one:

NEW

     Note that some responses to a group request might be filtered out 
and not reach the client if a NAT device is used with restrictive 
filtering in place. For example, this is the case if the NAT device 
employs “Endpoint-Dependent Filtering” (see Section 2.6 of [RFC5128]), 
i.e., the combination of “Address-Dependent Filtering” and “Address and 
Port-Dependent Filtering” as defined in Section 5 of [RFC4787].

(The new references to RFC 4787 and RFC 5128 are both informative)


> # Implementable? > > CURRENT: How the client in the case above determines the CoAP > 
servers that are currently members of the CoAP group is out of scope > 
for this document. > > How can the feature discussed in this section be 
implemented if we > don’t have a way to implement it? I expected some 
more explicit > behavior to be specified here as this is targeting STD 
tracks.
We do not think that “we don’t have a way to implement it”. We are just 
saying that the exact method used is out of scope for this document, and 
we are giving possible examples at least at a conceptual level.

As long as the client has *somehow* gained knowledge of the servers in 
the CoAP group, what is written in the previous paragraph MAY happen, 
according to the client’s local decision/knowledge. Otherwise it will 
not happen and there is a clear fallback that does not prevent 
interoperability or message exchange at all (it would just be a missed 
opportunity for a possible optimization).

We do not think that we (need to) care about whether and how the client 
is able to gain that knowledge, and we are suggesting realistic 
approaches to do so.

To make the text clearer, we have rephrased the quoted paragraph in 
Section 3.2.1 as below:

OLD

     How the client in the case above determines the CoAP servers that 
are currently members of the CoAP group is out of scope for this 
document. It may be, for example, via a Group Manager, or by monitoring 
group joining protocol exchanges.

NEW

     The client in the case above can use different possible methods to 
determine the CoAP servers that are currently members of the CoAP group. 
For example, consistent with enforced policies, the client can retrieve 
that information from the group’s configuring entity, or the client may 
be able to monitor group joining protocol exchanges. The specific method 
used by the client is out of the scope of this document.



> # dst port number > > CURRENT: the same port number is used as the destination port 
number > for requests across all CoAP servers that are members of a CoAP 
 > group and across all CoAP clients sending group requests to that > 
group. > > I guess we meant the dst port nb of multicast request (not 
dst of > responses from servers). I would make this clearer.
Indeed, which is consistent with the following text in Section 3.1.4:

     … the UDP destination port number of the response MUST match to the 
client endpoint’s UDP port number, i.e., to the UDP source port number 
of the client’s request.

Of course, the UDP source port number of the client’s request can be 
anything, as determined by the client’s application when sending the 
group request.

We have rephrased as below:

OLD

     Regardless of the method that is used for selecting the group’s 
port number, the same port number is used as the destination port number 
for requests across all CoAP servers that are members of a CoAP group 
and across all CoAP clients sending group requests to that group.

NEW (*emphasis* mine)

     Regardless of the method that is used for selecting the group’s 
port number, the same port number is used as the destination port number 
*by all CoAP clients when sending group requests to the CoAP group, thus 
addressing all CoAP servers that are members of that group.*


> # Tracking requests > > CURRENT: 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. > > This 
requires some tracking, which is needed anyway to store the > required 
info to forward a response back. > > I guess that tracking should be 
maintained for a minimum period that > would accommodate any 
reordering/delay in the network.
Yes, but the “tracking” is anyway already in place, as part of the 
replay protection provided by Group OSCORE through a per-client Replay 
Window at the server.

The first request from a given client that is both non-replayed and 
cryptographically verified is delivered to the server application, after 
which a response can follow as per the application intended behavior. 
Any further instance of the same request coming from a different proxy 
will be discarded by the server as a replay for Group OSCORE.

We have clarified by rephrasing as below, also extending the text in the 
paragraph immediately before the quoted one.

OLD

     In particular, each server is able to determine that all such 
received requests are copies of exactly the same group request.

     As a result, each server accepts only the first copy of the group 
request received from one of the proxies, …

NEW (*emphasis* mine)

     In particular, *by leveraging the replay protection provided by 
Group OSCORE*, each server is able to determine that all such received 
requests are copies of exactly the same group request.

     As a result, each server accepts only the first *verified* copy of 
the group request received from one of the proxies, …



> # TCP, TLS, and WebSockets > > This is more describing approaches to support this, but does not > 
specify an exact behavior. This can be better fit in an appendix, > IMO.
Not quite. The generic “pointing to approaches” is probably coming from 
the reference to draft-ietf-core-transport-indication (as to the 
discovery of proxies and available transports), but other pointers are 
specific to RFC 8323 as to CoAP over reliable transports.

That RFC specifies exact behaviors that are applicable here, in a number 
of situations that is not immediate to consider (e.g., the use of a 
cross-proxy, or a block-wise transfer that starts over multicast and 
then switches to reliable unicast).

Instead of being an appendix, we think that this Section 3.9.4 still 
fits nicely in the document body under the parent Section 3.9 “Transport 
Protocols”.


> # Other Transports > > I’m not sure whether all will be applicable. Better to declare 
those > out of scope.
That was already the intention. Section 1.1 “Scope” says:

     Other transport protocols (which may include broadcast, non-IP 
multicast, geocast, etc.) are not described in detail and are not 
considered.

The whole text in the quoted Section 3.9.5 is:

     CoAP group communication may be used over transports other than 
UDP/IP multicast. For example broadcast, non-UDP multicast, geocast, 
serial unicast, etc. In such cases the particular considerations for 
UDP/IP multicast in this document may need to be applied to that 
particular transport.

We have added the following sentence at the end of that paragraph:

     Further details about such alternative transports and their use for 
CoAP group communication are out of scope for this document.



> # No NoSec again > > CURRENT: Indications that endpoints can use the NoSec mode MUST 
NOT > rely on setting up and advertising a pseudo security group with 
name > "NoSec" or any of its lowercase/uppercase combinations. > > This 
reco is already stated in 2.2.1.3
Right. That statement fits in both sections, but we think it is ok to 
have it only in Section 2.2.1.3 where it appears for the first time. 
Later on, that section can be just referred to.

So in Section 4, we have made the following rephrasing:

OLD

     The NoSec mode does not require and does not make use of a security 
group. Indications that endpoints can use the NoSec mode MUST NOT rely 
on setting up and advertising a pseudo security group with name “NoSec” 
or any of its lowercase/uppercase combinations.

NEW

     The NoSec mode does not require and does not make use of a security 
group (see Section 2.2.1.3).


> > Cheers, Med >

-- 
*IoTconsultancy.nl* | Email/Teams: esko.dijk@iotconsultancy.nl | +31 6 
2385 8339