draft-ietf-netmod-arch-07.txt		draft-ietf-netmod-arch-08.txt
	Network Working Group P. Shafer		Network Working Group P. Shafer
	Internet-Draft Juniper Networks		Internet-Draft Juniper Networks
	Intended status: Informational June 23, 2010		Intended status: Informational August 20, 2010
	Expires: December 25, 2010		Expires: February 21, 2011
	An Architecture for Network Management using NETCONF and YANG		An Architecture for Network Management using NETCONF and YANG
	draft-ietf-netmod-arch-07		draft-ietf-netmod-arch-08
	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 39		skipping to change at page 1, line 39
	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 25, 2010.		This Internet-Draft will expire on February 21, 2011.
	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 12		skipping to change at page 3, line 12
	it for publication as an RFC or to translate it into languages other		it for publication as an RFC or to translate it into languages other
	than English.		than English.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1. Origins of NETCONF and YANG . . . . . . . . . . . . . . . 4		1.1. Origins of NETCONF and YANG . . . . . . . . . . . . . . . 4
	2. Elements of the Architecture . . . . . . . . . . . . . . . . . 6		2. Elements of the Architecture . . . . . . . . . . . . . . . . . 6
	2.1. NETCONF . . . . . . . . . . . . . . . . . . . . . . . . . 6		2.1. NETCONF . . . . . . . . . . . . . . . . . . . . . . . . . 6
	2.1.1. NETCONF Transport Mappings . . . . . . . . . . . . . . 8		2.1.1. NETCONF Transport Mappings . . . . . . . . . . . . . . 8
	2.2. YANG . . . . . . . . . . . . . . . . . . . . . . . . . . . 8		2.2. YANG . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	2.2.1. Constraints . . . . . . . . . . . . . . . . . . . . . 10		2.2.1. Constraints . . . . . . . . . . . . . . . . . . . . . 11
	2.2.2. Flexibility . . . . . . . . . . . . . . . . . . . . . 11		2.2.2. Flexibility . . . . . . . . . . . . . . . . . . . . . 12
	2.2.3. Extensibility Model . . . . . . . . . . . . . . . . . 12		2.2.3. Extensibility Model . . . . . . . . . . . . . . . . . 12
	2.3. YANG Translations . . . . . . . . . . . . . . . . . . . . 13		2.3. YANG Translations . . . . . . . . . . . . . . . . . . . . 13
	2.3.1. YIN . . . . . . . . . . . . . . . . . . . . . . . . . 13		2.3.1. YIN . . . . . . . . . . . . . . . . . . . . . . . . . 14
	2.3.2. DSDL (Relax NG) . . . . . . . . . . . . . . . . . . . 14		2.3.2. DSDL (Relax NG) . . . . . . . . . . . . . . . . . . . 14
	2.4. YANG Types . . . . . . . . . . . . . . . . . . . . . . . . 14		2.4. YANG Types . . . . . . . . . . . . . . . . . . . . . . . . 14
	2.5. IETF Guidelines . . . . . . . . . . . . . . . . . . . . . 14		2.5. IETF Guidelines . . . . . . . . . . . . . . . . . . . . . 15
	3. Working with YANG . . . . . . . . . . . . . . . . . . . . . . 15		3. Working with YANG . . . . . . . . . . . . . . . . . . . . . . 16
	3.1. Building NETCONF- and YANG-based Solutions . . . . . . . . 15		3.1. Building NETCONF- and YANG-based Solutions . . . . . . . . 16
	3.2. Addressing Operator Requirements . . . . . . . . . . . . . 16		3.2. Addressing Operator Requirements . . . . . . . . . . . . . 17
	3.3. Roles in Building Solutions . . . . . . . . . . . . . . . 18		3.3. Roles in Building Solutions . . . . . . . . . . . . . . . 19
	3.3.1. Modeler . . . . . . . . . . . . . . . . . . . . . . . 19		3.3.1. Modeler . . . . . . . . . . . . . . . . . . . . . . . 20
	3.3.2. Reviewer . . . . . . . . . . . . . . . . . . . . . . . 19		3.3.2. Reviewer . . . . . . . . . . . . . . . . . . . . . . . 20
	3.3.3. Device Developer . . . . . . . . . . . . . . . . . . . 19		3.3.3. Device Developer . . . . . . . . . . . . . . . . . . . 20
	3.3.4. Application Developer . . . . . . . . . . . . . . . . 20		3.3.4. Application Developer . . . . . . . . . . . . . . . . 21
	4. Modeling Considerations . . . . . . . . . . . . . . . . . . . 23		4. Modeling Considerations . . . . . . . . . . . . . . . . . . . 24
	4.1. Default Values . . . . . . . . . . . . . . . . . . . . . . 23		4.1. Default Values . . . . . . . . . . . . . . . . . . . . . . 24
	4.2. Compliance . . . . . . . . . . . . . . . . . . . . . . . . 24		4.2. Compliance . . . . . . . . . . . . . . . . . . . . . . . . 25
	4.3. Data Distinctions . . . . . . . . . . . . . . . . . . . . 25		4.3. Data Distinctions . . . . . . . . . . . . . . . . . . . . 26
	4.3.1. Background . . . . . . . . . . . . . . . . . . . . . . 25		4.3.1. Background . . . . . . . . . . . . . . . . . . . . . . 26
	4.3.2. Definitions . . . . . . . . . . . . . . . . . . . . . 26		4.3.2. Definitions . . . . . . . . . . . . . . . . . . . . . 27
	4.3.3. Implications . . . . . . . . . . . . . . . . . . . . . 27		4.3.3. Implications . . . . . . . . . . . . . . . . . . . . . 28
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 29		4.4. Direction . . . . . . . . . . . . . . . . . . . . . . . . 29
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30		5. Security Considerations . . . . . . . . . . . . . . . . . . . 30
	7. Normative References . . . . . . . . . . . . . . . . . . . . . 31		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 32		7. Normative References . . . . . . . . . . . . . . . . . . . . . 32
			Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 34
	1. Introduction		1. Introduction
	1.1. Origins of NETCONF and YANG		1.1. Origins of NETCONF and 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
	skipping to change at page 4, line 38		skipping to change at page 4, line 38
	to save and restore the device's configuration data. Many of the		to save and restore the device's configuration data. Many of the
	observations give insight into the problems operators were having		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 Network Configuration (NETCONF) protocol was created. This		the Network Configuration (NETCONF) protocol was created. This
	protocol defines a simple mechanism where network management		protocol defines a simple mechanism where network management
	applications, acting as clients, can invoke operations on the		applications, acting as clients, can invoke operations on the
	devices, which act as servers. The NETCONF specification defines a		devices, which act as servers. The NETCONF specification ([RFC4741])
	small set of operations, but goes out of its way to avoid making any		defines a small set of operations, but goes out of its way to avoid
	requirements on the data carried in those operations, preferring to		making any requirements on the data carried in those operations,
	allow the protocol to carry any data. This "data model agnostic"		preferring to allow the protocol to carry any data. This "data model
	approach allows data models to be defined independently.		agnostic" approach allows data models to be defined 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 ([W3CXSD]) and DSDL ([ISODSDL]) were
	because the problem domains have little natural overlap. Defining a		considered, but were rejected because the problem domains have little
	protocol which is encoded in XML is a distinct problem from defining		natural overlap. Defining a data model or protocol that is encoded
	an XML document.		in XML is a distinct problem from defining an XML document. The use
			of NETCONF operations place requirements on the data content that are
			not shared with the static document problem domain addressed by
			schema languages like XSD or Relax NG.
	In 2007 and 2008, the issue of a data modeling language for NETCONF		In 2007 and 2008, the issue of a data modeling language for NETCONF
	was discussed in the OPS and APPS areas of IETF 70 and 71, and a		was discussed in the OPS and APPS areas of IETF 70 and 71, and a
	design team was tasked with creating a requirements document (expired		design team was tasked with creating a requirements document (expired
	I-D draft-presuhn-rcdml-03.txt). After discussing the available		I-D draft-presuhn-rcdml-03.txt). After discussing the available
	options at the CANMOD BoF at IETF71, the community wrote a charter		options at the CANMOD BoF at IETF71, the community wrote a charter
	for the NETMOD working group. An excellent description of this time		for the NETMOD working group. An excellent description of this time
	period is available at		period is available at
	http://www.mail-archive.com/ietf@ietf.org/msg37006.html		http://www.mail-archive.com/ietf@ietf.org/msg37006.html
	skipping to change at page 7, line 50		skipping to change at page 7, line 50
	NETCONF includes mechanisms for controlling configuration datastores.		NETCONF includes mechanisms for controlling configuration datastores.
	Each datastore is a specific collection of configuration data that		Each datastore is a specific collection of configuration data that
	can be used as source or target of the configuration-related		can be used as source or target of the configuration-related
	operations. The device can indicate whether it has a distinct		operations. The device can indicate whether it has a distinct
	"startup" configuration datastore, whether the current or "running"		"startup" configuration datastore, whether the current or "running"
	datastore is directly writable, or whether there is a "candidate"		datastore is directly writable, or whether there is a "candidate"
	configuration datastore where configuration changes can be made that		configuration datastore where configuration changes can be made that
	will not affect the device until a "commit-configuration" operation		will not affect the device until a "commit-configuration" operation
	is invoked.		is invoked.
	NETCONF defined operations that are invoked as RPCs from the client		NETCONF defines operations that are invoked as RPCs from the client
	(the application) to the server (running on the device). The		(the application) to the server (running on the device). The
	following table lists these operations:		following table lists some of these operations:
	+-------------+----------------------------------------------------+		+---------------+---------------------------------------------------+
	| Operation | Description |		| Operation | Description |
	+-------------+----------------------------------------------------+		+---------------+---------------------------------------------------+
	| commit | Commits the "candidate" configuration to "running" |		| commit | Commits the "candidate" configuration to |
	| copy-config | Copy one configuration datastore to another |		| | "running" |
	| edit-config | Change the contents of a configuration database |		| copy-config | Copy one configuration datastore to another |
	| get-config | Retrieve all or part of a configuration datastore |		| delete-config | Delete a portion of a configuration datastore |
	| lock | Prevent changes to a datastore from another party |		| edit-config | Change the contents of a configuration datastore |
	| unlock | Release a lock on a datastore |		| get-config | Retrieve all or part of a configuration datastore |
	+-------------+----------------------------------------------------+		| lock | Prevent changes to a datastore from another party |
			| unlock | Release a lock on a datastore |
			+---------------+---------------------------------------------------+
	NETCONF's "capability" mechanism allows the device to announce the		NETCONF's "capability" mechanism allows the device to announce the
	set of capabilities that the device supports, including protocol		set of capabilities that the device supports, including protocol
	operations, datastores, data models, and other abilities. These are		operations, datastores, data models, and other abilities. These are
	announced during session establishment as part of the <hello>		announced during session establishment as part of the <hello>
	message. A client can inspect the hello message to determine what		message. A client can inspect the hello message to determine what
	the device is capable of and how to interact with the device to		the device is capable of and how to interact with the device to
	perform the desired tasks.		perform the desired tasks.
	NETCONF also defines a means of sending asynchronous notifications		NETCONF also defines a means of sending asynchronous notifications
	skipping to change at page 14, line 14		skipping to change at page 14, line 37
	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 ([RFCYANGDSDL]).		Description Languages ([RFCYANGDSDL]).
	DSDL is considered to be the best choice for the given purpose		DSDL is considered to be the best choice as a standard schema
	because it addresses not only grammar and datatypes of XML documents		language because it addresses not only grammar and datatypes of XML
	but also semantic constraints and rules for modifying information set		documents but also semantic constraints and rules for modifying the
	of the document.		information set 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.
	2.4. YANG Types		2.4. YANG Types
	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
	skipping to change at page 15, line 52		skipping to change at page 16, line 52
	| | base | |component||| |		| | base | |component||| |
	| +--------+ +---------+|| |		| +--------+ +---------+|| |
	| +---------+| |		| +---------+| |
	| +---------+ |		| +---------+ |
	+----------------------------+		+----------------------------+
	To use YANG, YANG modules must be defined to model the specific		To use YANG, YANG modules must be defined to model the specific
	problem domain. These modules are then loaded, compiled, or coded		problem domain. These modules are then loaded, compiled, or coded
	into the server.		into the server.
	The sequence of events for the typical client/server interaction is		The sequence of events for the typical client/server interaction may
	as follows:		be as follows:
	o A client application ([C]) opens a NETCONF session to the server		o A client application ([C]) opens a NETCONF session to the server
	(device) ([S])		(device) ([S])
	o [C] and [S] exchange <hello> messages containing the list of		o [C] and [S] exchange <hello> messages containing the list of
	capabilities supported by each side, allowing [C] to learn the		capabilities supported by each side, allowing [C] to learn the
	modules supported by [S]		modules supported by [S]
	o [C] builds and sends an operation defined in the YANG module,		o [C] builds and sends an operation defined in the YANG module,
	encoded in XML, within NETCONF's <rpc> element		encoded in XML, within NETCONF's <rpc> element
	o [S] receives and parses the <rpc> element		o [S] receives and parses the <rpc> element
	o [S] verifies the contents of the request against the data model		o [S] verifies the contents of the request against the data model
	defined in the YANG module		defined in the YANG module
	o [S] performs the requested operation, possibly changing the		o [S] performs the requested operation, possibly changing the
	configuration database		configuration datastore
	o [S] builds the response, containing the response, any requested		o [S] builds the response, containing the response, any requested
	data, and any errors		data, and any errors
	o [S] sends the response, encoded in XML, within NETCONF's		o [S] sends the response, encoded in XML, within NETCONF's
	<rpc-reply> element		<rpc-reply> element
	o [C] receives and parses the <rpc-reply> element		o [C] receives and parses the <rpc-reply> element
	o [C] inspects the response and processes it as needed		o [C] inspects the response and processes it as needed
	skipping to change at page 16, line 44		skipping to change at page 17, line 44
	Note that there is no requirement for the client or server to process		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		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		of the data model, rather than handle the content via a generic
	engine. Or the client may be targeted at the specific YANG model,		engine. Or the client may be targeted at the specific YANG model,
	rather than being driven generically. Such a client might be a		rather than being driven generically. Such a client might be a
	simple shell script that stuffs arguments into an XML payload		simple shell script that stuffs arguments into an XML payload
	template and sends it to the server.		template and sends it to the server.
	3.2. Addressing Operator Requirements		3.2. Addressing Operator Requirements
	YANG addresses many of the issues raised in the IAB NM workshop.		NETCONF and YANG address 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 state data: YANG clearly divides configuration		o Configuration and state data: YANG clearly divides configuration
	data from other types of data.		data from other types of data.
	o Transactions: NETCONF provides a simple transaction mechanism.		o Transactions: NETCONF provides a simple transaction mechanism.
	o Generation of deltas: A YANG module gives enough information to		o Generation of deltas: A YANG module gives enough information to
	generate the delta needed to change between two configuration data		generate the delta needed to change between two configuration data
	sets.		sets.
	o Dump and restore: NETCONF gives the ability to save and restore		o Dump and restore: NETCONF gives the ability to save and restore
	configuration data. This can also performed for a specific YANG		configuration data. This can also performed for a specific YANG
	module.		module.
	o Network-wide configuration: NETCONF supports robust network-wide		o Network-wide configuration: NETCONF supports robust network-wide
	configuration transactions via the confirmed-commit capability.		configuration transactions via the commit and confirmed-commit
			capability. When a change is attempted that affects multiple
			devices, these capabilities simplifies the management of failure
			scenarios, resulting in the ability to have transactions that will
			dependably succeed or fail atomically.
	o Text-friendly: YANG modules are very text friendly, as is the data		o Text-friendly: YANG modules are very text friendly, as is the data
	they define.		they define.
	o Configuration handling: NETCONF addresses the ability to		o Configuration handling: NETCONF addresses the ability to
	distinguish between distributing configuration data and activating		distinguish between distributing configuration data and activating
	it.		it.
	o Task-oriented: A YANG module can define specific tasks as RPC		o Task-oriented: A YANG module can define specific tasks as RPC
	operations. A client can choose to invoke the RPC operation or to		operations. A client can choose to invoke the RPC operation or to
	skipping to change at page 18, line 20		skipping to change at page 19, line 22
	o Implementation costs: Significant effort has been made to keep		o Implementation costs: Significant effort has been made to keep
	implementation costs as low as possible.		implementation costs as low as possible.
	o Human friendly syntax: YANG's syntax is optimized for the reader,		o Human friendly syntax: YANG's syntax is optimized for the reader,
	specifically the reviewer on the basis that this is the most		specifically the reviewer on the basis that this is the most
	common human interaction.		common human interaction.
	o Post-processing: Use of XML will maximize the opportunities for		o Post-processing: Use of XML will maximize the opportunities for
	post-processing of data, possibly using XML-based technologies		post-processing of data, possibly using XML-based technologies
	like XPath, XQuery, and XSLT.		like XPath ([W3CXPATH], XQuery ([W3CXQUERY]), and XSLT
			([W3CXSLT]).
	o Semantic mismatch: Richer, more descriptive data models will		o Semantic mismatch: Richer, more descriptive data models will
	reduce the possibility of semantic mismatch. With the ability to		reduce the possibility of semantic mismatch. With the ability to
	define new primitives, YANG modules will be more specific in		define new primitives, YANG modules will be more specific in
	content, allowing more enforcement of rules and constraints.		content, allowing more enforcement of rules and constraints.
	o Security: NETCONF runs over transport protocols secured by SSH or		o Security: NETCONF runs over transport protocols secured by SSH or
	TLS, allowing secure communications and authentication using well-		TLS, allowing secure communications and authentication using well-
	trusted technology. The secure transport can use existing key and		trusted technology. The secure transport can use existing key and
	credential management infrastructure, reducing deployment costs.		credential management infrastructure, reducing deployment costs.
	skipping to change at page 23, line 28		skipping to change at page 24, line 28
	data tree with the default value as its value". This gives the		data tree with the default value as its value". This gives the
	device implementation choices in how default values are handled.		device implementation choices in how default values are handled.
	One choice is to view the configuration as a set of instructions for		One choice is to view the configuration as a set of instructions for
	how the device should be configured. If a data value that is given		how the device should be configured. If a data value that is given
	as part of those instructions is the default value, then it should be		as part of those instructions is the default value, then it should be
	retained as part of the configuration, but if it is not explicitly		retained as part of the configuration, but if it is not explicitly
	given, then the value is not considered to be part of configuration.		given, then the value is not considered to be part of configuration.
	Another choice is to trim values that are identical to the default		Another choice is to trim values that are identical to the default
	values, implicitly removing them from the configuration database.		values, implicitly removing them from the configuration datastore.
	The act of setting a leaf to it's default value effectively deletes		The act of setting a leaf to it's default value effectively deletes
	that leaf.		that leaf.
	The device could also choose to report all default values, regardless		The device could also choose to report all default values, regardless
	of whether they were explicitly set. This choice eases the work of a		of whether they were explicitly set. This choice eases the work of a
	client that needs default values, but may significantly increase the		client that needs default values, but may significantly increase the
	size of the configuration data.		size of the configuration data.
	These choices reflect the default handling schemes of widely deployed		These choices reflect the default handling schemes of widely deployed
	networking devices and supporting them allows YANG to reduce		networking devices and supporting them allows YANG to reduce
	skipping to change at page 29, line 5		skipping to change at page 29, line 20
	operation).		operation).
	4.3.3.3. Introduction of an Operational State Datastore		4.3.3.3. Introduction of an Operational State Datastore
	Another option could be to introduce a new "configuration" data store		Another option could be to introduce a new "configuration" data store
	that represents the operational state. A <get-config> operation on		that represents the operational state. A <get-config> operation on
	the <operational> data store would then return the operational state		the <operational> data store would then return the operational state
	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.
			4.4. Direction
			At this time, the only viable solution is to distinctly model the
			configuration and operational values. The configuration leaf would
			indicate the desired value, as given by the user, and the operational
			leaf would indicate the current value, as observed on the device.
			In the duplex example, this would result in two distinct leafs being
			defined, "duplex" and "op-duplex", one with "config true" and one
			with "config false".
			In some cases, distinct leafs would be used, but in others, distinct
			lists might be used. Distinct lists allows the list to be organized
			in different ways, with different constraints. Keys, sorting, and
			constraint statements like must, unique, or when may differ between
			configuration data and operational data.
			For example, configured static routes might be a distinct list from
			the operational routing table, since the use of keys and sorting
			might differ.
	5. Security Considerations		5. Security Considerations
	This document discusses an architecture for network management using		This document discusses an architecture for network management using
	NETCONF and YANG. It has no security impact on the Internet.		NETCONF and YANG. It has no security impact on the Internet.
	6. IANA Considerations		6. IANA Considerations
	This document has no actions for IANA.		This document has no actions for IANA.
	7. Normative References		7. Normative References
			[ISODSDL] International Organization for Standardization, "Document
			Schema Definition Languages (DSDL) - Part 1: Overview",
			ISO/IEC 19757-1, November 2004.
	[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.
	[RFC4742] Wasserman, M. and T. Goddard, "Using the NETCONF		[RFC4742] Wasserman, M. and T. Goddard, "Using the NETCONF
	Configuration Protocol over Secure SHell (SSH)", RFC 4742,		Configuration Protocol over Secure SHell (SSH)", RFC 4742,
	December 2006.		December 2006.
	skipping to change at page 31, line 32		skipping to change at page 32, line 36
	December 2006.		December 2006.
	[RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event		[RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event
	Notifications", RFC 5277, July 2008.		Notifications", RFC 5277, July 2008.
	[RFC5539] Badra, M., "NETCONF over Transport Layer Security (TLS)",		[RFC5539] Badra, M., "NETCONF over Transport Layer Security (TLS)",
	RFC 5539, May 2009.		RFC 5539, May 2009.
	[RFCWITHDEFAULTS]		[RFCWITHDEFAULTS]
	Bierman, A. and B. Lengyel, "With-defaults capability for		Bierman, A. and B. Lengyel, "With-defaults capability for
	NETCONF", draft-ietf-netconf-with-defaults-09.txt (work in		NETCONF", draft-ietf-netconf-with-defaults-11.txt (work in
	progress).		progress).
	[RFCYANG] Bjorklund, M., Ed., "YANG - A data modeling language for		[RFCYANG] Bjorklund, M., Ed., "YANG - A data modeling language for
	the Network Configuration Protocol (NETCONF)",		the Network Configuration Protocol (NETCONF)",
	draft-ietf-netmod-yang-13 (work in progress).		draft-ietf-netmod-yang-13 (work in progress).
	[RFCYANGDSDL]		[RFCYANGDSDL]
	Lhotka, L., Mahy, R., and S. Chishom, "Mapping YANG to		Lhotka, L., Mahy, R., and S. Chishom, "Mapping YANG to
	Document Schema Definition Languages and Validating		Document Schema Definition Languages and Validating
	NETCONF Content", draft-ietf-netmod-dsdl-map-05 (work in		NETCONF Content", draft-ietf-netmod-dsdl-map-06 (work in
	progress).		progress).
	[RFCYANGTYPES]		[RFCYANGTYPES]
	Schoenwaelder, J., "Common YANG Data Types",		Schoenwaelder, J., "Common YANG Data Types",
	draft-ietf-netmod-yang-types-09.txt (work in progress).		draft-ietf-netmod-yang-types-09.txt (work in progress).
	[RFCYANGUSAGE]		[RFCYANGUSAGE]
	Bierman, A., "Guidelines for Authors and Reviewers of YANG		Bierman, A., "Guidelines for Authors and Reviewers of YANG
	Data Model Documents", draft-ietf-netmod-yang-usage-05.txt		Data Model Documents", draft-ietf-netmod-yang-usage-10.txt
	(work in progress).		(work in progress).
			[W3CXPATH]
			DeRose, S. and J. Clark, "XML Path Language (XPath)
			Version 1.0", World Wide Web Consortium
			Recommendation REC-xpath-19991116, November 1999,
			<http://www.w3.org/TR/1999/REC-xpath-19991116>.
			[W3CXQUERY]
			Boag, S., "XQuery 1.0: An XML Query Language", W3C WD WD-
			xquery-20050915, September 2005.
			[W3CXSD] Walmsley, P. and D. Fallside, "XML Schema Part 0: Primer
			Second Edition", World Wide Web Consortium
			Recommendation REC-xmlschema-0-20041028, October 2004,
			<http://www.w3.org/TR/2004/REC-xmlschema-0-20041028>.
			[W3CXSLT] Clark, J., "XSL Transformations (XSLT) Version 1.0", World
			Wide Web Consortium Recommendation REC-xslt-19991116,
			November 1999,
			<http://www.w3.org/TR/1999/REC-xslt-19991116>.
	Author's Address		Author's Address
	Phil Shafer		Phil Shafer
	Juniper Networks		Juniper Networks
	Email: phil@juniper.net		Email: phil@juniper.net
End of changes. 24 change blocks.
	63 lines changed or deleted		120 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/