< draft-ietf-dots-telemetry-20.txt		draft-ietf-dots-telemetry-21.txt >
	DOTS M. Boucadair, Ed.		DOTS M. Boucadair, Ed.
	Internet-Draft Orange		Internet-Draft Orange
	Intended status: Standards Track T. Reddy.K, Ed.		Intended status: Standards Track T. Reddy.K, Ed.
	Expires: 28 July 2022 Akamai		Expires: 7 August 2022 Akamai
	E. Doron		E. Doron
	Radware Ltd.		Radware Ltd.
	M. Chen		M. Chen
	CMCC		CMCC
	J. Shallow		J. Shallow
	24 January 2022		3 February 2022
	Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry		Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry
	draft-ietf-dots-telemetry-20		draft-ietf-dots-telemetry-21
	Abstract		Abstract
	This document aims to enrich the DOTS signal channel protocol with		This document aims to enrich the DOTS signal channel protocol with
	various telemetry attributes, allowing for optimal Distributed		various telemetry attributes, allowing for optimal Distributed
	Denial-of-Service (DDoS) attack mitigation. It specifies the normal		Denial-of-Service (DDoS) attack mitigation. It specifies the normal
	traffic baseline and attack traffic telemetry attributes a DOTS		traffic baseline and attack traffic telemetry attributes a DOTS
	client can convey to its DOTS server in the mitigation request, the		client can convey to its DOTS server in the mitigation request, the
	mitigation status telemetry attributes a DOTS server can communicate		mitigation status telemetry attributes a DOTS server can communicate
	to a DOTS client, and the mitigation efficacy telemetry attributes a		to a DOTS client, and the mitigation efficacy telemetry attributes a
	DOTS client can communicate to a DOTS server. The telemetry		DOTS client can communicate to a DOTS server. The telemetry
	attributes can assist the mitigator to choose the DDoS mitigation		attributes can assist the mitigator to choose the DDoS mitigation
	techniques and perform optimal DDoS attack mitigation.		techniques and perform optimal DDoS attack mitigation.
			This document specifies a YANG module for representing DOTS telemetry
			message types. It also specifies a second YANG module to share the
			attack mapping details over the DOTS data channel.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on 28 July 2022.		This Internet-Draft will expire on 7 August 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2022 IETF Trust and the persons identified as the		Copyright (c) 2022 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 (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 3, line 26 ¶		skipping to change at page 3, line 26 ¶
	8.2. From DOTS Clients to DOTS Servers . . . . . . . . . . . . 56		8.2. From DOTS Clients to DOTS Servers . . . . . . . . . . . . 56
	8.3. From DOTS Servers to DOTS Clients . . . . . . . . . . . . 59		8.3. From DOTS Servers to DOTS Clients . . . . . . . . . . . . 59
	9. DOTS Telemetry Mitigation Status Update . . . . . . . . . . . 64		9. DOTS Telemetry Mitigation Status Update . . . . . . . . . . . 64
	9.1. DOTS Clients to Servers Mitigation Efficacy DOTS Telemetry		9.1. DOTS Clients to Servers Mitigation Efficacy DOTS Telemetry
	Attributes . . . . . . . . . . . . . . . . . . . . . . . 64		Attributes . . . . . . . . . . . . . . . . . . . . . . . 64
	9.2. DOTS Servers to Clients Mitigation Status DOTS Telemetry		9.2. DOTS Servers to Clients Mitigation Status DOTS Telemetry
	Attributes . . . . . . . . . . . . . . . . . . . . . . . 66		Attributes . . . . . . . . . . . . . . . . . . . . . . . 66
	10. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 70		10. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 70
	11. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 71		11. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 71
	11.1. DOTS Signal Channel Telemetry YANG Module . . . . . . . 71		11.1. DOTS Signal Channel Telemetry YANG Module . . . . . . . 71
	11.2. Vendor Attack Mapping Details YANG Module . . . . . . . 100		11.2. Vendor Attack Mapping Details YANG Module . . . . . . . 101
	12. YANG/JSON Mapping Parameters to CBOR . . . . . . . . . . . . 103		12. YANG/JSON Mapping Parameters to CBOR . . . . . . . . . . . . 105
	13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 106		13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 108
	13.1. DOTS Signal Channel CBOR Key Values . . . . . . . . . . 106		13.1. DOTS Signal Channel CBOR Key Values . . . . . . . . . . 108
	13.2. DOTS Signal Channel Conflict Cause Codes . . . . . . . . 109		13.2. DOTS Signal Channel Conflict Cause Codes . . . . . . . . 110
	13.3. DOTS Signal Telemetry YANG Module . . . . . . . . . . . 109		13.3. DOTS Signal Telemetry YANG Module . . . . . . . . . . . 111
	14. Security Considerations . . . . . . . . . . . . . . . . . . . 110		14. Security Considerations . . . . . . . . . . . . . . . . . . . 111
	14.1. DOTS Signal Channel Telemetry . . . . . . . . . . . . . 110		14.1. DOTS Signal Channel Telemetry . . . . . . . . . . . . . 112
	14.2. Vendor Attack Mapping . . . . . . . . . . . . . . . . . 111		14.2. Vendor Attack Mapping . . . . . . . . . . . . . . . . . 113
	15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 112		15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 114
	16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 112		16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 114
	17. References . . . . . . . . . . . . . . . . . . . . . . . . . 112		17. References . . . . . . . . . . . . . . . . . . . . . . . . . 114
	17.1. Normative References . . . . . . . . . . . . . . . . . . 112		17.1. Normative References . . . . . . . . . . . . . . . . . . 114
	17.2. Informative References . . . . . . . . . . . . . . . . . 114		17.2. Informative References . . . . . . . . . . . . . . . . . 116
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 116		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 118
	1. Introduction		1. Introduction
	IT organizations and service providers are facing Distributed Denial		IT organizations and service providers are facing Distributed Denial
	of Service (DDoS) attacks that fall into two broad categories:		of Service (DDoS) attacks that fall into two broad categories:
	1. Network/Transport layer attacks target the victim's		1. Network/Transport layer attacks target the victim's
	infrastructure. These attacks are not necessarily aimed at		infrastructure. These attacks are not necessarily aimed at
	taking down the actual delivered services, but rather to prevent		taking down the actual delivered services, but rather to prevent
	various network elements (routers, switches, firewalls, transit		various network elements (routers, switches, firewalls, transit
	skipping to change at page 4, line 21 ¶		skipping to change at page 4, line 21 ¶
	(Network Time Protocol), DNS (Domain Name System), SNMP (Simple		(Network Time Protocol), DNS (Domain Name System), SNMP (Simple
	Network Management Protocol), or SSDP (Simple Service Discovery		Network Management Protocol), or SSDP (Simple Service Discovery
	Protocol).		Protocol).
	2. Application layer attacks target various applications. Typical		2. Application layer attacks target various applications. Typical
	examples include attacks against HTTP/HTTPS, DNS, SIP (Session		examples include attacks against HTTP/HTTPS, DNS, SIP (Session
	Initiation Protocol), or SMTP (Simple Mail Transfer Protocol).		Initiation Protocol), or SMTP (Simple Mail Transfer Protocol).
	However, all applications with their port numbers open at network		However, all applications with their port numbers open at network
	edges can be attractive attack targets.		edges can be attractive attack targets.
	Application layer attacks are considered more complex and hard to		Application layer attacks are considered more complex and harder
	categorize, and therefore harder to detect and mitigate		to categorize, and therefore harder to detect and mitigate
	efficiently.		efficiently.
	To compound the problem, attackers also leverage multi-vectored		To compound the problem, attackers also leverage multi-vectored
	attacks. These attacks are assembled from dynamic attack vectors		attacks. These attacks are assembled from dynamic attack vectors
	(Network/Application) and tactics. As such, multiple attack vectors		(Network/Application) and tactics. As such, multiple attack vectors
	formed by multiple attack types and volumes are launched		formed by multiple attack types and volumes are launched
	simultaneously towards a victim. Multi-vector attacks are harder to		simultaneously towards a victim. Multi-vector attacks are harder to
	detect and defend against. Multiple and simultaneous mitigation		detect and defend against. Multiple and simultaneous mitigation
	techniques are needed to defeat such attack campaigns. It is also		techniques are needed to defeat such attack campaigns. It is also
	common for attackers to change attack vectors right after a		common for attackers to change attack vectors right after a
	successful mitigation, burdening their opponents with changing their		successful mitigation, burdening their opponents with changing their
	defense methods.		defense methods.
	The conclusion derived from these real scenarios is that modern		The conclusion derived from the aforementioned attack scenarios is
	attacks detection and mitigation are most certainly complicated and		that modern attacks detection and mitigation are most certainly
	highly convoluted tasks. They demand a comprehensive knowledge of		complicated and highly convoluted tasks. They demand a comprehensive
	the attack attributes, the normal behavior of the targeted systems		knowledge of the attack attributes, the normal behavior of the
	(including normal traffic patterns), as well as the attacker's		targeted systems (including normal traffic patterns), as well as the
	ongoing and past actions. Even more challenging, retrieving all the		attacker's ongoing and past actions. Even more challenging,
	analytics needed for detecting these attacks is not simple with the		retrieving all the analytics needed for detecting these attacks is
	industry's current reporting capabilities.		not simple with the industry's current reporting capabilities.
	The DOTS signal channel protocol [RFC9132] is used to carry		The DOTS signal channel protocol [RFC9132] is used to carry
	information about a network resource or a network (or a part thereof)		information about a network resource or a network (or a part thereof)
	that is under a DDoS attack. Such information is sent by a DOTS		that is under a DDoS attack. Such information is sent by a DOTS
	client to one or multiple DOTS servers so that appropriate mitigation		client to one or multiple DOTS servers so that appropriate mitigation
	actions are undertaken on traffic deemed suspicious. Various use		actions are undertaken on traffic deemed suspicious. Various use
	cases are discussed in [RFC8903].		cases are discussed in [RFC8903].
	DOTS clients can be integrated within a DDoS attack detector, or		DOTS clients can be integrated within a DDoS attack detector, or
	network and security elements that have been actively engaged with		network and security elements that have been actively engaged with
	skipping to change at page 6, line 15 ¶		skipping to change at page 6, line 15 ¶
	The reader should be familiar with the terms defined in [RFC8612].		The reader should be familiar with the terms defined in [RFC8612].
	"DOTS Telemetry" is defined as the collection of attributes that are		"DOTS Telemetry" is defined as the collection of attributes that are
	used to characterize the normal traffic baseline, attacks and their		used to characterize the normal traffic baseline, attacks and their
	mitigation measures, and any related information that may help in		mitigation measures, and any related information that may help in
	enforcing countermeasures. DOTS Telemetry is an optional set of		enforcing countermeasures. DOTS Telemetry is an optional set of
	attributes that can be signaled in the DOTS signal channel protocol.		attributes that can be signaled in the DOTS signal channel protocol.
	Telemetry Setup Identifier (tsid) is an identifier that is generated		Telemetry Setup Identifier (tsid) is an identifier that is generated
	by DOTS clients to uniquely identify DOTS telemetry setup		by DOTS clients to uniquely identify DOTS telemetry setup
	configuration data.		configuration data. See Section 7.1.2 for more details.
	Telemetry Identifier (tmid) is an identifier that is generated by		Telemetry Identifier (tmid) is an identifier that is generated by
	DOTS clients to uniquely identify DOTS telemetry data that is		DOTS clients to uniquely identify DOTS telemetry data that is
	communicated prior to or during a mitigation.		communicated prior to or during a mitigation. See Section 8.2 for
			more details.
	When two telemetry requests overlap, "overlapped" lower numeric		When two telemetry requests overlap, "overlapped" lower numeric
	'tsid' (or 'tmid') refers to the lower 'tsid' (or 'tmid') value of		'tsid' (or 'tmid') refers to the lower 'tsid' (or 'tmid') value of
	these overlapping requests.		these overlapping requests.
	The term "pipe" represents the maximum level of traffic that the DOTS		The term "pipe" represents the maximum level of traffic that the DOTS
	client domain can receive. Whether a "pipe" is mapped to one or a		client domain can receive. Whether a "pipe" is mapped to one or a
	group of network interfaces is deployment-specific. For example,		group of network interfaces is deployment-specific. For example,
	each interconnection link may be considered as a specific pipe if the		each interconnection link may be considered as a specific pipe if the
	DOTS server is hosted by each upstream provider, whike the aggregate		DOTS server is hosted by each upstream provider, while the aggregate
	of all links to connect to upstream network providers can be		of all links to connect to upstream network providers can be
	considered by a DOTS client domain as a single pipe when		considered by a DOTS client domain as a single pipe when
	communicating with a DOTS server not hosted by these upstream		communicating with a DOTS server not hosted by these upstream
	providers.		providers.
	The document uses IANA-assigned Enterprise Numbers. These numbers		The document uses IANA-assigned Enterprise Numbers. These numbers
	are also known as "Private Enterprise Numbers" and "SMI (Structure of		are also known as "Private Enterprise Numbers" and "SMI (Structure of
	Management Information) Network Management Private Enterprise Codes"		Management Information) Network Management Private Enterprise Codes"
	[Private-Enterprise-Numbers].		[Private-Enterprise-Numbers].
	The meaning of the symbols in YANG tree diagrams are defined in		The meaning of the symbols in YANG tree diagrams are defined in
	[RFC8340] and [RFC8791].		[RFC8340] and [RFC8791].
	Consistent with the convention set in Section 2 of [RFC8783], the		Consistent with the convention set in Section 2 of [RFC8783], the
	examples in Section 8.1.6 use "/restconf" as the discovered RESTCONF		examples in Section 8.1.6 use "/restconf" as the discovered RESTCONF
	API root path. Within these examples, some protocol header lines are		API root path. Within these examples, some protocol header lines are
	split into multiple lines for display purposes only. When a line		split into multiple lines for display purposes only. When a line
	ends with backslash ('\') as the last character, the line is wrapped		ends with backslash ('\') as the last character, the line is wrapped
	for display purposes. It is to be considered to be joined to the		for display purposes. It is considered to be joined to the next line
	next line by deleting the backslash, the following line break, and		by deleting the backslash, the following line break, and the leading
	the leading whitespace of the next line.		whitespace of the next line.
	3. DOTS Telemetry: Overview and Purpose		3. DOTS Telemetry: Overview and Purpose
	Timely and effective signaling of up-to-date DDoS telemetry to all		Timely and effective signaling of up-to-date DDoS telemetry to all
	elements involved in the mitigation process is essential and improves		elements involved in the mitigation process is essential and improves
	the overall DDoS mitigation service effectiveness. Bi-directional		the overall DDoS mitigation service effectiveness. Bi-directional
	feedback between DOTS agents is required for increased awareness by		feedback between DOTS agents is required for increased awareness by
	each party of the attack and mitigation efforts, supporting a		each party of the attack and mitigation efforts, supporting a
	superior and highly efficient attack mitigation service.		superior and highly efficient attack mitigation service.
	skipping to change at page 8, line 33 ¶		skipping to change at page 8, line 33 ¶
	DOTS telemetry can also be used as input for determining what values		DOTS telemetry can also be used as input for determining what values
	to use for the tuning parameters available on the mitigation		to use for the tuning parameters available on the mitigation
	resources. During the last few years, DDoS attack detection		resources. During the last few years, DDoS attack detection
	technologies have evolved from threshold-based detection (that is,		technologies have evolved from threshold-based detection (that is,
	cases when all or specific parts of traffic cross a predefined		cases when all or specific parts of traffic cross a predefined
	threshold for a certain period of time is considered as an attack) to		threshold for a certain period of time is considered as an attack) to
	an "anomaly detection" approach. For the latter, it is required to		an "anomaly detection" approach. For the latter, it is required to
	maintain rigorous learning of "normal" behavior, and an "anomaly" (or		maintain rigorous learning of "normal" behavior, and an "anomaly" (or
	an attack) is identified and categorized based on the knowledge about		an attack) is identified and categorized based on the knowledge about
	the normal behavior and a deviation from this normal behavior.		the normal behavior and a deviation from this normal behavior.
	Machine learning approaches are used such that the actual traffic		Statistical and artificial intelligence algorithms (e.g., machine
	thresholds are automatically calculated by learning the protected		learning) are used such that the actual traffic thresholds are
	entity's normal traffic behavior during 'idle' time (i.e., no		automatically calculated by learning the protected entity's normal
	mitigation is active). The normal traffic characterization learned		traffic behavior during 'idle' time (i.e., no mitigation is active).
	is referred to as the "normal traffic baseline". An attack is		The normal traffic characterization learned is referred to as the
	detected when the victim's actual traffic is deviating from this		"normal traffic baseline". An attack is detected when the victim's
	normal baseline pattern.		actual traffic is deviating from this normal baseline pattern.
	In addition, subsequent activities toward mitigating an attack are		In addition, subsequent activities toward mitigating an attack are
	much more challenging. The ability to distinguish legitimate traffic		much more challenging. The ability to distinguish legitimate traffic
	from attacker traffic on a per packet basis is complex. For example,		from attacker traffic on a per packet basis is complex. For example,
	a packet may look "legitimate" and no attack signature can be		a packet may look "legitimate" and no attack signature can be
	identified. The anomaly can be identified only after detailed		identified. The anomaly can be identified only after detailed
	statistical analysis. DDoS attack mitigators use the normal baseline		statistical analysis. DDoS attack mitigators use the normal baseline
	during the mitigation of an attack to identify and categorize the		during the mitigation of an attack to identify and categorize the
	expected appearance of a specific traffic pattern. Particularly, the		expected appearance of a specific traffic pattern. Particularly, the
	mitigators use the normal baseline to recognize the "level of		mitigators use the normal baseline to recognize the "level of
	skipping to change at page 11, line 13 ¶		skipping to change at page 11, line 13 ¶
	small messages that are important to deliver during an attack. As a		small messages that are important to deliver during an attack. As a
	reminder, both DOTS signal and data channels require secure		reminder, both DOTS signal and data channels require secure
	communication channels (Section 11 of [RFC9132] and Section 10 of		communication channels (Section 11 of [RFC9132] and Section 10 of
	[RFC8783]).		[RFC8783]).
	Telemetry information has aspects that correspond to both operational		Telemetry information has aspects that correspond to both operational
	modes (i.e., signal and data channels): there is certainly a need to		modes (i.e., signal and data channels): there is certainly a need to
	convey updated information about ongoing attack traffic and targets		convey updated information about ongoing attack traffic and targets
	during an attack, so as to convey detailed information about		during an attack, so as to convey detailed information about
	mitigation status and inform updates to mitigation strategy in the		mitigation status and inform updates to mitigation strategy in the
	face of adaptive attacks, but it is also useful to provide mitigation		face of adaptive attacks. However, it is also useful to provide
	services with a picture of normal or "baseline" traffic towards		mitigation services with a picture of normal or "baseline" traffic
	potential targets, to aid in detecting when incoming traffic deviates		towards potential targets to aid in detecting when incoming traffic
	from normal into being an attack. Also, one might populate a		deviates from normal into being an attack. Also, one might populate
	"database" of classifications of known types of attack so that a		a "database" of classifications of known types of attack so that a
	short attack identifier can be used during attack time to describe an		short attack identifier can be used during attack time to describe an
	observed attack. This specification does make provision for use of		observed attack. This specification does make provision for use of
	the DOTS data channel for the latter function (Section 8.1.6), but		the DOTS data channel for the latter function (Section 8.1.6), but
	otherwise retains most telemetry functionality in the DOTS signal		otherwise retains most telemetry functionality in the DOTS signal
	channel.		channel.
	Note that it is a functional requirement to convey information about		Note that it is a functional requirement to convey information about
	ongoing attack traffic during an attack, and information about		ongoing attack traffic during an attack, and information about
	baseline traffic uses an essentially identical data structure that is		baseline traffic uses an essentially identical data structure that is
	naturally defined to sit next to the description of attack traffic.		naturally defined to sit next to the description of attack traffic.
	skipping to change at page 13, line 14 ¶		skipping to change at page 13, line 14 ¶
	This document specifies a YANG module [RFC7950] for representing DOTS		This document specifies a YANG module [RFC7950] for representing DOTS
	telemetry message types (Section 11.1). All parameters in the		telemetry message types (Section 11.1). All parameters in the
	payload of the DOTS signal channel are mapped to CBOR types as		payload of the DOTS signal channel are mapped to CBOR types as
	specified in Section 12. As a reminder, Section 3 of [RFC9132]		specified in Section 12. As a reminder, Section 3 of [RFC9132]
	defines the rules for mapping YANG-modeled data to CBOR.		defines the rules for mapping YANG-modeled data to CBOR.
	The DOTS telemetry module (Section 11.1) is not intended to be used		The DOTS telemetry module (Section 11.1) is not intended to be used
	via NETCONF/RESTCONF for DOTS server management purposes. It serves		via NETCONF/RESTCONF for DOTS server management purposes. It serves
	only to provide a data model and encoding following [RFC8791].		only to provide a data model and encoding following [RFC8791].
	Server deviations are strongly discouraged, as the peer DOTS agent		Server deviations (Section 5.6.3 of [RFC7950]) are strongly
	does not have means to retrieve the list of deviations and thus		discouraged, as the peer DOTS agent does not have means to retrieve
	interoperability issues are likely to be encountered.		the list of deviations and thus interoperability issues are likely to
			be encountered.
	The DOTS telemetry module (Section 11.1) uses "enumerations" rather		The DOTS telemetry module (Section 11.1) uses "enumerations" rather
	than "identities" to define units, samples, and intervals because		than "identities" to define units, samples, and intervals because
	otherwise the namespace identifier "ietf-dots-telemetry" must be		otherwise the namespace identifier "ietf-dots-telemetry" must be
	included when a telemetry attribute is included (e.g., in a		included when a telemetry attribute is included (e.g., in a
	mitigation efficacy update). The use of "identities" is thus		mitigation efficacy update). The use of "identities" is thus
	suboptimal from a message compactness standpoint; one of the key		suboptimal from a message compactness standpoint; one of the key
	requirements for DOTS Signal Channel messages.		requirements for DOTS Signal Channel messages.
	The DOTS telemetry module (Section 11.1) includes some lists for		The DOTS telemetry module (Section 11.1) includes some lists for
	skipping to change at page 15, line 25 ¶		skipping to change at page 15, line 25 ¶
	together with the mapping table established in Section 12. The		together with the mapping table established in Section 12. The
	structure of telemetry message bodies is represented as a YANG data		structure of telemetry message bodies is represented as a YANG data
	structure (Section 11.1).		structure (Section 11.1).
	5.6. A Note About Examples		5.6. A Note About Examples
	Examples are provided for illustration purposes. The document does		Examples are provided for illustration purposes. The document does
	not aim to provide a comprehensive list of message examples.		not aim to provide a comprehensive list of message examples.
	JSON encoding of YANG-modeled data is used to illustrate the various		JSON encoding of YANG-modeled data is used to illustrate the various
	telemetry operations.		telemetry operations. To ease readability, parameter names and their
			JSON types are, thus, used in the examples rather than their CBOR key
			values and CBOR types following the mappings in Section 12. These
			conventions are inherited from [RFC9132].
	The examples use the Enterprise Number 32473 defined for		The examples use the Enterprise Number 32473 defined for
	documentation use [RFC5612].		documentation use [RFC5612].
	6. Telemetry Operation Paths		6. Telemetry Operation Paths
	As discussed in Section 4.2 of [RFC9132], each DOTS operation is		As discussed in Section 4.2 of [RFC9132], each DOTS operation is
	indicated by a path suffix that indicates the intended operation.		indicated by a path suffix that indicates the intended operation.
	The operation path is appended to the path prefix to form the URI		The operation path is appended to the path prefix to form the URI
	used with a CoAP request to perform the desired DOTS operation. The		used with a CoAP request to perform the desired DOTS operation. The
	skipping to change at page 20, line 15 ¶		skipping to change at page 20, line 15 ¶
	7.1.2. Conveying DOTS Telemetry Configuration		7.1.2. Conveying DOTS Telemetry Configuration
	A PUT request is used to convey the configuration parameters for the		A PUT request is used to convey the configuration parameters for the
	telemetry data (e.g., low, mid, or high percentile values). For		telemetry data (e.g., low, mid, or high percentile values). For
	example, a DOTS client may contact its DOTS server to change the		example, a DOTS client may contact its DOTS server to change the
	default percentile values used as baseline for telemetry data.		default percentile values used as baseline for telemetry data.
	Figure 3 lists the attributes that can be set by a DOTS client in		Figure 3 lists the attributes that can be set by a DOTS client in
	such a PUT request. An example of a DOTS client that modifies all		such a PUT request. An example of a DOTS client that modifies all
	percentile reference values is shown in Figure 4.		percentile reference values is shown in Figure 4.
			Note: The payload of the message depicted in Figure 4 is CBOR-
			encoded as indicated by the Content-Format set to "application/
			dots+cbor" (Section 10.3 of [RFC9132]). However, and for the sake
			of better readability, the example (and other similar figures
			depicting a DOTS telemetry message body) follows the conventions
			set in Section 5.6: use the JSON names and types defined in
			Section 12.
	Header: PUT (Code=0.03)		Header: PUT (Code=0.03)
	Uri-Path: ".well-known"		Uri-Path: ".well-known"
	Uri-Path: "dots"		Uri-Path: "dots"
	Uri-Path: "tm-setup"		Uri-Path: "tm-setup"
	Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"		Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"
	Uri-Path: "tsid=123"		Uri-Path: "tsid=123"
	Content-Format: "application/dots+cbor"		Content-Format: "application/dots+cbor"
	{		{
	"ietf-dots-telemetry:telemetry-setup": {		"ietf-dots-telemetry:telemetry-setup": {
	skipping to change at page 20, line 46 ¶		skipping to change at page 21, line 6 ¶
	Figure 4: PUT to Convey the DOTS Telemetry Configuration		Figure 4: PUT to Convey the DOTS Telemetry Configuration
	'cuid' is a mandatory Uri-Path parameter for PUT requests.		'cuid' is a mandatory Uri-Path parameter for PUT requests.
	The following additional Uri-Path parameter is defined:		The following additional Uri-Path parameter is defined:
	tsid: Telemetry Setup Identifier is an identifier for the DOTS		tsid: Telemetry Setup Identifier is an identifier for the DOTS
	telemetry setup configuration data represented as an integer.		telemetry setup configuration data represented as an integer.
	This identifier MUST be generated by DOTS clients. 'tsid'		This identifier MUST be generated by DOTS clients. 'tsid'
	values MUST increase monotonically (when a new PUT is generated		values MUST increase monotonically whenever new configuration
	by a DOTS client to convey new configuration parameters for the		parameters (not just for changed values) need to be conveyed by
	telemetry).		the DOTS client.
	The procedure specified in Section 4.4.1 of [RFC9132] for 'mid'		The procedure specified in Section 4.4.1 of [RFC9132] for 'mid'
	rollover MUST also be followed for 'tsid' rollover.		rollover MUST also be followed for 'tsid' rollover.
	This is a mandatory attribute. 'tsid' MUST follow 'cuid'.		This is a mandatory attribute. 'tsid' MUST appear after 'cuid'
			in the Uri-Path options.
	'cuid' and 'tsid' MUST NOT appear in the PUT request message body.		'cuid' and 'tsid' MUST NOT appear in the PUT request message body.
	At least one configurable attribute MUST be present in the PUT		At least one configurable attribute MUST be present in the PUT
	request.		request.
	A PUT request with a higher numeric 'tsid' value overrides the DOTS		A PUT request with a higher numeric 'tsid' value overrides the DOTS
	telemetry configuration data installed by a PUT request with a lower		telemetry configuration data installed by a PUT request with a lower
	numeric 'tsid' value. To avoid maintaining a long list of 'tsid'		numeric 'tsid' value. To avoid maintaining a long list of 'tsid'
	requests for requests carrying telemetry configuration data from a		requests for requests carrying telemetry configuration data from a
	skipping to change at page 47, line 11 ¶		skipping to change at page 47, line 11 ¶
	...		...
	Figure 27: Total Attack Traffic Tree Structure		Figure 27: Total Attack Traffic Tree Structure
	8.1.4. Total Attack Connections		8.1.4. Total Attack Connections
	If the target is susceptible to resource-consuming DDoS attacks, the		If the target is susceptible to resource-consuming DDoS attacks, the
	'total-attack-connection-protocol' attribute is used to convey the		'total-attack-connection-protocol' attribute is used to convey the
	percentile values (including peak and current observed values) of		percentile values (including peak and current observed values) of
	various attributes related to the total attack connections. The		various attributes related to the total attack connections. The
	following optional subattributes for the target per transport		following optional sub-attributes for the target per transport
	protocol are included to represent the attack characteristics:		protocol are included to represent the attack characteristics:
	* The number of simultaneous attack connections to the target.		* The number of simultaneous attack connections to the target.
	* The number of simultaneous embryonic connections to the target.		* The number of simultaneous embryonic connections to the target.
	* The number of attack connections per second to the target.		* The number of attack connections per second to the target.
	* The number of attack requests per second to the target.		* The number of attack requests per second to the target.
	* The number of attack partial requests to the target.		* The number of attack partial requests to the target.
	The total attack connections per port number is represented using the		The total attack connections per port number is represented using the
	'total-attack-connection-port' attribute.		'total-attack-connection-port' attribute.
	skipping to change at page 49, line 18 ¶		skipping to change at page 49, line 18 ¶
	| +-- peak-g? yang:gauge64		| +-- peak-g? yang:gauge64
	| +-- current-g? yang:gauge64		| +-- current-g? yang:gauge64
	+-- attack-detail* [vendor-id attack-id]		+-- attack-detail* [vendor-id attack-id]
	...		...
	Figure 28: Total Attack Connections Tree Structure		Figure 28: Total Attack Connections Tree Structure
	8.1.5. Attack Details		8.1.5. Attack Details
	This attribute (depicted in Figure 29) is used to signal a set of		This attribute (depicted in Figure 29) is used to signal a set of
	details characterizing an attack. The following subattributes		details characterizing an attack. The following sub-attributes
	describing the ongoing attack can be signalled as attack details:		describing the ongoing attack can be signalled as attack details:
	vendor-id: Vendor ID is a security vendor's enterprise number as		vendor-id: Vendor ID is a security vendor's enterprise number as
	registered in the IANA's "Private Enterprise Numbers" registry		registered in the IANA's "Private Enterprise Numbers" registry
	[Private-Enterprise-Numbers].		[Private-Enterprise-Numbers].
	attack-id: Unique identifier assigned for the attack by a vendor.		attack-id: Unique identifier assigned for the attack by a vendor.
	This parameter MUST be present independent of whether 'attack-		This parameter MUST be present independent of whether 'attack-
	description' is included or not.		description' is included or not.
			description-lang: Indicates the language tag that is used for the
			text that is included in the 'attack-description' attribute. The
			attribute is encoded following the rules in Section 2.1 of
			[RFC5646].
	attack-description: Textual representation of the attack		attack-description: Textual representation of the attack
	description. Natural Language Processing techniques (e.g., word		description. Natural Language Processing techniques (e.g., word
	embedding) might provide some utility in mapping the attack		embedding) might provide some utility in mapping the attack
	description to an attack type. Textual representation of attack		description to an attack type. Textual representation of attack
	solves two problems: (a) avoids the need to create mapping tables		solves two problems: (a) avoids the need to create mapping tables
	manually between vendors and (b) avoids the need to standardize		manually between vendors and (b) avoids the need to standardize
	attack types which keep evolving.		attack types which keep evolving.
	attack-severity: Attack severity level. This attribute takes one of		attack-severity: Attack severity level. This attribute takes one of
	the values defined in Section 3.12.2 of [RFC7970].		the values defined in Section 3.12.2 of [RFC7970].
	skipping to change at page 50, line 48 ¶		skipping to change at page 51, line 6 ¶
	| ...		| ...
	+-- total-attack-traffic-port* [unit port]		+-- total-attack-traffic-port* [unit port]
	| ...		| ...
	+-- total-attack-connection-protocol* [protocol]		+-- total-attack-connection-protocol* [protocol]
	| ...		| ...
	+-- total-attack-connection-port* [protocol port]		+-- total-attack-connection-port* [protocol port]
	| ...		| ...
	+-- attack-detail* [vendor-id attack-id]		+-- attack-detail* [vendor-id attack-id]
	+-- vendor-id uint32		+-- vendor-id uint32
	+-- attack-id uint32		+-- attack-id uint32
			+-- description-lang? string
	+-- attack-description? string		+-- attack-description? string
	+-- attack-severity? attack-severity		+-- attack-severity? attack-severity
	+-- start-time? uint64		+-- start-time? uint64
	+-- end-time? uint64		+-- end-time? uint64
	+-- source-count		+-- source-count
	| +-- low-percentile-g? yang:gauge64		| +-- low-percentile-g? yang:gauge64
	| +-- mid-percentile-g? yang:gauge64		| +-- mid-percentile-g? yang:gauge64
	| +-- high-percentile-g? yang:gauge64		| +-- high-percentile-g? yang:gauge64
	| +-- peak-g? yang:gauge64		| +-- peak-g? yang:gauge64
	| +-- current-g? yang:gauge64		| +-- current-g? yang:gauge64
	skipping to change at page 53, line 11 ¶		skipping to change at page 53, line 15 ¶
	The "ietf-dots-mapping" YANG module defined in Section 11.2 augments		The "ietf-dots-mapping" YANG module defined in Section 11.2 augments
	the "ietf-dots-data-channel" [RFC8783] module. The tree structure of		the "ietf-dots-data-channel" [RFC8783] module. The tree structure of
	the "ietf-dots-mapping" module is shown in Figure 30.		the "ietf-dots-mapping" module is shown in Figure 30.
	module: ietf-dots-mapping		module: ietf-dots-mapping
	augment /data-channel:dots-data/data-channel:dots-client:		augment /data-channel:dots-data/data-channel:dots-client:
	+--rw vendor-mapping {dots-telemetry}?		+--rw vendor-mapping {dots-telemetry}?
	+--rw vendor* [vendor-id]		+--rw vendor* [vendor-id]
	+--rw vendor-id uint32		+--rw vendor-id uint32
	+--rw vendor-name? string		+--rw vendor-name? string
			+--rw description-lang? string
	+--rw last-updated uint64		+--rw last-updated uint64
	+--rw attack-mapping* [attack-id]		+--rw attack-mapping* [attack-id]
	+--rw attack-id uint32		+--rw attack-id uint32
	+--rw attack-description string		+--rw attack-description string
	augment /data-channel:dots-data/data-channel:capabilities:		augment /data-channel:dots-data/data-channel:capabilities:
	+--ro vendor-mapping-enabled? boolean {dots-telemetry}?		+--ro vendor-mapping-enabled? boolean {dots-telemetry}?
	augment /data-channel:dots-data:		augment /data-channel:dots-data:
	+--ro vendor-mapping {dots-telemetry}?		+--ro vendor-mapping {dots-telemetry}?
	+--ro vendor* [vendor-id]		+--ro vendor* [vendor-id]
	+--ro vendor-id uint32		+--ro vendor-id uint32
	+--ro vendor-name? string		+--ro vendor-name? string
			+--ro description-lang? string
	+--ro last-updated uint64		+--ro last-updated uint64
	+--ro attack-mapping* [attack-id]		+--ro attack-mapping* [attack-id]
	+--ro attack-id uint32		+--ro attack-id uint32
	+--ro attack-description string		+--ro attack-description string
	Figure 30: Vendor Attack Mapping Tree Structure		Figure 30: Vendor Attack Mapping Tree Structure
	A DOTS client sends a GET request to retrieve the capabilities		A DOTS client sends a GET request over the DOTS data channel to
	supported by a DOTS server as per Section 7.1 of [RFC8783]. This		retrieve the capabilities supported by a DOTS server as per
	request is meant to assess whether the capability of sharing vendor		Section 7.1 of [RFC8783]. This request is meant to assess whether
	attack mapping details is supported by the server (i.e., check the		the capability of sharing vendor attack mapping details is supported
	value of 'vendor-mapping-enabled').		by the server (i.e., check the value of 'vendor-mapping-enabled').
	If 'vendor-mapping-enabled' is set to 'true', a DOTS client MAY send		If 'vendor-mapping-enabled' is set to 'true', a DOTS client MAY send
	a GET request to retrieve the DOTS server's vendor attack mapping		a GET request to retrieve the DOTS server's vendor attack mapping
	details. An example of such a GET request is shown in Figure 31.		details. An example of such a GET request is shown in Figure 31.
	GET /restconf/data/ietf-dots-data-channel:dots-data\		GET /restconf/data/ietf-dots-data-channel:dots-data\
	/ietf-dots-mapping:vendor-mapping HTTP/1.1		/ietf-dots-mapping:vendor-mapping HTTP/1.1
	Host: example.com		Host: example.com
	Accept: application/yang-data+json		Accept: application/yang-data+json
	skipping to change at page 54, line 25 ¶		skipping to change at page 54, line 31 ¶
	{		{
	"vendor-id": 32473,		"vendor-id": 32473,
	"vendor-name": "mitigator-s",		"vendor-name": "mitigator-s",
	"last-updated": "1629898758",		"last-updated": "1629898758",
	"attack-mapping": []		"attack-mapping": []
	}		}
	]		]
	}		}
	}		}
	Figure 33: Response to a GET to Retrieve the Vendors List used by		Figure 33: Response Message Body to a GET to Retrieve the Vendors
	a DOTS Server		List used by a DOTS Server
	The DOTS client repeats the above procedure regularly (e.g., once a		The DOTS client repeats the above procedure regularly (e.g., once a
	week) to update the DOTS server's vendor attack mapping details.		week) to update the DOTS server's vendor attack mapping details.
	If the DOTS client concludes that the DOTS server does not have any		If the DOTS client concludes that the DOTS server does not have any
	reference to the specific vendor attack mapping details, the DOTS		reference to the specific vendor attack mapping details, the DOTS
	client uses a POST request to install its vendor attack mapping		client uses a POST request to install its vendor attack mapping
	details. An example of such a POST request is depicted in Figure 34.		details. An example of such a POST request is depicted in Figure 34.
	POST /restconf/data/ietf-dots-data-channel:dots-data\		POST /restconf/data/ietf-dots-data-channel:dots-data\
	skipping to change at page 57, line 51 ¶		skipping to change at page 57, line 51 ¶
	Figure 36: PUT to Send Pre-or-Ongoing-Mitigation Telemetry		Figure 36: PUT to Send Pre-or-Ongoing-Mitigation Telemetry
	'cuid' is a mandatory Uri-Path parameter for DOTS PUT requests.		'cuid' is a mandatory Uri-Path parameter for DOTS PUT requests.
	The following additional Uri-Path parameter is defined:		The following additional Uri-Path parameter is defined:
	tmid: Telemetry Identifier is an identifier for the DOTS pre-or-		tmid: Telemetry Identifier is an identifier for the DOTS pre-or-
	ongoing-mitigation telemetry data represented as an integer.		ongoing-mitigation telemetry data represented as an integer.
	This identifier MUST be generated by DOTS clients. 'tmid' values		This identifier MUST be generated by DOTS clients. 'tmid' values
	MUST increase monotonically (when a new PUT is generated by a		MUST increase monotonically whenever a DOTS client needs to
	DOTS client to convey pre-or-ongoing-mitigation telemetry).		convey new set of pre-or-ongoing-mitigation telemetry.
	The procedure specified in Section 4.4.1 of [RFC9132] for 'mid'		The procedure specified in Section 4.4.1 of [RFC9132] for 'mid'
	rollover MUST be followed for 'tmid' rollover.		rollover MUST be followed for 'tmid' rollover.
	This is a mandatory attribute. 'tmid' MUST follow 'cuid'.		This is a mandatory attribute. 'tmid' MUST appear after 'cuid'
			in the Uri-Path options.
	'cuid' and 'tmid' MUST NOT appear in the PUT request message body.		'cuid' and 'tmid' MUST NOT appear in the PUT request message body.
	At least the 'target' attribute and another pre-or-ongoing-mitigation		At least the 'target' attribute and another pre-or-ongoing-mitigation
	attribute (Section 8.1) MUST be present in the PUT request. If only		attribute (Section 8.1) MUST be present in the PUT request. If only
	the 'target' attribute is present, this request is handled as per		the 'target' attribute is present, this request is handled as per
	Section 8.3.		Section 8.3.
	The relative order of two PUT requests carrying DOTS pre-or-ongoing-		The relative order of two PUT requests carrying DOTS pre-or-ongoing-
	mitigation telemetry from a DOTS client is determined by comparing		mitigation telemetry from a DOTS client is determined by comparing
	skipping to change at page 72, line 32 ¶		skipping to change at page 72, line 32 ¶
	<mailto:kondtir@gmail.com>";		<mailto:kondtir@gmail.com>";
	description		description
	"This module contains YANG definitions for the signaling		"This module contains YANG definitions for the signaling
	of DOTS telemetry data exchanged between a DOTS client and		of DOTS telemetry data exchanged between a DOTS client and
	a DOTS server by means of the DOTS signal channel.		a DOTS server by means of the DOTS signal channel.
	Copyright (c) 2022 IETF Trust and the persons identified as		Copyright (c) 2022 IETF Trust and the persons identified as
	authors of the code. All rights reserved.		authors of the code. All rights reserved.
	Redistribution and use in source and binary forms, with or		Redistribution and use in source and binary forms, with or
	without modification, is permitted pursuant to, and subject		without modification, is permitted pursuant to, and subject to
	to the license terms contained in, the Simplified BSD License		the license terms contained in, the Revised BSD License set
	set forth in Section 4.c of the IETF Trust's Legal Provisions		forth in Section 4.c of the IETF Trust's Legal Provisions
	Relating to IETF Documents		Relating to IETF Documents
	(https://trustee.ietf.org/license-info).		(https://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 2021-11-29 {		revision 2021-11-29 {
	description		description
	"Initial revision.";		"Initial revision.";
	reference		reference
	skipping to change at page 73, line 21 ¶		skipping to change at page 73, line 21 ¶
	}		}
	enum medium {		enum medium {
	value 3;		value 3;
	description		description
	"A subset of DOTS client domain resources are		"A subset of DOTS client domain resources are
	out of service.";		out of service.";
	}		}
	enum high {		enum high {
	value 4;		value 4;
	description		description
	"The DOTS client domain is under extremly severe		"The DOTS client domain is under extremely severe
	conditions.";		conditions.";
	}		}
	enum unknown {		enum unknown {
	value 5;		value 5;
	description		description
	"The impact of the attack is not known.";		"The impact of the attack is not known.";
	}		}
	}		}
	description		description
	"Enumeration for attack severity.";		"Enumeration for attack severity.";
	skipping to change at page 89, line 21 ¶		skipping to change at page 89, line 21 ¶
	"Vendor ID is a security vendor's Private Enterprise Number		"Vendor ID is a security vendor's Private Enterprise Number
	as registered with IANA.";		as registered with IANA.";
	reference		reference
	"IANA: Private Enterprise Numbers";		"IANA: Private Enterprise Numbers";
	}		}
	leaf attack-id {		leaf attack-id {
	type uint32;		type uint32;
	description		description
	"Unique identifier assigned by the vendor for the attack.";		"Unique identifier assigned by the vendor for the attack.";
	}		}
			leaf description-lang {
			type string {
			pattern '^(([A-Za-z]{2,3}(-[A-Za-z]{3}(-[A-Za-z]{3})'
			+ '{,2})?|[A-Za-z]{4}|[A-Za-z]{5,8})(-[A-Za-z]{4})?'
			+ '(-([A-Za-z]{2}|[0-9]{3}))?(-([A-Za-z0-9]{5,8}'
			+ '|([0-9][A-Za-z0-9]{3})))*(-[0-9A-WY-Za-wy-z]'
			+ '(-([A-Za-z0-9]{2,8}))+)*(-[Xx](-([A-Za-z0-9]'
			+ '{1,8}))+)?|[Xx](-([A-Za-z0-9]{1,8}))+|'
			+ '(([Ee][Nn]-[Gg][Bb]-[Oo][Ee][Dd]|[Ii]-'
			+ '[Aa][Mm][Ii]|[Ii]-[Bb][Nn][Nn]|[Ii]-'
			+ '[Dd][Ee][Ff][Aa][Uu][Ll][Tt]|[Ii]-'
			+ '[Ee][Nn][Oo][Cc][Hh][Ii][Aa][Nn]'
			+ '|[Ii]-[Hh][Aa][Kk]|'
			+ '[Ii]-[Kk][Ll][Ii][Nn][Gg][Oo][Nn]|'
			+ '[Ii]-[Ll][Uu][Xx]|[Ii]-[Mm][Ii][Nn][Gg][Oo]|'
			+ '[Ii]-[Nn][Aa][Vv][Aa][Jj][Oo]|[Ii]-[Pp][Ww][Nn]|'
			+ '[Ii]-[Tt][Aa][Oo]|[Ii]-[Tt][Aa][Yy]|'
			+ '[Ii]-[Tt][Ss][Uu]|[Ss][Gg][Nn]-[Bb][Ee]-[Ff][Rr]|'
			+ '[Ss][Gg][Nn]-[Bb][Ee]-[Nn][Ll]|[Ss][Gg][Nn]-'
			+ '[Cc][Hh]-[Dd][Ee])|([Aa][Rr][Tt]-'
			+ '[Ll][Oo][Jj][Bb][Aa][Nn]|[Cc][Ee][Ll]-'
			+ '[Gg][Aa][Uu][Ll][Ii][Ss][Hh]|'
			+ '[Nn][Oo]-[Bb][Oo][Kk]|[Nn][Oo]-'
			+ '[Nn][Yy][Nn]|[Zz][Hh]-[Gg][Uu][Oo][Yy][Uu]|'
			+ '[Zz][Hh]-[Hh][Aa][Kk][Kk][Aa]|[Zz][Hh]-'
			+ '[Mm][Ii][Nn]|[Zz][Hh]-[Mm][Ii][Nn]-'
			+ '[Nn][Aa][Nn]|[Zz][Hh]-[Xx][Ii][Aa][Nn][Gg])))$';
			}
			description
			"Indicates the language tag that is used for
			'attack-description'.";
			reference
			"RFC 5646: Tags for Identifying Languages, Section 2.1";
			}
	leaf attack-description {		leaf attack-description {
	type string;		type string;
	description		description
	"Textual representation of attack description. Natural		"Textual representation of attack description. Natural
	Language Processing techniques (e.g., word embedding)		Language Processing techniques (e.g., word embedding)
	might provide some utility in mapping the attack		might provide some utility in mapping the attack
	description to an attack type.";		description to an attack type.";
	}		}
	leaf attack-severity {		leaf attack-severity {
	type attack-severity;		type attack-severity;
	skipping to change at page 101, line 23 ¶		skipping to change at page 102, line 9 ¶
	<mailto:supjps-ietf@jpshallow.com>";		<mailto:supjps-ietf@jpshallow.com>";
	description		description
	"This module contains YANG definitions for the sharing		"This module contains YANG definitions for the sharing
	DDoS attack mapping details between a DOTS client and		DDoS attack mapping details between a DOTS client and
	a DOTS server, by means of the DOTS data channel.		a DOTS server, by means of the DOTS data channel.
	Copyright (c) 2022 IETF Trust and the persons identified as		Copyright (c) 2022 IETF Trust and the persons identified as
	authors of the code. All rights reserved.		authors of the code. All rights reserved.
	Redistribution and use in source and binary forms, with or		Redistribution and use in source and binary forms, with or
	without modification, is permitted pursuant to, and subject		without modification, is permitted pursuant to, and subject to
	to the license terms contained in, the Simplified BSD License		the license terms contained in, the Revised BSD License set
	set forth in Section 4.c of the IETF Trust's Legal Provisions		forth in Section 4.c of the IETF Trust's Legal Provisions
	Relating to IETF Documents		Relating to IETF Documents
	(https://trustee.ietf.org/license-info).		(https://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-06-26 {		revision 2020-06-26 {
	description		description
	"Initial revision.";		"Initial revision.";
	reference		reference
	skipping to change at page 102, line 19 ¶		skipping to change at page 103, line 4 ¶
	"Vendor ID is a security vendor's Private Enterprise Number		"Vendor ID is a security vendor's Private Enterprise Number
	as registered with IANA.";		as registered with IANA.";
	reference		reference
	"IANA: Private Enterprise Numbers";		"IANA: Private Enterprise Numbers";
	}		}
	leaf vendor-name {		leaf vendor-name {
	type string;		type string;
	description		description
	"The name of the vendor (e.g., company A).";		"The name of the vendor (e.g., company A).";
	}		}
			leaf description-lang {
			type string {
			pattern '^(([A-Za-z]{2,3}(-[A-Za-z]{3}(-[A-Za-z]{3})'
			+ '{,2})?|[A-Za-z]{4}|[A-Za-z]{5,8})(-[A-Za-z]{4})?'
			+ '(-([A-Za-z]{2}|[0-9]{3}))?(-([A-Za-z0-9]{5,8}'
			+ '|([0-9][A-Za-z0-9]{3})))*(-[0-9A-WY-Za-wy-z]'
			+ '(-([A-Za-z0-9]{2,8}))+)*(-[Xx](-([A-Za-z0-9]'
			+ '{1,8}))+)?|[Xx](-([A-Za-z0-9]{1,8}))+|'
			+ '(([Ee][Nn]-[Gg][Bb]-[Oo][Ee][Dd]|[Ii]-'
			+ '[Aa][Mm][Ii]|[Ii]-[Bb][Nn][Nn]|[Ii]-'
			+ '[Dd][Ee][Ff][Aa][Uu][Ll][Tt]|[Ii]-'
			+ '[Ee][Nn][Oo][Cc][Hh][Ii][Aa][Nn]'
			+ '|[Ii]-[Hh][Aa][Kk]|'
			+ '[Ii]-[Kk][Ll][Ii][Nn][Gg][Oo][Nn]|'
			+ '[Ii]-[Ll][Uu][Xx]|[Ii]-[Mm][Ii][Nn][Gg][Oo]|'
			+ '[Ii]-[Nn][Aa][Vv][Aa][Jj][Oo]|[Ii]-[Pp][Ww][Nn]|'
			+ '[Ii]-[Tt][Aa][Oo]|[Ii]-[Tt][Aa][Yy]|'
			+ '[Ii]-[Tt][Ss][Uu]|[Ss][Gg][Nn]-[Bb][Ee]-[Ff][Rr]|'
			+ '[Ss][Gg][Nn]-[Bb][Ee]-[Nn][Ll]|[Ss][Gg][Nn]-'
			+ '[Cc][Hh]-[Dd][Ee])|([Aa][Rr][Tt]-'
			+ '[Ll][Oo][Jj][Bb][Aa][Nn]|[Cc][Ee][Ll]-'
			+ '[Gg][Aa][Uu][Ll][Ii][Ss][Hh]|'
			+ '[Nn][Oo]-[Bb][Oo][Kk]|[Nn][Oo]-'
			+ '[Nn][Yy][Nn]|[Zz][Hh]-[Gg][Uu][Oo][Yy][Uu]|'
			+ '[Zz][Hh]-[Hh][Aa][Kk][Kk][Aa]|[Zz][Hh]-'
			+ '[Mm][Ii][Nn]|[Zz][Hh]-[Mm][Ii][Nn]-'
			+ '[Nn][Aa][Nn]|[Zz][Hh]-[Xx][Ii][Aa][Nn][Gg])))$';
			}
			description
			"Indicates the language tag that is used for
			'attack-description'.";
			reference
			"RFC 5646: Tags for Identifying Languages, Section 2.1";
			}
	leaf last-updated {		leaf last-updated {
	type uint64;		type uint64;
	mandatory true;		mandatory true;
	description		description
	"The time the mapping table was updated. It is represented		"The time the mapping table was updated. It is represented
	in seconds relative to 1970-01-01T00:00:00Z.";		in seconds relative to 1970-01-01T00:00:00Z.";
	}		}
	list attack-mapping {		list attack-mapping {
	key "attack-id";		key "attack-id";
	description		description
	skipping to change at page 106, line 30 ¶		skipping to change at page 107, line 47 ¶
	| ietf-dots-telemetry: | | | | |		| ietf-dots-telemetry: | | | | |
	| total-attack-traffic | list |TBA80 | 4 array | Array |		| total-attack-traffic | list |TBA80 | 4 array | Array |
	| ietf-dots-telemetry: | | | | |		| ietf-dots-telemetry: | | | | |
	| total-attack- | | | | |		| total-attack- | | | | |
	| connection | container |TBA81 | 5 map | Object |		| connection | container |TBA81 | 5 map | Object |
	| ietf-dots-telemetry: | | | | |		| ietf-dots-telemetry: | | | | |
	| attack-detail | list |TBA82 | 4 array | Array |		| attack-detail | list |TBA82 | 4 array | Array |
	| ietf-dots-telemetry: | | | | |		| ietf-dots-telemetry: | | | | |
	| telemetry | container |TBA83 | 5 map | Object |		| telemetry | container |TBA83 | 5 map | Object |
	| current-g | yang:gauge64|TBA84 | 0 unsigned | String |		| current-g | yang:gauge64|TBA84 | 0 unsigned | String |
			| description-lang | string |TBA85 | 3 text string | String |
	| lower-type | uint8 |32771 | 0 unsigned | Number |		| lower-type | uint8 |32771 | 0 unsigned | Number |
	| upper-type | uint8 |32772 | 0 unsigned | Number |		| upper-type | uint8 |32772 | 0 unsigned | Number |
	+----------------------+-------------+------+---------------+--------+		+----------------------+-------------+------+---------------+--------+
	Table 3: YANG/JSON Mapping Parameters to CBOR		Table 3: YANG/JSON Mapping Parameters to CBOR
	13. IANA Considerations		13. IANA Considerations
	13.1. DOTS Signal Channel CBOR Key Values		13.1. DOTS Signal Channel CBOR Key Values
	This specification registers the DOTS telemetry attributes in the		This specification registers the DOTS telemetry attributes in the
	IANA "DOTS Signal Channel CBOR Key Values" registry [Key-Map].		IANA "DOTS Signal Channel CBOR Key Values" registry [Key-Map].
	The DOTS telemetry attributes defined in this specification are		The DOTS telemetry attributes defined in this specification are
	skipping to change at page 109, line 17 ¶		skipping to change at page 110, line 36 ¶
	| ietf-dots-telemetry: | TBA80 | 4 | IESG | [RFCXXXX] |		| ietf-dots-telemetry: | TBA80 | 4 | IESG | [RFCXXXX] |
	| total-attack-traffic | | | | |		| total-attack-traffic | | | | |
	| ietf-dots-telemetry: | TBA81 | 5 | IESG | [RFCXXXX] |		| ietf-dots-telemetry: | TBA81 | 5 | IESG | [RFCXXXX] |
	| total-attack- | | | | |		| total-attack- | | | | |
	| connection | | | | |		| connection | | | | |
	| ietf-dots-telemetry: | TBA82 | 4 | IESG | [RFCXXXX] |		| ietf-dots-telemetry: | TBA82 | 4 | IESG | [RFCXXXX] |
	| attack-detail | | | | |		| attack-detail | | | | |
	| ietf-dots-telemetry: | TBA83 | 5 | IESG | [RFCXXXX] |		| ietf-dots-telemetry: | TBA83 | 5 | IESG | [RFCXXXX] |
	| telemetry | | | | |		| telemetry | | | | |
	| current-g | TBA84 | 0 | IESG | [RFCXXXX] |		| current-g | TBA84 | 0 | IESG | [RFCXXXX] |
			| description-lang | TBA85 | 3 | IESG | [RFCXXXX] |
	+----------------------+-------+-------+------------+---------------+		+----------------------+-------+-------+------------+---------------+
	Table 4: Registered DOTS Signal Channel CBOR Key Values		Table 4: Registered DOTS Signal Channel CBOR Key Values
	13.2. DOTS Signal Channel Conflict Cause Codes		13.2. DOTS Signal Channel Conflict Cause Codes
	This specification requests IANA to assign a new code from the "DOTS		This specification requests IANA to assign a new code from the "DOTS
	Signal Channel Conflict Cause Codes" registry [Cause].		Signal Channel Conflict Cause Codes" registry [Cause].
	+------+-------------------+------------------------+-------------+		+------+-------------------+------------------------+-------------+
	skipping to change at page 112, line 46 ¶		skipping to change at page 114, line 32 ¶
	Special thanks to Jon Shallow and Kaname Nishizuka for their		Special thanks to Jon Shallow and Kaname Nishizuka for their
	implementation and interoperability work.		implementation and interoperability work.
	Many thanks to Jan Lindblad for the yangdoctors review, Nagendra		Many thanks to Jan Lindblad for the yangdoctors review, Nagendra
	Nainar for the opsdir review, James Gruessing for the artart review,		Nainar for the opsdir review, James Gruessing for the artart review,
	Michael Scharf for the tsv-art review, Ted Lemon for the int-dir		Michael Scharf for the tsv-art review, Ted Lemon for the int-dir
	review, and Robert Sparks for the gen-art review.		review, and Robert Sparks for the gen-art review.
	Thanks to Benjamin Kaduk for the detailed AD review.		Thanks to Benjamin Kaduk for the detailed AD review.
			Thanks to Roman Danyliw, Eric Vyncke, Francesca Palombini, Warren
			Kumari, and Erik Kline for the IESG review.
	17. References		17. References
	17.1. Normative References		17.1. Normative References
	[Private-Enterprise-Numbers]		[Private-Enterprise-Numbers]
	"Private Enterprise Numbers", 4 May 2020,		"Private Enterprise Numbers", 4 May 2020,
	<https://www.iana.org/assignments/enterprise-numbers>.		<https://www.iana.org/assignments/enterprise-numbers>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,		[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
	DOI 10.17487/RFC3688, January 2004,		DOI 10.17487/RFC3688, January 2004,
	<https://www.rfc-editor.org/info/rfc3688>.		<https://www.rfc-editor.org/info/rfc3688>.
			[RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying
			Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646,
			September 2009, <https://www.rfc-editor.org/info/rfc5646>.
	[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for		[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
	the Network Configuration Protocol (NETCONF)", RFC 6020,		the Network Configuration Protocol (NETCONF)", RFC 6020,
	DOI 10.17487/RFC6020, October 2010,		DOI 10.17487/RFC6020, October 2010,
	<https://www.rfc-editor.org/info/rfc6020>.		<https://www.rfc-editor.org/info/rfc6020>.
	[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",		[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
	RFC 6991, DOI 10.17487/RFC6991, July 2013,		RFC 6991, DOI 10.17487/RFC6991, July 2013,
	<https://www.rfc-editor.org/info/rfc6991>.		<https://www.rfc-editor.org/info/rfc6991>.
	[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained		[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
End of changes. 39 change blocks.
	75 lines changed or deleted		179 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/