draft-ietf-netmod-schema-mount-12.txt		rfc8528.txt
	Network Working Group M. Bjorklund		Internet Engineering Task Force (IETF) M. Bjorklund
	Internet-Draft Tail-f Systems		Request for Comments: 8528 Tail-f Systems
	Intended status: Standards Track L. Lhotka		Category: Standards Track L. Lhotka
	Expires: April 20, 2019 CZ.NIC		ISSN: 2070-1721 CZ.NIC
	October 17, 2018		March 2019
	YANG Schema Mount		YANG Schema Mount
	draft-ietf-netmod-schema-mount-12
	Abstract		Abstract
	This document defines a mechanism to add the schema trees defined by		This document defines a mechanism that adds the schema trees defined
	a set of YANG modules onto a mount point defined in the schema tree		by a set of YANG modules onto a mount point defined in the schema
	in some YANG module.		tree in another YANG module.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This is an Internet Standards Track document.
	provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		This document is a product of the Internet Engineering Task Force
	and may be updated, replaced, or obsoleted by other documents at any		(IETF). It represents the consensus of the IETF community. It has
	time. It is inappropriate to use Internet-Drafts as reference		received public review and has been approved for publication by the
	material or to cite them other than as "work in progress."		Internet Engineering Steering Group (IESG). Further information on
			Internet Standards is available in Section 2 of RFC 7841.
	This Internet-Draft will expire on April 20, 2019.		Information about the current status of this document, any errata,
			and how to provide feedback on it may be obtained at
			https://www.rfc-editor.org/info/rfc8528.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2019 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		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction ....................................................3
	2. Terminology and Notation . . . . . . . . . . . . . . . . . . 5		2. Terminology and Notation ........................................6
	2.1. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 6		2.1. Tree Diagrams ..............................................7
	2.2. Namespace Prefixes . . . . . . . . . . . . . . . . . . . 6		2.2. Namespace Prefixes .........................................7
	3. Schema Mount . . . . . . . . . . . . . . . . . . . . . . . . 7		3. Schema Mount ....................................................8
	3.1. Mount Point Definition . . . . . . . . . . . . . . . . . 7		3.1. Mount Point Definition .....................................8
	3.2. Data Model . . . . . . . . . . . . . . . . . . . . . . . 8		3.2. Data Model .................................................9
	3.3. Specification of the Mounted Schema . . . . . . . . . . . 8		3.3. Specification of the Mounted Schema ........................9
	3.4. Multiple Levels of Schema Mount . . . . . . . . . . . . . 9		3.4. Multiple Levels of Schema Mount ...........................10
	4. Referring to Data Nodes in the Parent Schema . . . . . . . . 9		4. Referring to Data Nodes in the Parent Schema ...................10
	5. RPC operations and Notifications . . . . . . . . . . . . . . 11		5. RPC Operations and Notifications ...............................11
	6. Network Management Datastore Architecture (NMDA)		6. NMDA Considerations ............................................12
	Considerations . . . . . . . . . . . . . . . . . . . . . . . 11		7. Interaction with NACM ..........................................12
	7. Interaction with the Network Configuration Access Control		8. Implementation Notes ...........................................13
	Model (NACM) . . . . . . . . . . . . . . . . . . . . . . . . 11		9. Schema Mount YANG Module .......................................13
	8. Implementation Notes . . . . . . . . . . . . . . . . . . . . 12		10. IANA Considerations ...........................................18
	9. Schema Mount YANG Module . . . . . . . . . . . . . . . . . . 12		11. Security Considerations .......................................18
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17		12. References ....................................................19
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 17		12.1. Normative References .....................................19
	12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18		12.2. Informative References ...................................21
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . 19		Appendix A. Example: Device Model with LNEs and NIs ..............22
	13.1. Normative References . . . . . . . . . . . . . . . . . . 19		A.1. Physical Device ...........................................22
	13.2. Informative References . . . . . . . . . . . . . . . . . 20		A.2. Logical Network Elements ..................................24
	Appendix A. Example: Device Model with LNEs and NIs . . . . . . 21		A.3. Network Instances .........................................27
	A.1. Physical Device . . . . . . . . . . . . . . . . . . . . . 21		A.4. Invoking an RPC Operation .................................28
	A.2. Logical Network Elements . . . . . . . . . . . . . . . . 23		Contributors ......................................................28
	A.3. Network Instances . . . . . . . . . . . . . . . . . . . . 26		Authors' Addresses ................................................28
	A.4. Invoking an RPC Operation . . . . . . . . . . . . . . . . 27
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
	1. Introduction		1. Introduction
	Modularity and extensibility were among the leading design principles		Modularity and extensibility are among the leading design principles
	of the YANG data modeling language. As a result, the same YANG		of the YANG data modeling language. As a result, the same YANG
	module can be combined with various sets of other modules and thus		module can be combined with various sets of other modules to form a
	form a data model that is tailored to meet the requirements of a		data model that is tailored to meet the requirements of a specific
	specific use case. Server implementors are only required to specify		use case. Server implementors are only required to specify all YANG
	all YANG modules comprising the data model (together with their		modules comprising the data model (together with their revisions and
	revisions and other optional choices) in the YANG library data		other optional choices) in the YANG library data ([RFC7895],
	([RFC7895], [I-D.ietf-netconf-rfc7895bis] and Section 5.6.4 of		[RFC8525], and Section 5.6.4 of [RFC7950]) implemented by the server.
	[RFC7950]) implemented by the server. Such YANG modules appear in		Such YANG modules appear in the data model "side by side", i.e., top-
	the data model "side by side", i.e., top-level data nodes of each		level data nodes of each module (if there are any) are also top-level
	module - if there are any - are also top-level nodes of the overall		nodes of the overall data model.
	data model.
	YANG has two mechanisms for contributing a schema hierarchy defined		YANG has two mechanisms for contributing a schema hierarchy defined
	elsewhere to the contents of an internal node of the schema tree;		elsewhere to the contents of an internal node of the schema tree.
	these mechanisms are realized through the following YANG statements:		These mechanisms are realized through the following YANG statements:
	o The "uses" statement explicitly incorporates the contents of a		o The "uses" statement explicitly incorporates the contents of a
	grouping defined in the same or another module. See Section 4.2.6		grouping defined in the same or another module. See Section 4.2.6
	of [RFC7950] for more details.		of [RFC7950] for more details.
	o The "augment" statement explicitly adds contents to a target node		o The "augment" statement explicitly adds contents to a target node
	defined in the same or another module. See Section 4.2.8 of		defined in the same or another module. See Section 4.2.8 of
	[RFC7950] for more details.		[RFC7950] for more details.
	With both mechanisms, the YANG module with the "uses" or "augment"		With both mechanisms, the YANG module with the "uses" or "augment"
	statement explicitly defines the exact location in the schema tree		statement explicitly defines the exact location in the schema tree
	where the new nodes are placed.		where the new nodes are placed.
	In some cases these mechanisms are not sufficient; it is sometimes		In some cases, these mechanisms are not sufficient; it is sometimes
	necessary that an existing module (or a set of modules) is added to		necessary for an existing module (or a set of modules) to be added to
	the data model starting at locations other than the root. For		the data model starting at locations other than the root. For
	example, YANG modules such as "ietf-interfaces" [RFC8343] are defined		example, YANG modules such as "ietf-interfaces" [RFC8343] are defined
	so as to be used in a data model of a physical device. Now suppose		so as to be used in a data model of a physical device. Now suppose
	we want to model a device that supports multiple logical devices		we want to model a device that supports multiple logical devices
	[I-D.ietf-rtgwg-lne-model], each of which has its own instantiation		[RFC8530], each of which has its own instantiation of
	of "ietf-interfaces", and possibly other modules, but, at the same		"ietf-interfaces", and possibly other modules; at the same time, we
	time, we want to be able to manage all these logical devices from the		want to be able to manage all these logical devices from the master
	master device. Hence, we would like to have a schema tree like this:		device. Hence, we would like to have a schema tree like this:
	+--rw interfaces		+--rw interfaces
	| +--rw interface* [name]		| +--rw interface* [name]
	| ...		| ...
	+--rw logical-network-element* [name]		+--rw logical-network-element* [name]
	+--rw name		+--rw name
	| ...		| ...
	+--rw interfaces		+--rw interfaces
	+--rw interface* [name]		+--rw interface* [name]
	...		...
	skipping to change at page 4, line 16 ¶		skipping to change at page 4, line 37 ¶
	if the grouping is used in different locations.		if the grouping is used in different locations.
	o Nodes defined inside a grouping belong to the namespace of the		o Nodes defined inside a grouping belong to the namespace of the
	module where it is used, which makes references to such nodes from		module where it is used, which makes references to such nodes from
	other modules difficult or even impossible.		other modules difficult or even impossible.
	o It would be difficult for vendors to add proprietary modules when		o It would be difficult for vendors to add proprietary modules when
	the "uses" statements are defined in a standard module.		the "uses" statements are defined in a standard module.
	With the "augment" approach, "ietf-interfaces" would have to augment		With the "augment" approach, "ietf-interfaces" would have to augment
	the "logical-network-element" list with all its nodes, and at the		the "logical-network-element" list with all its nodes and, at the
	same time define all its nodes at the top level. The same hierarchy		same time, define all its nodes at the top level. The same hierarchy
	of nodes would thus have to be defined twice, which is clearly not		of nodes would thus have to be defined twice, which is clearly not
	scalable either.		scalable either.
	This document introduces a new mechanism, denoted as schema mount,		This document introduces a new mechanism, denoted as "schema mount",
	that allows for mounting one data model consisting of any number of		that allows for mounting one data model consisting of any number of
	YANG modules at a specified location of another (parent) schema.		YANG modules at a specified location of another (parent) schema.
	Unlike the "uses" and "augment" approaches discussed above, the		Unlike the "uses" and "augment" approaches discussed above, the
	mounted modules needn't be specially prepared for mounting and,		mounted modules needn't be specially prepared for mounting;
	consequently, existing modules such as "ietf-interfaces" can be		consequently, existing modules such as "ietf-interfaces" can be
	mounted without any modifications.		mounted without any modifications.
	The basic idea of schema mount is to label a data node in the parent		The basic idea of schema mount is to label a data node in the parent
	schema as the mount point, and then define a complete data model to		schema as the mount point and then define a complete data model to be
	be attached to the mount point so that the labeled data node		attached to the mount point so that the labeled data node effectively
	effectively becomes the root node of the mounted data model.		becomes the root node of the mounted data model.
	In principle, the mounted schema can be specified at three different		In principle, the mounted schema can be specified at three different
	phases of the data model life cycle:		phases of the data model life cycle:
	1. Design-time: the mounted schema is defined along with the mount		1. Design time: The mounted schema is defined along with the mount
	point in the parent YANG module. In this case, the mounted		point in the parent YANG module. In this case, the mounted
	schema has to be the same for every implementation of the parent		schema has to be the same for every implementation of the parent
	module.		module.
	2. Implementation-time: the mounted schema is defined by a server		2. Implementation time: The mounted schema is defined by a server
	implementor and is as stable as the YANG library information of		implementor and is as stable as the YANG library information of
	the server.		the server.
	3. Run-time: the mounted schema is defined by instance data that is		3. Run time: The mounted schema is defined by instance data that is
	part of the mounted data model. If there are multiple instances		part of the mounted data model. If there are multiple instances
	of the same mount point (e.g., in multiple entries of a list),		of the same mount point (e.g., in multiple entries of a list),
	the mounted data model may be different for each instance.		the mounted data model may be different for each instance.
	The schema mount mechanism defined in this document provides support		The schema mount mechanism defined in this document provides support
	only for the latter two cases. Design-time mounts are outside the		only for the latter two cases. Design-time mounts are outside the
	scope of this document, and could be possibly dealt with in a future		scope of this document and could be possibly dealt with in a future
	revision of the YANG data modeling language.		revision of the YANG data modeling language.
	Schema mount applies to the data model, and specifically does not		Schema mount applies to the data model and specifically does not
	assume anything about the source of instance data for the mounted		assume anything about the source of instance data for the mounted
	schemas. It may be implemented using the same instrumentation as the		schemas. It may be implemented using the same instrumentation as the
	rest of the system, or it may be implemented by querying some other		rest of the system, or it may be implemented by querying some other
	system. Future specifications may define mechanisms to control or		system. Future specifications may define mechanisms to control or
	monitor the implementation of specific mount points.		monitor the implementation of specific mount points.
	How and when specific mount points are instantiated by the server is		How and when specific mount points are instantiated by the server is
	out of scope for this document. Such mechanisms may be defined in		out of scope for this document. Such mechanisms may be defined in
	future specifications.		future specifications.
	skipping to change at page 5, line 29 ¶		skipping to change at page 6, line 9 ¶
	specifications may extend this model by defining additional		specifications may extend this model by defining additional
	mechanisms such as mounting sub-hierarchies of a module.		mechanisms such as mounting sub-hierarchies of a module.
	The YANG modules in this document conform to the Network Management		The YANG modules in this document conform to the Network Management
	Datastore Architecture (NMDA) [RFC8342].		Datastore Architecture (NMDA) [RFC8342].
	2. Terminology and Notation		2. Terminology and Notation
	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
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	The following terms are defined in [RFC7950] and are not redefined		The following terms are defined in [RFC7950] and are not redefined
	here:		here:
	o action		o action
	o container		o container
	o data node		o data node
	skipping to change at page 6, line 17 ¶		skipping to change at page 6, line 45 ¶
	o notification		o notification
	o operational state		o operational state
	o server		o server
	The following term is defined in [RFC8343] and is not redefined here:		The following term is defined in [RFC8343] and is not redefined here:
	o system-controlled interface		o system-controlled interface
	The following term is defined in [I-D.ietf-netconf-rfc7895bis] is not		The following term is defined in [RFC8525] and is not redefined here:
	redefined here:
	o YANG library content identifier		o YANG library content identifier
			The following additional terms are used in this document:
	The following additional terms are used within this document:
	o mount point: A container or a list node whose definition contains		o mount point: A container or a list node whose definition contains
	the "mount-point" extension statement. The argument of the		the "mount-point" extension statement. The argument of the
	"mount-point" statement defines a label for the mount point.		"mount-point" extension statement defines a label for the mount
			point.
	o schema: A collection of schema trees with a common root.		o schema: A collection of schema trees with a common root.
	o top-level schema: A schema rooted at the root node.		o top-level schema: A schema rooted at the root node.
	o mounted schema: A schema rooted at a mount point.		o mounted schema: A schema rooted at a mount point.
	o parent schema (of a mounted schema): A schema containing the mount		o parent schema (of a mounted schema): A schema containing the mount
	point.		point.
	o schema mount: The mechanism to combine data models defined in this		o schema mount: The mechanism to combine data models defined in this
	document.		document.
	2.1. Tree Diagrams		2.1. Tree Diagrams
	Tree diagrams used in this document follow the notation defined in		Tree diagrams used in this document follow the notation defined in
	[RFC8340]		[RFC8340].
	2.2. Namespace Prefixes		2.2. Namespace Prefixes
	In this document, names of data nodes, YANG extensions, actions and		In this document, names of data nodes, YANG extensions, actions, and
	other data model objects are often used without a prefix, as long as		other data model objects are often used without a prefix when the
	it is clear from the context in which YANG module each name is		YANG module in which they are defined is clear from the context.
	defined. Otherwise, names are prefixed using the standard prefix		Otherwise, names are prefixed using the standard prefix associated
	associated with the corresponding YANG module, as shown in Table 1.		with the corresponding YANG module, as shown in Table 1.
	+---------+------------------------+--------------------------------+		+---------+------------------------+----------------------+
	| Prefix | YANG module | Reference |		| Prefix | YANG module | Reference |
	+---------+------------------------+--------------------------------+		+---------+------------------------+----------------------+
	| yangmnt | ietf-yang-schema-mount | Section 9 |		| yangmnt | ietf-yang-schema-mount | Section 9 |
	| inet | ietf-inet-types | [RFC6991] |		| inet | ietf-inet-types | [RFC6991] |
	| yang | ietf-yang-types | [RFC6991] |		| yang | ietf-yang-types | [RFC6991] |
	| yanglib | ietf-yang-library | [RFC7895], |		| yanglib | ietf-yang-library | [RFC7895], [RFC8525] |
	| | | [I-D.ietf-netconf-rfc7895bis] |		+---------+------------------------+----------------------+
	+---------+------------------------+--------------------------------+
	Table 1: Namespace Prefixes		Table 1: Namespace Prefixes
	3. Schema Mount		3. Schema Mount
	The schema mount mechanism defined in this document provides a new		The schema mount mechanism defined in this document provides a new
	extensibility mechanism for use with YANG 1.1. In contrast to the		extensibility mechanism for use with YANG 1.1 [RFC7950]. In contrast
	existing mechanisms described in Section 1, schema mount defines the		to the existing mechanisms described in Section 1, schema mount
	relationship between the source and target YANG modules outside these		defines the relationship between the source and target YANG modules
	modules. The procedure consists of two separate steps that are		outside these modules.
	described in the following subsections.
	3.1. Mount Point Definition		3.1. Mount Point Definition
	A "container" or "list" node becomes a mount point if the		A container or list node becomes a mount point if the "mount-point"
	"mount-point" extension (defined in the "ietf-yang-schema-mount"		extension statement (defined in the "ietf-yang-schema-mount" module)
	module) is used in its definition. This extension can appear only as		is used in its definition. This extension can appear only as a
	a substatement of "container" and "list" statements.		substatement of "container" and "list" statements.
	The argument of the "mount-point" extension is a YANG identifier that		The argument of the "mount-point" extension statement is a YANG
	defines a label for the mount point. A module MAY contain multiple		identifier that defines a label for the mount point. A module MAY
	"mount-point" statements having the same argument.		contain multiple "mount-point" extension statements having the same
			argument.
	It is therefore up to the designer of the parent schema to decide		It is therefore up to the designer of the parent schema to decide
	about the placement of mount points. A mount point can also be made		about the placement of mount points. A mount point can also be made
	conditional by placing "if-feature" and/or "when" as substatements of		conditional by placing "if-feature" and/or "when" as substatements of
	the "container" or "list" statement that represents the mount point.		the "container" or "list" statement that represents the mount point.
	The "mount-point" statement MUST NOT be used in a YANG version 1		The "mount-point" extension statement MUST NOT be used in a YANG
	module [RFC6020]. The reason for this is that otherwise it is not		version 1 module [RFC6020]. If used in a YANG version 1 module, it
	possible to invoke mounted RPC operations, and receive mounted		would not be possible to invoke mounted RPC operations and receive
	notifications. See Section 5 for details. Note, however, that		mounted notifications. See Section 5 for details. Note, however,
	modules written in any YANG version, including version 1, can be		that modules written in any YANG version, including version 1, can be
	mounted under a mount point.		mounted under a mount point.
	Note that the "mount-point" statement does not define a new data		Note that the "mount-point" extension statement does not define a new
	node.		data node.
	3.2. Data Model		3.2. Data Model
	This document defines the YANG 1.1 module [RFC7950]		This document defines the YANG 1.1 module [RFC7950]
	"ietf-yang-schema-mount", which has the following structure:		"ietf-yang-schema-mount", which has the following structure:
	module: ietf-yang-schema-mount		module: ietf-yang-schema-mount
	+--ro schema-mounts		+--ro schema-mounts
	+--ro namespace* [prefix]		+--ro namespace* [prefix]
	| +--ro prefix yang:yang-identifier		| +--ro prefix yang:yang-identifier
	skipping to change at page 8, line 33 ¶		skipping to change at page 9, line 33 ¶
	+--ro shared-schema!		+--ro shared-schema!
	+--ro parent-reference* yang:xpath1.0		+--ro parent-reference* yang:xpath1.0
	3.3. Specification of the Mounted Schema		3.3. Specification of the Mounted Schema
	Mounted schemas for all mount points in the parent schema are		Mounted schemas for all mount points in the parent schema are
	determined from state data in the "/schema-mounts" container.		determined from state data in the "/schema-mounts" container.
	Generally, the modules that are mounted under a mount point have no		Generally, the modules that are mounted under a mount point have no
	relation to the modules in the parent schema; specifically, if a		relation to the modules in the parent schema; specifically, if a
	module is mounted it may or may not be present in the parent schema		module is mounted, it may or may not be present in the parent schema;
	and, if present, its data will generally have no relationship to the		if present, its data will generally have no relationship to the data
	data of the parent. Exceptions are possible and such needs to be		of the parent. Exceptions are possible and need to be defined in the
	defined in the model defining the exception. For example,		model itself. For example, [RFC8530] defines a mechanism to bind
	[I-D.ietf-rtgwg-lne-model] defines a mechanism to bind interfaces to		interfaces to mounted logical network elements.
	mounted logical network elements.
	The "/schema-mounts" container has the "mount-point" list as one of		The "/schema-mounts" container has the "mount-point" list as one of
	its children. Every entry of this list refers through its key to a		its children. Every entry of this list refers (through its key) to a
	mount point and specifies the mounted schema.		mount point and specifies the mounted schema.
	If a mount point is defined in the parent schema but does not have an		If a mount point is defined in the parent schema but does not have an
	entry in the "mount-point" list, then the mounted schema is void,		entry in the "mount-point" list, then the mounted schema is void,
	i.e., instances of that mount point MUST NOT contain any data except		i.e., instances of that mount point MUST NOT contain any data except
	those that are defined in the parent schema.		those that are defined in the parent schema.
	If multiple mount points with the same name are defined in the same		If multiple mount points with the same name are defined in the same
	module - either directly or because the mount point is defined in a		module -- either directly or because the mount point is defined in a
	grouping and the grouping is used multiple times - then the		grouping and the grouping is used multiple times -- then the
	corresponding "mount-point" entry applies equally to all such mount		corresponding "mount-point" entry applies equally to all such mount
	points.		points.
	The "config" property of mounted schema nodes is overridden and all		The "config" property of mounted schema nodes is overridden and all
	nodes in the mounted schema are read-only ("config false") if at		nodes in the mounted schema are read-only ("config false") if at
	least one of the following conditions is satisfied for a mount point:		least one of the following conditions is satisfied for a mount point:
	o the mount point is itself defined as "config false"		o The mount point is itself defined as "config false".
	o the "config" leaf in the corresponding entry of the "mount-point"		o The "config" leaf in the corresponding entry of the "mount-point"
	list is set to "false".		list is set to "false".
	An entry of the "mount-point" list can specify the mounted schema in		An entry of the "mount-point" list can specify the mounted schema in
	two different ways, "inline" or "shared-schema".		two different ways: "inline" or "shared-schema".
	The mounted schema is determined at run time: every instance of the		The mounted schema is determined at run time: every instance of the
	mount point that exists in the operational state MUST contain a copy		mount point that exists in the operational state MUST contain a copy
	of YANG library data that defines the mounted schema exactly as for a		of YANG library data that defines the mounted schema in exactly the
	top-level schema. A client is expected to retrieve this data from		same way as a top-level schema. A client is expected to retrieve
	the instance tree. In the "inline" case, instances of the same mount		this data from the instance tree. In the "inline" case, instances of
	point MAY use different mounted schemas, whereas in the		the same mount point MAY use different mounted schemas, whereas in
	"shared-schema" case, all instances MUST use the same mounted schema.		the "shared-schema" case, all instances MUST use the same mounted
	This means that in the "shared-schema" case, all instances of the		schema. This means that in the "shared-schema" case, all instances
	same mount point MUST have the same YANG library content identifier.		of the same mount point MUST have the same YANG library content
	In the "inline" case, if two instances have the same YANG library		identifier. In the "inline" case, if two instances have the same
	content identifier it is not guaranteed that the YANG library		YANG library content identifier, it is not guaranteed that the YANG
	contents are equal for these instances.		library contents are equal for these instances.
	Examples of "inline" and "shared-schema" can be found in Appendix A.2		Examples of "inline" and "shared-schema" can be found in Appendix A.2
	and Appendix A.3, respectively.		and Appendix A.3, respectively.
	3.4. Multiple Levels of Schema Mount		3.4. Multiple Levels of Schema Mount
	YANG modules in a mounted schema MAY again contain mount points under		YANG modules in a mounted schema MAY again contain mount points under
	which other schemas can be mounted. Consequently, it is possible to		which other schemas can be mounted. Consequently, it is possible to
	construct data models with an arbitrary number of mounted schemas. A		construct data models with an arbitrary number of mounted schemas. A
	schema for a mount point contained in a mounted module can be		schema for a mount point contained in a mounted module can be
	specified by implementing "ietf-yang-library" and		specified by implementing the "ietf-yang-library" and
	"ietf-yang-schema-mount" modules in the mounted schema, and		"ietf-yang-schema-mount" modules in the mounted schema and specifying
	specifying the schemas exactly as it is done in the top-level schema.		the schemas in exactly the same way as the top-level schema.
	4. Referring to Data Nodes in the Parent Schema		4. Referring to Data Nodes in the Parent Schema
	A fundamental design principle of schema mount is that the mounted		A fundamental design principle of schema mount is that the mounted
	schema works exactly as a top-level schema, i.e., it is confined to		schema works exactly as a top-level schema, i.e., it is confined to
	the "mount jail". This means that all paths in the mounted schema		the "mount jail". This means that all paths in the mounted schema
	(in leafrefs, instance-identifiers, XPath [XPATH] expressions, and		(in leafrefs, instance-identifiers, XPath [XPATH] expressions, and
	target nodes of augments) are interpreted with the mount point as the		target nodes of "augment" statements) are interpreted with the mount
	root node. YANG modules of the mounted schema as well as		point as the root node. YANG modules of the mounted schema as well
	corresponding instance data thus cannot refer to schema nodes or		as corresponding instance data thus cannot refer to schema nodes or
	instance data outside the mount jail.		instance data outside the "mount jail".
	However, this restriction is sometimes too severe. A typical example		However, this restriction is sometimes too severe. A typical example
	is network instances (NI) [I-D.ietf-rtgwg-ni-model], where each NI		is network instances (NIs) [RFC8529] in which each NI has its own
	has its own routing engine but the list of interfaces is global and		routing engine but the list of interfaces is global and shared by all
	shared by all NIs. If we want to model this organization with the NI		NIs. If we want to model this organization with the NI schema
	schema mounted using schema mount, the overall schema tree would look		mounted using schema mount, the overall schema tree would look
	schematically as follows:		schematically as follows:
	+--rw interfaces		+--rw interfaces
	| +--rw interface* [name]		| +--rw interface* [name]
	| ...		| ...
	+--rw network-instances		+--rw network-instances
	+--rw network-instance* [name]		+--rw network-instance* [name]
	+--rw name		+--rw name
	+--rw root		+--mp root
	+--rw routing		+--rw routing
	...		...
	Here, the "root" node is the mount point for the NI schema. Routing		Here, the "root" container is the mount point for the NI schema.
	configuration inside an NI often needs to refer to interfaces (at		Routing configuration inside an NI often needs to refer to interfaces
	least those that are assigned to the NI), which is impossible unless		(at least those that are assigned to the NI), which is impossible
	such a reference can point to a node in the parent schema (interface		unless such a reference can point to a node in the parent schema
	name).		(interface name).
	Therefore, schema mount also allows for such references. For every		Therefore, schema mount also allows for such references. For every
	mount point in the "shared-schema" case, it is possible to specify a		mount point in the "shared-schema" case, it is possible to specify a
	leaf-list named "parent-reference" that contains zero or more XPath		leaf-list named "parent-reference" that contains zero or more XPath
	1.0 expressions. Each expression is evaluated with the node in the		1.0 expressions. Each expression is evaluated with the node in the
	parent data tree where the mount point is defined as the context		parent data tree where the mount point is defined as the context
	node. The result of this evaluation MUST be a nodeset (see the		node. The result of this evaluation MUST be a node-set (see the
	description of the "parent-reference" node for a complete definition		description of the "parent-reference" node for a complete definition
	of the evaluation context). For the purposes of evaluating XPath		of the evaluation context). For the purposes of evaluating XPath
	expressions within the mounted data tree, the union of all such		expressions within the mounted data tree, the union of all such node-
	nodesets is added to the accessible data tree.		sets is added to the accessible data tree.
	It is worth emphasizing that the nodes specified in		It is worth emphasizing that the nodes specified in the
	"parent-reference" leaf-list are available in the mounted schema only		"parent-reference" leaf-list are available in the mounted schema only
	for XPath evaluations. In particular, they cannot be accessed there		for XPath evaluations. In particular, they cannot be accessed in the
	via network management protocols such as NETCONF [RFC6241] or		mounted schema via network management protocols such as NETCONF
	RESTCONF [RFC8040].		[RFC6241] or RESTCONF [RFC8040].
	5. RPC operations and Notifications		5. RPC Operations and Notifications
	If a mounted YANG module defines an RPC operation, clients can invoke		If a mounted YANG module defines an RPC operation, clients can invoke
	this operation as if it were defined as an action for the		this operation as if it were defined as an action for the
	corresponding mount point, see Section 7.15 of [RFC7950]. An example		corresponding mount point; see Section 7.15 of [RFC7950]. An example
	of this is given in Appendix A.4.		of this is given in Appendix A.4.
	Similarly, if the server emits a notification defined at the top		Similarly, if the server emits a notification defined at the top
	level of any mounted module, it MUST be represented as if the		level of any mounted module, it MUST be represented as if the
	notification was connected to the mount point, see Section 7.16 of		notification was connected to the mount point; see Section 7.16 of
	[RFC7950].		[RFC7950].
	Note, inline actions and notifications will not work when they are		Note that inline actions and notifications will not work when they
	contained within a list node without a "key" statement (see section		are contained within a list node without a "key" statement (see
	7.15 and 7.16 of [RFC7950]). Therefore, to be useful, mount points		Sections 7.15 and 7.16 of [RFC7950]). Therefore, to be useful, mount
	that contain modules with RPCs, actions, and notifications SHOULD NOT		points that contain modules with RPCs, actions, and notifications
	have any ancestor node that is a list node without a "key" statement.		SHOULD NOT have any ancestor node that is a list node without a "key"
	This requirement applies to the definition of modules using the		statement. This requirement applies to the definition of modules
	"mount-point" extension statement.		using the "mount-point" extension statement.
	6. Network Management Datastore Architecture (NMDA) Considerations		6. NMDA Considerations
	The schema mount solution presented in this document is designed to		The schema mount solution presented in this document is designed to
	work both with servers that implement the NMDA [RFC8342], and old		work with both servers that implement the NMDA [RFC8342] and old
	servers that don't implement the NMDA.		servers that don't implement the NMDA.
	Note to RFC Editor: please update the date YYYY-MM-DD below with the		Specifically, a server that doesn't support the NMDA MAY implement
	revision of the ietf-yang-library in the published version of draft-
	ietf-netconf-rfc7895bis, and remove this note.
	Specifically, a server that doesn't support the NMDA, MAY implement
	revision 2016-06-21 of "ietf-yang-library" [RFC7895] under a mount		revision 2016-06-21 of "ietf-yang-library" [RFC7895] under a mount
	point. A server that supports the NMDA, MUST implement at least		point. A server that supports the NMDA MUST implement at least
	revision YYYY-MM-DD of "ietf-yang-library"		revision 2019-01-04 of "ietf-yang-library" [RFC8525] under a mount
	[I-D.ietf-netconf-rfc7895bis] under the mount points.		point.
	7. Interaction with the Network Configuration Access Control Model		7. Interaction with NACM
	(NACM)
	If NACM [RFC8341] is implemented on a server, it is used to control		If the Network Configuration Access Control Model (NACM) [RFC8341] is
	access to nodes defined by the mounted schema in the same way as for		implemented on a server, it is used to control access to nodes
	nodes defined by the top-level schema.		defined by the mounted schema in the same way as for nodes defined by
			the top-level schema.
	For example, suppose the module "ietf-interfaces" is mounted in the		For example, suppose the module "ietf-interfaces" is mounted in the
	"root" container in the "logical-network-element" list defined in		"root" container in the "logical-network-element" list defined in
	[I-D.ietf-rtgwg-lne-model]. Then the following NACM path can be used		[RFC8530]. Then, the following NACM path can be used to control
	to control access to the "interfaces" container (where the character		access to the "interfaces" container (where the character '\' is used
	'\' is used where a line break has been inserted for formatting		where a line break has been inserted for formatting reasons):
	reasons):
	<path xmlns:lne=		<path xmlns:lne=
	"urn:ietf:params:xml:ns:yang:ietf-logical-network-element"		"urn:ietf:params:xml:ns:yang:ietf-logical-network-element"
	xmlns:if="urn:ietf:params:xml:ns:yang:ietf-interfaces">		xmlns:if="urn:ietf:params:xml:ns:yang:ietf-interfaces">
	/lne:logical-network-elements\		/lne:logical-network-elements\
	/lne:logical-network-element/lne:root/if:interfaces		/lne:logical-network-element/lne:root/if:interfaces
	</path>		</path>
	8. Implementation Notes		8. Implementation Notes
	Network management of devices that use a data model with schema mount		Network management of devices that use a data model with schema mount
	can be implemented in different ways. However, the following		can be implemented in different ways. However, the following
	implementations options are envisioned as typical:		implementation options are envisioned as typical:
	o shared management: instance data of both parent and mounted		o shared management: Instance data of both parent and mounted
	schemas are accessible within the same management session.		schemas are accessible within the same management session.
	o split management: one (master) management session has access to		o split management: One (master) management session has access to
	instance data of both parent and mounted schemas but, in addition,		instance data of both parent and mounted schemas; in addition, an
	an extra session exists for every instance of the mount point,		extra session that has access only to the mounted data tree exists
	having access only to the mounted data tree.		for every instance of the mount point.
	9. Schema Mount YANG Module		9. Schema Mount YANG Module
	This module references [RFC6991].		This module references [RFC6991] and [RFC7950].
	<CODE BEGINS> file "ietf-yang-schema-mount@2018-10-16"		<CODE BEGINS> file "ietf-yang-schema-mount@2019-01-14.yang"
	module ietf-yang-schema-mount {		module ietf-yang-schema-mount {
	yang-version 1.1;		yang-version 1.1;
	namespace "urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount";		namespace "urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount";
	prefix yangmnt;		prefix yangmnt;
	import ietf-inet-types {		import ietf-inet-types {
	prefix inet;		prefix inet;
	reference		reference
	"RFC 6991: Common YANG Data Types";		"RFC 6991: Common YANG Data Types";
	skipping to change at page 13, line 7 ¶		skipping to change at page 13, line 46 ¶
	import ietf-yang-types {		import ietf-yang-types {
	prefix yang;		prefix yang;
	reference		reference
	"RFC 6991: Common YANG Data Types";		"RFC 6991: Common YANG Data Types";
	}		}
	organization		organization
	"IETF NETMOD (NETCONF Data Modeling Language) Working Group";		"IETF NETMOD (NETCONF Data Modeling Language) Working Group";
	contact		contact
	"WG Web: <https://tools.ietf.org/wg/netmod/>		"WG Web: <https://datatracker.ietf.org/wg/netmod/>
	WG List: <mailto:netmod@ietf.org>		WG List: <mailto:netmod@ietf.org>
	Editor: Martin Bjorklund		Editor: Martin Bjorklund
	<mailto:mbj@tail-f.com>		<mailto:mbj@tail-f.com>
	Editor: Ladislav Lhotka		Editor: Ladislav Lhotka
	<mailto:lhotka@nic.cz>";		<mailto:lhotka@nic.cz>";
	// RFC Ed.: replace XXXX with actual RFC number and
	// remove this note.
	description		description
	"This module defines a YANG extension statement that can be used		"This module defines a YANG extension statement that can be used
	to incorporate data models defined in other YANG modules in a		to incorporate data models defined in other YANG modules in a
	module. It also defines operational state data that specify the		module. It also defines operational state data that specify the
	overall structure of the data model.		overall structure of the data model.
	Copyright (c) 2018 IETF Trust and the persons identified as		The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
	authors of the code. All rights reserved.		NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
			'MAY', and 'OPTIONAL' in this document are to be interpreted as
			described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
			they appear in all capitals, as shown here.
			Copyright (c) 2019 IETF Trust and the persons identified as
			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
	(https://trustee.ietf.org/license-info).		(https://trustee.ietf.org/license-info).
	The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL		This version of this YANG module is part of RFC 8528;
	NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',		see the RFC itself for full legal notices.";
	'MAY', and 'OPTIONAL' in the module text are to be interpreted
	as described in BCP 14 [RFC 2119] [RFC8174] when, and only when,
	they appear in all capitals, as shown here.
	This version of this YANG module is part of RFC XXXX
	(https://tools.ietf.org/html/rfcXXXX); see the RFC itself for
	full legal notices.";
	// RFC Ed.: update the date below with the date of RFC publication		revision 2019-01-14 {
	// and remove this note.
	revision 2018-10-16 {
	description		description
	"Initial revision.";		"Initial revision.";
	reference		reference
	"RFC XXXX: YANG Schema Mount";		"RFC 8528: YANG Schema Mount";
	}		}
	/*		/*
	* Extensions		* Extensions
	*/		*/
	extension mount-point {		extension mount-point {
	argument label;		argument label;
	description		description
	"The argument 'label' is a YANG identifier, i.e., it is of the		"The argument 'label' is a YANG identifier, i.e., it is of the
	type 'yang:yang-identifier'.		type 'yang:yang-identifier'.
	skipping to change at page 14, line 19 ¶		skipping to change at page 15, line 6 ¶
	argument label;		argument label;
	description		description
	"The argument 'label' is a YANG identifier, i.e., it is of the		"The argument 'label' is a YANG identifier, i.e., it is of the
	type 'yang:yang-identifier'.		type 'yang:yang-identifier'.
	The 'mount-point' statement MUST NOT be used in a YANG		The 'mount-point' statement MUST NOT be used in a YANG
	version 1 module, neither explicitly nor via a 'uses'		version 1 module, neither explicitly nor via a 'uses'
	statement.		statement.
	The 'mount-point' statement MAY be present as a substatement		The 'mount-point' statement MAY be present as a substatement
	of 'container' and 'list', and MUST NOT be present elsewhere.		of 'container' and 'list' and MUST NOT be present elsewhere.
	There MUST NOT be more than one 'mount-point' statement in a		There MUST NOT be more than one 'mount-point' statement in a
	given 'container' or 'list' statement.		given 'container' or 'list' statement.
	If a mount point is defined within a grouping, its label is		If a mount point is defined within a grouping, its label is
	bound to the module where the grouping is used.		bound to the module where the grouping is used.
	A mount point defines a place in the node hierarchy where		A mount point defines a place in the node hierarchy where
	other data models may be attached. A server that implements a		other data models may be attached. A server that implements a
	module with a mount point populates the		module with a mount point populates the
	/schema-mounts/mount-point list with detailed information on		'/schema-mounts/mount-point' list with detailed information on
	which data models are mounted at each mount point.		which data models are mounted at each mount point.
	Note that the 'mount-point' statement does not define a new		Note that the 'mount-point' statement does not define a new
	data node.";		data node.";
	}		}
	/*		/*
	* State data nodes		* State data nodes
	*/		*/
	skipping to change at page 15, line 39 ¶		skipping to change at page 16, line 27 ¶
	type yang:yang-identifier;		type yang:yang-identifier;
	description		description
	"Label of the mount point defined using the 'mount-point'		"Label of the mount point defined using the 'mount-point'
	extension.";		extension.";
	}		}
	leaf config {		leaf config {
	type boolean;		type boolean;
	default "true";		default "true";
	description		description
	"If this leaf is set to 'false', then all data nodes in the		"If this leaf is set to 'false', then all data nodes in the
	mounted schema are read-only (config false), regardless of		mounted schema are read-only ('config false'), regardless
	their 'config' property.";		of their 'config' property.";
	}		}
	choice schema-ref {		choice schema-ref {
	mandatory true;		mandatory true;
	description		description
	"Alternatives for specifying the schema.";		"Alternatives for specifying the schema.";
	container inline {		container inline {
	presence		presence
	"A complete self-contained schema is mounted at the		"A complete self-contained schema is mounted at the
	mount point.";		mount point.";
	description		description
	skipping to change at page 16, line 44 ¶		skipping to change at page 17, line 34 ¶
	- The accessible tree is the parent data tree		- The accessible tree is the parent data tree
	*without* any nodes defined in modules that are		*without* any nodes defined in modules that are
	mounted inside the parent schema.		mounted inside the parent schema.
	- The context position and context size are both equal		- The context position and context size are both equal
	to 1.		to 1.
	- The set of variable bindings is empty.		- The set of variable bindings is empty.
	- The function library is the core function library		- The function library is the core function library
	defined in [XPath] and the functions defined in		defined in the W3C XPath 1.0 document
	Section 10 of [RFC7950].		(http://www.w3.org/TR/1999/REC-xpath-19991116) and
			the functions defined in Section 10 of RFC 7950.
	- The set of namespace declarations is defined by the		- The set of namespace declarations is defined by the
	'namespace' list under 'schema-mounts'.		'namespace' list under 'schema-mounts'.
	Each XPath expression MUST evaluate to a nodeset		Each XPath expression MUST evaluate to a node-set
	(possibly empty). For the purposes of evaluating XPath		(possibly empty). For the purposes of evaluating
	expressions whose context nodes are defined in the		XPath expressions whose context nodes are defined in
	mounted schema, the union of all these nodesets		the mounted schema, the union of all these node-sets
	together with ancestor nodes are added to the		together with ancestor nodes are added to the
	accessible data tree.		accessible data tree.
	Note that in the case 'ietf-yang-schema-mount' is		Note that in the case 'ietf-yang-schema-mount' is
	itself mounted, a 'parent-reference' in the mounted		itself mounted, a 'parent-reference' in the mounted
	module may refer to nodes that were brought into the		module may refer to nodes that were brought into the
	accessible tree through a 'parent-reference' in the		accessible tree through a 'parent-reference' in the
	parent schema.";		parent schema.";
	}		}
	}		}
	}		}
	}		}
	}		}
	}		}
	<CODE ENDS>		<CODE ENDS>
	10. IANA Considerations		10. IANA Considerations
	skipping to change at page 17, line 25 ¶		skipping to change at page 18, line 16 ¶
	}		}
	}		}
	}		}
	}		}
	}		}
	<CODE ENDS>		<CODE ENDS>
	10. IANA Considerations		10. IANA Considerations
	This document registers a URI in the IETF XML registry [RFC3688].		This document registers a URI in the "IETF XML Registry" [RFC3688].
	Following the format in RFC 3688, the following registration is
	requested to be made.
	URI: urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount		URI: urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount
	Registrant Contact: The IESG.		Registrant Contact: The IESG.
	XML: N/A, the requested URI is an XML namespace.		XML: N/A, the requested URI is an XML namespace.
	This document registers a YANG module in the YANG Module Names		This document registers a YANG module in the "YANG Module Names"
	registry [RFC6020].		registry [RFC6020].
	name: ietf-yang-schema-mount		name: ietf-yang-schema-mount
	namespace: urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount		namespace: urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount
	prefix: yangmnt		prefix: yangmnt
	reference: RFC XXXX		reference: RFC 8528
	11. Security Considerations		11. Security Considerations
	YANG module "ietf-yang-schema-mount" specified in this document		The YANG module specified in this document defines a schema for data
	defines a schema for data that is designed to be accessed via network		that is designed to be accessed via network management protocols such
	management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040].		as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer
	The lowest NETCONF layer is the secure transport layer, and the		is the secure transport layer, and the mandatory-to-implement secure
	mandatory-to-implement secure transport is Secure Shell (SSH)		transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer
	[RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-		is HTTPS, and the mandatory-to-implement secure transport is TLS
	implement secure transport is TLS [RFC5246].		[RFC8446].
	The network configuration access control model [RFC8341] provides the		The Network Configuration Access Control Model (NACM) [RFC8341]
	means to restrict access for particular NETCONF or RESTCONF users to		provides the means to restrict access for particular NETCONF or
	a preconfigured subset of all available NETCONF or RESTCONF protocol		RESTCONF users to a preconfigured subset of all available NETCONF or
	operations and content.		RESTCONF protocol operations and content.
	Some of the readable data nodes in this YANG module may be considered		Some of the readable data nodes in this YANG module may be considered
	sensitive or vulnerable in some network environments. It is thus		sensitive or vulnerable in some network environments. It is thus
	important to control read access (e.g., via get, get-config, or		important to control read access (e.g., via get, get-config, or
	notification) to these data nodes. These are the subtrees and data		notification) to these data nodes. These are the subtrees and data
	nodes and their sensitivity/vulnerability:		nodes and their sensitivity/vulnerability:
	o /schema-mounts: The schema defined by this state data provides		o /schema-mounts: The schema defined by this state data provides
	detailed information about a server implementation may help an		detailed information about a server implementation that may help
	attacker identify the server capabilities and server		an attacker identify the server capabilities and server
	implementations with known bugs. Server vulnerabilities may be		implementations with known bugs. Server vulnerabilities may be
	specific to particular modules included in the schema, module		specific to particular modules included in the schema, module
	revisions, module features, or even module deviations. For		revisions, module features, or even module deviations. For
	example, if a particular operation on a particular data node is		example, if a particular operation on a particular data node is
	known to cause a server to crash or significantly degrade device		known to cause a server to crash or significantly degrade device
	performance, then the schema information will help an attacker		performance, then the schema information will help an attacker
	identify server implementations with such a defect, in order to		identify server implementations with such a defect, in order to
	launch a denial-of-service attack on the device.		launch a denial-of-service attack on the device.
	It is important to take the security considerations for all nodes in		It is important to take into account the security considerations for
	the mounted schemas into account, and control access to these nodes		all nodes in the mounted schemas and to control access to these nodes
	by using the mechanism described in Section 7.		by using the mechanism described in Section 7.
	Care must be taken when the "parent-reference" XPath expressions are		Care must be taken when the "parent-reference" XPath expressions are
	constructed, since the result of the evaluation of these expressions		constructed, since the result of the evaluation of these expressions
	is added to the accessible tree for any XPath expression found in the		is added to the accessible tree for any XPath expression found in the
	mounted schema.		mounted schema.
	12. Contributors		12. References
	The idea of having some way to combine schemas from different YANG
	modules into one has been proposed independently by several groups of
	people: Alexander Clemm, Jan Medved, and Eric Voit
	([I-D.clemm-netmod-mount]); and Lou Berger and Christian Hopps:
	o Lou Berger, LabN Consulting, L.L.C., <lberger@labn.net>
	o Alexander Clemm, Huawei, <alexander.clemm@huawei.com>
	o Christian Hopps, Deutsche Telekom, <chopps@chopps.org>
	o Jan Medved, Cisco, <jmedved@cisco.com>
	o Eric Voit, Cisco, <evoit@cisco.com>
	13. References
	13.1. Normative References
	[I-D.ietf-netconf-rfc7895bis]		12.1. Normative References
	Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K.,
	and R. Wilton, "YANG Library", draft-ietf-netconf-
	rfc7895bis-06 (work in progress), April 2018.
	[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, <https://www.rfc-		DOI 10.17487/RFC2119, March 1997,
	editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,		[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
	DOI 10.17487/RFC3688, January 2004, <https://www.rfc-		DOI 10.17487/RFC3688, January 2004,
	editor.org/info/rfc3688>.		<https://www.rfc-editor.org/info/rfc3688>.
	[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
	(TLS) Protocol Version 1.2", RFC 5246,
	DOI 10.17487/RFC5246, August 2008, <https://www.rfc-
	editor.org/info/rfc5246>.
	[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for		[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
	the Network Configuration Protocol (NETCONF)", RFC 6020,		the Network Configuration Protocol (NETCONF)", RFC 6020,
	DOI 10.17487/RFC6020, October 2010, <https://www.rfc-		DOI 10.17487/RFC6020, October 2010,
	editor.org/info/rfc6020>.		<https://www.rfc-editor.org/info/rfc6020>.
			[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
			and A. Bierman, Ed., "Network Configuration Protocol
			(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
			<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>.
	[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",		[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
	RFC 6991, DOI 10.17487/RFC6991, July 2013,		RFC 6991, DOI 10.17487/RFC6991, July 2013,
	<https://www.rfc-editor.org/info/rfc6991>.		<https://www.rfc-editor.org/info/rfc6991>.
	[RFC7895] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module		[RFC7895] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module
	Library", RFC 7895, DOI 10.17487/RFC7895, June 2016,		Library", RFC 7895, DOI 10.17487/RFC7895, June 2016,
	<https://www.rfc-editor.org/info/rfc7895>.		<https://www.rfc-editor.org/info/rfc7895>.
	[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>.
			[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
			Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
			<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
	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>.
	[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration		[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
	Access Control Model", STD 91, RFC 8341,		Access Control Model", STD 91, RFC 8341,
	DOI 10.17487/RFC8341, March 2018, <https://www.rfc-		DOI 10.17487/RFC8341, March 2018,
	editor.org/info/rfc8341>.		<https://www.rfc-editor.org/info/rfc8341>.
	[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,		[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
	and R. Wilton, "Network Management Datastore Architecture		and R. Wilton, "Network Management Datastore Architecture
	(NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,		(NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
	<https://www.rfc-editor.org/info/rfc8342>.		<https://www.rfc-editor.org/info/rfc8342>.
			[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
			Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
			<https://www.rfc-editor.org/info/rfc8446>.
			[RFC8525] Bierman, A., Bjorklund, M., Schoenwaelder, J., Watsen, K.,
			and R. Wilton, "YANG Library", RFC 8525,
			DOI 10.17487/RFC8525, March 2019,
			<https://www.rfc-editor.org/info/rfc8525>.
	[XPATH] Clark, J. and S. DeRose, "XML Path Language (XPath)		[XPATH] Clark, J. and S. DeRose, "XML Path Language (XPath)
	Version 1.0", World Wide Web Consortium Recommendation		Version 1.0", World Wide Web Consortium Recommendation
	REC-xpath-19991116, November 1999,		REC-xpath-19991116, November 1999,
	<http://www.w3.org/TR/1999/REC-xpath-19991116>.		<http://www.w3.org/TR/1999/REC-xpath-19991116>.
	13.2. Informative References		12.2. Informative References
	[I-D.clemm-netmod-mount]
	Clemm, A., Voit, E., and J. Medved, "Mounting YANG-Defined
	Information from Remote Datastores", draft-clemm-netmod-
	mount-06 (work in progress), March 2017.
	[I-D.ietf-isis-yang-isis-cfg]
	Litkowski, S., Yeung, D., Lindem, A., Zhang, Z., and L.
	Lhotka, "YANG Data Model for IS-IS protocol", draft-ietf-
	isis-yang-isis-cfg-24 (work in progress), August 2018.
	[I-D.ietf-rtgwg-device-model]
	Lindem, A., Berger, L., Bogdanovic, D., and C. Hopps,
	"Network Device YANG Logical Organization", draft-ietf-
	rtgwg-device-model-02 (work in progress), March 2017.
	[I-D.ietf-rtgwg-lne-model]
	Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X.
	Liu, "YANG Model for Logical Network Elements", draft-
	ietf-rtgwg-lne-model-10 (work in progress), March 2018.
	[I-D.ietf-rtgwg-ni-model]
	Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X.
	Liu, "YANG Model for Network Instances", draft-ietf-rtgwg-
	ni-model-12 (work in progress), March 2018.
	[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,		[DEVICE-YANG]
	and A. Bierman, Ed., "Network Configuration Protocol		Lindem, A., Ed., Berger, L., Ed., Bogdanovic, D., and C.
	(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,		Hopps, "Network Device YANG Logical Organization", Work in
	<https://www.rfc-editor.org/info/rfc6241>.		Progress, draft-ietf-rtgwg-device-model-02, March 2017.
	[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF		[IS-IS-YANG]
	Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,		Litkowski, S., Yeung, D., Lindem, A., Zhang, J., and L.
	<https://www.rfc-editor.org/info/rfc8040>.		Lhotka, "YANG Data Model for IS-IS protocol", Work in
			Progress, draft-ietf-isis-yang-isis-cfg-34, January 2019.
	[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>.
	[RFC8343] Bjorklund, M., "A YANG Data Model for Interface		[RFC8343] Bjorklund, M., "A YANG Data Model for Interface
	Management", RFC 8343, DOI 10.17487/RFC8343, March 2018,		Management", RFC 8343, DOI 10.17487/RFC8343, March 2018,
	<https://www.rfc-editor.org/info/rfc8343>.		<https://www.rfc-editor.org/info/rfc8343>.
			[RFC8529] Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and
			X. Liu, "YANG Data Model for Network Instances", RFC 8529,
			DOI 10.17487/RFC8529, March 2019,
			<https://www.rfc-editor.org/info/rfc8529>.
			[RFC8530] Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and
			X. Liu, "YANG Model for Logical Network Elements",
			RFC 8530, DOI 10.17487/RFC8530, March 2019,
			<https://www.rfc-editor.org/info/rfc8530>.
			[YANG-MOUNT]
			Clemm, A., Voit, E., and J. Medved, "Mounting YANG-Defined
			Information from Remote Datastores", Work in Progress,
			draft-clemm-netmod-mount-06, March 2017.
	Appendix A. Example: Device Model with LNEs and NIs		Appendix A. Example: Device Model with LNEs and NIs
	This non-normative example demonstrates an implementation of the		This non-normative example demonstrates an implementation of the
	device model as specified in Section 2 of		device model as specified in Section 2 of [DEVICE-YANG], using both
	[I-D.ietf-rtgwg-device-model], using both logical network elements		logical network elements (LNEs) and network instances (NIs).
	(LNE) and network instances (NI).
	In these examples, the character '\' is used where a line break has		In these examples, the character '\' is used where a line break has
	been inserted for formatting reasons.		been inserted for formatting reasons.
	A.1. Physical Device		A.1. Physical Device
	The data model for the physical device may be described by this YANG		The data model for the physical device may be described by this YANG
	library content, assuming the server supports the NMDA:		library content, assuming the server supports the NMDA:
	{		{
	skipping to change at page 22, line 15 ¶		skipping to change at page 22, line 51 ¶
	"namespace":		"namespace":
	"urn:ietf:params:xml:ns:yang:ietf-interfaces"		"urn:ietf:params:xml:ns:yang:ietf-interfaces"
	},		},
	{		{
	"name": "ietf-ip",		"name": "ietf-ip",
	"revision": "2018-02-22",		"revision": "2018-02-22",
	"namespace": "urn:ietf:params:xml:ns:yang:ietf-ip"		"namespace": "urn:ietf:params:xml:ns:yang:ietf-ip"
	},		},
	{		{
	"name": "ietf-logical-network-element",		"name": "ietf-logical-network-element",
	"revision": "2016-10-21",		"revision": "2018-03-20",
	"feature": [ "bind-lne-name" ],		"feature": [ "bind-lne-name" ],
	"namespace":		"namespace":
	"urn:ietf:params:xml:ns:yang:\		"urn:ietf:params:xml:ns:yang:\
	ietf-logical-network-element"		ietf-logical-network-element"
	},		},
	{		{
	"name": "ietf-yang-library",		"name": "ietf-yang-library",
	"revision": "2018-02-21",		"revision": "2019-01-04",
	"namespace":		"namespace":
	"urn:ietf:params:xml:ns:yang:ietf-yang-library"		"urn:ietf:params:xml:ns:yang:ietf-yang-library"
	},		},
	{		{
	"name": "ietf-yang-schema-mount",		"name": "ietf-yang-schema-mount",
	"revision": "2018-03-20",		"revision": "2019-01-14",
	"namespace":		"namespace":
	"urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount"		"urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount"
	}		}
	],		],
	"import-only-module": [		"import-only-module": [
	{		{
	"name": "ietf-inet-types",		"name": "ietf-inet-types",
	"revision": "2013-07-15",		"revision": "2013-07-15",
	"namespace":		"namespace":
	"urn:ietf:params:xml:ns:yang:ietf-inet-types"		"urn:ietf:params:xml:ns:yang:ietf-inet-types"
	skipping to change at page 23, line 17 ¶		skipping to change at page 24, line 4 ¶
	],		],
	"datastore": [		"datastore": [
	{		{
	"name": "ietf-datastores:running",		"name": "ietf-datastores:running",
	"schema": "physical-device-schema"		"schema": "physical-device-schema"
	},		},
	{		{
	"name": "ietf-datastores:operational",		"name": "ietf-datastores:operational",
	"schema": "physical-device-schema"		"schema": "physical-device-schema"
	}		}
	]		]
	}		}
	}		}
	A.2. Logical Network Elements		A.2. Logical Network Elements
	Each LNE can have a specific data model that is determined at run		Each LNE can have a specific data model that is determined at run
	time, so it is appropriate to mount it using the "inline" method,		time, so it is appropriate to mount it using the "inline" method.
	hence the following "schema-mounts" data:		Hence, the following "schema-mounts" data is used:
	{		{
	"ietf-yang-schema-mount:schema-mounts": {		"ietf-yang-schema-mount:schema-mounts": {
	"mount-point": [		"mount-point": [
	{		{
	"module": "ietf-logical-network-element",		"module": "ietf-logical-network-element",
	"label": "root",		"label": "root",
	"inline": {}		"inline": {}
	}		}
	]		]
	}		}
	}		}
	An administrator of the host device has to configure an entry for		An administrator of the host device has to configure an entry for
	each LNE instance, for example,		each LNE instance, for example:
	{		{
	"ietf-interfaces:interfaces": {		"ietf-interfaces:interfaces": {
	"interface": [		"interface": [
	{		{
	"name": "eth0",		"name": "eth0",
	"type": "iana-if-type:ethernetCsmacd",		"type": "iana-if-type:ethernetCsmacd",
	"enabled": true,		"enabled": true,
	"ietf-logical-network-element:bind-lne-name": "eth0"		"ietf-logical-network-element:bind-lne-name": "eth0"
	}		}
	]		]
	skipping to change at page 24, line 27 ¶		skipping to change at page 25, line 4 ¶
	{		{
	"name": "lne-1",		"name": "lne-1",
	"managed": true,		"managed": true,
	"description": "LNE with NIs",		"description": "LNE with NIs",
	"root": {		"root": {
	...		...
	}		}
	}		}
	...		...
	]		]
	}		}
	}		}
	and then also place necessary state data as the contents of the		and then also place necessary state data as the contents of the
	"root" instance, which should include at least		"root" instance, which should include at least:
	o YANG library data specifying the LNE's data model, for example,		o YANG library data specifying the LNE's data model, for example,
	assuming the server does not implement the NMDA:		assuming the server does not implement the NMDA:
	{		{
	"ietf-yang-library:modules-state": {		"ietf-yang-library:modules-state": {
	"module-set-id": "9358e11874068c8be06562089e94a89e0a392019",		"module-set-id": "9358e11874068c8be06562089e94a89e0a392019",
	"module": [		"module": [
	{		{
	"name": "iana-if-type",		"name": "iana-if-type",
	skipping to change at page 25, line 25 ¶		skipping to change at page 25, line 51 ¶
	"name": "ietf-ip",		"name": "ietf-ip",
	"revision": "2014-06-16",		"revision": "2014-06-16",
	"feature": [		"feature": [
	"ipv6-privacy-autoconf"		"ipv6-privacy-autoconf"
	],		],
	"namespace": "urn:ietf:params:xml:ns:yang:ietf-ip",		"namespace": "urn:ietf:params:xml:ns:yang:ietf-ip",
	"conformance-type": "implement"		"conformance-type": "implement"
	},		},
	{		{
	"name": "ietf-network-instance",		"name": "ietf-network-instance",
	"revision": "2016-10-27",		"revision": "2018-03-20",
	"feature": [		"feature": [
	"bind-network-instance-name"		"bind-network-instance-name"
	],		],
	"namespace":		"namespace":
	"urn:ietf:params:xml:ns:yang:ietf-network-instance",		"urn:ietf:params:xml:ns:yang:ietf-network-instance",
	"conformance-type": "implement"		"conformance-type": "implement"
	},		},
	{		{
	"name": "ietf-yang-library",		"name": "ietf-yang-library",
	"revision": "2016-06-21",		"revision": "2016-06-21",
	"namespace": "urn:ietf:params:xml:ns:yang:ietf-yang-library",		"namespace": "urn:ietf:params:xml:ns:yang:ietf-yang-library",
	"conformance-type": "implement"		"conformance-type": "implement"
	},		},
	{		{
	"name": "ietf-yang-schema-mount",		"name": "ietf-yang-schema-mount",
	"revision": "2017-05-16",		"revision": "2019-01-14",
	"namespace":		"namespace":
	"urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount",		"urn:ietf:params:xml:ns:yang:ietf-yang-schema-mount",
	"conformance-type": "implement"		"conformance-type": "implement"
	},		},
	{		{
	"name": "ietf-yang-types",		"name": "ietf-yang-types",
	"revision": "2013-07-15",		"revision": "2013-07-15",
	"namespace": "urn:ietf:params:xml:ns:yang:ietf-yang-types",		"namespace": "urn:ietf:params:xml:ns:yang:ietf-yang-types",
	"conformance-type": "import"		"conformance-type": "import"
	}		}
	skipping to change at page 27, line 41 ¶		skipping to change at page 28, line 8 ¶
	Note also that the "ietf-interfaces" module appears in the		Note also that the "ietf-interfaces" module appears in the
	"parent-reference" leaf-list for the mounted NI schema. This means		"parent-reference" leaf-list for the mounted NI schema. This means
	that references to LNE interfaces, such as "outgoing-interface" in		that references to LNE interfaces, such as "outgoing-interface" in
	static routes, are valid despite the fact that "ietf-interfaces"		static routes, are valid despite the fact that "ietf-interfaces"
	isn't part of the NI schema.		isn't part of the NI schema.
	A.4. Invoking an RPC Operation		A.4. Invoking an RPC Operation
	Assume that the mounted NI data model also implements the "ietf-isis"		Assume that the mounted NI data model also implements the "ietf-isis"
	module [I-D.ietf-isis-yang-isis-cfg]. An RPC operation defined in		module [IS-IS-YANG]. An RPC operation defined in this module, such
	this module, such as "clear-adjacency", can be invoked by a client		as "clear-adjacency", can be invoked by a client session of an LNE's
	session of a LNE's RESTCONF server as an action tied to a the mount		RESTCONF server as an action tied to the mount point of a particular
	point of a particular network instance using a request URI like this		network instance using a request URI like this (all on one line):
	(all on one line):
	POST /restconf/data/ietf-network-instance:network-instances/		POST /restconf/data/ietf-network-instance:network-instances/
	network-instance=rtrA/root/ietf-isis:clear-adjacency HTTP/1.1		network-instance=rtrA/root/ietf-isis:clear-adjacency HTTP/1.1
			Contributors
			The idea of having some way to combine schemas from different YANG
			modules into one has been proposed independently by others:
			o Authors of [YANG-MOUNT]:
			* Lou Berger, LabN Consulting, L.L.C., <lberger@labn.net>
			* Alexander Clemm, Huawei, <alexander.clemm@huawei.com>
			* Christian Hopps, Deutsche Telekom, <chopps@chopps.org>
			o Jan Medved, Cisco, <jmedved@cisco.com>
			o Eric Voit, Cisco, <evoit@cisco.com>
	Authors' Addresses		Authors' Addresses
	Martin Bjorklund		Martin Bjorklund
	Tail-f Systems		Tail-f Systems
	Email: mbj@tail-f.com		Email: mbj@tail-f.com
	Ladislav Lhotka		Ladislav Lhotka
	CZ.NIC		CZ.NIC
End of changes. 116 change blocks.
	346 lines changed or deleted		325 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/