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/