draft-ietf-netmod-arch-03.txt   draft-ietf-netmod-arch-04.txt 
Network Working Group P. Shafer Network Working Group P. Shafer
Internet-Draft Juniper Networks Internet-Draft Juniper Networks
Intended status: Informational February 27, 2010 Intended status: Informational March 8, 2010
Expires: August 31, 2010 Expires: September 9, 2010
An NETCONF- and NETMOD-based Architecture for Network Management An NETCONF- and NETMOD-based Architecture for Network Management
draft-ietf-netmod-arch-03 draft-ietf-netmod-arch-04
Abstract Abstract
NETCONF gives access to native capabilities of the devices within a NETCONF gives access to native capabilities of the devices within a
network, defining methods for manipulating configuration databases, network, defining methods for manipulating configuration databases,
retrieving operational data, and invoking specific operations. YANG retrieving operational data, and invoking specific operations. YANG
provides the means to define the content carried via NETCONF, both provides the means to define the content carried via NETCONF, both
data and operations. Using both technologies, standard modules can data and operations. Using both technologies, standard modules can
be defined to give interoperability and commonality to devices, while be defined to give interoperability and commonality to devices, while
still allowing devices to express their unique capabilities. still allowing devices to express their unique capabilities.
skipping to change at page 1, line 45 skipping to change at page 1, line 45
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 31, 2010. This Internet-Draft will expire on September 9, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 7 skipping to change at page 3, line 7
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
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. Key Words . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Origins of YANG . . . . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Elements of YANG . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. NETCONF . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. NETCONF . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. YANG . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3. YANG . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2.1. Constraints . . . . . . . . . . . . . . . . . . . . . 10
2.3.1. Extensibility Model . . . . . . . . . . . . . . . . . 9 2.2.2. Flexibility . . . . . . . . . . . . . . . . . . . . . 11
3. An Architecture for NETMOD . . . . . . . . . . . . . . . . . . 11 2.2.3. Extensibility Model . . . . . . . . . . . . . . . . . 11
4. YANG and Related Technologies . . . . . . . . . . . . . . . . 14 2.3. YANG Technologies . . . . . . . . . . . . . . . . . . . . 13
4.1. YIN . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.3.1. YIN . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2. DSDL (Relax NG) . . . . . . . . . . . . . . . . . . . . . 14 2.3.2. DSDL (Relax NG) . . . . . . . . . . . . . . . . . . . 13
4.3. YANG Types . . . . . . . . . . . . . . . . . . . . . . . . 15 2.4. YANG Types . . . . . . . . . . . . . . . . . . . . . . . . 14
5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 16 3. Working with YANG . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Device Developer . . . . . . . . . . . . . . . . . . . . . 16 3.1. Addressing Operator Problems . . . . . . . . . . . . . . . 15
5.2. Generic Content Support . . . . . . . . . . . . . . . . . 16 3.2. Building YANG-based Solutions . . . . . . . . . . . . . . 17
5.3. XML "over the wire" Definitions . . . . . . . . . . . . . 16 3.3. Modeler . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.4. Application Developer . . . . . . . . . . . . . . . . . . 16 3.4. Reviewer . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.4.1. Hard Coded . . . . . . . . . . . . . . . . . . . . . . 16 3.5. Device Developer . . . . . . . . . . . . . . . . . . . . . 17
5.4.2. Bottom Up . . . . . . . . . . . . . . . . . . . . . . 17 3.5.1. Generic Content Support . . . . . . . . . . . . . . . 17
5.4.3. Top Down . . . . . . . . . . . . . . . . . . . . . . . 17 3.5.2. XML "over the wire" Definitions . . . . . . . . . . . 18
6. Modeling Considerations . . . . . . . . . . . . . . . . . . . 18 3.6. Application Developer . . . . . . . . . . . . . . . . . . 18
7. Data Distinctions . . . . . . . . . . . . . . . . . . . . . . 19 3.6.1. Hard Coded . . . . . . . . . . . . . . . . . . . . . . 18
7.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 19 3.6.2. Bottom Up . . . . . . . . . . . . . . . . . . . . . . 18
7.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 19 3.6.3. Top Down . . . . . . . . . . . . . . . . . . . . . . . 19
7.2.1. Example 1: IP Routing Table . . . . . . . . . . . . . 20 4. Modeling Considerations . . . . . . . . . . . . . . . . . . . 21
7.2.2. Example 2: Interfaces . . . . . . . . . . . . . . . . 20 4.1. Default Values . . . . . . . . . . . . . . . . . . . . . . 21
7.2.3. Example 3: Account Information . . . . . . . . . . . . 20 4.2. Compliance . . . . . . . . . . . . . . . . . . . . . . . . 21
7.3. Implications . . . . . . . . . . . . . . . . . . . . . . . 21 4.3. Data Distinctions . . . . . . . . . . . . . . . . . . . . 22
7.3.1. Data Models . . . . . . . . . . . . . . . . . . . . . 21 4.3.1. Background . . . . . . . . . . . . . . . . . . . . . . 22
7.3.2. Additional Operations to Retrieve Operational State . 21 4.3.2. Definitions . . . . . . . . . . . . . . . . . . . . . 22
7.3.3. Introduction of an Operational State Datastore . . . . 21 4.3.3. Implications . . . . . . . . . . . . . . . . . . . . . 24
8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 5. Security Considerations . . . . . . . . . . . . . . . . . . . 25
9. Normative References . . . . . . . . . . . . . . . . . . . . . 23 6. Normative References . . . . . . . . . . . . . . . . . . . . . 26
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 27
1. Key Words
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14, [RFC2119].
2. Introduction 1. Origins of YANG
Networks are increasing in complexity and capacity, as well as the Networks are increasing in complexity and capacity, as well as the
density of the services deployed upon them. Uptime, reliability, and density of the services deployed upon them. Uptime, reliability, and
predictable latency requirements drive the need for automation. 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.
The problems with network management are not simple. They are In June of 2002, Internet Architecture Board (IAB) held a workshop on
complex and intricate. But these problems must be solved for Network Management ([RFC3535]). The members of this workshop made a
networks to meet the stability needs of existing services while number of observations and recommendations for the IETF's
incorporating new services in a world where the growth of the consideration concerning the issues operators were facing in their
networks is exhausting the supply of qualified networking engineers. network management-related work as well as issues they were having
We need to move from a CLI world into a world of automation, but that with the direction of the IETF activities in this area.
automation must be robust and trustworthy.
This document presents an architecture based on NETCONF ([RFC4741]) The output of this workshop was focused on current problems. The
and [YANG]. NETCONF and YANG address the problems of network operator's needs were reasonable and straight forward, including the
management with flexibility and expressiveness. NETCONF allows any need for transactions, rollback, low implementation costs, and the
manner of configuration and operational data to be carried with few ability to save and restore the device's configuration data. Many of
rules governing the data. YANG allows data models to be defined that the observations give insight into the problems operators were having
are flexible and extensible in ways that allow the data to be with existing network management solutions, such as the lack of full
cohesive and structured, but not rigid. coverage of device capabilities and the ability to distinguish
between configuration data and other types of data.
This approach allows the device to express its native capabilities in Based on these directions, the NETCONF working group was formed and
a way that is flexible and extensible. Evolution of devices and data the NETCONF protocol was created. This protocol defines a simple
models are permitted and managed. RPC-based mechanism where network management applications, acting as
clients, can invoke operations on the devices, which act as servers.
The NETCONF specification 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.
2.1. Terminology 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 and Relax NG were considered, but were rejected
because the problem domains have little natural overlap. Defining an
RPC which is encoded in XML is a distinct problem from defining an
XML document.
The document mirrors terminology from NETCONF. NETCONF uses a simple In early 2005, the NETMOD working group embraced YANG ([RFCYANG]) as
RPC-based mechanism to facilitate communication between a client and a means for defining data models for NETCONF, allowing both standard
a server. The client can be a script or application typically and proprietary data models to be published in a form that easily
running as part of a network management system. The server is digestible by human readers and satisfies many of the issues raised
typically a network device. The terms "device" and "server" are used in the IAB NM workshop. This brings NETCONF to a point where is can
interchangeably in this document, as are "client" and "application". be used to develop standards within the IETF.
2.2. NETCONF 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.
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, seemlessly 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.
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.
2. Elements of YANG
2.1. NETCONF
YANG is focused on creating data models for NETCONF, and any
understanding of the former must begin with the latter.
NETCONF defines an XML-based RPC mechanism that leverages the NETCONF defines an XML-based RPC mechanism that leverages the
simplicity and availability of high-quality XML parsers. XML gives a simplicity and availability of high-quality XML parsers. XML gives a
rich, flexible, hierarchical, standard representation of data that rich, flexible, hierarchical, standard representation of data that
matches the needs of networking devices. NETCONF carries matches the needs of networking devices. NETCONF carries
configuration data and operations encoded in XML using an RPC configuration data and operations encoded in XML using an RPC
mechanism over a connection-oriented transport. mechanism over a connection-oriented transport.
XML's hierarchical data representation allows complex networking data XML's hierarchical data representation allows complex networking data
to be rendered in a natural way. For example, the following to be rendered in a natural way. For example, the following
configuration places interfaces in OSPF areas. The <ospf> element configuration places interfaces in OSPF areas. The <ospf> element
contains a list of <area> elements, each of which contain a list of contains a list of <area> elements, each of which contain a list of
<interface> elements. The <name> element identifies the specific <interface> elements. The <name> element identifies the specific
area or interface. Additional configuration for each area or area or interface. Additional configuration for each area or
interface appears directly inside the appropriate element. interface appears directly inside the appropriate element.
<ospf xmlns="http://ns.ietf.org/netconf/ospf"> <ospf xmlns="http://example.org/netconf/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>
<!-- The priority for this interface --> <!-- The priority for this interface -->
<priority>30</priority> <priority>30</priority>
<metric>100</metric> <metric>100</metric>
<dead-interval>120</dead-interval> <dead-interval>120</dead-interval>
skipping to change at page 6, line 44 skipping to change at page 7, line 41
<interface> <interface>
<name>ge-0/0/3.0</name> <name>ge-0/0/3.0</name>
<metric>140</metric> <metric>140</metric>
<dead-interval>120</dead-interval> <dead-interval>120</dead-interval>
</interface> </interface>
</area> </area>
</ospf> </ospf>
NETCONF includes mechanisms for controlling configuration datastores, NETCONF includes mechanisms for controlling configuration datastores,
fetching state data, receiving notifications, and allows for fetching state data, and receiving notifications, and permits
additional RPC methods. Configuration operations include the ability additional RPC methods. Configuration operations include the ability
to lock datastores to isolate one application from the actions of to lock datastores to isolate one application from the actions of
others, the ability to save and restore configuration data sets, and others, the ability to save and restore configuration data sets, and
the ability to discover (via the <hello> message) the capabilities of the ability to discover (via the <hello> message) the capabilities of
the device. the device.
2.3. YANG More information about NETCONF can be found in [RFC4741].
YANG is the data model language for NETCONF that allows the 2.2. YANG
YANG is a data modeling language for NETCONF. It allows the
description of hierarchies of data model nodes ("nodes") and the description of hierarchies of data model nodes ("nodes") and the
constraints that exist amongst them. YANG defines data models and constraints that exist among them. YANG defines data models and how
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
allows tight integration of standard data models and proprietary data allows tight integration of standard data models and proprietary data
models. Models are built from organizational containers, lists of models. Models are built from organizational containers, lists of
data instances and leaf data values. data instances and leaf data values.
module ietf-ospf { module example-ospf {
namespace http://ns.ietf.org/netconf/ospf; namespace http://example.org/netconf/ospf;
prefix ospf; prefix ospf;
import network-types { // Access another module's def'ns import network-types { // Access another module's def'ns
prefix nett; prefix nett;
} }
container ospf { // Declare the top-level tag container ospf { // Declare the top-level tag
list area { // Declare a list of "area" nodes list area { // Declare a list of "area" nodes
key name; // The key "name" identifies list members key name; // The key "name" identifies list members
leaf name { leaf name {
skipping to change at page 9, line 5 skipping to change at page 9, line 51
} }
} }
} }
} }
A YANG module defines a data model in terms of the data, its A YANG module defines a data model in terms of the data, its
hierarchical organization, and the constraints on that data. YANG hierarchical organization, and the constraints on that data. YANG
defines how this data is represented in XML and how that data is used defines how this data is represented in XML and how that data is used
in NETCONF operations. in NETCONF operations.
2.3.1. Extensibility Model The following table briefly describes some common YANG statements:
+--------------+----------------------------------------------------+
| Statement | Description |
+--------------+----------------------------------------------------+
| augment | Extends existing data hierarchies |
| choice | Defines mutually exclusive alternatives |
| container | Defines a layer of the data hierarchy |
| extension | Allows new statements to be added to YANG |
| feature | Indicates parts of the model are optional |
| grouping | Groups data definitions into reusable sets |
| key | Defines the keys leafs for lists |
| leaf | Defines a leaf node in the data hierarchy |
| leaf-list | A leaf node that can appear as multiple times |
| list | A layer of hierarchy that can appear multiple |
| | times |
| notification | Define an notification |
| rpc | Define an RPC operation |
| typedef | Define a new type |
| uses | Incorporate the contents of a "grouping" |
+--------------+----------------------------------------------------+
2.2.1. Constraints
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.
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:
+--------------+----------------------------------------------------+
| Statement | Description |
+--------------+----------------------------------------------------+
| length | Limits the length of a string |
| mandatory | Requires the node appear |
| max-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 |
| pattern | Regular expression must be satisfied |
| range | Value must appear in range |
| reference | Value must appear elsewhere in the data |
| unique | Value must be unique within the data |
| when | Node is only present when XPath expression is true |
+--------------+----------------------------------------------------+
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.
2.2.2. Flexibility
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":
type union {
type int32;
type enumeration {
enum "unbounded";
}
}
A choice gives a set of mutually exclusive nodes, so a valid
configuration can choose any one node (or case). The "feature"
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.
The "deviation" give some flexibility to the device, allowing it to
define 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 problem, rather than ignoring it.
2.2.3. Extensibility Model
XML includes the concept of namespaces, allowing XML elements from XML includes the concept of namespaces, allowing XML elements from
different sources to be combined in the same hierarchy without different sources to be combined in the same hierarchy without
risking collision. YANG modules define content for specific risking collision. YANG modules define content for specific
namespaces, but one module may augment the definition of another namespaces, but one module may augment the definition of another
module, introducing elements from that module's namespace into the module, introducing elements from that module's namespace into the
first module's hierarchy. first module's hierarchy.
Since one module can augment another module's definition, hierarchies Since one module can augment another module's definition, hierarchies
of definitions are allowed to grow, as definitions from multiple of definitions are allowed to grow, as definitions from multiple
skipping to change at page 9, line 27 skipping to change at page 12, line 12
qualified using the namespace of the source module, helping to avoid qualified using the namespace of the source module, helping to avoid
issues with name conflicts as the modules change over time. issues with name conflicts as the modules change over time.
For example, if the above OSPF configuration were the standard, a For example, if the above OSPF configuration were the standard, a
vendor module may augment this with vendor-specific extensions. vendor module may augment this with vendor-specific extensions.
module vendorx-ospf { module vendorx-ospf {
namespace http://vendorx.example.com/ospf; namespace http://vendorx.example.com/ospf;
prefix vendorx; prefix vendorx;
import ietf-ospf { import example-ospf {
prefix ospf; prefix ospf;
} }
augment /ospf:ospf/ospf:area/ospf:interfaces { augment /ospf:ospf/ospf:area/ospf:interfaces {
leaf no-neighbor-down-notification { leaf no-neighbor-down-notification {
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:
<protocols xmlns="http://ietf.org/netconf/protocols" <protocols xmlns="http://example.org/netconf/protocols"
xmlns:vendorx="http://vendorx.example.com/ospf"> xmlns:vendorx="http://vendorx.example.com/ospf">
<ospf xmlns="http://ietf.org/netconf/ospf"> <ospf xmlns="http://example.org/netconf/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>
</area> </area>
</ospf> </ospf>
</protocols> </protocols>
Augmentations are seamlessly integrated with base modules, allowing Augmentations are seamlessly integrated with base modules, allowing
them to be fetched, archived, loaded, and deleted within their them to be fetched, archived, loaded, and deleted within their
natural hierarchy. If a client application asks for the natural hierarchy. If a client application asks for the
configuration for a specific OSPF area, it will receive the sub- configuration for a specific OSPF area, it will receive the sub-
hierarchy for that area, complete with any augmentations. hierarchy for that area, complete with any augmentated data.
3. An Architecture for NETMOD
In the NETMOD architecture, each device vendor implements a set of
data models in their devices. These models are either standard data
models, defined in YANG modules published by a standards body, or
proprietary data models, defined in YANG modules published by
vendors.
Standard data models define content that is independent of the
vendor, allowing client applications to request specific behavior
without concern for the vendor, product line, or installed software
revision. The translation between the standard model and the device
specific behavior is performed by the device, freeing the application
from such concerns.
Proprietary data models allow the vendor to accurately describe the
content and behavior of their devices in explicit detail.
Applications may take advantage of these specifics to give their
users complete control over the device.
When a NETCONF session begins, the namespaces for all supported
modules are announced as capabilities via the device's <hello>
message. The device should also support the schema discovery
mechanism [ref], enabling applications to discover the location from
which the modules may be downloaded.
The schema discovery for standard YANG modules should list a common,
standard location for these modules, presumably one set by the
organization that defined the standard.
When an application connects with a device, it receives the list of
capabilities supported by that device. The application may compare
the set of capabilities announced by the device with the set of
modules the application is aware of. Any new modules or new
revisions of known modules may be downloaded as needed from the
locations given via the schema discovery mechanism.
Once the application has access to the YANG modules, it may
manipulate the device as a "YANG data browser", capable of parsing
the elements sent from the device with an understanding of the
organization of the data. The module describes the syntax of the
data and constraints on that data, allowing the application to create
data that abides by those constraints.
To have a real understanding of a module's content, the application
may need to incorporate logic specific to that module. Semantic
information contained in description statements is not machine
readable, but module-specific custom work can be done to tailor the
user interface to the particular semantic needs of a module.
For example, a module could define the "location" of a device using
longitude and latitude, and the application can use the "browser"
style to display this data using input fields in a web form. Custom
logic would be needed to take the value of these fields and place the
device on a map of the world, and additional logic would be needed to
update the data values when the user drags the device from Dallas to
Dulles.
If an application is meant to manage a specific problem, it may model
the data internally in whatever form is most convenient to its
organizational needs. When the application interacts with a device,
it may choose one of two paths. If the device implements a standard
module, the application may generate content for that standard by
translating its internal form into the standard one.
If the device doesn't implement such a standard or no such standard
exists, the application may use a transformation that is particular
to that device's vendor, product model, hardware, or software.
Depending on the application, this transformation may be provided by
the application vendor, the device vendor, a third-party, or the
provider.
For a popular application, the device vendor may wish to provide this
transformation to increase market acceptance of their devices. For
popular devices, the application may provide this transformation as a
means of making the application useful in the maximum number of
provider networks. For problem domains where the mapping from the
application to the device is not straight-forward or requires
tailoring to the specific provider or environment, the provider may
wish to control this transformation. Additionally, other parties may
make such transformations available via open source.
Note that both cases may appear within a single application on an "as
needed" basis. If the device announces the capability for the
standard YANG module, the application may transmit to the device via
NETCONF the content in the standard modules format. If the device
does not announce the appropriate capability, the application may
find a transformation that matches the device, perform the
transformation on the standard data to produce device native
configuration, and transmit via NETCONF that device configuration to
the device.
In both cases, the key is the ability to discover the capabilities of
the specific device, download the YANG modules that support those
capabilities, gain an understanding of those data models and their
constraints, generate appropriate content, and transmit that content
to the device.
4. YANG and Related Technologies 2.3. YANG Technologies
The YANG data modeling language is the central piece of a group of The YANG data modeling language is the central piece of a group of
related technologies. The YANG language itself, described in [ref], related technologies. The YANG language itself, described in
defines the syntax of the language and its statements, the meaning of [RFCYANG], defines the syntax of the language and its statements, the
those statements, and how to combine them to build the hierarchy of meaning of those statements, and how to combine them to build the
nodes that describe a data model. hierarchy of nodes that describe a data model.
That document also defines the "on the wire" XML content for NETCONF That document also defines the "on the wire" XML content for NETCONF
operations on data models defined in YANG modules. This includes the operations on data models defined in YANG modules. This includes the
basic mapping between YANG data tree nodes and XML elements, as well basic mapping between YANG data tree nodes and XML elements, as well
as mechanisms used in <edit-config> content to manipulate that data, as mechanisms used in <edit-config> content to manipulate that data,
such as arranging the order of nodes within a list. such as arranging the order of nodes within a list.
YANG uses a syntax that is regular and easily described, primarily YANG uses a syntax that is regular and easily described, primarily
designed for human readability. YANG's syntax is friendly to email, designed for human readability. YANG's syntax is friendly to email,
diff, patch, and the constraints of RFC formatting. diff, patch, and the constraints of RFC formatting.
4.1. YIN 2.3.1. YIN
In some environments, incorporating a YANG parser may not be an In some environments, incorporating a YANG parser may not be an
acceptable option. For those scenarios, an XML grammar for YANG is acceptable option. For those scenarios, an XML grammar for YANG is
defined in YIN (YANG Independent Notation) [ref]. YIN allows the use defined as YIN (YANG Independent Notation). YIN allows the use of
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.
4.2. DSDL (Relax NG) 2.3.2. DSDL (Relax NG)
Since NETCONF content is encoded in XML, it is natural to use XML Since NETCONF content is encoded in XML, it is natural to use XML
schema languages for their validation. To facilitate this, YANG schema languages for their validation. To facilitate this, YANG
offers a standardized mapping of YANG modules into Document Schema offers a standardized mapping of YANG modules into Document Schema
Description Languages (DSDL) [DSDL]. Description Languages (DSDL) [DSDL].
DSDL is considered to be the best choice for the given purpose DSDL is considered to be the best choice for the given purpose
because it addresses not only grammar and datatypes of XML documents because it addresses not only grammar and datatypes of XML documents
but also semantic constraints and rules for modifying information set but also semantic constraints and rules for modifying information set
of the document. of the document.
In addition, DSDL offers formal means for coordinating multiple In addition, DSDL offers formal means for coordinating multiple
independent schemas and specifying how to apply the schemas to the independent schemas and specifying how to apply the schemas to the
various parts of the document. This is useful since YANG content is various parts of the document. This is useful since YANG content is
typically composed of multiple vocabularies. typically composed of multiple vocabularies.
4.3. 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
can add additional restrictions to allowable data values. can add additional restrictions to allowable data values.
A standard type library for use by YANG is available [ref]. These A standard type library for use by YANG is available [RFCYANGTYPES].
YANG modules define commonly used data types for IETF-related These YANG modules define commonly used data types for IETF-related
standards. standards.
5. Applicability 3. Working with YANG
The data model in a YANG module yields value in five specific areas. 3.1. Addressing Operator Problems
5.1. Device Developer YANG addresses many of the issues raised in the IAB NM workshop.
o Ease of use: YANG is designed to be human friendly, simple and
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.
o Configuration and Operational data: YANG clearly divides
configuration data from other types of data.
o Transactions: NETCONF provides a simple transaction mechanism.
o Generation of deltas: A YANG module gives enough information to
generate a the delta needed to change between two configuration
data sets.
o Dump and restore: NETCONF gives the ability to save and restore
configuration data. This can also performed for a specific YANG
module.
o Network-wide configuration: A standard YANG module can be
implemented in all devices, giving a common view of configuration
data.
o Text-friendly: YANG modules are very text friendly, as is the data
they define.
o Configuration handling: NETCONF addresses the ability to
distinguish between distributing configuration data and activating
it.
o Task-oriented: A YANG module can define specific tasks as rpc
methods. A client can choose to invoke the rpc or to access any
underlying data directly.
o 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 CLI/Expect access.
o Timeliness: YANG modules can be tied to CLI operations, so all
native operations and data are immediately available.
o Implementation difficulty: YANG's flexibility should allow simpler
modules that can be more easily implemented. Adding "features"
and replacing "third normal form" with a natural data hierarchy
should reduce complexity.
o Simple DDL: 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.
o Internationalization: YANG uses UTF-8 data.
o Event correlation: YANG integrated rpc, notification, operational,
and configuration data, allowing the data to make 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.
o Implementation costs: Significant effort has been made to keep
implementation costs as low as possible.
o 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.
o Post-processing: Use of XML will maximize the opportunities for
post-processing of data, possibly using XML-based technologies
like XPath, XQuery, and XSLT.
o 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.
o Security: NETCONF runs as an ssh service, allowing secure
communications and authentication using well-trusted technology.
This uses the existing key and credential management
infrastructure, reducing deployment costs.
o Reliable: NETCONF and YANG are solid and reliable technologies.
NETCONF is connection based, and includes automatic recovery
mechanisms when the connection is lost.
o Delta friendly: YANG-based models support operations that are
delta friendly. Add, change, insert, and delete operations are
all well defined.
o Method-oriented: YANG allows new NETCONF RPCs to be defined,
including an operation name, which is essentially a method. The
RPC's input and output data are also defined in the YANG module.
3.2. Building YANG-based Solutions
Building 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.
3.3. Modeler
(No clue what needs said here; lots to say, but what's important?)
Additional modeling issues are discussed in Section 4.
3.4. Reviewer
The reviewer role is perhaps the more 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.
In addition, reviewers can encode review policies in scripts, such as
XSLT. A policy that leaf names can't have underscores can be coded
as:
<xsl:template match="leaf[contains(@name, '_')]">
Error: leaf name contains underscore
</xsl:template>
3.5. Device Developer
The YANG model tells the device developer what data is being modeled. The YANG model tells the device developer what data is being modeled.
The developer reads the YANG models, absorbs the zen of the model, The developer reads the YANG models, absorbs the zen of the model,
and writes code that supports the model. The model describes the and writes code that supports the model. The model describes the
data hierarchy and associated constraints, and the description and data hierarchy and associated constraints, and the description and
reference material helps the developer understand how to transform reference material helps the developer understand how to transform
the models view into the device native implementation. the models view into the device's native implementation.
5.2. Generic Content Support 3.5.1. Generic Content Support
The YANG model can be compiled into a YANG-based engine for either The YANG model can be compiled into a YANG-based engine for either
the client or server side. Incoming data can be validated, as can the client or server side. Incoming data can be validated, as can
outgoing data. The complete configuration datastore may be validated outgoing data. The complete configuration datastore may be validated
in accordance with the constraints described in the data model. in accordance with the constraints described in the data model.
Serializers and deserializers for generating and receiving NETCONF Serializers and deserializers for generating and receiving NETCONF
content can be driven by the meta-data in the model. As data is content can be driven by the meta-data in the model. As data is
received, the meta-data is consulted to ensure the validity of received, the meta-data is consulted to ensure the validity of
incoming XML elements. incoming XML elements.
5.3. XML "over the wire" Definitions 3.5.2. XML "over the wire" Definitions
The YANG module dictates the XML encoding sent "over the wire", The YANG module dictates the XML encoding sent "over the wire",
though actual transmission should be encrypted so as not to appear as though actual transmission should be encrypted so as not to appear as
readable text on the physical media. The rules that define the readable text on the physical media. The rules that define the
encoding are fixed, so the YANG module can be used to ascertain encoding are fixed, so the YANG module can be used to ascertain
whether a specific NETCONF payload is obeying the rules. whether a specific NETCONF payload is obeying the rules.
5.4. Application Developer 3.6. 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.
5.4.1. Hard Coded 3.6.1. Hard Coded
An application can be coded against the specific, well-known contents An application can be coded against the specific, well-known contents
of YANG modules, implementing their organization, rules, and logic of YANG modules, implementing their organization, rules, and logic
directly with explicit knowledge. For example, a script could be directly with explicit knowledge. For example, a script could be
written to change the domain name of a set of devices using a written to change the domain name of a set of devices using a
standard YANG module that includes such a leaf node. This script standard YANG module that includes such a leaf node. This script
takes the new domain name as an argument and insert it into a string takes the new domain name as an argument and inserts it into a string
containing the rest of the XML encoding as required by the YANG containing the rest of the XML encoding as required by the YANG
module. This content is then sent via NETCONF to the devices. module. This content is then sent via NETCONF to each of the
devices.
This type of application is useful for small, fixed problems where This type of application is useful for small, fixed problems where
the cost and complexity of flexibility is overwhelmed by the ease of the cost and complexity of flexibility is overwhelmed by the ease of
hard coding direct knowledge into the application. hard coding direct knowledge into the application.
5.4.2. Bottom Up 3.6.2. Bottom Up
An application may take a generic, bottom up approach to An application may take a generic, bottom up approach to
configuration, concentrating on the device's data directly and configuration, concentrating on the device's data directly and
treating that data without specific understanding. treating that data without specific understanding.
YANG modules may be used to drive the operation of the YANG YANG modules may be used to drive the operation of the YANG
equivalent of a "MIB Browser". Such an application manipulates the equivalent of a "MIB Browser". Such an application manipulates the
device's configuration data based on the data organization contained device's configuration data based on the data organization contained
in the YANG module. For example, a GUI may present a straight- in the YANG module. For example, a GUI may present a straight-
forward visualization where elements of the YANG hierarchy are forward visualization where elements of the YANG hierarchy are
depicted in a hierarchy of folders or GUI panels. Clicking on a line depicted in a hierarchy of folders or GUI panels. Clicking on a line
expands to the contents of the matching content. expands to the contents of the matching XML hierarchy.
This type of GUI can easily be built by generating XSLT stylesheets This type of GUI can easily be built by generating XSLT stylesheets
from the YANG data models. An XSLT engine can then be used to turn from the YANG data models. An XSLT engine can then be used to turn
configuration data into a set of web pages. configuration data into a set of web pages.
The YANG modules allows the application to enforce a set of The YANG modules allows the application to enforce a set of
constraints without understanding the semantics of the YANG module. constraints without understanding the semantics of the YANG module.
5.4.3. Top Down 3.6.3. Top Down
In contrast to the bottom-up approach, the top-down approach allows In contrast to the bottom-up approach, the top-down approach allows
the application to take a view of the configuration data which is the application to take a view of the configuration data which is
distinct from the standard and/or proprietary YANG modules. The distinct from the standard and/or proprietary YANG modules. The
application is free to construct its own model for data organization application is free to construct its own model for data organization
and to present this model to the user. When the application needs to and to present this model to the user. When the application needs to
transmit data to a device, the application transforms its data from transmit data to a device, the application transforms its data from
the problem-oriented view of the world into the data needed for that the problem-oriented view of the world into the data needed for that
particular device. This transformation is under the control and particular device. This transformation is under the control and
maintenance of the application, allowing the transformation to be maintenance of the application, allowing the transformation to be
changed and updated without affecting the device. changed and updated without affecting the device.
For example, an application could be written that models VPNs in a For example, an application could be written that models VPNs in a
network-oriented view. The application would need to transform these network-oriented view. The application would need to transform these
high-level VPN definitions into the configuration data that would be high-level VPN definitions into the configuration data that would be
handed to any particular device within a VPN. handed to any particular device within a VPN.
6. Modeling Considerations Even in this approach, YANG is useful since it can be used to model
the VPN.
list vpn {
key name;
leaf name { ... }
leaf type {
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 {
...
}
}
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 uses either a
standard device model (e.g. bgp.yang) or by transforming that
standard device content into some proprietary format for devices that
do not support that standard.
4. Modeling Considerations
This section discusses considerations the modeler should be aware of
while developing models in YANG.
4.1. Default Values
(With all the discussion on this point, it needs to be mentioned
here.)
4.2. Compliance
In developing good data models, there are many conflicting interests In developing good data models, there are many conflicting interests
the data modeler must keep in mind. Modelers need to be aware of the data modeler must keep in mind. Modelers need to be aware of
four types of behavior in modeled device: four types of behavior in modeled device:
o [strict compliance] behavior that follow the model completely o [strict compliance] behavior that follow the model completely
o [modeled deviations] behavior that follows within deviations o [modeled deviations] behavior that follows within deviations
allowed by the model allowed by the model
o [allowable deviations] behavior that falls outside the model, but o [allowable deviations] behavior that falls outside the model, but
can still be handled can still be handled
o [unacceptable deviations] behavior that is not at all consistent o [unacceptable deviations] behavior that is not at all consistent
with the model with the model
Once the model is published, an implementer may decide to make a Once the model is published, an implementer may decide to make a
particular data model node configurable, where the standard model particular data model node configurable, where the standard model
describes it a state data. The implementation reports the value describes it a state data. The implementation reports the value
normally and may have an "out of band" mechanism for reporting that normally and may declare a deviation that this device behaves in a
this device behaves in a different manner than the standard. different manner than the standard. Applications capable of
Applications capable of discovering such behavior can make discovering this deviation can make allowances, but applications that
allowances, but applications that do not discover such behavior can do not discover the deviation can continue treating the
continue treating the implementation as if it were compliant. implementation as if it were compliant.
Rarely, implementations may make decisions that prevent compliance Rarely, implementations may make decisions that prevent compliance
with the standard. Such occasions are regrettable, but they remain a with the standard. Such occasions are regrettable, but they remain a
part of reality, and modelers and application writers ignore them at part of reality, and modelers and application writers ignore them at
their own risk. An implementation that emits an integer leaf as their own risk. An implementation that emits an integer leaf as
"cow" would be difficult to manage, but applications must expect to "cow" would be difficult to manage, but applications must expect to
encounter such misbehaving devices in the field. encounter such misbehaving devices in the field.
Despite this, both client and server should view the YANG module as a Despite this, both client and server should view the YANG module as a
contract, with both sides agreeing to abide by the terms. The contract, with both sides agreeing to abide by the terms. The
modeler should be explicit about the terms of such a contract, and modeler should be explicit about the terms of such a contract, and
both client and server implementations should strive to faithfully both client and server implementations should strive to faithfully
and accurately implement the data model described in the YANG module. and accurately implement the data model described in the YANG module.
7. Data Distinctions 4.3. Data Distinctions
The distinction between configuration data, operational state data, The distinction between configuration data, operational state data,
and statistics is important to understand for data model writers and and statistics is important to understand for data model writers and
people who plan to extend the NETCONF protocol. This section first people who plan to extend the NETCONF protocol. This section first
discusses some background and then provides a definition and some discusses some background and then provides a definition and some
examples. examples.
7.1. Background 4.3.1. Background
During the IAB Network Management Workshop documented in RFC 3535, During the IAB NM workshop, operators did formulate the following two
operators did formulate the following two requirements: requirements:
2. It is necessary to make a clear distinction between 2. It is necessary to make a clear distinction between
configuration data, data that describes operational state configuration data, data that describes operational state
and statistics. Some devices make it very hard to determine and statistics. Some devices make it very hard to determine
which parameters were administratively configured and which which parameters were administratively configured and which
were obtained via other mechanisms such as routing were obtained via other mechanisms such as routing
protocols. protocols.
3. It is required to be able to fetch separately configuration 3. It is required to be able to fetch separately configuration
data, operational state data, and statistics from devices, data, operational state data, and statistics from devices,
skipping to change at page 19, line 45 skipping to change at page 22, line 45
State data is the additional data on a system that is not State data is the additional data on a system that is not
configuration data such as read-only status information and configuration data such as read-only status information and
collected statistics. collected statistics.
NETCONF does not follow the distinction formulated by the operators NETCONF does not follow the distinction formulated by the operators
between configuration data, operational state data, and statistical between configuration data, operational state data, and statistical
data, since it considers state data to include both statistics and data, since it considers state data to include both statistics and
operational state data. operational state data.
7.2. Definitions 4.3.2. Definitions
Below is a definition for configuration data, operational state data, Below is a definition for configuration data, operational state data,
and statistical data. The definition borrows from previous work. and statistical data. The definition borrows from previous work.
o Configuration data is the set of writable data that is required to o Configuration data is the set of writable data that is required to
transform a system from its initial default state into its current transform a system from its initial default state into its current
state. [RFC 4741] state. [RFC 4741]
o Operational state data is a set of data that has been obtained by o Operational state data is a set of data that has been obtained by
the system at runtime and influences the system's behaviour the system at runtime and influences the system's behaviour
skipping to change at page 20, line 18 skipping to change at page 23, line 18
operational state is transient and modified by interactions with operational state is transient and modified by interactions with
internal components or other systems via specialized protocols. internal components or other systems via specialized protocols.
o Statistical data is the set of read-only data created by a system o Statistical data is the set of read-only data created by a system
itself. It describes the performance of the system and its itself. It describes the performance of the system and its
components. components.
The following examples help to clarify the difference between The following examples help to clarify the difference between
configuration data, operational state data and statistical data. configuration data, operational state data and statistical data.
7.2.1. Example 1: IP Routing Table 4.3.2.1. Example 1: IP Routing Table
IP routing tables can contain entries that are statically configured IP routing tables can contain entries that are statically configured
(configuration data) as well as entries obtained from routing (configuration data) as well as entries obtained from routing
protocols such as OSPF (operational state data). In addition, a protocols such as OSPF (operational state data). In addition, a
routing engine might collect statistics like how often a particular routing engine might collect statistics like how often a particular
routing table entry has been used. routing table entry has been used.
7.2.2. Example 2: Interfaces 4.3.2.2. Example 2: Interfaces
Network interfaces usually comes with a large number of attributes Network interfaces usually comes with a large number of attributes
that are specific to the interface type and in some cases specific to that are specific to the interface type and in some cases specific to
the cable plugged into an interface. Examples are the maximum the cable plugged into an interface. Examples are the maximum
transmission unit of an interface or the speed detected by an transmission unit of an interface or the speed detected by an
Ethernet interface. Ethernet interface.
In many deployments, systems use the interface attributes detected In many deployments, systems use the interface attributes detected
when an interface is initialized. As such, these attributes when an interface is initialized. As such, these attributes
constitute operational state. However, there are usually provisions constitute operational state. However, there are usually provisions
to overwrite the discovered attributes with static configuration to overwrite the discovered attributes with static configuration
data, like for example configuring the interface MTU to use a data, like for example configuring the interface MTU to use a
specific value or forcing an Ethernet interface to run at a given specific value or forcing an Ethernet interface to run at a given
speed. speed.
The system will record statistics (counters) measuring the number of The system will record statistics (counters) measuring the number of
packets, bytes, and errors received and transmitted on each packets, bytes, and errors received and transmitted on each
interface. interface.
7.2.3. Example 3: Account Information 4.3.2.3. Example 3: Account Information
Systems usually maintain static configuration information about the Systems usually maintain static configuration information about the
accounts on the system. In addition, systems can obtain information accounts on the system. In addition, systems can obtain information
about accounts from other sources (e.g. LDAP, NIS) dynamically, about accounts from other sources (e.g. LDAP, NIS) dynamically,
leading to operational state data. Information about account usage leading to operational state data. Information about account usage
are examples of statistic data. are examples of statistic data.
Note that configuration data supplied to a system in order to create Note that configuration data supplied to a system in order to create
a new account might be supplemented with additional configuration a new account might be supplemented with additional configuration
information determined by the system when the account is being information determined by the system when the account is being
created (such as a unique account id). Even though the system might created (such as a unique account id). Even though the system might
create such information, it usually becomes part of the static create such information, it usually becomes part of the static
configuration of the system since this data is not transient. configuration of the system since this data is not transient.
7.3. Implications 4.3.3. Implications
The primary focus of YANG is configuration data. There is no single The primary focus of YANG is configuration data. There is no single
mechanism defined for the separation of operational state data and mechanism defined for the separation of operational state data and
statistics since NETCONF treats them both as state data. This statistics since NETCONF treats them both as state data. This
section describes several different options for addressing this section describes several different options for addressing this
issue. issue.
7.3.1. Data Models 4.3.3.1. Data Models
The first option is to have data models that provide explicitly The first option is to have data models that provide explicitly
differentiate between configuration data and operational state data. differentiate between configuration data and operational state data.
This leads to duplication of data structures and might not scale well This leads to duplication of data structures and might not scale well
from a modeling perspective. from a modeling perspective.
For example, the configured duplex value and the operational duplex For example, the configured duplex value and the operational duplex
value would be distinct leafs in the data model. value would be distinct leafs in the data model.
7.3.2. Additional Operations to Retrieve Operational State 4.3.3.2. Additional Operations to Retrieve Operational State
The NETCONF protocol can be extended with new protocol operations The NETCONF protocol can be extended with new protocol operations
that specifically allow the retrieval of all operational state, e.g. that specifically allow the retrieval of all operational state, e.g.
by introducing a <get-ops> operation (and perhaps also a <get-stats> by introducing a <get-ops> operation (and perhaps also a <get-stats>
operation). operation).
7.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.
8. Security Considerations 5. Security Considerations
This document defines a language with which to write and read This document discusses data modeling using YANG, and has no security
descriptions of management information. The language itself has no impact on the Internet.
security impact on the Internet.
9. Normative References 6. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC3535] Schoenwaelder, J., "Overview of the 2002 IAB Network
Requirement Levels", BCP 14, RFC 2119, March 1997. 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.
[YANG] Bjorklund, M., Ed., "YANG - A data modeling language for [RFCYANG] Bjorklund, M., Ed., "YANG - A data modeling language for
NETCONF", draft-ietf-netmod-yang-11 (work in progress). NETCONF", draft-ietf-netmod-yang-11 (work in progress).
[RFCYANGTYPES]
Schoenwaelder, J., Ed., "Common YANG Data Types",
draft-ietf-netmod-yang-types-07.txt (work in progress).
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. 62 change blocks. 
233 lines changed or deleted 428 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/