< draft-pelov-lpwan-architecture-01.txt		draft-pelov-lpwan-architecture-02.txt >
	lpwan Working Group A. Pelov		LPWAN Working Group A. Pelov
	Internet-Draft Acklio		Internet-Draft Acklio
	Intended status: Informational P. Thubert		Intended status: Informational P. Thubert
	Expires: October 30, 2021 Cisco Systems		Expires: October 31, 2021 Cisco Systems
	A. Minaburo		A. Minaburo
	Acklio		Acklio
	April 28, 2021		April 29, 2021
	LPWAN Static Context Header Compression (SCHC) Architecture		LPWAN Static Context Header Compression (SCHC) Architecture
	draft-pelov-lpwan-architecture-01		draft-pelov-lpwan-architecture-02
	Abstract		Abstract
	This document defines the LPWAN SCHC architecture.		This document defines the LPWAN SCHC architecture.
	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 October 30, 2021.		This Internet-Draft will expire on October 31, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 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 . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. SCHC Operation . . . . . . . . . . . . . . . . . . . . . . . 4		2. LPWAN Technologies and Profiles . . . . . . . . . . . . . . . 2
	3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5		3. The Static Context Header Compression . . . . . . . . . . . . 3
	4. Global architecture . . . . . . . . . . . . . . . . . . . . . 5		4. SCHC Endpoints . . . . . . . . . . . . . . . . . . . . . . . 3
	5. Data management . . . . . . . . . . . . . . . . . . . . . . . 6		5. SCHC Instances . . . . . . . . . . . . . . . . . . . . . . . 4
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7		6. SCHC Data Model . . . . . . . . . . . . . . . . . . . . . . . 5
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7		7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	7.1. Normative References . . . . . . . . . . . . . . . . . . 7		8. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 7
	7.2. Informative References . . . . . . . . . . . . . . . . . 8		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
			10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
			10.1. Normative References . . . . . . . . . . . . . . . . . . 7
			10.2. Informative References . . . . . . . . . . . . . . . . . 8
			10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
	1. Introduction		1. Introduction
	The IETF LPWAN WG defined the necessary operations to enable IPv6		The IETF LPWAN WG defined the necessary operations to enable IPv6
	over selected Low-Power Wide Area Networking (LPWAN) radio		over selected Low-Power Wide Area Networking (LPWAN) radio
	technologies. [rfc8376] presents an overview of those technologies.		technologies. [rfc8376] presents an overview of those technologies.
	The core product of the working group is the Static Context Header		The Static Context Header Compression (SCHC) [rfc8724] technology is
	Compression (SCHC) [rfc8724] technology.		the core product of the IETF LPWAN working group. [rfc8724] defines a
			generic framework for header compression and fragmentation, based on
	SCHC provides an extreme compression capability based on a state that		a static context that is pre-installed on the SCHC endpoints.
	must match on the compressor and decompressor side. This state if
	formed of an ordered set of Compression/Decompression (C/D) rules.
	The first rule that matches is used to compress, and is indicated
	with the compression residue. Based on the rule identifier (RuleID)
	the decompressor can rebuild the original bitstream based on the
	residue.
	[rfc8724] also provides a Fragmentation/Reassembly (F/R) capability		This document details the constitutive elements of a SCHC-based
	to cope with a constrained Maximum Transmit Unit (MTU) below the IPv6		solution, and how the solution can be deployed. It provides a
	minimum link MTU of 1280 bytes (see section 5 of [rfc8200]), which is		general architecture for a SCHC deployment, positioning the required
	typically the case on an LPWAN network.		specifications, describing the possible deployment types, and
			indicating models whereby the rules can be distributed and installed
			to enable reliable and scalable operations.
	[rfc8724] was defined to compress IPv6 and UDP; but SCHC really is a		2. LPWAN Technologies and Profiles
	generic compression and fragmentation technology. As such, SCHC is
	agnostic to which protocol it compresses and at which layer it is
	operated. The C/D peers may be hosted by different entities for
	different layers, and the F/R operation may also be performed between
	different parties, or different sub-layers in the same stack.
	If a protocol or a layer requires additional capabilities, it is		Because LPWAN technologies [rfc8376] have strict yet distinct
	always possible to document more specifically how to use SCHC in that		constraints, e.g., in terms of maximum frame size, throughput, and/or
	context, or to specify additional behaviours. For instance,		directionality, a SCHC instance must be profiled to adapt to the
	[I-D.ietf-lpwan-coap-static-context-hc] extends the compression to		specific necessities of the technology to which it is applied.
	CoAP [rfc7252] and OSCORE [rfc8613].
	SCHC is also designed to be profiled to adapt to the specific
	necessities of the various LPWAN technologies to which it is applied.
	Appendix D. "SCHC Parameters" of [rfc8724] lists the information		Appendix D. "SCHC Parameters" of [rfc8724] lists the information
	that an LPWAN technology-specific document must provide to profile		that an LPWAN technology-specific document must provide to profile
	SCHC for that technology. As an example, [rfc9011] provides the		SCHC for that technology.
	profile for LoRaWAN networks.
	In order to deploy SCHC, it is mandatory that the C/D and F/R peers		As an example, [rfc9011] provides the SCHC profile for LoRaWAN
	are provisionned with the exact same set of rules. To be able to		networks.
	provision end-points from different vendors, a common data model is
	needed that expresses the SCHC rules in an interoperable fashion. To
	that effect, [I-D.ietf-lpwan-schc-yang-data-model] defines a rule
	representation using the YANG [rfc7950] formalism.
	Finally, section 3 of [rfc8724] depicts a typical network		3. The Static Context Header Compression
	architecture for an LPWAN network, simplified from that shown in
	[rfc8376]and reproduced in Figure 1.		SCHC [rfc8724] specifies an extreme compression capability based on a
			state that must match on the compressor and decompressor side. This
			state comprises a set of Compression/Decompression (C/D) rules.
			The SCHC Parser analyzes incoming packets and creates a list of
			fields that it matches against the compression rules. The rule that
			matches best is used to compress the packet, and the rule identifier
			(RuleID) is transmitted together with the compression residue to the
			decompressor. Based on the RuleID and the residue, the decompressor
			can rebuild the original packet and forward it in its uncompressed
			form over the Internet.
			[rfc8724] also provides a Fragmentation/Reassembly (F/R) capability
			to cope with the maximum frame size of a Link, which is extremely
			constrained in the case of an LPWAN network.
			If a SCHC-compressed packet is too large to be sent in a single Link-
			Layer PDU, the SCHC fragmentation can be applied on the compressed
			packet. The process of SCHC fragmentation is similar to that of
			compression; the fragmentation rules that are programmed for this
			device are checked to find the most appropriate one, regarding the
			SCHC packet size, the link error rate, and the reliability level
			required by the application.
			The nature of a ruleID allows to determine if it is a compression or
			fragmentation rule.
			4. SCHC Endpoints
			Section 3 of [rfc8724] depicts a typical network architecture for an
			LPWAN network, simplified from that shown in [rfc8376] and reproduced
			in Figure 1.
	() () () |		() () () |
	() () () () / \ +---------+		() () () () / \ +---------+
	() () () () () () / \======| ^ | +-----------+		() () () () () () / \======| ^ | +-----------+
	() () () | | <--|--> | |Application|		() () () | | <--|--> | |Application|
	() () () () / \==========| v |=============| Server |		() () () () / \==========| v |=============| Server |
	() () () / \ +---------+ +-----------+		() () () / \ +---------+ +-----------+
	Dev RGWs NGW App		Dev RGWs NGW App
	Figure 1: Typical LPWAN Network Architecture		Figure 1: Typical LPWAN Network Architecture
	skipping to change at page 4, line 7 ¶		skipping to change at page 4, line 23 ¶
	to star-oriented deployments and/or to use cases where applications		to star-oriented deployments and/or to use cases where applications
	are very static and the state can provisionned in advance.		are very static and the state can provisionned in advance.
	[I-D.thubert-intarea-schc-over-ppp] describes an alternate deployment		[I-D.thubert-intarea-schc-over-ppp] describes an alternate deployment
	where the C/D and/or F/R operations are performed between peers of		where the C/D and/or F/R operations are performed between peers of
	equal capabilities over a PPP [rfc2516] connection. SCHC over PPP		equal capabilities over a PPP [rfc2516] connection. SCHC over PPP
	illustrates that with SCHC, the protocols that are compressed can be		illustrates that with SCHC, the protocols that are compressed can be
	discovered dynamically and the rules can be fetched on-demand by both		discovered dynamically and the rules can be fetched on-demand by both
	parties from the same Uniform Resource Name (URN) [rfc8141], ensuring		parties from the same Uniform Resource Name (URN) [rfc8141], ensuring
	that the peers use the exact same set of rules.		that the peers use the exact same set of rules.
	+----------+ Wi-Fi / +----------+ ....		+----------+ Wi-Fi / +----------+ ....
	| IP | Ethernet | IP | .. )		| IP | Ethernet | IP | .. )
	| Host +-----/------+ Router +----------( Internet )		| Host +-----/------+ Router +----------( Internet )
	| SCHC C/D | Serial | SCHC C/D | ( )		| SCHC C/D | Serial | SCHC C/D | ( )
	+----------+ +----------+ ...		+----------+ +----------+ ...
	<-- SCHC -->		<-- SCHC -->
	over PPP		over PPP
	Figure 2: PPP-based SCHC Deployment		Figure 2: PPP-based SCHC Deployment
	This document provides a general architecture for a SCHC deployment,		5. SCHC Instances
	positioning the required specifications, describing the possible
	deployment types, and indicating models whereby the rules can be
	distributed and installed to enable reliable and scalable operations.
	2. SCHC Operation		The rule database contains a set of rules that are specific per
			device. There is thus a SCHC instance per pair of endpoints.
			[rfc8724] states that a SCHC instance obtains the rules to process C/
			D and F/R before the session starts, and that rules cannot be
			modified during the session.
	As [I-D.ietf-lpwan-coap-static-context-hc] states, the SCHC		[rfc8724] was defined to compress IPv6 [rfc8200] and UDP; but SCHC
	compression and fragmentation mechanism can be implemented at		really is a generic compression and fragmentation technology. As
	different levels and/or managed by different organizations. For		such, SCHC is agnostic to which protocol it compresses and at which
	instance, as represented figure Figure 3, IP compression and		layer it is operated. The C/D peers may be hosted by different
	fragmentation may be managed by the network SCHC instance and end-to-		entities for different layers, and the F/R operation may also be
	end compression between the device and the application. The former		performed between different parties, or different sub-layers in the
	can itself be split in two instances since encryption hides the field		same stack, and/or managed by different organizations.
	structure.
			If a protocol or a layer requires additional capabilities, it is
			always possible to document more specifically how to use SCHC in that
			context, or to specify additional behaviours. For instance,
			[I-D.ietf-lpwan-coap-static-context-hc] extends the compression to
			CoAP [RFC7252] and OSCORE [RFC8613].
			As represented figure Figure 3, the fragmentation and the compression
			of the IP and UDP headers may be operated by a network SCHC instance
			whereas the end-to-end compression of the application payload happens
			between the device and the application. The compression of the
			application payload may be split in two instances to deal with the
			encrypted portion of the application PDU.
	(device) (NGW) (App)		(device) (NGW) (App)
	+--------+ +--------+		+--------+ +--------+
	A S | CoAP | | CoAP |		A S | CoAP | | CoAP |
	p C | inner | | inner |		p C | inner | | inner |
	p H +--------+ +--------+		p H +--------+ +--------+
	. V | SCHC | | SCHC |		. C | SCHC | | SCHC |
	| inner | cryptographical boundary | inner |		| inner | cryptographical boundary | inner |
	-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._		-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._
	A S | CoAP | | CoAP |		A S | CoAP | | CoAP |
	p C | outer | | outer |		p C | outer | | outer |
	p H +--------+ +--------+		p H +--------+ +--------+
	. C | SCHC | | SCHC |		. C | SCHC | | SCHC |
	| outer | functional boundary | outer |		| outer | layer / functional boundary | outer |
	-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._		-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._.-._
	N . udp . . udp .		N . UDP . . UDP .
	e .......... .................. ..........		e .......... .................. ..........
	t . ipv6 . . ipv6 . . ipv6 .		t . IPv6 . . IPv6 . . IPv6 .
	w C .......... .................. ..........		w S .......... .................. ..........
	o S . schc . . schc . . . .		o C . SCHC . . SCHC . . . .
	r H .......... .......... . . .		r H .......... .......... . . .
	k C . lpwan . . lpwan . . . .		k C . LPWAN . . LPWAN . . . .
	.......... .................. ..........		.......... .................. ..........
	((((LPWAN)))) ------ Internet ------		((((LPWAN)))) ------ Internet ------
	Figure 3: Different SCHC instances in a global system		Figure 3: Different SCHC instances in a global system
	This document defines a generic architecture for SCHC that can be		This document defines a generic architecture for SCHC that can be
	used at any of these levels. The goal of the architectural document		used at any of these levels. The goal of the architectural document
	is to orchestrate the different protocols and data model defined by		is to orchestrate the different protocols and data model defined by
	the LPWAN woeking group to design an operational and interoperable		the LPWAN woeking group to design an operational and interoperable
	framework for allowing IP application over contrained networks.		framework for allowing IP application over contrained networks.
	3. Definitions		6. SCHC Data Model
	4. Global architecture
	As described in [rfc8724] a SCHC service is composed of a Parser,
	analyzing packets and creating a list of fields what will be used to
	match against the compression rules. If a packet matches rules,
	compression can be applied following rules instructions.
	If SCHC compressed packet is too large to be send in a single L2
	frame, fragmentation will apply. The process is similar, device
	rules are checked to find the most appropriate fragmentation rule,
	regarding the SCHC packet size, the link error rate, the reliability
	required by the application, ...
	On the other direction, when a packet SCHC arrives, the ruleID is
	used to find the rule. Its nature allows to select if it is a
	compression or fragmentation rule.
	The rule database contains a set of rules specific to a single
	device. The [rfc8724] indicates that the SCHC instance reads the
	rules to process C/D and F/R, rules are not modified during these
	actions.
	A SCHC instance, summarized in the Figure 4, implies C/D and F/R
	present in both end. The device connected to a constrained network
	is in one end and the other end is either located in the core network
	or at the application.
	In any cases, the rules must be the same in both ends to perform C/D
	and F/R.
	(device) (core|app)		A SCHC instance, summarized in the Figure 4, implies C/D and/or F/R
			present in both end and that both ends are provisionned with the same
			set of rules.
	(---) (---)		(-------) (-------)
	( r ) ( r )		( Rules ) ( Rules )
	(---) (---)		(-------) (-------)
	. read . read		. read . read
	. .		. .
	+-----+ +-----+		+-------+ +-------+
	<===| R&D |<=..............................<=| C&F |<===		<===| R & D |<=== <===| C & F |<===
	===>| C&F |=>..............................=>| R&D |===>		===>| C & F |===> ===>| R & D |===>
	+-----+ +-----+		+-------+ +-------+
			+-------+
	Figure 4: Summarized SCHC elements		Figure 4: Summarized SCHC elements
	To enable rule synchronization between both ends, a common rule		To be able to provision end-points from different vendors, a common
	representation must be defined.		rule representation is needed that expresses the SCHC rules in an
			interoperable fashion. To that effect,
	5. Data management		[I-D.ietf-lpwan-schc-yang-data-model] defines a rule representation
			using the YANG [1] formalism.
	[I-D.ietf-lpwan-schc-yang-data-model] defines an YANG data model to		[I-D.ietf-lpwan-schc-yang-data-model] defines an YANG data model to
	represent the rules. This enables the use of several protocols for		represent the rules. This enables the use of several protocols for
	rule management, such as NETCONF, RESTCONF and CORECONF. NETCONF		rule management, such as NETCONF[RFC6241], RESTCONF[RFC8040], and
	uses SSH, RESTCONF uses HTTPS, and CORECONF uses CoAP(s) as their		CORECONF[I-D.ietf-core-comi]. NETCONF uses SSH, RESTCONF uses HTTPS,
	respective transport layer protocols. The data is represented in XML		and CORECONF uses CoAP(s) as their respective transport layer
	under NETCONF, in JSON under RESTCONF and in CBOR under CORECONF.		protocols. The data is represented in XML under NETCONF, in
			JSON[RFC8259] under RESTCONF and in CBOR[RFC8949] under CORECONF.
	create		create
	(-------) read +=======+ *		(-------) read +=======+ *
	( rules )<------->|Rule |<--|-------->		( rules )<------->|Rule |<--|-------->
	(-------) update |Manager| NETCONF, RESTCONF or CORECONF		(-------) update |Manager| NETCONF, RESTCONF or CORECONF
	. read delete +=======+ request		. read delete +=======+ request
	.		.
	+-------+		+-------+
	<===| R & D |<===		<===| R & D |<===
	===>| C & F |===>		===>| C & F |===>
	+-------+		+-------+
	Figure 5: Summerized SCHC elements		Figure 5: Summerized SCHC elements
	Rule Manager (RM) is in charge of handling data derived from the YANG		The Rule Manager (RM) is in charge of handling data derived from the
	Data Model and apply changes to the rules database Figure 5.		YANG Data Model and apply changes to the rules database Figure 5.
	The RM is a application using the Internet to exchange information,		The RM is a application using the Internet to exchange information,
	therefore:		therefore:
	o for the network-level SCHC, the communication does not require		o for the network-level SCHC, the communication does not require
	routing. Each of the end-points having an RM and both RMs can be		routing. Each of the end-points having an RM and both RMs can be
	viewed on the same link, therefore wellknown Link Local addresses		viewed on the same link, therefore wellknown Link Local addresses
	can be used to identify the device and the core RM. L2 security		can be used to identify the device and the core RM. L2 security
	MAY be deemed as sufficient, if it provides the necessary level of		MAY be deemed as sufficient, if it provides the necessary level of
	protection.		protection.
	o for application-level SCHC, routing is involved and global IP		o for application-level SCHC, routing is involved and global IP
	addresses SHOULD be used. End-to-end encryption is recommended.		addresses SHOULD be used. End-to-end encryption is RECOMMENDED.
	Management messages can also be carried in the negotiation protocol		Management messages can also be carried in the negotiation protocol
	as proposed in [I-D.thubert-intarea-schc-over-ppp]		as proposed in [I-D.thubert-intarea-schc-over-ppp]. The RM traffic
			may be itself compressed by SCHC, especially if CORECONF is used,
			[I-D.ietf-lpwan-coap-static-context-hc] can be used.
	The RM traffic may be itself compressed by SCHC, especially if		7. Security Considerations
	CORECONF is used, [I-D.ietf-lpwan-coap-static-context-hc] can be
	used.
	6. Acknowledgements		SCHC is sensitive to the rules that could be abused to form arbitrary
			long messages or as a form of attack against the C/D and/or F/R
			functions, say to generate a buffer overflow and either modify the
			device or crash it. It is thus critical to ensure that the rules are
			distributed in a fashion that is protected against tempering, e.g.,
			encrypted and signed.
			8. IANA Consideration
			This document has no request to IANA
			9. Acknowledgements
	The authors would like to thank (in alphabetic order):		The authors would like to thank (in alphabetic order):
	7. References		10. References
	7.1. Normative References		10.1. Normative References
	[rfc8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC.		[rfc8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC.
	Zuniga, "SCHC: Generic Framework for Static Context Header		Zuniga, "SCHC: Generic Framework for Static Context Header
	Compression and Fragmentation", RFC 8724,		Compression and Fragmentation", RFC 8724,
	DOI 10.17487/RFC8724, April 2020,		DOI 10.17487/RFC8724, April 2020,
	<https://www.rfc-editor.org/info/rfc8724>.		<https://www.rfc-editor.org/info/rfc8724>.
	7.2. Informative References		[rfc9011] Gimenez, O., Ed. and I. Petrov, Ed., "Static Context
			Header Compression and Fragmentation (SCHC) over LoRaWAN",
			RFC 9011, DOI 10.17487/RFC9011, April 2021,
			<https://www.rfc-editor.org/info/rfc9011>.
			10.2. Informative References
			[I-D.ietf-core-comi]
			Veillette, M., Stok, P., Pelov, A., Bierman, A., and I.
			Petrov, "CoAP Management Interface (CORECONF)", draft-
			ietf-core-comi-11 (work in progress), January 2021.
	[I-D.ietf-lpwan-coap-static-context-hc]		[I-D.ietf-lpwan-coap-static-context-hc]
	Minaburo, A., Toutain, L., and R. Andreasen, "LPWAN Static		Minaburo, A., Toutain, L., and R. Andreasen, "LPWAN Static
	Context Header Compression (SCHC) for CoAP", draft-ietf-		Context Header Compression (SCHC) for CoAP", draft-ietf-
	lpwan-coap-static-context-hc-19 (work in progress), March		lpwan-coap-static-context-hc-19 (work in progress), March
	2021.		2021.
	[I-D.ietf-lpwan-schc-yang-data-model]		[I-D.ietf-lpwan-schc-yang-data-model]
	Minaburo, A. and L. Toutain, "Data Model for Static		Minaburo, A. and L. Toutain, "Data Model for Static
	Context Header Compression (SCHC)", draft-ietf-lpwan-schc-		Context Header Compression (SCHC)", draft-ietf-lpwan-schc-
	skipping to change at page 8, line 33 ¶		skipping to change at page 8, line 32 ¶
	[I-D.thubert-intarea-schc-over-ppp]		[I-D.thubert-intarea-schc-over-ppp]
	Thubert, P., "SCHC over PPP", draft-thubert-intarea-schc-		Thubert, P., "SCHC over PPP", draft-thubert-intarea-schc-
	over-ppp-03 (work in progress), April 2021.		over-ppp-03 (work in progress), April 2021.
	[rfc2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D.,		[rfc2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D.,
	and R. Wheeler, "A Method for Transmitting PPP Over		and R. Wheeler, "A Method for Transmitting PPP Over
	Ethernet (PPPoE)", RFC 2516, DOI 10.17487/RFC2516,		Ethernet (PPPoE)", RFC 2516, DOI 10.17487/RFC2516,
	February 1999, <https://www.rfc-editor.org/info/rfc2516>.		February 1999, <https://www.rfc-editor.org/info/rfc2516>.
	[rfc7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained		[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
			and A. Bierman, Ed., "Network Configuration Protocol
			(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
			<https://www.rfc-editor.org/info/rfc6241>.
			[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>.
	[rfc7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",		[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
	RFC 7950, DOI 10.17487/RFC7950, August 2016,		Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
	<https://www.rfc-editor.org/info/rfc7950>.		<https://www.rfc-editor.org/info/rfc8040>.
	[rfc8141] Saint-Andre, P. and J. Klensin, "Uniform Resource Names		[rfc8141] Saint-Andre, P. and J. Klensin, "Uniform Resource Names
	(URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017,		(URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017,
	<https://www.rfc-editor.org/info/rfc8141>.		<https://www.rfc-editor.org/info/rfc8141>.
	[rfc8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6		[rfc8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
	(IPv6) Specification", STD 86, RFC 8200,		(IPv6) Specification", STD 86, RFC 8200,
	DOI 10.17487/RFC8200, July 2017,		DOI 10.17487/RFC8200, July 2017,
	<https://www.rfc-editor.org/info/rfc8200>.		<https://www.rfc-editor.org/info/rfc8200>.
			[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>.
	[rfc8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN)		[rfc8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN)
	Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018,		Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018,
	<https://www.rfc-editor.org/info/rfc8376>.		<https://www.rfc-editor.org/info/rfc8376>.
	[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>.
	[rfc9011] Gimenez, O., Ed. and I. Petrov, Ed., "Static Context		[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
	Header Compression and Fragmentation (SCHC) over LoRaWAN",		Representation (CBOR)", STD 94, RFC 8949,
	RFC 9011, DOI 10.17487/RFC9011, April 2021,		DOI 10.17487/RFC8949, December 2020,
	<https://www.rfc-editor.org/info/rfc9011>.		<https://www.rfc-editor.org/info/rfc8949>.
			10.3. URIs
			[1] RFC7950
	Authors' Addresses		Authors' Addresses
	Alexander Pelov		Alexander Pelov
	Acklio		Acklio
	1137A avenue des Champs Blancs		1137A avenue des Champs Blancs
	35510 Cesson-Sevigne Cedex		35510 Cesson-Sevigne Cedex
	France		France
	Email: a@ackl.io		Email: a@ackl.io
End of changes. 42 change blocks.
	145 lines changed or deleted		187 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/