draft-ietf-netmod-schema-mount-11.txt		draft-ietf-netmod-schema-mount-12.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: February 8, 2019 CZ.NIC		Expires: April 20, 2019 CZ.NIC
	August 7, 2018		October 17, 2018
	YANG Schema Mount		YANG Schema Mount
	draft-ietf-netmod-schema-mount-11		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 to add the schema trees defined by
	a set of YANG modules onto a mount point defined in the schema tree		a set of YANG modules onto a mount point defined in the schema tree
	in some YANG module.		in some YANG module.
	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
	skipping to change at page 1, line 33 ¶		skipping to change at page 1, line 33 ¶
	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 February 8, 2019.		This Internet-Draft will expire on April 20, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 17 ¶		skipping to change at page 2, line 17 ¶
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology and Notation . . . . . . . . . . . . . . . . . . 5		2. Terminology and Notation . . . . . . . . . . . . . . . . . . 5
	2.1. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 6		2.1. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 6
	2.2. Namespace Prefixes . . . . . . . . . . . . . . . . . . . 6		2.2. 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. Data Model . . . . . . . . . . . . . . . . . . . . . . . 8		3.2. Data Model . . . . . . . . . . . . . . . . . . . . . . . 8
	3.3. Specification of the Mounted Schema . . . . . . . . . . . 8		3.3. Specification of the Mounted Schema . . . . . . . . . . . 8
	3.4. Multiple Levels of Schema Mount . . . . . . . . . . . . . 9		3.4. 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 . . . . . . . . . . . . . . 11
	6. Network Management Datastore Architecture (NMDA)		6. Network Management Datastore Architecture (NMDA)
	Considerations . . . . . . . . . . . . . . . . . . . . . . . 11		Considerations . . . . . . . . . . . . . . . . . . . . . . . 11
	7. Interaction with the Network Configuration Access Control		7. Interaction with the Network Configuration Access Control
	Model (NACM) . . . . . . . . . . . . . . . . . . . . . . . . 11		Model (NACM) . . . . . . . . . . . . . . . . . . . . . . . . 11
	8. Implementation Notes . . . . . . . . . . . . . . . . . . . . 12		8. Implementation Notes . . . . . . . . . . . . . . . . . . . . 12
	9. Schema Mount YANG Module . . . . . . . . . . . . . . . . . . 12		9. Schema Mount YANG Module . . . . . . . . . . . . . . . . . . 12
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 17		11. Security Considerations . . . . . . . . . . . . . . . . . . . 17
	12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18		12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . 18		13. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
	13.1. Normative References . . . . . . . . . . . . . . . . . . 18		13.1. Normative References . . . . . . . . . . . . . . . . . . 19
	13.2. Informative References . . . . . . . . . . . . . . . . . 20		13.2. Informative References . . . . . . . . . . . . . . . . . 20
	Appendix A. Example: Device Model with LNEs and NIs . . . . . . 21		Appendix A. Example: Device Model with LNEs and NIs . . . . . . 21
	A.1. Physical Device . . . . . . . . . . . . . . . . . . . . . 21		A.1. Physical Device . . . . . . . . . . . . . . . . . . . . . 21
	A.2. Logical Network Elements . . . . . . . . . . . . . . . . 23		A.2. Logical Network Elements . . . . . . . . . . . . . . . . 23
	A.3. Network Instances . . . . . . . . . . . . . . . . . . . . 26		A.3. Network Instances . . . . . . . . . . . . . . . . . . . . 26
	A.4. Invoking an RPC Operation . . . . . . . . . . . . . . . . 27		A.4. Invoking an RPC Operation . . . . . . . . . . . . . . . . 27
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
	1. Introduction		1. Introduction
	skipping to change at page 4, line 43 ¶		skipping to change at page 4, line 43 ¶
	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 YANG library information of the		implementor and is as stable as the YANG library information of
	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.
	skipping to change at page 6, line 20 ¶		skipping to change at page 6, line 20 ¶
	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 [I-D.ietf-netconf-rfc7895bis] is not
	redefined here:		redefined here:
	o YANG library checksum		o YANG library content identifier
	The following additional terms are used within 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" 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.
	skipping to change at page 9, line 27 ¶		skipping to change at page 9, line 27 ¶
	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 exactly as for a
	top-level schema. A client is expected to retrieve this data from		top-level schema. A client is expected to retrieve this data from
	the instance tree. In the "inline" case, instances of the same mount		the instance tree. In the "inline" case, instances of the same mount
	point MAY use different mounted schemas, whereas in the		point MAY use different mounted schemas, whereas in the
	"shared-schema" case, all instances MUST use the same mounted schema.		"shared-schema" case, all instances MUST use the same mounted schema.
	This means that in the "shared-schema" case, all instances of the		This means that in the "shared-schema" case, all instances of the
	same mount point MUST have the same YANG library checksum. In the		same mount point MUST have the same YANG library content identifier.
	"inline" case, if two instances have the same YANG library checksum		In the "inline" case, if two instances have the same YANG library
	it is not guaranteed that the YANG library contents are equal for		content identifier it is not guaranteed that the YANG library
	these instances.		contents are equal for these instances.
			Examples of "inline" and "shared-schema" can be found in Appendix A.2
			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 "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 the schemas exactly as it is done in the top-level schema.		specifying the schemas exactly as it is done in 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 expressions, and target		(in leafrefs, instance-identifiers, XPath [XPATH] expressions, and
	nodes of augments) are interpreted with the mount point as the root		target nodes of augments) are interpreted with the mount point as the
	node. YANG modules of the mounted schema as well as corresponding		root node. YANG modules of the mounted schema as well as
	instance data thus cannot refer to schema nodes or instance data		corresponding instance data thus cannot refer to schema nodes or
	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 (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]
	skipping to change at page 11, line 13 ¶		skipping to change at page 11, line 20 ¶
	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, inline actions and notifications will not work when they are
	contained within a list node without a "key" statement (see section		contained within a list node without a "key" statement (see section
	7.15 and 7.16 of [RFC7950]). Therefore, to be useful, mount points		7.15 and 7.16 of [RFC7950]). Therefore, to be useful, mount points
	which contain modules with RPCs, actions, and notifications SHOULD		that contain modules with RPCs, actions, and notifications SHOULD NOT
	NOT have any ancestor node that is a list node without a "key"		have any ancestor node that is a list node without a "key" statement.
	statement. This requirement applies to the definition of modules		This requirement applies to the definition of modules using the
	using the "mount-point" extension statement.		"mount-point" extension statement.
	6. Network Management Datastore Architecture (NMDA) Considerations		6. Network Management Datastore Architecture (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 both with 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		Note to RFC Editor: please update the date YYYY-MM-DD below with the
	revision of the ietf-yang-library in the published version of draft-		revision of the ietf-yang-library in the published version of draft-
	ietf-netconf-rfc7895bis, and remove this note.		ietf-netconf-rfc7895bis, and remove this note.
	Specifically, a server that doesn't support the NMDA, MAY implement		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 YYYY-MM-DD of "ietf-yang-library"
	[I-D.ietf-netconf-rfc7895bis] under the mount points.		[I-D.ietf-netconf-rfc7895bis] under the mount points.
	7. Interaction with the Network Configuration Access Control Model		7. Interaction with the Network Configuration Access Control Model
	(NACM)		(NACM)
	If NACM [RFC8341] is implemented on a server, it can be used to		If NACM [RFC8341] is implemented on a server, it is used to control
	control access to nodes defined by the mounted schema in the same way		access to nodes defined by the mounted schema in the same way as for
	as for nodes defined by the top-level schema.		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		[I-D.ietf-rtgwg-lne-model]. Then the following NACM path can be used
	to control access to the "interfaces" container (where the character		to control access to the "interfaces" container (where the character
	'\' is used where a line break has been inserted for formatting		'\' is used 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"
	skipping to change at page 12, line 30 ¶		skipping to change at page 12, line 32 ¶
	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 but, in addition,
	an extra session exists for every instance of the mount point,		an extra session exists for every instance of the mount point,
	having access only to the mounted data tree.		having access only to the mounted data tree.
	9. Schema Mount YANG Module		9. Schema Mount YANG Module
	This module references [RFC6991].		This module references [RFC6991].
	<CODE BEGINS> file "ietf-yang-schema-mount@2018-08-07"		<CODE BEGINS> file "ietf-yang-schema-mount@2018-10-16"
	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 32 ¶		skipping to change at page 13, line 35 ¶
	authors of the code. All rights reserved.		authors of the code. All rights reserved.
	Redistribution and use in source and binary forms, with or		Redistribution and use in source and binary forms, with or
	without modification, is permitted pursuant to, and subject to		without modification, is permitted pursuant to, and subject to
	the license terms contained in, the Simplified BSD License set		the license terms contained in, the Simplified BSD License set
	forth in Section 4.c of the IETF Trust's Legal Provisions		forth in Section 4.c of the IETF Trust's Legal Provisions
	Relating to IETF Documents		Relating to IETF Documents
	(https://trustee.ietf.org/license-info).		(https://trustee.ietf.org/license-info).
	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', 'NOT RECOMMENDED',
	'OPTIONAL' in the module text are to be interpreted as described		'MAY', and 'OPTIONAL' in the module text are to be interpreted
	in RFC 2119 (https://tools.ietf.org/html/rfc2119).		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		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.";
	// RFC Ed.: update the date below with the date of RFC publication		// RFC Ed.: update the date below with the date of RFC publication
	// and remove this note.		// and remove this note.
	revision 2018-08-07 {		revision 2018-10-16 {
	description		description
	"Initial revision.";		"Initial revision.";
	reference		reference
	"RFC XXXX: YANG Schema Mount";		"RFC XXXX: 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 18, line 23 ¶		skipping to change at page 18, line 28 ¶
	attacker identify the server capabilities and server		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
			the mounted schemas into account, and control access to these nodes
			by using the mechanism described in Section 7.
			Care must be taken when the "parent-reference" XPath expressions are
			constructed, since the result of the evaluation of these expressions
			is added to the accessible tree for any XPath expression found in the
			mounted schema.
	12. Contributors		12. Contributors
	The idea of having some way to combine schemas from different YANG		The idea of having some way to combine schemas from different YANG
	modules into one has been proposed independently by several groups of		modules into one has been proposed independently by several groups of
	people: Alexander Clemm, Jan Medved, and Eric Voit		people: Alexander Clemm, Jan Medved, and Eric Voit
	([I-D.clemm-netmod-mount]); and Lou Berger and Christian Hopps:		([I-D.clemm-netmod-mount]); and Lou Berger and Christian Hopps:
	o Lou Berger, LabN Consulting, L.L.C., <lberger@labn.net>		o Lou Berger, LabN Consulting, L.L.C., <lberger@labn.net>
	o Alexander Clemm, Huawei, <alexander.clemm@huawei.com>		o Alexander Clemm, Huawei, <alexander.clemm@huawei.com>
	skipping to change at page 20, line 5 ¶		skipping to change at page 20, line 15 ¶
	[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, <https://www.rfc-
	editor.org/info/rfc8341>.		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>.
			[XPATH] Clark, J. and S. DeRose, "XML Path Language (XPath)
			Version 1.0", World Wide Web Consortium Recommendation
			REC-xpath-19991116, November 1999,
			<http://www.w3.org/TR/1999/REC-xpath-19991116>.
	13.2. Informative References		13.2. Informative References
	[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-19 (work in progress), November 2017.		isis-yang-isis-cfg-24 (work in progress), August 2018.
	[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., Bogdanovic, D., and X.		Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X.
	Liu, "YANG Model for Logical Network Elements", draft-		Liu, "YANG Model for Logical Network Elements", draft-
	ietf-rtgwg-lne-model-10 (work in progress), March 2018.		ietf-rtgwg-lne-model-10 (work in progress), March 2018.
	skipping to change at page 21, line 22 ¶		skipping to change at page 21, line 34 ¶
	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:
	{		{
	"ietf-yang-library:yang-library": {		"ietf-yang-library:yang-library": {
	"checksum": "14e2ab5dc325f6d86f743e8d3ade233f1a61a899",		"content-id": "14e2ab5dc325f6d86f743e8d3ade233f1a61a899",
	"module-set": [		"module-set": [
	{		{
	"name": "physical-device-modules",		"name": "physical-device-modules",
	"module": [		"module": [
	{		{
	"name": "ietf-datastores",		"name": "ietf-datastores",
	"revision": "2018-02-14",		"revision": "2018-02-14",
	"namespace":		"namespace":
	"urn:ietf:params:xml:ns:yang:ietf-datastores"		"urn:ietf:params:xml:ns:yang:ietf-datastores"
	},		},
End of changes. 19 change blocks.
	34 lines changed or deleted		51 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/