draft-ietf-netmod-yang-tree-diagrams-00.txt		draft-ietf-netmod-yang-tree-diagrams-01.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 15, 2017 LabN Consulting, L.L.C.		Expires: December 31, 2017 LabN Consulting, L.L.C.
	June 13, 2017		June 29, 2017
	YANG Tree Diagrams		YANG Tree Diagrams
	draft-ietf-netmod-yang-tree-diagrams-00		draft-ietf-netmod-yang-tree-diagrams-01
	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 15, 2017.		This Internet-Draft will expire on December 31, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	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 . . . . . . . . . . . . . . . . . . . . . 2		2. Tree Diagram Syntax . . . . . . . . . . . . . . . . . . . . . 3
	3. Next Steps . . . . . . . . . . . . . . . . . . . . . . . . . 3		2.1. Submodules . . . . . . . . . . . . . . . . . . . . . . . 4
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4		2.2. Groupings . . . . . . . . . . . . . . . . . . . . . . . . 4
	5. Informative References . . . . . . . . . . . . . . . . . . . 4		2.3. Collapsed Node Representation . . . . . . . . . . . . . . 4
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4		2.4. Node Representation . . . . . . . . . . . . . . . . . . . 4
			2.5. Extensions . . . . . . . . . . . . . . . . . . . . . . . 5
			3. Usage Guidelines For RFCs . . . . . . . . . . . . . . . . . . 5
			3.1. Wrapping Long Lines . . . . . . . . . . . . . . . . . . . 6
			4. YANG Schema Mount Tree Diagrams . . . . . . . . . . . . . . . 6
			5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
			6. Informative References . . . . . . . . . . . . . . . . . . . 7
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
	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.
	Today's Common practice is include the definition of the syntax used		Today's common practice is include the definition of the syntax used
	to represent a YANG module in every document that provides a tree		to represent a YANG module in every document that provides a tree
	diagram. This practice has several disadvantages and the purpose of		diagram. This practice has several disadvantages and the purpose of
	the document is to provide a single location for this definition. It		the document is to provide a single location for this definition. It
	is not the intent of this document to restrict future changes, but		is not the intent of this document to restrict future changes, but
	rather to ensure such changes are easily identified and suitably		rather to ensure such changes are easily identified and suitably
	agreed upon.		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:
	skipping to change at page 2, line 51 ¶		skipping to change at page 3, line 10 ¶
	| +--rw link-up-down-trap-enable? enumeration		| +--rw link-up-down-trap-enable? enumeration
	The remainder of this document contains YANG Tree Diagram syntax		The remainder of this document contains YANG Tree Diagram syntax
	based on output from pyang version 1.7.1.		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
			the name of the module and sections for top level module statements
			(typically containers), augmentations, rpcs and notifications all
			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
			nodes.
			A module is identified by "module:" followed the module-name. Top
			level module statements are listed immediately following, offset by 4
			spaces. Augmentations are listed next, offset by 2 spaces and
			identified by the keyword "augment" followed by the augment target
			node and a colon (':') character. This is followed by, RPCs which
			are identified by "rpcs:" and are also offset by 2 spaces.
			Notifications are last and are identified by "notifications:" and are
			also offset by 2 spaces.
			The relative organization of each section is provided using a text-
			based format that is typical of a file system directory tree display
			command. Each node in the tree is prefaces with '+--'. Schema nodes
			that are children of another node are offset from the parent by 3
			spaces. Schema peer nodes separated are listed with the same space
			offset and, when separated by lines, linked via a pipe ('|')
			character.
			The full format, including spacing conventions is:
			module: <module-name>
			+--<node>
			| +--<node>
			| +--<node>
			+--<node>
			+--<node>
			+--<node>
			augment <target-node>:
			+--<node>
			+--<node>
			+--<node>
			+--<node>
			rpcs:
			+--<node>
			+--<node>
			notifications:
			+--<node>
			+--<node>
			| +--<node>
			+--<node>
			2.1. Submodules
			Submodules are represented in the same fashion as modules, but are
			identified by "submodule:" followed the (sub)module-name. For
			example:
			submodule: <module-name>
			+--<node>
			| +--<node>
			| +--<node>
			2.2. Groupings
			Nodes within a used grouping are expanded as if the nodes were
			defined at the location of the uses statement.
			2.3. Collapsed Node Representation
			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
			their children can be collapsed using the notation '...' in place of
			the text lines used to represent the summarized nodes. For example:
			+--<node>
			| ...
			+--<node>
			+--<node>
			+--<node>
			2.4. 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
	-x for rpcs and actions		-x for rpcs and actions
	-n for notifications		-n for notifications
	skipping to change at page 3, line 17 ¶		skipping to change at page 5, line 14 ¶
	<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
	-x for rpcs and actions		-x for rpcs and actions
	-n for notifications		-n for notifications
			mp for schema mount points
	<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, its		If the node is augmented into the tree from another module, its
	name is printed as <prefix>:<name>.		name is printed as <prefix>:<name>.
	<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 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		<type> is the name of the type for leafs and leaf-lists
	If the type is a leafref, the type is printed as "-> TARGET",		If the type is a leafref, the type is printed as "-> TARGET",
	where TARGET is either the leafref path, with prefixed removed		where TARGET is either the leafref path, with prefixed removed
	if possible.		if possible.
	<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 "{...}?"
	3. Next Steps		2.5. Extensions
	Authors' note: This draft is currently a bit rough. The next/future		TBD
	version is expected to add text covering different types of trees and
	when to use them; for example, complete module trees, subtrees, trees
	for groupings etc. Maybe also how to deal with the limited line
	lengths in RFCs.
	4. IANA Considerations		3. Usage Guidelines For RFCs
			This section provides general guidelines related to the use of tree
			diagrams in RFCs. This section covers [Authors' note: will cover]
			different types of trees and when to use them; for example, complete
			module trees, subtrees, trees for groupings etc.
			3.1. Wrapping Long Lines
			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
			node results in line being longer than this limit the line should be
			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
			least two characters. For example:
			notifications:
			+---n yang-library-change
			+--ro module-set-id
			-> /modules-state/module-set-id
			The previously 'pyang' command can be helpful in producing such
			output, for example the above example was produced using:
			pyang -f tree --tree-line-length 50 < ietf-yang-library.yang
			4. YANG Schema Mount Tree Diagrams
			YANG Schema Mount is defined in [I-D.ietf-netmod-schema-mount] and
			warrants some specific discussion. Schema mount document is a
			generic mechanism that allows for mounting one data model consisting
			of any number of YANG modules at a specified location of another
			(parent) schema. Modules containing mount points will identify mount
			points by name using the mount-point extension. These mount-points
			should be identified, as indicated above using the 'mp' flag. For
			example:
			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?
			Note that a mount point definition alone is not sufficient to
			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,
			it is helpful to show how the mount point would look with mounted
			modules. In such cases, the mount point should be treated much like
			a 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 example, the following
			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/
			| ...
			+--rw rt:routing/
			| ...
			+--ro if:interfaces@
			| ...
			+--ro if:interfaces-state@
			...
			The with 'config' indicating false, the only change would be to the
			flag on the rt:routing node:
			+--ro rt:routing/
			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.
	5. Informative References		6. Informative References
			[I-D.ietf-netmod-schema-mount]
			Bjorklund, M. and L. Lhotka, "YANG Schema Mount", draft-
			ietf-netmod-schema-mount-05 (work in progress), May 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>.		<http://www.rfc-editor.org/info/rfc7223>.
	[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>.
	Authors' Addresses		Authors' Addresses
End of changes. 13 change blocks.
	19 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/