< draft-ietf-dots-telemetry-01.txt		draft-ietf-dots-telemetry-02.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: August 3, 2020 McAfee		Expires: August 10, 2020 McAfee
	E. Doron		E. Doron
	Radware Ltd.		Radware Ltd.
	M. Chen		M. Chen
	CMCC		CMCC
	January 31, 2020		February 7, 2020
	Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry		Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry
	draft-ietf-dots-telemetry-01		draft-ietf-dots-telemetry-02
	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.
	This document specifies the normal traffic baseline and attack		This document specifies the normal traffic baseline and attack
	traffic telemetry attributes a DOTS client can convey to its DOTS		traffic telemetry attributes a DOTS client can convey to its DOTS
	server in the mitigation request, the mitigation status telemetry		server in the mitigation request, the mitigation status telemetry
	attributes a DOTS server can communicate to a DOTS client, and the		attributes a DOTS server can communicate to a DOTS client, and the
	mitigation efficacy telemetry attributes a DOTS client can		mitigation efficacy telemetry attributes a DOTS client can
	skipping to change at page 1, line 44 ¶		skipping to change at page 1, line 44 ¶
	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 August 3, 2020.		This Internet-Draft will expire on August 10, 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 31 ¶		skipping to change at page 2, line 31 ¶
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. DOTS Telemetry: Overview and Purpose . . . . . . . . . . . . 6		3. DOTS Telemetry: Overview and Purpose . . . . . . . . . . . . 6
	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 . . . . . . . . . . . . . . . . . . . 10		4.5. Block-wise Transfer . . . . . . . . . . . . . . . . . . . 10
	4.6. YANG Considerations . . . . . . . . . . . . . . . . . . . 10		4.6. DOTS Multi-homing Considerations . . . . . . . . . . . . 10
	4.7. A Note About Examples . . . . . . . . . . . . . . . . . . 10		4.7. YANG Considerations . . . . . . . . . . . . . . . . . . . 10
	5. Telemetry Operation Paths . . . . . . . . . . . . . . . . . . 10		4.8. A Note About Examples . . . . . . . . . . . . . . . . . . 10
	6. DOTS Telemetry Setup and Configuration . . . . . . . . . . . 11		5. Telemetry Operation Paths . . . . . . . . . . . . . . . . . . 11
			6. DOTS Telemetry Setup Configuration . . . . . . . . . . . . . 12
	6.1. Telemetry Configuration . . . . . . . . . . . . . . . . . 12		6.1. Telemetry Configuration . . . . . . . . . . . . . . . . . 12
	6.1.1. Retrieve Current DOTS Telemetry Configuration . . . . 12		6.1.1. Retrieve Current DOTS Telemetry Configuration . . . . 12
	6.1.2. Convey DOTS Telemetry Configuration . . . . . . . . . 15		6.1.2. Convey DOTS Telemetry Configuration . . . . . . . . . 15
	6.1.3. Retrieve Installed DOTS Telemetry Configuration . . . 18		6.1.3. Retrieve Installed DOTS Telemetry Configuration . . . 18
	6.1.4. Delete DOTS Telemetry Configuration . . . . . . . . . 19		6.1.4. Delete DOTS Telemetry Configuration . . . . . . . . . 18
	6.2. Total Pipe Capacity . . . . . . . . . . . . . . . . . . . 19		6.2. Total Pipe Capacity . . . . . . . . . . . . . . . . . . . 19
	6.2.1. Convey DOTS Client Domain Pipe Capacity . . . . . . . 20		6.2.1. Convey DOTS Client Domain Pipe Capacity . . . . . . . 20
	6.2.2. Retrieve DOTS Client Domain Pipe Capacity . . . . . . 25		6.2.2. Retrieve DOTS Client Domain Pipe Capacity . . . . . . 25
	6.2.3. Delete DOTS Client Domain Pipe Capacity . . . . . . . 25		6.2.3. Delete DOTS Client Domain Pipe Capacity . . . . . . . 25
	6.3. Telemetry Baseline . . . . . . . . . . . . . . . . . . . 26		6.3. Telemetry Baseline . . . . . . . . . . . . . . . . . . . 26
	6.3.1. Convey DOTS Client Domain Baseline Information . . . 29		6.3.1. Convey DOTS Client Domain Baseline Information . . . 28
	6.3.2. Retrieve Normal Traffic Baseline . . . . . . . . . . 30		6.3.2. Retrieve Normal Traffic Baseline . . . . . . . . . . 29
	6.3.3. Retrieve Normal Traffic Baseline . . . . . . . . . . 30		6.3.3. Delete Normal Traffic Baseline . . . . . . . . . . . 29
	6.4. Reset Installed Telemetry Setup and Configuration . . . . 31		6.4. Reset Installed Telemetry Setup . . . . . . . . . . . . . 29
	6.5. Conflict with Other DOTS Clients of the Same Domain . . . 31		6.5. Conflict with Other DOTS Clients of the Same Domain . . . 30
	7. DOTS Telemetry from Clients to Servers . . . . . . . . . . . 31		7. DOTS Pre-mitigation Telemetry . . . . . . . . . . . . . . . . 30
	7.1. Pre-mitigation DOTS Telemetry Attributes . . . . . . . . 32		7.1. Pre-mitigation DOTS Telemetry Attributes . . . . . . . . 31
	7.1.1. Total Traffic . . . . . . . . . . . . . . . . . . . . 33		7.1.1. Target . . . . . . . . . . . . . . . . . . . . . . . 31
	7.1.2. Total Attack Traffic . . . . . . . . . . . . . . . . 34		7.1.2. Total Traffic . . . . . . . . . . . . . . . . . . . . 32
	7.1.3. Total Attack Connections . . . . . . . . . . . . . . 35		7.1.3. Total Attack Traffic . . . . . . . . . . . . . . . . 33
	7.1.4. Attack Details . . . . . . . . . . . . . . . . . . . 36		7.1.4. Total Attack Connections . . . . . . . . . . . . . . 34
	7.2. DOTS Client to Server Mitigation Efficacy DOTS Telemetry		7.1.5. Attack Details . . . . . . . . . . . . . . . . . . . 36
	Attributes . . . . . . . . . . . . . . . . . . . . . . . 39		7.2. From DOTS Clients to DOTS Servers . . . . . . . . . . . . 38
	7.3. Sample Examples . . . . . . . . . . . . . . . . . . . . . 40		7.3. From DOTS Servers to DOTS Client . . . . . . . . . . . . 39
	7.3.1. Single Pre-Mitigation . . . . . . . . . . . . . . . . 40		8. DOTS Telemetry Mitigation Status Update . . . . . . . . . . . 42
	7.3.2. Multiple Pre-Mitigations . . . . . . . . . . . . . . 40		8.1. DOTS Client to Server Mitigation Efficacy DOTS Telemetry
	7.3.3. Top-Talker of Targets . . . . . . . . . . . . . . . . 40		Attributes . . . . . . . . . . . . . . . . . . . . . . . 42
	7.3.4. Top-Talker of Each Target . . . . . . . . . . . . . . 40		8.2. DOTS Server to Client Mitigation Status DOTS Telemetry
	8. DOTS Telemetry from Servers to Clients . . . . . . . . . . . 40		Attributes . . . . . . . . . . . . . . . . . . . . . . . 43
	8.1. DOTS Server to Client Mitigation Status DOTS Telemetry		9. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 46
	Attributes . . . . . . . . . . . . . . . . . . . . . . . 40		10. YANG/JSON Mapping Parameters to CBOR . . . . . . . . . . . . 67
	8.1.1. Mitigation Status . . . . . . . . . . . . . . . . . . 42		11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 69
	8.2. DOTS Detector to Clients Detection Telemetry . . . . . . 43		11.1. DOTS Signal Channel CBOR Key Values . . . . . . . . . . 69
	9. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 43		11.2. DOTS Signal Channel Conflict Cause Codes . . . . . . . . 70
	10. YANG/JSON Mapping Parameters to CBOR . . . . . . . . . . . . 63		11.3. DOTS Signal Telemetry YANG Module . . . . . . . . . . . 71
	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 65		12. Security Considerations . . . . . . . . . . . . . . . . . . . 71
	11.1. DOTS Signal Channel CBOR Key Values . . . . . . . . . . 65		13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 71
	11.2. DOTS Signal Channel Conflict Cause Codes . . . . . . . . 66		14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 71
	11.3. DOTS Signal Telemetry YANG Module . . . . . . . . . . . 67		15. References . . . . . . . . . . . . . . . . . . . . . . . . . 72
	12. Security Considerations . . . . . . . . . . . . . . . . . . . 67		15.1. Normative References . . . . . . . . . . . . . . . . . . 72
	13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 67		15.2. Informative References . . . . . . . . . . . . . . . . . 73
	14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 67		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 74
	15. References . . . . . . . . . . . . . . . . . . . . . . . . . 68
	15.1. Normative References . . . . . . . . . . . . . . . . . . 68
	15.2. Informative References . . . . . . . . . . . . . . . . . 69
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 70
	1. Introduction		1. Introduction
	Distributed Denial of Service (DDoS) attacks have become more vicious		Distributed Denial of Service (DDoS) attacks have become more vicious
	and sophisticated in almost all aspects of their maneuvers and		and sophisticated in almost all aspects of their maneuvers and
	malevolent intentions. IT organizations and service providers are		malevolent intentions. IT organizations and service providers are
	facing DDoS attacks that fall into two broad categories: Network/		facing DDoS attacks that fall into two broad categories: Network/
	Transport layer attacks and Application layer attacks:		Transport layer attacks and Application layer attacks:
	o Network/Transport layer attacks target the victim's		o Network/Transport layer attacks target the victim's
	skipping to change at page 5, line 4 ¶		skipping to change at page 4, line 49 ¶
	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 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 the DOTS server. 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 abilities		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		In some deployments, DOTS clients can send mitigation hints derived
	from attack details to DOTS servers, with the full understanding that		from attack details to DOTS servers, with the full understanding that
	the DOTS server may ignore mitigation hints, as described in		the DOTS server may ignore mitigation hints, as described in
	skipping to change at page 6, line 43 ¶		skipping to change at page 6, line 43 ¶
	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 the DOTS server to share DOTS telemetry
	with the DOTS client.		with the DOTS client.
	Thus mutual sharing of information is crucial for "closing the		Thus mutual sharing of information is crucial for "closing the
	mitigation loop" between the DOTS client and server. For the server		mitigation loop" between the DOTS client and server. 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 the 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 client
	and server can be high-lighted, and maybe handled, using the DOTS		and server can be high-lighted, 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 potentially use DOTS telemetry as a
	feedback to automate various control and management activities		feedback to automate various control and management activities
	derived from ongoing information signaled.		derived from ongoing information signaled.
	skipping to change at page 8, line 21 ¶		skipping to change at page 8, line 21 ¶
	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 client
	behavior. Consequently, common global thresholds for attack		behavior. Consequently, common global thresholds for attack
	detection practically cannot be realized. Each DOTS client can have		detection practically cannot be realized. Each DOTS client can have
	its own levels of traffic and normal behavior. Without facilitating		its own levels of traffic and normal behavior. Without facilitating
	normal baseline signaling, it may be very difficult for DOTS servers		normal baseline signaling, it may be very difficult for DOTS servers
	in some cases to detect and mitigate the attacks accurately:		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 server's mitigators to calculate the normal baseline in cases
	they do not have any knowledge of the traffic beforehand.		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 protect 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. The DOTS client asks the DOTS server 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 client. In this case, it can be
	valuable to clients to signal to server the "Total pipe capacity",		valuable to clients to signal to server the "Total pipe capacity",
	which is the level of traffic the DOTS client domain can absorb from		which is the level of traffic the DOTS client domain can absorb from
	the upstream network. Dynamic updating of the condition of pipes		the upstream network. Dynamic updates of the condition of pipes
	between DOTS agents while they are under a DDoS attack is essential.		between DOTS agents while they are under a DDoS attack is essential.
	For example, for cases of multiple DOTS clients share the same		For example, where multiple DOTS clients share the same physical
	physical connectivity pipes. It is important to note, that the term		connectivity pipes. It is important to note, that the term "pipe"
	"pipe" noted here does not necessary represent physical pipe, but		noted here does not necessary represent physical pipe, but rather
	rather represents the current level of traffic client can observe		represents the maximum level of traffic that the DOTS client domain
	from server. The server should activate other mechanisms to ensure		can receive. The DOTS server should activate other mechanisms to
	it does not saturate the client's pipes unintentionally. The rate-		ensure it does not allow the client's pipes to be saturated
	limit action defined in [I-D.ietf-dots-data-channel] is a reasonable		unintentionally. The rate-limit action defined in
	candidate to achieve this objective; the client can ask for the type		[I-D.ietf-dots-data-channel] is a reasonable candidate to achieve
	of traffic (such as ICMP, UDP, TCP port number 80) it prefers to		this objective; the client can ask for the type of traffic (such as
	limit. The rate-limit action can be controlled via the signal-		ICMP, UDP, TCP port number 80) it prefers to limit. The rate-limit
	channel [I-D.ietf-dots-signal-filter-control] even when the pipe is		action can be controlled via the signal-channel
			[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 DOTS 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 service effectiveness. Bi-
	directional feedback between DOTS agents is required for the		directional feedback between DOTS agents is required for the
	increased awareness of each party, supporting superior and highly		increased awareness of each party, supporting superior and highly
	efficient attack mitigation service.		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.		collisions ('cuid').
	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.
	4.3. Empty URI Paths		4.3. Empty URI Paths
	Uri-Path parameters with empty values MUST NOT be present in DOTS		Uri-Path parameters and attributes with empty values MUST NOT be
	telemetry requests.		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
	client may control the selection of configuration and non-		client may control the selection of configuration and non-
	configuration data nodes when sending a GET request by means of the		configuration data nodes when sending a GET request by means of the
	'c' Uri-Query option and following the procedure specified in		'c' Uri-Query option and following the procedure specified in
	Section of 4.4.2 of [I-D.ietf-dots-signal-channel]. These		Section of 4.4.2 of [I-D.ietf-dots-signal-channel]. These
	considerations are not re-iterated in the following sections.		considerations are not re-iterated in the following sections.
	4.5. Block-wise Transfer		4.5. Block-wise Transfer
	DOTS clients can use Block-wise transfer [RFC7959] with the		DOTS clients can use Block-wise transfer [RFC7959] with the
	recommendation detailed in Section 4.4.2 of		recommendation detailed in Section 4.4.2 of
	[I-D.ietf-dots-signal-channel] to control the size of a response when		[I-D.ietf-dots-signal-channel] to control the size of a response when
	the data to be returned does not fit within a single datagram.		the data to be returned does not fit within a single datagram.
	DOTS clients can also use Block1 Option in a PUT request (see		DOTS clients can also use Block1 Option in a PUT request (see
	Section 2.5 of [RFC7959]).		Section 2.5 of [RFC7959]) to initiate large transfers, but these
			Block1 transfers will fail if the inbound "pipe" is running full, so
			consideration needs to be made to try to fit this PUT into a single
			transfer, or to separate out the PUT into several discrete PUTs where
			each of them fits into a single packet.
	o NOTE: Add more details.		4.6. DOTS Multi-homing Considerations
	4.6. YANG Considerations		Multi-homed DOTS clients are assumed to follow the recommendations in
			[I-D.ietf-dots-multihoming] to select which DOTS server to contact
			and which IP prefixes to include in a telemetry message to a given
			peer DOTS server. For example, if each upstream network exposes a
			DOTS server and the DOTS client maintains DOTS channels with all of
			them, only the information related to prefixes assigned by an
			upstream network to the DOTS client domain will be signaled via the
			DOTS channel established with the DOTS server of that upstream
			network. Considerations related to whether (and how) a DOTS client
			gleans some telemetry information (e.g., attack details) it receives
			from a first DOTS server and share it with a second DOTS server are
			implementation- and deployment-specific.
			4.7. YANG Considerations
	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.
	4.7. 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
	not aim to provide a comprehensive list of message examples.		not aim to provide a comprehensive list of message examples.
	The authoritative reference for validating telemetry messages is the		The authoritative reference for validating telemetry messages is the
	YANG module (Section 9) and the mapping table established in		YANG module (Section 9) and the mapping table established in
	Section 10.		Section 10.
	5. Telemetry Operation Paths		5. Telemetry Operation Paths
	As discussed in [I-D.ietf-dots-signal-channel], each DOTS operation		As discussed in [I-D.ietf-dots-signal-channel], each DOTS operation
	is indicated by a path-suffix that indicates the intended operation.		is indicated by a path-suffix that indicates the intended operation.
	The operation path is appended to the path-prefix to form the URI		The operation path is appended to the path-prefix to form the URI
	used with a CoAP request to perform the desired DOTS operation. The		used with a CoAP request to perform the desired DOTS operation. The
	following telemetry path-suffixes are defined (Table 1):		following telemetry path-suffixes are defined (Table 1):
	+-----------------+----------------+-------------+		+-----------------+----------------+-----------+
	| Operation | Operation Path | Details |		| Operation | Operation Path | Details |
	+-----------------+----------------+-------------+		+-----------------+----------------+-----------+
	| Telemetry Setup | /tm-setup | Section 6 |		| Telemetry Setup | /tm-setup | Section 6 |
	| Telemetry | /tm | Section 7.1 |		| Telemetry | /tm | Section 7 |
	+-----------------+----------------+-------------+		+-----------------+----------------+-----------+
	Table 1: DOTS Telemetry Operations		Table 1: DOTS Telemetry Operations
	Consequently, the "ietf-dots-telemetry" YANG module defined in this		Consequently, the "ietf-dots-telemetry" YANG module defined in this
	document augments the "ietf-dots-signal" with two new message types		document (Section 9) augments the "ietf-dots-signal" with two new
	called "telemetry-setup" and "telemetry". The tree structure of the		message types called "telemetry-setup" and "telemetry". The tree
	"telemetry-setup" message type is shown below (more details are		structure is shown in Figure 1 (more details are provided in the
	provided in the following sections about the exact structure of		following sections about the exact structure of "telemetry-setup" and
	"telemetry-setup" and "telemetry" message types).		"telemetry" message types).
	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 (setup-type)?		| +--rw (setup-type)?
	| +--:(telemetry-config)		| +--:(telemetry-config)
	| | ...		| | ...
	| +--:(pipe)		| +--:(pipe)
	| | ...		| | ...
	| +--:(baseline)		| +--:(baseline)
	| ...		| ...
	+--:(telemetry) {dots-telemetry}?		+--:(telemetry) {dots-telemetry}?
	...		...
	Figure 1: New DOTS Message Types (YANG Tree Structure)		Figure 1: New DOTS Message Types (YANG Tree Structure)
	6. DOTS Telemetry Setup and Configuration		6. DOTS Telemetry Setup Configuration
	In reference to Figure 1, a DOTS telemetry setup message MUST include		In reference to Figure 1, a DOTS telemetry setup message MUST include
	only telemetry-related configuration parameters (Section 6.1) or		only telemetry-related configuration parameters (Section 6.1) or
	information about DOTS client domain pipe capacity (Section 6.2) or		information about DOTS client domain pipe capacity (Section 6.2) or
	telemetry traffic baseline (Section 6.3). As such, requests that		telemetry traffic baseline (Section 6.3). As such, requests that
	include a mix of telemetry configuration, pipe capacity, or traffic		include a mix of telemetry configuration, pipe capacity, or traffic
	baseline MUST be rejected by DOTS servers with a 4.00 (Bad Request).		baseline MUST be rejected by DOTS servers with a 4.00 (Bad Request).
	A DOTS client can reset all installed DOTS telemetry setup and		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.
	DOTS telemetry setup and configuration request and response messages		DOTS telemetry setup configuration request and response messages are
	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
	o Measurement units		o Measurement units
	o Acceptable percentile values		o Acceptable percentile values
	o Telemetry notification interval		o Telemetry notification interval
	o Acceptable Server-initiated pre-mitigation telemetry		o Acceptable Server-originated telemetry
	Section 11.3 of [RFC2330] includes more details about computing		Section 11.3 of [RFC2330] includes more details about computing
	percentiles.		percentiles.
	6.1.1. Retrieve Current DOTS Telemetry Configuration		6.1.1. Retrieve Current DOTS Telemetry Configuration
	A GET request is used to obtain acceptable and current telemetry		A GET request is used to obtain acceptable and current telemetry
	configuration parameters on the DOTS server. This request may		configuration parameters on the DOTS server. This request may
	include a 'cdid' Path-URI when the request is relayed by a DOTS		include a 'cdid' Path-URI when the request is relayed by a DOTS
	gateway. An example of such request is depicted in Figure 2.		gateway. An example of such request is depicted in Figure 2.
	skipping to change at page 12, line 48 ¶		skipping to change at page 13, line 17 ¶
	Uri-Path: "dots"		Uri-Path: "dots"
	Uri-Path: "tm-setup"		Uri-Path: "tm-setup"
	Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"		Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
	Figure 2: GET to Retrieve Current and Acceptable DOTS Telemetry		Figure 2: GET to Retrieve Current and Acceptable DOTS Telemetry
	Configuration		Configuration
	Upon receipt of such request, the DOTS server replies with a 2.05		Upon receipt of such request, the DOTS server replies with a 2.05
	(Content) response that conveys the current and telemetry parameters		(Content) response that conveys the current and telemetry parameters
	acceptable by the DOTS server. The tree structure of the response		acceptable by the DOTS server. The tree structure of the response
	message body is provided in Figure 3. Note that the response		message body is provided in Figure 3. Note that the response also
	includes also any pipe (Section 6.2) and baseline information		includes any pipe (Section 6.2) and baseline information
	(Section 6.3) maintained by the DOTS server for this DOTS client.		(Section 6.3) maintained by the DOTS server for this DOTS client.
	DOTS servers that support the capability of sending pre-mitigation		DOTS servers that support the capability of sending pre-mitigation
	telemetry information to DOTS clients (Section 8) sets 'server-		telemetry information to DOTS clients (Section 8.2) sets 'server-
	initiated-telemetry' under 'max-config-values' to 'true' ('false' is		originated-telemetry' under 'max-config-values' to 'true' ('false' is
	used otherwise). If 'server-initiated-telemetry' is not present in a		used otherwise). If 'server-originated-telemetry' is not present in
	response, this is equivalent to receiving a request with 'server-		a response, this is equivalent to receiving a request with 'server-
	initiated-telemetry'' set to 'false'.		originated-telemetry'' 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}?
	| +--rw telemetry* [cuid tsid]		| +--rw telemetry* [cuid tsid]
	| ...		| ...
	| +--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
	| | | | +--rw unit-status? boolean		| | | | +--rw unit-status? boolean
	| | | +--rw server-initiated-telemetry? boolean		| | | +--rw server-originated-telemetry? boolean
	| | | +--rw telemetry-notify-interval? uint32		| | | +--rw telemetry-notify-interval? uint32
	| | +--ro max-config-values		| | +--ro max-config-values
	| | | +--ro measurement-interval? interval		| | | +--ro measurement-interval? interval
	| | | +--ro measurement-sample? sample		| | | +--ro measurement-sample? sample
	| | | +--ro low-percentile? percentile		| | | +--ro low-percentile? percentile
	| | | +--ro mid-percentile? percentile		| | | +--ro mid-percentile? percentile
	| | | +--ro high-percentile? percentile		| | | +--ro high-percentile? percentile
	| | | +--ro server-initiated-telemetry? boolean		| | | +--ro server-originated-telemetry? boolean
	| | | +--ro telemetry-notify-interval? uint32		| | | +--ro telemetry-notify-interval? uint32
	| | +--ro min-config-values		| | +--ro min-config-values
	| | | +--ro measurement-interval? interval		| | | +--ro measurement-interval? interval
	| | | +--ro measurement-sample? sample		| | | +--ro measurement-sample? sample
	| | | +--ro low-percentile? percentile		| | | +--ro low-percentile? percentile
	| | | +--ro mid-percentile? percentile		| | | +--ro mid-percentile? percentile
	| | | +--ro high-percentile? percentile		| | | +--ro high-percentile? percentile
	| | | +--ro telemetry-notify-interval? uint32		| | | +--ro telemetry-notify-interval? uint32
	| | +--ro supported-units		| | +--ro supported-units
	| | +--ro unit-config* [unit]		| | +--ro unit-config* [unit]
	| | +--ro unit unit		| | +--ro unit unit
	| | +--ro unit-status? boolean		| | +--ro unit-status? boolean
	| +--:(pipe)		| +--:(pipe)
	| ...		| ...
	| +--:(baseline)		| +--:(baseline)
	| ...		| ...
	+--:(telemetry) {dots-telemetry}?		+--:(telemetry) {dots-telemetry}?
	+--rw pre-mitigation* [cuid id]		+--rw pre-mitigation* [cuid tmid]
	...		...
	Figure 3: Telemetry Configuration Tree Structure		Figure 3: Telemetry Configuration Tree Structure
	6.1.2. Convey DOTS Telemetry Configuration		6.1.2. Convey DOTS Telemetry Configuration
	PUT request is used to convey the configuration parameters for the		PUT request is used to convey the configuration parameters for the
	telemetry data (e.g., low, mid, or high percentile values). For		telemetry data (e.g., low, mid, or high percentile values). For
	example, a DOTS client may contact its DOTS server to change the		example, a DOTS client may contact its DOTS server to change the
	default percentile values used as baseline for telemetry data.		default percentile values used as baseline for telemetry data.
	skipping to change at page 15, line 24 ¶		skipping to change at page 15, line 24 ¶
	Header: PUT (Code=0.03)		Header: PUT (Code=0.03)
	Uri-Path: ".well-known"		Uri-Path: ".well-known"
	Uri-Path: "dots"		Uri-Path: "dots"
	Uri-Path: "tm-setup"		Uri-Path: "tm-setup"
	Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"		Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
	Uri-Path: "tsid=123"		Uri-Path: "tsid=123"
	Content-Format: "application/dots+cbor"		Content-Format: "application/dots+cbor"
	{		{
	"ietf-dots-signal-channel:telemetry-setup": {		"ietf-dots-telemetry:telemetry-setup": {
	"telemetry": [		"telemetry": [
	{		{
	"current-config": {		"current-config": {
	"low-percentile": 5.00,		"low-percentile": 5.00,
	"mid-percentile": 65.00,		"mid-percentile": 65.00,
	"high-percentile": 95.00		"high-percentile": 95.00
	}		}
	}		}
	]		]
	}		}
	}		}
	Figure 4: PUT to Convey the DOTS Telemetry Configuration		Figure 4: PUT to Convey the DOTS Telemetry Configuration
	'cuid' is a mandatory Uri-Path parameter for PUT requests.		'cuid' is a mandatory Uri-Path parameter for PUT requests.
	The following additional Uri-Path parameter is defined:		The following additional Uri-Path parameter is defined:
	tsid: Telemetry Setup Identifier is an identifier for the DOTS		tsid: Telemetry Setup Identifier is an identifier for the DOTS
	telemetry setup and configuration data represented as an		telemetry setup configuration data represented as an integer.
	integer. This identifier MUST be generated by DOTS clients.		This identifier MUST be generated by DOTS clients. 'tsid'
	'tsid' values MUST increase monotonically (when a new PUT is		values MUST increase monotonically (when a new PUT is generated
	generated by a DOTS client to convey new configuration		by a DOTS client to convey new configuration parameters for the
	parameters for the telemetry).		telemetry).
	This is a mandatory attribute.		This is a mandatory attribute.
	At least one configurable attribute MUST be present in the PUT		At least one configurable attribute MUST be present in the PUT
	request.		request.
	Attributes and Uri-Path parameters with empty values MUST NOT be
	present in a request and render the entire request invalid.
	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 available at the DOTS server.		and no longer be available at the DOTS server.
	The DOTS server indicates the result of processing the PUT request		The DOTS server indicates the result of processing the PUT request
	using the following response codes:		using the following response codes:
	o If the request is missing a mandatory attribute, does not include		o If the request is missing a mandatory attribute, does not include
	'cuid' or 'tsid' Uri-Path parameters, or contains one or more		'cuid' or 'tsid' Uri-Path parameters, or contains one or more
	invalid or unknown parameters, 4.00 (Bad Request) MUST be returned		invalid or unknown parameters, 4.00 (Bad Request) MUST be returned
	in the response.		in the response.
	o If the DOTS server does not find the 'tsid' parameter value		o If the DOTS server does not find the 'tsid' parameter value
	skipping to change at page 16, line 43 ¶		skipping to change at page 16, line 40 ¶
	has accepted the updated configuration parameters, 2.04 (Changed)		has accepted the updated configuration parameters, 2.04 (Changed)
	MUST be returned in the response.		MUST be returned in the response.
	o If any of the enclosed configurable attribute values are not		o If any of the enclosed configurable attribute values are not
	acceptable to the DOTS server (Section 6.1.1), 4.22 (Unprocessable		acceptable to the DOTS server (Section 6.1.1), 4.22 (Unprocessable
	Entity) MUST be returned in the response.		Entity) MUST be returned in the response.
	The DOTS client may re-try and send the PUT request with updated		The DOTS client may re-try and send the PUT request with updated
	attribute values acceptable to the DOTS server.		attribute values acceptable to the DOTS server.
	Setting 'low-percentile' to '0.00' indicates that the DOTS client is		By default, low percentile (10th percentile), mid percentile (50th
	not interested in receiving low-percentiles. Likewise, setting 'mid-		percentile), high percentile (90th percentile), and peak (100th
	percentile' (or 'high-percentile') to the same value as 'low-		percentile) values are used to represent telemetry data.
	percentile' (or 'mid-percentile') indicates that the DOTS client is		Nevertheless, a DOTS client can disable some percentile types (low,
	not interested in receiving mid-percentiles (or high-percentiles).		mid, high). In particular, setting 'low-percentile' to '0.00'
	For example, a DOTS client can send the request depicted in Figure 5		indicates that the DOTS client is not interested in receiving low-
	to inform the server that it is interested in receiving only high-		percentiles. Likewise, setting 'mid-percentile' (or 'high-
	percentiles. This assumes that the client will only use that		percentile') to the same value as 'low-percentile' (or 'mid-
	percentile type when sharing telemetry data with the server.		percentile') indicates that the DOTS client is not interested in
			receiving mid-percentiles (or high-percentiles). For example, a DOTS
			client can send the request depicted in Figure 5 to inform the server
			that it is interested in receiving only high-percentiles. This
			assumes that the client will only use that percentile type when
			sharing telemetry data with the server.
	Header: PUT (Code=0.03)		Header: PUT (Code=0.03)
	Uri-Path: ".well-known"		Uri-Path: ".well-known"
	Uri-Path: "dots"		Uri-Path: "dots"
	Uri-Path: "tm-setup"		Uri-Path: "tm-setup"
	Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"		Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
	Uri-Path: "tsid=569"		Uri-Path: "tsid=569"
	Content-Format: "application/dots+cbor"		Content-Format: "application/dots+cbor"
	{		{
	"ietf-dots-signal-channel:telemetry-setup": {		"ietf-dots-telemetry:telemetry-setup": {
	"telemetry": [		"telemetry": [
	{		{
	"current-config": {		"current-config": {
	"low-percentile": 0.00,		"low-percentile": 0.00,
	"mid-percentile": 0.00,		"mid-percentile": 0.00,
	"high-percentile": 95.00		"high-percentile": 95.00
	}		}
	}		}
	]		]
	}		}
	}		}
	Figure 5: PUT to Disable Low- and Mid-Percentiles		Figure 5: PUT to Disable Low- and Mid-Percentiles
			DOTS clients can also configure the unit(s) to be used for traffic-
			related telemetry data. Typically, the supported units are: packets
			per second (PPS) or kilo packets per second (Kpps) and Bits per
			Second (BPS), and kilobytes per second or megabytes per second or
			gigabytes per second.
	DOTS clients that are interested to receive pre-mitigation telemetry		DOTS clients that are interested to receive pre-mitigation telemetry
	information from a DOTS server (Section 8) MUST set 'server-		information from a DOTS server (Section 8.2) MUST set 'server-
	initiated-telemetry' to 'true'. If 'server-initiated-telemetry' is		originated-telemetry' to 'true'. If 'server-originated-telemetry' is
	not present in a PUT request, this is equivalent to receiving a		not present in a PUT request, this is equivalent to receiving a
	request with 'server-initiated-telemetry'' set to 'false'. An		request with 'server-originated-telemetry'' set to 'false'. An
	example of a reques to enable pre-mitigation telemetry from DOTS		example of a reques to enable pre-mitigation telemetry from DOTS
	servers is shown in Figure 6.		servers is shown in Figure 6.
	Header: PUT (Code=0.03)		Header: PUT (Code=0.03)
	Uri-Path: ".well-known"		Uri-Path: ".well-known"
	Uri-Path: "dots"		Uri-Path: "dots"
	Uri-Path: "tm-setup"		Uri-Path: "tm-setup"
	Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"		Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
	Uri-Path: "tsid=569"		Uri-Path: "tsid=569"
	Content-Format: "application/dots+cbor"		Content-Format: "application/dots+cbor"
	{		{
	"ietf-dots-signal-channel:telemetry-setup": {		"ietf-dots-telemetry:telemetry-setup": {
	"telemetry": [		"telemetry": [
	{		{
	"current-config": {		"current-config": {
	"server-initiated-telemetry": true		"server-originated-telemetry": true
	}		}
	}		}
	]		]
	}		}
	}		}
	Figure 6: PUT to Enable Pre-mitigation Telemetry from the DOTS server		Figure 6: PUT to Enable Pre-mitigation Telemetry from the DOTS server
	o Note 1: Consider adding examples where signaling link aggregates
	is sufficient.?
	o Note 2: Which target prefix to communicate in the baseline/pipe
	depends on the location of the DOTS server. For example, if both
	upstream networks exposes a DOTS server; only information related
	to prefixes assigned by that upstream network to the DOTS client
	domain will be signalled. Consider adding a reference to the DOTS
	Multihoming draft.
	6.1.3. Retrieve Installed DOTS Telemetry Configuration		6.1.3. Retrieve Installed DOTS Telemetry Configuration
	A DOTS client may issue a GET message with 'tsid' Uri-Path parameter		A DOTS client may issue a GET message with 'tsid' Uri-Path parameter
	to retrieve the current DOTS telemetry configuration. An example of		to retrieve the current DOTS telemetry configuration. An example of
	such request is depicted in Figure 7.		such request is depicted in Figure 7.
	Header: GET (Code=0.01)		Header: GET (Code=0.01)
	Uri-Path: ".well-known"		Uri-Path: ".well-known"
	Uri-Path: "dots"		Uri-Path: "dots"
	Uri-Path: "tm-setup"		Uri-Path: "tm-setup"
	skipping to change at page 19, line 24 ¶		skipping to change at page 19, line 14 ¶
	Header: DELETE (Code=0.04)		Header: DELETE (Code=0.04)
	Uri-Path: ".well-known"		Uri-Path: ".well-known"
	Uri-Path: "dots"		Uri-Path: "dots"
	Uri-Path: "tm-setup"		Uri-Path: "tm-setup"
	Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"		Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
	Uri-Path: "tsid=123"		Uri-Path: "tsid=123"
	Figure 8: Delete Telemetry Configuration		Figure 8: Delete Telemetry Configuration
	If the DELETE request does not include 'cuid' and 'tsid' parameters,
	the DOTS server MUST reply with a 4.00 (Bad Request).
	The DOTS server resets the DOTS telemetry configuration back to the		The DOTS server resets the DOTS telemetry configuration back to the
	default values and acknowledges a DOTS client's request to remove the		default values and acknowledges a DOTS client's request to remove the
	DOTS telemetry configuration using 2.02 (Deleted) response code. A		DOTS telemetry configuration using 2.02 (Deleted) response code. A
	2.02 (Deleted) Response Code is returned even if the 'tsid' parameter		2.02 (Deleted) Response Code is returned even if the 'tsid' parameter
	value conveyed in the DELETE request does not exist in its		value conveyed in the DELETE request does not exist in its
	configuration data before the request.		configuration data before the request.
			Section 6.4 discusses the procedure to reset all DOTS telemetry setup
			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
	skipping to change at page 20, line 22 ¶		skipping to change at page 19, line 47 ¶
	| +--:(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
	| | +--rw capacity uint64		| | +--rw capacity uint64
	| | +--rw unit unit		| | +--rw unit unit
	| +--:(baseline)		| +--:(baseline)
	| ...		| ...
	+--:(telemetry) {dots-telemetry}?		+--:(telemetry) {dots-telemetry}?
	+--rw pre-mitigation* [cuid id]		+--rw pre-mitigation* [cuid tmid]
	...		...
	Figure 9: Pipe Tree Structure		Figure 9: Pipe Tree Structure
	A DOTS client domain pipe is defined as a list of limits of		A DOTS client domain pipe is defined as a list of limits of
	(incoming) traffic volume (total-pipe-capacity") that can be		(incoming) traffic volume (total-pipe-capacity") that can be
	forwarded over ingress interconnection links fo a DOTS client domain.		forwarded over ingress interconnection links of a DOTS client domain.
	Each of these links is identified with a "link-id" [RFC8345].		Each of these links is identified with a "link-id" [RFC8345].
	This limit can be expressed in packets per second (PPS) or kilo		This limit can be expressed in packets per second (PPS) or kilo
	packets per second (Kpps) and Bits per Second (BPS), and in kilobytes		packets per second (Kpps) and Bits per Second (BPS), and in kilobytes
	per second or megabytes per second or gigabytes per second. The unit		per second or megabytes per second or gigabytes per second. The unit
	used by a DOTS client when conveying pipe information is captured in		used by a DOTS client when conveying pipe information is captured in
	"unit" attribute.		'unit' attribute.
	6.2.1. Convey DOTS Client Domain Pipe Capacity		6.2.1. Convey DOTS Client Domain Pipe Capacity
	Similar considerations to those specified in Section 6.1.2 are		Similar considerations to those specified in Section 6.1.2 are
	followed with one exception:		followed with one exception:
	The relative order of two PUT requests carrying DOTS client domain		The relative order of two PUT requests carrying DOTS client domain
	pipe attributes from a DOTS client is determined by comparing		pipe attributes from a DOTS client is determined by comparing
	their respective 'tsid' values. If such two requests have		their respective 'tsid' values. If such two requests have
	overlapping "link-id" and "unit", the PUT request with higher		overlapping "link-id" and "unit", the PUT request with higher
	numeric 'tsid' value will override the request with a lower		numeric 'tsid' value will override the request with a lower
	numeric 'tsid' value. The overlapped lower numeric 'tsid' MUST be		numeric 'tsid' value. The overlapped lower numeric 'tsid' MUST be
	automatically deleted and no longer.		automatically deleted and no longer be available.
	DOTS clients SHOULD minimize the number of active "tsids" used for		DOTS clients SHOULD minimize the number of active 'tsids' used for
	pipe information. Typically, in order to avoid maintaining a long		pipe information. Typically, in order to avoid maintaining a long
	list of "tsids" for pipe information, it is RECOMMENDED that DOTS		list of 'tsids' for pipe information, it is RECOMMENDED that DOTS
	clients include in a request to update information related to a given		clients include in any request to update information related to a
	link, the information of other links (already communicated using a		given link the information of other links (already communicated using
	lower 'tsid' value). Doing so, this update request will override		a lower 'tsid' value). Doing so, this update request will override
	these existing requests and hence optimize the number of 'tsid"		these existing requests and hence optimize the number of 'tsid'
	request per DOTS client.		request per DOTS client.
	o Note: This assumes that all link information can fit in one single		o Note: This assumes that all link information can fit in one single
	message.		message.
	For example, a DOTS client managing a single homed domain (Figure 10)		For example, a DOTS client managing a single homed domain (Figure 10)
	can send a PUT request (shown in Figure 11) to communicate the		can send a PUT request (shown in Figure 11) to communicate the
	capacity of "link1" used to connected its ISP.		capacity of "link1" used to connect to its ISP.
	,--,--,--. ,--,--,--.		,--,--,--. ,--,--,--.
	,-' `-. ,-' `-.		,-' `-. ,-' `-.
	( DOTS Client )=====( ISP#A )		( DOTS Client )=====( ISP#A )
	`-. Domain ,-' link1 `-. ,-'		`-. Domain ,-' link1 `-. ,-'
	`--'--'--' `--'--'--'		`--'--'--' `--'--'--'
	Figure 10: Single Homed DOTS Client Domain		Figure 10: Single Homed DOTS Client Domain
	Header: PUT (Code=0.03)		Header: PUT (Code=0.03)
	Uri-Path: ".well-known"		Uri-Path: ".well-known"
	Uri-Path: "dots"		Uri-Path: "dots"
	Uri-Path: "tm-setup"		Uri-Path: "tm-setup"
	Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"		Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
	Uri-Path: "tsid=457"		Uri-Path: "tsid=457"
	Content-Format: "application/dots+cbor"		Content-Format: "application/dots+cbor"
	{		{
	"ietf-dots-signal-channel:telemetry-setup": {		"ietf-dots-telemetry:telemetry-setup": {
	"telemetry": [		"telemetry": [
	{		{
	"total-pipe-capacity": [		"total-pipe-capacity": [
	{		{
	"link-id": "link1",		"link-id": "link1",
	"capacity": 500,		"capacity": 500,
	"unit": "megabytes-ps"		"unit": "megabytes-ps"
	}		}
	]		]
	}		}
	]		]
	}		}
	}		}
	Figure 11: Example of a PUT Request to Convey Pipe Information		Figure 11: Example of a PUT Request to Convey Pipe Information
	(Single Homed)		(Single Homed)
			DOTS clients may be instructed to signal a link aggregate instead of
			individual links. For example, a DOTS client managing a DOTS client
			domain having two interconnection links with an upstream ISP
			(Figure 12) can send a PUT request (shown in Figure 13) to
			communicate the aggregate link capacity with its ISP. Signalling
			individual or aggregate link capacity is deployment-specific.
			,--,--,--. ,--,--,--.
			,-' `-.===== ,-' `-.
			( DOTS Client ) ( ISP#C )
			`-. Domain ,-'====== `-. ,-'
			`--'--'--' `--'--'--'
			Figure 12: DOTS Client Domain with Two Interconnection Links
			Header: PUT (Code=0.03)
			Uri-Path: ".well-known"
			Uri-Path: "dots"
			Uri-Path: "tm-setup"
			Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
			Uri-Path: "tsid=896"
			Content-Format: "application/dots+cbor"
			{
			"ietf-dots-telemetry:telemetry-setup": {
			"telemetry": [
			{
			"total-pipe-capacity": [
			{
			"link-id": "aggregate",
			"capacity": 700,
			"unit": "megabytes-ps"
			}
			]
			}
			]
			}
			}
			Figure 13: Example of a PUT Request to Convey Pipe Information
			(Aggregated Link)
	Now consider that the DOTS client domain was upgraded to connect to		Now consider that the DOTS client domain was upgraded to connect to
	an additional ISP (ISP#B of Figure 12), the DOTS client can inform		an additional ISP (ISP#B of Figure 14), the DOTS client can inform a
	the DOTS server about this update by sending the PUT request depicted		third-party DOTS server (that is, not hosted with ISP#A and ISP#B
	in Figure 13. This request includes also information related to		domains) about this update by sending the PUT request depicted in
	"link1" even if that link is not upgraded. Upon receipt of this		Figure 15. This request also includes information related to "link1"
	request, the DOTS server removes the request with "tsid=457" and		even if that link is not upgraded. Upon receipt of this request, the
	updates its configuration base to maintain two links (link#1 and		DOTS server removes the request with 'tsid=457' and updates its
	link#2).		configuration base to maintain two links (link#1 and link#2).
	,--,--,--.		,--,--,--.
	,-' `-.		,-' `-.
	( ISP#B )		( ISP#B )
	`-. ,-'		`-. ,-'
	`--'--'--'		`--'--'--'
	||		||
	|| link2		|| link2
	,--,--,--. ,--,--,--.		,--,--,--. ,--,--,--.
	,-' `-. ,-' `-.		,-' `-. ,-' `-.
	( DOTS Client )=====( ISP#A )		( DOTS Client )=====( ISP#A )
	`-. Domain ,-' link1 `-. ,-'		`-. Domain ,-' link1 `-. ,-'
	`--'--'--' `--'--'--'		`--'--'--' `--'--'--'
	Figure 12: Multi-Homed DOTS Client Domain		Figure 14: Multi-Homed DOTS Client Domain
	Header: PUT (Code=0.03)		Header: PUT (Code=0.03)
	Uri-Path: ".well-known"		Uri-Path: ".well-known"
	Uri-Path: "dots"		Uri-Path: "dots"
	Uri-Path: "tm-setup"		Uri-Path: "tm-setup"
	Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"		Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
	Uri-Path: "tsid=458"		Uri-Path: "tsid=458"
	Content-Format: "application/dots+cbor"		Content-Format: "application/dots+cbor"
	{		{
	"ietf-dots-signal-channel:telemetry-setup": {		"ietf-dots-telemetry:telemetry-setup": {
	"telemetry": [		"telemetry": [
	{		{
	"total-pipe-capacity": [		"total-pipe-capacity": [
	{		{
	"link-id": "link1",		"link-id": "link1",
	"capacity": 500,		"capacity": 500,
	"unit": "megabytes-ps"		"unit": "megabytes-ps"
	},		},
	{		{
	"link-id": "link2",		"link-id": "link2",
	"capacity": 500,		"capacity": 500,
	"unit": "megabytes-ps"		"unit": "megabytes-ps"
	}		}
	]		]
	}		}
	]		]
	}		}
	}		}
	Figure 13: Example of a PUT Request to Convey Pipe Information		Figure 15: Example of a PUT Request to Convey Pipe Information
	(Multi-Homed)		(Multi-Homed)
	A DOTS client can delete a link by sending a PUT request with the		A DOTS client can delete a link by sending a PUT request with the
	capacity" attribute set to "0" if other links are still active for		'capacity' attribute set to "0" if other links are still active for
	the same DOTS client domain (see Section 6.2.3 for other delete		the same DOTS client domain (see Section 6.2.3 for other delete
	cases). For example, if a DOTS client domain re-homes (that is, it		cases). For example, if a DOTS client domain re-homes (that is, it
	changes it ISP), the DOTS client can inform the DOTS server about		changes its ISP), the DOTS client can inform its DOTS server about
	this update (e.g., from the network configuration in Figure 10 to the		this update (e.g., from the network configuration in Figure 10 to the
	one shown in Figure 14) by sending the PUT request depicted in		one shown in Figure 16) by sending the PUT request depicted in
	Figure 15. Upon receipt of this request, the DOTS server removes		Figure 17. Upon receipt of this request, the DOTS server removes
	"link1" from its configuration bases for this DOTS client domain.		"link1" from its configuration bases for this DOTS client domain.
	,--,--,--.		,--,--,--.
	,-' `-.		,-' `-.
	( ISP#B )		( ISP#B )
	`-. ,-'		`-. ,-'
	`--'--'--'		`--'--'--'
	||		||
	|| link2		|| link2
	,--,--,--.		,--,--,--.
	,-' `-.		,-' `-.
	( DOTS Client )		( DOTS Client )
	`-. Domain ,-'		`-. Domain ,-'
	`--'--'--'		`--'--'--'
	Figure 14: Multi-Homed DOTS Client Domain		Figure 16: Multi-Homed DOTS Client Domain
	Header: PUT (Code=0.03)		Header: PUT (Code=0.03)
	Uri-Path: ".well-known"		Uri-Path: ".well-known"
	Uri-Path: "dots"		Uri-Path: "dots"
	Uri-Path: "tm-setup"		Uri-Path: "tm-setup"
	Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"		Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
	Uri-Path: "tsid=459"		Uri-Path: "tsid=459"
	Content-Format: "application/dots+cbor"		Content-Format: "application/dots+cbor"
	{		{
	"ietf-dots-signal-channel:telemetry-setup": {		"ietf-dots-telemetry:telemetry-setup": {
	"telemetry": [		"telemetry": [
	{		{
	"total-pipe-capacity": [		"total-pipe-capacity": [
	{		{
	"link-id": "link1",		"link-id": "link1",
	"capacity": 0,		"capacity": 0,
	"unit": "megabytes-ps"		"unit": "megabytes-ps"
	},		},
	{		{
	"link-id": "link2",		"link-id": "link2",
	"capacity": 500,		"capacity": 500,
	"unit": "megabytes-ps"		"unit": "megabytes-ps"
	}		}
	]		]
	}		}
	]		]
	}		}
	}		}
	Figure 15: Example of a PUT Request to Convey Pipe Information		Figure 17: Example of a PUT Request to Convey Pipe Information
	(Multi-Homed)		(Multi-Homed)
	6.2.2. Retrieve DOTS Client Domain Pipe Capacity		6.2.2. Retrieve DOTS Client Domain Pipe Capacity
	A GET request with 'tsid' Uri-Path parameter is used to retrieve a		A GET request with 'tsid' Uri-Path parameter is used to retrieve a
	specific installed DOTS client domain pipe related information. The		specific installed DOTS client domain pipe related information. The
	that aim, the same procedure defined in (Section 6.1.3) is followed.		same procedure as defined in (Section 6.1.3) is followed.
	To retrieve all pipe information bound to a DOTS client, the DOTS		To retrieve all pipe information bound to a DOTS client, the DOTS
	client proceeds as specified in Section 6.1.1.		client proceeds as specified in Section 6.1.1.
	6.2.3. Delete DOTS Client Domain Pipe Capacity		6.2.3. Delete 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 that aim, the same procedure defined		pipe related information. The same procedure as defined in
	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 total connections capacity:
	Total Traffic Normal Baseline: By default, the low percentile (10th		Total Traffic Normal Baseline: The percentile values representing
	percentile), mid percentile (50th percentile), high percentile		the total traffic normal baseline.
	(90th percentile), and peak values (100th percentile) of "Total
	traffic normal baselines" measured in packets per second (PPS) or
	kilo packets per second (Kpps) and Bits per Second (BPS), and
	kilobytes per second or megabytes per second or gigabytes per
	second. For example, 90th percentile says that 90% of the time,
	the total normal traffic is below the limit specified.
	The traffic normal baseline is represented for a target and is		The traffic normal baseline is represented for a target and is
	transport-protocol specific.		transport-protocol specific.
	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 attack, 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:
	* The maximum number of simultaneous connections that are allowed		Total Connections Capacity:
	to the target. The threshold is transport-protocol specific
	because the target could support multiple protocols.
	* The maximum number of simultaneous connections that are allowed		* The maximum number of simultaneous connections that are allowed
			to the target.
			* 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 and embryonic connection is only possible in
	connection-oriented transport protocols like TCP or SCTP.		connection-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.
	* 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 tree structure of the baseline is shown in Figure 16.		The threshold is transport-protocol.
			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)
	| | ...		| | ...
	skipping to change at page 28, line 44 ¶		skipping to change at page 27, line 46 ¶
	| +--rw protocol uint8		| +--rw protocol uint8
	| +--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? uint6		| +--rw partial-request-client-ps? uint64
	+--:(telemetry) {dots-telemetry}?		+--:(telemetry) {dots-telemetry}?
	+--rw pre-mitigation* [cuid id]		+--rw pre-mitigation* [cuid tmid]
	...		...
	Figure 16: Telemetry Baseline Tree Structure		Figure 18: Telemetry Baseline Tree Structure
	6.3.1. Convey DOTS Client Domain Baseline Information		6.3.1. Convey DOTS Client Domain Baseline Information
	Similar considerations to those specified in Section 6.1.2 are		Similar considerations to those specified in Section 6.1.2 are
	followed with one exception:		followed with one exception:
	The relative order of two PUT requests carrying DOTS client domain		The relative order of two PUT requests carrying DOTS client domain
	baseline attributes from a DOTS client is determined by comparing		baseline attributes from a DOTS client is determined by comparing
	their respective 'tsid' values. If such two requests have		their respective 'tsid' values. If such two requests have
	overlapping targets, the PUT request with higher numeric 'tsid'		overlapping targets, the PUT request with higher numeric 'tsid'
	value will override the request with a lower numeric 'tsid' value.		value will override the request with a lower numeric 'tsid' value.
	The overlapped lower numeric 'tsid' MUST be automatically deleted		The overlapped lower numeric 'tsid' MUST be automatically deleted
	and no longer.		and no longer be available.
	Two PUT requests from a DOTS client have overlapping targets if there		Two PUT requests from a DOTS client have overlapping targets if there
	is a common IP address, IP prefix, FQDN, or URI.		is a common IP address, IP prefix, FQDN, or URI.
	DOTS clients SHOULD minimize the number of active "tsids" used for		DOTS clients SHOULD minimize the number of active 'tsids' used for
	baseline information. Typically, in order to avoid maintaining a		baseline information. Typically, in order to avoid maintaining a
	long list of "tsids" for baseline information, it is RECOMMENDED that		long list of 'tsids' for baseline information, it is RECOMMENDED that
	DOTS clients include in a request to update information related to a		DOTS clients include in a request to update information related to a
	given target, the information of other targets (already communicated		given target, the information of other targets (already communicated
	using a lower 'tsid' value) (assuming this fits within one single		using a lower 'tsid' value) (assuming this fits within one single
	datagram). This update request will override these existing requests		datagram). This update request will override these existing requests
	and hence optimize the number of 'tsid" request per DOTS client.		and hence optimize the number of 'tsid' request per DOTS client.
	If no target clause in included in the request, this is an indication		If no target clause in included in the request, this is an indication
	that the baseline information applies for the DOTS client domain as a		that the baseline information applies for the DOTS client domain as a
	whole.		whole.
	An example of a PUT request to convey the baseline information is		An example of a PUT request to convey the baseline information is
	shown in Figure 17.		shown in Figure 19.
	Header: PUT (Code=0.03)		Header: PUT (Code=0.03)
	Uri-Path: ".well-known"		Uri-Path: ".well-known"
	Uri-Path: "dots"		Uri-Path: "dots"
	Uri-Path: "tm-setup"		Uri-Path: "tm-setup"
	Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"		Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
	Uri-Path: "tsid=126"		Uri-Path: "tsid=126"
	Content-Format: "application/dots+cbor"		Content-Format: "application/dots+cbor"
	{		{
	"ietf-dots-signal-channel:telemetry": {		"ietf-dots-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-baseline": {
	"unit": "megabytes-ps",		"unit": "megabytes-ps",
	"protocol": 6,		"protocol": 6,
	"peak-g": "50"		"peak-g": "50"
	}		}
	}		}
	}		}
	}		}
	Figure 17: PUT to Convey the DOTS Traffic Baseline		Figure 19: PUT to Convey the DOTS Traffic Baseline
	o Note: Add some multi-homing considerations in this section or in
	the multi-homing I-D.
	6.3.2. Retrieve Normal Traffic Baseline		6.3.2. Retrieve 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 that aim, the same procedure defined in (Section 6.1.3) is		The same procedure as defined in (Section 6.1.3) is followed.
	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.
	6.3.3. Retrieve Normal Traffic Baseline		6.3.3. Delete Normal Traffic Baseline
	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 that aim, the same procedure 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 and Configuration		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
	a DOTS client MAY send a DELETE request to set the telemetry		DOTS client setup), a DOTS client MAY send a DELETE request to set
	parameters to default values. Such a request does not include any		the telemetry parameters to default values. Such a request does not
	'tsid'. An example of such request is depicted in Figure 18.		include any 'tsid'. An example of such request is depicted in
			Figure 20.
	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 18: Delete Telemetry Configuration		Figure 20: 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 confict 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:
	1: Overlapping targets (already defined in		1: Overlapping targets (already defined in
	[I-D.ietf-dots-signal-channel]).		[I-D.ietf-dots-signal-channel]).
	TBA: Overlapping pipe scope (see Section 11).		TBA: Overlapping pipe scope (see Section 11).
	7. DOTS Telemetry from Clients to Servers		7. DOTS Pre-mitigation Telemetry
	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 description and motivation behind each attribute are presented in
	Section 3. DOTS telemetry attributes are optionally signaled and
	therefore MUST NOT be treated as mandatory fields in the DOTS signal
	channel protocol.
	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 19.		structure of the "telemetry" message type is shown Figure 21.
			The pre-mitigation telemetry attributes are indicated by 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. Pre-
			mitigation telemetry attributes specified in Section 7.1 can be
			signaled between DOTS agents.
			Pre-mitigation telemetry attributes may be sent by a DOTS client or a
			DOTS server.
			DOTS agents MUST bind pre-mitigation telemetry data with mitigation
			requests relying upon the target clause.
			DOTS agents MUST NOT sent pre-mitigation telemetry messages to the
			same peer more frequently than once every 'telemetry-notify-interval'
			(Section 6.1).
			DOTS pre-mitigation telemetry request and response messages MUST be
			marked as Non-Confirmable messages.
			o Notes: How long a pre-mitgation id can be maintained by a peer?
	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-mitigation* [cuid id]		+--rw pre-mitigation* [cuid tmid]
	+--rw cuid string		+--rw cuid string
	+--rw cdid? string		+--rw cdid? string
	+--rw id uint32		+--rw tmid uint32
			+--rw target
			| ...
			+--rw total-traffic* [unit protocol]
			| ...
			+--rw total-attack-traffic* [unit protocol]
			| ...
			+--rw total-attack-connection
			| ...
			+--rw attack-detail
			...
			Figure 21: Telemetry Message Type Tree Structure
			7.1. Pre-mitigation DOTS Telemetry Attributes
			The description and motivation behind each attribute are presented in
			Section 3. DOTS telemetry attributes are optionally signaled and
			therefore MUST NOT be treated as mandatory fields in the DOTS signal
			channel protocol.
			7.1.1. Target
			A target resource (Figure 22) is identified using the attributes
			'target-prefix', 'target-port-range', 'target-protocol', 'target-
			fqdn', 'target-uri', or 'alias-name' defined in the base DOTS signal
			channel protocol.
			+--:(telemetry) {dots-telemetry}?
			+--rw pre-mitigation* [cuid tmid]
			+--rw cuid string
			+--rw cdid? string
			+--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 total-traffic* [unit protocol]		+--rw total-traffic* [unit protocol]
	| ...		| ...
	+--rw total-attack-traffic* [unit protocol]		+--rw total-attack-traffic* [unit protocol]
	| ...		| ...
	+--rw total-attack-connection		+--rw total-attack-connection
	| ...		| ...
	+--rw attack-detail		+--rw attack-detail
	...		...
	Figure 19: Telemetry Message Type Tree Structure		Figure 22: Target Tree Structure
	7.1. Pre-mitigation DOTS Telemetry Attributes		At least one of the attributes 'target-prefix', 'target-fqdn',
			'target-uri', or 'alias-name' MUST be present in the attack details.
	The pre-mitigation telemetry attributes are indicated by the path-		If the target is subjected to bandwidth consuming attack, the
	suffix '/tm'. The '/tm' is appended to the path-prefix to form the		attributes representing the percentile values of the 'attack-id'
	URI used with a CoAP request to signal the DOTS telemetry. The		attack traffic are included.
	following pre-mitigation telemetry attributes can be signaled from
	DOTS clients to DOTS servers.
	o DISCUSSION NOTES: (1) Some telemetry can be communicated using		If the target is subjected to resource consuming DDoS attacks, the
	DOTS data channel. (2) Evaluate the risk of fragmentation,. Some		same attributes defined for Section 7.1.4 are applicable for
	of the information is not specific to each mitigation request. (3)		representing the attack.
	Should we define other configuration parameters to be controlled
	by a DOTS client, e.g., Indicate a favorite measurement unit?
	Indicate a minimum notification interval?
	7.1.1. Total Traffic		This is an optional sub-attribute.
	By default, this attribute conveys the low percentile (10th		7.1.2. Total Traffic
	percentile), mid percentile (50th percentile), high percentile (90th
	percentile) and peak values of total traffic during a DDoS attack		This attribute (Figure 23) conveys the percentile values of total
	measured in packets per second (PPS) or kilo packets per second		traffic observed during a DDoS attack.
	(Kpps) and Bits per Second (BPS), and kilobytes per second or
	megabytes per second gigabytes per second.
	The total traffic is represented for a target and is transport-		The total traffic is represented for a target and is transport-
	protocol specific.		protocol specific.
	augment /ietf-signal:dots-signal/ietf-signal:message-type:
	+--:(telemetry-setup) {dots-telemetry}?
	| +--rw telemetry* [cuid tsid]
	| ...
	+--:(telemetry) {dots-telemetry}?		+--:(telemetry) {dots-telemetry}?
	+--rw pre-mitigation* [cuid id]		+--rw pre-mitigation* [cuid tmid]
	+--rw cuid string		+--rw cuid string
	+--rw cdid? string		+--rw cdid? string
	+--rw id uint32		+--rw tmid uint32
	+--rw target		+--rw target
	| +--rw target-prefix* inet:ip-prefix		| ...
	| +--rw target-port-range* [lower-port]
	| | +--rw lower-port inet:port-number
	| | +--rw upper-port? inet:port-number
	| +--rw target-protocol* uint8
	| +--rw target-fqdn* inet:domain-name
	| +--rw target-uri* inet:uri
	+--rw total-traffic* [unit protocol]		+--rw total-traffic* [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-attack-traffic* [unit protocol]		+--rw total-attack-traffic* [unit protocol]
	| ...		| ...
	+--rw total-attack-connection		+--rw total-attack-connection
	| ...		| ...
	+--rw attack-detail		+--rw attack-detail
	...		...
	Figure 20: Total Traffic Tree Structure		Figure 23: Total Traffic Tree Structure
	7.1.2. Total Attack Traffic		7.1.3. Total Attack Traffic
	By default, this attribute conveys the total attack traffic can be		This attribute (Figure 24) conveys the total attack traffic
	identified by the DOTS client domain's DMS or DDoS Detector. The low		identified by the DOTS client domain's DMS (or DDoS Detector).
	percentile (10th percentile), mid percentile (50th percentile), high
	percentile (90th percentile) and peak values of total attack traffic
	measured in packets per second (PPS) or kilo packets per second
	(Kpps) and Bits per Second (BPS), and kilobytes per second or
	megabytes per second or gigabytes per second.
	The total attack traffic is represented for a target and is		The total attack traffic is represented for a target and is
	transport-protocol specific.		transport-protocol specific.
	augment /ietf-signal:dots-signal/ietf-signal:message-type:
	+--:(telemetry-setup) {dots-telemetry}?
	| +--rw telemetry* [cuid tsid]
	| ...
	+--:(telemetry) {dots-telemetry}?		+--:(telemetry) {dots-telemetry}?
	+--rw pre-mitigation* [cuid id]		+--rw pre-mitigation* [cuid tmid]
	+--rw cuid string		+--rw cuid string
	+--rw cdid? string		+--rw cdid? string
	+--rw id uint32		+--rw tmid uint32
	+--rw target		+--rw target
	| +--rw target-prefix* inet:ip-prefix		| ...
	| +--rw target-port-range* [lower-port]
	| | +--rw lower-port inet:port-number
	| | +--rw upper-port? inet:port-number
	| +--rw target-protocol* uint8
	| +--rw target-fqdn* inet:domain-name
	| +--rw target-uri* inet:uri
	+--rw total-traffic* [unit protocol]		+--rw total-traffic* [unit protocol]
	| ...		| ...
	+--rw total-attack-traffic* [unit protocol]		+--rw total-attack-traffic* [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-attack-connection		+--rw total-attack-connection
	| ...		| ...
	+--rw attack-detail		+--rw attack-detail
	...		...
	Figure 21: Total Attack Traffic Tree Structure		Figure 24: Total Attack Traffic Tree Structure
	7.1.3. Total Attack Connections
	If the target is subjected to resource consuming DDoS attack, the low
	percentile (10th percentile), mid percentile (50th percentile), high
	percentile (90th percentile) and peak values of following optional
	attributes for the target per transport-protocol are included to
	represent the attack characteristics:
	o The number of simultaneous attack connections to the target
	server.
	o The number of simultaneous embryonic connections to the target		7.1.4. Total Attack Connections
	server.
	o The number of attack connections per second to the target server.		If the target is subjected to resource consuming DDoS attack, this
			attribute is used to convey the percentile values of total attack
			connections. The following optional sub-attributes for the target
			per transport-protocol are included to represent the attack
			characteristics:
	o The number of attack requests to the target server.		o The number of simultaneous attack 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 requests to the target.
	augment /ietf-signal:dots-signal/ietf-signal:message-type:
	+--:(telemetry-setup) {dots-telemetry}?
	| +--rw telemetry* [cuid tsid]
	| ...
	+--:(telemetry) {dots-telemetry}?		+--:(telemetry) {dots-telemetry}?
	+--rw pre-mitigation* [cuid id]		+--rw pre-mitigation* [cuid tmid]
	+--rw cuid string		+--rw cuid string
	+--rw cdid? string		+--rw cdid? string
	+--rw id uint32		+--rw tmid uint32
	+--rw target		+--rw target
	| +--rw target-prefix* inet:ip-prefix		| ...
	| +--rw target-port-range* [lower-port]
	| | +--rw lower-port inet:port-number
	| | +--rw upper-port? inet:port-number
	| +--rw target-protocol* uint8
	| +--rw target-fqdn* inet:domain-name
	| +--rw target-uri* inet:uri
	+--rw total-traffic* [unit protocol]		+--rw total-traffic* [unit protocol]
	| ...		| ...
	+--rw total-attack-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
	skipping to change at page 36, line 27 ¶		skipping to change at page 35, line 48 ¶
	| +--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 attack-detail
	...		...
	Figure 22: Total Attack Connections Tree Structure		Figure 25: Total Attack Connections Tree Structure
	7.1.4. Attack Details		7.1.5. Attack Details
	The attack details need to cover well-known and common attacks (such		This attribute (Figure 26) is used to signal a set of details
	as a SYN Flood) along with new emerging or vendor-specific attacks.		characterizing an attack. The following optional sub-attributes
			describing the on-going attack can be signal as attack details.
			id: Vendor ID is a security vendor's Enterprise Number as registered
			with IANA [Enterprise-Numbers]. It is a four-byte integer value.
			attack-id: Unique identifier assigned by the vendor for the attack.
			attack-name: Textual representation of attack description. Natural
			Language Processing techniques (e.g., word embedding) can possibly
			be used to map the attack description to an attack type. Textual
			representation of attack solves two problems: (a) avoids the need
			to create mapping tables manually between vendors and (2) avoids
			the need to standardize attack types which keep evolving.
			attack-severity: Attack severity. These values are supported:
			Emergency (1), critical (2), and alert (3).
			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
			(Section 2.4.1 of [RFC7049]). The CBOR encoding is modified so
			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
			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
			that the leading tag 1 (epoch-based date/time) MUST be omitted.
			Source-count: A count of sources involved in the attack targeting
			the victim.
			Top-talkers: A list of top talkers among attack sources. The top
			talkers are represented using the 'source-prefix' defined in
			[I-D.ietf-dots-signal-call-home].
			'spoofed-status' is used whether a top talker is a spoofed IP
			address (e.g., reflection attacks) or not.
			If the target is subjected to bandwidth consuming attack, the
			attack traffic from each of the top talkers is included ('total-
			attack-traffic', Section 7.1.3).
			If the target is subjected to resource consuming DDoS attacks, the
			same attributes defined for Section 7.1.4 are applicable for
			representing the attack per talker.
	augment /ietf-signal:dots-signal/ietf-signal:message-type:
	+--:(telemetry-setup) {dots-telemetry}?
	| +--rw telemetry* [cuid tsid]
	| ...
	+--:(telemetry) {dots-telemetry}?		+--:(telemetry) {dots-telemetry}?
	+--rw pre-mitigation* [cuid id]		+--rw pre-mitigation* [cuid tmid]
	+--rw cuid string		+--rw cuid string
	+--rw cdid? string		+--rw cdid? string
	+--rw id uint32		+--rw tmid uint32
	...		+--rw target
			| ...
			+--rw total-traffic* [unit protocol]
			| ...
			+--rw total-attack-traffic* [unit protocol]
			| ...
			+--rw total-attack-connection
			| ...
	+--rw attack-detail		+--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 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
	skipping to change at page 37, line 21 ¶		skipping to change at page 37, line 42 ¶
	+--rw spoofed-status? boolean		+--rw spoofed-status? boolean
	+--rw source-prefix inet:ip-prefix		+--rw source-prefix inet:ip-prefix
	+--rw total-attack-traffic* [unit]		+--rw total-attack-traffic* [unit]
	| +--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
	+--rw total-attack-connection		+--rw total-attack-connection
	+--rw low-percentile-l* [protocol]		+--rw low-percentile-l* [protocol]
	| +--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]		+--rw mid-percentile-l* [protocol]
	| +--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]		+--rw high-percentile-l* [protocol]
	| +--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]		+--rw peak-l* [protocol]
	+--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
	Attack Detail Tree Structure		Figure 26: Attack Detail Tree Structure
	The following new fields describing the on-going attack are		7.2. From DOTS Clients to DOTS Servers
	discussed:
	id: Vendor ID is a security vendor's Enterprise Number as registered		DOTS clients uses PUT request to signal pre-mitigation telemetry to
	with IANA [Enterprise-Numbers]. It is a four-byte integer value.		DOTS servers. An example of such request is shown in Figure 27.
	This is a mandatory sub-attribute.		Header: PUT (Code=0.03)
			Uri-Path: ".well-known"
			Uri-Path: "dots"
			Uri-Path: "tm"
			Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
			Uri-Path: "tmid=123"
			Content-Format: "application/dots+cbor"
	attack-id: Unique identifier assigned by the vendor for the attack.		{
			"ietf-dots-telemetry:telemetry": {
			"target": [
			{
			"target-prefix": [
			"2001:db8::1/128"
			]
			"total-attack-traffic": [
			{
			"protocol": 17,
			"unit": "megabytes-ps",
			"mid-percentile-g": "900"
			}
			],
			"attack-detail": {
			"start-time": "1957811234",
			"attack-severity": "emergency"
			}
			}
			]
			}
			}
	This is a mandatory sub-attribute.		Figure 27: PUT to Send Pre-Mitigation Telemetry
	attack-name: Textual representation of attack description. Natural		'cuid' is a mandatory Uri-Path parameter for PUT requests.
	Language Processing techniques (e.g., word embedding) can possibly
	be used to map the attack description to an attack type. Textual
	representation of attack solves two problems (a) avoids the need
	to create mapping tables manually between vendors (2) Avoids the
	need to standardize attack types which keep evolving.
	This is a mandatory sub-attribute		The following additional Uri-Path parameter is defined:
	attack-severity: Attack severity. Emergency (0), critical (1) and		tmid: Telemetry Identifier is an identifier for the DOTS pre-
	alert (2).		mitigation telemetry data represented as an integer. This
			identifier MUST be generated by DOTS clients. 'tsid' values MUST
			increase monotonically (when a new PUT is generated by a DOTS
			client to convey pre-mitigation telemetry).
	This is an optional sub-attribute		This is a mandatory attribute.
	start-time: The time the attack started. The attack start time is		At least 'target' attribute and another pre-mitigation attributes
	expressed in seconds relative to 1970-01-01T00:00Z in UTC time		(Section 7.1) MUST be present in the PUT request. If only the
	(Section 2.4.1 of [RFC7049]). The CBOR encoding is modified so		'target' attribute is present, this request is handled as per
	that the leading tag 1 (epoch-based date/time) MUST be omitted.		Section 7.3.
	This is a mandatory sub-attribute		The relative order of two PUT requests carrying DOTS pre-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.
	end-time: The time the attack-id attack ended. The attack		<<should we restrict pre-mitigation to one tmid i a request?>>
	end 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 that the leading tag 1 (epoch-based date/time) MUST be
	omitted.
	This is an optional sub-attribute		<<processing at the server>>
	The following existing fields are re-defined describing the on-going		7.3. From DOTS Servers to DOTS Client
	attack are discussed:
	o The target resource is identified using the attributes 'target-		The pre-mitigation (attack details, in particular) can also be
	prefix', 'target-port-range', 'target-protocol', 'target-		signaled from DOTS servers to DOTS clients. For example, the DOTS
	fqdn','target-uri', or 'alias-name' defined in the base DOTS		server co-located with a DDoS detector collects monitoring
	signal channel protocol and at least one of the attributes		information from the target network, identifies DDoS attack using
	'target-prefix', 'target-fqdn','target-uri', or 'alias-name' MUST		statistical analysis or deep learning techniques, and signals the
	be present in the attack details.		attack details to the DOTS client.
	A. If the target is subjected to bandwidth consuming attack, the		The DOTS client can use the attack details to decide whether to
	attributes representing the low percentile (10th percentile),		trigger a DOTS mitigation request or not. Furthermore, the security
	mid percentile (50th percentile), high percentile (90th		operation personnel at the DOTS client domain can use the attack
	percentile) and peak values of the attack-id attack traffic		details to determine the protection strategy and select the
	measured in packets per second (PPS) or kilo packets per		appropriate DOTS server for mitigating the attack.
	second (Kpps) and Bits per Second (BPS), and kilobytes per
	second or megabytes per second or gigabytes per second are
	included.
	B. If the target is subjected to resource consuming DDoS attacks,		In order to receive pre-mitigation telemetry notifications from a
	the same attributes defined for Section 7.1.3 are applicable		DOTS server, a DOTS client MUST send a PUT (followed by a GET) with
	for representing the attack.		the target filter. An example of such request is shown in Figure 28.
			In order to avoid maintaining a long list of such requests, it is
			RECOMMENDED that DOTS clients include all targets in the same
			request. DOTS servers may be instructed to restrict the number of
			pre-mitigation requests per DOTS client domain.
	This is an optional sub-attribute.		Header: PUT (Code=0.03)
			Uri-Path: ".well-known"
			Uri-Path: "dots"
			Uri-Path: "tm"
			Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
			Uri-Path: "tmid=123"
			Content-Format: "application/dots+cbor"
	o A count of sources involved in the attack targeting the victim and		{
	a list of top talkers among those sources. The top talkers are		"ietf-dots-telemetry:telemetry": {
	represented using the 'source-prefix' defined in		"target": {
	[I-D.ietf-dots-signal-call-home]. If the top talkers are spoofed		{
	IP addresses (e.g., reflection attacks) or not. If the target is		"target-prefix": [
	subjected to bandwidth consuming attack, the attack traffic from		"2001:db8::/32"
	each of the top talkers represented in the low percentile (10th		]
	percentile), mid percentile (50th percentile), high percentile		}
	(90th percentile) and peak values of traffic measured in packets		}
	per second (PPS) or kilo packets per second (Kpps) and Bits per		}
	Second (BPS), and kilobytes per second or megabytes per second		}
	gigabytes per second. If the target is subjected to resource
	consuming DDoS attacks, the same attributes defined for
	Section 7.1.3 are applicable here for representing the attack per
	talker. This is an optional sub-attribute.
	7.2. DOTS Client to Server Mitigation Efficacy DOTS Telemetry		Figure 28: PUT to Request Pre-Mitigation Telemetry
	Attributes
	The mitigation efficacy telemetry attributes can be signaled from the		<<<Include more details about the processing of the request:
	DOTS client to the DOTS server as part of the periodic mitigation		lifetime, etc.>>>
	efficacy updates to the server (Section 5.3.4 of
	[I-D.ietf-dots-signal-channel]).
	Total Attack Traffic: The low percentile (10th percentile), mid		DOTS clients of the same domain can request to receive pre-mitigation
	percentile (50th percentile), high percentile (90th percentile),		telemetry bound to the same target.
	and peak values of total attack traffic the DOTS client still sees
	during the active mitigation service measured in packets per
	second (PPS) or kilo packets per second (Kpps) and Bits per Second
	(BPS), and kilobytes per second or megabytes per second or
	gigabytes per second. See Figure 21.
	Attack Details: The overall attack details as observed from the		Then, the DOTS client conveys the Observe Option set to '0' in the
	DOTS client perspective during the active mitigation service. The		GET request to receive asynchronous notifications carrying pre-
	same attributes defined in Section 7.1.4 are applicable here.		mitigation telemetry data from the DOTS server. The GET request
			specify a 'tmid' (Figure 29) or not (Figure 30).
	7.3. Sample Examples		Header: GET (Code=0.01)
			Uri-Path: ".well-known"
			Uri-Path: "dots"
			Uri-Path: "tm"
			Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
			Uri-Path: "tmid=123"
			Observe: 0
	7.3.1. Single Pre-Mitigation		Figure 29: GET to Subscribe to Telemetry Asynchronous Notifications
			for a Specific 'tmid'
	<<>>		Header: GET (Code=0.01)
			Uri-Path: ".well-known"
			Uri-Path: "dots"
			Uri-Path: "tm"
			Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
			Observe: 0
	7.3.2. Multiple Pre-Mitigations		Figure 30: GET to Subscribe to Telemetry Asynchronous Notifications
			for All 'tmids'
	<<multiple mitigation-ids are used >>		The DOTS server will then send asynchronous notifications to the DOTS
			client when an event if following similar considerations as in
			Section 4.4.2.1 of [I-D.ietf-dots-signal-channel]. An example of a
			pre-mitugation telemetry notification is shown in Figure 31.
	7.3.3. Top-Talker of Targets		{
			"ietf-dots-telemetry:telemetry": {
			"target": [
			{
			"tmid": 123,
			"target-prefix": [
			"2001:db8::1/128"
			]
			"total-attack-traffic": [
			{
			"protocol": 17,
			"unit": "megabytes-ps",
			"mid-percentile-g": "900"
			}
			],
			"attack-detail": {
			"start-time": "1957818434",
			"attack-severity": "emergency"
			}
			}
			]
			}
			}
	<<A server can aggregate top-talkers for all targets of a domain, or		Figure 31: Message Body of a Pre-mitigation Telemetry Notification
	when justified, send specific information (including top-talkers) per		from the DOTS Server
	individual targets. >>
	<<several target victim (target) addresses should be included in the		A DOTS server may aggregate pre-mitigation data (e.g., 'top-talkers')
	target-prefix*.>>		for all targets of a domain, or when justified, send specific
			information (e.g., 'top-talkers') per individual targets.
	7.3.4. Top-Talker of Each Target		The DOTS client may log pre-mitigation telemetry data with an alert
			to an administrator or a network controller. The DOTS client may
			send a mitigation request if the attack cannot be handled locally.
	<<Each target victim (target) address should be included in the list		8. DOTS Telemetry Mitigation Status Update
	of target-prefix* in each pre-mitigation, and several pre-mitigations
	should be included in the pre-mitigation*.>>
	8. DOTS Telemetry from Servers to Clients		8.1. DOTS Client to Server Mitigation Efficacy DOTS Telemetry
			Attributes
	8.1. DOTS Server to Client Mitigation Status DOTS Telemetry Attributes		The mitigation efficacy telemetry attributes can be signaled from
			DOTS clients to DOTS servers as part of the periodic mitigation
			efficacy updates to the server (Section 5.3.4 of
			[I-D.ietf-dots-signal-channel]).
			Total Attack Traffic: The overall attack traffic as observed from
			the DOTS client perspective during an active mitigation. See
			Figure 24.
			Attack Details: The overall attack details as observed from the
			DOTS client perspective during an active mitigation. See
			Section 7.1.5.
			The "ietf-dots-telemetry" YANG module augments the "mitigation-scope"
			type message defined in "ietf-dots-signal" so that these attributes
			can be signalled by a DOTS client in a mitigation efficacy update
			(Figure 32).
			augment /ietf-signal:dots-signal/ietf-signal:message-type
			/ietf-signal:mitigation-scope/ietf-signal:scope:
			+--rw total-attack-traffic* [unit] {dots-telemetry}?
			| ...
			+--rw attack-detail {dots-telemetry}?
			+--rw id? uint32
			+--rw attack-id? string
			+--rw attack-name? string
			+--rw attack-severity? attack-severity
			+--rw start-time? uint64
			+--rw end-time? uint64
			+--rw source-count
			| ...
			+--rw top-talker
			...
			Figure 32: Telemetry Efficacy Update Tree Structure
			In order to signal telemetry data in a mitigation efficacy update, it
			is RECOMMENDED that the DOTS client has already established a DOTS
			telemetry setup session with the server in 'idle' time.
			Header: PUT (Code=0.03)
			Uri-Path: ".well-known"
			Uri-Path: "dots"
			Uri-Path: "mitigate"
			Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
			Uri-Path: "mid=123"
			If-Match:
			Content-Format: "application/dots+cbor"
			{
			"ietf-dots-signal-channel:mitigation-scope": {
			"scope": [
			{
			"alias-name": [
			"myserver"
			],
			"attack-status": "under-attack",
			"ietf-dots-telemetry:total-attack-traffic": [
			{
			"ietf-dots-telemetry:unit": "megabytes-ps",
			"ietf-dots-telemetry:mid-percentile-g": "900"
			}
			]
			}
			]
			}
			}
			Figure 33: An Example of Mitigation Efficacy Update with Telemetry
			Attributes
			8.2. DOTS Server to Client Mitigation Status DOTS Telemetry 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
	in [RFC7641].		in [RFC7641].
	The "ietf-dots-telemetry" YANG module augments the "mitigation-scope"		In order to make use of this feature, DOTS clients MUST establish a
	type message defined in "ietf-dots-signal" with telemetry data as		telemetry setup session with the DOTS server in 'idle' time and MUST
	depicted in following tree structure:		set the 'server-originated-telemetry' attribute to 'true'.
			DOTS servers MUST NOT include telemetry attributes in mitigation
			status updates sent to DOTS clients for which 'server-originated-
			telemetry' attribute is set to 'false'.
			As defined in [RFC8612], the actual mitigation activities can include
			several countermeasure mechanisms. The DOTS server signals the
			current operational status to each relevant countermeasure. A list
			of attacks detected by each countermeasure MAY also be included. The
			same attributes defined for Section 7.1.5 are applicable for
			describing the attacks detected and mitigated.
			The "ietf-dots-telemetry" YANG module (Section 9) augments the
			"mitigation-scope" type message defined in "ietf-dots-signal" with
			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:
	+--rw total-traffic* [unit protocol] {dots-telemetry}?		+--ro total-traffic* [unit protocol] {dots-telemetry}?
	| +--rw unit unit		| +--ro unit unit
	| +--rw protocol uint8		| +--ro protocol uint8
	| +--rw low-percentile-g? yang:gauge64		| +--ro low-percentile-g? yang:gauge64
	| +--rw mid-percentile-g? yang:gauge64		| +--ro mid-percentile-g? yang:gauge64
	| +--rw high-percentile-g? yang:gauge64		| +--ro high-percentile-g? yang:gauge64
	| +--rw 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
	+--rw total-attack-connection {dots-telemetry}?		+--ro total-attack-connection {dots-telemetry}?
	| +--rw low-percentile-c		| +--ro low-percentile-c
	| | +--rw connection? yang:gauge64		| | +--ro connection? yang:gauge64
	| | +--rw embryonic? yang:gauge64		| | +--ro embryonic? yang:gauge64
	| | +--rw connection-ps? yang:gauge64		| | +--ro connection-ps? yang:gauge64
	| | +--rw request-ps? yang:gauge64		| | +--ro request-ps? yang:gauge64
	| | +--rw partial-request-ps? yang:gauge64		| | +--ro partial-request-ps? yang:gauge64
	| +--rw mid-percentile-c		| +--ro mid-percentile-c
	| | +--rw connection? yang:gauge64		| | ...
	| | +--rw embryonic? yang:gauge64		| +--ro high-percentile-c
	| | +--rw connection-ps? yang:gauge64		| | ...
	| | +--rw request-ps? yang:gauge64		| +--ro peak-c
	| | +--rw partial-request-ps? yang:gauge64		| ...
	| +--rw high-percentile-c
	| | +--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-c
	| +--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 {dots-telemetry}?		+--rw attack-detail {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
	skipping to change at page 42, line 25 ¶		skipping to change at page 45, line 25 ¶
	| +--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-c		+--rw low-percentile-c
	| +--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-c		+--rw mid-percentile-c
	| +--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-c		+--rw high-percentile-c
	| +--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-c		+--rw peak-c
	+--rw connection? yang:gauge64		...
	+--rw embryonic? yang:gauge64
	+--rw connection-ps? yang:gauge64
	+--rw request-ps? yang:gauge64
	+--rw partial-request-ps? yang:gauge64
	8.1.1. Mitigation Status
	As defined in [RFC8612], the actual mitigation activities can include
	several countermeasure mechanisms. The DOTS server SHOULD signal the
	current operational status to each relevant countermeasure. A list
	of attacks detected by each countermeasure.
	The same attributes defined for Section 7.1.4 are applicable for
	describing the attacks detected and mitigated.
	8.2. DOTS Detector to Clients Detection Telemetry
	The attack details can also be signaled from DOTS servers to DOTS		Figure 34 shows an example of an asynchronous notification of attack
	clients. For example, the DOTS server co-located with a DDoS		mitigation status from the DOTS server. This notification signals
	detector collects monitoring information from the target network,		both the mid-percentile value of processed attack traffic and the
	identifies DDoS attack using statistical analysis or deep learning		peak percentile value of unique sources involved in the attack.
	techniques, and signals the attack details to the DOTS client.
	The DOTS client can use the attack details to decide whether to		{
	trigger a DOTS mitigation request or not. Furthermore, the security		"ietf-dots-signal-channel:mitigation-scope": {
	operation personnel at the DOTS client domain can use the attack		"scope": [
	details to determine the protection strategy and select the		{
	appropriate DOTS server for mitigating the attack.		"mid": 12332,
			"mitigation-start": "1507818434",
			"alias-name": [
			"myserver"
			],
			"lifetime": 1600,
			"status": "attack-successfully-mitigated",
			"bytes-dropped": "134334555",
			"bps-dropped": "43344",
			"pkts-dropped": "333334444",
			"pps-dropped": "432432",
			"ietf-dots-telemetry:total-attack-traffic": [
			{
			"ietf-dots-telemetry:unit": "megabytes-ps",
			"ietf-dots-telemetry:mid-percentile-g": "900"
			}
			],
			"ietf-dots-telemetry::attack-detail": {
			"ietf-dots-telemetry:source-count": {
			"ietf-dots-telemetry:peak-g": "10000"
			}
			}
			}
			]
			}
			}
	<<to be further discussed>>		Figure 34: Response Body of a Mitigation Status With Telemetry
			Attributes
	9. YANG Module		9. YANG Module
	This module uses types defined in [RFC6991].		This module uses types defined in [RFC6991] and [RFC8345].
	<CODE BEGINS> file "ietf-dots-telemetry@2020-01-23.yang"		<CODE BEGINS> file "ietf-dots-telemetry@2020-01-23.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
	skipping to change at page 45, line 44 ¶		skipping to change at page 49, line 14 ¶
	"Packets per second (PPS).";		"Packets per second (PPS).";
	}		}
	enum kilo-pps {		enum kilo-pps {
	value 2;		value 2;
	description		description
	"Kilo packets per second (Kpps).";		"Kilo packets per second (Kpps).";
	}		}
	enum bps {		enum bps {
	value 3;		value 3;
	description		description
	"Bits per Second (BPS).";		"Bit per Second (BPS).";
	}		}
	enum kilobytes-ps {		enum kilobyte-ps {
	value 4;		value 4;
	description		description
	"Kilobytes per second.";		"Kilobyte per second.";
	}		}
	enum megabytes-ps {		enum megabyte-ps {
	value 5;		value 5;
	description		description
	"Megabytes per second.";		"Megabyte per second.";
	}		}
	enum gigabytes-ps {		enum gigabit-ps {
	value 6;		value 6;
	description		description
	"Gigabytes per second.";		"Gigabit per second.";
			}
			enum gigabyte-ps {
			value 7;
			description
			"Gigabyte per second.";
			}
			enum terabit-ps {
			value 8;
			description
			"Terabit per second.";
	}		}
	}		}
	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 57, line 4 ¶		skipping to change at page 60, line 34 ¶
	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 {
			type string;
			description
			"An alias name that points to a resource.";
			}
	list total-traffic-normal-baseline {		list total-traffic-normal-baseline {
	key "unit protocol";		key "unit protocol";
	description		description
	"Total traffic normal baselines.";		"Total traffic normal baselines.";
	uses traffic-unit-protocol;		uses traffic-unit-protocol;
	}		}
	list total-connection-capacity {		list total-connection-capacity {
	key "protocol";		key "protocol";
	description		description
	"Total connection capacity.";		"Total connection capacity.";
	skipping to change at page 58, line 4 ¶		skipping to change at page 61, line 38 ¶
	list total-attack-traffic {		list total-attack-traffic {
	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;
	}		}
	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 attack-detail {
	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 protocol";
			config false;
	description		description
	"Total traffic.";		"Total traffic.";
	uses traffic-unit-protocol;		uses traffic-unit-protocol;
	}		}
	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;
	description		description
	"Total attack connections.";		"Total attack connections.";
	uses connection-percentile;		uses connection-percentile;
	}		}
	container attack-detail {		container attack-detail {
	description		description
	"Atatck details";		"Atatck details";
	uses attack-detail;		uses attack-detail;
	container top-talker {		container top-talker {
	description		description
	skipping to change at page 60, line 7 ¶		skipping to change at page 63, line 43 ¶
	"Can be a mitigation configuration, a pipe capacity,		"Can be a mitigation configuration, a pipe capacity,
	or baseline message.";		or baseline message.";
	case telemetry-config {		case telemetry-config {
	description		description
	"Uses to set low, mid, and high percentile values.";		"Uses to set low, mid, and high percentile values.";
	container current-config {		container current-config {
	description		description
	"Current configuration values.";		"Current configuration values.";
	uses percentile-config;		uses percentile-config;
	uses unit-config;		uses unit-config;
	leaf server-initiated-telemetry {		leaf server-originated-telemetry {
	type boolean;		type boolean;
	description		description
	"Used by a DOTS client to enable/disable whether it		"Used by a DOTS client to enable/disable whether it
	accepts pre-mitigation telemetry from the DOTS		accepts pre-mitigation telemetry from the DOTS
	server.";		server.";
	}		}
	leaf telemetry-notify-interval {		leaf telemetry-notify-interval {
	type uint32 {		type uint32 {
	range "1 .. 3600";		range "1 .. 3600";
	}		}
	units "seconds";		units "seconds";
	description		description
	"Minimum number of seconds between successive		"Minimum number of seconds between successive
	telemetry notifications.";		telemetry notifications.";
	}		}
	}		}
	container max-config-values {		container max-config-values {
			config false;
	description		description
	"Maximum acceptable configuration values.";		"Maximum acceptable configuration values.";
	config false;
	uses percentile-config;		uses percentile-config;
	// Check if this is right place for indciating this capability		// Check if this is right place for indciating this capability
	leaf server-initiated-telemetry {		leaf server-originated-telemetry {
	type boolean;		type boolean;
	description		description
	"Indicates whether the DOTS server can be instructed		"Indicates whether the DOTS server can be instructed
	to send pre-mitigation telemetry. If set to FALSE		to send pre-mitigation telemetry. If set to FALSE
	or the attribute is not present, this is an indication		or the attribute is not present, this is an indication
	that the server does not support this capability.";		that the server does not support this capability.";
	}		}
	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 min-config-values {		container min-config-values {
			config false;
	description		description
	"Minimum acceptable configuration values.";		"Minimum acceptable configuration values.";
	config false;
	uses percentile-config;		uses percentile-config;
	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 supported-units {		container supported-units {
			config false;
	description		description
	"Supported units and default activation status.";		"Supported units and default activation status.";
	config false;
	uses unit-config;		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.";
	skipping to change at page 62, line 16 ¶		skipping to change at page 66, line 4 ¶
	key "id";		key "id";
	description		description
	"Traffic baseline information";		"Traffic baseline information";
	leaf id {		leaf id {
	type uint32;		type uint32;
	must '. >= 1';		must '. >= 1';
	description		description
	"A baseline entry identifier.";		"A baseline entry identifier.";
	}		}
	uses baseline;		uses baseline;
	}		}
	}		}
	}		}
	}		}
	}		}
	case telemetry {		case telemetry {
	description		description
	"Indicates the message is about telemetry.";		"Indicates the message is about telemetry.";
	list pre-mitigation {		list pre-mitigation {
	key "cuid id";		key "cuid tmid";
	description		description
	"Pre-mitigation telemetry per DOTS client.";		"Pre-mitigation telemetry 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
	cuid will remain consistent throughout the		cuid will remain consistent throughout the
	lifetime of the DOTS client.";		lifetime of the DOTS client.";
	skipping to change at page 62, line 50 ¶		skipping to change at page 66, line 39 ¶
	"The cdid should be included by a server-domain		"The cdid should be included by a server-domain
	DOTS gateway to propagate the client domain		DOTS gateway to propagate the client domain
	identification information from the		identification information from the
	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 id {		leaf tmid {
	type uint32;		type uint32;
	description		description
	"An identifier to uniquely demux telemetry data send using		"An identifier to uniquely demux telemetry data send using
	the same message.";		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 {
			type string;
			description
			"An alias name that points to a resource.";
			}
	}		}
	uses pre-mitigation;		uses pre-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 Some of these attributes should be prepended with "ietf-dots-
			telemetry:"
			o Implementers may use the values in: https://github.com/boucadair/
			draft-dots-telemetry/blob/master/mapping-table.txt
	+----------------------+-------------+------+---------------+--------+		+----------------------+-------------+------+---------------+--------+
	| Parameter Name | YANG | CBOR | CBOR Major | JSON |		| Parameter Name | YANG | CBOR | CBOR Major | JSON |
	| | Type | Key | Type & | Type |		| | Type | Key | Type & | Type |
	| | | | Information | |		| | | | Information | |
	+----------------------+-------------+------+---------------+--------+		+----------------------+-------------+------+---------------+--------+
	| ietf-dots-signal-cha | | | | |		| ietf-dots-telemetry: | | | | |
	| nnel:telemetry | container |32776 | 5 map | Object |		| telemetry | container |TBA1 | 5 map | Object |
	| tsid | uint32 |32777 | 0 unsigned | Number |		| tsid | uint32 |TBA2 | 0 unsigned | Number |
	| telemetry-config | container |32778 | 5 map | Object |		| telemetry-config | container |TBA3 | 5 map | Object |
	| low-percentile | decimal64 |32779 | 6 tag 4 | |		| low-percentile | decimal64 |TBA4 | 6 tag 4 | |
	| | | | [-2, integer]| String |		| | | | [-2, integer]| String |
	| mid-percentile | decimal64 |32780 | 6 tag 4 | |		| mid-percentile | decimal64 |TBA5 | 6 tag 4 | |
	| | | | [-2, integer]| String |		| | | | [-2, integer]| String |
	| high-percentile | decimal64 |32781 | 6 tag 4 | |		| high-percentile | decimal64 |TBA6 | 6 tag 4 | |
	| | | | [-2, integer]| String |		| | | | [-2, integer]| String |
	| unit-config | list |32782 | 4 array | Array |		| unit-config | list |TBA7 | 4 array | Array |
	| unit | enumeration |32783 | 0 unsigned | String |		| unit | enumeration |TBA8 | 0 unsigned | String |
	| unit-status | boolean |32784 | 7 bits 20 | False |		| unit-status | boolean |TBA9 | 7 bits 20 | False |
	| | | | 7 bits 21 | True |		| | | | 7 bits 21 | True |
	| total-pipe-capability| list |32785 | 4 array | Array |		| total-pipe-capability| list |TBA10 | 4 array | Array |
	| pipe | uint64 |32786 | 0 unsigned | String |		| pipe | uint64 |TBA11 | 0 unsigned | String |
	| pre-mitigation | list |32787 | 4 array | Array |		| pre-mitigation | list |TBA12 | 4 array | Array |
	| ietf-dots-signal-cha | | | | |		| ietf-dots-telemetry: | | | | |
	| nnel:telemetry-setup | container |32888 | 5 map | Object |		| telemetry-setup | container |TBA13 | 5 map | Object |
	| total-traffic- | | | | |		| total-traffic- | | | | |
	| normal-baseline | list |32789 | 4 array | Array |		| normal-baseline | list |TBA14 | 4 array | Array |
	| low-percentile-g | yang:gauge64|32790 | 0 unsigned | String |		| low-percentile-g | yang:gauge64|TBA15 | 0 unsigned | String |
	| mid-percentile-g | yang:gauge64|32791 | 0 unsigned | String |		| mid-percentile-g | yang:gauge64|TBA16 | 0 unsigned | String |
	| high-percentile-g | yang:gauge64|32792 | 0 unsigned | String |		| high-percentile-g | yang:gauge64|TBA17 | 0 unsigned | String |
	| peak-g | yang:gauge64|32793 | 0 unsigned | String |		| peak-g | yang:gauge64|TBA18 | 0 unsigned | String |
	| total-attack-traffic | list |32794 | 4 array | Array |		| total-attack-traffic | list |TBA19 | 4 array | Array |
	| total-traffic | list |32795 | 4 array | Array |		| total-traffic | list |TBA20 | 4 array | Array |
	| total-connection- | | | | |		| total-connection- | | | | |
	| capacity | list |32796 | 4 array | Array |		| capacity | list |TBA21 | 4 array | Array |
	| connection | uint64 |32797 | 0 unsigned | String |		| connection | uint64 |TBA22 | 0 unsigned | String |
	| connection-client | uint64 |32798 | 0 unsigned | String |		| connection-client | uint64 |TBA23 | 0 unsigned | String |
	| embryonic | uint64 |32799 | 0 unsigned | String |		| embryonic | uint64 |TBA24 | 0 unsigned | String |
	| embryonic-client | uint64 |32800 | 0 unsigned | String |		| embryonic-client | uint64 |TBA25 | 0 unsigned | String |
	| connection-ps | uint64 |32801 | 0 unsigned | String |		| connection-ps | uint64 |TBA26 | 0 unsigned | String |
	| connection-client-ps | uint64 |32802 | 0 unsigned | String |		| connection-client-ps | uint64 |TBA27 | 0 unsigned | String |
	| request-ps | uint64 |32803 | 0 unsigned | String |		| request-ps | uint64 |TBA28 | 0 unsigned | String |
	| request-client-ps | uint64 |32804 | 0 unsigned | String |		| request-client-ps | uint64 |TBA29 | 0 unsigned | String |
	| partial-request-ps | uint64 |32805 | 0 unsigned | String |		| partial-request-ps | uint64 |TBA30 | 0 unsigned | String |
	| partial-request- | | | | |		| partial-request- | | | | |
	| client-ps | uint64 |32806 | 0 unsigned | String |		| client-ps | uint64 |TBA31 | 0 unsigned | String |
	| total-attack- | | | | |		| total-attack- | | | | |
	| connection | container |32807 | 5 map | Object |		| connection | container |TBA32 | 5 map | Object |
	| low-percentile-l | list |32808 | 4 array | Array |		| low-percentile-l | list |TBA33 | 4 array | Array |
	| mid-percentile-l | list |32809 | 4 array | Array |		| mid-percentile-l | list |TBA34 | 4 array | Array |
	| high-percentile-l | list |32810 | 4 array | Array |		| high-percentile-l | list |TBA35 | 4 array | Array |
	| peak-l | list |32811 | 4 array | Array |		| peak-l | list |TBA36 | 4 array | Array |
	| attack-detail | container |32812 | 5 map | Object |		| attack-detail | container |TBA37 | 5 map | Object |
	| id | uint32 |32813 | 0 unsigned | Number |		| id | uint32 |TBA38 | 0 unsigned | Number |
	| attack-id | string |32814 | 3 text string | String |		| attack-id | string |TBA39 | 3 text string | String |
	| attack-name | string |32815 | 3 text string | String |		| attack-name | string |TBA40 | 3 text string | String |
	| attack-severity | enumeration |32816 | 0 unsigned | String |		| attack-severity | enumeration |TBA41 | 0 unsigned | String |
	| start-time | uint64 |32817 | 0 unsigned | String |		| start-time | uint64 |TBA42 | 0 unsigned | String |
	| end-time | uint64 |32819 | 0 unsigned | String |		| end-time | uint64 |TBA43 | 0 unsigned | String |
	| source-count | container |32820 | 5 map | Object |		| source-count | container |TBA44 | 5 map | Object |
	| top-talker | container |32821 | 5 map | Object |		| top-talker | container |TBA45 | 5 map | Object |
	| spoofed-status | boolean |32822 | 7 bits 20 | False |		| spoofed-status | boolean |TBA46 | 7 bits 20 | False |
	| | | | 7 bits 21 | True |		| | | | 7 bits 21 | True |
	| low-percentile-c | container |32823 | 5 map | Object |		| low-percentile-c | container |TBA47 | 5 map | Object |
	| mid-percentile-c | container |32824 | 5 map | Object |		| mid-percentile-c | container |TBA48 | 5 map | Object |
	| high-percentile-c | container |32825 | 5 map | Object |		| high-percentile-c | container |TBA49 | 5 map | Object |
	| peak-c | container |32826 | 5 map | Object |		| peak-c | container |TBA50 | 5 map | Object |
	| baseline | container |32827 | 5 map | Object |		| baseline | container |TBA51 | 5 map | Object |
	| current-config | container |32828 | 5 map | Object |		| current-config | container |TBA52 | 5 map | Object |
	| max-config-values | container |32829 | 5 map | Object |		| max-config-values | container |TBA53 | 5 map | Object |
	| min-config-values | container |32830 | 5 map | Object |		| min-config-values | container |TBA54 | 5 map | Object |
	| supported-units | container |32831 | 5 map | Object |		| supported-units | container |TBA55 | 5 map | Object |
	| server-initiated- | boolean |32832 | 7 bits 20 | False |		| server-originated- | boolean |TBA56 | 7 bits 20 | False |
	| telemetry | | | 7 bits 21 | True |		| telemetry | | | 7 bits 21 | True |
	| telemetry-notify- | uint32 |32833 | 0 unsigned | Number |		| telemetry-notify- | uint32 |TBA57 | 0 unsigned | Number |
	| interval | | | | |		| interval | | | | |
			| tmid | uint32 |TBA58 | 0 unsigned | Number |
	+----------------------+-------------+------+---------------+--------+		+----------------------+-------------+------+---------------+--------+
	11. IANA Considerations		11. IANA Considerations
	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 65, line 27 ¶		skipping to change at page 69, line 27 ¶
	o Note to the RFC Editor: (1) CBOR keys are assigned from the		o Note to the RFC Editor: (1) CBOR keys are assigned from the
	32768-49151 range. (2) Please assign the following suggested		32768-49151 range. (2) Please assign the following suggested
	values.		values.
	+----------------------+-------+-------+------------+---------------+		+----------------------+-------+-------+------------+---------------+
	| Parameter Name | CBOR | CBOR | Change | Specification |		| Parameter Name | CBOR | CBOR | Change | Specification |
	| | Key | Major | Controller | Document(s) |		| | Key | Major | Controller | Document(s) |
	| | Value | Type | | |		| | Value | Type | | |
	+----------------------+-------+-------+------------+---------------+		+----------------------+-------+-------+------------+---------------+
	| ietf-dots-signal-cha | 32776 | 5 | IESG | [RFCXXXX] |		| ietf-dots-telemetry: | TBA1 | 5 | IESG | [RFCXXXX] |
	| nnel:telemetry | | | | |		| telemetry | | | | |
	| tsid | 32777 | 0 | IESG | [RFCXXXX] |		| tsid | TBA2 | 0 | IESG | [RFCXXXX] |
	| telemetry-config | 32778 | 5 | IESG | [RFCXXXX] |		| telemetry-config | TBA3 | 5 | IESG | [RFCXXXX] |
	| low-percentile | 32779 | 6tag4 | IESG | [RFCXXXX] |		| low-percentile | TBA4 | 6tag4 | IESG | [RFCXXXX] |
	| mid-percentile | 32780 | 6tag4 | IESG | [RFCXXXX] |		| mid-percentile | TBA5 | 6tag4 | IESG | [RFCXXXX] |
	| high-percentile | 32781 | 6tag4 | IESG | [RFCXXXX] |		| high-percentile | TBA6 | 6tag4 | IESG | [RFCXXXX] |
	| unit-config | 32782 | 4 | IESG | [RFCXXXX] |		| unit-config | TBA7 | 4 | IESG | [RFCXXXX] |
	| unit | 32783 | 0 | IESG | [RFCXXXX] |		| unit | TBA8 | 0 | IESG | [RFCXXXX] |
	| unit-status | 32784 | 7 | IESG | [RFCXXXX] |		| unit-status | TBA9 | 7 | IESG | [RFCXXXX] |
	| total-pipe-capability| 32785 | 4 | IESG | [RFCXXXX] |		| total-pipe-capability| TBA10 | 4 | IESG | [RFCXXXX] |
	| pipe | 32786 | 0 | IESG | [RFCXXXX] |		| pipe | TBA11 | 0 | IESG | [RFCXXXX] |
	| pre-mitigation | 32787 | 4 | IESG | [RFCXXXX] |		| pre-mitigation | TBA12 | 4 | IESG | [RFCXXXX] |
	| ietf-dots-signal-cha | 32788 | 5 | IESG | [RFCXXXX] |		| ietf-dots-telemetry: | TBA13 | 5 | IESG | [RFCXXXX] |
	| nnel:telemetry | | | | |		| telemetry-setup | | | | |
	| total-traffic- | 32789 | 4 | IESG | [RFCXXXX] |		| total-traffic- | TBA14 | 4 | IESG | [RFCXXXX] |
	| normal-baseline | | | | |		| normal-baseline | | | | |
	| low-percentile-g | 32790 | 0 | IESG | [RFCXXXX] |		| low-percentile-g | TBA15 | 0 | IESG | [RFCXXXX] |
	| mid-percentile-g | 32791 | 0 | IESG | [RFCXXXX] |		| mid-percentile-g | TBA16 | 0 | IESG | [RFCXXXX] |
	| high-percentile-g | 32792 | 0 | IESG | [RFCXXXX] |		| high-percentile-g | TBA17 | 0 | IESG | [RFCXXXX] |
	| peak-g | 32793 | 0 | IESG | [RFCXXXX] |		| peak-g | TBA18 | 0 | IESG | [RFCXXXX] |
	| total-attack-traffic | 32794 | 4 | IESG | [RFCXXXX] |		| total-attack-traffic | TBA19 | 4 | IESG | [RFCXXXX] |
	| total-traffic | 32795 | 4 | IESG | [RFCXXXX] |		| total-traffic | TBA20 | 4 | IESG | [RFCXXXX] |
	| total-connection- | 32796 | 4 | IESG | [RFCXXXX] |		| total-connection- | TBA21 | 4 | IESG | [RFCXXXX] |
	| capacity | | | | |		| capacity | | | | |
	| connection | 32797 | 0 | IESG | [RFCXXXX] |		| connection | TBA22 | 0 | IESG | [RFCXXXX] |
	| connection-client | 32798 | 0 | IESG | [RFCXXXX] |		| connection-client | TBA23 | 0 | IESG | [RFCXXXX] |
	| embryonic | 32799 | 0 | IESG | [RFCXXXX] |		| embryonic | TBA24 | 0 | IESG | [RFCXXXX] |
	| embryonic-client | 32800 | 0 | IESG | [RFCXXXX] |		| embryonic-client | TBA25 | 0 | IESG | [RFCXXXX] |
	| connection-ps | 32801 | 0 | IESG | [RFCXXXX] |		| connection-ps | TBA26 | 0 | IESG | [RFCXXXX] |
	| connection-client-ps | 32802 | 0 | IESG | [RFCXXXX] |		| connection-client-ps | TBA27 | 0 | IESG | [RFCXXXX] |
	| request-ps | 32803 | 0 | IESG | [RFCXXXX] |		| request-ps | TBA28 | 0 | IESG | [RFCXXXX] |
	| request-client-ps | 32804 | 0 | IESG | [RFCXXXX] |		| request-client-ps | TBA29 | 0 | IESG | [RFCXXXX] |
	| partial-request-ps | 32805 | 0 | IESG | [RFCXXXX] |		| partial-request-ps | TBA30 | 0 | IESG | [RFCXXXX] |
	| partial-request- | 32806 | 0 | IESG | [RFCXXXX] |		| partial-request- | TBA31 | 0 | IESG | [RFCXXXX] |
	| client-ps | | | | |		| client-ps | | | | |
	| total-attack- | 32807 | 5 | IESG | [RFCXXXX] |		| total-attack- | TBA32 | 5 | IESG | [RFCXXXX] |
	| connection | | | | |		| connection | | | | |
	| low-percentile-l | 32808 | 4 | IESG | [RFCXXXX] |		| low-percentile-l | TBA33 | 4 | IESG | [RFCXXXX] |
	| mid-percentile-l | 32809 | 4 | IESG | [RFCXXXX] |		| mid-percentile-l | TBA34 | 4 | IESG | [RFCXXXX] |
	| high-percentile-l | 32810 | 4 | IESG | [RFCXXXX] |		| high-percentile-l | TBA35 | 4 | IESG | [RFCXXXX] |
	| peak-l | 32811 | 4 | IESG | [RFCXXXX] |		| peak-l | TBA36 | 4 | IESG | [RFCXXXX] |
	| attack-detail | 32812 | 5 | IESG | [RFCXXXX] |		| attack-detail | TBA37 | 5 | IESG | [RFCXXXX] |
	| id | 32813 | 0 | IESG | [RFCXXXX] |		| id | TBA38 | 0 | IESG | [RFCXXXX] |
	| attack-id | 32814 | 3 | IESG | [RFCXXXX] |		| attack-id | TBA39 | 3 | IESG | [RFCXXXX] |
	| attack-name | 32815 | 3 | IESG | [RFCXXXX] |		| attack-name | TBA40 | 3 | IESG | [RFCXXXX] |
	| attack-severity | 32816 | 0 | IESG | [RFCXXXX] |		| attack-severity | TBA41 | 0 | IESG | [RFCXXXX] |
	| start-time | 32817 | 0 | IESG | [RFCXXXX] |		| start-time | TBA42 | 0 | IESG | [RFCXXXX] |
	| end-time | 32819 | 0 | IESG | [RFCXXXX] |		| end-time | TBA43 | 0 | IESG | [RFCXXXX] |
	| source-count | 32820 | 5 | IESG | [RFCXXXX] |		| source-count | TBA44 | 5 | IESG | [RFCXXXX] |
	| top-talker | 32821 | 5 | IESG | [RFCXXXX] |		| top-talker | TBA45 | 5 | IESG | [RFCXXXX] |
	| spoofed-status | 32822 | 7 | IESG | [RFCXXXX] |		| spoofed-status | TBA46 | 7 | IESG | [RFCXXXX] |
	| low-percentile-c | 32823 | 5 | IESG | [RFCXXXX] |		| low-percentile-c | TBA47 | 5 | IESG | [RFCXXXX] |
	| mid-percentile-c | 32824 | 5 | IESG | [RFCXXXX] |		| mid-percentile-c | TBA48 | 5 | IESG | [RFCXXXX] |
	| high-percentile-c | 32825 | 5 | IESG | [RFCXXXX] |		| high-percentile-c | TBA49 | 5 | IESG | [RFCXXXX] |
	| peak-c | 32826 | 5 | IESG | [RFCXXXX] |		| peak-c | TBA50 | 5 | IESG | [RFCXXXX] |
	| ietf-dots-signal-cha | 32827 | 5 | IESG | [RFCXXXX] |		| ietf-dots-signal-cha | TBA51 | 5 | IESG | [RFCXXXX] |
	| current-config | 32828 | 5 | IESG | [RFCXXXX] |		| current-config | TBA52 | 5 | IESG | [RFCXXXX] |
	| max-config-value | 32829 | 5 | IESG | [RFCXXXX] |		| max-config-value | TBA53 | 5 | IESG | [RFCXXXX] |
	| min-config-values | 32830 | 5 | IESG | [RFCXXXX] |		| min-config-values | TBA54 | 5 | IESG | [RFCXXXX] |
	| supported-units | 32831 | 5 | IESG | [RFCXXXX] |		| supported-units | TBA55 | 5 | IESG | [RFCXXXX] |
	| server-initiated- | 32832 | 7 | IESG | [RFCXXXX] |		| server-originated- | TBA56 | 7 | IESG | [RFCXXXX] |
	| telemetry | | | | |		| telemetry | | | | |
	| telemetry-notify- | 32833 | 0 | IESG | [RFCXXXX] |		| telemetry-notify- | TBA57 | 0 | IESG | [RFCXXXX] |
	| interval | | | | |		| interval | | | | |
			| tmid | TBA58 | 0 | IESG | [RFCXXXX] |
	+----------------------+-------+-------+------------+---------------+		+----------------------+-------+-------+------------+---------------+
	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.
	Code Label Description Reference		Code Label Description Reference
	skipping to change at page 68, line 32 ¶		skipping to change at page 72, line 35 ¶
	Channel Call Home", draft-ietf-dots-signal-call-home-07		Channel Call Home", draft-ietf-dots-signal-call-home-07
	(work in progress), November 2019.		(work in progress), November 2019.
	[I-D.ietf-dots-signal-channel]		[I-D.ietf-dots-signal-channel]
	Reddy.K, T., Boucadair, M., Patil, P., Mortensen, A., and		Reddy.K, T., Boucadair, M., Patil, P., Mortensen, A., and
	N. Teague, "Distributed Denial-of-Service Open Threat		N. Teague, "Distributed Denial-of-Service Open Threat
	Signaling (DOTS) Signal Channel Specification", draft-		Signaling (DOTS) Signal Channel Specification", draft-
	ietf-dots-signal-channel-41 (work in progress), January		ietf-dots-signal-channel-41 (work in progress), January
	2020.		2020.
			[I-D.ietf-dots-signal-filter-control]
			Nishizuka, K., Boucadair, M., Reddy.K, T., and T. Nagata,
			"Controlling Filtering Rules Using Distributed Denial-of-
			Service Open Threat Signaling (DOTS) Signal Channel",
			draft-ietf-dots-signal-filter-control-02 (work in
			progress), September 2019.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,		[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
	DOI 10.17487/RFC3688, January 2004,		DOI 10.17487/RFC3688, January 2004,
	<https://www.rfc-editor.org/info/rfc3688>.		<https://www.rfc-editor.org/info/rfc3688>.
	[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",		[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
	skipping to change at page 69, line 20 ¶		skipping to change at page 73, line 33 ¶
	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>.
	15.2. Informative References		15.2. Informative References
	[I-D.ietf-dots-signal-filter-control]		[I-D.ietf-dots-multihoming]
	Nishizuka, K., Boucadair, M., Reddy.K, T., and T. Nagata,		Boucadair, M., Reddy.K, T., and W. Pan, "Multi-homing
	"Controlling Filtering Rules Using Distributed Denial-of-		Deployment Considerations for Distributed-Denial-of-
	Service Open Threat Signaling (DOTS) Signal Channel",		Service Open Threat Signaling (DOTS)", draft-ietf-dots-
	draft-ietf-dots-signal-filter-control-02 (work in		multihoming-03 (work in progress), January 2020.
	progress), September 2019.
	[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,
	L., and K. Nishizuka, "Use cases for DDoS Open Threat		L., and K. Nishizuka, "Use cases for DDoS Open Threat
	Signaling", draft-ietf-dots-use-cases-20 (work in		Signaling", draft-ietf-dots-use-cases-20 (work in
	progress), September 2019.		progress), September 2019.
	[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,
End of changes. 231 change blocks.
	652 lines changed or deleted		893 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/