Draft: draft-ietf-core-groupcomm-bis

Commentary: Review suggestion was that we could use also Uri - Host for naming of application groups . But : RFC 7252 defines an endpoint ( in 4.1 ) for CoAP - NoSec mode solely by IP address and UDP port number . And since we define CoAP group as a set of endpoints , changing the Uri - Host Option to something else will not change the CoAP group if the CoAP request is still delivered to the same IP address and port . In other words , the use of Uri - Host Option influences the ' common set of resources ' that can be reached by a request and hence it has direct impact on the ( selection of ) application group . Use of Uri - Host can be tricky : if it is encoded in the CoAP group URI , then the information typically gets removed in the actual CoAP request sent over the wire . So that means the receiving server can not use can be to an outgoing CoAP request ( for which the group URI was already resolved to IP address ) . In that case it influences the choice of application group , because each virtual server will have a different set of resources hosted . 
 Current draft has this text : To consider if this should say " Response Code class " instead of " Response Code " . The No - Response Option for example works on class level . As an example , then consistency means if 4.04 is suppressed by default then also 4.05 is suppressed by default . 
 To clarify RFC 7252 endpoint concept and messaging model that , in case of multicast , the server may respond from a different UDP port ( endpoint ) than the UDP port used in the request . See email thread :
Mailing list commentary: Thanks Klaus & Jim , it is clear to me now how you view the endpoint concept for multicast messages . Because ( to me ) this is not fully compatible with the definitions of " endpoint " and messaging model in RFC 7252 that I quoted , it would be good to clarify this aspect more in draft - ietf - core - groupcomm - bis i.e. refine the RFC 7252 endpoint definitions for the multicast case and clarify the multicast messaging model . I guess the rationale for the " mailing list " type behavior is that the receiving node anyhow changes the endpoint ( by changing multicast IP address to a unicast IP address ) so it could change the port number as well , the responding endpoint will anyhow be different . ( To me that was unexpected and feels not entirely right - port number should not need to change , but I can live with it . ) I ' m assuming by now there are no different opinions from the list on this question anymore , so I 'll proceed with some text for draft - ietf - core - groupcomm - bis . Maybe a " SHOULD " level requirement on keeping the UDP port number the same ? And indicate if there are any good reasons to change port number the server can do just that .
Paragraph (version A):
All guidelines in RFC7390 are updated by this document, which
replaces and obsoletes RFC7390.  Furthermore, this document updates
RFC7252, by adding security for CoAP group communication and updates
RFC7641, by adding the multicast usage of CoAP Observe.
Paragraph (version B):
All guidelines in RFC7390 are updated by this document, which
replaces and obsoletes RFC7390.  Furthermore, this document updates
RFC7252, by specifying a group request/response model and by adding
security for CoAP group communication.  Finally, this document also
updates RFC7641, by adding the multicast usage of CoAP Observe for
both the GET and FETCH methods.
Paragraph (version A):
Furthermore, "Security material" refers to any security keys,
counters or parameters required to participate in secure group
communication with other devices that share the same security
material.
Paragraph (version A):
The general operation of group communication, applicable for both
unsecured and secured operation, is specified in this section by
going through the stack from top to bottom.  First, different group
types are defined in sec-groupdef.  Group configuration (e.g. group
creation and maintenance which are usually done by an application,
user or commissioning entity) is considered next in sec-groupconf.
Then the use of CoAP for group communication including support for
protocol extensions (block-wise transfer, Observe) follows in sec-
coap-usage.  How CoAP group messages are carried over various
transport layers is the subject of sec-transport.  Finally, sec-
other-protocols covers the interworking of CoAP group communication
with other protocols that may operate in the same network.
Paragraph (version A):
A CoAP group is defined as a set of CoAP endpoints, where each
endpoint is configured to receive CoAP multicast messages that are
sent to the group's associated IP multicast address and UDP port.  An
endpoint may be a member of multiple CoAP groups by subscribing to
multiple IP multicast groups.  Group membership(s) of an endpoint may
dynamically change over time.  A device sending a CoAP multicast
message to a group is not necessarily itself a member of this group:
it is a member only if it also has a CoAP endpoint listening to the
group's associated IP multicast address and UDP port.  A CoAP group
can be encoded within a Group URI, i.e. a CoAP URI that has the
"coap" scheme and includes in the authority part either an IP
multicast address or a group hostname (e.g., a Group Fully Qualified
Domain Name (FQDN)) that can be resolved to an IP multicast address.
A Group URI also contains an optional UDP port number in the
authority part.  Group URIs follow the regular CoAP URI syntax (see
Section 6 of RFC7252).
Paragraph (version B):
Furthermore, "Security material" refers to any security keys,
counters or parameters stored in a device that are required to
participate in secure group communication with other devices.
Paragraph (version B):
The general operation of group communication, both unsecured and
secured, is specified in this section.  First, different group types
are defined in sec-groupdef.  Group configuration, including group
creation and maintenance by an application, user or commissioning
entity is considered next in sec-groupconf.  Then the use of CoAP for
group communication including support for protocol extensions (block-
wise transfer, Observe) follows in sec-coap-usage.  How CoAP group
messages are carried over various transport layers is the subject of
sec-transport.  Finally, sec-other-protocols covers the interworking
of CoAP group communication with other protocols that may operate in
the same network.
Paragraph (version B):
A CoAP group is defined as a set of CoAP endpoints, where each
endpoint is configured to receive CoAP multicast messages that are
sent to the group's associated IP multicast address and UDP port.  An
endpoint may be a member of multiple CoAP groups by subscribing to
multiple IP multicast groups and/or listening on multiple UDP ports.
Group membership(s) of an endpoint may dynamically change over time.
A device sending a CoAP multicast message to a CoAP group is not
necessarily itself a member of this CoAP group: it is a member only
if it also has a CoAP endpoint listening on the group's associated IP
multicast address and UDP port.  A CoAP group can be encoded within a
Group URI.  This is defined as a CoAP URI that has the "coap" scheme
and includes in the authority part either an IP multicast address or
a group hostname (e.g., a Group Fully Qualified Domain Name (FQDN))
that can be resolved to an IP multicast address.  A Group URI also
contains an optional UDP port number in the authority part.  Group
URIs follow the regular CoAP URI syntax (see Section 6 of RFC7252).
Paragraph (version A):
application group is optionally identified explicitly in the path
component or query component of a Group URI.  If not explicitly
identified, the application group is specified implicitly in a Group
URI by choice of CoAP group and resource path.
Paragraph (version B):
application group identifier is optionally encoded explicitly in the
CoAP request.  If not explicitly encoded, the application group is
implicitly derived by the receiver, based on information in the CoAP
request.  See sec-groupnaming for more details on identifying the
application group.
Paragraph (version B):
A special note is appropriate about the possible relation between
security groups and application groups.
Paragraph (version B):
On one hand, multiple application groups may use the same security
group.  Thus, the same group security material is used to protect the
messages targeting any of those application groups.  In this case, a
CoAP endpoint is supposed to know the exact application group to
refer to for each message, based on, e.g., the used server port
number, the targeted resource, or the content and structure of the
message payload.
Paragraph (version B):
On the other hand, a single application group may use multiple
security groups.  Thus, different messages targeting the resources of
the application group can be protected with different security
material.  This can be convenient, for example, if the security
groups differ with respect to the crytpographic algorithms and
related parameters they use.  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.
Paragraph (version B):
Beyond this particular case, applications should be greatly careful
in associating a same application group to multiple security groups.
In particular, it is NOT RECOMMENDED using different security groups
to reflect different access policies for resources in a same
application group.  That is, being a member of a security group
actually grants access only to exchanged secure messages, while
access to resources in the application group belongs to a separate
security domain, and has to be separately enforced by leveraging the
resource properties or through dedicated access control credentials
assessed by separate means.
Paragraph (version A):
A CoAP group is identified and named by the authority component in
the Group URI, which includes host and optional port number.  It is
recommended to configure an endpoint by default with an IP multicast
address literal, instead of a hostname.  This is because DNS
infrastructure may not be deployed in many constrained networks.  In
case a group hostname is configured, it can be uniquely mapped to an
IP multicast address via DNS resolution - if DNS client functionality
is available in the clients and the DNS service is supported in the
network.  Some examples of hierarchical CoAP group FQDN naming (and
scoping) for a building control application are shown in Section 2.2
of RFC7390.
Paragraph (version A):
An application group can be named in many ways through different
types of identifiers, such as numbers, URIs or other strings.  An
application group name or identifier, if explicitly encoded, is
typically included in the path component or query component of a
Group URI.  Appendix A of I-D.ietf-core-resource-directory shows
registration of application groups into a Resource Directory, along
with the CoAP group it maps to.
Paragraph (version A):
A security group is identified by a stable and invariant string used
as group name, which is generally not related with other kind of
group identifiers, specific to the chosen security solution.  The
"NoSec" security group is typically identified by the absence of any
name or identifier, and of any security-related data structures in
the CoAP message.
Paragraph (version B):
A CoAP group is identified and named by the authority component in
the Group URI, which includes host (possibly an IP multicast address
literal) and an optional UDP port number.  It is recommended to
configure an endpoint with an IP multicast address literal, instead
of a hostname, when configuring a CoAP group membership.  This is
because DNS infrastructure may not be deployed in many constrained
networks.  In case a group hostname is configured, it can be uniquely
mapped to an IP multicast address via DNS resolution - if DNS client
functionality is available in the endpoint being configured and the
DNS service is supported in the network.  Some examples of
hierarchical CoAP group FQDN naming (and scoping) for a building
control application are shown in Section 2.2 of RFC7390.
Paragraph (version B):
An application group can be named in many ways through different
types of identifiers, such as numbers, URIs or other strings.  An
application group name or identifier, if explicitly encoded in a CoAP
request, is typically included in the path component or in the query
component of a Group URI.  It may also be encoded using the Uri-Host
Option RFC7252 in case application group members implement a virtual
CoAP server specific to that application group.  The application
group can then be identified by the value of the Uri-Host Option and
each virtual server serves one specific application group.  However,
encoding the application group in the Uri-Host Option is not the
preferred method because in this case the application group cannot be
encoded in a Group URI, and also the Uri-Host Option is being used
for another purpose than encoding the host part of a URI as intended
by RFC7252 -- which is potentially confusing.  Appendix A of I-
D.ietf-core-resource-directory shows an example registration of an
application group into a Resource Directory, along with the CoAP
group it uses and the resources supported by the application group.
In this example an application group identifier is not explicitly
encoded in the RD nor in CoAP requests made to the group, but it
implicitly follows from the CoAP group used for the request.  So
there is a one-to-one binding between the CoAP group and the
application group.  The "NoSec" security group is used.
Paragraph (version B):
A best practice for encoding application group into a Group URI is to
use one URI path component to identify the application group and use
the following URI paths component(s) to identify the resource within
this application group.  For example, /<groupname>/res1 or
/base/<groupname>/res1/res2 conform to this practice.  An application
group identifier (like <groupname>) should be as short as possible
when used in constrained networks.
Paragraph (version B):
A security group is identified by a stable and invariant string used
as group name, which is generally not related with other kinds of
group identifiers, specific to the chosen security solution.  The
"NoSec" security group name MUST be only used to represent the case
of group communication without any security.  It is typically
characterized by the absence of any security group name, identifier,
or security-related data structures in the CoAP message.
Paragraph (version A):
communication, based on JSON-formatted configuration resources.
Paragraph (version A):
To create an application group, a configuring entity may configure a
resource (name) or set of resources on a CoAP endpoint, such that a
request sent by a configured CoAP client with a configured URI path
will be processed by one or more CoAP servers that have the same URI
path configured - i.e. the application group members.
Paragraph (version A):
To create a security group, a configuring entity defines a set of
group properties including the crytpographic algorithms and
parameters used in the group, as well as additional information
relevant throughout the group life-cycle, including the group name
and description.  This task MAY be entrusted to a dedicated
administrator, that interacts with a Group Manager as defined in
chap-oscore.  After that, security material to protect group
communications has to be generated, as compatible with the specified
group configuration.
Paragraph (version B):
communication, based on JSON-formatted configuration resources.  For
IPv6 CoAP groups, common multicast address ranges that are used to
configure group addresses from are ff1x::/16 and ff3x::/16.
Paragraph (version B):
To create an application group, a configuring entity may configure a
resource (name) or set of resources on CoAP endpoints, such that a
CoAP request with Group URI sent by a configured CoAP client will be
processed by one or more CoAP servers that have the matching URI path
configured.  These servers are the application group members.
Paragraph (version B):
To create a security group, a configuring entity defines an initial
subset of the related security material.  This comprises a set of
group properties including the crytpographic algorithms and
parameters used in the group, as well as additional information
relevant throughout the group life-cycle, such as the security group
name and description.  This task MAY be entrusted to a dedicated
administrator, that interacts with a Group Manager as defined in
chap-oscore.  After that, further security material to protect group
communications have to be generated, as compatible with the specified
group configuration.
Paragraph (version A):
A server sends back a unicast response to the CoAP group request -
but the server MAY suppress the response for various reasons
(Section 8.2 of RFC7252).  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 requires such a
response to be made.  The unicast responses received by the CoAP
client may be a mixture of success (e.g., 2.05 Content) and failure
(e.g., 4.04 Not Found) codes, depending on the individual server
processing results.
Paragraph (version A):
The CoAP No-Response Option RFC7967 can be used by a client to
influence the default response suppression on the server side.  It is
RECOMMENDED for a server to implement this option only on selected
resources where it is useful in the application context.  If the
Option is supported on a resource, it MUST override the default
response suppression of that resource.
Paragraph (version A):
Any default response suppression by a server SHOULD be performed in a
consistent way, such that if a request on a resource produces a
Response Code and this response is not suppressed, then a later
request on the same resource that produces a response with the same
Response Code is also not suppressed.
Paragraph (version B):
A server sends back a unicast response to the CoAP group request -
but the server MAY suppress the response for various reasons
(Section 8.2 of RFC7252).  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.  The unicast responses received by the CoAP client may be a
mixture of success (e.g., 2.05 Content) and failure (e.g., 4.04 Not
Found) codes, depending on the individual server processing results.
Paragraph (version B):
The CoAP No-Response Option RFC7967 can be used by a client to
influence the default response suppression on the server side.  It is
RECOMMENDED for a server to support this option only on selected
resources where it is useful in the application context.  If the
Option is supported on a resource, it MUST override the default
response suppression of that resource.
Paragraph (version B):
Any default response suppression by a server SHOULD be performed
consistently, as follows: if a request on a resource produces a
particular Response Code and this response is not suppressed, then
another request on the same resource that produces a response of the
same Response Code class is also not suppressed.  For example, if a
on a resource, then a 4.15 Unsupported Content-Format error response
code is also suppressed by default for that resource.
Paragraph (version A):
While processing a response, the source endpoint of the response is
not exactly matched to the destination endpoint of the request, since
for a multicast request these will never match.  This is specified in
Section 8.2 of RFC7252.  In case a single client has sent multiple
group requests and concurrent CoAP transactions are ongoing, the
responses received by that client are matched to a request using the
Token value.  Due to UDP level multiplexing, the UDP destination port
of the response MUST match to the client endpoint's UDP port value,
i.e. to the UDP source port of the client's request.
Paragraph (version B):
While processing a response, the source endpoint of the response is
not matched to the destination endpoint of the request, since for a
multicast request these will never match.  This is specified in
Section 8.2 of RFC7252.  It implies also that a server MAY respond
from a UDP port number that differs from the destination UDP port
number of the request, yet a CoAP server normally SHOULD respond from
the UDP port number that equals the destination port of the request
-- following the convention for UDP-based protocols.  In case a
single client has sent multiple group requests and concurrent CoAP
transactions are ongoing, the responses received by that client are
matched to an active request using only the Token value.  Due to UDP
level multiplexing, the UDP destination port of the response MUST
match to the client endpoint's UDP port value, i.e. to the UDP source
port of the client's request.
Paragraph (version A):
One way to create multiple CoAP groups is using different UDP ports
with the same IP multicast address, in case the devices' network
stack only supports a limited number of CoAP group memberships.
However, it must be taken into account that this incurs additional
processing overhead on each CoAP server participating in at least one
of these groups: messages to groups that are not of interest to the
node are only discarded at the higher transport (UDP) layer instead
of directly at the network (IP) layer.
Paragraph (version B):
One way to create multiple CoAP groups is using different UDP ports
with the same IP multicast address, in case the devices' network
stack only supports a limited number of multicast address
subscriptions.  However, it must be taken into account that this
incurs additional processing overhead on each CoAP server
participating in at least one of these groups: messages to groups
that are not of interest to the node are only discarded at the higher
transport (UDP) layer instead of directly at the network (IP) layer.
Paragraph (version A):
The operation of HTTP-to-CoAP proxies for multicast CoAP requests is
specified in Section 8.4 and 10.1 of RFC8075.  In this case, the
"application/http" media type is used to let the proxy return
multiple CoAP responses -- each translated to a HTTP response -- back
to the HTTP client.  Of course, in this case the HTTP client sending
a group URI to the proxy needs to be aware that it is going to
receive this format, and needs to be able to decode it into the
responses of multiple CoAP servers.  Also, the IP source address of
each CoAP response cannot be determined anymore from the application/
http response.
Paragraph (version B):
The operation of HTTP-to-CoAP proxies for multicast CoAP requests is
specified in Section 8.4 and 10.1 of RFC8075.  In this case, the
"application/http" media type is used to let the proxy return
multiple CoAP responses -- each translated to a HTTP response -- back
to the HTTP client.  Of course, in this case the HTTP client sending
a group URI to the proxy needs to be aware that it is going to
receive this format, and needs to be able to decode it into the
responses of multiple CoAP servers.  Also, the IP source address of
each CoAP response cannot be determined anymore from the
"application/http" response.  The HTTP client still identify the CoAP
servers by other means such as application-specific information in
the response payload.
Paragraph (version A):
A server in a constrained network should only support group
communication GET for resources that are small.  This can consist,
for example, in having the payload of the response as limited to
approximately 5% of the IP Maximum Transmit Unit (MTU) size, so
that it fits into a single link-layer frame in case IPv6 over Low-
Power Wireless Personal Area Networks (6LoWPAN) (see Section 4 of
RFC4944) is used.
Paragraph (version A):
A server SHOULD minimize the payload size of a response to a
multicast GET on "/.well-known/core" by using hierarchy in
arranging link descriptions for the response.  An example of this
is given in Section 5 of RFC6690.
Paragraph (version A):
A server MAY minimize the payload size of a response to a
multicast GET (e.g., on "/.well-known/core") by using CoAP block-
wise transfers RFC7959 in case the payload is long, returning only
a first block of the CoRE Link Format description.  For this
reason, a CoAP client sending an IP multicast CoAP request to
"/.well-known/core" SHOULD support block-wise transfers.  See also
sec-block-wise.
Paragraph (version B):
A server in a constrained network should only support group
communication with GET and FETCH for resources that are small.
This can consist, for example, in having the payload of the
response as limited to approximately 5% of the IP Maximum Transmit
Unit (MTU) size, so that it fits into a single link-layer frame in
case IPv6 over Low-Power Wireless Personal Area Networks (6LoWPAN)
(see Section 4 of RFC4944) is used.
Paragraph (version B):
A server SHOULD minimize the payload size of a response to a
multicast GET or FETCH on "/.well-known/core" by using hierarchy
in arranging link descriptions for the response.  An example of
this is given in Section 5 of RFC6690.
Paragraph (version B):
A server MAY minimize the payload size of a response to a
multicast GET or FETCH (e.g., on "/.well-known/core") by using
CoAP block-wise transfers RFC7959 in case the payload is long,
returning only a first block of the CoRE Link Format description.
For this reason, a CoAP client sending an IP multicast CoAP
request to "/.well-known/core" SHOULD support block-wise
transfers.  See also sec-block-wise.
Paragraph (version A):
The CoAP Observe Option RFC7641 is a protocol extension of CoAP, that
allows a CoAP client to retrieve a representation of a resource and
automatically keep this representation up-to-date over a longer
period of time.  The client gets notified when the representation has
changed.  RFC7641 does not mention whether the Observe Option can be
combined with CoAP multicast.  This section updates RFC7641 with the
use of the Observe Option in a CoAP multicast GET request and defines
normative behavior for both client and server.
Paragraph (version A):
Multicast Observe is a useful way to start observing a particular
resource on all members of a CoAP group at the same time.  Group
members that do not have this particular resource or do not allow the
GET method on it will either respond with an error status -- 4.04 Not
Found or 4.05 Method Not Allowed, respectively -- or will silently
suppress the response following the rules of sec-request-response,
depending on server-specific configuration.
Paragraph (version A):
A client that sends a multicast GET request with the Observe Option
MAY repeat this request using the same Token value and the same
Observe Option value, in order to ensure that enough (or all) members
of the CoAP group have been reached with the request.  This is useful
in case a number of group members did not respond to the initial
request.  The client MAY additionally use the same Message ID in the
repeated request to avoid that group members that had already
received the initial request would respond again.  Note that using
the same Message ID in a repeated request will not be helpful in case
of loss of a response message, since the server that responded
already will consider the repeated request as a duplicate message.
On the other hand, if the client uses a different, fresh Message ID
in the repeated request, then all the group members that receive this
new message will typically respond again, which increases the network
load.
Paragraph (version B):
The CoAP Observe Option RFC7641 is a protocol extension of CoAP, that
allows a CoAP client to retrieve a representation of a resource and
automatically keep this representation up-to-date over a longer
period of time.  The client gets notified when the representation has
changed.  RFC7641 does not mention whether the Observe Option can be
combined with CoAP multicast.
Paragraph (version B):
This section updates RFC7641 with the use of the Observe Option in a
CoAP multicast GET request, and defines normative behavior for both
client and server.  Consistently with Section 2.4 of RFC8132, it is
also possible to use the Observe Option in a CoAP multicast FETCH
request.
Paragraph (version B):
Multicast Observe is a useful way to start observing a particular
resource on all members of a CoAP group at the same time.  Group
members that do not have this particular resource or do not allow the
GET or FETCH method on it will either respond with an error status --
silently suppress the response following the rules of sec-request-
response, depending on server-specific configuration.
Paragraph (version B):
A client that sends a multicast GET or FETCH request with the Observe
Option MAY repeat this request using the same Token value and the
same Observe Option value, in order to ensure that enough (or all)
members of the CoAP group have been reached with the request.  This
is useful in case a number of group members did not respond to the
initial request.  The client MAY additionally use the same Message ID
in the repeated request to avoid that group members that had already
received the initial request would respond again.  Note that using
the same Message ID in a repeated request will not be helpful in case
of loss of a response message, since the server that responded
already will consider the repeated request as a duplicate message.
On the other hand, if the client uses a different, fresh Message ID
in the repeated request, then all the group members that receive this
new message will typically respond again, which increases the network
load.
Paragraph (version A):
A client that sent a multicast GET request with the Observe Option
MAY follow up by sending a new unicast CON request with the same
Token value and same Observe Option value to a particular server, in
order to ensure that the particular server receives the request.
This is useful in case a specific group member, that was expected to
respond to the initial group request, did not respond to the initial
request.  The client in this case always uses a Message ID that
differs from the initial multicast message.
Paragraph (version B):
A client that has sent a multicast GET or FETCH request with the
Observe Option MAY follow up by sending a new unicast CON request
with the same Token value and same Observe Option value to a
particular server, in order to ensure that the particular server
receives the request.  This is useful in case a specific group
member, that was expected to respond to the initial group request,
did not respond to the initial request.  In this case, the client
always uses a Message ID that differs from the initial multicast
message.
Paragraph (version B):
Furthermore, consistently with Section 3.3.1 of RFC7641 and following
its guidelines, a client MAY at any time send a new multicast GET or
FETCH request with the same Token value and same Observe Option value
as the original request.  This allows the client to verify that it
has an up-to-date representation of an observed resource and/or to
re-register its interest to observe a resource.
Paragraph (version A):
A server that receives a GET request with the Observe Option, for
which request processing is successful, SHOULD respond to this
request and not suppress the response.  A server that adds a client
to the list of observers for a resource due to an Observe request
MUST respond to this request and not suppress it.
Paragraph (version B):
A server that receives a GET or FETCH request with the Observe
Option, for which request processing is successful, SHOULD respond to
this request and not suppress the response.  A server that adds a
client to the list of observers for a resource due to an Observe
request MUST respond to this request and not suppress it.
Paragraph (version A):
A client can use the unicast cancellation methods of Section 3.6 of
RFC7641 and stop the ongoing observation of a particular resource on
members of a CoAP group.  This can be used to remove specific
observed servers, or even all servers in the group.  In addition, a
client MAY explicitly deregister from all those servers at once, by
sending a multicast GET request that includes the Token value of the
observation to be cancelled and includes an Observe Option with the
value set to 1 (deregister).  In case not all the servers in the CoAP
group received this deregistration request, either the unicast
cancellation methods can be used or the multicast deregistration
request MAY be repeated upon receiving another observe response from
a server.
Paragraph (version A):
For observing a group of servers through a CoAP-to-CoAP proxy or
HTTP-CoAP proxy, the limitations stated in sec-proxy apply.
Paragraph (version A):
Section 2.8 of RFC7959 specifies how a client can use block-wise
transfer (Block2 Option) in a multicast GET request to limit the size
of the initial response of each server.  The client has to use
unicast for any further requests, separately addressing each
different server, in order to retrieve more blocks of the resource
from that server, if any.  Also, a server (member of a targeted CoAP
group) that needs to respond to a multicast request with a
particularly large resource can use block-wise transfer (Block2
Option) at its own initiative, to limit the size of the initial
response.  Again, a client would have to use unicast for any further
requests to retrieve more blocks of the resource.
Paragraph (version A):
A solution for multicast block-wise transfer using the Block1 Option
is not specified in RFC7959 nor in the present document.  Such a
solution would be useful for multicast PUT/POST/PATCH/iPATCH
requests, to efficiently distribute a large request payload as
multiple blocks to all members of a CoAP group.  Multicast usage of
Block1 is non-trivial due to potential message loss (leading to
missing blocks or missing confirmations), and potential diverging
block size preferences of different members of the CoAP group.
Paragraph (version B):
A client can use the unicast cancellation methods of Section 3.6 of
RFC7641 and stop the ongoing observation of a particular resource on
members of a CoAP group.  This can be used to remove specific
observed servers, or even all servers in the group.  In addition, a
client MAY explicitly deregister from all those servers at once, by
sending a multicast GET or FETCH request that includes the Token
value of the observation to be cancelled and includes an Observe
Option with the value set to 1 (deregister).  In case not all the
servers in the CoAP group received this deregistration request,
either the unicast cancellation methods can be used or the multicast
deregistration request MAY be repeated upon receiving another observe
response from a server.
Paragraph (version B):
For observing a group of servers through a CoAP-to-CoAP proxy, the
limitations stated in sec-proxy apply.  The method defined in I-
D.tiloca-core-groupcomm-proxy enables group communication through
proxies and addresses those limitations.
Paragraph (version B):
Section 2.8 of RFC7959 specifies how a client can use block-wise
transfer (Block2 Option) in a multicast GET request to limit the size
of the initial response of each server.  Consistently with
Section 2.5 of RFC8132, the same can be done with a multicast FETCH
request.
Paragraph (version B):
The client has to use unicast for any further request, separately
addressing each different server, in order to retrieve more blocks of
the resource from that server, if any.  Also, a server (member of a
targeted CoAP group) that needs to respond to a multicast request
with a particularly large resource can use block-wise transfer
(Block2 Option) at its own initiative, to limit the size of the
initial response.  Again, a client would have to use unicast for any
further requests to retrieve more blocks of the resource.
Paragraph (version B):
A solution for multicast block-wise transfer using the Block1 Option
is not specified in RFC7959 nor in the present document.  Such a
solution would be useful for multicast FETCH/PUT/POST/PATCH/iPATCH
requests, to efficiently distribute a large request payload as
multiple blocks to all members of a CoAP group.  Multicast usage of
Block1 is non-trivial due to potential message loss (leading to
missing blocks or missing confirmations), and potential diverging
block size preferences of different members of the CoAP group.
Paragraph (version A):
In particular, Group OSCORE protects CoAP requests sent over IP
multicast by a CoAP client, as well as multiple corresponding CoAP
responses sent over IP unicast by different CoAP servers.  However,
the same keying material can also be used to protect CoAP requests
sent over IP unicast to a single CoAP server in the OSCORE group, as
well as the corresponding responses.
Paragraph (version B):
In particular, Group OSCORE protects CoAP requests sent over IP
multicast by a CoAP client, as well as multiple corresponding CoAP
responses sent over IP unicast by different CoAP servers.  However,
the same security material can also be used to protect CoAP requests
sent over IP unicast to a single CoAP server in the OSCORE group, as
well as the corresponding responses.
Paragraph (version A):
A Group Manager is responsible for one or multiple OSCORE groups.  In
particular, the Group Manager acts as repository of public keys of
group members; manages, renews and provides keying material in the
group; and handles the join process of new group members.
Paragraph (version A):
As defined in I-D.tiloca-ace-oscore-gm-admin, an administrator entity
can interact with the Group Manager to create OSCORE groups and
specify their configuration (see sssec-group-creation).  During the
lifetime of the OSCORE group, the administrator can further interact
with the Group Manager, in order to possibly update the group
configuration and eventually delete the group.
Paragraph (version B):
A Group Manager is responsible for one or multiple OSCORE groups.  In
particular, the Group Manager acts as repository of public keys of
group members; manages, renews and provides security material in the
group; and handles the join process of new group members.
Paragraph (version B):
As defined in I-D.ietf-ace-oscore-gm-admin, an administrator entity
can interact with the Group Manager to create OSCORE groups and
specify their configuration (see sssec-group-creation).  During the
lifetime of the OSCORE group, the administrator can further interact
with the Group Manager, in order to possibly update the group
configuration and eventually delete the group.
Paragraph (version A):
A key management scheme for secure revocation and renewal of group
keying material, namely group rekeying, should be adopted in OSCORE
groups.  In particular, the key management scheme should preserve
backward and forward security in the OSCORE group, if the application
requires so (see Section 3.1 of I-D.ietf-core-oscore-groupcomm).
Paragraph (version B):
A key management scheme for secure revocation and renewal of group
security material, namely group rekeying, should be adopted in OSCORE
groups.  In particular, the key management scheme should preserve
backward and forward security in the OSCORE group, if the application
requires so (see Section 3.1 of I-D.ietf-core-oscore-groupcomm).
Paragraph (version A):
This comes at the cost of not continuously preserving backward and
forward security, since group rekeying might not occur upon every
single group membership change.  That is, most recently joined nodes
would have access to the key material used prior to their join, and
thus be able to access past group communications protected with that
key material.  Similarly, until the group is rekeyed, most recently
left nodes would preserve access to group communications protected
with the retained key material.
Paragraph (version B):
This comes at the cost of not continuously preserving backward and
forward security, since group rekeying might not occur upon every
single group membership change.  That is, most recently joined nodes
would have access to the security material used prior to their join,
and thus be able to access past group communications protected with
that security material.  Similarly, until the group is rekeyed, most
recently left nodes would preserve access to group communications
protected with the retained security material.
Paragraph (version A):
Within an OSCORE group, the shared symmetric key material strictly
provides only group-level authentication (see Section 10.1 of I-
D.ietf-core-oscore-groupcomm).  However, source authentication of
messages is also ensured, both in the group mode by means of
countersignatures (see Sections 8.1 and 8.3 of I-D.ietf-core-
oscore-groupcomm), and in the pairwise mode by using additionally
derived pairwise keys (see Sections 9.1 and 9.3 of I-D.ietf-core-
oscore-groupcomm).  Thus, recipient endpoints can verify a message
to be originated by the alleged, identifiable sender in the OSCORE
group.
Paragraph (version B):
Within an OSCORE group, the shared symmetric-key security material
strictly provides only group-level authentication (see
Section 10.1 of I-D.ietf-core-oscore-groupcomm).  However, source
authentication of messages is also ensured, both in the group mode
by means of countersignatures (see Sections 8.1 and 8.3 of I-
D.ietf-core-oscore-groupcomm), and in the pairwise mode by using
additionally derived pairwise keys (see Sections 9.1 and 9.3 of I-
D.ietf-core-oscore-groupcomm).  Thus, recipient endpoints can
verify a message to be originated by the alleged, identifiable
sender in the OSCORE group.
Paragraph (version A):
Group OSCORE does not require group members to be equipped with a
good source of entropy for generating key material (see
Section 11.6 of RFC7252), and thus does not contribute to create
an attack vector against such (constrained) CoAP endpoints.  In
particular, the symmetric keys used for message encryption and
decryption are derived through the same HMAC-based HKDF scheme
used for OSCORE (see Section 3.2 of RFC8613).  Besides, the OSCORE
Master Secret used in such derivation is securely generated by the
Group Manager responsible for the OSCORE group, and securely
provided to the CoAP endpoints when they join the group.
Paragraph (version B):
Group OSCORE does not require group members to be equipped with a
good source of entropy for generating security material (see
Section 11.6 of RFC7252), and thus does not contribute to create
an attack vector against such (constrained) CoAP endpoints.  In
particular, the symmetric keys used for message encryption and
decryption are derived through the same HMAC-based HKDF scheme
used for OSCORE (see Section 3.2 of RFC8613).  Besides, the OSCORE
Master Secret used in such derivation is securely generated by the
Group Manager responsible for the OSCORE group, and securely
provided to the CoAP endpoints when they join the group.
Paragraph (version A):
Group OSCORE prevents to make any single group member a target for
subverting security in the whole OSCORE group (see Section 11.6 of
RFC7252), even though all group members share (and can derive) the
same symmetric key material used in the OSCORE group (see
Section 10.1 of I-D.ietf-core-oscore-groupcomm).  In fact, source
authentication is always ensured for exchanged CoAP messages, as
verifiable to be originated by the alleged, identifiable sender in
the OSCORE group.  This relies on including a countersignature
computed with a node's individual private key (in the group mode),
or on protecting messages with a pairwise symmetric key, which is
in turn derived from the asymmetric keys of the sender and
recipient CoAP endpoints (in the pairwise mode).
Paragraph (version B):
Group OSCORE prevents to make any single group member a target for
subverting security in the whole OSCORE group (see Section 11.6 of
RFC7252), even though all group members share (and can derive) the
same symmetric-key security material used in the OSCORE group (see
Section 10.1 of I-D.ietf-core-oscore-groupcomm).  In fact, source
authentication is always ensured for exchanged CoAP messages, as
verifiable to be originated by the alleged, identifiable sender in
the OSCORE group.  This relies on including a countersignature
computed with a node's individual private key (in the group mode),
or on protecting messages with a pairwise symmetric key, which is
in turn derived from the asymmetric keys of the sender and
recipient CoAP endpoints (in the pairwise mode).