< draft-ietf-dots-telemetry-16.txt		draft-ietf-dots-telemetry-17.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: November 26, 2021 McAfee		Expires: May 20, 2022 McAfee
	E. Doron		E. Doron
	Radware Ltd.		Radware Ltd.
	M. Chen		M. Chen
	CMCC		CMCC
	J. Shallow		J. Shallow
	May 25, 2021		November 16, 2021
	Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry		Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry
	draft-ietf-dots-telemetry-16		draft-ietf-dots-telemetry-17
	Abstract		Abstract
	This document aims to enrich DOTS signal channel protocol with		This document aims to enrich the DOTS signal channel protocol with
	various telemetry attributes allowing optimal Distributed Denial-of-		various telemetry attributes, allowing for optimal Distributed
	Service attack mitigation. It specifies the normal traffic baseline		Denial-of-Service attack mitigation. It specifies the normal traffic
	and attack traffic telemetry attributes a DOTS client can convey to		baseline and attack traffic telemetry attributes a DOTS client can
	its DOTS server in the mitigation request, the mitigation status		convey to its DOTS server in the mitigation request, the mitigation
	telemetry attributes a DOTS server can communicate to a DOTS client,		status telemetry attributes a DOTS server can communicate to a DOTS
	and the mitigation efficacy telemetry attributes a DOTS client can		client, and the mitigation efficacy telemetry attributes a DOTS
	communicate to a DOTS server. The telemetry attributes can assist		client can communicate to a DOTS server. The telemetry attributes
	the mitigator to choose the DDoS mitigation techniques and perform		can assist the mitigator to choose the DDoS mitigation techniques and
	optimal DDoS attack mitigation.		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 November 26, 2021.		This Internet-Draft will expire on May 20, 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/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 28 ¶		skipping to change at page 2, line 28 ¶
	described in the Simplified 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5
	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 . . . . . . . . . . . . . . . . . . 6
	3.2. Enhanced Detection . . . . . . . . . . . . . . . . . . . 7		3.2. Enhanced Detection . . . . . . . . . . . . . . . . . . . 7
	3.3. Efficient Mitigation . . . . . . . . . . . . . . . . . . 9		3.3. Efficient Mitigation . . . . . . . . . . . . . . . . . . 9
	4. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 9		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 . . . . . . . . . . . . . . . . . 10
	4.2.1. DOTS Client Identification . . . . . . . . . . . . . 10		4.2.1. DOTS Client Identification . . . . . . . . . . . . . 10
	4.2.2. DOTS Gateways . . . . . . . . . . . . . . . . . . . . 10		4.2.2. DOTS Gateways . . . . . . . . . . . . . . . . . . . . 10
	4.2.3. Empty URI Paths . . . . . . . . . . . . . . . . . . . 11		4.2.3. Empty URI Paths . . . . . . . . . . . . . . . . . . . 11
	4.2.4. Controlling Configuration Data . . . . . . . . . . . 11		4.2.4. Controlling Configuration Data . . . . . . . . . . . 11
	4.3. Block-wise Transfer . . . . . . . . . . . . . . . . . . . 11		4.3. Block-wise Transfer . . . . . . . . . . . . . . . . . . . 11
	4.4. DOTS Multi-homing Considerations . . . . . . . . . . . . 11		4.4. DOTS Multi-homing Considerations . . . . . . . . . . . . 11
	4.5. YANG Considerations . . . . . . . . . . . . . . . . . . . 12		4.5. YANG Considerations . . . . . . . . . . . . . . . . . . . 12
	4.6. A Note About Examples . . . . . . . . . . . . . . . . . . 13		4.6. A Note About Examples . . . . . . . . . . . . . . . . . . 13
	5. Telemetry Operation Paths . . . . . . . . . . . . . . . . . . 13		5. Telemetry Operation Paths . . . . . . . . . . . . . . . . . . 13
	6. DOTS Telemetry Setup Configuration . . . . . . . . . . . . . 14		6. DOTS Telemetry Setup Configuration . . . . . . . . . . . . . 14
	6.1. Telemetry Configuration . . . . . . . . . . . . . . . . . 15		6.1. Telemetry Configuration . . . . . . . . . . . . . . . . . 15
	6.1.1. Retrieve Current DOTS Telemetry Configuration . . . . 15		6.1.1. Retrieve Current DOTS Telemetry Configuration . . . . 15
	6.1.2. Convey DOTS Telemetry Configuration . . . . . . . . . 17		6.1.2. Conveying DOTS Telemetry Configuration . . . . . . . 17
	6.1.3. Retrieve Installed DOTS Telemetry Configuration . . . 20		6.1.3. Retrieve Installed DOTS Telemetry Configuration . . . 20
	6.1.4. Delete DOTS Telemetry Configuration . . . . . . . . . 21		6.1.4. Delete DOTS Telemetry Configuration . . . . . . . . . 21
	6.2. Total Pipe Capacity . . . . . . . . . . . . . . . . . . . 21		6.2. Total Pipe Capacity . . . . . . . . . . . . . . . . . . . 21
	6.2.1. Convey DOTS Client Domain Pipe Capacity . . . . . . . 22		6.2.1. Conveying DOTS Client Domain Pipe Capacity . . . . . 22
	6.2.2. Retrieve Installed DOTS Client Domain Pipe Capacity . 28		6.2.2. Retrieve Installed DOTS Client Domain Pipe Capacity . 28
	6.2.3. Delete Installed DOTS Client Domain Pipe Capacity . . 28		6.2.3. Delete Installed DOTS Client Domain Pipe Capacity . . 28
	6.3. Telemetry Baseline . . . . . . . . . . . . . . . . . . . 28		6.3. Telemetry Baseline . . . . . . . . . . . . . . . . . . . 28
	6.3.1. Convey DOTS Client Domain Baseline Information . . . 31		6.3.1. Conveying DOTS Client Domain Baseline Information . . 31
	6.3.2. Retrieve Installed Normal Traffic Baseline . . . . . 34		6.3.2. Retrieve Installed Normal Traffic Baseline . . . . . 35
	6.3.3. Delete Installed Normal Traffic Baseline . . . . . . 34		6.3.3. Delete Installed Normal Traffic Baseline . . . . . . 35
	6.4. Reset Installed Telemetry Setup . . . . . . . . . . . . . 34		6.4. Reset Installed Telemetry Setup . . . . . . . . . . . . . 35
	6.5. Conflict with Other DOTS Clients of the Same Domain . . . 34		6.5. Conflict with Other DOTS Clients of the Same Domain . . . 35
	7. DOTS Pre-or-Ongoing Mitigation Telemetry . . . . . . . . . . 35		7. DOTS Pre-or-Ongoing Mitigation Telemetry . . . . . . . . . . 36
	7.1. Pre-or-Ongoing-Mitigation DOTS Telemetry Attributes . . . 37		7.1. Pre-or-Ongoing-Mitigation DOTS Telemetry Attributes . . . 38
	7.1.1. Target . . . . . . . . . . . . . . . . . . . . . . . 38		7.1.1. Target . . . . . . . . . . . . . . . . . . . . . . . 39
	7.1.2. Total Traffic . . . . . . . . . . . . . . . . . . . . 39		7.1.2. Total Traffic . . . . . . . . . . . . . . . . . . . . 40
	7.1.3. Total Attack Traffic . . . . . . . . . . . . . . . . 41		7.1.3. Total Attack Traffic . . . . . . . . . . . . . . . . 42
	7.1.4. Total Attack Connections . . . . . . . . . . . . . . 43		7.1.4. Total Attack Connections . . . . . . . . . . . . . . 44
	7.1.5. Attack Details . . . . . . . . . . . . . . . . . . . 45		7.1.5. Attack Details . . . . . . . . . . . . . . . . . . . 46
	7.2. From DOTS Clients to DOTS Servers . . . . . . . . . . . . 52		7.2. From DOTS Clients to DOTS Servers . . . . . . . . . . . . 53
	7.3. From DOTS Servers to DOTS Clients . . . . . . . . . . . . 55		7.3. From DOTS Servers to DOTS Clients . . . . . . . . . . . . 56
	8. DOTS Telemetry Mitigation Status Update . . . . . . . . . . . 60		8. DOTS Telemetry Mitigation Status Update . . . . . . . . . . . 61
	8.1. DOTS Clients to Servers Mitigation Efficacy DOTS		8.1. DOTS Clients to Servers Mitigation Efficacy DOTS
	Telemetry Attributes . . . . . . . . . . . . . . . . . . 60		Telemetry Attributes . . . . . . . . . . . . . . . . . . 61
	8.2. DOTS Servers to Clients Mitigation Status DOTS Telemetry		8.2. DOTS Servers to Clients Mitigation Status DOTS Telemetry
	Attributes . . . . . . . . . . . . . . . . . . . . . . . 62		Attributes . . . . . . . . . . . . . . . . . . . . . . . 63
	9. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 66		9. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 67
	10. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 67		10. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 68
	10.1. DOTS Signal Channel Telemetry YANG Module . . . . . . . 67		10.1. DOTS Signal Channel Telemetry YANG Module . . . . . . . 68
	10.2. Vendor Attack Mapping Details YANG Module . . . . . . . 98		10.2. Vendor Attack Mapping Details YANG Module . . . . . . . 99
	11. YANG/JSON Mapping Parameters to CBOR . . . . . . . . . . . . 101		11. YANG/JSON Mapping Parameters to CBOR . . . . . . . . . . . . 102
	12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 104		12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 105
	12.1. DOTS Signal Channel CBOR Key Values . . . . . . . . . . 104		12.1. DOTS Signal Channel CBOR Key Values . . . . . . . . . . 105
	12.2. DOTS Signal Channel Conflict Cause Codes . . . . . . . . 106		12.2. DOTS Signal Channel Conflict Cause Codes . . . . . . . . 107
	12.3. DOTS Signal Telemetry YANG Module . . . . . . . . . . . 107		12.3. DOTS Signal Telemetry YANG Module . . . . . . . . . . . 108
	13. Security Considerations . . . . . . . . . . . . . . . . . . . 107		13. Security Considerations . . . . . . . . . . . . . . . . . . . 108
	13.1. DOTS Signal Channel Telemetry . . . . . . . . . . . . . 107		13.1. DOTS Signal Channel Telemetry . . . . . . . . . . . . . 108
	13.2. Vendor Attack Mapping . . . . . . . . . . . . . . . . . 108		13.2. Vendor Attack Mapping . . . . . . . . . . . . . . . . . 109
	14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 109		14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 110
	15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 109		15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 110
	16. References . . . . . . . . . . . . . . . . . . . . . . . . . 110		16. References . . . . . . . . . . . . . . . . . . . . . . . . . 111
	16.1. Normative References . . . . . . . . . . . . . . . . . . 110		16.1. Normative References . . . . . . . . . . . . . . . . . . 111
	16.2. Informative References . . . . . . . . . . . . . . . . . 112		16.2. Informative References . . . . . . . . . . . . . . . . . 112
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 113		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 114
	1. Introduction		1. Introduction
	Distributed Denial of Service (DDoS) attacks have become more		Distributed Denial of Service (DDoS) attacks have become more
	sophisticated. IT organizations and service providers are facing		sophisticated. IT organizations and service providers are facing
	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		taking down the actual delivered services, but rather to prevent
	eliminate various network elements (routers, switches, firewalls,		various network elements (routers, switches, firewalls, transit
	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 such as NTP (Network Time Protocol), DNS
	(Domain Name System), SNMP (Simple Network Management Protocol),		(Domain Name System), SNMP (Simple Network Management Protocol),
	or SSDP (Simple Service Discovery 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, therefore harder to detect and mitigate efficiently.		categorize, and therefore harder to detect and mitigate
			efficiently.
	To compound the problem, attackers also leverage multi-vectored		To compound the problem, attackers also leverage multi-vectored
	attacks. These attacks are assembled from dynamic attack vectors		attacks. These attacks are assembled from dynamic attack vectors
	(Network/Application) and tactics. As such, multiple attack vectors		(Network/Application) and tactics. As such, multiple attack vectors
	formed by multiple attack types and volumes are launched		formed by multiple attack types and volumes are launched
	simultaneously towards a victim. Multi-vector attacks are harder to		simultaneously towards a victim. Multi-vector attacks are harder to
	detect and defend. Multiple and simultaneous mitigation techniques		detect and defend against. Multiple and simultaneous mitigation
	are needed to defeat such attack campaigns. It is also common for		techniques are needed to defeat such attack campaigns. It is also
	attackers to change attack vectors right after a successful		common for attackers to change attack vectors right after a
	mitigation, burdening their opponents with changing their defense		successful mitigation, burdening their opponents with changing their
	methods.		defense methods.
	The conclusion derived from these real scenarios is that modern		The conclusion derived from these real scenarios is that modern
	attacks detection and mitigation are most certainly complicated and		attacks detection and mitigation are most certainly complicated and
	highly convoluted tasks. They demand a comprehensive knowledge of		highly convoluted tasks. They demand a comprehensive knowledge of
	the attack attributes, the targeted normal behavior (including,		the attack attributes, the normal behavior of the targeted systems
	normal traffic patterns), as well as the attacker's ongoing and past		(including normal traffic patterns), as well as the attacker's
	actions. Even more challenging, retrieving all the analytics needed		ongoing and past actions. Even more challenging, retrieving all the
	for detecting these attacks is not simple to obtain with the		analytics needed for detecting these attacks is not simple with the
	industry's current capabilities.		industry's current reporting capabilities.
	The DOTS signal channel protocol [I-D.ietf-dots-rfc8782-bis] is used		The DOTS signal channel protocol [RFC9132] is used to carry
	to carry information about a network resource or a network (or a part		information about a network resource or a network (or a part thereof)
	thereof) that is under a DDoS attack. Such information is sent by a		that is under a DDoS attack. Such information is sent by a DOTS
	DOTS client to one or multiple DOTS servers so that appropriate		client to one or multiple DOTS servers so that appropriate mitigation
	mitigation actions are undertaken on traffic deemed suspicious.		actions are undertaken on traffic deemed suspicious. Various use
	Various use cases are discussed in [I-D.ietf-dots-use-cases].		cases are discussed in [RFC8903].
	DOTS clients can be integrated within a DDoS attack detector, or		DOTS clients can be integrated within a DDoS attack detector, or
	network and security elements that have been actively engaged with		network and security elements that have been actively engaged with
	ongoing attacks. The DOTS client mitigation environment determines		ongoing attacks. The DOTS client mitigation environment determines
	that it is no longer possible or practical for it to handle these		that it is no longer possible or practical for it to handle these
	attacks. This can be due to a lack of resources or security		attacks itself. This can be due to a lack of resources or security
	capabilities, as derived from the complexities and the intensity of		capabilities, as derived from the complexities and the intensity of
	these attacks. In this circumstance, the DOTS client has invaluable		these attacks. In this circumstance, the DOTS client has invaluable
	knowledge about the actual attacks that need to be handled by its		knowledge about the actual attacks that need to be handled by its
	DOTS server(s). By enabling the DOTS client to share this		DOTS server(s). By enabling the DOTS client to share this
	comprehensive knowledge of an ongoing attack under specific		comprehensive knowledge of an ongoing attack under specific
	circumstances, the DOTS server can drastically increase its ability		circumstances, the DOTS server can drastically increase its ability
	to accomplish successful mitigation. While the attack is being		to accomplish successful mitigation. While the attack is being
	handled by the DOTS server associated mitigation resources, the DOTS		handled by the mitigation resources associated with the DOTS server,
	server has the knowledge about the ongoing attack mitigation. The		the DOTS server has knowledge about the ongoing attack mitigation.
	DOTS server can share this information with the DOTS client so that		The DOTS server can share this information with the DOTS client so
	the client can better assess and evaluate the actual mitigation		that the client can better assess and evaluate the actual mitigation
	realized.		realized.
	DOTS clients can send mitigation hints derived from attack details to		DOTS clients can send mitigation hints derived from attack details to
	DOTS servers, with the full understanding that the DOTS server may		DOTS servers, with the full understanding that the DOTS server may
	ignore mitigation hints, as described in [RFC8612] (Gen-004).		ignore mitigation hints, as described in [RFC8612] (Gen-004).
	Mitigation hints will be transmitted across the DOTS signal channel,		Mitigation hints will be transmitted across the DOTS signal channel,
	as the data channel may not be functional during an attack. How a		as the data channel may not be functional during an attack. How a
	DOTS server is handling normal and attack traffic attributes, and		DOTS server is handling normal and attack traffic attributes, and
	mitigation hints is implementation specific.		mitigation hints, is implementation specific.
	Both DOTS clients and servers can benefit 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 [I-D.ietf-dots-rfc8782-bis]. Nevertheless, when DOTS		protocol [RFC9132]. Nevertheless, when DOTS telemetry attributes are
	telemetry attributes are available to a DOTS agent, and absent any		available to a DOTS agent, and absent any limitation by policy, it
	policy, it can signal the attributes in order to optimize the overall		can signal the attributes in order to optimize the overall mitigation
	mitigation service provisioned using DOTS.		service provisioned using DOTS.
	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].
	"DOTS Telemetry" is defined as the collection of attributes that are		"DOTS Telemetry" is defined as the collection of attributes that are
	used to characterize normal traffic baseline, attacks and their		used to characterize the normal traffic baseline, attacks and their
	mitigation measures, and any related information that may help in		mitigation measures, and any related information that may help in
	enforcing countermeasures. The DOTS Telemetry is an optional set of		enforcing countermeasures. DOTS Telemetry is an optional set of
	attributes that can be signaled in the DOTS signal channel protocol.		attributes that can be signaled in the DOTS signal channel protocol.
	Telemetry Setup Identifier (tsid) is an identifier that is generated		Telemetry Setup Identifier (tsid) is an identifier that is generated
	by DOTS clients to uniquely identify DOTS telemetry setup		by DOTS clients to uniquely identify DOTS telemetry setup
	configuration data.		configuration data.
	Telemetry Identifier (tmid) is an identifier that is generated by		Telemetry Identifier (tmid) is an identifier that is generated by
	DOTS clients to uniquely identify DOTS telemetry data that is		DOTS clients to uniquely identify DOTS telemetry data that is
	communicated prior 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].
	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 an increased awareness		feedback between DOTS agents is required for increased awareness by
	of each party, supporting superior and highly efficient attack		each party of the attack and mitigation efforts, supporting a
	mitigation service.		superior and highly efficient attack mitigation service.
	3.1. Need More Visibility		3.1. Need More Visibility
	When signaling a mitigation request, it is most certainly beneficial		When signaling a mitigation request, it is most certainly beneficial
	for DOTS clients to signal to DOTS servers any knowledge regarding		for DOTS clients to signal to DOTS servers any knowledge regarding
	ongoing attacks. This can happen in cases where DOTS clients are		ongoing attacks. This can happen in cases where DOTS clients are
	asking DOTS servers for support in defending against attacks that		asking DOTS servers for support in defending against attacks that
	they have already detected and/or mitigated.		they have already detected and/or (partially) mitigated.
	If attacks are already detected and categorized within a DOTS client		If attacks are already detected and categorized within a DOTS client
	domain, the DOTS server, and its associated mitigation services, can		domain, the DOTS server, and its associated mitigation services, can
	proactively benefit this information and optimize the overall service		proactively benefit from this information and optimize the overall
	delivery. It is important to note that DOTS client domains and DOTS		service delivery. It is important to note that DOTS client domains'
	server domains detection and mitigation approaches can be different,		and DOTS server domains' detection and mitigation approaches can be
	and can potentially outcome different results and attack		different, and can potentially result in different results and attack
	classifications. The DDoS mitigation service treats the ongoing		classifications. The DDoS mitigation service treats the ongoing
	attack details received from DOTS clients as hints and cannot		attack details received from DOTS clients as hints and cannot
	completely rely or trust the attack details conveyed by DOTS clients.		completely rely or trust the attack details conveyed by DOTS clients.
	A basic requirement of security operation teams is to be aware and		In addition to the DOTS server directly using telemetry data as
	get visibility into the attacks they need to handle. The DOTS server		operational hints, the DOTS server security operation team also
	security operation teams benefit from the DOTS telemetry, especially		benefits from telemetry data. A basic requirement of security
	from the reports of ongoing attacks. Even if some mitigation can be		operation teams is to be aware of and get visibility into the attacks
	automated, operational teams can use the DOTS telemetry to be		they need to handle. This holds especially for the case of ongoing
	prepared for attack mitigation and to assign the correct resources		attacks, where DOTS telemetry provides data about the current attack
	(operation staff, networking and mitigation) for the specific		status. Even if some mitigation can be automated, operational teams
	service. Similarly, security operation personnel at the DOTS client		can use the DOTS telemetry information to be prepared for attack
	side ask for feedback about their requests for protection.		mitigation and to assign the correct resources (operation staff,
	Therefore, it is valuable for DOTS servers to share DOTS telemetry		networking and mitigation) for the specific service. Similarly,
	with DOTS clients.		security operations personnel at the DOTS client side ask for
			feedback about their requests for protection. Therefore, it is
			valuable for DOTS servers to share DOTS telemetry with DOTS clients.
	Mutual sharing of information is thus crucial for "closing the		Mutual sharing of information is thus crucial for "closing the
	mitigation loop" between DOTS clients and servers. For the server		mitigation loop" between DOTS clients and servers. For the server
	side team, it is important to realize that the same attacks that the		side team, it is important to confirm that the same attacks that the
	DOTS server's mitigation resources are seeing are those that a DOTS		DOTS server's mitigation resources are seeing are those that a DOTS
	client is asking to mitigate. For the DOTS client side team, it is		client is asking for mitigation of. For the DOTS client side team,
	important to realize that the DOTS clients receive the required		it is important to realize that the DOTS clients receive the required
	service. For example, understanding that "I asked for mitigation of		service. For example, understanding that "I asked for mitigation of
	two attacks and my DOTS server detects and mitigates only one of		two attacks and my DOTS server detects and mitigates only one of
	them". Cases of inconsistency in attack classification between DOTS		them". Cases of inconsistency in attack classification between DOTS
	clients and servers can be highlighted, and maybe handled, using the		clients and servers can be highlighted, and maybe handled, using the
	DOTS telemetry attributes.		DOTS telemetry attributes.
	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.
	skipping to change at page 7, line 44 ¶		skipping to change at page 7, line 47 ¶
	decisions and actions.		decisions and actions.
	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 to tune the DDoS mitigators with the
	correct state of an attack. During the last few years, DDoS attack		correct state of an attack. During the last few years, DDoS attack
	detection technologies have evolved from threshold-based detection		detection technologies have evolved from threshold-based detection
	(that is, cases when all or specific parts of traffic cross a		(that is, cases when all or specific parts of traffic cross a
	predefined threshold for a certain period of time is considered as an		predefined threshold for a certain period of time is considered as an
	attack) to an "anomaly detection" approach. For the latter, it is		attack) to an "anomaly detection" approach. For the latter, it is
	required to maintain rigorous learning of "normal" behavior and where		required to maintain rigorous learning of "normal" behavior, and an
	an "anomaly" (or an attack) is identified and categorized based on		"anomaly" (or an attack) is identified and categorized based on the
	the knowledge about the normal behavior and a deviation from this		knowledge about the normal behavior and a deviation from this normal
	normal behavior. Machine learning approaches are used such that the		behavior. Machine learning approaches are used such that the actual
	actual traffic thresholds are automatically calculated by learning		traffic thresholds are automatically calculated by learning the
	the protected entity normal traffic behavior during idle time. The		protected entity's normal traffic behavior during idle time. The
	normal traffic characterization learned is referred to as the "normal		normal traffic characterization learned is referred to as the "normal
	traffic baseline". An attack is detected when the victim's actual		traffic baseline". An attack is detected when the victim's actual
	traffic is deviating from this normal baseline.		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
	normality" needs to be achieved during the various mitigation		normality" that needs to be achieved during the various mitigation
	process.		process.
	Normal baseline calculation is performed based on continuous learning		Normal baseline calculation is performed based on continuous learning
	of the normal behavior of the protected entities. The minimum		of the normal behavior of the protected entities. The minimum
	learning period varies from hours to days and even weeks, depending		learning period varies from hours to days and even weeks, depending
	on the protected application behavior. The baseline cannot be		on the protected application behavior. The baseline cannot be
	learned during active attacks because attack conditions do not		learned during active attacks because attack conditions do not
	characterize the protected entities' normal behavior.		characterize the protected entities' normal behavior.
	If the DOTS client has calculated the normal baseline of its		If the DOTS client has calculated the normal baseline of its
	protected entities, signaling such information to the DOTS server		protected entities, signaling such information to the DOTS server
	along with the attack traffic levels is significantly valuable. The		along with the attack traffic levels provides value. The DOTS server
	DOTS server benefits from this telemetry by tuning its mitigation		benefits from this telemetry by tuning its mitigation resources with
	resources with the DOTS client's normal baseline. The DOTS server		the DOTS client's normal baseline. The DOTS server mitigators use
	mitigators use the baseline to familiarize themselves with the attack		the baseline to familiarize themselves with the attack victim's
	victim's normal behavior and target the baseline as the level of		normal behavior and target the baseline as the level of normality
	normality they need to achieve. Fed with this information, the		they need to achieve. Fed with this information, the overall
	overall mitigation performances is expected to be improved in terms		mitigation performances is expected to be improved in terms of time
	of time to mitigate, accuracy, false-negative, and false-positive.		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 in [I-D.ietf-dots-use-cases]).		recursive signaling (see Section 3.2.3 of [RFC8903]). In addition,
	In addition, the highly diverse types of use cases where DOTS clients		the highly diverse types of use cases where DOTS clients are
	are integrated also emphasize the need for knowledge of each DOTS		integrated also emphasize the need for knowledge of each DOTS client
	client domain behavior. Consequently, common global thresholds for		domain behavior. Consequently, common global thresholds for attack
	attack detection practically cannot be realized. Each DOTS client		detection practically cannot be realized. Each DOTS client domain
	domain can have its own levels of traffic and normal behavior.		can have its own levels of traffic and normal behavior. Without
	Without facilitating normal baseline signaling, it may be very		facilitating normal baseline signaling, it may be very difficult for
	difficult for DOTS servers in some cases to detect and mitigate the		DOTS servers in some cases to detect and mitigate the attacks
	attacks accurately:		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		Of course, this information can provided using out-of-band mechanisms
	mechanisms or manual configuration at the risk to maintain		or manual configuration at the risk of unmaintained information
	inaccurate information as the network evolves and "normal"		becoming inaccurate as the network evolves and "normal" patterns
	patterns change. The use of a dynamic and collaborative means		change. The use of a dynamic and collaborative means between the
	between the DOTS client and server to identify and share key		DOTS client and server to identify and share key parameters for the
	parameters for the sake of efficient DDoS protection is valuable.		sake of efficient DDoS protection is valuable.
	3.3. Efficient Mitigation		3.3. Efficient Mitigation
	During a high volume attack, DOTS client pipes can be totally		During a high volume attack, DOTS client pipes can be totally
	saturated. DOTS clients ask their DOTS servers to handle the attack		saturated. DOTS clients ask their DOTS servers to handle the attack
	upstream so that DOTS client pipes return to a reasonable load level		upstream so that DOTS client pipes return to a reasonable load level
	(normal pattern, ideally). At this point, it is essential to ensure		(normal pattern, ideally). At this point, it is essential to ensure
	that the mitigator does not overwhelm the DOTS client pipes by		that the mitigator does not overwhelm the DOTS client pipes by
	sending back "clean traffic", or what it believes is "clean". This		sending back large volumes of "clean traffic", or what it believes is
	can happen when the mitigator has not managed to detect and mitigate		"clean". This can happen when the mitigator has not managed to
	all the attacks launched towards the DOTS client domain.		detect and mitigate all the attacks launched towards the DOTS client
			domain.
	In this case, it can be valuable to DOTS clients to signal to DOTS		In this case, it can be valuable to DOTS clients to signal to DOTS
	servers the "total pipe capacity", which is the level of traffic the		servers the total pipe capacity, which is the level of traffic the
	DOTS client domain can absorb from its upstream network. Dynamic		DOTS client domain can absorb from its upstream network. Dynamic
	updates of the condition of pipes between DOTS agents while they are		updates of the condition of pipes between DOTS agents while they are
	under a DDoS attack is essential (e.g., where multiple DOTS clients		under a DDoS attack is essential (e.g., where multiple DOTS clients
	share the same physical connectivity pipes). It is important to note		share the same physical connectivity pipes). It is important to note
	that the term "pipe" noted here does not necessary represent physical		that the term "pipe" noted here does not necessary represent physical
	pipe, but rather represents the maximum level of traffic that the		pipe, but rather represents the maximum level of traffic that the
	DOTS client domain can receive. The DOTS server should activate		DOTS client domain can receive. The DOTS server should activate
	other mechanisms to ensure it does not allow the DOTS client domain's		other mechanisms to ensure it does not allow the DOTS client domain's
	pipes to be saturated unintentionally. The rate-limit action defined		pipes to be saturated unintentionally. The rate-limit action defined
	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 ask for 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		be controlled via the signal channel [RFC9133] even when the pipe is
	[I-D.ietf-dots-signal-filter-control] 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
	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		use of the DOTS signal channel are specified in [RFC9132].
	[I-D.ietf-dots-rfc8782-bis].
	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		interface, 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 to receive telemetry notifications related		client that is interested in receiving telemetry notifications
	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.
	Aggregate DOTS telemetry data can also be included in efficacy update		Aggregate DOTS telemetry data can also be included in efficacy update
	(Section 8.1) or mitigation update (Section 8.2) messages.		(Section 8.1) or mitigation update (Section 8.2) messages.
	4.2. Generic Considerations		4.2. Generic Considerations
	4.2.1. DOTS Client Identification		4.2.1. DOTS Client Identification
	Following the rules in Section 4.4.1 of [I-D.ietf-dots-rfc8782-bis],		Following the rules in Section 4.4.1 of [RFC9132], a unique
	a unique identifier is generated by a DOTS client to prevent request		identifier is generated by a DOTS client to prevent request
	collisions ('cuid').		collisions ('cuid').
	As a reminder, [I-D.ietf-dots-rfc8782-bis] forbids 'cuid' to be		As a reminder, [RFC9132] forbids 'cuid' to be returned in a response
	returned in a response message body.		message body.
	4.2.2. DOTS Gateways		4.2.2. DOTS Gateways
	DOTS gateways may be located between DOTS clients and servers. The		DOTS gateways may be located between DOTS clients and servers. The
	considerations elaborated in Section 4.4.1 of		considerations elaborated in Section 4.4.1 of [RFC9132] must be
	[I-D.ietf-dots-rfc8782-bis] must be followed. In particular, 'cdid'		followed. In particular, 'cdid' attribute is used to unambiguously
	attribute is used to unambiguously identify a DOTS client domain.		identify a DOTS client domain.
	As a reminder, [I-D.ietf-dots-rfc8782-bis] forbids 'cdid' (if		As a reminder, Section 4.4.1.3 of [RFC9132] forbids 'cdid' (if
	present) to be returned in a response message body.		present) to be returned in a response message body.
	4.2.3. Empty URI Paths		4.2.3. Empty URI Paths
	Uri-Path parameters and attributes with empty values MUST NOT be		Uri-Path parameters and attributes with empty values MUST NOT be
	present in a request and render an entire message invalid.		present in a request. The presence of such an empty value renders
			the entire containing message invalid.
	4.2.4. Controlling Configuration Data		4.2.4. Controlling Configuration Data
	The DOTS server follows the same considerations discussed in		The DOTS server follows the same considerations discussed in
	Section of 4.5.3 of [I-D.ietf-dots-rfc8782-bis] for managing DOTS		Section of 4.5.3 of [RFC9132] for managing DOTS telemetry
	telemetry configuration freshness and notification.		configuration freshness and notification.
	Likewise, a DOTS client may control the selection of configuration		Likewise, a DOTS client may control the selection of configuration
	and non-configuration data nodes when sending a GET request by means		and non-configuration data nodes when sending a GET request by means
	of the 'c' Uri-Query option and following the procedure specified in		of the 'c' Uri-Query option and following the procedure specified in
	Section of 4.4.2 of [I-D.ietf-dots-rfc8782-bis]. These		Section of 4.4.2 of [RFC9132]. These considerations are not
	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		recommendation detailed in Section 4.4.2 of [RFC9132] to control the
	[I-D.ietf-dots-rfc8782-bis] to control the size of a response when		size of a response when the data to be returned does not fit within a
	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 (see
	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 will fail if the inbound "pipe" is running full, so
	consideration needs to be made to try to fit this PUT into a single		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		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.		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
	Multi-homed DOTS clients are assumed to follow the recommendations in		Multi-homed DOTS clients are assumed to follow the recommendations in
	[I-D.ietf-dots-multihoming] to select which DOTS server to contact		[I-D.ietf-dots-multihoming] to select which DOTS server to contact
	and which IP prefixes to include in a telemetry message to a given		and which IP prefixes to include in a telemetry message to a given
	peer DOTS server. For example, if each upstream network exposes a		peer DOTS server. For example, if each upstream network exposes a
	DOTS server and the DOTS client maintains DOTS channels with all of		DOTS server and the DOTS client maintains DOTS channels with all of
	them, only the information related to prefixes assigned by an		them, only the information related to prefixes assigned by an
	upstream network to the DOTS client domain will be signaled via the		upstream network to the DOTS client domain will be signaled via the
	skipping to change at page 12, line 14 ¶		skipping to change at page 12, line 16 ¶
	Considerations related to whether (and how) a DOTS client gleans some		Considerations related to whether (and how) a DOTS client gleans some
	telemetry information (e.g., attack details) it receives from a first		telemetry information (e.g., attack details) it receives from a first
	DOTS server and share it with a second DOTS server are implementation		DOTS server and share it with a second DOTS server are implementation
	and deployment specific.		and deployment specific.
	4.5. YANG Considerations		4.5. YANG Considerations
	Telemetry messages exchanged between DOTS agents are serialized using		Telemetry messages exchanged between DOTS agents are serialized using
	Concise Binary Object Representation (CBOR) [RFC8949]. CBOR-encoded		Concise Binary Object Representation (CBOR) [RFC8949]. CBOR-encoded
	payloads are used to carry signal channel specific payload messages		payloads are used to carry signal-channel-specific payload messages
	which convey request parameters and response information such as		which convey request parameters and response information such as
	errors.		errors.
	This document specifies a YANG module [RFC7950] for representing DOTS		This document specifies a YANG module [RFC7950] for representing DOTS
	telemetry message types (Section 10.1). All parameters in the		telemetry message types (Section 10.1). All parameters in the
	payload of the DOTS signal channel are mapped to CBOR types as		payload of the DOTS signal channel are mapped to CBOR types as
	specified in Section 11. As a reminder, Section 3 of		specified in Section 11. As a reminder, Section 3 of [RFC9132]
	[I-D.ietf-dots-rfc8782-bis] defines the rules for mapping YANG-		defines the rules for mapping YANG-modeled data to CBOR.
	modeled data to CBOR.
	The DOTS telemetry module (Section 10.1) is not intended to be used		The DOTS telemetry module (Section 10.1) is not intended to be used
	via NETCONF/RESTCONF for DOTS server management purposes. It serves		via NETCONF/RESTCONF for DOTS server management purposes. It serves
	only to provide a data model and encoding following [RFC8791].		only to provide a data model and encoding following [RFC8791].
	Server deviations are strongly discouraged as the peer DOTS agent		Server deviations are strongly discouraged, as the peer DOTS agent
	does not have means to retrieve the list of deviations and that		does not have means to retrieve the list of deviations and thus
	interoperability issues are likely to be encountered.		interoperability issues are likely to be encountered.
	The DOTS telemetry module (Section 10.1) uses "enumerations" rather		The DOTS telemetry module (Section 10.1) uses "enumerations" rather
	than "identities" to define units, samples, and intervals because		than "identities" to define units, samples, and intervals because
	otherwise the namespace identifier "ietf-dots-telemetry" must be		otherwise the namespace identifier "ietf-dots-telemetry" must be
	included when a telemetry attribute is included (e.g., in a		included when a telemetry attribute is included (e.g., in a
	mitigation efficacy update). The use of "identities" is thus		mitigation efficacy update). The use of "identities" is thus
	suboptimal from a message compactness standpoint; one of the key		suboptimal from a message compactness standpoint; one of the key
	requirements for DOTS 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.
	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 mapping
	details (Section 7.1.5). DOTS clients can use tools, e.g., YANG		details (Section 7.1.5). DOTS clients can use tools, e.g., YANG
	Library [RFC8525], to retrieve the list of features and deviations		Library [RFC8525], to retrieve the list of features and deviations
	supported by the DOTS server.		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).
	5. Telemetry Operation Paths		5. Telemetry Operation Paths
	As discussed in Section 4.2 of [I-D.ietf-dots-rfc8782-bis], each DOTS		As discussed in Section 4.2 of [RFC9132], each DOTS operation is
	operation is indicated by a path suffix that indicates the intended		indicated by a path suffix that indicates the intended operation.
	operation. The operation path is appended to the path prefix to form		The operation path is appended to the path prefix to form the URI
	the URI used with a CoAP request to perform the desired DOTS		used with a CoAP request to perform the desired DOTS operation. The
	operation. The following telemetry path suffixes are defined		following telemetry path suffixes are defined (Table 1):
	(Table 1):
	+-----------------+----------------+-----------+		+-----------------+----------------+-----------+
	| Operation | Operation Path | Details |		| Operation | Operation Path | Details |
	+=================+================+===========+		+=================+================+===========+
	| Telemetry Setup | /tm-setup | Section 6 |		| Telemetry Setup | /tm-setup | Section 6 |
	| Telemetry | /tm | Section 7 |		| Telemetry | /tm | Section 7 |
	+-----------------+----------------+-----------+		+-----------------+----------------+-----------+
	Table 1: DOTS Telemetry Operations		Table 1: DOTS Telemetry Operations
	skipping to change at page 14, line 29 ¶		skipping to change at page 14, line 29 ¶
	...		...
	Figure 1: New DOTS Message Types (YANG Tree Structure)		Figure 1: New DOTS Message Types (YANG Tree Structure)
	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, or 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).
	A DOTS client can reset all installed DOTS telemetry setup		A DOTS client can reset all installed DOTS telemetry setup
	configuration data following the considerations detailed in		configuration data following the considerations detailed in
	Section 6.4.		Section 6.4.
	A DOTS server may detect conflicts when processing requests related		A DOTS server may detect conflicts when processing requests related
	to DOTS client domain pipe capacity or telemetry traffic baseline		to DOTS client domain pipe capacity or telemetry traffic baseline
	with requests from other DOTS clients of the same DOTS client domain.		with requests from other DOTS clients of the same DOTS client domain.
	More details are included in Section 6.5.		More details are included in Section 6.5.
	skipping to change at page 15, line 29 ¶		skipping to change at page 15, line 29 ¶
	o Acceptable Server-originated telemetry		o Acceptable Server-originated telemetry
	Section 11.3 of [RFC2330] includes more details about computing		Section 11.3 of [RFC2330] includes more details about computing
	percentiles.		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 request is depicted in Figure 2.		gateway. An example of such a GET request (without gateway) is
			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 request, and assuming no error is encountered by		Upon receipt of such a request, and assuming no error is encountered
	processing the request, the DOTS server replies with a 2.05 (Content)		when processing the request, the DOTS server replies with a 2.05
	response that conveys the current and telemetry parameters acceptable		(Content) response that conveys the current and telemetry parameters
	by the DOTS server. The tree structure of the response message body		acceptable by the DOTS server. The tree structure of the response
	is provided in Figure 3. Note that the response also includes any		message body is provided in Figure 3. Note that the response also
	pipe (Section 6.2) and baseline information (Section 6.3) maintained		includes any pipe (Section 6.2) and baseline information
	by the DOTS server for this DOTS client.		(Section 6.3) maintained by the DOTS server for this DOTS client.
	DOTS servers that support the capability of sending telemetry		DOTS servers that support the capability of sending telemetry
	information to DOTS clients prior 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 request 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:
	+-- (telemetry-message-type)?		+-- (telemetry-message-type)?
	+--:(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
	skipping to change at page 16, line 51 ¶		skipping to change at page 17, line 4 ¶
	| | +-- 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? uint32
	| +--:(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. Convey DOTS Telemetry Configuration		6.1.2. Conveying DOTS Telemetry Configuration
	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
	example, a DOTS client may contact its DOTS server to change the		example, a DOTS client may contact its DOTS server to change the
	default percentile values used as baseline for telemetry data.		default percentile values used as baseline for telemetry data.
	Figure 3 lists the attributes that can be set by a DOTS client in		Figure 3 lists the attributes that can be set by a DOTS client in
	such PUT request. An example of a DOTS client that modifies all		such a PUT request. An example of a DOTS client that modifies all
	percentile reference values is shown in Figure 4.		percentile reference values is shown in Figure 4.
	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=123"		Uri-Path: "tsid=123"
	Content-Format: "application/dots+cbor"		Content-Format: "application/dots+cbor"
	skipping to change at page 18, line 12 ¶		skipping to change at page 18, line 14 ¶
	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
	telemetry).		telemetry).
	The procedure specified in Section 4.4.1 of		The procedure specified in Section 4.4.1 of [RFC9132] for 'mid'
	[I-D.ietf-dots-rfc8782-bis] MUST be followed for 'tsid'		rollover MUST also be followed for 'tsid' rollover.
	rollover.
	This is a mandatory attribute. 'tsid' MUST follow 'cuid'.		This is a mandatory attribute. 'tsid' MUST follow 'cuid'.
	'cuid' and 'tsid' MUST NOT appear in the PUT request message body.		'cuid' and 'tsid' MUST NOT appear in the PUT request message body.
	At least one configurable attribute MUST be present in the PUT		At least one configurable attribute MUST be present in the PUT
	request.		request.
	The 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		o If the request is missing a mandatory attribute, does not include
	skipping to change at page 22, line 34 ¶		skipping to change at page 22, line 34 ¶
	...		...
	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 '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.
	6.2.1. Convey 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
	numeric 'tsid' value will override the request with a lower		numeric 'tsid' value will override the request with a lower
	numeric 'tsid' value. The overlapped lower numeric 'tsid' MUST be		numeric 'tsid' value. The overlapped lower numeric 'tsid' MUST be
	automatically deleted and no longer be available.		automatically deleted and no longer be available.
	DOTS clients SHOULD minimize the number of active 'tsids' 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
	'tsids' 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		o Note: This assumes that all link information can fit in one single
	message.		message.
	For example, a DOTS client managing a single homed domain (Figure 10)		As an example of configuring pipe information, a DOTS client managing
	can send a PUT request (shown in Figure 11) to communicate the		a single homed domain (Figure 10) can send a PUT request (shown in
	capacity of "link1" used to connect to its ISP.		Figure 11) to communicate the capacity of "link1" used to connect to
			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)
	skipping to change at page 24, line 48 ¶		skipping to change at page 24, line 48 ¶
	]		]
	}		}
	]		]
	}		}
	}		}
	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
	link#2).		link#2).
	,--,--,--.		,--,--,--.
	,-' `-.		,-' `-.
	skipping to change at page 28, line 29 ¶		skipping to change at page 28, line 29 ¶
	6.3. Telemetry Baseline		6.3. Telemetry Baseline
	A DOTS client can communicate to its DOTS server(s) its normal		A DOTS client can communicate to its DOTS server(s) its normal
	traffic baseline and connections capacity:		traffic baseline and connections capacity:
	Total traffic normal baseline: The percentile values representing		Total traffic normal baseline: The percentile values representing
	the total traffic normal baseline. It can be represented for a		the total traffic normal baseline. It can be represented for a
	target using 'total-traffic-normal'.		target using 'total-traffic-normal'.
	The traffic normal per protocol ('total-traffic-normal-per-		The traffic normal per-protocol ('total-traffic-normal-per-
	protocol') baseline is represented for a target and is transport-		protocol') baseline is represented for a target and is transport-
	protocol specific.		protocol specific.
	The traffic normal per port number ('total-traffic-normal-per-		The traffic normal per-port-number ('total-traffic-normal-per-
	port') baseline is represented for each port number bound to a		port') baseline is represented for each port number bound to a
	target.		target.
	If the DOTS client negotiated percentile values and units		If the DOTS client negotiated percentile values and units
	(Section 6.1), these negotiated parameters will be used instead of		(Section 6.1), these negotiated parameters will be used instead of
	the default ones. For each used unit class, the DOTS client MUST		the default ones. For each used unit class, the DOTS client MUST
	auto-scale so that the appropriate unit is used.		auto-scale so that the appropriate unit is used.
	Total connections capacity: If the target is subjected to resource		Total connections capacity: If the target is susceptible to
	consuming DDoS attacks, the following optional attributes for the		resource-consuming DDoS attacks, the following optional attributes
	target per transport protocol are useful to detect resource		for the target per transport protocol are useful to detect
	consuming DDoS attacks:		resource-consuming DDoS attacks:
	* The maximum number of simultaneous connections that are allowed		* The maximum number of simultaneous connections that are allowed
	to the target.		to the target.
	* The maximum number of simultaneous connections that are allowed		* The maximum number of simultaneous connections that are allowed
	to the target per client.		to the target per client.
	* The maximum number of simultaneous embryonic connections that		* The maximum number of simultaneous embryonic connections that
	are allowed to the target. The term "embryonic connection"		are allowed to the target. The term "embryonic connection"
	refers to a connection whose connection handshake is not		refers to a connection whose connection handshake is not
	finished. Embryonic connection is only possible in connection-		finished. Embryonic connection is only possible in connection-
	oriented transport protocols like TCP or SCTP.		oriented transport protocols like TCP or Stream Control
			Transmission Protocol (SCTP) [RFC4960].
	* 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.
	skipping to change at page 29, line 35 ¶		skipping to change at page 29, line 36 ¶
	* The maximum number of partial requests allowed per second to		* The maximum number of partial requests allowed per second 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 partial requests allowed per second 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
			'target-prefix', 'target-port-range', 'target-protocol', 'target-
			fqdn', 'target-uri', or 'alias-name' defined in Section 4.4.1.1 of
			[RFC9132].
	The tree structure of the normal traffic baseline is shown in		The tree structure of the normal traffic baseline is shown in
	Figure 18.		Figure 18.
	structure dots-telemetry:		structure dots-telemetry:
	+-- (telemetry-message-type)?		+-- (telemetry-message-type)?
	+--:(telemetry-setup)		+--:(telemetry-setup)
	| ...		| ...
	| +-- telemetry* []		| +-- telemetry* []
	| +-- (direction)?		| +-- (direction)?
	| | +--:(server-to-client-only)		| | +--:(server-to-client-only)
	skipping to change at page 31, line 26 ¶		skipping to change at page 31, line 32 ¶
	| +-- 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-ps? uint64
	| +-- partial-request-client-ps? uint64		| +-- partial-request-client-ps? uint64
	+--:(telemetry)		+--:(telemetry)
	...		...
	Figure 18: Telemetry Baseline Tree Structure		Figure 18: Telemetry Baseline Tree Structure
	6.3.1. Convey 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 if the
	addresses associated with the FQDN, URI, or alias are overlapping		addresses associated with the FQDN, URI, or alias are overlapping
	with each other or with 'target-prefix'.		with each other or with 'target-prefix'.
	DOTS clients SHOULD minimize the number of active 'tsids' 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
	'tsids' 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.
	If no target attribute is included in the request, this is an		If no target attribute is included in the request, this is an
	indication that the baseline information applies for the DOTS client		indication that the baseline information applies for the DOTS client
	domain as a whole.		domain as a whole.
	skipping to change at page 32, line 46 ¶		skipping to change at page 33, line 37 ¶
	"peak-g": "60"		"peak-g": "60"
	}		}
	]		]
	}		}
	]		]
	}		}
	]		]
	}		}
	}		}
	Figure 19: PUT to Convey the DOTS Traffic Baseline		Figure 19: PUT to Conveying the DOTS Traffic Baseline
	The DOTS client may share protocol specific baseline information		The DOTS client may share protocol specific baseline information
	(e.g., TCP and UDP) as shown in Figure 19.		(e.g., TCP and UDP) as shown in Figure 19.
	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=128"		Uri-Path: "tsid=128"
	skipping to change at page 34, line 38 ¶		skipping to change at page 35, line 38 ¶
	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
	6.5. Conflict with Other DOTS Clients of the Same Domain		6.5. Conflict with Other DOTS Clients of the Same Domain
	A DOTS server may detect conflicts between requests to convey pipe		A DOTS server may detect conflicts between requests conveying pipe
	and baseline information received from DOTS clients of the same DOTS		and baseline information received from DOTS clients of the same DOTS
	client domain. 'conflict-information' is used to report the conflict		client domain. 'conflict-information' is used to report the conflict
	to the DOTS client following similar conflict handling discussed in		to the DOTS client following similar conflict handling discussed in
	Section 4.4.1 of [I-D.ietf-dots-rfc8782-bis]. The conflict cause can		Section 4.4.1 of [RFC9132]. The conflict cause can be set to one of
	be set to one of these values:		these values:
	1: Overlapping targets (Section 4.4.1 of		1: Overlapping targets (Section 4.4.1 of [RFC9132]).
	[I-D.ietf-dots-rfc8782-bis]).
	TBA: Overlapping pipe scope (see Section 12).		TBA: Overlapping pipe scope (see Section 12).
	7. DOTS Pre-or-Ongoing Mitigation Telemetry		7. DOTS Pre-or-Ongoing Mitigation Telemetry
	There are two broad types of DDoS attacks, one is bandwidth consuming		There are two broad types of DDoS attacks: one is a bandwidth
	attack, the other is target resource consuming attack. This section		consuming attack, the other is a target-resource-consuming attack.
	outlines the set of DOTS telemetry attributes (Section 7.1) that		This section outlines the set of DOTS telemetry attributes
	covers both the types of attacks. The objective of these attributes		(Section 7.1) that covers both types of attack. The objective of
	is to allow for the complete knowledge of attacks and the various		these attributes is to allow for the complete knowledge of attacks
	particulars that can best characterize attacks.		and the various particulars that can best characterize attacks.
	The "ietf-dots-telemetry" YANG module (Section 10.1) defines the data		The "ietf-dots-telemetry" YANG module (Section 10.1) defines the data
	structure of a new message type called 'telemetry'. The tree		structure of a new message type called 'telemetry'. The tree
	structure of the 'telemetry' message type is shown in Figure 24.		structure of the 'telemetry' message type is shown in Figure 24.
	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 with		DOTS agents SHOULD bind pre-or-ongoing-mitigation telemetry data to
	mitigation requests relying upon the target attribute. In		mitigation requests relying upon the target attribute. 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 requests 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		When generating telemetry data to send to a peer, the DOTS agent MUST
	auto-scale so that appropriate unit(s) are used.		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.,
	skipping to change at page 39, line 9 ¶		skipping to change at page 40, line 9 ¶
	| ...		| ...
	+-- 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 subjected to bandwidth consuming attack, 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 subjected to resource consuming DDoS attacks, the		If the target is susceptible to resource-consuming DDoS attacks, the
	same attributes defined for 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.		This is an optional attribute.
	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 total traffic
	observed during a DDoS attack. More granular total traffic can be		observed during a DDoS attack. More fine-grained information about
	conveyed in 'total-traffic-protocol' and 'total-traffic-port'.		the total traffic can be conveyed in the 'total-traffic-protocol' and
			'total-traffic-port' attributes.
	The 'total-traffic-protocol' represents the total traffic for a		The 'total-traffic-protocol' attribute represents the total traffic
	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)?
	| +--:(server-to-client-only)		| +--:(server-to-client-only)
	| +-- tmid? uint32		| +-- tmid? uint32
	+-- target		+-- target
	skipping to change at page 41, line 9 ¶		skipping to change at page 42, line 9 ¶
	| ...		| ...
	+-- 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		attack traffic identified by the DOTS client domain's DDoS Mitigation
	System (or DDoS Detector). More granular total traffic can be		System (or DDoS Detector). More fine-grained information about the
	conveyed in 'total-attack-traffic-protocol' and 'total-attack-		total attack traffic can be conveyed in the 'total-attack-traffic-
	traffic-port'.		protocol' and 'total-attack-traffic-port' attributes.
	The 'total-attack-traffic-protocol' represents the total attack		The 'total-attack-traffic-protocol' attribute represents the total
	traffic for a target and is transport-protocol specific.		attack traffic for a target and is transport-protocol specific.
	The 'total-attack-traffic-port' represents the total attack traffic		The 'total-attack-traffic-port' attribute represents the total attack
	for a target per port number.		traffic for a target per port number.
	+--:(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
	| ...		| ...
	+-- total-traffic* [unit]		+-- total-traffic* [unit]
	| ...		| ...
	+-- 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]
	| +-- protocol? uint8
	| +-- 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-traffic-protocol* [unit protocol]		+-- total-attack-traffic-protocol* [unit protocol]
	| +-- protocol uint8		| +-- protocol uint8
	| +-- unit unit		| +-- unit unit
	| +-- low-percentile-g? yang:gauge64		| +-- low-percentile-g? yang:gauge64
	skipping to change at page 43, line 7 ¶		skipping to change at page 44, line 7 ¶
	| ...		| ...
	+-- total-attack-connection-port		+-- total-attack-connection-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 subjected to resource consuming DDoS attack, 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' attribute is used to convey the percentile
	values (including peak and current observed values) of total attack		values (including peak and current observed values) of total attack
	connections. The following optional subattributes for the target per		connections. The following optional subattributes for the target per
	transport protocol are included to represent the attack		transport protocol are included to represent the attack
	characteristics:		characteristics:
	o The number of simultaneous attack connections to the target.		o The number of simultaneous attack connections to the target.
	o The number of simultaneous embryonic connections to the target.		o The number of simultaneous embryonic connections to the target.
	o The number of attack connections per second to the target.		o The number of attack connections per second to the target.
	o The number of attack requests to the target.		o The number of attack requests to the target.
	The total attack connections per port number is represented using		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
	| ...		| ...
	+-- total-traffic* [unit]		+-- total-traffic* [unit]
	skipping to change at page 45, line 28 ¶		skipping to change at page 46, line 28 ¶
	| +-- connection-ps? yang:gauge64		| +-- connection-ps? yang:gauge64
	| +-- request-ps? yang:gauge64		| +-- request-ps? yang:gauge64
	| +-- partial-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 (Figure 29) is used to signal a set of details		This attribute (depicted in Figure 29) is used to signal a set of
	characterizing an attack. The following subattributes describing the		details characterizing an attack. The following subattributes
	ongoing attack can be signal 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.
	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) can possibly be used to map the attack description to		embedding) might provide some utility in mapping the attack
	an attack type. Textual representation of attack solves two		description to an attack type. Textual representation of attack
	problems: (a) avoids the need to create mapping tables manually		solves two problems: (a) avoids the need to create mapping tables
	between vendors and (b) avoids the need to standardize attack		manually between vendors and (b) avoids the need to standardize
	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 in UTC time
	(Section 3.4.2 of [RFC8949]). The CBOR encoding is modified so		(Section 3.4.2 of [RFC8949]). The CBOR encoding is modified so
	that the leading tag 1 (epoch-based date/time) MUST be omitted.		that the leading 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
	skipping to change at page 46, line 21 ¶		skipping to change at page 47, line 21 ¶
	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 top talkers among attack sources. The top
	talkers are represented using the 'source-prefix'.		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 the target is subjected to a bandwidth consuming attack, the		If the target is being subjected to a bandwidth-consuming attack,
	attack traffic from each of the top talkers is included ('total-		a statistical profile of the attack traffic from each of the top
	attack-traffic', Section 7.1.3).		talkers is included ('total-attack-traffic', Section 7.1.3).
	If the target is subjected to a resource consuming DDoS attack,		If the target is being subjected to a resource-consuming DDoS
	the same attributes defined in Section 7.1.4 are applicable for		attack, the same attributes defined in Section 7.1.4 are
	representing the attack per talker.		applicable for characterizing the attack on a per-talker basis.
	+--:(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
	| ...		| ...
	+-- total-traffic* [unit]		+-- total-traffic* [unit]
	| ...		| ...
	skipping to change at page 48, line 50 ¶		skipping to change at page 49, line 50 ¶
	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 the vendor mapping(s) that it provided to
	the DOTS server and the DOTS server SHOULD use the vendor mappings(s)		the DOTS server and the DOTS server SHOULD use the vendor mappings(s)
	provided to the DOTS client when transmitting telemetry data to peer		provided to the DOTS client when transmitting telemetry data to the
	DOTS agent.		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]. The tree structure of the		the "ietf-dots-data-channel" [RFC8783] module. The tree structure of
	"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
	+--rw vendor-name? string		+--rw vendor-name? string
	+--rw last-updated uint64		+--rw last-updated uint64
	+--rw attack-mapping* [attack-id]		+--rw attack-mapping* [attack-id]
	+--rw attack-id uint32		+--rw attack-id uint32
	skipping to change at page 49, line 51 ¶		skipping to change at page 50, line 51 ¶
	details. An example of such GET request is shown in Figure 31.		details. An example of such 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 MAY 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 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
	skipping to change at page 52, line 22 ¶		skipping to change at page 53, line 22 ¶
	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 'attack-description'		7.2, 7.3, and 8), DOTS agents MUST NOT include the 'attack-
	attribute except if the corresponding attack mapping details were not		description' attribute unless the corresponding attack mapping
	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 uses PUT request 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 request is shown in		telemetry to DOTS servers. An example of such a request is shown in
	Figure 36.		Figure 36.
	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=123"		Uri-Path: "tmid=123"
	Content-Format: "application/dots+cbor"		Content-Format: "application/dots+cbor"
	skipping to change at page 53, line 44 ¶		skipping to change at page 54, line 44 ¶
	"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 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).
	The procedure specified in Section 4.4.1 of		The procedure specified in Section 4.4.1 of [RFC9132] for 'mid'
	[I-D.ietf-dots-rfc8782-bis] MUST be followed for 'tmid'		rollover MUST be followed for 'tmid' rollover.
	rollover.
	This is a mandatory attribute. 'tmid' MUST follow 'cuid'.		This is a mandatory attribute. 'tmid' MUST follow 'cuid'.
	'cuid' and 'tmid' MUST NOT appear in the PUT request message body.		'cuid' and 'tmid' MUST NOT appear in the PUT request message body.
	At least 'target' attribute and another pre-or-ongoing-mitigation		At least the 'target' attribute and another pre-or-ongoing-mitigation
	attributes (Section 7.1) MUST be present in the PUT request. If only		attribute (Section 7.1) MUST be present in the PUT request. If only
	the 'target' attribute is present, this request is handled as per		the 'target' attribute is present, this request is handled as per
	Section 7.3.		Section 7.3.
	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 two such requests have an
	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.
	The DOTS server indicates the result of processing a PUT request		The DOTS server indicates the result of processing a PUT request
	using CoAP Response Codes. In particular, the 2.04 (Changed)		using CoAP Response Codes. In particular, the 2.04 (Changed)
	Response Code is returned if the DOTS server has accepted the pre-or-		Response Code is returned if the DOTS server has accepted the pre-or-
	ongoing-mitigation telemetry. The 5.03 (Service Unavailable)		ongoing-mitigation telemetry. The 5.03 (Service Unavailable)
	Response Code is returned if the DOTS server has erred. 5.03 uses		Response Code is returned if the DOTS server has erred. 5.03 uses the
	Max-Age Option to indicate the number of seconds after which to		Max-Age Option to indicate the number of seconds after which to
	retry.		retry.
	How long a DOTS server maintains a 'tmid' as active or logs the		How long a DOTS server maintains a 'tmid' as active or logs the
	enclosed telemetry information is implementation specific. Note that		enclosed telemetry information is implementation specific. Note that
	if a 'tmid' is still active, then logging details are updated by the		if a 'tmid' is still active, then logging details are updated by the
	DOTS server as a function of the updates received from the peer DOTS		DOTS server as a function of the updates received from the peer DOTS
	client.		client.
	A DOTS client that lost the state of its active 'tmids' or has to set		A DOTS client that lost the state of its active 'tmid's or has to set
	'tmid' back to zero (e.g., crash or restart) MUST send a GET request		'tmid' back to zero (e.g., crash or restart) MUST send a GET request
	to the DOTS server to retrieve the list of active 'tmid'. The DOTS		to the DOTS server to retrieve the list of active 'tmid' values. The
	client may then delete 'tmids' that should not be active anymore		DOTS client may then delete 'tmid's that should not be active anymore
	(Figure 37). Sending a DELETE with no 'tmid' indicates that all		(Figure 37). Sending a DELETE with no 'tmid' indicates that all
	'tmids' must be deactivated (Figure 38).		'tmid's must be deactivated (Figure 38).
	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"		Uri-Path: "tm"
	Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"		Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
	Uri-Path: "tmid=123"		Uri-Path: "tmid=123"
	Figure 37: Delete a Pre-or-Ongoing-Mitigation Telemetry		Figure 37: Delete a Pre-or-Ongoing-Mitigation Telemetry
	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"		Uri-Path: "tm"
	Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"		Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
	Figure 38: Delete All Pre-or-Ongoing-Mitigation Telemetry		Figure 38: Delete All Pre-or-Ongoing-Mitigation Telemetry
	7.3. From DOTS Servers to DOTS Clients		7.3. From DOTS Servers to DOTS Clients
	The pre-or-ongoing-mitigation (attack details, in particular) can		The pre-or-ongoing-mitigation data (attack details, in particular)
	also be signaled from DOTS servers to DOTS clients. For example, the		can also be signaled from DOTS servers to DOTS clients. For example,
	DOTS server co-located with a DDoS detector collects monitoring		a DOTS server co-located with a DDoS detector can collect monitoring
	information from the target network, identifies DDoS attack using		information from the target network, identify a DDoS attack using
	statistical analysis or deep learning techniques, and signals the		statistical analysis or deep learning techniques, and signal the
	attack details to the DOTS client.		attack details to the DOTS client.
	The DOTS client can use the attack details to decide whether to		The DOTS client can use the attack details to decide whether to
	trigger a DOTS mitigation request or not. Furthermore, the security		trigger a DOTS mitigation request or not. Furthermore, the security
	operation 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 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. DOTS servers may be instructed to restrict the
	number of pre-or-ongoing-mitigation requests per DOTS client domain.		number of pre-or-ongoing-mitigation requests per DOTS client domain.
	This request MUST be maintained active by the DOTS server until a		This request MUST be maintained in an active state by the DOTS server
	delete request is received from the same DOTS client to clear this		until a delete request is received from the same DOTS client to clear
	pre-or-ongoing-mitigation telemetry.		this pre-or-ongoing-mitigation telemetry.
	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.
	skipping to change at page 56, line 33 ¶		skipping to change at page 57, line 33 ¶
	]		]
	}		}
	}		}
	]		]
	}		}
	}		}
	Figure 39: PUT to Request Pre-or-Ongoing-Mitigation Telemetry		Figure 39: PUT to Request Pre-or-Ongoing-Mitigation Telemetry
	DOTS clients of the same domain can request to receive pre-or-		DOTS clients of the same domain can request to receive pre-or-
	ongoing-mitigation telemetry bound to the same target.		ongoing-mitigation telemetry bound to the same target without being
			considered to be "overlapping" and in conflict.
	The DOTS client conveys the Observe Option set to '0' in the GET		Once the PUT request to instantiate request state on the server has
	request to receive asynchronous notifications carrying pre-or-		succeeded, the DOTS client issues a GET request to receive ongoing
	ongoing-mitigation telemetry data from the DOTS server. The GET		telemtry updates. The client uses the Observe Option, set to '0'
	request specifies a 'tmid' (Figure 40) or not (Figure 41).		(register), in the GET request to receive asynchronous notifications
			carrying pre-or-ongoing-mitigation telemetry data from the DOTS
			server. The GET request can specify a specific 'tmid' (Figure 40) or
			omit the 'tmid' (Figure 41) to receive updates on all active requests
			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 Notifications
	skipping to change at page 57, line 15 ¶		skipping to change at page 58, line 26 ¶
	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 Notifications
	for All 'tmids'		for All 'tmids'
	The DOTS client can filter out the asynchronous notifications from		The DOTS client can use a filter to request a subset of the
	the DOTS server by indicating one or more Uri-Query options in its		asynchronous notifications from the DOTS server by indicating one or
	GET request. A Uri-Query option can include the following		more Uri-Query options in its GET request. A Uri-Query option can
	parameters: 'target-prefix', 'target-port', 'target-protocol',		include the following parameters to restrict the notifications based
	'target-fqdn', 'target-uri', 'alias-name', 'mid', and 'c' (content)		on the attack target: 'target-prefix', 'target-port', 'target-
	(Section 4.2.4). Furthermore:		protocol', 'target-fqdn', 'target-uri', 'alias-name', 'mid', and 'c'
			(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.
	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., contiguous inclusive block) can be included		Range values (i.e., a contiguous inclusive block) can be included
	for 'target-port', 'target-protocol', and 'mid' parameters by		for the 'target-port', 'target-protocol', and 'mid' parameters by
	indicating two bound 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 "*"
	character) can be included in 'target-fqdn' or 'target-uri'		character) can be included in 'target-fqdn' or 'target-uri'
	parameters. DOTS clients MUST NOT include a name in which the "*"		parameters. DOTS clients MUST NOT include a name in which the "*"
	character is included in a label other than the leftmost label.		character is included in a label other than the leftmost label.
	"*.example.com" is an example of a valid wildcard name that can be		"*.example.com" is an example of a valid wildcard name that can be
	included as a value of the 'target-fqdn' parameter in an Uri-Query		included as a value of the 'target-fqdn' parameter in an Uri-Query
	option.		option.
	DOTS clients may also filter out the asynchronous notifications from		DOTS clients may also filter out the asynchronous notifications from
	the DOTS server by indicating a specific source information. To that		the DOTS server by indicating information about a specific attack
	aim, a DOTS client may include 'source-prefix', 'source-port', or		source. To that aim, a DOTS client may include 'source-prefix',
	'source-icmp-type' in a Uri-Query option. The same considerations		'source-port', or 'source-icmp-type' in a Uri-Query option. The same
	(ranges, multiple values) specified for target attributes apply for		considerations (ranges, multiple values) specified for target
	source attributes. Special care SHOULD be taken when using these		attributes apply for source attributes. Special care SHOULD be taken
	filters as some attacks may be hidden to the requesting DOTS client		when using these filters as their use may cause some attacks may be
	(e.g., the attack changes its source information).		hidden to the requesting DOTS client (e.g., if the attack changes its
			source information).
	Requests with invalid query types (e.g., not supported, malformed) by		Requests with invalid query types (e.g., not supported, malformed)
	the DOTS server MUST be rejected by DOTS servers with a 4.00 (Bad		received by the DOTS server MUST be rejected with a 4.00 (Bad
	Request).		Request) response code.
	An example of request to subscribe to asynchronous UDP telemetry		An example of a request to subscribe to asynchronous telemetry
	notifications is shown in Figure 42. This filter will be applied for		notifications regarding UDP traffic is shown in Figure 42. This
	all 'tmids'.		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 [I-D.ietf-dots-rfc8782-bis].		considerations as in Section 4.4.2.1 of [RFC9132]. An example of a
	An example of a pre-or-ongoing-mitigation telemetry notification is		pre-or-ongoing-mitigation telemetry notification is shown in
	shown in Figure 43.		Figure 43.
	{		{
	"ietf-dots-telemetry:telemetry": {		"ietf-dots-telemetry:telemetry": {
	"pre-or-ongoing-mitigation": [		"pre-or-ongoing-mitigation": [
	{		{
	"tmid": 567,		"tmid": 567,
	"target": {		"target": {
	"target-prefix": [		"target-prefix": [
	"2001:db8::1/128"		"2001:db8::1/128"
	]		]
	skipping to change at page 59, line 43 ¶		skipping to change at page 60, line 43 ¶
	]		]
	}		}
	}		}
	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
	granular data when needed (that is, 'total-attack-traffic-protocol'		fine-grained data when needed (that is, 'total-attack-traffic-
	and 'total-attack-traffic-port'). If a port filter (or protocol		protocol' and 'total-attack-traffic-port'). If a port filter (or
	filter) is included in a request, 'total-attack-traffic-protocol' (or		protocol filter) is included in a request, 'total-attack-traffic-
	'total-attack-traffic-port') conveys the data with the port (or		protocol' (or 'total-attack-traffic-port') conveys the data with the
	protocol) filter applied.		port (or protocol) filter applied.
	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.
	skipping to change at page 60, line 21 ¶		skipping to change at page 61, line 21 ¶
	mitigation telemetry data for a target MUST send a delete request		mitigation telemetry data for a target MUST send a delete request
	similar to the one depicted in Figure 37.		similar 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		efficacy updates to the server (Section 4.4.3 of [RFC9132]).
	[I-D.ietf-dots-rfc8782-bis]).
	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 client perspective during an active mitigation. See		DOTS 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 "ietf-dots-signal"		'mitigation-scope' message type defined in the "ietf-dots-signal"
	[I-D.ietf-dots-rfc8782-bis] so that these attributes can be signalled		module [RFC9132] so that these attributes can be signalled by a DOTS
	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]
	| +-- 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
	skipping to change at page 62, line 42 ¶		skipping to change at page 63, line 42 ¶
	}		}
	Figure 45: An Example of Mitigation Efficacy Update with Telemetry		Figure 45: An Example of Mitigation Efficacy Update with Telemetry
	Attributes		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.2 of [I-D.ietf-dots-rfc8782-bis]). In		status update (Section 4.4.2 of [RFC9132]). In particular, DOTS
	particular, DOTS clients can receive asynchronous notifications of		clients can receive asynchronous notifications of the attack details
	the attack details from DOTS servers using the Observe option defined		from DOTS servers using the Observe option defined in [RFC7641].
	in [RFC7641].
	In order to make use of this feature, DOTS clients MUST establish a		In order to make use of this feature, DOTS clients MUST establish a
	telemetry setup session with the DOTS server in 'idle' time and MUST		telemetry session with the DOTS server in 'idle' time and MUST set
	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 which 'server-originated-		status updates sent to DOTS clients for telemetry sessions in which
	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 each countermeasure 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"
	[I-D.ietf-dots-rfc8782-bis] with telemetry data as depicted in the		[RFC9132] with telemetry data as depicted in the following tree
	following tree structure:		structure:
	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:
	+-- (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
	skipping to change at page 65, line 8 ¶		skipping to change at page 66, line 5 ¶
	+-- high-percentile-c		+-- high-percentile-c
	| ...		| ...
	+-- peak-c		+-- peak-c
	| ...		| ...
	+-- current-c		+-- current-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 percentile value 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": [
	{		{
	"mid": 12332,		"mid": 12332,
	"mitigation-start": "1507818434",		"mitigation-start": "1507818434",
	"alias-name": [		"alias-name": [
	"https1",		"https1",
	"https2"		"https2"
	skipping to change at page 66, line 7 ¶		skipping to change at page 67, line 5 ¶
	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 name ('target-fqdn', 'target-uri').		wildcard names ('target-fqdn', 'target-uri').
	An example of request to subscribe to asynchronous notifications		An example of request to subscribe to asynchronous notifications
	bound to the "http1" alias is shown in Figure 47.		bound to the "http1" alias is shown in Figure 47.
	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"
	skipping to change at page 66, line 32 ¶		skipping to change at page 67, line 30 ¶
	using Uri-Query		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.
	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 [I-D.ietf-dots-rfc8782-bis]. The following		provided in Section 9 of [RFC9132]. The following additional error
	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		o 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		o 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		o 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
	skipping to change at page 67, line 11 ¶		skipping to change at page 68, line 11 ¶
	o 4.04 (Not Found) is returned by the DOTS server when the DOTS		o 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].
	Note to the RFC Editor: Please replace "RFC UUUU" with the RFC
	number to be assigned to [I-D.ietf-dots-rfc8782-bis].
	<CODE BEGINS> file "ietf-dots-telemetry@2020-12-07.yang"		<CODE BEGINS> file "ietf-dots-telemetry@2020-12-07.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 {		import ietf-dots-signal-channel {
	prefix dots-signal;		prefix dots-signal;
	reference		reference
	"RFC UUUU: Distributed Denial-of-Service Open Threat Signaling		"RFC 9132: Distributed Denial-of-Service Open Threat Signaling
	(DOTS) Signal Channel Specification";		(DOTS) Signal Channel Specification";
	}		}
	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";
	}		}
	import ietf-yang-types {		import ietf-yang-types {
	prefix yang;		prefix yang;
	skipping to change at page 68, line 4 ¶		skipping to change at page 68, line 50 ¶
	prefix nt;		prefix nt;
	reference		reference
	"Section 6.2 of RFC 8345: A YANG Data Model for Network		"Section 6.2 of RFC 8345: A YANG Data Model for Network
	Topologies";		Topologies";
	}		}
	import ietf-yang-structure-ext {		import ietf-yang-structure-ext {
	prefix sx;		prefix sx;
	reference		reference
	"RFC 8791: YANG Data Structure Extensions";		"RFC 8791: YANG Data Structure Extensions";
	}		}
	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: 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 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) 2020 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
	skipping to change at page 71, line 46 ¶		skipping to change at page 72, line 45 ¶
	"Peta packets per second (Ppps).";		"Peta packets per second (Ppps).";
	}		}
	enum petabit-ps {		enum petabit-ps {
	value 17;		value 17;
	description		description
	"Petabits per second (Pbps).";		"Petabits per second (Pbps).";
	}		}
	enum petabyte-ps {		enum petabyte-ps {
	value 18;		value 18;
	description		description
	"Exabytes per second (PBps).";		"Petabytes per second (PBps).";
	}		}
	enum exapacket-ps {		enum exapacket-ps {
	value 19;		value 19;
	description		description
	"Exa packets per second (Epps).";		"Exa packets per second (Epps).";
	}		}
	enum exabit-ps {		enum exabit-ps {
	value 20;		value 20;
	description		description
	"Exabits per second (Ebps).";		"Exabits per second (Ebps).";
	}		}
	enum exabyte-ps {		enum exabyte-ps {
	value 21;		value 21;
	description		description
	"Exabytes per second (EBps).";		"Exabytes per second (EBps).";
	skipping to change at page 73, line 36 ¶		skipping to change at page 74, line 36 ¶
	}		}
	description		description
	"Enumeration to indicate the overall measurement period.";		"Enumeration to indicate the overall measurement period.";
	}		}
	typedef sample {		typedef sample {
	type enumeration {		type enumeration {
	enum second {		enum second {
	value 1;		value 1;
	description		description
	"A one second measurement period.";		"A one-second measurement period.";
	}		}
	enum 5-seconds {		enum 5-seconds {
	value 2;		value 2;
	description		description
	"5 seconds measurement period.";		"5-second measurement period.";
	}		}
	enum 30-seconds {		enum 30-seconds {
	value 3;		value 3;
	description		description
	"30 seconds measurement period.";		"30-second measurement period.";
	}		}
	enum minute {		enum minute {
	value 4;		value 4;
	description		description
	"One minute measurement period.";		"One-minute measurement period.";
	}		}
	enum 5-minutes {		enum 5-minutes {
	value 5;		value 5;
	description		description
	"5 minutes measurement period.";		"5-minute measurement period.";
	}		}
	enum 10-minutes {		enum 10-minutes {
	value 6;		value 6;
	description		description
	"10 minutes measurement period.";		"10-minute measurement period.";
	}		}
	enum 30-minutes {		enum 30-minutes {
	value 7;		value 7;
	description		description
	"30 minutes measurement period.";		"30-minute measurement period.";
	}		}
	enum hour {		enum hour {
	value 8;		value 8;
	description		description
	"One hour measurement period.";		"One-hour measurement period.";
	}		}
	}		}
	description		description
	"Enumeration to indicate the sampling period.";		"Enumeration to indicate the sampling period.";
	}		}
	typedef percentile {		typedef percentile {
	type decimal64 {		type decimal64 {
	fraction-digits 2;		fraction-digits 2;
	}		}
	skipping to change at page 76, line 4 ¶		skipping to change at page 76, line 51 ¶
	}		}
	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		description
	"Enumeration support for query types that can be used		"Enumeration of support for query types that can be used
	in a GET request to filter out data. Requests with		in a GET request to filter out data. Requests with
	invalid query types (e.g., not supported, malformed)		invalid query types (e.g., not supported, malformed)
	by the DOTS server are rejected by DOTS servers with		received by the DOTS server are rejected with
	a 4.00 (Bad Request).";		a 4.00 (Bad Request) response code.";
	}		}
	grouping telemetry-parameters {		grouping telemetry-parameters {
	description		description
	"A grouping that includes a set of parameters that		"A grouping that includes a set of parameters that
	are used to compute telemetry data.		are used to prepare the reported telemetry data.
	The grouping indicates a measurement interval,		The grouping indicates a measurement interval,
	a measurement sample period, and low/mid/high		a measurement sample period, and low/mid/high
	percentile values.";		percentile values.";
	leaf measurement-interval {		leaf measurement-interval {
	type interval;		type interval;
	description		description
	"Defines the period on which percentiles are computed.";		"Defines the period on which percentiles are computed.";
	}		}
	leaf measurement-sample {		leaf measurement-sample {
	skipping to change at page 76, line 52 ¶		skipping to change at page 77, line 50 ¶
	}		}
	leaf mid-percentile {		leaf mid-percentile {
	type percentile;		type percentile;
	must '. >= ../low-percentile' {		must '. >= ../low-percentile' {
	error-message		error-message
	"The mid-percentile must be greater than		"The mid-percentile must be greater than
	or equal to the low-percentile.";		or equal to the low-percentile.";
	}		}
	default "50.00";		default "50.00";
	description		description
	"Mid percentile. If set to the same value as low-percentiles,		"Mid percentile. If set to the same value as low-percentile,
	this means mid-percentiles are disabled.";		this means mid-percentiles are disabled.";
	}		}
	leaf high-percentile {		leaf high-percentile {
	type percentile;		type percentile;
	must '. >= ../mid-percentile' {		must '. >= ../mid-percentile' {
	error-message		error-message
	"The high-percentile must be greater than		"The high-percentile must be greater than
	or equal to the mid-percentile.";		or equal to the mid-percentile.";
	}		}
	default "90.00";		default "90.00";
	description		description
	"High percentile. If set to the same value as mid-percentiles,		"High percentile. If set to the same value as mid-percentile,
	this means high-percentiles are disabled.";		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
	skipping to change at page 79, line 4 ¶		skipping to change at page 79, line 52 ¶
	}		}
	grouping traffic-unit-protocol {		grouping traffic-unit-protocol {
	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.";		a function of the measurement unit.";
	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/>.
	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
	including current values.";		a function of the measurement unit, including current values.";
	uses traffic-unit-protocol;		uses traffic-unit-protocol;
	leaf current-g {		leaf current-g {
	type yang:gauge64;		type yang:gauge64;
	description		description
	"Current observed value.";		"Current observed value.";
	}		}
	}		}
	grouping traffic-unit-port {		grouping traffic-unit-port {
	description		description
	skipping to change at page 80, line 4 ¶		skipping to change at page 80, line 52 ¶
	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 connections capacity. These data nodes are		"Total connection capacities for various types of
	useful to detect resource consuming DDoS attacks.";		connections, as well as overall capacity. These data nodes are
			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 handshake
	is not finished. Embryonic connection is only possible in		is not finished. Embryonic connections are only possible in
	connection-oriented transport protocols like TCP or SCTP.";		connection-oriented transport protocols like TCP or SCTP.";
	}		}
	leaf embryonic-client {		leaf embryonic-client {
	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 per client.";		that are allowed to the target server per client.";
	}		}
	leaf connection-ps {		leaf connection-ps {
	type uint64;		type uint64;
	description		description
	"The maximum number of connections allowed per second		"The maximum number of new connections allowed per second
	to the target server.";		to the target server.";
	}		}
	leaf connection-client-ps {		leaf connection-client-ps {
	type uint64;		type uint64;
	description		description
	"The maximum number of connections allowed per second		"The maximum number of new connections allowed per second
	to the target server per client.";		to the target server per client.";
	}		}
	leaf request-ps {		leaf request-ps {
	type uint64;		type uint64;
	description		description
	"The maximum number of requests allowed per second		"The maximum number of requests allowed per second
	to the target server.";		to the target server.";
	}		}
	leaf request-client-ps {		leaf request-client-ps {
	type uint64;		type uint64;
	skipping to change at page 85, line 49 ¶		skipping to change at page 86, line 49 ¶
	}		}
	leaf attack-id {		leaf attack-id {
	type uint32;		type uint32;
	description		description
	"Unique identifier assigned by the vendor for the attack.";		"Unique identifier assigned by the vendor for the attack.";
	}		}
	leaf attack-description {		leaf attack-description {
	type string;		type string;
	description		description
	"Textual representation of attack description. Natural Language		"Textual representation of attack description. Natural Language
	Processing techniques (e.g., word embedding) can possibly be		Processing techniques (e.g., word embedding) might provide some
	used to map the attack description to an attack type.";		utility in mapping the attack description to an attack type.";
	}		}
	leaf attack-severity {		leaf attack-severity {
	type attack-severity;		type attack-severity;
	description		description
	"Severity level of an attack. How this level is determined		"Severity level of an attack. How this level is determined
	is implementation-specific.";		is implementation-specific.";
	}		}
	leaf start-time {		leaf start-time {
	type uint64;		type uint64;
	description		description
	skipping to change at page 91, line 14 ¶		skipping to change at page 92, line 14 ¶
	list total-traffic-port {		list total-traffic-port {
	key "unit port";		key "unit port";
	description		description
	"Total traffic per port number.";		"Total traffic per port number.";
	uses traffic-unit-port-all;		uses traffic-unit-port-all;
	}		}
	list total-attack-traffic {		list total-attack-traffic {
	key "unit";		key "unit";
	description		description
	"Total attack traffic.";		"Total attack traffic.";
	uses traffic-unit-protocol-all;		uses traffic-unit-all;
	}		}
	list total-attack-traffic-protocol {		list total-attack-traffic-protocol {
	key "unit protocol";		key "unit protocol";
	description		description
	"Total attack traffic per protocol.";		"Total attack traffic per protocol.";
	uses traffic-unit-protocol-all;		uses traffic-unit-protocol-all;
	}		}
	list total-attack-traffic-port {		list total-attack-traffic-port {
	key "unit port";		key "unit port";
	description		description
	"Total attack traffic per port number.";		"Total attack traffic per port number.";
	uses traffic-unit-port-all;		uses traffic-unit-port-all;
	}		}
	container total-attack-connection {		container total-attack-connection {
	description		description
	"Total attack connections.";		"Total attack connections.";
	uses connection-protocol-all;		uses connection-protocol-all;
	}		}
	container total-attack-connection-port {		container total-attack-connection-port {
	description		description
	"Total attack connections.";		"Total attack connections per target port number.";
	uses connection-protocol-port-all;		uses connection-protocol-port-all;
	}		}
	list attack-detail {		list attack-detail {
	key "vendor-id attack-id";		key "vendor-id attack-id";
	description		description
	"Provides a set of attack details.";		"Provides a set of attack details.";
	uses attack-detail;		uses attack-detail;
	container top-talker {		container top-talker {
	description		description
	"Lists the top attack sources.";		"Lists the top attack sources.";
	skipping to change at page 93, line 8 ¶		skipping to change at page 94, line 8 ¶
	}		}
	}		}
	sx:structure dots-telemetry {		sx:structure dots-telemetry {
	description		description
	"Main structure for DOTS telemetry messages.";		"Main structure for DOTS telemetry messages.";
	choice telemetry-message-type {		choice telemetry-message-type {
	description		description
	"Can be a telemetry-setup or telemetry data.";		"Can be a telemetry-setup or telemetry data.";
	case telemetry-setup {		case telemetry-setup {
	description		description
	"Indicates the message is about telemetry.";		"Indicates the message is about telemetry steup.";
	choice direction {		choice direction {
	description		description
	"Indicates the communication direction in which the		"Indicates the communication direction in which the
	data nodes can be included.";		data nodes can be included.";
	case server-to-client-only {		case server-to-client-only {
	description		description
	"These data nodes appear only in a mitigation message		"These data nodes appear only in a mitigation message
	sent from the server to the client.";		sent from the server to the client.";
	container max-config-values {		container max-config-values {
	description		description
	skipping to change at page 94, line 27 ¶		skipping to change at page 95, line 27 ¶
	status.";		status.";
	uses unit-config;		uses unit-config;
	}		}
	leaf-list query-type {		leaf-list query-type {
	type query-type;		type query-type;
	description		description
	"Indicates which query types are supported by		"Indicates which query types are supported by
	the server. If the server does not announce		the server. If the server does not announce
	the query types it supports, the client will		the query types it supports, the client will
	be unable to use any of the potential		be unable to use any of the potential
	query-type to reduce the returned data		query-type values to reduce the returned data
	content from the server.";		content from the server.";
	}		}
	}		}
	}		}
	list telemetry {		list telemetry {
	description		description
	"The telemetry data per DOTS client. The keys		"The telemetry data per DOTS client. The keys
	of the list are 'cuid' and 'tsid', but these keys are not		of the list are 'cuid' and 'tsid', but these keys are not
	represented here because these keys are conveyed as		represented here because these keys are conveyed as
	mandatory Uri-Paths in requests. Omitting keys		mandatory Uri-Paths in requests. Omitting keys
	skipping to change at page 94, line 50 ¶		skipping to change at page 95, line 50 ¶
	description		description
	"Indicates the communication direction in which the		"Indicates the communication direction in which the
	data nodes can be included.";		data nodes can be included.";
	case server-to-client-only {		case server-to-client-only {
	description		description
	"These data nodes appear only in a mitigation message		"These data nodes appear only in a mitigation message
	sent from the server to the client.";		sent from the server to the client.";
	leaf tsid {		leaf tsid {
	type uint32;		type uint32;
	description		description
	"An identifier for the DOTS telemetry setup		"A client-assigned identifier for the DOTS telemetry
	data.";		setup data.";
	}		}
	}		}
	}		}
	choice setup-type {		choice setup-type {
	description		description
	"Can be a mitigation configuration, a pipe capacity,		"Can be a mitigation configuration, a pipe capacity,
	or baseline message.";		or baseline message.";
	case telemetry-config {		case telemetry-config {
	description		description
	skipping to change at page 95, line 25 ¶		skipping to change at page 96, line 25 ¶
	low, mid, and high percentile values.";		low, mid, and high percentile values.";
	container current-config {		container current-config {
	description		description
	"Current telemetry configuration values.";		"Current telemetry configuration values.";
	uses telemetry-parameters;		uses telemetry-parameters;
	uses unit-config;		uses unit-config;
	leaf server-originated-telemetry {		leaf server-originated-telemetry {
	type boolean;		type boolean;
	description		description
	"Used by a DOTS client to enable/disable whether it		"Used by a DOTS client to enable/disable whether it
	accepts pre-or-ongoing-mitigation telemetry from		requests pre-or-ongoing-mitigation telemetry from
	the DOTS server.";		the DOTS server.";
	}		}
	leaf telemetry-notify-interval {		leaf telemetry-notify-interval {
	type uint32 {		type uint32 {
	range "1 .. 3600";		range "1 .. 3600";
	}		}
	units "seconds";		units "seconds";
	description		description
	"Minimum number of seconds between successive		"Minimum number of seconds between successive
	telemetry notifications.";		telemetry notifications.";
	skipping to change at page 96, line 14 ¶		skipping to change at page 97, line 14 ¶
	type uint64;		type uint64;
	mandatory true;		mandatory true;
	description		description
	"Pipe capacity. This attribute is mandatory when		"Pipe capacity. This attribute is mandatory when
	total-pipe-capacity is included in a message.";		total-pipe-capacity is included in a message.";
	}		}
	leaf unit {		leaf unit {
	type unit;		type unit;
	description		description
	"The traffic can be measured using unit classes:		"The traffic can be measured using unit classes:
	packets per second (pps), Bits per Second (bit/s),		packets per second (pps), bits per second (bit/s),
	and/or bytes per second (Byte/s).		and/or bytes per second (Byte/s).
	For a given type, the DOTS agents auto-scale		For a given unit class, the DOTS agents auto-scales
	to the appropriate units (e.g., megabit-ps,		to the appropriate units (e.g., megabit-ps,
	kilobit-ps).";		kilobit-ps).";
	}		}
	}		}
	}		}
	case baseline {		case baseline {
	description		description
	"Traffic baseline information of a DOTS client domain.";		"Traffic baseline information of a DOTS client domain.";
	list baseline {		list baseline {
	key "id";		key "id";
	skipping to change at page 96, line 46 ¶		skipping to change at page 97, line 46 ¶
	entry communicated by a DOTS client.";		entry communicated by a DOTS client.";
	}		}
	uses baseline;		uses baseline;
	}		}
	}		}
	}		}
	}		}
	}		}
	case telemetry {		case telemetry {
	description		description
	"Indicates the message is about telemetry.";		"Telemetry information.";
	list pre-or-ongoing-mitigation {		list pre-or-ongoing-mitigation {
	description		description
	"Pre-or-ongoing-mitigation telemetry per DOTS client.		"Pre-or-ongoing-mitigation telemetry per DOTS client.
	The keys of the list are 'cuid' and 'tmid', but these		The keys of the list are 'cuid' and 'tmid', but these
	keys are not represented here because these keys are		keys are not represented here because these keys are
	conveyed as mandatory Uri-Paths in requests.		conveyed as mandatory Uri-Paths in requests.
	Omitting keys is compliant with RFC8791.";		Omitting keys is compliant with RFC8791.";
	choice direction {		choice direction {
	description		description
	"Indicates the communication direction in which the		"Indicates the communication direction in which the
	skipping to change at page 98, line 35 ¶		skipping to change at page 99, line 35 ¶
	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) 2020 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
	skipping to change at page 99, line 37 ¶		skipping to change at page 100, line 37 ¶
	leaf vendor-name {		leaf vendor-name {
	type string;		type string;
	description		description
	"The name of the vendor (e.g., company A).";		"The name of the vendor (e.g., company A).";
	}		}
	leaf last-updated {		leaf last-updated {
	type uint64;		type uint64;
	mandatory true;		mandatory true;
	description		description
	"The time the mapping table was updated. It is represented		"The time the mapping table was updated. It is represented
	in seconds relative to 1970-01-01T00:00:00Z in UTC time.";		in seconds relative to 1970-01-01T00:00:00Z in UTC time.";
	}		}
	list attack-mapping {		list attack-mapping {
	key "attack-id";		key "attack-id";
	description		description
	"Attack mapping details.";		"Attack mapping details.";
	leaf attack-id {		leaf attack-id {
	type uint32;		type uint32;
	description		description
	"Unique identifier assigned by the vendor for the attack.";		"Unique identifier assigned by the vendor for the attack.";
	}		}
	leaf attack-description {		leaf attack-description {
	type string;		type string;
	mandatory true;		mandatory true;
	description		description
	"Textual representation of attack description. Natural		"Textual representation of attack description. Natural
	Language Processing techniques (e.g., word embedding)		Language Processing techniques (e.g., word embedding)
	can possibly be used to map the attack description to		might provide some utility in mapping the attack
	an attack type.";		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		description
	"Augments the data channel with a vendor attack		"Augments the data channel with a vendor attack
	mapping table of the DOTS client.";		mapping table of the DOTS client.";
	skipping to change at page 103, line 43 ¶		skipping to change at page 104, line 43 ¶
	| 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-l | list |TBA85 | 4 array | Array |
	| current-c | container |TBA86 | 5 map | Object |		| current-c | container |TBA86 | 5 map | Object |
	| lower-type | uint8 |TBA87 | 0 unsigned | Number |		| lower-type | uint8 |32771 | 0 unsigned | Number |
	| upper-type | uint8 |TBA88 | 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		o Note to the RFC Editor: CBOR keys are assigned from the "128-255"
	range.		range. This specification meets the requirements listed in
			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 | 5 | 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] |
	skipping to change at page 105, line 26 ¶		skipping to change at page 106, line 27 ¶
	| 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] |		| low-percentile-c | TBA45 | 5 | IESG | [RFCXXXX] |
	| mid-percentile-c | TBA46 | 5 | IESG | [RFCXXXX] |		| mid-percentile-c | TBA46 | 5 | IESG | [RFCXXXX] |
	| high-percentile-c | TBA47 | 5 | IESG | [RFCXXXX] |		| high-percentile-c | TBA47 | 5 | IESG | [RFCXXXX] |
	| peak-c | TBA48 | 5 | IESG | [RFCXXXX] |		| peak-c | TBA48 | 5 | IESG | [RFCXXXX] |
	| ietf-dots-signal-cha | TBA49 | 5 | 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| TBA55 | 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] |
	| measurement-sample | TBA58 | 0 | IESG | [RFCXXXX] |		| measurement-sample | TBA58 | 0 | IESG | [RFCXXXX] |
	| talker | TBA59 | 0 | IESG | [RFCXXXX] |		| talker | TBA59 | 4 | IESG | [RFCXXXX] |
	| source-prefix | TBA60 | 0 | IESG | [RFCXXXX] |		| source-prefix | TBA60 | 3 | IESG | [RFCXXXX] |
	| mid-list | TBA61 | 4 | IESG | [RFCXXXX] |		| mid-list | TBA61 | 4 | IESG | [RFCXXXX] |
	| source-port-range | TBA62 | 4 | IESG | [RFCXXXX] |		| source-port-range | TBA62 | 4 | IESG | [RFCXXXX] |
	| source-icmp-type- | TBA63 | 4 | IESG | [RFCXXXX] |		| source-icmp-type- | TBA63 | 4 | IESG | [RFCXXXX] |
	| range | | | | |		| range | | | | |
	| target | TBA64 | 5 | IESG | [RFCXXXX] |		| target | TBA64 | 5 | IESG | [RFCXXXX] |
	| capacity | TBA65 | 0 | IESG | [RFCXXXX] |		| capacity | TBA65 | 0 | IESG | [RFCXXXX] |
	| protocol | TBA66 | 0 | IESG | [RFCXXXX] |		| protocol | TBA66 | 0 | IESG | [RFCXXXX] |
	| total-traffic- | TBA67 | 4 | IESG | [RFCXXXX] |		| total-traffic- | TBA67 | 4 | IESG | [RFCXXXX] |
	| normal-per-protocol | | | | |		| normal-per-protocol | | | | |
	| total-traffic- | TBA68 | 4 | IESG | [RFCXXXX] |		| total-traffic- | TBA68 | 4 | IESG | [RFCXXXX] |
	skipping to change at page 106, line 19 ¶		skipping to change at page 107, line 20 ¶
	| 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] |		| 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 | 0 | IESG | [RFCXXXX] |		| ietf-dots-telemetry: | TBA79 | 4 | IESG | [RFCXXXX] |
	| total-traffic | | | | |		| total-traffic | | | | |
	| ietf-dots-telemetry: | TBA80 | 0 | IESG | [RFCXXXX] |		| ietf-dots-telemetry: | TBA80 | 4 | IESG | [RFCXXXX] |
	| total-attack-traffic | | | | |		| total-attack-traffic | | | | |
	| ietf-dots-telemetry: | TBA81 | 0 | 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-l | TBA85 | 4 | IESG | [RFCXXXX] |
	| current-c | TBA86 | 5 | IESG | [RFCXXXX] |		| current-c | TBA86 | 5 | IESG | [RFCXXXX] |
	| lower-type | TBA87 | 0 | IESG | [RFCXXXX] |
	| upper-type | TBA88 | 0 | IESG | [RFCXXXX] |
	+----------------------+-------+-------+------------+---------------+		+----------------------+-------+-------+------------+---------------+
	Table 3: Registered DOTS Signal Channel CBOR Key Values		Table 3: Registered DOTS Signal Channel CBOR Key Values
	Note that 'lower-type' and 'upper-type' are also requested for
	assignment in the call-home I-D. Both I-Ds should be sync'ed as
	depending the one that will make it first to the IANA.
	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].
	+------+-------------------+------------------------+-------------+		+------+-------------------+------------------------+-------------+
	| Code | Label | Description | Reference |		| Code | Label | Description | Reference |
	+======+===================+========================+=============+		+======+===================+========================+=============+
	| TBA | overlapping-pipes | Overlapping pipe scope | [RFCXXXX] |		| TBA | overlapping-pipes | Overlapping pipe scope | [RFCXXXX] |
	+------+-------------------+------------------------+-------------+		+------+-------------------+------------------------+-------------+
	skipping to change at page 107, line 47 ¶		skipping to change at page 108, line 39 ¶
	namespace: urn:ietf:params:xml:ns:yang:ietf-dots-mapping		namespace: urn:ietf:params:xml:ns:yang:ietf-dots-mapping
	maintained by IANA: N		maintained by IANA: N
	prefix: dots-mapping		prefix: dots-mapping
	reference: RFC XXXX		reference: RFC XXXX
	13. Security Considerations		13. Security Considerations
	13.1. DOTS Signal Channel Telemetry		13.1. DOTS Signal Channel Telemetry
	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 [I-D.ietf-dots-rfc8782-bis]. The		discussed in Section 11 of [RFC9132]. The following discusses the
	following discusses the security considerations that are specific to		security considerations that are specific to the DOTS signal channel
	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.
	DOTS clients are typically trusted devices by the DOTS client domain.		DOTS clients are typically considered to be trusted devices by the
	DOTS clients may be co-located on network security services (e.g.,		DOTS client domain. DOTS clients may be co-located on network
	firewall) and a compromised security service potentially can do a lot		security services (e.g., firewall devices), and a compromised
	more damage to the network. This assumption differs from the often		security service potentially can do a lot more damage to the network
	held view that devices are untrusted, often referred to as the "zero-		than just the DOTS client component. This assumption differs from
	trust model". A compromised DOTS client can send fake DOTS telemetry		the often held view that devices are untrusted, often referred to as
	data to a DOTS server to mislead the DOTS server. This attack can be		the "zero-trust model". A compromised DOTS client can send fake DOTS
	prevented by monitoring and auditing DOTS clients to detect		telemetry data to a DOTS server to mislead the DOTS server. This
	misbehavior and to deter misuse, and by only authorizing the DOTS		attack can be prevented by monitoring and auditing DOTS clients to
	client to convey the DOTS telemetry for specific target resources		detect misbehavior and to deter misuse, and by only authorizing the
	(e.g., an application server is authorized to exchange DOTS telemetry		DOTS client to convey DOTS telemetry information for specific target
	for its IP addresses but a DDoS mitigator can exchange DOTS telemetry		resources (e.g., an application server is authorized to exchange DOTS
	for any target resource in the network). As a reminder, this is		telemetry for its IP addresses but a DDoS mitigator can exchange DOTS
	variation of dealing with compromised DOTS clients as discussed in		telemetry for any target resource in the network). As a reminder,
	Section 11 of [I-D.ietf-dots-rfc8782-bis].		this is a variation of dealing with compromised DOTS clients as
			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		o The probing rate (defined in Section 4.5 of [RFC9132]) can be used
	[I-D.ietf-dots-rfc8782-bis]) can be used to limit the average data		to limit the average data rate to the DOTS server.
	rate to the DOTS server.
	o Rate-limiting DOTS telemetry, including those with new 'tmid'		o 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 (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.
	13.2. Vendor Attack Mapping		13.2. Vendor Attack Mapping
	The security considerations for the DOTS data channel protocol are		The security considerations for the DOTS data channel protocol are
	discussed in Section 10 of [RFC8783]. The following discusses the		discussed in Section 10 of [RFC8783]. The following discusses the
	security considerations that are specific to the DOTS data channel		security considerations that are specific to the DOTS data channel
	skipping to change at page 110, line 8 ¶		skipping to change at page 110, line 47 ¶
	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.
	Special thanks to Jon Shallow and Kaname Nishizuka for their		Special thanks to Jon Shallow and Kaname Nishizuka for their
	implementation and interoperability work.		implementation and interoperability work.
	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.
	16. References		16. References
	16.1. Normative References		16.1. Normative References
	[Enterprise-Numbers]		[Enterprise-Numbers]
	"Private Enterprise Numbers", May 2020,		"Private Enterprise Numbers", May 2020,
	<http://www.iana.org/assignments/enterprise-numbers.html>.		<http://www.iana.org/assignments/enterprise-numbers.html>.
	[I-D.ietf-dots-rfc8782-bis]
	Boucadair, M., Shallow, J., and T. Reddy.K, "Distributed
	Denial-of-Service Open Threat Signaling (DOTS) Signal
	Channel Specification", draft-ietf-dots-rfc8782-bis-06
	(work in progress), March 2021.
	[I-D.ietf-dots-signal-filter-control]
	Nishizuka, K., Boucadair, M., Reddy, T., and T. Nagata,
	"Controlling Filtering Rules Using Distributed Denial-of-
	Service Open Threat Signaling (DOTS) Signal Channel",
	draft-ietf-dots-signal-filter-control-07 (work in
	progress), June 2020.
	[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>.
	[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for		[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
	skipping to change at page 112, line 5 ¶		skipping to change at page 112, line 32 ¶
	[RFC8791] Bierman, A., Bjoerklund, M., and K. Watsen, "YANG Data		[RFC8791] Bierman, A., Bjoerklund, 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,
			"Distributed Denial-of-Service Open Threat Signaling
			(DOTS) Signal Channel Specification", RFC 9132,
			DOI 10.17487/RFC9132, September 2021,
			<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", draft-doron-
	dots-telemetry-00 (work in progress), October 2016.		dots-telemetry-00 (work in progress), October 2016.
	[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 for Faster		Protocol (CoAP) Block-Wise Transfer Options Supporting
	Transmission", draft-ietf-core-new-block-11 (work in		Robust Transmission", draft-ietf-core-new-block-14 (work
	progress), April 2021.		in progress), May 2021.
	[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)", draft-ietf-dots-
	multihoming-05 (work in progress), November 2020.		multihoming-08 (work in progress), October 2021.
	[I-D.ietf-dots-use-cases]		[I-D.ietf-dots-robust-blocks]
	Dobbins, R., Migault, D., Moskowitz, R., Teague, N., Xia,		Boucadair, M. and J. Shallow, "Distributed Denial-of-
	L., and K. Nishizuka, "Use cases for DDoS Open Threat		Service Open Threat Signaling (DOTS) Signal Channel
	Signaling", draft-ietf-dots-use-cases-25 (work in		Configuration Attributes for Robust Block Transmission",
	progress), July 2020.		draft-ietf-dots-robust-blocks-00 (work in progress),
			August 2021.
	[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>.
	[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>.
			[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",
			RFC 4960, DOI 10.17487/RFC4960, September 2007,
			<https://www.rfc-editor.org/info/rfc4960>.
	[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>.
			[RFC8903] Dobbins, R., Migault, D., Moskowitz, R., Teague, N., Xia,
			L., and K. Nishizuka, "Use Cases for DDoS Open Threat
			Signaling", RFC 8903, DOI 10.17487/RFC8903, May 2021,
			<https://www.rfc-editor.org/info/rfc8903>.
	Authors' Addresses		Authors' Addresses
	Mohamed Boucadair (editor)		Mohamed Boucadair (editor)
	Orange		Orange
	Rennes 35000		Rennes 35000
	France		France
	Email: mohamed.boucadair@orange.com		Email: mohamed.boucadair@orange.com
	Tirumaleswar Reddy (editor)		Tirumaleswar Reddy (editor)
End of changes. 211 change blocks.
	462 lines changed or deleted		479 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/