< draft-ietf-lpwan-coap-static-context-hc-09.txt		draft-ietf-lpwan-coap-static-context-hc-10.txt >
	lpwan Working Group A. Minaburo		lpwan Working Group A. Minaburo
	Internet-Draft Acklio		Internet-Draft Acklio
	Intended status: Standards Track L. Toutain		Intended status: Standards Track L. Toutain
	Expires: January 7, 2020 Institut MINES TELECOM; IMT Atlantique		Expires: April 10, 2020 Institut MINES TELECOM; IMT Atlantique
	R. Andreasen		R. Andreasen
	Universidad de Buenos Aires		Universidad de Buenos Aires
	July 06, 2019		October 08, 2019
	LPWAN Static Context Header Compression (SCHC) for CoAP		LPWAN Static Context Header Compression (SCHC) for CoAP
	draft-ietf-lpwan-coap-static-context-hc-09		draft-ietf-lpwan-coap-static-context-hc-10
	Abstract		Abstract
	This draft defines the way SCHC header compression can be applied to		This draft defines the way SCHC header compression can be applied to
	CoAP headers. The CoAP header structure differs from IPv6 and UDP		CoAP headers. The CoAP header structure differs from IPv6 and UDP
	protocols since CoAP uses a flexible header with a variable number of		protocols since CoAP uses a flexible header with a variable number of
	options, themselves of variable length. The CoAP protocol is		options, themselves of variable length. The CoAP protocol messages
	asymmetric in its message format: the format of the packet header in		format is asymmetric: the request messages have a header format
	the request messages is different from that in the response messages.		different from the one in the response messages. This document
	Most of the compression mechanisms have been introduced in		explains how to use the SCHC compression mechanism described in
	[I-D.ietf-lpwan-ipv6-static-context-hc], this document explains how		[I-D.ietf-lpwan-ipv6-static-context-hc] for CoAP.
	to use the SCHC compression for CoAP.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 January 7, 2020.		This Internet-Draft will expire on April 10, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. SCHC Compression Process . . . . . . . . . . . . . . . . . . 3		2. SCHC Compression Process . . . . . . . . . . . . . . . . . . 3
	3. CoAP Compression with SCHC . . . . . . . . . . . . . . . . . 4		3. CoAP Compression with SCHC . . . . . . . . . . . . . . . . . 4
	4. Compression of CoAP header fields . . . . . . . . . . . . . . 6		4. Compression of CoAP header fields . . . . . . . . . . . . . . 6
	4.1. CoAP version field . . . . . . . . . . . . . . . . . . . 6		4.1. CoAP version field . . . . . . . . . . . . . . . . . . . 6
	4.2. CoAP type field . . . . . . . . . . . . . . . . . . . . . 6		4.2. CoAP type field . . . . . . . . . . . . . . . . . . . . . 6
	4.3. CoAP code field . . . . . . . . . . . . . . . . . . . . . 6		4.3. CoAP code field . . . . . . . . . . . . . . . . . . . . . 6
	4.4. CoAP Message ID field . . . . . . . . . . . . . . . . . . 6		4.4. CoAP Message ID field . . . . . . . . . . . . . . . . . . 6
	4.5. CoAP Token fields . . . . . . . . . . . . . . . . . . . . 7		4.5. CoAP Token fields . . . . . . . . . . . . . . . . . . . . 7
	5. CoAP options . . . . . . . . . . . . . . . . . . . . . . . . 7		5. CoAP options . . . . . . . . . . . . . . . . . . . . . . . . 7
	5.1. CoAP Content and Accept options. . . . . . . . . . . . . 7		5.1. CoAP Content and Accept options. . . . . . . . . . . . . 7
	5.2. CoAP option Max-Age, Uri-Host and Uri-Port fields . . . . 7		5.2. CoAP option Max-Age, Uri-Host and Uri-Port fields . . . . 8
	5.3. CoAP option Uri-Path and Uri-Query fields . . . . . . . . 8		5.3. CoAP option Uri-Path and Uri-Query fields . . . . . . . . 8
	5.3.1. Variable length Uri-Path and Uri-Query . . . . . . . 8		5.3.1. Variable length Uri-Path and Uri-Query . . . . . . . 8
	5.3.2. Variable number of path or query elements . . . . . . 9		5.3.2. Variable number of path or query elements . . . . . . 9
	5.4. CoAP option Size1, Size2, Proxy-URI and Proxy-Scheme		5.4. CoAP option Size1, Size2, Proxy-URI and Proxy-Scheme
	fields . . . . . . . . . . . . . . . . . . . . . . . . . 9		fields . . . . . . . . . . . . . . . . . . . . . . . . . 9
	5.5. CoAP option ETag, If-Match, If-None-Match, Location-Path		5.5. CoAP option ETag, If-Match, If-None-Match, Location-Path
	and Location-Query fields . . . . . . . . . . . . . . . . 9		and Location-Query fields . . . . . . . . . . . . . . . . 9
	6. Other RFCs . . . . . . . . . . . . . . . . . . . . . . . . . 9		6. Other RFCs . . . . . . . . . . . . . . . . . . . . . . . . . 10
	6.1. Block . . . . . . . . . . . . . . . . . . . . . . . . . . 9		6.1. Block . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	6.2. Observe . . . . . . . . . . . . . . . . . . . . . . . . . 10		6.2. Observe . . . . . . . . . . . . . . . . . . . . . . . . . 10
	6.3. No-Response . . . . . . . . . . . . . . . . . . . . . . . 10		6.3. No-Response . . . . . . . . . . . . . . . . . . . . . . . 10
	6.4. OSCORE . . . . . . . . . . . . . . . . . . . . . . . . . 10		6.4. OSCORE . . . . . . . . . . . . . . . . . . . . . . . . . 10
	7. Examples of CoAP header compression . . . . . . . . . . . . . 11		7. Examples of CoAP header compression . . . . . . . . . . . . . 12
	7.1. Mandatory header with CON message . . . . . . . . . . . . 11		7.1. Mandatory header with CON message . . . . . . . . . . . . 12
	7.2. OSCORE Compression . . . . . . . . . . . . . . . . . . . 12		7.2. OSCORE Compression . . . . . . . . . . . . . . . . . . . 13
	7.3. Example OSCORE Compression . . . . . . . . . . . . . . . 16		7.3. Example OSCORE Compression . . . . . . . . . . . . . . . 16
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
	9. Security considerations . . . . . . . . . . . . . . . . . . . 26		9. Security considerations . . . . . . . . . . . . . . . . . . . 26
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
	11. Normative References . . . . . . . . . . . . . . . . . . . . 26		11. Normative References . . . . . . . . . . . . . . . . . . . . 26
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
	1. Introduction		1. Introduction
	CoAP [rfc7252] is an implementation of the REST architecture for		CoAP [rfc7252] is an implementation of the REST architecture for
	constrained devices. Although CoAP was designed for constrained		constrained devices. Although CoAP was designed for constrained
	devices, the size of a CoAP header may still be too large for the		devices, the size of a CoAP header still is too large for the
	constraints of Low Power Wide Area Networks (LPWAN) and some		constraints of Low Power Wide Area Networks (LPWAN) and some
	compression may be needed to reduce the header size.		compression is needed to reduce the header size.
	[I-D.ietf-lpwan-ipv6-static-context-hc] defines a header compression		[I-D.ietf-lpwan-ipv6-static-context-hc] defines a header compression
	mechanism for LPWAN network based on a static context. The context		mechanism for LPWAN network based on a static context. The context
	is said static since the field description composing the Rules are		is said static since the field description composing the Rules are
	not learned during the packet exchanges but are previously defined.		not learned during the packet exchanges but are previously defined.
	The context(s) is(are) known by both ends before transmission.		The context(s) is(are) known by both ends before transmission.
	A context is composed of a set of rules that are referenced by Rule		A context is composed of a set of rules that are referenced by Rule
	IDs (identifiers). A rule contains an ordered list of the fields		IDs (identifiers). A rule contains an ordered list of the fields
	descriptions containing a field ID (FID), its length (FL) and its		descriptions containing a field ID (FID), its length (FL) and its
	position (FP), a direction indicator (DI) (upstream, downstream and		position (FP), a direction indicator (DI) (upstream, downstream and
	bidirectional) and some associated Target Values (TV). Target Value		bidirectional) and some associated Target Values (TV). Target Value
	indicates the value that can be expected. TV can also be a list of		indicates the value that can be expected. TV can also be a list of
	values. A Matching Operator (MO) is associated to each header field		values. A Matching Operator (MO) is associated to each header field
	description. The rule is selected if all the MOs fit the TVs for all		description. The rule is selected if all the MOs fit the TVs for all
	fields of the incoming packet. In that case, a Compression/		fields of the incoming packet. In that case, a Compression/
	Decompression Action (CDA) associated to each field defines how the		Decompression Action (CDA) associated to each field defines how the
	compressed and the decompressed values are computed out of each		compressed and the decompressed values are computed out of each
	other, for each of the header fields. Compression mainly results in		other, for each of the header fields. Compression mainly results in
	one of 4 actions: send the field value, send nothing, send some least		one of 4 actions: send the field value, send nothing, send some least
	significant bits of the field or send an index. Values sent are		significant bits of the field or send an index. After applying the
	called Compression Residues and follow the rule ID in the transmitted		compression there may be some bits to be sent, these values are
	message.		called Compression Residues and are transmitted after the Rule ID in
			the compressed messages.
	The compression rules define a generic way to compress and decompress		The compression rules define a generic way to compress and decompress
	the fields. If the device is modified, for example, to introduce new		the fields. If the device is modified, for example, to introduce new
	functionalities or new CoAP options, the rules must be updated to		functionalities or new CoAP options, the rules must be updated to
	reflect the evolution. There is no risk to lock a device in a		reflect the evolution. There is no risk to lock a device in a
	particular version of CoAP.		particular version of CoAP.
	2. SCHC Compression Process		2. SCHC Compression Process
	The SCHC Compression rules can be applied to CoAP flows. SCHC		The SCHC Compression rules can be applied to CoAP flows. SCHC
	skipping to change at page 4, line 20 ¶		skipping to change at page 4, line 20 ¶
	| | IPv6 | | UDP | | +------------+		| | IPv6 | | UDP | | +------------+
	v +------------+ +------------+ | | IPv6 |		v +------------+ +------------+ | | IPv6 |
	| IPv6 | v +------------+		| IPv6 | v +------------+
	+------------+		+------------+
	Figure 1: rule scope for CoAP		Figure 1: rule scope for CoAP
	Figure 1 shows some examples for CoAP architecture and the SCHC		Figure 1 shows some examples for CoAP architecture and the SCHC
	rule's scope.		rule's scope.
	In the first example, a rule compresses all headers from IPv6 to		In the first example, a rule compresses the complete header stack
	CoAP. In this case, SCHC C/D is performed at the device and at the		from IPv6 to CoAP. In this case, SCHC C/D is performed at the device
	LPWAN boundary.		and at the LPWAN boundary.
	In the second example, an end-to-end encryption mechanisms is used		In the second example, an end-to-end encryption mechanisms is used
	between the device and the application. CoAP is compressed		between the device and the application. The SCHC compression is
	independently of the other layers. The rule ID and the compression		applied in the CoAP layer compressing the CoAP header independently
	residue are encrypted using a mechanism such as DTLS. Only the other		of the other layers. The rule ID and the compression residue are
	end can decipher the information.		encrypted using a mechanism such as DTLS. Only the other end can
	Layers below may also be compressed using other SCHC rules (this is		decipher the information. Layers below may also be compressed using
	out of the scope of this document).		other SCHC rules (this is out of the scope of this document) as
			defined in the SCHC [I-D.ietf-lpwan-ipv6-static-context-hc] document.
	In the third example, OSCORE [I-D.ietf-core-object-security] is used.		In the third example, OSCORE [rfc8613] is used. In this case, two
	2 rulesets are used to compress the CoAP message. A first ruleset		rulesets are used to compress the CoAP message. A first ruleset
	focuses on the inner header and is end to end, a second ruleset		focused on the inner header and is applied end to end by both ends.
	compresses the outer header and the layers below. SCHC C/D for inner		A second ruleset compresses the outer header and the layers below and
	header is done by both ends, and SCHC C/D for outer header and other		is done between the device and the LPWAN boundary.
	headers is done between the device and the LPWAN boundary.
	3. CoAP Compression with SCHC		3. CoAP Compression with SCHC
	CoAP differs from IPv6 and UDP protocols on the following aspects:		CoAP differs from IPv6 and UDP protocols on the following aspects:
	o IPv6 and UDP are symmetrical protocols. The same fields are found		o IPv6 and UDP are symmetrical protocols. The same fields are found
	in the request and in the response, with the value of some fields		in the request and in the response, with the value of some fields
	being swapped on the return path (e.g. source and destination		being swapped on the return path (e.g. source and destination
	fields). A CoAP request is intrinsically different from a		fields). A CoAP request is intrinsically different from a
	response. For example, the URI-path option is mandatory in the		response. For example, the URI-path option is mandatory in the
	skipping to change at page 5, line 17 ¶		skipping to change at page 5, line 17 ¶
	single Rule to process message headers differently depending of		single Rule to process message headers differently depending of
	the direction.		the direction.
	o Even when a field is "symmetric" (i.e. found in both directions)		o Even when a field is "symmetric" (i.e. found in both directions)
	the values carried in each direction are different. Combined with		the values carried in each direction are different. Combined with
	a matching list in the TV, this allows reducing the range of		a matching list in the TV, this allows reducing the range of
	expected values in a particular direction and therefore reduce the		expected values in a particular direction and therefore reduce the
	size of the compression residue. For instance, if a client sends		size of the compression residue. For instance, if a client sends
	only CON request, the type can be elided by compression and the		only CON request, the type can be elided by compression and the
	answer may use one single bit to carry either the ACK or RST type.		answer may use one single bit to carry either the ACK or RST type.
	The same behavior can be applied to the CoAP Code field (0.0X code		The same behavior can be applied to the CoAP Code field 0.0X code
	are present in the request and Y.ZZ in the answer). The direction		Format is found in the request and Y.ZZ code format in the answer.
	allows splitting in two parts the possible values for each		The direction allows splitting in two parts the possible values
	direction.		for each direction in the same Rule.
	o In IPv6 and UDP, header fields have a fixed size. In CoAP, Token		o In IPv6 and UDP, header fields have a fixed size and it is not
	size may vary from 0 to 8 bytes, the length being given by a field		sent. In CoAP, some fields in the header have a varying size, for
	in the header. More systematically, the CoAP options are		example the Token size may vary from 0 to 8 bytes, the length is
	described using the Type-Length-Value.		given by a field in the header. More systematically, the CoAP
			options are described using the Type-Length-Value.
	[I-D.ietf-lpwan-ipv6-static-context-hc] offers the possibility to		[I-D.ietf-lpwan-ipv6-static-context-hc] offers the possibility to
	define a function for the Field Length in the Field Description.		define a function for the Field Length in the Field Description.
	o In CoAP headers, a field can appear several times. This is		o In CoAP headers, a field can appear several times. This is
	typical for elements of a URI (path or queries).		typical for elements of a URI (path or queries). The SCHC
	[I-D.ietf-lpwan-ipv6-static-context-hc] allows a Field ID to		specification [I-D.ietf-lpwan-ipv6-static-context-hc] allows a
	appears several times in the rule, the Field Position (FP)		Field ID to appears several times in the rule, and uses the Field
	identifies the proper instance, thereby removing the ambiguity of		Position (FP) to identify the correct instance, and thereby
	the matching operation.		removing the ambiguity of the matching operation.
	o Field sizes defined in the CoAP protocol can be too large		o Field sizes defined in the CoAP protocol can be too large
	regarding LPWAN traffic constraints. This is particularly true		regarding LPWAN traffic constraints. This is particularly true
	for the message ID field or Token field. The MSB MO can be used		for the Message ID field and the Token field. The MSB MO can be
	to reduce the information carried on LPWANs.		applied to reduce the information carried on LPWANs.
	o CoAP also obeys the client/server paradigm and the compression		o CoAP also obeys the client/server paradigm and the compression
	ratio can be different if the request is issued from an LPWAN		ratio can be different if the request is issued from an LPWAN
	device or from a non LPWAN device. For instance a Device (Dev)		device or from a non LPWAN device. For instance, a Device (Dev)
	aware of LPWAN constraints can generate a 1 byte token, but a		aware of LPWAN constraints can generate a 1-byte token, but a
	regular CoAP client will certainly send a larger token to the Dev.		regular CoAP client will certainly send a larger token to the Dev.
	The SCHC compression-decompression process does not modify the		The SCHC compression-decompression process never modifies the
	values. Nevertheless, a proxy placed before the compressor may		Values it only reduces their sizes. Nevertheless, a proxy placed
	change some field values to allow SCHC achieving a better		before the compressor may change some field values to allow SCHC
	compression ratio, while maintaining the necessary context for		achieving a better compression ratio, while maintaining the
	interoperability with existing CoAP implementations.		necessary context for interoperability with existing CoAP
			implementations.
	4. Compression of CoAP header fields		4. Compression of CoAP header fields
	This section discusses the compression of the different CoAP header		This section discusses the compression of the different CoAP header
	fields.		fields.
	4.1. CoAP version field		4.1. CoAP version field
	This field is bidirectional and MUST be elided during the SCHC		CoAP version is bidirectional and MUST be elided during the SCHC
	compression, since it always contains the same value. In the future,		compression, since it always contains the same value. In the future,
	if new versions of CoAP are defined, new rules will be defined to		if new versions of CoAP are defined, new rules will be needed to
	avoid ambiguities between versions.		avoid ambiguities between versions.
	4.2. CoAP type field		4.2. CoAP type field
	[rfc7252] defines 4 types of messages: CON, NON, ACK and RST. The		CoAP Protocol [rfc7252] defines 4 types of messages: CON, NON, ACK
	last two are a response to the first two. If the device plays a		and RST. ACK and RST are a response to the CON and NON. If the
	specific client or server role, a rule can exploit these properties		device plays a specific client or server role, a rule can take
	with the mapping list: [CON, NON] for one direction and [ACK, RST]		advantage of these properties with the mapping list: [CON, NON] for
	for the other direction. The compression residue is reduced to 1		one direction and [ACK, RST] for the other direction and so, the
	bit.		compression residue is reduced to 1 bit.
	The field SHOULD be elided if for instance a client is sending only		The field SHOULD be elided if for instance a client is sending only
	NON or only CON messages.		NON or only CON messages.
	In any case, a rule MUST be defined to carry RST to a client.		In any case, a rule MUST be defined to carry RST to a client.
	4.3. CoAP code field		4.3. CoAP code field
	The compression of the CoAP code field follows the same principle as		The compression of the CoAP code field follows the same principle as
	that of the CoAP type field. If the device plays a specific role,		that of the CoAP type field. If the device plays a specific role,
	the set of code values can be split in two parts, the request codes		the set of code values can be split in two parts, the request codes
	with the 0 class and the response values.		with the 0 class and the response values.
	If the device only implements a CoAP client, the request code can be		If the device only implements a CoAP client, the request code can be
	reduced to the set of requests the client is able to process.		reduced to the set of requests the client is able to process.
	All the response codes MUST be compressed with a SCHC rule.		All the response codes MUST be compressed with a SCHC rule.
	4.4. CoAP Message ID field		4.4. CoAP Message ID field
	This field is bidirectional and is used to manage acknowledgments.		The Message ID field is bidirectional and is used to manage
	The server memorizes the value for a EXCHANGE_LIFETIME period (by		acknowledgments. The server memorizes the value for an
	default 247 seconds) for CON messages and a NON_LIFETIME period (by		EXCHANGE_LIFETIME period (by default 247 seconds) for CON messages
	default 145 seconds) for NON messages. During that period, a server		and a NON_LIFETIME period (by default 145 seconds) for NON messages.
	receiving the same Message ID value will process the message as a		During that period, a server receiving the same Message ID value will
	retransmission. After this period, it will be processed as a new		process the message as a retransmission. After this period, it will
	message.		be processed as a new message.
	In case the Device is a client, the size of the message ID field may		In case where the Device is a client, the size of the Message ID
	be too large regarding the number of messages sent. The client		field may be too large regarding the number of messages sent. The
	SHOULD use only small message ID values, for instance 4 bit long.		client SHOULD use only small Message ID values, for instance 4 bit
	Therefore, a MSB can be used to limit the size of the compression		long. Therefore, an MSB can be used to limit the size of the
	residue.		compression residue.
	In case the Device is a server, the client may be located outside of		In case where the Device is a server, the client may be located
	the LPWAN area and view the Device as a regular device connected to		outside of the LPWAN area and it views the Device as a regular device
	the internet. The client will generate Message ID using the 16 bits		connected to the Internet. The client will generate Message ID using
	space offered by this field. A CoAP proxy can be set before the SCHC		the 16 bits space offered by this field. A CoAP proxy can be set
	C/D to reduce the value of the Message ID, to allow its compression		before the SCHC C/D to reduce the value of the Message ID, to allow
	with the MSB matching operator and LSB CDA.		its compression with the MSB matching operator and LSB CDA.
	4.5. CoAP Token fields		4.5. CoAP Token fields
	Token is defined through two CoAP fields, Token Length in the		Token is defined through two CoAP fields, Token Length in the
	mandatory header and Token Value directly following the mandatory		mandatory header and Token Value directly following the mandatory
	CoAP header.		CoAP header.
	Token Length is processed as any protocol field. If the value		Token Length is processed as any protocol field. If the value
	remains the same during all the transaction, the size can be stored		remains the same during all the transaction, the size can be stored
	in the context and elided during the transmission. Otherwise, it		in the context and elided during the transmission. Otherwise, it
	will have to the sent as a compression residue.		will have to be sent as a compression residue.
	Token Value size cannot be defined directly in the rule in the Field		Token Value size cannot be defined directly in the rule in the Field
	Length (FL). Instead, a specific function designated as "TKL" MUST		Length (FL). Instead, a specific function designated as "TKL" MUST
	be used and length does not have to the sent with the residue.		be used and length does not have to be sent with the residue. During
	During the decompression, this function returns the value contained		the decompression, this function returns the value contained in the
	in the Token Length field.		Token Length field.
	5. CoAP options		5. CoAP options
	5.1. CoAP Content and Accept options.		5.1. CoAP Content and Accept options.
	These fields are both unidirectional and MUST NOT be set to		These fields are both unidirectional and MUST NOT be set to
	bidirectional in a rule entry.		bidirectional in a rule entry.
	If a single value is expected by the client, it can be stored in the		If a single value is expected by the client, it can be stored in the
	TV and elided during the transmission. Otherwise, if several		TV and elided during the transmission. Otherwise, if several
	possible values are expected by the client, a matching-list SHOULD be		possible values are expected by the client, a matching-list SHOULD be
	used to limit the size of the residue. If is not possible, the value		used to limit the size of the residue. Otherwise, the value has to
	has to be sent as a residue (fixed or variable length).		be sent as a residue (fixed or variable length).
	5.2. CoAP option Max-Age, Uri-Host and Uri-Port fields		5.2. CoAP option Max-Age, Uri-Host and Uri-Port fields
	These fields are unidirectional and MUST NOT be set to bidirectional		These fields are unidirectional and MUST NOT be set to bidirectional
	in a rule entry. They are used only by the server to inform of the		in a rule entry. They are used only by the server to inform of the
	caching duration and is never found in client requests.		caching duration and is never found in client requests.
	If the duration is known by both ends, the value can be elided on the		If the duration is known by both ends, the value can be elided on the
	LPWAN.		LPWAN.
	skipping to change at page 10, line 7 ¶		skipping to change at page 10, line 15 ¶
	6. Other RFCs		6. Other RFCs
	6.1. Block		6.1. Block
	Block [rfc7959] allows a fragmentation at the CoAP level. SCHC also		Block [rfc7959] allows a fragmentation at the CoAP level. SCHC also
	includes a fragmentation protocol. They are compatible. If a block		includes a fragmentation protocol. They are compatible. If a block
	option is used, its content MUST be sent as a compression residue.		option is used, its content MUST be sent as a compression residue.
	6.2. Observe		6.2. Observe
	[rfc7641] defines the Observe option. The TV is not set, MO is set		The [rfc7641] defines the Observe option. The TV is not set, MO is
	to "ignore" and the CDA is set to "value-sent". SCHC does not limit		set to "ignore" and the CDA is set to "value-sent". SCHC does not
	the maximum size for this option (3 bytes). To reduce the		limit the maximum size for this option (3 bytes). To reduce the
	transmission size, either the device implementation MAY limit the		transmission size, either the device implementation MAY limit the
	delta between two consecutive values, or a proxy can modify the		delta between two consecutive values, or a proxy can modify the
	increment.		increment.
	Since an RST message may be sent to inform a server that the client		Since an RST message may be sent to inform a server that the client
	does not require Observe response, a rule MUST allow the transmission		does not require Observe response, a rule MUST allow the transmission
	of this message.		of this message.
	6.3. No-Response		6.3. No-Response
	[rfc7967] defines a No-Response option limiting the responses made by		The [rfc7967] defines a No-Response option limiting the responses
	a server to a request. If the value is known by both ends, then TV		made by a server to a request. If the value is known by both ends,
	is set to this value, MO is set to "equal" and CDA is set to "not-		then TV is set to this value, MO is set to "equal" and CDA is set to
	sent".		"not-sent".
	Otherwise, if the value is changing over time, TV is not set, MO is		Otherwise, if the value is changing over time, TV is not set, MO is
	set to "ignore" and CDA to "value-sent". A matching list can also be		set to "ignore" and CDA to "value-sent". A matching list can also be
	used to reduce the size.		used to reduce the size.
	6.4. OSCORE		6.4. OSCORE
	OSCORE [I-D.ietf-core-object-security] defines end-to-end protection		OSCORE [rfc8613] defines end-to-end protection for CoAP messages.
	for CoAP messages. This section describes how SCHC rules can be		This section describes how SCHC rules can be applied to compress
	applied to compress OSCORE-protected messages.		OSCORE-protected messages.
	0 1 2 3 4 5 6 7 <--------- n bytes ------------->		0 1 2 3 4 5 6 7 <--------- n bytes ------------->
	+-+-+-+-+-+-+-+-+---------------------------------		+-+-+-+-+-+-+-+-+---------------------------------
	|0 0 0|h|k| n | Partial IV (if any) ...		|0 0 0|h|k| n | Partial IV (if any) ...
	+-+-+-+-+-+-+-+-+---------------------------------		+-+-+-+-+-+-+-+-+---------------------------------
	| | |		| | |
	|<-- CoAP -->|<------ CoAP OSCORE_piv ------> |		|<-- CoAP -->|<------ CoAP OSCORE_piv ------> |
	OSCORE_flags		OSCORE_flags
	<- 1 byte -> <------ s bytes ----->		<- 1 byte -> <------ s bytes ----->
	+------------+----------------------+-----------------------+		+------------+----------------------+-----------------------+
	| s (if any) | kid context (if any) | kid (if any) ... |		| s (if any) | kid context (if any) | kid (if any) ... |
	+------------+----------------------+-----------------------+		+------------+----------------------+-----------------------+
	| | |		| | |
	| <------ CoAP OSCORE_kidctxt ----->|<-- CoAP OSCORE_kid -->|		| <------ CoAP OSCORE_kidctxt ----->|<-- CoAP OSCORE_kid -->|
	Figure 4: OSCORE Option		Figure 4: OSCORE Option
	The encoding of the OSCORE Option Value defined in Section 6.1 of		The encoding of the OSCORE Option Value defined in Section 6.1 of
	[I-D.ietf-core-object-security] is repeated in Figure 4.		[rfc8613] is repeated in Figure 4.
	The first byte is used for flags that specify the contents of the		The first byte is used for flags that specify the contents of the
	OSCORE option. The 3 most significant bits are reserved and always		OSCORE option. The 3 most significant bits of this byte are reserved
	set to 0. Bit h, when set, indicates the presence of the kid context		and always set to 0. Bit h, when set, indicates the presence of the
	field in the option. Bit k, when set, indicates the presence of a		kid context field in the option. Bit k, when set, indicates the
	kid field. The 3 least significant bits n indicate the length of the		presence of a kid field. The 3 least significant bits n indicate the
	piv field in bytes. When n = 0, no piv is present.		length of the piv (Partial Initialization Vector) field in bytes.
			When n = 0, no piv is present.
	After the flag byte follow the piv field, kid context field and kid		The flag byte is followed by the piv field, kid context field and kid
	field in order and if present; the length of the kid context field is		field in this order and if present; the length of the kid context
	encoded in the first byte denoting by s the length of the kid context		field is encoded in the first byte denoting by s the length of the
	in bytes.		kid context in bytes.
	This draft recommends to implement a parser that is able to identify		This draft recommends to implement a parser that is able to identify
	the OSCORE Option and the fields it contains.		the OSCORE Option and the fields it contains.
	Conceptually, it discerns up to 4 distinct pieces of information		Conceptually, it discerns up to 4 distinct pieces of information
	within the OSCORE option: the flag bits, the piv, the kid context,		within the OSCORE option: the flag bits, the piv, the kid context,
	and the kid. It is thus recommended that the parser split the OSCORE		and the kid. It is thus recommended that the parser split the OSCORE
	option into the 4 subsequent fields:		option into the 4 subsequent fields:
	o CoAP OSCORE_flags,		o CoAP OSCORE_flags,
	skipping to change at page 11, line 33 ¶		skipping to change at page 12, line 4 ¶
	Conceptually, it discerns up to 4 distinct pieces of information		Conceptually, it discerns up to 4 distinct pieces of information
	within the OSCORE option: the flag bits, the piv, the kid context,		within the OSCORE option: the flag bits, the piv, the kid context,
	and the kid. It is thus recommended that the parser split the OSCORE		and the kid. It is thus recommended that the parser split the OSCORE
	option into the 4 subsequent fields:		option into the 4 subsequent fields:
	o CoAP OSCORE_flags,		o CoAP OSCORE_flags,
	o CoAP OSCORE_piv,		o CoAP OSCORE_piv,
	o CoAP OSCORE_kidctxt,		o CoAP OSCORE_kidctxt,
	o CoAP OSCORE_kid.		o CoAP OSCORE_kid.
	These fields are shown superimposed on the OSCORE Option format in		These fields are shown superimposed on the OSCORE Option format in
	Figure 4, the CoAP OSCORE_kidctxt field including the size bits s.		Figure 4, the CoAP OSCORE_kidctxt field including the size bits s.
	Their size SHOULD be reduced using SCHC compression.		Their size SHOULD be reduced using SCHC compression.
	7. Examples of CoAP header compression		7. Examples of CoAP header compression
	7.1. Mandatory header with CON message		7.1. Mandatory header with CON message
	In this first scenario, the LPWAN compressor at the Network Gateway		In this first scenario, the LPWAN compressor at the Network Gateway
	side receives from a client on the Internet a POST message, which is		side receives from an Internet client a POST message, which is
	immediately acknowledged by the Device. For this simple scenario,		immediately acknowledged by the Device. For this simple scenario,
	the rules are described Figure 5.		the rules are described Figure 5.
	Rule ID 1		Rule ID 1
	+-------------+--+--+--+------+---------+-------------++------------+		+-------------+--+--+--+------+---------+-------------++------------+
	| Field |FL|FP|DI|Target| Match | CDA || Sent |		| Field |FL|FP|DI|Target| Match | CDA || Sent |
	| | | | |Value | Opera. | || [bits] |		| | | | |Value | Opera. | || [bits] |
	+-------------+--+--+--+------+---------+-------------++------------+		+-------------+--+--+--+------+---------+-------------++------------+
	|CoAP version | | |bi| 01 |equal |not-sent || |		|CoAP version | | |bi| 01 |equal |not-sent || |
	|CoAP Type | | |dw| CON |equal |not-sent || |		|CoAP Type | | |dw| CON |equal |not-sent || |
	skipping to change at page 12, line 33 ¶		skipping to change at page 12, line 47 ¶
	The version and Token Length fields are elided. The 26 method and		The version and Token Length fields are elided. The 26 method and
	response codes defined in [rfc7252] has been shrunk to 5 bits using a		response codes defined in [rfc7252] has been shrunk to 5 bits using a
	matching list. Uri-Path contains a single element indicated in the		matching list. Uri-Path contains a single element indicated in the
	matching operator.		matching operator.
	SCHC Compression reduces the header sending only the Type, a mapped		SCHC Compression reduces the header sending only the Type, a mapped
	code and the least significant bits of Message ID (9 bits in the		code and the least significant bits of Message ID (9 bits in the
	example above).		example above).
	Note that a request sent by a client located an Application Server to		Note that a request sent by a client located in an Application Server
	a server in the device, may not be compressed through this rule since		to a server located in the device, may not be compressed through this
	the MID will not start with 7 bits equal to 0. A CoAP proxy, before		rule since the MID will not start with 7 bits equal to 0. A CoAP
	the core SCHC C/D can rewrite the message ID to a value matched by		proxy, before the core SCHC C/D can rewrite the message ID to a value
	the rule.		matched by the rule.
	7.2. OSCORE Compression		7.2. OSCORE Compression
	OSCORE aims to solve the problem of end-to-end encryption for CoAP		OSCORE aims to solve the problem of end-to-end encryption for CoAP
	messages. The goal, therefore, is to hide as much of the message as		messages. The goal, therefore, is to hide as much of the message as
	possible while still enabling proxy operation.		possible while still enabling proxy operation.
	Conceptually this is achieved by splitting the CoAP message into an		Conceptually this is achieved by splitting the CoAP message into an
	Inner Plaintext and Outer OSCORE Message. The Inner Plaintext		Inner Plaintext and Outer OSCORE Message. The Inner Plaintext
	contains sensible information which is not necessary for proxy		contains sensible information which is not necessary for proxy
	skipping to change at page 13, line 19 ¶		skipping to change at page 13, line 34 ¶
	o Class E: Encrypted options moved to the Inner Plaintext,		o Class E: Encrypted options moved to the Inner Plaintext,
	o Class I: Integrity-protected options included in the AAD for the		o Class I: Integrity-protected options included in the AAD for the
	encryption of the Plaintext but otherwise left untouched in the		encryption of the Plaintext but otherwise left untouched in the
	Outer Message,		Outer Message,
	o Class U: Unprotected options left untouched in the Outer Message.		o Class U: Unprotected options left untouched in the Outer Message.
	Additionally, the OSCORE Option is added as an Outer option,		Additionally, the OSCORE Option is added as an Outer option,
	signaling that the message is OSCORE protected. This option carries		signalling that the message is OSCORE protected. This option carries
	the information necessary to retrieve the Security Context with which		the information necessary to retrieve the Security Context with which
	the message was encrypted so that it may be correctly decrypted at		the message was encrypted so that it may be correctly decrypted at
	the other end-point.		the other end-point.
	Original CoAP Message		Original CoAP Message
	+-+-+---+-------+---------------+		+-+-+---+-------+---------------+
	|v|t|tkl| code | Msg Id. |		|v|t|tkl| code | Msg Id. |
	+-+-+---+-------+---------------+....+		+-+-+---+-------+---------------+....+
	| Token |		| Token |
	+-------------------------------.....+		+-------------------------------.....+
	skipping to change at page 14, line 44 ¶		skipping to change at page 14, line 44 ¶
	+------+-------------------+ | Payload |		+------+-------------------+ | Payload |
	| 0xFF | | |		| 0xFF | | |
	+------+ +-------------------+		+------+ +-------------------+
	Figure 6: A CoAP message is split into an OSCORE outer and plaintext		Figure 6: A CoAP message is split into an OSCORE outer and plaintext
	Figure 6 shows the message format for the OSCORE Message and		Figure 6 shows the message format for the OSCORE Message and
	Plaintext.		Plaintext.
	In the Outer Header, the original message code is hidden and replaced		In the Outer Header, the original message code is hidden and replaced
	by a default dummy value. As seen in sections 4.1.3.5 and 4.2 of		by a default dummy value. As seen in sections 4.1.3.5 and 4.2 of the
	[I-D.ietf-core-object-security], the message code is replaced by POST		[rfc8613], the message code is replaced by POST for requests and
	for requests and Changed for responses when Observe is not used. If		Changed for responses when Observe is not used. If Observe is used,
	Observe is used, the message code is replaced by FETCH for requests		the message code is replaced by FETCH for requests and Content for
	and Content for responses.		responses.
	The original message code is put into the first byte of the		The original message code is put into the first byte of the
	Plaintext. Following the message code, the class E options comes and		Plaintext. Following the message code, the class E options comes and
	if present the original message Payload is preceded by its payload		if present the original message Payload is preceded by its payload
	marker.		marker.
	The Plaintext is now encrypted by an AEAD algorithm which integrity		The Plaintext is now encrypted by an AEAD algorithm which integrity
	protects Security Context parameters and eventually any class I		protects Security Context parameters and eventually any class I
	options from the Outer Header. Currently no CoAP options are marked		options from the Outer Header. Currently no CoAP options are marked
	class I. The resulting Ciphertext becomes the new Payload of the		class I. The resulting Ciphertext becomes the new Payload of the
	skipping to change at page 18, line 6 ¶		skipping to change at page 18, line 6 ¶
	0xFF Payload marker		0xFF Payload marker
	Payload:		Payload:
	0x32332043		0x32332043
	Original msg length: 10		Original msg length: 10
	Figure 10: CoAP CONTENT Response		Figure 10: CoAP CONTENT Response
	The SCHC Rules for the Inner Compression include all fields that are		The SCHC Rules for the Inner Compression include all fields that are
	already present in a regular CoAP message, what is important is the		already present in a regular CoAP message, what is important is their
	order of appearance and inclusion of only those CoAP fields that go		order and the definition of only those CoAP fields are into
	into the Plaintext, Figure 11.		Plaintext, Figure 11.
	Rule ID 0		Rule ID 0
	+---------------+--+--+-----------+-----------+-----------++------+		+---------------+--+--+-----------+-----------+-----------++------+
	| Field |FP|DI| Target | MO | CDA || Sent |		| Field |FP|DI| Target | MO | CDA || Sent |
	| | | | Value | | ||[bits]|		| | | | Value | | ||[bits]|
	+---------------+--+--+-----------+-----------+-----------++------+		+---------------+--+--+-----------+-----------+-----------++------+
	|CoAP Code | |up| 1 | equal |not-sent || |		|CoAP Code | |up| 1 | equal |not-sent || |
	|CoAP Code | |dw|[69,132] | match-map |match-sent || c |		|CoAP Code | |dw|[69,132] | match-map |match-sent || c |
	|CoAP Uri-Path | |up|temperature| equal |not-sent || |		|CoAP Uri-Path | |up|temperature| equal |not-sent || |
	|COAP Option-End| |dw| 0xFF | equal |not-sent || |		|COAP Option-End| |dw| 0xFF | equal |not-sent || |
	skipping to change at page 21, line 8 ¶		skipping to change at page 21, line 8 ¶
	| tag = 0xe9aef3f2461e0c29 (8 bytes) |		| tag = 0xe9aef3f2461e0c29 (8 bytes) |
	| |		| |
	| ciphertext = 0x10c6d7c26cc1e9aef3f2461e0c29 (14 bytes) |		| ciphertext = 0x10c6d7c26cc1e9aef3f2461e0c29 (14 bytes) |
	|_________________________________________________________|		|_________________________________________________________|
	Figure 13: Plaintext compression and encryption for CONTENT Response		Figure 13: Plaintext compression and encryption for CONTENT Response
	The Outer SCHC Rules (Figure 16) MUST process the OSCORE Options		The Outer SCHC Rules (Figure 16) MUST process the OSCORE Options
	fields. In Figure 14 and Figure 15 we show a dump of the OSCORE		fields. In Figure 14 and Figure 15 we show a dump of the OSCORE
	Messages generated from our example messages once they have been		Messages generated from our example messages once they have been
	provided with the Inner Compressed Ciphertext in the payload. These		provided with the Inner Compressed Ciphertext in the payload. These
	are the messages that are to go through Outer SCHC Compression.		are the messages that have to be compressed by the Outer SCHC
			Compression.
	Protected message:		Protected message:
	==================		==================
	0x4102000182d7080904636c69656e74ffa2c54fe1b434297b62		0x4102000182d7080904636c69656e74ffa2c54fe1b434297b62
	(25 bytes)		(25 bytes)
	Header:		Header:
	0x4102		0x4102
	01 Ver		01 Ver
	00 CON		00 CON
	skipping to change at page 22, line 31 ¶		skipping to change at page 22, line 31 ¶
	0xd008 (2 bytes)		0xd008 (2 bytes)
	Option 21: OBJECT_SECURITY		Option 21: OBJECT_SECURITY
	Value = b''		Value = b''
	0xFF Payload marker		0xFF Payload marker
	Payload:		Payload:
	0x10c6d7c26cc1e9aef3f2461e0c29 (14 bytes)		0x10c6d7c26cc1e9aef3f2461e0c29 (14 bytes)
	Figure 15: Protected and Inner SCHC Compressed CONTENT Response		Figure 15: Protected and Inner SCHC Compressed CONTENT Response
	For the flag bits, a number of compression methods could prove to be		For the flag bits, a number of compression methods has been shown to
	useful depending on the application. The simplest alternative is to		be useful depending on the application. The simplest alternative is
	provide a fixed value for the flags, combining MO equal and CDA not-		to provide a fixed value for the flags, combining MO equal and CDA
	sent. This saves most bits but could hinder flexibility. Otherwise,		not- sent. This saves most bits but could prevent flexibility.
	match-mapping could allow to choose from a number of configurations		Otherwise, match-mapping could be used to choose from an interested
	of interest to the exchange. If neither of these alternatives is		number of configurations to the exchange. Otherwise, MSB could be
	desirable, MSB could be used to mask off the 3 hard-coded most		used to mask off the 3 hard-coded most significant bits.
	significant bits.
	Note that fixing a flag bit will limit the choice of CoAP Options		Note that fixing a flag bit will limit the choice of CoAP Options
	that can be used in the exchange, since their values are dependent on		that can be used in the exchange, since their values are dependent on
	certain options.		certain options.
	The piv field lends itself to having a number of bits masked off with		The piv field lends itself to having a number of bits masked off with
	MO MSB and CDA LSB. This could prove useful in applications where		MO MSB and CDA LSB. This could be useful in applications where the
	the message frequency is low such as that found in LPWAN		message frequency is low such as that found in LPWAN technologies.
	technologies. Note that compressing the sequence numbers effectively		Note that compressing the sequence numbers effectively reduces the
	reduces the maximum amount of sequence numbers that can be used in an		maximum amount of sequence numbers that can be used in an exchange.
	exchange. Once this amount is exceeded, the SCHC Context would need		Once this amount is exceeded, the SCHC Context would need to be re-
	to be re-established.		established.
	The size s included in the kid context field MAY be masked off with		The size s included in the kid context field MAY be masked off with
	CDA MSB. The rest of the field could have additional bits masked		CDA MSB. The rest of the field could have additional bits masked
	off, or have the whole field be fixed with MO equal and CDA not-sent.		off, or have the whole field be fixed with MO equal and CDA not-sent.
	The same holds for the kid field.		The same holds for the kid field.
	Figure 16 shows a possible set of Outer Rules to compress the Outer		Figure 16 shows a possible set of Outer Rules to compress the Outer
	Header.		Header.
	Rule ID 0		Rule ID 0
	skipping to change at page 26, line 40 ¶		skipping to change at page 26, line 40 ¶
	ones already raised on [I-D.ietf-lpwan-ipv6-static-context-hc]		ones already raised on [I-D.ietf-lpwan-ipv6-static-context-hc]
	10. Acknowledgements		10. Acknowledgements
	The authors would like to thank Dominique Barthel, Carsten Bormann,		The authors would like to thank Dominique Barthel, Carsten Bormann,
	Thomas Fossati, Klaus Hartke, Francesca Palombini, Alexander Pelov,		Thomas Fossati, Klaus Hartke, Francesca Palombini, Alexander Pelov,
	Goran Selander.		Goran Selander.
	11. Normative References		11. Normative References
	[I-D.ietf-core-object-security]
	Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
	"Object Security for Constrained RESTful Environments
	(OSCORE)", draft-ietf-core-object-security-16 (work in
	progress), March 2019.
	[I-D.ietf-lpwan-ipv6-static-context-hc]		[I-D.ietf-lpwan-ipv6-static-context-hc]
	Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and J.		Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and J.
	Zuniga, "Static Context Header Compression (SCHC) and		Zuniga, "Static Context Header Compression (SCHC) and
	fragmentation for LPWAN, application to UDP/IPv6", draft-		fragmentation for LPWAN, application to UDP/IPv6", draft-
	ietf-lpwan-ipv6-static-context-hc-19 (work in progress),		ietf-lpwan-ipv6-static-context-hc-21 (work in progress),
	July 2019.		July 2019.
	[I-D.toutain-core-time-scale]
	Minaburo, A. and L. Toutain, "CoAP Time Scale Option",
	draft-toutain-core-time-scale-00 (work in progress),
	October 2017.
	[rfc7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained		[rfc7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
	Application Protocol (CoAP)", RFC 7252,		Application Protocol (CoAP)", RFC 7252,
	DOI 10.17487/RFC7252, June 2014,		DOI 10.17487/RFC7252, June 2014,
	<https://www.rfc-editor.org/info/rfc7252>.		<https://www.rfc-editor.org/info/rfc7252>.
	[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>.
	[rfc7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in		[rfc7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in
	the Constrained Application Protocol (CoAP)", RFC 7959,		the Constrained Application Protocol (CoAP)", RFC 7959,
	DOI 10.17487/RFC7959, August 2016,		DOI 10.17487/RFC7959, August 2016,
	<https://www.rfc-editor.org/info/rfc7959>.		<https://www.rfc-editor.org/info/rfc7959>.
	[rfc7967] Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T.		[rfc7967] Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T.
	Bose, "Constrained Application Protocol (CoAP) Option for		Bose, "Constrained Application Protocol (CoAP) Option for
	No Server Response", RFC 7967, DOI 10.17487/RFC7967,		No Server Response", RFC 7967, DOI 10.17487/RFC7967,
	August 2016, <https://www.rfc-editor.org/info/rfc7967>.		August 2016, <https://www.rfc-editor.org/info/rfc7967>.
			[rfc8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
			"Object Security for Constrained RESTful Environments
			(OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
			<https://www.rfc-editor.org/info/rfc8613>.
	Authors' Addresses		Authors' Addresses
	Ana Minaburo		Ana Minaburo
	Acklio		Acklio
	1137A avenue des Champs Blancs		1137A avenue des Champs Blancs
	35510 Cesson-Sevigne Cedex		35510 Cesson-Sevigne Cedex
	France		France
	Email: ana@ackl.io		Email: ana@ackl.io
	Laurent Toutain		Laurent Toutain
	Institut MINES TELECOM; IMT Atlantique		Institut MINES TELECOM; IMT Atlantique
	2 rue de la Chataigneraie		2 rue de la Chataigneraie
	CS 17607		CS 17607
	35576 Cesson-Sevigne Cedex		35576 Cesson-Sevigne Cedex
	France		France
	Email: Laurent.Toutain@imt-atlantique.fr		Email: Laurent.Toutain@imt-atlantique.fr
	Ricardo Andreasen		Ricardo Andreasen
End of changes. 50 change blocks.
	154 lines changed or deleted		151 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/