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.

Please find some comments (ordered following the spec flow), fwiw. Feel free to grab whatever useful.

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

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

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

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

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

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

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

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

# Figure 1

From a deployment perspective, which entity has to maintain this 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? 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

# Other Transports

I’m not sure whether all will be applicable. Better to declare those out of scope.

# 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

Cheers,
Med