lpwan Working Group                                          A. Minaburo
Internet-Draft                                                    Acklio
Intended status: Standards Track                              L. Toutain
Expires: August 6, 2021 13 March 2022            Institut MINES TELECOM; IMT Atlantique
                                                       February 02,
                                                        9 September 2021

        Data Model for Static Context Header Compression (SCHC)
                draft-ietf-lpwan-schc-yang-data-model-04
                draft-ietf-lpwan-schc-yang-data-model-05

Abstract

   This document describes a YANG data model for the SCHC (Static
   Context Header Compression) compression and fragmentation rules.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on August 6, 2021. 13 March 2022.

Copyright Notice

   Copyright (c) 2021 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Simplified BSD License text
   as described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  SCHC rules  . . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.1.  Compression Rules . . . . . . . . . . . . . . . . . . . .   3
     2.2.  Identifier generation . . . . . . . . . . . . . . . . . .   4
     2.3.  Field Identifier  . . . . . . . . . . . . . . . . . . . .   3
     2.3.   5
     2.4.  Field length  . . . . . . . . . . . . . . . . . . . . . .   5
     2.4.   7
     2.5.  Field position  . . . . . . . . . . . . . . . . . . . . .   6
     2.5.   8
     2.6.  Direction Indicator . . . . . . . . . . . . . . . . . . .   6
     2.6.   8
     2.7.  Target Value  . . . . . . . . . . . . . . . . . . . . . .   7
     2.7.   9
     2.8.  Matching Operator . . . . . . . . . . . . . . . . . . . .   8
       2.7.1.  10
       2.8.1.  Matching Operator arguments . . . . . . . . . . . . .   9
     2.8.  11
     2.9.  Compression Decompression Actions . . . . . . . . . . . .  10
       2.8.1.  11
       2.9.1.  Compression Decompression Action arguments  . . . . .  12
   3.  Rule definition
     2.10. Fragmentation rule  . . . . . . . . . . . . . . . . . . .  12
       2.10.1.  Fragmentation mode . . . . . . . . . . . . . . . . .  12
     3.1.  Compression rule
       2.10.2.  Fragmentation Header . . . . . . . . . . . . . . . .  13
       2.10.3.  Last fragment format . . . . . . .  14
       3.1.1.  Compression context representation. . . . . . . . . .  14
       3.1.2.
       2.10.4.  Acknowledgment behavior  . . . . . . . . . . . . . .  16
       2.10.5.  Fragmentation Parameters . . . . . . . . . . . . . .  18
       2.10.6.  Layer 2 parameters . . . . . . . . . . . . . . . . .  19
   3.  Rule definition . . . . . . . . . . . . . . . . . . .  15 . . . .  19
     3.1.  Compression rule  . . . . . . . . . . . . . . . . . . . .  21
     3.2.  Fragmentation rule  . . . . . . . . . . . . . . . . . . .  16  23
     3.3.  YANG Tree . . . . . . . . . . . . . . . . . . . . . . . .  26
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  24  28
   5.  Security considerations . . . . . . . . . . . . . . . . . . .  24  28
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  24  28
   7.  YANG Module . . . . . . . . . . . . . . . . . . . . . . . . .  24  28
   8.  Normative References  . . . . . . . . . . . . . . . . . . . .  41  50
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  42  51

1.  Introduction

2.  SCHC rules

   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 this constrained network.
   Draft [RFC8724] provides an 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:

   o

   *  the same definition on both ends, even if the internal
      representation is different.

   o

   *  an update the other end to set up some specific values (e.g.  IPv6
      prefix, Destination address,...)

   o

   *  ...

   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.

   SCHC compression is generic, the main mechanism do no refers does not refer to a
   specific protocol.  Any header field is abstracted through an ID, a
   position, a direction direction, and a value that can be a numerical value or a
   string.  [RFC8724] and [I-D.ietf-lpwan-coap-static-context-hc] [RFC8824] specifies fields for IPv6, UDP, CoAP
   and OSCORE.  [I-D.barthel-lpwan-oam-schc] decribes describes ICMPv6 header compression.
   compression and [I-D.ietf-lpwan-schc-compound-ack] includes a new
   fragmentation behavior.

   SCHC fragmentation requires a set of common parameters that are
   included in a rule.  These parameters are defined in [RFC8724].

2.1.  Compression Rules

   [RFC8724] proposes an a non formal representation of the compression
   rule.  A compression context for a device is composed of a set of
   rules.  Each rule contains information to describe a specific field
   in the header to be compressed.

     +-----------------------------------------------------------------+
     |                      Rule N                                     |
    +-----------------------------------------------------------------+|
    |                    Rule i                                       ||
   +-----------------------------------------------------------------+||
   |  (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|||
   |+-------+--+--+--+------------+-----------------+---------------+|/
   |                                                                 |
   \-----------------------------------------------------------------/

                Figure 1: Compression Decompression Context

2.2.  Field  Identifier

   In the process of compression, the headers of generation

   Identifier used un the original packet SCHC YANG Data Model are
   first parsed from the identityref
   statement to create ensure to be globally unique and be easily augmented if
   needed.  The principle to define a list new type based on a group of fields.  This list
   identityref is the following:

   *  define a main identity ending with the keyword base-type.

   *  derive all the identity used in the Data Model from this base
      type.

   *  create a typedef from this base type.

   The example (Figure 2) 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 RSC.
          The algorithm also defines the size if the RSC field.";
     }

     identity rcs-RFC8724 {
       base rcs-algorithm-base-type;
       description
         "CRC 32 defined as default RCS in RFC8724.";
     }

     typedef rcs-algorithm-type {
       type identityref {
         base rcs-algorithm-base-type;
       }
       description
         "type used in rules";
     }

         Figure 2: Principle to define a type based on identityref.

2.3.  Field Identifier

   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
   matched against the rules to find the appropriate one and apply
   compression.  The link between the list given by the parsed fields
   and the rules is done through a field ID.  [RFC8724] do not state how
   the field ID value can be constructed.  In examples, identification
   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], and [I-D.barthel-lpwan-oam-schc].

   Using the YANG model, each field MUST be identified through a global
   YANG identityref.  A YANG field ID for the protocol always derives
   from the field-id-base- fid-base-type.  Then an identity for each protocol is
   specified using the naming convention fid-<<protocol name>>-base-
   type.  All possible fields for this protocol MUST derive from the
   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.

   The full field-id definition is found in Section 7.  The example
   Figure 2 3 gives some the first field ID definitions.  Note that some
   field IDs can be splitted is smaller pieces.  This  A type is the case defined for
   "fid-ipv6-trafficclass-ds"
   IPv6 protocol, and "fid-ipv6-trafficclass-ecn" which are
   a subset of "fid-ipv6-trafficclass-ds". each field is based on it.  Note that the DiffServ
   bits derives from the Traffic Class identity.

     identity field-id-base-type fid-base-type {
       description
         "Field ID with SID";
       }

       identity fid-ipv6-version { base field-id-base-type;
              description "IPv6 version field from RFC8200"; type for all fields";
     }

     identity fid-ipv6-trafficclass fid-ipv6-base-type {
       base field-id-base-type; fid-base-type;
       description "IPv6 Traffic Class
         "Field IP base type for IPv6 headers described in RFC 8200";
     }

     identity fid-ipv6-version {
       base fid-ipv6-base-type;
       description
         "IPv6 version field from RFC8200";
     }

     identity fid-ipv6-trafficclass-ds fid-ipv6-trafficclass {
       base field-id-base-type; fid-ipv6-base-type;
       description
         "IPv6 Traffic Class field from RFC8200,
          DiffServ field from RFC3168"; RFC8200";
     }

     identity fid-ipv6-trafficclass-ecn fid-ipv6-trafficclass-ds {
       base field-id-base-type; fid-ipv6-trafficclass;
       description
         "IPv6 Traffic Class field from RFC8200,
          ECN
          DiffServ field from RFC3168";
     }

     ...

             Figure 2: 3: 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 fid-type (cf.  Figure 3) 4)

     typedef field-id-type fid-type {
           description "Field ID generic type.";
       type identityref {
         base field-id-base-type; fid-base-type;
       }
       description
         "Field ID generic type.";
     }

                  Figure 3: 4: Type definition for field IDs

2.3.

2.4.  Field length

   Field length is either an integer giving the size of a field in bits
   or a specific function.  [RFC8724] defines the "var" function which
   allows variable length fields in byte and
   [I-D.ietf-lpwan-coap-static-context-hc] [RFC8824] defines the "tkl"
   function for managing the CoAP Token length field.

   The naming convention is "fl" followed by the function name.

     identity field-length-base-type fl-base-type {
       description "used
         "Used to extend field length functions";
     }

     identity fl-variable {
       base field-length-base-type; fl-base-type;
       description "residue
         "Residue length in Byte is sent"; sent defined in
         for CoAP in RFC 8824 (cf. 5.3)";
     }

     identity fl-token-length {
       base field-length-base-type; fl-base-type;
       description "residue
         "Residue length in Byte is sent"; sent defined in
         for CoAP in RFC 8824 (cf. 4.5)";
     }

            Figure 4: 5: Definition of identityref for field ILength Field Length

   As for field ID, field length function can be defined as a an
   identityref as shown in Figure 4.

   Therefore 5.

   Therefore, the type for field length is a union between an integer
   giving in bits the size of the length and the identityref (cf.
   Figure 5). 6).

     typedef field-length-type fl-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; fl-base-type;
         }
       }
       description
         "Field length either a positive integer giving the size in bits
          or a function defined through an identityref.";
     }
                 Figure 5: 6: Type definition for field Length

   The naming convention is fl followed by the function name as defined
   in SCHC specifications.

