<?xml version="1.0" encoding="US-ASCII"?> encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="4"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?> [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="std" consensus="true" docName="draft-ietf-dots-robust-blocks-06"
     ipr="trust200902"> number="9362" ipr="trust200902" obsoletes="" updates="" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3">

  <!-- xml2rfc v2v3 conversion 3.15.0 -->
  <front>
    <title abbrev="DOTS Robust Block Transmission">Distributed
    Denial-of-Service Open Threat Signaling (DOTS) Signal Channel
    Configuration Attributes for Robust Block Transmission</title>

    <seriesInfo name="RFC" value="9362"/>
    <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
      <organization>Orange</organization>
      <address>
        <postal>
          <street></street>
          <street/>
          <city>Rennes</city>

          <region></region>
          <region/>
          <code>35000</code>
          <country>France</country>
        </postal>
        <email>mohamed.boucadair@orange.com</email>
      </address>
    </author>
    <author fullname="Jon Shallow" initials="J." surname="Shallow">
      <organization></organization>
      <organization/>
      <address>
        <postal>
          <street></street>

          <city></city>

          <region></region>

          <code></code>
          <street/>
          <city/>
          <region/>
          <code/>
          <country>United Kingdom</country>
        </postal>
        <email>supjps-ietf@jpshallow.com</email>
      </address>
    </author>
    <date year="2023" month="February" />

    <workgroup>DOTS</workgroup>
    <area>sec</area>
    <workgroup>dots</workgroup>
    <keyword>Quick-Block</keyword>
    <keyword>Robust-Block</keyword>
    <keyword>R-Block</keyword>
    <keyword>Tough-Block</keyword>
    <keyword>Resilient-Block</keyword>
    <keyword>Fast-Block</keyword>
    <keyword>Resilience</keyword>
    <keyword>Filtering</keyword>
    <keyword>Faster transmission</keyword>
    <keyword>Large amounts of data</keyword>
    <keyword>Less packet interchange</keyword>
    <keyword>Fast recovery</keyword>
    <abstract>
      <t>This document specifies new DDoS Open Threat Signaling (DOTS) signal
      channel configuration parameters that can be negotiated between DOTS
      peers to enable the use of Q-Block1 and Q-Block2 CoAP Constrained Application Protocol (CoAP) options. These
      options enable robust and faster transmission rates for large amounts of
      data with less packet interchanges as well as supporting support for faster recovery
      should any of the blocks get lost in transmission (especially, (especially during
      DDoS attacks).</t>
      <t>Also, this document defines a YANG data model for representing these
      new DOTS signal channel configuration parameters. This model augments
      the DOTS signal YANG module ("ietf-dots-signal-channel") defined in RFC
      9132.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="introduction" title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>The Constrained Application Protocol (CoAP) <xref
      target="RFC7252"></xref>, target="RFC7252" format="default"/>, although inspired by HTTP, was designed to use
      UDP instead of TCP. The message layer of CoAP over UDP includes support
      for reliable delivery, simple congestion control, and flow control. The
      block-wise transfer <xref target="RFC7959"></xref> target="RFC7959" format="default"/> introduced the CoAP
      Block1 and Block2 options to handle data records that cannot fit in a
      single IP packet, so not to avoid having to rely on IP fragmentation. The
      block-wise transfer was further updated by <xref
      target="RFC8323"></xref> target="RFC8323" format="default"/> for use over TCP, TLS, and WebSockets.</t>
      <t>The CoAP Block1 and Block2 options work well in environments where
      there are no or minimal packet losses. These options operate
      synchronously where each individual block has to be requested and can
      only ask for (or send) the next block when the request for the previous
      block has completed. Packet, Packet rates, and hence block transmission rate, is rates, are
      controlled by Round-Trip Times (RTTs).</t>
      <t>There is a requirement for these blocks of data to be transmitted at
      higher rates under network conditions where there may be asymmetrical
      transient packet loss (e.g., responses may get dropped). An example is
      when a network is subject to a Distributed Denial of Service (DDoS)
      attack and there is a need for DDoS mitigation agents relying upon CoAP
      to communicate with each other (e.g., <xref target="RFC9244"></xref>). target="RFC9244" format="default"/>).
      As a reminder, <xref target="RFC7959"></xref> target="RFC7959" format="default"/> recommends the use of
      Confirmable (CON) responses to handle potential packet loss. However,
      such a recommendation does not work with a flooded pipe "flooded pipe" DDoS situation
      because the returning ACK packets may not get through.</t>
      <t>The block-wise transfer specified in <xref target="RFC7959"></xref> target="RFC7959" format="default"/>
      covers the general case, case but falls short in situations where packet loss
      is highly asymmetrical. The mechanism specified in <xref
      target="RFC9177"></xref> target="RFC9177" format="default"/> provides features roughly similar features to the
      Block1/Block2 options, options but also provides additional properties that are
      tailored towards the intended DDoS Open Threat Signaling (DOTS)
      transmission. Concretely, <xref target="RFC9177"></xref> target="RFC9177" format="default"/> primarily
      targets applications such as DOTS that can't use Confirmable responses
      to handle potential packet loss and that support application-specific
      mechanisms to assess whether the remote peer is able to handle the
      messages sent by a CoAP endpoint (e.g., DOTS heartbeats as discussed in Section 4.7
      of <xref target="RFC9132"></xref>).</t> target="RFC9132" sectionFormat="of" section="4.7"/>).</t>
      <t><xref target="RFC9177"></xref> target="RFC9177" format="default"/> includes guards to prevent a CoAP
      agent from overloading the network by adopting an aggressive sending
      rate. These guards are followed in addition to the existing CoAP
      congestion control as specified in Section 4.7 of <xref
      target="RFC7252"></xref> (mainly, target="RFC7252" sectionFormat="of" section="4.7"/> (mainly PROBING_RATE). Table 1 <xref target="tab-1"/> lists the
      additional CoAP parameters that are used for the guards (Section 7.2 of
      <xref target="RFC9177"></xref>). (<xref target="RFC9177" sectionFormat="of" section="7.2"/>). Note that NON in this table refers to
      Non-confirmable.</t>

      <t><figure align="center">
          <artwork align="center"><![CDATA[+---------------------+-------------------+
| Parameter Name      |     Default Value |
+=====================+===================+
| MAX_PAYLOADS        |                10 |
| NON_MAX_RETRANSMIT  |                 4 |
| NON_TIMEOUT         |               2 s |
| NON_TIMEOUT_RANDOM  |     between

<table anchor="tab-1">
  <name>Congestion Control Parameters</name>
  <thead>
    <tr>
      <th>Parameter Name</th>
      <th>Default Value</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>MAX_PAYLOADS</td>
      <td>10</td>
    </tr>
    <tr>
      <td>NON_MAX_RETRANSMIT</td>
      <td>4</td>
    </tr>
    <tr>
      <td>NON_TIMEOUT</td>
      <td>2 s</td>
    </tr>
    <tr>
      <td>NON_TIMEOUT_RANDOM</td>
      <td>between 2-3 s |
| NON_RECEIVE_TIMEOUT |               4 s |
| NON_PROBING_WAIT    | between s</td>
    </tr>
    <tr>
      <td>NON_RECEIVE_TIMEOUT</td>
      <td>4 s</td>
    </tr>
    <tr>
      <td>NON_PROBING_WAIT</td>
      <td>between 247-248 s |
| NON_PARTIAL_TIMEOUT |             247 s |
+---------------------+-------------------+

Table 1: Congestion Control Parameters]]></artwork>
        </figure></t> s</td>
    </tr>
    <tr>
      <td>NON_PARTIAL_TIMEOUT</td>
      <td>247 s</td>
    </tr>
  </tbody>
</table>
      <t>PROBING_RATE and other transmission parameters are negotiated between
      DOTS peers as discussed in Section 4.5.2 of <xref
      target="RFC9132"></xref>. target="RFC9132" sectionFormat="of" section="4.5.2"/>. Nevertheless, negotiating the parameters
      listed in Table 1 <xref target="tab-1"/> is not supported in <xref target="RFC9132"></xref>. target="RFC9132" format="default"/>.
      This document defines new DOTS signal channel attributes, corresponding
      to the parameters in Table 1, <xref target="tab-1"/>, that are used to customize the
      configuration of robust block transmission in a DOTS context.</t>
    </section>
    <section anchor="notation" title="Terminology"> numbered="true" toc="default">
      <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="RFC2119"/> <xref target="RFC8174"></xref> target="RFC8174"/> when, and only
       when, they appear in all capitals, as shown here.</t>
      <t>Readers should be familiar with the terms and concepts defined in
      <xref target="RFC7252"></xref> target="RFC7252" format="default"/> and <xref target="RFC8612"></xref>.</t> target="RFC8612" format="default"/>.</t>
      <t>The terms "payload" and "body" are defined in <xref
      target="RFC7959"></xref>. target="RFC7959" format="default"/>. The term "payload" is thus used for the
      content of a single CoAP message (i.e., a single block being
      transferred), while the term "body" is used for the entire resource
      representation that is being transferred in a block-wise fashion.</t>
      <t>The meaning meanings of the symbols in YANG tree diagrams are defined in <xref
      target="RFC8340"></xref> target="RFC8340" format="default"/> and <xref target="RFC8791"></xref>.</t> target="RFC8791" format="default"/>.</t>
    </section>
    <section anchor="new"
             title="DOTS numbered="true" toc="default">
      <name>DOTS Attributes for Robust Block Transmission">
      <t>Section 7.2 of <xref target="RFC9177"></xref> Transmission</name>
      <t><xref target="RFC9177" sectionFormat="of" section="7.2"/> defines the following
      parameters that are used for congestion control purposes:<list
          style="hanging">
          <t hangText="MAX_PAYLOADS:">is purposes:</t>
      <dl newline="false" spacing="normal">
        <dt>MAX_PAYLOADS:</dt>
        <dd>This parameter represents the maximum number of payloads that
          can be transmitted at any one time.</t>

          <t hangText="NON_MAX_RETRANSMIT:">is time.</dd>
        <dt>NON_MAX_RETRANSMIT:</dt>
        <dd>This parameter represents the maximum number of times a
          request for the retransmission of missing payloads can occur without
          a response from the remote peer. By default, NON_MAX_RETRANSMIT has
          the same value as MAX_RETRANSMIT (Section 4.8 of <xref
          target="RFC7252"></xref>).</t>

          <t hangText="NON_TIMEOUT:">is (<xref target="RFC7252" sectionFormat="of" section="4.8"/>).</dd>
        <dt>NON_TIMEOUT:</dt>
        <dd>This parameter represents the maximum period of delay between
          sending sets of MAX_PAYLOADS payloads for the same body. NON_TIMEOUT
          has the same value as ACK_TIMEOUT (Section 4.8 of <xref
          target="RFC7252"></xref>).</t>

          <t hangText="NON_TIMEOUT_RANDOM:">is (<xref target="RFC7252" sectionFormat="of" section="4.8"/>).</dd>
        <dt>NON_TIMEOUT_RANDOM:</dt>
        <dd>This parameter represents the initial actual delay
          between sending the first two MAX_PAYLOADS_SETs of the same body. It
          is a random duration between NON_TIMEOUT and (NON_TIMEOUT *
          ACK_RANDOM_FACTOR).</t>

          <t hangText="NON_RECEIVE_TIMEOUT:">is
          ACK_RANDOM_FACTOR).</dd>
        <dt>NON_RECEIVE_TIMEOUT:</dt>
        <dd>This parameter represents the maximum time to wait for a
          missing payload before requesting retransmission. By default,
          NON_RECEIVE_TIMEOUT has a value of twice NON_TIMEOUT.</t>

          <t hangText="NON_PROBING_WAIT:">is NON_TIMEOUT.</dd>
        <dt>NON_PROBING_WAIT:</dt>
        <dd>This parameter is used to limit the potential wait
          needed when using PROBING_RATE.</t>

          <t hangText="NON_PARTIAL_TIMEOUT:">is PROBING_RATE.</dd>
        <dt>NON_PARTIAL_TIMEOUT:</dt>
        <dd>This parameter is used for expiring partially
          received bodies.</t>
        </list></t> bodies.</dd>
      </dl>
      <t>These parameters are used together with the PROBING_RATE parameter parameter, which
      in CoAP indicates the average data rate that must not be exceeded by a
      CoAP endpoint in sending to a peer endpoint that does not respond. The
      single body of blocks will be subjected to PROBING_RATE (Section 4.7 of
      <xref target="RFC7252"></xref>), (<xref target="RFC7252" sectionFormat="of" section="4.7"/>), not the individual packets. If the wait
      time between sending bodies that are not being responded to based on
      PROBING_RATE exceeds NON_PROBING_WAIT, then the wait time is limited to
      NON_PROBING_WAIT.</t>
      <t>This document augments the "ietf-dots-signal-channel" DOTS signal
      YANG module defined in Section 5.3 of <xref target="RFC9132"></xref> target="RFC9132" sectionFormat="of" section="5.3"/> with the following additional attributes that can be negotiated between
      DOTS peers to enable robust and faster transmission:</t>

      <t><list style="hanging">
          <t hangText="max-payloads:">This
      <dl newline="false" spacing="normal">
        <dt>max-payloads:</dt>
        <dd>
          <t>This attribute echoes the MAX_PAYLOADS
          parameter defined in <xref target="RFC9177"></xref>.<vspace
          blankLines="1" />This target="RFC9177" format="default"/>.</t>
          <t>This is an optional attribute. If the attribute is
          supplied in both &lsquo;idle-config&rsquo; 'idle-config' and
          &lsquo;mitigating-config&rsquo;,
          'mitigating-config', then it MUST <bcp14>MUST</bcp14> convey the same value.
          If the attribute is only provided as part of
          &lsquo;idle-config&rsquo;
          'idle-config' (or &lsquo;mitigating-config&rsquo;), 'mitigating-config'), then
          the other definition (i.e., &lsquo;mitigating-config&rsquo; 'mitigating-config' (or
          &lsquo;idle-config&rsquo;)) MUST
          'idle-config')) <bcp14>MUST</bcp14> be updated to the same value.</t>

          <t hangText="non-max-retransmit:">This
        </dd>
        <dt>non-max-retransmit:</dt>
        <dd>
          <t>This attribute echoes the
          NON_MAX_RETRANSMIT parameter defined in <xref target="RFC9177"></xref>. target="RFC9177" format="default"/>. The
          default value of this attribute is 'max-retransmit'. Note that DOTS
          uses a default value of '3' instead of '4' (which is used for the generic
          generically by CoAP
          use (Section 4.5.2 of <xref target="RFC9132"></xref>) for
          max-transmit. <vspace blankLines="1" />This 'max-transmit'; see <xref target="RFC9132" sectionFormat="of" section="4.5.2"/> and <xref target="RFC7252" sectionFormat="of" section="4.8"/>).</t>

          <t>This is an optional
          attribute.</t>

          <t hangText="non-timeout:">This
        </dd>
        <dt>non-timeout:</dt>
        <dd>
          <t>This attribute, expressed in seconds,
          echoes the NON_TIMEOUT parameter defined in <xref target="RFC9177"></xref>. target="RFC9177" format="default"/>.
          The default value of this attribute is 'ack-timeout'.<vspace
          blankLines="1" />This 'ack-timeout'.</t>
          <t>This attribute is also used to compute the
          NON_TIMEOUT_RANDOM parameter.<vspace blankLines="1" />This parameter.</t>
          <t>This is an
          optional attribute.</t>

          <t hangText="non-receive-timeout:">This
        </dd>
        <dt>non-receive-timeout:</dt>
        <dd>
          <t>This attribute, expressed in
          seconds, echoes the NON_RECEIVE_TIMEOUT parameter defined in <xref
          target="RFC9177"></xref>. target="RFC9177" format="default"/>. The default value of this attribute is
          twice 'non-timeout'.<vspace blankLines="1" />This 'non-timeout'.</t>
          <t>This is an optional
          attribute.</t>

          <t hangText="non-probing-wait:">This
        </dd>
        <dt>non-probing-wait:</dt>
        <dd>
          <t>This attribute, expressed in
          seconds, echoes the NON_PROBING_WAIT parameter defined in <xref
          target="RFC9177"></xref>. <vspace blankLines="1" />This target="RFC9177" format="default"/>. </t>
          <t>This is an
          optional attribute.</t>

          <t hangText="non-partial-timeout:">This
        </dd>
        <dt>non-partial-timeout:</dt>
        <dd>
          <t>This attribute, expressed in
          seconds, echoes the NON_PARTIAL_TIMEOUT parameter defined in <xref
          target="RFC9177"></xref>. target="RFC9177" format="default"/>. The default value of this attribute is 247
          seconds.<vspace blankLines="1" />This
          seconds.</t>
          <t>This is an optional attribute.</t>
        </list></t>
        </dd>
      </dl>
      <t>The tree structure of the "ietf-dots-robust-trans" module (<xref
      target="module"></xref>) target="module" format="default"/>) is shown in <xref target="tree"></xref>.</t>

      <t><figure anchor="tree"
          title="DOTS target="tree" format="default"/>.</t>

      <figure anchor="tree">
        <name>DOTS Fast Block Transmission Tree Structure">
          <artwork><![CDATA[module: Structure</name>
        <sourcecode name="" type="yangtree"><![CDATA[module: ietf-dots-robust-trans

  augment-structure /dots-signal:dots-signal/dots-signal:message-type
                    /dots-signal:signal-config
                    /dots-signal:mitigating-config:
    +-- max-payloads
    |  +-- (direction)?
    |  |  +--:(server-to-client-only)
    |  |     +-- max-value?   uint16
    |  |     +-- min-value?   uint16
    |  +-- current-value?     uint16
    +-- non-max-retransmit
    |  +-- (direction)?
    |  |  +--:(server-to-client-only)
    |  |     +-- max-value?   uint16
    |  |     +-- min-value?   uint16
    |  +-- current-value?     uint16
    +-- non-timeout
    |  +-- (direction)?
    |  |  +--:(server-to-client-only)
    |  |     +-- max-value-decimal?   decimal64
    |  |     +-- min-value-decimal?   decimal64
    |  +-- current-value-decimal?     decimal64
    +-- non-receive-timeout
    |  +-- (direction)?
    |  |  +--:(server-to-client-only)
    |  |     +-- max-value-decimal?   decimal64
    |  |     +-- min-value-decimal?   decimal64
    |  +-- current-value-decimal?     decimal64
    +-- non-probing-wait
    |  +-- (direction)?
    |  |  +--:(server-to-client-only)
    |  |     +-- max-value-decimal?   decimal64
    |  |     +-- min-value-decimal?   decimal64
    |  +-- current-value-decimal?     decimal64
    +-- non-partial-wait: non-partial-timeout:
       +-- (direction)?
       |  +--:(server-to-client-only)
       |     +-- max-value-decimal?   decimal64
       |     +-- min-value-decimal?   decimal64
       +-- current-value-decimal?     decimal64

  augment-structure /dots-signal:dots-signal/dots-signal:message-type
                    /dots-signal:signal-config/dots-signal:idle-config:
                    /dots-signal:signal-config
                    /dots-signal:idle-config:
    +-- max-payloads
    |  +-- (direction)?
    |  |  +--:(server-to-client-only)
    |  |     +-- max-value?   uint16
    |  |     +-- min-value?   uint16
    |  +-- current-value?     uint16
    +-- non-max-retransmit
    |  +-- (direction)?
    |  |  +--:(server-to-client-only)
    |  |     +-- max-value?   uint16
    |  |     +-- min-value?   uint16
    |  +-- current-value?     uint16
    +-- non-timeout
    |  +-- (direction)?
    |  |  +--:(server-to-client-only)
    |  |     +-- max-value-decimal?   decimal64
    |  |     +-- min-value-decimal?   decimal64
    |  +-- current-value-decimal?     decimal64
    +-- non-receive-timeout
    |  +-- (direction)?
    |  |  +--:(server-to-client-only)
    |  |     +-- max-value-decimal?   decimal64
    |  |     +-- min-value-decimal?   decimal64
    |  +-- current-value-decimal?     decimal64
    +-- non-probing-wait
    |  +-- (direction)?
    |  |  +--:(server-to-client-only)
    |  |     +-- max-value-decimal?   decimal64
    |  |     +-- min-value-decimal?   decimal64
    |  +-- current-value-decimal?     decimal64
    +-- non-partial-wait: non-partial-timeout:
       +-- (direction)?
       |  +--:(server-to-client-only)
       |     +-- max-value-decimal?   decimal64
       |     +-- min-value-decimal?   decimal64
       +-- current-value-decimal?     decimal64
]]></artwork>
        </figure></t>
]]></sourcecode>
      </figure>
      <t>These attributes are mapped to CBOR Concise Binary Object Representation (CBOR) types as specified in <xref
      target="maptab"></xref> target="maptab" format="default"/> and Section 6 of in <xref
      target="RFC9132"></xref>.</t> target="RFC9132" sectionFormat="of" section="6"/>.</t>
      <t>DOTS clients follow the procedure specified in Section 4.5 of <xref
      target="RFC9132"></xref> target="RFC9132" sectionFormat="of" section="4.5"/> to negotiate, configure, and retrieve the DOTS
      signal channel session behavior (including Q-Block parameters) with DOTS
      peers.</t>

      <t><list style="hanging">
          <t hangText="Implementation
      <dl newline="false" spacing="normal">
        <dt>Implementation Note 1:">'non-probing-wait' 1:</dt>
        <dd>'non-probing-wait' ideally
          should be left having some jitter and so should not be hard-coded
          with an explicit value. It is suggested to use a base value (using
          NON_TIMEOUT instead of NON_TIMEOUT_RANDOM) and, then, NON_TIMEOUT_RANDOM); the jitter
          (ACK_RANDOM_FACTOR - 1) is then added to each time the value is
          checked.</t>

          <t hangText="Implementation
          checked.</dd>
        <dt>Implementation Note 2:">If 2:</dt>
        <dd>If any of the signal channel
          session configuration parameters is updated, the 'non-probing-wait'
          and 'non-partial-timeout' values should be recalculated according to
          the definition algorithms provided in Section 7.2 of <xref
          target="RFC9177"></xref> target="RFC9177" sectionFormat="of" section="7.2"/> unless explicit values are provided as part
          of the negotiated configuration.</t>
        </list></t> configuration.</dd>
      </dl>
      <t>An example of a PUT message to configure Q-Block parameters is
      depicted in <xref target="put"></xref>. target="put" format="default"/>. In this example, a non-default
      value is configured for the 'max-payloads' attribute, while default
      values are used for 'non-max-retransmit', 'non-timeout', and
      'non-receive-timeout' in both idle and mitigation times. Given that
      'non-probing-wait' and 'non-partial-wait' 'non-partial-timeout' are not explicitly configured
      in this example, these attributes will be computed following the
      algorithms provided in Section 7.2 of <xref target="RFC9177"></xref>. target="RFC9177" sectionFormat="of" section="7.2"/>. The meaning meanings
      of the other attributes is are detailed in Section 4.5 of <xref
      target="RFC9132"></xref>.</t>

      <t><figure align="center" anchor="put"
          title="Example target="RFC9132" sectionFormat="of" section="4.5"/>.</t>
      <figure anchor="put">
        <name>Example of PUT to Convey the Configuration Parameters">
          <artwork align="left"><![CDATA[ Parameters</name>
<sourcecode name="" type="http-message"><![CDATA[
     Header: PUT (Code=0.03)
     Uri-Path: ".well-known"
     Uri-Path: "dots"
     Uri-Path: "config"
     Uri-Path: "sid=123"
     Content-Format: "application/dots+cbor"

     {
       "ietf-dots-signal-channel:signal-config": {
         "mitigating-config": {
           "heartbeat-interval": {
             "current-value": 30
           },
           "missing-hb-allowed": {
             "current-value": 15
           },
           "probing-rate": {
             "current-value": 15
           },
           "max-retransmit": {
             "current-value": 3
           },
           "ack-timeout": {
             "current-value-decimal": "2.00"
           },
           "ack-random-factor": {
             "current-value-decimal": "1.50"
           },
           "ietf-dots-robust-trans:max-payloads": {
             "current-value": 15
           },
           "ietf-dots-robust-trans:non-max-retransmit": {
             "current-value": 3
           },
           "ietf-dots-robust-trans:non-timeout": {
             "current-value-decimal": "2.00"
           },
           "ietf-dots-robust-trans:non-receive-timeout": {
             "current-value-decimal": "4.00"
           }
         },
         "idle-config": {
           "heartbeat-interval": {
             "current-value": 0
           },
           "max-retransmit": {
             "current-value": 3
           },
           "ack-timeout": {
             "current-value-decimal": "2.00"
           },
           "ack-random-factor": {
             "current-value-decimal": "1.50"
           },
           "ietf-dots-robust-trans:max-payloads": {
             "current-value": 15
           },
           "ietf-dots-robust-trans:non-max-retransmit": {
             "current-value": 3
           },
           "ietf-dots-robust-trans:non-timeout": {
             "current-value-decimal": "2.00"
           },
           "ietf-dots-robust-trans:non-receive-timeout": {
             "current-value-decimal": "4.00"
           }
         }
       }
     }]]></artwork>
        </figure></t>

      <t></t>
     }
]]></sourcecode>
      </figure>
      <t>The payload of the message depicted in <xref target="put"></xref> target="put" format="default"/> is
      CBOR-encoded as indicated by the Content-Format set to
      "application/dots+cbor" (Section 10.3 of <xref
      target="RFC9132"></xref>). (<xref target="RFC9132" sectionFormat="of" section="10.4"/>). However, and for the sake of better
      readability, the example uses JSON encoding of YANG-modeled data
      following the mapping table tables in <xref target="maptab"></xref> target="maptab" format="default"/> and Section
      6 of in <xref target="RFC9132"></xref>: target="RFC9132" sectionFormat="of" section="6"/>: use the JSON names and types
      defined in <xref target="maptab"></xref>. target="maptab" format="default"/>. These conventions are
      inherited from <xref target="RFC9132"></xref>.</t> target="RFC9132" format="default"/>.</t>
    </section>
    <section anchor="maptab" title="YANG/JSON numbered="true" toc="default">
      <name>YANG/JSON Mapping Parameters to CBOR"> CBOR</name>
      <t>The YANG/JSON mapping parameters to CBOR are listed in Table 2.<list
          style="symbols">
          <t>Note: <xref target="tab-2"/>.</t>
        <t indent="3">Note: Implementers must check that the mapping output provided by
          their YANG-to-CBOR encoding schemes is aligned with the content of
          Table 2.</t>
        </list></t>

      <t><figure align="center">
          <artwork><![CDATA[+----------------------+------------+------+---------------+--------+
|   Parameter Name     | YANG       | CBOR | CBOR Major    | JSON   |
|                      | Type       | Key  |    Type &     | Type   |
|                      |            |      | Information   |        |
+======================+============+======+===============+========+
| ietf-dots-robust-    | container  | TBA1 | 5 map         | Object |
|   trans:max-payloads |            |      |               |        |
+----------------------+------------+------+---------------+--------+
| ietf-dots-robust-    | container  | TBA2 | 5 map         | Object |
|   trans:non-max-     |            |      |               |        |
|   retransmit         |            |      |               |        |
+----------------------+------------+------+---------------+--------+
| ietf-dots-robust-    | container  | TBA3 | 5 map         | Object |
|   trans:non-timeout  |            |      |               |        |
+----------------------+------------+------+---------------+--------+
| ietf-dots-robust-    | container  | TBA4 | 5 map         | Object |
|   trans:non-receive- |            |      |               |        |
|   timeout            |            |      |               |        |
+----------------------+------------+------+---------------+--------+
| ietf-dots-robust-    | container  | TBA5 | 5 map         | Object |
|   trans:non-probing- |            |      |               |        |
|   wait               |            |      |               |        |
+----------------------+------------+------+---------------+--------+
| ietf-dots-robust-    | container  | TBA6 | 5 map         | Object |
|   trans:non-partial- |            |      |               |        |
|   wait               |            |      |               |        |
+----------------------+------------+------+---------------+--------+

           Table 2: YANG/JSON
          <xref target="tab-2"/>.</t>

<table anchor="tab-2">
  <name>YANG/JSON Mapping Parameters to CBOR
]]></artwork>
        </figure></t>

      <t></t> CBOR</name>
  <thead>
    <tr>
      <th>Parameter Name</th>
      <th>YANG Type</th>
      <th>CBOR Key</th>
      <th>CBOR Major Type &amp; Information</th>
      <th>JSON Type</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>ietf-dots-robust-trans:max-payloads</td>
      <td>container</td>
      <td>32776</td>
      <td>5 map</td>
      <td>Object</td>
    </tr>
    <tr>
      <td>ietf-dots-robust-trans:non-max-retransmit</td>
      <td>container</td>
      <td>32777</td>
      <td>5 map</td>
      <td>Object</td>
    </tr>
    <tr>
      <td>ietf-dots-robust-trans:non-timeout</td>
      <td>container</td>
      <td>32778</td>
      <td>5 map</td>
      <td>Object</td>
    </tr>
    <tr>
      <td>ietf-dots-robust-trans:non-receive-timeout</td>
      <td>container</td>
      <td>32779</td>
      <td>5 map</td>
      <td>Object</td>
    </tr>
    <tr>
      <td>ietf-dots-robust-trans:non-probing-wait</td>
      <td>container</td>
      <td>32780</td>
      <td>5 map</td>
      <td>Object</td>
    </tr>
    <tr>
      <td>ietf-dots-robust-trans:non-partial-timeout</td>
      <td>container</td>
      <td>32781</td>
      <td>5 map</td>
      <td>Object</td>
    </tr>
  </tbody>
