< draft-ietf-lpwan-coap-static-context-hc-05.txt		draft-ietf-lpwan-coap-static-context-hc-06.txt >
	lpwan Working Group A. Minaburo		lpwan Working Group A. Minaburo
	Internet-Draft Acklio		Internet-Draft Acklio
	Intended status: Informational L. Toutain		Intended status: Informational L. Toutain
	Expires: April 25, 2019 Institut MINES TELECOM; IMT Atlantique		Expires: August 9, 2019 Institut MINES TELECOM; IMT Atlantique
	R. Andreasen		R. Andreasen
	Universidad de Buenos Aires		Universidad de Buenos Aires
	October 22, 2018		February 05, 2019
	LPWAN Static Context Header Compression (SCHC) for CoAP		LPWAN Static Context Header Compression (SCHC) for CoAP
	draft-ietf-lpwan-coap-static-context-hc-05		draft-ietf-lpwan-coap-static-context-hc-06
	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. CoAP header structure differs from IPv6 and UDP		CoAP headers. The CoAP header structure differs from IPv6 and UDP
	protocols since the CoAP		protocols since CoAP
	use a flexible header with a variable number of options themselves of		use a flexible header with a variable number of options themselves of
	a variable length. Another important difference is the asymmetry in		a variable length. The CoAP protocol is asymmetric in its format
	the header format used in request and response messages. Most of the		messages, the format of the header packet in the request messages is
	compression mechanisms have been introduced in		different than in the response messages. Most of the compression
			mechanisms have been introduced in
	[I-D.ietf-lpwan-ipv6-static-context-hc], this document explains how		[I-D.ietf-lpwan-ipv6-static-context-hc], this document explains how
	to use the SCHC compression 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 April 25, 2019.		This Internet-Draft will expire on August 9, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	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 . . . . . . . . . . . . . . 5		4. Compression of CoAP header fields . . . . . . . . . . . . . . 6
	4.1. CoAP version field . . . . . . . . . . . . . . . . . . . 5		4.1. CoAP version field . . . . . . . . . . . . . . . . . . . 6
	4.2. CoAP type field . . . . . . . . . . . . . . . . . . . . . 5		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 . . . . . . . . . . . . . . . . . . . . 6		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 field, CoAP option Uri-Host and Uri-		5.2. CoAP option Max-Age field, CoAP option Uri-Host and Uri-
	Port fields . . . . . . . . . . . . . . . . . . . . . . . 7		Port fields . . . . . . . . . . . . . . . . . . . . . . . 7
	5.3. CoAP option Uri-Path and Uri-Query fields . . . . . . . . 7		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 . . . . . . 8		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 . . . . . . . . . . . . . . . . . . . . . . . . . 9
	6.1. Block . . . . . . . . . . . . . . . . . . . . . . . . . . 9		6.1. Block . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	6.2. Observe . . . . . . . . . . . . . . . . . . . . . . . . . 9		6.2. Observe . . . . . . . . . . . . . . . . . . . . . . . . . 10
	6.3. No-Response . . . . . . . . . . . . . . . . . . . . . . . 9		6.3. No-Response . . . . . . . . . . . . . . . . . . . . . . . 10
	6.4. Time Scale . . . . . . . . . . . . . . . . . . . . . . . 10		6.4. Time Scale . . . . . . . . . . . . . . . . . . . . . . . 10
	6.5. OSCORE . . . . . . . . . . . . . . . . . . . . . . . . . 10		6.5. 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 . . . . . . . . . . . . . . . . . . . 13		7.2. OSCORE Compression . . . . . . . . . . . . . . . . . . . 13
	7.3. Example OSCORE Compression . . . . . . . . . . . . . . . 17		7.3. Example OSCORE Compression . . . . . . . . . . . . . . . 17
	8. Normative References . . . . . . . . . . . . . . . . . . . . 27		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27		9. Security considerations . . . . . . . . . . . . . . . . . . . 27
			10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27
			11. Normative References . . . . . . . . . . . . . . . . . . . . 27
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
	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. Nevertheless, if limited, the size of a CoAP		constrained devices. Nevertheless, if limited, the size of a CoAP
	header may be too large for LPWAN constraints and some compression		header may be too large for LPWAN constraints and some compression
	may be needed to reduce the header size.		may be 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
	skipping to change at page 12, line 7 ¶		skipping to change at page 12, line 19 ¶
	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 receives from outside		In this first scenario, the LPWAN compressor receives from outside
	client a POST message, which is immediately acknowledged by the		client a POST message, which is immediately acknowledged by the
	Device. For this simple scenario, the rules are described Figure 5.		Device. For this simple scenario, 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 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 || |
	|CoAP Type | | |up|[ACK, | | || |		|CoAP Type | | |up|[ACK, | | || |
	| | | | | RST] |match-map|matching-sent|| T |		| | | | | RST] |match-map|matching-sent|| T |
	|CoAP TKL | | |bi| 0 |equal |not-sent || |		|CoAP TKL | | |bi| 0 |equal |not-sent || |
	|CoAP Code | | |bi| ML1 |match-map|matching-sent|| CC CCC |		|CoAP Code | | |bi| ML1 |match-map|matching-sent|| CC CCC |
	|CoAP MID | | |bi| 0000 |MSB(7 ) |LSB(9) || M-ID|		|CoAP MID | | |bi| 0000 |MSB(7 ) |LSB(9) || M-ID|
	|CoAP Uri-Path| | |dw| path |equal 1 |not-sent || |		|CoAP Uri-Path| | |dw| path |equal 1 |not-sent || |
	+-------------+--+--+--+------+---------+-------------++------------+		+-------------+--+--+--+------+---------+-------------++------------+
	Figure 5: CoAP Context to compress header without token		Figure 5: CoAP Context to compress header without token
	skipping to change at page 18, line 32 ¶		skipping to change at page 18, line 32 ¶
	Original msg length: 10		Original msg length: 10
	Figure 11: CoAP CONTENT Response		Figure 11: 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 the
	order of appearance and inclusion of only those CoAP fields that go		order of appearance and inclusion of only those CoAP fields that go
	into the Plaintext, Figure 12.		into the Plaintext, Figure 12.
	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 || |
	+----------------+--+--+-----------+-----------+-----------++--------+		+---------------+--+--+-----------+-----------+-----------++------+
	Figure 12: Inner SCHC Rules		Figure 12: Inner SCHC Rules
	Figure 13 shows the Plaintext obtained for our example GET Request		Figure 13 shows the Plaintext obtained for our example GET Request
	and follows the process of Inner Compression and Encryption until we		and follows the process of Inner Compression and Encryption until we
	end up with the Payload to be added in the outer OSCORE Message.		end up with the Payload to be added in the outer OSCORE Message.
	In this case the original message has no payload and its resulting		In this case the original message has no payload and its resulting
	Plaintext can be compressed up to only 1 byte (size of the Rule ID).		Plaintext can be compressed up to only 1 byte (size of the Rule ID).
	The AEAD algorithm preserves this length in its first output, but		The AEAD algorithm preserves this length in its first output, but
	skipping to change at page 24, line 13 ¶		skipping to change at page 24, line 13 ¶
	to be re-established.		to be re-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 17 shows a possible set of Outer Rules to compress the Outer		Figure 17 shows a possible set of Outer Rules to compress the Outer
	Header.		Header.
	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 version | |bi| 01 |equal |not-sent || |		|CoAP version | |bi| 01 |equal |not-sent || |
	|CoAP Type | |up| 0 |equal |not-sent || |		|CoAP Type | |up| 0 |equal |not-sent || |
	|CoAP Type | |dw| 2 |equal |not-sent || |		|CoAP Type | |dw| 2 |equal |not-sent || |
	|CoAP TKL | |bi| 1 |equal |not-sent || |		|CoAP TKL | |bi| 1 |equal |not-sent || |
	|CoAP Code | |up| 2 |equal |not-sent || |		|CoAP Code | |up| 2 |equal |not-sent || |
	|CoAP Code | |dw| 68 |equal |not-sent || |		|CoAP Code | |dw| 68 |equal |not-sent || |
	|CoAP MID | |bi| 0000 |MSB(12) |LSB ||MMMM |		|CoAP MID | |bi| 0000 |MSB(12) |LSB ||MMMM |
	|CoAP Token | |bi| 0x80 |MSB(5) |LSB ||TTT |		|CoAP Token | |bi| 0x80 |MSB(5) |LSB ||TTT |
	|CoAP OSCORE_flags | |up| 0x09 |equal |not-sent || |		|CoAP OSCORE_flags | |up| 0x09 |equal |not-sent || |
	|CoAP OSCORE_piv | |up| 0x00 |MSB(4) |LSB ||PPPP |		|CoAP OSCORE_piv | |up| 0x00 |MSB(4) |LSB ||PPPP |
	|COAP OSCORE_kid | |up|0x636c69656e70|MSB(52) |LSB ||KKKK |		|COAP OSCORE_kid | |up|0x636c69656e70|MSB(52) |LSB ||KKKK |
	|COAP OSCORE_kidctxt| |bi| b'' |equal |not-sent || |		|COAP OSCORE_kidctxt| |bi| b'' |equal |not-sent || |
	|CoAP OSCORE_flags | |dw| b'' |equal |not-sent || |		|CoAP OSCORE_flags | |dw| b'' |equal |not-sent || |
	|CoAP OSCORE_piv | |dw| b'' |equal |not-sent || |		|CoAP OSCORE_piv | |dw| b'' |equal |not-sent || |
	|CoAP OSCORE_kid | |dw| b'' |equal |not-sent || |		|CoAP OSCORE_kid | |dw| b'' |equal |not-sent || |
	|COAP Option-End | |dw| 0xFF |equal |not-sent || |		|COAP Option-End | |dw| 0xFF |equal |not-sent || |
	+-------------------+--+--+--------------+---------+-----------++--------+		+-------------------+--+--+--------------+--------+---------++------+
	Figure 17: Outer SCHC Rules		Figure 17: Outer SCHC Rules
	These Outer Rules are applied to the example GET Request and CONTENT		These Outer Rules are applied to the example GET Request and CONTENT
	Response. The resulting messages are shown in Figure 18 and		Response. The resulting messages are shown in Figure 18 and
	Figure 19.		Figure 19.
	Compressed message:		Compressed message:
	==================		==================
	0x001489458a9fc3686852f6c4 (12 bytes)		0x001489458a9fc3686852f6c4 (12 bytes)
	skipping to change at page 26, line 5 ¶		skipping to change at page 26, line 5 ¶
	Compressed msg length: 16 bytes		Compressed msg length: 16 bytes
	Figure 19: SCHC-OSCORE Compressed CONTENT Response		Figure 19: SCHC-OSCORE Compressed CONTENT Response
	For contrast, we compare these results with what would be obtained by		For contrast, we compare these results with what would be obtained by
	SCHC compressing the original CoAP messages without protecting them		SCHC compressing the original CoAP messages without protecting them
	with OSCORE. To do this, we compress the CoAP messages according to		with OSCORE. To do this, we compress the CoAP messages according to
	the SCHC rules in Figure 20.		the SCHC rules in Figure 20.
	Rule ID 1		Rule ID 1
	+---------------+--+--+-----------+---------+-----------++------------+		+---------------+--+--+-----------+---------+-----------++--------+
	| Field |FP|DI| Target | MO | CDA || Sent |		| Field |FP|DI| Target | MO | CDA || Sent |
	| | | | Value | | || [bits] |		| | | | Value | | || [bits] |
	+---------------+--+--+-----------+---------+-----------++------------+		+---------------+--+--+-----------+---------+-----------++--------+
	|CoAP version | |bi| 01 |equal |not-sent || |		|CoAP version | |bi| 01 |equal |not-sent || |
	|CoAP Type | |up| 0 |equal |not-sent || |		|CoAP Type | |up| 0 |equal |not-sent || |
	|CoAP Type | |dw| 2 |equal |not-sent || |		|CoAP Type | |dw| 2 |equal |not-sent || |
	|CoAP TKL | |bi| 1 |equal |not-sent || |		|CoAP TKL | |bi| 1 |equal |not-sent || |
	|CoAP Code | |up| 2 |equal |not-sent || |		|CoAP Code | |up| 2 |equal |not-sent || |
	|CoAP Code | |dw| [69,132] |equal |not-sent || |		|CoAP Code | |dw| [69,132] |equal |not-sent || |
	|CoAP MID | |bi| 0000 |MSB(12) |LSB ||MMMM |		|CoAP MID | |bi| 0000 |MSB(12) |LSB ||MMMM |
	|CoAP Token | |bi| 0x80 |MSB(5) |LSB ||TTT |		|CoAP Token | |bi| 0x80 |MSB(5) |LSB ||TTT |
	|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 || |
	+---------------+--+--+-----------+---------+-----------++------------+		+---------------+--+--+-----------+---------+-----------++--------+
	Figure 20: SCHC-CoAP Rules (No OSCORE)		Figure 20: SCHC-CoAP Rules (No OSCORE)
	This yields the results in Figure 21 for the Request, and Figure 22		This yields the results in Figure 21 for the Request, and Figure 22
	for the Response.		for the Response.
	Compressed message:		Compressed message:
	==================		==================
	0x0114		0x0114
	0x01 = Rule ID		0x01 = Rule ID
	skipping to change at page 27, line 8 ¶		skipping to change at page 27, line 23 ¶
	Payload		Payload
	0x32332043		0x32332043
	Compressed msg length: 6		Compressed msg length: 6
	Figure 22: CoAP CONTENT Compressed without OSCORE		Figure 22: CoAP CONTENT Compressed without OSCORE
	As can be seen, the difference between applying SCHC + OSCORE as		As can be seen, the difference between applying SCHC + OSCORE as
	compared to regular SCHC + COAP is about 10 bytes of cost.		compared to regular SCHC + COAP is about 10 bytes of cost.
	8. Normative References		8. IANA Considerations
			This document has no request to IANA.
			9. Security considerations
			This document does not have any more Security consideration than the
			ones already raised on [I-D.ietf-lpwan-ipv6-static-context-hc]
			10. Acknowledgements
			Thanks to all the persons that have give us feedback
			11. Normative References
	[I-D.ietf-core-object-security]		[I-D.ietf-core-object-security]
	Selander, G., Mattsson, J., Palombini, F., and L. Seitz,		Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
	"Object Security for Constrained RESTful Environments		"Object Security for Constrained RESTful Environments
	(OSCORE)", draft-ietf-core-object-security-15 (work in		(OSCORE)", draft-ietf-core-object-security-15 (work in
	progress), August 2018.		progress), August 2018.
	[I-D.ietf-lpwan-ipv6-static-context-hc]		[I-D.ietf-lpwan-ipv6-static-context-hc]
	Minaburo, A., Toutain, L., Gomez, C., and D. Barthel,		Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and J.
	"LPWAN Static Context Header Compression (SCHC) and		Zuniga, "LPWAN Static Context Header Compression (SCHC)
	fragmentation for IPv6 and UDP", draft-ietf-lpwan-ipv6-		and fragmentation for IPv6 and UDP", draft-ietf-lpwan-
	static-context-hc-16 (work in progress), June 2018.		ipv6-static-context-hc-18 (work in progress), December
			2018.
	[I-D.toutain-core-time-scale]		[I-D.toutain-core-time-scale]
	Minaburo, A. and L. Toutain, "CoAP Time Scale Option",		Minaburo, A. and L. Toutain, "CoAP Time Scale Option",
	draft-toutain-core-time-scale-00 (work in progress),		draft-toutain-core-time-scale-00 (work in progress),
	October 2017.		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>.
End of changes. 22 change blocks.
	78 lines changed or deleted		96 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/