draft-ietf-netmod-arch-09.txt   draft-ietf-netmod-arch-10.txt 
Network Working Group P. Shafer Network Working Group P. Shafer
Internet-Draft Juniper Networks Internet-Draft Juniper Networks
Intended status: Informational September 22, 2010 Intended status: Informational September 23, 2010
Expires: March 26, 2011 Expires: March 27, 2011
An Architecture for Network Management using NETCONF and YANG An Architecture for Network Management using NETCONF and YANG
draft-ietf-netmod-arch-09 draft-ietf-netmod-arch-10
Abstract Abstract
NETCONF gives access to native capabilities of the devices within a The Network Configuration Protocol (NETCONF) gives access to native
network, defining methods for manipulating configuration databases, capabilities of the devices within a network, defining methods for
retrieving operational data, and invoking specific operations. YANG manipulating configuration databases, retrieving operational data,
provides the means to define the content carried via NETCONF, both and invoking specific operations. YANG provides the means to define
data and operations. Using both technologies, standard modules can the content carried via NETCONF, both data and operations. Using
be defined to give interoperability and commonality to devices, while both technologies, standard modules can be defined to give
still allowing devices to express their unique capabilities. interoperability and commonality to devices, while still allowing
devices to express their unique capabilities.
This document describes how NETCONF and YANG help build network This document describes how NETCONF and YANG help build network
management applications that meet the needs of network operators. management applications that meet the needs of network operators.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 March 26, 2011. This Internet-Draft will expire on March 27, 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 17 skipping to change at page 3, line 17
1. Origins of NETCONF and YANG . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.2. YANG . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.1. Constraints . . . . . . . . . . . . . . . . . . . . . 11 2.2.1. Constraints . . . . . . . . . . . . . . . . . . . . . 11
2.2.2. Flexibility . . . . . . . . . . . . . . . . . . . . . 12 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 . . . . . . . . . . . . . . . . . . . . . . . . . 14 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 . . . . . . . . . . . . . . . . . . . . . . . . 15
2.5. IETF Guidelines . . . . . . . . . . . . . . . . . . . . . 15 2.5. IETF Guidelines . . . . . . . . . . . . . . . . . . . . . 15
3. Working with YANG . . . . . . . . . . . . . . . . . . . . . . 16 3. Working with YANG . . . . . . . . . . . . . . . . . . . . . . 16
3.1. Building NETCONF- and YANG-based Solutions . . . . . . . . 16 3.1. Building NETCONF- and YANG-based Solutions . . . . . . . . 16
3.2. Addressing Operator Requirements . . . . . . . . . . . . . 17 3.2. Addressing Operator Requirements . . . . . . . . . . . . . 17
3.3. Roles in Building Solutions . . . . . . . . . . . . . . . 19 3.3. Roles in Building Solutions . . . . . . . . . . . . . . . 20
3.3.1. Modeler . . . . . . . . . . . . . . . . . . . . . . . 20 3.3.1. Modeler . . . . . . . . . . . . . . . . . . . . . . . 20
3.3.2. Reviewer . . . . . . . . . . . . . . . . . . . . . . . 20 3.3.2. Reviewer . . . . . . . . . . . . . . . . . . . . . . . 20
3.3.3. Device Developer . . . . . . . . . . . . . . . . . . . 20 3.3.3. Device Developer . . . . . . . . . . . . . . . . . . . 20
3.3.4. Application Developer . . . . . . . . . . . . . . . . 21 3.3.4. Application Developer . . . . . . . . . . . . . . . . 21
4. Modeling Considerations . . . . . . . . . . . . . . . . . . . 24 4. Modeling Considerations . . . . . . . . . . . . . . . . . . . 24
4.1. Default Values . . . . . . . . . . . . . . . . . . . . . . 24 4.1. Default Values . . . . . . . . . . . . . . . . . . . . . . 24
4.2. Compliance . . . . . . . . . . . . . . . . . . . . . . . . 25 4.2. Compliance . . . . . . . . . . . . . . . . . . . . . . . . 25
4.3. Data Distinctions . . . . . . . . . . . . . . . . . . . . 26 4.3. Data Distinctions . . . . . . . . . . . . . . . . . . . . 26
4.3.1. Background . . . . . . . . . . . . . . . . . . . . . . 26 4.3.1. Background . . . . . . . . . . . . . . . . . . . . . . 26
4.3.2. Definitions . . . . . . . . . . . . . . . . . . . . . 27 4.3.2. Definitions . . . . . . . . . . . . . . . . . . . . . 27
skipping to change at page 4, line 44 skipping to change at page 4, line 44
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 ([RFC4741]) devices, which act as servers. The NETCONF specification ([RFC4741])
defines a small set of operations, but goes out of its way to avoid defines a small set of operations, but goes out of its way to avoid
making any requirements on the data carried in those operations, making any requirements on the data carried in those operations,
preferring to allow the protocol to carry any data. This "data model preferring to allow the protocol to carry any data. This "data model
agnostic" 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 ([W3CXSD]) and DSDL ([ISODSDL]) were languages such as the XML Schema Language (XSD) ([W3CXSD]) and the
Document Schema Definition Languages (DSDL) ([ISODSDL]) were
considered, but were rejected because the problem domains have little considered, but were rejected because the problem domains have little
natural overlap. Defining a data model or protocol that is encoded natural overlap. Defining a data model or protocol that is encoded
in XML is a distinct problem from defining an XML document. The use in XML is a distinct problem from defining an XML document. The use
of NETCONF operations place requirements on the data content that are of NETCONF operations place requirements on the data content that are
not shared with the static document problem domain addressed by not shared with the static document problem domain addressed by
schema languages like XSD or Relax NG. 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.ietf.org/mail-archive/web/ietf/current/msg51644.html
In 2008 and 2009, the NETMOD working group produced a specification In 2008 and 2009, the NETMOD working group produced a specification
for YANG ([RFCYANG]) as a means for defining data models for NETCONF, for YANG ([RFCYANG]) as a means for defining data models for NETCONF,
allowing both standard and proprietary data models to be published in allowing both standard and proprietary data models to be published in
a form that is easily digestible by human readers and satisfies many a form that is easily digestible by human readers and satisfies many
of the issues raised in the IAB NM workshop. This brings NETCONF to 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. a point where is can be used to develop standard data models 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 8, line 11 skipping to change at page 8, line 11
NETCONF defines 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 some of these operations: following table lists some of these operations:
+---------------+---------------------------------------------------+ +---------------+---------------------------------------------------+
| Operation | Description | | Operation | Description |
+---------------+---------------------------------------------------+ +---------------+---------------------------------------------------+
| commit | Commits the "candidate" configuration to | | commit | Commits the "candidate" configuration to |
| | "running" | | | "running" |
| copy-config | Copy one configuration datastore to another | | copy-config | Copy one configuration datastore to another |
| delete-config | Delete a portion of a configuration datastore | | delete-config | Delete a configuration datastore |
| edit-config | Change the contents of a configuration datastore | | edit-config | Change the contents of a configuration datastore |
| get-config | Retrieve all or part of a configuration datastore | | get-config | Retrieve all or part of a configuration datastore |
| lock | Prevent changes to a datastore from another party | | lock | Prevent changes to a datastore from another party |
| unlock | Release a lock on a datastore | | 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>
skipping to change at page 8, line 46 skipping to change at page 8, line 46
requirements defined in RFC4741, including requirements defined in RFC4741, including
o connection-oriented operation o connection-oriented operation
o authentication o authentication
o integrity o integrity
o confidentiality o confidentiality
[RFC4742] defines an mapping for the SSH protocol, which is the [RFC4742] defines an mapping for the SSH ([RFC4251]) protocol, which
mandatory transport protocol. Others include SOAP ([RFC4743]), BEEP is the mandatory transport protocol. Others include SOAP
([RFC4744]), and TLS ([RFC5539]). ([RFC4743]), BEEP ([RFC4744]), and TLS ([RFC5539]).
2.2. YANG 2.2. YANG
YANG is a data modeling language for NETCONF. It allows the YANG is a data modeling language for NETCONF. It allows the
description of hierarchies of data nodes ("nodes") and the description of hierarchies of data nodes ("nodes") and the
constraints that exist among them. YANG defines data models and how constraints that exist among them. YANG defines data models and how
to manipulate those models via NETCONF protocol operations. to manipulate those models via NETCONF protocol operations.
Each YANG module defines a data model, uniquely identified by a Each YANG module defines a data model, uniquely identified by a
namespace URI. These data models are extensible in a manner that namespace URI. These data models are extensible in a manner that
skipping to change at page 12, line 4 skipping to change at page 12, line 4
| mandatory | Requires the node appear | | mandatory | Requires the node appear |
| max-elements | Limits the number of instances in a list | | max-elements | Limits the number of instances in a list |
| min-elements | Limits the number of instances in a list | | min-elements | Limits the number of instances in a list |
| must | XPath expression must be true | | must | XPath expression must be true |
| pattern | Regular expression must be satisfied | | pattern | Regular expression must be satisfied |
| range | Value must appear in range | | range | Value must appear in range |
| reference | Value must appear elsewhere in the data | | reference | Value must appear elsewhere in the data |
| unique | Value must be unique within the data | | unique | Value must be unique within the data |
| when | Node is only present when XPath expression is true | | when | Node is only present when XPath expression is true |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
The "must" and "when" statements use XPath expressions to specify The "must" and "when" statements use XPath ([W3CXPATH]) expressions
conditions that are semantically evaluated against the data to specify conditions that are semantically evaluated against the
hierarchy, but neither the client nor the server are required to data hierarchy, but neither the client nor the server are required to
implement the XPath specification. Instead they can use any means to implement the XPath specification. Instead they can use any means to
ensure these conditions are met. ensure these conditions are met.
2.2.2. Flexibility 2.2.2. Flexibility
YANG uses the "union" type and the "choice" and "feature" statements YANG uses the "union" type and the "choice" and "feature" statements
to give modelers flexibility in defining their data models. The to give modelers flexibility in defining their data models. The
"union" type allows a single leaf to accept multiple types, like an "union" type allows a single leaf to accept multiple types, like an
integer or the word "unbounded": integer or the word "unbounded":
skipping to change at page 13, line 28 skipping to change at page 13, line 28
type empty; type empty;
description "Don't inform other protocols about" description "Don't inform other protocols about"
+ " neighbor down events"; + " neighbor down events";
} }
} }
} }
The <no-neighbor-down-notification> element is then placed in the The <no-neighbor-down-notification> element is then placed in the
vendorx namespace: vendorx namespace:
<ospf xmlns="http://example.org/netconf/ospf"> <ospf xmlns="http://example.org/netconf/ospf"
xmlns:vendorx=""http://vendorx.example.com/ospf">
<area> <area>
<name>0.0.0.0</name> <name>0.0.0.0</name>
<interface> <interface>
<name>ge-0/0/0.0</name> <name>ge-0/0/0.0</name>
<priority>30</priority> <priority>30</priority>
<vendorx:no-neighbor-down-notification/> <vendorx:no-neighbor-down-notification/>
</interface> </interface>
skipping to change at page 14, line 30 skipping to change at page 14, line 32
acceptable option. For those scenarios, an XML grammar for YANG is acceptable option. For those scenarios, an XML grammar for YANG is
defined as YIN (YANG Independent Notation). YIN allows the use of defined as YIN (YANG Independent Notation). YIN allows the use of
XML parsers which are readily available in both open source and XML parsers which are readily available in both open source and
commercial versions. Conversion between YANG and YIN is direct, commercial versions. Conversion between YANG and YIN is direct,
loss-less and reversible. YANG statements are converted to XML loss-less and reversible. YANG statements are converted to XML
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 ([RFCYANGDSDL]). Description Languages ([RFCYANGDSDL]), of which RELAX NG is a major
component.
DSDL is considered to be the best choice as a standard schema DSDL is considered to be the best choice as a standard schema
language because it addresses not only grammar and datatypes of XML language because it addresses not only grammar and datatypes of XML
documents but also semantic constraints and rules for modifying the documents but also semantic constraints and rules for modifying the
information set 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.
skipping to change at page 18, line 39 skipping to change at page 18, line 39
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
access any underlying data directly. access any underlying data directly.
o Full coverage: YANG modules can be defined that give full coverage o Full coverage: YANG modules can be defined that give full coverage
to all the native abilities of the device. Giving this access to all the native abilities of the device. Giving this access
avoids the need to resort to the command line interface (CLI) avoids the need to resort to the command line interface (CLI)
using tools such as Expect. using tools such as Expect ([SWEXPECT]).
o Timeliness: YANG modules can be tied to CLI operations, so all o Timeliness: YANG modules can be tied to CLI operations, so all
native operations and data are immediately available. native operations and data are immediately available.
o Implementation difficulty: YANG's flexibility enables modules that o Implementation difficulty: YANG's flexibility enables modules that
can be more easily implemented. Adding "features" and replacing can be more easily implemented. Adding "features" and replacing
"third normal form" with a natural data hierarchy should reduce "third normal form" with a natural data hierarchy should reduce
complexity. complexity.
o Simple data modeling language: YANG has sufficient power to be o Simple data modeling language: YANG has sufficient power to be
usable in other situations. In particular, on-box API and native usable in other situations. In particular, on-box API and native
CLI can be integrated to achieve simplification of the CLI can be integrated to achieve simplification of the
infrastructure. infrastructure.
o Internationalization: YANG uses UTF-8 encoded unicode characters. o Internationalization: YANG uses UTF-8 ([RFC3629]) encoded unicode
characters.
o Event correlation: YANG integrates RPC operations, notification, o Event correlation: YANG integrates RPC operations, notification,
configuration and state data, enabling internal references. For configuration and state data, enabling internal references. For
example, a field in a notification can be tagged as pointing to a example, a field in a notification can be tagged as pointing to a
BGP peer, and the client application can easily find that peer in BGP peer, and the client application can easily find that peer in
the configuration data. the configuration data.
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.
skipping to change at page 21, line 5 skipping to change at page 21, line 8
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.3.3.2. XML "over the wire" Definitions 3.3.3.2. XML Definitions
The YANG module dictates the XML encoding sent "over the wire", The YANG module dictates the XML encoding for data sent via NETCONF.
though actual transmission should be encrypted so as not to appear as The rules that define the encoding are fixed, so the YANG module can
readable text on the physical media. The rules that define the be used to ascertain whether a specific NETCONF payload is obeying
encoding are fixed, so the YANG module can be used to ascertain the rules.
whether a specific NETCONF payload is obeying the rules.
3.3.4. Application Developer 3.3.4. 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.3.4.1. Hard Coded 3.3.4.1. Hard Coded
skipping to change at page 24, line 29 skipping to change at page 24, line 29
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 datastore. 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 its 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
implementation and deployment costs of YANG-based models. implementation and deployment costs of YANG-based models.
skipping to change at page 32, line 14 skipping to change at page 32, line 14
7. Normative References 7. Normative References
[ISODSDL] International Organization for Standardization, "Document [ISODSDL] International Organization for Standardization, "Document
Schema Definition Languages (DSDL) - Part 1: Overview", Schema Definition Languages (DSDL) - Part 1: Overview",
ISO/IEC 19757-1, November 2004. 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.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
Protocol Architecture", RFC 4251, January 2006.
[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.
[RFC4743] Goddard, T., "Using NETCONF over the Simple Object Access [RFC4743] Goddard, T., "Using NETCONF over the Simple Object Access
Protocol (SOAP)", RFC 4743, December 2006. Protocol (SOAP)", RFC 4743, December 2006.
skipping to change at page 32, line 46 skipping to change at page 32, line 52
NETCONF", draft-ietf-netconf-with-defaults-11.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-06 (work in NETCONF Content", draft-ietf-netmod-dsdl-map-07 (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-10.txt Data Model Documents", draft-ietf-netmod-yang-usage-10.txt
(work in progress). (work in progress).
[SWEXPECT]
"The Expect Home Page", <http://expect.sourceforge.net/>.
[W3CXPATH] [W3CXPATH]
DeRose, S. and J. Clark, "XML Path Language (XPath) DeRose, S. and J. Clark, "XML Path Language (XPath)
Version 1.0", World Wide Web Consortium Version 1.0", World Wide Web Consortium
Recommendation REC-xpath-19991116, November 1999, Recommendation REC-xpath-19991116, November 1999,
<http://www.w3.org/TR/1999/REC-xpath-19991116>. <http://www.w3.org/TR/1999/REC-xpath-19991116>.
[W3CXQUERY] [W3CXQUERY]
Boag, S., "XQuery 1.0: An XML Query Language", W3C WD WD- Boag, S., "XQuery 1.0: An XML Query Language", W3C WD WD-
xquery-20050915, September 2005. xquery-20050915, September 2005.
 End of changes. 24 change blocks. 
38 lines changed or deleted 52 lines changed or added

This html diff was produced by rfcdiff 1.39. The latest version is available from http://tools.ietf.org/tools/rfcdiff/