draft-ietf-netmod-rfc6020bis-09.txt   draft-ietf-netmod-rfc6020bis-10.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 December 11, 2015 Intended status: Standards Track February 4, 2016
Expires: June 13, 2016 Expires: August 7, 2016
The YANG 1.1 Data Modeling Language The YANG 1.1 Data Modeling Language
draft-ietf-netmod-rfc6020bis-09 draft-ietf-netmod-rfc6020bis-10
Abstract Abstract
YANG is a data modeling language used to model configuration data, YANG is a data modeling language used to model configuration data,
state data, remote procedure calls, and notifications for network state data, remote procedure calls, and notifications for network
management protocols like the Network Configuration Protocol management protocols like the Network Configuration Protocol
(NETCONF). (NETCONF).
Status of This Memo Status of This Memo
skipping to change at page 1, line 33 skipping to change at page 1, line 33
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 13, 2016. This Internet-Draft will expire on August 7, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 20 skipping to change at page 2, line 20
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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 8
1.1. Summary of Changes from RFC 6020 . . . . . . . . . . . . 9 1.1. Summary of Changes from RFC 6020 . . . . . . . . . . . . 8
2. Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2. Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 10 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 10
4. YANG Overview . . . . . . . . . . . . . . . . . . . . . . . . 13 4. YANG Overview . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1. Functional Overview . . . . . . . . . . . . . . . . . . . 13 4.1. Functional Overview . . . . . . . . . . . . . . . . . . . 13
4.2. Language Overview . . . . . . . . . . . . . . . . . . . . 15 4.2. Language Overview . . . . . . . . . . . . . . . . . . . . 15
4.2.1. Modules and Submodules . . . . . . . . . . . . . . . 15 4.2.1. Modules and Submodules . . . . . . . . . . . . . . . 15
4.2.2. Data Modeling Basics . . . . . . . . . . . . . . . . 16 4.2.2. Data Modeling Basics . . . . . . . . . . . . . . . . 16
4.2.3. State Data . . . . . . . . . . . . . . . . . . . . . 19 4.2.3. State Data . . . . . . . . . . . . . . . . . . . . . 19
4.2.4. Built-In Types . . . . . . . . . . . . . . . . . . . 20 4.2.4. Built-In Types . . . . . . . . . . . . . . . . . . . 20
4.2.5. Derived Types (typedef) . . . . . . . . . . . . . . . 21 4.2.5. Derived Types (typedef) . . . . . . . . . . . . . . . 21
4.2.6. Reusable Node Groups (grouping) . . . . . . . . . . . 22 4.2.6. Reusable Node Groups (grouping) . . . . . . . . . . . 22
4.2.7. Choices . . . . . . . . . . . . . . . . . . . . . . . 23 4.2.7. Choices . . . . . . . . . . . . . . . . . . . . . . . 23
4.2.8. Extending Data Models (augment) . . . . . . . . . . . 24 4.2.8. Extending Data Models (augment) . . . . . . . . . . . 24
4.2.9. Operation Definitions . . . . . . . . . . . . . . . . 25 4.2.9. Operation Definitions . . . . . . . . . . . . . . . . 25
4.2.10. Notification Definitions . . . . . . . . . . . . . . 27 4.2.10. Notification Definitions . . . . . . . . . . . . . . 28
5. Language Concepts . . . . . . . . . . . . . . . . . . . . . . 28 5. Language Concepts . . . . . . . . . . . . . . . . . . . . . . 28
5.1. Modules and Submodules . . . . . . . . . . . . . . . . . 28 5.1. Modules and Submodules . . . . . . . . . . . . . . . . . 28
5.1.1. Import and Include by Revision . . . . . . . . . . . 29 5.1.1. Import and Include by Revision . . . . . . . . . . . 29
5.1.2. Module Hierarchies . . . . . . . . . . . . . . . . . 30 5.1.2. Module Hierarchies . . . . . . . . . . . . . . . . . 31
5.2. File Layout . . . . . . . . . . . . . . . . . . . . . . . 31 5.2. File Layout . . . . . . . . . . . . . . . . . . . . . . . 32
5.3. XML Namespaces . . . . . . . . . . . . . . . . . . . . . 32 5.3. XML Namespaces . . . . . . . . . . . . . . . . . . . . . 32
5.3.1. YANG XML Namespace . . . . . . . . . . . . . . . . . 32 5.3.1. YANG XML Namespace . . . . . . . . . . . . . . . . . 32
5.4. Resolving Grouping, Type, and Identity Names . . . . . . 32 5.4. Resolving Grouping, Type, and Identity Names . . . . . . 32
5.5. Nested Typedefs and Groupings . . . . . . . . . . . . . . 32 5.5. Nested Typedefs and Groupings . . . . . . . . . . . . . . 33
5.6. Conformance . . . . . . . . . . . . . . . . . . . . . . . 33 5.6. Conformance . . . . . . . . . . . . . . . . . . . . . . . 33
5.6.1. Basic Behavior . . . . . . . . . . . . . . . . . . . 33 5.6.1. Basic Behavior . . . . . . . . . . . . . . . . . . . 34
5.6.2. Optional Features . . . . . . . . . . . . . . . . . . 34 5.6.2. Optional Features . . . . . . . . . . . . . . . . . . 34
5.6.3. Deviations . . . . . . . . . . . . . . . . . . . . . 34 5.6.3. Deviations . . . . . . . . . . . . . . . . . . . . . 34
5.6.4. Implementing a Module . . . . . . . . . . . . . . . . 35 5.6.4. Implementing a Module . . . . . . . . . . . . . . . . 35
5.6.5. Announcing Conformance Information in NETCONF . . . . 37 5.6.5. Announcing Conformance Information in NETCONF . . . . 38
5.7. Datastore Modification . . . . . . . . . . . . . . . . . 38 5.7. Datastore Modification . . . . . . . . . . . . . . . . . 39
6. YANG Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 38 6. YANG Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.1. Lexical Tokenization . . . . . . . . . . . . . . . . . . 39 6.1. Lexical Tokenization . . . . . . . . . . . . . . . . . . 39
6.1.1. Comments . . . . . . . . . . . . . . . . . . . . . . 39 6.1.1. Comments . . . . . . . . . . . . . . . . . . . . . . 39
6.1.2. Tokens . . . . . . . . . . . . . . . . . . . . . . . 39 6.1.2. Tokens . . . . . . . . . . . . . . . . . . . . . . . 40
6.1.3. Quoting . . . . . . . . . . . . . . . . . . . . . . . 39 6.1.3. Quoting . . . . . . . . . . . . . . . . . . . . . . . 40
6.2. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 41 6.2. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 41
6.2.1. Identifiers and Their Namespaces . . . . . . . . . . 41 6.2.1. Identifiers and Their Namespaces . . . . . . . . . . 42
6.3. Statements . . . . . . . . . . . . . . . . . . . . . . . 42 6.3. Statements . . . . . . . . . . . . . . . . . . . . . . . 43
6.3.1. Language Extensions . . . . . . . . . . . . . . . . . 42 6.3.1. Language Extensions . . . . . . . . . . . . . . . . . 43
6.4. XPath Evaluations . . . . . . . . . . . . . . . . . . . . 42 6.4. XPath Evaluations . . . . . . . . . . . . . . . . . . . . 43
6.4.1. XPath Context . . . . . . . . . . . . . . . . . . . . 43 6.4.1. XPath Context . . . . . . . . . . . . . . . . . . . . 44
6.5. Schema Node Identifier . . . . . . . . . . . . . . . . . 48 6.5. Schema Node Identifier . . . . . . . . . . . . . . . . . 49
7. YANG Statements . . . . . . . . . . . . . . . . . . . . . . . 48 7. YANG Statements . . . . . . . . . . . . . . . . . . . . . . . 49
7.1. The module Statement . . . . . . . . . . . . . . . . . . 49 7.1. The module Statement . . . . . . . . . . . . . . . . . . 50
7.1.1. The module's Substatements . . . . . . . . . . . . . 49 7.1.1. The module's Substatements . . . . . . . . . . . . . 50
7.1.2. The yang-version Statement . . . . . . . . . . . . . 50 7.1.2. The yang-version Statement . . . . . . . . . . . . . 51
7.1.3. The namespace Statement . . . . . . . . . . . . . . . 51 7.1.3. The namespace Statement . . . . . . . . . . . . . . . 52
7.1.4. The prefix Statement . . . . . . . . . . . . . . . . 51 7.1.4. The prefix Statement . . . . . . . . . . . . . . . . 52
7.1.5. The import Statement . . . . . . . . . . . . . . . . 51 7.1.5. The import Statement . . . . . . . . . . . . . . . . 52
7.1.6. The include Statement . . . . . . . . . . . . . . . . 52 7.1.6. The include Statement . . . . . . . . . . . . . . . . 54
7.1.7. The organization Statement . . . . . . . . . . . . . 53 7.1.7. The organization Statement . . . . . . . . . . . . . 54
7.1.8. The contact Statement . . . . . . . . . . . . . . . . 53 7.1.8. The contact Statement . . . . . . . . . . . . . . . . 54
7.1.9. The revision Statement . . . . . . . . . . . . . . . 53 7.1.9. The revision Statement . . . . . . . . . . . . . . . 55
7.1.10. Usage Example . . . . . . . . . . . . . . . . . . . . 54 7.1.10. Usage Example . . . . . . . . . . . . . . . . . . . . 55
7.2. The submodule Statement . . . . . . . . . . . . . . . . . 55 7.2. The submodule Statement . . . . . . . . . . . . . . . . . 56
7.2.1. The submodule's Substatements . . . . . . . . . . . . 56 7.2.1. The submodule's Substatements . . . . . . . . . . . . 57
7.2.2. The belongs-to Statement . . . . . . . . . . . . . . 56 7.2.2. The belongs-to Statement . . . . . . . . . . . . . . 58
7.2.3. Usage Example . . . . . . . . . . . . . . . . . . . . 57 7.2.3. Usage Example . . . . . . . . . . . . . . . . . . . . 59
7.3. The typedef Statement . . . . . . . . . . . . . . . . . . 57 7.3. The typedef Statement . . . . . . . . . . . . . . . . . . 59
7.3.1. The typedef's Substatements . . . . . . . . . . . . . 58 7.3.1. The typedef's Substatements . . . . . . . . . . . . . 60
7.3.2. The typedef's type Statement . . . . . . . . . . . . 58 7.3.2. The typedef's type Statement . . . . . . . . . . . . 60
7.3.3. The units Statement . . . . . . . . . . . . . . . . . 58 7.3.3. The units Statement . . . . . . . . . . . . . . . . . 60
7.3.4. The typedef's default Statement . . . . . . . . . . . 58 7.3.4. The typedef's default Statement . . . . . . . . . . . 60
7.3.5. Usage Example . . . . . . . . . . . . . . . . . . . . 59 7.3.5. Usage Example . . . . . . . . . . . . . . . . . . . . 61
7.4. The type Statement . . . . . . . . . . . . . . . . . . . 59 7.4. The type Statement . . . . . . . . . . . . . . . . . . . 61
7.4.1. The type's Substatements . . . . . . . . . . . . . . 59 7.4.1. The type's Substatements . . . . . . . . . . . . . . 61
7.5. The container Statement . . . . . . . . . . . . . . . . . 59 7.5. The container Statement . . . . . . . . . . . . . . . . . 61
7.5.1. Containers with Presence . . . . . . . . . . . . . . 60 7.5.1. Containers with Presence . . . . . . . . . . . . . . 62
7.5.2. The container's Substatements . . . . . . . . . . . . 60 7.5.2. The container's Substatements . . . . . . . . . . . . 62
7.5.3. The must Statement . . . . . . . . . . . . . . . . . 61 7.5.3. The must Statement . . . . . . . . . . . . . . . . . 63
7.5.4. The must's Substatements . . . . . . . . . . . . . . 62 7.5.4. The must's Substatements . . . . . . . . . . . . . . 64
7.5.5. The presence Statement . . . . . . . . . . . . . . . 63 7.5.5. The presence Statement . . . . . . . . . . . . . . . 65
7.5.6. The container's Child Node Statements . . . . . . . . 63 7.5.6. The container's Child Node Statements . . . . . . . . 65
7.5.7. XML Encoding Rules . . . . . . . . . . . . . . . . . 63 7.5.7. XML Encoding Rules . . . . . . . . . . . . . . . . . 65
7.5.8. NETCONF <edit-config> Operations . . . . . . . . . . 64 7.5.8. NETCONF <edit-config> Operations . . . . . . . . . . 66
7.5.9. Usage Example . . . . . . . . . . . . . . . . . . . . 64 7.5.9. Usage Example . . . . . . . . . . . . . . . . . . . . 66
7.6. The leaf Statement . . . . . . . . . . . . . . . . . . . 65 7.6. The leaf Statement . . . . . . . . . . . . . . . . . . . 67
7.6.1. The leaf's default value . . . . . . . . . . . . . . 65 7.6.1. The leaf's default value . . . . . . . . . . . . . . 67
7.6.2. The leaf's Substatements . . . . . . . . . . . . . . 66 7.6.2. The leaf's Substatements . . . . . . . . . . . . . . 68
7.6.3. The leaf's type Statement . . . . . . . . . . . . . . 67 7.6.3. The leaf's type Statement . . . . . . . . . . . . . . 69
7.6.4. The leaf's default Statement . . . . . . . . . . . . 67 7.6.4. The leaf's default Statement . . . . . . . . . . . . 69
7.6.5. The leaf's mandatory Statement . . . . . . . . . . . 67 7.6.5. The leaf's mandatory Statement . . . . . . . . . . . 69
7.6.6. XML Encoding Rules . . . . . . . . . . . . . . . . . 68 7.6.6. XML Encoding Rules . . . . . . . . . . . . . . . . . 70
7.6.7. NETCONF <edit-config> Operations . . . . . . . . . . 68 7.6.7. NETCONF <edit-config> Operations . . . . . . . . . . 70
7.6.8. Usage Example . . . . . . . . . . . . . . . . . . . . 68 7.6.8. Usage Example . . . . . . . . . . . . . . . . . . . . 70
7.7. The leaf-list Statement . . . . . . . . . . . . . . . . . 69 7.7. The leaf-list Statement . . . . . . . . . . . . . . . . . 71
7.7.1. Ordering . . . . . . . . . . . . . . . . . . . . . . 69 7.7.1. Ordering . . . . . . . . . . . . . . . . . . . . . . 71
7.7.2. The leaf-list's default values . . . . . . . . . . . 70 7.7.2. The leaf-list's default values . . . . . . . . . . . 72
7.7.3. The leaf-list's Substatements . . . . . . . . . . . . 71 7.7.3. The leaf-list's Substatements . . . . . . . . . . . . 73
7.7.4. The leaf-list's default Statement . . . . . . . . . . 71 7.7.4. The leaf-list's default Statement . . . . . . . . . . 73
7.7.5. The min-elements Statement . . . . . . . . . . . . . 72 7.7.5. The min-elements Statement . . . . . . . . . . . . . 74
7.7.6. The max-elements Statement . . . . . . . . . . . . . 72 7.7.6. The max-elements Statement . . . . . . . . . . . . . 74
7.7.7. The ordered-by Statement . . . . . . . . . . . . . . 72 7.7.7. The ordered-by Statement . . . . . . . . . . . . . . 74
7.7.8. XML Encoding Rules . . . . . . . . . . . . . . . . . 73 7.7.8. XML Encoding Rules . . . . . . . . . . . . . . . . . 75
7.7.9. NETCONF <edit-config> Operations . . . . . . . . . . 73 7.7.9. NETCONF <edit-config> Operations . . . . . . . . . . 75
7.7.10. Usage Example . . . . . . . . . . . . . . . . . . . . 74 7.7.10. Usage Example . . . . . . . . . . . . . . . . . . . . 76
7.8. The list Statement . . . . . . . . . . . . . . . . . . . 76 7.8. The list Statement . . . . . . . . . . . . . . . . . . . 78
7.8.1. The list's Substatements . . . . . . . . . . . . . . 76 7.8.1. The list's Substatements . . . . . . . . . . . . . . 78
7.8.2. The list's key Statement . . . . . . . . . . . . . . 77 7.8.2. The list's key Statement . . . . . . . . . . . . . . 79
7.8.3. The list's unique Statement . . . . . . . . . . . . . 78 7.8.3. The list's unique Statement . . . . . . . . . . . . . 80
7.8.4. The list's Child Node Statements . . . . . . . . . . 79 7.8.4. The list's Child Node Statements . . . . . . . . . . 81
7.8.5. XML Encoding Rules . . . . . . . . . . . . . . . . . 79 7.8.5. XML Encoding Rules . . . . . . . . . . . . . . . . . 81
7.8.6. NETCONF <edit-config> Operations . . . . . . . . . . 80 7.8.6. NETCONF <edit-config> Operations . . . . . . . . . . 82
7.8.7. Usage Example . . . . . . . . . . . . . . . . . . . . 81 7.8.7. Usage Example . . . . . . . . . . . . . . . . . . . . 83
7.9. The choice Statement . . . . . . . . . . . . . . . . . . 84 7.9. The choice Statement . . . . . . . . . . . . . . . . . . 86
7.9.1. The choice's Substatements . . . . . . . . . . . . . 84 7.9.1. The choice's Substatements . . . . . . . . . . . . . 86
7.9.2. The choice's case Statement . . . . . . . . . . . . . 85 7.9.2. The choice's case Statement . . . . . . . . . . . . . 87
7.9.3. The choice's default Statement . . . . . . . . . . . 86 7.9.3. The choice's default Statement . . . . . . . . . . . 88
7.9.4. The choice's mandatory Statement . . . . . . . . . . 88 7.9.4. The choice's mandatory Statement . . . . . . . . . . 90
7.9.5. XML Encoding Rules . . . . . . . . . . . . . . . . . 88 7.9.5. XML Encoding Rules . . . . . . . . . . . . . . . . . 90
7.9.6. Usage Example . . . . . . . . . . . . . . . . . . . . 88 7.9.6. Usage Example . . . . . . . . . . . . . . . . . . . . 90
7.10. The anydata Statement . . . . . . . . . . . . . . . . . . 89 7.10. The anydata Statement . . . . . . . . . . . . . . . . . . 91
7.10.1. The anydata's Substatements . . . . . . . . . . . . 90 7.10.1. The anydata's Substatements . . . . . . . . . . . . 92
7.10.2. XML Encoding Rules . . . . . . . . . . . . . . . . . 90 7.10.2. XML Encoding Rules . . . . . . . . . . . . . . . . . 92
7.10.3. NETCONF <edit-config> Operations . . . . . . . . . . 90 7.10.3. NETCONF <edit-config> Operations . . . . . . . . . . 92
7.10.4. Usage Example . . . . . . . . . . . . . . . . . . . 91 7.10.4. Usage Example . . . . . . . . . . . . . . . . . . . 93
7.11. The anyxml Statement . . . . . . . . . . . . . . . . . . 91 7.11. The anyxml Statement . . . . . . . . . . . . . . . . . . 93
7.11.1. The anyxml's Substatements . . . . . . . . . . . . . 92 7.11.1. The anyxml's Substatements . . . . . . . . . . . . . 94
7.11.2. XML Encoding Rules . . . . . . . . . . . . . . . . . 92 7.11.2. XML Encoding Rules . . . . . . . . . . . . . . . . . 94
7.11.3. NETCONF <edit-config> Operations . . . . . . . . . . 92 7.11.3. NETCONF <edit-config> Operations . . . . . . . . . . 94
7.11.4. Usage Example . . . . . . . . . . . . . . . . . . . 93 7.11.4. Usage Example . . . . . . . . . . . . . . . . . . . 95
7.12. The grouping Statement . . . . . . . . . . . . . . . . . 93 7.12. The grouping Statement . . . . . . . . . . . . . . . . . 95
7.12.1. The grouping's Substatements . . . . . . . . . . . . 94 7.12.1. The grouping's Substatements . . . . . . . . . . . . 96
7.12.2. Usage Example . . . . . . . . . . . . . . . . . . . 95 7.12.2. Usage Example . . . . . . . . . . . . . . . . . . . 97
7.13. The uses Statement . . . . . . . . . . . . . . . . . . . 95 7.13. The uses Statement . . . . . . . . . . . . . . . . . . . 97
7.13.1. The uses's Substatements . . . . . . . . . . . . . . 95 7.13.1. The uses's Substatements . . . . . . . . . . . . . . 97
7.13.2. The refine Statement . . . . . . . . . . . . . . . . 96 7.13.2. The refine Statement . . . . . . . . . . . . . . . . 98
7.13.3. XML Encoding Rules . . . . . . . . . . . . . . . . . 97 7.13.3. XML Encoding Rules . . . . . . . . . . . . . . . . . 99
7.13.4. Usage Example . . . . . . . . . . . . . . . . . . . 97 7.13.4. Usage Example . . . . . . . . . . . . . . . . . . . 99
7.14. The rpc Statement . . . . . . . . . . . . . . . . . . . . 98 7.14. The rpc Statement . . . . . . . . . . . . . . . . . . . . 100
7.14.1. The rpc's Substatements . . . . . . . . . . . . . . 98 7.14.1. The rpc's Substatements . . . . . . . . . . . . . . 100
7.14.2. The input Statement . . . . . . . . . . . . . . . . 99 7.14.2. The input Statement . . . . . . . . . . . . . . . . 101
7.14.3. The output Statement . . . . . . . . . . . . . . . . 100 7.14.3. The output Statement . . . . . . . . . . . . . . . . 102
7.14.4. NETCONF XML Encoding Rules . . . . . . . . . . . . . 101 7.14.4. NETCONF XML Encoding Rules . . . . . . . . . . . . . 103
7.14.5. Usage Example . . . . . . . . . . . . . . . . . . . 101 7.14.5. Usage Example . . . . . . . . . . . . . . . . . . . 103
7.15. The action Statement . . . . . . . . . . . . . . . . . . 102 7.15. The action Statement . . . . . . . . . . . . . . . . . . 104
7.15.1. The action's Substatements . . . . . . . . . . . . . 102 7.15.1. The action's Substatements . . . . . . . . . . . . . 104
7.15.2. NETCONF XML Encoding Rules . . . . . . . . . . . . . 103 7.15.2. NETCONF XML Encoding Rules . . . . . . . . . . . . . 105
7.15.3. Usage Example . . . . . . . . . . . . . . . . . . . 103 7.15.3. Usage Example . . . . . . . . . . . . . . . . . . . 105
7.16. The notification Statement . . . . . . . . . . . . . . . 105 7.16. The notification Statement . . . . . . . . . . . . . . . 107
7.16.1. The notification's Substatements . . . . . . . . . . 106 7.16.1. The notification's Substatements . . . . . . . . . . 108
7.16.2. NETCONF XML Encoding Rules . . . . . . . . . . . . . 106 7.16.2. NETCONF XML Encoding Rules . . . . . . . . . . . . . 108
7.16.3. Usage Example . . . . . . . . . . . . . . . . . . . 107 7.16.3. Usage Example . . . . . . . . . . . . . . . . . . . 109
7.17. The augment Statement . . . . . . . . . . . . . . . . . . 108 7.17. The augment Statement . . . . . . . . . . . . . . . . . . 110
7.17.1. The augment's Substatements . . . . . . . . . . . . 110 7.17.1. The augment's Substatements . . . . . . . . . . . . 112
7.17.2. XML Encoding Rules . . . . . . . . . . . . . . . . . 111 7.17.2. XML Encoding Rules . . . . . . . . . . . . . . . . . 113
7.17.3. Usage Example . . . . . . . . . . . . . . . . . . . 111 7.17.3. Usage Example . . . . . . . . . . . . . . . . . . . 113
7.18. The identity Statement . . . . . . . . . . . . . . . . . 113 7.18. The identity Statement . . . . . . . . . . . . . . . . . 115
7.18.1. The identity's Substatements . . . . . . . . . . . . 113 7.18.1. The identity's Substatements . . . . . . . . . . . . 115
7.18.2. The base Statement . . . . . . . . . . . . . . . . . 113 7.18.2. The base Statement . . . . . . . . . . . . . . . . . 115
7.18.3. Usage Example . . . . . . . . . . . . . . . . . . . 114 7.18.3. Usage Example . . . . . . . . . . . . . . . . . . . 116
7.19. The extension Statement . . . . . . . . . . . . . . . . . 115 7.19. The extension Statement . . . . . . . . . . . . . . . . . 118
7.19.1. The extension's Substatements . . . . . . . . . . . 115 7.19.1. The extension's Substatements . . . . . . . . . . . 118
7.19.2. The argument Statement . . . . . . . . . . . . . . . 115 7.19.2. The argument Statement . . . . . . . . . . . . . . . 118
7.19.3. Usage Example . . . . . . . . . . . . . . . . . . . 116 7.19.3. Usage Example . . . . . . . . . . . . . . . . . . . 119
7.20. Conformance-Related Statements . . . . . . . . . . . . . 117 7.20. Conformance-Related Statements . . . . . . . . . . . . . 120
7.20.1. The feature Statement . . . . . . . . . . . . . . . 117 7.20.1. The feature Statement . . . . . . . . . . . . . . . 120
7.20.2. The if-feature Statement . . . . . . . . . . . . . . 119 7.20.2. The if-feature Statement . . . . . . . . . . . . . . 122
7.20.3. The deviation Statement . . . . . . . . . . . . . . 119 7.20.3. The deviation Statement . . . . . . . . . . . . . . 122
7.21. Common Statements . . . . . . . . . . . . . . . . . . . . 123 7.21. Common Statements . . . . . . . . . . . . . . . . . . . . 126
7.21.1. The config Statement . . . . . . . . . . . . . . . . 123 7.21.1. The config Statement . . . . . . . . . . . . . . . . 126
7.21.2. The status Statement . . . . . . . . . . . . . . . . 123 7.21.2. The status Statement . . . . . . . . . . . . . . . . 126
7.21.3. The description Statement . . . . . . . . . . . . . 124 7.21.3. The description Statement . . . . . . . . . . . . . 127
7.21.4. The reference Statement . . . . . . . . . . . . . . 124 7.21.4. The reference Statement . . . . . . . . . . . . . . 127
7.21.5. The when Statement . . . . . . . . . . . . . . . . . 124 7.21.5. The when Statement . . . . . . . . . . . . . . . . . 128
8. Constraints . . . . . . . . . . . . . . . . . . . . . . . . . 126 8. Constraints . . . . . . . . . . . . . . . . . . . . . . . . . 129
8.1. Constraints on Data . . . . . . . . . . . . . . . . . . . 126 8.1. Constraints on Data . . . . . . . . . . . . . . . . . . . 129
8.2. Configuration Data Modifications . . . . . . . . . . . . 127 8.2. Configuration Data Modifications . . . . . . . . . . . . 130
8.3. NETCONF Constraint Enforcement Model . . . . . . . . . . 127 8.3. NETCONF Constraint Enforcement Model . . . . . . . . . . 130
8.3.1. Payload Parsing . . . . . . . . . . . . . . . . . . . 127 8.3.1. Payload Parsing . . . . . . . . . . . . . . . . . . . 130
8.3.2. NETCONF <edit-config> Processing . . . . . . . . . . 128 8.3.2. NETCONF <edit-config> Processing . . . . . . . . . . 131
8.3.3. Validation . . . . . . . . . . . . . . . . . . . . . 128 8.3.3. Validation . . . . . . . . . . . . . . . . . . . . . 132
9. Built-In Types . . . . . . . . . . . . . . . . . . . . . . . 129 9. Built-In Types . . . . . . . . . . . . . . . . . . . . . . . 132
9.1. Canonical Representation . . . . . . . . . . . . . . . . 129 9.1. Canonical Representation . . . . . . . . . . . . . . . . 132
9.2. The Integer Built-In Types . . . . . . . . . . . . . . . 129 9.2. The Integer Built-In Types . . . . . . . . . . . . . . . 133
9.2.1. Lexical Representation . . . . . . . . . . . . . . . 130 9.2.1. Lexical Representation . . . . . . . . . . . . . . . 133
9.2.2. Canonical Form . . . . . . . . . . . . . . . . . . . 131 9.2.2. Canonical Form . . . . . . . . . . . . . . . . . . . 134
9.2.3. Restrictions . . . . . . . . . . . . . . . . . . . . 131 9.2.3. Restrictions . . . . . . . . . . . . . . . . . . . . 134
9.2.4. The range Statement . . . . . . . . . . . . . . . . . 131 9.2.4. The range Statement . . . . . . . . . . . . . . . . . 134
9.2.5. Usage Example . . . . . . . . . . . . . . . . . . . . 132 9.2.5. Usage Example . . . . . . . . . . . . . . . . . . . . 135
9.3. The decimal64 Built-In Type . . . . . . . . . . . . . . . 132 9.3. The decimal64 Built-In Type . . . . . . . . . . . . . . . 135
9.3.1. Lexical Representation . . . . . . . . . . . . . . . 132 9.3.1. Lexical Representation . . . . . . . . . . . . . . . 136
9.3.2. Canonical Form . . . . . . . . . . . . . . . . . . . 133 9.3.2. Canonical Form . . . . . . . . . . . . . . . . . . . 136
9.3.3. Restrictions . . . . . . . . . . . . . . . . . . . . 133 9.3.3. Restrictions . . . . . . . . . . . . . . . . . . . . 136
9.3.4. The fraction-digits Statement . . . . . . . . . . . . 133 9.3.4. The fraction-digits Statement . . . . . . . . . . . . 136
9.3.5. Usage Example . . . . . . . . . . . . . . . . . . . . 134 9.3.5. Usage Example . . . . . . . . . . . . . . . . . . . . 137
9.4. The string Built-In Type . . . . . . . . . . . . . . . . 134 9.4. The string Built-In Type . . . . . . . . . . . . . . . . 137
9.4.1. Lexical Representation . . . . . . . . . . . . . . . 134 9.4.1. Lexical Representation . . . . . . . . . . . . . . . 137
9.4.2. Canonical Form . . . . . . . . . . . . . . . . . . . 134 9.4.2. Canonical Form . . . . . . . . . . . . . . . . . . . 138
9.4.3. Restrictions . . . . . . . . . . . . . . . . . . . . 134 9.4.3. Restrictions . . . . . . . . . . . . . . . . . . . . 138
9.4.4. The length Statement . . . . . . . . . . . . . . . . 134 9.4.4. The length Statement . . . . . . . . . . . . . . . . 138
9.4.5. The pattern Statement . . . . . . . . . . . . . . . . 135 9.4.5. The pattern Statement . . . . . . . . . . . . . . . . 139
9.4.6. The modifier Statement . . . . . . . . . . . . . . . 136 9.4.6. The modifier Statement . . . . . . . . . . . . . . . 139
9.4.7. Usage Example . . . . . . . . . . . . . . . . . . . . 136 9.4.7. Usage Example . . . . . . . . . . . . . . . . . . . . 139
9.5. The boolean Built-In Type . . . . . . . . . . . . . . . . 137 9.5. The boolean Built-In Type . . . . . . . . . . . . . . . . 141
9.5.1. Lexical Representation . . . . . . . . . . . . . . . 137 9.5.1. Lexical Representation . . . . . . . . . . . . . . . 141
9.5.2. Canonical Form . . . . . . . . . . . . . . . . . . . 137 9.5.2. Canonical Form . . . . . . . . . . . . . . . . . . . 141
9.5.3. Restrictions . . . . . . . . . . . . . . . . . . . . 138 9.5.3. Restrictions . . . . . . . . . . . . . . . . . . . . 141
9.6. The enumeration Built-In Type . . . . . . . . . . . . . . 138 9.6. The enumeration Built-In Type . . . . . . . . . . . . . . 141
9.6.1. Lexical Representation . . . . . . . . . . . . . . . 138 9.6.1. Lexical Representation . . . . . . . . . . . . . . . 141
9.6.2. Canonical Form . . . . . . . . . . . . . . . . . . . 138 9.6.2. Canonical Form . . . . . . . . . . . . . . . . . . . 141
9.6.3. Restrictions . . . . . . . . . . . . . . . . . . . . 138 9.6.3. Restrictions . . . . . . . . . . . . . . . . . . . . 141
9.6.4. The enum Statement . . . . . . . . . . . . . . . . . 138 9.6.4. The enum Statement . . . . . . . . . . . . . . . . . 141
9.6.5. Usage Example . . . . . . . . . . . . . . . . . . . . 139 9.6.5. Usage Example . . . . . . . . . . . . . . . . . . . . 143
9.7. The bits Built-In Type . . . . . . . . . . . . . . . . . 141 9.7. The bits Built-In Type . . . . . . . . . . . . . . . . . 144
9.7.1. Restrictions . . . . . . . . . . . . . . . . . . . . 141 9.7.1. Restrictions . . . . . . . . . . . . . . . . . . . . 144
9.7.2. Lexical Representation . . . . . . . . . . . . . . . 141 9.7.2. Lexical Representation . . . . . . . . . . . . . . . 144
9.7.3. Canonical Form . . . . . . . . . . . . . . . . . . . 141 9.7.3. Canonical Form . . . . . . . . . . . . . . . . . . . 145
9.7.4. The bit Statement . . . . . . . . . . . . . . . . . . 141 9.7.4. The bit Statement . . . . . . . . . . . . . . . . . . 145
9.7.5. Usage Example . . . . . . . . . . . . . . . . . . . . 142 9.7.5. Usage Example . . . . . . . . . . . . . . . . . . . . 146
9.8. The binary Built-In Type . . . . . . . . . . . . . . . . 144 9.8. The binary Built-In Type . . . . . . . . . . . . . . . . 147
9.8.1. Restrictions . . . . . . . . . . . . . . . . . . . . 144 9.8.1. Restrictions . . . . . . . . . . . . . . . . . . . . 147
9.8.2. Lexical Representation . . . . . . . . . . . . . . . 144 9.8.2. Lexical Representation . . . . . . . . . . . . . . . 147
9.8.3. Canonical Form . . . . . . . . . . . . . . . . . . . 144 9.8.3. Canonical Form . . . . . . . . . . . . . . . . . . . 147
9.9. The leafref Built-In Type . . . . . . . . . . . . . . . . 144 9.9. The leafref Built-In Type . . . . . . . . . . . . . . . . 147
9.9.1. Restrictions . . . . . . . . . . . . . . . . . . . . 144 9.9.1. Restrictions . . . . . . . . . . . . . . . . . . . . 148
9.9.2. The path Statement . . . . . . . . . . . . . . . . . 145 9.9.2. The path Statement . . . . . . . . . . . . . . . . . 148
9.9.3. The require-instance Statement . . . . . . . . . . . 145 9.9.3. The require-instance Statement . . . . . . . . . . . 148
9.9.4. Lexical Representation . . . . . . . . . . . . . . . 146 9.9.4. Lexical Representation . . . . . . . . . . . . . . . 149
9.9.5. Canonical Form . . . . . . . . . . . . . . . . . . . 146 9.9.5. Canonical Form . . . . . . . . . . . . . . . . . . . 149
9.9.6. Usage Example . . . . . . . . . . . . . . . . . . . . 146 9.9.6. Usage Example . . . . . . . . . . . . . . . . . . . . 149
9.10. The identityref Built-In Type . . . . . . . . . . . . . . 149 9.10. The identityref Built-In Type . . . . . . . . . . . . . . 153
9.10.1. Restrictions . . . . . . . . . . . . . . . . . . . . 149 9.10.1. Restrictions . . . . . . . . . . . . . . . . . . . . 153
9.10.2. The identityref's base Statement . . . . . . . . . . 149 9.10.2. The identityref's base Statement . . . . . . . . . . 153
9.10.3. Lexical Representation . . . . . . . . . . . . . . . 150 9.10.3. Lexical Representation . . . . . . . . . . . . . . . 153
9.10.4. Canonical Form . . . . . . . . . . . . . . . . . . . 150 9.10.4. Canonical Form . . . . . . . . . . . . . . . . . . . 154
9.10.5. Usage Example . . . . . . . . . . . . . . . . . . . 150 9.10.5. Usage Example . . . . . . . . . . . . . . . . . . . 154
9.11. The empty Built-In Type . . . . . . . . . . . . . . . . . 152 9.11. The empty Built-In Type . . . . . . . . . . . . . . . . . 155
9.11.1. Restrictions . . . . . . . . . . . . . . . . . . . . 152 9.11.1. Restrictions . . . . . . . . . . . . . . . . . . . . 155
9.11.2. Lexical Representation . . . . . . . . . . . . . . . 152 9.11.2. Lexical Representation . . . . . . . . . . . . . . . 155
9.11.3. Canonical Form . . . . . . . . . . . . . . . . . . . 152 9.11.3. Canonical Form . . . . . . . . . . . . . . . . . . . 155
9.11.4. Usage Example . . . . . . . . . . . . . . . . . . . 152 9.11.4. Usage Example . . . . . . . . . . . . . . . . . . . 155
9.12. The union Built-In Type . . . . . . . . . . . . . . . . . 152 9.12. The union Built-In Type . . . . . . . . . . . . . . . . . 156
9.12.1. Restrictions . . . . . . . . . . . . . . . . . . . . 153 9.12.1. Restrictions . . . . . . . . . . . . . . . . . . . . 156
9.12.2. Lexical Representation . . . . . . . . . . . . . . . 153 9.12.2. Lexical Representation . . . . . . . . . . . . . . . 156
9.12.3. Canonical Form . . . . . . . . . . . . . . . . . . . 153 9.12.3. Canonical Form . . . . . . . . . . . . . . . . . . . 156
9.12.4. Usage Example . . . . . . . . . . . . . . . . . . . 153 9.12.4. Usage Example . . . . . . . . . . . . . . . . . . . 156
9.13. The instance-identifier Built-In Type . . . . . . . . . . 154 9.13. The instance-identifier Built-In Type . . . . . . . . . . 157
9.13.1. Restrictions . . . . . . . . . . . . . . . . . . . . 155 9.13.1. Restrictions . . . . . . . . . . . . . . . . . . . . 158
9.13.2. Lexical Representation . . . . . . . . . . . . . . . 155 9.13.2. Lexical Representation . . . . . . . . . . . . . . . 158
9.13.3. Canonical Form . . . . . . . . . . . . . . . . . . . 155 9.13.3. Canonical Form . . . . . . . . . . . . . . . . . . . 158
9.13.4. Usage Example . . . . . . . . . . . . . . . . . . . 155 9.13.4. Usage Example . . . . . . . . . . . . . . . . . . . 159
10. XPath Functions . . . . . . . . . . . . . . . . . . . . . . . 156 10. XPath Functions . . . . . . . . . . . . . . . . . . . . . . . 159
10.1. Functions for Node Sets . . . . . . . . . . . . . . . . 156 10.1. Functions for Node Sets . . . . . . . . . . . . . . . . 159
10.1.1. current() . . . . . . . . . . . . . . . . . . . . . 156 10.1.1. current() . . . . . . . . . . . . . . . . . . . . . 159
10.2. Functions for Strings . . . . . . . . . . . . . . . . . 157 10.2. Functions for Strings . . . . . . . . . . . . . . . . . 160
10.2.1. re-match() . . . . . . . . . . . . . . . . . . . . . 157 10.2.1. re-match() . . . . . . . . . . . . . . . . . . . . . 160
10.3. Functions for the YANG Types "leafref" and "instance- 10.3. Functions for the YANG Types "leafref" and "instance-
identifier" . . . . . . . . . . . . . . . . . . . . . . 157 identifier" . . . . . . . . . . . . . . . . . . . . . . 161
10.3.1. deref() . . . . . . . . . . . . . . . . . . . . . . 157 10.3.1. deref() . . . . . . . . . . . . . . . . . . . . . . 161
10.4. Functions for the YANG Type "identityref" . . . . . . . 158 10.4. Functions for the YANG Type "identityref" . . . . . . . 162
10.4.1. derived-from() . . . . . . . . . . . . . . . . . . . 158 10.4.1. derived-from() . . . . . . . . . . . . . . . . . . . 162
10.4.2. derived-from-or-self() . . . . . . . . . . . . . . . 160 10.4.2. derived-from-or-self() . . . . . . . . . . . . . . . 163
10.5. Functions for the YANG Type "enumeration" . . . . . . . 160 10.5. Functions for the YANG Type "enumeration" . . . . . . . 164
10.5.1. enum-value() . . . . . . . . . . . . . . . . . . . . 160 10.5.1. enum-value() . . . . . . . . . . . . . . . . . . . . 164
10.6. Functions for the YANG Type "bits" . . . . . . . . . . . 161 10.6. Functions for the YANG Type "bits" . . . . . . . . . . . 165
10.6.1. bit-is-set() . . . . . . . . . . . . . . . . . . . . 161 10.6.1. bit-is-set() . . . . . . . . . . . . . . . . . . . . 165
11. Updating a Module . . . . . . . . . . . . . . . . . . . . . . 162 11. Updating a Module . . . . . . . . . . . . . . . . . . . . . . 166
12. Coexistence with YANG version 1 . . . . . . . . . . . . . . . 164 12. Coexistence with YANG version 1 . . . . . . . . . . . . . . . 168
13. YIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 13. YIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
13.1. Formal YIN Definition . . . . . . . . . . . . . . . . . 165 13.1. Formal YIN Definition . . . . . . . . . . . . . . . . . 169
13.1.1. Usage Example . . . . . . . . . . . . . . . . . . . 168 13.1.1. Usage Example . . . . . . . . . . . . . . . . . . . 172
14. YANG ABNF Grammar . . . . . . . . . . . . . . . . . . . . . . 169 14. YANG ABNF Grammar . . . . . . . . . . . . . . . . . . . . . . 173
15. NETCONF Error Responses for YANG Related Errors . . . . . . . 193 15. NETCONF Error Responses for YANG Related Errors . . . . . . . 197
15.1. Error Message for Data That Violates a unique Statement 193 15.1. Error Message for Data That Violates a unique Statement 197
15.2. Error Message for Data That Violates a max-elements 15.2. Error Message for Data That Violates a max-elements
Statement . . . . . . . . . . . . . . . . . . . . . . . 194 Statement . . . . . . . . . . . . . . . . . . . . . . . 198
15.3. Error Message for Data That Violates a min-elements 15.3. Error Message for Data That Violates a min-elements
Statement . . . . . . . . . . . . . . . . . . . . . . . 194 Statement . . . . . . . . . . . . . . . . . . . . . . . 198
15.4. Error Message for Data That Violates a must Statement . 194 15.4. Error Message for Data That Violates a must Statement . 198
15.5. Error Message for Data That Violates a require-instance 15.5. Error Message for Data That Violates a require-instance
Statement . . . . . . . . . . . . . . . . . . . . . . . 194 Statement . . . . . . . . . . . . . . . . . . . . . . . 199
15.6. Error Message for Data That Does Not Match a leafref 15.6. Error Message for Data That Violates a mandatory choice
Type . . . . . . . . . . . . . . . . . . . . . . . . . . 195 Statement . . . . . . . . . . . . . . . . . . . . . . . 199
15.7. Error Message for Data That Violates a mandatory choice 15.7. Error Message for the "insert" Operation . . . . . . . . 199
Statement . . . . . . . . . . . . . . . . . . . . . . . 195 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 199
15.8. Error Message for the "insert" Operation . . . . . . . . 195 17. Security Considerations . . . . . . . . . . . . . . . . . . . 199
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 195 18. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 200
17. Security Considerations . . . . . . . . . . . . . . . . . . . 195 19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 200
18. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 196 20. ChangeLog . . . . . . . . . . . . . . . . . . . . . . . . . . 201
19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 196 20.1. Version -10 . . . . . . . . . . . . . . . . . . . . . . 201
20. ChangeLog . . . . . . . . . . . . . . . . . . . . . . . . . . 197 20.2. Version -09 . . . . . . . . . . . . . . . . . . . . . . 201
20.1. Version -09 . . . . . . . . . . . . . . . . . . . . . . 197 20.3. Version -08 . . . . . . . . . . . . . . . . . . . . . . 201
20.2. Version -08 . . . . . . . . . . . . . . . . . . . . . . 197 20.4. Version -07 . . . . . . . . . . . . . . . . . . . . . . 201
20.3. Version -07 . . . . . . . . . . . . . . . . . . . . . . 197 20.5. Version -06 . . . . . . . . . . . . . . . . . . . . . . 201
20.4. Version -06 . . . . . . . . . . . . . . . . . . . . . . 197 20.6. Version -05 . . . . . . . . . . . . . . . . . . . . . . 202
20.5. Version -05 . . . . . . . . . . . . . . . . . . . . . . 197 20.7. Version -04 . . . . . . . . . . . . . . . . . . . . . . 202
20.6. Version -04 . . . . . . . . . . . . . . . . . . . . . . 198 20.8. Version -03 . . . . . . . . . . . . . . . . . . . . . . 202
20.7. Version -03 . . . . . . . . . . . . . . . . . . . . . . 198 20.9. Version -02 . . . . . . . . . . . . . . . . . . . . . . 202
20.8. Version -02 . . . . . . . . . . . . . . . . . . . . . . 198 20.10. Version -01 . . . . . . . . . . . . . . . . . . . . . . 203
20.9. Version -01 . . . . . . . . . . . . . . . . . . . . . . 198 20.11. Version -00 . . . . . . . . . . . . . . . . . . . . . . 203
20.10. Version -00 . . . . . . . . . . . . . . . . . . . . . . 199 21. References . . . . . . . . . . . . . . . . . . . . . . . . . 203
21. References . . . . . . . . . . . . . . . . . . . . . . . . . 199 21.1. Normative References . . . . . . . . . . . . . . . . . . 203
21.1. Normative References . . . . . . . . . . . . . . . . . . 199 21.2. Informative References . . . . . . . . . . . . . . . . . 205
21.2. Informative References . . . . . . . . . . . . . . . . . 200 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 206
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 201
1. Introduction 1. Introduction
YANG is a data modeling language originally designed to model YANG is a data modeling language originally designed to model
configuration and state data manipulated by the Network Configuration configuration and state data manipulated by the Network Configuration
Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF
notifications [RFC6241]. Since the publication of YANG version 1 notifications [RFC6241]. Since the publication of YANG version 1
[RFC6020], YANG has been used or proposed to be used for other [RFC6020], YANG has been used or proposed to be used for other
protocols (e.g., RESTCONF [I-D.ietf-netconf-restconf] and CoMI protocols (e.g., RESTCONF [I-D.ietf-netconf-restconf] and CoMI
[I-D.vanderstok-core-comi]). Further, other encodings than XML have [I-D.vanderstok-core-comi]). Further, other encodings than XML have
skipping to change at page 9, line 25 skipping to change at page 9, line 19
o Made noncharacters illegal in the built-in type "string". o Made noncharacters illegal in the built-in type "string".
o Defined the legal characters in YANG modules. o Defined the legal characters in YANG modules.
o Changed the rules for the interpretation of escaped characters in o Changed the rules for the interpretation of escaped characters in
double quoted strings. This is an backwards incompatible change double quoted strings. This is an backwards incompatible change
from YANG version 1. A module that uses a character sequence that from YANG version 1. A module that uses a character sequence that
is now illegal must change the string to match the new rules. See is now illegal must change the string to match the new rules. See
Section 6.1.3 for details. Section 6.1.3 for details.
o An unquoted string cannot contain any single or double quote
characters. This is an backwards incompatible change from YANG
version 1.
o Extended the "if-feature" syntax to be a boolean expression over o Extended the "if-feature" syntax to be a boolean expression over
feature names. feature names.
o Allow "if-feature" in "bit", "enum", and "identity". o Allow "if-feature" in "bit", "enum", and "identity".
o Allow "if-feature" in "refine". o Allow "if-feature" in "refine".
o Made "when" and "if-feature" illegal on list keys. o Made "when" and "if-feature" illegal on list keys.
o Allow "choice" as a shorthand case statement (see Section 7.9). o Allow "choice" as a shorthand case statement (see Section 7.9).
o Added a new substatement "modifier" to pattern (see o Added a new substatement "modifier" to pattern (see
Section 9.4.6). Section 9.4.6).
o Allow "must" in "input", "output", and "notification". o Allow "must" in "input", "output", and "notification".
o Allow "require-instance" in leafref.
o Allow "augment" to add conditionally mandatory nodes (see o Allow "augment" to add conditionally mandatory nodes (see
Section 7.17). Section 7.17).
o Added a set of new XPath functions in Section 10. o Added a set of new XPath functions in Section 10.
o Clarified the XPath context's tree in Section 6.4.1. o Clarified the XPath context's tree in Section 6.4.1.
o Defined the string value of an identityref in XPath expressions o Defined the string value of an identityref in XPath expressions
(see Section 9.10). (see Section 9.10).
skipping to change at page 12, line 11 skipping to change at page 12, line 11
o grouping: A reusable set of schema nodes, which may be used o grouping: A reusable set of schema nodes, which may be used
locally in the module and by other modules that import from it. locally in the module and by other modules that import from it.
The grouping statement is not a data definition statement and, as The grouping statement is not a data definition statement and, as
such, does not define any nodes in the schema tree. such, does not define any nodes in the schema tree.
o identifier: Used to identify different kinds of YANG items by o identifier: Used to identify different kinds of YANG items by
name. name.
o identity: A globally unique, abstract, and untyped name.
o instance identifier: A mechanism for identifying a particular node o instance identifier: A mechanism for identifying a particular node
in a data tree. in a data tree.
o interior node: Nodes within a hierarchy that are not leaf nodes. o interior node: Nodes within a hierarchy that are not leaf nodes.
o leaf: A data node that exists in at most one instance in the data o leaf: A data node that exists in at most one instance in the data
tree. A leaf has a value but no child nodes. tree. A leaf has a value but no child nodes.
o leaf-list: Like the leaf node but defines a set of uniquely o leaf-list: Like the leaf node but defines a set of uniquely
identifiable nodes rather than a single node. Each node has a identifiable nodes rather than a single node. Each node has a
skipping to change at page 16, line 7 skipping to change at page 16, line 13
regardless of the presence or size of its submodules. regardless of the presence or size of its submodules.
The "import" statement allows a module or submodule to reference The "import" statement allows a module or submodule to reference
material defined in other modules. material defined in other modules.
The "include" statement is used by a module to incorporate the The "include" statement is used by a module to incorporate the
contents of its submodules into the module. contents of its submodules into the module.
4.2.2. Data Modeling Basics 4.2.2. Data Modeling Basics
YANG defines four types of data nodes for data modeling. In each of YANG defines four main types of data nodes for data modeling. In
the following subsections, the examples show the YANG syntax as well each of the following subsections, the examples show the YANG syntax
as a corresponding XML encoding. as well as a corresponding XML encoding.
4.2.2.1. Leaf Nodes 4.2.2.1. Leaf Nodes
A leaf instance contains simple data like an integer or a string. It A leaf instance contains simple data like an integer or a string. It
has exactly one value of a particular type and no child nodes. has exactly one value of a particular type and no child nodes.
YANG Example: YANG Example:
leaf host-name { leaf host-name {
type string; type string;
skipping to change at page 18, line 42 skipping to change at page 18, line 42
<full-name>Rapun 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 "example-system.yang"
module acme-system { module example-system {
yang-version 1.1; yang-version 1.1;
namespace "http://acme.example.com/system"; namespace "urn:example:system";
prefix "acme"; prefix "sys";
organization "ACME Inc."; organization "Example Inc.";
contact "joe@acme.example.com"; contact "joe@example.com";
description description
"The module for entities implementing the ACME system."; "The module for entities implementing the Example system.";
revision 2007-06-09 { revision 2007-06-09 {
description "Initial revision."; description "Initial revision.";
} }
container system { container system {
leaf host-name { leaf host-name {
type string; type string;
description description
"Hostname for this system"; "Hostname for this system";
skipping to change at page 26, line 22 skipping to change at page 26, line 22
leaf status { leaf status {
type string; type string;
} }
} }
} }
NETCONF XML Example: NETCONF XML Example:
<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">
<activate-software-image xmlns="http://acme.example.com/system"> <activate-software-image xmlns="http://example.com/system">
<image-name>acmefw-2.3</image-name> <image-name>example-fw-2.3</image-name>
</activate-software-image> </activate-software-image>
</rpc> </rpc>
<rpc-reply message-id="101" <rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<status xmlns="http://acme.example.com/system"> <status xmlns="http://example.com/system">
The image acmefw-2.3 is being installed. The image example-fw-2.3 is being installed.
</status> </status>
</rpc-reply> </rpc-reply>
YANG Example: YANG Example:
list interface { list interface {
key "name"; key "name";
leaf name { leaf name {
type string; type string;
skipping to change at page 27, line 30 skipping to change at page 27, line 30
type uint8; type uint8;
} }
} }
} }
} }
NETCONF XML Example: NETCONF XML Example:
<rpc message-id="102" <rpc message-id="102"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<interface xmlns="http://acme.example.com/system"> <action xmlns="urn:ietf:params:xml:ns:yang:1">
<name>eth1</name> <interface xmlns="http://example.com/system">
<ping> <name>eth1</name>
<destination>192.0.2.1</destination> <ping>
</ping> <destination>192.0.2.1</destination>
</interface> </ping>
</interface>
</action>
</rpc> </rpc>
<rpc-reply message-id="102" <rpc-reply message-id="102"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:acme="http://acme.example.com/system"> xmlns:sys="http://example.com/system">
<acme:packet-loss>60</acme:packet-loss> <sys:packet-loss>60</sys:packet-loss>
</rpc-reply> </rpc-reply>
The "rpc" statement is covered in Section 7.14, and the "action" The "rpc" statement is covered in Section 7.14, and the "action"
statement in Section 7.15. statement in Section 7.15.
4.2.10. Notification Definitions 4.2.10. Notification Definitions
YANG allows the definition of notifications. YANG data definition YANG allows the definition of notifications. YANG data definition
statements are used to model the content of the notification. statements are used to model the content of the notification.
skipping to change at page 28, line 26 skipping to change at page 28, line 33
leaf if-oper-status { leaf if-oper-status {
type oper-status; type oper-status;
} }
} }
NETCONF XML Example: NETCONF XML Example:
<notification <notification
xmlns="urn:ietf:params:netconf:capability:notification:1.0"> xmlns="urn:ietf:params:netconf:capability:notification:1.0">
<eventTime>2007-09-01T10:00:00Z</eventTime> <eventTime>2007-09-01T10:00:00Z</eventTime>
<link-failure xmlns="http://acme.example.com/system"> <link-failure xmlns="urn:example:system">
<if-name>so-1/2/3.0</if-name> <if-name>so-1/2/3.0</if-name>
<if-admin-status>up</if-admin-status> <if-admin-status>up</if-admin-status>
<if-oper-status>down</if-oper-status> <if-oper-status>down</if-oper-status>
</link-failure> </link-failure>
</notification> </notification>
The "notification" statement is covered in Section 7.16. The "notification" statement is covered in Section 7.16.
5. Language Concepts 5. Language Concepts
skipping to change at page 30, line 16 skipping to change at page 30, line 22
For submodules, the issue is related but simpler. A module or For submodules, the issue is related but simpler. A module or
submodule that includes submodules needs to specify the revision of submodule that includes submodules needs to specify the revision of
the included submodules. If a submodule changes, any module or the included submodules. If a submodule changes, any module or
submodule that includes it needs to be updated. submodule that includes it needs to be updated.
For example, module "b" imports module "a". For example, module "b" imports module "a".
module a { module a {
yang-version 1.1; yang-version 1.1;
namespace "http://example.com/a"; namespace "urn:example:a";
prefix "a"; prefix "a";
revision 2008-01-01 { ... } revision 2008-01-01 { ... }
grouping a { grouping a {
leaf eh { .... } leaf eh { .... }
} }
} }
module b { module b {
yang-version 1.1; yang-version 1.1;
namespace "http://example.com/b"; namespace "urn:example:b";
prefix "b"; prefix "b";
import a { import a {
prefix "p"; prefix "p";
revision-date 2008-01-01; revision-date 2008-01-01;
} }
container bee { container bee {
uses p:a; uses p:a;
} }
skipping to change at page 31, line 15 skipping to change at page 31, line 21
5.1.2.1. NETCONF XML Encoding 5.1.2.1. NETCONF XML Encoding
NETCONF is capable of carrying any XML content as the payload in the NETCONF is capable of carrying any XML content as the payload in the
<config> and <data> elements. The top-level nodes of YANG modules <config> and <data> elements. The top-level nodes of YANG modules
are encoded as child elements, in any order, within these elements. are encoded as child elements, in any order, within these elements.
This encapsulation guarantees that the corresponding NETCONF messages This encapsulation guarantees that the corresponding NETCONF messages
are always well-formed XML documents. are always well-formed XML documents.
For example: For example:
module my-config { module example-config {
yang-version 1.1; yang-version 1.1;
namespace "http://example.com/schema/config"; namespace "urn:example:config";
prefix "co"; prefix "co";
container system { ... } container system { ... }
container routing { ... } container routing { ... }
} }
could be encoded in NETCONF as: could be encoded in NETCONF as:
<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>
<config> <config>
<system xmlns="http://example.com/schema/config"> <system xmlns="urn:example:config">
<!-- system data here --> <!-- system data here -->
</system> </system>
<routing xmlns="http://example.com/schema/config"> <routing xmlns="urn:example:config">
<!-- routing data here --> <!-- routing data here -->
</routing> </routing>
</config> </config>
</edit-config> </edit-config>
</rpc> </rpc>
5.2. File Layout 5.2. File Layout
YANG modules and submodules are typically stored in files, one module YANG modules and submodules are typically stored in files, one module
or submodule per file. The name of the file SHOULD be of the form: or submodule per file. The name of the file SHOULD be of the form:
skipping to change at page 35, line 34 skipping to change at page 35, line 40
If a server implements a module A that imports a module B, and A uses If a server implements a module A that imports a module B, and A uses
any node from B in an "augment" or "path" statement that the server any node from B in an "augment" or "path" statement that the server
supports, then the server MUST implement a revision of module B that supports, then the server MUST implement a revision of module B that
has these nodes defined. This is regardless of if module B is has these nodes defined. This is regardless of if module B is
imported by revision or not. imported by revision or not.
If a server implements a module A that imports a module C without If a server implements a module A that imports a module C without
specifying the revision date of module C, and the server does not specifying the revision date of module C, and the server does not
implement C (e.g., if C only defines some typedefs), the server MUST implement C (e.g., if C only defines some typedefs), the server MUST
list module C in the "/modules/module" list from "ietf-yang-library" list module C in the "/modules-state/module" list from
[I-D.ietf-netconf-yang-library], and it MUST set the leaf "ietf-yang-library" [I-D.ietf-netconf-yang-library], and it MUST set
"conformance" to "import" for this module. the leaf "conformance-type" to "import" for this module.
If a server lists a module C in the "/modules-state/module" list from
"ietf-yang-library", and there are other modules Ms listed that
import C without specifying the revision date of module C, the server
MUST use the definitions from the most recent revision of C listed
for modules Ms.
The reason for these rules is that clients need to be able to know The reason for these rules is that clients need to be able to know
the exact data model structure and types of all leafs and leaf-lists the exact data model structure and types of all leafs and leaf-lists
implemented in a server. implemented in a server.
For example, with these modules: For example, with these modules:
module a { module a {
yang-version 1.1; yang-version 1.1;
namespace "http://example.com/a"; namespace "urn:example:a";
prefix "a"; prefix "a";
import b { import b {
revision-date 2015-01-01; revision-date 2015-01-01;
} }
import c; import c;
revision 2015-01-01; revision 2015-01-01;
feature foo; feature foo;
skipping to change at page 36, line 26 skipping to change at page 36, line 41
container a { container a {
leaf x { leaf x {
type c:bar; type c:bar;
} }
} }
} }
module b { module b {
yang-version 1.1; yang-version 1.1;
namespace "http://example.com/b"; namespace "urn:example:b";
prefix "b"; prefix "b";
revision 2015-04-04; revision 2015-04-04;
revision 2015-01-01; revision 2015-01-01;
typedef myenum { typedef myenum {
type enumeration { type enumeration {
enum zero; // added in 2015-01-01 enum zero; // added in 2015-01-01
enum one; // added in 2015-04-04 enum one; // added in 2015-04-04
} }
} }
container x { // added in 2015-01-01
container x { // added in 2015-01-01 container y; // added in 2015-04-04
container y; // added in 2015-04-04
} }
} }
module c { module c {
yang-version 1.1; yang-version 1.1;
namespace "http://example.com/c"; namespace "urn:example:c";
prefix "c"; prefix "c";
revision 2015-03-03; revision 2015-03-03;
revision 2015-02-02; revision 2015-02-02;
typedef foo {
typedef bar {
... ...
} }
} }
A server that implements revision "2015-01-01" of module "a" and A server that implements revision "2015-01-01" of module "a" and
supports feature "foo" can implement revision "2015-01-01" or supports feature "foo" can implement revision "2015-01-01" or
"2015-04-04" of module "b". Since "b" was imported by revision, the "2015-04-04" of module "b". Since "b" was imported by revision, the
type of leaf "/b:x/a:y" is the same regardless of which revision of type of leaf "/b:x/a:y" is the same regardless of which revision of
"b" the server implements. "b" the server implements.
A server that implements module "a", but does not support feature A server that implements module "a", but does not support feature
"foo" does not have to implement module "b". "foo" does not have to implement module "b".
A server that implements revision "2015-01-01" of module "a" must A server that implements revision "2015-01-01" of module "a" must
pick a revision of module "c", and list it in the "/modules/module" pick a revision of module "c", and list it in the "/modules-state/
list from "ietf-yang-library". module" list from "ietf-yang-library".
The following XML encoding example shows valid data for the The following XML encoding example shows valid data for the
"/modules/module" list for a server that implements module "a": "/modules-state/module" list for a server that implements module "a":
<modules xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library"> <modules-state
xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library">
<module-set-id>ee1ecb017370cafd</module-set-id> <module-set-id>ee1ecb017370cafd</module-set-id>
<module> <module>
<name>a</module> <name>a</name>
<revision>2015-01-01</revision> <revision>2015-01-01</revision>
<namespace>urn:example:a</namespace>
<feature>foo</feature> <feature>foo</feature>
<conformance>implement</conformance> <conformance-type>implement</conformance-type>
</module> </module>
<module> <module>
<name>b</module> <name>b</name>
<revision>2015-04-04</revision> <revision>2015-04-04</revision>
<conformance>implement</conformance> <namespace>urn:example:b</namespace>
<conformance-type>implement</conformance-type>
</module> </module>
<module> <module>
<name>c</module> <name>c</name>
<revision>2015-02-02</revision> <revision>2015-02-02</revision>
<conformance>import</conformance> <namespace>urn:example:c</namespace>
<conformance-type>import</conformance-type>
</module> </module>
</modules> </modules-state>
5.6.5. Announcing Conformance Information in NETCONF 5.6.5. Announcing Conformance Information in NETCONF
This document defines the following mechanism for announcing This document defines the following mechanism for announcing
conformance information. Other mechanisms may be defined by future conformance information. Other mechanisms may be defined by future
specifications. specifications.
A NETCONF server announces the modules it implements by implementing A NETCONF server announces the modules it implements by implementing
the YANG module "ietf-yang-library" defined in the YANG module "ietf-yang-library" defined in
[I-D.ietf-netconf-yang-library], and listing all implemented modules [I-D.ietf-netconf-yang-library], and listing all implemented modules
in the "/modules/module" list. in the "/modules-state/module" list.
The server also advertises the following capability in the <hello> The server also advertises the following capability in the <hello>
message (line-breaks and whitespaces are used for formatting reasons message (line-breaks and whitespaces are used for formatting reasons
only): only):
urn:ietf:params:netconf:capability:yang-library:1.0? urn:ietf:params:netconf:capability:yang-library:1.0?
module-set-id=<id> module-set-id=<id>
The parameter "module-set-id" has the same value as the leaf The parameter "module-set-id" has the same value as the leaf
"/modules/module-set-id" from "ietf-yang-library". This parameter "/modules-state/module-set-id" from "ietf-yang-library". This
MUST be present. parameter MUST be present.
With this mechanism, a client can cache the supported modules for a With this mechanism, a client can cache the supported modules for a
server, and only update the cache if the "module-set-id" value in the server, and only update the cache if the "module-set-id" value in the
<hello> message changes. <hello> message changes.
5.7. Datastore Modification 5.7. Datastore Modification
Data models may allow the server to alter the configuration datastore Data models may allow the server to alter the configuration datastore
in ways not explicitly directed via network management protocol in ways not explicitly directed via network management protocol
messages. For example, a data model may define leafs that are messages. For example, a data model may define leafs that are
skipping to change at page 39, line 20 skipping to change at page 39, line 49
driven by a need to keep the parsers easy to implement, while the driven by a need to keep the parsers easy to implement, while the
power is driven by the fact that modelers need to express their power is driven by the fact that modelers need to express their
models in readable formats. models in readable formats.
6.1.1. Comments 6.1.1. Comments
Comments are C++ style. A single line comment starts with "//" and Comments are C++ style. A single line comment starts with "//" and
ends at the end of the line. A block comment is enclosed within "/*" ends at the end of the line. A block comment is enclosed within "/*"
and "*/". and "*/".
Note that inside a quoted string (Section 6.1.3), these character
pairs are never interpreted as the start or end of a comment.
6.1.2. Tokens 6.1.2. Tokens
A token in YANG is either a keyword, a string, a semicolon (";"), or A token in YANG is either a keyword, a string, a semicolon (";"), or
braces ("{" or "}"). A string can be quoted or unquoted. A keyword braces ("{" or "}"). A string can be quoted or unquoted. A keyword
is either one of the YANG keywords defined in this document, or a is either one of the YANG keywords defined in this document, or a
prefix identifier, followed by ":", followed by a language extension prefix identifier, followed by ":", followed by a language extension
keyword. Keywords are case sensitive. See Section 6.2 for a formal keyword. Keywords are case sensitive. See Section 6.2 for a formal
definition of identifiers. definition of identifiers.
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, tab, or newline characters, a single
braces ("{" or "}"), or comment sequences ("//", "/*", or "*/"), then or double quote character, a semicolon (";"), braces ("{" or "}"), or
it MUST be enclosed within double or single quotes. comment sequences ("//", "/*", or "*/"), then it MUST be enclosed
within double or single quotes.
If the double-quoted string contains a line break followed by space Within an unquoted string, every character is preserved. Note that
or tab characters that are used to indent the text according to the this means that the backslash character does not have any special
meaning in an unquoted string.
If a double-quoted string contains a line break followed by space or
tab characters that 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 and including the column of the double quote character, string, up to and including the column of the double quote character,
or to the first non-whitespace character, whichever occurs first. In or to the first non-whitespace character, whichever occurs first. In
this process, a tab character is treated as 8 space characters. this process, a tab character is treated as 8 space characters.
If the double-quoted string contains space or tab characters before a If a 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 within the quotes. A single quote character cannot occur in a
single-quoted string, even when preceded by a backslash. single-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
character that immediately follows the backslash: character that immediately follows the backslash:
skipping to change at page 46, line 6 skipping to change at page 47, line 6
The context node varies with the YANG XPath expression, and is The context node varies with the YANG XPath expression, and is
specified where the YANG statement with the XPath expression is specified where the YANG statement with the XPath expression is
defined. defined.
6.4.1.1. Examples 6.4.1.1. Examples
Given the following module: Given the following module:
module example-a { module example-a {
namespace http://example.com/a; namespace urn:example:a;
prefix a; prefix a;
container a { container a {
list b { list b {
key id; key id;
leaf id { leaf id {
type string; type string;
} }
notification down { notification down {
leaf reason { leaf reason {
skipping to change at page 46, line 45 skipping to change at page 47, line 45
leaf b-ref { leaf b-ref {
type leafref { type leafref {
path "/a/b/id"; path "/a/b/id";
} }
} }
} }
} }
And given the following data tree, specified in XML: And given the following data tree, specified in XML:
<a xmlns="http://example.com/a"> <a xmlns="urn:example:a">
<b> <b>
<id>1</id> <id>1</id>
</b> </b>
<b> <b>
<id>2</id> <id>2</id>
</b> </b>
</a> </a>
The accessible tree for a notification "down" on /a/b[id="2"] is: The accessible tree for a notification "down" on /a/b[id="2"] is:
<a xmlns="http://example.com/a"> <a xmlns="urn:example:a">
<b> <b>
<id>1</id> <id>1</id>
</b> </b>
<b> <b>
<id>2</id> <id>2</id>
<down> <down>
<reason>error</reason> <reason>error</reason>
</down> </down>
</b> </b>
</a> </a>
// possibly other top-level nodes here // possibly other top-level nodes here
The accessible tree for an action invocation of "reset" on /a/ The accessible tree for an action invocation of "reset" on /a/
b[id="1"] with the "when" parameter set to "10" would be: b[id="1"] with the "when" parameter set to "10" would be:
<a xmlns="http://example.com/a"> <a xmlns="urn:example:a">
<b> <b>
<id>1</id> <id>1</id>
<reset> <reset>
<delay>10</delay> <delay>10</delay>
</down> </down>
</b> </b>
<b> <b>
<id>2</id> <id>2</id>
</b> </b>
</a> </a>
// possibly other top-level nodes here // possibly other top-level nodes here
The accessible tree for the action output of this action is: The accessible tree for the action output of this action is:
<a xmlns="http://example.com/a"> <a xmlns="urn:example:a">
<b> <b>
<id>1</id> <id>1</id>
<reset> <reset>
<result>ok</result> <result>ok</result>
</reset> </reset>
</b> </b>
<b> <b>
<id>2</id> <id>2</id>
</b> </b>
</a> </a>
// possibly other top-level nodes here // possibly other top-level nodes here
The accessible tree for a notification "failure" could be: The accessible tree for a notification "failure" could be:
<a xmlns="http://example.com/a"> <a xmlns="urn:example:a">
<b> <b>
<id>1</id> <id>1</id>
</b> </b>
<b> <b>
<id>2</id> <id>2</id>
</b> </b>
</a> </a>
<failure> <failure>
<b-ref>2</b-ref> <b-ref>2</b-ref>
</failure> </failure>
skipping to change at page 48, line 46 skipping to change at page 49, line 46
7. YANG Statements 7. YANG Statements
The following sections describe all of the YANG statements. The following sections describe all of the YANG statements.
Note that even a statement that does not have any substatements Note that even a statement that does not have any substatements
defined in YANG can have vendor-specific extensions as substatements. defined in YANG can have vendor-specific extensions as substatements.
For example, the "description" statement does not have any For example, the "description" statement does not have any
substatements defined in YANG, but the following is legal: substatements defined in YANG, but the following is legal:
description "some text" { description "some text" {
acme:documentation-flag 5; ex:documentation-flag 5;
} }
7.1. The module Statement 7.1. The module Statement
The "module" statement defines the module's name, and groups all The "module" statement defines the module's name, and groups all
statements that belong to the module together. The "module" statements that belong to the module together. The "module"
statement's argument is the name of the module, followed by a block statement's argument is the name of the module, followed by a block
of substatements that hold detailed module information. The module of substatements that hold detailed module information. The module
name follows the rules for identifiers in Section 6.2. name follows the rules for identifiers in Section 6.2.
skipping to change at page 52, line 38 skipping to change at page 53, line 38
module they are taken. module they are taken.
Multiple revisions of the same module can be imported, provided that Multiple revisions of the same module can be imported, provided that
different prefixes are used. different prefixes are used.
+---------------+---------+-------------+ +---------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+---------------+---------+-------------+ +---------------+---------+-------------+
| prefix | 7.1.4 | 1 | | prefix | 7.1.4 | 1 |
| revision-date | 7.1.5.1 | 0..1 | | revision-date | 7.1.5.1 | 0..1 |
| description | 7.21.3 | 0..1 |
| reference | 7.21.4 | 0..1 |
+---------------+---------+-------------+ +---------------+---------+-------------+
The import's Substatements The import's Substatements
7.1.5.1. The import's revision-date Statement 7.1.5.1. The import's revision-date Statement
The import's "revision-date" statement is used to specify the exact The import's "revision-date" statement is used to specify the exact
version of the module to import. version of the module to import.
7.1.6. The include Statement 7.1.6. The include Statement
skipping to change at page 53, line 26 skipping to change at page 54, line 32
an error if the specified revision of the submodule does not exist. an error if the specified revision of the submodule does not exist.
If no "revision-date" substatement is present, it is undefined which If no "revision-date" substatement is present, it is undefined which
revision of the submodule is included. revision of the submodule is included.
Multiple revisions of the same submodule MUST NOT be included. Multiple revisions of the same submodule MUST NOT be included.
+---------------+---------+-------------+ +---------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+---------------+---------+-------------+ +---------------+---------+-------------+
| revision-date | 7.1.5.1 | 0..1 | | revision-date | 7.1.5.1 | 0..1 |
| description | 7.21.3 | 0..1 |
| reference | 7.21.4 | 0..1 |
+---------------+---------+-------------+ +---------------+---------+-------------+
The includes's Substatements The includes's Substatements
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 that is used to specify a textual module. The argument is a string that 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.
skipping to change at page 54, line 19 skipping to change at page 56, line 4
7.1.9.1. The revision's Substatement 7.1.9.1. The revision's Substatement
+--------------+---------+-------------+ +--------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+--------------+---------+-------------+ +--------------+---------+-------------+
| description | 7.21.3 | 0..1 | | description | 7.21.3 | 0..1 |
| reference | 7.21.4 | 0..1 | | reference | 7.21.4 | 0..1 |
+--------------+---------+-------------+ +--------------+---------+-------------+
7.1.10. Usage Example 7.1.10. Usage Example
module example-system {
module acme-system {
yang-version 1.1; yang-version 1.1;
namespace "http://acme.example.com/system"; namespace "urn:example:system";
prefix "acme"; prefix "sys";
import ietf-yang-types { import ietf-yang-types {
prefix "yang"; prefix "yang";
} }
include acme-types; include example-types;
organization "ACME Inc."; organization "Example Inc.";
contact contact
"Joe L. User "Joe L. User
ACME, Inc. Example Inc.
42 Anywhere Drive 42 Anywhere Drive
Nowhere, CA 95134 Nowhere, CA 95134
USA USA
Phone: +1 800 555 0100 Phone: +1 800 555 0100
EMail: joe@acme.example.com"; EMail: joe@example.com";
description description
"The module for entities implementing the ACME protocol."; "The module for entities implementing the Example system.";
revision "2007-06-09" { revision 2007-06-09 {
description "Initial revision."; description "Initial revision.";
} }
// definitions follow... // definitions follow...
} }
7.2. The submodule Statement 7.2. The submodule Statement
While the primary unit in YANG is a module, a YANG module can itself While the primary unit in YANG is a module, a YANG module can itself
be constructed out of several submodules. Submodules allow a module be constructed out of several submodules. Submodules allow a module
skipping to change at page 57, line 15 skipping to change at page 59, line 15
+--------------+---------+-------------+ +--------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+--------------+---------+-------------+ +--------------+---------+-------------+
| prefix | 7.1.4 | 1 | | prefix | 7.1.4 | 1 |
+--------------+---------+-------------+ +--------------+---------+-------------+
The belongs-to's Substatements The belongs-to's Substatements
7.2.3. Usage Example 7.2.3. Usage Example
submodule acme-types { submodule example-types {
yang-version 1.1; yang-version 1.1;
belongs-to "acme-system" { belongs-to "example-system" {
prefix "acme"; prefix "sys";
} }
import ietf-yang-types { import ietf-yang-types {
prefix "yang"; prefix "yang";
} }
organization "ACME Inc."; organization "Example Inc.";
contact contact
"Joe L. User "Joe L. User
ACME, Inc. Example Inc.
42 Anywhere Drive 42 Anywhere Drive
Nowhere, CA 95134 Nowhere, CA 95134
USA USA
Phone: +1 800 555 0100 Phone: +1 800 555 0100
EMail: joe@acme.example.com"; EMail: joe@example.com";
description description
"This submodule defines common ACME types."; "This submodule defines common Example types.";
revision "2007-06-09" { revision "2007-06-09" {
description "Initial revision."; description "Initial revision.";
} }
// definitions follows... // definitions follows...
} }
7.3. The typedef Statement 7.3. The typedef Statement
skipping to change at page 62, line 6 skipping to change at page 64, line 6
The XPath expression is conceptually evaluated in the following The XPath expression is conceptually evaluated in the following
context, in addition to the definition in Section 6.4.1: context, in addition to the definition in Section 6.4.1:
o The context node is the node in the accessible tree for which the o The context node is the node in the accessible tree for which the
"must" statement is defined. "must" statement is defined.
The result of the XPath expression is converted to a boolean value The result of the XPath expression is converted to a boolean value
using the standard XPath rules. using the standard XPath rules.
Note that since all leaf values in the data tree are conceptually Note that since all leaf values in the data tree are conceptually
stored in their canonical form (see Section 7.6 and Section 7.7), any stored in their canonical form (see Section 9.1), any XPath
XPath comparisons are done on the canonical value. comparisons are done on the canonical value.
Also note that the XPath expression is conceptually evaluated. This Also note that the XPath expression is conceptually evaluated. This
means that an implementation does not have to use an XPath evaluator means that an implementation does not have to use an XPath evaluator
in the server. How the evaluation is done in practice is an in the server. How the evaluation is done in practice is an
implementation decision. implementation decision.
7.5.4. The must's Substatements 7.5.4. The must's Substatements
+---------------+---------+-------------+ +---------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
skipping to change at page 65, line 23 skipping to change at page 67, line 23
To delete a container with an <edit-config>: To delete a container with an <edit-config>:
<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>
<config> <config>
<system xmlns="http://example.com/schema/config"> <system xmlns="urn:example:config">
<services> <services>
<ssh nc:operation="delete"/> <ssh nc:operation="delete"/>
</services> </services>
</system> </system>
</config> </config>
</edit-config> </edit-config>
</rpc> </rpc>
7.6. The leaf Statement 7.6. The leaf Statement
skipping to change at page 69, line 13 skipping to change at page 71, line 13
To set the value of a leaf with an <edit-config>: To set the value of a leaf with an <edit-config>:
<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>
<config> <config>
<system xmlns="http://example.com/schema/config"> <system xmlns="urn:example:config">
<services> <services>
<ssh> <ssh>
<port>2022</port> <port>2022</port>
</ssh> </ssh>
</services> </services>
</system> </system>
</config> </config>
</edit-config> </edit-config>
</rpc> </rpc>
skipping to change at page 75, line 13 skipping to change at page 77, line 13
operation "merge": operation "merge":
<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>
<config> <config>
<system xmlns="http://example.com/schema/config"> <system xmlns="urn:example:config">
<services> <services>
<ssh> <ssh>
<allow-user>eric</allow-user> <allow-user>eric</allow-user>
</ssh> </ssh>
</services> </services>
</system> </system>
</config> </config>
</edit-config> </edit-config>
</rpc> </rpc>
skipping to change at page 76, line 14 skipping to change at page 78, line 14
<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"
xmlns:yang="urn:ietf:params:xml:ns:yang:1"> xmlns:yang="urn:ietf:params:xml:ns:yang:1">
<edit-config> <edit-config>
<target> <target>
<running/> <running/>
</target> </target>
<config> <config>
<system xmlns="http://example.com/schema/config"> <system xmlns="urn:example:config">
<services> <services>
<ssh> <ssh>
<cipher nc:operation="create" <cipher nc:operation="create"
yang:insert="after" yang:insert="after"
yang:value="3des-cbc">blowfish-cbc</cipher> yang:value="3des-cbc">blowfish-cbc</cipher>
</ssh> </ssh>
</services> </services>
</system> </system>
</config> </config>
</edit-config> </edit-config>
skipping to change at page 82, line 13 skipping to change at page 84, line 13
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>
<config> <config>
<system xmlns="http://example.com/schema/config"> <system xmlns="urn:example:config">
<user nc:operation="create"> <user nc:operation="create">
<name>barney</name> <name>barney</name>
<type>admin</type> <type>admin</type>
<full-name>Barney Rubble</full-name> <full-name>Barney Rubble</full-name>
</user> </user>
</system> </system>
</config> </config>
</edit-config> </edit-config>
</rpc> </rpc>
To change the type of "fred" to "superuser": To change the type of "fred" to "superuser":
<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>
<config> <config>
<system xmlns="http://example.com/schema/config"> <system xmlns="urn:example:config">
<user> <user>
<name>fred</name> <name>fred</name>
<type>superuser</type> <type>superuser</type>
</user> </user>
</system> </system>
</config> </config>
</edit-config> </edit-config>
</rpc> </rpc>
Given the following ordered-by user list: Given the following ordered-by user list:
skipping to change at page 83, line 36 skipping to change at page 85, line 36
<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"
xmlns:yang="urn:ietf:params:xml:ns:yang:1"> xmlns:yang="urn:ietf:params:xml:ns:yang:1">
<edit-config> <edit-config>
<target> <target>
<running/> <running/>
</target> </target>
<config> <config>
<system xmlns="http://example.com/schema/config" <system xmlns="urn:example:config"
xmlns:ex="http://example.com/schema/config"> xmlns:ex="urn:example:config">
<user nc:operation="create" <user nc:operation="create"
yang:insert="after" yang:insert="after"
yang:key="[ex:first-name='fred'] yang:key="[ex:first-name='fred']
[ex:surname='flintstone']"> [ex:surname='flintstone']">
<first-name>barney</first-name> <first-name>barney</first-name>
<surname>rubble</surname> <surname>rubble</surname>
<type>admin</type> <type>admin</type>
</user> </user>
</system> </system>
</config> </config>
skipping to change at page 84, line 14 skipping to change at page 86, line 14
<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"
xmlns:yang="urn:ietf:params:xml:ns:yang:1"> xmlns:yang="urn:ietf:params:xml:ns:yang:1">
<edit-config> <edit-config>
<target> <target>
<running/> <running/>
</target> </target>
<config> <config>
<system xmlns="http://example.com/schema/config" <system xmlns="urn:example:config"
xmlns:ex="http://example.com/schema/config"> xmlns:ex="urn:example:config">
<user nc:operation="merge" <user nc:operation="merge"
yang:insert="before" yang:insert="before"
yang:key="[ex:name='fred'] yang:key="[ex:name='fred']
[ex:surname='flintstone']"> [ex:surname='flintstone']">
<first-name>barney</first-name> <first-name>barney</first-name>
<surname>rubble</surname> <surname>rubble</surname>
</user> </user>
</system> </system>
</config> </config>
</edit-config> </edit-config>
skipping to change at page 87, line 31 skipping to change at page 89, line 31
value will be used if none of "daily", "time-of-day", or "manual" are value will be used if none of "daily", "time-of-day", or "manual" are
present. If "daily" is present, the default value for "time-of-day" present. If "daily" is present, the default value for "time-of-day"
will be used. will be used.
container transfer { container transfer {
choice how { choice how {
default interval; default interval;
case interval { case interval {
leaf interval { leaf interval {
type uint16; type uint16;
default 30;
units minutes; units minutes;
default 30;
} }
} }
case daily { case daily {
leaf daily { leaf daily {
type empty; type empty;
} }
leaf time-of-day { leaf time-of-day {
type string; type string;
units 24-hour-clock; units 24-hour-clock;
default 1am; default "01.00";
} }
} }
case manual { case manual {
leaf manual { leaf manual {
type empty; type empty;
} }
} }
} }
} }
skipping to change at page 89, line 21 skipping to change at page 91, line 21
To change the protocol from tcp to udp: To change the protocol from tcp to udp:
<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>
<config> <config>
<system xmlns="http://example.com/schema/config"> <system xmlns="urn:example:config">
<protocol> <protocol>
<udp nc:operation="create"/> <udp nc:operation="create"/>
</protocol> </protocol>
</system> </system>
</config> </config>
</edit-config> </edit-config>
</rpc> </rpc>
7.10. The anydata Statement 7.10. The anydata Statement
skipping to change at page 91, line 28 skipping to change at page 93, line 28
} }
The following is a valid encoding of such a list instance: The following is a valid encoding of such a list instance:
<logged-notification> <logged-notification>
<time>2014-07-29T13:43:12Z</time> <time>2014-07-29T13:43:12Z</time>
<data> <data>
<notification <notification
xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
<eventTime>2014-07-29T13:43:01Z</eventTime> <eventTime>2014-07-29T13:43:01Z</eventTime>
<event xmlns="http://example.com/event"> <event xmlns="urn:example:event">
<event-class>fault</event-class> <event-class>fault</event-class>
<reporting-entity> <reporting-entity>
<card>Ethernet0</card> <card>Ethernet0</card>
</reporting-entity> </reporting-entity>
<severity>major</severity> <severity>major</severity>
</event> </event>
</notification> </notification>
</data> </data>
7.11. The anyxml Statement 7.11. The anyxml Statement
skipping to change at page 97, line 16 skipping to change at page 99, line 16
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.13.4. Usage Example 7.13.4. Usage Example
To use the "endpoint" grouping defined in Section 7.12.2 in a To use the "endpoint" grouping defined in Section 7.12.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 example-system {
prefix "acme"; prefix "sys";
} }
container http-server { container http-server {
leaf name { leaf name {
type string; type string;
} }
uses acme:endpoint; uses sys: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:endpoint { uses sys: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:endpoint; uses sys:endpoint;
} }
The following is an error: The following is an error:
container http-server { container http-server {
uses acme:endpoint; uses sys:endpoint;
leaf ip { // illegal - same identifier "ip" used twice leaf ip { // illegal - same identifier "ip" used twice
type string; type string;
} }
} }
7.14. The rpc Statement 7.14. The rpc Statement
The "rpc" statement is used to define an RPC operation. It takes one The "rpc" statement is used to define an RPC operation. It takes one
argument, which is an identifier, followed by a block of 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 101, line 26 skipping to change at page 103, line 26
If the RPC operation invocation succeeded, and no output parameters If the RPC operation invocation succeeded, and no output parameters
are returned, the <rpc-reply> contains a single <ok/> element defined are returned, the <rpc-reply> contains a single <ok/> element defined
in [RFC6241]. If output parameters are returned, they are encoded as in [RFC6241]. If output parameters are returned, they are encoded as
child elements to the <rpc-reply> element defined in [RFC6241], in child elements to the <rpc-reply> element defined in [RFC6241], in
the same order as they are defined within the "output" statement. the same order as they are defined within the "output" statement.
7.14.5. Usage Example 7.14.5. Usage Example
The following example defines an RPC operation: The following example defines an RPC operation:
module rock { module example-rock {
yang-version 1.1; yang-version 1.1;
namespace "http://example.net/rock"; namespace "urn:example:rock";
prefix "rock"; prefix "rock";
rpc rock-the-house { rpc rock-the-house {
input { input {
leaf zip-code { leaf zip-code {
type string; type string;
} }
} }
} }
} }
A corresponding XML instance example of the complete rpc and rpc- A corresponding XML instance example of the complete rpc and rpc-
reply: reply:
<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">
<rock-the-house xmlns="http://example.net/rock"> <rock-the-house xmlns="urn:example:rock">
<zip-code>27606-0100</zip-code> <zip-code>27606-0100</zip-code>
</rock-the-house> </rock-the-house>
</rpc> </rpc>
<rpc-reply message-id="101" <rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<ok/> <ok/>
</rpc-reply> </rpc-reply>
7.15. The action Statement 7.15. The action Statement
skipping to change at page 104, line 5 skipping to change at page 106, line 5
element defined in [RFC6241]. If output parameters are returned, element defined in [RFC6241]. If output parameters are returned,
they are encoded as child elements to the <rpc-reply> element defined they are encoded as child elements to the <rpc-reply> element defined
in [RFC6241], in the same order as they are defined within the in [RFC6241], in the same order as they are defined within the
"output" statement. "output" statement.
7.15.3. Usage Example 7.15.3. Usage Example
The following example defines an action to reset one server at a The following example defines an action to reset one server at a
server farm: server farm:
module server-farm { module example-server-farm {
yang-version 1.1; yang-version 1.1;
namespace "http://example.net/server-farm"; namespace "urn:example:server-farm";
prefix "sfarm"; prefix "sfarm";
import ietf-yang-types { import ietf-yang-types {
prefix "yang"; prefix "yang";
} }
list server { list server {
key name; key name;
leaf name { leaf name {
type string; type string;
skipping to change at page 105, line 8 skipping to change at page 107, line 8
} }
} }
} }
A corresponding XML instance example of the complete rpc and rpc- A corresponding XML instance example of the complete rpc and rpc-
reply: reply:
<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">
<action xmlns="urn:ietf:params:xml:ns:yang:1"> <action xmlns="urn:ietf:params:xml:ns:yang:1">
<server xmlns="http://example.net/server-farm"> <server xmlns="urn:example:server-farm">
<name>apache-1</name> <name>apache-1</name>
<reset> <reset>
<reset-at>2014-07-29T13:42:00Z</reset-at> <reset-at>2014-07-29T13:42:00Z</reset-at>
</reset> </reset>
</server> </server>
</action> </action>
</rpc> </rpc>
<rpc-reply message-id="101" <rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<reset-finished-at xmlns="http://example.net/server-farm"> <reset-finished-at xmlns="urn:example:server-farm">
2014-07-29T13:42:12Z 2014-07-29T13:42:12Z
</reset-finished-at> </reset-finished-at>
</rpc-reply> </rpc-reply>
7.16. The notification Statement 7.16. The notification Statement
The "notification" statement is used to define a notification. It The "notification" statement is used to define a notification. 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 notification information. The substatements that holds detailed notification information. The
"notification" statement defines a notification node in the schema "notification" statement defines a notification node in the schema
skipping to change at page 107, line 16 skipping to change at page 109, line 16
of the defined notification. of the defined notification.
The notification's child nodes are encoded as subelements to the The notification's child nodes are encoded as subelements to the
notification node's XML element, in any order. notification node's XML element, in any order.
7.16.3. Usage Example 7.16.3. Usage Example
The following example defines a notification at the top-level of a The following example defines a notification at the top-level of a
module: module:
module event { module example-event {
yang-version 1.1; yang-version 1.1;
namespace "http://example.com/event"; namespace "urn:example:event";
prefix "ev"; prefix "ev";
notification event { notification event {
leaf event-class { leaf event-class {
type string; type string;
} }
leaf reporting-entity { leaf reporting-entity {
type instance-identifier; type instance-identifier;
} }
leaf severity { leaf severity {
type string; type string;
} }
} }
} }
A corresponding XML instance example of the complete notification: A corresponding XML instance example of the complete 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-07-08T00:01:00Z</eventTime> <eventTime>2008-07-08T00:01:00Z</eventTime>
<event xmlns="http://example.com/event"> <event xmlns="urn:example:event">
<event-class>fault</event-class> <event-class>fault</event-class>
<reporting-entity> <reporting-entity>
/ex:interface[ex:name='Ethernet0'] /ex:interface[ex:name='Ethernet0']
</reporting-entity> </reporting-entity>
<severity>major</severity> <severity>major</severity>
</event> </event>
</notification> </notification>
The following example defines a notification in a data node: The following example defines a notification in a data node:
module interface-module { module example-interface-module {
yang-version 1.1; yang-version 1.1;
namespace "http://example.com/schema/interfaces"; namespace "urn:example:interface-module";
prefix "if"; prefix "if";
container interfaces { container interfaces {
list interface { list interface {
key "name"; key "name";
leaf name { leaf name {
type string; type string;
} }
notification interface-enabled { notification interface-enabled {
leaf by-user { leaf by-user {
skipping to change at page 108, line 30 skipping to change at page 110, line 30
} }
} }
} }
} }
A corresponding XML instance example of the complete notification: A corresponding XML instance example of the complete 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-07-08T00:01:00Z</eventTime> <eventTime>2008-07-08T00:01:00Z</eventTime>
<interfaces xmlns="http://example.com/schema/interfaces"> <interfaces xmlns="urn:example:interface-module">
<interface> <interface>
<name>eth1</name> <name>eth1</name>
<interface-enabled> <interface-enabled>
<by-user>fred</by-user> <by-user>fred</by-user>
</interface-enabled> </interface-enabled>
</interface> </interface>
</interfaces> </interfaces>
</notification> </notification>
7.17. The augment Statement 7.17. The augment Statement
skipping to change at page 109, line 25 skipping to change at page 111, line 25
If the target node is a container or list node, the "action" and If the target node is a container or list node, the "action" and
"notification" statements can be used within the "augment" statement. "notification" statements can be used within the "augment" statement.
If the target node is a choice node, the "case" statement, or a case If the target node is a choice node, the "case" statement, or a case
shorthand statement (see Section 7.9.2) can be used within the shorthand statement (see Section 7.9.2) can be used within the
"augment" statement. "augment" statement.
The "augment" statement MUST NOT add multiple nodes with the same The "augment" statement MUST NOT add multiple nodes with the same
name from the same module to the target node. name from the same module to the target node.
If the augmentation adds mandatory nodes (see Section 3) to a target If the augmentation adds mandatory configuration nodes (see
node in another module, the augmentation MUST be conditional with a Section 3) to a target node in another module, the augmentation MUST
"when" statement. Care must be taken when defining the "when" be conditional with a "when" statement. Care must be taken when
expression, so that clients that do not know about the augmenting defining the "when" expression, so that clients that do not know
module do not break. about the augmenting module do not break.
In the following example, it is OK to augment the "interface" entry In the following example, it is OK to augment the "interface" entry
with "mandatory-leaf" because the augmentation depends on support for with "mandatory-leaf" because the augmentation depends on support for
"some-new-iftype". The old client does not know about this type so "some-new-iftype". The old client does not know about this type so
it would never select this type, and therefore not be adding a it would never select this type, and therefore not be adding a
mandatory data node. mandatory data node.
module example-augment { module example-augment {
namespace "http://example.com/augment"; namespace "urn:example:augment";
prefix mymod; prefix mymod;
import ietf-interfaces { import ietf-interfaces {
prefix if; prefix if;
} }
identity some-new-iftype { identity some-new-iftype {
base if:interface-type; base if:interface-type;
} }
skipping to change at page 111, line 16 skipping to change at page 113, line 16
All data nodes defined in the "augment" statement are defined as XML All data nodes defined in the "augment" statement are defined as XML
elements in the XML namespace of the module where the "augment" is elements in the XML namespace of the module where the "augment" is
specified. specified.
When a node is augmented, the augmenting child nodes are encoded as When a node is augmented, the augmenting child nodes are encoded as
subelements to the augmented node, in any order. subelements to the augmented node, in any order.
7.17.3. Usage Example 7.17.3. Usage Example
In namespace http://example.com/schema/interfaces, we have: In namespace urn:example:interface-module, we have:
container interfaces { container interfaces {
list ifEntry { list ifEntry {
key "ifIndex"; key "ifIndex";
leaf ifIndex { leaf ifIndex {
type uint32; type uint32;
} }
leaf ifDescr { leaf ifDescr {
type string; type string;
} }
leaf ifType { leaf ifType {
type iana:IfType; type iana:IfType;
} }
leaf ifMtu { leaf ifMtu {
type int32; type int32;
} }
} }
} }
Then, in namespace http://example.com/schema/ds0, we have: Then, in namespace urn:example:ds0, we have:
import interface-module { import example-interface-module {
prefix "if"; prefix "if";
} }
augment "/if:interfaces/if:ifEntry" { augment "/if:interfaces/if:ifEntry" {
when "if:ifType='ds0'"; when "if:ifType='ds0'";
leaf ds0ChannelNumber { leaf ds0ChannelNumber {
type ChannelNumber; type ChannelNumber;
} }
} }
A corresponding XML instance example: A corresponding XML instance example:
<interfaces xmlns="http://example.com/schema/interfaces" <interfaces xmlns="urn:example:interface-module"
xmlns:ds0="http://example.com/schema/ds0"> xmlns:ds0="urn:example:ds0">
<ifEntry> <ifEntry>
<ifIndex>1</ifIndex> <ifIndex>1</ifIndex>
<ifDescr>Flintstone Inc Ethernet A562</ifDescr> <ifDescr>Flintstone Inc Ethernet A562</ifDescr>
<ifType>ethernetCsmacd</ifType> <ifType>ethernetCsmacd</ifType>
<ifMtu>1500</ifMtu> <ifMtu>1500</ifMtu>
</ifEntry> </ifEntry>
<ifEntry> <ifEntry>
<ifIndex>2</ifIndex> <ifIndex>2</ifIndex>
<ifDescr>Flintstone Inc DS0</ifDescr> <ifDescr>Flintstone Inc DS0</ifDescr>
<ifType>ds0</ifType> <ifType>ds0</ifType>
skipping to change at page 114, line 9 skipping to change at page 117, line 4
The derivation of identities has the following properties: The derivation of identities has the following properties:
o It is irreflexive, which means that an identity is not derived o It is irreflexive, which means that an identity is not derived
from itself. from itself.
o It is transitive, which means that if identity B is derived from A o It is transitive, which means that if identity B is derived from A
and C is derived from B, then C is also derived from A. and C is derived from B, then C is also derived from A.
7.18.3. Usage Example 7.18.3. Usage Example
module example-crypto-base {
yang-version 1.1;
namespace "urn:example:crypto-base";
prefix "crypto";
module crypto-base { identity crypto-alg {
yang-version 1.1; description
namespace "http://example.com/crypto-base"; "Base identity from which all crypto algorithms
prefix "crypto"; are derived.";
}
identity crypto-alg {
description
"Base identity from which all crypto algorithms
are derived.";
}
identity symmetric-key { identity symmetric-key {
description description
"Base identity used to identify symmetric-key crypto algorithms."; "Base identity used to identify symmetric-key crypto
} algorithms.";
}
identity public-key { identity public-key {
description description
"Base identity used to identify public-key crypto algorithms."; "Base identity used to identify public-key crypto
} algorithms.";
} }
}
module des { module example-des {
yang-version 1.1; yang-version 1.1;
namespace "http://example.com/des"; namespace "urn:example:des";
prefix "des"; prefix "des";
import "crypto-base" { import "example-crypto-base" {
prefix "crypto"; prefix "crypto";
} }
identity des { identity des {
base "crypto:crypto-alg"; base "crypto:crypto-alg";
base "crypto:symmetric-key"; base "crypto:symmetric-key";
description "DES crypto algorithm"; description "DES crypto algorithm";
} }
identity des3 { identity des3 {
base "crypto:crypto-alg"; base "crypto:crypto-alg";
base "crypto:symmetric-key"; base "crypto:symmetric-key";
description "Triple DES crypto algorithm"; description "Triple DES crypto algorithm";
} }
} }
7.19. The extension Statement 7.19. The extension Statement
The "extension" statement allows the definition of new statements The "extension" statement allows the definition of new statements
within the YANG language. This new statement definition can be within the YANG language. This new statement definition can be
imported and used by other modules. imported and used by other modules.
The statement's argument is an identifier that is the new keyword for The statement's argument is an identifier that is the new keyword for
the extension and must be followed by a block of substatements that the extension and must be followed by a block of substatements that
holds detailed extension information. The purpose of the "extension" holds detailed extension information. The purpose of the "extension"
skipping to change at page 116, line 30 skipping to change at page 119, line 30
the string "true" or "false". This statement indicates if the the string "true" or "false". This statement indicates if the
argument is mapped to an XML element in YIN or to an XML attribute argument is mapped to an XML element in YIN or to an XML attribute
(see Section 13). (see Section 13).
If no "yin-element" statement is present, it defaults to "false". If no "yin-element" statement is present, it defaults to "false".
7.19.3. Usage Example 7.19.3. Usage Example
To define an extension: To define an extension:
module my-extensions { module example-extensions {
yang-version 1.1; yang-version 1.1;
... ...
extension c-define { extension c-define {
description description
"Takes as argument a name string. "Takes as argument a name string.
Makes the code generator use the given name in the Makes the code generator use the given name in the
#define."; #define.";
argument "name"; argument "name";
} }
} }
To use the extension: To use the extension:
module my-interfaces { module example-interfaces {
yang-version 1.1; yang-version 1.1;
... ...
import my-extensions { import example-extensions {
prefix "myext"; prefix "myext";
} }
... ...
container interfaces { container interfaces {
... ...
myext:c-define "MY_INTERFACES"; myext:c-define "MY_INTERFACES";
} }
} }
skipping to change at page 118, line 5 skipping to change at page 121, line 5
name is used by the "if-feature" statement to tie the schema nodes to name is used by the "if-feature" statement to tie the schema nodes to
the feature. the feature.
In this example, a feature called "local-storage" represents the In this example, a feature called "local-storage" represents the
ability for a server to store syslog messages on local storage of ability for a server to store syslog messages on local storage of
some sort. This feature is used to make the "local-storage-limit" some sort. This feature is used to make the "local-storage-limit"
leaf conditional on the presence of some sort of local storage. If leaf conditional on the presence of some sort of local storage. If
the server does not report that it supports this feature, the the server does not report that it supports this feature, the
"local-storage-limit" node is not supported. "local-storage-limit" node is not supported.
module syslog { module example-syslog {
yang-version 1.1; yang-version 1.1;
... ...
feature local-storage { feature local-storage {
description description
"This feature means the server supports local "This feature means the server supports local
storage (memory, flash or disk) that can be used to storage (memory, flash or disk) that can be used to
store syslog messages."; store syslog messages.";
} }
skipping to change at page 122, line 5 skipping to change at page 125, line 5
If the target node has a property defined by an extension, this If the target node has a property defined by an extension, this
property can be deviated if the extension allows deviations. See property can be deviated if the extension allows deviations. See
Section 7.19 for details. Section 7.19 for details.
7.20.3.3. Usage Example 7.20.3.3. Usage Example
In this example, the server is informing client applications that it In this example, the server is informing client applications that it
does not support the "daytime" service in the style of RFC 867. does not support the "daytime" service in the style of RFC 867.
module my-deviations { module example-deviations {
yang-version 1.1; yang-version 1.1;
namespace "http://example.com/my-deviations"; namespace "urn:example:deviations";
prefix md; prefix md;
import my-base { import example-base {
prefix base; prefix base;
} }
deviation /base:system/base:daytime { deviation /base:system/base:daytime {
deviate not-supported; deviate not-supported;
} }
... ...
} }
A server would advertise both modules "my-base" and "my-deviations". A server would advertise both modules "example-base" and
"example-deviations".
The following example sets a server-specific default value to a leaf The following example sets a server-specific default value to a leaf
that does not have a default value defined: that does not have a default value defined:
deviation /base:system/base:user/base:type { deviation /base:system/base:user/base:type {
deviate add { deviate add {
default "admin"; // new users are 'admin' by default default "admin"; // new users are 'admin' by default
} }
} }
skipping to change at page 129, line 40 skipping to change at page 132, line 47
type's values. Some types allow multiple lexical representations of type's values. Some types allow multiple lexical representations of
the same value, for example, the positive integer "17" can be the same value, for example, the positive integer "17" can be
represented as "+17" or "17". Implementations MUST support all represented as "+17" or "17". Implementations MUST support all
lexical representations specified in this document. lexical representations specified in this document.
When a server sends data encoded in XML, it MUST use the canonical When a server sends data encoded in XML, it MUST use the canonical
form defined in this section. Other encodings may introduce form defined in this section. Other encodings may introduce
alternate representations. Note, however, that values in the data alternate representations. Note, however, that values in the data
tree are conceptually stored in the canonical representation as tree are conceptually stored in the canonical representation as
defined in this section. In particular, any XPath expression defined in this section. In particular, any XPath expression
evaluations are done using the canonical form. evaluations are done using the canonical form, if the data type has a
canonical form. If the data type does not have a canonical form, the
format of the value MUST match the data type's lexical
representation, but the exact format is implementation dependent.
Some types have a lexical representation that depends on the Some types have a lexical representation that depends on the
encoding, e.g., the XML context in which they occur. These types do encoding, e.g., the XML context in which they occur. These types do
not have a canonical form. not have a canonical form.
9.2. The Integer Built-In Types 9.2. The Integer Built-In Types
The integer built-in types are int8, int16, int32, int64, uint8, The integer built-in types are int8, int16, int32, int64, uint8,
uint16, uint32, and uint64. They represent signed and unsigned uint16, uint32, and uint64. They represent signed and unsigned
integers of different sizes: integers of different sizes:
skipping to change at page 138, line 34 skipping to change at page 141, line 50
An enumeration can be restricted with the "enum" (Section 9.6.4) An enumeration can be restricted with the "enum" (Section 9.6.4)
statement. statement.
9.6.4. The enum Statement 9.6.4. The enum Statement
The "enum" statement, which is a substatement to the "type" The "enum" statement, which is a substatement to the "type"
statement, MUST be present if the type is "enumeration". It is statement, MUST be present if the type is "enumeration". It is
repeatedly used to specify each assigned name of an enumeration type. repeatedly used to specify each assigned name of an enumeration type.
It takes as an argument a string which is the assigned name. The It takes as an argument a string which is the assigned name. The
string MUST NOT be empty and MUST NOT have any leading or trailing string MUST NOT be zero-length and MUST NOT have any leading or
whitespace characters. The use of Unicode control codes SHOULD be trailing whitespace characters (any Unicode character with the
"White_Space" property). The use of Unicode control codes SHOULD be
avoided. avoided.
The statement is optionally followed by a block of substatements that The statement is optionally followed by a block of substatements that
holds detailed enum information. holds detailed enum information.
All assigned names in an enumeration MUST be unique. All assigned names in an enumeration MUST be unique.
When an existing enumeration type is restricted, the set of assigned When an existing enumeration type is restricted, the set of assigned
names in the new type MUST be a subset of the base type's set of names in the new type MUST be a subset of the base type's set of
assigned names. The value of such an assigned name MUST not be assigned names. The value of such an assigned name MUST not be
skipping to change at page 141, line 34 skipping to change at page 144, line 46
changed. changed.
9.7.1. Restrictions 9.7.1. Restrictions
A bits type can be restricted with the "bit" (Section 9.7.4) A bits type can be restricted with the "bit" (Section 9.7.4)
statement. statement.
9.7.2. Lexical Representation 9.7.2. Lexical Representation
The lexical representation of the bits type is a space-separated list The lexical representation of the bits type is a space-separated list
of the individual bit values that are set. An empty string thus of the individual bit values that are set. A zero-length string thus
represents a value where no bits are set. represents a value where no bits are set.
9.7.3. Canonical Form 9.7.3. Canonical Form
In the canonical form, the bit values are separated by a single space In the canonical form, the bit values are separated by a single space
character and they appear ordered by their position (see character and they appear ordered by their position (see
Section 9.7.4.2). Section 9.7.4.2).
9.7.4. The bit Statement 9.7.4. The bit Statement
skipping to change at page 149, line 24 skipping to change at page 153, line 8
+ "/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>
<link-failure xmlns="http://acme.example.com/system"> <link-failure xmlns="urn:example:system">
<if-name>eth0</if-name> <if-name>eth0</if-name>
<admin-status>up</admin-status> <admin-status>up</admin-status>
</link-failure> </link-failure>
</notification> </notification>
9.10. The identityref Built-In Type 9.10. The identityref Built-In Type
The identityref type is used to reference an existing identity (see The identityref type is used to reference an existing identity (see
Section 7.18). Section 7.18).
skipping to change at page 151, line 5 skipping to change at page 154, line 22
9.10.4. Canonical Form 9.10.4. Canonical Form
Since the lexical form depends on the XML context in which the value Since the lexical form depends on the XML context in which the value
occurs, this type does not have a canonical form. occurs, this type does not have a canonical form.
9.10.5. Usage Example 9.10.5. Usage Example
With the identity definitions in Section 7.18.3 and the following With the identity definitions in Section 7.18.3 and the following
module: module:
module my-crypto { module example-my-crypto {
yang-version 1.1; yang-version 1.1;
namespace "http://example.com/my-crypto"; namespace "urn:example:my-crypto";
prefix mc; prefix mc;
import "crypto-base" { import "example-crypto-base" {
prefix "crypto"; prefix "crypto";
} }
identity aes { identity aes {
base "crypto:crypto-alg"; base "crypto:crypto-alg";
} }
leaf crypto { leaf crypto {
type identityref { type identityref {
base "crypto:crypto-alg"; base "crypto:crypto-alg";
skipping to change at page 151, line 33 skipping to change at page 154, line 50
container aes-parameters { container aes-parameters {
when "../crypto = 'mc:aes'"; when "../crypto = 'mc:aes'";
... ...
} }
} }
the following is an example how the leaf "crypto" can be encoded, if the following is an example how the leaf "crypto" can be encoded, if
the value is the "des3" identity defined in the "des" module: the value is the "des3" identity defined in the "des" module:
<crypto xmlns:des="http://example.com/des">des:des3</crypto> <crypto xmlns:des="urn:example:des">des:des3</crypto>
Any prefixes used in the encoding are local to each instance Any prefixes used in the encoding are local to each instance
encoding. This means that the same identityref may be encoded encoding. This means that the same identityref may be encoded
differently by different implementations. For example, the following differently by different implementations. For example, the following
example encodes the same leaf as above: example encodes the same leaf as above:
<crypto xmlns:x="http://example.com/des">x:des3</crypto> <crypto xmlns:x="urn:example:des">x:des3</crypto>
If the "crypto" leaf's value instead is "aes" defined in the If the "crypto" leaf's value instead is "aes" defined in the
"my-crypto" module, it can be encoded as: "example-my-crypto" module, it can be encoded as:
<crypto xmlns:mc="http://example.com/my-crypto">mc:aes</crypto> <crypto xmlns:mc="urn:example:my-crypto">mc:aes</crypto>
or, using the default namespace: or, using the default namespace:
<crypto>aes</crypto> <crypto>aes</crypto>
9.11. The empty Built-In Type 9.11. The empty Built-In Type
The empty built-in type represents a leaf that does not have any The empty built-in type represents a leaf that does not have any
value, it conveys information by its presence or absence. value, it conveys information by its presence or absence.
skipping to change at page 155, line 5 skipping to change at page 158, line 13
particular instance node in the data tree. particular instance node in the data tree.
The syntax for an instance-identifier is a subset of the XPath The syntax for an instance-identifier is a subset of the XPath
abbreviated syntax, formally defined by the rule abbreviated syntax, formally defined by the rule
"instance-identifier" in Section 14. It is used to uniquely identify "instance-identifier" in Section 14. It is used to uniquely identify
a node in the data tree. Predicates are used only for specifying the a node in the data tree. Predicates are used only for specifying the
values for the key nodes for list entries, a value of a leaf-list values for the key nodes for list entries, a value of a leaf-list
entry, or a positional index for a list without keys. For entry, or a positional index for a list without keys. For
identifying list entries with keys, each predicate consists of one identifying list entries with keys, each predicate consists of one
equality test per key, and each key MUST have a corresponding equality test per key, and each key MUST have a corresponding
predicate. predicate. If a key is of type "empty", it is represented as a zero-
length string ("").
If the leaf with the instance-identifier type represents If the leaf with the instance-identifier type represents
configuration data, and the "require-instance" property configuration data, and the "require-instance" property
(Section 9.9.3) is "true", the node it refers to MUST also represent (Section 9.9.3) is "true", the node it refers to MUST also represent
configuration. Such a leaf puts a constraint on valid data. All configuration. Such a leaf puts a constraint on valid data. All
such leaf nodes MUST reference existing nodes or leaf or leaf-list such leaf nodes MUST reference existing nodes or leaf or leaf-list
nodes with their default value in use (see Section 7.6.1 and nodes with their default value in use (see Section 7.6.1 and
Section 7.7.2) for the data to be valid. This constraint is enforced Section 7.7.2) for the data to be valid. This constraint is enforced
according to the rules in Section 8. according to the rules in Section 8.
skipping to change at page 156, line 20 skipping to change at page 159, line 24
/* instance-identifier for a list entry */ /* instance-identifier for a list entry */
/ex:system/ex:user[ex:name='fred'] /ex:system/ex:user[ex:name='fred']
/* instance-identifier for a leaf in a list entry */ /* instance-identifier for a leaf in a list entry */
/ex:system/ex:user[ex:name='fred']/ex:type /ex:system/ex:user[ex:name='fred']/ex:type
/* instance-identifier for a list entry with two keys */ /* instance-identifier for a list entry with two keys */
/ex:system/ex:server[ex:ip='192.0.2.1'][ex:port='80'] /ex:system/ex:server[ex:ip='192.0.2.1'][ex:port='80']
/* instance-identifier for a list entry where the second
key ("enabled") is of type empty */
/ex:system/ex:service[ex:name='foo'][ex:enabled='']
/* instance-identifier for a leaf-list entry */ /* instance-identifier for a leaf-list entry */
/ex:system/ex:services/ex:ssh/ex:cipher[.='blowfish-cbc'] /ex:system/ex:services/ex:ssh/ex:cipher[.='blowfish-cbc']
/* instance-identifier for a list entry without keys */ /* instance-identifier for a list entry without keys */
/ex:stats/ex:port[3] /ex:stats/ex:port[3]
10. XPath Functions 10. XPath Functions
This document defines two generic XPath functions and four YANG type- This document defines two generic XPath functions and four YANG type-
specific XPath functions. The function signatures are specified with specific XPath functions. The function signatures are specified with
skipping to change at page 158, line 33 skipping to change at page 162, line 22
} }
container mgmt-interface { container mgmt-interface {
leaf name { leaf name {
type leafref { type leafref {
path "/interface/name"; path "/interface/name";
} }
} }
leaf type { leaf type {
type leafref { type leafref {
path "/interface[name=current()/../name]/type"; path "/interface[name=current()/../name]/type";
}
must 'deref(.)/../enabled = "true"' { must 'deref(.)/../enabled = "true"' {
error-message error-message
"The management interface cannot be disabled."; "The management interface cannot be disabled.";
} }
} }
} }
10.4. Functions for the YANG Type "identityref" 10.4. Functions for the YANG Type "identityref"
10.4.1. derived-from() 10.4.1. derived-from()
skipping to change at page 160, line 24 skipping to change at page 164, line 15
The parameter "identity" is a string matching the rule The parameter "identity" is a string matching the rule
"identifier-ref" in Section 14. If a prefix is present on the "identifier-ref" in Section 14. If a prefix is present on the
identity, it refers to an identity defined in the module that was identity, it refers to an identity defined in the module that was
imported with that prefix, or the local module if the prefix matches imported with that prefix, or the local module if the prefix matches
the local module's prefix. If no prefix is present, the identity the local module's prefix. If no prefix is present, the identity
refers to an identity defined in the current module or an included refers to an identity defined in the current module or an included
submodule. submodule.
10.4.2.1. Usage Example 10.4.2.1. Usage Example
The module defined in ^derived-from-ex^ might also have: The module defined in Section 10.4.1.1 might also have:
augment "/interface" { augment "/interface" {
when 'derived-from-or-self(type, when 'derived-from-or-self(type, "exif:fast-ethernet");
"example-interface",
"fast-ethernet")';
// fast-ethernet-specific definitions here // fast-ethernet-specific definitions here
} }
10.5. Functions for the YANG Type "enumeration" 10.5. Functions for the YANG Type "enumeration"
10.5.1. enum-value() 10.5.1. enum-value()
number enum-value(node-set nodes) number enum-value(node-set nodes)
The enum-value() function checks if the first node in document order The enum-value() function checks if the first node in document order
skipping to change at page 162, line 21 skipping to change at page 166, line 21
} }
the following XPath expression can be used to select all interfaces the following XPath expression can be used to select all interfaces
with the UP flag set: with the UP flag set:
/interface[bit-is-set(flags, "UP")] /interface[bit-is-set(flags, "UP")]
11. Updating a Module 11. Updating a Module
As experience is gained with a module, it may be desirable to revise As experience is gained with a module, it may be desirable to revise
that module. However, changes are not allowed if they have any that module. However, changes to published modules are not allowed
potential to cause interoperability problems between a client using if they have any potential to cause interoperability problems between
an original specification and a server using an updated a client using an original specification and a server using an
specification. updated specification.
For any published change, a new "revision" statement (Section 7.1.9) For any published change, a new "revision" statement (Section 7.1.9)
MUST be included in front of the existing "revision" statements. If MUST be included in front of the existing "revision" statements. If
there are no existing "revision" statements, then one MUST be added there are no existing "revision" statements, then one MUST be added
to identify the new revision. Furthermore, any necessary changes to identify the new revision. Furthermore, any necessary changes
MUST be applied to any meta-data statements, including the MUST be applied to any meta-data statements, including the
"organization" and "contact" statements (Section 7.1.7, "organization" and "contact" statements (Section 7.1.7,
Section 7.1.8). Section 7.1.8).
Note that definitions contained in a module are available to be Note that definitions contained in a module are available to be
imported by any other module, and are referenced in "import" imported by any other module, and are referenced in "import"
statements via the module name. Thus, a module name MUST NOT be statements via the module name. Thus, a module name MUST NOT be
changed. Furthermore, the "namespace" statement MUST NOT be changed, changed. Furthermore, the "namespace" statement MUST NOT be changed,
since all XML elements are qualified by the namespace. since all XML elements are qualified by the namespace.
Obsolete definitions MUST NOT be removed from modules since their Obsolete definitions MUST NOT be removed from published modules since
identifiers may still be referenced by other modules. their identifiers may still be referenced by other modules.
A definition may be revised in any of the following ways: A definition in a published module may be revised in any of the
following ways:
o An "enumeration" type may have new enums added, provided the old o An "enumeration" type may have new enums added, provided the old
enums's values do not change. Note that inserting a new enum enums's values do not change. Note that inserting a new enum
before an existing enum or reordering existing enums will result before an existing enum or reordering existing enums will result
in new values for the existing enums, unless they have explicit in new values for the existing enums, unless they have explicit
values assigned to them. values assigned to them.
o A "bits" type may have new bits added, provided the old bit o A "bits" type may have new bits added, provided the old bit
positions do not change. Note that inserting a new bit before an positions do not change. Note that inserting a new bit before an
existing bit or reordering existing bit will result in new existing bit or reordering existing bit will result in new
skipping to change at page 164, line 36 skipping to change at page 168, line 39
o The "prefix" statement may be changed, provided all local uses of o The "prefix" statement may be changed, provided all local uses of
the prefix also are changed. the prefix also are changed.
Otherwise, if the semantics of any previous definition are changed Otherwise, if the semantics of any previous definition are changed
(i.e., if a non-editorial change is made to any definition other than (i.e., if a non-editorial change is made to any definition other than
those specifically allowed above), then this MUST be achieved by a those specifically allowed above), then this MUST be achieved by a
new definition with a new identifier. new definition with a new identifier.
In statements that have any data definition statements as In statements that have any data definition statements as
substatements, those data definition substatements MUST NOT be substatements, those data definition substatements MUST NOT be
reordered. reordered. If new data definition statements are added, they can be
added anywhere in the sequence of existing substatement.
12. Coexistence with YANG version 1 12. Coexistence with YANG version 1
A YANG version 1.1 module MUST NOT include a YANG version 1 A YANG version 1.1 module MUST NOT include a YANG version 1
submodule, and a YANG version 1 module MUST NOT include a YANG submodule, and a YANG version 1 module MUST NOT include a YANG
version 1.1 submodule. version 1.1 submodule.
A YANG version 1 module or submodule MUST NOT import a YANG version A YANG version 1 module or submodule MUST NOT import a YANG version
1.1 module by revision. 1.1 module by revision.
skipping to change at page 168, line 9 skipping to change at page 172, line 12
| yang-version | value | false | | yang-version | value | false |
| yin-element | value | false | | yin-element | value | false |
+------------------+---------------+-------------+ +------------------+---------------+-------------+
Table 1: Mapping of arguments of the YANG statements. Table 1: Mapping of arguments of the YANG statements.
13.1.1. Usage Example 13.1.1. Usage Example
The following YANG module: The following YANG module:
module acme-foo { module example-foo {
yang-version 1.1; yang-version 1.1;
namespace "http://acme.example.com/foo"; namespace "urn:example:foo";
prefix "acfoo"; prefix "foo";
import my-extensions { import example-extensions {
prefix "myext"; prefix "myext";
} }
list interface { list interface {
key "name"; key "name";
leaf name { leaf name {
type string; type string;
} }
leaf mtu { leaf mtu {
type uint32; type uint32;
description "The MTU of the interface."; description "The MTU of the interface.";
myext:c-define "MY_MTU"; myext:c-define "MY_MTU";
} }
} }
} }
where the extension "c-define" is defined in Section 7.19.3, is where the extension "c-define" is defined in Section 7.19.3, is
translated into the following YIN: translated into the following YIN:
<module name="acme-foo" <module name="example-foo"
xmlns="urn:ietf:params:xml:ns:yang:yin:1" xmlns="urn:ietf:params:xml:ns:yang:yin:1"
xmlns:acfoo="http://acme.example.com/foo" xmlns:foo="urn:example:foo"
xmlns:myext="http://example.com/my-extensions"> xmlns:myext="urn:example:extensions">
<namespace uri="http://acme.example.com/foo"/> <namespace uri="urn:example:foo"/>
<prefix value="acfoo"/> <prefix value="foo"/>
<import module="my-extensions"> <import module="example-extensions">
<prefix value="myext"/> <prefix value="myext"/>
</import> </import>
<list name="interface"> <list name="interface">
<key value="name"/> <key value="name"/>
<leaf name="name"> <leaf name="name">
<type name="string"/> <type name="string"/>
</leaf> </leaf>
<leaf name="mtu"> <leaf name="mtu">
<type name="uint32"/> <type name="uint32"/>
skipping to change at page 171, line 24 skipping to change at page 175, line 24
yang-version-arg-str = < a string that matches the rule > yang-version-arg-str = < a string that matches the rule >
< yang-version-arg > < yang-version-arg >
yang-version-arg = "1.1" yang-version-arg = "1.1"
import-stmt = import-keyword sep identifier-arg-str optsep import-stmt = import-keyword sep identifier-arg-str optsep
"{" stmtsep "{" stmtsep
;; these stmts can appear in any order ;; these stmts can appear in any order
prefix-stmt prefix-stmt
[revision-date-stmt] [revision-date-stmt]
[description-stmt]
[reference-stmt]
"}" stmtsep "}" stmtsep
include-stmt = include-keyword sep identifier-arg-str optsep include-stmt = include-keyword sep identifier-arg-str optsep
(";" / (";" /
"{" stmtsep "{" stmtsep
;; these stmts can appear in any order
[revision-date-stmt] [revision-date-stmt]
[description-stmt]
[reference-stmt]
"}") stmtsep "}") stmtsep
namespace-stmt = namespace-keyword sep uri-str stmtend namespace-stmt = namespace-keyword sep uri-str stmtend
uri-str = < a string that matches the rule > uri-str = < a string that matches the rule >
< URI in RFC 3986 > < URI in RFC 3986 >
prefix-stmt = prefix-keyword sep prefix-arg-str stmtend prefix-stmt = prefix-keyword sep prefix-arg-str stmtend
belongs-to-stmt = belongs-to-keyword sep identifier-arg-str belongs-to-stmt = belongs-to-keyword sep identifier-arg-str
skipping to change at page 195, line 5 skipping to change at page 199, line 16
If a NETCONF operation would result in configuration data where a If a NETCONF operation would result in configuration data where a
leaf of type "instance-identifier" or "leafref" marked with require- leaf of type "instance-identifier" or "leafref" marked with require-
instance "true" refers to a non-existing instance, the following instance "true" refers to a non-existing instance, the following
error is returned: error is returned:
error-tag: data-missing error-tag: data-missing
error-app-tag: instance-required error-app-tag: instance-required
error-path: Path to the instance-identifier or leafref leaf. error-path: Path to the instance-identifier or leafref leaf.
15.6. Error Message for Data That Does Not Match a leafref Type 15.6. Error Message for Data That Violates a mandatory choice Statement
If a NETCONF operation would result in configuration data where a
leaf of type "leafref" refers to a non-existing instance, the
following error is returned:
error-tag: data-missing
error-app-tag: instance-required
error-path: Path to the leafref leaf.
15.7. Error Message for Data That Violates a mandatory choice Statement
If a NETCONF operation would result in configuration data where no If a NETCONF operation would result in configuration data where no
nodes exists in a mandatory choice, the following error is returned: nodes exists in a mandatory choice, the following error is returned:
error-tag: data-missing error-tag: data-missing
error-app-tag: missing-choice error-app-tag: missing-choice
error-path: Path to the element with the missing choice. error-path: Path to the element with the missing choice.
error-info: <missing-choice>: Contains the name of the missing error-info: <missing-choice>: Contains the name of the missing
mandatory choice. mandatory choice.
The <missing-choice> element is in the YANG The <missing-choice> element is in the YANG
namespace ("urn:ietf:params:xml:ns:yang:1"). namespace ("urn:ietf:params:xml:ns:yang:1").
15.8. Error Message for the "insert" Operation 15.7. Error Message for the "insert" Operation
If the "insert" and "key" or "value" attributes are used in an If the "insert" and "key" or "value" attributes are used in an
<edit-config> for a list or leaf-list node, and the "key" or "value" <edit-config> for a list or leaf-list node, and the "key" or "value"
refers to a non-existing instance, the following error is returned: refers to a non-existing instance, the following error is returned:
error-tag: bad-attribute error-tag: bad-attribute
error-app-tag: missing-instance error-app-tag: missing-instance
16. IANA Considerations 16. IANA Considerations
skipping to change at page 197, line 9 skipping to change at page 201, line 9
provided helpful comments on various versions of this document: provided helpful comments on various versions of this document:
Mehmet Ersue, Washam Fan, Joel Halpern, Per Hedeland, Leif Johansson, Mehmet Ersue, Washam Fan, Joel Halpern, Per Hedeland, Leif Johansson,
Ladislav Lhotka, Gerhard Muenz, Peyman Owladi, Tom Petch, Randy Ladislav Lhotka, Gerhard Muenz, Peyman Owladi, Tom Petch, Randy
Presuhn, David Reid, Jernej Tuljak, Kent Watsen, Bert Wijnen, and Presuhn, David Reid, Jernej Tuljak, Kent Watsen, Bert Wijnen, and
Robert Wilton. Robert Wilton.
20. ChangeLog 20. ChangeLog
RFC Editor: remove this section upon publication as an RFC. RFC Editor: remove this section upon publication as an RFC.
20.1. Version -09 20.1. Version -10
o Made single and double quote characters illegal in unquoted
strings.
o Allow "description" and "reference" in "import" and "include".
o Removed redundant NETCONF Error Message subsection.
o Editorial fixes and clarifications after second WGLC reviews.
20.2. Version -09
o Editorial fixes and clarifications after WGLC reviews. o Editorial fixes and clarifications after WGLC reviews.
o when statement context clarification. o when statement context clarification.
o Allow "augment" to add conditionally mandatory nodes (see o Allow "augment" to add conditionally mandatory nodes (see
Section 7.17). Section 7.17).
o Allow non-unique config false leaf-lists. o Allow non-unique config false leaf-lists.
o Made handling of choice and false "when" expressions non-NETCONF o Made handling of choice and false "when" expressions non-NETCONF
specific. specific.
o Changed the function signatures for "derived-from" and o Changed the function signatures for "derived-from" and
"derived-from-or-self". "derived-from-or-self".
20.2. Version -08 20.3. Version -08
o Fixes after WGLC reviews. o Fixes after WGLC reviews.
20.3. Version -07 20.4. Version -07
o Fixes after WG review. o Fixes after WG review.
o Included solution Y60-01. o Included solution Y60-01.
20.4. Version -06 20.5. Version -06
o Included solution Y45-05. o Included solution Y45-05.
20.5. Version -05 20.6. Version -05
o Included solution Y18-01. o Included solution Y18-01.
o Included solution Y25-02 (parts of it was included in -04). o Included solution Y25-02 (parts of it was included in -04).
o Included solution Y34-05. o Included solution Y34-05.
o Included solution Y36-03. o Included solution Y36-03.
20.6. Version -04 20.7. Version -04
o Incorporated changes to ABNF grammar after review and errata for o Incorporated changes to ABNF grammar after review and errata for
RFC 6020. RFC 6020.
o Included solution Y16-03. o Included solution Y16-03.
o Included solution Y49-04. o Included solution Y49-04.
o Included solution Y58-01. o Included solution Y58-01.
o Included solution Y59-01. o Included solution Y59-01.
20.7. Version -03 20.8. Version -03
o Incorporated changes from WG reviews. o Incorporated changes from WG reviews.
o Included solution Y05-01. o Included solution Y05-01.
o Included solution Y10-01. o Included solution Y10-01.
o Included solution Y13-01. o Included solution Y13-01.
o Included solution Y28-02. o Included solution Y28-02.
o Included solution Y55-01 (parts of it was included in -01). o Included solution Y55-01 (parts of it was included in -01).
20.8. Version -02 20.9. Version -02
o Included solution Y02-01. o Included solution Y02-01.
o Included solution Y04-02. o Included solution Y04-02.
o Included solution Y11-01. o Included solution Y11-01.
o Included solution Y41-01. o Included solution Y41-01.
o Included solution Y56-01. o Included solution Y56-01.
20.9. Version -01 20.10. Version -01
o Included solution Y01-01. o Included solution Y01-01.
o Included solution Y03-01. o Included solution Y03-01.
o Included solution Y06-02. o Included solution Y06-02.
o Included solution Y07-01. o Included solution Y07-01.
o Included solution Y14-01. o Included solution Y14-01.
skipping to change at page 199, line 19 skipping to change at page 203, line 29
o Included solution Y23-01. o Included solution Y23-01.
o Included solution Y29-01. o Included solution Y29-01.
o Included solution Y30-01. o Included solution Y30-01.
o Included solution Y31-01. o Included solution Y31-01.
o Included solution Y35-01. o Included solution Y35-01.
20.10. Version -00 20.11. Version -00
o Applied all reported errata for RFC 6020. o Applied all reported errata for RFC 6020.
o Updated YANG version to 1.1, and made the "yang-version" statement o Updated YANG version to 1.1, and made the "yang-version" statement
mandatory. mandatory.
21. References 21. References
21.1. Normative References 21.1. Normative References
[I-D.ietf-netconf-yang-library] [I-D.ietf-netconf-yang-library]
Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module
Library", draft-ietf-netconf-yang-library (work in Library", draft-ietf-netconf-yang-library-04 (work in
progress), July 2015. progress), February 2016.
[ISO.10646] [ISO.10646]
International Organization for Standardization, International Organization for Standardization,
"Information Technology - Universal Multiple-Octet Coded "Information Technology - Universal Multiple-Octet Coded
Character Set (UCS)", ISO Standard 10646:2003, 2003. Character Set (UCS)", ISO Standard 10646:2003, 2003.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003. 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <http://www.rfc-editor.org/info/rfc3629>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC Resource Identifier (URI): Generic Syntax", STD 66,
3986, January 2005. RFC 3986, DOI 10.17487/RFC3986, January 2005,
<http://www.rfc-editor.org/info/rfc3986>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006. Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<http://www.rfc-editor.org/info/rfc4648>.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>.
[RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event
Notifications", RFC 5277, July 2008. Notifications", RFC 5277, DOI 10.17487/RFC5277, July 2008,
<http://www.rfc-editor.org/info/rfc5277>.
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
Bierman, "Network Configuration Protocol (NETCONF)", RFC and A. Bierman, Ed., "Network Configuration Protocol
6241, June 2011. (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<http://www.rfc-editor.org/info/rfc6241>.
[RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", RFC [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF",
7405, December 2014. RFC 7405, DOI 10.17487/RFC7405, December 2014,
<http://www.rfc-editor.org/info/rfc7405>.
[XML-NAMES] [XML-NAMES]
Hollander, D., Tobin, R., Thompson, H., Bray, T., and A. Bray, T., Hollander, D., Layman, A., Tobin, R., and H.
Layman, "Namespaces in XML 1.0 (Third Edition)", World Thompson, "Namespaces in XML 1.0 (Third Edition)", World
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 Recommendation Version 1.0", World Wide Web Consortium Recommendation
REC-xpath-19991116, November 1999, 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]
Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes
Second Edition", World Wide Web Consortium Recommendation Second Edition", World Wide Web Consortium Recommendation
REC-xmlschema-2-20041028, October 2004, REC-xmlschema-2-20041028, October 2004,
<http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>. <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
21.2. Informative References 21.2. Informative References
[I-D.ietf-netconf-restconf] [I-D.ietf-netconf-restconf]
Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", draft-ietf-netconf-restconf-07 (work in Protocol", draft-ietf-netconf-restconf-09 (work in
progress), July 2015. progress), December 2015.
[I-D.ietf-netmod-yang-json] [I-D.ietf-netmod-yang-json]
Lhotka, L., "JSON Encoding of Data Modeled with YANG", Lhotka, L., "JSON Encoding of Data Modeled with YANG",
draft-ietf-netmod-yang-json-04 (work in progress), June draft-ietf-netmod-yang-json-07 (work in progress), January
2015. 2016.
[I-D.vanderstok-core-comi] [I-D.vanderstok-core-comi]
Stok, P., Bierman, A., Schoenwaelder, J., and A. Sehgal, Stok, P., Bierman, A., Schoenwaelder, J., and A. Sehgal,
"CoAP Management Interface", draft-vanderstok-core-comi-07 "CoAP Management Interface", draft-vanderstok-core-comi-08
(work in progress), July 2015. (work in progress), October 2015.
[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,
DOI 10.17487/RFC2578, April 1999,
<http://www.rfc-editor.org/info/rfc2578>.
[RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD Schoenwaelder, Ed., "Textual Conventions for SMIv2",
58, RFC 2579, April 1999. STD 58, RFC 2579, DOI 10.17487/RFC2579, April 1999,
<http://www.rfc-editor.org/info/rfc2579>.
[RFC3780] Strauss, F. and J. Schoenwaelder, "SMIng - Next Generation [RFC3780] Strauss, F. and J. Schoenwaelder, "SMIng - Next Generation
Structure of Management Information", RFC 3780, May 2004. Structure of Management Information", RFC 3780,
DOI 10.17487/RFC3780, May 2004,
<http://www.rfc-editor.org/info/rfc3780>.
[RFC4844] Daigle, L. and Internet Architecture Board, "The RFC [RFC4844] Daigle, L., Ed. and Internet Architecture Board, "The RFC
Series and RFC Editor", RFC 4844, July 2007. Series and RFC Editor", RFC 4844, DOI 10.17487/RFC4844,
July 2007, <http://www.rfc-editor.org/info/rfc4844>.
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
Network Configuration Protocol (NETCONF)", RFC 6020, the Network Configuration Protocol (NETCONF)", RFC 6020,
October 2010. DOI 10.17487/RFC6020, October 2010,
<http://www.rfc-editor.org/info/rfc6020>.
[RFC6643] Schoenwaelder, J., "Translation of Structure of Management [RFC6643] Schoenwaelder, J., "Translation of Structure of Management
Information Version 2 (SMIv2) MIB Modules to YANG Information Version 2 (SMIv2) MIB Modules to YANG
Modules", RFC 6643, DOI 10.17487/RFC6643, July 2012, Modules", RFC 6643, DOI 10.17487/RFC6643, July 2012,
<http://www.rfc-editor.org/info/rfc6643>. <http://www.rfc-editor.org/info/rfc6643>.
[XPATH2.0] [XPATH2.0]
Berglund, A., Boag, S., Chamberlin, D., Fernandez, M., Berglund, A., Boag, S., Chamberlin, D., Fernandez, M.,
Kay, M., Robie, J., and J. Simeon, "XML Path Language Kay, M., Robie, J., and J. Simeon, "XML Path Language
(XPath) 2.0", World Wide Web Consortium Recommendation (XPath) 2.0 (Second Edition)", World Wide Web Consortium
REC-xpath20-20070123, January 2007, Recommendation REC-xpath20-20101214, December 2010,
<http://www.w3.org/TR/2007/REC-xpath20-20070123>. <http://www.w3.org/TR/2010/REC-xpath20-20101214>.
[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>.
Author's Address Author's Address
Martin Bjorklund (editor) Martin Bjorklund (editor)
Tail-f Systems Tail-f Systems
 End of changes. 197 change blocks. 
540 lines changed or deleted 605 lines changed or added

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