draft-ietf-netmod-schema-mount-05.txt		draft-ietf-netmod-schema-mount-06.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: November 17, 2017 CZ.NIC		Expires: January 6, 2018 CZ.NIC
	May 16, 2017		July 5, 2017
	YANG Schema Mount		YANG Schema Mount
	draft-ietf-netmod-schema-mount-05		draft-ietf-netmod-schema-mount-06
	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 November 17, 2017.		This Internet-Draft will expire on January 6, 2018.
	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 10 ¶		skipping to change at page 2, line 10 ¶
	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 . . . . . . . . . . . . . . . . . . . . . . . . 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. Namespace Prefixes . . . . . . . . . . . . . . . . . . . 6
	2.3. Namespace Prefixes . . . . . . . . . . . . . . . . . . . 6		3. Schema Mount . . . . . . . . . . . . . . . . . . . . . . . . 6
	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 . . . . . . . . . . . . . 9		3.3. Multiple Levels of Schema Mount . . . . . . . . . . . . . 9
	4. Referring to Data Nodes in the Parent Schema . . . . . . . . 9		4. Referring to Data Nodes in the Parent Schema . . . . . . . . 9
	5. RPC operations and Notifications . . . . . . . . . . . . . . 10		5. RPC operations and Notifications . . . . . . . . . . . . . . 10
	6. Implementation Notes . . . . . . . . . . . . . . . . . . . . 11		6. Implementation Notes . . . . . . . . . . . . . . . . . . . . 11
	7. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 11		7. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 11
	8. Schema Mount YANG Module . . . . . . . . . . . . . . . . . . 13		8. Schema Mount YANG Module . . . . . . . . . . . . . . . . . . 13
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 18		10. Security Considerations . . . . . . . . . . . . . . . . . . . 18
	11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18		11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
	12.1. Normative References . . . . . . . . . . . . . . . . . . 19		12.1. Normative References . . . . . . . . . . . . . . . . . . 19
	12.2. Informative References . . . . . . . . . . . . . . . . . 19		12.2. Informative References . . . . . . . . . . . . . . . . . 19
	Appendix A. Example: Device Model with LNEs and NIs . . . . . . 20		Appendix A. Example: Device Model with LNEs and NIs . . . . . . 20
	A.1. Physical Device . . . . . . . . . . . . . . . . . . . . . 20		A.1. Physical Device . . . . . . . . . . . . . . . . . . . . . 21
	A.2. Logical Network Elements . . . . . . . . . . . . . . . . 22		A.2. Logical Network Elements . . . . . . . . . . . . . . . . 22
	A.3. Network Instances . . . . . . . . . . . . . . . . . . . . 25		A.3. Network Instances . . . . . . . . . . . . . . . . . . . . 25
	A.4. Invoking an RPC Operation . . . . . . . . . . . . . . . . 27		A.4. Invoking an RPC Operation . . . . . . . . . . . . . . . . 26
	Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 27		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
	B.1. RPC Operations and Notifications in Mounted Modules . . . 27
	B.2. Tree Representation . . . . . . . . . . . . . . . . . . . 27
	B.3. Design-Time Mounts . . . . . . . . . . . . . . . . . . . 28
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
	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 4, line 38 ¶		skipping to change at page 4, line 35 ¶
	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 attached to the mount point so that the labeled data node		be attached to the mount point so that the labeled data node
	effectively becomes the root node of the mounted data model.		effectively 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 module. In this case, the mounted schema has		point in the parent YANG module. In this case, the mounted
	to be the same for every implementation of the parent module.		schema has to be the same for every implementation of the parent
			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 YANG library information, i.e.,		implementor and is as stable as YANG library information, i.e.,
	it may change after an upgrade of server software but not after		it may change after an upgrade of server software but not after
	rebooting the server. Also, a client can learn the entire schema		rebooting the server. Also, a client can learn the entire schema
	together with YANG library data.		together with YANG library data.
	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 because design-time definition of the		only for the latter two cases. Design-time mounts are outside the
	mounted schema doesn't play well with the existing YANG modularity		scope of this document, and could be possibly dealt with in a future
	mechanisms. For example, it would be impossible to augment the		revision of the YANG data modeling language.
	mounted data model.
	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.
	This document allows mounting of complete data models only. Other		This document allows mounting of complete data models only. Other
	specifications may extend this model by defining additional		specifications may extend this model by defining additional
	skipping to change at page 6, line 6 ¶		skipping to change at page 6, line 4 ¶
	o container		o container
	o list		o list
	o operation		o operation
	The following terms are defined in [RFC7223] and are not redefined		The following terms are defined in [RFC7223] and are not redefined
	here:		here:
	o system-controlled interface		o system-controlled interface
			Tree diagrams used in this document follow the notation defined in
			[I-D.ietf-netmod-yang-tree-diagrams].
	2.1. Glossary of New Terms		2.1. Glossary of New Terms
	o inline schema: a mounted schema whose definition is provided as		o inline schema: a mounted schema whose definition is provided as
	part of the mounted data, using YANG library [RFC7895].		part of the mounted data, using YANG library [RFC7895].
	o mount point: container or list node whose definition contains the		o mount point: container or list node whose definition contains the
	"mount-point" extension statement. The argument of the		"mount-point" extension statement. The argument of the
	"mount-point" statement defines the name of the mount point.		"mount-point" statement defines the name of the mount point.
	o parent schema (of a particular mounted schema): the schema that		o parent schema (of a particular mounted schema): the schema that
	contains the mount point for the mounted schema.		contains the mount point for the mounted schema.
	o top-level schema: a schema according to [RFC7950] in which schema		o top-level schema: a schema according to [RFC7950] in which schema
	trees of each module (except augments) start at the root node.		trees of each module (except augments) start at the root node.
	2.2. Tree Diagrams		2.2. Namespace Prefixes
	A simplified graphical representation of the data model is used in
	this document. The meaning of the symbols in these diagrams is as
	follows:
	o Brackets "[" and "]" enclose list keys.
	o Abbreviations before data node names: "rw" means configuration
	data (read-write) and "ro" state data (read-only).
	o Symbols after data node names: "?" means an optional node, "!"
	means a presence container, and "*" denotes a list and leaf-list.
	o Parentheses enclose choice and case nodes, and case nodes are also
	marked with a colon (":").
	o Ellipsis ("...") stands for contents of subtrees that are not
	shown.
	2.3. 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, as long as
	it is clear from the context in which YANG module each name is		it is clear from the context in which YANG module each name is
	defined. Otherwise, names are prefixed using the standard prefix		defined. Otherwise, names are prefixed using the standard prefix
	associated with the corresponding YANG module, as shown in Table 1.		associated with the corresponding YANG module, as shown in Table 1.
	+---------+------------------------+-----------+		+---------+------------------------+-----------+
	| Prefix | YANG module | Reference |		| Prefix | YANG module | Reference |
	+---------+------------------------+-----------+		+---------+------------------------+-----------+
	skipping to change at page 8, line 5 ¶		skipping to change at page 7, line 33 ¶
	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		Mounted schemas for all mount points in the parent schema are
	determined from state data in the "yangmnt:schema-mounts" container.		determined from state data in the "yangmnt:schema-mounts" container.
	Data in this container is intended to be as stable as data in the		Data in this container is intended to be as stable as data in the
	top-level YANG library [RFC7895]. In particular, it SHOULD NOT		top-level YANG library [RFC7895]. In particular, it SHOULD NOT
	change during the same management session.		change during the same management session.
			Generally, the modules that are mounted under a mount point have no
			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
			and, if present, its data will generally have no relationship to the
			data of the parent. Exceptions are possible and such needs to be
			defined in the model defining the exception, e.g., the interface
			module in [I-D.ietf-rtgwg-lne-model].
	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 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
	skipping to change at page 8, line 52 ¶		skipping to change at page 8, line 39 ¶
	expected to retrieve this data from the instance tree, possibly after		expected to retrieve this data from the instance tree, possibly after
	creating the mount point. Instances of the same mount point MAY use		creating the mount point. Instances of the same mount point MAY use
	different mounted schemas.		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. In this case,		"schema" entries referred to in the "use-schema" list. In this case,
	the mounted schema is specified as implementation-time data that can		the mounted schema is specified as implementation-time data that can
	be retrieved together with YANG library data for the parent schema,		be retrieved together with YANG library data for the parent schema,
	i.e., even before any instances of the mount point exist. However,		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		the mounted schema has to be the same for all instances of the mount
	point.		point. Note, that in this case a mount point may include a mounted
			YANG library module and the data contained in the mounted module MUST
			exactly match the data contained in the "schema" entries associated
			with the mount point.
	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. Note that this includes modules that solely augment other
			listed modules;
	o (optionally) a new "mount-point" list that applies to mount points		o (optionally) a new "mount-point" list that applies to 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
	skipping to change at page 11, line 5 ¶		skipping to change at page 11, line 5 ¶
	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
	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
			contained within a list node without a "key" statement (see section
			7.15 and 7.16 of [RFC7950]). Therefore, to be useful, mount points
			which contain modules with RPCs, actions, and notifications SHOULD
			NOT have any ancestor node that is a list node without a "key"
			statement. This requirement applies to the definition of modules
			using the "mount-point" extension statement.
	6. Implementation Notes		6. 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:		implementations 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
	skipping to change at page 12, line 9 ¶		skipping to change at page 12, line 9 ¶
	7. Data Model		7. 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
	| +--ro ns-uri? inet:uri		| +--ro uri? inet:uri
	+--ro mount-point* [module name]		+--ro mount-point* [module name]
	| +--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
	skipping to change at page 13, line 9 ¶		skipping to change at page 13, line 9 ¶
	+--:(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 parent-reference* yang:xpath1.0		+--ro parent-reference* yang:xpath1.0
	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-05-16.yang"		<CODE BEGINS> file "ietf-yang-schema-mount@2017-06-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 14, 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-05-16 {		revision 2017-06-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 17, line 38 ¶		skipping to change at page 17, line 38 ¶
	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 'parent-reference' 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 uri {
	type inet:uri;		type inet:uri;
	description		description
	"Namespace URI reference.";		"Namespace URI reference.";
	}		}
	}		}
	uses mount-point-list;		uses mount-point-list;
	list schema {		list schema {
	key "name";		key "name";
	description		description
	"Each entry specifies a schema that can be mounted at a mount		"Each entry specifies a schema that can be mounted at a mount
	skipping to change at page 19, line 20 ¶		skipping to change at page 19, line 20 ¶
	o Jan Medved, Cisco, <jmedved@cisco.com>		o Jan Medved, Cisco, <jmedved@cisco.com>
	o Eric Voit, Cisco, <evoit@cisco.com>		o Eric Voit, Cisco, <evoit@cisco.com>
	12. References		12. References
	12.1. Normative References		12.1. Normative References
	[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/
	DOI 10.17487/RFC2119, March 1997,		RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://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,		DOI 10.17487/RFC3688, January 2004,
	<http://www.rfc-editor.org/info/rfc3688>.		<http://www.rfc-editor.org/info/rfc3688>.
	[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,		DOI 10.17487/RFC6020, October 2010,
	<http://www.rfc-editor.org/info/rfc6020>.		<http://www.rfc-editor.org/info/rfc6020>.
	[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",		[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC
	RFC 6991, DOI 10.17487/RFC6991, July 2013,		6991, DOI 10.17487/RFC6991, July 2013,
	<http://www.rfc-editor.org/info/rfc6991>.		<http://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,
	<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>.
	skipping to change at page 20, line 10 ¶		skipping to change at page 20, line 10 ¶
	[I-D.clemm-netmod-mount]		[I-D.clemm-netmod-mount]
	Clemm, A., Voit, E., and J. Medved, "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-06 (work in progress), March 2017.		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-17 (work in progress), March 2017.		isis-yang-isis-cfg-17 (work in progress), March 2017.
			[I-D.ietf-netmod-yang-tree-diagrams]
			Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft-
			ietf-netmod-yang-tree-diagrams-01 (work in progress), June
			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 Logical Organization", draft-ietf-		"Network Device YANG Logical Organization", draft-ietf-
	rtgwg-device-model-02 (work in progress), March 2017.		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., Bogdanovic, D., and X.
	"YANG Logical Network Elements", draft-ietf-rtgwg-lne-		Liu, "YANG Logical Network Elements", draft-ietf-rtgwg-
	model-02 (work in progress), March 2017.		lne-model-03 (work in progress), July 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., Bogdanovic, D., and X.
	"YANG Network Instances", draft-ietf-rtgwg-ni-model-02		Liu, "YANG Network Instances", draft-ietf-rtgwg-ni-
	(work in progress), March 2017.		model-03 (work in progress), July 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>.
	skipping to change at page 23, line 35 ¶		skipping to change at page 23, line 35 ¶
	...		...
	]		]
	}		}
	}		}
	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:
	"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",
	"revision": "2014-05-08",		"revision": "2014-05-08",
	"namespace": "urn:ietf:params:xml:ns:yang:iana-if-type",		"namespace": "urn:ietf:params:xml:ns:yang:iana-if-type",
	"conformance-type": "implement"		"conformance-type": "implement"
	},		},
	{		{
	"name": "ietf-inet-types",		"name": "ietf-inet-types",
	"revision": "2013-07-15",		"revision": "2013-07-15",
	"namespace": "urn:ietf:params:xml:ns:yang:ietf-inet-types",		"namespace": "urn:ietf:params:xml:ns:yang:ietf-inet-types",
	"conformance-type": "import"		"conformance-type": "import"
	},		},
	{		{
	"name": "ietf-interfaces",		"name": "ietf-interfaces",
	"revision": "2014-05-08",		"revision": "2014-05-08",
	"feature": [		"feature": [
	"arbitrary-names",		"arbitrary-names",
	"pre-provisioning"		"pre-provisioning"
	],		],
	"namespace": "urn:ietf:params:xml:ns:yang:ietf-interfaces",		"namespace": "urn:ietf:params:xml:ns:yang:ietf-interfaces",
	"conformance-type": "implement"		"conformance-type": "implement"
	},		},
	{		{
	"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": "2016-10-27",
	"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": "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"
	}		}
	]		]
	}		}
	o state data for interfaces assigned to the LNE instance (that		o state data for interfaces assigned to the LNE instance (that
	effectively become system-controlled interfaces for the LNE), for		effectively become system-controlled interfaces for the LNE), for
	example:		example:
	"ietf-interfaces:interfaces-state": {		"ietf-interfaces:interfaces-state": {
	"interface": [		"interface": [
	{		{
	"name": "eth0",		"name": "eth0",
	"type": "iana-if-type:ethernetCsmacd",		"type": "iana-if-type:ethernetCsmacd",
	"oper-status": "up",		"oper-status": "up",
	"statistics": {		"statistics": {
	"discontinuity-time": "2016-12-16T17:11:27+02:00"		"discontinuity-time": "2016-12-16T17:11:27+02:00"
	},
	"ietf-ip:ipv6": {
	"address": [
	{
	"ip": "fe80::42a8:f0ff:fea8:24fe",
	"origin": "link-layer",
	"prefix-length": 64
	}
	]
	}
	},		},
	...		"ietf-ip:ipv6": {
	]		"address": [
	}		{
			"ip": "fe80::42a8:f0ff:fea8:24fe",
			"origin": "link-layer",
			"prefix-length": 64
			}
			]
			}
			},
			...
			]
			}
	A.3. Network Instances		A.3. Network Instances
	Assuming that network instances share the same data model, it can be		Assuming that network instances share the same data model, it can be
	mounted using the "use-schema" method as follows:		mounted using the "use-schema" method as follows:
	"ietf-yang-schema-mount:schema-mounts": {		"ietf-yang-schema-mount:schema-mounts": {
	"mount-point": [		"namespace": [
	{		{
	"module": "ietf-network-instance",		"prefix": "if",
	"name": "root",		"uri": "urn:ietf:params:xml:ns:yang:ietf-interfaces"
	"parent-reference": ["ietf-interfaces"],		}
	"use-schema": [		],
	{		"mount-point": [
	"name": "ni-schema"		{
	}		"module": "ietf-network-instance",
	]		"name": "root",
	}		"use-schema": [
	],		{
	"schema": [		"name": "ni-schema",
	{		"parent-reference": ["/if:interfaces"]
	"name": "ni-schema",		}
	"module": [
	{		]
	"name": "ietf-ipv4-unicast-routing",		}
	"revision": "2016-11-04",		],
	"namespace":		"schema": [
	"urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing",		{
	"conformance-type": "implement"		"name": "ni-schema",
	},		"module": [
	{		{
	"name": "ietf-ipv6-unicast-routing",		"name": "ietf-ipv4-unicast-routing",
	"revision": "2016-11-04",		"revision": "2016-11-04",
	"namespace":		"namespace":
	"urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing",		"urn:ietf:params:xml:ns:yang:ietf-ipv4-unicast-routing",
	"conformance-type": "implement"		"conformance-type": "implement"
	},		},
	{		{
	"name": "ietf-routing",		"name": "ietf-ipv6-unicast-routing",
	"revision": "2016-11-04",		"revision": "2016-11-04",
	"feature": [		"namespace":
	"multiple-ribs",		"urn:ietf:params:xml:ns:yang:ietf-ipv6-unicast-routing",
	"router-id"		"conformance-type": "implement"
	],		},
	"namespace": "urn:ietf:params:xml:ns:yang:ietf-routing",		{
	"conformance-type": "implement"		"name": "ietf-routing",
	}		"revision": "2016-11-04",
	]		"feature": [
	}		"multiple-ribs",
	]		"router-id"
	}		],
			"namespace": "urn:ietf:params:xml:ns:yang:ietf-routing",
			"conformance-type": "implement"
			}
			]
			}
			]
			}
	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 [I-D.ietf-isis-yang-isis-cfg]. An RPC operation defined in
	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
	B.1. RPC Operations and Notifications in Mounted Modules
	Turning RPC operations defined in mounted modules into actions tied
	to the corresponding mount point (see Section 5, and similarly for
	notifications) is not possible if the path to the mount point in the
	parent schema contains a keyless list (Section 7.15 of [RFC7950]).
	The solutions for this corner case are possible:
	1. any mount point MUST NOT have a keyless list among its ancestors
	2. any mounted module MUST NOT contain RPC operations and/or
	notifications
	3. specifically for each mount point, at least one of the above
	conditions MUST be satisfied.
	4. treat such actions and notifications as non-existing, i.e.,
	ignore them.
	The first two requirements seem rather restrictive. On the other
	hand, the last one is difficult to guarantee - for example, things
	can break after an augment within the mounted schema.
	B.2. Tree Representation
	Need to decide how/if mount points are represented in trees.
	B.3. Design-Time Mounts
	The document currently doesn't provide explicit support for design-
	time mounts. Design-time mounts have been identified as possibly for
	multiple cases, and it may be worthwhile to identify a minimum or
	complete set of modules that must be supported under a mount point.
	This could be used in service modules that want to allow for
	configuration of device-specific information. One option could be to
	add an extension that specify that a certain module is required to be
	mounted.
	Also, if design-time mounts are supported, it could be possible to
	represent both mounts points and their required modules in tree
	representations and support for such would need to be defined.
	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. 29 change blocks.
	234 lines changed or deleted		198 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/