< draft-ietf-dots-telemetry-17.txt		draft-ietf-dots-telemetry-18.txt >
	DOTS M. Boucadair, Ed.		DOTS M. Boucadair, Ed.
	Internet-Draft Orange		Internet-Draft Orange
	Intended status: Standards Track T. Reddy, Ed.		Intended status: Standards Track T. Reddy, Ed.
	Expires: May 20, 2022 McAfee		Expires: 16 June 2022 Akamai
	E. Doron		E. Doron
	Radware Ltd.		Radware Ltd.
	M. Chen		M. Chen
	CMCC		CMCC
	J. Shallow		J. Shallow
	November 16, 2021		13 December 2021
	Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry		Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry
	draft-ietf-dots-telemetry-17		draft-ietf-dots-telemetry-18
	Abstract		Abstract
	This document aims to enrich the DOTS signal channel protocol with		This document aims to enrich the DOTS signal channel protocol with
	various telemetry attributes, allowing for optimal Distributed		various telemetry attributes, allowing for optimal Distributed
	Denial-of-Service attack mitigation. It specifies the normal traffic		Denial-of-Service (DDoS) attack mitigation. It specifies the normal
	baseline and attack traffic telemetry attributes a DOTS client can		traffic baseline and attack traffic telemetry attributes a DOTS
	convey to its DOTS server in the mitigation request, the mitigation		client can convey to its DOTS server in the mitigation request, the
	status telemetry attributes a DOTS server can communicate to a DOTS		mitigation status telemetry attributes a DOTS server can communicate
	client, and the mitigation efficacy telemetry attributes a DOTS		to a DOTS client, and the mitigation efficacy telemetry attributes a
	client can communicate to a DOTS server. The telemetry attributes		DOTS client can communicate to a DOTS server. The telemetry
	can assist the mitigator to choose the DDoS mitigation techniques and		attributes can assist the mitigator to choose the DDoS mitigation
	perform optimal DDoS attack mitigation.		techniques and perform optimal DDoS attack mitigation.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on May 20, 2022.		This Internet-Draft will expire on 16 June 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2021 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	(https://trustee.ietf.org/license-info) in effect on the date of		license-info) in effect on the date of publication of this document.
	publication of this document. Please review these documents		Please review these documents carefully, as they describe your rights
	carefully, as they describe your rights and restrictions with respect		and restrictions with respect to this document. Code Components
	to this document. Code Components extracted from this document must		extracted from this document must include Revised BSD License text as
	include Simplified BSD License text as described in Section 4.e of		described in Section 4.e of the Trust Legal Provisions and are
	the Trust Legal Provisions and are provided without warranty as		provided without warranty as described in the Revised BSD License.
	described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
	3. DOTS Telemetry: Overview and Purpose . . . . . . . . . . . . 6		3. DOTS Telemetry: Overview and Purpose . . . . . . . . . . . . 6
	3.1. Need More Visibility . . . . . . . . . . . . . . . . . . 6		3.1. Need More Visibility . . . . . . . . . . . . . . . . . . 7
	3.2. Enhanced Detection . . . . . . . . . . . . . . . . . . . 7		3.2. Enhanced Detection . . . . . . . . . . . . . . . . . . . 8
	3.3. Efficient Mitigation . . . . . . . . . . . . . . . . . . 9		3.3. Efficient Mitigation . . . . . . . . . . . . . . . . . . 9
	4. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 10		4. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 10
	4.1. Overview of Telemetry Operations . . . . . . . . . . . . 10		4.1. Overview of Telemetry Operations . . . . . . . . . . . . 10
	4.2. Generic Considerations . . . . . . . . . . . . . . . . . 10		4.2. Generic Considerations . . . . . . . . . . . . . . . . . 11
	4.2.1. DOTS Client Identification . . . . . . . . . . . . . 10		4.2.1. DOTS Client Identification . . . . . . . . . . . . . 11
	4.2.2. DOTS Gateways . . . . . . . . . . . . . . . . . . . . 10		4.2.2. DOTS Gateways . . . . . . . . . . . . . . . . . . . . 12
	4.2.3. Empty URI Paths . . . . . . . . . . . . . . . . . . . 11		4.2.3. Empty URI Paths . . . . . . . . . . . . . . . . . . . 12
	4.2.4. Controlling Configuration Data . . . . . . . . . . . 11		4.2.4. Controlling Configuration Data . . . . . . . . . . . 12
	4.3. Block-wise Transfer . . . . . . . . . . . . . . . . . . . 11		4.3. Block-wise Transfer . . . . . . . . . . . . . . . . . . . 12
	4.4. DOTS Multi-homing Considerations . . . . . . . . . . . . 11		4.4. DOTS Multi-homing Considerations . . . . . . . . . . . . 13
	4.5. YANG Considerations . . . . . . . . . . . . . . . . . . . 12		4.5. YANG Considerations . . . . . . . . . . . . . . . . . . . 13
	4.6. A Note About Examples . . . . . . . . . . . . . . . . . . 13		4.6. A Note About Examples . . . . . . . . . . . . . . . . . . 14
	5. Telemetry Operation Paths . . . . . . . . . . . . . . . . . . 13		5. Telemetry Operation Paths . . . . . . . . . . . . . . . . . . 15
	6. DOTS Telemetry Setup Configuration . . . . . . . . . . . . . 14		6. DOTS Telemetry Setup Configuration . . . . . . . . . . . . . 16
	6.1. Telemetry Configuration . . . . . . . . . . . . . . . . . 15		6.1. Telemetry Configuration . . . . . . . . . . . . . . . . . 16
	6.1.1. Retrieve Current DOTS Telemetry Configuration . . . . 15		6.1.1. Retrieve Current DOTS Telemetry Configuration . . . . 17
	6.1.2. Conveying DOTS Telemetry Configuration . . . . . . . 17		6.1.2. Conveying DOTS Telemetry Configuration . . . . . . . 19
	6.1.3. Retrieve Installed DOTS Telemetry Configuration . . . 20		6.1.3. Retrieve Installed DOTS Telemetry Configuration . . . 22
	6.1.4. Delete DOTS Telemetry Configuration . . . . . . . . . 21		6.1.4. Delete DOTS Telemetry Configuration . . . . . . . . . 23
	6.2. Total Pipe Capacity . . . . . . . . . . . . . . . . . . . 21		6.2. Total Pipe Capacity . . . . . . . . . . . . . . . . . . . 23
	6.2.1. Conveying DOTS Client Domain Pipe Capacity . . . . . 22		6.2.1. Conveying DOTS Client Domain Pipe Capacity . . . . . 24
	6.2.2. Retrieve Installed DOTS Client Domain Pipe Capacity . 28		6.2.2. Retrieve Installed DOTS Client Domain Pipe
	6.2.3. Delete Installed DOTS Client Domain Pipe Capacity . . 28		Capacity . . . . . . . . . . . . . . . . . . . . . . 30
	6.3. Telemetry Baseline . . . . . . . . . . . . . . . . . . . 28		6.2.3. Delete Installed DOTS Client Domain Pipe Capacity . . 30
	6.3.1. Conveying DOTS Client Domain Baseline Information . . 31		6.3. Telemetry Baseline . . . . . . . . . . . . . . . . . . . 30
	6.3.2. Retrieve Installed Normal Traffic Baseline . . . . . 35		6.3.1. Conveying DOTS Client Domain Baseline Information . . 33
	6.3.3. Delete Installed Normal Traffic Baseline . . . . . . 35		6.3.2. Retrieve Installed Normal Traffic Baseline . . . . . 37
	6.4. Reset Installed Telemetry Setup . . . . . . . . . . . . . 35		6.3.3. Delete Installed Normal Traffic Baseline . . . . . . 37
	6.5. Conflict with Other DOTS Clients of the Same Domain . . . 35		6.4. Reset Installed Telemetry Setup . . . . . . . . . . . . . 37
	7. DOTS Pre-or-Ongoing Mitigation Telemetry . . . . . . . . . . 36		6.5. Conflict with Other DOTS Clients of the Same Domain . . . 37
	7.1. Pre-or-Ongoing-Mitigation DOTS Telemetry Attributes . . . 38		7. DOTS Pre-or-Ongoing Mitigation Telemetry . . . . . . . . . . 38
	7.1.1. Target . . . . . . . . . . . . . . . . . . . . . . . 39		7.1. Pre-or-Ongoing-Mitigation DOTS Telemetry Attributes . . . 41
	7.1.2. Total Traffic . . . . . . . . . . . . . . . . . . . . 40		7.1.1. Target . . . . . . . . . . . . . . . . . . . . . . . 41
	7.1.3. Total Attack Traffic . . . . . . . . . . . . . . . . 42		7.1.2. Total Traffic . . . . . . . . . . . . . . . . . . . . 42
	7.1.4. Total Attack Connections . . . . . . . . . . . . . . 44		7.1.3. Total Attack Traffic . . . . . . . . . . . . . . . . 44
	7.1.5. Attack Details . . . . . . . . . . . . . . . . . . . 46		7.1.4. Total Attack Connections . . . . . . . . . . . . . . 46
	7.2. From DOTS Clients to DOTS Servers . . . . . . . . . . . . 53		7.1.5. Attack Details . . . . . . . . . . . . . . . . . . . 48
	7.3. From DOTS Servers to DOTS Clients . . . . . . . . . . . . 56		7.1.6. Vendor Attack Mapping . . . . . . . . . . . . . . . . 51
	8. DOTS Telemetry Mitigation Status Update . . . . . . . . . . . 61		7.2. From DOTS Clients to DOTS Servers . . . . . . . . . . . . 55
	8.1. DOTS Clients to Servers Mitigation Efficacy DOTS		7.3. From DOTS Servers to DOTS Clients . . . . . . . . . . . . 58
	Telemetry Attributes . . . . . . . . . . . . . . . . . . 61		8. DOTS Telemetry Mitigation Status Update . . . . . . . . . . . 63
	8.2. DOTS Servers to Clients Mitigation Status DOTS Telemetry		8.1. DOTS Clients to Servers Mitigation Efficacy DOTS Telemetry
	Attributes . . . . . . . . . . . . . . . . . . . . . . . 63		Attributes . . . . . . . . . . . . . . . . . . . . . . . 63
	9. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 67		8.2. DOTS Servers to Clients Mitigation Status DOTS Telemetry
	10. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 68		Attributes . . . . . . . . . . . . . . . . . . . . . . . 65
	10.1. DOTS Signal Channel Telemetry YANG Module . . . . . . . 68		9. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 69
			10. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 70
			10.1. DOTS Signal Channel Telemetry YANG Module . . . . . . . 70
	10.2. Vendor Attack Mapping Details YANG Module . . . . . . . 99		10.2. Vendor Attack Mapping Details YANG Module . . . . . . . 99
	11. YANG/JSON Mapping Parameters to CBOR . . . . . . . . . . . . 102		11. YANG/JSON Mapping Parameters to CBOR . . . . . . . . . . . . 102
	12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 105		12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 105
	12.1. DOTS Signal Channel CBOR Key Values . . . . . . . . . . 105		12.1. DOTS Signal Channel CBOR Key Values . . . . . . . . . . 105
	12.2. DOTS Signal Channel Conflict Cause Codes . . . . . . . . 107		12.2. DOTS Signal Channel Conflict Cause Codes . . . . . . . . 108
	12.3. DOTS Signal Telemetry YANG Module . . . . . . . . . . . 108		12.3. DOTS Signal Telemetry YANG Module . . . . . . . . . . . 108
	13. Security Considerations . . . . . . . . . . . . . . . . . . . 108		13. Security Considerations . . . . . . . . . . . . . . . . . . . 109
	13.1. DOTS Signal Channel Telemetry . . . . . . . . . . . . . 108		13.1. DOTS Signal Channel Telemetry . . . . . . . . . . . . . 109
	13.2. Vendor Attack Mapping . . . . . . . . . . . . . . . . . 109		13.2. Vendor Attack Mapping . . . . . . . . . . . . . . . . . 110
	14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 110		14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 111
	15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 110		15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 111
	16. References . . . . . . . . . . . . . . . . . . . . . . . . . 111		16. References . . . . . . . . . . . . . . . . . . . . . . . . . 111
	16.1. Normative References . . . . . . . . . . . . . . . . . . 111		16.1. Normative References . . . . . . . . . . . . . . . . . . 111
	16.2. Informative References . . . . . . . . . . . . . . . . . 112		16.2. Informative References . . . . . . . . . . . . . . . . . 113
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 114		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 115
	1. Introduction		1. Introduction
	Distributed Denial of Service (DDoS) attacks have become more		IT organizations and service providers are facing Distributed Denial
	sophisticated. IT organizations and service providers are facing		of Service (DDoS) attacks that fall into two broad categories:
	DDoS attacks that fall into two broad categories:
	1. Network/Transport layer attacks target the victim's		1. Network/Transport layer attacks target the victim's
	infrastructure. These attacks are not necessarily aimed at		infrastructure. These attacks are not necessarily aimed at
	taking down the actual delivered services, but rather to prevent		taking down the actual delivered services, but rather to prevent
	various network elements (routers, switches, firewalls, transit		various network elements (routers, switches, firewalls, transit
	links, and so on) from serving legitimate users' traffic.		links, and so on) from serving legitimate users' traffic.
	The main method of such attacks is to send a large volume or high		The main method of such attacks is to send a large volume or high
	packet per second (pps) of traffic toward the victim's		packet per second (pps) of traffic toward the victim's
	infrastructure. Typically, attack volumes may vary from a few		infrastructure. Typically, attack volumes may vary from a few
	100 Mbps to 100s of Gbps or even Tbps. Attacks are commonly		100 Mbps to 100s of Gbps or even Tbps. Attacks are commonly
	carried out leveraging botnets and attack reflectors for		carried out leveraging botnets and attack reflectors for
	amplification attacks such as NTP (Network Time Protocol), DNS		amplification attacks (Section 3.1 of [RFC4732]) such as NTP
	(Domain Name System), SNMP (Simple Network Management Protocol),		(Network Time Protocol), DNS (Domain Name System), SNMP (Simple
	or SSDP (Simple Service Discovery Protocol).		Network Management Protocol), or SSDP (Simple Service Discovery
			Protocol).
	2. Application layer attacks target various applications. Typical		2. Application layer attacks target various applications. Typical
	examples include attacks against HTTP/HTTPS, DNS, SIP (Session		examples include attacks against HTTP/HTTPS, DNS, SIP (Session
	Initiation Protocol), or SMTP (Simple Mail Transfer Protocol).		Initiation Protocol), or SMTP (Simple Mail Transfer Protocol).
	However, all applications with their port numbers open at network		However, all applications with their port numbers open at network
	edges can be attractive attack targets.		edges can be attractive attack targets.
	Application layer attacks are considered more complex and hard to		Application layer attacks are considered more complex and hard to
	categorize, and therefore harder to detect and mitigate		categorize, and therefore harder to detect and mitigate
	efficiently.		efficiently.
	skipping to change at page 5, line 38 ¶		skipping to change at page 5, line 41 ¶
	Both DOTS clients and servers can benefit from this information by		Both DOTS clients and servers can benefit from this information by
	presenting various information in relevant management, reporting, and		presenting various information in relevant management, reporting, and
	portal systems.		portal systems.
	This document defines DOTS telemetry attributes that can be conveyed		This document defines DOTS telemetry attributes that can be conveyed
	by DOTS clients to DOTS servers, and vice versa. The DOTS telemetry		by DOTS clients to DOTS servers, and vice versa. The DOTS telemetry
	attributes are not mandatory attributes of the DOTS signal channel		attributes are not mandatory attributes of the DOTS signal channel
	protocol [RFC9132]. Nevertheless, when DOTS telemetry attributes are		protocol [RFC9132]. Nevertheless, when DOTS telemetry attributes are
	available to a DOTS agent, and absent any limitation by policy, it		available to a DOTS agent, and absent any limitation by policy, it
	can signal the attributes in order to optimize the overall mitigation		can signal the attributes in order to optimize the overall mitigation
	service provisioned using DOTS.		service provisioned using DOTS. The aforementioned policy can be,
			for example, agreed during a service subscription (that is out of
			scope) to identify a subset of DOTS clients among those deployed in a
			DOTS client domain that are allowed to send or receive telemetry
			data.
	2. Terminology		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119][RFC8174] when, and only when, they appear in all		14 [RFC2119][RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	The reader should be familiar with the terms defined in [RFC8612].		The reader should be familiar with the terms defined in [RFC8612].
	skipping to change at page 6, line 23 ¶		skipping to change at page 6, line 36 ¶
	DOTS clients to uniquely identify DOTS telemetry data that is		DOTS clients to uniquely identify DOTS telemetry data that is
	communicated prior to or during a mitigation.		communicated prior to or during a mitigation.
	When two telemetry requests overlap, "overlapped" lower numeric		When two telemetry requests overlap, "overlapped" lower numeric
	'tsid' (or 'tmid') refers to the lower 'tsid' (or 'tmid') value of		'tsid' (or 'tmid') refers to the lower 'tsid' (or 'tmid') value of
	these overlapping requests.		these overlapping requests.
	The meaning of the symbols in YANG tree diagrams are defined in		The meaning of the symbols in YANG tree diagrams are defined in
	[RFC8340] and [RFC8791].		[RFC8340] and [RFC8791].
			Consistent with the convention set in Section 2 of [RFC8783], the
			examples in Section 7.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 backslash ('\') as the last character, the line is wrapped
			for display purposes. It is to be considered to be joined to the
			next line by deleting the backslash, the following line break, and
			the leading whitespace of the next line.
	3. DOTS Telemetry: Overview and Purpose		3. DOTS Telemetry: Overview and Purpose
	Timely and effective signaling of up-to-date DDoS telemetry to all		Timely and effective signaling of up-to-date DDoS telemetry to all
	elements involved in the mitigation process is essential and improves		elements involved in the mitigation process is essential and improves
	the overall DDoS mitigation service effectiveness. Bi-directional		the overall DDoS mitigation service effectiveness. Bi-directional
	feedback between DOTS agents is required for increased awareness by		feedback between DOTS agents is required for increased awareness by
	each party of the attack and mitigation efforts, supporting a		each party of the attack and mitigation efforts, supporting a
	superior and highly efficient attack mitigation service.		superior and highly efficient attack mitigation service.
	3.1. Need More Visibility		3.1. Need More Visibility
	skipping to change at page 7, line 37 ¶		skipping to change at page 8, line 9 ¶
	In addition, management and orchestration systems, at both DOTS		In addition, management and orchestration systems, at both DOTS
	client and server sides, can use DOTS telemetry as a feedback to		client and server sides, can use DOTS telemetry as a feedback to
	automate various control and management activities derived from		automate various control and management activities derived from
	signaled telemetry information.		signaled telemetry information.
	If the DOTS server's mitigation resources have the capabilities to		If the DOTS server's mitigation resources have the capabilities to
	facilitate the DOTS telemetry, the DOTS server adapts its protection		facilitate the DOTS telemetry, the DOTS server adapts its protection
	strategy and activates the required countermeasures immediately		strategy and activates the required countermeasures immediately
	(automation enabled) for the sake of optimized attack mitigation		(automation enabled) for the sake of optimized attack mitigation
	decisions and actions.		decisions and actions. The interface from the DOTS server to the
			mitigator to signal the telemetry data is out of scope.
	3.2. Enhanced Detection		3.2. Enhanced Detection
	DOTS telemetry can also be used to tune the DDoS mitigators with the		DOTS telemetry can also be used as input for determining what values
	correct state of an attack. During the last few years, DDoS attack		to use for the tuning parameters available on the mitigation
	detection technologies have evolved from threshold-based detection		resources. During the last few years, DDoS attack detection
	(that is, cases when all or specific parts of traffic cross a		technologies have evolved from threshold-based detection (that is,
	predefined threshold for a certain period of time is considered as an		cases when all or specific parts of traffic cross a predefined
	attack) to an "anomaly detection" approach. For the latter, it is		threshold for a certain period of time is considered as an attack) to
	required to maintain rigorous learning of "normal" behavior, and an		an "anomaly detection" approach. For the latter, it is required to
	"anomaly" (or an attack) is identified and categorized based on the		maintain rigorous learning of "normal" behavior, and an "anomaly" (or
	knowledge about the normal behavior and a deviation from this normal		an attack) is identified and categorized based on the knowledge about
	behavior. Machine learning approaches are used such that the actual		the normal behavior and a deviation from this normal behavior.
	traffic thresholds are automatically calculated by learning the		Machine learning approaches are used such that the actual traffic
	protected entity's normal traffic behavior during idle time. The		thresholds are automatically calculated by learning the protected
	normal traffic characterization learned is referred to as the "normal		entity's normal traffic behavior during 'idle' time (i.e., no
	traffic baseline". An attack is detected when the victim's actual		mitigation is active). The normal traffic characterization learned
	traffic is deviating from this normal baseline pattern.		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.
	In addition, subsequent activities toward mitigating an attack are		In addition, subsequent activities toward mitigating an attack are
	much more challenging. The ability to distinguish legitimate traffic		much more challenging. The ability to distinguish legitimate traffic
	from attacker traffic on a per packet basis is complex. For example,		from attacker traffic on a per packet basis is complex. For example,
	a packet may look "legitimate" and no attack signature can be		a packet may look "legitimate" and no attack signature can be
	identified. The anomaly can be identified only after detailed		identified. The anomaly can be identified only after detailed
	statistical analysis. DDoS attack mitigators use the normal baseline		statistical analysis. DDoS attack mitigators use the normal baseline
	during the mitigation of an attack to identify and categorize the		during the mitigation of an attack to identify and categorize the
	expected appearance of a specific traffic pattern. Particularly, the		expected appearance of a specific traffic pattern. Particularly, the
	mitigators use the normal baseline to recognize the "level of		mitigators use the normal baseline to recognize the "level of
	skipping to change at page 8, line 41 ¶		skipping to change at page 9, line 18 ¶
	benefits from this telemetry by tuning its mitigation resources with		benefits from this telemetry by tuning its mitigation resources with
	the DOTS client's normal baseline. The DOTS server mitigators use		the DOTS client's normal baseline. The DOTS server mitigators use
	the baseline to familiarize themselves with the attack victim's		the baseline to familiarize themselves with the attack victim's
	normal behavior and target the baseline as the level of normality		normal behavior and target the baseline as the level of normality
	they need to achieve. Fed with this information, the overall		they need to achieve. Fed with this information, the overall
	mitigation performances is expected to be improved in terms of time		mitigation performances is expected to be improved in terms of time
	to mitigate, accuracy, and false-negative and false-positive rates.		to mitigate, accuracy, and false-negative and false-positive rates.
	Mitigation of attacks without having certain knowledge of normal		Mitigation of attacks without having certain knowledge of normal
	traffic can be inaccurate at best. This is especially true for		traffic can be inaccurate at best. This is especially true for
	recursive signaling (see Section 3.2.3 of [RFC8903]). In addition,		recursive signaling (see Section 3.2.3 of [RFC8811]). Given that
	the highly diverse types of use cases where DOTS clients are		DOTS clients can be integrated in a highly diverse set of scenarios
	integrated also emphasize the need for knowledge of each DOTS client		and use cases, this emphasizes the need for knowledge of each DOTS
	domain behavior. Consequently, common global thresholds for attack		client domain behavior especially that common global thresholds for
	detection practically cannot be realized. Each DOTS client domain		attack detection practically cannot be realized. Each DOTS client
	can have its own levels of traffic and normal behavior. Without		domain can have its own levels of traffic and normal behavior.
	facilitating normal baseline signaling, it may be very difficult for		Without facilitating normal baseline signaling, it may be very
	DOTS servers in some cases to detect and mitigate the attacks		difficult for DOTS servers in some cases to detect and mitigate the
	accurately:		attacks accurately:
	It is important to emphasize that it is practically impossible for		It is important to emphasize that it is practically impossible for
	the DOTS server's mitigators to calculate the normal baseline in		the DOTS server's mitigators to calculate the normal baseline in
	cases where they do not have any knowledge of the traffic		cases where they do not have any knowledge of the traffic
	beforehand.		beforehand.
	In addition, baseline learning requires a period of time that		In addition, baseline learning requires a period of time that
	cannot be afforded during active attack.		cannot be afforded during active attack.
	Of course, this information can provided using out-of-band mechanisms		Of course, this information can provided using out-of-band mechanisms
	skipping to change at page 10, line 9 ¶		skipping to change at page 10, line 27 ¶
	in [RFC8783] is a reasonable candidate to achieve this objective; the		in [RFC8783] is a reasonable candidate to achieve this objective; the
	DOTS client can indicate the type(s) of traffic (such as ICMP, UDP,		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		TCP port number 80) it prefers to limit. The rate-limit action can
	be controlled via the signal channel [RFC9133] even when the pipe is		be controlled via the signal channel [RFC9133] even when the pipe is
	overwhelmed.		overwhelmed.
	4. Design Overview		4. Design Overview
	4.1. Overview of Telemetry Operations		4.1. Overview of Telemetry Operations
			The DOTS protocol suite is divided into two logical channels: the
			signal channel [RFC9132] and data channel [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, e.g., 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 (Section 2.2 of
			[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 (Section 2.3 of
			[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 truly require reliable delivery during an attack.
			Telemetry information has aspects that correspond to both operational
			modes (i.e., signal and data channels): 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, but it is also useful to provide mitigation
			services with a picture of normal or "baseline" traffic towards
			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 attack so that a
			short attack identifier can be used during attack time to describe an
			observed attack. This specification does make provision for use of
			the DOTS data channel for the latter function (Section 7.1.6), but
			otherwise retains most telemetry functionality in the DOTS signal
			channel.
			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.
	This document specifies an extension to the DOTS signal channel		This document specifies an extension to the DOTS signal channel
	protocol. Considerations about how to establish, maintain, and make		protocol. Considerations about how to establish, maintain, and make
	use of the DOTS signal channel are specified in [RFC9132].		use of the DOTS signal channel are specified in [RFC9132].
	Once the DOTS signal channel is established, DOTS clients that		Once the DOTS signal channel is established, DOTS clients that
	support the DOTS telemetry extension proceed with the telemetry setup		support the DOTS telemetry extension proceed with the telemetry setup
	configuration (e.g., measurement interval, telemetry notification		configuration (e.g., measurement interval, telemetry notification
	interface, pipe capacity, normal traffic baseline) as detailed in		interval, pipe capacity, normal traffic baseline) as detailed in
	Section 6. DOTS agents can then include DOTS telemetry attributes		Section 6. DOTS agents can then include DOTS telemetry attributes
	using the DOTS signal channel (Section 7.1). A DOTS client can use		using the DOTS signal channel (Section 7.1). A DOTS client can use
	separate messages to share with its DOTS server(s) a set of telemetry		separate messages to share with its DOTS server(s) a set of telemetry
	data bound to an ongoing mitigation (Section 7.2). Also, a DOTS		data bound to an ongoing mitigation (Section 7.2). Also, a DOTS
	client that is interested in receiving telemetry notifications		client that is interested in receiving telemetry notifications
	related to some of its resources follows the procedure defined in		related to some of its resources follows the procedure defined in
	Section 7.3. The DOTS client can then decide to send a mitigation		Section 7.3. The DOTS client can then decide to send a mitigation
	request if the notified attack cannot be mitigated locally within the		request if the notified attack cannot be mitigated locally within the
	DOTS client domain.		DOTS client domain.
	skipping to change at page 11, line 30 ¶		skipping to change at page 12, line 43 ¶
	Section of 4.4.2 of [RFC9132]. These considerations are not		Section of 4.4.2 of [RFC9132]. These considerations are not
	reiterated in the following sections.		reiterated in the following sections.
	4.3. Block-wise Transfer		4.3. Block-wise Transfer
	DOTS clients can use block wise transfer [RFC7959] with the		DOTS clients can use block wise transfer [RFC7959] with the
	recommendation detailed in Section 4.4.2 of [RFC9132] to control the		recommendation detailed in Section 4.4.2 of [RFC9132] to control the
	size of a response when the data to be returned does not fit within a		size of a response when the data to be returned does not fit within a
	single datagram.		single datagram.
	DOTS clients can also use CoAP Block1 Option in a PUT request (see		DOTS clients can also use CoAP Block1 Option in a PUT request
	Section 2.5 of [RFC7959]) to initiate large transfers, but these		(Section 2.5 of [RFC7959]) to initiate large transfers, but these
	Block1 transfers will fail if the inbound "pipe" is running full, so		Block1 transfers is likely to fail if the inbound "pipe" is running
	consideration needs to be made to try to fit this PUT into a single		full because the transfer requires a message from the server for each
	transfer, or to separate out the PUT into several discrete PUTs where		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.		each of them fits into a single packet.
	Q-Block1 and Q-Block2 Options that are similar to the CoAP Block1 and		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		Block2 Options, but enable robust transmissions of big blocks of data
	with less packet interchanges using NON messages, are defined in		with less packet interchanges using NON messages, are defined in
	[I-D.ietf-core-new-block]. DOTS implementations can consider the use		[I-D.ietf-core-new-block]. DOTS implementations can consider the use
	of Q-Block1 and Q-Block2 Options [I-D.ietf-dots-robust-blocks].		of Q-Block1 and Q-Block2 Options [I-D.ietf-dots-robust-blocks].
	4.4. DOTS Multi-homing Considerations		4.4. DOTS Multi-homing Considerations
	skipping to change at page 12, line 49 ¶		skipping to change at page 14, line 16 ¶
	requirements for DOTS Signal Channel messages.		requirements for DOTS Signal Channel messages.
	The DOTS telemetry module (Section 10.1) includes some lists for		The DOTS telemetry module (Section 10.1) includes some lists for
	which no key statement is included. This behavior is compliant with		which no key statement is included. This behavior is compliant with
	[RFC8791]. The reason for not including these keys is because they		[RFC8791]. The reason for not including these keys is because they
	are not included in the request message body but as mandatory Uri-		are not included in the request message body but as mandatory Uri-
	Paths in requests (Sections 6 and 7). Otherwise, whenever a key		Paths in requests (Sections 6 and 7). Otherwise, whenever a key
	statement is used in the module, the same definition as in		statement is used in the module, the same definition as in
	Section 7.8.2 of [RFC7950] is assumed.		Section 7.8.2 of [RFC7950] is assumed.
			The full tree diagram of the DOTS telemetry module can be generated
			using the "pyang" tool [PYANG]. That tree is not included here
			because it is too long (Section 3.3 of [RFC8340]). Instead, subtrees
			are provided for the reader's convenience.
	In order to optimize the data exchanged over the DOTS signal channel,		In order to optimize the data exchanged over the DOTS signal channel,
	the document specifies a second YANG module ("ietf-dots-mapping",		the document specifies a second YANG module ("ietf-dots-mapping",
	Section 10.2) that augments the DOTS data channel [RFC8783]. This		Section 10.2) that augments the DOTS data channel [RFC8783]. This
	augmentation can be used during idle time to share the attack mapping		augmentation can be used during 'idle' time to share the attack
	details (Section 7.1.5). DOTS clients can use tools, e.g., YANG		mapping details (Section 7.1.5). DOTS clients can use tools, e.g.,
	Library [RFC8525], to retrieve the list of features and deviations		YANG Library [RFC8525], to retrieve the list of features and
	supported by the DOTS server over the data channel.		deviations supported by the DOTS server over the data channel.
	4.6. A Note About Examples		4.6. A Note About Examples
	Examples are provided for illustration purposes. The document does		Examples are provided for illustration purposes. The document does
	not aim to provide a comprehensive list of message examples.		not aim to provide a comprehensive list of message examples.
	The authoritative reference for validating telemetry messages		The authoritative reference for validating telemetry messages
	exchanged over the DOTS signal channel are Sections 6, 7, and 8		exchanged over the DOTS signal channel are Sections 6, 7, and 8
	together with the mapping table established in Section 11. The		together with the mapping table established in Section 11. The
	structure of telemetry message bodies is represented as a YANG data		structure of telemetry message bodies is represented as a YANG data
	structure (Section 10.1).		structure (Section 10.1).
			JSON encoding of YANG-modeled data is used to illustrate the various
			telemetry operations.
			The examples use the Enterprise Number 32473 defined for
			documentation use [RFC5612].
	5. Telemetry Operation Paths		5. Telemetry Operation Paths
	As discussed in Section 4.2 of [RFC9132], each DOTS operation is		As discussed in Section 4.2 of [RFC9132], each DOTS operation is
	indicated by a path suffix that indicates the intended operation.		indicated by a path suffix that indicates the intended operation.
	The operation path is appended to the path prefix to form the URI		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		used with a CoAP request to perform the desired DOTS operation. The
	following telemetry path suffixes are defined (Table 1):		following telemetry path suffixes are defined (Table 1):
	+-----------------+----------------+-----------+		+-----------------+----------------+-----------+
	| Operation | Operation Path | Details |		| Operation | Operation Path | Details |
	skipping to change at page 14, line 21 ¶		skipping to change at page 15, line 45 ¶
	| +-- (setup-type)?		| +-- (setup-type)?
	| +--:(telemetry-config)		| +--:(telemetry-config)
	| | ...		| | ...
	| +--:(pipe)		| +--:(pipe)
	| | ...		| | ...
	| +--:(baseline)		| +--:(baseline)
	| ...		| ...
	+--:(telemetry)		+--:(telemetry)
	...		...
	Figure 1: New DOTS Message Types (YANG Tree Structure)		Figure 1: New DOTS Message Types (YANG Tree Structure)
			DOTS implementations MUST support the Observe Option for 'tm'
			(Section 7).
	6. DOTS Telemetry Setup Configuration		6. DOTS Telemetry Setup Configuration
	In reference to Figure 1, a DOTS telemetry setup message MUST include		In reference to Figure 1, a DOTS telemetry setup message MUST include
	only telemetry-related configuration parameters (Section 6.1) or		only telemetry-related configuration parameters (Section 6.1) or
	information about DOTS client domain pipe capacity (Section 6.2) or		information about DOTS client domain pipe capacity (Section 6.2) or
	telemetry traffic baseline (Section 6.3). As such, requests that		telemetry traffic baseline (Section 6.3). As such, requests that
	include a mix of telemetry configuration, pipe capacity, and traffic		include a mix of telemetry configuration, pipe capacity, and traffic
	baseline MUST be rejected by DOTS servers with a 4.00 (Bad Request).		baseline MUST be rejected by DOTS servers with a 4.00 (Bad Request).
	skipping to change at page 15, line 7 ¶		skipping to change at page 16, line 37 ¶
	with a DOTS client domain. DOTS servers MUST NOT reset 'tsid'		with a DOTS client domain. DOTS servers MUST NOT reset 'tsid'
	because a session failed with a DOTS client. DOTS clients update		because a session failed with a DOTS client. DOTS clients update
	their telemetry setup configuration upon change of a parameter that		their telemetry setup configuration upon change of a parameter that
	may impact attack mitigation.		may impact attack mitigation.
	DOTS telemetry setup configuration request and response messages are		DOTS telemetry setup configuration request and response messages are
	marked as Confirmable messages (Section 2.1 of [RFC7252]).		marked as Confirmable messages (Section 2.1 of [RFC7252]).
	6.1. Telemetry Configuration		6.1. Telemetry Configuration
			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 percentile). More details about percentile values and
			their computation are found in Section 11.3 of [RFC2330].
			DOTS telemetry uses up to three percentile values, plus the overall
			peak, to characterize traffic distributions. Which percentile
			thresholds are used for these "low", "medium", and "high" percentile
			values is configurable (with suitable defaults).
	A DOTS client can negotiate with its server(s) a set of telemetry		A DOTS client can negotiate with its server(s) a set of telemetry
	configuration parameters to be used for telemetry. Such parameters		configuration parameters to be used for telemetry. Such parameters
	include:		include:
	o Percentile-related measurement parameters		* Percentile-related measurement parameters. In particular,
			'measurement-interval' defines the period on which percentiles are
	o Measurement units		computed, while 'measurement-sample' defines the time distribution
			for measuring values that are used to compute percentiles.
	o Acceptable percentile values		* Measurement units
	o Telemetry notification interval		* Acceptable percentile values
	o Acceptable Server-originated telemetry		* Telemetry notification interval
	Section 11.3 of [RFC2330] includes more details about computing		* Acceptable Server-originated telemetry
	percentiles.
	6.1.1. Retrieve Current DOTS Telemetry Configuration		6.1.1. Retrieve Current DOTS Telemetry Configuration
	A GET request is used to obtain acceptable and current telemetry		A GET request is used to obtain acceptable and current telemetry
	configuration parameters on the DOTS server. This request may		configuration parameters on the DOTS server. This request may
	include a 'cdid' Uri-Path when the request is relayed by a DOTS		include a 'cdid' Uri-Path when the request is relayed by a DOTS
	gateway. An example of such a GET request (without gateway) is		gateway. An example of such a GET request (without gateway) is
	depicted in Figure 2.		depicted in Figure 2.
	Header: GET (Code=0.01)		Header: GET (Code=0.01)
	Uri-Path: ".well-known"		Uri-Path: ".well-known"
	Uri-Path: "dots"		Uri-Path: "dots"
	Uri-Path: "tm-setup"		Uri-Path: "tm-setup"
	Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"		Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
	Figure 2: GET to Retrieve Current and Acceptable DOTS Telemetry		Figure 2: GET to Retrieve Current and Acceptable DOTS Telemetry
	Configuration		Configuration
	Upon receipt of such a request, and assuming no error is encountered		Upon receipt of such a request, and assuming no error is encountered
	when processing the request, the DOTS server replies with a 2.05		when processing the request, the DOTS server replies with a 2.05
	(Content) response that conveys the current and telemetry parameters		(Content) response that conveys the telemetry parameters that are
	acceptable by the DOTS server. The tree structure of the response		acceptable by the DOTS server, any pipe information (Section 6.2),
	message body is provided in Figure 3. Note that the response also		and the current baseline information (Section 6.3) maintained by the
	includes any pipe (Section 6.2) and baseline information		DOTS server for this DOTS client. The tree structure of the response
	(Section 6.3) maintained by the DOTS server for this DOTS client.		message body is provided in Figure 3.
	DOTS servers that support the capability of sending telemetry		DOTS servers that support the capability of sending telemetry
	information to DOTS clients prior to or during a mitigation		information to DOTS clients prior to or during a mitigation
	(Section 8.2) sets 'server-originated-telemetry' under 'max-config-		(Section 8.2) sets 'server-originated-telemetry' under 'max-config-
	values' to 'true' ('false' is used otherwise). If 'server-		values' to 'true' ('false' is used otherwise). If 'server-
	originated-telemetry' is not present in a response, this is		originated-telemetry' is not present in a response, this is
	equivalent to receiving a response with 'server-originated-telemetry'		equivalent to receiving a response with 'server-originated-telemetry'
	set to 'false'.		set to 'false'.
	structure dots-telemetry:		structure dots-telemetry:
	skipping to change at page 16, line 20 ¶		skipping to change at page 18, line 25 ¶
	+--:(telemetry-setup)		+--:(telemetry-setup)
	| +-- (direction)?		| +-- (direction)?
	| | +--:(server-to-client-only)		| | +--:(server-to-client-only)
	| | +-- max-config-values		| | +-- max-config-values
	| | | +-- measurement-interval? interval		| | | +-- measurement-interval? interval
	| | | +-- measurement-sample? sample		| | | +-- measurement-sample? sample
	| | | +-- low-percentile? percentile		| | | +-- low-percentile? percentile
	| | | +-- mid-percentile? percentile		| | | +-- mid-percentile? percentile
	| | | +-- high-percentile? percentile		| | | +-- high-percentile? percentile
	| | | +-- server-originated-telemetry? boolean		| | | +-- server-originated-telemetry? boolean
	| | | +-- telemetry-notify-interval? uint32		| | | +-- telemetry-notify-interval? uint16
	| | +-- min-config-values		| | +-- min-config-values
	| | | +-- measurement-interval? interval		| | | +-- measurement-interval? interval
	| | | +-- measurement-sample? sample		| | | +-- measurement-sample? sample
	| | | +-- low-percentile? percentile		| | | +-- low-percentile? percentile
	| | | +-- mid-percentile? percentile		| | | +-- mid-percentile? percentile
	| | | +-- high-percentile? percentile		| | | +-- high-percentile? percentile
	| | | +-- telemetry-notify-interval? uint32		| | | +-- telemetry-notify-interval? uint16
	| | +-- supported-unit-classes		| | +-- supported-unit-classes
	| | | +-- unit-config* [unit]		| | | +-- unit-config* [unit]
	| | | +-- unit unit-class		| | | +-- unit unit-class
	| | | +-- unit-status boolean		| | | +-- unit-status boolean
	| | +-- query-type* query-type		| | +-- supported-query-type* query-type
	| +-- telemetry* []		| +-- telemetry* []
	| +-- (direction)?		| +-- (direction)?
	| | +--:(server-to-client-only)		| | +--:(server-to-client-only)
	| | +-- tsid? uint32		| | +-- tsid? uint32
	| +-- (setup-type)?		| +-- (setup-type)?
	| +--:(telemetry-config)		| +--:(telemetry-config)
	| | +-- current-config		| | +-- current-config
	| | +-- measurement-interval? interval		| | +-- measurement-interval? interval
	| | +-- measurement-sample? sample		| | +-- measurement-sample? sample
	| | +-- low-percentile? percentile		| | +-- low-percentile? percentile
	| | +-- mid-percentile? percentile		| | +-- mid-percentile? percentile
	| | +-- high-percentile? percentile		| | +-- high-percentile? percentile
	| | +-- unit-config* [unit]		| | +-- unit-config* [unit]
	| | | +-- unit unit-class		| | | +-- unit unit-class
	| | | +-- unit-status boolean		| | | +-- unit-status boolean
	| | +-- server-originated-telemetry? boolean		| | +-- server-originated-telemetry? boolean
	| | +-- telemetry-notify-interval? uint32		| | +-- telemetry-notify-interval? uint16
	| +--:(pipe)		| +--:(pipe)
	| | ...		| | ...
	| +--:(baseline)		| +--:(baseline)
	| ...		| ...
	+--:(telemetry)		+--:(telemetry)
	...		...
	Figure 3: Telemetry Configuration Tree Structure		Figure 3: Telemetry Configuration Tree Structure
	When both 'min-config-values' and 'max-config-values' attributes are		When both 'min-config-values' and 'max-config-values' attributes are
	present, the values carried in 'max-config-values' attributes MUST be		present, the values carried in 'max-config-values' attributes MUST be
	greater or equal to their counterpart in 'min-config-values'		greater or equal to their counterpart in 'min-config-values'
	attributes.		attributes.
	6.1.2. Conveying DOTS Telemetry Configuration		6.1.2. Conveying DOTS Telemetry Configuration
	A PUT request is used to convey the configuration parameters for the		A PUT request is used to convey the configuration parameters for the
	telemetry data (e.g., low, mid, or high percentile values). For		telemetry data (e.g., low, mid, or high percentile values). For
	skipping to change at page 17, line 48 ¶		skipping to change at page 20, line 4 ¶
	{		{
	"current-config": {		"current-config": {
	"low-percentile": "5.00",		"low-percentile": "5.00",
	"mid-percentile": "65.00",		"mid-percentile": "65.00",
	"high-percentile": "95.00"		"high-percentile": "95.00"
	}		}
	}		}
	]		]
	}		}
	}		}
			Figure 4: PUT to Convey the DOTS Telemetry Configuration
	Figure 4: PUT to Convey the DOTS Telemetry Configuration
	'cuid' is a mandatory Uri-Path parameter for PUT requests.		'cuid' is a mandatory Uri-Path parameter for PUT requests.
	The following additional Uri-Path parameter is defined:		The following additional Uri-Path parameter is defined:
	tsid: Telemetry Setup Identifier is an identifier for the DOTS		tsid: Telemetry Setup Identifier is an identifier for the DOTS
	telemetry setup configuration data represented as an integer.		telemetry setup configuration data represented as an integer.
	This identifier MUST be generated by DOTS clients. 'tsid'		This identifier MUST be generated by DOTS clients. 'tsid'
	values MUST increase monotonically (when a new PUT is generated		values MUST increase monotonically (when a new PUT is generated
	by a DOTS client to convey new configuration parameters for the		by a DOTS client to convey new configuration parameters for the
	skipping to change at page 18, line 34 ¶		skipping to change at page 20, line 37 ¶
	A PUT request with a higher numeric 'tsid' value overrides the DOTS		A PUT request with a higher numeric 'tsid' value overrides the DOTS
	telemetry configuration data installed by a PUT request with a lower		telemetry configuration data installed by a PUT request with a lower
	numeric 'tsid' value. To avoid maintaining a long list of 'tsid'		numeric 'tsid' value. To avoid maintaining a long list of 'tsid'
	requests for requests carrying telemetry configuration data from a		requests for requests carrying telemetry configuration data from a
	DOTS client, the lower numeric 'tsid' MUST be automatically deleted		DOTS client, the lower numeric 'tsid' MUST be automatically deleted
	and no longer be available at the DOTS server.		and no longer be available at the DOTS server.
	The DOTS server indicates the result of processing the PUT request		The DOTS server indicates the result of processing the PUT request
	using the following Response Codes:		using the following Response Codes:
	o If the request is missing a mandatory attribute, does not include		* If the request is missing a mandatory attribute, does not include
	'cuid' or 'tsid' Uri-Path parameters, or contains one or more		'cuid' or 'tsid' Uri-Path parameters, or contains one or more
	invalid or unknown parameters, 4.00 (Bad Request) MUST be returned		invalid or unknown parameters, 4.00 (Bad Request) MUST be returned
	in the response.		in the response.
	o If the DOTS server does not find the 'tsid' parameter value		* If the DOTS server does not find the 'tsid' parameter value
	conveyed in the PUT request in its configuration data and if the		conveyed in the PUT request in its configuration data and if the
	DOTS server has accepted the configuration parameters, then a 2.01		DOTS server has accepted the configuration parameters, then a 2.01
	(Created) Response Code MUST be returned in the response.		(Created) Response Code MUST be returned in the response.
	o If the DOTS server finds the 'tsid' parameter value conveyed in		* If the DOTS server finds the 'tsid' parameter value conveyed in
	the PUT request in its configuration data and if the DOTS server		the PUT request in its configuration data and if the DOTS server
	has accepted the updated configuration parameters, 2.04 (Changed)		has accepted the updated configuration parameters, 2.04 (Changed)
	MUST be returned in the response.		MUST be returned in the response.
	o If any of the enclosed configurable attribute values are not		* If any of the enclosed configurable attribute values are not
	acceptable to the DOTS server (Section 6.1.1), 4.22 (Unprocessable		acceptable to the DOTS server (Section 6.1.1), 4.22 (Unprocessable
	Entity) MUST be returned in the response.		Entity) MUST be returned in the response.
	The DOTS client may retry and send the PUT request with updated		The DOTS client may retry and send the PUT request with updated
	attribute values acceptable to the DOTS server.		attribute values acceptable to the DOTS server.
	By default, low percentile (10th percentile), mid percentile (50th		By default, low percentile (10th percentile), mid percentile (50th
	percentile), high percentile (90th percentile), and peak (100th		percentile), high percentile (90th percentile), and peak (100th
	percentile) values are used to represent telemetry data.		percentile) values are used to represent telemetry data.
	Nevertheless, a DOTS client can disable some percentile types (low,		Nevertheless, a DOTS client can disable some percentile types (low,
	skipping to change at page 20, line 30 ¶		skipping to change at page 22, line 37 ¶
	"telemetry": [		"telemetry": [
	{		{
	"current-config": {		"current-config": {
	"server-originated-telemetry": true		"server-originated-telemetry": true
	}		}
	}		}
	]		]
	}		}
	}		}
	Figure 6: PUT to Enable Pre-or-ongoing-mitigation Telemetry from the		Figure 6: PUT to Enable Pre-or-ongoing-mitigation Telemetry from
	DOTS server		the DOTS server
	6.1.3. Retrieve Installed DOTS Telemetry Configuration		6.1.3. Retrieve Installed DOTS Telemetry Configuration
	A DOTS client may issue a GET message with 'tsid' Uri-Path parameter		A DOTS client may issue a GET message with 'tsid' Uri-Path parameter
	to retrieve the current DOTS telemetry configuration. An example of		to retrieve the current DOTS telemetry configuration. An example of
	such request is depicted in Figure 7.		such a request is depicted in Figure 7.
	Header: GET (Code=0.01)		Header: GET (Code=0.01)
	Uri-Path: ".well-known"		Uri-Path: ".well-known"
	Uri-Path: "dots"		Uri-Path: "dots"
	Uri-Path: "tm-setup"		Uri-Path: "tm-setup"
	Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"		Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
	Uri-Path: "tsid=123"		Uri-Path: "tsid=123"
	Figure 7: GET to Retrieve Current DOTS Telemetry Configuration		Figure 7: GET to Retrieve Current DOTS Telemetry Configuration
	If the DOTS server does not find the 'tsid' Uri-Path value conveyed		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		in the GET request in its configuration data for the requesting DOTS
	client, it MUST respond with a 4.04 (Not Found) error Response Code.		client, it MUST respond with a 4.04 (Not Found) error Response Code.
	6.1.4. Delete DOTS Telemetry Configuration		6.1.4. Delete DOTS Telemetry Configuration
	A DELETE request is used to delete the installed DOTS telemetry		A DELETE request is used to delete the installed DOTS telemetry
	configuration data (Figure 8). 'cuid' and 'tsid' are mandatory Uri-		configuration data (Figure 8). 'cuid' and 'tsid' are mandatory Uri-
	Path parameters for such DELETE requests.		Path parameters for such DELETE requests.
	Header: DELETE (Code=0.04)		Header: DELETE (Code=0.04)
	Uri-Path: ".well-known"		Uri-Path: ".well-known"
	Uri-Path: "dots"		Uri-Path: "dots"
	Uri-Path: "tm-setup"		Uri-Path: "tm-setup"
	Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"		Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
	Uri-Path: "tsid=123"		Uri-Path: "tsid=123"
	Figure 8: Delete Telemetry Configuration		Figure 8: Delete Telemetry Configuration
	The DOTS server resets the DOTS telemetry configuration back to the		The DOTS server resets the DOTS telemetry configuration back to the
	default values and acknowledges a DOTS client's request to remove the		default values and acknowledges a DOTS client's request to remove the
	DOTS telemetry configuration using 2.02 (Deleted) Response Code. A		DOTS telemetry configuration using 2.02 (Deleted) Response Code. A
	2.02 (Deleted) Response Code is returned even if the 'tsid' parameter		2.02 (Deleted) Response Code is returned even if the 'tsid' parameter
	value conveyed in the DELETE request does not exist in its		value conveyed in the DELETE request does not exist in its
	configuration data before the request.		configuration data before the request.
	Section 6.4 discusses the procedure to reset all DOTS telemetry setup		Section 6.4 discusses the procedure to reset all DOTS telemetry setup
	configuration.		configuration.
	skipping to change at page 22, line 35 ¶		skipping to change at page 24, line 35 ¶
	Figure 9: Pipe Tree Structure		Figure 9: Pipe Tree Structure
	A DOTS client domain pipe is defined as a list of limits of		A DOTS client domain pipe is defined as a list of limits of
	(incoming) traffic volume ('total-pipe-capacity') that can be		(incoming) traffic volume ('total-pipe-capacity') that can be
	forwarded over ingress interconnection links of a DOTS client domain.		forwarded over ingress interconnection links of a DOTS client domain.
	Each of these links is identified with a 'link-id' [RFC8345].		Each of these links is identified with a 'link-id' [RFC8345].
	The unit used by a DOTS client when conveying pipe information is		The unit used by a DOTS client when conveying pipe information is
	captured in the 'unit' attribute. The DOTS client MUST auto-scale so		captured in the 'unit' attribute. The DOTS client MUST auto-scale so
	that the appropriate unit is used.		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.
	6.2.1. Conveying DOTS Client Domain Pipe Capacity		6.2.1. Conveying DOTS Client Domain Pipe Capacity
	Similar considerations to those specified in Section 6.1.2 are		Similar considerations to those specified in Section 6.1.2 are
	followed with one exception:		followed with one exception:
	The relative order of two PUT requests carrying DOTS client domain		The relative order of two PUT requests carrying DOTS client domain
	pipe attributes from a DOTS client is determined by comparing		pipe attributes from a DOTS client is determined by comparing
	their respective 'tsid' values. If such two requests have		their respective 'tsid' values. If such two requests have
	overlapping 'link-id' and 'unit', the PUT request with higher		overlapping 'link-id' and 'unit', the PUT request with higher
	skipping to change at page 23, line 10 ¶		skipping to change at page 25, line 14 ¶
	DOTS clients SHOULD minimize the number of active 'tsid's used for		DOTS clients SHOULD minimize the number of active 'tsid's used for
	pipe information. In order to avoid maintaining a long list of		pipe information. In order to avoid maintaining a long list of
	'tsid's for pipe information, it is RECOMMENDED that DOTS clients		'tsid's for pipe information, it is RECOMMENDED that DOTS clients
	include in any request to update information related to a given link		include in any request to update information related to a given link
	the information of other links (already communicated using a lower		the information of other links (already communicated using a lower
	'tsid' value). Doing so, this update request will override these		'tsid' value). Doing so, this update request will override these
	existing requests and hence optimize the number of 'tsid' request per		existing requests and hence optimize the number of 'tsid' request per
	DOTS client.		DOTS client.
	o Note: This assumes that all link information can fit in one single		* Note: This assumes that all link information can fit in one single
	message.		message.
	As an example of configuring pipe information, a DOTS client managing		As an example of configuring pipe information, a DOTS client managing
	a single homed domain (Figure 10) can send a PUT request (shown in		a single homed domain (Figure 10) can send a PUT request (shown in
	Figure 11) to communicate the capacity of "link1" used to connect to		Figure 11) to communicate the capacity of "link1" used to connect to
	its ISP.		its ISP.
	,--,--,--. ,--,--,--.		,--,--,--. ,--,--,--.
	,-' `-. ,-' `-.		,-' `-. ,-' `-.
	( DOTS Client )=====( ISP#A )		( DOTS Client )=====( ISP#A )
	`-. Domain ,-' link1 `-. ,-'		`-. Domain ,-' link1 `-. ,-'
	`--'--'--' `--'--'--'		`--'--'--' `--'--'--'
	Figure 10: Single Homed DOTS Client Domain		Figure 10: Single Homed DOTS Client Domain
	Header: PUT (Code=0.03)		Header: PUT (Code=0.03)
	Uri-Path: ".well-known"		Uri-Path: ".well-known"
	Uri-Path: "dots"		Uri-Path: "dots"
	Uri-Path: "tm-setup"		Uri-Path: "tm-setup"
	Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"		Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
	Uri-Path: "tsid=457"		Uri-Path: "tsid=457"
	Content-Format: "application/dots+cbor"		Content-Format: "application/dots+cbor"
	{		{
	skipping to change at page 23, line 49 ¶		skipping to change at page 26, line 4 ¶
	{		{
	"link-id": "link1",		"link-id": "link1",
	"capacity": "500",		"capacity": "500",
	"unit": "megabit-ps"		"unit": "megabit-ps"
	}		}
	]		]
	}		}
	]		]
	}		}
	}		}
			Figure 11: Example of a PUT Request to Convey Pipe Information
	Figure 11: Example of a PUT Request to Convey Pipe Information		(Single Homed)
	(Single Homed)
	DOTS clients may be instructed to signal a link aggregate instead of		DOTS clients may be instructed to signal a link aggregate instead of
	individual links. For example, a DOTS client that manages a DOTS		individual links. For example, a DOTS client that manages a DOTS
	client domain having two interconnection links with an upstream ISP		client domain having two interconnection links with an upstream ISP
	(Figure 12) can send a PUT request (shown in Figure 13) to		(Figure 12) can send a PUT request (shown in Figure 13) to
	communicate the aggregate link capacity with its ISP. Signalling		communicate the aggregate link capacity with its ISP. Signaling
	individual or aggregate link capacity is deployment specific.		individual or aggregate link capacity is deployment specific.
	,--,--,--. ,--,--,--.		,--,--,--. ,--,--,--.
	,-' `-.===== ,-' `-.		,-' `-.===== ,-' `-.
	( DOTS Client ) ( ISP#C )		( DOTS Client ) ( ISP#C )
	`-. Domain ,-'====== `-. ,-'		`-. Domain ,-'====== `-. ,-'
	`--'--'--' `--'--'--'		`--'--'--' `--'--'--'
	Figure 12: DOTS Client Domain with Two Interconnection Links		Figure 12: DOTS Client Domain with Two Interconnection Links
	Header: PUT (Code=0.03)		Header: PUT (Code=0.03)
	Uri-Path: ".well-known"		Uri-Path: ".well-known"
	Uri-Path: "dots"		Uri-Path: "dots"
	Uri-Path: "tm-setup"		Uri-Path: "tm-setup"
	Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"		Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
	Uri-Path: "tsid=896"		Uri-Path: "tsid=896"
	Content-Format: "application/dots+cbor"		Content-Format: "application/dots+cbor"
	{		{
	skipping to change at page 24, line 44 ¶		skipping to change at page 26, line 46 ¶
	"link-id": "aggregate",		"link-id": "aggregate",
	"capacity": "700",		"capacity": "700",
	"unit": "megabit-ps"		"unit": "megabit-ps"
	}		}
	]		]
	}		}
	]		]
	}		}
	}		}
	Figure 13: Example of a PUT Request to Convey Pipe Information		Figure 13: Example of a PUT Request to Convey Pipe Information
	(Aggregated Link)		(Aggregated Link)
	Now consider that the DOTS client domain was upgraded to connect to		Now consider that the DOTS client domain was upgraded to connect to
	an additional ISP (e.g., ISP#B of Figure 14); the DOTS client can		an additional ISP (e.g., ISP#B of Figure 14); the DOTS client can
	inform a third-party DOTS server (that is, not hosted with ISP#A and		inform a third-party DOTS server (that is, not hosted with ISP#A and
	ISP#B domains) about this update by sending the PUT request depicted		ISP#B domains) about this update by sending the PUT request depicted
	in Figure 15. This request also includes information related to		in Figure 15. This request also includes information related to
	"link1" even if that link is not upgraded. Upon receipt of this		"link1" even if that link is not upgraded. Upon receipt of this
	request, the DOTS server removes the request with 'tsid=457' and		request, the DOTS server removes the request with 'tsid=457' and
	updates its configuration base to maintain two links (link#1 and		updates its configuration base to maintain two links (link#1 and
	skipping to change at page 26, line 34 ¶		skipping to change at page 28, line 34 ¶
	"link-id": "link2",		"link-id": "link2",
	"capacity": "500",		"capacity": "500",
	"unit": "megabit-ps"		"unit": "megabit-ps"
	}		}
	]		]
	}		}
	]		]
	}		}
	}		}
	Figure 15: Example of a PUT Request to Convey Pipe Information		Figure 15: Example of a PUT Request to Convey Pipe Information
	(Multi-Homed)		(Multi-Homed)
	A DOTS client can delete a link by sending a PUT request with the		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		'capacity' attribute set to "0" if other links are still active for
	the same DOTS client domain (see Section 6.2.3 for other delete		the same DOTS client domain (see Section 6.2.3 for other delete
	cases). For example, if a DOTS client domain re-homes (that is, it		cases). For example, if a DOTS client domain re-homes (that is, it
	changes its ISP), the DOTS client can inform its DOTS server about		changes its ISP), the DOTS client can inform its DOTS server about
	this update (e.g., from the network configuration in Figure 10 to the		this update (e.g., from the network configuration in Figure 10 to the
	one shown in Figure 16) by sending the PUT request depicted in		one shown in Figure 16) by sending the PUT request depicted in
	Figure 17. Upon receipt of this request, and assuming no error is		Figure 17. Upon receipt of this request, and assuming no error is
	skipping to change at page 27, line 49 ¶		skipping to change at page 29, line 49 ¶
	"link-id": "link2",		"link-id": "link2",
	"capacity": "500",		"capacity": "500",
	"unit": "megabit-ps"		"unit": "megabit-ps"
	}		}
	]		]
	}		}
	]		]
	}		}
	}		}
	Figure 17: Example of a PUT Request to Convey Pipe Information		Figure 17: Example of a PUT Request to Convey Pipe Information
	(Multi-Homed)		(Multi-Homed)
	6.2.2. Retrieve Installed DOTS Client Domain Pipe Capacity		6.2.2. Retrieve Installed DOTS Client Domain Pipe Capacity
	A GET request with 'tsid' Uri-Path parameter is used to retrieve a		A GET request with 'tsid' Uri-Path parameter is used to retrieve a
	specific installed DOTS client domain pipe related information. The		specific installed DOTS client domain pipe related information. The
	same procedure as defined in Section 6.1.3 is followed.		same procedure as defined in Section 6.1.3 is followed.
	To retrieve all pipe information bound to a DOTS client, the DOTS		To retrieve all pipe information bound to a DOTS client, the DOTS
	client proceeds as specified in Section 6.1.1.		client proceeds as specified in Section 6.1.1.
	skipping to change at page 29, line 21 ¶		skipping to change at page 31, line 21 ¶
	* The maximum number of simultaneous embryonic connections that		* The maximum number of simultaneous embryonic connections that
	are allowed to the target per client.		are allowed to the target per client.
	* The maximum number of connections allowed per second to the		* The maximum number of connections allowed per second to the
	target.		target.
	* The maximum number of connections allowed per second to the		* The maximum number of connections allowed per second to the
	target per client.		target per client.
	* The maximum number of requests allowed per second to the		* The maximum number of requests (e.g., HTTP/DNS/SIP requests)
	target.		allowed per second to the target.
	* The maximum number of requests allowed per second to the target		* The maximum number of requests allowed per second to the target
	per client.		per client.
	* The maximum number of partial requests allowed per second to		* The maximum number of outstanding partial requests allowed to
	the target. Attacks relying upon partial requests create a		the target. Attacks relying upon partial requests create a
	connection with a target but do not send a complete request		connection with a target but do not send a complete request
	(e.g., HTTP request).		(e.g., HTTP request).
	* The maximum number of partial requests allowed per second to		* The maximum number of outstanding partial requests allowed to
	the target per client.		the target per client.
	The aggregate per transport protocol is captured in 'total-		The aggregate per transport protocol is captured in 'total-
	connection-capacity', while port-specific capabilities are		connection-capacity', while port-specific capabilities are
	represented using 'total-connection-capacity-per-port'.		represented using 'total-connection-capacity-per-port'.
	Note that a target resource is identified using the attributes		Note that a target resource is identified using the attributes
	'target-prefix', 'target-port-range', 'target-protocol', 'target-		'target-prefix', 'target-port-range', 'target-protocol', 'target-
	fqdn', 'target-uri', or 'alias-name' defined in Section 4.4.1.1 of		fqdn', 'target-uri', or 'alias-name' defined in Section 4.4.1.1 of
	[RFC9132].		[RFC9132].
	skipping to change at page 31, line 10 ¶		skipping to change at page 33, line 10 ¶
	| +-- total-connection-capacity* [protocol]		| +-- total-connection-capacity* [protocol]
	| | +-- protocol uint8		| | +-- protocol uint8
	| | +-- connection? uint64		| | +-- connection? uint64
	| | +-- connection-client? uint64		| | +-- connection-client? uint64
	| | +-- embryonic? uint64		| | +-- embryonic? uint64
	| | +-- embryonic-client? uint64		| | +-- embryonic-client? uint64
	| | +-- connection-ps? uint64		| | +-- connection-ps? uint64
	| | +-- connection-client-ps? uint64		| | +-- connection-client-ps? uint64
	| | +-- request-ps? uint64		| | +-- request-ps? uint64
	| | +-- request-client-ps? uint64		| | +-- request-client-ps? uint64
	| | +-- partial-request-ps? uint64		| | +-- partial-request-max? uint64
	| | +-- partial-request-client-ps? uint64		| | +-- partial-request-client-max? uint64
	| +-- total-connection-capacity-per-port*		| +-- total-connection-capacity-per-port*
	| [protocol port]		| [protocol port]
	| +-- port		| +-- port
	| | inet:port-number		| | inet:port-number
	| +-- protocol uint8		| +-- protocol uint8
	| +-- connection? uint64		| +-- connection? uint64
	| +-- connection-client? uint64		| +-- connection-client? uint64
	| +-- embryonic? uint64		| +-- embryonic? uint64
	| +-- embryonic-client? uint64		| +-- embryonic-client? uint64
	| +-- connection-ps? uint64		| +-- connection-ps? uint64
	| +-- connection-client-ps? uint64		| +-- connection-client-ps? uint64
	| +-- request-ps? uint64		| +-- request-ps? uint64
	| +-- request-client-ps? uint64		| +-- request-client-ps? uint64
	| +-- partial-request-ps? uint64		| +-- partial-request-max? uint64
	| +-- partial-request-client-ps? uint64		| +-- partial-request-client-max? uint64
	+--:(telemetry)		+--:(telemetry)
	...		...
	Figure 18: Telemetry Baseline Tree Structure		Figure 18: Telemetry Baseline Tree Structure
			A DOTS client can share one or multiple normal traffic baselines
			(e.g., aggregate or per-prefix baselines), each are 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.
	6.3.1. Conveying DOTS Client Domain Baseline Information		6.3.1. Conveying DOTS Client Domain Baseline Information
	Similar considerations to those specified in Section 6.1.2 are		Similar considerations to those specified in Section 6.1.2 are
	followed with one exception:		followed with one exception:
	The relative order of two PUT requests carrying DOTS client domain		The relative order of two PUT requests carrying DOTS client domain
	baseline attributes from a DOTS client is determined by comparing		baseline attributes from a DOTS client is determined by comparing
	their respective 'tsid' values. If such two requests have		their respective 'tsid' values. If such two requests have
	overlapping targets, the PUT request with higher numeric 'tsid'		overlapping targets, the PUT request with higher numeric 'tsid'
	value will override the request with a lower numeric 'tsid' value.		value will override the request with a lower numeric 'tsid' value.
	The overlapped lower numeric 'tsid' MUST be automatically deleted		The overlapped lower numeric 'tsid' MUST be automatically deleted
	and no longer be available.		and no longer be available.
	Two PUT requests from a DOTS client have overlapping targets if there		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,		is a common IP address, IP prefix, FQDN, URI, or alias-name. Also,
	two PUT requests from a DOTS client have overlapping targets if the		two PUT requests from a DOTS client have overlapping targets from the
	addresses associated with the FQDN, URI, or alias are overlapping		perspective of the DOTS server if the addresses associated with the
	with each other or with 'target-prefix'.		FQDN, URI, or alias are overlapping with each other or with 'target-
			prefix'.
	DOTS clients SHOULD minimize the number of active 'tsid's used for		DOTS clients SHOULD minimize the number of active 'tsid's used for
	baseline information. In order to avoid maintaining a long list of		baseline information. In order to avoid maintaining a long list of
	'tsid's for baseline information, it is RECOMMENDED that DOTS clients		'tsid's for baseline information, it is RECOMMENDED that DOTS clients
	include in a request to update information related to a given target,		include in a request to update information related to a given target,
	the information of other targets (already communicated using a lower		the information of other targets (already communicated using a lower
	'tsid' value) (assuming this fits within one single datagram). This		'tsid' value) (assuming this fits within one single datagram). This
	update request will override these existing requests and hence		update request will override these existing requests and hence
	optimize the number of 'tsid' request per DOTS client.		optimize the number of 'tsid' request per DOTS client.
	skipping to change at page 34, line 43 ¶		skipping to change at page 36, line 43 ¶
	"peak-g": "10"		"peak-g": "10"
	}		}
	]		]
	}		}
	]		]
	}		}
	]		]
	}		}
	}		}
	Figure 20: PUT to Convey the DOTS Traffic Baseline (2)		Figure 20: PUT to Convey the DOTS Traffic Baseline (2)
	The normal traffic baseline information should be updated to reflect		The normal traffic baseline information should be updated to reflect
	legitimate overloads (e.g., flash crowds) to prevent unnecessary		legitimate overloads (e.g., flash crowds) to prevent unnecessary
	mitigation.		mitigation.
	6.3.2. Retrieve Installed Normal Traffic Baseline		6.3.2. Retrieve Installed Normal Traffic Baseline
	A GET request with 'tsid' Uri-Path parameter is used to retrieve a		A GET request with 'tsid' Uri-Path parameter is used to retrieve a
	specific installed DOTS client domain baseline traffic information.		specific installed DOTS client domain baseline traffic information.
	The same procedure as defined in Section 6.1.3 is followed.		The same procedure as defined in Section 6.1.3 is followed.
	skipping to change at page 35, line 25 ¶		skipping to change at page 37, line 25 ¶
	A DELETE request is used to delete the installed DOTS client domain		A DELETE request is used to delete the installed DOTS client domain
	normal traffic baseline. The same procedure as defined in		normal traffic baseline. The same procedure as defined in
	Section 6.1.4 is followed.		Section 6.1.4 is followed.
	6.4. Reset Installed Telemetry Setup		6.4. Reset Installed Telemetry Setup
	Upon bootstrapping (or reboot or any other event that may alter the		Upon bootstrapping (or reboot or any other event that may alter the
	DOTS client setup), a DOTS client MAY send a DELETE request to set		DOTS client setup), a DOTS client MAY send a DELETE request to set
	the telemetry parameters to default values. Such a request does not		the telemetry parameters to default values. Such a request does not
	include any 'tsid'. An example of such request is depicted in		include any 'tsid'. An example of such a request is depicted in
	Figure 21.		Figure 21.
	Header: DELETE (Code=0.04)		Header: DELETE (Code=0.04)
	Uri-Path: ".well-known"		Uri-Path: ".well-known"
	Uri-Path: "dots"		Uri-Path: "dots"
	Uri-Path: "tm-setup"		Uri-Path: "tm-setup"
	Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"		Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
	Figure 21: Delete Telemetry Configuration		Figure 21: Delete Telemetry Configuration
	skipping to change at page 36, line 28 ¶		skipping to change at page 38, line 28 ¶
	The pre-or-ongoing-mitigation telemetry attributes are indicated by		The pre-or-ongoing-mitigation telemetry attributes are indicated by
	the path suffix '/tm'. The '/tm' is appended to the path prefix to		the path suffix '/tm'. The '/tm' is appended to the path prefix to
	form the URI used with a CoAP request to signal the DOTS telemetry.		form the URI used with a CoAP request to signal the DOTS telemetry.
	Pre-or-ongoing-mitigation telemetry attributes specified in		Pre-or-ongoing-mitigation telemetry attributes specified in
	Section 7.1 can be signaled between DOTS agents.		Section 7.1 can be signaled between DOTS agents.
	Pre-or-ongoing-mitigation telemetry attributes may be sent by a DOTS		Pre-or-ongoing-mitigation telemetry attributes may be sent by a DOTS
	client or a DOTS server.		client or a DOTS server.
	DOTS agents SHOULD bind pre-or-ongoing-mitigation telemetry data to		DOTS agents SHOULD bind pre-or-ongoing-mitigation telemetry data to
	mitigation requests relying upon the target attribute. In		mitigation requests associated with the resources under attack. In
	particular, a telemetry PUT request sent after a mitigation request		particular, a telemetry PUT request sent after a mitigation request
	may include a reference to that mitigation request ('mid-list') as		may include a reference to that mitigation request ('mid-list') as
	shown in Figure 22. An example illustrating request correlation by		shown in Figure 22. An example illustrating request correlation by
	means of 'target-prefix' is shown in Figure 23.		means of 'target-prefix' is shown in Figure 23.
	When generating telemetry data to send to a peer, the DOTS agent MUST		Many of the pre-or-ongoing-mitigation telemetry data use a unit that
	auto-scale so that appropriate unit(s) are used.		falls under the unit class that is configured following the procedure
			described in Section 6.1.2. When generating telemetry data to send
			to a peer, the DOTS agent MUST auto-scale so that appropriate unit(s)
			are used.
	+-----------+ +-----------+		+-----------+ +-----------+
	|DOTS client| |DOTS server|		|DOTS client| |DOTS server|
	+-----------+ +-----------+		+-----------+ +-----------+
	| |		| |
	|===============Mitigation Request (mid)===============>|		|===============Mitigation Request (mid)===============>|
	| |		| |
	|===============Telemetry (mid-list{mid})==============>|		|===============Telemetry (mid-list{mid})==============>|
	| |		| |
	Figure 22: Example of Request Correlation using 'mid'		Figure 22: Example of Request Correlation using 'mid'
	+-----------+ +-----------+		+-----------+ +-----------+
	|DOTS client| |DOTS server|		|DOTS client| |DOTS server|
	+-----------+ +-----------+		+-----------+ +-----------+
	| |		| |
	|<================Telemetry (target-prefix)=============|		|<================Telemetry (target-prefix)=============|
	| |		| |
	|=========Mitigation Request (target-prefix)===========>|		|=========Mitigation Request (target-prefix)===========>|
	| |		| |
	Figure 23: Example of Request Correlation using Target Prefix		Figure 23: Example of Request Correlation using Target Prefix
	DOTS agents MUST NOT send pre-or-ongoing-mitigation telemetry		DOTS agents MUST NOT send pre-or-ongoing-mitigation telemetry
	notifications to the same peer more frequently than once every		notifications to the same peer more frequently than once every
	'telemetry-notify-interval' (Section 6.1). If a telemetry		'telemetry-notify-interval' (Section 6.1). If a telemetry
	notification is sent using a block-like transfer mechanism (e.g.,		notification is sent using a block-like transfer mechanism (e.g.,
	[I-D.ietf-core-new-block]), this rate limit policy MUST NOT consider		[I-D.ietf-core-new-block]), this rate limit policy MUST NOT consider
	these individual blocks as separate notifications, but as a single		these individual blocks as separate notifications, but as a single
	notification.		notification.
	DOTS pre-or-ongoing-mitigation telemetry request and response		DOTS pre-or-ongoing-mitigation telemetry request and response
	skipping to change at page 38, line 39 ¶		skipping to change at page 40, line 39 ¶
	+-- total-traffic-protocol* [unit protocol]		+-- total-traffic-protocol* [unit protocol]
	| ...		| ...
	+-- total-traffic-port* [unit port]		+-- total-traffic-port* [unit port]
	| ...		| ...
	+-- total-attack-traffic* [unit]		+-- total-attack-traffic* [unit]
	| ...		| ...
	+-- total-attack-traffic-protocol* [unit protocol]		+-- total-attack-traffic-protocol* [unit protocol]
	| ...		| ...
	+-- total-attack-traffic-port* [unit port]		+-- total-attack-traffic-port* [unit port]
	| ...		| ...
	+-- total-attack-connection		+-- total-attack-connection-protocol* [protocol]
	| ...		| ...
	+-- total-attack-connection-port		+-- total-attack-connection-port* [protocol port]
	| ...		| ...
	+-- attack-detail* [vendor-id attack-id]		+-- attack-detail* [vendor-id attack-id]
	...		...
	Figure 24: Telemetry Message Type Tree Structure		Figure 24: Telemetry Message Type Tree Structure
	7.1. Pre-or-Ongoing-Mitigation DOTS Telemetry Attributes		7.1. Pre-or-Ongoing-Mitigation DOTS Telemetry Attributes
	The description and motivation behind each attribute are presented in		The description and motivation behind each attribute are presented in
	Section 3. DOTS telemetry attributes are optionally signaled and		Section 3. DOTS telemetry attributes are optionally signaled and
	therefore MUST NOT be treated as mandatory fields in the DOTS signal		therefore MUST NOT be treated as mandatory fields in the DOTS signal
	channel protocol.		channel protocol.
	7.1.1. Target		7.1.1. Target
	skipping to change at page 39, line 41 ¶		skipping to change at page 41, line 46 ¶
	+-- total-traffic-protocol* [unit protocol]		+-- total-traffic-protocol* [unit protocol]
	| ...		| ...
	+-- total-traffic-port* [unit port]		+-- total-traffic-port* [unit port]
	| ...		| ...
	+-- total-attack-traffic* [unit]		+-- total-attack-traffic* [unit]
	| ...		| ...
	+-- total-attack-traffic-protocol* [unit protocol]		+-- total-attack-traffic-protocol* [unit protocol]
	| ...		| ...
	+-- total-attack-traffic-port* [unit port]		+-- total-attack-traffic-port* [unit port]
	| ...		| ...
	+-- total-attack-connection		+-- total-attack-connection-protocol* [protocol]
	| ...		| ...
	+-- total-attack-connection-port		+-- total-attack-connection-port* [protocol port]
	| ...		| ...
	+-- attack-detail* [vendor-id attack-id]		+-- attack-detail* [vendor-id attack-id]
	...		...
	Figure 25: Target Tree Structure		Figure 25: Target Tree Structure
	At least one of the attributes 'target-prefix', 'target-fqdn',		At least one of the attributes 'target-prefix', 'target-fqdn',
	'target-uri', 'alias-name', or 'mid-list' MUST be present in the		'target-uri', 'alias-name', or 'mid-list' MUST be present in the
	target definition.		target definition.
	If the target is susceptible to bandwidth-consuming attacks, the		If the target is susceptible to bandwidth-consuming attacks, the
	attributes representing the percentile values of the 'attack-id'		attributes representing the percentile values of the 'attack-id'
	attack traffic are included.		attack traffic are included.
	If the target is susceptible to resource-consuming DDoS attacks, the		If the target is susceptible to resource-consuming DDoS attacks, the
	same attributes defined in Section 7.1.4 are applicable for		same attributes defined in Section 7.1.4 are applicable for
	representing the attack.		representing the attack.
	This is an optional attribute.		At least the 'target' attribute and one other pre-or-ongoing-
			mitigation attribute MUST be present in the DOTS telemetry message.
	7.1.2. Total Traffic		7.1.2. Total Traffic
	The 'total-traffic' attribute (Figure 26) conveys the percentile		The 'total-traffic' attribute (Figure 26) conveys the percentile
	values (including peak and current observed values) of total traffic		values (including peak and current observed values) of the total
	observed during a DDoS attack. More fine-grained information about		observed traffic. More fine-grained information about the total
	the total traffic can be conveyed in the 'total-traffic-protocol' and		traffic can be conveyed in the 'total-traffic-protocol' and 'total-
	'total-traffic-port' attributes.		traffic-port' attributes.
	The 'total-traffic-protocol' attribute represents the total traffic		The 'total-traffic-protocol' attribute represents the total traffic
	for a target and is transport-protocol specific.		for a target and is transport-protocol specific.
	The 'total-traffic-port' represents the total traffic for a target		The 'total-traffic-port' represents the total traffic for a target
	per port number.		per port number.
	+--:(telemetry)		+--:(telemetry)
	+-- pre-or-ongoing-mitigation* []		+-- pre-or-ongoing-mitigation* []
	+-- (direction)?		+-- (direction)?
	skipping to change at page 41, line 41 ¶		skipping to change at page 43, line 41 ¶
	| +-- mid-percentile-g? yang:gauge64		| +-- mid-percentile-g? yang:gauge64
	| +-- high-percentile-g? yang:gauge64		| +-- high-percentile-g? yang:gauge64
	| +-- peak-g? yang:gauge64		| +-- peak-g? yang:gauge64
	| +-- current-g? yang:gauge64		| +-- current-g? yang:gauge64
	+-- total-attack-traffic* [unit]		+-- total-attack-traffic* [unit]
	| ...		| ...
	+-- total-attack-traffic-protocol* [unit protocol]		+-- total-attack-traffic-protocol* [unit protocol]
	| ...		| ...
	+-- total-attack-traffic-port* [unit port]		+-- total-attack-traffic-port* [unit port]
	| ...		| ...
	+-- total-attack-connection		+-- total-attack-connection-protocol* [protocol]
	| ...		| ...
	+-- total-attack-connection-port		+-- total-attack-connection-port* [protocol port]
	| ...		| ...
	+-- attack-detail* [vendor-id attack-id]		+-- attack-detail* [vendor-id attack-id]
	...		...
	Figure 26: Total Traffic Tree Structure		Figure 26: Total Traffic Tree Structure
	7.1.3. Total Attack Traffic		7.1.3. Total Attack Traffic
	The 'total-attack-traffic' attribute (Figure 27) conveys the total		The 'total-attack-traffic' attribute (Figure 27) conveys the total
	attack traffic identified by the DOTS client domain's DDoS Mitigation		observed attack traffic. More fine-grained information about the
	System (or DDoS Detector). More fine-grained information about the
	total attack traffic can be conveyed in the 'total-attack-traffic-		total attack traffic can be conveyed in the 'total-attack-traffic-
	protocol' and 'total-attack-traffic-port' attributes.		protocol' and 'total-attack-traffic-port' attributes.
	The 'total-attack-traffic-protocol' attribute represents the total		The 'total-attack-traffic-protocol' attribute represents the total
	attack traffic for a target and is transport-protocol specific.		attack traffic for a target and is transport-protocol specific.
	The 'total-attack-traffic-port' attribute represents the total attack		The 'total-attack-traffic-port' attribute represents the total attack
	traffic for a target per port number.		traffic for a target per port number.
	+--:(telemetry)		+--:(telemetry)
	skipping to change at page 43, line 41 ¶		skipping to change at page 45, line 41 ¶
	| +-- peak-g? yang:gauge64		| +-- peak-g? yang:gauge64
	| +-- current-g? yang:gauge64		| +-- current-g? yang:gauge64
	+-- total-attack-traffic-port* [unit port]		+-- total-attack-traffic-port* [unit port]
	| +-- port inet:port-number		| +-- port inet:port-number
	| +-- unit unit		| +-- unit unit
	| +-- low-percentile-g? yang:gauge64		| +-- low-percentile-g? yang:gauge64
	| +-- mid-percentile-g? yang:gauge64		| +-- mid-percentile-g? yang:gauge64
	| +-- high-percentile-g? yang:gauge64		| +-- high-percentile-g? yang:gauge64
	| +-- peak-g? yang:gauge64		| +-- peak-g? yang:gauge64
	| +-- current-g? yang:gauge64		| +-- current-g? yang:gauge64
	+-- total-attack-connection		+-- total-attack-connection-protocol* [protocol]
	| ...		| ...
	+-- total-attack-connection-port		+-- total-attack-connection-port* [protocol port]
	| ...		| ...
	+-- attack-detail* [vendor-id attack-id]		+-- attack-detail* [vendor-id attack-id]
	...		...
	Figure 27: Total Attack Traffic Tree Structure		Figure 27: Total Attack Traffic Tree Structure
	7.1.4. Total Attack Connections		7.1.4. Total Attack Connections
	If the target is susceptible to resource-consuming DDoS attacks, the		If the target is susceptible to resource-consuming DDoS attacks, the
	'total-attack-connection' attribute is used to convey the percentile		'total-attack-connection-protocol' attribute is used to convey the
	values (including peak and current observed values) of total attack		percentile values (including peak and current observed values) of
	connections. The following optional subattributes for the target per		various attributes related to the total attack connections. The
	transport protocol are included to represent the attack		following optional subattributes for the target per transport
	characteristics:		protocol are included to represent the attack characteristics:
	o The number of simultaneous attack connections to the target.		* The number of simultaneous attack connections to the target.
	o The number of simultaneous embryonic connections to the target.		* The number of simultaneous embryonic connections to the target.
	o The number of attack connections per second to the target.		* The number of attack connections per second to the target.
	o The number of attack requests to the target.		* The number of attack requests per second to the target.
			* The number of attack partial requests to the target.
	The total attack connections per port number is represented using the		The total attack connections per port number is represented using the
	'total-attack-connection-port' attribute.		'total-attack-connection-port' attribute.
	+--:(telemetry)		+--:(telemetry)
	+-- pre-or-ongoing-mitigation* []		+-- pre-or-ongoing-mitigation* []
	+-- (direction)?		+-- (direction)?
	| +--:(server-to-client-only)		| +--:(server-to-client-only)
	| +-- tmid? uint32		| +-- tmid? uint32
	+-- target		+-- target
	skipping to change at page 44, line 41 ¶		skipping to change at page 46, line 42 ¶
	+-- total-traffic-protocol* [unit protocol]		+-- total-traffic-protocol* [unit protocol]
	| ...		| ...
	+-- total-traffic-port* [unit port]		+-- total-traffic-port* [unit port]
	| ...		| ...
	+-- total-attack-traffic* [unit]		+-- total-attack-traffic* [unit]
	| ...		| ...
	+-- total-attack-traffic-protocol* [unit protocol]		+-- total-attack-traffic-protocol* [unit protocol]
	| ...		| ...
	+-- total-attack-traffic-port* [unit port]		+-- total-attack-traffic-port* [unit port]
	| ...		| ...
	+-- total-attack-connection		+-- total-attack-connection-protocol* [protocol]
	| +-- low-percentile-l* [protocol]		| +-- protocol uint8
	| | +-- protocol uint8		| +-- connection-c
	| | +-- connection? yang:gauge64		| | +-- low-percentile-g? yang:gauge64
	| | +-- embryonic? yang:gauge64		| | +-- mid-percentile-g? yang:gauge64
	| | +-- connection-ps? yang:gauge64		| | +-- high-percentile-g? yang:gauge64
	| | +-- request-ps? yang:gauge64		| | +-- peak-g? yang:gauge64
	| | +-- partial-request-ps? yang:gauge64		| | +-- current-g? yang:gauge64
	| +-- mid-percentile-l* [protocol]		| +-- embryonic-c
	| | +-- protocol uint8		| | +-- low-percentile-g? yang:gauge64
	| | +-- connection? yang:gauge64		| | +-- mid-percentile-g? yang:gauge64
	| | +-- embryonic? yang:gauge64		| | +-- high-percentile-g? yang:gauge64
	| | +-- connection-ps? yang:gauge64		| | +-- peak-g? yang:gauge64
	| | +-- request-ps? yang:gauge64		| | +-- current-g? yang:gauge64
	| | +-- partial-request-ps? yang:gauge64		| +-- connection-ps-c
	| +-- high-percentile-l* [protocol]		| | +-- low-percentile-g? yang:gauge64
	| | +-- protocol uint8		| | +-- mid-percentile-g? yang:gauge64
	| | +-- connection? yang:gauge64		| | +-- high-percentile-g? yang:gauge64
	| | +-- embryonic? yang:gauge64		| | +-- peak-g? yang:gauge64
	| | +-- connection-ps? yang:gauge64		| | +-- current-g? yang:gauge64
	| | +-- request-ps? yang:gauge64		| +-- request-ps-c
	| | +-- partial-request-ps? yang:gauge64		| | +-- low-percentile-g? yang:gauge64
	| +-- peak-l* [protocol]		| | +-- mid-percentile-g? yang:gauge64
	| | +-- protocol uint8		| | +-- high-percentile-g? yang:gauge64
	| | +-- connection? yang:gauge64		| | +-- peak-g? yang:gauge64
	| | +-- embryonic? yang:gauge64		| | +-- current-g? yang:gauge64
	| | +-- connection-ps? yang:gauge64		| +-- partial-request-c
	| | +-- request-ps? yang:gauge64		| +-- low-percentile-g? yang:gauge64
	| | +-- partial-request-ps? yang:gauge64		| +-- mid-percentile-g? yang:gauge64
	| +-- current-l* [protocol]		| +-- high-percentile-g? yang:gauge64
	| +-- protocol uint8		| +-- peak-g? yang:gauge64
	| +-- connection? yang:gauge64		| +-- current-g? yang:gauge64
	| +-- embryonic? yang:gauge64		+-- total-attack-connection-port* [protocol port]
	| +-- connection-ps? yang:gauge64		| +-- protocol uint8
	| +-- request-ps? yang:gauge64		| +-- port inet:port-number
	| +-- partial-request-ps? yang:gauge64		| +-- connection-c
	+-- total-attack-connection-port		| | +-- low-percentile-g? yang:gauge64
	| +-- low-percentile-l* [protocol port]		| | +-- mid-percentile-g? yang:gauge64
	| | +-- port inet:port-number		| | +-- high-percentile-g? yang:gauge64
	| | +-- protocol uint8		| | +-- peak-g? yang:gauge64
	| | +-- connection? yang:gauge64		| | +-- current-g? yang:gauge64
	| | +-- embryonic? yang:gauge64		| +-- embryonic-c
	| | +-- connection-ps? yang:gauge64		| | +-- low-percentile-g? yang:gauge64
	| | +-- request-ps? yang:gauge64		| | +-- mid-percentile-g? yang:gauge64
	| | +-- partial-request-ps? yang:gauge64		| | +-- high-percentile-g? yang:gauge64
	| +-- mid-percentile-l* [protocol port]		| | +-- peak-g? yang:gauge64
	| | +-- port inet:port-number		| | +-- current-g? yang:gauge64
	| | +-- protocol uint8		| +-- connection-ps-c
	| | +-- connection? yang:gauge64		| | +-- low-percentile-g? yang:gauge64
	| | +-- embryonic? yang:gauge64		| | +-- mid-percentile-g? yang:gauge64
	| | +-- connection-ps? yang:gauge64		| | +-- high-percentile-g? yang:gauge64
	| | +-- request-ps? yang:gauge64		| | +-- peak-g? yang:gauge64
	| | +-- partial-request-ps? yang:gauge64		| | +-- current-g? yang:gauge64
	| +-- high-percentile-l* [protocol port]		| +-- request-ps-c
	| | +-- port inet:port-number		| | +-- low-percentile-g? yang:gauge64
	| | +-- protocol uint8		| | +-- mid-percentile-g? yang:gauge64
	| | +-- connection? yang:gauge64		| | +-- high-percentile-g? yang:gauge64
	| | +-- embryonic? yang:gauge64		| | +-- peak-g? yang:gauge64
	| | +-- connection-ps? yang:gauge64		| | +-- current-g? yang:gauge64
	| | +-- request-ps? yang:gauge64		| +-- partial-request-c
	| | +-- partial-request-ps? yang:gauge64		| +-- low-percentile-g? yang:gauge64
	| +-- peak-l* [protocol port]		| +-- mid-percentile-g? yang:gauge64
	| | +-- port inet:port-number		| +-- high-percentile-g? yang:gauge64
	| | +-- protocol uint8		| +-- peak-g? yang:gauge64
	| | +-- connection? yang:gauge64		| +-- current-g? yang:gauge64
	| | +-- embryonic? yang:gauge64
	| | +-- connection-ps? yang:gauge64
	| | +-- request-ps? yang:gauge64
	| | +-- partial-request-ps? yang:gauge64
	| +-- current-l* [protocol port]
	| +-- port inet:port-number
	| +-- protocol uint8
	| +-- connection? yang:gauge64
	| +-- embryonic? yang:gauge64
	| +-- connection-ps? yang:gauge64
	| +-- request-ps? yang:gauge64
	| +-- partial-request-ps? yang:gauge64
	+-- attack-detail* [vendor-id attack-id]		+-- attack-detail* [vendor-id attack-id]
	...		...
	Figure 28: Total Attack Connections Tree Structure		Figure 28: Total Attack Connections Tree Structure
	7.1.5. Attack Details		7.1.5. Attack Details
	This attribute (depicted in Figure 29) is used to signal a set of		This attribute (depicted in Figure 29) is used to signal a set of
	details characterizing an attack. The following subattributes		details characterizing an attack. The following subattributes
	describing the ongoing attack can be signalled as attack details.		describing the ongoing attack can be signalled as attack details:
	vendor-id: Vendor ID is a security vendor's Enterprise Number as		vendor-id: Vendor ID is a security vendor's Enterprise Number as
	registered with IANA [Enterprise-Numbers]. It is a four-byte		registered with IANA [Enterprise-Numbers]. It is a four-byte
	integer value.		integer value.
	attack-id: Unique identifier assigned for the attack.		attack-id: Unique identifier assigned for the attack by a vendor.
	attack-description: Textual representation of the attack		attack-description: Textual representation of the attack
	description. Natural Language Processing techniques (e.g., word		description. Natural Language Processing techniques (e.g., word
	embedding) might provide some utility in mapping the attack		embedding) might provide some utility in mapping the attack
	description to an attack type. Textual representation of attack		description to an attack type. Textual representation of attack
	solves two problems: (a) avoids the need to create mapping tables		solves two problems: (a) avoids the need to create mapping tables
	manually between vendors and (b) avoids the need to standardize		manually between vendors and (b) avoids the need to standardize
	attack types which keep evolving.		attack types which keep evolving.
	attack-severity: Attack severity level. This attribute takes one of		attack-severity: Attack severity level. This attribute takes one of
	the values defined in Section 3.12.2 of [RFC7970].		the values defined in Section 3.12.2 of [RFC7970].
	start-time: The time the attack started. The attack's start time is		start-time: The time the attack started. The attack's start time is
	expressed in seconds relative to 1970-01-01T00:00Z in UTC time		expressed in seconds relative to 1970-01-01T00:00Z (Section 3.4.2
	(Section 3.4.2 of [RFC8949]). The CBOR encoding is modified so		of [RFC8949]). The CBOR encoding is modified so that the leading
	that the leading tag 1 (epoch-based date/time) MUST be omitted.		tag 1 (epoch-based date/time) MUST be omitted.
	end-time: The time the attack ended. The attack end time is		end-time: The time the attack ended. The attack end time is
	expressed in seconds relative to 1970-01-01T00:00Z in UTC time		expressed in seconds relative to 1970-01-01T00:00Z (Section 3.4.2
	(Section 3.4.2 of [RFC8949]). The CBOR encoding is modified so		of [RFC8949]). The CBOR encoding is modified so that the leading
	that the leading tag 1 (epoch-based date/time) MUST be omitted.		tag 1 (epoch-based date/time) MUST be omitted.
	source-count: A count of sources involved in the attack targeting		source-count: A count of sources involved in the attack targeting
	the victim.		the victim.
	top-talker: A list of top talkers among attack sources. The top		top-talker: A list of attack sources that are involved in an attack
	talkers are represented using the 'source-prefix'.		and which are generating an important part of the attack traffic.
			The top talkers are represented using the 'source-prefix'.
	'spoofed-status' indicates whether a top talker is a spoofed IP		'spoofed-status' indicates whether a top talker is a spoofed IP
	address (e.g., reflection attacks) or not.		address (e.g., reflection attacks) or not. If no 'spoofed-status'
			data node is included, this means that the spoofing status is
			unknown.
	If the target is being subjected to a bandwidth-consuming attack,		If the target is being subjected to a bandwidth-consuming attack,
	a statistical profile of the attack traffic from each of the top		a statistical profile of the attack traffic from each of the top
	talkers is included ('total-attack-traffic', Section 7.1.3).		talkers is included ('total-attack-traffic', Section 7.1.3).
	If the target is being subjected to a resource-consuming DDoS		If the target is being subjected to a resource-consuming DDoS
	attack, the same attributes defined in Section 7.1.4 are		attack, the same attributes defined in Section 7.1.4 are
	applicable for characterizing the attack on a per-talker basis.		applicable for characterizing the attack on a per-talker basis.
	+--:(telemetry)		+--:(telemetry)
	skipping to change at page 47, line 48 ¶		skipping to change at page 49, line 39 ¶
	+-- total-traffic-protocol* [unit protocol]		+-- total-traffic-protocol* [unit protocol]
	| ...		| ...
	+-- total-traffic-port* [unit port]		+-- total-traffic-port* [unit port]
	| ...		| ...
	+-- total-attack-traffic* [unit]		+-- total-attack-traffic* [unit]
	| ...		| ...
	+-- total-attack-traffic-protocol* [unit protocol]		+-- total-attack-traffic-protocol* [unit protocol]
	| ...		| ...
	+-- total-attack-traffic-port* [unit port]		+-- total-attack-traffic-port* [unit port]
	| ...		| ...
	+-- total-attack-connection		+-- total-attack-connection-protocol* [protocol]
	| ...		| ...
	+-- total-attack-connection-port		+-- total-attack-connection-port* [protocol port]
	| ...		| ...
	+-- attack-detail* [vendor-id attack-id]		+-- attack-detail* [vendor-id attack-id]
	+-- vendor-id uint32		+-- vendor-id uint32
	+-- attack-id uint32		+-- attack-id uint32
	+-- attack-description? string		+-- attack-description? string
	+-- attack-severity? attack-severity		+-- attack-severity? attack-severity
	+-- start-time? uint64		+-- start-time? uint64
	+-- end-time? uint64		+-- end-time? uint64
	+-- source-count		+-- source-count
	| +-- low-percentile-g? yang:gauge64		| +-- low-percentile-g? yang:gauge64
	| +-- mid-percentile-g? yang:gauge64		| +-- mid-percentile-g? yang:gauge64
	skipping to change at page 48, line 35 ¶		skipping to change at page 50, line 25 ¶
	+-- source-icmp-type-range* [lower-type]		+-- source-icmp-type-range* [lower-type]
	| +-- lower-type uint8		| +-- lower-type uint8
	| +-- upper-type? uint8		| +-- upper-type? uint8
	+-- total-attack-traffic* [unit]		+-- total-attack-traffic* [unit]
	| +-- unit unit		| +-- unit unit
	| +-- low-percentile-g? yang:gauge64		| +-- low-percentile-g? yang:gauge64
	| +-- mid-percentile-g? yang:gauge64		| +-- mid-percentile-g? yang:gauge64
	| +-- high-percentile-g? yang:gauge64		| +-- high-percentile-g? yang:gauge64
	| +-- peak-g? yang:gauge64		| +-- peak-g? yang:gauge64
	| +-- current-g? yang:gauge64		| +-- current-g? yang:gauge64
	+-- total-attack-connection		+-- total-attack-connection-protocol*
	+-- low-percentile-l* [protocol]		[protocol]
	| +-- protocol uint8		+-- protocol uint8
	| +-- connection? yang:gauge64		+-- connection-c
	| +-- embryonic? yang:gauge64		| +-- low-percentile-g? yang:gauge64
	| +-- connection-ps? yang:gauge64		| +-- mid-percentile-g? yang:gauge64
	| +-- request-ps? yang:gauge64		| +-- high-percentile-g? yang:gauge64
	| +-- partial-request-ps? yang:gauge64		| +-- peak-g? yang:gauge64
	+-- mid-percentile-l* [protocol]		| +-- current-g? yang:gauge64
	| +-- protocol uint8		+-- embryonic-c
	| +-- connection? yang:gauge64		| +-- low-percentile-g? yang:gauge64
	| +-- embryonic? yang:gauge64		| +-- mid-percentile-g? yang:gauge64
	| +-- connection-ps? yang:gauge64		| +-- high-percentile-g? yang:gauge64
	| +-- request-ps? yang:gauge64		| +-- peak-g? yang:gauge64
	| +-- partial-request-ps? yang:gauge64		| +-- current-g? yang:gauge64
	+-- high-percentile-l* [protocol]		+-- connection-ps-c
	| +-- protocol uint8		| +-- low-percentile-g? yang:gauge64
	| +-- connection? yang:gauge64		| +-- mid-percentile-g? yang:gauge64
	| +-- embryonic? yang:gauge64		| +-- high-percentile-g? yang:gauge64
	| +-- connection-ps? yang:gauge64		| +-- peak-g? yang:gauge64
	| +-- request-ps? yang:gauge64		| +-- current-g? yang:gauge64
	| +-- partial-request-ps? yang:gauge64		+-- request-ps-c
	+-- peak-l* [protocol]		| +-- low-percentile-g? yang:gauge64
	| +-- protocol uint8		| +-- mid-percentile-g? yang:gauge64
	| +-- connection? yang:gauge64		| +-- high-percentile-g? yang:gauge64
	| +-- embryonic? yang:gauge64		| +-- peak-g? yang:gauge64
	| +-- connection-ps? yang:gauge64		| +-- current-g? yang:gauge64
	| +-- request-ps? yang:gauge64		+-- partial-request-c
	| +-- partial-request-ps? yang:gauge64		+-- low-percentile-g? yang:gauge64
	+-- current-l* [protocol]		+-- mid-percentile-g? yang:gauge64
	+-- protocol uint8		+-- high-percentile-g? yang:gauge64
	+-- connection? yang:gauge64		+-- peak-g? yang:gauge64
	+-- embryonic? yang:gauge64		+-- current-g? yang:gauge64
	+-- connection-ps? yang:gauge64
	+-- request-ps? yang:gauge64
	+-- partial-request-ps? yang:gauge64
	Figure 29: Attack Detail Tree Structure		Figure 29: Attack Detail Tree Structure
	In order to optimize the size of telemetry data conveyed over the		In order to optimize the size of telemetry data conveyed over the
	DOTS signal channel, DOTS agents MAY use the DOTS data channel		DOTS signal channel, DOTS agents MAY use the DOTS data channel
	[RFC8783] to exchange vendor specific attack mapping details (that		[RFC8783] to exchange vendor specific attack mapping details (that
	is, {vendor identifier, attack identifier} ==> attack description).		is, {vendor identifier, attack identifier} ==> textual representation
	As such, DOTS agents do not have to convey systematically an attack		of the attack description). As such, DOTS agents do not have to
	description in their telemetry messages over the DOTS signal channel.		convey systematically an attack description in their telemetry
			messages over the DOTS signal channel. Refer to Section 7.1.6.
			7.1.6. Vendor Attack Mapping
	Multiple mappings for different vendor identifiers may be used; the		Multiple mappings for different vendor identifiers may be used; the
	DOTS agent transmitting telemetry information can elect to use one or		DOTS agent transmitting telemetry information can elect to use one or
	more vendor mappings even in the same telemetry message.		more vendor mappings even in the same telemetry message.
	Note: It is possible that a DOTS server is making use of multiple		Note: It is possible that a DOTS server is making use of multiple
	DOTS mitigators; each from a different vendor. How telemetry		DOTS mitigators; each from a different vendor. How telemetry
	information and vendor mappings are exchanged between DOTS servers		information and vendor mappings are exchanged between DOTS servers
	and DOTS mitigators is outside the scope of this document.		and DOTS mitigators is outside the scope of this document.
	DOTS clients and servers may be provided with mappings from different		DOTS clients and servers may be provided with mappings from different
	vendors and so have their own different sets of vendor attack		vendors and so have their own different sets of vendor attack
	mappings. A DOTS agent MUST accept receipt of telemetry data with a		mappings. A DOTS agent MUST accept receipt of telemetry data with a
	vendor identifier that is different to the one it uses to transmit		vendor identifier that is different to the one it uses to transmit
	telemetry data. Furthermore, it is possible that the DOTS client and		telemetry data. Furthermore, it is possible that the DOTS client and
	DOTS server are provided by the same vendor, but the vendor mapping		DOTS server are provided by the same vendor, but the vendor mapping
	tables are at different revisions. The DOTS client SHOULD transmit		tables are at different revisions. The DOTS client SHOULD transmit
	telemetry information using the vendor mapping(s) that it provided to		telemetry information using any vendor mapping(s) that it provided to
	the DOTS server and the DOTS server SHOULD use the vendor mappings(s)		the DOTS server (e.g., using a POST as depicted in Figure 34) and the
	provided to the DOTS client when transmitting telemetry data to the		DOTS server SHOULD use any vendor mappings(s) provided to the DOTS
	peer DOTS agent.		client when transmitting telemetry data to the peer DOTS agent.
	The "ietf-dots-mapping" YANG module defined in Section 10.2 augments		The "ietf-dots-mapping" YANG module defined in Section 10.2 augments
	the "ietf-dots-data-channel" [RFC8783] module. The tree structure of		the "ietf-dots-data-channel" [RFC8783] module. The tree structure of
	the "ietf-dots-mapping" module is shown in Figure 30.		the "ietf-dots-mapping" module is shown in Figure 30.
	module: ietf-dots-mapping		module: ietf-dots-mapping
	augment /data-channel:dots-data/data-channel:dots-client:		augment /data-channel:dots-data/data-channel:dots-client:
	+--rw vendor-mapping {dots-telemetry}?		+--rw vendor-mapping {dots-telemetry}?
	+--rw vendor* [vendor-id]		+--rw vendor* [vendor-id]
	+--rw vendor-id uint32		+--rw vendor-id uint32
	skipping to change at page 50, line 41 ¶		skipping to change at page 52, line 37 ¶
	Figure 30: Vendor Attack Mapping Tree Structure		Figure 30: Vendor Attack Mapping Tree Structure
	A DOTS client sends a GET request to retrieve the capabilities		A DOTS client sends a GET request to retrieve the capabilities
	supported by a DOTS server as per Section 7.1 of [RFC8783]. This		supported by a DOTS server as per Section 7.1 of [RFC8783]. This
	request is meant to assess whether the capability of sharing vendor		request is meant to assess whether the capability of sharing vendor
	attack mapping details is supported by the server (i.e., check the		attack mapping details is supported by the server (i.e., check the
	value of 'vendor-mapping-enabled').		value of 'vendor-mapping-enabled').
	If 'vendor-mapping-enabled' is set to 'true', A DOTS client MAY send		If 'vendor-mapping-enabled' is set to 'true', A DOTS client MAY send
	a GET request to retrieve the DOTS server's vendor attack mapping		a GET request to retrieve the DOTS server's vendor attack mapping
	details. An example of such GET request is shown in Figure 31.		details. An example of such a GET request is shown in Figure 31.
	GET /restconf/data/ietf-dots-data-channel:dots-data\		GET /restconf/data/ietf-dots-data-channel:dots-data\
	/ietf-dots-mapping:vendor-mapping HTTP/1.1		/ietf-dots-mapping:vendor-mapping HTTP/1.1
	Host: example.com		Host: example.com
	Accept: application/yang-data+json		Accept: application/yang-data+json
	Figure 31: GET to Retrieve the Vendor Attack Mappings of a DOTS		Figure 31: GET to Retrieve the Vendor Attack Mappings of a DOTS
	Server		Server
	A DOTS client can retrieve only the list of vendors supported by the		A DOTS client can retrieve only the list of vendors supported by the
	DOTS server. It does so by setting the "depth" parameter		DOTS server. It does so by setting the "depth" parameter
	(Section 4.8.2 of [RFC8040]) to "3" in the GET request as shown in		(Section 4.8.2 of [RFC8040]) to "3" in the GET request as shown in
	Figure 32. An example of a response body received from the DOTS		Figure 32. An example of a response body received from the DOTS
	server as a response to such request is illustrated in Figure 33.		server as a response to such a request is illustrated in Figure 33.
	GET /restconf/data/ietf-dots-data-channel:dots-data\		GET /restconf/data/ietf-dots-data-channel:dots-data\
	/ietf-dots-mapping:vendor-mapping?depth=3 HTTP/1.1		/ietf-dots-mapping:vendor-mapping?depth=3 HTTP/1.1
	Host: example.com		Host: example.com
	Accept: application/yang-data+json		Accept: application/yang-data+json
	Figure 32: GET to Retrieve the Vendors List used by a DOTS Server		Figure 32: GET to Retrieve the Vendors List used by a DOTS Server
	{		{
	"ietf-dots-mapping:vendor-mapping": {		"ietf-dots-mapping:vendor-mapping": {
	"vendor": [		"vendor": [
	{		{
	"vendor-id": 1234,		"vendor-id": 32473,
	"vendor-name": "mitigator-s",		"vendor-name": "mitigator-s",
	"last-updated": "1576856561",		"last-updated": "1629898758",
	"attack-mapping": []		"attack-mapping": []
	}		}
	]		]
	}		}
	}		}
	Figure 33: Response to a GET to Retrieve the Vendors List used by a		Figure 33: Response to a GET to Retrieve the Vendors List used by
	DOTS Server		a DOTS Server
	The DOTS client reiterates the above procedure regularly (e.g., once		The DOTS client reiterates the above procedure regularly (e.g., once
	a week) to update the DOTS server's vendor attack mapping details.		a week) to update the DOTS server's vendor attack mapping details.
	If the DOTS client concludes that the DOTS server does not have any		If the DOTS client concludes that the DOTS server does not have any
	reference to the specific vendor attack mapping details, the DOTS		reference to the specific vendor attack mapping details, the DOTS
	client uses a POST request to install its vendor attack mapping		client uses a POST request to install its vendor attack mapping
	details. An example of such POST request is depicted in Figure 34.		details. An example of such a POST request is depicted in Figure 34.
	POST /restconf/data/ietf-dots-data-channel:dots-data\		POST /restconf/data/ietf-dots-data-channel:dots-data\
	/dots-client=dz6pHjaADkaFTbjr0JGBpw HTTP/1.1		/dots-client=dz6pHjaADkaFTbjr0JGBpw HTTP/1.1
	Host: example.com		Host: example.com
	Content-Type: application/yang-data+json		Content-Type: application/yang-data+json
	{		{
	"ietf-dots-mapping:vendor-mapping": {		"ietf-dots-mapping:vendor-mapping": {
	"vendor": [		"vendor": [
	{		{
	"vendor-id": 345,		"vendor-id": 345,
	"vendor-name": "mitigator-c",		"vendor-name": "mitigator-c",
	"last-updated": "1576812345",		"last-updated": "1629898958",
	"attack-mapping": [		"attack-mapping": [
	{		{
	"attack-id": 1,		"attack-id": 1,
	"attack-description":		"attack-description":
	"Include a description of this attack"		"Include a description of this attack"
	},		},
	{		{
	"attack-id": 2,		"attack-id": 2,
	"attack-description":		"attack-description":
	"Again, include a description of the attack"		"Again, include a description of the attack"
	}		}
	]		]
	}		}
	]		]
	}		}
	}		}
	Figure 34: POST to Install Vendor Attack Mapping Details		Figure 34: POST to Install Vendor Attack Mapping Details
	The DOTS server indicates the result of processing the POST request		The DOTS server indicates the result of processing the POST request
	using the status-line. Concretely, "201 Created" status-line MUST be		using the status-line. Concretely, "201 Created" status-line MUST be
	returned in the response if the DOTS server has accepted the vendor		returned in the response if the DOTS server has accepted the vendor
	attack mapping details. If the request is missing a mandatory		attack mapping details. If the request is missing a mandatory
	attribute or contains an invalid or unknown parameter, "400 Bad		attribute or contains an invalid or unknown parameter, "400 Bad
	Request" status-line MUST be returned by the DOTS server in the		Request" status-line MUST be returned by the DOTS server in the
	response. The error-tag is set to "missing-attribute", "invalid-		response. The error-tag is set to "missing-attribute", "invalid-
	value", or "unknown-element" as a function of the encountered error.		value", or "unknown-element" as a function of the encountered error.
	skipping to change at page 53, line 19 ¶		skipping to change at page 55, line 19 ¶
	A DOTS client uses a GET request to retrieve its vendor attack		A DOTS client uses a GET request to retrieve its vendor attack
	mapping details as maintained by the DOTS server (Figure 35).		mapping details as maintained by the DOTS server (Figure 35).
	GET /restconf/data/ietf-dots-data-channel:dots-data\		GET /restconf/data/ietf-dots-data-channel:dots-data\
	/dots-client=dz6pHjaADkaFTbjr0JGBpw\		/dots-client=dz6pHjaADkaFTbjr0JGBpw\
	/ietf-dots-mapping:vendor-mapping?\		/ietf-dots-mapping:vendor-mapping?\
	content=all HTTP/1.1		content=all HTTP/1.1
	Host: example.com		Host: example.com
	Accept: application/yang-data+json		Accept: application/yang-data+json
	Figure 35: GET to Retrieve Installed Vendor Attack Mapping Details		Figure 35: GET to Retrieve Installed Vendor Attack Mapping Details
	When conveying attack details in DOTS telemetry messages (Sections		When conveying attack details in DOTS telemetry messages (Sections
	7.2, 7.3, and 8), DOTS agents MUST NOT include the 'attack-		7.2, 7.3, and 8), DOTS agents MUST NOT include the 'attack-
	description' attribute unless the corresponding attack mapping		description' attribute unless the corresponding attack mapping
	details were not previously shared with the peer DOTS agent.		details were not previously shared with the peer DOTS agent.
	7.2. From DOTS Clients to DOTS Servers		7.2. From DOTS Clients to DOTS Servers
	DOTS clients use PUT requests to signal pre-or-ongoing-mitigation		DOTS clients use PUT requests to signal pre-or-ongoing-mitigation
	telemetry to DOTS servers. An example of such a request is shown in		telemetry to DOTS servers. An example of such a request is shown in
	skipping to change at page 54, line 31 ¶		skipping to change at page 56, line 31 ¶
	},		},
	"total-attack-traffic-protocol": [		"total-attack-traffic-protocol": [
	{		{
	"protocol": 17,		"protocol": 17,
	"unit": "megabit-ps",		"unit": "megabit-ps",
	"mid-percentile-g": "900"		"mid-percentile-g": "900"
	}		}
	],		],
	"attack-detail": [		"attack-detail": [
	{		{
	"vendor-id": 1234,		"vendor-id": 32473,
	"attack-id": 77,		"attack-id": 77,
	"start-time": "1957811234",		"start-time": "1608336568",
	"attack-severity": "high"		"attack-severity": "high"
	}		}
	]		]
	}		}
	]		]
	}		}
	}		}
	Figure 36: PUT to Send Pre-or-Ongoing-Mitigation Telemetry		Figure 36: PUT to Send Pre-or-Ongoing-Mitigation Telemetry
	'cuid' is a mandatory Uri-Path parameter for DOTS PUT requests.		'cuid' is a mandatory Uri-Path parameter for DOTS PUT requests.
	The following additional Uri-Path parameter is defined:		The following additional Uri-Path parameter is defined:
	tmid: Telemetry Identifier is an identifier for the DOTS pre-or-		tmid: Telemetry Identifier is an identifier for the DOTS pre-or-
	ongoing-mitigation telemetry data represented as an integer.		ongoing-mitigation telemetry data represented as an integer.
	This identifier MUST be generated by DOTS clients. 'tmid' values		This identifier MUST be generated by DOTS clients. 'tmid' values
	MUST increase monotonically (when a new PUT is generated by a		MUST increase monotonically (when a new PUT is generated by a
	DOTS client to convey pre-or-ongoing-mitigation telemetry).		DOTS client to convey pre-or-ongoing-mitigation telemetry).
	skipping to change at page 56, line 42 ¶		skipping to change at page 58, line 34 ¶
	trigger a DOTS mitigation request or not. Furthermore, the security		trigger a DOTS mitigation request or not. Furthermore, the security
	operations personnel at the DOTS client domain can use the attack		operations personnel at the DOTS client domain can use the attack
	details to determine the protection strategy and select the		details to determine the protection strategy and select the
	appropriate DOTS server for mitigating the attack.		appropriate DOTS server for mitigating the attack.
	In order to receive pre-or-ongoing-mitigation telemetry notifications		In order to receive pre-or-ongoing-mitigation telemetry notifications
	from a DOTS server, a DOTS client MUST send a PUT (followed by a GET)		from a DOTS server, a DOTS client MUST send a PUT (followed by a GET)
	with the target filter. An example of such a PUT request is shown in		with the target filter. An example of such a PUT request is shown in
	Figure 39. In order to avoid maintaining a long list of such		Figure 39. In order to avoid maintaining a long list of such
	requests, it is RECOMMENDED that DOTS clients include all targets in		requests, it is RECOMMENDED that DOTS clients include all targets in
	the same request. DOTS servers may be instructed to restrict the		the same request (assuming this fits within one single datagram).
	number of pre-or-ongoing-mitigation requests per DOTS client domain.		DOTS servers may be instructed to restrict the number of pre-or-
	This request MUST be maintained in an active state by the DOTS server		ongoing-mitigation requests per DOTS client domain. The PUT request
	until a delete request is received from the same DOTS client to clear		MUST be maintained in an active state by the DOTS server until a
	this pre-or-ongoing-mitigation telemetry.		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., Section 3.5 of [RFC8783]).
	The relative order of two PUT requests carrying DOTS pre-or-ongoing-		The relative order of two PUT requests carrying DOTS pre-or-ongoing-
	mitigation telemetry from a DOTS client is determined by comparing		mitigation telemetry from a DOTS client is determined by comparing
	their respective 'tmid' values. If such two requests have		their respective 'tmid' values. If such two requests have
	overlapping 'target', the PUT request with higher numeric 'tmid'		overlapping 'target', the PUT request with higher numeric 'tmid'
	value will override the request with a lower numeric 'tmid' value.		value will override the request with a lower numeric 'tmid' value.
	The overlapped lower numeric 'tmid' MUST be automatically deleted and		The overlapped lower numeric 'tmid' MUST be automatically deleted and
	no longer be available.		no longer be available.
	Header: PUT (Code=0.03)		Header: PUT (Code=0.03)
	Uri-Path: ".well-known"		Uri-Path: ".well-known"
	Uri-Path: "dots"		Uri-Path: "dots"
	Uri-Path: "tm"		Uri-Path: "tm"
	Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"		Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
	Uri-Path: "tmid=567"		Uri-Path: "tmid=567"
	Content-Format: "application/dots+cbor"		Content-Format: "application/dots+cbor"
	skipping to change at page 58, line 13 ¶		skipping to change at page 59, line 50 ¶
	from that client.		from that client.
	Header: GET (Code=0.01)		Header: GET (Code=0.01)
	Uri-Path: ".well-known"		Uri-Path: ".well-known"
	Uri-Path: "dots"		Uri-Path: "dots"
	Uri-Path: "tm"		Uri-Path: "tm"
	Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"		Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
	Uri-Path: "tmid=567"		Uri-Path: "tmid=567"
	Observe: 0		Observe: 0
	Figure 40: GET to Subscribe to Telemetry Asynchronous Notifications		Figure 40: GET to Subscribe to Telemetry Asynchronous
	for a Specific 'tmid'		Notifications for a Specific 'tmid'
	Header: GET (Code=0.01)		Header: GET (Code=0.01)
	Uri-Path: ".well-known"		Uri-Path: ".well-known"
	Uri-Path: "dots"		Uri-Path: "dots"
	Uri-Path: "tm"		Uri-Path: "tm"
	Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"		Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
	Observe: 0		Observe: 0
	Figure 41: GET to Subscribe to Telemetry Asynchronous Notifications		Figure 41: GET to Subscribe to Telemetry Asynchronous
	for All 'tmids'		Notifications for All 'tmids'
	The DOTS client can use a filter to request a subset of the		The DOTS client can use a filter to request a subset of the
	asynchronous notifications from the DOTS server by indicating one or		asynchronous notifications from the DOTS server by indicating one or
	more Uri-Query options in its GET request. A Uri-Query option can		more Uri-Query options in its GET request. A Uri-Query option can
	include the following parameters to restrict the notifications based		include the following parameters to restrict the notifications based
	on the attack target: 'target-prefix', 'target-port', 'target-		on the attack target: 'target-prefix', 'target-port', 'target-
	protocol', 'target-fqdn', 'target-uri', 'alias-name', 'mid', and 'c'		protocol', 'target-fqdn', 'target-uri', 'alias-name', 'mid', and 'c'
	(content) (Section 4.2.4). Furthermore:		(content) (Section 4.2.4). Furthermore:
	If more than one Uri-Query option is included in a request, these		If more than one Uri-Query option is included in a request, these
	options are interpreted in the same way as when multiple target		options are interpreted in the same way as when multiple target
	attributes are included in a message body.		attributes are included in a message body (Section 4.4.1 of
			[RFC9132]).
	If multiple values of a query parameter are to be included in a		If multiple values of a query parameter are to be included in a
	request, these values MUST be included in the same Uri-Query		request, these values MUST be included in the same Uri-Query
	option and separated by a "," character without any spaces.		option and separated by a "," character without any spaces.
	Range values (i.e., a contiguous inclusive block) can be included		Range values (i.e., a contiguous inclusive block) can be included
	for the 'target-port', 'target-protocol', and 'mid' parameters by		for the 'target-port', 'target-protocol', and 'mid' parameters by
	indicating the two boundary values separated by a "-" character.		indicating the two boundary values separated by a "-" character.
	Wildcard names (i.e., a name with the leftmost label is the "*"		Wildcard names (i.e., a name with the leftmost label is the "*"
	skipping to change at page 59, line 31 ¶		skipping to change at page 61, line 21 ¶
	filter will be applied for all 'tmid's.		filter will be applied for all 'tmid's.
	Header: GET (Code=0.01)		Header: GET (Code=0.01)
	Uri-Path: ".well-known"		Uri-Path: ".well-known"
	Uri-Path: "dots"		Uri-Path: "dots"
	Uri-Path: "tm"		Uri-Path: "tm"
	Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"		Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
	Uri-Query: "target-protocol=17"		Uri-Query: "target-protocol=17"
	Observe: 0		Observe: 0
	Figure 42: GET Request to Receive Telemetry Asynchronous		Figure 42: GET Request to Receive Telemetry Asynchronous
	Notifications Filtered using Uri-Query		Notifications Filtered using Uri-Query
	The DOTS server will send asynchronous notifications to the DOTS		The DOTS server will send asynchronous notifications to the DOTS
	client when an attack event is detected following similar		client when an attack event is detected following similar
	considerations as in Section 4.4.2.1 of [RFC9132]. An example of a		considerations as in Section 4.4.2.1 of [RFC9132]. An example of a
	pre-or-ongoing-mitigation telemetry notification is shown in		pre-or-ongoing-mitigation telemetry notification is shown in
	Figure 43.		Figure 43.
	{		{
	"ietf-dots-telemetry:telemetry": {		"ietf-dots-telemetry:telemetry": {
	"pre-or-ongoing-mitigation": [		"pre-or-ongoing-mitigation": [
	skipping to change at page 60, line 26 ¶		skipping to change at page 62, line 26 ¶
	17		17
	],		],
	"total-attack-traffic": [		"total-attack-traffic": [
	{		{
	"unit": "megabit-ps",		"unit": "megabit-ps",
	"mid-percentile-g": "900"		"mid-percentile-g": "900"
	}		}
	],		],
	"attack-detail": [		"attack-detail": [
	{		{
	"vendor-id": 1234,		"vendor-id": 32473,
	"attack-id": 77,		"attack-id": 77,
	"start-time": "1957818434",		"start-time": "1618339785",
	"attack-severity": "high"		"attack-severity": "high"
	}		}
	]		]
	}		}
	]		]
	}		}
	}		}
	Figure 43: Message Body of a Pre-or-Ongoing-Mitigation Telemetry		Figure 43: Message Body of a Pre-or-Ongoing-Mitigation Telemetry
	Notification from the DOTS Server		Notification from the DOTS Server
	A DOTS server sends the aggregate data for a target using 'total-		A DOTS server sends the aggregate data for a target using 'total-
	attack-traffic' attribute. The aggregate assumes that Uri-Query		attack-traffic' attribute. The aggregate assumes that Uri-Query
	filters are applied on the target. The DOTS server MAY include more		filters are applied on the target. The DOTS server MAY include more
	fine-grained data when needed (that is, 'total-attack-traffic-		fine-grained data when needed (that is, 'total-attack-traffic-
	protocol' and 'total-attack-traffic-port'). If a port filter (or		protocol' and 'total-attack-traffic-port'). If a port filter (or
	protocol filter) is included in a request, 'total-attack-traffic-		protocol filter) is included in a request, 'total-attack-traffic-
	protocol' (or 'total-attack-traffic-port') conveys the data with the		protocol' (or 'total-attack-traffic-port') conveys the data with the
	port (or protocol) filter applied.		port (or protocol) filter applied.
	skipping to change at page 61, line 11 ¶		skipping to change at page 63, line 11 ¶
	A DOTS server may aggregate pre-or-ongoing-mitigation data (e.g.,		A DOTS server may aggregate pre-or-ongoing-mitigation data (e.g.,
	'top-talker') for all targets of a domain, or when justified, send		'top-talker') for all targets of a domain, or when justified, send
	specific information (e.g., 'top-talker') per individual targets.		specific information (e.g., 'top-talker') per individual targets.
	The DOTS client may log pre-or-ongoing-mitigation telemetry data with		The DOTS client may log pre-or-ongoing-mitigation telemetry data with
	an alert sent to an administrator or a network controller. The DOTS		an alert sent to an administrator or a network controller. The DOTS
	client may send a mitigation request if the attack cannot be handled		client may send a mitigation request if the attack cannot be handled
	locally.		locally.
	A DOTS client that is not interested to receive pre-or-ongoing-		A DOTS client that is not interested to receive pre-or-ongoing-
	mitigation telemetry data for a target MUST send a delete request		mitigation telemetry data for a target sends a delete request similar
	similar to the one depicted in Figure 37.		to the one depicted in Figure 37.
	8. DOTS Telemetry Mitigation Status Update		8. DOTS Telemetry Mitigation Status Update
	8.1. DOTS Clients to Servers Mitigation Efficacy DOTS Telemetry		8.1. DOTS Clients to Servers Mitigation Efficacy DOTS Telemetry
	Attributes		Attributes
	The mitigation efficacy telemetry attributes can be signaled from		The mitigation efficacy telemetry attributes can be signaled from
	DOTS clients to DOTS servers as part of the periodic mitigation		DOTS clients to DOTS servers as part of the periodic mitigation
	efficacy updates to the server (Section 4.4.3 of [RFC9132]).		efficacy updates to the server (Section 4.4.3 of [RFC9132]).
	Total Attack Traffic: The overall attack traffic as observed from		Total Attack Traffic: The overall attack traffic as observed from
	the DOTS client perspective during an active mitigation. See		the DOTS client perspective during an active mitigation. See
	Figure 27.		Figure 27.
	Attack Details: The overall attack details as observed from the		Attack Details: The overall attack details as observed from the DOTS
	DOTS client perspective during an active mitigation. See		client perspective during an active mitigation. See
	Section 7.1.5.		Section 7.1.5.
	The "ietf-dots-telemetry" YANG module (Section 10.1) augments the		The "ietf-dots-telemetry" YANG module (Section 10.1) augments the
	'mitigation-scope' message type defined in the "ietf-dots-signal"		'mitigation-scope' message type defined in the "ietf-dots-signal"
	module [RFC9132] so that these attributes can be signalled by a DOTS		module [RFC9132] so that these attributes can be signalled by a DOTS
	client in a mitigation efficacy update (Figure 44).		client in a mitigation efficacy update (Figure 44).
	augment-structure /dots-signal:dots-signal/dots-signal:message-type		augment-structure /dots-signal:dots-signal/dots-signal:message-type
	/dots-signal:mitigation-scope/dots-signal:scope:		/dots-signal:mitigation-scope/dots-signal:scope:
	+-- total-attack-traffic* [unit]		+-- total-attack-traffic* [unit]
	skipping to change at page 62, line 27 ¶		skipping to change at page 64, line 28 ¶
	| +-- lower-type uint8		| +-- lower-type uint8
	| +-- upper-type? uint8		| +-- upper-type? uint8
	+-- total-attack-traffic* [unit]		+-- total-attack-traffic* [unit]
	| +-- unit unit		| +-- unit unit
	| +-- low-percentile-g? yang:gauge64		| +-- low-percentile-g? yang:gauge64
	| +-- mid-percentile-g? yang:gauge64		| +-- mid-percentile-g? yang:gauge64
	| +-- high-percentile-g? yang:gauge64		| +-- high-percentile-g? yang:gauge64
	| +-- peak-g? yang:gauge64		| +-- peak-g? yang:gauge64
	| +-- current-g? yang:gauge64		| +-- current-g? yang:gauge64
	+-- total-attack-connection		+-- total-attack-connection
	+-- low-percentile-c		+-- connection-c
	| +-- connection? yang:gauge64		| +-- low-percentile-g? yang:gauge64
	| +-- embryonic? yang:gauge64		| +-- mid-percentile-g? yang:gauge64
	| +-- connection-ps? yang:gauge64		| +-- high-percentile-g? yang:gauge64
	| +-- request-ps? yang:gauge64		| +-- peak-g? yang:gauge64
	| +-- partial-request-ps? yang:gauge64		| +-- current-g? yang:gauge64
	+-- mid-percentile-c		+-- embryonic-c
	| ...		| ...
	+-- high-percentile-c		+-- connection-ps-c
	| ...		| ...
	+-- peak-c		+-- request-ps-c
	| ...		| ...
	+-- current-c		+-- partial-request-c
	...		...
	Figure 44: Telemetry Efficacy Update Tree Structure		Figure 44: Telemetry Efficacy Update Tree Structure
	In order to signal telemetry data in a mitigation efficacy update, it		In order to signal telemetry data in a mitigation efficacy update, it
	is RECOMMENDED that the DOTS client has already established a DOTS		is RECOMMENDED that the DOTS client has already established a DOTS
	telemetry setup session with the server in 'idle' time.		telemetry setup session with the server in 'idle' time.
	An example of an efficacy update with telemetry attributes is		An example of an efficacy update with telemetry attributes is
	depicted in Figure 45.		depicted in Figure 45.
	skipping to change at page 63, line 34 ¶		skipping to change at page 65, line 34 ¶
	{		{
	"unit": "megabit-ps",		"unit": "megabit-ps",
	"mid-percentile-g": "900"		"mid-percentile-g": "900"
	}		}
	]		]
	}		}
	]		]
	}		}
	}		}
	Figure 45: An Example of Mitigation Efficacy Update with Telemetry		Figure 45: An Example of Mitigation Efficacy Update with
	Attributes		Telemetry Attributes
	8.2. DOTS Servers to Clients Mitigation Status DOTS Telemetry		8.2. DOTS Servers to Clients Mitigation Status DOTS Telemetry
	Attributes		Attributes
	The mitigation status telemetry attributes can be signaled from the		The mitigation status telemetry attributes can be signaled from the
	DOTS server to the DOTS client as part of the periodic mitigation		DOTS server to the DOTS client as part of the periodic mitigation
	status update (Section 4.4.2 of [RFC9132]). In particular, DOTS		status update (Section 4.4.2 of [RFC9132]). In particular, DOTS
	clients can receive asynchronous notifications of the attack details		clients can receive asynchronous notifications of the attack details
	from DOTS servers using the Observe option defined in [RFC7641].		from DOTS servers using the Observe option defined in [RFC7641].
	skipping to change at page 64, line 8 ¶		skipping to change at page 66, line 8 ¶
	telemetry session with the DOTS server in 'idle' time and MUST set		telemetry session with the DOTS server in 'idle' time and MUST set
	the 'server-originated-telemetry' attribute to 'true'.		the 'server-originated-telemetry' attribute to 'true'.
	DOTS servers MUST NOT include telemetry attributes in mitigation		DOTS servers MUST NOT include telemetry attributes in mitigation
	status updates sent to DOTS clients for telemetry sessions in which		status updates sent to DOTS clients for telemetry sessions in which
	the 'server-originated-telemetry' attribute is set to 'false'.		the 'server-originated-telemetry' attribute is set to 'false'.
	As defined in [RFC8612], the actual mitigation activities can include		As defined in [RFC8612], the actual mitigation activities can include
	several countermeasure mechanisms. The DOTS server signals the		several countermeasure mechanisms. The DOTS server signals the
	current operational status of relevant countermeasures. A list of		current operational status of relevant countermeasures. A list of
	attacks detected by each countermeasure MAY also be included. The		attacks detected by these countermeasures MAY also be included. The
	same attributes defined in Section 7.1.5 are applicable for		same attributes defined in Section 7.1.5 are applicable for
	describing the attacks detected and mitigated at the DOTS server		describing the attacks detected and mitigated at the DOTS server
	domain.		domain.
	The "ietf-dots-telemetry" YANG module (Section 10.1) augments the		The "ietf-dots-telemetry" YANG module (Section 10.1) augments the
	'mitigation-scope' message type defined in "ietf-dots-signal"		'mitigation-scope' message type defined in "ietf-dots-signal"
	[RFC9132] with telemetry data as depicted in the following tree		[RFC9132] with telemetry data as depicted in the following tree
	structure:		structure:
	augment-structure /dots-signal:dots-signal/dots-signal:message-type		augment-structure /dots-signal:dots-signal/dots-signal:message-type
	skipping to change at page 64, line 30 ¶		skipping to change at page 66, line 30 ¶
	+-- (direction)?		+-- (direction)?
	| +--:(server-to-client-only)		| +--:(server-to-client-only)
	| +-- total-traffic* [unit]		| +-- total-traffic* [unit]
	| | +-- unit unit		| | +-- unit unit
	| | +-- low-percentile-g? yang:gauge64		| | +-- low-percentile-g? yang:gauge64
	| | +-- mid-percentile-g? yang:gauge64		| | +-- mid-percentile-g? yang:gauge64
	| | +-- high-percentile-g? yang:gauge64		| | +-- high-percentile-g? yang:gauge64
	| | +-- peak-g? yang:gauge64		| | +-- peak-g? yang:gauge64
	| | +-- current-g? yang:gauge64		| | +-- current-g? yang:gauge64
	| +-- total-attack-connection		| +-- total-attack-connection
	| +-- low-percentile-c		| +-- connection-c
	| | +-- connection? yang:gauge64		| | +-- low-percentile-g? yang:gauge64
	| | +-- embryonic? yang:gauge64		| | +-- mid-percentile-g? yang:gauge64
	| | +-- connection-ps? yang:gauge64		| | +-- high-percentile-g? yang:gauge64
	| | +-- request-ps? yang:gauge64		| | +-- peak-g? yang:gauge64
	| | +-- partial-request-ps? yang:gauge64		| | +-- current-g? yang:gauge64
	| +-- mid-percentile-c		| +-- embryonic-c
	| | ...		| | ...
	| +-- high-percentile-c		| +-- connection-ps-c
	| | ...		| | ...
	| +-- peak-c		| +-- request-ps-c
	| | ...		| | ...
	| +-- current-c		| +-- partial-request-c
	| ...		| ...
	+-- total-attack-traffic* [unit]		+-- total-attack-traffic* [unit]
	| +-- unit unit		| +-- unit unit
	| +-- low-percentile-g? yang:gauge64		| +-- low-percentile-g? yang:gauge64
	| +-- mid-percentile-g? yang:gauge64		| +-- mid-percentile-g? yang:gauge64
	| +-- high-percentile-g? yang:gauge64		| +-- high-percentile-g? yang:gauge64
	| +-- peak-g? yang:gauge64		| +-- peak-g? yang:gauge64
	| +-- current-g? yang:gauge64		| +-- current-g? yang:gauge64
	+-- attack-detail* [vendor-id attack-id]		+-- attack-detail* [vendor-id attack-id]
	+-- vendor-id uint32		+-- vendor-id uint32
	skipping to change at page 65, line 33 ¶		skipping to change at page 67, line 33 ¶
	| +-- lower-type uint8		| +-- lower-type uint8
	| +-- upper-type? uint8		| +-- upper-type? uint8
	+-- total-attack-traffic* [unit]		+-- total-attack-traffic* [unit]
	| +-- unit unit		| +-- unit unit
	| +-- low-percentile-g? yang:gauge64		| +-- low-percentile-g? yang:gauge64
	| +-- mid-percentile-g? yang:gauge64		| +-- mid-percentile-g? yang:gauge64
	| +-- high-percentile-g? yang:gauge64		| +-- high-percentile-g? yang:gauge64
	| +-- peak-g? yang:gauge64		| +-- peak-g? yang:gauge64
	| +-- current-g? yang:gauge64		| +-- current-g? yang:gauge64
	+-- total-attack-connection		+-- total-attack-connection
	+-- low-percentile-c		+-- connection-c
	| +-- connection? yang:gauge64		| +-- low-percentile-g? yang:gauge64
	| +-- embryonic? yang:gauge64		| +-- mid-percentile-g? yang:gauge64
	| +-- connection-ps? yang:gauge64		| +-- high-percentile-g? yang:gauge64
	| +-- request-ps? yang:gauge64		| +-- peak-g? yang:gauge64
	| +-- partial-request-ps? yang:gauge64		| +-- current-g? yang:gauge64
	+-- mid-percentile-c		+-- embryonic-c
	| ...		| ...
	+-- high-percentile-c		+-- connection-ps-c
	| ...		| ...
	+-- peak-c		+-- request-ps-c
	| ...		| ...
	+-- current-c		+-- partial-request-c
	...		...
	Figure 46 shows an example of an asynchronous notification of attack		Figure 46 shows an example of an asynchronous notification of attack
	mitigation status from the DOTS server. This notification signals		mitigation status from the DOTS server. This notification signals
	both the mid-percentile value of processed attack traffic and the		both the mid-percentile value of processed attack traffic and the
	peak count of unique sources involved in the attack.		peak count of unique sources involved in the attack.
	{		{
	"ietf-dots-signal-channel:mitigation-scope": {		"ietf-dots-signal-channel:mitigation-scope": {
	"scope": [		"scope": [
	skipping to change at page 66, line 26 ¶		skipping to change at page 68, line 24 ¶
	],		],
	"lifetime": 1600,		"lifetime": 1600,
	"status": "attack-successfully-mitigated",		"status": "attack-successfully-mitigated",
	"bytes-dropped": "134334555",		"bytes-dropped": "134334555",
	"bps-dropped": "43344",		"bps-dropped": "43344",
	"pkts-dropped": "333334444",		"pkts-dropped": "333334444",
	"pps-dropped": "432432",		"pps-dropped": "432432",
	"ietf-dots-telemetry:total-attack-traffic": [		"ietf-dots-telemetry:total-attack-traffic": [
	{		{
	"unit": "megabit-ps",		"unit": "megabit-ps",
	"mid-percentile-g": "900"		"mid-percentile-g": "752"
	}		}
	],		],
	"ietf-dots-telemetry:attack-detail": [		"ietf-dots-telemetry:attack-detail": [
	{		{
	"vendor-id": 1234,		"vendor-id": 32473,
	"attack-id": 77,		"attack-id": 77,
	"source-count": {		"source-count": {
	"peak-g": "10000"		"peak-g": "12683"
	}		}
	}		}
	]		]
	}		}
	]		]
	}		}
	}		}
	Figure 46: Response Body of a Mitigation Status With Telemetry		Figure 46: Response Body of a Mitigation Status With Telemetry
	Attributes		Attributes
	DOTS clients can filter out the asynchronous notifications from the		DOTS clients can filter out the asynchronous notifications from the
	DOTS server by indicating one or more Uri-Query options in its GET		DOTS server by indicating one or more Uri-Query options in its GET
	request. A Uri-Query option can include the following parameters:		request. A Uri-Query option can include the following parameters:
	'target-prefix', 'target-port', 'target-protocol', 'target-fqdn',		'target-prefix', 'target-port', 'target-protocol', 'target-fqdn',
	'target-uri', 'alias-name', and 'c' (content) (Section 4.2.4). The		'target-uri', 'alias-name', and 'c' (content) (Section 4.2.4). The
	considerations discussed in Section 7.3 MUST be followed to include		considerations discussed in Section 7.3 MUST be followed to include
	multiple query values, ranges ('target-port', 'target-protocol'), and		multiple query values, ranges ('target-port', 'target-protocol'), and
	wildcard names ('target-fqdn', 'target-uri').		wildcard names ('target-fqdn', 'target-uri').
	skipping to change at page 67, line 19 ¶		skipping to change at page 69, line 17 ¶
	Header: GET (Code=0.01)		Header: GET (Code=0.01)
	Uri-Path: ".well-known"		Uri-Path: ".well-known"
	Uri-Path: "dots"		Uri-Path: "dots"
	Uri-Path: "mitigate"		Uri-Path: "mitigate"
	Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"		Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
	Uri-Path: "mid=12332"		Uri-Path: "mid=12332"
	Uri-Query: "target-alias=https1"		Uri-Query: "target-alias=https1"
	Observe: 0		Observe: 0
	Figure 47: GET Request to Receive Asynchronous Notifications Filtered		Figure 47: GET Request to Receive Asynchronous Notifications
	using Uri-Query		Filtered using Uri- Query
	If the target query does not match the target of the enclosed 'mid'		If the target query does not match the target of the enclosed 'mid'
	as maintained by the DOTS server, the latter MUST respond with a 4.04		as maintained by the DOTS server, the latter MUST respond with a 4.04
	(Not Found) error Response Code. The DOTS server MUST NOT add a new		(Not Found) error Response Code. The DOTS server MUST NOT add a new
	observe entry if this query overlaps with an existing one.		observe entry if this query overlaps with an existing one. In such a
			case, the DOTS server replies with 4.09 (Conflict).
	9. Error Handling		9. Error Handling
	A list of common CoAP errors that are implemented by DOTS servers are		A list of common CoAP errors that are implemented by DOTS servers are
	provided in Section 9 of [RFC9132]. The following additional error		provided in Section 9 of [RFC9132]. The following additional error
	cases apply for the telemetry extension:		cases apply for the telemetry extension:
	o 4.00 (Bad Request) is returned by the DOTS server when the DOTS		* 4.00 (Bad Request) is returned by the DOTS server when the DOTS
	client has sent a request that violates the DOTS telemetry		client has sent a request that violates the DOTS telemetry
	extension.		extension.
	o 4.04 (Not Found) is returned by the DOTS server when the DOTS		* 4.04 (Not Found) is returned by the DOTS server when the DOTS
	client is requesting a 'tsid' or 'tmid' that is not valid.		client is requesting a 'tsid' or 'tmid' that is not valid.
	o 4.00 (Bad Request) is returned by the DOTS server when the DOTS		* 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		client has sent a request with invalid query types (e.g., not
	supported, malformed).		supported, malformed).
	o 4.04 (Not Found) is returned by the DOTS server when the DOTS		* 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		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.		the target of the enclosed 'mid' as maintained by the DOTS server.
	10. YANG Modules		10. YANG Modules
	10.1. DOTS Signal Channel Telemetry YANG Module		10.1. DOTS Signal Channel Telemetry YANG Module
	This module uses types defined in [RFC6991] and [RFC8345].		This module uses types defined in [RFC6991] and [RFC8345].
	<CODE BEGINS> file "ietf-dots-telemetry@2020-12-07.yang"		<CODE BEGINS> file "ietf-dots-telemetry@2021-11-29.yang"
	module ietf-dots-telemetry {		module ietf-dots-telemetry {
	yang-version 1.1;		yang-version 1.1;
	namespace "urn:ietf:params:xml:ns:yang:ietf-dots-telemetry";		namespace "urn:ietf:params:xml:ns:yang:ietf-dots-telemetry";
	prefix 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
	"Section 3 of RFC 6991";
	}
	import ietf-inet-types {
	prefix inet;
	reference
	"Section 4 of RFC 6991";
	}
	import ietf-network-topology {
	prefix nt;
	reference
	"Section 6.2 of RFC 8345: A YANG Data Model for Network
	Topologies";
	}
	import ietf-yang-structure-ext {
	prefix sx;
	reference
	"RFC 8791: YANG Data Structure Extensions";
	}
	organization		import ietf-dots-signal-channel {
	"IETF DDoS Open Threat Signaling (DOTS) Working Group";		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
			"Section 3 of RFC 6991";
			}
			import ietf-inet-types {
			prefix inet;
			reference
			"Section 4 of RFC 6991";
			}
			import ietf-network-topology {
			prefix nt;
			reference
			"Section 6.2 of RFC 8345: A YANG Data Model for Network
			Topologies";
			}
			import ietf-yang-structure-ext {
			prefix sx;
			reference
			"RFC 8791: YANG Data Structure Extensions";
			}
	contact		organization
	"WG Web: <https://datatracker.ietf.org/wg/dots/>		"IETF DDoS Open Threat Signaling (DOTS) Working Group";
	WG List: <mailto:dots@ietf.org>		contact
			"WG Web: <https://datatracker.ietf.org/wg/dots/>
			WG List: <mailto:dots@ietf.org>
	Author: Mohamed Boucadair		Author: Mohamed Boucadair
	<mailto:mohamed.boucadair@orange.com>		<mailto:mohamed.boucadair@orange.com>
	Author: Konda, Tirumaleswar Reddy		Author: Konda, Tirumaleswar Reddy
	<mailto:TirumaleswarReddy_Konda@McAfee.com>";		<mailto:TirumaleswarReddy_Konda@McAfee.com>";
	description		description
	"This module contains YANG definitions for the signaling		"This module contains YANG definitions for the signaling
	of DOTS telemetry data exchanged between a DOTS client and		of DOTS telemetry data exchanged between a DOTS client and
	a DOTS server by means of the DOTS signal channel.		a DOTS server by means of the DOTS signal channel.
	Copyright (c) 2021 IETF Trust and the persons identified as		Copyright (c) 2021 IETF Trust and the persons identified as
	authors of the code. All rights reserved.		authors of the code. All rights reserved.
	Redistribution and use in source and binary forms, with or		Redistribution and use in source and binary forms, with or
	without modification, is permitted pursuant to, and subject		without modification, is permitted pursuant to, and subject
	to the license terms contained in, the Simplified BSD License		to the license terms contained in, the Simplified BSD License
	set forth in Section 4.c of the IETF Trust's Legal Provisions		set forth in Section 4.c of the IETF Trust's Legal Provisions
	Relating to IETF Documents		Relating to IETF Documents
	(http://trustee.ietf.org/license-info).		(http://trustee.ietf.org/license-info).
	This version of this YANG module is part of RFC XXXX; see		This version of this YANG module is part of RFC XXXX; see
	the RFC itself for full legal notices.";		the RFC itself for full legal notices.";
	revision 2020-12-07 {		revision 2021-11-29 {
	description		description
	"Initial revision.";		"Initial revision.";
	reference		reference
	"RFC XXXX: Distributed Denial-of-Service Open Threat		"RFC XXXX: Distributed Denial-of-Service Open Threat
	Signaling (DOTS) Telemetry";		Signaling (DOTS) Telemetry";
	}		}
	typedef attack-severity {		typedef attack-severity {
	type enumeration {		type enumeration {
	enum none {		enum none {
	value 1;		value 1;
	description		description
	"No effect on the DOTS client domain.";		"No effect on the DOTS client domain.";
	}		}
	enum low {		enum low {
	value 2;		value 2;
	description		description
	"Minimal effect on the DOTS client domain.";		"Minimal effect on the DOTS client domain.";
	}		}
	enum medium {		enum medium {
	value 3;		value 3;
	description		description
	"A subset of DOTS client domain resources are		"A subset of DOTS client domain resources are
	out of service.";		out of service.";
	}		}
	enum high {		enum high {
	value 4;		value 4;
	description		description
	"The DOTS client domain is under extremly severe		"The DOTS client domain is under extremly severe
	conditions.";		conditions.";
	}		}
	enum unknown {		enum unknown {
	value 5;		value 5;
	description		description
	"The impact of the attack is not known.";		"The impact of the attack is not known.";
	}		}
	}		}
	description		description
	"Enumeration for attack severity.";		"Enumeration for attack severity.";
	reference		reference
	"RFC 7970: The Incident Object Description Exchange		"RFC 7970: The Incident Object Description Exchange
	Format Version 2";		Format Version 2, Section 3.12.2";
	}		}
	typedef unit-class {		typedef unit-class {
	type enumeration {		type enumeration {
	enum packet-ps {		enum packet-ps {
	value 1;		value 1;
	description		description
	"Packets per second (pps).";		"Packets per second (pps).";
	}		}
	enum bit-ps {		enum bit-ps {
	value 2;		value 2;
	description		description
	"Bits per Second (bit/s).";		"Bits per Second (bit/s).";
	}		}
	enum byte-ps {		enum byte-ps {
	value 3;		value 3;
	description		description
	"Bytes per second (Byte/s).";		"Bytes per second (Byte/s).";
	}		}
	}		}
	description		description
	"Enumeration to indicate which unit class is used.		"Enumeration to indicate which unit class is used.
	These classes are supported: pps, bit/s, and Byte/s.";		These classes are supported: pps, bit/s, and Byte/s.";
	}		}
			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).";
	typedef unit {		}
	type enumeration {		enum exabit-ps {
	enum packet-ps {		value 20;
	value 1;		description
	description		"Exabits per second (Ebps).";
	"Packets per second (pps).";		}
	}		enum exabyte-ps {
	enum bit-ps {		value 21;
	value 2;		description
	description		"Exabytes per second (EBps).";
	"Bits per Second (bps).";		}
	}		enum zettapacket-ps {
	enum byte-ps {		value 22;
	value 3;		description
	description		"Zetta packets per second (Zpps).";
	"Bytes per second (Bps).";		}
	}		enum zettabit-ps {
	enum kilopacket-ps {		value 23;
	value 4;		description
	description		"Zettabits per second (Zbps).";
	"Kilo packets per second (kpps).";		}
	}		enum zettabyte-ps {
	enum kilobit-ps {		value 24;
	value 5;		description
	description		"Zettabytes per second (ZBps).";
	"Kilobits per second (kbps).";		}
	}		}
	enum kilobyte-ps {		description
	value 6;		"Enumeration to indicate which unit is used.
	description		Only one unit per unit class is used owing to
	"Kilobytes per second (kBps).";		unit auto-scaling.";
	}		}
	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 {		typedef interval {
	type enumeration {		type enumeration {
	enum 5-minutes {		enum 5-minutes {
	value 1;		value 1;
	description		description
	"5 minutes.";		"5 minutes.";
	}		}
	enum 10-minutes {		enum 10-minutes {
	value 2;		value 2;
	description		description
	"10 minutes.";		"10 minutes.";
	}		}
	enum 30-minutes {		enum 30-minutes {
	value 3;		value 3;
	description		description
	"30 minutes.";		"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 {
	enum hour {		type enumeration {
	value 4;		enum second {
	description		value 1;
	"Hour.";		description
	}		"A one-second measurement period.";
	enum day {		}
	value 5;		enum 5-seconds {
	description		value 2;
	"Day.";		description
	}		"5-second measurement period.";
	enum week {		}
	value 6;		enum 30-seconds {
	description		value 3;
	"Week.";		description
	}		"30-second measurement period.";
	enum month {		}
	value 7;		enum minute {
	description		value 4;
	"Month.";		description
	}		"One-minute measurement period.";
	}
	description
	"Enumeration to indicate the overall measurement period.";
	}
	typedef sample {		}
	type enumeration {		enum 5-minutes {
	enum second {		value 5;
	value 1;		description
	description		"5-minute measurement period.";
	"A one-second measurement period.";		}
	}		enum 10-minutes {
	enum 5-seconds {		value 6;
	value 2;		description
	description		"10-minute measurement period.";
	"5-second measurement period.";		}
	}		enum 30-minutes {
	enum 30-seconds {		value 7;
	value 3;		description
	description		"30-minute measurement period.";
	"30-second measurement period.";		}
	}		enum hour {
	enum minute {		value 8;
	value 4;		description
	description		"One-hour measurement period.";
	"One-minute measurement period.";		}
	}		}
	enum 5-minutes {		description
	value 5;		"Enumeration to indicate the sampling period.";
	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 {		typedef percentile {
	type decimal64 {		type decimal64 {
	fraction-digits 2;		fraction-digits 2;
	}		}
	description		description
	"The nth percentile of a set of data is the		"The nth percentile of a set of data is the
	value at which n percent of the data is below it.";		value at which n percent of the data is below it.";
	}		}
	typedef query-type {		typedef query-type {
	type enumeration {		type enumeration {
	enum target-prefix {		enum target-prefix {
	value 1;		value 1;
	description		description
	"Query based on target prefix.";		"Query based on target prefix.";
	}		}
	enum target-port {		enum target-port {
	value 2;		value 2;
	description		description
	"Query based on target port number.";		"Query based on target port number.";
	}		}
	enum target-protocol {		enum target-protocol {
	value 3;		value 3;
	description		description
	"Query based on target protocol.";		"Query based on target protocol.";
	}		}
	enum target-fqdn {		enum target-fqdn {
	value 4;		value 4;
	description		description
	"Query based on target FQDN.";		"Query based on target FQDN.";
	}		}
	enum target-uri {		enum target-uri {
	value 5;		value 5;
	description		description
	"Query based on target URI.";		"Query based on target URI.";
	}		}
	enum target-alias {		enum target-alias {
	value 6;		value 6;
	description		description
	"Query based on target alias.";		"Query based on target alias.";
	}		}
	enum mid {		enum mid {
	value 7;		value 7;
	description		description
	"Query based on mitigation identifier (mid).";		"Query based on mitigation identifier (mid).";
	}		}
	enum source-prefix {		enum source-prefix {
	value 8;		value 8;
	description		description
	"Query based on source prefix.";		"Query based on source prefix.";
	}		}
	enum source-port {		enum source-port {
	value 9;		value 9;
	description		description
	"Query based on source port number.";		"Query based on source port number.";
	}		}
	enum source-icmp-type {		enum source-icmp-type {
	value 10;		value 10;
	description		description
	"Query based on ICMP type";		"Query based on ICMP type";
	}		}
	enum content {		enum content {
	value 11;		value 11;
	description		description
	"Query based on 'c' Uri-Query option that is used		"Query based on 'c' Uri-Query option that is used
	to control the selection of configuration		to control the selection of configuration
	and non-configuration data nodes.";		and non-configuration data nodes.";
	reference		reference
	"Section 4.4.2 of RFC UUUU.";		"Section 4.4.2 of RFC UUUU.";
	}		}
	}
	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		description
	"A grouping that includes a set of parameters that		"Enumeration of support for query types that can be used
	are used to prepare the reported telemetry data.		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.";
			}
	The grouping indicates a measurement interval,		grouping telemetry-parameters {
	a measurement sample period, and low/mid/high		description
	percentile values.";		"A grouping that includes a set of parameters that
	leaf measurement-interval {		are used to prepare the reported telemetry data.
	type interval;
	description
	"Defines the period on 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		The grouping indicates a measurement interval,
	measurement interval value.";		a measurement sample period, and low/mid/high
	}		percentile values.";
	leaf low-percentile {		leaf measurement-interval {
	type percentile;		type interval;
	default "10.00";		description
	description		"Defines the period on which percentiles are computed.";
	"Low percentile. If set to '0', this means low-percentiles		}
	are disabled.";		leaf measurement-sample {
	}		type sample;
	leaf mid-percentile {		description
	type percentile;		"Defines the time distribution for measuring
	must '. >= ../low-percentile' {		values that are used to compute percentiles.
	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 mid-percentiles are disabled.";
	}		The measurement sample value must be less than the
	leaf high-percentile {		measurement interval value.";
	type percentile;		}
	must '. >= ../mid-percentile' {		leaf low-percentile {
	error-message		type percentile;
	"The high-percentile must be greater than		default "10.00";
	or equal to the mid-percentile.";		description
	}		"Low percentile. If set to '0', this means low-percentiles
	default "90.00";		are disabled.";
	description		}
	"High percentile. If set to the same value as mid-percentile,		leaf mid-percentile {
	this means high-percentiles are disabled.";		type percentile;
	}		must '. >= ../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 mid-percentiles are disabled.";
			}
			leaf high-percentile {
			type percentile;
			must '. >= ../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 high-percentiles are disabled.";
			}
			}
	grouping percentile-and-peak {		grouping percentile-and-peak {
	description		description
	"Generic grouping for percentile and peak values.";		"Generic grouping for percentile and peak values.";
	leaf low-percentile-g {		leaf low-percentile-g {
	type yang:gauge64;		type yang:gauge64;
	description		description
	"Low percentile value.";		"Low percentile value.";
	}		}
	leaf mid-percentile-g {		leaf mid-percentile-g {
	type yang:gauge64;		type yang:gauge64;
	description		description
	"Mid percentile value.";		"Mid percentile value.";
	}		}
	leaf high-percentile-g {		leaf high-percentile-g {
	type yang:gauge64;		type yang:gauge64;
	description		description
	"High percentile value.";		"High percentile value.";
	}		}
	leaf peak-g {		leaf peak-g {
	type yang:gauge64;		type yang:gauge64;
	description		description
	"Peak value.";		"Peak value.";
	}		}
	}		}
	grouping unit-config {		grouping percentile-peak-and-current {
	description		description
	"Generic grouping for unit configuration.";		"Generic grouping for percentile and peak values.";
	list unit-config {		uses percentile-and-peak;
	key "unit";		leaf current-g {
	description		type yang:gauge64;
	"Controls which unit classes are allowed when sharing		description
	telemetry data.";		"Current value.";
			}
			}
	leaf unit {		grouping unit-config {
	type unit-class;		description
	description		"Generic grouping for unit configuration.";
	"Can be packet-ps, bit-ps, or byte-ps.";		list unit-config {
	}		key "unit";
	leaf unit-status {		description
	type boolean;		"Controls which unit classes are allowed when sharing
	default true;		telemetry data.";
	description		leaf unit {
	"Enable/disable the use of the measurement unit class.";		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 {		grouping traffic-unit {
	description		description
	"Grouping of traffic as a function of the measurement unit.";		"Grouping of traffic as a function of the measurement unit.";
	leaf unit {		leaf unit {
	type unit;		type unit;
	description		description
	"The traffic can be measured using unit classes: packet-ps,		"The traffic can be measured using unit classes: packet-ps,
	bit-ps, or byte-ps. DOTS agents auto-scale to the appropriate		bit-ps, or byte-ps. DOTS agents auto-scale to the
	units (e.g., megabit-ps, kilobit-ps).";		appropriate units (e.g., megabit-ps, kilobit-ps).";
	}		}
	uses percentile-and-peak;		uses percentile-and-peak;
	}		}
	grouping traffic-unit-all {		grouping traffic-unit-all {
	description		description
	"Grouping of traffic as a function of the measurement unit,		"Grouping of traffic as a function of the measurement unit,
	including current values.";		including current values.";
	uses traffic-unit;		uses traffic-unit;
	leaf current-g {		leaf current-g {
	type yang:gauge64;		type yang:gauge64;
	description		description
	"Current observed value.";		"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:
	<https://www.iana.org/assignments/protocol-numbers/>.		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:
			<https://www.iana.org/assignments/protocol-numbers/>.
	For example, this parameter contains 6 for TCP,		For example, this parameter contains 6 for TCP,
	17 for UDP, 33 for DCCP, or 132 for SCTP.";		17 for UDP, 33 for DCCP, or 132 for SCTP.";
	}		}
	uses traffic-unit;		uses traffic-unit;
	}		}
	grouping traffic-unit-protocol-all {		grouping traffic-unit-protocol-all {
	description		description
	"Grouping of traffic of a given transport protocol as		"Grouping of traffic of a given transport protocol as
	a function of the measurement unit, including current values.";		a function of the measurement unit, including current
	uses traffic-unit-protocol;		values.";
	leaf current-g {		uses traffic-unit-protocol;
	type yang:gauge64;		leaf current-g {
	description		type yang:gauge64;
	"Current observed value.";		description
	}		"Current observed value.";
	}		}
			}
	grouping traffic-unit-port {		grouping traffic-unit-port {
	description		description
	"Grouping of traffic bound to a port number as		"Grouping of traffic bound to a port number as
	a function of the measurement unit.";		a function of the measurement unit.";
	leaf port {		leaf port {
	type inet:port-number;		type inet:port-number;
	description		description
	"Port number used by a transport protocol.";		"Port number used by a transport protocol.";
	}		}
	uses traffic-unit;		uses traffic-unit;
	}		}
	grouping traffic-unit-port-all {		grouping traffic-unit-port-all {
	description		description
	"Grouping of traffic bound to a port number as		"Grouping of traffic bound to a port number as
	a function of the measurement unit, including		a function of the measurement unit, including
	current values.";		current values.";
	uses traffic-unit-port;		uses traffic-unit-port;
	leaf current-g {		leaf current-g {
	type yang:gauge64;		type yang:gauge64;
	description		description
	"Current observed value.";		"Current observed value.";
	}		}
	}		}
	grouping total-connection-capacity {		grouping total-connection-capacity {
	description		description
	"Total connection capacities for various types of		"Total connection capacities for various types of
	connections, as well as overall capacity. These data nodes are		connections, as well as overall capacity. These data nodes are
	useful to detect resource-consuming DDoS attacks.";		useful to detect resource-consuming DDoS attacks.";
	leaf connection {		leaf connection {
	type uint64;		type uint64;
	description		description
	"The maximum number of simultaneous connections that		"The maximum number of simultaneous connections that
	are allowed to the target server.";		are allowed to the target server.";
	}		}
	leaf connection-client {		leaf connection-client {
	type uint64;		type uint64;
	description		description
	"The maximum number of simultaneous connections that		"The maximum number of simultaneous connections that
	are allowed to the target server per client.";		are allowed to the target server per client.";
	}		}
	leaf embryonic {		leaf embryonic {
	type uint64;		type uint64;
	description		description
	"The maximum number of simultaneous embryonic connections		"The maximum number of simultaneous embryonic connections
	that are allowed to the target server. The term 'embryonic		that are allowed to the target server. The term 'embryonic
	connection' refers to a connection whose connection handshake		connection' refers to a connection whose connection
	is not finished. Embryonic connections are only possible in		handshake is not finished. Embryonic connections are only
	connection-oriented transport protocols like TCP or SCTP.";		possible in connection-oriented transport protocols like
	}		TCP or SCTP.";
	leaf embryonic-client {		}
	type uint64;		leaf embryonic-client {
	description		type uint64;
	"The maximum number of simultaneous embryonic connections		description
	that are allowed to the target server per client.";		"The maximum number of simultaneous embryonic connections
	}		that are allowed to the target server per client.";
	leaf connection-ps {		}
	type uint64;		leaf connection-ps {
	description		type uint64;
	"The maximum number of new connections allowed per second		description
	to the target server.";		"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-ps {
	type uint64;
	description
	"The maximum number of partial requests allowed per
	second to the target server.";
	}
	leaf partial-request-client-ps {
	type uint64;
	description
	"The maximum number of partial requests allowed per
	second to the target server per client.";
	}
	}
	grouping total-connection-capacity-protocol {		}
	description		leaf connection-client-ps {
	"Total connections capacity per protocol. These data nodes are		type uint64;
	useful to detect resource consuming DDoS attacks.";		description
	leaf protocol {		"The maximum number of new connections allowed per second
	type uint8;		to the target server per client.";
	description		}
	"The transport protocol.		leaf request-ps {
	Values are taken from the IANA Protocol Numbers registry:		type uint64;
	<https://www.iana.org/assignments/protocol-numbers/>.";		description
	}		"The maximum number of requests allowed per second
	uses total-connection-capacity;		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 connection {		grouping total-connection-capacity-protocol {
	description		description
	"A set of data nodes which represent the attack		"Total connections capacity per protocol. These data nodes are
	characteristics.";		useful to detect resource consuming DDoS attacks.";
	leaf connection {		leaf protocol {
	type yang:gauge64;		type uint8;
	description		description
	"The number of simultaneous attack connections to		"The transport protocol.
	the target server.";		Values are taken from the IANA Protocol Numbers registry:
	}		<https://www.iana.org/assignments/protocol-numbers/>.";
	leaf embryonic {		}
	type yang:gauge64;		uses total-connection-capacity;
	description		}
	"The number of simultaneous embryonic connections to
	the target server.";
	}		grouping connection-percentile-and-peak {
	leaf connection-ps {		description
	type yang:gauge64;		"A set of data nodes which represent the attack
	description		characteristics.";
	"The number of attack connections per second to		container connection-c {
	the target server.";		uses percentile-and-peak;
	}		description
	leaf request-ps {		"The number of simultaneous attack connections to
	type yang:gauge64;		the target server.";
	description		}
	"The number of attack requests per second to		container embryonic-c {
	the target server.";		uses percentile-and-peak;
	}		description
	leaf partial-request-ps {		"The number of simultaneous embryonic connections to
	type yang:gauge64;		the target server.";
	description		}
	"The number of attack partial requests to		container connection-ps-c {
	the target server.";		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-percentile-and-peak {		grouping connection-all {
	description		description
	"Total attack connections. Low/mid/high percentile		"Total attack connections including current values.";
	and peak values are included.";		container connection-c {
	container low-percentile-c {		uses percentile-peak-and-current;
	description		description
	"Low percentile of attack connections.";		"The number of simultaneous attack connections to
	uses connection;		the target server.";
	}		}
	container mid-percentile-c {		container embryonic-c {
	description		uses percentile-peak-and-current;
	"Mid percentile of attack connections.";		description
	uses connection;		"The number of simultaneous embryonic connections to
	}		the target server.";
	container high-percentile-c {		}
	description		container connection-ps-c {
	"High percentile of attack connections.";		uses percentile-peak-and-current;
	uses connection;		description
	}		"The number of attack connections per second to
	container peak-c {		the target server.";
	description		}
	"Peak attack connections.";		container request-ps-c {
	uses connection;		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-all {		grouping connection-protocol {
	description		description
	"Total attack connections including current values.";		"Total attack connections.";
	uses connection-percentile-and-peak;		leaf protocol {
	container current-c {		type uint8;
	description		description
	"Current attack connections.";		"The transport protocol.
	uses connection;		Values are taken from the IANA Protocol Numbers registry:
	}		<https://www.iana.org/assignments/protocol-numbers/>.";
	}		}
			uses connection-percentile-and-peak;
			}
	grouping connection-protocol {		grouping connection-port {
	description		description
	"Total attack connections.";		"Total attack connections per port number.";
	leaf protocol {		leaf protocol {
	type uint8;		type uint8;
	description		description
	"The transport protocol.		"The transport protocol.
	Values are taken from the IANA Protocol Numbers registry:		Values are taken from the IANA Protocol Numbers registry:
	<https://www.iana.org/assignments/protocol-numbers/>.";		<https://www.iana.org/assignments/protocol-numbers/>.";
	}		}
	uses connection;		leaf port {
	}		type inet:port-number;
			description
			"Port number.";
			}
			uses connection-percentile-and-peak;
			}
	grouping connection-port {		grouping connection-protocol-all {
	description		description
	"Total attack connections per port number.";		"Total attack connections per protocol, including current
	leaf port {		values.";
	type inet:port-number;		leaf protocol {
	description		type uint8;
	"Port number.";		description
	}		"The transport protocol.
	uses connection-protocol;		Values are taken from the IANA Protocol Numbers registry:
	}		<https://www.iana.org/assignments/protocol-numbers/>.";
			}
			uses connection-all;
			}
	grouping connection-protocol-percentile {		grouping connection-protocol-port-all {
	description		description
	"Total attack connections per protocol.";		"Total attack connections per port number, including current
	list low-percentile-l {		values.";
	key "protocol";		leaf protocol {
	description		type uint8;
	"Low percentile of attack connections per protocol.";		description
	uses connection-protocol;		"The transport protocol.
	}		Values are taken from the IANA Protocol Numbers registry:
	list mid-percentile-l {		<https://www.iana.org/assignments/protocol-numbers/>.";
	key "protocol";		}
	description		leaf port {
	"Mid percentile of attack connections per protocol.";		type inet:port-number;
	uses connection-protocol;		description
			"Port number.";
			}
			uses connection-all;
			}
	}		grouping attack-detail {
	list high-percentile-l {		description
	key "protocol";		"Various details that describe the on-going
	description		attacks that need to be mitigated by the DOTS server.
	"High percentile of attack connections per protocol.";		The attack details need to cover well-known and common attacks
	uses connection-protocol;		(such as a SYN Flood) along with new emerging or
	}		vendor-specific attacks.";
	list peak-l {		leaf vendor-id {
	key "protocol";		type uint32;
	description		description
	"Peak attack connections per protocol.";		"Vendor ID is a security vendor's Enterprise Number as
	uses connection-protocol;		as registered with IANA.";
	}		reference
	}		"IANA: Private Enterprise Numbers";
			}
			leaf attack-id {
			type uint32;
			description
			"Unique identifier assigned by the vendor for the attack.";
			}
			leaf attack-description {
			type string;
			description
			"Textual representation of 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. Start time is represented in
			seconds relative to 1970-01-01T00:00:00Z.";
			}
			leaf end-time {
			type uint64;
			description
			"The time the attack ended. 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 '. >= ../lower-port' {
			error-message
			"The upper port number must be greater than
			or equal to 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 '. >= ../lower-type' {
			error-message
			"The upper ICMP type must be greater than
			or equal to 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 connection-protocol-all {		grouping top-talker-aggregate {
	description		description
	"Total attack connections per protocol, including current		"An aggregate of top attack sources. This aggregate is
	values.";		typically used when included in a mitigation request.";
	uses connection-protocol-percentile;		list talker {
	list current-l {		key "source-prefix";
	key "protocol";		description
	description		"Refers to a top-talker that is identified by an IPv4
	"Current attack connections per protocol.";		or IPv6 prefix identifying the attacker(s).";
	uses connection-protocol;		uses talker;
	}		container total-attack-connection {
	}		description
			"Total attack connections issued from this source.";
			uses connection-all;
			}
			}
			}
	grouping connection-protocol-port-percentile {		grouping top-talker {
	description		description
	"Total attack connections per port number experessed in		"Top attack sources with detailed per-protocol
	low/mid/high percentile and peak values.";		structure.";
	list low-percentile-l {		list talker {
	key "protocol port";		key "source-prefix";
	description		description
	"Low percentile of attack connections per port number.";		"Refers to a top-talker that is identified by an IPv4
	uses connection-port;		or IPv6 prefix identifying the attacker(s).";
	}		uses talker;
	list mid-percentile-l {		list total-attack-connection-protocol {
	key "protocol port";		key "protocol";
	description		description
	"Mid percentile of attack connections per port number.";		"Total attack connections issued from this source.";
	uses connection-port;
	}
	list high-percentile-l {
	key "protocol port";
	description
	"High percentile of attack connections per port number.";
	uses connection-port;		uses connection-protocol-all;
	}		}
	list peak-l {		}
	key "protocol port";		}
	description
	"Peak attack connections per port number.";
	uses connection-port;
	}
	}
	grouping connection-protocol-port-all {		grouping baseline {
	description		description
	"Total attack connections per port number, including current		"Grouping for the telemetry baseline.";
	values.";		uses data-channel:target;
	uses connection-protocol-port-percentile;		leaf-list alias-name {
	list current-l {		type string;
	key "protocol port";		description
	description		"An alias name that points to an IP resource.
	"Current attack connections per port number.";		An IP resource can be be a router, a host,
	uses connection-port;		an 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.";
	grouping attack-detail {		}
	description		uses total-connection-capacity-protocol;
	"Various details that describe the on-going		}
	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
	"Vendor ID is a security vendor's Enterprise Number.";
	}
	leaf attack-id {
	type uint32;
	description
	"Unique identifier assigned by the vendor for the attack.";
	}
	leaf attack-description {
	type string;
	description
	"Textual representation of 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. Start time is represented in
	seconds relative to 1970-01-01T00:00:00Z in UTC time.";
	}
	leaf end-time {
	type uint64;
	description
	"The time the attack ended. End time is represented in seconds
	relative to 1970-01-01T00:00:00Z in UTC time.";
	}
	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 top-talker-aggregate {		grouping pre-or-ongoing-mitigation {
	description		description
	"An aggregate of top attack sources. This aggregate is		"Grouping for the telemetry data.";
	typically used when included in a mitigation request.";		list total-traffic {
	list talker {		key "unit";
	key "source-prefix";		description
	description		"Total traffic.";
	"IPv4 or IPv6 prefix identifying the attacker(s).";		uses traffic-unit-all;
	leaf spoofed-status {		}
	type boolean;		list total-traffic-protocol {
	description		key "unit protocol";
	"Indicates whether this address is spoofed.";		description
	}		"Total traffic per protocol.";
	leaf source-prefix {		uses traffic-unit-protocol-all;
	type inet:ip-prefix;		}
	description		list total-traffic-port {
	"IPv4 or IPv6 prefix identifying the attacker(s).";		key "unit port";
	}		description
	list source-port-range {		"Total traffic per port number.";
	key "lower-port";		uses traffic-unit-port-all;
	description		}
	"Port range. When only lower-port is		list total-attack-traffic {
	present, it represents a single port number.";		key "unit";
	leaf lower-port {		description
	type inet:port-number;		"Total attack traffic.";
	description		uses traffic-unit-all;
	"Lower port number of the port range.";		}
	}		list total-attack-traffic-protocol {
	leaf upper-port {		key "unit protocol";
	type inet:port-number;		description
	must '. >= ../lower-port' {		"Total attack traffic per protocol.";
	error-message		uses traffic-unit-protocol-all;
	"The upper port number must be greater than		}
	or equal to lower port number.";		list total-attack-traffic-port {
	}		key "unit port";
	description		description
	"Upper port number of the port range.";		"Total attack traffic per port number.";
	}		uses traffic-unit-port-all;
	}		}
	list source-icmp-type-range {		list total-attack-connection-protocol {
	key "lower-type";		key "protocol";
	description		description
	"ICMP type range. When only lower-type is		"Total attack connections.";
	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 '. >= ../lower-type' {
	error-message
	"The upper ICMP type must be greater than
	or equal to 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;
	}
	container total-attack-connection {
	description
	"Total attack connections issued from this source.";
	uses connection-all;
	}
	}
	}
	grouping top-talker {		uses connection-protocol-all;
	description		}
	"Top attack sources.";		list total-attack-connection-port {
	list talker {		key "protocol port";
	key "source-prefix";		description
	description		"Total attack connections per target port number.";
	"IPv4 or IPv6 prefix identifying the attacker(s).";		uses connection-protocol-port-all;
	leaf spoofed-status {		}
	type boolean;		list attack-detail {
	description		key "vendor-id attack-id";
	"Indicates whether this address is spoofed.";		description
	}		"Provides a set of attack details.";
	leaf source-prefix {		uses attack-detail;
	type inet:ip-prefix;		container top-talker {
	description		description
	"IPv4 or IPv6 prefix identifying the attacker(s).";		"Lists the top attack sources.";
	}		uses top-talker;
	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 '. >= ../lower-port' {
	error-message
	"The upper port number must be greater than
	or equal to 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 '. >= ../lower-type' {
	error-message
	"The upper ICMP type must be greater than
	or equal to 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;
	}
	container total-attack-connection {
	description
	"Total attack connections issued from this source.";
	uses connection-protocol-all;
	}
	}
	}
	grouping baseline {		sx:augment-structure "/dots-signal:dots-signal"
	description		+ "/dots-signal:message-type"
	"Grouping for the telemetry baseline.";		+ "/dots-signal:mitigation-scope"
	uses data-channel:target;		+ "/dots-signal:scope" {
	leaf-list alias-name {		description
	type string;		"Extends mitigation scope with telemetry update data.";
	description		choice direction {
	"An alias name that points to an IP resource.		description
	An IP resource can be be a router, a host,		"Indicates the communication direction in which the
	an IoT object, a server, etc.";		data nodes can be included.";
	}		case server-to-client-only {
	list total-traffic-normal {		description
	key "unit";		"These data nodes appear only in a mitigation message
	description		sent from the server to the client.";
	"Total traffic normal baselines.";		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 a telemetry-setup or telemetry data.";
			case telemetry-setup {
			description
			"Indicates the message is about telemetry steup.";
			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.";
			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.";
	uses traffic-unit;		}
	}		leaf telemetry-notify-interval {
	list total-traffic-normal-per-protocol {		type uint16 {
	key "unit protocol";		range "1 .. 3600";
	description		}
	"Total traffic normal baselines per protocol.";		units "seconds";
	uses traffic-unit-protocol;		must '. >= ../../min-config-values'
	}		+ '/telemetry-notify-interval' {
	list total-traffic-normal-per-port {		error-message
	key "unit port";		"The value must be greater than or equal
	description		to the telemetry-notify-interval in the
	"Total traffic normal baselines per port number.";		min-config-values";
	uses traffic-unit-port;		}
	}		description
	list total-connection-capacity {		"Minimum number of seconds between successive
	key "protocol";		telemetry notifications.";
	description		}
	"Total connection capacity.";		}
	uses total-connection-capacity-protocol;		container min-config-values {
	}		description
	list total-connection-capacity-per-port {		"Minimum acceptable configuration values.";
	key "protocol port";		uses telemetry-parameters;
	description		leaf telemetry-notify-interval {
	"Total connection capacity per port number.";		type uint16 {
	leaf port {		range "1 .. 3600";
	type inet:port-number;		}
	description		units "seconds";
	"The target port number.";		description
	}		"Minimum number of seconds between successive
	uses total-connection-capacity-protocol;		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.";
			}
	grouping pre-or-ongoing-mitigation {		}
	description		}
	"Grouping for the telemetry data.";		list telemetry {
	list total-traffic {		description
	key "unit";		"The telemetry data per DOTS client. The keys
	description		of the list are 'cuid' and 'tsid', but these keys are
	"Total traffic.";		not represented here because these keys are conveyed
	uses traffic-unit-all;		as mandatory Uri-Paths in requests. Omitting keys
	}		is compliant with RFC8791.";
	list total-traffic-protocol {		choice direction {
	key "unit protocol";		description
	description		"Indicates the communication direction in which the
	"Total traffic per protocol.";		data nodes can be included.";
	uses traffic-unit-protocol-all;		case server-to-client-only {
	}		description
	list total-traffic-port {		"These data nodes appear only in a mitigation message
	key "unit port";		sent from the server to the client.";
	description		leaf tsid {
	"Total traffic per port number.";		type uint32;
	uses traffic-unit-port-all;		description
	}		"A client-assigned identifier for the DOTS
	list total-attack-traffic {		telemetry setup data.";
	key "unit";		}
	description		}
	"Total attack traffic.";		}
	uses traffic-unit-all;		choice setup-type {
	}		description
	list total-attack-traffic-protocol {		"Can be a mitigation configuration, a pipe capacity,
	key "unit protocol";		or baseline message.";
	description		case telemetry-config {
	"Total attack traffic per protocol.";		description
	uses traffic-unit-protocol-all;		"Used to set telemetry parameters such as setting
	}		low, mid, and high percentile values.";
	list total-attack-traffic-port {		container current-config {
	key "unit port";		description
	description		"Current telemetry configuration values.";
	"Total attack traffic per port number.";		uses telemetry-parameters;
	uses traffic-unit-port-all;		uses unit-config;
	}		leaf server-originated-telemetry {
	container total-attack-connection {		type boolean;
	description		description
	"Total attack connections.";		"Used by a DOTS client to enable/disable whether
	uses connection-protocol-all;		it requests pre-or-ongoing-mitigation telemetry
	}		from the DOTS server.";
	container total-attack-connection-port {		}
	description		leaf telemetry-notify-interval {
	"Total attack connections per target port number.";		type uint16 {
	uses connection-protocol-port-all;		range "1 .. 3600";
	}
	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"		units "seconds";
	+ "/dots-signal:mitigation-scope"		description
	+ "/dots-signal:scope" {		"Minimum number of seconds between successive
	description		telemetry notifications.";
	"Extends mitigation scope with telemetry update data.";		}
	choice direction {		}
	description		}
	"Indicates the communication direction in which the		case pipe {
	data nodes can be included.";		description
	case server-to-client-only {		"Total pipe capacity of a DOTS client domain.";
	description		list total-pipe-capacity {
	"These data nodes appear only in a mitigation message		key "link-id unit";
	sent from the server to the client.";		description
	list total-traffic {		"Total pipe capacity of a DOTS client domain.";
	key "unit";		leaf link-id {
	description		type nt:link-id;
	"Total traffic.";		description
	uses traffic-unit-all;		"Identifier of an interconnection link of
	}		the DOTS client domain.";
	container total-attack-connection {		}
	description		leaf capacity {
	"Total attack connections.";		type uint64;
	uses connection-all;		mandatory true;
	}		description
	}		"Pipe capacity. This attribute is mandatory when
	}		total-pipe-capacity is included in a message.";
	list total-attack-traffic {		}
	key "unit";		leaf unit {
	description		type unit;
	"Total attack traffic.";		description
	uses traffic-unit-all;		"The traffic can be measured using unit classes:
	}		packets per second (pps), bits per second
	list attack-detail {		(bit/s), and/or bytes per second (Byte/s).
	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 a telemetry-setup or telemetry data.";
	case telemetry-setup {
	description
	"Indicates the message is about telemetry steup.";
	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.";
	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 uint32 {
	range "1 .. 3600";
	}
	units "seconds";
	must ". >= ../../min-config-values"
	+ "/telemetry-notify-interval" {
	error-message
	"The value must be greater than or equal
	to the telemetry-notify-interval in the
	min-config-values";
	}
	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 uint32 {
	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 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 RFC8791.";
	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.";
	leaf tsid {
	type uint32;
	description
	"A client-assigned identifier for the DOTS telemetry
	setup data.";
	}		For a given unit class, the DOTS agents
	}		auto-scales to the appropriate units (e.g.,
	}		megabit-ps, kilobit-ps).";
	choice setup-type {		}
	description		}
	"Can be a mitigation configuration, a pipe capacity,		}
	or baseline message.";		case baseline {
	case telemetry-config {		description
	description		"Traffic baseline information of a DOTS client
	"Used to set telemetry parameters such as setting		domain.";
	low, mid, and high percentile values.";		list baseline {
	container current-config {		key "id";
	description		description
	"Current telemetry configuration values.";		"Traffic baseline information of a DOTS client
	uses telemetry-parameters;		domain.";
	uses unit-config;		leaf id {
	leaf server-originated-telemetry {		type uint32;
	type boolean;		must '. >= 1';
	description		description
	"Used by a DOTS client to enable/disable whether it		"An identifier that uniquely identifies a
	requests pre-or-ongoing-mitigation telemetry from		baseline entry communicated by a DOTS client.";
	the DOTS server.";		}
	}		uses baseline;
	leaf telemetry-notify-interval {		}
	type uint32 {		}
	range "1 .. 3600";		}
	}		}
	units "seconds";		}
	description		case telemetry {
	"Minimum number of seconds between successive		description
	telemetry notifications.";		"Telemetry information.";
	}		list pre-or-ongoing-mitigation {
	}		description
	}		"Pre-or-ongoing-mitigation telemetry per DOTS client.
	case pipe {		The keys of the list are 'cuid' and 'tmid', but these
	description		keys are not represented here because these keys are
	"Total pipe capacity of a DOTS client domain.";		conveyed as mandatory Uri-Paths in requests.
	list total-pipe-capacity {		Omitting keys is compliant with RFC8791.";
	key "link-id unit";		choice direction {
	description		description
	"Total pipe capacity of a DOTS client domain.";		"Indicates the communication direction in which the
	leaf link-id {		data nodes can be included.";
	type nt:link-id;		case server-to-client-only {
	description		description
	"Identifier of an interconnection link of		"These data nodes appear only in a mitigation message
	the DOTS client domain.";		sent from the server to the client.";
	}		leaf tmid {
	leaf capacity {		type uint32;
	type uint64;		description
	mandatory true;		"A client-assigned identifier for the DOTS
	description		telemetry data.";
	"Pipe capacity. This attribute is mandatory when		}
	total-pipe-capacity is included in a message.";		}
	}		}
	leaf unit {		container target {
	type unit;		description
	description		"Indicates the target. At least one of the attributes
	"The traffic can be measured using unit classes:		'target-prefix', 'target-fqdn', 'target-uri',
	packets per second (pps), bits per second (bit/s),		'alias-name', or 'mid-list' must be present in the
	and/or bytes per second (Byte/s).		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 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;
			}
			}
			}
			}
			}
			<CODE ENDS>
	For a given unit class, the DOTS agents auto-scales
	to the appropriate units (e.g., megabit-ps,
	kilobit-ps).";
	}
	}
	}
	case baseline {
	description
	"Traffic baseline information of a DOTS client domain.";
	list baseline {
	key "id";
	description
	"Traffic baseline information of a DOTS client
	domain.";
	leaf id {
	type uint32;
	must '. >= 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 RFC8791.";
	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.";
	leaf tmid {
	type uint32;
	description
	"An identifier to uniquely demux telemetry data sent
	using the same message.";
	}
	}
	}
	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 a list of associated mitigation requests.";
	}
	}
	uses pre-or-ongoing-mitigation;
	}
	}
	}
	}
	}
	<CODE ENDS>
	10.2. Vendor Attack Mapping Details YANG Module		10.2. Vendor Attack Mapping Details YANG Module
	<CODE BEGINS> file "ietf-dots-mapping@2020-06-26.yang"		<CODE BEGINS> file "ietf-dots-mapping@2020-06-26.yang"
	module ietf-dots-mapping {		module ietf-dots-mapping {
	yang-version 1.1;		yang-version 1.1;
	namespace "urn:ietf:params:xml:ns:yang:ietf-dots-mapping";		namespace "urn:ietf:params:xml:ns:yang:ietf-dots-mapping";
	prefix dots-mapping;		prefix dots-mapping;
	import ietf-dots-data-channel {		import ietf-dots-data-channel {
	prefix data-channel;		prefix data-channel;
	reference		reference
	"RFC 8783: Distributed Denial-of-Service Open Threat		"RFC 8783: Distributed Denial-of-Service Open Threat
	Signaling (DOTS) Data Channel Specification";		Signaling (DOTS) Data Channel Specification";
	}		}
	organization		organization
	"IETF DDoS Open Threat Signaling (DOTS) Working Group";		"IETF DDoS Open Threat Signaling (DOTS) Working Group";
	contact		contact
	"WG Web: <https://datatracker.ietf.org/wg/dots/>		"WG Web: <https://datatracker.ietf.org/wg/dots/>
	WG List: <mailto:dots@ietf.org>		WG List: <mailto:dots@ietf.org>
	Author: Mohamed Boucadair		Author: Mohamed Boucadair
	<mailto:mohamed.boucadair@orange.com>		<mailto:mohamed.boucadair@orange.com>
	Author: Jon Shallow		Author: Jon Shallow
	<mailto:supjps-ietf@jpshallow.com>";		<mailto:supjps-ietf@jpshallow.com>";
	description		description
	"This module contains YANG definitions for the sharing		"This module contains YANG definitions for the sharing
	DDoS attack mapping details between a DOTS client and		DDoS attack mapping details between a DOTS client and
	a DOTS server, by means of the DOTS data channel.		a DOTS server, by means of the DOTS data channel.
	Copyright (c) 2021 IETF Trust and the persons identified as		Copyright (c) 2021 IETF Trust and the persons identified as
	authors of the code. All rights reserved.		authors of the code. All rights reserved.
	Redistribution and use in source and binary forms, with or		Redistribution and use in source and binary forms, with or
	without modification, is permitted pursuant to, and subject		without modification, is permitted pursuant to, and subject
	to the license terms contained in, the Simplified BSD License		to the license terms contained in, the Simplified BSD License
	set forth in Section 4.c of the IETF Trust's Legal Provisions		set forth in Section 4.c of the IETF Trust's Legal Provisions
	Relating to IETF Documents		Relating to IETF Documents
	(http://trustee.ietf.org/license-info).		(http://trustee.ietf.org/license-info).
	This version of this YANG module is part of RFC XXXX; see		This version of this YANG module is part of RFC XXXX; see
	the RFC itself for full legal notices.";		the RFC itself for full legal notices.";
	revision 2020-06-26 {		revision 2020-06-26 {
	description		description
	"Initial revision.";		"Initial revision.";
	reference		reference
	"RFC XXXX: Distributed Denial-of-Service Open Threat		"RFC XXXX: Distributed Denial-of-Service Open Threat
	Signaling (DOTS) Telemetry";		Signaling (DOTS) Telemetry";
	}		}
	feature dots-telemetry {		feature dots-telemetry {
	description		description
	"This feature indicates that DOTS telemetry data can be		"This feature indicates that DOTS telemetry data can be
	shared between DOTS clients and servers.";		shared between DOTS clients and servers.";
	}		}
	grouping attack-mapping {		grouping attack-mapping {
	description
	"A set of information used for sharing vendor attack mapping
	information with a peer.";
	list vendor {
	key "vendor-id";
	description		description
	"Vendor attack mapping information of the client/server";		"A set of information used for sharing vendor attack mapping
	leaf vendor-id {		information with a peer.";
	type uint32;		list vendor {
	description		key "vendor-id";
	"Vendor ID is a security vendor's Enterprise Number.";
	}
	leaf vendor-name {
	type string;
	description
	"The name of the vendor (e.g., company A).";
	}
	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 in UTC time.";
	}
	list attack-mapping {
	key "attack-id";
	description		description
	"Attack mapping details.";		"Vendor attack mapping information of the client/server";
	leaf attack-id {		leaf vendor-id {
	type uint32;		type uint32;
	description		description
	"Unique identifier assigned by the vendor for the attack.";		"Vendor ID is a security vendor's Enterprise Number as
			registered with IANA.";
			reference
			"IANA: Private Enterprise Numbers";
	}		}
	leaf attack-description {		leaf vendor-name {
	type string;		type string;
			description
			"The name of the vendor (e.g., company A).";
			}
			leaf last-updated {
			type uint64;
	mandatory true;		mandatory true;
	description		description
	"Textual representation of attack description. Natural		"The time the mapping table was updated. It is represented
	Language Processing techniques (e.g., word embedding)		in seconds relative to 1970-01-01T00:00:00Z.";
	might provide some utility in mapping the attack		}
	description to an attack type.";		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 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" {		augment "/data-channel:dots-data/data-channel:dots-client" {
	if-feature "dots-telemetry";		if-feature "dots-telemetry";
	description
	"Augments the data channel with a vendor attack
	mapping table of the DOTS client.";
	container vendor-mapping {
	description		description
	"Used by DOTS clients to share their vendor		"Augments the data channel with a vendor attack
	attack mapping information with DOTS servers.";		mapping table of the DOTS client.";
	uses attack-mapping;		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" {		augment "/data-channel:dots-data/data-channel:capabilities" {
	if-feature "dots-telemetry";		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		description
	"Indicates that the server supports sharing		"Augments the DOTS server capabilities with a
	attack vendor mapping details with DOTS clients.";		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" {		augment "/data-channel:dots-data" {
	if-feature "dots-telemetry";		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		description
	"Includes the list of vendor attack mapping details		"Augments the data channel with a vendor attack
	that will be shared upon request with DOTS clients.";		mapping table of the DOTS server.";
	uses attack-mapping;		container vendor-mapping {
			config false;
			description
			"Includes the list of vendor attack mapping details
			that will be shared upon request with DOTS clients.";
			uses attack-mapping;
			}
	}		}
	}		}
	}		<CODE ENDS>
	<CODE ENDS>
	11. YANG/JSON Mapping Parameters to CBOR		11. YANG/JSON Mapping Parameters to CBOR
	All DOTS telemetry parameters in the payload of the DOTS signal		All DOTS telemetry parameters in the payload of the DOTS signal
	channel MUST be mapped to CBOR types as shown in Table 2:		channel MUST be mapped to CBOR types as shown in Table 2:
	o Note: Implementers must check that the mapping output provided by		* Note: Implementers must check that the mapping output provided by
	their YANG-to-CBOR encoding schemes is aligned with the content of		their YANG-to-CBOR encoding schemes is aligned with the content of
	Table 2.		Table 2.
	+----------------------+-------------+------+---------------+--------+		+----------------------+-------------+------+---------------+--------+
	| Parameter Name | YANG | CBOR | CBOR Major | JSON |		| Parameter Name | YANG | CBOR | CBOR Major | JSON |
	| | Type | Key | Type & | Type |		| | Type | Key | Type & | Type |
	| | | | Information | |		| | | | Information | |
	+======================+=============+======+===============+========+		+======================+=============+======+===============+========+
	| tsid | uint32 |TBA1 | 0 unsigned | Number |		| tsid | uint32 |TBA1 | 0 unsigned | Number |
	| telemetry | container |TBA2 | 5 map | Object |		| telemetry | list |TBA2 | 4 array | Array |
	| low-percentile | decimal64 |TBA3 | 6 tag 4 | |		| low-percentile | decimal64 |TBA3 | 6 tag 4 | |
	| | | | [-2, integer]| String |		| | | | [-2, integer]| String |
	| mid-percentile | decimal64 |TBA4 | 6 tag 4 | |		| mid-percentile | decimal64 |TBA4 | 6 tag 4 | |
	| | | | [-2, integer]| String |		| | | | [-2, integer]| String |
	| high-percentile | decimal64 |TBA5 | 6 tag 4 | |		| high-percentile | decimal64 |TBA5 | 6 tag 4 | |
	| | | | [-2, integer]| String |		| | | | [-2, integer]| String |
	| unit-config | list |TBA6 | 4 array | Array |		| unit-config | list |TBA6 | 4 array | Array |
	| unit | enumeration |TBA7 | 0 unsigned | String |		| unit | enumeration |TBA7 | 0 unsigned | String |
	| unit-status | boolean |TBA8 | 7 bits 20 | False |		| unit-status | boolean |TBA8 | 7 bits 20 | False |
	| | | | 7 bits 21 | True |		| | | | 7 bits 21 | True |
	skipping to change at page 103, line 8 ¶		skipping to change at page 103, line 36 ¶
	| total-connection- | | | | |		| total-connection- | | | | |
	| capacity | list |TBA19 | 4 array | Array |		| capacity | list |TBA19 | 4 array | Array |
	| connection | uint64 |TBA20 | 0 unsigned | String |		| connection | uint64 |TBA20 | 0 unsigned | String |
	| connection-client | uint64 |TBA21 | 0 unsigned | String |		| connection-client | uint64 |TBA21 | 0 unsigned | String |
	| embryonic | uint64 |TBA22 | 0 unsigned | String |		| embryonic | uint64 |TBA22 | 0 unsigned | String |
	| embryonic-client | uint64 |TBA23 | 0 unsigned | String |		| embryonic-client | uint64 |TBA23 | 0 unsigned | String |
	| connection-ps | uint64 |TBA24 | 0 unsigned | String |		| connection-ps | uint64 |TBA24 | 0 unsigned | String |
	| connection-client-ps | uint64 |TBA25 | 0 unsigned | String |		| connection-client-ps | uint64 |TBA25 | 0 unsigned | String |
	| request-ps | uint64 |TBA26 | 0 unsigned | String |		| request-ps | uint64 |TBA26 | 0 unsigned | String |
	| request-client-ps | uint64 |TBA27 | 0 unsigned | String |		| request-client-ps | uint64 |TBA27 | 0 unsigned | String |
	| partial-request-ps | uint64 |TBA28 | 0 unsigned | String |		| partial-request-max | uint64 |TBA28 | 0 unsigned | String |
	| partial-request- | | | | |		| partial-request- | | | | |
	| client-ps | uint64 |TBA29 | 0 unsigned | String |		| client-max | uint64 |TBA29 | 0 unsigned | String |
	| total-attack- | | | | |		| total-attack- | | | | |
	| connection | container |TBA30 | 5 map | Object |		| connection | container |TBA30 | 5 map | Object |
	| low-percentile-l | list |TBA31 | 4 array | Array |		| connection-c | container |TBA31 | 5 map | Object |
	| mid-percentile-l | list |TBA32 | 4 array | Array |		| embryonic-c | container |TBA32 | 5 map | Object |
	| high-percentile-l | list |TBA33 | 4 array | Array |		| connection-ps-c | container |TBA33 | 5 map | Object |
	| peak-l | list |TBA34 | 4 array | Array |		| request-ps-c | container |TBA34 | 5 map | Object |
	| attack-detail | list |TBA35 | 4 array | Array |		| attack-detail | list |TBA35 | 4 array | Array |
	| id | uint32 |TBA36 | 0 unsigned | Number |		| id | uint32 |TBA36 | 0 unsigned | Number |
	| attack-id | uint32 |TBA37 | 0 unsigned | Number |		| attack-id | uint32 |TBA37 | 0 unsigned | Number |
	| attack-description | string |TBA38 | 3 text string | String |		| attack-description | string |TBA38 | 3 text string | String |
	| attack-severity | enumeration |TBA39 | 0 unsigned | String |		| attack-severity | enumeration |TBA39 | 0 unsigned | String |
	| start-time | uint64 |TBA40 | 0 unsigned | String |		| start-time | uint64 |TBA40 | 0 unsigned | String |
	| end-time | uint64 |TBA41 | 0 unsigned | String |		| end-time | uint64 |TBA41 | 0 unsigned | String |
	| source-count | container |TBA42 | 5 map | Object |		| source-count | container |TBA42 | 5 map | Object |
	| top-talker | container |TBA43 | 5 map | Object |		| top-talker | container |TBA43 | 5 map | Object |
	| spoofed-status | boolean |TBA44 | 7 bits 20 | False |		| spoofed-status | boolean |TBA44 | 7 bits 20 | False |
	| | | | 7 bits 21 | True |		| | | | 7 bits 21 | True |
	| low-percentile-c | container |TBA45 | 5 map | Object |		| partial-request-c | container |TBA45 | 5 map | Object |
	| mid-percentile-c | container |TBA46 | 5 map | Object |		| total-attack- | | | | |
	| high-percentile-c | container |TBA47 | 5 map | Object |		| connection-protocol | list |TBA46 | 4 array | Array |
	| peak-c | container |TBA48 | 5 map | Object |		| baseline | list |TBA49 | 4 array | Array |
	| baseline | container |TBA49 | 5 map | Object |
	| current-config | container |TBA50 | 5 map | Object |		| current-config | container |TBA50 | 5 map | Object |
	| max-config-values | container |TBA51 | 5 map | Object |		| max-config-values | container |TBA51 | 5 map | Object |
	| min-config-values | container |TBA52 | 5 map | Object |		| min-config-values | container |TBA52 | 5 map | Object |
	|supported-unit-classes| container |TBA53 | 5 map | Object |		|supported-unit-classes| container |TBA53 | 5 map | Object |
	| server-originated- | boolean |TBA54 | 7 bits 20 | False |		| server-originated- | boolean |TBA54 | 7 bits 20 | False |
	| telemetry | | | 7 bits 21 | True |		| telemetry | | | 7 bits 21 | True |
	| telemetry-notify- | uint32 |TBA55 | 0 unsigned | Number |		| telemetry-notify- | uint32 |TBA55 | 0 unsigned | Number |
	| interval | | | | |		| interval | | | | |
	| tmid | uint32 |TBA56 | 0 unsigned | Number |		| tmid | uint32 |TBA56 | 0 unsigned | Number |
	| measurement-interval | enumeration |TBA57 | 0 unsigned | String |		| measurement-interval | enumeration |TBA57 | 0 unsigned | String |
	skipping to change at page 104, line 24 ¶		skipping to change at page 104, line 51 ¶
	| protocol | list |TBA70 | 4 array | Array |		| protocol | list |TBA70 | 4 array | Array |
	| total-traffic-port | list |TBA71 | 4 array | Array |		| total-traffic-port | list |TBA71 | 4 array | Array |
	| total-attack- | | | | |		| total-attack- | | | | |
	| traffic-protocol | list |TBA72 | 4 array | Array |		| traffic-protocol | list |TBA72 | 4 array | Array |
	| total-attack- | | | | |		| total-attack- | | | | |
	| traffic-port | list |TBA73 | 4 array | Array |		| traffic-port | list |TBA73 | 4 array | Array |
	| total-attack- | | | | |		| total-attack- | | | | |
	| connection-port | list |TBA74 | 4 array | Array |		| connection-port | list |TBA74 | 4 array | Array |
	| port | inet: | | | |		| port | inet: | | | |
	| | port-number|TBA75 | 0 unsigned | Number |		| | port-number|TBA75 | 0 unsigned | Number |
	| query-type | leaf-list |TBA76 | 4 array | Array |		| supported-query-type | leaf-list |TBA76 | 4 array | Array |
	| | | | 0 unsigned | String |		| | | | 0 unsigned | String |
	| vendor-id | uint32 |TBA77 | 0 unsigned | Number |		| vendor-id | uint32 |TBA77 | 0 unsigned | Number |
	| ietf-dots-telemetry: | | | | |		| ietf-dots-telemetry: | | | | |
	| telemetry-setup | container |TBA78 | 5 map | Object |		| telemetry-setup | container |TBA78 | 5 map | Object |
	| ietf-dots-telemetry: | | | | |		| ietf-dots-telemetry: | | | | |
	| total-traffic | list |TBA79 | 4 array | Array |		| total-traffic | list |TBA79 | 4 array | Array |
	| ietf-dots-telemetry: | | | | |		| ietf-dots-telemetry: | | | | |
	| total-attack-traffic | list |TBA80 | 4 array | Array |		| total-attack-traffic | list |TBA80 | 4 array | Array |
	| ietf-dots-telemetry: | | | | |		| ietf-dots-telemetry: | | | | |
	| total-attack- | | | | |		| total-attack- | | | | |
	| connection | container |TBA81 | 5 map | Object |		| connection | container |TBA81 | 5 map | Object |
	| ietf-dots-telemetry: | | | | |		| ietf-dots-telemetry: | | | | |
	| attack-detail | list |TBA82 | 4 array | Array |		| attack-detail | list |TBA82 | 4 array | Array |
	| ietf-dots-telemetry: | | | | |		| ietf-dots-telemetry: | | | | |
	| telemetry | container |TBA83 | 5 map | Object |		| telemetry | container |TBA83 | 5 map | Object |
	| current-g | yang:gauge64|TBA84 | 0 unsigned | String |		| current-g | yang:gauge64|TBA84 | 0 unsigned | String |
	| current-l | list |TBA85 | 4 array | Array |
	| current-c | container |TBA86 | 5 map | Object |
	| lower-type | uint8 |32771 | 0 unsigned | Number |		| lower-type | uint8 |32771 | 0 unsigned | Number |
	| upper-type | uint8 |32772 | 0 unsigned | Number |		| upper-type | uint8 |32772 | 0 unsigned | Number |
	+----------------------+-------------+------+---------------+--------+		+----------------------+-------------+------+---------------+--------+
	Table 2: YANG/JSON Mapping Parameters to CBOR		Table 2: YANG/JSON Mapping Parameters to CBOR
	12. IANA Considerations		12. IANA Considerations
	12.1. DOTS Signal Channel CBOR Key Values		12.1. DOTS Signal Channel CBOR Key Values
	This specification registers the DOTS telemetry attributes in the		This specification registers the DOTS telemetry attributes in the
	IANA "DOTS Signal Channel CBOR Key Values" registry [Key-Map].		IANA "DOTS Signal Channel CBOR Key Values" registry [Key-Map].
	The DOTS telemetry attributes defined in this specification are		The DOTS telemetry attributes defined in this specification are
	comprehension-optional parameters.		comprehension-optional parameters.
	o Note to the RFC Editor: CBOR keys are assigned from the "128-255"		* Note to the RFC Editor: CBOR keys are assigned from the "128-255"
	range. This specification meets the requirements listed in		range. This specification meets the requirements listed in
	Section 3.1 [RFC9132] for assignments in the "128-255" range.		Section 3.1 [RFC9132] for assignments in the "128-255" range.
	+----------------------+-------+-------+------------+---------------+		+----------------------+-------+-------+------------+---------------+
	| Parameter Name | CBOR | CBOR | Change | Specification |		| Parameter Name | CBOR | CBOR | Change | Specification |
	| | Key | Major | Controller | Document(s) |		| | Key | Major | Controller | Document(s) |
	| | Value | Type | | |		| | Value | Type | | |
	+======================+=======+=======+============+===============+		+======================+=======+=======+============+===============+
	| tsid | TBA1 | 0 | IESG | [RFCXXXX] |		| tsid | TBA1 | 0 | IESG | [RFCXXXX] |
	| telemetry | TBA2 | 5 | IESG | [RFCXXXX] |		| telemetry | TBA2 | 4 | IESG | [RFCXXXX] |
	| low-percentile | TBA3 | 6tag4 | IESG | [RFCXXXX] |		| low-percentile | TBA3 | 6tag4 | IESG | [RFCXXXX] |
	| mid-percentile | TBA4 | 6tag4 | IESG | [RFCXXXX] |		| mid-percentile | TBA4 | 6tag4 | IESG | [RFCXXXX] |
	| high-percentile | TBA5 | 6tag4 | IESG | [RFCXXXX] |		| high-percentile | TBA5 | 6tag4 | IESG | [RFCXXXX] |
	| unit-config | TBA6 | 4 | IESG | [RFCXXXX] |		| unit-config | TBA6 | 4 | IESG | [RFCXXXX] |
	| unit | TBA7 | 0 | IESG | [RFCXXXX] |		| unit | TBA7 | 0 | IESG | [RFCXXXX] |
	| unit-status | TBA8 | 7 | IESG | [RFCXXXX] |		| unit-status | TBA8 | 7 | IESG | [RFCXXXX] |
	| total-pipe-capacity | TBA9 | 4 | IESG | [RFCXXXX] |		| total-pipe-capacity | TBA9 | 4 | IESG | [RFCXXXX] |
	| link-id | TBA10 | 3 | IESG | [RFCXXXX] |		| link-id | TBA10 | 3 | IESG | [RFCXXXX] |
	| pre-or-ongoing- | TBA11 | 4 | IESG | [RFCXXXX] |		| pre-or-ongoing- | TBA11 | 4 | IESG | [RFCXXXX] |
	| mitigation | | | | |		| mitigation | | | | |
	skipping to change at page 106, line 4 ¶		skipping to change at page 106, line 26 ¶
	| total-connection- | TBA19 | 4 | IESG | [RFCXXXX] |		| total-connection- | TBA19 | 4 | IESG | [RFCXXXX] |
	| capacity | | | | |		| capacity | | | | |
	| connection | TBA20 | 0 | IESG | [RFCXXXX] |		| connection | TBA20 | 0 | IESG | [RFCXXXX] |
	| connection-client | TBA21 | 0 | IESG | [RFCXXXX] |		| connection-client | TBA21 | 0 | IESG | [RFCXXXX] |
	| embryonic | TBA22 | 0 | IESG | [RFCXXXX] |		| embryonic | TBA22 | 0 | IESG | [RFCXXXX] |
	| embryonic-client | TBA23 | 0 | IESG | [RFCXXXX] |		| embryonic-client | TBA23 | 0 | IESG | [RFCXXXX] |
	| connection-ps | TBA24 | 0 | IESG | [RFCXXXX] |		| connection-ps | TBA24 | 0 | IESG | [RFCXXXX] |
	| connection-client-ps | TBA25 | 0 | IESG | [RFCXXXX] |		| connection-client-ps | TBA25 | 0 | IESG | [RFCXXXX] |
	| request-ps | TBA26 | 0 | IESG | [RFCXXXX] |		| request-ps | TBA26 | 0 | IESG | [RFCXXXX] |
	| request-client-ps | TBA27 | 0 | IESG | [RFCXXXX] |		| request-client-ps | TBA27 | 0 | IESG | [RFCXXXX] |
	| partial-request-ps | TBA28 | 0 | IESG | [RFCXXXX] |		| partial-request-max | TBA28 | 0 | IESG | [RFCXXXX] |
	| partial-request- | TBA29 | 0 | IESG | [RFCXXXX] |		| partial-request- | TBA29 | 0 | IESG | [RFCXXXX] |
	| client-ps | | | | |		| client-max | | | | |
	| total-attack- | TBA30 | 5 | IESG | [RFCXXXX] |		| total-attack- | TBA30 | 5 | IESG | [RFCXXXX] |
	| connection | | | | |		| connection | | | | |
	| low-percentile-l | TBA31 | 4 | IESG | [RFCXXXX] |		| connection-c | TBA31 | 5 | IESG | [RFCXXXX] |
	| mid-percentile-l | TBA32 | 4 | IESG | [RFCXXXX] |		| embryonic-c | TBA32 | 5 | IESG | [RFCXXXX] |
	| high-percentile-l | TBA33 | 4 | IESG | [RFCXXXX] |		| connection-ps-c | TBA33 | 5 | IESG | [RFCXXXX] |
	| peak-l | TBA34 | 4 | IESG | [RFCXXXX] |		| request-ps-c | TBA34 | 5 | IESG | [RFCXXXX] |
	| attack-detail | TBA35 | 4 | IESG | [RFCXXXX] |		| attack-detail | TBA35 | 4 | IESG | [RFCXXXX] |
	| id | TBA36 | 0 | IESG | [RFCXXXX] |		| id | TBA36 | 0 | IESG | [RFCXXXX] |
	| attack-id | TBA37 | 0 | IESG | [RFCXXXX] |		| attack-id | TBA37 | 0 | IESG | [RFCXXXX] |
	| attack-description | TBA38 | 3 | IESG | [RFCXXXX] |		| attack-description | TBA38 | 3 | IESG | [RFCXXXX] |
	| attack-severity | TBA39 | 0 | IESG | [RFCXXXX] |		| attack-severity | TBA39 | 0 | IESG | [RFCXXXX] |
	| start-time | TBA40 | 0 | IESG | [RFCXXXX] |		| start-time | TBA40 | 0 | IESG | [RFCXXXX] |
	| end-time | TBA41 | 0 | IESG | [RFCXXXX] |		| end-time | TBA41 | 0 | IESG | [RFCXXXX] |
	| source-count | TBA42 | 5 | IESG | [RFCXXXX] |		| source-count | TBA42 | 5 | IESG | [RFCXXXX] |
	| top-talker | TBA43 | 5 | IESG | [RFCXXXX] |		| top-talker | TBA43 | 5 | IESG | [RFCXXXX] |
	| spoofed-status | TBA44 | 7 | IESG | [RFCXXXX] |		| spoofed-status | TBA44 | 7 | IESG | [RFCXXXX] |
	| low-percentile-c | TBA45 | 5 | IESG | [RFCXXXX] |		| partial-request-c | TBA45 | 5 | IESG | [RFCXXXX] |
	| mid-percentile-c | TBA46 | 5 | IESG | [RFCXXXX] |		| total-attack- | TBA46 | 4 | IESG | [RFCXXXX] |
	| high-percentile-c | TBA47 | 5 | IESG | [RFCXXXX] |		| connection-protocol | | | | |
	| peak-c | TBA48 | 5 | IESG | [RFCXXXX] |		| baseline | TBA49 | 4 | IESG | [RFCXXXX] |
	| baseline | TBA49 | 5 | IESG | [RFCXXXX] |
	| current-config | TBA50 | 5 | IESG | [RFCXXXX] |		| current-config | TBA50 | 5 | IESG | [RFCXXXX] |
	| max-config-value | TBA51 | 5 | IESG | [RFCXXXX] |		| max-config-value | TBA51 | 5 | IESG | [RFCXXXX] |
	| min-config-values | TBA52 | 5 | IESG | [RFCXXXX] |		| min-config-values | TBA52 | 5 | IESG | [RFCXXXX] |
	|supported-unit-classes| TBA53 | 5 | IESG | [RFCXXXX] |		|supported-unit-classes| TBA53 | 5 | IESG | [RFCXXXX] |
	| server-originated- | TBA54 | 7 | IESG | [RFCXXXX] |		| server-originated- | TBA54 | 7 | IESG | [RFCXXXX] |
	| telemetry | | | | |		| telemetry | | | | |
	| telemetry-notify- | TBA55 | 0 | IESG | [RFCXXXX] |		| telemetry-notify- | TBA55 | 0 | IESG | [RFCXXXX] |
	| interval | | | | |		| interval | | | | |
	| tmid | TBA56 | 0 | IESG | [RFCXXXX] |		| tmid | TBA56 | 0 | IESG | [RFCXXXX] |
	| measurement-interval | TBA57 | 0 | IESG | [RFCXXXX] |		| measurement-interval | TBA57 | 0 | IESG | [RFCXXXX] |
	skipping to change at page 107, line 16 ¶		skipping to change at page 107, line 37 ¶
	| total-traffic- | TBA70 | 4 | IESG | [RFCXXXX] |		| total-traffic- | TBA70 | 4 | IESG | [RFCXXXX] |
	| protocol | | | | |		| protocol | | | | |
	| total-traffic-port | TBA71 | 4 | IESG | [RFCXXXX] |		| total-traffic-port | TBA71 | 4 | IESG | [RFCXXXX] |
	| total-attack- | TBA72 | 4 | IESG | [RFCXXXX] |		| total-attack- | TBA72 | 4 | IESG | [RFCXXXX] |
	| traffic-protocol | | | | |		| traffic-protocol | | | | |
	| total-attack- | TBA73 | 4 | IESG | [RFCXXXX] |		| total-attack- | TBA73 | 4 | IESG | [RFCXXXX] |
	| traffic-port | | | | |		| traffic-port | | | | |
	| total-attack- | TBA74 | 4 | IESG | [RFCXXXX] |		| total-attack- | TBA74 | 4 | IESG | [RFCXXXX] |
	| connection-port | | | | |		| connection-port | | | | |
	| port | TBA75 | 0 | IESG | [RFCXXXX] |		| port | TBA75 | 0 | IESG | [RFCXXXX] |
	| query-type | TBA76 | 4 | IESG | [RFCXXXX] |		| supported-query-type | TBA76 | 4 | IESG | [RFCXXXX] |
	| vendor-id | TBA77 | 0 | IESG | [RFCXXXX] |		| vendor-id | TBA77 | 0 | IESG | [RFCXXXX] |
	| ietf-dots-telemetry: | TBA78 | 5 | IESG | [RFCXXXX] |		| ietf-dots-telemetry: | TBA78 | 5 | IESG | [RFCXXXX] |
	| telemetry-setup | | | | |		| telemetry-setup | | | | |
	| ietf-dots-telemetry: | TBA79 | 4 | IESG | [RFCXXXX] |		| ietf-dots-telemetry: | TBA79 | 4 | IESG | [RFCXXXX] |
	| total-traffic | | | | |		| total-traffic | | | | |
	| ietf-dots-telemetry: | TBA80 | 4 | IESG | [RFCXXXX] |		| ietf-dots-telemetry: | TBA80 | 4 | IESG | [RFCXXXX] |
	| total-attack-traffic | | | | |		| total-attack-traffic | | | | |
	| ietf-dots-telemetry: | TBA81 | 5 | IESG | [RFCXXXX] |		| ietf-dots-telemetry: | TBA81 | 5 | IESG | [RFCXXXX] |
	| total-attack- | | | | |		| total-attack- | | | | |
	| connection | | | | |		| connection | | | | |
	| ietf-dots-telemetry: | TBA82 | 4 | IESG | [RFCXXXX] |		| ietf-dots-telemetry: | TBA82 | 4 | IESG | [RFCXXXX] |
	| attack-detail | | | | |		| attack-detail | | | | |
	| ietf-dots-telemetry: | TBA83 | 5 | IESG | [RFCXXXX] |		| ietf-dots-telemetry: | TBA83 | 5 | IESG | [RFCXXXX] |
	| telemetry | | | | |		| telemetry | | | | |
	| current-g | TBA84 | 0 | IESG | [RFCXXXX] |		| current-g | TBA84 | 0 | IESG | [RFCXXXX] |
	| current-l | TBA85 | 4 | IESG | [RFCXXXX] |
	| current-c | TBA86 | 5 | IESG | [RFCXXXX] |
	+----------------------+-------+-------+------------+---------------+		+----------------------+-------+-------+------------+---------------+
	Table 3: Registered DOTS Signal Channel CBOR Key Values		Table 3: Registered DOTS Signal Channel CBOR Key Values
	12.2. DOTS Signal Channel Conflict Cause Codes		12.2. DOTS Signal Channel Conflict Cause Codes
	This specification requests IANA to assign a new code from the "DOTS		This specification requests IANA to assign a new code from the "DOTS
	Signal Channel Conflict Cause Codes" registry [Cause].		Signal Channel Conflict Cause Codes" registry [Cause].
	+------+-------------------+------------------------+-------------+		+------+-------------------+------------------------+-------------+
	skipping to change at page 108, line 47 ¶		skipping to change at page 109, line 18 ¶
	The security considerations for the DOTS signal channel protocol are		The security considerations for the DOTS signal channel protocol are
	discussed in Section 11 of [RFC9132]. The following discusses the		discussed in Section 11 of [RFC9132]. The following discusses the
	security considerations that are specific to the DOTS signal channel		security considerations that are specific to the DOTS signal channel
	extension defined in this document.		extension defined in this document.
	The DOTS telemetry information includes DOTS client network topology,		The DOTS telemetry information includes DOTS client network topology,
	DOTS client domain pipe capacity, normal traffic baseline and		DOTS client domain pipe capacity, normal traffic baseline and
	connections capacity, and threat and mitigation information. Such		connections capacity, and threat and mitigation information. Such
	information is sensitive; it MUST be protected at rest by the DOTS		information is sensitive; it MUST be protected at rest by the DOTS
	server domain to prevent data leakage.		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 that 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.
	DOTS clients are typically considered to be trusted devices by the		DOTS clients are typically considered to be trusted devices by the
	DOTS client domain. DOTS clients may be co-located on network		DOTS client domain. DOTS clients may be co-located on network
	security services (e.g., firewall devices), and a compromised		security services (e.g., firewall devices), and a compromised
	security service potentially can do a lot more damage to the network		security service potentially can do a lot more damage to the network
	than just the DOTS client component. This assumption differs from		than just the DOTS client component. This assumption differs from
	the often held view that devices are untrusted, often referred to as		the often held view that devices are untrusted, often referred to as
	the "zero-trust model". A compromised DOTS client can send fake DOTS		the "zero-trust model". A compromised DOTS client can send fake DOTS
	telemetry data to a DOTS server to mislead the DOTS server. This		telemetry data to a DOTS server to mislead the DOTS server. This
	attack can be prevented by monitoring and auditing DOTS clients to		attack can be prevented by monitoring and auditing DOTS clients to
	skipping to change at page 109, line 22 ¶		skipping to change at page 109, line 47 ¶
	telemetry for its IP addresses but a DDoS mitigator can 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,		telemetry for any target resource in the network). As a reminder,
	this is a variation of dealing with compromised DOTS clients as		this is a variation of dealing with compromised DOTS clients as
	discussed in Section 11 of [RFC9132].		discussed in Section 11 of [RFC9132].
	DOTS servers must be capable of defending themselves against DoS		DOTS servers must be capable of defending themselves against DoS
	attacks from compromised DOTS clients. The following non-		attacks from compromised DOTS clients. The following non-
	comprehensive list of mitigation techniques can be used by a DOTS		comprehensive list of mitigation techniques can be used by a DOTS
	server to handle misbehaving DOTS clients:		server to handle misbehaving DOTS clients:
	o The probing rate (defined in Section 4.5 of [RFC9132]) can be used		* The probing rate (defined in Section 4.5 of [RFC9132]) can be used
	to limit the average data rate to the DOTS server.		to limit the average data rate to the DOTS server.
	o Rate-limiting DOTS telemetry, including those with new 'tmid'		* Rate-limiting DOTS telemetry, including those with new 'tmid'
	values, from the same DOTS client defends against DoS attacks that		values, from the same DOTS client defends against DoS attacks that
	would result in varying the 'tmid' to exhaust DOTS server		would result in varying the 'tmid' to exhaust DOTS server
	resources. Likewise, the DOTS server can enforce a quota and		resources. Likewise, the DOTS server can enforce a quota and
	time-limit on the number of active pre-or-ongoing-mitigation		time-limit on the number of active pre-or-ongoing-mitigation
	telemetry data items (identified by 'tmid') from the DOTS client.		telemetry data items (identified by 'tmid') from the DOTS client.
	Note also that telemetry notification interval may be used to rate-		Note also that telemetry notification interval may be used to rate-
	limit the pre-or-ongoing-mitigation telemetry notifications received		limit the pre-or-ongoing-mitigation telemetry notifications received
	by a DOTS client domain.		by a DOTS client domain.
	skipping to change at page 110, line 5 ¶		skipping to change at page 110, line 33 ¶
	All data nodes defined in the YANG module specified in Section 10.2		All data nodes defined in the YANG module specified in Section 10.2
	which can be created, modified, and deleted (i.e., config true, which		which can be created, modified, and deleted (i.e., config true, which
	is the default) are considered sensitive. Write operations to these		is the default) are considered sensitive. Write operations to these
	data nodes without proper protection can have a negative effect on		data nodes without proper protection can have a negative effect on
	network operations. Appropriate security measures are recommended to		network operations. Appropriate security measures are recommended to
	prevent illegitimate users from invoking DOTS data channel primitives		prevent illegitimate users from invoking DOTS data channel primitives
	as discussed in [RFC8783]. Nevertheless, an attacker who can access		as discussed in [RFC8783]. Nevertheless, an attacker who can access
	a DOTS client is technically capable of undertaking various attacks,		a DOTS client is technically capable of undertaking various attacks,
	such as:		such as:
	o Communicating invalid attack mapping details to the server		* Communicating invalid attack mapping details to the server
	('/data-channel:dots-data/data-channel:dots-client/dots-		('/data-channel:dots-data/data-channel:dots-client/dots-
	telemetry:vendor-mapping'), which will mislead the server when		telemetry:vendor-mapping'), which will mislead the server when
	correlating attack details.		correlating attack details.
	Some of the readable data nodes in the YANG module specified in		Some of the readable data nodes in the YANG module specified in
	Section 10.2 may be considered sensitive. It is thus important to		Section 10.2 may be considered sensitive. It is thus important to
	control read access to these data nodes. These are the data nodes		control read access to these data nodes. These are the data nodes
	and their sensitivity:		and their sensitivity:
	o '/data-channel:dots-data/data-channel:dots-client/dots-		* '/data-channel:dots-data/data-channel:dots-client/dots-
	telemetry:vendor-mapping' can be misused to infer the DDoS		telemetry:vendor-mapping' can be misused to infer the DDoS
	protection technology deployed in a DOTS client domain.		protection technology deployed in a DOTS client domain.
	o '/data-channel:dots-data/dots-telemetry:vendor-mapping' can be		* '/data-channel:dots-data/dots-telemetry:vendor-mapping' can be
	used by a compromised DOTS client to leak the attack detection		used by a compromised DOTS client to leak the attack detection
	capabilities of the DOTS server. This is a variation of the		capabilities of the DOTS server. This is a variation of the
	compromised DOTS client attacks discussed in Section 13.1.		compromised DOTS client attacks discussed in Section 13.1.
	14. Contributors		14. Contributors
	The following individuals have contributed to this document:		The following individuals have contributed to this document:
	o Li Su, CMCC, Email: suli@chinamobile.com		* Li Su, CMCC, Email: suli@chinamobile.com
	o Pan Wei, Huawei, Email: william.panwei@huawei.com		* Pan Wei, Huawei, Email: william.panwei@huawei.com
	15. Acknowledgements		15. Acknowledgements
	The authors would like to thank Flemming Andreasen, Liang Xia, and		The authors would like to thank Flemming Andreasen, Liang Xia, and
	Kaname Nishizuka co-authors of [I-D.doron-dots-telemetry] and		Kaname Nishizuka co-authors of [I-D.doron-dots-telemetry] and
	everyone who had contributed to that document.		everyone who had contributed to that document.
	The authors would like to thank Kaname Nishizuka, Wei Pan, and Yuuhei		The authors would like to thank Kaname Nishizuka, Wei Pan, and Yuuhei
	Hayashi for comments and review.		Hayashi for comments and review.
	skipping to change at page 111, line 10 ¶		skipping to change at page 111, line 35 ¶
	Many thanks to Jan Lindblad for the yangdoctors review and Nagendra		Many thanks to Jan Lindblad for the yangdoctors review and Nagendra
	Nainar for the opsdir review.		Nainar for the opsdir review.
	Thanks to Benjamin Kaduk for the detailed AD review.		Thanks to Benjamin Kaduk for the detailed AD review.
	16. References		16. References
	16.1. Normative References		16.1. Normative References
	[Enterprise-Numbers]		[Enterprise-Numbers]
	"Private Enterprise Numbers", May 2020,		"Private Enterprise Numbers", 4 May 2020,
	<http://www.iana.org/assignments/enterprise-numbers.html>.		<http://www.iana.org/assignments/enterprise-numbers.html>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,		[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
	DOI 10.17487/RFC3688, January 2004,		DOI 10.17487/RFC3688, January 2004,
	<https://www.rfc-editor.org/info/rfc3688>.		<https://www.rfc-editor.org/info/rfc3688>.
	skipping to change at page 112, line 23 ¶		skipping to change at page 112, line 50 ¶
	[RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N.,		[RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N.,
	Ananthakrishnan, H., and X. Liu, "A YANG Data Model for		Ananthakrishnan, H., and X. Liu, "A YANG Data Model for
	Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March		Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March
	2018, <https://www.rfc-editor.org/info/rfc8345>.		2018, <https://www.rfc-editor.org/info/rfc8345>.
	[RFC8783] Boucadair, M., Ed. and T. Reddy.K, Ed., "Distributed		[RFC8783] Boucadair, M., Ed. and T. Reddy.K, Ed., "Distributed
	Denial-of-Service Open Threat Signaling (DOTS) Data		Denial-of-Service Open Threat Signaling (DOTS) Data
	Channel Specification", RFC 8783, DOI 10.17487/RFC8783,		Channel Specification", RFC 8783, DOI 10.17487/RFC8783,
	May 2020, <https://www.rfc-editor.org/info/rfc8783>.		May 2020, <https://www.rfc-editor.org/info/rfc8783>.
	[RFC8791] Bierman, A., Bjoerklund, M., and K. Watsen, "YANG Data		[RFC8791] Bierman, A., Björklund, M., and K. Watsen, "YANG Data
	Structure Extensions", RFC 8791, DOI 10.17487/RFC8791,		Structure Extensions", RFC 8791, DOI 10.17487/RFC8791,
	June 2020, <https://www.rfc-editor.org/info/rfc8791>.		June 2020, <https://www.rfc-editor.org/info/rfc8791>.
	[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object		[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
	Representation (CBOR)", STD 94, RFC 8949,		Representation (CBOR)", STD 94, RFC 8949,
	DOI 10.17487/RFC8949, December 2020,		DOI 10.17487/RFC8949, December 2020,
	<https://www.rfc-editor.org/info/rfc8949>.		<https://www.rfc-editor.org/info/rfc8949>.
	[RFC9132] Boucadair, M., Ed., Shallow, J., and T. Reddy.K,		[RFC9132] Boucadair, M., Ed., Shallow, J., and T. Reddy.K,
	"Distributed Denial-of-Service Open Threat Signaling		"Distributed Denial-of-Service Open Threat Signaling
	(DOTS) Signal Channel Specification", RFC 9132,		(DOTS) Signal Channel Specification", RFC 9132,
	DOI 10.17487/RFC9132, September 2021,		DOI 10.17487/RFC9132, September 2021,
	<https://www.rfc-editor.org/info/rfc9132>.		<https://www.rfc-editor.org/info/rfc9132>.
	[RFC9133] Nishizuka, K., Boucadair, M., Reddy.K, T., and T. Nagata,
	"Controlling Filtering Rules Using Distributed Denial-of-
	Service Open Threat Signaling (DOTS) Signal Channel",
	RFC 9133, DOI 10.17487/RFC9133, September 2021,
	<https://www.rfc-editor.org/info/rfc9133>.
	16.2. Informative References		16.2. Informative References
	[Cause] IANA, "DOTS Signal Channel Conflict Cause Codes",		[Cause] IANA, "DOTS Signal Channel Conflict Cause Codes",
	<https://www.iana.org/assignments/dots/dots.xhtml#dots-		<https://www.iana.org/assignments/dots/dots.xhtml#dots-
	signal-channel-conflict-cause-codes>.		signal-channel-conflict-cause-codes>.
	[I-D.doron-dots-telemetry]		[I-D.doron-dots-telemetry]
	Doron, E., Reddy, T., Andreasen, F., (Frank), L. X., and		Doron, E., Reddy, T., Andreasen, F., (Frank), L. X., and
	K. Nishizuka, "Distributed Denial-of-Service Open Threat		K. Nishizuka, "Distributed Denial-of-Service Open Threat
	Signaling (DOTS) Telemetry Specifications", draft-doron-		Signaling (DOTS) Telemetry Specifications", Work in
	dots-telemetry-00 (work in progress), October 2016.		Progress, Internet-Draft, draft-doron-dots-telemetry-00,
			30 October 2016, <https://www.ietf.org/archive/id/draft-
			doron-dots-telemetry-00.txt>.
	[I-D.ietf-core-new-block]		[I-D.ietf-core-new-block]
	Boucadair, M. and J. Shallow, "Constrained Application		Boucadair, M. and J. Shallow, "Constrained Application
	Protocol (CoAP) Block-Wise Transfer Options Supporting		Protocol (CoAP) Block-Wise Transfer Options Supporting
	Robust Transmission", draft-ietf-core-new-block-14 (work		Robust Transmission", Work in Progress, Internet-Draft,
	in progress), May 2021.		draft-ietf-core-new-block-14, 26 May 2021,
			<https://www.ietf.org/archive/id/draft-ietf-core-new-
			block-14.txt>.
	[I-D.ietf-dots-multihoming]		[I-D.ietf-dots-multihoming]
	Boucadair, M., Reddy, T., and W. Pan, "Multi-homing		Boucadair, M., Reddy, T., and W. Pan, "Multi-homing
	Deployment Considerations for Distributed-Denial-of-		Deployment Considerations for Distributed-Denial-of-
	Service Open Threat Signaling (DOTS)", draft-ietf-dots-		Service Open Threat Signaling (DOTS)", Work in Progress,
	multihoming-08 (work in progress), October 2021.		Internet-Draft, draft-ietf-dots-multihoming-09, 2 December
			2021, <https://www.ietf.org/archive/id/draft-ietf-dots-
			multihoming-09.txt>.
	[I-D.ietf-dots-robust-blocks]		[I-D.ietf-dots-robust-blocks]
	Boucadair, M. and J. Shallow, "Distributed Denial-of-		Boucadair, M. and J. Shallow, "Distributed Denial-of-
	Service Open Threat Signaling (DOTS) Signal Channel		Service Open Threat Signaling (DOTS) Signal Channel
	Configuration Attributes for Robust Block Transmission",		Configuration Attributes for Robust Block Transmission",
	draft-ietf-dots-robust-blocks-00 (work in progress),		Work in Progress, Internet-Draft, draft-ietf-dots-robust-
	August 2021.		blocks-00, 23 August 2021,
			<https://www.ietf.org/archive/id/draft-ietf-dots-robust-
			blocks-00.txt>.
	[Key-Map] IANA, "DOTS Signal Channel CBOR Key Values",		[Key-Map] IANA, "DOTS Signal Channel CBOR Key Values",
	<https://www.iana.org/assignments/dots/dots.xhtml#dots-		<https://www.iana.org/assignments/dots/dots.xhtml#dots-
	signal-channel-cbor-key-values>.		signal-channel-cbor-key-values>.
			[PYANG] "pyang", November 2020,
			<https://github.com/mbj4668/pyang>.
	[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,		[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
	"Framework for IP Performance Metrics", RFC 2330,		"Framework for IP Performance Metrics", RFC 2330,
	DOI 10.17487/RFC2330, May 1998,		DOI 10.17487/RFC2330, May 1998,
	<https://www.rfc-editor.org/info/rfc2330>.		<https://www.rfc-editor.org/info/rfc2330>.
			[RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet
			Denial-of-Service Considerations", RFC 4732,
			DOI 10.17487/RFC4732, December 2006,
			<https://www.rfc-editor.org/info/rfc4732>.
	[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",		[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",
	RFC 4960, DOI 10.17487/RFC4960, September 2007,		RFC 4960, DOI 10.17487/RFC4960, September 2007,
	<https://www.rfc-editor.org/info/rfc4960>.		<https://www.rfc-editor.org/info/rfc4960>.
			[RFC5612] Eronen, P. and D. Harrington, "Enterprise Number for
			Documentation Use", RFC 5612, DOI 10.17487/RFC5612, August
			2009, <https://www.rfc-editor.org/info/rfc5612>.
	[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",		[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
	BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,		BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
	<https://www.rfc-editor.org/info/rfc8340>.		<https://www.rfc-editor.org/info/rfc8340>.
	[RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K.,		[RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K.,
	and R. Wilton, "YANG Library", RFC 8525,		and R. Wilton, "YANG Library", RFC 8525,
	DOI 10.17487/RFC8525, March 2019,		DOI 10.17487/RFC8525, March 2019,
	<https://www.rfc-editor.org/info/rfc8525>.		<https://www.rfc-editor.org/info/rfc8525>.
	[RFC8612] Mortensen, A., Reddy, T., and R. Moskowitz, "DDoS Open		[RFC8612] Mortensen, A., Reddy, T., and R. Moskowitz, "DDoS Open
	Threat Signaling (DOTS) Requirements", RFC 8612,		Threat Signaling (DOTS) Requirements", RFC 8612,
	DOI 10.17487/RFC8612, May 2019,		DOI 10.17487/RFC8612, May 2019,
	<https://www.rfc-editor.org/info/rfc8612>.		<https://www.rfc-editor.org/info/rfc8612>.
			[RFC8811] Mortensen, A., Ed., Reddy.K, T., Ed., Andreasen, F.,
			Teague, N., and R. Compton, "DDoS Open Threat Signaling
			(DOTS) Architecture", RFC 8811, DOI 10.17487/RFC8811,
			August 2020, <https://www.rfc-editor.org/info/rfc8811>.
	[RFC8903] Dobbins, R., Migault, D., Moskowitz, R., Teague, N., Xia,		[RFC8903] Dobbins, R., Migault, D., Moskowitz, R., Teague, N., Xia,
	L., and K. Nishizuka, "Use Cases for DDoS Open Threat		L., and K. Nishizuka, "Use Cases for DDoS Open Threat
	Signaling", RFC 8903, DOI 10.17487/RFC8903, May 2021,		Signaling", RFC 8903, DOI 10.17487/RFC8903, May 2021,
	<https://www.rfc-editor.org/info/rfc8903>.		<https://www.rfc-editor.org/info/rfc8903>.
			[RFC9133] Nishizuka, K., Boucadair, M., Reddy.K, T., and T. Nagata,
			"Controlling Filtering Rules Using Distributed Denial-of-
			Service Open Threat Signaling (DOTS) Signal Channel",
			RFC 9133, DOI 10.17487/RFC9133, September 2021,
			<https://www.rfc-editor.org/info/rfc9133>.
	Authors' Addresses		Authors' Addresses
	Mohamed Boucadair (editor)		Mohamed Boucadair (editor)
	Orange		Orange
	Rennes 35000		35000 Rennes
	France		France
	Email: mohamed.boucadair@orange.com		Email: mohamed.boucadair@orange.com
	Tirumaleswar Reddy (editor)		Tirumaleswar Reddy (editor)
	McAfee, Inc.		Akamai
	Embassy Golf Link Business Park		Embassy Golf Link Business Park
	Bangalore, Karnataka 560071		Bangalore 560071
			Karnataka
	India		India
	Email: kondtir@gmail.com		Email: kondtir@gmail.com
	Ehud Doron		Ehud Doron
	Radware Ltd.		Radware Ltd.
	Raoul Wallenberg Street		Raoul Wallenberg Street
	Tel-Aviv 69710		Tel-Aviv 69710
	Israel		Israel
	Email: ehudd@radware.com		Email: ehudd@radware.com
	Meiling Chen		Meiling Chen
	CMCC		CMCC
	32, Xuanwumen West		32, Xuanwumen West
	BeiJing, BeiJing 100053		BeiJing
			BeiJing, 100053
	China		China
	Email: chenmeiling@chinamobile.com		Email: chenmeiling@chinamobile.com
	Jon Shallow		Jon Shallow
	United Kingdom		United Kingdom
	Email: supjps-ietf@jpshallow.com		Email: supjps-ietf@jpshallow.com
End of changes. 274 change blocks.
	2028 lines changed or deleted		2089 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/