< draft-ietf-dots-telemetry-02.txt		draft-ietf-dots-telemetry-03.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 10, 2020 McAfee		Expires: September 3, 2020 McAfee
	E. Doron		E. Doron
	Radware Ltd.		Radware Ltd.
	M. Chen		M. Chen
	CMCC		CMCC
	February 7, 2020		March 2, 2020
	Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry		Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry
	draft-ietf-dots-telemetry-02		draft-ietf-dots-telemetry-03
	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 10, 2020.		This Internet-Draft will expire on September 3, 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 33 ¶		skipping to change at page 2, line 33 ¶
	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. DOTS Multi-homing Considerations . . . . . . . . . . . . 10		4.6. DOTS Multi-homing Considerations . . . . . . . . . . . . 10
	4.7. YANG Considerations . . . . . . . . . . . . . . . . . . . 10		4.7. YANG Considerations . . . . . . . . . . . . . . . . . . . 10
	4.8. A Note About Examples . . . . . . . . . . . . . . . . . . 10		4.8. A Note About Examples . . . . . . . . . . . . . . . . . . 11
	5. Telemetry Operation Paths . . . . . . . . . . . . . . . . . . 11		5. Telemetry Operation Paths . . . . . . . . . . . . . . . . . . 11
	6. DOTS Telemetry Setup Configuration . . . . . . . . . . . . . 12		6. DOTS Telemetry Setup Configuration . . . . . . . . . . . . . 12
	6.1. Telemetry Configuration . . . . . . . . . . . . . . . . . 12		6.1. Telemetry Configuration . . . . . . . . . . . . . . . . . 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 . . . . . . . . . 18		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 Installed DOTS Client Domain Pipe Capacity . 25
	6.2.3. Delete DOTS Client Domain Pipe Capacity . . . . . . . 25		6.2.3. Delete Installed 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 . . . 28		6.3.1. Convey DOTS Client Domain Baseline Information . . . 28
	6.3.2. Retrieve Normal Traffic Baseline . . . . . . . . . . 29		6.3.2. Retrieve Installed Normal Traffic Baseline . . . . . 29
	6.3.3. Delete Normal Traffic Baseline . . . . . . . . . . . 29		6.3.3. Delete Installed Normal Traffic Baseline . . . . . . 29
	6.4. Reset Installed Telemetry Setup . . . . . . . . . . . . . 29		6.4. Reset Installed Telemetry Setup . . . . . . . . . . . . . 29
	6.5. Conflict with Other DOTS Clients of the Same Domain . . . 30		6.5. Conflict with Other DOTS Clients of the Same Domain . . . 30
	7. DOTS Pre-mitigation Telemetry . . . . . . . . . . . . . . . . 30		7. DOTS Pre-mitigation Telemetry . . . . . . . . . . . . . . . . 30
	7.1. Pre-mitigation DOTS Telemetry Attributes . . . . . . . . 31		7.1. Pre-mitigation DOTS Telemetry Attributes . . . . . . . . 32
	7.1.1. Target . . . . . . . . . . . . . . . . . . . . . . . 31		7.1.1. Target . . . . . . . . . . . . . . . . . . . . . . . 32
	7.1.2. Total Traffic . . . . . . . . . . . . . . . . . . . . 32		7.1.2. Total Traffic . . . . . . . . . . . . . . . . . . . . 33
	7.1.3. Total Attack Traffic . . . . . . . . . . . . . . . . 33		7.1.3. Total Attack Traffic . . . . . . . . . . . . . . . . 34
	7.1.4. Total Attack Connections . . . . . . . . . . . . . . 34		7.1.4. Total Attack Connections . . . . . . . . . . . . . . 35
	7.1.5. Attack Details . . . . . . . . . . . . . . . . . . . 36		7.1.5. Attack Details . . . . . . . . . . . . . . . . . . . 37
	7.2. From DOTS Clients to DOTS Servers . . . . . . . . . . . . 38		7.2. From DOTS Clients to DOTS Servers . . . . . . . . . . . . 39
	7.3. From DOTS Servers to DOTS Client . . . . . . . . . . . . 39		7.3. From DOTS Servers to DOTS Client . . . . . . . . . . . . 40
	8. DOTS Telemetry Mitigation Status Update . . . . . . . . . . . 42		8. DOTS Telemetry Mitigation Status Update . . . . . . . . . . . 43
	8.1. DOTS Client to Server Mitigation Efficacy DOTS Telemetry		8.1. DOTS Client to Server Mitigation Efficacy DOTS Telemetry
	Attributes . . . . . . . . . . . . . . . . . . . . . . . 42
	8.2. DOTS Server to Client Mitigation Status DOTS Telemetry
	Attributes . . . . . . . . . . . . . . . . . . . . . . . 43		Attributes . . . . . . . . . . . . . . . . . . . . . . . 43
	9. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 46		8.2. DOTS Server to Client Mitigation Status DOTS Telemetry
	10. YANG/JSON Mapping Parameters to CBOR . . . . . . . . . . . . 67		Attributes . . . . . . . . . . . . . . . . . . . . . . . 44
	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 69		9. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 47
	11.1. DOTS Signal Channel CBOR Key Values . . . . . . . . . . 69		10. YANG/JSON Mapping Parameters to CBOR . . . . . . . . . . . . 68
	11.2. DOTS Signal Channel Conflict Cause Codes . . . . . . . . 70		11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 71
	11.3. DOTS Signal Telemetry YANG Module . . . . . . . . . . . 71		11.1. DOTS Signal Channel CBOR Key Values . . . . . . . . . . 71
	12. Security Considerations . . . . . . . . . . . . . . . . . . . 71		11.2. DOTS Signal Channel Conflict Cause Codes . . . . . . . . 75
	13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 71		11.3. DOTS Signal Telemetry YANG Module . . . . . . . . . . . 75
	14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 71		12. Security Considerations . . . . . . . . . . . . . . . . . . . 75
	15. References . . . . . . . . . . . . . . . . . . . . . . . . . 72		13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 75
	15.1. Normative References . . . . . . . . . . . . . . . . . . 72		14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 76
	15.2. Informative References . . . . . . . . . . . . . . . . . 73		15. References . . . . . . . . . . . . . . . . . . . . . . . . . 76
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 74		15.1. Normative References . . . . . . . . . . . . . . . . . . 76
			15.2. Informative References . . . . . . . . . . . . . . . . . 77
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 78
	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 10, line 46 ¶		skipping to change at page 10, line 46 ¶
	Messages exchanged between DOTS agents are serialized using Concise		Messages exchanged between DOTS agents are serialized using Concise
	Binary Object Representation (CBOR). CBOR-encoded payloads are used		Binary Object Representation (CBOR). CBOR-encoded payloads are used
	to carry signal channel-specific payload messages which convey		to carry signal channel-specific payload messages which convey
	request parameters and response information such as errors		request parameters and response information such as errors
	[I-D.ietf-dots-signal-channel].		[I-D.ietf-dots-signal-channel].
	This document specifies a YANG module for representing DOTS telemetry		This document specifies a YANG module for representing DOTS telemetry
	message types (Section 9). All parameters in the payload of the DOTS		message types (Section 9). All parameters in the payload of the DOTS
	signal channel are mapped to CBOR types as specified in Section 10.		signal channel are mapped to CBOR types as specified in Section 10.
			The DOTS telemetry module (Section 9) uses "enumerations" rather than
			"identities" to define units, samples, and intervals because
			otherwise the namespace identifier "ietf-dots-telemetry" must be
			included when a telemetry attribute is included (e.g., in a
			mitigation efficacy update). The use of "identities" is thus
			suboptimal from a message compactness standpoint.
	4.8. A Note About Examples		4.8. A Note About Examples
	Examples are provided for illustration purposes. The document does		Examples are provided for illustration purposes. The document does
	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
	skipping to change at page 17, line 42 ¶		skipping to change at page 17, line 42 ¶
	related telemetry data. Typically, the supported units are: packets		related telemetry data. Typically, the supported units are: 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.		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.2) MUST set 'server-		information from a DOTS server (Section 8.2) MUST set 'server-
	originated-telemetry' to 'true'. If 'server-originated-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-originated-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 request 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"
	skipping to change at page 25, line 37 ¶		skipping to change at page 25, line 37 ¶
	}		}
	]		]
	}		}
	]		]
	}		}
	}		}
	Figure 17: Example of a PUT Request to Convey Pipe Information		Figure 17: Example of a PUT Request to Convey Pipe Information
	(Multi-Homed)		(Multi-Homed)
	6.2.2. Retrieve DOTS Client Domain Pipe Capacity		6.2.2. Retrieve Installed DOTS Client Domain Pipe Capacity
	A GET request with 'tsid' Uri-Path parameter is used to retrieve a		A GET request with 'tsid' Uri-Path parameter is used to retrieve a
	specific installed DOTS client domain pipe related information. The		specific installed DOTS client domain pipe related information. The
	same procedure as defined in (Section 6.1.3) is followed.		same procedure as defined in (Section 6.1.3) is followed.
	To retrieve all pipe information bound to a DOTS client, the DOTS		To retrieve all pipe information bound to a DOTS client, the DOTS
	client proceeds as specified in Section 6.1.1.		client proceeds as specified in Section 6.1.1.
	6.2.3. Delete DOTS Client Domain Pipe Capacity		6.2.3. Delete Installed DOTS Client Domain Pipe Capacity
	A DELETE request is used to delete the installed DOTS client domain		A DELETE request is used to delete the installed DOTS client domain
	pipe related information. The same procedure as defined in		pipe related information. The same procedure as defined in
	(Section 6.1.4) is followed.		(Section 6.1.4) is followed.
	6.3. Telemetry Baseline		6.3. Telemetry Baseline
	A DOTS client can communicate to its server(s) its normal traffic		A DOTS client can communicate to its server(s) its normal traffic
	baseline and total connections capacity:		baseline and total connections capacity:
	skipping to change at page 29, line 32 ¶		skipping to change at page 29, line 32 ¶
	"unit": "megabytes-ps",		"unit": "megabytes-ps",
	"protocol": 6,		"protocol": 6,
	"peak-g": "50"		"peak-g": "50"
	}		}
	}		}
	}		}
	}		}
	Figure 19: PUT to Convey the DOTS Traffic Baseline		Figure 19: PUT to Convey the DOTS Traffic Baseline
	6.3.2. Retrieve Normal Traffic Baseline		6.3.2. Retrieve Installed Normal Traffic Baseline
	A GET request with 'tsid' Uri-Path parameter is used to retrieve a		A GET request with 'tsid' Uri-Path parameter is used to retrieve a
	specific installed DOTS client domain baseline traffic information.		specific installed DOTS client domain baseline traffic information.
	The same procedure as defined in (Section 6.1.3) is followed.		The same procedure as defined in (Section 6.1.3) is followed.
	To retrieve all baseline information bound to a DOTS client, the DOTS		To retrieve all baseline information bound to a DOTS client, the DOTS
	client proceeds as specified in Section 6.1.1.		client proceeds as specified in Section 6.1.1.
	6.3.3. Delete Normal Traffic Baseline		6.3.3. Delete Installed 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 same procedure as defined in		normal traffic baseline. The same procedure as defined in
	(Section 6.1.4) is followed.		(Section 6.1.4) is followed.
	6.4. Reset Installed Telemetry Setup		6.4. Reset Installed Telemetry Setup
	Upon bootstrapping (or reboot or any other event that may alter the		Upon bootstrapping (or reboot or any other event that may alter the
	DOTS client setup), a DOTS client MAY send a DELETE request to set		DOTS client setup), a DOTS client MAY send a DELETE request to set
	the telemetry parameters to default values. Such a request does not		the telemetry parameters to default values. Such a request does not
	skipping to change at page 30, line 40 ¶		skipping to change at page 30, line 40 ¶
	There are two broad types of DDoS attacks, one is bandwidth consuming		There are two broad types of DDoS attacks, one is bandwidth consuming
	attack, the other is target resource consuming attack. This section		attack, the other is target resource consuming attack. This section
	outlines the set of DOTS telemetry attributes (Section 7.1) that		outlines the set of DOTS telemetry attributes (Section 7.1) that
	covers both the types of attacks. The ultimate objective of these		covers both the types of attacks. The ultimate objective of these
	attributes is to allow for the complete knowledge of attacks and the		attributes is to allow for the complete knowledge of attacks and the
	various particulars that can best characterize attacks.		various particulars that can best characterize attacks.
	The "ietf-dots-telemetry" YANG module (Section 9) augments the "ietf-		The "ietf-dots-telemetry" YANG module (Section 9) augments the "ietf-
	dots-signal" with a new message type called "telemetry". The tree		dots-signal" with a new message type called "telemetry". The tree
	structure of the "telemetry" message type is shown Figure 21.		structure of the "telemetry" message type is shown Figure 23.
	The pre-mitigation telemetry attributes are indicated by the path-		The pre-mitigation telemetry attributes are indicated by the path-
	suffix '/tm'. The '/tm' is appended to the path-prefix to form the		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-		URI used with a CoAP request to signal the DOTS telemetry. Pre-
	mitigation telemetry attributes specified in Section 7.1 can be		mitigation telemetry attributes specified in Section 7.1 can be
	signaled between DOTS agents.		signaled between DOTS agents.
	Pre-mitigation telemetry attributes may be sent by a DOTS client or a		Pre-mitigation telemetry attributes may be sent by a DOTS client or a
	DOTS server.		DOTS server.
	DOTS agents MUST bind pre-mitigation telemetry data with mitigation		DOTS agents MUST bind pre-mitigation telemetry data with mitigation
	requests relying upon the target clause.		requests relying upon the target clause. In particular, a telemetry
			PUT request sent after a mitigation request may include a reference
			to that mitigation request ('mid-list') as shown in Figure 21. An
			example illustrating requests correlation by means of 'target-prefix'
			is shown in Figure 22.
			+-----------+ +-----------+
			|DOTS client| |DOTS server|
			+-----------+ +-----------+
			| |
			|=========Mitigation Request (mid)=====================>|
			| |
			|====Pre-mitigation Telemetry (mid-list{mid})==========>|
			| |
			Figure 21: Example of Request Correlation using 'mid'
			+-----------+ +-----------+
			|DOTS client| |DOTS server|
			+-----------+ +-----------+
			| |
			|<======Pre-mitigation Telemetry (target-prefix)========|
			| |
			|=========Mitigation Request (target-prefix)===========>|
			| |
			Figure 22: Example of Request Correlation using Target Prefix
	DOTS agents MUST NOT sent pre-mitigation telemetry messages to the		DOTS agents MUST NOT sent pre-mitigation telemetry messages to the
	same peer more frequently than once every 'telemetry-notify-interval'		same peer more frequently than once every 'telemetry-notify-interval'
	(Section 6.1).		(Section 6.1).
	DOTS pre-mitigation telemetry request and response messages MUST be		DOTS pre-mitigation telemetry request and response messages MUST be
	marked as Non-Confirmable messages.		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 tmid]		+--rw pre-mitigation* [cuid tmid]
	+--rw cuid string		+--rw cuid string
	+--rw cdid? string		+--rw cdid? string
	+--rw tmid uint32		+--rw tmid uint32
	+--rw target		+--rw target
	| ...		| ...
	+--rw total-traffic* [unit protocol]		+--rw total-traffic* [unit 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 21: Telemetry Message Type Tree Structure		Figure 23: Telemetry Message Type Tree Structure
	7.1. Pre-mitigation DOTS Telemetry Attributes		7.1. Pre-mitigation DOTS Telemetry Attributes
	The description and motivation behind each attribute are presented in		The description and motivation behind each attribute are presented in
	Section 3. DOTS telemetry attributes are optionally signaled and		Section 3. DOTS telemetry attributes are optionally signaled and
	therefore MUST NOT be treated as mandatory fields in the DOTS signal		therefore MUST NOT be treated as mandatory fields in the DOTS signal
	channel protocol.		channel protocol.
	7.1.1. Target		7.1.1. Target
	A target resource (Figure 22) is identified using the attributes		A target resource (Figure 24) is identified using the attributes
	'target-prefix', 'target-port-range', 'target-protocol', 'target-		'target-prefix', 'target-port-range', 'target-protocol', 'target-
	fqdn', 'target-uri', or 'alias-name' defined in the base DOTS signal		fqdn', 'target-uri', or 'alias-name' defined in the base DOTS signal
	channel protocol.		channel protocol.
	+--:(telemetry) {dots-telemetry}?		+--:(telemetry) {dots-telemetry}?
	+--rw pre-mitigation* [cuid tmid]		+--rw pre-mitigation* [cuid tmid]
	+--rw cuid string		+--rw cuid string
	+--rw cdid? string		+--rw cdid? string
	+--rw tmid uint32		+--rw tmid uint32
	+--rw target		+--rw target
	| +--rw target-prefix* inet:ip-prefix		| +--rw target-prefix* inet:ip-prefix
	| +--rw target-port-range* [lower-port]		| +--rw target-port-range* [lower-port]
	| | +--rw lower-port inet:port-number		| | +--rw lower-port inet:port-number
	| | +--rw upper-port? inet:port-number		| | +--rw upper-port? inet:port-number
	| +--rw target-protocol* uint8		| +--rw target-protocol* uint8
	| +--rw target-fqdn* inet:domain-name		| +--rw target-fqdn* inet:domain-name
	| +--rw target-uri* inet:uri		| +--rw target-uri* inet:uri
	| +--rw alias-name* string		| +--rw alias-name* string
			| +--rw mid-list* uint32
	+--rw 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 22: Target Tree Structure		Figure 24: Target Tree Structure
	At least one of the attributes 'target-prefix', 'target-fqdn',		At least one of the attributes 'target-prefix', 'target-fqdn',
	'target-uri', or 'alias-name' MUST be present in the attack details.		'target-uri', 'alias-name', or 'mid-lis' MUST be present in the
			attack details.
	If the target is subjected to bandwidth consuming attack, the		If the target is subjected to bandwidth consuming attack, the
	attributes representing the percentile values of the 'attack-id'		attributes representing the percentile values of the 'attack-id'
	attack traffic are included.		attack traffic are included.
	If the target is subjected to resource consuming DDoS attacks, the		If the target is subjected to resource consuming DDoS attacks, the
	same attributes defined for Section 7.1.4 are applicable for		same attributes defined for Section 7.1.4 are applicable for
	representing the attack.		representing the attack.
	This is an optional sub-attribute.		This is an optional sub-attribute.
	7.1.2. Total Traffic		7.1.2. Total Traffic
	This attribute (Figure 23) conveys the percentile values of total		This attribute (Figure 25) conveys the percentile values of total
	traffic observed during a DDoS attack.		traffic observed during a DDoS attack.
	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.
	+--:(telemetry) {dots-telemetry}?		+--:(telemetry) {dots-telemetry}?
	+--rw pre-mitigation* [cuid tmid]		+--rw pre-mitigation* [cuid tmid]
	+--rw cuid string		+--rw cuid string
	+--rw cdid? string		+--rw cdid? string
	+--rw tmid uint32		+--rw tmid uint32
	skipping to change at page 33, line 26 ¶		skipping to change at page 34, line 26 ¶
	| +--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 23: Total Traffic Tree Structure		Figure 25: Total Traffic Tree Structure
	7.1.3. Total Attack Traffic		7.1.3. Total Attack Traffic
	This attribute (Figure 24) conveys the total attack traffic		This attribute (Figure 26) conveys the total attack traffic
	identified by the DOTS client domain's DMS (or DDoS Detector).		identified by the DOTS client domain's DMS (or DDoS Detector).
	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.
	+--:(telemetry) {dots-telemetry}?		+--:(telemetry) {dots-telemetry}?
	+--rw pre-mitigation* [cuid tmid]		+--rw pre-mitigation* [cuid tmid]
	+--rw cuid string		+--rw cuid string
	+--rw cdid? string		+--rw cdid? string
	+--rw tmid uint32		+--rw tmid uint32
	skipping to change at page 34, line 26 ¶		skipping to change at page 35, line 26 ¶
	| +--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 24: Total Attack Traffic Tree Structure		Figure 26: Total Attack Traffic Tree Structure
	7.1.4. Total Attack Connections		7.1.4. Total Attack Connections
	If the target is subjected to resource consuming DDoS attack, this		If the target is subjected to resource consuming DDoS attack, this
	attribute is used to convey the percentile values of total attack		attribute is used to convey the percentile values of total attack
	connections. The following optional sub-attributes for the target		connections. The following optional sub-attributes for the target
	per transport-protocol are included to represent the attack		per transport-protocol are included to represent the attack
	characteristics:		characteristics:
	o The number of simultaneous attack connections to the target.		o The number of simultaneous attack connections to the target.
	skipping to change at page 35, line 48 ¶		skipping to change at page 36, 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 25: Total Attack Connections Tree Structure		Figure 27: Total Attack Connections Tree Structure
	7.1.5. Attack Details		7.1.5. Attack Details
	This attribute (Figure 26) is used to signal a set of details		This attribute (Figure 28) is used to signal a set of details
	characterizing an attack. The following optional sub-attributes		characterizing an attack. The following optional sub-attributes
	describing the on-going attack can be signal as attack details.		describing the on-going attack can be signal as attack details.
	id: Vendor ID is a security vendor's Enterprise Number as registered		id: Vendor ID is a security vendor's Enterprise Number as registered
	with IANA [Enterprise-Numbers]. It is a four-byte integer value.		with IANA [Enterprise-Numbers]. It is a four-byte integer value.
	attack-id: Unique identifier assigned by the vendor for the attack.		attack-id: Unique identifier assigned by the vendor for the attack.
	attack-name: Textual representation of attack description. Natural		attack-name: Textual representation of attack description. Natural
	Language Processing techniques (e.g., word embedding) can possibly		Language Processing techniques (e.g., word embedding) can possibly
	skipping to change at page 37, line 31 ¶		skipping to change at page 38, line 31 ¶
	+--rw attack-name? string		+--rw attack-name? string
	+--rw attack-severity? attack-severity		+--rw attack-severity? attack-severity
	+--rw start-time? uint64		+--rw start-time? uint64
	+--rw end-time? uint64		+--rw end-time? uint64
	+--rw source-count		+--rw source-count
	| +--rw low-percentile-g? yang:gauge64		| +--rw low-percentile-g? yang:gauge64
	| +--rw mid-percentile-g? yang:gauge64		| +--rw mid-percentile-g? yang:gauge64
	| +--rw high-percentile-g? yang:gauge64		| +--rw high-percentile-g? yang:gauge64
	| +--rw peak-g? yang:gauge64		| +--rw peak-g? yang:gauge64
	+--rw top-talker		+--rw top-talker
	+--rw source-prefix* [source-prefix]		+--rw talker* [source-prefix]
	+--rw spoofed-status? boolean		+--rw spoofed-status? boolean
	+--rw source-prefix inet:ip-prefix		+--rw source-prefix inet:ip-prefix
	+--rw 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 mid-percentile-l* [protocol]		+--rw mid-percentile-l* [protocol]
	| ...		| ...
	+--rw high-percentile-l* [protocol]		+--rw high-percentile-l* [protocol]
	| ...		| ...
	+--rw peak-l* [protocol]		+--rw peak-l* [protocol]
	...		...
	Figure 26: Attack Detail Tree Structure		Figure 28: Attack Detail Tree Structure
	7.2. From DOTS Clients to DOTS Servers		7.2. From DOTS Clients to DOTS Servers
	DOTS clients uses PUT request to signal pre-mitigation telemetry to		DOTS clients uses PUT request to signal pre-mitigation telemetry to
	DOTS servers. An example of such request is shown in Figure 27.		DOTS servers. An example of such request is shown in Figure 29.
	Header: PUT (Code=0.03)		Header: PUT (Code=0.03)
	Uri-Path: ".well-known"		Uri-Path: ".well-known"
	Uri-Path: "dots"		Uri-Path: "dots"
	Uri-Path: "tm"		Uri-Path: "tm"
	Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"		Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
	Uri-Path: "tmid=123"		Uri-Path: "tmid=123"
	Content-Format: "application/dots+cbor"		Content-Format: "application/dots+cbor"
	{		{
	skipping to change at page 38, line 41 ¶		skipping to change at page 39, line 41 ¶
	],		],
	"attack-detail": {		"attack-detail": {
	"start-time": "1957811234",		"start-time": "1957811234",
	"attack-severity": "emergency"		"attack-severity": "emergency"
	}		}
	}		}
	]		]
	}		}
	}		}
	Figure 27: PUT to Send Pre-Mitigation Telemetry		Figure 29: PUT to Send Pre-Mitigation Telemetry
	'cuid' is a mandatory Uri-Path parameter for PUT requests.		'cuid' is a mandatory Uri-Path parameter for PUT requests.
	The following additional Uri-Path parameter is defined:		The following additional Uri-Path parameter is defined:
	tmid: Telemetry Identifier is an identifier for the DOTS pre-		tmid: Telemetry Identifier is an identifier for the DOTS pre-
	mitigation telemetry data represented as an integer. This		mitigation telemetry data represented as an integer. This
	identifier MUST be generated by DOTS clients. 'tsid' values MUST		identifier MUST be generated by DOTS clients. 'tsid' values MUST
	increase monotonically (when a new PUT is generated by a DOTS		increase monotonically (when a new PUT is generated by a DOTS
	client to convey pre-mitigation telemetry).		client to convey pre-mitigation telemetry).
	skipping to change at page 39, line 20 ¶		skipping to change at page 40, line 20 ¶
	Section 7.3.		Section 7.3.
	The relative order of two PUT requests carrying DOTS pre-mitigation		The relative order of two PUT requests carrying DOTS pre-mitigation
	telemetry from a DOTS client is determined by comparing their		telemetry from a DOTS client is determined by comparing their
	respective 'tmid' values. If such two requests have overlapping		respective 'tmid' values. If such two requests have overlapping
	'target', the PUT request with higher numeric 'tmid' value will		'target', the PUT request with higher numeric 'tmid' value will
	override the request with a lower numeric 'tmid' value. The		override the request with a lower numeric 'tmid' value. The
	overlapped lower numeric 'tmid' MUST be automatically deleted and no		overlapped lower numeric 'tmid' MUST be automatically deleted and no
	longer be available.		longer be available.
	<<should we restrict pre-mitigation to one tmid i a request?>>		The DOTS server indicates the result of processing a PUT request
			using CoAP response codes. The response code 2.04 (Changed) is
	<<processing at the server>>		returned if the DOTS server has accepted the pre-mitigation
			telemetry. The error response code 5.03 (Service Unavailable) is
			returned if the DOTS server has erred . 5.03 uses Max-Age option to
			indicate the number of seconds after which to retry.
	7.3. From DOTS Servers to DOTS Client		7.3. From DOTS Servers to DOTS Client
	The pre-mitigation (attack details, in particular) can also be		The pre-mitigation (attack details, in particular) can also be
	signaled from DOTS servers to DOTS clients. For example, the DOTS		signaled from DOTS servers to DOTS clients. For example, the DOTS
	server co-located with a DDoS detector collects monitoring		server co-located with a DDoS detector collects monitoring
	information from the target network, identifies DDoS attack using		information from the target network, identifies DDoS attack using
	statistical analysis or deep learning techniques, and signals the		statistical analysis or deep learning techniques, and signals the
	attack details to the DOTS client.		attack details to the DOTS client.
	The DOTS client can use the attack details to decide whether to		The DOTS client can use the attack details to decide whether to
	trigger a DOTS mitigation request or not. Furthermore, the security		trigger a DOTS mitigation request or not. Furthermore, the security
	operation personnel at the DOTS client domain can use the attack		operation personnel at the DOTS client domain can use the attack
	details to determine the protection strategy and select the		details to determine the protection strategy and select the
	appropriate DOTS server for mitigating the attack.		appropriate DOTS server for mitigating the attack.
	In order to receive pre-mitigation telemetry notifications from a		In order to receive pre-mitigation telemetry notifications from a
	DOTS server, a DOTS client MUST send a PUT (followed by a GET) with		DOTS server, a DOTS client MUST send a PUT (followed by a GET) with
	the target filter. An example of such request is shown in Figure 28.		the target filter. An example of such PUT request is shown in
	In order to avoid maintaining a long list of such requests, it is		Figure 30. In order to avoid maintaining a long list of such
	RECOMMENDED that DOTS clients include all targets in the same		requests, it is RECOMMENDED that DOTS clients include all targets in
	request. DOTS servers may be instructed to restrict the number of		the same request. DOTS servers may be instructed to restrict the
	pre-mitigation requests per DOTS client domain.		number of pre-mitigation requests per 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"		Uri-Path: "tm"
	Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"		Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
	Uri-Path: "tmid=123"		Uri-Path: "tmid=123"
	Content-Format: "application/dots+cbor"		Content-Format: "application/dots+cbor"
	{		{
	skipping to change at page 40, line 25 ¶		skipping to change at page 41, line 25 ¶
	"target": {		"target": {
	{		{
	"target-prefix": [		"target-prefix": [
	"2001:db8::/32"		"2001:db8::/32"
	]		]
	}		}
	}		}
	}		}
	}		}
	Figure 28: PUT to Request Pre-Mitigation Telemetry		Figure 30: PUT to Request Pre-Mitigation Telemetry
	<<<Include more details about the processing of the request:
	lifetime, etc.>>>
	DOTS clients of the same domain can request to receive pre-mitigation		DOTS clients of the same domain can request to receive pre-mitigation
	telemetry bound to the same target.		telemetry bound to the same target.
	Then, the DOTS client conveys the Observe Option set to '0' in the		The DOTS client conveys the Observe Option set to '0' in the GET
	GET request to receive asynchronous notifications carrying pre-		request to receive asynchronous notifications carrying pre-mitigation
	mitigation telemetry data from the DOTS server. The GET request		telemetry data from the DOTS server. The GET request specify a
	specify a 'tmid' (Figure 29) or not (Figure 30).		'tmid' (Figure 31) or not (Figure 32).
	Header: GET (Code=0.01)		Header: GET (Code=0.01)
	Uri-Path: ".well-known"		Uri-Path: ".well-known"
	Uri-Path: "dots"		Uri-Path: "dots"
	Uri-Path: "tm"		Uri-Path: "tm"
	Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"		Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
	Uri-Path: "tmid=123"		Uri-Path: "tmid=123"
	Observe: 0		Observe: 0
	Figure 29: GET to Subscribe to Telemetry Asynchronous Notifications		Figure 31: GET to Subscribe to Telemetry Asynchronous Notifications
	for a Specific 'tmid'		for a Specific 'tmid'
	Header: GET (Code=0.01)		Header: GET (Code=0.01)
	Uri-Path: ".well-known"		Uri-Path: ".well-known"
	Uri-Path: "dots"		Uri-Path: "dots"
	Uri-Path: "tm"		Uri-Path: "tm"
	Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"		Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
	Observe: 0		Observe: 0
	Figure 30: GET to Subscribe to Telemetry Asynchronous Notifications		Figure 32: GET to Subscribe to Telemetry Asynchronous Notifications
	for All 'tmids'		for All 'tmids'
	The DOTS server will then send asynchronous notifications to the DOTS		The DOTS server will send asynchronous notifications to the DOTS
	client when an event if following similar considerations as in		client when an event if following similar considerations as in
	Section 4.4.2.1 of [I-D.ietf-dots-signal-channel]. An example of a		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.		pre-mitugation telemetry notification is shown in Figure 33.
	{		{
	"ietf-dots-telemetry:telemetry": {		"ietf-dots-telemetry:telemetry": {
	"target": [		"target": [
	{		{
	"tmid": 123,		"tmid": 123,
	"target-prefix": [		"target-prefix": [
	"2001:db8::1/128"		"2001:db8::1/128"
	]		]
	"total-attack-traffic": [		"total-attack-traffic": [
	skipping to change at page 41, line 44 ¶		skipping to change at page 42, line 44 ¶
	],		],
	"attack-detail": {		"attack-detail": {
	"start-time": "1957818434",		"start-time": "1957818434",
	"attack-severity": "emergency"		"attack-severity": "emergency"
	}		}
	}		}
	]		]
	}		}
	}		}
	Figure 31: Message Body of a Pre-mitigation Telemetry Notification		Figure 33: Message Body of a Pre-mitigation Telemetry Notification
	from the DOTS Server		from the DOTS Server
	A DOTS server may aggregate pre-mitigation data (e.g., 'top-talkers')		A DOTS server may aggregate pre-mitigation data (e.g., 'top-talkers')
	for all targets of a domain, or when justified, send specific		for all targets of a domain, or when justified, send specific
	information (e.g., 'top-talkers') per individual targets.		information (e.g., 'top-talkers') per individual targets.
	The DOTS client may log pre-mitigation telemetry data with an alert		The DOTS client may log pre-mitigation telemetry data with an alert
	to an administrator or a network controller. The DOTS client may		to an administrator or a network controller. The DOTS client may
	send a mitigation request if the attack cannot be handled locally.		send a mitigation request if the attack cannot be handled locally.
	skipping to change at page 42, line 21 ¶		skipping to change at page 43, line 21 ¶
	8.1. DOTS Client to Server Mitigation Efficacy DOTS Telemetry		8.1. DOTS Client to Server Mitigation Efficacy DOTS Telemetry
	Attributes		Attributes
	The mitigation efficacy telemetry attributes can be signaled from		The mitigation efficacy telemetry attributes can be signaled from
	DOTS clients to DOTS servers as part of the periodic mitigation		DOTS clients to DOTS servers as part of the periodic mitigation
	efficacy updates to the server (Section 5.3.4 of		efficacy updates to the server (Section 5.3.4 of
	[I-D.ietf-dots-signal-channel]).		[I-D.ietf-dots-signal-channel]).
	Total Attack Traffic: The overall attack traffic as observed from		Total Attack Traffic: The overall attack traffic as observed from
	the DOTS client perspective during an active mitigation. See		the DOTS client perspective during an active mitigation. See
	Figure 24.		Figure 26.
	Attack Details: The overall attack details as observed from the		Attack Details: The overall attack details as observed from the
	DOTS client perspective during an active mitigation. See		DOTS client perspective during an active mitigation. See
	Section 7.1.5.		Section 7.1.5.
	The "ietf-dots-telemetry" YANG module augments the "mitigation-scope"		The "ietf-dots-telemetry" YANG module augments the "mitigation-scope"
	type message defined in "ietf-dots-signal" so that these attributes		type message defined in "ietf-dots-signal" so that these attributes
	can be signalled by a DOTS client in a mitigation efficacy update		can be signalled by a DOTS client in a mitigation efficacy update
	(Figure 32).		(Figure 34).
	augment /ietf-signal:dots-signal/ietf-signal:message-type		augment /ietf-signal:dots-signal/ietf-signal:message-type
	/ietf-signal:mitigation-scope/ietf-signal:scope:		/ietf-signal:mitigation-scope/ietf-signal:scope:
	+--rw total-attack-traffic* [unit] {dots-telemetry}?		+--rw total-attack-traffic* [unit] {dots-telemetry}?
	| ...		| ...
	+--rw attack-detail {dots-telemetry}?		+--rw attack-detail {dots-telemetry}?
	+--rw id? uint32		+--rw id? uint32
	+--rw attack-id? string		+--rw attack-id? string
	+--rw attack-name? string		+--rw attack-name? string
	+--rw attack-severity? attack-severity		+--rw attack-severity? attack-severity
	+--rw start-time? uint64		+--rw start-time? uint64
	+--rw end-time? uint64		+--rw end-time? uint64
	+--rw source-count		+--rw source-count
	| ...		| ...
	+--rw top-talker		+--rw top-talker
	...		...
	Figure 32: Telemetry Efficacy Update Tree Structure		Figure 34: Telemetry Efficacy Update Tree Structure
	In order to signal telemetry data in a mitigation efficacy update, it		In order to signal telemetry data in a mitigation efficacy update, it
	is RECOMMENDED that the DOTS client has already established a DOTS		is RECOMMENDED that the DOTS client has already established a DOTS
	telemetry setup session with the server in 'idle' time.		telemetry setup session with the server in 'idle' time.
	Header: PUT (Code=0.03)		Header: PUT (Code=0.03)
	Uri-Path: ".well-known"		Uri-Path: ".well-known"
	Uri-Path: "dots"		Uri-Path: "dots"
	Uri-Path: "mitigate"		Uri-Path: "mitigate"
	Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"		Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
	skipping to change at page 43, line 33 ¶		skipping to change at page 44, line 33 ¶
	{		{
	"ietf-dots-telemetry:unit": "megabytes-ps",		"ietf-dots-telemetry:unit": "megabytes-ps",
	"ietf-dots-telemetry:mid-percentile-g": "900"		"ietf-dots-telemetry:mid-percentile-g": "900"
	}		}
	]		]
	}		}
	]		]
	}		}
	}		}
	Figure 33: An Example of Mitigation Efficacy Update with Telemetry		Figure 35: An Example of Mitigation Efficacy Update with Telemetry
	Attributes		Attributes
	8.2. DOTS Server to Client Mitigation Status DOTS 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].
	skipping to change at page 45, line 8 ¶		skipping to change at page 46, line 8 ¶
	+--rw attack-name? string		+--rw attack-name? string
	+--rw attack-severity? attack-severity		+--rw attack-severity? attack-severity
	+--rw start-time? uint64		+--rw start-time? uint64
	+--rw end-time? uint64		+--rw end-time? uint64
	+--rw source-count		+--rw source-count
	| +--rw low-percentile-g? yang:gauge64		| +--rw low-percentile-g? yang:gauge64
	| +--rw mid-percentile-g? yang:gauge64		| +--rw mid-percentile-g? yang:gauge64
	| +--rw high-percentile-g? yang:gauge64		| +--rw high-percentile-g? yang:gauge64
	| +--rw peak-g? yang:gauge64		| +--rw peak-g? yang:gauge64
	+--rw top-talker		+--rw top-talker
	+--rw source-prefix* [source-prefix]		+--rw talker* [source-prefix]
	+--rw spoofed-status? boolean		+--rw spoofed-status? boolean
	+--rw source-prefix inet:ip-prefix		+--rw source-prefix inet:ip-prefix
	+--rw 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-c		+--rw low-percentile-c
	skipping to change at page 45, line 31 ¶		skipping to change at page 46, line 31 ¶
	| +--rw connection-ps? yang:gauge64		| +--rw connection-ps? yang:gauge64
	| +--rw request-ps? yang:gauge64		| +--rw request-ps? yang:gauge64
	| +--rw partial-request-ps? yang:gauge64		| +--rw partial-request-ps? yang:gauge64
	+--rw mid-percentile-c		+--rw mid-percentile-c
	| ...		| ...
	+--rw high-percentile-c		+--rw high-percentile-c
	| ...		| ...
	+--rw peak-c		+--rw peak-c
	...		...
	Figure 34 shows an example of an asynchronous notification of attack		Figure 36 shows an example of an asynchronous notification of attack
	mitigation status from the DOTS server. This notification signals		mitigation status from the DOTS server. This notification signals
	both the mid-percentile value of processed attack traffic and the		both the mid-percentile value of processed attack traffic and the
	peak percentile value of unique sources involved in the attack.		peak percentile value of unique sources involved in the attack.
	{		{
	"ietf-dots-signal-channel:mitigation-scope": {		"ietf-dots-signal-channel:mitigation-scope": {
	"scope": [		"scope": [
	{		{
	"mid": 12332,		"mid": 12332,
	"mitigation-start": "1507818434",		"mitigation-start": "1507818434",
	skipping to change at page 46, line 36 ¶		skipping to change at page 47, line 36 ¶
	"ietf-dots-telemetry::attack-detail": {		"ietf-dots-telemetry::attack-detail": {
	"ietf-dots-telemetry:source-count": {		"ietf-dots-telemetry:source-count": {
	"ietf-dots-telemetry:peak-g": "10000"		"ietf-dots-telemetry:peak-g": "10000"
	}		}
	}		}
	}		}
	]		]
	}		}
	}		}
	Figure 34: Response Body of a Mitigation Status With Telemetry		Figure 36: Response Body of a Mitigation Status With Telemetry
	Attributes		Attributes
	9. YANG Module		9. YANG Module
	This module uses types defined in [RFC6991] and [RFC8345].		This module uses types defined in [RFC6991] and [RFC8345].
	<CODE BEGINS> file "ietf-dots-telemetry@2020-01-23.yang"		<CODE BEGINS> file "ietf-dots-telemetry@2020-02-21.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 48, line 10 ¶		skipping to change at page 49, line 10 ¶
	Redistribution and use in source and binary forms, with or		Redistribution and use in source and binary forms, with or
	without modification, is permitted pursuant to, and subject		without modification, is permitted pursuant to, and subject
	to the license terms contained in, the Simplified BSD License		to the license terms contained in, the Simplified BSD License
	set forth in Section 4.c of the IETF Trust's Legal Provisions		set forth in Section 4.c of the IETF Trust's Legal Provisions
	Relating to IETF Documents		Relating to IETF Documents
	(http://trustee.ietf.org/license-info).		(http://trustee.ietf.org/license-info).
	This version of this YANG module is part of RFC XXXX; see		This version of this YANG module is part of RFC XXXX; see
	the RFC itself for full legal notices.";		the RFC itself for full legal notices.";
	revision 2020-01-23 {		revision 2020-02-21 {
	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 49, line 21 ¶		skipping to change at page 50, line 21 ¶
	enum bps {		enum bps {
	value 3;		value 3;
	description		description
	"Bit per Second (BPS).";		"Bit per Second (BPS).";
	}		}
	enum kilobyte-ps {		enum kilobyte-ps {
	value 4;		value 4;
	description		description
	"Kilobyte per second.";		"Kilobyte per second.";
	}		}
	enum megabyte-ps {		enum megabit-ps {
	value 5;		value 5;
	description		description
			"Megabit per second.";
			}
			enum megabyte-ps {
			value 6;
			description
	"Megabyte per second.";		"Megabyte per second.";
	}		}
	enum gigabit-ps {		enum gigabit-ps {
	value 6;		value 7;
	description		description
	"Gigabit per second.";		"Gigabit per second.";
	}		}
	enum gigabyte-ps {		enum gigabyte-ps {
	value 7;		value 8;
	description		description
	"Gigabyte per second.";		"Gigabyte per second.";
	}		}
	enum terabit-ps {		enum terabit-ps {
	value 8;		value 9;
	description		description
	"Terabit per second.";		"Terabit per second.";
	}		}
			enum terabyte-ps {
			value 10;
			description
			"Terabyte 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;
	description		description
	skipping to change at page 59, line 26 ¶		skipping to change at page 60, line 36 ¶
	description		description
	"Indicates the count of unique sources involved		"Indicates the count of unique sources involved
	in the attack.";		in the attack.";
	uses percentile;		uses percentile;
	}		}
	}		}
	grouping top-talker-aggregate {		grouping top-talker-aggregate {
	description		description
	"Top attack sources.";		"Top attack sources.";
	list source-prefix {		list talker {
	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
	"Indicates whether this address is spoofed.";		"Indicates whether this address is spoofed.";
	}		}
	leaf source-prefix {		leaf source-prefix {
	type inet:ip-prefix;		type inet:ip-prefix;
	skipping to change at page 60, line 4 ¶		skipping to change at page 61, line 14 ¶
	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;
	}		}
	}		}
	}		}
	grouping top-talker {		grouping top-talker {
	description		description
	"Top attack sources.";		"Top attack sources.";
	list source-prefix {		list talker {
	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
	"Indicates whether this address is spoofed.";		"Indicates whether this address is spoofed.";
	}		}
	leaf source-prefix {		leaf source-prefix {
	type inet:ip-prefix;		type inet:ip-prefix;
	skipping to change at page 67, line 4 ¶		skipping to change at page 68, line 14 ¶
	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 {		leaf-list alias-name {
	type string;		type string;
	description		description
	"An alias name that points to a resource.";		"An alias name that points to a resource.";
			}
			leaf-list mid-list {
			type uint32;
			description
			"Reference a list of associated mitigation requests.";
	}		}
	}		}
	uses pre-mitigation;		uses pre-mitigation;
	}		}
	}		}
	}		}
	}		}
	<CODE ENDS>		<CODE ENDS>
	10. YANG/JSON Mapping Parameters to CBOR		10. YANG/JSON Mapping Parameters to CBOR
	skipping to change at page 69, line 4 ¶		skipping to change at page 70, line 19 ¶
	| baseline | container |TBA51 | 5 map | Object |		| baseline | container |TBA51 | 5 map | Object |
	| current-config | container |TBA52 | 5 map | Object |		| current-config | container |TBA52 | 5 map | Object |
	| max-config-values | container |TBA53 | 5 map | Object |		| max-config-values | container |TBA53 | 5 map | Object |
	| min-config-values | container |TBA54 | 5 map | Object |		| min-config-values | container |TBA54 | 5 map | Object |
	| supported-units | container |TBA55 | 5 map | Object |		| supported-units | container |TBA55 | 5 map | Object |
	| server-originated- | boolean |TBA56 | 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 |TBA57 | 0 unsigned | Number |		| telemetry-notify- | uint32 |TBA57 | 0 unsigned | Number |
	| interval | | | | |		| interval | | | | |
	| tmid | uint32 |TBA58 | 0 unsigned | Number |		| tmid | uint32 |TBA58 | 0 unsigned | Number |
			| measurement-interval | identityref |TBA59 | 0 unsigned | String |
			| measurement-sample | identityref |TBA60 | 0 unsigned | String |
			| ietf-dots-telemetry: | | | | |
			| total-traffic | list |TBA61 | 4 array | Array |
			| ietf-dots-telemetry: | | | | |
			| unit | enumeration |TBA62 | 0 unsigned | String |
			| ietf-dots-telemetry: | | | | |
			| low-percentile-g | yang:gauge64|TBA63 | 0 unsigned | String |
			| ietf-dots-telemetry: | | | | |
			| mid-percentile-g | yang:gauge64|TBA64 | 0 unsigned | String |
			| ietf-dots-telemetry: | | | | |
			| high-percentile-g | yang:gauge64|TBA65 | 0 unsigned | String |
			| ietf-dots-telemetry: | | | | |
			| peak-g | yang:gauge64|TBA66 | 0 unsigned | String |
			| ietf-dots-telemetry: | | | | |
			| total-attack-traffic | list |TBA67 | 4 array | Array |
			| ietf-dots-telemetry: | | | | |
			| total-attack- | | | | |
			| connection | container |TBA68 | 5 map | Object |
			| ietf-dots-telemetry: | | | | |
			| low-percentile-c | container |TBA69 | 5 map | Object |
			| ietf-dots-telemetry: | | | | |
			| mid-percentile-c | container |TBA70 | 5 map | Object |
			| ietf-dots-telemetry: | | | | |
			| high-percentile-c | container |TBA71 | 5 map | Object |
			| ietf-dots-telemetry: | | | | |
			| peak-c | container |TBA72 | 5 map | Object |
			| ietf-dots-telemetry: | | | | |
			| connection | uint64 |TBA73 | 0 unsigned | String |
			| ietf-dots-telemetry: | | | | |
			| embryonic | uint64 |TBA74 | 0 unsigned | String |
			| ietf-dots-telemetry: | | | | |
			| connection-ps | uint64 |TBA75 | 0 unsigned | String |
			| ietf-dots-telemetry: | | | | |
			| request-ps | uint64 |TBA76 | 0 unsigned | String |
			| ietf-dots-telemetry: | | | | |
			| partial-request-ps | uint64 |TBA77 | 0 unsigned | String |
			| ietf-dots-telemetry: | | | | |
			| attack-detail | container |TBA78 | 5 map | Object |
			| ietf-dots-telemetry: | | | | |
			| id | uint32 |TBA79 | 0 unsigned | Number |
			| ietf-dots-telemetry: | | | | |
			| attack-id | string |TBA80 | 3 text string | String |
			| ietf-dots-telemetry: | | | | |
			| attack-name | string |TBA81 | 3 text string | String |
			| ietf-dots-telemetry: | | | | |
			| attack-severity | enumeration |TBA82 | 0 unsigned | String |
			| ietf-dots-telemetry: | | | | |
			| start-time | uint64 |TBA83 | 0 unsigned | String |
			| ietf-dots-telemetry: | | | | |
			| end-time | uint64 |TBA84 | 0 unsigned | String |
			| ietf-dots-telemetry: | | | | |
			| source-count | container |TBA85 | 5 map | Object |
			| ietf-dots-telemetry: | | | | |
			| top-talker | container |TBA86 | 5 map | Object |
			| ietf-dots-telemetry: | | | | |
			| spoofed-status | boolean |TBA87 | 7 bits 20 | False |
			| | | | 7 bits 21 | True |
			| talker | list |TBA88 | 4 array | Array |
			| ietf-dots-telemetry: | | | | |
			| talker | list |TBA89 | 4 array | Array |
			| source-prefix | inet: |TBA90 | 3 text string | String |
			| | ip-prefix | | | |
			| ietf-dots-telemetry: | inet: |TBA91 | 3 text string | String |
			| source-prefix | ip-prefix | | | |
			| mid-list | leaf-list |TBA92 | 4 array | Array |
			| | uint32 | | 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 70, line 45 ¶		skipping to change at page 73, line 31 ¶
	| ietf-dots-signal-cha | TBA51 | 5 | IESG | [RFCXXXX] |		| ietf-dots-signal-cha | TBA51 | 5 | IESG | [RFCXXXX] |
	| current-config | TBA52 | 5 | IESG | [RFCXXXX] |		| current-config | TBA52 | 5 | IESG | [RFCXXXX] |
	| max-config-value | TBA53 | 5 | IESG | [RFCXXXX] |		| max-config-value | TBA53 | 5 | IESG | [RFCXXXX] |
	| min-config-values | TBA54 | 5 | IESG | [RFCXXXX] |		| min-config-values | TBA54 | 5 | IESG | [RFCXXXX] |
	| supported-units | TBA55 | 5 | IESG | [RFCXXXX] |		| supported-units | TBA55 | 5 | IESG | [RFCXXXX] |
	| server-originated- | TBA56 | 7 | IESG | [RFCXXXX] |		| server-originated- | TBA56 | 7 | IESG | [RFCXXXX] |
	| telemetry | | | | |		| telemetry | | | | |
	| telemetry-notify- | TBA57 | 0 | IESG | [RFCXXXX] |		| telemetry-notify- | TBA57 | 0 | IESG | [RFCXXXX] |
	| interval | | | | |		| interval | | | | |
	| tmid | TBA58 | 0 | IESG | [RFCXXXX] |		| tmid | TBA58 | 0 | IESG | [RFCXXXX] |
			| measurement-interval | TBA59 | 0 | IESG | [RFCXXXX] |
			| measurement-sample | TBA60 | 0 | IESG | [RFCXXXX] |
			| ietf-dots-telemetry: | TBA61 | 0 | IESG | [RFCXXXX] |
			| total-traffic | | | | |
			| ietf-dots-telemetry: | TBA62 | 0 | IESG | [RFCXXXX] |
			| unit | | | | |
			| ietf-dots-telemetry: | TBA63 | 0 | IESG | [RFCXXXX] |
			| low-percentile-g | | | | |
			| ietf-dots-telemetry: | TBA64 | 0 | IESG | [RFCXXXX] |
			| mid-percentile-g | | | | |
			| ietf-dots-telemetry: | TBA65 | 0 | IESG | [RFCXXXX] |
			| high-percentile-g | | | | |
			| ietf-dots-telemetry: | TBA66 | 0 | IESG | [RFCXXXX] |
			| peak-g | | | | |
			| ietf-dots-telemetry: | TBA67 | 0 | IESG | [RFCXXXX] |
			| total-attack-traffic | | | | |
			| ietf-dots-telemetry: | TBA68 | 0 | IESG | [RFCXXXX] |
			| total-attack- | | | | |
			| connection | | | | |
			| ietf-dots-telemetry: | TBA69 | 0 | IESG | [RFCXXXX] |
			| low-percentile-c | | | | |
			| ietf-dots-telemetry: | TBA70 | 0 | IESG | [RFCXXXX] |
			| mid-percentile-c | | | | |
			| ietf-dots-telemetry: | TBA71 | 0 | IESG | [RFCXXXX] |
			| high-percentile-c | | | | |
			| ietf-dots-telemetry: | TBA72 | 0 | IESG | [RFCXXXX] |
			| peak-c | | | | |
			| ietf-dots-telemetry: | TBA73 | 0 | IESG | [RFCXXXX] |
			| connection | | | | |
			| ietf-dots-telemetry: | TBA74 | 0 | IESG | [RFCXXXX] |
			| embryonic | | | | |
			| ietf-dots-telemetry: | TBA75 | 0 | IESG | [RFCXXXX] |
			| connection-ps | | | | |
			| ietf-dots-telemetry: | TBA76 | 0 | IESG | [RFCXXXX] |
			| request-ps | | | | |
			| ietf-dots-telemetry: | TBA77 | 0 | IESG | [RFCXXXX] |
			| partial-request-ps | | | | |
			| ietf-dots-telemetry: | TBA78 | 0 | IESG | [RFCXXXX] |
			| attack-detail | | | | |
			| ietf-dots-telemetry: | TBA79 | 0 | IESG | [RFCXXXX] |
			| id | | | | |
			| ietf-dots-telemetry: | TBA80 | 0 | IESG | [RFCXXXX] |
			| attack-id | | | | |
			| ietf-dots-telemetry: | TBA81 | 0 | IESG | [RFCXXXX] |
			| attack-name | | | | |
			| ietf-dots-telemetry: | TBA82 | 0 | IESG | [RFCXXXX] |
			| attack-severity | | | | |
			| ietf-dots-telemetry: | TBA83 | 0 | IESG | [RFCXXXX] |
			| start-time | | | | |
			| ietf-dots-telemetry: | TBA84 | 0 | IESG | [RFCXXXX] |
			| end-time | | | | |
			| ietf-dots-telemetry: | TBA85 | 0 | IESG | [RFCXXXX] |
			| source-count | | | | |
			| ietf-dots-telemetry: | TBA86 | 0 | IESG | [RFCXXXX] |
			| top-talker | | | | |
			| ietf-dots-telemetry: | TBA87 | 0 | IESG | [RFCXXXX] |
			| spoofed-status | | | | |
			| talker | TBA88 | 0 | IESG | [RFCXXXX] |
			| ietf-dots-telemetry: | TBA89 | 0 | IESG | [RFCXXXX] |
			| talker | | | | |
			| source-prefix | TBA90 | 0 | IESG | [RFCXXXX] |
			| ietf-dots-telemetry: | TBA91 | 0 | IESG | [RFCXXXX] |
			| source-prefix | | | | |
			| mid-list | TBA92 | 4 | 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
End of changes. 64 change blocks.
	94 lines changed or deleted		271 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/