draft-ietf-netmod-yang-tree-diagrams-04.txt		draft-ietf-netmod-yang-tree-diagrams-05.txt
	Network Working Group M. Bjorklund		Network Working Group M. Bjorklund
	Internet-Draft Tail-f Systems		Internet-Draft Tail-f Systems
	Intended status: Best Current Practice L. Berger, Ed.		Intended status: Best Current Practice L. Berger, Ed.
	Expires: June 24, 2018 LabN Consulting, L.L.C.		Expires: July 27, 2018 LabN Consulting, L.L.C.
	December 21, 2017		January 23, 2018
	YANG Tree Diagrams		YANG Tree Diagrams
	draft-ietf-netmod-yang-tree-diagrams-04		draft-ietf-netmod-yang-tree-diagrams-05
	Abstract		Abstract
	This document captures the current syntax used in YANG module Tree		This document captures the current syntax used in YANG module Tree
	Diagrams. The purpose of the document is to provide a single		Diagrams. The purpose of the document is to provide a single
	location for this definition. This syntax may be updated from time		location for this definition. This syntax may be updated from time
	to time based on the evolution of the YANG language.		to time based on the evolution of the YANG language.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 34 ¶		skipping to change at page 1, line 34 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on June 24, 2018.		This Internet-Draft will expire on July 27, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2018 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	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. Tree Diagram Syntax . . . . . . . . . . . . . . . . . . . . . 3		2. Tree Diagram Syntax . . . . . . . . . . . . . . . . . . . . . 3
	2.1. Submodules . . . . . . . . . . . . . . . . . . . . . . . 5		2.1. Submodules . . . . . . . . . . . . . . . . . . . . . . . 6
	2.2. Groupings . . . . . . . . . . . . . . . . . . . . . . . . 6		2.2. Groupings . . . . . . . . . . . . . . . . . . . . . . . . 6
	2.3. yang-data . . . . . . . . . . . . . . . . . . . . . . . . 6		2.3. yang-data . . . . . . . . . . . . . . . . . . . . . . . . 6
	2.4. Collapsed Node Representation . . . . . . . . . . . . . . 6		2.4. Collapsed Node Representation . . . . . . . . . . . . . . 6
	2.5. Comments . . . . . . . . . . . . . . . . . . . . . . . . 6		2.5. Comments . . . . . . . . . . . . . . . . . . . . . . . . 7
	2.6. Node Representation . . . . . . . . . . . . . . . . . . . 6		2.6. Node Representation . . . . . . . . . . . . . . . . . . . 7
	3. Usage Guidelines For RFCs . . . . . . . . . . . . . . . . . . 7		3. Usage Guidelines For RFCs . . . . . . . . . . . . . . . . . . 8
	3.1. Wrapping Long Lines . . . . . . . . . . . . . . . . . . . 7		3.1. Wrapping Long Lines . . . . . . . . . . . . . . . . . . . 8
	3.2. Groupings . . . . . . . . . . . . . . . . . . . . . . . . 8		3.2. Groupings . . . . . . . . . . . . . . . . . . . . . . . . 9
	3.3. Long Diagrams . . . . . . . . . . . . . . . . . . . . . . 8		3.3. Long Diagrams . . . . . . . . . . . . . . . . . . . . . . 9
	4. YANG Schema Mount Tree Diagrams . . . . . . . . . . . . . . . 9		4. YANG Schema Mount Tree Diagrams . . . . . . . . . . . . . . . 10
	4.1. Representation of Mounted Schema Trees . . . . . . . . . 9		4.1. Representation of Mounted Schema Trees . . . . . . . . . 10
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 12		6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	7. Informative References . . . . . . . . . . . . . . . . . . . 12		7. Informative References . . . . . . . . . . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
	1. Introduction		1. Introduction
	YANG Tree Diagrams were first published in [RFC6536]. Such diagrams		YANG Tree Diagrams were first published in [RFC6536]. Such diagrams
	are commonly used to provided a simplified graphical representation		are used to provided a simplified graphical representation of a data
	of a data model and can be automatically generated via tools such as		model and can be automatically generated via tools such as "pyang".
	"pyang". (See <https://github.com/mbj4668/pyang>). This document		(See <https://github.com/mbj4668/pyang>). This document describes
	provides the syntax used in YANG Tree Diagrams. It is expected that		the syntax used in YANG Tree Diagrams. It is expected that this
	this document will be updated or replaced as changes to the YANG		document will be updated or replaced as changes to the YANG language,
	language, see [RFC7950], necessitate.		see [RFC7950], necessitate.
	Today's common practice is include the definition of the syntax used		Today's common practice is to include the definition of the syntax
	to represent a YANG module in every document that provides a tree		used to represent a YANG module in every document that provides a
	diagram. This practice has several disadvantages and the purpose of		tree diagram. This practice has several disadvantages and the
	the document is to provide a single location for this definition. It		purpose of the document is to provide a single location for this
	is not the intent of this document to restrict future changes, but		definition. It is not the intent of this document to restrict future
	rather to ensure such changes are easily identified and suitably		changes, but rather to ensure such changes are easily identified and
	agreed upon.		suitably agreed upon.
	An example tree diagram can be found in [RFC7223] Section 3. A		An example tree diagram can be found in [RFC7223] Section 3. A
	portion of which follows:		portion of which follows:
	+--rw interfaces		+--rw interfaces
	| +--rw interface* [name]		| +--rw interface* [name]
	| +--rw name string		| +--rw name string
	| +--rw description? string		| +--rw description? string
	| +--rw type identityref		| +--rw type identityref
	| +--rw enabled? boolean		| +--rw enabled? boolean
	| +--rw link-up-down-trap-enable? enumeration		| +--rw link-up-down-trap-enable? enumeration
	2. Tree Diagram Syntax		2. Tree Diagram Syntax
	This section provides the meaning of the symbols used in YANG Tree		This section describes the meaning of the symbols used in YANG Tree
	diagrams.		diagrams.
	A full tree diagram of a module represents all elements. It includes		A full tree diagram of a module represents all elements. It includes
	the name of the module and sections for top level module statements		the name of the module and sections for top level module statements
	(typically containers), augmentations, rpcs and notifications all		(typically containers), augmentations, rpcs and notifications all
	identified under a module statement. Module trees may be included in		identified under a module statement. Module trees may be included in
	a document as a whole, by one or more sections, or even subsets of		a document as a whole, by one or more sections, or even subsets of
	nodes.		nodes.
	A module is identified by "module:" followed the module-name. This		A module is identified by "module:" followed the module-name. This
	is followed by one or more sections, in order:		is followed by one or more sections, in order:
	1. The top-level data nodes defined in the module, offset by 4		1. The top-level data nodes defined in the module, offset by 2
	spaces.		spaces.
	2. Augmentations, offset by 2 spaces and identified by the keyword		2. Augmentations, offset by 2 spaces and identified by the keyword
	"augment" followed by the augment target node and a colon (":")		"augment" followed by the augment target node and a colon (":")
	character.		character.
	3. RPCs, offset by 2 spaces and identified by "rpcs:".		3. RPCs, offset by 2 spaces and identified by "rpcs:".
	4. Notifications, offset by 2 spaces and identified by		4. Notifications, offset by 2 spaces and identified by
	"notifications:".		"notifications:".
	skipping to change at page 4, line 9 ¶		skipping to change at page 5, line 5 ¶
	The relative organization of each section is provided using a text-		The relative organization of each section is provided using a text-
	based format that is typical of a file system directory tree display		based format that is typical of a file system directory tree display
	command. Each node in the tree is prefaces with "+--". Schema nodes		command. Each node in the tree is prefaces with "+--". Schema nodes
	that are children of another node are offset from the parent by 3		that are children of another node are offset from the parent by 3
	spaces. Sibling schema nodes are listed with the same space offset		spaces. Sibling schema nodes are listed with the same space offset
	and, when separated by lines, linked via a vertical bar ("|")		and, when separated by lines, linked via a vertical bar ("|")
	character.		character.
	The full format, including spacing conventions is:		The full format, including spacing conventions is:
	module: <module-name>		module: <module-name>
	+--<node>		+--<node>
	| +--<node>		| +--<node>
	| +--<node>		| +--<node>
	+--<node>		+--<node>
	+--<node>		+--<node>
	+--<node>		+--<node>
	augment <target-node>:		augment <target-node>:
	+--<node>		+--<node>
	+--<node>		+--<node>
	+--<node>		+--<node>
	+--<node>		+--<node>
	augment <target-node>:		augment <target-node>:
	+--<node>		+--<node>
	rpcs:		rpcs:
	+--<rpc-node>		+--<rpc-node>
	+--<rpc-node>		+--<rpc-node>
	+--<node>		+--<node>
	| +--<node>		| +--<node>
	+--<node>		+--<node>
	notifications:		notifications:
	+--<notification-node>		+--<notification-node>
	+--<notification-node>		+--<notification-node>
	+--<node>		+--<node>
	| +--<node>		| +--<node>
	+--<node>		+--<node>
	grouping <grouping-name>:		grouping <grouping-name>:
	+--<node>		+--<node>
	+--<node>		+--<node>
	| +--<node>		| +--<node>
	+--<node>		+--<node>
	grouping <grouping-name>:		grouping <grouping-name>:
	+--<node>		+--<node>
	yang-data <yang-data-name>:		yang-data <yang-data-name>:
	+--<node>		+--<node>
	+--<node>		+--<node>
	| +--<node>		| +--<node>
	+--<node>		+--<node>
	yang-data <yang-data-name>:		yang-data <yang-data-name>:
	+--<node>		+--<node>
	2.1. Submodules		2.1. Submodules
	Submodules are represented in the same fashion as modules, but are		Submodules are represented in the same fashion as modules, but are
	identified by "submodule:" followed the (sub)module-name. For		identified by "submodule:" followed the (sub)module-name. For
	example:		example:
	submodule: <module-name>		submodule: <module-name>
	+--<node>		+--<node>
	| +--<node>		| +--<node>
	| +--<node>		| +--<node>
	2.2. Groupings		2.2. Groupings
	Nodes within a used grouping are normally expanded as if the nodes		Nodes within a used grouping are normally expanded as if the nodes
	were defined at the location of the "uses" statement. However, it is		were defined at the location of the "uses" statement. However, it is
	also possible to not expand the "uses" statement, but instead print		also possible to not expand the "uses" statement, but instead print
	the name of the grouping.		the name of the grouping.
			For example, the following diagram shows the "tls-transport" grouping
			from [RFC7407] unexpanded:
			+--rw tls
			+---u tls-transport
			If the grouping is expanded, it could be printed as:
			+--rw tls
			+--rw port? inet:port-number
			+--rw client-fingerprint? x509c2n:tls-fingerprint
			+--rw server-fingerprint? x509c2n:tls-fingerprint
			+--rw server-identity? snmp:admin-string
	Groupings may optionally be present in the "groupings" section.		Groupings may optionally be present in the "groupings" section.
	2.3. yang-data		2.3. yang-data
	If the module defines a "yang-data" structure [RFC8040], these		If the module defines a "yang-data" structure [RFC8040], these
	structures may optionally be present in the "yang-data" section.		structures may optionally be present in the "yang-data" section.
	2.4. Collapsed Node Representation		2.4. Collapsed Node Representation
	At times when the composition of the nodes within a module schema are		At times when the composition of the nodes within a module schema are
	not important in the context of the presented tree, sibling nodes and		not important in the context of the presented tree, sibling nodes and
	their children can be collapsed using the notation "..." in place of		their children can be collapsed using the notation "..." in place of
	the text lines used to represent the summarized nodes. For example:		the text lines used to represent the summarized nodes. For example:
	+--<node>		+--<node>
	| ...		| ...
	+--<node>		+--<node>
	+--<node>		+--<node>
	+--<node>		+--<node>
	2.5. Comments		2.5. Comments
	Single line comments, starting with "//" and ending at the end of the		Single line comments, starting with "//" (possibly indented) and
	line, may be used in the tree notation.		ending at the end of the line, may be used in the tree notation.
	2.6. Node Representation		2.6. Node Representation
	Each node in a YANG module is printed as:		Each node in a YANG module is printed as:
	<status> <flags> <name> <opts> <type> <if-features>		<status>--<flags> <name><opts> <type> <if-features>
	<status> is one of:		<status> is one of:
	+ for current		+ for current
	x for deprecated		x for deprecated
	o for obsolete		o for obsolete
	<flags> is one of:		<flags> is one of:
	rw for configuration data		rw for configuration data
	ro for non-configuration data		ro for non-configuration data, output parameters to rpcs
			and actions, and notification parameters
			-w for input parameters to rpcs and actions
	-u for uses of a grouping		-u for uses of a grouping
	-x for rpcs and actions		-x for rpcs and actions
	-n for notifications		-n for notifications
	mp for nodes containing a "mount-point" extension statment		mp for nodes containing a "mount-point" extension statement
	<name> is the name of the node		<name> is the name of the node
	(<name>) means that the node is a choice node		(<name>) means that the node is a choice node
	:(<name>) means that the node is a case node		:(<name>) means that the node is a case node
	If the node is augmented into the tree from another module,		If the node is augmented into the tree from another module,
	its name is printed as <prefix>:<name>.		its name is printed as <prefix>:<name>, where <prefix> is the
			prefix defined in the module where the node is defined.
	<opts> is one of:		<opts> is one of:
	? for an optional leaf, choice, anydata or anyxml		? for an optional leaf, choice, anydata or anyxml
	! for a presence container		! for a presence container
	* for a leaf-list or list		* for a leaf-list or list
	[<keys>] for a list's keys		[<keys>] for a list's keys
	/ for a top-level data node in a mounted module		/ for a top-level data node in a mounted module
	@ for a top-level data node in a parent referenced module		@ for a top-level data node in a parent referenced module
	<type> is the name of the type for leafs and leaf-lists		<type> is the name of the type for leafs and leaf-lists
	If the type is a leafref, the type is either printed as		If the type is a leafref, the type is either printed as
	"-> TARGET", where TARGET is the leafref path, with prefixes		"-> TARGET", where TARGET is the leafref path, with prefixes
	removed if possible, or printed as "leafref".		removed if possible, or printed as "leafref".
	<if-features> is the list of features this node depends on,		<if-features> is the list of features this node depends on,
	printed within curly brackets and a question mark "{...}?"		printed within curly brackets and a question mark "{...}?"
			Arbitrary whitespace is allowed between any of the whitespace
			separated fields (e.g., <opts> and <type>). Additional whitespace
			may for example be used to column align fields (e.g., within a list
			or container) to improve readability.
	3. Usage Guidelines For RFCs		3. Usage Guidelines For RFCs
	This section provides general guidelines related to the use of tree		This section provides general guidelines related to the use of tree
	diagrams in RFCs.		diagrams in RFCs.
	3.1. Wrapping Long Lines		3.1. Wrapping Long Lines
	Internet Drafts and RFCs limit the number of characters that may in a		Internet Drafts and RFCs limit the number of characters that may in a
	line of text to 72 characters. When the tree representation of a		line of text to 72 characters. When the tree representation of a
	node results in line being longer than this limit the line should be		node results in line being longer than this limit the line should be
	broken between <opts> and <type>. The type should be indented so		broken between <opts> and <type>, or between <type> and <if-feature>.
	that the new line starts below <name> with a white space offset of at		The new line should be indented so that it starts below <name> with a
	least two characters. For example:		white space offset of at least two characters. For example:
	notifications:		notifications:
	+---n yang-library-change		+---n yang-library-change
	+--ro module-set-id		+--ro module-set-id
	-> /modules-state/module-set-id		-> /modules-state/module-set-id
	Long paths (e.g., leafref paths or augment targets) can be split and		Long paths (e.g., leafref paths or augment targets) can be split and
	printed on more than one line. For example:		printed on more than one line. For example:
	augment /nat:nat/nat:instances/nat:instance/nat:mapping-table		augment /nat:nat/nat:instances/nat:instance/nat:mapping-table
	skipping to change at page 8, line 49 ¶		skipping to change at page 9, line 41 ¶
	it might be possible to have one diagram with the data node and		it might be possible to have one diagram with the data node and
	another with all notifications. If the data nodes tree is too long,		another with all notifications. If the data nodes tree is too long,
	it is also possible to split the diagram into smaller diagrams for		it is also possible to split the diagram into smaller diagrams for
	different subtrees. When long diagrams are included in a document,		different subtrees. When long diagrams are included in a document,
	authors should consider whether to include the long diagram in the		authors should consider whether to include the long diagram in the
	main body of the document or in an appendix.		main body of the document or in an appendix.
	An example of such a split can be found in [RFC7407], where section		An example of such a split can be found in [RFC7407], where section
	2.4 shows the diagram for "engine configuration":		2.4 shows the diagram for "engine configuration":
	+--rw snmp		+--rw snmp
	+--rw engine		+--rw engine
	// more parameters from the "engine" subtree here		// more parameters from the "engine" subtree here
	Further, section 2.5 shows the diagram for "target configuration":		Further, section 2.5 shows the diagram for "target configuration":
	+--rw snmp		+--rw snmp
	+--rw target* [name]		+--rw target* [name]
	// more parameters from the "target" subtree here		// more parameters from the "target" subtree here
	The previously mentioned "pyang" command can be helpful in producing		The previously mentioned "pyang" command can be helpful in producing
	such output, for example the above example was produced using:		such output, for example the above example was produced using:
	pyang -f tree --tree-path /snmp/target ietf-snmp.yang		pyang -f tree --tree-path /snmp/target ietf-snmp.yang
	4. YANG Schema Mount Tree Diagrams		4. YANG Schema Mount Tree Diagrams
	YANG Schema Mount is defined in [I-D.ietf-netmod-schema-mount] and		YANG Schema Mount is defined in [I-D.ietf-netmod-schema-mount] and
	warrants some specific discussion. Schema mount is a generic		warrants some specific discussion. Schema mount is a generic
	mechanism that allows for mounting of one or more YANG modules at a		mechanism that allows for mounting of one or more YANG modules at a
	specified location of another (parent) schema. The specific location		specified location of another (parent) schema. The specific location
	is referred to as a mount point, and any container or list node in a		is referred to as a mount point, and any container or list node in a
	schema may serve as a mount point. Mount points are identified via		schema may serve as a mount point. Mount points are identified via
	the inclusion of the "mount-point" extension statement as a		the inclusion of the "mount-point" extension statement as a
	substament under a container or list node. Mount point nodes are		substatement under a container or list node. Mount point nodes are
	thus directly identified in a module schema definition and can be		thus directly identified in a module schema definition and can be
	identified in a tree diagram as indicated above using the "mp" flag.		identified in a tree diagram as indicated above using the "mp" flag.
	In the following example taken from [I-D.ietf-rtgwg-ni-model],		In the following example taken from [I-D.ietf-rtgwg-ni-model],
	"vrf-root" is a container that includes the "mount-point" extension		"vrf-root" is a container that includes the "mount-point" extension
	statement as part of its definition:		statement as part of its definition:
	module: ietf-network-instance		module: ietf-network-instance
	+--rw network-instances		+--rw network-instances
	+--rw network-instance* [name]		+--rw network-instance* [name]
	+--rw name string		+--rw name string
	+--rw enabled? boolean		+--rw enabled? boolean
	+--rw description? string		+--rw description? string
	+--rw (ni-type)?		+--rw (ni-type)?
	+--rw (root-type)		+--rw (root-type)
	+--:(vrf-root)		+--:(vrf-root)
	| +--mp vrf-root		| +--mp vrf-root
	4.1. Representation of Mounted Schema Trees		4.1. Representation of Mounted Schema Trees
	The actual modules made available under a mount point is controlled		The actual modules made available under a mount point is controlled
	by a server and is provided to clients. This information is		by a server and is provided to clients. This information is
	typically provided via the Schema Mount module defined in		typically provided via the Schema Mount module defined in
	[I-D.ietf-netmod-schema-mount]. The Schema Mount module supports		[I-D.ietf-netmod-schema-mount]. The Schema Mount module supports
	exposure of both mounted schema and "parent-references". Parent		exposure of both mounted schema and "parent-references". Parent
	references are used for XPath evaluation within mounted modules and		references are used for XPath evaluation within mounted modules and
	do not represent client-accessible paths; the referenced information		do not represent client-accessible paths; the referenced information
	skipping to change at page 11, line 5 ¶		skipping to change at page 11, line 20 ¶
	In such diagrams, the mount point should be treated much like a		In such diagrams, the mount point should be treated much like a
	container that uses a grouping. The flags should also be set based		container that uses a grouping. The flags should also be set based
	on the "config" leaf mentioned above, and the mount related options		on the "config" leaf mentioned above, and the mount related options
	indicated above should be shown for the top level nodes in a mounted		indicated above should be shown for the top level nodes in a mounted
	or referenced module. The following example, taken from		or referenced module. The following example, taken from
	[I-D.ietf-rtgwg-ni-model], represents the prior example with YANG		[I-D.ietf-rtgwg-ni-model], represents the prior example with YANG
	Routing and OSPF modules mounted, YANG Interface module nodes		Routing and OSPF modules mounted, YANG Interface module nodes
	accessible via a parent-reference, and "config" indicating true:		accessible via a parent-reference, and "config" indicating true:
	module: ietf-network-instance		module: ietf-network-instance
	+--rw network-instances		+--rw network-instances
	+--rw network-instance* [name]		+--rw network-instance* [name]
	+--rw name string		+--rw name string
	+--rw enabled? boolean		+--rw enabled? boolean
	+--rw description? string		+--rw description? string
	+--rw (ni-type)?		+--rw (ni-type)?
	+--rw (root-type)		+--rw (root-type)
	+--:(vrf-root)		+--:(vrf-root)
	+--mp vrf-root		+--mp vrf-root
	+--ro rt:routing-state/		+--ro rt:routing-state/
	| +--ro router-id?		| +--ro router-id?
	| +--ro control-plane-protocols		| +--ro control-plane-protocols
	| +--ro control-plane-protocol* [type name]		| +--ro control-plane-protocol* [type name]
	| +--ro ospf:ospf		| +--ro ospf:ospf
	| +--ro instance* [af]		| +--ro instance* [af]
	| ...		| ...
	+--rw rt:routing/		+--rw rt:routing/
	| +--rw router-id?		| +--rw router-id?
	| +--rw control-plane-protocols		| +--rw control-plane-protocols
	| +--rw control-plane-protocol* [type name]		| +--rw control-plane-protocol* [type name]
	| +--rw ospf:ospf		| +--rw ospf:ospf
	| +--rw instance* [af]		| +--rw instance* [af]
	| ...		| ...
	+--ro if:interfaces@		+--ro if:interfaces@
	| ...		| ...
	+--ro if:interfaces-state@		+--ro if:interfaces-state@
	| ...		| ...
	It is worth highlighting that the OSPF module augments the Routing		It is worth highlighting that the OSPF module augments the Routing
	module, and while it is listed in the Schema Mount module (or inline		module, and while it is listed in the Schema Mount module (or inline
	YANG library) there is no special mount-related notation in the tree		YANG library) there is no special mount-related notation in the tree
	diagram.		diagram.
	A mount point definition alone is not sufficient to identify if the		A mount point definition alone is not sufficient to identify if the
	mounted modules are used for configuration or for non-configuration		mounted modules are used for configuration or for non-configuration
	data. This is determined by the "ietf-yang-schema-mount" module's		data. This is determined by the "ietf-yang-schema-mount" module's
	"config" leaf associated with the specific mount point and is		"config" leaf associated with the specific mount point and is
	indicated on the top level mounted nodes. For example in the above		indicated on the top level mounted nodes. For example in the above
	tree, when the "config" for the routing module indicates false, the		tree, when the "config" for the routing module indicates false, the
	nodes in the "rt:routing" subtree would have different flags:		nodes in the "rt:routing" subtree would have different flags:
	+--ro rt:routing/		+--ro rt:routing/
	| +--ro router-id?		| +--ro router-id?
	| +--ro control-plane-protocols		| +--ro control-plane-protocols
	...		...
	5. IANA Considerations		5. IANA Considerations
	There are no IANA requests or assignments included in this document.		There are no IANA requests or assignments included in this document.
	6. Security Considerations		6. Security Considerations
	There is no security impact related to the tree diagrams defined in		There is no security impact related to the tree diagrams defined in
	this document.		this document.
	skipping to change at page 12, line 27 ¶		skipping to change at page 12, line 42 ¶
	Bjorklund, M. and L. Lhotka, "YANG Schema Mount", draft-		Bjorklund, M. and L. Lhotka, "YANG Schema Mount", draft-
	ietf-netmod-schema-mount-08 (work in progress), October		ietf-netmod-schema-mount-08 (work in progress), October
	2017.		2017.
	[I-D.ietf-rtgwg-ni-model]		[I-D.ietf-rtgwg-ni-model]
	Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X.		Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X.
	Liu, "YANG Network Instances", draft-ietf-rtgwg-ni-		Liu, "YANG Network Instances", draft-ietf-rtgwg-ni-
	model-05 (work in progress), December 2017.		model-05 (work in progress), December 2017.
	[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration		[RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration
	Protocol (NETCONF) Access Control Model", RFC 6536, DOI		Protocol (NETCONF) Access Control Model", RFC 6536,
	10.17487/RFC6536, March 2012, <https://www.rfc-		DOI 10.17487/RFC6536, March 2012, <https://www.rfc-
	editor.org/info/rfc6536>.		editor.org/info/rfc6536>.
	[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,
	<https://www.rfc-editor.org/info/rfc7223>.		<https://www.rfc-editor.org/info/rfc7223>.
	[RFC7407] Bjorklund, M. and J. Schoenwaelder, "A YANG Data Model for		[RFC7407] Bjorklund, M. and J. Schoenwaelder, "A YANG Data Model for
	SNMP Configuration", RFC 7407, DOI 10.17487/RFC7407,		SNMP Configuration", RFC 7407, DOI 10.17487/RFC7407,
	December 2014, <https://www.rfc-editor.org/info/rfc7407>.		December 2014, <https://www.rfc-editor.org/info/rfc7407>.
End of changes. 35 change blocks.
	135 lines changed or deleted		155 lines changed or added
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/