draft-ietf-netmod-rfc6020bis-08.txt   draft-ietf-netmod-rfc6020bis-09.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 October 19, 2015 Intended status: Standards Track December 11, 2015
Expires: April 21, 2016 Expires: June 13, 2016
The YANG 1.1 Data Modeling Language The YANG 1.1 Data Modeling Language
draft-ietf-netmod-rfc6020bis-08 draft-ietf-netmod-rfc6020bis-09
Abstract Abstract
YANG is a data modeling language used to model configuration data, YANG is a data modeling language used to model configuration data,
state data, remote procedure calls, and notifications for network state data, remote procedure calls, and notifications for network
management protocols like the Network Configuration Protocol management protocols like the Network Configuration Protocol
(NETCONF). (NETCONF).
Status of This Memo Status of This Memo
skipping to change at page 1, line 33 skipping to change at page 1, line 33
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 21, 2016. This Internet-Draft will expire on June 13, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 10 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 10
4. YANG Overview . . . . . . . . . . . . . . . . . . . . . . . . 13 4. YANG Overview . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1. Functional Overview . . . . . . . . . . . . . . . . . . . 13 4.1. Functional Overview . . . . . . . . . . . . . . . . . . . 13
4.2. Language Overview . . . . . . . . . . . . . . . . . . . . 15 4.2. Language Overview . . . . . . . . . . . . . . . . . . . . 15
4.2.1. Modules and Submodules . . . . . . . . . . . . . . . 15 4.2.1. Modules and Submodules . . . . . . . . . . . . . . . 15
4.2.2. Data Modeling Basics . . . . . . . . . . . . . . . . 15 4.2.2. Data Modeling Basics . . . . . . . . . . . . . . . . 16
4.2.3. State Data . . . . . . . . . . . . . . . . . . . . . 19 4.2.3. State Data . . . . . . . . . . . . . . . . . . . . . 19
4.2.4. Built-In Types . . . . . . . . . . . . . . . . . . . 20 4.2.4. Built-In Types . . . . . . . . . . . . . . . . . . . 20
4.2.5. Derived Types (typedef) . . . . . . . . . . . . . . . 21 4.2.5. Derived Types (typedef) . . . . . . . . . . . . . . . 21
4.2.6. Reusable Node Groups (grouping) . . . . . . . . . . . 22 4.2.6. Reusable Node Groups (grouping) . . . . . . . . . . . 22
4.2.7. Choices . . . . . . . . . . . . . . . . . . . . . . . 23 4.2.7. Choices . . . . . . . . . . . . . . . . . . . . . . . 23
4.2.8. Extending Data Models (augment) . . . . . . . . . . . 24 4.2.8. Extending Data Models (augment) . . . . . . . . . . . 24
4.2.9. Operation Definitions . . . . . . . . . . . . . . . . 25 4.2.9. Operation Definitions . . . . . . . . . . . . . . . . 25
4.2.10. Notification Definitions . . . . . . . . . . . . . . 27 4.2.10. Notification Definitions . . . . . . . . . . . . . . 27
5. Language Concepts . . . . . . . . . . . . . . . . . . . . . . 28 5. Language Concepts . . . . . . . . . . . . . . . . . . . . . . 28
5.1. Modules and Submodules . . . . . . . . . . . . . . . . . 28 5.1. Modules and Submodules . . . . . . . . . . . . . . . . . 28
skipping to change at page 3, line 14 skipping to change at page 3, line 14
6.1. Lexical Tokenization . . . . . . . . . . . . . . . . . . 39 6.1. Lexical Tokenization . . . . . . . . . . . . . . . . . . 39
6.1.1. Comments . . . . . . . . . . . . . . . . . . . . . . 39 6.1.1. Comments . . . . . . . . . . . . . . . . . . . . . . 39
6.1.2. Tokens . . . . . . . . . . . . . . . . . . . . . . . 39 6.1.2. Tokens . . . . . . . . . . . . . . . . . . . . . . . 39
6.1.3. Quoting . . . . . . . . . . . . . . . . . . . . . . . 39 6.1.3. Quoting . . . . . . . . . . . . . . . . . . . . . . . 39
6.2. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 41 6.2. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 41
6.2.1. Identifiers and Their Namespaces . . . . . . . . . . 41 6.2.1. Identifiers and Their Namespaces . . . . . . . . . . 41
6.3. Statements . . . . . . . . . . . . . . . . . . . . . . . 42 6.3. Statements . . . . . . . . . . . . . . . . . . . . . . . 42
6.3.1. Language Extensions . . . . . . . . . . . . . . . . . 42 6.3.1. Language Extensions . . . . . . . . . . . . . . . . . 42
6.4. XPath Evaluations . . . . . . . . . . . . . . . . . . . . 42 6.4. XPath Evaluations . . . . . . . . . . . . . . . . . . . . 42
6.4.1. XPath Context . . . . . . . . . . . . . . . . . . . . 43 6.4.1. XPath Context . . . . . . . . . . . . . . . . . . . . 43
6.5. Schema Node Identifier . . . . . . . . . . . . . . . . . 45 6.5. Schema Node Identifier . . . . . . . . . . . . . . . . . 48
7. YANG Statements . . . . . . . . . . . . . . . . . . . . . . . 45 7. YANG Statements . . . . . . . . . . . . . . . . . . . . . . . 48
7.1. The module Statement . . . . . . . . . . . . . . . . . . 46 7.1. The module Statement . . . . . . . . . . . . . . . . . . 49
7.1.1. The module's Substatements . . . . . . . . . . . . . 46 7.1.1. The module's Substatements . . . . . . . . . . . . . 49
7.1.2. The yang-version Statement . . . . . . . . . . . . . 47 7.1.2. The yang-version Statement . . . . . . . . . . . . . 50
7.1.3. The namespace Statement . . . . . . . . . . . . . . . 48 7.1.3. The namespace Statement . . . . . . . . . . . . . . . 51
7.1.4. The prefix Statement . . . . . . . . . . . . . . . . 48 7.1.4. The prefix Statement . . . . . . . . . . . . . . . . 51
7.1.5. The import Statement . . . . . . . . . . . . . . . . 48 7.1.5. The import Statement . . . . . . . . . . . . . . . . 51
7.1.6. The include Statement . . . . . . . . . . . . . . . . 49 7.1.6. The include Statement . . . . . . . . . . . . . . . . 52
7.1.7. The organization Statement . . . . . . . . . . . . . 50 7.1.7. The organization Statement . . . . . . . . . . . . . 53
7.1.8. The contact Statement . . . . . . . . . . . . . . . . 50 7.1.8. The contact Statement . . . . . . . . . . . . . . . . 53
7.1.9. The revision Statement . . . . . . . . . . . . . . . 50 7.1.9. The revision Statement . . . . . . . . . . . . . . . 53
7.1.10. Usage Example . . . . . . . . . . . . . . . . . . . . 51 7.1.10. Usage Example . . . . . . . . . . . . . . . . . . . . 54
7.2. The submodule Statement . . . . . . . . . . . . . . . . . 52 7.2. The submodule Statement . . . . . . . . . . . . . . . . . 55
7.2.1. The submodule's Substatements . . . . . . . . . . . . 53 7.2.1. The submodule's Substatements . . . . . . . . . . . . 56
7.2.2. The belongs-to Statement . . . . . . . . . . . . . . 53 7.2.2. The belongs-to Statement . . . . . . . . . . . . . . 56
7.2.3. Usage Example . . . . . . . . . . . . . . . . . . . . 54 7.2.3. Usage Example . . . . . . . . . . . . . . . . . . . . 57
7.3. The typedef Statement . . . . . . . . . . . . . . . . . . 54 7.3. The typedef Statement . . . . . . . . . . . . . . . . . . 57
7.3.1. The typedef's Substatements . . . . . . . . . . . . . 55 7.3.1. The typedef's Substatements . . . . . . . . . . . . . 58
7.3.2. The typedef's type Statement . . . . . . . . . . . . 55 7.3.2. The typedef's type Statement . . . . . . . . . . . . 58
7.3.3. The units Statement . . . . . . . . . . . . . . . . . 55 7.3.3. The units Statement . . . . . . . . . . . . . . . . . 58
7.3.4. The typedef's default Statement . . . . . . . . . . . 55 7.3.4. The typedef's default Statement . . . . . . . . . . . 58
7.3.5. Usage Example . . . . . . . . . . . . . . . . . . . . 56 7.3.5. Usage Example . . . . . . . . . . . . . . . . . . . . 59
7.4. The type Statement . . . . . . . . . . . . . . . . . . . 56 7.4. The type Statement . . . . . . . . . . . . . . . . . . . 59
7.4.1. The type's Substatements . . . . . . . . . . . . . . 56 7.4.1. The type's Substatements . . . . . . . . . . . . . . 59
7.5. The container Statement . . . . . . . . . . . . . . . . . 56 7.5. The container Statement . . . . . . . . . . . . . . . . . 59
7.5.1. Containers with Presence . . . . . . . . . . . . . . 57 7.5.1. Containers with Presence . . . . . . . . . . . . . . 60
7.5.2. The container's Substatements . . . . . . . . . . . . 57 7.5.2. The container's Substatements . . . . . . . . . . . . 60
7.5.3. The must Statement . . . . . . . . . . . . . . . . . 58 7.5.3. The must Statement . . . . . . . . . . . . . . . . . 61
7.5.4. The must's Substatements . . . . . . . . . . . . . . 59 7.5.4. The must's Substatements . . . . . . . . . . . . . . 62
7.5.5. The presence Statement . . . . . . . . . . . . . . . 60 7.5.5. The presence Statement . . . . . . . . . . . . . . . 63
7.5.6. The container's Child Node Statements . . . . . . . . 60 7.5.6. The container's Child Node Statements . . . . . . . . 63
7.5.7. XML Encoding Rules . . . . . . . . . . . . . . . . . 60 7.5.7. XML Encoding Rules . . . . . . . . . . . . . . . . . 63
7.5.8. NETCONF <edit-config> Operations . . . . . . . . . . 61 7.5.8. NETCONF <edit-config> Operations . . . . . . . . . . 64
7.5.9. Usage Example . . . . . . . . . . . . . . . . . . . . 61 7.5.9. Usage Example . . . . . . . . . . . . . . . . . . . . 64
7.6. The leaf Statement . . . . . . . . . . . . . . . . . . . 62 7.6. The leaf Statement . . . . . . . . . . . . . . . . . . . 65
7.6.1. The leaf's default value . . . . . . . . . . . . . . 62 7.6.1. The leaf's default value . . . . . . . . . . . . . . 65
7.6.2. The leaf's Substatements . . . . . . . . . . . . . . 63 7.6.2. The leaf's Substatements . . . . . . . . . . . . . . 66
7.6.3. The leaf's type Statement . . . . . . . . . . . . . . 63 7.6.3. The leaf's type Statement . . . . . . . . . . . . . . 67
7.6.4. The leaf's default Statement . . . . . . . . . . . . 64 7.6.4. The leaf's default Statement . . . . . . . . . . . . 67
7.6.5. The leaf's mandatory Statement . . . . . . . . . . . 64 7.6.5. The leaf's mandatory Statement . . . . . . . . . . . 67
7.6.6. XML Encoding Rules . . . . . . . . . . . . . . . . . 64 7.6.6. XML Encoding Rules . . . . . . . . . . . . . . . . . 68
7.6.7. NETCONF <edit-config> Operations . . . . . . . . . . 64 7.6.7. NETCONF <edit-config> Operations . . . . . . . . . . 68
7.6.8. Usage Example . . . . . . . . . . . . . . . . . . . . 65 7.6.8. Usage Example . . . . . . . . . . . . . . . . . . . . 68
7.7. The leaf-list Statement . . . . . . . . . . . . . . . . . 66 7.7. The leaf-list Statement . . . . . . . . . . . . . . . . . 69
7.7.1. Ordering . . . . . . . . . . . . . . . . . . . . . . 66 7.7.1. Ordering . . . . . . . . . . . . . . . . . . . . . . 69
7.7.2. The leaf-list's default values . . . . . . . . . . . 67 7.7.2. The leaf-list's default values . . . . . . . . . . . 70
7.7.3. The leaf-list's Substatements . . . . . . . . . . . . 67 7.7.3. The leaf-list's Substatements . . . . . . . . . . . . 71
7.7.4. The leaf-list's default Statement . . . . . . . . . . 68 7.7.4. The leaf-list's default Statement . . . . . . . . . . 71
7.7.5. The min-elements Statement . . . . . . . . . . . . . 68 7.7.5. The min-elements Statement . . . . . . . . . . . . . 72
7.7.6. The max-elements Statement . . . . . . . . . . . . . 69 7.7.6. The max-elements Statement . . . . . . . . . . . . . 72
7.7.7. The ordered-by Statement . . . . . . . . . . . . . . 69 7.7.7. The ordered-by Statement . . . . . . . . . . . . . . 72
7.7.8. XML Encoding Rules . . . . . . . . . . . . . . . . . 69 7.7.8. XML Encoding Rules . . . . . . . . . . . . . . . . . 73
7.7.9. NETCONF <edit-config> Operations . . . . . . . . . . 70 7.7.9. NETCONF <edit-config> Operations . . . . . . . . . . 73
7.7.10. Usage Example . . . . . . . . . . . . . . . . . . . . 71 7.7.10. Usage Example . . . . . . . . . . . . . . . . . . . . 74
7.8. The list Statement . . . . . . . . . . . . . . . . . . . 72 7.8. The list Statement . . . . . . . . . . . . . . . . . . . 76
7.8.1. The list's Substatements . . . . . . . . . . . . . . 72 7.8.1. The list's Substatements . . . . . . . . . . . . . . 76
7.8.2. The list's key Statement . . . . . . . . . . . . . . 73 7.8.2. The list's key Statement . . . . . . . . . . . . . . 77
7.8.3. The list's unique Statement . . . . . . . . . . . . . 74 7.8.3. The list's unique Statement . . . . . . . . . . . . . 78
7.8.4. The list's Child Node Statements . . . . . . . . . . 75 7.8.4. The list's Child Node Statements . . . . . . . . . . 79
7.8.5. XML Encoding Rules . . . . . . . . . . . . . . . . . 75 7.8.5. XML Encoding Rules . . . . . . . . . . . . . . . . . 79
7.8.6. NETCONF <edit-config> Operations . . . . . . . . . . 76 7.8.6. NETCONF <edit-config> Operations . . . . . . . . . . 80
7.8.7. Usage Example . . . . . . . . . . . . . . . . . . . . 77 7.8.7. Usage Example . . . . . . . . . . . . . . . . . . . . 81
7.9. The choice Statement . . . . . . . . . . . . . . . . . . 80 7.9. The choice Statement . . . . . . . . . . . . . . . . . . 84
7.9.1. The choice's Substatements . . . . . . . . . . . . . 80 7.9.1. The choice's Substatements . . . . . . . . . . . . . 84
7.9.2. The choice's case Statement . . . . . . . . . . . . . 81 7.9.2. The choice's case Statement . . . . . . . . . . . . . 85
7.9.3. The choice's default Statement . . . . . . . . . . . 82 7.9.3. The choice's default Statement . . . . . . . . . . . 86
7.9.4. The choice's mandatory Statement . . . . . . . . . . 84 7.9.4. The choice's mandatory Statement . . . . . . . . . . 88
7.9.5. XML Encoding Rules . . . . . . . . . . . . . . . . . 84 7.9.5. XML Encoding Rules . . . . . . . . . . . . . . . . . 88
7.9.6. NETCONF <edit-config> Operations . . . . . . . . . . 84 7.9.6. Usage Example . . . . . . . . . . . . . . . . . . . . 88
7.9.7. Usage Example . . . . . . . . . . . . . . . . . . . . 84 7.10. The anydata Statement . . . . . . . . . . . . . . . . . . 89
7.10. The anydata Statement . . . . . . . . . . . . . . . . . . 85 7.10.1. The anydata's Substatements . . . . . . . . . . . . 90
7.10.1. The anydata's Substatements . . . . . . . . . . . . 86 7.10.2. XML Encoding Rules . . . . . . . . . . . . . . . . . 90
7.10.2. XML Encoding Rules . . . . . . . . . . . . . . . . . 86 7.10.3. NETCONF <edit-config> Operations . . . . . . . . . . 90
7.10.3. NETCONF <edit-config> Operations . . . . . . . . . . 86 7.10.4. Usage Example . . . . . . . . . . . . . . . . . . . 91
7.10.4. Usage Example . . . . . . . . . . . . . . . . . . . 87 7.11. The anyxml Statement . . . . . . . . . . . . . . . . . . 91
7.11. The anyxml Statement . . . . . . . . . . . . . . . . . . 87 7.11.1. The anyxml's Substatements . . . . . . . . . . . . . 92
7.11.1. The anyxml's Substatements . . . . . . . . . . . . . 88 7.11.2. XML Encoding Rules . . . . . . . . . . . . . . . . . 92
7.11.2. XML Encoding Rules . . . . . . . . . . . . . . . . . 88 7.11.3. NETCONF <edit-config> Operations . . . . . . . . . . 92
7.11.3. NETCONF <edit-config> Operations . . . . . . . . . . 89 7.11.4. Usage Example . . . . . . . . . . . . . . . . . . . 93
7.11.4. Usage Example . . . . . . . . . . . . . . . . . . . 89 7.12. The grouping Statement . . . . . . . . . . . . . . . . . 93
7.12. The grouping Statement . . . . . . . . . . . . . . . . . 89 7.12.1. The grouping's Substatements . . . . . . . . . . . . 94
7.12.1. The grouping's Substatements . . . . . . . . . . . . 90 7.12.2. Usage Example . . . . . . . . . . . . . . . . . . . 95
7.12.2. Usage Example . . . . . . . . . . . . . . . . . . . 91 7.13. The uses Statement . . . . . . . . . . . . . . . . . . . 95
7.13. The uses Statement . . . . . . . . . . . . . . . . . . . 91 7.13.1. The uses's Substatements . . . . . . . . . . . . . . 95
7.13.1. The uses's Substatements . . . . . . . . . . . . . . 91 7.13.2. The refine Statement . . . . . . . . . . . . . . . . 96
7.13.2. The refine Statement . . . . . . . . . . . . . . . . 92 7.13.3. XML Encoding Rules . . . . . . . . . . . . . . . . . 97
7.13.3. XML Encoding Rules . . . . . . . . . . . . . . . . . 93 7.13.4. Usage Example . . . . . . . . . . . . . . . . . . . 97
7.13.4. Usage Example . . . . . . . . . . . . . . . . . . . 93 7.14. The rpc Statement . . . . . . . . . . . . . . . . . . . . 98
7.14. The rpc Statement . . . . . . . . . . . . . . . . . . . . 94 7.14.1. The rpc's Substatements . . . . . . . . . . . . . . 98
7.14.1. The rpc's Substatements . . . . . . . . . . . . . . 94 7.14.2. The input Statement . . . . . . . . . . . . . . . . 99
7.14.2. The input Statement . . . . . . . . . . . . . . . . 95 7.14.3. The output Statement . . . . . . . . . . . . . . . . 100
7.14.3. The output Statement . . . . . . . . . . . . . . . . 96 7.14.4. NETCONF XML Encoding Rules . . . . . . . . . . . . . 101
7.14.4. NETCONF XML Encoding Rules . . . . . . . . . . . . . 97 7.14.5. Usage Example . . . . . . . . . . . . . . . . . . . 101
7.14.5. Usage Example . . . . . . . . . . . . . . . . . . . 97 7.15. The action Statement . . . . . . . . . . . . . . . . . . 102
7.15. The action Statement . . . . . . . . . . . . . . . . . . 98 7.15.1. The action's Substatements . . . . . . . . . . . . . 102
7.15.1. The action's Substatements . . . . . . . . . . . . . 98 7.15.2. NETCONF XML Encoding Rules . . . . . . . . . . . . . 103
7.15.2. NETCONF XML Encoding Rules . . . . . . . . . . . . . 99 7.15.3. Usage Example . . . . . . . . . . . . . . . . . . . 103
7.15.3. Usage Example . . . . . . . . . . . . . . . . . . . 99 7.16. The notification Statement . . . . . . . . . . . . . . . 105
7.16. The notification Statement . . . . . . . . . . . . . . . 101 7.16.1. The notification's Substatements . . . . . . . . . . 106
7.16.1. The notification's Substatements . . . . . . . . . . 102 7.16.2. NETCONF XML Encoding Rules . . . . . . . . . . . . . 106
7.16.2. NETCONF XML Encoding Rules . . . . . . . . . . . . . 102 7.16.3. Usage Example . . . . . . . . . . . . . . . . . . . 107
7.16.3. Usage Example . . . . . . . . . . . . . . . . . . . 103 7.17. The augment Statement . . . . . . . . . . . . . . . . . . 108
7.17. The augment Statement . . . . . . . . . . . . . . . . . . 104 7.17.1. The augment's Substatements . . . . . . . . . . . . 110
7.17.1. The augment's Substatements . . . . . . . . . . . . 105 7.17.2. XML Encoding Rules . . . . . . . . . . . . . . . . . 111
7.17.2. XML Encoding Rules . . . . . . . . . . . . . . . . . 106 7.17.3. Usage Example . . . . . . . . . . . . . . . . . . . 111
7.17.3. Usage Example . . . . . . . . . . . . . . . . . . . 106 7.18. The identity Statement . . . . . . . . . . . . . . . . . 113
7.18. The identity Statement . . . . . . . . . . . . . . . . . 108 7.18.1. The identity's Substatements . . . . . . . . . . . . 113
7.18.1. The identity's Substatements . . . . . . . . . . . . 108 7.18.2. The base Statement . . . . . . . . . . . . . . . . . 113
7.18.2. The base Statement . . . . . . . . . . . . . . . . . 108 7.18.3. Usage Example . . . . . . . . . . . . . . . . . . . 114
7.18.3. Usage Example . . . . . . . . . . . . . . . . . . . 109 7.19. The extension Statement . . . . . . . . . . . . . . . . . 115
7.19. The extension Statement . . . . . . . . . . . . . . . . . 109 7.19.1. The extension's Substatements . . . . . . . . . . . 115
7.19.1. The extension's Substatements . . . . . . . . . . . 110 7.19.2. The argument Statement . . . . . . . . . . . . . . . 115
7.19.2. The argument Statement . . . . . . . . . . . . . . . 110 7.19.3. Usage Example . . . . . . . . . . . . . . . . . . . 116
7.19.3. Usage Example . . . . . . . . . . . . . . . . . . . 111 7.20. Conformance-Related Statements . . . . . . . . . . . . . 117
7.20. Conformance-Related Statements . . . . . . . . . . . . . 111 7.20.1. The feature Statement . . . . . . . . . . . . . . . 117
7.20.1. The feature Statement . . . . . . . . . . . . . . . 112 7.20.2. The if-feature Statement . . . . . . . . . . . . . . 119
7.20.2. The if-feature Statement . . . . . . . . . . . . . . 113 7.20.3. The deviation Statement . . . . . . . . . . . . . . 119
7.20.3. The deviation Statement . . . . . . . . . . . . . . 114 7.21. Common Statements . . . . . . . . . . . . . . . . . . . . 123
7.21. Common Statements . . . . . . . . . . . . . . . . . . . . 117 7.21.1. The config Statement . . . . . . . . . . . . . . . . 123
7.21.1. The config Statement . . . . . . . . . . . . . . . . 117 7.21.2. The status Statement . . . . . . . . . . . . . . . . 123
7.21.2. The status Statement . . . . . . . . . . . . . . . . 117 7.21.3. The description Statement . . . . . . . . . . . . . 124
7.21.3. The description Statement . . . . . . . . . . . . . 118 7.21.4. The reference Statement . . . . . . . . . . . . . . 124
7.21.4. The reference Statement . . . . . . . . . . . . . . 118 7.21.5. The when Statement . . . . . . . . . . . . . . . . . 124
7.21.5. The when Statement . . . . . . . . . . . . . . . . . 119 8. Constraints . . . . . . . . . . . . . . . . . . . . . . . . . 126
8. Constraints . . . . . . . . . . . . . . . . . . . . . . . . . 120 8.1. Constraints on Data . . . . . . . . . . . . . . . . . . . 126
8.1. Constraints on Data . . . . . . . . . . . . . . . . . . . 120 8.2. Configuration Data Modifications . . . . . . . . . . . . 127
8.2. NETCONF Constraint Enforcement Model . . . . . . . . . . 121 8.3. NETCONF Constraint Enforcement Model . . . . . . . . . . 127
8.2.1. Payload Parsing . . . . . . . . . . . . . . . . . . . 121 8.3.1. Payload Parsing . . . . . . . . . . . . . . . . . . . 127
8.2.2. NETCONF <edit-config> Processing . . . . . . . . . . 122 8.3.2. NETCONF <edit-config> Processing . . . . . . . . . . 128
8.2.3. Validation . . . . . . . . . . . . . . . . . . . . . 123 8.3.3. Validation . . . . . . . . . . . . . . . . . . . . . 128
9. Built-In Types . . . . . . . . . . . . . . . . . . . . . . . 123 9. Built-In Types . . . . . . . . . . . . . . . . . . . . . . . 129
9.1. Canonical Representation . . . . . . . . . . . . . . . . 123 9.1. Canonical Representation . . . . . . . . . . . . . . . . 129
9.2. The Integer Built-In Types . . . . . . . . . . . . . . . 124 9.2. The Integer Built-In Types . . . . . . . . . . . . . . . 129
9.2.1. Lexical Representation . . . . . . . . . . . . . . . 124 9.2.1. Lexical Representation . . . . . . . . . . . . . . . 130
9.2.2. Canonical Form . . . . . . . . . . . . . . . . . . . 125 9.2.2. Canonical Form . . . . . . . . . . . . . . . . . . . 131
9.2.3. Restrictions . . . . . . . . . . . . . . . . . . . . 125 9.2.3. Restrictions . . . . . . . . . . . . . . . . . . . . 131
9.2.4. The range Statement . . . . . . . . . . . . . . . . . 125 9.2.4. The range Statement . . . . . . . . . . . . . . . . . 131
9.2.5. Usage Example . . . . . . . . . . . . . . . . . . . . 126 9.2.5. Usage Example . . . . . . . . . . . . . . . . . . . . 132
9.3. The decimal64 Built-In Type . . . . . . . . . . . . . . . 126 9.3. The decimal64 Built-In Type . . . . . . . . . . . . . . . 132
9.3.1. Lexical Representation . . . . . . . . . . . . . . . 126 9.3.1. Lexical Representation . . . . . . . . . . . . . . . 132
9.3.2. Canonical Form . . . . . . . . . . . . . . . . . . . 127 9.3.2. Canonical Form . . . . . . . . . . . . . . . . . . . 133
9.3.3. Restrictions . . . . . . . . . . . . . . . . . . . . 127 9.3.3. Restrictions . . . . . . . . . . . . . . . . . . . . 133
9.3.4. The fraction-digits Statement . . . . . . . . . . . . 127 9.3.4. The fraction-digits Statement . . . . . . . . . . . . 133
9.3.5. Usage Example . . . . . . . . . . . . . . . . . . . . 128 9.3.5. Usage Example . . . . . . . . . . . . . . . . . . . . 134
9.4. The string Built-In Type . . . . . . . . . . . . . . . . 128 9.4. The string Built-In Type . . . . . . . . . . . . . . . . 134
9.4.1. Lexical Representation . . . . . . . . . . . . . . . 128 9.4.1. Lexical Representation . . . . . . . . . . . . . . . 134
9.4.2. Canonical Form . . . . . . . . . . . . . . . . . . . 128 9.4.2. Canonical Form . . . . . . . . . . . . . . . . . . . 134
9.4.3. Restrictions . . . . . . . . . . . . . . . . . . . . 128 9.4.3. Restrictions . . . . . . . . . . . . . . . . . . . . 134
9.4.4. The length Statement . . . . . . . . . . . . . . . . 128 9.4.4. The length Statement . . . . . . . . . . . . . . . . 134
9.4.5. The pattern Statement . . . . . . . . . . . . . . . . 129 9.4.5. The pattern Statement . . . . . . . . . . . . . . . . 135
9.4.6. The modifier Statement . . . . . . . . . . . . . . . 130 9.4.6. The modifier Statement . . . . . . . . . . . . . . . 136
9.4.7. Usage Example . . . . . . . . . . . . . . . . . . . . 130 9.4.7. Usage Example . . . . . . . . . . . . . . . . . . . . 136
9.5. The boolean Built-In Type . . . . . . . . . . . . . . . . 131 9.5. The boolean Built-In Type . . . . . . . . . . . . . . . . 137
9.5.1. Lexical Representation . . . . . . . . . . . . . . . 131 9.5.1. Lexical Representation . . . . . . . . . . . . . . . 137
9.5.2. Canonical Form . . . . . . . . . . . . . . . . . . . 131 9.5.2. Canonical Form . . . . . . . . . . . . . . . . . . . 137
9.5.3. Restrictions . . . . . . . . . . . . . . . . . . . . 132 9.5.3. Restrictions . . . . . . . . . . . . . . . . . . . . 138
9.6. The enumeration Built-In Type . . . . . . . . . . . . . . 132 9.6. The enumeration Built-In Type . . . . . . . . . . . . . . 138
9.6.1. Lexical Representation . . . . . . . . . . . . . . . 132 9.6.1. Lexical Representation . . . . . . . . . . . . . . . 138
9.6.2. Canonical Form . . . . . . . . . . . . . . . . . . . 132 9.6.2. Canonical Form . . . . . . . . . . . . . . . . . . . 138
9.6.3. Restrictions . . . . . . . . . . . . . . . . . . . . 132 9.6.3. Restrictions . . . . . . . . . . . . . . . . . . . . 138
9.6.4. The enum Statement . . . . . . . . . . . . . . . . . 132 9.6.4. The enum Statement . . . . . . . . . . . . . . . . . 138
9.6.5. Usage Example . . . . . . . . . . . . . . . . . . . . 133 9.6.5. Usage Example . . . . . . . . . . . . . . . . . . . . 139
9.7. The bits Built-In Type . . . . . . . . . . . . . . . . . 134 9.7. The bits Built-In Type . . . . . . . . . . . . . . . . . 141
9.7.1. Restrictions . . . . . . . . . . . . . . . . . . . . 134 9.7.1. Restrictions . . . . . . . . . . . . . . . . . . . . 141
9.7.2. Lexical Representation . . . . . . . . . . . . . . . 135 9.7.2. Lexical Representation . . . . . . . . . . . . . . . 141
9.7.3. Canonical Form . . . . . . . . . . . . . . . . . . . 135 9.7.3. Canonical Form . . . . . . . . . . . . . . . . . . . 141
9.7.4. The bit Statement . . . . . . . . . . . . . . . . . . 135 9.7.4. The bit Statement . . . . . . . . . . . . . . . . . . 141
9.7.5. Usage Example . . . . . . . . . . . . . . . . . . . . 136 9.7.5. Usage Example . . . . . . . . . . . . . . . . . . . . 142
9.8. The binary Built-In Type . . . . . . . . . . . . . . . . 136 9.8. The binary Built-In Type . . . . . . . . . . . . . . . . 144
9.8.1. Restrictions . . . . . . . . . . . . . . . . . . . . 136 9.8.1. Restrictions . . . . . . . . . . . . . . . . . . . . 144
9.8.2. Lexical Representation . . . . . . . . . . . . . . . 136 9.8.2. Lexical Representation . . . . . . . . . . . . . . . 144
9.8.3. Canonical Form . . . . . . . . . . . . . . . . . . . 137 9.8.3. Canonical Form . . . . . . . . . . . . . . . . . . . 144
9.9. The leafref Built-In Type . . . . . . . . . . . . . . . . 137 9.9. The leafref Built-In Type . . . . . . . . . . . . . . . . 144
9.9.1. Restrictions . . . . . . . . . . . . . . . . . . . . 137 9.9.1. Restrictions . . . . . . . . . . . . . . . . . . . . 144
9.9.2. The path Statement . . . . . . . . . . . . . . . . . 137 9.9.2. The path Statement . . . . . . . . . . . . . . . . . 145
9.9.3. The require-instance Statement . . . . . . . . . . . 138 9.9.3. The require-instance Statement . . . . . . . . . . . 145
9.9.4. Lexical Representation . . . . . . . . . . . . . . . 138 9.9.4. Lexical Representation . . . . . . . . . . . . . . . 146
9.9.5. Canonical Form . . . . . . . . . . . . . . . . . . . 138 9.9.5. Canonical Form . . . . . . . . . . . . . . . . . . . 146
9.9.6. Usage Example . . . . . . . . . . . . . . . . . . . . 138 9.9.6. Usage Example . . . . . . . . . . . . . . . . . . . . 146
9.10. The identityref Built-In Type . . . . . . . . . . . . . . 142 9.10. The identityref Built-In Type . . . . . . . . . . . . . . 149
9.10.1. Restrictions . . . . . . . . . . . . . . . . . . . . 142 9.10.1. Restrictions . . . . . . . . . . . . . . . . . . . . 149
9.10.2. The identityref's base Statement . . . . . . . . . . 142 9.10.2. The identityref's base Statement . . . . . . . . . . 149
9.10.3. Lexical Representation . . . . . . . . . . . . . . . 143 9.10.3. Lexical Representation . . . . . . . . . . . . . . . 150
9.10.4. Canonical Form . . . . . . . . . . . . . . . . . . . 143 9.10.4. Canonical Form . . . . . . . . . . . . . . . . . . . 150
9.10.5. Usage Example . . . . . . . . . . . . . . . . . . . 143 9.10.5. Usage Example . . . . . . . . . . . . . . . . . . . 150
9.11. The empty Built-In Type . . . . . . . . . . . . . . . . . 145 9.11. The empty Built-In Type . . . . . . . . . . . . . . . . . 152
9.11.1. Restrictions . . . . . . . . . . . . . . . . . . . . 145 9.11.1. Restrictions . . . . . . . . . . . . . . . . . . . . 152
9.11.2. Lexical Representation . . . . . . . . . . . . . . . 145 9.11.2. Lexical Representation . . . . . . . . . . . . . . . 152
9.11.3. Canonical Form . . . . . . . . . . . . . . . . . . . 145 9.11.3. Canonical Form . . . . . . . . . . . . . . . . . . . 152
9.11.4. Usage Example . . . . . . . . . . . . . . . . . . . 145 9.11.4. Usage Example . . . . . . . . . . . . . . . . . . . 152
9.12. The union Built-In Type . . . . . . . . . . . . . . . . . 145 9.12. The union Built-In Type . . . . . . . . . . . . . . . . . 152
9.12.1. Restrictions . . . . . . . . . . . . . . . . . . . . 146 9.12.1. Restrictions . . . . . . . . . . . . . . . . . . . . 153
9.12.2. Lexical Representation . . . . . . . . . . . . . . . 146 9.12.2. Lexical Representation . . . . . . . . . . . . . . . 153
9.12.3. Canonical Form . . . . . . . . . . . . . . . . . . . 146 9.12.3. Canonical Form . . . . . . . . . . . . . . . . . . . 153
9.12.4. Usage Example . . . . . . . . . . . . . . . . . . . 146 9.12.4. Usage Example . . . . . . . . . . . . . . . . . . . 153
9.13. The instance-identifier Built-In Type . . . . . . . . . . 147 9.13. The instance-identifier Built-In Type . . . . . . . . . . 154
9.13.1. Restrictions . . . . . . . . . . . . . . . . . . . . 148 9.13.1. Restrictions . . . . . . . . . . . . . . . . . . . . 155
9.13.2. Lexical Representation . . . . . . . . . . . . . . . 148 9.13.2. Lexical Representation . . . . . . . . . . . . . . . 155
9.13.3. Canonical Form . . . . . . . . . . . . . . . . . . . 148 9.13.3. Canonical Form . . . . . . . . . . . . . . . . . . . 155
9.13.4. Usage Example . . . . . . . . . . . . . . . . . . . 148 9.13.4. Usage Example . . . . . . . . . . . . . . . . . . . 155
10. XPath Functions . . . . . . . . . . . . . . . . . . . . . . . 149 10. XPath Functions . . . . . . . . . . . . . . . . . . . . . . . 156
10.1. Functions for Node Sets . . . . . . . . . . . . . . . . 149 10.1. Functions for Node Sets . . . . . . . . . . . . . . . . 156
10.1.1. current() . . . . . . . . . . . . . . . . . . . . . 149 10.1.1. current() . . . . . . . . . . . . . . . . . . . . . 156
10.2. Functions for Strings . . . . . . . . . . . . . . . . . 149 10.2. Functions for Strings . . . . . . . . . . . . . . . . . 157
10.2.1. re-match() . . . . . . . . . . . . . . . . . . . . . 149 10.2.1. re-match() . . . . . . . . . . . . . . . . . . . . . 157
10.3. Functions for the YANG Types "leafref" and "instance- 10.3. Functions for the YANG Types "leafref" and "instance-
identifier" . . . . . . . . . . . . . . . . . . . . . . 150 identifier" . . . . . . . . . . . . . . . . . . . . . . 157
10.3.1. deref() . . . . . . . . . . . . . . . . . . . . . . 150 10.3.1. deref() . . . . . . . . . . . . . . . . . . . . . . 157
10.4. Functions for the YANG Type "identityref" . . . . . . . 151 10.4. Functions for the YANG Type "identityref" . . . . . . . 158
10.4.1. derived-from() . . . . . . . . . . . . . . . . . . . 151 10.4.1. derived-from() . . . . . . . . . . . . . . . . . . . 158
10.4.2. derived-from-or-self() . . . . . . . . . . . . . . . 151 10.4.2. derived-from-or-self() . . . . . . . . . . . . . . . 160
10.5. Functions for the YANG Type "enumeration" . . . . . . . 152 10.5. Functions for the YANG Type "enumeration" . . . . . . . 160
10.5.1. enum-value() . . . . . . . . . . . . . . . . . . . . 153 10.5.1. enum-value() . . . . . . . . . . . . . . . . . . . . 160
10.6. Functions for the YANG Type "bits" . . . . . . . . . . . 154 10.6. Functions for the YANG Type "bits" . . . . . . . . . . . 161
10.6.1. bit-is-set() . . . . . . . . . . . . . . . . . . . . 154 10.6.1. bit-is-set() . . . . . . . . . . . . . . . . . . . . 161
11. Updating a Module . . . . . . . . . . . . . . . . . . . . . . 154 11. Updating a Module . . . . . . . . . . . . . . . . . . . . . . 162
12. Coexistence with YANG version 1 . . . . . . . . . . . . . . . 157 12. Coexistence with YANG version 1 . . . . . . . . . . . . . . . 164
13. YIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 13. YIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
13.1. Formal YIN Definition . . . . . . . . . . . . . . . . . 157 13.1. Formal YIN Definition . . . . . . . . . . . . . . . . . 165
13.1.1. Usage Example . . . . . . . . . . . . . . . . . . . 160 13.1.1. Usage Example . . . . . . . . . . . . . . . . . . . 168
14. YANG ABNF Grammar . . . . . . . . . . . . . . . . . . . . . . 161 14. YANG ABNF Grammar . . . . . . . . . . . . . . . . . . . . . . 169
15. NETCONF Error Responses for YANG Related Errors . . . . . . . 185 15. NETCONF Error Responses for YANG Related Errors . . . . . . . 193
15.1. Error Message for Data That Violates a unique Statement 185 15.1. Error Message for Data That Violates a unique Statement 193
15.2. Error Message for Data That Violates a max-elements 15.2. Error Message for Data That Violates a max-elements
Statement . . . . . . . . . . . . . . . . . . . . . . . 186 Statement . . . . . . . . . . . . . . . . . . . . . . . 194
15.3. Error Message for Data That Violates a min-elements 15.3. Error Message for Data That Violates a min-elements
Statement . . . . . . . . . . . . . . . . . . . . . . . 186 Statement . . . . . . . . . . . . . . . . . . . . . . . 194
15.4. Error Message for Data That Violates a must Statement . 186 15.4. Error Message for Data That Violates a must Statement . 194
15.5. Error Message for Data That Violates a require-instance 15.5. Error Message for Data That Violates a require-instance
Statement . . . . . . . . . . . . . . . . . . . . . . . 187 Statement . . . . . . . . . . . . . . . . . . . . . . . 194
15.6. Error Message for Data That Does Not Match a leafref 15.6. Error Message for Data That Does Not Match a leafref
Type . . . . . . . . . . . . . . . . . . . . . . . . . . 187 Type . . . . . . . . . . . . . . . . . . . . . . . . . . 195
15.7. Error Message for Data That Violates a mandatory choice 15.7. Error Message for Data That Violates a mandatory choice
Statement . . . . . . . . . . . . . . . . . . . . . . . 187 Statement . . . . . . . . . . . . . . . . . . . . . . . 195
15.8. Error Message for the "insert" Operation . . . . . . . . 187 15.8. Error Message for the "insert" Operation . . . . . . . . 195
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 188 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 195
17. Security Considerations . . . . . . . . . . . . . . . . . . . 188 17. Security Considerations . . . . . . . . . . . . . . . . . . . 195
18. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 188 18. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 196
19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 189 19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 196
20. ChangeLog . . . . . . . . . . . . . . . . . . . . . . . . . . 189 20. ChangeLog . . . . . . . . . . . . . . . . . . . . . . . . . . 197
20.1. Version -08 . . . . . . . . . . . . . . . . . . . . . . 189 20.1. Version -09 . . . . . . . . . . . . . . . . . . . . . . 197
20.2. Version -07 . . . . . . . . . . . . . . . . . . . . . . 189 20.2. Version -08 . . . . . . . . . . . . . . . . . . . . . . 197
20.3. Version -06 . . . . . . . . . . . . . . . . . . . . . . 189 20.3. Version -07 . . . . . . . . . . . . . . . . . . . . . . 197
20.4. Version -05 . . . . . . . . . . . . . . . . . . . . . . 189 20.4. Version -06 . . . . . . . . . . . . . . . . . . . . . . 197
20.5. Version -04 . . . . . . . . . . . . . . . . . . . . . . 189 20.5. Version -05 . . . . . . . . . . . . . . . . . . . . . . 197
20.6. Version -03 . . . . . . . . . . . . . . . . . . . . . . 190 20.6. Version -04 . . . . . . . . . . . . . . . . . . . . . . 198
20.7. Version -02 . . . . . . . . . . . . . . . . . . . . . . 190 20.7. Version -03 . . . . . . . . . . . . . . . . . . . . . . 198
20.8. Version -01 . . . . . . . . . . . . . . . . . . . . . . 190 20.8. Version -02 . . . . . . . . . . . . . . . . . . . . . . 198
20.9. Version -00 . . . . . . . . . . . . . . . . . . . . . . 191 20.9. Version -01 . . . . . . . . . . . . . . . . . . . . . . 198
21. References . . . . . . . . . . . . . . . . . . . . . . . . . 191 20.10. Version -00 . . . . . . . . . . . . . . . . . . . . . . 199
21.1. Normative References . . . . . . . . . . . . . . . . . . 191 21. References . . . . . . . . . . . . . . . . . . . . . . . . . 199
21.2. Informative References . . . . . . . . . . . . . . . . . 192 21.1. Normative References . . . . . . . . . . . . . . . . . . 199
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 193 21.2. Informative References . . . . . . . . . . . . . . . . . 200
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 201
1. Introduction 1. Introduction
YANG is a data modeling language originally designed to model YANG is a data modeling language originally designed to model
configuration and state data manipulated by the Network Configuration configuration and state data manipulated by the Network Configuration
Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF
notifications [RFC6241]. Since the publication of YANG version 1 notifications [RFC6241]. Since the publication of YANG version 1
[RFC6020], YANG has been used or proposed to be used for other [RFC6020], YANG has been used or proposed to be used for other
protocols (e.g., RESTCONF [I-D.ietf-netconf-restconf] and CoMI protocols (e.g., RESTCONF [I-D.ietf-netconf-restconf] and CoMI
[I-D.vanderstok-core-comi]). Further, other encodings than XML have [I-D.vanderstok-core-comi]). Further, other encodings than XML have
been propsed (e.g., JSON [I-D.ietf-netmod-yang-json]). been proposed (e.g., JSON [I-D.ietf-netmod-yang-json]).
This document describes the syntax and semantics of version 1.1 of This document describes the syntax and semantics of version 1.1 of
the YANG language. It also describes how a data model defined in a the YANG language. It also describes how a data model defined in a
YANG module is encoded in the Extensible Markup Language (XML), and YANG module is encoded in the Extensible Markup Language (XML), and
how NETCONF operations are used to manipulate the data. Other how NETCONF operations are used to manipulate the data. Other
protocols and encodings are possible, but out of scope for this protocols and encodings are possible, but out of scope for this
specification. specification.
1.1. Summary of Changes from RFC 6020 1.1. Summary of Changes from RFC 6020
skipping to change at page 9, line 26 skipping to change at page 9, line 32
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 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, unless the o Made "when" and "if-feature" illegal on list keys.
parent is also conditional, and the condition matches the parent's
condition.
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 "augment" to add conditionally mandatory nodes (see
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 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 to be subtyped (see Section 9.6). o Allow enumerations and bits to be subtyped (see Section 9.6 and
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 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.5).
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 defintions 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).
o Allow types empty and leafref in unions.
o Allow type empty in a key.
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:
skipping to change at page 28, line 47 skipping to change at page 28, line 47
5.1. Modules and Submodules 5.1. Modules and Submodules
The module is the base unit of definition in YANG. A module defines The module is the base unit of definition in YANG. A module defines
a single data model. A module can define a complete, cohesive model, a single data model. A module can define a complete, cohesive model,
or augment an existing data model with additional nodes. or augment an existing data model with additional nodes.
Submodules are partial modules that contribute definitions to a Submodules are partial modules that contribute definitions to a
module. A module may include any number of submodules, but each module. A module may include any number of submodules, but each
submodule may belong to only one module. submodule may belong to only one module.
The names of all standard modules and submodules MUST be unique. Developers of YANG modules and submodules are RECOMMENDED to choose
Developers of enterprise modules are RECOMMENDED to choose names for names for their modules that will have a low probability of colliding
their modules that will have a low probability of colliding with with standard or other enterprise modules, e.g., by using the
standard or other enterprise modules, e.g., by using the enterprise enterprise or organization name as a prefix for the module name.
or organization name as a prefix for the module name. 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 it 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 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:
skipping to change at page 37, line 22 skipping to change at page 37, line 22
type of leaf "/b:x/a:y" is the same regardless of which revision of type of leaf "/b:x/a:y" is the same regardless of which revision of
"b" the server implements. "b" the server implements.
A server that implements module "a", but does not support feature A server that implements module "a", but does not support feature
"foo" does not have to implement module "b". "foo" does not have to implement module "b".
A server that implements revision "2015-01-01" of module "a" must A server that implements revision "2015-01-01" of module "a" must
pick a revision of module "c", and list it in the "/modules/module" pick a revision of module "c", and list it in the "/modules/module"
list from "ietf-yang-library". list from "ietf-yang-library".
The following XML enconding example shows valid data for the The following XML encoding example shows valid data for the
"/modules/module" list for a server that implements module "a": "/modules/module" list for a server that implements module "a":
<modules xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library"> <modules xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library">
<module-set-id>ee1ecb017370cafd</module-set-id> <module-set-id>ee1ecb017370cafd</module-set-id>
<module> <module>
<name>a</module> <name>a</module>
<revision>2015-01-01</revision> <revision>2015-01-01</revision>
<feature>foo</feature> <feature>foo</feature>
<conformance>implement</conformance> <conformance>implement</conformance>
</module> </module>
skipping to change at page 38, line 28 skipping to change at page 38, line 28
"/modules/module-set-id" from "ietf-yang-library". This parameter "/modules/module-set-id" from "ietf-yang-library". This parameter
MUST be present. MUST be present.
With this mechanism, a client can cache the supported modules for a With this mechanism, a client can cache the supported modules for a
server, and only update the cache if the "module-set-id" value in the server, and only update the cache if the "module-set-id" value in the
<hello> message changes. <hello> message changes.
5.7. Datastore Modification 5.7. Datastore Modification
Data models may allow the server to alter the configuration datastore Data models may allow the server to alter the configuration datastore
in ways not explicitly directed via NETCONF protocol messages. For in ways not explicitly directed via network management protocol
example, a data model may define leafs that are assigned system- messages. For example, a data model may define leafs that are
generated values when the client does not provide one. A formal assigned system-generated values when the client does not provide
mechanism for specifying the circumstances where these changes are one. A formal mechanism for specifying the circumstances where these
allowed is out of scope for this specification. changes are allowed is out of scope for this specification.
6. YANG Syntax 6. YANG Syntax
The YANG syntax is similar to that of SMIng [RFC3780] and programming The YANG syntax is similar to that of SMIng [RFC3780] and programming
languages like C and C++. This C-like syntax was chosen specifically languages like C and C++. This C-like syntax was chosen specifically
for its readability, since YANG values the time and effort of the for its readability, since YANG values the time and effort of the
readers of models above those of modules writers and YANG tool-chain readers of models above those of modules writers and YANG tool-chain
developers. This section introduces the YANG syntax. developers. This section introduces the YANG syntax.
YANG modules use the UTF-8 [RFC3629] character encoding. YANG modules use the UTF-8 [RFC3629] character encoding.
skipping to change at page 43, line 19 skipping to change at page 43, line 19
The data model used in the XPath expressions is the same as that used The data model used in the XPath expressions is the same as that used
in XPath 1.0 [XPATH], with the same extension for root node children in XPath 1.0 [XPATH], with the same extension for root node children
as used by XSLT 1.0 [XSLT] (Section 3.1). Specifically, it means as used by XSLT 1.0 [XSLT] (Section 3.1). Specifically, it means
that the root node may have any number of element nodes as its that the root node may have any number of element nodes as its
children. children.
The data tree has no concept of document order. An implementation The data tree has no concept of document order. An implementation
needs to choose some document order but how it is done is an needs to choose some document order but how it is done is an
implementation decision. This means that XPath expressions in YANG implementation decision. This means that XPath expressions in YANG
modules SHOULD not rely on any specific document order. modules SHOULD NOT rely on any specific document order.
Numbers in XPath 1.0 are IEEE 754 double-precision floating-point Numbers in XPath 1.0 are IEEE 754 double-precision floating-point
values, see Section 3.5 in [XPATH]. This means that some values of values, see Section 3.5 in [XPATH]. This means that some values of
int64, uint64 and decimal64 types (see Section 9.2 and Section 9.3) int64, uint64 and decimal64 types (see Section 9.2 and Section 9.3)
cannot be exactly represented in XPath expressions. Therefore, due cannot be exactly represented in XPath expressions. Therefore, due
caution should be exercised when using nodes with 64-bit numeric caution should be exercised when using nodes with 64-bit numeric
values in XPath expressions. In particular, numerical comparisons values in XPath expressions. In particular, numerical comparisons
involving equality may yield unexpected results. involving equality may yield unexpected results.
For example, consider the following definition: For example, consider the following definition:
skipping to change at page 44, line 36 skipping to change at page 44, line 36
all top-level configuration data nodes in all modules as children. all top-level configuration data nodes in all modules as children.
o If the XPath expression is defined in a substatement to a data o If the XPath expression is defined in a substatement to a data
node that represents state data, the accessible tree is all state node that represents state data, the accessible tree is all state
data in the server, and the running configuration datastore. The data in the server, and the running configuration datastore. The
root node has all top-level data nodes in all modules as children. root node has all top-level data nodes in all modules as children.
o If the XPath expression is defined in a substatement to a o If the XPath expression is defined in a substatement to a
"notification" statement, the accessible tree is the notification "notification" statement, the accessible tree is the notification
instance, all state data in the server, and the running instance, all state data in the server, and the running
configuration datastore. The root node has the node representing configuration datastore. If the notification is defined on the
the notification being defined and all top-level data nodes in all top-level in a module, then the root node has the node
modules as children. representing the notification being defined and all top-level data
nodes in all modules as children. Otherwise, the root node has
all top-level data nodes in all modules as children.
o If the XPath expression is defined in a substatement to an "input" o If the XPath expression is defined in a substatement to an "input"
statement in an "rpc" or "action" statement, the accessible tree statement in an "rpc" or "action" statement, the accessible tree
is the RPC or action operation instance, all state data in the is the RPC or action operation instance, all state data in the
server, and the running configuration datastore. The root node server, and the running configuration datastore. The root node
has the node representing the operation being defined and all top- has top-level data nodes in all modules as children.
level data nodes in all modules as children. The node Additionally, for an RPC, the root node also has the node
representing the RPC operation being defined as a child. The node
representing the operation being defined has the operation's input representing the operation being defined has the operation's input
parameters as children. parameters as children.
o If the XPath expression is defined in a substatement to an o If the XPath expression is defined in a substatement to an
"output" statement in an "rpc" or "action" statement, the "output" statement in an "rpc" or "action" statement, the
accessible tree is the RPC or action operation's output, all state accessible tree is the RPC or action operation instance, all state
data in the server, and the running configuration datastore. The data in the server, and the running configuration datastore. The
root node has the node representing the operation being defined root node has top-level data nodes in all modules as children.
and all top-level data nodes in all modules as children. The node Additionally, for an RPC, the root node also has the node
representing the RPC operation being defined as a child. The node
representing the operation being defined has the operation's representing the operation being defined has the operation's
output parameters as children. output parameters as children.
In the accessible tree, all leafs and leaf-lists with default values In the accessible tree, all leafs and leaf-lists with default values
in use exist (See Section 7.6.1 and Section 7.7.2). in use exist (See Section 7.6.1 and Section 7.7.2).
If a node that exists in the accessible tree has a non-presence If a node that exists in the accessible tree has a non-presence
container as a child, then the non-presence container also exists in container as a child, then the non-presence container also exists in
the tree. the tree.
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
Given the following module:
module example-a {
namespace http://example.com/a;
prefix a;
container a {
list b {
key id;
leaf id {
type string;
}
notification down {
leaf reason {
type string;
}
}
action reset {
input {
leaf delay {
type uint32;
}
}
output {
leaf result {
type string;
}
}
}
}
}
notification failure {
leaf b-ref {
type leafref {
path "/a/b/id";
}
}
}
}
And given the following data tree, specified in XML:
<a xmlns="http://example.com/a">
<b>
<id>1</id>
</b>
<b>
<id>2</id>
</b>
</a>
The accessible tree for a notification "down" on /a/b[id="2"] is:
<a xmlns="http://example.com/a">
<b>
<id>1</id>
</b>
<b>
<id>2</id>
<down>
<reason>error</reason>
</down>
</b>
</a>
// possibly other top-level nodes here
The accessible tree for an action invocation of "reset" on /a/
b[id="1"] with the "when" parameter set to "10" would be:
<a xmlns="http://example.com/a">
<b>
<id>1</id>
<reset>
<delay>10</delay>
</down>
</b>
<b>
<id>2</id>
</b>
</a>
// possibly other top-level nodes here
The accessible tree for the action output of this action is:
<a xmlns="http://example.com/a">
<b>
<id>1</id>
<reset>
<result>ok</result>
</reset>
</b>
<b>
<id>2</id>
</b>
</a>
// possibly other top-level nodes here
The accessible tree for a notification "failure" could be:
<a xmlns="http://example.com/a">
<b>
<id>1</id>
</b>
<b>
<id>2</id>
</b>
</a>
<failure>
<b-ref>2</b-ref>
</failure>
// possibly other top-level nodes here
6.5. Schema Node Identifier 6.5. Schema Node Identifier
A schema node identifier is a string that identifies a node in the A schema node identifier is a string that identifies a node in the
schema tree. It has two forms, "absolute" and "descendant", defined schema tree. It has two forms, "absolute" and "descendant", defined
by the rules "absolute-schema-nodeid" and "descendant-schema-nodeid" by the rules "absolute-schema-nodeid" and "descendant-schema-nodeid"
in Section 14, respectively. A schema node identifier consists of a in Section 14, respectively. A schema node identifier consists of a
path of identifiers, separated by slashes ("/"). In an absolute path of identifiers, separated by slashes ("/"). In an absolute
schema node identifier, the first identifier after the leading slash schema node identifier, the first identifier after the leading slash
is any top-level schema node in the local module or in all imported is any top-level schema node in the local module or in all imported
modules. modules.
skipping to change at page 63, line 18 skipping to change at page 66, line 18
o Otherwise, if this ancestor is a case node, the default value MUST o Otherwise, if this ancestor is a case node, the default value MUST
be used if any node from the case exists in the data tree, or if be used if any node from the case exists in the data tree, or if
the case node is the choice's default case, and no nodes from any the case node is the choice's default case, and no nodes from any
other case exist in the data tree. other case exist in the data tree.
o Otherwise, the default value MUST be used if the ancestor node o Otherwise, the default value MUST be used if the ancestor node
exists in the data tree. exists in the data tree.
In these cases, the default value is said to be in use. In these cases, the default value is said to be in use.
Note that if the leaf or any of its ancestors has a "when" condition
or "if-feature" expression that evaluates to "false", then the
default value is not in use.
When the default value is in use, the server MUST operationally When the default value is in use, the server MUST operationally
behave as if the leaf was present in the data tree with the default behave as if the leaf was present in the data tree with the default
value as its value. value as its value.
If a leaf has a "default" statement, the leaf's default value is the If a leaf has a "default" statement, the leaf's default value is the
value of the "default" statement. Otherwise, if the leaf's type has value of the "default" statement. Otherwise, if the leaf's type has
a default value, and the leaf is not mandatory, then the leaf's a default value, and the leaf is not mandatory, then the leaf's
default value is the type's default value. In all other cases, the default value is the type's default value. In all other cases, the
leaf does not have a default value. leaf does not have a default value.
skipping to change at page 64, line 16 skipping to change at page 67, line 23
The "default" statement, which is optional, takes as an argument a The "default" statement, which is optional, takes as an argument a
string that contains a default value for the leaf. string that contains a default value for the leaf.
The value of the "default" statement MUST be valid according to the The value of the "default" statement MUST be valid according to the
type specified in the leaf's "type" statement. type specified in the leaf's "type" statement.
The "default" statement MUST NOT be present on nodes where The "default" statement MUST NOT be present on nodes where
"mandatory" is true. "mandatory" is true.
The default value MUST NOT be marked with an "if-feature" statement.
For example, the following is illegal:
leaf color {
type enumeration {
enum blue { if-feature blue; }
...
}
default blue; // illegal - enum value is conditional
}
7.6.5. The leaf's mandatory Statement 7.6.5. The leaf's mandatory Statement
The "mandatory" statement, which is optional, takes as an argument The "mandatory" statement, which is optional, takes as an argument
the string "true" or "false", and puts a constraint on valid data. the string "true" or "false", and puts a constraint on valid data.
If not specified, the default is "false". If not specified, the default is "false".
If "mandatory" is "true", the behavior of the constraint depends on If "mandatory" is "true", the behavior of the constraint depends on
the type of the leaf's closest ancestor node in the schema tree that the type of the leaf's closest ancestor node in the schema tree that
is not a non-presence-container (see Section 7.5.1): is not a non-presence-container (see Section 7.5.1):
skipping to change at page 66, line 13 skipping to change at page 69, line 32
</rpc> </rpc>
7.7. The leaf-list Statement 7.7. The leaf-list Statement
Where the "leaf" statement is used to define a simple scalar variable Where the "leaf" statement is used to define a simple scalar variable
of a particular type, the "leaf-list" statement is used to define an of a particular type, the "leaf-list" statement is used to define an
array of a particular type. The "leaf-list" statement takes one array of a particular type. The "leaf-list" statement takes one
argument, which is an identifier, followed by a block of argument, which is an identifier, followed by a block of
substatements that holds detailed leaf-list information. substatements that holds detailed leaf-list information.
The values in a leaf-list MUST be unique. In configuration data, the values in a leaf-list MUST be unique.
The default values MUST NOT be marked with an "if-feature" statement.
Conceptually, the values in the data tree are always in the canonical Conceptually, the values in the data tree are always in the canonical
form (see Section 9.1). form (see Section 9.1).
7.7.1. Ordering 7.7.1. Ordering
YANG supports two styles for ordering the entries within lists and YANG supports two styles for ordering the entries within lists and
leaf-lists. In many lists, the order of list entries does not impact leaf-lists. In many lists, the order of list entries does not impact
the implementation of the list's configuration, and the server is the implementation of the list's configuration, and the server is
free to sort the list entries in any reasonable order. The free to sort the list entries in any reasonable order. The
skipping to change at page 67, line 26 skipping to change at page 70, line 47
o Otherwise, if this ancestor is a case node, the default values o Otherwise, if this ancestor is a case node, the default values
MUST be used if any node from the case exists in the data tree, or MUST be used if any node from the case exists in the data tree, or
if the case node is the choice's default case, and no nodes from if the case node is the choice's default case, and no nodes from
any other case exist in the data tree. any other case exist in the data tree.
o Otherwise, the default values MUST be used if the ancestor node o Otherwise, the default values MUST be used if the ancestor node
exists in the data tree. exists in the data tree.
In these cases, the default values are said to be in use. In these cases, the default values are said to be in use.
Note that if the leaf-list or any of its ancestors has a "when"
condition or "if-feature" expression that evaluates to "false", then
the default values are not in use.
When the default values are in use, the server MUST operationally When the default values are in use, the server MUST operationally
behave as if the leaf-list was present in the data tree with the behave as if the leaf-list was present in the data tree with the
default values as its values. default values as its values.
If a leaf-list has one or more "default" statement, the leaf-list's If a leaf-list has one or more "default" statement, the leaf-list's
default value are the values of the "default" statements, and if the default value are the values of the "default" statements, and if the
leaf-list is user-ordered, the default values are used in the order leaf-list is user-ordered, the default values are used in the order
of the "default" statements. Otherwise, if the leaf-list's type has of the "default" statements. Otherwise, if the leaf-list's type has
a default value, and the leaf-list does not have a "min-elements" a default value, and the leaf-list does not have a "min-elements"
statement with a value greater than or equal to one, then the leaf- statement with a value greater than or equal to one, then the leaf-
skipping to change at page 80, line 41 skipping to change at page 84, 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.
See Section 8.2.2 for additional information. Since only one of the choice's cases can be valid at any time, the
creation of a node from one case implicitly deletes all nodes from
all other cases. If a request creates a node from a case, the server
will delete any existing nodes that are defined in 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 84, line 35 skipping to change at page 88, line 35
7.9.5. XML Encoding Rules 7.9.5. XML Encoding Rules
The choice and case nodes are not visible in XML. The choice and case nodes are not visible in XML.
The child nodes of the selected "case" statement MUST be encoded in The child nodes of the selected "case" statement MUST be encoded in
the same order as they are defined in the "case" statement if they the same order as they are defined in the "case" statement if they
are part of an RPC or action input or output parameter definition. are part of an RPC or action input or output parameter definition.
Otherwise, the subelements are encoded in any order. Otherwise, the subelements are encoded in any order.
7.9.6. NETCONF <edit-config> Operations 7.9.6. Usage Example
Since only one of the choice's cases can be valid at any time, the
creation of a node from one case implicitly deletes all nodes from
all other cases. If an <edit-config> operation creates a node from a
case, the NETCONF server will delete any existing nodes that are
defined in other cases inside the choice.
7.9.7. Usage Example
Given the following choice: Given the following choice:
container protocol { container protocol {
choice name { choice name {
case a { case a {
leaf udp { leaf udp {
type empty; type empty;
} }
} }
skipping to change at page 85, line 52 skipping to change at page 89, line 37
</edit-config> </edit-config>
</rpc> </rpc>
7.10. The anydata Statement 7.10. The anydata Statement
The "anydata" statement defines an interior node in the schema tree. The "anydata" statement defines an interior node in the schema tree.
It takes one argument, which is an identifier, followed by a block of It takes one argument, which is an identifier, followed by a block of
substatements that holds detailed anydata information. substatements that holds detailed anydata information.
The "anydata" statement is used to represent an unknown set of nodes The "anydata" statement is used to represent an unknown set of nodes
that can be modelled with YANG. An example of where this can be that can be modelled with YANG, except anyxml, but for which the data
useful is a list of received notifications, where the exact model is not known at module design time. It is possible, though not
notifications are not known at design time. required, for the data model for "anydata" content to become known
through protocol signalling or other means that are outside the scope
of this document.
An example of where anydata can be useful is a list of received
notifications, where the exact notifications are not known at design
time.
An anydata node cannot be augmented (see Section 7.17). An anydata node cannot be augmented (see Section 7.17).
An anydata node exists in zero or one instances in the data tree. An anydata node exists in zero or one instances in the data tree.
An implementation may or may not know the data model used to model a An implementation may or may not know the data model used to model a
specific instance of an anydata node. specific instance of an anydata node.
Since the use of anydata limits the manipulation of the content, it Since the use of anydata limits the manipulation of the content, it
is RECOMMENDED that the "anydata" statement not be used to define is RECOMMENDED that the "anydata" statement not be used to define
skipping to change at page 90, line 31 skipping to change at page 94, line 22
A grouping is more than just a mechanism for textual substitution, A grouping is more than just a mechanism for textual substitution,
but defines a collection of nodes. Identifiers appearing inside the but defines a collection of nodes. Identifiers appearing inside the
grouping are resolved relative to the scope in which the grouping is grouping are resolved relative to the scope in which the grouping is
defined, not where it is used. Prefix mappings, type names, grouping defined, not where it is used. Prefix mappings, type names, grouping
names, and extension usage are evaluated in the hierarchy where the names, and extension usage are evaluated in the hierarchy where the
"grouping" statement appears. For extensions, this means that "grouping" statement appears. For extensions, this means that
extensions defined as direct children to a "grouping" statement are extensions defined as direct children to a "grouping" statement are
applied to the grouping itself. applied to the grouping itself.
Note that if a grouping defines an "action" or a "notification" node
in its hierarchy, then it cannot be used in all contexts. For
example, it cannot be used in an rpc definition. See Section 7.15
and Section 7.16.
7.12.1. The grouping's Substatements 7.12.1. The grouping's Substatements
+--------------+---------+-------------+ +--------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+--------------+---------+-------------+ +--------------+---------+-------------+
| action | 7.15 | 0..n | | action | 7.15 | 0..n |
| 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 105, line 15 skipping to change at page 109, line 15
"absolute-schema-nodeid" in Section 14) of a schema node identifier "absolute-schema-nodeid" in Section 14) of a schema node identifier
MUST be used. If the "augment" statement is a substatement to the MUST be used. If the "augment" statement is a substatement to the
"uses" statement, the descendant form (defined by the rule "uses" statement, the descendant form (defined by the rule
"descendant-schema-nodeid" in Section 14) MUST be used. "descendant-schema-nodeid" in Section 14) MUST be used.
If the target node is a container, list, case, input, output, or If the target node is a container, list, case, input, output, or
notification node, the "container", "leaf", "list", "leaf-list", notification node, the "container", "leaf", "list", "leaf-list",
"uses", and "choice" statements can be used within the "augment" "uses", and "choice" statements can be used within the "augment"
statement. statement.
If the target node is a container or list node, the "action" and
"notification" statements can be used within the "augment" statement.
If the target node is a choice node, the "case" statement, or a case If the target node is a choice node, the "case" statement, or a case
shorthand statement (see Section 7.9.2) can be used within the shorthand statement (see Section 7.9.2) can be used within the
"augment" statement. "augment" statement.
If the target node is in another module, then nodes added by the
augmentation MUST NOT be mandatory nodes (see Section 3).
The "augment" statement MUST NOT add multiple nodes with the same The "augment" statement MUST NOT add multiple nodes with the same
name from the same module to the target node. name from the same module to the target node.
If the augmentation adds mandatory nodes (see Section 3) to a target
node in another module, the augmentation MUST be conditional with a
"when" statement. Care must be taken when defining the "when"
expression, so that clients that do not know about the augmenting
module do not break.
In the following example, it is OK to augment the "interface" entry
with "mandatory-leaf" because the augmentation depends on support for
"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
mandatory data node.
module example-augment {
namespace "http://example.com/augment";
prefix mymod;
import ietf-interfaces {
prefix if;
}
identity some-new-iftype {
base if:interface-type;
}
augment "/if:interfaces/if:interface" {
when "if:type = 'mymod:some-new-iftype'";
leaf mandatory-leaf {
mandatory true;
type string;
}
}
}
7.17.1. The augment's Substatements 7.17.1. The augment's Substatements
+--------------+---------+-------------+ +--------------+---------+-------------+
| substatement | section | cardinality | | substatement | section | cardinality |
+--------------+---------+-------------+ +--------------+---------+-------------+
| action | 7.15 | 0..n | | action | 7.15 | 0..n |
| 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 |
skipping to change at page 107, line 22 skipping to change at page 112, line 22
</ifEntry> </ifEntry>
<ifEntry> <ifEntry>
<ifIndex>2</ifIndex> <ifIndex>2</ifIndex>
<ifDescr>Flintstone Inc DS0</ifDescr> <ifDescr>Flintstone Inc DS0</ifDescr>
<ifType>ds0</ifType> <ifType>ds0</ifType>
<ds0:ds0ChannelNumber>1</ds0:ds0ChannelNumber> <ds0:ds0ChannelNumber>1</ds0:ds0ChannelNumber>
</ifEntry> </ifEntry>
</interfaces> </interfaces>
As another example, suppose we have the choice defined in As another example, suppose we have the choice defined in
Section 7.9.7. The following construct can be used to extend the Section 7.9.6. The following construct can be used to extend the
protocol definition: protocol definition:
augment /ex:system/ex:protocol/ex:name { augment /ex:system/ex:protocol/ex:name {
case c { case c {
leaf smtp { leaf smtp {
type empty; type empty;
} }
} }
} }
skipping to change at page 109, line 10 skipping to change at page 114, line 10
The derivation of identities has the following properties: The derivation of identities has the following properties:
o It is irreflexive, which means that an identity is not derived o It is irreflexive, which means that an identity is not derived
from itself. from itself.
o It is transitive, which means that if identity B is derived from A o It is transitive, which means that if identity B is derived from A
and C is derived from B, then C is also derived from A. and C is derived from B, then C is also derived from A.
7.18.3. Usage Example 7.18.3. Usage Example
module crypto-base { module crypto-base {
yang-version 1.1; yang-version 1.1;
namespace "http://example.com/crypto-base"; namespace "http://example.com/crypto-base";
prefix "crypto"; prefix "crypto";
identity crypto-alg { identity crypto-alg {
description description
"Base identity from which all crypto algorithms "Base identity from which all crypto algorithms
are derived."; are derived.";
} }
}
module des { identity symmetric-key {
yang-version 1.1; description
namespace "http://example.com/des"; "Base identity used to identify symmetric-key crypto algorithms.";
prefix "des"; }
import "crypto-base" { identity public-key {
prefix "crypto"; description
} "Base identity used to identify public-key crypto algorithms.";
}
}
identity des { module des {
base "crypto:crypto-alg"; yang-version 1.1;
description "DES crypto algorithm"; namespace "http://example.com/des";
} prefix "des";
identity des3 { import "crypto-base" {
base "crypto:crypto-alg"; prefix "crypto";
description "Triple DES crypto algorithm"; }
}
} identity des {
base "crypto:crypto-alg";
base "crypto:symmetric-key";
description "DES crypto algorithm";
}
identity des3 {
base "crypto:crypto-alg";
base "crypto:symmetric-key";
description "Triple DES crypto algorithm";
}
}
7.19. The extension Statement 7.19. The extension Statement
The "extension" statement allows the definition of new statements The "extension" statement allows the definition of new statements
within the YANG language. This new statement definition can be within the YANG language. This new statement definition can be
imported and used by other modules. imported and used by other modules.
The statement's argument is an identifier that is the new keyword for The statement's argument is an identifier that is the new keyword for
the extension and must be followed by a block of substatements that the extension and must be followed by a block of substatements that
holds detailed extension information. The purpose of the "extension" holds detailed extension information. The purpose of the "extension"
skipping to change at page 111, line 19 skipping to change at page 116, line 31
argument is mapped to an XML element in YIN or to an XML attribute argument is mapped to an XML element in YIN or to an XML attribute
(see Section 13). (see Section 13).
If no "yin-element" statement is present, it defaults to "false". If no "yin-element" statement is present, it defaults to "false".
7.19.3. Usage Example 7.19.3. Usage Example
To define an extension: To define an extension:
module my-extensions { module my-extensions {
yang-version 1.1;
... ...
extension c-define { extension c-define {
description description
"Takes as argument a name string. "Takes as argument a name string.
Makes the code generator use the given name in the Makes the code generator use the given name in the
#define."; #define.";
argument "name"; argument "name";
} }
} }
To use the extension: To use the extension:
module my-interfaces { module my-interfaces {
yang-version 1.1;
... ...
import my-extensions { import my-extensions {
prefix "myext"; prefix "myext";
} }
... ...
container interfaces { container interfaces {
... ...
myext:c-define "MY_INTERFACES"; myext:c-define "MY_INTERFACES";
} }
skipping to change at page 112, line 30 skipping to change at page 118, line 6
the feature. the feature.
In this example, a feature called "local-storage" represents the In this example, a feature called "local-storage" represents the
ability for a server to store syslog messages on local storage of ability for a server to store syslog messages on local storage of
some sort. This feature is used to make the "local-storage-limit" some sort. This feature is used to make the "local-storage-limit"
leaf conditional on the presence of some sort of local storage. If leaf conditional on the presence of some sort of local storage. If
the server does not report that it supports this feature, the the server does not report that it supports this feature, the
"local-storage-limit" node is not supported. "local-storage-limit" node is not supported.
module syslog { module syslog {
yang-version 1.1;
... ...
feature local-storage { feature local-storage {
description description
"This feature means the server supports local "This feature means the server supports local
storage (memory, flash or disk) that can be used to storage (memory, flash or disk) that can be used to
store syslog messages."; store syslog messages.";
} }
container syslog { container syslog {
leaf local-storage-limit { leaf local-storage-limit {
skipping to change at page 113, line 38 skipping to change at page 119, line 15
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 implemented 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. When this boolean expression rule "if-feature-expr" in Section 14. Parenthesis are used to group
is evaluated, the operator order of precedence is (highest precedence expressions. When the expression is evaluated, the order of
first): "not", "and", "or". precedence is (highest precedence first): grouping (parenthesis),
"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" is implemented 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:
if-feature "not foo or bar and baz";
if-feature "(not foo) or (bar and baz)";
7.20.3. The deviation Statement 7.20.3. The deviation Statement
The "deviation" statement defines a hierarchy of a module that the The "deviation" statement defines a hierarchy of a module that the
server does not implement faithfully. The argument is a string that server does not implement faithfully. The argument is a string that
identifies the node in the schema tree where a deviation from the identifies the node in the schema tree where a deviation from the
module occurs. This node is called the deviation's target node. The module occurs. This node is called the deviation's target node. The
contents of the "deviation" statement give details about the contents of the "deviation" statement give details about the
deviation. deviation.
The argument string is an absolute schema node identifier (see The argument string is an absolute schema node identifier (see
skipping to change at page 116, line 30 skipping to change at page 122, line 5
If the target node has a property defined by an extension, this If the target node has a property defined by an extension, this
property can be deviated if the extension allows deviations. See property can be deviated if the extension allows deviations. See
Section 7.19 for details. Section 7.19 for details.
7.20.3.3. Usage Example 7.20.3.3. Usage Example
In this example, the server is informing client applications that it In this example, the server is informing client applications that it
does not support the "daytime" service in the style of RFC 867. does not support the "daytime" service in the style of RFC 867.
deviation /base:system/base:daytime { module my-deviations {
deviate not-supported; yang-version 1.1;
namespace "http://example.com/my-deviations";
prefix md;
import my-base {
prefix base;
}
deviation /base:system/base:daytime {
deviate not-supported;
}
...
} }
A server would advertise both modules "my-base" and "my-deviations".
The following example sets a server-specific default value to a leaf The following example sets a server-specific default value to a leaf
that does not have a default value defined: that does not have a default value defined:
deviation /base:system/base:user/base:type { deviation /base:system/base:user/base:type {
deviate add { deviate add {
default "admin"; // new users are 'admin' by default default "admin"; // new users are 'admin' by default
} }
} }
In this example, the server limits the number of name servers to 3: In this example, the server limits the number of name servers to 3:
skipping to change at page 117, line 12 skipping to change at page 122, line 48
If the original definition is: If the original definition is:
container system { container system {
must "daytime or time"; must "daytime or time";
... ...
} }
a server might remove this must constraint by doing: a server might remove this must constraint by doing:
deviation "/base:system" { deviation /base:system {
deviate delete { deviate delete {
must "daytime or time"; must "daytime or time";
} }
} }
7.21. Common Statements 7.21. Common Statements
This section defines substatements common to several other This section defines substatements common to several other
statements. statements.
skipping to change at page 119, line 25 skipping to change at page 125, line 7
conditional. The node defined by the parent data definition conditional. The node defined by the parent data definition
statement is only valid when the condition specified by the "when" statement is only valid when the condition specified by the "when"
statement is satisfied. The statement's argument is an XPath statement is satisfied. The statement's argument is an XPath
expression (see Section 6.4), which is used to formally specify this expression (see Section 6.4), which is used to formally specify this
condition. If the XPath expression conceptually evaluates to "true" condition. If the XPath expression conceptually evaluates to "true"
for a particular instance, then the node defined by the parent data for a particular instance, then the node defined by the parent data
definition statement is valid; otherwise, it is not. definition statement is valid; otherwise, it is not.
A leaf that is a list key MUST NOT have a "when" statement. A leaf that is a list key MUST NOT have a "when" statement.
See Section 8.2.2 for additional information. If a leaf key is defined in a grouping that is used in a list, the
"uses" statement MUST NOT have a "when" statement.
See Section 8.3.2 for additional information.
The XPath expression is conceptually evaluated in the following The XPath expression is conceptually evaluated in the following
context, in addition to the definition in Section 6.4.1: context, in addition to the definition in Section 6.4.1:
o If the "when" statement is a child of an "augment" statement, then o If the "when" statement is a child of an "augment" statement, then
the context node is the augment's target node in the data tree, if the context node is the augment's target node in the data tree, if
the target node is a data node. Otherwise, the context node is the target node is a data node. Otherwise, the context node is
the closest ancestor node to the target node that is also a data the closest ancestor node to the target node that is also a data
node. If no such node exists, the context node is the root node. node. If no such node exists, the context node is the root node.
The accessible tree is tentatively altered during the processing The accessible tree is tentatively altered during the processing
skipping to change at page 121, line 20 skipping to change at page 127, line 5
The following properties are true in a valid data tree: The following properties are true in a valid data tree:
o All "must" constraints MUST evaluate to "true". o All "must" constraints MUST evaluate to "true".
o All referential integrity constraints defined via the "path" o All referential integrity constraints defined via the "path"
statement MUST be satisfied. statement MUST be satisfied.
o All "unique" constraints on lists MUST be satisfied. o All "unique" constraints on lists MUST be satisfied.
o The "mandatory" constraint is enforced for leafs and choices,
unless the node or any of its ancestors has a "when" condition or
"if-feature" expression that evaluates to "false".
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. lists and leaf-lists, unless the node or any of its ancestors has
a "when" condition or "if-feature" expression that evaluates to
"false".
The running configuration datastore MUST always be valid. The running configuration datastore MUST always be valid.
8.2. NETCONF Constraint Enforcement Model 8.2. Configuration Data Modifications
o If a request creates configuration data nodes under a "choice",
any existing nodes from other "case" branches are deleted by the
server.
o If a request modifies a configuration data node such that any
node's "when" expression becomes false, then the node with the
"when" expression is deleted by the server.
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 NETCONF operations
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.2.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.
o If a leaf data value does not match the type constraints for the o If a leaf data value does not match the type constraints for the
leaf, including those defined in the type's "range", "length", and leaf, including those defined in the type's "range", "length", and
"pattern" properties, the server MUST reply with an "pattern" properties, the server MUST reply with an
"invalid-value" error-tag in the rpc-error, and with the error- "invalid-value" error-tag in the rpc-error, and with the error-
app-tag and error-message associated with the constraint, if any app-tag and error-message associated with the constraint, if any
skipping to change at page 122, line 26 skipping to change at page 128, line 29
o For insert handling, if the value for the attributes "before" and o For insert handling, if the value for the attributes "before" and
"after" are not valid for the type of the appropriate key leafs, "after" are not valid for the type of the appropriate key leafs,
the server MUST reply with a "bad-attribute" error-tag in the rpc- the server MUST reply with a "bad-attribute" error-tag in the rpc-
error. error.
o If the attributes "before" and "after" appears in any element that o If the attributes "before" and "after" appears in any element that
is not a list whose "ordered-by" property is "user", the server is not a list whose "ordered-by" property is "user", the server
MUST reply with an "unknown-attribute" error-tag in the rpc-error. MUST reply with an "unknown-attribute" error-tag in the rpc-error.
8.2.2. NETCONF <edit-config> Processing 8.3.2. NETCONF <edit-config> Processing
After the incoming data is parsed, the NETCONF server performs the After the incoming data is parsed, the NETCONF server performs the
<edit-config> operation by applying the data to the configuration <edit-config> operation by applying the data to the configuration
datastore. During this processing, the following errors MUST be datastore. During this processing, the following errors MUST be
detected: detected:
o Delete requests for non-existent data. o Delete requests for non-existent data.
o Create requests for existent data. o Create requests for existent data.
o Insert requests with "before" or "after" parameters that do not o Insert requests with "before" or "after" parameters that do not
exist. exist.
o Modification requests for nodes tagged with "when", and the "when" o Modification requests for nodes tagged with "when", and the "when"
condition evaluates to "false". In this case the server MUST condition evaluates to "false". In this case the server MUST
reply with an "unknown-element" error-tag in the rpc-error. reply with an "unknown-element" error-tag in the rpc-error.
During <edit-config> processing: 8.3.3. Validation
o If the NETCONF operation creates data nodes under a "choice", any
existing nodes from other "case" branches are deleted by the
server.
o If the NETCONF operation modifies a data node such that any node's
"when" expression becomes false, then the node with the "when"
expression is deleted by the server.
8.2.3. Validation
When datastore processing is complete, the final contents MUST obey When datastore processing is complete, the final contents MUST obey
all validation constraints. This validation processing is performed all validation constraints. This validation processing is performed
at differing times according to the datastore. If the datastore is at differing times according to the datastore. If the datastore is
"running" or "startup", these constraints MUST be enforced at the end "running" or "startup", these constraints MUST be enforced at the end
of the <edit-config> or <copy-config> operation. If the datastore is of the <edit-config> or <copy-config> operation. If the datastore is
"candidate", the constraint enforcement is delayed until a <commit> "candidate", the constraint enforcement is delayed until a <commit>
or <validate> operation. or <validate> operation.
9. Built-In Types 9. Built-In Types
skipping to change at page 133, line 28 skipping to change at page 139, line 28
value MUST be in the range -2147483648 to 2147483647, and it MUST be value MUST be in the range -2147483648 to 2147483647, and it MUST be
unique within the enumeration type. unique within the enumeration type.
If a value is not specified, then one will be automatically assigned. If a value is not specified, then one will be automatically assigned.
If the "enum" substatement is the first one defined, the assigned If the "enum" substatement is the first one defined, the assigned
value is zero (0); otherwise, the assigned value is one greater than value is zero (0); otherwise, the assigned value is one greater than
the current highest enum value (i.e., the highest enum value, the current highest enum value (i.e., the highest enum value,
implicit or explicit, prior to the current "enum" substatement in the implicit or explicit, prior to the current "enum" substatement in the
parent "type" statement). parent "type" statement).
Note that the the presence of an "if-feature" statement in an "enum"
statement does not affect the automatically assigned value.
If the current highest value is equal to 2147483647, then an enum If the current highest value is equal to 2147483647, then an enum
value MUST be specified for "enum" substatements following the one value MUST be specified for "enum" substatements following the one
with the current highest value. with the current highest value.
When an existing enumeration type is restricted, the "value" When an existing enumeration type is restricted, the "value"
statement MUST either have the same value as in the base type or not statement MUST either have the same value as in the base type or not
be present, in which case the value is the same as in the base type. be present, in which case the value is the same as in the base type.
9.6.5. Usage Example 9.6.5. Usage Example
skipping to change at page 134, line 41 skipping to change at page 140, line 46
and the following refinement is illegal: and the following refinement is illegal:
type my-base-enumeration-type { type my-base-enumeration-type {
// illegal enum refinement // illegal enum refinement
enum yellow { enum yellow {
value 4; // illegal value change value 4; // illegal value change
} }
enum black; // illegal addition of new name enum black; // illegal addition of new name
} }
The following example shows how an "enum" can be tagged with
"if-feature", making the value legal only on servers that advertise
the corresponding feature:
type enumeration {
enum tcp;
enum ssh {
if-feature ssh;
}
enum tls {
if-feature tls;
}
}
9.7. The bits Built-In Type 9.7. The bits Built-In Type
The bits built-in type represents a bit set. That is, a bits value The bits built-in type represents a bit set. That is, a bits value
is a set of flags identified by small integer position numbers is a set of flags identified by small integer position numbers
starting at 0. Each bit number has an assigned name. starting at 0. Each bit number has an assigned name.
When an existing bits type is restricted, the set of assigned names
in the new type MUST be a subset of the base type's set of assigned
names. The bit position of such an assigned name MUST not be
changed.
9.7.1. Restrictions 9.7.1. Restrictions
A bits type cannot be restricted. A bits type can be restricted with the "bit" (Section 9.7.4)
statement.
9.7.2. Lexical Representation 9.7.2. Lexical Representation
The lexical representation of the bits type is a space-separated list The lexical representation of the bits type is a space-separated list
of the individual bit values that are set. An empty string thus of the individual bit values that are set. An empty string thus
represents a value where no bits are set. represents a value where no bits are set.
9.7.3. Canonical Form 9.7.3. Canonical Form
In the canonical form, the bit values are separated by a single space In the canonical form, the bit values are separated by a single space
skipping to change at page 136, line 7 skipping to change at page 142, line 33
hypothetical bit field. The position value MUST be in the range 0 to hypothetical bit field. The position value MUST be in the range 0 to
4294967295, and it MUST be unique within the bits type. 4294967295, and it MUST be unique within the bits type.
If a bit position is not specified, then one will be automatically If a bit position is not specified, then one will be automatically
assigned. If the "bit" substatement is the first one defined, the assigned. If the "bit" substatement is the first one defined, the
assigned value is zero (0); otherwise, the assigned value is one assigned value is zero (0); otherwise, the assigned value is one
greater than the current highest bit position (i.e., the highest bit greater than the current highest bit position (i.e., the highest bit
position, implicit or explicit, prior to the current "bit" position, implicit or explicit, prior to the current "bit"
substatement in the parent "type" statement). substatement in the parent "type" statement).
Note that the the presence of an "if-feature" statement in an "bit"
statement does not affect the automatically assigned position.
If the current highest bit position value is equal to 4294967295, If the current highest bit position value is equal to 4294967295,
then a position value MUST be specified for "bit" substatements then a position value MUST be specified for "bit" substatements
following the one with the current highest position value. following the one with the current highest position value.
When an existing bits type is restricted, the "position" statement
MUST either have the same value as in the base type or not be
present, in which case the value is the same as in the base type.
9.7.5. Usage Example 9.7.5. Usage Example
Given the following leaf: Given the following typedef and leaf:
leaf mybits { typedef mybits-type {
type bits { type bits {
bit disable-nagle { bit disable-nagle {
position 0; position 0;
} }
bit auto-sense-speed { bit auto-sense-speed {
position 1; position 1;
} }
bit ten-mb-only { bit ten-mb-only {
position 2; position 2;
} }
} }
}
leaf mybits {
type mybits-type;
default "auto-sense-speed"; default "auto-sense-speed";
} }
The lexical representation of this leaf with bit values disable-nagle The lexical representation of this leaf with bit values disable-nagle
and ten-mb-only set would be: and ten-mb-only set would be:
<mybits>disable-nagle ten-mb-only</mybits> <mybits>disable-nagle ten-mb-only</mybits>
The following example shows a legal refinement of this type:
type mybits-type {
// legal bit refinement
bit disable-nagle {
position 0;
}
bit auto-sense-speed {
position 1;
}
}
and the following refinement is illegal:
type mybits-type {
// illegal bit refinement
bit disable-nagle {
position 2; // illegal position change
}
bit hundred-mb-only; // illegal addition of new name
}
9.8. The binary Built-In Type 9.8. The binary Built-In Type
The binary built-in type represents any binary data, i.e., a sequence The binary built-in type represents any binary data, i.e., a sequence
of octets. of octets.
9.8.1. Restrictions 9.8.1. Restrictions
A binary type can be restricted with the "length" (Section 9.4.4) A binary type can be restricted with the "length" (Section 9.4.4)
statement. The length of a binary value is the number of octets it statement. The length of a binary value is the number of octets it
contains. contains.
skipping to change at page 149, line 41 skipping to change at page 156, line 41
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
set with the initial context node as its only member. set with the initial context node as its only member.
10.1.1.1. Usage Example
With this list:
list interface {
key "name";
...
leaf enabled {
type boolean;
}
...
}
the following leaf defines a must expression that ensures that the
referred interface is enabled:
leaf outgoing-interface {
type leafref {
path "/interface/name";
}
must '/interface[name=current()]/enabled = "true"';
}
10.2. Functions for Strings 10.2. Functions for Strings
10.2.1. re-match() 10.2.1. re-match()
boolean re-match(string subject, string pattern) boolean re-match(string subject, string pattern)
The re-match() function returns true if the "subject" string matches The re-match() function returns true if the "subject" string matches
the regular expression "pattern"; otherwise it returns false. the regular expression "pattern"; otherwise it returns false.
The function "re-match" checks if a string matches a given regular The function "re-match" checks if a string matches a given regular
skipping to change at page 151, line 34 skipping to change at page 158, line 45
error-message error-message
"The management interface cannot be disabled."; "The management interface cannot be disabled.";
} }
} }
} }
10.4. Functions for the YANG Type "identityref" 10.4. Functions for the YANG Type "identityref"
10.4.1. derived-from() 10.4.1. derived-from()
boolean derived-from(node-set nodes, boolean derived-from(node-set nodes, string identity)
string module-name,
string identity-name)
The derived-from() function returns true if the first node in
document order in the argument "nodes" is a node of type identityref,
and its value is an identity that is derived from the identity
"identity-name" defined in the YANG module "module-name"; otherwise
it returns false.
10.4.2. derived-from-or-self()
boolean derived-from-or-self(node-set nodes,
string module-name,
string identity-name)
The derived-from-or-self() function returns true if the first node in The derived-from() function returns true if any node in the argument
document order in the argument "nodes" is a node of type identityref, "nodes" is a node of type identityref, and its value is an identity
and its value is an identity that is equal to or derived from the that is derived from (see Section 7.18.2) the identity "identity";
identity "identity-name" defined in the YANG module "module-name";
otherwise it returns false. otherwise it returns false.
10.4.2.1. Usage Example The parameter "identity" is a string matching the rule
"identifier-ref" in Section 14. If a prefix is present on the
identity, it refers to an identity defined in the module that was
imported with that prefix, or the local module if the prefix matches
the local module's prefix. If no prefix is present, the identity
refers to an identity defined in the current module or an included
submodule.
10.4.1.1. Usage Example
module example-interface { module example-interface {
... yang-version 1.1;
...
identity interface-type; identity interface-type;
identity ethernet { identity ethernet {
base interface-type; base interface-type;
} }
identity fast-ethernet { identity fast-ethernet {
base ethernet; base ethernet;
} }
skipping to change at page 152, line 39 skipping to change at page 159, line 45
... ...
leaf type { leaf type {
type identityref { type identityref {
base interface-type; base interface-type;
} }
} }
... ...
} }
augment "/interface" { augment "/interface" {
when 'derived-from(type, when 'derived-from(type, "exif:ethernet")';
"example-interface", // generic ethernet definitions here
"ethernet")';
// ethernet-specific definitions here
} }
...
} }
10.4.2. derived-from-or-self()
boolean derived-from-or-self(node-set nodes, string identity)
The derived-from-or-self() function returns true if any node in the
argument "nodes" is a node of type identityref, and its value is an
identity that is equal to or derived from (see Section 7.18.2) the
identity "identity"; otherwise it returns false.
The parameter "identity" is a string matching the rule
"identifier-ref" in Section 14. If a prefix is present on the
identity, it refers to an identity defined in the module that was
imported with that prefix, or the local module if the prefix matches
the local module's prefix. If no prefix is present, the identity
refers to an identity defined in the current module or an included
submodule.
10.4.2.1. Usage Example
The module defined in ^derived-from-ex^ might also have:
augment "/interface" {
when 'derived-from-or-self(type,
"example-interface",
"fast-ethernet")';
// fast-ethernet-specific definitions here
}
10.5. Functions for the YANG Type "enumeration" 10.5. Functions for the YANG Type "enumeration"
10.5.1. enum-value() 10.5.1. enum-value()
number enum-value(node-set nodes) number enum-value(node-set nodes)
The enum-value() function checks if the first node in document order The enum-value() function checks if the first node in document order
in the argument "nodes" is a node of type enumeration, and returns in the argument "nodes" is a node of type enumeration, and returns
the enum's integer value. If the "nodes" node set is empty, or if the enum's integer value. If the "nodes" node set is empty, or if
the first node in "nodes" is not of type enumeration, it returns NaN. the first node in "nodes" is not of type enumeration, it returns NaN.
10.5.1.1. Usage Example 10.5.1.1. Usage Example
skipping to change at page 155, line 34 skipping to change at page 163, line 20
o A "default" statement may be added to a leaf that does not have a o A "default" statement may be added to a leaf that does not have a
default value (either directly or indirectly through its type). default value (either directly or indirectly through its type).
o A "units" statement may be added. o A "units" statement may be added.
o A "reference" statement may be added or updated. o A "reference" statement may be added or updated.
o A "must" statement may be removed or its constraint relaxed. o A "must" statement may be removed or its constraint relaxed.
o A "when" statement may be removed or its constraint relaxed.
o A "mandatory" statement may be removed or changed from "true" to o A "mandatory" statement may be removed or changed from "true" to
"false". "false".
o A "min-elements" statement may be removed, or changed to require o A "min-elements" statement may be removed, or changed to require
fewer elements. fewer elements.
o A "max-elements" statement may be removed, or changed to allow o A "max-elements" statement may be removed, or changed to allow
more elements. more elements.
o A "description" statement may be added or clarified without o A "description" statement may be added or clarified without
skipping to change at page 157, line 19 skipping to change at page 164, line 52
version 1.1 submodule. version 1.1 submodule.
A YANG version 1 module or submodule MUST NOT import a YANG version A YANG version 1 module or submodule MUST NOT import a YANG version
1.1 module by revision. 1.1 module by revision.
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 at the same time. In such cases, a NETCONF server MUST these modules (A and B) at the same time. In such cases, a NETCONF
advertise both modules using the rules defined in Section 5.6.5, and server MUST advertise both modules using the rules defined in
SHOULD advertise module A and the latest revision of module B that is Section 5.6.5, and SHOULD advertise module A and the latest revision
specified with YANG version 1 according to the rules defined in of module B that is specified with YANG version 1 according to the
[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
A YANG module can be translated into an alternative XML-based syntax A YANG module can be translated into an alternative XML-based syntax
skipping to change at page 163, line 21 skipping to change at page 171, line 21
yang-version-stmt = yang-version-keyword sep yang-version-arg-str yang-version-stmt = yang-version-keyword sep yang-version-arg-str
stmtend stmtend
yang-version-arg-str = < a string that matches the rule > yang-version-arg-str = < a string that matches the rule >
< yang-version-arg > < yang-version-arg >
yang-version-arg = "1.1" yang-version-arg = "1.1"
import-stmt = import-keyword sep identifier-arg-str optsep import-stmt = import-keyword sep identifier-arg-str optsep
"{" stmtsep "{" stmtsep
;; these stmts can appear in any order
prefix-stmt prefix-stmt
[revision-date-stmt] [revision-date-stmt]
"}" stmtsep "}" stmtsep
include-stmt = include-keyword sep identifier-arg-str optsep include-stmt = include-keyword sep identifier-arg-str optsep
(";" / (";" /
"{" stmtsep "{" stmtsep
[revision-date-stmt] [revision-date-stmt]
"}") stmtsep "}") stmtsep
skipping to change at page 185, line 14 skipping to change at page 193, line 14
CRLF = CR LF CRLF = CR LF
; Internet standard new line ; Internet standard new line
DIGIT = %x30-39 DIGIT = %x30-39
; 0-9 ; 0-9
DQUOTE = %x22 DQUOTE = %x22
; double quote ; double quote
HEXDIG = DIGIT /
%x61 / %x62 / %x63 / %x64 / %x65 / %x66
; only lower-case a..f
HTAB = %x09 HTAB = %x09
; horizontal tab ; horizontal tab
LF = %x0A LF = %x0A
; linefeed ; linefeed
SP = %x20 SP = %x20
; space ; space
VCHAR = %x21-7E
; visible (printing) characters
WSP = SP / HTAB WSP = SP / HTAB
; whitespace ; whitespace
<CODE ENDS> <CODE ENDS>
15. NETCONF Error Responses for YANG Related Errors 15. NETCONF Error Responses for YANG Related Errors
A number of NETCONF error responses are defined for error cases A number of NETCONF error responses are defined for error cases
related to the data-model handling. If the relevant YANG statement related to the data-model handling. If the relevant YANG statement
has an "error-app-tag" substatement, that overrides the default value has an "error-app-tag" substatement, that overrides the default value
skipping to change at page 189, line 5 skipping to change at page 196, line 35
Reading malformed documents from unknown or untrusted sources could Reading malformed documents from unknown or untrusted sources could
result in an attacker gaining privileges of the user running the YANG result in an attacker gaining privileges of the user running the YANG
parser. In an extreme situation, the entire machine could be parser. In an extreme situation, the entire machine could be
compromised. compromised.
18. Contributors 18. Contributors
The following people all contributed significantly to the initial The following people all contributed significantly to the initial
YANG document: YANG document:
- Andy Bierman (Brocade) - Andy Bierman (YumaWorks)
- Balazs Lengyel (Ericsson) - Balazs Lengyel (Ericsson)
- David Partain (Ericsson) - David Partain (Ericsson)
- Juergen Schoenwaelder (Jacobs University Bremen) - Juergen Schoenwaelder (Jacobs University Bremen)
- Phil Shafer (Juniper Networks) - Phil Shafer (Juniper Networks)
19. Acknowledgements 19. Acknowledgements
The editor wishes to thank the following individuals, who all The editor wishes to thank the following individuals, who all
provided helpful comments on various versions of this document: provided helpful comments on various versions of this document:
Mehmet Ersue, Washam Fan, Joel Halpern, Per Hedeland, Leif Johansson, Mehmet Ersue, Washam Fan, Joel Halpern, Per Hedeland, Leif Johansson,
Ladislav Lhotka, Gerhard Muenz, Peyman Owladi, Tom Petch, Randy Ladislav Lhotka, Gerhard Muenz, Peyman Owladi, Tom Petch, Randy
Presuhn, David Reid, Jernej Tuljak, and Bert Wijnen. Presuhn, David Reid, Jernej Tuljak, Kent Watsen, Bert Wijnen, and
Robert Wilton.
20. ChangeLog 20. ChangeLog
RFC Editor: remove this section upon publication as an RFC. RFC Editor: remove this section upon publication as an RFC.
20.1. Version -08 20.1. Version -09
o Editorial fixes and clarifications after WGLC reviews.
o when statement context clarification.
o Allow "augment" to add conditionally mandatory nodes (see
Section 7.17).
o Allow non-unique config false leaf-lists.
o Made handling of choice and false "when" expressions non-NETCONF
specific.
o Changed the function signatures for "derived-from" and
"derived-from-or-self".
20.2. Version -08
o Fixes after WGLC reviews. o Fixes after WGLC reviews.
20.2. Version -07 20.3. Version -07
o Fixes after WG review. o Fixes after WG review.
o Included solution Y60-01. o Included solution Y60-01.
20.3. Version -06 20.4. Version -06
o Included solution Y45-05. o Included solution Y45-05.
20.4. Version -05 20.5. Version -05
o Included solution Y18-01. o Included solution Y18-01.
o Included solution Y25-02 (parts of it was included in -04). o Included solution Y25-02 (parts of it was included in -04).
o Included solution Y34-05. o Included solution Y34-05.
o Included solution Y36-03. o Included solution Y36-03.
20.5. Version -04 20.6. Version -04
o Incorporated changes to ABNF grammar after review and errata for o Incorporated changes to ABNF grammar after review and errata for
RFC 6020. RFC 6020.
o Included solution Y16-03. o Included solution Y16-03.
o Included solution Y49-04. o Included solution Y49-04.
o Included solution Y58-01. o Included solution Y58-01.
o Included solution Y59-01. o Included solution Y59-01.
20.6. Version -03 20.7. Version -03
o Incorporated changes from WG reviews. o Incorporated changes from WG reviews.
o Included solution Y05-01. o Included solution Y05-01.
o Included solution Y10-01. o Included solution Y10-01.
o Included solution Y13-01. o Included solution Y13-01.
o Included solution Y28-02. o Included solution Y28-02.
o Included solution Y55-01 (parts of it was included in -01). o Included solution Y55-01 (parts of it was included in -01).
20.7. Version -02 20.8. Version -02
o Included solution Y02-01. o Included solution Y02-01.
o Included solution Y04-02. o Included solution Y04-02.
o Included solution Y11-01. o Included solution Y11-01.
o Included solution Y41-01. o Included solution Y41-01.
o Included solution Y56-01. o Included solution Y56-01.
20.8. Version -01 20.9. Version -01
o Included solution Y01-01. o Included solution Y01-01.
o Included solution Y03-01. o Included solution Y03-01.
o Included solution Y06-02. o Included solution Y06-02.
o Included solution Y07-01. o Included solution Y07-01.
o Included solution Y14-01. o Included solution Y14-01.
skipping to change at page 191, line 13 skipping to change at page 199, line 19
o Included solution Y23-01. o Included solution Y23-01.
o Included solution Y29-01. o Included solution Y29-01.
o Included solution Y30-01. o Included solution Y30-01.
o Included solution Y31-01. o Included solution Y31-01.
o Included solution Y35-01. o Included solution Y35-01.
20.9. Version -00 20.10. Version -00
o Applied all reported errata for RFC 6020. o Applied all reported errata for RFC 6020.
o Updated YANG version to 1.1, and made the "yang-version" statement o Updated YANG version to 1.1, and made the "yang-version" statement
mandatory. mandatory.
21. References 21. References
21.1. Normative References 21.1. Normative References
 End of changes. 97 change blocks. 
398 lines changed or deleted 746 lines changed or added

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