< draft-ietf-ippm-twamp-yang-07.txt		draft-ietf-ippm-twamp-yang-08.txt >
	IPPM WG R. Civil		IPPM WG R. Civil
	Internet-Draft Ciena Corporation		Internet-Draft Ciena Corporation
	Intended status: Standards Track A. Morton		Intended status: Standards Track A. Morton
	Expires: October 10, 2018 AT&T Labs		Expires: October 16, 2018 AT&T Labs
	R. Rahman		R. Rahman
	Cisco Systems		Cisco Systems
	M. Jethanandani		M. Jethanandani
	K. Pentikousis, Ed.		K. Pentikousis, Ed.
	Travelping		Travelping
	April 8, 2018		April 14, 2018
	Two-Way Active Measurement Protocol (TWAMP) Data Model		Two-Way Active Measurement Protocol (TWAMP) Data Model
	draft-ietf-ippm-twamp-yang-07		draft-ietf-ippm-twamp-yang-08
	Abstract		Abstract
	This document specifies a data model for client and server		This document specifies a data model for client and server
	implementations of the Two-Way Active Measurement Protocol (TWAMP).		implementations of the Two-Way Active Measurement Protocol (TWAMP).
	We define the TWAMP data model through Unified Modeling Language		We define the TWAMP data model through Unified Modeling Language
	(UML) class diagrams and formally specify it using YANG.		(UML) class diagrams and formally specify it using YANG.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 40 ¶		skipping to change at page 1, line 40 ¶
	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 October 10, 2018.		This Internet-Draft will expire on October 16, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3		1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3
	1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3		1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
	1.3. Document Organization . . . . . . . . . . . . . . . . . . 4		1.3. Document Organization . . . . . . . . . . . . . . . . . . 4
	2. Scope, Model, and Applicability . . . . . . . . . . . . . . . 4		2. Scope, Model, and Applicability . . . . . . . . . . . . . . . 4
	3. Data Model Overview . . . . . . . . . . . . . . . . . . . . . 5		3. Data Model Overview . . . . . . . . . . . . . . . . . . . . . 5
	3.1. Control-Client . . . . . . . . . . . . . . . . . . . . . 6		3.1. Control-Client . . . . . . . . . . . . . . . . . . . . . 6
	3.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 7		3.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 7
	3.3. Session-Sender . . . . . . . . . . . . . . . . . . . . . 7		3.3. Session-Sender . . . . . . . . . . . . . . . . . . . . . 7
	3.4. Session-Reflector . . . . . . . . . . . . . . . . . . . . 7		3.4. Session-Reflector . . . . . . . . . . . . . . . . . . . . 8
	4. Data Model Parameters . . . . . . . . . . . . . . . . . . . . 8		4. Data Model Parameters . . . . . . . . . . . . . . . . . . . . 8
	4.1. Control-Client . . . . . . . . . . . . . . . . . . . . . 8		4.1. Control-Client . . . . . . . . . . . . . . . . . . . . . 8
	4.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 11		4.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 11
	4.3. Session-Sender . . . . . . . . . . . . . . . . . . . . . 12		4.3. Session-Sender . . . . . . . . . . . . . . . . . . . . . 13
	4.4. Session-Reflector . . . . . . . . . . . . . . . . . . . . 13		4.4. Session-Reflector . . . . . . . . . . . . . . . . . . . . 14
	5. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 15		5. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 16
	5.1. YANG Tree Diagram . . . . . . . . . . . . . . . . . . . . 15		5.1. YANG Tree Diagram . . . . . . . . . . . . . . . . . . . . 16
	5.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 18		5.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 19
	6. Data Model Examples . . . . . . . . . . . . . . . . . . . . . 46		6. Data Model Examples . . . . . . . . . . . . . . . . . . . . . 48
	6.1. Control-Client . . . . . . . . . . . . . . . . . . . . . 47		6.1. Control-Client . . . . . . . . . . . . . . . . . . . . . 48
	6.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 49		6.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 50
	6.3. Session-Sender . . . . . . . . . . . . . . . . . . . . . 50		6.3. Session-Sender . . . . . . . . . . . . . . . . . . . . . 51
	6.4. Session-Reflector . . . . . . . . . . . . . . . . . . . . 51		6.4. Session-Reflector . . . . . . . . . . . . . . . . . . . . 52
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 54		7. Security Considerations . . . . . . . . . . . . . . . . . . . 55
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 55		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 56
	10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 55		10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 56
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 55		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 57
	11.1. Normative References . . . . . . . . . . . . . . . . . . 55		11.1. Normative References . . . . . . . . . . . . . . . . . . 57
	11.2. Informative References . . . . . . . . . . . . . . . . . 57		11.2. Informative References . . . . . . . . . . . . . . . . . 58
	Appendix A. Detailed Data Model Examples . . . . . . . . . . . . 58		Appendix A. Detailed Data Model Examples . . . . . . . . . . . . 60
	A.1. Control-Client . . . . . . . . . . . . . . . . . . . . . 58		A.1. Control-Client . . . . . . . . . . . . . . . . . . . . . 60
	A.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 60		A.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 62
	A.3. Session-Sender . . . . . . . . . . . . . . . . . . . . . 62		A.3. Session-Sender . . . . . . . . . . . . . . . . . . . . . 63
	A.4. Session-Reflector . . . . . . . . . . . . . . . . . . . . 62		A.4. Session-Reflector . . . . . . . . . . . . . . . . . . . . 64
	Appendix B. TWAMP Operational Commands . . . . . . . . . . . . . 65		Appendix B. TWAMP Operational Commands . . . . . . . . . . . . . 67
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 65		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 67
	1. Introduction		1. Introduction
	The Two-Way Active Measurement Protocol (TWAMP) [RFC5357] is used to		The Two-Way Active Measurement Protocol (TWAMP) [RFC5357] is used to
	measure network performance parameters such as latency, bandwidth,		measure network performance parameters such as latency, bandwidth,
	and packet loss by sending probe packets and measuring their		and packet loss by sending probe packets and measuring their
	experience in the network. To date, TWAMP implementations do not		experience in the network. To date, TWAMP implementations do not
	come with a standard management framework, and, as such, implementors		come with a standard management framework, and, as such, implementors
	have no choice except to provide a proprietary mechanism. This		have no choice except to provide a proprietary mechanism. This
	document addresses this gap by formally specifying the TWAMP data		document addresses this gap by formally specifying the TWAMP data
	model using YANG.		model using YANG [RFC7950].
	1.1. Motivation		1.1. Motivation
	In current TWAMP deployments the lack of a standardized data model		In current TWAMP deployments the lack of a standardized data model
	limits the flexibility to dynamically instantiate TWAMP-based		limits the flexibility to dynamically instantiate TWAMP-based
	measurements across equipment from different vendors. In large,		measurements across equipment from different vendors. In large,
	virtualized, and dynamically instantiated infrastructures where		virtualized, and dynamically instantiated infrastructures where
	network functions are placed according to orchestration algorithms as		network functions are placed according to orchestration algorithms as
	discussed in [I-D.unify-nfvrg-challenges][I-D.unify-nfvrg-devops],		discussed in Unifying Carrier and Cloud Networks: Problem Statement
	proprietary mechanisms for managing TWAMP measurements pose severe		and Challenges [I-D.unify-nfvrg-challenges]DevOps For Software-
	limitations with respect to programmability.		Defined Telecom Infrastructures [I-D.unify-nfvrg-devops], proprietary
			mechanisms for managing TWAMP measurements pose severe limitations
			with respect to programmability.
	Two major trends call for standardizing TWAMP management aspects.		Two major trends call for standardizing TWAMP management aspects.
	First, we expect that in the coming years large-scale and multi-		First, we expect that in the coming years large-scale and multi-
	vendor TWAMP deployments will become the norm. From an operations		vendor TWAMP deployments will become the norm. From an operations
	perspective, using several vendor-specific TWAMP configuration		perspective, using several vendor-specific TWAMP configuration
	mechanisms when one standard mechanism could provide an alternative		mechanisms when one standard mechanism could provide an alternative
	is expensive and inefficient. Second, the increasingly software-		is expensive and inefficient. Second, the increasingly software-
	defined and virtualized nature of network infrastructures, based on		defined and virtualized nature of network infrastructures, based on
	dynamic service chains [NSC] and programmable control and management		dynamic service chains [NSC] and programmable control and management
	planes [RFC7426] requires a well-defined data model for TWAMP		planes Software-Defined Networking (SDN): Layers and Architecture
			Terminology [RFC7426] requires a well-defined data model for TWAMP
	implementations. This document defines such a TWAMP data model and		implementations. This document defines such a TWAMP data model and
	specifies it formally using the YANG data modeling language		specifies it formally using the YANG [RFC7950] data modeling
	[RFC7950].		language.
	Note to RFC Editor:		Note to RFC Editor:
	Please replace the date 2018-04-08 in Section 5.2 of the draft with		Please replace the date 2018-04-16 in Section 5.2 of the draft with
	the date of publication of this draft as a RFC. Also, replace		the date of publication of this draft as a RFC. Also, replace
	reference to RFC XXXX, and draft-ietf-ippm-metric-registry with the		reference to RFC XXXX, and draft-ietf-port-twamp-test with the RFC
	RFC numbers assigned to the draft.		numbers assigned to the drafts.
	1.2. Terminology		1.2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	1.3. Document Organization		1.3. Document Organization
	skipping to change at page 4, line 23 ¶		skipping to change at page 4, line 29 ¶
	specifies in YANG the TWAMP data model. Section 6 lists illustrative		specifies in YANG the TWAMP data model. Section 6 lists illustrative
	examples which conform to the YANG data model specified in this		examples which conform to the YANG data model specified in this
	document. Appendix A elaborates these examples further.		document. Appendix A elaborates these examples further.
	2. Scope, Model, and Applicability		2. Scope, Model, and Applicability
	The purpose of this document is the specification of a vendor-		The purpose of this document is the specification of a vendor-
	independent data model for TWAMP implementations.		independent data model for TWAMP implementations.
	Figure 1 illustrates a redrawn version of the TWAMP logical model		Figure 1 illustrates a redrawn version of the TWAMP logical model
	found in Section 1.2 of [RFC5357]. The figure is annotated with		found in Section 1.2 of TWAMP [RFC5357]. The figure is annotated
	pointers to the UML diagrams provided in this document and associated		with pointers to the UML diagrams provided in this document and
	with the data model of the four logical entities in a TWAMP		associated with the data model of the four logical entities in a
	deployment, namely the TWAMP Control-Client, Server, Session-Sender		TWAMP deployment, namely the TWAMP Control-Client, Server, Session-
	and Session-Reflector.		Sender and Session-Reflector.
	As per [RFC5357], unlabeled links in Figure 1 are left unspecified		As per TWAMP [RFC5357], unlabeled links in Figure 1 are left
	and may be proprietary protocols.		unspecified and may be proprietary protocols.
	[Fig. 3] [Fig. 4]		[Fig. 3] [Fig. 4]
	+----------------+ +--------+		+----------------+ +--------+
	| Control-Client | <-- TWAMP-Control --> | Server |		| Control-Client | <-- TWAMP-Control --> | Server |
	+----------------+ +--------+		+----------------+ +--------+
	^ ^		^ ^
	| |		| |
	V V		V V
	+----------------+ +-------------------+		+----------------+ +-------------------+
	| Session-Sender | <-- TWAMP-Test --> | Session-Reflector |		| Session-Sender | <-- TWAMP-Test --> | Session-Reflector |
	+----------------+ +-------------------+		+----------------+ +-------------------+
	[Fig. 5] [Fig. 6]		[Fig. 5] [Fig. 6]
	Figure 1: Annotated TWAMP logical model		Figure 1: Annotated TWAMP logical model
	As per [RFC5357], a TWAMP implementation may follow a simplified		As per TWAMP [RFC5357], a TWAMP implementation may follow a
	logical model, in which the same node acts both as Control-Client and		simplified logical model, in which the same node acts both as
	Session-Sender, while another node acts at the same time as TWAMP		Control-Client and Session-Sender, while another node acts at the
	Server and Session-Reflector. Figure 2 illustrates this simplified		same time as TWAMP Server and Session-Reflector. Figure 2
	logical model and indicates the interaction between the TWAMP		illustrates this simplified logical model and indicates the
	configuration client and server using, for instance, NETCONF		interaction between the TWAMP configuration client and server using,
	[RFC6241] or RESTCONF [RFC8040].		for instance, NETCONF [RFC6241] or RESTCONF [RFC8040].
	o-------------------o o-------------------o		o-------------------o o-------------------o
	| Config client | | Config client |		| Config client | | Config client |
	o-------------------o o-------------------o		o-------------------o o-------------------o
	|| ||		|| ||
	NETCONF || RESTCONF NETCONF || RESTCONF		NETCONF || RESTCONF NETCONF || RESTCONF
	|| ||		|| ||
	o-------------------o o-------------------o		o-------------------o o-------------------o
	| Config server | | Config server |		| Config server | | Config server |
	| [Fig. 3, 5] | | [Fig. 4, 6] |		| [Fig. 3, 5] | | [Fig. 4, 6] |
	skipping to change at page 5, line 32 ¶		skipping to change at page 5, line 38 ¶
	Figure 2: Simplified TWAMP model and protocols		Figure 2: Simplified TWAMP model and protocols
	The data model defined in this document is orthogonal to the specific		The data model defined in this document is orthogonal to the specific
	protocol used between the Config client and Config server to		protocol used between the Config client and Config server to
	communicate the TWAMP configuration parameters.		communicate the TWAMP configuration parameters.
	Operational actions such as how TWAMP-Test sessions are started and		Operational actions such as how TWAMP-Test sessions are started and
	stopped, how performance measurement results are retrieved, or how		stopped, how performance measurement results are retrieved, or how
	stored results are cleared, and so on, are not addressed by the		stored results are cleared, and so on, are not addressed by the
	configuration model defined in this document. As noted above, such		configuration model defined in this document. As noted above, such
	operational actions are not part of the TWAMP specification [RFC5357]		operational actions are not part of the TWAMP specification TWAMP
	and hence are out of scope of this document. See also Appendix B.		[RFC5357] and hence are out of scope of this document. See also
			Appendix B.
	3. Data Model Overview		3. Data Model Overview
	The TWAMP data model includes four categories of configuration items.		The TWAMP data model includes four categories of configuration items.
	First, global configuration items relate to parameters that are set		First, global configuration items relate to parameters that are set
	on a per device level. For example, the administrative status of the		on a per device level. For example, the administrative status of the
	device with respect to whether it allows TWAMP sessions and, if so,		device with respect to whether it allows TWAMP sessions and, if so,
	in what capacity (e.g. Control-Client, Server or both), is a typical		in what capacity (e.g. Control-Client, Server or both), is a typical
	instance of a global configuration item.		instance of a global configuration item.
	skipping to change at page 6, line 36 ¶		skipping to change at page 6, line 43 ¶
	information needed to uniquely identify the connection is		information needed to uniquely identify the connection is
	available.		available.
	o The IP address of the interface the Control-Client will use for		o The IP address of the interface the Control-Client will use for
	connections.		connections.
	o The IP address of the remote TWAMP Server.		o The IP address of the remote TWAMP Server.
	o Authentication and encryption attributes such as KeyID, Token and		o Authentication and encryption attributes such as KeyID, Token and
	the Client Initialization Vector (Client-IV); see also the last		the Client Initialization Vector (Client-IV); see also the last
	paragraph of Section 6 in [RFC4656] and [RFC4086].		paragraph of Section 6 in OWAMP [RFC4656] and Randomness
			Requirements for Security [RFC4086].
	Each TWAMP-Control connection, in turn, is associated with zero or		Each TWAMP-Control connection, in turn, is associated with zero or
	more TWAMP-Test sessions. For each test session we note the		more TWAMP-Test sessions. For each test session we note the
	following configuration items:		following configuration items:
	o The test session name that uniquely identifies a particular test		o The test session name that uniquely identifies a particular test
	session at the Control-Client and Session-Sender. Similarly to		session at the Control-Client and Session-Sender. Similarly to
	the control connections above, this unique test session name is		the control connections above, this unique test session name is
	needed because at the time of creation of a TWAMP-Test session,		needed because at the time of creation of a TWAMP-Test session,
	for example, the source UDP port number is not known to uniquely		for example, the source UDP port number is not known to uniquely
	identify the test session.		identify the test session.
	o The IP address and UDP port number of the Session-Sender on the		o The IP address and UDP port number of the Session-Sender on the
	path under test by TWAMP.		path under test by TWAMP.
	o The IP address and UDP port number of the Session-Reflector on		o The IP address and UDP port number of the Session-Reflector on
	said path.		said path.
	o Information pertaining to the test packet stream, such as the test		o Information pertaining to the test packet stream, such as the test
	starting time, which performance metric is to be used		starting time, which performance metric is to be used Registry for
	[I-D.ietf-ippm-metric-registry], or whether the test should be		Performance Metrics [I-D.ietf-ippm-metric-registry], or whether
	repeated.		the test should be repeated.
	3.2. Server		3.2. Server
	Each TWAMP Server has an administrative status field set at the		Each TWAMP Server has an administrative status field set at the
	device level to indicate whether the node is enabled to function as a		device level to indicate whether the node is enabled to function as a
	TWAMP Server.		TWAMP Server.
	Each Server is associated with zero or more TWAMP-Control		Each Server is associated with zero or more TWAMP-Control
	connections. Each control connection is uniquely identified by the		connections. Each control connection is uniquely identified by the
	4-tuple {Control-Client IP address, Control-Client TCP port number,		4-tuple {Control-Client IP address, Control-Client TCP port number,
	skipping to change at page 7, line 44 ¶		skipping to change at page 7, line 50 ¶
	o The test session name that MUST be identical with the		o The test session name that MUST be identical with the
	corresponding test session name on the TWAMP Control-Client		corresponding test session name on the TWAMP Control-Client
	(Section 3.1).		(Section 3.1).
	o The control connection name, which along with the test session		o The control connection name, which along with the test session
	name uniquely identify the TWAMP Session-Sender instance.		name uniquely identify the TWAMP Session-Sender instance.
	o Information pertaining to the test packet stream, such as, for		o Information pertaining to the test packet stream, such as, for
	example, the number of test packets and the packet distribution to		example, the number of test packets and the packet distribution to
	be employed; see also [RFC3432].		be employed; see also Network performence measurement with
			periodic streams [RFC3432].
	3.4. Session-Reflector		3.4. Session-Reflector
	Each TWAMP Session-Reflector has an administrative status field set		Each TWAMP Session-Reflector has an administrative status field set
	at the device level to indicate whether the node is enabled to		at the device level to indicate whether the node is enabled to
	function as such.		function as such.
	Each Session-Reflector is associated with zero or more TWAMP-Test		Each Session-Reflector is associated with zero or more TWAMP-Test
	sessions. For each test session, the REFWAIT timeout parameter which		sessions. For each test session, the REFWAIT timeout parameter which
	determines whether to discontinue the session if no packets have been		determines whether to discontinue the session if no packets have been
	received ([RFC5357], Section 4.2) can be configured.		received (TWAMP [RFC5357], Section 4.2) can be configured.
	Read-only access to other data model parameters, such as the Sender		Read-only access to other data model parameters, such as the Sender
	IP address is foreseen. Each test session can be uniquely identified		IP address is foreseen. Each test session can be uniquely identified
	by the 4-tuple mentioned in Section 3.2.		by the 4-tuple mentioned in Section 3.2.
	4. Data Model Parameters		4. Data Model Parameters
	This section defines the TWAMP data model using UML and introduces		This section defines the TWAMP data model using UML and introduces
	selected parameters associated with the four TWAMP logical entities.		selected parameters associated with the four TWAMP logical entities.
	The complete TWAMP data model specification is provided in the YANG		The complete TWAMP data model specification is provided in the YANG
	skipping to change at page 10, line 11 ¶		skipping to change at page 10, line 11 ¶
	mode and its corresponding priority, expressed as a 16-bit unsigned		mode and its corresponding priority, expressed as a 16-bit unsigned
	integer, where zero is the highest priority and subsequent values are		integer, where zero is the highest priority and subsequent values are
	monotonically increasing.		monotonically increasing.
	Depending on the Modes available in the Server Greeting, the Control-		Depending on the Modes available in the Server Greeting, the Control-
	Client MUST choose the highest priority Mode from the configured		Client MUST choose the highest priority Mode from the configured
	mode-preference-chain list.		mode-preference-chain list.
	Note that the list of preferred Modes may set bit position		Note that the list of preferred Modes may set bit position
	combinations when necessary, such as when referring to the extended		combinations when necessary, such as when referring to the extended
	TWAMP features in [RFC5618], [RFC5938], [RFC6038], and [RFC7717]. If		TWAMP features in Mixed Security Mode for TWAMP [RFC5618], Individual
	the Control-Client cannot determine an acceptable Mode, it MUST		Session Control Feature for TWAMP [RFC5938], TWAMP Reflect Octets and
	respond with zero Mode bits set in the Set-up Response message,		Symmetrical Size Features [RFC6038], and IKEv2-Derived Shared Secret
	indicating it will not continue with the control connection.		Key for OWAMP and TWAMP [RFC7717]. If the Control-Client cannot
			determine an acceptable Mode, it MUST respond with zero Mode bits set
			in the Set-up Response message, indicating it will not continue with
			the control connection.
	In addition, the client container holds a list named key-chain which		In addition, the client container holds a list named key-chain which
	relates KeyIDs with the respective secret keys. Both the Server and		relates KeyIDs with the respective secret keys. Both the Server and
	the Control-Client use the same mappings from KeyIDs to shared		the Control-Client use the same mappings from KeyIDs to shared
	secrets (key-id and secret-key in Figure 3, respectively). The		secrets (key-id and secret-key in Figure 3, respectively). The
	Server, being prepared to conduct sessions with more than one		Server, being prepared to conduct sessions with more than one
	Control-Client, uses KeyIDs to choose the appropriate secret-key; a		Control-Client, uses KeyIDs to choose the appropriate secret-key; a
	Control-Client would typically have different secret keys for		Control-Client would typically have different secret keys for
	different Servers. The secret-key is the shared secret, an octet		different Servers. The secret-key is the shared secret, an octet
	string of arbitrary length whose interpretation as a text string is		string of arbitrary length whose interpretation as a text string is
	unspecified. The key-id and secret-key encoding SHOULD follow		unspecified. The key-id and secret-key encoding SHOULD follow
	Section 9.4 of [RFC7950]. The derived key length (dkLen in		Section 9.4 of YANG [RFC7950]. The derived key length (dkLen in PKCS
	[RFC8018]) MUST be 16 octets for the AES Session-key used for		#5: Password-Based Cryptography Specification Version 2.1 [RFC8018])
	encryption and 32 octets for the HMAC-SHA1 Session-key used for		MUST be 16 octets for the AES Session-key used for encryption and 32
	authentication; see also Section 6.10 of [RFC4656].		octets for the HMAC-SHA1 Session-key used for authentication; see
			also Section 6.10 of OWAMP [RFC4656].
	Each client container also holds a list of control connections, where		Each client container also holds a list of control connections, where
	each item in the list describes a TWAMP control connection initiated		each item in the list describes a TWAMP control connection initiated
	by this Control-Client. There SHALL be one ctrl-connection per		by this Control-Client. There SHALL be one ctrl-connection per
	TWAMP-Control (TCP) connection that is to be initiated from this		TWAMP-Control (TCP) connection that is to be initiated from this
	device.		device.
	In turn, each ctrl-connection holds a list of test-session-request.		In turn, each ctrl-connection holds a list of test-session-request.
	test-session-request holds information associated with the Control-		test-session-request holds information associated with the Control-
	Client for this test session. This includes information associated		Client for this test session. This includes information associated
	with the Request-TW-Session/Accept-Session message exchange (see		with the Request-TW-Session/Accept-Session message exchange (see
	Section 3.5 of [RFC5357]).		Section 3.5 of TWAMP [RFC5357]).
	There SHALL be one instance of test-session-request for each TWAMP-		There SHALL be one instance of test-session-request for each TWAMP-
	Test session that is to be negotiated by this TWAMP-Control		Test session that is to be negotiated by this TWAMP-Control
	connection via a Request-TW-Session/Accept-Session exchange.		connection via a Request-TW-Session/Accept-Session exchange.
	The Control-Client is also responsible for scheduling TWAMP-Test		The Control-Client is also responsible for scheduling TWAMP-Test
	sessions so test-session-request holds information related to these		sessions so test-session-request holds information related to these
	actions (e.g. pm-index, repeat-interval).		actions (e.g. pm-index, repeat-interval).
	4.2. Server		4.2. Server
	skipping to change at page 15, line 5 ¶		skipping to change at page 15, line 43 ¶
	Figure 6: TWAMP Session-Reflector UML class diagram		Figure 6: TWAMP Session-Reflector UML class diagram
	Each incoming TWAMP-Test session that is active on the Session-		Each incoming TWAMP-Test session that is active on the Session-
	Reflector SHALL be represented by an instance of a test-session		Reflector SHALL be represented by an instance of a test-session
	object. All items in the test-session object are read-only.		object. All items in the test-session object are read-only.
	Instances of test-session are indexed by a session identifier (sid).		Instances of test-session are indexed by a session identifier (sid).
	This value is auto-allocated by the TWAMP Server as test session		This value is auto-allocated by the TWAMP Server as test session
	requests are received, and communicated back to the Control-Client in		requests are received, and communicated back to the Control-Client in
	the SID field of the Accept-Session message; see Section 4.3 of		the SID field of the Accept-Session message; see Section 4.3 of TWAMP
	[RFC6038].		Reflect Octets and Symmetrical Size Features [RFC6038].
	When attempting to retrieve operational data for active test sessions		When attempting to retrieve operational data for active test sessions
	from a Session-Reflector device, the user will not know what sessions		from a Session-Reflector device, the user will not know what sessions
	are currently active on that device, or what SIDs have been auto-		are currently active on that device, or what SIDs have been auto-
	allocated for these test sessions. If the user has network access to		allocated for these test sessions. If the user has network access to
	the Control-Client device, then it is possible to read the data for		the Control-Client device, then it is possible to read the data for
	this session under client/ctrl-connection/test-session-request/sid		this session under client/ctrl-connection/test-session-request/sid
	and obtain the SID (see Figure 3). The user may then use this SID		and obtain the SID (see Figure 3). The user may then use this SID
	value as an index to retrieve an individual session-reflector/test-		value as an index to retrieve an individual session-reflector/test-
	session instance on the Session-Reflector device.		session instance on the Session-Reflector device.
	skipping to change at page 15, line 42 ¶		skipping to change at page 16, line 31 ¶
	5. Data Model		5. Data Model
	This section formally specifies the TWAMP data model using YANG.		This section formally specifies the TWAMP data model using YANG.
	5.1. YANG Tree Diagram		5.1. YANG Tree Diagram
	This section presents a simplified graphical representation of the		This section presents a simplified graphical representation of the
	TWAMP data model using a YANG tree diagram. Readers should keep in		TWAMP data model using a YANG tree diagram. Readers should keep in
	mind that the limit of 72 characters per line forces us to introduce		mind that the limit of 72 characters per line forces us to introduce
	artificial line breaks in some tree diagram nodes.		artificial line breaks in some tree diagram nodes. Tree diagrams
			used in this document follow the notation defined in YANG Tree
			Diagrams [RFC8340].
	module: ietf-twamp		module: ietf-twamp
	+--rw twamp		+--rw twamp
	+--rw client! {control-client}?		+--rw client {control-client}?
	| +--rw admin-state boolean		| +--rw admin-state? boolean
	| +--rw mode-preference-chain* [priority]		| +--rw mode-preference-chain* [priority]
	| | +--rw priority uint16		| | +--rw priority uint16
	| | +--rw mode? twamp-modes		| | +--rw mode? twamp-modes
	| +--rw key-chain* [key-id]		| +--rw key-chain* [key-id]
	| | +--rw key-id string		| | +--rw key-id string
	| | +--rw secret-key? binary		| | +--rw secret-key? string
	| +--rw ctrl-connection* [name]		| +--rw ctrl-connection* [name]
	| +--rw name string		| +--rw name string
	| +--rw client-ip? inet:ip-address		| +--rw client-ip? inet:ip-address
	| +--rw server-ip inet:ip-address		| +--rw server-ip inet:ip-address
	| +--rw server-tcp-port? inet:port-number		| +--rw server-tcp-port? inet:port-number
	| +--rw control-packet-dscp? inet:dscp		| +--rw control-packet-dscp? inet:dscp
	| +--rw key-id? string		| +--rw key-id? string
	| +--rw max-count? uint8		| +--rw max-count? uint8
	| +--ro client-tcp-port? inet:port-number		| +--ro client-tcp-port? inet:port-number
	| +--ro server-start-time? uint64		| +--ro server-start-time? uint64
	skipping to change at page 16, line 27 ¶		skipping to change at page 17, line 18 ¶
	| +--ro state?		| +--ro state?
	| | control-client-connection-state		| | control-client-connection-state
	| +--ro selected-mode? twamp-modes		| +--ro selected-mode? twamp-modes
	| +--ro token? binary		| +--ro token? binary
	| +--ro client-iv? binary		| +--ro client-iv? binary
	| +--rw test-session-request* [name]		| +--rw test-session-request* [name]
	| +--rw name string		| +--rw name string
	| +--rw sender-ip? inet:ip-address		| +--rw sender-ip? inet:ip-address
	| +--rw sender-udp-port? union		| +--rw sender-udp-port? union
	| +--rw reflector-ip inet:ip-address		| +--rw reflector-ip inet:ip-address
	| +--rw reflector-udp-port? uint32		| +--rw reflector-udp-port? inet:port-number
	| +--rw timeout? uint64		| +--rw timeout? uint64
	| +--rw padding-length? uint32		| +--rw padding-length? uint32
	| +--rw test-packet-dscp? inet:dscp		| +--rw test-packet-dscp? inet:dscp
	| +--rw start-time? uint64		| +--rw start-time? uint64
	| +--rw repeat? union		| +--rw repeat? union
	| +--rw repeat-interval? uint32		| +--rw repeat-interval? uint32
	| +--rw pm-reg-list* [pm-index]		| +--rw pm-reg-list* [pm-index]
	| | +--rw pm-index uint16		| | +--rw pm-index uint16
	| +--ro state? test-session-state		| +--ro state? test-session-state
	| +--ro sid? string		| +--ro sid? string
	+--rw server! {server}?		+--rw server {server}?
	| +--rw admin-state boolean		| +--rw admin-state? boolean
	| +--rw server-tcp-port? inet:port-number		| +--rw server-tcp-port? inet:port-number
	| +--rw servwait? uint32		| +--rw servwait? uint32
	| +--rw control-packet-dscp? inet:dscp		| +--rw control-packet-dscp? inet:dscp
	| +--rw count? uint8		| +--rw count? uint8
	| +--rw max-count? uint8		| +--rw max-count? uint8
	| +--rw modes? twamp-modes		| +--rw modes? twamp-modes
	| +--rw key-chain* [key-id]		| +--rw key-chain* [key-id]
	| | +--rw key-id string		| | +--rw key-id string
	| | +--rw secret-key? binary		| | +--rw secret-key? string
	| +--ro ctrl-connection*		| +--ro ctrl-connection*
	| [client-ip client-tcp-port server-ip server-tcp-port]		| [client-ip client-tcp-port server-ip server-tcp-port]
	| +--ro client-ip inet:ip-address		| +--ro client-ip inet:ip-address
	| +--ro client-tcp-port inet:port-number		| +--ro client-tcp-port inet:port-number
	| +--ro server-ip inet:ip-address		| +--ro server-ip inet:ip-address
	| +--ro server-tcp-port inet:port-number		| +--ro server-tcp-port inet:port-number
	| +--ro state? server-ctrl-connection-state		| +--ro state? server-ctrl-connection-state
	| +--ro control-packet-dscp? inet:dscp		| +--ro control-packet-dscp? inet:dscp
	| +--ro selected-mode? twamp-modes		| +--ro selected-mode? twamp-modes
	| +--ro key-id? string		| +--ro key-id? string
	| +--ro count? uint8		| +--ro count? uint8
	| +--ro max-count? uint8		| +--ro max-count? uint8
	| +--ro salt? binary		| +--ro salt? binary
	| +--ro server-iv? binary		| +--ro server-iv? binary
	| +--ro challenge? binary		| +--ro challenge? binary
	+--rw session-sender! {session-sender}?		+--rw session-sender {session-sender}?
	| +--rw admin-state boolean		| +--rw admin-state? boolean
	| +--rw test-session* [name]		| +--rw test-session* [name]
	| +--rw name string		| +--rw name string
	| +--ro ctrl-connection-name? string		| +--ro ctrl-connection-name? string
	| +--rw fill-mode? padding-fill-mode		| +--rw fill-mode? padding-fill-mode
	| +--rw number-of-packets uint32		| +--rw number-of-packets uint32
	| +--rw (packet-distribution)?		| +--rw (packet-distribution)?
	| | +--:(periodic)		| | +--:(periodic)
	| | | +--rw periodic-interval decimal64		| | | +--rw periodic-interval decimal64
	| | +--:(poisson)		| | +--:(poisson)
	| | +--rw lambda decimal64		| | +--rw lambda decimal64
	| | +--rw max-interval? decimal64		| | +--rw max-interval? decimal64
	| +--ro state? sender-session-state		| +--ro state? sender-session-state
	| +--ro sent-packets? uint32		| +--ro sent-packets? uint32
	| +--ro rcv-packets? uint32		| +--ro rcv-packets? uint32
	| +--ro last-sent-seq? uint32		| +--ro last-sent-seq? uint32
	| +--ro last-rcv-seq? uint32		| +--ro last-rcv-seq? uint32
	+--rw session-reflector! {session-reflector}?		+--rw session-reflector {session-reflector}?
	+--rw admin-state boolean		+--rw admin-state? boolean
	+--rw refwait? uint32		+--rw refwait? uint32
	+--ro test-session*		+--ro test-session*
	[sender-ip sender-udp-port reflector-ip reflector-udp		[sender-ip sender-udp-port reflector-ip reflector-udp
	-port]		-port]
	+--ro sid? string		+--ro sid? string
	+--ro sender-ip inet:ip-address		+--ro sender-ip inet:ip-address
	+--ro sender-udp-port		+--ro sender-udp-port
	| dynamic-port-number		| dynamic-port-number
	+--ro reflector-ip inet:ip-address		+--ro reflector-ip inet:ip-address
	+--ro reflector-udp-port uint32		+--ro reflector-udp-port inet:port-numbe
			r
	+--ro parent-connection-client-ip? inet:ip-address		+--ro parent-connection-client-ip? inet:ip-address
	+--ro parent-connection-client-tcp-port? inet:port-numbe		+--ro parent-connection-client-tcp-port? inet:port-numbe
	r		r
	+--ro parent-connection-server-ip? inet:ip-address		+--ro parent-connection-server-ip? inet:ip-address
	+--ro parent-connection-server-tcp-port? inet:port-numbe		+--ro parent-connection-server-tcp-port? inet:port-numbe
	r		r
	+--ro test-packet-dscp? inet:dscp		+--ro test-packet-dscp? inet:dscp
	+--ro sent-packets? uint32		+--ro sent-packets? uint32
	+--ro rcv-packets? uint32		+--ro rcv-packets? uint32
	+--ro last-sent-seq? uint32		+--ro last-sent-seq? uint32
	+--ro last-rcv-seq? uint32		+--ro last-rcv-seq? uint32
	Figure 7: YANG Tree Diagram.		Figure 7: YANG Tree Diagram.
	5.2. YANG Module		5.2. YANG Module
	This section presents the YANG module for the TWAMP data model		This section presents the YANG module for the TWAMP data model
	defined in this document. The module imports definitions from Common		defined in this document. The module imports definitions from NTPv3
	YANG Data Types [RFC6991].		Specification [RFC1305], Randomness Requirements for Security
			[RFC4086], OWAMP [RFC4656], TWAMP [RFC5357], More Features for TWAMP
			[RFC5618], Individual Session Control Feature [RFC5938], TWAMP
			Reflect Octets and Symmetrical Size Features [RFC6038], Common YANG
			Data Types [RFC6991], Advances Stream and Sampling Framework
			[RFC7312], IKEv2-Derived Shared Secret Key for OWAMP and TWAMP
			[RFC7717], and OWAMP and TWAMP Well-Known Port Assignments
			[I-D.ietf-ippm-port-twamp-test].
	<CODE BEGINS> file "ietf-twamp@2018-04-08.yang"		<CODE BEGINS> file "ietf-twamp@2018-04-16.yang"
	module ietf-twamp {		module ietf-twamp {
	yang-version 1.1;		yang-version 1.1;
	namespace urn:ietf:params:xml:ns:yang:ietf-twamp;		namespace urn:ietf:params:xml:ns:yang:ietf-twamp;
	prefix ietf-twamp;		prefix ietf-twamp;
	import ietf-inet-types {		import ietf-inet-types {
	prefix inet;		prefix inet;
	reference		reference
	"RFC 6991: Common YANG Types.";		"RFC 6991: Common YANG Types.";
	skipping to change at page 19, line 4 ¶		skipping to change at page 19, line 51 ¶
	acmorton@att.com		acmorton@att.com
	Editor: Reshad Rehman		Editor: Reshad Rehman
	rrahman@cisco.com		rrahman@cisco.com
	Editor: Mahesh Jethanandani		Editor: Mahesh Jethanandani
	mjethanandani@gmail.com		mjethanandani@gmail.com
	Editor: Kostas Pentikousis		Editor: Kostas Pentikousis
	k.pentikousis@travelping.com";		k.pentikousis@travelping.com";
	description		description
	"This YANG module specifies a vendor-independent data		"This YANG module specifies a vendor-independent data
	model for the Two-Way Active Measurement Protocol (TWAMP).		model for the Two-Way Active Measurement Protocol (TWAMP).
	The data model covers four TWAMP logical entities, namely,		The data model covers four TWAMP logical entities, namely,
	Control-Client, Server, Session-Sender, and Session-Reflector,		Control-Client, Server, Session-Sender, and Session-Reflector,
	as illustrated in the annotated TWAMP logical model (Fig. 1		as illustrated in the annotated TWAMP logical model (Fig. 1
	of RFC XXXX).		of RFC XXXX).
	This YANG module uses features to indicate which of the four		This YANG module uses features to indicate which of the four
	logical entities are supported by a TWAMP implementation.";		logical entities are supported by a TWAMP implementation.
	revision 2018-04-08 {		Copyright (c) 2018 IETF Trust and the persons identified as
			the document authors. All rights reserved.
			Redistribution and use in source and binary forms, with or
			without modification, is permitted pursuant to, and subject
			to the license terms contained in, the Simplified BSD
			License set forth in Section 4.c of the IETF Trust's Legal
			Provisions Relating to IETF Documents
			(http://trustee.ietf.org/license-info).
			This version of this YANG module is part of RFC XXXX; see
			the RFC itself for full legal notices.";
			revision 2018-04-16 {
	description		description
	"Initial Revision.		"Initial Revision.
	Covers RFC 5357, RFC 5618, RFC 5938, RFC 6038, RFC 7717, and		Covers RFC 5357, RFC 5618, RFC 5938, RFC 6038, RFC 7717, and
	draft-ietf-ippm-metric-registry";		draft-ietf-ippm-metric-registry";
	reference		reference
	"RFC XXXX: TWAMP YANG Data Model.";		"RFC XXXX: TWAMP YANG Data Model.";
	}		}
	skipping to change at page 21, line 51 ¶		skipping to change at page 23, line 13 ¶
	description		description
	"Indicates the Control-Client TWAMP-Control connection		"Indicates the Control-Client TWAMP-Control connection
	state.";		state.";
	}		}
	typedef test-session-state {		typedef test-session-state {
	type enumeration {		type enumeration {
	enum accepted {		enum accepted {
	value 0;		value 0;
	description		description
	"Indicates that accepted TWAMP-Test session request.";		"Indicates an accepted TWAMP-Test session request.";
	}		}
	enum failed {		enum failed {
	value 1;		value 1;
	description		description
	"Indicates a TWAMP-Test session failure due to		"Indicates a TWAMP-Test session failure due to
	some unspecified reason (catch-all).";		some unspecified reason (catch-all).";
	}		}
	enum internal-error {		enum internal-error {
	value 2;		value 2;
	description		description
	skipping to change at page 24, line 49 ¶		skipping to change at page 26, line 11 ¶
	length 1..80;		length 1..80;
	}		}
	description		description
	"KeyID used for a TWAMP-Control connection. As per		"KeyID used for a TWAMP-Control connection. As per
	Section 3.1 of RFC 4656, KeyID is 'a UTF-8 string, up to		Section 3.1 of RFC 4656, KeyID is 'a UTF-8 string, up to
	80 octets in length' and is used to select which 'shared		80 octets in length' and is used to select which 'shared
	shared secret the [Control-Client] wishes to use to		shared secret the [Control-Client] wishes to use to
	authenticate or encrypt'.";		authenticate or encrypt'.";
	}		}
	leaf secret-key {		leaf secret-key {
	type binary;		type string;
	description		description
	"The secret key corresponding to the KeyID for this		"The secret key corresponding to the KeyID for this
	TWAMP-Control connection.";		TWAMP-Control connection.";
	}		}
	description		description
	"Relates KeyIDs with their respective secret keys		"Relates KeyIDs with their respective secret keys
	in a TWAMP-Control connection.";		in a TWAMP-Control connection.";
	}		}
	description		description
	"Used by the Control-Client and Server for TWAMP-Control		"Used by the Control-Client and Server for TWAMP-Control
	skipping to change at page 25, line 43 ¶		skipping to change at page 27, line 4 ¶
	config false;		config false;
	description		description
	"Indicates the last sent sequence number.";		"Indicates the last sent sequence number.";
	}		}
	leaf last-rcv-seq {		leaf last-rcv-seq {
	type uint32;		type uint32;
	config false;		config false;
	description		description
	"Indicates the last received sequence number.";		"Indicates the last received sequence number.";
	}		}
	description		description
	"Used for TWAMP-Test maintenance statistics.";		"Used for TWAMP-Test maintenance statistics.";
	}		}
	grouping count {		grouping count {
	leaf count {		leaf count {
	type uint8 {		type uint8 {
	range "10..31";		range "10..31";
	}		}
	default 10;		default 10;
	description		description
	"Parameter communicated to the Control-Client as part of		"Parameter communicated to the Control-Client as part of
	the Server Greeting message and used for deriving a key		the Server Greeting message and used for deriving a key
	from a shared secret as per Section 3.1 of RFC 4656:		from a shared secret as per Section 3.1 of RFC 4656:
	MUST be a power of 2 and at least 1024. It is configured		MUST be a power of 2 and at least 1024. It is configured
	by providing said power. For example, configuring 15 here		by providing said power. For example, configuring 15 here
	means count 2^15 = 32768. The default is 10,		means count 2^15 = 32768. The default is 10,
	meaning 2^10 = 1024.";		meaning 2^10 = 1024.";
	}		}
	description		description
	"Reusable data structure for count which is used both in the		"Reusable data structure for count, which is used both in the
	Server container.";		Server and the Control-Client.";
	}		}
	grouping max-count {		grouping max-count-exponent {
	leaf max-count {		leaf max-count {
	type uint8 {		type uint8 {
	range 10..31;		range 10..31;
	}		}
	default 15;		default 15;
	description		description
	"This parameter limits the maximum Count value, which MUST		"This parameter limits the maximum Count value, which MUST
	be a power of 2 and at least 1024 as per RFC 5357. It is		be a power of 2 and at least 1024 as per RFC 5357. It is
	configured by providing said power. For example,		configured by providing said power. For example,
	configuring 10 here means max count 2^10 = 1024.		configuring 10 here means max count 2^10 = 1024.
	skipping to change at page 27, line 27 ¶		skipping to change at page 28, line 37 ¶
	container twamp {		container twamp {
	description		description
	"TWAMP logical entity configuration grouping of four models		"TWAMP logical entity configuration grouping of four models
	which correspond to the four TWAMP logical entities		which correspond to the four TWAMP logical entities
	Control-Client, Server, Session-Sender, and Session-Reflector		Control-Client, Server, Session-Sender, and Session-Reflector
	as illustrated in Fig. 1 of RFC XXXX.";		as illustrated in Fig. 1 of RFC XXXX.";
	container client {		container client {
	if-feature control-client;		if-feature control-client;
	presence "Enables TWAMP Control-Client functionality.";
	description		description
	"Configuration of the TWAMP Control-Client logical		"Configuration of the TWAMP Control-Client logical
	entity.";		entity.";
	leaf admin-state {		leaf admin-state {
	type boolean;		type boolean;
	mandatory true;		default true;
	description		description
	"Indicates whether the device is allowed to operate as a		"Indicates whether the device is allowed to operate as a
	TWAMP Control-Client.";		TWAMP Control-Client.";
	}		}
	list mode-preference-chain {		list mode-preference-chain {
	key priority;		key priority;
	unique mode;		unique mode;
	leaf priority {		leaf priority {
	type uint16;		type uint16;
	skipping to change at page 29, line 41 ¶		skipping to change at page 30, line 48 ¶
	leaf key-id {		leaf key-id {
	type string {		type string {
	length 1..80;		length 1..80;
	}		}
	description		description
	"Indicates the KeyID value selected for this		"Indicates the KeyID value selected for this
	TWAMP-Control connection.";		TWAMP-Control connection.";
	}		}
	uses max-count;		uses max-count-exponent;
	leaf client-tcp-port {		leaf client-tcp-port {
	type inet:port-number;		type inet:port-number;
	config false;		config false;
	description		description
	"Indicates the source TCP port number used in the		"Indicates the source TCP port number used in the
	TWAMP-Control packets belonging to this control		TWAMP-Control packets belonging to this control
	connection.";		connection.";
	}		}
	leaf server-start-time {		leaf server-start-time {
	type uint64;		type uint64;
	config false;		config false;
	description		description
	"Indicates the Start-Time advertized by the Server in		"Indicates the Start-Time advertized by the Server in
	the Server-Start message (RFC 4656, Section 3.1),		the Server-Start message (RFC 4656, Section 3.1),
	representing the time when the current		representing the time when the current
	instantiation of the Server started operating.		instantiation of the Server started operating.
	The timestamp format follows RFC 1305		The timestamp format follows RFC 1305
	according to Section 4.1.2 of RFC 4656.";		according to Section 4.1.2 of RFC 4656.";
			reference
			"RFC 4656: OWAMP, Section 3.1 and 4.1.2,
			RFC 1305: NTPv3 Specification.";
	}		}
	leaf repeat-count {		leaf repeat-count {
	type uint64;		type uint64;
	config false;		config false;
	description		description
	"Indicates how many times the test session has been		"Indicates how many times the test session has been
	repeated. When a test is running, this value will be		repeated. When a test is running, this value will be
	greater than 0. If the repeat parameter is non-zero,		greater than 0. If the repeat parameter is non-zero,
	this value is smaller than or equal to the repeat		this value is smaller than or equal to the repeat
	skipping to change at page 33, line 22 ¶		skipping to change at page 34, line 34 ¶
	mandatory true;		mandatory true;
	description		description
	"The IP address belonging to the remote		"The IP address belonging to the remote
	Session-Reflector device to which the TWAMP-Test		Session-Reflector device to which the TWAMP-Test
	session will be initiated. This value will be		session will be initiated. This value will be
	used to populate the receiver address field of		used to populate the receiver address field of
	the Request-TW-Session message.";		the Request-TW-Session message.";
	}		}
	leaf reflector-udp-port {		leaf reflector-udp-port {
	type uint32 {		type inet:port-number {
	range "862 | 49152..65535";		range "862 | 49152..65535";
	}		}
	description		description
	"This parameter defines the UDP port number that		"This parameter defines the UDP port number that
	will be used by the Session-Reflector for		will be used by the Session-Reflector for
	this TWAMP-Test session. The default number is		this TWAMP-Test session. The default number is
	within to the dynamic port range and is to be placed		within the dynamic port range and is to be placed
	in the Receiver Port field of the Request-TW-Session		in the Receiver Port field of the Request-TW-Session
	message. The new well-known port (862) MAY be		message. The well-known port (862) MAY be
	used.";		used.";
			reference
			"draft-ietf-ippm-port-twamp-test: OWAMP and TWAMP
			Well-Known Port Assignments.";
	}		}
	leaf timeout {		leaf timeout {
	type uint64;		type uint64;
	units seconds;		units seconds;
	default 2;		default 2;
	description		description
	"The length of time (in seconds) that the		"The length of time (in seconds) that the
	Session-Reflector should continue to respond to		Session-Reflector should continue to respond to
	packets belonging to this TWAMP-Test session after		packets belonging to this TWAMP-Test session after
	a Stop-Sessions TWAMP-Control message has been		a Stop-Sessions TWAMP-Control message has been
	received (RFC 5357, Section 3.8).		received.
	This value will be placed in the Timeout field of		This value will be placed in the Timeout field of
	the Request-TW-Session message.";		the Request-TW-Session message.";
			reference
			"RFC 5357: TWAMP, Section 3.8";
	}		}
	leaf padding-length {		leaf padding-length {
	type uint32 {		type uint32 {
	range 64..4096;		range 64..4096;
	}		}
	description		description
	"The number of padding bytes to be added to the		"The number of padding bytes to be added to the
	TWAMP-Test (UDP) packets generated by the		TWAMP-Test (UDP) packets generated by the
	Session-Sender.		Session-Sender.
	skipping to change at page 37, line 12 ¶		skipping to change at page 38, line 28 ¶
	in the SID field of the Accept-Session message";		in the SID field of the Accept-Session message";
	reference		reference
	"Section 4.3 of RFC 6038.";		"Section 4.3 of RFC 6038.";
	}		}
	}		}
	}		}
	}		}
	container server {		container server {
	if-feature server;		if-feature server;
	presence "Enables TWAMP Server functionality.";
	description		description
	"Configuration of the TWAMP Server logical entity.";		"Configuration of the TWAMP Server logical entity.";
	leaf admin-state {		leaf admin-state {
	type boolean;		type boolean;
	mandatory true;		default true;
	description		description
	"Indicates whether the device is allowed to operate		"Indicates whether the device is allowed to operate
	as a TWAMP Server.";		as a TWAMP Server.";
	}		}
	leaf server-tcp-port {		leaf server-tcp-port {
	type inet:port-number;		type inet:port-number;
	default 862;		default 862;
	description		description
	"This parameter defines the well known TCP port number		"This parameter defines the well known TCP port number
	skipping to change at page 38, line 31 ¶		skipping to change at page 39, line 46 ¶
	OS-portable version of TWAMP.		OS-portable version of TWAMP.
	The default behavior if this item is not set is to use		The default behavior if this item is not set is to use
	the DSCP value from the Control-Clients TCP SYN.";		the DSCP value from the Control-Clients TCP SYN.";
	reference		reference
	"Section 3.1 of RFC 5357.";		"Section 3.1 of RFC 5357.";
	}		}
	uses count;		uses count;
	uses max-count;		uses max-count-exponent;
	leaf modes {		leaf modes {
	type twamp-modes;		type twamp-modes;
	description		description
	"The bit mask of TWAMP Modes this Server instance		"The bit mask of TWAMP Modes this Server instance
	is willing to support; see IANA TWAMP Modes Registry.";		is willing to support; see IANA TWAMP Modes Registry.";
	}		}
	uses key-management;		uses key-management;
	skipping to change at page 40, line 40 ¶		skipping to change at page 42, line 7 ¶
	description		description
	"The count value that is in use by this TWAMP-Control		"The count value that is in use by this TWAMP-Control
	connection. This will usually be the same value		connection. This will usually be the same value
	as is configured under twamp/server. However, in the		as is configured under twamp/server. However, in the
	event that the user re-configured server/count		event that the user re-configured server/count
	after this control connection is already in progress,		after this control connection is already in progress,
	this read-only value will show the actual count that		this read-only value will show the actual count that
	is in use for this TWAMP-Control connection.";		is in use for this TWAMP-Control connection.";
	}		}
	uses max-count {		uses max-count-exponent {
	description		description
	"This read-only value indicates the actual max-count in		"This read-only value indicates the actual max-count in
	use for this control connection. Usually this would be		use for this control connection. Usually this would be
	the same value as configured under twamp/server.";		the same value as configured under twamp/server.";
	}		}
	leaf salt {		leaf salt {
	type binary {		type binary {
	length 16;		length 16;
	}		}
	skipping to change at page 41, line 34 ¶		skipping to change at page 42, line 49 ¶
	"A random sequence of octets generated by the Server.		"A random sequence of octets generated by the Server.
	As described in client/token, Challenge is used		As described in client/token, Challenge is used
	by the Control-Client to prove possession of a		by the Control-Client to prove possession of a
	shared secret.";		shared secret.";
	}		}
	}		}
	}		}
	container session-sender {		container session-sender {
	if-feature session-sender;		if-feature session-sender;
	presence "Enables TWAMP Session-Sender functionality.";
	description		description
	"Configuration of the TWAMP Session-Sender logical entity";		"Configuration of the TWAMP Session-Sender logical entity";
	leaf admin-state {		leaf admin-state {
	type boolean;		type boolean;
	mandatory true;		default true;
	description		description
	"Indicates whether the device is allowed to operate		"Indicates whether the device is allowed to operate
	as a TWAMP Session-Sender.";		as a TWAMP Session-Sender.";
	}		}
	list test-session{		list test-session{
	key name;		key name;
	description		description
	"List of TWAMP Session-Sender test sessions.";		"List of TWAMP Session-Sender test sessions.";
	skipping to change at page 44, line 4 ¶		skipping to change at page 45, line 19 ¶
	leaf state {		leaf state {
	type sender-session-state;		type sender-session-state;
	config false;		config false;
	description		description
	"Indicates the Session-Sender test session state.";		"Indicates the Session-Sender test session state.";
	}		}
	uses maintenance-statistics;		uses maintenance-statistics;
	}		}
	}		}
	container session-reflector {		container session-reflector {
	if-feature session-reflector;		if-feature session-reflector;
	presence "Enables TWAMP Session-Reflector functionality.";
	description		description
	"Configuration of the TWAMP Session-Reflector logical		"Configuration of the TWAMP Session-Reflector logical
	entity";		entity";
	leaf admin-state {		leaf admin-state {
	type boolean;		type boolean;
	mandatory true;		default true;
	description		description
	"Indicates whether the device is allowed to operate		"Indicates whether the device is allowed to operate
	as a TWAMP Session-Reflector.";		as a TWAMP Session-Reflector.";
	}		}
	leaf refwait {		leaf refwait {
	type uint32 {		type uint32 {
	range 1..604800;		range 1..604800;
	}		}
	units seconds;		units seconds;
	skipping to change at page 45, line 29 ¶		skipping to change at page 46, line 45 ¶
	leaf reflector-ip {		leaf reflector-ip {
	type inet:ip-address;		type inet:ip-address;
	description		description
	"The IP address of the local Session-Reflector		"The IP address of the local Session-Reflector
	device, which is the destination IP address used		device, which is the destination IP address used
	in the TWAMP-Test (UDP) packets belonging to this test		in the TWAMP-Test (UDP) packets belonging to this test
	session.";		session.";
	}		}
	leaf reflector-udp-port {		leaf reflector-udp-port {
	type uint32 {		type inet:port-number {
	range "862 | 49152..65535";		range "862 | 49152..65535";
	}		}
	description		description
	"The destination UDP port number used in the		"The destination UDP port number used in the
	TWAMP-Test (UDP) test packets belonging to this		TWAMP-Test (UDP) test packets belonging to this
	test session.";		test session.";
	}		}
	leaf parent-connection-client-ip {		leaf parent-connection-client-ip {
	type inet:ip-address;		type inet:ip-address;
	description		description
	"The IP address on the Control-Client device, which		"The IP address on the Control-Client device, which
	is the source IP address used in the TWAMP-Control		is the source IP address used in the TWAMP-Control
	(TCP) packets belonging to the parent control		(TCP) packets belonging to the parent control
	connection that negotiated this test session.";		connection that negotiated this test session.";
	}		}
	leaf parent-connection-client-tcp-port {		leaf parent-connection-client-tcp-port {
	skipping to change at page 54, line 25 ¶		skipping to change at page 55, line 25 ¶
	<rcv-packets>21</rcv-packets>		<rcv-packets>21</rcv-packets>
	<last-sent-seq>20</last-sent-seq>		<last-sent-seq>20</last-sent-seq>
	<last-rcv-seq>20</last-rcv-seq>		<last-rcv-seq>20</last-rcv-seq>
	</test-session>		</test-session>
	</session-reflector>		</session-reflector>
	</twamp>		</twamp>
	</data>		</data>
	7. Security Considerations		7. Security Considerations
	The YANG module defined in Section 5 is designed to be accessed,		The YANG module specified in Section 5 this document defines a schema
	among other protocols, via NETCONF [RFC6241]. Protocols like NETCONF		for data that is designed to be accessed via network management
	use a secure transport layer like SSH that is mandatory to implement.		protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The
			lowest NETCONF [RFC6241] layer is the secure transport layer, and the
			mandatory-to-implement secure transport is Secure Shell (SSH)
			[RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-
			implement secure transport is TLS [RFC5246].
	The NETCONF Access Control Module (NACM) [RFC8341] provides the means		The NETCONF Access Control Module (NACM) [RFC8341] provides the means
	to restrict access for particular users to a pre-configured set of		to restrict access for particular NETCONF or RESTCONF users to a
	NETCONF protocol operations and attributes.		preconfigured subset of all available NETCONF or RESTCONF protocol
			operations and content..
	There are a number of nodes defined in this YANG module which are		There are a number of nodes defined in this YANG module which are
	writeable. These data nodes may be considered sensitive and		writeable. These data nodes may be considered sensitive and
	vulnerable to attacks in some network environments. Ability to write		vulnerable to attacks in some network environments. Ability to write
	into these nodes without proper protection can have a negative effect		into these nodes without proper protection can have a negative effect
	on the devices that support this feature.		on the devices that support this feature.
	Examples of nodes that are particularly vulnerable include several		Examples of nodes that are particularly vulnerable include several
	timeout values put in the protocol to protect against sessions that		timeout values put in the protocol to protect against sessions that
	are not active but are consuming resources.		are not active but are consuming resources.
	8. IANA Considerations		8. IANA Considerations
	This document registers a URI in the IETF XML registry [RFC3688].		This document registers a URI in the IETF XML registry [RFC3688].
	Following the format in [RFC3688], the following registration is		Following the format in IETF XML Registry [RFC3688], the following
	requested to be made.		registration is requested to be made.
	URI: urn:ietf:params:xml:ns:yang:ietf-twamp		URI: urn:ietf:params:xml:ns:yang:ietf-twamp
	Registrant Contact: The IPPM WG of the IETF.		Registrant Contact: The IPPM WG of the IETF.
	XML: N/A, the requested URI is an XML namespace.		XML: N/A, the requested URI is an XML namespace.
	This document registers a YANG module in the YANG Module Names		This document registers a YANG module in the YANG Module Names
	registry [RFC6020].		registry YANG [RFC6020].
	name: ietf-twamp		name: ietf-twamp
	namespace: urn:ietf:params:xml:ns:yang:ietf-twamp		namespace: urn:ietf:params:xml:ns:yang:ietf-twamp
	prefix: twamp		prefix: twamp
	reference: RFC XXXX		reference: RFC XXXX
	9. Acknowledgements		9. Acknowledgements
	skipping to change at page 55, line 45 ¶		skipping to change at page 57, line 9 ¶
	may be made of the information in this document.		may be made of the information in this document.
	10. Contributors		10. Contributors
	Lianshu Zheng.		Lianshu Zheng.
	11. References		11. References
	11.1. Normative References		11.1. Normative References
			[I-D.ietf-ippm-port-twamp-test]
			Morton, A. and G. Mirsky, "OWAMP and TWAMP Well-Known Port
			Assignments", draft-ietf-ippm-port-twamp-test-01 (work in
			progress), March 2018.
			[RFC1305] Mills, D., "Network Time Protocol (Version 3)
			Specification, Implementation and Analysis", RFC 1305,
			DOI 10.17487/RFC1305, March 1992,
			<https://www.rfc-editor.org/info/rfc1305>.
	[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>.
	[RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network		[RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network
	performance measurement with periodic streams", RFC 3432,		performance measurement with periodic streams", RFC 3432,
	DOI 10.17487/RFC3432, November 2002,		DOI 10.17487/RFC3432, November 2002,
	<https://www.rfc-editor.org/info/rfc3432>.		<https://www.rfc-editor.org/info/rfc3432>.
	skipping to change at page 56, line 38 ¶		skipping to change at page 58, line 9 ¶
	[RFC6038] Morton, A. and L. Ciavattone, "Two-Way Active Measurement		[RFC6038] Morton, A. and L. Ciavattone, "Two-Way Active Measurement
	Protocol (TWAMP) Reflect Octets and Symmetrical Size		Protocol (TWAMP) Reflect Octets and Symmetrical Size
	Features", RFC 6038, DOI 10.17487/RFC6038, October 2010,		Features", RFC 6038, DOI 10.17487/RFC6038, October 2010,
	<https://www.rfc-editor.org/info/rfc6038>.		<https://www.rfc-editor.org/info/rfc6038>.
	[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>.
			[RFC7312] Fabini, J. and A. Morton, "Advanced Stream and Sampling
			Framework for IP Performance Metrics (IPPM)", RFC 7312,
			DOI 10.17487/RFC7312, August 2014,
			<https://www.rfc-editor.org/info/rfc7312>.
	[RFC7717] Pentikousis, K., Ed., Zhang, E., and Y. Cui,		[RFC7717] Pentikousis, K., Ed., Zhang, E., and Y. Cui,
	"IKEv2-Derived Shared Secret Key for the One-Way Active		"IKEv2-Derived Shared Secret Key for the One-Way Active
	Measurement Protocol (OWAMP) and Two-Way Active		Measurement Protocol (OWAMP) and Two-Way Active
	Measurement Protocol (TWAMP)", RFC 7717,		Measurement Protocol (TWAMP)", RFC 7717,
	DOI 10.17487/RFC7717, December 2015,		DOI 10.17487/RFC7717, December 2015,
	<https://www.rfc-editor.org/info/rfc7717>.		<https://www.rfc-editor.org/info/rfc7717>.
	[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",		[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
	RFC 7950, DOI 10.17487/RFC7950, August 2016,		RFC 7950, DOI 10.17487/RFC7950, August 2016,
	<https://www.rfc-editor.org/info/rfc7950>.		<https://www.rfc-editor.org/info/rfc7950>.
	skipping to change at page 57, line 33 ¶		skipping to change at page 59, line 10 ¶
	[NSC] John, W., Pentikousis, K., et al., "Research directions in		[NSC] John, W., Pentikousis, K., et al., "Research directions in
	network service chaining", Proc. SDN for Future Networks		network service chaining", Proc. SDN for Future Networks
	and Services (SDN4FNS), Trento, Italy IEEE, November 2013.		and Services (SDN4FNS), Trento, Italy IEEE, November 2013.
	[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,		[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
	"Randomness Requirements for Security", BCP 106, RFC 4086,		"Randomness Requirements for Security", BCP 106, RFC 4086,
	DOI 10.17487/RFC4086, June 2005,		DOI 10.17487/RFC4086, June 2005,
	<https://www.rfc-editor.org/info/rfc4086>.		<https://www.rfc-editor.org/info/rfc4086>.
			[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
			(TLS) Protocol Version 1.2", RFC 5246,
			DOI 10.17487/RFC5246, August 2008,
			<https://www.rfc-editor.org/info/rfc5246>.
	[RFC5618] Morton, A. and K. Hedayat, "Mixed Security Mode for the		[RFC5618] Morton, A. and K. Hedayat, "Mixed Security Mode for the
	Two-Way Active Measurement Protocol (TWAMP)", RFC 5618,		Two-Way Active Measurement Protocol (TWAMP)", RFC 5618,
	DOI 10.17487/RFC5618, August 2009,		DOI 10.17487/RFC5618, August 2009,
	<https://www.rfc-editor.org/info/rfc5618>.		<https://www.rfc-editor.org/info/rfc5618>.
	[RFC5938] Morton, A. and M. Chiba, "Individual Session Control		[RFC5938] Morton, A. and M. Chiba, "Individual Session Control
	Feature for the Two-Way Active Measurement Protocol		Feature for the Two-Way Active Measurement Protocol
	(TWAMP)", RFC 5938, DOI 10.17487/RFC5938, August 2010,		(TWAMP)", RFC 5938, DOI 10.17487/RFC5938, August 2010,
	<https://www.rfc-editor.org/info/rfc5938>.		<https://www.rfc-editor.org/info/rfc5938>.
	[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,		[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
	and A. Bierman, Ed., "Network Configuration Protocol		and A. Bierman, Ed., "Network Configuration Protocol
	(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,		(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
	<https://www.rfc-editor.org/info/rfc6241>.		<https://www.rfc-editor.org/info/rfc6241>.
			[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
			Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
			<https://www.rfc-editor.org/info/rfc6242>.
	[RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S.,		[RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S.,
	Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software-		Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software-
	Defined Networking (SDN): Layers and Architecture		Defined Networking (SDN): Layers and Architecture
	Terminology", RFC 7426, DOI 10.17487/RFC7426, January		Terminology", RFC 7426, DOI 10.17487/RFC7426, January
	2015, <https://www.rfc-editor.org/info/rfc7426>.		2015, <https://www.rfc-editor.org/info/rfc7426>.
	[RFC8018] Moriarty, K., Ed., Kaliski, B., and A. Rusch, "PKCS #5:		[RFC8018] Moriarty, K., Ed., Kaliski, B., and A. Rusch, "PKCS #5:
	Password-Based Cryptography Specification Version 2.1",		Password-Based Cryptography Specification Version 2.1",
	RFC 8018, DOI 10.17487/RFC8018, January 2017,		RFC 8018, DOI 10.17487/RFC8018, January 2017,
	<https://www.rfc-editor.org/info/rfc8018>.		<https://www.rfc-editor.org/info/rfc8018>.
	[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF		[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
	Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,		Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
	<https://www.rfc-editor.org/info/rfc8040>.		<https://www.rfc-editor.org/info/rfc8040>.
			[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
			BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
			<https://www.rfc-editor.org/info/rfc8340>.
	[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration		[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
	Access Control Model", STD 91, RFC 8341,		Access Control Model", STD 91, RFC 8341,
	DOI 10.17487/RFC8341, March 2018,		DOI 10.17487/RFC8341, March 2018,
	<https://www.rfc-editor.org/info/rfc8341>.		<https://www.rfc-editor.org/info/rfc8341>.
	Appendix A. Detailed Data Model Examples		Appendix A. Detailed Data Model Examples
	This appendix extends the example presented in Section 6 by		This appendix extends the example presented in Section 6 by
	configuring more fields such as authentication parameters, DSCP		configuring more fields such as authentication parameters, DSCP
	values and so on.		values and so on.
	skipping to change at page 65, line 16 ¶		skipping to change at page 67, line 16 ¶
	TWAMP operational commands could be performed programmatically or		TWAMP operational commands could be performed programmatically or
	manually, e.g. using a command-line interface (CLI).		manually, e.g. using a command-line interface (CLI).
	With respect to programmability, YANG can be used to define NETCONF		With respect to programmability, YANG can be used to define NETCONF
	Remote Procedure Calls (RPC), therefore it would be, in principle,		Remote Procedure Calls (RPC), therefore it would be, in principle,
	possible to define TWAMP RPC operations for actions such as starting		possible to define TWAMP RPC operations for actions such as starting
	or stopping control connections or test sessions or groups of		or stopping control connections or test sessions or groups of
	sessions; retrieving results; clearing stored results, and so on.		sessions; retrieving results; clearing stored results, and so on.
	However, [RFC5357] does not attempt to describe such operational		However, TWAMP [RFC5357] does not attempt to describe such
	actions. Refer also to Section 2 and the unlabeled links in		operational actions. Refer also to Section 2 and the unlabeled links
	Figure 1. In actual deployments different TWAMP implementations may		in Figure 1. In actual deployments different TWAMP implementations
	support different sets of operational commands, with different		may support different sets of operational commands, with different
	restrictions. Therefore, this document considers it the		restrictions. Therefore, this document considers it the
	responsibility of the individual implementation to define its		responsibility of the individual implementation to define its
	corresponding TWAMP operational commands data model.		corresponding TWAMP operational commands data model.
	Authors' Addresses		Authors' Addresses
	Ruth Civil		Ruth Civil
	Ciena Corporation		Ciena Corporation
	307 Legget Drive		307 Legget Drive
	Kanata, ON K2K 3C8		Kanata, ON K2K 3C8
End of changes. 77 change blocks.
	133 lines changed or deleted		202 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/