<?xml version="1.0" encoding="UTF-8"?>
<!--  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>-->
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.3 -->
<?xml-model href="rfc7991bis.rnc"?> version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]>

<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc strict="yes"?>
<?rfc compact="yes"?>
<?rfc toc="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" submissionType="IETF" consensus="true" number="9441" docName="draft-ietf-lpwan-schc-compound-ack-17" category="std" updates="8724,9363"> obsoletes="" updates="8724,9363" symRefs="true" sortRefs="true" tocInclude="true" xml:lang="en" version="3">
  <!-- xml2rfc v2v3 conversion 3.17.3 -->
  <front>
    <title abbrev="SCHC Compound ACK">
     SCHC
     Static Context Header Compression (SCHC) Compound ACK Acknowledgement (ACK)
    </title>
    <seriesInfo name="RFC" value="9441"/>
    <author fullname="Juan Carlos Zuniga" Zúñiga" initials="JC." surname="Zuniga"> surname="Zúñiga">
      <organization abbrev="Cisco">
        Cisco
      </organization>
      <address>
        <postal>
          <street></street>
          <street/>
          <city>Montreal</city>
          <code> QC</code>
          <code>QC</code>
          <country>Canada</country>
        </postal>
        <email>juzuniga@cisco.com</email>
      </address>
    </author>
    <author initials="C." surname="Gomez" fullname="Carles Gomez">
      <organization>Universitat Politecnica Politècnica de Catalunya</organization>
      <address>
        <postal>
          <street>C/Esteve Terradas, 7</street>
          <street>08860 Castelldefels</street>
          <country>Spain</country>
        </postal>
        <email>carles.gomez@upc.edu</email>
      </address>
    </author>
    <author initials="S." surname="Aguilar" fullname="Sergio Aguilar">
      <organization>Universitat Politecnica Politècnica de Catalunya</organization>
      <address>
        <postal>
          <street>C/Esteve Terradas, 7</street>
          <street>08860 Castelldefels</street>
          <country>Spain</country>
        </postal>
        <email>sergio.aguilar.romero@upc.edu</email>
      </address>
    </author>
    <author initials="L." surname="Toutain" fullname="Laurent Toutain">
      <organization>IMT-Atlantique</organization>
      <address>
        <postal>
          <street>2 rue de la Chataigneraie</street>
          <street>CS 17607</street>
          <city>35576 Cesson-Sevigne Cedex</city>
          <country>France</country>
        </postal>
        <email>Laurent.Toutain@imt-atlantique.fr</email>
      </address>
    </author>
    <author initials="S." surname="Cespedes" surname="Céspedes" fullname="Sandra Cespedes"> Céspedes">
      <organization>Concordia University</organization>
      <address>
        <postal>
          <street>1455 De Maisonneuve Blvd. W.</street>
          <city>Montreal QC, H3G 1M8</city>
          <country>Canada</country>
        </postal>
        <email>sandra.cespedes@concordia.ca</email>
      </address>
    </author>
    <author initials="D." surname="Wistuba" fullname="Diego Wistuba">
      <organization>NIC Labs, Universidad de Chile</organization>
      <address>
        <postal>
          <street>Av. Almte. Blanco Encalada 1975</street>
          <street>Santiago</street>
          <country>Chile</country>
        </postal>
        <email>wistuba@niclabs.cl</email>
        <email>research@witu.cl</email>
      </address>
    </author>
    <date year="2023" month="April" day="5"/>

    <workgroup>lpwan Working Group</workgroup> month="July"/>
    <workgroup>lpwan</workgroup>
<keyword>SCHC</keyword>
<keyword>LPWAN</keyword>
<keyword>IoT</keyword>
<keyword>Fragmentation</keyword>
<keyword>Reliable Delivery</keyword>
<keyword>Link Layer Protocols</keyword>
<keyword>Cross-Layer Protocols</keyword>
<keyword>Adaptation Layer</keyword>
<keyword>Acknowledgment</keyword>
<keyword>Sigfox</keyword>
<keyword>LoRaWAN</keyword>
<keyword>NB-IoT</keyword>
<keyword>Compound ACK</keyword>
    <abstract>

<t>The present
      <t>This document updates the SCHC (Static Static Context Header Compression (SCHC) and fragmentation) fragmentation protocol RFC8724 (RFC 8724) and the corresponding Yang Module RFC9363. YANG module (RFC 9363). It defines a SCHC Compound ACK Acknowledgement (ACK) message
format and procedure, which are intended to reduce the number of response transmissions (i.e., SCHC ACKs) in the ACK-on-Error mode, Mode, by accumulating bitmaps of several windows in a single SCHC message
(i.e., the SCHC Compound ACK). </t>
      <t>Both the message format and procedure are generic, so they can be used, for instance, by any of the four Low Power Low-Power Wide Area Networks (LPWANs) Network (LPWAN) technologies defined in RFC8376, being RFC 8376, which are Sigfox, LoRaWAN, NB-IoT Long Range Wide Area Network (LoRaWAN), Narrowband Internet of Things (NB-IoT), and IEEE 802.15.4w.

</t>
    </abstract>
  </front>
  <middle>
    <section anchor="Introduction" title="Introduction"> anchor="Introduction">
      <name>Introduction</name>
      <t>The Generic Framework for Static Context Header Compression (SCHC) and Fragmentation (SCHC) specification <xref target="RFC8724"/> describes two mechanisms:
i) a protocol header compression scheme, scheme and ii) a frame fragmentation and loss recovery functionality. Either can be used on top of radio technologies technologies, such as the four Low Power Low-Power Wide Area Networks (LPWANs) listed in <xref target="RFC8376"/>, being which are Sigfox, LoRaWAN, NB-IoT NB-IoT, and IEEE 802.15.4w. These LPWANs have similar characteristics characteristics, such as star-oriented topologies, network architecture, and
connected devices with built-in applications, etc. applications.
</t>
      <t>SCHC offers a great level of flexibility to accommodate all these LPWAN technologies. Even though there are a great number of similarities between
them, some differences exist with respect to the transmission characteristics, payload sizes, etc. Hence, there are optimal parameters and modes of operation
that can be used when SCHC is used on top of a specific LPWAN technology.
</t>
      <t>
   In ACK-on-Error mode in <xref target="RFC8724"/> target="RFC8724"/>, the SCHC Packet is fragmented into pieces called tiles, with where all tiles of are the same size except for the last one, which can be smaller. Successive tiles are grouped in windows of fixed size.
    A SCHC Fragment carries one or several contiguous tiles, which may span multiple windows. When sending all tiles from all windows, the last tile is sent in an All-1 SCHC Fragment. The SCHC receiver, after receiving the All-1 SCHC Fragment receiver will send a SCHC ACK reporting on the reception of exactly one window of tiles. tiles after receiving the All-1 SCHC Fragment. In case of SCHC Fragment losses, a bitmap is added to the failure SCHC ACK, where each bit in the bitmap corresponds to a tile in the window. If SCHC Fragment losses span multiple windows, the SCHC receiver will send one failure SCHC ACK per window with losses.
</t>

    <t>The present
      <t>This document updates the SCHC protocol for frame fragmentation and loss recovery. It defines a SCHC Compound ACK format and procedure, which
is
are intended to reduce the number of response transmissions (i.e., SCHC ACKs) in the ACK-on-Error mode of SCHC. The SCHC Compound ACK extends the failure SCHC ACK message
format so that it can contain several bitmaps, with each bitmap being identified by its corresponding window number.
The SCHC Compound ACK is backwards compatible with the SCHC ACK as defined in <xref target="RFC8724"/>, and introduces flexibility, as the receiver has the capability to respond to the All-0 SCHC Fragment, providing more downlink opportunities, Downlink opportunities and therefore adjusting to the delay requirements of the application.
</t>
    </section>
    <section anchor="terminology" title="Terminology">
<t>The anchor="terminology">
      <name>Terminology</name>
      <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and
   "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in
   BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t> here.
      </t>
      <t>It is assumed that the reader is familiar with the terms and mechanisms defined in <xref target="RFC8376"/> and
in <xref target="RFC8724"/>.
</t>
    </section>
    <section anchor="schc-compound-ack" title="SCHC anchor="schc-compound-ack">
      <name>SCHC Compound ACK"> ACK</name>
      <t>The SCHC Compound ACK is a failure SCHC ACK message that can contain several bitmaps, with each bitmap being identified by its
corresponding window number.
    In <xref target="RFC8724"/>, the failure SCHC ACK message only contain contains one bitmap corresponding to one window.
    The SCHC Compound ACK extends this format format, allowing more windows to be acknowledged in a single ACK, ACK and reducing the total number of failure SCHC ACK messages, specially especially when fragment losses are present in intermediate windows.
</t>
      <t>The SCHC Compound ACK MAY <bcp14>MAY</bcp14> be used in fragmentation modes that use windows and that allow
reporting the bitmaps of multiple windows at the same time, and MUST NOT time; otherwise, the SCHC Compound ACK <bcp14>MUST NOT</bcp14> be used otherwise. used.
</t>
      <t>The SCHC Compound ACK:</t>