</table>

    </section>
    <section anchor="module"
             title="DOTS numbered="true" toc="default">
      <name>DOTS Robust Block Transmission YANG Module"> Module</name>
      <t>This module uses the data structure extension defined in <xref
      target="RFC8791"></xref>.</t>

      <t><figure>
          <artwork><![CDATA[<CODE BEGINS> file "ietf-dots-robust-trans@2022-01-04.yang" target="RFC8791" format="default"/>.</t>
      <sourcecode name="ietf-dots-robust-trans@2023-01-26.yang" type="yang" markers="true"><![CDATA[
module ietf-dots-robust-trans {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-dots-robust-trans";
  prefix dots-robust;

  import ietf-dots-signal-channel {
    prefix dots-signal;
    reference
      "RFC 9132: Distributed Denial-of-Service Open Threat
                 Signaling (DOTS) Signal Channel Specification";
  }
  import ietf-yang-structure-ext {
    prefix sx;
    reference
      "RFC 8791: YANG Data Structure Extensions";
  }

  organization
    "IETF DDoS Open Threat Signaling (DOTS) Working Group";
  contact
    "WG Web:   <https://datatracker.ietf.org/wg/dots/>
     WG List:  <mailto:dots@ietf.org>

     Author:   Mohamed Boucadair
               <mailto:mohamed.boucadair@orange.com>;

     Author:   Jon Shallow
               <mailto:ietf-supjps@jpshallow.com>";
  description
    "This module contains YANG definitions for the configuration
     of parameters that can be negotiated between a DOTS client
     and a DOTS server for robust block transmission.

     Copyright (c) 2022 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
     (http://trustee.ietf.org/license-info).
     (https://trustee.ietf.org/license-info).

     This version of this YANG module is part of RFC XXXX; 9362; see the
     RFC itself for full legal notices.";

  revision 2022-01-04 2023-01-26 {
    description
      "Initial revision.";
    reference
      "RFC XXXX: 9362: Distributed Denial-of-Service Open Threat
                 Signaling (DOTS) Configuration Attributes
                 for Robust Block Transmission";
  }

  grouping robust-transmission-attributes {
    description
      "A set of DOTS signal channel session configuration
       parameters that are negotiated between DOTS agents when
       making use of Q-Block1 and Q-Block2 options.";
    container max-payloads {
      description
        "Indicates the maximum number of payloads that
         can be transmitted at any one time.";
      choice direction {
        description
          "Indicates the communication direction in which the
           data nodes can be included.";
        case server-to-client-only {
          description
            "These data nodes appear only in a message sent
             from the server to the client.";
          leaf max-value {
            type uint16;
            description
              "Maximum acceptable max-payloads 'max-payloads' value.";
          }
          leaf min-value {
            type uint16;
            description
              "Minimum acceptable max-payloads 'max-payloads' value.";
          }
        }
      }
      leaf current-value {
        type uint16;
        default "10";
        description
          "Current max-payloads 'max-payloads' value.";
        reference
          "RFC 9177: Constrained Application Protocol (CoAP)
                     Block-Wise Transfer Options Supporting
                     Robust Transmission, Section 7.2";
      }
    }
    container non-max-retransmit {
      description
        "Indicates the maximum number of times a request
         for the retransmission of missing payloads can
         occur without a response from the remote peer.";
      choice direction {
        description
          "Indicates the communication direction in which the
           data nodes can be included.";
        case server-to-client-only {
          description
            "These data nodes appear only in a message sent
             from the server to the client.";
          leaf max-value {
            type uint16;
            description
              "Maximum acceptable non-max-retransmit 'non-max-retransmit' value.";
          }
          leaf min-value {
            type uint16;
            description
              "Minimum acceptable non-max-retransmit 'non-max-retransmit' value.";
          }
        }
      }
      leaf current-value {
        type uint16;
        default "3";
        description
          "Current non-max-retransmit 'non-max-retransmit' value.";
        reference
          "RFC 9177: Constrained Application Protocol (CoAP)
                     Block-Wise Transfer Options Supporting
                     Robust Transmission, Section 7.2";
      }
    }
    container non-timeout {
      description
        "Indicates the maximum period of delay between
         sending sets of MAX_PAYLOADS payloads for the same
         body.";
      choice direction {
        description
          "Indicates the communication direction in which the
           data nodes can be included.";
        case server-to-client-only {
          description
            "These data nodes appear only in a message sent
             from the server to the client.";
          leaf max-value-decimal {
            type decimal64 {
              fraction-digits 2;
            }
            units "seconds";
            description
              "Maximum ack-timeout 'ack-timeout' value.";
          }
          leaf min-value-decimal {
            type decimal64 {
              fraction-digits 2;
            }
            units "seconds";
            description
              "Minimum ack-timeout 'ack-timeout' value.";
          }
        }
      }
      leaf current-value-decimal {
        type decimal64 {
          fraction-digits 2;
        }
        units "seconds";
        default "2.00";
        description
          "Current ack-timeout 'ack-timeout' value.";
        reference
          "RFC 9177: Constrained Application Protocol (CoAP)
                     Block-Wise Transfer Options Supporting
                     Robust Transmission, Section 7.2";
      }
    }
    container non-receive-timeout {
      description
        "Indicates the time to wait for a missing payload
         before requesting retransmission.";
      choice direction {
        description
          "Indicates the communication direction in which the
           data nodes can be included.";
        case server-to-client-only {
          description
            "These data nodes appear only in a message sent
             from the server to the client.";
          leaf max-value-decimal {
            type decimal64 {
              fraction-digits 2;
            }
            units "seconds";
            description
              "Maximum non-receive-timeout 'non-receive-timeout' value.";
          }
          leaf min-value-decimal {
            type decimal64 {
              fraction-digits 2;
            }
            units "seconds";
            description
              "Minimum non-receive-timeout 'non-receive-timeout' value.";
          }
        }
      }
      leaf current-value-decimal {
        type decimal64 {
          fraction-digits 2;
        }
        units "seconds";
        default "4.00";
        description
          "Current non-receive-timeout 'non-receive-timeout' value.";
        reference
          "RFC 9177: Constrained Application Protocol (CoAP)
                     Block-Wise Transfer Options Supporting
                     Robust Transmission, Section 7.2";
      }
    }
    container non-probing-wait {
      description
        "Is used
        "Used to limit the potential wait needed when
         using probing-rate."; 'probing-rate'.";
      choice direction {
        description
          "Indicates the communication direction in which the
           data nodes can be included.";
        case server-to-client-only {
          description
            "These data nodes appear only in a message sent
             from the server to the client.";
          leaf max-value-decimal {
            type decimal64 {
              fraction-digits 2;
            }
            units "seconds";
            description
              "Maximum non-probing-wait 'non-probing-wait' value.";
          }
          leaf min-value-decimal {
            type decimal64 {
              fraction-digits 2;
            }
            units "seconds";
            description
              "Minimum non-probing-wait 'non-probing-wait' value.";
          }
        }
      }
      leaf current-value-decimal {
        type decimal64 {
          fraction-digits 2;
        }
        units "seconds";
        description
          "Current non-probing-wait 'non-probing-wait' value.";
        reference
          "RFC 9177: Constrained Application Protocol (CoAP)
                     Block-Wise Transfer Options Supporting
                     Robust Transmission, Section 7.2";
      }
    }
    container non-partial-wait non-partial-timeout {
      description
        "Is used
        "Used for expiring partially received bodies.";
      choice direction {
        description
          "Indicates the communication direction in which the
           data nodes can be included.";
        case server-to-client-only {
          description
            "These data nodes appear only in a message sent
             from the server to the client.";
          leaf max-value-decimal {
            type decimal64 {
              fraction-digits 2;
            }
            units "seconds";
            description
              "Maximum non-partial-wait 'non-partial-timeout' value.";
          }
          leaf min-value-decimal {
            type decimal64 {
              fraction-digits 2;
            }
            units "seconds";
            description
              "Minimum non-partial-wait 'non-partial-timeout' value.";
          }
        }
      }
      leaf current-value-decimal {
        type decimal64 {
          fraction-digits 2;
        }
        units "seconds";
        default "247.00";
        description
          "Current non-partial-wait 'non-partial-timeout' value.";
        reference
          "RFC 9177: Constrained Application Protocol (CoAP)
                     Block-Wise Transfer Options Supporting
                     Robust Transmission, Section 7.2";
      }
    }
  }

  sx:augment-structure "/dots-signal:dots-signal"
                     + "/dots-signal:message-type"
                     + "/dots-signal:signal-config"
                     + "/dots-signal:mitigating-config" {
    description
      "Indicates DOTS configuration attributes to use for
       robust transmission when a mitigation is active.";
    uses robust-transmission-attributes;
  }
  sx:augment-structure "/dots-signal:dots-signal"
                     + "/dots-signal:message-type"
                     + "/dots-signal:signal-config"
                     + "/dots-signal:idle-config" {
    description
      "Indicates DOTS configuration parameters to use for
       robust transmission when no mitigation is active.";
    uses robust-transmission-attributes;
  }
}
<CODE ENDS>]]></artwork>
        </figure></t>
]]></sourcecode>
    </section>
    <section anchor="IANA" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <section anchor="map" title="DOTS numbered="true" toc="default">
        <name>Registry for DOTS Signal Channel CBOR Mappings Registry"> Mappings</name>
        <t>This specification registers the following parameters in the IANA
        "DOTS Signal Channel CBOR Key Values" registry <xref
        target="Key-Map"></xref>.</t>

        <t><list style="symbols">
            <t>Note to the RFC Editor: Please replace TBA1-TBA6 with the CBOR
            keys that are assigned from the 32768-49151 range. Please update
            Table 2 accordingly.</t>
          </list></t>

        <t><figure align="center">
            <artwork><![CDATA[+------------------------+-------+-------+------------+---------------+
| Parameter Name         | CBOR  | target="Key-Map" format="default"/>.</t>

<table>
 <name>DOTS Robust Block Transmission CBOR  | Change     | Specification |
|                        | Mappings</name>
  <thead>
    <tr>
      <th>Parameter Name</th>
      <th>CBOR Key   | Value</th>
      <th>CBOR Major | Controller | Document(s)   |
|                        | Value | Type  |            |               |
+========================+=======+=======+============+===============+
| ietf-dots-robust-trans:| TBA1  |   5   |    IESG    |   [RFCXXXX]   |
|  max-payloads          |       |       |            |               |
+------------------------+-------+-------+------------+---------------+
| ietf-dots-robust-trans:| TBA2  |   5   |    IESG    |   [RFCXXXX]   |
|  non-max-retransmit    |       |       |            |               |
+------------------------+-------+-------+------------+---------------+
| ietf-dots-robust-trans:| TBA3  |   5   |    IESG    |   [RFCXXXX]   |
|  non-timeout           |       |       |            |               |
+------------------------+-------+-------+------------+---------------+
| ietf-dots-robust-trans:| TBA4  |   5   |    IESG    |   [RFCXXXX]   |
|  non-receive-timeout   |       |       |            |               |
+------------------------+-------+-------+------------+---------------+
| ietf-dots-robust-trans:| TBA5  |   5   |    IESG    |   [RFCXXXX]   |
|  non-probing-wait      |       |       |            |               |
+------------------------+-------+-------+------------+---------------+
| ietf-dots-robust-trans:| TBA6  |   5   |    IESG    |   [RFCXXXX]   |
|  non-partial-wait      |       |       |            |               |
+------------------------+-------+-------+------------+---------------+

]]></artwork>
          </figure></t> Type</th>
      <th>Change Controller</th>
      <th>Specification Document(s)</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>ietf-dots-robust-trans:max-payloads</td>
      <td>32776</td>
      <td>5</td>
      <td>IESG</td>
      <td>RFC 9362</td>
    </tr>
    <tr>
      <td>ietf-dots-robust-trans:non-max-retransmit</td>
      <td>32777</td>
      <td>5</td>
      <td>IESG</td>
      <td>RFC 9362</td>
    </tr>
    <tr>
      <td>ietf-dots-robust-trans:non-timeout</td>
      <td>32778</td>
      <td>5</td>
      <td>IESG</td>
      <td>RFC 9362</td>
    </tr>
    <tr>
      <td>ietf-dots-robust-trans:non-receive-timeout</td>
      <td>32779</td>
      <td>5</td>
      <td>IESG</td>
      <td>RFC 9362</td>
    </tr>
    <tr>
      <td>ietf-dots-robust-trans:non-probing-wait</td>
      <td>32780</td>
      <td>5</td>
      <td>IESG</td>
      <td>RFC 9362</td>
    </tr>
    <tr>
      <td>ietf-dots-robust-trans:non-partial-timeout</td>
      <td>32781</td>
      <td>5</td>
      <td>IESG</td>
      <td>RFC 9362</td>
    </tr>
  </tbody>
</table>
      </section>
      <section anchor="yang-iana"
               title="DOTS numbered="true" toc="default">
        <name>DOTS Robust Block Transmission YANG Module">
        <t>This document requests IANA to register Module</name>
        <t>IANA has registered the following URI in the
        "ns" subregistry within the "IETF XML Registry" <xref
        target="RFC3688"></xref>:</t>

        <t><figure>
            <artwork><![CDATA[  URI: urn:ietf:params:xml:ns:yang:ietf-dots-robust-trans
  Registrant Contact: The IESG.
  XML: N/A; target="RFC3688" format="default"/>:</t>
 <dl newline="false" spacing="compact">
  <dt>URI:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-dots-robust-trans</dd>
  <dt>Registrant Contact:</dt><dd>The IESG.</dd>
  <dt>XML:</dt><dd>N/A; the requested URI is an XML namespace.
]]></artwork>
          </figure></t>

        <t>This document requests IANA to register namespace.</dd>
 </dl>
        <t>IANA has registered the following YANG module
        in the "YANG Module Names" subregistry <xref target="RFC6020"></xref> target="RFC6020" format="default"/>
        within the "YANG Parameters" registry.</t>

        <t><figure>
            <artwork><![CDATA[  Name: ietf-dots-robust-trans
  Namespace: urn:ietf:params:xml:ns:yang:ietf-dots-robust-trans
  Maintained
 <dl newline="false" spacing="compact">
  <dt>Name:</dt><dd>ietf-dots-robust-trans</dd>
  <dt>Namespace:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-dots-robust-trans</dd>
  <dt>Maintained by IANA? N
  Prefix: dots-robust
  Reference: RFC XXXX
]]></artwork>
          </figure></t> IANA?</dt><dd>N</dd>
  <dt>Prefix:</dt><dd>dots-robust</dd>
  <dt>Reference:</dt><dd>RFC 9362</dd>
 </dl>
      </section>
    </section>
    <section anchor="security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>The security considerations for the DOTS signal channel protocol are
      discussed in Section 11 of <xref target="RFC9132"></xref>.</t> target="RFC9132" sectionFormat="of" section="11"/>.</t>
      <t>CoAP-specific security considerations are discussed in Section 11 of <xref target="RFC9177"></xref>.</t> target="RFC9177" sectionFormat="of" section="11"/>.</t>
      <t>Consistent with Section 5 of <xref target="RFC9132"></xref>, target="RFC9132" sectionFormat="of" section="5"/>, the
      "ietf-dots-robust-trans" module is not intended to be used via
      NETCONF/RESTCONF. It serves as an abstract representation in DOTS signal
      channel messages. The "ietf-dots-robust-trans" module does not introduce
      any new vulnerabilities beyond those specified above.</t>
    </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.7252.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.7959.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8323.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8791.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9177.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9132.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.3688.xml"/>
      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9244.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8612.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8340.xml"/>

        <reference anchor="Key-Map" target="https://www.iana.org/assignments/dots/">
          <front>
            <title>DOTS Signal Channel CBOR Key Values</title>
            <author>
              <organization>IANA</organization>
            </author>
            <date/>
          </front>
        </reference>
      </references>
    </references>
    <section anchor="ack" title="Acknowledgements"> numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>Thanks to Tiru Reddy, Meiling Chen, and Kaname Nishizuka <contact fullname="Tiru Reddy"/>, <contact fullname="Meiling Chen"/>, and <contact fullname="Kaname Nishizuka"/> for the
      review.</t>
      <t>Thanks to Michal Va&scaron;ko <contact fullname="Michal Vaško"/> for the yangdoctors review.</t>
      <t>Thanks to Valery Smyslov <contact fullname="Valery Smyslov"/> for shepherding the document, Paul Wouters <contact fullname="Paul Wouters"/>
      for the AD review, Paul Kyzivat <contact fullname="Paul Kyzivat"/> for the artart directorate review, Tim
      Evens <contact fullname="Tim Evens"/> for the Gen-ART review, and Jean-Michel Combes <contact fullname="Jean-Michel Combes"/> for the int-dir
      review.</t>
      <t>Thanks to John Scudder, Lars Eggert, &Eacute;ric Vyncke, Roman
      Danyliw, Rob Wilton, and Martin Duke <contact fullname="John Scudder"/>, <contact fullname="Lars Eggert"/>, <contact fullname="Éric Vyncke"/>, <contact fullname="Roman
      Danyliw"/>, <contact fullname="Rob Wilton"/>, and <contact fullname="Martin Duke"/> for the their comments during the IESG
      review.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include='reference.RFC.2119'?>

      <?rfc include='reference.RFC.7252'?>

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

      <?rfc include='reference.RFC.7959'?>

      <?rfc include='reference.RFC.8323'?>

      <?rfc include='reference.RFC.8791'?>

      <?rfc include='reference.RFC.9177'?>

      <?rfc include='reference.RFC.9132'?>

      <?rfc include='reference.RFC.6020'?>

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

    <references title="Informative References">
      <?rfc include="reference.RFC.9244"?>

      <?rfc include='reference.RFC.8612'?>

      <?rfc include='reference.RFC.8340'?>

      <reference anchor="Key-Map"
                 target="https://www.iana.org/assignments/dots/dots.xhtml#dots-signal-channel-cbor-key-values">
        <front>
          <title>DOTS Signal Channel CBOR Key Values</title>

          <author fullname="IANA">
            <organization></organization>
          </author>

          <date />
        </front>
      </reference>
    </references>
  </back>
 </rfc>