draft-ietf-netmod-arch-04.txt		draft-ietf-netmod-arch-05.txt
	Network Working Group P. Shafer		Network Working Group P. Shafer
	Internet-Draft Juniper Networks		Internet-Draft Juniper Networks
	Intended status: Informational March 8, 2010		Intended status: Informational April 16, 2010
	Expires: September 9, 2010		Expires: October 18, 2010
	An NETCONF- and NETMOD-based Architecture for Network Management		An NETCONF- and NETMOD-based Architecture for Network Management
	draft-ietf-netmod-arch-04		draft-ietf-netmod-arch-05
	Abstract		Abstract
	NETCONF gives access to native capabilities of the devices within a		NETCONF gives access to native capabilities of the devices within a
	network, defining methods for manipulating configuration databases,		network, defining methods for manipulating configuration databases,
	retrieving operational data, and invoking specific operations. YANG		retrieving operational data, and invoking specific operations. YANG
	provides the means to define the content carried via NETCONF, both		provides the means to define the content carried via NETCONF, both
	data and operations. Using both technologies, standard modules can		data and operations. Using both technologies, standard modules can
	be defined to give interoperability and commonality to devices, while		be defined to give interoperability and commonality to devices, while
	still allowing devices to express their unique capabilities.		still allowing devices to express their unique capabilities.
	skipping to change at page 1, line 45		skipping to change at page 1, line 45
	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."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on September 9, 2010.		This Internet-Draft will expire on October 18, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2010 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 3, line 19		skipping to change at page 3, line 19
	2.1. NETCONF . . . . . . . . . . . . . . . . . . . . . . . . . 6		2.1. NETCONF . . . . . . . . . . . . . . . . . . . . . . . . . 6
	2.2. YANG . . . . . . . . . . . . . . . . . . . . . . . . . . . 8		2.2. YANG . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	2.2.1. Constraints . . . . . . . . . . . . . . . . . . . . . 10		2.2.1. Constraints . . . . . . . . . . . . . . . . . . . . . 10
	2.2.2. Flexibility . . . . . . . . . . . . . . . . . . . . . 11		2.2.2. Flexibility . . . . . . . . . . . . . . . . . . . . . 11
	2.2.3. Extensibility Model . . . . . . . . . . . . . . . . . 11		2.2.3. Extensibility Model . . . . . . . . . . . . . . . . . 11
	2.3. YANG Technologies . . . . . . . . . . . . . . . . . . . . 13		2.3. YANG Technologies . . . . . . . . . . . . . . . . . . . . 13
	2.3.1. YIN . . . . . . . . . . . . . . . . . . . . . . . . . 13		2.3.1. YIN . . . . . . . . . . . . . . . . . . . . . . . . . 13
	2.3.2. DSDL (Relax NG) . . . . . . . . . . . . . . . . . . . 13		2.3.2. DSDL (Relax NG) . . . . . . . . . . . . . . . . . . . 13
	2.4. YANG Types . . . . . . . . . . . . . . . . . . . . . . . . 14		2.4. YANG Types . . . . . . . . . . . . . . . . . . . . . . . . 14
	3. Working with YANG . . . . . . . . . . . . . . . . . . . . . . 15		3. Working with YANG . . . . . . . . . . . . . . . . . . . . . . 15
	3.1. Addressing Operator Problems . . . . . . . . . . . . . . . 15		3.1. Building YANG-based Solutions . . . . . . . . . . . . . . 15
	3.2. Building YANG-based Solutions . . . . . . . . . . . . . . 17		3.2. Addressing Operator Problems . . . . . . . . . . . . . . . 16
	3.3. Modeler . . . . . . . . . . . . . . . . . . . . . . . . . 17		3.3. Building YANG-based Solutions . . . . . . . . . . . . . . 18
	3.4. Reviewer . . . . . . . . . . . . . . . . . . . . . . . . . 17		3.4. Modeler . . . . . . . . . . . . . . . . . . . . . . . . . 19
	3.5. Device Developer . . . . . . . . . . . . . . . . . . . . . 17		3.5. Reviewer . . . . . . . . . . . . . . . . . . . . . . . . . 19
	3.5.1. Generic Content Support . . . . . . . . . . . . . . . 17		3.6. Device Developer . . . . . . . . . . . . . . . . . . . . . 19
	3.5.2. XML "over the wire" Definitions . . . . . . . . . . . 18		3.6.1. Generic Content Support . . . . . . . . . . . . . . . 19
	3.6. Application Developer . . . . . . . . . . . . . . . . . . 18		3.6.2. XML "over the wire" Definitions . . . . . . . . . . . 20
	3.6.1. Hard Coded . . . . . . . . . . . . . . . . . . . . . . 18		3.7. Application Developer . . . . . . . . . . . . . . . . . . 20
	3.6.2. Bottom Up . . . . . . . . . . . . . . . . . . . . . . 18		3.7.1. Hard Coded . . . . . . . . . . . . . . . . . . . . . . 20
	3.6.3. Top Down . . . . . . . . . . . . . . . . . . . . . . . 19		3.7.2. Bottom Up . . . . . . . . . . . . . . . . . . . . . . 20
	4. Modeling Considerations . . . . . . . . . . . . . . . . . . . 21		3.7.3. Top Down . . . . . . . . . . . . . . . . . . . . . . . 21
	4.1. Default Values . . . . . . . . . . . . . . . . . . . . . . 21		4. Modeling Considerations . . . . . . . . . . . . . . . . . . . 23
	4.2. Compliance . . . . . . . . . . . . . . . . . . . . . . . . 21		4.1. Default Values . . . . . . . . . . . . . . . . . . . . . . 23
	4.3. Data Distinctions . . . . . . . . . . . . . . . . . . . . 22		4.2. Compliance . . . . . . . . . . . . . . . . . . . . . . . . 24
	4.3.1. Background . . . . . . . . . . . . . . . . . . . . . . 22		4.3. Data Distinctions . . . . . . . . . . . . . . . . . . . . 24
	4.3.2. Definitions . . . . . . . . . . . . . . . . . . . . . 22		4.3.1. Background . . . . . . . . . . . . . . . . . . . . . . 25
	4.3.3. Implications . . . . . . . . . . . . . . . . . . . . . 24		4.3.2. Definitions . . . . . . . . . . . . . . . . . . . . . 25
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 25		4.3.3. Implications . . . . . . . . . . . . . . . . . . . . . 27
	6. Normative References . . . . . . . . . . . . . . . . . . . . . 26		5. Security Considerations . . . . . . . . . . . . . . . . . . . 28
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 27		6. Normative References . . . . . . . . . . . . . . . . . . . . . 29
			Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 30
	1. Origins of YANG		1. Origins of YANG
	Networks are increasing in complexity and capacity, as well as the		Networks are increasing in complexity and capacity, as well as the
	density of the services deployed upon them. Uptime, reliability, and		density of the services deployed upon them. Uptime, reliability, and
	predictable latency requirements drive the need for automation. The		predictable latency requirements drive the need for automation. The
	problems with network management are not simple. They are complex		problems with network management are not simple. They are complex
	and intricate. But these problems must be solved for networks to		and intricate. But these problems must be solved for networks to
	meet the stability needs of existing services while incorporating new		meet the stability needs of existing services while incorporating new
	services in a world where the growth of networks is exhausting the		services in a world where the growth of networks is exhausting the
	skipping to change at page 4, line 34		skipping to change at page 4, line 34
	operator's needs were reasonable and straight forward, including the		operator's needs were reasonable and straight forward, including the
	need for transactions, rollback, low implementation costs, and the		need for transactions, rollback, low implementation costs, and the
	ability to save and restore the device's configuration data. Many of		ability to save and restore the device's configuration data. Many of
	the observations give insight into the problems operators were having		the observations give insight into the problems operators were having
	with existing network management solutions, such as the lack of full		with existing network management solutions, such as the lack of full
	coverage of device capabilities and the ability to distinguish		coverage of device capabilities and the ability to distinguish
	between configuration data and other types of data.		between configuration data and other types of data.
	Based on these directions, the NETCONF working group was formed and		Based on these directions, the NETCONF working group was formed and
	the NETCONF protocol was created. This protocol defines a simple		the NETCONF protocol was created. This protocol defines a simple
	RPC-based mechanism where network management applications, acting as		mechanism where network management applications, acting as clients,
	clients, can invoke operations on the devices, which act as servers.		can invoke operations on the devices, which act as servers. The
	The NETCONF specification defines a small set of operations, but goes		NETCONF specification defines a small set of operations, but goes out
	out of its way to avoid making any requirements on the data carried		of its way to avoid making any requirements on the data carried in
	in those operations, preferring to allow the protocol to carry any		those operations, preferring to allow the protocol to carry any data.
	data. This "data model agnostic" approach allows data models to be		This "data model agnostic" approach allows data models to be defined
	defined independently.		independently.
	But lacking a means of defining data models, the NETCONF protocol was		But lacking a means of defining data models, the NETCONF protocol was
	not usable for standards-based work. Existing data modeling		not usable for standards-based work. Existing data modeling
	languages such as XSD and Relax NG were considered, but were rejected		languages such as XSD and Relax NG were considered, but were rejected
	because the problem domains have little natural overlap. Defining an		because the problem domains have little natural overlap. Defining a
	RPC which is encoded in XML is a distinct problem from defining an		protocol which is encoded in XML is a distinct problem from defining
	XML document.		an XML document.
	In early 2005, the NETMOD working group embraced YANG ([RFCYANG]) as		In 2007 and 2008, the issue of a data modeling language for NETCONF
	a means for defining data models for NETCONF, allowing both standard		was discussed in the OPS and APPS areas of IETF 70 and 71, and a
	and proprietary data models to be published in a form that easily		design team was tasked with creating a requirements document (expired
	digestible by human readers and satisfies many of the issues raised		I-D draft-presuhn-rcdml-03.txt). After discussing the available
	in the IAB NM workshop. This brings NETCONF to a point where is can		options at the CANMOD BoF at IETF71, the community wrote a charter
	be used to develop standards within the IETF.		for the NETMOD working group. An excellent description of this time
			period is available at
			http://www.mail-archive.com/ietf@ietf.org/msg37006.html
			In 2008 and 2009, the NETMOD working group produced a specification
			for YANG ([RFCYANG]) as a means for defining data models for NETCONF,
			allowing both standard and proprietary data models to be published in
			a form that easily digestible by human readers and satisfies many of
			the issues raised in the IAB NM workshop. This brings NETCONF to a
			point where is can be used to develop standards within the IETF.
	YANG allows a modeler to create a data model, to define the		YANG allows a modeler to create a data model, to define the
	organization of the data in that model, and to define constraints on		organization of the data in that model, and to define constraints on
	that data. Once published, the YANG module acts as a contract		that data. Once published, the YANG module acts as a contract
	between the client and server, with both parties understanding how		between the client and server, with both parties understanding how
	their peer will expect them to behave. A client knows how to create		their peer will expect them to behave. A client knows how to create
	valid data for the server, and knows what data will be sent from the		valid data for the server, and knows what data will be sent from the
	server. A server knows the rules that govern the data and how it		server. A server knows the rules that govern the data and how it
	should behave.		should behave.
	skipping to change at page 6, line 12		skipping to change at page 6, line 12
	related technologies work and how solutions built on them can address		related technologies work and how solutions built on them can address
	the network management problem domain.		the network management problem domain.
	2. Elements of YANG		2. Elements of YANG
	2.1. NETCONF		2.1. NETCONF
	YANG is focused on creating data models for NETCONF, and any		YANG is focused on creating data models for NETCONF, and any
	understanding of the former must begin with the latter.		understanding of the former must begin with the latter.
	NETCONF defines an XML-based RPC mechanism that leverages the		NETCONF defines an XML-based remote procedure call (RPC) mechanism
	simplicity and availability of high-quality XML parsers. XML gives a		that leverages the simplicity and availability of high-quality XML
	rich, flexible, hierarchical, standard representation of data that		parsers. XML gives a rich, flexible, hierarchical, standard
	matches the needs of networking devices. NETCONF carries		representation of data that matches the needs of networking devices.
	configuration data and operations encoded in XML using an RPC		NETCONF carries configuration data and operations as requests and
	mechanism over a connection-oriented transport.		replies using RPCs encoded in XML over a connection-oriented
			transport.
	XML's hierarchical data representation allows complex networking data		XML's hierarchical data representation allows complex networking data
	to be rendered in a natural way. For example, the following		to be rendered in a natural way. For example, the following
	configuration places interfaces in OSPF areas. The <ospf> element		configuration places interfaces in OSPF areas. The <ospf> element
	contains a list of <area> elements, each of which contain a list of		contains a list of <area> elements, each of which contain a list of
	<interface> elements. The <name> element identifies the specific		<interface> elements. The <name> element identifies the specific
	area or interface. Additional configuration for each area or		area or interface. Additional configuration for each area or
	interface appears directly inside the appropriate element.		interface appears directly inside the appropriate element.
	<ospf xmlns="http://example.org/netconf/ospf">		<ospf xmlns="http://example.org/netconf/ospf">
	skipping to change at page 9, line 26		skipping to change at page 9, line 26
	leaf name {		leaf name {
	type nett:area-id;		type nett:area-id;
	}		}
	list interface {		list interface {
	key name;		key name;
	leaf name {		leaf name {
	type nett:interface-name;		type nett:interface-name;
	}		}
	leaf priority {		leaf priority {
	description "Designated router priority";		description "Designated router priority";
	type uint { // The type and range are		type uint8; // The type is a constraint on
	range 0..255; // constraints on valid		// valid values for "priority".
	} // values for "priority".
	}		}
	leaf metric {		leaf metric {
	type uint {		type uint16 {
	range 1..65535;		range 1..65535;
	}		}
	}		}
	leaf dead-interval {		leaf dead-interval {
	units seconds;		units seconds;
	type uint {		type uint16 {
	range 1..65535;		range 1..65535;
	}		}
	}		}
	}		}
	}		}
	}		}
	}		}
	A YANG module defines a data model in terms of the data, its		A YANG module defines a data model in terms of the data, its
	hierarchical organization, and the constraints on that data. YANG		hierarchical organization, and the constraints on that data. YANG
	skipping to change at page 13, line 41		skipping to change at page 13, line 41
	elements, preserving the structure and content of YANG, but enabling		elements, preserving the structure and content of YANG, but enabling
	the use of off-the-shelf XML parsers rather than requiring the		the use of off-the-shelf XML parsers rather than requiring the
	integration of a YANG parser. YIN maintains complete semantic		integration of a YANG parser. YIN maintains complete semantic
	equivalence with YANG.		equivalence with YANG.
	2.3.2. DSDL (Relax NG)		2.3.2. DSDL (Relax NG)
	Since NETCONF content is encoded in XML, it is natural to use XML		Since NETCONF content is encoded in XML, it is natural to use XML
	schema languages for their validation. To facilitate this, YANG		schema languages for their validation. To facilitate this, YANG
	offers a standardized mapping of YANG modules into Document Schema		offers a standardized mapping of YANG modules into Document Schema
	Description Languages (DSDL) [DSDL].		Description Languages ([DSDL]).
	DSDL is considered to be the best choice for the given purpose		DSDL is considered to be the best choice for the given purpose
	because it addresses not only grammar and datatypes of XML documents		because it addresses not only grammar and datatypes of XML documents
	but also semantic constraints and rules for modifying information set		but also semantic constraints and rules for modifying information set
	of the document.		of the document.
	In addition, DSDL offers formal means for coordinating multiple		In addition, DSDL offers formal means for coordinating multiple
	independent schemas and specifying how to apply the schemas to the		independent schemas and specifying how to apply the schemas to the
	various parts of the document. This is useful since YANG content is		various parts of the document. This is useful since YANG content is
	typically composed of multiple vocabularies.		typically composed of multiple vocabularies.
	skipping to change at page 15, line 7		skipping to change at page 15, line 7
	YANG supports a number of builtin types, and allows additional types		YANG supports a number of builtin types, and allows additional types
	to be derived from those types in an extensible manner. New types		to be derived from those types in an extensible manner. New types
	can add additional restrictions to allowable data values.		can add additional restrictions to allowable data values.
	A standard type library for use by YANG is available [RFCYANGTYPES].		A standard type library for use by YANG is available [RFCYANGTYPES].
	These YANG modules define commonly used data types for IETF-related		These YANG modules define commonly used data types for IETF-related
	standards.		standards.
	3. Working with YANG		3. Working with YANG
	3.1. Addressing Operator Problems		3.1. Building YANG-based Solutions
			In the typical YANG-based solution, the client and server are driven
			by the content of YANG modules. The server includes the definitions
			of the modules as meta-data that is available to the NETCONF engine.
			This engine processes incoming requests, uses the meta-data to parse
			and verify the request, performs the requested operation, and returns
			the results to the client.
			+----------------------------+
			|Server (device) |
			| +--------------------+ |
			| | configuration | |
			+----+ | | ---------------| |
			|YANG|+ | | m d state data | |
			|mods||+ | | e a ---------------| |
			+----+|| -----> | t t notifications | |
			+----+| | | a a ---------------| |
			+----+ | | operations | |
			| +--------------------+ |
			| ^ |
			| | |
			| v |
			+------+ | +-------------+ |
			| | -------------> | | |
			|Client| <rpc> | | NETCONF | |
			| (app)| | | engine | |
			| | <------------ | | |
			+------+ <rpc-reply> +-------------+ |
			| / \ |
			| / \ |
			| / \ |
			| +--------+ +---------+ |
			| | config | |system |+ |
			| | data- | |software ||+ |
			| | base | |component||| |
			| +--------+ +---------+|| |
			| +---------+| |
			| +---------+ |
			+----------------------------+
			To use YANG, YANG modules must be defined to model the specific
			problem domain. These modules are then loaded, compiled, or coded
			into the server.
			The sequence of events for the typical client/server interaction is
			as follows:
			o A client application ([C]) opens a NETCONF session to the server
			(device) ([S])
			o [C] and [S] exchange <hello> messages containing the list of
			capabilities supported by each side, allowing [C] to learn the
			modules supported by [S]
			o [C] builds and sends an operation defined in the YANG module,
			encoded in XML, within NETCONF's <rpc> element
			o [S] receives and parses the <rpc> element
			o [S] verifies the contents of the request against the data defined
			in the YANG module
			o [S] performs the requested operation, possibly changing the
			configuration database
			o [S] builds the response, containing the response, any requested
			data, and any errors
			o [S] sends the response, encoded in XML, within NETCONF's
			<rpc-reply> element
			o [C] receives and parses the <rpc-reply> element
			o [C] inspects the response and processes it as needed
			Note that there is no requirement for the client or server to process
			the YANG modules in this way. The server may hard code the contents
			of the data model, rather than handle the content via a generic
			engine. Or the client may be targeted at the specific YANG model,
			rather than being driven generically. Such a client might be a
			simple shell script that stuffs arguments into an XML payload and
			sends it to the server.
			3.2. Addressing Operator Problems
	YANG addresses many of the issues raised in the IAB NM workshop.		YANG addresses many of the issues raised in the IAB NM workshop.
	o Ease of use: YANG is designed to be human friendly, simple and		o Ease of use: YANG is designed to be human friendly, simple and
	readable. Many tricky issues remain due to the complexity of the		readable. Many tricky issues remain due to the complexity of the
	problem domain, but YANG strives to make them more visible and		problem domain, but YANG strives to make them more visible and
	easier to deal with.		easier to deal with.
	o Configuration and Operational data: YANG clearly divides		o Configuration and Operational data: YANG clearly divides
	configuration data from other types of data.		configuration data from other types of data.
	skipping to change at page 17, line 5		skipping to change at page 18, line 41
	mechanisms when the connection is lost.		mechanisms when the connection is lost.
	o Delta friendly: YANG-based models support operations that are		o Delta friendly: YANG-based models support operations that are
	delta friendly. Add, change, insert, and delete operations are		delta friendly. Add, change, insert, and delete operations are
	all well defined.		all well defined.
	o Method-oriented: YANG allows new NETCONF RPCs to be defined,		o Method-oriented: YANG allows new NETCONF RPCs to be defined,
	including an operation name, which is essentially a method. The		including an operation name, which is essentially a method. The
	RPC's input and output data are also defined in the YANG module.		RPC's input and output data are also defined in the YANG module.
	3.2. Building YANG-based Solutions		3.3. Building YANG-based Solutions
	Building YANG-based solutions requires interacting with many distinct		Building YANG-based solutions requires interacting with many distinct
	groups. Modelers must understand how to build useful models that		groups. Modelers must understand how to build useful models that
	give structure and meaning to data while maximizing the flexibility		give structure and meaning to data while maximizing the flexibility
	of that data to "future proof" their work. Reviewers need to quickly		of that data to "future proof" their work. Reviewers need to quickly
	determine if that structure is accurate. Device developers need to		determine if that structure is accurate. Device developers need to
	code that data model into their devices, and application developers		code that data model into their devices, and application developers
	need to code their applications to take advantage of that data model.		need to code their applications to take advantage of that data model.
	There are a variety of strategies for performing each piece of this		There are a variety of strategies for performing each piece of this
	work. This section discusses some of those strategies.		work. This section discusses some of those strategies.
	3.3. Modeler		3.4. Modeler
	(No clue what needs said here; lots to say, but what's important?)		The modeler's role constructing a model based on their in-depth
			knowledge of the problem domain being modeled. This model should be
			as simple as possible, but should balance complexity with
			expressiveness. The organization of the model should target not only
			the current model, but should allow for extensibility from other
			modules and for adaptability to future changes.
	Additional modeling issues are discussed in Section 4.		Additional modeling issues are discussed in Section 4.
	3.4. Reviewer		3.5. Reviewer
	The reviewer role is perhaps the more important and the time		The reviewer role is perhaps the more important and the time
	reviewers are willing to give is precious. To help the reviewer,		reviewers are willing to give is precious. To help the reviewer,
	YANG stresses readability, with a human-friendly syntax, natural data		YANG stresses readability, with a human-friendly syntax, natural data
	hierarchy, and simple, concise statements.		hierarchy, and simple, concise statements.
	In addition, reviewers can encode review policies in scripts, such as		In addition, reviewers can encode review policies in scripts, such as
	XSLT. A policy that leaf names can't have underscores can be coded		XSLT. A policy that leaf names can't have underscores can be coded
	as:		as:
	<xsl:template match="leaf[contains(@name, '_')]">		<xsl:template match="leaf[contains(@name, '_')]">
	Error: leaf name contains underscore		Error: leaf name contains underscore
	</xsl:template>		</xsl:template>
	3.5. Device Developer		3.6. Device Developer
	The YANG model tells the device developer what data is being modeled.		The YANG model tells the device developer what data is being modeled.
	The developer reads the YANG models, absorbs the zen of the model,		The developer reads the YANG models, absorbs the zen of the model,
	and writes code that supports the model. The model describes the		and writes code that supports the model. The model describes the
	data hierarchy and associated constraints, and the description and		data hierarchy and associated constraints, and the description and
	reference material helps the developer understand how to transform		reference material helps the developer understand how to transform
	the models view into the device's native implementation.		the models view into the device's native implementation.
	3.5.1. Generic Content Support		3.6.1. Generic Content Support
	The YANG model can be compiled into a YANG-based engine for either		The YANG model can be compiled into a YANG-based engine for either
	the client or server side. Incoming data can be validated, as can		the client or server side. Incoming data can be validated, as can
	outgoing data. The complete configuration datastore may be validated		outgoing data. The complete configuration datastore may be validated
	in accordance with the constraints described in the data model.		in accordance with the constraints described in the data model.
	Serializers and deserializers for generating and receiving NETCONF		Serializers and deserializers for generating and receiving NETCONF
	content can be driven by the meta-data in the model. As data is		content can be driven by the meta-data in the model. As data is
	received, the meta-data is consulted to ensure the validity of		received, the meta-data is consulted to ensure the validity of
	incoming XML elements.		incoming XML elements.
	3.5.2. XML "over the wire" Definitions		3.6.2. XML "over the wire" Definitions
	The YANG module dictates the XML encoding sent "over the wire",		The YANG module dictates the XML encoding sent "over the wire",
	though actual transmission should be encrypted so as not to appear as		though actual transmission should be encrypted so as not to appear as
	readable text on the physical media. The rules that define the		readable text on the physical media. The rules that define the
	encoding are fixed, so the YANG module can be used to ascertain		encoding are fixed, so the YANG module can be used to ascertain
	whether a specific NETCONF payload is obeying the rules.		whether a specific NETCONF payload is obeying the rules.
	3.6. Application Developer		3.7. Application Developer
	The YANG module tells the application developer what data can be		The YANG module tells the application developer what data can be
	modeled. Developers can inspect the modules and take one of three		modeled. Developers can inspect the modules and take one of three
	distinct views. In this section, we will consider them and the		distinct views. In this section, we will consider them and the
	impact of YANG on their design. In the real world, most applications		impact of YANG on their design. In the real world, most applications
	are a mixture of these approaches.		are a mixture of these approaches.
	3.6.1. Hard Coded		3.7.1. Hard Coded
	An application can be coded against the specific, well-known contents		An application can be coded against the specific, well-known contents
	of YANG modules, implementing their organization, rules, and logic		of YANG modules, implementing their organization, rules, and logic
	directly with explicit knowledge. For example, a script could be		directly with explicit knowledge. For example, a script could be
	written to change the domain name of a set of devices using a		written to change the domain name of a set of devices using a
	standard YANG module that includes such a leaf node. This script		standard YANG module that includes such a leaf node. This script
	takes the new domain name as an argument and inserts it into a string		takes the new domain name as an argument and inserts it into a string
	containing the rest of the XML encoding as required by the YANG		containing the rest of the XML encoding as required by the YANG
	module. This content is then sent via NETCONF to each of the		module. This content is then sent via NETCONF to each of the
	devices.		devices.
	This type of application is useful for small, fixed problems where		This type of application is useful for small, fixed problems where
	the cost and complexity of flexibility is overwhelmed by the ease of		the cost and complexity of flexibility is overwhelmed by the ease of
	hard coding direct knowledge into the application.		hard coding direct knowledge into the application.
	3.6.2. Bottom Up		3.7.2. Bottom Up
	An application may take a generic, bottom up approach to		An application may take a generic, bottom up approach to
	configuration, concentrating on the device's data directly and		configuration, concentrating on the device's data directly and
	treating that data without specific understanding.		treating that data without specific understanding.
	YANG modules may be used to drive the operation of the YANG		YANG modules may be used to drive the operation of the YANG
	equivalent of a "MIB Browser". Such an application manipulates the		equivalent of a "MIB Browser". Such an application manipulates the
	device's configuration data based on the data organization contained		device's configuration data based on the data organization contained
	in the YANG module. For example, a GUI may present a straight-		in the YANG module. For example, a GUI may present a straight-
	forward visualization where elements of the YANG hierarchy are		forward visualization where elements of the YANG hierarchy are
	depicted in a hierarchy of folders or GUI panels. Clicking on a line		depicted in a hierarchy of folders or GUI panels. Clicking on a line
	expands to the contents of the matching XML hierarchy.		expands to the contents of the matching XML hierarchy.
	This type of GUI can easily be built by generating XSLT stylesheets		This type of GUI can easily be built by generating XSLT stylesheets
	from the YANG data models. An XSLT engine can then be used to turn		from the YANG data models. An XSLT engine can then be used to turn
	configuration data into a set of web pages.		configuration data into a set of web pages.
	The YANG modules allows the application to enforce a set of		The YANG modules allows the application to enforce a set of
	constraints without understanding the semantics of the YANG module.		constraints without understanding the semantics of the YANG module.
	3.6.3. Top Down		3.7.3. Top Down
	In contrast to the bottom-up approach, the top-down approach allows		In contrast to the bottom-up approach, the top-down approach allows
	the application to take a view of the configuration data which is		the application to take a view of the configuration data which is
	distinct from the standard and/or proprietary YANG modules. The		distinct from the standard and/or proprietary YANG modules. The
	application is free to construct its own model for data organization		application is free to construct its own model for data organization
	and to present this model to the user. When the application needs to		and to present this model to the user. When the application needs to
	transmit data to a device, the application transforms its data from		transmit data to a device, the application transforms its data from
	the problem-oriented view of the world into the data needed for that		the problem-oriented view of the world into the data needed for that
	particular device. This transformation is under the control and		particular device. This transformation is under the control and
	maintenance of the application, allowing the transformation to be		maintenance of the application, allowing the transformation to be
	changed and updated without affecting the device.		changed and updated without affecting the device.
	For example, an application could be written that models VPNs in a		For example, an application could be written that models VPNs in a
	network-oriented view. The application would need to transform these		network-oriented view. The application would need to transform these
	high-level VPN definitions into the configuration data that would be		high-level VPN definitions into the configuration data that would be
	handed to any particular device within a VPN.		handed to any particular device within a VPN.
	Even in this approach, YANG is useful since it can be used to model		Even in this approach, YANG is useful since it can be used to model
	the VPN.		the VPN. For example, the following VPN straw-man models a list of
			VPNs, each with a protocol, a topology, a list of member interfaces,
			and a list of classifiers.
	list vpn {		list ietf-bgpvpn {
	key name;		key name;
	leaf name { ... }		leaf name { ... }
	leaf type {		leaf protocol {
	type enumeration {		type enumeration {
	enum bgpvpn;		enum bgpvpn;
	enum l2vpn;		enum l2vpn;
	}		}
	}		}
	leaf topology {		leaf topology {
	type enumeration {		type enumeration {
	enum hub-n-spoke;		enum hub-n-spoke;
	enum mesh;		enum mesh;
	}		}
	skipping to change at page 20, line 33		skipping to change at page 22, line 33
	leaf interface { ... }		leaf interface { ... }
	}		}
	list classifiers {		list classifiers {
	...		...
	}		}
	}		}
	The application can use such a YANG module to drive its operation,		The application can use such a YANG module to drive its operation,
	building VPN instances in a database and then pushing the		building VPN instances in a database and then pushing the
	configuration for those VPNs to individual devices uses either a		configuration for those VPNs to individual devices uses either a
	standard device model (e.g. bgp.yang) or by transforming that		standard device model (e.g. ietf-bgpvpn.yang) or by transforming that
	standard device content into some proprietary format for devices that		standard device content into some proprietary format for devices that
	do not support that standard.		do not support that standard.
	4. Modeling Considerations		4. Modeling Considerations
	This section discusses considerations the modeler should be aware of		This section discusses considerations the modeler should be aware of
	while developing models in YANG.		while developing models in YANG.
	4.1. Default Values		4.1. Default Values
	(With all the discussion on this point, it needs to be mentioned		The concept of default values is simple, but their details,
	here.)		representation, and interaction with configuration data can be
			difficult issues. NETCONF leaves default values as a data model
			issue, and YANG gives flexibility to the device implementation in
			terms of how default values are handled. The requirement is that the
			device "MUST operationally behave as is if the leaf was present in
			the data tree with the default value as its value". This gives the
			device implementation choices in how default values are handled.
			One choice is to view the configuration as a set of instructions for
			how the device should be configured. If a data value is given as
			part of those instructions is the default value, then it should be
			retained as part of the configuration, but if it not explicitly
			given, then the value is not considered to be part of configuration.
			Another choice is to trim values that are identical to the default
			values, implicitly removing them from the configuration database.
			The act of setting a leaf to it's default value effectively deletes
			that leaf.
			The device could also choose to report all default values, regardless
			of whether they were explicitly set. This choice eases the work of a
			client that needs default values, but may significantly increase the
			size of the configuration data.
			These choices reflect the default handling schemes of widely deployed
			networking devices and supporting them allows YANG to reduce
			implementation and deployment costs of YANG-based models.
			When the client retrieves data from the device, it must be prepared
			to handle the absence of leaf nodes with the default value, since the
			server is not required to send such leaf elements. This permits the
			device to implement either of the first two default handling schemes
			given above.
			Regardless of the implementation choice, the device can support the
			"with-defaults" capability ([RFCWITHDEFAULTS]) and give the client
			the ability to select the desired handling of default values.
			When evaluating the XPath expressions for constraints like "must" and
			"when", the evaluation context for the expressions will include any
			appropriate default values, so the modeler can depend on consistent
			behavior from all devices.
	4.2. Compliance		4.2. Compliance
	In developing good data models, there are many conflicting interests		In developing good data models, there are many conflicting interests
	the data modeler must keep in mind. Modelers need to be aware of		the data modeler must keep in mind. Modelers need to be aware of
	four types of behavior in modeled device:		four types of behavior in modeled device:
	o [strict compliance] behavior that follow the model completely		o [strict compliance] behavior that follow the model completely
	o [modeled deviations] behavior that follows within deviations		o [modeled deviations] behavior that follows within deviations
	skipping to change at page 26, line 7		skipping to change at page 29, line 7
	determining the behaviour of the box instead of its static and		determining the behaviour of the box instead of its static and
	explicit configuration state.		explicit configuration state.
	5. Security Considerations		5. Security Considerations
	This document discusses data modeling using YANG, and has no security		This document discusses data modeling using YANG, and has no security
	impact on the Internet.		impact on the Internet.
	6. Normative References		6. Normative References
			[DSDL] International Organization for Standardization, "DSDL Part
			0 - Overview", ISO DSDL, December 2001.
	[RFC3535] Schoenwaelder, J., "Overview of the 2002 IAB Network		[RFC3535] Schoenwaelder, J., "Overview of the 2002 IAB Network
	Management Workshop", RFC 3535, May 2003.		Management Workshop", RFC 3535, May 2003.
	[RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741,		[RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741,
	December 2006.		December 2006.
			[RFCWITHDEFAULTS]
			Bierman, A. and B. Lengyel, "With-defaults capability for
			NETCONF", draft-ietf-netconf-with-defaults-05.txt (work in
			progress).
	[RFCYANG] Bjorklund, M., Ed., "YANG - A data modeling language for		[RFCYANG] Bjorklund, M., Ed., "YANG - A data modeling language for
	NETCONF", draft-ietf-netmod-yang-11 (work in progress).		NETCONF", draft-ietf-netmod-yang-11 (work in progress).
	[RFCYANGTYPES]		[RFCYANGTYPES]
	Schoenwaelder, J., Ed., "Common YANG Data Types",		Schoenwaelder, J., Ed., "Common YANG Data Types",
	draft-ietf-netmod-yang-types-07.txt (work in progress).		draft-ietf-netmod-yang-types-07.txt (work in progress).
	Author's Address		Author's Address
	Phil Shafer		Phil Shafer
End of changes. 31 change blocks.
	71 lines changed or deleted		221 lines changed or added
This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/