<t><list style="symbols">
<t>provides
      <ul spacing="normal">
        <li>provides feedback only for windows with fragment losses,</t>
<t>has losses,</li>
        <li>has a variable size that depends on the number of windows with fragment losses being reported in the single Compound SCHC ACK,</t>
<t>includes Compound ACK,</li>
        <li>includes the window number (i.e., W) of each bitmap,</t>
<!--has the same SCHC ACK format defined in <xref target="RFC8724"/> when only one window with losses is reported,-->
<t>might bitmap,</li>
<li>might not cover all windows with fragment losses of a SCHC Packet,</t>
<t>and is Packet, and</li>
        <li>is distinguishable from the SCHC Receiver-Abort.</t>
</list></t> Receiver-Abort.</li>
      </ul>
      <section anchor="schc-ack-format-1B" title="SCHC anchor="schc-ack-format-1B">
        <name>SCHC Compound ACK Message Format"> Format</name>
        <t><xref target="success-ack-1byte"/> shows the success SCHC ACK format, i.e., when all fragments have been correctly received (C=1), as defined in <xref target="RFC8724"/>. </t>

<t><figure title="SCHC
        <figure anchor="success-ack-1byte">
          <name>SCHC Success ACK message format, Message Format, as defined Defined in RFC8724" anchor="success-ack-1byte"><artwork><![CDATA[

               |-- RFC 8724</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
               |--- SCHC ACK Header --|
                        |--T-|---M--| ---|
               |        |--T-|--M--| 1 |
               +--------+----+------+---+~~~~~~~~~~~~~~~~~~
               +--------+----+-----+---+~~~~~~~~~~~~~~~~~~
               | RuleID |DTag|  W  |C=1| padding as needed
               +--------+----+------+---+~~~~~~~~~~~~~~~~~~

]]></artwork></figure></t>
               +--------+----+-----+---+~~~~~~~~~~~~~~~~~~
]]></artwork>
        </figure>
        <t>In case SCHC Fragment losses are found in any of the windows of the SCHC Packet, the SCHC Compound ACK MAY <bcp14>MAY</bcp14> be used.
The SCHC Compound ACK message format is shown in Figures <xref target="compound-ack-1byte"/> target="compound-ack-1byte" format="counter"/> and <xref target="compound-ack-less-M-padding"/>. target="compound-ack-less-M-padding" format="counter"/>.

</t>
<t><figure title="SCHC
        <figure anchor="compound-ack-1byte">
          <name>SCHC Compound ACK message format" anchor="compound-ack-1byte"><artwork><![CDATA[ Message Format. Losses are found in windows W = w1,...,wi, where w1 &lt; w2 &lt;...&lt; wi.
</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
  |--- SCHC ACK Header --|- W=w1 -|...|---- W=wi -----|
         |--T-|---M--|-1-|        |...|---M--|        |---M--|
  +------+----+------+---+--------+...+------+--------+------+~~~~~+
  |RuleID|DTag| W=w1 |C=0| Bitmap |...| W=wi | Bitmap |00..00| pad |
  +------+----+------+---+--------+...+------+--------+------+~~~~~+
                            next L2 Word boundary ->|<-- L2 Word ->|

     Losses are found in windows W = w1,...,wi; where w1<w2<...<wi

]]></artwork></figure></t>
]]></artwork>
        </figure>
        <t>The SCHC Compound ACK groups the window number (W) with its corresponding bitmap.
Window numbers do not need to be contiguous. However, the window numbers and its their corresponding bitmaps included in the SCHC Compound ACK message MUST <bcp14>MUST</bcp14> be ordered from the lowest-numbered to the highest-numbered window.
Hence, if the bitmap of window number zero is present in the SCHC Compound ACK message, it MUST <bcp14>MUST</bcp14> always be the first one in order and its W window number MUST <bcp14>MUST</bcp14> be placed in the SCHC ACK Header.</t>
        <t>If M or more padding bits would be needed after the last bitmap in the message to fill the last L2 layer two (L2) Word, M bits at 0 MUST <bcp14>MUST</bcp14> be appended after the last bitmap, and then padding is applied as needed (see <xref target="compound-ack-1byte"/>).
<!-- The M bits with 0 value signal the end of the SCHC Compound ACK.
To avoid confusing the M '0s' padding bits with Window number 0, if present in the SCHC Compound ACK, Window number 0 MUST be placed as w1. -->
Since window number 0, if 0 (if present in the message, message) is placed as w1, the M bits set to zero can't be confused with window number 0,
and therefore 0;
therefore, they signal the end of the SCHC Compound ACK message.
<!-- The RECOMMENDED value for the padding bits is 0. -->
</t>
        <t> <xref target="compound-ack-less-M-padding"/> shows the case when the required padding bits are strictly less than M bits.
    In this case, the layer-2 MTU (Maximum L2 Maximum Transmission Unit) Unit (MTU) does not leave room for any extra window value, let alone any bitmap,
	thereby signaling the end of the SCHC Compound ACK message.
<!--    The RECOMMENDED padding value is 0. -->
</t>

<t><figure title="SCHC
        <figure anchor="compound-ack-less-M-padding">
          <name>SCHC Compound ACK message format Message Format with less Less than M padding bits" anchor="compound-ack-less-M-padding"><artwork><![CDATA[ Padding Bits. Losses are found in windows W = w1,...,wi, where w1  &lt; w2  &lt;...&lt; wi.</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
  |--- SCHC ACK Header --|- W=w1 -|...|---- W=wi -----|
         |--T-|---M--|-1-|        |...|---M--|        |---M--|
  +------+----+------+---+--------+...+------+--------+~~~+
  |RuleID|DTag| W=w1 |C=0| Bitmap |...| W=wi | Bitmap |pad|
  +------+----+------+---+--------+...+------+--------+~~~+
                                  next L2 Word boundary ->|
     Losses are found in windows W = w1,...,wi; where w1<w2<...<wi

    ]]></artwork></figure></t>
   ]]></artwork>
        </figure>
        <t>The SCHC Compound ACK MUST NOT <bcp14>MUST NOT</bcp14> use the Compressed Bitmap format for intermediate windows/bitmaps (i.e., bitmaps that are not the last one of the SCHC Compound ACK message), and
therefore message); therefore, intermediate bitmaps bitmap fields MUST <bcp14>MUST</bcp14> be of size WINDOW_SIZE.
Hence, the SCHC Compound ACK MAY <bcp14>MAY</bcp14> use a Compressed Bitmap format only for the last bitmap in the message.
The optional usage of this Compressed Bitmap for the last bitmap MUST <bcp14>MUST</bcp14> be specified by the SCHC technology-specific profile.</t> SCHC Profile.</t>

        <t> The case where the last bitmap is effectively compressed corresponds to <xref target="compound-ack-less-M-padding"/>,
    with the last bitmap ending, by construction, ending (by construction) on an L2 Word boundary, therefore resulting in no padding at all.</t>
        <t><xref target="compound-ack-compressed-bitmap-1"/> illustrates a bitmap compression example of a SCHC Compound ACK,
    where the bitmap of the last window (wi) indicates that the first tile has not been correctly
    received.
    Because the compression algorithm resulted in effective compression, no padding is needed.
        </t>

<t><figure title="SCHC
        <figure anchor="compound-ack-compressed-bitmap-1">
          <name>SCHC Compound ACK message format Message Format with compressed bitmap" anchor="compound-ack-compressed-bitmap-1"><artwork><![CDATA[ Compressed Bitmap and No Padding Added. Losses are found in windows W = w1,...,wi, where w1 &lt; w2 &lt;...&lt; wi.</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
  |--- SCHC ACK Header --|- W=w1 -|...|-------- W=wi -------|
         |--T-|---M--|-1-|        |...|---M--|
  +------+----+------+---+--------+...+------+--------------+
  |RuleID|DTag| W=w1 |C=0| Bitmap |...| W=wi |0 1 1 1 1 1 1 |
  +------+----+------+---+--------+...+------+--------------+
                         next L2 Word boundary ->|

                 SCHC Compound ACK with uncompressed Uncompressed Bitmap

  |--- SCHC ACK Header --|- W=w1 -|...|-- W=wi --|
         |--T-|---M--|-1-|        |...|---M--|
  +------+----+------+---+--------+...+------+---+
  |RuleID|DTag| W=w1 |C=0| Bitmap |...| W=wi |0 1|
  +------+----+------+---+--------+...+------+---+
                         next L2 Word boundary ->|

        Transmitted SCHC Compound ACK with compressed Compressed Bitmap

   Losses are found in windows W = w1,...,wi; where w1<w2<...<wi

]]></artwork></figure></t>
]]></artwork>
        </figure>
       <t><xref target="compound-ack-compressed-bitmap"/> illustrates another bitmap compression example of a SCHC Compound ACK,
    where the bitmap of the last window (wi) indicates that the second and the fourth tile tiles have not been correctly
    received.
    In this example, the compression algorithm does not result in effective compression of the last bitmap.
    Besides, because more than M bits of padding would be needed to fill the last L2 Word, M bits at 0 are appended to the message before padding is applied.
        </t>