2.4.

2.5.  Field position

   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
   times, the value is higher.  value 0 indicates that the position is
   not important and is not taken into account considered during the rule selection
   process.

   Field position is a positive integer.  The type is an uint8.

2.5.

2.6.  Direction Indicator

   The Direction Indicator (DI) (di) is used to tell if a field appears in
   both direction (Bi) or only uplink (Up) or Downlink (Dw).

     identity direction-indicator-base-type di-base-type {
       description "used
         "Used to extend field length functions";
     }

     identity di-bidirectional {
       base direction-indicator-base-type; di-base-type;
       description
         "Direction Indication of bi directionality"; directionality in
         RFC 8724 (cf. 7.1)";
     }

     identity di-up {
       base direction-indicator-base-type; di-base-type;
       description
         "Direction Indication of upstream"; upstream defined in
         RFC 8724 (cf. 7.1)";
     }

     identity di-down {
       base direction-indicator-base-type; di-base-type;
       description
         "Direction Indication of downstream"; downstream defined in
         RFC 8724 (cf. 7.1)";
     }

        Figure 6: 7: Definition of identityref for direction indicators

   Figure 6 7 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). 8).

  typedef direction-indicator-type di-type {
    type identityref {
      base di-base-type;
    }
    description "direction
      "Direction in LPWAN network, up when emitted by the device,
       down when received by the device, bi when emitted or received by the device.";
        type identityref {
            base direction-indicator-base-type;
        }
  }

          Figure 7: 8: Type definition for direction indicators

2.6.

2.7.  Target Value

   The Target Value may be either is a string or list of binary sequence.  For match-
   mapping, several sequences of these values can be contained in a Target Value
   field.  In any length, aligned
   on the left.  Figure 9 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 for LSB CDA.  The position allows
   to specify several values:

   *  For Equal and LSB, a single value is used, such as for the equal
      or LSB CDA, the position is set to 0.

   *  For match-mapping, several of these values can be contained in a
      Target Value field.  In the data model, this is generalized by
      adding a position, which orders the list of values.  By default the position is set to
   0.

   The leaf "value" is not mandatory to represent a non existing value
   in a TV.  Position
      values must start from 0 and be contiguous.

  grouping target-values-struct tv-struct {
    description "defines
      "Define the target value element. Can be either an arbitrary
        binary or ascii element. All target values are considered as Always a matching lists.
        Position is used binary type, strings
       must be converted to order values, by default position 0 is used when containing
        a single element."; binary. field-id allows the conversion to the appropriate
       type.";
    leaf value {
      type union {
                type binary;
                type string;
            }
    }
    leaf position {
      type uint16;
      description
        "If only one element position is 0, otherwise position is the
         matching list.";
            type uint16;
    }
  }

                 Figure 8: 9: 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.

2.8.  Matching Operator

   Matching Operator (MO) is a function applied between a field value
   provided by the parsed header and the target value.  [RFC8724]
   defines 4 MO. MO as listed in Figure 10.

     identity matching-operator-base-type mo-base-type {
       description "used
         "Used to extend Matching Operators with SID values";
     }

     identity mo-equal {
       base matching-operator-base-type; mo-base-type;
       description "RFC 8724";
         "Equal MO as defined RFC 8724 (cf. 7.3)";
     }

     identity mo-ignore {
       base matching-operator-base-type; mo-base-type;
       description "RFC 8724";
         "Ignore MO as defined RFC 8724 (cf. 7.3)";
     }

     identity mo-msb {
       base matching-operator-base-type; mo-base-type;
       description "RFC 8724";
         "MSB MO as defined RFC 8724 (cf. 7.3)";
     }

     identity mo-matching {
       base matching-operator-base-type; mo-base-type;
       description "RFC 8724";
         "match-mapping MO as defined RFC 8724 (cf. 7.3)";
     }

         Figure 9: 10: Definition of identityref for Matching Operator

   The naming convention is "mo" followed by the MO name.

   The type is "matching-operator-type" (cf.  Figure 10) 11)

  typedef matching-operator-type mo-type {
    type identityref {
      base mo-base-type;
    }
    description
      "Matching Operator (MO) to compare fields values with target values";
        type identityref {
            base matching-operator-base-type;
        }
  }
           Figure 10: 11: Type definition for Matching Operator

2.7.1.

2.8.1.  Matching Operator arguments

   Some Matching Operator such as MSB can take some values.  Even if
   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.

2.9.  Compression Decompression Actions

   Compression Decompression Action (CDA) identified the function to use
   either for compression or decompression.  [RFC8724] defines 6 CDA.

   Figure 13 gives some CDA definition, the full definition is in
   Section 7.

     identity compression-decompression-action-base-type; cda-base-type {
       description
         "Compression Decompression Actions";
     }

     identity cda-not-sent {
       base compression-decompression-action-base-type; cda-base-type;
       description "RFC 8724";
         "not-sent CDA as defines in RFC 8724 (cf. 7.4)";
     }

     identity cda-value-sent {
       base compression-decompression-action-base-type; cda-base-type;
       description "RFC 8724";
         "value-sent CDA as defines in RFC 8724 (cf. 7.4)";
     }

     identity cda-lsb {
       base compression-decompression-action-base-type; cda-base-type;
       description "RFC 8724";
         "LSB CDA as defines in RFC 8724 (cf. 7.4)";
     }

     identity cda-mapping-sent {
       base compression-decompression-action-base-type;
               description "RFC 8724";
       }

       identity cda-compute-length {
           base compression-decompression-action-base-type;
               description "RFC 8724";
       }

       identity cda-compute-checksum {
           base compression-decompression-action-base-type;
               description "RFC 8724";
       }

       identity cda-deviid {
           base compression-decompression-action-base-type;
               description "RFC 8724";
       }

      identity cda-appiid {
           base compression-decompression-action-base-type; cda-base-type;
       description "RFC 8724";
         "mapping-sent CDA as defines in RFC 8724 (cf. 7.4)";
     }

       ....

     Figure 11: 12: Definition of identityref for Compresion Decompression
                                   Action

   The type naming convention is "comp-decomp-action-type" (cf.  Figure 12) "cda" followed by the CDA name.

  typedef comp-decomp-action-type cda-type {
    type identityref {
      base cda-base-type;
    }
    description
      "Compression Decompression Action to compression or decompress a field.";
        type identityref {
            base compression-decompression-action-base-type;
        }
  }

    Figure 12: 13: Type definition for Compresion Decompression Action

2.8.1.

2.9.1.  Compression Decompression Action arguments

   Currently no CDA requires arguments, but the future some CDA may
   require several arguments.  They are viewed as a list of target-
   values-type.

3.  Rule definition

   A rule is either a C/D or an F/R rule.  A

2.10.  Fragmentation rule

   Fragmentation is identified by optional in the
   rule ID value data model and its associated length.  The YANG grouping rule-id-
   type defines depends on the structure used to represent a rule ID.  Length
   presence of 0
   is allowed to represent an implicit rule.

// Define rule ID. Rule ID is composed the "fragmentation" feature.

   Most of parameters for fragmentation are defined in Annex D of
   [RFC8724].

   Since fragmentation rules work for a RuleID value and specific direction, they contain
   a Rule ID Length

    grouping rule-id-type {
        leaf rule-id { mandatory direction.  The type uint32;
            description "rule ID value, is the same as the one used in
   compression entries, but the use of bidirectional is forbidden.

2.10.1.  Fragmentation mode

   [RFC8724] defines 3 fragmentation modes:

   *  No Ack: this value mode is unidirectionnal, no acknowledgment is sent
      back.

   *  Ack Always: each fragmentation window must be unique combined with explicitly
      acknowledged before going to the length";
        }
        leaf rule-length {
            type uint8 {
                range 0..32;
            }
            description "rule ID length in bits, value 0 next.

   *  Ack on Error: A window is acknowledged only when the receiver
      detects some missing fragments.

   Figure 14 give the definition for implicit rules";
        }
    }

