draft-ietf-netmod-yang-11.txt   draft-ietf-netmod-yang-12.txt 
Network Working Group M. Bjorklund, Ed. Network Working Group M. Bjorklund, Ed.
Internet-Draft Tail-f Systems Internet-Draft Tail-f Systems
Intended status: Standards Track February 24, 2010 Intended status: Standards Track April 14, 2010
Expires: August 28, 2010 Expires: October 16, 2010
YANG - A data modeling language for NETCONF YANG - A data modeling language for NETCONF
draft-ietf-netmod-yang-11 draft-ietf-netmod-yang-12
Abstract Abstract
YANG is a data modeling language used to model configuration and YANG is a data modeling language used to model configuration and
state data manipulated by the Network Configuration Protocol state data manipulated by the Network Configuration Protocol
(NETCONF) protocol, NETCONF remote procedure calls, and NETCONF (NETCONF) protocol, NETCONF remote procedure calls, and NETCONF
notifications. notifications.
Status of this Memo Status of this Memo
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 28, 2010. This Internet-Draft will expire on October 16, 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 8, line 28 skipping to change at page 8, line 28
choice Statement . . . . . . . . . . . . . . . . . . . . 169 choice Statement . . . . . . . . . . . . . . . . . . . . 169
13.8. Error Message for the "insert" Operation . . . . . . . . 170 13.8. Error Message for the "insert" Operation . . . . . . . . 170
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 171 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 171
15. Security Considerations . . . . . . . . . . . . . . . . . . . 172 15. Security Considerations . . . . . . . . . . . . . . . . . . . 172
16. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 173 16. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 173
17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 174 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 174
18. References . . . . . . . . . . . . . . . . . . . . . . . . . 175 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 175
18.1. Normative References . . . . . . . . . . . . . . . . . . 175 18.1. Normative References . . . . . . . . . . . . . . . . . . 175
18.2. Non-Normative References . . . . . . . . . . . . . . . . 176 18.2. Non-Normative References . . . . . . . . . . . . . . . . 176
Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . 177 Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . 177
A.1. Version -10 . . . . . . . . . . . . . . . . . . . . . . . 177 A.1. Version -12 . . . . . . . . . . . . . . . . . . . . . . . 177
A.2. Version -09 . . . . . . . . . . . . . . . . . . . . . . . 177 A.2. Version -11 . . . . . . . . . . . . . . . . . . . . . . . 177
A.3. Version -08 . . . . . . . . . . . . . . . . . . . . . . . 177 A.3. Version -10 . . . . . . . . . . . . . . . . . . . . . . . 177
A.4. Version -07 . . . . . . . . . . . . . . . . . . . . . . . 178 A.4. Version -09 . . . . . . . . . . . . . . . . . . . . . . . 177
A.5. Version -06 . . . . . . . . . . . . . . . . . . . . . . . 178 A.5. Version -08 . . . . . . . . . . . . . . . . . . . . . . . 178
A.6. Version -05 . . . . . . . . . . . . . . . . . . . . . . . 178 A.6. Version -07 . . . . . . . . . . . . . . . . . . . . . . . 178
A.7. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 179 A.7. Version -06 . . . . . . . . . . . . . . . . . . . . . . . 178
A.8. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 179 A.8. Version -05 . . . . . . . . . . . . . . . . . . . . . . . 178
A.9. Version -02 . . . . . . . . . . . . . . . . . . . . . . . 179 A.9. Version -04 . . . . . . . . . . . . . . . . . . . . . . . 179
A.10. Version -01 . . . . . . . . . . . . . . . . . . . . . . . 180 A.10. Version -03 . . . . . . . . . . . . . . . . . . . . . . . 179
A.11. Version -00 . . . . . . . . . . . . . . . . . . . . . . . 181 A.11. Version -02 . . . . . . . . . . . . . . . . . . . . . . . 180
A.12. Version -01 . . . . . . . . . . . . . . . . . . . . . . . 180
A.13. Version -00 . . . . . . . . . . . . . . . . . . . . . . . 181
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 182 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 182
1. Introduction 1. Introduction
YANG is a data modeling language used to model configuration and YANG is a data modeling language used to model configuration and
state data manipulated by the Network Configuration Protocol state data manipulated by the Network Configuration Protocol
(NETCONF) protocol, NETCONF remote procedure calls, and NETCONF (NETCONF) protocol, NETCONF remote procedure calls, and NETCONF
notifications. YANG is used to model the operations and content notifications. YANG is used to model the operations and content
layers of NETCONF (see the NETCONF Configuration Protocol [RFC4741], layers of NETCONF (see the NETCONF Configuration Protocol [RFC4741],
section 1.1). section 1.1).
skipping to change at page 15, line 34 skipping to change at page 15, line 34
arbitrary XML documents or arbitrary data models. The data models arbitrary XML documents or arbitrary data models. The data models
described by YANG are designed to be easily operated upon by NETCONF described by YANG are designed to be easily operated upon by NETCONF
operations. operations.
To the extent possible, YANG maintains compatibility with SNMP's To the extent possible, YANG maintains compatibility with SNMP's
SMIv2 (Structure of Management Information version 2 [RFC2578], SMIv2 (Structure of Management Information version 2 [RFC2578],
[RFC2579]). SMIv2-based MIB modules can be automatically translated [RFC2579]). SMIv2-based MIB modules can be automatically translated
into YANG modules for read-only access. However, YANG is not into YANG modules for read-only access. However, YANG is not
concerned with reverse translation from YANG to SMIv2. concerned with reverse translation from YANG to SMIv2.
Like NETCONF, YANG targets smooth integration with device's native Like NETCONF, YANG targets smooth integration with the device's
management infrastructure. This allows implementations to leverage native management infrastructure. This allows implementations to
their existing access control mechanisms to protect or expose leverage their existing access control mechanisms to protect or
elements of the data model. expose elements of the data model.
4.2. Language Overview 4.2. Language Overview
This section introduces some important constructs used in YANG that This section introduces some important constructs used in YANG that
will aid in the understanding of the language specifics in later will aid in the understanding of the language specifics in later
sections. This progressive approach handles the inter-related nature sections. This progressive approach handles the inter-related nature
of YANG concepts and statements. A detailed description of YANG of YANG concepts and statements. A detailed description of YANG
statements and syntax begins in Section 7. statements and syntax begins in Section 7.
4.2.1. Modules and Submodules 4.2.1. Modules and Submodules
skipping to change at page 17, line 41 skipping to change at page 17, line 41
description description
"Message given at start of login session"; "Message given at start of login session";
} }
} }
} }
NETCONF XML Example: NETCONF XML Example:
<system> <system>
<login> <login>
<message>Good morning, Dave</message> <message>Good morning</message>
</login> </login>
</system> </system>
The "container" statement is covered in Section 7.5. The "container" statement is covered in Section 7.5.
4.2.2.4. List Nodes 4.2.2.4. List Nodes
A list defines a sequence of list entries. Each entry is like a A list defines a sequence of list entries. Each entry is like a
structure or a record instance, and is uniquely identified by the structure or a record instance, and is uniquely identified by the
values of its key leafs. A list can define multiple key leafs and values of its key leafs. A list can define multiple key leafs and
skipping to change at page 18, line 34 skipping to change at page 18, line 34
<name>glocks</name> <name>glocks</name>
<full-name>Goldie Locks</full-name> <full-name>Goldie Locks</full-name>
<class>intruder</class> <class>intruder</class>
</user> </user>
<user> <user>
<name>snowey</name> <name>snowey</name>
<full-name>Snow White</full-name> <full-name>Snow White</full-name>
<class>free-loader</class> <class>free-loader</class>
</user> </user>
<user> <user>
<name>rzull</name> <name>rzell</name>
<full-name>Repun Zell</full-name> <full-name>Rapun Zell</full-name>
<class>tower</class> <class>tower</class>
</user> </user>
The "list" statement is covered in Section 7.8. The "list" statement is covered in Section 7.8.
4.2.2.5. Example Module 4.2.2.5. Example Module
These statements are combined to define the module: These statements are combined to define the module:
// Contents of "acme-system.yang" // Contents of "acme-system.yang"
skipping to change at page 21, line 5 skipping to change at page 21, line 5
} }
} }
4.2.4. Built-in Types 4.2.4. Built-in Types
YANG has a set of built-in types, similar to those of many YANG has a set of built-in types, similar to those of many
programming languages, but with some differences due to special programming languages, but with some differences due to special
requirements from the management domain. The following table requirements from the management domain. The following table
summarizes the built-in types discussed in Section 9: summarizes the built-in types discussed in Section 9:
+---------------------+---------------------------------------------+ +---------------------+-------------------------------------+
| Name | Description | | Name | Description |
+---------------------+---------------------------------------------+ +---------------------+-------------------------------------+
| binary | Any binary data | | binary | Any binary data |
| bits | A set of bits or flags | | bits | A set of bits or flags |
| boolean | "true" or "false" | | boolean | "true" or "false" |
| decimal64 | 64-bit signed decimal number | | decimal64 | 64-bit signed decimal number |
| empty | A leaf that does not have any value | | empty | A leaf that does not have any value |
| enumeration | Enumerated strings with associated numeric | | enumeration | Enumerated strings |
| | values | | identityref | A reference to an abstract identity |
| identityref | A reference to an abstract identity | | instance-identifier | References a data tree node |
| instance-identifier | References a data tree node | | int8 | 8-bit signed integer |
| int8 | 8-bit signed integer | | int16 | 16-bit signed integer |
| int16 | 16-bit signed integer | | int32 | 32-bit signed integer |
| int32 | 32-bit signed integer | | int64 | 64-bit signed integer |
| int64 | 64-bit signed integer | | leafref | A reference to a leaf instance |
| leafref | A reference to a leaf instance | | string | Human readable string |
| string | Human readable string | | uint8 | 8-bit unsigned integer |
| uint8 | 8-bit unsigned integer | | uint16 | 16-bit unsigned integer |
| uint16 | 16-bit unsigned integer | | uint32 | 32-bit unsigned integer |
| uint32 | 32-bit unsigned integer | | uint64 | 64-bit unsigned integer |
| uint64 | 64-bit unsigned integer | | union | Choice of member types |
| union | Choice of member types | +---------------------+-------------------------------------+
+---------------------+---------------------------------------------+
The "type" statement is covered in Section 7.4. The "type" statement is covered in Section 7.4.
4.2.5. Derived Types (typedef) 4.2.5. Derived Types (typedef)
YANG can define derived types from base types using the "typedef" YANG can define derived types from base types using the "typedef"
statement. A base type can be either a built-in type or a derived statement. A base type can be either a built-in type or a derived
type, allowing a hierarchy of derived types. type, allowing a hierarchy of derived types.
A derived type can be used as the argument for the "type" statement. A derived type can be used as the argument for the "type" statement.
skipping to change at page 26, line 35 skipping to change at page 26, line 35
YANG allows the definition of notifications suitable for NETCONF. YANG allows the definition of notifications suitable for NETCONF.
YANG data definition statements are used to model the content of the YANG data definition statements are used to model the content of the
notification. notification.
YANG Example: YANG Example:
notification link-failure { notification link-failure {
description "A link failure has been detected"; description "A link failure has been detected";
leaf if-name { leaf if-name {
type leafref { type leafref {
path "/interfaces/interface/name"; path "/interface/name";
} }
} }
leaf if-admin-status { leaf if-admin-status {
type admin-status; type admin-status;
} }
leaf if-oper-status { leaf if-oper-status {
type oper-status; type oper-status;
} }
} }
skipping to change at page 34, line 20 skipping to change at page 34, line 20
would be far better if the application had prior knowledge of this would be far better if the application had prior knowledge of this
limitation and could prevent the user from starting down the path limitation and could prevent the user from starting down the path
that could not succeed. that could not succeed.
Device deviations are declared using the "deviation" statement, which Device deviations are declared using the "deviation" statement, which
takes as its argument a string which identifies a node in the schema takes as its argument a string which identifies a node in the schema
tree. The contents of the statement details the manner in which the tree. The contents of the statement details the manner in which the
device implementation deviates from the contract as defined in the device implementation deviates from the contract as defined in the
module. module.
Further details are available in Section 7.18.3.
5.6.4. Announcing Conformance Information in the <hello> Message 5.6.4. Announcing Conformance Information in the <hello> Message
The namespace URI MUST be advertised as a capability in the NETCONF The namespace URI MUST be advertised as a capability in the NETCONF
<hello> message to indicate support for the YANG module by a NETCONF <hello> message to indicate support for the YANG module by a NETCONF
server. The capability URI advertised MUST be on the form: server. The capability URI advertised MUST be on the form:
capability-string = namespace-uri [ parameter-list ] capability-string = namespace-uri [ parameter-list ]
parameter-list = "?" parameter *( "&" parameter ) parameter-list = "?" parameter *( "&" parameter )
parameter = revision-parameter / parameter = revision-parameter /
module-parameter / module-parameter /
skipping to change at page 34, line 41 skipping to change at page 34, line 43
deviation-parameter deviation-parameter
revision-parameter = "revision=" revision-date revision-parameter = "revision=" revision-date
module-parameter = "module=" module-name module-parameter = "module=" module-name
feature-parameter = "features=" feature *( "," feature ) feature-parameter = "features=" feature *( "," feature )
deviation-parameter = "deviations=" deviation *( "," deviation ) deviation-parameter = "deviations=" deviation *( "," deviation )
Where "revision-date" is the revision of the module (see Where "revision-date" is the revision of the module (see
Section 7.1.9) that the NETCONF server implements, "module-name" is Section 7.1.9) that the NETCONF server implements, "module-name" is
the name of module as it appears in the "module" statement (see the name of module as it appears in the "module" statement (see
Section 7.1), "namespace-uri" is the namespace URI for the module as Section 7.1), "namespace-uri" is the namespace URI for the module as
it appears in the "namespace" statement, "feature" is the name of an it appears in the "namespace" statement (see Section 7.1.3),
optional feature implemented by the device (see Section 7.18.1), and "feature" is the name of an optional feature implemented by the
"deviation" is the name of a module defining device deviations (see device (see Section 7.18.1), and "deviation" is the name of a module
Section 7.18.3). defining device deviations (see Section 7.18.3).
In the parameter list, each named parameter MUST occur at most once. In the parameter list, each named parameter MUST occur at most once.
5.6.4.1. Modules 5.6.4.1. Modules
Servers indicate the names of supported modules via the <hello> Servers indicate the names of supported modules via the <hello>
message. Module namespaces are encoded as the base URI in the message. Module namespaces are encoded as the base URI in the
capability string, and the module name is encoded as the "module" capability string, and the module name is encoded as the "module"
parameter to the base URI. parameter to the base URI.
skipping to change at page 37, line 48 skipping to change at page 37, line 48
6.1.3. Quoting 6.1.3. Quoting
If a string contains any space or tab characters, a semicolon (";"), If a string contains any space or tab characters, a semicolon (";"),
braces ("{" or "}"), or comment sequences ("//", "/*", or "*/"), then braces ("{" or "}"), or comment sequences ("//", "/*", or "*/"), then
it MUST be enclosed within double or single quotes. it MUST be enclosed within double or single quotes.
If the double quoted string contains a line break followed by space If the double quoted string contains a line break followed by space
or tab characters which are used to indent the text according to the or tab characters which are used to indent the text according to the
layout in the YANG file, this leading whitespace is stripped from the layout in the YANG file, this leading whitespace is stripped from the
string, up to the column of the double quote character, or to the string, up to and including the column of the double quote character,
first non-whitespace character, whichever occurs first. or to the first non-whitespace character, whichever occurs first.
If the double quoted string contains space or tab characters before a If the double quoted string contains space or tab characters before a
line break, this trailing whitespace is stripped from the string. line break, this trailing whitespace is stripped from the string.
A single quoted string (enclosed within ' ') preserves each character A single quoted string (enclosed within ' ') preserves each character
within the quotes. A single quote character cannot occur in a single within the quotes. A single quote character cannot occur in a single
quoted string, even when preceded by a backslash. quoted string, even when preceded by a backslash.
Within a double quoted string (enclosed within " "), a backslash Within a double quoted string (enclosed within " "), a backslash
character introduces a special character, which depends on the character introduces a special character, which depends on the
skipping to change at page 48, line 23 skipping to change at page 48, line 23
7.1.7. The organization Statement 7.1.7. The organization Statement
The "organization" statement defines the party responsible for this The "organization" statement defines the party responsible for this
module. The argument is a string which is used to specify a textual module. The argument is a string which is used to specify a textual
description of the organization(s) under whose auspices this module description of the organization(s) under whose auspices this module
was developed. was developed.
7.1.8. The contact Statement 7.1.8. The contact Statement
The "contact" statement provides contact information for the module. The "contact" statement provides contact information for the module.
The argument is a string which is used to specify the name, postal The argument is a string which is used to specify contact information
address, telephone number, and electronic mail address of the person for the person or persons to whom technical queries concerning this
to whom technical queries concerning this module should be sent. module should be sent, such as their name, postal address, telephone
number, and electronic mail address.
7.1.9. The revision Statement 7.1.9. The revision Statement
The "revision" statement specifies the editorial revision history of The "revision" statement specifies the editorial revision history of
the module, including the initial revision. A series of revision the module, including the initial revision. A series of revision
statements detail the changes in the module's definition. The statements detail the changes in the module's definition. The
argument is a date string in the format "YYYY-MM-DD", followed by a argument is a date string in the format "YYYY-MM-DD", followed by a
block of substatements that holds detailed revision information. A block of substatements that holds detailed revision information. A
module SHOULD have at least one initial "revision" statement. For module SHOULD have at least one initial "revision" statement. For
every published editorial change, a new one SHOULD be added in front every published editorial change, a new one SHOULD be added in front
skipping to change at page 75, line 42 skipping to change at page 75, line 42
type string; type string;
} }
} }
A corresponding XML instance example: A corresponding XML instance example:
<user> <user>
<name>fred</name> <name>fred</name>
<type>admin</type> <type>admin</type>
<full-name>Fred Flintstone</full-name> <full-name>Fred Flintstone</full-name>
</name> </user>
To create a new user "barney": To create a new user "barney":
<rpc message-id="101" <rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"> xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config> <edit-config>
<target> <target>
<running/> <running/>
</target> </target>
skipping to change at page 83, line 52 skipping to change at page 83, line 52
</edit-config> </edit-config>
</rpc> </rpc>
7.10. The anyxml Statement 7.10. The anyxml Statement
The "anyxml" statement defines an interior node in the schema tree. The "anyxml" statement defines an interior node in the schema tree.
It takes one argument, which is an identifier, followed by a block of It takes one argument, which is an identifier, followed by a block of
substatements that holds detailed anyxml information. substatements that holds detailed anyxml information.
The anyxml statement is used to represent an unknown chunk of XML. The anyxml statement is used to represent an unknown chunk of XML.
No restrictions are placed on the XML. This can be useful in for No restrictions are placed on the XML. This can be useful, for
example RPC replies. An example is the <filter> parameter in the example, in RPC replies. An example is the <filter> parameter in the
<get-config> operation. <get-config> operation.
An anyxml node cannot be augmented. An anyxml node cannot be augmented.
Since the use of anyxml limits the manipulation of the content, it is Since the use of anyxml limits the manipulation of the content, it is
RECOMMENDED that the anyxml statement not be used to represent RECOMMENDED that the anyxml statement not be used to represent
configuration data. configuration data.
An anyxml node exists in zero or one instances in the data tree. An anyxml node exists in zero or one instances in the data tree.
skipping to change at page 87, line 11 skipping to change at page 87, line 11
| typedef | 7.3 | 0..n | | typedef | 7.3 | 0..n |
| uses | 7.12 | 0..n | | uses | 7.12 | 0..n |
+--------------+---------+-------------+ +--------------+---------+-------------+
7.11.2. Usage Example 7.11.2. Usage Example
import ietf-inet-types { import ietf-inet-types {
prefix "inet"; prefix "inet";
} }
grouping address { grouping endpoint {
description "A reusable address group."; description "A reusable endpoint group.";
leaf ip { leaf ip {
type inet:ip-address; type inet:ip-address;
} }
leaf port { leaf port {
type inet:port-number; type inet:port-number;
} }
} }
7.12. The uses Statement 7.12. The uses Statement
skipping to change at page 88, line 24 skipping to change at page 88, line 24
| reference | 7.19.4 | 0..1 | | reference | 7.19.4 | 0..1 |
| status | 7.19.2 | 0..1 | | status | 7.19.2 | 0..1 |
| when | 7.19.5 | 0..1 | | when | 7.19.5 | 0..1 |
+--------------+---------+-------------+ +--------------+---------+-------------+
7.12.2. The refine Statement 7.12.2. The refine Statement
Some of the properties of each node in the grouping can be refined Some of the properties of each node in the grouping can be refined
with the "refine" statement. The argument is a string which with the "refine" statement. The argument is a string which
identifies a node in the grouping. This node is called the refine's identifies a node in the grouping. This node is called the refine's
target node. If a node in the grouping is not present as target node target node. If a node in the grouping is not present as a target
of a refine statement, it is not refined, and thus used exactly as it node of a refine statement, it is not refined, and thus used exactly
was defined in the grouping. as it was defined in the grouping.
The argument string is a descendant schema node identifier (see The argument string is a descendant schema node identifier (see
Section 6.5). Section 6.5).
The following refinements can be done: The following refinements can be done:
o A leaf or choice node may get a default value, or a new default o A leaf or choice node may get a default value, or a new default
value if it already had one. value if it already had one.
o Any node may get a specialized "description" string. o Any node may get a specialized "description" string.
skipping to change at page 89, line 13 skipping to change at page 89, line 13
"max-elements" statement. "max-elements" statement.
7.12.3. XML Mapping Rules 7.12.3. XML Mapping Rules
Each node in the grouping is encoded as if it was defined inline, Each node in the grouping is encoded as if it was defined inline,
even if it is imported from another module with another XML even if it is imported from another module with another XML
namespace. namespace.
7.12.4. Usage Example 7.12.4. Usage Example
To use the "address" grouping defined in Section 7.11.2 in a To use the "endpoint" grouping defined in Section 7.11.2 in a
definition of an HTTP server in some other module, we can do: definition of an HTTP server in some other module, we can do:
import acme-system { import acme-system {
prefix "acme"; prefix "acme";
} }
container http-server { container http-server {
leaf name { leaf name {
type string; type string;
} }
uses acme:address; uses acme:endpoint;
} }
A corresponding XML instance example: A corresponding XML instance example:
<http-server> <http-server>
<name>extern-web</name> <name>extern-web</name>
<ip>192.0.2.1</ip> <ip>192.0.2.1</ip>
<port>80</port> <port>80</port>
</http-server> </http-server>
If port 80 should be the default for the HTTP server, default can be If port 80 should be the default for the HTTP server, default can be
added: added:
container http-server { container http-server {
leaf name { leaf name {
type string; type string;
} }
uses acme:address { uses acme:endpoint {
refine port { refine port {
default 80; default 80;
} }
} }
} }
If we want to define a list of servers, and each server has the ip If we want to define a list of servers, and each server has the ip
and port as keys, we can do: and port as keys, we can do:
list server { list server {
key "ip port"; key "ip port";
leaf name { leaf name {
type string; type string;
} }
uses acme:address; uses acme:endpoint;
} }
The following is an error: The following is an error:
container http-server { container http-server {
uses acme:address; uses acme:endpoint;
leaf ip { // illegal - same identifier "ip" used twice leaf ip { // illegal - same identifier "ip" used twice
type string; type string;
} }
} }
7.13. The rpc Statement 7.13. The rpc Statement
The "rpc" statement is used to define a NETCONF RPC operation. It The "rpc" statement is used to define a NETCONF RPC operation. It
takes one argument, which is an identifier, followed by a block of takes one argument, which is an identifier, followed by a block of
substatements that holds detailed rpc information. This argument is substatements that holds detailed rpc information. This argument is
skipping to change at page 106, line 7 skipping to change at page 106, line 7
implementations vary from the standards. implementations vary from the standards.
Device deviations are strongly discouraged and SHOULD only be used as Device deviations are strongly discouraged and SHOULD only be used as
a last resort. Telling the application how a device fails to follow a last resort. Telling the application how a device fails to follow
a standard is no substitute for implementing the standard correctly. a standard is no substitute for implementing the standard correctly.
However in some cases a particular device may not have the hardware However in some cases a particular device may not have the hardware
or software ability to support parts of a standard module. When this or software ability to support parts of a standard module. When this
occurs, the device makes a choice to treat attempts to configure occurs, the device makes a choice to treat attempts to configure
unsupported parts of the module as either an error that is reported unsupported parts of the module as either an error that is reported
back to the unsuspecting application, or ignore that incoming back to the unsuspecting application, or ignore those incoming
requests. Neither choice is acceptable. requests. Neither choice is acceptable.
Instead, YANG allows devices to document portions of a base module Instead, YANG allows devices to document portions of a base module
which are not supported or supported but with different syntax, by which are not supported or supported but with different syntax, by
using the "deviation" statement. using the "deviation" statement.
7.18.3.1. The deviation's Substatements 7.18.3.1. The deviation's Substatements
+--------------+----------+-------------+ +--------------+----------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
skipping to change at page 122, line 11 skipping to change at page 122, line 11
00ABAB // illegal, too long 00ABAB // illegal, too long
xx00 // illegal, bad characters xx00 // illegal, bad characters
9.5. The boolean Built-in Type 9.5. The boolean Built-in Type
The boolean built-in type represents a boolean value. The boolean built-in type represents a boolean value.
9.5.1. Lexicographic Representation 9.5.1. Lexicographic Representation
The lexicographical representation of a boolean value is the strings The lexicographical representation of a boolean value is a string
"true" and "false". with a value of "true" or "false".
9.5.2. Canonical Form 9.5.2. Canonical Form
The canonical form is the same as the lexicographical representation. The canonical form is the same as the lexicographical representation.
9.5.3. Restrictions 9.5.3. Restrictions
A boolean cannot be restricted. A boolean cannot be restricted.
9.6. The enumeration Built-in Type 9.6. The enumeration Built-in Type
skipping to change at page 130, line 9 skipping to change at page 130, line 9
<address>192.0.2.2</address> <address>192.0.2.2</address>
</default-address> </default-address>
The following list uses a leafref for one of its keys. This is The following list uses a leafref for one of its keys. This is
similar to a foreign key in a relational database. similar to a foreign key in a relational database.
list packet-filter { list packet-filter {
key "if-name filter-id"; key "if-name filter-id";
leaf if-name { leaf if-name {
type leafref { type leafref {
path "/interfaces/interface/name"; path "/interface/name";
} }
} }
leaf filter-id { leaf filter-id {
type uint32; type uint32;
} }
... ...
} }
An example of a corresponding XML anippet: An example of a corresponding XML snippet:
<interface> <interface>
<name>eth0</name> <name>eth0</name>
<admin-status>up</admin-status> <admin-status>up</admin-status>
<address> <address>
<ip>192.0.2.1</ip> <ip>192.0.2.1</ip>
</address> </address>
<address> <address>
<ip>192.0.2.2</ip> <ip>192.0.2.2</ip>
</address> </address>
skipping to change at page 131, line 8 skipping to change at page 131, line 8
<filter-id>2</filter-id> <filter-id>2</filter-id>
... ...
</packet-filter> </packet-filter>
The following notification defines two leafrefs to refer to an The following notification defines two leafrefs to refer to an
existing admin-status: existing admin-status:
notification link-failure { notification link-failure {
leaf if-name { leaf if-name {
type leafref { type leafref {
path "/interfaces/interface/name"; path "/interface/name";
} }
} }
leaf admin-status { leaf admin-status {
type leafref { type leafref {
path path
"/interfaces/interface[name = current()/../if-name]" "/interface[name = current()/../if-name]"
+ "/admin-status"; + "/admin-status";
} }
} }
} }
An example of a corresponding XML notification: An example of a corresponding XML notification:
<notification <notification
xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
<eventTime>2008-04-01T00:01:00Z</eventTime> <eventTime>2008-04-01T00:01:00Z</eventTime>
skipping to change at page 168, line 22 skipping to change at page 168, line 22
13.1. Error Message for Data that Violates a unique Statement 13.1. Error Message for Data that Violates a unique Statement
If a NETCONF operation would result in configuration data where a If a NETCONF operation would result in configuration data where a
unique constraint is invalidated, the following error is returned: unique constraint is invalidated, the following error is returned:
Tag: operation-failed Tag: operation-failed
Error-app-tag: data-not-unique Error-app-tag: data-not-unique
Error-info: <non-unique>: Contains an instance identifier which Error-info: <non-unique>: Contains an instance identifier which
points to a leaf which invalidates the unique points to a leaf which invalidates the unique
constraint. This element is present once for each constraint. This element is present once for each
leaf invalidating the unique constraint. non-unique leaf.
The <non-unique> element is in the YANG The <non-unique> element is in the YANG
namespace ("urn:ietf:params:xml:ns:yang:1"). namespace ("urn:ietf:params:xml:ns:yang:1").
13.2. Error Message for Data that Violates a max-elements Statement 13.2. Error Message for Data that Violates a max-elements Statement
If a NETCONF operation would result in configuration data where a If a NETCONF operation would result in configuration data where a
list or a leaf-list would have too many entries the following error list or a leaf-list would have too many entries the following error
is returned: is returned:
skipping to change at page 172, line 11 skipping to change at page 172, line 11
Registrant Contact: The IESG. Registrant Contact: The IESG.
XML: N/A, the requested URIs are XML namespaces. XML: N/A, the requested URIs are XML namespaces.
15. Security Considerations 15. Security Considerations
This document defines a language with which to write and read This document defines a language with which to write and read
descriptions of management information. The language itself has no descriptions of management information. The language itself has no
security impact on the Internet. security impact on the Internet.
The same considerations are relevant as for the base NETCONF protocol
(See [RFC4741], section 9).
Data modeled in YANG might contain sensitive information. RPCs or Data modeled in YANG might contain sensitive information. RPCs or
notifications defined in YANG might transfer sensitive information. notifications defined in YANG might transfer sensitive information.
Security issues are related to the usage of data modeled in YANG. Security issues are related to the usage of data modeled in YANG.
Such issues shall be dealt with in documents describing the data Such issues shall be dealt with in documents describing the data
models and documents about the interfaces used to manipulate the data models and documents about the interfaces used to manipulate the data
e.g., the NETCONF documents. e.g., the NETCONF documents.
Data modeled in YANG is dependent upon: Data modeled in YANG is dependent upon:
skipping to change at page 176, line 8 skipping to change at page 176, line 8
Wide Web Consortium Recommendation REC-xml-names-20091208, Wide Web Consortium Recommendation REC-xml-names-20091208,
December 2009, December 2009,
<http://www.w3.org/TR/2009/REC-xml-names-20091208>. <http://www.w3.org/TR/2009/REC-xml-names-20091208>.
[XPATH] Clark, J. and S. DeRose, "XML Path Language (XPath) [XPATH] Clark, J. and S. DeRose, "XML Path Language (XPath)
Version 1.0", World Wide Web Consortium Version 1.0", World Wide Web Consortium
Recommendation REC-xpath-19991116, November 1999, Recommendation REC-xpath-19991116, November 1999,
<http://www.w3.org/TR/1999/REC-xpath-19991116>. <http://www.w3.org/TR/1999/REC-xpath-19991116>.
[XSD-TYPES] [XSD-TYPES]
Biron, P V. and A. Malhotra, "XML Schema Part 2: Datatypes Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes
Second Edition", W3C REC REC-xmlschema-2-20041028, Second Edition", World Wide Web Consortium
October 2004. Recommendation REC-xmlschema-2-20041028, October 2004,
<http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
18.2. Non-Normative References 18.2. Non-Normative References
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Structure of Management Information Schoenwaelder, Ed., "Structure of Management Information
Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Textual Conventions for SMIv2", Schoenwaelder, Ed., "Textual Conventions for SMIv2",
STD 58, RFC 2579, April 1999. STD 58, RFC 2579, April 1999.
skipping to change at page 177, line 9 skipping to change at page 177, line 9
[XSLT] Clark, J., "XSL Transformations (XSLT) Version 1.0", World [XSLT] Clark, J., "XSL Transformations (XSLT) Version 1.0", World
Wide Web Consortium Recommendation REC-xslt-19991116, Wide Web Consortium Recommendation REC-xslt-19991116,
November 1999, November 1999,
<http://www.w3.org/TR/1999/REC-xslt-19991116>. <http://www.w3.org/TR/1999/REC-xslt-19991116>.
Appendix A. ChangeLog Appendix A. ChangeLog
RFC Editor: remove this section upon publication as an RFC. RFC Editor: remove this section upon publication as an RFC.
A.1. Version -10 A.1. Version -12
o Editorial fixes after IETF Last Call.
A.2. Version -11
o New Copyright text and some editorial fixes.
A.3. Version -10
o Added "description" and "reference" as substatements to "when". o Added "description" and "reference" as substatements to "when".
o Make sure identifiers are XML compatible, i.e. do not start with o Make sure identifiers are XML compatible, i.e. do not start with
"xml". "xml".
o Use the terms "data node" and "schema node" instead of "node" in o Use the terms "data node" and "schema node" instead of "node" in
the Terminology section. the Terminology section.
o Use the character "@" as separator in recommended file names. o Use the character "@" as separator in recommended file names.
o Require a new "revision" statement in new versions of published o Require a new "revision" statement in new versions of published
modules. modules.
o Specified which error codes <edit-config> processing should o Specified which error codes <edit-config> processing should
generate. generate.
o Various editorial fixes and enhancements. o Various editorial fixes and enhancements.
A.2. Version -09 A.4. Version -09
o Specified that we do not specify formal rules for how the server o Specified that we do not specify formal rules for how the server
may modify configuration data stores. may modify configuration data stores.
o Added rule to allow defaults to be added to leafs in an updated o Added rule to allow defaults to be added to leafs in an updated
module. module.
o Clarified how ordered-by user lists and leaf-lists entries are o Clarified how ordered-by user lists and leaf-lists entries are
encoded in XML. encoded in XML.
o Clarified how child nodes to "case" are encoded in the XML. o Clarified how child nodes to "case" are encoded in the XML.
A.3. Version -08 A.5. Version -08
o Clarified text on leaf deafults. o Clarified text on leaf deafults.
o Added the term "top-level data node" to the terminology section. o Added the term "top-level data node" to the terminology section.
o Clarified how prefixes are mapped to namespaces in XPath o Clarified how prefixes are mapped to namespaces in XPath
expressions. expressions.
o Added "reference" as a substatement to "revision". o Added "reference" as a substatement to "revision".
o Added "choice" as a substatement to "case". o Added "choice" as a substatement to "case".
o Clarified that a leafreaf must be conditional if the leaf it o Clarified that a leafreaf must be conditional if the leaf it
refers to is conditional. refers to is conditional.
o Clarified how identityref default values are represented. o Clarified how identityref default values are represented.
o Various bug fixes, clarifications and editorial fixes. o Various bug fixes, clarifications and editorial fixes.
A.4. Version -07 A.6. Version -07
o The argument string of "augment", "refine", and "deviation" is o The argument string of "augment", "refine", and "deviation" is
described not as an XPath but as a "schema node identifier". described not as an XPath but as a "schema node identifier".
o Clarified that there must be no circular references in a leafref. o Clarified that there must be no circular references in a leafref.
A.5. Version -06 A.7. Version -06
o Various bug fixes, clarifications and editorial fixes after WGLC. o Various bug fixes, clarifications and editorial fixes after WGLC.
o Removed "require-instance" for leafref. o Removed "require-instance" for leafref.
o Allow leafrefs to refer to leaf-lists. o Allow leafrefs to refer to leaf-lists.
o Clarified the XPath context in Section 6.4.1, and for "must", o Clarified the XPath context in Section 6.4.1, and for "must",
"when", "augment", "path" and "instance-identifier". "when", "augment", "path" and "instance-identifier".
A.6. Version -05 A.8. Version -05
o Replaced the data types "float32" and "float64" with "decimal64". o Replaced the data types "float32" and "float64" with "decimal64".
o Specified that the elements in the XML encoding of configuration o Specified that the elements in the XML encoding of configuration
data can occur in any order. data can occur in any order.
o Clarified that "augment" cannot add multiple nodes with the same o Clarified that "augment" cannot add multiple nodes with the same
name. name.
o Clarified what "when" means in RPC input / output. o Clarified what "when" means in RPC input / output.
o Wrote the IANA Considerations section. o Wrote the IANA Considerations section.
o Changed requirement for minimum identifier length to 64 o Changed requirement for minimum identifier length to 64
characters. characters.
A.7. Version -04 A.9. Version -04
o Using "revision-date" substatement to "import" and "include". o Using "revision-date" substatement to "import" and "include".
o Corrected grammar and text for instance-identifier. o Corrected grammar and text for instance-identifier.
o Fixed bugs in some examples. o Fixed bugs in some examples.
o Rewrote the YIN description to use a declarative style. o Rewrote the YIN description to use a declarative style.
o Added two error codes in Section 13. o Added two error codes in Section 13.
skipping to change at page 179, line 31 skipping to change at page 179, line 38
o Corrected grammar for key-arg; now allowing optional prefix on o Corrected grammar for key-arg; now allowing optional prefix on
each leaf identifier. each leaf identifier.
o Clarified that "unique" constraints only check instances with o Clarified that "unique" constraints only check instances with
values for all referenced leafs. values for all referenced leafs.
o Clarified how mandatory and min-elements constraints are enforced. o Clarified how mandatory and min-elements constraints are enforced.
o Editorial fixes. o Editorial fixes.
A.8. Version -03 A.10. Version -03
o Added import by revision (yang-00413) o Added import by revision (yang-00413)
o Changed type "keyref" to "leafref", and added the statement o Changed type "keyref" to "leafref", and added the statement
"require-instance" (yang-01253) "require-instance" (yang-01253)
o Clarified that data sent from the server must be in the canonical o Clarified that data sent from the server must be in the canonical
form. form.
o Clarified when and how constraints in the models are enforced. o Clarified when and how constraints in the models are enforced.
skipping to change at page 179, line 44 skipping to change at page 180, line 4
o Changed type "keyref" to "leafref", and added the statement o Changed type "keyref" to "leafref", and added the statement
"require-instance" (yang-01253) "require-instance" (yang-01253)
o Clarified that data sent from the server must be in the canonical o Clarified that data sent from the server must be in the canonical
form. form.
o Clarified when and how constraints in the models are enforced. o Clarified when and how constraints in the models are enforced.
o Many editorial fixes o Many editorial fixes
o Added more strict grammar for the "deviate" statement. o Added more strict grammar for the "deviate" statement.
A.9. Version -02 A.11. Version -02
o Added module update rules. (yang-00000) o Added module update rules. (yang-00000)
o Added "refine" statement as a substatement to "uses". (yang-00088) o Added "refine" statement as a substatement to "uses". (yang-00088)
o Allow "augment" on top-level and in "uses" only. (yang-00088) o Allow "augment" on top-level and in "uses" only. (yang-00088)
o Allow "when" on all data defintion statements. (yang-00088) o Allow "when" on all data defintion statements. (yang-00088)
o Added section "Constraints" and clarified when constraints are o Added section "Constraints" and clarified when constraints are
enforced. (yang-00172) enforced. (yang-00172)
o Added "feature" and "if-feature" statements. (yang-00750) o Added "feature" and "if-feature" statements. (yang-00750)
o Added "prefix" as a substatement to "belongs-to". (yang-00755) o Added "prefix" as a substatement to "belongs-to". (yang-00755)
skipping to change at page 180, line 23 skipping to change at page 180, line 31
o Added "prefix" as a substatement to "belongs-to". (yang-00755) o Added "prefix" as a substatement to "belongs-to". (yang-00755)
o Added section on Conformance. (yang-01281) o Added section on Conformance. (yang-01281)
o Added "deviation" statement. (yang-01281) o Added "deviation" statement. (yang-01281)
o Added "identity" statement and "identityref" type. (yang-01339) o Added "identity" statement and "identityref" type. (yang-01339)
o Aligned grammar for "enum" with text. o Aligned grammar for "enum" with text.
A.10. Version -01 A.12. Version -01
o Removed "Appendix A. Derived YANG Types". o Removed "Appendix A. Derived YANG Types".
o Removed "Appendix C. XML Schema Considerations". o Removed "Appendix C. XML Schema Considerations".
o Removed "Appendix F. Why We Need a New Modeling Language". o Removed "Appendix F. Why We Need a New Modeling Language".
o Moved "Appendix B. YIN" to its own section. o Moved "Appendix B. YIN" to its own section.
o Moved "Appendix D. YANG ABNF Grammar" to its own section. o Moved "Appendix D. YANG ABNF Grammar" to its own section.
skipping to change at page 181, line 21 skipping to change at page 181, line 29
o Fixed whitespace issues in the ABNF grammar. o Fixed whitespace issues in the ABNF grammar.
o Added the term "mandatory node", and refer to it in the o Added the term "mandatory node", and refer to it in the
description of augment (see Section 7.15), and choice (see description of augment (see Section 7.15), and choice (see
Section 7.9.3). Section 7.9.3).
o Added support for multiple "pattern" statements in "type". o Added support for multiple "pattern" statements in "type".
o Several clarifications and fixed typos. o Several clarifications and fixed typos.
A.11. Version -00 A.13. Version -00
Changes from draft-bjorklund-netconf-yang-02.txt Changes from draft-bjorklund-netconf-yang-02.txt
o Fixed bug in grammar for bit-stmt o Fixed bug in grammar for bit-stmt
o Fixed bugs in example XPath expressions o Fixed bugs in example XPath expressions
o Added keyword 'presence' to the YIN mapping table o Added keyword 'presence' to the YIN mapping table
Author's Address Author's Address
 End of changes. 44 change blocks. 
92 lines changed or deleted 108 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/