<t><figure title="SCHC
        <figure anchor="compound-ack-compressed-bitmap">
          <name>SCHC Compound ACK message format Message Format with compressed bitmap" anchor="compound-ack-compressed-bitmap"><artwork><![CDATA[ Compressed Bitmap and Padding Added to Reach the L2 Boundary. Losses are found in windows W = w1,...,wi, where w1 &lt; w2 &lt;...&lt;wi.</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
 |--- SCHC ACK Header --|-W=w1-|...|-------- W=wi -------|
        |--T-|---M--|-1-|      |...|---M--|
 +------+----+------+---+------+...+------+--------------+
 |RuleID|DTag| W=w1 |C=0|Bitmap|...| W=wi |1 0 1 0 1 1 1 |
 +------+----+------+---+------+...+------+--------------+
                    next L2 Word boundary ->|

                 SCHC Compound ACK with uncompressed Uncompressed Bitmap

 |--- SCHC ACK Header --|-W=w1-|...|-------- W=wi -------|
        |--T-|---M--|-1-|      |...|---M--|              |---M--|
 +------+----+------+---+------+...+------+--------------+------+~~~+
 |RuleID|DTag| W=w1 |C=0|Bitmap|...| W=wi |1 0 1 0 1 1 1 |00..00|pad|
 +------+----+------+---+------+...+------+--------------+------+~~~+
                    next L2 Word boundary ->|<------ L2 Word ------>|

                  Transmitted SCHC Compound ACK

      Losses are found in windows W = w1,...,wi; where w1<w2<...<wi

]]></artwork></figure></t>
]]></artwork>
        </figure>
        <t>If a SCHC sender gets a SCHC Compound ACK with invalid W's, window numbers, such as duplicate W values or W values not sent yet, it MUST <bcp14>MUST</bcp14> discard the whole
	SCHC Compound ACK message.</t>

<t>Note: because it has a C bit reset to 0, the
        <aside><t>Note that SCHC Compound ACK is ACKs are distinguishable from the Receiver-Abort message <xref target="RFC8724"/>, which has in the same way that regular SCHC ACKs are distinguishable, since the Receiver-Abort pattern never occurs in a C bit set to 1.</t> legitimate SCHC Compound ACK <xref target="RFC8724"/>.</t></aside>
      </section>
      <section anchor="schc-compound-ack-behaviour" title="SCHC anchor="schc-compound-ack-behavior">
        <name>SCHC Compound ACK Behaviour"> Behavior</name>
        <t>The SCHC ACK-on-Error behaviour behavior is described in section 8.4.3 of <xref target="RFC8724"/>. target="RFC8724" section="8.4.3" sectionFormat="of" />. The present document slightly modifies this behaviour,
since in behavior.  In the baseline SCHC specification specification, a SCHC ACK reports only one bitmap for the reception of exactly one window of tiles. The present SCHC
Compound ACK specification extends the SCHC ACK message format so that it can contain several bitmaps, with each bitmap being identified by its corresponding
window number.</t>
<t>The SCHC ACK format, as
        <t>As presented in <xref target="RFC8724"/>, the SCHC ACK format can be considered a special SCHC Compound ACK case, case in which it reports only the tiles of one window. Therefore, the SCHC Compound ACK is backwards compatible with the SCHC ACK format presented in <xref target="RFC8724"/>.
The receiver can suspect if assume that the sender does not support the SCHC Compound ACK, if ACK if, although the SCHC Compound ACK sent by the receiver reports losses in more than one window, the sender does not resend any tiles from windows that are not other than the first one window reported in the SCHC Compound ACK and more ACKs are needed. ACK. In that case, the receiver can send SCHC Compound ACKs with only one window of tiles.</t>
        <t>Also, some flexibility is introduced with respect to <xref target="RFC8724"/>, target="RFC8724"/> in that the receiver has the capability to respond (or not) to the All-0 with a SCHC Compound ACK or not, ACK, depending on certain parameters, like network conditions, sender buffer/chache buffer/cache size, and supported application delay. Note that even though the protocol allows for such flexibility, the
actual decision criteria is not specified in this document. The application MUST <bcp14>MUST</bcp14> set expiration timer values according to when the feedback is expected to be received, e.g., after the All-0 or after the All-1.</t>

<t>The following <xref
        <t><xref target="ACK-on-Error-subsection"/> (and its subsections) replaces the complete sections 8.4.3 Section <xref target="RFC8724" section="8.4.3" sectionFormat="bare"/> (and its subsections) of RFC 8724.
<!--For the convenience of the reader, the added text to the original RFC 8724 is highlighted with *** NEW TEXT *** and the deleted text from RFC 8724 is delimited by &#45;&#45; OLD TEXT &#45;&#45;.--> <xref target="RFC8724"/>.
</t>
<!--<t>The following sections describe the differences between the baseline SCHC specification and the present SCHC protocol extension specification.-->
<!--New text is between ** NEW TEXT **. Old text is &#45;&#45; OLD TEXT &#45;&#45;. New text replaces old text.-->

<!--</t>-->
           <section anchor="ACK-on-Error-subsection" numbered="true" toc="include" removeInRFC="false" pn="section-8.4.3">
          <name slugifiedName="name-ack-on-error-mode">ACK-on-Error Mode</name>
          <t pn="section-8.4.3-1">The anchor="ACK-on-Error-subsection">
          <name>ACK-on-Error Mode (Replaces Section 8.4.3, RFC 8724)</name>
          <t>The ACK-on-Error mode supports L2 technologies that have variable MTU and out-of-order delivery.
It requires an L2 that provides a feedback path from the reassembler to the fragmenter.
See Appendix F <xref target="RFC8724" section="F" sectionFormat="bare"/> for a discussion on using ACK-on-Error mode on quasi-bidirectional links.</t>
          <t pn="section-8.4.3-2">In
          <t>In ACK-on-Error mode, windows are used.</t>
          <t pn="section-8.4.3-3">All
          <t>All tiles except the last one and the penultimate one <bcp14>MUST</bcp14> be of equal size, hereafter called "regular".
The size of the last tile <bcp14>MUST</bcp14> be smaller than or equal to the regular tile size.
Regarding the penultimate tile, a Profile <bcp14>MUST</bcp14> pick one of the following two options:</t>
          <ul spacing="normal" bare="false" empty="false" pn="section-8.4.3-4">
            <li pn="section-8.4.3-4.1">The spacing="normal">
            <li>The penultimate tile size <bcp14>MUST</bcp14> be the regular tile size, or</li>
            <li pn="section-8.4.3-4.2">the
            <li>the penultimate tile size <bcp14>MUST</bcp14> be either the regular tile size or the regular tile size minus one L2 Word.</li>
          </ul>
          <t pn="section-8.4.3-5">A
          <t>A SCHC Fragment message carries one or several contiguous tiles, which may span multiple windows.
            A SCHC Compound ACK reports on the reception of one window of tiles or several windows of tiles, each one identified by its window number.
          </t>
          <t pn="section-8.4.3-6">See
          <t>See <xref target="Fig-TilesACKonError" format="default" sectionFormat="of" derivedContent="Figure 23"/> target="Fig-TilesACKonError"/> (see <eref target="https://www.rfc-editor.org/rfc/rfc8724.html#figure-23">Figure 23 of RFC 8724</eref>) for an example.</t>
          <figure anchor="Fig-TilesACKonError" align="left" suppress-title="false" pn="figure-23">
            <name slugifiedName="name-schc-packet-fragmented-in-til">SCHC anchor="Fig-TilesACKonError">
            <name>SCHC Packet Fragmented in Tiles, ACK-on-Error Mode</name> Mode (Figure 23 in RFC 8724)</name>
            <artwork name="" type="" align="left" alt="" pn="section-8.4.3-7.1"> alt=""><![CDATA[
        +---------------------------------------------...-----------+
        |                       SCHC Packet                         |
        +---------------------------------------------...-----------+

Tile#   | 4 | 3 | 2 | 1 | 0 | 4 | 3 | 2 | 1 | 0 | 4 |     | 0 | 4 |3|
Window# |-------- 0 --------|-------- 1 --------|- 2  ... 27 -|- 28-|

SCHC Fragment msg   |-----------|</artwork>   |-----------|
]]></artwork>
          </figure>
          <t pn="section-8.4.3-8">The
          <t>The W field is wide enough that it unambiguously represents an absolute window number.
The fragment receiver sends SCHC Compound ACKs to the fragment sender about windows for which tiles are missing.
No SCHC Compound ACK is sent by the fragment receiver for windows that it knows have been fully received.</t>
          <t pn="section-8.4.3-9">The
          <t>The fragment sender retransmits SCHC Fragments for tiles that are reported missing.
It can advance to next windows even before it has ascertained that all tiles belonging to previous windows have been correctly received,
and it can still later retransmit SCHC Fragments with tiles belonging to previous windows.
Therefore, the sender and the receiver may operate in a decoupled fashion.
The fragmented SCHC Packet transmission concludes when:</t>
          <ul spacing="normal" bare="false" empty="false" pn="section-8.4.3-10">
            <li pn="section-8.4.3-10.1">integrity spacing="normal">
            <li>integrity checking shows that the fragmented SCHC Packet has been correctly reassembled at the receive end,
