draft-ietf-opsawg-service-assurance-yang-01.txt		draft-ietf-opsawg-service-assurance-yang-02.txt
	OPSAWG B. Claise		OPSAWG B. Claise
	Internet-Draft J. Quilbeuf		Internet-Draft J. Quilbeuf
	Intended status: Standards Track Huawei		Intended status: Standards Track Huawei
	Expires: January 3, 2022 P. Lucente		Expires: 8 July 2022 P. Lucente
	NTT		NTT
	P. Fasano		P. Fasano
	TIM S.p.A		TIM S.p.A
	T. Arumugam		T. Arumugam
	Cisco Systems, Inc.		Cisco Systems, Inc.
	July 2, 2021		4 January 2022
	YANG Modules for Service Assurance		YANG Modules for Service Assurance
	draft-ietf-opsawg-service-assurance-yang-01		draft-ietf-opsawg-service-assurance-yang-02
	Abstract		Abstract
	This document proposes YANG modules for the Service Assurance for		This document proposes YANG modules for the Service Assurance for
	Intent-based Networking Architecture.		Intent-based Networking Architecture.
	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.
	skipping to change at page 1, line 37 ¶		skipping to change at page 1, line 37 ¶
	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 January 3, 2022.		This Internet-Draft will expire on 8 July 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2022 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	(https://trustee.ietf.org/license-info) in effect on the date of		license-info) in effect on the date of publication of this document.
	publication of this document. Please review these documents		Please review these documents carefully, as they describe your rights
	carefully, as they describe your rights and restrictions with respect		and restrictions with respect to this document. Code Components
	to this document. Code Components extracted from this document must		extracted from this document must include Revised BSD License text as
	include Simplified BSD License text as described in Section 4.e of		described in Section 4.e of the Trust Legal Provisions and are
	the Trust Legal Provisions and are provided without warranty as		provided without warranty as described in the Revised BSD License.
	described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. YANG Models Overview . . . . . . . . . . . . . . . . . . . . 3		3. YANG Models Overview . . . . . . . . . . . . . . . . . . . . 3
	4. Base ietf-service-assurance YANG module . . . . . . . . . . . 4		4. Base ietf-service-assurance YANG module . . . . . . . . . . . 4
	4.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 4		4.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 4
	4.2. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 5		4.2. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 5
	4.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 7		4.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 7
	5. Subservice Extension: ietf-service-assurance-device YANG		5. Subservice Extension: ietf-service-assurance-device YANG
	module . . . . . . . . . . . . . . . . . . . . . . . . . . . 14		module . . . . . . . . . . . . . . . . . . . . . . . . . 14
	5.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 14		5.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 14
	5.2. Complete Tree View . . . . . . . . . . . . . . . . . . . 14		5.2. Complete Tree View . . . . . . . . . . . . . . . . . . . 15
	5.3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 15		5.3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 16
	5.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 16		5.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 16
	6. Subservice Extension: ietf-service-assurance-interface YANG		6. Subservice Extension: ietf-service-assurance-interface YANG
	module . . . . . . . . . . . . . . . . . . . . . . . . . . . 18		module . . . . . . . . . . . . . . . . . . . . . . . . . 18
	6.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 18		6.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 18
	6.2. Complete Tree View . . . . . . . . . . . . . . . . . . . 18		6.2. Complete Tree View . . . . . . . . . . . . . . . . . . . 18
	6.3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 19		6.3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 19
	6.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 20		6.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 20
	7. Vendor-specific Subservice Extension: example-service-		7. Vendor-specific Subservice Extension:
	assurance-device-acme YANG module . . . . . . . . . . . . . . 22		example-service-assurance-device-acme YANG module . . . . 22
	7.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 22		7.1. Tree View . . . . . . . . . . . . . . . . . . . . . . . . 22
	7.2. Complete Tree View . . . . . . . . . . . . . . . . . . . 22		7.2. Complete Tree View . . . . . . . . . . . . . . . . . . . 22
	7.3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 23		7.3. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 24
	7.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 24		7.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 24
	8. Further Extensions: IP Connectivity and IS-IS subservices . . 26		8. Further Extensions: IP Connectivity and IS-IS subservices . . 26
	8.1. IP Connectivity Tree View . . . . . . . . . . . . . . . . 26		8.1. IP Connectivity Tree View . . . . . . . . . . . . . . . . 26
	8.2. IS-IS Tree View . . . . . . . . . . . . . . . . . . . . . 26		8.2. IS-IS Tree View . . . . . . . . . . . . . . . . . . . . . 26
	8.3. Global Tree View . . . . . . . . . . . . . . . . . . . . 26		8.3. Global Tree View . . . . . . . . . . . . . . . . . . . . 27
	8.4. IP Connectivity YANG Module . . . . . . . . . . . . . . . 28		8.4. IP Connectivity YANG Module . . . . . . . . . . . . . . . 28
	8.5. IS-IS YANG Module . . . . . . . . . . . . . . . . . . . . 30		8.5. IS-IS YANG Module . . . . . . . . . . . . . . . . . . . . 30
	9. Guidelines for Specific Subservice Extension . . . . . . . . 31		9. Guidelines for Specific Subservice Extension . . . . . . . . 32
	9.1. Module Name . . . . . . . . . . . . . . . . . . . . . . . 32		9.1. Module Name . . . . . . . . . . . . . . . . . . . . . . . 32
	9.2. Module Namespace . . . . . . . . . . . . . . . . . . . . 32		9.2. Module Namespace . . . . . . . . . . . . . . . . . . . . 32
	9.3. Module Prefix . . . . . . . . . . . . . . . . . . . . . . 32		9.3. Module Prefix . . . . . . . . . . . . . . . . . . . . . . 33
	9.4. Subservice Specific Identity . . . . . . . . . . . . . . 33		9.4. Subservice Specific Identity . . . . . . . . . . . . . . 33
	9.5. Parameters . . . . . . . . . . . . . . . . . . . . . . . 33		9.5. Parameters . . . . . . . . . . . . . . . . . . . . . . . 33
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 33		10. Security Considerations . . . . . . . . . . . . . . . . . . . 33
	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34		11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
	11.1. The IETF XML Registry . . . . . . . . . . . . . . . . . 34		11.1. The IETF XML Registry . . . . . . . . . . . . . . . . . 34
	11.2. The YANG Module Names Registry . . . . . . . . . . . . . 34		11.2. The YANG Module Names Registry . . . . . . . . . . . . . 34
	12. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 35		12. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 35
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . 35		13. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
	13.1. Normative References . . . . . . . . . . . . . . . . . . 35		13.1. Normative References . . . . . . . . . . . . . . . . . . 35
	13.2. Informative References . . . . . . . . . . . . . . . . . 36		13.2. Informative References . . . . . . . . . . . . . . . . . 36
	Appendix A. Example of YANG instances . . . . . . . . . . . . . 36		Appendix A. Example of YANG instances . . . . . . . . . . . . . 36
	Appendix B. YANG Library for Service Assurance . . . . . . . . . 40		Appendix B. YANG Library for Service Assurance . . . . . . . . . 40
	skipping to change at page 3, line 33 ¶		skipping to change at page 3, line 39 ¶
	2. Introduction		2. Introduction
	The "Service Assurance for Intent-based Networking Architecture"		The "Service Assurance for Intent-based Networking Architecture"
	draft-ietf-opsawg-service-assurance-architecture, specifies the		draft-ietf-opsawg-service-assurance-architecture, specifies the
	architecture and all of its components for service assurance. This		architecture and all of its components for service assurance. This
	document complements the architecture by providing open interfaces		document complements the architecture by providing open interfaces
	between components. More specifically, the goal is to provide YANG		between components. More specifically, the goal is to provide YANG
	modules for the purpose of service assurance in a format that is:		modules for the purpose of service assurance in a format that is:
	o machine readable		* machine readable
	o vendor independent		* vendor independent
	o augmentable		* augmentable
	3. YANG Models Overview		3. YANG Models Overview
	The main YANG module, ietf-service-assurance, defines objects for		The main YANG module, ietf-service-assurance, defines objects for
	assuring network services based on their decomposition into so-called		assuring network services based on their decomposition into so-called
	subservices. The subservices are hierarchically organised by		subservices. The subservices are hierarchically organised by
	dependencies. The subservices, along with the dependencies,		dependencies. The subservices, along with the dependencies,
	constitute an assurance graph. This module should be supported by an		constitute an assurance graph. This module should be supported by an
	agent, able to interact with the devices in order to produce a health		agent, able to interact with the devices in order to produce a health
	status and symptoms for each subservice in the assurance graph. This		status and symptoms for each subservice in the assurance graph. This
	module is intended for the following use cases:		module is intended for the following use cases:
	o Assurance graph configuration:		* Assurance graph configuration:
	* Subservices: configure a set of subservices to assure, by		- Subservices: configure a set of subservices to assure, by
	specifying their types and parameters.		specifying their types and parameters.
	* Dependencies: configure the dependencies between the		- Dependencies: configure the dependencies between the
	subservices, along with their type.		subservices, along with their type.
	o Assurance telemetry: export the health status of the subservices,		* Assurance telemetry: export the health status of the subservices,
	along with the observed symptoms.		along with the observed symptoms.
	The second YANG module, ietf-service-assurance-device, extends the		The second YANG module, ietf-service-assurance-device, extends the
	ietf-service-assurance module to add support for the subservice		ietf-service-assurance module to add support for the subservice
	DeviceHealthy. Additional subservice types might be added the same		DeviceHealthy. Additional subservice types might be added the same
	way.		way.
	The third YANG module, ietf-service-assurance-device, is another		The third YANG module, ietf-service-assurance-device, is another
	example that extends the ietf-service-assurance-device module. This		example that extends the ietf-service-assurance-device module. This
	extension adds support for the subservice InterfaceHealthy.		extension adds support for the subservice InterfaceHealthy.
	skipping to change at page 5, line 21 ¶		skipping to change at page 5, line 21 ¶
	+--rw id string		+--rw id string
	+--ro last-change? yang:date-and-time		+--ro last-change? yang:date-and-time
	+--ro label? string		+--ro label? string
	+--rw under-maintenance? boolean		+--rw under-maintenance? boolean
	+--rw maintenance-contact string		+--rw maintenance-contact string
	+--rw (parameter)?		+--rw (parameter)?
	| +--:(service-instance-parameter)		| +--:(service-instance-parameter)
	| +--rw service-instance-parameter		| +--rw service-instance-parameter
	| +--rw service string		| +--rw service string
	| +--rw instance-name string		| +--rw instance-name string
	+--ro health-score? uint8		+--ro health-score? union
	+--ro symptoms-history-start? yang:date-and-time		+--ro symptoms-history-start? yang:date-and-time
	+--rw symptoms		+--rw symptoms
	| +--ro symptom* [start-date-time id]		| +--ro symptom* [start-date-time id]
	| +--ro id string		| +--ro id string
	| +--ro health-score-weight? uint8		| +--ro health-score-weight? uint8
	| +--ro description? string		| +--ro description? string
	| +--ro start-date-time yang:date-and-time		| +--ro start-date-time yang:date-and-time
	| +--ro stop-date-time? yang:date-and-time		| +--ro stop-date-time? yang:date-and-time
	+--rw dependencies		+--rw dependencies
	+--rw dependency* [type id]		+--rw dependency* [type id]
	skipping to change at page 5, line 43 ¶		skipping to change at page 5, line 43 ¶
	+--rw id -> /subservices/subservice[type=current()/../type]/id		+--rw id -> /subservices/subservice[type=current()/../type]/id
	+--rw dependency-type? identityref		+--rw dependency-type? identityref
	4.2. Concepts		4.2. Concepts
	The ietf-service-assurance YANG model assumes an identified number of		The ietf-service-assurance YANG model assumes an identified number of
	subservices, to be assured independently. A subservice is a feature		subservices, to be assured independently. A subservice is a feature
	or a subpart of the network system that a given service instance		or a subpart of the network system that a given service instance
	might depend on. Example of subservices include:		might depend on. Example of subservices include:
	o DeviceHealthy: whether a device is healthy, and if not, what are		* DeviceHealthy: whether a device is healthy, and if not, what are
	the symptoms. Potential symptoms are "CPU overloaded", "Out of		the symptoms. Potential symptoms are "CPU overloaded", "Out of
	RAM", or "Out of TCAM".		RAM", or "Out of TCAM".
	o ConnectivityHealthy: given two IP addresses owned by two devices,		* ConnectivityHealthy: given two IP addresses owned by two devices,
	what is the quality of the connection between them. Potential		what is the quality of the connection between them. Potential
	symptoms are "No route available" or "ECMP Imbalance".		symptoms are "No route available" or "ECMP Imbalance".
	The first example is a subservice representing a subpart of the		The first example is a subservice representing a subpart of the
	network system, while the second is a subservice representing a		network system, while the second is a subservice representing a
	feature of the network, In both cases, these subservices might depend		feature of the network, In both cases, these subservices might depend
	on other subservices, for instance, the connectivity might depend on		on other subservices, for instance, the connectivity might depend on
	a subservice representing the routing mechanism and on a subservice		a subservice representing the routing mechanism and on a subservice
	representing ECMP.		representing ECMP.
	skipping to change at page 6, line 26 ¶		skipping to change at page 6, line 26 ¶
	which the symptom was detected and stopped being detected. While the		which the symptom was detected and stopped being detected. While the
	unique id is sufficient as an unique key list, the start-date-time		unique id is sufficient as an unique key list, the start-date-time
	second key help sorting and retrieving relevant symptoms.		second key help sorting and retrieving relevant symptoms.
	The assurance of a given service instance can be obtained by		The assurance of a given service instance can be obtained by
	composing the assurance of the subservices that it depends on, via		composing the assurance of the subservices that it depends on, via
	the dependency relations.		the dependency relations.
	A subservice declaration MUST provide:		A subservice declaration MUST provide:
	o A type: identity inheriting of the base identity for subservice,		* A type: identity inheriting of the base identity for subservice,
	o An id: string uniquely identifying the subservice among those with		* An id: string uniquely identifying the subservice among those with
	the same identity,		the same identity,
	o One or more parameters, which should be specified in an augmenting		* One or more parameters, which should be specified in an augmenting
	model, as described in the next sections.		model, as described in the next sections.
	The type and id uniquely identify a given subservice. They are used		The type and id uniquely identify a given subservice. They are used
	to indicate the dependencies. Dependencies have types as well. Two		to indicate the dependencies. Dependencies have types as well. Two
	types are specified in the model:		types are specified in the model:
	o Impacting: such a dependency indicates an impact on the health of		* Impacting: such a dependency indicates an impact on the health of
	the dependent,		the dependent,
	o Informational: such a dependency might explain why the dependent		* Informational: such a dependency might explain why the dependent
	has issues but does not impact its health.		has issues but does not impact its health.
	To illustrate the difference between "impacting" and "informational",		To illustrate the difference between "impacting" and "informational",
	consider the subservice InterfaceHealthy, representing a network		consider the subservice InterfaceHealthy, representing a network
	interface. If the device to which the network interface belongs goes		interface. If the device to which the network interface belongs goes
	down, the network interface will transition to a down state as well.		down, the network interface will transition to a down state as well.
	Therefore, the dependency of InterfaceHealthy towards DeviceHealthy		Therefore, the dependency of InterfaceHealthy towards DeviceHealthy
	is "impacting". On the other hand, as a the dependency towards the		is "impacting". On the other hand, as a the dependency towards the
	ECMPLoad subservice, which checks that the load between ECMP remains		ECMPLoad subservice, which checks that the load between ECMP remains
	ce remains stable throughout time, is only "informational". Indeed,		ce remains stable throughout time, is only "informational". Indeed,
	skipping to change at page 7, line 29 ¶		skipping to change at page 7, line 39 ¶
	By specifying service instances and their dependencies in terms of		By specifying service instances and their dependencies in terms of
	subservices, one defines the whole assurance to apply for them. An		subservices, one defines the whole assurance to apply for them. An
	assurance agent supporting this model should then produce telemetry		assurance agent supporting this model should then produce telemetry
	in return with, for each subservice: a health-status indicating how		in return with, for each subservice: a health-status indicating how
	healthy the subservice is and when the subservice is not healthy, a		healthy the subservice is and when the subservice is not healthy, a
	list of symptoms explaining why the subservice is not healthy.		list of symptoms explaining why the subservice is not healthy.
	4.3. YANG Module		4.3. YANG Module
	<CODE BEGINS> file "ietf-service-assurance@2021-06-28.yang"		<CODE BEGINS> file "ietf-service-assurance@2022-01-04.yang"
	module ietf-service-assurance {		module ietf-service-assurance {
	yang-version 1.1;		yang-version 1.1;
	namespace "urn:ietf:params:xml:ns:yang:ietf-service-assurance";		namespace "urn:ietf:params:xml:ns:yang:ietf-service-assurance";
	prefix service-assurance;		prefix service-assurance;
	import ietf-yang-types {		import ietf-yang-types {
	prefix yang;		prefix yang;
	}		}
	skipping to change at page 8, line 42 ¶		skipping to change at page 8, line 50 ¶
	set forth in Section 4.c of the IETF Trust's Legal Provisions		set forth in Section 4.c of the IETF Trust's Legal Provisions
	Relating to IETF Documents		Relating to IETF Documents
	(https://trustee.ietf.org/license-info).		(https://trustee.ietf.org/license-info).
	This version of this YANG module is part of RFC XXXX; see the		This version of this YANG module is part of RFC XXXX; see the
	RFC itself for full legal notices.		RFC itself for full legal notices.
	TO DO:		TO DO:
	- Better type (IETF or OC) for device-id, interface-id, etc.		- Better type (IETF or OC) for device-id, interface-id, etc.
	- Have a YANG module for IETF and one for OC?";		- Have a YANG module for IETF and one for OC?";
			revision 2022-01-04 {
			description
			"Explicitely model a missing value";
			reference
			"RFC xxxx: Title to be completed";
			}
	revision 2021-06-28 {		revision 2021-06-28 {
	description		description
	"Made service-instance parameters mandatory.";		"Made service-instance parameters mandatory.";
	reference		reference
	"RFC xxxx: Title to be completed";		"RFC xxxx: Title to be completed";
	}		}
	revision 2020-01-13 {		revision 2020-01-13 {
	description		description
	"Added the maintenance window concept.";		"Added the maintenance window concept.";
	reference		reference
	skipping to change at page 11, line 12 ¶		skipping to change at page 11, line 28 ¶
	base dependency-type;		base dependency-type;
	}		}
	description		description
	"Represents the type of dependency (i.e. informational, impacting).";		"Represents the type of dependency (i.e. informational, impacting).";
	}		}
	// augment here if more info are needed (i.e. a percentage) depending on the dependency type.		// augment here if more info are needed (i.e. a percentage) depending on the dependency type.
	}		}
	leaf assurance-graph-version {		leaf assurance-graph-version {
	type yang:counter32;		type yang:counter32;
	mandatory true;
	config false;		config false;
			mandatory true;
	description		description
	"The assurance graph version, which increases by 1 for each new version, after the changes		"The assurance graph version, which increases by 1 for each new version, after the changes
	(dependencies and/or maintenance windows parameters) are applied to the subservice(s).";		(dependencies and/or maintenance windows parameters) are applied to the subservice(s).";
	}		}
	leaf assurance-graph-last-change {		leaf assurance-graph-last-change {
	type yang:date-and-time;		type yang:date-and-time;
	mandatory true;
	config false;		config false;
			mandatory true;
	description		description
	"Date and time at which the assurance graph last changed after the changes (dependencies		"Date and time at which the assurance graph last changed after the changes (dependencies
	and/or maintenance windows parameters) are applied to the subservice(s). These date and time		and/or maintenance windows parameters) are applied to the subservice(s). These date and time
	must be more recent or equal compared to the more recent value of any changed subservices		must be more recent or equal compared to the more recent value of any changed subservices
	last-change";		last-change";
	}		}
	container subservices {		container subservices {
	description		description
	"Root container for the subservices.";		"Root container for the subservices.";
	list subservice {		list subservice {
	skipping to change at page 13, line 19 ¶		skipping to change at page 13, line 34 ¶
	leaf instance-name {		leaf instance-name {
	type string;		type string;
	mandatory true;		mandatory true;
	description		description
	"Name of the instance for that service.";		"Name of the instance for that service.";
	}		}
	}		}
	// Other modules can augment their own cases into here		// Other modules can augment their own cases into here
	}		}
	leaf health-score {		leaf health-score {
	type uint8 {		type union {
	range "0 .. 100";		type uint8 {
			range "0 .. 100";
			}
			type enumeration {
			enum missing {
			value -1;
			description
			"Explictly represent the fact that the health score is
			missing. This could be used when metrics crucial to
			establish the health score are not collected anymore.";
			}
			}
	}		}
	config false;		config false;
	description		description
	"Score value of the subservice health. A value of 100 means that		"Score value of the subservice health. A value of 100 means that
	subservice is healthy. A value of 0 means that the subservice is		subservice is healthy. A value of 0 means that the subservice is
	broken. A value between 0 and 100 means that the subservice is		broken. A value between 0 and 100 means that the subservice is
	degraded.";		degraded.";
	}		}
	leaf symptoms-history-start {		leaf symptoms-history-start {
	type yang:date-and-time;		type yang:date-and-time;
	skipping to change at page 15, line 24 ¶		skipping to change at page 15, line 35 ¶
	+--rw under-maintenance? boolean		+--rw under-maintenance? boolean
	+--rw maintenance-contact string		+--rw maintenance-contact string
	+--rw (parameter)?		+--rw (parameter)?
	| +--:(service-instance-parameter)		| +--:(service-instance-parameter)
	| | +--rw service-instance-parameter		| | +--rw service-instance-parameter
	| | +--rw service string		| | +--rw service string
	| | +--rw instance-name string		| | +--rw instance-name string
	| +--:(service-assurance-device:parameters)		| +--:(service-assurance-device:parameters)
	| +--rw service-assurance-device:parameters		| +--rw service-assurance-device:parameters
	| +--rw service-assurance-device:device string		| +--rw service-assurance-device:device string
	+--ro health-score? uint8		+--ro health-score? union
	+--ro symptoms-history-start? yang:date-and-time		+--ro symptoms-history-start? yang:date-and-time
	+--rw symptoms		+--rw symptoms
	| +--ro symptom* [start-date-time id]		| +--ro symptom* [start-date-time id]
	| +--ro id string		| +--ro id string
	| +--ro health-score-weight? uint8		| +--ro health-score-weight? uint8
	| +--ro description? string		| +--ro description? string
	| +--ro start-date-time yang:date-and-time		| +--ro start-date-time yang:date-and-time
	| +--ro stop-date-time? yang:date-and-time		| +--ro stop-date-time? yang:date-and-time
	+--rw dependencies		+--rw dependencies
	+--rw dependency* [type id]		+--rw dependency* [type id]
	skipping to change at page 19, line 28 ¶		skipping to change at page 19, line 28 ¶
	| | +--rw service-instance-parameter		| | +--rw service-instance-parameter
	| | +--rw service string		| | +--rw service string
	| | +--rw instance-name string		| | +--rw instance-name string
	| +--:(service-assurance-interface:parameters)		| +--:(service-assurance-interface:parameters)
	| | +--rw service-assurance-interface:parameters		| | +--rw service-assurance-interface:parameters
	| | +--rw service-assurance-interface:device string		| | +--rw service-assurance-interface:device string
	| | +--rw service-assurance-interface:interface string		| | +--rw service-assurance-interface:interface string
	| +--:(service-assurance-device:parameters)		| +--:(service-assurance-device:parameters)
	| +--rw service-assurance-device:parameters		| +--rw service-assurance-device:parameters
	| +--rw service-assurance-device:device string		| +--rw service-assurance-device:device string
	+--ro health-score? uint8		+--ro health-score? union
	+--ro symptoms-history-start? yang:date-and-time		+--ro symptoms-history-start? yang:date-and-time
	+--rw symptoms		+--rw symptoms
	| +--ro symptom* [start-date-time id]		| +--ro symptom* [start-date-time id]
	| +--ro id string		| +--ro id string
	| +--ro health-score-weight? uint8		| +--ro health-score-weight? uint8
	| +--ro description? string		| +--ro description? string
	| +--ro start-date-time yang:date-and-time		| +--ro start-date-time yang:date-and-time
	| +--ro stop-date-time? yang:date-and-time		| +--ro stop-date-time? yang:date-and-time
	+--rw dependencies		+--rw dependencies
	+--rw dependency* [type id]		+--rw dependency* [type id]
	skipping to change at page 23, line 32 ¶		skipping to change at page 23, line 32 ¶
	| | +--rw service-assurance-device:parameters		| | +--rw service-assurance-device:parameters
	| | +--rw service-assurance-device:device string		| | +--rw service-assurance-device:device string
	| +--:(example-service-assurance-device-acme:parameters)		| +--:(example-service-assurance-device-acme:parameters)
	| | +--rw example-service-assurance-device-acme:parameters		| | +--rw example-service-assurance-device-acme:parameters
	| | +--rw example-service-assurance-device-acme:device string		| | +--rw example-service-assurance-device-acme:device string
	| | +--rw example-service-assurance-device-acme:acme-specific-parameter string		| | +--rw example-service-assurance-device-acme:acme-specific-parameter string
	| +--:(service-assurance-interface:parameters)		| +--:(service-assurance-interface:parameters)
	| +--rw service-assurance-interface:parameters		| +--rw service-assurance-interface:parameters
	| +--rw service-assurance-interface:device string		| +--rw service-assurance-interface:device string
	| +--rw service-assurance-interface:interface string		| +--rw service-assurance-interface:interface string
	+--ro health-score? uint8		+--ro health-score? union
	+--ro symptoms-history-start? yang:date-and-time		+--ro symptoms-history-start? yang:date-and-time
	+--rw symptoms		+--rw symptoms
	| +--ro symptom* [start-date-time id]		| +--ro symptom* [start-date-time id]
	| +--ro id string		| +--ro id string
	| +--ro health-score-weight? uint8		| +--ro health-score-weight? uint8
	| +--ro description? string		| +--ro description? string
	| +--ro start-date-time yang:date-and-time		| +--ro start-date-time yang:date-and-time
	| +--ro stop-date-time? yang:date-and-time		| +--ro stop-date-time? yang:date-and-time
	+--rw dependencies		+--rw dependencies
	+--rw dependency* [type id]		+--rw dependency* [type id]
	skipping to change at page 27, line 39 ¶		skipping to change at page 27, line 48 ¶
	| | +--rw service-assurance-device:parameters		| | +--rw service-assurance-device:parameters
	| | +--rw service-assurance-device:device string		| | +--rw service-assurance-device:device string
	| +--:(example-service-assurance-device-acme:parameters)		| +--:(example-service-assurance-device-acme:parameters)
	| | +--rw example-service-assurance-device-acme:parameters		| | +--rw example-service-assurance-device-acme:parameters
	| | +--rw example-service-assurance-device-acme:device string		| | +--rw example-service-assurance-device-acme:device string
	| | +--rw example-service-assurance-device-acme:acme-specific-parameter string		| | +--rw example-service-assurance-device-acme:acme-specific-parameter string
	| +--:(service-assurance-interface:parameters)		| +--:(service-assurance-interface:parameters)
	| +--rw service-assurance-interface:parameters		| +--rw service-assurance-interface:parameters
	| +--rw service-assurance-interface:device string		| +--rw service-assurance-interface:device string
	| +--rw service-assurance-interface:interface string		| +--rw service-assurance-interface:interface string
	+--ro health-score? uint8		+--ro health-score? union
	+--ro symptoms-history-start? yang:date-and-time		+--ro symptoms-history-start? yang:date-and-time
	+--rw symptoms		+--rw symptoms
	| +--ro symptom* [start-date-time id]		| +--ro symptom* [start-date-time id]
	| +--ro id string		| +--ro id string
	| +--ro health-score-weight? uint8		| +--ro health-score-weight? uint8
	| +--ro description? string		| +--ro description? string
	| +--ro start-date-time yang:date-and-time		| +--ro start-date-time yang:date-and-time
	| +--ro stop-date-time? yang:date-and-time		| +--ro stop-date-time? yang:date-and-time
	+--rw dependencies		+--rw dependencies
	+--rw dependency* [type id]		+--rw dependency* [type id]
	skipping to change at page 34, line 7 ¶		skipping to change at page 34, line 18 ¶
	RESTCONF protocol operations and content.		RESTCONF protocol operations and content.
	There are a number of data nodes defined in this YANG module that are		There are a number of data nodes defined in this YANG module that are
	writable/ creatable/deletable (i.e., config true, which is the		writable/ creatable/deletable (i.e., config true, which is the
	default). These data nodes may be considered sensitive or vulnerable		default). These data nodes may be considered sensitive or vulnerable
	in some network environments. Write operations (e.g., edit-config)		in some network environments. Write operations (e.g., edit-config)
	to these data nodes without proper protection can have a negative		to these data nodes without proper protection can have a negative
	effect on network operations. These are the subtrees and data nodes		effect on network operations. These are the subtrees and data nodes
	and their sensitivity/vulnerability:		and their sensitivity/vulnerability:
	o /subservices/subservice/type		* /subservices/subservice/type
	o /subservices/subservice/id		* /subservices/subservice/id
	o /subservices/subservice/under-maintenance		* /subservices/subservice/under-maintenance
	o /subservices/subservice/maintenance-contact		* /subservices/subservice/maintenance-contact
	11. IANA Considerations		11. IANA Considerations
	11.1. The IETF XML Registry		11.1. The IETF XML Registry
	This document registers two URIs in the IETF XML registry [RFC3688].		This document registers two URIs in the IETF XML registry [RFC3688].
	Following the format in [RFC3688], the following registrations are		Following the format in [RFC3688], the following registrations are
	requested:		requested:
	URI: urn:ietf:params:xml:ns:yang:ietf-service-assurance		URI: urn:ietf:params:xml:ns:yang:ietf-service-assurance
	skipping to change at page 35, line 29 ¶		skipping to change at page 35, line 29 ¶
	12. Open Issues		12. Open Issues
	-None		-None
	13. References		13. References
	13.1. Normative References		13.1. Normative References
	[I-D.ietf-opsawg-service-assurance-architecture]		[I-D.ietf-opsawg-service-assurance-architecture]
	Claise, B., Quilbeuf, J., Lopez, D., Voyer, D., and T.		Claise, B.C., Quilbeuf, J.Q., Lopez, D.L., Voyer, D.V.,
	Arumugam, "draft-claise-opsawg-service-assurance-		and T.A. Arumugam, "draft-claise-opsawg-service-assurance-
	architecture", 2020.		architecture", 2020.
	[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		[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>.
	skipping to change at page 36, line 37 ¶		skipping to change at page 36, line 37 ¶
	<https://www.rfc-editor.org/info/rfc7895>.		<https://www.rfc-editor.org/info/rfc7895>.
	[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>.
	[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>.
	13.3. URIs
	[1] https://yangson.labs.nic.cz/
	Appendix A. Example of YANG instances		Appendix A. Example of YANG instances
	This section contains examples of YANG instances that conform to the		This section contains examples of YANG instances that conform to the
	YANG modules. The validity of these data instances has been checked		YANG modules. The validity of these data instances has been checked
	using yangson [1]. Yangson requires a YANG library [RFC7895] to		using yangson (https://yangson.labs.nic.cz/). Yangson requires a
	define the complete model against which the data instance must be		YANG library [RFC7895] to define the complete model against which the
	validated. We provide in Appendix B the JSON library file, named		data instance must be validated. We provide in Appendix B the JSON
	"ietf-service-assurance-library.json", that we used for validation.		library file, named "ietf-service-assurance-library.json", that we
			used for validation.
	We provide below the contents of the file		We provide below the contents of the file
	"example_configuration_instance.json" which contains the		"example_configuration_instance.json" which contains the
	configuration data that models the Figure 2 of		configuration data that models the Figure 2 of
	[I-D.ietf-opsawg-service-assurance-architecture]. The instance can		[I-D.ietf-opsawg-service-assurance-architecture]. The instance can
	be validated with yangson by using the invocation "yangson -v		be validated with yangson by using the invocation "yangson -v
	example_configuration_instance.json ietf-service-assurance-		example_configuration_instance.json ietf-service-assurance-
	library.json", assuming all the files (YANG and JSON) defined in this		library.json", assuming all the files (YANG and JSON) defined in this
	draft reside in the current folder.		draft reside in the current folder.
	<CODE BEGINS> file "example_configuration_instance.json"		<CODE BEGINS> file "example_configuration_instance.json"
	{		{
	"ietf-service-assurance:subservices": {		"ietf-service-assurance:subservices": {
	skipping to change at page 41, line 46 ¶		skipping to change at page 41, line 48 ¶
	]		]
	}		}
	}		}
	<CODE ENDS>		<CODE ENDS>
	Appendix C. Changes between revisions		Appendix C. Changes between revisions
	v00 - v01		v00 - v01
	o Added needed subservice to model example from architecture draft		* Added needed subservice to model example from architecture draft
	o Added guideline section for naming models		* Added guideline section for naming models
			* Added data instance examples and validation procedure
	o Added data instance examples and validation procedure		* Added the "parameters" container in the interface YANG module to
	o Added the "parameters" container in the interface YANG module to
	correct a bug.		correct a bug.
	Acknowledgements		Acknowledgements
	The authors would like to thank Jan Lindblad for his help during the		The authors would like to thank Jan Lindblad for his help during the
	design of these YANG modules. The authors would like to thank		design of these YANG modules. The authors would like to thank
	Stephane Litkowski and Charles Eckel for their reviews.		Stephane Litkowski and Charles Eckel for their reviews.
	Authors' Addresses		Authors' Addresses
	skipping to change at page 42, line 28 ¶		skipping to change at page 42, line 30 ¶
	Email: benoit.claise@huawei.com		Email: benoit.claise@huawei.com
	Jean Quilbeuf		Jean Quilbeuf
	Huawei		Huawei
	Email: jean.quilbeuf@huawei.com		Email: jean.quilbeuf@huawei.com
	Paolo Lucente		Paolo Lucente
	NTT		NTT
	Siriusdreef 70-72		Siriusdreef 70-72
	Hoofddorp, WT 2132		2132 Hoofddorp
	Netherlands		Netherlands
	Email: paolo@ntt.net		Email: paolo@ntt.net
	Paolo Fasano		Paolo Fasano
	TIM S.p.A		TIM S.p.A
	via G. Reiss Romoli, 274		via G. Reiss Romoli, 274
	10148 Torino		10148 Torino
	Italy		Italy
	Email: paolo2.fasano@telecomitalia.it		Email: paolo2.fasano@telecomitalia.it
	Thangam Arumugam		Thangam Arumugam
	Cisco Systems, Inc.		Cisco Systems, Inc.
	Milpitas (California)		Milpitas (California),
	United States		United States
	Email: tarumuga@cisco.com		Email: tarumuga@cisco.com
End of changes. 55 change blocks.
	69 lines changed or deleted		81 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/