draft-ietf-netmod-schema-mount-04.txt		draft-ietf-netmod-schema-mount-05.txt
	Network Working Group M. Bjorklund		Network Working Group M. Bjorklund
	Internet-Draft Tail-f Systems		Internet-Draft Tail-f Systems
	Intended status: Standards Track L. Lhotka		Intended status: Standards Track L. Lhotka
	Expires: September 7, 2017 CZ.NIC		Expires: November 17, 2017 CZ.NIC
	March 6, 2017		May 16, 2017
	YANG Schema Mount		YANG Schema Mount
	draft-ietf-netmod-schema-mount-04		draft-ietf-netmod-schema-mount-05
	Abstract		Abstract
	This document defines a mechanism to combine YANG modules into the		This document defines a mechanism to combine YANG modules into the
	schema defined in other YANG modules.		schema defined in other YANG modules.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	skipping to change at page 1, line 32 ¶		skipping to change at page 1, line 32 ¶
	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 September 7, 2017.		This Internet-Draft will expire on November 17, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 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
	skipping to change at page 2, line 15 ¶		skipping to change at page 2, line 15 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology and Notation . . . . . . . . . . . . . . . . . . 5		2. Terminology and Notation . . . . . . . . . . . . . . . . . . 5
	2.1. Glossary of New Terms . . . . . . . . . . . . . . . . . . 6		2.1. Glossary of New Terms . . . . . . . . . . . . . . . . . . 6
	2.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 6		2.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 6
	2.3. Namespace Prefixes . . . . . . . . . . . . . . . . . . . 6		2.3. Namespace Prefixes . . . . . . . . . . . . . . . . . . . 6
	3. Schema Mount . . . . . . . . . . . . . . . . . . . . . . . . 7		3. Schema Mount . . . . . . . . . . . . . . . . . . . . . . . . 7
	3.1. Mount Point Definition . . . . . . . . . . . . . . . . . 7		3.1. Mount Point Definition . . . . . . . . . . . . . . . . . 7
	3.2. Specification of the Mounted Schema . . . . . . . . . . . 7		3.2. Specification of the Mounted Schema . . . . . . . . . . . 7
	3.3. Multiple Levels of Schema Mount . . . . . . . . . . . . . 11		3.3. Multiple Levels of Schema Mount . . . . . . . . . . . . . 9
	4. Refering to Data Nodes in the Parent Schema . . . . . . . . . 11		4. Referring to Data Nodes in the Parent Schema . . . . . . . . 9
	5. RPC operations and Notifications . . . . . . . . . . . . . . 12		5. RPC operations and Notifications . . . . . . . . . . . . . . 10
	6. Implementation Notes . . . . . . . . . . . . . . . . . . . . 13		6. Implementation Notes . . . . . . . . . . . . . . . . . . . . 11
	7. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 13		7. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 11
	8. Schema Mount YANG Module . . . . . . . . . . . . . . . . . . 15		8. Schema Mount YANG Module . . . . . . . . . . . . . . . . . . 13
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 21		10. Security Considerations . . . . . . . . . . . . . . . . . . . 18
	11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 21		11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
	12.1. Normative References . . . . . . . . . . . . . . . . . . 21		12.1. Normative References . . . . . . . . . . . . . . . . . . 19
	12.2. Informative References . . . . . . . . . . . . . . . . . 22		12.2. Informative References . . . . . . . . . . . . . . . . . 19
	Appendix A. Example: Device Model with LNEs and NIs . . . . . . 23		Appendix A. Example: Device Model with LNEs and NIs . . . . . . 20
	A.1. Physical Device . . . . . . . . . . . . . . . . . . . . . 23		A.1. Physical Device . . . . . . . . . . . . . . . . . . . . . 20
	A.2. Logical Network Elements . . . . . . . . . . . . . . . . 24		A.2. Logical Network Elements . . . . . . . . . . . . . . . . 22
	A.3. Network Instances . . . . . . . . . . . . . . . . . . . . 27		A.3. Network Instances . . . . . . . . . . . . . . . . . . . . 25
	A.4. Invoking an RPC Operation . . . . . . . . . . . . . . . . 29		A.4. Invoking an RPC Operation . . . . . . . . . . . . . . . . 27
	Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 29		Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 27
	B.1. Referencing Mount Points Using Schema Node Identifiers . 29		B.1. RPC Operations and Notifications in Mounted Modules . . . 27
	B.2. Defining the "mount-point" Extension in a Separate Module 30		B.2. Tree Representation . . . . . . . . . . . . . . . . . . . 27
	B.3. Parent References . . . . . . . . . . . . . . . . . . . . 31		B.3. Design-Time Mounts . . . . . . . . . . . . . . . . . . . 28
	B.4. RPC Operations and Notifications in Mounted Modules . . . 31		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
	B.5. Tree Representation . . . . . . . . . . . . . . . . . . . 32
	B.6. Design-Time Mounts . . . . . . . . . . . . . . . . . . . 32
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
	1. Introduction		1. Introduction
	Modularity and extensibility were among the leading design principles		Modularity and extensibility were 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 and thus
	form a data model that is tailored to meet the requirements of a		form a data model that is tailored to meet the requirements of a
	specific use case. Server implementors are only required to specify		specific use case. Server implementors are only required to specify
	all YANG modules comprising the data model (together with their		all YANG modules comprising the data model (together with their
	revisions and other optional choices) in the YANG library data		revisions and other optional choices) in the YANG library data
	skipping to change at page 7, line 49 ¶		skipping to change at page 7, line 47 ¶
	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" statement MUST NOT be used in a YANG version 1
	module. Note, however, that modules written in any YANG version,		module. Note, however, that modules written in any YANG version,
	including version 1, can be mounted under a mount point.		including version 1, can be mounted under a mount point.
	3.2. Specification of the Mounted Schema		3.2. Specification of the Mounted Schema
	Mounted schemas for all mount points in the parent schema are defined		Mounted schemas for all mount points in the parent schema are
	as state data in the "yangmnt:schema-mounts" container. Data in this		determined from state data in the "yangmnt:schema-mounts" container.
	container is intended to be as stable as data in the top-level YANG		Data in this container is intended to be as stable as data in the
	library [RFC7895]. In particular, it SHOULD NOT change during the		top-level YANG library [RFC7895]. In particular, it SHOULD NOT
	same management session.		change during the same management session.
	The "schema-mount" container has the "mount-point" list as one of its		The "schema-mounts" container has the "mount-point" list as one of
	children. Every entry of this list refers through its key to a mount		its children. Every entry of this list refers through its key to a
	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 above		i.e., instances of that mount point MUST NOT contain any data above
	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 overriden 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:
	1. The mount point is itself defined as "config false".		o the mount point is itself defined as "config false"
	2. 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:		two different ways:
	1. by stating that the schema is available inline, i.e., in run-time		1. by stating that the schema is available inline, i.e., in run-time
	instance data; or		instance data; or
	2. by referring to one or more entries of the "schema" list in the		2. by referring to one or more entries of the "schema" list in the
	same instance of "schema-mounts".		same instance of "schema-mounts".
	In case 1, every instance of the mount point that exists in the		In case 1, the mounted schema is determined at run time: every
	parent tree MUST contain a copy of YANG library data [RFC7895] that		instance of the mount point that exists in the parent tree MUST
	defines the mounted schema exactly as for a top-level data model. A		contain a copy of YANG library data [RFC7895] that defines the
	client is expected to retrieve this data from the instance tree,		mounted schema exactly as for a top-level data model. A client is
	possibly after creating the mount point. Instances of the same mount		expected to retrieve this data from the instance tree, possibly after
	point MAY use different mounted schemas.		creating the mount point. Instances of the same mount point MAY use
			different mounted schemas.
	In case 2, the mounted schema is defined by the combination of all		In case 2, the mounted schema is defined by the combination of all
	"schema" entries referred to in the "use-schema" list. Optionally, a		"schema" entries referred to in the "use-schema" list. In this case,
	reference to a "schema" entry can be made conditional by including		the mounted schema is specified as implementation-time data that can
	the "when" leaf. Its argument is an XPath expression that is		be retrieved together with YANG library data for the parent schema,
	evaluated in the parent tree with the mount point instance as the		i.e., even before any instances of the mount point exist. However,
	context node. The conditional "schema" entry is used only if the		the mounted schema has to be the same for all instances of the mount
	XPath expression evaluates to true. XPath expressions in the		point.
	argument of "when" may use namespace prefixes that are declared in
	the "namespace" list (child of "schema-mounts").
	Conditional schemas may be used, for example, in a situation where
	virtual devices are of several different types and the schema for
	each type is fixed and known in advance. The list of virtual devices
	in a parent schema module (say "example-virtual-host") might be
	defined as follows:
	list virtual-device {
	key name;
	leaf name {
	type string;
	}
	leaf type {
	type identityref {
	base virtual-device-type;
	}
	}
	container root {
	yangmnt:mount-point virtual-device;
	}
	The "schema-mounts" specification in state data might contain, for
	example,
	"yangmnt:schema-mounts": {
	"namespace": [
	{
	"prefix": "evh",
	"ns-uri": "http://example.org/ns/example-virtual-host"
	}
	],
	"mount-point": [
	{
	"module": "example-virtual-host",
	"name": "root",
	"use-schema": [
	{
	"name": "virtual-router-schema",
	"when": "derived-from(../evh:type, 'evh:virtual-router')"
	},
	{
	"name": "virtual-switch-schema",
	"when": "derived-from(../evh:type, 'evh:virtual-switch')"
	}
	],
	"schema": [
	{
	"name": "virtual-router-schema",
	"module": [
	...
	]
	},
	{
	"name": "virtual-switch-schema",
	"module": [
	...
	]
	}
	]
	}
	The schema of virtual device instances can then be controlled by
	setting the "type" leaf to an appropriate identity derived from the
	"virtual-device-type" base.
	In case 2, the mounted schema is specified as implementation-time
	data that can be retrieved together with YANG library data for the
	parent schema, i.e., even before any instances of the mount point
	exist. However, the mounted schema has to be the same for all
	instances of the mount point (except for parts that are conditional
	due to "when" leaves).
	Each entry of the "schema" list contains		Each entry of the "schema" list contains
	o a list in the YANG library format specifying all YANG modules (and		o a list in the YANG library format specifying all YANG modules (and
	revisions etc.) that are implemented or imported in the mounted		revisions etc.) that are implemented or imported in the mounted
	schema;		schema;
	o (optionally) a new "schema-mounts" specification that applies to		o (optionally) a new "mount-point" list that applies to mount points
	mount points defined within the mounted schema.		defined within the mounted schema.
	3.3. Multiple Levels of Schema Mount		3.3. 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 subschemas can be mounted. Consequently, it is possible to		which subschemas can be mounted. Consequently, it is possible to
	construct data models with an arbitrary number of schema levels. A		construct data models with an arbitrary number of schema levels. A
	subschema for a mount point contained in a mounted module can be		subschema for a mount point contained in a mounted module can be
	specified in one of the following ways:		specified in one of the following ways:
	o by implementing "ietf-yang-library" and "ietf-yang-schema-mount"		o by implementing "ietf-yang-library" and "ietf-yang-schema-mount"
	modules in the mounted schema, and specifying the subschemas		modules in the mounted schema, and specifying the subschemas
	exactly as it is done in the top-level schema		exactly as it is done in the top-level schema
	o by using the "mount-point" list inside the coresponding "schema"		o by using the "mount-point" list inside the corresponding "schema"
	entry.		entry.
	The former method is applicable to both "inline" and "use-schema"		The former method is applicable to both "inline" and "use-schema"
	cases whereas the latter requires the "use-schema" case. On the		cases whereas the latter requires the "use-schema" case. On the
	other hand, the latter method allows for a compact representation of		other hand, the latter method allows for a compact representation of
	a multi-level schema the does not rely on the presence of any		a multi-level schema the does not rely on the presence of any
	instance data.		instance data.
	4. Refering 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
	data model works exactly as a top-level data model, i.e., it is		data model works exactly as a top-level data model, i.e., it is
	confined to the "mount jail". This means that all paths in the		confined to the "mount jail". This means that all paths in the
	mounted data model (in leafrefs, instance-identifiers, XPath		mounted data model (in leafrefs, instance-identifiers, XPath
	expressions, and target nodes of augments) are interpreted with the		expressions, and target nodes of augments) are interpreted with the
	mount point as the root node. YANG modules of the mounted schema as		mount point as the root node. YANG modules of the mounted schema as
	well as corresponding instance data thus cannot refer to schema nodes		well as corresponding instance data thus cannot refer to schema nodes
	or instance data outside the mount jail.		or 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
	are network instances (NI) [I-D.ietf-rtgwg-ni-model], where each NI		is network instances (NI) [I-D.ietf-rtgwg-ni-model], where each NI
	has its own routing engine but the list of interfaces is global and		has its own routing engine but the list of interfaces is global and
	shared by all NIs. If we want to model this organization with the NI		shared by all NIs. If we want to model this organization with the NI
	schema mounted using schema mount, the overall schema tree would look		schema 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]
	skipping to change at page 12, line 21 ¶		skipping to change at page 10, line 21 ¶
	+--rw root		+--rw root
	+--rw routing		+--rw routing
	...		...
	Here, the "root" node is the mount point for the NI schema. Routing		Here, the "root" node is the mount point for the NI schema. Routing
	configuration inside an NI often needs to refer to interfaces (at		configuration inside an NI often needs to refer to interfaces (at
	least those that are assigned to the NI), which is impossible unless		least those that are assigned to the NI), which is impossible unless
	such a reference can point to a node in the parent schema (interface		such a reference can point to a node in the parent schema (interface
	name).		name).
	Therefore, schema mount also allows for such references, albeit in a		Therefore, schema mount also allows for such references. For every
	limited and controlled way. The "schema-mounts" container has a		schema mounted using the "use-schema" method, it is possible to
	child leaf-list named "parent-reference" that contains zero or more		specify a leaf-list named "parent-reference" that contains zero or
	module names. All modules appearing in this leaf-list MUST be		more XPath 1.0 expressions. Each expression is evaluated with the
	implemented in the parent schema and MUST NOT be implemented in the		root of the parent data tree as the context node and the result MUST
	mounted schema. All absolute leafref paths and instance identifiers		be a nodeset (see the description of the "parent-reference" node for
	within the mounted data model and corresponding instance data tree		a complete definition of the evaluation context). For the purposes
	are then evaluated as follows:		of evaluating XPath expressions within the mounted data tree, the
			union of all such nodesets is added to the accessible data tree.
	o If the leftmost node-identifier (right after the initial slash)		It is worth emphasizing that
	belongs to the namespace of a module that is listed in
	"parent-reference", then the root of the accessible tree is not
	the mount point but the root of the parent schema.
	o Other rules for the "leafref" and "instance-identifier" types as		o The nodes specified in "parent-reference" leaf-list are available
	defined in Sections 9.9 and 9.13 of [RFC7950] remain in effect.		in the mounted schema only for XPath evaluations. In particular,
			they cannot be accessed there via network management protocols
			such as NETCONF [RFC6241] or RESTCONF [RFC8040].
	It is worth emphasizing that the mount jail can be escaped only via		o The mechanism of referencing nodes in the parent schema is not
	absolute leafref paths and instance identifiers. Relative leafref		available for schemas mounted using the "inline" method.
	paths, "must"/"when" expressions and schema node identifiers are
	still restricted to the mounted schema.
	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 by representing it as an action defined for the		this operation by representing it as an action defined 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
	skipping to change at page 14, line 21 ¶		skipping to change at page 12, line 21 ¶
	| +--ro module yang:yang-identifier		| +--ro module yang:yang-identifier
	| +--ro name yang:yang-identifier		| +--ro name yang:yang-identifier
	| +--ro config? boolean		| +--ro config? boolean
	| +--ro (schema-ref)?		| +--ro (schema-ref)?
	| +--:(inline)		| +--:(inline)
	| | +--ro inline? empty		| | +--ro inline? empty
	| +--:(use-schema)		| +--:(use-schema)
	| +--ro use-schema* [name]		| +--ro use-schema* [name]
	| +--ro name		| +--ro name
	| | -> /schema-mounts/schema/name		| | -> /schema-mounts/schema/name
	| +--ro when? yang:xpath1.0		| +--ro parent-reference* yang:xpath1.0
	| +--ro parent-reference* yang:yang-identifier
	+--ro schema* [name]		+--ro schema* [name]
	+--ro name string		+--ro name string
	+--ro module* [name revision]		+--ro module* [name revision]
	| +--ro name yang:yang-identifier		| +--ro name yang:yang-identifier
	| +--ro revision union		| +--ro revision union
	| +--ro schema? inet:uri		| +--ro schema? inet:uri
	| +--ro namespace inet:uri		| +--ro namespace inet:uri
	| +--ro feature* yang:yang-identifier		| +--ro feature* yang:yang-identifier
	| +--ro deviation* [name revision]		| +--ro deviation* [name revision]
	| | +--ro name yang:yang-identifier		| | +--ro name yang:yang-identifier
	skipping to change at page 14, line 50 ¶		skipping to change at page 12, line 49 ¶
	+--ro module yang:yang-identifier		+--ro module yang:yang-identifier
	+--ro name yang:yang-identifier		+--ro name yang:yang-identifier
	+--ro config? boolean		+--ro config? boolean
	+--ro (schema-ref)?		+--ro (schema-ref)?
	+--:(inline)		+--:(inline)
	| +--ro inline? empty		| +--ro inline? empty
	+--:(use-schema)		+--:(use-schema)
	+--ro use-schema* [name]		+--ro use-schema* [name]
	+--ro name		+--ro name
	| -> /schema-mounts/schema/name		| -> /schema-mounts/schema/name
	+--ro when? yang:xpath1.0		+--ro parent-reference* yang:xpath1.0
	+--ro parent-reference* yang:yang-identifier
	8. Schema Mount YANG Module		8. Schema Mount YANG Module
	This module references [RFC6991] and [RFC7895].		This module references [RFC6991] and [RFC7895].
	<CODE BEGINS> file "ietf-yang-schema-mount@2017-03-06.yang"		<CODE BEGINS> file "ietf-yang-schema-mount@2017-05-16.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 16, line 24 ¶		skipping to change at page 14, line 24 ¶
	The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL		The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
	NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and		NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and
	'OPTIONAL' in the module text are to be interpreted as described		'OPTIONAL' in the module text are to be interpreted as described
	in RFC 2119 (https://tools.ietf.org/html/rfc2119).		in RFC 2119 (https://tools.ietf.org/html/rfc2119).
	This version of this YANG module is part of RFC XXXX		This version of this YANG module is part of RFC XXXX
	(https://tools.ietf.org/html/rfcXXXX); see the RFC itself for		(https://tools.ietf.org/html/rfcXXXX); see the RFC itself for
	full legal notices.";		full legal notices.";
	revision 2017-03-06 {		revision 2017-05-16 {
	description		description
	"Initial revision.";		"Initial revision.";
	reference		reference
	"RFC XXXX: YANG Schema Mount";		"RFC XXXX: YANG Schema Mount";
	}		}
	/*		/*
	* Extensions		* Extensions
	*/		*/
	skipping to change at page 18, line 22 ¶		skipping to change at page 16, line 22 ¶
	"This leaf indicates that the server has mounted		"This leaf indicates that the server has mounted
	'ietf-yang-library' and 'ietf-schema-mount' at the mount		'ietf-yang-library' and 'ietf-schema-mount' at the mount
	point, and their instantiation (i.e., state data		point, and their instantiation (i.e., state data
	containers 'yanglib:modules-state' and 'schema-mounts')		containers 'yanglib:modules-state' and 'schema-mounts')
	provides the information about the mounted schema.";		provides the information about the mounted schema.";
	}		}
	list use-schema {		list use-schema {
	key "name";		key "name";
	description		description
	"Each entry of this list contains a reference to a schema		"Each entry of this list contains a reference to a schema
	defined in the /schema-mounts/schema list. The entry can		defined in the /schema-mounts/schema list.";
	be made conditional by specifying an XPath expression in
	the 'when' leaf.";
	leaf name {		leaf name {
	type leafref {		type leafref {
	path "/schema-mounts/schema/name";		path "/schema-mounts/schema/name";
	}		}
	description		description
	"Name of the referenced schema.";		"Name of the referenced schema.";
	}		}
	leaf when {		leaf-list parent-reference {
	type yang:xpath1.0;		type yang:xpath1.0;
	description		description
	"This leaf contains an XPath expression. If it is		"Entries of this leaf-list are XPath 1.0 expressions
	present, then the current entry applies if and only if		that are evaluated in the following context:
	the expression evaluates to true.
	The XPath expression is evaluated once for each		- The context node is the root node of the parent data
	instance of the data node containing the mount		tree.
	point for which the 'when' leaf is defined.
	The XPath expression is evaluated using the rules		- The accessible tree is the parent data tree
	specified in sec. 6.4 of RFC 7950, with these		*without* any nodes defined in modules that are
	modifications:		mounted inside the parent schema.
	- The context node is the data node instance		- The context position and context size are both equal
	containing the corresponding 'mount-point'		to 1.
	statement.
	- The accessible tree contains only data belonging to		- The set of variable bindings is empty.
	the parent schema, i.e., all instances of data
	nodes containing the mount points are considered
	empty.
	- The set of namespace declarations is the set of all		- The function library is the core function library
	prefix/namespace pairs defined in the		defined in [XPath] and the functions defined in
	/schema-mounts/namespace list. Names without a		Section 10 of [RFC7950].
	namespace prefix belong to the same namespace as the
	context node.";
	}
	leaf-list parent-reference {
	type yang:yang-identifier;
	must "not(/schema-mounts/schema[name=current()/../name]/"
	+ "module[name=current() and conformance-type="
	+ "'implement'])" {
	error-message "Parent references cannot be used for a "
	+ "module implemented in the mounted schema.";
	description
	"Modules that are used for parent references MUST NOT
	be implemented in the mounted schema.";
	}
	description
	"Entries of this leaf-list are names of YANG modules.
	All these modules MUST be implemented in the parent
	schema.
	Within the mounted schema and the corresponding data		- The set of namespace declarations is defined by the
	tree, conceptual evaluation of absolute leafref paths		'namespace' list under 'schema-mounts'.
	and instance identifiers is modified in the following
	way:
	If the leftmost node-identifier in an absolute leafref		Each XPath expression MUST evaluate to a nodeset
	path or instance identifier belongs to a module whose		(possibly empty). For the purposes of evaluating XPath
	name is listed in 'parent-reference', then the root		expressions whose context nodes are defined in the
	of the accessible data tree coincides with the root of		mounted schema, the union of all these nodesets
	the parent data tree.";		together with ancestor nodes are added to the
			accessible data tree.";
	}		}
	}		}
	}		}
	}		}
	}		}
	/*		/*
	* State data nodes		* State data nodes
	*/		*/
	container schema-mounts {		container schema-mounts {
	config false;		config false;
	description		description
	"Contains information about the structure of the overall		"Contains information about the structure of the overall
	mounted data model implemented in the server.";		mounted data model implemented in the server.";
	list namespace {		list namespace {
	key "prefix";		key "prefix";
	description		description
	"This list provides a mapping of namespace prefixes that are		"This list provides a mapping of namespace prefixes that are
	used in XPath expressions of 'when' leafs to the		used in XPath expressions of 'parent-reference' leafs to the
	corresponding namespace URI references.";		corresponding namespace URI references.";
	leaf prefix {		leaf prefix {
	type yang:yang-identifier;		type yang:yang-identifier;
	description		description
	"Namespace prefix.";		"Namespace prefix.";
	}		}
	leaf ns-uri {		leaf ns-uri {
	type inet:uri;		type inet:uri;
	description		description
	"Namespace URI reference.";		"Namespace URI reference.";
	skipping to change at page 22, line 34 ¶		skipping to change at page 19, line 48 ¶
	Library", RFC 7895, DOI 10.17487/RFC7895, June 2016,		Library", RFC 7895, DOI 10.17487/RFC7895, June 2016,
	<http://www.rfc-editor.org/info/rfc7895>.		<http://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,
	<http://www.rfc-editor.org/info/rfc7950>.		<http://www.rfc-editor.org/info/rfc7950>.
	12.2. Informative References		12.2. Informative References
	[I-D.clemm-netmod-mount]		[I-D.clemm-netmod-mount]
	Clemm, A., Medved, J., and E. Voit, "Mounting YANG-Defined		Clemm, A., Voit, E., and J. Medved, "Mounting YANG-Defined
	Information from Remote Datastores", draft-clemm-netmod-		Information from Remote Datastores", draft-clemm-netmod-
	mount-05 (work in progress), September 2016.		mount-06 (work in progress), March 2017.
	[I-D.ietf-isis-yang-isis-cfg]		[I-D.ietf-isis-yang-isis-cfg]
	Litkowski, S., Yeung, D., Lindem, A., Zhang, Z., and L.		Litkowski, S., Yeung, D., Lindem, A., Zhang, Z., and L.
	Lhotka, "YANG Data Model for IS-IS protocol", draft-ietf-		Lhotka, "YANG Data Model for IS-IS protocol", draft-ietf-
	isis-yang-isis-cfg-15 (work in progress), February 2017.		isis-yang-isis-cfg-17 (work in progress), March 2017.
	[I-D.ietf-rtgwg-device-model]		[I-D.ietf-rtgwg-device-model]
	Lindem, A., Berger, L., Bogdanovic, D., and C. Hopps,		Lindem, A., Berger, L., Bogdanovic, D., and C. Hopps,
	"Network Device YANG Organizational Models", draft-ietf-		"Network Device YANG Logical Organization", draft-ietf-
	rtgwg-device-model-01 (work in progress), October 2016.		rtgwg-device-model-02 (work in progress), March 2017.
	[I-D.ietf-rtgwg-lne-model]		[I-D.ietf-rtgwg-lne-model]
	Berger, L., Hopps, C., Lindem, A., and D. Bogdanovic,		Berger, L., Hopps, C., Lindem, A., and D. Bogdanovic,
	"YANG Logical Network Elements", draft-ietf-rtgwg-lne-		"YANG Logical Network Elements", draft-ietf-rtgwg-lne-
	model-01 (work in progress), October 2016.		model-02 (work in progress), March 2017.
	[I-D.ietf-rtgwg-ni-model]		[I-D.ietf-rtgwg-ni-model]
	Berger, L., Hopps, C., Lindem, A., and D. Bogdanovic,		Berger, L., Hopps, C., Lindem, A., and D. Bogdanovic,
	"YANG Network Instances", draft-ietf-rtgwg-ni-model-01		"YANG Network Instances", draft-ietf-rtgwg-ni-model-02
	(work in progress), October 2016.		(work in progress), March 2017.
	[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,
	<http://www.rfc-editor.org/info/rfc6241>.		<http://www.rfc-editor.org/info/rfc6241>.
	[RFC7223] Bjorklund, M., "A YANG Data Model for Interface		[RFC7223] Bjorklund, M., "A YANG Data Model for Interface
	Management", RFC 7223, DOI 10.17487/RFC7223, May 2014,		Management", RFC 7223, DOI 10.17487/RFC7223, May 2014,
	<http://www.rfc-editor.org/info/rfc7223>.		<http://www.rfc-editor.org/info/rfc7223>.
			[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
			Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
			<http://www.rfc-editor.org/info/rfc8040>.
	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
	[I-D.ietf-rtgwg-device-model], using both logical network elements		[I-D.ietf-rtgwg-device-model], using both logical network elements
	(LNE) and network instances (NI).		(LNE) and network instances (NI).
	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
	skipping to change at page 24, line 31 ¶		skipping to change at page 21, line 50 ¶
	"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-03-06",		"revision": "2017-05-16",
	"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 4 ¶		skipping to change at page 24, line 39 ¶
	"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-03-06",		"revision": "2017-05-16",
	"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 29, line 22 ¶		skipping to change at page 27, line 22 ¶
	this module, such as "clear-adjacency", can be invoked by a client		this module, such as "clear-adjacency", can be invoked by a client
	session of a LNE's RESTCONF server as an action tied to a the mount		session of a LNE's RESTCONF server as an action tied to a the mount
	point of a particular network instance using a request URI like this		point of a particular 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
	Appendix B. Open Issues		Appendix B. Open Issues
	B.1. Referencing Mount Points Using Schema Node Identifiers		B.1. RPC Operations and Notifications in Mounted Modules
	Each entry in the "mount-point" list is currently identified by two
	keys, namely YANG module name and mount point name. An alternative
	is to use a schema node identifier of the mount point as a single
	key.
	For example, the "schema-mounts" data for NI (Appendix A.3) would be
	changed as follows (the "schema" list doesn't change):
	"ietf-yang-schema-mount:schema-mounts": {
	"namespace": [
	{
	"prefix": "ni",
	"ns-uri": "urn:ietf:params:xml:ns:yang:ietf-network-instance"
	}
	]
	"mount-point": [
	{
	"target": "/ni:network-instances/ni:network-instance/ni:root",
	"parent-reference": ["ietf-interfaces"],
	"use-schema": [
	{
	"name": "ni-schema"
	}
	]
	}
	],
	"schema": [
	...
	]
	}
	This change would have several advantages:
	o the schema mount mechanism becomes even closer to augments, which
	may simplify implementation
	o if a mount point appears inside a grouping, then a different
	mounted schema can be used for each use of the grouping.
	o it optionally allows for use of mount without use of the mount-
	point extension.
	B.2. Defining the "mount-point" Extension in a Separate Module
	The "inline" method of schema mounting can be further simplified by
	defining the "inline" case as the default. That is, if a mount point
	is defined through the "mount-point" extension but is not present in
	the "mount-point" list, the "inline" schema mount is assumed.
	Consequently, a data model that uses only the "inline" method could
	omit the "schema-mounts" data entirely, but it still needs to use the
	"mount-point" extension. In order to enable this, the definition of
	the "mount-point" extension has to be moved to a YANG module of its
	own.
	A variant of this approach is to completely separate the "inline" and
	"use-schema" cases by dedicating the "mount-point" extension for use
	with the "inline" method only (with no "schema-mounts" data), and
	using schema node identifiers as described in Appendix B.1 for the
	"use-schema" case.
	B.3. Parent References
	As explained in Section 4, references to the parent schema can only
	be used in absolute leafref paths and instance identifiers. However,
	it is conceivable that they may be useful in other XPath expressions,
	e.g. in "must" statements. The authors believe it is impossible to
	allow for parent references in general XPath expressions because, for
	example, in a location path "//foo:bar" it would be unclear whether
	the lookup has to be started in the mounted or parent schema.
	Should parent references in general XPath be needed, it would be
	necessary to indicate it explicitly. One way to achieve this is to
	defining a new XPath function, e.g., parent-root(), that returns the
	root of the parent data tree.
	B.4. RPC Operations and Notifications in Mounted Modules
	Turning RPC operations defined in mounted modules into actions tied		Turning RPC operations defined in mounted modules into actions tied
	to the corresponding mount point (see Section 5, and similarly for		to the corresponding mount point (see Section 5, and similarly for
	notifications) is not possible if the path to the mount point in the		notifications) is not possible if the path to the mount point in the
	parent schema contains a keyless list (Section 7.15 of [RFC7950]).		parent schema contains a keyless list (Section 7.15 of [RFC7950]).
	The solutions for this corner case are possible:		The solutions for this corner case are possible:
	1. any mount point MUST NOT have a keyless list among its ancestors		1. any mount point MUST NOT have a keyless list among its ancestors
	2. any mounted module MUST NOT contain RPC operations and/or		2. any mounted module MUST NOT contain RPC operations and/or
	skipping to change at page 32, line 5 ¶		skipping to change at page 27, line 45 ¶
	3. specifically for each mount point, at least one of the above		3. specifically for each mount point, at least one of the above
	conditions MUST be satisfied.		conditions MUST be satisfied.
	4. treat such actions and notifications as non-existing, i.e.,		4. treat such actions and notifications as non-existing, i.e.,
	ignore them.		ignore them.
	The first two requirements seem rather restrictive. On the other		The first two requirements seem rather restrictive. On the other
	hand, the last one is difficult to guarantee - for example, things		hand, the last one is difficult to guarantee - for example, things
	can break after an augment within the mounted schema.		can break after an augment within the mounted schema.
	B.5. Tree Representation		B.2. Tree Representation
	Need to decide how/if mount points are represented in trees.		Need to decide how/if mount points are represented in trees.
	B.6. Design-Time Mounts		B.3. Design-Time Mounts
	The document currently doesn't provide explicit support for design-		The document currently doesn't provide explicit support for design-
	time mounts. Design-time mounts have been identified as possibly for		time mounts. Design-time mounts have been identified as possibly for
	multiple cases, and it may be worthwhile to identify a minimum or		multiple cases, and it may be worthwhile to identify a minimum or
	complete set of modules that must be supported under a mount point.		complete set of modules that must be supported under a mount point.
	This could be used in service modules that want to allow for		This could be used in service modules that want to allow for
	configuration of device-specific information. One option could be to		configuration of device-specific information. One option could be to
	add an extension that specify that a certain module is required to be		add an extension that specify that a certain module is required to be
	mounted.		mounted.
End of changes. 47 change blocks.
	296 lines changed or deleted		118 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/