Re: [core] WGA of draft-dijk-core-groupcomm-bis-03

Hello Achim,

Thanks for your email and raising this point. The groupcomm-bis-03 draft now defines more explicitly the concepts of CoAP group, application group and security group.
If the CoAP group cannot be determined by the server, that should not be a problem when considering these 3 group concepts. By the fact that the message is received, the server knows that the message is targeting at least one CoAP group that it has joined.

How the server handles the request is not determined by the CoAP group but normally by the URI path (indicating the resource) and the URI query options (if any).
In groupcomm-bis we indicate that the application group may be optionally encoded in the URI path (e.g. /lights/g4/brightness to control brightness of all application-group g4 lights within a single luminaire device) or in the URI query (e.g. /lights/brightness?grp=g4) .

In addition, also security group needs to be considered. The server will need to check that the right security group is present in the request before processing the request for a specific resource or resource-plus-application-group indicator.
(For example, only an authenticated client that is member of group 'g4' can make a request to the /lights/g4/...  set of resources. CoAP group is then not so relevant anymore.)

You mention the "Uri-Host" option used to select a destination group, that is certainly possible - it influences the choice of application group according to the definitions in groupcomm-bis. (Maybe we should explain this in the draft also. Thomas had also a Uri-Host comment!)
So by looking at the value of "Uri-Host", a server can decide on different processing of the request. (For example, a request to resource /lights/brightness could operate differently depending on the contents of Uri-Host e.g. "g4" and also have different security requirements depending on that value. So each virtual server in the same endpoint serves resources for a different application group.).
The reason that "Uri-Host" does not impact selection of CoAP group is because CoAP group is defined at endpoint level only; and multiple virtual servers are within the same endpoint.

All in all, the server's processing of the request depends on URI path / URI query in a particular security context - and the CoAP group should not play a role in that anymore as this is more about getting the message to the right set of nodes.  If it does play a role then what you are really selecting is different application groups (that might be named after CoAP groups - but still they are application groups) and for that we have various tools at the moment: URI path, URI query and URI host option. Adding another tool to this like a "group selection option" would be possible though I feel URI path is the most logical place to encode application group!

Best regards
Esko

-----Original Message-----
From: core <core-bounces@ietf.org> On Behalf Of Achim Kraus
Sent: Friday, March 20, 2020 09:37
To: core@ietf.org
Subject: Re: [core] WGA of draft-dijk-core-groupcomm-bis-03

Hello list,

the draft "draft-dijk-core-groupcomm-bis-03" mention in
2.1 Group Definition

"An endpoint may be a member of multiple CoAP groups by subscribing to
multiple IP multicast groups."

At least for java, we (Eclipse Californium) didn't find a way for the
server-side, to determine, for which multicast group the message was
received. We even didn't find a way to distinguish on the server-side,
if the message was received through a multicast group or uni-cast
address. An approach, which uses "many ports", and so different
endpoints, has it's downsides (the document mentions them).
To overcome that for a "private deployment", I started to use the
"Uri-Host" option to send he destination "multicast group" as convention.

Maybe, if group communication gets more elaborated, the core wg consider
to spend a specific (new) option "multicast-group" in order to make it
easier/possible, to implement a proper server-side.

best regards
Achim Kraus

_______________________________________________
core mailing list
core@ietf.org
https://www.ietf.org/mailman/listinfo/core