< draft-reddy-dots-telemetry-03.txt		draft-reddy-dots-telemetry-04.txt >
	DOTS T. Reddy		DOTS T. Reddy
	Internet-Draft McAfee		Internet-Draft McAfee
	Intended status: Standards Track M. Boucadair		Intended status: Standards Track M. Boucadair
	Expires: April 6, 2020 Orange		Expires: April 20, 2020 Orange
	E. Doron		E. Doron
	Radware Ltd.		Radware Ltd.
	M. Chen		M. Chen
	CMCC		CMCC
	October 04, 2019		October 18, 2019
	Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry		Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry
	draft-reddy-dots-telemetry-03		draft-reddy-dots-telemetry-04
	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 April 6, 2020.		This Internet-Draft will expire on April 20, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 25 ¶		skipping to change at page 2, line 25 ¶
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. DOTS Telemetry: Overview & Purpose . . . . . . . . . . . . . 5		3. DOTS Telemetry: Overview & Purpose . . . . . . . . . . . . . 5
	4. DOTS Telemetry Attributes . . . . . . . . . . . . . . . . . . 8		4. Generic Considerations . . . . . . . . . . . . . . . . . . . 8
	4.1. Pre-mitigation DOTS Telemetry Attributes . . . . . . . . 8		4.1. DOTS Client Identification . . . . . . . . . . . . . . . 8
	4.1.1. Total Traffic Normal Baseline . . . . . . . . . . . . 9		4.2. DOTS Gateways . . . . . . . . . . . . . . . . . . . . . . 8
	4.1.2. Total Pipe Capability . . . . . . . . . . . . . . . . 9		5. DOTS Telemetry Attributes . . . . . . . . . . . . . . . . . . 9
	4.1.3. Total Attack Traffic . . . . . . . . . . . . . . . . 9		5.1. Pre-mitigation DOTS Telemetry Attributes . . . . . . . . 9
	4.1.4. Total Traffic . . . . . . . . . . . . . . . . . . . . 9		5.1.1. Total Traffic Normal Baseline . . . . . . . . . . . . 9
	4.1.5. Total Connections Capacity . . . . . . . . . . . . . 10		5.1.2. Total Pipe Capability . . . . . . . . . . . . . . . . 9
	4.1.6. Total Attack Connections . . . . . . . . . . . . . . 10		5.1.3. Total Attack Traffic . . . . . . . . . . . . . . . . 10
	4.1.7. Attack Details . . . . . . . . . . . . . . . . . . . 11		5.1.4. Total Traffic . . . . . . . . . . . . . . . . . . . . 10
	4.2. DOTS Client to Server Mitigation Efficacy DOTS Telemetry		5.1.5. Total Connections Capacity . . . . . . . . . . . . . 10
	Attributes . . . . . . . . . . . . . . . . . . . . . . . 13		5.1.6. Total Attack Connections . . . . . . . . . . . . . . 11
	4.2.1. Total Attack Traffic . . . . . . . . . . . . . . . . 13		5.1.7. Attack Details . . . . . . . . . . . . . . . . . . . 11
	4.2.2. Attack Details . . . . . . . . . . . . . . . . . . . 13		5.2. DOTS Client to Server Mitigation Efficacy DOTS Telemetry
	4.3. DOTS Server to Client Mitigation Status DOTS Telemetry
	Attributes . . . . . . . . . . . . . . . . . . . . . . . 13		Attributes . . . . . . . . . . . . . . . . . . . . . . . 13
	4.3.1. Mitigation Status . . . . . . . . . . . . . . . . . . 14		5.2.1. Total Attack Traffic . . . . . . . . . . . . . . . . 14
	5. DOTS Telemetry Configuration . . . . . . . . . . . . . . . . 14		5.2.2. Attack Details . . . . . . . . . . . . . . . . . . . 14
	5.1. Convey DOTS Telemetry Configuration . . . . . . . . . . . 14		5.3. DOTS Server to Client Mitigation Status DOTS Telemetry
	5.2. Delete DOTS Telemetry Configuration . . . . . . . . . . . 15		Attributes . . . . . . . . . . . . . . . . . . . . . . . 14
	6. DOTS Telemetry YANG Module . . . . . . . . . . . . . . . . . 16		5.3.1. Mitigation Status . . . . . . . . . . . . . . . . . . 14
	6.1. Tree Structure . . . . . . . . . . . . . . . . . . . . . 16		6. DOTS Telemetry Configuration . . . . . . . . . . . . . . . . 14
	6.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 21		6.1. Convey DOTS Telemetry Configuration . . . . . . . . . . . 14
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35		6.2. Delete DOTS Telemetry Configuration . . . . . . . . . . . 17
	7.1. DOTS Signal Channel CBOR Mappings Registry . . . . . . . 35		7. DOTS Telemetry YANG Module . . . . . . . . . . . . . . . . . 17
	7.2. DOTS Signal Telemetry YANG Module . . . . . . . . . . . . 36		7.1. Tree Structure . . . . . . . . . . . . . . . . . . . . . 17
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 36		7.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 23
	9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 36		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36		8.1. DOTS Signal Channel CBOR Mappings Registry . . . . . . . 38
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 37		8.2. DOTS Signal Telemetry YANG Module . . . . . . . . . . . . 38
	11.1. Normative References . . . . . . . . . . . . . . . . . . 37
	11.2. Informative References . . . . . . . . . . . . . . . . . 38		9. Security Considerations . . . . . . . . . . . . . . . . . . . 39
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38		10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 39
			11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39
			12. References . . . . . . . . . . . . . . . . . . . . . . . . . 39
			12.1. Normative References . . . . . . . . . . . . . . . . . . 39
			12.2. Informative References . . . . . . . . . . . . . . . . . 40
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
	1. Introduction		1. Introduction
	The Internet security 'battle' between the adversary and security		The Internet security 'battle' between the adversary and security
	countermeasures is an everlasting one. DDoS attacks have become more		countermeasures is an everlasting one. DDoS attacks have become more
	vicious and sophisticated in almost all aspects of their maneuvers		vicious and sophisticated in almost all aspects of their maneuvers
	and malevolent intentions. IT organizations and service providers		and malevolent intentions. IT organizations and service providers
	are facing DDoS attacks that fall into two broad categories: Network/		are facing DDoS attacks that fall into two broad categories: Network/
	Transport layer attacks and Application layer attacks. Network/		Transport layer attacks and Application layer attacks. Network/
	Transport layer attacks target the victim's infrastructure. These		Transport layer attacks target the victim's infrastructure. These
	skipping to change at page 8, line 30 ¶		skipping to change at page 8, line 35 ¶
	for the type of traffic (such as ICMP, UDP, TCP port 80) it prefers		for the type of traffic (such as ICMP, UDP, TCP port 80) it prefers
	to limit.		to limit.
	To summarize, timely and effective signaling of up-to-date DOTS		To summarize, timely and effective signaling of up-to-date DOTS
	telemetry to all elements involved in the mitigation process is		telemetry to all elements involved in the mitigation process is
	essential and absolutely improves the overall service effectiveness.		essential and absolutely improves the overall service effectiveness.
	Bi-directional feedback between DOTS agents is required for the		Bi-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. DOTS Telemetry Attributes		4. Generic Considerations
			4.1. DOTS Client Identification
			Following the rules in [I-D.ietf-dots-signal-channel], a unique
			identifier is generated by a DOTS client to prevent request
			collisions.
			4.2. DOTS Gateways
			DOTS gateways may be located between DOTS clients and servers. The
			considerations elaborated in [I-D.ietf-dots-signal-channel] must be
			followed. In particular, 'cdid' attribute is used to unambiguously
			identify a DOTS client domain.
			5. DOTS Telemetry Attributes
	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 that covers both the		outlines the set of DOTS telemetry attributes that covers both the
	types of attacks. The ultimate objective of these attributes is to		types of attacks. The ultimate objective of these attributes is to
	allow for the complete knowledge of attacks and the various		allow for the complete knowledge of attacks and the various
	particulars that can best characterize attacks.		particulars that can best characterize attacks.
	The description and motivation behind each attribute were presented		The description and motivation behind each attribute were presented
	in Section 3. DOTS telemetry attributes are optionally signaled and		in Section 3. DOTS telemetry attributes are optionally signaled and
	therefore MUST NOT be treated as mandatory fields in the DOTS signal		therefore MUST NOT be treated as mandatory fields in the DOTS signal
	channel protocol.		channel protocol.
	4.1. Pre-mitigation DOTS Telemetry Attributes		5.1. Pre-mitigation DOTS Telemetry Attributes
	The pre-mitigation telemetry attributes are indicated by the path-		The pre-mitigation telemetry attributes are indicated by the path-
	suffix '/telemetry'. The '/telemetry' is appended to the path-prefix		suffix '/telemetry'. The '/telemetry' is appended to the path-prefix
	to form the URI used with a CoAP request to signal the DOTS		to form the URI used with a CoAP request to signal the DOTS
	telemetry. The following pre-mitigation telemetry attributes can be		telemetry. The following pre-mitigation telemetry attributes can be
	signaled from the DOTS client to the DOTS server.		signaled from the DOTS client to the DOTS server.
	o DISCUSSION NOTES: (1) Some telemetry can be communicated using		o DISCUSSION NOTES: (1) Some telemetry can be communicated using
	DOTS data channel. (2) Evaluate the risk of fragmentation,. Some		DOTS data channel. (2) Evaluate the risk of fragmentation,. Some
	of the information is not specific to each mitigation request. (3)		of the information is not specific to each mitigation request. (3)
	Should we define other configuration parameters to be controlled a		Should we define other configuration parameters to be controlled
	DOTS client, e.g., Indicate a favorite measurement unit? Indicate		by a DOTS client, e.g., Indicate a favorite measurement unit?
	a minimum notification interval?		Indicate a minimum notification interval?
	4.1.1. Total Traffic Normal Baseline		5.1.1. Total Traffic Normal Baseline
	The low percentile (10th percentile), mid percentile (50th		The low percentile (10th percentile), mid percentile (50th
	percentile), high percentile (90th percentile) and peak values (100th		percentile), high percentile (90th percentile) and peak values (100th
	percentile) of "Total traffic normal baselines" measured in packets		percentile) of "Total traffic normal baselines" measured in packets
	per second (PPS) or kilo packets per second (Kpps) and Bits per		per second (PPS) or kilo packets per second (Kpps) and Bits per
	Second (BPS), and kilobytes per second or megabytes per second or		Second (BPS), and kilobytes per second or megabytes per second or
	gigabytes per second. For example, 90th percentile says that 90% of		gigabytes per second. For example, 90th percentile says that 90% of
	the time, the total normal traffic is below the limit specified. The		the time, the total normal traffic is below the limit specified. The
	traffic normal baseline is represented for a target and is transport-		traffic normal baseline is represented for a target and is transport-
	protocol specific.		protocol specific.
	4.1.2. Total Pipe Capability		5.1.2. Total Pipe Capability
	The limit of traffic volume, in packets per second (PPS) or kilo		The limit of traffic volume, 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. These		per second or megabytes per second or gigabytes per second. These
	attributes represents the DOTS client domain pipe limit.		attributes represents the DOTS client domain pipe limit.
	o NOTE: Multi-homing case to be considered.		o NOTE: Multi-homing case to be considered.
	4.1.3. Total Attack Traffic		5.1.3. Total Attack Traffic
	The total attack traffic can be identified by the DOTS client		The total attack traffic can be identified by the DOTS client
	domain's DDoS Mitigation System (DMS) or DDoS Detector. The low		domain's DDoS Mitigation System (DMS) or DDoS Detector. The low
	percentile (10th percentile), mid percentile (50th percentile), high		percentile (10th percentile), mid percentile (50th percentile), high
	percentile (90th percentile) and peak values of total attack traffic		percentile (90th percentile) and peak values of total attack traffic
	measured in packets per second (PPS) or kilo packets per second		measured in packets per second (PPS) or kilo packets per second
	(Kpps) and Bits per Second (BPS), and kilobytes per second or		(Kpps) and Bits per Second (BPS), and kilobytes per second or
	megabytes per second or gigabytes per second. The total attack		megabytes per second or gigabytes per second. The total attack
	traffic is represented for a target and is transport-protocol		traffic is represented for a target and is transport-protocol
	specific.		specific.
	4.1.4. Total Traffic		5.1.4. Total Traffic
	The low percentile (10th percentile), mid percentile (50th		The low percentile (10th percentile), mid percentile (50th
	percentile), high percentile (90th percentile) and peak values of		percentile), high percentile (90th percentile) and peak values of
	total traffic during a DDoS attack measured in packets per second		total traffic during a DDoS attack measured in packets per second
	(PPS) or kilo packets per second (Kpps) and Bits per Second (BPS),		(PPS) or kilo packets per second (Kpps) and Bits per Second (BPS),
	and kilobytes per second or megabytes per second gigabytes per		and kilobytes per second or megabytes per second gigabytes per
	second. The total traffic is represented for a target and is		second. The total traffic is represented for a target and is
	transport-protocol specific.		transport-protocol specific.
	4.1.5. Total Connections Capacity		5.1.5. Total Connections Capacity
	If the target is subjected to resource consuming DDoS attack, the		If the target is subjected to resource consuming DDoS attack, the
	following optional attributes for the target per transport-protocol		following optional attributes for the target per transport-protocol
	are useful to detect resource consuming DDoS attacks:		are useful to detect resource consuming DDoS attacks:
	o The maximum number of simultaneous connections that are allowed to		o The maximum number of simultaneous connections that are allowed to
	the target server. The threshold is transport-protocol specific		the target server. The threshold is transport-protocol specific
	because the target server could support multiple protocols.		because the target server could support multiple protocols.
	o The maximum number of simultaneous connections that are allowed to		o The maximum number of simultaneous connections that are allowed to
	skipping to change at page 10, line 47 ¶		skipping to change at page 11, line 20 ¶
	o The maximum number of requests allowed per second to the target		o The maximum number of requests allowed per second to the target
	server per client.		server per client.
	o The maximum number of partial requests allowed per second to the		o The maximum number of partial requests allowed per second to the
	target server.		target server.
	o The maximum number of partial requests allowed per second to the		o The maximum number of partial requests allowed per second to the
	target server per client.		target server per client.
	4.1.6. Total Attack Connections		5.1.6. Total Attack Connections
	If the target is subjected to resource consuming DDoS attack, the low		If the target is subjected to resource consuming DDoS attack, the low
	percentile (10th percentile), mid percentile (50th percentile), high		percentile (10th percentile), mid percentile (50th percentile), high
	percentile (90th percentile) and peak values of following optional		percentile (90th percentile) and peak values of following optional
	attributes for the target per transport-protocol are included to		attributes for the target per transport-protocol are included to
	represent the attack characteristics:		represent the attack characteristics:
	o The number of simultaneous attack connections to the target		o The number of simultaneous attack connections to the target
	server.		server.
	o The number of simultaneous embryonic connections to the target		o The number of simultaneous embryonic connections to the target
	server.		server.
	o The number of attack connections per second to the target server.		o The number of attack connections per second to the target server.
	o The number of attack requests to the target server.		o The number of attack requests to the target server.
	4.1.7. Attack Details		5.1.7. Attack Details
	Various information and details that describe the on-going attacks		Various information and details that describe the on-going attacks
	that needs to be mitigated by the DOTS server. The attack details		that needs to be mitigated by the DOTS server. The attack details
	need to cover well-known and common attacks (such as a SYN Flood)		need to cover well-known and common attacks (such as a SYN Flood)
	along with new emerging or vendor-specific attacks. The attack		along with new emerging or vendor-specific attacks. The attack
	details can also be signaled from the DOTS server to the DOTS client.		details can also be signaled from the DOTS server to the DOTS client.
	For example, the DOTS server co-located with a DDoS detector collects		For example, the DOTS server co-located with a DDoS detector collects
	monitoring information from the target network, identifies DDoS		monitoring information from the target network, identifies DDoS
	attack using statistical analysis or deep learning techniques, and		attack using statistical analysis or deep learning techniques, and
	signals the attack details to the DOTS client. The client can use		signals the attack details to the DOTS client. The client can use
	skipping to change at page 12, line 50 ¶		skipping to change at page 13, line 22 ¶
	A. If the target is subjected to bandwidth consuming attack, the		A. If the target is subjected to bandwidth consuming attack, the
	attributes representing the low percentile (10th percentile),		attributes representing the low percentile (10th percentile),
	mid percentile (50th percentile), high percentile (90th		mid percentile (50th percentile), high percentile (90th
	percentile) and peak values of the attack-id attack traffic		percentile) and peak values of the attack-id attack traffic
	measured in packets per second (PPS) or kilo packets per		measured in packets per second (PPS) or kilo packets per
	second (Kpps) and Bits per Second (BPS), and kilobytes per		second (Kpps) and Bits per Second (BPS), and kilobytes per
	second or megabytes per second or gigabytes per second are		second or megabytes per second or gigabytes per second are
	included.		included.
	B. If the target is subjected to resource consuming DDoS attacks,		B. If the target is subjected to resource consuming DDoS attacks,
	the same attributes defined for Section 4.1.6 are applicable		the same attributes defined for Section 5.1.6 are applicable
	for representing the attack.		for representing the attack.
	This is an optional sub-attribute.		This is an optional sub-attribute.
	o List of top talkers targeting the victim. The top talkers are		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
	represented using the 'source-prefix' defined in		represented using the 'source-prefix' defined in
	[I-D.ietf-dots-signal-call-home]. If the top talkers are spoofed		[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		IP addresses (e.g., reflection attacks) or not. If the target is
	subjected to bandwidth consuming attack, the attack traffic from		subjected to bandwidth consuming attack, the attack traffic from
	each of the top talkers represented in the low percentile (10th		each of the top talkers represented in the low percentile (10th
	percentile), mid percentile (50th percentile), high percentile		percentile), mid percentile (50th percentile), high percentile
	(90th percentile) and peak values of traffic measured in packets		(90th percentile) and peak values of traffic measured in packets
	per second (PPS) or kilo packets per second (Kpps) and Bits per		per second (PPS) or kilo packets per second (Kpps) and Bits per
	Second (BPS), and kilobytes per second or megabytes per second		Second (BPS), and kilobytes per second or megabytes per second
	gigabytes per second. If the target is subjected to resource		gigabytes per second. If the target is subjected to resource
	consuming DDoS attacks, the same attributes defined for		consuming DDoS attacks, the same attributes defined for
	Section 4.1.6 are applicable here for representing the attack per		Section 5.1.6 are applicable here for representing the attack per
	talker. This is an optional sub-attribute.		talker. This is an optional sub-attribute.
	4.2. DOTS Client to Server Mitigation Efficacy DOTS Telemetry		5.2. DOTS Client to Server Mitigation Efficacy DOTS Telemetry
	Attributes		Attributes
	The mitigation efficacy telemetry attributes can be signaled from the		The mitigation efficacy telemetry attributes can be signaled from the
	DOTS client to the DOTS server as part of the periodic mitigation		DOTS client to the DOTS server as part of the periodic mitigation
	efficacy updates to the server.		efficacy updates to the server.
	4.2.1. Total Attack Traffic		5.2.1. Total Attack Traffic
	The low percentile (10th percentile), mid percentile (50th		The low percentile (10th percentile), mid percentile (50th
	percentile), high percentile (90th percentile), and peak values of		percentile), high percentile (90th percentile), and peak values of
	total attack traffic the DOTS client still sees during the active		total attack traffic the DOTS client still sees during the active
	mitigation service measured in packets per second (PPS) or kilo		mitigation service measured in packets per second (PPS) or kilo
	packets per second (Kpps) and Bits per Second (BPS), and kilobytes		packets per second (Kpps) and Bits per Second (BPS), and kilobytes
	per second or megabytes per second or gigabytes per second.		per second or megabytes per second or gigabytes per second.
	4.2.2. Attack Details		5.2.2. Attack Details
	The overall attack details as observed from the DOTS client		The overall attack details as observed from the DOTS client
	perspective during the active mitigation service. The same		perspective during the active mitigation service. The same
	attributes defined in Section 4.1.7 are applicable here.		attributes defined in Section 5.1.7 are applicable here.
	4.3. DOTS Server to Client Mitigation Status DOTS Telemetry Attributes		5.3. 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.		status update.
	4.3.1. Mitigation Status		5.3.1. Mitigation Status
	As defined in [RFC8612], the actual mitigation activities can include		As defined in [RFC8612], the actual mitigation activities can include
	several countermeasure mechanisms. The DOTS server SHOULD signal the		several countermeasure mechanisms. The DOTS server SHOULD signal the
	current operational status to each relevant countermeasure. A list		current operational status to each relevant countermeasure. A list
	of attacks detected by each countermeasure. The same attributes		of attacks detected by each countermeasure. The same attributes
	defined for Section 4.1.7 are applicable here for describing the		defined for Section 5.1.7 are applicable here for describing the
	attacks detected and mitigated.		attacks detected and mitigated.
	5. DOTS Telemetry Configuration		6. DOTS Telemetry Configuration
	5.1. Convey DOTS Telemetry Configuration		6.1. 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 percentiles values used as baseline for telemetry data. In		default percentiles values used as baseline for telemetry data. In
	reference to the example shown in Figure 1, the DOTS client modifies		reference to the example shown in Figure 1, the DOTS client modifies
	all percentile reference values.		all percentile reference values.
	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: "telemetry"		Uri-Path: "telemetry"
			Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
	Uri-Path: "tcid=123"		Uri-Path: "tcid=123"
	Content-Format: "application/dots+cbor"		Content-Format: "application/dots+cbor"
	{		{
	"ietf-dots-telemetry:telemetry-config": {		"ietf-dots-telemetry:telemetry-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 1: PUT to Convey the DOTS Telemetry Configuration		Figure 1: PUT to Convey the DOTS Telemetry Configuration
			'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:
	tcid: Telemetry Configuration Identifier is an identifier for the		tcid: Telemetry Configuration Identifier is an identifier for the
	DOTS telemetry configuration data represented as an integer.		DOTS telemetry configuration data represented as an integer.
	This identifier MUST be generated by DOTS clients. 'tcid'		This identifier MUST be generated by DOTS clients. 'tcid'
	values MUST increase monotonically (when a new PUT is generated		values MUST increase monotonically (when a new PUT is generated
	by a DOTS client to convey the configuration parameters for the		by a DOTS client to convey the configuration 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 'tcid' value overrides the DOTS		The PUT request with a higher numeric 'tcid' 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 'tcid' value. To avoid maintaining a long list of 'tcid'		numeric 'tcid' value. To avoid maintaining a long list of 'tcid'
	requests from a DOTS client, the lower numeric 'tcid' MUST be		requests from a DOTS client, the lower numeric 'tcid' MUST be
	automatically deleted and no longer available at the DOTS server.		automatically deleted and no longer 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 CoAP response codes:		using CoAP 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
	a 'tcid' Uri-Path, or contains one or more invalid or unknown		'cuid' or 'tcid' Uri-Path parameters, or contains one or more
	parameters, 4.00 (Bad Request) MUST be returned in the response.		invalid or unknown parameters, 4.00 (Bad Request) MUST be returned
			in the response.
	o If the DOTS server does not find the 'tcid' parameter value		o If the DOTS server does not find the 'tcid' parameter value
	conveyed in the PUT request in its configuration data and if the		conveyed in the PUT request in its configuration data and if the
	DOTS server has accepted the configuration parameters, then a		DOTS server has accepted the configuration parameters, then a
	response code 2.01 (Created) MUST be returned in the response.		response code 2.01 (Created) MUST be returned in the response.
	o If the DOTS server finds the 'tcid' parameter value conveyed in		o If the DOTS server finds the 'tcid' parameter value conveyed in
	the PUT request in its configuration data and if the DOTS server		the PUT request in its configuration data and if the DOTS server
	has accepted the updated configuration parameters, 2.04 (Changed)		has accepted the updated configuration parameters, 2.04 (Changed)
	MUST be returned in the response.		MUST be returned in the response.
	skipping to change at page 15, line 42 ¶		skipping to change at page 16, line 28 ¶
	acceptable to the DOTS server, 4.22 (Unprocessable Entity) MUST be		acceptable to the DOTS server, 4.22 (Unprocessable Entity) MUST be
	returned in the response.		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.
	A DOTS client may issue a GET message with 'tcid' Uri-Path parameter		A DOTS client may issue a GET message with 'tcid' Uri-Path parameter
	to retrieve the negotiated configuration. The response does not need		to retrieve the negotiated configuration. The response does not need
	to include 'tcid' in its message body.		to include 'tcid' in its message body.
	5.2. Delete DOTS Telemetry Configuration		Setting 'low-percentile' to '0.00' indicates that the DOTS client is
			not interested in receiving low-percentiles. Likewise, setting 'mid-
			percentile' (or 'high-percentile') to the same value as 'low-
			percentile' (or 'mid-percentile') indicates that the DOTS client is
			not interested in receiving mid-percentiles (or high-percentiles).
			For example, a DOTS client can send the request depicted in Figure 2
			to inform the server that it is interested in receiving only high-
			percentiles.
			Notes: Should the server be able to indicate its preference too?
			If the DOTS server and client cannot agree on a common telemetry
			config, the client does not have to send the telemetry (it will
			anyway be ignored by the server).
			Header: PUT (Code=0.03)
			Uri-Path: ".well-known"
			Uri-Path: "dots"
			Uri-Path: "telemetry"
			Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
			Uri-Path: "tcid=569"
			Content-Format: "application/dots+cbor"
			{
			"ietf-dots-telemetry:telemetry-config": {
			"low-percentile": 0.00,
			"mid-percentile": 0.00,
			"high-percentile": 95.00
			}
			}
			Figure 2: PUT to Disable Low- and Mid-Percentiles
			6.2. Delete DOTS Telemetry Configuration
	A DELETE request is used to delete the installed DOTS telemetry		A DELETE request is used to delete the installed DOTS telemetry
	configuration data (Figure 2).		configuration data (Figure 3).
	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: "telemetry"		Uri-Path: "telemetry"
			Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
	Uri-Path: "tcid=123"		Uri-Path: "tcid=123"
	Figure 2: Delete Telemetry Configuration		Figure 3: Delete Telemetry Configuration
	The DOTS server resets the DOTS telemetry configuration back to the		The DOTS server resets the DOTS telemetry configuration back to the
	default values and acknowledges a DOTS client's request to remove the		default values and acknowledges a DOTS client's request to remove the
	DOTS telemetry configuration using 2.02 (Deleted) response code.		DOTS telemetry configuration using 2.02 (Deleted) response code.
	Upon bootstrapping or reboot, a DOTS client MAY send a DELETE request		Upon bootstrapping or reboot, a DOTS client MAY send a DELETE request
	to set the telemetry parameters to default values. Such a request		to set the telemetry parameters to default values. Such a request
	does not include any 'tcid'.		does not include any 'tcid'.
	6. DOTS Telemetry YANG Module		7. DOTS Telemetry YANG Module
	6.1. Tree Structure		7.1. Tree Structure
	This document defines the YANG module "ietf-dots-telemetry", which		This document defines the YANG module "ietf-dots-telemetry".
	has the following tree structure. It augments the "ietf-dots-signal"
	with a new message type called "telemetry" and the "mitigation-scope"
	type message with telemetry data.
	Notes: (1) Check naming conflict to ease CBOR mapping (e.g, low-		Notes: (1) Check naming conflict to ease CBOR mapping (e.g, low-
	percentile is defined as yang:gauge64, list, or container).		percentile is defined as yang:gauge64, list, or container).
	Distinct names may be considered. (2) "protocol" is not indicated		Distinct names may be considered. (2) "protocol" is not indicated
	in the telemetry data of "mitigation-scope" message type because		in the telemetry data of "mitigation-scope" message type because
	the mitigation request may include a "protocol". Similarly,		the mitigation request may include a "protocol". Similarly,
	"target-*" is not included in the in the telemetry data of		"target-*" attributes are not included in the in the telemetry
	"mitigation-scope" message type because the mitigation request		data of "mitigation-scope" message type because the mitigation
	must include at least one of the "target-*" attribute.		request must include at least one of the "target-*" attribute.
			The "ietf-dots-telemetry" YANG module augments the "mitigation-scope"
			type message defined in "ietf-dots-signal" with telemetry data as
			depicted in following tree structure:
	module: ietf-dots-telemetry
	augment /ietf-signal:dots-signal/ietf-signal:message-type		augment /ietf-signal:dots-signal/ietf-signal:message-type
	/ietf-signal:mitigation-scope/ietf-signal:scope:		/ietf-signal:mitigation-scope/ietf-signal:scope:
	+--rw total-attack-traffic* [unit] {dots-telemetry}?		+--rw total-attack-traffic* [unit] {dots-telemetry}?
	| +--rw unit unit		| +--rw unit unit
	| +--rw low-percentile? yang:gauge64		| +--rw low-percentile? yang:gauge64
	| +--rw mid-percentile? yang:gauge64		| +--rw mid-percentile? yang:gauge64
	| +--rw high-percentile? yang:gauge64		| +--rw high-percentile? yang:gauge64
	| +--rw peak? yang:gauge64		| +--rw peak? yang:gauge64
	+--rw total-attack-connection {dots-telemetry}?		+--rw total-attack-connection {dots-telemetry}?
	| +--rw low-percentile		| +--rw low-percentile
	skipping to change at page 17, line 31 ¶		skipping to change at page 19, line 7 ¶
	| +--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 {dots-telemetry}?		+--rw attack-detail {dots-telemetry}?
	+--rw vendor-id? uint32		+--rw vendor-id? uint32
	+--rw attack-id? string		+--rw attack-id? string
	+--rw attack-name? string		+--rw attack-name? string
	+--rw attack-severity? attack-severity		+--rw attack-severity? attack-severity
	+--rw start-time? uint64		+--rw start-time? uint64
	+--rw end-time? uint64		+--rw end-time? uint64
			+--rw source-count
			| +--rw low-percentile? yang:gauge64
			| +--rw mid-percentile? yang:gauge64
			| +--rw high-percentile? yang:gauge64
			| +--rw peak? yang:gauge64
	+--rw top-talker		+--rw top-talker
	+--rw source-prefix* [source-prefix]		+--rw source-prefix* [source-prefix]
	+--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? yang:gauge64		| +--rw low-percentile? yang:gauge64
	| +--rw mid-percentile? yang:gauge64		| +--rw mid-percentile? yang:gauge64
	| +--rw high-percentile? yang:gauge64		| +--rw high-percentile? yang:gauge64
	| +--rw peak? yang:gauge64		| +--rw peak? yang:gauge64
	skipping to change at page 18, line 18 ¶		skipping to change at page 19, line 47 ¶
	| +--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 peak		+--rw peak
	+--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
			Also, the "ietf-dots-telemetry" YANG module augments the "ietf-dots-
			signal" with a new message type called "telemetry". The tree
			structure of the "telemetry" message type is shown below:
	augment /ietf-signal:dots-signal/ietf-signal:message-type:		augment /ietf-signal:dots-signal/ietf-signal:message-type:
	+--:(telemetry) {dots-telemetry}?		+--:(telemetry) {dots-telemetry}?
	+--rw telemetry-config		+--rw telemetry* [cuid tcid]
	| +--rw tcid uint32		+--rw cuid string
	| +--rw low-percentile? percentile		+--rw cdid? string
	| +--rw mid-percentile? percentile		+--rw tcid uint32
	| +--rw high-percentile? percentile		+--rw telemetry-config
	+--rw total-pipe-capability* [unit]		| +--rw low-percentile? percentile
	| +--rw unit unit		| +--rw mid-percentile? percentile
	| +--rw pipe? uint64		| +--rw high-percentile? percentile
	+--rw pre-mitigation* [telemetry-id]		| +--rw unit-config* [unit]
	+--rw telemetry-id uint32		| +--rw unit unit
	+--rw target		| +--rw status? boolean
	| +--rw target-prefix* inet:ip-prefix		+--rw total-pipe-capability* [unit]
	| +--rw target-port-range* [lower-port]		| +--rw unit unit
	| | +--rw lower-port inet:port-number		| +--rw pipe? uint64
	| | +--rw upper-port? inet:port-number		+--rw pre-mitigation* [telemetry-id]
	| +--rw target-protocol* uint8		+--rw telemetry-id uint32
	| +--rw target-fqdn* inet:domain-name		+--rw target
	| +--rw target-uri* inet:uri		| +--rw target-prefix* inet:ip-prefix
	+--rw total-traffic-normal-baseline* [unit protocol]		| +--rw target-port-range* [lower-port]
	| +--rw unit unit		| | +--rw lower-port inet:port-number
	| +--rw protocol uint8		| | +--rw upper-port? inet:port-number
	| +--rw low-percentile? yang:gauge64		| +--rw target-protocol* uint8
	| +--rw mid-percentile? yang:gauge64		| +--rw target-fqdn* inet:domain-name
	| +--rw high-percentile? yang:gauge64		| +--rw target-uri* inet:uri
	| +--rw peak? yang:gauge64		+--rw total-traffic-normal-baseline* [unit protocol]
	+--ro total-attack-traffic* [unit protocol]		| +--rw unit unit
	| +--ro unit unit		| +--rw protocol uint8
	| +--ro protocol uint8		| +--rw low-percentile? yang:gauge64
	| +--ro low-percentile? yang:gauge64		| +--rw mid-percentile? yang:gauge64
	| +--ro mid-percentile? yang:gauge64		| +--rw high-percentile? yang:gauge64
	| +--ro high-percentile? yang:gauge64		| +--rw peak? yang:gauge64
	| +--ro peak? yang:gauge64		+--ro total-attack-traffic* [unit protocol]
	+--ro total-traffic* [unit protocol]		| +--ro unit unit
	| +--ro unit unit		| +--ro protocol uint8
	| +--ro protocol uint8		| +--ro low-percentile? yang:gauge64
	| +--ro low-percentile? yang:gauge64		| +--ro mid-percentile? yang:gauge64
	| +--ro mid-percentile? yang:gauge64		| +--ro high-percentile? yang:gauge64
	| +--ro high-percentile? yang:gauge64		| +--ro peak? yang:gauge64
	| +--ro peak? yang:gauge64		+--ro total-traffic* [unit protocol]
	+--rw total-connection-capacity* [protocol]		| +--ro unit unit
	| +--rw protocol uint8		| +--ro protocol uint8
	| +--rw connection? uint64		| +--ro low-percentile? yang:gauge64
	| +--rw connection-client? uint64		| +--ro mid-percentile? yang:gauge64
	| +--rw embryonic? uint64		| +--ro high-percentile? yang:gauge64
	| +--rw embryonic-client? uint64		| +--ro peak? yang:gauge64
	| +--rw connection-ps? uint64		+--rw total-connection-capacity* [protocol]
	| +--rw connection-client-ps? uint64		| +--rw protocol uint8
	| +--rw request-ps? uint64		| +--rw connection? uint64
	| +--rw request-client-ps? uint64		| +--rw connection-client? uint64
	| +--rw partial-request-ps? uint64		| +--rw embryonic? uint64
	| +--rw partial-request-client-ps? uint64		| +--rw embryonic-client? uint64
	+--ro total-attack-connection		| +--rw connection-ps? uint64
	| +--ro low-percentile* [protocol]		| +--rw connection-client-ps? uint64
	| | +--ro protocol uint8		| +--rw request-ps? uint64
	| | +--ro connection? yang:gauge64		| +--rw request-client-ps? uint64
	| | +--ro embryonic? yang:gauge64		| +--rw partial-request-ps? uint64
	| | +--ro connection-ps? yang:gauge64		| +--rw partial-request-client-ps? uint64
	| | +--ro request-ps? yang:gauge64		+--ro total-attack-connection
	| | +--ro partial-request-ps? yang:gauge64		| +--ro low-percentile* [protocol]
	| +--ro mid-percentile* [protocol]		| | +--ro protocol uint8
	| | +--ro protocol uint8		| | +--ro connection? yang:gauge64
	| | +--ro connection? yang:gauge64		| | +--ro embryonic? yang:gauge64
	| | +--ro embryonic? yang:gauge64		| | +--ro connection-ps? yang:gauge64
	| | +--ro connection-ps? yang:gauge64		| | +--ro request-ps? yang:gauge64
	| | +--ro request-ps? yang:gauge64		| | +--ro partial-request-ps? yang:gauge64
	| | +--ro partial-request-ps? yang:gauge64		| +--ro mid-percentile* [protocol]
	| +--ro high-percentile* [protocol]		| | +--ro protocol uint8
	| | +--ro protocol uint8		| | +--ro connection? yang:gauge64
	| | +--ro connection? yang:gauge64		| | +--ro embryonic? yang:gauge64
	| | +--ro embryonic? yang:gauge64		| | +--ro connection-ps? yang:gauge64
	| | +--ro connection-ps? yang:gauge64		| | +--ro request-ps? yang:gauge64
	| | +--ro request-ps? yang:gauge64		| | +--ro partial-request-ps? yang:gauge64
	| | +--ro partial-request-ps? yang:gauge64		| +--ro high-percentile* [protocol]
	| +--ro peak* [protocol]		| | +--ro protocol uint8
	| +--ro protocol uint8		| | +--ro connection? yang:gauge64
	| +--ro connection? yang:gauge64		| | +--ro embryonic? yang:gauge64
	| +--ro embryonic? yang:gauge64		| | +--ro connection-ps? yang:gauge64
	| +--ro connection-ps? yang:gauge64		| | +--ro request-ps? yang:gauge64
	| +--ro request-ps? yang:gauge64		| | +--ro partial-request-ps? yang:gauge64
	| +--ro partial-request-ps? yang:gauge64		| +--ro peak* [protocol]
	+--ro attack-detail		| +--ro protocol uint8
	+--ro vendor-id? uint32		| +--ro connection? yang:gauge64
	+--ro attack-id? string		| +--ro embryonic? yang:gauge64
	+--ro attack-name? string		| +--ro connection-ps? yang:gauge64
	+--ro attack-severity? attack-severity		| +--ro request-ps? yang:gauge64
	+--ro start-time? uint64		| +--ro partial-request-ps? yang:gauge64
	+--ro end-time? uint64		+--ro attack-detail
	+--ro top-talker		+--ro vendor-id? uint32
	+--ro source-prefix* [source-prefix]		+--ro attack-id? string
	+--ro spoofed-status? boolean		+--ro attack-name? string
	+--ro source-prefix inet:ip-prefix		+--ro attack-severity? attack-severity
	+--ro total-attack-traffic* [unit]		+--ro start-time? uint64
	| +--ro unit unit		+--ro end-time? uint64
	| +--ro low-percentile? yang:gauge64		+--ro source-count
	| +--ro mid-percentile? yang:gauge64		| +--ro low-percentile? yang:gauge64
	| +--ro high-percentile? yang:gauge64		| +--ro mid-percentile? yang:gauge64
	| +--ro peak? yang:gauge64		| +--ro high-percentile? yang:gauge64
	+--ro total-attack-connection		| +--ro peak? yang:gauge64
	+--ro low-percentile* [protocol]		+--ro top-talker
	| +--ro protocol uint8		+--ro source-prefix* [source-prefix]
	| +--ro connection? yang:gauge64		+--ro spoofed-status? boolean
	| +--ro embryonic? yang:gauge64		+--ro source-prefix inet:ip-prefix
	| +--ro connection-ps? yang:gauge64		+--ro total-attack-traffic* [unit]
	| +--ro request-ps? yang:gauge64		| +--ro unit unit
	| +--ro partial-request-ps? yang:gauge64		| +--ro low-percentile? yang:gauge64
	+--ro mid-percentile* [protocol]		| +--ro mid-percentile? yang:gauge64
	| +--ro protocol uint8		| +--ro high-percentile? yang:gauge64
	| +--ro connection? yang:gauge64		| +--ro peak? yang:gauge64
	| +--ro embryonic? yang:gauge64		+--ro total-attack-connection
	| +--ro connection-ps? yang:gauge64		+--ro low-percentile* [protocol]
	| +--ro request-ps? yang:gauge64		| +--ro protocol uint8
	| +--ro partial-request-ps? yang:gauge64		| +--ro connection? yang:gauge64
	+--ro high-percentile* [protocol]		| +--ro embryonic? yang:gauge64
	| +--ro protocol uint8		| +--ro connection-ps? yang:gauge64
	| +--ro connection? yang:gauge64		| +--ro request-ps? yang:gauge64
	| +--ro embryonic? yang:gauge64		| +--ro partial-request-ps? yang:gauge64
	| +--ro connection-ps? yang:gauge64		+--ro mid-percentile* [protocol]
	| +--ro request-ps? yang:gauge64		| +--ro protocol uint8
	| +--ro partial-request-ps? yang:gauge64		| +--ro connection? yang:gauge64
	+--ro peak* [protocol]		| +--ro embryonic? yang:gauge64
	+--ro protocol uint8		| +--ro connection-ps? yang:gauge64
	+--ro connection? yang:gauge64		| +--ro request-ps? yang:gauge64
	+--ro embryonic? yang:gauge64		| +--ro partial-request-ps? yang:gauge64
	+--ro connection-ps? yang:gauge64		+--ro high-percentile* [protocol]
	+--ro request-ps? yang:gauge64		| +--ro protocol uint8
	+--ro partial-request-ps? yang:gauge64		| +--ro connection? yang:gauge64
			| +--ro embryonic? yang:gauge64
			| +--ro connection-ps? yang:gauge64
			| +--ro request-ps? yang:gauge64
			| +--ro partial-request-ps? yang:gauge64
			+--ro peak* [protocol]
			+--ro protocol uint8
			+--ro connection? yang:gauge64
			+--ro embryonic? yang:gauge64
			+--ro connection-ps? yang:gauge64
			+--ro request-ps? yang:gauge64
			+--ro partial-request-ps? yang:gauge64
	6.2. YANG Module		7.2. YANG Module
	This module uses types defined in [RFC6991].		This module uses types defined in [RFC6991].
	<CODE BEGINS> file "ietf-dots-telemetry@2019-10-01.yang"		<CODE BEGINS> file "ietf-dots-telemetry@2019-10-14.yang"
	module ietf-dots-telemetry {		module ietf-dots-telemetry {
	yang-version 1.1;		yang-version 1.1;
	namespace "urn:ietf:params:xml:ns:yang:ietf-dots-telemetry";		namespace "urn:ietf:params:xml:ns:yang:ietf-dots-telemetry";
	prefix dots-telemetry;		prefix dots-telemetry;
	import ietf-dots-signal-channel {		import ietf-dots-signal-channel {
	prefix ietf-signal;		prefix ietf-signal;
	reference		reference
	"RFC SSSS: Distributed Denial-of-Service Open Threat		"RFC SSSS: Distributed Denial-of-Service Open Threat
	Signaling (DOTS) Signal Channel Specification";		Signaling (DOTS) Signal Channel Specification";
	skipping to change at page 22, line 16 ¶		skipping to change at page 24, line 16 ¶
	Redistribution and use in source and binary forms, with or		Redistribution and use in source and binary forms, with or
	without modification, is permitted pursuant to, and subject		without modification, is permitted pursuant to, and subject
	to the license terms contained in, the Simplified BSD License		to the license terms contained in, the Simplified BSD License
	set forth in Section 4.c of the IETF Trust's Legal Provisions		set forth in Section 4.c of the IETF Trust's Legal Provisions
	Relating to IETF Documents		Relating to IETF Documents
	(http://trustee.ietf.org/license-info).		(http://trustee.ietf.org/license-info).
	This version of this YANG module is part of RFC XXXX; see		This version of this YANG module is part of RFC XXXX; see
	the RFC itself for full legal notices.";		the RFC itself for full legal notices.";
	revision 2019-10-01 {		revision 2019-10-14 {
	description		description
	"Initial revision.";		"Initial revision.";
	reference		reference
	"RFC XXXX: Distributed Denial-of-Service Open Threat		"RFC XXXX: Distributed Denial-of-Service Open Threat
	Signaling (DOTS) Telemetry";		Signaling (DOTS) Telemetry";
	}		}
	feature dots-telemetry {		feature dots-telemetry {
	description		description
	"This feature means that the DOTS signal channel is able		"This feature means that the DOTS signal channel is able
	skipping to change at page 24, line 9 ¶		skipping to change at page 26, line 9 ¶
	value at which n percent of the data is below it.";		value at which n percent of the data is below it.";
	}		}
	grouping percentile-config {		grouping percentile-config {
	description		description
	"Configuration of low, mid, and high percentile values.";		"Configuration of low, mid, and high percentile values.";
	leaf low-percentile {		leaf low-percentile {
	type percentile;		type percentile;
	default "10.00";		default "10.00";
	description		description
	"Low percentile.";		"Low percentile. If set to '0', this means low-percentiles
			are disabled.";
	}		}
	leaf mid-percentile {		leaf mid-percentile {
	type percentile;		type percentile;
			must '. >= ../low-percentile' {
			error-message
			"The mid-percentile must be greater than
			or equal to the low-percentile.";
			}
	default "50.00";		default "50.00";
	description		description
	"Mid percentile.";		"Mid percentile. If set to the same value as low-percentiles,
			this means mid-percentiles are disabled.";
	}		}
	leaf high-percentile {		leaf high-percentile {
	type percentile;		type percentile;
			must '. >= ../mid-percentile' {
			error-message
			"The high-percentile must be greater than
			or equal to the mid-percentile.";
			}
	default "90.00";		default "90.00";
	description		description
	"High percentile.";		"High percentile. If set to the same value as mid-percentiles,
			this means high-percentiles are disabled.";
	}		}
	}		}
	grouping traffic {		grouping percentile {
	description		description
	"Generic grouping for traffic percentile.";		"Generic grouping for percentile.";
	leaf low-percentile {		leaf low-percentile {
	type yang:gauge64;		type yang:gauge64;
	description		description
	"Low traffic percentile.";		"Low traffic.";
	}		}
	leaf mid-percentile {		leaf mid-percentile {
	type yang:gauge64;		type yang:gauge64;
	description		description
	"Mid traffic percentile.";		"Mid percentile.";
	}		}
	leaf high-percentile {		leaf high-percentile {
	type yang:gauge64;		type yang:gauge64;
	description		description
	"High traffic percentile.";		"High percentile.";
	}		}
	leaf peak {		leaf peak {
	type yang:gauge64;		type yang:gauge64;
	description		description
	"Peak";		"Peak";
	}		}
	}		}
	grouping traffic-unit {		grouping traffic-unit {
	description		description
	"Grouping of traffic as a function of measurement unit.";		"Grouping of traffic as a function of measurement unit.";
	leaf unit {		leaf unit {
	type unit;		type unit;
	description		description
	"The traffic can be measured in packets per		"The traffic can be measured in packets per
	second (PPS) or kilo packets per second (Kpps) and Bits per		second (PPS) or kilo packets per second (Kpps) and Bits per
	Second (BPS), and kilobytes per second or megabytes per second		Second (BPS), and kilobytes per second or megabytes per second
	or gigabytes per second.";		or gigabytes per second.";
	}		}
	uses traffic;		uses percentile;
	}		}
	grouping traffic-unit-protocol {		grouping traffic-unit-protocol {
	description		description
	"Grouping of traffic of a given transport protocol as		"Grouping of traffic of a given transport protocol as
	a function of measurement unit.";		a function of measurement unit.";
	leaf unit {		leaf unit {
	type unit;		type unit;
	description		description
	"The traffic can be measured in packets per		"The traffic can be measured in packets per
	skipping to change at page 25, line 38 ¶		skipping to change at page 27, line 51 ¶
	leaf protocol {		leaf protocol {
	type uint8;		type uint8;
	description		description
	"The transport protocol.		"The transport protocol.
	Values are taken from the IANA Protocol Numbers registry:		Values are taken from the IANA Protocol Numbers registry:
	<https://www.iana.org/assignments/protocol-numbers/>.		<https://www.iana.org/assignments/protocol-numbers/>.
	For example, this field contains 6 for TCP,		For example, this field contains 6 for TCP,
	17 for UDP, 33 for DCCP, or 132 for SCTP.";		17 for UDP, 33 for DCCP, or 132 for SCTP.";
	}		}
	uses traffic;		uses percentile;
	}		}
	grouping total-connection-capacity {		grouping total-connection-capacity {
	description		description
	"Total Connections Capacity. If the target is subjected		"Total Connections Capacity. If the target is subjected
	to resource consuming DDoS attack, these attributes are		to resource consuming DDoS attack, these attributes are
	useful to detect resource consuming DDoS attacks";		useful to detect resource consuming DDoS attacks";
	leaf connection {		leaf connection {
	type uint64;		type uint64;
	description		description
	skipping to change at page 28, line 4 ¶		skipping to change at page 30, line 17 ¶
	"The number of attack requests per second to		"The number of attack requests per second to
	the target server.";		the target server.";
	}		}
	leaf partial-request-ps {		leaf partial-request-ps {
	type yang:gauge64;		type yang:gauge64;
	description		description
	"The number of attack partial requests to		"The number of attack partial requests to
	the target server.";		the target server.";
	}		}
	}		}
	grouping connection-percentile {		grouping connection-percentile {
	description		description
	"Total attack connections.";		"Total attack connections.";
	container low-percentile {		container low-percentile {
	description		description
	"Low percentile of attack connections.";		"Low percentile of attack connections.";
	uses connection;		uses connection;
	}		}
	container mid-percentile {		container mid-percentile {
	description		description
	"Mid percentile of attack connections.";		"Mid percentile of attack connections.";
	uses connection;		uses connection;
	}		}
	container high-percentile {		container high-percentile {
	description		description
	"Highg percentile of attack connections.";		"High percentile of attack connections.";
	uses connection;		uses connection;
	}		}
	container peak {		container peak {
	description		description
	"Peak attack connections.";		"Peak attack connections.";
	uses connection;		uses connection;
	}		}
	}		}
	grouping connection-protocol-percentile {		grouping connection-protocol-percentile {
	skipping to change at page 30, line 31 ¶		skipping to change at page 32, line 45 ¶
	description		description
	"The time the attack started. Start time is represented in seconds		"The time the attack started. Start time is represented in seconds
	relative to 1970-01-01T00:00:00Z in UTC time.";		relative to 1970-01-01T00:00:00Z in UTC time.";
	}		}
	leaf end-time {		leaf end-time {
	type uint64;		type uint64;
	description		description
	"The time the attack ended. End time is represented in seconds		"The time the attack ended. End time is represented in seconds
	relative to 1970-01-01T00:00:00Z in UTC time.";		relative to 1970-01-01T00:00:00Z in UTC time.";
	}		}
	//uses ietf-data:target;		container source-count {
			description
			"Indicates the count of unique sources involved
			in the attack.";
			uses percentile;
			}
	}		}
	grouping top-talker-aggregate {		grouping top-talker-aggregate {
	description		description
	"Top attack sources.";		"Top attack sources.";
	list source-prefix {		list source-prefix {
	key "source-prefix";		key "source-prefix";
	description		description
	"IPv4 or IPv6 prefix identifying the attacker(s).";		"IPv4 or IPv6 prefix identifying the attacker(s).";
	leaf spoofed-status {		leaf spoofed-status {
	type boolean;		type boolean;
	description		description
	skipping to change at page 31, line 15 ¶		skipping to change at page 33, line 33 ¶
	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-percentile;		uses connection-percentile;
	}		}
	}		}
	/*list source-port-range {
	key "lower-port";
	description
	"Port range. When only lower-port is
	present, it represents a single port number.";
	leaf lower-port {
	type inet:port-number;
	mandatory true;
	description
	"Lower port number of the port range.";
	}
	leaf upper-port {
	type inet:port-number;
	must '. >= ../lower-port' {
	error-message
	"The upper port number must be greater than
	or equal to lower port number.";
	}
	description
	"Upper port number of the port range.";
	}
	}
	list source-icmp-type-range {
	key "lower-type";
	description
	"ICMP type range. When only lower-type is
	present, it represents a single ICMP type.";
	leaf lower-type {
	type uint8;
	mandatory true;
	description
	"Lower ICMP type of the ICMP type range.";
	}
	leaf upper-type {
	type uint8;
	must '. >= ../lower-type' {
	error-message
	"The upper ICMP type must be greater than
	or equal to lower ICMP type.";
	}
	description
	"Upper type of the ICMP type range.";
	}
	}*/
	}		}
	grouping top-talker {		grouping top-talker {
	description		description
	"Top attack sources.";		"Top attack sources.";
	list source-prefix {		list source-prefix {
	key "source-prefix";		key "source-prefix";
	description		description
	"IPv4 or IPv6 prefix identifying the attacker(s).";		"IPv4 or IPv6 prefix identifying the attacker(s).";
	leaf spoofed-status {		leaf spoofed-status {
	skipping to change at page 33, line 34 ¶		skipping to change at page 35, line 7 ¶
	leaf protocol {		leaf protocol {
	type uint8;		type uint8;
	description		description
	"The transport protocol.		"The transport protocol.
	Values are taken from the IANA Protocol Numbers registry:		Values are taken from the IANA Protocol Numbers registry:
	<https://www.iana.org/assignments/protocol-numbers/>.";		<https://www.iana.org/assignments/protocol-numbers/>.";
	}		}
	uses total-connection-capacity;		uses total-connection-capacity;
	}		}
	container total-attack-connection {		container total-attack-connection {
			config false;
	description		description
	"Total attack connections.";		"Total attack connections.";
	config false;
	uses connection-protocol-percentile;		uses connection-protocol-percentile;
	}		}
	container attack-detail {		container attack-detail {
			config false;
	description		description
	"Attack details.";		"Attack details.";
	config false;
	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-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 {
	skipping to change at page 34, line 38 ¶		skipping to change at page 36, line 12 ¶
	}		}
	}		}
	augment "/ietf-signal:dots-signal/ietf-signal:message-type" {		augment "/ietf-signal:dots-signal/ietf-signal:message-type" {
	if-feature "dots-telemetry";		if-feature "dots-telemetry";
	description		description
	"Add a new choice to enclose telemetry data in DOTS		"Add a new choice to enclose telemetry data in DOTS
	signal channel.";		signal channel.";
	case telemetry {		case telemetry {
	description		description
	"Indicates the message is about telemetry.";		"Indicates the message is about telemetry.";
	container telemetry-config {		list telemetry {
			key "cuid tcid";
	description		description
	"Uses to set low, mid, and high percentile values.";		"The telemetry data per DOTS client.";
	leaf tcid {		leaf cuid {
	type uint32;		type string;
	mandatory true;
	description		description
	"An identifier for the DOTS telemetry		"A unique identifier that is
	configuration data.";		generated by a DOTS client to prevent
			request collisions. It is expected that the
			cuid will remain consistent throughout the
			lifetime of the DOTS client.";
	}		}
	uses percentile-config;		leaf cdid {
	}		type string;
	list total-pipe-capability {
	key "unit";
	description
	"Total pipe capacity of a DOTS client domain.";
	leaf unit {
	type unit;
	description		description
	"The traffic can be measured in packets per		"The cdid should be included by a server-domain
	second (PPS) or kilo packets per second (Kpps) and Bits per		DOTS gateway to propagate the client domain
	Second (BPS), and kilobytes per second or megabytes per second		identification information from the
	or gigabytes per second.";		gateway's client-facing-side to the gateway's
			server-facing-side, and from the gateway's
			server-facing-side to the DOTS server.
			It may be used by the final DOTS server
			for policy enforcement purposes.";
	}		}
	leaf pipe {		leaf tcid {
	type uint64;		type uint32;
	description		description
	"Mid traffic percentile.";		"An identifier for the DOTS telemetry configuration
			data.";
	}		}
	}		container telemetry-config {
	list pre-mitigation {
	key "telemetry-id";
	description
	"Pre-mitigation telemetry.";
	leaf telemetry-id {
	type uint32;
	description		description
	"An identifier to uniquely demux telemetry data send using		"Uses to set low, mid, and high percentile values.";
	the same message.";		uses percentile-config;
			list unit-config {
			key "unit";
			description
			"Controls which units are allowed when sharing telemetry
			data.";
			leaf unit {
			type unit;
			description
			"The traffic can be 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.";
			}
			leaf status {
			type boolean;
			description
			"Enable/disable the use of the measurement unit.";
			}
			}
	}		}
	container target {		list total-pipe-capability {
			key "unit";
	description		description
	"Indicates the target.";		"Total pipe capacity of a DOTS client domain.";
	uses ietf-data:target;		leaf unit {
			type unit;
			description
			"The traffic can be 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.";
			}
			leaf pipe {
			type uint64;
			description
			"Mid traffic percentile.";
			}
			}
			list pre-mitigation {
			key "telemetry-id";
			description
			"Pre-mitigation telemetry.";
			leaf telemetry-id {
			type uint32;
			description
			"An identifier to uniquely demux telemetry data send using
			the same message.";
			}
			container target {
			description
			"Indicates the target.";
			uses ietf-data:target;
			}
			uses pre-mitigation;
	}		}
	uses pre-mitigation;
	}		}
	}		}
	}		}
	}		}
	<CODE ENDS>		<CODE ENDS>
	7. IANA Considerations		8. IANA Considerations
	7.1. DOTS Signal Channel CBOR Mappings Registry		8.1. DOTS Signal Channel CBOR Mappings Registry
	This specification registers the DOTS telemetry attributes in the		This specification registers the DOTS telemetry attributes in the
	IANA "DOTS Signal Channel CBOR Mappings" registry established by		IANA "DOTS Signal Channel CBOR Mappings" registry established by
	[I-D.ietf-dots-signal-channel].		[I-D.ietf-dots-signal-channel].
	The DOTS telemetry attributes defined in this specification are		The DOTS telemetry attributes defined in this specification are
	comprehension-optional parameters.		comprehension-optional parameters.
	o Note to the RFC Editor: Please delete (TBD1)-(TBD5) once CBOR keys		o Note to the RFC Editor: Please delete (TBD1)-(TBD5) once CBOR keys
	are assigned from the 0x8000 - 0xBFFF range.		are assigned from the 0x8000 - 0xBFFF range.
	+-------------------+------------+--------+---------------+--------+		+-------------------+------------+--------+---------------+--------+
	| Parameter Name | YANG | CBOR | CBOR Major | JSON |		| Parameter Name | YANG | CBOR | CBOR Major | JSON |
	| | Type | Key | Type & | Type |		| | Type | Key | Type & | Type |
	| | | | Information | |		| | | | Information | |
	+-------------------+------------+--------+---------------+--------+		+-------------------+------------+--------+---------------+--------+
	| TODO | | | | |		| TODO | | | | |
	+-------------------+------------+--------+---------------+--------+		+-------------------+------------+--------+---------------+--------+
	7.2. DOTS Signal Telemetry YANG Module		8.2. DOTS Signal Telemetry YANG Module
	This document requests IANA to register the following URI in the "ns"		This document requests IANA to register the following URI in the "ns"
	subregistry within the "IETF XML Registry" [RFC3688]:		subregistry within the "IETF XML Registry" [RFC3688]:
	URI: urn:ietf:params:xml:ns:yang:ietf-dots-telemetry		URI: urn:ietf:params:xml:ns:yang:ietf-dots-telemetry
	Registrant Contact: The IESG.		Registrant Contact: The IESG.
	XML: N/A; the requested URI is an XML namespace.		XML: N/A; the requested URI is an XML namespace.
	This document requests IANA to register the following YANG module in		This document requests IANA to register the following YANG module in
	the "YANG Module Names" subregistry [RFC7950] within the "YANG		the "YANG Module Names" subregistry [RFC7950] within the "YANG
	Parameters" registry.		Parameters" registry.
	name: ietf-dots-telemetry		name: ietf-dots-telemetry
	namespace: urn:ietf:params:xml:ns:yang:ietf-dots-telemetry		namespace: urn:ietf:params:xml:ns:yang:ietf-dots-telemetry
	maintained by IANA: N		maintained by IANA: N
	prefix: dots-telemetry		prefix: dots-telemetry
	reference: RFC XXXX		reference: RFC XXXX
	8. Security Considerations		9. Security Considerations
	Security considerations in [I-D.ietf-dots-signal-channel] need to be		Security considerations in [I-D.ietf-dots-signal-channel] need to be
	taken into consideration.		taken into consideration.
	9. Contributors		10. Contributors
	The following individuals have contributed to this document:		The following individuals have contributed to this document:
	o Li Su, CMCC, Email: suli@chinamobile.com		o Li Su, CMCC, Email: suli@chinamobile.com
	o Jin Peng, CMCC, Email: pengjin@chinamobile.com		o Jin Peng, CMCC, Email: pengjin@chinamobile.com
	10. Acknowledgements		11. Acknowledgements
	The authors would like to thank Flemming Andreasen, Liang Xia, and		The authors would like to thank Flemming Andreasen, Liang Xia, and
	Kaname Nishizuka co-authors of https://tools.ietf.org/html/draft-		Kaname Nishizuka co-authors of https://tools.ietf.org/html/draft-
	doron-dots-telemetry-00 draft and everyone who had contributed to		doron-dots-telemetry-00 draft and everyone who had contributed to
	that document.		that document.
	Authors would like to thank Kaname Nishizuka, Jon Shallow, Wei Pan		Authors would like to thank Kaname Nishizuka, Jon Shallow, Wei Pan
	and Yuuhei Hayashi for comments and review.		and Yuuhei Hayashi for comments and review.
	11. References		12. References
	11.1. Normative References		12.1. Normative References
	[Enterprise-Numbers]		[Enterprise-Numbers]
	"Private Enterprise Numbers", 2005, <http://www.iana.org/		"Private Enterprise Numbers", 2005, <http://www.iana.org/
	assignments/enterprise-numbers.html>.		assignments/enterprise-numbers.html>.
	[I-D.ietf-dots-data-channel]		[I-D.ietf-dots-data-channel]
	Boucadair, M. and R. K, "Distributed Denial-of-Service		Boucadair, M. and R. K, "Distributed Denial-of-Service
	Open Threat Signaling (DOTS) Data Channel Specification",		Open Threat Signaling (DOTS) Data Channel Specification",
	draft-ietf-dots-data-channel-31 (work in progress), July		draft-ietf-dots-data-channel-31 (work in progress), July
	2019.		2019.
	skipping to change at page 38, line 18 ¶		skipping to change at page 40, line 41 ¶
	<https://www.rfc-editor.org/info/rfc7641>.		<https://www.rfc-editor.org/info/rfc7641>.
	[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",		[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
	RFC 7950, DOI 10.17487/RFC7950, August 2016,		RFC 7950, DOI 10.17487/RFC7950, August 2016,
	<https://www.rfc-editor.org/info/rfc7950>.		<https://www.rfc-editor.org/info/rfc7950>.
	[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>.
	11.2. Informative References		12.2. Informative References
	[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.
	[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",		[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
	BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,		BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
	<https://www.rfc-editor.org/info/rfc8340>.		<https://www.rfc-editor.org/info/rfc8340>.
End of changes. 92 change blocks.
	308 lines changed or deleted		412 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/