<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" consensus="true" docName="draft-ietf-dots-robust-blocks-06" indexInclude="true" ipr="trust200902" number="9362" prepTime="2023-02-28T22:51:11" scripts="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="4" tocInclude="true" xml:lang="en">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-dots-robust-blocks-06" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9362" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <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" stream="IETF"/>
    <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
      <organization showOnFrontPage="true">Orange</organization>
      <address>
        <postal>
          <street/>
          <city>Rennes</city>
          <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 showOnFrontPage="true"/>
      <address>
        <postal>
          <street/>
          <city/>
          <region/>
          <code/>
          <country>United Kingdom</country>
        </postal>
        <email>supjps-ietf@jpshallow.com</email>
      </address>
    </author>
    <date month="02" year="2023"/>
    <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 pn="section-abstract">
      <t indent="0" pn="section-abstract-1">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 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 support for faster recovery
      should any of the blocks get lost in transmission (especially during
      DDoS attacks).</t>
      <t indent="0" pn="section-abstract-2">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>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This is an Internet Standards Track document.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in Section 2 of 
            RFC 7841.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9362" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2023 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Revised BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Revised BSD License.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-terminology">Terminology</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-dots-attributes-for-robust-">DOTS Attributes for Robust Block Transmission</xref></t>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-yang-json-mapping-parameter">YANG/JSON Mapping Parameters to CBOR</xref></t>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-dots-robust-block-transmiss">DOTS Robust Block Transmission YANG Module</xref></t>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2">
              <li pn="section-toc.1-1.6.2.1">
                <t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent="6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-registry-for-dots-signal-ch">Registry for DOTS Signal Channel CBOR Mappings</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.2">
                <t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent="6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-dots-robust-block-transmissio">DOTS Robust Block Transmission YANG Module</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.8.2">
              <li pn="section-toc.1-1.8.2.1">
                <t indent="0" pn="section-toc.1-1.8.2.1.1"><xref derivedContent="8.1" format="counter" sectionFormat="of" target="section-8.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.2">
                <t indent="0" pn="section-toc.1-1.8.2.2.1"><xref derivedContent="8.2" format="counter" sectionFormat="of" target="section-8.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">The Constrained Application Protocol (CoAP) <xref target="RFC7252" format="default" sectionFormat="of" derivedContent="RFC7252"/>, 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" format="default" sectionFormat="of" derivedContent="RFC7959"/> introduced the CoAP
      Block1 and Block2 options to handle data records that cannot fit in a
      single IP packet, to avoid having to rely on IP fragmentation. The
      block-wise transfer was further updated by <xref target="RFC8323" format="default" sectionFormat="of" derivedContent="RFC8323"/> for use over TCP, TLS, and WebSockets.</t>
      <t indent="0" pn="section-1-2">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 rates, and hence block transmission rates, are
      controlled by Round-Trip Times (RTTs).</t>
      <t indent="0" pn="section-1-3">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" format="default" sectionFormat="of" derivedContent="RFC9244"/>).
      As a reminder, <xref target="RFC7959" format="default" sectionFormat="of" derivedContent="RFC7959"/> recommends the use of
      Confirmable (CON) responses to handle potential packet loss. However,
      such a recommendation does not work with a "flooded pipe" DDoS situation
      because the returning ACK packets may not get through.</t>
      <t indent="0" pn="section-1-4">The block-wise transfer specified in <xref target="RFC7959" format="default" sectionFormat="of" derivedContent="RFC7959"/>
      covers the general case but falls short in situations where packet loss
      is highly asymmetrical. The mechanism specified in <xref target="RFC9177" format="default" sectionFormat="of" derivedContent="RFC9177"/> provides features roughly similar to the
      Block1/Block2 options but also provides additional properties that are
      tailored towards the intended DDoS Open Threat Signaling (DOTS)
      transmission. Concretely, <xref target="RFC9177" format="default" sectionFormat="of" derivedContent="RFC9177"/> 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 <xref target="RFC9132" sectionFormat="of" section="4.7" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9132#section-4.7" derivedContent="RFC9132"/>).</t>
      <t indent="0" pn="section-1-5"><xref target="RFC9177" format="default" sectionFormat="of" derivedContent="RFC9177"/> 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 <xref target="RFC7252" sectionFormat="of" section="4.7" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7252#section-4.7" derivedContent="RFC7252"/> (mainly PROBING_RATE). <xref target="tab-1" format="default" sectionFormat="of" derivedContent="Table 1"/> lists the
      additional CoAP parameters that are used for the guards (<xref target="RFC9177" sectionFormat="of" section="7.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9177#section-7.2" derivedContent="RFC9177"/>). Note that NON in this table refers to
      Non-confirmable.</t>
      <table anchor="tab-1" align="center" pn="table-1">
        <name slugifiedName="name-congestion-control-paramete">Congestion Control Parameters</name>
        <thead>
          <tr>
            <th align="left" colspan="1" rowspan="1">Parameter Name</th>
            <th align="left" colspan="1" rowspan="1">Default Value</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left" colspan="1" rowspan="1">MAX_PAYLOADS</td>
            <td align="left" colspan="1" rowspan="1">10</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">NON_MAX_RETRANSMIT</td>
            <td align="left" colspan="1" rowspan="1">4</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">NON_TIMEOUT</td>
            <td align="left" colspan="1" rowspan="1">2 s</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">NON_TIMEOUT_RANDOM</td>
            <td align="left" colspan="1" rowspan="1">between 2-3 s</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">NON_RECEIVE_TIMEOUT</td>
            <td align="left" colspan="1" rowspan="1">4 s</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">NON_PROBING_WAIT</td>
            <td align="left" colspan="1" rowspan="1">between 247-248 s</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">NON_PARTIAL_TIMEOUT</td>
            <td align="left" colspan="1" rowspan="1">247 s</td>
          </tr>
        </tbody>
      </table>
      <t indent="0" pn="section-1-7">PROBING_RATE and other transmission parameters are negotiated between
      DOTS peers as discussed in <xref target="RFC9132" sectionFormat="of" section="4.5.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9132#section-4.5.2" derivedContent="RFC9132"/>. Nevertheless, negotiating the parameters
      listed in <xref target="tab-1" format="default" sectionFormat="of" derivedContent="Table 1"/> is not supported in <xref target="RFC9132" format="default" sectionFormat="of" derivedContent="RFC9132"/>.
      This document defines new DOTS signal channel attributes, corresponding
      to the parameters in <xref target="tab-1" format="default" sectionFormat="of" derivedContent="Table 1"/>, that are used to customize the
      configuration of robust block transmission in a DOTS context.</t>
    </section>
    <section anchor="notation" numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-terminology">Terminology</name>
      <t indent="0" pn="section-2-1">The key words "<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 "<bcp14>OPTIONAL</bcp14>" in this document
       are to be interpreted as described in BCP 14
       <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only
       when, they appear in all capitals, as shown here.</t>
      <t indent="0" pn="section-2-2">Readers should be familiar with the terms and concepts defined in
      <xref target="RFC7252" format="default" sectionFormat="of" derivedContent="RFC7252"/> and <xref target="RFC8612" format="default" sectionFormat="of" derivedContent="RFC8612"/>.</t>
      <t indent="0" pn="section-2-3">The terms "payload" and "body" are defined in <xref target="RFC7959" format="default" sectionFormat="of" derivedContent="RFC7959"/>. 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 indent="0" pn="section-2-4">The meanings of the symbols in YANG tree diagrams are defined in <xref target="RFC8340" format="default" sectionFormat="of" derivedContent="RFC8340"/> and <xref target="RFC8791" format="default" sectionFormat="of" derivedContent="RFC8791"/>.</t>
    </section>
    <section anchor="new" numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-dots-attributes-for-robust-">DOTS Attributes for Robust Block Transmission</name>
      <t indent="0" pn="section-3-1"><xref target="RFC9177" sectionFormat="of" section="7.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9177#section-7.2" derivedContent="RFC9177"/> defines the following
      parameters that are used for congestion control purposes:</t>
      <dl newline="false" spacing="normal" indent="3" pn="section-3-2">
        <dt pn="section-3-2.1">MAX_PAYLOADS:</dt>
        <dd pn="section-3-2.2">This parameter represents the maximum number of payloads that
          can be transmitted at any one time.</dd>
        <dt pn="section-3-2.3">NON_MAX_RETRANSMIT:</dt>
        <dd pn="section-3-2.4">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 (<xref target="RFC7252" sectionFormat="of" section="4.8" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7252#section-4.8" derivedContent="RFC7252"/>).</dd>
        <dt pn="section-3-2.5">NON_TIMEOUT:</dt>
        <dd pn="section-3-2.6">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 (<xref target="RFC7252" sectionFormat="of" section="4.8" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7252#section-4.8" derivedContent="RFC7252"/>).</dd>
        <dt pn="section-3-2.7">NON_TIMEOUT_RANDOM:</dt>
        <dd pn="section-3-2.8">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).</dd>
        <dt pn="section-3-2.9">NON_RECEIVE_TIMEOUT:</dt>
        <dd pn="section-3-2.10">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.</dd>
        <dt pn="section-3-2.11">NON_PROBING_WAIT:</dt>
        <dd pn="section-3-2.12">This parameter is used to limit the potential wait
          needed when using PROBING_RATE.</dd>
        <dt pn="section-3-2.13">NON_PARTIAL_TIMEOUT:</dt>
        <dd pn="section-3-2.14">This parameter is used for expiring partially
          received bodies.</dd>
      </dl>
      <t indent="0" pn="section-3-3">These parameters are used together with the PROBING_RATE 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 (<xref target="RFC7252" sectionFormat="of" section="4.7" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7252#section-4.7" derivedContent="RFC7252"/>), 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 indent="0" pn="section-3-4">This document augments the "ietf-dots-signal-channel" DOTS signal
      YANG module defined in <xref target="RFC9132" sectionFormat="of" section="5.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9132#section-5.3" derivedContent="RFC9132"/> with the following additional attributes that can be negotiated between
      DOTS peers to enable robust and faster transmission:</t>
      <dl newline="false" spacing="normal" indent="3" pn="section-3-5">
        <dt pn="section-3-5.1">max-payloads:</dt>
        <dd pn="section-3-5.2">
          <t indent="0" pn="section-3-5.2.1">This attribute echoes the MAX_PAYLOADS
          parameter defined in <xref target="RFC9177" format="default" sectionFormat="of" derivedContent="RFC9177"/>.</t>
          <t indent="0" pn="section-3-5.2.2">This is an optional attribute. If the attribute is
          supplied in both 'idle-config' and
          'mitigating-config', then it <bcp14>MUST</bcp14> convey the same value.
          If the attribute is only provided as part of
          'idle-config' (or 'mitigating-config'), then
          the other definition (i.e., 'mitigating-config' (or
          'idle-config')) <bcp14>MUST</bcp14> be updated to the same value.</t>
        </dd>
        <dt pn="section-3-5.3">non-max-retransmit:</dt>
        <dd pn="section-3-5.4">
          <t indent="0" pn="section-3-5.4.1">This attribute echoes the
          NON_MAX_RETRANSMIT parameter defined in <xref target="RFC9177" format="default" sectionFormat="of" derivedContent="RFC9177"/>. The
          default value of this attribute is 'max-retransmit'. Note that DOTS
          uses a default value of '3' instead of '4' (which is used 
          generically by CoAP for 'max-transmit'; see <xref target="RFC9132" sectionFormat="of" section="4.5.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9132#section-4.5.2" derivedContent="RFC9132"/> and <xref target="RFC7252" sectionFormat="of" section="4.8" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7252#section-4.8" derivedContent="RFC7252"/>).</t>
          <t indent="0" pn="section-3-5.4.2">This is an optional
          attribute.</t>
        </dd>
        <dt pn="section-3-5.5">non-timeout:</dt>
        <dd pn="section-3-5.6">
          <t indent="0" pn="section-3-5.6.1">This attribute, expressed in seconds,
          echoes the NON_TIMEOUT parameter defined in <xref target="RFC9177" format="default" sectionFormat="of" derivedContent="RFC9177"/>.
          The default value of this attribute is 'ack-timeout'.</t>
          <t indent="0" pn="section-3-5.6.2">This attribute is also used to compute the
          NON_TIMEOUT_RANDOM parameter.</t>
          <t indent="0" pn="section-3-5.6.3">This is an
          optional attribute.</t>
        </dd>
        <dt pn="section-3-5.7">non-receive-timeout:</dt>
        <dd pn="section-3-5.8">
          <t indent="0" pn="section-3-5.8.1">This attribute, expressed in
          seconds, echoes the NON_RECEIVE_TIMEOUT parameter defined in <xref target="RFC9177" format="default" sectionFormat="of" derivedContent="RFC9177"/>. The default value of this attribute is
          twice 'non-timeout'.</t>
          <t indent="0" pn="section-3-5.8.2">This is an optional
          attribute.</t>
        </dd>
        <dt pn="section-3-5.9">non-probing-wait:</dt>
        <dd pn="section-3-5.10">
          <t indent="0" pn="section-3-5.10.1">This attribute, expressed in
          seconds, echoes the NON_PROBING_WAIT parameter defined in <xref target="RFC9177" format="default" sectionFormat="of" derivedContent="RFC9177"/>. </t>
          <t indent="0" pn="section-3-5.10.2">This is an
          optional attribute.</t>
        </dd>
        <dt pn="section-3-5.11">non-partial-timeout:</dt>
        <dd pn="section-3-5.12">
          <t indent="0" pn="section-3-5.12.1">This attribute, expressed in
          seconds, echoes the NON_PARTIAL_TIMEOUT parameter defined in <xref target="RFC9177" format="default" sectionFormat="of" derivedContent="RFC9177"/>. The default value of this attribute is 247
          seconds.</t>
          <t indent="0" pn="section-3-5.12.2">This is an optional attribute.</t>
        </dd>
      </dl>
      <t indent="0" pn="section-3-6">The tree structure of the "ietf-dots-robust-trans" module (<xref target="module" format="default" sectionFormat="of" derivedContent="Section 5"/>) is shown in <xref target="tree" format="default" sectionFormat="of" derivedContent="Figure 1"/>.</t>
      <figure anchor="tree" align="left" suppress-title="false" pn="figure-1">
        <name slugifiedName="name-dots-fast-block-transmissio">DOTS Fast Block Transmission Tree Structure</name>
        <sourcecode name="" type="yangtree" markers="false" pn="section-3-7.1">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-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:
    +-- 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-timeout:
       +-- (direction)?
       |  +--:(server-to-client-only)
       |     +-- max-value-decimal?   decimal64
       |     +-- min-value-decimal?   decimal64
       +-- current-value-decimal?     decimal64
</sourcecode>
      </figure>
      <t indent="0" pn="section-3-8">These attributes are mapped to Concise Binary Object Representation (CBOR) types as specified in <xref target="maptab" format="default" sectionFormat="of" derivedContent="Section 4"/> and in <xref target="RFC9132" sectionFormat="of" section="6" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9132#section-6" derivedContent="RFC9132"/>.</t>
      <t indent="0" pn="section-3-9">DOTS clients follow the procedure specified in <xref target="RFC9132" sectionFormat="of" section="4.5" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9132#section-4.5" derivedContent="RFC9132"/> to negotiate, configure, and retrieve the DOTS
      signal channel session behavior (including Q-Block parameters) with DOTS
      peers.</t>
      <dl newline="false" spacing="normal" indent="3" pn="section-3-10">
        <dt pn="section-3-10.1">Implementation Note 1:</dt>
        <dd pn="section-3-10.2">'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); the jitter
          (ACK_RANDOM_FACTOR - 1) is then added to each time the value is
          checked.</dd>
        <dt pn="section-3-10.3">Implementation Note 2:</dt>
        <dd pn="section-3-10.4">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 <xref target="RFC9177" sectionFormat="of" section="7.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9177#section-7.2" derivedContent="RFC9177"/> unless explicit values are provided as part
          of the negotiated configuration.</dd>
      </dl>
      <t indent="0" pn="section-3-11">An example of a PUT message to configure Q-Block parameters is
      depicted in <xref target="put" format="default" sectionFormat="of" derivedContent="Figure 2"/>. 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-timeout' are not explicitly configured
      in this example, these attributes will be computed following the
      algorithms provided in <xref target="RFC9177" sectionFormat="of" section="7.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9177#section-7.2" derivedContent="RFC9177"/>. The meanings
      of the other attributes are detailed in <xref target="RFC9132" sectionFormat="of" section="4.5" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9132#section-4.5" derivedContent="RFC9132"/>.</t>
      <figure anchor="put" align="left" suppress-title="false" pn="figure-2">
        <name slugifiedName="name-example-of-put-to-convey-th">Example of PUT to Convey the Configuration Parameters</name>
        <sourcecode name="" type="http-message" markers="false" pn="section-3-12.1">
     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"
           }
         }
       }
     }