// SCHC table for a specific device.

    container schc identifiers from these three modes.

   identity fragmentation-mode-base-type {
        leaf version{
            type uint64;
            mandatory false;
       description "used as an indication for versioning";
         "Fragmentation mode";
     }
        list rule {
            key "rule-id rule-length";
            uses rule-id-type;
            choice nature {
                case fragmentation

     identity fragmentation-mode-no-ack {
                    uses fragmentation-content;
       base fragmentation-mode-base-type;
       description
         "No Ack of RFC 8724.";
     }
                case compression

     identity fragmentation-mode-ack-always {
                    uses compression-content;
       base fragmentation-mode-base-type;
       description
         "Ack Always of RFC8724.";
     }

     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";
     }

           Figure 13: 14: Definition of a SCHC Context

   To access to a specific rule, rule-id and its specific length is used
   as a key. fragmentation mode identifer

   The rule naming convention is either a compression or a "fragmentation-mode" followed by the
   fragmentation rule.

   Each context can be identified though a version id.

3.1.  Compression rule mode name.

2.10.2.  Fragmentation Header

   A compression data fragment header, directly following the rule ID can be sent on
   the fragmentation direction.  The direction is mandatory and must be
   up or down. bidirectional is forbidden.  The SCHC header may be
   composed of entries describing its processing (cf.  Figure 14).  An entry contains all 15):

   *  a Datagram Tag (Dtag) identifying the datagram being fragmented if
      the information fragmentation applies concurrently on several datagrams.  This
      field in optional and its length is defined by the rule.

   *  a Window (W) used in
   Figure Ack-Always and Ack-on-Error modes.  In Ack-
      Always, its size is 1 with and depends on the types defined above.

3.1.1.  Compression context representation.

   The compression rule described Figure 1 is associated to a rule ID.
   The compression rule entry is defined in Figure 14.  Each column Ack-on-Error.
      This field is not need in No-Ack mode.

   *  a Fragment Compressed Number (FCN) indicating the table fragment/tile
      position on the window.  This field is either represented by a leaf or mandatory on all modes
      defined in [RFC8724], its size is defined by the rule.

   |-- SCHC Fragment Header ----|
            |-- T --|-M-|-- N --|
   +-- ... -+- ... -+---+- ... -+--------...-------+~~~~~~~~~~~~~~~~~~~~
   | RuleID | DTag  | W |  FCN  | Fragment Payload | padding (as needed)
   +-- ... -+- ... -+---+- ... -+--------...-------+~~~~~~~~~~~~~~~~~~~~

             Figure 15: Data fragment header from RFC8724

2.10.3.  Last fragment format

   The last fragment of a list.  Note that
   Matching Operators datagram is sent with an RCS (Reassembly Check
   Sequence) field to detect residual transmission error and Compression Decompression actions can have
   arguments.  They are viewed possible
   losses in the last window.  [RFC8724] defines a ordered list single algorithm
   based on Ethernet CRC computation.  The identity of strings and numbers as the RCS algorithm
   is shown in target values.

    grouping compression-rule-entry Figure 16.

     // -- RCS algorithm types

     identity rcs-algorithm-base-type {
       description "These entries
         "Identify which algorithm is used to compute RSC.
          The algorithm defines a compression entry (i.e. a line) also the size if the RSC field.";
     }

     identity rcs-RFC8724 {
       base rcs-algorithm-base-type;
       description
         "CRC 32 defined as default RCS in RFC8724.";
     }

     typedef rcs-algorithm-type {
       type identityref {
         base rcs-algorithm-base-type;
       }
       description
         "type used in rules";
     }

                     Figure 16: type definition for RCS

   The naming convention is "rcs" followed by the algorithm name.

   For Ack-on-Error mode, the All-1 fragment may just contain the RCS or
   can include a tile.  The parameters defined in RFC 8724 Figure 17 allows to
   define the behavior:

   *  all1-data-no: the last fragment contains no data, just the RCS

   *  all1-data-yes: the last fragment includes a single tile and fragmentation parameters.

        +-------+--+--+--+------------+-----------------+---------------+
        |Field 1|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|
        +-------+--+--+--+------------+-----------------+---------------+

        An entry in the
      RCS

   *  all1-data-sender-choice: the last fragment may or may not contain
      a compression rule single tile.  The receiver can detect if a tile is composed of 7 elements:
        - Field ID: present.

    // -- 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-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 choose to send tiles or not in all1.";
     }

     typedef all1-data-type {
       type identityref {
         base all1-data-base-type;
       }
       description
         "Type used in rules";
     }

                     Figure 17: type definition for RCS

   The naming convention is "all1-data" followed by the behavior
   identifier.

2.10.4.  Acknowledgment behavior

   A cknowledgment fragment header field to be compressed. goes in the opposite direction of
   data.  The content header is a YANG identifer.
        - Field Length : either a positive integer composed of (see Figure 18):

   *  a function defined as a YANG id.
        - Field Position: Dtag (if present).

   *  a positive (and possibly equal to 0) integer.
        - Direction Indicator: mandatory window as in the data fragment.

   *  a YANG identifier C bit giving the direction.
        - Target value: status of RCS validation.  In case of failure,
      a value against which bitmap follows, indicating received fragment/tile.  The size of
      the header Field bitmap is compared.
        - Matching Operator: a YANG id giving given by the operation, parameters may FCN value.

   NOTE: IN THE DATA MODEL THERE IS A max-window-size FIELD TO LIMIT THE
   BITMAP SIZE, BUT IS NO MORE IN RFC8724!  DO WE KEEP IT?

   |--- 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 18: Acknowledgment fragment header for RFC8724

   For Ack-on-Error, SCHC defined when acknowledgment can be
        associated to that operator.
        - Comp./Decomp. Action: A YANG id giving sent.  This
   can be at any time defined by the compression layer 2, at the end of a window
   (FCN All-0) or decompression
        action, parameters may be associated at the end of the fragment (FCN All-1).  The following
   identifiers (cf.  Figure 19) define the acknowledgment behavior.

   // -- Ack behavior

     identity ack-behavior-base-type {
       description
         "Define when to that action.
        ";

        leaf field-id send an Acknowledgment message";
     }

     identity ack-behavior-after-All0 {
       base ack-behavior-base-type;
       description "Field ID, identify a field in the header with a YANG identityref.";
            mandatory true;
            type schc:field-id-type;
         "Fragmentation expects Ack after sending All0 fragment.";
     }
        leaf field-length

     identity ack-behavior-after-All1 {
       base ack-behavior-base-type;
       description "Field Length in bit or through a function defined as a YANG identityref";
            mandatory true;
            type schc:field-length-type;
         "Fragmentation expects Ack after sending All1 fragment.";
     }
        leaf field-position

     identity ack-behavior-always {
       base ack-behavior-base-type;
       description "field position
         "Fragmentation expects Ack after sending every fragment.";
     }

     typedef ack-behavior-type {
       type identityref {
         base ack-behavior-base-type;
       }
       description
         "Type used in the header rules";
     }

                   Figure 19: bitmap generation behavior

   The naming convention is a integer. If "ack-behavior" followed by the field is not repeated algorithm
   name.

   For Ack-onError, [RFC8724] allows a single bitmap in the header the value is 1, and incremented for each repetition of the field. Position
            0 means that the position is not important an acknowledment
   fragment, and order may change when decompressed";
            mandatory true;
            type uint8;
        }
        leaf direction-indicator {
            description "Direction Indicator, a YANG identityref [I-D.ietf-lpwan-schc-compound-ack] proposes to say if
   acknowledge several windows on a single ack fragment.  The following
   identifiers (cf.  Figure 20) define the packet is bidirectionnal,
            up or down";
            mandatory true;
            type schc:direction-indicator-type;
        }
        list target-values behavior.

     identity bitmap-format-base-type {
       description "a list of value to compare with the header field value. If target value
         "Define how the bitmap is a singleton, position must be 0. For matching-list, should be consecutive position
            values starting from 1.";
            key position;
            uses target-values-struct; defined in ACK messages.";
     }
        leaf matching-operator

     identity bitmap-RFC8724 {
            mandatory true;
            type schc:matching-operator-type;
       base bitmap-format-base-type;
       description
         "Bitmap as defined in RFC8724.";
     }
        list matching-operator-value

     identity bitmap-compound-ack {
            key position;
            uses target-values-struct;
       base bitmap-format-base-type;
       description
         "Compound Ack.";
     }
        leaf comp-decomp-action

     typedef bitmap-format-type {
            mandatory true;
       type schc:comp-decomp-action-type;
        }
        list comp-decomp-action-value identityref {
            key position;
            uses target-values-struct;
         base bitmap-format-base-type;
       }
       description
         "type used in rules";
     }

                   Figure 14: Definition of a compression entry

3.1.2.  Rule definition

   A compression rule 20: bitmap generation behavior

   The naming convention is a list "bitmap" followed by the algorithm name.

