draft-tiloca-core-oscore-discovery-07.txt		draft-tiloca-core-oscore-discovery-08.txt
	CoRE Working Group M. Tiloca		CoRE Working Group M. Tiloca
	Internet-Draft RISE AB		Internet-Draft RISE AB
	Intended status: Standards Track C. Amsuess		Intended status: Standards Track C. Amsuess
	Expires: May 6, 2021		Expires: August 26, 2021
	P. van der Stok		P. van der Stok
	Consultant		Consultant
	November 02, 2020		February 22, 2021
	Discovery of OSCORE Groups with the CoRE Resource Directory		Discovery of OSCORE Groups with the CoRE Resource Directory
	draft-tiloca-core-oscore-discovery-07		draft-tiloca-core-oscore-discovery-08
	Abstract		Abstract
	Group communication over the Constrained Application Protocol (CoAP)		Group communication over the Constrained Application Protocol (CoAP)
	can be secured by means of Group Object Security for Constrained		can be secured by means of Group Object Security for Constrained
	RESTful Environments (Group OSCORE). At deployment time, devices may		RESTful Environments (Group OSCORE). At deployment time, devices may
	not know the exact security groups to join, the respective Group		not know the exact security groups to join, the respective Group
	Manager, or other information required to perform the joining		Manager, or other information required to perform the joining
	process. This document describes how a CoAP endpoint can use		process. This document describes how a CoAP endpoint can use
	descriptions and links of resources registered at the CoRE Resource		descriptions and links of resources registered at the CoRE Resource
	skipping to change at page 1, line 46 ¶		skipping to change at page 1, line 46 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on May 6, 2021.		This Internet-Draft will expire on August 26, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2021 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5		1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
	2. Registration of Group Manager Endpoints . . . . . . . . . . . 6		2. Registration of Group Manager Endpoints . . . . . . . . . . . 6
	2.1. Parameters . . . . . . . . . . . . . . . . . . . . . . . 6		2.1. Parameters . . . . . . . . . . . . . . . . . . . . . . . 6
	2.2. Relation Link to Authorization Server . . . . . . . . . . 9		2.2. Relation Link to Authorization Server . . . . . . . . . . 9
	2.3. Registration Example . . . . . . . . . . . . . . . . . . 9		2.3. Registration Example . . . . . . . . . . . . . . . . . . 10
	2.3.1. Example in Link Format . . . . . . . . . . . . . . . 10		2.3.1. Example in Link Format . . . . . . . . . . . . . . . 10
	2.3.2. Example in CoRAL . . . . . . . . . . . . . . . . . . 10		2.3.2. Example in CoRAL . . . . . . . . . . . . . . . . . . 11
	3. Addition and Update of Security Groups . . . . . . . . . . . 11		3. Addition and Update of Security Groups . . . . . . . . . . . 11
	3.1. Addition Example . . . . . . . . . . . . . . . . . . . . 11		3.1. Addition Example . . . . . . . . . . . . . . . . . . . . 12
	3.1.1. Example in Link Format . . . . . . . . . . . . . . . 12		3.1.1. Example in Link Format . . . . . . . . . . . . . . . 12
	3.1.2. Example in CoRAL . . . . . . . . . . . . . . . . . . 12		3.1.2. Example in CoRAL . . . . . . . . . . . . . . . . . . 13
	4. Discovery of Security Groups . . . . . . . . . . . . . . . . 14		4. Discovery of Security Groups . . . . . . . . . . . . . . . . 15
	4.1. Discovery Example #1 . . . . . . . . . . . . . . . . . . 15		4.1. Discovery Example #1 . . . . . . . . . . . . . . . . . . 16
	4.1.1. Example in Link Format . . . . . . . . . . . . . . . 15		4.1.1. Example in Link Format . . . . . . . . . . . . . . . 16
	4.1.2. Example in CoRAL . . . . . . . . . . . . . . . . . . 16		4.1.2. Example in CoRAL . . . . . . . . . . . . . . . . . . 18
	4.2. Discovery Example #2 . . . . . . . . . . . . . . . . . . 18		4.2. Discovery Example #2 . . . . . . . . . . . . . . . . . . 19
	4.2.1. Example in Link Format . . . . . . . . . . . . . . . 18		4.2.1. Example in Link Format . . . . . . . . . . . . . . . 19
	4.2.2. Example in CoRAL . . . . . . . . . . . . . . . . . . 19		4.2.2. Example in CoRAL . . . . . . . . . . . . . . . . . . 20
	5. Use Case Example With Full Discovery . . . . . . . . . . . . 20		5. Use Case Example With Full Discovery . . . . . . . . . . . . 21
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 24		6. Security Considerations . . . . . . . . . . . . . . . . . . . 25
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 24		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
	8.1. Normative References . . . . . . . . . . . . . . . . . . 24		8.1. Normative References . . . . . . . . . . . . . . . . . . 25
	8.2. Informative References . . . . . . . . . . . . . . . . . 26		8.2. Informative References . . . . . . . . . . . . . . . . . 27
	Appendix A. Use Case Example With Full Discovery (CoRAL) . . . . 27		Appendix A. Use Case Example With Full Discovery (CoRAL) . . . . 28
	Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 31		Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 33
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
	1. Introduction		1. Introduction
	The Constrained Application Protocol (CoAP) [RFC7252] supports group		The Constrained Application Protocol (CoAP) [RFC7252] supports group
	communication over IP multicast [I-D.ietf-core-groupcomm-bis] to		communication over IP multicast [I-D.ietf-core-groupcomm-bis] to
	improve efficiency and latency of communication and reduce bandwidth		improve efficiency and latency of communication and reduce bandwidth
	requirements. A set of CoAP endpoints constitutes an application		requirements. A set of CoAP endpoints constitutes an application
	group by sharing a common pool of resources, that can be efficiently		group by sharing a common pool of resources, that can be efficiently
	accessed through group communication. The members of an application		accessed through group communication. The members of an application
	group may be members of a security group, thus sharing a common set		group may be members of a security group, thus sharing a common set
	skipping to change at page 4, line 43 ¶		skipping to change at page 4, line 43 ¶
	When querying the RD for security groups, a CoAP endpoint can use		When querying the RD for security groups, a CoAP endpoint can use
	CoAP observation [RFC7641]. This results in automatic notifications		CoAP observation [RFC7641]. This results in automatic notifications
	on the creation of new security groups or the update of existing		on the creation of new security groups or the update of existing
	groups. Thus, it facilitates the early deployment of CoAP endpoints,		groups. Thus, it facilitates the early deployment of CoAP endpoints,
	i.e. even before the GM is deployed and security groups are created.		i.e. even before the GM is deployed and security groups are created.
	Interaction examples are provided in Link Format, as well as in the		Interaction examples are provided in Link Format, as well as in the
	Constrained RESTful Application Language CoRAL [I-D.ietf-core-coral]		Constrained RESTful Application Language CoRAL [I-D.ietf-core-coral]
	with reference to a CoRAL-based RD [I-D.hartke-t2trg-coral-reef].		with reference to a CoRAL-based RD [I-D.hartke-t2trg-coral-reef].
	While all the CoRAL examples use the CoRAL textual serialization		While all the CoRAL examples show the CoRAL textual serialization
	format, the CBOR [I-D.ietf-cbor-7049bis] or JSON [RFC8259] binary		format, its binary serialization format is used on the wire.
	serialization format is used when sending such messages on the wire.
	The approach in this document is consistent with, but not limited to,		The approach in this document is consistent with, but not limited to,
	the joining of security groups defined in		the joining of security groups defined in
	[I-D.ietf-ace-key-groupcomm-oscore].		[I-D.ietf-ace-key-groupcomm-oscore].
	1.1. Terminology		1.1. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	skipping to change at page 6, line 37 ¶		skipping to change at page 6, line 37 ¶
	following parameters are specified together with the link.		following parameters are specified together with the link.
	In the RD defined in [I-D.ietf-core-resource-directory] and based on		In the RD defined in [I-D.ietf-core-resource-directory] and based on
	Link Format, each parameter is specified in a target attribute with		Link Format, each parameter is specified in a target attribute with
	the same name.		the same name.
	In a RD based on CoRAL, such as the one defined in		In a RD based on CoRAL, such as the one defined in
	[I-D.hartke-t2trg-coral-reef], each parameter is specified in a		[I-D.hartke-t2trg-coral-reef], each parameter is specified in a
	nested element with the same name.		nested element with the same name.
			o 'ct', specifying the content format used with the group-membership
			resource at the Group Manager, with value "application/ace-
			groupcomm+cbor" registered in Section 8.2 of
			[I-D.ietf-ace-key-groupcomm].
			Note: The examples in this document use the provisional value
			65000 from the range "Reserved for Experimental Use" of the "CoAP
			Content-Formats" registry, within the "CoRE Parameters" registry.
	o 'rt', specifying the resource type of the group-membership		o 'rt', specifying the resource type of the group-membership
	resource at the Group Manager, with value "core.osc.gm" registered		resource at the Group Manager, with value "core.osc.gm" registered
	in Section 21.11 of [I-D.ietf-ace-key-groupcomm-oscore].		in Section 21.11 of [I-D.ietf-ace-key-groupcomm-oscore].
	o 'if', specifying the interface description for accessing the		o 'if', specifying the interface description for accessing the
	group-membership resource at the Group Manager, with value		group-membership resource at the Group Manager, with value
	"ace.group" registered in Section 8.10 of		"ace.group" registered in Section 8.10 of
	[I-D.ietf-ace-key-groupcomm].		[I-D.ietf-ace-key-groupcomm].
	o 'sec-gp', specifying the name of the security group of interest,		o 'sec-gp', specifying the name of the security group of interest,
	skipping to change at page 7, line 20 ¶		skipping to change at page 7, line 30 ¶
	Thus, when registering the links to its group-membership resource,		Thus, when registering the links to its group-membership resource,
	the GM is aware of the application groups and their names.		the GM is aware of the application groups and their names.
	If a different entity than the GM registers the security groups to		If a different entity than the GM registers the security groups to
	the RD, e.g. a Commissioning Tool, this entity has to also be		the RD, e.g. a Commissioning Tool, this entity has to also be
	aware of the application groups and their names to specify. To		aware of the application groups and their names to specify. To
	this end, it can obtain them from the GM or from the Administator		this end, it can obtain them from the GM or from the Administator
	that created the security groups at the GM (see		that created the security groups at the GM (see
	[I-D.ietf-ace-oscore-gm-admin]).		[I-D.ietf-ace-oscore-gm-admin]).
	Optionally, the following parameters can also be specified.		Optionally, the following parameters can also be specified. If Link
			Format is used, the value of each of these parameters is encoded as a
			text string.
			o 'alg', specifying the AEAD algorithm used in the security group.
			If present, this parameter MUST specify a single value, which is
			taken from the 'Value' column of the "COSE Algorithms" Registry
			[COSE.Algorithms].
			o 'hkdf', specifying the HKDF algorithm used in the security group.
			If present, this parameter MUST specify a single value, which is
			taken from the 'Value' column of the "COSE Algorithms" Registry
			defined in [COSE.Algorithms].
	o 'cs_alg', specifying the algorithm used to countersign messages in		o 'cs_alg', specifying the algorithm used to countersign messages in
	the security group. If present, this parameter MUST specify a		the security group. If present, this parameter MUST specify a
	single value encoded as a text string, which is taken from the		single value, which is taken from the 'Value' column of the "COSE
	'Value' column of the "COSE Algorithms" Registry		Algorithms" Registry [COSE.Algorithms].
	[COSE.Algorithms].
	o 'cs_alg_crv', specifying the elliptic curve (if applicable) for		o 'cs_alg_crv', specifying the elliptic curve (if applicable) for
	the algorithm used to countersign messages in the security group.		the algorithm used to countersign messages in the security group.
	If present, this parameter MUST specify a single value encoded as		If present, this parameter MUST specify a single value, which is
	a text string, which is taken from the 'Value' column of the "COSE		taken from the 'Value' column of the "COSE Elliptic Curves"
	Elliptic Curves" Registry [COSE.Elliptic.Curves].		Registry [COSE.Elliptic.Curves].
	o 'cs_key_kty', specifying the key type of countersignature keys		o 'cs_key_kty', specifying the key type of countersignature keys
	used to countersign messages in the security group. If present,		used to countersign messages in the security group. If present,
	this parameter MUST specify a single value encoded as a text		this parameter MUST specify a single value, which is taken from
	string, which is taken from the 'Value' column of the "COSE Key		the 'Value' column of the "COSE Key Types" Registry
	Types" Registry [COSE.Key.Types].		[COSE.Key.Types].
	o 'cs_key_crv', specifying the elliptic curve (if applicable) of		o 'cs_key_crv', specifying the elliptic curve (if applicable) of
	countersignature keys used to countersign messages in the security		countersignature keys used to countersign messages in the security
	group. If present, this parameter MUST specify a single value		group. If present, this parameter MUST specify a single value,
	encoded as a text string, which is taken from the 'Value' column		which is taken from the 'Value' column of the "COSE Elliptic
	of the "COSE Elliptic Curves" Registry defined in		Curves" Registry defined in [COSE.Elliptic.Curves].
	[COSE.Elliptic.Curves].
	o 'cs_kenc', specifying the encoding of the public keys used in the		o 'cs_kenc', specifying the encoding of the public keys used in the
	security group. If present, this parameter MUST specify a single		security group. If present, this parameter MUST specify a single
	value encoded as a text string. This specification explicitly		value. This specification explicitly admits the signaling of COSE
	admits the signaling of COSE Keys		Keys [I-D.ietf-cose-rfc8152bis-struct] as encoding for public
	[I-D.ietf-cose-rfc8152bis-struct] as encoding for public keys,		keys, which is indicated with "1", as taken from the 'Confirmation
	which is indicated with "1", as taken from the 'Confirmation Key'		Key' column of the "CWT Confirmation Method" Registry defined in
	column of the "CWT Confirmation Method" Registry defined in
	[RFC8747]. Future specifications may define additional values for		[RFC8747]. Future specifications may define additional values for
	this parameter.		this parameter.
	o 'alg', specifying the AEAD algorithm used in the security group.		o 'ecdh_alg', specifying the ECDH algorithm used to derive pairwise
	If present, this parameter MUST specify a single value encoded as		encryption keys in the security group, e.g. as for the pairwise
	a text string, which is taken from the 'Value' column of the "COSE		mode of Group OSCORE (see Section 2.3 of
	Algorithms" Registry [COSE.Algorithms].		[I-D.ietf-core-oscore-groupcomm]). If present, this parameter
			MUST specify a single value, which is taken from the 'Value'
			column of the "COSE Algorithms" Registry [COSE.Algorithms].
	o 'hkdf', specifying the HKDF algorithm used in the security group.		o 'ecdh_alg_crv', specifying the elliptic curve for the ECDH
	If present, this parameter MUST specify a single value encoded as		algorithm used to derive pairwise encryption keys in the security
	a text string, which is taken from the 'Value' column of the "COSE		group. If present, this parameter MUST specify a single value,
	Algorithms" Registry defined in [COSE.Algorithms].		which is taken from the 'Value' column of the "COSE Elliptic
			Curves" Registry [COSE.Elliptic.Curves].
			o 'ecdh_key_kty', specifying the key type of keys used with an ECDH
			algorithm to derive pairwise encryption keys in the security
			group. If present, this parameter MUST specify a single value,
			which is taken from the 'Value' column of the "COSE Key Types"
			Registry [COSE.Key.Types].
			o 'ecdh_key_crv', specifying the elliptic curve of keys used with an
			ECDH algorithm to derive pairwise encryption keys in the security
			group. If present, this parameter MUST specify a single value,
			which is taken from the 'Value' column of the "COSE Elliptic
			Curves" Registry defined in [COSE.Elliptic.Curves].
	Note that the values registered in the COSE Registries		Note that the values registered in the COSE Registries
	[COSE.Algorithms][COSE.Elliptic.Curves][COSE.Key.Types] are strongly		[COSE.Algorithms][COSE.Elliptic.Curves][COSE.Key.Types] are strongly
	typed. On the contrary, Link Format is weakly typed and thus does		typed. On the contrary, Link Format is weakly typed and thus does
	not distinguish between, for instance, the string value "-10" and the		not distinguish between, for instance, the string value "-10" and the
	integer value -10.		integer value -10.
	Thus, in RDs that return responses in Link Format, string values		Thus, in RDs that return responses in Link Format, string values
	which look like an integer are not supported. Therefore, such values		which look like an integer are not supported. Therefore, such values
	MUST NOT be advertised through the corresponding parameters above.		MUST NOT be advertised through the corresponding parameters above.
	A CoAP endpoint that queries the RD to discover security groups and		A CoAP endpoint that queries the RD to discover security groups and
	their group-membership resource to access (see Section 4) would		their group-membership resource to access (see Section 4) would
	benefit from the information above as follows.		benefit from the information above as follows.
	o The values of 'cs_alg', 'cs_alg_crv', 'cs_key_kty', 'cs_key_crv'		o The values of 'cs_alg', 'cs_alg_crv', 'cs_key_kty', 'cs_key_crv',
	and 'cs_kenc' related to a group-membership resource provide an		'cs_kenc', 'ecdh_alg', 'ecdh_alg_crv', 'ecdh_key_kty' and
			'ecdh_key_crv' related to a group-membership resource provide an
	early knowledge of the format and encoding of public keys used in		early knowledge of the format and encoding of public keys used in
	the security group. Thus, the CoAP endpoint does not need to ask		the security group. Thus, the CoAP endpoint does not need to ask
	the GM for this information as a preliminary step before the		the GM for this information as a preliminary step before the
	joining process, or to perform a trial-and-error joining exchange		joining process, or to perform a trial-and-error joining exchange
	with the GM. Hence, the CoAP endpoint is able to provide the GM		with the GM. Hence, the CoAP endpoint is able to provide the GM
	with its own public key in the correct expected format and		with its own public key in the correct expected format and
	encoding at the very first step of the joining process.		encoding at the very first step of the joining process.
	o The values of 'cs_alg', 'alg' and 'hkdf' related to a group-		o The values of 'alg', 'hkdf', 'cs_alg' and 'ecdh_alg' related to a
	membership resource provide an early knowledge of the algorithms		group-membership resource provide an early knowledge of the
	used in the security group. Thus, the CoAP endpoint is able to		algorithms used in the security group. Thus, the CoAP endpoint is
	decide whether to actually proceed with the joining process,		able to decide whether to actually proceed with the joining
	depending on its support for the indicated algorithms.		process, depending on its support for the indicated algorithms.
	2.2. Relation Link to Authorization Server		2.2. Relation Link to Authorization Server
	For each registered link to a group-membership resource, the GM MAY		For each registered link to a group-membership resource, the GM MAY
	additionally specify the link to the ACE Authorization Server (AS)		additionally specify the link to the ACE Authorization Server (AS)
	[I-D.ietf-ace-oauth-authz] associated to the GM, and issuing		[I-D.ietf-ace-oauth-authz] associated to the GM, and issuing
	authorization credentials to join the security group as described in		authorization credentials to join the security group as described in
	[I-D.ietf-ace-key-groupcomm-oscore].		[I-D.ietf-ace-key-groupcomm-oscore].
	The link to the AS has as target the URI of the resource where to		The link to the AS has as target the URI of the resource where to
	skipping to change at page 9, line 39 ¶		skipping to change at page 10, line 22 ¶
	relation type.		relation type.
	2.3. Registration Example		2.3. Registration Example
	The example below shows a GM with endpoint name "gm1" and address		The example below shows a GM with endpoint name "gm1" and address
	2001:db8::ab that registers with the RD.		2001:db8::ab that registers with the RD.
	The GM specifies the value of the 'sec-gp' parameter for accessing		The GM specifies the value of the 'sec-gp' parameter for accessing
	the security group with name "feedca570000", and used by the		the security group with name "feedca570000", and used by the
	application group with name "group1" specified with the value of the		application group with name "group1" specified with the value of the
	'app-gp' parameter. The countersignature algorithm used in the		'app-gp' parameter.
	security group is EdDSA, with elliptic curve Ed25519 and keys of type
	OKP. Public keys used in the security group are encoded as COSE Keys		The countersignature algorithm used in the security group is EdDSA
	[I-D.ietf-cose-rfc8152bis-struct].		(-8), with elliptic curve Ed25519 (6). Public keys used in the
			security group are encoded as COSE Keys (1)
			[I-D.ietf-cose-rfc8152bis-struct]. The ECDH algorithm used in the
			security group is ECDH-SS + HKDF-256 (-27), with elliptic curve
			X25519 (4).
	In addition, the GM specifies the link to the ACE Authorization		In addition, the GM specifies the link to the ACE Authorization
	Server associated to the GM, to which a CoAP endpoint should send an		Server associated to the GM, to which a CoAP endpoint should send an
	Authorization Request for joining the corresponding security group		Authorization Request for joining the corresponding security group
	(see [I-D.ietf-ace-key-groupcomm-oscore]).		(see [I-D.ietf-ace-key-groupcomm-oscore]).
	2.3.1. Example in Link Format		2.3.1. Example in Link Format
	Request: GM -> RD		Request: GM -> RD
	Req: POST coap://rd.example.com/rd?ep=gm1		Req: POST coap://rd.example.com/rd?ep=gm1
	Content-Format: 40		Content-Format: 40
	Payload:		Payload:
	</ace-group/feedca570000>;ct=41;rt="core.osc.gm";if="ace.group";		</ace-group/feedca570000>;ct=65000;rt="core.osc.gm";if="ace.group";
	sec-gp="feedca570000";app-gp="group1";		sec-gp="feedca570000";app-gp="group1";
	cs_alg="-8";cs_alg_crv="6";		cs_alg="-8";cs_alg_crv="6";
	cs_key_kty="1";cs_key_crv=6";		cs_kenc="1";ecdh_alg="-27";
	cs_kenc="1",		ecdh_alg_crv="4",
	<coap://as.example.com/token>;		<coap://as.example.com/token>;
	rel="authorization-server";		rel="authorization-server";
	anchor="coap://[2001:db8::ab]/ace-group/feedca570000"		anchor="coap://[2001:db8::ab]/ace-group/feedca570000"
	Response: RD -> GM		Response: RD -> GM
	Res: 2.01 Created		Res: 2.01 Created
	Location-Path: /rd/4521		Location-Path: /rd/4521
	2.3.2. Example in CoRAL		2.3.2. Example in CoRAL
	Request: GM -> RD		Request: GM -> RD
	Req: POST coap://rd.example.com/rd?ep=gm1		Req: POST coap://rd.example.com/rd?ep=gm1
	Content-Format: TBD123456 (application/coral+cbor)		Content-Format: TBD123456 (application/coral+cbor)
	Payload:		Payload:
	#using <http://coreapps.org/core.oscore-discovery#>		#using <http://coreapps.org/core.oscore-discovery#>
	#using reef = <http://coreapps.org/reef#>		#using reef = <http://coreapps.org/reef#>
	#using iana = <http://www.iana.org/assignments/relation/>		#using iana = <http://www.iana.org/assignments/relation/>
	#base <coap://[2001:db8::ab]/>		#base <coap://[2001:db8::ab]/>
	reef:rd-item </ace-group/feedca570000> {		reef:rd-item </ace-group/feedca570000> {
			reef:ct 65000
	reef:rt "core.osc.gm"		reef:rt "core.osc.gm"
	reef:if "ace.group"		reef:if "ace.group"
	sec-gp "feedca570000"		sec-gp "feedca570000"
	app-gp "group1"		app-gp "group1"
	cs_alg -8		cs_alg -8
	cs_alg_crv 6		cs_alg_crv 6
	cs_key_kty 1
	cs_key_crv 6
	cs_kenc 1		cs_kenc 1
			ecdh_alg -27
			ecdh_alg_crv 4
	iana:authorization-server <coap://as.example.com/token>		iana:authorization-server <coap://as.example.com/token>
	}		}
	Response: RD -> GM		Response: RD -> GM
	Res: 2.01 Created		Res: 2.01 Created
	Location-Path: /rd/4521		Location-Path: /rd/4521
	3. Addition and Update of Security Groups		3. Addition and Update of Security Groups
	The GM is responsible to refresh the registration of all its group-		The GM is responsible to refresh the registration of all its group-
	membership resources in the RD. This means that the GM has to update		membership resources in the RD. This means that the GM has to update
	the registration within its lifetime as per Section 5.3.1 of		the registration within its lifetime as per Section 5.3.1 of
	[I-D.ietf-core-resource-directory], and has to change the content of		[I-D.ietf-core-resource-directory], and has to change the content of
	the registration when a group-membership resource is added/removed,		the registration when a group-membership resource is added/removed,
	skipping to change at page 12, line 11 ¶		skipping to change at page 13, line 4 ¶
	o A third group-membership resource associated with the security		o A third group-membership resource associated with the security
	group with name "abcdef120000" and used by two application groups,		group with name "abcdef120000" and used by two application groups,
	namely "group3" and "group4".		namely "group3" and "group4".
	Furthermore, the GM relates the same Authorization Server also to the		Furthermore, the GM relates the same Authorization Server also to the
	security groups "ech0ech00000" and "abcdef120000".		security groups "ech0ech00000" and "abcdef120000".
	3.1.1. Example in Link Format		3.1.1. Example in Link Format
	Request: GM -> RD		Request: GM -> RD
	Req: POST coap://rd.example.com/rd?ep=gm1		Req: POST coap://rd.example.com/rd?ep=gm1
	Content-Format: 40		Content-Format: 40
	Payload:		Payload:
	</ace-group/feedca570000>;ct=41;rt="core.osc.gm";if="ace.group";		</ace-group/feedca570000>;ct=65000;rt="core.osc.gm";if="ace.group";
	sec-gp="feedca570000";app-gp="group1";		sec-gp="feedca570000";app-gp="group1";
	cs_alg="-8";cs_alg_crv="6";		cs_alg="-8";cs_alg_crv="6";
	cs_key_kty="1";cs_key_crv=6";		cs_kenc="1";ecdh_alg="-27";
	cs_kenc="1",		ecdh_alg_crv="4",
	</ace-group/ech0ech00000>;ct=41;rt="core.osc.gm";if="ace.group";		</ace-group/ech0ech00000>;ct=65000;rt="core.osc.gm";if="ace.group";
	sec-gp="ech0ech00000";app-gp="group2";		sec-gp="ech0ech00000";app-gp="group2";
	cs_alg="-8";cs_alg_crv="6";		cs_alg="-8";cs_alg_crv="6";
	cs_key_kty="1";cs_key_crv=6";		cs_kenc="1";ecdh_alg="-27";
	cs_kenc="1",		ecdh_alg_crv="4",
	</ace-group/abcdef120000>;ct=41;rt="core.osc.gm";if="ace.group";		</ace-group/abcdef120000>;ct=65000;rt="core.osc.gm";if="ace.group";
	sec-gp="abcdef120000";app-gp="group3";		sec-gp="abcdef120000";app-gp="group3";
	app-gp="group4";cs_alg="-8";		app-gp="group4";cs_alg="-8";
	cs_alg_crv="6";cs_key_kty="1";		cs_alg_crv="6";cs_kenc="1";
	cs_key_crv=6";cs_kenc="1",		ecdh_alg="-27";ecdh_alg_crv="4",
	<coap://as.example.com/token>;		<coap://as.example.com/token>;
	rel="authorization-server";		rel="authorization-server";
	anchor="coap://[2001:db8::ab]/ace-group/feedca570000",		anchor="coap://[2001:db8::ab]/ace-group/feedca570000",
	<coap://as.example.com/token>;		<coap://as.example.com/token>;
	rel="authorization-server";		rel="authorization-server";
	anchor="coap://[2001:db8::ab]/ace-group/ech0ech00000",		anchor="coap://[2001:db8::ab]/ace-group/ech0ech00000",
	<coap://as.example.com/token>;		<coap://as.example.com/token>;
	rel="authorization-server";		rel="authorization-server";
	anchor="coap://[2001:db8::ab]/ace-group/abcdef120000"		anchor="coap://[2001:db8::ab]/ace-group/abcdef120000"
	skipping to change at page 13, line 4 ¶		skipping to change at page 13, line 40 ¶
	anchor="coap://[2001:db8::ab]/ace-group/abcdef120000"		anchor="coap://[2001:db8::ab]/ace-group/abcdef120000"
	Response: RD -> GM		Response: RD -> GM
	Res: 2.04 Changed		Res: 2.04 Changed
	Location-Path: /rd/4521		Location-Path: /rd/4521
	3.1.2. Example in CoRAL		3.1.2. Example in CoRAL
	Request: GM -> RD		Request: GM -> RD
	Req: POST coap://rd.example.com/rd?ep=gm1		Req: POST coap://rd.example.com/rd?ep=gm1
	Content-Format: TBD123456 (application/coral+cbor)		Content-Format: TBD123456 (application/coral+cbor)
	Payload:		Payload:
	#using <http://coreapps.org/core.oscore-discovery#>		#using <http://coreapps.org/core.oscore-discovery#>
	#using reef = <http://coreapps.org/reef#>		#using reef = <http://coreapps.org/reef#>
	#using iana = <http://www.iana.org/assignments/relation/>		#using iana = <http://www.iana.org/assignments/relation/>
	#base <coap://[2001:db8::ab]/>		#base <coap://[2001:db8::ab]/>
	reef:rd-item </ace-group/feedca570000> {		reef:rd-item </ace-group/feedca570000> {
			reef:ct 65000
	reef:rt "core.osc.gm"		reef:rt "core.osc.gm"
	reef:if "ace.group"		reef:if "ace.group"
	sec-gp "feedca570000"		sec-gp "feedca570000"
	app-gp "group1"		app-gp "group1"
	cs_alg -8		cs_alg -8
	cs_alg_crv 6		cs_alg_crv 6
	cs_key_kty 1
	cs_key_crv 6
	cs_kenc 1		cs_kenc 1
			ecdh_alg -27
			ecdh_alg_crv 4
	iana:authorization-server <coap://as.example.com/token>		iana:authorization-server <coap://as.example.com/token>
	}		}
	reef:rd-item </ace-group/ech0ech00000> {		reef:rd-item </ace-group/ech0ech00000> {
			reef:ct 65000
	reef:rt "core.osc.gm"		reef:rt "core.osc.gm"
	reef:if "ace.group"		reef:if "ace.group"
	sec-gp "ech0ech00000"		sec-gp "ech0ech00000"
	app-gp "group2"		app-gp "group2"
	cs_alg -8		cs_alg -8
	cs_alg_crv 6		cs_alg_crv 6
	cs_key_kty 1
	cs_key_crv 6
	cs_kenc 1		cs_kenc 1
			ecdh_alg -27
			ecdh_alg_crv 4
	iana:authorization-server <coap://as.example.com/token>		iana:authorization-server <coap://as.example.com/token>
	}		}
	reef:rd-item </ace-group/abcdef120000> {		reef:rd-item </ace-group/abcdef120000> {
			reef:ct 65000
	reef:rt "core.osc.gm"		reef:rt "core.osc.gm"
	reef:if "ace.group"		reef:if "ace.group"
	sec-gp "abcdef120000"		sec-gp "abcdef120000"
	app-gp "group3"		app-gp "group3"
	app-gp "group4"		app-gp "group4"
	cs_alg -8		cs_alg -8
	cs_alg_crv 6		cs_alg_crv 6
	cs_key_kty 1
	cs_key_crv 6
	cs_kenc 1		cs_kenc 1
			ecdh_alg -27
			ecdh_alg_crv 4
	iana:authorization-server <coap://as.example.com/token>		iana:authorization-server <coap://as.example.com/token>
	}		}
	Response: RD -> GM		Response: RD -> GM
	Res: 2.04 Changed		Res: 2.04 Changed
	Location-Path: /rd/4521		Location-Path: /rd/4521
	4. Discovery of Security Groups		4. Discovery of Security Groups
	A CoAP endpoint that wants to join a security group, hereafter called		A CoAP endpoint that wants to join a security group, hereafter called
	the joining node, might not have all the necessary information at		the joining node, might not have all the necessary information at
	deployment time. Also, it might want to know about possible new		deployment time. Also, it might want to know about possible new
	security groups created afterwards by the respective Group Managers.		security groups created afterwards by the respective Group Managers.
	skipping to change at page 15, line 29 ¶		skipping to change at page 16, line 26 ¶
	member (see [I-D.ietf-ace-key-groupcomm-oscore]).		member (see [I-D.ietf-ace-key-groupcomm-oscore]).
	Note that, with RD-based discovery, including the 'app-gp' parameter		Note that, with RD-based discovery, including the 'app-gp' parameter
	multiple times would result in finding only the group-membership		multiple times would result in finding only the group-membership
	resource that serves all the specified application groups, i.e. not		resource that serves all the specified application groups, i.e. not
	any group-membership resource that serves either. Therefore, a		any group-membership resource that serves either. Therefore, a
	joining node needs to perform N separate queries with different		joining node needs to perform N separate queries with different
	values for 'app-gp', in order to safely discover the (different)		values for 'app-gp', in order to safely discover the (different)
	group-membership resource(s) serving the N application groups.		group-membership resource(s) serving the N application groups.
			The discovery of security groups as defined in this document is
			applicable and useful to other CoAP endpoints than the actual joining
			nodes. In particular, other entities can be interested to discover
			and interact with the group-membership resource at the Group Manager.
			These include entities acting as signature checkers, e.g.
			intermediary gateways, that do not join a security group, but can
			retrieve public keys of group members from the Group Manager, in
			order to verify counter signatures of group messages (see Section 3
			of [I-D.ietf-core-oscore-groupcomm]).
	4.1. Discovery Example #1		4.1. Discovery Example #1
	Consistently with the examples in Section 2 and Section 3, the		Consistently with the examples in Section 2 and Section 3, the
	examples below consider a joining node that wants to join the		examples below consider a joining node that wants to join the
	security group associated with the application group "group1", but		security group associated with the application group "group1", but
	that does not know the name of the security group, the responsible GM		that does not know the name of the security group, the responsible GM
	and the group-membership resource to access.		and the group-membership resource to access.
	4.1.1. Example in Link Format		4.1.1. Example in Link Format
	skipping to change at page 15, line 45 ¶		skipping to change at page 17, line 4 ¶
	and the group-membership resource to access.		and the group-membership resource to access.
	4.1.1. Example in Link Format		4.1.1. Example in Link Format
	Request: Joining node -> RD		Request: Joining node -> RD
	Req: GET coap://rd.example.com/rd-lookup/res		Req: GET coap://rd.example.com/rd-lookup/res
	?rt=core.osc.gm&app-gp=group1		?rt=core.osc.gm&app-gp=group1
	Response: RD -> Joining node		Response: RD -> Joining node
	Res: 2.05 Content		Res: 2.05 Content
	Payload:		Payload:
	<coap://[2001:db8::ab]/ace-group/feedca570000>;rt="core.osc.gm";		<coap://[2001:db8::ab]/ace-group/feedca570000>;ct=65000;
	if="ace.group";sec-gp="feedca570000";app-gp="group1";		rt="core.osc.gm";if="ace.group";sec-gp="feedca570000";
	cs_alg="-8";cs_alg_crv="6";cs_key_kty="1";cs_key_crv=6";		app-gp="group1";cs_alg="-8";cs_alg_crv="6";
	cs_kenc="1";anchor="coap://[2001:db8::ab]"		cs_kenc="1";ecdh_alg="-27";ecdh_alg_crv="4";
			anchor="coap://[2001:db8::ab]"
	By performing the separate resource lookup below, the joining node		By performing the separate resource lookup below, the joining node
	can retrieve the link to the ACE Authorization Server associated to		can retrieve the link to the ACE Authorization Server associated to
	the GM, where to send an Authorization Request for joining the		the GM, where to send an Authorization Request for joining the
	corresponding security group (see		corresponding security group (see
	[I-D.ietf-ace-key-groupcomm-oscore]).		[I-D.ietf-ace-key-groupcomm-oscore]).
	Request: Joining node -> RD		Request: Joining node -> RD
	Req: GET coap://rd.example.com/rd-lookup/res		Req: GET coap://rd.example.com/rd-lookup/res
	?rel="authorization-server"&		?rel=authorization-server&
	anchor="coap://[2001:db8::ab]/ace-group/feedca570000"		anchor=coap://[2001:db8::ab]/ace-group/feedca570000
	Response: RD -> Joining node		Response: RD -> Joining node
	Res: 2.05 Content		Res: 2.05 Content
	Payload:		Payload:
	<coap://as.example.com/token>		<coap://as.example.com/token>
	To retrieve the multicast IP address of the CoAP group used by the		To retrieve the multicast IP address of the CoAP group used by the
	application group "group1", the joining node performs an endpoint		application group "group1", the joining node performs an endpoint
	lookup as shown below. The following assumes that the application		lookup as shown below. The following assumes that the application
	skipping to change at page 16, line 40 ¶		skipping to change at page 17, line 47 ¶
	Request: Joining node -> RD		Request: Joining node -> RD
	Req: GET coap://rd.example.com/rd-lookup/ep		Req: GET coap://rd.example.com/rd-lookup/ep
	?et=core.rd-group&ep=group1		?et=core.rd-group&ep=group1
	Response: RD -> Joining node		Response: RD -> Joining node
	Res: 2.05 Content		Res: 2.05 Content
	Payload:		Payload:
	</rd/501>;ep="group1";et="core.rd-group";		</rd/501>;ep="group1";et="core.rd-group";
	base="coap://[ff35:30:2001:db8::23]"		base="coap://[ff35:30:2001:db8::23]";rt="core.rd-ep"
	4.1.2. Example in CoRAL		4.1.2. Example in CoRAL
	Request: Joining node -> RD		Request: Joining node -> RD
	Req: GET coap://rd.example.com/rd-lookup/res		Req: GET coap://rd.example.com/rd-lookup/res
	?rt=core.osc.gm&app-gp=group1		?rt=core.osc.gm&app-gp=group1
	Accept: TBD123456 (application/coral+cbor)		Accept: TBD123456 (application/coral+cbor)
	Response: RD -> Joining node		Response: RD -> Joining node
	skipping to change at page 17, line 4 ¶		skipping to change at page 18, line 14 ¶
	4.1.2. Example in CoRAL		4.1.2. Example in CoRAL
	Request: Joining node -> RD		Request: Joining node -> RD
	Req: GET coap://rd.example.com/rd-lookup/res		Req: GET coap://rd.example.com/rd-lookup/res
	?rt=core.osc.gm&app-gp=group1		?rt=core.osc.gm&app-gp=group1
	Accept: TBD123456 (application/coral+cbor)		Accept: TBD123456 (application/coral+cbor)
	Response: RD -> Joining node		Response: RD -> Joining node
	Res: 2.05 Content		Res: 2.05 Content
	Content-Format: TBD123456 (application/coral+cbor)		Content-Format: TBD123456 (application/coral+cbor)
	Payload:		Payload:
	#using <http://coreapps.org/core.oscore-discovery#>		#using <http://coreapps.org/core.oscore-discovery#>
	#using reef = <http://coreapps.org/reef#>		#using reef = <http://coreapps.org/reef#>
	#using iana = <http://www.iana.org/assignments/relation/>		#using iana = <http://www.iana.org/assignments/relation/>
	#base <coap://[2001:db8::ab]/>		#base <coap://[2001:db8::ab]/>
	reef:rd-item </ace-group/feedca570000> {		reef:rd-item </ace-group/feedca570000> {
			reef:ct 65000
	reef:rt "core.osc.gm"		reef:rt "core.osc.gm"
	reef:if "ace.group"		reef:if "ace.group"
	sec-gp "feedca570000"		sec-gp "feedca570000"
	app-gp "group1"		app-gp "group1"
	cs_alg -8		cs_alg -8
	cs_alg_crv 6		cs_alg_crv 6
	cs_key_kty 1
	cs_key_crv 6
	cs_kenc 1		cs_kenc 1
			ecdh_alg -27
			ecdh_alg_crv 4
	iana:authorization-server <coap://as.example.com/token>		iana:authorization-server <coap://as.example.com/token>
	}		}
	To retrieve the multicast IP address of the CoAP group used by the		To retrieve the multicast IP address of the CoAP group used by the
	application group "group1", the joining node performs an endpoint		application group "group1", the joining node performs an endpoint
	lookup as shown below. The following assumes that the application		lookup as shown below. The following assumes that the application
	group "group1" had been previously registered, with		group "group1" had been previously registered, with
	ff35:30:2001:db8::23 as multicast IP address of the associated CoAP		ff35:30:2001:db8::23 as multicast IP address of the associated CoAP
	group.		group.
	skipping to change at page 18, line 12 ¶		skipping to change at page 19, line 12 ¶
	Response: RD -> Joining node		Response: RD -> Joining node
	Res: 2.05 Content		Res: 2.05 Content
	Content-Format: TBD123456 (application/coral+cbor)		Content-Format: TBD123456 (application/coral+cbor)
	Payload:		Payload:
	#using <http://coreapps.org/core.oscore-discovery#>		#using <http://coreapps.org/core.oscore-discovery#>
	#using reef = <http://coreapps.org/reef#>		#using reef = <http://coreapps.org/reef#>
	reef:rd-unit <./rd/501> {		reef:rd-unit <./rd/501> {
	reef:ep="group1"		reef:ep "group1"
	reef:et="core.rd-group"		reef:et "core.rd-group"
	reef:base <coap://[ff35:30:2001:db8::23]>		reef:base <coap://[ff35:30:2001:db8::23]>
			reef:rt "core.rd-ep"
	}		}
	4.2. Discovery Example #2		4.2. Discovery Example #2
	Consistently with the examples in Section 2 and Section 3, the		Consistently with the examples in Section 2 and Section 3, the
	examples below consider a joining node that wants to join the		examples below consider a joining node that wants to join the
	security group with name "feedca570000", but that does not know the		security group with name "feedca570000", but that does not know the
	responsible GM, the group-membership resource to access, and the		responsible GM, the group-membership resource to access, and the
	associated application groups.		associated application groups.
	skipping to change at page 18, line 45 ¶		skipping to change at page 19, line 46 ¶
	Req: GET coap://rd.example.com/rd-lookup/res		Req: GET coap://rd.example.com/rd-lookup/res
	?rt=core.osc.gm&sec-gp=feedca570000		?rt=core.osc.gm&sec-gp=feedca570000
	Observe: 0		Observe: 0
	Response: RD -> Joining node		Response: RD -> Joining node
	Res: 2.05 Content		Res: 2.05 Content
	Observe: 24		Observe: 24
	Payload:		Payload:
	<coap://[2001:db8::ab]/ace-group/feedca570000>;rt="core.osc.gm";		<coap://[2001:db8::ab]/ace-group/feedca570000>;ct=65000;
	if="ace.group";sec-gp="feedca570000";app-gp="group1";		rt="core.osc.gm";if="ace.group";sec-gp="feedca570000";
	cs_alg="-8";cs_alg_crv="6";cs_key_kty="1";cs_key_crv=6";		app-gp="group1";cs_alg="-8";cs_alg_crv="6";
	cs_kenc="1";anchor="coap://[2001:db8::ab]"		cs_kenc="1";ecdh_alg="-27";ecdh_alg_crv="4";
			anchor="coap://[2001:db8::ab]"
	Depending on the search criteria, the joining node performing the		Depending on the search criteria, the joining node performing the
	resource lookup can get large responses. This can happen, for		resource lookup can get large responses. This can happen, for
	instance, when the lookup request targets all the group-membership		instance, when the lookup request targets all the group-membership
	resources at a specified GM, or all the group-membership resources of		resources at a specified GM, or all the group-membership resources of
	all the registered GMs, as in the example below.		all the registered GMs, as in the example below.
	Request: Joining node -> RD		Request: Joining node -> RD
	Req: GET coap://rd.example.com/rd-lookup/res?rt=core.osc.gm		Req: GET coap://rd.example.com/rd-lookup/res?rt=core.osc.gm
	Response: RD -> Joining node		Response: RD -> Joining node
	Res: 2.05 Content		Res: 2.05 Content
	Payload:		Payload:
	<coap://[2001:db8::ab]/ace-group/feedca570000>;rt="core.osc.gm";		<coap://[2001:db8::ab]/ace-group/feedca570000>;ct=65000;
	if="ace.group";sec-gp="feedca570000";app-gp="group1";		rt="core.osc.gm";if="ace.group";sec-gp="feedca570000";
	cs_alg="-8";cs_alg_crv="6";cs_key_kty="1";cs_key_crv=6";		app-gp="group1";cs_alg="-8";cs_alg_crv="6";
	cs_kenc="1";anchor="coap://[2001:db8::ab]",		cs_kenc="1";ecdh_alg="-27";ecdh_alg_crv="4";
	<coap://[2001:db8::ab]/ace-group/ech0ech00000>;rt="core.osc.gm";		anchor="coap://[2001:db8::ab]",
	if="ace.group";sec-gp="ech0ech00000";app-gp="group2";		<coap://[2001:db8::ab]/ace-group/ech0ech00000>;ct=65000;
	cs_alg="-8";cs_alg_crv="6";cs_key_kty="1";cs_key_crv=6";		rt="core.osc.gm";if="ace.group";sec-gp="ech0ech00000";
	cs_kenc="1";anchor="coap://[2001:db8::ab]",		app-gp="group2";cs_alg="-8";cs_alg_crv="6";
	<coap://[2001:db8::ab]/ace-group/abcdef120000>;rt="core.osc.gm";		cs_kenc="1";ecdh_alg="-27";ecdh_alg_crv="4";
	if="ace.group";sec-gp="abcdef120000";app-gp="group3";		anchor="coap://[2001:db8::ab]",
	app-gp="group4";cs_alg="-8";cs_alg_crv="6";cs_key_kty="1";		<coap://[2001:db8::ab]/ace-group/abcdef120000>;ct=65000;
	cs_key_crv=6";cs_kenc="1";anchor="coap://[2001:db8::ab]"		rt="core.osc.gm";if="ace.group";sec-gp="abcdef120000";
			app-gp="group3";app-gp="group4";cs_alg="-8";cs_alg_crv="6";
			cs_kenc="1";ecdh_alg="-27";ecdh_alg_crv="4";
			anchor="coap://[2001:db8::ab]"
	Therefore, it is RECOMMENDED that a joining node which performs a		Therefore, it is RECOMMENDED that a joining node which performs a
	resource lookup with the CoAP Observe option specifies the value of		resource lookup with the CoAP Observe option specifies the value of
	the parameter 'sec-gp' in its GET request sent to the RD.		the parameter 'sec-gp' in its GET request sent to the RD.
	4.2.2. Example in CoRAL		4.2.2. Example in CoRAL
	Request: Joining node -> RD		Request: Joining node -> RD
	Req: GET coap://rd.example.com/rd-lookup/res		Req: GET coap://rd.example.com/rd-lookup/res
	skipping to change at page 20, line 15 ¶		skipping to change at page 21, line 15 ¶
	Observe: 24		Observe: 24
	Content-Format: TBD123456 (application/coral+cbor)		Content-Format: TBD123456 (application/coral+cbor)
	Payload:		Payload:
	#using <http://coreapps.org/core.oscore-discovery#>		#using <http://coreapps.org/core.oscore-discovery#>
	#using reef = <http://coreapps.org/reef#>		#using reef = <http://coreapps.org/reef#>
	#using iana = <http://www.iana.org/assignments/relation/>		#using iana = <http://www.iana.org/assignments/relation/>
	#base <coap://[2001:db8::ab]/>		#base <coap://[2001:db8::ab]/>
	reef:rd-item </ace-group/feedca570000> {		reef:rd-item </ace-group/feedca570000> {
	reef:rt "core.osc.gm"		reef:ct 65000
	reef:if "ace.group"		reef:rt "core.osc.gm"
	sec-gp "feedca570000"		reef:if "ace.group"
	app-gp "group1"		sec-gp "feedca570000"
	cs_alg -8		app-gp "group1"
	cs_alg_crv 6		cs_alg -8
	cs_key_kty 1		cs_alg_crv 6
	cs_key_crv 6		cs_kenc 1
	cs_kenc 1		ecdh_alg -27
	iana:authorization-server <coap://as.example.com/token>		ecdh_alg_crv 4
			iana:authorization-server <coap://as.example.com/token>
	}		}
	5. Use Case Example With Full Discovery		5. Use Case Example With Full Discovery
	In this section, the discovery of security groups is described to		In this section, the discovery of security groups is described to
	support the installation process of a lighting installation in an		support the installation process of a lighting installation in an
	office building. The described process is a simplified version of		office building. The described process is a simplified version of
	one of many processes.		one of many processes.
	The process described in this section is intended as an example and		The process described in this section is intended as an example and
	skipping to change at page 22, line 35 ¶		skipping to change at page 23, line 35 ¶
	Finally, the CT defines the corresponding security groups. In		Finally, the CT defines the corresponding security groups. In
	particular, assuming a Group Manager responsible for both security		particular, assuming a Group Manager responsible for both security
	groups and with address [2001:db8::ab], the CT specifies:		groups and with address [2001:db8::ab], the CT specifies:
	Request: CT -> RD		Request: CT -> RD
	Req: POST coap://[2001:db8:4::ff]/rd		Req: POST coap://[2001:db8:4::ff]/rd
	?ep=gm1&base=coap://[2001:db8::ab]		?ep=gm1&base=coap://[2001:db8::ab]
	Content-Format: 40		Content-Format: 40
	Payload:		Payload:
	</ace-group/feedca570000>;ct=41;rt="core.osc.gm";if="ace.group";		</ace-group/feedca570000>;ct=65000;rt="core.osc.gm";if="ace.group";
	sec-gp="feedca570000";		sec-gp="feedca570000";
	app-gp="grp_R2-4-015",		app-gp="grp_R2-4-015",
	</ace-group/feedsc590000>;ct=41;rt="core.osc.gm";if="ace.group";		</ace-group/feedsc590000>;ct=65000;rt="core.osc.gm";if="ace.group";
	sec-gp="feedsc590000";		sec-gp="feedsc590000";
	app-gp="grp_schedule"		app-gp="grp_schedule"
	Response: RD -> CT		Response: RD -> CT
	Res: 2.01 Created		Res: 2.01 Created
	Location-Path: /rd/4521		Location-Path: /rd/4521
	*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***		*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
	skipping to change at page 23, line 16 ¶		skipping to change at page 24, line 16 ¶
	Req: GET coap://[2001:db8:4::ff]/rd-lookup/ep		Req: GET coap://[2001:db8:4::ff]/rd-lookup/ep
	?et=core.rd-group&ep=grp_R2-4-015		?et=core.rd-group&ep=grp_R2-4-015
	Response: RD -> Joining node		Response: RD -> Joining node
	Res: 2.05 Content		Res: 2.05 Content
	Content-Format: 40		Content-Format: 40
	Payload:		Payload:
	</rd/501>;ep="grp_R2-4-015";et="core.rd-group";		</rd/501>;ep="grp_R2-4-015";et="core.rd-group";
	base="coap://[ff05::5:1]"		base="coap://[ff05::5:1]";rt="core.rd-ep"
	Similarly, to retrieve the multicast IP address of the CoAP group		Similarly, to retrieve the multicast IP address of the CoAP group
	used by the application group "grp_schedule", the device performs an		used by the application group "grp_schedule", the device performs an
	endpoint lookup as shown below.		endpoint lookup as shown below.
	Request: Joining node -> RD		Request: Joining node -> RD
	Req: GET coap://[2001:db8:4::ff]/rd-lookup/ep		Req: GET coap://[2001:db8:4::ff]/rd-lookup/ep
	?et=core.rd-group&ep=grp_schedule		?et=core.rd-group&ep=grp_schedule
	Response: RD -> Joining node		Response: RD -> Joining node
	Res: 2.05 Content		Res: 2.05 Content
	Content-Format: 40		Content-Format: 40
	Payload:		Payload:
	</rd/502>;ep="grp_schedule";et="core.rd-group";		</rd/502>;ep="grp_schedule";et="core.rd-group";
	base="coap://[ff05::5:2]"		base="coap://[ff05::5:2]";rt="core.rd-ep"
	*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***		*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
	Consequently, the device learns the security groups it has to join.		Consequently, the device learns the security groups it has to join.
	In particular, it does the following for app-gp="grp_R2-4-015".		In particular, it does the following for app-gp="grp_R2-4-015".
	Request: Joining node -> RD		Request: Joining node -> RD
	Req: GET coap://[2001:db8:4::ff]/rd-lookup/res		Req: GET coap://[2001:db8:4::ff]/rd-lookup/res
	?rt=core.osc.gm&app-gp=grp_R2-4-015		?rt=core.osc.gm&app-gp=grp_R2-4-015
	Response: RD -> Joining Node		Response: RD -> Joining Node
	Res: 2.05 Content		Res: 2.05 Content
	Content-Format: 40		Content-Format: 40
	Payload:		Payload:
	<coap://[2001:db8::ab]/ace-group/feedca570000>;		<coap://[2001:db8::ab]/ace-group/feedca570000>;ct=65000;
	rt="core.osc.gm";if="ace.group";sec-gp="feedca570000";		rt="core.osc.gm";if="ace.group";sec-gp="feedca570000";
	app-gp="grp_R2-4-015";anchor="coap://[2001:db8::ab]"		app-gp="grp_R2-4-015";anchor="coap://[2001:db8::ab]"
	Similarly, the device does the following for app-gp="grp_schedule".		Similarly, the device does the following for app-gp="grp_schedule".
	Req: GET coap://[2001:db8:4::ff]/rd-lookup/res		Req: GET coap://[2001:db8:4::ff]/rd-lookup/res
	?rt=core.osc.gm&app-gp=grp_schedule		?rt=core.osc.gm&app-gp=grp_schedule
	Response: RD -> Joining Node		Response: RD -> Joining Node
	Res: 2.05 Content		Res: 2.05 Content
	Content-Format: 40		Content-Format: 40
	Payload:		Payload:
	<coap://[2001:db8::ab]/ace-group/feedsc590000>;		<coap://[2001:db8::ab]/ace-group/feedsc590000>;ct=65000;
	rt="core.osc.gm";if="ace.group";sec-gp="feedsc590000";		rt="core.osc.gm";if="ace.group";sec-gp="feedsc590000";
	app-gp="grp_schedule";anchor="coap://[2001:db8::ab]"		app-gp="grp_schedule";anchor="coap://[2001:db8::ab]"
	*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***		*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
	After this last discovery step, the device can ask permission to join		After this last discovery step, the device can ask permission to join
	the security groups, and effectively join them through the Group		the security groups, and effectively join them through the Group
	Manager, e.g. according to [I-D.ietf-ace-key-groupcomm-oscore].		Manager, e.g. according to [I-D.ietf-ace-key-groupcomm-oscore].
	6. Security Considerations		6. Security Considerations
	skipping to change at page 25, line 13 ¶		skipping to change at page 26, line 13 ¶
	type>.		type>.
	[I-D.ietf-core-coral]		[I-D.ietf-core-coral]
	Hartke, K., "The Constrained RESTful Application Language		Hartke, K., "The Constrained RESTful Application Language
	(CoRAL)", draft-ietf-core-coral-03 (work in progress),		(CoRAL)", draft-ietf-core-coral-03 (work in progress),
	March 2020.		March 2020.
	[I-D.ietf-core-groupcomm-bis]		[I-D.ietf-core-groupcomm-bis]
	Dijk, E., Wang, C., and M. Tiloca, "Group Communication		Dijk, E., Wang, C., and M. Tiloca, "Group Communication
	for the Constrained Application Protocol (CoAP)", draft-		for the Constrained Application Protocol (CoAP)", draft-
	ietf-core-groupcomm-bis-02 (work in progress), November		ietf-core-groupcomm-bis-03 (work in progress), February
	2020.		2021.
	[I-D.ietf-core-oscore-groupcomm]		[I-D.ietf-core-oscore-groupcomm]
	Tiloca, M., Selander, G., Palombini, F., and J. Park,		Tiloca, M., Selander, G., Palombini, F., Mattsson, J., and
	"Group OSCORE - Secure Group Communication for CoAP",		J. Park, "Group OSCORE - Secure Group Communication for
	draft-ietf-core-oscore-groupcomm-10 (work in progress),		CoAP", draft-ietf-core-oscore-groupcomm-11 (work in
	November 2020.		progress), February 2021.
	[I-D.ietf-core-resource-directory]		[I-D.ietf-core-resource-directory]
	Shelby, Z., Koster, M., Bormann, C., Stok, P., and C.		Amsuess, C., Shelby, Z., Koster, M., Bormann, C., and P.
	Amsuess, "CoRE Resource Directory", draft-ietf-core-		Stok, "CoRE Resource Directory", draft-ietf-core-resource-
	resource-directory-25 (work in progress), July 2020.		directory-26 (work in progress), November 2020.
	[I-D.ietf-cose-rfc8152bis-algs]		[I-D.ietf-cose-rfc8152bis-algs]
	Schaad, J., "CBOR Object Signing and Encryption (COSE):		Schaad, J., "CBOR Object Signing and Encryption (COSE):
	Initial Algorithms", draft-ietf-cose-rfc8152bis-algs-12		Initial Algorithms", draft-ietf-cose-rfc8152bis-algs-12
	(work in progress), September 2020.		(work in progress), September 2020.
	[I-D.ietf-cose-rfc8152bis-struct]		[I-D.ietf-cose-rfc8152bis-struct]
	Schaad, J., "CBOR Object Signing and Encryption (COSE):		Schaad, J., "CBOR Object Signing and Encryption (COSE):
	Structures and Process", draft-ietf-cose-rfc8152bis-		Structures and Process", draft-ietf-cose-rfc8152bis-
	struct-14 (work in progress), September 2020.		struct-15 (work in progress), February 2021.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link		[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link
	Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,		Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
	<https://www.rfc-editor.org/info/rfc6690>.		<https://www.rfc-editor.org/info/rfc6690>.
	skipping to change at page 26, line 27 ¶		skipping to change at page 27, line 31 ¶
	2018.pdf>.		2018.pdf>.
	[I-D.hartke-t2trg-coral-reef]		[I-D.hartke-t2trg-coral-reef]
	Hartke, K., "Resource Discovery in Constrained RESTful		Hartke, K., "Resource Discovery in Constrained RESTful
	Environments (CoRE) using the Constrained RESTful		Environments (CoRE) using the Constrained RESTful
	Application Language (CoRAL)", draft-hartke-t2trg-coral-		Application Language (CoRAL)", draft-hartke-t2trg-coral-
	reef-04 (work in progress), May 2020.		reef-04 (work in progress), May 2020.
	[I-D.ietf-ace-key-groupcomm]		[I-D.ietf-ace-key-groupcomm]
	Palombini, F. and M. Tiloca, "Key Provisioning for Group		Palombini, F. and M. Tiloca, "Key Provisioning for Group
	Communication using ACE", draft-ietf-ace-key-groupcomm-10		Communication using ACE", draft-ietf-ace-key-groupcomm-11
	(work in progress), November 2020.		(work in progress), February 2021.
	[I-D.ietf-ace-key-groupcomm-oscore]		[I-D.ietf-ace-key-groupcomm-oscore]
	Tiloca, M., Park, J., and F. Palombini, "Key Management		Tiloca, M., Park, J., and F. Palombini, "Key Management
	for OSCORE Groups in ACE", draft-ietf-ace-key-groupcomm-		for OSCORE Groups in ACE", draft-ietf-ace-key-groupcomm-
	oscore-09 (work in progress), November 2020.		oscore-10 (work in progress), February 2021.
	[I-D.ietf-ace-oauth-authz]		[I-D.ietf-ace-oauth-authz]
	Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and		Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
	H. Tschofenig, "Authentication and Authorization for		H. Tschofenig, "Authentication and Authorization for
	Constrained Environments (ACE) using the OAuth 2.0		Constrained Environments (ACE) using the OAuth 2.0
	Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-35		Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-37
	(work in progress), June 2020.		(work in progress), February 2021.
	[I-D.ietf-ace-oscore-gm-admin]		[I-D.ietf-ace-oscore-gm-admin]
	Tiloca, M., Hoeglund, R., Stok, P., Palombini, F., and K.		Tiloca, M., Hoeglund, R., Stok, P., Palombini, F., and K.
	Hartke, "Admin Interface for the OSCORE Group Manager",		Hartke, "Admin Interface for the OSCORE Group Manager",
	draft-ietf-ace-oscore-gm-admin-01 (work in progress),		draft-ietf-ace-oscore-gm-admin-02 (work in progress),
	November 2020.		February 2021.
	[I-D.ietf-anima-bootstrapping-keyinfra]		[I-D.ietf-anima-bootstrapping-keyinfra]
	Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,		Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
	and K. Watsen, "Bootstrapping Remote Secure Key		and K. Watsen, "Bootstrapping Remote Secure Key
	Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-		Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
	keyinfra-44 (work in progress), September 2020.		keyinfra-45 (work in progress), November 2020.
	[I-D.ietf-cbor-7049bis]
	Bormann, C. and P. Hoffman, "Concise Binary Object
	Representation (CBOR)", draft-ietf-cbor-7049bis-16 (work
	in progress), September 2020.
	[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for		[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
	Constrained-Node Networks", RFC 7228,		Constrained-Node Networks", RFC 7228,
	DOI 10.17487/RFC7228, May 2014,		DOI 10.17487/RFC7228, May 2014,
	<https://www.rfc-editor.org/info/rfc7228>.		<https://www.rfc-editor.org/info/rfc7228>.
	[RFC7641] Hartke, K., "Observing Resources in the Constrained		[RFC7641] Hartke, K., "Observing Resources in the Constrained
	Application Protocol (CoAP)", RFC 7641,		Application Protocol (CoAP)", RFC 7641,
	DOI 10.17487/RFC7641, September 2015,		DOI 10.17487/RFC7641, September 2015,
	<https://www.rfc-editor.org/info/rfc7641>.		<https://www.rfc-editor.org/info/rfc7641>.
	[RFC8132] van der Stok, P., Bormann, C., and A. Sehgal, "PATCH and		[RFC8132] van der Stok, P., Bormann, C., and A. Sehgal, "PATCH and
	FETCH Methods for the Constrained Application Protocol		FETCH Methods for the Constrained Application Protocol
	(CoAP)", RFC 8132, DOI 10.17487/RFC8132, April 2017,		(CoAP)", RFC 8132, DOI 10.17487/RFC8132, April 2017,
	<https://www.rfc-editor.org/info/rfc8132>.		<https://www.rfc-editor.org/info/rfc8132>.
	[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
	Interchange Format", STD 90, RFC 8259,
	DOI 10.17487/RFC8259, December 2017,
	<https://www.rfc-editor.org/info/rfc8259>.
	[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz,		[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
	"Object Security for Constrained RESTful Environments		"Object Security for Constrained RESTful Environments
	(OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,		(OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
	<https://www.rfc-editor.org/info/rfc8613>.		<https://www.rfc-editor.org/info/rfc8613>.
	Appendix A. Use Case Example With Full Discovery (CoRAL)		Appendix A. Use Case Example With Full Discovery (CoRAL)
	This section provides the same use case example of Section 5, but		This section provides the same use case example of Section 5, but
	specified in CoRAL [I-D.ietf-core-coral].		specified in CoRAL [I-D.ietf-core-coral].
	skipping to change at page 29, line 13 ¶		skipping to change at page 30, line 13 ¶
	Request: CT -> RD		Request: CT -> RD
	Req: POST coap://[2001:db8:4::ff]/rd?ep=gm1		Req: POST coap://[2001:db8:4::ff]/rd?ep=gm1
	Content-Format: TBD123456 (application/coral+cbor)		Content-Format: TBD123456 (application/coral+cbor)
	Payload:		Payload:
	#using <http://coreapps.org/core.oscore-discovery#>		#using <http://coreapps.org/core.oscore-discovery#>
	#using reef = <http://coreapps.org/reef#>		#using reef = <http://coreapps.org/reef#>
	#base <coap://[2001:db8::ab]/>		#base <coap://[2001:db8::ab]/>
	reef:rd-item </ace-group/feedca570000> {		reef:rd-item </ace-group/feedca570000> {
			reef:ct 65000
	reef:ct 41		reef:ct 41
	reef:rt "core.osc.gm"		reef:rt "core.osc.gm"
	reef:if "ace.group"		reef:if "ace.group"
	sec-gp "feedca570000"		sec-gp "feedca570000"
	app-gp "grp_R2-4-015"		app-gp "grp_R2-4-015"
	}		}
	reef:rd-item </ace-group/feedsc590000> {		reef:rd-item </ace-group/feedsc590000> {
			reef:ct 65000
	reef:ct 41		reef:ct 41
	reef:rt "core.osc.gm"		reef:rt "core.osc.gm"
	reef:if "ace.group"		reef:if "ace.group"
	sec-gp "feedsc590000"		sec-gp "feedsc590000"
	app-gp "grp_schedule"		app-gp "grp_schedule"
	}		}
	Response: RD -> CT		Response: RD -> CT
	Res: 2.01 Created		Res: 2.01 Created
	skipping to change at page 30, line 15 ¶		skipping to change at page 31, line 15 ¶
	Content-Format: TBD123456 (application/coral+cbor)		Content-Format: TBD123456 (application/coral+cbor)
	Payload:		Payload:
	#using reef = <http://coreapps.org/reef#>		#using reef = <http://coreapps.org/reef#>
	#base <coap://[2001:db8:4::ff]/rd/>		#base <coap://[2001:db8:4::ff]/rd/>
	reef:rd-unit <501> {		reef:rd-unit <501> {
	reef:ep "grp_R2-4-015"		reef:ep "grp_R2-4-015"
	reef:et "core.rd-group"		reef:et "core.rd-group"
	reef:base <coap://[ff05::5:1]/>		reef:base <coap://[ff05::5:1]/>
			reef:rt "core.rd-ep"
	}		}
	Similarly, to retrieve the multicast IP address of the CoAP group		Similarly, to retrieve the multicast IP address of the CoAP group
	used by the application group "grp_schedule", the device performs an		used by the application group "grp_schedule", the device performs an
	endpoint lookup as shown below.		endpoint lookup as shown below.
	Request: Joining node -> RD		Request: Joining node -> RD
	Req: GET coap://[2001:db8:4::ff]/rd-lookup/ep		Req: GET coap://[2001:db8:4::ff]/rd-lookup/ep
	?et=core.rd-group&ep=grp_schedule		?et=core.rd-group&ep=grp_schedule
	Response: RD -> Joining node		Response: RD -> Joining node
	Res: 2.05 Content		Res: 2.05 Content
	Content-Format: TBD123456 (application/coral+cbor)		Content-Format: TBD123456 (application/coral+cbor)
	Payload:		Payload:
	#using reef = <http://coreapps.org/reef#>		#using reef = <http://coreapps.org/reef#>
	#base <coap://[2001:db8:4::ff]/rd/>		#base <coap://[2001:db8:4::ff]/rd/>
	reef:rd-unit <501> {		reef:rd-unit <502> {
	reef:ep "grp_schedule"		reef:ep "grp_schedule"
	reef:et "core.rd-group"		reef:et "core.rd-group"
	reef:base <coap://[ff05::5:2]/>		reef:base <coap://[ff05::5:2]/>
			reef:rt "core.rd-ep"
	}		}
	*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***		*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
	Consequently, the device learns the security groups it has to join.		Consequently, the device learns the security groups it has to join.
	In particular, it does the following for app-gp="grp_R2-4-015".		In particular, it does the following for app-gp="grp_R2-4-015".
	Request: Joining node -> RD		Request: Joining node -> RD
	Req: GET coap://[2001:db8:4::ff]/rd-lookup/res		Req: GET coap://[2001:db8:4::ff]/rd-lookup/res
	skipping to change at page 31, line 4 ¶		skipping to change at page 32, line 6 ¶
	Consequently, the device learns the security groups it has to join.		Consequently, the device learns the security groups it has to join.
	In particular, it does the following for app-gp="grp_R2-4-015".		In particular, it does the following for app-gp="grp_R2-4-015".
	Request: Joining node -> RD		Request: Joining node -> RD
	Req: GET coap://[2001:db8:4::ff]/rd-lookup/res		Req: GET coap://[2001:db8:4::ff]/rd-lookup/res
	?rt=core.osc.gm&app-gp=grp_R2-4-015		?rt=core.osc.gm&app-gp=grp_R2-4-015
	Response: RD -> Joining Node		Response: RD -> Joining Node
	Res: 2.05 Content		Res: 2.05 Content
	Content-Format: TBD123456 (application/coral+cbor)		Content-Format: TBD123456 (application/coral+cbor)
	Payload:		Payload:
	#using <http://coreapps.org/core.oscore-discovery#>		#using <http://coreapps.org/core.oscore-discovery#>
	#using reef = <http://coreapps.org/reef#>		#using reef = <http://coreapps.org/reef#>
	#base <coap://[2001:db8::ab]/>		#base <coap://[2001:db8::ab]/>
	reef:rd-item </ace-group/feedca570000> {		reef:rd-item </ace-group/feedca570000> {
			reef:ct 65000
	reef:rt "core.osc.gm"		reef:rt "core.osc.gm"
	reef:if "ace.group"		reef:if "ace.group"
	sec-gp "feedca570000"		sec-gp "feedca570000"
	app-gp "grp_R2-4-015"		app-gp "grp_R2-4-015"
	}		}
	Similarly, the device does the following for app-gp="grp_schedule".		Similarly, the device does the following for app-gp="grp_schedule".
	Req: GET coap://[2001:db8:4::ff]/rd-lookup/res		Req: GET coap://[2001:db8:4::ff]/rd-lookup/res
	?rt=core.osc.gm&app-gp=grp_schedule		?rt=core.osc.gm&app-gp=grp_schedule
	skipping to change at page 31, line 35 ¶		skipping to change at page 32, line 39 ¶
	Res: 2.05 Content		Res: 2.05 Content
	Content-Format: TBD123456 (application/coral+cbor)		Content-Format: TBD123456 (application/coral+cbor)
	Payload:		Payload:
	#using <http://coreapps.org/core.oscore-discovery#>		#using <http://coreapps.org/core.oscore-discovery#>
	#using reef = <http://coreapps.org/reef#>		#using reef = <http://coreapps.org/reef#>
	#base <coap://[2001:db8::ab]/>		#base <coap://[2001:db8::ab]/>
	reef:rd-item </ace-group/feedsc590000> {		reef:rd-item </ace-group/feedsc590000> {
			reef:ct 65000
	reef:rt "core.osc.gm"		reef:rt "core.osc.gm"
	reef:if "ace.group"		reef:if "ace.group"
	sec-gp "feedsc590000"		sec-gp "feedsc590000"
	app-gp "grp_schedule"		app-gp "grp_schedule"
	}		}
	*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***		*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
	After this last discovery step, the device can ask permission to join		After this last discovery step, the device can ask permission to join
	the security groups, and effectively join them through the Group		the security groups, and effectively join them through the Group
End of changes. 83 change blocks.
	161 lines changed or deleted		218 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/