draft-ietf-ippm-twamp-yang-08.txt		draft-ietf-ippm-twamp-yang-09.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 16, 2018 AT&T Labs		Expires: October 22, 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 14, 2018		April 20, 2018
	Two-Way Active Measurement Protocol (TWAMP) Data Model		Two-Way Active Measurement Protocol (TWAMP) Data Model
	draft-ietf-ippm-twamp-yang-08		draft-ietf-ippm-twamp-yang-09
	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		The document defines the TWAMP data model through Unified Modeling
	(UML) class diagrams and formally specify it using YANG.		Language (UML) class diagrams and formally specifies it using YANG.
	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 October 16, 2018.		This Internet-Draft will expire on October 22, 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
	skipping to change at page 2, line 42 ¶		skipping to change at page 2, line 42 ¶
	6.1. Control-Client . . . . . . . . . . . . . . . . . . . . . 48		6.1. Control-Client . . . . . . . . . . . . . . . . . . . . . 48
	6.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 50		6.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 50
	6.3. Session-Sender . . . . . . . . . . . . . . . . . . . . . 51		6.3. Session-Sender . . . . . . . . . . . . . . . . . . . . . 51
	6.4. Session-Reflector . . . . . . . . . . . . . . . . . . . . 52		6.4. Session-Reflector . . . . . . . . . . . . . . . . . . . . 52
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 55		7. Security Considerations . . . . . . . . . . . . . . . . . . . 55
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 56		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 56
	10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 56		10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 56
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 57		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 57
	11.1. Normative References . . . . . . . . . . . . . . . . . . 57		11.1. Normative References . . . . . . . . . . . . . . . . . . 57
	11.2. Informative References . . . . . . . . . . . . . . . . . 58		11.2. Informative References . . . . . . . . . . . . . . . . . 59
	Appendix A. Detailed Data Model Examples . . . . . . . . . . . . 60		Appendix A. Detailed Data Model Examples . . . . . . . . . . . . 60
	A.1. Control-Client . . . . . . . . . . . . . . . . . . . . . 60		A.1. Control-Client . . . . . . . . . . . . . . . . . . . . . 60
	A.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 62		A.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 62
	A.3. Session-Sender . . . . . . . . . . . . . . . . . . . . . 63		A.3. Session-Sender . . . . . . . . . . . . . . . . . . . . . 64
	A.4. Session-Reflector . . . . . . . . . . . . . . . . . . . . 64		A.4. Session-Reflector . . . . . . . . . . . . . . . . . . . . 64
	Appendix B. TWAMP Operational Commands . . . . . . . . . . . . . 67		Appendix B. TWAMP Operational Commands . . . . . . . . . . . . . 67
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 67		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
	skipping to change at page 3, line 24 ¶		skipping to change at page 3, line 24 ¶
	model using YANG [RFC7950].		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 Unifying Carrier and Cloud Networks: Problem Statement		discussed in Unifying Carrier and Cloud Networks: Problem Statement
	and Challenges [I-D.unify-nfvrg-challenges]DevOps For Software-		and Challenges [I-D.unify-nfvrg-challenges], and DevOps For Software-
	Defined Telecom Infrastructures [I-D.unify-nfvrg-devops], proprietary		Defined Telecom Infrastructures [I-D.unify-nfvrg-devops], proprietary
	mechanisms for managing TWAMP measurements pose severe limitations		mechanisms for managing TWAMP measurements pose severe limitations
	with respect to programmability.		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, it is expected 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 Software-Defined Networking (SDN): Layers and Architecture		planes Software-Defined Networking (SDN): Layers and Architecture
	Terminology [RFC7426] requires a well-defined data model for TWAMP		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 [RFC7950] data modeling		specifies it formally using the YANG [RFC7950] data modeling
	language.		language.
	Note to RFC Editor:		Note to RFC Editor:
	Please replace the date 2018-04-16 in Section 5.2 of the draft with		Please replace the date 2018-04-19 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-port-twamp-test with the RFC		reference to RFC XXXX, and draft-ietf-port-twamp-test with the RFC
	numbers assigned to the drafts.		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
	skipping to change at page 5, line 38 ¶		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 TWAMP		operational actions are not part of the TWAMP [RFC5357]
	[RFC5357] and hence are out of scope of this document. See also		specification, and hence are out of scope of this document. See also
	Appendix B.		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
	skipping to change at page 6, line 15 ¶		skipping to change at page 6, line 15 ¶
	A second category includes attributes that can be configured on a per		A second category includes attributes that can be configured on a per
	TWAMP-Control connection basis, such as the Server IP address.		TWAMP-Control connection basis, such as the Server IP address.
	A third category includes attributes related to per TWAMP-Test		A third category includes attributes related to per TWAMP-Test
	session attributes, for instance setting different values in the		session attributes, for instance setting different values in the
	Differentiated Services Code Point (DSCP) field.		Differentiated Services Code Point (DSCP) field.
	Finally, the data model includes attributes that relate to the		Finally, the data model includes attributes that relate to the
	operational state of the TWAMP implementation.		operational state of the TWAMP implementation.
	As we describe the TWAMP data model in the remaining sections of this		As the TWAMP data model is described in the remaining sections of
	document, readers should keep in mind the functional entity grouping		this document, readers should keep in mind the functional entity
	illustrated in Figure 1.		grouping illustrated in Figure 1.
	3.1. Control-Client		3.1. Control-Client
	A TWAMP Control-Client has an administrative status field set at the		A TWAMP Control-Client has an administrative status field set at the
	device level that indicates whether the node is enabled to function		device level that indicates whether the node is enabled to function
	as such.		as such.
	Each TWAMP Control-Client is associated with zero or more TWAMP-		Each TWAMP Control-Client is associated with zero or more TWAMP-
	Control connections. The main configuration parameters of each		Control connections. The main configuration parameters of each
	control connection are:		control connection are:
	skipping to change at page 6, line 47 ¶		skipping to change at page 6, line 47 ¶
	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 OWAMP [RFC4656] and Randomness		paragraph of Section 6 in OWAMP [RFC4656] and Randomness
	Requirements for Security [RFC4086].		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, the following
	following configuration items:		configuration items should be noted:
	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.
	skipping to change at page 9, line 48 ¶		skipping to change at page 9, line 48 ¶
	| pm-index | | sid {ro} |		| pm-index | | sid {ro} |
	+-------------+ +----------------------+		+-------------+ +----------------------+
	Figure 3: TWAMP Control-Client UML class diagram		Figure 3: TWAMP Control-Client UML class diagram
	The client container holds a list (mode-preference-chain) which		The client container holds a list (mode-preference-chain) which
	specifies the Mode values according to their preferred order of use		specifies the Mode values according to their preferred order of use
	by the operator of this Control-Client, including the authentication		by the operator of this Control-Client, including the authentication
	and encryption Modes. Specifically, mode-preference-chain lists the		and encryption Modes. Specifically, mode-preference-chain lists the
	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 integers
	monotonically increasing.		increase by one.
	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 Mixed Security Mode for TWAMP [RFC5618], Individual		TWAMP features in Mixed Security Mode for TWAMP [RFC5618], Individual
	Session Control Feature for TWAMP [RFC5938], TWAMP Reflect Octets and		Session Control Feature for TWAMP [RFC5938], TWAMP Reflect Octets and
	Symmetrical Size Features [RFC6038], and IKEv2-Derived Shared Secret		Symmetrical Size Features [RFC6038], and IKEv2-Derived Shared Secret
	skipping to change at page 17, line 4 ¶		skipping to change at page 17, line 4 ¶
	| +--rw key-chain* [key-id]		| +--rw key-chain* [key-id]
	| | +--rw key-id string		| | +--rw key-id string
	| | +--rw secret-key? string		| | +--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-exponent? 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
	| +--ro repeat-count? uint64		| +--ro repeat-count? uint64
	| +--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
	skipping to change at page 17, line 35 ¶		skipping to change at page 17, line 35 ¶
	| +--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-exponent? 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? string		| | +--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-exponent? 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
	skipping to change at page 19, line 8 ¶		skipping to change at page 19, line 8 ¶
	+--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 NTPv3		defined in this document. The module imports definitions from Common
	Specification [RFC1305], Randomness Requirements for Security		YANG Data Types [RFC6991], and references NTPv3 Specification
	[RFC4086], OWAMP [RFC4656], TWAMP [RFC5357], More Features for TWAMP		[RFC1305], Framework for IP Performance Metrics [RFC2330], Randomness
	[RFC5618], Individual Session Control Feature [RFC5938], TWAMP		Requirements for Security [RFC4086], OWAMP [RFC4656], TWAMP
	Reflect Octets and Symmetrical Size Features [RFC6038], Common YANG		[RFC5357], More Features for TWAMP [RFC5618], Individual Session
	Data Types [RFC6991], Advances Stream and Sampling Framework		Control Feature [RFC5938], TWAMP Reflect Octets and Symmetrical Size
	[RFC7312], IKEv2-Derived Shared Secret Key for OWAMP and TWAMP		Features [RFC6038], Advances Stream and Sampling Framework [RFC7312],
	[RFC7717], and OWAMP and TWAMP Well-Known Port Assignments		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].		[I-D.ietf-ippm-port-twamp-test].
	<CODE BEGINS> file "ietf-twamp@2018-04-16.yang"		<CODE BEGINS> file "ietf-twamp@2018-04-19.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 20, line 25 ¶		skipping to change at page 20, line 26 ¶
	Redistribution and use in source and binary forms, with or		Redistribution and use in source and binary forms, with or
	without modification, is permitted pursuant to, and subject		without modification, is permitted pursuant to, and subject
	to the license terms contained in, the Simplified BSD		to the license terms contained in, the Simplified BSD
	License set forth in Section 4.c of the IETF Trust's Legal		License set forth in Section 4.c of the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info).		(http://trustee.ietf.org/license-info).
	This version of this YANG module is part of RFC XXXX; see		This version of this YANG module is part of RFC XXXX; see
	the RFC itself for full legal notices.";		the RFC itself for full legal notices.";
	revision 2018-04-16 {		revision 2018-04-19 {
	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 27, line 31 ¶		skipping to change at page 27, line 32 ¶
	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 and the Control-Client.";		Server and the Control-Client.";
	}		}
	grouping max-count-exponent {		grouping max-count-exponent {
	leaf max-count {		leaf max-count-exponent {
	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.
	The default is 15, meaning 2^15 = 32768.		The default is 15, meaning 2^15 = 32768.
	skipping to change at page 28, line 12 ¶		skipping to change at page 28, line 14 ¶
	Further, note that according to Section 6 of RFC 5357:		Further, note that according to Section 6 of RFC 5357:
	'If an attacking system sets the maximum value in		'If an attacking system sets the maximum value in
	Count (2**32), then the system under attack would stall		Count (2**32), then the system under attack would stall
	for a significant period of time while it attempts to		for a significant period of time while it attempts to
	generate keys.		generate keys.
	TWAMP-compliant systems SHOULD have a configuration		TWAMP-compliant systems SHOULD have a configuration
	control to limit the maximum count value. The default		control to limit the maximum count value. The default
	max-count value SHOULD be 32768.'		max-count-exponent value SHOULD be 15 which corresponds
			to a maximum value of 2**15 or 32768.'
	RFC 5357 does not qualify 'significant period' in terms of		RFC 5357 does not qualify 'significant period' in terms of
	time, but it is clear that this depends on the processing		time, but it is clear that this depends on the processing
	capacity available and operators need to pay attention to		capacity available and operators need to pay attention to
	this security consideration.";		this security consideration.";
	}		}
	description		description
	"Reusable data structure for max-count which is used both at		"Reusable data structure for max-count which is used both at
	the Control-Client and the Server containers.";		the Control-Client and the Server containers.";
	}		}
	skipping to change at page 57, line 9 ¶		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-metric-registry]
			Bagnulo, M., Claise, B., Eardley, P., Morton, A., and A.
			Akhter, "Registry for Performance Metrics", draft-ietf-
			ippm-metric-registry-14 (work in progress), March 2018.
	[I-D.ietf-ippm-port-twamp-test]		[I-D.ietf-ippm-port-twamp-test]
	Morton, A. and G. Mirsky, "OWAMP and TWAMP Well-Known Port		Morton, A. and G. Mirsky, "OWAMP and TWAMP Well-Known Port
	Assignments", draft-ietf-ippm-port-twamp-test-01 (work in		Assignments", draft-ietf-ippm-port-twamp-test-01 (work in
	progress), March 2018.		progress), March 2018.
	[RFC1305] Mills, D., "Network Time Protocol (Version 3)		[RFC1305] Mills, D., "Network Time Protocol (Version 3)
	Specification, Implementation and Analysis", RFC 1305,		Specification, Implementation and Analysis", RFC 1305,
	DOI 10.17487/RFC1305, March 1992,		DOI 10.17487/RFC1305, March 1992,
	<https://www.rfc-editor.org/info/rfc1305>.		<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>.
			[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
			"Framework for IP Performance Metrics", RFC 2330,
			DOI 10.17487/RFC2330, May 1998,
			<https://www.rfc-editor.org/info/rfc2330>.
	[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>.
	[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>.
			[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
			"Randomness Requirements for Security", BCP 106, RFC 4086,
			DOI 10.17487/RFC4086, June 2005,
			<https://www.rfc-editor.org/info/rfc4086>.
	[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.		[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.
	Zekauskas, "A One-way Active Measurement Protocol		Zekauskas, "A One-way Active Measurement Protocol
	(OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006,		(OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006,
	<https://www.rfc-editor.org/info/rfc4656>.		<https://www.rfc-editor.org/info/rfc4656>.
	[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J.		[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J.
	Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)",		Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)",
	RFC 5357, DOI 10.17487/RFC5357, October 2008,		RFC 5357, DOI 10.17487/RFC5357, October 2008,
	<https://www.rfc-editor.org/info/rfc5357>.		<https://www.rfc-editor.org/info/rfc5357>.
	skipping to change at page 58, line 25 ¶		skipping to change at page 58, line 40 ¶
	"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>.
			[RFC8018] Moriarty, K., Ed., Kaliski, B., and A. Rusch, "PKCS #5:
			Password-Based Cryptography Specification Version 2.1",
			RFC 8018, DOI 10.17487/RFC8018, January 2017,
			<https://www.rfc-editor.org/info/rfc8018>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	11.2. Informative References		11.2. Informative References
	[I-D.ietf-ippm-metric-registry]
	Bagnulo, M., Claise, B., Eardley, P., Morton, A., and A.
	Akhter, "Registry for Performance Metrics", draft-ietf-
	ippm-metric-registry-14 (work in progress), March 2018.
	[I-D.unify-nfvrg-challenges]		[I-D.unify-nfvrg-challenges]
	Szabo, R., Csaszar, A., Pentikousis, K., Kind, M., Daino,		Szabo, R., Csaszar, A., Pentikousis, K., Kind, M., Daino,
	D., Qiang, Z., and H. Woesner, "Unifying Carrier and Cloud		D., Qiang, Z., and H. Woesner, "Unifying Carrier and Cloud
	Networks: Problem Statement and Challenges", draft-unify-		Networks: Problem Statement and Challenges", draft-unify-
	nfvrg-challenges-04 (work in progress), July 2016.		nfvrg-challenges-04 (work in progress), July 2016.
	[I-D.unify-nfvrg-devops]		[I-D.unify-nfvrg-devops]
	Meirosu, C., Manzalini, A., Steinert, R., Marchetto, G.,		Meirosu, C., Manzalini, A., Steinert, R., Marchetto, G.,
	Pentikousis, K., Wright, S., Lynch, P., and W. John,		Pentikousis, K., Wright, S., Lynch, P., and W. John,
	"DevOps for Software-Defined Telecom Infrastructures",		"DevOps for Software-Defined Telecom Infrastructures",
	draft-unify-nfvrg-devops-06 (work in progress), July 2016.		draft-unify-nfvrg-devops-06 (work in progress), July 2016.
	[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,
	"Randomness Requirements for Security", BCP 106, RFC 4086,
	DOI 10.17487/RFC4086, June 2005,
	<https://www.rfc-editor.org/info/rfc4086>.
	[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security		[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
	(TLS) Protocol Version 1.2", RFC 5246,		(TLS) Protocol Version 1.2", RFC 5246,
	DOI 10.17487/RFC5246, August 2008,		DOI 10.17487/RFC5246, August 2008,
	<https://www.rfc-editor.org/info/rfc5246>.		<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>.
	skipping to change at page 59, line 40 ¶		skipping to change at page 60, line 5 ¶
	[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure		[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
	Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,		Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
	<https://www.rfc-editor.org/info/rfc6242>.		<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:
	Password-Based Cryptography Specification Version 2.1",
	RFC 8018, DOI 10.17487/RFC8018, January 2017,
	<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",		[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
	BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,		BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
	<https://www.rfc-editor.org/info/rfc8340>.		<https://www.rfc-editor.org/info/rfc8340>.
	[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,
End of changes. 29 change blocks.
	50 lines changed or deleted		57 lines changed or added
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/