2.10.5.  Fragmentation Parameters

   The state machine requires some common values to handle
   fragmentation:

   *  retransmission-timer gives in seconds the duration before sending
      an ack request (cf. section 8.2.2.4. of entries.

    grouping compression-content {
        description "define a compression rule composed [RFC8724]).  If specified,
      value must be higher or equal to 1.

   *  inactivity-timer gives in seconds the duration before aborting
      (cf. section 8.2.2.4. of a list [RFC8724]), value of entries.";
        list entry {
            key "field-id field-position direction-indicator";
            uses compression-rule-entry;
        }
    }

                Figure 15: Definition 0 explicitly
      indicates that this timer is disabled.

   *  max-ack-requests gives the number of a compression rule

   To identify a specific entry Field ID, position and direction attempts before aborting (cf.
      section 8.2.2.4. of [RFC8724]).

   *  maximum-packet-size gives in bytes the larger packet size that can
      be reassembled.

   The are
   needed.

3.2.  Fragmentation rule

   Parameters defined as unsigned integer, see Section 7.

2.10.6.  Layer 2 parameters

   The data model includes two parameters needed for fragmentation:

   *  l2-word-size: [RFC8724] base fragmentation are defined in Annex D on a layer 2 word which
      can be of [RFC8724].

   Figure 16 gives any length.  The default value is 8 and correspond to
      the first elements found in this structure.  It
   starts with a direction.  Since fragmentation rules work default value for byte aligned layer 2.  A value of 1 will
      indicate that there is no alignment and no need for padding.

   *  maximum-packet-size: defines the maximum size of a
   specific direction, they contain uncompressed
      datagram.  By default, the value is set to 1280 bytes.

   They are defined as unsigned integer, see Section 7.

3.  Rule definition

   A rule is either a mandatory direction.  The type C/D or an F/R rule.  A rule is identified by the same as
   rule ID value and its associated length.  The YANG grouping rule-id-
   type defines the one structure used to represent a rule ID.  Length of 0
   is allowed to represent an implicit rule.

   Three types of rules are defined in [RFC8724]:

   *  Compression: a compression entries, but rule is associated to the use of
   bidirectionnal rule ID.

   *  No compression: nothing is forbidden.

   The next elements describe size of SCHC associated to the rule ID.

   *  Fragmentation: fragmentation header fields.
   Only parameters are associated to the FCN size rule
      ID.  Fragmentation is mandatory optional and value must feature "fragmentation" should
      be higher or equal to
   1. set.

  grouping fragmentation-content rule-id-type {
    leaf rule-id-value {
      type uint32;
      description "This grouping defines
        "Rule ID value, this value must be unique combined with the fragmentation parameters length";
    }
    leaf rule-id-length {
      type uint8 {
        range "0..32";
      }
      description
        "Rule ID length in bits, value 0 is for
        all the modes (No Ack, Ack Always implicit rules";
    }
    description
      "A rule ID is composed of a value and Ack on Error) specified a length in
        RFC 8724.";

        leaf direction bit";
  }

  // SCHC table for a specific device.

  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 {
          uses compression-content;
        }
        case no-compression {
            type schc:direction-indicator-type;
          description "should be up or down, bi directionnal
            "RFC8724 allows a rule for uncompressed headers";
        }
        description
          "A rule is forbidden.";
            mandatory true; either for compression, no compression or fragmentation";
      }
        leaf dtagsize {
            type uint8;
      description "size in bit
        "Set of the DTag field"; rules compression, no compression or fragmentation rules
        identified by their rule-id ";
    }
        leaf wsize {
            type uint8;
    description "size in bit
      "a SCHC set of the window field";
        }
        leaf fcnsize {
            type uint8 {
                range 1..max;
            }
            description "size in bit rules is composed of the FCN field";
            mandatory true; a list of rule which are either
       compression or fragmentation";
  }
}
...
               Figure 16: 21: Definition of a fragmentation parameters, SCHC header

   RCS algorithm Context

   To access to a specific rule, rule-id and its specific length is defined (Figure 17), by default with the CRC
   computation proposed in [RFC8724]. used
   as a key.  The algorithms are rule is either a compression or a fragmentation rule.

   Each context can be identified
   through an identityref specified though a version id.

3.1.  Compression rule

   A compression rule is composed of entries describing its processing
   (cf.  Figure 22).  An entry contains all the information defined in
   Figure 1 with the SCHC Data Model types defined above.

   The compression rule described Figure 1 is defined by compression-
   content.  It defines a list of compression-rule-entry, indexed by
   their field id, position and with direction.  The compression-rule-entry
   element represent a line of the table Figure 1.  Their type RCS-algorithm-type (Figure 18).

   ...
           leaf RCS-algorithm reflects
   the identifier types defined in Section 2.1

   Some controls are made on the values:

   *  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 {
               type RCS-algorithm-type;
               default schc:RFC8724-RCS;
    description "Algoritm used for RCS";
           }
   ...

    Figure 17: Definition of
      "These entries defines a compression entry (i.e. a line)
       as defined in RFC 8724 and fragmentation parameters, RCS algorithm
       identity RCS-algorithm-base-type {
           description "identify which algorithm parameters.

       +-------+--+--+--+------------+-----------------+---------------+
       |Field 1|FL|FP|DI|Target Value|Matching Operator|Comp/Decomp Act|
       +-------+--+--+--+------------+-----------------+---------------+

       An entry in a compression rule is used composed of 7 elements:
       - Field ID: The header field to compute RSC. be compressed. The algorithm defines also the size if the RSC field.";
       }

       identity RFC8724-RCS {
           description "CRC 32 content is a YANG identifer.
       - Field Length : either a positive integer of a function defined as default RCS in RFC8724.";
           base RCS-algorithm-base-type;
       }

       typedef RCS-algorithm-type {
           type identityref {
               base RCS-algorithm-base-type;
           }
       }

          Figure 18: Definition of identityref for RCS Algorithm

   Figure 19 gives the parameters used by the state machine a YANF id.
       - Field Position: a positive (and possibly equal to handle
   fragmentation:

   o  maximum-window-size contains 0) integer.
       - Direction Indicator: a YANG identifier giving the maximum FCN direction.
       - Target value: a value that can be
      used.

   o  retransmission-timer gives in seconds against which the duration before sending
      an ack request (cf. section 8.2.2.4. of [RFC8724]).  If specifed,
      value must header Field is compared.
       - Matching Operator: a YANG id giving the operation, paramters may be higher or equal
       associated to 1.

   o  inactivity-timer gives in seconds the duration before aborting
      (cf. section 8.2.2.4. of [RFC8724]), value of 0 explicitly
      indicates that this timer is disabled.

   o  max-ack-requests gives operator.
       - Comp./Decomp. Action: A YANG id giving the number of attempts before aborting (cf.
      section 8.2.2.4. of [RFC8724]).

   o  maximum-packet-size gives compression or decompression
       action, paramters may be associated to that action.
      ";
    leaf field-id {
      type schc:fid-type;
      mandatory true;
      description
        "Field ID, identify a field in bytes the larger packet size that can
      be reassembled.

... header with a YANG refenceid.";
    }
    leaf maximum-window-size field-length {
      type uint16; schc:fl-type;
      mandatory true;
      description "by default 2^wsize - 2";
        "Field Length in bit or through a function defined as a YANG referenceid";
    }
    leaf retransmission-timer field-position {
      type uint64 {
                range 1..max;
            } uint8;
      mandatory true;
      description "duration
        "Field position in seconds 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 retransmission timer"; // Check field. Position
         0 means that the units position is not important and order may change when decompressed";
    }
    leaf inactivity-timer direction-indicator {
      type uint64; schc:di-type;
      mandatory true;
      description "duration
        "Direction Indicator, a YANG referenceid to say if the packet is seconds bidirectional,
         up or down";
    }
    list target-value {
      key "position";
      uses tv-struct;
      description
        "A list of value to compare with the inactivity timer, 0 indicates the timer header field value. If target value
         is disabled"; // check units a singleton, position must be 0. For matching-list, should be consecutive position
         values starting from 1.";
    }
    leaf max-ack-requests matching-operator {
      type uint8 schc:mo-type;
      must "../target-value or derived-from-or-self(., 'mo-ignore')" {
                range 1..max;
            }
        error-message "mo-equal, mo-msb and mo-match-mapping require target-value";
        description "the maximum number of retries
          "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 MSB define a specific SCHC ACK."; single argument: length in bits  ";
    }
    leaf maximum-packet-size comp-decomp-action {
      type uint16;
            default 1280; schc:cda-type;
      mandatory true;
      description "When decompression
        "CDA: Compression Decompression Action";
    }
    list comp-decomp-action-value {
      key "position";
      uses tv-struct;
      description
        "CDA Arguments, based on TV structure to allow several arguments.
         In RFC 8724, no argument is done, packet size must not strictly exceed this limit defined for CDA";
    }
  }

  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 entry describing
         each header field. An entry is identifed through a field-id, its position
         in Bytes"; the packet and its direction";
    }
    description
      "Define a compression rule composed of a list of entries.";
  }
...

             Figure 19: 22: Definition of a fragmentation state machine parameters

   Figure 20 gives information related to a specific compression mode:
   fragmentation-mode MUST be set with a specific entry

3.2.  Fragmentation rule

   A Fragmentation rule is composed of entries describing the protocol
   behavior.  Identityref
   are given Figure 21.

   For Ack  Some on Error some specific information may be provided:

   o  tile-size gives them are numerical entries, others are identifiers
   defined in bits Section 2.10.

   The data model defines some relations between the entries:

   *  direction must be either up or down (not bidirectional).

   *  W size of the tile; If set to 0 a single
      tile is inserted inside a fragment.

   o  tile-in-All1 indicates if All1 contains only the RCS (all1-data-
      no) or may contain a single tile (all1-data-yes).  Since the
      reassembly process may detect this behavior, the choice can be
      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
      acknowledgments.  When ack-behavior-after-All0 is specified, the
      ack may be sent after the reception of All-0 fragment.  When ack-
      behavior-after-All1 is specified, the ack may be sent after the
      reception of All-1 fragment at the end of needed for Ack Always and Ack on Error modes.

   grouping fragmentation-content {
    description
      "This grouping defines the fragmentation
      process.  ack-behavior-always do not impose a limitation at the
      SCHC level.  The constraint may come from parameters for
       all the LPWAN technology.
      All possible values are given Figure 21.

... modes (No Ack, Ack Always and Ack on Error) specified in
       RFC 8724.";
    leaf fragmentation-mode l2-word-size {
      type schc:fragmentation-mode-type; uint8;
      default "8";
      description "which
        "Size in bit of the layer 2 word";
    }
    leaf direction {
      must "derived-from-or-self(., 'di-up') or derived-from-or-self(., 'di-down')" {
        error-message "direction for fragmentation mode rules is used (noAck, AckAlways, AckonError)"; up or down";
      }
      type schc:direction-indicator-type;
      mandatory true;
        }

        choice mode {
            case no-ack;
            case ack-always;
            case ack-on-error {
      description
        "Should be up or down, bi directionnal is forbiden.";
    }
    leaf tile-size dtag-size {
      type uint8;
      default "0";
      description "size
        "Size in bit of tiles, if not specified or set to 0: tile fills the fragment."; DTag field";
    }
    leaf tile-in-All1 w-size {
      when "not(derived-from(../fragmentation-mode, 'fragmentation-mode-no-ack'))";
      type schc:all1-data-type; uint8;
      description "When true, sender and receiver except a tile
        "Size in All-1 frag"; bit of the window field";
    }
    leaf ack-behavior fcn-size {
      type schc:ack-behavior-type; uint8;
      mandatory true;
      description "Sender behavior to acknowledge, after All-0, All-1 or when
        "Size in bit of the
                    LPWAN allows it (Always)";
                }
            } FCN field";
    }