and this information has been conveyed back to the sender, or</li>
            <li pn="section-8.4.3-10.2">too sender,</li>
            <li>too many retransmission attempts were have been made, or</li>
            <li pn="section-8.4.3-10.3">the
            <li>the receiver determines that the transmission of this fragmented SCHC Packet has been inactive for too long.</li>
          </ul>
          <t pn="section-8.4.3-11">Each
          <t>Each Profile <bcp14>MUST</bcp14> specify which RuleID value(s) corresponds to SCHC F/R messages operating in this mode.</t>
          <t pn="section-8.4.3-12">The
          <t>The W field <bcp14>MUST</bcp14> be present in the SCHC F/R messages.</t>
          <t pn="section-8.4.3-13">Each
          <t>Each Profile, for each RuleID value, <bcp14>MUST</bcp14> define:</t>
          <ul spacing="normal" bare="false" empty="false" pn="section-8.4.3-14">
            <li pn="section-8.4.3-14.1">the spacing="normal">
            <li>the tile size (a tile does not need to be multiple a duplicate of an L2 Word, but it <bcp14>MUST</bcp14> be at least the size of an L2 Word),</li>
            <li pn="section-8.4.3-14.2">the
            <li>the value of M,</li>
            <li pn="section-8.4.3-14.3">the
            <li>the value of N,</li>
            <li pn="section-8.4.3-14.4">the
            <li>the value of WINDOW_SIZE, which <bcp14>MUST</bcp14> be strictly less than 2^N,</li>
            <li pn="section-8.4.3-14.5">the 2<sup>N</sup>,</li>
            <li>the size and algorithm for the RCS field,</li>
            <li pn="section-8.4.3-14.6">the
            <li>the value of T,</li>
            <li pn="section-8.4.3-14.7">the
            <li>the value of MAX_ACK_REQUESTS,</li>
            <li pn="section-8.4.3-14.8">the
            <li>the expiration time of the Retransmission Timer,</li>
            <li pn="section-8.4.3-14.9">the
            <li>the expiration time of the Inactivity Timer,</li>
            <li pn="section-8.4.3-14.10">if
            <li>if the last tile is carried in a Regular SCHC Fragment or an All-1 SCHC Fragment (see Section 8.4.3.1), and</li>
            <li pn="section-8.4.3-14.11">if <xref target="ACK-on-Error-sender"/> (Section <xref target="RFC8724" sectionFormat="bare" section="8.4.3.1"/> in <xref target="RFC8724"/>),</li>
            <li>if the penultimate tile <bcp14>MAY</bcp14> be one L2 Word smaller than the regular tile size. In size (in this case, the regular tile size <bcp14>MUST</bcp14> be at least twice the L2 Word size.</li>
<!--              <li pn="section-8.4.3-14.12">if the SCHC Compound ACK is used.</li>-->
              <li pn="section-8.4.3-14.12">Usage size),</li>
              <li>usage or not of the SCHC Compound ACK message.</li>
              <li pn="section-8.4.3-14.13">Usage message, and</li>
            <li>usage or not of the compressed bitmap Compressed Bitmap format in the last window of the SCHC Compound ACK message.</li>
          </ul>
          <t pn="section-8.4.3-15">For
          <t>For each active pair of RuleID and DTag values, the sender <bcp14>MUST</bcp14> maintain:</t>
          <ul spacing="normal" bare="false" empty="false" pn="section-8.4.3-16">
            <li pn="section-8.4.3-16.1">one spacing="normal">
            <li>one Attempts counter, counter and</li>
            <li pn="section-8.4.3-16.2">one
            <li>one Retransmission Timer.</li>
          </ul>
          <t pn="section-8.4.3-17">For
          <t>For each active pair of RuleID and DTag values, the receiver <bcp14>MUST</bcp14> maintain:</t>
          <ul spacing="normal" bare="false" empty="false" pn="section-8.4.3-18">
            <li pn="section-8.4.3-18.1">one Inactivity Timer, and</li>
            <li pn="section-8.4.3-18.2">one spacing="normal">
            <li>one Attempts counter.</li> counter and</li>
            <li>one Inactivity Timer.</li>
          </ul>
          <section anchor="ACK-on-Error-sender" numbered="true" toc="exclude" removeInRFC="false" pn="section-8.4.3.1">
            <name slugifiedName="name-sender-behavior-3">Sender Behavior</name>
            <t pn="section-8.4.3.1-1">At anchor="ACK-on-Error-sender">
            <name>Sender Behavior (Replaces Section 8.4.3.1, RFC 8724)</name>
            <t>At the beginning of the fragmentation of a new SCHC Packet:</t>
            <ul spacing="normal" bare="false" empty="false" pn="section-8.4.3.1-2">
              <li pn="section-8.4.3.1-2.1">the spacing="normal">
              <li>the fragment sender <bcp14>MUST</bcp14> select a RuleID and DTag value pair for this SCHC Packet.
A Rule <bcp14>MUST NOT</bcp14> be selected if the values of M and WINDOW_SIZE for that Rule are such that the SCHC Packet cannot be fragmented in (2^M) (2<sup>M</sup>) * WINDOW_SIZE tiles or less.</li>
              <li pn="section-8.4.3.1-2.2">the
              <li>the fragment sender <bcp14>MUST</bcp14> initialize the Attempts counter to 0 for that RuleID and DTag value pair.</li>
            </ul>
            <t pn="section-8.4.3.1-3">A
            <t>A Regular SCHC Fragment message carries in its payload one or more tiles.
If more than one tile is carried in one Regular SCHC Fragment:</t>
            <ul spacing="normal" bare="false" empty="false" pn="section-8.4.3.1-4">
              <li pn="section-8.4.3.1-4.1">the spacing="normal">
              <li>the selected tiles <bcp14>MUST</bcp14> be contiguous in the original SCHC Packet, and</li>
              <li pn="section-8.4.3.1-4.2">they
              <li>they <bcp14>MUST</bcp14> be placed in the SCHC Fragment Payload adjacent to one another, in the order they appear in the SCHC Packet, from the start of the SCHC Packet toward its end.</li>
            </ul>
            <t pn="section-8.4.3.1-5">Tiles
            <t>Tiles that are not the last one <bcp14>MUST</bcp14> be sent in Regular SCHC Fragments as specified in Section 8.3.1.1. <xref target="RFC8724" section="8.3.1.1" sectionFormat="bare"/>.
The FCN field <bcp14>MUST</bcp14> contain the tile index of the first tile sent in that SCHC Fragment.</t>
            <t pn="section-8.4.3.1-6">In
            <t>In a Regular SCHC Fragment message, the sender <bcp14>MUST</bcp14> fill the W field with the window number of the first tile sent in that SCHC Fragment.</t>
            <t pn="section-8.4.3.1-7">A
            <t>A Profile <bcp14>MUST</bcp14> define if the last tile of a SCHC Packet is sent:</t>
            <ul spacing="normal" bare="false" empty="false" pn="section-8.4.3.1-8">
              <li pn="section-8.4.3.1-8.1">in spacing="normal">
              <li>in a Regular SCHC Fragment, alone or as part of a multi-tiles Payload,</li>
              <li pn="section-8.4.3.1-8.2">alone
              <li>alone in an All-1 SCHC Fragment, or</li>
              <li pn="section-8.4.3.1-8.3">with any
              <li>with either one of the above two methods.</li>
            </ul>
            <t pn="section-8.4.3.1-9">In
            <t>In an All-1 SCHC Fragment message, the sender <bcp14>MUST</bcp14> fill the W field with the window number of the last tile of the SCHC Packet.</t>
            <t pn="section-8.4.3.1-10">The
            <t>The fragment sender <bcp14>MUST</bcp14> send SCHC Fragments such that, all together, they contain all the tiles of the fragmented SCHC Packet.</t>
            <t pn="section-8.4.3.1-11">The
            <t>The fragment sender <bcp14>MUST</bcp14> send at least one All-1 SCHC Fragment.</t>
            <t pn="section-8.4.3.1-12">In
            <t>In doing the two items above, the sender <bcp14>MUST</bcp14> ascertain that the receiver will not receive the last tile through both a Regular SCHC Fragment and an All-1 SCHC Fragment.</t>
            <t pn="section-8.4.3.1-13">The
            <t>The fragment sender <bcp14>MUST</bcp14> listen for SCHC Compound ACK messages after having sent:</t>
            <ul spacing="normal" bare="false" empty="false" pn="section-8.4.3.1-14">
              <li pn="section-8.4.3.1-14.1">an spacing="normal">
              <li>an All-1 SCHC Fragment, Fragment or</li>
              <li pn="section-8.4.3.1-14.2">a
              <li>a SCHC ACK REQ.</li>
            </ul>
            <t pn="section-8.4.3.1-15">A
            <t>A Profile <bcp14>MAY</bcp14> specify other times at which the fragment sender <bcp14>MUST</bcp14> listen for SCHC Compound ACK messages.