</sourcecode>
      </figure>
      <t indent="0" pn="section-3-13">The payload of the message depicted in <xref target="put" format="default" sectionFormat="of" derivedContent="Figure 2"/> is
      CBOR-encoded as indicated by the Content-Format set to
      "application/dots+cbor" (<xref target="RFC9132" sectionFormat="of" section="10.4" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9132#section-10.4" derivedContent="RFC9132"/>). However, and for the sake of better
      readability, the example uses JSON encoding of YANG-modeled data
      following the mapping tables in <xref target="maptab" format="default" sectionFormat="of" derivedContent="Section 4"/> and in <xref target="RFC9132" sectionFormat="of" section="6" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9132#section-6" derivedContent="RFC9132"/>: use the JSON names and types
      defined in <xref target="maptab" format="default" sectionFormat="of" derivedContent="Section 4"/>. These conventions are
      inherited from <xref target="RFC9132" format="default" sectionFormat="of" derivedContent="RFC9132"/>.</t>
    </section>
    <section anchor="maptab" numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-yang-json-mapping-parameter">YANG/JSON Mapping Parameters to CBOR</name>
      <t indent="0" pn="section-4-1">The YANG/JSON mapping parameters to CBOR are listed in <xref target="tab-2" format="default" sectionFormat="of" derivedContent="Table 2"/>.</t>
      <t indent="3" pn="section-4-2">Note: Implementers must check that the mapping output provided by
          their YANG-to-CBOR encoding schemes is aligned with the content of
          <xref target="tab-2" format="default" sectionFormat="of" derivedContent="Table 2"/>.</t>
      <table anchor="tab-2" align="center" pn="table-2">
        <name slugifiedName="name-yang-json-mapping-parameters">YANG/JSON Mapping Parameters to CBOR</name>
        <thead>
          <tr>
            <th align="left" colspan="1" rowspan="1">Parameter Name</th>
            <th align="left" colspan="1" rowspan="1">YANG Type</th>
            <th align="left" colspan="1" rowspan="1">CBOR Key</th>
            <th align="left" colspan="1" rowspan="1">CBOR Major Type &amp; Information</th>
            <th align="left" colspan="1" rowspan="1">JSON Type</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left" colspan="1" rowspan="1">ietf-dots-robust-trans:max-payloads</td>
            <td align="left" colspan="1" rowspan="1">container</td>
            <td align="left" colspan="1" rowspan="1">32776</td>
            <td align="left" colspan="1" rowspan="1">5 map</td>
            <td align="left" colspan="1" rowspan="1">Object</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">ietf-dots-robust-trans:non-max-retransmit</td>
            <td align="left" colspan="1" rowspan="1">container</td>
            <td align="left" colspan="1" rowspan="1">32777</td>
            <td align="left" colspan="1" rowspan="1">5 map</td>
            <td align="left" colspan="1" rowspan="1">Object</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">ietf-dots-robust-trans:non-timeout</td>
            <td align="left" colspan="1" rowspan="1">container</td>
            <td align="left" colspan="1" rowspan="1">32778</td>
            <td align="left" colspan="1" rowspan="1">5 map</td>
            <td align="left" colspan="1" rowspan="1">Object</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">ietf-dots-robust-trans:non-receive-timeout</td>
            <td align="left" colspan="1" rowspan="1">container</td>
            <td align="left" colspan="1" rowspan="1">32779</td>
            <td align="left" colspan="1" rowspan="1">5 map</td>
            <td align="left" colspan="1" rowspan="1">Object</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">ietf-dots-robust-trans:non-probing-wait</td>
            <td align="left" colspan="1" rowspan="1">container</td>
            <td align="left" colspan="1" rowspan="1">32780</td>
            <td align="left" colspan="1" rowspan="1">5 map</td>
            <td align="left" colspan="1" rowspan="1">Object</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">ietf-dots-robust-trans:non-partial-timeout</td>
            <td align="left" colspan="1" rowspan="1">container</td>
            <td align="left" colspan="1" rowspan="1">32781</td>
            <td align="left" colspan="1" rowspan="1">5 map</td>
            <td align="left" colspan="1" rowspan="1">Object</td>
          </tr>
        </tbody>
      </table>
    </section>
    <section anchor="module" numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-dots-robust-block-transmiss">DOTS Robust Block Transmission YANG Module</name>
      <t indent="0" pn="section-5-1">This module uses the data structure extension defined in <xref target="RFC8791" format="default" sectionFormat="of" derivedContent="RFC8791"/>.</t>
      <sourcecode name="ietf-dots-robust-trans@2023-02-28.yang" type="yang" markers="true" pn="section-5-2">
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:   &lt;https://datatracker.ietf.org/wg/dots/&gt;
     WG List:  &lt;mailto:dots@ietf.org&gt;

     Author:   Mohamed Boucadair
               &lt;mailto:mohamed.boucadair@orange.com&gt;;

     Author:   Jon Shallow
               &lt;mailto:ietf-supjps@jpshallow.com&gt;";
  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) 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 9362; see the
     RFC itself for full legal notices.";

  revision 2023-02-28 {
    description
      "Initial revision.";
    reference
      "RFC 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' value.";
          }
          leaf min-value {
            type uint16;
            description
              "Minimum acceptable 'max-payloads' value.";
          }
        }
      }
      leaf current-value {
        type uint16;
        default "10";
        description
          "Current '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' value.";
          }
          leaf min-value {
            type uint16;
            description
              "Minimum acceptable 'non-max-retransmit' value.";
          }
        }
      }
      leaf current-value {
        type uint16;
        default "3";
        description
          "Current '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' value.";
          }
          leaf min-value-decimal {
            type decimal64 {
              fraction-digits 2;
            }
            units "seconds";
            description
              "Minimum 'ack-timeout' value.";
          }
        }
      }
      leaf current-value-decimal {
        type decimal64 {
          fraction-digits 2;
        }
        units "seconds";
        default "2.00";
        description
          "Current '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' value.";
          }
          leaf min-value-decimal {
            type decimal64 {
              fraction-digits 2;
            }
            units "seconds";
            description
              "Minimum 'non-receive-timeout' value.";
          }
        }
      }
      leaf current-value-decimal {
        type decimal64 {
          fraction-digits 2;
        }
        units "seconds";
        default "4.00";
        description
          "Current '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
        "Used to limit the potential wait needed when
         using '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' value.";
          }
          leaf min-value-decimal {
            type decimal64 {
              fraction-digits 2;
            }
            units "seconds";
            description
              "Minimum 'non-probing-wait' value.";
          }
        }
      }
      leaf current-value-decimal {
        type decimal64 {
          fraction-digits 2;
        }
        units "seconds";
        description
          "Current 'non-probing-wait' value.";
        reference
          "RFC 9177: Constrained Application Protocol (CoAP)
                     Block-Wise Transfer Options Supporting
                     Robust Transmission, Section 7.2";
      }
    }
    container non-partial-timeout {
      description
        "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-timeout' value.";
          }
          leaf min-value-decimal {
            type decimal64 {
              fraction-digits 2;
            }
            units "seconds";
            description
              "Minimum 'non-partial-timeout' value.";
          }
        }
      }
      leaf current-value-decimal {
        type decimal64 {
          fraction-digits 2;
        }
        units "seconds";
        default "247.00";
        description
          "Current '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;
  }
}
</sourcecode>
    </section>
    <section anchor="IANA" numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <section anchor="map" numbered="true" toc="include" removeInRFC="false" pn="section-6.1">
        <name slugifiedName="name-registry-for-dots-signal-ch">Registry for DOTS Signal Channel CBOR Mappings</name>
        <t indent="0" pn="section-6.1-1">This specification registers the following parameters in the IANA
        "DOTS Signal Channel CBOR Key Values" registry <xref target="Key-Map" format="default" sectionFormat="of" derivedContent="Key-Map"/>.</t>
        <table align="center" pn="table-3">
          <name slugifiedName="name-dots-robust-block-transmissi">DOTS Robust Block Transmission CBOR Mappings</name>
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Parameter Name</th>
              <th align="left" colspan="1" rowspan="1">CBOR Key Value</th>
              <th align="left" colspan="1" rowspan="1">CBOR Major Type</th>
              <th align="left" colspan="1" rowspan="1">Change Controller</th>
              <th align="left" colspan="1" rowspan="1">Specification Document(s)</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">ietf-dots-robust-trans:max-payloads</td>
              <td align="left" colspan="1" rowspan="1">32776</td>
              <td align="left" colspan="1" rowspan="1">5</td>
              <td align="left" colspan="1" rowspan="1">IESG</td>
              <td align="left" colspan="1" rowspan="1">RFC 9362</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">ietf-dots-robust-trans:non-max-retransmit</td>
              <td align="left" colspan="1" rowspan="1">32777</td>
              <td align="left" colspan="1" rowspan="1">5</td>
              <td align="left" colspan="1" rowspan="1">IESG</td>
              <td align="left" colspan="1" rowspan="1">RFC 9362</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">ietf-dots-robust-trans:non-timeout</td>
              <td align="left" colspan="1" rowspan="1">32778</td>
              <td align="left" colspan="1" rowspan="1">5</td>
              <td align="left" colspan="1" rowspan="1">IESG</td>
              <td align="left" colspan="1" rowspan="1">RFC 9362</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">ietf-dots-robust-trans:non-receive-timeout</td>
              <td align="left" colspan="1" rowspan="1">32779</td>
              <td align="left" colspan="1" rowspan="1">5</td>
              <td align="left" colspan="1" rowspan="1">IESG</td>
              <td align="left" colspan="1" rowspan="1">RFC 9362</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">ietf-dots-robust-trans:non-probing-wait</td>
              <td align="left" colspan="1" rowspan="1">32780</td>
              <td align="left" colspan="1" rowspan="1">5</td>
              <td align="left" colspan="1" rowspan="1">IESG</td>
              <td align="left" colspan="1" rowspan="1">RFC 9362</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">ietf-dots-robust-trans:non-partial-timeout</td>
              <td align="left" colspan="1" rowspan="1">32781</td>
              <td align="left" colspan="1" rowspan="1">5</td>
              <td align="left" colspan="1" rowspan="1">IESG</td>
              <td align="left" colspan="1" rowspan="1">RFC 9362</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section anchor="yang-iana" numbered="true" toc="include" removeInRFC="false" pn="section-6.2">
        <name slugifiedName="name-dots-robust-block-transmissio">DOTS Robust Block Transmission YANG Module</name>
        <t indent="0" pn="section-6.2-1">IANA has registered the following URI in the
        "ns" subregistry within the "IETF XML Registry" <xref target="RFC3688" format="default" sectionFormat="of" derivedContent="RFC3688"/>:</t>
        <dl newline="false" spacing="compact" indent="3" pn="section-6.2-2">
          <dt pn="section-6.2-2.1">URI:</dt>
          <dd pn="section-6.2-2.2">urn:ietf:params:xml:ns:yang:ietf-dots-robust-trans</dd>
          <dt pn="section-6.2-2.3">Registrant Contact:</dt>
          <dd pn="section-6.2-2.4">The IESG.</dd>
          <dt pn="section-6.2-2.5">XML:</dt>
          <dd pn="section-6.2-2.6">N/A; the requested URI is an XML namespace.</dd>
        </dl>
        <t indent="0" pn="section-6.2-3">IANA has registered the following YANG module
        in the "YANG Module Names" subregistry <xref target="RFC6020" format="default" sectionFormat="of" derivedContent="RFC6020"/>
        within the "YANG Parameters" registry.</t>
        <dl newline="false" spacing="compact" indent="3" pn="section-6.2-4">
          <dt pn="section-6.2-4.1">Name:</dt>
          <dd pn="section-6.2-4.2">ietf-dots-robust-trans</dd>
          <dt pn="section-6.2-4.3">Namespace:</dt>
          <dd pn="section-6.2-4.4">urn:ietf:params:xml:ns:yang:ietf-dots-robust-trans</dd>
          <dt pn="section-6.2-4.5">Maintained by IANA?</dt>
          <dd pn="section-6.2-4.6">N</dd>
          <dt pn="section-6.2-4.7">Prefix:</dt>
          <dd pn="section-6.2-4.8">dots-robust</dd>
          <dt pn="section-6.2-4.9">Reference:</dt>
          <dd pn="section-6.2-4.10">RFC 9362</dd>
        </dl>
      </section>
    </section>
    <section anchor="security" numbered="true" toc="include" removeInRFC="false" pn="section-7">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-7-1">The security considerations for the DOTS signal channel protocol are
      discussed in <xref target="RFC9132" sectionFormat="of" section="11" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9132#section-11" derivedContent="RFC9132"/>.</t>
      <t indent="0" pn="section-7-2">CoAP-specific security considerations are discussed in <xref target="RFC9177" sectionFormat="of" section="11" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9177#section-11" derivedContent="RFC9177"/>.</t>
      <t indent="0" pn="section-7-3">Consistent with <xref target="RFC9132" sectionFormat="of" section="5" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9132#section-5" derivedContent="RFC9132"/>, 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 pn="section-8">
      <name slugifiedName="name-references">References</name>
      <references pn="section-8.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t indent="0">In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized.  This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC3688" target="https://www.rfc-editor.org/info/rfc3688" quoteTitle="true" derivedAnchor="RFC3688">
          <front>
            <title>The IETF XML Registry</title>
            <author fullname="M. Mealling" initials="M." surname="Mealling"/>
            <date month="January" year="2004"/>
            <abstract>
              <t indent="0">This document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="81"/>
          <seriesInfo name="RFC" value="3688"/>
          <seriesInfo name="DOI" value="10.17487/RFC3688"/>
        </reference>
        <reference anchor="RFC6020" target="https://www.rfc-editor.org/info/rfc6020" quoteTitle="true" derivedAnchor="RFC6020">
          <front>
            <title>YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)</title>
            <author fullname="M. Bjorklund" initials="M." role="editor" surname="Bjorklund"/>
            <date month="October" year="2010"/>
            <abstract>
              <t indent="0">YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6020"/>
          <seriesInfo name="DOI" value="10.17487/RFC6020"/>
        </reference>
        <reference anchor="RFC7252" target="https://www.rfc-editor.org/info/rfc7252" quoteTitle="true" derivedAnchor="RFC7252">
          <front>
            <title>The Constrained Application Protocol (CoAP)</title>
            <author fullname="Z. Shelby" initials="Z." surname="Shelby"/>
            <author fullname="K. Hartke" initials="K." surname="Hartke"/>
            <author fullname="C. Bormann" initials="C." surname="Bormann"/>
            <date month="June" year="2014"/>
            <abstract>
              <t indent="0">The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation.</t>
              <t indent="0">CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7252"/>
          <seriesInfo name="DOI" value="10.17487/RFC7252"/>
        </reference>
        <reference anchor="RFC7959" target="https://www.rfc-editor.org/info/rfc7959" quoteTitle="true" derivedAnchor="RFC7959">
          <front>
            <title>Block-Wise Transfers in the Constrained Application Protocol (CoAP)</title>
            <author fullname="C. Bormann" initials="C." surname="Bormann"/>
            <author fullname="Z. Shelby" initials="Z." role="editor" surname="Shelby"/>
            <date month="August" year="2016"/>
            <abstract>
              <t indent="0">The Constrained Application Protocol (CoAP) is a RESTful transfer protocol for constrained nodes and networks. Basic CoAP messages work well for small payloads from sensors and actuators; however, applications will need to transfer larger payloads occasionally -- for instance, for firmware updates. In contrast to HTTP, where TCP does the grunt work of segmenting and resequencing, CoAP is based on datagram transports such as UDP or Datagram Transport Layer Security (DTLS). These transports only offer fragmentation, which is even more problematic in constrained nodes and networks, limiting the maximum size of resource representations that can practically be transferred.</t>
              <t indent="0">Instead of relying on IP fragmentation, this specification extends basic CoAP with a pair of "Block" options for transferring multiple blocks of information from a resource representation in multiple request-response pairs. In many important cases, the Block options enable a server to be truly stateless: the server can handle each block transfer separately, with no need for a connection setup or other server-side memory of previous block transfers. Essentially, the Block options provide a minimal way to transfer larger representations in a block-wise fashion.</t>
              <t indent="0">A CoAP implementation that does not support these options generally is limited in the size of the representations that can be exchanged, so there is an expectation that the Block options will be widely used in CoAP implementations. Therefore, this specification updates RFC 7252.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7959"/>
          <seriesInfo name="DOI" value="10.17487/RFC7959"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t indent="0">RFC 2119 specifies common key words that may be used in protocol specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC8323" target="https://www.rfc-editor.org/info/rfc8323" quoteTitle="true" derivedAnchor="RFC8323">
          <front>
            <title>CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets</title>
            <author fullname="C. Bormann" initials="C." surname="Bormann"/>
            <author fullname="S. Lemay" initials="S." surname="Lemay"/>
            <author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/>
            <author fullname="K. Hartke" initials="K." surname="Hartke"/>
            <author fullname="B. Silverajan" initials="B." surname="Silverajan"/>
            <author fullname="B. Raymor" initials="B." role="editor" surname="Raymor"/>
            <date month="February" year="2018"/>
            <abstract>
              <t indent="0">The Constrained Application Protocol (CoAP), 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.</t>
              <t indent="0">Some environments benefit from the availability of CoAP carried over reliable transports such as TCP or Transport Layer Security (TLS). This document outlines the changes required to use CoAP over TCP, TLS, and WebSockets transports. It also formally updates RFC 7641 for use with these transports and RFC 7959 to enable the use of larger messages over a reliable transport.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8323"/>
          <seriesInfo name="DOI" value="10.17487/RFC8323"/>
        </reference>
        <reference anchor="RFC8791" target="https://www.rfc-editor.org/info/rfc8791" quoteTitle="true" derivedAnchor="RFC8791">
          <front>
            <title>YANG Data Structure Extensions</title>
            <author fullname="A. Bierman" initials="A." surname="Bierman"/>
            <author fullname="M. Björklund" initials="M." surname="Björklund"/>
            <author fullname="K. Watsen" initials="K." surname="Watsen"/>
            <date month="June" year="2020"/>
            <abstract>
              <t indent="0">This document describes YANG mechanisms for defining abstract data structures with YANG.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8791"/>
          <seriesInfo name="DOI" value="10.17487/RFC8791"/>
        </reference>
        <reference anchor="RFC9132" target="https://www.rfc-editor.org/info/rfc9132" quoteTitle="true" derivedAnchor="RFC9132">
          <front>
            <title>Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification</title>
            <author fullname="M. Boucadair" initials="M." role="editor" surname="Boucadair"/>
            <author fullname="J. Shallow" initials="J." surname="Shallow"/>
            <author fullname="T. Reddy.K" initials="T." surname="Reddy.K"/>
            <date month="September" year="2021"/>
            <abstract>
              <t indent="0">This document specifies the Distributed Denial-of-Service Open Threat Signaling (DOTS) signal channel, a protocol for signaling the need for protection against Distributed Denial-of-Service (DDoS) attacks to a server capable of enabling network traffic mitigation on behalf of the requesting client.</t>
              <t indent="0">A companion document defines the DOTS data channel, a separate reliable communication layer for DOTS management and configuration purposes.</t>
              <t indent="0">This document obsoletes RFC 8782.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9132"/>
          <seriesInfo name="DOI" value="10.17487/RFC9132"/>
        </reference>
        <reference anchor="RFC9177" target="https://www.rfc-editor.org/info/rfc9177" quoteTitle="true" derivedAnchor="RFC9177">
          <front>
            <title>Constrained Application Protocol (CoAP) Block-Wise Transfer Options Supporting Robust Transmission</title>
            <author fullname="M. Boucadair" initials="M." surname="Boucadair"/>
            <author fullname="J. Shallow" initials="J." surname="Shallow"/>
            <date month="March" year="2022"/>
            <abstract>
              <t indent="0">This document specifies alternative Constrained Application Protocol (CoAP) block-wise transfer options: Q-Block1 and Q-Block2.</t>
              <t indent="0">These options are similar to, but distinct from, the CoAP Block1 and Block2 options defined in RFC 7959. The Q-Block1 and Q-Block2 options are not intended to replace the Block1 and Block2 options but rather have the goal of supporting Non-confirmable (NON) messages for large amounts of data with fewer packet interchanges. Also, the Q-Block1 and Q-Block2 options support faster recovery should any of the blocks get lost in transmission.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9177"/>
          <seriesInfo name="DOI" value="10.17487/RFC9177"/>
        </reference>
      </references>
      <references pn="section-8.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="Key-Map" target="https://www.iana.org/assignments/dots/" quoteTitle="true" derivedAnchor="Key-Map">
          <front>
            <title>DOTS Signal Channel CBOR Key Values</title>
            <author>
              <organization showOnFrontPage="true">IANA</organization>
            </author>
            <date/>
          </front>
        </reference>
        <reference anchor="RFC8340" target="https://www.rfc-editor.org/info/rfc8340" quoteTitle="true" derivedAnchor="RFC8340">
          <front>
            <title>YANG Tree Diagrams</title>
            <author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
            <author fullname="L. Berger" initials="L." role="editor" surname="Berger"/>
            <date month="March" year="2018"/>
            <abstract>
              <t indent="0">This document captures the current syntax used in YANG module tree diagrams.  The purpose of this document is to provide a single location for this definition.  This syntax may be updated from time to time based on the evolution of the YANG language.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="215"/>
          <seriesInfo name="RFC" value="8340"/>
          <seriesInfo name="DOI" value="10.17487/RFC8340"/>
        </reference>
        <reference anchor="RFC8612" target="https://www.rfc-editor.org/info/rfc8612" quoteTitle="true" derivedAnchor="RFC8612">
          <front>
            <title>DDoS Open Threat Signaling (DOTS) Requirements</title>
            <author fullname="A. Mortensen" initials="A." surname="Mortensen"/>
            <author fullname="T. Reddy" initials="T." surname="Reddy"/>
            <author fullname="R. Moskowitz" initials="R." surname="Moskowitz"/>
            <date month="May" year="2019"/>
            <abstract>
              <t indent="0">This document defines the requirements for the Distributed Denial-of- Service (DDoS) Open Threat Signaling (DOTS) protocols enabling coordinated response to DDoS attacks.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8612"/>
          <seriesInfo name="DOI" value="10.17487/RFC8612"/>
        </reference>
        <reference anchor="RFC9244" target="https://www.rfc-editor.org/info/rfc9244" quoteTitle="true" derivedAnchor="RFC9244">
          <front>
            <title>Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry</title>
            <author fullname="M. Boucadair" initials="M." role="editor" surname="Boucadair"/>
            <author fullname="T. Reddy.K" initials="T." role="editor" surname="Reddy.K"/>
            <author fullname="E. Doron" initials="E." surname="Doron"/>
            <author fullname="M. Chen" initials="M." surname="Chen"/>
            <author fullname="J. Shallow" initials="J." surname="Shallow"/>
            <date month="June" year="2022"/>
            <abstract>
              <t indent="0">This document aims to enrich the Distributed Denial-of-Service Open Threat Signaling (DOTS) signal channel protocol with various telemetry attributes, allowing for optimal Distributed Denial-of-Service (DDoS) attack mitigation. It specifies the normal traffic baseline and attack traffic telemetry attributes a DOTS client can convey to its DOTS server in the mitigation request, the mitigation status telemetry attributes a DOTS server can communicate to a DOTS client, and the mitigation efficacy telemetry attributes a DOTS client can communicate to a DOTS server. The telemetry attributes can assist the mitigator in choosing the DDoS mitigation techniques and performing optimal DDoS attack mitigation.</t>
              <t indent="0">This document specifies two YANG modules: one for representing DOTS telemetry message types and one for sharing the attack mapping details over the DOTS data channel.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9244"/>
          <seriesInfo name="DOI" value="10.17487/RFC9244"/>
        </reference>
      </references>
    </references>
    <section anchor="ack" numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t indent="0" pn="section-appendix.a-1">Thanks to <contact fullname="Tiru Reddy"/>, <contact fullname="Meiling Chen"/>, and <contact fullname="Kaname Nishizuka"/> for the
      review.</t>
      <t indent="0" pn="section-appendix.a-2">Thanks to <contact fullname="Michal Vaško"/> for the yangdoctors review.</t>
      <t indent="0" pn="section-appendix.a-3">Thanks to <contact fullname="Valery Smyslov"/> for shepherding the document, <contact fullname="Paul Wouters"/>
      for the AD review, <contact fullname="Paul Kyzivat"/> for the artart directorate review, <contact fullname="Tim Evens"/> for the Gen-ART review, and <contact fullname="Jean-Michel Combes"/> for the int-dir
      review.</t>
      <t indent="0" pn="section-appendix.a-4">Thanks to <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 their comments during the IESG
      review.</t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
        <organization showOnFrontPage="true">Orange</organization>
        <address>
          <postal>
            <street/>
            <city>Rennes</city>
            <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 showOnFrontPage="true"/>
        <address>
          <postal>
            <street/>
            <city/>
            <region/>
            <code/>
            <country>United Kingdom</country>
          </postal>
          <email>supjps-ietf@jpshallow.com</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