...

       Figure 20: Definition of a fragmentation specific information

// -- FRAGMENTATION TYPE

// -- fragmentation modes

    identity fragmentation-mode-base-type
    leaf rcs-algorithm {
      type rcs-algorithm-type;
      default "schc:rcs-RFC8724";
      description "fragmentation mode";
        "Algorithm used for RCS";
    }

    identity fragmentation-mode-no-ack
    leaf maximum-window-size {
      type uint16;
      description "No Ack of RFC 8724.";
        base fragmentation-mode-base-type;
        "By default 2^wsize - 1";

    }

    identity fragmentation-mode-ack-always
    leaf retransmission-timer {
      type uint64 {
        range "1..max";
      }
      description "Ack Always
        "Duration in seconds of RFC8724.";
        base fragmentation-mode-base-type; the retransmission timer"; // Check the units
    }
    identity fragmentation-mode-ack-on-error
    leaf inactivity-timer {
      type uint64;
      description "Ack on Error
        "Duration is seconds of RFC8724.";
        base fragmentation-mode-base-type; the inactivity timer, 0 indicates the timer is disabled"; // check units
    }

    typedef fragmentation-mode-type
    leaf max-ack-requests {
      type identityref {
            base fragmentation-mode-base-type;
        }
    }

// -- Ack behavior

    identity ack-behavior-base-type uint8 {
        description "define when to send an Acknowledgment message";
        range "1..max";
      }

    identity ack-behavior-after-All0 {
      description "fragmentation expects Ack after sending All0 fragment.";
        base ack-behavior-base-type;
        "The maximum number of retries for a specific SCHC ACK.";
    }

    identity ack-behavior-after-All1
    leaf maximum-packet-size {
      type uint16;
      default "1280";
      description "fragmentation expects Ack after sending All1 fragment.";
        base ack-behavior-base-type;
        "When decompression is done, packet size must not strictly exceed this limit in Bytes";
    }

    identity ack-behavior-always
    leaf fragmentation-mode {
      type schc:fragmentation-mode-type;
      mandatory true;
      description "fragmentation expects Ack after sending every fragment.";
        base ack-behavior-base-type;
        "Which fragmentation mode is used (noAck, AckAlways, AckonError)";
    }

    typedef ack-behavior-type
    choice mode {
        type identityref
      case no-ack;
      case ack-always;
      case ack-on-error {
            base ack-behavior-base-type;
        }
    }

// -- All1 with data types

    identity all1-data-base-type
        leaf tile-size {
        description "type to define
          type uint8;
          when to send an Acknowledgment message";
    }

    identity all1-data-no { "derived-from(../fragmentation-mode, 'fragmentation-mode-ack-on-error')";
          description "All1 contains no tiles.";
        base all1-data-base-type;
            "Size in bit of tiles, if not specified or set to 0: tile fills the fragment.";
        }

    identity all1-data-yes
        leaf tile-in-All1 {
          type schc:all1-data-type;
          when "derived-from(../fragmentation-mode, 'fragmentation-mode-ack-on-error')";
          description "All1 MUST contain
            "When true, sender and receiver except a tile";
        base all1-data-base-type; tile in All-1 frag";
        }

    identity all1-data-sender-choice
        leaf ack-behavior {
          type schc:ack-behavior-type;
          when "derived-from(../fragmentation-mode, 'fragmentation-mode-ack-on-error')";
          description "Fragmentation process choose
            "Sender behavior to send tiles acknowledge, after All-0, All-1 or not in all1.";
        base all1-data-base-type; when the
             LPWAN allows it (Always)";
        }

    typedef all1-data-type
        leaf bitmap-format {
          type identityref {
            base all1-data-base-type; schc:bitmap-format-type;
          when "derived-from(../fragmentation-mode, 'fragmentation-mode-ack-on-error')";
          default "schc:bitmap-RFC8724";
          description
            "How the bitmaps are included in the Ack message.";
        }
      }

              Figure 21: Specific types for Ack On Error mode

   ##
      description
        "RFC 8724 defines 3 fragmentation modes";
    }
  }

3.3.  YANG Tree
module: schc ietf-schc
  +--rw schc
     +--rw version?   uint64
     +--rw rule* [rule-id rule-length] [rule-id-value rule-id-length]
        +--rw rule-id rule-id-value                 uint32
        +--rw rule-length rule-id-length                uint8
        +--rw (nature)?
           +--:(fragmentation) {fragmentation}?
           |  +--rw l2-word-size?           uint8
           |  +--rw direction               schc:direction-indicator-type               schc:di-type
           |  +--rw dtagsize? dtag-size?              uint8
           |  +--rw wsize? w-size?                 uint8
           |  +--rw fcnsize fcn-size                uint8
           |  +--rw RCS-algorithm?          RCS-algorithm-type rcs-algorithm?          rcs-algorithm-type
           |  +--rw maximum-window-size?    uint16
           |  +--rw retransmission-timer?   uint64
           |  +--rw inactivity-timer?       uint64
           |  +--rw max-ack-requests?       uint8
           |  +--rw maximum-packet-size?    uint16
           |  +--rw fragmentation-mode      schc:fragmentation-mode-type
           |  +--rw (mode)?
           |     +--:(no-ack)
           |     +--:(ack-always)
           |     +--:(ack-on-error)
           |        +--rw tile-size?        uint8
           |        +--rw tile-in-All1?     schc:all1-data-type
           |        +--rw ack-behavior?     schc:ack-behavior-type
           |        +--rw bitmap-format?    schc:bitmap-format-type
           +--:(compression)
           |  +--rw entry* [field-id field-position direction-indicator]
           |     +--rw field-id                    schc:field-id-type                    schc:fid-type
           |     +--rw field-length                schc:field-length-type                schc:fl-type
           |     +--rw field-position              uint8
           |     +--rw direction-indicator         schc:direction-indicator-type         schc:di-type
           |     +--rw target-values* target-value* [position]
           |     |  +--rw value?      union      binary
           |     |  +--rw position    uint16
           |     +--rw matching-operator           schc:matching-operator-type           schc:mo-type
           |     +--rw matching-operator-value* [position]
           |     |  +--rw value?      union      binary
           |     |  +--rw position    uint16
           |     +--rw comp-decomp-action          schc:comp-decomp-action-type          schc:cda-type
           |     +--rw comp-decomp-action-value* [position]
           |        +--rw value?      union      binary
           |        +--rw position    uint16
           +--:(no-compression)

                              Figure 22 23

4.  IANA Considerations

   This document has no request to IANA.

5.  Security considerations

   This document does not have any more Security consideration than the
   ones already raised on [RFC8724]

6.  Acknowledgements

   The authors would like to thank Dominique Barthel, Carsten Bormann,
   Alexander Pelov.

7.  YANG Module

<code begins> file schc@2020-02-28.yang ietf-schc@2021-08-17.yang
module schc{ ietf-schc {
  yang-version "1"; 1.1;
  namespace "urn:ietf:lpwan:schc:rules-description"; "urn:ietf:params:xml:ns:yang:ietf-schc";
  prefix "schc"; schc;

  organization
    "IETF IPv6 over Low Power Wide-Area Networks (lpwan) working group";
  contact
    "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
    "Generic
    "
     Copyright (c) 2021 IETF Trust and the persons identified as
     authors of the code.  All rights reserved.