For example, this could be after sending a complete window of tiles.</t>
            <t pn="section-8.4.3.1-16">Each
            <t>Each time a fragment sender sends an All-1 SCHC Fragment or a SCHC ACK REQ:</t>
            <ul spacing="normal" bare="false" empty="false" pn="section-8.4.3.1-17">
              <li pn="section-8.4.3.1-17.1">it spacing="normal">
              <li>it <bcp14>MUST</bcp14> increment the Attempts counter, and</li>
              <li pn="section-8.4.3.1-17.2">it
              <li>it <bcp14>MUST</bcp14> reset the Retransmission Timer.</li>
            </ul>
            <t pn="section-8.4.3.1-18">On
            <t>On Retransmission Timer expiration:</t>
            <ul spacing="normal" bare="false" empty="false" pn="section-8.4.3.1-19">
              <li pn="section-8.4.3.1-19.1">if spacing="normal">
              <li>if the Attempts counter is strictly less than MAX_ACK_REQUESTS,
the fragment sender <bcp14>MUST</bcp14> send
either the All-1 SCHC Fragment or
a SCHC ACK REQ with the W field corresponding to the last window,</li>
              <li pn="section-8.4.3.1-19.2">otherwise,
              <li>otherwise, the fragment sender <bcp14>MUST</bcp14> send a SCHC Sender-Abort, and
it <bcp14>MAY</bcp14> exit with an error condition.</li>
            </ul>
            <t pn="section-8.4.3.1-20">All
            <t>All message receptions being discussed in the rest of this section are to be understood as
"matching the RuleID and DTag pair being processed", even if not spelled out, for brevity.</t>
            <t pn="section-8.4.3.1-21">On
            <t>On receiving a SCHC Compound ACK:</t>
            <ul spacing="normal" bare="false" empty="false" pn="section-8.4.3.1-22">
              <li pn="section-8.4.3.1-22.1">
                <t pn="section-8.4.3.1-22.1.1">if spacing="normal">
              <li>
                <t>if one of the W field fields in the SCHC Compound ACK corresponds to the last window of the SCHC Packet:</t>
                <ul spacing="normal" bare="false" empty="false" pn="section-8.4.3.1-22.1.2">
                  <li pn="section-8.4.3.1-22.1.2.1">if spacing="normal">
                  <li>if the C bit is set, the sender <bcp14>MAY</bcp14> exit successfully.</li>
                  <li pn="section-8.4.3.1-22.1.2.2">
                    <t pn="section-8.4.3.1-22.1.2.2.1">otherwise:
                  <li>
                    <t>otherwise:      </t>
                    <ul spacing="normal" bare="false" empty="false" pn="section-8.4.3.1-22.1.2.2.2">
                      <li pn="section-8.4.3.1-22.1.2.2.2.1">
                        <t pn="section-8.4.3.1-22.1.2.2.2.1.1">if spacing="normal">
                      <li>
                        <t>if the Profile mandates that the last tile be sent in an All-1 SCHC Fragment:</t>
                        <ul spacing="normal" bare="false" empty="false" pn="section-8.4.3.1-22.1.2.2.2.1.2">
                          <li pn="section-8.4.3.1-22.1.2.2.2.1.2.1">
                            <t pn="section-8.4.3.1-22.1.2.2.2.1.2.1.1">if spacing="normal">
                          <li>
                            <t>if the SCHC Compound ACK shows no missing tile at the receiver, the sender:</t>
                            <ul spacing="normal" bare="false" empty="false" pn="section-8.4.3.1-22.1.2.2.2.1.2.1.2">
                              <li pn="section-8.4.3.1-22.1.2.2.2.1.2.1.2.1"> spacing="normal">
                              <li>
                                <bcp14>MUST</bcp14> send a SCHC Sender-Abort, Sender-Abort and</li>
                              <li pn="section-8.4.3.1-22.1.2.2.2.1.2.1.2.2">
                              <li>
                                <bcp14>MAY</bcp14> exit with an error condition.</li>
                            </ul>
                          </li>
                          <li pn="section-8.4.3.1-22.1.2.2.2.1.2.2">
                            <t pn="section-8.4.3.1-22.1.2.2.2.1.2.2.1">otherwise:</t>
                          <li>
                            <t>otherwise:</t>
                            <ul spacing="normal" bare="false" empty="false" pn="section-8.4.3.1-22.1.2.2.2.1.2.2.2">
                              <li pn="section-8.4.3.1-22.1.2.2.2.1.2.2.2.1">the spacing="normal">
                              <li>the fragment sender <bcp14>MUST</bcp14> send SCHC Fragment messages containing all the tiles of all the windows that are reported missing in the SCHC Compound ACK.</li>
                              <li pn="section-8.4.3.1-22.1.2.2.2.1.2.2.2.2">if
                              <li>if the last of these SCHC Fragment messages is not an All-1 SCHC Fragment, then the fragment sender MAY <bcp14>MAY</bcp14> either send send, in addition addition, a SCHC ACK REQ with the W field corresponding to the last window, window or repeat the All-1 SCHC Fragment to ask the receiver confirmation to confirm that all tiles have been correctly received.
</li>
                              <li pn="section-8.4.3.1-22.1.2.2.2.1.2.2.2.3">in
                              <li>in doing the two items above, the sender <bcp14>MUST</bcp14> ascertain that the receiver will not receive the last tile through both a Regular SCHC Fragment and an All-1 SCHC Fragment.</li>
                            </ul>
                          </li>
                        </ul>
                      </li>
                      <li pn="section-8.4.3.1-22.1.2.2.2.2">
                        <t pn="section-8.4.3.1-22.1.2.2.2.2.1">otherwise:</t>
                      <li>
                        <t>otherwise:</t>
                        <ul spacing="normal" bare="false" empty="false" pn="section-8.4.3.1-22.1.2.2.2.2.2">
                          <li pn="section-8.4.3.1-22.1.2.2.2.2.2.1">if spacing="normal">
                          <li>if the SCHC Compound ACK shows no missing tile at the receiver, the sender
<bcp14>MUST</bcp14> send the All-1 SCHC Fragment</li>
                          <li pn="section-8.4.3.1-22.1.2.2.2.2.2.2">
                            <t pn="section-8.4.3.1-22.1.2.2.2.2.2.2.1">otherwise:</t>
                          <li>
                            <t>otherwise:</t>
                            <ul spacing="normal" bare="false" empty="false" pn="section-8.4.3.1-22.1.2.2.2.2.2.2.2">
                              <li pn="section-8.4.3.1-22.1.2.2.2.2.2.2.2.1">the spacing="normal">
                              <li>the fragment sender <bcp14>MUST</bcp14> send SCHC Fragment messages containing all the tiles that are reported missing in the SCHC Compound ACK.</li>
                              <li pn="section-8.4.3.1-22.1.2.2.2.2.2.2.2.2">the
                              <li>the fragment sender <bcp14>MUST</bcp14> then send
either the All-1 SCHC Fragment or
a SCHC ACK REQ with the W field corresponding to the last window.</li>
                            </ul>
                          </li>
                        </ul>
                      </li>
                    </ul>
                  </li>
                </ul>
              </li>
              <li pn="section-8.4.3.1-22.2">
                <t pn="section-8.4.3.1-22.2.1">otherwise,
              <li>
                <t>otherwise, the fragment sender:</t>
                <ul spacing="normal" bare="false" empty="false" pn="section-8.4.3.1-22.2.2">
                  <li pn="section-8.4.3.1-22.2.2.1"> spacing="normal">
                  <li>
                    <bcp14>MUST</bcp14> send SCHC Fragment messages containing the tiles that are reported missing in the SCHC Compound ACK.</li>
                  <li pn="section-8.4.3.1-22.2.2.2">then,
                  <li>then, it <bcp14>MAY</bcp14> send a SCHC ACK REQ with the W field corresponding to the last window.</li>
                </ul>
              </li>
            </ul>
            <t pn="section-8.4.3.1-23">See Figure 43/>
            <t>See <eref target="https://www.rfc-editor.org/rfc/rfc8724.html#figure-43">Figure 43</eref> for one among several possible examples of a Finite State Machine implementing a sender behavior obeying this specification.</t>
          </section>
          <section anchor="ACK-on-Error-receiver" numbered="true" toc="exclude" removeInRFC="false" pn="section-8.4.3.2">
            <name slugifiedName="name-receiver-behavior-3">Receiver Behavior</name>
            <t pn="section-8.4.3.2-1">On anchor="ACK-on-Error-receiver">
            <name>Receiver Behavior (Replaces Section 8.4.3.2, RFC 8724)</name>
            <t>On receiving a SCHC Fragment with a RuleID and DTag pair not being processed at that time:</t>
            <ul spacing="normal" bare="false" empty="false" pn="section-8.4.3.2-2">
              <li pn="section-8.4.3.2-2.1">the spacing="normal">
              <li>the receiver <bcp14>SHOULD</bcp14> check if that the DTag value has not recently been used for that RuleID value,
