<?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-telemetry-25" indexInclude="true" ipr="trust200902" number="9244" prepTime="2022-06-20T09:39:43" scripts="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude="true" xml:lang="en">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-dots-telemetry-25" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9244" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="DOTS Telemetry">Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry</title>
    <seriesInfo name="RFC" value="9244" stream="IETF"/>
    <author fullname="Mohamed Boucadair" initials="M." role="editor" surname="Boucadair">
      <organization showOnFrontPage="true">Orange</organization>
      <address>
        <postal>
          <street/>
          <city>Rennes</city>
          <code>35000</code>
          <country>France</country>
        </postal>
        <email>mohamed.boucadair@orange.com</email>
      </address>
    </author>
    <author fullname="Tirumaleswar Reddy.K" initials="T." role="editor" surname="Reddy.K">
      <organization showOnFrontPage="true">Akamai</organization>
      <address>
        <postal>
          <street>Embassy Golf Link Business Park</street>
          <city>Bangalore</city>
          <region>Karnataka</region>
          <code>560071</code>
          <country>India</country>
        </postal>
        <email>kondtir@gmail.com</email>
      </address>
    </author>
    <author fullname="Ehud Doron" initials="E." surname="Doron">
      <organization showOnFrontPage="true">Radware Ltd.</organization>
      <address>
        <postal>
          <street>Raoul Wallenberg Street</street>
          <city>Tel-Aviv</city>
          <code>69710</code>
          <country>Israel</country>
        </postal>
        <email>ehudd@radware.com</email>
      </address>
    </author>
    <author fullname="Meiling Chen" initials="M." surname="Chen">
      <organization showOnFrontPage="true">CMCC</organization>
      <address>
        <postal>
          <street>32 Xuanwumen West Street</street>
          <city>Beijing</city>
          <code>100053</code>
          <country>China</country>
        </postal>
        <email>chenmeiling@chinamobile.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="06" year="2022"/>
    <area>sec</area>
    <workgroup>DOTS</workgroup>
    <keyword>automation</keyword>
    <keyword>cybersecurity</keyword>
    <keyword>DDoS</keyword>
    <keyword>Resilience</keyword>
    <keyword>Intelligence</keyword>
    <keyword>Service delivery</keyword>
    <keyword>Robustness</keyword>
    <keyword>Collaborative</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">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" pn="section-abstract-2">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>
    <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/rfc9244" 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) 2022 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" 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-telemetry-overview-and">DOTS Telemetry: Overview and Purpose</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2">
              <li pn="section-toc.1-1.3.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.3.2.1.1"><xref derivedContent="3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-need-for-more-visibility">Need for More Visibility</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.2">
                <t indent="0" pn="section-toc.1-1.3.2.2.1"><xref derivedContent="3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-enhanced-detection">Enhanced Detection</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.3">
                <t indent="0" pn="section-toc.1-1.3.2.3.1"><xref derivedContent="3.3" format="counter" sectionFormat="of" target="section-3.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-efficient-mitigation">Efficient Mitigation</xref></t>
              </li>
            </ul>
          </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-design-overview">Design Overview</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2">
              <li pn="section-toc.1-1.4.2.1">
                <t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-overview-of-telemetry-opera">Overview of Telemetry Operations</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.2">
                <t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-block-wise-transfers">Block-Wise Transfers</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.3">
                <t indent="0" pn="section-toc.1-1.4.2.3.1"><xref derivedContent="4.3" format="counter" sectionFormat="of" target="section-4.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-dots-multihoming-considerat">DOTS Multihoming Considerations</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.4">
                <t indent="0" pn="section-toc.1-1.4.2.4.1"><xref derivedContent="4.4" format="counter" sectionFormat="of" target="section-4.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-yang-considerations">YANG Considerations</xref></t>
              </li>
            </ul>
          </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-generic-considerations">Generic Considerations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2">
              <li pn="section-toc.1-1.5.2.1">
                <t indent="0" pn="section-toc.1-1.5.2.1.1"><xref derivedContent="5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-dots-client-identification">DOTS Client Identification</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.2">
                <t indent="0" pn="section-toc.1-1.5.2.2.1"><xref derivedContent="5.2" format="counter" sectionFormat="of" target="section-5.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-dots-gateways">DOTS Gateways</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.3">
                <t indent="0" pn="section-toc.1-1.5.2.3.1"><xref derivedContent="5.3" format="counter" sectionFormat="of" target="section-5.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-uri-path-parameters-and-emp">Uri-Path Parameters and Empty Values</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.4">
                <t indent="0" pn="section-toc.1-1.5.2.4.1"><xref derivedContent="5.4" format="counter" sectionFormat="of" target="section-5.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-controlling-configuration-d">Controlling Configuration Data</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.5">
                <t indent="0" pn="section-toc.1-1.5.2.5.1"><xref derivedContent="5.5" format="counter" sectionFormat="of" target="section-5.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-message-validation">Message Validation</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.6">
                <t indent="0" pn="section-toc.1-1.5.2.6.1"><xref derivedContent="5.6" format="counter" sectionFormat="of" target="section-5.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-a-note-about-examples">A Note about Examples</xref></t>
              </li>
            </ul>
          </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-telemetry-operation-paths">Telemetry Operation Paths</xref></t>
          </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-dots-telemetry-setup-config">DOTS Telemetry Setup Configuration</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2">
              <li pn="section-toc.1-1.7.2.1">
                <t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent="7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-telemetry-configuration">Telemetry Configuration</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2.1.2">
                  <li pn="section-toc.1-1.7.2.1.2.1">
                    <t indent="0" pn="section-toc.1-1.7.2.1.2.1.1"><xref derivedContent="7.1.1" format="counter" sectionFormat="of" target="section-7.1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-retrieving-the-current-dots">Retrieving the Current DOTS Telemetry Configuration</xref></t>
                  </li>
                  <li pn="section-toc.1-1.7.2.1.2.2">
                    <t indent="0" pn="section-toc.1-1.7.2.1.2.2.1"><xref derivedContent="7.1.2" format="counter" sectionFormat="of" target="section-7.1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-conveying-the-dots-telemetr">Conveying the DOTS Telemetry Configuration</xref></t>
                  </li>
                  <li pn="section-toc.1-1.7.2.1.2.3">
                    <t indent="0" pn="section-toc.1-1.7.2.1.2.3.1"><xref derivedContent="7.1.3" format="counter" sectionFormat="of" target="section-7.1.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-retrieving-the-installed-do">Retrieving the Installed DOTS Telemetry Configuration</xref></t>
                  </li>
                  <li pn="section-toc.1-1.7.2.1.2.4">
                    <t indent="0" pn="section-toc.1-1.7.2.1.2.4.1"><xref derivedContent="7.1.4" format="counter" sectionFormat="of" target="section-7.1.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-deleting-the-dots-telemetry">Deleting the DOTS Telemetry Configuration</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.7.2.2">
                <t indent="0" pn="section-toc.1-1.7.2.2.1"><xref derivedContent="7.2" format="counter" sectionFormat="of" target="section-7.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-total-pipe-capacity">Total Pipe Capacity</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2.2.2">
                  <li pn="section-toc.1-1.7.2.2.2.1">
                    <t indent="0" pn="section-toc.1-1.7.2.2.2.1.1"><xref derivedContent="7.2.1" format="counter" sectionFormat="of" target="section-7.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-conveying-dots-client-domai">Conveying DOTS Client Domain Pipe Capacity</xref></t>
                  </li>
                  <li pn="section-toc.1-1.7.2.2.2.2">
                    <t indent="0" pn="section-toc.1-1.7.2.2.2.2.1"><xref derivedContent="7.2.2" format="counter" sectionFormat="of" target="section-7.2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-retrieving-installed-dots-c">Retrieving Installed DOTS Client Domain Pipe Capacity</xref></t>
                  </li>
                  <li pn="section-toc.1-1.7.2.2.2.3">
                    <t indent="0" pn="section-toc.1-1.7.2.2.2.3.1"><xref derivedContent="7.2.3" format="counter" sectionFormat="of" target="section-7.2.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-deleting-installed-dots-cli">Deleting Installed DOTS Client Domain Pipe Capacity</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.7.2.3">
                <t indent="0" pn="section-toc.1-1.7.2.3.1"><xref derivedContent="7.3" format="counter" sectionFormat="of" target="section-7.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-telemetry-baseline">Telemetry Baseline</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2.3.2">
                  <li pn="section-toc.1-1.7.2.3.2.1">
                    <t indent="0" pn="section-toc.1-1.7.2.3.2.1.1"><xref derivedContent="7.3.1" format="counter" sectionFormat="of" target="section-7.3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-conveying-dots-client-domain">Conveying DOTS Client Domain Baseline Information</xref></t>
                  </li>
                  <li pn="section-toc.1-1.7.2.3.2.2">
                    <t indent="0" pn="section-toc.1-1.7.2.3.2.2.1"><xref derivedContent="7.3.2" format="counter" sectionFormat="of" target="section-7.3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-retrieving-installed-normal">Retrieving Installed Normal Traffic Baseline Information</xref></t>
                  </li>
                  <li pn="section-toc.1-1.7.2.3.2.3">
                    <t indent="0" pn="section-toc.1-1.7.2.3.2.3.1"><xref derivedContent="7.3.3" format="counter" sectionFormat="of" target="section-7.3.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-deleting-installed-normal-t">Deleting Installed Normal Traffic Baseline Information</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.7.2.4">
                <t indent="0" pn="section-toc.1-1.7.2.4.1"><xref derivedContent="7.4" format="counter" sectionFormat="of" target="section-7.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-resetting-the-installed-tel">Resetting the Installed Telemetry Setup</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.5">
                <t indent="0" pn="section-toc.1-1.7.2.5.1"><xref derivedContent="7.5" format="counter" sectionFormat="of" target="section-7.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-conflict-with-other-dots-cl">Conflict with Other DOTS Clients of the Same Domain</xref></t>
              </li>
            </ul>
          </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-dots-pre-or-ongoing-mitigat">DOTS Pre-or-Ongoing-Mitigation Telemetry</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-pre-or-ongoing-mitigation-d">Pre-or-Ongoing-Mitigation DOTS Telemetry Attributes</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.8.2.1.2">
                  <li pn="section-toc.1-1.8.2.1.2.1">
                    <t indent="0" pn="section-toc.1-1.8.2.1.2.1.1"><xref derivedContent="8.1.1" format="counter" sectionFormat="of" target="section-8.1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-target">Target</xref></t>
                  </li>
                  <li pn="section-toc.1-1.8.2.1.2.2">
                    <t indent="0" pn="section-toc.1-1.8.2.1.2.2.1"><xref derivedContent="8.1.2" format="counter" sectionFormat="of" target="section-8.1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-total-traffic">Total Traffic</xref></t>
                  </li>
                  <li pn="section-toc.1-1.8.2.1.2.3">
                    <t indent="0" pn="section-toc.1-1.8.2.1.2.3.1"><xref derivedContent="8.1.3" format="counter" sectionFormat="of" target="section-8.1.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-total-attack-traffic">Total Attack Traffic</xref></t>
                  </li>
                  <li pn="section-toc.1-1.8.2.1.2.4">
                    <t indent="0" pn="section-toc.1-1.8.2.1.2.4.1"><xref derivedContent="8.1.4" format="counter" sectionFormat="of" target="section-8.1.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-total-attack-connections">Total Attack Connections</xref></t>
                  </li>
                  <li pn="section-toc.1-1.8.2.1.2.5">
                    <t indent="0" pn="section-toc.1-1.8.2.1.2.5.1"><xref derivedContent="8.1.5" format="counter" sectionFormat="of" target="section-8.1.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-attack-details">Attack Details</xref></t>
                  </li>
                  <li pn="section-toc.1-1.8.2.1.2.6">
                    <t indent="0" pn="section-toc.1-1.8.2.1.2.6.1"><xref derivedContent="8.1.6" format="counter" sectionFormat="of" target="section-8.1.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-vendor-attack-mapping">Vendor Attack Mapping</xref></t>
                  </li>
                </ul>
              </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-from-dots-clients-to-dots-s">From DOTS Clients to DOTS Servers</xref></t>
              </li>
              <li pn="section-toc.1-1.8.2.3">
                <t indent="0" pn="section-toc.1-1.8.2.3.1"><xref derivedContent="8.3" format="counter" sectionFormat="of" target="section-8.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-from-dots-servers-to-dots-c">From DOTS Servers to DOTS Clients</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-dots-telemetry-mitigation-s">DOTS Telemetry Mitigation Status Update</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.9.2">
              <li pn="section-toc.1-1.9.2.1">
                <t indent="0" pn="section-toc.1-1.9.2.1.1"><xref derivedContent="9.1" format="counter" sectionFormat="of" target="section-9.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-from-dots-clients-to-dots-se">From DOTS Clients to DOTS Servers: Mitigation Efficacy DOTS Telemetry Attributes</xref></t>
              </li>
              <li pn="section-toc.1-1.9.2.2">
                <t indent="0" pn="section-toc.1-1.9.2.2.1"><xref derivedContent="9.2" format="counter" sectionFormat="of" target="section-9.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-from-dots-servers-to-dots-cl">From DOTS Servers to DOTS Clients: Mitigation Status DOTS Telemetry Attributes</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="10" format="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-error-handling">Error Handling</xref></t>
          </li>
          <li pn="section-toc.1-1.11">
            <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="11" format="counter" sectionFormat="of" target="section-11"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-yang-modules">YANG Modules</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.11.2">
              <li pn="section-toc.1-1.11.2.1">
                <t indent="0" pn="section-toc.1-1.11.2.1.1"><xref derivedContent="11.1" format="counter" sectionFormat="of" target="section-11.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-dots-signal-channel-telemet">DOTS Signal Channel Telemetry YANG Module</xref></t>
              </li>
              <li pn="section-toc.1-1.11.2.2">
                <t indent="0" pn="section-toc.1-1.11.2.2.1"><xref derivedContent="11.2" format="counter" sectionFormat="of" target="section-11.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-vendor-attack-mapping-detai">Vendor Attack Mapping Details YANG Module</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.12">
            <t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="12" format="counter" sectionFormat="of" target="section-12"/>. <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.13">
            <t indent="0" pn="section-toc.1-1.13.1"><xref derivedContent="13" format="counter" sectionFormat="of" target="section-13"/>. <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.13.2">
              <li pn="section-toc.1-1.13.2.1">
                <t indent="0" pn="section-toc.1-1.13.2.1.1"><xref derivedContent="13.1" format="counter" sectionFormat="of" target="section-13.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-dots-signal-channel-cbor-ke">DOTS Signal Channel CBOR Key Values</xref></t>
              </li>
              <li pn="section-toc.1-1.13.2.2">
                <t indent="0" pn="section-toc.1-1.13.2.2.1"><xref derivedContent="13.2" format="counter" sectionFormat="of" target="section-13.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-dots-signal-channel-conflic">DOTS Signal Channel Conflict Cause Codes</xref></t>
              </li>
              <li pn="section-toc.1-1.13.2.3">
                <t indent="0" pn="section-toc.1-1.13.2.3.1"><xref derivedContent="13.3" format="counter" sectionFormat="of" target="section-13.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-dots-telemetry-uris-and-yan">DOTS Telemetry URIs and YANG Module Registrations</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.14">
            <t indent="0" pn="section-toc.1-1.14.1"><xref derivedContent="14" format="counter" sectionFormat="of" target="section-14"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.14.2">
              <li pn="section-toc.1-1.14.2.1">
                <t indent="0" pn="section-toc.1-1.14.2.1.1"><xref derivedContent="14.1" format="counter" sectionFormat="of" target="section-14.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-dots-signal-channel-telemetr">DOTS Signal Channel Telemetry</xref></t>
              </li>
              <li pn="section-toc.1-1.14.2.2">
                <t indent="0" pn="section-toc.1-1.14.2.2.1"><xref derivedContent="14.2" format="counter" sectionFormat="of" target="section-14.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-vendor-attack-mapping-2">Vendor Attack Mapping</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.15">
            <t indent="0" pn="section-toc.1-1.15.1"><xref derivedContent="15" format="counter" sectionFormat="of" target="section-15"/>. <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.15.2">
              <li pn="section-toc.1-1.15.2.1">
                <t indent="0" pn="section-toc.1-1.15.2.1.1"><xref derivedContent="15.1" format="counter" sectionFormat="of" target="section-15.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.15.2.2">
                <t indent="0" pn="section-toc.1-1.15.2.2.1"><xref derivedContent="15.2" format="counter" sectionFormat="of" target="section-15.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.16">
            <t indent="0" pn="section-toc.1-1.16.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgments">Acknowledgments</xref></t>
          </li>
          <li pn="section-toc.1-1.17">
            <t indent="0" pn="section-toc.1-1.17.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-contributors">Contributors</xref></t>
          </li>
          <li pn="section-toc.1-1.18">
            <t indent="0" pn="section-toc.1-1.18.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.c"/><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">IT organizations and service providers are facing Distributed Denial-of-Service
      (DDoS) attacks that fall into two broad categories:</t>
      <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-1-2"><li pn="section-1-2.1" derivedCounter="1.">
          <t indent="0" pn="section-1-2.1.1">Network-layer and transport-layer attacks target the victim's
          infrastructure. These attacks are not necessarily aimed at taking
          down the actual delivered services; rather, these attacks prevent various
          network elements (routers, switches, firewalls, transit links, and
          so on) from serving legitimate users' traffic. </t>
          <t indent="0" pn="section-1-2.1.2">The main method of such attacks is to send a large
          volume of traffic (e.g., high-pps (packets per second) traffic) toward the
          victim's infrastructure. Typically, attack volumes may vary from a
          few hundred Mbps to hundreds of Gbps or even Tbps. Attacks are commonly
          carried out leveraging botnets and attack reflectors for
          amplification attacks (<xref target="RFC4732" sectionFormat="of" section="3.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4732#section-3.1" derivedContent="RFC4732"/>) such as NTP (Network Time Protocol), DNS
          (Domain Name System), SNMP (Simple Network Management Protocol), or
          SSDP (Simple Service Discovery Protocol).</t>
        </li>
        <li pn="section-1-2.2" derivedCounter="2.">
          <t indent="0" pn="section-1-2.2.1">Application-layer attacks target various applications. Typical
          examples include attacks against HTTP/HTTPS, DNS, SIP (Session
          Initiation Protocol), or SMTP (Simple Mail Transfer Protocol).
          However, all applications with their port numbers open at network
          edges can be attractive attack targets. </t>
          <t indent="0" pn="section-1-2.2.2">Application-layer attacks are considered more
          complex and harder to categorize and are therefore harder to detect and
          mitigate efficiently.</t>
        </li>
      </ol>
      <t indent="0" pn="section-1-3">To compound the problem, attackers also leverage multi-vectored
      attacks. These attacks are assembled from dynamic network-layer and 
      application-layer attack vectors and other tactics. As such, multiple attack vectors
      formed by multiple attack types and volumes are launched simultaneously
      toward a victim. Multi-vector attacks are harder to detect and defend
      against. Multiple and simultaneous mitigation techniques are needed to
      defeat such attack campaigns. It is also common for attackers to change
      attack vectors right after a successful mitigation, burdening their
      opponents with changing their defense methods.</t>
      <t indent="0" pn="section-1-4">The conclusion derived from the aforementioned attack scenarios is
      that modern attack detection and mitigation are most certainly
      complicated and highly convoluted tasks. They demand a comprehensive
      knowledge of the attack attributes and the normal behavior of the targeted
      systems (including normal traffic patterns), as well as the attacker's
      ongoing and past actions. Even more challenging, retrieving all the
      analytics needed for detecting these attacks is not simple with the
      industry's current reporting capabilities.</t>
      <t indent="0" pn="section-1-5">The Distributed Denial-of-Service Open Threat Signaling (DOTS) signal channel protocol <xref target="RFC9132" format="default" sectionFormat="of" derivedContent="RFC9132"/> is
      used to carry information about a network resource or a network (or a
      part thereof) that is under a DDoS attack. Such information is sent by a
      DOTS client to one or multiple DOTS servers so that appropriate
      mitigation actions are undertaken on traffic deemed suspicious. Various
      use cases are discussed in <xref target="RFC8903" format="default" sectionFormat="of" derivedContent="RFC8903"/>.</t>
      <t indent="0" pn="section-1-6">DOTS clients can be integrated within a DDoS attack detector or
      within network and security elements that have been actively engaged with
      ongoing attacks. The DOTS client mitigation environment determines that
      it is no longer possible or practical for it to handle these attacks
      itself. This can be due to a lack of resources or security capabilities,
      as derived from the complexities and intensity of these attacks. In
      this circumstance, the DOTS client has invaluable knowledge about the
      actual attacks that need to be handled by its DOTS server(s). By
      enabling the DOTS client to share this comprehensive knowledge of an
      ongoing attack under specific circumstances, the DOTS server can
      drastically increase its ability to accomplish successful mitigation.
      While the attack is being handled by the mitigation resources associated
      with the DOTS server, the DOTS server has knowledge about the ongoing
      attack mitigation. The DOTS server can share this information with the
      DOTS client so that the client can better assess and evaluate the actual
      mitigation realized.</t>
      <t indent="0" pn="section-1-7">DOTS clients can send mitigation hints derived from attack details to
      DOTS servers, with the full understanding that a DOTS server may
      ignore mitigation hints, as described in <xref target="RFC8612" format="default" sectionFormat="of" derivedContent="RFC8612"/>
      (Gen-004). Mitigation hints will be transmitted across the DOTS signal
      channel, as the data channel may not be functional during an attack. How
      a DOTS server handles normal and attack traffic attributes, and
      mitigation hints, is implementation specific.</t>
      <t indent="0" pn="section-1-8">Both DOTS clients and servers can benefit from this information by
      presenting various information details in relevant management, reporting, and
      portal systems.</t>
      <t indent="0" pn="section-1-9">This document defines DOTS telemetry attributes that can be conveyed
      by DOTS clients to DOTS servers, and vice versa. The DOTS telemetry
      attributes are not mandatory attributes of the DOTS signal channel
      protocol <xref target="RFC9132" format="default" sectionFormat="of" derivedContent="RFC9132"/>. When no limitation policy is
      provided to a DOTS agent, it can signal available telemetry attributes
      to its peers in order to optimize the overall mitigation service
      provisioned using DOTS. The aforementioned policy can be, for example,
      agreed upon during a service subscription (which is out of scope for this document) to identify
      a subset of DOTS clients among those deployed in a DOTS client domain
      that are allowed to send or receive telemetry data.</t>
      <t indent="0" pn="section-1-10"><xref target="data" format="default" sectionFormat="of" derivedContent="Section 11.2"/> of this document specifies a YANG module that augments the DOTS data channel <xref target="RFC8783" format="default" sectionFormat="of" derivedContent="RFC8783"/> with information related to attack details. Sharing such
      details during 'idle' time is meant to optimize the data exchanged over
      the DOTS signal channel.</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">The reader should be familiar with the terms defined in <xref target="RFC8612" format="default" sectionFormat="of" derivedContent="RFC8612"/>.</t>
      <t indent="0" pn="section-2-3">"DOTS telemetry" is defined as the collection of attributes that are
      used to characterize the normal traffic baseline, attacks and their
      mitigation measures, and any related information that may help in
      enforcing countermeasures. "DOTS telemetry" is an optional set of
      attributes that can be signaled in the DOTS signal channel protocol.</t>
      <t indent="0" pn="section-2-4">The Telemetry Setup Identifier (tsid) is an identifier that is generated
      by DOTS clients to uniquely identify DOTS telemetry setup configuration
      data. See <xref target="PUT" format="default" sectionFormat="of" derivedContent="Section 7.1.2"/> for more details.</t>
      <t indent="0" pn="section-2-5">The Telemetry Identifier (tmid) is an identifier that is generated by
      DOTS clients to uniquely identify DOTS telemetry data that is
      communicated prior to or during a mitigation. See <xref target="preCtoS" format="default" sectionFormat="of" derivedContent="Section 8.2"/> for more details.</t>
      <t indent="0" pn="section-2-6">"Overlapped" lower numeric 'tsid' (or 'tmid') refers to the lower 'tsid' (or 'tmid') value of two overlapping telemetry requests.</t>
      <t indent="0" pn="section-2-7">The term "pipe" represents the maximum level of traffic that the DOTS
      client domain can receive. Whether a "pipe" is mapped to one or a group
      of network interfaces is deployment specific. For example, each
      interconnection link may be considered as a specific pipe if the DOTS
      server is hosted by each upstream provider, while the aggregate of all
      links to connect to upstream network providers can be considered by a
      DOTS client domain as a single pipe when communicating with a DOTS
      server not hosted by these upstream providers.</t>
      <t indent="0" pn="section-2-8">This document uses IANA-assigned Enterprise Numbers. These numbers are
      also known as "Private Enterprise Numbers" and "SMI (Structure of
      Management Information) Network Management Private Enterprise Codes"
      <xref target="Private-Enterprise-Numbers" format="default" sectionFormat="of" derivedContent="Private-Enterprise-Numbers"/>.</t>
      <t indent="0" pn="section-2-9">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>
      <t indent="0" pn="section-2-10">Consistent with the convention set in <xref target="RFC8783" sectionFormat="of" section="2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8783#section-2" derivedContent="RFC8783"/>, the examples in <xref target="vam" format="default" sectionFormat="of" derivedContent="Section 8.1.6"/> use
      "/restconf" as the discovered RESTCONF API root path. Within these
      examples, some protocol header lines are split into multiple lines for
      display purposes only. When a line ends with a backslash ("\") as the last
      character, the line is wrapped for display purposes. It is considered to
      be joined to the next line by deleting the backslash, the following line
      break, and the leading whitespace of the next line.</t>
    </section>
    <section anchor="overview" numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-dots-telemetry-overview-and">DOTS Telemetry: Overview and Purpose</name>
      <t indent="0" pn="section-3-1">Timely and effective signaling of up-to-date DDoS telemetry to all
      elements involved in the mitigation process is essential and improves
      the overall DDoS mitigation service's effectiveness. Bidirectional
      feedback between DOTS agents is required for increased awareness by each
      party of the attack and mitigation efforts, supporting a superior and
      highly efficient attack mitigation service.</t>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-3.1">
        <name slugifiedName="name-need-for-more-visibility">Need for More Visibility</name>
        <t indent="0" pn="section-3.1-1">When signaling a mitigation request, it is most certainly
        beneficial for DOTS clients to signal to DOTS servers any knowledge
        regarding ongoing attacks. This can happen in cases where DOTS clients
        are asking DOTS servers for support in defending against attacks that
        they have already detected and/or (partially) mitigated.</t>
        <t indent="0" pn="section-3.1-2">If attacks are already detected and categorized within a DOTS
        client domain, the DOTS server, and its associated mitigation
        services, can proactively benefit from this information and optimize
        the overall service delivery. It is important to note that DOTS client
        domains' and DOTS server domains' detection and mitigation approaches
        can be different and can potentially result in different results and
        attack classifications. The DDoS mitigation service treats the ongoing
        attack details received from DOTS clients as hints and cannot
        completely rely on or trust the attack details conveyed by DOTS
        clients.</t>
        <t indent="0" pn="section-3.1-3">In addition to the DOTS server directly using telemetry data as
        operational hints, the DOTS server's security operation team also
        benefits from telemetry data. A basic requirement of security
        operation teams is to be aware of and get visibility into the attacks
        they need to handle. This holds especially for the case of ongoing
        attacks, where DOTS telemetry provides data about the current attack
        status. Even if some mitigation can be automated, operational teams
        can use the DOTS telemetry information to be prepared for attack
        mitigation and to assign the correct resources (e.g., operation staff,
        networking resources, mitigation resources) for the specific service. Similarly,
        security operations personnel at the DOTS client side ask for feedback
        about their requests for protection. Therefore, it is valuable for
        DOTS servers to share DOTS telemetry with DOTS clients.</t>
        <t indent="0" pn="section-3.1-4">Mutual sharing of information is thus crucial for "closing the
        mitigation loop" between DOTS clients and servers. For the server-side
        team, it is important to confirm that the same attacks that the DOTS
        server's mitigation resources are seeing are those for which a DOTS client
        is requesting mitigation. For the DOTS client-side team, it is
        important to realize that the DOTS clients receive the required
        service -- for example, understanding that "I asked for mitigation of
        two attacks, and my DOTS server detects and mitigates only one of
        them." Cases of inconsistency in attack classification between DOTS
        clients and servers can be highlighted, and maybe handled, using the
        DOTS telemetry attributes.</t>
        <t indent="0" pn="section-3.1-5">In addition, management and orchestration systems, at both the DOTS
        client and server sides, can use DOTS telemetry as feedback to
        automate various control and management activities derived from
        signaled telemetry information.</t>
        <t indent="0" pn="section-3.1-6">If the DOTS server's mitigation resources have the capabilities to
        facilitate the DOTS telemetry, the DOTS server adapts its protection
        strategy and activates the required countermeasures immediately
        (automation enabled) for the sake of optimized attack mitigation
        decisions and actions. Discussion regarding the interface from the DOTS server to the
        mitigator to signal the telemetry data is out of scope for this document.</t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-3.2">
        <name slugifiedName="name-enhanced-detection">Enhanced Detection</name>
        <t indent="0" pn="section-3.2-1">DOTS telemetry can also be used as input for determining what
        values to use for the tuning parameters available on the mitigation
        resources. During the last few years, DDoS attack detection
        technologies have evolved from threshold-based detection (that is,
        cases when all or specific parts of traffic cross a predefined
        threshold for a certain period of time is considered as an attack) to
        an "anomaly detection" approach. For the latter, it is required to
        maintain rigorous learning of "normal" behavior, and an "anomaly" (or
        an attack) is identified and categorized based on the knowledge about
        the normal behavior and a deviation from this normal behavior.
        Statistical and artificial intelligence algorithms (e.g., machine
        learning) are used such that the actual traffic thresholds are
        automatically calculated by learning the protected entity's normal
        traffic behavior during 'idle' time (i.e., no mitigation is active).
        The normal traffic characterization learned is referred to as the
        "normal traffic baseline". An attack is detected when the victim's
        actual traffic is deviating from this normal baseline pattern.</t>
        <t indent="0" pn="section-3.2-2">In addition, subsequent activities toward mitigating an attack are
        much more challenging. The ability to distinguish legitimate traffic
        from attacker traffic on a per-packet basis is complex. For example, a
        packet may look "legitimate" and no attack signature can be
        identified. The anomaly can be identified only after detailed
        statistical analysis. DDoS attack mitigators use the normal baseline
        during the mitigation of an attack to identify and categorize the
        expected appearance of a specific traffic pattern. Particularly, the
        mitigators use the normal baseline to recognize the "level of
        normality" that needs to be achieved during the various mitigation
        processes.</t>
        <t indent="0" pn="section-3.2-3">Normal baseline calculation is performed based on continuous
        learning of the normal behavior of the protected entities. The minimum
        learning period varies from hours to days and even weeks, depending on
        the protected applications' behavior. The baseline cannot be learned
        during active attacks because attack conditions do not characterize
        the protected entities' normal behavior.</t>
        <t indent="0" pn="section-3.2-4">If the DOTS client has calculated the normal baseline of its
        protected entities, signaling such information to the DOTS server
        along with the attack traffic levels provides value. The DOTS server
        benefits from this telemetry by tuning its mitigation resources with
        the DOTS client's normal baseline. The DOTS server's mitigators use the
        baseline to familiarize themselves with the attack victim's normal
        behavior and target the baseline as the level of normality they need
        to achieve. Fed with this information, the overall mitigation
        performance is expected to be improved in terms of time to mitigate,
        accuracy, and false-negative and false-positive rates.</t>
        <t indent="0" pn="section-3.2-5">Mitigation of attacks without having certain knowledge of normal
        traffic can be inaccurate at best. This is especially true for
        recursive signaling (see <xref target="RFC8811" sectionFormat="of" section="3.2.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8811#section-3.2.3" derivedContent="RFC8811"/>). Given that DOTS clients can be integrated
        in a highly diverse set of scenarios and use cases, this emphasizes
        the need for knowledge of the behavior of each DOTS client domain -- especially
        given that common global thresholds for attack detection can almost never
        be realized. Each DOTS client domain can have its own levels of
        traffic and normal behavior. Without facilitating normal baseline
        signaling, it may be very difficult for DOTS servers in some cases to
        detect and mitigate the attacks accurately:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.2-6">
          <li pn="section-3.2-6.1">It is important to emphasize that it is practically impossible
            for the DOTS server's mitigators to calculate the normal baseline
            in cases where they do not have any knowledge of the traffic
            beforehand.</li>
        </ul>
        <t indent="0" pn="section-3.2-7">Of course, this information can be provided using out-of-band
        mechanisms or manual configuration, at the risk of unmaintained
        information becoming inaccurate as the network evolves and "normal"
        patterns change. The use of a dynamic and collaborative means between
        the DOTS client and server to identify and share key parameters for
        the sake of efficient DDoS protection is valuable.</t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-3.3">
        <name slugifiedName="name-efficient-mitigation">Efficient Mitigation</name>
        <t indent="0" pn="section-3.3-1">During a high-volume attack, DOTS client pipes can be totally
        saturated. DOTS clients ask their DOTS servers to handle the attack
        upstream so that DOTS client pipes return to a reasonable load level
        (normal pattern, ideally). At this point, it is essential to ensure
        that the mitigator does not overwhelm the DOTS client pipes by sending
        back large volumes of "clean traffic", or what it believes is "clean".
        This can happen when the mitigator has not managed to detect and
        mitigate all the attacks launched toward the DOTS client domain.</t>
        <t indent="0" pn="section-3.3-2">In this case, it can be valuable to DOTS clients to signal to DOTS
        servers the total pipe capacity, which is the level of traffic the
        DOTS client domain can absorb from its upstream network. This is usually
        the circuit size, which includes all the packet overheads. Dynamic
        updates of the condition of pipes between DOTS agents while they are
        under a DDoS attack are essential (e.g., where multiple DOTS clients
        share the same physical connectivity pipes). The DOTS server should
        activate other mechanisms to ensure that it does not allow the DOTS client
        domain's pipes to be saturated unintentionally. The rate-limit action
        defined in <xref target="RFC8783" format="default" sectionFormat="of" derivedContent="RFC8783"/> is a reasonable candidate to
        achieve this objective; the DOTS client can indicate the type(s) of
        traffic (such as ICMP, UDP, TCP port number 80) it prefers to limit.
        The rate-limit action can be controlled via the signal channel <xref target="RFC9133" format="default" sectionFormat="of" derivedContent="RFC9133"/> even when the pipe is overwhelmed.</t>
      </section>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-design-overview">Design Overview</name>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-4.1">
        <name slugifiedName="name-overview-of-telemetry-opera">Overview of Telemetry Operations</name>
        <t indent="0" pn="section-4.1-1">The DOTS protocol suite is divided into two logical channels: the
        signal channel <xref target="RFC9132" format="default" sectionFormat="of" derivedContent="RFC9132"/> and data channel <xref target="RFC8783" format="default" sectionFormat="of" derivedContent="RFC8783"/>. This division is due to the vastly different
        requirements placed upon the traffic they carry. The DOTS signal
        channel must remain available and usable even in the face of attack
        traffic that might, for example, saturate one direction of the links
        involved, rendering acknowledgment-based mechanisms unreliable and
        strongly incentivizing messages to be small enough to be contained in
        a single IP packet (<xref target="RFC8612" sectionFormat="of" section="2.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8612#section-2.2" derivedContent="RFC8612"/>). In
        contrast, the DOTS data channel is available for high-bandwidth data
        transfer before or after an attack, using more conventional transport
        protocol techniques (<xref target="RFC8612" sectionFormat="of" section="2.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8612#section-2.3" derivedContent="RFC8612"/>).
        It is generally preferable to perform advance configuration over the
        DOTS data channel, including configuring aliases for static or nearly
        static data sets such as sets of network addresses/prefixes that might
        be subject to related attacks. This design helps to optimize the use
        of the DOTS signal channel for the small messages that are important
        to deliver during an attack. As a reminder, the DOTS signal channel and data
        channel both require secure communication channels (<xref target="RFC9132" sectionFormat="of" section="11" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9132#section-11" derivedContent="RFC9132"/> and <xref target="RFC8783" sectionFormat="of" section="10" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8783#section-10" derivedContent="RFC8783"/>).</t>
        <t indent="0" pn="section-4.1-2">Telemetry information has aspects that correspond to both
        operational modes (i.e., signal channel and data channel): there is certainly
        a need to convey updated information about ongoing attack traffic and
        targets during an attack, so as to convey detailed information about
        mitigation status and inform updates to mitigation strategy in the
        face of adaptive attacks. However, it is also useful to provide
        mitigation services with a picture of normal or "baseline" traffic
        toward potential targets to aid in detecting when incoming traffic
        deviates from normal into being an attack. Also, one might populate a
        "database" of classifications of known types of attacks so that a short
        attack identifier can be used during an attack period to describe an
        observed attack. This specification does make provision for use of the
        DOTS data channel for the latter function (<xref target="vam" format="default" sectionFormat="of" derivedContent="Section 8.1.6"/>) but otherwise retains most telemetry
        functionality in the DOTS signal channel.</t>
        <t indent="0" pn="section-4.1-3">Note that it is a functional requirement to convey information
        about ongoing attack traffic during an attack, and information about
        baseline traffic uses an essentially identical data structure that is
        naturally defined to sit next to the description of attack traffic.
        The related telemetry setup information used to parameterize actual
        traffic data is also sent over the signal channel, out of
        expediency.</t>
        <t indent="0" pn="section-4.1-4">This document specifies an extension to the DOTS signal channel
        protocol. Considerations about how to establish, maintain, and make
        use of the DOTS signal channel are specified in <xref target="RFC9132" format="default" sectionFormat="of" derivedContent="RFC9132"/>.</t>
        <t indent="0" pn="section-4.1-5">Once the DOTS signal channel is established, DOTS clients that
        support the DOTS telemetry extension proceed with the telemetry setup
        configuration (e.g., measurement interval, telemetry notification
        interval, pipe capacity, normal traffic baseline) as detailed in <xref target="conf" format="default" sectionFormat="of" derivedContent="Section 7"/>. DOTS agents can then include DOTS telemetry
        attributes using the DOTS signal channel (<xref target="pre" format="default" sectionFormat="of" derivedContent="Section 8.1"/>).
        A DOTS client can use separate messages to share with its DOTS
        server(s) a set of telemetry data bound to an ongoing mitigation
        (<xref target="preCtoS" format="default" sectionFormat="of" derivedContent="Section 8.2"/>). Also, a DOTS client that is
        interested in receiving telemetry notifications related to some of its
        resources follows the procedure defined in <xref target="preStoC" format="default" sectionFormat="of" derivedContent="Section 8.3"/>. A DOTS client that receives such notifications can then decide to
   send a mitigation request if an attack cannot be mitigated locally
   within the DOTS client domain.</t>
        <t indent="0" pn="section-4.1-6">Aggregate DOTS telemetry data can also be included in efficacy
        update (<xref target="effu-S" format="default" sectionFormat="of" derivedContent="Section 9.1"/>) or mitigation update (<xref target="premStoC" format="default" sectionFormat="of" derivedContent="Section 9.2"/>) messages.</t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-4.2">
        <name slugifiedName="name-block-wise-transfers">Block-Wise Transfers</name>
        <t indent="0" pn="section-4.2-1">DOTS clients can use a block-wise transfer <xref target="RFC7959" format="default" sectionFormat="of" derivedContent="RFC7959"/> with the recommendation detailed in <xref target="RFC9132" sectionFormat="of" section="4.4.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9132#section-4.4.2" derivedContent="RFC9132"/> to control the size of a
        response when the data to be returned does not fit within a single
        datagram.</t>
        <t indent="0" pn="section-4.2-2">DOTS clients can also use the Constrained Application Protocol (CoAP) Block1 Option in a PUT request
        (<xref target="RFC7959" sectionFormat="of" section="2.5" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7959#section-2.5" derivedContent="RFC7959"/>) to initiate large
        transfers, but these Block1 transfers are likely to fail if the
        inbound "pipe" is running full because the transfer requires a message
        from the server for each block, which would likely be lost in the
        incoming flood. Consideration needs to be made to try to fit this PUT
        into a single transfer or to separate out the PUT into several
        discrete PUTs where each of them fits into a single packet.</t>
        <t indent="0" pn="section-4.2-3">Q-Block1 and Q-Block2 Options that are similar to the CoAP Block1
        and Block2 Options, but enable robust transmissions of big blocks of
        data with less packet interchanges using NON messages, are defined in
        <xref target="RFC9177" format="default" sectionFormat="of" derivedContent="RFC9177"/>. DOTS implementations
        can consider the use of Q-Block1 and Q-Block2 Options <xref target="I-D.ietf-dots-robust-blocks" format="default" sectionFormat="of" derivedContent="DOTS-Robust-Blocks"/>.</t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-4.3">
        <name slugifiedName="name-dots-multihoming-considerat">DOTS Multihoming Considerations</name>
        <t indent="0" pn="section-4.3-1">Considerations for multihomed DOTS clients to select which DOTS
        server to contact and which IP prefixes to include in a telemetry
        message to a given peer DOTS server are discussed in <xref target="I-D.ietf-dots-multihoming" format="default" sectionFormat="of" derivedContent="DOTS-Multihoming"/>. For example, if each
        upstream network exposes a DOTS server and the DOTS client maintains
        DOTS channels with all of them, only the information related to
        prefixes assigned by an upstream network to the DOTS client domain
        will be signaled via the DOTS channel established with the DOTS server
        of that upstream network.</t>
        <t indent="0" pn="section-4.3-2">Considerations related to whether (and how) a DOTS client gleans
        some telemetry information (e.g., attack details) it receives from a
        first DOTS server and shares it with a second DOTS server are
        implementation and deployment specific.</t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-4.4">
        <name slugifiedName="name-yang-considerations">YANG Considerations</name>
        <t indent="0" pn="section-4.4-1">Telemetry messages exchanged between DOTS agents are serialized
        using Concise Binary Object Representation (CBOR) <xref target="RFC8949" format="default" sectionFormat="of" derivedContent="RFC8949"/>. CBOR-encoded payloads are used to carry
        signal-channel-specific payload messages that convey request
        parameters and response information such as errors.</t>
        <t indent="0" pn="section-4.4-2">This document specifies a YANG module <xref target="RFC7950" format="default" sectionFormat="of" derivedContent="RFC7950"/> for representing DOTS telemetry message types
        (<xref target="module" format="default" sectionFormat="of" derivedContent="Section 11.1"/>). All parameters in the payload of the
        DOTS signal channel are mapped to CBOR types as specified in <xref target="map1" format="default" sectionFormat="of" derivedContent="Section 12"/>. As a reminder, <xref target="RFC9132" sectionFormat="of" section="3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9132#section-3" derivedContent="RFC9132"/> defines the rules for mapping YANG-modeled
        data to CBOR.</t>
        <t indent="0" pn="section-4.4-3">The DOTS telemetry module (<xref target="module" format="default" sectionFormat="of" derivedContent="Section 11.1"/>) is not
        intended to be used via the Network Configuration Protocol (NETCONF) / RESTCONF for DOTS server management
        purposes. It serves only to provide a data model and encoding
        following <xref target="RFC8791" format="default" sectionFormat="of" derivedContent="RFC8791"/>. Server deviations (<xref target="RFC7950" sectionFormat="of" section="5.6.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7950#section-5.6.3" derivedContent="RFC7950"/>) are strongly discouraged, as
        the peer DOTS agent does not have the means to retrieve the list of
        deviations and thus interoperability issues are likely to be
        encountered.</t>
        <t indent="0" pn="section-4.4-4">The DOTS telemetry module (<xref target="module" format="default" sectionFormat="of" derivedContent="Section 11.1"/>) uses
        "enumerations" rather than "identities" to define units, samples, and
        intervals because otherwise the namespace identifier
        "ietf-dots-telemetry" must be included when a telemetry attribute is
        included (e.g., in a mitigation efficacy update). The use of
        "identities" is thus suboptimal from the standpoint of message compactness, 
        as message compactness is one of the key requirements for DOTS signal channel messages.</t>
        <t indent="0" pn="section-4.4-5">The DOTS telemetry module (<xref target="module" format="default" sectionFormat="of" derivedContent="Section 11.1"/>) includes
        some lists for which no "key" statement is included. This behavior is
        compliant with <xref target="RFC8791" format="default" sectionFormat="of" derivedContent="RFC8791"/>. The reason for not
        including these keys is that they are not included in the message
        body of DOTS requests; such keys are included as mandatory Uri-Paths
        in requests (Sections <xref format="counter" target="conf" sectionFormat="of" derivedContent="7"/> and
        <xref format="counter" target="pre-t" sectionFormat="of" derivedContent="8"/>). Otherwise, whenever a
        "key" statement is used in the module, the same definition as the definition provided in <xref target="RFC7950" sectionFormat="of" section="7.8.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7950#section-7.8.2" derivedContent="RFC7950"/> is assumed.</t>
        <t indent="0" pn="section-4.4-6">Some parameters (e.g., low-percentile values) may be associated
        with different YANG types (e.g., decimal64 and yang:gauge64). To
        easily distinguish the types of these parameters while using
        meaningful names, the following suffixes are used:</t>
        <table anchor="tab-1" align="center" pn="table-1">
          <name slugifiedName="name-suffixes-and-yang-types">Suffixes and YANG Types</name>
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Suffix</th>
              <th align="left" colspan="1" rowspan="1">YANG Type</th>
              <th align="left" colspan="1" rowspan="1">Example</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">-g</td>
              <td align="left" colspan="1" rowspan="1">yang:gauge64</td>
              <td align="left" colspan="1" rowspan="1">low-percentile-g</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">-c</td>
              <td align="left" colspan="1" rowspan="1">container</td>
              <td align="left" colspan="1" rowspan="1">connection-c</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">-ps</td>
              <td align="left" colspan="1" rowspan="1">per second</td>
              <td align="left" colspan="1" rowspan="1">connection-ps</td>
            </tr>
          </tbody>
        </table>
        <t indent="0" pn="section-4.4-8">The full tree diagram of the DOTS telemetry module can be generated
        using the "pyang" tool <xref target="PYANG" format="default" sectionFormat="of" derivedContent="PYANG"/>. That tree is not
        included here because it is too long (<xref target="RFC8340" sectionFormat="of" section="3.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8340#section-3.3" derivedContent="RFC8340"/>). Instead, subtrees are provided for the
        reader's convenience.</t>
        <t indent="0" pn="section-4.4-9">In order to optimize the data exchanged over the DOTS signal
        channel, this document specifies a second YANG module
        ("ietf-dots-mapping"; see <xref target="data" format="default" sectionFormat="of" derivedContent="Section 11.2"/>) that augments the
        DOTS data channel <xref target="RFC8783" format="default" sectionFormat="of" derivedContent="RFC8783"/>. This augmentation
        can be used during 'idle' time to share the attack mapping details
        (<xref target="attackdetails" format="default" sectionFormat="of" derivedContent="Section 8.1.5"/>). DOTS clients can use tools,
        e.g., the YANG Library <xref target="RFC8525" format="default" sectionFormat="of" derivedContent="RFC8525"/>, to retrieve the
        list of features and deviations supported by the DOTS server over the
        data channel.</t>
      </section>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-generic-considerations">Generic Considerations</name>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-5.1">
        <name slugifiedName="name-dots-client-identification">DOTS Client Identification</name>
        <t indent="0" pn="section-5.1-1">Following the rules in <xref target="RFC9132" sectionFormat="of" section="4.4.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9132#section-4.4.1" derivedContent="RFC9132"/>, a unique identifier is generated by a DOTS
        client to prevent request collisions ('cuid').</t>
        <t indent="0" pn="section-5.1-2">As a reminder, <xref target="RFC9132" sectionFormat="of" section="4.4.1.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9132#section-4.4.1.3" derivedContent="RFC9132"/>
 forbids 'cuid' to be returned in a response message body.</t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-5.2">
        <name slugifiedName="name-dots-gateways">DOTS Gateways</name>
        <t indent="0" pn="section-5.2-1">DOTS gateways may be located between DOTS clients and servers. The
        considerations elaborated in <xref target="RFC9132" sectionFormat="of" section="4.4.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9132#section-4.4.1" derivedContent="RFC9132"/> must be followed. In particular, the 'cdid'
        attribute is used to unambiguously identify a DOTS client domain.</t>
        <t indent="0" pn="section-5.2-2">As a reminder, <xref target="RFC9132" sectionFormat="of" section="4.4.1.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9132#section-4.4.1.3" derivedContent="RFC9132"/>
        forbids 'cdid' (if present) to be returned in a response message
        body.</t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-5.3">
        <name slugifiedName="name-uri-path-parameters-and-emp">Uri-Path Parameters and Empty Values</name>
        <t indent="0" pn="section-5.3-1">Uri-Path parameters and attributes with empty values <bcp14>MUST NOT</bcp14> be
        present in a request. The presence of such an empty value renders the
        entire containing message invalid.</t>
      </section>
      <section anchor="control" numbered="true" toc="include" removeInRFC="false" pn="section-5.4">
        <name slugifiedName="name-controlling-configuration-d">Controlling Configuration Data</name>
        <t indent="0" pn="section-5.4-1">The DOTS server follows the same considerations discussed in
        <xref target="RFC9132" sectionFormat="of" section="4.5.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9132#section-4.5.3" derivedContent="RFC9132"/> for managing DOTS
        telemetry configuration freshness and notifications.</t>
        <t indent="0" pn="section-5.4-2">Likewise, a DOTS client may control the selection of configuration
        and non-configuration data nodes when sending a GET request by means
        of the 'c' (content) Uri-Query option and following the procedure specified in
        <xref target="RFC9132" sectionFormat="of" section="4.4.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9132#section-4.4.2" derivedContent="RFC9132"/>. These
        considerations are not reiterated in the following sections.</t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-5.5">
        <name slugifiedName="name-message-validation">Message Validation</name>
        <t indent="0" pn="section-5.5-1">The authoritative references for validating telemetry messages
        exchanged over the DOTS signal channel are Sections <xref format="counter" target="conf" sectionFormat="of" derivedContent="7"/>, <xref format="counter" target="pre-t" sectionFormat="of" derivedContent="8"/>, and <xref format="counter" target="status" sectionFormat="of" derivedContent="9"/> together with the mapping table provided in
        <xref target="map1" format="default" sectionFormat="of" derivedContent="Section 12"/>. The structure of telemetry message bodies
        is represented as a YANG data structure (<xref target="module" format="default" sectionFormat="of" derivedContent="Section 11.1"/>).</t>
      </section>
      <section anchor="note-examples" numbered="true" toc="include" removeInRFC="false" pn="section-5.6">
        <name slugifiedName="name-a-note-about-examples">A Note about Examples</name>
        <t indent="0" pn="section-5.6-1">Examples are provided for illustration purposes. This document does
        not aim to provide a comprehensive list of message examples.</t>
        <t indent="0" pn="section-5.6-2">JSON encoding of YANG-modeled data is used to illustrate the
        various telemetry operations. To ease readability, parameter names and
        their JSON types are thus used in the examples rather than their
        CBOR key values and CBOR types following the mappings in <xref target="map1" format="default" sectionFormat="of" derivedContent="Section 12"/>. These conventions are inherited from <xref target="RFC9132" format="default" sectionFormat="of" derivedContent="RFC9132"/>.</t>
        <t indent="0" pn="section-5.6-3">The examples use Enterprise Number 32473, which is defined for
        documentation use; see <xref target="RFC5612" format="default" sectionFormat="of" derivedContent="RFC5612"/>.</t>
      </section>
    </section>
    <section anchor="tel-op-paths" numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-telemetry-operation-paths">Telemetry Operation Paths</name>
      <t indent="0" pn="section-6-1">As discussed in <xref target="RFC9132" sectionFormat="of" section="4.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9132#section-4.2" derivedContent="RFC9132"/>, each
      DOTS operation is indicated by a path suffix that indicates the intended
      operation. The operation path is appended to the path prefix to form the
      URI used with a CoAP request to perform the desired DOTS operation. The
      following telemetry path suffixes are defined (<xref target="tab-2" format="default" sectionFormat="of" derivedContent="Table 2"/>):</t>
      <table anchor="tab-2" align="center" pn="table-2">
        <name slugifiedName="name-dots-telemetry-operations">DOTS Telemetry Operations</name>
        <thead>
          <tr>
            <th align="left" colspan="1" rowspan="1">Operation</th>
            <th align="left" colspan="1" rowspan="1">Operation Path</th>
            <th align="left" colspan="1" rowspan="1">Details</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left" colspan="1" rowspan="1">Telemetry Setup</td>
            <td align="left" colspan="1" rowspan="1">/tm-setup</td>
            <td align="left" colspan="1" rowspan="1">
              <xref target="conf" format="default" sectionFormat="of" derivedContent="Section 7"/></td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">Telemetry</td>
            <td align="left" colspan="1" rowspan="1">/tm</td>
            <td align="left" colspan="1" rowspan="1">
              <xref target="pre-t" format="default" sectionFormat="of" derivedContent="Section 8"/></td>
          </tr>
        </tbody>
      </table>
      <t indent="0" pn="section-6-3">Consequently, the "ietf-dots-telemetry" YANG module defined in <xref target="module" format="default" sectionFormat="of" derivedContent="Section 11.1"/> defines a data structure to represent new DOTS
      message types called 'telemetry-setup' and 'telemetry'. The tree
      structure is shown in <xref target="abstract-basic" format="default" sectionFormat="of" derivedContent="Figure 1"/>. More details are
      provided in Sections <xref format="counter" target="conf" sectionFormat="of" derivedContent="7"/> and
      <xref format="counter" target="pre-t" sectionFormat="of" derivedContent="8"/> about the exact structure
      of 'telemetry-setup' and 'telemetry' message types.</t>
      <figure anchor="abstract-basic" align="left" suppress-title="false" pn="figure-1">
        <name slugifiedName="name-new-dots-message-types-yang">New DOTS Message Types (YANG Tree Structure)</name>
        <sourcecode name="" type="yangtree" markers="false" pn="section-6-4.1">  structure dots-telemetry:
    +-- (telemetry-message-type)?
       +--:(telemetry-setup)
       |  ...
       |  +-- telemetry* []
       |     ...
       |     +-- (setup-type)?
       |        +--:(telemetry-config)
       |        |  ...
       |        +--:(pipe)
       |        |  ...
       |        +--:(baseline)
       |           ...
       +--:(telemetry)
          ...
</sourcecode>
      </figure>
      <t indent="0" pn="section-6-5">DOTS implementations <bcp14>MUST</bcp14> support the Observe Option <xref target="RFC7641" format="default" sectionFormat="of" derivedContent="RFC7641"/> for 'tm' (<xref target="pre-t" format="default" sectionFormat="of" derivedContent="Section 8"/>).</t>
    </section>
    <section anchor="conf" numbered="true" toc="include" removeInRFC="false" pn="section-7">
      <name slugifiedName="name-dots-telemetry-setup-config">DOTS Telemetry Setup Configuration</name>
      <t indent="0" pn="section-7-1">In reference to <xref target="abstract-basic" format="default" sectionFormat="of" derivedContent="Figure 1"/>, a DOTS telemetry
      setup message <bcp14>MUST</bcp14> include only telemetry-related configuration
      parameters (<xref target="tconfig" format="default" sectionFormat="of" derivedContent="Section 7.1"/>), information about DOTS
      client domain pipe capacity (<xref target="tpipe" format="default" sectionFormat="of" derivedContent="Section 7.2"/>), or information about the telemetry
      traffic baseline (<xref target="tbl" format="default" sectionFormat="of" derivedContent="Section 7.3"/>). As such, requests that
      include a mix of telemetry configuration, pipe capacity, and traffic
      baseline information <bcp14>MUST</bcp14> be rejected by DOTS servers with a 4.00 (Bad Request) Response Code.</t>
      <t indent="0" pn="section-7-2">A DOTS client can reset all installed DOTS telemetry setup
      configuration data following the considerations detailed in <xref target="reseta" format="default" sectionFormat="of" derivedContent="Section 7.4"/>.</t>
      <t indent="0" pn="section-7-3">A DOTS server may detect conflicts when processing requests related
      to DOTS client domain pipe capacity or telemetry traffic baseline information with
      requests from other DOTS clients of the same DOTS client domain. More
      details are included in <xref target="conflict" format="default" sectionFormat="of" derivedContent="Section 7.5"/>.</t>
      <t indent="0" pn="section-7-4">Telemetry setup configuration is bound to a DOTS client domain. DOTS
      servers <bcp14>MUST NOT</bcp14> expect DOTS clients to send regular requests to refresh
      the telemetry setup configuration. Any available telemetry setup
      configuration is valid until the DOTS server ceases to service a DOTS
      client domain. DOTS servers <bcp14>MUST NOT</bcp14> reset 'tsid' because a session
      failed with a DOTS client. DOTS clients update their telemetry setup
      configuration upon change of a parameter that may impact attack
      mitigation.</t>
      <t indent="0" pn="section-7-5">DOTS telemetry setup configuration request and response messages are
      marked as Confirmable messages (<xref target="RFC7252" sectionFormat="of" section="2.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7252#section-2.1" derivedContent="RFC7252"/>).</t>
      <section anchor="tconfig" numbered="true" toc="include" removeInRFC="false" pn="section-7.1">
        <name slugifiedName="name-telemetry-configuration">Telemetry Configuration</name>
        <t indent="0" pn="section-7.1-1">DOTS telemetry uses several percentile values to provide a picture
        of a traffic distribution overall, as opposed to just a single
        snapshot of observed traffic at a single point in time. Modeling raw
        traffic flow data as a distribution and describing that distribution
        entails choosing a measurement period that the distribution will
        describe, and a number of sampling intervals, or "buckets", within
        that measurement period. Traffic within each bucket is treated as a
        single event (i.e., averaged), and then the distribution of buckets is
        used to describe the distribution of traffic over the measurement
        period. A distribution can be characterized by statistical measures
        (e.g., mean, median, and standard deviation) and also by reporting
        the value of the distribution at various percentile levels of the data
        set in question (e.g., "quartiles" that correspond to 25th, 50th, and
        75th percentiles). More details about percentile values and their
        computation are found in <xref target="RFC2330" sectionFormat="of" section="11.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc2330#section-11.3" derivedContent="RFC2330"/>.</t>
        <t indent="0" pn="section-7.1-2">DOTS telemetry uses up to three percentile values, plus the overall
        peak, to characterize traffic distributions. Which percentile
        thresholds are used for these "low-percentile", "mid-percentile", and "high-percentile"
        values is configurable. Default values are defined in <xref target="PUT" format="default" sectionFormat="of" derivedContent="Section 7.1.2"/>.</t>
        <t indent="0" pn="section-7.1-3">A DOTS client can negotiate with its server(s) a set of telemetry
        configuration parameters to be used for telemetry. Such parameters
        include:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-7.1-4">
          <li pn="section-7.1-4.1">Percentile-related measurement parameters. In particular,
            'measurement-interval' defines the period during which percentiles are
            computed, while 'measurement-sample' defines the time distribution
            for measuring values that are used to compute percentiles.</li>
          <li pn="section-7.1-4.2">Measurement units.</li>
          <li pn="section-7.1-4.3">Acceptable percentile values.</li>
          <li pn="section-7.1-4.4">Telemetry notification interval.</li>
          <li pn="section-7.1-4.5">Acceptable server-originated telemetry.</li>
        </ul>
        <section anchor="acc" numbered="true" toc="include" removeInRFC="false" pn="section-7.1.1">
          <name slugifiedName="name-retrieving-the-current-dots">Retrieving the Current DOTS Telemetry Configuration</name>
          <t indent="0" pn="section-7.1.1-1">A GET request is used to obtain acceptable and current telemetry
          configuration parameters on the DOTS server. This request may
          include a 'cdid' Uri-Path when the request is relayed by a DOTS
          gateway. An example of such a GET request (without a gateway) is
          depicted in <xref target="GETa" format="default" sectionFormat="of" derivedContent="Figure 2"/>.</t>
          <figure anchor="GETa" align="left" suppress-title="false" pn="figure-2">
            <name slugifiedName="name-get-to-retrieve-the-current">GET to Retrieve the Current and Acceptable DOTS Telemetry Configuration</name>
            <sourcecode name="" type="json" markers="false" pn="section-7.1.1-2.1">Header: GET (Code=0.01)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "tm-setup"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
</sourcecode>
          </figure>
          <t indent="0" pn="section-7.1.1-3">Upon receipt of such a request, and assuming that no error is
          encountered when processing the request, the DOTS server replies
          with a 2.05 (Content) response that conveys the telemetry parameters
          that are acceptable to the DOTS server, any pipe information (<xref target="tpipe" format="default" sectionFormat="of" derivedContent="Section 7.2"/>), and the current baseline information (<xref target="tbl" format="default" sectionFormat="of" derivedContent="Section 7.3"/>) maintained by the DOTS server for this DOTS
          client. The tree structure of the response message body is provided
          in <xref target="tree-acceptable" format="default" sectionFormat="of" derivedContent="Figure 3"/>.</t>
          <t indent="0" pn="section-7.1.1-4">DOTS servers that support the capability of sending telemetry
          information to DOTS clients prior to or during a mitigation (<xref target="premStoC" format="default" sectionFormat="of" derivedContent="Section 9.2"/>) set 'server-originated-telemetry' under
          'max-config-values' to 'true' ('false' is used otherwise). If
          'server-originated-telemetry' is not present in a response, this is
          equivalent to receiving a response with
          'server-originated-telemetry' set to 'false'.</t>
          <figure anchor="tree-acceptable" align="left" suppress-title="false" pn="figure-3">
            <name slugifiedName="name-telemetry-configuration-tre">Telemetry Configuration Tree Structure</name>
            <sourcecode name="" type="yangtree" markers="false" pn="section-7.1.1-5.1">  structure dots-telemetry:
    +-- (telemetry-message-type)?
       +--:(telemetry-setup)
       |  +-- (direction)?
       |  |  +--:(server-to-client-only)
       |  |     +-- max-config-values
       |  |     |  +-- measurement-interval?          interval
       |  |     |  +-- measurement-sample?            sample
       |  |     |  +-- low-percentile?                percentile
       |  |     |  +-- mid-percentile?                percentile
       |  |     |  +-- high-percentile?               percentile
       |  |     |  +-- server-originated-telemetry?   boolean
       |  |     |  +-- telemetry-notify-interval?     uint16
       |  |     +-- min-config-values
       |  |     |  +-- measurement-interval?        interval
       |  |     |  +-- measurement-sample?          sample
       |  |     |  +-- low-percentile?              percentile
       |  |     |  +-- mid-percentile?              percentile
       |  |     |  +-- high-percentile?             percentile
       |  |     |  +-- telemetry-notify-interval?   uint16
       |  |     +-- supported-unit-classes
       |  |     |  +-- unit-config* [unit]
       |  |     |     +-- unit           unit-class
       |  |     |     +-- unit-status    boolean
       |  |     +-- supported-query-type*  query-type
       |  +-- telemetry* []
       |     +-- (direction)?
       |     |  +--:(server-to-client-only)
       |     |     +-- tsid?                  uint32
       |     +-- (setup-type)?
       |        +--:(telemetry-config)
       |        |  +-- current-config
       |        |     +-- measurement-interval?          interval
       |        |     +-- measurement-sample?            sample
       |        |     +-- low-percentile?                percentile
       |        |     +-- mid-percentile?                percentile
       |        |     +-- high-percentile?               percentile
       |        |     +-- unit-config* [unit]
       |        |     |  +-- unit           unit-class
       |        |     |  +-- unit-status    boolean
       |        |     +-- server-originated-telemetry?   boolean
       |        |     +-- telemetry-notify-interval?     uint16
       |        +--:(pipe)
       |        |  ...
       |        +--:(baseline)
       |           ...
       +--:(telemetry)
          ...
</sourcecode>
          </figure>
          <t indent="0" pn="section-7.1.1-6">When both 'min-config-values' and 'max-config-values' attributes
          are present, the values carried in 'max-config-values' attributes
          <bcp14>MUST</bcp14> be greater than or equal to their counterparts in 'min-config-values'
          attributes.</t>
        </section>
        <section anchor="PUT" numbered="true" toc="include" removeInRFC="false" pn="section-7.1.2">
          <name slugifiedName="name-conveying-the-dots-telemetr">Conveying the DOTS Telemetry Configuration</name>
          <t indent="0" pn="section-7.1.2-1">A PUT request is used to convey the configuration parameters for
          the telemetry data (e.g., low-, mid-, or high-percentile values). For
          example, a DOTS client may contact its DOTS server to change the
          default percentile values used as the baseline for telemetry data. <xref target="tree-acceptable" format="default" sectionFormat="of" derivedContent="Figure 3"/> lists the attributes that can be
          set by a DOTS client in such a PUT request. An example of a DOTS
          client that modifies all percentile reference values is shown in
          <xref target="tput" format="default" sectionFormat="of" derivedContent="Figure 4"/>. </t>
          <aside pn="section-7.1.2-2">
            <t indent="0" pn="section-7.1.2-2.1">
              Note: The payload of the message depicted in <xref target="tput" format="default" sectionFormat="of" derivedContent="Figure 4"/> is CBOR-encoded as indicated by setting the
              Content-Format entry to "application/dots+cbor" (<xref target="RFC9132" sectionFormat="of" section="10.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9132#section-10.3" derivedContent="RFC9132"/>). However, and for the sake of
              better readability, the example (and other similar figures
              depicting a DOTS telemetry message body) follows the conventions
              set in <xref target="note-examples" format="default" sectionFormat="of" derivedContent="Section 5.6"/>: use the JSON names
              and types defined in <xref target="map1" format="default" sectionFormat="of" derivedContent="Section 12"/>.
            </t>
          </aside>
          <figure anchor="tput" align="left" suppress-title="false" pn="figure-4">
            <name slugifiedName="name-put-to-convey-the-dots-tele">PUT to Convey the DOTS Telemetry Configuration, Depicted as per Section 5.6</name>
            <sourcecode name="" type="json" markers="false" pn="section-7.1.2-3.1">Header: PUT (Code=0.03)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "tm-setup"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "tsid=123"
Content-Format: "application/dots+cbor"

{
  "ietf-dots-telemetry:telemetry-setup": {
    "telemetry": [
      {
        "current-config": {
          "low-percentile": "5.00",
          "mid-percentile": "65.00",
          "high-percentile": "95.00"
        }
      }
    ]
  }
}
</sourcecode>
          </figure>
          <t indent="0" pn="section-7.1.2-4">'cuid' is a mandatory Uri-Path parameter for PUT requests.</t>
          <t indent="0" pn="section-7.1.2-5">The following additional Uri-Path parameter is defined: </t>
          <dl newline="false" spacing="normal" indent="3" pn="section-7.1.2-6">
            <dt pn="section-7.1.2-6.1">tsid:</dt>
            <dd pn="section-7.1.2-6.2">
              <t indent="0" pn="section-7.1.2-6.2.1">The Telemetry Setup Identifier is an identifier
              for the DOTS telemetry setup configuration data represented as
              an integer. This identifier <bcp14>MUST</bcp14> be generated by DOTS clients.
              'tsid' values <bcp14>MUST</bcp14> increase monotonically whenever new
              configuration parameters (not just for changed values) need to
              be conveyed by the DOTS client. </t>
              <t indent="0" pn="section-7.1.2-6.2.2">The
              procedure specified in <xref target="RFC9132" sectionFormat="of" section="4.4.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9132#section-4.4.1" derivedContent="RFC9132"/> for 'mid' rollover <bcp14>MUST</bcp14> also be
              followed for 'tsid' rollover.</t>
              <t indent="0" pn="section-7.1.2-6.2.3">This is a
              mandatory attribute.  'tsid' <bcp14>MUST</bcp14> appear after 'cuid' in the
              Uri-Path options.</t>
            </dd>
          </dl>
          <t indent="0" pn="section-7.1.2-7">'cuid' and 'tsid' <bcp14>MUST NOT</bcp14> appear in the PUT request message
          body.</t>
          <t indent="0" pn="section-7.1.2-8">At least one configurable attribute <bcp14>MUST</bcp14> be present in the PUT
          request.</t>
          <t indent="0" pn="section-7.1.2-9">A PUT request with a higher numeric 'tsid' value overrides the
          DOTS telemetry configuration data installed by a PUT request with a
          lower numeric 'tsid' value. To avoid maintaining a long list of
          'tsid' requests for requests carrying telemetry configuration data
          from a DOTS client, the lower numeric 'tsid' <bcp14>MUST</bcp14> be automatically
          deleted and no longer be available at the DOTS server.</t>
          <t indent="0" pn="section-7.1.2-10">The DOTS server indicates the result of processing the PUT
          request using the following Response Codes:</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-7.1.2-11">
            <li pn="section-7.1.2-11.1">If the request is missing a mandatory attribute, does not
              include 'cuid' or 'tsid' Uri-Path parameters, or contains one or
              more invalid or unknown parameters, a 4.00 (Bad Request) Response Code <bcp14>MUST</bcp14> be
              returned in the response.</li>
            <li pn="section-7.1.2-11.2">If the DOTS server does not find the 'tsid' parameter value
              conveyed in the PUT request in its configuration data and if the
              DOTS server has accepted the configuration parameters, then a
              2.01 (Created) Response Code <bcp14>MUST</bcp14> be returned in the
              response.</li>
            <li pn="section-7.1.2-11.3">If the DOTS server finds the 'tsid' parameter value conveyed
              in the PUT request in its configuration data and if the DOTS
              server has accepted the updated configuration parameters, a 2.04
              (Changed) Response Code <bcp14>MUST</bcp14> be returned in the response.</li>
            <li pn="section-7.1.2-11.4">
              <t indent="0" pn="section-7.1.2-11.4.1">If any of the enclosed configurable attribute values are not
              acceptable to the DOTS server (<xref target="acc" format="default" sectionFormat="of" derivedContent="Section 7.1.1"/>), a 4.22
              (Unprocessable Entity) Response Code <bcp14>MUST</bcp14> be returned in the response. </t>
              <t indent="0" pn="section-7.1.2-11.4.2">The DOTS client may retry and send the PUT
              request with updated attribute values acceptable to the DOTS
              server.</t>
            </li>
          </ul>
          <t indent="0" pn="section-7.1.2-12">By default, low-percentile (10th percentile), mid-percentile
          (50th percentile), high-percentile (90th percentile), and peak
          (100th percentile) values are used to represent telemetry data.
          Nevertheless, a DOTS client can disable some percentile types (low,
          mid, high). In particular, setting 'low-percentile' to "0.00"
          indicates that the DOTS client is not interested in receiving
          low-percentiles. Likewise, setting 'mid-percentile' (or
          'high-percentile') to the same value as 'low-percentile' (or
          'mid-percentile') indicates that the DOTS client is not interested
          in receiving mid-percentiles (or high-percentiles). For example, a
          DOTS client can send the request depicted in <xref target="tput1" format="default" sectionFormat="of" derivedContent="Figure 5"/> to inform the server that it is interested in
          receiving only high-percentiles. This assumes that the client will
          only use that percentile type when sharing telemetry data with the
          server.</t>
          <figure anchor="tput1" align="left" suppress-title="false" pn="figure-5">
            <name slugifiedName="name-put-to-disable-low-and-mid-">PUT to Disable Low- and Mid-Percentiles, Depicted as per Section 5.6</name>
            <sourcecode name="" type="json" markers="false" pn="section-7.1.2-13.1">Header: PUT (Code=0.03)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "tm-setup"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "tsid=124"
Content-Format: "application/dots+cbor"

{
  "ietf-dots-telemetry:telemetry-setup": {
    "telemetry": [
      {
        "current-config": {
          "low-percentile": "0.00",
          "mid-percentile": "0.00",
          "high-percentile": "95.00"
        }
      }
    ]
  }
}
</sourcecode>
          </figure>
          <t indent="0" pn="section-7.1.2-14">DOTS clients can also configure the unit class(es) to be used for
          traffic-related telemetry data among the following supported unit
          classes: packets per second, bits per second, and bytes per second.
          Supplying both bits per second and bytes per second unit classes is
          allowed for a given set of telemetry data. However, receipt of conflicting
          values is treated as invalid parameters and rejected with a 4.00 (Bad
          Request) Response Code.</t>
          <t indent="0" pn="section-7.1.2-15">DOTS clients that are interested in receiving pre-or-ongoing-
          mitigation telemetry ('pre-or-ongoing-mitigation') information from a
          DOTS server (<xref target="premStoC" format="default" sectionFormat="of" derivedContent="Section 9.2"/>) <bcp14>MUST</bcp14> set
          'server-originated-telemetry' to 'true'. If
          'server-originated-telemetry' is not present in a PUT request, this
          is equivalent to receiving a request with
          'server-originated-telemetry' set to 'false'. An example of a
          request to enable pre-or-ongoing-mitigation telemetry from DOTS
          servers is shown in <xref target="tput2" format="default" sectionFormat="of" derivedContent="Figure 6"/>.</t>
          <figure anchor="tput2" align="left" suppress-title="false" pn="figure-6">
            <name slugifiedName="name-put-to-enable-pre-or-ongoin">PUT to Enable Pre-or-Ongoing-Mitigation Telemetry from the DOTS Server, Depicted as per Section 5.6</name>
            <sourcecode name="" type="json" markers="false" pn="section-7.1.2-16.1">Header: PUT (Code=0.03)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "tm-setup"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "tsid=125"
Content-Format: "application/dots+cbor"

{
  "ietf-dots-telemetry:telemetry-setup": {
    "telemetry": [
      {
        "current-config": {
          "server-originated-telemetry": true
        }
      }
    ]
  }
}
</sourcecode>
          </figure>
        </section>
        <section anchor="GET" numbered="true" toc="include" removeInRFC="false" pn="section-7.1.3">
          <name slugifiedName="name-retrieving-the-installed-do">Retrieving the Installed DOTS Telemetry Configuration</name>
          <t indent="0" pn="section-7.1.3-1">A DOTS client may issue a GET message with a 'tsid' Uri-Path
          parameter to retrieve the current DOTS telemetry configuration. An
          example of such a request is depicted in <xref target="GETs" format="default" sectionFormat="of" derivedContent="Figure 7"/>.</t>
          <figure anchor="GETs" align="left" suppress-title="false" pn="figure-7">
            <name slugifiedName="name-get-to-retrieve-the-current-">GET to Retrieve the Current DOTS Telemetry Configuration</name>
            <sourcecode name="" type="json" markers="false" pn="section-7.1.3-2.1">Header: GET (Code=0.01)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "tm-setup"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "tsid=123"
</sourcecode>
          </figure>
          <t indent="0" pn="section-7.1.3-3">If the DOTS server does not find the 'tsid' Uri-Path value
          conveyed in the GET request in its configuration data for the
          requesting DOTS client, it <bcp14>MUST</bcp14> respond with a 4.04 (Not Found)
          error Response Code.</t>
        </section>
        <section anchor="DEL" numbered="true" toc="include" removeInRFC="false" pn="section-7.1.4">
          <name slugifiedName="name-deleting-the-dots-telemetry">Deleting the DOTS Telemetry Configuration</name>
          <t indent="0" pn="section-7.1.4-1">A DELETE request is used to delete the installed DOTS telemetry
          configuration data (<xref target="cdelete" format="default" sectionFormat="of" derivedContent="Figure 8"/>).  'cuid' and
          'tsid' are mandatory Uri-Path parameters for such DELETE
          requests.</t>
          <figure anchor="cdelete" align="left" suppress-title="false" pn="figure-8">
            <name slugifiedName="name-deleting-the-telemetry-conf">Deleting the Telemetry Configuration</name>
            <sourcecode name="" type="json" markers="false" pn="section-7.1.4-2.1">Header: DELETE (Code=0.04)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "tm-setup"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "tsid=123"
</sourcecode>
          </figure>
          <t indent="0" pn="section-7.1.4-3">The DOTS server resets the DOTS telemetry configuration back to
          the default values and acknowledges a DOTS client's request to
          remove the DOTS telemetry configuration using a 2.02 (Deleted)
          Response Code. A 2.02 (Deleted) Response Code is returned even if
          the 'tsid' parameter value conveyed in the DELETE request does not
          exist in its configuration data before the request.</t>
          <t indent="0" pn="section-7.1.4-4"><xref target="reseta" format="default" sectionFormat="of" derivedContent="Section 7.4"/> discusses the procedure to reset
          all DOTS telemetry setup configuration data.</t>
        </section>
      </section>
      <section anchor="tpipe" numbered="true" toc="include" removeInRFC="false" pn="section-7.2">
        <name slugifiedName="name-total-pipe-capacity">Total Pipe Capacity</name>
        <t indent="0" pn="section-7.2-1">A DOTS client can communicate to the DOTS server(s) its DOTS client
        domain pipe information. The tree structure of the pipe information is
        shown in <xref target="ptree" format="default" sectionFormat="of" derivedContent="Figure 9"/>.</t>
        <figure anchor="ptree" align="left" suppress-title="false" pn="figure-9">
          <name slugifiedName="name-pipe-tree-structure">Pipe Tree Structure</name>
          <sourcecode name="" type="yangtree" markers="false" pn="section-7.2-2.1">  structure dots-telemetry:
    +-- (telemetry-message-type)?
       +--:(telemetry-setup)
       |  ...
       |  +-- telemetry* []
       |     +-- (direction)?
       |     |  +--:(server-to-client-only)
       |     |     +-- tsid?                  uint32
       |     +-- (setup-type)?
       |        +--:(telemetry-config)
       |        |  ...
       |        +--:(pipe)
       |        |  +-- total-pipe-capacity* [link-id unit]
       |        |     +-- link-id     nt:link-id
       |        |     +-- capacity    uint64
       |        |     +-- unit        unit
       |        +--:(baseline)
       |           ...
       +--:(telemetry)
          ...
</sourcecode>
        </figure>
        <t indent="0" pn="section-7.2-3">A DOTS client domain pipe is defined as a list of limits on
        (incoming) traffic volume ('total-pipe-capacity') that can be
        forwarded over ingress interconnection links of a DOTS client domain.
        Each of these links is identified with a 'link-id' <xref target="RFC8345" format="default" sectionFormat="of" derivedContent="RFC8345"/>.</t>
        <t indent="0" pn="section-7.2-4">The unit used by a DOTS client when conveying pipe information is
        captured in the 'unit' attribute. The DOTS client <bcp14>MUST</bcp14> auto-scale so
        that the appropriate unit is used. That is, for a given unit class,
        the DOTS client uses the largest unit that gives a value greater than
        one. As such, only one unit per unit class is allowed.</t>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-7.2.1">
          <name slugifiedName="name-conveying-dots-client-domai">Conveying DOTS Client Domain Pipe Capacity</name>
          <t indent="0" pn="section-7.2.1-1">Considerations similar to those specified in <xref target="PUT" format="default" sectionFormat="of" derivedContent="Section 7.1.2"/> are followed, with one exception:</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-7.2.1-2">
            <li pn="section-7.2.1-2.1">The relative order of two PUT requests carrying DOTS client
              domain pipe attributes from a DOTS client is determined by
              comparing their respective 'tsid' values. If these two requests
              have overlapping 'link-id' and 'unit' settings, the PUT request with a
              higher numeric 'tsid' value will override the request with a
              lower numeric 'tsid' value. The overlapped lower numeric 'tsid'
              <bcp14>MUST</bcp14> be automatically deleted and no longer be available.</li>
          </ul>
          <t indent="0" pn="section-7.2.1-3">DOTS clients <bcp14>SHOULD</bcp14> minimize the number of active 'tsid's used
          for pipe information. In order to avoid maintaining a long list of
          'tsid's for pipe information, it is <bcp14>RECOMMENDED</bcp14> that DOTS clients
          include in any request to update information related to a given link
          the information regarding other links (already communicated using a lower
          'tsid' value). By doing so, this update request will override these
          existing requests and hence optimize the number of 'tsid' requests
          per DOTS client. </t>
          <aside pn="section-7.2.1-4">
            <t indent="0" pn="section-7.2.1-4.1">
              Note: This assumes that all link information can fit in one
              single message.
            </t>
          </aside>
          <t indent="0" pn="section-7.2.1-5">As an example of configuring pipe information, a DOTS client
          managing a single-homed domain (<xref target="single" format="default" sectionFormat="of" derivedContent="Figure 10"/>) can
          send a PUT request (shown in <xref target="putp1" format="default" sectionFormat="of" derivedContent="Figure 11"/>) to
          communicate the capacity of "link1" used to connect to its ISP.</t>
          <figure anchor="single" align="left" suppress-title="false" pn="figure-10">
            <name slugifiedName="name-single-homed-dots-client-do">Single-Homed DOTS Client Domain</name>
            <artwork name="" type="" align="left" alt="" pn="section-7.2.1-6.1">                      ,--,--,--.             ,--,--,--.
                   ,-'          `-.       ,-'          `-.
                  (  DOTS Client   )=====(     ISP#A      )
                   `-.  Domain  ,-' link1 `-.          ,-'
                      `--'--'--'             `--'--'--'
</artwork>
          </figure>
          <figure anchor="putp1" align="left" suppress-title="false" pn="figure-11">
            <name slugifiedName="name-example-of-a-put-request-to">Example of a PUT Request to Convey Pipe Information (Single-Homed), Depicted as per Section 5.6</name>
            <sourcecode name="" type="json" markers="false" pn="section-7.2.1-7.1">Header: PUT (Code=0.03)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "tm-setup"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "tsid=126"
Content-Format: "application/dots+cbor"

{
  "ietf-dots-telemetry:telemetry-setup": {
    "telemetry": [
      {
        "total-pipe-capacity": [
          {
            "link-id": "link1",
            "capacity": "500",
            "unit": "megabit-ps"
          }
        ]
      }
    ]
  }
}
</sourcecode>
          </figure>
          <t indent="0" pn="section-7.2.1-8">DOTS clients may be instructed to signal a link aggregate instead
          of individual links. For example, a DOTS client that manages a DOTS
          client domain having two interconnection links with an upstream ISP
          (<xref target="singleagg" format="default" sectionFormat="of" derivedContent="Figure 12"/>) can send a PUT request (shown in
          <xref target="putp1a" format="default" sectionFormat="of" derivedContent="Figure 13"/>) to communicate the aggregate link
          capacity with its ISP. Signaling individual or aggregate link
          capacity is deployment specific.</t>
          <figure anchor="singleagg" align="left" suppress-title="false" pn="figure-12">
            <name slugifiedName="name-dots-client-domain-with-two">DOTS Client Domain with Two Interconnection Links</name>
            <artwork name="" type="" align="left" alt="" pn="section-7.2.1-9.1">                      ,--,--,--.             ,--,--,--.
                   ,-'          `-.===== ,-'          `-.
                  (  DOTS Client   )    (     ISP#C      )
                   `-.  Domain  ,-'====== `-.          ,-'
                      `--'--'--'             `--'--'--'
</artwork>
          </figure>
          <figure anchor="putp1a" align="left" suppress-title="false" pn="figure-13">
            <name slugifiedName="name-example-of-a-put-request-to-">Example of a PUT Request to Convey Pipe Information (Aggregated Link), Depicted as per Section 5.6</name>
            <sourcecode name="" type="json" markers="false" pn="section-7.2.1-10.1">Header: PUT (Code=0.03)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "tm-setup"
Uri-Path: "cuid=hmcpH87lmPGsSTjkhXCbin"
Uri-Path: "tsid=896"
Content-Format: "application/dots+cbor"

{
  "ietf-dots-telemetry:telemetry-setup": {
    "telemetry": [
      {
        "total-pipe-capacity": [
          {
            "link-id": "aggregate",
            "capacity": "700",
            "unit": "megabit-ps"
          }
        ]
      }
    ]
  }
}
</sourcecode>
          </figure>
          <t indent="0" pn="section-7.2.1-11">Now consider that the DOTS client domain was upgraded to connect
          to an additional ISP (e.g., ISP#B in <xref target="multi" format="default" sectionFormat="of" derivedContent="Figure 14"/>);
          the DOTS client can inform a DOTS server that is not hosted with
          ISP#A and ISP#B domains about this update by sending the PUT request
          depicted in <xref target="putp2" format="default" sectionFormat="of" derivedContent="Figure 15"/>. This request also includes
          information related to "link1" even if that link is not upgraded.
          Upon receipt of this request, the DOTS server removes the request
          with 'tsid=126' and updates its configuration base to maintain two
          links (link1 and link2).</t>
          <figure anchor="multi" align="left" suppress-title="false" pn="figure-14">
            <name slugifiedName="name-multihomed-dots-client-doma">Multihomed DOTS Client Domain</name>
            <artwork name="" type="" align="left" alt="" pn="section-7.2.1-12.1">                     ,--,--,--.     
                   ,-'          `-. 
                  (     ISP#B      )
                   `-.          ,-' 
                      `--'--'--'    
                          ||
                          || link2                          
                     ,--,--,--.             ,--,--,--.
                   ,-'          `-.       ,-'          `-.
                  (  DOTS Client   )=====(     ISP#A      )
                   `-.  Domain  ,-' link1 `-.          ,-'
                      `--'--'--'             `--'--'--'
</artwork>
          </figure>
          <figure anchor="putp2" align="left" suppress-title="false" pn="figure-15">
            <name slugifiedName="name-example-of-a-put-request-to-c">Example of a PUT Request to Convey Pipe Information (Multihomed), Depicted as per Section 5.6</name>
            <sourcecode name="" type="json" markers="false" pn="section-7.2.1-13.1">Header: PUT (Code=0.03)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "tm-setup"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "tsid=127"
Content-Format: "application/dots+cbor"

{
  "ietf-dots-telemetry:telemetry-setup": {
    "telemetry": [
      {
        "total-pipe-capacity": [
          {
            "link-id": "link1",
            "capacity": "500",
            "unit": "megabit-ps"
          },
          {
            "link-id": "link2",
            "capacity": "500",
            "unit": "megabit-ps"
          }
        ]
      }
    ]
  }
}
</sourcecode>
          </figure>
          <t indent="0" pn="section-7.2.1-14">A DOTS client can delete a link by sending a PUT request with the
          'capacity' attribute set to "0" if other links are still active for
          the same DOTS client domain. For example, if a DOTS client domain re-homes
          (that is, it changes its ISP), the DOTS client can inform its DOTS
          server about this update (e.g., from the network configuration in
          <xref target="single" format="default" sectionFormat="of" derivedContent="Figure 10"/> to the network configuration shown in <xref target="single2" format="default" sectionFormat="of" derivedContent="Figure 16"/>) by sending the PUT request depicted in
          <xref target="putp3" format="default" sectionFormat="of" derivedContent="Figure 17"/>. Upon receipt of this request, and
          assuming that no error is encountered when processing the request, the
          DOTS server removes "link1" from its configuration bases for this
          DOTS client domain. Note that if the DOTS server receives a PUT
          request with a 'capacity' attribute set to "0" for all included
          links, it <bcp14>MUST</bcp14> reject the request with a 4.00 (Bad Request) Response Code.
          Instead, the DOTS client can use a DELETE request to delete all
          links (<xref target="pdel" format="default" sectionFormat="of" derivedContent="Section 7.2.3"/>).</t>
          <figure anchor="single2" align="left" suppress-title="false" pn="figure-16">
            <name slugifiedName="name-multihomed-dots-client-domai">Multihomed DOTS Client Domain</name>
            <artwork name="" type="" align="left" alt="" pn="section-7.2.1-15.1">                     ,--,--,--.     
                   ,-'          `-. 
                  (     ISP#B      )
                   `-.          ,-' 
                      `--'--'--'    
                          ||
                          || link2                          
                     ,--,--,--.     
                   ,-'          `-. 
                  (  DOTS Client   )
                   `-.  Domain  ,-' 
                      `--'--'--'
</artwork>
          </figure>
          <figure anchor="putp3" align="left" suppress-title="false" pn="figure-17">
            <name slugifiedName="name-example-of-a-put-request-to-co">Example of a PUT Request to Convey Pipe Information (Multihomed), Depicted as per Section 5.6</name>
            <sourcecode name="" type="json" markers="false" pn="section-7.2.1-16.1">Header: PUT (Code=0.03)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "tm-setup"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "tsid=128"
Content-Format: "application/dots+cbor"

{
  "ietf-dots-telemetry:telemetry-setup": {
    "telemetry": [
      {
        "total-pipe-capacity": [
          {
            "link-id": "link1",
            "capacity": "0",
            "unit": "megabit-ps"
          },
          {
            "link-id": "link2",
            "capacity": "500",
            "unit": "megabit-ps"
          }
        ]
      }
    ]
  }
}
</sourcecode>
          </figure>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-7.2.2">
          <name slugifiedName="name-retrieving-installed-dots-c">Retrieving Installed DOTS Client Domain Pipe Capacity</name>
          <t indent="0" pn="section-7.2.2-1">A GET request with a 'tsid' Uri-Path parameter is used to retrieve the
          specific information related to an installed DOTS client domain pipe.
          The same procedure as that defined in <xref target="GET" format="default" sectionFormat="of" derivedContent="Section 7.1.3"/> is
          followed.</t>
          <t indent="0" pn="section-7.2.2-2">To retrieve all pipe information bound to a DOTS client, the DOTS
          client proceeds as specified in <xref target="acc" format="default" sectionFormat="of" derivedContent="Section 7.1.1"/>.</t>
        </section>
        <section anchor="pdel" numbered="true" toc="include" removeInRFC="false" pn="section-7.2.3">
          <name slugifiedName="name-deleting-installed-dots-cli">Deleting Installed DOTS Client Domain Pipe Capacity</name>
          <t indent="0" pn="section-7.2.3-1">A DELETE request is used to delete the specific information related to an installed DOTS client domain pipe. The same procedure as that defined in
          <xref target="DEL" format="default" sectionFormat="of" derivedContent="Section 7.1.4"/> is followed.</t>
        </section>
      </section>
      <section anchor="tbl" numbered="true" toc="include" removeInRFC="false" pn="section-7.3">
        <name slugifiedName="name-telemetry-baseline">Telemetry Baseline</name>
        <t indent="0" pn="section-7.3-1">A DOTS client can communicate to its DOTS server(s) its normal
        traffic baseline and connection capacity:</t>
        <dl newline="false" spacing="normal" indent="3" pn="section-7.3-2">
          <dt pn="section-7.3-2.1">Total traffic normal baseline:</dt>
          <dd pn="section-7.3-2.2">
            <t indent="0" pn="section-7.3-2.2.1">Total traffic normal baseline data provides the percentile values
            representing the total traffic normal baseline. It can be
            represented for a target using 'total-traffic-normal'.</t>
            <t indent="0" pn="section-7.3-2.2.2">The traffic normal per-protocol
            ('total-traffic-normal-per-protocol') baseline is represented for
            a target and is transport-protocol specific.</t>
            <t indent="0" pn="section-7.3-2.2.3">The traffic normal per-port-number
            ('total-traffic-normal-per-port') baseline is represented for each
            port number bound to a target.</t>
            <t indent="0" pn="section-7.3-2.2.4">If the DOTS
            client negotiated percentile values and units (<xref target="tconfig" format="default" sectionFormat="of" derivedContent="Section 7.1"/>), these negotiated parameters will be
            used instead of the default parameters. For each unit class used, the
            DOTS client <bcp14>MUST</bcp14> auto-scale so that the appropriate unit is
            used.</t>
          </dd>
          <dt pn="section-7.3-2.3">Total connection capacity:</dt>
          <dd pn="section-7.3-2.4">
            <t indent="0" pn="section-7.3-2.4.1">If the target is
            susceptible to resource-consuming DDoS attacks, the following
            optional attributes for the target per transport protocol are
            useful for detecting resource-consuming DDoS attacks:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-7.3-2.4.2">
              <li pn="section-7.3-2.4.2.1">The maximum number of simultaneous connections that are
                allowed to the target.</li>
              <li pn="section-7.3-2.4.2.2">The maximum number of simultaneous connections that are
                allowed to the target per client.</li>
              <li pn="section-7.3-2.4.2.3">The maximum number of simultaneous embryonic connections
                that are allowed to the target. The term "embryonic
                connection" refers to a connection whose connection handshake
                is not finished. Embryonic connections are only possible in
                connection-oriented transport protocols like TCP or the Stream
                Control Transmission Protocol (SCTP) <xref target="RFC9260" format="default" sectionFormat="of" derivedContent="RFC9260"/>.</li>
              <li pn="section-7.3-2.4.2.4">The maximum number of simultaneous embryonic connections
                that are allowed to the target per client.</li>
              <li pn="section-7.3-2.4.2.5">The maximum number of connections allowed per second to the
                target.</li>
              <li pn="section-7.3-2.4.2.6">The maximum number of connections allowed per second to the
                target per client.</li>
              <li pn="section-7.3-2.4.2.7">The maximum number of requests (e.g., HTTP/DNS/SIP
                requests) allowed per second to the target.</li>
              <li pn="section-7.3-2.4.2.8">The maximum number of requests allowed per second to the
                target per client.</li>
              <li pn="section-7.3-2.4.2.9">The maximum number of outstanding partial requests allowed
                to the target. Attacks relying upon partial requests create a
                connection with a target but do not send a complete request
                (e.g., an HTTP request).</li>
              <li pn="section-7.3-2.4.2.10">The maximum number of outstanding partial requests allowed
                to the target per client.</li>
            </ul>
            <t indent="0" pn="section-7.3-2.4.3">The aggregate per transport
            protocol is captured in 'total-connection-capacity', while
            port-specific capabilities are represented using
            'total-connection-capacity-per-port'.</t>
          </dd>
        </dl>
        <t indent="0" pn="section-7.3-3">Note that a target resource is identified using the attributes
        'target-prefix', 'target-port-range', 'target-protocol', 'target-
        fqdn', 'target-uri', or 'alias-name' as defined in <xref target="RFC9132" sectionFormat="of" section="4.4.1.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9132#section-4.4.1.1" derivedContent="RFC9132"/>.</t>
        <t indent="0" pn="section-7.3-4">The tree structure of the normal traffic baseline is shown in <xref target="bltree" format="default" sectionFormat="of" derivedContent="Figure 18"/>.</t>
        <figure anchor="bltree" align="left" suppress-title="false" pn="figure-18">
          <name slugifiedName="name-telemetry-baseline-tree-str">Telemetry Baseline Tree Structure</name>
          <sourcecode name="" type="yangtree" markers="false" pn="section-7.3-5.1">  structure dots-telemetry:
    +-- (telemetry-message-type)?
       +--:(telemetry-setup)
       |  ...
       |  +-- telemetry* []
       |     +-- (direction)?
       |     |  +--:(server-to-client-only)
       |     |     +-- tsid?                  uint32
       |     +-- (setup-type)?
       |        +--:(telemetry-config)
       |        |  ...
       |        +--:(pipe)
       |        |  ...
       |        +--:(baseline)
       |           +-- baseline* [id]
       |              +-- id                     uint32
       |              +-- target-prefix*
       |              |       inet:ip-prefix
       |              +-- target-port-range* [lower-port]
       |              |  +-- lower-port    inet:port-number
       |              |  +-- upper-port?   inet:port-number
       |              +-- target-protocol*                      uint8
       |              +-- target-fqdn*
       |              |       inet:domain-name
       |              +-- target-uri*
       |              |       inet:uri
       |              +-- alias-name*
       |              |       string
       |              +-- total-traffic-normal* [unit]
       |              |  +-- unit                 unit
       |              |  +-- low-percentile-g?    yang:gauge64
       |              |  +-- mid-percentile-g?    yang:gauge64
       |              |  +-- high-percentile-g?   yang:gauge64
       |              |  +-- peak-g?              yang:gauge64
       |              +-- total-traffic-normal-per-protocol*
       |              |       [unit protocol]
       |              |  +-- protocol             uint8
       |              |  +-- unit                 unit
       |              |  +-- low-percentile-g?    yang:gauge64
       |              |  +-- mid-percentile-g?    yang:gauge64
       |              |  +-- high-percentile-g?   yang:gauge64
       |              |  +-- peak-g?              yang:gauge64
       |              +-- total-traffic-normal-per-port* [unit port]
       |              |  +-- port                 inet:port-number
       |              |  +-- unit                 unit
       |              |  +-- low-percentile-g?    yang:gauge64
       |              |  +-- mid-percentile-g?    yang:gauge64
       |              |  +-- high-percentile-g?   yang:gauge64
       |              |  +-- peak-g?              yang:gauge64
       |              +-- total-connection-capacity* [protocol]
       |              |  +-- protocol                     uint8
       |              |  +-- connection?                  uint64
       |              |  +-- connection-client?           uint64
       |              |  +-- embryonic?                   uint64
       |              |  +-- embryonic-client?            uint64
       |              |  +-- connection-ps?               uint64
       |              |  +-- connection-client-ps?        uint64
       |              |  +-- request-ps?                  uint64
       |              |  +-- request-client-ps?           uint64
       |              |  +-- partial-request-max?         uint64
       |              |  +-- partial-request-client-max?  uint64
       |              +-- total-connection-capacity-per-port*
       |                      [protocol port]
       |                 +-- port
       |                 |       inet:port-number
       |                 +-- protocol                     uint8
       |                 +-- connection?                  uint64
       |                 +-- connection-client?           uint64
       |                 +-- embryonic?                   uint64
       |                 +-- embryonic-client?            uint64
       |                 +-- connection-ps?               uint64
       |                 +-- connection-client-ps?        uint64
       |                 +-- request-ps?                  uint64
       |                 +-- request-client-ps?           uint64
       |                 +-- partial-request-max?         uint64
       |                 +-- partial-request-client-max?  uint64
       +--:(telemetry)
          ...
</sourcecode>
        </figure>
        <t indent="0" pn="section-7.3-6">A DOTS client can share one or multiple normal traffic baselines
        (e.g., aggregate or per-prefix baselines); each is uniquely
        identified within the DOTS client domain with an identifier ('id'). This
        identifier can be used to update a baseline entry, delete a specific
        entry, etc.</t>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-7.3.1">
          <name slugifiedName="name-conveying-dots-client-domain">Conveying DOTS Client Domain Baseline Information</name>
          <t indent="0" pn="section-7.3.1-1">Considerations similar to those specified in <xref target="PUT" format="default" sectionFormat="of" derivedContent="Section 7.1.2"/> are followed, with one exception:</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-7.3.1-2">
            <li pn="section-7.3.1-2.1">The relative order of two PUT requests carrying DOTS client
              domain baseline attributes from a DOTS client is determined by
              comparing their respective 'tsid' values. If these two requests
              have overlapping targets, the PUT request with a higher numeric
              'tsid' value will override the request with a lower numeric
              'tsid' value. The overlapped lower numeric 'tsid' <bcp14>MUST</bcp14> be
              automatically deleted and no longer be available.</li>
          </ul>
          <t indent="0" pn="section-7.3.1-3">Two PUT requests from a DOTS client have overlapping targets if
          there is a common IP address, IP prefix, FQDN, URI, or alias name.
          Also, two PUT requests from a DOTS client have overlapping targets
          from the perspective of the DOTS server if the addresses associated
          with the FQDN, URI, or alias are overlapping with each other or with
          'target-prefix'.</t>
          <t indent="0" pn="section-7.3.1-4">DOTS clients <bcp14>SHOULD</bcp14> minimize the number of active 'tsid's used
          for baseline information. In order to avoid maintaining a long list
          of 'tsid's for baseline information, it is <bcp14>RECOMMENDED</bcp14> that DOTS
          clients include in any request to update information related to a
          given target the information regarding other targets (already communicated
          using a lower 'tsid' value) (assuming that this information fits within one single
          datagram). This update request will override these existing requests
          and hence optimize the number of 'tsid' requests per DOTS client.</t>
          <t indent="0" pn="section-7.3.1-5">If no target attribute is included in the request, this is an
          indication that the baseline information applies for the DOTS client
          domain as a whole.</t>
          <t indent="0" pn="section-7.3.1-6">An example of a PUT request to convey the baseline information is
          shown in <xref target="tputs" format="default" sectionFormat="of" derivedContent="Figure 19"/>.</t>
          <figure anchor="tputs" align="left" suppress-title="false" pn="figure-19">
            <name slugifiedName="name-put-to-convey-dots-traffic-">PUT to Convey DOTS Traffic Baseline Information, Depicted as per Section 5.6</name>
            <sourcecode name="" type="json" markers="false" pn="section-7.3.1-7.1">Header: PUT (Code=0.03)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "tm-setup"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "tsid=129"
Content-Format: "application/dots+cbor"

{
  "ietf-dots-telemetry:telemetry-setup": {
    "telemetry": [
      {
        "baseline": [
          {
            "id": 1,
            "target-prefix": [
              "2001:db8:6401::1/128",
              "2001:db8:6401::2/128"
            ],
            "total-traffic-normal": [
              {
                "unit": "megabit-ps",
                "peak-g": "60"
              }
            ]
          }
        ]
      }
    ]
  }
}
</sourcecode>
          </figure>
          <t indent="0" pn="section-7.3.1-8">The DOTS client may share protocol-specific baseline information
          (e.g., TCP and UDP) as shown in <xref target="tputs2" format="default" sectionFormat="of" derivedContent="Figure 20"/>.</t>
          <figure anchor="tputs2" align="left" suppress-title="false" pn="figure-20">
            <name slugifiedName="name-put-to-convey-dots-traffic-b">PUT to Convey DOTS Traffic Baseline Information (2), Depicted as per Section 5.6</name>
            <sourcecode name="" type="json" markers="false" pn="section-7.3.1-9.1">Header: PUT (Code=0.03)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "tm-setup"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "tsid=130"
Content-Format: "application/dots+cbor"

{
  "ietf-dots-telemetry:telemetry-setup": {
    "telemetry": [
      {
        "baseline": [
          {
            "id": 1,
            "target-prefix": [
              "2001:db8:6401::1/128",
              "2001:db8:6401::2/128"
            ],
            "total-traffic-normal-per-protocol": [
              {
                "unit": "megabit-ps",
                "protocol": 6,
                "peak-g": "50"
              },
              {
                "unit": "megabit-ps",
                "protocol": 17,
                "peak-g": "10"
              }
            ]
          }
        ]
      }
    ]
  }
}
</sourcecode>
          </figure>
          <t indent="0" pn="section-7.3.1-10">The normal traffic baseline information should be updated to
          reflect legitimate overloads (e.g., flash crowds) to prevent
          unnecessary mitigation.</t>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-7.3.2">
          <name slugifiedName="name-retrieving-installed-normal">Retrieving Installed Normal Traffic Baseline Information</name>
          <t indent="0" pn="section-7.3.2-1">A GET request with a 'tsid' Uri-Path parameter is used to retrieve
          a specific installed DOTS client domain's baseline traffic
          information. The same procedure as that defined in <xref target="GET" format="default" sectionFormat="of" derivedContent="Section 7.1.3"/> is followed.</t>
          <t indent="0" pn="section-7.3.2-2">To retrieve all baseline information bound to a DOTS client, the
          DOTS client proceeds as specified in <xref target="acc" format="default" sectionFormat="of" derivedContent="Section 7.1.1"/>.</t>
        </section>
        <section anchor="basedel" numbered="true" toc="include" removeInRFC="false" pn="section-7.3.3">
          <name slugifiedName="name-deleting-installed-normal-t">Deleting Installed Normal Traffic Baseline Information</name>
          <t indent="0" pn="section-7.3.3-1">A DELETE request is used to delete the installed DOTS client
          domain's normal traffic baseline information. The same procedure as that defined in
          <xref target="DEL" format="default" sectionFormat="of" derivedContent="Section 7.1.4"/> is followed.</t>
        </section>
      </section>
      <section anchor="reseta" numbered="true" toc="include" removeInRFC="false" pn="section-7.4">
        <name slugifiedName="name-resetting-the-installed-tel">Resetting the Installed Telemetry Setup</name>
        <t indent="0" pn="section-7.4-1">Upon bootstrapping (or reboot or any other event that may alter the
        DOTS client setup), a DOTS client <bcp14>MAY</bcp14> send a DELETE request to set the
        telemetry parameters to default values. Such a request does not
        include any 'tsid' parameters. An example of such a request is depicted in <xref target="bdel" format="default" sectionFormat="of" derivedContent="Figure 21"/>.</t>
        <figure anchor="bdel" align="left" suppress-title="false" pn="figure-21">
          <name slugifiedName="name-deleting-the-telemetry-confi">Deleting the Telemetry Configuration</name>
          <sourcecode name="" type="json" markers="false" pn="section-7.4-2.1">Header: DELETE (Code=0.04)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "tm-setup"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
</sourcecode>
        </figure>
      </section>
      <section anchor="conflict" numbered="true" toc="include" removeInRFC="false" pn="section-7.5">
        <name slugifiedName="name-conflict-with-other-dots-cl">Conflict with Other DOTS Clients of the Same Domain</name>
        <t indent="0" pn="section-7.5-1">A DOTS server may detect conflicts between requests conveying pipe
        and baseline information received from DOTS clients of the same DOTS
        client domain.  'conflict-information' is used to report the conflict
        to the DOTS client, following guidelines for conflict handling similar to those discussed in
        <xref target="RFC9132" sectionFormat="of" section="4.4.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9132#section-4.4.1" derivedContent="RFC9132"/>. The conflict cause
        can be set to one of these values:</t>
        <dl newline="false" spacing="normal" indent="3" pn="section-7.5-2">
          <dt pn="section-7.5-2.1">1:</dt>
          <dd pn="section-7.5-2.2">Overlapping targets (<xref target="RFC9132" sectionFormat="of" section="4.4.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9132#section-4.4.1" derivedContent="RFC9132"/>).</dd>
          <dt pn="section-7.5-2.3">5:</dt>
          <dd pn="section-7.5-2.4">Overlapping pipe scope (see <xref target="IANA" format="default" sectionFormat="of" derivedContent="Section 13"/>).</dd>
        </dl>
      </section>
    </section>
    <section anchor="pre-t" numbered="true" toc="include" removeInRFC="false" pn="section-8">
      <name slugifiedName="name-dots-pre-or-ongoing-mitigat">DOTS Pre-or-Ongoing-Mitigation Telemetry</name>
      <t indent="0" pn="section-8-1">There are two broad types of DDoS attacks: bandwidth-consuming attacks and  target-resource-consuming attacks. This
      section outlines the set of DOTS telemetry attributes (<xref target="pre" format="default" sectionFormat="of" derivedContent="Section 8.1"/>) that covers both types of attacks. The objective of
      these attributes is to allow for the complete knowledge of attacks and
      the various particulars that can best characterize attacks.</t>
      <t indent="0" pn="section-8-2">The "ietf-dots-telemetry" YANG module (<xref target="module" format="default" sectionFormat="of" derivedContent="Section 11.1"/>)
      defines the data structure of a new message type called 'telemetry'. The
      tree structure of the 'telemetry' message type is shown in <xref target="tt" format="default" sectionFormat="of" derivedContent="Figure 22"/>.</t>
      <figure anchor="tt" align="left" suppress-title="false" pn="figure-22">
        <name slugifiedName="name-telemetry-message-type-tree">Telemetry Message Type Tree Structure</name>
        <sourcecode name="" type="yangtree" markers="false" pn="section-8-3.1">  structure dots-telemetry:
    +-- (telemetry-message-type)?
       +--:(telemetry-setup)
       |  ...
       |  +-- telemetry* []
       |     +-- (direction)?
       |     |  +--:(server-to-client-only)
       |     |     +-- tsid?                  uint32
       |     +-- (setup-type)?
       |        +--:(telemetry-config)
       |        |  ...
       |        +--:(pipe)
       |        |  ...
       |        +--:(baseline)
       |           ...
       +--:(telemetry)
          +-- pre-or-ongoing-mitigation* []
             +-- (direction)?
             |  +--:(server-to-client-only)
             |     +-- tmid?                      uint32
             +-- target
             |  ...
             +-- total-traffic* [unit]
             |  ...
             +-- total-traffic-protocol* [unit protocol]
             |  ...
             +-- total-traffic-port* [unit port]
             |  ...
             +-- total-attack-traffic* [unit]
             |  ...
             +-- total-attack-traffic-protocol* [unit protocol]
             |  ...
             +-- total-attack-traffic-port* [unit port]
             |  ...
             +-- total-attack-connection-protocol* [protocol]
             |  ...
             +-- total-attack-connection-port* [protocol port]
             |  ...
             +-- attack-detail* [vendor-id attack-id]
                ...
</sourcecode>
      </figure>
      <t indent="0" pn="section-8-4">The pre-or-ongoing-mitigation telemetry attributes are indicated by
      the path suffix '/tm'.  '/tm' is appended to the path prefix to form
      the URI used with a CoAP request to signal the DOTS telemetry.
      Pre-or-ongoing-mitigation telemetry attributes as specified in <xref target="pre" format="default" sectionFormat="of" derivedContent="Section 8.1"/> can be signaled between DOTS agents.</t>
      <t indent="0" pn="section-8-5">Pre-or-ongoing-mitigation telemetry attributes may be sent by a DOTS
      client or a DOTS server.</t>
      <t indent="0" pn="section-8-6">DOTS agents <bcp14>SHOULD</bcp14> bind pre-or-ongoing-mitigation telemetry data to
      mitigation requests associated with the resources under attack. In
      particular, a telemetry PUT request sent after a mitigation request may
      include a reference to that mitigation request ('mid-list') as shown in
      <xref target="mid-co" format="default" sectionFormat="of" derivedContent="Figure 23"/>. An example illustrating request
      correlation by means of 'target-prefix' is shown in <xref target="mid-co2" format="default" sectionFormat="of" derivedContent="Figure 24"/>.</t>
      <t indent="0" pn="section-8-7">Much of the pre-or-ongoing-mitigation telemetry data uses a unit that
      falls under the unit class that is configured following the procedure
      described in <xref target="PUT" format="default" sectionFormat="of" derivedContent="Section 7.1.2"/>. When generating telemetry data
      to send to a peer, the DOTS agent <bcp14>MUST</bcp14> auto-scale so that one or more appropriate
      units are used.</t>
      <figure anchor="mid-co" align="left" suppress-title="false" pn="figure-23">
        <name slugifiedName="name-example-of-request-correlat">Example of Request Correlation Using 'mid'</name>
        <artwork name="" type="" align="left" alt="" pn="section-8-8.1"> +-----------+                                         +-----------+
 |DOTS client|                                         |DOTS server|
 +-----------+                                         +-----------+
       |                                                     |
       |==============Mitigation Request (mid)==============&gt;|
       |                                                     |
       |==============Telemetry (mid-list{mid})=============&gt;|
       |                                                     |
</artwork>
      </figure>
      <figure anchor="mid-co2" align="left" suppress-title="false" pn="figure-24">
        <name slugifiedName="name-example-of-request-correlati">Example of Request Correlation Using 'target-prefix'</name>
        <artwork name="" type="" align="left" alt="" pn="section-8-9.1"> +-----------+                                         +-----------+
 |DOTS client|                                         |DOTS server|
 +-----------+                                         +-----------+
       |                                                     |
       |&lt;===============Telemetry (target-prefix)============|
       |                                                     |
       |========Mitigation Request (target-prefix)==========&gt;|
       |                                                     |
</artwork>
      </figure>
      <t indent="0" pn="section-8-10">DOTS agents <bcp14>MUST NOT</bcp14> send pre-or-ongoing-mitigation telemetry
      notifications to the same peer more frequently than once every
      'telemetry-notify-interval' (<xref target="tconfig" format="default" sectionFormat="of" derivedContent="Section 7.1"/>). If a
      telemetry notification is sent using a block-like transfer mechanism
      (e.g., <xref target="RFC9177" format="default" sectionFormat="of" derivedContent="RFC9177"/>), this
      rate-limit
      policy <bcp14>MUST NOT</bcp14> consider these individual blocks as separate
      notifications, but as a single notification.</t>
      <t indent="0" pn="section-8-11">DOTS pre-or-ongoing-mitigation telemetry request and response
      messages <bcp14>MUST</bcp14> be marked as Non-confirmable messages (<xref target="RFC7252" sectionFormat="of" section="2.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7252#section-2.1" derivedContent="RFC7252"/>).</t>
      <section anchor="pre" numbered="true" toc="include" removeInRFC="false" pn="section-8.1">
        <name slugifiedName="name-pre-or-ongoing-mitigation-d">Pre-or-Ongoing-Mitigation DOTS Telemetry Attributes</name>
        <t indent="0" pn="section-8.1-1"><xref target="overview" format="default" sectionFormat="of" derivedContent="Section 3"/> discusses the motivation for using the DOTS telemetry attributes. These attributes are specified in the following subsections.</t>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-8.1.1">
          <name slugifiedName="name-target">Target</name>
          <t indent="0" pn="section-8.1.1-1">A target resource (<xref target="targett" format="default" sectionFormat="of" derivedContent="Figure 25"/>) is identified
          using the attributes 'target-prefix', 'target-port-range',
          'target-protocol', 'target-fqdn', 'target-uri', 'alias-name', or a
          pointer to a mitigation request ('mid-list').</t>
          <figure anchor="targett" align="left" suppress-title="false" pn="figure-25">
            <name slugifiedName="name-target-tree-structure">Target Tree Structure</name>
            <sourcecode name="" type="yangtree" markers="false" pn="section-8.1.1-2.1">
       +--:(telemetry)
          +-- pre-or-ongoing-mitigation* []
             +-- (direction)?
             |  +--:(server-to-client-only)
             |     +-- tmid?                      uint32
             +-- target
             |  +-- target-prefix*       inet:ip-prefix
             |  +-- target-port-range* [lower-port]
             |  |  +-- lower-port    inet:port-number
             |  |  +-- upper-port?   inet:port-number
             |  +-- target-protocol*     uint8
             |  +-- target-fqdn*         inet:domain-name
             |  +-- target-uri*          inet:uri
             |  +-- alias-name*          string
             |  +-- mid-list*            uint32
             +-- total-traffic* [unit]
             |  ...
             +-- total-traffic-protocol* [unit protocol]
             |  ...
             +-- total-traffic-port* [unit port]
             |  ...
             +-- total-attack-traffic* [unit]
             |  ...
             +-- total-attack-traffic-protocol* [unit protocol]
             |  ...
             +-- total-attack-traffic-port* [unit port]
             |  ...
             +-- total-attack-connection-protocol* [protocol]
             |  ...
             +-- total-attack-connection-port* [protocol port]
             |  ...
             +-- attack-detail* [vendor-id attack-id]
                ...
</sourcecode>
          </figure>
          <t indent="0" pn="section-8.1.1-3">At least one of the attributes 'target-prefix', 'target-fqdn',
          'target-uri', 'alias-name', or 'mid-list' <bcp14>MUST</bcp14> be present in the
          target definition.</t>
          <t indent="0" pn="section-8.1.1-4">If the target is susceptible to bandwidth-consuming attacks, the
          attributes representing the percentile values of the 'attack-id'
          attack traffic are included.</t>
          <t indent="0" pn="section-8.1.1-5">If the target is susceptible to resource-consuming DDoS attacks,
          the attributes defined in <xref target="attackconn" format="default" sectionFormat="of" derivedContent="Section 8.1.4"/> are
          applicable for representing the attack.</t>
          <t indent="0" pn="section-8.1.1-6">At least the 'target' attribute and one other
          pre-or-ongoing-mitigation attribute <bcp14>MUST</bcp14> be present in the DOTS
          telemetry message.</t>
        </section>
        <section anchor="tot" numbered="true" toc="include" removeInRFC="false" pn="section-8.1.2">
          <name slugifiedName="name-total-traffic">Total Traffic</name>
          <t indent="0" pn="section-8.1.2-1">The 'total-traffic' attribute (<xref target="ttt" format="default" sectionFormat="of" derivedContent="Figure 26"/>)
          conveys the percentile values (including peak and current observed
          values) of the total observed traffic. More fine-grained information
          about the total traffic can be conveyed in the
          'total-traffic-protocol' and 'total-traffic-port' attributes.</t>
          <t indent="0" pn="section-8.1.2-2">The 'total-traffic-protocol' attribute represents the total
          traffic for a target and is transport-protocol specific.</t>
          <t indent="0" pn="section-8.1.2-3">The 'total-traffic-port' attribute represents the total traffic for a
          target per port number.</t>
          <figure anchor="ttt" align="left" suppress-title="false" pn="figure-26">
            <name slugifiedName="name-total-traffic-tree-structur">Total Traffic Tree Structure</name>
            <sourcecode name="" type="yangtree" markers="false" pn="section-8.1.2-4.1">
       +--:(telemetry)
          +-- pre-or-ongoing-mitigation* []
             +-- (direction)?
             |  +--:(server-to-client-only)
             |     +-- tmid?                      uint32
             +-- target
             |  ...
             +-- total-traffic* [unit]
             |  +-- unit                 unit
             |  +-- low-percentile-g?    yang:gauge64
             |  +-- mid-percentile-g?    yang:gauge64
             |  +-- high-percentile-g?   yang:gauge64
             |  +-- peak-g?              yang:gauge64
             |  +-- current-g?           yang:gauge64
             +-- total-traffic-protocol* [unit protocol]
             |  +-- protocol             uint8
             |  +-- unit                 unit
             |  +-- low-percentile-g?    yang:gauge64
             |  +-- mid-percentile-g?    yang:gauge64
             |  +-- high-percentile-g?   yang:gauge64
             |  +-- peak-g?              yang:gauge64
             |  +-- current-g?           yang:gauge64
             +-- total-traffic-port* [unit port]
             |  +-- port                 inet:port-number
             |  +-- unit                 unit
             |  +-- low-percentile-g?    yang:gauge64
             |  +-- mid-percentile-g?    yang:gauge64
             |  +-- high-percentile-g?   yang:gauge64
             |  +-- peak-g?              yang:gauge64
             |  +-- current-g?           yang:gauge64
             +-- total-attack-traffic* [unit]
             |  ...
             +-- total-attack-traffic-protocol* [unit protocol]
             |  ...
             +-- total-attack-traffic-port* [unit port]
             |  ...
             +-- total-attack-connection-protocol* [protocol]
             |  ...
             +-- total-attack-connection-port* [protocol port]
             |  ...
             +-- attack-detail* [vendor-id attack-id]
                ...
</sourcecode>
          </figure>
        </section>
        <section anchor="tat" numbered="true" toc="include" removeInRFC="false" pn="section-8.1.3">
          <name slugifiedName="name-total-attack-traffic">Total Attack Traffic</name>
          <t indent="0" pn="section-8.1.3-1">The 'total-attack-traffic' attribute (<xref target="tatt" format="default" sectionFormat="of" derivedContent="Figure 27"/>) conveys the total observed attack traffic.
          More fine-grained information about the total attack traffic can be
          conveyed in the 'total-attack-traffic-protocol' and
          'total-attack-traffic-port' attributes.</t>
          <t indent="0" pn="section-8.1.3-2">The 'total-attack-traffic-protocol' attribute represents the
          total attack traffic for a target and is transport-protocol
          specific.</t>
          <t indent="0" pn="section-8.1.3-3">The 'total-attack-traffic-port' attribute represents the total
          attack traffic for a target per port number.</t>
          <figure anchor="tatt" align="left" suppress-title="false" pn="figure-27">
            <name slugifiedName="name-total-attack-traffic-tree-s">Total Attack Traffic Tree Structure</name>
            <sourcecode name="" type="yangtree" markers="false" pn="section-8.1.3-4.1">
       +--:(telemetry)
          +-- pre-or-ongoing-mitigation* []
             +-- (direction)?
             |  +--:(server-to-client-only)
             |     +-- tmid?                      uint32
             +-- target
             |  ...
             +-- total-traffic* [unit]
             |  ...
             +-- total-traffic-protocol* [unit protocol]
             |  ...
             +-- total-traffic-port* [unit port]
             |  ...
             +-- total-attack-traffic* [unit]
             |  +-- unit                 unit
             |  +-- low-percentile-g?    yang:gauge64
             |  +-- mid-percentile-g?    yang:gauge64
             |  +-- high-percentile-g?   yang:gauge64
             |  +-- peak-g?              yang:gauge64
             |  +-- current-g?           yang:gauge64
             +-- total-attack-traffic-protocol* [unit protocol]
             |  +-- protocol             uint8
             |  +-- unit                 unit
             |  +-- low-percentile-g?    yang:gauge64
             |  +-- mid-percentile-g?    yang:gauge64
             |  +-- high-percentile-g?   yang:gauge64
             |  +-- peak-g?              yang:gauge64
             |  +-- current-g?           yang:gauge64
             +-- total-attack-traffic-port* [unit port]
             |  +-- port                 inet:port-number
             |  +-- unit                 unit
             |  +-- low-percentile-g?    yang:gauge64
             |  +-- mid-percentile-g?    yang:gauge64
             |  +-- high-percentile-g?   yang:gauge64
             |  +-- peak-g?              yang:gauge64
             |  +-- current-g?           yang:gauge64
             +-- total-attack-connection-protocol* [protocol]
             |  ...
             +-- total-attack-connection-port* [protocol port]
             |  ...
             +-- attack-detail* [vendor-id attack-id]
                ...
</sourcecode>
          </figure>
        </section>
        <section anchor="attackconn" numbered="true" toc="include" removeInRFC="false" pn="section-8.1.4">
          <name slugifiedName="name-total-attack-connections">Total Attack Connections</name>
          <t indent="0" pn="section-8.1.4-1">If the target is susceptible to resource-consuming DDoS attacks,
          the 'total-attack-connection-protocol' attribute is used to convey
          the percentile values (including peak and current observed values)
          of various attributes related to the total attack connections. The
          following optional sub-attributes for the target per transport
          protocol are included to represent the attack characteristics:</t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-8.1.4-2">
            <li pn="section-8.1.4-2.1">The number of simultaneous attack connections to the
              target.</li>
            <li pn="section-8.1.4-2.2">The number of simultaneous embryonic connections to the
              target.</li>
            <li pn="section-8.1.4-2.3">The number of attack connections per second to the
              target.</li>
            <li pn="section-8.1.4-2.4">The number of attack requests per second to the target.</li>
            <li pn="section-8.1.4-2.5">The number of attack partial requests to the target.</li>
          </ul>
          <t indent="0" pn="section-8.1.4-3">The total attack connections per port number are represented
          using the 'total-attack-connection-port' attribute.</t>
          <figure anchor="tact" align="left" suppress-title="false" pn="figure-28">
            <name slugifiedName="name-total-attack-connections-tr">Total Attack Connections Tree Structure</name>
            <sourcecode name="" type="yangtree" markers="false" pn="section-8.1.4-4.1">
       +--:(telemetry)
          +-- pre-or-ongoing-mitigation* []
             +-- (direction)?
             |  +--:(server-to-client-only)
             |     +-- tmid?                      uint32
             +-- target
             |  ...
             +-- total-traffic* [unit]
             |  ...
             +-- total-traffic-protocol* [unit protocol]
             |  ...
             +-- total-traffic-port* [unit port]
             |  ...
             +-- total-attack-traffic* [unit]
             |  ...
             +-- total-attack-traffic-protocol* [unit protocol]
             |  ...
             +-- total-attack-traffic-port* [unit port]
             |  ...
             +-- total-attack-connection-protocol* [protocol]
             |  +-- protocol              uint8
             |  +-- connection-c
             |  |  +-- low-percentile-g?    yang:gauge64
             |  |  +-- mid-percentile-g?    yang:gauge64
             |  |  +-- high-percentile-g?   yang:gauge64
             |  |  +-- peak-g?              yang:gauge64
             |  |  +-- current-g?           yang:gauge64
             |  +-- embryonic-c
             |  |  +-- low-percentile-g?    yang:gauge64
             |  |  +-- mid-percentile-g?    yang:gauge64
             |  |  +-- high-percentile-g?   yang:gauge64
             |  |  +-- peak-g?              yang:gauge64
             |  |  +-- current-g?           yang:gauge64
             |  +-- connection-ps-c
             |  |  +-- low-percentile-g?    yang:gauge64
             |  |  +-- mid-percentile-g?    yang:gauge64
             |  |  +-- high-percentile-g?   yang:gauge64
             |  |  +-- peak-g?              yang:gauge64
             |  |  +-- current-g?           yang:gauge64
             |  +-- request-ps-c
             |  |  +-- low-percentile-g?    yang:gauge64
             |  |  +-- mid-percentile-g?    yang:gauge64
             |  |  +-- high-percentile-g?   yang:gauge64
             |  |  +-- peak-g?              yang:gauge64
             |  |  +-- current-g?           yang:gauge64
             |  +-- partial-request-c
             |     +-- low-percentile-g?    yang:gauge64
             |     +-- mid-percentile-g?    yang:gauge64
             |     +-- high-percentile-g?   yang:gauge64
             |     +-- peak-g?              yang:gauge64
             |     +-- current-g?           yang:gauge64
             +-- total-attack-connection-port* [protocol port]
             |  +-- protocol              uint8
             |  +-- port                  inet:port-number
             |  +-- connection-c
             |  |  +-- low-percentile-g?    yang:gauge64
             |  |  +-- mid-percentile-g?    yang:gauge64
             |  |  +-- high-percentile-g?   yang:gauge64
             |  |  +-- peak-g?              yang:gauge64
             |  |  +-- current-g?           yang:gauge64
             |  +-- embryonic-c
             |  |  +-- low-percentile-g?    yang:gauge64
             |  |  +-- mid-percentile-g?    yang:gauge64
             |  |  +-- high-percentile-g?   yang:gauge64
             |  |  +-- peak-g?              yang:gauge64
             |  |  +-- current-g?           yang:gauge64
             |  +-- connection-ps-c
             |  |  +-- low-percentile-g?    yang:gauge64
             |  |  +-- mid-percentile-g?    yang:gauge64
             |  |  +-- high-percentile-g?   yang:gauge64
             |  |  +-- peak-g?              yang:gauge64
             |  |  +-- current-g?           yang:gauge64
             |  +-- request-ps-c
             |  |  +-- low-percentile-g?    yang:gauge64
             |  |  +-- mid-percentile-g?    yang:gauge64
             |  |  +-- high-percentile-g?   yang:gauge64
             |  |  +-- peak-g?              yang:gauge64
             |  |  +-- current-g?           yang:gauge64
             |  +-- partial-request-c
             |     +-- low-percentile-g?    yang:gauge64
             |     +-- mid-percentile-g?    yang:gauge64
             |     +-- high-percentile-g?   yang:gauge64
             |     +-- peak-g?              yang:gauge64
             |     +-- current-g?           yang:gauge64
             +-- attack-detail* [vendor-id attack-id]
                ...
</sourcecode>
          </figure>
        </section>
        <section anchor="attackdetails" numbered="true" toc="include" removeInRFC="false" pn="section-8.1.5">
          <name slugifiedName="name-attack-details">Attack Details</name>
          <t indent="0" pn="section-8.1.5-1">This attribute (depicted in <xref target="adt" format="default" sectionFormat="of" derivedContent="Figure 29"/>) is used
          to signal a set of details characterizing an attack. The following
          sub-attributes describing the ongoing attack can be signaled as
          attack details:</t>
          <dl newline="false" spacing="normal" indent="3" pn="section-8.1.5-2">
            <dt pn="section-8.1.5-2.1">vendor-id:</dt>
            <dd pn="section-8.1.5-2.2">Vendor ID. This parameter represents a security vendor's
              enterprise number as registered in the IANA "Private
              Enterprise Numbers" registry <xref target="Private-Enterprise-Numbers" format="default" sectionFormat="of" derivedContent="Private-Enterprise-Numbers"/>.</dd>
            <dt pn="section-8.1.5-2.3">attack-id:</dt>
            <dd pn="section-8.1.5-2.4">Unique identifier assigned for the
              attack by a vendor. This parameter <bcp14>MUST</bcp14> be present, independently
              of whether 'attack-description' is included or not.</dd>
            <dt pn="section-8.1.5-2.5">description-lang:</dt>
            <dd pn="section-8.1.5-2.6">Indicates the language tag that
              is used for the text that is included in the
              'attack-description' attribute. This attribute is encoded
              following the rules in <xref target="RFC5646" sectionFormat="of" section="2.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5646#section-2.1" derivedContent="RFC5646"/>. The default language tag is
              "en-US".</dd>
            <dt pn="section-8.1.5-2.7">attack-description:</dt>
            <dd pn="section-8.1.5-2.8">Textual representation of the
              attack description. This description is related to the class of
              attack rather than a specific instance of it. Natural Language
              Processing techniques (e.g., word embedding) might provide some
              utility in mapping the attack description to an attack type.
              Textual representation of an attack solves two problems: it avoids
              the need to (a) create mapping tables manually between vendors and
              (b) standardize attack types that keep
              evolving.</dd>
            <dt pn="section-8.1.5-2.9">attack-severity:</dt>
            <dd pn="section-8.1.5-2.10">Attack severity level. This
              attribute takes one of the values defined in <xref target="RFC7970" sectionFormat="of" section="3.12.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7970#section-3.12.2" derivedContent="RFC7970"/>.</dd>
            <dt pn="section-8.1.5-2.11">start-time:</dt>
            <dd pn="section-8.1.5-2.12">The time the attack started. The
              attack's start time is expressed in seconds relative to
              1970-01-01T00:00Z (<xref target="RFC8949" sectionFormat="of" section="3.4.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8949#section-3.4.2" derivedContent="RFC8949"/>). The CBOR encoding is modified so that
              the leading tag 1 (epoch-based date/time) <bcp14>MUST</bcp14> be omitted.</dd>
            <dt pn="section-8.1.5-2.13">end-time:</dt>
            <dd pn="section-8.1.5-2.14">The time the attack ended. The attack's
              end time is expressed in seconds relative to 1970-01-01T00:00Z
              (<xref target="RFC8949" sectionFormat="of" section="3.4.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8949#section-3.4.2" derivedContent="RFC8949"/>). The CBOR
              encoding is modified so that the leading tag 1 (epoch-based
              date/time) <bcp14>MUST</bcp14> be omitted.</dd>
            <dt pn="section-8.1.5-2.15">source-count:</dt>
            <dd pn="section-8.1.5-2.16">A count of sources involved in the
              attack targeting the victim.</dd>
            <dt pn="section-8.1.5-2.17">top-talker:</dt>
            <dd pn="section-8.1.5-2.18">
              <t indent="0" pn="section-8.1.5-2.18.1">A list of attack sources that are
              involved in an attack and that are generating an important part
              of the attack traffic. The top talkers are represented using
              'source-prefix'.</t>
              <t indent="0" pn="section-8.1.5-2.18.2">'spoofed-status'
              indicates whether a top talker is a spoofed IP address (e.g.,
              reflection attacks) or not. If no 'spoofed-status' data node is
              included, this means that the spoofing status is unknown.</t>
              <t indent="0" pn="section-8.1.5-2.18.3">If the target is being subjected to a
              bandwidth-consuming attack, a statistical profile of the attack
              traffic from each of the top talkers is included
              ('total-attack-traffic'; see <xref target="tat" format="default" sectionFormat="of" derivedContent="Section 8.1.3"/>). </t>
              <t indent="0" pn="section-8.1.5-2.18.4">If the target is being subjected to a
              resource-consuming DDoS attack, the same attributes as those defined in
              <xref target="attackconn" format="default" sectionFormat="of" derivedContent="Section 8.1.4"/> are applicable for
              characterizing the attack on a per-talker basis.</t>
            </dd>
          </dl>
          <figure anchor="adt" align="left" suppress-title="false" pn="figure-29">
            <name slugifiedName="name-attack-details-tree-structu">Attack Details Tree Structure</name>
            <sourcecode name="" type="yangtree" markers="false" pn="section-8.1.5-3.1">
       +--:(telemetry)
          +-- pre-or-ongoing-mitigation* []
             +-- (direction)?
             |  +--:(server-to-client-only)
             |     +-- tmid?                      uint32
             +-- target
             |  ...
             +-- total-traffic* [unit]
             |  ...
             +-- total-traffic-protocol* [unit protocol]
             |  ...
             +-- total-traffic-port* [unit port]
             |  ...
             +-- total-attack-traffic* [unit]
             |  ...
             +-- total-attack-traffic-protocol* [unit protocol]
             |  ...
             +-- total-attack-traffic-port* [unit port]
             |  ...
             +-- total-attack-connection-protocol* [protocol]
             |  ...
             +-- total-attack-connection-port* [protocol port]
             |  ...
             +-- attack-detail* [vendor-id attack-id]
                +-- vendor-id             uint32
                +-- attack-id             uint32
                +-- description-lang?     string
                +-- attack-description?   string
                +-- attack-severity?      attack-severity
                +-- start-time?           uint64
                +-- end-time?             uint64
                +-- source-count
                |  +-- low-percentile-g?    yang:gauge64
                |  +-- mid-percentile-g?    yang:gauge64
                |  +-- high-percentile-g?   yang:gauge64
                |  +-- peak-g?              yang:gauge64
                |  +-- current-g?           yang:gauge64
                +-- top-talker
                   +-- talker* [source-prefix]
                      +-- spoofed-status?            boolean
                      +-- source-prefix              inet:ip-prefix
                      +-- source-port-range* [lower-port]
                      |  +-- lower-port    inet:port-number
                      |  +-- upper-port?   inet:port-number
                      +-- source-icmp-type-range* [lower-type]
                      |  +-- lower-type    uint8
                      |  +-- upper-type?   uint8
                      +-- total-attack-traffic* [unit]
                      |  +-- unit                 unit
                      |  +-- low-percentile-g?    yang:gauge64
                      |  +-- mid-percentile-g?    yang:gauge64
                      |  +-- high-percentile-g?   yang:gauge64
                      |  +-- peak-g?              yang:gauge64
                      |  +-- current-g?           yang:gauge64
                      +-- total-attack-connection-protocol*
                              [protocol]
                         +-- protocol              uint8
                         +-- connection-c
                         |  +-- low-percentile-g?    yang:gauge64
                         |  +-- mid-percentile-g?    yang:gauge64
                         |  +-- high-percentile-g?   yang:gauge64
                         |  +-- peak-g?              yang:gauge64
                         |  +-- current-g?           yang:gauge64
                         +-- embryonic-c
                         |  +-- low-percentile-g?    yang:gauge64
                         |  +-- mid-percentile-g?    yang:gauge64
                         |  +-- high-percentile-g?   yang:gauge64
                         |  +-- peak-g?              yang:gauge64
                         |  +-- current-g?           yang:gauge64
                         +-- connection-ps-c
                         |  +-- low-percentile-g?    yang:gauge64
                         |  +-- mid-percentile-g?    yang:gauge64
                         |  +-- high-percentile-g?   yang:gauge64
                         |  +-- peak-g?              yang:gauge64
                         |  +-- current-g?           yang:gauge64
                         +-- request-ps-c
                         |  +-- low-percentile-g?    yang:gauge64
                         |  +-- mid-percentile-g?    yang:gauge64
                         |  +-- high-percentile-g?   yang:gauge64
                         |  +-- peak-g?              yang:gauge64
                         |  +-- current-g?           yang:gauge64
                         +-- partial-request-c
                            +-- low-percentile-g?    yang:gauge64
                            +-- mid-percentile-g?    yang:gauge64
                            +-- high-percentile-g?   yang:gauge64
                            +-- peak-g?              yang:gauge64
                            +-- current-g?           yang:gauge64
</sourcecode>
          </figure>
          <t indent="0" pn="section-8.1.5-4">In order to optimize the size of telemetry data conveyed over the
          DOTS signal channel, DOTS agents <bcp14>MAY</bcp14> use the DOTS data channel <xref target="RFC8783" format="default" sectionFormat="of" derivedContent="RFC8783"/> to exchange vendor-specific attack mapping
          details (that is, {vendor identifier, attack identifier} ==&gt;
          textual representation of the attack description). As such, DOTS
          agents do not have to convey an attack description systematically in
          their telemetry messages over the DOTS signal channel. Refer to
          <xref target="vam" format="default" sectionFormat="of" derivedContent="Section 8.1.6"/>.</t>
        </section>
        <section anchor="vam" numbered="true" toc="include" removeInRFC="false" pn="section-8.1.6">
          <name slugifiedName="name-vendor-attack-mapping">Vendor Attack Mapping</name>
          <t indent="0" pn="section-8.1.6-1">Multiple mappings for different vendor identifiers may be used;
          the DOTS agent transmitting telemetry information can elect to use
          one or more vendor mappings even in the same telemetry message.</t>
          <aside pn="section-8.1.6-2">
            <t indent="0" pn="section-8.1.6-2.1">
              Note: It is possible that a DOTS server is making use of
              multiple DOTS mitigators, each from a different vendor. How
              telemetry information and vendor mappings are exchanged between
              DOTS servers and DOTS mitigators is outside the scope of this
              document.
            </t>
          </aside>
          <t indent="0" pn="section-8.1.6-3">DOTS clients and servers may be provided with mappings from
          different vendors and so have their own different sets of vendor
          attack mappings. A DOTS agent <bcp14>MUST</bcp14> accept receipt of telemetry data
          with a vendor identifier that is different than the identifier it uses to
          transmit telemetry data. Furthermore, it is possible that the DOTS
          client and DOTS server are provided by the same vendor but the
          vendor mapping tables are at different revisions. The DOTS client
          <bcp14>SHOULD</bcp14> transmit telemetry information using any vendor mapping(s)
          that it provided to the DOTS server (e.g., using a POST as depicted
          in <xref target="installmap" format="default" sectionFormat="of" derivedContent="Figure 30"/>), and the DOTS server <bcp14>SHOULD</bcp14> use
          any vendor mappings(s) provided to the DOTS client when transmitting
          telemetry data to the peer DOTS agent.</t>
          <figure anchor="installmap" align="left" suppress-title="false" pn="figure-30">
            <name slugifiedName="name-post-to-install-vendor-atta">POST to Install Vendor Attack Mapping Details</name>
            <artwork name="" type="" align="left" alt="" pn="section-8.1.6-4.1">POST /restconf/data/ietf-dots-data-channel:dots-data\
     /dots-client=dz6pHjaADkaFTbjr0JGBpw HTTP/1.1
Host: example.com
Content-Type: application/yang-data+json

{
  "ietf-dots-mapping:vendor-mapping": {
    "vendor": [
      {
        "vendor-id": 345,
        "vendor-name": "mitigator-c",
        "last-updated": "1629898958",
        "attack-mapping": [
          {
            "attack-id": 1,
            "attack-description": 
               "Include a description of this attack"
          },
          {
            "attack-id": 2,
            "attack-description": 
               "Again, include a description of the attack"
          }
        ]
      }
    ]
  }
}
</artwork>
          </figure>
          <t indent="0" pn="section-8.1.6-5">The "ietf-dots-mapping" YANG module defined in <xref target="data" format="default" sectionFormat="of" derivedContent="Section 11.2"/> augments the "ietf-dots-data-channel" module <xref target="RFC8783" format="default" sectionFormat="of" derivedContent="RFC8783"/>. The tree structure of the
          "ietf-dots-mapping" module is shown in <xref target="abstract-data" format="default" sectionFormat="of" derivedContent="Figure 31"/>.</t>
          <figure anchor="abstract-data" align="left" suppress-title="false" pn="figure-31">
            <name slugifiedName="name-vendor-attack-mapping-tree-">Vendor Attack Mapping Tree Structure</name>
            <sourcecode name="" type="yangtree" markers="false" pn="section-8.1.6-6.1">
module: ietf-dots-mapping
  augment /data-channel:dots-data/data-channel:dots-client:
    +--rw vendor-mapping {dots-telemetry}?
       +--rw vendor* [vendor-id]
          +--rw vendor-id         uint32
          +--rw vendor-name?      string
          +--rw description-lang?   string
          +--rw last-updated      uint64
          +--rw attack-mapping* [attack-id]
             +--rw attack-id             uint32
             +--rw attack-description    string
  augment /data-channel:dots-data/data-channel:capabilities:
    +--ro vendor-mapping-enabled?   boolean {dots-telemetry}?
  augment /data-channel:dots-data:
    +--ro vendor-mapping {dots-telemetry}?
       +--ro vendor* [vendor-id]
          +--ro vendor-id         uint32
          +--ro vendor-name?      string
          +--ro description-lang?   string
          +--ro last-updated      uint64
          +--ro attack-mapping* [attack-id]
             +--ro attack-id             uint32
             +--ro attack-description    string
</sourcecode>
          </figure>
          <t indent="0" pn="section-8.1.6-7">A DOTS client sends a GET request over the DOTS data channel to
          retrieve the capabilities supported by a DOTS server as per <xref target="RFC8783" sectionFormat="of" section="7.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8783#section-7.1" derivedContent="RFC8783"/>. This request is meant to
          assess whether the capability of sharing vendor attack mapping
          details is supported by the server (i.e., check the value of
          'vendor-mapping-enabled').</t>
          <t indent="0" pn="section-8.1.6-8">If 'vendor-mapping-enabled' is set to 'true', a DOTS client <bcp14>MAY</bcp14>
          send a GET request to retrieve the DOTS server's vendor attack
          mapping details. An example of such a GET request is shown in <xref target="MfS" format="default" sectionFormat="of" derivedContent="Figure 32"/>.</t>
          <figure anchor="MfS" align="left" suppress-title="false" pn="figure-32">
            <name slugifiedName="name-get-to-retrieve-the-vendor-">GET to Retrieve the Vendor Attack Mappings of a DOTS Server</name>
            <artwork name="" type="" align="left" alt="" pn="section-8.1.6-9.1">GET /restconf/data/ietf-dots-data-channel:dots-data\
    /ietf-dots-mapping:vendor-mapping HTTP/1.1
Host: example.com
Accept: application/yang-data+json
</artwork>
          </figure>
          <t indent="0" pn="section-8.1.6-10">A DOTS client can retrieve only the list of vendors supported by
          the DOTS server. It does so by setting the "depth" parameter
          (<xref target="RFC8040" sectionFormat="of" section="4.8.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8040#section-4.8.2" derivedContent="RFC8040"/>) to "3" in the GET
          request as shown in <xref target="MfSd" format="default" sectionFormat="of" derivedContent="Figure 33"/>. An example of a
          response body received from the DOTS server as a response to such a
          request is illustrated in <xref target="MfSdr" format="default" sectionFormat="of" derivedContent="Figure 34"/>.</t>
          <figure anchor="MfSd" align="left" suppress-title="false" pn="figure-33">
            <name slugifiedName="name-get-to-retrieve-the-vendors">GET to Retrieve the Vendors List Used by a DOTS Server</name>
            <artwork name="" type="" align="left" alt="" pn="section-8.1.6-11.1">GET /restconf/data/ietf-dots-data-channel:dots-data\
    /ietf-dots-mapping:vendor-mapping?depth=3 HTTP/1.1
Host: example.com
Accept: application/yang-data+json
</artwork>
          </figure>
          <figure anchor="MfSdr" align="left" suppress-title="false" pn="figure-34">
            <name slugifiedName="name-response-message-body-to-a-">Response Message Body to a GET to Retrieve the Vendors List Used by a DOTS Server</name>
            <artwork name="" type="" align="left" alt="" pn="section-8.1.6-12.1">{
  "ietf-dots-mapping:vendor-mapping": {
    "vendor": [
      {
        "vendor-id": 32473,
        "vendor-name": "mitigator-s",
        "last-updated": "1629898758",
        "attack-mapping": []
      }
    ]
  }
}
</artwork>
          </figure>
          <t indent="0" pn="section-8.1.6-13">The DOTS client repeats the above procedure regularly (e.g., once
          a week) to update the DOTS server's vendor attack mapping
          details.</t>
          <t indent="0" pn="section-8.1.6-14">If the DOTS client concludes that the DOTS server does not have
          any reference to the specific vendor attack mapping details, the
          DOTS client uses a POST request to install its vendor attack mapping
          details. An example of such a POST request is depicted in <xref target="installmap" format="default" sectionFormat="of" derivedContent="Figure 30"/>.</t>
          <t indent="0" pn="section-8.1.6-15">The DOTS server indicates the result of processing the POST
          request using the status-line. A "201 Created" status-line <bcp14>MUST</bcp14> be
          returned in the response if the DOTS server has accepted the vendor
          attack mapping details. If the request is missing a mandatory
          attribute or contains an invalid or unknown parameter, a "400 Bad
          Request" status-line <bcp14>MUST</bcp14> be returned by the DOTS server in the
          response. The error-tag is set to "missing-attribute",
          "invalid-value", or "unknown-element" as a function of the
          encountered error.</t>
          <t indent="0" pn="section-8.1.6-16">If the request is received via a server-domain DOTS gateway but
          the DOTS server does not maintain a 'cdid' for this 'cuid' while a
          'cdid' is expected to be supplied, the DOTS server <bcp14>MUST</bcp14> reply with a
          "403 Forbidden" status-line and the error-tag "access-denied". Upon
          receipt of this message, the DOTS client <bcp14>MUST</bcp14> register (<xref target="RFC8783" sectionFormat="of" section="5.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8783#section-5.1" derivedContent="RFC8783"/>).</t>
          <t indent="0" pn="section-8.1.6-17">The DOTS client uses the PUT request to modify its vendor attack
          mapping details maintained by the DOTS server (e.g., add a new
          mapping entry, update an existing mapping).</t>
          <t indent="0" pn="section-8.1.6-18">A DOTS client uses a GET request to retrieve its vendor attack
          mapping details as maintained by the DOTS server (<xref target="allD" format="default" sectionFormat="of" derivedContent="Figure 35"/>).</t>
          <figure anchor="allD" align="left" suppress-title="false" pn="figure-35">
            <name slugifiedName="name-get-to-retrieve-installed-v">GET to Retrieve Installed Vendor Attack Mapping Details</name>
            <artwork name="" type="" align="left" alt="" pn="section-8.1.6-19.1">GET /restconf/data/ietf-dots-data-channel:dots-data\
    /dots-client=dz6pHjaADkaFTbjr0JGBpw\
    /ietf-dots-mapping:vendor-mapping?\
    content=all HTTP/1.1
Host: example.com
Accept: application/yang-data+json
</artwork>
          </figure>
          <t indent="0" pn="section-8.1.6-20">When conveying attack details in DOTS telemetry messages
          (Sections <xref format="counter" target="preCtoS" sectionFormat="of" derivedContent="8.2"/>, <xref format="counter" target="preStoC" sectionFormat="of" derivedContent="8.3"/>, and <xref format="counter" target="status" sectionFormat="of" derivedContent="9"/>), DOTS agents <bcp14>MUST NOT</bcp14>
          include the 'attack-description' attribute unless the corresponding
          attack mapping details were not previously shared with the peer DOTS
          agent.</t>
        </section>
      </section>
      <section anchor="preCtoS" numbered="true" toc="include" removeInRFC="false" pn="section-8.2">
        <name slugifiedName="name-from-dots-clients-to-dots-s">From DOTS Clients to DOTS Servers</name>
        <t indent="0" pn="section-8.2-1">DOTS clients use PUT requests to signal pre-or-ongoing-mitigation
        telemetry to DOTS servers. An example of such a request is shown in
        <xref target="put-tmid-c" format="default" sectionFormat="of" derivedContent="Figure 36"/>.</t>
        <figure anchor="put-tmid-c" align="left" suppress-title="false" pn="figure-36">
          <name slugifiedName="name-put-to-send-pre-or-ongoing-">PUT to Send Pre-or-Ongoing-Mitigation Telemetry, Depicted as per Section 5.6</name>
          <sourcecode name="" type="json" markers="false" pn="section-8.2-2.1">Header: PUT (Code=0.03)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "tm"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "tmid=123"
Content-Format: "application/dots+cbor"

{
  "ietf-dots-telemetry:telemetry": {
    "pre-or-ongoing-mitigation": [
      {
        "target": {
          "target-prefix": [
            "2001:db8::1/128"
          ]
        },
        "total-attack-traffic-protocol": [
          {
            "protocol": 17,
            "unit": "megabit-ps",
            "mid-percentile-g": "900"
          }
        ],
        "attack-detail": [
          {
            "vendor-id": 32473,
            "attack-id": 77,
            "start-time": "1608336568",
            "attack-severity": "high"
          }
        ]
      }
    ]
  }
}
</sourcecode>
        </figure>
        <t indent="0" pn="section-8.2-3">'cuid' is a mandatory Uri-Path parameter for DOTS PUT requests.</t>
        <t indent="0" pn="section-8.2-4">The following additional Uri-Path parameter is defined: </t>
        <dl newline="false" spacing="normal" indent="3" pn="section-8.2-5">
          <dt pn="section-8.2-5.1">tmid:</dt>
          <dd pn="section-8.2-5.2">
            <t indent="0" pn="section-8.2-5.2.1">The Telemetry Identifier is an identifier for the
            DOTS pre-or-ongoing-mitigation telemetry data represented as an
            integer. This identifier <bcp14>MUST</bcp14> be generated by DOTS clients.  'tmid'
            values <bcp14>MUST</bcp14> increase monotonically whenever a DOTS client needs to
            convey a new set of pre-or-ongoing-mitigation telemetry data. </t>
            <t indent="0" pn="section-8.2-5.2.2">The procedure specified in <xref target="RFC9132" sectionFormat="of" section="4.4.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9132#section-4.4.1" derivedContent="RFC9132"/> for 'mid' rollover <bcp14>MUST</bcp14> be followed for
            'tmid' rollover.</t>
            <t indent="0" pn="section-8.2-5.2.3">This is a mandatory
            attribute.  'tmid' <bcp14>MUST</bcp14> appear after 'cuid' in the Uri-Path
            options.</t>
          </dd>
        </dl>
        <t indent="0" pn="section-8.2-6">'cuid' and 'tmid' <bcp14>MUST NOT</bcp14> appear in the PUT request message
        body.</t>
        <t indent="0" pn="section-8.2-7">At least the 'target' attribute and another
        pre-or-ongoing-mitigation attribute (<xref target="pre" format="default" sectionFormat="of" derivedContent="Section 8.1"/>) <bcp14>MUST</bcp14>
        be present in the PUT request. If only the 'target' attribute is
        present, this request is handled as per <xref target="preStoC" format="default" sectionFormat="of" derivedContent="Section 8.3"/>.</t>
        <t indent="0" pn="section-8.2-8">The relative order of two PUT requests carrying DOTS
        pre-or-ongoing-mitigation telemetry from a DOTS client is determined
        by comparing their respective 'tmid' values. If these two requests have
        an overlapping 'target', the PUT request with a higher numeric 'tmid'
        value will override the request with a lower numeric 'tmid' value. The
        overlapped lower numeric 'tmid' <bcp14>MUST</bcp14> be automatically deleted and no
        longer be available.</t>
        <t indent="0" pn="section-8.2-9">The DOTS server indicates the result of processing a PUT request
        using CoAP Response Codes. In particular, the 2.04 (Changed) Response
        Code is returned if the DOTS server has accepted the
        pre-or-ongoing-mitigation telemetry. The 5.03 (Service Unavailable)
        Response Code is returned if the DOTS server has erred. The 5.03 Response Code uses the
        Max-Age Option to indicate the number of seconds after which to
        retry.</t>
        <t indent="0" pn="section-8.2-10">How long a DOTS server maintains a 'tmid' as active or logs the
        enclosed telemetry information is implementation specific. Note that
        if a 'tmid' is still active, then logging details are updated by
        the DOTS server as a function of the updates received from the peer
        DOTS client.</t>
        <t indent="0" pn="section-8.2-11">A DOTS client that lost the state of its active 'tmid's or has to
        set 'tmid' back to zero (e.g., crash or restart) <bcp14>MUST</bcp14> send a GET
        request to the DOTS server to retrieve the list of active 'tmid'
        values. The DOTS client may then delete 'tmid's that should not be
        active anymore (<xref target="spa" format="default" sectionFormat="of" derivedContent="Figure 37"/>). Sending a DELETE with no
        'tmid' indicates that all 'tmid's must be deactivated (<xref target="dpa" format="default" sectionFormat="of" derivedContent="Figure 38"/>).</t>
        <figure anchor="spa" align="left" suppress-title="false" pn="figure-37">
          <name slugifiedName="name-deleting-specific-pre-or-on">Deleting Specific Pre-or-Ongoing-Mitigation Telemetry  Information</name>
          <sourcecode name="" type="json" markers="false" pn="section-8.2-12.1">Header: DELETE (Code=0.04)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "tm"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "tmid=123"
</sourcecode>
        </figure>
        <figure anchor="dpa" align="left" suppress-title="false" pn="figure-38">
          <name slugifiedName="name-deleting-all-pre-or-ongoing">Deleting All Pre-or-Ongoing-Mitigation Telemetry Information</name>
          <sourcecode name="" type="json" markers="false" pn="section-8.2-13.1">Header: DELETE (Code=0.04)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "tm"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
</sourcecode>
        </figure>
      </section>
      <section anchor="preStoC" numbered="true" toc="include" removeInRFC="false" pn="section-8.3">
        <name slugifiedName="name-from-dots-servers-to-dots-c">From DOTS Servers to DOTS Clients</name>
        <t indent="0" pn="section-8.3-1">The pre-or-ongoing-mitigation data (attack details in particular)
        can also be signaled from DOTS servers to DOTS clients. For example, a
        DOTS server co-located with a DDoS detector can collect monitoring
        information from the target network, identify a DDoS attack using
        statistical analysis or deep learning techniques, and signal the
        attack details to the DOTS client.</t>
        <t indent="0" pn="section-8.3-2">The DOTS client can use the attack details to decide whether to
        trigger a DOTS mitigation request or not. Furthermore, the security
        operations personnel at the DOTS client domain can use the attack
        details to determine the protection strategy and select the
        appropriate DOTS server for mitigating the attack.</t>
        <t indent="0" pn="section-8.3-3">In order to receive pre-or-ongoing-mitigation telemetry
        notifications from a DOTS server, a DOTS client <bcp14>MUST</bcp14> send a PUT
        (followed by a GET) with the target filter. An example of such a PUT
        request is shown in <xref target="put-tmid" format="default" sectionFormat="of" derivedContent="Figure 39"/>. In order to avoid
        maintaining a long list of such requests, it is <bcp14>RECOMMENDED</bcp14> that DOTS
        clients include all targets in the same request (assuming that this information fits
        within one single datagram). DOTS servers may be instructed to
        restrict the number of pre-or-ongoing-mitigation requests per DOTS
        client domain. The pre-or-ongoing-mitigation requests <bcp14>MUST</bcp14> be
        maintained in an active state by the DOTS server until a DELETE
        request is received from the same DOTS client to clear this
        pre-or-ongoing-mitigation telemetry or when the DOTS client is
        considered inactive (e.g., <xref target="RFC8783" sectionFormat="of" section="3.5" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8783#section-3.5" derivedContent="RFC8783"/>).</t>
        <t indent="0" pn="section-8.3-4">The relative order of two PUT requests carrying DOTS
        pre-or-ongoing-mitigation telemetry from a DOTS client is determined
        by comparing their respective 'tmid' values. If these two requests have an
        overlapping 'target', the PUT request with a higher numeric 'tmid' value
        will override the request with a lower numeric 'tmid' value. The
        overlapped lower numeric 'tmid' <bcp14>MUST</bcp14> be automatically deleted and no
        longer be available.</t>
        <figure anchor="put-tmid" align="left" suppress-title="false" pn="figure-39">
          <name slugifiedName="name-put-to-request-pre-or-ongoi">PUT to Request Pre-or-Ongoing-Mitigation Telemetry, Depicted as per Section 5.6</name>
          <sourcecode name="" type="json" markers="false" pn="section-8.3-5.1">Header: PUT (Code=0.03)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "tm"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "tmid=567"
Content-Format: "application/dots+cbor"

{
  "ietf-dots-telemetry:telemetry": {
    "pre-or-ongoing-mitigation": [
      {
        "target": {
          "target-prefix": [
            "2001:db8::/32"
          ]
        }
      }
    ]
  }
}
</sourcecode>
        </figure>
        <t indent="0" pn="section-8.3-6">DOTS clients of the same domain can ask to receive
        pre-or-ongoing-mitigation telemetry bound to the same target without
        being considered to be "overlapping" and in conflict.</t>
        <t indent="0" pn="section-8.3-7">Once the PUT request to instantiate request state on the server has
        succeeded, the DOTS client issues a GET request to receive ongoing
        telemetry updates. The client uses the Observe Option, set to "0"
        (register), in the GET request to receive asynchronous notifications
        carrying pre-or-ongoing-mitigation telemetry data from the DOTS
        server. The GET request can specify a specific 'tmid' (<xref target="gettmid" format="default" sectionFormat="of" derivedContent="Figure 40"/>) or omit the 'tmid' (<xref target="getall" format="default" sectionFormat="of" derivedContent="Figure 41"/>) to receive updates on all active requests
        from that client.</t>
        <figure anchor="gettmid" align="left" suppress-title="false" pn="figure-40">
          <name slugifiedName="name-get-to-subscribe-to-telemet">GET to Subscribe to Telemetry Asynchronous Notifications for a Specific 'tmid'</name>
          <sourcecode name="" type="json" markers="false" pn="section-8.3-8.1">Header: GET (Code=0.01)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "tm"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "tmid=567"
Observe: 0
</sourcecode>
        </figure>
        <figure anchor="getall" align="left" suppress-title="false" pn="figure-41">
          <name slugifiedName="name-get-to-subscribe-to-telemetr">GET to Subscribe to Telemetry Asynchronous Notifications for All 'tmid's</name>
          <sourcecode name="" type="json" markers="false" pn="section-8.3-9.1">Header: GET (Code=0.01)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "tm"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Observe: 0
</sourcecode>
        </figure>
        <t indent="0" pn="section-8.3-10">The DOTS client can use a filter to request a subset of the
        asynchronous notifications from the DOTS server by indicating one or
        more Uri-Query options in its GET request. A Uri-Query option can
        include the following parameters to restrict the notifications based
        on the attack target: 'target-prefix', 'target-port',
        'target-protocol', 'target-fqdn', 'target-uri', 'alias-name', 'mid',
        and 'c' (content) (<xref target="control" format="default" sectionFormat="of" derivedContent="Section 5.4"/>). Furthermore:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-8.3-11">
          <li pn="section-8.3-11.1">If more than one Uri-Query option is included in a request,
            these options are interpreted in the same way as when multiple
            target attributes are included in a message body (<xref target="RFC9132" sectionFormat="of" section="4.4.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9132#section-4.4.1" derivedContent="RFC9132"/>).</li>
          <li pn="section-8.3-11.2">If multiple values of a query parameter are to be included in a
            request, these values <bcp14>MUST</bcp14> be included in the same Uri-Query
            option and separated by a "," character without any spaces.</li>
          <li pn="section-8.3-11.3">Range values (i.e., a contiguous inclusive block) can be
            included for the 'target-port', 'target-protocol', and 'mid'
            parameters by indicating the two boundary values separated by a
            "-" character.</li>
          <li pn="section-8.3-11.4">Wildcard names (i.e., a name with the leftmost label is the "*"
            character) can be included in 'target-fqdn' or 'target-uri'
            parameters. DOTS clients <bcp14>MUST NOT</bcp14> include a name in which the "*"
            character is included in a label other than the leftmost label.
            "*.example.com" is an example of a valid wildcard name that can be
            included as a value of the 'target-fqdn' parameter in a Uri-Query
            option.</li>
        </ul>
        <t indent="0" pn="section-8.3-12">DOTS clients may also filter out the asynchronous notifications
        from the DOTS server by indicating information about a specific attack
        source. To that aim, a DOTS client may include 'source-prefix',
        'source-port', or 'source-icmp-type' in a Uri-Query option. The same
        considerations (ranges, multiple values) specified for target
        attributes apply for source attributes. Special care <bcp14>SHOULD</bcp14> be taken
        when using these filters, as their use may cause some attacks to be
        hidden from the requesting DOTS client (e.g., if the attack changes its
        source information).</t>
        <t indent="0" pn="section-8.3-13">Requests with invalid query types (e.g., not supported, malformed)
        received by the DOTS server <bcp14>MUST</bcp14> be rejected with a 4.00 (Bad Request) Response Code.</t>
        <t indent="0" pn="section-8.3-14">An example of a request to subscribe to asynchronous telemetry
        notifications regarding UDP traffic is shown in <xref target="notif_filter-tm" format="default" sectionFormat="of" derivedContent="Figure 42"/>. This filter will be applied for all
        'tmid's.</t>
        <figure anchor="notif_filter-tm" align="left" suppress-title="false" pn="figure-42">
          <name slugifiedName="name-get-request-to-receive-tele">GET Request to Receive Telemetry Asynchronous Notifications Filtered Using Uri-Query</name>
          <sourcecode name="" type="json" markers="false" pn="section-8.3-15.1">Header: GET (Code=0.01)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "tm"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Query: "target-protocol=17"
Observe: 0
</sourcecode>
        </figure>
        <t indent="0" pn="section-8.3-16">The DOTS server will send asynchronous notifications to the DOTS
        client when an attack event is detected, following considerations similar
        to those discussed in <xref target="RFC9132" sectionFormat="of" section="4.4.2.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9132#section-4.4.2.1" derivedContent="RFC9132"/>. An example of a pre-or-ongoing-mitigation
        telemetry notification is shown in <xref target="noti" format="default" sectionFormat="of" derivedContent="Figure 43"/>.</t>
        <figure anchor="noti" align="left" suppress-title="false" pn="figure-43">
          <name slugifiedName="name-message-body-of-a-pre-or-on">Message Body of a Pre-or-Ongoing-Mitigation Telemetry Notification from the DOTS Server, Depicted as per Section 5.6</name>
          <artwork name="" type="" align="left" alt="" pn="section-8.3-17.1">{
  "ietf-dots-telemetry:telemetry": {
    "pre-or-ongoing-mitigation": [
      {
        "tmid": 567,
        "target": {
          "target-prefix": [
            "2001:db8::1/128"
          ]
        },
        "target-protocol": [
          17
        ],
        "total-attack-traffic": [
          {
            "unit": "megabit-ps",
            "mid-percentile-g": "900"
          }
        ],
        "attack-detail": [
          {
            "vendor-id": 32473,
            "attack-id": 77,
            "start-time": "1618339785",
            "attack-severity": "high"
          }
        ]
      }
    ]
  }
}
</artwork>
        </figure>
        <t indent="0" pn="section-8.3-18">A DOTS server sends the aggregate data for a target using the
        'total-attack-traffic' attribute. The aggregate assumes that Uri-Query
        filters are applied on the target. The DOTS server <bcp14>MAY</bcp14> include more
        fine-grained data when needed (that is,
        'total-attack-traffic-protocol' and 'total-attack-traffic-port'). If a
        port filter (or protocol filter) is included in a request,
        'total-attack-traffic-protocol' (or 'total-attack-traffic-port')
        conveys the data with the port (or protocol) filter applied.</t>
        <t indent="0" pn="section-8.3-19">A DOTS server may aggregate pre-or-ongoing-mitigation data (e.g.,
        'top-talker') for all targets of a domain or, when justified, send
        specific information (e.g., 'top-talker') for a specific target.</t>
        <t indent="0" pn="section-8.3-20">The DOTS client may log pre-or-ongoing-mitigation telemetry data
        with an alert sent to an administrator or a network controller. The
        DOTS client may send a mitigation request if the attack cannot be
        handled locally.</t>
        <t indent="0" pn="section-8.3-21">A DOTS client that is not interested in receiving
        pre-or-ongoing-mitigation telemetry data for a target sends a DELETE
        request similar to the DELETE request depicted in <xref target="spa" format="default" sectionFormat="of" derivedContent="Figure 37"/>.</t>
      </section>
    </section>
    <section anchor="status" numbered="true" toc="include" removeInRFC="false" pn="section-9">
      <name slugifiedName="name-dots-telemetry-mitigation-s">DOTS Telemetry Mitigation Status Update</name>
      <section anchor="effu-S" numbered="true" toc="include" removeInRFC="false" pn="section-9.1">
        <name slugifiedName="name-from-dots-clients-to-dots-se">From DOTS Clients to DOTS Servers: Mitigation Efficacy DOTS Telemetry Attributes</name>
        <t indent="0" pn="section-9.1-1">The mitigation efficacy telemetry attributes can be signaled from
        DOTS clients to DOTS servers as part of the periodic mitigation
        efficacy updates to the server (<xref target="RFC9132" sectionFormat="of" section="4.4.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9132#section-4.4.3" derivedContent="RFC9132"/>).</t>
        <dl newline="false" spacing="normal" indent="3" pn="section-9.1-2">
          <dt pn="section-9.1-2.1">Total attack traffic: </dt>
          <dd pn="section-9.1-2.2">The overall attack traffic as
            observed from the DOTS client's perspective during an active
            mitigation. See <xref target="tatt" format="default" sectionFormat="of" derivedContent="Figure 27"/>.</dd>
          <dt pn="section-9.1-2.3">Attack details: </dt>
          <dd pn="section-9.1-2.4">The overall attack details as
            observed from the DOTS client's perspective during an active
            mitigation. See <xref target="attackdetails" format="default" sectionFormat="of" derivedContent="Section 8.1.5"/>.</dd>
        </dl>
        <t indent="0" pn="section-9.1-3">The "ietf-dots-telemetry" YANG module (<xref target="module" format="default" sectionFormat="of" derivedContent="Section 11.1"/>) augments the 'mitigation-scope' message type
        defined in the "ietf-dots-signal-channel" module <xref target="RFC9132" format="default" sectionFormat="of" derivedContent="RFC9132"/> so that these attributes can be signaled by
        a DOTS client in a mitigation efficacy update (<xref target="eff" format="default" sectionFormat="of" derivedContent="Figure 44"/>).</t>
        <figure anchor="eff" align="left" suppress-title="false" pn="figure-44">
          <name slugifiedName="name-telemetry-efficacy-update-t">Telemetry Efficacy Update Tree Structure</name>
          <sourcecode name="" type="yangtree" markers="false" pn="section-9.1-4.1">  augment-structure /dots-signal:dots-signal/dots-signal:message-type
                    /dots-signal:mitigation-scope/dots-signal:scope:
    +-- total-attack-traffic* [unit]
    |  +-- unit                 unit
    |  +-- low-percentile-g?    yang:gauge64
    |  +-- mid-percentile-g?    yang:gauge64
    |  +-- high-percentile-g?   yang:gauge64
    |  +-- peak-g?              yang:gauge64
    |  +-- current-g?           yang:gauge64
    +-- attack-detail* [vendor-id attack-id]
       +-- vendor-id             uint32
       +-- attack-id             uint32
       +-- attack-description?   string
       +-- attack-severity?      attack-severity
       +-- start-time?           uint64
       +-- end-time?             uint64
       +-- source-count
       |  +-- low-percentile-g?    yang:gauge64
       |  +-- mid-percentile-g?    yang:gauge64
       |  +-- high-percentile-g?   yang:gauge64
       |  +-- peak-g?              yang:gauge64
       |  +-- current-g?           yang:gauge64
       +-- top-talker
          +-- talker* [source-prefix]
             +-- spoofed-status?            boolean
             +-- source-prefix              inet:ip-prefix
             +-- source-port-range* [lower-port]
             |  +-- lower-port    inet:port-number
             |  +-- upper-port?   inet:port-number
             +-- source-icmp-type-range* [lower-type]
             |  +-- lower-type    uint8
             |  +-- upper-type?   uint8
             +-- total-attack-traffic* [unit]
             |  +-- unit                 unit
             |  +-- low-percentile-g?    yang:gauge64
             |  +-- mid-percentile-g?    yang:gauge64
             |  +-- high-percentile-g?   yang:gauge64
             |  +-- peak-g?              yang:gauge64
             |  +-- current-g?           yang:gauge64
             +-- total-attack-connection
                +-- connection-c
                |  +-- low-percentile-g?    yang:gauge64
                |  +-- mid-percentile-g?    yang:gauge64
                |  +-- high-percentile-g?   yang:gauge64
                |  +-- peak-g?              yang:gauge64
                |  +-- current-g?           yang:gauge64
                +-- embryonic-c
                |  ...
                +-- connection-ps-c
                |  ...
                +-- request-ps-c
                |  ...
                +-- partial-request-c
                   ...
</sourcecode>
        </figure>
        <t indent="0" pn="section-9.1-5">In order to signal telemetry data in a mitigation efficacy update,
        it is <bcp14>RECOMMENDED</bcp14> that the DOTS client have already established a DOTS
        telemetry setup session with the server in 'idle' time. Such a session
        is primarily meant to assess whether the peer DOTS server supports
        telemetry extensions and to thus prevent message processing failure
        (<xref target="RFC9132" sectionFormat="of" section="3.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9132#section-3.1" derivedContent="RFC9132"/>).</t>
        <t indent="0" pn="section-9.1-6">An example of an efficacy update with telemetry attributes is
        depicted in <xref target="effu" format="default" sectionFormat="of" derivedContent="Figure 45"/>.</t>
        <figure anchor="effu" align="left" suppress-title="false" pn="figure-45">
          <name slugifiedName="name-example-of-mitigation-effic">Example of Mitigation Efficacy Update with Telemetry Attributes, Depicted as per Section 5.6</name>
          <sourcecode name="" type="json" markers="false" pn="section-9.1-7.1">Header: PUT (Code=0.03)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "mitigate"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "mid=123"
If-Match:
Content-Format: "application/dots+cbor"

{
  "ietf-dots-signal-channel:mitigation-scope": {
    "scope": [
      {
        "alias-name": [
          "https1",
          "https2"
        ],
        "attack-status": "under-attack",
        "ietf-dots-telemetry:total-attack-traffic": [
          {
            "unit": "megabit-ps",
            "mid-percentile-g": "900"
          }
        ]
      }
    ]
  }
}
</sourcecode>
        </figure>
      </section>
      <section anchor="premStoC" numbered="true" toc="include" removeInRFC="false" pn="section-9.2">
        <name slugifiedName="name-from-dots-servers-to-dots-cl">From DOTS Servers to DOTS Clients: Mitigation Status DOTS Telemetry Attributes</name>
        <t indent="0" pn="section-9.2-1">The mitigation status telemetry attributes can be signaled from the
        DOTS server to the DOTS client as part of the periodic mitigation
        status update (<xref target="RFC9132" sectionFormat="of" section="4.4.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9132#section-4.4.2" derivedContent="RFC9132"/>). In
        particular, DOTS clients can receive asynchronous notifications of the
        attack details from DOTS servers using the Observe Option defined in
        <xref target="RFC7641" format="default" sectionFormat="of" derivedContent="RFC7641"/>.</t>
        <t indent="0" pn="section-9.2-2">In order to make use of this feature, DOTS clients <bcp14>MUST</bcp14> establish a
        telemetry session with the DOTS server in 'idle' time and <bcp14>MUST</bcp14> set the
        'server-originated-telemetry' attribute to 'true'.</t>
        <t indent="0" pn="section-9.2-3">DOTS servers <bcp14>MUST NOT</bcp14> include telemetry attributes in mitigation
        status updates sent to DOTS clients for telemetry sessions in which
        the 'server-originated-telemetry' attribute is set to 'false'.</t>
        <t indent="0" pn="section-9.2-4">As defined in <xref target="RFC8612" format="default" sectionFormat="of" derivedContent="RFC8612"/>, the actual mitigation
        activities can include several countermeasure mechanisms. The DOTS
        server signals the current operational status of relevant
        countermeasures. A list of attacks detected by these countermeasures
        <bcp14>MAY</bcp14> also be included. The same attributes as those defined in <xref target="attackdetails" format="default" sectionFormat="of" derivedContent="Section 8.1.5"/> are applicable for describing the
        attacks detected and mitigated at the DOTS server domain.</t>
        <t indent="0" pn="section-9.2-5">The "ietf-dots-telemetry" YANG module (<xref target="module" format="default" sectionFormat="of" derivedContent="Section 11.1"/>) augments the 'mitigation-scope' message type
        defined in the "ietf-dots-signal-channel" module <xref target="RFC9132" format="default" sectionFormat="of" derivedContent="RFC9132"/> with
        telemetry data as depicted in <xref target="miscope" format="default" sectionFormat="of" derivedContent="Figure 46"/>.</t>
        <figure anchor="miscope" align="left" suppress-title="false" pn="figure-46">
          <name slugifiedName="name-dots-server-to-client-mitig">DOTS Server-to-Client Mitigation Status Telemetry Tree Structure</name>
          <sourcecode name="" type="yangtree" markers="false" pn="section-9.2-6.1">  augment-structure /dots-signal:dots-signal/dots-signal:message-type
                    /dots-signal:mitigation-scope/dots-signal:scope:
    +-- (direction)?
    |  +--:(server-to-client-only)
    |     +-- total-traffic* [unit]
    |     |  +-- unit                 unit
    |     |  +-- low-percentile-g?    yang:gauge64
    |     |  +-- mid-percentile-g?    yang:gauge64
    |     |  +-- high-percentile-g?   yang:gauge64
    |     |  +-- peak-g?              yang:gauge64
    |     |  +-- current-g?           yang:gauge64
    |     +-- total-attack-connection
    |        +-- connection-c
    |        |  +-- low-percentile-g?    yang:gauge64
    |        |  +-- mid-percentile-g?    yang:gauge64
    |        |  +-- high-percentile-g?   yang:gauge64
    |        |  +-- peak-g?              yang:gauge64
    |        |  +-- current-g?           yang:gauge64
    |        +-- embryonic-c
    |        |  ...
    |        +-- connection-ps-c
    |        |  ...
    |        +-- request-ps-c
    |        |  ...
    |        +-- partial-request-c
    |           ...
    +-- total-attack-traffic* [unit]
    |  +-- unit                 unit
    |  +-- low-percentile-g?    yang:gauge64
    |  +-- mid-percentile-g?    yang:gauge64
    |  +-- high-percentile-g?   yang:gauge64
    |  +-- peak-g?              yang:gauge64
    |  +-- current-g?           yang:gauge64
    +-- attack-detail* [vendor-id attack-id]
       +-- vendor-id             uint32
       +-- attack-id             uint32
       +-- attack-description?   string
       +-- attack-severity?      attack-severity
       +-- start-time?           uint64
       +-- end-time?             uint64
       +-- source-count
       |  +-- low-percentile-g?    yang:gauge64
       |  +-- mid-percentile-g?    yang:gauge64
       |  +-- high-percentile-g?   yang:gauge64
       |  +-- peak-g?              yang:gauge64
       |  +-- current-g?           yang:gauge64
       +-- top-talker
          +-- talker* [source-prefix]
             +-- spoofed-status?            boolean
             +-- source-prefix              inet:ip-prefix
             +-- source-port-range* [lower-port]
             |  +-- lower-port    inet:port-number
             |  +-- upper-port?   inet:port-number
             +-- source-icmp-type-range* [lower-type]
             |  +-- lower-type    uint8
             |  +-- upper-type?   uint8
             +-- total-attack-traffic* [unit]
             |  +-- unit                 unit
             |  +-- low-percentile-g?    yang:gauge64
             |  +-- mid-percentile-g?    yang:gauge64
             |  +-- high-percentile-g?   yang:gauge64
             |  +-- peak-g?              yang:gauge64
             |  +-- current-g?           yang:gauge64
             +-- total-attack-connection
                +-- connection-c
                |  +-- low-percentile-g?    yang:gauge64
                |  +-- mid-percentile-g?    yang:gauge64
                |  +-- high-percentile-g?   yang:gauge64
                |  +-- peak-g?              yang:gauge64
                |  +-- current-g?           yang:gauge64
                +-- embryonic-c
                |  ...
                +-- connection-ps-c
                |  ...
                +-- request-ps-c
                |  ...
                +-- partial-request-c
                   ...
</sourcecode>
        </figure>
        <t indent="0" pn="section-9.2-7"><xref target="upex" format="default" sectionFormat="of" derivedContent="Figure 47"/> shows an example of an asynchronous
        notification of attack mitigation status from the DOTS server. This
        notification signals both the mid-percentile value of processed attack
        traffic and the peak count of unique sources involved in the
        attack.</t>
        <figure anchor="upex" align="left" suppress-title="false" pn="figure-47">
          <name slugifiedName="name-response-body-of-a-mitigati">Response Body of a Mitigation Status with Telemetry Attributes, Depicted as per Section 5.6</name>
          <artwork name="" type="" align="left" alt="" pn="section-9.2-8.1">{
  "ietf-dots-signal-channel:mitigation-scope": {
    "scope": [
      {
        "mid": 12332,
        "mitigation-start": "1507818434",
        "alias-name": [
          "https1",
          "https2"
        ],
        "lifetime": 1600,
        "status": "attack-successfully-mitigated",
        "bytes-dropped": "134334555",
        "bps-dropped": "43344",
        "pkts-dropped": "333334444",
        "pps-dropped": "432432",
        "ietf-dots-telemetry:total-attack-traffic": [
          {
            "unit": "megabit-ps",
            "mid-percentile-g": "752"
          }
        ],
        "ietf-dots-telemetry:attack-detail": [
          {
            "vendor-id": 32473,
            "attack-id": 77,
            "source-count": {
              "peak-g": "12683"
            }
          }
        ]
      }
    ]
  }
}
</artwork>
        </figure>
        <t indent="0" pn="section-9.2-9">DOTS clients can filter out the asynchronous notifications from the
        DOTS server by indicating one or more Uri-Query options in its GET
        request. A Uri-Query option can include the following parameters:
        'target-prefix', 'target-port', 'target-protocol', 'target-fqdn',
        'target-uri', 'alias-name', and 'c' (content) (<xref target="control" format="default" sectionFormat="of" derivedContent="Section 5.4"/>). The considerations discussed in <xref target="preStoC" format="default" sectionFormat="of" derivedContent="Section 8.3"/> <bcp14>MUST</bcp14> be followed to include multiple query
        values, ranges ('target-port', 'target-protocol'), and wildcard names
        ('target-fqdn', 'target-uri').</t>
        <t indent="0" pn="section-9.2-10">An example of a request to subscribe to asynchronous notifications
        bound to the "https1" alias is shown in <xref target="notif_filter" format="default" sectionFormat="of" derivedContent="Figure 48"/>.</t>
        <figure anchor="notif_filter" align="left" suppress-title="false" pn="figure-48">
          <name slugifiedName="name-get-request-to-receive-asyn">GET Request to Receive Asynchronous Notifications 
Filtered Using Uri-⁠Query</name>
          <sourcecode name="" type="json" markers="false" pn="section-9.2-11.1">Header: GET (Code=0.01)
Uri-Path: ".well-known"
Uri-Path: "dots"
Uri-Path: "mitigate"
Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
Uri-Path: "mid=12332"
Uri-Query: "target-alias=https1"
Observe: 0
</sourcecode>
        </figure>
        <t indent="0" pn="section-9.2-12">If the target query does not match the target of the enclosed 'mid'
        as maintained by the DOTS server, the latter <bcp14>MUST</bcp14> respond with a 4.04
        (Not Found) error Response Code. The DOTS server <bcp14>MUST NOT</bcp14> add a new
        Observe entry if this query overlaps with an existing Observe entry. In such a
        case, the DOTS server replies with a 4.09 (Conflict) Response Code.</t>
      </section>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-10">
      <name slugifiedName="name-error-handling">Error Handling</name>
      <t indent="0" pn="section-10-1">A list of common CoAP errors that are implemented by DOTS servers is
      provided in <xref target="RFC9132" sectionFormat="of" section="9" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9132#section-9" derivedContent="RFC9132"/>. The following
      additional error cases apply for the telemetry extension:</t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-10-2">
        <li pn="section-10-2.1">4.00 (Bad Request) is returned by the DOTS server when the DOTS
          client has sent a request that violates the DOTS telemetry
          extension.</li>
        <li pn="section-10-2.2">4.04 (Not Found) is returned by the DOTS server when the DOTS
          client is requesting a 'tsid' or 'tmid' that is not valid.</li>
        <li pn="section-10-2.3">4.00 (Bad Request) is returned by the DOTS server when the DOTS
          client has sent a request with invalid query types (e.g., not
          supported, malformed).</li>
        <li pn="section-10-2.4">4.04 (Not Found) is returned by the DOTS server when the DOTS
          client has sent a request with a target query that does not match
          the target of the enclosed 'mid' as maintained by the DOTS
          server.</li>
      </ul>
      <t indent="0" pn="section-10-3">As indicated in <xref target="RFC9132" sectionFormat="of" section="9" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9132#section-9" derivedContent="RFC9132"/>, an
      additional plaintext diagnostic payload (<xref target="RFC7252" sectionFormat="of" section="5.5.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7252#section-5.5.2" derivedContent="RFC7252"/>) to help with troubleshooting is returned in the
      body of the response.</t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-11">
      <name slugifiedName="name-yang-modules">YANG Modules</name>
      <section anchor="module" numbered="true" toc="include" removeInRFC="false" pn="section-11.1">
        <name slugifiedName="name-dots-signal-channel-telemet">DOTS Signal Channel Telemetry YANG Module</name>
        <t indent="0" pn="section-11.1-1">This module uses types defined in <xref target="RFC6991" format="default" sectionFormat="of" derivedContent="RFC6991"/> and <xref target="RFC8345" format="default" sectionFormat="of" derivedContent="RFC8345"/>. It also reuses a grouping from <xref target="RFC8783" format="default" sectionFormat="of" derivedContent="RFC8783"/>.</t>
        <sourcecode name="ietf-dots-telemetry@2022-06-20.yang" type="yang" markers="true" pn="section-11.1-2">
module ietf-dots-telemetry {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-dots-telemetry";
  prefix dots-telemetry;

  import ietf-dots-signal-channel {
    prefix dots-signal;
    reference
      "RFC 9132: Distributed Denial-of-Service Open Threat
                 Signaling (DOTS) Signal Channel Specification";
  }
  import ietf-dots-data-channel {
    prefix data-channel;
    reference
      "RFC 8783: Distributed Denial-of-Service Open Threat
                 Signaling (DOTS) Data Channel Specification";
  }
  import ietf-yang-types {
    prefix yang;
    reference
      "RFC 6991: Common YANG Data Types, Section 3";
  }
  import ietf-inet-types {
    prefix inet;
    reference
      "RFC 6991: Common YANG Data Types, Section 4";
  }
  import ietf-network-topology {
    prefix nt;
    reference
      "RFC 8345: A YANG Data Model for Network Topologies,
                 Section 6.2";
  }
  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:   Konda, Tirumaleswar Reddy.K
               &lt;mailto:kondtir@gmail.com&gt;";
  description
    "This module contains YANG definitions for the signaling
     of DOTS telemetry data exchanged between a DOTS client and
     a DOTS server by means of the DOTS signal channel.

     Copyright (c) 2022 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 9244; see the
     RFC itself for full legal notices.";

  revision 2022-06-20 {
    description
      "Initial revision.";
    reference
      "RFC 9244: Distributed Denial-of-Service Open Threat
                 Signaling (DOTS) Telemetry";
  }

  typedef attack-severity {
    type enumeration {
      enum none {
        value 1;
        description
          "No effect on the DOTS client domain.";
      }
      enum low {
        value 2;
        description
          "Minimal effect on the DOTS client domain.";
      }
      enum medium {
        value 3;
        description
          "A subset of DOTS client domain resources is
           out of service.";
      }
      enum high {
        value 4;
        description
          "The DOTS client domain is under extremely severe
           conditions.";
      }
      enum unknown {
        value 5;
        description
          "The impact of the attack is not known.";
      }
    }
    description
      "Enumeration for attack severity.";
    reference
      "RFC 7970: The Incident Object Description Exchange
                 Format Version 2, Section 3.12.2";
  }

  typedef unit-class {
    type enumeration {
      enum packet-ps {
        value 1;
        description
          "Packets per second (pps).";
      }
      enum bit-ps {
        value 2;
        description
          "Bits per second (bps).";
      }
      enum byte-ps {
        value 3;
        description
          "Bytes per second (Bps).";
      }
    }
    description
      "Enumeration to indicate which unit class is used.
       These classes are supported: pps, bps, and Bps.";
  }

  typedef unit {
    type enumeration {
      enum packet-ps {
        value 1;
        description
          "Packets per second (pps).";
      }
      enum bit-ps {
        value 2;
        description
          "Bits per second (bps).";
      }
      enum byte-ps {
        value 3;
        description
          "Bytes per second (Bps).";
      }
      enum kilopacket-ps {
        value 4;
        description
          "Kilo packets per second (kpps).";
      }
      enum kilobit-ps {
        value 5;
        description
          "Kilobits per second (kbps).";
      }
      enum kilobyte-ps {
        value 6;
        description
          "Kilobytes per second (kBps).";
      }
      enum megapacket-ps {
        value 7;
        description
          "Mega packets per second (Mpps).";
      }
      enum megabit-ps {
        value 8;
        description
          "Megabits per second (Mbps).";
      }
      enum megabyte-ps {
        value 9;
        description
          "Megabytes per second (MBps).";
      }
      enum gigapacket-ps {
        value 10;
        description
          "Giga packets per second (Gpps).";
      }
      enum gigabit-ps {
        value 11;
        description
          "Gigabits per second (Gbps).";
      }
      enum gigabyte-ps {
        value 12;
        description
          "Gigabytes per second (GBps).";
      }
      enum terapacket-ps {
        value 13;
        description
          "Tera packets per second (Tpps).";
      }
      enum terabit-ps {
        value 14;
        description
          "Terabits per second (Tbps).";
      }
      enum terabyte-ps {
        value 15;
        description
          "Terabytes per second (TBps).";
      }
      enum petapacket-ps {
        value 16;
        description
          "Peta packets per second (Ppps).";
      }
      enum petabit-ps {
        value 17;
        description
          "Petabits per second (Pbps).";
      }
      enum petabyte-ps {
        value 18;
        description
          "Petabytes per second (PBps).";
      }
      enum exapacket-ps {
        value 19;
        description
          "Exa packets per second (Epps).";
      }
      enum exabit-ps {
        value 20;
        description
          "Exabits per second (Ebps).";
      }
      enum exabyte-ps {
        value 21;
        description
          "Exabytes per second (EBps).";
      }
      enum zettapacket-ps {
        value 22;
        description
          "Zetta packets per second (Zpps).";
      }
      enum zettabit-ps {
        value 23;
        description
          "Zettabits per second (Zbps).";
      }
      enum zettabyte-ps {
        value 24;
        description
          "Zettabytes per second (ZBps).";
      }
    }
    description
      "Enumeration to indicate which unit is used.
       Only one unit per unit class is used owing to
       unit auto-scaling.";
  }

  typedef interval {
    type enumeration {
      enum 5-minutes {
        value 1;
        description
          "5 minutes.";
      }
      enum 10-minutes {
        value 2;
        description
          "10 minutes.";
      }
      enum 30-minutes {
        value 3;
        description
          "30 minutes.";
      }
      enum hour {
        value 4;
        description
          "Hour.";
      }
      enum day {
        value 5;
        description
          "Day.";
      }
      enum week {
        value 6;
        description
          "Week.";
      }
      enum month {
        value 7;
        description
          "Month.";
      }
    }
    description
      "Enumeration to indicate the overall measurement period.";
  }

  typedef sample {
    type enumeration {
      enum second {
        value 1;
        description
          "One-second measurement period.";
      }
      enum 5-seconds {
        value 2;
        description
          "5-second measurement period.";
      }
      enum 30-seconds {
        value 3;
        description
          "30-second measurement period.";
      }
      enum minute {
        value 4;
        description
          "One-minute measurement period.";
      }
      enum 5-minutes {
        value 5;
        description
          "5-minute measurement period.";
      }
      enum 10-minutes {
        value 6;
        description
          "10-minute measurement period.";
      }
      enum 30-minutes {
        value 7;
        description
          "30-minute measurement period.";
      }
      enum hour {
        value 8;
        description
          "One-hour measurement period.";
      }
    }
    description
      "Enumeration to indicate the sampling period.";
  }

  typedef percentile {
    type decimal64 {
      fraction-digits 2;
    }
    description
      "The nth percentile of a set of data is the
       value at which n percent of the data is below it.";
  }

  typedef query-type {
    type enumeration {
      enum target-prefix {
        value 1;
        description
          "Query based on target prefix.";
      }
      enum target-port {
        value 2;
        description
          "Query based on target port number.";
      }
      enum target-protocol {
        value 3;
        description
          "Query based on target protocol.";
      }
      enum target-fqdn {
        value 4;
        description
          "Query based on target FQDN.";
      }
      enum target-uri {
        value 5;
        description
          "Query based on target URI.";
      }
      enum target-alias {
        value 6;
        description
          "Query based on target alias.";
      }
      enum mid {
        value 7;
        description
          "Query based on mitigation identifier (mid).";
      }
      enum source-prefix {
        value 8;
        description
          "Query based on source prefix.";
      }
      enum source-port {
        value 9;
        description
          "Query based on source port number.";
      }
      enum source-icmp-type {
        value 10;
        description
          "Query based on ICMP type.";
      }
      enum content {
        value 11;
        description
          "Query based on the 'c' (content) Uri-Query option,
           which is used to control the selection of configuration
           and non-configuration data nodes.";
        reference
          "RFC 9132: Distributed Denial-of-Service Open Threat
                     Signaling (DOTS) Signal Channel
                     Specification, Section 4.4.2";
      }
    }
    description
      "Enumeration of support for query types that can be used
       in a GET request to filter out data.  Requests with
       invalid query types (e.g., not supported, malformed)
       received by the DOTS server are rejected with
       a 4.00 (Bad Request) Response Code.";
  }

  grouping telemetry-parameters {
    description
      "A grouping that includes a set of parameters that
       are used to prepare the reported telemetry data.

       The grouping indicates a measurement interval,
       a measurement sample period, and
       low-percentile/mid-percentile/high-percentile values.";
    leaf measurement-interval {
      type interval;
      description
        "Defines the period during which percentiles are
         computed.";
    }
    leaf measurement-sample {
      type sample;
      description
        "Defines the time distribution for measuring
         values that are used to compute percentiles.

         The measurement sample value must be less than the
         measurement interval value.";
    }
    leaf low-percentile {
      type percentile;
      default "10.00";
      description
        "Low-percentile.  If set to '0', this means that
         the use of low-percentile values is disabled.";
    }
    leaf mid-percentile {
      type percentile;
      must '. &gt;= ../low-percentile' {
        error-message
          "The mid-percentile must be greater than
           or equal to the low-percentile.";
      }
      default "50.00";
      description
        "Mid-percentile.  If set to the same value as
         'low-percentile', this means that the use of
         mid-percentile values is disabled.";
    }
    leaf high-percentile {
      type percentile;
      must '. &gt;= ../mid-percentile' {
        error-message
          "The high-percentile must be greater than
           or equal to the mid-percentile.";
      }
      default "90.00";
      description
        "High-percentile.  If set to the same value as
         'mid-percentile', this means that the use of
         high-percentile values is disabled.";
    }
  }

  grouping percentile-and-peak {
    description
      "Generic grouping for percentile and peak values.";
    leaf low-percentile-g {
      type yang:gauge64;
      description
        "Low-percentile value.";
    }
    leaf mid-percentile-g {
      type yang:gauge64;
      description
        "Mid-percentile value.";
    }
    leaf high-percentile-g {
      type yang:gauge64;
      description
        "High-percentile value.";
    }
    leaf peak-g {
      type yang:gauge64;
      description
        "Peak value.";
    }
  }

  grouping percentile-peak-and-current {
    description
      "Generic grouping for percentile and peak values.";
    uses percentile-and-peak;
    leaf current-g {
      type yang:gauge64;
      description
        "Current value.";
    }
  }

  grouping unit-config {
    description
      "Generic grouping for unit configuration.";
    list unit-config {
      key "unit";
      description
        "Controls which unit classes are allowed when sharing
         telemetry data.";
      leaf unit {
        type unit-class;
        description
          "Can be 'packet-ps', 'bit-ps', or 'byte-ps'.";
      }
      leaf unit-status {
        type boolean;
        mandatory true;
        description
          "Enable/disable the use of the measurement unit class.";
      }
    }
  }

  grouping traffic-unit {
    description
      "Grouping of traffic as a function of the
       measurement unit.";
    leaf unit {
      type unit;
      description
        "The traffic can be measured using unit classes:
         'packet-ps', 'bit-ps', or 'byte-ps'.  DOTS agents
         auto-scale to the appropriate units (e.g., 'megabit-ps',
         'kilobit-ps').";
    }
    uses percentile-and-peak;
  }

  grouping traffic-unit-all {
    description
      "Grouping of traffic as a function of the measurement unit,
       including current values.";
    uses traffic-unit;
    leaf current-g {
      type yang:gauge64;
      description
        "Current observed value.";
    }
  }

  grouping traffic-unit-protocol {
    description
      "Grouping of traffic of a given transport protocol as
       a function of the measurement unit.";
    leaf protocol {
      type uint8;
      description
        "The transport protocol.
         Values are taken from the IANA 'Protocol Numbers'
         registry:
         &lt;https://www.iana.org/assignments/protocol-numbers/&gt;.

         For example, this parameter contains 6 for TCP,
         17 for UDP, 33 for the Datagram Congestion Control
         Protocol (DCCP), or 132 for the Stream Control
         Transmission Protocol (SCTP).";
    }
    uses traffic-unit;
  }

  grouping traffic-unit-protocol-all {
    description
      "Grouping of traffic of a given transport protocol as
       a function of the measurement unit, including current
       values.";
    uses traffic-unit-protocol;
    leaf current-g {
      type yang:gauge64;
      description
        "Current observed value.";
    }
  }

  grouping traffic-unit-port {
    description
      "Grouping of traffic bound to a port number as
       a function of the measurement unit.";
    leaf port {
      type inet:port-number;
      description
        "Port number used by a transport protocol.";
    }
    uses traffic-unit;
  }

  grouping traffic-unit-port-all {
    description
      "Grouping of traffic bound to a port number as
       a function of the measurement unit, including
       current values.";
    uses traffic-unit-port;
    leaf current-g {
      type yang:gauge64;
      description
        "Current observed value.";
    }
  }

  grouping total-connection-capacity {
    description
      "Total connection capacities for various types of
       connections, as well as overall capacity.  These data nodes
       are useful for detecting resource-consuming DDoS attacks.";
    leaf connection {
      type uint64;
      description
        "The maximum number of simultaneous connections that
         are allowed to the target server.";
    }
    leaf connection-client {
      type uint64;
      description
        "The maximum number of simultaneous connections that
         are allowed to the target server per client.";
    }
    leaf embryonic {
      type uint64;
      description
        "The maximum number of simultaneous embryonic connections
         that are allowed to the target server.  The term
         'embryonic connection' refers to a connection whose
         connection handshake is not finished.  Embryonic
         connections are only possible in connection-oriented
         transport protocols like TCP or SCTP.";
    }
    leaf embryonic-client {
      type uint64;
      description
        "The maximum number of simultaneous embryonic connections
         that are allowed to the target server per client.";
    }
    leaf connection-ps {
      type uint64;
      description
        "The maximum number of new connections allowed per second
         to the target server.";
    }
    leaf connection-client-ps {
      type uint64;
      description
        "The maximum number of new connections allowed per second
         to the target server per client.";
    }
    leaf request-ps {
      type uint64;
      description
        "The maximum number of requests allowed per second
         to the target server.";
    }
    leaf request-client-ps {
      type uint64;
      description
        "The maximum number of requests allowed per second
         to the target server per client.";
    }
    leaf partial-request-max {
      type uint64;
      description
        "The maximum number of outstanding partial requests
         that are allowed to the target server.";
    }
    leaf partial-request-client-max {
      type uint64;
      description
        "The maximum number of outstanding partial requests
         that are allowed to the target server per client.";
    }
  }

  grouping total-connection-capacity-protocol {
    description
      "Total connection capacity per protocol.  These data nodes
       are useful for detecting resource-consuming DDoS attacks.";
    leaf protocol {
      type uint8;
      description
        "The transport protocol.
         Values are taken from the IANA 'Protocol Numbers'
         registry:
         &lt;https://www.iana.org/assignments/protocol-numbers/&gt;.";
    }
    uses total-connection-capacity;
  }

  grouping connection-percentile-and-peak {
    description
      "A set of data nodes that represent the attack
       characteristics.";
    container connection-c {
      uses percentile-and-peak;
      description
        "The number of simultaneous attack connections to
         the target server.";
    }
    container embryonic-c {
      uses percentile-and-peak;
      description
        "The number of simultaneous embryonic connections to
         the target server.";
    }
    container connection-ps-c {
      uses percentile-and-peak;
      description
        "The number of attack connections per second to
         the target server.";
    }
    container request-ps-c {
      uses percentile-and-peak;
      description
        "The number of attack requests per second to
         the target server.";
    }
    container partial-request-c {
      uses percentile-and-peak;
      description
        "The number of attack partial requests to
         the target server.";
    }
  }

  grouping connection-all {
    description
      "Total attack connections, including current values.";
    container connection-c {
      uses percentile-peak-and-current;
      description
        "The number of simultaneous attack connections to
         the target server.";
    }
    container embryonic-c {
      uses percentile-peak-and-current;
      description
        "The number of simultaneous embryonic connections to
         the target server.";
    }
    container connection-ps-c {
      uses percentile-peak-and-current;
      description
        "The number of attack connections per second to
         the target server.";
    }
    container request-ps-c {
      uses percentile-peak-and-current;
      description
        "The number of attack requests per second to
         the target server.";
    }
    container partial-request-c {
      uses percentile-peak-and-current;
      description
        "The number of attack partial requests to
         the target server.";
    }
  }

  grouping connection-protocol {
    description
      "Total attack connections.";
    leaf protocol {
      type uint8;
      description
        "The transport protocol.
         Values are taken from the IANA 'Protocol Numbers'
         registry:
         &lt;https://www.iana.org/assignments/protocol-numbers/&gt;.";
    }
    uses connection-percentile-and-peak;
  }

  grouping connection-port {
    description
      "Total attack connections per port number.";
    leaf protocol {
      type uint8;
      description
        "The transport protocol.
         Values are taken from the IANA 'Protocol Numbers'
         registry:
         &lt;https://www.iana.org/assignments/protocol-numbers/&gt;.";
    }
    leaf port {
      type inet:port-number;
      description
        "Port number.";
    }
    uses connection-percentile-and-peak;
  }

  grouping connection-protocol-all {
    description
      "Total attack connections per protocol, including current
       values.";
    leaf protocol {
      type uint8;
      description
        "The transport protocol.
         Values are taken from the IANA 'Protocol Numbers'
         registry:
         &lt;https://www.iana.org/assignments/protocol-numbers/&gt;.";
    }
    uses connection-all;
  }

  grouping connection-protocol-port-all {
    description
      "Total attack connections per port number, including current
       values.";
    leaf protocol {
      type uint8;
      description
        "The transport protocol.
         Values are taken from the IANA 'Protocol Numbers'
         registry:
         &lt;https://www.iana.org/assignments/protocol-numbers/&gt;.";
    }
    leaf port {
      type inet:port-number;
      description
        "Port number.";
    }
    uses connection-all;
  }

  grouping attack-detail {
    description
      "Various details that describe the ongoing
       attacks that need to be mitigated by the DOTS server.
       The attack details need to cover well-known and common
       attacks (such as a SYN flood) along with new emerging or
       vendor-specific attacks.";
    leaf vendor-id {
      type uint32;
      description
        "The Vendor ID is a security vendor's Private Enterprise
         Number as registered with IANA.";
      reference
        "IANA: Private Enterprise Numbers
         (https://www.iana.org/assignments/enterprise-numbers/)";
    }
    leaf attack-id {
      type uint32;
      description
        "Unique identifier assigned by the vendor for the attack.";
    }
    leaf description-lang {
      type string {
        pattern '((([A-Za-z]{2,3}(-[A-Za-z]{3}(-[A-Za-z]{3})'
              + '{0,2})?)|[A-Za-z]{4}|[A-Za-z]{5,8})(-[A-Za-z]{4})'
              + '?(-([A-Za-z]{2}|[0-9]{3}))?(-([A-Za-z0-9]{5,8}'
              + '|([0-9][A-Za-z0-9]{3})))*(-[0-9A-WYZa-wyz]'
              + '(-([A-Za-z0-9]{2,8}))+)*(-[Xx](-([A-Za-z0-9]'
              + '{1,8}))+)?|[Xx](-([A-Za-z0-9]{1,8}))+|'
              + '(([Ee][Nn]-[Gg][Bb]-[Oo][Ee][Dd]|[Ii]-'
              + '[Aa][Mm][Ii]|[Ii]-[Bb][Nn][Nn]|[Ii]-'
              + '[Dd][Ee][Ff][Aa][Uu][Ll][Tt]|[Ii]-'
              + '[Ee][Nn][Oo][Cc][Hh][Ii][Aa][Nn]'
              + '|[Ii]-[Hh][Aa][Kk]|'
              + '[Ii]-[Kk][Ll][Ii][Nn][Gg][Oo][Nn]|'
              + '[Ii]-[Ll][Uu][Xx]|[Ii]-[Mm][Ii][Nn][Gg][Oo]|'
              + '[Ii]-[Nn][Aa][Vv][Aa][Jj][Oo]|[Ii]-[Pp][Ww][Nn]|'
              + '[Ii]-[Tt][Aa][Oo]|[Ii]-[Tt][Aa][Yy]|'
              + '[Ii]-[Tt][Ss][Uu]|[Ss][Gg][Nn]-[Bb][Ee]-[Ff][Rr]|'
              + '[Ss][Gg][Nn]-[Bb][Ee]-[Nn][Ll]|[Ss][Gg][Nn]-'
              + '[Cc][Hh]-[Dd][Ee])|([Aa][Rr][Tt]-'
              + '[Ll][Oo][Jj][Bb][Aa][Nn]|[Cc][Ee][Ll]-'
              + '[Gg][Aa][Uu][Ll][Ii][Ss][Hh]|'
              + '[Nn][Oo]-[Bb][Oo][Kk]|[Nn][Oo]-'
              + '[Nn][Yy][Nn]|[Zz][Hh]-[Gg][Uu][Oo][Yy][Uu]|'
              + '[Zz][Hh]-[Hh][Aa][Kk][Kk][Aa]|[Zz][Hh]-'
              + '[Mm][Ii][Nn]|[Zz][Hh]-[Mm][Ii][Nn]-'
              + '[Nn][Aa][Nn]|[Zz][Hh]-[Xx][Ii][Aa][Nn][Gg])))';
      }
      default "en-US";
      description
        "Indicates the language tag that is used for
         'attack-description'.";
      reference
        "RFC 5646: Tags for Identifying Languages, Section 2.1";
    }
    leaf attack-description {
      type string;
      description
        "Textual representation of the attack description.
         Natural Language Processing techniques (e.g.,
         word embedding) might provide some utility in mapping
         the attack description to an attack type.";
    }
    leaf attack-severity {
      type attack-severity;
      description
        "Severity level of an attack.  How this level is
         determined is implementation specific.";
    }
    leaf start-time {
      type uint64;
      description
        "The time the attack started.  The start time is
         represented in seconds relative to
         1970-01-01T00:00:00Z.";
    }
    leaf end-time {
      type uint64;
      description
        "The time the attack ended.  The end time is represented
         in seconds relative to 1970-01-01T00:00:00Z.";
    }
    container source-count {
      description
        "Indicates the count of unique sources involved
         in the attack.";
      uses percentile-and-peak;
      leaf current-g {
        type yang:gauge64;
        description
          "Current observed value.";
      }
    }
  }

  grouping talker {
    description
      "Defines generic data related to top talkers.";
    leaf spoofed-status {
      type boolean;
      description
        "When set to 'true', it indicates whether this address
         is spoofed.";
    }
    leaf source-prefix {
      type inet:ip-prefix;
      description
        "IPv4 or IPv6 prefix identifying the attacker(s).";
    }
    list source-port-range {
      key "lower-port";
      description
        "Port range.  When only 'lower-port' is
         present, it represents a single port number.";
      leaf lower-port {
        type inet:port-number;
        description
          "Lower port number of the port range.";
      }
      leaf upper-port {
        type inet:port-number;
        must '. &gt;= ../lower-port' {
          error-message
            "The upper port number must be greater than
             or equal to the lower port number.";
        }
        description
          "Upper port number of the port range.";
      }
    }
    list source-icmp-type-range {
      key "lower-type";
      description
        "ICMP type range.  When only 'lower-type' is
         present, it represents a single ICMP type.";
      leaf lower-type {
        type uint8;
        description
          "Lower ICMP type of the ICMP type range.";
      }
      leaf upper-type {
        type uint8;
        must '. &gt;= ../lower-type' {
          error-message
            "The upper ICMP type must be greater than
             or equal to the lower ICMP type.";
        }
        description
          "Upper type of the ICMP type range.";
      }
    }
    list total-attack-traffic {
      key "unit";
      description
        "Total attack traffic issued from this source.";
      uses traffic-unit-all;
    }
  }

  grouping top-talker-aggregate {
    description
      "An aggregate of top attack sources.  This aggregate is
       typically used when included in a mitigation request.";
    list talker {
      key "source-prefix";
      description
        "Refers to a top talker that is identified by an IPv4
         or IPv6 prefix identifying the attacker(s).";
      uses talker;
      container total-attack-connection {
        description
          "Total attack connections issued from this source.";
        uses connection-all;
      }
    }
  }

  grouping top-talker {
    description
      "Top attack sources with detailed per-protocol
       structure.";
    list talker {
      key "source-prefix";
      description
        "Refers to a top talker that is identified by an IPv4
         or IPv6 prefix identifying the attacker(s).";
      uses talker;
      list total-attack-connection-protocol {
        key "protocol";
        description
          "Total attack connections issued from this source.";
        uses connection-protocol-all;
      }
    }
  }

  grouping baseline {
    description
      "Grouping for the telemetry baseline.";
    uses data-channel:target;
    leaf-list alias-name {
      type string;
      description
        "An alias name that points to an IP resource.
         An IP resource can be a router, a host,
         an Internet of Things (IoT) object, a server, etc.";
    }
    list total-traffic-normal {
      key "unit";
      description
        "Total traffic normal baselines.";
      uses traffic-unit;
    }
    list total-traffic-normal-per-protocol {
      key "unit protocol";
      description
        "Total traffic normal baselines per protocol.";
      uses traffic-unit-protocol;
    }
    list total-traffic-normal-per-port {
      key "unit port";
      description
        "Total traffic normal baselines per port number.";
      uses traffic-unit-port;
    }
    list total-connection-capacity {
      key "protocol";
      description
        "Total connection capacity.";
      uses total-connection-capacity-protocol;
    }
    list total-connection-capacity-per-port {
      key "protocol port";
      description
        "Total connection capacity per port number.";
      leaf port {
        type inet:port-number;
        description
          "The target port number.";
      }
      uses total-connection-capacity-protocol;
    }
  }

  grouping pre-or-ongoing-mitigation {
    description
      "Grouping for the telemetry data.";
    list total-traffic {
      key "unit";
      description
        "Total traffic.";
      uses traffic-unit-all;
    }
    list total-traffic-protocol {
      key "unit protocol";
      description
        "Total traffic per protocol.";
      uses traffic-unit-protocol-all;
    }
    list total-traffic-port {
      key "unit port";
      description
        "Total traffic per port number.";
      uses traffic-unit-port-all;
    }
    list total-attack-traffic {
      key "unit";
      description
        "Total attack traffic.";
      uses traffic-unit-all;
    }
    list total-attack-traffic-protocol {
      key "unit protocol";
      description
        "Total attack traffic per protocol.";
      uses traffic-unit-protocol-all;
    }
    list total-attack-traffic-port {
      key "unit port";
      description
        "Total attack traffic per port number.";
      uses traffic-unit-port-all;
    }
    list total-attack-connection-protocol {
      key "protocol";
      description
        "Total attack connections.";
      uses connection-protocol-all;
    }
    list total-attack-connection-port {
      key "protocol port";
      description
        "Total attack connections per target port number.";
      uses connection-protocol-port-all;
    }
    list attack-detail {
      key "vendor-id attack-id";
      description
        "Provides a set of attack details.";
      uses attack-detail;
      container top-talker {
        description
          "Lists the top attack sources.";
        uses top-talker;
      }
    }
  }

  sx:augment-structure "/dots-signal:dots-signal"
                     + "/dots-signal:message-type"
                     + "/dots-signal:mitigation-scope"
                     + "/dots-signal:scope" {
    description
      "Extends mitigation scope with telemetry update data.";
    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 mitigation message
           sent from the server to the client.";
        list total-traffic {
          key "unit";
          description
            "Total traffic.";
          uses traffic-unit-all;
        }
        container total-attack-connection {
          description
            "Total attack connections.";
          uses connection-all;
        }
      }
    }
    list total-attack-traffic {
      key "unit";
      description
        "Total attack traffic.";
      uses traffic-unit-all;
    }
    list attack-detail {
      key "vendor-id attack-id";
      description
        "Attack details.";
      uses attack-detail;
      container top-talker {
        description
          "Top attack sources.";
        uses top-talker-aggregate;
      }
    }
  }
  sx:structure dots-telemetry {
    description
      "Main structure for DOTS telemetry messages.";
    choice telemetry-message-type {
      description
        "Can be 'telemetry-setup' or telemetry data.";
      case telemetry-setup {
        description
          "Indicates that the message is about telemetry setup.";
        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 telemetry message
               sent from the server to the client.";
            container max-config-values {
              description
                "Maximum acceptable configuration values.";
              uses telemetry-parameters;
              leaf server-originated-telemetry {
                type boolean;
                default "false";
                description
                  "Indicates whether the DOTS server can be
                   instructed to send pre-or-ongoing-mitigation
                   telemetry.  If set to 'false' or the data node
                   is not present, this is an indication that
                   the server does not support this capability.";
              }
              leaf telemetry-notify-interval {
                type uint16 {
                  range "1 .. 3600";
                }
                units "seconds";
                must '. &gt;= ../../min-config-values'
                   + '/telemetry-notify-interval' {
                  error-message
                    "The value must be greater than or equal
                     to the 'telemetry-notify-interval' value in
                     the 'min-config-values' attribute";
                }
                description
                  "Minimum number of seconds between successive
                   telemetry notifications.";
              }
            }
            container min-config-values {
              description
                "Minimum acceptable configuration values.";
              uses telemetry-parameters;
              leaf telemetry-notify-interval {
                type uint16 {
                  range "1 .. 3600";
                }
                units "seconds";
                description
                  "Minimum number of seconds between successive
                   telemetry notifications.";
              }
            }
            container supported-unit-classes {
              description
                "Supported unit classes and default activation
                 status.";
              uses unit-config;
            }
            leaf-list supported-query-type {
              type query-type;
              description
                "Indicates which query types are supported by
                 the server.  If the server does not announce
                 the query types it supports, the client will
                 be unable to use any of the potential
                 'query-type' values to reduce the returned data
                 content from the server.";
            }
          }
        }
        list telemetry {
          description
            "The telemetry data per DOTS client.  The keys
             of the list are 'cuid' and 'tsid', but these keys are
             not represented here because these keys are conveyed
             as mandatory Uri-Paths in requests.  Omitting keys
             is compliant with RFC 8791.";
          reference
            "RFC 8791: YANG Data Structure Extensions";
          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 telemetry
                 message sent from the server to the client.";
              leaf tsid {
                type uint32;
                description
                  "A client-assigned identifier for the DOTS
                   telemetry setup data.";
              }
            }
          }
          choice setup-type {
            description
              "Can be a mitigation configuration, a pipe capacity,
               or a baseline message.";
            case telemetry-config {
              description
                "Used to set telemetry parameters such as setting
                 low-, mid-, and high-percentile values.";
              container current-config {
                description
                  "Current telemetry configuration values.";
                uses telemetry-parameters;
                uses unit-config;
                leaf server-originated-telemetry {
                  type boolean;
                  description
                    "Used by a DOTS client to enable/disable
                     whether it requests pre-or-ongoing-mitigation
                     telemetry from the DOTS server.";
                }
                leaf telemetry-notify-interval {
                  type uint16 {
                    range "1 .. 3600";
                  }
                  units "seconds";
                  description
                    "Minimum number of seconds between successive
                     telemetry notifications.";
                }
              }
            }
            case pipe {
              description
                "Total pipe capacity of a DOTS client domain.";
              list total-pipe-capacity {
                key "link-id unit";
                description
                  "Total pipe capacity of a DOTS client domain.";
                leaf link-id {
                  type nt:link-id;
                  description
                    "Identifier of an interconnection link of
                     the DOTS client domain.";
                }
                leaf capacity {
                  type uint64;
                  mandatory true;
                  description
                    "Pipe capacity.  This attribute is mandatory
                     when 'total-pipe-capacity' is included in a
                     message.";
                }
                leaf unit {
                  type unit;
                  description
                    "The traffic can be measured using unit
                     classes: packets per second (pps), bits per
                     second (bps), and/or bytes per second
                     (Bps).

                     For a given unit class, the DOTS agents
                     auto-scale to the appropriate units (e.g.,
                     'megabit-ps', 'kilobit-ps').";
                }
              }
            }
            case baseline {
              description
                "Traffic baseline information related to a DOTS
                 client domain.";
              list baseline {
                key "id";
                description
                  "Traffic baseline information related to a DOTS
                   client domain.";
                leaf id {
                  type uint32;
                  must '. &gt;= 1';
                  description
                    "An identifier that uniquely identifies a
                     baseline entry communicated by a
                     DOTS client.";
                }
                uses baseline;
              }
            }
          }
        }
      }
      case telemetry {
        description
          "Telemetry information.";
        list pre-or-ongoing-mitigation {
          description
            "Pre-or-ongoing-mitigation telemetry per DOTS client.
             The keys of the list are 'cuid' and 'tmid', but these
             keys are not represented here because these keys are
             conveyed as mandatory Uri-Paths in requests.
             Omitting keys is compliant with RFC 8791.";
          reference
            "RFC 8791: YANG Data Structure Extensions";
          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 telemetry
                 message sent from the server to the client.";
              leaf tmid {
                type uint32;
                description
                  "A client-assigned identifier for the DOTS
                   telemetry data.";
              }
            }
          }
          container target {
            description
              "Indicates the target.  At least one of the
               attributes 'target-prefix', 'target-fqdn',
               'target-uri', 'alias-name', or 'mid-list'
               must be present in the target definition.";
            uses data-channel:target;
            leaf-list alias-name {
              type string;
              description
                "An alias name that points to a resource.";
            }
            leaf-list mid-list {
              type uint32;
              description
                "Reference to a list of associated mitigation
                 requests.";
              reference
                "RFC 9132: Distributed Denial-of-Service Open
                           Threat Signaling (DOTS) Signal Channel
                           Specification, Section 4.4.1";
            }
          }
          uses pre-or-ongoing-mitigation;
        }
      }
    }
  }
}
</sourcecode>
      </section>
      <section anchor="data" numbered="true" toc="include" removeInRFC="false" pn="section-11.2">
        <name slugifiedName="name-vendor-attack-mapping-detai">Vendor Attack Mapping Details YANG Module</name>
        <sourcecode name="ietf-dots-mapping@2022-06-20.yang" type="yang" markers="true" pn="section-11.2-1">
