draft-ietf-netmod-rfc6020bis-11.txt   draft-ietf-netmod-rfc6020bis-12.txt 
Network Working Group M. Bjorklund, Ed. Network Working Group M. Bjorklund, Ed.
Internet-Draft Tail-f Systems Internet-Draft Tail-f Systems
Intended status: Standards Track February 16, 2016 Intended status: Standards Track April 28, 2016
Expires: August 19, 2016 Expires: October 30, 2016
The YANG 1.1 Data Modeling Language The YANG 1.1 Data Modeling Language
draft-ietf-netmod-rfc6020bis-11 draft-ietf-netmod-rfc6020bis-12
Abstract Abstract
YANG is a data modeling language used to model configuration data, YANG is a data modeling language used to model configuration data,
state data, remote procedure calls, and notifications for network state data, remote procedure calls, and notifications for network
management protocols like the Network Configuration Protocol management protocols. This document also specifies the YANG mappings
(NETCONF). 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 August 19, 2016. This Internet-Draft will expire on October 30, 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 20 skipping to change at page 2, line 20
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 8
1.1. Summary of Changes from RFC 6020 . . . . . . . . . . . . 8 1.1. Summary of Changes from RFC 6020 . . . . . . . . . . . . 9
2. Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2. Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 10 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 11
4. YANG Overview . . . . . . . . . . . . . . . . . . . . . . . . 13 3.1. A Note on Examples . . . . . . . . . . . . . . . . . . . 14
4.1. Functional Overview . . . . . . . . . . . . . . . . . . . 13 4. YANG Overview . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2. Language Overview . . . . . . . . . . . . . . . . . . . . 15 4.1. Functional Overview . . . . . . . . . . . . . . . . . . . 14
4.2.1. Modules and Submodules . . . . . . . . . . . . . . . 15 4.2. Language Overview . . . . . . . . . . . . . . . . . . . . 16
4.2.1. Modules and Submodules . . . . . . . . . . . . . . . 16
4.2.2. Data Modeling Basics . . . . . . . . . . . . . . . . 16 4.2.2. Data Modeling Basics . . . . . . . . . . . . . . . . 16
4.2.3. State Data . . . . . . . . . . . . . . . . . . . . . 19 4.2.3. State Data . . . . . . . . . . . . . . . . . . . . . 20
4.2.4. Built-In Types . . . . . . . . . . . . . . . . . . . 20 4.2.4. Built-In Types . . . . . . . . . . . . . . . . . . . 21
4.2.5. Derived Types (typedef) . . . . . . . . . . . . . . . 21 4.2.5. Derived Types (typedef) . . . . . . . . . . . . . . . 22
4.2.6. Reusable Node Groups (grouping) . . . . . . . . . . . 22 4.2.6. Reusable Node Groups (grouping) . . . . . . . . . . . 23
4.2.7. Choices . . . . . . . . . . . . . . . . . . . . . . . 23 4.2.7. Choices . . . . . . . . . . . . . . . . . . . . . . . 24
4.2.8. Extending Data Models (augment) . . . . . . . . . . . 24 4.2.8. Extending Data Models (augment) . . . . . . . . . . . 25
4.2.9. Operation Definitions . . . . . . . . . . . . . . . . 25 4.2.9. Operation Definitions . . . . . . . . . . . . . . . . 26
4.2.10. Notification Definitions . . . . . . . . . . . . . . 28 4.2.10. Notification Definitions . . . . . . . . . . . . . . 29
5. Language Concepts . . . . . . . . . . . . . . . . . . . . . . 28 5. Language Concepts . . . . . . . . . . . . . . . . . . . . . . 29
5.1. Modules and Submodules . . . . . . . . . . . . . . . . . 28 5.1. Modules and Submodules . . . . . . . . . . . . . . . . . 29
5.1.1. Import and Include by Revision . . . . . . . . . . . 29 5.1.1. Import and Include by Revision . . . . . . . . . . . 31
5.1.2. Module Hierarchies . . . . . . . . . . . . . . . . . 31 5.1.2. Module Hierarchies . . . . . . . . . . . . . . . . . 32
5.2. File Layout . . . . . . . . . . . . . . . . . . . . . . . 32 5.2. File Layout . . . . . . . . . . . . . . . . . . . . . . . 33
5.3. XML Namespaces . . . . . . . . . . . . . . . . . . . . . 32 5.3. XML Namespaces . . . . . . . . . . . . . . . . . . . . . 33
5.3.1. YANG XML Namespace . . . . . . . . . . . . . . . . . 32 5.3.1. YANG XML Namespace . . . . . . . . . . . . . . . . . 34
5.4. Resolving Grouping, Type, and Identity Names . . . . . . 32 5.4. Resolving Grouping, Type, and Identity Names . . . . . . 34
5.5. Nested Typedefs and Groupings . . . . . . . . . . . . . . 33 5.5. Nested Typedefs and Groupings . . . . . . . . . . . . . . 34
5.6. Conformance . . . . . . . . . . . . . . . . . . . . . . . 33 5.6. Conformance . . . . . . . . . . . . . . . . . . . . . . . 35
5.6.1. Basic Behavior . . . . . . . . . . . . . . . . . . . 34 5.6.1. Basic Behavior . . . . . . . . . . . . . . . . . . . 35
5.6.2. Optional Features . . . . . . . . . . . . . . . . . . 34 5.6.2. Optional Features . . . . . . . . . . . . . . . . . . 35
5.6.3. Deviations . . . . . . . . . . . . . . . . . . . . . 34 5.6.3. Deviations . . . . . . . . . . . . . . . . . . . . . 36
5.6.4. Implementing a Module . . . . . . . . . . . . . . . . 35 5.6.4. Announcing Conformance Information in NETCONF . . . . 36
5.6.5. Announcing Conformance Information in NETCONF . . . . 38 5.6.5. Implementing a Module . . . . . . . . . . . . . . . . 37
5.7. Datastore Modification . . . . . . . . . . . . . . . . . 39 5.7. Datastore Modification . . . . . . . . . . . . . . . . . 40
6. YANG Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 39
6.1. Lexical Tokenization . . . . . . . . . . . . . . . . . . 39 6. YANG Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 40
6.1.1. Comments . . . . . . . . . . . . . . . . . . . . . . 39 6.1. Lexical Tokenization . . . . . . . . . . . . . . . . . . 41
6.1.2. Tokens . . . . . . . . . . . . . . . . . . . . . . . 40 6.1.1. Comments . . . . . . . . . . . . . . . . . . . . . . 41
6.1.3. Quoting . . . . . . . . . . . . . . . . . . . . . . . 40 6.1.2. Tokens . . . . . . . . . . . . . . . . . . . . . . . 41
6.2. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 41 6.1.3. Quoting . . . . . . . . . . . . . . . . . . . . . . . 41
6.2.1. Identifiers and Their Namespaces . . . . . . . . . . 42 6.2. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 43
6.3. Statements . . . . . . . . . . . . . . . . . . . . . . . 43 6.2.1. Identifiers and Their Namespaces . . . . . . . . . . 43
6.3.1. Language Extensions . . . . . . . . . . . . . . . . . 43 6.3. Statements . . . . . . . . . . . . . . . . . . . . . . . 44
6.4. XPath Evaluations . . . . . . . . . . . . . . . . . . . . 43 6.3.1. Language Extensions . . . . . . . . . . . . . . . . . 44
6.4.1. XPath Context . . . . . . . . . . . . . . . . . . . . 44 6.4. XPath Evaluations . . . . . . . . . . . . . . . . . . . . 45
6.5. Schema Node Identifier . . . . . . . . . . . . . . . . . 49 6.4.1. XPath Context . . . . . . . . . . . . . . . . . . . . 45
7. YANG Statements . . . . . . . . . . . . . . . . . . . . . . . 49 6.5. Schema Node Identifier . . . . . . . . . . . . . . . . . 50
7.1. The module Statement . . . . . . . . . . . . . . . . . . 50 7. YANG Statements . . . . . . . . . . . . . . . . . . . . . . . 51
7.1.1. The module's Substatements . . . . . . . . . . . . . 50 7.1. The module Statement . . . . . . . . . . . . . . . . . . 51
7.1.2. The yang-version Statement . . . . . . . . . . . . . 51 7.1.1. The module's Substatements . . . . . . . . . . . . . 52
7.1.3. The namespace Statement . . . . . . . . . . . . . . . 52 7.1.2. The yang-version Statement . . . . . . . . . . . . . 53
7.1.4. The prefix Statement . . . . . . . . . . . . . . . . 52 7.1.3. The namespace Statement . . . . . . . . . . . . . . . 54
7.1.5. The import Statement . . . . . . . . . . . . . . . . 52 7.1.4. The prefix Statement . . . . . . . . . . . . . . . . 54
7.1.6. The include Statement . . . . . . . . . . . . . . . . 54 7.1.5. The import Statement . . . . . . . . . . . . . . . . 54
7.1.7. The organization Statement . . . . . . . . . . . . . 54 7.1.6. The include Statement . . . . . . . . . . . . . . . . 56
7.1.8. The contact Statement . . . . . . . . . . . . . . . . 54 7.1.7. The organization Statement . . . . . . . . . . . . . 56
7.1.9. The revision Statement . . . . . . . . . . . . . . . 55 7.1.8. The contact Statement . . . . . . . . . . . . . . . . 56
7.1.10. Usage Example . . . . . . . . . . . . . . . . . . . . 55 7.1.9. The revision Statement . . . . . . . . . . . . . . . 57
7.2. The submodule Statement . . . . . . . . . . . . . . . . . 56 7.1.10. Usage Example . . . . . . . . . . . . . . . . . . . . 57
7.2.1. The submodule's Substatements . . . . . . . . . . . . 57 7.2. The submodule Statement . . . . . . . . . . . . . . . . . 58
7.2.2. The belongs-to Statement . . . . . . . . . . . . . . 58 7.2.1. The submodule's Substatements . . . . . . . . . . . . 59
7.2.3. Usage Example . . . . . . . . . . . . . . . . . . . . 59 7.2.2. The belongs-to Statement . . . . . . . . . . . . . . 60
7.3. The typedef Statement . . . . . . . . . . . . . . . . . . 59 7.2.3. Usage Example . . . . . . . . . . . . . . . . . . . . 61
7.3.1. The typedef's Substatements . . . . . . . . . . . . . 60 7.3. The typedef Statement . . . . . . . . . . . . . . . . . . 61
7.3.2. The typedef's type Statement . . . . . . . . . . . . 60 7.3.1. The typedef's Substatements . . . . . . . . . . . . . 62
7.3.3. The units Statement . . . . . . . . . . . . . . . . . 60 7.3.2. The typedef's type Statement . . . . . . . . . . . . 62
7.3.4. The typedef's default Statement . . . . . . . . . . . 60 7.3.3. The units Statement . . . . . . . . . . . . . . . . . 62
7.3.5. Usage Example . . . . . . . . . . . . . . . . . . . . 61 7.3.4. The typedef's default Statement . . . . . . . . . . . 62
7.4. The type Statement . . . . . . . . . . . . . . . . . . . 61 7.3.5. Usage Example . . . . . . . . . . . . . . . . . . . . 63
7.4.1. The type's Substatements . . . . . . . . . . . . . . 61 7.4. The type Statement . . . . . . . . . . . . . . . . . . . 63
7.5. The container Statement . . . . . . . . . . . . . . . . . 61 7.4.1. The type's Substatements . . . . . . . . . . . . . . 63
7.5.1. Containers with Presence . . . . . . . . . . . . . . 62 7.5. The container Statement . . . . . . . . . . . . . . . . . 63
7.5.2. The container's Substatements . . . . . . . . . . . . 62 7.5.1. Containers with Presence . . . . . . . . . . . . . . 64
7.5.3. The must Statement . . . . . . . . . . . . . . . . . 63 7.5.2. The container's Substatements . . . . . . . . . . . . 64
7.5.4. The must's Substatements . . . . . . . . . . . . . . 64 7.5.3. The must Statement . . . . . . . . . . . . . . . . . 65
7.5.5. The presence Statement . . . . . . . . . . . . . . . 65 7.5.4. The must's Substatements . . . . . . . . . . . . . . 66
7.5.6. The container's Child Node Statements . . . . . . . . 65 7.5.5. The presence Statement . . . . . . . . . . . . . . . 67
7.5.7. XML Encoding Rules . . . . . . . . . . . . . . . . . 65 7.5.6. The container's Child Node Statements . . . . . . . . 67
7.5.8. NETCONF <edit-config> Operations . . . . . . . . . . 66 7.5.7. XML Encoding Rules . . . . . . . . . . . . . . . . . 67
7.5.9. Usage Example . . . . . . . . . . . . . . . . . . . . 66 7.5.8. NETCONF <edit-config> Operations . . . . . . . . . . 68
7.6. The leaf Statement . . . . . . . . . . . . . . . . . . . 67 7.5.9. Usage Example . . . . . . . . . . . . . . . . . . . . 68
7.6.1. The leaf's default value . . . . . . . . . . . . . . 67 7.6. The leaf Statement . . . . . . . . . . . . . . . . . . . 69
7.6.2. The leaf's Substatements . . . . . . . . . . . . . . 68 7.6.1. The leaf's default value . . . . . . . . . . . . . . 69
7.6.3. The leaf's type Statement . . . . . . . . . . . . . . 69 7.6.2. The leaf's Substatements . . . . . . . . . . . . . . 70
7.6.4. The leaf's default Statement . . . . . . . . . . . . 69 7.6.3. The leaf's type Statement . . . . . . . . . . . . . . 71
7.6.5. The leaf's mandatory Statement . . . . . . . . . . . 69 7.6.4. The leaf's default Statement . . . . . . . . . . . . 71
7.6.6. XML Encoding Rules . . . . . . . . . . . . . . . . . 70 7.6.5. The leaf's mandatory Statement . . . . . . . . . . . 71
7.6.7. NETCONF <edit-config> Operations . . . . . . . . . . 70 7.6.6. XML Encoding Rules . . . . . . . . . . . . . . . . . 72
7.6.8. Usage Example . . . . . . . . . . . . . . . . . . . . 70 7.6.7. NETCONF <edit-config> Operations . . . . . . . . . . 72
7.7. The leaf-list Statement . . . . . . . . . . . . . . . . . 71 7.6.8. Usage Example . . . . . . . . . . . . . . . . . . . . 72
7.7.1. Ordering . . . . . . . . . . . . . . . . . . . . . . 71 7.7. The leaf-list Statement . . . . . . . . . . . . . . . . . 73
7.7.2. The leaf-list's default values . . . . . . . . . . . 72 7.7.1. Ordering . . . . . . . . . . . . . . . . . . . . . . 73
7.7.3. The leaf-list's Substatements . . . . . . . . . . . . 73 7.7.2. The leaf-list's default values . . . . . . . . . . . 74
7.7.4. The leaf-list's default Statement . . . . . . . . . . 73 7.7.3. The leaf-list's Substatements . . . . . . . . . . . . 75
7.7.5. The min-elements Statement . . . . . . . . . . . . . 74 7.7.4. The leaf-list's default Statement . . . . . . . . . . 75
7.7.6. The max-elements Statement . . . . . . . . . . . . . 74 7.7.5. The min-elements Statement . . . . . . . . . . . . . 76
7.7.7. The ordered-by Statement . . . . . . . . . . . . . . 74 7.7.6. The max-elements Statement . . . . . . . . . . . . . 76
7.7.8. XML Encoding Rules . . . . . . . . . . . . . . . . . 75 7.7.7. The ordered-by Statement . . . . . . . . . . . . . . 76
7.7.9. NETCONF <edit-config> Operations . . . . . . . . . . 75 7.7.8. XML Encoding Rules . . . . . . . . . . . . . . . . . 77
7.7.10. Usage Example . . . . . . . . . . . . . . . . . . . . 76 7.7.9. NETCONF <edit-config> Operations . . . . . . . . . . 77
7.8. The list Statement . . . . . . . . . . . . . . . . . . . 78 7.7.10. Usage Example . . . . . . . . . . . . . . . . . . . . 78
7.8.1. The list's Substatements . . . . . . . . . . . . . . 78 7.8. The list Statement . . . . . . . . . . . . . . . . . . . 80
7.8.2. The list's key Statement . . . . . . . . . . . . . . 79 7.8.1. The list's Substatements . . . . . . . . . . . . . . 80
7.8.3. The list's unique Statement . . . . . . . . . . . . . 80 7.8.2. The list's key Statement . . . . . . . . . . . . . . 81
7.8.4. The list's Child Node Statements . . . . . . . . . . 81 7.8.3. The list's unique Statement . . . . . . . . . . . . . 82
7.8.5. XML Encoding Rules . . . . . . . . . . . . . . . . . 81 7.8.4. The list's Child Node Statements . . . . . . . . . . 83
7.8.6. NETCONF <edit-config> Operations . . . . . . . . . . 82 7.8.5. XML Encoding Rules . . . . . . . . . . . . . . . . . 83
7.8.7. Usage Example . . . . . . . . . . . . . . . . . . . . 83 7.8.6. NETCONF <edit-config> Operations . . . . . . . . . . 84
7.9. The choice Statement . . . . . . . . . . . . . . . . . . 86 7.8.7. Usage Example . . . . . . . . . . . . . . . . . . . . 85
7.9.1. The choice's Substatements . . . . . . . . . . . . . 86 7.9. The choice Statement . . . . . . . . . . . . . . . . . . 88
7.9.2. The choice's case Statement . . . . . . . . . . . . . 87 7.9.1. The choice's Substatements . . . . . . . . . . . . . 88
7.9.3. The choice's default Statement . . . . . . . . . . . 88 7.9.2. The choice's case Statement . . . . . . . . . . . . . 89
7.9.4. The choice's mandatory Statement . . . . . . . . . . 90 7.9.3. The choice's default Statement . . . . . . . . . . . 90
7.9.5. XML Encoding Rules . . . . . . . . . . . . . . . . . 90 7.9.4. The choice's mandatory Statement . . . . . . . . . . 92
7.9.6. Usage Example . . . . . . . . . . . . . . . . . . . . 90 7.9.5. XML Encoding Rules . . . . . . . . . . . . . . . . . 92
7.10. The anydata Statement . . . . . . . . . . . . . . . . . . 91 7.9.6. Usage Example . . . . . . . . . . . . . . . . . . . . 92
7.10.1. The anydata's Substatements . . . . . . . . . . . . 92 7.10. The anydata Statement . . . . . . . . . . . . . . . . . . 93
7.10.2. XML Encoding Rules . . . . . . . . . . . . . . . . . 92 7.10.1. The anydata's Substatements . . . . . . . . . . . . 94
7.10.3. NETCONF <edit-config> Operations . . . . . . . . . . 92 7.10.2. XML Encoding Rules . . . . . . . . . . . . . . . . . 94
7.10.4. Usage Example . . . . . . . . . . . . . . . . . . . 93 7.10.3. NETCONF <edit-config> Operations . . . . . . . . . . 94
7.11. The anyxml Statement . . . . . . . . . . . . . . . . . . 93 7.10.4. Usage Example . . . . . . . . . . . . . . . . . . . 95
7.11.1. The anyxml's Substatements . . . . . . . . . . . . . 94 7.11. The anyxml Statement . . . . . . . . . . . . . . . . . . 95
7.11.2. XML Encoding Rules . . . . . . . . . . . . . . . . . 94 7.11.1. The anyxml's Substatements . . . . . . . . . . . . . 96
7.11.3. NETCONF <edit-config> Operations . . . . . . . . . . 94 7.11.2. XML Encoding Rules . . . . . . . . . . . . . . . . . 96
7.11.4. Usage Example . . . . . . . . . . . . . . . . . . . 95 7.11.3. NETCONF <edit-config> Operations . . . . . . . . . . 96
7.12. The grouping Statement . . . . . . . . . . . . . . . . . 95 7.11.4. Usage Example . . . . . . . . . . . . . . . . . . . 97
7.12.1. The grouping's Substatements . . . . . . . . . . . . 96 7.12. The grouping Statement . . . . . . . . . . . . . . . . . 97
7.12.2. Usage Example . . . . . . . . . . . . . . . . . . . 97 7.12.1. The grouping's Substatements . . . . . . . . . . . . 98
7.13. The uses Statement . . . . . . . . . . . . . . . . . . . 97 7.12.2. Usage Example . . . . . . . . . . . . . . . . . . . 99
7.13.1. The uses's Substatements . . . . . . . . . . . . . . 97 7.13. The uses Statement . . . . . . . . . . . . . . . . . . . 99
7.13.2. The refine Statement . . . . . . . . . . . . . . . . 98 7.13.1. The uses's Substatements . . . . . . . . . . . . . . 99
7.13.3. XML Encoding Rules . . . . . . . . . . . . . . . . . 99 7.13.2. The refine Statement . . . . . . . . . . . . . . . . 100
7.13.4. Usage Example . . . . . . . . . . . . . . . . . . . 99 7.13.3. XML Encoding Rules . . . . . . . . . . . . . . . . . 101
7.14. The rpc Statement . . . . . . . . . . . . . . . . . . . . 100 7.13.4. Usage Example . . . . . . . . . . . . . . . . . . . 101
7.14.1. The rpc's Substatements . . . . . . . . . . . . . . 100 7.14. The rpc Statement . . . . . . . . . . . . . . . . . . . . 102
7.14.2. The input Statement . . . . . . . . . . . . . . . . 101 7.14.1. The rpc's Substatements . . . . . . . . . . . . . . 102
7.14.3. The output Statement . . . . . . . . . . . . . . . . 102 7.14.2. The input Statement . . . . . . . . . . . . . . . . 103
7.14.4. NETCONF XML Encoding Rules . . . . . . . . . . . . . 103 7.14.3. The output Statement . . . . . . . . . . . . . . . . 104
7.14.5. Usage Example . . . . . . . . . . . . . . . . . . . 103 7.14.4. NETCONF XML Encoding Rules . . . . . . . . . . . . . 105
7.15. The action Statement . . . . . . . . . . . . . . . . . . 104 7.14.5. Usage Example . . . . . . . . . . . . . . . . . . . 105
7.15.1. The action's Substatements . . . . . . . . . . . . . 104 7.15. The action Statement . . . . . . . . . . . . . . . . . . 106
7.15.2. NETCONF XML Encoding Rules . . . . . . . . . . . . . 105 7.15.1. The action's Substatements . . . . . . . . . . . . . 107
7.15.3. Usage Example . . . . . . . . . . . . . . . . . . . 105 7.15.2. NETCONF XML Encoding Rules . . . . . . . . . . . . . 107
7.16. The notification Statement . . . . . . . . . . . . . . . 107 7.15.3. Usage Example . . . . . . . . . . . . . . . . . . . 107
7.16.1. The notification's Substatements . . . . . . . . . . 108 7.16. The notification Statement . . . . . . . . . . . . . . . 109
7.16.2. NETCONF XML Encoding Rules . . . . . . . . . . . . . 108 7.16.1. The notification's Substatements . . . . . . . . . . 110
7.16.3. Usage Example . . . . . . . . . . . . . . . . . . . 109 7.16.2. NETCONF XML Encoding Rules . . . . . . . . . . . . . 110
7.17. The augment Statement . . . . . . . . . . . . . . . . . . 110 7.16.3. Usage Example . . . . . . . . . . . . . . . . . . . 111
7.17.1. The augment's Substatements . . . . . . . . . . . . 112 7.17. The augment Statement . . . . . . . . . . . . . . . . . . 112
7.17.2. XML Encoding Rules . . . . . . . . . . . . . . . . . 113 7.17.1. The augment's Substatements . . . . . . . . . . . . 114
7.17.3. Usage Example . . . . . . . . . . . . . . . . . . . 113 7.17.2. XML Encoding Rules . . . . . . . . . . . . . . . . . 115
7.18. The identity Statement . . . . . . . . . . . . . . . . . 115 7.17.3. Usage Example . . . . . . . . . . . . . . . . . . . 115
7.18.1. The identity's Substatements . . . . . . . . . . . . 115 7.18. The identity Statement . . . . . . . . . . . . . . . . . 117
7.18.2. The base Statement . . . . . . . . . . . . . . . . . 115 7.18.1. The identity's Substatements . . . . . . . . . . . . 117
7.18.3. Usage Example . . . . . . . . . . . . . . . . . . . 116 7.18.2. The base Statement . . . . . . . . . . . . . . . . . 117
7.19. The extension Statement . . . . . . . . . . . . . . . . . 118 7.18.3. Usage Example . . . . . . . . . . . . . . . . . . . 118
7.19.1. The extension's Substatements . . . . . . . . . . . 118 7.19. The extension Statement . . . . . . . . . . . . . . . . . 120
7.19.2. The argument Statement . . . . . . . . . . . . . . . 118 7.19.1. The extension's Substatements . . . . . . . . . . . 120
7.19.3. Usage Example . . . . . . . . . . . . . . . . . . . 119 7.19.2. The argument Statement . . . . . . . . . . . . . . . 120
7.20. Conformance-Related Statements . . . . . . . . . . . . . 120 7.19.3. Usage Example . . . . . . . . . . . . . . . . . . . 121
7.20.1. The feature Statement . . . . . . . . . . . . . . . 120 7.20. Conformance-Related Statements . . . . . . . . . . . . . 122
7.20.2. The if-feature Statement . . . . . . . . . . . . . . 122 7.20.1. The feature Statement . . . . . . . . . . . . . . . 122
7.20.3. The deviation Statement . . . . . . . . . . . . . . 122 7.20.2. The if-feature Statement . . . . . . . . . . . . . . 124
7.21. Common Statements . . . . . . . . . . . . . . . . . . . . 126 7.20.3. The deviation Statement . . . . . . . . . . . . . . 124
7.21.1. The config Statement . . . . . . . . . . . . . . . . 126 7.21. Common Statements . . . . . . . . . . . . . . . . . . . . 128
7.21.2. The status Statement . . . . . . . . . . . . . . . . 126 7.21.1. The config Statement . . . . . . . . . . . . . . . . 128
7.21.3. The description Statement . . . . . . . . . . . . . 127 7.21.2. The status Statement . . . . . . . . . . . . . . . . 128
7.21.4. The reference Statement . . . . . . . . . . . . . . 127 7.21.3. The description Statement . . . . . . . . . . . . . 129
7.21.5. The when Statement . . . . . . . . . . . . . . . . . 128 7.21.4. The reference Statement . . . . . . . . . . . . . . 129
8. Constraints . . . . . . . . . . . . . . . . . . . . . . . . . 129 7.21.5. The when Statement . . . . . . . . . . . . . . . . . 130
8.1. Constraints on Data . . . . . . . . . . . . . . . . . . . 129 8. Constraints . . . . . . . . . . . . . . . . . . . . . . . . . 131
8.2. Configuration Data Modifications . . . . . . . . . . . . 130 8.1. Constraints on Data . . . . . . . . . . . . . . . . . . . 131
8.3. NETCONF Constraint Enforcement Model . . . . . . . . . . 130 8.2. Configuration Data Modifications . . . . . . . . . . . . 132
8.3.1. Payload Parsing . . . . . . . . . . . . . . . . . . . 130 8.3. NETCONF Constraint Enforcement Model . . . . . . . . . . 132
8.3.2. NETCONF <edit-config> Processing . . . . . . . . . . 131 8.3.1. Payload Parsing . . . . . . . . . . . . . . . . . . . 132
8.3.3. Validation . . . . . . . . . . . . . . . . . . . . . 132 8.3.2. NETCONF <edit-config> Processing . . . . . . . . . . 133
9. Built-In Types . . . . . . . . . . . . . . . . . . . . . . . 132 8.3.3. Validation . . . . . . . . . . . . . . . . . . . . . 134
9.1. Canonical Representation . . . . . . . . . . . . . . . . 132 9. Built-In Types . . . . . . . . . . . . . . . . . . . . . . . 134
9.2. The Integer Built-In Types . . . . . . . . . . . . . . . 133 9.1. Canonical Representation . . . . . . . . . . . . . . . . 134
9.2.1. Lexical Representation . . . . . . . . . . . . . . . 133 9.2. The Integer Built-In Types . . . . . . . . . . . . . . . 135
9.2.2. Canonical Form . . . . . . . . . . . . . . . . . . . 134 9.2.1. Lexical Representation . . . . . . . . . . . . . . . 135
9.2.3. Restrictions . . . . . . . . . . . . . . . . . . . . 134 9.2.2. Canonical Form . . . . . . . . . . . . . . . . . . . 136
9.2.4. The range Statement . . . . . . . . . . . . . . . . . 134 9.2.3. Restrictions . . . . . . . . . . . . . . . . . . . . 136
9.2.5. Usage Example . . . . . . . . . . . . . . . . . . . . 135 9.2.4. The range Statement . . . . . . . . . . . . . . . . . 136
9.3. The decimal64 Built-In Type . . . . . . . . . . . . . . . 135 9.2.5. Usage Example . . . . . . . . . . . . . . . . . . . . 137
9.3.1. Lexical Representation . . . . . . . . . . . . . . . 136 9.3. The decimal64 Built-In Type . . . . . . . . . . . . . . . 137
9.3.2. Canonical Form . . . . . . . . . . . . . . . . . . . 136 9.3.1. Lexical Representation . . . . . . . . . . . . . . . 138
9.3.3. Restrictions . . . . . . . . . . . . . . . . . . . . 136 9.3.2. Canonical Form . . . . . . . . . . . . . . . . . . . 138
9.3.4. The fraction-digits Statement . . . . . . . . . . . . 136 9.3.3. Restrictions . . . . . . . . . . . . . . . . . . . . 138
9.3.5. Usage Example . . . . . . . . . . . . . . . . . . . . 137 9.3.4. The fraction-digits Statement . . . . . . . . . . . . 138
9.4. The string Built-In Type . . . . . . . . . . . . . . . . 137 9.3.5. Usage Example . . . . . . . . . . . . . . . . . . . . 139
9.4.1. Lexical Representation . . . . . . . . . . . . . . . 137 9.4. The string Built-In Type . . . . . . . . . . . . . . . . 139
9.4.2. Canonical Form . . . . . . . . . . . . . . . . . . . 138 9.4.1. Lexical Representation . . . . . . . . . . . . . . . 139
9.4.3. Restrictions . . . . . . . . . . . . . . . . . . . . 138 9.4.2. Canonical Form . . . . . . . . . . . . . . . . . . . 140
9.4.4. The length Statement . . . . . . . . . . . . . . . . 138 9.4.3. Restrictions . . . . . . . . . . . . . . . . . . . . 140
9.4.5. The pattern Statement . . . . . . . . . . . . . . . . 139 9.4.4. The length Statement . . . . . . . . . . . . . . . . 140
9.4.6. The modifier Statement . . . . . . . . . . . . . . . 139 9.4.5. The pattern Statement . . . . . . . . . . . . . . . . 141
9.4.7. Usage Example . . . . . . . . . . . . . . . . . . . . 139 9.4.6. The modifier Statement . . . . . . . . . . . . . . . 141
9.5. The boolean Built-In Type . . . . . . . . . . . . . . . . 141 9.4.7. Usage Example . . . . . . . . . . . . . . . . . . . . 141
9.5.1. Lexical Representation . . . . . . . . . . . . . . . 141 9.5. The boolean Built-In Type . . . . . . . . . . . . . . . . 143
9.5.2. Canonical Form . . . . . . . . . . . . . . . . . . . 141 9.5.1. Lexical Representation . . . . . . . . . . . . . . . 143
9.5.3. Restrictions . . . . . . . . . . . . . . . . . . . . 141 9.5.2. Canonical Form . . . . . . . . . . . . . . . . . . . 143
9.6. The enumeration Built-In Type . . . . . . . . . . . . . . 141 9.5.3. Restrictions . . . . . . . . . . . . . . . . . . . . 143
9.6.1. Lexical Representation . . . . . . . . . . . . . . . 141 9.6. The enumeration Built-In Type . . . . . . . . . . . . . . 143
9.6.2. Canonical Form . . . . . . . . . . . . . . . . . . . 141 9.6.1. Lexical Representation . . . . . . . . . . . . . . . 143
9.6.3. Restrictions . . . . . . . . . . . . . . . . . . . . 141 9.6.2. Canonical Form . . . . . . . . . . . . . . . . . . . 143
9.6.4. The enum Statement . . . . . . . . . . . . . . . . . 141 9.6.3. Restrictions . . . . . . . . . . . . . . . . . . . . 143
9.6.5. Usage Example . . . . . . . . . . . . . . . . . . . . 143 9.6.4. The enum Statement . . . . . . . . . . . . . . . . . 143
9.7. The bits Built-In Type . . . . . . . . . . . . . . . . . 144 9.6.5. Usage Example . . . . . . . . . . . . . . . . . . . . 145
9.7.1. Restrictions . . . . . . . . . . . . . . . . . . . . 144 9.7. The bits Built-In Type . . . . . . . . . . . . . . . . . 146
9.7.2. Lexical Representation . . . . . . . . . . . . . . . 144 9.7.1. Restrictions . . . . . . . . . . . . . . . . . . . . 146
9.7.3. Canonical Form . . . . . . . . . . . . . . . . . . . 145 9.7.2. Lexical Representation . . . . . . . . . . . . . . . 146
9.7.4. The bit Statement . . . . . . . . . . . . . . . . . . 145 9.7.3. Canonical Form . . . . . . . . . . . . . . . . . . . 147
9.7.5. Usage Example . . . . . . . . . . . . . . . . . . . . 146 9.7.4. The bit Statement . . . . . . . . . . . . . . . . . . 147
9.8. The binary Built-In Type . . . . . . . . . . . . . . . . 147 9.7.5. Usage Example . . . . . . . . . . . . . . . . . . . . 148
9.8.1. Restrictions . . . . . . . . . . . . . . . . . . . . 147 9.8. The binary Built-In Type . . . . . . . . . . . . . . . . 149
9.8.2. Lexical Representation . . . . . . . . . . . . . . . 147 9.8.1. Restrictions . . . . . . . . . . . . . . . . . . . . 149
9.8.3. Canonical Form . . . . . . . . . . . . . . . . . . . 147 9.8.2. Lexical Representation . . . . . . . . . . . . . . . 149
9.9. The leafref Built-In Type . . . . . . . . . . . . . . . . 147 9.8.3. Canonical Form . . . . . . . . . . . . . . . . . . . 149
9.9.1. Restrictions . . . . . . . . . . . . . . . . . . . . 148 9.9. The leafref Built-In Type . . . . . . . . . . . . . . . . 149
9.9.2. The path Statement . . . . . . . . . . . . . . . . . 148 9.9.1. Restrictions . . . . . . . . . . . . . . . . . . . . 150
9.9.3. The require-instance Statement . . . . . . . . . . . 148 9.9.2. The path Statement . . . . . . . . . . . . . . . . . 150
9.9.4. Lexical Representation . . . . . . . . . . . . . . . 149 9.9.3. The require-instance Statement . . . . . . . . . . . 150
9.9.5. Canonical Form . . . . . . . . . . . . . . . . . . . 149 9.9.4. Lexical Representation . . . . . . . . . . . . . . . 151
9.9.6. Usage Example . . . . . . . . . . . . . . . . . . . . 149 9.9.5. Canonical Form . . . . . . . . . . . . . . . . . . . 151
9.10. The identityref Built-In Type . . . . . . . . . . . . . . 153 9.9.6. Usage Example . . . . . . . . . . . . . . . . . . . . 151
9.10.1. Restrictions . . . . . . . . . . . . . . . . . . . . 153 9.10. The identityref Built-In Type . . . . . . . . . . . . . . 155
9.10.2. The identityref's base Statement . . . . . . . . . . 153 9.10.1. Restrictions . . . . . . . . . . . . . . . . . . . . 155
9.10.3. Lexical Representation . . . . . . . . . . . . . . . 153 9.10.2. The identityref's base Statement . . . . . . . . . . 155
9.10.4. Canonical Form . . . . . . . . . . . . . . . . . . . 154 9.10.3. Lexical Representation . . . . . . . . . . . . . . . 155
9.10.5. Usage Example . . . . . . . . . . . . . . . . . . . 154 9.10.4. Canonical Form . . . . . . . . . . . . . . . . . . . 156
9.11. The empty Built-In Type . . . . . . . . . . . . . . . . . 155 9.10.5. Usage Example . . . . . . . . . . . . . . . . . . . 156
9.11.1. Restrictions . . . . . . . . . . . . . . . . . . . . 155 9.11. The empty Built-In Type . . . . . . . . . . . . . . . . . 157
9.11.2. Lexical Representation . . . . . . . . . . . . . . . 155 9.11.1. Restrictions . . . . . . . . . . . . . . . . . . . . 157
9.11.3. Canonical Form . . . . . . . . . . . . . . . . . . . 155 9.11.2. Lexical Representation . . . . . . . . . . . . . . . 157
9.11.4. Usage Example . . . . . . . . . . . . . . . . . . . 155 9.11.3. Canonical Form . . . . . . . . . . . . . . . . . . . 157
9.12. The union Built-In Type . . . . . . . . . . . . . . . . . 156 9.11.4. Usage Example . . . . . . . . . . . . . . . . . . . 157
9.12.1. Restrictions . . . . . . . . . . . . . . . . . . . . 156 9.12. The union Built-In Type . . . . . . . . . . . . . . . . . 158
9.12.2. Lexical Representation . . . . . . . . . . . . . . . 156 9.12.1. Restrictions . . . . . . . . . . . . . . . . . . . . 158
9.12.3. Canonical Form . . . . . . . . . . . . . . . . . . . 156 9.12.2. Lexical Representation . . . . . . . . . . . . . . . 158
9.12.4. Usage Example . . . . . . . . . . . . . . . . . . . 156 9.12.3. Canonical Form . . . . . . . . . . . . . . . . . . . 158
9.13. The instance-identifier Built-In Type . . . . . . . . . . 157 9.12.4. Usage Example . . . . . . . . . . . . . . . . . . . 158
9.13.1. Restrictions . . . . . . . . . . . . . . . . . . . . 158 9.13. The instance-identifier Built-In Type . . . . . . . . . . 159
9.13.2. Lexical Representation . . . . . . . . . . . . . . . 158 9.13.1. Restrictions . . . . . . . . . . . . . . . . . . . . 160
9.13.3. Canonical Form . . . . . . . . . . . . . . . . . . . 158 9.13.2. Lexical Representation . . . . . . . . . . . . . . . 160
9.13.4. Usage Example . . . . . . . . . . . . . . . . . . . 159 9.13.3. Canonical Form . . . . . . . . . . . . . . . . . . . 160
10. XPath Functions . . . . . . . . . . . . . . . . . . . . . . . 159 9.13.4. Usage Example . . . . . . . . . . . . . . . . . . . 161
10.1. Functions for Node Sets . . . . . . . . . . . . . . . . 159 10. XPath Functions . . . . . . . . . . . . . . . . . . . . . . . 161
10.1.1. current() . . . . . . . . . . . . . . . . . . . . . 159 10.1. Functions for Node Sets . . . . . . . . . . . . . . . . 161
10.2. Functions for Strings . . . . . . . . . . . . . . . . . 160 10.1.1. current() . . . . . . . . . . . . . . . . . . . . . 161
10.2.1. re-match() . . . . . . . . . . . . . . . . . . . . . 160 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" . . . . . . . . . . . . . . . . . . . . . . 161 identifier" . . . . . . . . . . . . . . . . . . . . . . 163
10.3.1. deref() . . . . . . . . . . . . . . . . . . . . . . 161 10.3.1. deref() . . . . . . . . . . . . . . . . . . . . . . 163
10.4. Functions for the YANG Type "identityref" . . . . . . . 162 10.4. Functions for the YANG Type "identityref" . . . . . . . 164
10.4.1. derived-from() . . . . . . . . . . . . . . . . . . . 162 10.4.1. derived-from() . . . . . . . . . . . . . . . . . . . 164
10.4.2. derived-from-or-self() . . . . . . . . . . . . . . . 163 10.4.2. derived-from-or-self() . . . . . . . . . . . . . . . 165
10.5. Functions for the YANG Type "enumeration" . . . . . . . 164 10.5. Functions for the YANG Type "enumeration" . . . . . . . 166
10.5.1. enum-value() . . . . . . . . . . . . . . . . . . . . 164 10.5.1. enum-value() . . . . . . . . . . . . . . . . . . . . 166
10.6. Functions for the YANG Type "bits" . . . . . . . . . . . 165 10.6. Functions for the YANG Type "bits" . . . . . . . . . . . 167
10.6.1. bit-is-set() . . . . . . . . . . . . . . . . . . . . 165 10.6.1. bit-is-set() . . . . . . . . . . . . . . . . . . . . 167
11. Updating a Module . . . . . . . . . . . . . . . . . . . . . . 166 11. Updating a Module . . . . . . . . . . . . . . . . . . . . . . 168
12. Coexistence with YANG version 1 . . . . . . . . . . . . . . . 168 12. Coexistence with YANG version 1 . . . . . . . . . . . . . . . 170
13. YIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 13. YIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
13.1. Formal YIN Definition . . . . . . . . . . . . . . . . . 169 13.1. Formal YIN Definition . . . . . . . . . . . . . . . . . 171
13.1.1. Usage Example . . . . . . . . . . . . . . . . . . . 172 13.1.1. Usage Example . . . . . . . . . . . . . . . . . . . 174
14. YANG ABNF Grammar . . . . . . . . . . . . . . . . . . . . . . 173 14. YANG ABNF Grammar . . . . . . . . . . . . . . . . . . . . . . 175
15. NETCONF Error Responses for YANG Related Errors . . . . . . . 197 15. NETCONF Error Responses for YANG Related Errors . . . . . . . 199
15.1. Error Message for Data That Violates a unique Statement 197 15.1. Error Message for Data That Violates a unique Statement 199
15.2. Error Message for Data That Violates a max-elements 15.2. Error Message for Data That Violates a max-elements
Statement . . . . . . . . . . . . . . . . . . . . . . . 198 Statement . . . . . . . . . . . . . . . . . . . . . . . 200
15.3. Error Message for Data That Violates a min-elements 15.3. Error Message for Data That Violates a min-elements
Statement . . . . . . . . . . . . . . . . . . . . . . . 198 Statement . . . . . . . . . . . . . . . . . . . . . . . 200
15.4. Error Message for Data That Violates a must Statement . 198 15.4. Error Message for Data That Violates a must Statement . 200
15.5. Error Message for Data That Violates a require-instance 15.5. Error Message for Data That Violates a require-instance
Statement . . . . . . . . . . . . . . . . . . . . . . . 199 Statement . . . . . . . . . . . . . . . . . . . . . . . 201
15.6. Error Message for Data That Violates a mandatory choice 15.6. Error Message for Data That Violates a mandatory choice
Statement . . . . . . . . . . . . . . . . . . . . . . . 199 Statement . . . . . . . . . . . . . . . . . . . . . . . 201
15.7. Error Message for the "insert" Operation . . . . . . . . 199 15.7. Error Message for the "insert" Operation . . . . . . . . 201
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 199 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 201
17. Security Considerations . . . . . . . . . . . . . . . . . . . 199 17. Security Considerations . . . . . . . . . . . . . . . . . . . 201
18. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 200 18. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 202
19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 200 19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 202
20. ChangeLog . . . . . . . . . . . . . . . . . . . . . . . . . . 201 20. ChangeLog . . . . . . . . . . . . . . . . . . . . . . . . . . 203
20.1. Version -10 . . . . . . . . . . . . . . . . . . . . . . 201 20.1. Version -10 . . . . . . . . . . . . . . . . . . . . . . 203
20.2. Version -09 . . . . . . . . . . . . . . . . . . . . . . 201 20.2. Version -09 . . . . . . . . . . . . . . . . . . . . . . 203
20.3. Version -08 . . . . . . . . . . . . . . . . . . . . . . 201 20.3. Version -08 . . . . . . . . . . . . . . . . . . . . . . 203
20.4. Version -07 . . . . . . . . . . . . . . . . . . . . . . 201 20.4. Version -07 . . . . . . . . . . . . . . . . . . . . . . 203
20.5. Version -06 . . . . . . . . . . . . . . . . . . . . . . 201 20.5. Version -06 . . . . . . . . . . . . . . . . . . . . . . 203
20.6. Version -05 . . . . . . . . . . . . . . . . . . . . . . 202 20.6. Version -05 . . . . . . . . . . . . . . . . . . . . . . 204
20.7. Version -04 . . . . . . . . . . . . . . . . . . . . . . 202 20.7. Version -04 . . . . . . . . . . . . . . . . . . . . . . 204
20.8. Version -03 . . . . . . . . . . . . . . . . . . . . . . 202 20.8. Version -03 . . . . . . . . . . . . . . . . . . . . . . 204
20.9. Version -02 . . . . . . . . . . . . . . . . . . . . . . 202 20.9. Version -02 . . . . . . . . . . . . . . . . . . . . . . 204
20.10. Version -01 . . . . . . . . . . . . . . . . . . . . . . 203 20.10. Version -01 . . . . . . . . . . . . . . . . . . . . . . 205
20.11. Version -00 . . . . . . . . . . . . . . . . . . . . . . 203 20.11. Version -00 . . . . . . . . . . . . . . . . . . . . . . 205
21. References . . . . . . . . . . . . . . . . . . . . . . . . . 203 21. References . . . . . . . . . . . . . . . . . . . . . . . . . 205
21.1. Normative References . . . . . . . . . . . . . . . . . . 203 21.1. Normative References . . . . . . . . . . . . . . . . . . 205
21.2. Informative References . . . . . . . . . . . . . . . . . 205 21.2. Informative References . . . . . . . . . . . . . . . . . 207
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 206 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 208
1. Introduction 1. Introduction
YANG is a data modeling language originally designed to model YANG is a data modeling language originally designed to model
configuration and state data manipulated by the Network Configuration configuration and state data manipulated by the Network Configuration
Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF
notifications [RFC6241]. Since the publication of YANG version 1 notifications [RFC6241]. Since the publication of YANG version 1
[RFC6020], YANG has been used or proposed to be used for other [RFC6020], YANG has been used or proposed to be used for other
protocols (e.g., RESTCONF [I-D.ietf-netconf-restconf] and CoMI protocols (e.g., RESTCONF [I-D.ietf-netconf-restconf] and CoMI
[I-D.vanderstok-core-comi]). Further, other encodings than XML have [I-D.vanderstok-core-comi]). Further, other encodings than XML have
skipping to change at page 9, line 5 skipping to change at page 9, line 11
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.
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].
o Changed the YANG version from "1" to "1.1". The following changes are not backwards compatible with YANG version
1:
o Made the "yang-version" statement mandatory.
o Made noncharacters illegal in the built-in type "string".
o Defined the legal characters in YANG modules.
o Changed the rules for the interpretation of escaped characters in o Changed the rules for the interpretation of escaped characters in
double quoted strings. This is an backwards incompatible change double quoted strings. This is an backwards incompatible change
from YANG version 1. A module that uses a character sequence that from YANG version 1. A module that uses a character sequence that
is now illegal must change the string to match the new rules. See is now illegal must change the string to match the new rules. See
Section 6.1.3 for details. Section 6.1.3 for details.
o An unquoted string cannot contain any single or double quote 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.
The following additional changes have been done to YANG:
o Changed the YANG version from "1" to "1.1".
o Made the "yang-version" statement mandatory.
o Made noncharacters illegal in the built-in type "string".
o Defined the legal characters in YANG modules.
o Extended the "if-feature" syntax to be a boolean expression over o Extended the "if-feature" syntax to be a boolean expression over
feature names. feature names.
o Allow "if-feature" in "bit", "enum", and "identity". o Allow "if-feature" in "bit", "enum", and "identity".
o Allow "if-feature" in "refine". o Allow "if-feature" in "refine".
o Made "when" and "if-feature" illegal on list keys. o Made "when" and "if-feature" illegal on list keys.
o Allow "choice" as a shorthand case statement (see Section 7.9). o Allow "choice" as a shorthand case statement (see Section 7.9).
o Added a new substatement "modifier" to pattern (see o Added a new substatement "modifier" to pattern (see
Section 9.4.6). Section 9.4.6).
o Allow "must" in "input", "output", and "notification". o Allow "must" in "input", "output", and "notification".
o Allow "require-instance" in leafref. o Allow "require-instance" in leafref.
o Allow "description" and "reference" in "import" and "include".
o Allow imports of multiple revisions of a module.
o Allow "augment" to add conditionally mandatory nodes (see o Allow "augment" to add conditionally mandatory nodes (see
Section 7.17). Section 7.17).
o Added a set of new XPath functions in Section 10. o Added a set of new XPath functions in Section 10.
o Clarified the XPath context's tree in Section 6.4.1. o Clarified the XPath context's tree in Section 6.4.1.
o Defined the string value of an identityref in XPath expressions o Defined the string value of an identityref in XPath expressions
(see Section 9.10). (see Section 9.10).
o Clarified what unprefixed names mean in leafrefs in typedefs (see o Clarified what unprefixed names mean in leafrefs in typedefs (see
Section 9.9.2). Section 6.4.1 and Section 9.9.2).
o Allow identities to be derived from multiple base identities (see o Allow identities to be derived from multiple base identities (see
Section 7.18 and Section 9.10). Section 7.18 and Section 9.10).
o Allow enumerations and bits to be subtyped (see Section 9.6 and o Allow enumerations and bits to be subtyped (see Section 9.6 and
Section 9.7). Section 9.7).
o Allow leaf-lists to have default values (see Section 7.7.2). o Allow leaf-lists to have default values (see Section 7.7.2).
o Allow non-unique values in non-configuration leaf-lists (see o Allow non-unique values in non-configuration leaf-lists (see
Section 7.7). Section 7.7).
o Use [RFC7405] syntax for case-sensitive strings in the grammar. o Use [RFC7405] syntax for case-sensitive strings in the grammar.
o Changed the module advertisement mechanism (see Section 5.6.5). o Changed the module advertisement mechanism (see Section 5.6.4).
o Changed the scoping rules for definitions in submodules. A o Changed the scoping rules for definitions in submodules. A
submodule can now reference all definitions in all submodules that submodule can now reference all definitions in all submodules that
belong to the same module, without using the "include" statement. belong to the same module, without using the "include" statement.
o Added a new statement "action" that is used to define operations o Added a new statement "action" that is used to define operations
tied to data nodes. tied to data nodes.
o Allow notifications to be tied to data nodes. o Allow notifications to be tied to data nodes.
o Added a new data definition statement "anydata" (see o Added a new data definition statement "anydata" (see Section 7.10)
Section 7.10). which is RECOMMENDED to be used instead of "anyxml" when the data
can be modeled in YANG
o Allow types empty and leafref in unions. o Allow types empty and leafref in unions.
o Allow type empty in a key. o Allow type empty in a key.
The following changes have been done to the NETCONF mapping:
o A server advertises support for YANG 1.1 modules by using ietf-
yang-library [I-D.ietf-netconf-yang-library] instead of listing
them as capabilities in the <hello> message.
2. Keywords 2. Keywords
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14, [RFC2119]. 14, [RFC2119].
3. Terminology 3. Terminology
The following terms are used within this document: The following terms are used within this document:
o action: An operation defined for a node in the data tree. o action: An operation defined for a node in the data tree.
o anydata: A data node that can contain an unknown set of nodes that o anydata: A data node that can contain an unknown set of nodes that
can be modelled by YANG. can be modelled by YANG, except anyxml.
o anyxml: A data node that can contain an unknown chunk of XML data. o anyxml: A data node that can contain an unknown chunk of XML data.
o augment: Adds new schema nodes to a previously defined schema o augment: Adds new schema nodes to a previously defined schema
node. node.
o base type: The type from which a derived type was derived, which o base type: The type from which a derived type was derived, which
may be either a built-in type or another derived type. may be either a built-in type or another derived type.
o built-in type: A YANG data type defined in the YANG language, such o built-in type: A YANG data type defined in the YANG language, such
skipping to change at page 13, line 33 skipping to change at page 14, line 7
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.
The following terms are defined in [RFC6241]: The following terms are defined in [RFC6241]:
o configuration data o configuration data
o configuration datastore: a configuration datastore is an o configuration datastore
instantiated data tree with configuration data
o datastore: an instantiated data tree
o running configuration datastore o datastore
o state data o state data
When modelled with YANG, a datastore is realized as an instantiated
data tree.
When modelled with YANG, a configuration datastore is realized as an
instantiated data tree with configuration data.
3.1. A Note on Examples
Throughout this document there are many examples of YANG statements.
These examples are supposed to illustrate certain features, and are
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 a hierarchy of data that can be used
for NETCONF-based operations, including configuration, state data, for NETCONF-based operations, including configuration, state data,
skipping to change at page 14, line 20 skipping to change at page 15, line 5
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 data from other external modules, and include data from
submodules. The hierarchy can be augmented, allowing one module to submodules. The hierarchy can be augmented, allowing one module to
add data nodes to the hierarchy defined in another module. This add data nodes to the hierarchy defined in another module. This
augmentation can be conditional, with new nodes appearing only if augmentation can be conditional, with new nodes appearing only if
certain conditions are met. certain conditions are met.
YANG models can describe constraints to be enforced on the data, YANG data models can describe constraints to be enforced on the data,
restricting the appearance 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, and valid content
MUST abide by them. 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.
skipping to change at page 17, line 12 skipping to change at page 17, line 44
<domain-search>low.example.com</domain-search> <domain-search>low.example.com</domain-search>
<domain-search>everywhere.example.com</domain-search> <domain-search>everywhere.example.com</domain-search>
The "leaf-list" statement is covered in Section 7.7. The "leaf-list" statement is covered in Section 7.7.
4.2.2.3. Container Nodes 4.2.2.3. Container Nodes
A container is used to group related nodes in a subtree. A container A container is used to group related nodes in a subtree. A container
has only child nodes and no value. A container may contain any has only child nodes and no value. A container may contain any
number of child nodes of any type (leafs, lists, containers, leaf- number of child nodes of any type (leafs, lists, containers, leaf-
lists, and actions). lists, actions, and notifications).
YANG Example: YANG Example:
container system { container system {
container login { container login {
leaf message { leaf message {
type string; type string;
description description
"Message given at start of login session"; "Message given at start of login session";
} }
skipping to change at page 21, line 15 skipping to change at page 22, line 15
+---------------------+-------------------------------------+ +---------------------+-------------------------------------+
| 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 | Enumerated strings |
| identityref | A reference to an abstract identity | | identityref | A reference to an abstract identity |
| instance-identifier | References a data tree node | | instance-identifier | A reference a data tree node |
| int8 | 8-bit signed integer | | int8 | 8-bit signed integer |
| int16 | 16-bit signed integer | | int16 | 16-bit signed integer |
| int32 | 32-bit signed integer | | int32 | 32-bit signed integer |
| int64 | 64-bit signed integer | | int64 | 64-bit signed integer |
| leafref | A reference to a leaf instance | | leafref | A reference to a leaf instance |
| string | Human-readable string | | string | Human-readable string |
| uint8 | 8-bit unsigned integer | | uint8 | 8-bit unsigned integer |
| uint16 | 16-bit unsigned integer | | uint16 | 16-bit unsigned integer |
| uint32 | 32-bit unsigned integer | | uint32 | 32-bit unsigned integer |
| uint64 | 64-bit unsigned integer | | uint64 | 64-bit unsigned integer |
skipping to change at page 22, line 36 skipping to change at page 23, line 36
container peer { container peer {
container destination { container destination {
uses target; uses target;
} }
} }
XML Encoding Example: XML Encoding Example:
<peer> <peer>
<destination> <destination>
<address>192.0.2.1</address> <address>2001:db8::2</address>
<port>830</port> <port>830</port>
</destination> </destination>
</peer> </peer>
The grouping can be refined as it is used, allowing certain The grouping can be refined as it is used, allowing certain
statements to be overridden. In this example, the description is statements to be overridden. In this example, the description is
refined: refined:
container connection { container connection {
container source { container source {
skipping to change at page 25, line 39 skipping to change at page 26, line 39
</user> </user>
The "augment" statement is covered in Section 7.17. The "augment" statement is covered in Section 7.17.
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
data node. Such operations are defined with the "action" statement. container or list data node. Such operations are defined with the
"action" statement.
YANG Example: YANG Example:
rpc activate-software-image { rpc activate-software-image {
input { input {
leaf image-name { leaf image-name {
type string; type string;
} }
} }
output { output {
skipping to change at page 26, line 24 skipping to change at page 27, line 24
} }
} }
} }
NETCONF XML Example: NETCONF XML Example:
<rpc message-id="101" <rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<activate-software-image xmlns="http://example.com/system"> <activate-software-image xmlns="http://example.com/system">
<image-name>example-fw-2.3</image-name> <image-name>example-fw-2.3</image-name>
</activate-software-image> </activate-software-image>
</rpc> </rpc>
<rpc-reply message-id="101" <rpc-reply message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<status xmlns="http://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:
skipping to change at page 29, line 19 skipping to change at page 30, line 19
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 include all its submodules,
and the "import" statement to reference external modules. Similarly, and the "import" statement to reference external modules. Similarly,
a submodule uses the "import" statement to reference other modules. a submodule uses the "import" statement to reference other modules.
For backward compatibility with YANG version 1, a submodule is For backward compatibility with YANG version 1, a submodule is
allowed to use the "include" statement to reference other submodules allowed to use the "include" statement to reference other submodules
within its module, but this is not necessary in YANG version 1.1. A 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 submodule can reference any definition in the module it belongs to
and in all submodules included by the module. 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, can 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 ":", and then the external
identifier. References to definitions in the local module MAY use identifier. References to definitions in the local module MAY use
the prefix notation. Since built-in data types do not belong to any the prefix notation. Since built-in data types do not belong to any
module and have no prefix, references to built-in data types (e.g., module and have no prefix, references to built-in data types (e.g.,
int32) cannot use the prefix notation. The syntax for a reference to int32) cannot use the prefix notation. The syntax for a reference to
a definition is formally defined by the rule "identifier-ref" in a definition is formally defined by the rule "identifier-ref" in
Section 14. 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 need to be imported using specific for this evolution, modules can be imported using specific revisions.
revisions. When a module is written, it uses the current revisions When a module is written, it can import the current revisions of
of other modules, based on what is available at the time. As future other modules, based on what is available at the time. As future
revisions of the imported modules are published, the importing module revisions of the imported modules are published, the importing module
is unaffected and its contents are unchanged. When the author of the is unaffected and its contents are unchanged. When the author of the
module is prepared to move to the most recently published revision of module is prepared to move to the most recently published revision of
an imported module, the module is republished with an updated an imported module, the module is republished with an updated
"import" statement. By republishing with the new revision, the "import" statement. By republishing with the new revision, the
authors explicitly indicate their acceptance of any changes in the authors explicitly indicate their acceptance of any changes in the
imported module. imported 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 needs to specify the revision of
skipping to change at page 31, line 5 skipping to change at page 32, line 10
container bee { container bee {
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
which exact 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. 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
skipping to change at page 35, line 24 skipping to change at page 36, line 46
that could not succeed. that could not succeed.
Server deviations are declared using the "deviation" statement, which Server deviations are declared using the "deviation" statement, which
takes as its argument a string that identifies a node in the schema takes as its argument a string that identifies a node in the schema
tree. The contents of the statement details the manner in which the tree. The contents of the statement details the manner in which the
server implementation deviates from the contract as defined in the server implementation deviates from the contract as defined in the
module. module.
Further details are available in Section 7.20.3. Further details are available in Section 7.20.3.
5.6.4. Implementing a Module 5.6.4. Announcing Conformance Information in NETCONF
This document defines the following mechanism for announcing
conformance information. Other mechanisms may be defined by future
specifications.
A NETCONF server announces the modules it implements (see
Section 5.6.5) by implementing the YANG module "ietf-yang-library"
defined in [I-D.ietf-netconf-yang-library], and listing all
implemented modules in the "/modules-state/module" list.
The server also advertises the following capability in the <hello>
message (line-breaks and whitespaces are used for formatting reasons
only):
urn:ietf:params:netconf:capability:yang-library:1.0?
revision=<date>&module-set-id=<id>
The parameter "revision" has the same value as the revision date of
the "ietf-yang-library" module implemented by the server. This
parameter MUST be present.
The parameter "module-set-id" has the same value as the leaf
"/modules-state/module-set-id" from "ietf-yang-library". This
parameter MUST be present.
With this mechanism, a client can cache the supported modules for a
server, and only update the cache if the "module-set-id" value in the
<hello> message changes.
5.6.5. Implementing a Module
A server implements a module if it implements the module's data A server implements a module if it implements the module's data
nodes, rpcs, actions, notifications, and deviations. nodes, rpcs, actions, notifications, and deviations.
A server MUST NOT implement more than one revision of a module. A server MUST NOT implement more than one revision of a module.
If a server implements a module A that imports a module B, and A uses If a server implements a module A that imports a module B, and A uses
any node from B in an "augment" or "path" statement that the server any node from B in an "augment" or "path" statement that the server
supports, then the server MUST implement a revision of module B that supports, then the server MUST implement a revision of module B that
has these nodes defined. This is regardless of if module B is has these nodes defined. This is regardless of if module B is
skipping to change at page 38, line 29 skipping to change at page 40, line 29
<conformance-type>implement</conformance-type> <conformance-type>implement</conformance-type>
</module> </module>
<module> <module>
<name>c</name> <name>c</name>
<revision>2015-02-02</revision> <revision>2015-02-02</revision>
<namespace>urn:example:c</namespace> <namespace>urn:example:c</namespace>
<conformance-type>import</conformance-type> <conformance-type>import</conformance-type>
</module> </module>
</modules-state> </modules-state>
5.6.5. Announcing Conformance Information in NETCONF
This document defines the following mechanism for announcing
conformance information. Other mechanisms may be defined by future
specifications.
A NETCONF server announces the modules it implements by implementing
the YANG module "ietf-yang-library" defined in
[I-D.ietf-netconf-yang-library], and listing all implemented modules
in the "/modules-state/module" list.
The server also advertises the following capability in the <hello>
message (line-breaks and whitespaces are used for formatting reasons
only):
urn:ietf:params:netconf:capability:yang-library:1.0?
module-set-id=<id>
The parameter "module-set-id" has the same value as the leaf
"/modules-state/module-set-id" from "ietf-yang-library". This
parameter MUST be present.
With this mechanism, a client can cache the supported modules for a
server, and only update the cache if the "module-set-id" value in the
<hello> message changes.
5.7. Datastore Modification 5.7. Datastore Modification
Data models may allow the server to alter the configuration datastore Data models may allow the server to alter the configuration datastore
in ways not explicitly directed via network management protocol in ways not explicitly directed via network management protocol
messages. For example, a data model may define leafs that are messages. For example, a data model may define leafs that are
assigned system-generated values when the client does not provide assigned system-generated values when the client does not provide
one. A formal mechanism for specifying the circumstances where these one. A formal mechanism for specifying the circumstances where these
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
skipping to change at page 47, line 6 skipping to change at page 48, line 6
The context node varies with the YANG XPath expression, and is The context node varies with the YANG XPath expression, and is
specified where the YANG statement with the XPath expression is specified where the YANG statement with the XPath expression is
defined. defined.
6.4.1.1. Examples 6.4.1.1. Examples
Given the following module: Given the following module:
module example-a { module example-a {
yang-version 1.1;
namespace urn:example:a; namespace urn:example:a;
prefix a; prefix a;
container a { container a {
list b { list b {
key id; key id;
leaf id { leaf id {
type string; type string;
} }
notification down { notification down {
skipping to change at page 48, line 28 skipping to change at page 49, line 37
// possibly other top-level nodes here // possibly other top-level nodes here
The accessible tree for an action invocation of "reset" on /a/ The accessible tree for an action invocation of "reset" on /a/
b[id="1"] with the "when" parameter set to "10" would be: b[id="1"] with the "when" parameter set to "10" would be:
<a xmlns="urn:example:a"> <a xmlns="urn:example:a">
<b> <b>
<id>1</id> <id>1</id>
<reset> <reset>
<delay>10</delay> <delay>10</delay>
</down> </reset>
</b> </b>
<b> <b>
<id>2</id> <id>2</id>
</b> </b>
</a> </a>
// possibly other top-level nodes here // possibly other top-level nodes here
The accessible tree for the action output of this action is: The accessible tree for the action output of this action is:
<a xmlns="urn:example:a"> <a xmlns="urn:example:a">
skipping to change at page 52, line 28 skipping to change at page 54, line 28
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 to refer to definitions contained in the
module, e.g., "if:ifName". A prefix follows the same rules as an module, e.g., "if:ifName". A prefix follows the same rules as 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 to be used when this module is imported. To defines the prefix suggested to be used when this module is imported.
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, 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 is used in
combination with a colon (":") and the identifier, e.g., combination with a colon (":") and the identifier, e.g.,
"if:ifIndex". To improve readability of YANG modules, the prefix "if:ifIndex". To improve readability of YANG modules, the prefix
defined by a module SHOULD be used when the module is imported, defined by a module SHOULD be used when the module is imported,
skipping to change at page 56, line 11 skipping to change at page 58, line 11
+--------------+---------+-------------+ +--------------+---------+-------------+
7.1.10. Usage Example 7.1.10. Usage Example
module example-system { module example-system {
yang-version 1.1; yang-version 1.1;
namespace "urn:example:system"; namespace "urn:example:system";
prefix "sys"; prefix "sys";
import ietf-yang-types { import ietf-yang-types {
prefix "yang"; prefix "yang";
reference "RFC 6991: Common YANG Data Types";
} }
include example-types; include example-types;
organization "Example Inc."; organization "Example Inc.";
contact contact
"Joe L. User "Joe L. User
Example Inc. Example Inc.
42 Anywhere Drive 42 Anywhere Drive
skipping to change at page 78, line 5 skipping to change at page 80, line 5
leaf-list cipher { leaf-list cipher {
type string; type string;
ordered-by user; ordered-by user;
description description
"A list of ciphers"; "A list of ciphers";
} }
The following would be used to insert a new cipher "blowfish-cbc" The following would be used to insert a new cipher "blowfish-cbc"
after "3des-cbc": after "3des-cbc":
<rpc message-id="101" <rpc message-id="102"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:yang="urn:ietf:params:xml:ns:yang:1"> xmlns:yang="urn:ietf:params:xml:ns:yang:1">
<edit-config> <edit-config>
<target> <target>
<running/> <running/>
</target> </target>
<config> <config>
<system xmlns="urn:example:config"> <system xmlns="urn:example:config">
<services> <services>
skipping to change at page 84, line 26 skipping to change at page 86, line 26
<type>admin</type> <type>admin</type>
<full-name>Barney Rubble</full-name> <full-name>Barney Rubble</full-name>
</user> </user>
</system> </system>
</config> </config>
</edit-config> </edit-config>
</rpc> </rpc>
To change the type of "fred" to "superuser": To change the type of "fred" to "superuser":
<rpc message-id="101" <rpc message-id="102"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"> xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
<edit-config> <edit-config>
<target> <target>
<running/> <running/>
</target> </target>
<config> <config>
<system xmlns="urn:example:config"> <system xmlns="urn:example:config">
<user> <user>
<name>fred</name> <name>fred</name>
skipping to change at page 86, line 5 skipping to change at page 88, line 5
<type>admin</type> <type>admin</type>
</user> </user>
</system> </system>
</config> </config>
</edit-config> </edit-config>
</rpc> </rpc>
The following would be used to move the user "barney rubble" before The following would be used to move the user "barney rubble" before
the user "fred flintstone": the user "fred flintstone":
<rpc message-id="101" <rpc message-id="102"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:yang="urn:ietf:params:xml:ns:yang:1"> xmlns:yang="urn:ietf:params:xml:ns:yang:1">
<edit-config> <edit-config>
<target> <target>
<running/> <running/>
</target> </target>
<config> <config>
<system xmlns="urn:example:config" <system xmlns="urn:example:config"
xmlns:ex="urn:example:config"> xmlns:ex="urn:example:config">
skipping to change at page 86, line 41 skipping to change at page 88, line 41
which may exist at any one time. The argument is an identifier, which may exist at any one time. The argument is an identifier,
followed by a block of substatements that holds detailed choice followed by a block of substatements that holds detailed choice
information. The identifier is used to identify the choice node in information. The identifier is used to identify the choice node in
the schema tree. A choice node does not exist in the data tree. 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, defined with the "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, the Since only one of the choice's cases can be valid at any time in the
creation of a node from one case implicitly deletes all nodes from data tree, the creation of a node from one case implicitly deletes
all other cases. If a request creates a node from a case, the server all nodes from all other cases. If a request creates a node from a
will delete any existing nodes that are defined in other cases inside case, the server will delete any existing nodes that are defined in
the choice. other cases inside the choice.
7.9.1. The choice's Substatements 7.9.1. The choice'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 |
| case | 7.9.2 | 0..n | | case | 7.9.2 | 0..n |
| choice | 7.9 | 0..n | | choice | 7.9 | 0..n |
| config | 7.21.1 | 0..1 | | config | 7.21.1 | 0..1 |
skipping to change at page 94, line 12 skipping to change at page 96, line 12
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, it is
RECOMMENDED that the "anyxml" statement not be used to define RECOMMENDED that the "anyxml" statement 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 model is not known at design time. In these but the exact YANG data model is not known at design time. In these
situations, it is RECOMMENDED to use anydata (Section 7.10) instead situations, it is RECOMMENDED to use anydata (Section 7.10) instead
of anyxml. 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 |
skipping to change at page 98, line 43 skipping to change at page 100, line 43
"mandatory" statement. "mandatory" statement.
o A container node may get a "presence" statement. o A container node may get a "presence" statement.
o A leaf, leaf-list, list, container, anydata, or anyxml node may o A leaf, leaf-list, list, container, anydata, or anyxml node may
get additional "must" expressions. get additional "must" expressions.
o A leaf-list or list node may get a different "min-elements" or o A leaf-list or list node may get a different "min-elements" or
"max-elements" statement. "max-elements" statement.
o A leaf, leaf-list, list, container, anydata, or anyxml node may o A leaf, leaf-list, list, container, choice, case, anydata, or
get additional "if-feature" expressions. anyxml node may get additional "if-feature" expressions.
o Any node can get refined extensions, if the extension allows o Any node can get refined extensions, if the extension allows
refinement. See Section 7.19 for details. refinement. See Section 7.19 for details.
7.13.3. XML Encoding Rules 7.13.3. XML Encoding Rules
Each node in the grouping is encoded as if it was defined inline, Each node in the grouping is encoded as if it was defined inline,
even if it is imported from another module with another XML even if it is imported from another module with another XML
namespace. namespace.
skipping to change at page 101, line 26 skipping to change at page 103, line 26
this value in the same cases as described in Section 7.6.1. In these this value in the same cases as described in Section 7.6.1. In these
cases, the server MUST operationally behave as if the leaf was cases, the server MUST operationally behave as if the leaf was
present in the RPC invocation with the default value as its value. present in the RPC invocation with the default value as its value.
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.
If a "config" statement is present for any node in the input tree, Since the input tree is not part of any datastore, all "config"
the "config" statement is 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, then
this node MUST NOT be present in the input tree. 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 |
skipping to change at page 102, line 26 skipping to change at page 104, line 26
this value in the same cases as described in Section 7.6.1. In these this value in the same cases as described in Section 7.6.1. In these
cases, the client MUST operationally behave as if the leaf was cases, the client MUST operationally behave as if the leaf was
present in the RPC reply with the default value as its value. present in the RPC reply with the default value as its value.
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.
If a "config" statement is present for any node in the output tree, Since the output tree is not part of any datastore, all "config"
the "config" statement is 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, then
this node MUST NOT be present in the output tree. 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 |
skipping to change at page 104, line 36 skipping to change at page 106, line 36
schema node with the name "output" are also defined. The nodes schema node with the name "output" are also defined. The nodes
"input" and "output" are defined in the module's namespace. "input" and "output" are defined in the module's namespace.
An action MUST NOT be defined within an rpc, another action or a An action MUST NOT be defined within an rpc, another action or a
notification, i.e., an action node MUST NOT have an rpc, action, or a notification, i.e., an action node MUST NOT have an rpc, action, or a
notification node as one of its ancestors in the schema tree. For notification node as one of its ancestors in the schema tree. For
example, this means that it is an error if a grouping that contains example, this means that it is an error if a grouping that contains
an action somewhere in its node hierarchy is used in a notification an action somewhere in its node hierarchy is used in a notification
definition. definition.
Since an action cannot be defined an the top-level of a module or in An action MUST NOT have any ancestor node that is a list node without
a "key" statement.
Since an action cannot be defined at the top-level of a module or in
a case statement, it is an error if a grouping that contains an a case statement, it is an error if a grouping that contains an
action at the top of its node hierarchy is used at the top-level of a action at the top of its node hierarchy is used at the top-level of a
module or in a case definition. module or in a case definition.
The difference between an action and an rpc is that an action is tied The difference between an action and an rpc is that an action is tied
to a node in the datastore, whereas an rpc is not. When an action is to a node in the datastore, whereas an rpc is not. When an action is
invoked, the node in the datastore is specified along with the name invoked, the node in the datastore is specified along with the name
of the action and the input parameters. of the action and the input parameters.
7.15.1. The action's Substatements 7.15.1. The action's Substatements
skipping to change at page 105, line 27 skipping to change at page 107, line 30
7.15.2. NETCONF XML Encoding Rules 7.15.2. NETCONF XML Encoding Rules
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 from the top level down to the list or container containing the nodes in the direct path from the top level down to the list or
action. For lists, all key leafs MUST also be included. The last container containing the action. For lists, all key leafs MUST also
container or list contains an XML element that carries the name of be included. The last container or list contains an XML element that
the defined action. Within this element the input parameters are carries the name of the defined action. Within this element the
encoded as child XML elements, in the same order as they are defined input parameters are encoded as child XML elements, in the same order
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,
they are encoded as child elements to the <rpc-reply> element defined they are encoded as child elements to the <rpc-reply> element defined
in [RFC6241], in the same order as they are defined within the in [RFC6241], in the same order as they are defined within the
skipping to change at page 107, line 43 skipping to change at page 109, line 43
connected to a specific container or list data node in the schema connected to a specific container or list data node in the schema
tree. tree.
A notification MUST NOT be defined within an rpc, action or another A notification MUST NOT be defined within an rpc, action or another
notification, i.e., a notification node MUST NOT have an rpc, action, notification, i.e., a notification node MUST NOT have an rpc, action,
or a notification node as one of its ancestors in the schema tree. or a notification node as one of its ancestors in the schema tree.
For example, this means that it is an error if a grouping that For example, this means that it is an error if a grouping that
contains an notification somewhere in its node hierarchy is used in contains an notification somewhere in its node hierarchy is used in
an rpc definition. an rpc definition.
A notification MUST NOT have any ancestor node that is a list node
without a "key" statement.
Since a notification cannot be defined in a case statement, it is an Since a notification cannot be defined in a case statement, it is an
error if a grouping that contains a notification at the top of its error if a grouping that contains a notification at the top of its
node hierarchy is used in a case definition. node hierarchy is used in a case definition.
If a leaf in the notification tree has a "mandatory" statement with If a leaf in the notification tree has a "mandatory" statement with
the value "true", the leaf MUST be present in a notification the value "true", the leaf MUST be present in a notification
instance. instance.
If a leaf in the notification tree has a default value, the client If a leaf in the notification tree has a default value, the client
MUST use this value in the same cases as described in Section 7.6.1. MUST use this value in the same cases as described in Section 7.6.1.
skipping to change at page 108, line 15 skipping to change at page 110, line 17
In these cases, the client MUST operationally behave as if the leaf In these cases, the client MUST operationally behave as if the leaf
was present in the notification instance with the default value as was present in the notification instance with the default value as
its value. its value.
If a leaf-list in the notification tree has one or more default If a leaf-list in the notification tree has one or more default
values, the client MUST use these values in the same cases as values, the client MUST use these values in the same cases as
described in Section 7.7.2. In these cases, the client MUST described in Section 7.7.2. In these cases, the client MUST
operationally behave as if the leaf-list was present in the operationally behave as if the leaf-list was present in the
notification instance with the default values as its values. notification instance with the default values as its values.
If a "config" statement is present for any node in the notification Since the notification tree is not part of any datastore, all
tree, the "config" statement is ignored. "config" statements for nodes in the notification tree are ignored.
7.16.1. The notification's Substatements 7.16.1. The notification'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 |
skipping to change at page 112, line 6 skipping to change at page 114, line 6
defining the "when" expression, so that clients that do not know defining the "when" expression, so that clients that do not know
about the augmenting module do not break. about the augmenting module do not break.
In the following example, it is OK to augment the "interface" entry In the following example, it is OK to augment the "interface" entry
with "mandatory-leaf" because the augmentation depends on support for with "mandatory-leaf" because the augmentation depends on support for
"some-new-iftype". The old client does not know about this type so "some-new-iftype". The old client does not know about this type so
it would never select this type, and therefore not be adding a it would never select this type, and therefore not be adding a
mandatory data node. mandatory data node.
module example-augment { module example-augment {
yang-version 1.1;
namespace "urn:example:augment"; namespace "urn:example:augment";
prefix mymod; prefix mymod;
import ietf-interfaces { import ietf-interfaces {
prefix if; prefix if;
} }
identity some-new-iftype { identity some-new-iftype {
base if:interface-type; base if:interface-type;
} }
augment "/if:interfaces/if:interface" { augment "/if:interfaces/if:interface" {
when "if:type = 'mymod:some-new-iftype'"; when 'derived-from-or-self(if:type, "mymod:some-new-iftype")';
leaf mandatory-leaf { leaf mandatory-leaf {
mandatory true; mandatory true;
type string; type string;
} }
} }
} }
7.17.1. The augment's Substatements 7.17.1. The augment's Substatements
skipping to change at page 121, line 36 skipping to change at page 123, line 36
} }
} }
The "if-feature" statement can be used in many places within the YANG The "if-feature" statement can be used in many places within the YANG
syntax. Definitions tagged with "if-feature" are ignored when the syntax. Definitions tagged with "if-feature" are ignored when the
server does not support that feature. server does not support that feature.
A feature MUST NOT reference itself, neither directly nor indirectly A feature MUST NOT reference itself, neither directly nor indirectly
through a chain of other features. through a chain of other features.
In order for a server to implement a feature that is dependent on any In order for a server to support a feature that is dependent on any
other features (i.e., the feature has one or more "if-feature" other features (i.e., the feature has one or more "if-feature"
substatements), the server MUST also implement all the dependant substatements), the server MUST also support all the dependant
features. features.
7.20.1.1. The feature's Substatements 7.20.1.1. The feature's Substatements
+--------------+---------+-------------+ +--------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+--------------+---------+-------------+ +--------------+---------+-------------+
| 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 |
| status | 7.21.2 | 0..1 | | status | 7.21.2 | 0..1 |
| reference | 7.21.4 | 0..1 | | reference | 7.21.4 | 0..1 |
+--------------+---------+-------------+ +--------------+---------+-------------+
7.20.2. The if-feature Statement 7.20.2. The if-feature Statement
The "if-feature" statement makes its parent statement conditional. The "if-feature" statement makes its parent statement conditional.
The argument is a boolean expression over feature names. In this The argument is a boolean expression over feature names. In this
expression, a feature name evaluates to "true" if and only if the expression, a feature name evaluates to "true" if and only if the
feature is implemented by the server. The parent statement is feature is supported by the server. The parent statement is
implemented by servers where the boolean expression evaluates to implemented by servers where the boolean expression evaluates to
"true". "true".
The if-feature boolean expression syntax is formally defined by the The if-feature boolean expression syntax is formally defined by the
rule "if-feature-expr" in Section 14. Parenthesis are used to group rule "if-feature-expr" in Section 14. Parenthesis are used to group
expressions. When the expression is evaluated, the order of expressions. When the expression is evaluated, the order of
precedence is (highest precedence first): grouping (parenthesis), precedence is (highest precedence first): grouping (parenthesis),
"not", "and", "or". "not", "and", "or".
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 any of the
features "outbound-tls" or "outbound-ssh" is implemented by 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 130, line 28 skipping to change at page 132, line 28
o The "min-elements" and "max-elements" constraints are enforced for o The "min-elements" and "max-elements" constraints are enforced for
lists and leaf-lists, unless the node or any of its ancestors has lists and leaf-lists, unless the node or any of its ancestors has
a "when" condition or "if-feature" expression that evaluates to a "when" condition or "if-feature" expression that evaluates to
"false". "false".
The running configuration datastore MUST always be valid. The running configuration datastore MUST always be valid.
8.2. Configuration Data Modifications 8.2. Configuration Data Modifications
o If a request creates configuration data nodes under a "choice", o If a request creates configuration data nodes under a "choice",
any existing nodes from other "case" branches are deleted by the any existing nodes from other "case" branches in the data tree are
server. deleted by the server.
o If a request modifies a configuration data node such that any o If a request modifies a configuration data node such that any
node's "when" expression becomes false, then the node with the node's "when" expression becomes false, then the node in the data
"when" expression is deleted by the server. tree with the "when" expression is deleted by the server.
8.3. NETCONF Constraint Enforcement Model 8.3. NETCONF Constraint Enforcement Model
For configuration data, there are three windows when constraints MUST For configuration data, there are three windows when constraints MUST
be enforced: be enforced:
o during parsing of RPC payloads o during parsing of RPC payloads
o during processing of NETCONF operations o during processing of the <edit-config> operation
o during validation o during validation
Each of these scenarios is considered in the following sections. Each of these scenarios is considered in the following sections.
8.3.1. Payload Parsing 8.3.1. Payload Parsing
When content arrives in RPC payloads, it MUST be well-formed XML, When content arrives in RPC payloads, it MUST be well-formed XML,
following the hierarchy and content rules defined by the set of following the hierarchy and content rules defined by the set of
models the server implements. models the server implements.
skipping to change at page 132, line 42 skipping to change at page 134, line 42
ranges in YANG modules. ranges in YANG modules.
9.1. Canonical Representation 9.1. Canonical Representation
For most types, there is a single canonical representation of the For most types, there is a single canonical representation of the
type's values. Some types allow multiple lexical representations of type's values. Some types allow multiple lexical representations of
the same value, for example, the positive integer "17" can be the same value, for example, the positive integer "17" can be
represented as "+17" or "17". Implementations MUST support all represented as "+17" or "17". Implementations MUST support all
lexical representations specified in this document. lexical representations specified in this document.
When a server sends data encoded in XML, it MUST use the canonical When a server sends XML encoded data, it MUST use the canonical form
form defined in this section. Other encodings may introduce defined in this section. Other encodings may introduce alternate
alternate representations. Note, however, that values in the data representations. Note, however, that values in the data tree are
tree are conceptually stored in the canonical representation as conceptually stored in the canonical representation as defined in
defined in this section. In particular, any XPath expression this section. In particular, any XPath expression evaluations are
evaluations are done using the canonical form, if the data type has a done using the canonical form, if the data type has a canonical form.
canonical form. If the data type does not have a canonical form, the If the data type does not have a canonical form, the format of the
format of the value MUST match the data type's lexical value MUST match the data type's lexical representation, but the
representation, but the exact format is implementation dependent. exact format is implementation dependent.
Some types have a lexical representation that depends on the Some types have a lexical representation that depends on the
encoding, e.g., the XML context in which they occur. These types do encoding, e.g., the XML context in which they occur. These types do
not have a canonical form. not have a canonical form.
9.2. The Integer Built-In Types 9.2. The Integer Built-In Types
The integer built-in types are int8, int16, int32, int64, uint8, The integer built-in types are int8, int16, int32, int64, uint8,
uint16, uint32, and uint64. They represent signed and unsigned uint16, uint32, and uint64. They represent signed and unsigned
integers of different sizes: integers of different sizes:
skipping to change at page 159, line 36 skipping to change at page 161, line 36
/ex:system/ex:service[ex:name='foo'][ex:enabled=''] /ex:system/ex:service[ex:name='foo'][ex:enabled='']
/* instance-identifier for a leaf-list entry */ /* instance-identifier for a leaf-list entry */
/ex:system/ex:services/ex:ssh/ex:cipher[.='blowfish-cbc'] /ex:system/ex:services/ex:ssh/ex:cipher[.='blowfish-cbc']
/* instance-identifier for a list entry without keys */ /* instance-identifier for a list entry without keys */
/ex:stats/ex:port[3] /ex:stats/ex:port[3]
10. XPath Functions 10. XPath Functions
This document defines two generic XPath functions and four YANG type- This document defines two generic XPath functions and five YANG type-
specific XPath functions. The function signatures are specified with specific XPath functions. The function signatures are specified with
the syntax used in [XPATH]. the syntax used in [XPATH].
10.1. Functions for Node Sets 10.1. Functions for Node Sets
10.1.1. current() 10.1.1. current()
node-set current() node-set current()
The function current() takes no input parameters, and returns a node The function current() takes no input parameters, and returns a node
skipping to change at page 160, line 46 skipping to change at page 162, line 46
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)
The deref() function follows the reference defined by the first node The deref() function follows the reference defined by the first node
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.
skipping to change at page 169, line 9 skipping to change at page 171, line 9
A YANG version 1 module or submodule MUST NOT import a YANG version A YANG version 1 module or submodule MUST NOT import a YANG version
1.1 module by revision. 1.1 module by revision.
A YANG version 1.1 module or submodule MAY import a YANG version 1 A YANG version 1.1 module or submodule MAY import a YANG version 1
module by revision. module by revision.
If a YANG version 1 module A imports module B without revision, and If a YANG version 1 module A imports module B without revision, and
module B is updated to YANG version 1.1, a server MAY implement both module B is updated to YANG version 1.1, a server MAY implement both
these modules (A and B) at the same time. In such cases, a NETCONF these modules (A and B) at the same time. In such cases, a NETCONF
server MUST advertise both modules using the rules defined in server MUST advertise both modules using the rules defined in
Section 5.6.5, and SHOULD advertise module A and the latest revision Section 5.6.4, and SHOULD advertise module A and the latest revision
of module B that is specified with YANG version 1 according to the of module B that is specified with YANG version 1 according to the
rules defined in [RFC6020]. rules defined in [RFC6020].
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
skipping to change at page 186, line 6 skipping to change at page 188, line 6
*uses-augment-stmt *uses-augment-stmt
"}") stmtsep "}") stmtsep
refine-stmt = refine-keyword sep refine-arg-str optsep refine-stmt = refine-keyword sep refine-arg-str optsep
"{" stmtsep "{" stmtsep
;; these stmts can appear in any order ;; these stmts can appear in any order
*if-feature-stmt *if-feature-stmt
*must-stmt *must-stmt
[presence-stmt] [presence-stmt]
[default-stmt] *default-stmt
[config-stmt] [config-stmt]
[mandatory-stmt] [mandatory-stmt]
[min-elements-stmt] [min-elements-stmt]
[max-elements-stmt] [max-elements-stmt]
[description-stmt] [description-stmt]
[reference-stmt] [reference-stmt]
"}" stmtsep "}" stmtsep
refine-arg-str = < a string that matches the rule > refine-arg-str = < a string that matches the rule >
< refine-arg > < refine-arg >
skipping to change at page 188, line 49 skipping to change at page 190, line 49
deviate-keyword sep deviate-keyword sep
not-supported-keyword-str stmtend not-supported-keyword-str stmtend
deviate-add-stmt = deviate-keyword sep add-keyword-str optsep deviate-add-stmt = deviate-keyword sep add-keyword-str optsep
(";" / (";" /
"{" stmtsep "{" stmtsep
;; these stmts can appear in any order ;; these stmts can appear in any order
[units-stmt] [units-stmt]
*must-stmt *must-stmt
*unique-stmt *unique-stmt
[default-stmt] *default-stmt
[config-stmt] [config-stmt]
[mandatory-stmt] [mandatory-stmt]
[min-elements-stmt] [min-elements-stmt]
[max-elements-stmt] [max-elements-stmt]
"}") stmtsep "}") stmtsep
deviate-delete-stmt = deviate-keyword sep delete-keyword-str optsep deviate-delete-stmt = deviate-keyword sep delete-keyword-str optsep
(";" / (";" /
"{" stmtsep "{" stmtsep
;; these stmts can appear in any order ;; these stmts can appear in any order
[units-stmt] [units-stmt]
*must-stmt *must-stmt
*unique-stmt *unique-stmt
[default-stmt] *default-stmt
"}") stmtsep "}") stmtsep
deviate-replace-stmt = deviate-keyword sep replace-keyword-str optsep deviate-replace-stmt = deviate-keyword sep replace-keyword-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]
[config-stmt] [config-stmt]
skipping to change at page 192, line 27 skipping to change at page 194, line 27
absolute-schema-nodeid = 1*("/" node-identifier) absolute-schema-nodeid = 1*("/" node-identifier)
descendant-schema-nodeid = descendant-schema-nodeid =
node-identifier node-identifier
[absolute-schema-nodeid] [absolute-schema-nodeid]
node-identifier = [prefix ":"] identifier node-identifier = [prefix ":"] identifier
;; Instance Identifiers ;; Instance Identifiers
instance-identifier = 1*("/" (node-identifier *predicate)) instance-identifier = 1*("/" (node-identifier
[1*key-predicate /
leaf-list-predicate /
pos]))
predicate = "[" *WSP (predicate-expr / pos) *WSP "]" key-predicate = "[" *WSP key-predicate-expr *WSP "]"
predicate-expr = (node-identifier / ".") *WSP "=" *WSP key-predicate-expr = node-identifier *WSP "=" *WSP quoted-string
((DQUOTE string DQUOTE) /
(SQUOTE string SQUOTE))
pos = non-negative-integer-value leaf-list-predicate = "[" *WSP leaf-list-predicate-expr *WSP "]"
leaf-list-predicate-expr = "." *WSP "=" *WSP quoted-string
pos = "[" *WSP positive-integer-value *WSP "]"
quoted-string = (DQUOTE string DQUOTE) / (SQUOTE string SQUOTE)
;; leafref path ;; leafref path
path-arg-str = < a string that matches the rule > path-arg-str = < a string that matches the rule >
< path-arg > < path-arg >
path-arg = absolute-path / relative-path path-arg = absolute-path / relative-path
absolute-path = 1*("/" (node-identifier *path-predicate)) absolute-path = 1*("/" (node-identifier *path-predicate))
relative-path = 1*("../") descendant-path relative-path = 1*("../") descendant-path
descendant-path = node-identifier descendant-path = node-identifier
[*path-predicate absolute-path] [*path-predicate absolute-path]
path-predicate = "[" *WSP path-equality-expr *WSP "]" path-predicate = "[" *WSP path-equality-expr *WSP "]"
path-equality-expr = node-identifier *WSP "=" *WSP path-key-expr path-equality-expr = node-identifier *WSP "=" *WSP path-key-expr
path-key-expr = current-function-invocation *WSP "/" *WSP path-key-expr = current-function-invocation *WSP "/" *WSP
skipping to change at page 203, line 42 skipping to change at page 205, line 42
o Updated YANG version to 1.1, and made the "yang-version" statement o Updated YANG version to 1.1, and made the "yang-version" statement
mandatory. mandatory.
21. References 21. References
21.1. Normative References 21.1. Normative References
[I-D.ietf-netconf-yang-library] [I-D.ietf-netconf-yang-library]
Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module
Library", draft-ietf-netconf-yang-library-04 (work in Library", draft-ietf-netconf-yang-library-06 (work in
progress), February 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/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 205, line 15 skipping to change at page 207, line 15
[XSD-TYPES] [XSD-TYPES]
Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes
Second Edition", World Wide Web Consortium Recommendation Second Edition", World Wide Web Consortium Recommendation
REC-xmlschema-2-20041028, October 2004, REC-xmlschema-2-20041028, October 2004,
<http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>. <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
21.2. Informative References 21.2. Informative References
[I-D.ietf-netconf-restconf] [I-D.ietf-netconf-restconf]
Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", draft-ietf-netconf-restconf-09 (work in Protocol", draft-ietf-netconf-restconf-13 (work in
progress), December 2015. progress), April 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-07 (work in progress), January draft-ietf-netmod-yang-json-10 (work in progress), March
2016. 2016.
[I-D.vanderstok-core-comi] [I-D.vanderstok-core-comi]
Stok, P., Bierman, A., Schoenwaelder, J., and A. Sehgal, Stok, P. and A. Bierman, "CoAP Management Interface",
"CoAP Management Interface", draft-vanderstok-core-comi-08 draft-vanderstok-core-comi-09 (work in progress), March
(work in progress), October 2015. 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/RFC2578, April 1999, DOI 10.17487/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 58, RFC 2579, DOI 10.17487/RFC2579, April 1999, STD 58, RFC 2579, DOI 10.17487/RFC2579, April 1999,
skipping to change at page 206, line 10 skipping to change at page 208, line 10
[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>.
[RFC6643] Schoenwaelder, J., "Translation of Structure of Management [RFC6643] Schoenwaelder, J., "Translation of Structure of Management
Information Version 2 (SMIv2) MIB Modules to YANG Information Version 2 (SMIv2) MIB Modules to YANG
Modules", RFC 6643, DOI 10.17487/RFC6643, July 2012, Modules", RFC 6643, DOI 10.17487/RFC6643, July 2012,
<http://www.rfc-editor.org/info/rfc6643>. <http://www.rfc-editor.org/info/rfc6643>.
[RFC6691] Borman, D., "TCP Options and Maximum Segment Size (MSS)",
RFC 6691, DOI 10.17487/RFC6691, July 2012,
<http://www.rfc-editor.org/info/rfc6691>.
[XPATH2.0] [XPATH2.0]
Berglund, A., Boag, S., Chamberlin, D., Fernandez, M., Berglund, A., Boag, S., Chamberlin, D., Fernandez, M.,
Kay, M., Robie, J., and J. Simeon, "XML Path Language Kay, M., Robie, J., and J. Simeon, "XML Path Language
(XPath) 2.0 (Second Edition)", World Wide Web Consortium (XPath) 2.0 (Second Edition)", World Wide Web Consortium
Recommendation REC-xpath20-20101214, December 2010, Recommendation REC-xpath20-20101214, December 2010,
<http://www.w3.org/TR/2010/REC-xpath20-20101214>. <http://www.w3.org/TR/2010/REC-xpath20-20101214>.
[XSLT] Clark, J., "XSL Transformations (XSLT) Version 1.0", World [XSLT] Clark, J., "XSL Transformations (XSLT) Version 1.0", World
Wide Web Consortium Recommendation REC-xslt-19991116, Wide Web Consortium Recommendation REC-xslt-19991116,
November 1999, November 1999,
 End of changes. 77 change blocks. 
421 lines changed or deleted 477 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/