thereby ensuring that the received SCHC Fragment is not a remnant of a prior fragmented SCHC Packet transmission.
The initial value of the Inactivity Timer is the <bcp14>RECOMMENDED</bcp14> lifetime for the DTag value at the receiver.
If the SCHC Fragment is determined to be such a remnant, the receiver <bcp14>MAY</bcp14> silently ignore it and discard it.</li>
              <li pn="section-8.4.3.2-2.2">the
              <li>the receiver <bcp14>MUST</bcp14> start a process to assemble a new SCHC Packet with that RuleID and DTag value pair.
The receiver <bcp14>MUST</bcp14> start an Inactivity Timer for that RuleID and DTag value pair.
It <bcp14>MUST</bcp14> initialize an Attempts counter to 0 for that RuleID and DTag value pair.
If the receiver is under-resourced to do this, it <bcp14>MUST</bcp14> respond to the sender with a SCHC Receiver-Abort.</li>
            </ul>
            <t pn="section-8.4.3.2-3">On
            <t>On reception of any SCHC F/R message for the RuleID and DTag pair being processed, the receiver <bcp14>MUST</bcp14> reset the Inactivity Timer pertaining to that RuleID and DTag pair.</t>
            <t pn="section-8.4.3.2-4">All
            <t>All message receptions being discussed in the rest of this section are to be understood as
"matching the RuleID and DTag pair being processed", even if not spelled out, for brevity.</t>
            <t pn="section-8.4.3.2-5">On
            <t>On receiving a SCHC Fragment message,
the receiver determines what tiles were received, based on the payload length and on the W and FCN fields of the SCHC Fragment.</t>
            <ul spacing="normal" bare="false" empty="false" pn="section-8.4.3.2-6">
              <li pn="section-8.4.3.2-6.1">if spacing="normal">
              <li>if the FCN is All-1, All-1 and if a Payload is present, the full SCHC Fragment Payload <bcp14>MUST</bcp14> be assembled including the padding bits.
This is because the size of the last tile is not known by the receiver;
therefore, padding bits are indistinguishable from the tile data bits, at this stage.
They will be removed by the SCHC C/D sublayer.
If the size of the SCHC Fragment Payload exceeds or equals
the size of one regular tile plus the size of an L2 Word, this <bcp14>SHOULD</bcp14> raise an error flag.</li>
              <li pn="section-8.4.3.2-6.2">
                <t pn="section-8.4.3.2-6.2.1">otherwise,
              <li>
                <t>otherwise, tiles <bcp14>MUST</bcp14> be assembled based on the a priori known tile size.
                </t>
                <ul spacing="normal" bare="false" empty="false" pn="section-8.4.3.2-6.2.2">
                  <li pn="section-8.4.3.2-6.2.2.1">If spacing="normal">
                  <li>If allowed by the Profile, the end of the payload <bcp14>MAY</bcp14> contain the last tile, which may be shorter. Padding bits are indistinguishable from the tile data bits, at this stage.</li>
                  <li pn="section-8.4.3.2-6.2.2.2">The
                  <li>The payload may contain the penultimate tile that, if allowed by the Profile, <bcp14>MAY</bcp14> be exactly one L2 Word shorter than the regular tile size.</li>
                  <li pn="section-8.4.3.2-6.2.2.3">
                    <t pn="section-8.4.3.2-6.2.2.3.1">Otherwise,
                  <li>
                    <t>Otherwise, padding bits <bcp14>MUST</bcp14> be discarded.
This is possible because:</t>
                    <ul spacing="normal" bare="false" empty="false" pn="section-8.4.3.2-6.2.2.3.2">
                      <li pn="section-8.4.3.2-6.2.2.3.2.1">the spacing="normal">
                      <li>the size of the tiles is known a priori,</li>
                      <li pn="section-8.4.3.2-6.2.2.3.2.2">tiles
                      <li>tiles are larger than an L2 Word, and</li>
                      <li pn="section-8.4.3.2-6.2.2.3.2.3">padding
                      <li>padding bits are always strictly less than an L2 Word.</li>
                    </ul>
                  </li>
                </ul>
              </li>
            </ul>
            <t pn="section-8.4.3.2-7">On
            <t>On receiving a SCHC All-0 SCHC Fragment:</t>
            <ul spacing="normal" bare="false" empty="false" pn="section-8.4.3.2-8">
                  <li pn="section-8.4.3.2-8.1">if spacing="normal">
              <li>if the receiver knows of any windows with missing tiles for the packet being reassembled (and depending on certain parameters, like network conditions, sender buffer/chache buffer/cache size, and supported application delay, among others), it MAY <bcp14>MAY</bcp14> return a SCHC Compound ACK for the missing tiles, starting from the lowest-numbered window.
                  </li>
            </ul>
            <t pn="section-8.4.3.2-9">On
            <t>On receiving a SCHC ACK REQ or an All-1 SCHC Fragment:</t>
            <ul spacing="normal" bare="false" empty="false" pn="section-8.4.3.2-10">
              <li pn="section-8.4.3.2-10.1">if spacing="normal">
              <li>if the receiver knows of any windows with missing tiles for the packet being reassembled, it
<bcp14>MUST</bcp14> return a SCHC Compound ACK for the missing tiles, starting from the lowest-numbered window.</li>
              <li pn="section-8.4.3.2-10.2">
                <t pn="section-8.4.3.2-10.2.1">otherwise:
              <li>
                <t>otherwise:
                </t>
                <ul spacing="normal" bare="false" empty="false" pn="section-8.4.3.2-10.2.2">
                  <li pn="section-8.4.3.2-10.2.2.1">if spacing="normal">
                  <li>if it has received at least one tile, it <bcp14>MUST</bcp14> return a SCHC Compound ACK for the highest-numbered window it currently has tiles for,</li>
                  <li pn="section-8.4.3.2-10.2.2.2">otherwise,
                  <li>otherwise, it <bcp14>MUST</bcp14> return a SCHC Compound ACK for window numbered number 0.</li>
                </ul>
              </li>
            </ul>
            <t pn="section-8.4.3.2-11">A
            <t>A Profile <bcp14>MAY</bcp14> specify other times and circumstances at which
a receiver sends a SCHC Compound ACK, ACK
and which window the SCHC Compound ACK reports about in these circumstances.</t>
            <t pn="section-8.4.3.2-12">Upon
            <t>Upon sending a SCHC Compound ACK, the receiver <bcp14>MUST</bcp14> increase the Attempts counter.</t>
            <t pn="section-8.4.3.2-13">After
            <t>After receiving an All-1 SCHC Fragment,
a receiver <bcp14>MUST</bcp14> check the integrity of the reassembled SCHC Packet at least every time
it prepares for sending to send a SCHC Compound ACK for the last window.</t>
            <t pn="section-8.4.3.2-14">Upon
            <t>Upon receiving a SCHC Sender-Abort,
the receiver <bcp14>MAY</bcp14> exit with an error condition.</t>
            <t pn="section-8.4.3.2-15">Upon
            <t>Upon expiration of the Inactivity Timer,
the receiver <bcp14>MUST</bcp14> send a SCHC Receiver-Abort,
and it <bcp14>MAY</bcp14> exit with an error condition.</t>
            <t pn="section-8.4.3.2-16">On
            <t>On the Attempts counter exceeding MAX_ACK_REQUESTS,
the receiver <bcp14>MUST</bcp14> send a SCHC Receiver-Abort,
and it <bcp14>MAY</bcp14> exit with an error condition.</t>
            <t pn="section-8.4.3.2-17">Reassembly
            <t>Reassembly of the SCHC Packet concludes when:</t>
            <ul spacing="normal" bare="false" empty="false" pn="section-8.4.3.2-18">
              <li pn="section-8.4.3.2-18.1">a spacing="normal">
              <li>a Sender-Abort has been received, or</li>
              <li pn="section-8.4.3.2-18.2">the received,</li>
              <li>the Inactivity Timer has expired, or</li>
              <li pn="section-8.4.3.2-18.3">the expired,</li>
              <li>the Attempts counter has exceeded MAX_ACK_REQUESTS, or</li>
              <li pn="section-8.4.3.2-18.4">at
              <li>at least an All-1 SCHC Fragment has been received and integrity checking of the reassembled SCHC Packet is successful.</li>
            </ul>
            <t pn="section-8.4.3.2-19">See Figure 44
            <t>See <eref target="https://www.rfc-editor.org/rfc/rfc8724.html#figure-44">Figure 44</eref> for one among several possible examples of a Finite State Machine implementing a receiver behavior obeying this specification. The example provided is meant to match the sender Finite State Machine of Figure 43.</t> <eref target="https://www.rfc-editor.org/rfc/rfc8724.html#figure-43">Figure 43</eref>.</t>
          </section>
        </section>
      </section>

<!--<section anchor="sender-behaviour" title="Sender Behaviour">-->

<!--<t>OLD TEXT (<xref target="RFC8724"/>, section 8.4.3.1) - On receiving a SCHC ACK:</t>-->

<!--<t><list style="symbols">-->
<!--<t>(...)</t>-->
<!--<t>the fragment sender MUST send SCHC Fragment messages containing all the tiles that are reported missing in the SCHC ACK.</t>-->
<!--<t>if the last of these SCHC Fragment messages is not an All-1 SCHC Fragment, then the fragment sender MUST in addition send-->
<!--after it a SCHC ACK REQ with the W field corresponding to the last window.</t>-->
<!--</list></t>-->