module ietf-dots-mapping {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-dots-mapping";
  prefix dots-mapping;

  import ietf-dots-data-channel {
    prefix data-channel;
    reference
      "RFC 8783: Distributed Denial-of-Service Open Threat
                 Signaling (DOTS) Data Channel Specification";
  }

  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:supjps-ietf@jpshallow.com&gt;";
  description
    "This module contains YANG definitions for the sharing
     of DDoS attack mapping details between a DOTS client and
     a DOTS server by means of the DOTS data channel.

     Copyright (c) 2022 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 9244; see the
     RFC itself for full legal notices.";

  revision 2022-06-20 {
    description
      "Initial revision.";
    reference
      "RFC 9244: Distributed Denial-of-Service Open Threat
                 Signaling (DOTS) Telemetry";
  }

  feature dots-telemetry {
    description
      "This feature indicates that DOTS telemetry data can be
       shared between DOTS clients and servers.";
  }

  grouping attack-mapping {
    description
      "A set of information used for sharing vendor attack mapping
       information with a peer.";
    list vendor {
      key "vendor-id";
      description
        "Vendor attack mapping information related to the
         client/server.";
      leaf vendor-id {
        type uint32;
        description
          "The Vendor ID is a security vendor's Private Enterprise
           Number as registered with IANA.";
        reference
          "IANA: Private Enterprise Numbers
           (https://www.iana.org/assignments/enterprise-numbers/)";
      }
      leaf vendor-name {
        type string;
        description
          "The name of the vendor (e.g., company A).";
      }
      leaf description-lang {
        type string {
          pattern '((([A-Za-z]{2,3}(-[A-Za-z]{3}(-[A-Za-z]{3})'
                + '{0,2})?)|[A-Za-z]{4}|[A-Za-z]{5,8})(-[A-Za-z]{4})'
                + '?(-([A-Za-z]{2}|[0-9]{3}))?(-([A-Za-z0-9]{5,8}'
                + '|([0-9][A-Za-z0-9]{3})))*(-[0-9A-WYZa-wyz]'
                + '(-([A-Za-z0-9]{2,8}))+)*(-[Xx](-([A-Za-z0-9]'
                + '{1,8}))+)?|[Xx](-([A-Za-z0-9]{1,8}))+|'
                + '(([Ee][Nn]-[Gg][Bb]-[Oo][Ee][Dd]|[Ii]-'
                + '[Aa][Mm][Ii]|[Ii]-[Bb][Nn][Nn]|[Ii]-'
                + '[Dd][Ee][Ff][Aa][Uu][Ll][Tt]|[Ii]-'
                + '[Ee][Nn][Oo][Cc][Hh][Ii][Aa][Nn]'
                + '|[Ii]-[Hh][Aa][Kk]|'
                + '[Ii]-[Kk][Ll][Ii][Nn][Gg][Oo][Nn]|'
                + '[Ii]-[Ll][Uu][Xx]|[Ii]-[Mm][Ii][Nn][Gg][Oo]|'
                + '[Ii]-[Nn][Aa][Vv][Aa][Jj][Oo]|[Ii]-[Pp][Ww][Nn]|'
                + '[Ii]-[Tt][Aa][Oo]|[Ii]-[Tt][Aa][Yy]|'
                + '[Ii]-[Tt][Ss][Uu]|[Ss][Gg][Nn]-[Bb][Ee]-[Ff][Rr]|'
                + '[Ss][Gg][Nn]-[Bb][Ee]-[Nn][Ll]|[Ss][Gg][Nn]-'
                + '[Cc][Hh]-[Dd][Ee])|([Aa][Rr][Tt]-'
                + '[Ll][Oo][Jj][Bb][Aa][Nn]|[Cc][Ee][Ll]-'
                + '[Gg][Aa][Uu][Ll][Ii][Ss][Hh]|'
                + '[Nn][Oo]-[Bb][Oo][Kk]|[Nn][Oo]-'
                + '[Nn][Yy][Nn]|[Zz][Hh]-[Gg][Uu][Oo][Yy][Uu]|'
                + '[Zz][Hh]-[Hh][Aa][Kk][Kk][Aa]|[Zz][Hh]-'
                + '[Mm][Ii][Nn]|[Zz][Hh]-[Mm][Ii][Nn]-'
                + '[Nn][Aa][Nn]|[Zz][Hh]-[Xx][Ii][Aa][Nn][Gg])))';
          }
        default "en-US";
        description
          "Indicates the language tag that is used for
           'attack-description'.";
        reference
          "RFC 5646: Tags for Identifying Languages, Section 2.1";
      }
      leaf last-updated {
        type uint64;
        mandatory true;
        description
          "The time the mapping table was updated.  It is
           represented in seconds relative to
           1970-01-01T00:00:00Z.";
      }
      list attack-mapping {
        key "attack-id";
        description
          "Attack mapping details.";
        leaf attack-id {
          type uint32;
          description
            "Unique identifier assigned by the vendor for the
             attack.";
        }
        leaf attack-description {
          type string;
          mandatory true;
          description
            "Textual representation of the attack description.
             Natural Language Processing techniques (e.g.,
             word embedding) might provide some utility in
             mapping the attack description to an attack type.";
        }
      }
    }
  }

  augment "/data-channel:dots-data/data-channel:dots-client" {
    if-feature "dots-telemetry";
    description
      "Augments the data channel with a vendor attack
       mapping table of the DOTS client.";
    container vendor-mapping {
      description
        "Used by DOTS clients to share their vendor
         attack mapping information with DOTS servers.";
      uses attack-mapping;
    }
  }

  augment "/data-channel:dots-data/data-channel:capabilities" {
    if-feature "dots-telemetry";
    description
      "Augments the DOTS server capabilities with a
       parameter to indicate whether they can share
       attack mapping details.";
    leaf vendor-mapping-enabled {
      type boolean;
      config false;
      description
        "Indicates that the DOTS server supports sharing
         attack vendor mapping details with DOTS clients.";
    }
  }

  augment "/data-channel:dots-data" {
    if-feature "dots-telemetry";
    description
      "Augments the data channel with a vendor attack
       mapping table of the DOTS server.";
    container vendor-mapping {
      config false;
      description
        "Includes the list of vendor attack mapping details
         that will be shared with DOTS clients upon request.";
      uses attack-mapping;
    }
  }
}
</sourcecode>
      </section>
    </section>
    <section anchor="map1" numbered="true" toc="include" removeInRFC="false" pn="section-12">
      <name slugifiedName="name-yang-json-mapping-parameter">YANG/JSON Mapping Parameters to CBOR</name>
      <t indent="0" pn="section-12-1">All DOTS telemetry parameters in the payload of the DOTS signal
      channel <bcp14>MUST</bcp14> be mapped to CBOR types as shown in <xref target="tab-3" format="default" sectionFormat="of" derivedContent="Table 3"/>:</t>
      <aside pn="section-12-2">
        <t indent="0" pn="section-12-2.1">
          Note: Implementers must check that the mapping output provided by
          their YANG-to-CBOR encoding schemes is aligned with the contents of
          <xref target="tab-3" format="default" sectionFormat="of" derivedContent="Table 3"/>.
        </t>
      </aside>
      <table anchor="tab-3" align="center" pn="table-3">
        <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">tsid</td>
            <td align="left" colspan="1" rowspan="1">uint32</td>
            <td align="left" colspan="1" rowspan="1">128</td>
            <td align="left" colspan="1" rowspan="1">0 unsigned</td>
            <td align="left" colspan="1" rowspan="1">Number</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">telemetry</td>
            <td align="left" colspan="1" rowspan="1">list</td>
            <td align="left" colspan="1" rowspan="1">129</td>
            <td align="left" colspan="1" rowspan="1">4 array</td>
            <td align="left" colspan="1" rowspan="1">Array</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">low-percentile</td>
            <td align="left" colspan="1" rowspan="1">decimal64</td>
            <td align="left" colspan="1" rowspan="1">130</td>
            <td align="left" colspan="1" rowspan="1">6 tag 4 [-2, integer]</td>
            <td align="left" colspan="1" rowspan="1">String</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">mid-percentile</td>
            <td align="left" colspan="1" rowspan="1">decimal64</td>
            <td align="left" colspan="1" rowspan="1">131</td>
            <td align="left" colspan="1" rowspan="1">6 tag 4 [-2, integer]</td>
            <td align="left" colspan="1" rowspan="1">String</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">high-percentile</td>
            <td align="left" colspan="1" rowspan="1">decimal64</td>
            <td align="left" colspan="1" rowspan="1">132</td>
            <td align="left" colspan="1" rowspan="1">6 tag 4 [-2, integer]</td>
            <td align="left" colspan="1" rowspan="1">String</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">unit-config</td>
            <td align="left" colspan="1" rowspan="1">list</td>
            <td align="left" colspan="1" rowspan="1">133</td>
            <td align="left" colspan="1" rowspan="1">4 array</td>
            <td align="left" colspan="1" rowspan="1">Array</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">unit</td>
            <td align="left" colspan="1" rowspan="1">enumeration</td>
            <td align="left" colspan="1" rowspan="1">134</td>
            <td align="left" colspan="1" rowspan="1">0 unsigned</td>
            <td align="left" colspan="1" rowspan="1">String</td>
          </tr>
          <tr>
            <td rowspan="2" align="left" colspan="1">unit-status</td>
            <td rowspan="2" align="left" colspan="1">boolean</td>
            <td rowspan="2" align="left" colspan="1">135</td>
            <td align="left" colspan="1" rowspan="1">7 bits 20</td>
            <td align="left" colspan="1" rowspan="1">False</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">7 bits 21</td>
            <td align="left" colspan="1" rowspan="1">True</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">total-pipe-capacity</td>
            <td align="left" colspan="1" rowspan="1">list</td>
            <td align="left" colspan="1" rowspan="1">136</td>
            <td align="left" colspan="1" rowspan="1">4 array</td>
            <td align="left" colspan="1" rowspan="1">Array</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">link-id</td>
            <td align="left" colspan="1" rowspan="1">string</td>
            <td align="left" colspan="1" rowspan="1">137</td>
            <td align="left" colspan="1" rowspan="1">3 text string</td>
            <td align="left" colspan="1" rowspan="1">String</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">pre-or-ongoing-mitigation</td>
            <td align="left" colspan="1" rowspan="1">list</td>
            <td align="left" colspan="1" rowspan="1">138</td>
            <td align="left" colspan="1" rowspan="1">4 array</td>
            <td align="left" colspan="1" rowspan="1">Array</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">total-traffic-normal</td>
            <td align="left" colspan="1" rowspan="1">list</td>
            <td align="left" colspan="1" rowspan="1">139</td>
            <td align="left" colspan="1" rowspan="1">4 array</td>
            <td align="left" colspan="1" rowspan="1">Array</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">low-percentile-g</td>
            <td align="left" colspan="1" rowspan="1">yang:gauge64</td>
            <td align="left" colspan="1" rowspan="1">140</td>
            <td align="left" colspan="1" rowspan="1">0 unsigned</td>
            <td align="left" colspan="1" rowspan="1">String</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">mid-percentile-g</td>
            <td align="left" colspan="1" rowspan="1">yang:gauge64</td>
            <td align="left" colspan="1" rowspan="1">141</td>
            <td align="left" colspan="1" rowspan="1">0 unsigned</td>
            <td align="left" colspan="1" rowspan="1">String</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">high-percentile-g</td>
            <td align="left" colspan="1" rowspan="1">yang:gauge64</td>
            <td align="left" colspan="1" rowspan="1">142</td>
            <td align="left" colspan="1" rowspan="1">0 unsigned</td>
            <td align="left" colspan="1" rowspan="1">String</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">peak-g</td>
            <td align="left" colspan="1" rowspan="1">yang:gauge64</td>
            <td align="left" colspan="1" rowspan="1">143</td>
            <td align="left" colspan="1" rowspan="1">0 unsigned</td>
            <td align="left" colspan="1" rowspan="1">String</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">total-attack-traffic</td>
            <td align="left" colspan="1" rowspan="1">list</td>
            <td align="left" colspan="1" rowspan="1">144</td>
            <td align="left" colspan="1" rowspan="1">4 array</td>
            <td align="left" colspan="1" rowspan="1">Array</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">total-traffic</td>
            <td align="left" colspan="1" rowspan="1">list</td>
            <td align="left" colspan="1" rowspan="1">145</td>
            <td align="left" colspan="1" rowspan="1">4 array</td>
            <td align="left" colspan="1" rowspan="1">Array</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">total-connection-capacity</td>
            <td align="left" colspan="1" rowspan="1">list</td>
            <td align="left" colspan="1" rowspan="1">146</td>
            <td align="left" colspan="1" rowspan="1">4 array</td>
            <td align="left" colspan="1" rowspan="1">Array</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">connection</td>
            <td align="left" colspan="1" rowspan="1">uint64</td>
            <td align="left" colspan="1" rowspan="1">147</td>
            <td align="left" colspan="1" rowspan="1">0 unsigned</td>
            <td align="left" colspan="1" rowspan="1">String</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">connection-client</td>
            <td align="left" colspan="1" rowspan="1">uint64</td>
            <td align="left" colspan="1" rowspan="1">148</td>
            <td align="left" colspan="1" rowspan="1">0 unsigned</td>
            <td align="left" colspan="1" rowspan="1">String</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">embryonic</td>
            <td align="left" colspan="1" rowspan="1">uint64</td>
            <td align="left" colspan="1" rowspan="1">149</td>
            <td align="left" colspan="1" rowspan="1">0 unsigned</td>
            <td align="left" colspan="1" rowspan="1">String</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">embryonic-client</td>
            <td align="left" colspan="1" rowspan="1">uint64</td>
            <td align="left" colspan="1" rowspan="1">150</td>
            <td align="left" colspan="1" rowspan="1">0 unsigned</td>
            <td align="left" colspan="1" rowspan="1">String</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">connection-ps</td>
            <td align="left" colspan="1" rowspan="1">uint64</td>
            <td align="left" colspan="1" rowspan="1">151</td>
            <td align="left" colspan="1" rowspan="1">0 unsigned</td>
            <td align="left" colspan="1" rowspan="1">String</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">connection-client-ps</td>
            <td align="left" colspan="1" rowspan="1">uint64</td>
            <td align="left" colspan="1" rowspan="1">152</td>
            <td align="left" colspan="1" rowspan="1">0 unsigned</td>
            <td align="left" colspan="1" rowspan="1">String</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">request-ps</td>
            <td align="left" colspan="1" rowspan="1">uint64</td>
            <td align="left" colspan="1" rowspan="1">153</td>
            <td align="left" colspan="1" rowspan="1">0 unsigned</td>
            <td align="left" colspan="1" rowspan="1">String</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">request-client-ps</td>
            <td align="left" colspan="1" rowspan="1">uint64</td>
            <td align="left" colspan="1" rowspan="1">154</td>
            <td align="left" colspan="1" rowspan="1">0 unsigned</td>
            <td align="left" colspan="1" rowspan="1">String</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">partial-request-max</td>
            <td align="left" colspan="1" rowspan="1">uint64</td>
            <td align="left" colspan="1" rowspan="1">155</td>
            <td align="left" colspan="1" rowspan="1">0 unsigned</td>
            <td align="left" colspan="1" rowspan="1">String</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">partial-request-client-max</td>
            <td align="left" colspan="1" rowspan="1">uint64</td>
            <td align="left" colspan="1" rowspan="1">156</td>
            <td align="left" colspan="1" rowspan="1">0 unsigned</td>
            <td align="left" colspan="1" rowspan="1">String</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">total-attack-connection</td>
            <td align="left" colspan="1" rowspan="1">container</td>
            <td align="left" colspan="1" rowspan="1">157</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">connection-c</td>
            <td align="left" colspan="1" rowspan="1">container</td>
            <td align="left" colspan="1" rowspan="1">158</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">embryonic-c</td>
            <td align="left" colspan="1" rowspan="1">container</td>
            <td align="left" colspan="1" rowspan="1">159</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">connection-ps-c</td>
            <td align="left" colspan="1" rowspan="1">container</td>
            <td align="left" colspan="1" rowspan="1">160</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">request-ps-c</td>
            <td align="left" colspan="1" rowspan="1">container</td>
            <td align="left" colspan="1" rowspan="1">161</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">attack-detail</td>
            <td align="left" colspan="1" rowspan="1">list</td>
            <td align="left" colspan="1" rowspan="1">162</td>
            <td align="left" colspan="1" rowspan="1">4 array</td>
            <td align="left" colspan="1" rowspan="1">Array</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">id</td>
            <td align="left" colspan="1" rowspan="1">uint32</td>
            <td align="left" colspan="1" rowspan="1">163</td>
            <td align="left" colspan="1" rowspan="1">0 unsigned</td>
            <td align="left" colspan="1" rowspan="1">Number</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">attack-id</td>
            <td align="left" colspan="1" rowspan="1">uint32</td>
            <td align="left" colspan="1" rowspan="1">164</td>
            <td align="left" colspan="1" rowspan="1">0 unsigned</td>
            <td align="left" colspan="1" rowspan="1">Number</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">attack-description</td>
            <td align="left" colspan="1" rowspan="1">string</td>
            <td align="left" colspan="1" rowspan="1">165</td>
            <td align="left" colspan="1" rowspan="1">3 text string</td>
            <td align="left" colspan="1" rowspan="1">String</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">attack-severity</td>
            <td align="left" colspan="1" rowspan="1">enumeration</td>
            <td align="left" colspan="1" rowspan="1">166</td>
            <td align="left" colspan="1" rowspan="1">0 unsigned</td>
            <td align="left" colspan="1" rowspan="1">String</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">start-time</td>
            <td align="left" colspan="1" rowspan="1">uint64</td>
            <td align="left" colspan="1" rowspan="1">167</td>
            <td align="left" colspan="1" rowspan="1">0 unsigned</td>
            <td align="left" colspan="1" rowspan="1">String</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">end-time</td>
            <td align="left" colspan="1" rowspan="1">uint64</td>
            <td align="left" colspan="1" rowspan="1">168</td>
            <td align="left" colspan="1" rowspan="1">0 unsigned</td>
            <td align="left" colspan="1" rowspan="1">String</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">source-count</td>
            <td align="left" colspan="1" rowspan="1">container</td>
            <td align="left" colspan="1" rowspan="1">169</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">top-talker</td>
            <td align="left" colspan="1" rowspan="1">container</td>
            <td align="left" colspan="1" rowspan="1">170</td>
            <td align="left" colspan="1" rowspan="1">5 map</td>
            <td align="left" colspan="1" rowspan="1">Object</td>
          </tr>
          <tr>
            <td rowspan="2" align="left" colspan="1">spoofed-status</td>
            <td rowspan="2" align="left" colspan="1">boolean</td>
            <td rowspan="2" align="left" colspan="1">171</td>
            <td align="left" colspan="1" rowspan="1">7 bits 20</td>
            <td align="left" colspan="1" rowspan="1">False</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">7 bits 21</td>
            <td align="left" colspan="1" rowspan="1">True</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">partial-request-c</td>
            <td align="left" colspan="1" rowspan="1">container</td>
            <td align="left" colspan="1" rowspan="1">172</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">total-attack-connection-protocol</td>
            <td align="left" colspan="1" rowspan="1">list</td>
            <td align="left" colspan="1" rowspan="1">173</td>
            <td align="left" colspan="1" rowspan="1">4 array</td>
            <td align="left" colspan="1" rowspan="1">Array</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">baseline</td>
            <td align="left" colspan="1" rowspan="1">list</td>
            <td align="left" colspan="1" rowspan="1">174</td>
            <td align="left" colspan="1" rowspan="1">4 array</td>
            <td align="left" colspan="1" rowspan="1">Array</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">current-config</td>
            <td align="left" colspan="1" rowspan="1">container</td>
            <td align="left" colspan="1" rowspan="1">175</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">max-config-values</td>
            <td align="left" colspan="1" rowspan="1">container</td>
            <td align="left" colspan="1" rowspan="1">176</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">min-config-values</td>
            <td align="left" colspan="1" rowspan="1">container</td>
            <td align="left" colspan="1" rowspan="1">177</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">supported-unit-classes</td>
            <td align="left" colspan="1" rowspan="1">container</td>
            <td align="left" colspan="1" rowspan="1">178</td>
            <td align="left" colspan="1" rowspan="1">5 map</td>
            <td align="left" colspan="1" rowspan="1">Object</td>
          </tr>
          <tr>
            <td rowspan="2" align="left" colspan="1">server-originated-telemetry</td>
            <td rowspan="2" align="left" colspan="1">boolean</td>
            <td rowspan="2" align="left" colspan="1">179</td>
            <td align="left" colspan="1" rowspan="1">7 bits 20</td>
            <td align="left" colspan="1" rowspan="1">False</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">7 bits 21</td>
            <td align="left" colspan="1" rowspan="1">True</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">telemetry-notify-interval</td>
            <td align="left" colspan="1" rowspan="1">uint16</td>
            <td align="left" colspan="1" rowspan="1">180</td>
            <td align="left" colspan="1" rowspan="1">0 unsigned</td>
            <td align="left" colspan="1" rowspan="1">Number</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">tmid</td>
            <td align="left" colspan="1" rowspan="1">uint32</td>
            <td align="left" colspan="1" rowspan="1">181</td>
            <td align="left" colspan="1" rowspan="1">0 unsigned</td>
            <td align="left" colspan="1" rowspan="1">Number</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">measurement-interval</td>
            <td align="left" colspan="1" rowspan="1">enumeration</td>
            <td align="left" colspan="1" rowspan="1">182</td>
            <td align="left" colspan="1" rowspan="1">0 unsigned</td>
            <td align="left" colspan="1" rowspan="1">String</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">measurement-sample</td>
            <td align="left" colspan="1" rowspan="1">enumeration</td>
            <td align="left" colspan="1" rowspan="1">183</td>
            <td align="left" colspan="1" rowspan="1">0 unsigned</td>
            <td align="left" colspan="1" rowspan="1">String</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">talker</td>
            <td align="left" colspan="1" rowspan="1">list</td>
            <td align="left" colspan="1" rowspan="1">184</td>
            <td align="left" colspan="1" rowspan="1">4 array</td>
            <td align="left" colspan="1" rowspan="1">Array</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">source-prefix</td>
            <td align="left" colspan="1" rowspan="1">inet:ip-prefix</td>
            <td align="left" colspan="1" rowspan="1">185</td>
            <td align="left" colspan="1" rowspan="1">3 text string</td>
            <td align="left" colspan="1" rowspan="1">String</td>
          </tr>
          <tr>
            <td rowspan="2" align="left" colspan="1">mid-list</td>
            <td align="left" colspan="1" rowspan="1">leaf-list</td>
            <td align="left" colspan="1" rowspan="1">186</td>
            <td align="left" colspan="1" rowspan="1">4 array</td>
            <td align="left" colspan="1" rowspan="1">Array</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">uint32</td>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="left" colspan="1" rowspan="1">0 unsigned</td>
            <td align="left" colspan="1" rowspan="1">Number</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">source-port-range</td>
            <td align="left" colspan="1" rowspan="1">list</td>
            <td align="left" colspan="1" rowspan="1">187</td>
            <td align="left" colspan="1" rowspan="1">4 array</td>
            <td align="left" colspan="1" rowspan="1">Array</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">source-icmp-type-range</td>
            <td align="left" colspan="1" rowspan="1">list</td>
            <td align="left" colspan="1" rowspan="1">188</td>
            <td align="left" colspan="1" rowspan="1">4 array</td>
            <td align="left" colspan="1" rowspan="1">Array</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">target</td>
            <td align="left" colspan="1" rowspan="1">container</td>
            <td align="left" colspan="1" rowspan="1">189</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">capacity</td>
            <td align="left" colspan="1" rowspan="1">uint64</td>
            <td align="left" colspan="1" rowspan="1">190</td>
            <td align="left" colspan="1" rowspan="1">0 unsigned</td>
            <td align="left" colspan="1" rowspan="1">String</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">protocol</td>
            <td align="left" colspan="1" rowspan="1">uint8</td>
            <td align="left" colspan="1" rowspan="1">191</td>
            <td align="left" colspan="1" rowspan="1">0 unsigned</td>
            <td align="left" colspan="1" rowspan="1">Number</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">total-traffic-normal-per-protocol</td>
            <td align="left" colspan="1" rowspan="1">list</td>
            <td align="left" colspan="1" rowspan="1">192</td>
            <td align="left" colspan="1" rowspan="1">4 array</td>
            <td align="left" colspan="1" rowspan="1">Array</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">total-traffic-normal-per-port</td>
            <td align="left" colspan="1" rowspan="1">list</td>
            <td align="left" colspan="1" rowspan="1">193</td>
            <td align="left" colspan="1" rowspan="1">4 array</td>
            <td align="left" colspan="1" rowspan="1">Array</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">total-connection-capacity-per-port</td>
            <td align="left" colspan="1" rowspan="1">list</td>
            <td align="left" colspan="1" rowspan="1">194</td>
            <td align="left" colspan="1" rowspan="1">4 array</td>
            <td align="left" colspan="1" rowspan="1">Array</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">total-traffic-protocol</td>
            <td align="left" colspan="1" rowspan="1">list</td>
            <td align="left" colspan="1" rowspan="1">195</td>
            <td align="left" colspan="1" rowspan="1">4 array</td>
            <td align="left" colspan="1" rowspan="1">Array</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">total-traffic-port</td>
            <td align="left" colspan="1" rowspan="1">list</td>
            <td align="left" colspan="1" rowspan="1">196</td>
            <td align="left" colspan="1" rowspan="1">4 array</td>
            <td align="left" colspan="1" rowspan="1">Array</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">total-attack-traffic-protocol</td>
            <td align="left" colspan="1" rowspan="1">list</td>
            <td align="left" colspan="1" rowspan="1">197</td>
            <td align="left" colspan="1" rowspan="1">4 array</td>
            <td align="left" colspan="1" rowspan="1">Array</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">total-attack-traffic-port</td>
            <td align="left" colspan="1" rowspan="1">list</td>
            <td align="left" colspan="1" rowspan="1">198</td>
            <td align="left" colspan="1" rowspan="1">4 array</td>
            <td align="left" colspan="1" rowspan="1">Array</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">total-attack-connection-port</td>
            <td align="left" colspan="1" rowspan="1">list</td>
            <td align="left" colspan="1" rowspan="1">199</td>
            <td align="left" colspan="1" rowspan="1">4 array</td>
            <td align="left" colspan="1" rowspan="1">Array</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">port</td>
            <td align="left" colspan="1" rowspan="1">inet:port-number</td>
            <td align="left" colspan="1" rowspan="1">200</td>
            <td align="left" colspan="1" rowspan="1">0 unsigned</td>
            <td align="left" colspan="1" rowspan="1">Number</td>
          </tr>
          <tr>
            <td rowspan="2" align="left" colspan="1">supported-query-type</td>
            <td align="left" colspan="1" rowspan="1">leaf-list</td>
            <td align="left" colspan="1" rowspan="1">201</td>
            <td align="left" colspan="1" rowspan="1">4 array</td>
            <td align="left" colspan="1" rowspan="1">Array</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="left" colspan="1" rowspan="1"/>
            <td align="left" colspan="1" rowspan="1">0 unsigned</td>
            <td align="left" colspan="1" rowspan="1">String</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">vendor-id</td>
            <td align="left" colspan="1" rowspan="1">uint32</td>
            <td align="left" colspan="1" rowspan="1">202</td>
            <td align="left" colspan="1" rowspan="1">0 unsigned</td>
            <td align="left" colspan="1" rowspan="1">Number</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">ietf-dots-telemetry:telemetry-setup</td>
            <td align="left" colspan="1" rowspan="1">container</td>
            <td align="left" colspan="1" rowspan="1">203</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-telemetry:total-traffic</td>
            <td align="left" colspan="1" rowspan="1">list</td>
            <td align="left" colspan="1" rowspan="1">204</td>
            <td align="left" colspan="1" rowspan="1">4 array</td>
            <td align="left" colspan="1" rowspan="1">Array</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">ietf-dots-telemetry:total-attack-traffic</td>
            <td align="left" colspan="1" rowspan="1">list</td>
            <td align="left" colspan="1" rowspan="1">205</td>
            <td align="left" colspan="1" rowspan="1">4 array</td>
            <td align="left" colspan="1" rowspan="1">Array</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">ietf-dots-telemetry:total-attack-connection</td>
            <td align="left" colspan="1" rowspan="1">container</td>
            <td align="left" colspan="1" rowspan="1">206</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-telemetry:attack-detail</td>
            <td align="left" colspan="1" rowspan="1">list</td>
            <td align="left" colspan="1" rowspan="1">207</td>
            <td align="left" colspan="1" rowspan="1">4 array</td>
            <td align="left" colspan="1" rowspan="1">Array</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">ietf-dots-telemetry:telemetry</td>
            <td align="left" colspan="1" rowspan="1">container</td>
            <td align="left" colspan="1" rowspan="1">208</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">current-g</td>
            <td align="left" colspan="1" rowspan="1">yang:gauge64</td>
            <td align="left" colspan="1" rowspan="1">209</td>
            <td align="left" colspan="1" rowspan="1">0 unsigned</td>
            <td align="left" colspan="1" rowspan="1">String</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">description-lang</td>
            <td align="left" colspan="1" rowspan="1">string</td>
            <td align="left" colspan="1" rowspan="1">210</td>
            <td align="left" colspan="1" rowspan="1">3 text string</td>
            <td align="left" colspan="1" rowspan="1">String</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">lower-type</td>
            <td align="left" colspan="1" rowspan="1">uint8</td>
            <td align="left" colspan="1" rowspan="1">32771</td>
            <td align="left" colspan="1" rowspan="1">0 unsigned</td>
            <td align="left" colspan="1" rowspan="1">Number</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">upper-type</td>
            <td align="left" colspan="1" rowspan="1">uint8</td>
            <td align="left" colspan="1" rowspan="1">32772</td>
            <td align="left" colspan="1" rowspan="1">0 unsigned</td>
            <td align="left" colspan="1" rowspan="1">Number</td>
          </tr>
        </tbody>
      </table>
    </section>
    <section anchor="IANA" numbered="true" toc="include" removeInRFC="false" pn="section-13">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <section anchor="map" numbered="true" toc="include" removeInRFC="false" pn="section-13.1">
        <name slugifiedName="name-dots-signal-channel-cbor-ke">DOTS Signal Channel CBOR Key Values</name>
        <t indent="0" pn="section-13.1-1">This specification registers the following comprehension-optional parameters in the IANA "DOTS Signal Channel CBOR Key Values" registry <xref target="Key-Map" format="default" sectionFormat="of" derivedContent="Key-Map"/>.</t>
        <table anchor="tab-4" align="center" pn="table-4">
          <name slugifiedName="name-registered-dots-signal-chan">Registered DOTS Signal Channel CBOR Key Values</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">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">tsid</td>
              <td align="left" colspan="1" rowspan="1">128</td>
              <td align="left" colspan="1" rowspan="1">0</td>
              <td align="left" colspan="1" rowspan="1">IESG</td>
              <td align="left" colspan="1" rowspan="1">RFC 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">telemetry</td>
              <td align="left" colspan="1" rowspan="1">129</td>
              <td align="left" colspan="1" rowspan="1">4</td>
              <td align="left" colspan="1" rowspan="1">IESG</td>
              <td align="left" colspan="1" rowspan="1">RFC 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">low-percentile</td>
              <td align="left" colspan="1" rowspan="1">130</td>
              <td align="left" colspan="1" rowspan="1">6tag4</td>
              <td align="left" colspan="1" rowspan="1">IESG</td>
              <td align="left" colspan="1" rowspan="1">RFC 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">mid-percentile</td>
              <td align="left" colspan="1" rowspan="1">131</td>
              <td align="left" colspan="1" rowspan="1">6tag4</td>
              <td align="left" colspan="1" rowspan="1">IESG</td>
              <td align="left" colspan="1" rowspan="1">RFC 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">high-percentile</td>
              <td align="left" colspan="1" rowspan="1">132</td>
              <td align="left" colspan="1" rowspan="1">6tag4</td>
              <td align="left" colspan="1" rowspan="1">IESG</td>
              <td align="left" colspan="1" rowspan="1">RFC 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">unit-config</td>
              <td align="left" colspan="1" rowspan="1">133</td>
              <td align="left" colspan="1" rowspan="1">4</td>
              <td align="left" colspan="1" rowspan="1">IESG</td>
              <td align="left" colspan="1" rowspan="1">RFC 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">unit</td>
              <td align="left" colspan="1" rowspan="1">134</td>
              <td align="left" colspan="1" rowspan="1">0</td>
              <td align="left" colspan="1" rowspan="1">IESG</td>
              <td align="left" colspan="1" rowspan="1">RFC 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">unit-status</td>
              <td align="left" colspan="1" rowspan="1">135</td>
              <td align="left" colspan="1" rowspan="1">7</td>
              <td align="left" colspan="1" rowspan="1">IESG</td>
              <td align="left" colspan="1" rowspan="1">RFC 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">total-pipe-capacity</td>
              <td align="left" colspan="1" rowspan="1">136</td>
              <td align="left" colspan="1" rowspan="1">4</td>
              <td align="left" colspan="1" rowspan="1">IESG</td>
              <td align="left" colspan="1" rowspan="1">RFC 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">link-id</td>
              <td align="left" colspan="1" rowspan="1">137</td>
              <td align="left" colspan="1" rowspan="1">3</td>
              <td align="left" colspan="1" rowspan="1">IESG</td>
              <td align="left" colspan="1" rowspan="1">RFC 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">pre-or-ongoing-mitigation</td>
              <td align="left" colspan="1" rowspan="1">138</td>
              <td align="left" colspan="1" rowspan="1">4</td>
              <td align="left" colspan="1" rowspan="1">IESG</td>
              <td align="left" colspan="1" rowspan="1">RFC 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">total-traffic-normal</td>
              <td align="left" colspan="1" rowspan="1">139</td>
              <td align="left" colspan="1" rowspan="1">4</td>
              <td align="left" colspan="1" rowspan="1">IESG</td>
              <td align="left" colspan="1" rowspan="1">RFC 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">low-percentile-g</td>
              <td align="left" colspan="1" rowspan="1">140</td>
              <td align="left" colspan="1" rowspan="1">0</td>
              <td align="left" colspan="1" rowspan="1">IESG</td>
              <td align="left" colspan="1" rowspan="1">RFC 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">mid-percentile-g</td>
              <td align="left" colspan="1" rowspan="1">141</td>
              <td align="left" colspan="1" rowspan="1">0</td>
              <td align="left" colspan="1" rowspan="1">IESG</td>
              <td align="left" colspan="1" rowspan="1">RFC 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">high-percentile-g</td>
              <td align="left" colspan="1" rowspan="1">142</td>
              <td align="left" colspan="1" rowspan="1">0</td>
              <td align="left" colspan="1" rowspan="1">IESG</td>
              <td align="left" colspan="1" rowspan="1">RFC 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">peak-g</td>
              <td align="left" colspan="1" rowspan="1">143</td>
              <td align="left" colspan="1" rowspan="1">0</td>
              <td align="left" colspan="1" rowspan="1">IESG</td>
              <td align="left" colspan="1" rowspan="1">RFC 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">total-attack-traffic</td>
              <td align="left" colspan="1" rowspan="1">144</td>
              <td align="left" colspan="1" rowspan="1">4</td>
              <td align="left" colspan="1" rowspan="1">IESG</td>
              <td align="left" colspan="1" rowspan="1">RFC 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">total-traffic</td>
              <td align="left" colspan="1" rowspan="1">145</td>
              <td align="left" colspan="1" rowspan="1">4</td>
              <td align="left" colspan="1" rowspan="1">IESG</td>
              <td align="left" colspan="1" rowspan="1">RFC 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">total-connection-capacity</td>
              <td align="left" colspan="1" rowspan="1">146</td>
              <td align="left" colspan="1" rowspan="1">4</td>
              <td align="left" colspan="1" rowspan="1">IESG</td>
              <td align="left" colspan="1" rowspan="1">RFC 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">connection</td>
              <td align="left" colspan="1" rowspan="1">147</td>
              <td align="left" colspan="1" rowspan="1">0</td>
              <td align="left" colspan="1" rowspan="1">IESG</td>
              <td align="left" colspan="1" rowspan="1">RFC 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">connection-client</td>
              <td align="left" colspan="1" rowspan="1">148</td>
              <td align="left" colspan="1" rowspan="1">0</td>
              <td align="left" colspan="1" rowspan="1">IESG</td>
              <td align="left" colspan="1" rowspan="1">RFC 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">embryonic</td>
              <td align="left" colspan="1" rowspan="1">149</td>
              <td align="left" colspan="1" rowspan="1">0</td>
              <td align="left" colspan="1" rowspan="1">IESG</td>
              <td align="left" colspan="1" rowspan="1">RFC 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">embryonic-client</td>
              <td align="left" colspan="1" rowspan="1">150</td>
              <td align="left" colspan="1" rowspan="1">0</td>
              <td align="left" colspan="1" rowspan="1">IESG</td>
              <td align="left" colspan="1" rowspan="1">RFC 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">connection-ps</td>
              <td align="left" colspan="1" rowspan="1">151</td>
              <td align="left" colspan="1" rowspan="1">0</td>
              <td align="left" colspan="1" rowspan="1">IESG</td>
              <td align="left" colspan="1" rowspan="1">RFC 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">connection-client-ps</td>
              <td align="left" colspan="1" rowspan="1">152</td>
              <td align="left" colspan="1" rowspan="1">0</td>
              <td align="left" colspan="1" rowspan="1">IESG</td>
              <td align="left" colspan="1" rowspan="1">RFC 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">request-ps</td>
              <td align="left" colspan="1" rowspan="1">153</td>
              <td align="left" colspan="1" rowspan="1">0</td>
              <td align="left" colspan="1" rowspan="1">IESG</td>
              <td align="left" colspan="1" rowspan="1">RFC 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">request-client-ps</td>
              <td align="left" colspan="1" rowspan="1">154</td>
              <td align="left" colspan="1" rowspan="1">0</td>
              <td align="left" colspan="1" rowspan="1">IESG</td>
              <td align="left" colspan="1" rowspan="1">RFC 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">partial-request-max</td>
              <td align="left" colspan="1" rowspan="1">155</td>
              <td align="left" colspan="1" rowspan="1">0</td>
              <td align="left" colspan="1" rowspan="1">IESG</td>
              <td align="left" colspan="1" rowspan="1">RFC 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">partial-request-client-max</td>
              <td align="left" colspan="1" rowspan="1">156</td>
              <td align="left" colspan="1" rowspan="1">0</td>
              <td align="left" colspan="1" rowspan="1">IESG</td>
              <td align="left" colspan="1" rowspan="1">RFC 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">total-attack-connection</td>
              <td align="left" colspan="1" rowspan="1">157</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 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">connection-c</td>
              <td align="left" colspan="1" rowspan="1">158</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 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">embryonic-c</td>
              <td align="left" colspan="1" rowspan="1">159</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 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">connection-ps-c</td>
              <td align="left" colspan="1" rowspan="1">160</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 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">request-ps-c</td>
              <td align="left" colspan="1" rowspan="1">161</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 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">attack-detail</td>
              <td align="left" colspan="1" rowspan="1">162</td>
              <td align="left" colspan="1" rowspan="1">4</td>
              <td align="left" colspan="1" rowspan="1">IESG</td>
              <td align="left" colspan="1" rowspan="1">RFC 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">id</td>
              <td align="left" colspan="1" rowspan="1">163</td>
              <td align="left" colspan="1" rowspan="1">0</td>
              <td align="left" colspan="1" rowspan="1">IESG</td>
              <td align="left" colspan="1" rowspan="1">RFC 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">attack-id</td>
              <td align="left" colspan="1" rowspan="1">164</td>
              <td align="left" colspan="1" rowspan="1">0</td>
              <td align="left" colspan="1" rowspan="1">IESG</td>
              <td align="left" colspan="1" rowspan="1">RFC 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">attack-description</td>
              <td align="left" colspan="1" rowspan="1">165</td>
              <td align="left" colspan="1" rowspan="1">3</td>
              <td align="left" colspan="1" rowspan="1">IESG</td>
              <td align="left" colspan="1" rowspan="1">RFC 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">attack-severity</td>
              <td align="left" colspan="1" rowspan="1">166</td>
              <td align="left" colspan="1" rowspan="1">0</td>
              <td align="left" colspan="1" rowspan="1">IESG</td>
              <td align="left" colspan="1" rowspan="1">RFC 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">start-time</td>
              <td align="left" colspan="1" rowspan="1">167</td>
              <td align="left" colspan="1" rowspan="1">0</td>
              <td align="left" colspan="1" rowspan="1">IESG</td>
              <td align="left" colspan="1" rowspan="1">RFC 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">end-time</td>
              <td align="left" colspan="1" rowspan="1">168</td>
              <td align="left" colspan="1" rowspan="1">0</td>
              <td align="left" colspan="1" rowspan="1">IESG</td>
              <td align="left" colspan="1" rowspan="1">RFC 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">source-count</td>
              <td align="left" colspan="1" rowspan="1">169</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 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">top-talker</td>
              <td align="left" colspan="1" rowspan="1">170</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 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">spoofed-status</td>
              <td align="left" colspan="1" rowspan="1">171</td>
              <td align="left" colspan="1" rowspan="1">7</td>
              <td align="left" colspan="1" rowspan="1">IESG</td>
              <td align="left" colspan="1" rowspan="1">RFC 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">partial-request-c</td>
              <td align="left" colspan="1" rowspan="1">172</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 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">total-attack-connection-protocol</td>
              <td align="left" colspan="1" rowspan="1">173</td>
              <td align="left" colspan="1" rowspan="1">4</td>
              <td align="left" colspan="1" rowspan="1">IESG</td>
              <td align="left" colspan="1" rowspan="1">RFC 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">baseline</td>
              <td align="left" colspan="1" rowspan="1">174</td>
              <td align="left" colspan="1" rowspan="1">4</td>
              <td align="left" colspan="1" rowspan="1">IESG</td>
              <td align="left" colspan="1" rowspan="1">RFC 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">current-config</td>
              <td align="left" colspan="1" rowspan="1">175</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 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">max-config-values</td>
              <td align="left" colspan="1" rowspan="1">176</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 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">min-config-values</td>
              <td align="left" colspan="1" rowspan="1">177</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 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">supported-unit-classes</td>
              <td align="left" colspan="1" rowspan="1">178</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 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">server-originated-telemetry</td>
              <td align="left" colspan="1" rowspan="1">179</td>
              <td align="left" colspan="1" rowspan="1">7</td>
              <td align="left" colspan="1" rowspan="1">IESG</td>
              <td align="left" colspan="1" rowspan="1">RFC 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">telemetry-notify-interval</td>
              <td align="left" colspan="1" rowspan="1">180</td>
              <td align="left" colspan="1" rowspan="1">0</td>
              <td align="left" colspan="1" rowspan="1">IESG</td>
              <td align="left" colspan="1" rowspan="1">RFC 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">tmid</td>
              <td align="left" colspan="1" rowspan="1">181</td>
              <td align="left" colspan="1" rowspan="1">0</td>
              <td align="left" colspan="1" rowspan="1">IESG</td>
              <td align="left" colspan="1" rowspan="1">RFC 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">measurement-interval</td>
              <td align="left" colspan="1" rowspan="1">182</td>
              <td align="left" colspan="1" rowspan="1">0</td>
              <td align="left" colspan="1" rowspan="1">IESG</td>
              <td align="left" colspan="1" rowspan="1">RFC 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">measurement-sample</td>
              <td align="left" colspan="1" rowspan="1">183</td>
              <td align="left" colspan="1" rowspan="1">0</td>
              <td align="left" colspan="1" rowspan="1">IESG</td>
              <td align="left" colspan="1" rowspan="1">RFC 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">talker</td>
              <td align="left" colspan="1" rowspan="1">184</td>
              <td align="left" colspan="1" rowspan="1">4</td>
              <td align="left" colspan="1" rowspan="1">IESG</td>
              <td align="left" colspan="1" rowspan="1">RFC 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">source-prefix</td>
              <td align="left" colspan="1" rowspan="1">185</td>
              <td align="left" colspan="1" rowspan="1">3</td>
              <td align="left" colspan="1" rowspan="1">IESG</td>
              <td align="left" colspan="1" rowspan="1">RFC 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">mid-list</td>
              <td align="left" colspan="1" rowspan="1">186</td>
              <td align="left" colspan="1" rowspan="1">4</td>
              <td align="left" colspan="1" rowspan="1">IESG</td>
              <td align="left" colspan="1" rowspan="1">RFC 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">source-port-range</td>
              <td align="left" colspan="1" rowspan="1">187</td>
              <td align="left" colspan="1" rowspan="1">4</td>
              <td align="left" colspan="1" rowspan="1">IESG</td>
              <td align="left" colspan="1" rowspan="1">RFC 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">source-icmp-type-range</td>
              <td align="left" colspan="1" rowspan="1">188</td>
              <td align="left" colspan="1" rowspan="1">4</td>
              <td align="left" colspan="1" rowspan="1">IESG</td>
              <td align="left" colspan="1" rowspan="1">RFC 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">target</td>
              <td align="left" colspan="1" rowspan="1">189</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 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">capacity</td>
              <td align="left" colspan="1" rowspan="1">190</td>
              <td align="left" colspan="1" rowspan="1">0</td>
              <td align="left" colspan="1" rowspan="1">IESG</td>
              <td align="left" colspan="1" rowspan="1">RFC 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">protocol</td>
              <td align="left" colspan="1" rowspan="1">191</td>
              <td align="left" colspan="1" rowspan="1">0</td>
              <td align="left" colspan="1" rowspan="1">IESG</td>
              <td align="left" colspan="1" rowspan="1">RFC 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">total-traffic-normal-per-protocol</td>
              <td align="left" colspan="1" rowspan="1">192</td>
              <td align="left" colspan="1" rowspan="1">4</td>
              <td align="left" colspan="1" rowspan="1">IESG</td>
              <td align="left" colspan="1" rowspan="1">RFC 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">total-traffic-normal-per-port</td>
              <td align="left" colspan="1" rowspan="1">193</td>
              <td align="left" colspan="1" rowspan="1">4</td>
              <td align="left" colspan="1" rowspan="1">IESG</td>
              <td align="left" colspan="1" rowspan="1">RFC 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">total-connection-capacity-per-port</td>
              <td align="left" colspan="1" rowspan="1">194</td>
              <td align="left" colspan="1" rowspan="1">4</td>
              <td align="left" colspan="1" rowspan="1">IESG</td>
              <td align="left" colspan="1" rowspan="1">RFC 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">total-traffic-protocol</td>
              <td align="left" colspan="1" rowspan="1">195</td>
              <td align="left" colspan="1" rowspan="1">4</td>
              <td align="left" colspan="1" rowspan="1">IESG</td>
              <td align="left" colspan="1" rowspan="1">RFC 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">total-traffic-port</td>
              <td align="left" colspan="1" rowspan="1">196</td>
              <td align="left" colspan="1" rowspan="1">4</td>
              <td align="left" colspan="1" rowspan="1">IESG</td>
              <td align="left" colspan="1" rowspan="1">RFC 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">total-attack-traffic-protocol</td>
              <td align="left" colspan="1" rowspan="1">197</td>
              <td align="left" colspan="1" rowspan="1">4</td>
              <td align="left" colspan="1" rowspan="1">IESG</td>
              <td align="left" colspan="1" rowspan="1">RFC 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">total-attack-traffic-port</td>
              <td align="left" colspan="1" rowspan="1">198</td>
              <td align="left" colspan="1" rowspan="1">4</td>
              <td align="left" colspan="1" rowspan="1">IESG</td>
              <td align="left" colspan="1" rowspan="1">RFC 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">total-attack-connection-port</td>
              <td align="left" colspan="1" rowspan="1">199</td>
              <td align="left" colspan="1" rowspan="1">4</td>
              <td align="left" colspan="1" rowspan="1">IESG</td>
              <td align="left" colspan="1" rowspan="1">RFC 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">port</td>
              <td align="left" colspan="1" rowspan="1">200</td>
              <td align="left" colspan="1" rowspan="1">0</td>
              <td align="left" colspan="1" rowspan="1">IESG</td>
              <td align="left" colspan="1" rowspan="1">RFC 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">supported-query-type</td>
              <td align="left" colspan="1" rowspan="1">201</td>
              <td align="left" colspan="1" rowspan="1">4</td>
              <td align="left" colspan="1" rowspan="1">IESG</td>
              <td align="left" colspan="1" rowspan="1">RFC 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">vendor-id</td>
              <td align="left" colspan="1" rowspan="1">202</td>
              <td align="left" colspan="1" rowspan="1">0</td>
              <td align="left" colspan="1" rowspan="1">IESG</td>
              <td align="left" colspan="1" rowspan="1">RFC 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">ietf-dots-telemetry:telemetry-setup</td>
              <td align="left" colspan="1" rowspan="1">203</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 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">ietf-dots-telemetry:total-traffic</td>
              <td align="left" colspan="1" rowspan="1">204</td>
              <td align="left" colspan="1" rowspan="1">4</td>
              <td align="left" colspan="1" rowspan="1">IESG</td>
              <td align="left" colspan="1" rowspan="1">RFC 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">ietf-dots-telemetry:total-attack-traffic</td>
              <td align="left" colspan="1" rowspan="1">205</td>
              <td align="left" colspan="1" rowspan="1">4</td>
              <td align="left" colspan="1" rowspan="1">IESG</td>
              <td align="left" colspan="1" rowspan="1">RFC 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">ietf-dots-telemetry:total-attack-connection</td>
              <td align="left" colspan="1" rowspan="1">206</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 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">ietf-dots-telemetry:attack-detail</td>
              <td align="left" colspan="1" rowspan="1">207</td>
              <td align="left" colspan="1" rowspan="1">4</td>
              <td align="left" colspan="1" rowspan="1">IESG</td>
              <td align="left" colspan="1" rowspan="1">RFC 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">ietf-dots-telemetry:telemetry</td>
              <td align="left" colspan="1" rowspan="1">208</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 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">current-g</td>
              <td align="left" colspan="1" rowspan="1">209</td>
              <td align="left" colspan="1" rowspan="1">0</td>
              <td align="left" colspan="1" rowspan="1">IESG</td>
              <td align="left" colspan="1" rowspan="1">RFC 9244</td>
            </tr>
            <tr>
              <td align="left" colspan="1" rowspan="1">description-lang</td>
              <td align="left" colspan="1" rowspan="1">210</td>
              <td align="left" colspan="1" rowspan="1">3</td>
              <td align="left" colspan="1" rowspan="1">IESG</td>
              <td align="left" colspan="1" rowspan="1">RFC 9244</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-13.2">
        <name slugifiedName="name-dots-signal-channel-conflic">DOTS Signal Channel Conflict Cause Codes</name>
        <t indent="0" pn="section-13.2-1">Per this document, IANA has assigned a new code from the
        "DOTS Signal Channel Conflict Cause Codes" registry <xref target="Cause" format="default" sectionFormat="of" derivedContent="Cause"/>.</t>
        <table anchor="tab-5" align="center" pn="table-5">
          <name slugifiedName="name-registered-dots-signal-chann">Registered DOTS Signal Channel Conflict Cause Code</name>
          <thead>
            <tr>
              <th align="left" colspan="1" rowspan="1">Code</th>
              <th align="left" colspan="1" rowspan="1">Label</th>
              <th align="left" colspan="1" rowspan="1">Description</th>
              <th align="left" colspan="1" rowspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left" colspan="1" rowspan="1">5</td>
              <td align="left" colspan="1" rowspan="1">overlapping-pipes</td>
              <td align="left" colspan="1" rowspan="1">Overlapping pipe scope</td>
              <td align="left" colspan="1" rowspan="1">RFC 9244</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section anchor="yang" numbered="true" toc="include" removeInRFC="false" pn="section-13.3">
        <name slugifiedName="name-dots-telemetry-uris-and-yan">DOTS Telemetry URIs and YANG Module Registrations</name>
        <t indent="0" pn="section-13.3-1">Per this document, IANA has registered the following URIs 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-13.3-2">
          <dt pn="section-13.3-2.1">URI:</dt>
          <dd pn="section-13.3-2.2">urn:ietf:params:xml:ns:yang:ietf-dots-telemetry</dd>
          <dt pn="section-13.3-2.3">Registrant Contact:</dt>
          <dd pn="section-13.3-2.4">The IESG.</dd>
          <dt pn="section-13.3-2.5">XML:</dt>
          <dd pn="section-13.3-2.6">N/A; the requested URI is an XML namespace.</dd>
        </dl>
        <dl newline="false" spacing="compact" indent="3" pn="section-13.3-3">
          <dt pn="section-13.3-3.1">URI:</dt>
          <dd pn="section-13.3-3.2">urn:ietf:params:xml:ns:yang:ietf-dots-mapping</dd>
          <dt pn="section-13.3-3.3">Registrant Contact:</dt>
          <dd pn="section-13.3-3.4">The IESG.</dd>
          <dt pn="section-13.3-3.5">XML:</dt>
          <dd pn="section-13.3-3.6">N/A; the requested URI is an XML namespace.</dd>
        </dl>
        <t indent="0" pn="section-13.3-4">Per this document, IANA has registered the following YANG
        modules 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-13.3-5">
          <dt pn="section-13.3-5.1">Name:</dt>
          <dd pn="section-13.3-5.2">ietf-dots-telemetry</dd>
          <dt pn="section-13.3-5.3">Namespace:</dt>
          <dd pn="section-13.3-5.4">urn:ietf:params:xml:ns:yang:ietf-dots-telemetry</dd>
          <dt pn="section-13.3-5.5">Maintained by IANA:</dt>
          <dd pn="section-13.3-5.6">N</dd>
          <dt pn="section-13.3-5.7">Prefix:</dt>
          <dd pn="section-13.3-5.8">dots-telemetry</dd>
          <dt pn="section-13.3-5.9">Reference:</dt>
          <dd pn="section-13.3-5.10">RFC 9244</dd>
        </dl>
        <dl newline="false" spacing="compact" indent="3" pn="section-13.3-6">
          <dt pn="section-13.3-6.1">Name:</dt>
          <dd pn="section-13.3-6.2">ietf-dots-mapping</dd>
          <dt pn="section-13.3-6.3">Namespace:</dt>
          <dd pn="section-13.3-6.4">urn:ietf:params:xml:ns:yang:ietf-dots-mapping</dd>
          <dt pn="section-13.3-6.5">Maintained by IANA:</dt>
          <dd pn="section-13.3-6.6">N</dd>
          <dt pn="section-13.3-6.7">Prefix:</dt>
          <dd pn="section-13.3-6.8">dots-mapping</dd>
          <dt pn="section-13.3-6.9">Reference:</dt>
          <dd pn="section-13.3-6.10">RFC 9244</dd>
        </dl>
      </section>
    </section>
    <section anchor="security" numbered="true" toc="include" removeInRFC="false" pn="section-14">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <section anchor="sec-cons-1" numbered="true" toc="include" removeInRFC="false" pn="section-14.1">
        <name slugifiedName="name-dots-signal-channel-telemetr">DOTS Signal Channel Telemetry</name>
        <t indent="0" pn="section-14.1-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"/>. The
        following discusses the security considerations that are specific to
        the DOTS signal channel extension defined in this document.</t>
        <t indent="0" pn="section-14.1-2">The DOTS telemetry information includes DOTS client network
        topology, DOTS client domain pipe capacity, normal traffic baseline
        and connection capacity, and threat and mitigation information. Such
        information is sensitive; it <bcp14>MUST</bcp14> be protected at rest by the DOTS
        server domain to prevent data leakage. Note that sharing this
        sensitive data with a trusted DOTS server does not introduce any new
        significant considerations other than the need for the aforementioned
        protection. Such a DOTS server is already trusted to have access to
        that kind of information by being in the position to observe and
        mitigate attacks.</t>
        <t indent="0" pn="section-14.1-3">DOTS clients are typically considered to be trusted devices by the
        DOTS client domain. DOTS clients may be co-located on network security
        services (e.g., firewall devices), and a compromised security service
        potentially can do a lot more damage to the network than just the DOTS
        client component. This assumption differs from the often-held view
        (often referred to as the "zero-trust model") that devices are untrusted. A compromised DOTS client can send fake DOTS telemetry data to
        a DOTS server to mislead the DOTS server. This attack can be prevented
        by monitoring and auditing DOTS clients to detect misbehavior and to
        deter misuse, and by only authorizing the DOTS client to convey DOTS
        telemetry information for specific target resources (e.g., an
        application server is authorized to exchange DOTS telemetry for its IP
        addresses but a DDoS mitigator can exchange DOTS telemetry for any
        target resource in the network). As a reminder, this is a variation of
        dealing with compromised DOTS clients as 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-14.1-4">DOTS servers must be capable of defending themselves against DoS
        attacks from compromised DOTS clients. The following non-comprehensive
        list of mitigation techniques can be used by a DOTS server to handle
        misbehaving DOTS clients:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-14.1-5">
          <li pn="section-14.1-5.1">The probing rate (defined in <xref target="RFC9132" sectionFormat="of" section="4.5" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9132#section-4.5" derivedContent="RFC9132"/>) can be used to limit the average data
            rate to the DOTS server.</li>
          <li pn="section-14.1-5.2">Rate-limiting DOTS telemetry, including packets with new 'tmid'
            values from the same DOTS client, defends against DoS attacks that
            would result in varying the 'tmid' to exhaust DOTS server
            resources.
 Likewise, the DOTS server can enforce a quota and
            time limit on the number of active pre-or-ongoing-mitigation
            telemetry data items (identified by 'tmid') from the DOTS
            client.</li>
        </ul>
        <t indent="0" pn="section-14.1-6">Note also that the telemetry notification interval may be used to
        rate-limit the pre-or-ongoing-mitigation telemetry notifications
        received by a DOTS client domain.</t>
      </section>
      <section anchor="sec-cons-2" numbered="true" toc="include" removeInRFC="false" pn="section-14.2">
        <name slugifiedName="name-vendor-attack-mapping-2">Vendor Attack Mapping</name>
        <t indent="0" pn="section-14.2-1">The security considerations for the DOTS data channel protocol are
        discussed in <xref target="RFC8783" sectionFormat="of" section="10" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8783#section-10" derivedContent="RFC8783"/>. The
        following discusses the security considerations that are specific to
        the DOTS data channel extension defined in this document.</t>
        <t indent="0" pn="section-14.2-2">All data nodes defined in the YANG module specified in <xref target="data" format="default" sectionFormat="of" derivedContent="Section 11.2"/> that can be created, modified, and deleted (i.e., config true, which
   is the default) are considered sensitive.  Write operations to these
   data nodes without proper protection can have a negative effect on
   network operations. Appropriate security measures are recommended to prevent illegitimate users
        from invoking DOTS data channel primitives as discussed in <xref target="RFC8783" format="default" sectionFormat="of" derivedContent="RFC8783"/>. Nevertheless, an attacker who can access
        a DOTS client is technically capable of undertaking various attacks,
        such as: </t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-14.2-3">
          <li pn="section-14.2-3.1">Communicating invalid attack mapping details to the server
            ('/data-channel:dots-data/data-channel:dots-client/dots-telemetry:vendor-mapping'),
            which will mislead the server when correlating attack details.</li>
        </ul>
        <t indent="0" pn="section-14.2-4">Some of the readable data nodes in the YANG module specified in
        <xref target="data" format="default" sectionFormat="of" derivedContent="Section 11.2"/> may be considered sensitive. It is thus
        important to control read access to these data nodes. These are the
        data nodes and their sensitivity:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-14.2-5">
          <li pn="section-14.2-5.1">'/data-channel:dots-data/data-channel:dots-client/dots-telemetry:vendor-mapping'
            can be misused to infer the DDoS protection technology deployed in
            a DOTS client domain.</li>
          <li pn="section-14.2-5.2">'/data-channel:dots-data/dots-telemetry:vendor-mapping' can be
            used by a compromised DOTS client to leak the attack detection
            capabilities of the DOTS server. This is a variation of the
            compromised DOTS client attacks discussed in <xref target="sec-cons-1" format="default" sectionFormat="of" derivedContent="Section 14.1"/>.</li>
        </ul>
      </section>
    </section>
  </middle>
  <back>
    <displayreference target="I-D.ietf-dots-multihoming" to="DOTS-Multihoming"/>
    <displayreference target="I-D.ietf-dots-robust-blocks" to="DOTS-Robust-Blocks"/>
    <references pn="section-15">
      <name slugifiedName="name-references">References</name>
      <references pn="section-15.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="Private-Enterprise-Numbers" target="https://www.iana.org/assignments/enterprise-numbers/" quoteTitle="true" derivedAnchor="Private-Enterprise-Numbers">
          <front>
            <title>Private Enterprise Numbers</title>
            <author>
              <organization showOnFrontPage="true">IANA</organization>
            </author>
          </front>
        </reference>
        <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 initials="S." surname="Bradner" fullname="S. Bradner">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="1997" month="March"/>
            <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 initials="M." surname="Mealling" fullname="M. Mealling">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2004" month="January"/>
            <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="RFC5646" target="https://www.rfc-editor.org/info/rfc5646" quoteTitle="true" derivedAnchor="RFC5646">
          <front>
            <title>Tags for Identifying Languages</title>
            <author initials="A." surname="Phillips" fullname="A. Phillips" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Davis" fullname="M. Davis" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2009" month="September"/>
            <abstract>
              <t indent="0">This document describes the structure, content, construction, and semantics of language tags for use in cases where it is desirable to indicate the language used in an information object.  It also describes how to register values for use in language tags and the creation of user-defined extensions for private interchange.  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="47"/>
          <seriesInfo name="RFC" value="5646"/>
          <seriesInfo name="DOI" value="10.17487/RFC5646"/>
        </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 initials="M." surname="Bjorklund" fullname="M. Bjorklund" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2010" month="October"/>
            <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="RFC6991" target="https://www.rfc-editor.org/info/rfc6991" quoteTitle="true" derivedAnchor="RFC6991">
          <front>
            <title>Common YANG Data Types</title>
            <author initials="J." surname="Schoenwaelder" fullname="J. Schoenwaelder" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2013" month="July"/>
            <abstract>
              <t indent="0">This document introduces a collection of common data types to be used with the YANG data modeling language.  This document obsoletes RFC 6021.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6991"/>
          <seriesInfo name="DOI" value="10.17487/RFC6991"/>
        </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 initials="Z." surname="Shelby" fullname="Z. Shelby">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="K." surname="Hartke" fullname="K. Hartke">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C." surname="Bormann" fullname="C. Bormann">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2014" month="June"/>
            <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="RFC7641" target="https://www.rfc-editor.org/info/rfc7641" quoteTitle="true" derivedAnchor="RFC7641">
          <front>
            <title>Observing Resources in the Constrained Application Protocol (CoAP)</title>
            <author initials="K." surname="Hartke" fullname="K. Hartke">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2015" month="September"/>
            <abstract>
              <t indent="0">The Constrained Application Protocol (CoAP) is a RESTful application protocol for constrained nodes and networks.  The state of a resource on a CoAP server can change over time.  This document specifies a simple protocol extension for CoAP that enables CoAP clients to "observe" resources, i.e., to retrieve a representation of a resource and keep this representation updated by the server over a period of time.  The protocol follows a best-effort approach for sending new representations to clients and provides eventual consistency between the state observed by each client and the actual resource state at the server.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7641"/>
          <seriesInfo name="DOI" value="10.17487/RFC7641"/>
        </reference>
        <reference anchor="RFC7950" target="https://www.rfc-editor.org/info/rfc7950" quoteTitle="true" derivedAnchor="RFC7950">
          <front>
            <title>The YANG 1.1 Data Modeling Language</title>
            <author initials="M." surname="Bjorklund" fullname="M. Bjorklund" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2016" month="August"/>
            <abstract>
              <t indent="0">YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols.  This document describes the syntax and semantics of version 1.1 of the YANG language.  YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification.  There are a small number of backward incompatibilities from YANG version 1.  This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7950"/>
          <seriesInfo name="DOI" value="10.17487/RFC7950"/>
        </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 initials="C." surname="Bormann" fullname="C. Bormann">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="Z." surname="Shelby" fullname="Z. Shelby" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2016" month="August"/>
            <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="RFC7970" target="https://www.rfc-editor.org/info/rfc7970" quoteTitle="true" derivedAnchor="RFC7970">
          <front>
            <title>The Incident Object Description Exchange Format Version 2</title>
            <author initials="R." surname="Danyliw" fullname="R. Danyliw">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2016" month="November"/>
            <abstract>
              <t indent="0">The Incident Object Description Exchange Format (IODEF) defines a data representation for security incident reports and indicators commonly exchanged by operational security teams for mitigation and watch and warning.  This document describes an updated information model for the IODEF and provides an associated data model specified with the XML schema.  This new information and data model obsoletes RFCs 5070 and 6685.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7970"/>
          <seriesInfo name="DOI" value="10.17487/RFC7970"/>
        </reference>
        <reference anchor="RFC8040" target="https://www.rfc-editor.org/info/rfc8040" quoteTitle="true" derivedAnchor="RFC8040">
          <front>
            <title>RESTCONF Protocol</title>
            <author initials="A." surname="Bierman" fullname="A. Bierman">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Bjorklund" fullname="M. Bjorklund">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="K." surname="Watsen" fullname="K. Watsen">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2017" month="January"/>
            <abstract>
              <t indent="0">This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8040"/>
          <seriesInfo name="DOI" value="10.17487/RFC8040"/>
        </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 initials="B." surname="Leiba" fullname="B. Leiba">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2017" month="May"/>
            <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="RFC8345" target="https://www.rfc-editor.org/info/rfc8345" quoteTitle="true" derivedAnchor="RFC8345">
          <front>
            <title>A YANG Data Model for Network Topologies</title>
            <author initials="A." surname="Clemm" fullname="A. Clemm">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Medved" fullname="J. Medved">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="Varga" fullname="R. Varga">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="N." surname="Bahadur" fullname="N. Bahadur">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="H." surname="Ananthakrishnan" fullname="H. Ananthakrishnan">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="X." surname="Liu" fullname="X. Liu">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2018" month="March"/>
            <abstract>
              <t indent="0">This document defines an abstract (generic, or base) YANG data model for network/service topologies and inventories.  The data model serves as a base model that is augmented with technology-specific details in other, more specific topology and inventory data models.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8345"/>
          <seriesInfo name="DOI" value="10.17487/RFC8345"/>
        </reference>
        <reference anchor="RFC8783" target="https://www.rfc-editor.org/info/rfc8783" quoteTitle="true" derivedAnchor="RFC8783">
          <front>
            <title>Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification</title>
            <author initials="M." surname="Boucadair" fullname="M. Boucadair" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="T." surname="Reddy.K" fullname="T. Reddy.K" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2020" month="May"/>
            <abstract>
              <t indent="0">The document specifies a Distributed Denial-of-Service Open Threat Signaling (DOTS) data channel used for bulk exchange of data that cannot easily or appropriately communicated through the DOTS signal channel under attack conditions.</t>
              <t indent="0">This is a companion document to "Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification" (RFC 8782).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8783"/>
          <seriesInfo name="DOI" value="10.17487/RFC8783"/>
        </reference>
        <reference anchor="RFC8791" target="https://www.rfc-editor.org/info/rfc8791" quoteTitle="true" derivedAnchor="RFC8791">
          <front>
            <title>YANG Data Structure Extensions</title>
            <author initials="A." surname="Bierman" fullname="A. Bierman">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Björklund" fullname="M. Björklund">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="K." surname="Watsen" fullname="K. Watsen">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2020" month="June"/>
            <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="RFC8949" target="https://www.rfc-editor.org/info/rfc8949" quoteTitle="true" derivedAnchor="RFC8949">
          <front>
            <title>Concise Binary Object Representation (CBOR)</title>
            <author initials="C." surname="Bormann" fullname="C. Bormann">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="P." surname="Hoffman" fullname="P. Hoffman">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2020" month="December"/>
            <abstract>
              <t indent="0">The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack.</t>
              <t indent="0">This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049.  It does not create a new version of the format.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="94"/>
          <seriesInfo name="RFC" value="8949"/>
          <seriesInfo name="DOI" value="10.17487/RFC8949"/>
        </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 initials="M." surname="Boucadair" fullname="M. Boucadair" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Shallow" fullname="J. Shallow">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="T." surname="Reddy.K" fullname="T. Reddy.K">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2021" month="September"/>
            <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>
      </references>
      <references pn="section-15.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="Cause" target="https://www.iana.org/assignments/dots/" quoteTitle="true" derivedAnchor="Cause">
          <front>
            <title>DOTS Signal Channel Conflict Cause Codes</title>
            <author>
              <organization showOnFrontPage="true">IANA</organization>
            </author>
            <date/>
          </front>
        </reference>
        <reference anchor="I-D.ietf-dots-multihoming" quoteTitle="true" target="https://datatracker.ietf.org/doc/html/draft-ietf-dots-multihoming-13" derivedAnchor="DOTS-Multihoming">
          <front>
            <title>Multi-homing Deployment Considerations for Distributed-Denial-of-Service Open Threat Signaling (DOTS)</title>
            <author fullname="Mohamed Boucadair">
              <organization showOnFrontPage="true">Orange</organization>
            </author>
            <author fullname="Tirumaleswar Reddy.K">
              <organization showOnFrontPage="true">Akamai</organization>
            </author>
            <author fullname="Wei Pan">
              <organization showOnFrontPage="true">Huawei Technologies</organization>
            </author>
            <date month="April" day="26" year="2022"/>
            <abstract>
              <t indent="0">   This document discusses multi-homing considerations for Distributed-
   Denial-of-Service Open Threat Signaling (DOTS).  The goal is to
   provide some guidance for DOTS clients and client-domain DOTS
   gateways when multihomed.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-dots-multihoming-13"/>
          <format type="TXT" target="https://www.ietf.org/archive/id/draft-ietf-dots-multihoming-13.txt"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="I-D.ietf-dots-robust-blocks" quoteTitle="true" target="https://datatracker.ietf.org/doc/html/draft-ietf-dots-robust-blocks-03" derivedAnchor="DOTS-Robust-Blocks">
          <front>
            <title>Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Configuration Attributes for Robust Block Transmission</title>
            <author fullname="Mohamed Boucadair">
              <organization showOnFrontPage="true">Orange</organization>
            </author>
            <author fullname="Jon Shallow">
	 </author>
            <date month="February" day="11" year="2022"/>
            <abstract>
              <t indent="0">   This document specifies new DOTS signal channel configuration
   parameters that are negotiated between DOTS peers to enable the use
   of Q-Block1 and Q-Block2 CoAP Options.  These options enable robust
   and faster transmission rates for large amounts of data with less
   packet interchanges as well as supporting faster recovery should any
   of the blocks get lost in transmission.

   This document defines a YANG data model for representing these new
   DOTS signal channel configuration parameters.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-dots-robust-blocks-03"/>
          <format type="TXT" target="https://www.ietf.org/archive/id/draft-ietf-dots-robust-blocks-03.txt"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="DOTS-Telemetry-Specs" quoteTitle="true" target="https://datatracker.ietf.org/doc/html/draft-doron-dots-telemetry-00" derivedAnchor="DOTS-Telemetry-Specs">
          <front>
            <title>Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry Specifications</title>
            <author initials="E." surname="Doron" fullname="Ehud Doron">
         </author>
            <author initials="T." surname="Reddy" fullname="Tirumaleswar Reddy">
         </author>
            <author initials="F." surname="Andreasen" fullname="Flemming Andreasen">
         </author>
            <author initials="L." surname="Xia" fullname="Liang Xia">
         </author>
            <author initials="K." surname="Nishizuka" fullname="Kaname Nishizuka">
         </author>
            <date month="October" day="30" year="2016"/>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-doron-dots-telemetry-00"/>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <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="PYANG" target="https://github.com/mbj4668/pyang" quoteTitle="true" derivedAnchor="PYANG">
          <front>
            <title>pyang</title>
            <author>
              <organization showOnFrontPage="true"/>
            </author>
            <date month="April" year="2022"/>
          </front>
          <refcontent>commit dad5c68</refcontent>
        </reference>
        <reference anchor="RFC2330" target="https://www.rfc-editor.org/info/rfc2330" quoteTitle="true" derivedAnchor="RFC2330">
          <front>
            <title>Framework for IP Performance Metrics</title>
            <author initials="V." surname="Paxson" fullname="V. Paxson">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="G." surname="Almes" fullname="G. Almes">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Mahdavi" fullname="J. Mahdavi">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Mathis" fullname="M. Mathis">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="1998" month="May"/>
            <abstract>
              <t indent="0">The purpose of this memo is to define a general framework for particular metrics to be developed by the IETF's IP Performance Metrics effort. This memo provides information for the Internet community.  It does not specify an Internet standard of any kind.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2330"/>
          <seriesInfo name="DOI" value="10.17487/RFC2330"/>
        </reference>
        <reference anchor="RFC4732" target="https://www.rfc-editor.org/info/rfc4732" quoteTitle="true" derivedAnchor="RFC4732">
          <front>
            <title>Internet Denial-of-Service Considerations</title>
            <author initials="M." surname="Handley" fullname="M. Handley" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="E." surname="Rescorla" fullname="E. Rescorla" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author>
              <organization showOnFrontPage="true">IAB</organization>
            </author>
            <date year="2006" month="December"/>
            <abstract>
              <t indent="0">This document provides an overview of possible avenues for denial-of-service (DoS) attack on Internet systems.  The aim is to encourage protocol designers and network engineers towards designs that are more robust.  We discuss partial solutions that reduce the effectiveness of attacks, and how some solutions might inadvertently open up alternative vulnerabilities.  This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4732"/>
          <seriesInfo name="DOI" value="10.17487/RFC4732"/>
        </reference>
        <reference anchor="RFC5612" target="https://www.rfc-editor.org/info/rfc5612" quoteTitle="true" derivedAnchor="RFC5612">
          <front>
            <title>Enterprise Number for Documentation Use</title>
            <author initials="P." surname="Eronen" fullname="P. Eronen">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="D." surname="Harrington" fullname="D. Harrington">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2009" month="August"/>
            <abstract>
              <t indent="0">This document describes an Enterprise Number (also known as SMI Network Management Private Enterprise Code) for use in documentation.   This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5612"/>
          <seriesInfo name="DOI" value="10.17487/RFC5612"/>
        </reference>
        <reference anchor="RFC8340" target="https://www.rfc-editor.org/info/rfc8340" quoteTitle="true" derivedAnchor="RFC8340">
          <front>
            <title>YANG Tree Diagrams</title>
            <author initials="M." surname="Bjorklund" fullname="M. Bjorklund">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="L." surname="Berger" fullname="L. Berger" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2018" month="March"/>
            <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="RFC8525" target="https://www.rfc-editor.org/info/rfc8525" quoteTitle="true" derivedAnchor="RFC8525">
          <front>
            <title>YANG Library</title>
            <author initials="A." surname="Bierman" fullname="A. Bierman">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Bjorklund" fullname="M. Bjorklund">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Schoenwaelder" fullname="J. Schoenwaelder">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="K." surname="Watsen" fullname="K. Watsen">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="Wilton" fullname="R. Wilton">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2019" month="March"/>
            <abstract>
              <t indent="0">This document describes a YANG library that provides information about the YANG modules, datastores, and datastore schemas used by a network management server.  Simple caching mechanisms are provided to allow clients to minimize retrieval of this information.  This version of the YANG library supports the Network Management Datastore Architecture (NMDA) by listing all datastores supported by a network management server and the schema that is used by each of these datastores.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8525"/>
          <seriesInfo name="DOI" value="10.17487/RFC8525"/>
        </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 initials="A." surname="Mortensen" fullname="A. Mortensen">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="T." surname="Reddy" fullname="T. Reddy">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="Moskowitz" fullname="R. Moskowitz">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2019" month="May"/>
            <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="RFC8811" target="https://www.rfc-editor.org/info/rfc8811" quoteTitle="true" derivedAnchor="RFC8811">
          <front>
            <title>DDoS Open Threat Signaling (DOTS) Architecture</title>
            <author initials="A." surname="Mortensen" fullname="A. Mortensen" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="T." surname="Reddy.K" fullname="T. Reddy.K" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="F." surname="Andreasen" fullname="F. Andreasen">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="N." surname="Teague" fullname="N. Teague">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="Compton" fullname="R. Compton">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2020" month="August"/>
            <abstract>
              <t indent="0">This document describes an architecture for establishing and maintaining Distributed Denial-of-Service (DDoS) Open Threat Signaling (DOTS) within and between domains. The document does not specify protocols or protocol extensions, instead focusing on defining architectural relationships, components, and concepts used in a DOTS deployment.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8811"/>
          <seriesInfo name="DOI" value="10.17487/RFC8811"/>
        </reference>
        <reference anchor="RFC8903" target="https://www.rfc-editor.org/info/rfc8903" quoteTitle="true" derivedAnchor="RFC8903">
          <front>
            <title>Use Cases for DDoS Open Threat Signaling</title>
            <author initials="R." surname="Dobbins" fullname="R. Dobbins">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="D." surname="Migault" fullname="D. Migault">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="Moskowitz" fullname="R. Moskowitz">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="N." surname="Teague" fullname="N. Teague">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="L." surname="Xia" fullname="L. Xia">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="K." surname="Nishizuka" fullname="K. Nishizuka">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2021" month="May"/>
            <abstract>
              <t indent="0">The DDoS Open Threat Signaling (DOTS) effort is intended to provide protocols to facilitate interoperability across disparate DDoS Mitigation solutions. This document presents sample use cases that describe the interactions expected between the DOTS components as well as DOTS messaging exchanges. These use cases are meant to identify the interacting DOTS components, how they collaborate, and what the typical information to be exchanged is.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8903"/>
          <seriesInfo name="DOI" value="10.17487/RFC8903"/>
        </reference>
        <reference anchor="RFC9133" target="https://www.rfc-editor.org/info/rfc9133" quoteTitle="true" derivedAnchor="RFC9133">
          <front>
            <title>Controlling Filtering Rules Using Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel</title>
            <author initials="K." surname="Nishizuka" fullname="K. Nishizuka">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Boucadair" fullname="M. Boucadair">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="T." surname="Reddy.K" fullname="T. Reddy.K">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="T." surname="Nagata" fullname="T. Nagata">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2021" month="September"/>
            <abstract>
              <t indent="0">This document specifies an extension to the Distributed Denial-of-Service Open Threat Signaling (DOTS) signal channel protocol so that DOTS clients can control their filtering rules when an attack mitigation is active.</t>
              <t indent="0">Particularly, this extension allows a DOTS client to activate or deactivate existing filtering rules during a Distributed Denial-of-Service (DDoS) attack. The characterization of these filtering rules is conveyed by a DOTS client during an 'idle' time (i.e., no mitigation is active) by means of the DOTS data channel protocol.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9133"/>
          <seriesInfo name="DOI" value="10.17487/RFC9133"/>
        </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 initials="M." surname="Boucadair" fullname="M. Boucadair">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Shallow" fullname="J. Shallow">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2022" month="March"/>
            <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>
        <reference anchor="RFC9260" target="https://www.rfc-editor.org/info/rfc9260" quoteTitle="true" derivedAnchor="RFC9260">
          <front>
            <title>Stream Control Transmission Protocol</title>
            <author initials="R." surname="Stewart" fullname="R. Stewart">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Tüxen" fullname="M. Tüxen">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="K." surname="Nielsen" fullname="K. Nielsen">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2022" month="June"/>
            <abstract>
              <t indent="0">This document describes the Stream Control Transmission Protocol (SCTP) and obsoletes RFC 4960.  It incorporates the specification of the chunk flags registry from RFC 6096 and the specification of the I bit of DATA chunks from RFC 7053. Therefore, RFCs 6096 and 7053 are also obsoleted by this document. In addition, RFCs 4460 and 8540, which describe errata for SCTP, are obsoleted by this document. </t>
              <t indent="0">SCTP was originally designed to transport Public Switched Telephone Network (PSTN) signaling messages over IP networks. It is also suited to be used for other applications, for example, WebRTC.</t>
              <t indent="0">SCTP is a reliable transport protocol operating on top of a connectionless packet network, such as IP. It offers the following services to its users:</t>
              <t indent="0">The design of SCTP includes appropriate congestion avoidance behavior and resistance to flooding and masquerade attacks.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9260"/>
          <seriesInfo name="DOI" value="10.17487/RFC9260"/>
        </reference>
      </references>
    </references>
    <section anchor="ack" numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgments">Acknowledgments</name>
      <t indent="0" pn="section-appendix.a-1">The authors would like to thank <contact fullname="Flemming Andreasen"/>, <contact fullname="Liang Xia"/>, and
      <contact fullname="Kaname Nishizuka"/>, coauthors of <xref target="DOTS-Telemetry-Specs" format="default" sectionFormat="of" derivedContent="DOTS-Telemetry-Specs"/>, and everyone who had
      contributed to that document.</t>
      <t indent="0" pn="section-appendix.a-2">Thanks to <contact fullname="Kaname Nishizuka"/>, <contact fullname="Yuhei Hayashi"/>, and <contact fullname="Tom Petch"/>
      for comments and review.</t>
      <t indent="0" pn="section-appendix.a-3">Special thanks to <contact fullname="Jon Shallow"/> and <contact fullname="Kaname Nishizuka"/> for their
      implementation and interoperability work.</t>
      <t indent="0" pn="section-appendix.a-4">Many thanks to <contact fullname="Jan Lindblad"/> for the yangdoctors review, <contact fullname="Nagendra Nainar"/> for the opsdir review, <contact fullname="James Gruessing"/> for the artart review,
      <contact fullname="Michael Scharf"/> for the tsv-art review, <contact fullname="Ted Lemon"/> for the int-dir review,
      and <contact fullname="Robert Sparks"/> for the gen-art review.</t>
      <t indent="0" pn="section-appendix.a-5">Thanks to <contact fullname="Benjamin Kaduk"/> for the detailed AD review.</t>
      <t indent="0" pn="section-appendix.a-6">Thanks to <contact fullname="Roman Danyliw"/>, <contact fullname="Éric Vyncke"/>, <contact fullname="Francesca Palombini"/>,
      <contact fullname="Warren Kumari"/>, <contact fullname="Erik Kline"/>, <contact fullname="Lars Eggert"/>, and <contact fullname="Robert Wilton"/> for the IESG
      review.</t>
    </section>
    <section anchor="contr" numbered="false" toc="include" removeInRFC="false" pn="section-appendix.b">
      <name slugifiedName="name-contributors">Contributors</name>
      <t indent="0" pn="section-appendix.b-1">The following individuals have contributed to this document:</t>
      <contact fullname="Li Su">
        <organization showOnFrontPage="true">CMCC</organization>
        <address>
          <email>suli@chinamobile.com</email>
        </address>
      </contact>
      <contact fullname="Pan Wei">
        <organization showOnFrontPage="true">Huawei</organization>
        <address>
          <email>william.panwei@huawei.com</email>
        </address>
      </contact>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.c">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author fullname="Mohamed Boucadair" initials="M." role="editor" surname="Boucadair">
        <organization showOnFrontPage="true">Orange</organization>
        <address>
          <postal>
            <street/>
            <city>Rennes</city>
            <code>35000</code>
            <country>France</country>
          </postal>
          <email>mohamed.boucadair@orange.com</email>
        </address>
      </author>
      <author fullname="Tirumaleswar Reddy.K" initials="T." role="editor" surname="Reddy.K">
        <organization showOnFrontPage="true">Akamai</organization>
        <address>
          <postal>
            <street>Embassy Golf Link Business Park</street>
            <city>Bangalore</city>
            <region>Karnataka</region>
            <code>560071</code>
            <country>India</country>
          </postal>
          <email>kondtir@gmail.com</email>
        </address>
      </author>
      <author fullname="Ehud Doron" initials="E." surname="Doron">
        <organization showOnFrontPage="true">Radware Ltd.</organization>
        <address>
          <postal>
            <street>Raoul Wallenberg Street</street>
            <city>Tel-Aviv</city>
            <code>69710</code>
            <country>Israel</country>
          </postal>
          <email>ehudd@radware.com</email>
        </address>
      </author>
      <author fullname="Meiling Chen" initials="M." surname="Chen">
        <organization showOnFrontPage="true">CMCC</organization>
        <address>
          <postal>
            <street>32 Xuanwumen West Street</street>
            <city>Beijing</city>
            <code>100053</code>
            <country>China</country>
          </postal>
          <email>chenmeiling@chinamobile.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>
