< draft-ietf-dots-telemetry-05.txt		draft-ietf-dots-telemetry-06.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: September 28, 2020 McAfee		Expires: October 9, 2020 McAfee
	E. Doron		E. Doron
	Radware Ltd.		Radware Ltd.
	M. Chen		M. Chen
	CMCC		CMCC
	March 27, 2020		April 7, 2020
	Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry		Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry
	draft-ietf-dots-telemetry-05		draft-ietf-dots-telemetry-06
	Abstract		Abstract
	This document aims to enrich DOTS signal channel protocol with		This document aims to enrich DOTS signal channel protocol with
	various telemetry attributes allowing optimal DDoS attack mitigation.		various telemetry attributes allowing optimal DDoS attack mitigation.
	It specifies the normal traffic baseline and attack traffic telemetry		It specifies the normal traffic baseline and attack traffic telemetry
	attributes a DOTS client can convey to its DOTS server in the		attributes a DOTS client can convey to its DOTS server in the
	mitigation request, the mitigation status telemetry attributes a DOTS		mitigation request, the mitigation status telemetry attributes a DOTS
	server can communicate to a DOTS client, and the mitigation efficacy		server can communicate to a DOTS client, and the mitigation efficacy
	telemetry attributes a DOTS client can communicate to a DOTS server.		telemetry attributes a DOTS client can communicate to a DOTS server.
	skipping to change at page 1, line 43 ¶		skipping to change at page 1, line 43 ¶
	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 September 28, 2020.		This Internet-Draft will expire on October 9, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 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 25 ¶		skipping to change at page 2, line 25 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. DOTS Telemetry: Overview and Purpose . . . . . . . . . . . . 5		3. DOTS Telemetry: Overview and Purpose . . . . . . . . . . . . 5
	4. Generic Considerations . . . . . . . . . . . . . . . . . . . 9		4. Generic Considerations . . . . . . . . . . . . . . . . . . . 9
	4.1. DOTS Client Identification . . . . . . . . . . . . . . . 9		4.1. DOTS Client Identification . . . . . . . . . . . . . . . 9
	4.2. DOTS Gateways . . . . . . . . . . . . . . . . . . . . . . 9		4.2. DOTS Gateways . . . . . . . . . . . . . . . . . . . . . . 9
	4.3. Empty URI Paths . . . . . . . . . . . . . . . . . . . . . 9		4.3. Empty URI Paths . . . . . . . . . . . . . . . . . . . . . 9
	4.4. Controlling Configuration Data . . . . . . . . . . . . . 9		4.4. Controlling Configuration Data . . . . . . . . . . . . . 9
	4.5. Block-wise Transfer . . . . . . . . . . . . . . . . . . . 9		4.5. Block-wise Transfer . . . . . . . . . . . . . . . . . . . 10
	4.6. DOTS Multi-homing Considerations . . . . . . . . . . . . 10		4.6. DOTS Multi-homing Considerations . . . . . . . . . . . . 10
	4.7. YANG Considerations . . . . . . . . . . . . . . . . . . . 10		4.7. YANG Considerations . . . . . . . . . . . . . . . . . . . 10
	4.8. A Note About Examples . . . . . . . . . . . . . . . . . . 11		4.8. A Note About Examples . . . . . . . . . . . . . . . . . . 11
	5. Telemetry Operation Paths . . . . . . . . . . . . . . . . . . 11		5. Telemetry Operation Paths . . . . . . . . . . . . . . . . . . 11
	6. DOTS Telemetry Setup Configuration . . . . . . . . . . . . . 12		6. DOTS Telemetry Setup Configuration . . . . . . . . . . . . . 12
	6.1. Telemetry Configuration . . . . . . . . . . . . . . . . . 12		6.1. Telemetry Configuration . . . . . . . . . . . . . . . . . 13
	6.1.1. Retrieve Current DOTS Telemetry Configuration . . . . 12		6.1.1. Retrieve Current DOTS Telemetry Configuration . . . . 13
	6.1.2. Convey DOTS Telemetry Configuration . . . . . . . . . 15		6.1.2. Convey DOTS Telemetry Configuration . . . . . . . . . 16
	6.1.3. Retrieve Installed DOTS Telemetry Configuration . . . 18		6.1.3. Retrieve Installed DOTS Telemetry Configuration . . . 19
	6.1.4. Delete DOTS Telemetry Configuration . . . . . . . . . 18		6.1.4. Delete DOTS Telemetry Configuration . . . . . . . . . 19
	6.2. Total Pipe Capacity . . . . . . . . . . . . . . . . . . . 19		6.2. Total Pipe Capacity . . . . . . . . . . . . . . . . . . . 20
	6.2.1. Convey DOTS Client Domain Pipe Capacity . . . . . . . 20		6.2.1. Convey DOTS Client Domain Pipe Capacity . . . . . . . 21
	6.2.2. Retrieve Installed DOTS Client Domain Pipe Capacity . 25		6.2.2. Retrieve Installed DOTS Client Domain Pipe Capacity . 26
	6.2.3. Delete Installed DOTS Client Domain Pipe Capacity . . 25		6.2.3. Delete Installed DOTS Client Domain Pipe Capacity . . 26
	6.3. Telemetry Baseline . . . . . . . . . . . . . . . . . . . 26		6.3. Telemetry Baseline . . . . . . . . . . . . . . . . . . . 27
	6.3.1. Convey DOTS Client Domain Baseline Information . . . 28		6.3.1. Convey DOTS Client Domain Baseline Information . . . 30
	6.3.2. Retrieve Installed Normal Traffic Baseline . . . . . 29		6.3.2. Retrieve Installed Normal Traffic Baseline . . . . . 33
	6.3.3. Delete Installed Normal Traffic Baseline . . . . . . 29		6.3.3. Delete Installed Normal Traffic Baseline . . . . . . 33
	6.4. Reset Installed Telemetry Setup . . . . . . . . . . . . . 30		6.4. Reset Installed Telemetry Setup . . . . . . . . . . . . . 33
	6.5. Conflict with Other DOTS Clients of the Same Domain . . . 30		6.5. Conflict with Other DOTS Clients of the Same Domain . . . 33
	7. DOTS Pre-or-Ongoing Mitigation Telemetry . . . . . . . . . . 30		7. DOTS Pre-or-Ongoing Mitigation Telemetry . . . . . . . . . . 34
	7.1. Pre-or-Ongoing-Mitigation DOTS Telemetry Attributes . . . 32		7.1. Pre-or-Ongoing-Mitigation DOTS Telemetry Attributes . . . 36
	7.1.1. Target . . . . . . . . . . . . . . . . . . . . . . . 32		7.1.1. Target . . . . . . . . . . . . . . . . . . . . . . . 36
	7.1.2. Total Traffic . . . . . . . . . . . . . . . . . . . . 33		7.1.2. Total Traffic . . . . . . . . . . . . . . . . . . . . 38
	7.1.3. Total Attack Traffic . . . . . . . . . . . . . . . . 34		7.1.3. Total Attack Traffic . . . . . . . . . . . . . . . . 39
	7.1.4. Total Attack Connections . . . . . . . . . . . . . . 35		7.1.4. Total Attack Connections . . . . . . . . . . . . . . 41
	7.1.5. Attack Details . . . . . . . . . . . . . . . . . . . 37		7.1.5. Attack Details . . . . . . . . . . . . . . . . . . . 42
	7.2. From DOTS Clients to DOTS Servers . . . . . . . . . . . . 39		7.2. From DOTS Clients to DOTS Servers . . . . . . . . . . . . 44
	7.3. From DOTS Servers to DOTS Clients . . . . . . . . . . . . 40		7.3. From DOTS Servers to DOTS Clients . . . . . . . . . . . . 47
	8. DOTS Telemetry Mitigation Status Update . . . . . . . . . . . 43		8. DOTS Telemetry Mitigation Status Update . . . . . . . . . . . 51
	8.1. DOTS Clients to Servers Mitigation Efficacy DOTS		8.1. DOTS Clients to Servers Mitigation Efficacy DOTS
	Telemetry Attributes . . . . . . . . . . . . . . . . . . 43		Telemetry Attributes . . . . . . . . . . . . . . . . . . 51
	8.2. DOTS Servers to Clients Mitigation Status DOTS Telemetry		8.2. DOTS Servers to Clients Mitigation Status DOTS Telemetry
	Attributes . . . . . . . . . . . . . . . . . . . . . . . 45		Attributes . . . . . . . . . . . . . . . . . . . . . . . 52
	9. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 48		9. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 56
	10. YANG/JSON Mapping Parameters to CBOR . . . . . . . . . . . . 72		10. YANG/JSON Mapping Parameters to CBOR . . . . . . . . . . . . 81
	11. IANA Considerationsr . . . . . . . . . . . . . . . . . . . . 75		11. IANA Considerationsr . . . . . . . . . . . . . . . . . . . . 85
	11.1. DOTS Signal Channel CBOR Key Values . . . . . . . . . . 75		11.1. DOTS Signal Channel CBOR Key Values . . . . . . . . . . 85
	11.2. DOTS Signal Channel Conflict Cause Codes . . . . . . . . 79		11.2. DOTS Signal Channel Conflict Cause Codes . . . . . . . . 89
	11.3. DOTS Signal Telemetry YANG Module . . . . . . . . . . . 79		11.3. DOTS Signal Telemetry YANG Module . . . . . . . . . . . 90
	12. Security Considerations . . . . . . . . . . . . . . . . . . . 79		12. Security Considerations . . . . . . . . . . . . . . . . . . . 90
	13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 80		13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 90
	14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 80		14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 90
	15. References . . . . . . . . . . . . . . . . . . . . . . . . . 80		15. References . . . . . . . . . . . . . . . . . . . . . . . . . 91
	15.1. Normative References . . . . . . . . . . . . . . . . . . 80		15.1. Normative References . . . . . . . . . . . . . . . . . . 91
	15.2. Informative References . . . . . . . . . . . . . . . . . 81		15.2. Informative References . . . . . . . . . . . . . . . . . 92
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 82		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 93
	1. Introduction		1. Introduction
	Distributed Denial of Service (DDoS) attacks have become more vicious		Distributed Denial of Service (DDoS) attacks have become more
	and sophisticated in almost all aspects of their maneuvers and		sophisticated. IT organizations and service providers are facing
	malevolent intentions. IT organizations and service providers are		DDoS attacks that fall into two broad categories:
	facing DDoS attacks that fall into two broad categories: Network/
	Transport layer attacks and Application layer attacks:
	o Network/Transport layer attacks target the victim's
	infrastructure. These attacks are not necessarily aimed at taking
	down the actual delivered services, but rather to eliminate
	various network elements (routers, switches, firewalls, transit
	links, and so on) from serving legitimate user traffic.
	The main method of such attacks is to send a large volume or high		1. Network/Transport layer attacks target the victim's
	packet per second (PPS) of traffic toward the victim's		infrastructure. These attacks are not necessarily aimed at
	infrastructure. Typically, attack volumes may vary from a few 100		taking down the actual delivered services, but rather to
	Mbps/PPS to 100s of Gbps or even Tbps. Attacks are commonly		eliminate various network elements (routers, switches, firewalls,
	carried out leveraging botnets and attack reflectors for		transit links, and so on) from serving legitimate users traffic.
	amplification attacks such as NTP (Network Time Protocol), DNS
	(Domain Name System), SNMP (Simple Network Management Protocol),
	or SSDP (Simple Service Discovery Protoco).
	o Application layer attacks target various applications. Typical		The main method of such attacks is to send a large volume or high
	examples include attacks against HTTP/HTTPS, DNS, SIP (Session		packet per second (pps) of traffic toward the victim's
	Initiation Protocol), or SMTP (Simple Mail Transfer Protocol).		infrastructure. Typically, attack volumes may vary from a few
			100 Mbps to 100s of Gbps or even Tbps. Attacks are commonly
			carried out leveraging botnets and attack reflectors for
			amplification attacks such as NTP (Network Time Protocol), DNS
			(Domain Name System), SNMP (Simple Network Management Protocol),
			or SSDP (Simple Service Discovery Protocol).
	However, all valid applications with their port numbers open at		2. Application layer attacks target various applications. Typical
	network edges can be attractive attack targets.		examples include attacks against HTTP/HTTPS, DNS, SIP (Session
			Initiation Protocol), or SMTP (Simple Mail Transfer Protocol).
			However, all applications with their port numbers open at network
			edges can be attractive attack targets.
	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, 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. Multiple and simultaneous mitigation techniques
	are needed to defeat such attack campaigns. It is also common for		are needed to defeat such attack campaigns. It is also common for
	attackers to change attack vectors right after a successful		attackers to change attack vectors right after a successful
	mitigation, burdening their opponents with changing their defense		mitigation, burdening their opponents with changing their defense
	methods.		methods.
	The ultimate conclusion derived from these real scenarios is that		The ultimate conclusion derived from these real scenarios is that
	modern attacks detection and mitigation are most certainly		modern attacks detection and mitigation are most certainly
	complicated and highly convoluted tasks. They demand a comprehensive		complicated and highly convoluted tasks. They demand a comprehensive
	knowledge of the attack attributes, the targeted normal behavior/		knowledge of the attack attributes, the targeted normal behavior
	traffic patterns, as well as the attacker's on-going and past		(including, normal traffic patterns), as well as the attacker's on-
	actions. Even more challenging, retrieving all the analytics needed		going 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 to obtain
	industry's current capabilities.		with the industry's current capabilities.
	The DOTS signal channel protocol [I-D.ietf-dots-signal-channel] is		The DOTS signal channel protocol [I-D.ietf-dots-signal-channel] is
	used to carry information about a network resource or a network (or a		used to carry information about a network resource or a network (or a
	part thereof) that is under a DDoS attack. Such information is sent		part thereof) that is under a DDoS attack. Such information is sent
	by a DOTS client to one or multiple DOTS servers so that appropriate		by a DOTS client to one or multiple DOTS servers so that appropriate
	mitigation actions are undertaken on traffic deemed suspicious.		mitigation actions are undertaken on traffic deemed suspicious.
	Various use cases are discussed in [I-D.ietf-dots-use-cases].		Various use cases are discussed in [I-D.ietf-dots-use-cases].
	Typically, DOTS clients can be integrated within a DDoS attack		Typically, DOTS clients can be integrated within a DDoS attack
	detector, or network and security elements that have been actively		detector, or network and security elements that have been actively
	engaged with ongoing attacks. The DOTS client mitigation environment		engaged with ongoing attacks. The DOTS client mitigation environment
	determines that it is no longer possible or practical for it to		determines that it is no longer possible or practical for it to
	handle these attacks. This can be due to lack of resources or		handle these attacks. This can be due to a lack of resources or
	security capabilities, as derived from the complexities and the		security capabilities, as derived from the complexities and the
	intensity of these attacks. In this circumstance, the DOTS client		intensity of these attacks. In this circumstance, the DOTS client
	has invaluable knowledge about the actual attacks that need to be		has invaluable knowledge about the actual attacks that need to be
	handled by its DOTS server(s). By enabling the DOTS client to share		handled by its DOTS server(s). By enabling the DOTS client to share
	this comprehensive knowledge of an ongoing attack under specific		this 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 DOTS server associated mitigation resources, the DOTS
	server has the knowledge about the ongoing attack mitigation. The		server has the knowledge about the ongoing attack mitigation. The
	DOTS server can share this information with the DOTS client so that		DOTS server can share this information with the DOTS client so that
	the client can better assess and evaluate the actual mitigation		the client can better assess and evaluate the actual mitigation
	realized.		realized.
	In some deployments, DOTS clients can send mitigation hints derived		DOTS clients can send mitigation hints derived from attack details to
	from attack details to DOTS servers, with the full understanding that		DOTS servers, with the full understanding that the DOTS server may
	the DOTS server may ignore mitigation hints, as described in		ignore mitigation hints, as described in [RFC8612] (Gen-004).
	[RFC8612] (Gen-004). Mitigation hints will be transmitted across the		Mitigation hints will be transmitted across the DOTS signal channel,
	DOTS signal channel, as the data channel may not be functional during		as the data channel may not be functional during an attack. How a
	an attack. How a DOTS server is handling normal and attack traffic		DOTS server is handling normal and attack traffic attributes, and
	attributes, and mitigation hints is implementation-specific.		mitigation hints is implementation-specific.
	Both DOTS client and server can benefit this information by		Both DOTS client and server can benefit 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 the DOTS client can		This document defines DOTS telemetry attributes that can be conveyed
	convey to the DOTS server, and vice versa. The DOTS telemetry		by DOTS clients to DOTS servers, and vice versa. The DOTS telemetry
	attributes are not mandatory fields. Nevertheless, when DOTS		attributes are not mandatory fields. Nevertheless, when DOTS
	telemetry attributes are available to a DOTS agent, and absent any		telemetry attributes are available to a DOTS agent, and absent any
	policy, it can signal the attributes in order to optimize the overall		policy, it can signal the attributes in order to optimize the overall
	mitigation service provisioned using DOTS. Some of the DOTS		mitigation service provisioned using DOTS. Some of the DOTS
	telemetry data is not shared during an attack time.		telemetry data is not shared during an attack time.
	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
	skipping to change at page 5, line 49 ¶		skipping to change at page 5, line 47 ¶
	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. The 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.
	The meaning of the symbols in YANG tree diagrams is defined in		The meaning of the symbols in YANG tree diagrams is defined in
	[RFC8340].		[RFC8340].
	3. DOTS Telemetry: Overview and Purpose		3. DOTS Telemetry: Overview and Purpose
	When signaling a mitigation request, it is most certainly beneficial		When signaling a mitigation request, it is most certainly beneficial
	for the DOTS client to signal to the DOTS server any knowledge		for DOTS clients to signal to DOTS servers any knowledge regarding
	regarding ongoing attacks. This can happen in cases where DOTS		ongoing attacks. This can happen in cases where DOTS clients are
	clients are asking the DOTS server for support in defending against		asking DOTS servers for support in defending against attacks that
	attacks that they have already detected and/or mitigated. These		they have already detected and/or mitigated. These actions taken by
	actions taken by DOTS clients are referred to as "signaling the DOTS		DOTS clients are referred to as "signaling the DOTS Telemetry".
	Telemetry".
	If attacks are already detected and categorized by the 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 this information and optimize the overall service
	delivered. It is important to note that DOTS client and server		delivery. It is important to note that DOTS clients and servers
	detection and mitigation approaches can be different, and can		detection and mitigation approaches can be different, and can
	potentially outcome different results and attack classifications.		potentially outcome different results and attack classifications.
	The DDoS mitigation service treats the ongoing attack details from		The DDoS mitigation service treats the ongoing attack details
	the client as hints and cannot completely rely or trust the attack		received from DOTS clients as hints and cannot completely rely or
	details conveyed by the DOTS client.		trust the attack details conveyed by DOTS clients.
	A basic requirement of security operation teams is to be aware and		A basic requirement of security operation teams is to be aware and
	get visibility into the attacks they need to handle. The DOTS server		get visibility into the attacks they need to handle. The DOTS server
	security operation teams benefit from the DOTS telemetry, especially		security operation teams benefit from the DOTS telemetry, especially
	from the reports of ongoing attacks. Even if some mitigation can be		from the reports of ongoing attacks. Even if some mitigation can be
	automated, operational teams can use the DOTS telemetry to be		automated, operational teams can use the DOTS telemetry to be
	prepared for attack mitigation and to assign the correct resources		prepared for attack mitigation and to assign the correct resources
	(operation staff, networking and mitigation) for the specific		(operation staff, networking and mitigation) for the specific
	service. Similarly, security operation personnel at the DOTS client		service. Similarly, security operation personnel at the DOTS client
	side ask for feedback about their requests for protection.		side ask for feedback about their requests for protection.
	Therefore, it is valuable for the DOTS server to share DOTS telemetry		Therefore, it is valuable for DOTS servers to share DOTS telemetry
	with the DOTS client.		with DOTS clients.
	Thus mutual sharing of information is crucial for "closing the		Mutual sharing of information is thus crucial for "closing the
	mitigation loop" between the DOTS client and server. 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 realize that the same attacks that the
	DOTS server's mitigation resources are seeing are those that the 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 to mitigate. For the DOTS client side team, it is
	important to realize that the DOTS clients receive the required		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...".		two attacks and my DOTS server detects and mitigates only one...".
	Cases of inconsistency in attack classification between DOTS client		Cases of inconsistency in attack classification between DOTS clients
	and server can be high-lighted, and maybe handled, using the DOTS		and servers can be highlighted, and maybe handled, using the DOTS
	telemetry attributes.		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 potentially use DOTS telemetry as a		client and server sides, can use DOTS telemetry as a feedback to
	feedback to automate various control and management activities		automate various control and management activities derived from
	derived from ongoing information signaled.		signaled telemetry information .
	If the DOTS server's mitigation resources have the capabilities to		If the DOTS server's mitigation resources have the capabilities to
	facilitate the DOTS telemetry, the DOTS server adopts its protection		facilitate the DOTS telemetry, the DOTS server adapts its protection
	strategy and activates the required countermeasures immediately		strategy and activates the required countermeasures immediately
	(automation enabled). The overall results of this adoption are		(automation enabled) for the sake of optimized attack mitigation
	optimized attack mitigation decisions and actions.		decisions and actions.
	The DOTS telemetry can also be used to tune the DDoS mitigators with		DOTS telemetry can also be used to tune the DDoS mitigators with the
	the correct state of the attack. During the last few years, DDoS		correct state of an attack. During the last few years, DDoS attack
	attack detection technologies have evolved from threshold-based		detection technologies have evolved from threshold-based detection
	detection (that is, cases when all or specific parts of traffic cross		(that is, cases when all or specific parts of traffic cross a pre-
	a pre-defined threshold for a certain period of time is considered as		defined threshold for a certain period of time is considered as an
	an attack) to an "anomaly detection" approach. In anomaly detection,		attack) to an "anomaly detection" approach. For the latter, it is
	the main idea is to maintain rigorous learning of "normal" behavior		required to maintain rigorous learning of "normal" behavior and where
	and where an "anomaly" (or an attack) is identified and categorized		an "anomaly" (or an attack) is identified and categorized based on
	based on the knowledge about the normal behavior and a deviation from		the knowledge about the normal behavior and a deviation from this
	this normal behavior. Machine learning approaches are used such that		normal behavior. Machine learning approaches are used such that the
	the actual "traffic thresholds" are "automatically calculated" by		actual traffic thresholds are automatically calculated by learning
	learning the protected entity normal traffic behavior during peace		the protected entity normal traffic behavior during idle time. The
	time. The normal traffic characterization learned is referred to as		normal traffic characterization learned is referred to as the "normal
	the "normal traffic baseline". An attack is detected when the		traffic baseline". An attack is detected when the victim's actual
	victim's actual traffic is deviating from this normal baseline.		traffic is deviating from this normal baseline.
	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. This		from attacker traffic on a per packet basis is complex. For example,
	complexity originates from the fact that the packet itself may look		a packet may look "legitimate" and no attack signature can be
	"legitimate" and no attack signature can be identified. The anomaly		identified. The anomaly can be identified only after detailed
	can be identified only after detailed statistical analysis. DDoS		statistical analysis. DDoS attack mitigators use the normal baseline
	attack mitigators use the normal baseline during the mitigation of an		during the mitigation of an attack to identify and categorize the
	attack to identify and categorize the expected appearance of a		expected appearance of a specific traffic pattern. Particularly, the
	specific traffic pattern. Particularly the mitigators use the normal		mitigators use the normal baseline to recognize the "level of
	baseline to recognize the "level of normality" needs to be achieved		normality" needs to be achieved during the various mitigation
	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 this attribute to the DOTS server along		protected entities, signaling such information to the DOTS server
	with the attack traffic levels is significantly valuable. The DOTS		along with the attack traffic levels is significantly valuable. The
	server benefits from this telemetry by tuning its mitigation		DOTS server benefits from this telemetry by tuning its mitigation
	resources with the DOTS client's normal baseline. The DOTS server		resources with the DOTS client's normal baseline. The DOTS server
	mitigators use the baseline to familiarize themselves with the attack		mitigators use the baseline to familiarize themselves with the attack
	victim's normal behavior and target the baseline as the level of		victim's normal behavior and target the baseline as the level of
	normality they need to achieve. Consequently, the overall mitigation		normality they need to achieve. Fed with this inforamtion, the
	performances obtained are dramatically improved in terms of time to		overall mitigation performances is expected to be improved in terms
	mitigate, accuracy, false-negative, false-positive, and other		of time to mitigate, accuracy, false-negative, and false-positive.
	measures.
	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 in [I-D.ietf-dots-use-cases]).
	In addition, the highly diverse types of use-cases where DOTS clients		In addition, the highly diverse types of use-cases where DOTS clients
	are integrated also emphasize the need for knowledge of client		are integrated also emphasize the need for knowledge of each DOTS
	behavior. Consequently, common global thresholds for attack		client domain behavior. Consequently, common global thresholds for
	detection practically cannot be realized. Each DOTS client can have		attack detection practically cannot be realized. Each DOTS client
	its own levels of traffic and normal behavior. Without facilitating		domain can have its own levels of traffic and normal behavior.
	normal baseline signaling, it may be very difficult for DOTS servers		Without facilitating normal baseline signaling, it may be very
	in some cases to detect and mitigate the attacks accurately:		difficult for DOTS servers in some cases to detect and mitigate the
			attacks accurately:
	It is important to emphasize that it is practically impossible for		It is important to emphasize that it is practically impossible for
	the server's mitigators to calculate the normal baseline in cases		the DOTS server's mitigators to calculate the normal baseline in
	where they do not have any knowledge of the traffic beforehand.		cases where they do not have any knowledge of the traffic
			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 or manual configuration at the risk to maintain		mechanisms or manual configuration at the risk to maintain
	inaccurate information as the network evolves and "normal"		inaccurate information as the network evolves and "normal"
	patterns change. The use of a dynamic and collaborative means		patterns change. The use of a dynamic and collaborative means
	between the DOTS client and server to identify and share key		between the DOTS client and server to identify and share key
	parameters for the sake of efficient DDoS protection is valuable.		parameters for the sake of efficient DDoS protection is valuable.
	During a high volume attack, DOTS client pipes can be totally		During a high volume attack, DOTS client pipes can be totally
	saturated. The DOTS client asks the DOTS server 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 "clean traffic", or what it believes is "clean". This
	can happen when the mitigator has not managed to detect and mitigate		can happen when the mitigator has not managed to detect and mitigate
	all the attacks launched towards the client. In this case, it can be		all the attacks launched towards the DOTS client domain. In this
	valuable to clients to signal to server the "Total pipe capacity",		case, it can be valuable to DOTS clients to signal to DOTS servers
	which is the level of traffic the DOTS client domain can absorb from		the "total pipe capacity", which is the level of traffic the DOTS
	the upstream network. Dynamic updates of the condition of pipes		client domain can absorb from its upstream network. Dynamic updates
	between DOTS agents while they are under a DDoS attack is essential.		of the condition of pipes between DOTS agents while they are under a
	For example, where multiple DOTS clients share the same physical		DDoS attack is essential (e.g., where multiple DOTS clients share the
	connectivity pipes. It is important to note, that the term "pipe"		same physical connectivity pipes). It is important to note that the
	noted here does not necessary represent physical pipe, but rather		term "pipe" noted here does not necessary represent physical pipe,
	represents the maximum level of traffic that the DOTS client domain		but rather represents the maximum level of traffic that the DOTS
	can receive. The DOTS server should activate other mechanisms to		client domain can receive. The DOTS server should activate other
	ensure it does not allow the client's pipes to be saturated		mechanisms to ensure it does not allow the DOTS client domain's pipes
	unintentionally. The rate-limit action defined in		to be saturated unintentionally. The rate-limit action defined in
	[I-D.ietf-dots-data-channel] is a reasonable candidate to achieve		[I-D.ietf-dots-data-channel] is a reasonable candidate to achieve
	this objective; the client can ask for the type of traffic (such as		this objective; the DOTS client can ask for the type(s) of traffic
	ICMP, UDP, TCP port number 80) it prefers to limit. The rate-limit		(such as ICMP, UDP, TCP port number 80) it prefers to limit. The
	action can be controlled via the signal-channel		rate-limit action can be controlled via the signal-channel
	[I-D.ietf-dots-signal-filter-control] even when the pipe is		[I-D.ietf-dots-signal-filter-control] even when the pipe is
	overwhelmed.		overwhelmed.
	To summarize:		To summarize:
	Timely and effective signaling of up-to-date DOTS telemetry to all		Timely and effective signaling of up-to-date DDoS telemetry to all
	elements involved in the mitigation process is essential and		elements involved in the mitigation process is essential and
	absolutely improves the overall service effectiveness. Bi-		absolutely improves the overall DDoS mitigation service
	directional feedback between DOTS agents is required for the		effectiveness. Bi-directional feedback between DOTS agents is
	increased awareness of each party, supporting superior and highly		required for an increased awareness of each party, supporting
	efficient attack mitigation service.		superior and highly efficient attack mitigation service.
	4. Generic Considerations		4. Generic Considerations
	4.1. DOTS Client Identification		4.1. DOTS Client Identification
	Following the rules in [I-D.ietf-dots-signal-channel], a unique		Following the rules in [I-D.ietf-dots-signal-channel], 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-signal-channel] forbids 'cuid' to be
			returned in a response message body.
	4.2. DOTS Gateways		4.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 [I-D.ietf-dots-signal-channel] must be		considerations elaborated in [I-D.ietf-dots-signal-channel] must be
	followed. In particular, 'cdid' attribute is used to unambiguously		followed. In particular, 'cdid' attribute is used to unambiguously
	identify a DOTS client domain.		identify a DOTS client domain.
			As a reminder, [I-D.ietf-dots-signal-channel] forbids 'cdid' (if
			present) to be returned in a response message body.
	4.3. Empty URI Paths		4.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 and render an entire message invalid.
	4.4. Controlling Configuration Data		4.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-signal-channel] for managing DOTS		Section of 4.5.3 of [I-D.ietf-dots-signal-channel] for managing DOTS
	telemetry configuration freshness and notification. Likewise, a DOTS		telemetry configuration freshness and notification. Likewise, a DOTS
	skipping to change at page 10, line 42 ¶		skipping to change at page 10, line 46 ¶
	Messages exchanged between DOTS agents are serialized using Concise		Messages exchanged between DOTS agents are serialized using Concise
	Binary Object Representation (CBOR). CBOR-encoded payloads are used		Binary Object Representation (CBOR). CBOR-encoded payloads are used
	to carry signal channel-specific payload messages which convey		to carry signal channel-specific payload messages which convey
	request parameters and response information such as errors		request parameters and response information such as errors
	[I-D.ietf-dots-signal-channel].		[I-D.ietf-dots-signal-channel].
	This document specifies a YANG module for representing DOTS telemetry		This document specifies a YANG module for representing DOTS telemetry
	message types (Section 9). All parameters in the payload of the DOTS		message types (Section 9). All parameters in the payload of the DOTS
	signal channel are mapped to CBOR types as specified in Section 10.		signal channel are mapped to CBOR types as specified in Section 10.
			This YANG module is not intended to be used via NETCONF/ RESTCONF for
			DOTS server management purposes; such module is out of the scope of
			this document. It serves only to provide a data model and encoding,
			but not a management data model.
			DOTS servers are allowed to update the non-configurable 'ro' entities
			in the responses.
	The DOTS telemetry module (Section 9) uses "enumerations" rather than		The DOTS telemetry module (Section 9) uses "enumerations" rather than
	"identities" to define units, samples, and intervals because		"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.		suboptimal from a message compactness standpoint.
	4.8. A Note About Examples		4.8. A Note About Examples
	Examples are provided for illustration purposes. The document does		Examples are provided for illustration purposes. The document does
	skipping to change at page 12, line 23 ¶		skipping to change at page 12, line 38 ¶
	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.
			Telemetry setup configuration is bound to a DOTS client domain. DOTS
			serves MUST NOT expect DOTS clients to send regular requests to
			refresh the telemetry setup configuration. Any available telemetry
			setup configuration has a validity timeout of the DOTS session with a
			DOTS client domain. DOTS clients update their telemetry setup
			configuration upon change of a parameter that may impact attack
			mitigation.
	DOTS telemetry setup configuration request and response messages are		DOTS telemetry setup configuration request and response messages are
	marked as Confirmable messages.		marked as Confirmable messages.
	6.1. Telemetry Configuration		6.1. Telemetry Configuration
	A DOTS client can negotiate with its server(s) a set of telemetry		A DOTS client can negotiate with its server(s) a set of telemetry
	configuration parameters to be used for telemetry. Such parameters		configuration parameters to be used for telemetry. Such parameters
	include:		include:
	o Percentile-related measurement parameters		o Percentile-related measurement parameters
	skipping to change at page 14, line 7 ¶		skipping to change at page 15, line 7 ¶
	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 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 request with 'server-originated-telemetry''
	set to 'false'.		set to 'false'.
	augment /ietf-signal:dots-signal/ietf-signal:message-type:		augment /ietf-signal:dots-signal/ietf-signal:message-type:
	+--:(telemetry-setup) {dots-telemetry}?		+--:(telemetry-setup) {dots-telemetry}?
			| +--ro max-config-values
			| | +--ro measurement-interval? interval
			| | +--ro measurement-sample? sample
			| | +--ro low-percentile? percentile
			| | +--ro mid-percentile? percentile
			| | +--ro high-percentile? percentile
			| | +--ro server-originated-telemetry? boolean
			| | +--ro telemetry-notify-interval? uint32
			| +--ro min-config-values
			| | +--ro measurement-interval? interval
			| | +--ro measurement-sample? sample
			| | +--ro low-percentile? percentile
			| | +--ro mid-percentile? percentile
			| | +--ro high-percentile? percentile
			| | +--ro telemetry-notify-interval? uint32
			| +--ro supported-units
			| | +--ro unit-config* [unit]
			| | +--ro unit unit-type
			| | +--ro unit-status? boolean
	| +--rw telemetry* [cuid tsid]		| +--rw telemetry* [cuid tsid]
	| ...		| +--rw cuid string
			| +--rw cdid? string
			| +--rw tsid uint32
	| +--rw (setup-type)?		| +--rw (setup-type)?
	| +--:(telemetry-config)		| +--:(telemetry-config)
	| | +--rw current-config		| | +--rw current-config
	| | | +--rw measurement-interval? interval		| | +--rw measurement-interval? interval
	| | | +--rw measurement-sample? sample		| | +--rw measurement-sample? sample
	| | | +--rw low-percentile? percentile		| | +--rw low-percentile? percentile
	| | | +--rw mid-percentile? percentile		| | +--rw mid-percentile? percentile
	| | | +--rw high-percentile? percentile		| | +--rw high-percentile? percentile
	| | | +--rw unit-config* [unit]		| | +--rw unit-config* [unit]
	| | | | +--rw unit unit		| | | +--rw unit unit-type
	| | | | +--rw unit-status? boolean		| | | +--rw unit-status? boolean
	| | | +--rw server-originated-telemetry? boolean		| | +--rw server-originated-telemetry? boolean
	| | | +--rw telemetry-notify-interval? uint32		| | +--rw telemetry-notify-interval? uint32
	| | +--ro max-config-values
	| | | +--ro measurement-interval? interval
	| | | +--ro measurement-sample? sample
	| | | +--ro low-percentile? percentile
	| | | +--ro mid-percentile? percentile
	| | | +--ro high-percentile? percentile
	| | | +--ro server-originated-telemetry? boolean
	| | | +--ro telemetry-notify-interval? uint32
	| | +--ro min-config-values
	| | | +--ro measurement-interval? interval
	| | | +--ro measurement-sample? sample
	| | | +--ro low-percentile? percentile
	| | | +--ro mid-percentile? percentile
	| | | +--ro high-percentile? percentile
	| | | +--ro telemetry-notify-interval? uint32
	| | +--ro supported-units
	| | +--ro unit-config* [unit]
	| | +--ro unit unit
	| | +--ro unit-status? boolean
	| +--:(pipe)		| +--:(pipe)
	| ...		| ...
	| +--:(baseline)		| +--:(baseline)
	| ...		| ...
	+--:(telemetry) {dots-telemetry}?		+--:(telemetry) {dots-telemetry}?
	+--rw pre-or-ongoing-mitigation* [cuid tmid]		+--rw pre-or-ongoing-mitigation* [cuid tmid]
	...		...
	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. Convey DOTS Telemetry Configuration
	skipping to change at page 16, line 7 ¶		skipping to change at page 17, line 9 ¶
	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).
	This is a mandatory attribute.		This is a mandatory attribute.
			'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		The 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.
	skipping to change at page 19, line 32 ¶		skipping to change at page 20, line 32 ¶
	configuration.		configuration.
	6.2. Total Pipe Capacity		6.2. Total Pipe Capacity
	A DOTS client can communicate to its server(s) its DOTS client domain		A DOTS client can communicate to its server(s) its DOTS client domain
	pipe information. The tree structure of the pipe information is		pipe information. The tree structure of the pipe information is
	shown in Figure 9.		shown in Figure 9.
	augment /ietf-signal:dots-signal/ietf-signal:message-type:		augment /ietf-signal:dots-signal/ietf-signal:message-type:
	+--:(telemetry-setup) {dots-telemetry}?		+--:(telemetry-setup) {dots-telemetry}?
			| ...
	| +--rw telemetry* [cuid tsid]		| +--rw telemetry* [cuid tsid]
	| +--rw cuid string		| +--rw cuid string
	| +--rw cdid? string		| +--rw cdid? string
	| +--rw tsid uint32		| +--rw tsid uint32
	| +--rw (setup-type)?		| +--rw (setup-type)?
	| +--:(telemetry-config)		| +--:(telemetry-config)
	| | ...		| | ...
	| +--:(pipe)		| +--:(pipe)
	| | +--rw total-pipe-capacity* [link-id unit]		| | +--rw total-pipe-capacity* [link-id unit]
	| | +--rw link-id nt:link-id		| | +--rw link-id nt:link-id
	skipping to change at page 26, line 8 ¶		skipping to change at page 27, line 8 ¶
	6.2.3. Delete Installed DOTS Client Domain Pipe Capacity		6.2.3. Delete Installed DOTS Client Domain Pipe Capacity
	A DELETE request is used to delete the installed DOTS client domain		A DELETE request is used to delete the installed DOTS client domain
	pipe related information. The same procedure as defined in		pipe related information. The same procedure as defined in
	(Section 6.1.4) is followed.		(Section 6.1.4) is followed.
	6.3. Telemetry Baseline		6.3. Telemetry Baseline
	A DOTS client can communicate to its server(s) its normal traffic		A DOTS client can communicate to its server(s) its normal traffic
	baseline and total connections capacity:		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.		the total traffic normal baseline. It can be represented for a
			target using 'total-traffic-normal'.
	The traffic normal baseline is represented for a target and is		The traffic normal per protocol ('total-traffic-normal-per-
	transport-protocol specific.		protocol') baseline is represented for a target and is transport-
			protocol specific.
			The traffic normal per port number ('total-traffic-normal-per-
			port') baseline is represented for each port number bound to a
			target.
	If the DOTS client negotiated percentile values and units		If the DOTS client negotiated percentile values and units
	(Section 6.1), these negotiated values will be used instead of the		(Section 6.1), these negotiated values will be used instead of the
	default ones.		default ones.
	Total Connections Capacity: If the target is subjected to resource		Total connections capacity: If the target is subjected to resource
	consuming DDoS attacks, the following optional attributes for the		consuming DDoS attacks, the following optional attributes for the
	target per transport-protocol are useful to detect resource		target per transport-protocol are useful to detect resource
	consuming DDoS attacks:		consuming DDoS attacks:
	Total Connections Capacity:
	* 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 and embryonic connection is only possible in		finished. Embryonic connection is only possible in connection-
	connection-oriented transport protocols like TCP or SCTP.		oriented transport protocols like TCP or SCTP.
	* The maximum number of simultaneous embryonic connections that		* The maximum number of simultaneous embryonic connections that
	are allowed to the target per client.		are allowed to the target per client.
	* The maximum number of connections allowed per second to the		* The maximum number of connections allowed per second to the
	target.		target.
	* The maximum number of connections allowed per second to the		* The maximum number of connections allowed per second to the
	target per client.		target per client.
	* The maximum number of requests allowed per second to the		* The maximum number of requests allowed per second to the
	target.		target.
	* The maximum number of requests allowed per second to the target		* The maximum number of requests allowed per second to the target
	per client.		per client.
	* The maximum number of partial requests allowed per second to		* The maximum number of partial requests allowed per second to
	the target.		the target. Attacks relying upon partial requests create a
			connection with a target but do not send a complete 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 threshold is transport-protocol.		The aggregate per transport protocol is captured in 'total-
			connection-capacity', while port-specific capabilities are
			represented using 'total-connection-capacity-per-port'.
	The tree structure of the baseline is shown in Figure 18.		The tree structure of the baseline is shown in Figure 18.
	augment /ietf-signal:dots-signal/ietf-signal:message-type:		augment /ietf-signal:dots-signal/ietf-signal:message-type:
	+--:(telemetry-setup) {dots-telemetry}?		+--:(telemetry-setup) {dots-telemetry}?
			| ...
	| +--rw telemetry* [cuid tsid]		| +--rw telemetry* [cuid tsid]
	| +--rw cuid string		| +--rw cuid string
	| +--rw cdid? string		| +--rw cdid? string
	| +--rw tsid uint32		| +--rw tsid uint32
	| +--rw (setup-type)?		| +--rw (setup-type)?
	| +--:(telemetry-config)		| +--:(telemetry-config)
	| | ...		| | ...
	| +--:(pipe)		| +--:(pipe)
	| | ...		| | ...
	| +--:(baseline)		| +--:(baseline)
	| +--rw baseline* [id]		| +--rw baseline* [id]
	| +--rw id uint32		| +--rw id uint32
	| +--rw target-prefix* inet:ip-prefix		| +--rw target-prefix* inet:ip-prefix
	| +--rw target-port-range* [lower-port]		| +--rw target-port-range* [lower-port]
	| | +--rw lower-port inet:port-number		| | +--rw lower-port inet:port-number
	| | +--rw upper-port? inet:port-number		| | +--rw upper-port? inet:port-number
	| +--rw target-protocol* uint8		| +--rw target-protocol* uint8
	| +--rw target-fqdn* inet:domain-name		| +--rw target-fqdn* inet:domain-name
	| +--rw target-uri* inet:uri		| +--rw target-uri* inet:uri
	| +--rw total-traffic-normal-baseline* [unit protocol]		| +--rw alias-name* string
			| +--rw total-traffic-normal* [unit]
			| | +--rw unit unit
			| | +--rw low-percentile-g? yang:gauge64
			| | +--rw mid-percentile-g? yang:gauge64
			| | +--rw high-percentile-g? yang:gauge64
			| | +--rw peak-g? yang:gauge64
			| +--rw total-traffic-normal-per-protocol* [unit protocol]
	| | +--rw unit unit		| | +--rw unit unit
	| | +--rw protocol uint8		| | +--rw protocol uint8
	| | +--rw low-percentile-g? yang:gauge64		| | +--rw low-percentile-g? yang:gauge64
	| | +--rw mid-percentile-g? yang:gauge64		| | +--rw mid-percentile-g? yang:gauge64
	| | +--rw high-percentile-g? yang:gauge64		| | +--rw high-percentile-g? yang:gauge64
	| | +--rw peak-g? yang:gauge64		| | +--rw peak-g? yang:gauge64
			| +--rw total-traffic-normal-per-port* [unit port]
			| | +--rw port inet:port-number
			| | +--rw unit unit
			| | +--rw low-percentile-g? yang:gauge64
			| | +--rw mid-percentile-g? yang:gauge64
			| | +--rw high-percentile-g? yang:gauge64
			| | +--rw peak-g? yang:gauge64
	| +--rw total-connection-capacity* [protocol]		| +--rw total-connection-capacity* [protocol]
			| | +--rw protocol uint8
			| | +--rw connection? uint64
			| | +--rw connection-client? uint64
			| | +--rw embryonic? uint64
			| | +--rw embryonic-client? uint64
			| | +--rw connection-ps? uint64
			| | +--rw connection-client-ps? uint64
			| | +--rw request-ps? uint64
			| | +--rw request-client-ps? uint64
			| | +--rw partial-request-ps? uint64
			| | +--rw partial-request-client-ps? uint64
			| +--rw total-connection-capacity-per-port* [protocol port]
	| +--rw protocol uint8		| +--rw protocol uint8
			| +--rw port inet:port-number
	| +--rw connection? uint64		| +--rw connection? uint64
	| +--rw connection-client? uint64		| +--rw connection-client? uint64
	| +--rw embryonic? uint64		| +--rw embryonic? uint64
	| +--rw embryonic-client? uint64		| +--rw embryonic-client? uint64
	| +--rw connection-ps? uint64		| +--rw connection-ps? uint64
	| +--rw connection-client-ps? uint64		| +--rw connection-client-ps? uint64
	| +--rw request-ps? uint64		| +--rw request-ps? uint64
	| +--rw request-client-ps? uint64		| +--rw request-client-ps? uint64
	| +--rw partial-request-ps? uint64		| +--rw partial-request-ps? uint64
	| +--rw partial-request-client-ps? uint64		| +--rw partial-request-client-ps? uint64
	skipping to change at page 29, line 25 ¶		skipping to change at page 31, line 25 ¶
	{		{
	"ietf-dots-telemetry:telemetry-setup": {		"ietf-dots-telemetry:telemetry-setup": {
	"telemetry": [		"telemetry": [
	{		{
	"baseline": {		"baseline": {
	"id": 1,		"id": 1,
	"target-prefix": [		"target-prefix": [
	"2001:db8:6401::1/128",		"2001:db8:6401::1/128",
	"2001:db8:6401::2/128"		"2001:db8:6401::2/128"
	],		],
	"total-traffic-normal-baseline": {		"total-traffic-normal": [{
			"unit": "megabit-ps",
			"peak-g": "60"
			}]
			}
			}
			]
			}
			}
			Figure 19: PUT to Convey the DOTS Traffic Baseline
			The DOTS client may share protocol-specific baseline information
			(e.g., TCP and UDP) as shown in Figure 19.
			Header: PUT (Code=0.03)
			Uri-Path: ".well-known"
			Uri-Path: "dots"
			Uri-Path: "tm-setup"
			Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
			Uri-Path: "tsid=128"
			Content-Format: "application/dots+cbor"
			{
			"ietf-dots-telemetry:telemetry": {
			{
			"ietf-dots-telemetry:telemetry-setup": {
			"telemetry": [
			{
			"baseline": {
			"id": 1,
			"target-prefix": [
			"2001:db8:6401::1/128",
			"2001:db8:6401::2/128"
			],
			"total-traffic-normal-per-protocol": [
			{
	"unit": "megabit-ps",		"unit": "megabit-ps",
	"protocol": 6,		"protocol": 6,
	"peak-g": "50"		"peak-g": "50"
	}		},
			{
			"unit": "megabit-ps",
			"protocol": 17,
			"peak-g": "10"
			}
			]
	}		}
	}		}
	]		]
	}		}
	}		}
	Figure 19: PUT to Convey the DOTS Traffic Baseline		Figure 20: PUT to Convey the DOTS Traffic Baseline (2)
			The traffic baseline information should be updated to reflect
			legitimate overloads (e.g., flash crowds) to prevent unnecessary
			mitigation.
	6.3.2. Retrieve Installed Normal Traffic Baseline		6.3.2. Retrieve Installed Normal Traffic Baseline
	A GET request with 'tsid' Uri-Path parameter is used to retrieve a		A GET request with 'tsid' Uri-Path parameter is used to retrieve a
	specific installed DOTS client domain baseline traffic information.		specific installed DOTS client domain baseline traffic information.
	The same procedure as defined in (Section 6.1.3) is followed.		The same procedure as defined in (Section 6.1.3) is followed.
	To retrieve all baseline information bound to a DOTS client, the DOTS		To retrieve all baseline information bound to a DOTS client, the DOTS
	client proceeds as specified in Section 6.1.1.		client proceeds as specified in Section 6.1.1.
	skipping to change at page 30, line 11 ¶		skipping to change at page 33, line 26 ¶
	A DELETE request is used to delete the installed DOTS client domain		A DELETE request is used to delete the installed DOTS client domain
	normal traffic baseline. The same procedure as defined in		normal traffic baseline. The same procedure as defined in
	(Section 6.1.4) is followed.		(Section 6.1.4) is followed.
	6.4. Reset Installed Telemetry Setup		6.4. Reset Installed Telemetry Setup
	Upon bootstrapping (or reboot or any other event that may alter the		Upon bootstrapping (or reboot or any other event that may alter the
	DOTS client setup), a DOTS client MAY send a DELETE request to set		DOTS client setup), a DOTS client MAY send a DELETE request to set
	the telemetry parameters to default values. Such a request does not		the telemetry parameters to default values. Such a request does not
	include any 'tsid'. An example of such request is depicted in		include any 'tsid'. An example of such request is depicted in
	Figure 20.		Figure 21.
	Header: DELETE (Code=0.04)		Header: DELETE (Code=0.04)
	Uri-Path: ".well-known"		Uri-Path: ".well-known"
	Uri-Path: "dots"		Uri-Path: "dots"
	Uri-Path: "tm-setup"		Uri-Path: "tm-setup"
	Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"		Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
	Figure 20: 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 to convey 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-signal-channel]. The conflict cause		Section 4.4.1 of [I-D.ietf-dots-signal-channel]. The conflict cause
	can be set to one of these values:		can be set to one of these values:
	skipping to change at page 30, line 46 ¶		skipping to change at page 34, line 16 ¶
	There are two broad types of DDoS attacks, one is bandwidth consuming		There are two broad types of DDoS attacks, one is bandwidth consuming
	attack, the other is target resource consuming attack. This section		attack, the other is target resource consuming attack. This section
	outlines the set of DOTS telemetry attributes (Section 7.1) that		outlines the set of DOTS telemetry attributes (Section 7.1) that
	covers both the types of attacks. The ultimate objective of these		covers both the types of attacks. The ultimate objective of these
	attributes is to allow for the complete knowledge of attacks and the		attributes is to allow for the complete knowledge of attacks and the
	various particulars that can best characterize attacks.		various particulars that can best characterize attacks.
	The "ietf-dots-telemetry" YANG module (Section 9) augments the "ietf-		The "ietf-dots-telemetry" YANG module (Section 9) augments the "ietf-
	dots-signal" with a new message type called "telemetry". The tree		dots-signal" with a new message type called "telemetry". The tree
	structure of the "telemetry" message type is shown Figure 23.		structure of the "telemetry" message type is shown 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 with
	mitigation requests relying upon the target clause. In particular, a		mitigation requests relying upon the target clause. In particular, a
	telemetry PUT request sent after a mitigation request may include a		telemetry PUT request sent after a mitigation request may include a
	reference to that mitigation request ('mid-list') as shown in		reference to that mitigation request ('mid-list') as shown in
	Figure 21. An example illustrating requests correlation by means of		Figure 22. An example illustrating requests correlation by means of
	'target-prefix' is shown in Figure 22.		'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 21: 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 22: 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
	messages to the same peer more frequently than once every 'telemetry-		messages to the same peer more frequently than once every 'telemetry-
	notify-interval' (Section 6.1).		notify-interval' (Section 6.1).
	DOTS pre-or-ongoing-mitigation telemetry request and response		DOTS pre-or-ongoing-mitigation telemetry request and response
	messages MUST be marked as Non-Confirmable messages.		messages MUST be marked as Non-Confirmable messages.
	augment /ietf-signal:dots-signal/ietf-signal:message-type:		augment /ietf-signal:dots-signal/ietf-signal:message-type:
	+--:(telemetry-setup) {dots-telemetry}?		+--:(telemetry-setup) {dots-telemetry}?
	| +--rw telemetry* [cuid tsid]		| +--rw telemetry* [cuid tsid]
	| ...		| ...
	+--:(telemetry) {dots-telemetry}?		+--:(telemetry) {dots-telemetry}?
	+--rw pre-or-ongoing-mitigation* [cuid tmid]		+--rw pre-or-ongoing-mitigation* [cuid tmid]
	+--rw cuid string		+--rw cuid string
	+--rw cdid? string		+--rw cdid? string
	+--rw tmid uint32		+--rw tmid uint32
	+--rw target		+--rw target
	| ...		| ...
	+--rw total-traffic* [unit protocol]		+--rw total-traffic* [unit]
	| ...		| ...
	+--rw total-attack-traffic* [unit protocol]		+--rw total-traffic-protocol* [unit protocol]
			| ...
			+--rw total-traffic-port* [unit port]
			| ...
			+--rw total-attack-traffic* [unit]
			| ...
			+--rw total-attack-traffic-protocol* [unit protocol]
			| ...
			+--rw total-attack-traffic-port* [unit port]
	| ...		| ...
	+--rw total-attack-connection		+--rw total-attack-connection
	| ...		| ...
	+--rw attack-detail		+--rw total-attack-connection-port
			| ...
			+--rw attack-detail* [attack-id]
	...		...
	Figure 23: Telemetry Message Type Tree Structure		Figure 24: Telemetry Message Type Tree Structure
	7.1. Pre-or-Ongoing-Mitigation DOTS Telemetry Attributes		7.1. Pre-or-Ongoing-Mitigation DOTS Telemetry Attributes
	The description and motivation behind each attribute are presented in		The description and motivation behind each attribute are presented in
	Section 3. DOTS telemetry attributes are optionally signaled and		Section 3. DOTS telemetry attributes are optionally signaled and
	therefore MUST NOT be treated as mandatory fields in the DOTS signal		therefore MUST NOT be treated as mandatory fields in the DOTS signal
	channel protocol.		channel protocol.
	7.1.1. Target		7.1.1. Target
	A target resource (Figure 24) is identified using the attributes		A target resource (Figure 25) is identified using the attributes
	'target-prefix', 'target-port-range', 'target-protocol', 'target-		'target-prefix', 'target-port-range', 'target-protocol', 'target-
	fqdn', 'target-uri', or 'alias-name' defined in the base DOTS signal		fqdn', 'target-uri', or 'alias-name' defined in the base DOTS signal
	channel protocol.		channel protocol.
	+--:(telemetry) {dots-telemetry}?		+--:(telemetry) {dots-telemetry}?
	+--rw pre-or-ongoing-mitigation* [cuid tmid]		+--rw pre-or-ongoing-mitigation* [cuid tmid]
	+--rw cuid string		+--rw cuid string
	+--rw cdid? string		+--rw cdid? string
	+--rw tmid uint32		+--rw tmid uint32
	+--rw target		+--rw target
	| +--rw target-prefix* inet:ip-prefix		| +--rw target-prefix* inet:ip-prefix
	| +--rw target-port-range* [lower-port]		| +--rw target-port-range* [lower-port]
	| | +--rw lower-port inet:port-number		| | +--rw lower-port inet:port-number
	| | +--rw upper-port? inet:port-number		| | +--rw upper-port? inet:port-number
	| +--rw target-protocol* uint8		| +--rw target-protocol* uint8
	| +--rw target-fqdn* inet:domain-name		| +--rw target-fqdn* inet:domain-name
	| +--rw target-uri* inet:uri		| +--rw target-uri* inet:uri
	| +--rw alias-name* string		| +--rw alias-name* string
	| +--rw mid-list* uint32		| +--rw mid-list* uint32
	+--rw total-traffic* [unit protocol]		+--rw total-traffic* [unit]
	| ...		| ...
	+--rw total-attack-traffic* [unit protocol]		+--rw total-traffic-protocol* [unit protocol]
			| ...
			+--rw total-traffic-port* [unit port]
			| ...
			+--rw total-attack-traffic* [unit]
			| ...
			+--rw total-attack-traffic-protocol* [unit protocol]
			| ...
			+--rw total-attack-traffic-port* [unit port]
	| ...		| ...
	+--rw total-attack-connection		+--rw total-attack-connection
	| ...		| ...
	+--rw attack-detail		+--rw total-attack-connection-port
			| ...
			+--rw attack-detail* [attack-id]
	...		...
	Figure 24: 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 subjected to bandwidth consuming attack, 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 subjected to resource consuming DDoS attacks, the
	same attributes defined for Section 7.1.4 are applicable for		same attributes defined for Section 7.1.4 are applicable for
	representing the attack.		representing the attack.
	This is an optional sub-attribute.		This is an optional sub-attribute.
	7.1.2. Total Traffic		7.1.2. Total Traffic
	This attribute (Figure 25) conveys the percentile values of total		The 'total-traffic' attribute (Figure 26) conveys the percentile
	traffic observed during a DDoS attack.		values of total traffic observed during a DDoS attack. More granular
			total traffic can be conveyed in 'total-traffic-protocol' and 'total-
			traffic-port'.
	The total traffic is represented for a target and is transport-		The 'total-traffic-protocol' represents the total traffic for a
	protocol specific.		target and is transport-protocol specific.
			The 'total-traffic-port' represents the total traffic for a target
			per port number.
	+--:(telemetry) {dots-telemetry}?		+--:(telemetry) {dots-telemetry}?
	+--rw pre-or-ongoing-mitigation* [cuid tmid]		+--rw pre-or-ongoing-mitigation* [cuid tmid]
	+--rw cuid string		+--rw cuid string
	+--rw cdid? string		+--rw cdid? string
	+--rw tmid uint32		+--rw tmid uint32
	+--rw target		+--rw target
	| ...		| ...
	+--rw total-traffic* [unit protocol]		+--rw total-traffic* [unit]
	| +--rw unit unit		| +--rw unit unit
			| +--rw low-percentile-g? yang:gauge64
			| +--rw mid-percentile-g? yang:gauge64
			| +--rw high-percentile-g? yang:gauge64
			| +--rw peak-g? yang:gauge64
			+--rw total-traffic-protocol* [unit protocol]
	| +--rw protocol uint8		| +--rw protocol uint8
			| +--rw unit unit
	| +--rw low-percentile-g? yang:gauge64		| +--rw low-percentile-g? yang:gauge64
	| +--rw mid-percentile-g? yang:gauge64		| +--rw mid-percentile-g? yang:gauge64
	| +--rw high-percentile-g? yang:gauge64		| +--rw high-percentile-g? yang:gauge64
	| +--rw peak-g? yang:gauge64		| +--rw peak-g? yang:gauge64
	+--rw total-attack-traffic* [unit protocol]		+--rw total-traffic-port* [unit port]
			| +--rw port inet:port-number
			| +--rw unit unit
			| +--rw low-percentile-g? yang:gauge64
			| +--rw mid-percentile-g? yang:gauge64
			| +--rw high-percentile-g? yang:gauge64
			| +--rw peak-g? yang:gauge64
			+--rw total-attack-traffic* [unit]
			| ...
			+--rw total-attack-traffic-protocol* [unit protocol]
			| ...
			+--rw total-attack-traffic-port* [unit port]
	| ...		| ...
	+--rw total-attack-connection		+--rw total-attack-connection
	| ...		| ...
	+--rw attack-detail		+--rw total-attack-connection-port
			| ...
			+--rw attack-detail* [attack-id]
	...		...
	Figure 25: Total Traffic Tree Structure		Figure 26: Total Traffic Tree Structure
	7.1.3. Total Attack Traffic		7.1.3. Total Attack Traffic
	This attribute (Figure 26) conveys the total attack traffic		The 'total-attack-traffic' attribute (Figure 27) conveys the total
	identified by the DOTS client domain's DMS (or DDoS Detector).		attack traffic identified by the DOTS client domain's DMS (or DDoS
			Detector). More granular total traffic can be conveyed in 'total-
			attack-traffic-protocol' and 'total-attack-traffic-port'.
	The total attack traffic is represented for a target and is		The 'total-attack-traffic-protocol' represents the total attack
	transport-protocol specific.		traffic for a target and is transport-protocol specific.
			The 'total-attack-traffic-port' represents the total attack traffic
			for a target per port number.
	+--:(telemetry) {dots-telemetry}?		+--:(telemetry) {dots-telemetry}?
	+--rw pre-or-ongoing-mitigation* [cuid tmid]		+--rw pre-or-ongoing-mitigation* [cuid tmid]
	+--rw cuid string		+--rw cuid string
	+--rw cdid? string		+--rw cdid? string
	+--rw tmid uint32		+--rw tmid uint32
	+--rw target		+--rw target
	| ...		| ...
	+--rw total-traffic* [unit protocol]		+--rw total-traffic* [unit]
	| ...		| ...
	+--rw total-attack-traffic* [unit protocol]		+--rw total-traffic-protocol* [unit protocol]
			| ...
			+--rw total-traffic-port* [unit port]
			| ...
			+--rw total-attack-traffic* [unit]
	| +--rw unit unit		| +--rw unit unit
			| +--rw low-percentile-g? yang:gauge64
			| +--rw mid-percentile-g? yang:gauge64
			| +--rw high-percentile-g? yang:gauge64
			| +--rw peak-g? yang:gauge64
			+--rw total-attack-traffic-protocol* [unit protocol]
	| +--rw protocol uint8		| +--rw protocol uint8
			| +--rw unit unit
			| +--rw low-percentile-g? yang:gauge64
			| +--rw mid-percentile-g? yang:gauge64
			| +--rw high-percentile-g? yang:gauge64
			| +--rw peak-g? yang:gauge64
			+--rw total-attack-traffic-port* [unit port]
			| +--rw port inet:port-number
			| +--rw unit unit
	| +--rw low-percentile-g? yang:gauge64		| +--rw low-percentile-g? yang:gauge64
	| +--rw mid-percentile-g? yang:gauge64		| +--rw mid-percentile-g? yang:gauge64
	| +--rw high-percentile-g? yang:gauge64		| +--rw high-percentile-g? yang:gauge64
	| +--rw peak-g? yang:gauge64		| +--rw peak-g? yang:gauge64
	+--rw total-attack-connection		+--rw total-attack-connection
	| ...		| ...
	+--rw attack-detail		+--rw total-attack-connection-port
			| ...
			+--rw attack-detail* [attack-id]
	...		...
	Figure 26: 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, this		If the target is subjected to resource consuming DDoS attack, the
	attribute is used to convey the percentile values of total attack		'total-attack-connection' attribute is used to convey the percentile
	connections. The following optional sub-attributes for the target		values of total attack connections. The following optional sub-
	per transport-protocol are included to represent the attack		attributes for the target per transport-protocol are included to
	characteristics:		represent the attack 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
			'total-attack-connection-port' attribute.
	+--:(telemetry) {dots-telemetry}?		+--:(telemetry) {dots-telemetry}?
	+--rw pre-or-ongoing-mitigation* [cuid tmid]		+--rw pre-or-ongoing-mitigation* [cuid tmid]
	+--rw cuid string		+--rw cuid string
	+--rw cdid? string		+--rw cdid? string
	+--rw tmid uint32		+--rw tmid uint32
	+--rw target		+--rw target
	| ...		| ...
	+--rw total-traffic* [unit protocol]
	| ...
	+--rw total-attack-traffic* [unit protocol]
	| ...
	+--rw total-attack-connection		+--rw total-attack-connection
	| +--rw low-percentile-l* [protocol]		| +--rw low-percentile-l* [protocol]
	| | +--rw protocol uint8		| | +--rw protocol uint8
	| | +--rw connection? yang:gauge64		| | +--rw connection? yang:gauge64
	| | +--rw embryonic? yang:gauge64		| | +--rw embryonic? yang:gauge64
	| | +--rw connection-ps? yang:gauge64		| | +--rw connection-ps? yang:gauge64
	| | +--rw request-ps? yang:gauge64		| | +--rw request-ps? yang:gauge64
	| | +--rw partial-request-ps? yang:gauge64		| | +--rw partial-request-ps? yang:gauge64
	| +--rw mid-percentile-l* [protocol]		| +--rw mid-percentile-l* [protocol]
	| | +--rw protocol uint8		| | +--rw protocol uint8
	skipping to change at page 36, line 45 ¶		skipping to change at page 42, line 8 ¶
	| | +--rw connection-ps? yang:gauge64		| | +--rw connection-ps? yang:gauge64
	| | +--rw request-ps? yang:gauge64		| | +--rw request-ps? yang:gauge64
	| | +--rw partial-request-ps? yang:gauge64		| | +--rw partial-request-ps? yang:gauge64
	| +--rw peak-l* [protocol]		| +--rw peak-l* [protocol]
	| +--rw protocol uint8		| +--rw protocol uint8
	| +--rw connection? yang:gauge64		| +--rw connection? yang:gauge64
	| +--rw embryonic? yang:gauge64		| +--rw embryonic? yang:gauge64
	| +--rw connection-ps? yang:gauge64		| +--rw connection-ps? yang:gauge64
	| +--rw request-ps? yang:gauge64		| +--rw request-ps? yang:gauge64
	| +--rw partial-request-ps? yang:gauge64		| +--rw partial-request-ps? yang:gauge64
	+--rw attack-detail		+--rw total-attack-connection-port
			| +--rw low-percentile-l* [protocol port]
			| | +--rw port inet:port-number
			| | +--rw protocol uint8
			| | +--rw connection? yang:gauge64
			| | +--rw embryonic? yang:gauge64
			| | +--rw connection-ps? yang:gauge64
			| | +--rw request-ps? yang:gauge64
			| | +--rw partial-request-ps? yang:gauge64
			| +--rw mid-percentile-l* [protocol port]
			| | +--rw port inet:port-number
			| | +--rw protocol uint8
			| | +--rw connection? yang:gauge64
			| | +--rw embryonic? yang:gauge64
			| | +--rw connection-ps? yang:gauge64
			| | +--rw request-ps? yang:gauge64
			| | +--rw partial-request-ps? yang:gauge64
			| +--rw high-percentile-l* [protocol port]
			| | +--rw port inet:port-number
			| | +--rw protocol uint8
			| | +--rw connection? yang:gauge64
			| | +--rw embryonic? yang:gauge64
			| | +--rw connection-ps? yang:gauge64
			| | +--rw request-ps? yang:gauge64
			| | +--rw partial-request-ps? yang:gauge64
			| +--rw peak-l* [protocol port]
			| +--rw port inet:port-number
			| +--rw protocol uint8
			| +--rw connection? yang:gauge64
			| +--rw embryonic? yang:gauge64
			| +--rw connection-ps? yang:gauge64
			| +--rw request-ps? yang:gauge64
			| +--rw partial-request-ps? yang:gauge64
			+--rw attack-detail* [attack-id]
	...		...
	Figure 27: 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 28) is used to signal a set of details		This attribute (Figure 29) is used to signal a set of details
	characterizing an attack. The following optional sub-attributes		characterizing an attack. The following sub-attributes describing
	describing the on-going attack can be signal as attack details.		the on-going attack can be signal as attack details.
	id: Vendor ID is a security vendor's Enterprise Number as registered		id: Vendor ID is a security vendor's Enterprise Number as registered
	with IANA [Enterprise-Numbers]. It is a four-byte integer value.		with IANA [Enterprise-Numbers]. It is a four-byte integer value.
	attack-id: Unique identifier assigned by the vendor for the attack.		attack-id: Unique identifier assigned for the attack.
	attack-name: Textual representation of attack description. Natural		attack-name: Textual representation of attack description. Natural
	Language Processing techniques (e.g., word embedding) can possibly		Language Processing techniques (e.g., word embedding) can possibly
	be used to map the attack description to an attack type. Textual		be used to map the attack description to an attack type. Textual
	representation of attack solves two problems: (a) avoids the need		representation of attack solves two problems: (a) avoids the need
	to create mapping tables manually between vendors and (2) avoids		to create mapping tables manually between vendors and (2) avoids
	the need to standardize attack types which keep evolving.		the need to standardize attack types which keep evolving.
	attack-severity: Attack severity. These values are supported:		attack-severity: Attack severity. These values are supported:
	Emergency (1), critical (2), and alert (3).		emergency (1), critical (2), and alert (3).
	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 2.4.1 of [RFC7049]). The CBOR encoding is modified so		(Section 2.4.1 of [RFC7049]). 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-id attack ended. The attack end time		end-time: The time the attack-id attack ended. The attack end time
	is expressed in seconds relative to 1970-01-01T00:00Z in UTC time		is expressed in seconds relative to 1970-01-01T00:00Z in UTC time
	(Section 2.4.1 of [RFC7049]). The CBOR encoding is modified so		(Section 2.4.1 of [RFC7049]). 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.
	skipping to change at page 38, line 7 ¶		skipping to change at page 44, line 7 ¶
	If the target is subjected to bandwidth consuming attack, the		If the target is subjected to bandwidth consuming attack, the
	attack traffic from each of the top talkers is included ('total-		attack traffic from each of the top talkers is included ('total-
	attack-traffic', Section 7.1.3).		attack-traffic', Section 7.1.3).
	If the target is subjected to resource consuming DDoS attacks, the		If the target is subjected to resource consuming DDoS attacks, the
	same attributes defined for Section 7.1.4 are applicable for		same attributes defined for Section 7.1.4 are applicable for
	representing the attack per talker.		representing the attack per talker.
	+--:(telemetry) {dots-telemetry}?		+--:(telemetry) {dots-telemetry}?
	+--rw pre-or-ongoing-mitigation* [cuid tmid]		+--rw pre-or-ongoing-mitigation* [cuid tmid]
	+--rw cuid string		+--rw cuid string
	+--rw cdid? string		+--rw cdid? string
	+--rw tmid uint32		+--rw tmid uint32
	+--rw target		+--rw target
	| ...		| ...
	+--rw total-traffic* [unit protocol]		+--rw attack-detail* [attack-id]
	| ...
	+--rw total-attack-traffic* [unit protocol]
	| ...
	+--rw total-attack-connection
	| ...
	+--rw attack-detail
	+--rw id? uint32		+--rw id? uint32
	+--rw attack-id? string		+--rw attack-id string
	+--rw attack-name? string		+--rw attack-name? string
	+--rw attack-severity? attack-severity		+--rw attack-severity? attack-severity
	+--rw start-time? uint64		+--rw start-time? uint64
	+--rw end-time? uint64		+--rw end-time? uint64
	+--rw source-count
	| +--rw low-percentile-g? yang:gauge64
	| +--rw mid-percentile-g? yang:gauge64
	| +--rw high-percentile-g? yang:gauge64
	| +--rw peak-g? yang:gauge64
	+--rw top-talker		+--rw top-talker
	+--rw talker* [source-prefix]		+--rw talker* [source-prefix]
	+--rw spoofed-status? boolean		+--rw spoofed-status? boolean
	+--rw source-prefix inet:ip-prefix		+--rw source-prefix inet:ip-prefix
	+--rw source-port-range* [lower-port]		+--rw source-port-range* [lower-port]
	| +--rw lower-port inet:port-number		| +--rw lower-port inet:port-number
	| +--rw upper-port? inet:port-number		| +--rw upper-port? inet:port-number
	+--rw source-icmp-type-range* [lower-type]		+--rw source-icmp-type-range* [lower-type]
	| +--rw lower-type uint8		| +--rw lower-type uint8
	| +--rw upper-type? uint8		| +--rw upper-type? uint8
	skipping to change at page 39, line 4 ¶		skipping to change at page 44, line 42 ¶
	| +--rw mid-percentile-g? yang:gauge64		| +--rw mid-percentile-g? yang:gauge64
	| +--rw high-percentile-g? yang:gauge64		| +--rw high-percentile-g? yang:gauge64
	| +--rw peak-g? yang:gauge64		| +--rw peak-g? yang:gauge64
	+--rw total-attack-connection		+--rw total-attack-connection
	+--rw low-percentile-l* [protocol]		+--rw low-percentile-l* [protocol]
	| ...		| ...
	+--rw mid-percentile-l* [protocol]		+--rw mid-percentile-l* [protocol]
	| ...		| ...
	+--rw high-percentile-l* [protocol]		+--rw high-percentile-l* [protocol]
	| ...		| ...
	+--rw peak-l* [protocol]		+--rw peak-l* [protocol]
	...		...
	Figure 28: Attack Detail Tree Structure		Figure 29: Attack Detail Tree Structure
	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 uses PUT request 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 request is shown in
	Figure 29.		Figure 30.
	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"
	{		{
	"ietf-dots-telemetry:telemetry": {		"ietf-dots-telemetry:telemetry": {
	"pre-or-ongoing-mitigation": {		"pre-or-ongoing-mitigation": {
	"target": {		"target": {
	{		{
	"target-prefix": [		"target-prefix": [
	"2001:db8::1/128"		"2001:db8::1/128"
	]		],
	"total-attack-traffic": [		"total-attack-traffic-protocol": [
	{		{
	"protocol": 17,		"protocol": 17,
	"unit": "megabit-ps",		"unit": "megabit-ps",
	"mid-percentile-g": "900"		"mid-percentile-g": "900"
	}		}
	],		],
	"attack-detail": {		"attack-detail": [
	"start-time": "1957811234",		{
	"attack-severity": "emergency"		"attack-id": "an-id";
	}		"start-time": "1957811234",
			"attack-severity": "emergency"
			}
			]
	}		}
	}		}
	}		}
	}		}
	}		}
	Figure 29: PUT to Send Pre-or-Ongoing-Mitigation Telemetry		Figure 30: 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 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. 'tsid' 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).
	This is a mandatory attribute.		This is a mandatory attribute.
			'cuid' and 'tmid' MUST NOT appear in the PUT request message body.
	At least 'target' attribute and another pre-or-ongoing-mitigation		At least 'target' attribute and another pre-or-ongoing-mitigation
	attributes (Section 7.1) MUST be present in the PUT request. If only		attributes (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 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.
	skipping to change at page 40, line 44 ¶		skipping to change at page 46, line 38 ¶
	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 'tmids' 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'. The DOTS
	client may then delete 'tmids' that should not be active anymore.		client may then delete 'tmids' that should not be active anymore
			(Figure 31). Sending a DELETE with no 'tmid' indicates that all
			'tmids' must be deactivated (Figure 32).
			Header: DELETE (Code=0.04)
			Uri-Path: ".well-known"
			Uri-Path: "dots"
			Uri-Path: "tm"
			Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
			Uri-Path: "tmid=123"
			Figure 31: Delete a Pre-or-Ongoing-Mitigation Telemetry
			Header: DELETE (Code=0.04)
			Uri-Path: ".well-known"
			Uri-Path: "dots"
			Uri-Path: "tm"
			Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
			Figure 32: 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 (attack details, in particular) can
	also be signaled from DOTS servers to DOTS clients. For example, the		also be signaled from DOTS servers to DOTS clients. For example, the
	DOTS server co-located with a DDoS detector collects monitoring		DOTS server co-located with a DDoS detector collects monitoring
	information from the target network, identifies DDoS attack using		information from the target network, identifies DDoS attack using
	statistical analysis or deep learning techniques, and signals the		statistical analysis or deep learning techniques, and signals 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		operation 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 PUT request is shown in
	Figure 30. In order to avoid maintaining a long list of such		Figure 33. 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
			delete request is received from the same DOTS client to clear this
			pre-or-ongoing-mitigation telemetry.
			The relative order of two PUT requests carrying DOTS pre-or-ongoing-
			mitigation telemetry from a DOTS client is determined by comparing
			their respective 'tmid' values. If such two requests have
			overlapping 'target', the PUT request with higher numeric 'tmid'
			value will override the request with a lower numeric 'tmid' value.
			The overlapped lower numeric 'tmid' MUST be automatically deleted and
			no longer be available.
	Header: PUT (Code=0.03)		Header: PUT (Code=0.03)
	Uri-Path: ".well-known"		Uri-Path: ".well-known"
	Uri-Path: "dots"		Uri-Path: "dots"
	Uri-Path: "tm"		Uri-Path: "tm"
	Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"		Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
	Uri-Path: "tmid=123"		Uri-Path: "tmid=123"
	Content-Format: "application/dots+cbor"		Content-Format: "application/dots+cbor"
	{		{
	skipping to change at page 41, line 43 ¶		skipping to change at page 48, line 27 ¶
	{		{
	"target-prefix": [		"target-prefix": [
	"2001:db8::/32"		"2001:db8::/32"
	]		]
	}		}
	}		}
	}		}
	}		}
	}		}
	Figure 30: PUT to Request Pre-or-Ongoing-Mitigation Telemetry		Figure 33: 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.
	The DOTS client conveys the Observe Option set to '0' in the GET		The DOTS client conveys the Observe Option set to '0' in the GET
	request to receive asynchronous notifications carrying pre-or-		request to receive asynchronous notifications carrying pre-or-
	ongoing-mitigation telemetry data from the DOTS server. The GET		ongoing-mitigation telemetry data from the DOTS server. The GET
	request specify a 'tmid' (Figure 31) or not (Figure 32).		request specifies a 'tmid' (Figure 34) or not (Figure 35).
	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=123"		Uri-Path: "tmid=123"
	Observe: 0		Observe: 0
	Figure 31: GET to Subscribe to Telemetry Asynchronous Notifications		Figure 34: GET to Subscribe to Telemetry Asynchronous Notifications
	for a Specific 'tmid'		for a Specific 'tmid'
	Header: GET (Code=0.01)		Header: GET (Code=0.01)
	Uri-Path: ".well-known"		Uri-Path: ".well-known"
	Uri-Path: "dots"		Uri-Path: "dots"
	Uri-Path: "tm"		Uri-Path: "tm"
	Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"		Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
	Observe: 0		Observe: 0
	Figure 32: GET to Subscribe to Telemetry Asynchronous Notifications		Figure 35: 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 server by indicating one or more Uri-Query options in its
			GET request. A Uri-Query option can include the following
			parameters: target-prefix, lower-port, upper-port, target-protocol,
			target-fqdn, target-uri, alias-name. An example of request to
			subscribe to asynchronous UDP telemetry notifications is shown in
			Figure 36. This filter will be applied for all 'tmids'.
			Header: GET (Code=0.01)
			Uri-Path: ".well-known"
			Uri-Path: "dots"
			Uri-Path: "tm"
			Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
			Uri-Query: "target-protocol=17"
			Observe: 0
			Figure 36: GET Request to Receive Telemetry Asynchronous
			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 event if following similar considerations as in		client when an attack event is detected following similar
	Section 4.4.2.1 of [I-D.ietf-dots-signal-channel]. An example of a		considerations as in Section 4.4.2.1 of
	pre-or-ongoing-mitigation telemetry notification is shown in		[I-D.ietf-dots-signal-channel]. An example of a pre-or-ongoing-
	Figure 33.		mitigation telemetry notification is shown in Figure 37.
	{		{
	"ietf-dots-telemetry:telemetry": {		"ietf-dots-telemetry:telemetry": {
	"pre-or-ongoing-mitigation": {		"pre-or-ongoing-mitigation": {
	"target": {		"target": {
	{		{
	"tmid": 123,		"tmid": 123,
	"target-prefix": [		"target-prefix": [
	"2001:db8::1/128"		"2001:db8::1/128"
	]		],
			"target-protocol": [17],
	"total-attack-traffic": [		"total-attack-traffic": [
	{		{
	"protocol": 17,
	"unit": "megabit-ps",		"unit": "megabit-ps",
	"mid-percentile-g": "900"		"mid-percentile-g": "900"
	}		}
	],		],
	"attack-detail": {		"attack-detail": [
			{
			"attack-id": "an-id",
	"start-time": "1957818434",		"start-time": "1957818434",
	"attack-severity": "emergency"		"attack-severity": "emergency"
	}		}
			]
	}		}
	}		}
	}		}
	}		}
	}		}
	Figure 33: Message Body of a Pre-or-Ongoing-Mitigation Telemetry		Figure 37: 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-
			attack-traffic' attribute. It may includes more granular data when
			needed (that is, 'total-attack-traffic-protocol' and 'total-attack-
			traffic-port').
	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-talkers') for all targets of a domain, or when justified, send		'top-talkers') for all targets of a domain, or when justified, send
	specific information (e.g., 'top-talkers') per individual targets.		specific information (e.g., 'top-talkers') per individual targets.
	The DOTS client may log pre-or-ongoing-mitigation telemetry data with		The DOTS client may log pre-or-ongoing-mitigation telemetry data with
	an alert sent to an administrator or a network controller. The DOTS		an alert sent to an administrator or a network controller. The DOTS
	client may send a mitigation request if the attack cannot be handled		client may send a mitigation request if the attack cannot be handled
	locally.		locally.
			A DOTS client that is not interested to receive pre-or-ongoing-
			mitigation telemetry data for a target MUST send a delete request
			similar to the one depicted in Figure 31.
	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 5.3.4 of		efficacy updates to the server (Section 5.3.4 of
	[I-D.ietf-dots-signal-channel]).		[I-D.ietf-dots-signal-channel]).
	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 26.		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 augments the "mitigation-scope"		The "ietf-dots-telemetry" YANG module augments the "mitigation-scope"
	type message defined in "ietf-dots-signal" so that these attributes		type message defined in "ietf-dots-signal" so that these attributes
	can be signalled by a DOTS client in a mitigation efficacy update		can be signalled by a DOTS client in a mitigation efficacy update
	(Figure 34).		(Figure 38).
	augment /ietf-signal:dots-signal/ietf-signal:message-type		augment /ietf-signal:dots-signal/ietf-signal:message-type
	/ietf-signal:mitigation-scope/ietf-signal:scope:		/ietf-signal:mitigation-scope/ietf-signal:scope:
	+--rw total-attack-traffic* [unit] {dots-telemetry}?		+--rw total-attack-traffic* [unit] {dots-telemetry}?
	| ...		| ...
	+--rw attack-detail {dots-telemetry}?		+--rw attack-detail* [attack-id] {dots-telemetry}?
	+--rw id? uint32		+--rw id? uint32
	+--rw attack-id? string		+--rw attack-id string
	+--rw attack-name? string		+--rw attack-name? string
	+--rw attack-severity? attack-severity		+--rw attack-severity? attack-severity
	+--rw start-time? uint64		+--rw start-time? uint64
	+--rw end-time? uint64		+--rw end-time? uint64
	+--rw source-count		+--rw source-count
	| ...		| ...
	+--rw top-talker		+--rw top-talker
	...		...
	Figure 34: Telemetry Efficacy Update Tree Structure		Figure 38: Telemetry Efficacy Update Tree Structure
	In order to signal telemetry data in a mitigation efficacy update, it		In order to signal telemetry data in a mitigation efficacy update, it
	is RECOMMENDED that the DOTS client has already established a DOTS		is RECOMMENDED that the DOTS client has already established a DOTS
	telemetry setup session with the server in 'idle' time.		telemetry setup session with the server in 'idle' time.
	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: "mitigate"		Uri-Path: "mitigate"
	Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"		Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
	Uri-Path: "mid=123"		Uri-Path: "mid=123"
	If-Match:		If-Match:
	Content-Format: "application/dots+cbor"		Content-Format: "application/dots+cbor"
	{		{
	"ietf-dots-signal-channel:mitigation-scope": {		"ietf-dots-signal-channel:mitigation-scope": {
	"scope": [		"scope": [
	{		{
	"alias-name": [		"alias-name": [
	"myserver"		"https1",
			"https2"
	],		],
	"attack-status": "under-attack",		"attack-status": "under-attack",
	"ietf-dots-telemetry:total-attack-traffic": [		"ietf-dots-telemetry:total-attack-traffic": [
	{		{
	"ietf-dots-telemetry:unit": "megabit-ps",		"ietf-dots-telemetry:unit": "megabit-ps",
	"ietf-dots-telemetry:mid-percentile-g": "900"		"ietf-dots-telemetry:mid-percentile-g": "900"
	}		}
	]		]
	}		}
	]		]
	}		}
	}		}
	Figure 35: An Example of Mitigation Efficacy Update with Telemetry		Figure 39: 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 5.3.3 of [I-D.ietf-dots-signal-channel]). In		status update (Section 5.3.3 of [I-D.ietf-dots-signal-channel]). In
	particular, DOTS clients can receive asynchronous notifications of		particular, DOTS clients can receive asynchronous notifications of
	the attack details from DOTS servers using the Observe option defined		the attack details from DOTS servers using the Observe option defined
	skipping to change at page 46, line 18 ¶		skipping to change at page 53, line 22 ¶
	of attacks detected by each countermeasure MAY also be included. The		of attacks detected by each countermeasure MAY also be included. The
	same attributes defined for Section 7.1.5 are applicable for		same attributes defined for Section 7.1.5 are applicable for
	describing the attacks detected and mitigated.		describing the attacks detected and mitigated.
	The "ietf-dots-telemetry" YANG module (Section 9) augments the		The "ietf-dots-telemetry" YANG module (Section 9) augments the
	"mitigation-scope" type message defined in "ietf-dots-signal" with		"mitigation-scope" type message defined in "ietf-dots-signal" with
	telemetry data as depicted in following tree structure:		telemetry data as depicted in following tree structure:
	augment /ietf-signal:dots-signal/ietf-signal:message-type		augment /ietf-signal:dots-signal/ietf-signal:message-type
	/ietf-signal:mitigation-scope/ietf-signal:scope:		/ietf-signal:mitigation-scope/ietf-signal:scope:
	+--ro total-traffic* [unit protocol] {dots-telemetry}?		+--ro total-traffic* [unit] {dots-telemetry}?
	| +--ro unit unit		| +--ro unit unit
	| +--ro protocol uint8
	| +--ro low-percentile-g? yang:gauge64		| +--ro low-percentile-g? yang:gauge64
	| +--ro mid-percentile-g? yang:gauge64		| +--ro mid-percentile-g? yang:gauge64
	| +--ro high-percentile-g? yang:gauge64		| +--ro high-percentile-g? yang:gauge64
	| +--ro peak-g? yang:gauge64		| +--ro peak-g? yang:gauge64
	+--rw total-attack-traffic* [unit] {dots-telemetry}?		+--rw total-attack-traffic* [unit] {dots-telemetry}?
	| +--rw unit unit		| +--rw unit unit
	| +--rw low-percentile-g? yang:gauge64		| +--rw low-percentile-g? yang:gauge64
	| +--rw mid-percentile-g? yang:gauge64		| +--rw mid-percentile-g? yang:gauge64
	| +--rw high-percentile-g? yang:gauge64		| +--rw high-percentile-g? yang:gauge64
	| +--rw peak-g? yang:gauge64		| +--rw peak-g? yang:gauge64
	skipping to change at page 46, line 44 ¶		skipping to change at page 53, line 47 ¶
	| | +--ro embryonic? yang:gauge64		| | +--ro embryonic? yang:gauge64
	| | +--ro connection-ps? yang:gauge64		| | +--ro connection-ps? yang:gauge64
	| | +--ro request-ps? yang:gauge64		| | +--ro request-ps? yang:gauge64
	| | +--ro partial-request-ps? yang:gauge64		| | +--ro partial-request-ps? yang:gauge64
	| +--ro mid-percentile-c		| +--ro mid-percentile-c
	| | ...		| | ...
	| +--ro high-percentile-c		| +--ro high-percentile-c
	| | ...		| | ...
	| +--ro peak-c		| +--ro peak-c
	| ...		| ...
	+--rw attack-detail {dots-telemetry}?		+--rw attack-detail* [attack-id] {dots-telemetry}?
	+--rw id? uint32		+--rw id? uint32
	+--rw attack-id? string		+--rw attack-id string
	+--rw attack-name? string		+--rw attack-name? string
	+--rw attack-severity? attack-severity		+--rw attack-severity? attack-severity
	+--rw start-time? uint64		+--rw start-time? uint64
	+--rw end-time? uint64		+--rw end-time? uint64
	+--rw source-count		+--rw source-count
	| +--rw low-percentile-g? yang:gauge64		| +--rw low-percentile-g? yang:gauge64
	| +--rw mid-percentile-g? yang:gauge64		| +--rw mid-percentile-g? yang:gauge64
	| +--rw high-percentile-g? yang:gauge64		| +--rw high-percentile-g? yang:gauge64
	| +--rw peak-g? yang:gauge64		| +--rw peak-g? yang:gauge64
	+--rw top-talker		+--rw top-talker
	skipping to change at page 47, line 37 ¶		skipping to change at page 54, line 40 ¶
	| +--rw connection-ps? yang:gauge64		| +--rw connection-ps? yang:gauge64
	| +--rw request-ps? yang:gauge64		| +--rw request-ps? yang:gauge64
	| +--rw partial-request-ps? yang:gauge64		| +--rw partial-request-ps? yang:gauge64
	+--rw mid-percentile-c		+--rw mid-percentile-c
	| ...		| ...
	+--rw high-percentile-c		+--rw high-percentile-c
	| ...		| ...
	+--rw peak-c		+--rw peak-c
	...		...
	Figure 36 shows an example of an asynchronous notification of attack		Figure 40 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 percentile value 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", "https2"],
	"myserver"
	],
	"lifetime": 1600,		"lifetime": 1600,
	"status": "attack-successfully-mitigated",		"status": "attack-successfully-mitigated",
	"bytes-dropped": "134334555",		"bytes-dropped": "134334555",
	"bps-dropped": "43344",		"bps-dropped": "43344",
	"pkts-dropped": "333334444",		"pkts-dropped": "333334444",
	"pps-dropped": "432432",		"pps-dropped": "432432",
	"ietf-dots-telemetry:total-attack-traffic": [		"ietf-dots-telemetry:total-attack-traffic": [
	{		{
	"ietf-dots-telemetry:unit": "megabit-ps",		"ietf-dots-telemetry:unit": "megabit-ps",
	"ietf-dots-telemetry:mid-percentile-g": "900"		"ietf-dots-telemetry:mid-percentile-g": "900"
	}		}
	],		],
	"ietf-dots-telemetry::attack-detail": {		"ietf-dots-telemetry::attack-detail": [
			{
			"ietf-dots-telemetry:attack-id": "another-id",
	"ietf-dots-telemetry:source-count": {		"ietf-dots-telemetry:source-count": {
	"ietf-dots-telemetry:peak-g": "10000"		"ietf-dots-telemetry:peak-g": "10000"
			}
	}		}
	}		]
	}		}
	]		]
	}		}
	}		}
	Figure 36: Response Body of a Mitigation Status With Telemetry		Figure 40: Response Body of a Mitigation Status With Telemetry
	Attributes		Attributes
			DOTS clients can filter out the asynchronous notifications from the
			DOTS server by indicating one or more Uri-Query options in its GET
			request. A Uri-Query option can include the following parameters:
			target-prefix, lower-port, upper-port, target-protocol, target-fqdn,
			target-uri, alias-name. An example of request to subscribe to
			asynchronous notifications bound to the "http1" alias is shown in
			Figure 41.
			Header: GET (Code=0.01)
			Uri-Path: ".well-known"
			Uri-Path: "dots"
			Uri-Path: "mitigate"
			Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
			Uri-Path: "mid=12332"
			Uri-Query: "target-alias=https1"
			Observe: 0
			Figure 41: GET Request to Receive Asynchronous Notifications Filtered
			using Uri-Query
			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
			(Not Found) error response code. The DOTS server MUST NOT add a new
			observe entry if this query overlaps with an existing one.
	9. YANG Module		9. YANG Module
	This module uses types defined in [RFC6991] and [RFC8345].		This module uses types defined in [RFC6991] and [RFC8345].
	<CODE BEGINS> file "ietf-dots-telemetry@2020-03-27.yang"		<CODE BEGINS> file "ietf-dots-telemetry@2020-04-03.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 ietf-signal;		prefix ietf-signal;
	reference		reference
	"RFC SSSS: Distributed Denial-of-Service Open Threat		"RFC SSSS: Distributed Denial-of-Service Open Threat
	Signaling (DOTS) Signal Channel Specification";		Signaling (DOTS) Signal Channel Specification";
	skipping to change at page 50, line 10 ¶		skipping to change at page 57, line 42 ¶
	Redistribution and use in source and binary forms, with or		Redistribution and use in source and binary forms, with or
	without modification, is permitted pursuant to, and subject		without modification, is permitted pursuant to, and subject
	to the license terms contained in, the Simplified BSD License		to the license terms contained in, the Simplified BSD License
	set forth in Section 4.c of the IETF Trust's Legal Provisions		set forth in Section 4.c of the IETF Trust's Legal Provisions
	Relating to IETF Documents		Relating to IETF Documents
	(http://trustee.ietf.org/license-info).		(http://trustee.ietf.org/license-info).
	This version of this YANG module is part of RFC XXXX; see		This version of this YANG module is part of RFC XXXX; see
	the RFC itself for full legal notices.";		the RFC itself for full legal notices.";
	revision 2020-03-27 {		revision 2020-04-03 {
	description		description
	"Initial revision.";		"Initial revision.";
	reference		reference
	"RFC XXXX: Distributed Denial-of-Service Open Threat		"RFC XXXX: Distributed Denial-of-Service Open Threat
	Signaling (DOTS) Telemetry";		Signaling (DOTS) Telemetry";
	}		}
	feature dots-telemetry {		feature dots-telemetry {
	description		description
	"This feature means that the DOTS signal channel is able		"This feature means that the DOTS signal channel is able
	skipping to change at page 51, line 4 ¶		skipping to change at page 58, line 35 ¶
	}		}
	description		description
	"Enumeration for attack severity.";		"Enumeration for attack severity.";
	}		}
	typedef unit-type {		typedef unit-type {
	type enumeration {		type enumeration {
	enum packet-ps {		enum packet-ps {
	value 1;		value 1;
	description		description
	"Packets per second (PPS).";		"Packets per second (pps).";
	}		}
	enum bit-ps {		enum bit-ps {
	value 3;		value 2;
	description		description
	"Bit per Second (BPS).";		"Bits per Second (bit/s).";
	}		}
	enum byte-ps {		enum byte-ps {
	value 4;		value 3;
	description		description
	"Kilobyte per second.";		"Bytes per second (Byte/s).";
	}		}
	}		}
	description		description
	"Enumeration to indicate which unit type is used.";		"Enumeration to indicate which unit type is used.";
	}		}
	typedef unit {		typedef unit {
	type enumeration {		type enumeration {
	enum packet-ps {		enum packet-ps {
	value 1;		value 1;
	description		description
	"Packets per second (PPS).";		"Packets per second (pps).";
	}		}
	enum kilopacket-ps {		enum bit-ps {
	value 2;		value 2;
	description		description
	"Kilo packets per second (Kpps).";		"Bits per Second (bps).";
	}		}
	enum bit-ps {		enum byte-ps {
	value 3;		value 3;
	description		description
	"Bit per Second (BPS).";		"Bytes per second (Bps).";
	}		}
	enum byte-ps {		enum kilopacket-ps {
	value 4;		value 4;
	description		description
	"Kilobyte per second.";		"Kilo packets per second (kpps).";
	}		}
	enum kilobyte-ps {		enum kilobit-ps {
	value 5;		value 5;
	description		description
	"Kilobyte per second.";		"Kilobits per second (kbps).";
	}		}
	enum megabit-ps {		enum kilobyte-ps {
	value 6;		value 6;
	description		description
	"Megabit per second.";		"Kilobytes per second (kBps).";
	}		}
	enum megabyte-ps {		enum megapacket-ps {
	value 7;		value 7;
	description		description
	"Megabyte per second.";		"Mega packets per second (Mpps).";
	}		}
	enum gigabit-ps {		enum megabit-ps {
	value 8;		value 8;
	description		description
	"Gigabit per second.";		"Megabits per second (Mbps).";
	}		}
	enum gigabyte-ps {		enum megabyte-ps {
	value 9;		value 9;
	description		description
	"Gigabyte per second.";		"Megabytes per second (MBps).";
	}		}
	enum terabit-ps {		enum gigapacket-ps {
	value 10;		value 10;
	description		description
	"Terabit per second.";		"Giga packets per second (Gpps).";
	}		}
	enum terabyte-ps {		enum gigabit-ps {
	value 11;		value 11;
	description		description
	"Terabyte per second.";		"Gigabits per second (Gbps).";
			}
			enum gigabyte-ps {
			value 12;
			description
			"Gigabytes per second (GBps).";
			}
			enum terapacket-ps {
			value 13;
			description
			"Tera packets per second (Tpps).";
			}
			enum terabit-ps {
			value 14;
			description
			"Terabits per second (Tbps).";
			}
			enum terabyte-ps {
			value 15;
			description
			"Terabytes per second (TBps).";
	}		}
	}		}
	description		description
	"Enumeration to indicate which unit is used.";		"Enumeration to indicate which unit is used.";
	}		}
	typedef interval {		typedef interval {
	type enumeration {		type enumeration {
	enum hour {		enum hour {
	value 1;		value 1;
	skipping to change at page 54, line 34 ¶		skipping to change at page 62, line 37 ¶
	"Configuration of low, mid, and high percentile values.";		"Configuration of low, mid, and high 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 {
	type sample;		type sample;
	description		description
	"Defines the time distribution for measuring		"Defines the time distribution for measuring
	values that are used to compute percentiles..";		values that are used to compute percentiles.";
	}		}
	leaf low-percentile {		leaf low-percentile {
	type percentile;		type percentile;
	default "10.00";		default "10.00";
	description		description
	"Low percentile. If set to '0', this means low-percentiles		"Low percentile. If set to '0', this means low-percentiles
	are disabled.";		are disabled.";
	}		}
	leaf mid-percentile {		leaf mid-percentile {
	type percentile;		type percentile;
	skipping to change at page 55, line 49 ¶		skipping to change at page 64, line 4 ¶
	leaf peak-g {		leaf peak-g {
	type yang:gauge64;		type yang:gauge64;
	description		description
	"Peak";		"Peak";
	}		}
	}		}
	grouping unit-config {		grouping unit-config {
	description		description
	"Generic grouping for unit configuration.";		"Generic grouping for unit configuration.";
	list unit-config {		list unit-config {
	key "unit";		key "unit";
	description		description
	"Controls which units are allowed when sharing telemetry		"Controls which units are allowed when sharing telemetry
	data.";		data.";
	leaf unit {		leaf unit {
	type unit-type;		type unit-type;
	description		description
	"Can be pps, bit/ps, or byte/ps";		"Can be packet-ps, bit-ps, or byte-ps.";
	}		}
	leaf unit-status {		leaf unit-status {
	type boolean;		type boolean;
	description		description
	"Enable/disable the use of the measurement unit.";		"Enable/disable the use of the measurement unit.";
	}		}
	}		}
	}		}
	grouping traffic-unit {		grouping traffic-unit {
	skipping to change at page 56, line 37 ¶		skipping to change at page 64, line 41 ¶
	bytes per second. DOTS agents auto-scale to the appropriate		bytes per second. DOTS agents auto-scale to the appropriate
	units (e.g., megabit-ps, kilobit-ps).";		units (e.g., megabit-ps, kilobit-ps).";
	}		}
	uses percentile;		uses percentile;
	}		}
	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 measurement unit.";		a function of measurement unit.";
	leaf unit {
	type unit;
	description
	"The traffic can be measured using unit types: packets
	per second (PPS), Bits per Second (BPS), and/or
	bytes per second. DOTS agents auto-scale to the appropriate
	units (e.g., megabit-ps, kilobit-ps).";
	}
	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 field contains 6 for TCP,		For example, this field 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 percentile;		uses traffic-unit;
			}
			grouping traffic-unit-port {
			description
			"Grouping of traffic bound to port number as
			a function of measurement unit.";
			leaf port {
			type inet:port-number;
			description
			"Port number.";
			}
			uses traffic-unit;
	}		}
	grouping total-connection-capacity {		grouping total-connection-capacity {
	description		description
	"Total Connections Capacity. If the target is subjected		"Total Connections Capacity. If the target is subjected
	to resource consuming DDoS attack, these attributes are		to resource consuming DDoS attack, these attributes are
	useful to detect resource consuming DDoS attacks";		useful to detect resource consuming DDoS attacks";
	leaf connection {		leaf connection {
	type uint64;		type uint64;
	description		description
	skipping to change at page 58, line 34 ¶		skipping to change at page 66, line 40 ¶
	second to the target server.";		second to the target server.";
	}		}
	leaf partial-request-client-ps {		leaf partial-request-client-ps {
	type uint64;		type uint64;
	description		description
	"The maximum number of partial requests allowed per		"The maximum number of partial requests allowed per
	second to the target server per client.";		second to the target server per client.";
	}		}
	}		}
			grouping total-connection-capacity-protocol {
			description
			"Total Connections Capacity per protocol. If the target is subjected
			to resource consuming DDoS attack, these attributes are
			useful to detect resource consuming DDoS attacks";
			leaf protocol {
			type uint8;
			description
			"The transport protocol.
			Values are taken from the IANA Protocol Numbers registry:
			<https://www.iana.org/assignments/protocol-numbers/>.";
			}
			uses total-connection-capacity;
			}
	grouping connection {		grouping connection {
	description		description
	"A set of attributes which represent the attack		"A set of attributes which represent the attack
	characteristics";		characteristics";
	leaf connection {		leaf connection {
	type yang:gauge64;		type yang:gauge64;
	description		description
	"The number of simultaneous attack connections to		"The number of simultaneous attack connections to
	the target server.";		the target server.";
	}		}
	skipping to change at page 59, line 47 ¶		skipping to change at page 68, line 20 ¶
	"High percentile of attack connections.";		"High percentile of attack connections.";
	uses connection;		uses connection;
	}		}
	container peak-c {		container peak-c {
	description		description
	"Peak attack connections.";		"Peak attack connections.";
	uses connection;		uses connection;
	}		}
	}		}
			grouping connection-protocol {
			description
			"Total attack connections.";
			leaf protocol {
			type uint8;
			description
			"The transport protocol.
			Values are taken from the IANA Protocol Numbers registry:
			<https://www.iana.org/assignments/protocol-numbers/>.";
			}
			uses connection;
			}
			grouping connection-port {
			description
			"Total attack connections per port number.";
			leaf port {
			type inet:port-number;
			description
			"Port number.";
			}
			uses connection-protocol;
			}
	grouping connection-protocol-percentile {		grouping connection-protocol-percentile {
	description		description
	"Total attack connections.";		"Total attack connections.";
	list low-percentile-l {		list low-percentile-l {
	key "protocol";		key "protocol";
	description		description
	"Low percentile of attack connections.";		"Low percentile of attack connections.";
	leaf protocol {		uses connection-protocol;
	type uint8;
	description
	"The transport protocol.
	Values are taken from the IANA Protocol Numbers registry:
	<https://www.iana.org/assignments/protocol-numbers/>.";
	}
	uses connection;
	}		}
	list mid-percentile-l {		list mid-percentile-l {
	key "protocol";		key "protocol";
	description		description
	"Mid percentile of attack connections.";		"Mid percentile of attack connections.";
	leaf protocol {		uses connection-protocol;
	type uint8;
	description
	"The transport protocol.
	Values are taken from the IANA Protocol Numbers registry:
	<https://www.iana.org/assignments/protocol-numbers/>.";
	}
	uses connection;
	}		}
	list high-percentile-l {		list high-percentile-l {
	key "protocol";		key "protocol";
	description		description
	"High percentile of attack connections.";		"High percentile of attack connections.";
	leaf protocol {		uses connection-protocol;
	type uint8;
	description
	"The transport protocol.
	Values are taken from the IANA Protocol Numbers registry:
	<https://www.iana.org/assignments/protocol-numbers/>.";
	}
	uses connection;
	}		}
	list peak-l {		list peak-l {
	key "protocol";		key "protocol";
	description		description
	"Peak attack connections.";		"Peak attack connections.";
	leaf protocol {		uses connection-protocol;
	type uint8;
	description
	"The transport protocol.
	Values are taken from the IANA Protocol Numbers registry:
	<https://www.iana.org/assignments/protocol-numbers/>.";
	}
	uses connection;
	}		}
	}		}
			grouping connection-protocol-port-percentile {
			description
			"Total attack connections.";
			list low-percentile-l {
			key "protocol port";
			description
			"Low percentile of attack connections.";
			uses connection-port;
			}
			list mid-percentile-l {
			key "protocol port";
			description
			"Mid percentile of attack connections.";
			uses connection-port;
			}
			list high-percentile-l {
			key "protocol port";
			description
			"High percentile of attack connections.";
			uses connection-port;
			}
			list peak-l {
			key "protocol port";
			description
			"Peak attack connections.";
			uses connection-port;
			}
			}
	grouping attack-detail {		grouping attack-detail {
	description		description
	"Various information and details that describe the on-going		"Various information and details that describe the on-going
	attacks that needs to be mitigated by the DOTS server.		attacks that needs to be mitigated by the DOTS server.
	The attack details need to cover well-known and common attacks		The attack details need to cover well-known and common attacks
	(such as a SYN Flood) along with new emerging or vendor-specific		(such as a SYN Flood) along with new emerging or vendor-specific
	attacks.";		attacks.";
	leaf id {		leaf id {
	type uint32;		type uint32;
	description		description
	skipping to change at page 62, line 39 ¶		skipping to change at page 71, line 38 ¶
	"Port range. When only lower-port is		"Port range. When only lower-port is
	present, it represents a single port number.";		present, it represents a single port number.";
	leaf lower-port {		leaf lower-port {
	type inet:port-number;		type inet:port-number;
	mandatory true;		mandatory true;
	description		description
	"Lower port number of the port range.";		"Lower port number of the port range.";
	}		}
	leaf upper-port {		leaf upper-port {
	type inet:port-number;		type inet:port-number;
	must ". >= ../lower-port" {		must '. >= ../lower-port' {
	error-message		error-message
	"The upper port number must be greater than		"The upper port number must be greater than
	or equal to lower port number.";		or equal to lower port number.";
	}		}
	description		description
	"Upper port number of the port range.";		"Upper port number of the port range.";
	}		}
	}		}
	list source-icmp-type-range {		list source-icmp-type-range {
	key "lower-type";		key "lower-type";
	description		description
	"ICMP type range. When only lower-type is		"ICMP type range. When only lower-type is
	present, it represents a single ICMP type.";		present, it represents a single ICMP type.";
	leaf lower-type {		leaf lower-type {
	type uint8;		type uint8;
	mandatory true;		mandatory true;
	description		description
	"Lower ICMP type of the ICMP type range.";		"Lower ICMP type of the ICMP type range.";
	}		}
	leaf upper-type {		leaf upper-type {
	type uint8;		type uint8;
	must ". >= ../lower-type" {		must '. >= ../lower-type' {
	error-message		error-message
	"The upper ICMP type must be greater than		"The upper ICMP type must be greater than
	or equal to lower ICMP type.";		or equal to lower ICMP type.";
	}		}
	description		description
	"Upper type of the ICMP type range.";		"Upper type of the ICMP type range.";
	}		}
	}		}
	list total-attack-traffic {		list total-attack-traffic {
	key "unit";		key "unit";
	description		description
	"Total attack traffic issued from this source.";		"Total attack traffic issued from this source.";
	skipping to change at page 64, line 4 ¶		skipping to change at page 72, line 50 ¶
	"IPv4 or IPv6 prefix identifying the attacker(s).";		"IPv4 or IPv6 prefix identifying the attacker(s).";
	leaf spoofed-status {		leaf spoofed-status {
	type boolean;		type boolean;
	description		description
	"Indicates whether this address is spoofed.";		"Indicates whether this address is spoofed.";
	}		}
	leaf source-prefix {		leaf source-prefix {
	type inet:ip-prefix;		type inet:ip-prefix;
	description		description
	"IPv4 or IPv6 prefix identifying the attacker(s).";		"IPv4 or IPv6 prefix identifying the attacker(s).";
	}		}
	list source-port-range {		list source-port-range {
	key "lower-port";		key "lower-port";
	description		description
	"Port range. When only lower-port is		"Port range. When only lower-port is
	present, it represents a single port number.";		present, it represents a single port number.";
	leaf lower-port {		leaf lower-port {
	type inet:port-number;		type inet:port-number;
	mandatory true;		mandatory true;
	description		description
	"Lower port number of the port range.";		"Lower port number of the port range.";
	}		}
	leaf upper-port {		leaf upper-port {
	type inet:port-number;		type inet:port-number;
	must ". >= ../lower-port" {		must '. >= ../lower-port' {
	error-message		error-message
	"The upper port number must be greater than		"The upper port number must be greater than
	or equal to lower port number.";		or equal to lower port number.";
	}		}
	description		description
	"Upper port number of the port range.";		"Upper port number of the port range.";
	}		}
	}		}
	list source-icmp-type-range {		list source-icmp-type-range {
	key "lower-type";		key "lower-type";
	description		description
	"ICMP type range. When only lower-type is		"ICMP type range. When only lower-type is
	present, it represents a single ICMP type.";		present, it represents a single ICMP type.";
	leaf lower-type {		leaf lower-type {
	type uint8;		type uint8;
	mandatory true;		mandatory true;
	description		description
	"Lower ICMP type of the ICMP type range.";		"Lower ICMP type of the ICMP type range.";
	}		}
	leaf upper-type {		leaf upper-type {
	type uint8;		type uint8;
	must ". >= ../lower-type" {		must '. >= ../lower-type' {
	error-message		error-message
	"The upper ICMP type must be greater than		"The upper ICMP type must be greater than
	or equal to lower ICMP type.";		or equal to lower ICMP type.";
	}		}
	description		description
	"Upper type of the ICMP type range.";		"Upper type of the ICMP type range.";
	}		}
	}		}
	list total-attack-traffic {		list total-attack-traffic {
	key "unit";		key "unit";
	description		description
	"Total attack traffic issued from this source.";		"Total attack traffic issued from this source.";
	skipping to change at page 65, line 6 ¶		skipping to change at page 74, line 4 ¶
	}		}
	description		description
	"Upper type of the ICMP type range.";		"Upper type of the ICMP type range.";
	}		}
	}		}
	list total-attack-traffic {		list total-attack-traffic {
	key "unit";		key "unit";
	description		description
	"Total attack traffic issued from this source.";		"Total attack traffic issued from this source.";
	uses traffic-unit;		uses traffic-unit;
	}		}
	container total-attack-connection {		container total-attack-connection {
	description		description
	"Total attack connections issued from this source.";		"Total attack connections issued from this source.";
	uses connection-protocol-percentile;		uses connection-protocol-percentile;
	}		}
	}		}
	}		}
	grouping baseline {		grouping baseline {
	description		description
	"Grouping for the telemetry baseline.";		"Grouping for the telemetry baseline.";
	uses ietf-data:target;		uses ietf-data:target;
	leaf-list alias-name {		leaf-list alias-name {
	type string;		type string;
	description		description
	"An alias name that points to a resource.";		"An alias name that points to a resource.";
	}		}
	list total-traffic-normal-baseline {		list total-traffic-normal {
	key "unit protocol";		key "unit";
	description		description
	"Total traffic normal baselines.";		"Total traffic normal baselines.";
			uses traffic-unit;
			}
			list total-traffic-normal-per-protocol {
			key "unit protocol";
			description
			"Total traffic normal baselines per protocol.";
	uses traffic-unit-protocol;		uses traffic-unit-protocol;
	}		}
			list total-traffic-normal-per-port {
			key "unit port";
			description
			"Total traffic normal baselines per port number.";
			uses traffic-unit-port;
			}
	list total-connection-capacity {		list total-connection-capacity {
	key "protocol";		key "protocol";
	description		description
	"Total connection capacity.";		"Total connection capacity.";
	leaf protocol {		uses total-connection-capacity-protocol;
	type uint8;		}
			list total-connection-capacity-per-port {
			key "protocol port";
			description
			"Total connection capacity per port number.";
			leaf port {
			type inet:port-number;
	description		description
	"The transport protocol.		"The target port number.";
	Values are taken from the IANA Protocol Numbers registry:
	<https://www.iana.org/assignments/protocol-numbers/>.";
	}		}
	uses total-connection-capacity;		uses total-connection-capacity-protocol;
	}		}
	}		}
	grouping pre-or-ongoing-mitigation {		grouping pre-or-ongoing-mitigation {
	description		description
	"Grouping for the telemetry data.";		"Grouping for the telemetry data.";
	list total-traffic {		list total-traffic {
			key "unit";
			description
			"Total traffic.";
			uses traffic-unit;
			}
			list total-traffic-protocol {
	key "unit protocol";		key "unit protocol";
	description		description
	"Total traffic.";		"Total traffic.";
	uses traffic-unit-protocol;		uses traffic-unit-protocol;
	}		}
			list total-traffic-port {
			key "unit port";
			description
			"Total traffic per port.";
			uses traffic-unit-port;
			}
	list total-attack-traffic {		list total-attack-traffic {
			key "unit";
			description
			"Total attack traffic.";
			uses traffic-unit-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;		uses traffic-unit-protocol;
	}		}
			list total-attack-traffic-port {
			key "unit port";
			description
			"Total attack traffic per port.";
			uses traffic-unit-port;
			}
	container total-attack-connection {		container total-attack-connection {
	description		description
	"Total attack connections.";		"Total attack connections.";
	uses connection-protocol-percentile;		uses connection-protocol-percentile;
	}		}
	container attack-detail {		container total-attack-connection-port {
			description
			"Total attack connections.";
			uses connection-protocol-port-percentile;
			}
			list attack-detail {
			key "attack-id";
	description		description
	"Attack details.";		"Attack details.";
	uses attack-detail;		uses attack-detail;
	container top-talker {		container top-talker {
	description		description
	"Top attack sources.";		"Top attack sources.";
	uses top-talker;		uses top-talker;
	}		}
	}		}
	}		}
	augment "/ietf-signal:dots-signal/ietf-signal:message-type/"		augment "/ietf-signal:dots-signal/ietf-signal:message-type/"
	+ "ietf-signal:mitigation-scope/ietf-signal:scope" {		+ "ietf-signal:mitigation-scope/ietf-signal:scope" {
	if-feature "dots-telemetry";		if-feature "dots-telemetry";
	description		description
	"Extends mitigation scope with telemetry update data.";		"Extends mitigation scope with telemetry update data.";
	list total-traffic {		list total-traffic {
	key "unit protocol";		key "unit";
	config false;		config false;
	description		description
	"Total traffic.";		"Total traffic.";
	uses traffic-unit-protocol;		uses traffic-unit;
	}		}
	list total-attack-traffic {		list total-attack-traffic {
	key "unit";		key "unit";
	description		description
	"Total attack traffic.";		"Total attack traffic.";
	uses traffic-unit;		uses traffic-unit;
	}		}
	container total-attack-connection {		container total-attack-connection {
	config false;		config false;
	description		description
	skipping to change at page 67, line 4 ¶		skipping to change at page 76, line 48 ¶
	key "unit";		key "unit";
	description		description
	"Total attack traffic.";		"Total attack traffic.";
	uses traffic-unit;		uses traffic-unit;
	}		}
	container total-attack-connection {		container total-attack-connection {
	config false;		config false;
	description		description
	"Total attack connections.";		"Total attack connections.";
	uses connection-percentile;		uses connection-percentile;
	}		}
	container attack-detail {		list attack-detail {
			key "attack-id";
	description		description
	"Atatck details";		"Atatck details";
	uses attack-detail;		uses attack-detail;
	container top-talker {		container top-talker {
	description		description
	"Top attack sources.";		"Top attack sources.";
	uses top-talker-aggregate;		uses top-talker-aggregate;
	}		}
	}		}
	}		}
	augment "/ietf-signal:dots-signal/ietf-signal:message-type" {		augment "/ietf-signal:dots-signal/ietf-signal:message-type" {
	if-feature "dots-telemetry";		if-feature "dots-telemetry";
	description		description
	"Add a new choice to enclose telemetry data in DOTS		"Add a new choice to enclose telemetry data in DOTS
	signal channel.";		signal channel.";
	case telemetry-setup {		case telemetry-setup {
	description		description
	"Indicates the message is about telemetry.";		"Indicates the message is about telemetry.";
			container max-config-values {
			config false;
			description
			"Maximum acceptable configuration values.";
			uses percentile-config;
			leaf server-originated-telemetry {
			type boolean;
			description
			"Indicates whether the DOTS server can be instructed
			to send pre-or-ongoing-mitigation telemetry. If set to FALSE
			or the attribute is not present, this is an indication
			that the server does not support this capability.";
			}
			leaf telemetry-notify-interval {
			type uint32 {
			range "1 .. 3600";
			}
			must '. >= ../../min-config-values/telemetry-notify-interval' {
			error-message
			"The value must be greater than or equal
			to the telemetry-notify-interval in the min-config-values";
			}
			units "seconds";
			description
			"Minimum number of seconds between successive
			telemetry notifications.";
			}
			}
			container min-config-values {
			config false;
			description
			"Minimum acceptable configuration values.";
			uses percentile-config;
			leaf telemetry-notify-interval {
			type uint32 {
			range "1 .. 3600";
			}
			units "seconds";
			description
			"Minimum number of seconds between successive
			telemetry notifications.";
			}
			}
			container supported-units {
			config false;
			description
			"Supported units and default activation status.";
			uses unit-config;
			}
	list telemetry {		list telemetry {
	key "cuid tsid";		key "cuid tsid";
	description		description
	"The telemetry data per DOTS client.";		"The telemetry data per DOTS client.";
	leaf cuid {		leaf cuid {
	type string;		type string;
	description		description
	"A unique identifier that is		"A unique identifier that is
	generated by a DOTS client to prevent		generated by a DOTS client to prevent
	request collisions. It is expected that the		request collisions. It is expected that the
	skipping to change at page 68, line 38 ¶		skipping to change at page 79, line 36 ¶
	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.";
	}		}
	}		}
	container max-config-values {
	config false;
	description
	"Maximum acceptable configuration values.";
	uses percentile-config;
	// Check if this is right place for indciating this capability
	leaf server-originated-telemetry {
	type boolean;
	description
	"Indicates whether the DOTS server can be instructed
	to send pre-or-ongoing-mitigation telemetry. If set to FALSE
	or the attribute is not present, this is an indication
	that the server does not support this capability.";
	}
	leaf telemetry-notify-interval {
	type uint32 {
	range "1 .. 3600";
	}
	must '. >= ../../min-config-values/telemetry-notify-interval' {
	error-message
	"The value must be greater than or equal
	to the telemetry-notify-interval in the min-config-values";
	}
	units "seconds";
	description
	"Minimum number of seconds between successive
	telemetry notifications.";
	}
	}
	container min-config-values {
	config false;
	description
	"Minimum acceptable configuration values.";
	uses percentile-config;
	leaf telemetry-notify-interval {
	type uint32 {
	range "1 .. 3600";
	}
	units "seconds";
	description
	"Minimum number of seconds between successive
	telemetry notifications.";
	}
	}
	container supported-units {
	config false;
	description
	"Supported units and default activation status.";
	uses unit-config;
	}
	}		}
	case pipe {		case pipe {
	description		description
	"Total pipe capacity of a DOTS client domain";		"Total pipe capacity of a DOTS client domain";
	list total-pipe-capacity {		list total-pipe-capacity {
	key "link-id unit";		key "link-id unit";
	description		description
	"Total pipe capacity of a DOTS client domain.";		"Total pipe capacity of a DOTS client domain.";
	leaf link-id {		leaf link-id {
	type nt:link-id;		type nt:link-id;
	skipping to change at page 71, line 24 ¶		skipping to change at page 81, line 20 ¶
	gateway's client-facing-side to the gateway's		gateway's client-facing-side to the gateway's
	server-facing-side, and from the gateway's		server-facing-side, and from the gateway's
	server-facing-side to the DOTS server.		server-facing-side to the DOTS server.
	It may be used by the final DOTS server		It may be used by the final DOTS server
	for policy enforcement purposes.";		for policy enforcement purposes.";
	}		}
	leaf tmid {		leaf tmid {
	type uint32;		type uint32;
	description		description
	"An identifier to uniquely demux telemetry data send using		"An identifier to uniquely demux telemetry data sent
	the same message.";		using the same message.";
	}		}
	container target {		container target {
	description		description
	"Indicates the target.";		"Indicates the target.";
	uses ietf-data:target;		uses ietf-data:target;
	leaf-list alias-name {		leaf-list alias-name {
	type string;		type string;
	description		description
	"An alias name that points to a resource.";		"An alias name that points to a resource.";
	}		}
	leaf-list mid-list {		leaf-list mid-list {
	type uint32;		type uint32;
	description		description
	"Reference a list of associated mitigation requests.";		"Reference a list of associated mitigation requests.";
	}		}
	}		}
	uses pre-or-ongoing-mitigation;		uses pre-or-ongoing-mitigation;
	}		}
	}		}
	}		}
	}		}
	<CODE ENDS>		<CODE ENDS>
	10. YANG/JSON Mapping Parameters to CBOR		10. YANG/JSON Mapping Parameters to CBOR
	All DOTS telemetry parameters in the payload of the DOTS signal		All DOTS telemetry parameters in the payload of the DOTS signal
	channel MUST be mapped to CBOR types as shown in the following table:		channel MUST be mapped to CBOR types as shown in the following table:
	o Implementers may use the values in: https://github.com/boucadair/		o Implementers may use the values in: https://github.com/boucadair/
	draft-dots-telemetry/blob/master/mapping-table.txt		draft-dots-telemetry/blob/master/mapping-table.txt
	+----------------------+-------------+------+---------------+--------+		+----------------------+-------------+------+---------------+--------+
	| Parameter Name | YANG | CBOR | CBOR Major | JSON |		| Parameter Name | YANG | CBOR | CBOR Major | JSON |
	skipping to change at page 72, line 33 ¶		skipping to change at page 82, line 26 ¶
	| high-percentile | decimal64 |TBA5 | 6 tag 4 | |		| high-percentile | decimal64 |TBA5 | 6 tag 4 | |
	| | | | [-2, integer]| String |		| | | | [-2, integer]| String |
	| unit-config | list |TBA6 | 4 array | Array |		| unit-config | list |TBA6 | 4 array | Array |
	| unit | enumeration |TBA7 | 0 unsigned | String |		| unit | enumeration |TBA7 | 0 unsigned | String |
	| unit-status | boolean |TBA8 | 7 bits 20 | False |		| unit-status | boolean |TBA8 | 7 bits 20 | False |
	| | | | 7 bits 21 | True |		| | | | 7 bits 21 | True |
	| total-pipe-capability| list |TBA9 | 4 array | Array |		| total-pipe-capability| list |TBA9 | 4 array | Array |
	| link-id | string |TBA10 | 3 text string | String |		| link-id | string |TBA10 | 3 text string | String |
	| pre-or-ongoing- | list |TBA11 | 4 array | Array |		| pre-or-ongoing- | list |TBA11 | 4 array | Array |
	| mitigation | | | | |		| mitigation | | | | |
	| total-traffic- | | | | |		| total-traffic-normal | list |TBA12 | 4 array | Array |
	| normal-baseline | list |TBA12 | 4 array | Array |
	| low-percentile-g | yang:gauge64|TBA13 | 0 unsigned | String |		| low-percentile-g | yang:gauge64|TBA13 | 0 unsigned | String |
	| mid-percentile-g | yang:gauge64|TBA14 | 0 unsigned | String |		| mid-percentile-g | yang:gauge64|TBA14 | 0 unsigned | String |
	| high-percentile-g | yang:gauge64|TBA15 | 0 unsigned | String |		| high-percentile-g | yang:gauge64|TBA15 | 0 unsigned | String |
	| peak-g | yang:gauge64|TBA16 | 0 unsigned | String |		| peak-g | yang:gauge64|TBA16 | 0 unsigned | String |
	| total-attack-traffic | list |TBA17 | 4 array | Array |		| total-attack-traffic | list |TBA17 | 4 array | Array |
	| total-traffic | list |TBA18 | 4 array | Array |		| total-traffic | list |TBA18 | 4 array | Array |
	| total-connection- | | | | |		| total-connection- | | | | |
	| capacity | list |TBA19 | 4 array | Array |		| capacity | list |TBA19 | 4 array | Array |
	| connection | uint64 |TBA20 | 0 unsigned | String |		| connection | uint64 |TBA20 | 0 unsigned | String |
	| connection-client | uint64 |TBA21 | 0 unsigned | String |		| connection-client | uint64 |TBA21 | 0 unsigned | String |
	skipping to change at page 73, line 12 ¶		skipping to change at page 82, line 52 ¶
	| request-client-ps | uint64 |TBA27 | 0 unsigned | String |		| request-client-ps | uint64 |TBA27 | 0 unsigned | String |
	| partial-request-ps | uint64 |TBA28 | 0 unsigned | String |		| partial-request-ps | uint64 |TBA28 | 0 unsigned | String |
	| partial-request- | | | | |		| partial-request- | | | | |
	| client-ps | uint64 |TBA29 | 0 unsigned | String |		| client-ps | uint64 |TBA29 | 0 unsigned | String |
	| total-attack- | | | | |		| total-attack- | | | | |
	| connection | container |TBA30 | 5 map | Object |		| connection | container |TBA30 | 5 map | Object |
	| low-percentile-l | list |TBA31 | 4 array | Array |		| low-percentile-l | list |TBA31 | 4 array | Array |
	| mid-percentile-l | list |TBA32 | 4 array | Array |		| mid-percentile-l | list |TBA32 | 4 array | Array |
	| high-percentile-l | list |TBA33 | 4 array | Array |		| high-percentile-l | list |TBA33 | 4 array | Array |
	| peak-l | list |TBA34 | 4 array | Array |		| peak-l | list |TBA34 | 4 array | Array |
	| attack-detail | container |TBA35 | 5 map | Object |		| attack-detail | list |TBA35 | 4 array | Array |
	| id | uint32 |TBA36 | 0 unsigned | Number |		| id | uint32 |TBA36 | 0 unsigned | Number |
	| attack-id | string |TBA37 | 3 text string | String |		| attack-id | string |TBA37 | 3 text string | String |
	| attack-name | string |TBA38 | 3 text string | String |		| attack-name | string |TBA38 | 3 text string | String |
	| attack-severity | enumeration |TBA39 | 0 unsigned | String |		| attack-severity | enumeration |TBA39 | 0 unsigned | String |
	| start-time | uint64 |TBA40 | 0 unsigned | String |		| start-time | uint64 |TBA40 | 0 unsigned | String |
	| end-time | uint64 |TBA41 | 0 unsigned | String |		| end-time | uint64 |TBA41 | 0 unsigned | String |
	| source-count | container |TBA42 | 5 map | Object |		| source-count | container |TBA42 | 5 map | Object |
	| top-talker | container |TBA43 | 5 map | Object |		| top-talker | container |TBA43 | 5 map | Object |
	| spoofed-status | boolean |TBA44 | 7 bits 20 | False |		| spoofed-status | boolean |TBA44 | 7 bits 20 | False |
	| | | | 7 bits 21 | True |		| | | | 7 bits 21 | True |
	skipping to change at page 73, line 37 ¶		skipping to change at page 83, line 28 ¶
	| baseline | container |TBA49 | 5 map | Object |		| baseline | container |TBA49 | 5 map | Object |
	| current-config | container |TBA50 | 5 map | Object |		| current-config | container |TBA50 | 5 map | Object |
	| max-config-values | container |TBA51 | 5 map | Object |		| max-config-values | container |TBA51 | 5 map | Object |
	| min-config-values | container |TBA52 | 5 map | Object |		| min-config-values | container |TBA52 | 5 map | Object |
	| supported-units | container |TBA53 | 5 map | Object |		| supported-units | container |TBA53 | 5 map | Object |
	| server-originated- | boolean |TBA54 | 7 bits 20 | False |		| server-originated- | boolean |TBA54 | 7 bits 20 | False |
	| telemetry | | | 7 bits 21 | True |		| telemetry | | | 7 bits 21 | True |
	| telemetry-notify- | uint32 |TBA55 | 0 unsigned | Number |		| telemetry-notify- | uint32 |TBA55 | 0 unsigned | Number |
	| interval | | | | |		| interval | | | | |
	| tmid | uint32 |TBA56 | 0 unsigned | Number |		| tmid | uint32 |TBA56 | 0 unsigned | Number |
	| measurement-interval | identityref |TBA57 | 0 unsigned | String |		| measurement-interval | enumeration |TBA57 | 0 unsigned | String |
	| measurement-sample | identityref |TBA58 | 0 unsigned | String |		| measurement-sample | enumeration |TBA58 | 0 unsigned | String |
	| talker | list |TBA59 | 4 array | Array |		| talker | list |TBA59 | 4 array | Array |
	| source-prefix | inet: |TBA60 | 3 text string | String |		| source-prefix | inet: |TBA60 | 3 text string | String |
	| | ip-prefix | | | |		| | ip-prefix | | | |
	| mid-list | leaf-list |TBA61 | 4 array | Array |		| mid-list | leaf-list |TBA61 | 4 array | Array |
	| | uint32 | | 0 unsigned | Number |		| | uint32 | | 0 unsigned | Number |
	| source-port-range | list |TBA62 | 4 array | Array |		| source-port-range | list |TBA62 | 4 array | Array |
	| source-icmp-type- | list |TBA63 | 4 array | Array |		| source-icmp-type- | list |TBA63 | 4 array | Array |
	| range | | | | |		| range | | | | |
	| lower-type | uint8 |TBA64 | 0 unsigned | Number |		| lower-type | uint8 |TBA64 | 0 unsigned | Number |
	| upper-type | uint8 |TBA65 | 0 unsigned | Number |		| upper-type | uint8 |TBA65 | 0 unsigned | Number |
	| target | container |TBA66 | 5 map | Object |		| target | container |TBA66 | 5 map | Object |
	| capacity | uint64 |TBA67 | 0 unsigned | String |		| capacity | uint64 |TBA67 | 0 unsigned | String |
			| protocol | uint8 |TBA68 | 0 unsigned | Number |
			| total-traffic- | | | | |
			| normal-per-protocol | list |TBA69 | 4 array | Array |
			| total-traffic- | | | | |
			| normal-per-port | list |TBA70 | 4 array | Array |
			| total-connection- | | | | |
			| capacity-per-port | list |TBA71 | 4 array | Array |
			| total-traffic- | | | | |
			| -protocol | list |TBA72 | 4 array | Array |
			| total-traffic- port | list |TBA73 | 4 array | Array |
			| total-attack- | | | | |
			| traffic-protocol | list |TBA74 | 4 array | Array |
			| total-attack- | | | | |
			| traffic-port | list |TBA75 | 4 array | Array |
			| total-attack- | | | | |
			| connection-port | list |TBA76 | 4 array | Array |
			| port | inet: | | | |
			| | port-number|TBA77 | 0 unsigned | Number |
	| ietf-dots-telemetry: | | | | |		| ietf-dots-telemetry: | | | | |
	| telemetry-setup | container |TBA70 | 5 map | Object |		| telemetry-setup | container |TBA80 | 5 map | Object |
	| ietf-dots-telemetry: | | | | |		| ietf-dots-telemetry: | | | | |
	| total-traffic | list |TBA71 | 4 array | Array |		| total-traffic | list |TBA81 | 4 array | Array |
	| ietf-dots-telemetry: | | | | |		| ietf-dots-telemetry: | | | | |
	| unit | enumeration |TBA72 | 0 unsigned | String |		| unit | enumeration |TBA82 | 0 unsigned | String |
	| ietf-dots-telemetry: | | | | |		| ietf-dots-telemetry: | | | | |
	| low-percentile-g | yang:gauge64|TBA73 | 0 unsigned | String |		| low-percentile-g | yang:gauge64|TBA83 | 0 unsigned | String |
	| ietf-dots-telemetry: | | | | |		| ietf-dots-telemetry: | | | | |
	| mid-percentile-g | yang:gauge64|TBA74 | 0 unsigned | String |		| mid-percentile-g | yang:gauge64|TBA84 | 0 unsigned | String |
	| ietf-dots-telemetry: | | | | |		| ietf-dots-telemetry: | | | | |
	| high-percentile-g | yang:gauge64|TBA75 | 0 unsigned | String |		| high-percentile-g | yang:gauge64|TBA85 | 0 unsigned | String |
	| ietf-dots-telemetry: | | | | |		| ietf-dots-telemetry: | | | | |
	| peak-g | yang:gauge64|TBA76 | 0 unsigned | String |		| peak-g | yang:gauge64|TBA86 | 0 unsigned | String |
	| ietf-dots-telemetry: | | | | |		| ietf-dots-telemetry: | | | | |
	| total-attack-traffic | list |TBA77 | 4 array | Array |		| total-attack-traffic | list |TBA87 | 4 array | Array |
	| ietf-dots-telemetry: | | | | |		| ietf-dots-telemetry: | | | | |
	| total-attack- | | | | |		| total-attack- | | | | |
	| connection | container |TBA78 | 5 map | Object |		| connection | container |TBA88 | 5 map | Object |
	| ietf-dots-telemetry: | | | | |		| ietf-dots-telemetry: | | | | |
	| low-percentile-c | container |TBA79 | 5 map | Object |		| low-percentile-c | container |TBA89 | 5 map | Object |
	| ietf-dots-telemetry: | | | | |		| ietf-dots-telemetry: | | | | |
	| mid-percentile-c | container |TBA80 | 5 map | Object |		| mid-percentile-c | container |TBA90 | 5 map | Object |
	| ietf-dots-telemetry: | | | | |		| ietf-dots-telemetry: | | | | |
	| high-percentile-c | container |TBA81 | 5 map | Object |		| high-percentile-c | container |TBA91 | 5 map | Object |
	| ietf-dots-telemetry: | | | | |		| ietf-dots-telemetry: | | | | |
	| peak-c | container |TBA82 | 5 map | Object |		| peak-c | container |TBA92 | 5 map | Object |
	| ietf-dots-telemetry: | | | | |		| ietf-dots-telemetry: | | | | |
	| connection | uint64 |TBA83 | 0 unsigned | String |		| connection | uint64 |TBA93 | 0 unsigned | String |
	| ietf-dots-telemetry: | | | | |		| ietf-dots-telemetry: | | | | |
	| embryonic | uint64 |TBA84 | 0 unsigned | String |		| embryonic | uint64 |TBA94 | 0 unsigned | String |
	| ietf-dots-telemetry: | | | | |		| ietf-dots-telemetry: | | | | |
	| connection-ps | uint64 |TBA85 | 0 unsigned | String |		| connection-ps | uint64 |TBA95 | 0 unsigned | String |
	| ietf-dots-telemetry: | | | | |		| ietf-dots-telemetry: | | | | |
	| request-ps | uint64 |TBA86 | 0 unsigned | String |		| request-ps | uint64 |TBA96 | 0 unsigned | String |
	| ietf-dots-telemetry: | | | | |		| ietf-dots-telemetry: | | | | |
	| partial-request-ps | uint64 |TBA87 | 0 unsigned | String |		| partial-request-ps | uint64 |TBA97 | 0 unsigned | String |
	| ietf-dots-telemetry: | | | | |		| ietf-dots-telemetry: | | | | |
	| attack-detail | container |TBA88 | 5 map | Object |		| attack-detail | list |TBA98 | 4 array | Array |
	| ietf-dots-telemetry: | | | | |		| ietf-dots-telemetry: | | | | |
	| id | uint32 |TBA89 | 0 unsigned | Number |		| id | uint32 |TBA99 | 0 unsigned | Number |
	| ietf-dots-telemetry: | | | | |		| ietf-dots-telemetry: | | | | |
	| attack-id | string |TBA90 | 3 text string | String |		| attack-id | string |TBA100| 3 text string | String |
	| ietf-dots-telemetry: | | | | |		| ietf-dots-telemetry: | | | | |
	| attack-name | string |TBA91 | 3 text string | String |		| attack-name | string |TBA101| 3 text string | String |
	| ietf-dots-telemetry: | | | | |		| ietf-dots-telemetry: | | | | |
	| attack-severity | enumeration |TBA92 | 0 unsigned | String |		| attack-severity | enumeration |TBA102| 0 unsigned | String |
	| ietf-dots-telemetry: | | | | |		| ietf-dots-telemetry: | | | | |
	| start-time | uint64 |TBA93 | 0 unsigned | String |		| start-time | uint64 |TBA103| 0 unsigned | String |
	| ietf-dots-telemetry: | | | | |		| ietf-dots-telemetry: | | | | |
	| end-time | uint64 |TBA94 | 0 unsigned | String |		| end-time | uint64 |TBA104| 0 unsigned | String |
	| ietf-dots-telemetry: | | | | |		| ietf-dots-telemetry: | | | | |
	| source-count | container |TBA95 | 5 map | Object |		| source-count | container |TBA105| 5 map | Object |
	| ietf-dots-telemetry: | | | | |		| ietf-dots-telemetry: | | | | |
	| top-talker | container |TBA96 | 5 map | Object |		| top-talker | container |TBA106| 5 map | Object |
	| ietf-dots-telemetry: | | | | |		| ietf-dots-telemetry: | | | | |
	| spoofed-status | boolean |TBA97 | 7 bits 20 | False |		| spoofed-status | boolean |TBA107| 7 bits 20 | False |
	| | | | 7 bits 21 | True |		| | | | 7 bits 21 | True |
	| ietf-dots-telemetry: | | | | |		| ietf-dots-telemetry: | | | | |
	| talker | list |TBA98 | 4 array | Array |		| talker | list |TBA108| 4 array | Array |
	| ietf-dots-telemetry: | inet: |TBA99 | 3 text string | String |		| ietf-dots-telemetry: | inet: |TBA109| 3 text string | String |
	| source-prefix | ip-prefix | | | |		| source-prefix | ip-prefix | | | |
	| ietf-dots-telemetry: | | | | |		| ietf-dots-telemetry: | | | | |
	| source-port-range | list |TBA100| 4 array | Array |		| source-port-range | list |TBA110| 4 array | Array |
	| ietf-dots-telemetry: | | | | |		| ietf-dots-telemetry: | | | | |
	| lower-port | inet: | | | |		| lower-port | inet: | | | |
	| | port-number|TBA101| 0 unsigned | Number |		| | port-number|TBA111| 0 unsigned | Number |
	| ietf-dots-telemetry: | | | | |		| ietf-dots-telemetry: | | | | |
	| upper-port | inet: | | | |		| upper-port | inet: | | | |
	| | port-number|TBA102| 0 unsigned | Number |		| | port-number|TBA112| 0 unsigned | Number |
	| ietf-dots-telemetry: | | | | |		| ietf-dots-telemetry: | | | | |
	| source-icmp-type- | list |TBA103| 4 array | Array |		| source-icmp-type- | list |TBA113| 4 array | Array |
	| range | | | | |		| range | | | | |
	| ietf-dots-telemetry: | | | | |		| ietf-dots-telemetry: | | | | |
	| lower-type | uint8 |TBA104| 0 unsigned | Number |		| lower-type | uint8 |TBA114| 0 unsigned | Number |
	| ietf-dots-telemetry: | | | | |		| ietf-dots-telemetry: | | | | |
	| upper-type | uint8 |TBA105| 0 unsigned | Number |		| upper-type | uint8 |TBA115| 0 unsigned | Number |
	| ietf-dots-telemetry: | | | | |		| ietf-dots-telemetry: | | | | |
	| telemetry | container |TBA106| 5 map | Object |		| telemetry | container |TBA116| 5 map | Object |
	+----------------------+-------------+------+---------------+--------+		+----------------------+-------------+------+---------------+--------+
	11. IANA Considerationsr		11. IANA Considerationsr
	11.1. DOTS Signal Channel CBOR Key Values		11.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 available at		IANA "DOTS Signal Channel CBOR Key Values" registry available at
	https://www.iana.org/assignments/dots/dots.xhtml#dots-signal-channel-		https://www.iana.org/assignments/dots/dots.xhtml#dots-signal-channel-
	cbor-key-values.		cbor-key-values.
	skipping to change at page 76, line 22 ¶		skipping to change at page 86, line 31 ¶
	| low-percentile | TBA3 | 6tag4 | IESG | [RFCXXXX] |		| low-percentile | TBA3 | 6tag4 | IESG | [RFCXXXX] |
	| mid-percentile | TBA4 | 6tag4 | IESG | [RFCXXXX] |		| mid-percentile | TBA4 | 6tag4 | IESG | [RFCXXXX] |
	| high-percentile | TBA5 | 6tag4 | IESG | [RFCXXXX] |		| high-percentile | TBA5 | 6tag4 | IESG | [RFCXXXX] |
	| unit-config | TBA6 | 4 | IESG | [RFCXXXX] |		| unit-config | TBA6 | 4 | IESG | [RFCXXXX] |
	| unit | TBA7 | 0 | IESG | [RFCXXXX] |		| unit | TBA7 | 0 | IESG | [RFCXXXX] |
	| unit-status | TBA8 | 7 | IESG | [RFCXXXX] |		| unit-status | TBA8 | 7 | IESG | [RFCXXXX] |
	| total-pipe-capability| TBA9 | 4 | IESG | [RFCXXXX] |		| total-pipe-capability| TBA9 | 4 | IESG | [RFCXXXX] |
	| link-id | TBA10 | 3 | IESG | [RFCXXXX] |		| link-id | TBA10 | 3 | IESG | [RFCXXXX] |
	| pre-or-ongoing- | TBA11 | 4 | IESG | [RFCXXXX] |		| pre-or-ongoing- | TBA11 | 4 | IESG | [RFCXXXX] |
	| mitigation | | | | |		| mitigation | | | | |
	| total-traffic- | TBA12 | 4 | IESG | [RFCXXXX] |		| total-traffic-normal | TBA12 | 4 | IESG | [RFCXXXX] |
	| normal-baseline | | | | |
	| low-percentile-g | TBA13 | 0 | IESG | [RFCXXXX] |		| low-percentile-g | TBA13 | 0 | IESG | [RFCXXXX] |
	| mid-percentile-g | TBA14 | 0 | IESG | [RFCXXXX] |		| mid-percentile-g | TBA14 | 0 | IESG | [RFCXXXX] |
	| high-percentile-g | TBA15 | 0 | IESG | [RFCXXXX] |		| high-percentile-g | TBA15 | 0 | IESG | [RFCXXXX] |
	| peak-g | TBA16 | 0 | IESG | [RFCXXXX] |		| peak-g | TBA16 | 0 | IESG | [RFCXXXX] |
	| total-attack-traffic | TBA17 | 4 | IESG | [RFCXXXX] |		| total-attack-traffic | TBA17 | 4 | IESG | [RFCXXXX] |
	| total-traffic | TBA18 | 4 | IESG | [RFCXXXX] |		| total-traffic | TBA18 | 4 | IESG | [RFCXXXX] |
	| total-connection- | TBA19 | 4 | IESG | [RFCXXXX] |		| total-connection- | TBA19 | 4 | IESG | [RFCXXXX] |
	| capacity | | | | |		| capacity | | | | |
	| connection | TBA20 | 0 | IESG | [RFCXXXX] |		| connection | TBA20 | 0 | IESG | [RFCXXXX] |
	| connection-client | TBA21 | 0 | IESG | [RFCXXXX] |		| connection-client | TBA21 | 0 | IESG | [RFCXXXX] |
	skipping to change at page 76, line 49 ¶		skipping to change at page 87, line 9 ¶
	| request-client-ps | TBA27 | 0 | IESG | [RFCXXXX] |		| request-client-ps | TBA27 | 0 | IESG | [RFCXXXX] |
	| partial-request-ps | TBA28 | 0 | IESG | [RFCXXXX] |		| partial-request-ps | TBA28 | 0 | IESG | [RFCXXXX] |
	| partial-request- | TBA29 | 0 | IESG | [RFCXXXX] |		| partial-request- | TBA29 | 0 | IESG | [RFCXXXX] |
	| client-ps | | | | |		| client-ps | | | | |
	| total-attack- | TBA30 | 5 | IESG | [RFCXXXX] |		| total-attack- | TBA30 | 5 | IESG | [RFCXXXX] |
	| connection | | | | |		| connection | | | | |
	| low-percentile-l | TBA31 | 4 | IESG | [RFCXXXX] |		| low-percentile-l | TBA31 | 4 | IESG | [RFCXXXX] |
	| mid-percentile-l | TBA32 | 4 | IESG | [RFCXXXX] |		| mid-percentile-l | TBA32 | 4 | IESG | [RFCXXXX] |
	| high-percentile-l | TBA33 | 4 | IESG | [RFCXXXX] |		| high-percentile-l | TBA33 | 4 | IESG | [RFCXXXX] |
	| peak-l | TBA34 | 4 | IESG | [RFCXXXX] |		| peak-l | TBA34 | 4 | IESG | [RFCXXXX] |
	| attack-detail | TBA35 | 5 | IESG | [RFCXXXX] |		| attack-detail | TBA35 | 4 | IESG | [RFCXXXX] |
	| id | TBA36 | 0 | IESG | [RFCXXXX] |		| id | TBA36 | 0 | IESG | [RFCXXXX] |
	| attack-id | TBA37 | 3 | IESG | [RFCXXXX] |		| attack-id | TBA37 | 3 | IESG | [RFCXXXX] |
	| attack-name | TBA38 | 3 | IESG | [RFCXXXX] |		| attack-name | TBA38 | 3 | IESG | [RFCXXXX] |
	| attack-severity | TBA39 | 0 | IESG | [RFCXXXX] |		| attack-severity | TBA39 | 0 | IESG | [RFCXXXX] |
	| start-time | TBA40 | 0 | IESG | [RFCXXXX] |		| start-time | TBA40 | 0 | IESG | [RFCXXXX] |
	| end-time | TBA41 | 0 | IESG | [RFCXXXX] |		| end-time | TBA41 | 0 | IESG | [RFCXXXX] |
	| source-count | TBA42 | 5 | IESG | [RFCXXXX] |		| source-count | TBA42 | 5 | IESG | [RFCXXXX] |
	| top-talker | TBA43 | 5 | IESG | [RFCXXXX] |		| top-talker | TBA43 | 5 | IESG | [RFCXXXX] |
	| spoofed-status | TBA44 | 7 | IESG | [RFCXXXX] |		| spoofed-status | TBA44 | 7 | IESG | [RFCXXXX] |
	| low-percentile-c | TBA45 | 5 | IESG | [RFCXXXX] |		| low-percentile-c | TBA45 | 5 | IESG | [RFCXXXX] |
	skipping to change at page 77, line 31 ¶		skipping to change at page 87, line 40 ¶
	| 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 | 0 | IESG | [RFCXXXX] |
	| source-prefix | TBA60 | 0 | IESG | [RFCXXXX] |		| source-prefix | TBA60 | 0 | 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 | | | | |
	| lower-type | TBA64 | 0 | IESG | [RFCXXXX] |		| lower-type | TBA64 | 0 | IESG | [RFCXXXX] |
	| upper-type | TBA65 | 0 | IESG | [RFCXXXX] |		| upper-type | TBA65 | 0 | IESG | [RFCXXXX] |
	| target | TBA66 | 5 | IESG | [RFCXXXX] |		| target | TBA66 | 5 | IESG | [RFCXXXX] |
	| capacity | TBA67 | 0 | IESG | [RFCXXXX] |		| capacity | TBA67 | 0 | IESG | [RFCXXXX] |
	| ietf-dots-telemetry: | TBA70 | 5 | IESG | [RFCXXXX] |		| protocol | TBA68 | 0 | IESG | [RFCXXXX] |
			| total-traffic- | TBA69 | 4 | IESG | [RFCXXXX] |
			| normal-per-protocol | | | | |
			| total-traffic- | TBA70 | 4 | IESG | [RFCXXXX] |
			| normal-per-port | | | | |
			| total-connection- | TBA71 | 4 | IESG | [RFCXXXX] |
			| capacity-per-port | | | | |
			| total-traffic- | TBA72 | 4 | IESG | [RFCXXXX] |
			| -protocol | | | | |
			| total-traffic-port | TBA73 | 4 | IESG | [RFCXXXX] |
			| total-attack- | TBA74 | 4 | IESG | [RFCXXXX] |
			| traffic-protocol | | | | |
			| total-attack- | TBA75 | 4 | IESG | [RFCXXXX] |
			| traffic-port | | | | |
			| total-attack- | TBA76 | 4 | IESG | [RFCXXXX] |
			| connection-port | | | | |
			| port | TBA77 | 0 | IESG | [RFCXXXX] |
			| ietf-dots-telemetry: | TBA80 | 5 | IESG | [RFCXXXX] |
	| telemetry-setup | | | | |		| telemetry-setup | | | | |
	| ietf-dots-telemetry: | TBA71 | 0 | IESG | [RFCXXXX] |		| ietf-dots-telemetry: | TBA81 | 0 | IESG | [RFCXXXX] |
	| total-traffic | | | | |		| total-traffic | | | | |
	| ietf-dots-telemetry: | TBA72 | 0 | IESG | [RFCXXXX] |		| ietf-dots-telemetry: | TBA82 | 0 | IESG | [RFCXXXX] |
	| unit | | | | |		| unit | | | | |
	| ietf-dots-telemetry: | TBA73 | 0 | IESG | [RFCXXXX] |		| ietf-dots-telemetry: | TBA83 | 0 | IESG | [RFCXXXX] |
	| low-percentile-g | | | | |		| low-percentile-g | | | | |
	| ietf-dots-telemetry: | TBA74 | 0 | IESG | [RFCXXXX] |		| ietf-dots-telemetry: | TBA84 | 0 | IESG | [RFCXXXX] |
	| mid-percentile-g | | | | |		| mid-percentile-g | | | | |
	| ietf-dots-telemetry: | TBA75 | 0 | IESG | [RFCXXXX] |		| ietf-dots-telemetry: | TBA85 | 0 | IESG | [RFCXXXX] |
	| high-percentile-g | | | | |		| high-percentile-g | | | | |
	| ietf-dots-telemetry: | TBA76 | 0 | IESG | [RFCXXXX] |		| ietf-dots-telemetry: | TBA86 | 0 | IESG | [RFCXXXX] |
	| peak-g | | | | |		| peak-g | | | | |
	| ietf-dots-telemetry: | TBA77 | 0 | IESG | [RFCXXXX] |		| ietf-dots-telemetry: | TBA87 | 0 | IESG | [RFCXXXX] |
	| total-attack-traffic | | | | |		| total-attack-traffic | | | | |
	| ietf-dots-telemetry: | TBA78 | 0 | IESG | [RFCXXXX] |		| ietf-dots-telemetry: | TBA88 | 0 | IESG | [RFCXXXX] |
	| total-attack- | | | | |		| total-attack- | | | | |
	| connection | | | | |		| connection | | | | |
	| ietf-dots-telemetry: | TBA79 | 0 | IESG | [RFCXXXX] |		| ietf-dots-telemetry: | TBA89 | 0 | IESG | [RFCXXXX] |
	| low-percentile-c | | | | |		| low-percentile-c | | | | |
	| ietf-dots-telemetry: | TBA80 | 0 | IESG | [RFCXXXX] |		| ietf-dots-telemetry: | TBA90 | 0 | IESG | [RFCXXXX] |
	| mid-percentile-c | | | | |		| mid-percentile-c | | | | |
	| ietf-dots-telemetry: | TBA71 | 0 | IESG | [RFCXXXX] |		| ietf-dots-telemetry: | TBA91 | 0 | IESG | [RFCXXXX] |
	| high-percentile-c | | | | |		| high-percentile-c | | | | |
	| ietf-dots-telemetry: | TBA82 | 0 | IESG | [RFCXXXX] |		| ietf-dots-telemetry: | TBA92 | 0 | IESG | [RFCXXXX] |
	| peak-c | | | | |		| peak-c | | | | |
	| ietf-dots-telemetry: | TBA83 | 0 | IESG | [RFCXXXX] |		| ietf-dots-telemetry: | TBA93 | 0 | IESG | [RFCXXXX] |
	| connection | | | | |		| connection | | | | |
	| ietf-dots-telemetry: | TBA84 | 0 | IESG | [RFCXXXX] |		| ietf-dots-telemetry: | TBA94 | 0 | IESG | [RFCXXXX] |
	| embryonic | | | | |		| embryonic | | | | |
	| ietf-dots-telemetry: | TBA85 | 0 | IESG | [RFCXXXX] |		| ietf-dots-telemetry: | TBA95 | 0 | IESG | [RFCXXXX] |
	| connection-ps | | | | |		| connection-ps | | | | |
	| ietf-dots-telemetry: | TBA86 | 0 | IESG | [RFCXXXX] |		| ietf-dots-telemetry: | TBA96 | 0 | IESG | [RFCXXXX] |
	| request-ps | | | | |		| request-ps | | | | |
	| ietf-dots-telemetry: | TBA87 | 0 | IESG | [RFCXXXX] |		| ietf-dots-telemetry: | TBA97 | 0 | IESG | [RFCXXXX] |
	| partial-request-ps | | | | |		| partial-request-ps | | | | |
	| ietf-dots-telemetry: | TBA88 | 0 | IESG | [RFCXXXX] |		| ietf-dots-telemetry: | TBA98 | 4 | IESG | [RFCXXXX] |
	| attack-detail | | | | |		| attack-detail | | | | |
	| ietf-dots-telemetry: | TBA89 | 0 | IESG | [RFCXXXX] |		| ietf-dots-telemetry: | TBA99 | 0 | IESG | [RFCXXXX] |
	| id | | | | |		| id | | | | |
	| ietf-dots-telemetry: | TBA90 | 0 | IESG | [RFCXXXX] |		| ietf-dots-telemetry: | TBA100| 0 | IESG | [RFCXXXX] |
	| attack-id | | | | |		| attack-id | | | | |
	| ietf-dots-telemetry: | TBA91 | 0 | IESG | [RFCXXXX] |		| ietf-dots-telemetry: | TBA101| 0 | IESG | [RFCXXXX] |
	| attack-name | | | | |		| attack-name | | | | |
	| ietf-dots-telemetry: | TBA92 | 0 | IESG | [RFCXXXX] |		| ietf-dots-telemetry: | TBA102| 0 | IESG | [RFCXXXX] |
	| attack-severity | | | | |		| attack-severity | | | | |
	| ietf-dots-telemetry: | TBA93 | 0 | IESG | [RFCXXXX] |		| ietf-dots-telemetry: | TBA103| 0 | IESG | [RFCXXXX] |
	| start-time | | | | |		| start-time | | | | |
	| ietf-dots-telemetry: | TBA94 | 0 | IESG | [RFCXXXX] |		| ietf-dots-telemetry: | TBA104| 0 | IESG | [RFCXXXX] |
	| end-time | | | | |		| end-time | | | | |
	| ietf-dots-telemetry: | TBA95 | 0 | IESG | [RFCXXXX] |		| ietf-dots-telemetry: | TBA105| 0 | IESG | [RFCXXXX] |
	| source-count | | | | |		| source-count | | | | |
	| ietf-dots-telemetry: | TBA96 | 0 | IESG | [RFCXXXX] |		| ietf-dots-telemetry: | TBA106| 0 | IESG | [RFCXXXX] |
	| top-talker | | | | |		| top-talker | | | | |
	| ietf-dots-telemetry: | TBA97 | 0 | IESG | [RFCXXXX] |		| ietf-dots-telemetry: | TBA107| 0 | IESG | [RFCXXXX] |
	| spoofed-status | | | | |		| spoofed-status | | | | |
	| ietf-dots-telemetry: | TBA98 | 0 | IESG | [RFCXXXX] |		| ietf-dots-telemetry: | TBA108| 0 | IESG | [RFCXXXX] |
	| talker | | | | |		| talker | | | | |
	| ietf-dots-telemetry: | TBA99 | 0 | IESG | [RFCXXXX] |		| ietf-dots-telemetry: | TBA109| 0 | IESG | [RFCXXXX] |
	| source-prefix | | | | |		| source-prefix | | | | |
	| ietf-dots-telemetry: | | | | |		| ietf-dots-telemetry: | | | | |
	| source-port-range | TBA100| 4 | IESG | [RFCXXXX] |		| source-port-range | TBA110| 4 | IESG | [RFCXXXX] |
	| ietf-dots-telemetry: | | | | |		| ietf-dots-telemetry: | | | | |
	| lower-port | TBA101| 0 | IESG | [RFCXXXX] |		| lower-port | TBA111| 0 | IESG | [RFCXXXX] |
	| ietf-dots-telemetry: | | | | |		| ietf-dots-telemetry: | | | | |
	| upper-port | TBA102| 0 | IESG | [RFCXXXX] |		| upper-port | TBA112| 0 | IESG | [RFCXXXX] |
	| ietf-dots-telemetry: | | | | |		| ietf-dots-telemetry: | | | | |
	| source-icmp-type- | TBA103| 4 | IESG | [RFCXXXX] |		| source-icmp-type- | TBA113| 4 | IESG | [RFCXXXX] |
	| range | | | | |		| range | | | | |
	| ietf-dots-telemetry: | | | | |		| ietf-dots-telemetry: | | | | |
	| lower-type | TBA104| 0 | IESG | [RFCXXXX] |		| lower-type | TBA114| 0 | IESG | [RFCXXXX] |
	| ietf-dots-telemetry: | | | | |		| ietf-dots-telemetry: | | | | |
	| upper-type | TBA105| 0 | IESG | [RFCXXXX] |		| upper-type | TBA115| 0 | IESG | [RFCXXXX] |
	| ietf-dots-telemetry: | TBA106| 5 | IESG | [RFCXXXX] |		| ietf-dots-telemetry: | TBA116| 5 | IESG | [RFCXXXX] |
	| telemetry | | | | |		| telemetry | | | | |
	+----------------------+-------+-------+------------+---------------+		+----------------------+-------+-------+------------+---------------+
	11.2. DOTS Signal Channel Conflict Cause Codes		11.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 available at		Signal Channel Conflict Cause Codes" registry available at
	https://www.iana.org/assignments/dots/dots.xhtml#dots-signal-channel-		https://www.iana.org/assignments/dots/dots.xhtml#dots-signal-channel-
	conflict-cause-codes.		conflict-cause-codes.
	skipping to change at page 80, line 22 ¶		skipping to change at page 90, line 49 ¶
	o Pan Wei, Huawei, Email: william.panwei@huawei.com		o Pan Wei, Huawei, Email: william.panwei@huawei.com
	14. Acknowledgements		14. Acknowledgements
	The authors would like to thank Flemming Andreasen, Liang Xia, and		The authors would like to thank Flemming Andreasen, Liang Xia, and
	Kaname Nishizuka co-authors of https://tools.ietf.org/html/draft-		Kaname Nishizuka co-authors of https://tools.ietf.org/html/draft-
	doron-dots-telemetry-00 draft and everyone who had contributed to		doron-dots-telemetry-00 draft and everyone who had contributed to
	that document.		that document.
	Authors would like to thank Kaname Nishizuka, Jon Shallow, Wei Pan		The authors would like to thank Kaname Nishizuka, Jon Shallow, Wei
	and Yuuhei Hayashi for comments and review.		Pan and Yuuhei Hayashi for comments and review.
	15. References		15. References
	15.1. Normative References		15.1. Normative References
	[Enterprise-Numbers]		[Enterprise-Numbers]
	"Private Enterprise Numbers", 2005, <http://www.iana.org/		"Private Enterprise Numbers", 2005, <http://www.iana.org/
	assignments/enterprise-numbers.html>.		assignments/enterprise-numbers.html>.
	[I-D.ietf-dots-data-channel]		[I-D.ietf-dots-data-channel]
	skipping to change at page 81, line 47 ¶		skipping to change at page 92, line 27 ¶
	[RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in		[RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in
	the Constrained Application Protocol (CoAP)", RFC 7959,		the Constrained Application Protocol (CoAP)", RFC 7959,
	DOI 10.17487/RFC7959, August 2016,		DOI 10.17487/RFC7959, August 2016,
	<https://www.rfc-editor.org/info/rfc7959>.		<https://www.rfc-editor.org/info/rfc7959>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
			[RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N.,
			Ananthakrishnan, H., and X. Liu, "A YANG Data Model for
			Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March
			2018, <https://www.rfc-editor.org/info/rfc8345>.
	15.2. Informative References		15.2. Informative References
	[I-D.ietf-dots-multihoming]		[I-D.ietf-dots-multihoming]
	Boucadair, M., Reddy.K, T., and W. Pan, "Multi-homing		Boucadair, M., Reddy.K, 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-03 (work in progress), January 2020.		multihoming-03 (work in progress), January 2020.
	[I-D.ietf-dots-use-cases]		[I-D.ietf-dots-use-cases]
	Dobbins, R., Migault, D., Moskowitz, R., Teague, N., Xia,		Dobbins, R., Migault, D., Moskowitz, R., Teague, N., Xia,
	skipping to change at page 82, line 26 ¶		skipping to change at page 93, line 9 ¶
	[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>.
	[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>.
	[RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N.,
	Ananthakrishnan, H., and X. Liu, "A YANG Data Model for
	Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March
	2018, <https://www.rfc-editor.org/info/rfc8345>.
	[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>.
	Authors' Addresses		Authors' Addresses
	Mohamed Boucadair (editor)		Mohamed Boucadair (editor)
	Orange		Orange
	Rennes 35000		Rennes 35000
End of changes. 316 change blocks.
	586 lines changed or deleted		1023 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/