< draft-ietf-lpwan-schc-yang-data-model-04.txt		draft-ietf-lpwan-schc-yang-data-model-09.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: August 6, 2021 Institut MINES TELECOM; IMT Atlantique		Expires: 17 November 2022 Institut MINES TELECOM; IMT Atlantique
	February 02, 2021		16 May 2022
	Data Model for Static Context Header Compression (SCHC)		Data Model for Static Context Header Compression (SCHC)
	draft-ietf-lpwan-schc-yang-data-model-04		draft-ietf-lpwan-schc-yang-data-model-09
	Abstract		Abstract
	This document describes a YANG data model for the SCHC (Static		This document describes a YANG data model for the SCHC (Static
	Context Header Compression) compression and fragmentation rules.		Context Header Compression) compression and fragmentation rules.
	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.
	skipping to change at page 1, line 32 ¶		skipping to change at page 1, line 32 ¶
	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 August 6, 2021.		This Internet-Draft will expire on 17 November 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2022 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/
	(https://trustee.ietf.org/license-info) in effect on the date of		license-info) in effect on the date of publication of this document.
	publication of this document. Please review these documents		Please review these documents carefully, as they describe your rights
	carefully, as they describe your rights and restrictions with respect		and restrictions with respect to this document. Code Components
	to this document. Code Components extracted from this document must		extracted from this document must include Revised BSD License text as
	include Simplified BSD License text as described in Section 4.e of		described in Section 4.e of the Trust Legal Provisions and are
	the Trust Legal Provisions and are provided without warranty as		provided without warranty as described in the Revised BSD License.
	described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. SCHC rules . . . . . . . . . . . . . . . . . . . . . . . . . 2		2. SCHC rules . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2.1. Compression Rules . . . . . . . . . . . . . . . . . . . . 3		2.1. Compression Rules . . . . . . . . . . . . . . . . . . . . 4
	2.2. Field Identifier . . . . . . . . . . . . . . . . . . . . 3		2.2. Identifier generation . . . . . . . . . . . . . . . . . . 4
	2.3. Field length . . . . . . . . . . . . . . . . . . . . . . 5		2.3. Field Identifier . . . . . . . . . . . . . . . . . . . . 5
	2.4. Field position . . . . . . . . . . . . . . . . . . . . . 6		2.4. Field length . . . . . . . . . . . . . . . . . . . . . . 7
	2.5. Direction Indicator . . . . . . . . . . . . . . . . . . . 6		2.5. Field position . . . . . . . . . . . . . . . . . . . . . 8
	2.6. Target Value . . . . . . . . . . . . . . . . . . . . . . 7		2.6. Direction Indicator . . . . . . . . . . . . . . . . . . . 8
	2.7. Matching Operator . . . . . . . . . . . . . . . . . . . . 8		2.7. Target Value . . . . . . . . . . . . . . . . . . . . . . 10
	2.7.1. Matching Operator arguments . . . . . . . . . . . . . 9		2.8. Matching Operator . . . . . . . . . . . . . . . . . . . . 10
	2.8. Compression Decompression Actions . . . . . . . . . . . . 10		2.8.1. Matching Operator arguments . . . . . . . . . . . . . 12
	2.8.1. Compression Decompression Action arguments . . . . . 12		2.9. Compression Decompression Actions . . . . . . . . . . . . 12
	3. Rule definition . . . . . . . . . . . . . . . . . . . . . . . 12		2.9.1. Compression Decompression Action arguments . . . . . 13
	3.1. Compression rule . . . . . . . . . . . . . . . . . . . . 14		2.10. Fragmentation rule . . . . . . . . . . . . . . . . . . . 13
	3.1.1. Compression context representation. . . . . . . . . . 14		2.10.1. Fragmentation mode . . . . . . . . . . . . . . . . . 13
	3.1.2. Rule definition . . . . . . . . . . . . . . . . . . . 15		2.10.2. Fragmentation Header . . . . . . . . . . . . . . . . 14
	3.2. Fragmentation rule . . . . . . . . . . . . . . . . . . . 16		2.10.3. Last fragment format . . . . . . . . . . . . . . . . 15
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24		2.10.4. Acknowledgment behavior . . . . . . . . . . . . . . 17
	5. Security considerations . . . . . . . . . . . . . . . . . . . 24		2.10.5. Fragmentation Parameters . . . . . . . . . . . . . . 18
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24		2.10.6. Layer 2 parameters . . . . . . . . . . . . . . . . . 19
	7. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 24		3. Rule definition . . . . . . . . . . . . . . . . . . . . . . . 19
	8. Normative References . . . . . . . . . . . . . . . . . . . . 41		3.1. Compression rule . . . . . . . . . . . . . . . . . . . . 21
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42		3.2. Fragmentation rule . . . . . . . . . . . . . . . . . . . 24
			3.3. YANG Tree . . . . . . . . . . . . . . . . . . . . . . . . 28
			4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
			5. Security considerations . . . . . . . . . . . . . . . . . . . 29
			6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29
			7. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 30
			8. Normative References . . . . . . . . . . . . . . . . . . . . 52
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52
	1. Introduction		1. Introduction
			SCHC is a compression and fragmentation mechanism for constrained
			networks defined in [RFC8724]. It is based on a static context
			shared by two entities at the boundary of the constrained network.
			[RFC8724] provides a non formal representation of the rules used
			either for compression/decompression (or C/D) or fragmentation/
			reassembly (or F/R). The goal of this document is to formalize the
			description of the rules to offer:
			* the same definition on both ends, even if the internal
			representation is different.
			* an update of the other end to set up some specific values (e.g.
			IPv6 prefix, Destination address,...)
			* ...
			This document defines a YANG module to represent both compression and
			fragmentation rules, which leads to common representation for values
			for all the rules elements.
	2. SCHC rules		2. SCHC rules
	SCHC is a compression and fragmentation mechanism for constrained		SCHC is a compression and fragmentation mechanism for constrained
	networks defined in [RFC8724]. It is based on a static context		networks defined in [RFC8724]. It is based on a static context
	shared by two entities at the boundary this constrained network.		shared by two entities at the boundary of the constrained network.
	Draft [RFC8724] provides an non formal representation of the rules		[RFC8724] provides a non formal representation of the rules used
	used either for compression/decompression (or C/D) or fragmentation/		either for compression/decompression (or C/D) or fragmentation/
	reassembly (or F/R). The goal of this document is to formalize the		reassembly (or F/R). The goal of this document is to formalize the
	description of the rules to offer:		description of the rules to offer:
	o the same definition on both ends, even if the internal		* the same definition on both ends, even if the internal
	representation is different.		representation is different.
	o an update the other end to set up some specific values (e.g. IPv6		* an update of the other end to set up some specific values (e.g.
	prefix, Destination address,...)		IPv6 prefix, Destination address,...)
	o ...		* ...
	This document defines a YANG module to represent both compression and		This document defines a YANG module to represent both compression and
	fragmentation rules, which leads to common representation for values		fragmentation rules, which leads to common representation for values
	for all the rules elements.		for all the rules elements.
	SCHC compression is generic, the main mechanism do no refers to a		SCHC compression is generic, the main mechanism does not refer to a
	specific protocol. Any header field is abstracted through an ID, a		specific protocol. Any header field is abstracted through an ID, a
	position, a direction and a value that can be a numerical value or a		position, a direction, and a value that can be a numerical value or a
	string. [RFC8724] and [I-D.ietf-lpwan-coap-static-context-hc]		string. [RFC8724] and [RFC8824] specify fields for IPv6, UDP, CoAP
	specifies fields for IPv6, UDP, CoAP and OSCORE.		and OSCORE.
	[I-D.barthel-lpwan-oam-schc] decribes ICMPv6 header compression.
	SCHC fragmentation requires a set of common parameters that are		SCHC fragmentation requires a set of common parameters that are
	included in a rule. These parameters are defined in [RFC8724].		included in a rule. These parameters are defined in [RFC8724].
			The YANG model allows to select the compression or the fragmentation
			using the feature command.
			feature compression {
			description
			"SCHC compression capabilities are taken into account";
			}
			feature fragmentation {
			description
			"SCHC fragmentation capabilities are taken into account";
			}
			Figure 1: Feature for compression and fragmentation.
	2.1. Compression Rules		2.1. Compression Rules
	[RFC8724] proposes an non formal representation of the compression		[RFC8724] proposes a non formal representation of the compression
	rule. A compression context for a device is composed of a set of		rule. A compression context for a device is composed of a set of
	rules. Each rule contains information to describe a specific field		rules. Each rule contains information to describe a specific field
	in the header to be compressed.		in the header to be compressed.
	+-----------------------------------------------------------------+		+-----------------------------------------------------------------+
	| Rule N |		| Rule N |
	+-----------------------------------------------------------------+|		+-----------------------------------------------------------------+|
	| Rule i ||		| Rule i ||
	+-----------------------------------------------------------------+||		+-----------------------------------------------------------------+||
	| (FID) Rule 1 |||		| (FID) Rule 1 |||
	skipping to change at page 3, line 44 ¶		skipping to change at page 4, line 42 ¶
	|+-------+--+--+--+------------+-----------------+---------------+|||		|+-------+--+--+--+------------+-----------------+---------------+|||
	||Field 2|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act||||		||Field 2|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act||||
	|+-------+--+--+--+------------+-----------------+---------------+|||		|+-------+--+--+--+------------+-----------------+---------------+|||
	||... |..|..|..| ... | ... | ... ||||		||... |..|..|..| ... | ... | ... ||||
	|+-------+--+--+--+------------+-----------------+---------------+||/		|+-------+--+--+--+------------+-----------------+---------------+||/
	||Field N|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|||		||Field N|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|||
	|+-------+--+--+--+------------+-----------------+---------------+|/		|+-------+--+--+--+------------+-----------------+---------------+|/
	| |		| |
	\-----------------------------------------------------------------/		\-----------------------------------------------------------------/
	Figure 1: Compression Decompression Context		Figure 2: Compression Decompression Context
	2.2. Field Identifier		2.2. Identifier generation
			Identifier used in the SCHC YANG Data Model are from the identityref
			statement to ensure to be globally unique and be easily augmented if
			needed. The principle to define a new type based on a group of
			identityref is the following:
			* define a main identity ending with the keyword base-type.
			* derive all the identities used in the Data Model from this base
			type.
			* create a typedef from this base type.
			The example (Figure 3) shows how an identityref is created for RCS
			algorithms used during SCHC fragmentation.
			// -- RCS algorithm types
			identity rcs-algorithm-base-type {
			description
			"Identify which algorithm is used to compute RCS.
			The algorithm also defines the size of the RCS field.";
			}
			identity rcs-RFC8724 {
			base rcs-algorithm-base-type;
			description
			"CRC 32 defined as default RCS in RFC8724. RCS is 4 byte-long";
			}
			typedef rcs-algorithm-type {
			type identityref {
			base rcs-algorithm-base-type;
			}
			description
			"type used in rules.";
			}
			Figure 3: Principle to define a type based on identityref.
			2.3. Field Identifier
	In the process of compression, the headers of the original packet are		In the process of compression, the headers of the original packet are
	first parsed to create a list of fields. This list of fields is		first parsed to create a list of fields. This list of fields is
	matched against the rules to find the appropriate one and apply		matched against the rules to find the appropriate rule and apply
	compression. The link between the list given by the parsed fields		compression. [RFC8724] does not state how the field ID value is
	and the rules is done through a field ID. [RFC8724] do not state how		constructed. In examples, identification is done through a string
	the field ID value can be constructed. In examples, identification		indexed by the protocol name (e.g. IPv6.version, CoAP.version,...).
	is done through a string indexed by the protocol name (e.g.
	IPv6.version, CoAP.version,...).		The current YANG Data Model includes fields definitions found in
			[RFC8724], [RFC8824].
	Using the YANG model, each field MUST be identified through a global		Using the YANG model, each field MUST be identified through a global
	YANG identityref. A YANG field ID derives from the field-id-base-		YANG identityref. A YANG field ID for the protocol always derives
	type. Figure 2 gives some field ID definitions. Note that some		from the fid-base-type. Then an identity for each protocol is
	field IDs can be splitted is smaller pieces. This is the case for		specified using the naming convention fid-<<protocol name>>-base-
	"fid-ipv6-trafficclass-ds" and "fid-ipv6-trafficclass-ecn" which are		type. All possible fields for this protocol MUST derive from the
	a subset of "fid-ipv6-trafficclass-ds".		protocol identity. The naming convention is "fid" followed by the
			protocol name and the field name. If a field has to be divided into
			sub-fields, the field identity serves as a base.
	identity field-id-base-type {		The full field-id definition is found in Section 7. The example
	description "Field ID with SID";		Figure 4 gives the first field ID definitions. A type is defined for
	}		IPv6 protocol, and each field is based on it. Note that the DiffServ
			bits derives from the Traffic Class identity.
	identity fid-ipv6-version {		identity fid-base-type {
	base field-id-base-type;		description
	description "IPv6 version field from RFC8200";		"Field ID base type for all fields";
	}		}
	identity fid-ipv6-trafficclass {		identity fid-ipv6-base-type {
	base field-id-base-type;		base fid-base-type;
	description "IPv6 Traffic Class field from RFC8200";		description
			"Field ID base type for IPv6 headers described in RFC 8200";
	}		}
	identity fid-ipv6-trafficclass-ds {		identity fid-ipv6-version {
	base field-id-base-type;		base fid-ipv6-base-type;
	description "IPv6 Traffic Class field from RFC8200,		description
	DiffServ field from RFC3168";		"IPv6 version field from RFC8200";
	}		}
	identity fid-ipv6-trafficclass-ecn {		identity fid-ipv6-trafficclass {
	base field-id-base-type;		base fid-ipv6-base-type;
	description "IPv6 Traffic Class field from RFC8200,		description
	ECN field from RFC3168";		"IPv6 Traffic Class field from RFC8200";
	}		}
			identity fid-ipv6-trafficclass-ds {
			base fid-ipv6-trafficclass;
			description
			"IPv6 Traffic Class field from RFC8200,
			DiffServ field from RFC3168";
			}
	...		...
	Figure 2: Definition of identityref for field IDs		Figure 4: Definition of identityref for field IDs
	Figure 2 gives some examples of field ID identityref definitions.
	The base identity is field-id-base-type, and field id are derived for
	it.
	The naming convention is "fid" followed by the protocol name and the
	field name.
	The yang model in annex (see Section 7) gives the full definition of
	the field ID for [RFC8724], [I-D.ietf-lpwan-coap-static-context-hc],
	and [I-D.barthel-lpwan-oam-schc].
	The type associated to this identity is field-id-type (cf. Figure 3)
	typedef field-id-type {		The type associated to this identity is fid-type (cf. Figure 5)
	description "Field ID generic type.";		typedef fid-type {
	type identityref {		type identityref {
	base field-id-base-type;		base fid-base-type;
	}
	}		}
			description
			"Field ID generic type.";
			}
	Figure 3: Type definition for field IDs		Figure 5: Type definition for field IDs
	2.3. Field length		2.4. Field length
	Field length is either an integer giving the size of a field in bits		Field length is either an integer giving the size of a field in bits
	or a specific function. [RFC8724] defines the "var" function which		or a specific function. [RFC8724] defines the "var" function which
	allows variable length fields in byte and		allows variable length fields (whose length is expressed in bytes)
	[I-D.ietf-lpwan-coap-static-context-hc] defines the "tkl" function		and [RFC8824] defines the "tkl" function for managing the CoAP Token
	for managing the CoAP Token length field.		length field.
	identity field-length-base-type {		The naming convention is "fl" followed by the function name.
	description "used to extend field length functions";
			identity fl-base-type {
			description
			"Used to extend field length functions.";
	}		}
	identity fl-variable {		identity fl-variable {
	base field-length-base-type;		base fl-base-type;
	description "residue length in Byte is sent";		description
			"Residue length in Byte is sent as defined
			for CoAP in RFC 8824 (cf. 5.3).";
	}		}
	identity fl-token-length {		identity fl-token-length {
	base field-length-base-type;		base fl-base-type;
	description "residue length in Byte is sent";		description
			"Residue length in Byte is sent as defined
			for CoAP in RFC 8824 (cf. 4.5).";
	}		}
	Figure 4: Definition of identityref for field ILength		Figure 6: Definition of identityref for Field Length
	As for field ID, field length function can be defined as a		The field length function can be defined as an identityref as shown
	identityref as shown in Figure 4.		in Figure 6.
	Therefore the type for field length is a union between an integer		Therefore, the type for field length is a union between an integer
	giving in bits the size of the length and the identityref (cf.		giving in bits the size of the length and the identityref (cf.
	Figure 5).		Figure 7).
	typedef field-length-type {
	description "Field length either a positive integer giving the size in bits
	or a function defined through an identityref.";
	type union {
	type int64; /* positive length in bits */
	type identityref { /* function */
	base field-length-base-type;
	}
	}
	}
	Figure 5: Type definition for field Length		typedef fl-type {
			type union {
			type int64; /* positive integer, expressing length in bits */
			type identityref { /* function */
			base fl-base-type;
			}
			}
			description
			"Field length either a positive integer expressing the size in
			bits or a function defined through an identityref.";
			}
	The naming convention is fl followed by the function name as defined		Figure 7: Type definition for field Length
	in SCHC specifications.
	2.4. Field position		2.5. Field position
	Field position is a positive integer which gives the position of a		Field position is a positive integer which gives the position of a
	field, the default value is 1, but if the field is repeated several		field, the default value is 1, and incremented at each repetition.
	times, the value is higher. value 0 indicates that the position is		value 0 indicates that the position is not important and is not
	not important and is not taken into account during the rule selection		considered during the rule selection process.
	process.
	Field position is a positive integer. The type is an uint8.		Field position is a positive integer. The type is an uint8.
	2.5. Direction Indicator		2.6. Direction Indicator
	The Direction Indicator (DI) is used to tell if a field appears in		The Direction Indicator (di) is used to tell if a field appears in
	both direction (Bi) or only uplink (Up) or Downlink (Dw).		both direction (Bi) or only uplink (Up) or Downlink (Dw).
	identity direction-indicator-base-type {		identity di-base-type {
	description "used to extend field length functions";		description
			"Used to extend direction indicators.";
	}		}
	identity di-bidirectional {		identity di-bidirectional {
	base direction-indicator-base-type;		base di-base-type;
	description "Direction Indication of bi directionality";		description
			"Direction Indication of bidirectionality in
			RFC 8724 (cf. 7.1).";
	}		}
	identity di-up {		identity di-up {
	base direction-indicator-base-type;		base di-base-type;
	description "Direction Indication of upstream";		description
			"Direction Indication of uplink defined in
			RFC 8724 (cf. 7.1).";
	}		}
	identity di-down {		identity di-down {
	base direction-indicator-base-type;		base di-base-type;
	description "Direction Indication of downstream";		description
			"Direction Indication of downlink defined in
			RFC 8724 (cf. 7.1).";
	}		}
	Figure 6: Definition of identityref for direction indicators		Figure 8: Definition of identityref for direction indicators
	Figure 6 gives the identityref for Direction Indicators.		Figure 8 gives the identityref for Direction Indicators. The naming
			convention is "di" followed by the Direction Indicator name.
	The type is "direction-indicator-type" (cf. Figure 7).		The type is "di-type" (cf. Figure 9).
	typedef direction-indicator-type {		typedef di-type {
	description "direction in LPWAN network, up when emitted by the device,		type identityref {
	down when received by the device, bi when emitted or received by the device.";		base di-base-type;
	type identityref {		}
	base direction-indicator-base-type;		description
	}		"Direction in LPWAN network, up when emitted by the device,
	}		down when received by the device, bi when emitted or
			received by the device.";
			}
	Figure 7: Type definition for direction indicators		Figure 9: Type definition for direction indicators
	2.6. Target Value		2.7. Target Value
	Target Value may be either a string or binary sequence. For match-		The Target Value is a list of binary sequences of any length, aligned
	mapping, several of these values can be contained in a Target Value		to the left. Figure 10 shows the definition of a single element of a
	field. In the data model, this is generalized by adding a position,		Target Value. In the rule, the structure will be used as a list,
	which orders the list of values. By default the position is set to		with position as a key. The highest position value is used to
	0.		compute the size of the index sent in residue for the match-mapping
			CDA. The position allows to specify several values:
	The leaf "value" is not mandatory to represent a non existing value		* For Equal and LSB, Target Value contains a single element.
	in a TV.		Therefore, the indicia is set to 0.
	grouping target-values-struct {		* For match-mapping, Target Value can contain several elements.
	description "defines the target value element. Can be either an arbitrary		Indicia values MUST start from 0 and MUST be contiguous.
	binary or ascii element. All target values are considered as a matching lists.
	Position is used to order values, by default position 0 is used when containing
	a single element.";
	leaf value {		grouping tv-struct {
	type union {		description
	type binary;		"Defines the target value element. Always a binary type, strings
	type string;		must be converted to binary. field-id allows the conversion
	}		to the appropriate type.";
	}		leaf value {
	leaf position {		type binary;
	description "If only one element position is 0, otherwise position is the		description
	matching list.";		"Target Value";
	type uint16;		}
	}		leaf indicia {
			type uint16;
			description
			"Indicia gives the position in the matching-list. If only one
			element is present, indicia is 0. Otherwise, indicia is the
			the order in the matching list, starting at 0.";
			}
	}		}
	Figure 8: Definition of target value		Figure 10: Definition of target value
	Figure 8 gives the definition of a single element of a Target Value.
	In the rule, this will be used as a list, with position as a key.
	The highest position value is used to compute the size of the index
	sent in residue.
	2.7. Matching Operator		2.8. Matching Operator
	Matching Operator (MO) is a function applied between a field value		Matching Operator (MO) is a function applied between a field value
	provided by the parsed header and the target value. [RFC8724]		provided by the parsed header and the target value. [RFC8724]
	defines 4 MO.		defines 4 MO as listed in Figure 11.
	identity matching-operator-base-type {		identity mo-base-type {
	description "used to extend Matching Operators with SID values";		description
			"Used to extend Matching Operators with SID values";
	}		}
	identity mo-equal {		identity mo-equal {
	base matching-operator-base-type;		base mo-base-type;
	description "RFC 8724";		description
			"Equal MO as defined in RFC 8724 (cf. 7.3)";
	}		}
	identity mo-ignore {		identity mo-ignore {
	base matching-operator-base-type;		base mo-base-type;
	description "RFC 8724";		description
			"Ignore MO as defined in RFC 8724 (cf. 7.3)";
	}		}
	identity mo-msb {		identity mo-msb {
	base matching-operator-base-type;		base mo-base-type;
	description "RFC 8724";		description
			"MSB MO as defined in RFC 8724 (cf. 7.3)";
	}		}
	identity mo-matching {		identity mo-match-mapping {
	base matching-operator-base-type;		base mo-base-type;
	description "RFC 8724";		description
			"match-mapping MO as defined in RFC 8724 (cf. 7.3)";
	}		}
	Figure 9: Definition of identityref for Matching Operator		Figure 11: Definition of identityref for Matching Operator
	the type is "matching-operator-type" (cf. Figure 10)		The naming convention is "mo" followed by the MO name.
	typedef matching-operator-type {		The type is "mo-type" (cf. Figure 12)
	description "Matching Operator (MO) to compare fields values with target values";
	type identityref {
	base matching-operator-base-type;
	}
	}
	Figure 10: Type definition for Matching Operator		typedef mo-type {
			type identityref {
			base mo-base-type;
			}
			description
			"Matching Operator (MO) to compare fields values with
			target values";
			}
	2.7.1. Matching Operator arguments		Figure 12: Type definition for Matching Operator
	Some Matching Operator such as MSB can take some values. Even if		2.8.1. Matching Operator arguments
	currently LSB is the only MO takes only one argument, in the future
	some MO may require several arguments. They are viewed as a list of
	target-values-type.
	2.8. Compression Decompression Actions		They are viewed as a list, built with a tv-struct (see chapter
			Section 2.7).
	Compression Decompression Action (CDA) identified the function to use		2.9. Compression Decompression Actions
	either for compression or decompression. [RFC8724] defines 6 CDA.
	identity compression-decompression-action-base-type;		Compression Decompression Action (CDA) identifies the function to use
			for compression or decompression. [RFC8724] defines 6 CDA.
	identity cda-not-sent {		Figure 14 shows some CDA definition, the full definition is in
	base compression-decompression-action-base-type;		Section 7.
	description "RFC 8724";
	}
	identity cda-value-sent {		identity cda-base-type {
	base compression-decompression-action-base-type;		description
	description "RFC 8724";		"Compression Decompression Actions.";
	}		}
	identity cda-lsb {		identity cda-not-sent {
	base compression-decompression-action-base-type;		base cda-base-type;
	description "RFC 8724";		description
	}		"not-sent CDA as defined in RFC 8724 (cf. 7.4).";
			}
	identity cda-mapping-sent {		identity cda-value-sent {
	base compression-decompression-action-base-type;		base cda-base-type;
	description "RFC 8724";		description
	}		"value-sent CDA as defined in RFC 8724 (cf. 7.4).";
			}
	identity cda-compute-length {		identity cda-lsb {
	base compression-decompression-action-base-type;		base cda-base-type;
	description "RFC 8724";		description
	}		"LSB CDA as defined in RFC 8724 (cf. 7.4).";
			}
	identity cda-compute-checksum {		identity cda-mapping-sent {
	base compression-decompression-action-base-type;		base cda-base-type;
	description "RFC 8724";		description
	}		"mapping-sent CDA as defined in RFC 8724 (cf. 7.4).";
			}
	identity cda-deviid {		identity cda-compute {
	base compression-decompression-action-base-type;		base cda-base-type;
	description "RFC 8724";		description
	}		"compute-* CDA as defined in RFC 8724 (cf. 7.4)";
			}
			....
	identity cda-appiid {		Figure 13: Definition of identityref for Compresion Decompression
	base compression-decompression-action-base-type;		Action
	description "RFC 8724";
			The naming convention is "cda" followed by the CDA name.
			typedef cda-type {
			type identityref {
			base cda-base-type;
	}		}
			description
			"Compression Decompression Action to compression or
			decompress a field.";
			}
	Figure 11: Definition of identityref for Compresion Decompression		Figure 14: Type definition for Compresion Decompression Action
	Action
	The type is "comp-decomp-action-type" (cf. Figure 12)		2.9.1. Compression Decompression Action arguments
	typedef comp-decomp-action-type {
	description "Compression Decompression Action to compression or decompress a field.";
	type identityref {
	base compression-decompression-action-base-type;
	}
	}
	Figure 12: Type definition for Compresion Decompression Action		Currently no CDA requires arguments, but in the future some CDA may
			require one or several arguments. They are viewed as a list, of
			target-value type.
	2.8.1. Compression Decompression Action arguments		2.10. Fragmentation rule
	Currently no CDA requires arguments, but the future some CDA may		Fragmentation is optional in the data model and depends on the
	require several arguments. They are viewed as a list of target-		presence of the "fragmentation" feature.
	values-type.
	3. Rule definition		Most of the fragmentation parameters are listed in Annex D of
			[RFC8724].
	A rule is either a C/D or an F/R rule. A rule is identified by the		Since fragmentation rules work for a specific direction, they MUST
	rule ID value and its associated length. The YANG grouping rule-id-		contain a mandatory direction indicator. The type is the same as the
	type defines the structure used to represent a rule ID. Length of 0		one used in compression entries, but bidirectional MUST NOT be used.
	is allowed to represent an implicit rule.
	// Define rule ID. Rule ID is composed of a RuleID value and a Rule ID Length		2.10.1. Fragmentation mode
	grouping rule-id-type {		[RFC8724] defines 3 fragmentation modes:
	leaf rule-id {
	type uint32;
	description "rule ID value, this value must be unique combined with the length";
	}
	leaf rule-length {
	type uint8 {
	range 0..32;
	}
	description "rule ID length in bits, value 0 is for implicit rules";
	}
	}
	// SCHC table for a specific device.		* No Ack: this mode is unidirectionnal, no acknowledgment is sent
			back.
	container schc {		* Ack Always: each fragmentation window must be explicitly
	leaf version{		acknowledged before going to the next.
	type uint64;
	mandatory false;
	description "used as an indication for versioning";
	}
	list rule {
	key "rule-id rule-length";
	uses rule-id-type;
	choice nature {
	case fragmentation {
	uses fragmentation-content;
	}
	case compression {
	uses compression-content;
	}
	}
	}
	}
	Figure 13: Definition of a SCHC Context		* Ack on Error: A window is acknowledged only when the receiver
			detects some missing fragments.
	To access to a specific rule, rule-id and its specific length is used		Figure 15 shows the definition for identifiers from these three
	as a key. The rule is either a compression or a fragmentation rule.		modes.
	Each context can be identified though a version id.		identity fragmentation-mode-base-type {
			description
			"fragmentation mode.";
			}
	3.1. Compression rule		identity fragmentation-mode-no-ack {
			base fragmentation-mode-base-type;
			description
			"No-ACK of RFC8724.";
			}
	A compression rule is composed of entries describing its processing		identity fragmentation-mode-ack-always {
	(cf. Figure 14). An entry contains all the information defined in		base fragmentation-mode-base-type;
	Figure 1 with the types defined above.		description
			"ACK-Always of RFC8724.";
			}
	3.1.1. Compression context representation.		identity fragmentation-mode-ack-on-error {
			base fragmentation-mode-base-type;
			description
			"ACK-on-Error of RFC8724.";
			}
	The compression rule described Figure 1 is associated to a rule ID.		typedef fragmentation-mode-type {
	The compression rule entry is defined in Figure 14. Each column in		type identityref {
	the table is either represented by a leaf or a list. Note that		base fragmentation-mode-base-type;
	Matching Operators and Compression Decompression actions can have		}
	arguments. They are viewed a ordered list of strings and numbers as		description
	in target values.		"type used in rules";
			}
	grouping compression-rule-entry {		Figure 15: Definition of fragmentation mode identifer
	description "These entries defines a compression entry (i.e. a line)
	as defined in RFC 8724 and fragmentation parameters.
	+-------+--+--+--+------------+-----------------+---------------+		The naming convention is "fragmentation-mode" followed by the
	|Field 1|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|		fragmentation mode name.
	+-------+--+--+--+------------+-----------------+---------------+
	An entry in a compression rule is composed of 7 elements:		2.10.2. Fragmentation Header
	- Field ID: The header field to be compressed. The content is a YANG identifer.
	- Field Length : either a positive integer of a function defined as a YANG id.
	- Field Position: a positive (and possibly equal to 0) integer.
	- Direction Indicator: a YANG identifier giving the direction.
	- Target value: a value against which the header Field is compared.
	- Matching Operator: a YANG id giving the operation, parameters may be
	associated to that operator.
	- Comp./Decomp. Action: A YANG id giving the compression or decompression
	action, parameters may be associated to that action.
	";
	leaf field-id {		A data fragment header, starting with the rule ID can be sent on the
	description "Field ID, identify a field in the header with a YANG identityref.";		fragmentation direction. The SCHC header may be composed of (cf.
	mandatory true;		Figure 16):
	type schc:field-id-type;
	}
	leaf field-length {
	description "Field Length in bit or through a function defined as a YANG identityref";
	mandatory true;
	type schc:field-length-type;
	}
	leaf field-position {
	description "field position in the header is a integer. If the field is not repeated
	in the header the value is 1, and incremented for each repetition of the field. Position
	0 means that the position is not important and order may change when decompressed";
	mandatory true;
	type uint8;
	}
	leaf direction-indicator {
	description "Direction Indicator, a YANG identityref to say if the packet is bidirectionnal,
	up or down";
	mandatory true;
	type schc:direction-indicator-type;
	}
	list target-values {
	description "a list of value to compare with the header field value. If target value
	is a singleton, position must be 0. For matching-list, should be consecutive position
	values starting from 1.";
	key position;
	uses target-values-struct;
	}
	leaf matching-operator {
	mandatory true;
	type schc:matching-operator-type;
	}
	list matching-operator-value {
	key position;
	uses target-values-struct;
	}
	leaf comp-decomp-action {
	mandatory true;
	type schc:comp-decomp-action-type;
	}
	list comp-decomp-action-value {
	key position;
	uses target-values-struct;
	}
	}
	Figure 14: Definition of a compression entry		* a Datagram Tag (Dtag) identifying the datagram being fragmented if
			the fragmentation applies concurrently on several datagrams. This
			field in optional and its length is defined by the rule.
	3.1.2. Rule definition		* a Window (W) used in Ack-Always and Ack-on-Error modes. In Ack-
			Always, its size is 1. In Ack-on-Error, it depends on the rule.
			This field is not needed in No-Ack mode.
	A compression rule is a list of entries.		* a Fragment Compressed Number (FCN) indicating the fragment/tile
			position on the window. This field is mandatory on all modes
			defined in [RFC8724], its size is defined by the rule.
	grouping compression-content {		|-- SCHC Fragment Header ----|
	description "define a compression rule composed of a list of entries.";		|-- T --|-M-|-- N --|
	list entry {		+-- ... -+- ... -+---+- ... -+--------...-------+~~~~~~~~~~~~~~~~~~~~
	key "field-id field-position direction-indicator";		| RuleID | DTag | W | FCN | Fragment Payload | padding (as needed)
	uses compression-rule-entry;		+-- ... -+- ... -+---+- ... -+--------...-------+~~~~~~~~~~~~~~~~~~~~
	}
	}
	Figure 15: Definition of a compression rule		Figure 16: Data fragment header from RFC8724
	To identify a specific entry Field ID, position and direction are		2.10.3. Last fragment format
	needed.
	3.2. Fragmentation rule		The last fragment of a datagram is sent with an RCS (Reassembly Check
			Sequence) field to detect residual transmission error and possible
			losses in the last window. [RFC8724] defines a single algorithm
			based on Ethernet CRC computation. The identity of the RCS algorithm
			is shown in Figure 17.
	Parameters for fragmentation are defined in Annex D of [RFC8724].		identity rcs-algorithm-base-type {
			description
			"Identify which algorithm is used to compute RCS.
			The algorithm also defines the size of the RCS field.";
			}
	Figure 16 gives the first elements found in this structure. It		identity rcs-RFC8724 {
	starts with a direction. Since fragmentation rules work for a		base rcs-algorithm-base-type;
	specific direction, they contain a mandatory direction. The type is		description
	the same as the one used in compression entries, but the use of		"CRC 32 defined as default RCS in RFC8724. RCS is 4 byte-long";
	bidirectionnal is forbidden.		}
	The next elements describe size of SCHC fragmentation header fields.		typedef rcs-algorithm-type {
	Only the FCN size is mandatory and value must be higher or equal to		type identityref {
	1.		base rcs-algorithm-base-type;
			}
			description
			"type used in rules.";
			}
	grouping fragmentation-content {		Figure 17: type definition for RCS
	description "This grouping defines the fragmentation parameters for
	all the modes (No Ack, Ack Always and Ack on Error) specified in
	RFC 8724.";
	leaf direction {		The naming convention is "rcs" followed by the algorithm name.
	type schc:direction-indicator-type;
	description "should be up or down, bi directionnal is forbidden.";
	mandatory true;
	}
	leaf dtagsize {
	type uint8;
	description "size in bit of the DTag field";
	}		For Ack-on-Error mode, the All-1 fragment may just contain the RCS or
	leaf wsize {		can include a tile. The parameters defined in Figure 18 allows to
	type uint8;		define the behavior:
	description "size in bit of the window field";
	}
	leaf fcnsize {
	type uint8 {
	range 1..max;
	}
	description "size in bit of the FCN field";
	mandatory true;
	}
	...
	Figure 16: Definition of a fragmentation parameters, SCHC header		* all1-data-no: the last fragment contains no data, just the RCS
	RCS algorithm is defined (Figure 17), by default with the CRC		* all1-data-yes: the last fragment includes a single tile and the
	computation proposed in [RFC8724]. The algorithms are identified		RCS
	through an identityref specified in the SCHC Data Model and with the
	type RCS-algorithm-type (Figure 18).
	...		* all1-data-sender-choice: the last fragment may or may not contain
	leaf RCS-algorithm {		a single tile. The receiver can detect if a tile is present.
	type RCS-algorithm-type;
	default schc:RFC8724-RCS;
	description "Algoritm used for RCS";
	}
	...
	Figure 17: Definition of a fragmentation parameters, RCS algorithm		identity all1-data-base-type {
	identity RCS-algorithm-base-type {		description
	description "identify which algorithm is used to compute RSC.		"Type to define when to send an Acknowledgment message.";
	The algorithm defines also the size if the RSC field.";		}
	}
	identity RFC8724-RCS {		identity all1-data-no {
	description "CRC 32 defined as default RCS in RFC8724.";		base all1-data-base-type;
	base RCS-algorithm-base-type;		description
			"All1 contains no tiles.";
			}
			identity all1-data-yes {
			base all1-data-base-type;
			description
			"All1 MUST contain a tile.";
			}
			identity all1-data-sender-choice {
			base all1-data-base-type;
			description
			"Fragmentation process chooses to send tiles or not in all1.";
			}
			typedef all1-data-type {
			type identityref {
			base all1-data-base-type;
	}		}
			description
			"Type used in rules.";
			}
	typedef RCS-algorithm-type {		Figure 18: type definition for RCS
	type identityref {
	base RCS-algorithm-base-type;		The naming convention is "all1-data" followed by the behavior
	}		identifier.
			2.10.4. Acknowledgment behavior
			The acknowledgment fragment header goes in the opposite direction of
			data. The header is composed of (see Figure 19):
			* a Dtag (if present).
			* a mandatory window as in the data fragment.
			* a C bit giving the status of RCS validation. In case of failure,
			a bitmap follows, indicating the received tile.
			|--- SCHC ACK Header ----|
			|-- T --|-M-| 1 |
			+-- ... -+- ... -+---+---+~~~~~~~~~~~~~~~~~~
			| RuleID | DTag | W |C=1| padding as needed (success)
			+-- ... -+- ... -+---+---+~~~~~~~~~~~~~~~~~~
			+-- ... -+- ... -+---+---+------ ... ------+~~~~~~~~~~~~~~~
			| RuleID | DTag | W |C=0|Compressed Bitmap| pad. as needed (failure)
			+-- ... -+- ... -+---+---+------ ... ------+~~~~~~~~~~~~~~~
			Figure 19: Acknowledgment fragment header for RFC8724
			For Ack-on-Error, SCHC defines when an acknowledgment can be sent.
			This can be at any time defined by the layer 2, at the end of a
			window (FCN All-0) or as a response to receiving the last fragment
			(FCN All-1). The following identifiers (cf. Figure 20) define the
			acknowledgment behavior.
			identity ack-behavior-base-type {
			description
			"Define when to send an Acknowledgment .";
			}
			identity ack-behavior-after-All0 {
			base ack-behavior-base-type;
			description
			"Fragmentation expects Ack after sending All0 fragment.";
			}
			identity ack-behavior-after-All1 {
			base ack-behavior-base-type;
			description
			"Fragmentation expects Ack after sending All1 fragment.";
			}
			identity ack-behavior-by-layer2 {
			base ack-behavior-base-type;
			description
			"Layer 2 defines when to send an Ack.";
			}
			typedef ack-behavior-type {
			type identityref {
			base ack-behavior-base-type;
	}		}
			description
			"Type used in rules.";
			}
	Figure 18: Definition of identityref for RCS Algorithm		Figure 20: bitmap generation behavior
	Figure 19 gives the parameters used by the state machine to handle		The naming convention is "ack-behavior" followed by the algorithm
			name.
			2.10.5. Fragmentation Parameters
			The state machine requires some common values to handle
	fragmentation:		fragmentation:
	o maximum-window-size contains the maximum FCN value that can be		* retransmission-timer expresses, in seconds, the duration before
	used.		sending an ack request (cf. section 8.2.2.4. of [RFC8724]). If
			specified, value must be higher or equal to 1.
	o retransmission-timer gives in seconds the duration before sending		* inactivity-timer expresses, in seconds, the duration before
	an ack request (cf. section 8.2.2.4. of [RFC8724]). If specifed,		aborting a fragmentation session (cf. section 8.2.2.4. of
	value must be higher or equal to 1.		[RFC8724]). The value 0 explicitly indicates that this timer is
			disabled.
	o inactivity-timer gives in seconds the duration before aborting		* max-ack-requests expresses the number of attempts before aborting
	(cf. section 8.2.2.4. of [RFC8724]), value of 0 explicitly		(cf. section 8.2.2.4. of [RFC8724]).
	indicates that this timer is disabled.
	o max-ack-requests gives the number of attempts before aborting (cf.		* maximum-packet-size rexpresses, in bytes, the larger packet size
	section 8.2.2.4. of [RFC8724]).		that can be reassembled.
	o maximum-packet-size gives in bytes the larger packet size that can		They are defined as unsigned integers, see Section 7.
	be reassembled.
	...		2.10.6. Layer 2 parameters
	leaf maximum-window-size {
	type uint16;
	description "by default 2^wsize - 2";
	}
	leaf retransmission-timer {		The data model includes two parameters needed for fragmentation:
	type uint64 {
	range 1..max;
	}
	description "duration in seconds of the retransmission timer"; // Check the units
	}
	leaf inactivity-timer {		* l2-word-size: [RFC8724] base fragmentation on a layer 2 word which
	type uint64;		can be of any length. The default value is 8 and correspond to
	description "duration is seconds of the inactivity timer, 0 indicates the timer is disabled"; // check units		the default value for byte aligned layer 2. A value of 1 will
	}		indicate that there is no alignment and no need for padding.
	leaf max-ack-requests {		* maximum-packet-size: defines the maximum size of a uncompressed
	type uint8 {		datagram. By default, the value is set to 1280 bytes.
	range 1..max;
	}
	description "the maximum number of retries for a specific SCHC ACK.";
	}
	leaf maximum-packet-size {		They are defined as unsigned integer, see Section 7.
	type uint16;
	default 1280;
	description "When decompression is done, packet size must not strictly exceed this limit in Bytes";
	}
	...
	Figure 19: Definition of a fragmentation state machine parameters		3. Rule definition
	Figure 20 gives information related to a specific compression mode:		A rule is idenfied by a unique rule identifier (rule ID) comprising
	fragmentation-mode MUST be set with a specific behavior. Identityref		both a Rule ID value and a Rule ID length. The YANG grouping rule-
	are given Figure 21.		id-type defines the structure used to represent a rule ID. A length
			of 0 is allowed to represent an implicit rule.
	For Ack on Error some specific information may be provided:		Three types of rules are defined in [RFC8724]:
	o tile-size gives in bits the size of the tile; If set to 0 a single		* Compression: a compression rule is associated with the rule ID.
	tile is inserted inside a fragment.
	o tile-in-All1 indicates if All1 contains only the RCS (all1-data-		* No compression: this identifies the default rule used to send a
	no) or may contain a single tile (all1-data-yes). Since the		packet in extenso when no compression rule was found (see
	reassembly process may detect this behavior, the choice can be		[RFC8724] section 6).
	left to the fragmentation process. In that case identityref all1-
	data-sender-choice as to be specified. All possible values are
	given Figure 21.
	o ack-behavior tells when the fragmentation process may send		* Fragmentation: fragmentation parameters are associated with the
	acknowledgments. When ack-behavior-after-All0 is specified, the		rule ID. Fragmentation is optional and feature "fragmentation"
	ack may be sent after the reception of All-0 fragment. When ack-		should be set.
	behavior-after-All1 is specified, the ack may be sent after the
	reception of All-1 fragment at the end of the fragmentation
	process. ack-behavior-always do not impose a limitation at the
	SCHC level. The constraint may come from the LPWAN technology.
	All possible values are given Figure 21.
	...		grouping rule-id-type {
	leaf fragmentation-mode {		leaf rule-id-value {
	type schc:fragmentation-mode-type;		type uint32;
	description "which fragmentation mode is used (noAck, AckAlways, AckonError)";		description
	mandatory true;		"Rule ID value, this value must be unique, considering its
			length.";
			}
			leaf rule-id-length {
			type uint8 {
			range "0..32";
	}		}
			description
			"Rule ID length, in bits. The value 0 is for implicit rules.";
			}
			description
			"A rule ID is composed of a value and a length, expressed in
			bits.";
			}
	choice mode {		// SCHC table for a specific device.
	case no-ack;
	case ack-always;
	case ack-on-error {
	leaf tile-size {
	type uint8;
	description "size in bit of tiles, if not specified or set to 0: tile fills the fragment.";
	}
	leaf tile-in-All1 {
	type schc:all1-data-type;
	description "When true, sender and receiver except a tile in All-1 frag";
	}
	leaf ack-behavior {
	type schc:ack-behavior-type;
	description "Sender behavior to acknowledge, after All-0, All-1 or when the
	LPWAN allows it (Always)";
	}
	}
	}
	...
	Figure 20: Definition of a fragmentation specific information		container schc {
			list rule {
			key "rule-id-value rule-id-length";
			uses rule-id-type;
			choice nature {
			case fragmentation {
			if-feature "fragmentation";
			uses fragmentation-content;
			}
			case compression {
			if-feature "compression";
			uses compression-content;
			}
			case no-compression {
			description
			"RFC8724 requires a rule for uncompressed headers.";
			}
			description
			"A rule is for compression, for no-compression or for
			fragmentation.";
			}
			description
			"Set of rules compression, no compression or fragmentation
			rules identified by their rule-id.";
			}
			description
			"a SCHC set of rules is composed of a list of rules which are
			used for compression, no-compression or fragmentation.";
			}
			}
	// -- FRAGMENTATION TYPE		Figure 21: Definition of a SCHC Context
	// -- fragmentation modes		To access a specific rule, the rule ID length and value are used as a
			key. The rule is either a compression or a fragmentation rule.
	identity fragmentation-mode-base-type {		3.1. Compression rule
	description "fragmentation mode";
	}		A compression rule is composed of entries describing its processing
			(cf. Figure 22). An entry contains all the information defined in
			Figure 2 with the types defined above.
	identity fragmentation-mode-no-ack {		The compression rule described Figure 2 is defined by compression-
	description "No Ack of RFC 8724.";		content. It defines a list of compression-rule-entry, indexed by
	base fragmentation-mode-base-type;		their field id, position and direction. The compression-rule-entry
	}		element represent a line of the table Figure 2. Their type reflects
			the identifier types defined in Section 2.1
	identity fragmentation-mode-ack-always {		Some checks are performed on the values:
	description "Ack Always of RFC8724.";
	base fragmentation-mode-base-type;		* target value must be present for MO different from ignore.
			* when MSB MO is specified, the matching-operator-value must be
			present
			grouping compression-rule-entry {
			description
			"These entries defines a compression entry (i.e. a line)
			as defined in RFC 8724.
			+-------+--+--+--+------------+-----------------+---------------+
			|Field 1|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|
			+-------+--+--+--+------------+-----------------+---------------+
			An entry in a compression rule is composed of 7 elements:
			- Field ID: The header field to be compressed. The content is a
			YANG identifer.
			- Field Length : either a positive integer of a function defined
			as a YANG id.
			- Field Position: a positive (and possibly equal to 0) integer.
			- Direction Indicator: a YANG identifier giving the direction.
			- Target value: a value against which the header Field is
			compared.
			- Matching Operator: a YANG id giving the operation, parameters
			may be associated to that operator.
			- Comp./Decomp. Action: A YANG id giving the compression or
			decompression action, parameters may be associated to that
			action.
			";
			leaf field-id {
			type schc:fid-type;
			mandatory true;
			description
			"Field ID, identify a field in the header with a YANG
			referenceid.";
	}		}
	identity fragmentation-mode-ack-on-error {		leaf field-length {
	description "Ack on Error of RFC8724.";		type schc:fl-type;
	base fragmentation-mode-base-type;		mandatory true;
			description
			"Field Length, expressed in number of bits or through a function defined as a
			YANG referenceid.";
			}
			leaf field-position {
			type uint8;
			mandatory true;
			description
			"Field position in the header is an integer. Position 1 matches
			the first occurence of a field in the header, while incremented
			position values match subsequent occurences.
			Position 0 means that this entry matches a field irrespective
			of its position of occurence in the header.
			Be aware that the decompressed header may have position-0
			fields ordered differently than they appeared in the original
			packet.";
			}
			leaf direction-indicator {
			type schc:di-type;
			mandatory true;
			description
			"Direction Indicator, a YANG referenceid to say if the packet
			is bidirectional, up or down";
			}
			list target-value {
			key "position";
			uses tv-struct;
			description
			"A list of value to compare with the header field value.
			If target value is a singleton, position must be 0.
			For use as a matching list for the mo-match-mapping matching
			operator, positions should take consecutive values starting
			from 1.";
			}
			leaf matching-operator {
			type schc:mo-type;
			must "../target-value or derived-from-or-self(., 'mo-ignore')" {
			error-message
			"mo-equal, mo-msb and mo-match-mapping need target-value";
			description
			"target-value is not required for mo-ignore";
			}
			must "not (derived-from-or-self(., 'mo-msb')) or
			../matching-operator-value" {
			error-message "mo-msb requires length value";
			}
			mandatory true;
			description
			"MO: Matching Operator";
	}		}
			list matching-operator-value {
			key "position";
			uses tv-struct;
			description
			"Matching Operator Arguments, based on TV structure to allow
			several arguments.
			In RFC 8724, only the MSB matching operator needs arguments (a single argument, which is the
			number of most significant bits to be matched)";
			}
			leaf comp-decomp-action {
			type schc:cda-type;
			mandatory true;
			description
			"CDA: Compression Decompression Action.";
			}
			list comp-decomp-action-value {
			key "position";
			uses tv-struct;
			description
			"CDA arguments, based on a TV structure, in order to allow for
			several arguments. The CDAs specified in RFC 8724 require no
			argument.";
			}
			}
	typedef fragmentation-mode-type {		grouping compression-content {
	type identityref {		list entry {
	base fragmentation-mode-base-type;		key "field-id field-position direction-indicator";
	}		uses compression-rule-entry;
			description
			"A compression rule is a list of rule entries, each describing
			a header field. An entry is identifed through a field-id,
			its position in the packet and its direction.";
	}		}
			description
			"Define a compression rule composed of a list of entries.";
			}
	// -- Ack behavior		Figure 22: Definition of a compression entry
	identity ack-behavior-base-type {		3.2. Fragmentation rule
	description "define when to send an Acknowledgment message";
	}
	identity ack-behavior-after-All0 {		A Fragmentation rule is composed of entries describing the protocol
	description "fragmentation expects Ack after sending All0 fragment.";		behavior. Some on them are numerical entries, others are identifiers
	base ack-behavior-base-type;		defined in Section 2.10.
	}
	identity ack-behavior-after-All1 {		The definition of a Fragmentation rule is divided into three sub-
	description "fragmentation expects Ack after sending All1 fragment.";		parts (cf. figure Figure 24):
	base ack-behavior-base-type;
	}
	identity ack-behavior-always {		* parameters such as the fragmentation-mode, the l2-word-size and
	description "fragmentation expects Ack after sending every fragment.";		the direction. Since Fragmentation rules are always defined for a
	base ack-behavior-base-type;		specific direction, the value must be either di-up or di-down (di-
	}		bidirectional is not allowed).
	typedef ack-behavior-type {		* parameters defining the Fragmentation header format (dtag-size,
	type identityref {		w-size, fcn-size and rcs-algorithm).
	base ack-behavior-base-type;
	}
	}
	// -- All1 with data types		* Protocol parameters for timers (inactivity-timer, retransmission-
			timer). [RFC8724] do not specified any range for these timers.
			[RFC9011] recommends a duration of 12 hours. In fact, the value
			range sould be between milli-seconds for real time systems to
			several days. Figure Figure 23 shows the two parameters defined
			for timers:
	identity all1-data-base-type {		- the duration of a tick is computed through this formula 2^tick-
	description "type to define when to send an Acknowledgment message";		duration/10^6. When tick-duration is set to 0, the unit is the
	}		micro-second. The default value of 20 leads to a unit of about
			1.05 second. A value of 32 leads to a tick duration of about
			1.19 hours.
	identity all1-data-no {		- the number of ticks in the predefined unit. With the default
	description "All1 contains no tiles.";		tick-duration value of 20, the timers can cover a range between
	base all1-data-base-type;		1.0 sec and 19 hours covering [RFC9011] recommandation.
	}
	identity all1-data-yes {		* Protocol behavior (maximum-packet-size, max-interleaved-frames,
	description "All1 MUST contain a tile";		max-ack-requests). If these parameters are specific to a single
	base all1-data-base-type;		fragmentation mode, they are grouped in a structure dedicated to
			that Fragmentation mode. If some parameters can be found in
			several modes, typically ACK-Always and ACK-on-Error, they are
			defined in a common part and a when statement indicates which
			modes are allowed.
			grouping timer-duration {
			leaf ticks-duration {
			type uint8;
			default 20;
			description "duration of one tick in micro-seconds, 2^ticks-duration/10^6 = 1.048s";
			}
			leaf ticks-numbers {
			type uint16;
			description "timer duration = ticks-numbers * 2^ticks-duration / 10^6";
	}		}
			}
	identity all1-data-sender-choice {		Figure 23: Timer duration values
	description "Fragmentation process choose to send tiles or not in all1.";
	base all1-data-base-type;		grouping fragmentation-content {
			description
			"This grouping defines the fragmentation parameters for
			all the modes (No-Ack, Ack-Always and Ack-on-Error) specified in
			RFC 8724.";
			leaf fragmentation-mode {
			type schc:fragmentation-mode-type;
			mandatory true;
			description
			"which fragmentation mode is used (noAck, AckAlways,
			AckonError)";
			}
			leaf l2-word-size {
			type uint8;
			default "8";
			description
			"Size, in bits, of the layer 2 word";
			}
			leaf direction {
			type schc:di-type;
			must "derived-from-or-self(., 'di-up') or
			derived-from-or-self(., 'di-down')" {
			error-message
			"direction for fragmentation rules are up or down.";
			}
			mandatory true;
			description
			"Should be up or down, bidirectionnal is forbiden.";
			}
			// SCHC Frag header format
			leaf dtag-size {
			type uint8;
			default "0";
			description
			"Size, in bits, of the DTag field (T variable from RFC8724).";
			}
			leaf w-size {
			when "derived-from(../fragmentation-mode,
			'fragmentation-mode-ack-on-error')
			or
			derived-from(../fragmentation-mode,
			'fragmentation-mode-ack-always') ";
			type uint8;
			description
			"Size, in bits, of the window field (M variable from RFC8724).";
			}
			leaf fcn-size {
			type uint8;
			mandatory true;
			description
			"Size, in bits, of the FCN field (N variable from RFC8724).";
			}
			leaf rcs-algorithm {
			type rcs-algorithm-type;
			default "schc:rcs-RFC8724";
			description
			"Algorithm used for RCS. The algorithm specifies the RCS size";
			}
			// SCHC fragmentation protocol parameters
			leaf maximum-packet-size {
			type uint16;
			default "1280";
			description
			"When decompression is done, packet size must not
			strictly exceed this limit, expressed in bytes.";
			}
			leaf window-size {
			type uint16;
			description
			"By default, if not specified 2^w-size - 1. Should not exceed
			this value. Possible FCN values are between 0 and
			window-size - 1.";
	}		}
			leaf max-interleaved-frames {
			type uint8;
			default "1";
			description
			"Maximum of simultaneously fragmented frames. Maximum value is
			2^dtag-size. All DTAG values can be used, but at most
			max-interleaved-frames must be active at any time.";
			}
			leaf inactivity-timer {
			type uint64;
			description
			"Duration is seconds of the inactivity timer, 0 indicates
			that the timer is disabled.";
			}
			leaf retransmission-timer {
			when "derived-from(../fragmentation-mode,
			'fragmentation-mode-ack-on-error')
			or
			derived-from(../fragmentation-mode,
			'fragmentation-mode-ack-always') ";
			type uint64 {
			range "1..max";
			}
			description
			"Duration in seconds of the retransmission timer.";
			}
			leaf max-ack-requests {
			when "derived-from(../fragmentation-mode,
			'fragmentation-mode-ack-on-error')
			or
			derived-from(../fragmentation-mode,
			'fragmentation-mode-ack-always') ";
			type uint8 {
			range "1..max";
			}
			description
			"The maximum number of retries for a specific SCHC ACK.";
			}
			choice mode {
			case no-ack;
			case ack-always;
			case ack-on-error {
			leaf tile-size {
			when "derived-from(../fragmentation-mode,
			'fragmentation-mode-ack-on-error')";
			type uint8;
			description
			"Size, in bits, of tiles. If not specified or set to 0,
			tiles fill the fragment.";
	typedef all1-data-type {
	type identityref {
	base all1-data-base-type;
	}		}
			leaf tile-in-All1 {
			when "derived-from(../fragmentation-mode,
			'fragmentation-mode-ack-on-error')";
			type schc:all1-data-type;
			description
			"Defines whether the sender and receiver expect a tile in
			All-1 fragments or not, or if it is left to the sender's
			choice.";
			}
			leaf ack-behavior {
			when "derived-from(../fragmentation-mode,
			'fragmentation-mode-ack-on-error')";
			type schc:ack-behavior-type;
			description
			"Sender behavior to acknowledge, after All-0, All-1 or
			when the LPWAN allows it.";
			}
			}
			description
			"RFC 8724 defines 3 fragmentation modes.";
	}		}
			}
	Figure 21: Specific types for Ack On Error mode		Figure 24: Fragmentation Parameters
	## YANG Tree		3.3. YANG Tree
	module: schc		module: ietf-schc
	+--rw schc		+--rw schc
	+--rw version? uint64		+--rw rule* [rule-id-value rule-id-length]
	+--rw rule* [rule-id rule-length]		+--rw rule-id-value uint32
	+--rw rule-id uint32		+--rw rule-id-length uint8
	+--rw rule-length uint8
	+--rw (nature)?		+--rw (nature)?
	+--:(fragmentation)		+--:(fragmentation) {fragmentation}?
	| +--rw direction schc:direction-indicator-type		| +--rw fragmentation-mode schc:fragmentation-mode-type
	| +--rw dtagsize? uint8		| +--rw l2-word-size? uint8
	| +--rw wsize? uint8		| +--rw direction schc:di-type
	| +--rw fcnsize uint8		| +--rw dtag-size? uint8
	| +--rw RCS-algorithm? RCS-algorithm-type		| +--rw w-size? uint8
	| +--rw maximum-window-size? uint16		| +--rw fcn-size uint8
	| +--rw retransmission-timer? uint64		| +--rw rcs-algorithm? rcs-algorithm-type
	| +--rw inactivity-timer? uint64		| +--rw maximum-packet-size? uint16
	| +--rw max-ack-requests? uint8		| +--rw window-size? uint16
	| +--rw maximum-packet-size? uint16		| +--rw max-interleaved-frames? uint8
	| +--rw fragmentation-mode schc:fragmentation-mode-type		| +--rw inactivity-timer
			| | +--rw ticks-duration? uint8
			| | +--rw ticks-numbers? uint16
			| +--rw retransmission-timer
			| | +--rw ticks-duration? uint8
			| | +--rw ticks-numbers? uint16
			| +--rw max-ack-requests? uint8
	| +--rw (mode)?		| +--rw (mode)?
	| +--:(no-ack)		| +--:(no-ack)
	| +--:(ack-always)		| +--:(ack-always)
	| +--:(ack-on-error)		| +--:(ack-on-error)
	| +--rw tile-size? uint8		| +--rw tile-size? uint8
	| +--rw tile-in-All1? schc:all1-data-type		| +--rw tile-in-All1? schc:all1-data-type
	| +--rw ack-behavior? schc:ack-behavior-type		| +--rw ack-behavior? schc:ack-behavior-type
	+--:(compression)		+--:(compression) {compression}?
	+--rw entry* [field-id field-position direction-indicator]		| +--rw entry* [field-id field-position direction-indicator]
	+--rw field-id schc:field-id-type		| +--rw field-id schc:fid-type
	+--rw field-length schc:field-length-type		| +--rw field-length schc:fl-type
	+--rw field-position uint8		| +--rw field-position uint8
	+--rw direction-indicator schc:direction-indicator-type		| +--rw direction-indicator schc:di-type
	+--rw target-values* [position]		| +--rw target-value* [indicia]
	| +--rw value? union		| | +--rw value? binary
	| +--rw position uint16		| | +--rw indicia uint16
	+--rw matching-operator schc:matching-operator-type		| +--rw matching-operator schc:mo-type
	+--rw matching-operator-value* [position]		| +--rw matching-operator-value* [indicia]
	| +--rw value? union		| | +--rw value? binary
	| +--rw position uint16		| | +--rw indicia uint16
	+--rw comp-decomp-action schc:comp-decomp-action-type		| +--rw comp-decomp-action schc:cda-type
	+--rw comp-decomp-action-value* [position]		| +--rw comp-decomp-action-value* [indicia]
	+--rw value? union		| +--rw value? binary
	+--rw position uint16		| +--rw indicia uint16
			+--:(no-compression)
	Figure 22		Figure 25
	4. IANA Considerations		4. IANA Considerations
	This document has no request to IANA.		This document has no request to IANA.
	5. Security considerations		5. Security considerations
	This document does not have any more Security consideration than the		This document does not have any more Security consideration than the
	ones already raised on [RFC8724]		ones already raised in [RFC8724] and [RFC8824].
	6. Acknowledgements		6. Acknowledgements
	The authors would like to thank Dominique Barthel, Carsten Bormann,		The authors would like to thank Dominique Barthel, Carsten Bormann,
	Alexander Pelov.		Alexander Pelov for their careful reading and valuable inputs. A
			special thanks for Carl Moberg for his patience and wise advices when
			building the model.
	7. YANG Module		7. YANG Module
	<code begins> file schc@2020-02-28.yang		<code begins> file ietf-schc@2022-02-15.yang
	module schc{		module ietf-schc {
	yang-version "1";		yang-version 1.1;
	namespace "urn:ietf:lpwan:schc:rules-description";		namespace "urn:ietf:params:xml:ns:yang:ietf-schc";
	prefix "schc";		prefix schc;
	description		organization
	"Generic Data model for Static Context Header Compression Rule for SCHC,		"IETF IPv6 over Low Power Wide-Area Networks (lpwan) working group";
	based on draft-ietf-lpwan-ipv6-static-context-hc-18. Include compression		contact
	rules and fragmentation rules.		"WG Web: <https://datatracker.ietf.org/wg/lpwan/about/>
			WG List: <mailto:p-wan@ietf.org>
			Editor: Laurent Toutain
			<mailto:laurent.toutain@imt-atlantique.fr>
			Editor: Ana Minaburo
			<mailto:ana@ackl.io>";
			description
			"
			Copyright (c) 2021 IETF Trust and the persons identified as
			authors of the code. All rights reserved.
	This module is a YANG model for SCHC rules (RFc 8724).		Redistribution and use in source and binary forms, with or
	RFC 8724 describes a rule in a abstract way through a table.		without modification, is permitted pursuant to, and subject to
			the license terms contained in, the Simplified BSD License set
			forth in Section 4.c of the IETF Trust's Legal Provisions
			Relating to IETF Documents
			(https://trustee.ietf.org/license-info).
	|-----------------------------------------------------------------|		This version of this YANG module is part of RFC XXXX
	| (FID) Rule 1 |		(https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
	|+-------+--+--+--+------------+-----------------+---------------+|		for full legal notices.
	||Field 1|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act||
	|+-------+--+--+--+------------+-----------------+---------------+|
	||Field 2|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act||
	|+-------+--+--+--+------------+-----------------+---------------+|
	||... |..|..|..| ... | ... | ... ||
	|+-------+--+--+--+------------+-----------------+---------------+|
	||Field N|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act||
	+-------+--+--+--+------------+-----------------+---------------+||
	|-----------------------------------------------------------------|
	This module proposes a global data model that can be used for rule		The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
	exchanges or modification. It proposes both the data model format and		NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
	the global identifiers used to describes some operations in fields.		'MAY', and 'OPTIONAL' in this document are to be interpreted as
	This data model applies both to compression and fragmentation.";		described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
	revision 2020-06-15 {		they appear in all capitals, as shown here.
	description "clean up and add descriptions, merge schc-id to this file";
	}
	revision 2020-02-28 {		*****************************************************************
	description "Add Fragmentation parameters";
	}
	revision 2020-01-23 {		Generic Data model for Static Context Header Compression Rule for
	description "Modified TV with binary and union";		SCHC, based on RFC 8724 and RFC8824. Include compression, no
	}		compression and fragmentation rules.
	revision 2020-01-07 {		This module is a YANG model for SCHC rules (RFC 8724 and RFC8824).
	description "First version of the YANG model";		RFC 8724 describes compression rules in a abstract way through a
	}		table.
	// -------------------------		|-----------------------------------------------------------------|
	// Field ID type definition		| (FID) Rule 1 |
	//--------------------------		|+-------+--+--+--+------------+-----------------+---------------+|
			||Field 1|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act||
			|+-------+--+--+--+------------+-----------------+---------------+|
			||Field 2|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act||
			|+-------+--+--+--+------------+-----------------+---------------+|
			||... |..|..|..| ... | ... | ... ||
			|+-------+--+--+--+------------+-----------------+---------------+|
			||Field N|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act||
			+-------+--+--+--+------------+-----------------+---------------+||
			|-----------------------------------------------------------------|
	// generic value TV definition		This module proposes a global data model that can be used for rule
			exchanges or modification. It proposes both the data model format
			and the global identifiers used to describe some operations in
			fields.
			This data model applies to both compression and fragmentation.";
	identity field-id-base-type {		revision 2022-02-15 {
	description "Field ID with SID";		description
	}		"Initial version from RFC XXXX ";
			reference
			"RFC XXX: Data Model for Static Context Header Compression
			(SCHC)";
			}
	identity fid-ipv6-version {		feature compression {
	base field-id-base-type;		description
	description "IPv6 version field from RFC8200";		"SCHC compression capabilities are taken into account";
	}		}
	identity fid-ipv6-trafficclass {		feature fragmentation {
	base field-id-base-type;		description
	description "IPv6 Traffic Class field from RFC8200";		"SCHC fragmentation capabilities are taken into account";
	}		}
	identity fid-ipv6-trafficclass-ds {		// -------------------------
	base field-id-base-type;		// Field ID type definition
	description "IPv6 Traffic Class field from RFC8200,		//--------------------------
	DiffServ field from RFC3168";		// generic value TV definition
	}
	identity fid-ipv6-trafficclass-ecn {		identity fid-base-type {
	base field-id-base-type;		description
	description "IPv6 Traffic Class field from RFC8200,		"Field ID base type for all fields";
	ECN field from RFC3168";		}
	}
	identity fid-ipv6-flowlabel {
	base field-id-base-type;
	description "IPv6 Flow Label field from RFC8200";
	}
	identity fid-ipv6-payloadlength {		identity fid-ipv6-base-type {
	base field-id-base-type;		base fid-base-type;
	description "IPv6 Payload Length field from RFC8200";		description
	}		"Field ID base type for IPv6 headers described in RFC 8200";
			}
	identity fid-ipv6-nextheader {		identity fid-ipv6-version {
	base field-id-base-type;		base fid-ipv6-base-type;
	description "IPv6 Next Header field from RFC8200";		description
	}		"IPv6 version field from RFC8200";
			}
	identity fid-ipv6-hoplimit {		identity fid-ipv6-trafficclass {
	base field-id-base-type;		base fid-ipv6-base-type;
	description "IPv6 Next Header field from RFC8200";		description
	}		"IPv6 Traffic Class field from RFC8200";
			}
	identity fid-ipv6-devprefix {		identity fid-ipv6-trafficclass-ds {
	base field-id-base-type;		base fid-ipv6-trafficclass;
	description "correspond either to the source address or the desdination		description
	address prefix of RFC 8200. Depending if it is respectively		"IPv6 Traffic Class field from RFC8200,
	a uplink or an downklink message.";		DiffServ field from RFC3168";
	}		}
	identity fid-ipv6-deviid {		identity fid-ipv6-trafficclass-ecn {
	base field-id-base-type;		base fid-ipv6-trafficclass;
	description "correspond either to the source address or the desdination		description
	address prefix of RFC 8200. Depending if it is respectively		"IPv6 Traffic Class field from RFC8200,
	a uplink or an downklink message.";		ECN field from RFC3168";
	}		}
	identity fid-ipv6-appprefix {		identity fid-ipv6-flowlabel {
	base field-id-base-type;		base fid-ipv6-base-type;
	description "correspond either to the source address or the desdination		description
	address prefix of RFC 768. Depending if it is respectively		"IPv6 Flow Label field from RFC8200";
	a downlink or an uplink message.";		}
	}
	identity fid-ipv6-appiid {		identity fid-ipv6-payloadlength {
	base field-id-base-type;		base fid-ipv6-base-type;
	description "correspond either to the source address or the desdination		description
	address prefix of RFC 768. Depending if it is respectively		"IPv6 Payload Length field from RFC8200";
	a downlink or an uplink message.";		}
	}
	identity fid-udp-dev-port {
	base field-id-base-type;
	description "UDP length from RFC 768";
	}
	identity fid-udp-app-port {		identity fid-ipv6-nextheader {
	base field-id-base-type;		base fid-ipv6-base-type;
	description "UDP length from RFC 768";		description
	}		"IPv6 Next Header field from RFC8200";
			}
			identity fid-ipv6-hoplimit {
			base fid-ipv6-base-type;
			description
			"IPv6 Next Header field from RFC8200";
			}
	identity fid-udp-length {		identity fid-ipv6-devprefix {
	base field-id-base-type;		base fid-ipv6-base-type;
	description "UDP length from RFC 768";		description
	}		"corresponds to either the source address or the destination
			address prefix of RFC 8200. Depending if it is
			respectively an uplink or a downlink message.";
			}
	identity fid-udp-checksum {		identity fid-ipv6-deviid {
	base field-id-base-type;		base fid-ipv6-base-type;
	description "UDP length from RFC 768";		description
	}		"corresponds to either the source address or the destination
			address prefix of RFC 8200. Depending if it is respectively
			an uplink or a downlink message.";
			}
	identity fid-coap-version {		identity fid-ipv6-appprefix {
	base field-id-base-type;		base fid-ipv6-base-type;
	description "CoAP version from RFC 7252";		description
	}		"corresponds to either the source address or the destination
			address prefix of RFC 8200. Depending if it is respectively
			a downlink or an uplink message.";
			}
	identity fid-coap-type {		identity fid-ipv6-appiid {
	base field-id-base-type;		base fid-ipv6-base-type;
	description "CoAP type from RFC 7252";		description
	}		"corresponds to either the source address or the destination
			address prefix of RFC 8200. Depending if it is respectively
			a downlink or an uplink message.";
			}
	identity fid-coap-tkl {		identity fid-udp-base-type {
	base field-id-base-type;		base fid-base-type;
	description "CoAP token length from RFC 7252";		description
	}		"Field ID base type for UDP headers described in RFC 768";
			}
	identity fid-coap-code {		identity fid-udp-dev-port {
	base field-id-base-type;		base fid-udp-base-type;
	description "CoAP code from RFC 7252";		description
	}		"UDP source or destination port from RFC 768, if uplink or
			downlink communication, respectively.";
			}
	identity fid-coap-code-class {		identity fid-udp-app-port {
	base field-id-base-type;		base fid-udp-base-type;
	description "CoAP code class from RFC 7252";		description
	}		"UDP destination or source port from RFC 768, if uplink or
			downlink communication, respectively.";
			}
	identity fid-coap-code-detail {		identity fid-udp-length {
	base field-id-base-type;		base fid-udp-base-type;
	description "CoAP code detail from RFC 7252";		description
			"UDP length from RFC 768";
			}
	}		identity fid-udp-checksum {
			base fid-udp-base-type;
			description
			"UDP length from RFC 768";
			}
	identity fid-coap-mid {		identity fid-coap-base-type {
	base field-id-base-type;		base fid-base-type;
	description "CoAP message ID from RFC 7252";		description
	}		"Field ID base type for UDP headers described in RFC 7252";
			}
	identity fid-coap-token {		identity fid-coap-version {
	base field-id-base-type;		base fid-coap-base-type;
	description "CoAP token from RFC 7252";		description
	}		"CoAP version from RFC 7252";
			}
	identity fid-coap-option-if-match {		identity fid-coap-type {
	base field-id-base-type;		base fid-coap-base-type;
	description "CoAP option If-Match from RFC 7252";		description
	}		"CoAP type from RFC 7252";
			}
	identity fid-coap-option-uri-host {		identity fid-coap-tkl {
	base field-id-base-type;		base fid-coap-base-type;
	description "CoAP option URI-Host from RFC 7252";		description
	}		"CoAP token length from RFC 7252";
			}
	identity fid-coap-option-etag {		identity fid-coap-code {
	base field-id-base-type;		base fid-coap-base-type;
	description "CoAP option Etag from RFC 7252";		description
	}		"CoAP code from RFC 7252";
			}
	identity fid-coap-option-if-none-match {		identity fid-coap-code-class {
	base field-id-base-type;		base fid-coap-code;
	description "CoAP option if-none-match from RFC 7252";		description
	}		"CoAP code class from RFC 7252";
			}
	identity fid-coap-option-observe {		identity fid-coap-code-detail {
	base field-id-base-type;		base fid-coap-code;
	description "CoAP option Observe from RFC 7641";		description
	}		"CoAP code detail from RFC 7252";
			}
	identity fid-coap-option-uri-port {		identity fid-coap-mid {
	base field-id-base-type;		base fid-coap-base-type;
	description "CoAP option Uri-Port from RFC 7252";		description
	}		"CoAP message ID from RFC 7252";
			}
	identity fid-coap-option-location-path {		identity fid-coap-token {
	base field-id-base-type;		base fid-coap-base-type;
	description "CoAP option Location-Path from RFC 7252";		description
	}		"CoAP token from RFC 7252";
			}
	identity fid-coap-option-uri-path {		identity fid-coap-option-if-match {
	base field-id-base-type;		base fid-coap-base-type;
	description "CoAP option Uri-Path from RFC 7252";		description
	}		"CoAP option If-Match from RFC 7252";
			}
	identity fid-coap-option-content-format {		identity fid-coap-option-uri-host {
	base field-id-base-type;		base fid-coap-base-type;
	description "CoAP option Content Format from RFC 7252";		description
	}		"CoAP option URI-Host from RFC 7252";
			}
	identity fid-coap-option-max-age {		identity fid-coap-option-etag {
	base field-id-base-type;		base fid-coap-base-type;
	description "CoAP option Max-Age from RFC 7252";		description
	}		"CoAP option Etag from RFC 7252";
			}
	identity fid-coap-option-uri-query {		identity fid-coap-option-if-none-match {
	base field-id-base-type;		base fid-coap-base-type;
	description "CoAP option Uri-Query from RFC 7252";		description
	}		"CoAP option if-none-match from RFC 7252";
			}
	identity fid-coap-option-accept {		identity fid-coap-option-observe {
	base field-id-base-type;		base fid-coap-base-type;
	description "CoAP option Max-Age from RFC 7252";		description
	}		"CoAP option Observe from RFC 7641";
			}
	identity fid-coap-option-location-query {		identity fid-coap-option-uri-port {
	base field-id-base-type;		base fid-coap-base-type;
	description "CoAP option Location-Query from RFC 7252";		description
	}		"CoAP option Uri-Port from RFC 7252";
			}
	identity fid-coap-option-block2 {		identity fid-coap-option-location-path {
	base field-id-base-type;		base fid-coap-base-type;
	description "CoAP option Block2 from RFC 7959";		description
	}		"CoAP option Location-Path from RFC 7252";
			}
	identity fid-coap-option-block1 {		identity fid-coap-option-uri-path {
	base field-id-base-type;		base fid-coap-base-type;
	description "CoAP option Block1 from RFC 7959";		description
	}		"CoAP option Uri-Path from RFC 7252";
			}
	identity fid-coap-option-size2 {		identity fid-coap-option-content-format {
	base field-id-base-type;		base fid-coap-base-type;
	description "CoAP option size2 from RFC 7959";		description
	}		"CoAP option Content Format from RFC 7252";
			}
	identity fid-coap-option-proxy-uri {		identity fid-coap-option-max-age {
	base field-id-base-type;		base fid-coap-base-type;
	description "CoAP option Proxy-Uri from RFC 7252";		description
	}		"CoAP option Max-Age from RFC 7252";
	identity fid-coap-option-proxy-scheme {		}
	base field-id-base-type;
	description "CoAP option Proxy-scheme from RFC 7252";
	}
	identity fid-coap-option-size1 {		identity fid-coap-option-uri-query {
	base field-id-base-type;		base fid-coap-base-type;
	description "CoAP option Size1 from RFC 7252";		description
	}		"CoAP option Uri-Query from RFC 7252";
			}
	identity fid-coap-option-no-response {		identity fid-coap-option-accept {
	base field-id-base-type;		base fid-coap-base-type;
	description "CoAP option No response from RFC 7967";		description
	}		"CoAP option Accept from RFC 7252";
			}
	identity fid-coap-option-oscore-flags {		identity fid-coap-option-location-query {
	base field-id-base-type;		base fid-coap-base-type;
	description "CoAP option oscore flags (see draft schc coap, section 6.4)";		description
	}		"CoAP option Location-Query from RFC 7252";
			}
	identity fid-coap-option-oscore-piv {		identity fid-coap-option-block2 {
	base field-id-base-type;		base fid-coap-base-type;
	description "CoAP option oscore flags (see draft schc coap, section 6.4)";		description
	}		"CoAP option Block2 from RFC 7959";
			}
	identity fid-coap-option-oscore-kid {		identity fid-coap-option-block1 {
	base field-id-base-type;		base fid-coap-base-type;
	description "CoAP option oscore flags (see draft schc coap, section 6.4)";		description
	}		"CoAP option Block1 from RFC 7959";
			}
	identity fid-coap-option-oscore-kidctx {		identity fid-coap-option-size2 {
	base field-id-base-type;		base fid-coap-base-type;
	description "CoAP option oscore flags (see draft schc coap, section 6.4)";		description
	}		"CoAP option size2 from RFC 7959";
			}
	identity fid-icmpv6-type {		identity fid-coap-option-proxy-uri {
	base field-id-base-type;		base fid-coap-base-type;
	description "ICMPv6 field (see draft OAM)";		description
	}		"CoAP option Proxy-Uri from RFC 7252";
			}
	identity fid-icmpv6-code {		identity fid-coap-option-proxy-scheme {
	base field-id-base-type;		base fid-coap-base-type;
	description "ICMPv6 field (see draft OAM)";		description
	}		"CoAP option Proxy-scheme from RFC 7252";
			}
	identity fid-icmpv6-checksum {		identity fid-coap-option-size1 {
	base field-id-base-type;		base fid-coap-base-type;
	description "ICMPv6 field (see draft OAM)";		description
			"CoAP option Size1 from RFC 7252";
			}
	}		identity fid-coap-option-no-response {
			base fid-coap-base-type;
			description
			"CoAP option No response from RFC 7967";
			}
	identity fid-icmpv6-identifier {		identity fid-coap-option-oscore-flags {
	base field-id-base-type;		base fid-coap-base-type;
	description "ICMPv6 field (see draft OAM)";		description
	}		"CoAP option oscore flags (see RFC 8824, section 6.4)";
			}
	identity fid-icmpv6-sequence {		identity fid-coap-option-oscore-piv {
	base field-id-base-type;		base fid-coap-base-type;
	description "ICMPv6 field (see draft OAM)";		description
	}		"CoAP option oscore flags (see RFC 8824, section 6.4)";
			}
	/// !!!!!!! See future CoAP extentions		identity fid-coap-option-oscore-kid {
			base fid-coap-base-type;
			description
			"CoAP option oscore flags (see RFC 8824, section 6.4)";
			}
	//----------------------------------		identity fid-coap-option-oscore-kidctx {
	// Field Length type definition		base fid-coap-base-type;
	//----------------------------------		description
			"CoAP option oscore flags (see RFC 8824, section 6.4)";
			}
	identity field-length-base-type {		//----------------------------------
	description "used to extend field length functions";		// Field Length type definition
			//----------------------------------
			identity fl-base-type {
			description
			"Used to extend field length functions.";
	}		}
	identity fl-variable {		identity fl-variable {
	base field-length-base-type;		base fl-base-type;
	description "residue length in Byte is sent";		description
			"Residue length in Byte is sent as defined
			for CoAP in RFC 8824 (cf. 5.3).";
	}		}
	identity fl-token-length {		identity fl-token-length {
	base field-length-base-type;		base fl-base-type;
	description "residue length in Byte is sent";		description
			"Residue length in Byte is sent as defined
			for CoAP in RFC 8824 (cf. 4.5).";
	}		}
	//---------------------------------		//---------------------------------
	// Direction Indicator type		// Direction Indicator type
	//---------------------------------		//---------------------------------
	identity direction-indicator-base-type {		identity di-base-type {
	description "used to extend field length functions";		description
			"Used to extend direction indicators.";
	}		}
	identity di-bidirectional {		identity di-bidirectional {
	base direction-indicator-base-type;		base di-base-type;
	description "Direction Indication of bi directionality";		description
			"Direction Indication of bidirectionality in
			RFC 8724 (cf. 7.1).";
	}		}
	identity di-up {		identity di-up {
	base direction-indicator-base-type;		base di-base-type;
	description "Direction Indication of upstream";		description
			"Direction Indication of uplink defined in
			RFC 8724 (cf. 7.1).";
	}		}
	identity di-down {		identity di-down {
	base direction-indicator-base-type;		base di-base-type;
	description "Direction Indication of downstream";		description
			"Direction Indication of downlink defined in
			RFC 8724 (cf. 7.1).";
	}		}
	//----------------------------------		//----------------------------------
	// Matching Operator type definition		// Matching Operator type definition
	//----------------------------------		//----------------------------------
	identity matching-operator-base-type {
	description "used to extend Matching Operators with SID values";
	}
	identity mo-equal {
	base matching-operator-base-type;
	description "RFC 8724";
	}
	identity mo-ignore {		identity mo-base-type {
	base matching-operator-base-type;		description
	description "RFC 8724";		"Used to extend Matching Operators with SID values";
	}		}
	identity mo-msb {		identity mo-equal {
	base matching-operator-base-type;		base mo-base-type;
	description "RFC 8724";		description
	}		"Equal MO as defined in RFC 8724 (cf. 7.3)";
			}
			identity mo-ignore {
			base mo-base-type;
			description
			"Ignore MO as defined in RFC 8724 (cf. 7.3)";
			}
	identity mo-matching {		identity mo-msb {
	base matching-operator-base-type;		base mo-base-type;
	description "RFC 8724";		description
	}		"MSB MO as defined in RFC 8724 (cf. 7.3)";
			}
	//------------------------------		identity mo-match-mapping {
	// CDA type definition		base mo-base-type;
	//------------------------------		description
			"match-mapping MO as defined in RFC 8724 (cf. 7.3)";
			}
	identity compression-decompression-action-base-type;		//------------------------------
			// CDA type definition
			//------------------------------
	identity cda-not-sent {		identity cda-base-type {
	base compression-decompression-action-base-type;		description
	description "RFC 8724";		"Compression Decompression Actions.";
	}		}
	identity cda-value-sent {		identity cda-not-sent {
	base compression-decompression-action-base-type;		base cda-base-type;
	description "RFC 8724";		description
	}		"not-sent CDA as defined in RFC 8724 (cf. 7.4).";
			}
	identity cda-lsb {		identity cda-value-sent {
	base compression-decompression-action-base-type;		base cda-base-type;
	description "RFC 8724";		description
	}		"value-sent CDA as defined in RFC 8724 (cf. 7.4).";
			}
	identity cda-mapping-sent {		identity cda-lsb {
	base compression-decompression-action-base-type;		base cda-base-type;
	description "RFC 8724";		description
	}		"LSB CDA as defined in RFC 8724 (cf. 7.4).";
			}
	identity cda-compute-length {		identity cda-mapping-sent {
	base compression-decompression-action-base-type;		base cda-base-type;
	description "RFC 8724";		description
	}		"mapping-sent CDA as defined in RFC 8724 (cf. 7.4).";
			}
	identity cda-compute-checksum {		identity cda-compute {
	base compression-decompression-action-base-type;		base cda-base-type;
	description "RFC 8724";		description
	}		"compute-length CDA as defined in RFC 8724 (cf. 7.4)";
			}
	identity cda-deviid {		identity cda-deviid {
	base compression-decompression-action-base-type;		base cda-base-type;
	description "RFC 8724";		description
	}		"deviid CDA as defined in RFC 8724 (cf. 7.4)";
			}
	identity cda-appiid {		identity cda-appiid {
	base compression-decompression-action-base-type;		base cda-base-type;
	description "RFC 8724";		description
	}		"appiid CDA as defined in RFC 8724 (cf. 7.4)";
			}
	// -- type definition		// -- type definition
	typedef field-id-type {		typedef fid-type {
	description "Field ID generic type.";		type identityref {
	type identityref {		base fid-base-type;
	base field-id-base-type;
	}
	}		}
			description
			"Field ID generic type.";
			}
	typedef field-length-type {		typedef fl-type {
	description "Field length either a positive integer giving the size in bits		type union {
	or a function defined through an identityref.";		type int64; /* positive integer, expressing length in bits */
	type union {		type identityref { /* function */
	type int64; /* positive length in bits */		base fl-base-type;
	type identityref { /* function */		}
	base field-length-base-type;
	}
	}
	}		}
			description
			"Field length either a positive integer expressing the size in
			bits or a function defined through an identityref.";
			}
	typedef direction-indicator-type {		typedef di-type {
	description "direction in LPWAN network, up when emitted by the device,		type identityref {
	down when received by the device, bi when emitted or received by the device.";		base di-base-type;
	type identityref {
	base direction-indicator-base-type;
	}
	}		}
			description
			"Direction in LPWAN network, up when emitted by the device,
			down when received by the device, bi when emitted or
			received by the device.";
			}
	typedef matching-operator-type {		typedef mo-type {
	description "Matching Operator (MO) to compare fields values with target values";		type identityref {
	type identityref {		base mo-base-type;
	base matching-operator-base-type;
	}
	}		}
			description
			"Matching Operator (MO) to compare fields values with
			target values";
			}
	typedef comp-decomp-action-type {		typedef cda-type {
	description "Compression Decompression Action to compression or decompress a field.";		type identityref {
	type identityref {		base cda-base-type;
	base compression-decompression-action-base-type;
	}
	}		}
			description
			"Compression Decompression Action to compression or
			decompress a field.";
			}
	// -- FRAGMENTATION TYPE		// -- FRAGMENTATION TYPE
			// -- fragmentation modes
	// -- fragmentation modes
	identity fragmentation-mode-base-type {		identity fragmentation-mode-base-type {
	description "fragmentation mode";		description
	}		"fragmentation mode.";
			}
	identity fragmentation-mode-no-ack {		identity fragmentation-mode-no-ack {
	description "No Ack of RFC 8724.";		base fragmentation-mode-base-type;
	base fragmentation-mode-base-type;		description
	}		"No-ACK of RFC8724.";
			}
	identity fragmentation-mode-ack-always {		identity fragmentation-mode-ack-always {
	description "Ack Always of RFC8724.";		base fragmentation-mode-base-type;
	base fragmentation-mode-base-type;		description
	}		"ACK-Always of RFC8724.";
	identity fragmentation-mode-ack-on-error {		}
	description "Ack on Error of RFC8724.";
	base fragmentation-mode-base-type;
			identity fragmentation-mode-ack-on-error {
			base fragmentation-mode-base-type;
			description
			"ACK-on-Error of RFC8724.";
			}
			typedef fragmentation-mode-type {
			type identityref {
			base fragmentation-mode-base-type;
	}		}
			description
			"type used in rules";
			}
	typedef fragmentation-mode-type {		// -- Ack behavior
	type identityref {
	base fragmentation-mode-base-type;
	}
	}
	// -- Ack behavior		identity ack-behavior-base-type {
			description
			"Define when to send an Acknowledgment .";
			}
	identity ack-behavior-base-type {		identity ack-behavior-after-All0 {
	description "define when to send an Acknowledgment message";		base ack-behavior-base-type;
	}		description
			"Fragmentation expects Ack after sending All0 fragment.";
			}
	identity ack-behavior-after-All0 {		identity ack-behavior-after-All1 {
	description "fragmentation expects Ack after sending All0 fragment.";		base ack-behavior-base-type;
	base ack-behavior-base-type;		description
	}		"Fragmentation expects Ack after sending All1 fragment.";
			}
	identity ack-behavior-after-All1 {		identity ack-behavior-by-layer2 {
	description "fragmentation expects Ack after sending All1 fragment.";		base ack-behavior-base-type;
	base ack-behavior-base-type;		description
	}		"Layer 2 defines when to send an Ack.";
			}
	identity ack-behavior-always {		typedef ack-behavior-type {
	description "fragmentation expects Ack after sending every fragment.";		type identityref {
	base ack-behavior-base-type;		base ack-behavior-base-type;
	}		}
			description
			"Type used in rules.";
			}
	typedef ack-behavior-type {		// -- All1 with data types
	type identityref {
	base ack-behavior-base-type;
	}
	}
	// -- All1 with data types		identity all1-data-base-type {
			description
			"Type to define when to send an Acknowledgment message.";
			}
			identity all1-data-no {
			base all1-data-base-type;
			description
			"All1 contains no tiles.";
			}
	identity all1-data-base-type {		identity all1-data-yes {
	description "type to define when to send an Acknowledgment message";		base all1-data-base-type;
	}		description
			"All1 MUST contain a tile.";
			}
	identity all1-data-no {		identity all1-data-sender-choice {
	description "All1 contains no tiles.";		base all1-data-base-type;
	base all1-data-base-type;		description
	}		"Fragmentation process chooses to send tiles or not in all1.";
			}
	identity all1-data-yes {		typedef all1-data-type {
	description "All1 MUST contain a tile";		type identityref {
	base all1-data-base-type;		base all1-data-base-type;
	}		}
			description
			"Type used in rules.";
			}
	identity all1-data-sender-choice {		// -- RCS algorithm types
	description "Fragmentation process choose to send tiles or not in all1.";
	base all1-data-base-type;
	}
	typedef all1-data-type {		identity rcs-algorithm-base-type {
	type identityref {		description
	base all1-data-base-type;		"Identify which algorithm is used to compute RCS.
	}		The algorithm also defines the size of the RCS field.";
	}		}
	// -- RCS algorithm types		identity rcs-RFC8724 {
			base rcs-algorithm-base-type;
			description
			"CRC 32 defined as default RCS in RFC8724. RCS is 4 byte-long";
			}
	identity RCS-algorithm-base-type {		typedef rcs-algorithm-type {
	description "identify which algorithm is used to compute RSC.		type identityref {
	The algorithm defines also the size if the RSC field.";		base rcs-algorithm-base-type;
	}		}
			description
			"type used in rules.";
			}
			// --------- TIMER DURATION -------------------
	identity RFC8724-RCS {		grouping timer-duration {
	description "CRC 32 defined as default RCS in RFC8724.";		leaf ticks-duration {
	base RCS-algorithm-base-type;		type uint8;
			default 20;
			description "duration of one tick in micro-seconds, 2^ticks-duration/10^6 = 1.048s";
	}		}
			leaf ticks-numbers {
	typedef RCS-algorithm-type {		type uint16;
	type identityref {		description "timer duration = ticks-numbers * 2^ticks / 10^6";
	base RCS-algorithm-base-type;
	}
	}		}
			}
	// -------- RULE ENTRY DEFINITION ------------		// -------- RULE ENTRY DEFINITION ------------
	grouping target-values-struct {
	description "defines the target value element. Can be either an arbitrary
	binary or ascii element. All target values are considered as a matching lists.
	Position is used to order values, by default position 0 is used when containing
	a single element.";
	leaf value {		grouping tv-struct {
	type union {		description
	type binary;		"Defines the target value element. Always a binary type, strings
	type string;		must be converted to binary. field-id allows the conversion
	}		to the appropriate type.";
	}		leaf value {
	leaf position {		type binary;
	description "If only one element position is 0, otherwise position is the		description
	matching list.";		"Target Value";
	type uint16;
	}
	}		}
			leaf indicia {
			type uint16;
			description
			"Indicia gives the position in the matching-list. If only one
			element is present, indicia is 0. Otherwise, indicia is the
			the order in the matching list, starting at 0.";
			}
			}
	grouping compression-rule-entry {		grouping compression-rule-entry {
	description "These entries defines a compression entry (i.e. a line)		description
	as defined in RFC 8724 and fragmentation parameters.		"These entries defines a compression entry (i.e. a line)
			as defined in RFC 8724.
	+-------+--+--+--+------------+-----------------+---------------+
	|Field 1|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|
	+-------+--+--+--+------------+-----------------+---------------+
	An entry in a compression rule is composed of 7 elements:		+-------+--+--+--+------------+-----------------+---------------+
	- Field ID: The header field to be compressed. The content is a YANG identifer.		|Field 1|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|
	- Field Length : either a positive integer of a function defined as a YANF id.		+-------+--+--+--+------------+-----------------+---------------+
	- Field Position: a positive (and possibly equal to 0) integer.
	- Direction Indicator: a YANG identifier giving the direction.
	- Target value: a value against which the header Field is compared.
	- Matching Operator: a YANG id giving the operation, paramters may be
	associated to that operator.
	- Comp./Decomp. Action: A YANG id giving the compression or decompression
	action, paramters may be associated to that action.
	";
	leaf field-id {		An entry in a compression rule is composed of 7 elements:
	description "Field ID, identify a field in the header with a YANG refenceid.";		- Field ID: The header field to be compressed. The content is a
	mandatory true;		YANG identifer.
	type schc:field-id-type;		- Field Length : either a positive integer of a function defined
	}		as a YANG id.
	leaf field-length {		- Field Position: a positive (and possibly equal to 0) integer.
	description "Field Length in bit or through a function defined as a YANG referenceid";		- Direction Indicator: a YANG identifier giving the direction.
	mandatory true;		- Target value: a value against which the header Field is
	type schc:field-length-type;		compared.
	}		- Matching Operator: a YANG id giving the operation, parameters
	leaf field-position {		may be associated to that operator.
	description "field position in the header is a integer. If the field is not repeated		- Comp./Decomp. Action: A YANG id giving the compression or
	in the header the value is 1, and incremented for each repetition of the field. Position		decompression action, parameters may be associated to that
	0 means that the position is not important and order may change when decompressed";		action.
	mandatory true;		";
	type uint8;		leaf field-id {
	}		type schc:fid-type;
	leaf direction-indicator {		mandatory true;
	description "Direction Indicator, a YANG referenceid to say if the packet is bidirectionnal,		description
	up or down";		"Field ID, identify a field in the header with a YANG
	mandatory true;		referenceid.";
	type schc:direction-indicator-type;
	}
	list target-values {
	description "a list of value to compare with the header field value. If target value
	is a singleton, position must be 0. For matching-list, should be consecutive position
	values starting from 1.";
	key position;
	uses target-values-struct;
	}
	leaf matching-operator {
	mandatory true;
	type schc:matching-operator-type;
	}
	list matching-operator-value {
	key position;
	uses target-values-struct;
	}
	leaf comp-decomp-action {
	mandatory true;
	type schc:comp-decomp-action-type;
	}
	list comp-decomp-action-value {
	key position;
	uses target-values-struct;
	}
	}		}
			leaf field-length {
	grouping compression-content {		type schc:fl-type;
	description "define a compression rule composed of a list of entries.";		mandatory true;
	list entry {		description
	key "field-id field-position direction-indicator";		"Field Length, expressed in number of bits or through a function defined as a
	uses compression-rule-entry;		YANG referenceid.";
	}
	}		}
			leaf field-position {
			type uint8;
			mandatory true;
			description
			"Field position in the header is an integer. Position 1 matches
			the first occurence of a field in the header, while incremented
			position values match subsequent occurences.
			Position 0 means that this entry matches a field irrespective
			of its position of occurence in the header.
			Be aware that the decompressed header may have position-0
			fields ordered differently than they appeared in the original
			packet.";
			}
			leaf direction-indicator {
			type schc:di-type;
			mandatory true;
			description
			"Direction Indicator, a YANG referenceid to say if the packet
			is bidirectional, up or down";
			}
			list target-value {
			key "indicia";
			uses tv-struct;
			description
			"A list of value to compare with the header field value.
			If target value is a singleton, position must be 0.
			For use as a matching list for the mo-match-mapping matching
			operator, positions should take consecutive values starting
			from 1.";
			}
			leaf matching-operator {
			type schc:mo-type;
			must "../target-value or derived-from-or-self(., 'mo-ignore')" {
			error-message
			"mo-equal, mo-msb and mo-match-mapping need target-value";
			description
			"target-value is not required for mo-ignore";
			}
			must "not (derived-from-or-self(., 'mo-msb')) or
			../matching-operator-value" {
			error-message "mo-msb requires length value";
			}
			mandatory true;
			description
			"MO: Matching Operator";
			}
			list matching-operator-value {
			key "indicia";
			uses tv-struct;
			description
			"Matching Operator Arguments, based on TV structure to allow
			several arguments.
			In RFC 8724, only the MSB matching operator needs arguments (a single argument, which is the
			number of most significant bits to be matched)";
			}
			leaf comp-decomp-action {
			type schc:cda-type;
			mandatory true;
			description
			"CDA: Compression Decompression Action.";
			}
			list comp-decomp-action-value {
			key "indicia";
			uses tv-struct;
			description
			"CDA arguments, based on a TV structure, in order to allow for
			several arguments. The CDAs specified in RFC 8724 require no
			argument.";
			}
			}
			grouping compression-content {
			list entry {
			key "field-id field-position direction-indicator";
			uses compression-rule-entry;
			description
			"A compression rule is a list of rule entries, each describing
			a header field. An entry is identifed through a field-id,
			its position in the packet and its direction.";
			}
			description
			"Define a compression rule composed of a list of entries.";
			}
	grouping fragmentation-content {		grouping fragmentation-content {
	description "This grouping defines the fragmentation parameters for		description
	all the modes (No Ack, Ack Always and Ack on Error) specified in		"This grouping defines the fragmentation parameters for
	RFC 8724.";		all the modes (No-Ack, Ack-Always and Ack-on-Error) specified in
			RFC 8724.";
	leaf direction {		leaf fragmentation-mode {
	type schc:direction-indicator-type;		type schc:fragmentation-mode-type;
	description "should be up or down, bi directionnal is forbiden.";		mandatory true;
	mandatory true;		description
	}		"which fragmentation mode is used (noAck, AckAlways,
	leaf dtagsize {		AckonError)";
	type uint8;		}
	description "size in bit of the DTag field";		leaf l2-word-size {
			type uint8;
	}		default "8";
	leaf wsize {		description
	type uint8;		"Size, in bits, of the layer 2 word";
	description "size in bit of the window field";		}
	}		leaf direction {
	leaf fcnsize {		type schc:di-type;
	type uint8;		must "derived-from-or-self(., 'di-up') or
	description "size in bit of the FCN field";		derived-from-or-self(., 'di-down')" {
	mandatory true;		error-message
	}		"direction for fragmentation rules are up or down.";
	leaf RCS-algorithm {		}
	type RCS-algorithm-type;		mandatory true;
	default schc:RFC8724-RCS;		description
	description "Algoritm used for RCS";		"Should be up or down, bidirectionnal is forbiden.";
	}		}
	leaf maximum-window-size {		// SCHC Frag header format
	type uint16;		leaf dtag-size {
	description "by default 2^wsize - 1";		type uint8;
	}		default "0";
			description
	leaf retransmission-timer {		"Size, in bits, of the DTag field (T variable from RFC8724).";
	type uint64 {
	range 1..max;
	}
	description "duration in seconds of the retransmission timer"; // Check the units
	}
	leaf inactivity-timer {
	type uint64;
	description "duration is seconds of the inactivity timer, 0 indicates the timer is disabled"; // check units
	}
	leaf max-ack-requests {		}
	type uint8 {		leaf w-size {
	range 1..max;		when "derived-from(../fragmentation-mode,
	}		'fragmentation-mode-ack-on-error')
	description "the maximum number of retries for a specific SCHC ACK.";		or
			derived-from(../fragmentation-mode,
			'fragmentation-mode-ack-always') ";
			type uint8;
			description
			"Size, in bits, of the window field (M variable from RFC8724).";
			}
			leaf fcn-size {
			type uint8;
			mandatory true;
			description
			"Size, in bits, of the FCN field (N variable from RFC8724).";
			}
			leaf rcs-algorithm {
			type rcs-algorithm-type;
			default "schc:rcs-RFC8724";
			description
			"Algorithm used for RCS. The algorithm specifies the RCS size";
			}
			// SCHC fragmentation protocol parameters
			leaf maximum-packet-size {
			type uint16;
			default "1280";
			description
			"When decompression is done, packet size must not
			strictly exceed this limit, expressed in bytes.";
			}
			leaf window-size {
			type uint16;
			description
			"By default, if not specified 2^w-size - 1. Should not exceed
			this value. Possible FCN values are between 0 and
			window-size - 1.";
			}
			leaf max-interleaved-frames {
			type uint8;
			default "1";
			description
			"Maximum of simultaneously fragmented frames. Maximum value is
			2^dtag-size. All DTAG values can be used, but at most
			max-interleaved-frames must be active at any time.";
			}
			container inactivity-timer {
			uses timer-duration;
			description
			"Duration is seconds of the inactivity timer, 0 indicates
			that the timer is disabled.";
			}
			container retransmission-timer {
			uses timer-duration;
			when "derived-from(../fragmentation-mode,
			'fragmentation-mode-ack-on-error')
			or
			derived-from(../fragmentation-mode,
			'fragmentation-mode-ack-always') ";
			description
			"Duration in seconds of the retransmission timer.";
			}
			leaf max-ack-requests {
			when "derived-from(../fragmentation-mode,
			'fragmentation-mode-ack-on-error')
			or
			derived-from(../fragmentation-mode,
			'fragmentation-mode-ack-always') ";
			type uint8 {
			range "1..max";
			}
			description
			"The maximum number of retries for a specific SCHC ACK.";
			}
			choice mode {
			case no-ack;
			case ack-always;
			case ack-on-error {
			leaf tile-size {
			when "derived-from(../fragmentation-mode,
			'fragmentation-mode-ack-on-error')";
			type uint8;
			description
			"Size, in bits, of tiles. If not specified or set to 0,
			tiles fill the fragment.";
	}		}
			leaf tile-in-All1 {
	leaf maximum-packet-size {		when "derived-from(../fragmentation-mode,
	type uint16;		'fragmentation-mode-ack-on-error')";
	default 1280;		type schc:all1-data-type;
	description "When decompression is done, packet size must not strictly exceed this limit in Bytes";		description
			"Defines whether the sender and receiver expect a tile in
			All-1 fragments or not, or if it is left to the sender's
			choice.";
	}		}
			leaf ack-behavior {
	leaf fragmentation-mode {		when "derived-from(../fragmentation-mode,
	type schc:fragmentation-mode-type;		'fragmentation-mode-ack-on-error')";
	description "which fragmentation mode is used (noAck, AckAlways, AckonError)";		type schc:ack-behavior-type;
	mandatory true;		description
			"Sender behavior to acknowledge, after All-0, All-1 or
			when the LPWAN allows it.";
	}		}
			}
	choice mode {		description
	case no-ack;		"RFC 8724 defines 3 fragmentation modes.";
	case ack-always;
	case ack-on-error {
	leaf tile-size {
	type uint8;
	description "size in bit of tiles, if not specified or set to 0: tile fills the fragment.";
	}
	leaf tile-in-All1 {
	type schc:all1-data-type;
	description "When true, sender and receiver except a tile in All-1 frag";
	}
	leaf ack-behavior {
	type schc:ack-behavior-type;
	description "Sender behavior to acknowledge, after All-0, All-1 or when the
	LPWAN allows it (Always)";
	}
	}
	}
	}		}
			}
	// Define rule ID. Rule ID is composed of a RuleID value and a Rule ID Length		// Define rule ID. Rule ID is composed of a RuleID value and a
			// Rule ID Length
	grouping rule-id-type {		grouping rule-id-type {
	leaf rule-id {		leaf rule-id-value {
	type uint32;		type uint32;
	description "rule ID value, this value must be unique combined with the length";		description
	}		"Rule ID value, this value must be unique, considering its
	leaf rule-length {		length.";
	type uint8 {
	range 0..32;
	}
	description "rule ID length in bits, value 0 is for implicit rules";
	}
	}		}
			leaf rule-id-length {
			type uint8 {
			range "0..32";
			}
			description
			"Rule ID length, in bits. The value 0 is for implicit rules.";
			}
			description
			"A rule ID is composed of a value and a length, expressed in
			bits.";
			}
	// SCHC table for a specific device.		// SCHC table for a specific device.
	container schc {
	leaf version{
	type uint64;
	mandatory false;
	description "used as an indication for versioning";
			container schc {
			list rule {
			key "rule-id-value rule-id-length";
			uses rule-id-type;
			choice nature {
			case fragmentation {
			if-feature "fragmentation";
			uses fragmentation-content;
	}		}
	list rule {		case compression {
	key "rule-id rule-length";		if-feature "compression";
	uses rule-id-type;		uses compression-content;
	choice nature {
	case fragmentation {
	uses fragmentation-content;
	}
	case compression {
	uses compression-content;
	}
	}
	}		}
			case no-compression {
			description
			"RFC8724 requires a rule for uncompressed headers.";
			}
			description
			"A rule is for compression, for no-compression or for
			fragmentation.";
			}
			description
			"Set of rules compression, no compression or fragmentation
			rules identified by their rule-id.";
	}		}
			description
			"a SCHC set of rules is composed of a list of rules which are
			used for compression, no-compression or fragmentation.";
			}
	}		}
	<code ends>		<code ends>
	Figure 23		Figure 26
	8. Normative References		8. Normative References
	[I-D.barthel-lpwan-oam-schc]
	Barthel, D., Toutain, L., Kandasamy, A., Dujovne, D., and
	J. Zuniga, "OAM for LPWAN using Static Context Header
	Compression (SCHC)", draft-barthel-lpwan-oam-schc-02 (work
	in progress), November 2020.
	[I-D.ietf-lpwan-coap-static-context-hc]
	Minaburo, A., Toutain, L., and R. Andreasen, "LPWAN Static
	Context Header Compression (SCHC) for CoAP", draft-ietf-
	lpwan-coap-static-context-hc-18 (work in progress),
	January 2021.
	[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
	Application Protocol (CoAP)", RFC 7252,
	DOI 10.17487/RFC7252, June 2014,
	<https://www.rfc-editor.org/info/rfc7252>.
	[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>.
	Authors' Addresses		[RFC8824] Minaburo, A., Toutain, L., and R. Andreasen, "Static
			Context Header Compression (SCHC) for the Constrained
			Application Protocol (CoAP)", RFC 8824,
			DOI 10.17487/RFC8824, June 2021,
			<https://www.rfc-editor.org/info/rfc8824>.
			[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>.
			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
End of changes. 338 change blocks.
	1311 lines changed or deleted		1943 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/