draft-ietf-netmod-revised-datastores-09.txt		draft-ietf-netmod-revised-datastores-10.txt
	Network Working Group M. Bjorklund		Network Working Group M. Bjorklund
	Internet-Draft Tail-f Systems		Internet-Draft Tail-f Systems
	Updates: 7950 (if approved) J. Schoenwaelder		Updates: 7950 (if approved) J. Schoenwaelder
	Intended status: Standards Track Jacobs University		Intended status: Standards Track Jacobs University
	Expires: June 23, 2018 P. Shafer		Expires: July 17, 2018 P. Shafer
	K. Watsen		K. Watsen
	Juniper Networks		Juniper Networks
	R. Wilton		R. Wilton
	Cisco Systems		Cisco Systems
	December 20, 2017		January 13, 2018
	Network Management Datastore Architecture		Network Management Datastore Architecture
	draft-ietf-netmod-revised-datastores-09		draft-ietf-netmod-revised-datastores-10
	Abstract		Abstract
	Datastores are a fundamental concept binding the data models written		Datastores are a fundamental concept binding the data models written
	in the YANG data modeling language to network management protocols		in the YANG data modeling language to network management protocols
	such as NETCONF and RESTCONF. This document defines an architectural		such as NETCONF and RESTCONF. This document defines an architectural
	framework for datastores based on the experience gained with the		framework for datastores based on the experience gained with the
	initial simpler model, addressing requirements that were not well		initial simpler model, addressing requirements that were not well
	supported in the initial model. This document updates RFC 7950.		supported in the initial model. This document updates RFC 7950.
	skipping to change at page 1, line 41 ¶		skipping to change at page 1, line 41 ¶
	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 http://datatracker.ietf.org/drafts/current/.		Drafts is at http://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 June 23, 2018.		This Internet-Draft will expire on July 17, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 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
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://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
	skipping to change at page 2, line 39 ¶		skipping to change at page 2, line 39 ¶
	5.3.3. System-controlled Resources . . . . . . . . . . . . . 15		5.3.3. System-controlled Resources . . . . . . . . . . . . . 15
	5.3.4. Origin Metadata Annotation . . . . . . . . . . . . . 15		5.3.4. Origin Metadata Annotation . . . . . . . . . . . . . 15
	6. Implications on YANG . . . . . . . . . . . . . . . . . . . . 17		6. Implications on YANG . . . . . . . . . . . . . . . . . . . . 17
	6.1. XPath Context . . . . . . . . . . . . . . . . . . . . . . 17		6.1. XPath Context . . . . . . . . . . . . . . . . . . . . . . 17
	6.2. Invocation of Actions and RPCs . . . . . . . . . . . . . 18		6.2. Invocation of Actions and RPCs . . . . . . . . . . . . . 18
	7. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 18		7. YANG Modules . . . . . . . . . . . . . . . . . . . . . . . . 18
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
	8.1. Updates to the IETF XML Registry . . . . . . . . . . . . 24		8.1. Updates to the IETF XML Registry . . . . . . . . . . . . 24
	8.2. Updates to the YANG Module Names Registry . . . . . . . . 24		8.2. Updates to the YANG Module Names Registry . . . . . . . . 24
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 24		9. Security Considerations . . . . . . . . . . . . . . . . . . . 24
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24		10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 25		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
	11.1. Normative References . . . . . . . . . . . . . . . . . . 25		11.1. Normative References . . . . . . . . . . . . . . . . . . 26
	11.2. Informative References . . . . . . . . . . . . . . . . . 26		11.2. Informative References . . . . . . . . . . . . . . . . . 26
	Appendix A. Guidelines for Defining Datastores . . . . . . . . . 27		Appendix A. Guidelines for Defining Datastores . . . . . . . . . 27
	A.1. Define which YANG modules can be used in the datastore . 27		A.1. Define which YANG modules can be used in the datastore . 27
	A.2. Define which subset of YANG-modeled data applies . . . . 27		A.2. Define which subset of YANG-modeled data applies . . . . 28
	A.3. Define how data is actualized . . . . . . . . . . . . . . 27		A.3. Define how data is actualized . . . . . . . . . . . . . . 28
	A.4. Define which protocols can be used . . . . . . . . . . . 28		A.4. Define which protocols can be used . . . . . . . . . . . 28
	A.5. Define YANG identities for the datastore . . . . . . . . 28		A.5. Define YANG identities for the datastore . . . . . . . . 28
	Appendix B. Ephemeral Dynamic Configuration Datastore Example . 28		Appendix B. Ephemeral Dynamic Configuration Datastore Example . 29
	Appendix C. Example Data . . . . . . . . . . . . . . . . . . . . 29		Appendix C. Example Data . . . . . . . . . . . . . . . . . . . . 30
	C.1. System Example . . . . . . . . . . . . . . . . . . . . . 30		C.1. System Example . . . . . . . . . . . . . . . . . . . . . 30
	C.2. BGP Example . . . . . . . . . . . . . . . . . . . . . . . 32		C.2. BGP Example . . . . . . . . . . . . . . . . . . . . . . . 33
	C.2.1. Datastores . . . . . . . . . . . . . . . . . . . . . 34		C.2.1. Datastores . . . . . . . . . . . . . . . . . . . . . 35
	C.2.2. Adding a Peer . . . . . . . . . . . . . . . . . . . . 34		C.2.2. Adding a Peer . . . . . . . . . . . . . . . . . . . . 35
	C.2.3. Removing a Peer . . . . . . . . . . . . . . . . . . . 35		C.2.3. Removing a Peer . . . . . . . . . . . . . . . . . . . 36
	C.3. Interface Example . . . . . . . . . . . . . . . . . . . . 36		C.3. Interface Example . . . . . . . . . . . . . . . . . . . . 37
	C.3.1. Pre-provisioned Interfaces . . . . . . . . . . . . . 36		C.3.1. Pre-provisioned Interfaces . . . . . . . . . . . . . 37
	C.3.2. System-provided Interface . . . . . . . . . . . . . . 37		C.3.2. System-provided Interface . . . . . . . . . . . . . . 38
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
	1. Introduction		1. Introduction
	This document provides an architectural framework for datastores as		This document provides an architectural framework for datastores as
	they are used by network management protocols such as NETCONF		they are used by network management protocols such as NETCONF
	[RFC6241], RESTCONF [RFC8040] and the YANG [RFC7950] data modeling		[RFC6241], RESTCONF [RFC8040] and the YANG [RFC7950] data modeling
	language. Datastores are a fundamental concept binding network		language. Datastores are a fundamental concept binding network
	management data models to network management protocols. Agreement on		management data models to network management protocols. Agreement on
	a common architectural model of datastores ensures that data models		a common architectural model of datastores ensures that data models
	can be written in a network management protocol agnostic way. This		can be written in a network management protocol agnostic way. This
	architectural framework identifies a set of conceptual datastores but		architectural framework identifies a set of conceptual datastores but
	it does not mandate that all network management protocols expose all		it does not mandate that all network management protocols expose all
	these conceptual datastores. This architecture is agnostic with		these conceptual datastores. This architecture is agnostic with
	regard to the encoding used by network management protocols.		regard to the encoding used by network management protocols.
			This document updates RFC 7950 by refining the definition of the
			accessible tree for some XPath context (see Section 6.1) and the
			invocation context of operations (see Section 6.2).
	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.
	2. Objectives		2. Objectives
	Network management data objects can often take two different values,		Network management data objects can often take two different values,
	the value configured by the user or an application (configuration)		the value configured by the user or an application (configuration)
	skipping to change at page 4, line 16 ¶		skipping to change at page 4, line 20 ¶
	operational state data from configuration data leads to a number of		operational state data from configuration data leads to a number of
	problems. Having configuration and operational state data in		problems. Having configuration and operational state data in
	separate branches in the data model is operationally complicated and		separate branches in the data model is operationally complicated and
	impacts the readability of module definitions. Furthermore, the		impacts the readability of module definitions. Furthermore, the
	relationship between the branches is not machine readable and filter		relationship between the branches is not machine readable and filter
	expressions operating on configuration and on related operational		expressions operating on configuration and on related operational
	state are different.		state are different.
	With the revised architectural model of datastores defined in this		With the revised architectural model of datastores defined in this
	document, the data objects are defined only once in the YANG schema		document, the data objects are defined only once in the YANG schema
	but independent instantiations can appear in two different		but independent instantiations can appear in different datastores,
	datastores, one for configured values and one for operational state		e.g., one for a configured value and another for an operationally
	values. This provides a more elegant and simpler solution to the		used value. This provides a more elegant and simpler solution to the
	problem.		problem.
	The revised architectural model of datastores supports additional		The revised architectural model of datastores supports additional
	datastores for systems that support more advanced processing chains		datastores for systems that support more advanced processing chains
	converting configuration to operational state. For example, some		converting configuration to operational state. For example, some
	systems support configuration that is not currently used (so called		systems support configuration that is not currently used (so called
	inactive configuration) or they support configuration templates that		inactive configuration) or they support configuration templates that
	are used to expand configuration data via a common template.		are used to expand configuration data via a common template.
	3. Terminology		3. Terminology
	skipping to change at page 7, line 50 ¶		skipping to change at page 8, line 4 ¶
	[RFC6244] defined operational state data as follows:		[RFC6244] defined operational state data as follows:
	o Operational state data is a set of data that has been obtained by		o Operational state data is a set of data that has been obtained by
	the system at runtime and influences the system's behavior similar		the system at runtime and influences the system's behavior similar
	to configuration data. In contrast to configuration data,		to configuration data. In contrast to configuration data,
	operational state is transient and modified by interactions with		operational state is transient and modified by interactions with
	internal components or other systems via specialized protocols.		internal components or other systems via specialized protocols.
	Section 4.3.3 of [RFC6244] discusses operational state and among		Section 4.3.3 of [RFC6244] discusses operational state and among
	other things mentions the option to consider operational state as		other things mentions the option to consider operational state as
	being stored in another datastore. Section 4.4 of this document then		being stored in another datastore. Section 4.4 of [RFC6244] then
	concludes that at the time of the writing, modeling state as distinct		concludes that at the time of the writing, modeling state as distinct
	leafs and distinct branches is the recommended approach.		leafs and distinct branches is the recommended approach.
	Implementation experience and requests from operators		Implementation experience and requests from operators
	[I-D.ietf-netmod-opstate-reqs], [I-D.openconfig-netmod-opstate]		[I-D.ietf-netmod-opstate-reqs], [I-D.openconfig-netmod-opstate]
	indicate that the datastore model initially designed for NETCONF and		indicate that the datastore model initially designed for NETCONF and
	refined by YANG needs to be extended. In particular, the notion of		refined by YANG needs to be extended. In particular, the notion of
	intended configuration and applied configuration has developed.		intended configuration and applied configuration has developed.
	4.1. Original Model of Datastores		4.1. Original Model of Datastores
	skipping to change at page 12, line 10 ¶		skipping to change at page 12, line 10 ¶
	protocols or implementations.		protocols or implementations.
	<candidate> does not typically persist across reboots, even in the		<candidate> does not typically persist across reboots, even in the
	presence of non-volatile storage. If <candidate> is stored using		presence of non-volatile storage. If <candidate> is stored using
	non-volatile storage, it is reset at boot time to the contents of		non-volatile storage, it is reset at boot time to the contents of
	<running>.		<running>.
	5.1.3. The Running Configuration Datastore (<running>)		5.1.3. The Running Configuration Datastore (<running>)
	The running configuration datastore (<running>) is a configuration		The running configuration datastore (<running>) is a configuration
	datastore that holds the complete current configuration on the		datastore that holds the current configuration of the device. It MAY
	device. It MAY include configuration that requires further		include configuration that requires further transformation before it
	transformation before it can be applied, e.g., inactive		can be applied, e.g., inactive configuration, or template-mechanism-
	configuration, or template-mechanism-oriented configuration that		oriented configuration that needs further expansion. However,
	needs further expansion. However, <running> MUST always be a valid		<running> MUST always be a valid configuration data tree, as defined
	configuration data tree, as defined in Section 8.1 of [RFC7950].		in Section 8.1 of [RFC7950].
	<running> MUST be supported if the device can be configured via		<running> MUST be supported if the device can be configured via
	conventional configuration datastores.		conventional configuration datastores.
	If a device does not have a distinct <startup> and non-volatile		If a device does not have a distinct <startup> and non-volatile
	storage is available, the device will typically use that non-volatile		storage is available, the device will typically use that non-volatile
	storage to allow <running> to persist across reboots.		storage to allow <running> to persist across reboots.
	5.1.4. The Intended Configuration Datastore (<intended>)		5.1.4. The Intended Configuration Datastore (<intended>)
	skipping to change at page 18, line 19 ¶		skipping to change at page 18, line 19 ¶
	Actions are always invoked in the context of the operational state		Actions are always invoked in the context of the operational state
	datastore. The node for which the action is invoked MUST exist in		datastore. The node for which the action is invoked MUST exist in
	the operational state datastore.		the operational state datastore.
	Note that this document does not constrain the result of invoking an		Note that this document does not constrain the result of invoking an
	RPC or action in any way. For example, an RPC might be defined to		RPC or action in any way. For example, an RPC might be defined to
	modify the contents of some datastore.		modify the contents of some datastore.
	7. YANG Modules		7. YANG Modules
	<CODE BEGINS> file "ietf-datastores@2017-12-20.yang"		<CODE BEGINS> file "ietf-datastores@2018-01-11.yang"
	module ietf-datastores {		module ietf-datastores {
	yang-version 1.1;		yang-version 1.1;
	namespace "urn:ietf:params:xml:ns:yang:ietf-datastores";		namespace "urn:ietf:params:xml:ns:yang:ietf-datastores";
	prefix ds;		prefix ds;
	organization		organization
	"IETF Network Modeling (NETMOD) Working Group";		"IETF Network Modeling (NETMOD) Working Group";
	contact		contact
	skipping to change at page 19, line 5 ¶		skipping to change at page 19, line 5 ¶
	<mailto:kwatsen@juniper.net>		<mailto:kwatsen@juniper.net>
	Author: Rob Wilton		Author: Rob Wilton
	<rwilton@cisco.com>";		<rwilton@cisco.com>";
	description		description
	"This YANG module defines two sets of identities for datastores.		"This YANG module defines two sets of identities for datastores.
	The first identifies the datastores themselves, the second		The first identifies the datastores themselves, the second
	identifies datastore properties.		identifies datastore properties.
	Copyright (c) 2017 IETF Trust and the persons identified as		Copyright (c) 2018 IETF Trust and the persons identified as
	authors of the code. All rights reserved.		authors of the code. All rights reserved.
	Redistribution and use in source and binary forms, with or		Redistribution and use in source and binary forms, with or
	without modification, is permitted pursuant to, and subject to		without modification, is permitted pursuant to, and subject to
	the license terms contained in, the Simplified BSD License set		the license terms contained in, the Simplified BSD License set
	forth in Section 4.c of the IETF Trust's Legal Provisions		forth in Section 4.c of the IETF Trust's Legal Provisions
	Relating to IETF Documents		Relating to IETF Documents
	(http://trustee.ietf.org/license-info).		(http://trustee.ietf.org/license-info).
	This version of this YANG module is part of RFC XXXX		This version of this YANG module is part of RFC XXXX
	(http://www.rfc-editor.org/info/rfcxxxx); see the RFC itself		(http://www.rfc-editor.org/info/rfcxxxx); see the RFC itself
	for full legal notices.";		for full legal notices.";
	revision 2017-12-20 {		revision 2018-01-11 {
	description		description
	"Initial revision.";		"Initial revision.";
	reference		reference
	"RFC XXXX: Network Management Datastore Architecture";		"RFC XXXX: Network Management Datastore Architecture";
	}		}
	/*		/*
	* Identities		* Identities
	*/		*/
	skipping to change at page 20, line 44 ¶		skipping to change at page 20, line 44 ¶
	base datastore;		base datastore;
	}		}
	description		description
	"A datastore identity reference.";		"A datastore identity reference.";
	}		}
	}		}
	<CODE ENDS>		<CODE ENDS>
	<CODE BEGINS> file "ietf-origin@2017-12-20.yang"		<CODE BEGINS> file "ietf-origin@2018-01-11.yang"
	module ietf-origin {		module ietf-origin {
	yang-version 1.1;		yang-version 1.1;
	namespace "urn:ietf:params:xml:ns:yang:ietf-origin";		namespace "urn:ietf:params:xml:ns:yang:ietf-origin";
	prefix or;		prefix or;
	import ietf-yang-metadata {		import ietf-yang-metadata {
	prefix md;		prefix md;
	}		}
	skipping to change at page 21, line 34 ¶		skipping to change at page 21, line 34 ¶
	Author: Kent Watsen		Author: Kent Watsen
	<mailto:kwatsen@juniper.net>		<mailto:kwatsen@juniper.net>
	Author: Rob Wilton		Author: Rob Wilton
	<rwilton@cisco.com>";		<rwilton@cisco.com>";
	description		description
	"This YANG module defines an 'origin' metadata annotation, and a		"This YANG module defines an 'origin' metadata annotation, and a
	set of identities for the origin value.		set of identities for the origin value.
	Copyright (c) 2017 IETF Trust and the persons identified as		Copyright (c) 2018 IETF Trust and the persons identified as
	authors of the code. All rights reserved.		authors of the code. All rights reserved.
	Redistribution and use in source and binary forms, with or		Redistribution and use in source and binary forms, with or
	without modification, is permitted pursuant to, and subject to		without modification, is permitted pursuant to, and subject to
	the license terms contained in, the Simplified BSD License set		the license terms contained in, the Simplified BSD License set
	forth in Section 4.c of the IETF Trust's Legal Provisions		forth in Section 4.c of the IETF Trust's Legal Provisions
	Relating to IETF Documents		Relating to IETF Documents
	(http://trustee.ietf.org/license-info).		(http://trustee.ietf.org/license-info).
	This version of this YANG module is part of RFC XXXX		This version of this YANG module is part of RFC XXXX
	(http://www.rfc-editor.org/info/rfcxxxx); see the RFC itself		(http://www.rfc-editor.org/info/rfcxxxx); see the RFC itself
	for full legal notices.";		for full legal notices.";
	revision 2017-12-20 {		revision 2018-01-11 {
	description		description
	"Initial revision.";		"Initial revision.";
	reference		reference
	"RFC XXXX: Network Management Datastore Architecture";		"RFC XXXX: Network Management Datastore Architecture";
	}		}
	/*		/*
	* Identities		* Identities
	*/		*/
	skipping to change at page 24, line 44 ¶		skipping to change at page 24, line 44 ¶
	prefix: or		prefix: or
	reference: RFC XXXX		reference: RFC XXXX
	9. Security Considerations		9. Security Considerations
	This document discusses an architectural model of datastores for		This document discusses an architectural model of datastores for
	network management using NETCONF/RESTCONF and YANG. It has no		network management using NETCONF/RESTCONF and YANG. It has no
	security impact on the Internet.		security impact on the Internet.
	Although this document specifies several YANG modules, these modules		Although this document specifies several YANG modules, these modules
	only define identities and meta-data, hence the "YANG module security		only define identities and a metadata annotation, hence the "YANG
	guidelines" do not apply.		module security guidelines" do not apply.
			The origin metadata annotation exposes the origin of values in the
			applied configuration. Origin information may provide hints that
			certain control plane protocols are active on a device. Since origin
			information is tied to applied configuration values, it is only
			accessible to clients that have the permissions to read the applied
			configuration values. Security administrators should consider the
			sensitivity of origin information while defining access control
			rules.
	10. Acknowledgments		10. Acknowledgments
	This document grew out of many discussions that took place since		This document grew out of many discussions that took place since
	2010. Several Internet-Drafts ([I-D.bjorklund-netmod-operational],		2010. Several Internet-Drafts ([I-D.bjorklund-netmod-operational],
	[I-D.wilton-netmod-opstate-yang], [I-D.ietf-netmod-opstate-reqs],		[I-D.wilton-netmod-opstate-yang], [I-D.ietf-netmod-opstate-reqs],
	[I-D.kwatsen-netmod-opstate], [I-D.openconfig-netmod-opstate]) and		[I-D.kwatsen-netmod-opstate], [I-D.openconfig-netmod-opstate]) and
	[RFC6244] touched on some of the problems of the original datastore		[RFC6244] touched on some of the problems of the original datastore
	model. The following people were authors to these Internet-Drafts or		model. The following people were authors to these Internet-Drafts or
	otherwise actively involved in the discussions that led to this		otherwise actively involved in the discussions that led to this
	document:		document:
	o Lou Berger, LabN Consulting, L.L.C., <lberger@labn.net>		o Lou Berger, LabN Consulting, L.L.C., <lberger@labn.net>
	o Andy Bierman, YumaWorks, <andy@yumaworks.com>		o Andy Bierman, YumaWorks, <andy@yumaworks.com>
	o Marcus Hines, Google, <hines@google.com>		o Marcus Hines, Google, <hines@google.com>
	skipping to change at page 26, line 6 ¶		skipping to change at page 26, line 17 ¶
	Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/		Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
	RFC2119, March 1997, <https://www.rfc-editor.org/info/		RFC2119, March 1997, <https://www.rfc-editor.org/info/
	rfc2119>.		rfc2119>.
	[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>.
	[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
	<https://www.rfc-editor.org/info/rfc7950>.		.rfc-editor.org/info/rfc7950>.
	[RFC7952] Lhotka, L., "Defining and Using Metadata with YANG", RFC		[RFC7952] Lhotka, L., "Defining and Using Metadata with YANG", RFC
	7952, DOI 10.17487/RFC7952, August 2016, <https://www.rfc-		7952, DOI 10.17487/RFC7952, August 2016, <https://www.rfc-
	editor.org/info/rfc7952>.		editor.org/info/rfc7952>.
	[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>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	skipping to change at page 31, line 14 ¶		skipping to change at page 32, line 4 ¶
	leaf ip {		leaf ip {
	type inet:ip-address;		type inet:ip-address;
	}		}
	leaf prefix-length {		leaf prefix-length {
	type uint8;		type uint8;
	}		}
	}		}
	}		}
	}		}
	}		}
	The operator has configured the host name and two interfaces, so the		The operator has configured the host name and two interfaces, so the
	contents of <intended> are:		contents of <intended> are:
	<system xmlns="urn:example:system">		<system xmlns="urn:example:system">
	<hostname>foo</hostname>		<hostname>foo.example.com</hostname>
	<interface>		<interface>
	<name>eth0</name>		<name>eth0</name>
	<auto-negotiation>		<auto-negotiation>
	<speed>1000</speed>		<speed>1000</speed>
	</auto-negotiation>		</auto-negotiation>
	<address>		<address>
	<ip>2001:db8::10</ip>		<ip>2001:db8::10</ip>
	<prefix-length>64</prefix-length>		<prefix-length>64</prefix-length>
	</address>		</address>
	skipping to change at page 32, line 9 ¶		skipping to change at page 33, line 9 ¶
	to a default value, a loopback interface is automatically added by		to a default value, a loopback interface is automatically added by
	the system, and the result of the "speed" auto-negotiation. All of		the system, and the result of the "speed" auto-negotiation. All of
	this is reflected in <operational>. Note how the origin metadata		this is reflected in <operational>. Note how the origin metadata
	attribute for several "config true" data nodes is inherited from		attribute for several "config true" data nodes is inherited from
	their parent data nodes.		their parent data nodes.
	<system		<system
	xmlns="urn:example:system"		xmlns="urn:example:system"
	xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin">		xmlns:or="urn:ietf:params:xml:ns:yang:ietf-origin">
	<hostname or:origin="or:learned">bar</hostname>		<hostname or:origin="or:learned">bar.example.com</hostname>
	<interface or:origin="or:intended">		<interface or:origin="or:intended">
	<name>eth0</name>		<name>eth0</name>
	<auto-negotiation>		<auto-negotiation>
	<enabled or:origin="or:default">true</enabled>		<enabled or:origin="or:default">true</enabled>
	<speed>1000</speed>		<speed>1000</speed>
	</auto-negotiation>		</auto-negotiation>
	<speed>100</speed>		<speed>100</speed>
	<address>		<address>
	<ip>2001:db8::10</ip>		<ip>2001:db8::10</ip>
	skipping to change at page 34, line 33 ¶		skipping to change at page 35, line 33 ¶
	No time delay should exist between the appearance of the peer in		No time delay should exist between the appearance of the peer in
	<running> and <intended>.		<running> and <intended>.
	In this scenario, we've added the following to <running>:		In this scenario, we've added the following to <running>:
	<bgp>		<bgp>
	<local-as>64501</local-as>		<local-as>64501</local-as>
	<peer-as>64502</peer-as>		<peer-as>64502</peer-as>
	<peer>		<peer>
	<name>10.1.2.3</name>		<name>2001:db8::2:3</name>
	</peer>		</peer>
	</bgp>		</bgp>
	C.2.2.1. <operational>		C.2.2.1. <operational>
	The operational datastore will contain the fully expanded peer data,		The operational datastore will contain the fully expanded peer data,
	including "config false" nodes. In our example, this means the		including "config false" nodes. In our example, this means the
	"state" node will appear.		"state" node will appear.
	In addition, <operational> will contain the "currently in use" values		In addition, <operational> will contain the "currently in use" values
	skipping to change at page 35, line 19 ¶		skipping to change at page 36, line 19 ¶
	values for the local-port and remote-port nodes regardless of the		values for the local-port and remote-port nodes regardless of the
	origin. If the system has chosen the values, the "origin" attribute		origin. If the system has chosen the values, the "origin" attribute
	will be set to "system". Before the connection is established, one		will be set to "system". Before the connection is established, one
	or both of the nodes may not appear, since the system may not yet		or both of the nodes may not appear, since the system may not yet
	have their values.		have their values.
	<bgp or:origin="or:intended">		<bgp or:origin="or:intended">
	<local-as>64501</local-as>		<local-as>64501</local-as>
	<peer-as>64502</peer-as>		<peer-as>64502</peer-as>
	<peer>		<peer>
	<name>10.1.2.3</name>		<name>2001:db8::2:3</name>
	<local-as or:origin="or:default">64501</local-as>		<local-as or:origin="or:default">64501</local-as>
	<peer-as or:origin="or:default">64502</peer-as>		<peer-as or:origin="or:default">64502</peer-as>
	<local-port or:origin="or:system">60794</local-port>		<local-port or:origin="or:system">60794</local-port>
	<remote-port or:origin="or:default">179</remote-port>		<remote-port or:origin="or:default">179</remote-port>
	<state>established</state>		<state>established</state>
	</peer>		</peer>
	</bgp>		</bgp>
	C.2.3. Removing a Peer		C.2.3. Removing a Peer
	skipping to change at page 36, line 9 ¶		skipping to change at page 37, line 9 ¶
	existence of that peer until the peer's resources are released,		existence of that peer until the peer's resources are released,
	including closing the peer's connection. During this period, the		including closing the peer's connection. During this period, the
	current data values will continue to be visible in <operational>,		current data values will continue to be visible in <operational>,
	with the "origin" attribute set to indicate the origin of the		with the "origin" attribute set to indicate the origin of the
	original data.		original data.
	<bgp or:origin="or:intended">		<bgp or:origin="or:intended">
	<local-as>64501</local-as>		<local-as>64501</local-as>
	<peer-as>64502</peer-as>		<peer-as>64502</peer-as>
	<peer>		<peer>
	<name>10.1.2.3</name>		<name>2001:db8::2:3</name>
	<local-as or:origin="or:default">64501</local-as>		<local-as or:origin="or:default">64501</local-as>
	<peer-as or:origin="or:default">64502</peer-as>		<peer-as or:origin="or:default">64502</peer-as>
	<local-port or:origin="or:system">60794</local-port>		<local-port or:origin="or:system">60794</local-port>
	<remote-port or:origin="or:default">179</remote-port>		<remote-port or:origin="or:default">179</remote-port>
	<state>closing</state>		<state>closing</state>
	</peer>		</peer>
	</bgp>		</bgp>
	Once resources are released and the connection is closed, the peer's		Once resources are released and the connection is closed, the peer's
	data is removed from <operational>.		data is removed from <operational>.
End of changes. 29 change blocks.
	46 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/