     Redistribution and use in source and binary forms, with or
     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
     (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
     for full legal notices.

     The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
     NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
     'MAY', and 'OPTIONAL' in this document are to be interpreted as
     described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
     they appear in all capitals, as shown here.

     *************************************************************************

     Generic Data model for Static Context Header Compression Rule for SCHC,
     based on draft-ietf-lpwan-ipv6-static-context-hc-18. Include compression
     rules and fragmentation rules.

     This module is a YANG model for SCHC rules (RFc 8724).
     RFC 8724 describes a rule in a abstract way through a table.

     |-----------------------------------------------------------------|
     |  (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||
     +-------+--+--+--+------------+-----------------+---------------+||
     |-----------------------------------------------------------------|

     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 describes some operations in fields.
     This data model applies both to compression and fragmentation.";

  revision 2020-06-15 {
        description "clean up and add descriptions, merge schc-id to this file";
    }

    revision 2020-02-28 {
        description "Add Fragmentation parameters";
    }

    revision 2020-01-23 2021-08-17 {
    description "Modified TV with binary and union";
      "Initial version from RFC XXXX ";
    reference
      "RFC XXX: Data Model for Static Context Header Compression (SCHC)";
  }

    revision 2020-01-07

  feature fragmentation {
    description "First version of
      "Fragmentation is usually required only at the YANG model"; transportation level.";
  }

  // -------------------------
  //  Field ID type definition
  //--------------------------
  // generic value TV definition
  identity field-id-base-type fid-base-type {
    description
      "Field ID with SID"; base type for all fields";
  }

  identity fid-ipv6-base-type {
    base fid-base-type;
    description
      "Field IP base type for IPv6 headers described in RFC 8200";
  }

  identity fid-ipv6-version {
    base field-id-base-type; fid-ipv6-base-type;
    description
      "IPv6 version field from RFC8200";
  }

  identity fid-ipv6-trafficclass {
    base field-id-base-type; fid-ipv6-base-type;
    description
      "IPv6 Traffic Class field from RFC8200";
  }

  identity fid-ipv6-trafficclass-ds {
    base field-id-base-type; fid-ipv6-trafficclass;
    description
      "IPv6 Traffic Class field from RFC8200,
       DiffServ field from RFC3168";
  }

  identity fid-ipv6-trafficclass-ecn {
    base field-id-base-type; fid-ipv6-trafficclass;
    description
      "IPv6 Traffic Class field from RFC8200,
       ECN field from RFC3168";
  }

  identity fid-ipv6-flowlabel {
    base field-id-base-type; fid-ipv6-base-type;
    description
      "IPv6 Flow Label field from RFC8200";
  }

  identity fid-ipv6-payloadlength {
    base field-id-base-type; fid-ipv6-base-type;
    description
      "IPv6 Payload Length field from RFC8200";
  }
  identity fid-ipv6-nextheader {
    base field-id-base-type; fid-ipv6-base-type;
    description
      "IPv6 Next Header field from RFC8200";
  }

  identity fid-ipv6-hoplimit {
    base field-id-base-type; fid-ipv6-base-type;
    description
      "IPv6 Next Header field from RFC8200";
  }

  identity fid-ipv6-devprefix {
    base field-id-base-type; fid-ipv6-base-type;
    description
      "correspond either to the source address or the desdination
              address prefix of RFC 8200. Depending if it is respectively
              a uplink or an downklink message.";
  }

  identity fid-ipv6-deviid {
    base field-id-base-type; fid-ipv6-base-type;
    description
      "correspond either to the source address or the desdination
              address prefix of RFC 8200. Depending if it is respectively
              a uplink or an downklink message.";
  }

  identity fid-ipv6-appprefix {
    base field-id-base-type; fid-ipv6-base-type;
    description
      "correspond either to the source address or the desdination
              address prefix of RFC 768. Depending if it is respectively
              a downlink or an uplink message.";
  }

  identity fid-ipv6-appiid {
    base field-id-base-type; fid-ipv6-base-type;
    description
      "correspond either to the source address or the desdination
              address prefix of RFC 768. Depending if it is respectively
              a downlink or an uplink message.";
  }

  identity fid-udp-base-type {
    base fid-base-type;
    description
      "Field IP base type for UDP headers described in RFC 768";

  }

  identity fid-udp-dev-port {
    base field-id-base-type; fid-udp-base-type;
    description
      "UDP length from RFC 768";
  }

  identity fid-udp-app-port {
    base field-id-base-type; fid-udp-base-type;
    description
      "UDP length from RFC 768";
  }

  identity fid-udp-length {
    base field-id-base-type; fid-udp-base-type;
    description
      "UDP length from RFC 768";
  }

  identity fid-udp-checksum {
    base field-id-base-type; fid-udp-base-type;
    description
      "UDP length from RFC 768";
  }

  identity fid-coap-base-type {
    base fid-base-type;
    description
      "Field IP base type for UDP headers described in RFC 768";
  }

  identity fid-coap-version {
    base field-id-base-type; fid-coap-base-type;
    description
      "CoAP version from RFC 7252";
  }

  identity fid-coap-type {
    base field-id-base-type; fid-coap-base-type;
    description
      "CoAP type from RFC 7252";
  }

  identity fid-coap-tkl {
    base field-id-base-type; fid-coap-base-type;
    description
      "CoAP token length from RFC 7252";

  }

  identity fid-coap-code {
    base field-id-base-type; fid-coap-base-type;
    description
      "CoAP code from RFC 7252";
  }

  identity fid-coap-code-class {
    base field-id-base-type; fid-coap-code;
    description
      "CoAP code class from RFC 7252";
  }

  identity fid-coap-code-detail {
    base field-id-base-type; fid-coap-code;
    description
      "CoAP code detail from RFC 7252";
  }

  identity fid-coap-mid {
    base field-id-base-type; fid-coap-base-type;
    description
      "CoAP message ID from RFC 7252";
  }

  identity fid-coap-token {
    base field-id-base-type; fid-coap-base-type;
    description
      "CoAP token from RFC 7252";
  }

  identity fid-coap-option-if-match {
    base field-id-base-type; fid-coap-base-type;
    description
      "CoAP option If-Match from RFC 7252";
  }

  identity fid-coap-option-uri-host {
    base field-id-base-type; fid-coap-base-type;
    description
      "CoAP option URI-Host from RFC 7252";
  }

  identity fid-coap-option-etag {
    base field-id-base-type; fid-coap-base-type;
    description
      "CoAP option Etag from RFC 7252";

  }

  identity fid-coap-option-if-none-match {
    base field-id-base-type; fid-coap-base-type;
    description
      "CoAP option if-none-match from RFC 7252";
  }

  identity fid-coap-option-observe {
    base field-id-base-type; fid-coap-base-type;
    description
      "CoAP option Observe from RFC 7641";
  }

  identity fid-coap-option-uri-port {
    base field-id-base-type; fid-coap-base-type;
    description
      "CoAP option Uri-Port from RFC 7252";
  }

  identity fid-coap-option-location-path {
    base field-id-base-type; fid-coap-base-type;
    description
      "CoAP option Location-Path from RFC 7252";
  }

  identity fid-coap-option-uri-path {
    base field-id-base-type; fid-coap-base-type;
    description
      "CoAP option Uri-Path from RFC 7252";
  }

  identity fid-coap-option-content-format {
    base field-id-base-type; fid-coap-base-type;
    description
      "CoAP option Content Format from RFC 7252";
  }

  identity fid-coap-option-max-age {
    base field-id-base-type; fid-coap-base-type;
    description
      "CoAP option Max-Age from RFC 7252";
  }

  identity fid-coap-option-uri-query {
    base field-id-base-type; fid-coap-base-type;
    description
      "CoAP option Uri-Query from RFC 7252";

  }

  identity fid-coap-option-accept {
    base field-id-base-type; fid-coap-base-type;
    description
      "CoAP option Max-Age from RFC 7252";
  }

  identity fid-coap-option-location-query {
    base field-id-base-type; fid-coap-base-type;
    description
      "CoAP option Location-Query from RFC 7252";
  }

  identity fid-coap-option-block2 {
    base field-id-base-type; fid-coap-base-type;
    description
      "CoAP option Block2 from RFC 7959";
  }

  identity fid-coap-option-block1 {
    base field-id-base-type; fid-coap-base-type;
    description
      "CoAP option Block1 from RFC 7959";
  }

  identity fid-coap-option-size2 {
    base field-id-base-type; fid-coap-base-type;
    description
      "CoAP option size2 from RFC 7959";
  }

  identity fid-coap-option-proxy-uri {
    base field-id-base-type; fid-coap-base-type;
    description
      "CoAP option Proxy-Uri from RFC 7252";
  }

  identity fid-coap-option-proxy-scheme {
    base field-id-base-type; fid-coap-base-type;
    description
      "CoAP option Proxy-scheme from RFC 7252";
  }

  identity fid-coap-option-size1 {
    base field-id-base-type; fid-coap-base-type;
    description
      "CoAP option Size1 from RFC 7252";

  }

  identity fid-coap-option-no-response {
    base field-id-base-type; fid-coap-base-type;
    description
      "CoAP option No response from RFC 7967";
  }

  identity fid-coap-option-oscore-flags {
    base field-id-base-type; fid-coap-base-type;
    description
      "CoAP option oscore flags (see draft schc coap, section 6.4)";
  }

  identity fid-coap-option-oscore-piv {
    base field-id-base-type; fid-coap-base-type;
    description
      "CoAP option oscore flags (see draft schc coap, section 6.4)";
  }

  identity fid-coap-option-oscore-kid {
    base field-id-base-type; fid-coap-base-type;
    description
      "CoAP option oscore flags (see draft schc coap, section 6.4)";
  }

  identity fid-coap-option-oscore-kidctx {
    base field-id-base-type; fid-coap-base-type;
    description
      "CoAP option oscore flags (see draft schc coap, section 6.4)";
  }

  identity fid-icmpv6-base-type {
    base fid-base-type;
    description
      "Field IP base type for UDP headers described in RFC 768";
  }

  identity fid-icmpv6-type {
    base field-id-base-type; fid-icmpv6-base-type;
    description
      "ICMPv6 field (see draft OAM)";
  }

  identity fid-icmpv6-code {
    base field-id-base-type; fid-icmpv6-base-type;
    description
      "ICMPv6 field (see draft OAM)";

  }

  identity fid-icmpv6-checksum {
    base field-id-base-type; fid-icmpv6-base-type;
    description
      "ICMPv6 field (see draft OAM)";
  }

  identity fid-icmpv6-identifier {
    base field-id-base-type; fid-icmpv6-base-type;
    description
      "ICMPv6 field (see draft OAM)";
  }

  identity fid-icmpv6-sequence {
    base field-id-base-type; fid-icmpv6-base-type;
    description
      "ICMPv6 field (see draft OAM)";
  }

/// !!!!!!! See future CoAP extentions

  //----------------------------------
  // Field Length type definition
  //----------------------------------

  identity field-length-base-type fl-base-type {
    description "used
      "Used to extend field length functions";
  }

  identity fl-variable {
    base field-length-base-type; fl-base-type;
    description "residue
      "Residue length in Byte is sent"; sent defined in
      for CoAP in RFC 8824 (cf. 5.3)";
  }

  identity fl-token-length {
    base field-length-base-type; fl-base-type;
    description "residue
      "Residue length in Byte is sent"; sent defined in
      for CoAP in RFC 8824 (cf. 4.5)";
  }

  //---------------------------------
  // Direction Indicator type
  //---------------------------------

  identity direction-indicator-base-type di-base-type {
    description "used
      "Used to extend field length functions";
  }

  identity di-bidirectional {
    base direction-indicator-base-type; di-base-type;
    description
      "Direction Indication of bi directionality"; directionality in
      RFC 8724 (cf. 7.1)";
  }

  identity di-up {
    base direction-indicator-base-type; di-base-type;
    description
      "Direction Indication of upstream"; upstream defined in
      RFC 8724 (cf. 7.1)";
  }

  identity di-down {
    base direction-indicator-base-type; di-base-type;
    description
      "Direction Indication of downstream"; downstream defined in
      RFC 8724 (cf. 7.1)";
  }

  //----------------------------------
  // Matching Operator type definition
  //----------------------------------

  identity matching-operator-base-type mo-base-type {
    description "used
      "Used to extend Matching Operators with SID values";
  }

  identity mo-equal {
    base matching-operator-base-type; mo-base-type;
    description "RFC 8724";
      "Equal MO as defined RFC 8724 (cf. 7.3)";
  }

  identity mo-ignore {
    base matching-operator-base-type; mo-base-type;
    description "RFC 8724";
      "Ignore MO as defined RFC 8724 (cf. 7.3)";
  }

  identity mo-msb {
    base matching-operator-base-type; mo-base-type;
    description "RFC 8724";
      "MSB MO as defined RFC 8724 (cf. 7.3)";
  }

  identity mo-matching {
    base matching-operator-base-type; mo-base-type;
    description "RFC 8724";
      "match-mapping MO as defined RFC 8724 (cf. 7.3)";
  }

  //------------------------------
  // CDA type definition
  //------------------------------

  identity compression-decompression-action-base-type; cda-base-type {
    description
      "Compression Decompression Actions";
  }

  identity cda-not-sent {
    base compression-decompression-action-base-type; cda-base-type;
    description "RFC 8724";
      "not-sent CDA as defines in RFC 8724 (cf. 7.4)";
  }

  identity cda-value-sent {
    base compression-decompression-action-base-type; cda-base-type;
    description "RFC 8724";
      "value-sent CDA as defines in RFC 8724 (cf. 7.4)";
  }

  identity cda-lsb {
    base compression-decompression-action-base-type; cda-base-type;
    description "RFC 8724";
      "LSB CDA as defines in RFC 8724 (cf. 7.4)";
  }

  identity cda-mapping-sent {
    base compression-decompression-action-base-type; cda-base-type;
    description "RFC 8724";
      "mapping-sent CDA as defines in RFC 8724 (cf. 7.4)";
  }

  identity cda-compute-length {
    base compression-decompression-action-base-type; cda-base-type;
    description "RFC 8724";
      "compute-length CDA as defines in RFC 8724 (cf. 7.4)";
  }
  identity cda-compute-checksum {
    base compression-decompression-action-base-type; cda-base-type;
    description "RFC 8724";
      "compute-checksum CDA as defines in RFC 8724 (cf. 7.4)";
  }

  identity cda-deviid {
    base compression-decompression-action-base-type; cda-base-type;
    description "RFC 8724";
      "deviid CDA as defines in RFC 8724 (cf. 7.4)";
  }

  identity cda-appiid {
    base compression-decompression-action-base-type; cda-base-type;
    description "RFC 8724";
      "appiid CDA as defines in RFC 8724 (cf. 7.4)";
  }

  // -- type definition

  typedef field-id-type fid-type {
    type identityref {
      base fid-base-type;
    }
    description
      "Field ID generic type.";
  }

  typedef fl-type {
    type union {
      type int64; /* positive length in bits */
      type identityref { /* function */
        base field-id-base-type; fl-base-type;
      }
    }

    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
  }

  typedef di-type {
    type int64; /* positive length in bits */
            type identityref { /* function */
      base field-length-base-type; di-base-type;
    }
        }
    }

    typedef direction-indicator-type {
    description "direction
      "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 mo-type {
    type identityref {
      base direction-indicator-base-type;
        } mo-base-type;
    }

    typedef matching-operator-type {
    description
      "Matching Operator (MO) to compare fields values with target values";
  }

  typedef cda-type {
    type identityref {
      base matching-operator-base-type;
        } cda-base-type;
    }

    typedef comp-decomp-action-type {
    description
      "Compression Decompression Action to compression or decompress a field.";
        type identityref {
            base compression-decompression-action-base-type;
        }
  }

  // -- FRAGMENTATION TYPE
  // -- fragmentation modes

  identity fragmentation-mode-base-type {
    description
      "fragmentation mode";
  }

  identity fragmentation-mode-no-ack {
    base fragmentation-mode-base-type;
    description
      "No Ack of RFC 8724.";
        base fragmentation-mode-base-type;
  }

  identity fragmentation-mode-ack-always {
    base fragmentation-mode-base-type;
    description
      "Ack Always of RFC8724.";
        base fragmentation-mode-base-type;
  }

  identity fragmentation-mode-ack-on-error {
    base fragmentation-mode-base-type;
    description
      "Ack on Error of RFC8724.";
        base fragmentation-mode-base-type;
  }

  typedef fragmentation-mode-type {
    type identityref {
      base fragmentation-mode-base-type;
    }
    description
      "type used in rules";

  }

  // -- Ack behavior

  identity ack-behavior-base-type {
    description "define
      "Define when to send an Acknowledgment message";
  }

  identity ack-behavior-after-All0 {
    base ack-behavior-base-type;
    description "fragmentation
      "Fragmentation expects Ack after sending All0 fragment.";
        base ack-behavior-base-type;
  }

  identity ack-behavior-after-All1 {
    base ack-behavior-base-type;
    description "fragmentation
      "Fragmentation expects Ack after sending All1 fragment.";
        base ack-behavior-base-type;
  }

  identity ack-behavior-always {
    base ack-behavior-base-type;
    description "fragmentation
      "Fragmentation expects Ack after sending every fragment.";
        base ack-behavior-base-type;
  }

  typedef ack-behavior-type {
    type identityref {
      base ack-behavior-base-type;
    }
    description
      "Type used in rules";
  }

  // -- All1 with data types

  identity all1-data-base-type {
    description "type
      "Type to define when to send an Acknowledgment message";
  }

  identity all1-data-no {
    base all1-data-base-type;
    description
      "All1 contains no tiles.";
        base all1-data-base-type;
  }
  identity all1-data-yes {
    base all1-data-base-type;
    description
      "All1 MUST contain a tile";
        base all1-data-base-type;
  }

  identity all1-data-sender-choice {
    base all1-data-base-type;
    description
      "Fragmentation process choose to send tiles or not in all1.";
        base all1-data-base-type;
  }

  typedef all1-data-type {
    type identityref {
      base all1-data-base-type;
    }
    description
      "Type used in rules";
  }

  // -- RCS algorithm types

  identity RCS-algorithm-base-type rcs-algorithm-base-type {
    description "identify
      "Identify which algorithm is used to compute RSC.
       The algorithm defines also defines the size if the RSC field.";
  }

  identity RFC8724-RCS rcs-RFC8724 {
    base rcs-algorithm-base-type;
    description
      "CRC 32 defined as default RCS in RFC8724.";
  }

  typedef rcs-algorithm-type {
    type identityref {
      base rcs-algorithm-base-type;
    }
    description
      "type used in rules";
  }

   // --- Bitmap format

  identity bitmap-format-base-type {
    description
      "Define how the bitmap is defined in ACK messages.";
  }
  identity bitmap-RFC8724 {
    base bitmap-format-base-type;
    description
      "Bitmap as defined in RFC8724.";
  }

  identity bitmap-compound-ack {
    base RCS-algorithm-base-type; bitmap-format-base-type;
    description
      "Compound Ack.";
  }

  typedef RCS-algorithm-type bitmap-format-type {
    type identityref {
      base RCS-algorithm-base-type; bitmap-format-base-type;
    }
    description
      "type used in rules";
  }

  // --------  RULE ENTRY DEFINITION ------------

  grouping target-values-struct tv-struct {
    description "defines
      "Define the target value element. Can be either an arbitrary
        binary or ascii element. All target values are considered as Always a matching lists.
        Position is used binary type, strings
       must be converted to order values, by default position 0 is used when containing
        a single element."; binary. field-id allows the conversion to the appropriate
       type.";
    leaf value {
      type union {
                type binary;
                type string;
            }
    }
    leaf position {
      type uint16;
      description
        "If only one element position is 0, otherwise position is the
         matching list.";
            type uint16;
    }
  }

  grouping compression-rule-entry {
    description
      "These entries defines a compression entry (i.e. a line)
       as defined in RFC 8724 and fragmentation parameters.

       +-------+--+--+--+------------+-----------------+---------------+
       |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 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 {
      type schc:fid-type;
      mandatory true;
      description
        "Field ID, identify a field in the header with a YANG refenceid.";
            mandatory true;
            type schc:field-id-type;
    }
    leaf field-length {
      type schc:fl-type;
      mandatory true;
      description
        "Field Length in bit or through a function defined as a YANG referenceid";
            mandatory true;
            type schc:field-length-type;
    }
    leaf field-position {
      type uint8;
      mandatory true;
      description "field
        "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 {
      type schc:di-type;
      mandatory true;
      description
        "Direction Indicator, a YANG referenceid to say if the packet is bidirectionnal, bidirectional,
         up or down";
            mandatory true;
            type schc:direction-indicator-type;
    }
    list target-values target-value {
      key "position";
      uses tv-struct;
      description "a
        "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 {
      type schc:mo-type;
      must "../target-value or derived-from-or-self(., 'mo-ignore')" {
        error-message "mo-equal, mo-msb and mo-match-mapping require 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;
            type schc:matching-operator-type;
      description
        "MO: Matching Operator";
    }
    list matching-operator-value {
      key position; "position";
      uses target-values-struct; tv-struct;
      description
        "Matching Operator Arguments, based on TV structure to allow several arguments.
         In RFC 8724, only MSB define a single argument: length in bits  ";
    }
    leaf comp-decomp-action {
      type schc:cda-type;
      mandatory true;
            type schc:comp-decomp-action-type;
      description
        "CDA: Compression Decompression Action";
    }
    list comp-decomp-action-value {
      key position; "position";
      uses target-values-struct; tv-struct;
      description
        "CDA Arguments, based on TV structure to allow several arguments.
         In RFC 8724, no argument is defined for CDA";
    }
  }

  grouping compression-content {
        description "define a compression rule composed of a list of entries.";
    list entry {
      key "field-id field-position direction-indicator";
      uses compression-rule-entry;
      description
        "A compression rule is a list of rule entry describing
         each 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 {
    description
      "This grouping defines the fragmentation parameters for
       all the modes (No Ack, Ack Always and Ack on Error) specified in
       RFC 8724.";
    leaf l2-word-size {
      type uint8;
      default "8";
      description
        "Size in bit of the layer 2 word";
    }
    leaf direction {
      must "derived-from-or-self(., 'di-up') or derived-from-or-self(., 'di-down')" {
        error-message "direction for fragmentation rules are up or down";
      }
      type schc:direction-indicator-type; schc:di-type;
      mandatory true;
      description "should
        "Should be up or down, bi directionnal is forbiden.";
            mandatory true;
    }
    leaf dtagsize dtag-size {
      type uint8;
      default "0";
      description "size
        "Size in bit of the DTag field";
    }
    leaf wsize w-size {
      when "not(derived-from(../fragmentation-mode, 'fragmentation-mode-no-ack'))";
      type uint8;
      description "size
        "Size in bit of the window field";
    }
    leaf fcnsize fcn-size {
      type uint8;
      mandatory true;
      description "size
        "Size in bit of the FCN field";
            mandatory true;
    }
    leaf RCS-algorithm rcs-algorithm {
      type RCS-algorithm-type; rcs-algorithm-type;
      default schc:RFC8724-RCS; "schc:rcs-RFC8724";
      description
        "Algoritm used for RCS";
    }
    leaf maximum-window-size {
      type uint16;
      description "by
        "By default 2^wsize - 1";
    }
    leaf retransmission-timer {
      type uint64 {
        range 1..max; "1..max";
      }
      description "duration
        "Duration in seconds of the retransmission timer"; // Check the units
    }
    leaf inactivity-timer {
      type uint64;
      description "duration
        "Duration is seconds of the inactivity timer, 0 indicates the timer is disabled"; // check units
    }
    leaf max-ack-requests {
      type uint8 {
        range 1..max; "1..max";
      }
      description "the
        "The maximum number of retries for a specific SCHC ACK.";
    }
    leaf maximum-packet-size {
      type uint16;
      default 1280; "1280";
      description
        "When decompression is done, packet size must not strictly exceed this limit in Bytes";
    }
    leaf fragmentation-mode {
      type schc:fragmentation-mode-type;
      mandatory true;
      description
        "which fragmentation mode is used (noAck, AckAlways, AckonError)";
            mandatory true;
    }
    choice mode {
      case no-ack;
      case ack-always;
      case ack-on-error {
        leaf tile-size {
          type uint8;
          when "derived-from(../fragmentation-mode, 'fragmentation-mode-ack-on-error')";
          description "size
            "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;
          when "derived-from(../fragmentation-mode, 'fragmentation-mode-ack-on-error')";
          description
            "When true, sender and receiver except a tile in All-1 frag";
        }
        leaf ack-behavior {
          type schc:ack-behavior-type;
          when "derived-from(../fragmentation-mode, 'fragmentation-mode-ack-on-error')";
          description
            "Sender behavior to acknowledge, after All-0, All-1 or when the
             LPWAN allows it (Always)";
        }
        leaf bitmap-format {
          type schc:bitmap-format-type;
          when "derived-from(../fragmentation-mode, 'fragmentation-mode-ack-on-error')";
          default "schc:bitmap-RFC8724";
          description
            "How the bitmaps are included in the Ack message.";
        }
      }
      description
        "RFC 8724 defines 3 fragmentation modes";
    }
  }

  // Define rule ID. Rule ID is composed of a RuleID value and a Rule ID Length

  grouping rule-id-type {
    leaf rule-id rule-id-value {
      type uint32;
      description "rule
        "Rule ID value, this value must be unique combined with the length";
    }
    leaf rule-length rule-id-length {
      type uint8 {
        range 0..32; "0..32";
      }
      description "rule
        "Rule ID length in bits, value 0 is for implicit rules";
    }
    description
      "A rule ID is composed of a value and a length in bit";
  }

  // SCHC table for a specific device.

  container schc {
        leaf version{
            type uint64;
            mandatory false;
            description "used as an indication for versioning";

        }
    list rule {
      key "rule-id rule-length"; "rule-id-value rule-id-length";
      uses rule-id-type;
      choice nature {
        case fragmentation {
          if-feature "fragmentation";
          uses fragmentation-content;
        }
        case compression {
          uses compression-content;
        }
        case no-compression {
          description
            "RFC8724 allows a rule for uncompressed headers";
        }
        description
          "A rule is either for compression, no compression or 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 rule which are either
       compression or fragmentation";
  }
}
<code ends>

                              Figure 23 24

8.  Normative References

   [I-D.barthel-lpwan-oam-schc]
              Barthel, D., Toutain, L., Kandasamy, A., Dujovne, D., and
              J. C. Zuniga, "OAM for LPWAN using Static Context Header
              Compression (SCHC)", draft-barthel-lpwan-oam-schc-02 (work Work in progress), Progress, Internet-Draft,
              draft-barthel-lpwan-oam-schc-02, 2 November 2020.

   [I-D.ietf-lpwan-coap-static-context-hc]
              Minaburo, A., 2020,
              <https://www.ietf.org/archive/id/draft-barthel-lpwan-oam-
              schc-02.txt>.

   [I-D.ietf-lpwan-schc-compound-ack]
              Zuniga, J. C., Gomez, C., Aguilar, S., Toutain, L.,
              Cespedes, S., and R. Andreasen, "LPWAN Static
              Context Header Compression (SCHC) for CoAP", draft-ietf-
              lpwan-coap-static-context-hc-18 (work in progress),
              January 2021. D. Wistuba, "SCHC Compound ACK", Work in
              Progress, Internet-Draft, draft-ietf-lpwan-schc-compound-
              ack-00, 9 July 2021, <https://www.ietf.org/archive/id/
              draft-ietf-lpwan-schc-compound-ack-00.txt>.

   [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.
              Zuniga,
              Zúñiga, "SCHC: Generic Framework for Static Context Header
              Compression and Fragmentation", RFC 8724,
              DOI 10.17487/RFC8724, April 2020,
              <https://www.rfc-editor.org/info/rfc8724>.

   [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>.

Authors' Addresses

   Ana Minaburo
   Acklio
   1137A avenue des Champs Blancs
   35510 Cesson-Sevigne Cedex
   France

   Email: ana@ackl.io

   Laurent Toutain
   Institut MINES TELECOM; IMT Atlantique
   2 rue de la Chataigneraie
   CS 17607
   35576 Cesson-Sevigne Cedex
   France

   Email: Laurent.Toutain@imt-atlantique.fr