draft-ietf-netmod-rfc6020bis-12.txt   draft-ietf-netmod-rfc6020bis-13.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 April 28, 2016 Intended status: Standards Track June 10, 2016
Expires: October 30, 2016 Expires: December 12, 2016
The YANG 1.1 Data Modeling Language The YANG 1.1 Data Modeling Language
draft-ietf-netmod-rfc6020bis-12 draft-ietf-netmod-rfc6020bis-13
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. This document also specifies the YANG mappings management protocols. This document describes the syntax and
to the Network Configuration Protocol (NETCONF). semantics of version 1.1 of the YANG language. YANG version 1.1 is a
maintenance release of the YANG language, addressing ambiguities and
defects in the original specification. There are a small number of
backward incompatibilities from YANG version 1. This document also
specifies the YANG mappings to the Network Configuration Protocol
(NETCONF).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 30, 2016. This Internet-Draft will expire on December 12, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 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
skipping to change at page 2, line 24 skipping to change at page 2, line 28
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 . . . . . . . . . . . . 9
2. Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2. Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 11 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1. A Note on Examples . . . . . . . . . . . . . . . . . . . 14 3.1. A Note on Examples . . . . . . . . . . . . . . . . . . . 14
4. YANG Overview . . . . . . . . . . . . . . . . . . . . . . . . 14 4. YANG Overview . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1. Functional Overview . . . . . . . . . . . . . . . . . . . 14 4.1. Functional Overview . . . . . . . . . . . . . . . . . . . 15
4.2. Language Overview . . . . . . . . . . . . . . . . . . . . 16 4.2. Language Overview . . . . . . . . . . . . . . . . . . . . 16
4.2.1. Modules and Submodules . . . . . . . . . . . . . . . 16 4.2.1. Modules and Submodules . . . . . . . . . . . . . . . 16
4.2.2. Data Modeling Basics . . . . . . . . . . . . . . . . 16 4.2.2. Data Modeling Basics . . . . . . . . . . . . . . . . 17
4.2.3. State Data . . . . . . . . . . . . . . . . . . . . . 20 4.2.3. Configuration and State Data . . . . . . . . . . . . 21
4.2.4. Built-In Types . . . . . . . . . . . . . . . . . . . 21 4.2.4. Built-In Types . . . . . . . . . . . . . . . . . . . 21
4.2.5. Derived Types (typedef) . . . . . . . . . . . . . . . 22 4.2.5. Derived Types (typedef) . . . . . . . . . . . . . . . 22
4.2.6. Reusable Node Groups (grouping) . . . . . . . . . . . 23 4.2.6. Reusable Node Groups (grouping) . . . . . . . . . . . 23
4.2.7. Choices . . . . . . . . . . . . . . . . . . . . . . . 24 4.2.7. Choices . . . . . . . . . . . . . . . . . . . . . . . 24
4.2.8. Extending Data Models (augment) . . . . . . . . . . . 25 4.2.8. Extending Data Models (augment) . . . . . . . . . . . 25
4.2.9. Operation Definitions . . . . . . . . . . . . . . . . 26 4.2.9. Operation Definitions . . . . . . . . . . . . . . . . 26
4.2.10. Notification Definitions . . . . . . . . . . . . . . 29 4.2.10. Notification Definitions . . . . . . . . . . . . . . 29
5. Language Concepts . . . . . . . . . . . . . . . . . . . . . . 29 5. Language Concepts . . . . . . . . . . . . . . . . . . . . . . 29
5.1. Modules and Submodules . . . . . . . . . . . . . . . . . 29 5.1. Modules and Submodules . . . . . . . . . . . . . . . . . 29
5.1.1. Import and Include by Revision . . . . . . . . . . . 31 5.1.1. Import and Include by Revision . . . . . . . . . . . 31
5.1.2. Module Hierarchies . . . . . . . . . . . . . . . . . 32 5.1.2. Module Hierarchies . . . . . . . . . . . . . . . . . 32
5.2. File Layout . . . . . . . . . . . . . . . . . . . . . . . 33 5.2. File Layout . . . . . . . . . . . . . . . . . . . . . . . 33
5.3. XML Namespaces . . . . . . . . . . . . . . . . . . . . . 33 5.3. XML Namespaces . . . . . . . . . . . . . . . . . . . . . 34
5.3.1. YANG XML Namespace . . . . . . . . . . . . . . . . . 34 5.3.1. YANG XML Namespace . . . . . . . . . . . . . . . . . 34
5.4. Resolving Grouping, Type, and Identity Names . . . . . . 34 5.4. Resolving Grouping, Type, and Identity Names . . . . . . 34
5.5. Nested Typedefs and Groupings . . . . . . . . . . . . . . 34 5.5. Nested Typedefs and Groupings . . . . . . . . . . . . . . 34
5.6. Conformance . . . . . . . . . . . . . . . . . . . . . . . 35 5.6. Conformance . . . . . . . . . . . . . . . . . . . . . . . 35
5.6.1. Basic Behavior . . . . . . . . . . . . . . . . . . . 35 5.6.1. Basic Behavior . . . . . . . . . . . . . . . . . . . 36
5.6.2. Optional Features . . . . . . . . . . . . . . . . . . 35 5.6.2. Optional Features . . . . . . . . . . . . . . . . . . 36
5.6.3. Deviations . . . . . . . . . . . . . . . . . . . . . 36 5.6.3. Deviations . . . . . . . . . . . . . . . . . . . . . 36
5.6.4. Announcing Conformance Information in NETCONF . . . . 36 5.6.4. Announcing Conformance Information in NETCONF . . . . 37
5.6.5. Implementing a Module . . . . . . . . . . . . . . . . 37 5.6.5. Implementing a Module . . . . . . . . . . . . . . . . 38
5.7. Datastore Modification . . . . . . . . . . . . . . . . . 40 5.7. Datastore Modification . . . . . . . . . . . . . . . . . 41
6. YANG Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 41
6.1. Lexical Tokenization . . . . . . . . . . . . . . . . . . 42
6.1.1. Comments . . . . . . . . . . . . . . . . . . . . . . 42
6.1.2. Tokens . . . . . . . . . . . . . . . . . . . . . . . 42
6.1.3. Quoting . . . . . . . . . . . . . . . . . . . . . . . 42
6.2. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 44
6.2.1. Identifiers and Their Namespaces . . . . . . . . . . 44
6.3. Statements . . . . . . . . . . . . . . . . . . . . . . . 45
6.3.1. Language Extensions . . . . . . . . . . . . . . . . . 46
6.4. XPath Evaluations . . . . . . . . . . . . . . . . . . . . 46
6.4.1. XPath Context . . . . . . . . . . . . . . . . . . . . 47
6.5. Schema Node Identifier . . . . . . . . . . . . . . . . . 51
7. YANG Statements . . . . . . . . . . . . . . . . . . . . . . . 52
7.1. The module Statement . . . . . . . . . . . . . . . . . . 52
7.1.1. The module's Substatements . . . . . . . . . . . . . 53
7.1.2. The yang-version Statement . . . . . . . . . . . . . 54
7.1.3. The namespace Statement . . . . . . . . . . . . . . . 55
7.1.4. The prefix Statement . . . . . . . . . . . . . . . . 55
7.1.5. The import Statement . . . . . . . . . . . . . . . . 56
7.1.6. The include Statement . . . . . . . . . . . . . . . . 57
7.1.7. The organization Statement . . . . . . . . . . . . . 57
7.1.8. The contact Statement . . . . . . . . . . . . . . . . 58
7.1.9. The revision Statement . . . . . . . . . . . . . . . 58
7.1.10. Usage Example . . . . . . . . . . . . . . . . . . . . 58
7.2. The submodule Statement . . . . . . . . . . . . . . . . . 59
7.2.1. The submodule's Substatements . . . . . . . . . . . . 60
7.2.2. The belongs-to Statement . . . . . . . . . . . . . . 61
7.2.3. Usage Example . . . . . . . . . . . . . . . . . . . . 62
7.3. The typedef Statement . . . . . . . . . . . . . . . . . . 62
7.3.1. The typedef's Substatements . . . . . . . . . . . . . 63
7.3.2. The typedef's type Statement . . . . . . . . . . . . 63
7.3.3. The units Statement . . . . . . . . . . . . . . . . . 63
7.3.4. The typedef's default Statement . . . . . . . . . . . 63
7.3.5. Usage Example . . . . . . . . . . . . . . . . . . . . 64
7.4. The type Statement . . . . . . . . . . . . . . . . . . . 64
7.4.1. The type's Substatements . . . . . . . . . . . . . . 64
7.5. The container Statement . . . . . . . . . . . . . . . . . 64
7.5.1. Containers with Presence . . . . . . . . . . . . . . 65
7.5.2. The container's Substatements . . . . . . . . . . . . 65
7.5.3. The must Statement . . . . . . . . . . . . . . . . . 66
7.5.4. The must's Substatements . . . . . . . . . . . . . . 67
7.5.5. The presence Statement . . . . . . . . . . . . . . . 68
7.5.6. The container's Child Node Statements . . . . . . . . 68
7.5.7. XML Encoding Rules . . . . . . . . . . . . . . . . . 68
7.5.8. NETCONF <edit-config> Operations . . . . . . . . . . 69
7.5.9. Usage Example . . . . . . . . . . . . . . . . . . . . 69
7.6. The leaf Statement . . . . . . . . . . . . . . . . . . . 71
7.6.1. The leaf's default value . . . . . . . . . . . . . . 71
7.6.2. The leaf's Substatements . . . . . . . . . . . . . . 72
7.6.3. The leaf's type Statement . . . . . . . . . . . . . . 72
7.6.4. The leaf's default Statement . . . . . . . . . . . . 72
7.6.5. The leaf's mandatory Statement . . . . . . . . . . . 73
7.6.6. XML Encoding Rules . . . . . . . . . . . . . . . . . 73
7.6.7. NETCONF <edit-config> Operations . . . . . . . . . . 73
7.6.8. Usage Example . . . . . . . . . . . . . . . . . . . . 74
7.7. The leaf-list Statement . . . . . . . . . . . . . . . . . 74
7.7.1. Ordering . . . . . . . . . . . . . . . . . . . . . . 75
7.7.2. The leaf-list's default values . . . . . . . . . . . 75
7.7.3. The leaf-list's Substatements . . . . . . . . . . . . 76
7.7.4. The leaf-list's default Statement . . . . . . . . . . 77
7.7.5. The min-elements Statement . . . . . . . . . . . . . 77
7.7.6. The max-elements Statement . . . . . . . . . . . . . 78
7.7.7. The ordered-by Statement . . . . . . . . . . . . . . 78
7.7.8. XML Encoding Rules . . . . . . . . . . . . . . . . . 79
7.7.9. NETCONF <edit-config> Operations . . . . . . . . . . 79
7.7.10. Usage Example . . . . . . . . . . . . . . . . . . . . 80
7.8. The list Statement . . . . . . . . . . . . . . . . . . . 81
7.8.1. The list's Substatements . . . . . . . . . . . . . . 82
7.8.2. The list's key Statement . . . . . . . . . . . . . . 82
7.8.3. The list's unique Statement . . . . . . . . . . . . . 83
7.8.4. The list's Child Node Statements . . . . . . . . . . 84
7.8.5. XML Encoding Rules . . . . . . . . . . . . . . . . . 84
7.8.6. NETCONF <edit-config> Operations . . . . . . . . . . 85
7.8.7. Usage Example . . . . . . . . . . . . . . . . . . . . 86
7.9. The choice Statement . . . . . . . . . . . . . . . . . . 89
7.9.1. The choice's Substatements . . . . . . . . . . . . . 89
7.9.2. The choice's case Statement . . . . . . . . . . . . . 90
7.9.3. The choice's default Statement . . . . . . . . . . . 91
7.9.4. The choice's mandatory Statement . . . . . . . . . . 93
7.9.5. XML Encoding Rules . . . . . . . . . . . . . . . . . 93
7.9.6. Usage Example . . . . . . . . . . . . . . . . . . . . 93
7.10. The anydata Statement . . . . . . . . . . . . . . . . . . 94
7.10.1. The anydata's Substatements . . . . . . . . . . . . 95
7.10.2. XML Encoding Rules . . . . . . . . . . . . . . . . . 95
7.10.3. NETCONF <edit-config> Operations . . . . . . . . . . 95
7.10.4. Usage Example . . . . . . . . . . . . . . . . . . . 96
7.11. The anyxml Statement . . . . . . . . . . . . . . . . . . 97
7.11.1. The anyxml's Substatements . . . . . . . . . . . . . 97
7.11.2. XML Encoding Rules . . . . . . . . . . . . . . . . . 97
7.11.3. NETCONF <edit-config> Operations . . . . . . . . . . 98
7.11.4. Usage Example . . . . . . . . . . . . . . . . . . . 98
6. YANG Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 40 7.12. The grouping Statement . . . . . . . . . . . . . . . . . 99
6.1. Lexical Tokenization . . . . . . . . . . . . . . . . . . 41 7.12.1. The grouping's Substatements . . . . . . . . . . . . 99
6.1.1. Comments . . . . . . . . . . . . . . . . . . . . . . 41 7.12.2. Usage Example . . . . . . . . . . . . . . . . . . . 100
6.1.2. Tokens . . . . . . . . . . . . . . . . . . . . . . . 41 7.13. The uses Statement . . . . . . . . . . . . . . . . . . . 100
6.1.3. Quoting . . . . . . . . . . . . . . . . . . . . . . . 41 7.13.1. The uses's Substatements . . . . . . . . . . . . . . 101
6.2. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 43 7.13.2. The refine Statement . . . . . . . . . . . . . . . . 101
6.2.1. Identifiers and Their Namespaces . . . . . . . . . . 43 7.13.3. XML Encoding Rules . . . . . . . . . . . . . . . . . 102
6.3. Statements . . . . . . . . . . . . . . . . . . . . . . . 44 7.13.4. Usage Example . . . . . . . . . . . . . . . . . . . 102
6.3.1. Language Extensions . . . . . . . . . . . . . . . . . 44 7.14. The rpc Statement . . . . . . . . . . . . . . . . . . . . 103
6.4. XPath Evaluations . . . . . . . . . . . . . . . . . . . . 45 7.14.1. The rpc's Substatements . . . . . . . . . . . . . . 103
6.4.1. XPath Context . . . . . . . . . . . . . . . . . . . . 45 7.14.2. The input Statement . . . . . . . . . . . . . . . . 104
6.5. Schema Node Identifier . . . . . . . . . . . . . . . . . 50 7.14.3. The output Statement . . . . . . . . . . . . . . . . 105
7. YANG Statements . . . . . . . . . . . . . . . . . . . . . . . 51 7.14.4. NETCONF XML Encoding Rules . . . . . . . . . . . . . 106
7.1. The module Statement . . . . . . . . . . . . . . . . . . 51 7.14.5. Usage Example . . . . . . . . . . . . . . . . . . . 106
7.1.1. The module's Substatements . . . . . . . . . . . . . 52 7.15. The action Statement . . . . . . . . . . . . . . . . . . 107
7.1.2. The yang-version Statement . . . . . . . . . . . . . 53 7.15.1. The action's Substatements . . . . . . . . . . . . . 108
7.1.3. The namespace Statement . . . . . . . . . . . . . . . 54 7.15.2. NETCONF XML Encoding Rules . . . . . . . . . . . . . 108
7.1.4. The prefix Statement . . . . . . . . . . . . . . . . 54 7.15.3. Usage Example . . . . . . . . . . . . . . . . . . . 109
7.1.5. The import Statement . . . . . . . . . . . . . . . . 54 7.16. The notification Statement . . . . . . . . . . . . . . . 110
7.1.6. The include Statement . . . . . . . . . . . . . . . . 56 7.16.1. The notification's Substatements . . . . . . . . . . 111
7.1.7. The organization Statement . . . . . . . . . . . . . 56 7.16.2. NETCONF XML Encoding Rules . . . . . . . . . . . . . 111
7.1.8. The contact Statement . . . . . . . . . . . . . . . . 56 7.16.3. Usage Example . . . . . . . . . . . . . . . . . . . 112
7.1.9. The revision Statement . . . . . . . . . . . . . . . 57 7.17. The augment Statement . . . . . . . . . . . . . . . . . . 113
7.1.10. Usage Example . . . . . . . . . . . . . . . . . . . . 57 7.17.1. The augment's Substatements . . . . . . . . . . . . 115
7.2. The submodule Statement . . . . . . . . . . . . . . . . . 58 7.17.2. XML Encoding Rules . . . . . . . . . . . . . . . . . 116
7.2.1. The submodule's Substatements . . . . . . . . . . . . 59 7.17.3. Usage Example . . . . . . . . . . . . . . . . . . . 116
7.2.2. The belongs-to Statement . . . . . . . . . . . . . . 60 7.18. The identity Statement . . . . . . . . . . . . . . . . . 118
7.2.3. Usage Example . . . . . . . . . . . . . . . . . . . . 61 7.18.1. The identity's Substatements . . . . . . . . . . . . 118
7.3. The typedef Statement . . . . . . . . . . . . . . . . . . 61 7.18.2. The base Statement . . . . . . . . . . . . . . . . . 118
7.3.1. The typedef's Substatements . . . . . . . . . . . . . 62 7.18.3. Usage Example . . . . . . . . . . . . . . . . . . . 119
7.3.2. The typedef's type Statement . . . . . . . . . . . . 62 7.19. The extension Statement . . . . . . . . . . . . . . . . . 121
7.3.3. The units Statement . . . . . . . . . . . . . . . . . 62 7.19.1. The extension's Substatements . . . . . . . . . . . 121
7.3.4. The typedef's default Statement . . . . . . . . . . . 62 7.19.2. The argument Statement . . . . . . . . . . . . . . . 121
7.3.5. Usage Example . . . . . . . . . . . . . . . . . . . . 63 7.19.3. Usage Example . . . . . . . . . . . . . . . . . . . 122
7.4. The type Statement . . . . . . . . . . . . . . . . . . . 63 7.20. Conformance-Related Statements . . . . . . . . . . . . . 123
7.4.1. The type's Substatements . . . . . . . . . . . . . . 63 7.20.1. The feature Statement . . . . . . . . . . . . . . . 123
7.5. The container Statement . . . . . . . . . . . . . . . . . 63 7.20.2. The if-feature Statement . . . . . . . . . . . . . . 125
7.5.1. Containers with Presence . . . . . . . . . . . . . . 64 7.20.3. The deviation Statement . . . . . . . . . . . . . . 125
7.5.2. The container's Substatements . . . . . . . . . . . . 64 7.21. Common Statements . . . . . . . . . . . . . . . . . . . . 129
7.5.3. The must Statement . . . . . . . . . . . . . . . . . 65 7.21.1. The config Statement . . . . . . . . . . . . . . . . 129
7.5.4. The must's Substatements . . . . . . . . . . . . . . 66 7.21.2. The status Statement . . . . . . . . . . . . . . . . 129
7.5.5. The presence Statement . . . . . . . . . . . . . . . 67 7.21.3. The description Statement . . . . . . . . . . . . . 130
7.5.6. The container's Child Node Statements . . . . . . . . 67 7.21.4. The reference Statement . . . . . . . . . . . . . . 130
7.5.7. XML Encoding Rules . . . . . . . . . . . . . . . . . 67 7.21.5. The when Statement . . . . . . . . . . . . . . . . . 131
7.5.8. NETCONF <edit-config> Operations . . . . . . . . . . 68 8. Constraints . . . . . . . . . . . . . . . . . . . . . . . . . 132
7.5.9. Usage Example . . . . . . . . . . . . . . . . . . . . 68 8.1. Constraints on Data . . . . . . . . . . . . . . . . . . . 132
7.6. The leaf Statement . . . . . . . . . . . . . . . . . . . 69 8.2. Configuration Data Modifications . . . . . . . . . . . . 133
7.6.1. The leaf's default value . . . . . . . . . . . . . . 69 8.3. NETCONF Constraint Enforcement Model . . . . . . . . . . 133
7.6.2. The leaf's Substatements . . . . . . . . . . . . . . 70 8.3.1. Payload Parsing . . . . . . . . . . . . . . . . . . . 133
7.6.3. The leaf's type Statement . . . . . . . . . . . . . . 71 8.3.2. NETCONF <edit-config> Processing . . . . . . . . . . 134
7.6.4. The leaf's default Statement . . . . . . . . . . . . 71 8.3.3. Validation . . . . . . . . . . . . . . . . . . . . . 135
7.6.5. The leaf's mandatory Statement . . . . . . . . . . . 71 9. Built-In Types . . . . . . . . . . . . . . . . . . . . . . . 135
7.6.6. XML Encoding Rules . . . . . . . . . . . . . . . . . 72 9.1. Canonical Representation . . . . . . . . . . . . . . . . 135
7.6.7. NETCONF <edit-config> Operations . . . . . . . . . . 72 9.2. The Integer Built-In Types . . . . . . . . . . . . . . . 136
7.6.8. Usage Example . . . . . . . . . . . . . . . . . . . . 72 9.2.1. Lexical Representation . . . . . . . . . . . . . . . 136
7.7. The leaf-list Statement . . . . . . . . . . . . . . . . . 73 9.2.2. Canonical Form . . . . . . . . . . . . . . . . . . . 137
7.7.1. Ordering . . . . . . . . . . . . . . . . . . . . . . 73 9.2.3. Restrictions . . . . . . . . . . . . . . . . . . . . 137
7.7.2. The leaf-list's default values . . . . . . . . . . . 74 9.2.4. The range Statement . . . . . . . . . . . . . . . . . 137
7.7.3. The leaf-list's Substatements . . . . . . . . . . . . 75 9.2.5. Usage Example . . . . . . . . . . . . . . . . . . . . 138
7.7.4. The leaf-list's default Statement . . . . . . . . . . 75 9.3. The decimal64 Built-In Type . . . . . . . . . . . . . . . 138
7.7.5. The min-elements Statement . . . . . . . . . . . . . 76 9.3.1. Lexical Representation . . . . . . . . . . . . . . . 139
7.7.6. The max-elements Statement . . . . . . . . . . . . . 76 9.3.2. Canonical Form . . . . . . . . . . . . . . . . . . . 139
7.7.7. The ordered-by Statement . . . . . . . . . . . . . . 76 9.3.3. Restrictions . . . . . . . . . . . . . . . . . . . . 139
7.7.8. XML Encoding Rules . . . . . . . . . . . . . . . . . 77 9.3.4. The fraction-digits Statement . . . . . . . . . . . . 139
7.7.9. NETCONF <edit-config> Operations . . . . . . . . . . 77 9.3.5. Usage Example . . . . . . . . . . . . . . . . . . . . 140
7.7.10. Usage Example . . . . . . . . . . . . . . . . . . . . 78 9.4. The string Built-In Type . . . . . . . . . . . . . . . . 140
7.8. The list Statement . . . . . . . . . . . . . . . . . . . 80 9.4.1. Lexical Representation . . . . . . . . . . . . . . . 140
7.8.1. The list's Substatements . . . . . . . . . . . . . . 80 9.4.2. Canonical Form . . . . . . . . . . . . . . . . . . . 141
7.8.2. The list's key Statement . . . . . . . . . . . . . . 81 9.4.3. Restrictions . . . . . . . . . . . . . . . . . . . . 141
7.8.3. The list's unique Statement . . . . . . . . . . . . . 82 9.4.4. The length Statement . . . . . . . . . . . . . . . . 141
7.8.4. The list's Child Node Statements . . . . . . . . . . 83 9.4.5. The pattern Statement . . . . . . . . . . . . . . . . 142
7.8.5. XML Encoding Rules . . . . . . . . . . . . . . . . . 83 9.4.6. The modifier Statement . . . . . . . . . . . . . . . 142
7.8.6. NETCONF <edit-config> Operations . . . . . . . . . . 84 9.4.7. Usage Example . . . . . . . . . . . . . . . . . . . . 142
7.8.7. Usage Example . . . . . . . . . . . . . . . . . . . . 85 9.5. The boolean Built-In Type . . . . . . . . . . . . . . . . 144
7.9. The choice Statement . . . . . . . . . . . . . . . . . . 88 9.5.1. Lexical Representation . . . . . . . . . . . . . . . 144
7.9.1. The choice's Substatements . . . . . . . . . . . . . 88 9.5.2. Canonical Form . . . . . . . . . . . . . . . . . . . 144
7.9.2. The choice's case Statement . . . . . . . . . . . . . 89 9.5.3. Restrictions . . . . . . . . . . . . . . . . . . . . 144
7.9.3. The choice's default Statement . . . . . . . . . . . 90 9.6. The enumeration Built-In Type . . . . . . . . . . . . . . 144
7.9.4. The choice's mandatory Statement . . . . . . . . . . 92 9.6.1. Lexical Representation . . . . . . . . . . . . . . . 144
7.9.5. XML Encoding Rules . . . . . . . . . . . . . . . . . 92 9.6.2. Canonical Form . . . . . . . . . . . . . . . . . . . 144
7.9.6. Usage Example . . . . . . . . . . . . . . . . . . . . 92 9.6.3. Restrictions . . . . . . . . . . . . . . . . . . . . 144
7.10. The anydata Statement . . . . . . . . . . . . . . . . . . 93 9.6.4. The enum Statement . . . . . . . . . . . . . . . . . 144
7.10.1. The anydata's Substatements . . . . . . . . . . . . 94 9.6.5. Usage Example . . . . . . . . . . . . . . . . . . . . 146
7.10.2. XML Encoding Rules . . . . . . . . . . . . . . . . . 94 9.7. The bits Built-In Type . . . . . . . . . . . . . . . . . 147
7.10.3. NETCONF <edit-config> Operations . . . . . . . . . . 94 9.7.1. Restrictions . . . . . . . . . . . . . . . . . . . . 147
7.10.4. Usage Example . . . . . . . . . . . . . . . . . . . 95 9.7.2. Lexical Representation . . . . . . . . . . . . . . . 147
7.11. The anyxml Statement . . . . . . . . . . . . . . . . . . 95 9.7.3. Canonical Form . . . . . . . . . . . . . . . . . . . 148
7.11.1. The anyxml's Substatements . . . . . . . . . . . . . 96 9.7.4. The bit Statement . . . . . . . . . . . . . . . . . . 148
7.11.2. XML Encoding Rules . . . . . . . . . . . . . . . . . 96 9.7.5. Usage Example . . . . . . . . . . . . . . . . . . . . 149
7.11.3. NETCONF <edit-config> Operations . . . . . . . . . . 96 9.8. The binary Built-In Type . . . . . . . . . . . . . . . . 150
7.11.4. Usage Example . . . . . . . . . . . . . . . . . . . 97 9.8.1. Restrictions . . . . . . . . . . . . . . . . . . . . 150
7.12. The grouping Statement . . . . . . . . . . . . . . . . . 97 9.8.2. Lexical Representation . . . . . . . . . . . . . . . 150
7.12.1. The grouping's Substatements . . . . . . . . . . . . 98 9.8.3. Canonical Form . . . . . . . . . . . . . . . . . . . 150
7.12.2. Usage Example . . . . . . . . . . . . . . . . . . . 99 9.9. The leafref Built-In Type . . . . . . . . . . . . . . . . 150
7.13. The uses Statement . . . . . . . . . . . . . . . . . . . 99 9.9.1. Restrictions . . . . . . . . . . . . . . . . . . . . 151
7.13.1. The uses's Substatements . . . . . . . . . . . . . . 99 9.9.2. The path Statement . . . . . . . . . . . . . . . . . 151
7.13.2. The refine Statement . . . . . . . . . . . . . . . . 100 9.9.3. The require-instance Statement . . . . . . . . . . . 152
7.13.3. XML Encoding Rules . . . . . . . . . . . . . . . . . 101 9.9.4. Lexical Representation . . . . . . . . . . . . . . . 152
7.13.4. Usage Example . . . . . . . . . . . . . . . . . . . 101 9.9.5. Canonical Form . . . . . . . . . . . . . . . . . . . 152
7.14. The rpc Statement . . . . . . . . . . . . . . . . . . . . 102 9.9.6. Usage Example . . . . . . . . . . . . . . . . . . . . 152
7.14.1. The rpc's Substatements . . . . . . . . . . . . . . 102 9.10. The identityref Built-In Type . . . . . . . . . . . . . . 156
7.14.2. The input Statement . . . . . . . . . . . . . . . . 103 9.10.1. Restrictions . . . . . . . . . . . . . . . . . . . . 156
7.14.3. The output Statement . . . . . . . . . . . . . . . . 104 9.10.2. The identityref's base Statement . . . . . . . . . . 156
7.14.4. NETCONF XML Encoding Rules . . . . . . . . . . . . . 105 9.10.3. Lexical Representation . . . . . . . . . . . . . . . 156
7.14.5. Usage Example . . . . . . . . . . . . . . . . . . . 105 9.10.4. Canonical Form . . . . . . . . . . . . . . . . . . . 157
7.15. The action Statement . . . . . . . . . . . . . . . . . . 106 9.10.5. Usage Example . . . . . . . . . . . . . . . . . . . 157
7.15.1. The action's Substatements . . . . . . . . . . . . . 107 9.11. The empty Built-In Type . . . . . . . . . . . . . . . . . 158
7.15.2. NETCONF XML Encoding Rules . . . . . . . . . . . . . 107 9.11.1. Restrictions . . . . . . . . . . . . . . . . . . . . 158
7.15.3. Usage Example . . . . . . . . . . . . . . . . . . . 107 9.11.2. Lexical Representation . . . . . . . . . . . . . . . 158
7.16. The notification Statement . . . . . . . . . . . . . . . 109 9.11.3. Canonical Form . . . . . . . . . . . . . . . . . . . 158
7.16.1. The notification's Substatements . . . . . . . . . . 110 9.11.4. Usage Example . . . . . . . . . . . . . . . . . . . 158
7.16.2. NETCONF XML Encoding Rules . . . . . . . . . . . . . 110 9.12. The union Built-In Type . . . . . . . . . . . . . . . . . 159
7.16.3. Usage Example . . . . . . . . . . . . . . . . . . . 111 9.12.1. Restrictions . . . . . . . . . . . . . . . . . . . . 159
7.17. The augment Statement . . . . . . . . . . . . . . . . . . 112 9.12.2. Lexical Representation . . . . . . . . . . . . . . . 159
7.17.1. The augment's Substatements . . . . . . . . . . . . 114 9.12.3. Canonical Form . . . . . . . . . . . . . . . . . . . 159
7.17.2. XML Encoding Rules . . . . . . . . . . . . . . . . . 115 9.12.4. Usage Example . . . . . . . . . . . . . . . . . . . 159
7.17.3. Usage Example . . . . . . . . . . . . . . . . . . . 115 9.13. The instance-identifier Built-In Type . . . . . . . . . . 160
7.18. The identity Statement . . . . . . . . . . . . . . . . . 117 9.13.1. Restrictions . . . . . . . . . . . . . . . . . . . . 161
7.18.1. The identity's Substatements . . . . . . . . . . . . 117 9.13.2. Lexical Representation . . . . . . . . . . . . . . . 161
7.18.2. The base Statement . . . . . . . . . . . . . . . . . 117 9.13.3. Canonical Form . . . . . . . . . . . . . . . . . . . 161
7.18.3. Usage Example . . . . . . . . . . . . . . . . . . . 118 9.13.4. Usage Example . . . . . . . . . . . . . . . . . . . 162
7.19. The extension Statement . . . . . . . . . . . . . . . . . 120 10. XPath Functions . . . . . . . . . . . . . . . . . . . . . . . 162
7.19.1. The extension's Substatements . . . . . . . . . . . 120 10.1. Functions for Node Sets . . . . . . . . . . . . . . . . 162
7.19.2. The argument Statement . . . . . . . . . . . . . . . 120 10.1.1. current() . . . . . . . . . . . . . . . . . . . . . 162
7.19.3. Usage Example . . . . . . . . . . . . . . . . . . . 121 10.2. Functions for Strings . . . . . . . . . . . . . . . . . 163
7.20. Conformance-Related Statements . . . . . . . . . . . . . 122 10.2.1. re-match() . . . . . . . . . . . . . . . . . . . . . 163
7.20.1. The feature Statement . . . . . . . . . . . . . . . 122
7.20.2. The if-feature Statement . . . . . . . . . . . . . . 124
7.20.3. The deviation Statement . . . . . . . . . . . . . . 124
7.21. Common Statements . . . . . . . . . . . . . . . . . . . . 128
7.21.1. The config Statement . . . . . . . . . . . . . . . . 128
7.21.2. The status Statement . . . . . . . . . . . . . . . . 128
7.21.3. The description Statement . . . . . . . . . . . . . 129
7.21.4. The reference Statement . . . . . . . . . . . . . . 129
7.21.5. The when Statement . . . . . . . . . . . . . . . . . 130
8. Constraints . . . . . . . . . . . . . . . . . . . . . . . . . 131
8.1. Constraints on Data . . . . . . . . . . . . . . . . . . . 131
8.2. Configuration Data Modifications . . . . . . . . . . . . 132
8.3. NETCONF Constraint Enforcement Model . . . . . . . . . . 132
8.3.1. Payload Parsing . . . . . . . . . . . . . . . . . . . 132
8.3.2. NETCONF <edit-config> Processing . . . . . . . . . . 133
8.3.3. Validation . . . . . . . . . . . . . . . . . . . . . 134
9. Built-In Types . . . . . . . . . . . . . . . . . . . . . . . 134
9.1. Canonical Representation . . . . . . . . . . . . . . . . 134
9.2. The Integer Built-In Types . . . . . . . . . . . . . . . 135
9.2.1. Lexical Representation . . . . . . . . . . . . . . . 135
9.2.2. Canonical Form . . . . . . . . . . . . . . . . . . . 136
9.2.3. Restrictions . . . . . . . . . . . . . . . . . . . . 136
9.2.4. The range Statement . . . . . . . . . . . . . . . . . 136
9.2.5. Usage Example . . . . . . . . . . . . . . . . . . . . 137
9.3. The decimal64 Built-In Type . . . . . . . . . . . . . . . 137
9.3.1. Lexical Representation . . . . . . . . . . . . . . . 138
9.3.2. Canonical Form . . . . . . . . . . . . . . . . . . . 138
9.3.3. Restrictions . . . . . . . . . . . . . . . . . . . . 138
9.3.4. The fraction-digits Statement . . . . . . . . . . . . 138
9.3.5. Usage Example . . . . . . . . . . . . . . . . . . . . 139
9.4. The string Built-In Type . . . . . . . . . . . . . . . . 139
9.4.1. Lexical Representation . . . . . . . . . . . . . . . 139
9.4.2. Canonical Form . . . . . . . . . . . . . . . . . . . 140
9.4.3. Restrictions . . . . . . . . . . . . . . . . . . . . 140
9.4.4. The length Statement . . . . . . . . . . . . . . . . 140
9.4.5. The pattern Statement . . . . . . . . . . . . . . . . 141
9.4.6. The modifier Statement . . . . . . . . . . . . . . . 141
9.4.7. Usage Example . . . . . . . . . . . . . . . . . . . . 141
9.5. The boolean Built-In Type . . . . . . . . . . . . . . . . 143
9.5.1. Lexical Representation . . . . . . . . . . . . . . . 143
9.5.2. Canonical Form . . . . . . . . . . . . . . . . . . . 143
9.5.3. Restrictions . . . . . . . . . . . . . . . . . . . . 143
9.6. The enumeration Built-In Type . . . . . . . . . . . . . . 143
9.6.1. Lexical Representation . . . . . . . . . . . . . . . 143
9.6.2. Canonical Form . . . . . . . . . . . . . . . . . . . 143
9.6.3. Restrictions . . . . . . . . . . . . . . . . . . . . 143
9.6.4. The enum Statement . . . . . . . . . . . . . . . . . 143
9.6.5. Usage Example . . . . . . . . . . . . . . . . . . . . 145
9.7. The bits Built-In Type . . . . . . . . . . . . . . . . . 146
9.7.1. Restrictions . . . . . . . . . . . . . . . . . . . . 146
9.7.2. Lexical Representation . . . . . . . . . . . . . . . 146
9.7.3. Canonical Form . . . . . . . . . . . . . . . . . . . 147
9.7.4. The bit Statement . . . . . . . . . . . . . . . . . . 147
9.7.5. Usage Example . . . . . . . . . . . . . . . . . . . . 148
9.8. The binary Built-In Type . . . . . . . . . . . . . . . . 149
9.8.1. Restrictions . . . . . . . . . . . . . . . . . . . . 149
9.8.2. Lexical Representation . . . . . . . . . . . . . . . 149
9.8.3. Canonical Form . . . . . . . . . . . . . . . . . . . 149
9.9. The leafref Built-In Type . . . . . . . . . . . . . . . . 149
9.9.1. Restrictions . . . . . . . . . . . . . . . . . . . . 150
9.9.2. The path Statement . . . . . . . . . . . . . . . . . 150
9.9.3. The require-instance Statement . . . . . . . . . . . 150
9.9.4. Lexical Representation . . . . . . . . . . . . . . . 151
9.9.5. Canonical Form . . . . . . . . . . . . . . . . . . . 151
9.9.6. Usage Example . . . . . . . . . . . . . . . . . . . . 151
9.10. The identityref Built-In Type . . . . . . . . . . . . . . 155
9.10.1. Restrictions . . . . . . . . . . . . . . . . . . . . 155
9.10.2. The identityref's base Statement . . . . . . . . . . 155
9.10.3. Lexical Representation . . . . . . . . . . . . . . . 155
9.10.4. Canonical Form . . . . . . . . . . . . . . . . . . . 156
9.10.5. Usage Example . . . . . . . . . . . . . . . . . . . 156
9.11. The empty Built-In Type . . . . . . . . . . . . . . . . . 157
9.11.1. Restrictions . . . . . . . . . . . . . . . . . . . . 157
9.11.2. Lexical Representation . . . . . . . . . . . . . . . 157
9.11.3. Canonical Form . . . . . . . . . . . . . . . . . . . 157
9.11.4. Usage Example . . . . . . . . . . . . . . . . . . . 157
9.12. The union Built-In Type . . . . . . . . . . . . . . . . . 158
9.12.1. Restrictions . . . . . . . . . . . . . . . . . . . . 158
9.12.2. Lexical Representation . . . . . . . . . . . . . . . 158
9.12.3. Canonical Form . . . . . . . . . . . . . . . . . . . 158
9.12.4. Usage Example . . . . . . . . . . . . . . . . . . . 158
9.13. The instance-identifier Built-In Type . . . . . . . . . . 159
9.13.1. Restrictions . . . . . . . . . . . . . . . . . . . . 160
9.13.2. Lexical Representation . . . . . . . . . . . . . . . 160
9.13.3. Canonical Form . . . . . . . . . . . . . . . . . . . 160
9.13.4. Usage Example . . . . . . . . . . . . . . . . . . . 161
10. XPath Functions . . . . . . . . . . . . . . . . . . . . . . . 161
10.1. Functions for Node Sets . . . . . . . . . . . . . . . . 161
10.1.1. current() . . . . . . . . . . . . . . . . . . . . . 161
10.2. Functions for Strings . . . . . . . . . . . . . . . . . 162
10.2.1. re-match() . . . . . . . . . . . . . . . . . . . . . 162
10.3. Functions for the YANG Types "leafref" and "instance- 10.3. Functions for the YANG Types "leafref" and "instance-
identifier" . . . . . . . . . . . . . . . . . . . . . . 163 identifier" . . . . . . . . . . . . . . . . . . . . . . 164
10.3.1. deref() . . . . . . . . . . . . . . . . . . . . . . 163 10.3.1. deref() . . . . . . . . . . . . . . . . . . . . . . 164
10.4. Functions for the YANG Type "identityref" . . . . . . . 164 10.4. Functions for the YANG Type "identityref" . . . . . . . 165
10.4.1. derived-from() . . . . . . . . . . . . . . . . . . . 164 10.4.1. derived-from() . . . . . . . . . . . . . . . . . . . 165
10.4.2. derived-from-or-self() . . . . . . . . . . . . . . . 165 10.4.2. derived-from-or-self() . . . . . . . . . . . . . . . 166
10.5. Functions for the YANG Type "enumeration" . . . . . . . 166 10.5. Functions for the YANG Type "enumeration" . . . . . . . 167
10.5.1. enum-value() . . . . . . . . . . . . . . . . . . . . 166 10.5.1. enum-value() . . . . . . . . . . . . . . . . . . . . 167
10.6. Functions for the YANG Type "bits" . . . . . . . . . . . 167 10.6. Functions for the YANG Type "bits" . . . . . . . . . . . 168
10.6.1. bit-is-set() . . . . . . . . . . . . . . . . . . . . 167 10.6.1. bit-is-set() . . . . . . . . . . . . . . . . . . . . 168
11. Updating a Module . . . . . . . . . . . . . . . . . . . . . . 168 11. Updating a Module . . . . . . . . . . . . . . . . . . . . . . 169
12. Coexistence with YANG version 1 . . . . . . . . . . . . . . . 170 12. Coexistence with YANG version 1 . . . . . . . . . . . . . . . 171
13. YIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 13. YIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
13.1. Formal YIN Definition . . . . . . . . . . . . . . . . . 171 13.1. Formal YIN Definition . . . . . . . . . . . . . . . . . 172
13.1.1. Usage Example . . . . . . . . . . . . . . . . . . . 174 13.1.1. Usage Example . . . . . . . . . . . . . . . . . . . 175
14. YANG ABNF Grammar . . . . . . . . . . . . . . . . . . . . . . 175 14. YANG ABNF Grammar . . . . . . . . . . . . . . . . . . . . . . 176
15. NETCONF Error Responses for YANG Related Errors . . . . . . . 199 15. NETCONF Error Responses for YANG Related Errors . . . . . . . 200
15.1. Error Message for Data That Violates a unique Statement 199 15.1. Error Message for Data That Violates a unique Statement 201
15.2. Error Message for Data That Violates a max-elements 15.2. Error Message for Data That Violates a max-elements
Statement . . . . . . . . . . . . . . . . . . . . . . . 200 Statement . . . . . . . . . . . . . . . . . . . . . . . 201
15.3. Error Message for Data That Violates a min-elements 15.3. Error Message for Data That Violates a min-elements
Statement . . . . . . . . . . . . . . . . . . . . . . . 200
15.4. Error Message for Data That Violates a must Statement . 200
15.5. Error Message for Data That Violates a require-instance
Statement . . . . . . . . . . . . . . . . . . . . . . . 201 Statement . . . . . . . . . . . . . . . . . . . . . . . 201
15.4. Error Message for Data That Violates a must Statement . 201
15.5. Error Message for Data That Violates a require-instance
Statement . . . . . . . . . . . . . . . . . . . . . . . 202
15.6. Error Message for Data That Violates a mandatory choice 15.6. Error Message for Data That Violates a mandatory choice
Statement . . . . . . . . . . . . . . . . . . . . . . . 201 Statement . . . . . . . . . . . . . . . . . . . . . . . 202
15.7. Error Message for the "insert" Operation . . . . . . . . 201 15.7. Error Message for the "insert" Operation . . . . . . . . 202
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 201 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 202
17. Security Considerations . . . . . . . . . . . . . . . . . . . 201 17. Security Considerations . . . . . . . . . . . . . . . . . . . 203
18. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 202 18. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 203
19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 202 19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 204
20. ChangeLog . . . . . . . . . . . . . . . . . . . . . . . . . . 203 20. ChangeLog . . . . . . . . . . . . . . . . . . . . . . . . . . 204
20.1. Version -10 . . . . . . . . . . . . . . . . . . . . . . 203 20.1. Version -10 . . . . . . . . . . . . . . . . . . . . . . 204
20.2. Version -09 . . . . . . . . . . . . . . . . . . . . . . 203 20.2. Version -09 . . . . . . . . . . . . . . . . . . . . . . 204
20.3. Version -08 . . . . . . . . . . . . . . . . . . . . . . 203 20.3. Version -08 . . . . . . . . . . . . . . . . . . . . . . 204
20.4. Version -07 . . . . . . . . . . . . . . . . . . . . . . 203 20.4. Version -07 . . . . . . . . . . . . . . . . . . . . . . 205
20.5. Version -06 . . . . . . . . . . . . . . . . . . . . . . 203 20.5. Version -06 . . . . . . . . . . . . . . . . . . . . . . 205
20.6. Version -05 . . . . . . . . . . . . . . . . . . . . . . 204 20.6. Version -05 . . . . . . . . . . . . . . . . . . . . . . 205
20.7. Version -04 . . . . . . . . . . . . . . . . . . . . . . 204 20.7. Version -04 . . . . . . . . . . . . . . . . . . . . . . 205
20.8. Version -03 . . . . . . . . . . . . . . . . . . . . . . 204 20.8. Version -03 . . . . . . . . . . . . . . . . . . . . . . 205
20.9. Version -02 . . . . . . . . . . . . . . . . . . . . . . 204 20.9. Version -02 . . . . . . . . . . . . . . . . . . . . . . 206
20.10. Version -01 . . . . . . . . . . . . . . . . . . . . . . 205 20.10. Version -01 . . . . . . . . . . . . . . . . . . . . . . 206
20.11. Version -00 . . . . . . . . . . . . . . . . . . . . . . 205 20.11. Version -00 . . . . . . . . . . . . . . . . . . . . . . 206
21. References . . . . . . . . . . . . . . . . . . . . . . . . . 205 21. References . . . . . . . . . . . . . . . . . . . . . . . . . 206
21.1. Normative References . . . . . . . . . . . . . . . . . . 205 21.1. Normative References . . . . . . . . . . . . . . . . . . 207
21.2. Informative References . . . . . . . . . . . . . . . . . 207 21.2. Informative References . . . . . . . . . . . . . . . . . 208
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 208 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 209
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
been proposed (e.g., JSON [I-D.ietf-netmod-yang-json]). been proposed (e.g., JSON [I-D.ietf-netmod-yang-json]).
This document describes the syntax and semantics of version 1.1 of This document describes the syntax and semantics of version 1.1 of
the YANG language. It also describes how a data model defined in a the YANG language. It also describes how a data model defined in a
YANG module is encoded in the Extensible Markup Language (XML), and YANG module is encoded in the Extensible Markup Language (XML), and
how NETCONF operations are used to manipulate the data. Other how NETCONF operations are used to manipulate the data. Other
protocols and encodings are possible, but out of scope for this protocols and encodings are possible, but out of scope for this
specification. specification.
In terms of developing YANG data models, [I-D.ietf-netmod-rfc6087bis]
provides some guidelines and recommendations.
Note that this document does not obsolete RFC 6020 [RFC6020].
1.1. Summary of Changes from RFC 6020 1.1. Summary of Changes from RFC 6020
This document defines version 1.1 of the YANG language. YANG version This document defines version 1.1 of the YANG language. YANG version
1.1 is a maintenance release of the YANG language, addressing 1.1 is a maintenance release of the YANG language, addressing
ambiguities and defects in the original specification [RFC6020]. ambiguities and defects in the original specification [RFC6020].
The following changes are not backwards compatible with YANG version The following changes are not backwards compatible with YANG version
1: 1:
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. When updating a YANG version 1 module to
is now illegal must change the string to match the new rules. See 1.1, and the module uses a character sequence that is now illegal,
the string must be changed 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 o An unquoted string cannot contain any single or double quote
characters. This is an backwards incompatible change from YANG characters. This is an backwards incompatible change from YANG
version 1. version 1. When updating a YANG version 1 module to 1.1, and the
module uses such quote characters, the string must be changed to
match the new rules. See Section 6.1.3 for details.
The following additional changes have been done to YANG: o Made "when" and "if-feature" illegal on list keys. This is an
backwards incompatible change from YANG version 1. When updating
a YANG version 1 module to 1.1, and the module uses these
constructs, they must be removed to match the new rules.
o Changed the YANG version from "1" to "1.1". o Defined the legal characters in YANG modules. When updating a
YANG version 1 module to 1.1, any characters that are now illegal
must be removed. See Section 6 for details.
o Made the "yang-version" statement mandatory. o Made noncharacters illegal in the built-in type "string". This
change affects the run-time behavior of YANG-based protocols.
o Made noncharacters illegal in the built-in type "string". The following additional changes have been done to YANG:
o Defined the legal characters in YANG modules. o Changed the YANG version from "1" to "1.1".
o Made the "yang-version" statement mandatory in YANG version "1.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 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 "require-instance" in leafref.
o Allow "description" and "reference" in "import" and "include". o Allow "description" and "reference" in "import" and "include".
skipping to change at page 12, line 33 skipping to change at page 12, line 47
o feature: A mechanism for marking a portion of the model as o feature: A mechanism for marking a portion of the model as
optional. Definitions can be tagged with a feature name and are optional. Definitions can be tagged with a feature name and are
only valid on servers that support that feature. only valid on servers that support that feature.
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: A string used to identify different kinds of YANG
name. items by name.
o identity: A globally unique, abstract, and untyped 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.
skipping to change at page 13, line 13 skipping to change at page 13, line 29
nodes. nodes.
o mandatory node: A mandatory node is one of: o mandatory node: A mandatory node is one of:
* A leaf, choice, anydata, or anyxml node with a "mandatory" * A leaf, choice, anydata, or anyxml node with a "mandatory"
statement with the value "true". statement with the value "true".
* A list or leaf-list node with a "min-elements" statement with a * A list or leaf-list node with a "min-elements" statement with a
value greater than zero. value greater than zero.
* A container node without a "presence" statement, which has at * A container node without a "presence" statement and which has
least one mandatory node as a child. at least one mandatory node as a child.
o module: A YANG module defines a hierarchy of schema nodes. With o module: A YANG module defines hierarchies of schema nodes. With
its definitions and the definitions it imports or includes from its definitions and the definitions it imports or includes from
elsewhere, a module is self-contained and "compilable". elsewhere, a module is self-contained and "compilable".
o non-presence container: A container that has no meaning of its
own, existing only to contain child nodes.
o presence container: A container where the presence of the
container itself carries some meaning.
o RPC: A Remote Procedure Call. o RPC: A Remote Procedure Call.
o RPC operation: A specific Remote Procedure Call. o RPC operation: A specific Remote Procedure Call.
o schema node: A node in the schema tree. One of action, container, o schema node: A node in the schema tree. One of action, container,
leaf, leaf-list, list, choice, case, rpc, input, output, leaf, leaf-list, list, choice, case, rpc, input, output,
notification, anydata, and anyxml. notification, anydata, and anyxml.
o schema node identifier: A mechanism for identifying a particular o schema node identifier: A mechanism for identifying a particular
node in the schema tree. node in the schema tree.
skipping to change at page 13, line 52 skipping to change at page 14, line 26
submodules. submodules.
o top-level data node: A data node where there is no other data node o top-level data node: A data node where there is no other data node
between it and a module or submodule statement. between it and a module or submodule statement.
o uses: The "uses" statement is used to instantiate the set of o uses: The "uses" statement is used to instantiate the set of
schema nodes defined in a grouping statement. The instantiated schema nodes defined in a grouping statement. The instantiated
nodes may be refined and augmented to tailor them to any specific nodes may be refined and augmented to tailor them to any specific
needs. needs.
o value space: For a data type; the set of values permitted by the
data type. For a leaf or leaf-list instance; the value space of
its data type.
The following terms are defined in [RFC6241]: The following terms are defined in [RFC6241]:
o configuration data o configuration data
o configuration datastore o configuration datastore
o datastore o datastore
o state data o state data
skipping to change at page 14, line 33 skipping to change at page 15, line 13
not supposed to be complete, valid YANG modules. not supposed to be complete, valid YANG modules.
4. YANG Overview 4. YANG Overview
This non-normative section is intended to give a high-level overview This non-normative section is intended to give a high-level overview
of YANG to first-time readers. of YANG to first-time readers.
4.1. Functional Overview 4.1. Functional Overview
YANG is a language originally designed to model data for the NETCONF YANG is a language originally designed to model data for the NETCONF
protocol. A YANG module defines a hierarchy of data that can be used protocol. A YANG module defines hierarchies of data that can be used
for NETCONF-based operations, including configuration, state data, for NETCONF-based operations, including configuration, state data,
Remote Procedure Calls (RPCs), and notifications. This allows a Remote Procedure Calls (RPCs), and notifications. This allows a
complete description of all data sent between a NETCONF client and complete description of all data sent between a NETCONF client and
server. Although out of scope for this specification, YANG can also server. Although out of scope for this specification, YANG can also
be used with other protocols than NETCONF. be used with other protocols than NETCONF.
YANG models the hierarchical organization of data as a tree in which YANG models the hierarchical organization of data as a tree in which
each node has a name, and either a value or a set of child nodes. each node has a name, and either a value or a set of child nodes.
YANG provides clear and concise descriptions of the nodes, as well as YANG provides clear and concise descriptions of the nodes, as well as
the interaction between those nodes. the interaction between those nodes.
YANG structures data models into modules and submodules. A module YANG structures data models into modules and submodules. A module
can import data from other external modules, and include data from can import definitions from other external modules, and include
submodules. The hierarchy can be augmented, allowing one module to definitions from submodules. The hierarchy can be augmented,
add data nodes to the hierarchy defined in another module. This allowing one module to add data nodes to the hierarchy defined in
augmentation can be conditional, with new nodes appearing only if another module. This augmentation can be conditional, with new nodes
certain conditions are met. appearing only if certain conditions are met.
YANG data models can describe constraints to be enforced on the data, YANG data models can describe constraints to be enforced on the data,
restricting the presence or value of nodes based on the presence or restricting the presence or value of nodes based on the presence or
value of other nodes in the hierarchy. These constraints are value of other nodes in the hierarchy. These constraints are
enforceable by either the client or the server, and valid content enforceable by either the client or the server.
MUST abide by them.
YANG defines a set of built-in types, and has a type mechanism YANG defines a set of built-in types, and has a type mechanism
through which additional types may be defined. Derived types can through which additional types may be defined. Derived types can
restrict their base type's set of valid values using mechanisms like restrict their base type's set of valid values using mechanisms like
range or pattern restrictions that can be enforced by clients or range or pattern restrictions that can be enforced by clients or
servers. They can also define usage conventions for use of the servers. They can also define usage conventions for use of the
derived type, such as a string-based type that contains a host name. derived type, such as a string-based type that contains a host name.
YANG permits the definition of reusable groupings of nodes. The YANG permits the definition of reusable groupings of nodes. The
instantiation of these groupings can refine or augment the nodes, usage of these groupings can refine or augment the nodes, allowing it
allowing it to tailor the nodes to its particular needs. Derived to tailor the nodes to its particular needs. Derived types and
types and groupings can be defined in one module and used in either groupings can be defined in one module and used in either the same
the same module or in another module that imports it. module or in another module that imports it.
YANG data hierarchy constructs include defining lists where list YANG data hierarchy constructs include defining lists where list
entries are identified by keys that distinguish them from each other. entries are identified by keys that distinguish them from each other.
Such lists may be defined as either sorted by user or automatically Such lists may be defined as either sorted by user or automatically
sorted by the system. For user-sorted lists, operations are defined sorted by the system. For user-sorted lists, operations are defined
for manipulating the order of the list entries. for manipulating the order of the list entries.
YANG modules can be translated into an equivalent XML syntax called YANG modules can be translated into an equivalent XML syntax called
YANG Independent Notation (YIN) (Section 13), allowing applications YANG Independent Notation (YIN) (Section 13), allowing applications
using XML parsers and Extensible Stylesheet Language Transformations using XML parsers and Extensible Stylesheet Language Transformations
(XSLT) scripts to operate on the models. The conversion from YANG to (XSLT) scripts to operate on the models. The conversion from YANG to
YIN is lossless, so content in YIN can be round-tripped back into YIN is semantically lossless, so content in YIN can be round-tripped
YANG. back into YANG.
YANG strikes a balance between high-level data modeling and low-level
bits-on-the-wire encoding. The reader of a YANG module can see the
high-level view of the data model while understanding how the data
will be encoded on-the-wire.
YANG is an extensible language, allowing extension statements to be YANG is an extensible language, allowing extension statements to be
defined by standards bodies, vendors, and individuals. The statement defined by standards bodies, vendors, and individuals. The statement
syntax allows these extensions to coexist with standard YANG syntax allows these extensions to coexist with standard YANG
statements in a natural way, while extensions in a YANG module stand statements in a natural way, while extensions in a YANG module stand
out sufficiently for the reader to notice them. out sufficiently for the reader to notice them.
YANG resists the tendency to solve all possible problems, limiting YANG resists the tendency to solve all possible problems, limiting
the problem space to allow expression of data models for network the problem space to allow expression of data models for network
management protocols such as NETCONF, not arbitrary XML documents or management protocols such as NETCONF, not arbitrary XML documents or
skipping to change at page 16, line 20 skipping to change at page 16, line 40
translation from YANG to SMIv2. translation from YANG to SMIv2.
4.2. Language Overview 4.2. Language Overview
This section introduces some important constructs used in YANG that This section introduces some important constructs used in YANG that
will aid in the understanding of the language specifics in later will aid in the understanding of the language specifics in later
sections. sections.
4.2.1. Modules and Submodules 4.2.1. Modules and Submodules
YANG data models are defined in modules. A module contains a
collection of related definitions.
A module contains three types of statements: module-header A module contains three types of statements: module-header
statements, revision statements, and definition statements. The statements, revision statements, and definition statements. The
module header statements describe the module and give information module header statements describe the module and give information
about the module itself, the revision statements give information about the module itself, the revision statements give information
about the history of the module, and the definition statements are about the history of the module, and the definition statements are
the body of the module where the data model is defined. the body of the module where the data model is defined.
A server may implement a number of modules, allowing multiple views A server may implement a number of modules, allowing multiple views
of the same data, or multiple views of disjoint subsections of the of the same data, or multiple views of disjoint subsections of the
server's data. Alternatively, the server may implement only one server's data. Alternatively, the server may implement only one
module that defines all available data. module that defines all available data.
A module may be divided into submodules, based on the needs of the A module may have portions of its definitions separated into
module owner. The external view remains that of a single module, submodules, based on the needs of the module designer. The external
regardless of the presence or size of its submodules. view remains that of a single module, 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. definitions defined in other modules.
The "include" statement is used by a module to incorporate the The "include" statement is used in a module to identify each
contents of its submodules into the module. submodule that belongs to it.
4.2.2. Data Modeling Basics 4.2.2. Data Modeling Basics
YANG defines four main types of data nodes for data modeling. In YANG defines four main types of data nodes for data modeling. In
each of the following subsections, the examples show the YANG syntax each of the following subsections, the examples show the YANG syntax
as well as a corresponding XML encoding. as well as a corresponding XML encoding. The syntax of YANG
statements is defined in Section 6.3.
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 28 skipping to change at page 18, line 51
<login> <login>
<message>Good morning</message> <message>Good morning</message>
</login> </login>
</system> </system>
The "container" statement is covered in Section 7.5. The "container" statement is covered in Section 7.5.
4.2.2.4. List Nodes 4.2.2.4. List Nodes
A list defines a sequence of list entries. Each entry is like a A list defines a sequence of list entries. Each entry is like a
structure or a record instance, and is uniquely identified by the container, and is uniquely identified by the values of its key leafs,
values of its key leafs. A list can define multiple key leafs and if it has any key leafs defined. A list can define multiple key
may contain any number of child nodes of any type (including leafs, leafs and may contain any number of child nodes of any type
lists, containers etc.). (including leafs, lists, containers etc.).
YANG Example: YANG Example:
list user { list user {
key "name"; key "name";
leaf name { leaf name {
type string; type string;
} }
leaf full-name { leaf full-name {
type string; type string;
skipping to change at page 20, line 30 skipping to change at page 21, line 5
type string; type string;
} }
leaf class { leaf class {
type string; type string;
} }
} }
} }
} }
} }
4.2.3. State Data 4.2.3. Configuration and State Data
YANG can model state data, as well as configuration data, based on YANG can model state data, as well as configuration data, based on
the "config" statement. When a node is tagged with "config false", the "config" statement. When a node is tagged with "config false",
its subhierarchy is flagged as state data. In NETCONF, state data is its subhierarchy is flagged as state data. If it is tagged with
reported using the <get> operation, not the <get-config> operation. "config true", its subhierarchy is flagged as configuration data.
Parent containers, lists, and key leafs are reported also, giving the Parent containers, lists, and key leafs are reported also, giving the
context for the state data. context for the state data.
In this example, two leafs are defined for each interface, a In this example, two leafs are defined for each interface, a
configured speed and an observed speed. The observed speed is not configured speed and an observed speed.
configuration, so it can be returned with NETCONF <get> operations,
but not with <get-config> operations. The observed speed is not
configuration data, and it cannot be manipulated using <edit-config>.
list interface { list interface {
key "name"; key "name";
config true;
leaf name { leaf name {
type string; type string;
} }
leaf speed { leaf speed {
type enumeration { type enumeration {
enum 10m; enum 10m;
enum 100m; enum 100m;
enum auto; enum auto;
} }
} }
leaf observed-speed { leaf observed-speed {
type uint32; type uint32;
config false; config false;
} }
} }
The "config" statement is covered in Section 7.21.1.
4.2.4. Built-In Types 4.2.4. Built-In Types
YANG has a set of built-in types, similar to those of many YANG has a set of built-in types, similar to those of many
programming languages, but with some differences due to special programming languages, but with some differences due to special
requirements from the management domain. The following table requirements of network management. The following table summarizes
summarizes the built-in types discussed in Section 9: the built-in types discussed in Section 9:
+---------------------+-------------------------------------+ +---------------------+-------------------------------------+
| Name | Description | | Name | Description |
+---------------------+-------------------------------------+ +---------------------+-------------------------------------+
| binary | Any binary data | | binary | Any binary data |
| bits | A set of bits or flags | | bits | A set of bits or flags |
| boolean | "true" or "false" | | boolean | "true" or "false" |
| decimal64 | 64-bit signed decimal number | | decimal64 | 64-bit signed decimal number |
| empty | A leaf that does not have any value | | empty | A leaf that does not have any value |
| enumeration | Enumerated strings | | enumeration | One of an enumerated set of strings |
| identityref | A reference to an abstract identity | | identityref | A reference to an abstract identity |
| instance-identifier | A reference a data tree node | | instance-identifier | A reference to a data tree node |
| int8 | 8-bit signed integer | | int8 | 8-bit signed integer |
| int16 | 16-bit signed integer | | int16 | 16-bit signed integer |
| int32 | 32-bit signed integer | | int32 | 32-bit signed integer |
| int64 | 64-bit signed integer | | int64 | 64-bit signed integer |
| leafref | A reference to a leaf instance | | leafref | A reference to a leaf instance |
| string | Human-readable string | | string | A character string |
| uint8 | 8-bit unsigned integer | | uint8 | 8-bit unsigned integer |
| uint16 | 16-bit unsigned integer | | uint16 | 16-bit unsigned integer |
| uint32 | 32-bit unsigned integer | | uint32 | 32-bit unsigned integer |
| uint64 | 64-bit unsigned integer | | uint64 | 64-bit unsigned integer |
| union | Choice of member types | | union | Choice of member types |
+---------------------+-------------------------------------+ +---------------------+-------------------------------------+
The "type" statement is covered in Section 7.4. The "type" statement is covered in Section 7.4.
4.2.5. Derived Types (typedef) 4.2.5. Derived Types (typedef)
skipping to change at page 23, line 13 skipping to change at page 23, line 13
XML Encoding Example: XML Encoding Example:
<completed>20</completed> <completed>20</completed>
The "typedef" statement is covered in Section 7.3. The "typedef" statement is covered in Section 7.3.
4.2.6. Reusable Node Groups (grouping) 4.2.6. Reusable Node Groups (grouping)
Groups of nodes can be assembled into reusable collections using the Groups of nodes can be assembled into reusable collections using the
"grouping" statement. A grouping defines a set of nodes that are "grouping" statement. A grouping defines a set of nodes that are
instantiated with the "uses" statement: instantiated with the "uses" statement.
YANG Example:
grouping target { grouping target {
leaf address { leaf address {
type inet:ip-address; type inet:ip-address;
description "Target IP address"; description "Target IP address";
} }
leaf port { leaf port {
type inet:port-number; type inet:port-number;
description "Target port number"; description "Target port number";
} }
skipping to change at page 24, line 39 skipping to change at page 24, line 39
4.2.7. Choices 4.2.7. Choices
YANG allows the data model to segregate incompatible nodes into YANG allows the data model to segregate incompatible nodes into
distinct choices using the "choice" and "case" statements. The distinct choices using the "choice" and "case" statements. The
"choice" statement contains a set of "case" statements that define "choice" statement contains a set of "case" statements that define
sets of schema nodes that cannot appear together. Each "case" may sets of schema nodes that cannot appear together. Each "case" may
contain multiple nodes, but each node may appear in only one "case" contain multiple nodes, but each node may appear in only one "case"
under a "choice". under a "choice".
When a node from one case is created in the data tree, all nodes from
all other cases are implicitly deleted. The server handles the
enforcement of the constraint, preventing incompatibilities from
existing in the configuration.
The choice and case nodes appear only in the schema tree but not in The choice and case nodes appear only in the schema tree but not in
the data tree. The additional levels of hierarchy are not needed the data tree. The additional levels of hierarchy are not needed
beyond the conceptual schema. beyond the conceptual schema. The presence of a case is indicated by
the presence of one or more of the nodes within it.
Since only one of the choice's cases can be valid at any time, when a
node from one case is created in the data tree, all nodes from all
other cases are implicitly deleted. The server handles the
enforcement of the constraint, preventing incompatibilities from
existing in the configuration.
YANG Example: YANG Example:
container food { container food {
choice snack { choice snack {
case sports-arena { case sports-arena {
leaf pretzel { leaf pretzel {
type empty; type empty;
} }
leaf beer { leaf beer {
skipping to change at page 25, line 47 skipping to change at page 25, line 47
YANG allows a module to insert additional nodes into data models, YANG allows a module to insert additional nodes into data models,
including both the current module (and its submodules) or an external including both the current module (and its submodules) or an external
module. This is useful for example for vendors to add vendor- module. This is useful for example for vendors to add vendor-
specific parameters to standard data models in an interoperable way. specific parameters to standard data models in an interoperable way.
The "augment" statement defines the location in the data model The "augment" statement defines the location in the data model
hierarchy where new nodes are inserted, and the "when" statement hierarchy where new nodes are inserted, and the "when" statement
defines the conditions when the new nodes are valid. defines the conditions when the new nodes are valid.
When a server implements a module containing an "augment" statement,
that implies that the server's implementation of the augmented module
contains the additional nodes.
YANG Example: YANG Example:
augment /system/login/user { augment /system/login/user {
when "class != 'wheel'"; when "class != 'wheel'";
leaf uid { leaf uid {
type uint16 { type uint16 {
range "1000 .. 30000"; range "1000 .. 30000";
} }
} }
} }
This example defines a "uid" node that only is valid when the user's This example defines a "uid" node that only is valid when the user's
"class" is not "wheel". "class" is not "wheel".
If a module augments another module, the XML encoding of the data If a module augments another module, the XML elements that are added
will reflect the prefix of the augmenting module. For example, if to the encoding are in the namespace of the augmenting module. For
the above augmentation were in a module with prefix "other", the XML example, if the above augmentation were in a module with prefix
would look like: "other", the XML would look like:
XML Encoding Example: XML Encoding Example:
<user> <user>
<name>alicew</name> <name>alicew</name>
<full-name>Alice N. Wonderland</full-name> <full-name>Alice N. Wonderland</full-name>
<class>drop-out</class> <class>drop-out</class>
<other:uid>1024</other:uid> <other:uid>1024</other:uid>
</user> </user>
skipping to change at page 26, line 42 skipping to change at page 26, line 42
4.2.9. Operation Definitions 4.2.9. Operation Definitions
YANG allows the definition of operations. The operations' name, YANG allows the definition of operations. The operations' name,
input parameters, and output parameters are modeled using YANG data input parameters, and output parameters are modeled using YANG data
definition statements. Operations on the top-level in a module are definition statements. Operations on the top-level in a module are
defined with the "rpc" statement. Operations can also be tied to a defined with the "rpc" statement. Operations can also be tied to a
container or list data node. Such operations are defined with the container or list data node. Such operations are defined with the
"action" statement. "action" statement.
YANG Example: YANG Example for an operation at the top-level:
rpc activate-software-image { rpc activate-software-image {
input { input {
leaf image-name { leaf image-name {
type string; type string;
} }
} }
output { output {
leaf status { leaf status {
type string; type string;
skipping to change at page 27, line 34 skipping to change at page 27, line 34
</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://example.com/system"> <status xmlns="http://example.com/system">
The image example-fw-2.3 is being installed. The image example-fw-2.3 is being installed.
</status> </status>
</rpc-reply> </rpc-reply>
YANG Example: YANG Example for an operation tied to a list data node:
list interface { list interface {
key "name"; key "name";
leaf name { leaf name {
type string; type string;
} }
action ping { action ping {
input { input {
skipping to change at page 29, line 47 skipping to change at page 29, line 47
</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
5.1. Modules and Submodules 5.1. Modules and Submodules
The module is the base unit of definition in YANG. A module defines The module is the base unit of definition in YANG. A module defines
a single data model. A module can define a complete, cohesive model, a single data model. A module can also augment an existing data
or augment an existing data model with additional nodes. model with additional nodes.
Submodules are partial modules that contribute definitions to a Submodules are partial modules that contribute definitions to a
module. A module may include any number of submodules, but each module. A module may include any number of submodules, but each
submodule may belong to only one module. submodule may belong to only one module.
Developers of YANG modules and submodules are RECOMMENDED to choose Developers of YANG modules and submodules are RECOMMENDED to choose
names for their modules that will have a low probability of colliding names for their modules that will have a low probability of colliding
with standard or other enterprise modules, e.g., by using the with standard or other enterprise modules, e.g., by using the
enterprise or organization name as a prefix for the module name. enterprise or organization name as a prefix for the module name.
Within a server, all module names MUST be unique. Within a server, all module names MUST be unique.
A module uses the "include" statement to include all its submodules, A module uses the "include" statement to list all its submodules. A
and the "import" statement to reference external modules. Similarly, module, or submodule belonging to that module, can reference
a submodule uses the "import" statement to reference other modules. definitions in the module and all submodules included by the module.
For backward compatibility with YANG version 1, a submodule is A module or submodule uses the "import" statement to reference
allowed to use the "include" statement to reference other submodules external modules. Statements in the module or submodule can
within its module, but this is not necessary in YANG version 1.1. A reference definitions in the external module using the prefix
submodule can reference any definition in the module it belongs to specified in the "import" statement.
and in all submodules included by the module. A submodule MUST NOT
include different revisions of other submodules than the revisions For backward compatibility with YANG version 1, a submodule MAY use
that its module includes. the "include" statement to reference other submodules within its
module, but this is not necessary in YANG version 1.1. A submodule
can reference any definition in the module it belongs to and in all
submodules included by the module. A submodule MUST NOT include
different revisions of other submodules than the revisions that its
module includes.
A module or submodule MUST NOT include submodules from other modules, A module or submodule MUST NOT include submodules from other modules,
and a submodule MUST NOT import its own module. and a submodule MUST NOT import its own module.
The import and include statements are used to make definitions The import and include statements are used to make definitions
available from other modules: available from other modules:
o For a module or submodule to reference definitions in an external o For a module or submodule to reference definitions in an external
module, the external module MUST be imported. module, the external module MUST be imported.
o A module MUST include all its submodules. o A module MUST include all its submodules.
o A module, or submodule belonging to that module, can reference o A module, or submodule belonging to that module, MAY reference
definitions in the module and all submodules included by the definitions in the module and all submodules included by the
module. module.
There MUST NOT be any circular chains of imports. For example, if There MUST NOT be any circular chains of imports. For example, if
module "a" imports module "b", "b" cannot import "a". module "a" imports module "b", "b" cannot import "a".
When a definition in an external module is referenced, a locally When a definition in an external module is referenced, a locally
defined prefix MUST be used, followed by ":", and then the external defined prefix MUST be used, followed by a colon (":"), and then the
identifier. References to definitions in the local module MAY use external identifier. References to definitions in the local module
the prefix notation. Since built-in data types do not belong to any MAY use the prefix notation. Since built-in data types do not belong
module and have no prefix, references to built-in data types (e.g., to any module and have no prefix, references to built-in data types
int32) cannot use the prefix notation. The syntax for a reference to (e.g., int32) cannot use the prefix notation. The syntax for a
a definition is formally defined by the rule "identifier-ref" in reference to a definition is formally defined by the rule
Section 14. "identifier-ref" in Section 14.
5.1.1. Import and Include by Revision 5.1.1. Import and Include by Revision
Published modules evolve independently over time. In order to allow Published modules evolve independently over time. In order to allow
for this evolution, modules can be imported using specific revisions. for this evolution, modules can be imported using specific revisions.
When a module is written, it can import the current revisions of Initially, a module imports the revisions of other modules that are
other modules, based on what is available at the time. As future current when the module is written. As future revisions of the
revisions of the imported modules are published, the importing module imported modules are published, the importing module is unaffected
is unaffected and its contents are unchanged. When the author of the and its contents are unchanged. When the author of the module is
module is prepared to move to the most recently published revision of prepared to move to the most recently published revision of an
an imported module, the module is republished with an updated imported module, the module is republished with an updated "import"
"import" statement. By republishing with the new revision, the statement. By republishing with the new revision, the authors
authors explicitly indicate their acceptance of any changes in the explicitly indicate their acceptance of any changes in the imported
imported module. module.
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 may specify the revision of the
the included submodules. If a submodule changes, any module or included submodules. If a submodule changes, any module or submodule
submodule that includes it needs to be updated. that includes it by revision needs to be updated to reference the new
revision.
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 "urn:example:a"; namespace "urn:example:a";
prefix "a"; prefix "a";
revision 2008-01-01 { ... } revision 2008-01-01 { ... }
grouping a { grouping a {
skipping to change at page 32, line 11 skipping to change at page 32, line 37
uses p:a; uses p:a;
} }
} }
When the author of "a" publishes a new revision, the changes may not When the author of "a" publishes a new revision, the changes may not
be acceptable to the author of "b". If the new revision is be acceptable to the author of "b". If the new revision is
acceptable, the author of "b" can republish with an updated revision acceptable, the author of "b" can republish with an updated revision
in the "import" statement. in the "import" statement.
If a module is not imported with a specific revision, it is undefined If a module is not imported with a specific revision, it is undefined
which exact revision is used. which revision is used.
5.1.2. Module Hierarchies 5.1.2. Module Hierarchies
YANG allows modeling of data in multiple hierarchies, where data may YANG allows modeling of data in multiple hierarchies, where data may
have more than one top-level node. Models that have multiple top- have more than one top-level node. Each top-level data node in a
module defines a separate hierarchy. Models that have multiple top-
level nodes are sometimes convenient, and are supported by YANG. level nodes are sometimes convenient, and are supported by YANG.
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, an instance of:
module example-config { module example-config {
yang-version 1.1; yang-version 1.1;
namespace "urn:example:config"; namespace "urn:example:config";
prefix "co"; prefix "co";
container system { ... } container system { ... }
container routing { ... } container routing { ... }
} }
skipping to change at page 33, line 26 skipping to change at page 33, line 39
<routing xmlns="urn:example: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 statement per file. The name of the file SHOULD be of
the form:
module-or-submodule-name ['@' revision-date] ( '.yang' / '.yin' ) module-or-submodule-name ['@' revision-date] ( '.yang' / '.yin' )
"module-or-submodule-name" is the name of the module or submodule,
and the optional "revision-date" is the latest revision of the module
or submodule, as defined by the "revision" statement (Section 7.1.9).
The file extension ".yang" denotes that the contents of the file is
written with YANG syntax (Section 6), and ".yin" denotes that it is
written with YIN syntax (Section 13).
YANG parsers can find imported modules and included submodules via YANG parsers can find imported modules and included submodules via
this convention. this convention.
5.3. XML Namespaces 5.3. XML Namespaces
All YANG definitions are specified within a module that is bound to a All YANG definitions are specified within a module. Each module is
particular XML namespace [XML-NAMES], which is a globally unique URI bound to a distinct XML namespace [XML-NAMES], which is a globally
[RFC3986]. A NETCONF client or server uses the namespace during XML unique URI [RFC3986]. A NETCONF client or server uses the namespace
encoding of data. during XML encoding of data.
XML namespaces for modules published in RFC streams [RFC4844] MUST be XML namespaces for modules published in RFC streams [RFC4844] MUST be
assigned by IANA, see section 14 in [RFC6020]. assigned by IANA, see section 14 in [RFC6020].
XML namespaces for private modules are assigned by the organization XML namespaces for private modules are assigned by the organization
owning the module without a central registry. Namespace URIs MUST be owning the module without a central registry. Namespace URIs MUST be
chosen so they cannot collide with standard or other enterprise chosen so they cannot collide with standard or other enterprise
namespaces, for example by using the enterprise or organization name namespaces, for example by using the enterprise or organization name
in the namespace. in the namespace.
skipping to change at page 34, line 23 skipping to change at page 34, line 44
Grouping, type, and identity names are resolved in the context in Grouping, type, and identity names are resolved in the context in
which they are defined, rather than the context in which they are which they are defined, rather than the context in which they are
used. Users of groupings, typedefs, and identities are not required used. Users of groupings, typedefs, and identities are not required
to import modules or include submodules to satisfy all references to import modules or include submodules to satisfy all references
made by the original definition. This behaves like static scoping in made by the original definition. This behaves like static scoping in
a conventional programming language. a conventional programming language.
For example, if a module defines a grouping in which a type is For example, if a module defines a grouping in which a type is
referenced, when the grouping is used in a second module, the type is referenced, when the grouping is used in a second module, the type is
resolved in the context of the original module, not the second resolved in the context of the original module, not the second
module. There is no worry over conflicts if both modules define the module. There is no ambiguity if both modules define the type, since
type, since there is no ambiguity. there is no ambiguity.
5.5. Nested Typedefs and Groupings 5.5. Nested Typedefs and Groupings
Typedefs and groupings may appear nested under many YANG statements, Typedefs and groupings may appear nested under many YANG statements,
allowing these to be lexically scoped by the hierarchy under which allowing these to be lexically scoped by the statement hierarchy
they appear. This allows types and groupings to be defined near under which they appear. This allows types and groupings to be
where they are used, rather than placing them at the top level of the defined near where they are used, rather than placing them at the top
hierarchy. The close proximity increases readability. level of the hierarchy. The close proximity increases readability.
Scoping also allows types to be defined without concern for naming Scoping also allows types to be defined without concern for naming
conflicts between types in different submodules. Type names can be conflicts between types in different submodules. Type names can be
specified without adding leading strings designed to prevent name specified without adding leading strings designed to prevent name
collisions within large modules. collisions within large modules.
Finally, scoping allows the module author to keep types and groupings Finally, scoping allows the module author to keep types and groupings
private to their module or submodule, preventing their reuse. Since private to their module or submodule, preventing their reuse. Since
only top-level types and groupings (i.e., those appearing as only top-level types and groupings (i.e., those appearing as
substatements to a module or submodule statement) can be used outside substatements to a module or submodule statement) can be used outside
the module or submodule, the developer has more control over what the module or submodule, the developer has more control over what
pieces of their module are presented to the outside world, supporting pieces of their module are presented to the outside world, supporting
the need to hide internal information and maintaining a boundary the need to hide internal information and maintaining a boundary
between what is shared with the outside world and what is kept between what is shared with the outside world and what is kept
private. private.
Scoped definitions MUST NOT shadow definitions at a higher scope. A Scoped definitions MUST NOT shadow definitions at a higher scope. A
type or grouping cannot be defined if a higher level in the schema type or grouping cannot be defined if a higher level in the statement
hierarchy has a definition with a matching identifier. hierarchy has a definition with a matching identifier.
A reference to an unprefixed type or grouping, or one which uses the A reference to an unprefixed type or grouping, or one which uses the
prefix of the current module, is resolved by locating the matching prefix of the current module, is resolved by locating the matching
"typedef" or "grouping" statement among the immediate substatements "typedef" or "grouping" statement among the immediate substatements
of each ancestor statement. of each ancestor statement.
5.6. Conformance 5.6. Conformance
Conformance is a measure of how accurately a server follows the Conformance to a model is a measure of how accurately a server
model. Generally speaking, servers are responsible for implementing follows the model. Generally speaking, servers are responsible for
the model faithfully, allowing applications to treat servers which implementing the model faithfully, allowing applications to treat
implement the model identically. Deviations from the model can servers which implement the model identically. Deviations from the
reduce the utility of the model and increase fragility of model can reduce the utility of the model and increase fragility of
applications that use it. applications that use it.
YANG modelers have three mechanisms for conformance: YANG modelers have three mechanisms for conformance:
o the basic behavior of the model o the basic behavior of the model
o optional features that are part of the model o optional features that are part of the model
o deviations from the model o deviations from the model
skipping to change at page 37, line 5 skipping to change at page 37, line 29
module. module.
Further details are available in Section 7.20.3. Further details are available in Section 7.20.3.
5.6.4. Announcing Conformance Information in NETCONF 5.6.4. 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 (see A NETCONF server MUST announce the modules it implements (see
Section 5.6.5) by implementing the YANG module "ietf-yang-library" Section 5.6.5) by implementing the YANG module "ietf-yang-library"
defined in [I-D.ietf-netconf-yang-library], and listing all defined in [I-D.ietf-netconf-yang-library], and listing all
implemented modules in the "/modules-state/module" list. implemented modules in the "/modules-state/module" list.
The server also advertises the following capability in the <hello> The server also MUST advertise the following capability in the
message (line-breaks and whitespaces are used for formatting reasons <hello> message (line-breaks and whitespaces are used for formatting
only): reasons only):
urn:ietf:params:netconf:capability:yang-library:1.0? urn:ietf:params:netconf:capability:yang-library:1.0?
revision=<date>&module-set-id=<id> revision=<date>&module-set-id=<id>
The parameter "revision" has the same value as the revision date of The parameter "revision" has the same value as the revision date of
the "ietf-yang-library" module implemented by the server. This the "ietf-yang-library" module implemented by the server. This
parameter MUST be present. parameter MUST be present.
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-state/module-set-id" from "ietf-yang-library". This "/modules-state/module-set-id" from "ietf-yang-library". This
skipping to change at page 38, line 8 skipping to change at page 38, line 32
"ietf-yang-library" [I-D.ietf-netconf-yang-library], and it MUST set "ietf-yang-library" [I-D.ietf-netconf-yang-library], and it MUST set
the leaf "conformance-type" 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 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 "ietf-yang-library", and there are other modules Ms listed that
import C without specifying the revision date of module C, the server import C without specifying the revision date of module C, the server
MUST use the definitions from the most recent revision of C listed MUST use the definitions from the most recent revision of C listed
for modules Ms. 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 specific data model structure and types of all leafs and leaf-
implemented in a server. lists 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 "urn:example:a"; namespace "urn:example:a";
prefix "a"; prefix "a";
import b { import b {
revision-date 2015-01-01; revision-date 2015-01-01;
skipping to change at page 38, line 46 skipping to change at page 39, line 21
type c:bar; type c:bar;
} }
} }
} }
module b { module b {
yang-version 1.1; yang-version 1.1;
namespace "urn:example:b"; namespace "urn:example:b";
prefix "b"; prefix "b";
revision 2015-01-01;
typedef myenum {
type enumeration {
enum zero;
}
}
container x {
}
}
module b {
yang-version 1.1;
namespace "urn:example: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 {
yang-version 1.1;
namespace "urn:example:c";
prefix "c";
revision 2015-02-02;
typedef bar {
...
}
}
module c { module c {
yang-version 1.1; yang-version 1.1;
namespace "urn:example: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 bar { typedef bar {
skipping to change at page 39, line 35 skipping to change at page 40, line 38
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" picks
pick a revision of module "c", and list it in the "/modules-state/ any revision of module "c", and list it in the "/modules-state/
module" 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-state/module" list for a server that implements module "a": "/modules-state/module" list for a server that implements module "a":
<modules-state <modules-state
xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library"> 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</name> <name>a</name>
skipping to change at page 40, line 46 skipping to change at page 41, line 46
changes are allowed is out of scope for this specification. changes are allowed is out of scope for this specification.
6. YANG Syntax 6. YANG Syntax
The YANG syntax is similar to that of SMIng [RFC3780] and programming The YANG syntax is similar to that of SMIng [RFC3780] and programming
languages like C and C++. This C-like syntax was chosen specifically languages like C and C++. This C-like syntax was chosen specifically
for its readability, since YANG values the time and effort of the for its readability, since YANG values the time and effort of the
readers of models above those of modules writers and YANG tool-chain readers of models above those of modules writers and YANG tool-chain
developers. This section introduces the YANG syntax. developers. This section introduces the YANG syntax.
YANG modules use the UTF-8 [RFC3629] character encoding.
Legal characters in YANG modules are the Unicode and ISO/IEC 10646 Legal characters in YANG modules are the Unicode and ISO/IEC 10646
[ISO.10646] characters, including tab, carriage return, and line feed [ISO.10646] characters, including tab, carriage return, and line feed
but excluding the other C0 control characters, the surrogate blocks, but excluding the other C0 control characters, the surrogate blocks,
and the noncharacters. The character syntax is formally defined by and the noncharacters. The character syntax is formally defined by
the rule "yang-char" in Section 14. the rule "yang-char" in Section 14.
YANG modules and submodules are stored in files using the UTF-8
[RFC3629] character encoding.
Lines in a YANG module end with a carriage return-line feed
combination or with a line feed alone. A carriage return that is not
followed by a line feed may only appear inside a quoted string
(Section 6.1.3). Note that carriage returns and line feeds that
appear inside quoted strings become part of the value of the string
without modification; the value of a multi-line quoted string
contains the same form of line ends as those lines of the YANG
module.
6.1. Lexical Tokenization 6.1. Lexical Tokenization
YANG modules are parsed as a series of tokens. This section details YANG modules are parsed as a series of tokens. This section details
the rules for recognizing tokens from an input stream. YANG the rules for recognizing tokens from an input stream. YANG
tokenization rules are both simple and powerful. The simplicity is tokenization rules are both simple and powerful. The simplicity is
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 starts with "/*" and
and "*/". ends with the nearest following "*/".
Note that inside a quoted string (Section 6.1.3), these character Note that inside a quoted string (Section 6.1.3), these character
pairs are never interpreted as the start or end of a comment. 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 a colon (":"), followed by a language
keyword. Keywords are case sensitive. See Section 6.2 for a formal extension keyword. Keywords are case sensitive. See Section 6.2 for
definition of identifiers. a formal definition of identifiers.
6.1.3. Quoting 6.1.3. Quoting
If a string contains any space, tab, or newline characters, a single An unquoted string is any sequence of characters that does not
or double quote character, a semicolon (";"), braces ("{" or "}"), or contain any space, tab, carriage return, or line feed characters, a
comment sequences ("//", "/*", or "*/"), then it MUST be enclosed single or double quote character, a semicolon (";"), braces ("{" or
within double or single quotes. "}"), or comment sequences ("//", "/*", or "*/").
Note that any keyword can legally appear as an unquoted string.
Within an unquoted string, every character is preserved. Note that Within an unquoted string, every character is preserved. Note that
this means that the backslash character does not have any special this means that the backslash character does not have any special
meaning in an unquoted string. meaning in an unquoted string.
If a double-quoted string contains a line break followed by space or 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 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 starting double quote
or to the first non-whitespace character, whichever occurs first. In character, or to the first non-whitespace character, whichever occurs
this process, a tab character is treated as 8 space characters. first. Any tab character in a succeeding line that must be examined
for stripping is first converted into 8 space characters.
If a 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 representation of a special character, which
character that immediately follows the backslash: depends on the character that immediately follows the backslash:
\n new line \n new line
\t a tab character \t a tab character
\" a double quote \" a double quote
\\ a single backslash \\ a single backslash
It is an error if any other character follows the backslash The backslash MUST NOT be followed by any other character.
character.
If a quoted string is followed by a plus character ("+"), followed by If a quoted string is followed by a plus character ("+"), followed by
another quoted string, the two strings are concatenated into one another quoted string, the two strings are concatenated into one
string, allowing multiple concatenations to build one string. string, allowing multiple concatenations to build one string.
Whitespace trimming is done before substitution of backslash-escaped Whitespace, line breaks, and comments are allowed between the quoted
characters in double-quoted strings. Concatenation is performed as strings and the plus character.
the last step.
In double-quoted strings, whitespace trimming is done before
substitution of backslash-escaped characters. Concatenation is
performed as the last step.
6.1.3.1. Quoting Examples 6.1.3.1. Quoting Examples
The following strings are equivalent: The following strings are equivalent:
hello hello
"hello" "hello"
'hello' 'hello'
"hel" + "lo" "hel" + "lo"
'hel' + "lo" 'hel' + "lo"
skipping to change at page 44, line 37 skipping to change at page 46, line 13
The argument is a string, as defined in Section 6.1.2. The argument is a string, as defined in Section 6.1.2.
6.3.1. Language Extensions 6.3.1. Language Extensions
A module can introduce YANG extensions by using the "extension" A module can introduce YANG extensions by using the "extension"
keyword (see Section 7.19). The extensions can be imported by other keyword (see Section 7.19). The extensions can be imported by other
modules with the "import" statement (see Section 7.1.5). When an modules with the "import" statement (see Section 7.1.5). When an
imported extension is used, the extension's keyword MUST be qualified imported extension is used, the extension's keyword MUST be qualified
using the prefix with which the extension's module was imported. If using the prefix with which the extension's module was imported. If
an extension is used in the module where it is defined, the an extension is used in the module where it is defined, the
extension's keyword MUST be qualified with the module's prefix. extension's keyword MUST be qualified with the prefix of this module.
The processing of extensions depends on whether support for those The processing of extensions depends on whether support for those
extensions is claimed for a given YANG parser or the tool set in extensions is claimed for a given YANG parser or the tool set in
which it is embedded. An unsupported extension, appearing in a YANG which it is embedded. An unsupported extension, appearing in a YANG
module as an unknown-statement (see Section 14) MAY be ignored in its module as an unknown-statement (see Section 14) MAY be ignored in its
entirety. Any supported extension MUST be processed in accordance entirety. Any supported extension MUST be processed in accordance
with the specification governing that extension. with the specification governing that extension.
Care must be taken when defining extensions so that modules that use Care must be taken when defining extensions so that modules that use
the extensions are meaningful also for applications that do not the extensions are meaningful also for applications that do not
skipping to change at page 50, line 41 skipping to change at page 51, line 41
// possibly other top-level nodes here // possibly other top-level nodes here
6.5. Schema Node Identifier 6.5. Schema Node Identifier
A schema node identifier is a string that identifies a node in the A schema node identifier is a string that identifies a node in the
schema tree. It has two forms, "absolute" and "descendant", defined schema tree. It has two forms, "absolute" and "descendant", defined
by the rules "absolute-schema-nodeid" and "descendant-schema-nodeid" by the rules "absolute-schema-nodeid" and "descendant-schema-nodeid"
in Section 14, respectively. A schema node identifier consists of a in Section 14, respectively. A schema node identifier consists of a
path of identifiers, separated by slashes ("/"). In an absolute path of identifiers, separated by slashes ("/"). In an absolute
schema node identifier, the first identifier after the leading slash schema node identifier, the first identifier after the leading slash
is any top-level schema node in the local module or in all imported is any top-level schema node in the local module or in an imported
modules. module.
References to identifiers defined in external modules MUST be References to identifiers defined in external modules MUST be
qualified with appropriate prefixes, and references to identifiers qualified with appropriate prefixes, and references to identifiers
defined in the current module and its submodules MAY use a prefix. defined in the current module and its submodules MAY use a prefix.
For example, to identify the child node "b" of top-level node "a", For example, to identify the child node "b" of top-level node "a",
the string "/a/b" can be used. the string "/a/b" can be used.
7. YANG Statements 7. YANG Statements
skipping to change at page 51, line 24 skipping to change at page 52, line 24
description "some text" { description "some text" {
ex: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 is an identifier (see Section 6.2).
Names of modules published in RFC streams [RFC4844] MUST be assigned Names of modules published in RFC streams [RFC4844] MUST be assigned
by IANA, see section 14 in [RFC6020]. by IANA, see section 14 in [RFC6020].
Private module names are assigned by the organization owning the Private module names are assigned by the organization owning the
module without a central registry. See Section 5.1 for module without a central registry. See Section 5.1 for
recommendations on how to name modules. recommendations on how to name modules.
A module typically has the following layout: A module typically has the following layout:
skipping to change at page 53, line 40 skipping to change at page 54, line 40
| rpc | 7.14 | 0..n | | rpc | 7.14 | 0..n |
| typedef | 7.3 | 0..n | | typedef | 7.3 | 0..n |
| uses | 7.13 | 0..n | | uses | 7.13 | 0..n |
| yang-version | 7.1.2 | 1 | | yang-version | 7.1.2 | 1 |
+--------------+---------+-------------+ +--------------+---------+-------------+
7.1.2. The yang-version Statement 7.1.2. The yang-version Statement
The "yang-version" statement specifies which version of the YANG The "yang-version" statement specifies which version of the YANG
language was used in developing the module. The statement's argument language was used in developing the module. The statement's argument
is a string. It MUST contain the value "1.1", which is the current is a string. It MUST contain the value "1.1" for YANG modules
YANG version. defined based on this specification.
A module or submodule that doesn't contain the "yang-version" A module or submodule that doesn't contain the "yang-version"
statement, or one that contains the value "1", is developed for YANG statement, or one that contains the value "1", is developed for YANG
version 1, defined in [RFC6020]. version 1, defined in [RFC6020].
Handling of the "yang-version" statement for versions other than Handling of the "yang-version" statement for versions other than
"1.1" (the version defined here) is out of scope for this "1.1" (the version defined here) is out of scope for this
specification. Any document that defines a higher version will need specification. Any document that defines a higher version will need
to define the backward compatibility of such a higher version. to define the backward compatibility of such a higher version.
skipping to change at page 54, line 23 skipping to change at page 55, line 23
Section 7.13 for details). The argument to the "namespace" statement Section 7.13 for details). The argument to the "namespace" statement
is the URI of the namespace. is the URI of the namespace.
See also Section 5.3. See also Section 5.3.
7.1.4. The prefix Statement 7.1.4. The prefix Statement
The "prefix" statement is used to define the prefix associated with The "prefix" statement is used to define the prefix associated with
the module and its namespace. The "prefix" statement's argument is the module and its namespace. The "prefix" statement's argument is
the prefix string that is used as a prefix to access a module. The the prefix string that is used as a prefix to access a module. The
prefix string MAY be used to refer to definitions contained in the prefix string MAY be used with the module to refer to definitions
module, e.g., "if:ifName". A prefix follows the same rules as an contained in the module, e.g., "if:ifName". A prefix is an
identifier (see Section 6.2). identifier (see Section 6.2).
When used inside the "module" statement, the "prefix" statement When used inside the "module" statement, the "prefix" statement
defines the prefix suggested to be used when this module is imported. defines the prefix suggested to be used when this module is imported.
To improve readability of the NETCONF XML, a NETCONF client or server To improve readability of the NETCONF XML, a NETCONF client or server
that generates XML or XPath that use prefixes SHOULD use the prefix that generates XML or XPath that use prefixes SHOULD use the prefix
defined by the module, unless there is a conflict. defined by the module as the XML namespace prefix, unless there is a
conflict.
When used inside the "import" statement, the "prefix" statement When used inside the "import" statement, the "prefix" statement
defines the prefix to be used when accessing definitions inside the defines the prefix to be used when accessing definitions inside the
imported module. When a reference to an identifier from the imported imported module. When a reference to an identifier from the imported
module is used, the prefix string for the imported module is used in module is used, the prefix string for the imported module followed by
combination with a colon (":") and the identifier, e.g., a colon (":") and the identifier is used, e.g., "if:ifIndex". To
"if:ifIndex". To improve readability of YANG modules, the prefix improve readability of YANG modules, the prefix defined by a module
defined by a module SHOULD be used when the module is imported, SHOULD be used when the module is imported, unless there is a
unless there is a conflict. If there is a conflict, i.e., two conflict. If there is a conflict, i.e., two different modules that
different modules that both have defined the same prefix are both have defined the same prefix are imported, at least one of them
imported, at least one of them MUST be imported with a different MUST be imported with a different prefix.
prefix.
All prefixes, including the prefix for the module itself MUST be All prefixes, including the prefix for the module itself MUST be
unique within the module or submodule. unique within the module or submodule.
7.1.5. The import Statement 7.1.5. The import Statement
The "import" statement makes definitions from one module available The "import" statement makes definitions from one module available
inside another module or submodule. The argument is the name of the inside another module or submodule. The argument is the name of the
module to import, and the statement is followed by a block of module to import, and the statement is followed by a block of
substatements that holds detailed import information. When a module substatements that holds detailed import information. When a module
skipping to change at page 55, line 46 skipping to change at page 57, line 7
| 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 | | description | 7.21.3 | 0..1 |
| reference | 7.21.4 | 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 version
version of the module to import. of the module to import.
7.1.6. The include Statement 7.1.6. The include Statement
The "include" statement is used to make content from a submodule The "include" statement is used to make content from a submodule
available to that submodule's parent module. The argument is an available to that submodule's parent module. The argument is an
identifier that is the name of the submodule to include. Modules are identifier that is the name of the submodule to include. Modules are
only allowed to include submodules that belong to that module, as only allowed to include submodules that belong to that module, as
defined by the "belongs-to" statement (see Section 7.2.2). defined by the "belongs-to" statement (see Section 7.2.2).
When a module includes a submodule, it incorporates the contents of When a module includes a submodule, it incorporates the contents of
the submodule into the node hierarchy of the module. the submodule into the node hierarchy of the module.
For backward compatibility with YANG version 1, a submodule is For backward compatibility with YANG version 1, a submodule is
allowed to include another submodule belonging to the same module, allowed to include another submodule belonging to the same module,
but this is not necessary in YANG version 1.1. but this is not necessary in YANG version 1.1 (see Section 5.1).
When the optional "revision-date" substatement is present, the When the optional "revision-date" substatement is present, the
specified revision of the submodule is included in the module. It is specified revision of the submodule is included in the module. It is
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.
+---------------+---------+-------------+ +---------------+---------+-------------+
skipping to change at page 58, line 50 skipping to change at page 59, line 50
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
designer to split a complex model into several pieces where all the designer to split a complex model into several pieces where all the
submodules contribute to a single namespace, which is defined by the submodules contribute to a single namespace, which is defined by the
module that includes the submodules. module that includes the submodules.
The "submodule" statement defines the submodule's name, and groups The "submodule" statement defines the submodule's name, and groups
all statements that belong to the submodule together. The all statements that belong to the submodule together. The
"submodule" statement's argument is the name of the submodule, "submodule" statement's argument is the name of the submodule,
followed by a block of substatements that hold detailed submodule followed by a block of substatements that hold detailed submodule
information. The submodule name follows the rules for identifiers in information. The submodule name is an identifier (see Section 6.2).
Section 6.2.
Names of submodules published in RFC streams [RFC4844] MUST be Names of submodules published in RFC streams [RFC4844] MUST be
assigned by IANA, see section 14 in [RFC6020]. assigned by IANA, see section 14 in [RFC6020].
Private submodule names are assigned by the organization owning the Private submodule names are assigned by the organization owning the
submodule without a central registry. See Section 5.1 for submodule without a central registry. See Section 5.1 for
recommendations on how to name submodules. recommendations on how to name submodules.
A submodule typically has the following layout: A submodule typically has the following layout:
skipping to change at page 64, line 16 skipping to change at page 65, line 16
nodes in the data tree. The child nodes are defined in the nodes in the data tree. The child nodes are defined in the
container's substatements. container's substatements.
7.5.1. Containers with Presence 7.5.1. Containers with Presence
YANG supports two styles of containers, those that exist only for YANG supports two styles of containers, those that exist only for
organizing the hierarchy of data nodes, and those whose presence in organizing the hierarchy of data nodes, and those whose presence in
the data tree has an explicit meaning. the data tree has an explicit meaning.
In the first style, the container has no meaning of its own, existing In the first style, the container has no meaning of its own, existing
only to contain child nodes. This is the default style. only to contain child nodes. In particular, the presence of the
container node with no child nodes is semantically equivalent to the
absence of the container node. YANG calls this style a "non-presence
container". This is the default style.
For example, the set of scrambling options for Synchronous Optical For example, the set of scrambling options for Synchronous Optical
Network (SONET) interfaces may be placed inside a "scrambling" Network (SONET) interfaces may be placed inside a "scrambling"
container to enhance the organization of the configuration hierarchy, container to enhance the organization of the configuration hierarchy,
and to keep these nodes together. The "scrambling" node itself has and to keep these nodes together. The "scrambling" node itself has
no meaning, so removing the node when it becomes empty relieves the no meaning, so removing the node when it becomes empty relieves the
user from performing this task. user from performing this task.
In the second style, the presence of the container itself carries In the second style, the presence of the container itself carries
some meaning, representing a single bit of data. some meaning, representing a single bit of data.
In configuration data, the container acts as both a configuration For configuration data, the container acts as both a configuration
knob and a means of organizing related configuration. These knob and a means of organizing related configuration. These
containers are explicitly created and deleted. containers are explicitly created and deleted.
YANG calls this style a "presence container" and it is indicated YANG calls this style a "presence container" and it is indicated
using the "presence" statement, which takes as its argument a text using the "presence" statement, which takes as its argument a text
string indicating what the presence of the node means. string indicating what the presence of the node means.
For example, an "ssh" container may turn on the ability to log into For example, an "ssh" container may turn on the ability to log into
the server using ssh, but can also contain any ssh-related the server using ssh, but can also contain any ssh-related
configuration knobs, such as connection rates or retry limits. configuration knobs, such as connection rates or retry limits.
skipping to change at page 65, line 40 skipping to change at page 66, line 40
The "must" statement, which is optional, takes as an argument a The "must" statement, which is optional, takes as an argument a
string that contains an XPath expression (see Section 6.4). It is string that contains an XPath expression (see Section 6.4). It is
used to formally declare a constraint on valid data. The constraint used to formally declare a constraint on valid data. The constraint
is enforced according to the rules in Section 8. is enforced according to the rules in Section 8.
When a datastore is validated, all "must" constraints are When a datastore is validated, all "must" constraints are
conceptually evaluated once for each node in the accessible tree (see conceptually evaluated once for each node in the accessible tree (see
Section 6.4.1). Section 6.4.1).
All such constraints MUST evaluate to true for the data to be valid. All such constraints MUST evaluate to "true" for the data to be
valid.
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.
skipping to change at page 66, line 28 skipping to change at page 67, line 28
+---------------+---------+-------------+ +---------------+---------+-------------+
| description | 7.21.3 | 0..1 | | description | 7.21.3 | 0..1 |
| error-app-tag | 7.5.4.2 | 0..1 | | error-app-tag | 7.5.4.2 | 0..1 |
| error-message | 7.5.4.1 | 0..1 | | error-message | 7.5.4.1 | 0..1 |
| reference | 7.21.4 | 0..1 | | reference | 7.21.4 | 0..1 |
+---------------+---------+-------------+ +---------------+---------+-------------+
7.5.4.1. The error-message Statement 7.5.4.1. The error-message Statement
The "error-message" statement, which is optional, takes a string as The "error-message" statement, which is optional, takes a string as
an argument. If the constraint evaluates to false, the string is an argument. If the constraint evaluates to "false", the string is
passed as <error-message> in the <rpc-error> in NETCONF. passed as <error-message> in the <rpc-error> in NETCONF.
7.5.4.2. The error-app-tag Statement 7.5.4.2. The error-app-tag Statement
The "error-app-tag" statement, which is optional, takes a string as The "error-app-tag" statement, which is optional, takes a string as
an argument. If the constraint evaluates to false, the string is an argument. If the constraint evaluates to "false", the string is
passed as <error-app-tag> in the <rpc-error> in NETCONF. passed as <error-app-tag> in the <rpc-error> in NETCONF.
7.5.4.3. Usage Example of must and error-message 7.5.4.3. Usage Example of must and error-message
container interface { container interface {
leaf ifType { leaf ifType {
type enumeration { type enumeration {
enum ethernet; enum ethernet;
enum atm; enum atm;
} }
} }
leaf ifMTU { leaf ifMTU {
type uint32; type uint32;
} }
must "ifType != 'ethernet' or " + must 'ifType != "ethernet" or ifMTU = 1500' {
"(ifType = 'ethernet' and ifMTU = 1500)" {
error-message "An ethernet MTU must be 1500"; error-message "An ethernet MTU must be 1500";
} }
must "ifType != 'atm' or " + must 'ifType != "atm" or'
"(ifType = 'atm' and ifMTU <= 17966 and ifMTU >= 64)" { + ' (ifMTU <= 17966 and ifMTU >= 64)' {
error-message "An atm MTU must be 64 .. 17966"; error-message "An atm MTU must be 64 .. 17966";
} }
} }
7.5.5. The presence Statement 7.5.5. The presence Statement
The "presence" statement assigns a meaning to the presence of a The "presence" statement assigns a meaning to the presence of a
container in the data tree. It takes as an argument a string that container in the data tree. It takes as an argument a string that
contains a textual description of what the node's presence means. contains a textual description of what the node's presence means.
skipping to change at page 68, line 7 skipping to change at page 69, line 7
A container node is encoded as an XML element. The element's local A container node is encoded as an XML element. The element's local
name is the container's identifier, and its namespace is the module's name is the container's identifier, and its namespace is the module's
XML namespace (see Section 7.1.3). XML namespace (see Section 7.1.3).
The container's child nodes are encoded as subelements to the The container's child nodes are encoded as subelements to the
container element. If the container defines RPC or action input or container element. If the container defines RPC or action input or
output parameters, these subelements are encoded in the same order as output parameters, these subelements are encoded in the same order as
they are defined within the "container" statement. Otherwise, the they are defined within the "container" statement. Otherwise, the
subelements are encoded in any order. subelements are encoded in any order.
Any whitespace between the subelements to the container is
insignificant, i.e., an implementation MAY insert whitespace
characters between subelements.
If a non-presence container does not have any child nodes, the If a non-presence container does not have any child nodes, the
container may or may not be present in the XML encoding. container may or may not be present in the XML encoding.
7.5.8. NETCONF <edit-config> Operations 7.5.8. NETCONF <edit-config> Operations
Containers can be created, deleted, replaced, and modified through Containers can be created, deleted, replaced, and modified through
<edit-config>, by using the "operation" attribute (see [RFC6241], <edit-config>, by using the "operation" attribute (see [RFC6241],
Section 7.2) in the container's XML element. Section 7.2) in the container's XML element.
If a container does not have a "presence" statement and the last If a container does not have a "presence" statement and the last
skipping to change at page 69, line 52 skipping to change at page 71, line 25
A leaf node exists in zero or one instances in the data tree. A leaf node exists in zero or one instances in the data tree.
The "leaf" statement is used to define a scalar variable of a The "leaf" statement is used to define a scalar variable of a
particular built-in or derived type. particular built-in or derived type.
7.6.1. The leaf's default value 7.6.1. The leaf's default value
The default value of a leaf is the value that the server uses if the The default value of a leaf is the value that the server uses if the
leaf does not exist in the data tree. The usage of the default value leaf does not exist in the data tree. The usage of the default value
depends on the leaf's closest ancestor node in the schema tree that depends on the leaf's closest ancestor node in the schema tree that
is not a non-presence-container (see Section 7.5.1): is not a non-presence container (see Section 7.5.1):
o If no such ancestor exists in the schema tree, the default value o If no such ancestor exists in the schema tree, the default value
MUST be used. MUST be used.
o Otherwise, if this ancestor is a case node, the default value MUST o Otherwise, if this ancestor is a case node, the default value MUST
be used if any node from the case exists in the data tree, or if be used if any node from the case exists in the data tree, or if
the case node is the choice's default case, and no nodes from any the case node is the choice's default case, and no nodes from any
other case exist in the data tree. other case exist in the data tree.
o Otherwise, the default value MUST be used if the ancestor node o Otherwise, the default value MUST be used if the ancestor node
skipping to change at page 71, line 21 skipping to change at page 72, line 39
7.6.4. The leaf's default Statement 7.6.4. The leaf's default Statement
The "default" statement, which is optional, takes as an argument a The "default" statement, which is optional, takes as an argument a
string that contains a default value for the leaf. string that contains a default value for the leaf.
The value of the "default" statement MUST be valid according to the The value of the "default" statement MUST be valid according to the
type specified in the leaf's "type" statement. type specified in the leaf's "type" statement.
The "default" statement MUST NOT be present on nodes where The "default" statement MUST NOT be present on nodes where
"mandatory" is true. "mandatory" is "true".
The default value MUST NOT be marked with an "if-feature" statement. The definition of the default value MUST NOT be marked with an
For example, the following is illegal: "if-feature" statement. For example, the following is illegal:
leaf color { leaf color {
type enumeration { type enumeration {
enum blue { if-feature blue; } enum blue { if-feature blue; }
... ...
} }
default blue; // illegal - enum value is conditional default blue; // illegal - enum value is conditional
} }
7.6.5. The leaf's mandatory Statement 7.6.5. The leaf's mandatory Statement
The "mandatory" statement, which is optional, takes as an argument The "mandatory" statement, which is optional, takes as an argument
the string "true" or "false", and puts a constraint on valid data. the string "true" or "false", and puts a constraint on valid data.
If not specified, the default is "false". If not specified, the default is "false".
If "mandatory" is "true", the behavior of the constraint depends on If "mandatory" is "true", the behavior of the constraint depends on
the type of the leaf's closest ancestor node in the schema tree that the type of the leaf's closest ancestor node in the schema tree that
is not a non-presence-container (see Section 7.5.1): is not a non-presence container (see Section 7.5.1):
o If no such ancestor exists in the schema tree, the leaf MUST o If no such ancestor exists in the schema tree, the leaf MUST
exist. exist.
o Otherwise, if this ancestor is a case node, the leaf MUST exist if o Otherwise, if this ancestor is a case node, the leaf MUST exist if
any node from the case exists in the data tree. any node from the case exists in the data tree.
o Otherwise, the leaf MUST exist if the ancestor node exists in the o Otherwise, the leaf MUST exist if the ancestor node exists in the
data tree. data tree.
skipping to change at page 73, line 34 skipping to change at page 75, line 5
7.7. The leaf-list Statement 7.7. The leaf-list Statement
Where the "leaf" statement is used to define a simple scalar variable Where the "leaf" statement is used to define a simple scalar variable
of a particular type, the "leaf-list" statement is used to define an of a particular type, the "leaf-list" statement is used to define an
array of a particular type. The "leaf-list" statement takes one array of a particular type. The "leaf-list" statement 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 leaf-list information. substatements that holds detailed leaf-list information.
In configuration data, the values in a leaf-list MUST be unique. In configuration data, the values in a leaf-list MUST be unique.
The default values MUST NOT be marked with an "if-feature" statement. The definitions of the default values MUST NOT be marked with an
"if-feature" statement.
Conceptually, the values in the data tree are always in the canonical Conceptually, the values in the data tree MUST be in the canonical
form (see Section 9.1). form (see Section 9.1).
7.7.1. Ordering 7.7.1. Ordering
YANG supports two styles for ordering the entries within lists and YANG supports two styles for ordering the entries within lists and
leaf-lists. In many lists, the order of list entries does not impact leaf-lists. In many lists, the order of list entries does not impact
the implementation of the list's configuration, and the server is the implementation of the list's configuration, and the server is
free to sort the list entries in any reasonable order. The free to sort the list entries in any reasonable order. The
"description" string for the list may suggest an order to the server "description" string for the list may suggest an order to the server
implementor. YANG calls this style of list "system ordered" and they implementor. YANG calls this style of list "system ordered" and they
skipping to change at page 74, line 31 skipping to change at page 75, line 51
positioned as the first or last entry in the list, or positioned positioned as the first or last entry in the list, or positioned
before or after another specific entry. before or after another specific entry.
The "ordered-by" statement is covered in Section 7.7.7. The "ordered-by" statement is covered in Section 7.7.7.
7.7.2. The leaf-list's default values 7.7.2. The leaf-list's default values
The default values of a leaf-list are the values that the server uses The default values of a leaf-list are the values that the server uses
if the leaf-list does not exist in the data tree. The usage of the if the leaf-list does not exist in the data tree. The usage of the
default values depends on the leaf-list's closest ancestor node in default values depends on the leaf-list's closest ancestor node in
the schema tree that is not a non-presence-container (see the schema tree that is not a non-presence container (see
Section 7.5.1): Section 7.5.1):
o If no such ancestor exists in the schema tree, the default values o If no such ancestor exists in the schema tree, the default values
MUST be used. MUST be used.
o Otherwise, if this ancestor is a case node, the default values o Otherwise, if this ancestor is a case node, the default values
MUST be used if any node from the case exists in the data tree, or MUST be used if any node from the case exists in the data tree, or
if the case node is the choice's default case, and no nodes from if the case node is the choice's default case, and no nodes from
any other case exist in the data tree. any other case exist in the data tree.
skipping to change at page 75, line 10 skipping to change at page 76, line 27
Note that if the leaf-list or any of its ancestors has a "when" Note that if the leaf-list or any of its ancestors has a "when"
condition or "if-feature" expression that evaluates to "false", then condition or "if-feature" expression that evaluates to "false", then
the default values are not in use. the default values are not in use.
When the default values are in use, the server MUST operationally When the default values are in use, the server MUST operationally
behave as if the leaf-list was present in the data tree with the behave as if the leaf-list was present in the data tree with the
default values as its values. default values as its values.
If a leaf-list has one or more "default" statement, the leaf-list's If a leaf-list has one or more "default" statement, the leaf-list's
default value are the values of the "default" statements, and if the default values are the values of the "default" statements, and if the
leaf-list is user-ordered, the default values are used in the order leaf-list is user-ordered, the default values are used in the order
of the "default" statements. Otherwise, if the leaf-list's type has of the "default" statements. Otherwise, if the leaf-list's type has
a default value, and the leaf-list does not have a "min-elements" a default value, and the leaf-list does not have a "min-elements"
statement with a value greater than or equal to one, then the leaf- statement with a value greater than or equal to one, then the leaf-
list's default value is the type's default value. In all other list's default value is one instance of the type's default value. In
cases, the leaf-list does not have any default values. all other cases, the leaf-list does not have any default values.
7.7.3. The leaf-list's Substatements 7.7.3. The leaf-list's Substatements
+--------------+---------+-------------+ +--------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+--------------+---------+-------------+ +--------------+---------+-------------+
| config | 7.21.1 | 0..1 | | config | 7.21.1 | 0..1 |
| default | 7.7.4 | 0..n | | default | 7.7.4 | 0..n |
| description | 7.21.3 | 0..1 | | description | 7.21.3 | 0..1 |
| if-feature | 7.20.2 | 0..n | | if-feature | 7.20.2 | 0..n |
| max-elements | 7.7.6 | 0..1 | | max-elements | 7.7.6 | 0..1 |
| min-elements | 7.7.5 | 0..1 | | min-elements | 7.7.5 | 0..1 |
| must | 7.5.3 | 0..n | | must | 7.5.3 | 0..n |
skipping to change at page 76, line 15 skipping to change at page 77, line 43
7.7.5. The min-elements Statement 7.7.5. The min-elements Statement
The "min-elements" statement, which is optional, takes as an argument The "min-elements" statement, which is optional, takes as an argument
a non-negative integer that puts a constraint on valid list entries. a non-negative integer that puts a constraint on valid list entries.
A valid leaf-list or list MUST have at least min-elements entries. A valid leaf-list or list MUST have at least min-elements entries.
If no "min-elements" statement is present, it defaults to zero. If no "min-elements" statement is present, it defaults to zero.
The behavior of the constraint depends on the type of the leaf-list's The behavior of the constraint depends on the type of the leaf-list's
or list's closest ancestor node in the schema tree that is not a non- or list's closest ancestor node in the schema tree that is not a non-
presence-container (see Section 7.5.1): presence container (see Section 7.5.1):
o If this ancestor is a case node, the constraint is enforced if any o If no such ancestor exists in the schema tree, the constraint is
other node from the case exists. enforced.
o Otherwise, if this ancestor is a case node, the constraint is
enforced if any other node from the case exists.
o Otherwise, it is enforced if the ancestor node exists. o Otherwise, it is enforced if the ancestor node exists.
The constraint is further enforced according to the rules in The constraint is further enforced according to the rules in
Section 8. Section 8.
7.7.6. The max-elements Statement 7.7.6. The max-elements Statement
The "max-elements" statement, which is optional, takes as an argument The "max-elements" statement, which is optional, takes as an argument
a positive integer or the string "unbounded", which puts a constraint a positive integer or the string "unbounded", which puts a constraint
skipping to change at page 77, line 7 skipping to change at page 78, line 35
is one of the strings "system" or "user". If not present, order is one of the strings "system" or "user". If not present, order
defaults to "system". defaults to "system".
This statement is ignored if the list represents state data, RPC This statement is ignored if the list represents state data, RPC
output parameters, or notification content. output parameters, or notification content.
See Section 7.7.1 for additional information. See Section 7.7.1 for additional information.
7.7.7.1. ordered-by system 7.7.7.1. ordered-by system
The entries in the list are sorted according to an order determined The entries in the list are ordered according to an order determined
by the system. The "description" string for the list may suggest an by the system. The "description" string for the list may suggest an
order to the server implementor. If not, an implementation is free order to the server implementor. If not, an implementation is free
to sort the entries in the most appropriate order. An implementation to order the entries in any order. An implementation SHOULD use the
SHOULD use the same order for the same data, regardless of how the same order for the same data, regardless of how the data were
data were created. Using a deterministic order will make comparisons created. Using a deterministic order will make comparisons possible
possible using simple tools like "diff". using simple tools like "diff".
This is the default order. This is the default order.
7.7.7.2. ordered-by user 7.7.7.2. ordered-by user
The entries in the list are sorted according to an order defined by The entries in the list are ordered according to an order defined by
the user. This order is controlled by using special XML attributes the user. In NETCONF, this order is controlled by using special XML
in the <edit-config> request. See Section 7.7.9 for details. attributes in the <edit-config> request. See Section 7.7.9 for
details.
7.7.8. XML Encoding Rules 7.7.8. XML Encoding Rules
A leaf-list node is encoded as a series of XML elements. Each A leaf-list node is encoded as a series of XML elements. Each
element's local name is the leaf-list's identifier, and its namespace element's local name is the leaf-list's identifier, and its namespace
is the module's XML namespace (see Section 7.1.3). is the module's XML namespace (see Section 7.1.3).
The value of each leaf-list entry is encoded to XML according to the The value of each leaf-list entry is encoded to XML according to the
type, and sent as character data in the element. type, and sent as character data in the element.
The XML elements representing leaf-list entries MUST appear in the The XML elements representing leaf-list entries MUST appear in the
order specified by the user if the leaf-list is "ordered-by user"; order specified by the user if the leaf-list is "ordered-by user";
otherwise, the order is implementation-dependent. The XML elements otherwise, the order is implementation-dependent. The XML elements
representing leaf-list entries MAY be interleaved with other sibling representing leaf-list entries MAY be interleaved with elements for
elements, unless the leaf-list defines RPC or action input or output siblings of the leaf-list, unless the leaf-list defines RPC or action
parameters. input or output parameters.
See Section 7.7.10 for an example. See Section 7.7.10 for an example.
7.7.9. NETCONF <edit-config> Operations 7.7.9. NETCONF <edit-config> Operations
Leaf-list entries can be created and deleted, but not modified, Leaf-list entries can be created and deleted, but not modified,
through <edit-config>, by using the "operation" attribute in the through <edit-config>, by using the "operation" attribute in the
leaf-list entry's XML element. leaf-list entry's XML element.
In an "ordered-by user" leaf-list, the attributes "insert" and In an "ordered-by user" leaf-list, the attributes "insert" and
skipping to change at page 81, line 37 skipping to change at page 82, line 40
| typedef | 7.3 | 0..n | | typedef | 7.3 | 0..n |
| unique | 7.8.3 | 0..n | | unique | 7.8.3 | 0..n |
| uses | 7.13 | 0..n | | uses | 7.13 | 0..n |
| when | 7.21.5 | 0..1 | | when | 7.21.5 | 0..1 |
+--------------+---------+-------------+ +--------------+---------+-------------+
7.8.2. The list's key Statement 7.8.2. The list's key Statement
The "key" statement, which MUST be present if the list represents The "key" statement, which MUST be present if the list represents
configuration, and MAY be present otherwise, takes as an argument a configuration, and MAY be present otherwise, takes as an argument a
string that specifies a space-separated list of leaf identifiers of string that specifies a space-separated list of one or more leaf
this list. A leaf identifier MUST NOT appear more than once in the identifiers of this list. A leaf identifier MUST NOT appear more
key. Each such leaf identifier MUST refer to a child leaf of the than once in the key. Each such leaf identifier MUST refer to a
list. The leafs can be defined directly in substatements to the child leaf of the list. The leafs can be defined directly in
list, or in groupings used in the list. substatements to the list, or in groupings used in the list.
The combined values of all the leafs specified in the key are used to The combined values of all the leafs specified in the key are used to
uniquely identify a list entry. All key leafs MUST be given values uniquely identify a list entry. All key leafs MUST be given values
when a list entry is created. Thus, any default values in the key when a list entry is created. Thus, any default values in the key
leafs or their types are ignored. It also implies that any mandatory leafs or their types are ignored. It also implies that any mandatory
statement in the key leafs are ignored. statement in the key leafs are ignored.
A leaf that is part of the key can be of any built-in or derived A leaf that is part of the key can be of any built-in or derived
type. type.
skipping to change at page 82, line 25 skipping to change at page 83, line 28
separated list of schema node identifiers, which MUST be given in the separated list of schema node identifiers, which MUST be given in the
descendant form (see the rule "descendant-schema-nodeid" in descendant form (see the rule "descendant-schema-nodeid" in
Section 14). Each such schema node identifier MUST refer to a leaf. Section 14). Each such schema node identifier MUST refer to a leaf.
If one of the referenced leafs represents configuration data, then If one of the referenced leafs represents configuration data, then
all of the referenced leafs MUST represent configuration data. all of the referenced leafs MUST represent configuration data.
The "unique" constraint specifies that the combined values of all the The "unique" constraint specifies that the combined values of all the
leaf instances specified in the argument string, including leafs with leaf instances specified in the argument string, including leafs with
default values, MUST be unique within all list entry instances in default values, MUST be unique within all list entry instances in
which all referenced leafs exist. The constraint is enforced which all referenced leafs exist or have default values. The
according to the rules in Section 8. constraint is enforced according to the rules in Section 8.
The unique string syntax is formally defined by the rule "unique-arg" The unique string syntax is formally defined by the rule "unique-arg"
in Section 14. in Section 14.
7.8.3.1. Usage Example 7.8.3.1. Usage Example
With the following list: With the following list:
list server { list server {
key "name"; key "name";
skipping to change at page 83, line 48 skipping to change at page 84, line 48
Within a list, the "container", "leaf", "list", "leaf-list", "uses", Within a list, the "container", "leaf", "list", "leaf-list", "uses",
"choice", "anydata", and "anyxml" statements can be used to define "choice", "anydata", and "anyxml" statements can be used to define
child nodes to the list. child nodes to the list.
7.8.5. XML Encoding Rules 7.8.5. XML Encoding Rules
A list is encoded as a series of XML elements, one for each entry in A list is encoded as a series of XML elements, one for each entry in
the list. Each element's local name is the list's identifier, and the list. Each element's local name is the list's identifier, and
its namespace is the module's XML namespace (see Section 7.1.3). its namespace is the module's XML namespace (see Section 7.1.3).
There is no XML element surrounding the list as a whole.
The list's key nodes are encoded as subelements to the list's The list's key nodes are encoded as subelements to the list's
identifier element, in the same order as they are defined within the identifier element, in the same order as they are defined within the
"key" statement. "key" statement.
The rest of the list's child nodes are encoded as subelements to the The rest of the list's child nodes are encoded as subelements to the
list element, after the keys. If the list defines RPC or action list element, after the keys. If the list defines RPC or action
input or output parameters, the subelements are encoded in the same input or output parameters, the subelements are encoded in the same
order as they are defined within the "list" statement. Otherwise, order as they are defined within the "list" statement. Otherwise,
the subelements are encoded in any order. the subelements are encoded in any order.
Any whitespace between the subelements to the list entry is
insignificant, i.e., an implementation MAY insert whitespace
characters between subelements.
The XML elements representing list entries MUST appear in the order The XML elements representing list entries MUST appear in the order
specified by the user if the list is "ordered-by user", otherwise the specified by the user if the list is "ordered-by user", otherwise the
order is implementation-dependent. The XML elements representing order is implementation-dependent. The XML elements representing
list entries MAY be interleaved with other sibling elements, unless list entries MAY be interleaved with elements for siblings of the
the list defines RPC or action input or output parameters. list, unless the list defines RPC or action input or output
parameters.
7.8.6. NETCONF <edit-config> Operations 7.8.6. NETCONF <edit-config> Operations
List entries can be created, deleted, replaced, and modified through List entries can be created, deleted, replaced, and modified through
<edit-config>, by using the "operation" attribute in the list's XML <edit-config>, by using the "operation" attribute in the list's XML
element. In each case, the values of all keys are used to uniquely element. In each case, the values of all keys are used to uniquely
identify a list entry. If all keys are not specified for a list identify a list entry. If all keys are not specified for a list
entry, a "missing-element" error is returned. entry, a "missing-element" error is returned.
In an "ordered-by user" list, the attributes "insert" and "key" in In an "ordered-by user" list, the attributes "insert" and "key" in
skipping to change at page 88, line 31 skipping to change at page 89, line 31
<surname>rubble</surname> <surname>rubble</surname>
</user> </user>
</system> </system>
</config> </config>
</edit-config> </edit-config>
</rpc> </rpc>
7.9. The choice Statement 7.9. The choice Statement
The "choice" statement defines a set of alternatives, only one of The "choice" statement defines a set of alternatives, only one of
which may exist at any one time. The argument is an identifier, which may be present in any one data tree. The argument is an
followed by a block of substatements that holds detailed choice identifier, followed by a block of substatements that holds detailed
information. The identifier is used to identify the choice node in choice information. The identifier is used to identify the choice
the schema tree. A choice node does not exist in the data tree. node in the schema tree. A choice node does not exist in the data
tree.
A choice consists of a number of branches, defined with the "case" A choice consists of a number of branches, each defined with a "case"
substatement. Each branch contains a number of child nodes. The substatement. Each branch contains a number of child nodes. The
nodes from at most one of the choice's branches exist at the same nodes from at most one of the choice's branches exist at the same
time. time.
Since only one of the choice's cases can be valid at any time in the Since only one of the choice's cases can be valid at any time in the
data tree, the creation of a node from one case implicitly deletes data tree, the creation of a node from one case implicitly deletes
all nodes from all other cases. If a request creates a node from a all nodes from all other cases. If a request creates a node from a
case, the server will delete any existing nodes that are defined in case, the server will delete any existing nodes that are defined in
other cases inside the choice. other cases inside the choice.
skipping to change at page 90, line 5 skipping to change at page 91, line 5
} }
case b { case b {
container ethernet { ...} container ethernet { ...}
} }
} }
As a shorthand, the "case" statement can be omitted if the branch As a shorthand, the "case" statement can be omitted if the branch
contains a single "anydata", "anyxml", "choice", "container", "leaf", contains a single "anydata", "anyxml", "choice", "container", "leaf",
"list", or "leaf-list" statement. In this case, the case node still "list", or "leaf-list" statement. In this case, the case node still
exists in the schema tree, and its identifier is the same as the exists in the schema tree, and its identifier is the same as the
identifier in the branch statement. Schema node identifiers identifier of the child node. Schema node identifiers (Section 6.5)
(Section 6.5) MUST always explicitly include case node identifiers. MUST always explicitly include case node identifiers. The following
The following example: example:
choice interface-type { choice interface-type {
container ethernet { ... } container ethernet { ... }
} }
is equivalent to: is equivalent to:
choice interface-type { choice interface-type {
case ethernet { case ethernet {
container ethernet { ... } container ethernet { ... }
skipping to change at page 90, line 47 skipping to change at page 91, line 47
| reference | 7.21.4 | 0..1 | | reference | 7.21.4 | 0..1 |
| status | 7.21.2 | 0..1 | | status | 7.21.2 | 0..1 |
| uses | 7.13 | 0..n | | uses | 7.13 | 0..n |
| when | 7.21.5 | 0..1 | | when | 7.21.5 | 0..1 |
+--------------+---------+-------------+ +--------------+---------+-------------+
7.9.3. The choice's default Statement 7.9.3. The choice's default Statement
The "default" statement indicates if a case should be considered as The "default" statement indicates if a case should be considered as
the default if no child nodes from any of the choice's cases exist. the default if no child nodes from any of the choice's cases exist.
The argument is the identifier of the "case" statement. If the The argument is the identifier of the default "case" statement. If
"default" statement is missing, there is no default case. the "default" statement is missing, there is no default case.
The "default" statement MUST NOT be present on choices where The "default" statement MUST NOT be present on choices where
"mandatory" is true. "mandatory" is "true".
The default case is only important when considering the default The default case is only important when considering the default
statements of nodes under the cases (i.e., default values of leafs statements of nodes under the cases (i.e., default values of leafs
and leaf-lists, and default cases of nested choices). The default and leaf-lists, and default cases of nested choices). The default
values and nested default cases under the default case are used if values and nested default cases under the default case are used if
none of the nodes under any of the cases are present. none of the nodes under any of the cases are present.
There MUST NOT be any mandatory nodes (Section 3) directly under the There MUST NOT be any mandatory nodes (Section 3) directly under the
default case. default case.
skipping to change at page 92, line 15 skipping to change at page 93, line 15
7.9.4. The choice's mandatory Statement 7.9.4. The choice's mandatory Statement
The "mandatory" statement, which is optional, takes as an argument The "mandatory" statement, which is optional, takes as an argument
the string "true" or "false", and puts a constraint on valid data. the string "true" or "false", and puts a constraint on valid data.
If "mandatory" is "true", at least one node from exactly one of the If "mandatory" is "true", at least one node from exactly one of the
choice's case branches MUST exist. choice's case branches MUST exist.
If not specified, the default is "false". If not specified, the default is "false".
The behavior of the constraint depends on the type of the choice's The behavior of the constraint depends on the type of the choice's
closest ancestor node in the schema tree that is not a non-presence- closest ancestor node in the schema tree that is not a non-presence
container (see Section 7.5.1): container (see Section 7.5.1):
o If this ancestor is a case node, the constraint is enforced if any o If no such ancestor exists in the schema tree, the constraint is
other node from the case exists. enforced.
o Otherwise, if this ancestor is a case node, the constraint is
enforced if any other node from the case exists.
o Otherwise, it is enforced if the ancestor node exists. o Otherwise, it is enforced if the ancestor node exists.
The constraint is further enforced according to the rules in The constraint is further enforced according to the rules in
Section 8. Section 8.
7.9.5. XML Encoding Rules 7.9.5. XML Encoding Rules
The choice and case nodes are not visible in XML. The choice and case nodes are not visible in XML.
skipping to change at page 93, line 44 skipping to change at page 95, line 10
substatements that holds detailed anydata information. substatements that holds detailed anydata information.
The "anydata" statement is used to represent an unknown set of nodes The "anydata" statement is used to represent an unknown set of nodes
that can be modelled with YANG, except anyxml, but for which the data that can be modelled with YANG, except anyxml, but for which the data
model is not known at module design time. It is possible, though not model is not known at module design time. It is possible, though not
required, for the data model for "anydata" content to become known required, for the data model for "anydata" content to become known
through protocol signalling or other means that are outside the scope through protocol signalling or other means that are outside the scope
of this document. of this document.
An example of where anydata can be useful is a list of received An example of where anydata can be useful is a list of received
notifications, where the exact notifications are not known at design notifications, where the specific notifications are not known at
time. design time.
An anydata node cannot be augmented (see Section 7.17). An anydata node cannot be augmented (see Section 7.17).
An anydata node exists in zero or one instances in the data tree. An anydata node exists in zero or one instances in the data tree.
An implementation may or may not know the data model used to model a An implementation may or may not know the data model used to model a
specific instance of an anydata node. specific instance of an anydata node.
Since the use of anydata limits the manipulation of the content, it Since the use of anydata limits the manipulation of the content, the
is RECOMMENDED that the "anydata" statement not be used to define "anydata" statement SHOULD NOT be used to define configuration data.
configuration data.
7.10.1. The anydata's Substatements 7.10.1. The anydata's Substatements
+--------------+---------+-------------+ +--------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+--------------+---------+-------------+ +--------------+---------+-------------+
| config | 7.21.1 | 0..1 | | config | 7.21.1 | 0..1 |
| description | 7.21.3 | 0..1 | | description | 7.21.3 | 0..1 |
| if-feature | 7.20.2 | 0..n | | if-feature | 7.20.2 | 0..n |
| mandatory | 7.6.5 | 0..1 | | mandatory | 7.6.5 | 0..1 |
skipping to change at page 96, line 5 skipping to change at page 97, line 20
The "anyxml" statement is used to represent an unknown chunk of XML. The "anyxml" statement is used to represent an unknown chunk of XML.
No restrictions are placed on the XML. This can be useful, for No restrictions are placed on the XML. This can be useful, for
example, in RPC replies. An example is the <filter> parameter in the example, in RPC replies. An example is the <filter> parameter in the
<get-config> operation in NETCONF. <get-config> operation in NETCONF.
An anyxml node cannot be augmented (see Section 7.17). An anyxml node cannot be augmented (see Section 7.17).
An anyxml node exists in zero or one instances in the data tree. An anyxml node exists in zero or one instances in the data tree.
Since the use of anyxml limits the manipulation of the content, it is Since the use of anyxml limits the manipulation of the content, the
RECOMMENDED that the "anyxml" statement not be used to define "anyxml" statement SHOULD NOT be used to define configuration data.
configuration data.
It should be noted that in YANG version 1, anyxml was the only It should be noted that in YANG version 1, anyxml was the only
statement that could model an unknown hierarchy of data. In many statement that could model an unknown hierarchy of data. In many
cases this unknown hierarchy of data is actually modelled in YANG, cases this unknown hierarchy of data is actually modelled in YANG,
but the exact YANG data model is not known at design time. In these but the specific YANG data model is not known at design time. In
situations, it is RECOMMENDED to use anydata (Section 7.10) instead these situations, it is RECOMMENDED to use anydata (Section 7.10)
of anyxml. instead of anyxml.
7.11.1. The anyxml's Substatements 7.11.1. The anyxml's Substatements
+--------------+---------+-------------+ +--------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+--------------+---------+-------------+ +--------------+---------+-------------+
| config | 7.21.1 | 0..1 | | config | 7.21.1 | 0..1 |
| description | 7.21.3 | 0..1 | | description | 7.21.3 | 0..1 |
| if-feature | 7.20.2 | 0..n | | if-feature | 7.20.2 | 0..n |
| mandatory | 7.6.5 | 0..1 | | mandatory | 7.6.5 | 0..1 |
skipping to change at page 103, line 29 skipping to change at page 104, line 41
If a leaf-list in the input tree has one or more default values, the If a leaf-list in the input tree has one or more default values, the
server MUST use these values in the same cases as described in server MUST use these values in the same cases as described in
Section 7.7.2. In these cases, the server MUST operationally behave Section 7.7.2. In these cases, the server MUST operationally behave
as if the leaf-list was present in the RPC invocation with the as if the leaf-list was present in the RPC invocation with the
default values as its values. default values as its values.
Since the input tree is not part of any datastore, all "config" Since the input tree is not part of any datastore, all "config"
statements for nodes in the input tree are ignored. statements for nodes in the input tree are ignored.
If any node has a "when" statement that would evaluate to false, then If any node has a "when" statement that would evaluate to "false",
this node MUST NOT be present in the input tree. then this node MUST NOT be present in the input tree.
7.14.2.1. The input's Substatements 7.14.2.1. The input's Substatements
+--------------+---------+-------------+ +--------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+--------------+---------+-------------+ +--------------+---------+-------------+
| anydata | 7.10 | 0..n | | anydata | 7.10 | 0..n |
| anyxml | 7.11 | 0..n | | anyxml | 7.11 | 0..n |
| choice | 7.9 | 0..n | | choice | 7.9 | 0..n |
| container | 7.5 | 0..n | | container | 7.5 | 0..n |
| grouping | 7.12 | 0..n | | grouping | 7.12 | 0..n |
| leaf | 7.6 | 0..n | | leaf | 7.6 | 0..n |
| leaf-list | 7.7 | 0..n | | leaf-list | 7.7 | 0..n |
skipping to change at page 104, line 29 skipping to change at page 105, line 44
If a leaf-list in the output tree has one or more default values, the If a leaf-list in the output tree has one or more default values, the
client MUST use these values in the same cases as described in client MUST use these values in the same cases as described in
Section 7.7.2. In these cases, the client MUST operationally behave Section 7.7.2. In these cases, the client MUST operationally behave
as if the leaf-list was present in the RPC reply with the default as if the leaf-list was present in the RPC reply with the default
values as its values. values as its values.
Since the output tree is not part of any datastore, all "config" Since the output tree is not part of any datastore, all "config"
statements for nodes in the output tree are ignored. statements for nodes in the output tree are ignored.
If any node has a "when" statement that would evaluate to false, then If any node has a "when" statement that would evaluate to "false",
this node MUST NOT be present in the output tree. then this node MUST NOT be present in the output tree.
7.14.3.1. The output's Substatements 7.14.3.1. The output's Substatements
+--------------+---------+-------------+ +--------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+--------------+---------+-------------+ +--------------+---------+-------------+
| anydata | 7.10 | 0..n | | anydata | 7.10 | 0..n |
| anyxml | 7.11 | 0..n | | anyxml | 7.11 | 0..n |
| choice | 7.9 | 0..n | | choice | 7.9 | 0..n |
| container | 7.5 | 0..n | | container | 7.5 | 0..n |
| grouping | 7.12 | 0..n | | grouping | 7.12 | 0..n |
| leaf | 7.6 | 0..n | | leaf | 7.6 | 0..n |
| leaf-list | 7.7 | 0..n | | leaf-list | 7.7 | 0..n |
skipping to change at page 107, line 32 skipping to change at page 108, line 45
When an action is invoked, an element with the local name "action" in When an action is invoked, an element with the local name "action" in
the namespace "urn:ietf:params:xml:ns:yang:1" (see Section 5.3.1) is the namespace "urn:ietf:params:xml:ns:yang:1" (see Section 5.3.1) is
encoded as a child XML element to the <rpc> element defined in encoded as a child XML element to the <rpc> element defined in
[RFC6241], as designated by the substitution group "rpcOperation" in [RFC6241], as designated by the substitution group "rpcOperation" in
[RFC6241]. [RFC6241].
The "action" element contains an hierarchy of nodes that identifies The "action" element contains an hierarchy of nodes that identifies
the node in the datastore. It MUST contain all containers and list the node in the datastore. It MUST contain all containers and list
nodes in the direct path from the top level down to the list or nodes in the direct path from the top level down to the list or
container containing the action. For lists, all key leafs MUST also container containing the action. For lists, all key leafs MUST also
be included. The last container or list contains an XML element that be included. The innermost container or list contains an XML element
carries the name of the defined action. Within this element the that carries the name of the defined action. Within this element the
input parameters are encoded as child XML elements, in the same order input parameters are encoded as child XML elements, in the same order
as they are defined within the "input" statement. as they are defined within the "input" statement.
Only one action can be invoked in one <rpc>. If more than one action Only one action can be invoked in one <rpc>. If more than one action
is present in the <rpc>, the server MUST reply with an "bad-element" is present in the <rpc>, the server MUST reply with an "bad-element"
error-tag in the <rpc-error>. error-tag in the <rpc-error>.
If the action operation invocation succeeded, and no output If the action operation invocation succeeded, and no output
parameters are returned, the <rpc-reply> contains a single <ok/> parameters are returned, the <rpc-reply> contains a single <ok/>
element defined in [RFC6241]. If output parameters are returned, element defined in [RFC6241]. If output parameters are returned,
skipping to change at page 111, line 7 skipping to change at page 112, line 7
in NETCONF Event Notifications [RFC5277]. The element's local name in NETCONF Event Notifications [RFC5277]. The element's local name
is the notification's identifier, and its namespace is the module's is the notification's identifier, and its namespace is the module's
XML namespace (see Section 7.1.3). XML namespace (see Section 7.1.3).
When a notification node is defined as a child to a data node, the When a notification node is defined as a child to a data node, the
<notification> element defined in NETCONF Event Notifications <notification> element defined in NETCONF Event Notifications
[RFC5277] contains an hierarchy of nodes that identifies the node in [RFC5277] contains an hierarchy of nodes that identifies the node in
the datastore. It MUST contain all containers and list nodes from the datastore. It MUST contain all containers and list nodes from
the top level down to the list or container containing the the top level down to the list or container containing the
notification. For lists, all key leafs MUST also be included. The notification. For lists, all key leafs MUST also be included. The
last container or list contains an XML element that carries the name innermost container or list contains an XML element that carries the
of the defined notification. name 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 example-event { module example-event {
skipping to change at page 112, line 42 skipping to change at page 113, line 42
<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
The "augment" statement allows a module or submodule to add to the The "augment" statement allows a module or submodule to add to a
schema tree defined in an external module, or the current module and schema tree defined in an external module, or in the current module
its submodules, and to add to the nodes from a grouping in a "uses" and its submodules, and to add to the nodes from a grouping in a
statement. The argument is a string that identifies a node in the "uses" statement. The argument is a string that identifies a node in
schema tree. This node is called the augment's target node. The the schema tree. This node is called the augment's target node. The
target node MUST be either a container, list, choice, case, input, target node MUST be either a container, list, choice, case, input,
output, or notification node. It is augmented with the nodes defined output, or notification node. It is augmented with the nodes defined
in the substatements that follow the "augment" statement. in the substatements that follow the "augment" statement.
The argument string is a schema node identifier (see Section 6.5). The argument string is a schema node identifier (see Section 6.5).
If the "augment" statement is on the top level in a module or If the "augment" statement is on the top level in a module or
submodule, the absolute form (defined by the rule submodule, the absolute form (defined by the rule
"absolute-schema-nodeid" in Section 14) of a schema node identifier "absolute-schema-nodeid" in Section 14) of a schema node identifier
MUST be used. If the "augment" statement is a substatement to the MUST be used. If the "augment" statement is a substatement to the
"uses" statement, the descendant form (defined by the rule "uses" statement, the descendant form (defined by the rule
skipping to change at page 113, line 25 skipping to change at page 114, 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 configuration nodes (see If the augmentation adds mandatory nodes (see Section 3) that
Section 3) to a target node in another module, the augmentation MUST represent configuration to a target node in another module, the
be conditional with a "when" statement. Care must be taken when augmentation MUST be conditional with a "when" statement. Care must
defining the "when" expression, so that clients that do not know be taken when defining the "when" expression, so that clients that do
about the augmenting module do not break. not know 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 {
yang-version 1.1; yang-version 1.1;
namespace "urn:example:augment"; namespace "urn:example:augment";
skipping to change at page 117, line 8 skipping to change at page 118, line 8
<ex:system> <ex:system>
<ex:protocol> <ex:protocol>
<other:smtp/> <other:smtp/>
</ex:protocol> </ex:protocol>
</ex:system> </ex:system>
7.18. The identity Statement 7.18. The identity Statement
The "identity" statement is used to define a new globally unique, The "identity" statement is used to define a new globally unique,
abstract, and untyped identity. Its only purpose is to denote its abstract, and untyped identity. The identity's only purpose is to
name, semantics, and existence. An identity can either be defined denote its name, semantics, and existence. An identity can either be
from scratch or derived from one or more base identities. The defined from scratch or derived from one or more base identities.
identity's argument is an identifier that is the name of the The identity's argument is an identifier that is the name of the
identity. It is followed by a block of substatements that holds identity. It is followed by a block of substatements that holds
detailed identity information. detailed identity information.
The built-in datatype "identityref" (see Section 9.10) can be used to The built-in datatype "identityref" (see Section 9.10) can be used to
reference identities within a data model. reference identities within a data model.
7.18.1. The identity's Substatements 7.18.1. The identity's Substatements
+--------------+---------+-------------+ +--------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
skipping to change at page 120, line 11 skipping to change at page 121, line 11
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 "extension" statement's argument is an identifier that is the new
the extension and must be followed by a block of substatements that keyword for the extension and must be followed by a block of
holds detailed extension information. The purpose of the "extension" substatements that holds detailed extension information. The purpose
statement is to define a keyword, so that it can be imported and used of the "extension" statement is to define a keyword, so that it can
by other modules. be imported and used by other modules.
The extension can be used like a normal YANG statement, with the The extension can be used like a normal YANG statement, with the
statement name followed by an argument if one is defined by the statement name followed by an argument if one is defined by the
"extension" statement, and an optional block of substatements. The "extension" statement, and an optional block of substatements. The
statement's name is created by combining the prefix of the module in statement's name is created by combining the prefix of the module in
which the extension was defined, a colon (":"), and the extension's which the extension was defined, a colon (":"), and the extension's
keyword, with no interleaving whitespace. The substatements of an keyword, with no interleaving whitespace. The substatements of an
extension are defined by the "extension" statement, using some extension are defined by the "extension" statement, using some
mechanism outside the scope of this specification. Syntactically, mechanism outside the scope of this specification. Syntactically,
the substatements MUST be YANG statements, or also extensions defined the substatements MUST be YANG statements, or also extensions defined
skipping to change at page 124, line 30 skipping to change at page 125, line 30
If a prefix is present on a feature name in the boolean expression, If a prefix is present on a feature name in the boolean expression,
the prefixed name refers to a feature defined in the module that was the prefixed name refers to a feature 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. Otherwise, a feature with the matching the local module's prefix. Otherwise, a feature with the matching
name MUST be defined in the current module or an included submodule. name MUST be defined in the current module or an included submodule.
A leaf that is a list key MUST NOT have any "if-feature" statements. A leaf that is a list key MUST NOT have any "if-feature" statements.
7.20.2.1. Usage Example 7.20.2.1. Usage Example
In this example, the container "target" is implemented if any of the In this example, the container "target" is implemented if either of
features "outbound-tls" or "outbound-ssh" are supported by the the features "outbound-tls" or "outbound-ssh" are supported by the
server. server.
container target { container target {
if-feature "outbound-tls or outbound-ssh"; if-feature "outbound-tls or outbound-ssh";
... ...
} }
The following examples are equivalent: The following examples are equivalent:
if-feature "not foo or bar and baz"; if-feature "not foo or bar and baz";
skipping to change at page 125, line 30 skipping to change at page 126, line 30
or software ability to support parts of a standard module. When this or software ability to support parts of a standard module. When this
occurs, the server makes a choice either to treat attempts to occurs, the server makes a choice either to treat attempts to
configure unsupported parts of the module as an error that is configure unsupported parts of the module as an error that is
reported back to the unsuspecting application or ignore those reported back to the unsuspecting application or ignore those
incoming requests. Neither choice is acceptable. incoming requests. Neither choice is acceptable.
Instead, YANG allows servers to document portions of a base module Instead, YANG allows servers to document portions of a base module
that are not supported or supported but with different syntax, by that are not supported or supported but with different syntax, by
using the "deviation" statement. using the "deviation" statement.
After applying all deviations announced by a server, in any order,
the resulting data model MUST still be valid.
7.20.3.1. The deviation's Substatements 7.20.3.1. The deviation's Substatements
+--------------+----------+-------------+ +--------------+----------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+--------------+----------+-------------+ +--------------+----------+-------------+
| description | 7.21.3 | 0..1 | | description | 7.21.3 | 0..1 |
| deviate | 7.20.3.2 | 1..n | | deviate | 7.20.3.2 | 1..n |
| reference | 7.21.4 | 0..1 | | reference | 7.21.4 | 0..1 |
+--------------+----------+-------------+ +--------------+----------+-------------+
skipping to change at page 129, line 34 skipping to change at page 130, line 34
The "description" statement takes as an argument a string that The "description" statement takes as an argument a string that
contains a human-readable textual description of this definition. contains a human-readable textual description of this definition.
The text is provided in a language (or languages) chosen by the The text is provided in a language (or languages) chosen by the
module developer; for the sake of interoperability, it is RECOMMENDED module developer; for the sake of interoperability, it is RECOMMENDED
to choose a language that is widely understood among the community of to choose a language that is widely understood among the community of
network administrators who will use the module. network administrators who will use the module.
7.21.4. The reference Statement 7.21.4. The reference Statement
The "reference" statement takes as an argument a string that is used The "reference" statement takes as an argument a string that is a
to specify a textual cross-reference to an external document, either human-readable cross-reference to an external document, either
another module that defines related management information, or a another module that defines related management information, or a
document that provides additional information relevant to this document that provides additional information relevant to this
definition. definition.
For example, a typedef for a "uri" data type could look like: For example, a typedef for a "uri" data type could look like:
typedef uri { typedef uri {
type string; type string;
reference reference
"RFC 3986: Uniform Resource Identifier (URI): Generic Syntax"; "RFC 3986: Uniform Resource Identifier (URI): Generic Syntax";
skipping to change at page 131, line 6 skipping to change at page 132, line 6
processing of the XPath expression by replacing all instances of processing of the XPath expression by replacing all instances of
the data node for which the "when" statement is defined with a the data node for which the "when" statement is defined with a
single dummy node with the same name, but with no value and no single dummy node with the same name, but with no value and no
children. If no such instance exists, the dummy node is children. If no such instance exists, the dummy node is
tentatively created. The context node is this dummy node. tentatively created. The context node is this dummy node.
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.
If the XPath expression references any node that also has associated If the XPath expression references any node that also has associated
"when" statements, these "when" expressions MUST be evaluated first. "when" statements, those "when" expressions MUST be evaluated first.
There MUST NOT be any circular dependencies in these "when" There MUST NOT be any circular dependencies among "when" expressions.
expressions.
Note that the XPath expression is conceptually evaluated. This means Note that the XPath expression is conceptually evaluated. This means
that an implementation does not have to use an XPath evaluator in the that an implementation does not have to use an XPath evaluator in the
server. The "when" statement can very well be implemented with server. The "when" statement can very well be implemented with
specially written code. specially written code.
8. Constraints 8. Constraints
8.1. Constraints on Data 8.1. Constraints on Data
skipping to change at page 143, line 41 skipping to change at page 144, line 41
The lexical representation of an enumeration value is the assigned The lexical representation of an enumeration value is the assigned
name string. name string.
9.6.2. Canonical Form 9.6.2. Canonical Form
The canonical form is the assigned name string. The canonical form is the assigned name string.
9.6.3. Restrictions 9.6.3. Restrictions
An enumeration can be restricted with the "enum" (Section 9.6.4) An enumeration can be restricted with one or more "enum"
statement. (Section 9.6.4) statements, which enumerate a subset of the values
for the base type.
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 zero-length and MUST NOT have any leading or string MUST NOT be zero-length and MUST NOT have any leading or
trailing whitespace characters (any Unicode character with the trailing whitespace characters (any Unicode character with the
"White_Space" property). The use of Unicode control codes SHOULD be "White_Space" property). The use of Unicode control codes SHOULD be
skipping to change at page 146, line 46 skipping to change at page 147, 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. A zero-length string thus of the names of the bits 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 33 skipping to change at page 150, line 33
statement. The length of a binary value is the number of octets it statement. The length of a binary value is the number of octets it
contains. contains.
9.8.2. Lexical Representation 9.8.2. Lexical Representation
Binary values are encoded with the base64 encoding scheme (see Binary values are encoded with the base64 encoding scheme (see
[RFC4648], Section 4). [RFC4648], Section 4).
9.8.3. Canonical Form 9.8.3. Canonical Form
The canonical form of a binary value follows the rules in [RFC4648]. The canonical form of a binary value follows the rules of "Base 64
Encoding" in [RFC4648].
9.9. The leafref Built-In Type 9.9. The leafref Built-In Type
The leafref type is used to declare a constraint on the value space The leafref type is restricted to the value space of some leaf or
of a leaf, based on a reference to a set of leaf instances in the leaf-list node in the schema tree and optionally further restricted
data tree. The "path" substatement (Section 9.9.2) selects a set of by corresponding instance nodes in the data tree. The "path"
leaf instances, and the leafref value space is the set of values of substatement (Section 9.9.2) is used to identify the referred leaf or
these leaf instances. leaf-list node in the schema tree. The value space of the referring
node is the value space of the referred node.
If the leaf with the leafref type represents configuration data, and If the "require-instance" property (Section 9.9.3) is "true", there
the "require-instance" property (Section 9.9.3) is "true", the leaf MUST exist an node in the data tree, or a node with a default value
it refers to MUST also represent configuration. Such a leaf puts a in use (see Section 7.6.1 and Section 7.7.2), of the referred schema
constraint on valid data. All such nodes MUST reference existing tree leaf or leaf-list node with the same value as the leafref value
leaf instances or leafs with default values in use (see Section 7.6.1 in a valid data tree.
and Section 7.7.2) for the data to be valid. This constraint is
enforced according to the rules in Section 8. If the referring node represents configuration data, and the
"require-instance" property (Section 9.9.3) is "true", the referred
node MUST also represent configuration.
There MUST NOT be any circular chains of leafrefs. There MUST NOT be any circular chains of leafrefs.
If the leaf that the leafref refers to is conditional based on one or If the leaf that the leafref refers to is conditional based on one or
more features (see Section 7.20.2), then the leaf with the leafref more features (see Section 7.20.2), then the leaf with the leafref
type MUST also be conditional based on at least the same set of type MUST also be conditional based on at least the same set of
features. features.
9.9.1. Restrictions 9.9.1. Restrictions
skipping to change at page 151, line 8 skipping to change at page 152, line 13
the "path" statement is defined. the "path" statement is defined.
9.9.3. The require-instance Statement 9.9.3. The require-instance Statement
The "require-instance" statement, which is a substatement to the The "require-instance" statement, which is a substatement to the
"type" statement, MAY be present if the type is "instance-identifier" "type" statement, MAY be present if the type is "instance-identifier"
or "leafref". It takes as an argument the string "true" or "false". or "leafref". It takes as an argument the string "true" or "false".
If this statement is not present, it defaults to "true". If this statement is not present, it defaults to "true".
If "require-instance" is "true", it means that the instance being If "require-instance" is "true", it means that the instance being
referred MUST exist for the data to be valid. This constraint is referred to MUST exist for the data to be valid. This constraint is
enforced according to the rules in Section 8. enforced according to the rules in Section 8.
If "require-instance" is "false", it means that the instance being If "require-instance" is "false", it means that the instance being
referred MAY exist in valid data. referred to MAY exist in valid data.
9.9.4. Lexical Representation 9.9.4. Lexical Representation
A leafref value is lexically represented the same way as the leaf it A leafref value is lexically represented the same way as the leaf it
references. references represents its value.
9.9.5. Canonical Form 9.9.5. Canonical Form
The canonical form of a leafref is the same as the canonical form of The canonical form of a leafref is the same as the canonical form of
the leaf it references. the leaf it references.
9.9.6. Usage Example 9.9.6. Usage Example
With the following list: With the following list:
skipping to change at page 158, line 11 skipping to change at page 159, line 11
<enable-qos/> <enable-qos/>
if the leaf exists. if the leaf exists.
9.12. The union Built-In Type 9.12. The union Built-In Type
The union built-in type represents a value that corresponds to one of The union built-in type represents a value that corresponds to one of
its member types. its member types.
When the type is "union", the "type" statement (Section 7.4) MUST be When the type is "union", the "type" statement (Section 7.4) MUST be
present. It is used to repeatedly specify each member type of the present. It is repeatedly used to specify each member type of the
union. It takes as an argument a string that is the name of a member union. It takes as an argument a string that is the name of a member
type. type.
A member type can be of any built-in or derived type. A member type can be of any built-in or derived type.
In the XML encoding, a value representing a union data type is When generating an XML encoding, a value is encoded according to the
validated consecutively against each member type, in the order they rules of the member type to which the value belongs. When
are specified in the "type" statement, until a match is found. The interpreting an XML encoding, a value is validated consecutively
type that matched will be the type of the value for the node that was against each member type, in the order they are specified in the
validated. "type" statement, until a match is found. The type that matched will
be the type of the value for the node that was validated, and the
encoding is interpreted according to the rules for that type.
Any default value or "units" property defined in the member types is Any default value or "units" property defined in the member types is
not inherited by the union type. not inherited by the union type.
9.12.1. Restrictions 9.12.1. Restrictions
A union cannot be restricted. However, each member type can be A union cannot be restricted. However, each member type can be
restricted, based on the rules defined in Section 9. restricted, based on the rules defined in Section 9.
9.12.2. Lexical Representation 9.12.2. Lexical Representation
skipping to change at page 158, line 43 skipping to change at page 159, line 45
The lexical representation of a union is a value that corresponds to The lexical representation of a union is a value that corresponds to
the representation of any one of the member types. the representation of any one of the member types.
9.12.3. Canonical Form 9.12.3. Canonical Form
The canonical form of a union value is the same as the canonical form The canonical form of a union value is the same as the canonical form
of the member type of the value. of the member type of the value.
9.12.4. Usage Example 9.12.4. Usage Example
The following is a union of an int32 an enumeration: The following is a union of an int32 and an enumeration:
type union { type union {
type int32; type int32;
type enumeration { type enumeration {
enum "unbounded"; enum "unbounded";
} }
} }
Care must be taken when a member type is a leafref where the Care must be taken when a member type is a leafref where the
"require-instance" property (Section 9.9.3) is "true". If a leaf of "require-instance" property (Section 9.9.3) is "true". If a leaf of
skipping to change at page 162, line 34 skipping to change at page 163, line 34
} }
must '/interface[name=current()]/enabled = "true"'; must '/interface[name=current()]/enabled = "true"';
} }
10.2. Functions for Strings 10.2. Functions for Strings
10.2.1. re-match() 10.2.1. re-match()
boolean re-match(string subject, string pattern) boolean re-match(string subject, string pattern)
The re-match() function returns true if the "subject" string matches The re-match() function returns "true" if the "subject" string
the regular expression "pattern"; otherwise it returns false. matches the regular expression "pattern"; otherwise it returns
"false".
The function "re-match" checks if a string matches a given regular The function "re-match" checks if a string matches a given regular
expression. The regular expressions used are the XML Schema regular expression. The regular expressions used are the XML Schema regular
expressions [XSD-TYPES]. Note that this includes implicit anchoring expressions [XSD-TYPES]. Note that this includes implicit anchoring
of the regular expression at the head and tail. of the regular expression at the head and tail.
10.2.1.1. Usage Example 10.2.1.1. Usage Example
The expression: The expression:
re-match("1.22.333", "\d{1,3}\.\d{1,3}\.\d{1,3}") re-match("1.22.333", "\d{1,3}\.\d{1,3}\.\d{1,3}")
returns true. returns "true".
To count all logical interfaces called eth0.<number>, do: To count all logical interfaces called eth0.<number>, do:
count(/interface[re-match(name, "eth0\.\d+")]) count(/interface[re-match(name, "eth0\.\d+")])
10.3. Functions for the YANG Types "leafref" and "instance-identifier" 10.3. Functions for the YANG Types "leafref" and "instance-identifier"
10.3.1. deref() 10.3.1. deref()
node-set deref(node-set nodes) node-set deref(node-set nodes)
skipping to change at page 163, line 22 skipping to change at page 164, line 24
in document order in the argument "nodes", and returns the nodes it in document order in the argument "nodes", and returns the nodes it
refers to. refers to.
If the first argument node is of type instance-identifier, the If the first argument node is of type instance-identifier, the
function returns a node set that contains the single node that the function returns a node set that contains the single node that the
instance identifier refers to, if it exists. If no such node exists, instance identifier refers to, if it exists. If no such node exists,
an empty node-set is returned. an empty node-set is returned.
If the first argument node is of type leafref, the function returns a If the first argument node is of type leafref, the function returns a
node set that contains the nodes that the leafref refers to. node set that contains the nodes that the leafref refers to.
Specifically, this set contains the nodes selected by the leafref's
"path" statement (Section 9.9.2) that have the same value as the
first argument node.
If the first argument node is of any other type, an empty node set is If the first argument node is of any other type, an empty node set is
returned. returned.
10.3.1.1. Usage Example 10.3.1.1. Usage Example
list interface { list interface {
key "name type"; key "name type";
leaf name { ... } leaf name { ... }
leaf type { ... } leaf type { ... }
leaf enabled { leaf enabled {
skipping to change at page 164, line 37 skipping to change at page 165, line 37
} }
} }
} }
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()
boolean derived-from(node-set nodes, string identity) boolean derived-from(node-set nodes, string identity)
The derived-from() function returns true if any node in the argument The derived-from() function returns "true" if any node in the
"nodes" is a node of type identityref, and its value is an identity argument "nodes" is a node of type identityref, and its value is an
that is derived from (see Section 7.18.2) the identity "identity"; identity that is derived from (see Section 7.18.2) the identity
otherwise it returns false. "identity"; otherwise it returns "false".
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.1.1. Usage Example 10.4.1.1. Usage Example
skipping to change at page 165, line 47 skipping to change at page 166, line 47
when 'derived-from(type, "exif:ethernet")'; when 'derived-from(type, "exif:ethernet")';
// generic ethernet definitions here // generic ethernet definitions here
} }
... ...
} }
10.4.2. derived-from-or-self() 10.4.2. derived-from-or-self()
boolean derived-from-or-self(node-set nodes, string identity) boolean derived-from-or-self(node-set nodes, string identity)
The derived-from-or-self() function returns true if any node in the The derived-from-or-self() function returns "true" if any node in the
argument "nodes" is a node of type identityref, and its value is an argument "nodes" is a node of type identityref, and its value is an
identity that is equal to or derived from (see Section 7.18.2) the identity that is equal to or derived from (see Section 7.18.2) the
identity "identity"; otherwise it returns false. identity "identity"; otherwise it returns "false".
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
skipping to change at page 167, line 42 skipping to change at page 168, line 42
severity "major" or higher: severity "major" or higher:
/alarm[enum-value(severity) >= 5] /alarm[enum-value(severity) >= 5]
10.6. Functions for the YANG Type "bits" 10.6. Functions for the YANG Type "bits"
10.6.1. bit-is-set() 10.6.1. bit-is-set()
boolean bit-is-set(node-set nodes, string bit-name) boolean bit-is-set(node-set nodes, string bit-name)
The bit-is-set() function returns true if the first node in document The bit-is-set() function returns "true" if the first node in
order in the argument "nodes" is a node of type bits, and its value document order in the argument "nodes" is a node of type bits, and
has the bit "'bit-name" set; otherwise it returns false. its value has the bit "'bit-name" set; otherwise it returns "false".
10.6.1.1. Usage Example 10.6.1.1. Usage Example
If an interface has this leaf: If an interface has this leaf:
leaf flags { leaf flags {
type bits { type bits {
bit UP; bit UP;
bit PROMISCUOUS bit PROMISCUOUS
bit DISABLED; bit DISABLED;
skipping to change at page 169, line 34 skipping to change at page 170, line 34
o A "mandatory" statement may be removed or changed from "true" to o A "mandatory" statement may be removed or changed from "true" to
"false". "false".
o A "min-elements" statement may be removed, or changed to require o A "min-elements" statement may be removed, or changed to require
fewer elements. fewer elements.
o A "max-elements" statement may be removed, or changed to allow o A "max-elements" statement may be removed, or changed to allow
more elements. more elements.
o A "description" statement may be added or clarified without o A "description" statement may be added or changed without changing
changing the semantics of the definition. the semantics of the definition.
o A "base" statement may be added to an "identity" statement. o A "base" statement may be added to an "identity" statement.
o A "base" statement may be removed from an "identityref" type, o A "base" statement may be removed from an "identityref" type,
provided there is at least one "base" statement left. provided there is at least one "base" statement left.
o New typedefs, groupings, rpcs, notifications, extensions, o New typedefs, groupings, rpcs, notifications, extensions,
features, and identities may be added. features, and identities may be added.
o New data definition statements may be added if they do not add o New data definition statements may be added if they do not add
skipping to change at page 171, line 23 skipping to change at page 172, line 23
This rule exists in order to allow implementations of existing YANG This rule exists in order to allow implementations of existing YANG
version 1 modules together with YANG version 1.1 modules. Without version 1 modules together with YANG version 1.1 modules. Without
this rule, updating a single module to YANG version 1.1 would have a this rule, updating a single module to YANG version 1.1 would have a
cascading effect on modules that import it, requiring all of them to cascading effect on modules that import it, requiring all of them to
also be updated to YANG version 1.1, and so on. also be updated to YANG version 1.1, and so on.
13. YIN 13. YIN
A YANG module can be translated into an alternative XML-based syntax A YANG module can be translated into an alternative XML-based syntax
called YIN. The translated module is called a YIN module. This called YIN. The translated module is called a YIN module. This
section describes symmetric mapping rules between the two formats. section describes bidirectional mapping rules between the two
formats.
The YANG and YIN formats contain equivalent information using The YANG and YIN formats contain equivalent information using
different notations. The YIN notation enables developers to different notations. The YIN notation enables developers to
represent YANG data models in XML and therefore use the rich set of represent YANG data models in XML and therefore use the rich set of
XML-based tools for data filtering and validation, automated XML-based tools for data filtering and validation, automated
generation of code and documentation, and other tasks. Tools like generation of code and documentation, and other tasks. Tools like
XSLT or XML validators can be utilized. XSLT or XML validators can be utilized.
The mapping between YANG and YIN does not modify the information The mapping between YANG and YIN does not modify the information
content of the model. Comments and whitespace are not preserved. content of the model. Comments and whitespace are not preserved.
skipping to change at page 179, line 30 skipping to change at page 180, line 30
[description-stmt] [description-stmt]
[reference-stmt] [reference-stmt]
"}") stmtsep "}") stmtsep
if-feature-stmt = if-feature-keyword sep if-feature-expr-str if-feature-stmt = if-feature-keyword sep if-feature-expr-str
stmtend stmtend
if-feature-expr-str = < a string that matches the rule > if-feature-expr-str = < a string that matches the rule >
< if-feature-expr > < if-feature-expr >
if-feature-expr = "(" if-feature-expr ")" / if-feature-expr = if-feature-term
if-feature-expr sep boolean-operator sep [sep or-keyword sep if-feature-expr]
if-feature-expr /
not-keyword sep if-feature-expr / if-feature-term = if-feature-factor
[sep and-keyword sep if-feature-term]
if-feature-factor = not-keyword sep if-feature-factor /
"(" sep if-feature-expr sep ")" /
identifier-ref-arg identifier-ref-arg
boolean-operator = and-keyword / or-keyword boolean-operator = and-keyword / or-keyword
typedef-stmt = typedef-keyword sep identifier-arg-str optsep typedef-stmt = typedef-keyword sep identifier-arg-str optsep
"{" stmtsep "{" stmtsep
;; these stmts can appear in any order ;; these stmts can appear in any order
type-stmt type-stmt
[units-stmt] [units-stmt]
[default-stmt] [default-stmt]
skipping to change at page 180, line 19 skipping to change at page 181, line 22
decimal64-specification / decimal64-specification /
string-restrictions / string-restrictions /
enum-specification / enum-specification /
leafref-specification / leafref-specification /
identityref-specification / identityref-specification /
instance-identifier-specification / instance-identifier-specification /
bits-specification / bits-specification /
union-specification / union-specification /
binary-specification binary-specification
numerical-restrictions = range-stmt numerical-restrictions = [range-stmt]
range-stmt = range-keyword sep range-arg-str optsep range-stmt = range-keyword sep range-arg-str optsep
(";" / (";" /
"{" stmtsep "{" stmtsep
;; these stmts can appear in any order ;; these stmts can appear in any order
[error-message-stmt] [error-message-stmt]
[error-app-tag-stmt] [error-app-tag-stmt]
[description-stmt] [description-stmt]
[reference-stmt] [reference-stmt]
"}") stmtsep "}") stmtsep
skipping to change at page 199, line 47 skipping to change at page 201, line 8
15. NETCONF Error Responses for YANG Related Errors 15. NETCONF Error Responses for YANG Related Errors
A number of NETCONF error responses are defined for error cases A number of NETCONF error responses are defined for error cases
related to the data-model handling. If the relevant YANG statement related to the data-model handling. If the relevant YANG statement
has an "error-app-tag" substatement, that overrides the default value has an "error-app-tag" substatement, that overrides the default value
specified below. specified below.
15.1. Error Message for Data That Violates a unique Statement 15.1. Error Message for Data That Violates a unique Statement
If a NETCONF operation would result in configuration data where a If a NETCONF operation would result in configuration data where a
unique constraint is invalidated, the following error is returned: unique constraint is invalidated, the following error MUST be
returned:
error-tag: operation-failed error-tag: operation-failed
error-app-tag: data-not-unique error-app-tag: data-not-unique
error-info: <non-unique>: Contains an instance identifier that error-info: <non-unique>: Contains an instance identifier that
points to a leaf that invalidates the unique points to a leaf that invalidates the unique
constraint. This element is present once for each constraint. This element is present once for each
non-unique leaf. non-unique leaf.
The <non-unique> element is in the YANG The <non-unique> element is in the YANG
namespace ("urn:ietf:params:xml:ns:yang:1"). namespace ("urn:ietf:params:xml:ns:yang:1").
15.2. Error Message for Data That Violates a max-elements Statement 15.2. Error Message for Data That Violates a max-elements Statement
If a NETCONF operation would result in configuration data where a If a NETCONF operation would result in configuration data where a
list or a leaf-list would have too many entries the following error list or a leaf-list would have too many entries the following error
is returned: MUST be returned:
error-tag: operation-failed error-tag: operation-failed
error-app-tag: too-many-elements error-app-tag: too-many-elements
This error is returned once, with the error-path identifying the list This error is returned once, with the error-path identifying the list
node, even if there are more than one extra child present. node, even if there are more than one extra child present.
15.3. Error Message for Data That Violates a min-elements Statement 15.3. Error Message for Data That Violates a min-elements Statement
If a NETCONF operation would result in configuration data where a If a NETCONF operation would result in configuration data where a
list or a leaf-list would have too few entries the following error is list or a leaf-list would have too few entries the following error
returned: MUST be returned:
error-tag: operation-failed error-tag: operation-failed
error-app-tag: too-few-elements error-app-tag: too-few-elements
This error is returned once, with the error-path identifying the list This error is returned once, with the error-path identifying the list
node, even if there are more than one child missing. node, even if there are more than one child missing.
15.4. Error Message for Data That Violates a must Statement 15.4. Error Message for Data That Violates a must Statement
If a NETCONF operation would result in configuration data where the If a NETCONF operation would result in configuration data where the
restrictions imposed by a "must" statement is violated the following restrictions imposed by a "must" statement is violated the following
error is returned, unless a specific "error-app-tag" substatement is error MUST be returned, unless a specific "error-app-tag"
present for the "must" statement. substatement is present for the "must" statement.
error-tag: operation-failed error-tag: operation-failed
error-app-tag: must-violation error-app-tag: must-violation
15.5. Error Message for Data That Violates a require-instance Statement 15.5. Error Message for Data That Violates a require-instance Statement
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 MUST be 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 Violates a mandatory choice Statement 15.6. 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 MUST be
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.7. 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 MUST be
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
This document registers one capability identifier URN from the This document registers one capability identifier URN from the
"Network Configuration Protocol (NETCONF) Capability URNs" registry: "Network Configuration Protocol (NETCONF) Capability URNs" registry:
Index Capability Identifier Index Capability Identifier
skipping to change at page 202, line 49 skipping to change at page 204, line 10
- Balazs Lengyel (Ericsson) - Balazs Lengyel (Ericsson)
- David Partain (Ericsson) - David Partain (Ericsson)
- Juergen Schoenwaelder (Jacobs University Bremen) - Juergen Schoenwaelder (Jacobs University Bremen)
- Phil Shafer (Juniper Networks) - Phil Shafer (Juniper Networks)
19. Acknowledgements 19. Acknowledgements
The editor wishes to thank the following individuals, who all The editor wishes to thank the following individuals, who all
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, Lionel Morand, Gerhard Muenz, Peyman Owladi, Tom
Presuhn, David Reid, Jernej Tuljak, Kent Watsen, Bert Wijnen, and Petch, Randy Presuhn, David Reid, Jernej Tuljak, Kent Watsen, Bert
Robert Wilton. Wijnen, Robert Wilton, and Dale Worley.
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 -10 20.1. Version -10
o Made single and double quote characters illegal in unquoted o Made single and double quote characters illegal in unquoted
strings. strings.
skipping to change at page 206, line 6 skipping to change at page 207, line 17
Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module
Library", draft-ietf-netconf-yang-library-06 (work in Library", draft-ietf-netconf-yang-library-06 (work in
progress), April 2016. progress), April 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, Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
DOI 10.17487/RFC2119, March 1997, RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <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, DOI 10.17487/RFC3629, November 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <http://www.rfc-editor.org/info/rfc3629>. 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, Resource Identifier (URI): Generic Syntax", STD 66, RFC
RFC 3986, DOI 10.17487/RFC3986, January 2005, 3986, DOI 10.17487/RFC3986, January 2005,
<http://www.rfc-editor.org/info/rfc3986>. <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, DOI 10.17487/RFC4648, October 2006, Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<http://www.rfc-editor.org/info/rfc4648>. <http://www.rfc-editor.org/info/rfc4648>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/
DOI 10.17487/RFC5234, January 2008, RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>. <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, DOI 10.17487/RFC5277, July 2008, Notifications", RFC 5277, DOI 10.17487/RFC5277, July 2008,
<http://www.rfc-editor.org/info/rfc5277>. <http://www.rfc-editor.org/info/rfc5277>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<http://www.rfc-editor.org/info/rfc6241>. <http://www.rfc-editor.org/info/rfc6241>.
[RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", RFC
RFC 7405, DOI 10.17487/RFC7405, December 2014, 7405, DOI 10.17487/RFC7405, December 2014,
<http://www.rfc-editor.org/info/rfc7405>. <http://www.rfc-editor.org/info/rfc7405>.
[XML-NAMES] [XML-NAMES]
Bray, T., Hollander, D., Layman, A., Tobin, R., and H. Bray, T., Hollander, D., Layman, A., Tobin, R., and H.
Thompson, "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)
skipping to change at page 207, line 18 skipping to change at page 208, line 30
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-13 (work in Protocol", draft-ietf-netconf-restconf-13 (work in
progress), April 2016. progress), April 2016.
[I-D.ietf-netmod-rfc6087bis]
Bierman, A., "Guidelines for Authors and Reviewers of YANG
Data Model Documents", draft-ietf-netmod-rfc6087bis-06
(work in progress), March 2016.
[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-10 (work in progress), March draft-ietf-netmod-yang-json-10 (work in progress), March
2016. 2016.
[I-D.vanderstok-core-comi] [I-D.vanderstok-core-comi]
Stok, P. and A. Bierman, "CoAP Management Interface", Stok, P. and A. Bierman, "CoAP Management Interface",
draft-vanderstok-core-comi-09 (work in progress), March draft-vanderstok-core-comi-09 (work in progress), March
2016. 2016.
[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, Version 2 (SMIv2)", STD 58, RFC 2578, DOI 10.17487/
DOI 10.17487/RFC2578, April 1999, RFC2578, April 1999,
<http://www.rfc-editor.org/info/rfc2578>. <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", Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD
STD 58, RFC 2579, DOI 10.17487/RFC2579, April 1999, 58, RFC 2579, DOI 10.17487/RFC2579, April 1999,
<http://www.rfc-editor.org/info/rfc2579>. <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, Structure of Management Information", RFC 3780, DOI
DOI 10.17487/RFC3780, May 2004, 10.17487/RFC3780, May 2004,
<http://www.rfc-editor.org/info/rfc3780>. <http://www.rfc-editor.org/info/rfc3780>.
[RFC4844] Daigle, L., Ed. and Internet Architecture Board, "The RFC [RFC4844] Daigle, L., Ed. and Internet Architecture Board, "The RFC
Series and RFC Editor", RFC 4844, DOI 10.17487/RFC4844, Series and RFC Editor", RFC 4844, DOI 10.17487/RFC4844,
July 2007, <http://www.rfc-editor.org/info/rfc4844>. July 2007, <http://www.rfc-editor.org/info/rfc4844>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020, the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010, DOI 10.17487/RFC6020, October 2010,
<http://www.rfc-editor.org/info/rfc6020>. <http://www.rfc-editor.org/info/rfc6020>.
 End of changes. 191 change blocks. 
626 lines changed or deleted 764 lines changed or added

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