<!--<t>NEW TEXT - On receiving a SCHC Compound ACK:</t>-->

<!--<t><list style="symbols">-->
<!--<t>(...)</t>-->
<!--<t>the fragment sender MUST send SCHC Fragment messages containing all the tiles of all the windows that are reported missing in the-->
<!--SCHC Compound ACK.</t>-->
<!--<t>if the last of these SCHC Fragment messages reported missing is not an All-1 SCHC Fragment, then the fragment sender MAY either,-->
<!--send in addition a SCHC ACK REQ with the W field corresponding to the last window, continue the transmission of the remaining fragments to be-->
<!--transmitted, or repeat the All-1 fragment to confirm that all fragments have been correctly received.</t>-->
<!--</list></t>-->

<!--</section>-->

<!--<section anchor="receiver-behaviour" title="Receiver Behaviour">-->

<!--<t>OLD TEXT (<xref target="RFC8724"/>, section 8.4.3.2) - On receiving a SCHC ACK REQ or an All-1 SCHC Fragment:</t>-->

<!--<t><list style="symbols">-->
<!--<t>if the receiver knows of any windows with missing tiles for the packet being reassembled, it MUST return a SCHC ACK for the-->
<!--lowest-numbered such window.</t>-->
<!--</list></t>-->

<!--<t>NEW TEXT: On receiving an All-0 SCHC Fragment:</t>-->

<!--<t><list style="symbols">-->
<!--<t>if the receiver knows of any windows with missing tiles for the packet being reassembled (and if network conditions are known to be conducive),-->
<!--it MAY return a SCHC Compound ACK for the missing tiles, starting from the lowest-numbered window.</t>-->
<!--</list></t>-->

<!--<t>NEW TEXT: On receiving a SCHC ACK REQ or an All-1 SCHC Fragment:</t>-->

<!--<t><list style="symbols">-->
<!--<t>if the receiver knows of any windows with missing tiles for the packet being reassembled, it MUST return a SCHC Compound ACK for the missing tiles, starting from the lowest-numbered window.</t>-->
<!--</list></t>-->

<!--</section>-->
</section>
    <section anchor="schc-compound-ack-examples" title="SCHC anchor="schc-compound-ack-examples">
      <name>SCHC Compound ACK Example"> Example</name>
      <t><xref target="compound-ack-ex-ex"/> shows an example transmission of a SCHC Packet in ACK-on-Error mode using the SCHC Compound ACK.
In the example, the SCHC Packet is fragmented in 14 tiles, with N=3, WINDOW_SIZE=7, M=2 M=2, and two lost SCHC fragments.
Only 1 compound SCHC Compound ACK is generated.</t>

<t><figure title="SCHC
      <figure anchor="compound-ack-ex-ex">
        <name>SCHC Compound ACK message sequence example" anchor="compound-ack-ex-ex"><artwork><![CDATA[ Message Sequence Example</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
        Sender                Receiver
          |-----W=0, FCN=6 ----->|
          |-----W=0, FCN=5 ----->|
          |-----W=0, FCN=4 ----->|
          |-----W=0, FCN=3 ----->|
          |-----W=0, FCN=2 --X   |
          |-----W=0, FCN=1 ----->|
          |-----W=0, FCN=0 ----->| Bitmap: 1111011
      (no ACK)
          |-----W=1, FCN=6 ----->|
          |-----W=1, FCN=5 ----->|
          |-----W=1, FCN=4 ----->|
          |-----W=1, FCN=3 ----->|
          |-----W=1, FCN=2 ----->|
          |-----W=1, FCN=1 --X   |
          |-- W=1, FCN=7 + RCS ->| Integrity check: failure
          |<--- Compound ACK ----| [C=0, W=0 - Bitmap:1111011,
          |-----W=0, FCN=2 ----->|        W=1 - Bitmap:1111101]
          |-----W=1, FCN=1 ----->| Integrity check: success
          |<--- ACK, W=1, C=1 ---| C=1
        (End)
]]></artwork></figure></t>

<t><figure title="SCHC
]]></artwork>
      </figure>
      <figure anchor="compound-ack-fmt-ex">
        <name>SCHC Compound ACK message format example: Message Format Example: Losses are found Found in windows Windows 00 and 01" anchor="compound-ack-fmt-ex"><artwork><![CDATA[ 01</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
 |--- SCHC ACK Header --|- W=00 --|----- W=01 -----|
        |--T-|---M--|-1-|         |---M--|         |---M--|
 +------+----+------+---+---------+------+---------+------+-----+
 |RuleID|DTag| W=00 |C=0| 1111011 | W=01 | 1111101 |  00  | pad |
 +------+----+------+---+---------+------+---------+------+-----+
                         next L2 Word boundary ->|<-- L2 Word ->|

]]></artwork></figure></t>
]]></artwork>
      </figure>
    </section>
    <section anchor="schc-compound-ack-yang-model" title="SCHC anchor="schc-compound-ack-yang-model">
      <name>SCHC Compound ACK YANG Data Model">

<t>The present Model</name>
      <t>This document also extends the SCHC YANG data model defined in <xref target="RFC9363"/> by including
a new leaf in the Ack-on-Error fragmentation mode to describe both the option to use the SCHC Compound ACK, as well as its bitmap format. </t>
      <section anchor="yang-model" title="SCHC anchor="yang-model">
        <name>SCHC YANG Data Model Extension">

<t><figure title="SCHC Extension</name>
        <figure anchor="schc-data-model">
          <name>SCHC YANG Data Model - Compound ACK extension" anchor="schc-data-model"><artwork><![CDATA[

<CODE BEGINS> file "ietf-lpwan-schc-compound-ack@2023-03-16.yang" Extension</name>
          <sourcecode markers="true" name="ietf-schc-compound-ack@2023-07-22.yang" type="yang"><![CDATA[
module ietf-lpwan-schc-compound-ack ietf-schc-compound-ack {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:"
          + "ietf-lpwan-schc-compound-ack"; "urn:ietf:params:xml:ns:yang:ietf-schc-compound-ack";
  prefix schc-compound-ack;

  import ietf-schc {
    prefix schc;
  }

  organization
    "IETF IPv6 over Low Power Wide-Area Networks (lpwan)
     working group";
     Working Group";
  contact
    "WG Web:   <https://datatracker.ietf.org/wg/lpwan/about/>
     WG List:  <mailto:lp-wan@ietf.org>
     Editor:   Laurent Toutain
       <mailto:laurent.toutain@imt-atlantique.fr>
     Editor:   Juan Carlos Zuniga
       <mailto:j.c.zuniga@ieee.org>
     Editor:   Sergio Aguilar
       <mailto:sergio.aguilar.romero@upc.edu>";
  description
    "Copyright (c) 2023 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 Revised 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 9363
     (https://www.rfc-editor.org/info/rfc9363); 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 the Static Context Header Compression
     Rule for SCHC, based on RFCs 8724 and 8824.  Including
     compression, no-compression, and fragmentation Rules.";

  revision 2023-03-16 2023-07-22 {
    description
      "Initial version for RFC YYYY "; 9441.";
    reference
      "RFC YYYY: SCHC 9441 Static Context Header Compression (SCHC) Compound ACK";
                Acknowledgement (ACK)";
  }

  identity bitmap-format-base-type {
    description
      "Define how the bitmap is formed in ACK messages.";
  }

  identity bitmap-RFC8724 {
    base bitmap-format-base-type;
    description
      "Bitmap by default as defined in RFC8724."; RFC 8724.";
    reference
      "RFC 8724 SCHC: Generic Framework for Static Context Header
                Compression and Fragmentation";
  }

  identity bitmap-compound-ack {
    base bitmap-format-base-type;
    description
      "Compound ACK allows several bitmaps in a an ACK message.";
  }

  typedef bitmap-format-type {
    type identityref {
      base bitmap-format-base-type;
    }
    description
      "Type of bitmap used in rules."; Rules.";
  }

  augment "/schc:schc/schc:rule/schc:nature/"
        + "schc:fragmentation/schc:mode/schc:ack-on-error" {
    leaf bitmap-format {
      when "derived-from-or-self(../schc:fragmentation-mode,
                        'schc:fragmentation-mode-ack-on-error')";
      type schc-compound-ack:bitmap-format-type;
      default "schc-compound-ack:bitmap-RFC8724";
      description
        "How the bitmaps are included in the SCHC ACK message.";
    }
    leaf last-bitmap-compression {
      when "derived-from-or-self(../schc:fragmentation-mode,
                        'schc:fragmentation-mode-ack-on-error')";
      type boolean;
      default "true";
      description
        "When true true, the ultimate bitmap in the SCHC ACK message
         can be compressed.  Default behavior from RFC8724"; RFC 8724.";
      reference
        "RFC 8724 SCHC: Generic Framework for Static Context Header
                  Compression and Fragmentation";
    }
    description
      "Augment the SCHC rules Rules to manage Compound Ack."; ACK.";
  }
}

<CODE ENDS>

]]></artwork></figure></t>
]]></sourcecode>
        </figure>
      </section>
      <section anchor="yang-tree" title="SCHC anchor="yang-tree">
        <name>SCHC YANG Tree Extension">

