One document matched: draft-ietf-netmod-arch-09.xml
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd'>
<?rfc toc="yes"?>
<?rfc compact="no"?>
<?rfc subcompact="no"?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no"?>
<?rfc strict="yes"?>
<rfc ipr="pre5378Trust200902" category="info" docName="draft-ietf-netmod-arch-09">
<front>
<title abbrev="NETMODARCH">An Architecture for Network Management using NETCONF and YANG</title>
<author initials="P" surname="Shafer" fullname='Phil Shafer' >
<organization>Juniper Networks</organization>
<address>
<email>phil@juniper.net</email>
</address>
</author>
<date/>
<abstract>
<t>
NETCONF gives access to native capabilities of the
devices within a network, defining methods for manipulating
configuration databases, retrieving operational data, and invoking
specific operations. YANG provides the means to define the content
carried via NETCONF, both data and operations. Using both
technologies, standard modules can be defined to give interoperability
and commonality to devices, while still allowing devices to express
their unique capabilities.
</t>
<t>
This document describes how NETCONF and YANG help build network
management applications that meet the needs of network operators.
</t>
</abstract>
</front>
<middle>
<section title="Origins of NETCONF and YANG">
<t>
Networks are increasing in complexity and capacity, as well as the
density of the services deployed upon them. Uptime, reliability, and
predictable latency requirements drive the need for automation. The
problems with network management are not simple. They are complex and
intricate. But these problems must be solved for networks to meet the
stability needs of existing services while incorporating new services
in a world where the growth of networks is exhausting the supply
of qualified networking engineers.
</t>
<t>
In June of 2002, Internet Architecture Board (IAB) held a workshop on
Network Management (<xref target="RFC3535"/>). The members of this workshop made a
number of observations and recommendations for the IETF's
consideration concerning the issues operators were facing in their
network management-related work as well as issues they were having
with the direction of the IETF activities in this area.
</t>
<t>
The output of this workshop was focused on current problems. The
observations were reasonable and straight forward, including the
need for transactions, rollback, low implementation costs, and the
ability to save and restore the device's configuration data. Many of
the observations give insight into the problems operators were
having with existing network management solutions, such as the lack of
full coverage of device capabilities and the ability to distinguish
between configuration data and other types of data.
</t>
<t>
Based on these directions, the NETCONF working group was formed and
the Network Configuration (NETCONF) protocol was created. This
protocol defines a simple mechanism where network management
applications, acting as clients, can invoke operations on the devices,
which act as servers. The NETCONF specification (<xref target="RFC4741"/>) defines a
small set of operations, but goes out of its way to avoid making any
requirements on the data carried in those operations, preferring to
allow the protocol to carry any data. This "data model agnostic"
approach allows data models to be defined independently.
</t>
<t>
But lacking a means of defining data models, the NETCONF protocol was
not usable for standards-based work. Existing data modeling languages
such as XSD (<xref target="W3CXSD"/>) and DSDL (<xref target="ISODSDL"/>) were considered, but were
rejected because the problem domains have little natural overlap.
Defining a data model or protocol that is encoded 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.
</t>
<t>
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
design team was tasked with creating a requirements document (expired
I-D draft-presuhn-rcdml-03.txt). After discussing the available
options at the CANMOD BoF at IETF71, the community wrote a charter for
the NETMOD working group. An excellent description of this time
period is available at
http://www.mail-archive.com/ietf@ietf.org/msg37006.html
</t>
<t>
In 2008 and 2009, the NETMOD working group produced a specification
for YANG (<xref target="RFCYANG"/>) as a means for defining data models for NETCONF,
allowing both standard and proprietary data models to be published in
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 a
point where is can be used to develop standards within the IETF.
</t>
<t>
YANG allows a modeler to create a data model, to define the
organization of the data in that model, and to define constraints on
that data. Once published, the YANG module acts as a contract between
the client and server, with both parties understanding how 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 server. A
server knows the rules that govern the data and how it should behave.
</t>
<t>
YANG also incorporates a level of extensibility and flexibility
not present in other model languages. New modules can augment the
data hierarchies defined in other modules, seamlessly adding data at
appropriate places in the existing data organization. YANG also
allows new statements to be defined, allowing the language itself to
be expanded in a consistent way.
</t>
<t>
This document presents an architecture for YANG, describing how
YANG-related technologies work and how solutions built on them can
address the network management problem domain.
</t>
</section>
<section title="Elements of the Architecture">
<section title="NETCONF">
<t>
NETCONF defines an XML-based remote procedure call (RPC) mechanism
that leverages the simplicity and availability of high-quality XML
parsers. XML gives a rich, flexible, hierarchical, standard
representation of data that matches the needs of networking devices.
NETCONF carries configuration data and operations as requests and
replies using RPCs encoded in XML over a connection-oriented
transport.
</t>
<t>
XML's hierarchical data representation allows complex networking data
to be rendered in a natural way. For example, the following
configuration places interfaces in OSPF areas. The <ospf> element
contains a list of <area> elements, each of which contain a list of
<interface> elements. The <name> element identifies the specific area
or interface. Additional configuration for each area or interface
appears directly inside the appropriate element.
</t>
<figure>
<artwork><![CDATA[
<ospf xmlns="http://example.org/netconf/ospf">
<area>
<name>0.0.0.0</name>
<interface>
<name>ge-0/0/0.0</name>
<!-- The priority for this interface -->
<priority>30</priority>
<metric>100</metric>
<dead-interval>120</dead-interval>
</interface>
<interface>
<name>ge-0/0/1.0</name>
<metric>140</metric>
</interface>
</area>
<area>
<name>10.1.2.0</name>
<interface>
<name>ge-0/0/2.0</name>
<metric>100</metric>
</interface>
<interface>
<name>ge-0/0/3.0</name>
<metric>140</metric>
<dead-interval>120</dead-interval>
</interface>
</area>
</ospf>
]]></artwork>
</figure>
<t>
NETCONF includes mechanisms for controlling configuration datastores.
Each datastore is a specific collection of configuration data that can
be used as source or target of the configuration-related operations.
The device can indicate whether it has a distinct "startup"
configuration datastore, whether the current or "running" datastore is
directly writable, or whether there is a "candidate" configuration
datastore where configuration changes can be made that will not affect
the device until a "commit‑configuration" operation is invoked.
</t>
<t>
NETCONF defines operations that are invoked as RPCs from the client
(the application) to the server (running on the device). The
following table lists some of these operations:
</t>
<?rfc compact="yes"?>
<texttable>
<ttcol align='left'>Operation</ttcol>
<ttcol align='left'>Description</ttcol>
<c>commit</c>
<c>Commits the "candidate" configuration to "running"</c>
<c>copy-config</c>
<c>Copy one configuration datastore to another</c>
<c>delete-config</c>
<c>Delete a portion of a configuration datastore</c>
<c>edit-config</c>
<c>Change the contents of a configuration datastore</c>
<c>get-config</c>
<c>Retrieve all or part of a configuration datastore</c>
<c>lock</c>
<c>Prevent changes to a datastore from another party</c>
<c>unlock</c>
<c>Release a lock on a datastore</c>
</texttable>
<?rfc compact="no"?>
<t>
NETCONF's "capability" mechanism allows the device to announce the set
of capabilities that the device supports, including protocol
operations, datastores, data models, and other abilities. These are
announced during session establishment as part of the <hello> message.
A client can inspect the hello message to determine what the device is
capable of and how to interact with the device to perform the desired
tasks.
</t>
<t>
NETCONF also defines a means of sending asynchronous notifications
from the server to the client, described in <xref target="RFC5277"/>.
</t>
<t>
In addition, NETCONF can fetch state data, receive notifications, and
invoke additional RPC methods defined as part of a capability. Complete
information about NETCONF can be found in <xref target="RFC4741"/>.
</t>
<section title="NETCONF Transport Mappings">
<t>
NETCONF can run over any transport protocol that meets the
requirements defined in RFC4741, including
</t>
<t>
<list style="symbols">
<t>
connection-oriented operation
</t>
<t>
authentication
</t>
<t>
integrity
</t>
<t>
confidentiality
</t>
</list>
</t>
<t>
<xref target="RFC4742"/> defines an mapping for the SSH protocol, which is the
mandatory transport protocol. Others include SOAP (<xref target="RFC4743"/>),
BEEP (<xref target="RFC4744"/>), and TLS (<xref target="RFC5539"/>).
</t>
</section>
</section>
<section title="YANG">
<t>
YANG is a data modeling language for NETCONF. It allows the
description of hierarchies of data nodes ("nodes") and the
constraints that exist among them. YANG defines data models and how
to manipulate those models via NETCONF protocol operations.
</t>
<t>
Each YANG module defines a data model, uniquely identified by a
namespace URI. These data models are extensible in a manner that
allows tight integration of standard data models and proprietary data
models. Models are built from organizational containers, lists of
data nodes and data node forming leafs of the data tree.
</t>
<figure>
<artwork><![CDATA[
module example-ospf {
namespace "http://example.org/netconf/ospf";
prefix ospf;
import network-types { // Access another module's def'ns
prefix nett;
}
container ospf { // Declare the top-level tag
list area { // Declare a list of "area" nodes
key name; // The key "name" identifies list members
leaf name {
type nett:area-id;
}
list interface {
key name;
leaf name {
type nett:interface-name;
}
leaf priority {
description "Designated router priority";
type uint8; // The type is a constraint on
// valid values for "priority".
}
leaf metric {
type uint16 {
range 1..65535;
}
}
leaf dead-interval {
units seconds;
type uint16 {
range 1..65535;
}
}
}
}
}
}
]]></artwork>
</figure>
<t>
A YANG module defines a data model in terms of the data, its
hierarchical organization, and the constraints on that data. YANG
defines how this data is represented in XML and how that data is used
in NETCONF operations.
</t>
<t>
The following table briefly describes some common YANG statements:
</t>
<?rfc compact="yes"?>
<texttable>
<ttcol align='left'>Statement</ttcol>
<ttcol align='left'>Description</ttcol>
<c>augment</c>
<c>Extends existing data hierarchies</c>
<c>choice</c>
<c>Defines mutually exclusive alternatives</c>
<c>container</c>
<c>Defines a layer of the data hierarchy</c>
<c>extension</c>
<c>Allows new statements to be added to YANG</c>
<c>feature</c>
<c>Indicates parts of the model are optional</c>
<c>grouping</c>
<c>Groups data definitions into reusable sets</c>
<c>key</c>
<c>Defines the key leafs for lists</c>
<c>leaf</c>
<c>Defines a leaf node in the data hierarchy</c>
<c>leaf-list</c>
<c>A leaf node that can appear multiple times</c>
<c>list</c>
<c>A hierarchy that can appear multiple times</c>
<c>notification</c>
<c>Defines notification</c>
<c>rpc</c>
<c>Defines input and output parameters for an RPC operation</c>
<c>typedef</c>
<c>Defines a new type</c>
<c>uses</c>
<c>Incorporates the contents of a "grouping"</c>
</texttable>
<?rfc compact="no"?>
<section title="Constraints">
<t>
YANG allows the modeler to add constraints to the data model to
prevent impossible or illogical data. These constraints give clients
information about the data being sent from the device, and also allow
the client to know as much as possible about the data the device will
accept, so the client can send correct data. These constraints apply
to configuration data, but can also be used for rpc and notification
data.
</t>
<t>
The principal constraint is the "type" statement, which limits the
contents of a leaf node to that of the named type. The following
table briefly describes some other common YANG constraints:
</t>
<?rfc compact="yes"?>
<texttable>
<ttcol align='left'>Statement</ttcol>
<ttcol align='left'>Description</ttcol>
<c>length</c>
<c>Limits the length of a string</c>
<c>mandatory</c>
<c>Requires the node appear</c>
<c>max-elements</c>
<c>Limits the number of instances in a list</c>
<c>min-elements</c>
<c>Limits the number of instances in a list</c>
<c>must</c>
<c>XPath expression must be true</c>
<c>pattern</c>
<c>Regular expression must be satisfied</c>
<c>range</c>
<c>Value must appear in range</c>
<c>reference</c>
<c>Value must appear elsewhere in the data</c>
<c>unique</c>
<c>Value must be unique within the data</c>
<c>when</c>
<c>Node is only present when XPath expression is true</c>
</texttable>
<?rfc compact="no"?>
<t>
The "must" and "when" statements use XPath expressions to specify
conditions that are semantically evaluated against the data hierarchy,
but neither the client nor the server are required to implement the
XPath specification. Instead they can use any means to ensure these
conditions are met.
</t>
</section>
<section title="Flexibility">
<t>
YANG uses the "union" type and the "choice" and "feature" statements
to give modelers flexibility in defining their data models. The
"union" type allows a single leaf to accept multiple types, like an
integer or the word "unbounded":
</t>
<figure>
<artwork><![CDATA[
type union {
type int32;
type enumeration {
enum "unbounded";
}
}
]]></artwork>
</figure>
<t>
The "choice" statement lists a set of mutually exclusive nodes, so a
valid configuration can choose any one node (or case). The "feature"
statement allows the modeler to identify parts of the model which can
be optional, and allows the device to indicate whether it implements
these optional portions.
</t>
<t>
The "deviation" statement allows the device, to indicate parts of a
YANG module which the device does not faithfully implement. While
devices are encouraged to fully abide according to the contract
presented in the YANG module, real world situations may force the
device to break the contract. Deviations give a means of declaring
this limitation, rather than leaving it to be discovered via run-time
errors.
</t>
</section>
<section title="Extensibility Model">
<t>
XML includes the concept of namespaces, allowing XML elements from
different sources to be combined in the same hierarchy without
risking collision. YANG modules define content for specific
namespaces, but one module may augment the definition of another module,
introducing elements from that module's namespace into the first
module's hierarchy.
</t>
<t>
Since one module can augment another module's definition, hierarchies
of definitions are allowed to grow, as definitions from multiple
sources are added to the base hierarchy. These augmentations are
qualified using the namespace of the source module, helping to avoid
issues with name conflicts as the modules change over time.
</t>
<t>
For example, if the above OSPF configuration were the standard, a
vendor module may augment this with vendor-specific extensions.
</t>
<figure>
<artwork><![CDATA[
module vendorx-ospf {
namespace "http://vendorx.example.com/ospf";
prefix vendorx;
import example-ospf {
prefix ospf;
}
augment /ospf:ospf/ospf:area/ospf:interfaces {
leaf no-neighbor-down-notification {
type empty;
description "Don't inform other protocols about"
+ " neighbor down events";
}
}
}
]]></artwork>
</figure>
<t>
The <no‑neighbor‑down‑notification> element is then placed in the
vendorx namespace:
</t>
<figure>
<artwork><![CDATA[
<ospf xmlns="http://example.org/netconf/ospf">
<area>
<name>0.0.0.0</name>
<interface>
<name>ge-0/0/0.0</name>
<priority>30</priority>
<vendorx:no-neighbor-down-notification/>
</interface>
</area>
</ospf>
]]></artwork>
</figure>
<t>
Augmentations are seamlessly integrated with base modules, allowing
them to be fetched, archived, loaded, and deleted within their natural
hierarchy. If a client application asks for the configuration for a
specific OSPF area, it will receive the sub-hierarchy for
that area, complete with any augmented data.
</t>
</section>
</section>
<section title="YANG Translations">
<t>
The YANG data modeling language is the central piece of a group of
related technologies. The YANG language itself, described in <xref target="RFCYANG"/>,
defines the syntax of the language and its statements, the meaning of
those statements, and how to combine them to build the hierarchy of
nodes that describe a data model.
</t>
<t>
That document also defines the "on the wire" XML content for NETCONF
operations on data models defined in YANG modules. This includes the
basic mapping between YANG data tree nodes and XML elements, as well
as mechanisms used in <edit‑config> content to manipulate that data,
such as arranging the order of nodes within a list.
</t>
<t>
YANG uses a syntax that is regular and easily described, primarily
designed for human readability. YANG's syntax is friendly to email,
diff, patch, and the constraints of RFC formatting.
</t>
<section title="YIN">
<t>
In some environments, incorporating a YANG parser may not be an
acceptable option. For those scenarios, an XML grammar for YANG is
defined as YIN (YANG Independent Notation). YIN allows the use
of XML parsers which are readily available in both open source and
commercial versions. Conversion between YANG and YIN is direct,
loss-less and reversible. YANG statements are converted to XML
elements, preserving the structure and content of YANG, but enabling
the use of off-the-shelf XML parsers rather than requiring the
integration of a YANG parser. YIN maintains complete semantic
equivalence with YANG.
</t>
</section>
<section title="DSDL (Relax NG)">
<t>
Since NETCONF content is encoded in XML, it is natural to use XML
schema languages for their validation. To facilitate this, YANG
offers a standardized mapping of YANG modules into Document Schema
Description Languages (<xref target="RFCYANGDSDL"/>).
</t>
<t>
DSDL is considered to be the best choice as a standard schema language
because it addresses not only grammar and datatypes of XML
documents but also semantic constraints and rules for modifying
the information set of the document.
</t>
<t>
In addition, DSDL offers formal means for coordinating multiple
independent schemas and specifying how to apply the schemas to the
various parts of the document. This is useful since YANG content
is typically composed of multiple vocabularies.
</t>
</section>
</section>
<section title="YANG Types">
<t>
YANG supports a number of builtin types, and allows additional types
to be derived from those types in an extensible manner. New types can
add additional restrictions to allowable data values.
</t>
<t>
A standard type library for use by YANG is available <xref target="RFCYANGTYPES"/>.
These YANG modules define commonly used data types for IETF-related
standards.
</t>
</section>
<section title="IETF Guidelines">
<t>
A set of additional guidelines are defined that indicate desirable
usage for authors and reviewers of standards track specifications
containing YANG data model modules (<xref target="RFCYANGUSAGE"/>). These
guidelines should be used as a basis for reviews of other YANG data
model documents.
</t>
</section>
</section>
<section title="Working with YANG">
<section title="Building NETCONF- and YANG-based Solutions">
<t>
In the typical YANG-based solution, the client and server are driven
by the content of YANG modules. The server includes the definitions
of the modules as meta-data that is available to the NETCONF engine.
This engine processes incoming requests, uses the meta-data to parse
and verify the request, performs the requested operation, and returns
the results to the client.
</t>
<figure>
<artwork><![CDATA[
+----------------------------+
|Server (device) |
| +--------------------+ |
| | configuration | |
+----+ | | ---------------| |
|YANG|+ | | m d state data | |
|mods||+ | | e a ---------------| |
+----+|| -----> | t t notifications | |
+----+| | | a a ---------------| |
+----+ | | operations | |
| +--------------------+ |
| ^ |
| | |
| v |
+------+ | +-------------+ |
| | -------------> | | |
|Client| <rpc> | | NETCONF | |
| (app)| | | engine | |
| | <------------ | | |
+------+ <rpc-reply> +-------------+ |
| / \ |
| / \ |
| / \ |
| +--------+ +---------+ |
| | config | |system |+ |
| | data- | |software ||+ |
| | base | |component||| |
| +--------+ +---------+|| |
| +---------+| |
| +---------+ |
+----------------------------+
]]></artwork>
</figure>
<t>
To use YANG, YANG modules must be defined to model the specific
problem domain. These modules are then loaded, compiled, or coded
into the server.
</t>
<t>
The sequence of events for the typical client/server interaction may
be as follows:
</t>
<t>
<list style="symbols">
<t>
A client application ([C]) opens a NETCONF session to the server
(device) ([S])
</t>
<t>
[C] and [S] exchange <hello> messages containing the list of
capabilities supported by each side, allowing [C] to learn the modules
supported by [S]
</t>
<t>
[C] builds and sends an operation defined in the YANG module,
encoded in XML, within NETCONF's <rpc> element
</t>
<t>
[S] receives and parses the <rpc> element
</t>
<t>
[S] verifies the contents of the request against the data model
defined in the YANG module
</t>
<t>
[S] performs the requested operation, possibly changing the
configuration datastore
</t>
<t>
[S] builds the response, containing the response, any requested
data, and any errors
</t>
<t>
[S] sends the response, encoded in XML, within NETCONF's <rpc‑reply>
element
</t>
<t>
[C] receives and parses the <rpc‑reply> element
</t>
<t>
[C] inspects the response and processes it as needed
</t>
</list>
</t>
<t>
Note that there is no requirement for the client or server to process
the YANG modules in this way. The server may hard code the contents
of the data model, rather than handle the content via a generic
engine. Or the client may be targeted at the specific YANG model,
rather than being driven generically. Such a client might be a simple
shell script that stuffs arguments into an XML payload template and
sends it to the server.
</t>
</section>
<section title="Addressing Operator Requirements">
<t>
NETCONF and YANG address many of the issues raised in the IAB NM
workshop.
</t>
<t>
<list style="symbols">
<t>
Ease of use: YANG is designed to be human friendly, simple and
readable. Many tricky issues remain due to the complexity of the
problem domain, but YANG strives to make them more visible and easier
to deal with.
</t>
<t>
Configuration and state data: YANG clearly divides
configuration data from other types of data.
</t>
<t>
Transactions: NETCONF provides a simple transaction mechanism.
</t>
<t>
Generation of deltas: A YANG module gives enough information to
generate the delta needed to change between two configuration data
sets.
</t>
<t>
Dump and restore: NETCONF gives the ability to save and restore
configuration data. This can also performed for a specific YANG
module.
</t>
<t>
Network-wide configuration: NETCONF supports robust network-wide
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.
</t>
<t>
Text-friendly: YANG modules are very text friendly, as is the data
they define.
</t>
<t>
Configuration handling: NETCONF addresses the ability to distinguish
between distributing configuration data and activating it.
</t>
<t>
Task-oriented: A YANG module can define specific tasks as RPC
operations. A client can choose to invoke the RPC operation or to
access any underlying data directly.
</t>
<t>
Full coverage: YANG modules can be defined that give full coverage
to all the native abilities of the device. Giving this access
avoids the need to resort to the command line interface (CLI)
using tools such as Expect.
</t>
<t>
Timeliness: YANG modules can be tied to CLI operations, so all
native operations and data are immediately available.
</t>
<t>
Implementation difficulty: YANG's flexibility enables modules that
can be more easily implemented. Adding "features" and replacing
"third normal form" with a natural data hierarchy should reduce
complexity.
</t>
<t>
Simple data modeling language: YANG has sufficient power to be
usable in other situations. In particular, on-box API and native CLI
can be integrated to achieve simplification of the infrastructure.
</t>
<t>
Internationalization: YANG uses UTF-8 encoded unicode characters.
</t>
<t>
Event correlation: YANG integrates RPC operations, notification,
configuration and state data, enabling internal
references. For 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 the configuration data.
</t>
<t>
Implementation costs: Significant effort has been made to keep
implementation costs as low as possible.
</t>
<t>
Human friendly syntax: YANG's syntax is optimized for the reader,
specifically the reviewer on the basis that this is the most common
human interaction.
</t>
<t>
Post-processing: Use of XML will maximize the opportunities for
post-processing of data, possibly using XML-based technologies like
XPath (<xref target="W3CXPATH"/>, XQuery (<xref target="W3CXQUERY"/>), and XSLT (<xref target="W3CXSLT"/>).
</t>
<t>
Semantic mismatch: Richer, more descriptive data models will reduce
the possibility of semantic mismatch. With the ability to define new
primitives, YANG modules will be more specific in content, allowing
more enforcement of rules and constraints.
</t>
<t>
Security: NETCONF runs over transport protocols secured by SSH or
TLS, allowing secure communications and authentication using
well-trusted technology. The secure transport can use existing key
and credential management infrastructure, reducing deployment costs.
</t>
<t>
Reliable: NETCONF and YANG are solid and reliable technologies.
NETCONF is connection based, and includes automatic recovery
mechanisms when the connection is lost.
</t>
<t>
Delta friendly: YANG-based models support operations that are delta
friendly. Add, change, insert, and delete operations are all well
defined.
</t>
<t>
Method-oriented: YANG allows new RPC operations to be defined,
including an operation name, which is essentially a method. The input
and output parameters of the RPC operations are also defined in the
YANG module.
</t>
</list>
</t>
</section>
<section title="Roles in Building Solutions">
<t>
Building NETCONF- and YANG-based solutions requires interacting with
many distinct groups. Modelers must understand how to build useful
models that give structure and meaning to data while maximizing the
flexibility of that data to "future proof" their work. Reviewers need
to quickly determine if that structure is accurate. Device developers
need to code that data model into their devices, and application
developers need to code their applications to take advantage of that
data model. There are a variety of strategies for performing each
piece of this work. This section discusses some of those strategies.
</t>
<section title="Modeler">
<t>
The modeler defines a data model based on their in-depth knowledge of
the problem domain being modeled. This model should be as simple as
possible, but should balance complexity with expressiveness. The
organization of the model should target not only the current model,
but should allow for extensibility from other modules and for
adaptability to future changes.
</t>
<t>
Additional modeling issues are discussed in <xref target="modeling"/>.
</t>
</section>
<section title="Reviewer">
<t>
The reviewer role is perhaps the most important and the time
reviewers are willing to give is precious. To help the reviewer, YANG
stresses readability, with a human-friendly syntax, natural
data hierarchy, and simple, concise statements.
</t>
</section>
<section title="Device Developer">
<t>
The YANG model tells the device developer what data is being modeled.
The developer reads the YANG models and writes code that supports the
model. The model describes the data hierarchy and associated
constraints, and the description and reference material helps the
developer understand how to transform the models view into the
device's native implementation.
</t>
<section title="Generic Content Support">
<t>
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
outgoing data. The complete configuration datastore may be validated
in accordance with the constraints described in the data model.
</t>
<t>
Serializers and deserializers for generating and receiving NETCONF
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
incoming XML elements.
</t>
</section>
<section title="XML "over the wire" Definitions">
<t>
The YANG module dictates the XML encoding sent "over the wire", though
actual transmission should be encrypted so as not to appear as
readable text on the physical media. The rules that define the
encoding are fixed, so the YANG module can be used to ascertain
whether a specific NETCONF payload is obeying the rules.
</t>
</section>
</section>
<section title="Application Developer">
<t>
The YANG module tells the application developer what data can be
modeled. Developers can inspect the modules and take one of three
distinct views. In this section, we will consider them and the impact
of YANG on their design. In the real world, most applications are a
mixture of these approaches.
</t>
<section title="Hard Coded">
<t>
An application can be coded against the specific, well-known contents
of YANG modules, implementing their organization, rules, and logic
directly with explicit knowledge. For example, a script could be
written to change the domain name of a set of devices using a standard
YANG module that includes such a leaf node. This script takes the
new domain name as an argument and inserts it into a string containing the
rest of the XML encoding as required by the YANG module. This content
is then sent via NETCONF to each of the devices.
</t>
<t>
This type of application is useful for small, fixed problems where the
cost and complexity of flexibility is overwhelmed by the ease of hard
coding direct knowledge into the application.
</t>
</section>
<section title="Bottom Up">
<t>
An application may take a generic, bottom up approach to
configuration, concentrating on the device's data directly and
treating that data without specific understanding.
</t>
<t>
YANG modules may be used to drive the operation of the YANG equivalent
of a "MIB Browser". Such an application manipulates the device's
configuration data based on the data organization contained in the
YANG module. For example, a GUI may present a straight-forward
visualization where elements of the YANG hierarchy are depicted in a
hierarchy of folders or GUI panels. Clicking on a line expands to the
contents of the matching XML hierarchy.
</t>
<t>
This type of GUI can easily be built by generating XSLT stylesheets
from the YANG data models. An XSLT engine can then be used to turn
configuration data into a set of web pages.
</t>
<t>
The YANG modules allow the application to enforce a set of
constraints without understanding the semantics of the YANG
module.
</t>
</section>
<section title="Top Down">
<t>
In contrast to the bottom-up approach, the top-down approach allows
the application to take a view of the configuration data which is
distinct from the standard and/or proprietary YANG modules. The
application is free to construct its own model for data organization
and to present this model to the user. When the application needs to
transmit data to a device, the application transforms its data from
the problem-oriented view of the world into the data needed for that
particular device. This transformation is under the control and
maintenance of the application, allowing the transformation to be
changed and updated without affecting the device.
</t>
<t>
For example, an application could be written that models VPNs in a
network-oriented view. The application would need to transform these
high-level VPN definitions into the configuration data that would be
handed to any particular device within a VPN.
</t>
<t>
Even in this approach, YANG is useful since it can be used to model
the VPN. For example, the following VPN straw-man models a list of
VPNs, each with a protocol, a topology, a list of member interfaces,
and a list of classifiers.
</t>
<figure>
<artwork><![CDATA[
list example-bgpvpn {
key name;
leaf name { ... }
leaf protocol {
type enumeration {
enum bgpvpn;
enum l2vpn;
}
}
leaf topology {
type enumeration {
enum hub-n-spoke;
enum mesh;
}
}
list members {
key "device interface";
leaf device { ... }
leaf interface { ... }
}
list classifiers {
...
}
}
]]></artwork>
</figure>
<t>
The application can use such a YANG module to drive its operation,
building VPN instances in a database and then pushing the
configuration for those VPNs to individual devices using either a
standard device model (e.g. example-bgpvpn.yang) or by transforming that
standard device content into some proprietary format for devices that
do not support that standard.
</t>
</section>
</section>
</section>
</section>
<section title="Modeling Considerations" anchor="modeling">
<t>
This section discusses considerations the modeler should be aware of
while developing models in YANG.
</t>
<section title="Default Values">
<t>
The concept of default values is simple, but their details,
representation, and interaction with configuration data can be
difficult issues. NETCONF leaves default values as a data model
issue, and YANG gives flexibility to the device implementation in
terms of how default values are handled. The requirement is that the
device "MUST operationally behave as if the leaf was present in the
data tree with the default value as its value". This gives the device
implementation choices in how default values are handled.
</t>
<t>
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 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 given,
then the value is not considered to be part of configuration.
</t>
<t>
Another choice is to trim values that are identical to the default
values, implicitly removing them from the configuration datastore.
The act of setting a leaf to it's default value effectively deletes
that leaf.
</t>
<t>
The device could also choose to report all default values, regardless
of whether they were explicitly set. This choice eases the work of
a client that needs default values, but may significantly increase the
size of the configuration data.
</t>
<t>
These choices reflect the default handling schemes of widely deployed
networking devices and supporting them allows YANG to reduce
implementation and deployment costs of YANG-based models.
</t>
<t>
When the client retrieves data from the device, it must be prepared to
handle the absence of leaf nodes with the default value, since the
server is not required to send such leaf elements. This permits the
device to implement either of the first two default handling schemes
given above.
</t>
<t>
Regardless of the implementation choice, the device can support the
"with‑defaults" capability (<xref target="RFCWITHDEFAULTS"/>) and give the client the
ability to select the desired handling of default values.
</t>
<t>
When evaluating the XPath expressions for constraints like "must" and
"when", the evaluation context for the expressions will include any
appropriate default values, so the modeler can depend on consistent
behavior from all devices.
</t>
</section>
<section title="Compliance">
<t>
In developing good data models, there are many conflicting interests
the data modeler must keep in mind. Modelers need to be aware of five
issues with models and devices:
</t>
<t>
<list style="symbols">
<t>
usefulness
</t>
<t>
compliance
</t>
<t>
flexibility
</t>
<t>
extensibility
</t>
<t>
deviations
</t>
</list>
</t>
<t>
For a model to be interesting, it must be useful, solving a problem in
a more direct or more powerful way than can be accomplished without
the model. The model should maximize the usefulness of the model
with in the problem domain.
</t>
<t>
Modelers should build models that maximize the number of devices that
can faithfully implement the model. If the model is drawn too
narrowly, or includes too many assumptions about the device, then the
difficulty and cost of accurately implementing the model will lead to
low quality implementations, interoperability issues, and will reduce
the value of the model.
</t>
<t>
Modelers can use the "feature" statement in their models to give the
device some flexibility by partitioning their model and allowing the
device to indicate which portions of the model are implemented on the
device. For example, if the model includes some a "logging" feature , a
device with no storage facilities for the log can tell the client that
it does not support this feature of the model.
</t>
<t>
Models can be extended via the "augment" statement, and the modeler
should consider how their model is likely to be extended. These
augmentations can be defined by vendors, applications, or standards
bodies.
</t>
<t>
Deviations are a means of allowing the devices to indicate where its
implementation is not in full compliance with the model. For example,
once a model is published, an implementer may decide to make a
particular node configurable, where the standard model
describes it as state data. The implementation reports the value
normally and may declare a deviation that this device behaves in a
different manner than the standard. Applications capable of
discovering this deviation can make allowances, but applications that
do not discover the deviation can continue treating the implementation
as if it were compliant.
</t>
<t>
Rarely, implementations may make decisions that prevent compliance
with the standard. Such occasions are regrettable, but they remain a
part of reality, and modelers and application writers ignore them at
their own risk. An implementation that emits an integer leaf as
"cow" would be difficult to manage, but applications should expect to
encounter such misbehaving devices in the field.
</t>
<t>
Despite this, both client and server should view the YANG module as a
contract, with both sides agreeing to abide by the terms. The modeler
should be explicit about the terms of such a contract, and both client
and server implementations should strive to faithfully and accurately
implement the data model described in the YANG module.
</t>
</section>
<section title="Data Distinctions">
<t>
The distinction between configuration data, operational state data,
and statistics is important to understand for data model writers and
people who plan to extend the NETCONF protocol. This section first
discusses some background and then provides a definition and some
examples.
</t>
<section title="Background">
<t>
During the IAB NM workshop, operators did formulate the following two
requirements:
</t>
<figure>
<artwork><![CDATA[
2. It is necessary to make a clear distinction between
configuration data, data that describes operational state
and statistics. Some devices make it very hard to determine
which parameters were administratively configured and which
were obtained via other mechanisms such as routing
protocols.
3. It is required to be able to fetch separately configuration
data, operational state data, and statistics from devices,
and to be able to compare these between devices.
]]></artwork>
</figure>
<t>
The NETCONF protocol defined in RFC 4741 distinguishes two types
of data, namely configuration data and state data:
</t>
<figure>
<artwork><![CDATA[
Configuration data is the set of writable data that is
required to transform a system from its initial default state
into its current state.
State data is the additional data on a system that is not
configuration data such as read-only status information and
collected statistics.
]]></artwork>
</figure>
<t>
NETCONF does not follow the distinction formulated by the operators
between configuration data, operational state data, and statistical
data, since it considers state data to include both statistics and
operational state data.
</t>
</section>
<section title="Definitions">
<t>
Below is a definition for configuration data, operational state data,
and statistical data. The definition borrows from previous work.
</t>
<t>
<list style="symbols">
<t>
Configuration data is the set of writable data that is required to
transform a system from its initial default state into its current
state. <xref target="RFC4741"/>
</t>
<t>
Operational state data is a set of data that has been obtained by
the system at runtime and influences the system's behaviour similar
to configuration data. In contrast to configuration data,
operational state is transient and modified by interactions with
internal components or other systems via specialized protocols.
</t>
<t>
Statistical data is the set of read-only data created by a system
itself. It describes the performance of the system and its
components.
</t>
</list>
</t>
<t>
The following examples help to clarify the difference between
configuration data, operational state data and statistical data.
</t>
<section title="Example 1: IP Routing Table">
<t>
IP routing tables can contain entries that are statically configured
(configuration data) as well as entries obtained from routing
protocols such as OSPF (operational state data). In addition, a
routing engine might collect statistics like how often a particular
routing table entry has been used.
</t>
</section>
<section title="Example 2: Interfaces">
<t>
Network interfaces usually come with a large number of attributes
that are specific to the interface type and in some cases specific to
the cable plugged into an interface. Examples are the maximum
transmission unit of an interface or the speed detected by an Ethernet
interface.
</t>
<t>
In many deployments, systems use the interface attributes detected
when an interface is initialized. As such, these attributes constitute
operational state. However, there are usually provisions to overwrite
the discovered attributes with static configuration data, like for
example configuring the interface MTU to use a specific value or
forcing an Ethernet interface to run at a given speed.
</t>
<t>
The system will record statistics (counters) measuring the number of
packets, bytes, and errors received and transmitted on each interface.
</t>
</section>
<section title="Example 3: Account Information">
<t>
Systems usually maintain static configuration information about the
accounts on the system. In addition, systems can obtain information
about accounts from other sources (e.g. LDAP, NIS) dynamically,
leading to operational state data. Information about account usage are
examples of statistic data.
</t>
<t>
Note that configuration data supplied to a system in order to create a
new account might be supplemented with additional configuration
information determined by the system when the account is being created
(such as a unique account id). Even though the system might create
such information, it usually becomes part of the static configuration
of the system since this data is not transient.
</t>
</section>
</section>
<section title="Implications">
<t>
The primary focus of YANG is configuration data. There is no single
mechanism defined for the separation of operational state data and
statistics since NETCONF treats them both as state data. This section
describes several different options for addressing this issue.
</t>
<section title="Data Models">
<t>
The first option is to have data models that explicitly
differentiate between configuration data and operational state data.
This leads to duplication of data structures and might not scale well
from a modeling perspective.
</t>
<t>
For example, the configured duplex value and the operational duplex
value would be distinct leafs in the data model.
</t>
</section>
<section title="Additional Operations to Retrieve Operational State">
<t>
The NETCONF protocol can be extended with new protocol operations that
specifically allow the retrieval of all operational state, e.g. by
introducing a <get‑ops> operation (and perhaps also a <get‑stats>
operation).
</t>
</section>
<section title="Introduction of an Operational State Datastore">
<t>
Another option could be to introduce a new "configuration" data store
that represents the operational state. A <get‑config> operation on the
<operational> data store would then return the operational state
determining the behaviour of the box instead of its static and
explicit configuration state.
</t>
</section>
</section>
</section>
<section title="Direction">
<t>
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.
</t>
<t>
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".
</t>
<t>
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.
</t>
<t>
For example, configured static routes might be a distinct list from
the operational routing table, since the use of keys and sorting might
differ.
</t>
</section>
</section>
<section title="Security Considerations">
<t>
This document discusses an architecture for network management
using NETCONF and YANG. It has no security impact on the Internet.
</t>
</section>
<section title="IANA Considerations">
<t>
This document has no actions for IANA.
</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="RFCYANG">
<front>
<title>YANG - A data modeling language for the Network Configuration Protocol (NETCONF)</title>
<author initials="M." surname="Bjorklund" fullname="Martin Bjorklund" role="editor">
<organization>Tail-f Systems</organization>
</author>
</front>
<seriesInfo name="internet-draft" value="draft-ietf-netmod-yang-13"/>
</reference>
<reference anchor="RFCYANGTYPES">
<front>
<title>Common YANG Data Types</title>
<author initials="J." surname="Schoenwaelder" fullname="J. Schoenwaelder" role="author">
<organization>Jacobs University</organization>
</author>
</front>
<seriesInfo name="internet-draft" value="draft-ietf-netmod-yang-types-09.txt"/>
</reference>
<reference anchor="RFCWITHDEFAULTS">
<front>
<title>With-defaults capability for NETCONF</title>
<author initials="A." surname="Bierman" fullname="Andy Bierman" role="author">
<organization>InterWorking Labs</organization>
</author>
<author initials="B." surname="Lengyel" fullname="Balazs Lengyel" role="author">
<organization>Ericsson</organization>
</author>
</front>
<seriesInfo name="internet-draft" value="draft-ietf-netconf-with-defaults-11.txt"/>
</reference>
<reference anchor="RFCYANGUSAGE">
<front>
<title>Guidelines for Authors and Reviewers of YANG Data Model Documents</title>
<author initials="A." surname="Bierman" fullname="Andy Bierman" role="author">
<organization>InterWorking Labs</organization>
</author>
</front>
<seriesInfo name="internet-draft" value="draft-ietf-netmod-yang-usage-10.txt"/>
</reference>
<reference anchor="RFCYANGDSDL">
<front>
<title>Mapping YANG to Document Schema Definition Languages and Validating NETCONF Content</title>
<author initials="L." surname="Lhotka" fullname="Ladislav Lhotka" role="author">
<organization>CESNET</organization>
</author>
<author initials="R." surname="Mahy" fullname="Rohan Mahy" role="author">
<organization>Plantronics</organization>
</author>
<author initials="S." surname="Chishom" fullname="Sharon Chisholm" role="author">
<organization>Nortel</organization>
</author>
</front>
<seriesInfo name="internet-draft" value="draft-ietf-netmod-dsdl-map-06"/>
</reference>
<!--
<reference anchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials="S." surname="Bradner" fullname="S. Bradner">
<organization>Harvard University</organization>
</author>
<date month="March" year="1997"/>
<abstract>
<t>
In many standards track documents several words are used to signify
the requirements in the specification. These words are often
capitalized. This document defines these words as they should be
interpreted in IETF documents.
</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<format type="TXT" octets="4723" target="ftp://ftp.isi.edu/in-notes/rfc2119.txt"/>
</reference>
-->
<reference anchor="RFC3535">
<front>
<title>Overview of the 2002 IAB Network Management Workshop</title>
<author initials="J." surname="Schoenwaelder" fullname="J. Schoenwaelder">
<organization/>
</author>
<date year="2003" month="May"/>
<abstract>
<t>
This document provides an overview of a workshop held by the Internet
Architecture Board (IAB) on Network Management. The workshop was
hosted by CNRI in Reston, VA, USA on June 4 thru June 6, 2002. The
goal of the workshop was to continue the important dialog started
between network operators and protocol developers, and to guide the
IETFs focus on future work regarding network management. This report
summarizes the discussions and lists the conclusions and
recommendations to the Internet Engineering Task Force (IETF)
community. This memo provides information for the Internet community.
</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3535"/>
<format type="TXT" octets="42566"
target="ftp://ftp.rfc-editor.org/in-notes/rfc3535.txt"/>
</reference>
<reference anchor="RFC4741">
<front>
<title>NETCONF Configuration Protocol</title>
<author initials="R." surname="Enns" fullname="R. Enns">
<organization/>
</author>
<date year="2006" month="December"/>
<abstract>
<t>
The Network Configuration Protocol (NETCONF) defined in this document
provide s mechanisms to install, manipulate, and delete the
configuration of network devices. It u ses an Extensible Markup
Language (XML)-based data encoding for the configuration data as well
as the protocol messages. The NETCONF protocol operations are realized
on top of a si mple Remote Procedure Call (RPC) layer. [STANDARDS
TRACK]
</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4741"/>
<format type="TXT" octets="173914" target="ftp://ftp.isi.edu/in-notes/rfc4741.txt"/>
</reference>
<reference anchor="RFC4742">
<front>
<title>Using the NETCONF Configuration Protocol over Secure SHell (SSH)</title>
<author initials="M." surname="Wasserman" fullname="M. Wasserman">
<organization/>
</author>
<author initials="T." surname="Goddard" fullname="T. Goddard">
<organization/>
</author>
<date year="2006" month="December"/>
<abstract>
<t>
This document describes a method for invoking and
running the Network Configuration Protocol (NETCONF)
within a Secure Shell (SSH) session as an SSH
subsystem. [STANDARDS TRACK]
</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4742"/>
<format type="TXT" octets="17807"
target="http://www.rfc-editor.org/rfc/rfc4742.txt"/>
</reference>
<reference anchor="RFC4743">
<front>
<title>Using NETCONF over the Simple Object Access Protocol (SOAP)</title>
<author initials="T." surname="Goddard" fullname="T. Goddard">
<organization/>
</author>
<date year="2006" month="December"/>
<abstract>
<t>
The Network Configuration Protocol (NETCONF) is
applicable to a wide range of devices in a variety of
environments. Web Services is one such environment and
is presently characterized by the use of the Simple
Object Access Protocol (SOAP). NETCONF finds many
benefits in this environment: from the reuse of existing
standards, to ease of software development, to
integration with deployed systems. Herein, we describe
SOAP over HTTP and SOAP over Blocks Exchange Extensible
Protocol (BEEP) bindings for NETCONF. [STANDARDS TRACK]
</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4743"/>
<format type="TXT" octets="39734"
target="http://www.rfc-editor.org/rfc/rfc4743.txt"/>
</reference>
<reference anchor="RFC4744">
<front>
<title>Using the NETCONF Protocol over the Blocks Extensible Exchange Protocol (BEEP)</title>
<author initials="E." surname="Lear" fullname="E. Lear">
<organization/>
</author>
<author initials="K." surname="Crozier" fullname="K. Crozier">
<organization/>
</author>
<date year="2006" month="December"/>
<abstract>
<t>
This document specifies an application protocol mapping
for the Network Configuration Protocol (NETCONF) over
the Blocks Extensible Exchange Protocol
(BEEP). [STANDARDS TRACK]
</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4744"/>
<format type="TXT" octets="19287"
target="http://www.rfc-editor.org/rfc/rfc4744.txt"/>
</reference>
<reference anchor="RFC5277">
<front>
<title>NETCONF Event Notifications</title>
<author initials="S." surname="Chisholm" fullname="S. Chisholm">
<organization/>
</author>
<author initials="H." surname="Trevino" fullname="H. Trevino">
<organization/>
</author>
<date year="2008" month="July"/>
<abstract>
<t>
This document defines mechanisms that provide an
asynchronous message notification delivery service for
the Network Configuration protocol (NETCONF). This is
an optional capability built on top of the base NETCONF
definition. This document defines the capabilities and
operations necessary to support this service. [STANDARDS
TRACK]
</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5277"/>
<format type="TXT" octets="70878"
target="http://www.rfc-editor.org/rfc/rfc5277.txt"/>
</reference>
<reference anchor="RFC5539">
<front>
<title>NETCONF over Transport Layer Security (TLS)</title>
<author initials="M." surname="Badra" fullname="M. Badra">
<organization/>
</author>
<date year="2009" month="May"/>
<abstract>
<t>
The Network Configuration Protocol (NETCONF) provides
mechanisms to install, manipulate, and delete the
configuration of network devices. This document
describes how to use the Transport Layer Security (TLS)
protocol to secure NETCONF exchanges. [STANDARDS TRACK]
</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5539"/>
<format type="TXT" octets="16073"
target="http://www.rfc-editor.org/rfc/rfc5539.txt"/>
</reference>
<reference anchor="W3CXPATH"
target='http://www.w3.org/TR/1999/REC-xpath-19991116'>
<front>
<title>XML Path Language (XPath) Version 1.0</title>
<author initials='S.' surname='DeRose' fullname='Steven DeRose'>
<organization />
</author>
<author initials='J.' surname='Clark' fullname='James Clark'>
<organization />
</author>
<date month='November' day='16' year='1999' />
</front>
<seriesInfo name='World Wide Web Consortium Recommendation'
value='REC-xpath-19991116' />
<format type='HTML'
target='http://www.w3.org/TR/1999/REC-xpath-19991116' />
</reference>
<reference anchor="W3CXQUERY">
<front>
<title>XQuery 1.0: An XML Query Language</title>
<author initials='S' surname='Boag' fullname='Scott Boag'>
<organization />
</author>
<date month='September' day='15' year='2005' />
</front>
<seriesInfo name='W3C WD' value='WD-xquery-20050915' />
<format type='HTML'
target='http://www.w3.org/TR/2005/WD-xquery-20050915' />
</reference>
<reference anchor="W3CXSLT"
target='http://www.w3.org/TR/1999/REC-xslt-19991116'>
<front>
<title>XSL Transformations (XSLT) Version 1.0</title>
<author initials='J.' surname='Clark' fullname='James Clark'>
<organization />
</author>
<date month='November' day='16' year='1999' />
</front>
<seriesInfo name='World Wide Web Consortium Recommendation'
value='REC-xslt-19991116' />
<format type='HTML'
target='http://www.w3.org/TR/1999/REC-xslt-19991116' />
</reference>
<reference anchor="W3CXSD"
target='http://www.w3.org/TR/2004/REC-xmlschema-0-20041028'>
<front>
<title>XML Schema Part 0: Primer Second Edition</title>
<author initials='P.' surname='Walmsley'
fullname='Priscilla Walmsley'>
<organization />
</author>
<author initials='D.' surname='Fallside'
fullname='David C. Fallside'>
<organization />
</author>
<date month='October' day='28' year='2004' />
</front>
<seriesInfo name='World Wide Web Consortium Recommendation'
value='REC-xmlschema-0-20041028' />
<format type='HTML'
target='http://www.w3.org/TR/2004/REC-xmlschema-0-20041028' />
</reference>
<reference anchor="ISODSDL">
<front>
<title>Document Schema Definition Languages (DSDL)
- Part 1: Overview</title>
<author>
<organization>International Organization for Standardization</organization>
</author>
<date month="November" year="2004"/>
</front>
<seriesInfo name="ISO/IEC" value="19757-1"/>
</reference>
</references>
</back></rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 03:12:06 |