draft-ietf-netmod-yang-tree-diagrams-01.txt		draft-ietf-netmod-yang-tree-diagrams-02.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. Berger, Ed.		Intended status: Standards Track L. Berger, Ed.
	Expires: December 31, 2017 LabN Consulting, L.L.C.		Expires: April 28, 2018 LabN Consulting, L.L.C.
	June 29, 2017		October 25, 2017
	YANG Tree Diagrams		YANG Tree Diagrams
	draft-ietf-netmod-yang-tree-diagrams-01		draft-ietf-netmod-yang-tree-diagrams-02
	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 December 31, 2017.		This Internet-Draft will expire on April 28, 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
	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 . . . . . . . . . . . . . . . . . . . . . . . 4		2.1. Submodules . . . . . . . . . . . . . . . . . . . . . . . 5
	2.2. Groupings . . . . . . . . . . . . . . . . . . . . . . . . 4		2.2. Groupings . . . . . . . . . . . . . . . . . . . . . . . . 5
	2.3. Collapsed Node Representation . . . . . . . . . . . . . . 4		2.3. yang-data . . . . . . . . . . . . . . . . . . . . . . . . 5
	2.4. Node Representation . . . . . . . . . . . . . . . . . . . 4		2.4. Collapsed Node Representation . . . . . . . . . . . . . . 5
	2.5. Extensions . . . . . . . . . . . . . . . . . . . . . . . 5		2.5. Comments . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. Usage Guidelines For RFCs . . . . . . . . . . . . . . . . . . 5		2.6. Node Representation . . . . . . . . . . . . . . . . . . . 5
	3.1. Wrapping Long Lines . . . . . . . . . . . . . . . . . . . 6		3. Usage Guidelines For RFCs . . . . . . . . . . . . . . . . . . 6
	4. YANG Schema Mount Tree Diagrams . . . . . . . . . . . . . . . 6		3.1. Wrapping Long Lines . . . . . . . . . . . . . . . . . . . 7
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		3.2. Long Diagrams . . . . . . . . . . . . . . . . . . . . . . 7
	6. Informative References . . . . . . . . . . . . . . . . . . . 7		4. YANG Schema Mount Tree Diagrams . . . . . . . . . . . . . . . 8
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8		4.1. Representation of Instance Data Trees . . . . . . . . . . 8
			5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
			6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
			7. Informative References . . . . . . . . . . . . . . . . . . . 10
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
	1. Introduction		1. Introduction
	YANG Tree Diagrams were first published in [RFC7223]. Such diagrams		YANG Tree Diagrams were first published in [RFC7223]. Such diagrams
	are commonly used to provided a simplified graphical representation		are commonly used to provided a simplified graphical representation
	of a data model and can be automatically generated via tools such as		of a data model and can be automatically generated via tools such as
	"pyang". (See <https://github.com/mbj4668/pyang>). This document		"pyang". (See <https://github.com/mbj4668/pyang>). This document
	provides the syntax used in YANG Tree Diagrams. It is expected that		provides the syntax used in YANG Tree Diagrams. It is expected that
	this document will be updated or replaced as changes to the YANG		this document will be updated or replaced as changes to the YANG
	language, see [RFC7950], necessitate.		language, see [RFC7950], necessitate.
	skipping to change at page 2, line 50 ¶		skipping to change at page 3, line 5 ¶
	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
	The remainder of this document contains YANG Tree Diagram syntax
	based on output from pyang version 1.7.1.
	2. Tree Diagram Syntax		2. Tree Diagram Syntax
	This section provides the meaning of the symbols used in YANG Tree		This section provides 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. Top		A module is identified by "module:" followed the module-name. This
	level module statements are listed immediately following, offset by 4		is followed by one or more sections, in order:
	spaces. Augmentations are listed next, offset by 2 spaces and
	identified by the keyword "augment" followed by the augment target		1. The top-level data nodes defined in the module, offset by 4
	node and a colon (':') character. This is followed by, RPCs which		spaces.
	are identified by "rpcs:" and are also offset by 2 spaces.
	Notifications are last and are identified by "notifications:" and are		2. Augmentations, offset by 2 spaces and identified by the keyword
	also offset by 2 spaces.		"augment" followed by the augment target node and a colon (":")
			character.
			3. RPCs, offset by 2 spaces and identified by "rpcs:".
			4. Notifications, offset by 2 spaces and identified by
			"notifications:".
			5. Groupings, offset by 2 spaces, and identified by the keyword
			"grouping" followed by the name of the grouping and a colon (":")
			character.
			6. yang-data, offset by 2 spaces, and identified by the keyword
			"yang-data" followed by the name of the yang-data structure and a
			colon (":") character.
	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. Schema peer nodes separated are listed with the same space		spaces. Schema peer nodes separated are listed with the same space
	offset and, when separated by lines, linked via a pipe ('|')		offset 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>:
			+--<node>
	rpcs:		rpcs:
			+--<rpc-node>
			+--<rpc-node>
			+--<node>
			| +--<node>
			+--<node>
			notifications:
			+--<notification-node>
			+--<notification-node>
			+--<node>
			| +--<node>
			+--<node>
			grouping <grouping-name>:
	+--<node>		+--<node>
			+--<node>
			| +--<node>
			+--<node>
			grouping <grouping-name>:
	+--<node>		+--<node>
	notifications:		yang-data <yang-data-name>:
	+--<node>		+--<node>
	+--<node>		+--<node>
	| +--<node>		| +--<node>
	+--<node>		+--<node>
			yang-data <yang-data-name>:
			+--<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 expanded as if the nodes were		Nodes within a used grouping are expanded as if the nodes were
	defined at the location of the uses statement.		defined at the location of the uses statement.
	2.3. Collapsed Node Representation		Groupings may optionally be present in the "groupings" section.
			2.3. yang-data
			If the module defines a "yang-data" structure [RFC8040], these
			structures may optionally be present in the "yang-data" section.
			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, peer nodes and		not important in the context of the presented tree, peer 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.4. Node Representation		2.5. Comments
			Single line comments, starting with "//" and ending at the end of the
			line, may be used in the tree notation.
			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:
	+ for current
	x for deprecated
	o for obsolete
	<flags> is one of:		<status> is one of:
	rw for configuration data
	ro for non-configuration data
	-x for rpcs and actions
	-n for notifications
	mp for schema mount points
	<name> is the name of the node		+ for current
	(<name>) means that the node is a choice node
	:(<name>) means that the node is a case node
	If the node is augmented into the tree from another module, its		x for deprecated
			o for obsolete
	name is printed as <prefix>:<name>.		<flags> is one of:
			rw for configuration data
			ro for non-configuration data
			-x for rpcs and actions
			-n for notifications
			mp for nodes containing a "mount-point" extension statment
	<opts> is one of:		<name> is the name of the node
	? for an optional leaf, choice, anydata or anyxml		(<name>) means that the node is a choice node
	! for a presence container		:(<name>) means that the node is a case node
	* for a leaf-list or list
	[<keys>] for a list's keys
	/ for a mounted module
	@ for a node made available via a schema mount
	parent reference
	<type> is the name of the type for leafs and leaf-lists		If the node is augmented into the tree from another module,
			its name is printed as <prefix>:<name>.
	If the type is a leafref, the type is printed as "-> TARGET",		<opts> is one of:
	where TARGET is either the leafref path, with prefixed removed		? for an optional leaf, choice, anydata or anyxml
	if possible.		! for a presence container
			* for a leaf-list or list
			[<keys>] for a list's keys
			/ for a top-level data node in a mounted module
			@ for a top-level data node in a parent referenced module
	<if-features> is the list of features this node depends on,		<type> is the name of the type for leafs and leaf-lists
	printed within curly brackets and a question mark "{...}?"
	2.5. Extensions		If the type is a leafref, the type is printed as "-> TARGET",
			where TARGET is either the leafref path, with prefixed removed
			if possible.
	TBD		<if-features> is the list of features this node depends on,
			printed within curly brackets and a question mark "{...}?"
	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. This section covers [Authors' note: will cover]		diagrams in RFCs.
	different types of trees and when to use them; for example, complete
	module trees, subtrees, trees for groupings etc.
	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>. The type should be indented so
	that the new line starts below <name> with a white space offset of at		that the new line starts below <name> with a white space offset of at
	least two characters. For example:		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
	The previously 'pyang' command can be helpful in producing such		The previously mentioned "pyang" command can be helpful in producing
	output, for example the above example was produced using:		such output, for example the above example was produced using:
	pyang -f tree --tree-line-length 50 < ietf-yang-library.yang		pyang -f tree --tree-line-length 50 ietf-yang-library.yang
			When a tree diagram is included as a figure in an Internet Draft or
			RFC, "--tree-line-length 69" works well.
			3.2. Long Diagrams
			As tree diagrams are intended to provide a simplified view of a
			module, diagrams longer than a page should generally be avoided. If
			the complete tree diagram for a module becomes too long, the diagram
			can be split into several smaller diagrams. For example, 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, it is also
			possible to split the diagram into smaller diagrams for different
			subtrees. When long diagrams are included in a document, authors
			should consider whether to include the long diagram in the main body
			of the document or in an appendix.
			An example of such a split can be found in [RFC7407], where section
			2.4 shows the diagram for "engine configuration":
			+--rw snmp
			+--rw engine
			// more parameters from the "engine" subtree here
			Further, section 2.5 shows the diagram for "target configuration":
			+--rw snmp
			+--rw target* [name]
			// more parameters from the "target" subtree here
			The previously mentioned "pyang" command can be helpful in producing
			such output, for example the above example was produced using:
			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 document is a		warrants some specific discussion. Schema mount is a generic
	generic mechanism that allows for mounting one data model consisting		mechanism that allows for mounting of one or more data modules at a
	of any number of YANG modules at a specified location of another		specified location of another (parent) schema. The specific location
	(parent) schema. Modules containing mount points will identify mount		is referred to as a mount point, and any container or list node in a
	points by name using the mount-point extension. These mount-points		schema may serve as a mount point. Mount points are identified via
	should be identified, as indicated above using the 'mp' flag. For		the inclusion of the "mount-point" extension statement as a
	example:		substament under a container or list node. Mount point nodes are
			thus directly identified in a module schema definition and can be
			identified in a tree diagram as indicated above using the "mp" flag.
			In the following example taken from [I-D.ietf-rtgwg-ni-model],
			"vrf-root" is a container that includes the "mount-point" extension
			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
	Note that a mount point definition alone is not sufficient to		4.1. Representation of Instance Data Trees
	identify if a mount point configuration or for non-configuration
	data. This is determined by the yang-schema-mount module 'config'
	leaf associated with the specific mount point.
	In describing the intended use of a module containing a mount point,		The actual modules made available under a mount point is controlled
	it is helpful to show how the mount point would look with mounted		by a server and is provided to clients. This information is
	modules. In such cases, the mount point should be treated much like		typically provided via the Schema Mount module defined in
	a container that uses a grouping. The flags should also be set based		[I-D.ietf-netmod-schema-mount]. The Schema Mount module supports
	on the 'config' leaf mentioned above, and the mount realted options		exposure of both mounted schema and "parent-references". Parent
	indicated above should be shown. For example, the following		references are used for XPath evaluation within mounted modules and
	represents the prior example with YANG Routing and OSPF modules		do not represent client-accessible paths; the referenced information
	mounted, YANG Interface module nodes accessible via a parent-		is available to clients via the parent schema. Schema mount also
	reference, and 'config' indicating true:		defines an "inline" type mount point where mounted modules are
			exposed via the YANG library module.
	module: ietf-network-instance		While the modules made available under a mount point are not
	+--rw network-instances		specified in YANG modules that include mount points, the document
	+--rw network-instance* [name]		defining the module will describe the intended use of the module and
	+--rw name string		may identify both modules that will be mounted and parent modules
	+--rw enabled? boolean		that can be referenced by mounted modules. An example of such a
	+--rw description? string		description can be found in [I-D.ietf-rtgwg-ni-model]. A specific
	+--rw (ni-type)?		implementation of a module containing mount points will also support
	+--rw (root-type)?		a specific list of mounted and referenced modules. In describing
	+--:(vrf-root)		both intended use and actual implementations, it is helpful to show
	+--mp vrf-root?		how mounted modules would be instantiated and referenced under a
	+--ro rt:routing-state/		mount point using tree diagrams.
	| ...
	+--rw rt:routing/
	| ...
	+--ro if:interfaces@
	| ...
	+--ro if:interfaces-state@
	...
	The with 'config' indicating false, the only change would be to the		In such diagrams, the mount point should be treated much like a
	flag on the rt:routing node:		container that uses a grouping. The flags should also be set based
			on the "config" leaf mentioned above, and the mount realted options
			indicated above should be shown for the top level nodes in a mounted
			or referenced module. The following example, taken from
			[I-D.ietf-rtgwg-ni-model], represents the prior example with YANG
			Routing and OSPF modules mounted, YANG Interface module nodes
			accessible via a parent-reference, and "config" indicating true:
			module: ietf-network-instance
			+--rw network-instances
			+--rw network-instance* [name]
			+--rw name string
			+--rw enabled? boolean
			+--rw description? string
			+--rw (ni-type)?
			+--rw (root-type)
			+--:(vrf-root)
			+--mp vrf-root
			+--ro rt:routing-state/
			| +--ro router-id?
			| +--ro control-plane-protocols
			| +--ro control-plane-protocol* [type name]
			| +--ro ospf:ospf
			| +--ro instance* [af]
			| ...
			+--rw rt:routing/
			| +--rw router-id?
			| +--rw control-plane-protocols
			| +--rw control-plane-protocol* [type name]
			| +--rw ospf:ospf
			| +--rw instance* [af]
			| ...
			+--ro if:interfaces@
			| ...
			+--ro if:interfaces-state@
			| ...
			It is worth highlighting that the OSPF module augments the Routing
			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
			diagram.
			A mount point definition alone is not sufficient to identify if the
			mounted modules are used for configuration or for non-configuration
			data. This is determined by the "ietf-yang-schema-mount" module's
			"config" leaf associated with the specific mount point and is
			indicated on the top level mounted nodes. For example in the above
			tree, when the "config" for the routing module indicates false, the
			only change would be to the flag on the rt:routing node:
	+--ro rt:routing/		+--ro rt:routing/
	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. Informative References		6. Security Considerations
			There is no security impact related to the tree diagrams defined in
			this document.
			7. Informative References
	[I-D.ietf-netmod-schema-mount]		[I-D.ietf-netmod-schema-mount]
	Bjorklund, M. and L. Lhotka, "YANG Schema Mount", draft-		Bjorklund, M. and L. Lhotka, "YANG Schema Mount", draft-
	ietf-netmod-schema-mount-05 (work in progress), May 2017.		ietf-netmod-schema-mount-08 (work in progress), October
			2017.
			[I-D.ietf-rtgwg-ni-model]
			Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X.
			Liu, "YANG Network Instances", draft-ietf-rtgwg-ni-
			model-04 (work in progress), September 2017.
	[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>.		<https://www.rfc-editor.org/info/rfc7223>.
			[RFC7407] Bjorklund, M. and J. Schoenwaelder, "A YANG Data Model for
			SNMP Configuration", RFC 7407, DOI 10.17487/RFC7407,
			December 2014, <https://www.rfc-editor.org/info/rfc7407>.
	[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>.		<https://www.rfc-editor.org/info/rfc7950>.
			[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
			Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
			<https://www.rfc-editor.org/info/rfc8040>.
	Authors' Addresses		Authors' Addresses
	Martin Bjorklund		Martin Bjorklund
	Tail-f Systems		Tail-f Systems
	Email: mbj@tail-f.com		Email: mbj@tail-f.com
	Lou Berger (editor)		Lou Berger (editor)
	LabN Consulting, L.L.C.		LabN Consulting, L.L.C.
End of changes. 43 change blocks.
	122 lines changed or deleted		264 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/