<t><figure title="Tree Extension</name>
        <figure anchor="schc-data-tree">
          <name>Tree Diagram - Compound ACK extension" anchor="schc-data-tree"><artwork><![CDATA[ Extension</name>
          <sourcecode type="yangtree"><![CDATA[
module: ietf-lpwan-schc-compound-ack ietf-schc-compound-ack
  augment /schc:schc/schc:rule/schc:nature/schc:fragmentation/
        schc:mode/schc:ack-on-error:
    +--rw bitmap-format?        schc-compound-ack:bitmap-format-type
    +--rw last-bitmap-compression?   boolean

]]></artwork></figure></t>
]]></sourcecode>
        </figure>
      </section>
    </section>

<!--</section>-->
<section anchor="schc-compound-ack-parameters" title="SCHC anchor="schc-compound-ack-parameters">
      <name>SCHC Compound ACK Parameters"> Parameters</name>
      <t>This section lists the parameters related to the SCHC Compound ACK usage that need to be defined in the Profile.
    This list MUST <bcp14>MUST</bcp14> be appended to the list of SCHC parameters under "Decision to use SCHC fragmentation mechanism or not. If yes, the document must describe:" as defined in Annex D Appendix <xref target="RFC8724" sectionFormat="bare" section="D"/> of <xref target="RFC8724"/>.
</t>

<t><list style="symbols">
<t>Usage or not of
      <ul spacing="normal">
        <li>whether the SCHC Compound ACK message.</t>
<t>Usage message is used or not of not, and</li>
        <li>whether the compressed bitmap format in the last window of the SCHC Compound ACK message.</t>
</list></t> message is used or not.</li>
      </ul>
    </section>
    <section anchor="security-considerations" title="Security considerations">

<t>The current anchor="security-considerations">
      <name>Security Considerations</name>
      <t>This document specifies a message format extension for SCHC.
    Hence, the same Security Considerations security considerations defined in <xref target="RFC8724"/>
      and in <xref target="RFC9363"/> apply.</t>
      <t>The YANG module specified in this document defines a schema for data that is designed to be accessed via network management protocols such as NETCONF <xref target="RFC6241"/> or RESTCONF <xref target="RFC8040"/>. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) <xref target="RFC6242"/>. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS <xref target="RFC8446"/>.</t>
      <t>The Network Configuration Access Control Model (NACM) <xref target="RFC8341"/> provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content.</t>
      <t>There are a number of data nodes defined in this YANG module that are
   writable/creatable/deletable (i.e., config true, which is the
   default).  These data nodes may be considered sensitive or vulnerable
   in some network environments.  Write operations (e.g., edit-config)
   to these data nodes without proper protection can have a negative
   effect on network operations.  These are the subtrees and data nodes
      and their sensitivity/vulnerability:

   /schc:schc/schc:rule/schc:nature/schc:fragmentation/schc:mode/schc:ack-on-error:
   All sensitivity/vulnerability:</t>
<dl newline="true" spacing="normal">
  <dt>/schc:schc/schc:rule/schc:nature/schc:fragmentation/schc:mode/schc:ack-on-error:</dt>
  <dd>All the data nodes may be modified. The Rule contains sensitive information, such
    as the SCHC F/R mode configuration and usage and configuration of the SCHC Compound ACK. ACK configuration.
    An attacker may try to modify other devices' Rules by changing the F/R mode or the
    usage of the SCHC Compound ACK and may block communication or create extra ACKs.
     Therefore, a device must be allowed to modify only
      its own rules Rules on the remote SCHC instance.  The identity of the
      requester must be validated.  This can be done through
  certificates or access lists.

   Some lists.</dd>
</dl>
   <t>Some of the readable data nodes in this YANG module may be considered
   sensitive or vulnerable in some network environments.  It is thus
   important to control read access (e.g., via get, get-config, or
   notification) to these data nodes.  These are the subtrees and data
   nodes and their sensitivity/vulnerability:

   /schc:schc/schc:rule/schc:nature/schc:fragmentation/schc:mode/schc:ack-on-error:
    By sensitivity/vulnerability:</t>
<dl newline="true" spacing="normal">
  <dt>/schc:schc/schc:rule/schc:nature/schc:fragmentation/schc:mode/schc:ack-on-error:</dt>
  <dd>By reading this module, an attacker may learn the F/R mode used by the device
    and device,
    how the device manage manages the bitmap creation and also learn creation, the buffer sizes sizes, and when the device will request an ACK.

    </t> ACK.</dd>
</dl>
    </section>
    <section anchor="ianaconsiderations" title="IANA Considerations"> anchor="ianaconsiderations">
      <name>IANA Considerations</name>
      <t> This document registers one URI and one YANG data model.</t>
      <section anchor="uri_registration" title="URI Registration"> anchor="uri_registration">
        <name>URI Registration</name>
        <t>
       IANA registered the following URI in the "IETF XML Registry"
        <xref target="RFC3688"/>:
        </t>

<t><list>
<t>URI:  urn:ietf:params:xml:ns:yang:ietf-lpwan-schc-compound-ack</t>
<t>Registrant Contact:  The IESG.</t>
<t>XML:  N/A;
        <dl newline="false">
          <dt>URI:</dt>  <dd>urn:ietf:params:xml:ns:yang:ietf-schc-compound-ack</dd>
          <dt>Registrant Contact:</dt>  <dd>The IESG.</dd>
          <dt>XML:</dt>  <dd>N/A; the requested URI is an XML namespace.</t>
</list></t> namespace.</dd>
        </dl>
      </section>
      <section anchor="module_name_registration" title="YANG anchor="module_name_registration">
        <name>YANG Module Name Registration"> Registration</name>
        <t> IANA has registered the following YANG data model in the "YANG Module
   Names" registry <xref target="RFC6020"/>.</t>
        <t><list>
<t> name:  ietf-lpwan-schc-compound-ack</t>
<t>namespace:  urn:ietf:params:xml:ns:yang:ietf-lpwan-schc-compound-ack</t>
<t>prefix:  schc-compound-ack</t>
<t>reference:  RFC </t>
</list></t>
        <dl newline="false">
          <dt>name:</dt>  <dd>ietf-schc-compound-ack</dd>
          <dt>namespace:</dt> <dd>urn:ietf:params:xml:ns:yang:ietf-schc-compound-ack</dd>
          <dt>prefix:</dt>  <dd>schc-compound-ack</dd>
          <dt>reference:</dt>  <dd>RFC 9441</dd>
        </dl>
      </section>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8724.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9363.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3688.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6020.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6241.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8040.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6242.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8341.xml"/>
      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8376.xml"/>
      </references>
    </references>
    <section anchor="acknowledgements" title="Acknowledgements">

<t>Carles Gomez numbered="false">
      <name>Acknowledgements</name>
      <t><contact fullname="Carles Gomez"/> has been funded in part by the Spanish Government
   through the TEC2016-79988-P
   grant, grant and the PID2019-106808RA-I00 grant
   (funded by MCIN / AEI / 10.13039/501100011033), 10.13039/501100011033) and by Secretaria
   d'Universitats i Recerca del Departament d'Empresa i Coneixement de
   la Generalitat de Catalunya 2017 through 2017 grant SGR 376.</t>
<t>Sergio Aguilar 376 and 2021 grant SGR 00330.</t>
      <t><contact fullname="Sergio Aguilar"/> has been funded by the ERDF and the Spanish Government through project TEC2016-79988-P and project PID2019-106808RA-I00,
AEI/FEDER, EU (funded by MCIN / AEI / 10.13039/501100011033).</t>
<t>Sandra Cespedes
      <t><contact fullname="Sandra Cespedes"/> has been funded in part by the ANID Chile Project FONDECYT Regular 1201893 and Basal Project FB0008.</t>
<t>Diego Wistuba
      <t><contact fullname="Diego Wistuba"/> has been funded by the ANID Chile Project FONDECYT Regular 1201893.</t>
      <t>The authors would like to thank Rafael Vidal, Julien Boite, Renaud Marty, Antonis Platis, Dominique Barthel and Pascal Thubert <contact fullname="Rafael Vidal"/>, <contact fullname="Julien Boite"/>, <contact fullname="Renaud Marty"/>, <contact fullname="Antonis Platis"/>, <contact fullname="Dominique Barthel"/>, and <contact fullname="Pascal Thubert"/> for their
very useful comments, reviews reviews, and implementation design considerations.</t>
    </section>

  </middle>

  <back>

   <references title='Normative References'>

<?rfc include='reference.RFC.2119'?>
<?rfc include='reference.RFC.8174'?>

<?rfc include='reference.RFC.8724'?>
<?rfc include='reference.RFC.9363'?>
<?rfc include='reference.RFC.3688'?>
<?rfc include='reference.RFC.6020'?>
    </references>

	<references title='Informative References'>
        <?rfc include='reference.RFC.8376'?>
	    </references>
  </back>
</rfc>